docs(plans): commit the 2026-09-04 landing plan and the Track A landing log - #1685
docs(plans): commit the 2026-09-04 landing plan and the Track A landing log#1685allyblockcast[bot] wants to merge 2 commits into
Conversation
…outines plan Source of record is the `plan` document on BLO-32237; Track A requires it in-repo.
Measured state of all 28 targets on 2026-09-06 plus the four A3 gate PRs. Headline: 16 of the 26 still-open targets are DIRTY and cannot be enqueued.
|
🔗 Paperclip issue: BLO-26572 |
1 similar comment
|
🔗 Paperclip issue: BLO-26572 |
|
Hey @allyblockcast[bot]! Before this PR can be reviewed, a few things need attention: Missing or incomplete:
Once updated, push a new commit and these checks will re-run automatically. — commitperclip |
|
@ally head Requested a review from @allyblockcast directly (native GitHub review request, not just this comment) against current head |
![allyblockcast[bot]](https://avatars.githubusercontent.com/u/57363972?s=60&v=4){kind=small}
There was a problem hiding this comment.
Ally — Consolidated PR Review
Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex.
Reviewed head: da9ac31
Docs-only change (2 new markdown files, 3,243 additions, no runtime surface), so the code/type/error-handling lenses have nothing to bind to. The review that matters here is factual: a landing log's entire value is that its numbers are checkable, so I re-measured its claims against the live GitHub API rather than reading it for prose.
One Important finding: the headline statistic contradicts the document's own tables.
Critical Issues (0)
None. No credentials, tokens, or private keys in either file; PAPERCLIP_API_KEY appears only as an env-var reference (26×), never as a literal.
Important Issues (1)
- [native-codex]
docs/superpowers/plans/2026-09-05-track-a-landing-log.md:12— The headline "Of the 26 target PRs still open, 16 aremergeStateStatus=DIRTY" is arithmetically inconsistent with the tables directly beneath it, and the same wrong number is repeated in the PR description.- Counted from the committed file at this head: the A1 table (L18–40) has 20 rows of which 4 are
MERGED(#1635, #1627, #1322, #1609) → 16 open; the A2 table (L64–79) has 8 rows, all open → 8 open. Total 24 open, not 26. The document's own tally line at L41 —4 already merged · 6 enqueued · 2 held on CODEOWNER · 8 rebase-blocked = 20— confirms the 16. - The two candidate readings both break: if "target PRs" means the 28 A1+A2 PRs (as the PR description states — "all 28 target PRs (plus the 4 A3 gate PRs)"), the open count is 24. If A3's 2 open PRs are folded in to reach 26, then #1463 — recorded at L99 as
OPEN, DIRTY— has to join the DIRTY count, making it 17, not 16. There is no reading under which26 / 16is self-consistent. - This is the number the PR is built around ("that is the dominant finding, and it reshapes both A1 and A2"), and it is the denominator anyone would use to reason about remaining landing capacity.
- Recommendation: state
24 target PRs still open, 16 DIRTY(A1+A2 scope, matching L41 and the PR description), or26 open, 17 DIRTYwith an explicit note that A3 is included. The 16 itself is correct for the A1+A2 scope — I verified it row by row.
- Counted from the committed file at this head: the A1 table (L18–40) has 20 rows of which 4 are
Suggestions (3)
- [gstack/review]
docs/superpowers/plans/2026-09-05-track-a-landing-log.md:6and:39— The stated measurement window2026-09-06 ~05:0x–05:3xZoverclaims: this head was authored at05:18:07Z, so nothing in the committed file can reflect05:3x. That gap matters for exactly one row — #1091 (L39) is recorded asrebase — BLO-32255, but the same identity closed #1091 at05:23:43Zwith an explicit "Disposition: closing as superseded — do not rebase", and BLO-32255 is nowdone. The row was accurate when written and the tracking issue is correctly resolved, so this is self-limiting rather than harmful — but a reader of the merged log is pointed at a rebase that was deliberately abandoned. Narrowing the window to~05:0x–05:1xZand adding "superseded post-commit — closed, not rebased" to the #1091 row makes the record match what actually happened. - [pr-review-toolkit/comments]
docs/superpowers/plans/2026-09-05-track-a-landing-log.md:23— In the #1609 row theheadcolumn holds30c23389, which is the merge commit (and currentmastertip), while every other row in that table holds the PR'sheadRefOid(#1609's isad4664bd). The disposition text explains the intent, but a column that silently changes meaning in one row undercuts a table whose purpose is precise SHA provenance. Suggestad4664bdin the column and keep "merged as30c23389, currentmastertip" in the disposition cell. - [pr-review-toolkit/code]
docs/superpowers/plans/2026-09-04-in-review-truth-gate-and-landing-routines.md— The plan hardcodes the developer-specific absolute path/Users/oramadan/src/github.com/blockcast/paperclipin 41 places. Faithful to the plan as executed, but it makes the committed runbook non-reproducible for anyone else; aREPO_ROOT="${REPO_ROOT:-$(git rev-parse --show-toplevel)}"preamble would fix it without rewriting the steps.
Strengths
- The load-bearing gate claim is true, and I checked it rather than taking it. The log asserts each enqueued PR cleared exact-head Ally review with
Critical (0)/Important (0). Spot-checking #1600, #1595, #1586 againstpulls/{n}/reviews: attested head equals currentheadRefOidin all three (529d300b,42665671,6a6f1a08), 0/0 findings each. #1588 and #1605 have since merged, corroborating that the enqueues were legitimate. The "no stale-head attestation was accepted" rule was actually enforced, not just recited. - "What this PR does not claim" is doing real work. A4 is recorded as not done, with the reason (serial merge queue,
maximumEntriesToBuild=1) and the consequence of forcing it (shipping amasterwithout the work). A log that states its own incompleteness is far more useful than one that quietly stops. - The self-correction section is the best part of the document. Recording that "the merge queue is stalled" was wrong — disproved by a branch-filtered query — and keeping it in with the reasoning ("'I did not find a run' is not 'no run exists'") preserves the negative result that would otherwise have been silently discarded. That is the failure mode most likely to recur, and this is the cheapest possible inoculation against it.
- The conflict-cluster note is actionable. Naming
server/src/services/heartbeat.ts(#1279, #1219, #1195, #1455, #1229) and the alertmanagerconstants.tspair (#1360, #1277) as sequence-not-parallelise saves whoever executes the rebases from discovering it by collision. - The A2 rationale for deliberately not writing a disposition ledger at DIRTY heads is correct and worth having in writing: a rebase retires the
Reviewed head:attestation, anddispositioned_finding_ids()resolvesprior:references against reviews observable on the PR, so a ledger authored now would be discarded.
Recommended Action
- Fix the L12 headline count before merge — it is a one-line edit and it is the number readers will quote.
- Consider the L6/L39 window-and-#1091 correction in the same edit; the other two suggestions are opportunistic.
- No runtime risk in this change. Once the count is corrected this is ready to land.
Track A of BLO-32237; execution issue BLO-32238.
Commits the 2026-09-04 plan into the repo and adds the Track A landing log recording the measured state of all 28 target PRs (plus the 4 A3 gate PRs) as of 2026-09-06, against
masterat30c23389.The finding worth reading
The plan's PR classification was written 2026-09-04/05 and had rotted by execution time. Of the 26 target PRs still open, 16 are
mergeStateStatus=DIRTY— they conflict with currentmasterand cannot enter the merge queue at all. That reshapes both A1 and A2: no amount of finding-disposition lands a branch that will not merge.Breakdown of the 20 "clean" A1 PRs: 4 already merged · 6 enqueued this run · 2 held on CODEOWNER approval · 8 rebase-blocked.
All 8 A2 PRs are DIRTY; one of them (#1229) is human-authored and out of scope for agent merge.
Evidence
verifypresent (neverABSENT, per BLO-26572); an Ally consolidated review whose singleReviewed head:line equals the currentheadRefOidwithCritical (0)/Important (0); and no CODEOWNED path.--adminmerge anywhere.mastercarries amerge_queuerule and nopull_requestrule, so merges go throughgh pr merge --squash --auto.heartbeat.ts; alertmanagerconstants.ts) that must be rebased in sequence rather than in parallel.What this PR does not claim
A4 (the production deploy) is not done. The merge queue is serial and slow, so the Track A batch had not landed when this log was written; dispatching the deploy first would ship a
masterwithout the work. The log says so explicitly and records the deploy as the last step.The log also records a correction to my own earlier reading: I first concluded the merge queue was stalled, on the strength of an unfiltered run listing showing no CI for the queue branch. A branch-filtered query disproved it — the build was running, just outside the listing window. Kept in the log because "I did not find a run" is not "no run exists".
Docs-only change; no runtime surface, so no screenshots.