ableton-mcp-ai/ralph/tasks/failed/20260403-193730-20260403-193721-sprint-v0-1-41-ralph-swarm-open/SOURCE.md

# SPRINT v0.1.41 - Ralph Swarm - Open Project Editing and Coherence

## Goal

Use the Ralph swarm to work on the already-open Ableton project:

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

This is not a new-song generation sprint.

This sprint is about:

1. giving the MCP more real editing power over open projects
2. using those tools on the current open project
3. improving coherence, continuity and musical identity
4. reducing symmetry, repeated blocks and empty gaps
5. treating harmonic MIDI as a real backbone across the full arrangement

## Important Product Clarification

The user comes from FL Studio and may say `piano roll`.

In this project that means:

- harmonic MIDI backbone
- long-form arrangement MIDI that carries harmony/melodic identity
- editable MIDI clips in Arrangement

It does **not** mean:

- force piano timbre everywhere
- spam piano loops
- replace the user library with generic piano sounds

The right interpretation is:

- use `HARMONY_*_MIDI` as the musical spine
- blend that spine with the user's library
- keep the project library-first-hybrid
- make the MIDI audible, useful and persistent throughout the song

## Current Problems To Solve

The current system has improved, but the open-project result still tends to show:

- too much geometric symmetry
- repeated section shapes with near-identical spacing
- too many silence islands
- a good 4-second loop followed by dead air
- harmonic MIDI backbone still too weak or too local
- sections differentiated by removal instead of transformation
- sound selection still too conservative or too repetitive
- aggressive snares sometimes damaging coherence

The specific snare to watch carefully is:

- `SS_RNBL_Me_Gustas_One_Shot_Snare.wav`

Do **not** hard-ban it blindly.

Instead:

- analyze when it is appropriate
- score it more selectively by section energy, density and surrounding sources
- stop it from dominating softer sections or smoother grooves

## Scope

This sprint has two parallel tracks that must meet in one validated result.

### Track A - MCP Capability

Strengthen the public MCP editing workflow for an already-open project.

The target is not theoretical wrappers.

The target is:

- inspect open project
- inspect clips/devices/parameters
- edit Arrangement
- edit MIDI in Arrangement
- edit device parameters by name
- use repair tools meaningfully on a real project

### Track B - Project Editing

Apply those tools to `song.als` and improve the real set.

Do not stop at “tools exist”.

Use them.

## Required Outcomes

### A. Open-project editing must be real

At least these MCP abilities must be validated live on the open project:

- inspect tracks
- inspect clips on a track
- inspect a specific clip
- inspect devices on a track
- inspect device parameters
- set a device parameter by name
- create or duplicate Arrangement material
- add MIDI notes in Arrangement
- retrieve enough project state to support editing decisions

If any of these are still analysis-only or fallback-only, say so explicitly.

Do not mark them complete unless they were exercised against the open Live project.

### B. Harmonic MIDI backbone must become real arrangement content

The harmonic MIDI backbone must:

- exist in Arrangement, not just Session
- span much more of the song, not only one local region
- be audible and useful for continuity
- help fill gaps where the arrangement currently drops out
- support the user library rather than replacing it

It is acceptable if the timbre is pluck/keys/pad/synth instead of literal piano.

It is not acceptable if the MIDI exists only as metadata or one hidden clip.

### C. Coherence must improve without becoming sterile

The edit pass must reduce:

- mirrored section pairs
- dead gaps between phrases
- silence islands
- same-source overuse
- section-to-section copy-paste feel

At the same time, it must preserve:

- clear structure
- strong recognizable motif
- coherent sound family choices
- continuity across drums, bass and harmony

Do not solve “repetition” by randomizing everything.
Do not solve “coherence” by making every section identical.

### D. Sound freedom with discipline

The system should gain a bit more freedom in sound choice, but inside a coherent frame.

That means:

- allow controlled variation of support layers
- allow section-aware alternates
- keep identity layers constrained
- avoid collapsing everything into 3-4 sounds
- avoid hard lock to one exact symmetric loop

## Acceptance Criteria

The sprint is complete only if all of these are true:

