ableton-mcp-ai/ralph/tasks/failed/20260403-211425-20260403-211423-sprint-v0-1-43-unlock-backbone-e/TASK.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.

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