Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
kkroo merged 3 commits into from
Oct 4, 2026
Merged

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

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
66a1ada
docs(landing-log): record that the first confirmed-merged row went to…
Sep 29, 2026
64d21ce
docs(landing-log): drop the running receipt count, extend the scoped …
Sep 29, 2026
3ba3f99
docs(landing-log): caption the filtered receipt blocks, drop the comm…
Sep 29, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
78 changes: 73 additions & 5 deletions docs/superpowers/plans/2026-09-05-track-a-landing-log.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -788,14 +788,82 @@ receipts.
The remaining rows are open as of writing — #1985, #1976, #2020, #1774 all `state: OPEN`,
`mergedAt: null` — so `still-queued` remains the accurate classification for the three of them that
armed. For #2020 it is accurate only about the PR's state, not about the routine's: it never entered
the queue. **No receipt has yet printed a literal `confirmed-merged` row**, because each merge fell
outside the one-receipt confirmation window that had already resolved its row. Resolution-to-merge
was 1d23h12m for #1990 (`aec91d73`, `2026-09-23T03:22:09Z`), 1d22h43m for #1804 (`aa6a0a70`,
`2026-09-23T16:44:08Z`) and 1d07h58m for #2001 (`933af750`, `2026-09-25T07:18:04Z`) — #2001 is the
sharpest of the three and still misses its window by more than a day. Every later receipt that names
the queue. **No receipt printed a literal `confirmed-merged` row through `ff4e032e`
(`2026-09-26T20:14:55Z`)**, because each merge fell outside the one-receipt confirmation window that
had already resolved its row. (The next receipt did — to #2020, the row that never armed; see
below.) Resolution-to-merge was 1d23h12m for #1990 (`aec91d73`, `2026-09-23T03:22:09Z`), 1d22h43m
for #1804 (`aa6a0a70`, `2026-09-23T16:44:08Z`) and 1d07h58m for #2001 (`933af750`,
`2026-09-25T07:18:04Z`) — #2001 is the sharpest of the three and still misses its window by more
than a day. Every later receipt that names
#2001 at all carries it only as a `skip` / `mergestate:UNKNOWN` classifier row, not a confirmation;
the last of those is `8ae54c04` (`2026-09-26T08:17:49Z`), 6h59m before the merge.

#### The first literal `confirmed-merged` row went to the PR that never armed

Recorded 2026-09-29, from receipts that postdate the table above. The scoped claim in the previous
section held through `ff4e032e`, the last receipt before this one, and no further: `cd9d77f9`
(`2026-09-27T02:47:42Z`) printed the first literal `confirmed-merged` row this ledger has produced,
and it went to **#2020** — the one row that has never armed. Across every ledger comment through
`d121863e` (`2026-09-29T08:16:39Z`), `cd9d77f9` is still the only one containing the token at all.

Both blocks below are filtered to the rows under discussion: `ff4e032e`'s five `enqueue` rows in
source order, and `cd9d77f9`'s five confirmation rows reordered to lead with `#2020`. Each
receipt's other rows — the classifier table, and `ff4e032e`'s own `#2047` `skip` row — are omitted.

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

cd9d77f9-82fd-4f64-900c-8034f8d7192f (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 it runs the wrong way.** All four rows that genuinely armed resolved
`still-queued`; the only row reaching `confirmed-merged` is the one whose arm failed. #2020 merged
at `2026-09-26T23:17:54Z` by some route that was not this routine — the confirmation step merely
observed a merged PR and reported it.

Two consequences for anyone reading this ledger:

1. **A `confirmed-merged` row does not attest that the routine landed the PR.** The confirmation
step re-reads state; it does not check that the preceding `enqueue` actually armed. So the row is
evidence about GitHub, not about C2. To claim a round trip, pair a `confirmed-merged` row with an
`auto-merge armed` detail on its originating `enqueue` — the fourth column, not the second.
2. **`gh pr view <n> --json state,mergedAt` → `MERGED` cannot close that gap either.** A terminal
state does not name the mechanism that produced it, so it corroborates the merge and says nothing
about the cause.

This is not hypothetical. A draft of this record ([#2103](https://github.com/Blockcast/paperclip/pull/2103),
closed unmerged) 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. The mechanism was a truncated quotation, which is why the rule in the section above is
to reproduce all four columns of a receipt row or none.

On the evidence to date, a completed `enqueue` → `confirmed-merged` round trip **attributable to
this routine** is still not demonstrated by any single receipt pair. The three landings recorded
under "Landed end to end" remain the routine's proof, and they are proof precisely because each was
armed, tracked, and verified — not because a confirmation row said `confirmed-merged`.

**This also settles the open question in the section above**, in the negative. That section recorded
a clean correlation between the arm failure and `mergestate:BLOCKED`, while flagging that with one
distinct 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 at both
mergestates — `mergestate:CLEAN` in `dad3bb36` (`2026-09-28T12:39:53Z`) and `mergestate:BLOCKED` in
`c26e7d0a` (`2026-09-29T02:37:37Z`). No count of the failing receipts is recorded here, for the
reason given above: #2047 keeps firing, so any number is stale at the next fire, and the two receipt
ids are what carry the argument. The failure is independent of mergestate, which is what the
missing-merge-method diagnosis predicts: `gh` refuses for want of a flag, before mergeability is
relevant. The earlier correlation was an artifact of a single-PR sample.

The arm failure itself is [BLO-36804](https://paperclip.blockcast.net/BLO/issues/BLO-36804); it
remains live and is now visible on #2047 as well as #2020.

#### AC 3 names a field this repo does not use — fifth plan-vs-reality drift

AC 3 expects each `enqueue` row to show `autoMergeRequest` set on GitHub. Measured, it is **null on
Expand Down