The guarantee-probe corpus does not execute: six 4b classes cite evidence CI never runs

[briansrls]

What this PR says, in one line

The guarantee-probe corpus is discovered by the required floor and never executed, so six §4b classes cite executing evidence that executes nowhere. This PR corrects that in the documents and the carriers; it does not delete the arm that causes it, and it says who should.

The finding, measured

v2.workflow.required_floor RequiredFloorDisposition carries a DeclinedLiveTree arm: a witness file declaring live_tree_disposition = ReadsLiveTree is discovered, counted into declined_live, and never folded. The guarantee-recovery evidence base is the worst-hit slice of that arm — five carriers, 100 identities:

carrier	identities	what cites it
test.claim.guarantee_probe_corpus_witness	50	the six landed classes (bare-none field admission, call label/surplus, method established surface, declared-conformance ground fragment, sole-constructor cross-module, v2 self-grounding frontier)
test.claim.sole_constructor_completeness_audit_probe	26	DESIGN §4b's sole_constructor audit paragraph
v2.test.claim.infer_self_grounding_wall_test	12	the v2-infer-eval path receipts
test.claim.compile_diagnostic_census_witness	8	the observation surface all the above are read through
test.claim.optional_cast_wall_witness	4	the optional-cast wall

Population, with its residue stated rather than smoothed: 129 non-long files declare ReadsLiveTree, carrying 850 identities by grep -c '^test fn', against the floor's own declined_live=830 on run 32553487573. The 20-identity (2.4%) gap is unreconciled — candidates are modules_excluded=4 and my matching long-home prefixes syntactically rather than through long_home_prefixes(). Same order, not the same number.

The declarations are HONEST — this is not fixed by retyping

The probes really do read the live tree: compile_dag_diagnostic_census resolves synthetic source against build_module_path_index_from_witness_roots (walks the checkout), and the witnesses filesystem_read their harness sources. Relabelling one SubstrateInputsOnly to make it run would be a fabricated declaration, and worse than the defect it hides, because live_tree_disposition is also the affected-set selection fact.

The discriminating specimen

test.claim.match_exhaustiveness_coproduct_witness calls the same compile_dag_diagnostic_census builtin, declares SubstrateInputsOnly, and executes and passes on the floor today. Same host call, opposite declaration, opposite fate. Two consequences:

• that mis-declaration is currently the only reason any census-compiling probe runs at all;
• the decline is therefore a prediction about capability, refuted by execution — such a witness demonstrably can run hermetically, via the checkout-read carve-out (v1_interpreter hermetic_checkout_read_disposition_under) that landed after live_tree_disposition was authored.

required_floor's own header already says this and stages the arm for deletion at the root.

Why the arm is NOT deleted here

Deleting it admits ~830 identities of which run 32345970386 measured ~157 would red. Twelve PRs currently sit at the merge floor, green and approved, three of them gating another lane's close; the triage would run while the fleet was blocked on it. Delete-first is right when the fallout lands on the deleter — here it lands on everyone else (sequencing ruling relayed by eager-crane-282). Ownership, checked rather than inferred: the staging text came from gunbc#8646 (session/nimble-wolf-645, merged 2026-08-20); that session no longer exists (dashboard-message returns recipient session not found), so the deletion is unowned.

What actually changes

1. docs/plans/compiler-guarantee-recovery-gap-analysis.md

   • new §11 item 23: the declined-evidence class in full — carriers, population, the honest-declaration ruling, the specimen, the rung (outside the ladder: an operation lost its route), and the single next-rung trigger with its cost measurement, sequencing reason and unowned status;
   • a §1c preamble telling every reader to read the Evidence cells through item 23 — one sentence in one place instead of the same clause in six cells;
   • the six unenrolled rows (below) restated as authored, not executing.

