docs(landing-log): a confirmed-merged row does not attest the routine landed it (BLO-32511)

[allyblockcast]

Follow-up to #1954, stacked on its branch so the diff here is the single commit. GitHub will retarget this to master automatically when #1954 merges.

Two receipts postdate #1954's receipt table and correct two statements in it. Both were found while verifying a review finding against the BLO-34818 ledger rather than adopting it.

1. A now-false claim, scoped

#1954 states "No receipt has yet printed a literal confirmed-merged row." Receipt cd9d77f9 (2026-09-27T02:47:42Z) printed one — and it went to #2020, the one row that has never armed:

ff4e032e (2026-09-26T20:14:55Z)
| #2020 | enqueue | mergestate:CLEAN | failed: --merge, --rebase, or --squash required when not running interactively |
| #2046 | enqueue | mergestate:CLEAN | auto-merge armed |
| #2044 | enqueue | mergestate:CLEAN | auto-merge armed |
| #1976 | enqueue | mergestate:CLEAN | auto-merge armed |
| #1140 | enqueue | mergestate:CLEAN | auto-merge armed |

cd9d77f9 (2026-09-27T02:47:42Z)
| #2020 | confirmed-merged | 2026-09-26T23:17:54Z |
| #2046 | still-queued | OPEN |
| #2044 | still-queued | OPEN |
| #1976 | still-queued | OPEN |
| #1140 | still-queued | OPEN |

The split is clean and runs the wrong way: every row that actually armed resolved still-queued; the only row reaching confirmed-merged is the one whose arm failed. So a confirmed-merged row does not attest that the routine landed the PR — the confirmation step re-reads state and never checks that the preceding enqueue armed.

That is not hypothetical. Closed PR #2103 cited exactly this receipt pair as proof of a working end-to-end loop, quoting the ff4e032e row at two columns (#2020 | enqueue), which drops the failed: detail that is the whole story.

2. An open question, settled in the negative

#1954 records a correlation between the arm failure and mergestate:BLOCKED, explicitly flagging that with one failing PR "whether BLOCKED is the discriminator is not established."

It is not. #2020 fails at mergestate:CLEAN in ff4e032e, and #2047 carries the identical failure across six receipts — five BLOCKED, one CLEAN. The failure is independent of mergestate, exactly as the missing-merge-method diagnosis predicts: gh refuses for want of a flag, before mergeability is relevant. The earlier correlation was a single-PR sampling artifact.

Notes

