Sync: Complete project state with all MEGA SPRINT V1-V3 features and Codex stubs

2026-04-08 17:58:47 -03:00
parent c9d3528900
commit 6d080d43b3
372 changed files with 189715 additions and 8590 deletions
--- a/docs/autopilot/20260403-203809-next-task-manual.md
+++ b/docs/autopilot/20260403-203809-next-task-manual.md
@@ -0,0 +1,219 @@
+# SPRINT v0.1.42 - Live Proof of Open-Project Editing
+
+## Goal
+
+Validate and use the existing MCP editing path on the already-open Ableton project:
+
+- C:\Users\ren\Desktop\song Project\song.als
+
+This sprint is not a generation sprint and not a wrapper-expansion sprint.
+
+It is a runtime-proof sprint:
+
+- prove the MCP can inspect the real open project
+- prove the MCP can apply real Arrangement edits on that project
+- prove the edits improve coherence in measurable ways
+- document exact evidence or fail explicitly
+
+## Why This Task Exists
+
+The previous run failed.
+
+Repository truth from the failed run:
+
+- infrastructure was added in AbletonMCP_AI/MCP_Server/server.py
+- contextual snare scoring was added in AbletonMCP_AI/MCP_Server/sample_selector.py
+- docs/SPRINT_v0.1.41_VALIDATION_REPORT.md was corrected to an honest fail
+- no live MCP calls were exercised against song.als
+- no real edit pass was applied
+- no before/after coherence metrics were captured
+- no proof exists that the new editing tools work through the real Ableton runtime path
+
+The highest-signal blocker is now obvious:
+
+- stop adding unvalidated infrastructure
+- prove runtime behavior on the open project
+- if runtime behavior is blocked, isolate the exact blocker with raw evidence
+
+## Required Work
+
+1. Prove the live target is the real open project.
+- Connect through the MCP to the active Ableton session.
+- Capture enough session evidence to prove the target is the already-open song.als session and not a generated set or blank template.
+- Save raw outputs under temp/.
+
+2. Validate the existing MCP tool path live before adding more tools.
+- Exercise these tools against the open project and record exact calls plus raw outputs:
+  - get_session_info()
+  - get_tracks()
+  - get_track_info(...)
+  - get_clips(...)
+  - get_clip_info(...)
+  - get_devices(...)
+  - get_device_parameters(...)
+  - set_device_parameter_by_name(...)
+  - one arrangement creation or duplication path
+  - one arrangement MIDI note insertion path
+- For each tool, classify it as:
+  - live validated
+  - failed live
+  - blocked by backend/runtime limitation
+- Do not mark a tool complete just because it compiles.
+
+3. If a live tool path fails, fix only the minimal blocker.
+- Use the existing code added in v0.1.41 as the starting point.
+- If a backend handler or runtime path is missing, add the smallest fix needed in the real runtime path.
+- Re-run the exact same MCP call after the fix and save the before/after evidence.
+- Do not add unrelated new feature surface.
+
+4. Audit the open project before editing.
+- Run project-facing audits on the real song.als session.
+- Capture exact before metrics for:
+  - silence islands
+  - mirrored section pairs
+  - harmonic coverage / harmonic backbone status
+  - same-source dominance or repeated-source overuse
+  - repeated clip overuse if available
+- Save raw outputs under temp/.
+- Use these audits to choose the edit targets.
+
+5. Apply a bounded real edit pass on song.als.
+- Use the validated MCP editing tools on the real open project.
+- The edit pass must be small, targeted, and measurable.
+- Prioritize:
+  - extending or repairing harmonic MIDI backbone in Arrangement
+  - reducing dead gaps
+  - breaking at least one mirrored or obviously repeated arrangement shape
+  - improving continuity without destroying identity
+- The harmonic MIDI backbone must become real Arrangement content intended to be audible.
+- It is acceptable to use keys, pluck, pad, or synth timbre.
+- It is not acceptable to leave the backbone as metadata, a hidden clip, or an empty placeholder.
+
+6. Validate snare selectivity in the real path.
+- Do not hard-ban SS_RNBL_Me_Gustas_One_Shot_Snare.wav.
+- Prove whether the new contextual snare scoring actually affects selection in real use.
+- If the logic exists but is not wired into the live path, wire the minimal real path and validate it.
+- Record exact evidence showing whether lower-energy sections are treated more conservatively than higher-energy sections.
+
+7. Re-audit after editing.
+- Run the same project-facing audits again.
+- Save raw after-state outputs under temp/.
+- Produce an exact before/after table using measured values, not estimates.
+- State clearly what improved, what stayed flat, and what regressed.
+
+8. Keep the scope disciplined.
+- Touch only the files directly required to validate or minimally fix the runtime editing path.
+- Likely files:
+  - AbletonMCP_AI/MCP_Server/server.py
+  - AbletonMCP_AI/MCP_Server/sample_selector.py
+  - abletonmcp_init.py
+  - AbletonMCP_AI/abletonmcp_runtime.py
+  - docs/SPRINT_v0.1.42_VALIDATION_REPORT.md
+- Do not add broad new capability areas unless they are the direct blocker to a required live validation step.
+
+9. Fail fast if the runtime is not reachable.
+- If Ableton, the control surface, or the MCP connection is unavailable, do not continue building infrastructure.
+- Capture the exact failing step and raw evidence.
+- Mark the sprint failed with specific blocker evidence.
+- A code-only partial success is not acceptable for this sprint.
+
+## Acceptance Criteria
+
+This sprint passes only if all of the following are true:
+
+1. The live validation target is the already-open song.als project.
+2. Exact MCP calls and exact raw results are recorded for the validated live tool sequence.
+3. At least one real Arrangement edit is applied through the MCP path on the open project.
+4. At least one real Arrangement MIDI operation is applied on the open project, or the report proves the exact runtime limitation with raw evidence.
+5. Harmonic MIDI backbone exists in Arrangement as meaningful content over materially more of the song than before.
+6. Before and after project-audit metrics are captured from the real open project with exact values.
+7. The after state shows at least one concrete improvement in coherence metrics, such as fewer silence islands, fewer mirrored pairs, stronger harmonic coverage, or reduced repeated-source dominance.
+8. Snare selectivity is validated in the real selection path, not only described from source code.
+9. All changed Python files compile.
+10. Relevant tests for touched MCP/runtime/coherence code pass.
+11. The validation report is strict and honest about what was and was not validated live.
+12. Codex can reasonably return pass from repository evidence alone.
+
+Automatic fail conditions:
+- validation remains code-only
+- no exact MCP call log exists
+- no before/after metrics exist
+- no live edit was applied to song.als
+- the run validates against a new generated song or different session
+- the report claims completion without runtime evidence
+
+## Validation
+
+Produce all of the following artifacts:
+
+1. docs/SPRINT_v0.1.42_VALIDATION_REPORT.md
+Required sections:
+- Summary
+- Files Changed
+- Live Target Proof
+- MCP Tools Validated Live
+- Project Audits Before
+- Project Edits Applied
+- Project Audits After
+- Before/After Metrics
+- Snare Selectivity
+- Harmonic MIDI Backbone
+- What Is Still Weak
+- Remaining Risks
+
+2. temp/v04142_live_target_proof.json
+- raw evidence proving the active Ableton session is the intended open project
+
+3. temp/v04142_mcp_calls.jsonl
+- one JSON line per MCP call
+- include tool name, arguments, success or failure, and raw result or raw error
+
+4. temp/v04142_before_audit.json
+- raw before-state audit outputs
+
+5. temp/v04142_after_audit.json
+- raw after-state audit outputs
+
+6. temp/v04142_edit_actions.json
+- exact live edits attempted and whether each succeeded
+
+7. If blocked, replace missing success artifacts with:
+- temp/v04142_blocker_evidence.json
+- include the exact failing step, exact raw response, and why the sprint could not proceed
+
+Required validation actions:
+- python -m py_compile on every changed Python file
+- relevant tests for touched runtime/MCP/coherence code
+- live MCP calls against the open project
+- before and after audits on the same open project session
+
+## Context
+
+Read these first:
+
+- previous failed run directory:
+  - C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-195932-queue
+- previous summary:
+  - C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-195932-queue\SUMMARY.md
+- previous reviews:
+  - C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-195932-queue\reviews\codex_master_pre_fix.json
+  - C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-195932-queue\reviews\opencode_qwen3coder_plus.json
+  - C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-195932-queue\reviews\opencode_glm47.json
+- previous validation report:
+  - docs/SPRINT_v0.1.41_VALIDATION_REPORT.md
+
+Primary source files:
+- AbletonMCP_AI/MCP_Server/server.py
+- AbletonMCP_AI/MCP_Server/sample_selector.py
+- abletonmcp_init.py
+- AbletonMCP_AI/abletonmcp_runtime.py
+
+Execution priority for this sprint:
+1. prove live target and MCP connectivity
+2. validate existing tools live
+3. minimally fix only the runtime blockers that prevent validation
+4. apply one bounded real edit pass
+5. capture before/after evidence
+6. report strictly from repository truth
+
+Do not overclaim. This sprint exists to turn unvalidated open-project editing infrastructure into demonstrated live behavior on the real Ableton session.
--- a/docs/autopilot/20260403-211423-autofollowup-sprint-v0-1-42-live-proof-of.md
+++ b/docs/autopilot/20260403-211423-autofollowup-sprint-v0-1-42-live-proof-of.md
@@ -0,0 +1,238 @@
+# 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.
+
+## Acceptance Criteria
+
+This sprint passes only if all of the following are true:
+
+1. The live target is the already-open song.als session.
+2. The run makes at least one real source-code change in the runtime or selection path, unless an already-existing code path is conclusively shown to be the canonical supported fallback and is validated end-to-end live.
+3. At least one real Arrangement content edit is applied on the open project to improve harmonic continuity or fill a real weak span.
+4. The backbone goal is met either by:
+- meaningful Arrangement MIDI backbone content added live
+- or a documented and validated supported fallback path that adds backbone-like Arrangement content when MIDI insertion is blocked
+5. At least one coherence metric in the saved before/after evidence improves materially.
+6. The run validates the previously missing live tool coverage:
+- get_tracks()
+- get_device_parameters(...)
+- set_device_parameter_by_name(...)
+7. Snare selectivity is validated through a real runtime path across at least two section contexts.
+8. All changed Python files compile.
+9. Relevant tests for touched code pass.
+10. The validation report contains exact raw evidence references and does not overclaim.
+11. Codex can reasonably return pass from repository evidence alone.
+
+Automatic fail conditions:
+- no source-code or real wiring change is made while blockers remain
+- only property edits are applied again
+- backbone remains absent and no validated fallback is delivered
+- all saved coherence metrics remain flat again
+- snare selectivity is still argued from inference instead of runtime evidence
+- the report claims success without a measurable improvement
+
+## 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
+
+## Context
+
+Read these first:
+
+- previous run directory:
+  - C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-203815-queue
+- previous summary:
+  - C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-203815-queue\SUMMARY.md
+- previous reviews:
+  - C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-203815-queue\reviews\codex_master_pre_fix.json
+  - C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-203815-queue\reviews\opencode_qwen3coder_plus.json
+  - C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-203815-queue\reviews\opencode_glm47.json
+- previous validation report:
+  - docs/SPRINT_v0.1.42_VALIDATION_REPORT.md
+
+Most important evidence files from the previous run:
+- temp/v04142_mcp_calls_final.jsonl
+- temp/v04142_comprehensive_validation.json
+- temp/v04142_audio_pattern_results.json
+- temp/v04142_edit_actions.json
+
+Primary source files:
+- AbletonMCP_AI/MCP_Server/server.py
+- abletonmcp_init.py
+- AbletonMCP_AI/abletonmcp_runtime.py
+- AbletonMCP_AI/MCP_Server/sample_selector.py
+
+Execution priority for this sprint:
+1. preserve the proven live connection and working arrangement-audio path
+2. make the blocked backbone path succeed, or formalize a supported fallback in code
+3. validate the previously missing live MCP tools
+4. deliver one measurable coherence improvement
+5. validate snare selectivity in a real runtime path
+6. report only what repository evidence proves
+
+Do not overclaim. The previous run proved that live editing is partially possible. This sprint exists to turn that partial proof into a repeatable, code-backed, measurable project improvement.