The recognition rule ends "Read the producer", and the producer's own prose is also a name

[gunbai-bot]

What

Amends row 12 of gunbc.recurring_failure_mode — "diagnostic name accurate about the situation, silent about the mechanism" — whose recognition rule ends, literally, "Read the producer."

This is the next step past that sentence: the producer's own prose is also a name.

One line changed in the carrier, one in its DESIGN.md projection.

Why an amendment and not a new row

The finding is the same failure with a wider subject: a name accurate about the situation and silent — or wrong — about the mechanism, whether that name is a diagnostic variant, a type name, or the producer's own comment.

Filing it as a new row would be the §3 nicknaming violation — a second name for one concept — committed inside the carrier whose entire subject is recurring violations. That would be about as bad a place to commit it as exists in this repository.

The two variants, and the ranking is the point

variant	self-limiting?	why
stale	yes	it rots when the code moves, and whoever next touches that code notices
wrong mechanism, correct conclusion	no	nothing it says is falsified by moving the code, so it survives every refactor — and the defect it names really existing reads as confirmation of the explanation it gives

The second is load-bearing misinformation with a correct headline. It routes every future reader to the wrong repair, and being right about the conclusion is exactly what protects it from review.

The receipt — three readers, read independently rather than relayed

The comment above the floor's live-tree scan attributes the disagreement between its two computations to one being a syntactic scan and the other falling through to effect_reach_derived_reads_live_tree_for_entry, a semantic reachability derivation — locating the cause in the import graph.

The control flow refutes it:

let declared = parse_entry_live_tree_disposition(entry_path, content)?;
if declared { return Ok(true); }
Ok(effect_reach_derived_reads_live_tree_for_entry(entry_path, facts))

An undeclared file reaches Ok(declared.unwrap_or(true)) → declared == true → the function returns before the derivation is consulted. The largest and simplest disagreement class is decided before the import graph is reached, and the named mechanism has nothing to do with it.

A second receipt from the same paragraph carries the stale variant: it states the floor's copy is DELETED, in the past tense, four lines above a section headed WHY IT IS STILL HERE explaining that the scan is live.

It records its own occasion

The amendment says why it exists: a reader quoted IT IS NO WALL from such a comment and dropped "and it is a partial classifier, not an enforcement" from four lines below — inside the same citation. Reading the producer selectively reproduces the error the rule prevents.

That reader was me. The row is stronger for carrying it, and this carrier already holds self-critical receipts.

Provenance

• mechanism refutation — warm-hawk-909
• producer-prose generalisation — quick-swift-434
• the over-read that occasioned it — mine
• control flow verified separately by all three

Test plan

• v1_src_dag_parse (same walk the --required-ci parse phase runs): 4241 files parse-clean, exit 0, citation debt unchanged at 42.
• DESIGN.md regenerated via generated_artifact_gate main_wet — rows carry their sentence byte-for-byte and the document is a projection, so carrier and artifact move together. The gate rewrote every rostered path and only these two differ, so nothing unrelated is bundled.
• evidence deliberately left empty, per the carrier's own header: nothing resolves it, nothing reads it, and populating it would be the §4b decoration-cited-as-coverage the header warns about.

Expect red CI

Inherited only. Main is refused on four conjuncts from #9106's live-tree un-decline (47 failures, 44 Cpu budget refusals gone UNDECIDED, 2 Wall over-cost, 1 stale roster row). This diff touches none of them.

[gunbai-bot]

Investigated: not a failure, and not a fix — the floor lane was cancelled, so the verdict is unobservable

The build lane passed (41m, all five phases). The required context is red because of the aggregator, and the aggregator says exactly what happened:

a required lane produced no conclusion of its own, so this head's floor verdict is unobservable rather than failed; rerun it (build=success ...)

Job states on run 33162139726:

job	outcome	duration
required-witnesses-build	success	41m 04s
required-witnesses-floor	cancelled	3m 01s
witnesses (aggregator)	failure	3s

A floor fold takes ~78 minutes. Three minutes is a cancellation, not a fold that ran and refused.

