From 66a1adaf5413d0e646a5627e196edd4b5210eab8 Mon Sep 17 00:00:00 2001 From: Ally Date: Tue, 29 Sep 2026 08:03:49 +0000 Subject: [PATCH 1/3] docs(landing-log): record that the first confirmed-merged row went to the PR that never armed Receipts ff4e032e (09-26T20:14:55Z) and cd9d77f9 (09-27T02:47:42Z) postdate this document's receipt table and correct two things in it. 1. The claim "No receipt has yet printed a literal confirmed-merged row" is no longer true, so it is scoped to the range it was measured over (through 85529fad). cd9d77f9 printed one -- for #2020, the single row that has never armed. All four rows in that fire that genuinely armed resolved still-queued. The consequence is worth stating plainly: 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, so it reports a merge that happened by any route. Reading one as proof of an end-to-end loop is exactly the error a closed draft of this record (#2103) made. 2. The open question "whether BLOCKED is the discriminator is not established" is settled in the negative. #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, as the missing-merge-method diagnosis predicts. The earlier correlation was a single-PR sampling artifact. Every row quoted here is reproduced at full four-column width, per this document's own rule -- the truncation of that fourth column is what let the false claim through in the first place. Arm failure remains live as BLO-36804. Co-Authored-By: Claude --- .../plans/2026-09-05-track-a-landing-log.md | 63 ++++++++++++++++++- 1 file changed, 61 insertions(+), 2 deletions(-) diff --git a/docs/superpowers/plans/2026-09-05-track-a-landing-log.md b/docs/superpowers/plans/2026-09-05-track-a-landing-log.md index 02ecefe2f507..3e70463243fd 100644 --- a/docs/superpowers/plans/2026-09-05-track-a-landing-log.md +++ b/docs/superpowers/plans/2026-09-05-track-a-landing-log.md @@ -788,14 +788,73 @@ 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 +the queue. **No receipt printed a literal `confirmed-merged` row through `85529fad`**, because each +merge fell outside the one-receipt confirmation window that had already resolved its row. (A later +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 only through `85529fad`; receipt `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: + + ff4e032e-2d91-4052-aceb-a0278738a713 (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-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 --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 across six +receipts — five `mergestate:BLOCKED` and one `mergestate:CLEAN`. 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 From 64d21ce4228448abefb83b7688063805c1231b02 Mon Sep 17 00:00:00 2001 From: Ally Date: Tue, 29 Sep 2026 08:33:00 +0000 Subject: [PATCH 2/3] docs(landing-log): drop the running receipt count, extend the scoped claim (BLO-32511) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Review on #2106 found three defects in the new section; all three verified against the live BLO-34818 ledger (37 comments) before fixing. 1. The `#2047 ... across six receipts` sentence was an unbounded running count, which :783 of this same document forbids — and it had already gone stale: receipt `d121863e` (2026-09-29T08:16:39Z) landed 12m50s after the commit, making it 7 receipts, not 6. Replaced with the two receipt ids that actually carry the argument (`dad3bb36` CLEAN, `c26e7d0a` BLOCKED) and no count at all. 2. The `ff4e032e` quoted block reordered its source rows to lead with the failing one, four paragraphs above this document's own rule on quotation fidelity. Restored to source order; now byte-identical. 3. `through 85529fad` discarded ~1.8 days of 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` — the receipt immediately preceding it. --- .../plans/2026-09-05-track-a-landing-log.md | 33 +++++++++++-------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/docs/superpowers/plans/2026-09-05-track-a-landing-log.md b/docs/superpowers/plans/2026-09-05-track-a-landing-log.md index 3e70463243fd..1b54a4e7a1f3 100644 --- a/docs/superpowers/plans/2026-09-05-track-a-landing-log.md +++ b/docs/superpowers/plans/2026-09-05-track-a-landing-log.md @@ -788,26 +788,28 @@ 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 printed a literal `confirmed-merged` row through `85529fad`**, because each -merge fell outside the one-receipt confirmation window that had already resolved its row. (A later -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 +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 only through `85529fad`; receipt `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: +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. Read across all 37 ledger comments on +2026-09-29, `cd9d77f9` is still the only one containing the token at all: ff4e032e-2d91-4052-aceb-a0278738a713 (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 | + | #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 | @@ -847,10 +849,13 @@ armed, tracked, and verified — not because a confirmation row said `confirmed- **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 across six -receipts — five `mergestate:BLOCKED` and one `mergestate:CLEAN`. 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. +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. From 3ba3f999a58220b9b7a9ec265ac47288f2ffa922 Mon Sep 17 00:00:00 2001 From: Ally Date: Tue, 29 Sep 2026 09:48:17 +0000 Subject: [PATCH 3/3] docs(landing-log): caption the filtered receipt blocks, drop the comment count (BLO-32511) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Review suggestions on #2106. - The two quoted receipt blocks are filtered subsets and `cd9d77f9`'s is reordered to lead with #2020. Both sat four paragraphs below this document's own rule about truncated quotation, with nothing saying they were filtered. Caption states the filter and the reorder. - "all 37 ledger comments on 2026-09-29" is a running total, which :783 forbids. Re-anchored on the last ledger comment id instead of a count. Not anchored on `c26e7d0a` as the review proposed: `d121863e` (2026-09-29T08:16:39Z) postdates it, so "through c26e7d0a, 37" would be wrong — that cut-off is 36. Co-Authored-By: Paperclip --- docs/superpowers/plans/2026-09-05-track-a-landing-log.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/superpowers/plans/2026-09-05-track-a-landing-log.md b/docs/superpowers/plans/2026-09-05-track-a-landing-log.md index 1b54a4e7a1f3..fcccd1368614 100644 --- a/docs/superpowers/plans/2026-09-05-track-a-landing-log.md +++ b/docs/superpowers/plans/2026-09-05-track-a-landing-log.md @@ -803,8 +803,12 @@ the last of those is `8ae54c04` (`2026-09-26T08:17:49Z`), 6h59m before the merge 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. Read across all 37 ledger comments on -2026-09-29, `cd9d77f9` is still the only one containing the token at all: +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 |