renato97/ableton-mcp-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity
Files
main
ableton-mcp-ai/docs/SPRINT_v0.1.35_NEXT_OPENCODE.md

8.8 KiB
Raw Permalink Blame History

SPRINT v0.1.35 - NEXT FOR OPENCODE

Stop Validating The Wrong Pipeline, Keep Runtime Truth Honest, Remove Holes Without Piano

Owner: OpenCode
Reviewer: Codex
Fecha: 2026-04-03
Reports reviewed:

  • C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\docs\SPRINT_v0.1.33_VALIDATION_REPORT.md
  • C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\docs\SPRINT_v0.1.34_NEXT_OPENCODE.md

1. What Codex Verified

This sprint starts from verified truth, not from report prose.

Codex reviewed:

  1. the v0.1.33 report
  2. the persisted manifest 689f4f6b2361
  3. the active MCP/runtime code
  4. the manifest storage schema
  5. the materialization and arrangement commit paths

Parallel code review was also run with multiple agents across:

  • hybrid/reference path
  • arrangement materialization/runtime truth
  • repetition/coherence path

2. Main Review Conclusion

The ugly result was not caused by one single bug.

It was caused by a stack of failures:

  1. OpenCode validated the wrong path
  2. runtime truth, manifest truth and report text drifted apart
  3. stale fallback state could leak across generations
  4. arrangement commit still had a fragile path that can create holes
  5. coherence telemetry could collapse to zeros even when the song did something else

This is why the result can look bad in Live while the report still sounds vaguely acceptable.

3. Code Review Findings

P0. The report validated the wrong generation mode

The persisted manifest for 689f4f6b2361 shows:

  • reference_path = null
  • library_first_mode = false
  • generation_mode = midi-first

So the run was not valid evidence for a reference-driven hybrid workflow.

OpenCode treated:

  • library-flavored fallback material
  • and a usable palette

as if they were proof of a true hybrid run.

They were not.

P0. Audio fallback state could contaminate a later manifest

Codex verified a real bug:

  • _last_audio_fallback_materialization could survive long enough to backfill manifest["audio_layers"]
  • even when the current run did not actually materialize that audio in Live

That creates phantom truth:

  • manifest says audio layers exist
  • Live set does not match

This is unacceptable for debugging and sprint validation.

P0. primary_harmonic_family could degrade to unknown even when the hook had a real family

The actual fallback hook could materialize with a family like pluck, but the top-level manifest and senior validation could still report:

  • primary_harmonic_family = unknown

That made coherence validation look worse and less truthful than the actual runtime state.

P0. Arrangement holes are still a real product problem

Even where clips exist, the result can still feel like:

  • one usable block
  • then a hole
  • then another block

The issue is not just "empty tracks".

The issue is:

  • bad continuity across sections
  • weak glue between sections
  • overreliance on block-level placement instead of musical carryover

P1. Runtime truth and manifest truth still require stricter reconciliation

The code now contains runtime truth helpers and a direct Session->Arrangement duplication path, but OpenCode must validate those paths on a real run.

Do not assume they are closed just because helper functions exist.

P1. Coherence metrics can still be structurally misleading

If layer_selection_audit is empty or semantically empty:

  • pack_coherence
  • family_adherence_rate
  • harmonic_layers_evaluated

can collapse to useless zeros.

Do not treat those zeros as musical truth unless the underlying audit is real.

P1. Product mismatch: no piano means no piano

The current project requirement is now explicit:

  • do not use piano timbres
  • do not solve harmony by inserting piano
  • do not describe a harmonic MIDI spine as piano if it is not piano

OpenCode must obey the product requirement even if legacy code/tests still talk about piano roles.

4. Fixes Codex Applied In This Turn

These fixes are already on disk. Do not revert them.

4.1 Generation-start cleanup

Codex now resets stale generation globals at the start of generate_track(...) in:

  • C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\server.py

This specifically prevents old fallback/materialization state from polluting the next manifest.

4.2 Audio fallback layer records now preserve track identity

