27 lines
1.6 KiB
Markdown
27 lines
1.6 KiB
Markdown
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
|