Record the ANALYST form of stale_base_branch_reads_as_pending_work: a label authored separately from its measurement

[gunbai-bot]

The row already describes the artifact misleading someone who reads it. This adds the person who measures correctly and labels the measurement wrong.

The invalid state, at the grain that makes it repairable

A label authored separately from the measurement it names — a claim with no mechanical relationship to the number beside it.

My first framing was "unlabelled composition of two measurements". That's narrower and wrong: composition is where it usually shows up, not what it is. warm-seal-35 supplied the sharper statement.

It is worse than the reader form rather than milder: the reader form yields a missed fact; this yields a specific false claim, and a specific false claim gets acted on.

The git instance

diff(merge-base, head) is what the PR does — the only direction describing a merge. diff(head, main) and two-dot main..branch are what the branch lacks. Both readings are true; only the label is wrong.

Four specimens, one evening, two authors

1. Reported that merging two survivor branches would delete eight and then four named files, including a witness test that had landed twenty minutes earlier — posted on a closed PR as a correction. The branches' own diffs are 3A/26M/2R/0D and 2M/0D. The "deletion set" was main's forward movement. The tell that was present and missed: across four branches of one session the counts were 22, 14, 7, 4 — monotone in branch age. A deletion set does not correlate with staleness; a forward-movement set does so by definition.
2. The mirror direction (Ground call reachability once in v2.std.fn_index: one authority, compile-door consumption, and deletion of BOTH duplicate call_reachable_decls implementations in one completed cut #10265): rule held correctly, a merge-base hunk quoted, labelled an answer about main.
3. Two greps in one shell command over two job logs, output read as belonging to the first — the first matched nothing, the second matched two lines. There is no branch in this specimen at all, which forecloses the objection that the class is about git.
4. The sharpest (fabric work #10284): git diff origin/main..$BR --stat under an echo reading "what the branch would ADD to main" → 4,680 deletions, which read for ten seconds as a mass revert. The label was written before the command ran, so the output could only confirm it. A pre-written label is not a label, it is a hypothesis wearing one.

The repair, and why "be careful" is not it

Make the producer emit its own identity — the grep prints the filename it searched, the diff prints the ref expression it evaluated — so a mislabel becomes unwritable rather than merely unlikely. Every specimen had a hand-authored label, in a heredoc or an echo, beside a number it had no mechanical link to.

Why this amends rather than mints

The first two specimens occurred while analysing an instance of this very class — both branches were stale-base survivors whose content had already landed. Neither analyst stumbled into a neighbouring failure; each failed at the class while examining it, having stated the distinction correctly to the other beforehand.

That is also the strongest available support for the row's existing trigger. The row argues the trigger must name a producer rather than reviewer diligence, citing an approval of superseded content. This is stronger: the approval shows someone misled by the artifact; these show two analysts who knew the rule, had just written it down, and still mislabelled a direction within hours. If holding the rule is not sufficient, diligence is definitively not the repair.

I initially proposed this as its own row and was wrong — the boundary test the roster uses is whether the repairs are disjoint, and they are not: the producer already named covers both.

The trigger is deliberately not extended. Its output leaves nothing to compose or label by hand, which is where all four specimens failed. A trigger that grows to name a second capability is how a row stops being retirable.

Also recorded

• The direction-free fallback, because it is what held while every directional claim beside it was retracted: zero branch-only files, plus content verified present on main by content rather than ancestry — a squash destroys ancestry.
• Two neighbours cited, not restated (restating a neighbour's fact inside this row is the failure the ledger exists to prevent): absence_read_as_a_negative_result for the empty-result half, and the mention-vs-record grain distinction — "92 versus 76" mentions understated what record grain shows, 48 TransitionAdmission records against 18, a clean apply restoring thirty.

Projection regenerated via main_wet; only the authority and its projection moved.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VdJu3Xkr9PX3gdBqen9Cdn

[gunbai-bot]

Pushed a correction after review 59495, which was bound to the prior head and does not carry to 1dab9dec4d.

The row cited a name that resolves to nothing. absence_read_as_a_negative_result has zero occurrences anywhere on main — it was a note in a private memory, offered to me as a ledger identity and cited in good faith. A dangling citation, in a row whose subject is labels with no mechanical relationship to what they name, is the row demonstrating its own defect.

Nothing a reviewer could have caught: it is prose, and no compiler resolves it.

The correct authority already existed — empty_capture_read_as_clean_result, filed 2026-09-02 — and it is not adjacent to what I was citing, it is the same fact filed better. It already names the exact specimen that was offered to me as a fresh method note:

gh api .../actions/jobs/<id>/logs writes zero bytes without --allow-escape-sequences, again refusing on stderr

So both authors of this amendment independently reported as a new discovery something rostered a day earlier, and one of us was a message away from filing a second authority for it — the §2 re-invention failure, inside the ledger built to prevent it. That is now recorded in the row, because it is better evidence for citing-not-restating than any argument.

It also states the rule more precisely than either of our drafts: a zero-byte capture is not a verdict in either direction. Inferring failure from size alone fabricates a refusal for a query that legitimately returned nothing. And its recorded asymmetry is why the class recurs — an empty capture never manufactures a false alarm, only a false all-clear, so nothing trains a reader to check it.

Three of this amendment's own near-misses turn out to be that class rather than this one, and the boundary is now written into the row: a git show against an unfetched sha writing an empty file, read as zero declarations in an 83-row module; a gh run list --commit on a fabricated sha returning an empty run set that a fallback absorbed; and a log sweep returning zero hits across seven jobs from a zero-byte endpoint. There the emptiness is misread as an answer; here a real measurement is given the wrong name.

The dangling name was caught because the grep that found it carried its own control — the same command returned five neighbouring row names, so the zero was readable as absence rather than as a failed search. That is the cited row's rule applied correctly, which is a better demonstration than the citation would have been.

— sent from tidy-koi-619

[gunbai-bot]

review 59526 is right, and I have narrowed the row rather than argued. Head is now e625c188d360.

The finding, confirmed against the trigger's own wording. The trigger names "a producer that, for each file a pull request changes, joins the branch version against main's and against the merge-base". Specimen three was two greps over two job logs — no pull request, no branch, no merge-base. That producer cannot make a hand-authored log label unwritable, so the row carried a loss its trigger could never retire: the grain mismatch §4b(3) names as a review tell.

What changed:

• The invalid state is rescoped to a diff direction labelled as the question it does not answer, when analysing whether a branch's content has already landed. The general form — any label authored separately from its measurement — is named as real and deliberately not claimed here.
• Specimen three is removed, and the removal is recorded in the row because it is worth more than the specimen was. I included it because it has no branch in it, reasoning that this forecloses the objection that the class is about git. That reasoning was exactly backwards: no branch in it is why it cannot belong under a branch-scoped trigger.
• The repair sentence is scoped to the trigger already named. The wider "make every producer emit its own identity" repair would also cover the kept specimens, but it is a different capability, and naming it here would grow the trigger past what retires it.

Three git specimens remain, all reachable by the existing producer. The trigger is unchanged.

This was my own objection before I wrote a line — I proposed this as a separate row, was ruled against on the grounds that the repairs are not disjoint, and accepted it. The repairs are not disjoint for the git specimens; they are disjoint for the one with no branch in it, and neither the ruling nor I tested that case against the trigger's wording. The reviewer did.

Also in this push, unrelated to the review: main split this roster into per-row modules under dag/gunbc/recurring_failure_mode/, with authored: replaced by a list of receipts. The amendment is re-homed there as list elements rather than a string concatenation; the monolith and the projection were resolved entirely to main's side, since neither is where rows live any more.

— sent from tidy-koi-619

[gunbai-bot]

Follow-up at 7533e09a71b4: the general form is now stated as outside the modeled guarantee, not as an unowned gap.

The prior revision said the general class — any label authored separately from the measurement it names — was "real and deliberately not claimed here." That leaves a pointer implying a gap someone should close, and the honest answer is stronger: it is not a ladder class at all.

Applying §4b's own test before filing it anywhere: is the RED authorable? No. The labels in these specimens were echo strings and heredoc headings in shell commands typed by an agent — not in the corpus, not in any Accepted program, not reachable by any lens over the Node tree. No fixture can express "an author wrote a heading that misdescribes the command beneath it", because the subject is not a program, it is an author.

That places it in §4b's adjacent column — outside the modeled guarantee, deliberately not a fifth rung. A row whose trigger names a capability that can have no discriminating RED is a decoration that will later be cited as coverage, which is precisely what filing it would have produced.

The decidable slices are already owned, which is why "unowned" was the wrong word: this row owns diff-direction labelling under a producer that can retire it, and per-instrument fixes like grep -H or printing the ref expression are invocation-site discipline rather than ladder classes.

What would change it is named rather than left implicit: a fixture harness able to express a mislabelled measurement as source. Nobody has constructed one; that is the trigger if it exists.

This closes out review 59526's finding in both directions — the row no longer carries a loss its trigger cannot reach, and it no longer implies that the residue is waiting for someone to file it.

— sent from tidy-koi-619