# SPRINT v0.1.37 - NEXT FOR GLM
## Close The Real Project-Editing Runtime Path On `song.als`

**Owner:** GLM via OpenCode  
**Reviewer:** Codex  
**Fecha:** 2026-04-02  
**Mode:** Project editing, not new-song generation

Primary benchmark project:

- `C:\Users\ren\Desktop\song Project\song.als`

Reference docs:

- `C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\docs\PROJECT_AUDIT_song_2026-04-03.md`
- `C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\docs\SPRINT_v0.1.36_IMPLEMENTATION_REPORT.md`

---

## 1. Reviewer Summary

GLM did useful work in `server.py`: the public MCP surface for project editing is now much larger.

But the report was **not** accurate enough to mark the sprint complete.

Codex review found this real state:

- the report said `COMPLETED`
- the code actually had a **partial MCP layer / partial runtime layer** split
- `get_clips` was exposed publicly but not routed in the runtime
- arrangement MIDI editing still depended on `track.create_clip(...)`, which is not available in this Live install
- `set_device_parameter` was exposed publicly, but the public tool did not expose the runtime's `parameter_name` path
- the report mentioned a temp file `sprint_036_tools.py`, but that file is not present in the active tree

So the correct interpretation of v0.1.36 is:

- **good direction**
- **not closed**

---

## 2. What Codex Fixed After GLM

These are already fixed in code and must be treated as the new baseline.

### 2.1 `server.py`

Codex fixed:

- `set_device_parameter(...)` now supports both:
  - `parameter_index`
  - `parameter_name`
- `audit_current_project()` now reports `repeated_clip_overuse`

### 2.2 `abletonmcp_init.py`

Codex fixed:

- runtime routing for `get_clips`
- runtime routing now passes `track_type` to:
  - `get_clip_info`
  - `create_arrangement_clip`
  - `add_notes_to_arrangement_clip`
  - `duplicate_clip_to_arrangement`
- arrangement clip creation no longer depends only on direct `track.create_clip(...)`
- fallback now attempts **session-clip-to-arrangement recording**
- arrangement clip lookup is more robust via cached/retrieved clips near `start_time`

### 2.3 `abletonmcp_runtime.py`

Codex applied the same parity fixes there:

- `get_clips` routing
- `track_type` propagation
- `parameter_name` support in `set_device_parameter`
- same arrangement fallback strategy

### 2.4 Tests added/updated by Codex

Codex added/extended tests for:

- public `set_device_parameter` by `parameter_name`
- `audit_current_project()` repeated clip overuse reporting

Current validated tests:

- `test_runtime_truth.py`
- `test_selection_coherence.py`
- `test_piano_forward.py`

All pass locally.

---

## 3. Current Truth After Review

You must start from this truth, not from the v0.1.36 report text.

### 3.1 What is now true in code

- public editing tools exist in `server.py`
- runtime now has `get_clips` routing
- runtime now has an arrangement creation fallback path instead of only `track.create_clip(...)`
- the public `set_device_parameter` API is no longer index-only

### 3.2 What is still NOT proven

These fixes are **not** proven complete until you restart Live/OpenCode and test them against the real benchmark project:

- `create_arrangement_clip`
- `add_notes_to_arrangement_clip`
- `duplicate_clip_to_arrangement`
- `get_clips`

Reason:

- those paths depend on the loaded Ableton runtime, not just Python compilation

So this sprint is a **runtime validation + stabilization sprint**, not another layer of speculative wrapper code.

---

## 4. Code Review Findings You Must Respect

### 4.1 Do not overclaim completion

This was the biggest process failure in v0.1.36.

Wrong pattern:

- public MCP wrapper exists
- compile passes
- report says `COMPLETED`

Correct pattern:

- public wrapper exists
- runtime command exists
- Ableton loaded the new runtime
- tool works against `song.als`
- evidence is included

If any of those is missing:

- the sprint is **not complete**

### 4.2 Do not count dead or missing files as implementation evidence

The report cited:

- `sprint_036_tools.py`

That file is not present in the active tree.

Do not cite temp artifacts as evidence unless they exist and matter.

### 4.3 Do not confuse “tool exists” with “editing workflow exists”

The product goal is not “more MCP tools”.

The goal is:

- open project
- inspect project
- edit project
- validate project

on a real `.als`

### 4.4 Do not invent a black-box `refine_existing_song()` yet

Not until the primitives are proven.

Right now the correct priority is:

1. clip inspection works
2. arrangement MIDI writing works
3. device parameter editing works
4. audit metrics work on real project

Only after that should you add orchestration.

---

## 5. Main Goal Of v0.1.37

Prove that the MCP can **inspect and edit an already-open project** in a real Ableton session.

The benchmark remains:

- `C:\Users\ren\Desktop\song Project\song.als`

This sprint is complete only if the MCP can perform real edit actions on that project.

---

## 6. P0 Tasks

## P0.1 Restart and validate the actual loaded runtime

Mandatory before any conclusion:

1. Restart Ableton Live
2. Restart OpenCode
3. Reconnect MCP
4. Confirm the editing tools are visible and callable

Minimum evidence:

