Seed-honesty verdict + acceptance receipt; sweep the stale gunbc_ci_floor_batches citations

[briansrls]

Summary

Records the operator's seed-honesty verdict, greens the closing validation that was deliberately red without it, and files the acceptance receipt for v1-seed-honesty-decision.

The node's handback was two things — a check that can fail, plus the decision recorded either way. Only the first half existed. The decision procedure (seed_self_verify_check) landed earlier and is genuinely discriminating: a reflexive claim/check refuses with bootstrap_self_verify_same_artifact, a planted divergence with bootstrap_self_verify_diverged, mismatched provenance with bootstrap_self_verify_provenance_mismatch, and a distinct equal-content pair with equal provenance admits, so none of the three refusals is a blanket red. But seed_honesty_decision was SeedHonestyUndecided, so the aggregate stayed red and was enrolled QuarantineProbeExpectRed rather than reported done over the missing half.

The verdict is FixedPointTrustSufficient, and the name undersells its conditions. It does not say a fixed point is trustworthy. It says v1 deletion does not require an independently implemented second compiler, and requires instead an explicit generation-admission pipeline — each stage executes against a declared requirement revision and binds its exact inputs, outputs, producer and verdict; a candidate generation may be produced and inspected but cannot promote itself; promotion requires declared requirement changes, complete stage and behavioral receipts, no undeclared v1 fallback, and a retained known-good recovery path; breaking requirement changes require an expand-migrate-contract bridge; and the previous generation stays available until the promoted compiler produces a valid changed successor rather than merely reproducing itself. That program is designed in docs/plans/emission-admission-stage-aware-pipeline-design.md — the corrected revision, which confers no promotion or merge authority of its own — and is unbuilt. This receipt accepts the decision, not the pipeline the decision requires.

What the verdict explicitly does not protect

Carried on the rationale itself so a later reader cannot infer safety from the node being green:

• A fixed point does not defeat a self-reproducing defect. stage1 == stage2 is exactly what such a defect also produces. That residual is accepted, not ruled out.
• seed_self_verify_check is not the live trust-path authority. The realized-comparison and regen paths do not route their artifact identities through it. This change does not wire that path.
• Rollback is not fix-forward. Committed emitted Rust gives rollback to any earlier generation; it does not give fix-forward once a requirement revision has changed what the previous generation can read.

An earlier draft of the rationale argued DDC was unnecessary because the seed's source is readable. That argument is wrong and is corrected here: the classic attack is a binary miscompiling readable source, so readability is not the defense. The narrower claim that survives is a mitigation, not a proof — the emitted Rust is committed as plain text and re-compared by the regen gate, so a perpetuated defect must appear in a readable diff and survive review of it.

The expect-red probe was flipped, not deleted

seed_honesty_undecided_keeps_closing_contract_red read the live decision constant, so the verdict landing left it able to assert only a state that no longer exists — it had to go red or be deleted, and DESIGN §4b(4) forbids deleting the evidence along with the machinery.

The conjunction is now a function of the decision, seed_honesty_closing_contract_over, applied to the live constant by the contract and to SeedHonestyUndecided by the permanent control seed_honesty_undecided_would_keep_closing_contract_red. That control is what keeps the fifth conjunct load-bearing: weaken the decision arm so an undecided value satisfies the contract and the contract stays green while only the control reds.

Handback

• src/v2/workflow/bootstrap.dag — the recorded verdict.
• src/v2/test/claim/execution/seed_honesty_discharge_unavailable_test.dag — contract parameterized over the decision; expect-red probe flipped to a permanent control.
• dag/gunbc/ci_layer_roots.dag — QuarantineProbeExpectRed enrollment and witness exclusion deleted (the climb dissolves the quarantine).
• dag/gunbc/roadmap_authority.dag — the acceptance receipt, plus the stale half of v1_seed_honesty_decision_contract_note corrected.

Test plan

Naming the executor, because there are at least three and they are not interchangeable. gunbc run, claim_batch, and claim_executor are separate binaries with separate entry points, and only claim_executor gates a merge. A local green names which one produced it or it is not a receipt.

Green by execution under claim_batch on this tree, binary rebuilt at this head — all three PASS:

• v1_seed_honesty_decision_closing_contract_holds — the bound closing validation.
• seed_honesty_undecided_would_keep_closing_contract_red — the permanent control.
• seed_honesty_check_four_poles_hold_before_decision — the four refusal/admission poles, unchanged.

