skill(reflect): do not apply findings from a fan-out that never returned

[EdbertChan]

Summary

A reflect pass whose lens agents all died on rate limits went straight to the apply step and opened five PRs with zero reviewer output and no grounding gate.

The skill allowed the parent to do the investigation itself when the worktree spawn failed, and said nothing about the reviewers themselves failing.

Step 5 now starts only when the reviewers reported and synthesis ran. A dead fan-out is re-run, staggered or on another model, or the pass is declared partial with the missing lenses named.

Review Claim

reflect refuses to apply findings from a fan-out that never returned, instead of treating unreturned reviewers as reviewers that passed.

Review Lane

docs

Review Unit

docs

Safety Invariant

One paragraph added immediately above the existing apply instruction, in the same voice; no step is removed or reordered, and the existing worktree-failure fallback is untouched.

Slice Rationale

Skill prose is separable from the two mechanical changes in this stack and reverts on its own.

Non-goals

Does not add a mechanical check that reviewers ran, which would be the stronger fix and needs its own slice. Does not change the fan-out itself or how lenses are spawned.

Test Plan

Test Plan

• python3 scripts/check_skill_trigger_mechanism.py --base origin/main — ok
• python3 scripts/check_skill_file_refs.py --base origin/main — ok
• python3 scripts/check_skill_test_coverage.py --base origin/main — ok
• python3 scripts/check_no_dated_provenance.py --base origin/main — ok

Revert Plan

Revert Plan

• Safe to revert? Yes
• Revert command: git revert <sha>
• Post-revert steps: None
• Data migration? No

🤖 Generated with Claude Code

https://claude.ai/code/session_01KU2pPKob4MJ1NqjsfTNyYJ

---

Note

Medium Risk
Changes when reflect may auto-open PRs from Accepted findings; mis-gating could block legitimate applies or still allow partial applies if callers skip the script.

Overview
Reflect step 5 (apply Accepted findings) is gated on a complete lens fan-out. The skill now states that presentation and auto-worktree apply may run only after step 3 reviewers have reported and step 4 synthesis (including the grounding gate) has actually run. A dead or partial fan-out must be re-run, staggered, or explicitly called partial with missing lenses named—not treated as if unreturned lenses passed. The parent substituting for a failed worktree spawn is unchanged; substituting for failed review is not allowed.

A new fanout_complete.py script implements that gate: compare expected vs returned lens names (CLI or JSON manifest), emit complete (exit 0), incomplete with missing lenses (exit 1), or unchecked when no expected set was recorded (exit 2). unchecked is explicitly non-passing so callers cannot treat “unknown” as safe to apply. Unit tests pin verdict logic, exit codes, manifest input, and unexpected lens reporting.

^{Reviewed by Cursor Bugbot for commit 41708da. Bugbot is set up for automated code reviews on this repo. Configure here.}

[EdbertChan]

This pull request is part of a Mergify stack:

#	Pull Request	Link
1	cat-mode: rejoin wrapped prose so the file is back under its own cap	#382
2	hook(diu-stop): scope the unverified marker to its own paragraph	#383
3	skill(reflect): do not apply findings from a fan-out that never returned	#384	👈
4	audit(token_audit): count naming the shortcut, and typing the fix command	#385

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_75a399a5-14d6-4545-881a-20a3c7c89948)

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[EdbertChan]

Mergify repair stopped: GitHub reports merge conflict. The retry cap was reached for current head 54530d6.

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_33311f42-3ec6-4292-84f7-54f6d10992f6)