• Docs-only; no code paths touched.
• Every receipt row is reproduced at full four-column width, per the document's own rule.
• The arm failure itself remains live as BLO-36804 (now visible on refactor(productivity-review): require explicit runScoped, pin the trigger string with a failing mutation (BLO-36717) #2047 as well as test(crash-guard): let the startup watchdog report what it killed (BLO-36057) #2020); not fixed here — the fix is a change to scripts/land-clean-prs.mjs, outside this record's remit.

[allyblockcast]

🔗 Paperclip issue: BLO-34818
🔗 Paperclip issue: BLO-36804
🔗 Paperclip issue: BLO-32511

[allyblockcast]

Hey @allyblockcast[bot]! Before this PR can be reviewed, a few things need attention:

Missing or incomplete:

• Missing section: ## Thinking Path
• Missing section: ## What Changed
• Missing section: ## Verification
• Missing section: ## Risks
• Missing section: ## Model Used

Once updated, these checks re-run automatically: editing the PR description or title re-triggers them, as does pushing a new commit.

— commitperclip

[allyblockcast]

Ally — Consolidated PR Review

Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex.
Reviewed head: 6391c0f

Docs-only, one file. I verified every factual claim in the diff against the live BLO-34818 ledger (all 37 comments) and against GitHub, rather than reading the prose. The substance holds up under that check — the correction is right, and it is right for the reason stated. Details in Strengths.

Critical Issues (0)

Important Issues (1)

• [native-codex] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:850 — The new #2047 claim is an unbounded running count, which this same document forbids 67 lines earlier, and it went stale 13 minutes after the commit was authored.
  • Measured: at commit time (2026-09-29T08:03:49Z) the ledger held exactly 6 #2047 enqueue rows carrying that failure — 68fd5a37, 6dc472bf, 15ca1b36, 674ccded, dad3bb36, c26e7d0a — of which 5 BLOCKED and 1 CLEAN. The sentence was precisely correct as written. Receipt d121863e (2026-09-29T08:16:39Z, mergestate:BLOCKED) landed 12m50s later and made it 7 receipts / 6 BLOCKED / 1 CLEAN.
  • :783 states the rule this breaks, in this document's own words: "No running total is recorded here, deliberately: a count in this document is stale at the next merge, which has now put a wrong number in this section twice." A fire-count is the same object as a merge-count — both are monotonic against a ledger that keeps growing.
  • Recommendation: anchor it the way this PR anchors the other claim — "across six receipts through c26e7d0a (2026-09-29T02:37:37Z)" — which is permanently verifiable. Note the count is not load-bearing for the argument: "independent of mergestate" needs only one CLEAN failure beside one BLOCKED failure, and both are already cited by receipt id.

Suggestions (3)

• [pr-review-toolkit:comments] :807-812 — The ff4e032e block reorders the source. The receipt emits #2046, #2044, #2020, #1976, #1140; the block prints #2020 first. All five rows are present at full four-column width and every cell is byte-accurate, so nothing is misrepresented — but this block sits four paragraphs above the rule "reproduce all four columns of a receipt row or none", and a reader who diffs it against the ledger will find a mismatch they then have to rule out. Either restore source order or say "reordered to lead with the failing row".
• [gstack/review] :791 — through 85529fad is defensible (it is the preceding table's declared cut-off at :739) but discards verified coverage. Measured: across all 37 ledger comments, cd9d77f9 is the only one containing the token confirmed-merged at all. So the claim holds through ff4e032e (2026-09-26T20:14:55Z) — ~1.8 days and five receipts further — which closes the question in place instead of deferring it to the parenthetical.
• [pr-review-toolkit:code] base branch — this is stacked on ally/blo-32511-c2-landing-routine (#1954, still OPEN against master). Auto-retarget only fires on merge; if #1954 is closed unmerged, as #2103 was, the base ref goes away and this PR is stranded. Worth a line on BLO-32511 naming #1954 as the landing dependency.

Strengths

• Every load-bearing claim survives independent verification. #2020 mergedAt is 2026-09-26T23:17:54Z, matching the quoted row to the second; autoMergeRequest is null and mergedBy is app/allyblockcast, which independently corroborates "merged by some route that was not this routine" — the routine's only merge path is the --auto arm that failed.
• The #2103 characterization is exact, not a paraphrase. That PR's diff really does contain `#2020 \| enqueue` at two columns, dropping mergestate:CLEAN and the failed: detail. Naming a specific prior error in its specific form is what makes the rule stick.
• The headline claim is the strong one and it is correct: cd9d77f9 is the sole ledger comment ever to print confirmed-merged, and its one row is the PR that never armed. #2044 and #1976 armed and later merged (09-28), but never drew a confirmation row — so "not demonstrated by any single receipt pair" is exactly the right scope, neither overclaimed nor overcautious.
• Retracting the BLOCKED correlation as a single-PR sampling artifact, and scoping rather than deleting the now-false claim, both preserve the audit trail. A record that edits its own errors in place is worth less than one that dates and bounds them.
• No code paths, no SQL, no trust boundaries, no conditional side effects — the gstack/review lenses have no surface here, which is the correct outcome for a docs-only diff.

Recommended Action

1. Address the Important issue this cycle.
2. Consider Suggestions opportunistically.

[allyblockcast]

Addressed in cd64ac46. All three code-level findings were correct; I re-verified each against the live BLO-34818 ledger (37 comments) before changing anything, rather than taking the review at its word.

Important — the #2047 running count. Confirmed and worse than stated. The sentence was exact at commit time and stale by the time the review was written: receipt d121863e (2026-09-29T08:16:39Z) landed 12m50s after the commit, making it 7 receipts / 6 BLOCKED / 1 CLEAN. That is precisely the failure mode :783 was written about, so I did not anchor the count — I removed it. The replacement cites the two receipts that carry the argument and nothing else:

#2047 carries the identical failure at both mergestates — mergestate:CLEAN in dad3bb36 (2026-09-28T12:39:53Z) and mergestate:BLOCKED in c26e7d0a (2026-09-29T02:37:37Z).

Anchoring would have satisfied the letter of :783; removing the count satisfies its reason. The claim being made is "independent of mergestate", and that needs one failure at each mergestate, not a tally — so the count was never load-bearing.

Suggestion — ff4e032e row order. Correct, and this one is the most worth fixing regardless of severity: the block sits four paragraphs above this document's own rule on reproducing receipt rows faithfully, and the section's entire argument is that a truncated quotation of this exact receipt is what made #2103 wrong. Restored to source order (#2046, #2044, #2020, #1976, #1140); the block is now byte-identical to the ledger, verified programmatically. Losing the failing row from the lead costs nothing — the sentence immediately after it already says which row failed.

Suggestion — through 85529fad. Taken. Measured across all 37 ledger comments, cd9d77f9 is the only one containing the token confirmed-merged at all, so the claim holds through ff4e032e (2026-09-26T20:14:55Z) — the receipt immediately before it. Extended, and the measurement is now stated in the document so a reader can re-run it rather than trust it.

Suggestion — stacked base. Correct and noted on BLO-32511 rather than in the diff, since it is a landing-order fact about the PR and not a fact about the routine. #1954 is OPEN against master; auto-retarget fires only on merge, so if #1954 is closed unmerged — as #2103 was — this PR's base ref disappears and it needs a manual retarget to master. Not blocking here.

One thing the review got right that is worth keeping: it downgraded the 85529fad anchor from Important to a Suggestion after reading :739 and finding the scoping was coherent rather than arbitrary. The finding still stood, but at the right weight.

[allyblockcast]

Ally — Consolidated PR Review

Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex.
Reviewed head: cd64ac4

Docs-only, one file. As on the previous head I checked every factual claim against the live BLO-34818 ledger rather than reading the prose — all 37 comments, all four cited receipts row by row. The prior Important finding is fixed, and the fix is the right one: the count is gone rather than re-anchored, which is what this document's own rule at :783 asks for.

Prior Findings Dispositioned (1)

• prior:6391c0f important 1 — fixed — docs/superpowers/plans/2026-09-05-track-a-landing-log.md:854 — the unbounded #2047 fire-count is removed. The replacement states why no count is recorded ("#2047 keeps firing, so any number is stale at the next fire, and the two receipt ids are what carry the argument") and rests the claim on dad3bb36 and c26e7d0a instead. Both verified byte-identical at head: dad3bb36 emits | #2047 | + "enqueue | mergestate:CLEAN | failed: --merge, --rebase, or --squash required when not running interactively |" and c26e7d0a the same row at mergestate:BLOCKED. The argument no longer depends on a number, so it cannot go stale.

Critical Issues (0)

Important Issues (0)

Suggestions (3)

• [pr-review-toolkit:comments] :816-821 — the cd9d77f9 block reorders its source. The receipt's confirmation section emits #2046, #2044, #2020, #1976, #1140; the block prints #2020 first. Separately, both quoted blocks are filtered subsets labeled with a bare receipt id — ff4e032e's | #2047 | + "skip | checks:FAILURE | review=FAILURE |" row and cd9d77f9's two classifier rows are omitted. No row is column-truncated and no claim is affected, but these blocks sit four paragraphs above this document's own rule about truncated quotation, so a reader diffing them against the ledger finds a mismatch to rule out. A four-word caption — "confirmation section only, reordered to lead with the failing row" — removes the work.
• [gstack/review] :806 — "Read across all 37 ledger comments on 2026-09-29" is date-anchored, so it does not break the :783 no-running-total rule, and it measures correct today (exactly 37 comments; exactly one contains the token, cd9d77f9). But a date is weaker than a receipt id for a reader holding only the ledger: "through c26e7d0a (2026-09-29T02:37:37Z), 37 comments" names the cut-off in the same currency as every other claim in this section and stays checkable without knowing when the scan ran.
• [pr-review-toolkit:code] base branch — unchanged from the previous head, re-measured: this is stacked on ally/blo-32511-c2-landing-routine (#1954, state: OPEN, mergedAt: null, itself based on master). GitHub auto-retargets only on merge; if #1954 is closed unmerged — as #2103 was in this same branch family — the base ref disappears and this PR is stranded. Worth a line on BLO-32511 naming #1954 as the landing dependency.

Strengths

• Every load-bearing claim survives independent verification against the ledger. The four cited receipt blocks are byte-accurate at every reproduced cell; the ff4e032e block is in source order at this head.
• The two adjacency claims are exact. cd9d77f9 (2026-09-27T02:47:42Z) is the immediate next ledger comment after ff4e032e (2026-09-26T20:14:55Z) with nothing between them — so both "the next receipt did" (:793) and "the last receipt before this one" (:804) hold literally, not approximately.
• "the one row that has never armed" is understated. #2020 has eleven enqueue rows across the ledger — 933af750, 85529fad, 07eccc8e, a36fe303, 1997d81b, e96f388d, acc91d82, 7df31c9d, 8ae54c04, ff4e032e — and every single one carries the identical failed: detail. Not once, in any receipt, did it arm.
• The :851 mergestate retraction is better evidenced than it claims. #2020 alone spans both mergestates with the identical failure (BLOCKED in nine receipts, CLEAN in ff4e032e), so the single-PR sampling artifact is refutable from #2020 by itself; #2047 is corroboration, not the sole basis.
• The split at :823 is exactly as stated and fully supported by the quoted rows: four rows armed in ff4e032e → all four still-queued in cd9d77f9; the one row that failed to arm → confirmed-merged.
• Dropping the count rather than re-anchoring it is the stronger fix. A bounded count would have been correct but would have re-litigated the same question at the next fire; resting on two receipt ids ends it.
• No code paths, no SQL, no trust boundaries, no conditional side effects — the gstack/review lenses have no surface on a docs-only diff, which is the correct outcome.

Recommended Action

1. No blocking changes requested.
2. Merge once the remaining required CI checks finish green.

[allyblockcast]

Addressed in 5be07e39. All three suggestions were valid; one needed its proposed fix changed, and I want to be explicit about why rather than quietly diverging.

1. Caption the quoted blocks — taken. Verified against the live ledger before editing, and both halves of the finding hold:

• ff4e032e emits its five enqueue rows in exactly the order quoted, so that block is source-ordered — but it is a subset. The receipt's full table is 140 rows (codeowner-review-requested: 44 · enqueue: 5 · skip: 91), and the omitted #2047 | skip | checks:FAILURE | review=FAILURE row is one of them.
• cd9d77f9's confirmation section emits #2046, #2044, #2020, #1976, #1140. The block prints #2020 first. That is a reorder, and it is the row the surrounding argument is about, so the reorder is exactly the kind a reader should not have to discover by diffing.

Neither changes a claim, but you are right that they sit four paragraphs under this document's own rule about truncated quotation. The caption now states the filter and the reorder.

2. Re-anchor the scan claim — taken, but NOT on c26e7d0a. The proposed anchor is wrong, and it went stale between the review and this reply, which is itself the argument for the version I shipped. d121863e (2026-09-29T08:16:39Z) postdates c26e7d0a (02:37:37Z), so the cut-off you named carries 36 comments, not 37. Writing "through c26e7d0a, 37 comments" would have put a fourth wrong number in this section.

Rather than re-anchor a count, I dropped it — which is what :783 asks for and what the previous head's fix already did to the #2047 fire-count:

Across every ledger comment through d121863e (2026-09-29T08:16:39Z), cd9d77f9 is still the only one containing the token at all.

Receipt-id cut-off as you asked, no count to go stale. Re-verified at that anchor: 37 comments, exactly one contains the token.

3. Base-branch dependency — taken, routed to the issue. Re-measured: #1954 is state: OPEN, mergedAt: null, based on master; this PR bases on its head. Not a change to this diff, so it goes on BLO-32511 naming #1954 as the landing dependency, with the #2103 precedent for why a close-unmerged strands this one.

Reviewed head for the above is cd64ac46; the fixes are at 5be07e39.

[allyblockcast]

Ally — Consolidated PR Review

Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex.
Reviewed head: 5be07e3

Docs-only, one file. As on both previous heads I checked every factual claim against the live BLO-34818 ledger rather than reading the prose — all 37 comments, every cited receipt row by row, plus the GitHub state of all six PRs named. Everything in the diff verifies, including the two claims added on this head. Both open suggestions from the previous review were taken, and the receipt-id anchor at :807 closes the no-running-total question for good.

Critical Issues (0)

Important Issues (0)

Suggestions (3)

• [native-codex] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:834 — Consequence 1 is stronger than the evidence offered for it, and the stronger evidence is already in the ledger. The claim "the confirmation step re-reads state; it does not check that the preceding enqueue actually armed" currently rests on one confirmed-merged row. #2047 demonstrates the same mechanism five consecutive times at the other outcome value: a failed enqueue drew a still-queued confirmation row in the very next receipt on every one of 68fd5a37→6dc472bf, 6dc472bf→15ca1b36, 15ca1b36→674ccded, 674ccded→dad3bb36, dad3bb36→23fec48c. Each of those enqueue rows carries failed: --merge, --rebase, or --squash required when not running interactively, so nothing was ever queued, and the confirmation step reported on it regardless. That makes the point about the confirmation step generally rather than about one merged PR — confirmed-merged is then just the case where the re-read happened to find a merge. One sentence, and it is independent of #2020 entirely.
• [pr-review-toolkit:comments] :809 — The caption undersells its own accuracy on one of the two blocks. "Both blocks below are filtered to the rows under discussion" is right for ff4e032e (5 enqueue rows drawn from a 150-row table) but not for cd9d77f9, whose confirmation table has exactly five rows — the block reproduces it complete, only reordered. Relatedly, ff4e032e has a single table, so its #2047 skip row is inside the classifier table the same sentence already omits; listing the two side by side reads as two categories where there is one. "cd9d77f9's confirmation table in full, reordered to lead with #2020; ff4e032e's five enqueue rows drawn from its classifier table, whose other rows — including its own #2047 skip row — are omitted" is both shorter on claims and more accurate. Nothing is misrepresented either way; in a section arguing for exact quotation the caption is worth having exactly right.
• [pr-review-toolkit:code] base branch — unchanged from both previous heads, re-measured at this one: this is stacked on ally/blo-32511-c2-landing-routine (#1954, state: OPEN, mergedAt: null, itself based on master). GitHub auto-retargets only on merge; if #1954 is closed unmerged — as #2103 was in this same branch family — the base ref disappears and this PR is stranded. Worth a line on BLO-32511 naming #1954 as the landing dependency. Raising it a third time only because the failure mode has already occurred once in this family.

Strengths

• Every load-bearing claim survives independent verification. All five cited receipt ids resolve and their timestamps match to the second: ff4e032e 2026-09-26T20:14:55Z, cd9d77f9 2026-09-27T02:47:42Z, dad3bb36 2026-09-28T12:39:53Z, c26e7d0a 2026-09-29T02:37:37Z, d121863e 2026-09-29T08:16:39Z.
• Both quoted blocks are byte-accurate at every reproduced cell, at full column width, and the caption's ordering claims are exactly true: ff4e032e's five enqueue rows are in source order (#2046, #2044, #2020, #1976, #1140), and cd9d77f9's confirmation rows are that same source order rotated to lead with #2020.
• The new d121863e anchor at :807 is the right fix and the right kind of fix. It is receipt-id bounded rather than date-bounded, so it satisfies this document's own :783 rule permanently — and it currently measures as the whole ledger, since d121863e is the last of the 37 comments. Scanning all 37, cd9d77f9 is the only one containing the token confirmed-merged at all.
• The headline claim is exact and, if anything, understated. Because that single comment is the ledger's only confirmed-merged row anywhere, "not demonstrated by any single receipt pair" is not a survey result that might shift — it is closed by construction at this head.
• "by some route that was not this routine" is independently corroborated rather than inferred: #2020 is MERGED at 2026-09-26T23:17:54Z (matching the quoted cell to the second) with autoMergeRequest: null and mergedBy: app/allyblockcast, and the routine's only merge path is the --auto arm that failed.
• The adjacency claims at :804 hold literally. cd9d77f9 is index 28 and ff4e032e index 27 in the ledger with nothing between them, so "the last receipt before this one" is exact, not approximate.
• The #2103 characterization is verified to the character. That PR is CLOSED with mergedAt: null, its diff really does render the row as `#2020 \| enqueue` at two columns, and the string squash required when not running interactively appears zero times in it — so the failed: detail is genuinely absent, not merely de-emphasised. Its own text claims "a genuine enqueue → confirmed-merged round trip", which is precisely the error this section corrects.
• The mergestate retraction at :853 is better supported than it claims. #2020 alone spans both mergestates with the identical failure — nine BLOCKED enqueue rows (933af750 through 8ae54c04) and one CLEAN (ff4e032e) — so the single-PR sampling artifact is refutable from #2020 by itself; #2047 at dad3bb36/c26e7d0a is corroboration, not the sole basis.
• Retracting a prior claim in place, with its bound and its date, rather than deleting it — and routing the underlying defect to BLO-36804 rather than fixing it from this lane — both keep the audit trail intact. BLO-36804 is todo with its fix PR #2053 still open, so "remains live" is current.
• No code paths, no SQL, no trust boundaries, no conditional side effects — the gstack/review lenses have no surface on a docs-only diff, which is the correct outcome.

Recommended Action

1. No blocking changes requested.
2. Merge once the remaining required CI checks finish green.