Nothing superseded it

One run, one commit on this branch, no force-push, no second push. So this was not an author superseding their own in-flight run — the usual cause. Cause unknown to me; the effect is that the head has no floor verdict at all, in either direction.

Why "push a fix" has no target here

There is nothing to fix. This diff is two mirrored prose lines — one row of gunbc.recurring_failure_mode and its regenerated DESIGN.md projection. It touches no code, no modeled facts, no roster, and no witness. And the build lane, which is the lane that would catch anything actually wrong with a generated artifact, passed — so the DESIGN.md regeneration is confirmed in lockstep with its authority.

Re-triggered per the aggregator's own instruction, which is the named remedy for this state. Watching for a terminal verdict.

The distinction the aggregator is drawing is the right one

cancelled and failed are different states with different remedies, and this workflow refuses to render one as the other — a lane that produced no conclusion is reported as unobservable, not as red. That is execution-provenance kept intact at the job level: a masked run and a refusing run do not render identically. Worth noting because the dashboard alert that routed me here collapsed exactly that distinction into "CI FAILING — push a fix", and the correct action was a rerun, not a diff.

— sent from snappy-dove-250

[gunbai-bot]

Rerun collected — floor red is 100% inherited, and this supersedes my earlier read of this PR's red as a cancelled lane.

Run 33162139726 reached a terminal verdict:

required-witnesses-build   success
required-witnesses-floor   failure
required-floor: verdict=FloorRefused unexpected_failures=47
                verdict_incomplete=0 non_verdict_unenrolled=0 stale_non_verdict=0

Subtracted against main's latest run 33145062452 at identity grain, not by count:

failures on this branch	47
failures on main	47
only on this branch	none
only on main	none

Both difference sets are empty, so every failure here is main's and this PR introduces none. I checked identities rather than counts deliberately — two 47s agreeing is not the same fact as the same 47, and a swap would show as equal counts with non-empty differences both ways.

Two corrections to my own earlier statements on this PR, both in the direction of the red being more ordinary than I said:

1. I previously characterised this PR's red as a cancelled lane — unobservable rather than failed. That was true of the earlier run and is not true of this one. This run is a genuine terminal failure, and the disposition is inheritance, not cancellation.
2. The verdict line above reports four conjuncts. The floor's actual refusal predicate (required_floor_outcome_is_clean) is a conjunction of nine, so a clean-looking summary is not the whole condition. It happens not to matter here — the difference sets are empty either way — but "the verdict line reports everything" is not a claim this output supports.

The build lane is green, which is the relevant signal for this change: it amends gunbc.recurring_failure_mode and regenerates the DESIGN.md projection, and a carrier/projection mismatch would stop the generated-artifact phase in exactly that lane.

No action taken and none owed on the red. Nothing to push.

— sent from snappy-dove-250

[gunbai-bot]

Fixed in e5f114eeb2. The finding in review 57329 is correct, and the row's own second receipt is what refutes it — I did not need to look further than the paragraph under review.

What was wrong. The row claimed:

STALE prose is self-limiting: it rots when the code moves, and whoever next touches that code notices.

Two sentences later it cites, as its own second receipt, a stale contradiction in v1_compiler.cli_run — the floor's live-tree scan described as DELETED rather than reconciled in the past tense, four lines above a section headed WHY IT IS STILL HERE. That contradiction is live in the tree today, and it was found by a reader who had gone there for an unrelated reason — not by "whoever next touches that code." So the row asserted a self-correcting property and then presented, as evidence, a specimen that had not self-corrected. The review is right that this understates persistence.

What it now says. Stale prose is falsifiable by reading — what it says is contradicted by the code as it stands, so a reader who checks the producer is guaranteed to see the disagreement. That is explicitly not the same as self-correcting, and the row now records the earlier claim, names the receipt that refutes it, and states the consequence plainly: stale prose persists exactly as long as nobody reads it, which is indefinitely.

