Closure First Overnight Batch

Closure-first overnight batch

Use this when a repo has many open status:plan-approved issues, but live state may be stale and only some lanes are truly ready for implementation.

When to use

• Overnight batch with multiple Codex terminals/worktrees
• Backlog contains several status:plan-approved issues
• You suspect queue drift: some issues may already be implemented, others may really be blocked by shared CI/governance infrastructure
• You want maximum morning impact, not maximum overnight token burn

Core idea

Do not spend the whole night implementing by default. Instead, split the batch into three types of lanes:

1. verify-close lanes for stale-open issues
2. one bounded PR-repair / blocker-diagnosis lane
3. one true implementation lane

This often yields better morning outcomes than five implementation lanes, because it:

• closes stale-open issues quickly
• turns fuzzy branch failures into precise blocker issues
• preserves one lane for genuine implementation progress

Recommended lane mix

For a 5-lane batch:

• T1 verify-close stale-open issue A
• T2 verify-close stale-open issue B
• T3 verify-close stale-open issue C
• T4 repair blocked PR / branch; if blocker is repo-wide, create a blocker issue and stop
• T5 implement one highest-confidence approved issue in an isolated worktree

Verify-close lane checklist

Each verify-close lane should:

1. git fetch origin --quiet
2. confirm candidate implementation commit is ancestor of origin/main
3. confirm content parity for the main deliverable path(s), not just commit ancestry
4. inspect issue comments / review artifacts / acceptance criteria
5. map acceptance criteria to exact proof
6. write a local evidence report artifact
7. post a proof-rich GitHub closeout comment
8. close the issue if and only if the acceptance target is already satisfied

Important lesson:

• commit containment alone is not enough; also check content parity on origin/main
• comment first, then close; do not rely on gh issue close --comment in race-prone situations

Blocker-conversion lane checklist

Use one lane for a live blocked PR/branch.

Goal:

• determine whether the branch is actually broken, or whether repo-wide CI/governance drift is the real blocker

Process:

1. inspect failing checks / local repro path
2. separate branch-specific failures from repo-wide infra failures
3. if the blocker is outside the branch's owned paths, stop implementation work
4. write a blocker report artifact
5. create a new GitHub issue for the shared blocker
6. comment on the originally blocked issue/PR linking the blocker issue

This keeps the queue truthful overnight and prevents random edits to the wrong branch.

Implementation lane checklist

Reserve one lane for a real approved implementation issue.

Requirements:

• clean isolated worktree from origin/main
• local .planning/plan-approved/<issue>.md marker committed in that worktree before starting
• explicit owned/read-only/forbidden paths
• narrow TDD-first scope

If push is blocked by shared hook/governance problems after local validation:

• do not silently bypass unless explicit authorization exists
• treat that as evidence for the blocker-conversion / landing-blocker stream
• comment on the issue with exact blocker and next dependency

What good morning output looks like

By morning, the batch should ideally produce:

• 2-3 stale-open issues closed with evidence
• 1 new blocker issue for any shared CI/hook/governance problem discovered
• 1 implementation branch advanced with real commits, or a precise blocker report

Why this pattern works

A drifted queue often contains three kinds of work that look identical from labels alone:

• already-landed work
• blocked work
• truly executable work

This batch pattern separates them early and spends tokens accordingly.

Pitfalls

• Do not trust status:plan-approved labels alone; do live eligibility checks.
• Do not assume a blocked PR needs branch edits; first test whether the real failure is repo-wide.
• Do not run all lanes as implementation lanes when file overlap or shared governance hooks make that unsafe.
• Do not close from commit ancestry alone; verify content parity and acceptance coverage.