# SPRINT v0.1.45 - NEXT
## Kimi Manual Open Project Coherence Repair

**Owner:** Kimi via OpenCode  
**Reviewer:** Codex  
**Date:** 2026-04-03  
**Mode:** Manual repair of open project `song.als`  
**Target:** Repair the real open Ableton project, not a generated set and not a dry-run

---

## 0. Baseline Truth

This sprint starts from the live open project, not from assumptions in the previous report.

Current verified live truth from MCP:

- `get_session_info()` returned `tempo = 96.0`, `track_count = 16`
- `get_track_info(track_index=15)` showed `HARMONY_BACKBONE_V04142`
- That track currently has only **1 meaningful arrangement clip**
- The previous report claimed 2 real arrangement clips and much better progress than the live set actually shows
- `audit_project_coherence()` still reports a very poor state, including a massive harmonic void

Current structural problem:

- the harmonic backbone is still too fragmented
- large sections still feel empty
- rhythm continuity still breaks down in places where bass/reese alone is not enough
- the song still behaves like "one good short loop, then too much empty space"

This sprint is about fixing that in the open project.

---

## 1. Codex Review of v0.1.44

The previous report overstated progress in several ways:

- it treated stale audit data as reliable
- it claimed "2 real arrangement clips" for the backbone, which did not match the verified live state
- it described `create_arrangement_audio_pattern(...)` as unavailable, but that is stale; the tool is already exposed in MCP
- it claimed a `server.py` syntax problem that does not reproduce under `py_compile`

Codex fixes applied before this sprint:

- `audit_project_coherence()` now measures family gaps per track, including leading/trailing voids
- `harmonic_backbone_status.span_ratio` no longer overcredits a sparse backbone just because first and last clips are far apart
- runtime truth tests were extended to catch these metric failures

Implication:

- you must not rely on old audit numbers from v0.1.44 output files
- restart OpenCode before validation so the updated `server.py` is loaded

---

## 2. Sprint Goal

Repair `song.als` so that the arrangement feels like a continuous song instead of isolated islands.

More concretely:

- the harmonic backbone must exist in Arrangement across the song
- silence islands must be reduced materially
- drum continuity must improve materially
- strong bass or Reese alone must not be treated as enough when rhythm has dropped out
- edits must be real MCP edits on the open set, not recommendations and not manual-only prose

---

## 3. Hard Musical Direction

The backbone track must behave like a real harmonic spine.

Interpretation:

- `HARMONY_*` MIDI must live in Arrangement, not only Session
- it must appear across the song, not in one or two isolated islands
- it should help fill empty stretches where the arrangement currently collapses into bass-only space
- the goal is continuity and coherence, not adding random layers

Rhythm direction:

- if a section carries bass/reese energy, it still needs enough rhythmic support to feel like a section, not a hole
- avoid sections where top/perc/hat support disappears for too long unless there is a very deliberate musical reason
- do not repair by making everything perfectly mirrored or equally dense

Variation direction:

- keep structure, but reduce geometric symmetry
- avoid copy-pasting the same visual pattern across sections
- variation must come from arrangement decisions, not from introducing new chaos

---

## 4. Required Workflow

You must work on the real open `song.als` via MCP.

Required process:

1. OpenCode restart first, so the updated `server.py` audit logic is actually loaded.
2. Reconnect to MCP and verify the open project with:
   - `get_session_info`
   - `get_tracks`
   - `get_track_info` for the harmonic backbone track and the main drum/top loop tracks
   - `audit_project_coherence`
3. Perform real edits using MCP tools on the open project.
4. Re-run the same inspection after edits.
5. Write the validation report only from the post-edit live state.

Do not validate from stale JSON files alone.

---

## 5. MCP Tools You Are Expected to Use

Use the real editing surface now available.

Core inspection:

- `get_session_info`
- `get_tracks`
- `get_track_info`
- `get_clips`
- `get_clip_info`
- `get_devices`
- `get_device_parameters`
- `audit_project_coherence`
- `audit_current_project`

Core editing:

- `create_arrangement_clip`
- `add_notes_to_arrangement_clip`
- `duplicate_clip_to_arrangement`
- `create_arrangement_audio_pattern`
- `set_track_mute`
- `set_track_solo`
- `set_track_volume`
- `set_track_pan`
- `set_track_send`
- `set_device_parameter`
- `apply_clip_fades`
- `write_volume_automation`

Repair helpers:

- `repair_harmonic_gaps`
- `extend_track_continuity`
- `repair_silence_gaps`
- `soften_grid_lock`

If a helper proves analysis-only or unreliable in the live set, say so clearly and switch to explicit lower-level edits.

---

## 6. Concrete Tasks

### T1. Re-validate the harmonic backbone track

You must identify the actual track index and current live state of the `HARMONY_*` backbone in the open set.

Required outcome:

- meaningful Arrangement clips
- no phantom/tiny clips counted as success
- enough span to function as song backbone, not just local patchwork

### T2. Extend harmonic continuity across the song

Use Arrangement MIDI editing to extend the harmonic spine across empty zones.

Requirements:

- do not stop after one or two clips
- do not rely only on Session clips existing
- if helper tools fail, use explicit `create_arrangement_clip + add_notes_to_arrangement_clip`
- the result must cover the real holes, not just create one token clip

### T3. Reduce rhythm voids

Inspect the tracks that create the "bass-only but rhythm disappeared" problem.

At minimum inspect and repair where relevant:

- top loop
- percussion support
- hats
- alternate perc

Goal:

- fewer silent rhythmic voids
- sections should feel supported, not amputated

### T4. Avoid fake success from stale metrics

Use the updated coherence audit after edits.

You must compare:

- before
- after

And explain whether improvements are real or only cosmetic.

---

## 7. Acceptance Criteria

This sprint only passes if all of these are true:

- the report is based on the live open project after edits
- the harmonic backbone track has meaningful Arrangement presence across the song
- `audit_project_coherence()` improves in a way that matches the arrangement visually and musically
- long empty stretches are materially reduced
- the set does not depend on bass/reese alone to pretend a section is full
- exact MCP calls are logged in the report

Target metrics:

- `longest_harmonic_gap.gap_beats < 64`
- `longest_drum_gap.gap_beats < 32`
- `harmonic_coverage_ratio >= 0.70`
- `drum_coverage_ratio >= 0.55`

These are not enough by themselves. The arrangement must also look and feel less empty.

---

## 8. Automatic Failure Conditions

Fail the sprint if any of these happen:

- report says `COMPLETED` while the backbone is still fragmentary
- report cites stale MCP data or stale JSON instead of live re-check
- only Session clips were created but Arrangement stayed mostly empty
- edits are mostly theoretical or dry-run output
- large rhythm voids remain where the song still drops into bass-only emptiness
- the report counts phantom or near-zero clips as successful materialization

---

## 9. Restart Policy

Required now:

- restart OpenCode before starting, because `server.py` changed

Not required by this Codex patch alone:

- Ableton Live restart

However:

- if you change runtime files (`abletonmcp_init.py`, `abletonmcp_runtime.py`), you must stop, tell the user, and request an Ableton restart
- if MCP reconnect is unstable, tell the user explicitly

Your report must include a final section named `Restart Requirements`.

---

## 10. Deliverables

Required files and evidence:

- `docs/SPRINT_v0.1.45_VALIDATION_REPORT.md`
- exact MCP calls used
- before/after metrics from live MCP
- exact track names and indexes touched
- explicit list of clips created, duplicated, or extended
- clear statement of what remains open if the sprint is only partial

Do not hand-wave. If the song still has holes, say so.

