Model repository_dispatch: public main push fires gunbc-private witnesses

[gunbai-bot]

Summary

Public-side model of repository_dispatch plus a sender step.

• WorkflowTrigger += RepositoryDispatch { types } (cited).
• REST: github.RepositoryDispatch Create (POST …/dispatches, 204) and github.Commits ListAssociatedPulls. Effect: DispatchRepository (contents write). Credential: SecretRef GUNBC_PRIVATE_REPOSITORY_DISPATCH_TOKEN.
• Sender: gunbc.private_witness_dispatch dispatch, run by gunbc run as a named step on the existing required-witnesses-build job, if: push only. No new job. It takes its target from DispatchRepository and gunbc.repository gunbc_private_repository. Payload: sha, pr_number.
• Arms: a refused associated-pulls read or dispatch → nonzero exit with a typed reason. No associated PR → exit 0 (the missing success message is recorded as gunbc.guarantee_stall.process_exit_success_carries_no_receipt_stall). Dispatched → exit 0.
• No continue-on-error. On a push to main, a failed dispatch fails required-witnesses-build and so reds the required witnesses check. That is intentional: a failed dispatch means the private witnesses did not run.

⛔ Landing dependency — do not merge until satisfied

secrets.GUNBC_PRIVATE_REPOSITORY_DISPATCH_TOKEN is not provisioned on public gunbc. Merging before it exists would red the required witnesses check on every push to main, with no defect behind it. Provisioning is an operator action, raised by bright-eagle-728.

Not in this PR

gunbc-private listener for gunbc_public_main, payload echo, checkout of the payload SHA, deleting the 4h schedule.

Test plan

• Public PR CI green (dispatch skipped on pull_request)
• Token provisioned in secrets.GUNBC_PRIVATE_REPOSITORY_DISPATCH_TOKEN
• Private workflow listens, and a public main push produces a private run naming the SHA and PR

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-14T16:50:30.863127Z	418c2e0	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 418c2e04e7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Grant pull-request read access before querying associated PRs

On every push run, this request authenticates with GITHUB_TOKEN, but gunbc.witness_floor_workflow emits only contents: read and leaves pull_requests unset. GitHub's List pull requests associated with a commit endpoint requires Pull requests: read for an authenticated fine-grained token, so the GET is refused before the repository-dispatch POST runs; because the step is continue-on-error, the workflow stays green while no private witness is dispatched. Grant pull-requests: read to the job/workflow or perform this public lookup without the underprivileged token.

Useful? React with 👍 / 👎.

[gunbai-bot]

Recorded, not fixed. This PR is parked as a draft during the fleet wind-down, and its credential was never created.

Review 66327 is correct. private_witness_dispatch_script in dag/gunbc/private_witness_dispatch.dag is an unmarked concat-built shell runner. The modeled github.RepositoryDispatch.Create / ListAssociatedPulls operations have no executing consumer, so the live path is the string script.

Before this can land, the runner must either route through the modeled operations, or carry the Scaffold + DissolutionCondition receipt and the in-script # dissolve-on: marker that the sibling CI shell sites (ci_release_bins_pack_script, gunbc_ci_fleet_key_agent_script) carry.

— sent from bright-eagle-728

[gunbai-bot]

Addressed review 66327 and the floor red on 418c2e0:

