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

docs/SPRINT_v0.1.43_NEXT_GLM_MANUAL_OPEN_PROJECT_EDITING.md

@@ -0,0 +1,169 @@
+# SPRINT v0.1.43 - GLM Manual Open Project Editing
+
+## Audience
+
+GLM via OpenCode, with manual review by Codex after implementation.
+
+## Context
+
+Before coding, read:
+
+1. `C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AGENTS.md`
+2. `C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\CLAUDE.md`
+3. `C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\docs\PROJECT_AUDIT_song_2026-04-03.md`
+4. this sprint file
+
+Do not rely on old "completed" reports without checking current code and the current open set.
+
+## Working Mode
+
+- This sprint is manual, not autopilot.
+- Work against the currently open project `C:\Users\ren\Desktop\song Project\song.als`.
+- Do not generate a brand-new song.
+- Use MCP live evidence and code changes together.
+
+## Why This Sprint Exists
+
+The repo guidance was too generic and the implementation flow drifted into:
+
+- overly symmetrical arrangements
+- too many silent gaps
+- weak harmonic continuity
+- reports that overstated closure
+- confusion between "harmonic MIDI" and "must sound like a piano"
+
+That guidance has now been rewritten in `AGENTS.md`, `CLAUDE.md`, `.cursorrules`, and `.github/copilot-instructions.md`.
+Use those files as the repo contract for this sprint.
+
+## Product Direction
+
+The target sound should feel:
+
+- coherent
+- editable
+- less empty
+- less mirrored
+- more musically continuous
+- freer in sound selection without becoming random
+
+Important:
+
+- harmonic MIDI is desired
+- forced piano timbre is not desired
+- automatic vocals are not desired
+
+## Code Review Findings You Must Respect
+
+1. The project currently overuses short repeated blocks and visible mirror symmetry.
+2. Harmonic support often exists in theory but not enough in Arrangement.
+3. Silent gaps are still too common and too large.
+4. Some agents overfit to manifests and under-validate the actual open set.
+5. The open-project editing path is more important than another generation path.
+
+## Goals
+
+### G1. Improve open-project editing tools
+
+Strengthen MCP editing for already-open projects. Prioritize real inspection and mutation tools that help continue `song.als`.
+
+### G2. Improve coherence and continuity
+
+Reduce structural holes and increase harmonic continuity across the arrangement.
+
+### G3. Restore sound-selection freedom without losing coherence
+
+The system should not always choose the same tiny set of sounds, but the result should still feel like one song.
+
+## Required Coding Work
+
+### T1. Inspect and harden open-project editing tools
+
+Review and improve the tools used for:
+
+- track inspection
+- clip inspection
+- device parameter inspection
+- arrangement clip editing
+- harmonic repair or continuity repair
+
+If a tool is only `analysis_only`, say so explicitly in code and report. Do not market it as full editing.
+
+### T2. Reduce silence-driven "variation"
+
+Any logic that creates variation primarily by removing content and leaving empty space should be reduced or made more selective.
+
+Variation should come more from:
+
+- section-aware substitutions
+- clip continuity edits
+- density changes that keep a backbone alive
+- harmonic support that survives transitions
+
+### T3. Keep harmonic MIDI alive across the song
+
+If the project has a harmonic MIDI backbone, it should help fill structural holes across the arrangement.
+
+This does not mean "make it sound like a piano."
+It means the harmonic lane should exist, be editable, and support the song over time.
+
+### T4. Make sound choice slightly freer but still coherent
+
+Relax over-rigid sameness where it causes "the same 3 sounds forever."
+
+But do this with coherence-aware logic:
+
+- family compatibility
+- pack compatibility
+- section role
+- continuity of musical identity
+
+Do not replace one rigid system with random selection.
+
+## Validation Requirements
+
+You must validate on the open project, not only in tests.
+
+### Required runtime evidence
+
+- exact MCP calls used
+- before/after project audit
+- proof of the edited target tracks, clips, or devices
+- proof that the open project remained stable
+
+### Required code validation
+
+- `py_compile` on every changed Python file
+- targeted tests relevant to the touched area
+
+### Minimum report contents
+
+Your report must include:
+
+- files changed
+- exact MCP calls issued
+- before/after evidence for coherence or continuity
+- what is still partial or not yet proven
+- what remains manual-only
+
+## Hard Failure Conditions
+
+The sprint is not complete if any of these are true:
+
+- you only improved docs and not the tool path
+- you used a generated set instead of the open project
+- you claimed harmonic improvement without proving Arrangement-level evidence
+- you introduced more empty space while claiming better variation
+- you conflated harmonic MIDI with mandatory piano timbre
+- you gave only manifest evidence and not MCP or live evidence
+
+## Deliverables
+
+1. code changes
+2. `docs/SPRINT_v0.1.43_VALIDATION_REPORT.md`
+3. runtime artifacts in `temp/` if needed
+4. a concise section listing what still is not fully solved
+
+## Final Reminder
+
+The bar is not "the tool exists."
+The bar is "the open project became easier to continue, less empty, and more coherent without becoming rigid or generic."