1. the open project `song.als` was used as the validation target
2. MCP editing tools were validated live, not just compiled
3. the open project received a real edit pass
4. harmonic MIDI backbone exists in Arrangement and covers materially more of the song
5. silence islands and mirrored symmetry were measured before and after
6. the result is less empty and less repetitive without losing structure
7. sound selection logic for aggressive snares became more selective instead of a blind blacklist
8. all changed Python files compile
9. relevant tests pass
10. the report includes exact MCP calls used on the open project
11. the report includes exact before/after coherence metrics
12. Codex final verdict is `pass`

## Mandatory Validation

Validation must include all of the following:

### 1. Code validation

- `python -m py_compile` on every changed Python file
- relevant tests for MCP/runtime/coherence

### 2. Live validation

Against the open Ableton project:

- `get_session_info()`
- `get_tracks()`
- `get_track_info(...)`
- the editing tools exercised for real

### 3. Project audit

Run project-facing audits before and after the edit pass, including:

- silence islands
- mirrored section pairs
- harmonic coverage / backbone status
- same-source dominance or reuse
- repeated clip overuse if available

### 4. Audible sanity

The report must state clearly:

- whether the harmonic MIDI is actually audible
- whether gaps were reduced
- whether the project still feels too symmetric
- whether the snare selectivity improved

## Constraints

- Do not generate a new song from scratch.
- Do not replace the project with a fresh template.
- Do not rely on Session-only material and then claim Arrangement success.
- Do not treat wrappers or helper functions as success.
- Do not add vocals.
- Do not force literal piano timbre just because the user said “piano roll”.
- Do not hard-ban `SS_RNBL_Me_Gustas_One_Shot_Snare.wav`; score it contextually.
- Do not overclaim if the edit tools still depend on fragile transport hacks.
- Do not mark complete if the live project still looks obviously symmetrical and full of dead gaps.

## Implementation Guidance

### For MCP capability work

Prioritize tools that matter for editing open projects:

- clip inspection
- device inspection
- parameter editing by name
- Arrangement MIDI editing
- duplication and continuity repair
- project audit tools that reflect real editing pain

If a tool remains inherently limited by the Live API, document the exact limit and the exact fallback.

### For project editing work

Use the project audit as the source of truth.

Then make targeted edits:

- extend harmonic continuity
- reduce dead air
- break mirrored copy-paste shapes
- vary support layers across sections without losing family identity
- tighten selection of snare/clap layers by context

Preferred musical strategy:

- strong recurring identity
- long-form harmonic support
- fewer abrupt disappearances
- section evolution by mutation, layering and phrasing
- support layers changing more than core identity layers

## Required Deliverables

The implementing swarm must produce:

1. code changes
2. a validation report:
   - `docs/SPRINT_v0.1.41_VALIDATION_REPORT.md`
3. if needed, one or more exported JSON artifacts under `temp/`
4. explicit list of changed files
5. exact MCP calls used
6. before/after metric table
7. a short section titled `Remaining Risks`

## Report Format

The validation report must contain these sections:

1. `Summary`
2. `Files Changed`
3. `MCP Tools Validated Live`
4. `Project Edits Applied`
5. `Before/After Metrics`
6. `Snare Selectivity`
7. `Harmonic MIDI Backbone`
8. `What Is Still Weak`
9. `Remaining Risks`

## Failure Conditions

The sprint automatically fails if any of these happen:

- the work validates against a new generated song instead of `song.als`
- `HARMONY_*_MIDI` is still absent from Arrangement in a meaningful way
- the project still has large obvious silence islands with no explanation
- the report claims success but the set still looks geometrically mirrored
- snare handling is “fixed” by crude blacklist instead of contextual scoring
- Codex final verdict is not `pass`

## Recommended Ralph Routing

Use the Ralph defaults already configured locally:

- implementer: `zai_glm51`
- reviewers: `dashscope_qwen3coder_plus`, `dashscope_glm5`
- Codex master: enabled

## Operator Note

This task is intended for the 24/7 Ralph queue.

Suggested submit command:

```powershell
powershell -ExecutionPolicy Bypass -File .\ralph\scripts\Submit-RalphTask.ps1 `
  -SourceFile .\docs\SPRINT_v0.1.41_NEXT_RALPH_OPEN_PROJECT_EDITING.md
```