docs(landing-log): record the C2 landing routine, its trigger, and both receipts (BLO-32511)

[allyblockcast]

Thinking Path

• Paperclip is the open source app people use to manage AI agents for work
• Track C of the 2026-09-04 in_review truth-gate plan adds a scheduled routine that runs the C1 landing classifier (scripts/land-clean-prs.mjs) and arms auto-merge on PRs that are already cleanly reviewed
• A cron routine's side effects are observed by no CI job, so the only durable record of what it did is the receipt it posts and the landing log that cites it
• Without that log, an auditor reading the routine later cannot tell a correct no-op fire from a broken one — and three specific readings of this routine's behaviour are counter-intuitive enough to be misread as defects
• This pull request appends the routine's identity, its trigger, its audit issue, and its first three fires with their receipts to docs/superpowers/plans/2026-09-05-track-a-landing-log.md
• The benefit is that the last acceptance criterion of BLO-32511 closes against a committed artifact, and the three counter-intuitive readings are recorded with their evidence rather than re-derived wrongly by the next reader

Linked Issues or Issue Description

• Refs BLO-32511 — Create the Land clean-reviewed PRs routine (Track C2). This PR closes its final acceptance criterion.
• Refs BLO-34818 — the audit issue carrying the receipts cited here.
• Refs BLO-32237 — the plan epic.

What Changed

• Appends one section to docs/superpowers/plans/2026-09-05-track-a-landing-log.md recording the C2 routine end-to-end. No other file is touched.

• Records the routine's identity and configuration:

  item	value
  routine	022cdf7f-e719-4992-b9c6-5bb36801995c — active, high, skip_if_active, assignee Ally
  trigger	50cb6f35-fd8c-46ad-aa24-6b6a4bf13e36 — 45 */6 * * * America/Los_Angeles, enabled
  audit issue	BLO-34818
  receipt 1	e5b20c74 — fire 1, 2026-09-20T13:10:13Z
  receipt 2	31344cc1 — fire 2, 2026-09-20T20:50:12Z
  receipt 3	19519080 — recovered 01:45Z slot, 2026-09-21T07:16:33Z

• Records a correction to the plan's step 4: POST /api/agents/<id>/heartbeat/invoke wakes the agent and does not fire the routine. The manual-fire path is POST /api/routines/{id}/run.

• Records three readings an auditor would otherwise get wrong:

  • ACs 3 and 4 hold vacuously, and the log says so. No fire produced a single enqueue row, so nothing was armed and nothing was confirmed. Across the three fires' 123 / 127 / 129 classified rows essentially every open PR fails a real gate first (checks:FAILURE dominates; codeowner-review-requested runs 13 → 20 → 29). The routine is correctly declining to merge PRs that are not clean. No gh pr view --json state,mergedAt verification was run because there are zero confirmed-merged rows to verify.
  • Four cron slots produced three receipts, and that is correct. skip_if_active records a dropped fire as skipped with a coalescedIntoRunId. Counting cron slots against receipts reports a false missing-receipt defect. The two coalesced slots resolved differently — 13:45Z produced no receipt, 01:45Z did — so no fixed receipts-per-slot ratio should be inferred from either.
  • BLO-34946 read blocked with blockedBy: [] and was NOT a BLO-27553 strand. It carried activeRecoveryAction.status: "active", attempt 1/5, future timeoutAt, wakePolicy: wake_owner — a live wake path. A PATCH {status} would have discharged the recovery action and deleted it. It was left untouched, and the recovery action then fired on its own and posted receipt 3, confirming the decision by outcome rather than only by rule.

• Supersedes the fire-1 placeholder ("receipts are not yet recorded here") and the workspace-binding risk note. That risk did not materialise — no receipt contains aborted:script-missing — but the binding is still absent, so it is recorded as live-but-unrealised rather than dropped.

Verification

• Routine description re-verified byte-identical against the CTO's verbatim block in comment db9e6844-… on BLO-32511, extracted programmatically between the code fences rather than retyped: both sides 2284 bytes, diff empty.

  curl -sS -H "Authorization: Bearer $PAPERCLIP_API_KEY" \
    "$PAPERCLIP_API_URL/api/routines/022cdf7f-e719-4992-b9c6-5bb36801995c" | jq -r .description
  

• GET /api/routines/022cdf7f-… → status: active, priority: high, concurrencyPolicy: skip_if_active, assigneeAgentId Ally.

• GET /api/routines/022cdf7f-…/triggers → exactly one enabled row, 45 */6 * * *, America/Los_Angeles.

• GET /api/issues/ad731b30-0579-4f2c-b5de-2190967bec50/comments → five comments whose first line is exactly <!-- landing-routine-receipt -->; the three cited above are receipts 1–3.

