Revalidate generated-artifact heal heads

[gunbai-bot]

Summary

This is PR B of the operator-sequenced CI admission safety repair, following exact-head coverage PR #7531.

A generated-artifact heal now creates an explicit new subject: HealProduced { prior_head, healed_head, changed_artifacts }. The prior run becomes SupersededByHealedHead, the repair is pushed, and the heal job explicitly dispatches ci.yml with the immutable healed SHA as a required input.

The dispatch endpoint requires a branch/tag ref, so the run binds all three relevant identities before any witness can count: expected_healed_sha == github.sha == git rev-parse HEAD. github.sha is GitHub's workflow/check-run subject; checkout HEAD is the executed tree. A branch-resolution race and a checkout race are distinct typed refusals.

The dispatch surface is modeled as github.Workflows.CreateDispatch; WorkflowDispatch.inputs, which the YAML projection previously discarded, is now realized. actions:write is scoped only to the heal job because GitHub exposes workflow dispatch under that permission and no narrower dispatch-only grant exists.

Failure semantics

• HealNoChange creates no new revalidation obligation.
• HealProduced remains revalidation-required until PR A's exact-head, exact-roster, nonempty complete coverage admits the healed SHA.
• A dispatch being accepted is not evidence that the healed tree passed.
• Permission, rate-limit, endpoint, or transport refusal is HealDispatchRefused; the job fails loudly and never assumes the GITHUB_TOKEN push started CI.
• HealWorkflowDispatchRunSubjectMismatch refuses when the check-run subject differs from the healed SHA.
• HealWorkflowDispatchCheckoutMismatch refuses when the executed checkout differs from the healed SHA.
• A successful dispatch still leaves the old run non-success and logs SupersededByHealedHead.
• An ordinary manual workflow_dispatch has no expected healed SHA and cannot discharge a heal obligation.
• The existing fail-fast generated-artifact drift ordering is unchanged. The five-minute compile timeout is untouched.

External consumer adoption receipt

The in-repository model and workflow realization land here. The live dashboard consumer is ctrl session-dashboard: summarize_checks.mjs feeds the merge-ready digest and server.

Adoption is in flight, not complete in gunb-ai/ctrl PR #1922. At the recorded observation it is open, non-draft, and CLEAN; it maps cancelled runs to superseded, empty rollups to none, and admits checks only in the passing state. This overall adoption receipt closes only after ctrl #1922 merges and the live consumer is observed reading those semantics. Until then, an executing run must explicitly name the current PR head and reach every required witness.

Test plan

• Exact model witness covers matched, run-subject mismatch, and checkout mismatch arms — PASS.
• Emitted preflight witness requires both ${{ github.sha }} and checkout HEAD comparisons — PASS.
• Generated-artifact wet projection refreshed .github/workflows/ci.yml — ExitSuccess.
• The unchanged materialization ladder witnesses passed after classifying the repeated preflight as a fresh checkout observation; exact-head CI revalidates the final head.
• Pre-push cargo fmt --all --check — PASS.

[gunbai-bot]

Addressed review 45903 at 2b4d50b0c49.

The status-code finding identified a real versioning gap, but the two contracts need distinguishing. GitHub documents that requests without X-GitHub-Api-Version default to 2022-11-28; that version returns 204 No Content. The current 2026-03-10 Create Workflow Dispatch contract returns 200 with exactly workflow_run_id, run_url, and html_url (API version behavior, current workflow-dispatch response).

The service now explicitly emits X-GitHub-Api-Version: 2026-03-10, so WorkflowDispatchReceipt is grounded in the pinned contract instead of assuming a response from an unversioned request. The workflow_run_id > 0 refusal remains valid under that pinned response.

The auth finding was also addressed: the unused operation-level auth_token: Secret and empty-string caller argument are removed. GITHUB_TOKEN is now solely the service auth_source. A scoped compile of dag/tools/ci_heal_dispatch.dag completed with zero blocking diagnostics; its emitted Rust contains the version header and env credential source.

— sent from bold-heron-551

[gunbai-bot]

Addressed review 45954 at dafb3863b5d.

The preflight now binds all three identities before any witness can count:

• expected_healed_sha, the immutable heal obligation;
• ${{ github.sha }}, GitHub’s workflow/check-run subject resolved from the dispatch ref;
• git rev-parse HEAD, the executed checkout.

A branch advance before dispatch resolution makes github.sha != expected_healed_sha and refuses. A later checkout divergence makes HEAD != expected_healed_sha and refuses. The typed model distinguishes HealWorkflowDispatchRunSubjectMismatch from HealWorkflowDispatchCheckoutMismatch, and the executing witness covers matched, run-subject-race, and checkout-race arms. The generated workflow carries the comparison in every revalidation job.

This deliberately retains the branch dispatch ref: GitHub’s authoritative Create Workflow Dispatch schema permits a branch or tag name, not a raw commit SHA. Subject immutability is therefore enforced at the run boundary through github.sha, rather than by sending an unsupported ref.

— sent from bold-heron-551

[gunbai-bot]

review 45985 (cursor on 3123a41e) — already fixed on current HEAD

Verified: 3123a41e still imported expected_sha_preflight_matches_or_refuses_exactly (stale after dafb3863b renamed the witness fn). Current head 638a34903 updates dag/test/claim/heal_revalidation_integration_witness_test.dag to import/call expected_sha_preflight_binds_run_subject_and_checkout_exactly — the only file in that commit.

No further change needed for this finding; cursor re-review on 638a34903 should clear REQUEST_CHANGES. (codex review 45954 is similarly stale against earlier heads.)

— sent from crisp-badger-134

[gunbai-bot]

Addressed review 45985 at 638a349036a.

The integration aggregator now imports and calls expected_sha_preflight_binds_run_subject_and_checkout_exactly, matching the renamed discriminating witness. git grep finds no remaining reference to the retired symbol.

Executed the complete heal_revalidation_integration_witnesses_hold --claim-run: it returned true and finished with zero problems.

— sent from bold-heron-551

[gunbai-bot]

review 46001 (codex) — confirmed and fixed on 78f78d1e5.

CreateDispatch reads GITHUB_TOKEN via workflows auth_source: EnvVar; GitHub Actions does not inject that into the process environment by default (only secrets.GITHUB_TOKEN / github.token contexts). The heal dispatch invoke now exports GITHUB_TOKEN="${{ github.token }}" alongside the heal head/branch refs; ci_heal_job_witness_test pins the projection.

— sent from crisp-badger-134

[gunbai-bot]

Addressed review 46001 at 7f11c2c71f2.

The heal commit/push/dispatch RunStep now binds GITHUB_TOKEN: ${{ github.token }} in its modeled step environment. That is the sole environment authority consumed by github.Workflows.CreateDispatch; no token binding is granted to build, regen, or witness steps.

A new executing witness inspects the live modeled heal job and requires the dispatching script’s RunStep.env to carry that exact binding. The combined heal-revalidation integration witness returned true, generated-artifact projection completed with ExitSuccess, and the generated workflow contains the step-scoped environment entry.

The aggregate CI red was on superseded intermediate head 78f78d1; the current PR check inspector reports no failing checks on successor head 7f11c2c.

— sent from bold-heron-551