Invert fallback-review-panel contract item 7: assume the isolated worktree points at the wrong ref

[topij]

Surfaced in docs/kit-friction-log.md (2026-07-26 and 2026-07-27) and graduated by the triage-friction-log sweep. Severity: H. 9 of 9 across two sessions.

Every review-lens launch landed on main with an empty git diff main...HEAD instead of the PR head:

• 4 of 4 last session (2 lenses × 2 rounds)
• 5 of 5 this session (2 lenses × 2 rounds on #65, plus 1 on #68)

Every single lens detected it and cloned the real target itself — because the launch prompt required them to report the path and diff stat they saw. Contract item 7 says to verify; what actually surfaced it was making the report mandatory output.

Proposed fix

1. Contract item 7 should stop saying "verify" and start saying "assume the worktree is wrong; clone the target yourself first". At 9 of 9 this is no longer a caveat, it is the default behaviour.
2. Promote "state the path reviewed and the diff stat" from advice to a required field of the lens report, and say plainly that a lens which cannot show a non-empty diff has not reviewed anything. A clean pass over an empty diff is indistinguishable from a real one.

[topij]

Supporting data from the third session of 2026-07-27: 8 of 8 lens launches isolated correctly — 2 lenses × 2 rounds on each of #85 and #87 — when the launch prompt already followed this issue's proposed inversion: "assume any worktree you start in is the wrong one; clone the target yourself; report clone path, verified head, and diff stat as required output fields." Every lens cloned, verified the head sha, and reported a non-empty diff stat on the first try. Contrast the 9-of-9 wrong-ref streak this issue records from the prior two sessions, where the prompt said "verify" rather than "assume wrong". The inversion works as predicted.

[topij]

Occurrence data — 2026-07-27, fourth session

Five panel launches across two PRs (#91 round 3, #96 rounds 1–2). The provided worktree was at the base ref, with an empty git diff main...HEAD, on all five. Every lens detected it and established its own copy of the target, because the launch prompt required clone-verify-report and stated the expected head SHA.

Verbatim from the five reports:

• "the worktree I was placed in was a worktree at main (1385b84) — the wrong code"
• "The provided worktree was wrong for the third time"
• "the worktree I was handed was at 1385b84 = base, as warned"
• "the worktree I was placed in was at 1385b84 (main, empty diff) for the third round running"
• "The worktree I was placed in was the wrong one, as warned"

Two details worth adding to this issue beyond the count:

1. Stale clones from earlier rounds accumulate in scratch and are also wrong. Two lenses reported finding clones at e3586b2 and 6193334 — earlier heads of the same branch — and correctly rejected them. A prompt that says only "verify you are in the right repo" is not enough; it has to name the expected head SHA, or a stale clone of the right branch passes.
2. One lens could not clone at all. Its isolation guard blocked git against the shared checkout, so it cloned from GitHub instead. That worked here because the branch was pushed — it would not have on an unpushed branch, and the lens would have had no route to the code.

No cumulative figure offered deliberately. The 8-of-8 recorded on this issue from session 3 counts launches that isolated correctly; the 5 of 5 above counts launches whose provided worktree was wrong. They measure different things and must not be summed — I nearly wrote "13 of 14" into the handoff before a review lens caught it.

[topij]

Occurrence data from the 2026-07-28 triage sweep

The provided worktree was at the base ref on 5 of 5 panel launches in the 2026-07-27 fourth session (main, empty diff). Every lens detected and corrected it, because the launch prompt required clone-verify-report.

Deliberately no cumulative figure

The earlier sessions' "8 of 8" counts launches that isolated correctly. That cannot be added to a count of launches that pointed wrong — they measure opposite outcomes. Recording both separately rather than producing a misleading combined figure.

What both sets support is the same conclusion this issue argues: the correction happens because the contract makes the lens verify, not because the launch is reliable.

---

Generated by Claude Code

[topij]

Occurrence data from the 2026-07-28 triage-friction-log sweep. No new fix proposed.

The panel's worktree pointed at the wrong ref on 2 of 2 launches. Both were detected and
corrected by the lens itself, because the launch prompt required verify-before-review — which is
the property this issue proposes making mandatory output rather than a verify instruction.

Recorded as its own set, deliberately not summed with the 9 of 9 already in this issue. Earlier
sessions counted launches that isolated correctly alongside ones that did not; this is the first
set here where every launch was wrong. Summing a set drawn under different accounting into the
running total would misstate the base rate in the direction that makes the issue look worse, so
the two are kept separate.