This sprint passes only if all of the following are true:

1. The live target is the already-open song.als session.
2. The run makes at least one real source-code change in the runtime or selection path, unless an already-existing code path is conclusively shown to be the canonical supported fallback and is validated end-to-end live.
3. At least one real Arrangement content edit is applied on the open project to improve harmonic continuity or fill a real weak span.
4. The backbone goal is met either by:
- meaningful Arrangement MIDI backbone content added live
- or a documented and validated supported fallback path that adds backbone-like Arrangement content when MIDI insertion is blocked
5. At least one coherence metric in the saved before/after evidence improves materially.
6. The run validates the previously missing live tool coverage:
- get_tracks()
- get_device_parameters(...)
- set_device_parameter_by_name(...)
7. Snare selectivity is validated through a real runtime path across at least two section contexts.
8. All changed Python files compile.
9. Relevant tests for touched code pass.
10. The validation report contains exact raw evidence references and does not overclaim.
11. Codex can reasonably return pass from repository evidence alone.

Automatic fail conditions:
- no source-code or real wiring change is made while blockers remain
- only property edits are applied again
- backbone remains absent and no validated fallback is delivered
- all saved coherence metrics remain flat again
- snare selectivity is still argued from inference instead of runtime evidence
- the report claims success without a measurable improvement