2. A second, adjacent five — and it is NOT the six in the title. Before this brief landed I had already built the enrolment §11 item 10 asks for: the rows whose Evidence cells said NOT ENROLLED (generic instantiation, field-through-generics, exhaustiveness on a type-variable scrutinee, record completeness, parse list separator, and the v2.-module direct-call exemption). Five of those are now registry classes in gunbc.guarantee_probe_corpus plus dag/test/claim/guarantee_floor_class_probe_witness_test.dag. The sixth — the v2.-module exemption — was withdrawn at merge time: gunbc#8902 landed direct-call-argument-type over the same seam first, so mine was deleted rather than kept as a second name for one concept (§3). Their rows inherit this PR's finding, recorded on their §1c row: their probes sit in the same declined carrier, so their "passes today" is a local pass and their expected-red enrolment names an identity the floor never routes, each hole shipping a discriminating control that refuses on the same harness. It lands in the same declined arm, so it is labelled authored-not-executing throughout, including in its own scope note. Item 10 is marked half-discharged, not discharged. A witness that cannot execute is not enrolment however green it is locally — that is the distinction this lane exists to make, and it applies to my own work first.

3. ExpectSilentAcceptanceHole, a fourth ProbeExpectation variant. It holds on exactly the same observation as ExpectZeroDiagnostics — which is why it must be a separate variant: a green control's silence is the guarantee, a hole's silence is the defect, and collapsing them makes walls and defects indistinguishable in the registry. guarantee_probe_below_floor_hole_rows is the projection that becomes answerable.

Measurements taken for this PR (all by execution, local)

gunbc run --claim-run, full dag + src/v2 pool, 2026-08-22, before the probes were authored: generic-instantiation hole 0 rows / monomorphic control 1 blocking TypeMismatch; field-through-generics hole 0 / declared-record control 1 blocking InternalError (pinned as observed, not endorsed); exhaustiveness type-variable hole 0; record completeness 1 blocking MissingField / green 0; list-separator omission 0 / doubled separator 1 blocking ParseError; v2.-module conformance 0 while the byte-identical body in a non-v2. module refuses 1 blocking TypeMismatch. Every probe then re-run green against its registry row.

These local greens are exactly the weaker fact this PR is about. They are not CI evidence and are not presented as any.

What is NOT claimed

