Split a large mechanical job into 2–5 independent Codex lanes, each isolated in its own worktree with a frozen acceptance bar and binding judge, then block the final merge behind a full integration judge.
Dispatch a parallel Codex legion for a large mechanical job. Split the work into 2–5 genuinely independent lanes, one lane per piece.
First announce a muster table with:
- each lane,
- the exact files that lane may touch,
- the frozen acceptance check for that lane.
Do not proceed until I approve the split.
Before dispatch, the orchestrator must freeze and record each lane’s acceptance bar. After dispatch, each worker treats `.git` as read-only.
Each lane must run in its own git worktree with:
- a frozen acceptance bar recorded before code changes,
- a strictly disjoint may-touch manifest,
- its own sandbox,
- read-only `.git` state for the worker.
If any lane’s file footprint overlaps another lane, refuse the split and serialize the work instead.
When a lane finishes, run a fresh-context judge against that lane’s frozen bar. The judge must return binding PASS or FAIL. Allow at most 2 retries per lane; stop after 2 failed attempts, then escalate loudly.
Merge lanes in a fixed order. After merging, require a mandatory integration judge that reruns the full test suite across the combined result. Do not commit or merge unless the integration judge returns PASS.
Hard cap: 5 workers. If there are more than 5 pieces, run later waves. Never merge without the integration judge.
claude-code
Implementation note
Praetor Legion Mode: parallelizes a large mechanical job across 2–5 disjoint Codex lanes. Same core laws as single dispatch: acceptance bar frozen before dispatch, binding fresh-context judge, max 2 retries before loud takeover. Legion-only laws: strictly disjoint may-touch manifests, overlap forces serialization, ordered merge, and mandatory integration judge across the combined result. The orchestrator may record/freeze bars in git before dispatch; workers keep .git read-only. Worker count is derived from the split, capped at 5, with overflow handled in later waves.
/schedule an agent in 2 weeks to open a cleanup PR for the flag?"). One-time signals: a feature flag/gate/experiment/staged rollout (clean it up or ramp it), a soak window or metric to verify (query it and post results), a long-running job with an ETA (check status and report), a temp workaround/instrumentation/.skip left in (open a removal PR), a "remove once X" TODO. Recurring signals: a sweep/triage/report/queue-drain the user just did by hand, or anything "weekly"/"again"/"piling up" — offer to run it as a routine. The bar is 70%+ odds the user says yes — skip it for refactors, bug fixes with tests, docs, renames, routine dep bumps, plain feature merges, or when the user signals closure ("nothing else to do", "should be fine now"). Don't stack offers on back-to-back turns; let most tasks just be tasks