ableton-mcp-ai/ralph/tasks/failed/20260403-203814-20260403-203809-sprint-v0-1-42-live-proof-of-ope/TASK.md

SPRINT v0.1.42 - Live Proof of Open-Project Editing

Goal

Validate and use the existing MCP editing path on the already-open Ableton project:

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

This sprint is not a generation sprint and not a wrapper-expansion sprint.

It is a runtime-proof sprint:

• prove the MCP can inspect the real open project
• prove the MCP can apply real Arrangement edits on that project
• prove the edits improve coherence in measurable ways
• document exact evidence or fail explicitly

Why This Task Exists

The previous run failed.

Repository truth from the failed run:

• infrastructure was added in AbletonMCP_AI/MCP_Server/server.py
• contextual snare scoring was added in AbletonMCP_AI/MCP_Server/sample_selector.py
• docs/SPRINT_v0.1.41_VALIDATION_REPORT.md was corrected to an honest fail
• no live MCP calls were exercised against song.als
• no real edit pass was applied
• no before/after coherence metrics were captured
• no proof exists that the new editing tools work through the real Ableton runtime path

The highest-signal blocker is now obvious:

• stop adding unvalidated infrastructure
• prove runtime behavior on the open project
• if runtime behavior is blocked, isolate the exact blocker with raw evidence

Required Work

1. Prove the live target is the real open project.

• Connect through the MCP to the active Ableton session.
• Capture enough session evidence to prove the target is the already-open song.als session and not a generated set or blank template.
• Save raw outputs under temp/.

2. Validate the existing MCP tool path live before adding more tools.

• Exercise these tools against the open project and record exact calls plus raw outputs:
  • get_session_info()
  • get_tracks()
  • get_track_info(...)
  • get_clips(...)
  • get_clip_info(...)
  • get_devices(...)
  • get_device_parameters(...)
  • set_device_parameter_by_name(...)
  • one arrangement creation or duplication path
  • one arrangement MIDI note insertion path
• For each tool, classify it as:
  • live validated
  • failed live
  • blocked by backend/runtime limitation
• Do not mark a tool complete just because it compiles.

3. If a live tool path fails, fix only the minimal blocker.

• Use the existing code added in v0.1.41 as the starting point.
• If a backend handler or runtime path is missing, add the smallest fix needed in the real runtime path.
• Re-run the exact same MCP call after the fix and save the before/after evidence.
• Do not add unrelated new feature surface.

4. Audit the open project before editing.

• Run project-facing audits on the real song.als session.
• Capture exact before metrics for:
  • silence islands
  • mirrored section pairs
  • harmonic coverage / harmonic backbone status
  • same-source dominance or repeated-source overuse
  • repeated clip overuse if available
• Save raw outputs under temp/.
• Use these audits to choose the edit targets.

5. Apply a bounded real edit pass on song.als.

• Use the validated MCP editing tools on the real open project.
• The edit pass must be small, targeted, and measurable.
• Prioritize:
  • extending or repairing harmonic MIDI backbone in Arrangement
  • reducing dead gaps
  • breaking at least one mirrored or obviously repeated arrangement shape
  • improving continuity without destroying identity
• The harmonic MIDI backbone must become real Arrangement content intended to be audible.
• It is acceptable to use keys, pluck, pad, or synth timbre.
• It is not acceptable to leave the backbone as metadata, a hidden clip, or an empty placeholder.

6. Validate snare selectivity in the real path.

• Do not hard-ban SS_RNBL_Me_Gustas_One_Shot_Snare.wav.
• Prove whether the new contextual snare scoring actually affects selection in real use.
• If the logic exists but is not wired into the live path, wire the minimal real path and validate it.
• Record exact evidence showing whether lower-energy sections are treated more conservatively than higher-energy sections.

7. Re-audit after editing.

• Run the same project-facing audits again.
• Save raw after-state outputs under temp/.
• Produce an exact before/after table using measured values, not estimates.
• State clearly what improved, what stayed flat, and what regressed.

8. Keep the scope disciplined.

• Touch only the files directly required to validate or minimally fix the runtime editing path.
• Likely files:
  • AbletonMCP_AI/MCP_Server/server.py
  • AbletonMCP_AI/MCP_Server/sample_selector.py
  • abletonmcp_init.py
  • AbletonMCP_AI/abletonmcp_runtime.py
  • docs/SPRINT_v0.1.42_VALIDATION_REPORT.md
• Do not add broad new capability areas unless they are the direct blocker to a required live validation step.

9. Fail fast if the runtime is not reachable.

• If Ableton, the control surface, or the MCP connection is unavailable, do not continue building infrastructure.
• Capture the exact failing step and raw evidence.
• Mark the sprint failed with specific blocker evidence.
• A code-only partial success is not acceptable for this sprint.

Validation

Produce all of the following artifacts:

1. docs/SPRINT_v0.1.42_VALIDATION_REPORT.md Required sections:

• Summary
• Files Changed
• Live Target Proof
• MCP Tools Validated Live
• Project Audits Before
• Project Edits Applied
• Project Audits After
• Before/After Metrics
• Snare Selectivity
• Harmonic MIDI Backbone
• What Is Still Weak
• Remaining Risks

2. temp/v04142_live_target_proof.json

• raw evidence proving the active Ableton session is the intended open project

3. temp/v04142_mcp_calls.jsonl

• one JSON line per MCP call
• include tool name, arguments, success or failure, and raw result or raw error

4. temp/v04142_before_audit.json

• raw before-state audit outputs

5. temp/v04142_after_audit.json

• raw after-state audit outputs

6. temp/v04142_edit_actions.json

• exact live edits attempted and whether each succeeded

7. If blocked, replace missing success artifacts with:

• temp/v04142_blocker_evidence.json
• include the exact failing step, exact raw response, and why the sprint could not proceed

Required validation actions:

• python -m py_compile on every changed Python file
• relevant tests for touched runtime/MCP/coherence code
• live MCP calls against the open project
• before and after audits on the same open project session