Phase 33: add a flat modern DAW workspace and track creation workflow

docs/ROADMAP.md

@@ -931,6 +931,35 @@ installation, reproducible source releases and relocatable binary packages pass.
 
 ---
 
+## Phase 33 — Flat Modern DAW Workspace
+
+### Goal
+Give xtc a clear, modern DAW presentation for creating tracks and arranging
+music, with simple flat controls and no 3D styling or proprietary assets.
+
+### Tasks and acceptance criteria
+- [x] Introduce one shared dark palette, typography, flat controls and focus/selection accents.
+- [x] Make track creation, import, instrument loading and MIDI editing visible in a persistent sidebar.
+- [x] Create/select MIDI tracks with clips and audio tracks transactionally, with undo and failure rollback.
+- [x] Organize transport, musical position/BPM, main editors, inspector and status in a resizable workspace.
+- [x] Draw colored track headers, clear clip selection, bar/beat grids and actual MIDI note previews.
+- [x] Preserve existing editing, mixer/automation, graph, plugin, recording and keyboard behavior.
+- [x] Add an original multi-track example and document the workflow and retained limitations.
+- [x] Verify GUI actions, minimum/large layouts, core regressions and release packaging.
+
+### Implementation status
+Implemented in the FLTK GUI without new dependencies, engine changes or a project
+format change. Default workspace 1280 × 800; supported minimum 1220 × 720.
+Track creation is a single undoable prepared-model edit. The transport and
+sidebar inspector are read-only displays; existing editors retain their controls.
+Original four-track example visually checked; GUI tests cover creation,
+selection, rollback, undo/reopen and minimum/large window sizes. This phase
+modernizes presentation and workflow; it does not claim commercial-DAW feature
+parity or add docking, scanning or mixer channel-strip functionality.
+See WORKSPACE.md for the workflow, tests and limits.
+
+---
+
 ## Recommended Execution Order
 
 Reorder the phases when the audit reveals a blocking dependency. Do not mark a phase complete merely because code exists: its acceptance criteria must be demonstrated by builds, tests, or documented manual verification.