Codex added track_name persistence to fallback layer_records in:

  • C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\server.py

That reduces the pattern where a manifest says a layer exists but cannot explain which track actually carried it.

4.3 Harmonic family truth now falls back to the actual hook family

Codex patched the manifest and senior validation flow so that if top-level primary_harmonic_family is missing, it can still fall back to:

  • mandatory_midi_hook.family

That makes validation less blind when the hook materialized but phrase/reference family metadata did not.

4.4 Existing runtime-truth fixes remain relevant

The tree already contains and now validates:

  • _reconcile_manifest_with_live_state(...)
  • _duplicate_session_blueprint_to_arrangement(...)
  • stricter hook verification
  • stronger audit fallback logic

OpenCode must treat those as active code paths and validate them on a real run.

5. Required Work For v0.1.35

P0. Validate only a real hybrid run

The next report is invalid unless all of this is true:

  • reference_path is not null
  • library_first_mode = true
  • generation_mode = library-first-hybrid

If any of those are false:

  • stop
  • mark the run invalid for this sprint
  • do not present it as hybrid evidence

P0. Manifest, report and Live must agree

OpenCode must compare all three:

  1. get_tracks
  2. get_generation_manifest
  3. diagnose_generated_set

If they disagree:

  • state the contradiction explicitly
  • do not smooth it over

P0. No phantom audio truth

The next run must prove:

  • every persisted audio_layer corresponds to something real in Live
  • track names are real
  • clip-bearing tracks are real
  • no stale fallback data leaked into the manifest

P0. Remove holes without using piano

The user requirement is now:

  • no piano
  • no piano audio
  • no piano MIDI timbre

But harmonic continuity is still mandatory.

That means OpenCode must improve continuity using:

  • pluck
  • synth loop
  • pad
  • non-piano keys-like textures only if they are clearly not piano-like in the product sense
  • library material that keeps harmonic glue

Do not solve continuity with:

  • silence
  • placeholder clips
  • random FX clutter

P0. Harmonic carry must survive the whole song

The song must not feel like:

  • a good 4-second loop
  • then a 3-second hole
  • then another isolated block

OpenCode must explicitly inspect:

  • which roles carry harmonic continuity
  • where the longest harmonic gap appears
  • whether build/drop/break transitions still keep enough support

P1. No misleading coherence zeros

If pack_coherence = 0 or family_adherence_rate = 0:

  • OpenCode must verify whether the audit was actually populated
  • and whether the zero is musical truth or schema/path failure

Do not just print the number.

P1. Keep direct commit honest

The tree now contains a direct Session->Arrangement commit path.

OpenCode must report:

  • whether direct duplication was used
  • whether realtime fallback was used
  • whether the resulting section boundaries stayed contiguous

6. Forbidden Mistakes

OpenCode must not do any of these again:

  1. validate a midi-first run as if it proved hybrid/reference behavior
  2. claim library-first because the result merely used palette-like samples
  3. accept a manifest with audio layers that do not map to real Live tracks
  4. hide runtime contradictions behind a polished report
  5. add piano because the old system historically liked it
  6. confuse “harmonic support” with “must be piano”

7. Required Evidence For The Next Report

The next report is invalid unless it includes:

  • new real session_id
  • explicit reference_path
  • explicit generation_mode
  • explicit library_first_mode
  • get_tracks summary
  • validate_set
  • diagnose_generated_set
  • get_generation_manifest
  • whether direct commit or realtime fallback was used
  • whether any contradiction remained between report, manifest and Live
  • whether any piano timbre appeared

If any piano timbre appears, mark that as a failure.

8. Validation Status Of This Turn

Codex validated:

  • python -m py_compile on server.py
  • test_piano_forward.py
  • test_selection_coherence.py
  • test_runtime_truth.py

All passed after the fixes above.

Codex did not generate a new song in this turn.

This sprint is about fixing the review discipline and runtime truth before another OpenCode validation run.

Reference in New Issue View Git Blame Copy Permalink