overnight-worktree-verification-fallback

name	overnight-worktree-verification-fallback
description	Verify overnight multi-worktree Codex batches when auto-sync, duplicate-lane convergence, and sandbox-blocked review create misleading local state or review provenance.
triggers	["Overnight Codex batch uses fresh worktrees plus auto-sync or hook-driven push behavior","Morning verification shows local worktree HEAD disagrees with origin/main","Two lanes may have converged on the same deterministic implementation","Planning-only worker produced review artifacts but could not run real cross-provider review"]

Overnight worktree verification fallback

Use this after overnight parallel Codex runs in workspace-hub-style repos.

Core problems this skill handles

1. A worker lands a commit on origin/main, but the isolated worktree remains at an older local HEAD.
2. A second worker verifies the same issue and correctly decides not to push because the change already landed elsewhere.
3. A planning-only worker cannot run scripts/review/cross-review.sh due to sandbox permissions, yet still writes review artifacts.
4. Morning verification can be misled by stale local worktrees, empty logs, or self-review artifacts that look like true cross-provider review.

Verification protocol for each overnight lane

1. Check the background process outcome and save the worker's own summary.
2. Verify the canonical repo state, not just the worker worktree:
   • git fetch origin main
   • compare HEAD and origin/main
   • inspect the claimed landed commit on origin/main
3. If the worktree is stale, do not treat stale grep results as proof of failure.
   • verify the landed commit/content from the canonical repo or a fresh checkout
   • only then decide whether the issue truly landed
4. For implementation lanes, confirm all of:
   • commit hash exists on remote main
   • expected content is present
   • issue comment/closeout exists
   • issue state matches the evidence
5. For verification-only duplicate lanes:
   • accept landed-but-blocked or already-landed as a successful outcome if the worker correctly avoided a duplicate push
   • preserve the evidence comment rather than forcing a second implementation

Auto-sync / hook-push gotcha

Some repos auto-push after commit via hooks or sync automation.

Observed failure mode:

• worker reports commit hash landed on origin/main
• explicit git push origin HEAD:main says Everything up-to-date
• local worktree HEAD is still the pre-run commit

Interpretation:

• the worker's local checkout may not have been fast-forwarded after the auto-push
• remote main is authoritative for morning verification

Required morning check:

git fetch origin main
git rev-parse --short HEAD
git rev-parse --short origin/main
git show --stat <claimed-commit>

Duplicate-lane convergence rule

When two lanes target the same deterministic transformation:

• the first lane may land the change
• the second lane should fetch before editing
• if the second lane can prove origin/main is byte-identical to the approved transform, that lane should not push

Treat this as success, not wasted work, when the second lane:

• detects the landed state early
• avoids a duplicate commit
• posts verification evidence on the issue
• leaves the issue in the correct state (closed or still open if residual blockers remain)

Sandboxed planning-review fallback rule

If a planning-only lane cannot run scripts/review/cross-review.sh:

• do NOT present the resulting artifacts as true cross-provider review
• every fallback artifact must contain a provenance note stating it is a single-author adversarial self-review
• every GitHub issue update must disclose that real cross-provider review is still required
• keep the issue in status:plan-review
• queue a real unsandboxed cross-review pass before any move to status:plan-approved

Acceptable fallback output:

• revised plan text
• self-review artifacts with provenance note
• issue comment summarizing what appears retired vs what still needs real review

Not acceptable:

• claiming Codex/Gemini/Codex review happened when only one author reviewed
• treating self-review artifacts as approval-equivalent

Morning scoreboard template

For each lane classify as one of:

• completed-and-closed
• landed-but-still-blocked
• already-landed-no-new-push
• planning-advanced-still-plan-review
• failed-needs-rerun

Then include:

• issue number
• landed commit(s)
• current issue state
• evidence source (remote commit, CI run, GH comment, child issue)
• next action if still open

Good outcomes from this pattern

• #2437-style: implementation landed on main, issue closed, child follow-ons created, stale worktree ignored after remote verification
• #2442-style: P1/P2 already landed elsewhere, verifier lane proves byte-identical state and leaves issue open with residual blocker follow-up
• #2441/#2443/#2444-style: plans improved, but artifacts explicitly disclose self-review provenance and issues remain in status:plan-review

Anti-patterns to avoid

• trusting stale local worktree grep over origin/main
• closing an issue because a worker claimed success without verifying remote content and issue comments
• treating self-review -r3.md artifacts as cross-provider approval evidence
• creating duplicate implementation commits when a deterministic change already landed