# 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