Surface policy does not govern context_panel_expected_build.py, which computes the fingerprints

[shiny-code-bot]

Problem

scripts/context_panel_surface_manifest/ imports scripts/context_panel_expected_build.py at module top level (core.py, artifact.py, artifact_comparison.py). That module defines hash_parts, SURFACE_DIGEST_DOMAIN, and SIGNING_CLASSES, which the manifest uses to compute the project, contract, and render fingerprints.

Config/ContextPanelSurfacePolicy.json lists the sibling scripts/context_panel_comparison_schema.py and scripts/context_panel_surface_manifest/**/*.py as governed surface-tooling inputs, but not context_panel_expected_build.py. A change to how fingerprints are hashed in that file therefore does not move the contract fingerprint, even though it changes what every fingerprint means.

Found during review of #709 by computing the real import closure of scripts/context-panel-surface-manifest.py. That PR's CI gate already treats the file as a build input; this issue is only about the surface policy.

Why this is not a one-line fix

Adding the path to the policy changes a contract input, moves contractFingerprint, and makes the current replay bundle stale. It should be done deliberately, at a point where regenerating the bundle is acceptable, not as a side effect of another change.

Acceptance criteria

• Decide whether scripts/context_panel_expected_build.py is a governed surface-tooling input. If not, record why in docs/.
• If it is, add it to both tooling lists in the policy and regenerate what the fingerprint move requires.
• Add a check that fails when the manifest entry point imports a module under scripts/ that the policy does not govern, so the list cannot drift again. Tests/ScriptsTests/test_ci_change_scope.py in ci: skip product builds when a pull request cannot affect them #709 has an import-closure probe that can be reused.

State

Governance was approved by the recorded Owner decision on 2026-09-20. Implementation remains not started and is scheduled immediately before the next validation train, not during one. See Current Status for the CP-710-D1 timing wait and recovery action.

Current Status

State: Waiting; governance approved, implementation not started. CP-710-D1 stopped before claim/code on 2026-10-03.
Next action: Coordinate the policy change, import-closure check and required replay regeneration with the release-owning session immediately before the next validation train, per the recorded 2026-09-20 Owner decision.
Blocked by: No native issue blocker. The Owner decision explicitly excludes making this fingerprint change during a train; #722 records unfinished 1.0.69 companion delivery/validation work.
Waiting for: The approved between-train preparation point and explicit private replay-root bindings. No new governance decision is needed.
Last verified: 2026-10-03; full #710 and linked #709 read, related #695 history checked; no recorded #710 claim, open implementation PR or local task worktree found. #722's recorded status was checked; no live release system or installed runtime was validated. No release dispatch is authorized by this trial.

[shiny-code-bot]

Owner decision (2026-09-20): yes, scripts/context_panel_expected_build.py is a governed surface-tooling input. Add it at a point where regenerating the replay bundle is convenient: just before the next validation train, not during one.

State: decided, not started. Next action: make the policy change and the import-closure check together, immediately before preparing the next train.

[shiny-code-app]

CP-710-D1: read the complete issue and its comment, linked PR #709 and the related #695 history; rechecked the issue, open PR inventory and local worktrees before any claim. No recorded claim or implementing PR for #710 was found. Stopping before code under the brief's pre-code wait rule: the recorded Owner decision approves governing context_panel_expected_build.py, but explicitly schedules the policy/import-closure change and replay regeneration immediately before the next validation train, “not during one.” #722's current status records the 1.0.69 Mac release as delivered while companion signed/runtime gates and release channels remain unfinished. That is evidence of an unfinished recorded train, not a live release-system check.

The overnight admission is the merged overall DIRECTION.md Order item 3 rule: engineering/tooling can proceed when every milestone waits on people and provider capacity would otherwise go unused, as recorded in direction#16 and this brief. That admission does not resolve the issue's deliberately chosen train boundary. No new Owner question is raised: the governance choice is already decided; this waits on the recorded timing condition. Resume with the release-owning session immediately before the next train, using explicitly supplied private replay-root bindings; never discover roots or dispatch a release for this item. No claim, worktree, source edit, build, install, production change or release dispatch occurred. Tests, model review and JetBrains inspection were not run because implementation did not start. The primary checkout is clean on main; unrelated worktrees remain in place.