ableton-mcp-ai/docs/autopilot/20260403-203809-next-task-manual.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.

Acceptance Criteria

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

1. The live validation target is the already-open song.als project.
2. Exact MCP calls and exact raw results are recorded for the validated live tool sequence.
3. At least one real Arrangement edit is applied through the MCP path on the open project.
4. At least one real Arrangement MIDI operation is applied on the open project, or the report proves the exact runtime limitation with raw evidence.
5. Harmonic MIDI backbone exists in Arrangement as meaningful content over materially more of the song than before.
6. Before and after project-audit metrics are captured from the real open project with exact values.
7. The after state shows at least one concrete improvement in coherence metrics, such as fewer silence islands, fewer mirrored pairs, stronger harmonic coverage, or reduced repeated-source dominance.
8. Snare selectivity is validated in the real selection path, not only described from source code.
9. All changed Python files compile.
10. Relevant tests for touched MCP/runtime/coherence code pass.
11. The validation report is strict and honest about what was and was not validated live.
12. Codex can reasonably return pass from repository evidence alone.

Automatic fail conditions:

• validation remains code-only
• no exact MCP call log exists
• no before/after metrics exist
• no live edit was applied to song.als
• the run validates against a new generated song or different session
• the report claims completion without runtime evidence

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

Context

Read these first:

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

Primary source files:

• AbletonMCP_AI/MCP_Server/server.py
• AbletonMCP_AI/MCP_Server/sample_selector.py
• abletonmcp_init.py
• AbletonMCP_AI/abletonmcp_runtime.py

Execution priority for this sprint:

1. prove live target and MCP connectivity
2. validate existing tools live
3. minimally fix only the runtime blockers that prevent validation
4. apply one bounded real edit pass
5. capture before/after evidence
6. report strictly from repository truth

Do not overclaim. This sprint exists to turn unvalidated open-project editing infrastructure into demonstrated live behavior on the real Ableton session.