Renumber the colliding prune decision from LLP 0223 to 0226 (#774)

[philcunliffe]

master carried two documents claiming LLP 0223. This renumbers one of them and sweeps every inbound reference. Nothing else changes.

Which document moved, and why

LLP 0156#renumber settles this: the document that reached master first keeps the number, the later claimant moves.

document	landed	commit
0223-converge-on-applied-config.decision.md	2026-08-13T23:16	348b0ae (PR #770)
0223-prune-direct-children-and-unreadable-assets.decision.md	2026-08-14T10:36	f581e4c (PR #749)

The prune decision is the later claimant, so it becomes LLP 0226. That also happens to be the smaller blast radius by file count (4 files vs 6 for the converge decision), which is what the issue predicted:

	inbound reference lines	files
prune decision (moved)	13	4
converge decision (kept 0223)	7	6

0226 is the next free number: it is above 0225, the highest claimed on origin/master and on every remote branch including origin/integration/bounded-query-execution, and llp-create's convention is max(existing) + 1. (0221 is unclaimed anywhere, but numbers are minted above the maximum, not into gaps.)

This is a rename plus a reference sweep. No content, status, date, anchor, or reasoning changed in either decision - the mechanical edit that CLAUDE.md and LLP 0156 explicitly allow on an Accepted document. The rename is recorded as a rename, so git log --follow still tracks the document.

Every reference updated

• llp/0219-retired-client-assets-are-pruned.decision.md (5): the **Extended-by:** header on line 9, and four body links [LLP 0223](./0223-prune-...) at lines 72, 104, 208, 244.
• test/core/client-assets-prune.test.js (5): @ref LLP 0223#unreadable-is-not-absent [tests] at 398 and 493, @ref LLP 0223#only-direct-children [tests] at 626, 685, 730.
• src/core/runtime/client_assets.js (2): @ref LLP 0223#unreadable-is-not-absent [implements] at 531, @ref LLP 0223#only-direct-children [implements] at 695.
• src/core/runtime/client_asset_ledger.js (1): @ref LLP 0223#unreadable-is-not-absent [implements] at 213.
• The document heading itself: # LLP 0223: becomes # LLP 0226:.

The eight surviving LLP 0223 mentions (in llp/0129, llp/0135, test/core/remote-login-command.test.js, src/core/cli/wizard/join.js, src/core/config/apply.js, src/core/cli/remote_commands.js) all mean the converge decision, which keeps the number. Each was checked by anchor and context, not swept blind.

Evidence

Reproducing check, before:

$ git ls-tree -r origin/master --name-only llp/ | sed -n 's|llp/\([0-9]\{4\}\)-.*|\1|p' | sort | uniq -d
0223

After, on this branch, and the llp-check.yml workflow's own command likewise:

$ git ls-tree -r HEAD --name-only llp/ | sed -n 's|llp/\([0-9]\{4\}\)-.*|\1|p' | sort | uniq -d
(no output)

The named assertion, before:

not ok 7 - no LLP number is claimed by two documents
+ [ 'LLP 223: llp/0223-converge-on-applied-config.decision.md, llp/0223-prune-direct-children-and-unreadable-assets.decision.md' ]
# pass 10 # fail 1

After: test/core/llp-ref-hygiene.test.js is 11/11 green.

Ref-check: every @ref resolves to a live LLP document and one of its anchors and every tolerated reference forgives no more than is still broken both pass in that same file, which is the in-repo enforcement of /ref-check. The #unreadable-is-not-absent and #only-direct-children anchors resolve against the renamed document, and a grep confirms zero references to a 0223-prune-... path remain.

npm test: the sorted failure set is identical to the origin/master baseline minus exactly one line, the duplicate-number assertion (23 failures before, 22 after). The remaining 22 are the known environmental skew in this worktree, 2 report-render* from a missing marked and 20 parquet-pushdown / hyparquet.

npm run typecheck: unchanged from baseline, the same single Cannot find module 'marked' in src/core/reports/render.js.

Not included

The issue floats hardening the duplicate-number check to run against the merge result. llp-check.yml already runs on pull_request, where actions/checkout checks out the merge ref, so the check is against a merge result - just one computed before the sibling PR landed, and a PR is not re-run when its base moves. Closing that gap means either requiring branches to be up to date before merging (a branch-protection setting, not a file in this PR) or checking the new number against every other branch, which would redden PRs over abandoned branches. Neither is a clean, testable change of the size this PR should carry, so it is left out.

Fixes#774

[philcunliffe]

Verdict: clean. Reviewed b8e3606 manually against the review brief (codex is not installed in this environment and the code-review skill is not invocable here, so this is a hand review, not a tool run). No findings. Nothing pushed; head is unchanged at b8e3606.

Reviewed in a detached worktree off origin/fix/issue-774, with origin/master (15cfd2a) checked out separately as the baseline. The merge base is 15cfd2a, which is the current origin/master tip, so the branch is up to date with its base and the diff below is the whole change.

1. Did any decision content change?

No. The moved document is byte-identical to its pre-rename content apart from the first line.

$ diff <(git show origin/master:llp/0223-prune-...md) <(git show b8e3606:llp/0226-prune-...md)
1c1
< # LLP 0223: The prune predicate narrows to direct children, and unreadable is not absent
---
> # LLP 0226: The prune predicate narrows to direct children, and unreadable is not absent

Normalising that one line makes the md5 identical (4bc3145... both sides), so Status: Accepted, Date, Author, Related, both anchor definitions ({#only-direct-children} at line 55, {#unreadable-is-not-absent} at line 83), and every word of reasoning are untouched. Git records it as R099, so git log --follow still tracks the document, which is the consequence LLP 0156 calls out.

The one other document touched, llp/0219-retired-client-assets-are-pruned.decision.md, is also Accepted, and its five changed lines change only the digits 0223 to 0226. Nothing else on those lines differs.

2. Is the right document the one that moved?

Yes. Verified independently of the PR body:

$ git log --follow --format='%H %cI' origin/master -- llp/0223-converge-on-applied-config.decision.md | tail -1
348b0ae... 2026-08-13T23:16:49-07:00 (PR #770)
$ git log --follow --format='%H %cI' origin/master -- llp/0223-prune-...decision.md | tail -1
f581e4c... 2026-08-14T10:36:01-07:00 (PR #749)

The converge decision reached master first, so under LLP 0156 #renumber ("the document that reached master first keeps the number") it keeps 0223 and the prune decision is the later claimant that moves. That is what the PR does.

3. Is 0226 actually free?

Yes, and free by the stricter standard LLP 0156 sets ("above the highest number claimed anywhere, including branches without an open PR"). I enumerated every llp/** numbered filename at any depth across all 47 remote branches, not just top level, because llp/tombstones/ counts for the CI check and a top-level-only glob would miss it:

0220 0222 0223 (x2, the bug) 0224 (x2, see below) 0225 0226 (this branch only)

0225 is the highest claimed anywhere, llp/tombstones/ holds only 0018-0020, and no branch or open PR claims 0226. All 18 open PRs' head branches are present in the fetched remote set, so the scan covers them. The workflow's own command runs clean on the branch:

$ find llp -path llp/reviews -prune -o -type f -name '[0-9][0-9][0-9][0-9]-*.md' -print \
| sed 's|.*/||' | cut -c1-4 | sort | uniq -d
(no output)

4. Are all inbound references repointed, and only the right ones?

Yes, in both directions. I built the reference set on origin/master and on the branch and compared them line by line; they correspond exactly, with only the number differing.

All 13 moved references land where the PR body says: llp/0219 lines 9, 72, 104, 208, 244; test/core/client-assets-prune.test.js lines 398, 493, 626, 685, 730; src/core/runtime/client_assets.js lines 531, 695; src/core/runtime/client_asset_ledger.js line 213.

Nothing was missed. Grepping the branch for the moved document by every shape it could take (0223, prune-direct-children, only-direct-children, unreadable-is-not-absent, and a loose LLP[ -]*0?223 that would catch an unpadded LLP 223) returns zero hits pointing at the old number or the old path.

Nothing was over-swept. All 8 surviving LLP 0223 mentions were checked one at a time by anchor and context, and every one means the converge decision that legitimately keeps the number:

• llp/0129:9 and llp/0135:339 link ./0223-converge-on-applied-config.decision.md by path.
• src/core/cli/remote_commands.js:207 and src/core/config/apply.js:119 are bare @ref LLP 0223 on the applied-slot convergence probe.
• src/core/cli/wizard/join.js:21 and test/core/remote-login-command.test.js:447,474 are prose on waitForCentralConverge.

An org-wide code search (gh search code --owner hyparam "LLP 0223") returns hits in hyparam/hypaware only, so the external-corpus sweep LLP 0156 lists as a consequence has nothing to do here. The moved document is also one day old, which bounds external exposure.

For consistency with precedent, I checked whether the earlier renumbers (0152, 0153, 0154, 0155) added a "formerly LLP NNNN" note to the moved document. None of them did, so this PR's omission of one matches how the repair has always been done.

5. Tests

test/core/llp-ref-hygiene.test.js is 11/11 green on the branch, including the three assertions the brief names:

• ok 2 - every @ref resolves to a live LLP document and one of its anchors
• ok 3 - every tolerated reference forgives no more than is still broken (so the renumber left no stale entry in the tolerance list)
• ok 7 - no LLP number is claimed by two documents

test/core/client-assets-prune.test.js, whose five annotations moved, is 24/24 green.

Full-suite delta against the origin/master baseline, sorted failure sets compared:

• baseline 23 failures, branch 22 failures, out of 4045 tests both sides.
• The only set difference is no LLP number is claimed by two documents, present in the baseline set and absent from the branch set. That is the bug being fixed.
• The remaining 22 are identical on both sides and environmental: 2 report-render* from a missing marked, 20 parquet-pushdown / hyparquet skew.

npm run typecheck: byte-identical error output on both sides, the same single pre-existing src/core/reports/render.js(23,24): error TS2307: Cannot find module 'marked'.

Conventions hold: no em dash (U+2014) anywhere in the diff or the commit message, and the changed lines are comments and markdown, so the semicolon rule is not in play.

Findings

None. This is the clean mechanical renumber it claims to be.

Observations, not findings, for a human

Neither of these is caused by this PR, neither blocks it, and neither should hold up a merge. Both are preference-level notes about the surrounding corpus.

• A second collision is brewing on 0224.origin/master has llp/0224-desktop-setup-second-pass.decision.md, and PR Daemon maintenance skip reasons reach a standing surface (#742) #759 (origin/fix/issue-742) adds a different llp/0224-maintenance-skips-are-a-standing-surface.decision.md. Merging Daemon maintenance skip reasons reach a standing surface (#742) #759 as it stands reproduces exactly the bug Two LLP documents both claim number 0223 on master #774 describes. That is Daemon maintenance skip reasons reach a standing surface (#742) #759's to fix under the same LLP 0156 rule, and fixing it here would be scope creep, but it is worth someone knowing before Daemon maintenance skip reasons reach a standing surface (#742) #759 merges.
• A pre-existing loose reference at src/core/runtime/client_assets.js:316 reads already gone (LLP 0219 #unreadable-is-not-absent), but that anchor is defined in the moved document, not in LLP 0219. It is prose in a comment rather than an @ref annotation, so no checker flags it, and it is unchanged from master. It was already pointing at the wrong document before this PR and still is; the renumber neither creates nor worsens it.

Per the brief, the CI-hardening idea the PR body declares out of scope is not treated as a finding.