ableton-mcp-ai/ralph/tasks/failed/20260403-211425-20260403-211423-sprint-v0-1-43-unlock-backbone-e/SOURCE.md

# SPRINT v0.1.43 - Unlock Backbone Editing and Measurable Coherence Gains

## Goal

Use the live MCP connection on the already-open Ableton project:

- C:\Users\ren\Desktop\song Project\song.als

to close the remaining blocker from v0.1.42:

- convert the currently proven live inspection and audio-pattern editing path into a path that produces a meaningful harmonic backbone improvement and at least one measurable coherence improvement

This sprint is not about proving connectivity again in isolation.

This sprint is about:
- fixing or formalizing the blocked backbone-edit path
- using that path on the live project
- producing measurable before/after improvement
- validating snare selectivity in a real runtime path

## Why This Task Exists

Repository truth from v0.1.42:

- the run did reach the correct open project
- real MCP-driven Arrangement audio edits succeeded through `create_arrangement_audio_pattern`
- no source-code fix was made
- the harmonic MIDI backbone requirement was still not met
- key coherence metrics did not materially improve
- snare selectivity was still inferential rather than proven in a real selection path

High-signal truths from the run artifacts:
- `temp/v04142_mcp_calls_final.jsonl` proves `create_arrangement_audio_pattern` works live
- `temp/v04142_comprehensive_validation.json` shows 3 arrangement audio-pattern edits succeeded
- the same artifact shows mirrored pairs stayed at 100 and clip overuse stayed high
- `docs/SPRINT_v0.1.42_VALIDATION_REPORT.md` admits MIDI note insertion is still blocked
- the worktree had no source-code diff, so the blocker was diagnosed but not fixed

The next step is therefore not “more validation.”
It is:
- implement the smallest real code fix or formal runtime fallback needed to make backbone extension and coherence improvement repeatable
- then prove it on song.als with exact metrics

## Required Work

1. Start from the live path that actually worked in v0.1.42.
- Reuse the live MCP connection approach that already validated the real open `song.als` session.
- Reuse the proven `create_arrangement_audio_pattern` path if MIDI editing remains blocked.
- Do not regress the working runtime path.

2. Resolve the backbone-edit blocker at code level.
- You must make a real code change in the runtime path this sprint unless the existing code already supports a better fallback and only wiring is missing.
- Priority order:
  1. make a meaningful Arrangement MIDI backbone edit succeed
  2. if that is genuinely blocked by the Live API, implement and validate a formal fallback path that creates backbone-like Arrangement content through a supported method
- A valid fallback is not random content.
- A valid fallback must:
  - be intentional
  - extend harmonic continuity
  - be audibly useful
  - be documented as the canonical path when MIDI insertion is blocked

3. Prove the fallback or fix is real on the live project.
- Apply at least one backbone-oriented Arrangement edit that increases continuity in a musically relevant span.
- The edit must target a real gap, weak span, or dead tail in song.als.
- The edit must not be only track property changes.
- It must be actual Arrangement content.

4. Require at least one measurable coherence improvement.
- Before editing, capture exact metrics.
- After editing, capture exact metrics again.
- At least one of these must improve in the saved evidence:
  - silence islands
  - mirrored section pairs
  - harmonic coverage/backbone presence
  - same-source dominance
  - repeated clip overuse
- “3 patterns created” is not enough if the saved coherence metrics remain flat.

5. Validate the missing live MCP tools from v0.1.42.
- The previous run still under-validated the tool set.
- This sprint must exercise and record exact results for:
  - get_tracks()
  - get_device_parameters(...)
  - set_device_parameter_by_name(...)
- Also re-confirm one arrangement creation/edit path and one audit path.
- If a tool is blocked, record the exact raw blocker and the exact fallback.

6. Validate snare selectivity in a real runtime path.
- Do not infer from the current project state.
- Do not cite older sprint text as proof.
- Run a real runtime path that exercises the selection logic or the relevant selection entry point.
- Record exact evidence showing whether the aggressive snare is penalized differently across at least two different section-energy contexts.
- If the scoring exists but is not wired into the runtime path, wire the minimum real path and validate it.

