# 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