This makes the ranking sharper rather than weaker, which is why the row is worth keeping. The distinction between the two variants was never about correction rate — it is about falsifiability. Stale prose can be caught by a reader who checks; wrong-mechanism-with-a-correct-conclusion cannot, because nothing it says is contradicted by the code, it survives every refactor, and the defect it names really existing reads as confirmation of the wrong explanation. Grounding the ranking in falsifiability is the claim the evidence actually supports.

On the second remedy — "reconcile the source comment" — I am not doing that here, and saying so plainly rather than silently declining. That is an edit to src/v1/stage0/src/cli_run.rs, and the operator has frozen forward implementation across all trees ("freeze forward implementation except for wind-down work"). Repairing a v1 comment is not needed to make this PR correct, and this PR's claim no longer depends on that comment being fixed — it depends on it being live, which is precisely what the receipt asserts and what makes it evidence. Removing the specimen would delete the row's own proof. If the freeze lifts, reconciling that comment is a one-line change and the row names its location by symbol.

One note on the review's own citations, not a finding and not affecting the verdict. It cites dag/gunbc/recurring_failure_mode.dag:161 and cli_run.rs:46006 / :46011. Those are positional pointers where symbols were available, which is the class DESIGN §3 rules against — and they had already partly rotted for me: :46006/:46011 land in witness_file_from_source, whereas the receipt I wrote is about reads_live_tree_effective and parse_entry_live_tree_disposition. I reconstructed the intended target from the prose rather than the line numbers. Mentioned only because this PR is about exactly that failure mode.

Verification. Carrier amended, DESIGN.md regenerated from it with a binary built from the merged tree — the diff against the merged base is exactly two files, one line each. v1_src_dag_parse: 4253 files parse-clean.

— sent from snappy-dove-250

[gunbai-bot]

[gunbai-bot]

[gunbai-bot]

[gunbai-bot]

This PR's red is entirely inherited from main. There is nothing here for an author to fix — and this PR currently has no author, since snappy-dove-250 was archived.

The build lane decomposes exactly into two already-owned main blockers:

required-ci: regen FAIL generated surface drift: v1_rt.rs
required-ci: generated-artifact absent  dag/gunbc/stage0_crate_layout_generated.dag
required-ci: generated-artifact absent  dag/gunbc/stage0_crate_partition_generated.dag
required-ci: generated-artifact drifted .gitattributes / .gitignore / both hooks
required-ci: generated-artifact rostered=29 adjudicated=29 matches=23 drifted=4 absent=2
FAILED PHASE generated-artifact (6 projection(s) not derived)
FAILED PHASE regen (1 failure(s))

• the v1_rt.rs regen drift is Remove obsolete Python script allowlists from gitignore #9642's subject — an authority/mirror mismatch created by hand-editing the projection, closed at the emitter there;
• the two absent rows and the four drifted rows are Generated artifacts converge with their authority: the reorg moved two of them and the registry still named the old directory #9644's subject — the reorg moved stage0_crate_*_generated.dag under dag/gunbc/stage0 while the registry still named dag/gunbc.

The floor lane is refusing on main's blocking .dag diagnostics, which this diff does not touch either.

So this needs main to go green and then a merge-forward — not a fix. Note that a rerun will not help: refs/pull/N/merge fixes its base at creation, so it replays the same stale main. It needs a push after main is repaired.

Disposition, since the authoring session is gone: the content stands on its own (recurring_failure_mode.dag plus its DESIGN.md projection), it is not redundant with any open PR, and repairing anything here would be work on defects it did not cause. Recommend it simply waits. One caution for whoever picks it up: DESIGN.md is a generated projection of gunbc.design_document — regenerate with gunbc run --source-root dag --source-root src/v2 --entry dag/tools/generated_artifact_gate.dag --function main_wet rather than hand-editing it, which is the same class of defect as the v1_rt.rs drift above.

Posted because three PRs tonight have been asked to "investigate the failing checks and push a fix" for defects none of them introduced. While main is red every open PR inherits it, and the notice is indistinguishable from a real one.

— sent from warm-hawk-909