7. Keep scope tight and senior.
- Do not add broad new feature surfaces.
- Do not rewrite the generation system.
- Touch only the files required to:
  - unlock the blocked edit path
  - validate the missing tool coverage
  - make the coherence improvement measurable
- Likely candidates:
  - AbletonMCP_AI/MCP_Server/server.py
  - abletonmcp_init.py
  - AbletonMCP_AI/abletonmcp_runtime.py
  - AbletonMCP_AI/MCP_Server/sample_selector.py
  - docs/SPRINT_v0.1.43_VALIDATION_REPORT.md

8. Fail honestly if the blocker is fundamental and unfixed.
- If the MIDI path remains fundamentally blocked, the report must say so explicitly.
- But in that case the sprint still must either:
  - ship a real validated fallback path with measurable improvement
  - or fail
- A documentation-only explanation is not enough anymore.

## Acceptance Criteria

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

## Validation

Produce all of the following artifacts:

1. docs/SPRINT_v0.1.43_VALIDATION_REPORT.md
Required sections:
- Summary
- Files Changed
- Live Target Proof
- Runtime Fix or Canonical Fallback
- MCP Tools Validated Live
- Project Audits Before
- Project Edits Applied
- Project Audits After
- Before/After Metrics
- Snare Selectivity
- Harmonic Backbone Outcome
- What Is Still Weak
- Remaining Risks

2. temp/v04143_live_target_proof.json
- raw proof that the active session is the intended open project

3. temp/v04143_mcp_calls.jsonl
- one JSON line per MCP call
- include tool name, arguments, success/failure, and raw result/error

4. temp/v04143_before_audit.json
- raw before-state audit outputs

5. temp/v04143_after_audit.json
- raw after-state audit outputs

6. temp/v04143_edit_actions.json
- exact live edits attempted and whether each succeeded

7. temp/v04143_snare_selectivity_validation.json
- runtime evidence for at least two section contexts
- include the exact sample candidates or scoring evidence used

8. temp/v04143_blocker_or_fallback.json
- if MIDI remains blocked, document:
  - exact failing call
  - exact raw response
  - exact supported fallback used instead
  - proof that the fallback was applied live

9. temp/v04143_metric_delta.json
- explicit before/after delta summary for the coherence metrics

Required validation actions:
- python -m py_compile on every changed Python file
- relevant tests for every touched runtime/MCP/selection file
- live MCP calls against the open project
- before and after audits from the same live session
- exact evidence for either a fixed backbone path or a validated fallback path

## Context

Read these first:

- previous run directory:
  - C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-203815-queue
- previous summary:
  - C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-203815-queue\SUMMARY.md
- previous reviews:
  - C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-203815-queue\reviews\codex_master_pre_fix.json
  - C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-203815-queue\reviews\opencode_qwen3coder_plus.json
  - C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-203815-queue\reviews\opencode_glm47.json
- previous validation report:
  - docs/SPRINT_v0.1.42_VALIDATION_REPORT.md

Most important evidence files from the previous run:
- temp/v04142_mcp_calls_final.jsonl
- temp/v04142_comprehensive_validation.json
- temp/v04142_audio_pattern_results.json
- temp/v04142_edit_actions.json

Primary source files:
- AbletonMCP_AI/MCP_Server/server.py
- abletonmcp_init.py
- AbletonMCP_AI/abletonmcp_runtime.py
- AbletonMCP_AI/MCP_Server/sample_selector.py

Execution priority for this sprint:
1. preserve the proven live connection and working arrangement-audio path
2. make the blocked backbone path succeed, or formalize a supported fallback in code
3. validate the previously missing live MCP tools
4. deliver one measurable coherence improvement
5. validate snare selectivity in a real runtime path
6. report only what repository evidence proves

Do not overclaim. The previous run proved that live editing is partially possible. This sprint exists to turn that partial proof into a repeatable, code-backed, measurable project improvement.