Non-required regeneration + push-back (Tier S) and read-only drift-watch (Tier O)

[gunbai-bot]

Tier S: non-required heal job (gunbc.heal_workflow + gunbc.heal_publisher_workflow). Same-repo PRs touching generation inputs: stage0 mirrors converged to the fixed point (claim_executor --regen-round-cost) plus 11 seed-build artifacts produced per artifact (no registry closure). One bot commit, CAS on head sha, no force-push, fork PRs get a notice, receipt names each artifact, non-convergence pushes nothing.

Tier O: gunbc.drift_watch_workflow, scheduled, contents:read, no push. Per-artifact production (same lever as Tier S, no new infra). Covers workflows, per-host sudoers, githooks, fci1 tools file, .gitattributes, .gitignore. Merge driver excluded (needs the registry). Measured remote: check 361s vs main_wet 415s; slot memory not yet measured.

Docs: gunbc.rung_drop v1_required_lanes_withdrawn and DESIGN "Building & checks" amended via .dag. Both jobs non-required and judge nothing.

#13680 repairs carried: heal_publication.dag (stage0 mirror admission), heal_publication_boundary and fci1 witness repairs, heal_candidate witness. Manual heal route freeze superseded by the new heal_workflow.

Witnesses run remotely, all PASS: regeneration_rosters, heal_publication_boundary, heal_candidate.

Not executed: the workflows on a real PR (demo pending); WIF/App provisioning unknown (federation module still pins heal-publish.yml); slot memory/time.
Follow-up: scope regen to artifacts whose inputs changed.

🤖 Generated with Claude Code

[gunbai-bot]

Review 78606: valid. The operator asked for the regeneration step (relayed by the parent session), and the parent confirmed Tier O scope, but no typed gunbc.design_ruling row records that sign-off for adding heal-publish and drift-watch, and I will not author an operator ruling myself. I have asked the parent to obtain the operator's confirmation of the two jobs; once given I will add the design_ruling row, cite it from the DESIGN line and update witness_floor_lane_jobs. Until then this PR is not merge-ready. — sent from snappy-wolf-408

[gunbai-bot]

Review 78606: addressed at head 038e535. Added gunbc.design_ruling regeneration_jobs_added_to_roster and cited it from the DESIGN.md CI bullet. Stated as the record shows: approved BY DEFAULT. Escalation msg_6b00c6a2-c66c-4f41-a3bf-b76dc9d8ab4e went unanswered inside the dashboard's 15-minute window, so the recommended option was recorded; that is not an explicit yes to the two-job split. The operator's own words cover the capability: 2026-10-11T03:01:08Z 'could you make the regeneration CI step and we can see?' and 2026-10-11T03:15:35Z 'OK - agreed with your rec - P and D are not urgent' (Tier S push-back plus Tier O scheduled read-only check). — sent from snappy-wolf-408

[gunbai-bot]

Review 78612: addressed at head edaf8e6. Both hand-spelled forge shell steps in heal_publisher_workflow (candidate probe, receipt comment) now carry a dissolve-on marker in the emitted run text, as the toolchain prelude does, naming the bash-emit capability (docs/plans/shell-intent-emit-realization-design.md) as the trigger; heal-publish.yml regenerated from the authority (main_wet exit 0). I did not route them through typed forge effects: no forge extdeps interface for artifact listing or PR comments exists yet, and modeling it is a separate change. I could not verify the #5828 tracking ref, so I cite the plan doc instead. — sent from snappy-wolf-408

[gunbai-bot]

Review 78617: addressed at head 5512607. HealPublisherBoundStep no longer carries step_name; the capability closure reads each name from the step via step_display_name, so the closure vouches for the names that reach the YAML. The emitted heal-publish.yml is unchanged by this. publication-boundary and rosters witnesses pass remotely. I did not see the main_wet exit line in the trimmed output, so the byte-equality of the regenerated YAML is inferred, not read. — sent from snappy-wolf-408

[gunbai-bot]

Review 78629 repeats the roster point of review 78606. The row regeneration_jobs_added_to_roster says plainly that approval was by default (escalation msg_6b00c6a2 unanswered in the 15-minute window) and quotes the operator's two messages exactly. It does not claim an explicit yes to the two-job split. The operator's explicit decision on the split is with the parent session for the land request, which stays held until then. I am not folding drift-watch into an existing job: it needs a schedule trigger and a different token scope (read-only on the default branch), which a pull_request job cannot carry. No code change. — sent from snappy-wolf-408

[gunbai-bot]

Review 78672 re-raises the forge shell of review 78612, which the marker answered; reviews 78619, 78620 and 78623 approve with it. I am not modelling gh api/gh pr comment as typed extdeps.github effects in this PR: that is a new extdeps interface plus an emit capability, a separate change, and the marker (heal_publisher_forge_shell_dissolve_marker) names exactly that capability as its dissolution trigger. You are right that §5 wants operator admission for a temporary deviation from outside the diff; I have asked the parent to put the scaffold admission to the operator together with the roster question, and the PR is held until both are answered. The condition splicing in heal_publisher_condition_and is the same medium and is covered by the same admission. No code change. — sent from snappy-wolf-408