The witnesses are moved into a home CI actually scans, and that correction is the substance of review 47620. My first cut deleted the seed-honesty QuarantineProbeExpectRed enrollment and claimed this PR's own CI run would therefore be the claim_executor verification. That was false. The file sat in src/v2/test/claim/execution/, which (a) carries a directory-grain OfflineLocalRecipe exclusion whose stated reason is the emit-vs-eval execution corpus, and (b) is not in witness_discovery_scan_dirs at all. So removing the enrollment removed the only thing scheduling the file, leaving both the closing contract and the permanent §4b(4) control executing nowhere on the merge-gating path — specification-without-execution for the very regression wall this PR says it is keeping.

These witnesses are hermetic (constructed DiverseCompilationRun fixtures, no host read), so they never belonged in an emit-vs-eval execution home. They now live in dag/test/claim/.

Correction to this PR's own earlier justification, made after reading the executor rather than the roster names. An earlier revision claimed the move worked by gaining positive membership in witness_discovery_scan_dirs. That was wrong. claim_executor's invoke_floor_discovery_producer_over_corpus uses scan_dirs for exactly one thing — the discover_owned_data_decls loop — and hands the witness producer discover_floor_corpus_rows_from_host_facts only source_roots and exclude_substrings. Witness discovery is a source-root walk for *_test.dag minus exclusions; witness_discovery_scan_dirs is the owned-data-decl scope, not the witness scope. The old location was already reachable by the walk. What excluded it was the exclusion substring test/claim/execution/, which the walk does honor — so the operative repair is leaving an excluded path, and the scan-dir half of the earlier justification named a mechanism that does not govern witnesses at all. The fix is unchanged and still correct; only the reason is.

Green by execution under claim_batch from the new location, all three PASS.

The criteria digest 1717cfe258d9afe1 was derived by execution (node_criteria_digest against the live node), not transcribed. The probe carried its own control: it reproduced f1c76111c83a0a60 for v2-emitter-producer-provenance, byte-matching the receipt an unrelated change had already stored for that node, and returned three distinct values for three nodes — so it computes the criteria rather than answering with a constant.

---

Also in this PR: the gunbc_ci_floor_batches citation sweep

Bundled rather than split, per the operator's standing preference on PR boundaries. Named here so it is not smuggled.

gunbc_ci_floor_batches was renamed to gunbc_ci_floor_plan. One note recorded the rename; the references were never swept. Found by execution — running DESIGN's own documented CI command refuses with no such function: gunbc_ci_floor_batches.

Repaired:

• DESIGN.md + gunbc.design_document — the documented claim_executor command did not run. ci.yml passes gunbc_ci_floor_plan.
• gunbc.doc_graph_roots, two typed DeclarationRef rows — the sharpest instances: structured citations, in the carrier built to hold machine-checkable references, resolving to nothing, with no gate reporting it.
• gunbc.ci_spec clamp note and gunbc.roster_registry — live index-alignment and membership claims. Not substituted blindly: the clamp rows align to the batch list gunbc_ci_floor_ordinary_batches, not to the plan function, per witness_scoped_batch_is_singleton_and_outside_positional_clamps. Substituting the plan function would have replaced one false citation with another.

Deliberately unchanged: gunbc_ci_floor_batch_wall_budget_note, which reads "named gunbc_ci_floor_batches through the static era this note records" — a correctly framed historical mention, and the only place the rename was recorded.

DESIGN.md is generated. The documented regen (generated_artifact_gate main_wet) refuses locally at stage0_emission_source_identities_host, and that refusal reproduces on pristine origin/main, so it is not introduced here. The DESIGN.md edit is the character-identical substitution the generator would produce from the corrected carrier, verified against the carrier literal; the drift gate is the independent check on that claim, and CI's auto-heal is the corrective if I got it wrong.

This is the class DESIGN §3 predicts and has not yet walled.

Corrected — an earlier revision of this body claimed feature:cited-symbol-resolution "would have caught all seven." It would have caught two. crisp-owl-732 re-derived the gate's population by execution against witness_layer_roots (2026-08-03) rather than inheriting my list, and the result is narrower than my claim: the G1 gate reads the typed HandAuthoredDocBind carrier — primary_work plus additional_works — not a corpus text scan and not prose. Its unresolvable population on the pre-repair tree is 2, both DeclarationRefDeclarationAbsent on v2.workflow.ci_floor_plan / gunbc_ci_floor_batches (slugs witness-realization-plan and progress-observation-design). Zero module-absent, zero field-absent, zero ambiguous.