- `opencode mcp list --print-logs`
- proof that the tool list includes the editing tools

If OpenCode shows stale tools or stale failures:

- do not continue “testing”
- restart again and prove the loaded runtime is current

---

## P0.2 Validate the inspection tools on `song.als`

Using the real loaded project, prove:

- `get_tracks()`
- `get_clips(track_index=...)`
- `get_devices(track_index=...)`
- `get_clip_info(track_index=..., clip_index=...)`
- `audit_current_project()`

### Required target tracks

At minimum inspect:

- `HARMONY_PIANO_MIDI`
- `AUDIO BASS`
- one percussion track
- one synth/music track

### Required evidence

For each tested tool, include:

- exact MCP call
- exact result
- whether it matches the real project seen in Live

Do not summarize vaguely.

---

## P0.3 Validate arrangement MIDI editing on the real project

This is the real blocker.

Using the already-open `song.als`, prove these work:

### 1. `create_arrangement_clip(...)`

Create a short test clip on `HARMONY_PIANO_MIDI`.

Requirements:

- clip appears in Arrangement
- it is on the expected track
- it is at the expected start time

### 2. `add_notes_to_arrangement_clip(...)`

Add a small note set to that clip.

Requirements:

- notes are visible in the created clip
- notes are audible when the track/device is valid

### 3. `duplicate_clip_to_arrangement(...)`

Take one existing Session clip and materialize it into Arrangement.

Requirements:

- duplicated result appears in Arrangement
- clip length is sensible
- it lands near the requested `start_time`

If any of these fail:

- capture the exact error
- inspect Ableton log / MCP response
- patch the runtime
- retest

Do not declare the sprint done if these remain unproven.

---

## P0.4 Validate `set_device_parameter(...)` by name

This was incomplete in GLM's public API and Codex fixed it.

Now you must prove it works end-to-end.

On a real device in the loaded project:

- call `get_devices(...)`
- choose a real device index
- use `set_device_parameter(..., parameter_name="...")`

Required evidence:

- exact parameter changed
- before/after value
- confirmation in Live if visible

---

## P0.5 Validate `audit_current_project()` against the benchmark

The audit must now report:

- longest drum gap
- longest harmonic gap
- empty arrangement tracks
- harmonic MIDI tracks with devices but no clips
- structure mismatch
- repeated clip overuse

You must verify that its output is directionally correct against:

- `PROJECT_AUDIT_song_2026-04-03.md`
- the real loaded set

This does **not** need perfect musical intelligence yet.
It does need to be honest and useful.

---

## 7. P1 Tasks

## P1.1 Improve `get_clip_info(...)` semantics

Right now `get_clip_info(...)` is still session-slot-centric.

That is acceptable as an intermediate state, but you must decide and document one of these directions:

1. keep `get_clip_info(...)` explicitly session-only and rename/scope it accordingly
2. add a second tool for arrangement clip info
3. extend the current API with a `view` or `clip_kind` argument

Do not leave it semantically ambiguous.

This is a product/API cleanup task, not the main blocker.

---

## P1.2 Design the first safe editing orchestration

Only after P0 works.

Candidate:

- `refine_existing_song(...)`

But it must:

- call public editing tools internally
- return an action log
- be inspectable, not magical

Do **not** implement this first.

---

## 8. Non-Goals

Do not spend this sprint on:

- new generation features
- reggaeton coherence tuning
- piano-forward logic
- new sample-selection heuristics
- cosmetic report writing

This sprint is specifically about the **editing runtime path**.

---

## 9. Required Files

Primary:

- `C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\server.py`
- `C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\abletonmcp_init.py`
- `C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\abletonmcp_runtime.py`
- `C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\tests\test_runtime_truth.py`

Benchmark:

- `C:\Users\ren\Desktop\song Project\song.als`

---

## 10. Required Validation Commands

Minimum:

```powershell
python -m py_compile "C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\server.py" "C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\abletonmcp_init.py" "C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\abletonmcp_runtime.py"
python "C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\tests\test_runtime_truth.py"
```

And then real MCP validation in OpenCode against the loaded project.

---

## 11. Deliverable Format

Write:

- `C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\docs\SPRINT_v0.1.37_VALIDATION_REPORT.md`

The report must contain:

### A. Runtime truth

- did you restart Ableton
- did you restart OpenCode
- did MCP reconnect successfully

### B. Tool-by-tool results

For each tool tested:

- exact call
- exact result
- pass/fail

### C. Benchmark evidence

- what changed in `song.als`
- what you inspected
- what you successfully edited

### D. Failures

For every remaining failure:

- exact command
- exact error
- root cause
- whether it is code, MCP, or Live API limitation

### E. Reviewer-grade conclusion

One of only:

- `COMPLETED`
- `PARTIAL`
- `BLOCKED`

Do not write `COMPLETED` unless arrangement MIDI editing was proven on the live project.

---

## 12. Final Rule

If the runtime still cannot write/edit Arrangement MIDI on the live benchmark project after restart and retest:

- do not hide it
- do not soften it
- do not declare success because wrappers exist

The whole point of this sprint is to close the gap between:

- MCP surface
- actual project editing in Ableton