sprint_orchestrationlisted

# sprint_orchestration Coordinate the sprint from durable records. Keep code context in worker shells and coordination context here. Use three procedures: - This skill: declare, dispatch, monitor, and advance the normal path. - `sprint_orchestration_recover`: diagnose and repair a stalled transition. - `sprint_orchestration_close`: run conformance, revoke authority, and report. Load a chain skill only when its trigger is true. ## 1. Establish the boundary Confirm the objective, governing spec or decisions, and success condition with the FnB. Ask two routing questions: 1. Which harness and model should every developer use? 2. Which harness and model should every reviewer use? Treat account configuration and billing limits as operator-managed inputs. Use the selected routes. Read active decisions before choosing architecture or sequencing: ```sh ./sc mem get decisions ./sc mem get decisions <id> ``` For concurrent sprints, partition hard resources before dispatch: - shells; - branches and worktrees; - migrations and other globally ordered identifiers; - files with substantial overlap; - external environments or exclusive services. Give each sprint a distinct label and record every reservation. Read back globally allocated IDs after creation; a planned number is provisional until the authoritative store confirms it. Use `S<doc-id>-U<seq>` in messages, flags, and reports. Unit labels are unique only inside one sprint. Keep the declared shell sets exclusive. Transfe