The other five repairs in this PR — DESIGN.md, gunbc.design_document, gunbc.ci_spec, gunbc.roster_registry, and the seed-honesty test path — are prose and plan-function citations that sit outside the typed carrier the gate reads, so no gate in flight covers them. That is worth stating plainly rather than letting the stronger sentence stand: a structural gate over typed DeclarationRef rows is not a wall against stale citations generally, and five of the seven defects repaired here would still be writable after G1 lands. Closing that remainder is the open half of feature:cited-symbol-resolution, not something this PR or G1 finishes.

---

Main integrated (merge commit 5618739fe9) — and why the earlier red was not this PR's

The run at 3502b1a failed, and the failure was inherited, not introduced. The job log names it exactly: 1 of 6420 discovery witness(es) failed: cross_module_same_leaf_emits_qualifier_module_not_registry_winner (dag/test/claim/qualified_leaf_registry_collision_emit_witness_test.dag). That file is not in this PR's diff. It is the bare discriminating RED that #7705 landed on main, which redded main itself and every open PR built on it — #7704 and #7710 failed on the identical single witness, 1-of-6411.

I verified this rather than inferring it from the coincidence, because I made exactly that mistake earlier today and mis-attributed a failure to an unrelated PR.

#7711 merged the quarantine, so main is repaired at bd3968ad1d. origin/main is merged in here.

The conflict was in dag/gunbc/ci_layer_roots.dag, and it is the one place a careless resolution would have done real damage. Both sides edit the quarantine roster: this branch deletes the seed-honesty QuarantineProbeExpectRed row and its paired probe_red entry (that deletion is the §4b(4) climb this PR exists to make), while main adds two new pairs — qualified_leaf_registry_collision_emit_witness_test.dag (#7711) and v2_emitter_direct_rust_door_acceptance_test.dag (#7680). Taking either side wholesale would have either resurrected the quarantine this PR dissolves or dropped a quarantine main depends on to stay green.

Resolution checked structurally, not by eye: the resulting exclusion-pattern set and probe_red entry set differ from origin/main by exactly one element each — seed_honesty_discharge_unavailable_test.dag — which is precisely this PR's intent and nothing else. Pairing was re-verified: every QuarantineProbeExpectRed row still has its matching probe_red entry, and the six rows that do not are the unchanged pre-existing main baseline, identical before and after.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[gunbai-bot]

Fixed in c539f41. Review 47620 was correct and this was a real defect in my own change, not a scoping disagreement.

The finding, restated so the record is unambiguous: deleting the seed-honesty QuarantineProbeExpectRed enrollment removed the only thing scheduling that file. It lived in src/v2/test/claim/execution/, which carries a DIRECTORY-grain OfflineLocalRecipe exclusion (stated reason: the emit-vs-eval execution corpus home) and is not listed in witness_discovery_scan_dirs at all. So both the closing contract and the permanent DESIGN 4b(4) control were left executing nowhere on the merge-gating path. Worse, the PR body asserted the opposite -- that this run would be the claim_executor verification. It would not have been.

The fix is the move, not an enrollment exception. These witnesses are hermetic (constructed DiverseCompilationRun fixtures, no host read anywhere), so they never belonged in an emit-vs-eval execution home; they were there incidentally. They now live in dag/test/claim/. Adding an explicit witness_entries row instead would have layered a second exception on top of a wrong classification.

Verified on BOTH halves rather than one, which is the part I want on the record: dag/test/claim IS a discovery scan dir (positive membership), and NO exclusion pattern in ci_layer_roots matches the new path. Checking only the exclusion roster is precisely how a sibling lane produced a false zero the same day -- absence of exclusion is not presence of scheduling.

Green by execution under claim_batch from the new location: v1_seed_honesty_decision_closing_contract_holds, seed_honesty_undecided_would_keep_closing_contract_red, and seed_honesty_check_four_poles_hold_before_decision all PASS. Naming the executor deliberately -- claim_batch, claim_executor and gunbc run are three separate binaries and only claim_executor gates a merge.

The acceptance receipt witness_module and both handback/entry paths are repointed, and the file note and PR body now record what was wrong rather than quietly reading correct.

— sent from still-bat-561