• Docs-only change: no runtime surface, no tests to add. docs/superpowers/plans/** is not covered by .github/CODEOWNERS, so this diff carries no @kkroo gate.

Risks

Low risk. The diff touches one Markdown file under docs/ and no code, schema, workflow, or configuration. There is no migration, no behavioural change, and nothing to roll back beyond reverting the commit.

The one real risk is staleness rather than breakage: the log is explicitly a point-in-time record through fire 3, and the routine remains active and keeps posting receipts to BLO-34818. The log says so in as many words and names BLO-34818 — not this file — as the running ledger, so a later reader is not misled into treating it as current.

Model Used

Claude Opus 5 (claude-opus-5, 1M context), running as the Ally agent under Claude Code with extended thinking and tool use (gh CLI, Paperclip MCP). All API readings, the byte-identical description diff, and the merge-gate check-run reads cited above were executed as tool calls, not recalled.

Checklist

• I have included a thinking path that traces from project context to this change
• I have specified the model used (with version and capability details)
• I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work
• I have searched GitHub for duplicate or related PRs and linked them above
• I have either (a) linked existing issues with Fixes: # / Closes # / Refs # OR (b) described the issue in-PR following the relevant issue template
• I have run tests locally and they pass — n/a, docs-only diff with no runtime surface
• I have added or updated tests where applicable — n/a, docs-only diff
• If this change affects the UI, I have included before/after screenshots — n/a, no UI surface
• I have updated relevant documentation to reflect my changes — this PR is the documentation update
• I have considered and documented any risks above
• All Paperclip CI gates are green
• Greptile is 5/5 with no open P2s, recommendations, or follow-ups
• I will address all Greptile and reviewer comments before requesting merge

[allyblockcast]

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

[allyblockcast]

✅ All checks passing — ready for Greptile review and maintainer approval.

— commitperclip

[github-actions]

@ally head 31c4201 has been awaiting review for 1.6h with no review on either surface (pulls/1954/reviews carries no consolidated report for this head, no ## Ally comment either) -- automated sweep (BLO-22892 / BLO-28203), not a human/agent re-ask.

Requested a review from @allyblockcast directly (native GitHub review request, not just this comment) against current head 31c4201.

[allyblockcast]

Ally — Consolidated PR Review

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

Documentation-only change: one landing-log section (+68) recording the replacement C2 routine, its trigger, and fire 1. No executable surface, so the code/test/error-handling/type lenses have nothing to bind to. The comments-and-prose lens is the whole review here, and I checked the factual claims mechanically rather than by eye.

Critical Issues (0)

Important Issues (0)

Suggestions (1)

• [native-codex] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:569 — "Receipts … are appended in the next section when the execution issue runs" resolves to ## C3 — governance sweep un-paused (2026-09-07), which is a different routine. Whoever appends the fire-1 receipts will most likely add them at the end of this C2 subsection, not in C3.
  • Say where instead of when: "appended below, under this C2 section". Cheap to fix now, and it is the line the next reader navigates by.

Strengths

• The description-fidelity check is stated as a method, not a conclusion. Extracting the CTO's block programmatically (awk between fences, no retyping), comparing byte counts, and publishing the re-run curl means the claim is reproducible by the next reader instead of trusted. That is the right shape for a log entry.
• Every checkable claim verified at this head. server/src/routes/routines.ts:100-106 is byte-exact — that range is assertCanManageCompanyRoutine, which throws forbidden("Agents can only manage routines assigned to themselves") when assigneeAgentId !== req.actor.agentId. The "fire path likewise refuses a foreign agent id" claim holds too: POST /routines/:id/run gates on assertCanManageExistingRoutine, which applies the same assignee equality test. scripts/land-clean-prs.mjs is 20217 bytes on master, exactly as stated. skills/paperclip/references/routines.md §"Manual Run" documents POST /api/routines/{routineId}/run with the source/triggerId payload the section describes.
• Internal arithmetic is consistent. 45 */6 * * * in America/Los_Angeles fires 06:45 PDT = 13:45Z, matching the recorded first nextRunAt; the fire-1 timeline (10:43:04Z fire → 10:48:58Z heartbeat → "~12 minutes in todo") is coherent.
• The step-4 correction is the valuable part of this diff. heartbeat/invoke waking the agent rather than firing the routine is a drift that would cost the next reader a confusing no-receipt fire; recording it alongside the correct endpoint and the idempotencyKey that prevents a double-fire is exactly what a landing log is for.
• Negative result reported rather than smoothed over. The missing projectId/workspace binding is called out ahead of the first receipt, with the specific symptom (aborted:script-missing) and an explicit statement that the cause would not be the C1 script. That pre-empts the wrong diagnosis.
• No secrets committed — the re-run snippet interpolates $PAPERCLIP_API_KEY rather than embedding a token. Heading nesting (## C2 → ### → #### → ## C3) and the 4-space indented-code style both match the surrounding document.

Recommended Action

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

[allyblockcast]

Auto-merge had been armed for over 13h without landing, so the landing routine disarmed it. It will re-arm on the next fire once this PR classifies clean.

[allyblockcast]

Ally — Consolidated PR Review

Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex. No nested CLI launched (k8s Job pod); lens prompts applied directly over the diff and the exact changed path.
Reviewed head: 2843364

Self-review disclosure. This PR is authored by app/allyblockcast and so is this review — same GitHub identity, same lane. GitHub bars a PR's author from APPROVE, so this is submitted as a formal COMMENTED review, which is the required delivery form. It does not constitute independent review and does not satisfy condition 4 of the BLO-26572 scope note ("reviewed by someone who did not write it"). Read the verdict below as an author's self-check, not as a second pair of eyes.

Critical Issues (0)

Important Issues (0)

Suggestions (1)

• [native-codex] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:531 — the trigger row (45 */6 * * *, America/Los_Angeles, enabled) could not be re-read directly this run: GET /api/routines/{id}/triggers returns {"error":"API route not found"}. The value is carried forward from the earlier verified record and corroborated indirectly — observed fire times are 13:45Z / 19:45Z / 01:45Z, i.e. 6h apart at :45, and 06:45 PDT = 13:45Z — plus triggerId: 50cb6f35-… appearing on every routine_runs row.
  • Worth one line in the table saying the cron/timezone is corroborated from fire times rather than re-read, and naming the working endpoint (the runs list carries triggerId) so the next reader does not repeat the 404. Not blocking: the corroboration is strong and self-consistent.

Strengths

• Three unverified claims were removed during review rather than reworded, and all three were the author's own. The fire-1 dispatch lag was recorded as "~12 minutes" and a source comment said "~18 minutes"; the measured gap from mint (10:43:04.948Z) to pickup (13:01:18.951Z) is 2h18m14s — the second figure had dropped the hours. The claim that the classifier suppresses an already-flagged stale-enqueue was invented; #1444 and #1271 simply reclassified to skip · checks:FAILURE, and the text now states that as observed with no mechanism claimed. The claim that coalescing drops a slot was too strong; the two coalesced slots resolved differently.
• ACs 3 and 4 are reported as vacuously satisfied rather than as a green pass. Zero enqueue rows across three fires means nothing was armed and nothing confirmed. A log that recorded these as "met" would be technically true and would mislead every later reader about whether the mechanism has ever run. Stating that the first genuine exercise awaits a PR with green checks and an owner approval at head is the useful form.
• The BLO-34946 section is now a worked example rather than a prediction, and it landed the right way round. The issue read blocked / blockedBy: [] for ~7h — the exact shape the BLO-27553 detector flags — while carrying an active recovery action with a future timeoutAt. It was left untouched, the recovery action fired unaided at 07:16Z, produced receipt 3, and closed the issue done at 07:20:47Z. Had a status PATCH "repaired" it in that window the action would have been discharged and the fire would have produced no receipt at all.
• Every figure in the diff is traceable to a command. Routine fields, the 2284-byte description check, receipt comment ids and timestamps, the four-slot coalescing table with coalescedIntoRunId, and the recovery-action timeline were each re-read from the API this run; the tallies reconcile (123, 127, 129 rows).
• docs/superpowers/plans/** is not covered by .github/CODEOWNERS (which scopes doc/RELEASING.md, not docs/), so no @kkroo gate applies. Docs-only, no runtime surface. No secrets: the re-run snippets interpolate $PAPERCLIP_API_KEY rather than embedding a token. Heading nesting and 4-space code indents match the surrounding document.

Recommended Action

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

[allyblockcast]

This PR is clean at its current head but still has an outstanding code-owner review request (allyblockcast). GitHub does not enforce CODEOWNERS on this repository, so the landing routine holds it here rather than enqueuing it.

[github-actions]

Merge-queue ejection detected for PR #1954. The merge-group run failed and GitHub may have removed the PR from the queue and dropped auto-merge. Inspect the merge-group jobs, fix or rerun the failing checks, then re-enqueue the PR.

Run: https://github.com/Blockcast/paperclip/actions/runs/36050446289

[github-actions]

@ally head c26eb0a has been awaiting review for 18.5h with no review on either surface (pulls/1954/reviews carries no consolidated report for this head, no ## Ally comment either) -- automated sweep (BLO-22892 / BLO-28203), not a human/agent re-ask.

Requested a review from @allyblockcast directly (native GitHub review request, not just this comment) against current head c26eb0a.

[github-actions]

@ally head c26eb0a has been awaiting review for 20.7h with no review on either surface (pulls/1954/reviews carries no consolidated report for this head, no ## Ally comment either) -- automated sweep (BLO-22892 / BLO-28203), not a human/agent re-ask.

Requested a review from @allyblockcast directly (native GitHub review request, not just this comment) against current head c26eb0a.

[allyblockcast]

Ally — Consolidated PR Review

Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex. No nested CLI launched (k8s Job pod); lens prompts applied directly over the diff and the exact changed path.
Reviewed head: c26eb0a

Self-review disclosure. This PR is authored by app/allyblockcast and so is this review — same GitHub identity, same lane. GitHub bars a PR's author from APPROVE, so this is submitted as a formal COMMENTED review, which is the required delivery form. It does not constitute independent review and does not satisfy condition 4 of the BLO-26572 scope note ("reviewed by someone who did not write it"). Read the verdict below as an author's self-check, not as a second pair of eyes.

Docs-only: one Markdown file, +289/−0, no executable surface, so the code/test/error-handling/type lenses have nothing to bind to. The prose lens is the whole review, and every checkable figure in the new "Fires 4–10" section was re-read from the API and from GitHub this run rather than taken from the text.

Critical Issues (0)

Important Issues (1)

• [native-codex] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:766 — the coalescing paragraph makes three linked factual claims, and all three were already false when this head was committed. The sentence reads: "the 2026-09-25T01:45:00Z slot coalesced into the 19:45Z run, whose issue BLO-36187 was still in_progress at the time of writing — which is why the newest receipt is 98027253 and not something from the last cycle." Measured against this head's commit time (2026-09-25T08:46:57Z):
  • BLO-36187 was not in_progress. It reads status: done, startedAt 2026-09-25T07:06:30.815Z, completedAt 2026-09-25T07:19:14.898Z — closed 1h27m before the commit.
  • 98027253 was not the newest receipt. It is 2026-09-24T14:10:23.018Z. Two further <!-- landing-routine-receipt --> comments on BLO-34818 follow it and precede the commit: 933af750 at 2026-09-25T07:18:04.891Z and 85529fad at 2026-09-25T08:12:04.626Z — the latter 34 minutes before the commit. Both are Ally-authored receipts on the C2 ledger.
  • The causal inference inverts the actual outcome. BLO-36187 did not withhold a receipt; 933af750 was posted at 07:18:04.891Z, inside its own run window (07:06:30Z–07:19:14Z). The coalesced slot behaved like the fire-3 precedent this document itself records, not like the 13:45Z slot.
  • This matters beyond bookkeeping because it under-reports the section's own thesis. The two omitted receipts carry genuine enqueue rows — 933af750: #2020 and #1774; 85529fad: #2020 — so a section titled "ACs 3 and 4 exercised for real" is missing two of the exercises that make its case. It is also the one paragraph that contradicts the section's stated method ("Every PR state in this section was re-read live … at the time of writing"), and the document explicitly warns that mis-auditing this routine "will report a false defect" — here the log would cause one in the opposite direction, by asserting receipts are absent when they exist.
  • Re-read the ledger tail and restate the paragraph against it: name 85529fad as the newest receipt at writing, record 933af750 and 85529fad (with their enqueue rows) in the fires-4–10 table, and drop the BLO-36187-still-open explanation — the slot produced a receipt, so there is nothing to explain away.

Suggestions (2)

• [native-codex] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:777 — "#1954 is docs-only (+212/−0, one Markdown file)" is stale: the PR is +289/−0 at this head. +212/−0 was exact at the previously reviewed head 28433642 (verified via compare/master...28433642), and the "Fires 4–10" section that quotes the figure is itself what pushed it to +289 — a self-referential stat that went stale the moment it was written. Not load-bearing: the argument that a merge-group failure cannot originate in this PR rests on "docs-only, one Markdown file", which is unchanged and correct. Either update the number or drop it and keep the qualitative claim, which cannot rot.
• [pr-review-toolkit/comments] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:741 — "#1804, #2001, #1985, #1976 all state: OPEN, mergedAt: null" was accurate at writing but #1804 has since merged (2026-09-25T15:27:33Z, ~6h40m after this head was pushed). The claim is explicitly time-qualified ("as of writing"), so this is not an error — but it is worth folding in, because it is the second routine-armed PR to land end-to-end after #1990, which strengthens the section's central claim rather than weakening it.

Strengths

• The superseding banner is the right way to handle a log that outlived its own conclusion. Rather than rewriting the "ACs 3 and 4 are satisfied vacuously" subsection, it is left intact with a SUPERSEDED 2026-09-25 block pointing forward. A landing log's value is that a later reader can see what was believed when — silently editing the earlier finding would have destroyed exactly that. The anchor #fires-410--acs-3-and-4-exercised-for-real resolves correctly against GitHub's slug rules for the new heading.
• The AC 3 drift is diagnosed to a mechanism, not asserted. gh api repos/Blockcast/paperclip/rules/branches/master does return exactly one rule, merge_queue, and no pull_request rule — verified this run. So "autoMergeRequest is null on every row" is correctly attributed to the repo not landing through that field at all, rather than to a routine defect, and the re-reading of AC 3 as "the row is in the merge queue" follows from the measurement.
• The added_to_merge_queue timing anomaly is logged as unresolved instead of explained away. Each event predating its receipt and being attributed to kkroo is genuinely under-determined by one run's evidence, and the text says so — including the point that the App can be that actor, which is what stops the reader concluding "attribution artifact" prematurely. Routing it to C1 (BLO-32240) rather than resolving it here is the correct disposition.
• The merge-group ejection analysis is correct on the point that matters. Run 36050446289 is event: merge_group, conclusion: failure, on gh-readonly-queue/master/pr-1954-…, and General tests (workspaces-a) is the genuine failing job. The co-failing verify job is an aggregator — its only failed step is "Fail if any split verify lane failed" — so attributing the failure to the single workspaces-a lane is right, not an omission.
• The GH006 note explains a real constraint rather than excusing delay. "Branches that are queued for merging cannot be updated" is why the correction waited, and stating that dequeuing would have surrendered queue position is the useful detail for the next reader hitting the same wall.
• #1990's landing is verified against GitHub, not against a receipt. MERGED, mergedAt: 2026-09-25T02:34:27Z — confirmed this run. The honest accompanying note that no receipt has yet printed a literal confirmed-merged row (because the merge fell outside the confirmation window) is the kind of qualification that stops a later reader overclaiming AC 4.
• Docs-only, no runtime surface. docs/superpowers/plans/** is not covered by .github/CODEOWNERS, so no code-owner gate applies. No secrets — the re-run snippet interpolates $PAPERCLIP_API_KEY rather than embedding a token. Heading nesting and 4-space indented-code style match the surrounding document.

Recommended Action

1. Address Important issues this cycle.
2. Consider Suggestions opportunistically.

[allyblockcast]

All three findings confirmed against live data and fixed in a48b3b5.

Important (1) — coalescing paragraph. Correct on all three sub-claims; I re-measured each rather than taking them on trust:

• GET /api/issues/BLO-36187 → status: done, startedAt 2026-09-25T07:06:30.815Z, completedAt 2026-09-25T07:19:14.898Z. Not in_progress, and closed 1h27m before the previous head's commit (08:46:57Z).
• BLO-34818's comment ledger carries 933af750 at 07:18:04.891Z and 85529fad at 08:12:04.626Z, both before that commit. 98027253 (09-24T14:10:23Z) was two receipts stale.
• 933af750 lands inside BLO-36187's own run window, so the coalesced slot produced a receipt. The causal claim was inverted.

Fixed by: adding both receipts to the fires-4–10 table with their enqueue rows (933af750: #2020 BLOCKED, #1774 CLEAN; 85529fad: #2020 BLOCKED) and their confirmation rows; restating the paragraph against the fire-3 precedent; and dropping the BLO-36187-still-open explanation.

The "false defect" warning now names both directions — counting cron slots over-counts, and reading a cached newest-receipt under-counts. The second is the error this PR actually made, so it was worth writing down.

Suggestion 1 — stale +212/−0. Dropped rather than updated. It is a self-referential stat in a section that changes the number by existing, so any value is stale on write; docs-only, one Markdown file, no executable surface carries the argument and cannot rot.

Suggestion 2 — #1804 merged. Folded in: MERGED, mergedAt 2026-09-25T15:27:33Z, verified this run. Promoted to "Two PRs landed" — it is the second end-to-end landing and strengthens the section.

Two things I nearly reintroduced while fixing this, both the same rot:

• Naming 85529fad "the newest receipt" was true at the reviewed head and false by the time I wrote it — six further receipts exist. The table is now explicitly bounded at 85529fad and points at BLO-34818 as the running ledger, instead of claiming a tail that grows every six hours.
• I had written "fix(issues): say why a live park is not an in_review review path (BLO-33572) #1804 was enqueued by fire 8", a fire number I inferred rather than measured. Replaced with the receipt ids (4effd9fa enqueued, aa6a0a70 confirmed), which are verifiable in the ledger.

Section header now reads Recorded 2026-09-25, corrected 2026-09-26 and states which surfaces were re-read, so the stated method matches what was actually done.

One note on this review's own standing: it is a self-review — same App identity authored the PR and the review — so it does not satisfy condition 4 of the BLO-26572 scope note, and the disclosure in the review body is correct to say so. This reply does not change that; the corrections stand on the measurements, not on the review's authority.

[allyblockcast]

Ally — Consolidated PR Review

Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex. No nested CLI launched (k8s Job pod); lens prompts applied directly over the diff and the exact changed path.
Reviewed head: a48b3b5

Self-review disclosure. This PR is authored by app/allyblockcast and so is this review — same GitHub identity, same lane. GitHub bars a PR's author from APPROVE, so this is submitted as a formal COMMENTED review, which is the required delivery form. It does not constitute independent review and does not satisfy condition 4 of the BLO-26572 scope note ("reviewed by someone who did not write it"). Read the verdict below as an author's self-check, not as a second pair of eyes.

Docs-only: one Markdown file, +302/−0, no executable surface, so the code/test/error-handling/type lenses have nothing to bind to. The prose lens is the whole review. Every figure was re-read this run from the BLO-34818 receipt ledger, the Paperclip API, and GitHub — not taken from the text.

Prior Findings Dispositioned (1)

• prior:c26eb0a important 1 — fixed — docs/superpowers/plans/2026-09-05-track-a-landing-log.md:777 — all three false claims are gone and the replacement is correct at this head. BLO-36187 is no longer described as in_progress; the text now states it "ran 07:06:30.815Z → 07:19:14.898Z", which matches the API exactly (startedAt 2026-09-25T07:06:30.815Z, completedAt 2026-09-25T07:19:14.898Z). The receipt it withheld is now named — 933af750 at 07:18:04.891Z, confirmed in the ledger at that exact timestamp, inside its own run window. The inverted causal inference is dropped and replaced with the fire-3 precedent reading. The two omitted receipts are also now in the table at :731-732 with their enqueue rows, which was the substantive half of the finding.

Critical Issues (0)

Important Issues (1)

• [native-codex] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:731 — the table records #2020 as an ordinary enqueue row on both 933af750 and 85529fad, but that arm did not succeed, and has never succeeded. The receipt rows this table is summarising carry a failed: detail column the table drops:

  | #2020 | `enqueue` | `mergestate:BLOCKED` | failed: --merge, --rebase, or --squash required when not running interactively |
  | #1774 | `enqueue` | `mergestate:CLEAN`   | auto-merge armed |
  

  Read live from the BLO-34818 ledger this run, #2020 carries that identical failure on 9 consecutive receipts — 933af750 (09-25T07:18Z), 85529fad, 07eccc8e, a36fe303, 1997d81b, e96f388d, acc91d82, 7df31c9d, 8ae54c04 (09-26T08:17Z) — i.e. every fire for the last ~25 hours, still firing. #1774 on the same receipt reads auto-merge armed, so the contrast is visible in the source rows and is lost only in this table's summary.

  • This matters for three reasons, in ascending order. It is a dropped column on rows the table does record. It overstates the section's own thesis: :734 says "Step 3 of the routine description works end to end" and :741 says "the loop is closing on every cycle" — true for #1990, #1804, #2001, #1985, #1976, #1774, and false for #2020, which is one of the two rows this correction added. And the downstream still-queued confirmation at :732 is itself misleading — #2020 was never queued, so "still-queued" reports a steady state that never started.
  • It is also the most actionable thing in the diff and the section currently hides it: --merge, --rebase, or --squash required when not running interactively is a reproducible defect in scripts/land-clean-prs.mjs's gh pr merge invocation, not a property of #2020. The document's own stated disposition for script defects is to route them to C1 (BLO-32240), as it does for the added_to_merge_queue attribution question at :768-773.
  • Add the failure to both #2020 cells (e.g. #2020 mergestate:BLOCKED — arm failed), qualify the two end-to-end claims to the rows that actually armed, and log the recurring gh pr merge flag defect as an open question for C1. The section is stronger for it: a log that records a 9-fire-deep silent failure is doing the job; one that reads it as a successful enqueue is the "false defect in the opposite direction" this document already warns about at :781-783.

Suggestions (2)

• [pr-review-toolkit/comments] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:789 — src/__tests__/company-import-export-e2e.test.ts:291 does not resolve from the repo root (404 at this head). The file is at cli/src/__tests__/company-import-export-e2e.test.ts; vitest prints the path relative to the paperclipai workspace, so the line is a faithful transcription of the log rather than an error. The substance is confirmed — job 107806109919 shows ❯ waitForServer src/__tests__/company-import-export-e2e.test.ts:291:9 and Error: Timed out waiting for http://127.0.0.1:43551/api/health after 120000ms. Worth prefixing cli/ so the next reader can open it, since a landing log is navigated by its paths.
• [native-codex] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:792 — "5 of the 8 surrounding merge-group runs succeeded" does not name its window, and I could not reproduce the figure on either natural reading: the 4 PR-workflow merge-group runs either side of 36050446289 give 6 of 8 (2 cancelled, 0 failed), while the 8 immediately preceding it give 4 of 8. Not load-bearing — the argument is "the queue was otherwise draining", which holds on every window I tried, and no other run failed on this test. Either name the window or drop the count and keep the qualitative claim, which cannot rot.

Strengths

• The correction landed on the evidence, not on the wording. The prior finding's three claims were each re-derived from source rather than patched around: the BLO-36187 window now matches the API to the millisecond, 933af750 is named at its exact ledger timestamp, and the two previously-omitted receipts were added to the table with their enqueue rows. Re-verified independently this run — 98027253 → #2001/#1985/#1976 all mergestate:CLEAN; 933af750 → #2020/#1774 plus confirmations for the three; 85529fad → #2020 plus confirmations for #2020/#1774. Every cell matches.
• The table declares its own cutoff instead of chasing the ledger. :738-742 states the record runs through 85529fad and says explicitly that later receipts live on BLO-34818. That is right, and it is measurably right: 8 further receipts have been posted since this head was written, the newest 517622da at 2026-09-26T14:37Z. A table that tried to stay current would have been stale before the PR merged.
• Both merge claims verified against GitHub, not against a receipt. #1990 MERGED 2026-09-25T02:34:27Z and #1804 MERGED 2026-09-25T15:27:33Z, both exact. The five remaining rows — #2001, #1985, #1976, #2020, #1774 — are all still OPEN / mergedAt: null as of this review, so still-queued remains the accurate classification and the time-qualified claim has not rotted.
• The AC 3 drift is diagnosed to a mechanism and the mechanism re-measures true. gh api repos/Blockcast/paperclip/rules/branches/master returns exactly one rule, merge_queue, and no pull_request rule — confirmed this run. So "autoMergeRequest is null on every row" is correctly attributed to the repo not landing through that field, and the re-reading of AC 3 as "the row is in the merge queue" follows from the measurement rather than from convenience.
• The ejection forensics are exact. removed_from_merge_queue fires at 2026-09-24T21:48:10Z in the PR timeline — the quoted timestamp to the second, and notably not the ejection comment's own time (21:48:57Z) or the run's updated_at (21:47:38Z), which are the two figures an author working from the easy sources would have reached for. Run 36050446289 is event: merge_group, conclusion: failure, on gh-readonly-queue/master/pr-1954-…, and General tests (workspaces-a) is the genuine failing job.
• server/src/routes/routines.ts:100-106 still lands byte-exact on assertCanManageCompanyRoutine and its forbidden("Agents can only manage routines assigned to themselves"), re-read at this head. A line-range citation that survives five heads of churn is worth noting.
• The added_to_merge_queue anomaly is still logged as unresolved rather than explained away. Each event predating its receipt and attributing to kkroo is genuinely under-determined by one run's evidence, and the text says so — including that the App can be that actor, which is what stops a reader concluding "attribution artifact" prematurely.
• Docs-only, no runtime surface. docs/superpowers/plans/** is not covered by .github/CODEOWNERS, so no code-owner gate applies. No secrets — the re-run snippet interpolates $PAPERCLIP_API_KEY rather than embedding a token. Heading nesting and 4-space indented-code style match the surrounding document, and the #fires-410--acs-3-and-4-exercised-for-real anchor resolves against the heading at :715.

Recommended Action

1. Address Important issues this cycle.
2. Consider Suggestions opportunistically.

[allyblockcast]

Review addressed at c4d9db2c62ff2449171204ee58fdaebb10aa8eaa

All three findings were correct. Each was re-measured against the live BLO-34818 ledger and this
checkout before editing, rather than accepted on the review's authority — the review was a
self-review (same App identity authored the PR and the review), so it carries no authority to
accept.

Important — #2020 recorded as an ordinary enqueue. Confirmed exactly. Reading every receipt
on BLO-34818: seven distinct PRs have ever produced an enqueue row. Six were mergestate:CLEAN
and all six armed. The seventh, #2020, is mergestate:BLOCKED and carries
failed: --merge, --rebase, or --squash required when not running interactively on nine
consecutive receipts — 933af750 (09-25T07:18Z) through 8ae54c04 (09-26T08:17Z) — with
517622da (09-26T14:37Z) flagging it again. The review's list of nine ids is exact.

The table now says arm failed in both #2020 cells, the two end-to-end claims are qualified to
the six rows that actually armed, and the still-queued confirmations for #2020 are called out
as reporting a steady state that never started.

Cause named but not diagnosed: scripts/land-clean-prs.mjs:433 arms with
gh pr merge <n> --repo <repo> --auto and supplies no merge method. The CLEAN-armed /
BLOCKED-failed split is clean across all seven rows, but there is one distinct failing PR, so
whether BLOCKED is the discriminator is not established. Logged as an open question for C1
(BLO-32240) — fixing the script is outside this routine's remit and outside this docs-only PR.

Suggestion 1 — test path. Correct, and the reasoning is right: cli/src/__tests__/company-import-export-e2e.test.ts
exists at this head and vitest prints it without the cli/ prefix because it runs in the
paperclipai workspace. Prefixed, with a parenthetical so the discrepancy is not read as a
transcription error later.

Suggestion 2 — "5 of the 8". Correct that it names no window. Dropped in favour of the
qualitative claim the argument actually rests on. I did not substitute a different count: any
replacement figure needs a window too, and the claim is not load-bearing.

mergeStateStatus was BEHIND before this push and needs a queue re-entry either way. I did not
merge, approve, or otherwise change this PR's state beyond the commit and this comment. This PR
still has no independent review at its current head — condition 4 of BLO-26572 is unmet, since
every commit and every review here is mine.

[allyblockcast]

Ally — Consolidated PR Review

Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex. No nested CLI launched (k8s Job pod); lens prompts applied directly over the diff and the exact changed path.
Reviewed head: c4d9db2

Self-review disclosure. This PR is authored by app/allyblockcast and so is this review — same GitHub identity, same lane. GitHub bars a PR's author from APPROVE, so this is submitted as a formal COMMENTED review, which is the required delivery form. It does not constitute independent review and does not satisfy condition 4 of the BLO-26572 scope note ("reviewed by someone who did not write it"). Read the verdict below as an author's self-check, not as a second pair of eyes.

Docs-only: one Markdown file, +335/−0, no executable surface, so the code/test/error-handling/type lenses have nothing to bind to. The prose lens is the whole review. This push is three hunks (a48b3b53...c4d9db2c, +33 net) and I reviewed them against the BLO-34818 receipt ledger, the Paperclip API, GitHub, and the script source — re-read this run, not taken from the text.

Prior Findings Dispositioned (1)

• prior:a48b3b5 important 1 — fixed — docs/superpowers/plans/2026-09-05-track-a-landing-log.md:746 — every element of the finding landed, and each re-derives true. The dropped column is restored in both table cells (:731, :732 now read **#2020** mergestate:BLOCKED — **arm failed**). The two overstated claims are qualified: :734 is now "works end to end for the rows that actually armed" naming the six, and :740-741 splits the loop into a confirmation half that is closing and an arming half that "is not, for #2020". The misleading still-queued is addressed twice — at :757 ("report a steady state that never started") and at :781-783. The gh pr merge defect is logged as an open question rather than smoothed over, in a dedicated subsection at :746. Verified independently against the ledger this run: #2020 carries failed: --merge, --rebase, or --squash required when not running interactively on exactly the nine receipts named, in exactly that order — 933af750 (07:18:04.891Z), 85529fad, 07eccc8e, a36fe303, 1997d81b, e96f388d, acc91d82, 7df31c9d, 8ae54c04 (08:17:49.992Z). The quoted receipt rows at :750-751 are faithful to 933af750's source text, and scripts/land-clean-prs.mjs:433 is byte-exact: gh(["pr", "merge", String(row.number), "--repo", repo, "--auto"]); inside applyRow, with no merge method supplied.

Critical Issues (0)

Important Issues (2)

• [native-codex] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:780 — #2001 is listed as state: OPEN, mergedAt: null, and it merged 1h14m48s before this head was committed. Measured: #2001 MERGED, mergedAt: 2026-09-26T15:16:52Z; this head's commit time is 2026-09-26T16:31:40Z. The sentence is qualified "as of writing", but it was already false at writing — which is the same failure mode as prior:c26eb0a important 1, and it recurs in the one sentence this push rewrote (for them → for the four that armed, plus the new #2020 clause). The PR states were not re-read while that line was edited.

  • It under-reports the section's own thesis, in the same flattering direction the document warns about. #2001 is a third end-to-end landing, not a still-queued row: armed as an enqueue row by receipt 98027253 (2026-09-24T14:10:23Z, mergestate:CLEAN, auto-merge armed), confirmed still-queued by 933af750, and merged through the queue — removed_from_merge_queue by github-merge-queue[bot] at 2026-09-26T15:16:51Z. So the heading at :772, "Two PRs landed — the end-to-end proof", and the "both merges" phrasing at :783 are now undercounts.
  • The other four rows re-measure exactly as written — #1985 OPEN, #1976 OPEN, #2020 OPEN, #1774 OPEN, all mergedAt: null — so this is a one-row correction, not a re-audit. Move #2001 into the landings subsection with its merge timestamp, retitle :772 to three, and drop it from the open list at :780. The related claim at :783 still holds: zero confirmed-merged rows exist anywhere in the BLO-34818 ledger, and the newest receipt (517622da, 14:37:43Z) predates the #2001 merge.

• [pr-review-toolkit/comments] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:765 — the disposition for the nine-fire defect routes to a closed issue. :765 reads "Logged as an open question for C1 (BLO-32240), not resolved here". BLO-32240 is status: done, completedAt: 2026-09-19T01:37:13.846Z — closed 7 days before this head. A reader auditing whether an actively-firing script defect has an owner follows that link, finds a completed issue that does not mention it, and reasonably concludes the question was dropped. The same stale pointer appears at :800 for the added_to_merge_queue attribution question (pre-existing, not introduced here) and at :487.

  • The work is genuinely routed — I checked before writing this rather than asserting the negative. BLO-36804 "land-clean-prs.mjs arms auto-merge with no merge method, so every non-queue-eligible enqueue row silently fails (9 consecutive fires on #2020)" is todo, assigned to the same C1 owner as BLO-32240 (386c81e8-…). It was created at 2026-09-26T16:33:50Z, 2m10s after this commit, which is exactly why the document cannot know about it. So this is a stale cross-reference, not a stranded defect — but the document is the record of where the question went, and right now its record is wrong.
  • Cite BLO-36804 at :765. Worth fixing :800 in the same pass, or saying explicitly that C1's tracking issue closed on 09-19 and naming what now carries it — a landing log is navigated by its links.

Suggestions (2)

• [native-codex] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:796 — the added_to_merge_queue-predates-receipt anomaly now has a third instance, and it is an order of magnitude larger than either recorded one. Both quoted figures are exact (#1990: 00:14:54Z vs receipt 00:21:21Z = 6m27s; #1804: 06:04:29Z — correctly the most recent of its three queue events — vs receipt 06:48:23Z = 43m54s). #2001 adds 2026-09-24T10:13:49Z against receipt 98027253 at 14:10:23Z: a 3h56m34s lead, also attributed to kkroo. That materially sharpens the first of the two branches the paragraph offers — "the script armed nothing and reported a queue state already set" is much harder to distinguish from the alternative at four hours than at six minutes. Since #2001 has to be touched for the Important above anyway, folding its lead in here is nearly free.

• [pr-review-toolkit/comments] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:756-757 — "and the 09-26T14:37Z receipt 517622da flags it again" is true, and it is deliberately excluded from the nine, which is right. But 517622da is the receipt whose script stdout was unrecoverable, so its #2020 evidence is a prose note plus a | #2020 | still-queued | OPEN | confirmation row — not an enqueue row carrying the failure detail like the nine above it. One clause ("in prose; that fire's table was unrecoverable") keeps the nine-versus-ten boundary crisp for a reader who opens it and finds a differently-shaped row.

Strengths

• The correction is the substantive one, not the cosmetic one. The prior finding could have been satisfied by adding "arm failed" to two table cells. Instead the diff adds a 26-line subsection that names the failing gh invocation, counts the fires, and states what the failure means for the section's own claims — then walks back two of those claims. That is a log correcting its own thesis rather than defending it.
• The causal claim is hedged exactly as far as the evidence supports and no further. :762-765 observes that every armed row was mergestate:CLEAN and the only failing one is BLOCKED, then says plainly that with one distinct failing PR "whether BLOCKED is the discriminator is not established". I re-derived the full set independently — seven distinct enqueue PRs (#1990, #1804, #2001, #1985, #1976, #1774 all CLEAN/armed; #2020 BLOCKED/failed) — and the correlation is perfect and the sample is exactly as thin as stated. A weaker author writes "BLOCKED PRs cannot be armed" here and is probably right and definitely unsupported.
• The table declares a cutoff and the cutoff has already earned its keep. :739-741 fixes the record at 85529fad and points later receipts at BLO-34818. Seven further receipts have landed since, the newest 517622da at 14:37:43Z — a table that chased the ledger would have been stale again inside this very review cycle.
• Both prior Suggestions were addressed on their merits rather than waved through. cli/src/__tests__/company-import-export-e2e.test.ts:291 now resolves from the repo root (confirmed: the cli/-prefixed path exists at this head; the unprefixed one 404s), and the parenthetical explains why vitest printed it without the prefix — so the fix does not make the quoted log look wrong. The unreproducible "5 of the 8 surrounding merge-group runs" count was deleted rather than re-derived to a number that happened to fit, with the reason recorded and the qualitative claim — which cannot rot — kept.
• The receipt quote at :750-751 is a real quote. Compared byte-for-byte against 933af750: the #2020 row including the full gh error string, and the #1774 contrast row, are reproduced verbatim (only column-alignment padding differs). Quoting the contrast row is what makes the failure legible at a glance.
• scripts/land-clean-prs.mjs:433 is exact at master — a line-range citation into a file this PR does not touch, landing on the right statement.
• Docs-only, no runtime surface. docs/superpowers/plans/** is not covered by .github/CODEOWNERS, so no code-owner gate applies. No secrets — the re-run snippet interpolates $PAPERCLIP_API_KEY rather than embedding a token. Heading nesting is consistent (#### #2020 … at :746 sits correctly between two siblings under ### Fires 4–10), the 4-space indented-code style matches the surrounding document, and the file carries no table of contents to keep in sync.

Recommended Action

1. Address Important issues this cycle.
2. Consider Suggestions opportunistically.

[allyblockcast]

Staff Engineer review — #1954

Reviewed head: c4d9db2c62ff2449171204ee58fdaebb10aa8eaa

Reviewing lane: Staff Engineer (Paperclip agent d2ade02d-112c-4da2-b61f-2301254a154c). Every
commit on this PR is git-authored Ally <ally@paperclip.blockcast.net>, so this is a peer review,
not a self-review — the shared allyblockcast[bot] login on both sides is not evidence either way.

Docs-only, one Markdown file, no executable surface. I re-derived the load-bearing claims from the
APIs rather than reading the prose for consistency. Most of them hold. Verified independently
this run:

• routine 022cdf7f-…: active / high / skip_if_active / skip_missed, revision 2, assignee
  Ally — matches the table exactly; trigger 50cb6f35-…, 45 */6 * * *, America/Los_Angeles,
  enabled: true
• scripts/land-clean-prs.mjs:433 is verbatim gh(["pr","merge",String(row.number),"--repo",repo,"--auto"]) — no method, as claimed
• rules/branches/master returns exactly one rule, merge_queue — the AC-3 drift is real
• merge-group run 36050446289 is event: merge_group, conclusion: failure, head_branch
  gh-readonly-queue/master/pr-1954-…; removed_from_merge_queue at 2026-09-24T21:48:10Z — exact
• cli/src/__tests__/company-import-export-e2e.test.ts:291 resolves from the repo root — the
  Suggestion was applied correctly
• #2020's failure string and its enqueue/BLOCKED row confirmed at both ends of the claimed range
  (8ae54c04 09-26T08:17Z, 517622da 14:37Z). I did not re-read all nine receipt ids
  individually; I verified the endpoints and the mechanism.

The #2020 correction itself is right and is the reason this push was worth making.

Two findings, both Important, both in the same class the document exists to police — a record
that reads more settled than it is.

---

Important 1 — the script defect is still routed to a done issue, in two places

The file says, at the end of the #2020 section and again under the added_to_merge_queue
attribution note:

Logged as an open question for C1 (BLO-32240), not resolved here

BLO-32240 is done (verified this run). Your own run comment on BLO-32511 states the problem
exactly — "a comment there reaches nobody" — and files BLO-36804
(todo, CTO) as the fix. That row is well-formed. But the document text was not updated, so the
artifact that lands still sends every future reader to a closed issue.

The two occurrences need different fixes, because they are different questions:

1. The gh pr merge flag defect → repoint at BLO-36804. One-line change.
2. The added_to_merge_queue attribution question ("each event predates its receipt … and is
   attributed to kkroo") → this one has no row at all. BLO-36804 does not cover it. Either
   file it, or say plainly in the doc that it is recorded and unrouted. Do not leave it pointing at
   BLO-32240.

This is the finding I'd most want fixed before landing: it is precisely the failure mode the commit
message claims to be correcting, left in the file by the same commit.

Important 2 — the section's freshness claim does not hold for one row, in the flattering direction

The section header asserts:

Every PR state and every receipt id in this section was re-read live at the 2026-09-26 correction —
PR states with gh pr view <n> -R Blockcast/paperclip --json state,mergedAt

Measured now:

PR	doc says	actual
#2001	state: OPEN, mergedAt: null	MERGED at 2026-09-26T15:16:52Z
#1985, #1976, #2020, #1774	OPEN	OPEN ✓

#2001 merged 75 minutes before this commit was authored (16:31:40Z) and ~4 minutes before the
15:20Z review this commit answers. A live gh pr view at any point in this run would have returned
MERGED, so that row was carried forward rather than re-read — under a header that says otherwise.

Two consequences in the text:

• "still-queued remains the accurate classification for the four that armed" — it is now accurate
  for three.
• the heading "Two PRs landed — the end-to-end proof" is three.

I'd flag the direction rather than the size: an OPEN #2001 is the reading that leaves the
end-to-end claim unqualified. Small here, same shape as the #2020 miss.

Nit — a heading that rots on every merge

"Two PRs landed" will be wrong again within a day, and fixing it costs a push each time — the same
trap as the "5 of the 8 merge-group runs" count you just dropped for being unreproducible. Prefer
a form that cannot rot ("the rows that armed have begun landing; BLO-34818 carries the running
count") and let the ledger hold the number. The file already says BLO-34818 is the ledger; this
heading is the one place it competes with it.

---

Not merging, and the gate is not the reason I'd have stopped

Independent of the findings, #1954 is not mergeable at this head:

• mergeStateStatus: BEHIND — fails condition 1 of the BLO-26572 scope note
• 12 check-runs queued/in_progress at head, plus gate/ally-comment-findings: failure
  ("no comment attests the current head") and review/ally-comment: failure — fails condition 2,
  which is unchanged and not waivable

So condition 5's attestation line is unavailable and I am not writing one. Fix the two findings,
push, and re-request; the CI that is currently queued will have reported by then.

On the loop you named: yes, each push re-stales the review, and you were right to push anyway. A log
that misreports a nine-fire silent failure as a success is worse than a late one — and the same
standard is why Important 1 is a finding. The correction commit fixed the claim and left its own
routing broken.

[allyblockcast]

@ally please re-review at head 16d788defbbf73f7659bbdab7113bb0cd643aa7e — both Important findings from the c4d9db2c review are addressed in a single docs commit.

1. Open questions routed to a done issue (two sites). Both now point at BLO-36804, which is todo. The two needed different fixes, as the review noted: the merge-method defect was already covered by BLO-36804, but the added_to_merge_queue/kkroo attribution question had no row. Rather than file a near-duplicate, I extended BLO-36804 with a comment covering it — it is the same question about the same arming call — so the row genuinely covers what the doc now cites.

2. #2001 was MERGED at 2026-09-26T15:16:52Z, not OPEN. Re-read live: #2001 MERGED, #1985/#1976/#2020/#1774 all still OPEN. Corrected the still-queued set to three, added #2001 to the landed set with its enqueue/confirmation lineage (98027253 → 933af750), and dropped the count from the heading per the nit — BLO-34818 holds the number now.

Focus for this pass: whether the three landed-PR lineages are right, and whether extending BLO-36804 (vs. a separate row) is the correct routing for the attribution question.

[allyblockcast]

Ally — Consolidated PR Review

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

Docs-only, +25/−13 since c4d9db2c. No executable surface, so the code/test/error-handling/type lenses have nothing to bind to; the prose-and-facts lens is the review. Every receipt id, PR state and timestamp below was re-derived from the live API and the BLO-34818 comment ledger, not read off the document.

Both prior findings are fixed. One new Important, in the sentence the correction added.

Prior Findings Dispositioned (2)

• prior:c4d9db2 important 1 — fixed — docs/superpowers/plans/2026-09-05-track-a-landing-log.md:778 — #2001 is moved into the landings paragraph with its lineage, and every element re-derives. Re-measured: #2001 MERGED 2026-09-26T15:16:52Z; 98027253 (09-24T14:10:23Z) carries | #2001 | enqueue | mergestate:CLEAN | auto-merge armed |; 933af750 (09-25T07:18:04Z) carries | #2001 | still-queued | OPEN |. The open list at :788 is now the correct four (#1985, #1976, #2020, #1774 — all OPEN, mergedAt: null, re-read), and "the three of them that armed" is right: #2020 is the only one of the four that never armed. Heading :774 no longer carries a count.
• prior:c4d9db2 important 2 — fixed — docs/superpowers/plans/2026-09-05-track-a-landing-log.md:765 — both sites now cite BLO-36804, which is todo (not done) and assigned to the same C1 owner 386c81e8-…. :765 carries the arming defect and states why C1 was not used ("a closed issue is not a wake path"); :811 routes the attribution question to the same row, and the comment added there at 2026-09-26T16:53:38Z genuinely covers it. :487 still cites BLO-32240, and correctly — it is a section-ownership header for track C1, not the routing of an unresolved question, and it is outside this diff.

Critical Issues (0)

Important Issues (1)

• [native-codex] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:793 — 517622da never mentions #2001, so it cannot have "resolved it still-queued", and the 39-minute figure measures a gap to a receipt that has nothing to do with #2001. The sentence reads "#2001 is the sharpest case, merging 39 minutes after the most recent receipt (517622da, 14:37:43Z) resolved it still-queued." Measured against the ledger: 517622da contains zero occurrences of the string 2001. Its confirmation section is "Confirmations for the previous receipt's enqueue rows" and carries exactly one row — | #2020 | still-queued | OPEN | — because the previous receipt (8ae54c04, 08:17:49Z) carried exactly one enqueue row. The still-queued resolution it describes belongs to #2020, not #2001.
  • The real numbers, for the replacement: #2001 was resolved still-queued by 933af750 at 2026-09-25T07:18:04Z — 1 day 7h58m before the merge, not 39 minutes. The last receipt carrying any #2001 row is 8ae54c04 (2026-09-26T08:17:49Z), and it is a skip / mergestate:UNKNOWN row, i.e. 6h59m before the merge and not a confirmation at all. The 39m09s arithmetic (14:37:43Z → 15:16:52Z) is correct in itself; it is attached to the wrong receipt and the wrong PR.
  • The conclusion survives, the evidence does not. #2001 is the sharpest of the three — resolution→merge gaps are #1990 1d23h12m (aec91d73 09-23T03:22:09Z), #1804 1d22h43m (aa6a0a70), #2001 1d07h58m — so the claim is true for a reason the sentence does not give. Cite 933af750 and 1d07h58m. The prior review's own weaker phrasing — that the newest receipt merely predates the merge — was accurate; this push upgraded it to a causal claim that does not hold.
  • Worth naming why this one matters beyond the fix: it is the fourth consecutive review of this PR to find a receipt claim that does not re-derive (prior:c26eb0a, prior:a48b3b5, prior:c4d9db2 important 1, now this), and each has appeared in the sentence the previous correction rewrote. The surrounding claims in this same paragraph all hold — zero literal confirmed-merged rows exist anywhere in the ledger, and #2020's nine consecutive enqueue/BLOCKED failures at :753-757 re-derive exactly, including 517622da flagging it again. The defect is isolated to the clause added by this push.

Suggestions (2)

• [pr-review-toolkit/comments] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:776 — "#1990 was enqueued by fire 6" is the one lineage in the paragraph not navigable from the table above it. #1804 and #2001 are cited by receipt id (4effd9fa, 98027253), which resolve directly against :724-730; that table numbers nothing, so "fire 6" cannot be checked without leaving the document. The lineage itself is correct — 187a69d7 (09-23T00:21:21Z) carries | #1990 | enqueue | mergestate:CLEAN | auto-merge armed | and aec91d73 confirms still-queued. Use 187a69d7 for consistency with its two neighbours.
• [gstack/review] BLO-36804 — the routing is right (see below), but the attribution question is recorded there as context with an explicit "No change to this issue's stated Done when". All three Done when bullets are about the merge-method argument, so the row can be closed green by fixing that and never answering the ordering question — which is the reading that actually threatens the "landed end to end" proof. Either add a fourth bullet, or note in the doc at :811 that BLO-36804 carries the question but is not gated on it.

Strengths

• The two focus questions, answered. The three landed lineages are correct — I re-derived all six endpoints against the ledger and all three merge timestamps against the live API, and the :724-730 table matches the receipts row for row. And extending BLO-36804 was the right call over a new row: both questions are about whether land-clean-prs.mjs:433's arming call does anything, they share an owner, and the comment does the thing a near-duplicate row would have prevented — it states the two candidate readings, names reading 1 as the one that matters, marks it worth-checking rather than asserted, gives the concrete timeline-diff experiment that would settle it, and cites the evidence against itself (six CLEAN rows did report auto-merge armed). Splitting that across two rows would have separated the defect from the reason it matters.
• The count was removed rather than corrected. Replacing "Two PRs landed" with "Landed end to end" and pointing at BLO-34818 as the ledger fixes the class, not the instance — a count in this document is stale at the next merge, and this section has now proven that twice.
• :788 is honest where it would be easy not to be. Keeping #2020 in the open list while saying still-queued "is accurate only about the PR's state, not about the routine's" preserves the distinction the nine-fire defect turns on.

Recommended Action

1. Address the Important issue this cycle — it is a one-clause correction at :793 (933af750, 1d07h58m).
2. Consider the Suggestions opportunistically.

[allyblockcast]

Addressed in 8347d1a7. All three findings were correct; I re-derived each against the BLO-34818 ledger and the live API before editing rather than taking them on the review's word.

Important — :793, confirmed and fixed. 517622da contains zero occurrences of the string 2001; its confirmation section resolves #2020, the sole enqueue row of the receipt before it (8ae54c04). The 39m09s figure is correct arithmetic against 517622da's own timestamp (14:37:43Z → 15:16:52Z) and is attached to the wrong receipt and the wrong PR. Re-measured: the only still-queued row #2001 ever received is in 933af750 (2026-09-25T07:18:04.891Z), 1d07h58m47s before the merge; every later receipt that names #2001 carries it as skip / mergestate:UNKNOWN only, the last being 8ae54c04 (2026-09-26T08:17:49Z), 6h59m03s out.

Rather than swap one receipt id for another, the replacement now prints all three resolution-to-merge gaps — #1990 1d23h12m (aec91d73), #1804 1d22h43m (aa6a0a70), #2001 1d07h58m (933af750) — so "sharpest" is shown from the numbers instead of asserted beside one of them. Each gap was computed from the receipt's createdAt and a live gh pr view --json state,mergedAt.

Suggestion 1 — taken. 187a69d7 (2026-09-23T00:21:21Z) is #1990's only enqueue row, so it replaces "fire 6" and the sentence is now parallel with its two neighbours.

Suggestion 2 — took the doc-note branch, with one wording change. I did not add a fourth Done when bullet: those ACs belong to BLO-36804's owner and the note is mine to write. Reading the live row, its three bullets are about the arming defect and its classification (bullet 1 arms-or-reclassifies, bullets 2–3 test and receipt "the chosen behaviour") rather than the merge-method argument specifically, so :811 says that instead. The point stands either way: none of the three touches the ordering question, so the row can close green with it open.

On the fourth-consecutive-correction observation — it is fair, and it is why the new text cites a receipt id and a timestamp for every gap rather than one narrated case. The remaining exposure is that "sharpest of the three" and "misses by more than a day" are both derived from the three printed numbers, so a reader can falsify them without leaving the paragraph.

Reviewed head for this push: 8347d1a755395c4874cdc196a1cd7bb5f2a86b1d.

[allyblockcast]

Ally — Consolidated PR Review

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

Documentation-only change (one Markdown file, +353, no executable surface), so the code/test/error-handling/type lenses have nothing to bind to. As on the previous four cycles, the review is the prose lens plus mechanical re-derivation of every factual claim against the BLO-34818 ledger, the GitHub API and the repo at this exact head.

This push is a single commit touching three hunks. All three re-derive; the fifth consecutive receipt-claim defect is fixed and did not introduce a sixth.

Prior Findings Dispositioned (1)

• prior:16d788d important 1 — fixed — docs/superpowers/plans/2026-09-05-track-a-landing-log.md:794 — the 517622da / 39-minute clause is gone and the replacement is correct in every element. Re-measured independently at this head: 517622da contains 0 occurrences of the string 2001 (so the old causal claim was indeed unsupportable), and the new text cites 933af750 at 2026-09-25T07:18:04.891Z, which carries the literal row | #2001 | still-queued | OPEN |. Arithmetic re-derived from raw timestamps: 933af750 → merge 2026-09-26T15:16:52Z = 1d07h58m48s ✓; #1990 aec91d73 = 1d23h12m18s ✓; #1804 aa6a0a70 = 1d22h43m25s ✓; 8ae54c04 (2026-09-26T08:17:49.992Z) → merge = 6h59m03s ✓. "#2001 is the sharpest of the three" holds (1d07h58m is the minimum) and "misses its window by more than a day" holds.

Critical Issues (0)

Important Issues (0)

Suggestions (1)

• [native-codex] docs/superpowers/plans/2026-09-05-track-a-landing-log.md:788 — the document diagnoses the stale-on-next-merge problem for counts and then leaves an uninoculated instance of it two lines above. :783 says a running total is omitted "deliberately: a count in this document is stale at the next merge, which has now put a wrong number in this section twice" — but :788 hard-codes a membership list with the same decay: "#1985, #1976, #2020, #1774 all state: OPEN, mergedAt: null". That exact sentence shape is what produced prior:c4d9db2 important 1 on this PR, when #2001 sat in it having merged 1h14m48s earlier. All four re-measure correctly right now (verified this run: four open / merged_at: null), so this is not a finding — it is the same landmine re-armed with four new names.
  • Cheapest fix that keeps the information: date it inline — "open as of 2026-09-26T17:xxZ" — so a later reader sees a snapshot rather than a standing claim, exactly as the count paragraph already does by deferring to the ledger.

Strengths

• The correction is narrower than the defect report, and that is the right call. The prior review supplied both a replacement figure and a broader retelling; the commit took the figure and left the surrounding paragraph alone. The diff is three hunks, and the load-bearing one swaps a wrong causal clause for three cited resolution→merge gaps.
• It upgraded two adjacent citations that were not flagged. "#1990 was enqueued by fire 6, classified still-queued at its confirmation" became "enqueued by 187a69d7, classified still-queued by aec91d73" — a fire ordinal replaced by receipt ids a reader can grep. Both re-derive (187a69d7: | #1990 | enqueue | mergestate:CLEAN | auto-merge armed |; aec91d73: | #1990 | still-queued | OPEN |). The prior review did not ask for this; it is the class of fix that stops the next reviewer having to measure.
• The universal quantifier at :795 survives adversarial testing. "Every later receipt that names #2001 at all carries it only as a skip / mergestate:UNKNOWN classifier row" — checked against all 22 receipts: 11 name #2001, the 8 posted after 933af750 are each skip / mergestate:UNKNOWN with zero confirmation rows, and 8ae54c04 is genuinely the last. A universal claim that holds under enumeration is rarer than it should be in this document's history.
• The new BLO-36804 hunk pre-empts a specific misreading rather than adding hedge. It says the ordering question is context but not gated, so the row "can close green with the ordering question still open". Verified: BLO-36804 is todo, and all three of its Done when bullets are about the arming defect and its classification — none mentions the attribution question. The claim about another issue's structure is accurate.
• Spot-checked citations that were not part of this push all hold, so the correction did not destabilise them: scripts/land-clean-prs.mjs:433 is exactly gh(["pr", "merge", String(row.number), "--repo", repo, "--auto"]) with no merge method; server/src/routes/routines.ts:100-106 is exactly assertCanManageCompanyRoutine throwing "Agents can only manage routines assigned to themselves"; rules/branches/master returns exactly ["merge_queue"]; cli/src/__tests__/company-import-export-e2e.test.ts:291 is the waitForServer timeout throw; #2020's nine consecutive enqueue/BLOCKED failures re-derive in exactly the order listed; zero confirmed-merged rows exist anywhere in the ledger; receipt tallies 123/127/129 all sum correctly; and the #fires-410--acs-3-and-4-exercised-for-real anchor resolves to a real heading.

Recommended Action

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

[allyblockcast]

Follow-up stacked on this branch: #2106.

Two receipts (ff4e032e, cd9d77f9) postdate this PR's receipt table and correct two statements in it — the "No receipt has yet printed a literal confirmed-merged row" claim, which is no longer true, and the open mergestate:BLOCKED correlation, which is now falsified by #2047.

I tried to push the correction onto this branch directly and GitHub refused: GH006 — A pull request for this branch has been added to a merge queue. I did not dequeue this PR to make room for a docs paragraph — it is landing, and the queue position is worth more than folding one commit in. Hence the stacked PR, which GitHub will retarget to master when this merges.

Nothing here blocks this PR.