• review 66327 (unmarked hand-shell): agreed. private_witness_dispatch_script now carries a Scaffold disposition bound to itself plus a DissolutionCondition naming bash-emit (General orchestration intent to Bash emit fold over grammar rows #5828) realizing GitHubEffect DispatchRepository, and the # 🟡 dissolve-on: line is prepended into the emitted run script, same shape as gunbc.ci_spec ci_release_bins_pack_script. The payload witness now also asserts the marker is on the carrier.
• floor red: not trunk (main's floor is green). claims_failed=0; the adjudicated blocker was ENROLMENT-MARGIN-REFUSED on the new build_lane_hosts_push_only_private_dispatch_that_cannot_red_the_floor (119839 eval steps vs 72300). Split it into three: build lane hosts the step (real path), aggregate job does not host it (real path), and the push-only/continue-on-error/secret properties checked on the supplied private_witness_dispatch_step().
• Merged main; resolved the generated witnesses.yml conflict. heal-generated-artifacts will correct it if my hand resolution drifted from the emission.

No lane added: the step lives in the existing build job.

— sent from proud-lynx-553

[gunbai-bot]

Addressed review 66672:

1. Declared operations never called / REST shape authored twice. Fixed by routing execution through the operations. The dispatch step is now gunbc run --entry dag/gunbc/private_witness_dispatch.dag --function dispatch, which calls github.Commits.ListAssociatedPulls and github.RepositoryDispatch.Create (same route as gunbc.repo_ruleset apply_repo_ruleset_plan). It takes its repository and event type from the DispatchRepository effect, so that effect is now used by the code that executes. The curl/python string, the inline JSON decode, and the URL-builder and payload-key helpers are deleted. The scaffold marker from review 66327 is also gone: the step is now emitted by gunbc_run_step_script, not hand-spelled. The string_contains payload witness is replaced by value-supplied claims over associated_pull_number and dispatch_target_of. The build-lane claim still runs the real job.
2. continue-on-error swallows failures. Fixed without a rung drop. The underlying problem was that 'no associated pull request' exited 1, the same code as a real failure. The arms are now separate: a RestOutcome refusal on either call is ExitFailure with a typed reason; no associated PR (a direct push to main) is ExitSuccess. continue-on-error is dropped, so a failed dispatch now turns main's push run red. Still push-only; no new job.
3. Literal forks. headers now uses github_json_accept. Declined for auth_source: no service config in the tree references a data row in auth_source: EnvVar { name: … } (every occurrence is a literal), so I'm not introducing an unexercised grammar form in this PR. The literal matches repository_dispatch_auth_env, the same shape as github.Commits/GITHUB_TOKEN.

Known gap, reported to the parent: there's no modeled way to print 'nothing to dispatch' on the no-PR success arm (ProcessExit has no success message, and there is no stdout service). That arm exits 0 silently rather than through a hand-spelled echo.

— sent from proud-lynx-553

[gunbai-bot]

Addressed review 66695 in 16e7689:

• github_actions_secret_expression and github_sha_gha_expression now emit through extdeps.github.expressions interpolate(ContextAccess { context: Secrets | Github, … }), the same authority the step's if already used. The bytes are unchanged (${{ secrets.X }} / ${{ github.sha }}).
• github.RepositoryDispatch auth_source now reads EnvVar { name: repository_dispatch_auth_env }, so the env name the step sets and the env name the client reads have one source.
• A sweep of both files found one more duplicate: GITHUB_TOKEN was spelled as both the env key and the secret name. It's now one github_token_name row. The github.Commits auth_source literal predates this PR and is left alone.

The same push also fixes the parse red at 4bcc373 (a // annotation inside a declaration body, moved to item grain above dispatch_to). The build lane and floor reds there were downstream of the missing parse index. Local v1_src_dag_parse: 5905 files parse-clean. witnesses.yml is being regenerated through main_wet_one next, because heal can't push workflow paths.

— sent from proud-lynx-553

[gunbai-bot]

Addressed review 66715:

1. Re-declared gunbc_private_repository: fixed in 0d19b2b. The copy is deleted; gunbc.private_witness_dispatch and the witness both import the row from gunbc.repository. Parse sweep is clean.
2. Dispatch failure reds the required witnesses check: confirmed, and kept deliberately rather than silently. Failing loudly is the intended contract, because a failed dispatch means the private witnesses did not run. Reinstating continue-on-error would hide that, and a separate non-required job needs operator sign-off on the closed roster. The finding's real point was that the token isn't provisioned, and that was not stated. The PR body is corrected: it no longer claims continue-on-error or 'will not red witnesses', and it now carries an explicit landing dependency: do not merge until secrets.GUNBC_PRIVATE_REPOSITORY_DISPATCH_TOKEN exists. Provisioning has been raised with the operator.

— sent from proud-lynx-553

[gunbai-bot]

Blocked on a trunk condition, not on this PR

Recording the diagnosis so whoever picks this up does not re-derive it.

The floor here refuses with:

REQUIRED-FLOOR REFUSAL cause=PureProducerShareProducerModuleOutsideSubject
  producer=test.claim.live_deploy.emit.witness_apply_script
  "the rostered producer's module is not in the prepared subject;
   delete the stale roster row or restore its consumers"
nested: EntryModuleOutsidePreparedSubject module=test.claim.live_deploy.emit

claims_failed=0 and no required-floor: planned= line — no claim was executed, so no claim failed. This PR does not touch live_deploy.

Why it is a trunk condition

The row was added to src/v2/workflow/floor_pure_producer_share.dag by #11204 (1d5c804fe6, 2026-09-15 18:54). Since then the same refusal appears on at least four unrelated branches — session/eager-gull-33, session/proud-wren-877, session/calm-bat-65, fix/realize-component-residual — with zero hits on earlier runs of those same branches. main's own floor is green, because a push subject contains the module so the rostered producer warms; a pull request's subject is derived from its touched closure and may not reach it.

Two explanations that look right and are not:

• Branch skew ("the branch predates the row"). Falsified: Sizing becomes derived: unbundle NodeSizing, delete authored intricacy and volume, stub the deriver #10994's merge-base is 1d5c804fe6, so it has the row and still refuses. Merging main into Model repository_dispatch: public main push fires gunbc-private witnesses #11389 also did not clear it.
• Something this PR did. None of the affected PRs touch live_deploy.

And it is not deterministic per PR: #11362 completed a full floor (3,955 claims, claims_failed=0) at 20:30 with the row already on main, then refused on a later head whose only change was a unit-carrier edit. Whether a given head's subject happens to reach the module decides the verdict.

Do not "fix" it here

The refusal offers "delete the stale roster row". Taking that arm inside an unrelated PR absorbs someone else's defect while hiding it — the same move as writing admission rows to silence a phase. It would also erase the clearest evidence that the row needs scoping.

Escalated to the operator; the remedy belongs with #11204.

— sent from bright-eagle-728

[gunbai-bot]

Closing: the dispatch this PR builds will not be provisioned

Operator decision — GUNBC_PRIVATE_REPOSITORY_DISPATCH_TOKEN will not be provisioned; the cross-repo dispatch is not worth the setup. That makes this PR unlandable rather than blocked, so it is being closed rather than parked.

Why it cannot land as-is. The whole point of the change is that a failed dispatch refuses loudly — continue_on_error is removed so the step cannot swallow a failure (DESIGN §5: a toggle whose only effect is "proceed as if the refusal had not fired" is an escape hatch). Without the token the dispatch fails on every push to main, and the step sits in required-witnesses-build, so a required check would go red on every main push indefinitely, for a missing secret rather than a defect — blocking every lane in the repo.

Re-adding continue_on_error would make it landable and would restore exactly the escape hatch this PR exists to remove. That is not a trade worth making for a feature nobody wants running.

State at close, so nothing here reads as abandoned mid-problem:

• 2 approving providers, no open REQUEST_CHANGES.
• required-witnesses-build, heal-generated-artifacts green; parse clean at 5,918 files.
• The floor executed 3,967 claims with claims_failed=0 after Floor share roster: scope admission to the prepared subject; a stale row is one absent from the corpus #11455 scoped roster admission — the modelling itself is sound and proven on the real path.
• Every review finding fixed: the REST shape routed through github.Commits.ListAssociatedPulls / github.RepositoryDispatch.Create instead of hand-built curl; the unreachable refusal arm removed by construction (target is the authority, effect derived); the decoration witness that cited it deleted; commits_auth_env and repository_dispatch_auth_env each given one home; gunbc_private_repository consumed rather than reminted; the RepositoryDispatch trigger declared as a frontier with its trigger stated.
• One finding deliberately left open and now moot: a GCP Secret Manager row used as the authority for a GitHub Actions secret name. It only mattered if the token were provisioned in one store or both.
• One blocker that was genuinely this PR's own cost: build_lane_hosts_the_private_dispatch_step at 108,904 eval steps against the 72,300 new-witness budget. Unresolved, and now moot.

The work is preserved in the branch history if the private-witness dispatch is ever wanted. Reopening would need the token decision revisited first.

— sent from bright-eagle-728