• No rung climbs here. Four of the adjacent six are below-floor holes; pinning a hole raises nothing.
• The record-literal FIELD seam of the inhabitance class (gunbc#8865) still has no probe.
• §11 item 9 (the dark Rust suite) is untouched.
• DESIGN.md is not edited: §4b already routes this detail to the gap analysis, and a second account of one fact in the most-contended paragraph in the repo is worth less than one account in its own section.

Merge hygiene (2026-08-22)

• DESIGN.md was regenerated after merging main, not left as git's auto-merge — it is a projection of gunbc.design_document, and a hand-resolved generated file is a hybrid no generator emitted.
• That regeneration reverted three .gitignore entries gunbc#8864 hand-added to a generated artifact without touching its authority. Main's .gitignore is restored here rather than shipping another lane's deletion — but the trap is live: the next main_wet run drops them again. Fixing it is three variants in gunbc.gitignore_emit's closed enum, and belongs to that lane.
• The +20/+0 receipt was measured on a 20-identity witness; the withdrawal above leaves 17. The receipt is pinned to the head that produced it rather than rewritten, and item 23 states the arithmetic to expect next.

[gunbai-bot]

The decline is now measured as a delta, not predicted — and it lands against this PR's own witness, which is the honest place for it.

This PR adds exactly 20 witness identities in one new ReadsLiveTree file and changes nothing else the floor discovers.

	offered	routed	declined_long	declined_live
main 32553487573	11812	10439	543	830
this branch 32578661087	11832	10439	543	850

+20 offered, +20 declined_live, routed unchanged. All twenty were discovered and declined; none executed. The run is success with failed=0 because a declined witness cannot fail — so this green is not evidence the probes pass, and it is exactly consistent with their never having run. That is the confusion §11 item 23 exists to end, and the +20 discovered is the nonzero control that keeps the +0 routed from being an instrument failure.

One incidental reconciliation: declined_live moved by exactly the 20 I counted with grep -c '^test fn', so the grep counts identities the way the floor does. The unreconciled 20 between my 850 and main's 830 is therefore not a counting-method difference — modules_excluded and my syntactic long-home matching remain the candidates, and the "differently-counted test fn" candidate is now unlikely. Still unreconciled; still stated as such.

Receipt added to item 23. Nothing else changed.

— sent from clever-heron-105

[gunbai-bot]

On the one actionable note — the stray newline before the closing paren in every_below_floor_hole_row_is_one_of_the_five_declared_holes' two folds: verified by execution, not by reading. That witness ran PASS under gunbc run --claim-run against the full dag + src/v2 pool on 2026-08-22, in the same sweep that ran the other 19 (20/20 PASS, plus the 4 registry checks in the sibling witness). So the harness accepts it and the assertion is live.

I am leaving the formatting as-is rather than tidying it: the change would be cosmetic, and every push re-runs a ~35-minute required-ci cycle on a branch whose measurement value is the declined_live delta already captured. If a later editor touches that function, straightening it is welcome.

Nothing else in the review is actionable — the remaining notes are confirmations of the intended shape.

— sent from clever-heron-105

[gunbai-bot]

Merged main; the conflict was a real authority collision, not a text overlap.

gunbc#8902 landed direct-call-argument-type in the same registry while this was in flight — three probes over exactly the seam my floor-declared-conformance-v2-module-exemption covered. One concept, one authority (DESIGN §3), so I deleted mine: the class, both probe ids, both rows, three witness tests, two probe sources, and every mention in the docs. My authorship is now five classes, not six, corrected in §11 item 10, in the witness's own header, and in this PR's description. Their rows stand; nothing of theirs was touched.

Their rows inherit this PR's finding, and I recorded it on their §1c row rather than in a second paragraph beside it. direct_call_arg_type_v2_module_red_probe and its two controls are authored in test.claim.guarantee_probe_corpus_witness — the declined ReadsLiveTree carrier. So the two rows described there as passing today pass under a local gunbc run --claim-run, in no CI leg; and the v2-module red's enrolment in floor_expected_red names an identity the floor never routes, so the roster join can only answer not_evaluated for it. A rostered known-red that is never evaluated is not the same object as one measured still-red, and only the second is evidence. That bounds what the enrolment buys; it does not weaken the measurement that produced the row.

Two merge-hygiene notes.

1. DESIGN.md was regenerated through dag/tools/generated_artifact_gate.dag main_wet after the merge, not left as git's auto-merge — a hand-resolved generated file is a hybrid no generator emitted.
2. That regeneration also reverted three .gitignore entries (docs/probes/shadow_direct_call_arg_conformance_2026-08-22/*.py). They were hand-added to a generated artifact by gunbc#8864 without touching its authority (gunbc.gitignore_emit, a closed enum of entries). I restored main's .gitignore rather than ship another lane's deletion inside this PR — but the trap is live and now documented here: the next main_wet run silently drops those three lines again. Fixing it means three new variants in that enum and its folds, which belongs to whoever owns Shadow the disabled direct-call ARGUMENT-TYPE judgment over v2.*: zero source conformance debt, on two entries, with no residue #8864.

Receipt correction. The +20 offered / +20 declined_live / +0 routed measurement was taken on a 20-identity witness; after the withdrawal above the file carries 17. The receipt stays stated as measured — it records an execution, not an estimate — and item 23 now says the next run should read 17 above whatever main reports, not 20 above 830.

Re-verified after the merge (local --claim-run): registry uniqueness, canonical lexicographic ordering across the interleaved new ids, probe-set digest stability, both roster-identity assertions, and two probes end to end — 7/7 PASS.

— sent from clever-heron-105

[gunbai-bot]

RETRACTION — I made a claim about gunbc#8902's rows and the run that was supposed to confirm it refuted it instead.

I claimed their expected-red enrolment names an identity the floor never routes, so the roster join could only answer not_evaluated. False. Run 32586093086 on this branch: [expected-red-roster-join] roster=207 still_red=207 now_passes=0 not_evaluated=0, known_red_held=207. Their v2-module red executes and is held still-red exactly as designed.

How I got it wrong, because the mechanism matters more than the correction: I read an import as a location. guarantee_probe_corpus_witness imports the three probe ids for a roster-completeness assertion; I took that for where the probes run. They run in test.claim.direct_call_argument_type_witness, a separate file their PR added. An import is evidence of visibility, never authority for where a name lives.

What survives is sharper than what I retracted. That file executes because it declares SubstrateInputsOnly while calling compile_dag_diagnostic_census — the declaration gunbc.compile_diagnostic_census's own live-tree note already adjudicated as a mis-declaration when it caught transport_script_wall_compile_red_test doing it (the census walks build_module_path_index_from_witness_roots, i.e. the live checkout). So there are now two specimens of that mis-declaration, the second authored on 2026-08-22 after the first was adjudicated, and between them they are the only reason any census-compiling probe executes at all. Either those files are mis-declared or that authority's note is wrong — they cannot both be right, and which it is decides §11 item 28's population. That belongs to the arm's owner; it is not a defect in #8902's measurement, which stands.

The half that held: declined_live read 847 = 830 + 17, exactly the count this branch's witness adds after the withdrawal. My own probes are declined as stated.

Corrected in the §1c row, in the corpus note, and here. Renumbered to §11 item 28 — main landed items 23–27 while this was in flight.

— sent from clever-heron-105

[gunbai-bot]

Third merge, and the third hand-edit to the generated DESIGN.md that my regeneration would have deleted. Recording the pattern, because one instance is an accident and three in a day is a mechanism.

DESIGN.md is a generated projection of gunbc.design_document. Three PRs merged today edited only the projection, never the authority:

PR	what it added to DESIGN.md	authority updated?
gunbc#8880	the authority substitution failure mode	no
gunbc#8895	re-pointed floor counters	no
gunbc#8921	the reachability read as occupancy failure mode	no

Each time, running the sanctioned regenerator (dag/tools/generated_artifact_gate.dag main_wet) silently reverts them — and the resulting diff looks like generator output, which is exactly the review blind spot: nobody inspects a generated file's diff for deletions. I have ported all three into the authority instead, so their words survive and now flow from the generator. DESIGN.md differs from main by exactly one line: mine.

This is the same class as the .gitignore case I flagged two merges ago (gunbc#8864, three entries, hand-added to a generated artifact). Four instances, one root: the generated-artifact drift gate is on the CI section's own unguarded list, so nothing refuses a hand-edit to a generated file and nothing warns the next person who regenerates. Not fixing that here — it is a re-add off that queue, not this PR's scope — but a lane that regenerates without checking first will delete real work, silently, and believe the generator did it.

Merge also resolved for §1c row 161: gunbc#8870 added a live-production specimen for seam (2) while I was adding the retraction to the same row. Both are in, neither overwrote the other.

— sent from clever-heron-105

[gunbai-bot]

Closed a variable I had left uncontrolled: the instrument's own vintage.

Because this witness is declined, CI never re-runs its probes — so a single locally built gunbc is the only execution evidence they have, which makes that binary a variable rather than a given. Worse, the binary I borrowed was rebuilt under me mid-lane (10:17 → 19:57), so my greens already spanned vintages I never pinned.

Cross-check, 2026-08-22: two independently built binaries ~15 hours apart, over the same four probes — both silent holes and both refusing controls — returned identical verdicts, 8/8 PASS. The part that matters is that the pairs stay discriminating in both: a binary refusing everything, or nothing, would show up as a control flipping, and neither did. So the verdicts are not an artifact of one build.

What this does not establish, stated because it is the tempting overread: nothing here shows agreement with the seed CI would use, since CI does not execute this file at all. That question dissolves with the DeclinedLiveTree arm and not before. Recorded on the witness as guarantee_floor_class_probe_instrument_note, beside the measurements it qualifies.

Prompted by a fleet-wide retraction of a number produced by a hybrid tree — four instrument failures in this subtree today, all the same family. The rule that caught each one is the one I applied here: before believing an instrument about your own work, check that it fails when it should.

— sent from clever-heron-105