fix(#384): the six-pass review no longer approves on absent evidence

[randomm]

Closes #384.

Where this came from

An operator asked whether the six-prong code review had been getting skipped in recent /work runs. Measured answer: it had not. Across every .pi/work-state/*.json in this repo, every cycle that reached lens-review ran lens-review×6, and no cycle recorded a lens-skipped-empty-diff event:

cycle	reached lens-review	skipped	dispatches
208, 282, 286, 312, 318, 327	✅	0	lens-review×6 (round 1)
5, 334, 338, 339, 304	✅	0	up to round 3 + developer:lens-fix-N
277, 279, 305, 308	❌ never got there	—	aborted/handoff before commit-pr

Cycles where the review looks absent aborted earlier. But the question exposed a real hazard, and this PR fixes it.

The hazard

runLens treats an empty diff as approved — correct for a cycle that genuinely changed nothing. The diff came from fetchIntegratedDiff (work-driver-diff.ts:131-149), which swallowed every git error and returned "":

} catch (err) {
  trace(`work-driver: fetchIntegratedDiff(${branchName}) failed: ...`);
  return "";          // <-- indistinguishable from "nothing to review"
}

So a stale origin/<branch> ref, a transient git failure, a maxBuffer overrun on a large diff, or an unset branch name all read as approved, and the code merged unreviewed. Under always-worktree (#287) the fallback read is also empty, so there was no second opinion. Same defect class as the ci-status: substring #380 removed from the merge step: a gate whose no-signal answer is approval is a gate that cannot fail.

This had already bitten twice from the other direction — pre-PR11 the guard fired on every successful cycle (34ms skip → merged unreviewed), and #287 re-introduced it when worktrees went detached. Both were fixed by changing which diff is read. The structural problem was never fixed.

The fix

readIntegratedDiff returns a discriminated result, and empty is established positively: git rev-list --count origin/<base>..origin/<branch> must return 0. Anything else halts with the new cap lens-diff-unreadable, carrying the git error verbatim in pipelineState.lensDiffError.

Situation	Before	After
origin/<branch> missing	approved	halt
git fails / maxBuffer overrun	approved	halt
commits ahead but empty diff	approved	halt
no branch name recorded	approved	halt
0 commits ahead of base	approved	approved (unchanged, now proven)

Two tests were passing for the wrong reason

test-work-driver-pr6.ts and test-work-driver-pr11-lens-diff.ts both claimed to cover the genuine no-work cycle. Neither created refs/remotes/origin/<branch> — so git diff origin/main..origin/<branch> failed with "unknown revision", and they were exercising a git failure the whole time. Both fixtures now create the ref and test what they say they test.

Testing

test-lens-diff-evidence.ts uses real git repositories, not a mocked exec. The bug lives in the gap between what git actually does and what the code assumed it does, and a fake that returns whatever the test wants cannot see that gap — which is precisely how the two fixtures above went years without noticing.

Covers: missing ref, genuine no-work branch, a real diff, commits-with-empty-diff, no branch name, not-a-git-repo. Plus an end-to-end assertion that an unreadable diff produces zero lens-approved events, spawns no lens children, and does not merge.

Restoring the old swallow-and-return-"" behaviour makes six of those assertions fail.

Quality gate

bun run build ✅ · bunx tsc --noEmit ✅ · bun run check ✅ · 78/78 offline smoke tests ✅