2026-08-12 - Voice 49 Should Neither Click Nor Eat Voice 50

Architectural connection

SpaceAge still owns a strict 48-voice main pool, but an unavoidable steal of a voice that has already produced audio now moves that voice into a fixed 48-slot retirement bank for a six-millisecond fade. Retirement audio travels through the same Mixer channel, pan, compressor, saturation, sends, metering, and Master path as the original voice. The bank is fixed-capacity: pool pressure cannot allocate memory or acquire a lock on the audio callback.

Voice allocation now has an explicit monotonically increasing start serial. Age alone cannot distinguish notes created in the same sample, so the serial makes 48-to-64-note chord and arpeggio bursts deterministic and prevents repeated replacement of one incoming slot. Delayed and never-rendered notes do not receive meaningless tails. Victim loudness is measured after lane routing rather than before it, so mute, solo, gain, and pan affect the definition of "quietest."

SoundFont voices have an additional connection to resource ownership. Each of the 48 prepared TSF playback instances must be returned before voice 49 can start. The stolen voice therefore returns its instance immediately and finishes with a lightweight captured stereo sample rather than retaining the complete SoundFont renderer. Hard stop, Panic, project reset, and pad stop clear both main voices and retirement tails.

Creative extensions

• The same retirement bank can support future instrument hot-swap and scene changes without clicks, provided those transitions remain bounded and callback-safe.
• Routed loudness is a useful seed for musician-facing voice-priority modes such as bass protection or lead protection, but such modes should remain explicit rather than inferred.
• Deterministic start serials can support per-note expression inspection and reproducible polyphony diagnostics without exposing internal IDs to musicians.

Verification and human review

Automated proof covers all 13 native engines, exact 288-sample retirement at 48 kHz, 48 sounding plus 48 retiring voices, an additional 16-note same-sample burst, SoundFont voice 49, hard-stop cleanup, finite stereo output, bounded peaks, and real-time timing. The complete 619-preset sweep, SoundFont lifecycle, hostile resource replacement, asset retirement, audio safety, MIDI closeout, and eight polyphonic CPU profiles also pass. Human listening should still judge whether dense overflow sounds graceful on real projects and audio hardware.

Agent contributions

Avicenna found SoundFont resource starvation and demanded exact fade/stereo proof. Hooke found callback sanitation, same-sample overflow, pre-routing loudness, and a test that had not rendered the claimed overlap. LT resolved every finding in production behavior and expanded the executable gates.

2026-08-12 - A Factory Preset Is A Promise To Make Sound

Architectural connection

Preset verification now joins saved-state truth to rendered-audio truth. The existing 619-preset fingerprint answers, "Did the intended parameter inventory load?" The new audio matrix separately answers, "Did that state actually become finite, audible, bounded sound and then release?" Keeping these contracts distinct makes failures useful: one points to recall/provenance, the other to DSP or envelope behavior.

The same pass connected preset confidence to polyphony policy. Every native engine now reports a shared post-envelope output magnitude to the bounded voice allocator. Future delayed notes are considered expendable before current audible notes, so an arpeggio or strum cannot reserve tomorrow's voice by abruptly deleting today's bass line.

Creative extensions

• The measured quietest, hottest, and longest-release presets can seed future loudness-normalization and preset-browser metadata without altering the sounds today.
• The deterministic per-preset seed can support repeatable waveform thumbnails and automated patch-comparison captures.
• The shared voice-importance signal is a foundation for a short de-click tail if all 48 voices are genuinely audible and one must still be stolen.
• The rendered-preset matrix can later absorb register, velocity, and aftertouch profiles while preserving the same engine/preset diagnostics.

Verification and human review

All 619 factory presets pass sustained audibility, finite output, raw peak, natural release, and silent-tail checks. All 13 native engines preserve an audible target at the 48-to-49 voice boundary. Human listening remains required for musical usefulness, tonal balance, and whether the quietest/loudest sounds feel appropriately matched.

Agent contributions

Avicenna separated real audibility from numerical residue and caught that forced cleanup could not prove natural release. Hooke found the TG-55-only victim metric and the risk of future delayed notes stealing present audio. LT integrated both findings into production behavior and deterministic release gates.

2026-08-11 - Factory Presets Must Own Envelope Shape

• A named factory preset should be a reproducible musical object, not a partial suggestion contaminated by the patch that preceded it.
• Propulsion 1, Liftoff, Glass Moon, Moonshadow, and Lunacy now explicitly recall a neutral A-D slope alongside their attack, decay, sustain, and release values.
• This same deterministic-recall principle should govern future Motion Blocks and patch morphing: deliberate variation belongs in an explicit modulation layer, never in accidental inherited state.

2026-08-11 - Filter Mode Truth Across Instruments

• Treat filter bypass as one shared visual contract: when FILTER TYPE is Off, controls that cannot affect sound are dimmed rather than pretending to remain actionable.
• Preserve disabled values so switching the filter back on restores the sound designer's prior cutoff, resonance, envelope, velocity, and LFO choices.
• Reuse the same refresh path for direct clicks, preset recall, undo, automation, and instrument-slot changes. This connects honest control presentation to the existing patch lifecycle instead of adding per-engine exceptions.
• Keep post-filter or otherwise independent controls, such as drive and vibrato, active. Contextual dimming should teach signal flow without making the editor feel unavailable.

2026-08-11 - Musical Range Is Part Of An Instrument's Contract

Task: Close the gap between one-note synth smoke tests and the way a musician actually judges an instrument.

Creative connection: Low, middle, high, and chord playback connect synthesis design to songwriting workflow. The same compact performance matrix can later protect imported SoundFonts, Quasar packages, hardware-preview paths, and future internal instruments without pretending that automated pitch and amplitude checks can replace human taste.

Architecture choice: Extend the existing factory-instrument contract rather than create another isolated gate. Every tonal native engine must now retain note identity in three registers, remain finite and bounded, release cleanly, and sustain three simultaneous voices for a C major chord. The test exposed unrelated per-grain oscillator resets in Lunacy, so generated grains now inherit a continuous per-voice phase clock while retaining independent windows, scan positions, pitch spread, and motion.

Subagents: Avicenna stalled during exposed-control audio-path mapping and was closed. Hooke completed the register/chord-safety review and identified the missing note-identity and true-polyphony contracts; that finding was incorporated into this gate.

Human review flag: This proves pitch identity, playable signal continuity, polyphony, bounded output, and release behavior. A musician must still judge aliasing, useful timbre, dynamics, and chord character across the keyboard.

2026-08-11 - Useful Knob Travel Is A Product Contract

Task: Prove that representative native-synth controls remain audible through ordinary working ranges rather than changing only at extreme endpoints.

Creative connection: A musician experiences a synth through the distance between two mouse positions, not through parameter registration. Mid-range audio proof connects DSP scaling, rotary-drag feel, preset design, automation usefulness, and future hardware mapping under one customer-facing rule: ordinary movement must produce an intelligible musical response.

Architecture choice: Seven moderate-range comparisons now run inside the existing rendered-audio quality gate. They cover Propulsion pulse width, Liftoff warp, Glass Moon brightness, Moonshadow tilt, Lunacy texture, Physical Model material, and TG-55 brightness. Endpoint tests remain because they prove range breadth; the new matrix proves usable travel.

2026-08-11 - Native Synth Fourth-Path Proof

Task: Extend native-instrument quality proof beyond basic sound, source, level, and broad tone controls.

Creative connection: Control variety is part of product quality. Each major engine now receives a fourth measured audio path chosen from a different synthesis dimension: pulse width, wavetable motion, FM operator balance, spectral tilt, granular texture, physical tension, or TG-55 motion. The same evidence can later guide preset-browser metadata and the planned AI patch assistant without teaching either system to rely on decorative controls.

Architecture choice: The new checks deliberately avoid duplicating the already-proven source, level, filter, and broad brightness paths. A control must change the rendered waveform while remaining finite and audible, giving future human and AI maintainers a useful failure instead of a superficial binding check.

2026-08-11 - Tonal Safety And Sound-Design Freedom Can Coexist

Task: Determine whether native synth controls are audibly functional, sensibly ranged, and appropriate for tonal music.

Creative connection: A control can serve two musical worlds without confusing them. Chord-safe defaults make a new Instrument immediately trustworthy, while clearly identified advanced controls preserve metallic, spectral, granular, and FM experimentation. The same classification can later guide preset-browser metadata, classroom modes, AI patch creation, and a simplified sound-design view without creating separate DSP engines.

Architecture choice: The shared tonal engines now use one stable filter topology. Chord-safe initialization is enforced independently from factory-preset creativity. Advanced controls publish tonal-safety metadata and explanatory tooltips instead of being deleted. Vestigial Lunacy-local effects parameters were removed because effects ownership belongs to the Mixer.

Verification: SYNTH_CONTROL_QUALITY now combines 712-control UI/Undo/accessibility proof, Redshift waveform/filter measurement, shared-filter bypass/response measurement, and two independent audible paths in each of seven additional native engines. Propulsion 1 waveform/level, Liftoff wavetable/level, Glass Moon algorithm/feedback, Moonshadow model/stretch, Lunacy source/pitch, Physical Model tune/material, and TG-55 level/brightness can no longer borrow confidence from one neighboring working control. Chord-safe default assertions remain part of the same gate.

Subagents: Two read-only independent reviews were assigned for beta-blocker ranking and synth-control skepticism, but the dispatcher stalled before returning agent identities. They were terminated and contributed no findings; the expanded proof was implemented and reviewed locally.

Human review flag: Sweep every exposed control while auditioning single notes and dense chords in multiple registers. Automated difference proves influence and safety, not that every centimeter of travel is musically excellent.

2026-08-11 - Release Gates Must Count What The App Actually Embeds

Task: Continue launch priorities after Redshift by reconciling release-asset cardinality.

Architecture choice: SampleSquadAssets, ReleaseAssetClearance.json, and the audit agree on 16 embedded resources: five first-party artwork files, Inter, nine TG55 audio files, and the TG55 catalog. The hygiene gate had drifted to an unimplemented 17-resource assumption; it now enforces the actual one-to-one set of 16 without weakening any hash or evidence requirement.

Launch boundary: Fifteen resources remain correctly blocked on human rights/provenance decisions. The code gate can prove coverage and identity, but it cannot make those business decisions.

2026-08-11 - A Knob Should Spend Its Travel On Useful Sound

Task: Refine Redshift's rotary controls for maximum usability while continuing launch-critical stability work.

Creative connection: A rotary control is both an editor and a miniature map of a sound. Frequency, tuning, and time controls need surgical travel; levels and timbral amounts need confident sweeps; integer degradation controls should feel stepped and show whole numbers. Applying one generic mouse curve to all three jobs makes the instrument feel cheaper than its DSP.

Architecture choice: Redshift now assigns precision, sweep, or stepped interaction by parameter role, publishes unique control identities and parameter-specific help, and shows units with suitable decimal precision. Oscillator 2 resets to chord-safe 1.000x. Oscillator Spread grows continuously from zero rather than jumping immediately to two cents. Drive is owned by one shared post-engine saturation stage instead of being silently applied twice inside Redshift.

Verification: SYNTH_CONTROL_QUALITY covers control identity, travel, help, reset behavior, integer readouts, all 12 waveforms, filter behavior, bounded Drive, continuous Spread, Undo, and finite output. The canonical 619-preset fingerprint is 4d2ddc400437c5d6; no preset was added or removed.

Future extensions: Reuse the precision/sweep/stepped vocabulary when polishing the remaining native Instruments, but keep each engine's actual DSP ranges independent. A visual knob family may be shared; a musical response curve should not be shared blindly.

Subagents: Test and documentation sidecars were requested, but the dispatcher stalled before returning usable agent IDs. No subagent result was used; implementation, tests, and documentation were completed locally.

2026-08-11 - Starting Points Are Instruments, Not Decorative Buttons

Task: Promote the Library Starting Point audio contract into canonical release convergence and reconcile factory-preset identity.

What connects creatively: A Starting Point is the shortest route from curiosity to sound. Testing its production callback, engine ownership, complete generated pad set, and audible output connects Library workflow, Instrument identity, preset safety, and release packaging in one customer-facing promise.

Architecture choice: Canonical convergence now names I01-C and runs all nine production Starting Point callbacks across 528 generated slots. The complete 619-preset runtime sweep remains the source of truth for preset identity; its verified 4d2ddc400437c5d6 fingerprint is synchronized through the machine inventory, hygiene gate, provenance record, and package evidence while older dated receipts remain historical.

Future extensions: Use the same callback-to-audio contract for templates, imported preset libraries, future Instrument Bay categories, and educational Starting Points. Every one-click musical doorway should prove that it creates the advertised owner, finite state, audible output, and clean teardown.

2026-08-10 - A Saved Patch Must Not Depend On The Previous Sound

Task: Make native patch loading deterministic and close the exposed-but-unwired A-D slope path.

What connects creatively: A preset is a complete musical promise, even when an older patch file omits controls introduced later. Filling omitted registered controls from factory defaults makes audition order irrelevant. Requiring every visible patch field to have registration, persistence, audio consumption, and proof keeps the Instrument Bay honest as more engines arrive.

Architecture choice: Native patch load now preflights every value before mutation, rejects malformed or out-of-range data without disturbing the current sound, and recalls omitted known controls to their declared defaults. The shared A-D slope is now a registered APVTS parameter, shapes the audible decay segment, survives save/reopen, and has an audio regression that compares opposite curve extremes.

Future extensions: Apply this inventory contract to engine-specific controls, the future preset browser, hardware editor parameters, VST wrappers, and Quasar metadata. A control should never become customer-visible until its registration, consumer, persistence, Undo, and focused proof all exist.

2026-08-08 - Automation History Must Restore What The Musician Hears

Task: Make Automation Undo and Redo reconcile the live controller state, then finish the popup's delete feedback, readability, and display containment.

What connects creatively: An automation curve is both project data and a sounding performance layer. History is trustworthy only when restoring the drawing also restores the effective Shared Pattern, Lane Local, or Clip Local value heard through the instrument and routed hardware.

Architecture choice: Full-state history captures the union of Automation rows before and after restoration, then refreshes each affected lane through the same ownership resolver used by live editing. Removed rows reveal lower owners or neutral; restored rows become audible immediately. The popup preserves whole-row delete receipts, uses one readable graph-font floor, and caps its shell to the current display while keeping the full editor reachable through scrollbars.

Future extensions: Reuse the before/after reconciliation pattern for any project history that owns live DSP or hardware state. Add physical-device proof for layered external-controller fallback and extend owner-stack visualization so musicians can see what Undo will reveal before invoking it.

2026-08-08 - Removing An Automation Layer Should Reveal What Is Underneath

Task: Make Automation deletion truthful across Shared Pattern, Lane Local, and Clip Local ownership.

What connects creatively: Automation owners behave like transparent musical layers. Removing a local override should reveal the broader movement underneath it, not erase the parameter's entire history or leave playback stuck at a neutral value.

Architecture choice: Live refresh now follows playback precedence (Shared PTN -> Lane Local -> Clip Local). Deleting or clearing a higher owner reapplies the surviving lower-owner value immediately to both internal playback and the scoped hardware route; only the final owner removal sends a neutral reset.

Future extensions: Reuse this layered-resolution rule for visible effective-value readouts, owner-stack previews, per-point provenance, and a one-click REVEAL SOURCE action in the Automation editor.

2026-07-30 - Progress Is Part Of File Trust

Task: Make portable project export/import visibly responsive without moving unsafe processor access onto a background thread.

What connects creatively: A progress window is not mere decoration. When a project contains a giant SoundFont or a deep Quasar package, visible motion tells the musician that SpaceAge is protecting and transporting their work rather than ignoring the command. The same trust language belongs in Quasar capture, stems, full-song render, sample analysis, and future VST scanning.

Architecture choice: SpaceAge captures a stable archive plan on the message thread, performs ZIP creation or hostile-archive inspection/extraction on a worker, and returns validated project loading to the message thread. Determinate stage callbacks drive the progress display. There is deliberately no fake Cancel button while the underlying ZIP operation cannot stop cooperatively.

Future extensions: Reuse this job boundary for a unified long-operation surface with stage names, elapsed time, safe shutdown behavior, and cancellable phases only where cancellation is truthful.

2026-07-30 - Musical Patterns Stay Portable Across Instruments

Task: Resolve the Arranger regression at the boundary between shared MIDI patterns and lane-owned Instruments.

What connects creatively: A useful musical phrase should be reusable like sheet music: the same notes can drive a bass, bell, hardware module, or future VST without cloning or rewriting the composition. The lane is the performer; the clip/pattern is the score.

Architecture choice: Non-drum Arrangement playback already resolves notes and Chord Engine events through the owning lane's Instrument. Instrument reassignment now follows that final model and leaves embedded pattern data untouched, including patterns shared by several lanes. Explicit standalone Piano Roll retargeting remains available where a pattern truly needs a source assignment outside an Arrangement lane.

Future extensions: This separation simplifies Scenes, orchestration alternatives, ghost notes, drag conversion dialogs, VST hosting, external hardware routing, and the final unbounded Instrument registry because none of those features need to rewrite note payloads merely to change the performer.

2026-07-30 - Save/Load Proof Must Resemble A Real Project

Task: Add a focused project-persistence gate to release convergence.

What connects creatively: Persistence tests become far more valuable when they restore a musician's actual decisions rather than a blank object. Tempo, loop, lane identity, Instrument routing, clip placement, long pattern length, expressive note data, and automation form a compact cross-section of the app's architecture.

Architecture choice: The new gate writes a representative .sskit, reloads it, verifies those fields, and proves restore creates no Undo history. Its musical cross-section now includes Section form markers, lane Mixer gain/pan, a detailed Chord Engine marker with strum/arp state, tempo, loop, routing, a long clip/pattern, an expressive note, and automation. The work exposed and fixed missing Arrangement-loop state, missing release velocity, and explicit pattern lengths being collapsed to the latest note/chord endpoint.

Future extensions: Grow this fixture deliberately with external asset relinking, recovery snapshots, clip/lane-local automation, and missing-asset receipts; avoid turning it into an opaque everything-test.

2026-07-30 - Performance Gates Must Describe Musical Workloads

Task: Replace an unreliable full-suite wall-clock assertion with a focused Release performance smoke test.

What connects creatively: CPU confidence is useful only when the benchmark describes music a person might actually make. Retriggering pads faster than voices can decay measures unbounded voice accumulation, not a stable instrument load.

Architecture choice: The focused gate warms up the engine, reuses audio/MIDI buffers, measures five runs, and judges the median against the real-time duration of 200 audio blocks. The workload uses eight active pads retriggered every 32 blocks; the deliberately harsher voice-flood remains a separate optimization target.

Future extensions: Give each expensive engine a named musical workload, then publish a small performance matrix by sample rate, buffer size, active voices, effects, and CPU class instead of relying on one opaque percentage.

2026-07-30 - Product Proof Tests Should Guard Meaning, Not Sentences

Task: Decouple hardware-editor and MIDI-readiness behavior contracts from fragile exact-copy assertions.

What connects creatively: The proof system exists to make SpaceAge more trustworthy. It becomes counterproductive when harmless wording or a more useful next-action priority makes a safe feature appear broken.

Architecture choice: Runtime gates remain strict about locked hardware sends, source proof, confirmation, receipt persistence, non-sending actions, direct Automation access, and conservative launch status. Longer copy contracts remain available as diagnostics without deciding product health.

Future extensions: Apply the same split to render receipts, Quasar packages, preset metadata, and recovery reports: typed behavior contract first, separately reviewed editorial copy second.

2026-07-30 - Export Tails Must Not Secretly Become Song Repeats

Task: Make full-arrangement WAV export ignore loop state and render effects decay without restarting the timeline.

What connects creatively: A loop is a composition and auditioning tool; a render tail is an acoustic consequence. Treating them as the same transport phase can turn a five-second reverb tail into an accidental encore. Separating musical render and decay render makes the result match the user's mental model.

Architecture choice: Full render now clears Arrangement and step loops, runs once from step zero to the timeline boundary, stops transport, and then renders five seconds of audio decay. A focused file-level gate proves a final-step event survives and the tail does not retrigger the arrangement.

Future extensions: The same two-phase boundary should underpin stems, freeze/flatten, Quasar capture, and future offline effect printing so every export can state whether transport is active or only existing voices/effects are decaying.

2026-07-30 - Fresh Lane Capacity Follows Ownership, Not Stale Storage

Task: Prevent abandoned bridge-era Instrument payload from falsely exhausting fresh lane creation.

What connects creatively: Users think in available Instruments and owned lanes, not private backing slots. A forgotten label or stale sound in an unowned slot should not make the app claim that no more Instruments can be created.

Architecture choice: Fresh lane creation may claim any unowned private Instrument slot because it immediately resets that slot. Copy and Variant keep the stricter empty-slot rule so existing sound payload is never overwritten accidentally.

Future extensions: This distinction maps cleanly to the final Instrument registry: create fresh allocates/reinitializes, while copy, variant, and adopt existing remain explicit ownership operations.

2026-07-29 - Takes Need A Verdict Before They Need A Paragraph

Task: Give MIDI recording takes a compact trust badge. Verification note: protected by the fast MIDI closeout gate run tagged codex-recording-take-trust-badge-20260729-rerun.

What connects creatively: A musician does not first want a dissertation after recording; they want to know whether the take is safe to keep. The long proof remains available, but the badge gives the emotional answer first: clean, timing suspect, or retake.

Architecture choice: The verdict lives in MidiProjectHealthSummary, then fans out to MIDI Health, serialization, and copy cards. This keeps UI wording from becoming a second truth source.

Future extensions: The same badge pattern can be reused for audio renders, Instrument Bay route health, hardware SysEx restores, Quasar package builds, and automation lanes: quick verdict first, evidence second, action third.

2026-07-28 - Proof Doors Should Cross-Reference Cleanly

Task: Update the Automation proof-copy summary so it names the focused MIDI Health COPY PROOF doorway.

What connects creatively: Automation is currently the main MIDI closeout blocker, so its proof report is a hub. A hub should name the nearby doors accurately: Automation's own proof sheet, the full report, the finish-line QA packet, the launch run order, and the focused next-proof card.

Architecture choice: The Automation model summary now includes MIDI Health COPY PROOF and tests protect that direct and serialized wording. No Automation data, MIDI routing, playback, recording, export, or hardware behavior changed.

Future extensions: As more proof surfaces appear, each domain report should have a tiny map of adjacent copy/report doors so testers never have to guess which packet fits which job.

2026-07-28 - Claim Copy Needs A Compass, Not Just A Caution Sign

Task: Add current proof handoff and fast-gate context to the hardware/public-claim proof copy block.

What connects creatively: Marketing language is powerful because it compresses trust into a sentence. That makes it dangerous when it floats away from the evidence. COPY CLAIM now carries the actual next proof doorway and verification ritual alongside the safe wording, so support, marketing, and QA are all looking at the same map.

Architecture choice: The hardware/public-claim packet now includes the current MIDI proof handoff plus fast MIDI closeout guardrails. This is report/copy text only; it sends no MIDI, changes no routing, mutates no project data, and touches no hardware.

Future extensions: Every public-facing claim surface should carry its proof compass: what can be said, what evidence exists, what is missing, and what command or human test proves the next step.

2026-07-28 - Same Words Should Not Mean Two Different Doors

Task: Clarify MIDI proof-copy surface names so MIDI Health and Automation proof buttons cannot be confused.

What connects creatively: As SpaceAge gains serious QA surfaces, button labels become part of the product language. If two proof buttons both sound like COPY PROOF, a tired tester can paste the wrong evidence into the right conversation. Naming the doorway in the text keeps the interface compact while the report remains precise.

Architecture choice: The model now distinguishes MIDI Health COPY PROOF from Automation COPY PROOF, and the MIDI Health copy tooltip/receipt says the next-proof card includes the current handoff. No MIDI routing, playback, recording, automation, or hardware behavior changed.

Future extensions: The same pattern should be used for render/export, Instrument Bay repair, VST scan, Quasar package, and hardware editor proof buttons: compact visible labels are fine, but copied text should name the originating doorway.

2026-07-28 - A Focused Proof Card Still Needs Its Coordinates

Task: Make the MIDI Health focused proof-copy packet carry the current finish-line handoff.

What connects creatively: A small copy button can accidentally create a tiny island of truth: useful locally, but confusing once pasted into a note, support thread, or QA checklist. Carrying the current handoff into COPY PROOF keeps even the smallest proof card tied to the larger launch mission.

Architecture choice: The focused proof card now includes currentFinishLineProofHandoffSummary() before launch run-order, next-receipt, and action-queue text. The behavior is documentation/reporting only; MIDI playback, routing, recording, and validation logic are unchanged.

Future extensions: Any future focused proof button should inherit the same pattern: current state, action doorway, proof boundary, receipt key, and verification command. This applies naturally to render/export, Instrument Bay, VST scanning, Quasar packages, hardware editors, and classroom-safe diagnostics.

2026-07-28 - Forms Should Remember Why They Opened

A proof form can become a dead end if it forgets the button, row, or mission that opened it. Carrying the handoff into the QA receipt dialog makes the app feel less like paperwork and more like a guided cockpit.

2026-07-28 - Buttons Should Explain Their Consequence

When a button opens a proof surface instead of performing the full task, its tooltip should carry the logic of that detour. The MIDI Health FIX NEXT button now behaves like a miniature checklist: destination, action, handoff, and safety boundary travel together.

2026-07-28 - Handoffs Beat Scatter

A complex app can be technically correct and still feel evasive if the next action is split across too many rows. The proof handoff line treats QA like arrangement workflow: show the current object, show the intended action, and show the proof ritual in one place.

2026-07-28 - Source Proof Turns Confusion Into A Receipt

When two controllers are connected, "MIDI lag" or "wrong notes" can become emotionally global: the whole app feels suspect. Source-aware last-recorded proof gives SpaceAge a calmer way to say "this exact note came from physical input slot 02, generation 4, into this lane and pattern." This can grow into a useful live-performance diagnostic surface: source badges, per-device timing stats, and post-take receipts that separate USB, DIN, host MIDI, and future network MIDI instead of blending them into one haunted bucket.

2026-07-28 - Proof Has To Be Visible

A diagnostic line that technically exists but is buried below the first screen does not calm a musician. The recording proof rows now live close to the top of MIDI Health because "what did SpaceAge just record?" is more emotionally urgent than release bookkeeping. This same rule should guide future export, render, Quasar capture, SysEx restore, and hardware setup panels: put the user's immediate trust question first, then show broader system proof underneath.

2026-07-28 - Last Recorded Event As Trust Evidence

A recorded MIDI event should leave a tiny footprint of proof: what landed, where it landed, and whether it belongs to the armed lane/pattern the user expected. The new last-recorded proof label is a seed for a future post-take receipt that can say "your C5 landed at step 192.5 in this 256-step clip" without making the user dig through the Piano Roll. This connects MIDI Health, Arrangement recording, automation capture, and future punch/loop recording into one calmer trust system.

2026-07-28 - Completion Percentages Are Not Permission

SpaceAge needs to treat "software seems complete," "humans proved it on real devices/files/hosts," and "future protocol families are deliberately excluded" as separate truths. A single percentage is emotionally satisfying, but it can lie by omission. midiOneCompletionBoundarySummary() is a small piece of product honesty: it lets the app say exactly what is ready, what still needs receipts, and what belongs to the roadmap. This pattern should guide future VST, Linux, XG, render/export, school-license, and AI-vocalist claims.

2026-07-28 - Important Buttons Need A Second Way Home

When a button has emotional weight, like RETAKE, it should not depend on one brittle metadata field. The backend should provide the exact doorway, but the UI can still know that a recordingTake source belongs in Automation/Retake. This is not duplicate business logic so much as a safety rail for navigation. The same idea should guide future Health doors for XG editor repair, VST scans, Quasar package rebuilds, and render/export proof: a serious action should have one model-owned truth and one graceful UI fallback.

2026-07-28 - Bad Takes Should Interrupt The Cockpit

A dropped recording event is not merely another warning; it damages trust in the musical performance. MIDI Health should therefore promote dropped note/drum or expression events above softer concerns and give the user a plain retake path. This design principle can later apply to audio recording, Quasar capture, render/export, and hardware SysEx restore: when the captured artifact itself is suspect, the UI should stop being coy and say what needs to be redone.

2026-07-28 - Use Existing Doors Before Adding More Buttons

The recording take review card belongs in COPY STEPS and COPY REPORT before it deserves a new button. That choice keeps MIDI Health from turning into a cockpit covered in tiny switches, while still making the serious information portable. This is a good default for SpaceAge: surface critical truth in the places users already copy, then promote it to a dedicated control only after the workflow proves it needs one.

2026-07-28 - A Take Needs A Trust Receipt

Recording confidence is emotional as much as technical. If the user plays a phrase and SpaceAge misplaces or drops it, the app must say so plainly rather than letting the bad take masquerade as musical truth. recordingTakeReviewCopyBlock() is a seed for that principle: ownership, capture policy, target boundary, queue trust, timing risks, and evidence all travel together. This same idea can later become a visible "TAKE CLEAN / TAKE SUSPECT / RETAKE" badge in Arrangement recording, Piano Roll recording, and hardware recording workflows.

2026-07-28 - Claim Copy Is Product Hygiene

A COPY CLAIM button is not glamorous, but it protects the product. It lets SpaceAge say: here is what is safe to claim, here is what is merely ready for proof, and here is what still needs real hardware/file/host receipts. This is the same pattern we should use later for VST hosting, Linux builds, school licensing language, XG editors, and audio export: give users and the company a clean evidence-aware statement instead of inviting optimistic phrasing.

2026-07-28 - Public Claims Need Their Own Proof Voice

Launch proof answers "did the software path pass its own evidence buckets?" Hardware public-claim proof answers "can we say this in the outside world without overpromising?" Those are related, but not identical. A dedicated hardwareProofReviewCopyBlock() gives SpaceAge a calm legal/product boundary: what is ready, what still needs real devices/files/hosts, what to do next, and what the copy operation does not touch. This pattern should later guide VST support, Yamaha XG editors, SoundFont relocation, render/export, and any future school/commercial claims.

2026-07-28 - The UI Should Ask For The Proof, Not Invent It

The MIDI Health panel should not be responsible for assembling proof language from raw fields. When the model owns midiLaunchValidationNextProofReviewCardCopyBlock(), every future UI can reuse the same tested text. This is the pattern we want for Instrument Bay repairs, XG hardware editors, VST scan reports, render/export receipts, and Quasar capture: the workflow model should produce the copyable truth, and the UI should display or copy it.

2026-07-28 - Proof Needs Two Copy Sizes

COPY LAUNCH is for planning the full launch proof pass; COPY PROOF is for the next tile under the user's feet. That distinction matters. Big copy surfaces help managers, support, and future us; small copy surfaces help a tired tester do the next right thing without context switching. This same split should guide render/export, Quasar capture, XG hardware setup, and future VST scan proof.

2026-07-28 - Proof Cards Should Sound Like A Calm Human

Raw key/value summaries are useful for tests, but they are not how tired people want to read instructions. A reviewCardText surface lets SpaceAge keep machine-verifiable fields while also presenting the next proof as a small calm card: what button, what receipt, what evidence, what script, and whether MIDI or project data will change. This pattern should later shape render/export, XG hardware editor plans, VST scans, and Quasar capture.

The same review card should appear in plain-text reports, not just object properties. A copied support report is often what survives outside the app, so the human card needs to travel there too. This turns health exports into usable handoff documents instead of raw diagnostics.

2026-07-28 - The Right Sized Copy Button

COPY REPORT is truthful, but it can be too much when the human only wants the launch-proof ritual. COPY LAUNCH is a smaller door into the same verified data, which is the pattern SpaceAge should prefer: big reports for audit, focused copy buttons for action. This should guide future render/export receipts, XG hardware setup, VST scan results, and Quasar capture packages.

2026-07-28 - Copy Blocks Are Human Interfaces

A hidden object property is not a workflow. The launch run order becomes useful when it can be copied as one clean block: summary, ordered proof rows, queue state, action queue, and the next receipt. This pattern should show up anywhere SpaceAge asks a human to prove something later: VST scans, Yamaha XG hardware profiles, Quasar capture, render/export, and preset-pack QA should each have a one-block handoff that can survive fatigue.

2026-07-28 - Next Steps Should Lead With The Ritual

If the next-steps report shows an unordered queue before the run order, the tester has to mentally assemble the session. Keeping the launch run order test-enforced in next steps makes SpaceAge feel guided: the app names the first ritual, then provides supporting receipts. This is a useful pattern for future customer-facing flows such as Hardware Passport setup, Quasar capture, render/export, and VST scanning.

2026-07-28 - Run Order Is A Product Feature

A launch checklist becomes much less scary when it is ordered. The MIDI launch validation run order turns scattered proof buckets into a guided testing session: do this first, then this, with the needed artifact and script attached. This same pattern should guide render/export QA, Instrument Bay route testing, VST scan validation, Quasar capture, and XG editor hardware checks: users and testers should feel led through a ritual, not left to interpret a spreadsheet.

2026-07-28 - The Evidence Form Is The Moment Of Truth

The receipt form is where a tester decides whether to write PASS, FAIL, or BLOCKED, so it must carry the same proof script as the health card and copied report. If the evidence-entry dialog is vague, the tester may save a weak PASS out of fatigue. This same principle belongs in render/export receipts, Quasar package creation, SysEx restore, and future VST scan validation: at the save/commit moment, show the proof standard.

2026-07-28 - Tooltips Can Carry Rituals

When a button says FIX NEXT, the tooltip should not merely repeat the label; it should reveal the safe ritual behind the action. Adding launch-proof scripts to MIDI Health and Fix Next tooltips turns hover text into a small training layer. This same approach should guide Hardware Passport tests, SysEx restore, Instrument Bay routing repairs, Quasar capture, and future VST scans: the tooltip should make the action less mysterious before the user commits.

2026-07-28 - The Next Action Should Be Executable

A status line that says "proof needed" is still asking the user to invent the next move. Adding the proof script to the MIDI launch next-action summary turns the line into something executable: here is the bucket, here is the evidence, here is the exact ritual. This should become a SpaceAge habit for XG editors, VST scans, Instrument Bay routing, Quasar capture, and render/export: every serious status should point to an action a human can actually perform.

2026-07-28 - A Receipt Should Suggest The Ritual

Launch proof should not make the tester invent the test from scratch. proofNeedsSummary says what kind of proof is needed; proofScriptCue says what ritual to perform. This pattern can later apply to Quasar capture, Instrument Bay reassignment, VST hosting, XG hardware editors, render/export, and MIDI Learn: every serious feature should offer a small, repeatable proof path instead of a vague confidence vibe.

2026-07-28 - Names Should Stay Full Until They Are Learned

Lane Local earns its extra word because it tells the musician that the data belongs to the lane over time, not merely to a visible lane row on screen. Short labels are useful on tiny buttons, but ownership labels should remain explicit until the user has a stable mental model. The same discipline should guide Instrument Bay routing, Quasar packages, XG editors, and VST automation later: compact UI is good only when it does not hide the contract.

2026-07-28 - Proof Needs Should Be Read Before The Test

Launch receipts are not just backend bookkeeping; they are a calm checklist for humans. If a proof bucket needs hardware, real files, or live performance, the app should say that before the user starts testing. The same idea can later help Instrument Bay, XG editors, VST hosting, Quasar capture, and render/export: every serious workflow should name the kind of evidence it needs, not merely whether something passed.

2026-07-28 - Ownership Labels Are Workflow Architecture

Automation ownership is not just a backend detail; it is a trust contract. Shared PTN, Clip Local, and Lane Local are small phrases, but they tell the musician whether a change travels with linked pattern material, lives only inside one clip, or follows the lane. That clarity will matter even more when full Arrangement automation lanes, Motion Clips, hardware CC editors, and VST automation arrive.

2026-07-28 - Test Evidence Is Part Of The Instrument

The app is not just the executable; the proof machinery is part of the product's nervous system. A stale test binary can make a good MIDI fix look broken, so future developer-facing tools should surface the exact binary path, timestamp, and focused gate being run. That same idea can become customer-facing later: MIDI Health, render progress, Quasar package builds, and hardware setup should always show enough proof that the user knows the app is doing the thing it claims.

2026-07-28 - One Tool, Two Door Sizes

Automation now has a practical naming split: AUTO where horizontal space is tight, AUTOMATION where clarity is worth the pixels. The creative rule is that different door sizes are acceptable only when they lead to the same room and the help surface says so plainly.

2026-07-28 - Do Not Make Important Doors Clever

AUTO was compact, but it was also ambiguous. A musician should not have to decode whether that means automation, automatic chords, auto-fill, auto-quantize, or something else. The more important the doorway, the more literal the label should be. This principle should guide Instrument Bay, MIDI Hardware, render/export, Quasar capture, and future VST hosting: clever names can live in product flavor, but workflow doors should tell the truth immediately.

2026-07-28 - Imports Are Edits, Too

Import workflows can feel like file management, but musically they are edits to the timeline. If an import replaces or clears notes and expression in a span, the same live-state promises must apply as manual Automation editing: what disappears from the project should disappear from the sound. This matters for future MIDI import review, hardware SysEx recall, SoundFont mapping, Quasar package import, and any preset browser that writes musical data into the Arrangement.

2026-07-28 - Copy Should Tell The Same Truth As Sound

Automation wording has to be technically humble. A delete might reset a lane to neutral, or it might reveal another remaining point that should become live. The UI should therefore say the output was refreshed, not over-explain or make a false promise. This same language discipline belongs in render progress, hardware routing, preset saves, Instrument Bay reassignment, and future VST hosting: describe the contract the app can prove.

2026-07-28 - Deleted Automation Must Sound Deleted

Automation is only trustworthy if the ear agrees with the eye. When a user deletes pan, expression, or any MIDI controller lane, SpaceAge should immediately prove that deletion in the audible state instead of waiting for playback to wander across the timeline later. This same rule should guide Motion Clips, future expanded automation lanes, hardware editors, and VST parameter automation: visible data and live sound must reconcile after every edit.

2026-07-28 - Recording Needs A Visible Border

The armed lane, the selected clip, and the playhead are all useful ideas, but only one of them should own live input. Naming that boundary gives the performer confidence before they play: the armed lane is the stage, the playhead/explicit clip is the landing zone, and selection is for editing. This same visible-border idea should guide punch recording, loop takes, automation write, hardware capture, and future VST recording, because every creative performance needs to know where it will land before the hands hit the keys.

2026-07-28 - Automation Needs Receipts Before It Needs More Real Estate

The temptation with Automation is to jump straight to big timeline lanes, but the more important launch question is whether the current doors tell the truth. A small doorway-proof line helps the app say: here are the doors, here is whether they create data, here is whether they send MIDI, and here is what QA must prove. That pattern can carry into future Motion Clips, full timeline automation lanes, Instrument Bay modulation, and hardware editor pages: a beautiful control is not enough unless the user can tell what owns the data and what will change.

2026-07-28 - Do Not Let Compensation Masquerade As Feel

MIDI timing has two truths: where the note lands after recording, and what the musician feels while playing. SpaceAge should treat those as siblings, not twins. A record-latency compensation tool can make the captured performance line up beautifully, but if the player hears the sound late, the musical experience is still damaged. This trust-boundary language should guide future MIDI Timing calibration, hardware setup, SoundFont diagnostics, VST hosting, and live-performance marketing: fix the player's feel first, then align the timeline.

2026-07-28 - Two Controllers Need A Traffic Cop, Not A Warning Siren

When two controllers are attached, the app should not make the user feel guilty for having a richer studio. The real question is whether the armed lane knows which source owns the performance. If it is source-pinned, the UI should say that plainly: this controller is allowed through, the others are ignored for this lane. That same pattern should inform future hardware editors, VST input routing, MIDI guitar/wind-controller workflows, and scene/orchestration experiments: multiple sources are powerful when the destination contract is visible.

2026-07-28 - The Playhead Is A Promise

If a lane is armed and the playhead sits over a real clip, every visible recording receipt should describe that clip, not whatever pattern the editor happened to have open a moment ago. This is a small wording fix with a large emotional effect: the user learns that SpaceAge records where the armed lane and playhead say it will record. The same rule should guide punch-in, loop takes, automation write, and future hardware capture: the active timeline location should win over stale UI context.

2026-07-28 - Do Not Name A Ghost Target

When no lane is armed, SpaceAge should avoid mentioning selected clips in recording summaries because that makes the user wonder if selection is secretly part of the live-input contract. The better pattern is blunt and kind: no armed lane, recording blocked, selection is edit context only. This same rule should apply to future punch recording, loop takes, hardware capture, and automation write modes: if an object is not eligible to receive data, do not present it as a possible target.

2026-07-28 - Recording Needs A Target Receipt

The user should never have to wonder whether MIDI recording is aimed at the selected clip, the open editor, the playhead, or a stale pattern. The new recording target proof treats the armed lane and playhead clip as a receipt. This same idea should guide future Arrangement record buttons, punch-in/out, loop recording, takes/comping, and hardware capture: before the user performs, SpaceAge should be able to say exactly where the performance will land.

2026-07-28 - The Armed Lane Is The Stage

When live MIDI feels confusing, the user usually does not need another abstract routing option; they need the app to point at the stage and say, "this is where your hands are playing." The armed lane destination proof ties lane type, Instrument, mixer channel, MIDI channel, and route target into one readable line. That pattern should become standard for Instrument Bay, hardware editors, Automation ownership, and future VST hosting: every performance path should have a plain-language proof of where sound and MIDI are actually going.

2026-07-28 - Takes Need Evidence, Not Guesswork

Recording trust is emotional: one bad take that records late can make the whole app feel unreliable. The new TAKE PROOF line treats every take like a tiny receipt: dropped events, queue age, buffer latency, voice-pool refusals, and sample-positioning are all named in one place. This pattern should extend to render, automation playback, hardware sync, Quasar capture, and future VST hosting. Anywhere a user thinks, "Did SpaceAge actually do what I asked?", the app should be able to answer with evidence.

2026-07-28 - Automation Needs A Door, Too

Automation is powerful enough to feel slippery if the user cannot tell what they are editing. The popup now treats owner, target, and next action as one visible doorway: "this owner, this row, this next move." That pattern should travel to the future expanded automation lanes, clip-level Motion Clips, hardware CC editors, and any AI-assisted modulation tools. Expression editing becomes calmer when the app continuously names what is safe, what is selected, and what proof remains.

2026-07-28 - Name The Door, Not Just The Task

The MIDI Setup Guide now labels the destination surface directly. That tiny shift matters: "MIDI INPUT" or "HARDWARE" is easier to trust than a long next-action sentence when the user is trying to connect a controller, synth, or module. SpaceAge should reuse this door-label pattern anywhere a workflow has multiple safe panels: Instrument Bay setup, VST scanning, sample relinking, Quasar capture, render/export, and future hardware editors.

2026-07-28 - A Health Page Should Name The Door

MIDI Health now shows an ACTION DOOR row beside the existing cockpit and next-action lines. This is the right direction for SpaceAge's diagnostic surfaces: when the app recommends an action, it should also name the doorway and safety class. That keeps the user oriented, and it gives future support/debugging reports a shared vocabulary: problem, next action, door, safety boundary, proof requirement.

2026-07-28 - The Passport Row Should Be A Tiny Control Tower

The Hardware Passport row now shows the Safe MIDI action directly: CONFIRM, QUEUE, or REVIEW. This is a useful pattern because a musician should not have to copy a report before understanding the next safe move. The row is the object, the chip is its present tense. That same "tiny control tower" idea should travel to Instrument Bay lanes, automation ownership, render/export, sample relinking, and future VST scan results.

2026-07-28 - Parallel Doors Should Speak The Same Language

The EDITOR PLAN and SAFE MIDI dialogs now both surface the Safe MIDI action class. This matters because users do not mentally separate "planning a hardware editor" from "previewing safe MIDI" as much as the code does. If two adjacent doors lead into the same safety system, they should use the same nouns. That rule should apply across SpaceAge: MIDI Tasks, Render, Library repair, Quasar, and destructive edit flows should all reuse common language when they share a safety boundary.

2026-07-28 - The Popup Should Echo The Receipt

The Safe MIDI copy popup now repeats the dashboard primary action. That is the right kind of redundancy: the user gets a fast emotional signal in the dialog, while the clipboard receipt preserves the full detail. SpaceAge should use this pattern for render, package import, SysEx restore, Quasar build, and destructive edit flows: popup tells the action class; receipt tells the whole story.

2026-07-28 - Receipts Should Preserve The Button Logic

The locked hardware editor receipt now prints the same primary action and section actions that the dashboard model exposes. This is important because receipts are not just logs; they are trust artifacts. If a user copies a plan before touching a Yamaha, Roland, Korg, Novation, or other device, the receipt should preserve the exact button logic the UI used. That makes screenshots, support, manuals, and future QA much easier.

2026-07-28 - One Dashboard Needs One Door

The Safe MIDI dashboard now has its own primary action, not just section-level actions. That matters for the actual screen: a user should be able to glance at the whole hardware dashboard and see one main door, then inspect sections if they want nuance. This should guide bigger SpaceAge architecture too. Every complex panel should know its own safest next action before the user starts hunting through details.

2026-07-28 - Buttons Should Come From State, Not Vibes

Safe MIDI dashboard sections now carry a primary action label and a stable action kind. This lets a future hardware editor draw a real button without guessing: Review if warnings exist, Confirm if the MIDI is valid but disruptive, Queue if it is a guarded everyday control. That pattern should become a SpaceAge design rule. Wherever the app shows complex state, the UI should not parse prose or improvise button meaning; the model should hand it a clear next action.

2026-07-28 - Labels Should Not Cry Wolf

Safe MIDI rows now separate guarded queue from confirm before queue. That is more than wording polish. If every harmless CC says it needs explicit confirmation, users learn to ignore the warning. SpaceAge should reserve the serious language for actions that can actually surprise the external instrument, such as Program Change, RPN setup, NRPN setup, SysEx writes, and resets. The same principle belongs in render/export, sample deletion, project repair, and AI-assisted patch creation: warnings only work when they mean something.

2026-07-28 - Valid MIDI Still Needs Consent

A preview can be technically valid while still being musically disruptive. Program Change can swap the user's hardware sound; RPN pitch-bend range can change how a performance feels. SpaceAge should keep this distinction visible: "ready" means the messages are well formed, while "requires confirmation" means the user deserves one more deliberate step before external hardware changes. This same consent layer should apply to SysEx dumps, bulk preset writes, scene orchestration changes, and any future AI patch-generation commit.

2026-07-28 - Channel Is Not A Footnote In Hardware MIDI

Safe MIDI dashboards now show the preview channel at every level. That is not trivia: a perfect CC, Program Change, or RPN becomes confusing if it lands on the wrong part of a multitimbral instrument. SpaceAge should treat MIDI channel as visible routing truth, the same way Arrangement lanes expose their instrument and mixer destination. Future hardware editors, automation lanes, and Instrument Bay routing should always keep channel context close to the control being edited.

2026-07-28 - One Hardware Plan Should Explain Both The Door And The Lock

The locked hardware editor plan now carries the Safe MIDI dashboard. That means a future Yamaha/XG editor page can show three truths from one object: what deep pages will exist, why dangerous controls remain locked, and which standard MIDI controls are safe to preview. This is better than scattering safety into separate buttons because the user sees the door, the lock, and the harmless controls in one mental model.

2026-07-28 - Group Controls The Way Musicians Think

Safe MIDI rows now group into dashboard sections using the same page names that the future hardware editor should show. This matters because "CC7, CC10, CC11, CC91" is protocol thinking, while "Channel Mixer" is musician thinking. SpaceAge should keep both truths: the section makes the UI legible, and the row/message data keeps the MIDI exact. This same pattern should guide Instrument Bay, automation, effects, and synth editors: friendly section first, exact machine contract underneath.

2026-07-28 - Rows Beat Paragraphs When UI Needs To Act

The Safe MIDI dashboard now exposes dashboardRows, not just a text report. That keeps future hardware editor UI honest: a row can draw a control, show its exact value/status/message count, and still point to a next action without parsing prose. The same move should be reused anywhere SpaceAge graduates from "copy a report" to "show me the safe controls": automation lanes, Instrument Bay routing, Quasar package inspection, sample relinking, and VST scan results.

2026-07-28 - A Status Chip Should Carry A Next Move

The Safe MIDI dashboard now carries a nextAction beside the summary. This is the humane version of protocol work: if SpaceAge says a hardware action is ready, it should also say what the musician should do with that readiness. This pattern belongs anywhere SpaceAge presents advanced state: automation ownership, MIDI hardware, Quasar packages, sample relinking, render/export, and future VST scan results.

2026-07-28 - Truth Chips Belong Beside The Thing They Describe

The selected Hardware Passport now shows a SAFE MIDI: chip directly inside the row. That is better than hiding status in a report button alone: the user sees the safety state while looking at the object that owns it. This pattern should travel to lane instruments, render/export, sample relinking, Quasar packages, VST scans, and automation lanes: put the miniature truth beside the thing, with the long receipt one click away.

2026-07-28 - Counts Make Hardware Feel Less Scary

The Safe Common MIDI Dashboard gives the future hardware editor a calm first glance: how many controls exist, how many previews are ready, how many messages would be queued, and whether warnings exist. This is a reusable UI idea. Any powerful SpaceAge operation, from SysEx restore to render/export to Quasar capture, should be able to present a small truth chip before showing the long receipt.

2026-07-28 - Preview The Message Before The Machine Hears It

Safe common MIDI controls now have preview-only action plans. This is a strong pattern for hardware editing: before SpaceAge touches a Yamaha QY, MU, Roland box, Korg synth, or future MIDI guitar processor, it can show the exact ordered MIDI messages and say what will happen. That makes advanced hardware feel less mystical and makes dangerous actions feel deliberate. The same preview-first pattern should serve SysEx restores, sample relinks, Quasar builds, render/export, and future AI-generated patch changes.

2026-07-28 - Common MIDI Is A Docking Clamp, Not A Deep Editor

The Yamaha/XG editor should not make users wait for every SysEx address before anything useful appears. Safe common MIDI controls are the docking clamp: bank/program, volume, pan, expression, sends, sustain, and pitch-bend range can be shown as standard MIDI concepts while deep Yamaha/MU/QY parameter pages remain locked. This same split can help future Roland GS, Korg, Novation, and MIDI guitar/wind-controller workflows: start with universal controls, then unlock device-specific depth only when the sources and receipts are real.

2026-07-28 - Checklists Beat Mystery Locks

When a feature is locked, the user should never have to wonder whether it is unfinished, unsafe, or intentionally disabled. The editor plan checklist turns a locked Yamaha/XG editor into a clear acquisition list: source PDFs, source artifacts, table proof, queue-safety proof, and real hardware receipts. This same pattern can later help VST scanning, AI patch generation, sample relinking, and export readiness.

2026-07-28 - Locked Pages Can Still Teach The Workflow

The Yamaha/XG editor can become useful before it becomes dangerous. A locked page plan lets the user see the future editor shape: Passport Header, Part Mixer, Part Sound, Effects, Drum Part, Multi EQ, and expansion pages, but every deep control stays disabled with a reason. This is a strong SpaceAge pattern: show the shape of the workflow, explain what evidence is missing, and never pretend a hardware send is safe until it is proven.

2026-07-28 - A Future Editor Should Reuse The Import Truth

The Yamaha/XG editor page should not invent a second explanation of readiness. The import dialog now has a reusable review contract that already knows the expected Passport family, imported table proof, registry match, lock state, blockers, and next actions. That same object can power a locked editor splash, a QA receipt, a support copy button, and eventually the unlock doorway. One truth, many surfaces.

2026-07-28 - One Report Should Answer The Next Question

After a user imports a hardware editor parameter table, the next question is obvious: "Can I use this yet?" The dialog now answers that immediately by pairing row-level proof with profile-level unlock readiness. This pattern matters beyond Yamaha XG: whenever SpaceAge previews a powerful artifact, the same report should say what the file contains, what is trusted, what remains blocked, and what the next useful action is.

2026-07-28 - Locked Should Still Teach

A disabled editor button is a dead end; a locked readiness card is a teacher. For hardware editors, SpaceAge can say exactly what is missing: source artifacts, parameter rows, queue safety, profile match, or a real hardware receipt. That pattern should travel into VST scans, AI patch creation, sample relinking, Quasar package validation, and render/export: when a feature is not ready, the app should tell the user the next useful step instead of merely saying no.

2026-07-28 - A Passport Should Narrow The Door

Once a user has selected a Hardware Passport, SpaceAge should use that context to make every later hardware action less ambiguous. Importing a parameter table while a QY Passport is selected should not feel like importing a random JSON blob; it should feel like asking, "does this table belong to this machine?" This same idea can help sample relinking, controller maps, VST presets, and Quasar packages: user context should quietly reduce the chance of a wrong-file mistake.

2026-07-28 - A Registry Before A Room Full Of Knobs

The XG editor needs a visible front door before it needs a deep editor surface. A locked Hardware Editor Profile Registry lets SpaceAge say, "we know this device family exists, we know what proof is required, and we will not pretend these controls are safe until the evidence exists." This also gives us a reusable model for future hardware families: Korg, Roland GS, Yamaha DX, and boutique instruments can all start as locked registry entries before becoming editable devices.

2026-07-28 - First Glance, Then Receipts

The IMPORT TABLE dialog now follows a good SpaceAge pattern: first glance for the musician, full receipt for trust. The headline says ready or locked and why; the report keeps every row and warning available for copying. This same interaction pattern should apply to future render/export, sample relinking, VST scanning, Quasar builds, and AI patch tools: give the user confidence in one breath, then offer the detailed ledger.

2026-07-28 - Trust Needs More Than A Red Light

A locked hardware editor row should say why it is locked. Missing source proof, malformed address data, bad ranges, and wrong-device rows are different problems that need different human action. Turning those into counters is product design, not mere diagnostics: it teaches the user what kind of evidence is needed next. The same approach should guide future preset browsers, sample metadata, AI patch generation, and VST scans: failure should classify itself usefully.

2026-07-28 - A Fixture Can Be Honest Without Being Finished

The first Yamaha QY parameter-table example is useful precisely because it stays locked. It gives the UI something real to chew on while telling the user, tester, and future developer, "this shape is accepted, but these rows are not yet proven." That pattern can save us later with user-created hardware profiles, AI-assisted patch generation, sample metadata, and third-party importers: a file can be syntactically valid and still not be authorized for musical or hardware-changing use.

2026-07-28 - A Locked Hardware Editor Still Needs A Front Door

The Yamaha/XG editor path now has a visible, safe doorway: import a table, preview the proof, copy the report. That matters because musicians should not have to know whether a feature is "implemented internally" before they can understand what it needs. A locked doorway can still be helpful if it tells the truth, teaches the source requirements, and avoids changing the project or the hardware until the user deliberately crosses into a confirmed action.

2026-07-28 - Importers Should Be Honest Mirrors Before They Become Doorways

A Yamaha XG parameter table is powerful enough to become a hardware editor, but the first customer-facing move should be a mirror: show what the file says, what SpaceAge can verify, what remains locked, and what source proof is attached. The same preview-first habit should guide SoundFont libraries, Quasar packages, VST scans, sample metadata, and future user-shared hardware profiles. If a file can reshape the app, it should first become a readable receipt.

2026-07-28 - Locked Editors Can Still Be Useful

• Connection: the Yamaha XG editor does not need to be fully unlocked to be productively visible. A locked editor can teach the user what SpaceAge knows, what it refuses to guess, and what proof is needed before old hardware receives parameter SysEx.
• Architecture choice: device templates now carry legal notes, source URLs, required artifacts, and unlock requirements as structured data. That same pattern can later serve VST device profiles, MIDI guitar controllers, SoundFont relocation, Quasar packages, and any future hardware editor.
• Product implication: this is how we make advanced gear feel approachable without turning SpaceAge into a dangerous button panel. The app can say, "I can help, but I will not pretend this unknown device is safe."

2026-07-28 - Old Hardware Editors Need Passports, Not Guesswork

• Connection: a Yamaha XG editor is exactly the kind of feature where SpaceAge can feel unusually humane. Instead of dumping SysEx archaeology onto the user, the app can say, "choose your Yamaha box, prove the route, capture its setup, edit one part, and send only what you confirm."
• Architecture choice: QY and MU support should stay profile-driven. Hardware Passports own the device identity and safe send policy; lanes own musical channels; SysEx Vault owns captures and recalls; editor pages read verified parameter descriptors rather than building raw byte strings in UI code.
• Product implication: this lets SpaceAge court hardware people without creating dangerous magic. A locked Yamaha XG page can be useful today as a checklist, then gradually unlock into a serious editor as exact Data Lists, value tables, checksums, and real hardware receipts are added.
• Legal boundary: QXGEdit and WebXGMIDI are workflow references, not code sources. The commercial version needs clean-room parameter descriptors derived from manuals, not copied implementation.

2026-07-26 - A Proof Card Should Name The Gate Beneath It

• Connection: launch-proof cards now carry the automated backend gate that protects the relevant code path. That means a future MIDI cockpit can say, "prove this with a human receipt, and here is the automated guardrail already watching the machinery."
• Reuse path: render/export, Quasar capture, SoundFont relocation, VST scanning, hardware editor scripts, and sampler package repair should all expose both proof evidence and backend guardrail in the same card.
• Product implication: this is how SpaceAge becomes rigorous without feeling evasive. The app can distinguish "tested by machine" from "proven in the real world" in one calm, readable object.

2026-07-26 - Human Proof And Machine Proof Should Shake Hands

• Connection: the MIDI checklist now names both sides of trust: the backend gate that protects the code path, and the human receipt that proves real-world launch behavior.
• Reuse path: render/export, SoundFont relocation, Quasar capture, VST scan, hardware editors, and future AI patch tools should all separate automated confidence from real-world proof instead of blurring them together.
• Product implication: this gives SpaceAge a more honest release language. We can say, "the automated guardrail passes; now here is the human evidence needed," which is much better than vague confidence theater.

2026-07-26 - A Progress Message Is A Promise

• Connection: the MIDI closeout slices were passing, but two of them printed a checkpoint for work they had intentionally skipped. Even test logs are part of the product-making experience: if a progress line says something happened, it should have happened.
• Reuse path: project loading, render/export, SoundFont import, Quasar capture, SysEx restore, and VST scan progress should follow the same rule. Name only the stage currently being performed.
• Product implication: honest progress language builds trust. Users and testers can tolerate waiting; they do not tolerate software narrating the wrong story.

2026-07-26 - Confidence Gets Faster When It Has Named Rooms

• Connection: MIDI closeout now has six named proof rooms instead of one giant hallway. That lets us prove playback/live automation, lane workflow, route/status messaging, instrument ownership, and protocol behavior independently while preserving the full sweep for deeper confidence.
• Reuse path: this is the right shape for future release gates: synth audio output, render/export, Quasar capture, SoundFont relocation, VST hosting, hardware editor SysEx, and automation playback should each get fast named slices plus one larger end-to-end ritual.
• Product implication: faster proof loops are how SpaceAge gets professional without becoming fragile. The user never sees these gates directly, but they will feel the result as fewer weird regressions and less beta-test whiplash.

2026-07-26 - A Focused Test Should Not Walk Through Another Room First

• Connection: early-return slice gates were better than one giant regression, but the instrument slices still walked through automation/protocol checks first. That was truthful but wasteful. A focused gate should start near the thing it claims to test.
• Reuse path: future proof gates for render/export, hardware setup, SoundFont import, VST scan, and Quasar capture should avoid unrelated setup whenever possible, then keep one deeper sweep for whole-system confidence.
• Product implication: development speed is part of product quality. The faster we can prove a change, the less likely we are to ship on hope or skip verification because it feels too expensive.

2026-07-26 - Confidence Needs Smaller Rituals

• Connection: the MIDI closeout gate was technically truthful but operationally clumsy. Splitting it into smaller proof rituals makes the same quality standard easier to run, easier to diagnose, and easier to trust.
• Reuse path: render/export, SoundFont import, Quasar capture, hardware profile setup, and future VST scan proof should all have small focused checks plus one deeper sweep. The user should not have to babysit one giant black box.
• Product implication: fast proof loops are creative infrastructure. When verification feels lighter, we can move faster without gambling on hidden regressions.

2026-07-26 - A Test That Looks Frozen Erodes Trust

• Connection: the MIDI closeout regression was passing, but it had become so large that it could run for minutes without visible output. That feels like a broken app even when the code is doing real work. Checkpoints turn silence into evidence.
• Reuse path: long actions in SpaceAge itself should follow the same rule: project load, render, Quasar capture, SoundFont import, SysEx restore, VST scan, and future AI patch generation all need progress pulses and named stages.
• Product implication: users forgive waiting when the software proves it is alive. They do not forgive mystery pauses.

2026-07-26 - The Next Step Should Be A First-Class Object

• Connection: the MIDI closeout list now exposes its first actionable row as structured data, not just prose. That gives the interface a stable way to say, "do this next," while still carrying the proof standard that makes the claim trustworthy.
• Reuse path: Instrument Bay repair, automation cleanup, render/export, hardware profile setup, and future VST scanning should all expose a first actionable item and a proof summary. It keeps dense engineering state from becoming a fog bank for the user.
• Product implication: this is how SpaceAge can feel helpful rather than bureaucratic. A rigorous app can still be graceful if it always knows the next meaningful move.

2026-07-26 - A Remaining Task Should Know Its Proof

• Connection: Remaining MIDI 1.0 checklist rows now carry the route, action surface, proof bucket, receipt key, and minimum PASS evidence beside the readable text. That means a future cockpit can show the musician or tester exactly what to do and what will count as done.
• Reuse path: Instrument Bay migration, render/export, VST hosting, SoundFont relocation, synth preset QA, and hardware editor support should follow the same model: every visible blocker should have a stable ID, doorway, proof type, and acceptance floor.
• Product implication: this is how SpaceAge avoids vague "almost done" states. If the app can name the missing proof, it can guide the user calmly instead of sounding evasive.

2026-07-26 - Magic Numbers Become UI Drift

• Connection: the MIDI Health cockpit was already dense, but its paint and layout code used separate hard-coded assumptions about how many rows existed. Replacing those with one row budget keeps the visual contract and button placement moving together.
• Reuse path: any future popup with diagnostic rows, automation lanes, device profiles, render progress, or patch metadata should avoid duplicated layout constants. One source of truth prevents subtle overlap bugs.
• Product implication: this is unglamorous work, but it protects the "professional app" feeling. Users rarely notice correct spacing; they immediately notice when text lands on top of controls.

2026-07-26 - A Button Can Teach Without Becoming A Manual

• Connection: the MIDI Health FIX NEXT tooltip now carries proof needs and minimum PASS evidence for launch-proof actions. The visible button stays compact, but the hover state explains the real acceptance criteria.
• Reuse path: this is a good pattern for risky workflows: render/export, VST scanning, SoundFont relocation, hardware editor dumps, and Instrument Bay repair can all keep the button short while letting the tooltip carry the safety/proof contract.
• Product implication: SpaceAge can stay minimal without becoming mysterious. The UI should not make the user hunt through a report to understand why a button matters.

2026-07-26 - Show One Proof Card, Keep The Deck Behind It

• Connection: MIDI Health now shows the first launch-proof card directly, while Copy Steps and Copy Report keep the full checklist available. That is a better cockpit pattern than making a dense popup carry every possible row at once.
• Reuse path: this “one actionable card plus full report” pattern should carry into Instrument Bay repair, SoundFont relocation, render/export proof, VST scan proof, and future hardware editor support.
• Product implication: the user gets the next move without drowning. The app can remain honest and rigorous while still feeling calm enough to use during a creative session.

2026-07-26 - The First Health Line Should Tell The Truth

• Connection: the MIDI cockpit now names launch-proof progress directly instead of burying it in the report. That helps prevent a misleading feeling of "done" when the backend is strong but proof receipts are still missing.
• Reuse path: all future readiness cockpits should expose the primary gate in the first line: Instrument Bay migration, render/export, VST hosting, sampler relocation, and hardware editors should all state the actual blocking proof count or action.
• Product implication: clarity beats optimism. The user can trust SpaceAge more if it says "we are close, and here is the exact gate" instead of glowing green too early.

2026-07-26 - Proof Cards Need A Human Reading Mode

• Connection: structured proof cards are good for the UI, but the Next Steps report also needs readable checklist rows so a human tester can run the ritual without decoding JSON-like fields.
• Reuse path: every future readiness deck should have both forms: rich card data for the interface and plain checklist lines for reports, bug tickets, manuals, and cold testing.
• Product implication: this helps SpaceAge feel less like a science project. If a tester can read "[ ] Automation hands-on QA" and know exactly what PASS requires, the path to release gets calmer.

2026-07-26 - Common UI Data Deserves A Front Door

• Connection: launch-proof cards still live in the detailed cockpit card, but they now also appear at the top level of MIDI Health. That keeps rich data available while giving the visible UI a direct, boring, reliable path.
• Reuse path: Instrument Bay, Effects health, synth preset QA, render/export, and hardware editors should follow this pattern: detailed nested object for diagnostics, top-level fields for the most common screen.
• Product implication: this reduces UI fragility. A beautiful cockpit is easier to build when it can ask for "the proof rows" directly instead of spelunking through a diagnostic object.

2026-07-26 - The Doorway Should Carry The Card

• Connection: if the cockpit says "do this next," the action surface should carry the proof card for that exact task. Otherwise the UI has to reconcile two different structures before it can draw a single helpful button or card.
• Reuse path: this applies to Instrument Bay repair, SoundFont relocation, render/export, VST scan failures, and future hardware editors. The button that opens the workflow should carry the compact data needed to explain why it matters.
• Product implication: fewer disconnected labels means less user confusion. SpaceAge should feel like it knows what it is asking for, especially during technical rituals like MIDI proof and hardware setup.

2026-07-26 - A Checklist Should Be Drawn From Data

• Connection: the MIDI launch-proof cockpit now has proofCardRows, which means the future UI can draw clean proof cards directly instead of scraping the validation matrix or reading prose.
• Reuse path: the same data-first card model should power future release-readiness views for Instrument Bay, render/export, synth preset QA, SoundFont relocation, VST hosting, hardware editor profiles, and sample-library integrity checks.
• Product implication: when the app knows the next proof item, proof type, minimum PASS evidence, and saved result as separate fields, it can guide a tired human without becoming another wall of text.

2026-07-26 - The UI Should Not Parse A Paragraph

• Connection: The launch-proof cockpit now carries the minimum evidence line as its own data and summary field. That matters because future UI should render cards, not mine prose for meaning.
• Reuse path: any future readiness cockpit should follow the same pattern: status, next action, proof type, minimum evidence, and safe doorway. This would work for VST hosting, SoundFont relocation, render/export, hardware editors, and synth preset QA.
• Product implication: clean internal data lets the interface feel calm. SpaceAge can ask a tester or user for exactly the missing piece instead of making them read a dense report while already worried something is broken.

2026-07-26 - Proof Needs A Floor, Not Just A Vibe

• Connection: "Capture proof" is too vague when a product is getting close to public claims. A minimum PASS evidence field turns QA from a mood into a checklist: device names, file paths, lane/channel identities, buffer sizes, heard results, and import/export comparisons where they matter.
• Reuse path: this pattern should apply to render/export, Instrument Bay, synth preset QA, SoundFont relocation, hardware editor support, and future VST hosting. Every risky feature needs a minimum acceptable evidence line.
• Product implication: this makes SpaceAge feel more professional internally before the customer ever sees it. Cleaner proof habits mean fewer confident-sounding claims that later embarrass us.

2026-07-26 - Name The Surface Before Selling The Feature

• Connection: Automation is not one thing to a musician; it is a set of visible places where intent can be created, found, edited, and trusted. The current popup editor, preview strips, badges, and doorways should be named as the launch surface, while full timeline lanes should stay honestly future-facing.
• Reuse path: this applies to Instrument Bay, Motion Clips, Scene orchestration, hardware editors, and synth macro pages. Every feature needs a clear answer to "where does the user touch it today?" before we expand the mythology around it.
• Product implication: honest surfaces create confidence. A musician can forgive a feature being compact if the app is clear about where the real control lives.

2026-07-26 - A Future Surface Should Not Pretend To Exist

• Connection: Automation is real now, but its current expression is preview strips, badges, doorways, and an owner-scoped popup editor. Full expanded timeline Automation lanes would be a larger visual/workflow feature, and the app should not imply that surface exists until it actually does.
• Reuse path: this same boundary applies to Motion Clips, Scene orchestration, hardware editors, and future MPE/MIDI 2.0. A feature can be architecturally prepared without being customer-facing complete.
• Product implication: honest labels build trust. SpaceAge can say "this works here, this is coming later" and feel more professional than a tool that blurs those boundaries for marketing sparkle.

2026-07-26 - Geometry Bugs Are Trust Bugs

• Connection: the Automation popup was not conceptually wrong, but its list/graph helpers were reserving more vertical space than the visible strips actually used. That kind of invisible mismatch creates a cramped, suspicious interface even when the MIDI logic is correct.
• Reuse path: every popup and device editor should eventually have one source of truth for row heights, spacer heights, and action-strip heights. This same principle applies to synth pages, effects pages, Instrument Bay panels, and future automation/motion editors.
• Product implication: musicians judge software by what their hands and eyes feel. If text breathes and hitboxes match what is drawn, SpaceAge feels deliberate instead of patched together.

2026-07-26 - Delete Must Mean Silence, Not Hidden Memory

• Connection: deleting automation is conceptually like lifting a hand from a physical control. Internal synths and external hardware both need a neutral hand-off, or the app lies visually while the instrument keeps obeying the old value.
• Reuse path: the same "visible delete sends a musical reset" principle should apply to future Motion Clips, Scene swaps, hardware editor dumps, and per-lane mixer automation. If SpaceAge removes a control lane, it should also remove the audible consequence unless the user explicitly preserves it.
• Product implication: this is workflow trust. A composer should not need to know whether a sound is internal, SoundFont, or a rack synth to believe that deleting a pan curve actually deleted the pan curve.

2026-07-26 - A Doorway Can Be Short Only After It Is Learned

• Connection: AUTO is elegant once the user already knows what it means, but the Arrangement toolbar is a primary discovery surface. AUTOMATION is a better teaching label there, while tiny clip badges can keep the compact shorthand.
• Reuse path: future features should use this hierarchy: full names on primary doors, compact glyphs/counts on evidence badges, and deeper explanatory labels inside popups.
• Product implication: SpaceAge can stay minimal without becoming cryptic. The UI should feel designed, not like it is asking musicians to memorize internal abbreviations before making music.

2026-07-26 - Fast Confidence Loops Matter

• Connection: the fresh MIDI closeout regression pass is valid, but it took roughly 4.4 minutes. That is acceptable for release gates, not for every small MIDI correction.
• Reuse path: split large verification suites into fast focused slices and slower release slices for MIDI, Instrument Bay, render/export, synth audio sanity, and automation. The fast slice should answer "did this exact thing regress?" while the slow slice answers "is the whole subsystem still coherent?"
• Product implication: faster internal confidence means fewer rushed builds for Shane and fewer half-tested fixes. That directly supports the commercial goal: a DAW that feels stable because the development process can catch regressions without grinding to a halt.

2026-07-26 - Fast Gates Are Product Design, Too

• Connection: a MIDI_LIVE_INPUT_HEALTH gate is not a visible feature, but it protects a visible promise: "two controllers connected should not make SpaceAge mysterious."
• Reuse path: every major user promise should eventually have a tiny fast gate: adding a clip, recording a first beat, changing an Instrument, deleting automation, rendering a song, and opening a project.
• Product implication: speed in development creates steadiness in the app. The less friction there is to prove a fix, the less likely we are to ship brittle fixes that feel clever in code but cruel in the hands.

2026-07-26 - Open Ports Are A Promise, Not A Fact

• Connection: two open MIDI inputs are not automatically wrong, but they are an unresolved promise. Until the lane is pinned, split by channel, or intentionally layered, SpaceAge should treat the setup as potentially ambiguous rather than declaring a take clean.
• Reuse path: this same "open is not proven" rule should guide future hardware output ports, SysEx restore targets, MPE zones, Instrument Bay auditions, and external clock: a connected thing needs an explicit owner before we call it reliable.
• Product implication: this is how the app earns trust with real studios. It can support complex rigs without silently letting a second keyboard, DIN route, or interface port become an invisible co-author of a take.

2026-07-26 - A Clean Queue Is Not A Clean Take

• Connection: low queue age only proves messages were drained quickly. If two controllers fed an unpinned lane, the take may still be musically ambiguous because the app cannot assume which controller the performer intended.
• Reuse path: this source-trust idea should apply to future audio recording, MPE zones, hardware clock, and Scene/orchestration recording: timing data needs owner identity, not just low latency.
• Product implication: SpaceAge should build confidence by refusing false reassurance. "Timing suspect" is friendlier than letting the user discover later that the wrong controller contaminated a take.

2026-07-26 - Two Controllers Need A Traffic Cop

• Connection: a musician may reasonably keep a USB keyboard and a DIN/interface keyboard connected at the same time. If both can reach an unpinned lane, timing complaints can actually be source ambiguity, duplicate routing, or layered input rather than a bad synth or bad clock.
• Reuse path: the same diagnostic pattern should apply later to MPE zones, hardware editors, Scene orchestration, and external clock: identify every active source, expose ambiguity, and make pinning/splitting the next obvious user action.
• Product implication: SpaceAge can support complex rigs without making the user feel blamed. The app should say, "I see two controllers talking; choose whether that is intentional," then provide the exact doorway to fix it.

2026-07-26 - Counts Belong Where They Help, Not Everywhere

• Connection: a lane-level AUTO command should teach one doorway, while tiny clip badges can carry row-count shorthand because they are evidence markers inside constrained visual objects.
• Reuse path: future MOTION, SCENE, ghost-note, and hardware badges should separate command labels from evidence badges the same way: commands stay stable; tiny breadcrumbs can compress facts.
• Product implication: users learn the action once, then inspect details when needed. The app feels calmer because it does not rename the same tool based on internal row count.

2026-07-26 - Doorway Labels Must Match The Thing On Screen

• Connection: MIDI closeout reports can correctly discuss Automation, but the actual control Shane sees is AUTO. The action card has to point at the visible object, or the app starts teaching users to look for controls that do not exist.
• Reuse path: future compact controls such as MOTION, BAY, SCENE, or hardware profile badges should follow the same split: short button label on the surface, full explanatory name in panels, reports, docs, and tooltips.
• Product implication: musicians should not need to translate between engineering names and GUI names while composing. The app can be deep without forcing a vocabulary tax.

2026-07-26 - Diagnostics Should Point, Not Whisper

• Connection: live MIDI lag can come from several places: buffer size, direct-input queue age, hardware-output queue age, SoundFont voice preparation, drivers, interfaces, or monitoring path. If the Health cockpit only highlights some of those, the user may chase the wrong suspect.
• Reuse path: future audio-engine, render, hardware, and Instrument Bay diagnostics should share this design rule: one visible attention predicate per human symptom, with the deeper report explaining which subsystem caused it.
• Product implication: trust grows when SpaceAge says "this is the first thing to check" instead of scattering true facts across several quiet rows.

2026-07-26 - One Label, Many Doorways

• Connection: Piano Roll and Arrangement both reach the same Automation editor, so they should speak with the same compact surface language.
• Reuse path: this is the same rule we should use for future Motion Clips, Instrument Bay editing, and hardware setup surfaces: short doorway labels can stay consistent while the deeper editor explains ownership and consequences.
• Product implication: musicians learn one gesture and one label. That reduces scanning and makes advanced MIDI feel like part of the song workspace rather than a separate technical subsystem.

2026-07-26 - Breadcrumbs Beat Bigger Buttons

• Connection: Automation already had backend power and multiple entry points, but Arrangement workflow benefits from small visible cues that say "there is motion data here" without consuming a whole new lane.
• Reuse path: the same feature + count badge language can serve Motion Clips, ghost-note sources, clip notes, Chord Engine arp data, and future Scene/orchestration alternates.
• Product implication: users discover depth by glancing at their work, not by hunting in menus. A compact breadcrumb can make a sophisticated feature feel native instead of hidden.

2026-07-26 - Two Columns Can Be Mercy

• Connection: Settings had become a warehouse for important switches, especially MIDI tools. Keeping everything in one vertical stack made the bottom controls feel like afterthoughts even though MIDI setup is core workflow.
• Reuse path: future setup panels, Instrument Bay preferences, hardware profiles, and Scene management should prefer grouped columns or cards once a feature family grows beyond a handful of rows.
• Product implication: SpaceAge can expose power-user features without making the app feel like a tax form. Width is often kinder than height because users can scan families of choices without scrolling or wondering what got clipped.

2026-07-26 - Shorter Text Is A Workflow Feature

• Connection: the Automation popup needs to protect users from editing the wrong owner, but visible safety text can become its own kind of clutter. Short labels should teach the active decision; deeper explanations belong in tooltips, docs, or help panels.
• Reuse path: this applies directly to future Motion Clips, Instrument Bay reassignment dialogs, hardware setup wizards, XG editors, and effect popup editors. The first visible sentence should orient the user, not explain the whole architecture.
• Product implication: dense features can still feel elegant if the UI behaves like cockpit labeling: brief, legible, and backed by reliable deeper documentation.

2026-07-26 - Readability Is Musical Confidence

• Connection: automation is a performance-editing surface, not a diagnostic readout. If the popup is hard to read, the user hesitates right when they should be listening and shaping movement.
• Reuse path: the same readability standard should guide future Motion Clips, MIDI hardware profiles, XG editors, MPE expression editors, and any popup where the user edits time-based behavior.
• Product implication: clearer automation panels make advanced MIDI feel approachable. The user should be able to glance, understand the target, and act without squinting or second-guessing.

2026-07-26 - Controller Generations Are Seatbelts

• Connection: a physical MIDI device is not only a name; it is a currently valid connection. If a controller disconnects, reconnects, or has its slot invalidated, old queued bytes must not be allowed to steer the new musical moment.
• Reuse path: the same generation idea applies to hardware outputs, SysEx restore flows, external clock, future MPE zones, and any live-performance surface that can be unplugged while notes are in flight.
• Product implication: SpaceAge should feel calm around real hardware. A user can hot-plug or recover from a flaky interface without hidden stale messages becoming stuck notes, wrong recordings, or ghost controller movement.

2026-07-26 - Every Engine Needs A Passport

• Connection: if an engine can make sound but cannot save/load a patch, it is not truly part of the Instrument Bay yet. TG-55 exposed that boundary: audio and UI are not enough unless the sound can become a named, reusable musical object.
• Reuse path: future engines, VST wrappers, hardware editors, Quasar instruments, and Scene orchestration should all pass the same test: choose it, edit it, save it, recall it, route it, and keep mix state separate.
• Product implication: the user should never wonder whether a new synth is "real" inside SpaceAge. If it appears in the Instrument Bay, it should behave like a proper instrument from day one.

2026-07-26 - Ambience Belongs To The Mix, Not The Patch

• Connection: an Instrument patch should answer "what sound is this?" while the Mixer answers "where does this sound live in the room?" If synth pages expose Halostar/Reverb/EchoRay send controls, users can no longer tell whether ambience changed because of a preset or because of a mix decision.
• Reuse path: this boundary matters for Instrument Bay, Scenes, Quasar captures, VST wrappers, hardware patch recall, and future stem rendering. A lane can swap Instruments without secretly changing the channel strip's effects story.
• Product implication: the workflow becomes easier to explain and safer to use. Musicians can design a sound, mix it, and re-orchestrate it without hidden ambience changes following them around.

2026-07-26 - Copy And Variant Are Two Different Creative Promises

• Connection: copying another lane's Instrument into the current lane says, "keep this musical owner, change its sound." Variant says, "branch this musical owner into a fresh sound identity." They may share mechanics, but they should not share identity semantics.
• Reuse path: this distinction belongs in future Scenes, VST preset swaps, Quasar captures, hardware patch alternates, and A/B sound design. Copy preserves the owner; Variant creates a new branch.
• Product implication: users can explore without bookkeeping anxiety. The app can offer creative branching while keeping routing stable and names meaningful.

2026-07-26 - Fresh Sounds Should Keep The Player Connected

• Connection: choosing a new Instrument engine for a lane is not only a patch edit; it is a live-performance routing event if that lane is armed. The user's controller should keep playing the lane they selected.
• Reuse path: this same rule applies to preset swaps, SoundFont loads, VST replacement, hardware profile changes, and Scene orchestration. If the sound changes while the lane remains the owner, live input should follow without the user re-arming anything.
• Product implication: re-orchestration feels immediate instead of brittle. The user can try sounds while playing and trust that the lane, mixer channel, and MIDI path remain coherent.

2026-07-26 - Forking Shared Patterns Is Creative Safety

• Connection: clip patterns can become shared through clone/paste/older workflows, but a lane-owned Instrument change is a creative act scoped to that lane. Forking the shared pattern before retargeting protects both truths: the changed lane gets its new sound, and the other lane keeps its existing musical identity.
• Reuse path: this same fork-before-mutate rule belongs in future Chord Progression libraries, Motion Clips, Scenes, Quasar captures, imported MIDI stems, and hardware patch lanes. If two musical owners share data and one owner changes context, fork the data first.
• Product implication: users can re-orchestrate confidently. The app quietly prevents hidden crosstalk instead of making users learn which clips are secretly sharing a pattern under the hood.

2026-07-26 - Hide The Scaffolding, Teach The Workflow

• Connection: backing slots are useful while we migrate, but they are scaffolding. The user-facing record should describe musical ownership: this lane owns this Instrument, uses this mixer channel, listens on this MIDI channel.
• Reuse path: the same principle applies to hardware profiles, VST hosting, Quasar packages, Scenes, and future automation/Motion Clip routing. Tell the user what they can act on, not how the data happens to be stored.
• Product implication: SpaceAge feels less like a prototype when temporary architecture stays invisible. The musician sees a lane, an Instrument, a mixer channel, and a musical result.

2026-07-26 - Labels Are Architecture Too

• Connection: a feature can route correctly and still teach the wrong model if its labels expose the old Pad bridge. The Synth Editor header is not decoration; it tells the user what object they are editing.
• Reuse path: every shared editor should pair routing tests with language tests: Instrument Bay, Synth Editors, hardware editors, VST wrappers, Quasar, and automation popups.
• Product implication: removing backend-ish words from the live surface makes SpaceAge feel deliberate. The user learns the final workflow by reading what is already on screen.

2026-07-26 - Automation Must Be Heard As Soon As It Is Drawn

• Connection: drawing or moving automation is not merely editing stored MIDI data; it is a sound-design gesture performed while listening. The audible state should answer immediately, or the user starts doubting whether the editor is real.
• Reuse path: the same live-latch rule belongs in future Motion Clips, synth macro automation, MPE editing, hardware CC editors, and any curve-drawing tool that changes sound over time.
• Product implication: immediate sonic feedback turns automation from bookkeeping into play. When a user hears the curve while drawing it, SpaceAge feels like an instrument instead of a spreadsheet.

2026-07-25 - Clearing Is Part Of Identity

• Connection: when a user chooses a new preset, the app is not just changing oscillator settings; it is replacing the sound identity for the selected musical owner. If that owner is a lane Instrument, resource cleanup should not sneak through a Pad-only path.
• Reuse path: this same owner-aware cleanup pattern belongs in future VST swaps, hardware patch loads, SoundFont imports, Quasar rebuilds, and Scene orchestration.
• Product implication: users can change sounds fearlessly because the app cleans the right object. That trust matters more than the storage details under the floorboards.

2026-07-25 - The Same Knob Can Belong To Different Worlds

• Connection: a Synth Editor control can edit a Drum Pad, a lane-owned Instrument, a future VST wrapper, or a hardware profile. The action must follow the owner, not the widget.
• Reuse path: active-target helpers should become the default pattern for future shared editor panels, especially Instrument Bay, SoundFont, Quasar, VST hosting, and hardware setup.
• Product implication: musicians should feel one coherent interface. They do not need to know which storage table currently holds the sound.

2026-07-25 - Owner-Aware Buttons Keep The Promise

• Connection: a clear/load button is not just maintenance; it tells the user what kind of object they are editing. If a lane Instrument clears like a Pad, the old mental model leaks back in.
• Reuse path: this owner-aware action pattern should be reused by future Instrument Bay imports, VST swaps, SoundFont relinking, Quasar rebuilding, hardware patch dumps, and Scene orchestration.
• Product implication: users can trust that the lane is the musical owner. The app can still use transitional storage internally, but the surface stays clean and intentional.

2026-07-25 - Menus Are Tiny Teachers

• Connection: every submenu is a small lesson in how SpaceAge wants the user to think. Lane Instrument teaches the correct object model; hidden slot language teaches implementation trivia.
• Reuse path: this same language discipline should guide the future Instrument Bay, preset browser, hardware profiles, Scenes, and VST hosting.
• Product implication: if the menu says what the musician is actually doing, the workflow feels calmer. The app becomes easier to trust before the user has consciously learned it.

2026-07-25 - Preset Choice Should Rename The Musical Object

• Connection: choosing a preset is part sound design and part orientation. If the user chooses a patch for a lane Instrument, the lane should inherit that musical identity without exposing the old pad-backed storage.
• Reuse path: the same owner-aware naming pattern should govern future preset browser categories, Scene orchestration, hardware patch recall, and Quasar/SoundFont imports.
• Product implication: users can trust the lane badge as the truth. The interface says, "this lane owns this sound," not "this lane is borrowing a hidden pad."

2026-07-25 - Save Buttons Should Respect The Owner

• Connection: saving a patch is a trust moment. If a user saves a Redshift patch from a lane, the app should update the lane's Instrument identity, not behave as though the user secretly edited a Drum Pad.
• Reuse path: this same owner-aware save doorway should govern future VST presets, hardware patch recipes, Quasar packages, SoundFont metadata, and Scene orchestration.
• Product implication: users can save happy accidents without wondering which hidden slot received the name. The surface stays musical.

2026-07-25 - File Names Also Teach The Instrument Model

• Connection: a patch filename suggestion can reinforce or undermine the workflow just as much as a button label. Harmony Test Fresh Redshift feels like a musical object; Pad 53 feels like a hidden machine part.
• Reuse path: this same naming rule should apply to exports, Quasar packages, SoundFont mappings, hardware profiles, Scenes, and future preset browser metadata.
• Product implication: users trust systems that name things the way they think about them. Good names are small UX compasses.

2026-07-25 - Context Survives The Button Press

• Connection: the copy button is not just a utility; it is a small teacher. If it says COPY INSTRUMENT while the user is editing a lane, it should keep saying that after being used.
• Reuse path: every reusable editor surface should refresh visible language from the current musical owner after actions: lane Instrument, Drum Pad, effect return, hardware profile, or future Scene override.
• Product implication: tiny wording stability makes the app feel intentional. The user should never sense that an old internal model briefly poked through the polished workflow.

2026-07-25 - Variation Without Rewiring

• Connection: a variant is a compositional promise: "same part, new sound possibility." It should alter the instrument identity while leaving the lane's routing and arrangement meaning intact.
• Reuse path: this same model should power future Scene orchestration, A/B patch auditioning, SoundFont swaps, Quasar captures, and VST replacement. The notes and chords stay in place while the sound identity branches.
• Product implication: this lets users explore tone without fear. SpaceAge can invite experimentation because the mixer, clips, and lane role do not unravel when a user asks for a variation.

2026-07-25 - Replace The Engine, Not The Lane

• Connection: a songwriter may change a lane from Redshift to Liftoff because the part wants a different color, but the lane is still the musical role, the mixer route, and the clip container. The instrument engine should be replaceable without moving the furniture around it.
• Reuse path: this same idea should guide Scenes, preset auditioning, VST swaps, SoundFont replacement, and future hardware orchestration. A lane can try a different sound without losing routing, notes, automation, or arrangement context.
• Product implication: SpaceAge can make re-orchestration feel playful instead of risky. The app says, "try the new sound here," not "start over."

2026-07-25 - Every Controller Is A Performer

• Connection: two hardware controllers are not just two cables; they may represent two hands, two musicians, or one keyboard plus one expressive surface. SpaceAge should not flatten them into one anonymous MIDI stream when direct source identity exists.
• Reuse path: this same source-aware thinking belongs in future MPE zones, hardware editors, automation capture, MIDI guitar, wind controllers, and external sequencer workflows.
• Product implication: the app can feel unusually trustworthy with hardware. When a user plugs in several things, SpaceAge should know who played what and avoid mysterious stolen releases.

2026-07-25 - One Gesture, One Audible Consequence

• Connection: MIDI recording is both a capture action and a performance action. The musician presses one key and should hear one voice, while SpaceAge quietly records timing and length in the background.
• Reuse path: this same rule should apply to automation capture, MPE gestures, hardware MIDI echo, and future audio recording: capture the gesture without duplicating its audible consequence.
• Product implication: this keeps recording feeling natural. The app can be technically rich underneath, but the user's body should experience one clean cause and one clean result.

2026-07-25 - Doorways Matter More Than Storage

• Connection: while the backend still has transitional private slots, the visible doorway must already behave like the final product. If Add Instrument Lane refuses Drum Pad space, the user learns that Pads are for Drum Composer behavior and lanes own Instruments.
• Reuse path: apply this same doorway rule to VST hosting, hardware profiles, Quasar instruments, SoundFonts, and future Scenes. Let advanced storage be flexible internally, but keep each user action semantically clean.
• Product implication: this is how SpaceAge can grow without becoming a maze. Powerful features can share infrastructure underneath while the musician sees one obvious place to make each kind of decision.

2026-07-25 - Fast Proof Loops Protect Creative Momentum

• Connection: if MIDI protocol tests take too long or give misleading output, development starts feeling like ritual instead of engineering. Splitting the proof surface lets us check the part we touched and keep moving.
• Reuse path: every large subsystem should eventually have one foundation gate and smaller topical gates: import, recording, routing, automation, hardware, instruments, effects, rendering, and UI clipping.
• Product implication: faster internal confidence loops mean fewer half-fixed builds reach Shane. That preserves the playful design rhythm instead of turning every beta pass into an archaeological dig.

2026-07-25 - Rejecting Is Sometimes More Musical Than Translating

• Connection: when a user asks for an Instrument lane, silently converting a Pad-number target into a hidden Instrument target teaches the wrong mental model even if the resulting sound works.
• Reuse path: future Instrument Bay, VST, hardware profile, and Scene workflows should reject category mistakes at the doorway: Drum Pads belong to Drum Composer behavior, while Instrument lanes own Instruments.
• Product implication: a clear refusal is less confusing than a clever fallback. Musicians can recover from a direct message; they lose trust when the app appears to make invisible substitutions.

2026-07-25 - Import Is Also Product Design

• Connection: importing a MIDI file is not only a parser operation; it is a short conversation about where old musical information should live in SpaceAge.
• Reuse path: the same language pattern belongs in future hardware import, SoundFont mapping, XG editor, and Scene workflows: choose an Instrument, choose a Mixer Channel, preserve performance expression when it matters.
• Product implication: if import copy is plain, musicians trust the app sooner. If it exposes bridge mechanics, they start wondering whether the whole system is secretly a workaround.

2026-07-25 - Availability Is The Gentle Word

• Connection: Available Instrument sounds like a thing waiting to be chosen; Lane-ready Instrument sounds like a system state. SpaceAge should teach the first idea.
• Reuse path: this wording can scale into future Instrument Bay filters such as Available, In Use, Missing Source, Hardware, SoundFont, Quasar, and Scene Override.
• Product implication: every label that avoids backend trivia makes the Instrument Bay migration feel deliberate instead of transitional.

2026-07-25 - Names Teach The Architecture

• Connection: the user learns SpaceAge's mental model from labels long before reading a manual. A lane-owned Instrument title that still smells like a Pad quietly teaches the wrong architecture.
• Reuse path: every future editor surface should ask, "Am I editing a Drum Pad, a lane Instrument, a hardware profile, or an effect return?" before choosing title text, side labels, and copy/paste language.
• Product implication: clear labels reduce the feeling that SpaceAge is a pile of hidden proxies. The app should feel like lanes own instruments, pads own drum-grid behavior, and the mixer receives both deliberately.

2026-07-25 - One Label Door For Shared Instruments

• Connection: synth engines, SoundFonts, and Quasar can be used from both Pad and Arrangement workflows, so they need one place to decide which identity system is being edited.
• Reuse path: future VST instruments, TG55-style editors, hardware profiles, and AI-generated patches should call the target-aware label helper rather than setting Pad labels directly.
• Product implication: users can load the same kind of sound into different musical contexts without seeing the app confuse a lane Instrument with a Drum Pad.

2026-07-25 - Quasar Belongs In Both Worlds, But Not With One Name

• Connection: Quasar can be loaded onto a Drum Pad or a lane Instrument, but those are different workflows and should not share Pad labeling when the target is a lane.
• Reuse path: future sample engines, VST instruments, and hardware-backed instruments should branch at the identity boundary: visible Pad labels for drum-grid targets, InstrumentSlot labels for Arrangement lanes.
• Product implication: a powerful engine can live in both the MPC-style and lane-composition worlds without making either world feel like a workaround.

2026-07-25 - Tests Are Part Of The Interface Contract

• Connection: a test looking for old wording is a tiny fossil that can keep the old workflow alive in the codebase.
• Reuse path: every time SpaceAge renames a core concept, update both visible text and the regressions that describe what the user should see.
• Product implication: tests become a guardrail for clarity, not just correctness. They protect the language of the app as much as the audio behavior.

2026-07-25 - Source Reads Matter As Much As Source Writes

• Connection: the old Pad model can leak through read-only calls too. Even if nothing is mutated, asking Pad-shaped questions from Piano Roll code trains the next feature to think in Pads again.
• Reuse path: future UI inspectors, preset browsers, automation targets, and hardware-lane profiles should ask lane-Instrument wrappers for source identity rather than peeking into storage-specific calls.
• Product implication: fewer confusing edge cases. The screen says lane Instrument, the code asks lane Instrument, and the user never has to learn the bridge underneath.

2026-07-25 - New Lanes Should Start Clean Without Touching Drums

• Connection: Add Lane is one of the moments where users are trusting SpaceAge most. It should create a clean Instrument without any chance of touching a Drum Pad behind the curtain.
• Reuse path: future Instrument Bay creation, VST instantiation, Quasar import, and hardware profile setup should share guarded creation helpers instead of reaching into legacy Pad storage directly.
• Product implication: the user learns one clean rule: Drum Pads are drums, Instrument lanes are instruments. The bridge code should protect that rule even before the final registry exists.

2026-07-25 - Wrappers Let The Old Engine Become Invisible

• Connection: the audio engine still has historical pad-shaped storage, but editor workflows can stop caring when every non-drum path goes through InstrumentSlot wrappers.
• Reuse path: Quasar import, VST instance creation, SoundFont loading, and future preset-browser actions should all get wrapper APIs before UI code reaches into storage-shaped functions.
• Product implication: this is how SpaceAge earns a clean workflow without requiring a dangerous big-bang rewrite. The old plumbing fades behind better nouns and stricter boundaries.

2026-07-25 - Menu Names Are Future Workflow Seeds

• Connection: the COPY INSTRUMENT SETTINGS FROM LANE menu is a good workflow because it says exactly what happens: copy another lane's Instrument settings into this lane.
• Reuse path: future source-copy menus for Scenes, Hardware Passports, Quasar captures, and VST presets should keep this copy/source language rather than exposing the storage browser as the assigned object.
• Product implication: when the code names match the musician's action, later features are less likely to grow confusing intermediary choices.

2026-07-25 - One Source Of Truth For Capacity

• Connection: lane creation, duplicate-slot repair, import, and future Instrument Bay browsing all need the same answer to one question: "can this private slot safely become a lane Instrument?"
• Reuse path: any future VST, Quasar, SoundFont, hardware profile, or Scene orchestration workflow should ask the processor/model for availability instead of rebuilding UI-local checks.
• Product implication: capacity limits are less likely to appear as random GUI failures. If SpaceAge cannot create another lane Instrument, the reason should be model-truth, not a stale editor assumption.

2026-07-25 - Import Wizards Should Teach Ownership

• Connection: MIDI import is often a user's first contact with external material, so its wording should teach the lane model from the start.
• Reuse path: future importers for SoundFonts, Quasar packages, VST presets, hardware profiles, and Scenes should say what will be created in the Arrangement, not expose where the choice was found.
• Product implication: "choose a lane Instrument" sounds like a musical decision. "choose an Instrument Bay preset" sounds like storage management.

2026-07-25 - Naming Is Architecture

• Connection: a helper called formatInstrumentBayLabel() keeps nudging future code toward the old abstraction even when the visible workflow is lane-owned Instruments.
• Reuse path: future helpers should name the user-facing job they perform, such as lane choice, hardware route, patch identity, or mixer destination, rather than the temporary storage mechanism underneath.
• Product implication: clean names make future features easier to add because the code itself keeps reminding us what the musician should experience.

2026-07-25 - Available Instruments Should Sound Ready, Not Abstract

• Connection: AVAILABLE INSTRUMENT suggests a musical choice the user can actually put on a lane, while pool, slot, or lane-ready suggests a developer container.
• Reuse path: future Instrument Bay browser copy should favor action-ready states: Ready, Loaded, Missing Source, Needs SoundFont, In Use, and Variant, rather than storage labels.
• Product implication: the less SpaceAge talks like its internals, the more it feels like a purposeful studio surface.

2026-07-25 - SoundFonts Are Instruments, Not Pads

• Connection: a SoundFont on a melodic lane should feel like a lane instrument, even if the bridge-phase storage still passes through an internal slot number.
• Reuse path: the same wrapper pattern belongs around Quasar, VST instruments, hardware profiles, and future preset-browser records so UI code can ask for "this slot's instrument state" without needing to know whether the storage is old Pad space or new lane-owned space.
• Product implication: the more completely the lane surface says Instrument, the less the user has to remember which parts of SpaceAge are still transitional under the hood.

2026-07-25 - Borrowing A Sound Should Feel Like Sampling An Instrument

• Connection: COPY INSTRUMENT SETTINGS FROM LANE is conceptually closer to sampling or duplicating a patch than routing two lanes into the same generator.
• Reuse path: this same distinction should guide patch browsers, Scene orchestration, VST presets, Hardware Passport templates, and future "try this sound here" workflows.
• Product implication: SpaceAge can encourage fearless experimentation because a musician can borrow the character of a sound without creating invisible dependencies.

2026-07-25 - Independence Requires Copy-On-Assign

• Connection: if an Instrument lane borrows another lane's sound, the musically useful behavior is "copy this sound here," not "make these two lanes secretly share one machine."
• Reuse path: the same copy-on-assign rule belongs in future VST lane instruments, hardware scenes, Quasar captures, template lanes, and Scene orchestration alternatives.
• Product implication: users can experiment freely. Changing a bass lane patch tomorrow should not mutate a harmony lane merely because both were once cloned from the same source.

2026-07-25 - Instrument Identity Is The Anchor

• Connection: a lane's instrument identity should survive lane movement, mixer reassignment, project restore, and future Scene swaps without becoming confused with a hidden backing slot.
• Reuse path: the same unique-identity repair belongs in future Instrument Bay records, VST instances, Quasar instruments, external hardware profiles, and Scene orchestration alternatives.
• Product implication: if a musician changes one lane's sound, only that lane should change. The app should feel like a studio with labeled instruments, not a pile of shared internal slots.

2026-07-25 - New Lanes Should Teach The Arrangement Stack

• Connection: creating an Instrument lane at the top and a Drum lane near the drum stack quietly teaches the orchestration model without a lesson screen.
• Reuse path: the same placement intelligence belongs in future Scene orchestration, imported MIDI split lanes, ghost-note source lists, and template/song-form creation.
• Product implication: the user feels guided by the layout itself. Good defaults reduce the need for explanation and make the app feel intentional.

2026-07-25 - Editing An Instrument Should Not Move The Musician's Hands

• Connection: the lane badge is becoming the trusted place to inspect and edit an instrument. Opening that editor should not secretly change the Pad page underneath, because that makes the app feel like two workflows are fighting each other.
• Reuse path: the same "context does not hijack unrelated selection" rule belongs in Automation, Mixer subpages, Hardware Passport editors, Quasar package reveal, and future VST editor windows.
• Product implication: users can jump from lane to synth editing and back without losing orientation. That is the difference between a professional workflow and a clever prototype.

2026-07-25 - The First Beat Deserves Mercy

• Connection: a human can play exactly on the first beat while the computer sees the event a hair before the audio block. SpaceAge should treat that as musical intent, not as a failed target.
• Reuse path: the same "small edge tolerance, hard wrong-target rejection" pattern should apply to Automation capture, loop boundaries, clip slicing, and future Motion Clips.
• Product implication: the app feels fair. It catches real mistakes without punishing the tiny timing realities of live performance.

2026-07-25 - Timing Trust Needs A Black Box Recorder

• Connection: live MIDI feel is partly musical and partly forensic. SpaceAge should help separate audio-buffer delay, app queue delay, interface delay, controller delay, and SoundFont preparedness instead of leaving the user to guess.
• Reuse path: the same diagnostic style belongs in render progress, Quasar capture, SysEx restore, hardware editor handshakes, and future VST hosting: tell the user where the evidence points, not just that something feels wrong.
• Product implication: confidence grows when the app can say, "I played the note immediately once I received it, but this device path arrived late." That is a professional answer.

2026-07-25 - Bad Takes Should Fail Loudly, Not Musically

• Connection: Arrangement recording is a trust contract. If SpaceAge knows the user meant "record into this clip," then a failed coordinate mapping should not silently become a note at the beginning of the pattern.
• Reuse path: this same principle belongs in Automation capture, Quasar sampling, render/export, hardware SysEx restore, and future Motion Clips: when the target is explicit, reject wrong-target data and make the diagnostic visible.
• Product implication: musicians can recover from a clear warning. They lose confidence when a take appears to work but the notes are quietly wrong.

2026-07-25 - Defaults Should Behave Like A Good Studio Assistant

• Connection: when a user creates a lane, they should not have to know MIDI channel bookkeeping yet. SpaceAge can quietly choose a clean channel while keeping the route visible on the lane.
• Reuse path: this same "choose the least surprising available resource" rule belongs in mixer-channel assignment, hardware output defaults, Quasar sample maps, Scene orchestration swaps, and future VST routing.
• Product implication: smart defaults make the app feel professional without hiding control. The musician can change the channel later, but the first result should already make sense.

2026-07-25 - Internal Storage Should Never Become The Metaphor

• Connection: private instrument slots can still be backed by old pad-index storage, but the interface must call them Instruments because that is the musician's mental model.
• Reuse path: future Quasar packages, Scenes, hardware profiles, and Automation owners should all separate internal IDs from the names shown in the creative workspace.
• Product implication: SpaceAge can keep moving fast internally without making users feel like they are managing implementation leftovers.

2026-07-25 - Route Changes Should Feel Instant Everywhere

• Connection: a lane mixer reassignment is not just an audio decision; it changes what the Arrangement lane, MIDI record path, playback snapshot, and future Instrument Bay inspector all need to agree on.
• Reuse path: every future lane-level route edit should use the same publication rhythm: normalize the lane, refresh demand snapshots, refresh device interest, then publish playback state.
• Product implication: SpaceAge feels trustworthy when changing a lane destination immediately updates sound, recording, labels, and saved project state without requiring a page switch.

2026-07-25 - The Lane Should Teach Its Own Signal Path

• Connection: if the lane says MIXER CHANNEL 08 / MIDI CHANNEL 03, the user does not need a top inspector to understand the route.
• Reuse path: this same literal labeling should appear in future Hardware Passport routing cards, render/stem names, Scene orchestration swaps, and MIDI setup receipts.
• Product implication: removing intermediary controls only works if the remaining surface is self-explanatory. The lane badge is now the teacher.

2026-07-25 - One Door, Three Owners

• Connection: Automation becomes easier to trust when the doorway is always named Automation, while ownership details are handled where the user is ready to edit: Shared PTN, Clip Local, or Lane Local.
• Reuse path: future Motion Clips, synth modulation lanes, and effect automation should follow the same pattern: one plain doorway, then explicit ownership/scope controls inside.
• Product implication: the user does not have to learn AUTO, AUTO LANES, and Shared PTN Data as separate ideas before doing the musical thing.

2026-07-25 - Every Route Has A Musical Name

• Connection: MIDI Health can route to many technical surfaces, but each one should sound like a musical or setup task: Hardware proof, MIDI timing, SysEx, Automation, or control mapping.
• Reuse path: use the same naming discipline for future Instrument Bay setup cards, Lane Signal panels, hardware editor pages, and project-open recovery tasks.
• Product implication: advanced MIDI support feels less intimidating when every doorway tells the user what kind of work they are about to do.

2026-07-25 - Cockpit Copy Should Be A Doorway, Not A Dump

• Connection: the MIDI cockpit is part of the musician's trust surface, so its summaries should name the action in plain language while preserving IDs underneath for routing and support.
• Reuse path: this pattern should shape future Instrument Bay launch cards, Automation editor action cards, render/export progress panels, and hardware setup wizards.
• Product implication: SpaceAge can expose advanced MIDI proof without making the user feel like they have opened a developer console.

2026-07-25 - Proof Summaries Should Sound Like Instructions

• Connection: QA evidence can stay structured without sounding like a variable dump. The summary should teach the tester what proof exists, while the serialized receipt keeps the machine-readable fields.
• Reuse path: use the same split for Hardware Passport receipts, SysEx restore summaries, Quasar package receipts, render/export receipts, Scene proofs, and future Motion Clip evidence.
• Product implication: reports that read like instructions reduce anxiety and make SpaceAge feel professionally supervised instead of internally exposed.

2026-07-25 - Compact Labels Need Full Explanations Nearby

• Connection: a tiny badge can say AUTO because space is scarce, but reports and tooltips should say Automation so the user does not have to decode house shorthand.
• Reuse path: the same rule should govern mixer strip mini-buttons, lane badges, MIDI/HW abbreviations, future Motion Clip icons, and small synth control labels.
• Product implication: SpaceAge can be compact without feeling cryptic if every compact glyph has a nearby full-language explanation somewhere in the workflow.

2026-07-25 - Machine Keys Should Stay Backstage

• Connection: receipt systems need durable internal keys, but musicians need plain proof prompts. The same object can serve both if stored keys remain stable while visible hints translate them.
• Reuse path: this pattern should apply to Instrument Bay IDs, Quasar package IDs, Hardware Passport fields, future Scene IDs, and Automation/Motion Clip ownership labels.
• Product implication: hiding implementation keys keeps SpaceAge feeling designed instead of debuggy, while still letting support and tests reason precisely about what happened.

2026-07-25 - Not Every Checklist Item Wants The Same Proof

• Connection: a release checklist is only useful if each row asks for the right kind of evidence. Hardware needs hardware proof; file import/export needs real files; public wording needs careful copy review, not a pretend technical receipt.
• Reuse path: future shippability dashboards should carry artifact type as a first-class idea: saved QA receipt, hardware listening note, round-trip file, screenshot/video, release-copy audit, or manual confirmation.
• Product implication: SpaceAge will feel more professional if its internal closeout rituals match real-world product work instead of flattening everything into one generic checkbox.

2026-07-25 - Trust Language Is Interface Design

• Connection: MIDI Health and closeout reports are part of the product surface. If the trust-boundary wording is clumsy, users feel the machinery underneath instead of the calm promise of the workflow.
• Reuse path: future Automation rows, Motion Clips, Hardware Passport receipts, export reports, and educational tooltips should all use the same discipline: name the visible musical object, then state exactly what is proven and what still needs auditioning.
• Product implication: honest language can still feel confident. This is how SpaceAge avoids overclaiming while sounding like a serious instrument.

2026-07-24 - Import Defaults Should Behave Like A Composer Assistant

• Connection: MIDI import is often the first moment SpaceAge interprets another app's work. Default destinations should feel like thoughtful lane choices, not arithmetic artifacts from hidden storage.
• Reuse path: the same prefer available, avoid duplicate, let the user override rule should apply to future SoundFont imports, Quasar package creation, hardware template loading, and scene/orchestration swaps.
• Product implication: good defaults make advanced workflows feel calm. The user can still make deliberate choices, but the app stops starting from a weird old internal assumption.

2026-07-24 - Copy Language Should Reveal Ownership

• Connection: COPY, CLONE, and VARIANT all carry ownership assumptions. For lane instruments, the wording must state whether the result is linked or independent, because sound design confidence depends on knowing whether one edit will affect another lane.
• Reuse path: Instrument Bay, preset browser, automation templates, Quasar package duplication, and future Scenes should all use explicit ownership language when copying musical objects.
• Product implication: the user should never need to guess whether changing a copied sound will mutate another lane. Clear language prevents fear-driven workflows.

2026-07-24 - Automation As A Visible Songwriting Object

Automation should feel like part of arranging, not a diagnostic MIDI utility. Placing the doorway near snap, cut, and render connects expressive controller data to ordinary composition gestures: draw a clip, cut it, automate it, render it. This also sets up a future visual language where clips can show tiny automation glyphs alongside note previews without making the canvas visually chaotic.

2026-07-24 - Transitional Storage Should Not Become Product Language

Instrument Bay cleanup is as much language design as code design. If a hidden lane-owned slot is described as "private" or as an Instrument Bay slot, the user learns implementation trivia instead of the product model. Calling the object a Lane Instrument keeps the musician's mental map simple: Pads are for Drum Composer and MPC-style work; the Instrument Bay is where lane instruments are chosen and managed.

2026-07-24 - Context Text As Workflow Guardrail

• Connection: wording is part of architecture. If a lane-owned synth editor says pad-ish things, users will correctly infer the model is still pad-owned. The UI now treats context labels as guardrails that teach the intended workflow.
• Reuse path: future Instrument Bay, automation target pickers, and render dialogs should use the same rule: name the user-facing musical object, not the temporary storage implementation.

2026-07-24 - Lane Routing As A Stable Patch Cable

• Treat each instrument lane like a stable patch cable: the user may change the instrument at the source without unexpectedly moving the channel strip destination. This lets a composer audition orchestration choices without blowing up the mix.

2026-07-24 - Overview Should Fit, Not Collapse

• Connection: Arrangement overview is a navigation gesture first, not a separate editing mode. O should show the whole song as large as possible and only simplify lane chrome when there is genuinely not enough vertical room.
• Reuse path: future Piano Roll/Automation/Motion Clip overview shortcuts should follow the same rule: fit the work at maximum useful scale before sacrificing controls or labels.
• Product implication: a shortcut that preserves context feels like assistance; a shortcut that suddenly hides controls feels like the app changed rooms without asking.

2026-07-24 - Clip Interiors As Trust Signals

• Connection: the miniature note drawing inside a clip is not decoration; it is a trust signal. If it lies about long clips, users begin doubting the Arrangement Canvas.
• Reuse path: the same time-sorted preview principle should apply to future automation lanes, Motion Clips, Chord Engine summaries, and waveform thumbnails.
• Product implication: subtle visual truth makes SpaceAge feel professionally grounded without adding visual clutter.

2026-07-24 - Lane Instrument Labels As Navigation

• Connection: the same label should teach the same concept everywhere. Reusing the lane instrument route label in the Synth Editor makes the lane badge, editor title, mixer assignment, and MIDI channel feel like one object instead of separate menus.
• Reuse path: this label pattern should carry into the future Instrument Bay browser, automation target picker, render stem names, and hardware routing panels.
• Product implication: fewer hidden translations means less user doubt. A composer should know exactly which lane, instrument, mixer channel, and MIDI channel they are touching.

2026-07-24 - Recording As A Performance, Cleanup As Housekeeping

• Connection: human-played notes and generated cleanup events share storage, but they should not share every timing rule. Performance input deserves latency compensation and musical placement; cleanup deserves deterministic closure so the project stays sane.
• Reuse path: the same distinction will matter for future automation capture, sustain-pedal cleanup, MPE gesture lanes, and hardware editor panic/release flows.
• Product implication: the user should feel that SpaceAge catches the first bar confidently and also cleans up broken controller/device states invisibly. That is the kind of invisible correctness that makes a music app feel calm.

2026-07-22 - Late Direct MIDI Live Drain Plays Immediately

• Connection: MIDI feel has a player-facing layer and a notation/editing layer. SpaceAge should keep those separate whenever necessary: what the player hears must feel immediate, while what the song stores must remain musically accurate.
• Reuse path: this same split applies to future automation recording, MPE gesture capture, and hardware editor moves: monitor instantly, commit precisely.

2026-07-22 - Playback Snapshot Note-Step Indexing

• Connection: the same indexed timeline idea can serve future automation lanes, Motion Clips, chord markers, and visual clip interiors. If an event belongs to a step or tick, the playback/paint layer should be able to ask for exactly that slice instead of rummaging through the whole clip.
• Product implication: smooth timing is part of the instrument feel. The user experiences this as confidence, not as an optimization.

2026-07-22 - Direct Slot Reuse Closes Recorded Notes At Current Step

• Direct MIDI source preparation now passes the current recording step into slot-generation retirement instead of always retiring old direct sources at step 0.
• Added regression coverage for a controller slot handoff during recording: the old held note closes at the timestamped handoff step, including wrap-safe end-of-loop starts, while the new controller owns its new note and voice.
• Updated architecture notes so same-channel/same-note source ownership is no longer listed as missing; the remaining frontier is real-controller timing/proof and live-onset performance cleanup.

2026-07-22 - MIDI Cockpit Public Claim Flag Requires Hardware Proof

• Tightened the MIDI launch-validation cockpit card so publicClaimsAllowed now requires both saved PASS launch receipts and clear hardware-proof release checks.
• Launch progress can still show PASS/100%, but public-facing MIDI claims remain blocked when Hardware Passport/timing/real-device proof is pending.
• Regression coverage now rejects the old misleading publicClaimsAllowed=yes state for launch-proof-complete but hardware-proof-pending projects.

2026-07-22 - MIDI Ship-State Separates Launch Proof From Hardware Proof

• midiOneShipStateSummary() no longer calls the app shippable just because launch-proof receipts are complete. It now reports launch-proof gate PASS / hardware proof pending until Hardware Passport/timing/round-trip/restoration proof checks are also clear, keeping public MIDI wording conservative and honest.

2026-07-22 - MIDI Launch Proof Review Summary Wording

• Completed MIDI launch validation summaries now say MIDI launch validation proof review instead of Next MIDI launch validation receipt/template, so plain-text reports, exported health fields, and the Health button all agree that all-PASS proof is review-only.

2026-07-22 - MIDI Launch Proof Complete State Becomes Review-Only

• The midi.validation.complete pseudo-receipt is now converted as a saved/reviewable PASS state, so the backend action surface, cockpit card, and Health button agree on REVIEW LAUNCH PROOF instead of offering another completion form after all launch-proof buckets are already satisfied.

2026-07-22 - MIDI Health Launch Proof Review State

• MIDI Health now preserves launch-proof wording after all launch validation buckets have saved PASS receipts: the action button reads REVIEW LAUNCH PROOF, and the review dialog/report title use launch-proof language instead of generic QA wording.

2026-07-22 - MIDI Health Launch Proof Doorway Label

• Changed launch-validation cockpit actions so their doorway label is Launch Proof instead of generic QA Receipt while keeping generic closeout QA receipts labeled QA Receipt.
• Regression assertions now protect the distinction, reducing proof-gathering ambiguity in MIDI Health.

2026-07-22 - MIDI Health Launch Proof Button Width

• Widened the MIDI Health receipt action button so COMPLETE LAUNCH PROOF / SAVE LAUNCH PROOF can be read instead of being clipped by the older QA-sized button slot.
• This keeps the launch-proof cockpit action explicit without requiring the user to infer meaning from a shortened label.

2026-07-22 - MIDI Launch Proof Button Wording Alignment

• Aligned the visible MIDI Health receipt button and modal save button with the model-owned launch-proof wording: SAVE LAUNCH PROOF / COMPLETE LAUNCH PROOF.
• This removes a small but meaningful mismatch between the cockpit action surface and the launch-validation proof model.

2026-07-22 - MIDI Health Ship State Layout Closeout

• Reserved the extra visible MIDI Health row added by SHIP STATE so the Health cockpit layout no longer undercounts itself.
• Updated the fixed summary card height and row count together; this keeps the launch-proof/public-claim status visible without crowding lower rows.

2026-07-22 - Shared Machinery, Separate Emotional Labels

• Connection: launch proof and QA receipts are the same ledger mechanism, but the user should not have to infer which trust phase they are in from backend keys.
• Reuse path: SpaceAge can reuse storage/action machinery while letting each surface speak its own product language: launch proof, render proof, hardware proof, import proof, and so on.
• Product implication: this is a small example of making engineering depth feel calm rather than bureaucratic.

2026-07-22 - Button Words Should Match The User's Trust Phase

• Connection: a launch-proof task and a QA task can share machinery, but they should not share vague labels. The user should feel whether they are doing internal QA or gathering evidence for public launch confidence.
• Reuse path: future render, VST, hardware-editor, and export proof flows should keep their button labels tied to the promise being proven, even when the backend storage/action system is shared.
• Product implication: precise button wording reduces anxiety because the user knows what phase of work they are in before clicking.

2026-07-22 - One Ship-State Sentence Prevents Fake Certainty

• Connection: percentages and proof queues are useful, but a user needs one sentence that says whether a feature is shippable. The new MIDI SHIP STATE row gives SpaceAge that high-level truth without hiding the deeper evidence.
• Reuse path: render/export, VST hosting, SoundFont relocation, and future hardware editors should get the same pattern: backend state, public claim state, next proof target.
• Product implication: honest status language can become part of the brand. SpaceAge should feel ambitious, but never slippery about what has actually been proven.

2026-07-22 - MIDI Panels Should Use Matching Paint And Resized Reservations

• Connection: whenever a SpaceAge panel draws explanatory strips and separately positions controls, the paint and resized paths must reserve the same vertical space. If they drift, text can look fine in one pass while controls overlap in another.
• Reuse path: future synth/effects skinning should avoid duplicating magic heights across paint/resized. A small local layout helper or card model would reduce this risk across Redshift, EchoRay, Hardware Passports, and future Instrument Bay panels.
• Product implication: dense MIDI workflows become less intimidating when the UI breathes. Shorter evidence language plus aligned control reservations makes the page feel deliberate instead of like a debug dashboard trying to become a product page.

2026-07-22 - MIDI Launch Proof Needs As Plain Tester Language

• Connection: the MIDI Health cockpit should behave like a preflight panel, not an engineer-only report. The new LAUNCH NEEDS line translates backend proof flags into human test requirements: cold tester proof, hardware/device, real-file/project, or live-performance feel/timing.
• Reuse path: this same pattern can guide future release gates for audio export, VST hosting, SoundFont relocation, and hardware editors. Instead of dumping long checklists into the UI, each cockpit card can expose nextThing, whyItMatters, and whatKindOfProof fields.
• Product implication: this makes SpaceAge feel more trustworthy because the app tells the tester or user what evidence is missing before we make public claims. That is boring in the best possible way: it prevents marketing language from outrunning reality.

2026-07-20 - Timing Proof As Player Trust

The useful split is backend timing truth versus human feel. Automated record-timing gates can prove note placement, source ownership, and direct timestamp handling, but they cannot prove a controller/interface/audio-driver chain feels good. SpaceAge should surface both truths: "the engine placed the note correctly" and "your rig still needs a live-feel receipt."

2026-07-20 - Health Cockpit As A Proof Compass

The Health cockpit should behave like a compass, not a filing cabinet. Prioritizing launch proof before generic hardware proof makes the next step feel coherent: first prove SpaceAge's launch claims, then chase deeper hardware polish. This pattern can later guide render/export, automation, and device-editor release gates.

2026-07-20 - One Truth Surface For MIDI Claims

A separate Health-level public-claim summary prevents drift between the cockpit, JSON payload, and plain-text reports. This same pattern should be reused for future launch-sensitive features: protocol copy can describe capability, while project health copy describes what is actually proven in the current project/session.

2026-07-20 - Truthful Marketing Starts In The Health Model

The public-claim gate is now shaped like a trust instrument: backend capability, hardware readiness, and launch proof are separate states. That distinction can become a product virtue because SpaceAge can say exactly what is proven, what is beta/internal, and what still needs real-world proof without marketing blur.

2026-07-20 - Launch Proof As A Trust Surface

The launch-validation verdict is becoming more than a backend flag: it can serve as a future customer-facing confidence surface. Once every proof bucket has saved PASS evidence, SpaceAge can expose MIDI readiness with calm certainty; until then, the UI should speak in precise blocked-next-step language rather than aspirational claims.

2026-07-20 - MIDI Health Verdict Regression Coverage

• Since JUCE paint output is not easily unit-tested here, the practical contract is to test the data/report source that the cockpit row draws. This keeps the UI truthful without brittle screenshot tests.
• Future UI cockpit rows should follow the same pattern: one canonical report string, serialized for tests, then rendered visually.

2026-07-20 - MIDI Health Launch Verdict Row

• The launch verdict row turns the MIDI proof system into a usable cockpit rather than a hidden report. The user should see the launch truth at a glance: pass, blocked, what kind of proof remains, and why public claims are constrained.
• The receiptSatisfied fix is a reminder for future UI work: whenever the backend has a canonical state field, visible counters should use that exact field instead of a parallel or assumed name.

2026-07-20 - MIDI Launch Validation Verdict

• A short launch verdict is useful product design: it gives the user and us one emotionally clear answer, while the deeper proof matrix remains available for inspection.
• This pattern should guide future high-stakes systems in SpaceAge: show a compact truth label first, then let the user drill into the evidence and next action.

2026-07-20 - Launch Proof Report Summaries

• Plain-text MIDI proof reports can now become launch-readiness checklists without a fragile second translation layer: the primary proof bucket and requirement counts already read like cockpit data.
• This creates a reusable pattern for future setup assistants: every action should say what it needs, whether it touches hardware, and what proof artifact will satisfy it.

2026-07-20 - Launch Proof Actions Carry Proof Context

• Treating launch proof requirements as first-class action data opens a cleaner cockpit design: badge chips such as Hardware, Real Files, and Live Performance can sit on action cards without fragile text parsing.
• This same pattern can later support customer-facing MIDI setup tasks, where each action clearly says whether it is safe to do offline or requires connected gear.

2026-07-20 - Wording Should Reveal The Kind Of Proof

A button that says QA receipt is technically correct, but a button that says launch proof tells the user what phase of trust they are in. SpaceAge should keep using specific labels when the same underlying mechanism serves different emotional jobs: QA for internal discipline, launch proof for public confidence.

2026-07-20 - Proof Work Should Name Its Environment

A remaining count is useful, but a remaining count that says hardware, real files, and live performance is more humane. MIDI launch validation now shows the kind of proof still needed directly in Health. That pattern should be reused for rendering, presets, exports, and hardware editors: do not just say work remains; say what world the user has to be in to finish it.

2026-07-20 - Proof Fields Should Follow The Feature, Not The Old Session Name

Automation had structured proof, but the launch-validation doorway initially only inherited the generic QA form. That is the kind of quiet mismatch that creates fake confidence. The better rule: if a feature needs special proof once, every receipt surface for that feature should discover it by capability/key, not by one historical session name.

2026-07-20 - The Cockpit Should Teach The Door

A feature is not really discoverable until its status surface shows both existence and first motion. Adding AUTO DOOR COUNT and AUTO FIRST to MIDI Health turns Automation from hidden depth into a visible path: here are the doors, here is the first one to use, and none of that requires the user to parse a technical report.

2026-07-20 - Rows Need A Human Sentence

Structured rows are excellent for code, but a user-facing cockpit also needs a sentence. Automation now has both: the exact doorway rows for UI cards and a compact summary/action line for tired human eyes. This should become a design rule for SpaceAge status systems: every table-like model gets a calm summary sentence and one obvious next action.

2026-07-20 - Doorways Should Be Data, Not Just Copy

If a feature has multiple entry points, those entry points should become structured rows. Automation now knows its own doors: Piano Roll, Arrangement, MIDI TASKS, Settings, MIDI Health, and MIDI PATCH Review. This lets future UI render confident action cards and prevents prose from becoming the only map to a powerful feature.

2026-07-20 - One Proof Model, Many Surfaces

Protocol Coverage and MIDI Health should not become rival narrators. The same launch-validation queue now appears in both places: without receipts it describes the whole road, and with receipts it describes what remains. This is the pattern to preserve for future QA cockpit work: one source model, many surfaces, no interpretive drift.

2026-07-20 - Queues Should Become Action Surfaces

A remaining-proof queue is helpful; a remaining-proof queue that already knows which safe action button it wants is better. MIDI launch validation can now move toward a cockpit where the user sees a stack of proof tasks and each one carries the same receipt contract. This pattern should generalize to release QA, render checks, hardware setup, and file round trips.

2026-07-20 - Count The Kind Of Proof, Not Just The Amount

A queue length tells us how far we have to go, but proof-type counts tell us what kind of day we need: hardware on the desk, real files from outside DAWs, or live playing with human hands. This should become a general SpaceAge pattern: progress is more useful when it names the next environment required, not merely the next checklist item.

2026-07-20 - A Proof Queue Beats A Single Next Step

A single next action is useful, but a visible queue is calming. For MIDI closeout, the user should be able to see the road: Automation, controller latency, external expression, SysEx, file round trips, live timing, project round trips, public wording. The receipt-aware queue can become the model for other serious finish lines, including render validation, SoundFont relocation, instrument audit, and release-candidate testing.

2026-07-20 - Deep Reports Must Not Be Dumber Than Copy Steps

The full Health report is where a careful user or support person goes for truth, so it cannot be less receipt-aware than the short copied checklist. Keeping launch-validation progress beside public-claim wording makes the report feel like a cockpit rather than an archive: here is what SpaceAge can safely say, here is how much proof exists, and here is the next proof object.

2026-07-20 - Progress Belongs In The Copyable Report

If a progress count only exists in structured data, it is useful to code but not yet useful to a tired human. Putting launch-validation receipt progress into COPY STEPS lets the user, support, and future QA cockpit share the same sentence: how much is done, and what comes next. This is the rhythm SpaceAge should use for all serious proof surfaces.

2026-07-20 - Proof Should Move The Cursor

A receipt system that accepts proof but keeps pointing at the same first task feels broken, even if the stored data is technically correct. Launch validation now behaves like a musical playhead: once a bucket has saved PASS evidence, the cursor advances to the next thing that needs attention. That pattern should guide future QA surfaces, render checks, SoundFont relocation, hardware setup, and release-readiness dashboards. The count matters too: a cockpit should be able to say 1/9 receipts are done without asking anyone to inspect nine rows by hand.

2026-07-20 - Health Should Carry The Same Checklist As Coverage

Once a checklist exists, every status surface should quote the same source instead of inventing a shorter local version. MIDI Health now carries the Remaining MIDI 1.0 perfection checklist in COPY STEPS and in its serialized payload, so the Health page, Protocol Coverage, and future QA cockpit can all point to the same finish-line evidence buckets.

2026-07-20 - A Checklist Is Better Than A Percentage Alone

The MIDI finish line needs rows a tester can execute, not only a progress sentence. A structured Remaining MIDI 1.0 perfection checklist now names the evidence buckets that still matter: Automation hands-on QA, real-controller latency, external-synth response, RPN/NRPN setup, SysEx restore proof, DAW file round trips, live timing, project reopen/export, and public wording. This can feed Settings, reports, or a future QA cockpit without making the UI parse prose.

2026-07-20 - File Round Trips Need A Passport Too

A MIDI file handoff is a kind of hardware path, except the device is another DAW or collaborator workflow. SpaceAge needs to prove what survived the trip: tempo, meter, key, notes, lengths, velocities, expression, setup rows, SysEx quarantine, and re-import comparison. This keeps import/export from becoming a comforting button that only proves SpaceAge can write bytes to disk.

2026-07-20 - Hardware Proof Needs Acceptance Criteria

A hardware PASS receipt should not be a vibe check. It needs to say which device and connection path were tested, which ports and lane/channel were intended, what latency context existed, whether notes/controllers/bend/pressure responded musically, whether SysEx/setup behavior was actually verified, and whether interchange claims had a real file/DAW round trip. This turns hardware validation into a repeatable product ritual rather than a hopeful studio anecdote.

2026-07-20 - Live Recording Needs A Ritual, Not A Guess

Arrangement recording is a high-trust workflow because it is where a musician expects performance intention to become durable music. The app needs to prove not just that MIDI events were observed, but that the armed lane owned input, timing and note lengths landed where the player meant, expression was captured as editable performance data, clip selection did not hijack the take, and setup messages stayed out of ordinary automation. This checklist can become the user-facing recording receipt later.

2026-07-20 - Future Protocol As A Promise Boundary

True MPE and MIDI 2.0 are valuable future destinations, but they are also promises with sharp edges. The current app can preserve MPE-like MIDI 1.0 expression, but it should not let that sound like zone ownership, member-channel allocation, UMP transport, profile exchange, or property exchange. Keeping this boundary inside the same QA ritual system as hardware and SysEx lets SpaceAge stay ambitious without becoming slippery.

2026-07-20 - MIDI Learn As Physical Trust

MIDI Learn is where SpaceAge connects a hand movement to a musical result, so the evidence needs to include both the mapping and the feel. Source, target, channel/device scope, pickup, range, curve, conflict choice, delete/undo, and in-context response should stay visible. That pattern can later extend to hardware setup wizards, performance templates, and AI-assisted controller profiles without hiding dangerous assumptions.

2026-07-20 - Hardware Setup As A Guarded Conversation

Hardware setup should feel like SpaceAge is helping the user shake hands with an external instrument, not silently throwing commands across a cable. The Hardware Setup Wizard can guide roles, channels, devices, and test notes, while MIDI PATCH keeps dangerous setup commands explicit. Keeping protected reset/channel-mode rows separate preserves confidence for Yamaha/Roland-style editors later.

2026-07-20 - Import And Export As Honesty Boundaries

MIDI import and export are trust events, not just file dialogs. Import should teach that source material is being reviewed and deliberately adopted, especially when tempo/meter/key maps could reshape a song. Export should teach that SpaceAge wrote a package, but real collaborator trust comes from receipts, checksums, and re-import/open validation. This same honesty pattern can later guide sample packages, Quasar exports, and project handoff bundles.

2026-07-20 - SysEx Vault As A Hardware Trust Ritual

SysEx recall is strongest when SpaceAge treats stored bytes as memory and verified response as trust. The Vault should feel like a library, but restoring a dump to external hardware should feel like a guarded ritual: identity, byte count, checksum, response/manual verification, and receipt. That same pattern can later power Yamaha XG editors, hardware templates, and per-device setup assistants without pretending that queued bytes equal accepted bytes.

2026-07-20 - Hardware Bend Ritual As A Trust Object

Hardware pitch bend is not just a MIDI event; it is a promise about what an external instrument will physically do. By treating the Hardware Passport plus TEST BEND flow as a first-class QA ritual, SpaceAge can keep expressive slides powerful without pretending that raw 14-bit bend data automatically means the same semitone range on every synth. This can connect later to hardware setup wizards, lane badges, export receipts, and a friendly "prove this device" workflow.

Creative Thinking - Visible First Fix (2026-07-19)

If reports say �first issue,� the live UI should say it too. LIVE FIRST closes that gap and makes MIDI Health feel less like a log and more like a cockpit: status, why, first fix, then row details. This ordering is a useful template for other high-friction systems in SpaceAge: show the state, explain the state, give the first fix, then expose the evidence.

Creative Thinking - First Issue Beats Full Scan (2026-07-19)

When a user is already frustrated by MIDI lag, asking them to scan a long diagnostic list is hostile. The first-attention summary turns a structured checklist into a first move: �Audio buffer, lower this first.� That pattern can apply broadly: project load can surface the first missing asset, render can surface the first blocker, hardware setup can surface the first unverified Passport item, and automation can surface the first lane that lacks proof.

Creative Thinking - Short Reports Need the Same Truth (2026-07-19)

A shortened report should not become a weaker report. Adding the live MIDI cockpit line to COPY STEPS means the musician-facing checklist and the full health report tell the same truth: current live status, how many checks exist, how many need attention, and what to do first. This keeps SpaceAge from becoming one of those apps where the �friendly� screen hides the important diagnostic fact in some deeper technical page.

Creative Thinking - Copyable Cockpit Lines (2026-07-19)

The app should increasingly produce small, exact, copyable diagnostic lines that are useful to both the user and support. A one-line Live MIDI: ATTENTION | 4 checks / 1 attention | lower the buffer... message is more humane than making someone screenshot an entire settings page. This same pattern can later serve Render, Hardware Passport, SoundFont relocation, external device setup, and crash recovery: concise headline first, detailed evidence below.

Creative Thinking - Status Plus Why (2026-07-19)

A status badge by itself is only half humane. ATTENTION tells the user something is wrong, but LIVE WHY turns the warning into a next move. This should become a general SpaceAge interaction pattern: every critical status should have an immediately adjacent reason/action line, especially for areas that can feel mystical to users: MIDI latency, hardware routing, render/export state, missing SoundFonts, audio-device setup, and automation ownership.

Creative Thinking - One-Word Health Signals (2026-07-19)

The MIDI Health cockpit is becoming more useful as it separates prose from machine-readable state. LIVE STATUS is deliberately blunt: OK, ATTENTION, UNKNOWN. That kind of one-word signal can become a visual badge, a support-report headline, or a future Settings notification without making the user decode paragraphs. The same design pattern should eventually apply to Render, Audio Device, Automation, External Hardware, and Project Load health: one clean status word, then expandable evidence for people who want the deeper truth.

Creative Thinking - Counts Are Cockpit Instruments (2026-07-19)

Structured MIDI diagnostic rows are helpful for humans, but structured counts are better cockpit instruments. A future MIDI Health panel can show �1 thing needs attention� without parsing a paragraph, and a support bundle can quickly summarize whether the likely live-performance bottleneck is audio buffer, direct input routing, hardware output, sample-position proof, or SoundFont prepared-pool pressure. This same pattern should be reused for automation health, render health, and project-load health: plain language for Shane, structured counts for the app.

2026-07-19 08:09 - Creative Thinking: performance trust needs visible evidence

• Live-play confidence is not only latency optimization; it is also helping the musician know where delay is coming from. A compact LIVE DIAG line can become part of a larger performance cockpit that makes controller troubleshooting feel guided rather than mysterious.

2026-07-19 08:00 - Creative Thinking: cold actions should be visibly harmless

• COPY QA and COPY CLOSEOUT now model the idea that diagnostic/report buttons should be obviously safe. This can later inform a small UI language for cold actions versus warm routing actions versus hot hardware-send actions.

2026-07-19 07:52 - Creative Thinking: copy actions as trust surfaces

• A copy/report button is still part of the instrument-like workflow: it should tell the user exactly what it does and, more importantly, what it cannot do. The shared COPY CLOSEOUT safety summary can become a reusable pattern for future cold actions such as export reports, diagnostic copies, and hardware passport summaries.

2026-07-19 - Reports Should Teach the UI What to Say

The MIDI closeout UI now shows the same compact row summary produced by the protocol model. This keeps interface wording, copied reports, and future automation/testing dashboards pointed at one source of truth instead of letting each surface invent its own wording.

2026-07-19 - One-Line Summaries Are UI Contracts

A structured array is best for detailed tables, but a model-owned one-line summary is still useful for compact cards. The MIDI closeout row summary now acts as the bridge between deep protocol data and glanceable interface copy.

2026-07-19 - Closeout Lists Should Be Data, Not Just Prose

Turning the MIDI closeout checklist into structured rows keeps the human-readable report intact while making future UI surfaces safer: a checklist view can filter by safety class, owner surface, or direct-openability without brittle string parsing.

2026-07-19 - Owner Surfaces Are Where Users Act

Grouping MIDI closeout by owner surface is more than reporting. It can become a UI navigation model: each row can open the relevant surface, show whether it is safe-door openable, and explain what proof is needed. This same idea can later help synth QA, render QA, and hardware setup workflows feel like guided missions instead of diagnostics dumps.

2026-07-19 - Marketing Claims Need Machine-Readable Brakes

A music app can hurt trust by claiming too much too early. Structured release wording rows let SpaceAge build a future launch cockpit that says, in plain language, which claims are safe and which need receipts. This bridges engineering truth and marketing confidence without making either side guess.

2026-07-19 - Run Order Cards Can Become Guided QA

Once run-order rows are structured, they can become more than documentation. The same data can power clickable QA cards, proof-capture prompts, disabled/enabled states, and a visible path from blocker to receipt. This pattern can later help Render, Hardware Assistant, and Arrangement diagnostics feel like guided workflows instead of walls of text.

2026-07-19 - Navigation Cards Should Declare What They Do Not Do

A next-action card is calmer when it says what it cannot accidentally do. Declaring sendsMidi=no and projectMutation=no turns a potentially scary MIDI closeout button into a trustworthy navigation object. This same pattern can later help Automation, Hardware Assistant, Render, and Project Recovery surfaces distinguish between view-only, project-changing, and hardware-affecting actions.

2026-07-19 - Copy Actions as Trust Signals

Treating clipboard actions as structured surfaces is small but useful product design: a user can learn that some actions are cold/report-only while others are warm/project-mutating or hot/hardware-affecting. That same visual grammar can later drive button colors, confirmation levels, and tooltips across SpaceAge.

2026-07-19 - Cockpit Action Summary Reuse

The cockpit summary pattern can become a standard SpaceAge UX primitive: one action surface, one compact summary, and one serialized object. That could make future panels feel calmer because every complex subsystem can say, plainly, what the next action is and whether it is safe, review-only, or hardware-affecting.

2026-07-19 - Structured MIDI Cockpit Actions

A structured cockpit action surface can later feed richer UI affordances: color-coded MIDI mission buttons, disabled/safe action states, and context-aware help text. The same shape can be reused for Arrangement, Automation, and Hardware Assistant panels where a single clear next action should be obvious to the user.

2026-07-19 - Reports Should Not Reinterpret Actions

A report should quote the action model, not re-derive the action state. When a cockpit summary invents its own enabled rule, it can accidentally contradict the button it is describing. Canonical action text keeps trust intact.

2026-07-19 - A Button Can Be Enabled Without Being Save-Ready

The receipt flow has multiple valid actions: complete, save, and review. Treating save-readiness as general enabled-state confuses the user. The better rule is to ask the active action what it can do, then render that honestly.

2026-07-19 - Symmetry Lowers Cognitive Load

When two UI regions answer the same question, they should expose the same shape. Matching action-surface payloads for current and next MIDI receipt work means fewer special cases, clearer tests, and a calmer interface later.

2026-07-19 - Make Safety Visible Before Action

Receipt actions are not just commands; they are trust surfaces. Keeping button labels, mutation flags, and MIDI-send flags structured lets SpaceAge show why an action is safe before a user clicks it.

2026-07-19 - Run Orders Want Rows

If a process has an order, each ordered step should be addressable. Row-backed QA run orders can later become checkable cockpit items, evidence prompts, and receipt attachment targets without rebuilding the underlying logic.

2026-07-19 - Proof Steps Should Be Clickable Rows

Closeout proof is easier to trust when each required test is its own row. The same model can later power checkboxes, receipt capture, screenshots/log attachment prompts, and a "what remains before public claim" cockpit without having to reinterpret paragraphs.

2026-07-19 - Action Cards Beat Status Paragraphs

Any workflow button that is supposed to guide the user should have a structured action-card payload behind it. Reports can stay warm and human, but the app should render next actions from fields: what this is, where it opens, why it matters, how risky it is, and what proof is still missing.

2026-07-19 - Checklists Should Be Data, Not Text Surgery

Whenever SpaceAge has a checklist that might become UI, expose it as rows and then build string reports from those rows. The inverse leads to brittle parsing and weird formatting edge cases, especially in health/status panels that need to be readable and machine-safe.

2026-07-19 - One Front Door Beats Clever Plumbing

The MIDI Health payload should act like the clean public lobby for MIDI status, even if Protocol Coverage remains the deeper machine room. Mirroring release wording into Health keeps future UI implementation simple and reduces the chance that a panel accidentally omits the claim boundary.

2026-07-19 - Every Diagnostic Surface Should Tell the Same Truth

If a user, tester, or future support person copies a full Health report instead of a compact next-steps report, the same public-claim boundary needs to travel with it. This is a good pattern for all proof-driven systems: summary badge, helper sentence, JSON field, short report, and full report should agree.

2026-07-19 - Diagnostic Text Can Double As Product Discipline

The MIDI Health text report is becoming more than a developer dump. By putting public-claim boundaries into the same report that lists proof work, SpaceAge can later give support, QA, beta testers, and marketing the same source of truth instead of letting each person invent their own interpretation.

2026-07-18 - Status Badges Need a Human Sentence

A badge like HARDWARE PROOF PENDING is useful for scanning, but the product feels more trustworthy when the app immediately explains why. Pairing compact labels with helper text should become a pattern for future proof-heavy areas: MIDI, hardware restore, rendering, sample relinking, and public release readiness.

2026-07-18 - Marketing Claims Should Be Computed From Evidence

The same MIDI evidence model that protects hardware setup can also protect SpaceAge's commercial voice. If release wording is derived from proof state, the app helps prevent accidental overpromising while still giving us confident, evidence-backed language when a feature truly clears the ladder.

2026-07-18 - Hardware Proof Is A Promise Ledger

The hardware proof percent can become a user-facing trust meter, but it must never imply that SpaceAge has verified a device merely because the route exists. Treat it like a promise ledger: Passport, timing, test phrase, device response, file round-trip, and saved receipt each earn proof only when evidence is captured.

2026-07-18 - MIDI Closeout Card As A Navigation Object

The new MIDI next-action card is more than a status string: it can become the visible bridge between diagnostics and action. The same card can power a Settings cockpit row, a safe-door button, a QA checklist entry, and later an in-app assistant explanation without each UI surface inventing its own interpretation of �what should I do next?�

Creative Thinking - A Dropped Take Should Confess Immediately

Task: Protect MIDI Health warnings for dropped recording events.

Connection: Recording trust is emotional as much as technical. If SpaceAge silently loses a note, bend, pedal, or controller gesture, the user stops believing the whole instrument. The same Health surface that talks about latency and controller focus should also confess dropped capture data immediately.

Creative extension: This can become a future take-quality badge on recorded clips: clean, compensated, warning, or untrusted. That would connect MIDI Health, Arrangement clips, Automation, and recording workflow into one visible confidence language.

Creative Thinking - Multiple Controllers Are A Feature Until They Are A Mystery

Task: Add MIDI Health coverage for multiple direct physical inputs.

Connection: A musician may intentionally use two controllers at once, but the app must not pretend that "two things are plugged in" is the same as "two things are actively performing." This connects MIDI Health, lane arming, Hardware Passport, recording trust, and future setup wizards into one product habit: distinguish availability from musical evidence.

Creative extension: Later, SpaceAge can turn this into a friendly Controller Focus mode: "I hear the keyboard and the wind controller. Which one should this lane listen to?" That would make complex rigs feel guided rather than fragile.

Creative Thinking - Hardware Proof As A Ritual

Task: Protect the Hardware Passport / MIDI Health proof workflow with focused regression coverage.

Connection: MIDI hardware trust is not a single feature. It is a ritual: Passport, timing, TEST BEND, SysEx verification, DAW/host round trip, and saved PASS/FAIL/BLOCKED evidence. Treating that sequence as a first-class checklist connects the backend, Settings, MIDI Health, future hardware editors, and support reports into one repeatable path.

Creative extension: The same proof ritual can later power a friendly setup wizard: SpaceAge asks the user to plug in a device, play a note, run a bend test, send/receive a safe SysEx probe, then prints a small "hardware passport stamped" receipt. This would make old synths and MIDI modules feel less scary.

2026-07-16 - Creative Connection: Tests Should Pin Contracts, Not Poetry

Task: De-brittle the MIDI project-readiness health gate.

What connects creatively: Reports are part of SpaceAge's voice. They should be free to become clearer without making the test suite collapse every time a sentence improves. The right test target is the contract underneath the language: what state exists, what route is open, what warning is active, what evidence is saved, and what remains unproven. That distinction will matter everywhere we have dashboards: MIDI, VST hosting, render/export, SoundFonts, Quasar packages, and future hardware editors.

Guardrail: Keep prose readable and honest, but test the durable facts. If a sentence changes while the truth stays the same, the build should not become a hostage.

2026-07-16 - Three Progress Numbers Are Better Than One

For complex systems like MIDI, one percentage creates emotional noise. A better product habit is to separate software exists, user can operate it, and the outside world proved it. The same structure should guide future readiness dashboards for VST hosting, Quasar packages, SoundFonts, hardware editors, and render/export: do not let internal capability pretend to be external proof.

2026-07-16 - Automation as One Door, Many Owners

A stable Automation button is better product language than state-changing labels. It lets the user learn one gesture while the app handles the technical ownership model underneath. This same pattern should guide future complex features: one memorable doorway, then context-aware scope inside the opened tool.

2026-07-16 - Creative Connection: Trust Has Layers

Task: Add an evidence-boundary summary to MIDI export job plans.

What connects creatively: Export confidence is layered like a mix: readiness is one fader, file-writing is another, and external verification is the master bus. If SpaceAge collapses those into one vague success state, the user can be surprised later when another DAW, collaborator, or hardware workflow exposes a mismatch. Naming the layers makes the product feel calmer and more professional.

Guardrail: Never let a successful plan or file write claim interoperability proof. The user-facing receipt should say what was prepared, what was written, and what still needs to be opened or re-imported.

2026-07-16 - Creative Connection: Export Proof Should Be A Checklist, Not A Vibe

Task: Add a MIDI export validation checklist to export readiness summaries.

What connects creatively: Export is the handshake between SpaceAge and the outside music world. A musician should not have to guess whether an exported file is good enough for a collaborator, hardware rig, or another DAW. Turning export readiness into a concrete checklist makes the handoff feel professional and repeatable, and the same idea can later guide audio stems, Quasar packages, SoundFont relocation, and hardware SysEx restore proof.

Guardrail: Do not call export launch-complete from internal serialization alone. Real-file import/open proof remains a separate human or automated fixture step.

2026-07-16 - Creative Connection: Evidence Is A Musical Object Too

Task: Make the MIDI Health QA receipt button say COMPLETE QA until evidence is actually save-ready.

What connects creatively: SpaceAge is not only recording notes; it is recording confidence. If a proof button says SAVE before the proof exists, the interface teaches a bad habit. Treating evidence like a real object with a state makes the whole app feel more trustworthy.

Guardrail: Never let a label imply proof before proof exists. COMPLETE, SAVE, and REVIEW are different states and should stay visually distinct.

2026-07-16 - Creative Connection: Separate Readiness From Capability

Task: Add a visible MIDI Health AUTO TOOLS row separate from AUTO OPS.

What connects creatively: A musician asks two different questions: "Can I trust this yet?" and "What can I do with it?" When those answers share one line, the interface sounds evasive. Separating readiness from capability gives the app a clearer conscience and gives the user a clearer next move.

Guardrail: Dashboards should not hide capability behind readiness warnings. Show the tool surface, then show what proof remains.

2026-07-16 - Creative Connection: Doorways Should Be Named Like The Door

Task: Align Automation wording with the actual Arrangement CLIP AUTO / LANE AUTO controls.

What connects creatively: SpaceAge is becoming powerful enough that vocabulary is now part of the instrument. If the button says one thing and the report says another, the user starts feeling like the app has secret rooms. Matching the wording to the visible doorway keeps advanced MIDI automation discoverable and lowers the cost of trust.

Guardrail: Do not invent new control names in docs or health reports unless the GUI actually exposes them. The user should be able to follow every instruction with their eyes.

2026-07-16 - Creative Connection: Automation Belongs In The Printed Score Too

Task: Move Arrangement expression playback onto snapshots for Shared PTN, Lane Local, and Clip Local owners.

What connects creatively: Notes, chords, and controller motion are all part of the same performance. If SpaceAge prints only the notes into its playback score but leaves the filter sweeps and hardware gestures on loose paper, the performance engine still has to pause and ask the editor what is true. Pulling expression payloads into the same immutable score makes future Motion Clips, scene variants, and hardware editor automation easier to reason about.

Guardrail: Keep ownership precedence unchanged: Shared PTN first, Lane Local second, Clip Local third. Snapshotting is a transport mechanism, not permission to change musical meaning.

2026-07-16 - Creative Connection: Arrangement Playback Needs A Printed Score

Task: Move Arrangement note/chord playback onto sequencer and pattern snapshots.

What connects creatively: The Arrangement Canvas is the score SpaceAge performs from. During playback, the audio engine should not be rifling through the composer's desk for live papers; it should read a prepared, printed score for the current state. That metaphor scales beautifully: future Motion Clips, scenes, hardware routing, and automation passes should publish prepared performance views while editing remains free to mutate the working copy.

Guardrail: Expression payload playback is the next score-printing target. Do not call the realtime cleanup complete until Shared PTN, Lane Local, and Clip Local expression data have the same prepared-state boundary.

2026-07-16 - Creative Connection: Snapshots Are Stage Cues

Task: Move isolated sequencer playback toward immutable pattern snapshots instead of live pattern locks.

What connects creatively: A snapshot is like giving the audio engine a clean stage cue: here is the exact pattern, chord, note, and controller reality for this moment, already copied and ready. That same idea can serve Arrangement playback, Motion Clips, scene/orchestration variants, and future hardware editor states. The user should feel fluid performance while the app quietly swaps prepared cue cards behind the curtain.

Guardrail: Do not call audio-thread work complete until Arrangement playback has the same prepared-state boundary. Partial snapshotting is useful progress, but not a license to ignore remaining live locks.

2026-07-16 - Creative Connection: Timing Proof Is Part Of The Instrument

Task: Verify sequencer-generated MIDI expression keeps exact sample timing and correct stale release-checklist entries.

What connects creatively: Expression data is part of the performance, not admin metadata. A filter sweep, pedal change, or pitch gesture that arrives late by a step can feel as wrong as a late note. The same standard should guide automation lanes, Motion Clips, Flux Nodes, and future hardware editors: if the user placed a change at a musical instant, SpaceAge should preserve that instant all the way through playback, export, and hardware routing.

Guardrail: Do not let checklist wording drift away from tested reality. Stale open items waste attention and make the project look less solid than it is.

2026-07-16 - Creative Connection: Mode Switches Must Be Musical Hand-Offs

Task: Preserve held MIDI recording notes when the user switches into Step Input.

What connects creatively: SpaceAge has several composition modes, but the user's hand does not care about our internal mode boundaries. If a key is held while the app changes from live recording to Step Input, that should feel like a hand-off between tools, not a trapdoor under the performance. This same rule should apply anywhere we cross modes: live recording into editing, chord audition into commit, automation draw into transform, and hardware capture into review.

Guardrail: Before any input mode clears transient state, close or commit meaningful musical gestures at the current transport position. Do not let mode changes silently erase played material.

2026-07-16 - Creative Connection: Record Off Should Mean Commit, Not Forget

Task: Make MIDI recording disarm close held notes instead of clearing them from transient state.

What connects creatively: A musician hitting record off is usually saying "capture what just happened," not "erase the note I am still holding." Treating disarm as a commit point makes SpaceAge feel more like an attentive recorder and less like a brittle data machine. This same idea belongs in future audio recording, automation passes, Flux Nodes capture, and hardware SysEx sessions: stopping the capture should preserve a coherent ending whenever the user has already given the app meaningful material.

Guardrail: Do not solve this by inventing synthetic note lengths detached from transport position. Close held notes at the current compensated recording step, then clear live state.

2026-07-16 - Creative Connection: Boundaries Should Preserve The Gesture

Task: Fix MIDI recording at the pattern edge so a note held across the loop boundary keeps its musical intent.

What connects creatively: A loop boundary is a visual/editor boundary, not a reason to destroy the player's gesture. Splitting a wrapped note into two legal notes gives the Piano Roll something honest to display and edit while preserving the feel of what was performed. This same rule should guide future automation curves, clip slicing, Motion Clips, and Quasar sampling zones: when data crosses a container boundary, preserve the gesture by representing it in the smallest honest pieces.

Guardrail: Do not solve loop-edge data by silently extending the pattern, moving the note, or hiding continuation state. Use visible, editable events that survive export and make sense to a musician.

2026-07-15 - Development Time Is A Product Resource

Task: Measure how much time SpaceAge's changing development process has saved, using repository and workflow evidence rather than an invented success number.

What connects creatively: Fewer beta handoffs preserve Shane's compositional concentration; focused gates preserve engineering concentration; model-owned reports preserve semantic concentration. All three are versions of the same product principle: protect the human from unnecessary context switching. A microDAW built around musical flow should be developed with a workflow that respects flow, too.

Architecture choice: Treat 40-75 net person-hours, midpoint roughly 55, as a planning estimate rather than accounting fact. Keep hard observations separate from modeled ranges, subtract setup cost, discount overlapping benefits, and refuse to count unfinished architecture as realized savings.

Future extensions: CI can capture actual build and gate durations, beta packages can carry a lightweight test-session timer, and a test-selection manifest can connect changed modules to required focused gates. Those additions would turn the next report from a modeled estimate into a mostly measured one.

Subagents: Rawls audited documented process changes, runtimes, and double-counting risks. Zeno audited Git activity, line churn, script history, focused-gate artifacts, and dirty-worktree limits. Both were read-only; their findings were reconciled locally.

2026-07-15 - One Ownership Model, One Vocabulary

Task: Remove the last contradiction between the implemented three-owner Automation architecture and customer-facing/report copy that still described Clip Local and Lane Local as future work.

What connects creatively: Ownership is not merely a storage detail. The owner selector, Source View, lane/clip context, copied report, Protocol Coverage dashboard, QA receipt, playback layering, and export layering are all different windows onto one musical promise. If any one of them uses older language, a correct backend can still feel unreliable.

Architecture choice: Derive every active description from the same vocabulary: Shared PTN follows linked clips until VARIANT; Clip Local isolates one clip; Lane Local follows the Arrangement lane; effective runtime/export data layers Shared PTN, then Lane, then Clip. Keep Motion Clips and general non-MIDI automation explicitly separate as future architecture.

Future extension: Treat this as a reusable product rule. Whenever SpaceAge adds an owner-scoped feature such as clip decorations, effect automation, articulation maps, or scenes, the editor, inspector, reports, QA receipts, serialization, playback, and export should all consume one ownership identity rather than carrying parallel prose.

2026-07-15 - Creative Connection: A PASS Must Prove The Whole Promise

Task: Harden Automation closeout evidence after adversarial review.

Creative connection: The editor already offers three useful ownership promises: Shared PTN, Clip Local, and Lane Local. Release evidence should mirror that musical grammar. A launch-closing PASS therefore proves every required doorway and all three owners against one exact Pattern/Clip/Lane context. Individual-owner evidence is still useful for diagnosis, but it cannot quietly certify the entire feature. This same whole-promise rule can later strengthen render receipts, hardware setup, project repair, and collaborative review.

Guardrail: The Automation session id and persistent state key are a canonical pair. Changing one cannot bypass structured validation. Pattern, Clip, and Lane are stored as integer coordinates rather than prose, and PASS requires all-owner proof plus edit, undo, playback, and export verification.

2026-07-15 - Creative Connection: Evidence Should Be A Playable Checklist

Task: Replace a prose-only Automation PASS receipt with structured proof of the customer workflow.

Creative connection: The same ownership language musicians see while editing now follows the feature into release evidence: doorway, owner, target, edit/undo/playback/export proof, and ownership outcome. This makes QA less like filing paperwork and more like replaying a short musical task. The pattern can later support guided project recovery, render verification, hardware editor receipts, and collaboration handoffs without creating separate evidence systems.

Guardrail: FAIL and BLOCKED may preserve an early-stop observation. PASS is different: it must prove the complete workflow and the ownership result must match Shared PTN, Clip Local, or Lane Local. A detailed paragraph is useful context but cannot substitute for those structured fields.

2026-07-15 - Creative Connection: Hardware Timing Is A Route Identity

Task: Prevent a second controller from impersonating the return pulse used to calibrate MIDI timing.

Creative connection: A timing measurement is trustworthy only when it belongs to the same physical route named by the Hardware Passport. Binding the test to that input gives SpaceAge one reusable identity model for timing calibration, MIDI Health, guided hardware setup, SysEx receipts, and future device editors. The direct-input queue-age timestamp is also preserved, so the measurement describes the cable and device path rather than accidentally adding one audio buffer of application delay.

Guardrail: A matching note and MIDI channel are not enough. Reject returns from every other source, count those rejections for the report, and require a saved real USB or DIN receipt before calling a hardware profile verified.

2026-07-15 - Creative Connection: Trust Is A Named Protocol, Not A Brand

Task: Give Hardware Passports a verified SysEx policy registry without pretending that every message from one manufacturer follows one dialect.

Creative connection: This registry can become the shared foundation for future Yamaha XG/QY editors, Roland hardware panels, patch librarians, and guided hardware setup. Each editor can declare the exact family it speaks, while the Passport remains the human-readable device identity and evidence ledger. That allows SpaceAge to grow device support without turning a logo or manufacturer byte into unsafe authority.

Guardrail: Persist stable IDs and exact message-family scope only. Keep implementation code immutable and compiled. Unknown IDs, missing families, and unevaluated checksums remain manual-review evidence rather than inferred success.

2026-07-15 - Creative Connection: A Reply Must Belong To One Question

A musical tool earns trust when its feedback has provenance. A generic hardware ACK is merely a device saying yes to something; it is not proof that it accepted the patch SpaceAge just sent. The restore path now asks a stronger question: can this response belong to exactly one outgoing SDS packet, from the expected device and packet number? If not, the app stays honest and keeps waiting.

This same design should connect to render completion, Quasar package generation, VST scanning, project loading, AI-assisted patch creation, hardware editor writes, and cloud collaboration. Any asynchronous success badge should identify the initiating action, target, generation, and expected response before it can become a committed receipt. That creates one reusable product language: intent, correlation, then proof.

2026-07-14 - A Parameter Gesture Belongs To Its Performer

Task: Prevent simultaneous MIDI controllers from sharing RPN/NRPN selector state.

Creative connection: Source-owned parameter state is the same foundation needed by Hardware Passports, Yamaha XG/QY editors, controller-specific pitch ranges, and future expressive-performance routing. A controller is not merely "channel 4"; it is a particular performer whose setup gestures, timing calibration, and hardware identity must remain attributable even when another device speaks on the same MIDI channel.

Guardrail: UI summaries may show the last observed value for convenience, but runtime decisions must retain source ownership. Imported evidence must never merge selector halves from different devices, and safety deselection must not erase a value the musician intentionally configured.

2026-07-14 - A Controller Is A Performer With Provenance

Task: Make direct physical MIDI input genuinely source-aware, timing-aware, and safe across disconnect/reconnect.

What connects creatively: Treating a controller as a named performer gives SpaceAge more than a routing fix. The same identity can support controller-specific timing calibration, Hardware Passports, guided setup, preferred expression mappings, and future performance scenes. The open-versus-active distinction can also become a confidence signal: SpaceAge can say not merely that a keyboard exists, but that the intended performer is actually reaching the armed lane.

2026-07-14 - Timing Proof Should Follow The Gesture

Task: Preserve direct callback timing and prove recording placement with deterministic age-offset tests.

What connects creatively: Timing evidence can later power an understandable MIDI Health story: where the gesture entered, how much delay belonged to the hardware/driver path, what SpaceAge compensated, and what remains constrained by the audio block. That same evidence model can serve live audio recording, external hardware returns, and render validation.

2026-07-14 - Creative Connection: Motion Has A Home

Task: Finish explicit MIDI automation ownership without creating three unrelated editors.

Connection: Shared musical ideas, lane-wide performance identity, and one-off clip gestures all need the same drawing tools but different homes. One Automation editor with a visible owner selector lets a composer reuse motion at the PTN level, shape an instrument lane as a whole, or make one clip breathe differently. This architecture can later power Motion Clips and Scenes without hiding where a gesture lives.

Guardrail: Ownership must be visible at entry, edit, copy/paste, report, export, and deletion. Viewport commands must never silently change it.

2026-07-14 00:22 - Creative Connection: Automation Must Live Near Recording

Automation should be visually associated with recording and transport, not hidden as a generic Arrangement action. This makes the workflow teach itself: record or draw performance movement, then immediately inspect or edit that movement in Automation. This same principle should guide future clip/lane-local automation: put the entry point near the action that creates the data.

2026-07-13 - Discovery Is A Button, Not A Side Effect

Task: Stop MIDI readiness/health reports from scanning physical hardware as a side effect.

What connects creatively: A musician asking ?am I ready to record?? should not accidentally trigger the same kind of driver/device discovery that belongs in Settings. This separation connects performance feel, diagnostics, and trust: live paths stay fast, while deliberate hardware setup remains explicit and visible.

Architecture choice: Keep full hardware inventory for user-invoked discovery, but give timing/readiness/health a no-scan inventory built from already-open devices and project references.

Future extensions: Apply this same rule to VST scanning, SoundFont library indexing, sample browsing, Quasar package discovery, and future hardware editors: expensive discovery is a visible action with progress feedback, never a hidden side effect of opening a report.

2026-07-13 16:25 - Dense Diagnostics Need a Cockpit, Not a Wall

• MIDI diagnostics are most useful when they behave like an aircraft cockpit: the surface shows the immediate status and next action, while the black-box detail lives in a report. This same pattern can guide future deep panels such as Instrument Bay diagnostics, Quasar packaging, and hardware editors.

2026-07-13 - Good music tools should teach by wording: REC text should name the physical gesture the user made, lane plus playhead, rather than exposing old implementation ideas like selected patterns.

2026-07-13 - Recording should obey the user's visible intention: the playhead is the musical insertion cursor, while selection is only context when no playhead target has been chosen.

2026-07-13 - Record Into The Shape The User Chose

Task: Align fresh Arrangement REC clips with the visible LENGTH target.

What connects creatively: Recording is not just data capture; it is the app respecting a prepared musical container. If the user sets up a longer phrase space, the recording system should not secretly shrink it to a starter clip. This connects Arrangement inspector state, record targeting, Piano Roll phrase display, and trust in live performance capture.

Architecture choice: Fresh clips created by Arrangement REC now materialize the selected pattern and clip to the visible LENGTH value. Normal fresh-lane creation still keeps its intentional 16-step starter clip behavior.

Future extensions: Use this same rule for automation record ranges, punch-in ranges, loop-take capture, and future hardware recording: the visible musical range should be the backend target unless the user explicitly changes it.

2026-07-13 - A Recording Should Draw The Shape You Played

Task: Add regression coverage for four-measure Arrangement MIDI recording.

What connects creatively: A musician judges recording trust visually before they judge it technically. If they play a four-measure phrase, the Piano Roll and clip preview must show musical events across four measures, not a nervous cluster at the front. This connects MIDI timing, Arrangement ownership, clip previews, and user confidence into one promise: SpaceAge records the shape you performed.

Architecture choice: The focused MIDI timing harness now records four notes through an armed Arrangement lane into a 64-step clip and asserts their starts, lengths, instrument pad, output channel, and pattern length.

Future extensions: Use this same phrase-shaped test style for loop recording, punch-in, quantized recording, automation capture, sustain-pedal capture, and future hardware timing receipts.

2026-07-13 08:42 - MIDI Closeout Reports Should Distinguish Missing Feature From Missing Proof

A launch checklist should not punish finished architecture by describing it as absent. Automation now has several real doors and a substantial editor, so the closeout language should name the remaining risk precisely: route consistency, hands-on handle feel, import/export/playback preservation, and real-device bend trust. This keeps the report useful for engineering and less demoralizing for product decisions.

2026-07-13 08:08 - Automation Doorway Copy As Workflow Contract

When a feature has multiple entry points, the tooltip is part of the architecture: it teaches the target-selection contract before the user clicks. Arrangement Automation now names selected clip, playhead clip, then first real clip as the same ordered fallback used by the code, which supports confidence without adding another inspector or workflow layer.

Creative Thinking

Hash-Bound Asset Rights Packets

Release artwork and factory audio are now treated like indivisible creative collections rather than unrelated files. A generated packet connects the human worksheet to exact SHA-256 identities, so replacing even one image or wave naturally forces a fresh decision. This same pattern can later protect theme packs, factory preset expansions, tutorial projects, and commercial sample libraries without pretending that software can decide legal ownership.

2026-08-21: Rights Evidence as a Small Decision Queue

Treating every blocked asset as an independent legal task made the release status look larger and less actionable than it is. The asset manifest already reveals two coherent ownership decisions: the complete visual identity collection and the complete TG55 factory-wave bank. A deterministic next-action helper now connects that machine-readable inventory to human-fillable worksheets. This same pattern can later organize preset authorship, commissioned artwork, factory sample packs, and theme/skin submissions: one collection-level decision, exact byte identities, durable evidence outside the public repository, and automated checks that prevent the recorded decision from drifting away from what ships.

2026-08-18 - Evidence Can Advance Without Becoming Authority

Task: Turn the remaining human release checks into reviewable candidate evidence without allowing automation to declare the product ready.

What connects creatively: SpaceAge already treats musical edits as a staged workflow: preview, commit, then preserve history. Release evidence benefits from the same rhythm. A tester records an observation, a reviewer confirms that the evidence belongs to the exact build, and only then can a readiness row be considered for closure. The generated report is therefore an inspector, not an executive.

Architecture choice: Keep readable Markdown receipts for humans and a parallel structured result file for deterministic review. Hash the cited artifacts into the review report, bind everything to candidate and commit identity, and leave the canonical readiness ledger unchanged. This same pattern can later govern installer certification, hardware-editor unlocks, asset-rights review, public marketing claims, and school-deployment qualification.

Guardrail: Never infer PASS from a filled form, a generated packet, or an automated backend gate. PASS requires explicit named review plus surviving evidence; FAIL and BLOCKED observations must remain visible.

2026-08-18 - Release Evidence Should Behave Like Authored Session Data

Task: Turn the remaining human release checks into an exact, candidate-bound working packet without pretending that generation equals completion.

Connection: SpaceAge already protects musical intent with project identity, receipts, checksums, and non-destructive history. Human QA should use the same design language. A receipt bound to a build and source commit is the release equivalent of a lane-owned Instrument: its ownership is explicit, it cannot silently float to another candidate, and negative results remain useful authored history.

Creative extension: The generated packet can later feed a read-only Release Cockpit inside SpaceAge, a school/site deployment certificate, support reproduction bundles, or a future CI dashboard. Software can prepare and validate the container, but only a human reviewer can accept perceptual, hardware, legal, or clean-machine evidence.

2026-08-18 - Block-Local Mixer Routing Snapshot

Connection to Existing Architecture

SpaceAge already captures immutable sequencer and loop snapshots once per audio block. Mixer routing now follows the same rule for channel mute, solo, output selection, and multi-output bus eligibility. These values do not need to be fetched again for every voice and every rendered sample.

Why This Helps Elsewhere

• The same block-local snapshot pattern can be reused for other control-rate channel-strip state without weakening sample-accurate MIDI event placement.
• It establishes a clear boundary: musical events and automation that are scheduled within the block remain sample accurate, while host routing decisions are stable for the duration of the callback.
• Future profiling can distinguish native voice cost from avoidable host bookkeeping instead of treating all CPU use as synthesis cost.

Executable Proof

• MIXER_LANE_ROUTING passes lane routing, mute/solo isolation, persistence, and hard-pan meter behavior.
• MIDI_RECORD_TIMING passes its complete timing and multi-controller matrix after the routing change.
• PERFORMANCE_SMOKE remains inside its real-time budget; its current eight-pad result is approximately 38-40% of the simulated callback window and remains a launch-optimization target rather than a closed item.

2026-07-13 - Tiny Copy Prevents Big Confusion

Task: Align Automation hover/help copy with the actual lane targeting order.

What connects creatively: A tooltip is not decoration here; it is a small contract. If the command picks selected clip, playhead clip, then fallback clip, the user should be able to learn that without reading source or guessing after a surprising panel opens.

Architecture choice: Lane AUTO badge tooltips and durable notes now state the selected/playhead/fallback order directly. This keeps the code behavior, status text, hover text, and reference docs from splitting into four stories.

Future extensions: Apply this same tooltip-as-contract discipline to MIDI recording, Hardware Passport actions, SysEx restore, render/export, Quasar capture, and future VST scans.

2026-07-13 - The Door Needs A Targeting Rule

Task: Make lane-level Automation opening choose a predictable clip target.

What connects creatively: A lane command should feel like it understands where the composer is looking. If a selected clip exists, that is the user's intent. If not, the playhead is the next strongest clue. Falling back to the first clip is useful only when there is no clearer context.

Architecture choice: openArrangementLaneMidiAuto() now resolves targets in this order: selected clip in lane, clip under Arrangement playhead, first playable clip in lane. It also synchronizes selection and reports the target reason in status text before opening Automation.

Future extensions: Use this same intent hierarchy for paste targets, automation recording targets, ghost-note source suggestions, render-range targeting, and future clip-local controller editing. Selection, playhead, fallback is a good default grammar for SpaceAge.

2026-07-13 - The Doorway Should Match The Room

Task: Align the Piano Roll AUTO button with the clip-aware Automation preview strip.

What connects creatively: If the strip below the chord lane shows automation but the button above it says nothing is there, the interface quietly teaches mistrust. This small UI pass connects backend truth to visible confidence: the button, strip, tooltip, and future automation editor doorway should all describe the same musical context.

Architecture choice: The button now asks for effective Arrangement-clip summaries when the visible Piano Roll is editing a selected Arrangement clip, otherwise it falls back to pattern summaries. This keeps shared PTN data, lane-local data, and clip-local data from presenting as separate realities.

Future extensions: Apply the same "doorway matches room" rule to automation record buttons, MIDI Learn badges, Hardware Passport status, SysEx Vault receipts, render progress, and Instrument Bay preset dirty states. Any small badge should be a reliable miniature of the deeper page it opens.

2026-07-13 - Recording Needs A Flight Plan

Task: Pin MIDI recording target length at record start so Arrangement recording cannot drift between clip-derived answers mid-session.

What connects creatively: A recording pass is a promise: the musician chose a lane, clip, and time window, and SpaceAge should keep that promise until recording stops. This same idea should guide automation capture, punch-in recording, hardware recording, and future clip-local MIDI expression: choose the target once, then perform into that target without making the performer chase hidden state changes.

Architecture choice: Immediate recording and count-in recording now snapshot the effective record length into processor-owned atomic state. The realtime length resolver still respects Arrangement clips, but the active session carries its own target length as the floor for note timing and commit behavior.

Future extensions: Add explicit target clip id/source-start fields for recording, not just target length. That will make punch-in, loop recording, take lanes, automation recording, and hardware capture even more deterministic.

2026-07-13 - Automation Should Not Wear A Note Mask

Task: Make MIDI expression recording clear stale note/drum receipt state and signal the UI only after the expression event commits.

What connects creatively: Automation is a different kind of musical gesture. If the app shows a note receipt after the user records a mod wheel, expression pedal, sustain, or pitch gesture, the interface teaches the wrong lesson. This pass keeps the status language aligned with the actual thing the musician just performed.

Architecture choice: Expression recording now mirrors the note/drum queue rule: successful enqueue stays quiet, commit raises the changed flag, and receipt fields are reset so the UI falls through to expression/automation reporting. Step input also stops firing the recording-changed flag before its queued note commit lands.

Future extensions: Automation should eventually display a concise committed-event receipt: controller name, channel, value, and musical position. The same model can make pitch-bend, aftertouch, sustain, and hardware CC captures feel visible without making the user read raw MIDI.

2026-07-13 - Receipts Must Come From Reality

Task: Make Arrangement drum recording receipts report the committed pad/step/velocity and remove the premature changed-signal race.

What connects creatively: A receipt is a tiny piece of trust. If it fires before the recording actually lands, the user sees uncertainty at the exact moment they need confidence. This connects directly to our broader SpaceAge philosophy: show the musician what truly happened, in plain musical language, right after it happened.

Architecture choice: Successful melodic and drum captures now let the queue commit path raise the changed signal. Drum commits store pad, step, and velocity receipt fields, while melodic commits clear drum receipt fields. The UI summary can therefore distinguish piano-note capture from drum-step capture without guessing.

Future extensions: Use the same committed-state receipt principle for automation lanes, SysEx Vault actions, Hardware Passport test notes, render/export progress, Quasar captures, and future VST scans. Anything that tells the user "done" should be describing committed state, not intent.

2026-07-12 - Recording Needs One Owner

Task: Remove MIDI recording fallback to a loose selected pattern.

What connects creatively: This is one of those workflow choices that makes the app feel either trustworthy or haunted. If recording sometimes follows the selected pattern and sometimes follows the lane, the musician has to keep a private map in their head. If the armed lane always owns live input and recording, the GUI can teach one simple rule: light up the lane you want to play into, then record.

Architecture choice: The editor-side recording target resolver now refuses to start without an armed Arrangement lane. It still uses the armed lane intelligently: record into an overlapped clip when the playhead sits over one, otherwise create a fresh lane-owned clip/pattern at the playhead or lane end according to existing landing rules.

Future extensions: The same ownership rule should drive automation capture, MIDI Learn context, hardware output testing, and ghost-note selection: first choose the lane/instrument context, then perform the action. This keeps Instrument Bay and Arrangement lanes from drifting back toward the old pad-as-proxy confusion.

2026-07-12 - A Cockpit Needs Its Flight Recorder Visible

Task: Show the MIDI QA receipt store inside MIDI Health.

What connects creatively: A ledger that exists only in project state is good engineering, but a visible cockpit row turns it into user trust. The musician can see whether the project carries append-only MIDI QA evidence without digging into a report, and we can reuse that same pattern for render proof, hardware setup proof, Quasar capture proof, and future release-candidate checklists.

Architecture choice: MIDI Health now asks the processor for MidiProtocolQaReceiptStore, renders its summary as QA STORE, and refreshes it with the other MIDI Health status rows. This keeps the panel cold and observational: it reports evidence; it does not send MIDI, alter routing, or mutate external hardware.

Future extensions: Add a receipt browser with filters for Hardware Passport, SysEx Vault, import/export round trips, timing calibration, and live recording checks. Eventually this can become a "project confidence" page for schools, collaborators, and release QA.

2026-07-12 - Evidence Should Travel With The Song

Task: Bridge MIDI QA receipt storage into project state.

What connects creatively: If QA proof lives only in copied text, it is easy to lose. If it lives in the project, the song becomes its own flight recorder: what MIDI surfaces were checked, which receipts passed, and what still needs evidence. That model can eventually make exports, archives, school-lab deployments, and collaborator handoffs feel trustworthy instead of anecdotal.

Architecture choice: The processor now owns a MidiProtocolQaReceiptStore, persists it as midiQaReceipts, restores it during project load, and exposes append/read/clear methods. MIDI Health shows the renderable QA action queue so the UI can display backend-owned actions rather than inventing them locally.

Future extensions: Wire the Settings panel buttons to appendMidiQaReceipt, add review/filter UI for saved receipts, include receipts in exported archives, and reuse the same ledger pattern for render proof, hardware setup proof, Quasar capture proof, and future VST scan decisions.

2026-07-12 - A Panel Should Render Truth, Not Invent It

Task: Add a renderable MIDI QA receipt action queue.

What connects creatively: One correct button is good, but a Settings panel needs a whole row of correct promises. If the panel has to infer which closeout receipts are incomplete, save-ready, or review-only, it becomes another place for drift. The queue lets the backend hand the UI a complete cold-action list: render this, count this, and do not send MIDI.

Architecture choice: MidiProtocolQaReceiptActionQueue collects action states for every active closeout receipt. It reports COMPLETE/SAVE/REVIEW counts, project-mutation count, MIDI-send count, allMidiSafe, primary action, structured payload, and plain-text report. MIDI Protocol Coverage and MIDI Health now expose the queue beside the single next-action surface.

Future extensions: The visible Settings panel can now show COMPLETE QA RECEIPT, SAVE QA RECEIPT, and REVIEW QA RECEIPT actions by reading the queue instead of duplicating logic. This same queue pattern should serve render receipts, hardware setup receipts, Quasar capture receipts, and VST scan decisions.

2026-07-12 - A Button Is A Promise

Task: Add a UI-facing action contract for MIDI QA receipts.

What connects creatively: The same receipt can mean three very different things: "finish filling me out," "save me as evidence," or "review what was already saved." If the UI does not know the difference, it can accidentally imply proof, mutate project state at the wrong time, or make a cold evidence action feel like a MIDI action. A tiny action state keeps that promise clean.

Architecture choice: MidiProtocolQaReceiptActionState maps receipt snapshots to completeQaReceipt, saveQaReceipt, or reviewQaReceipt. The action state reports its button label, storage path, helper text, project-mutation boundary, and sendsMidi=false. MIDI Protocol Coverage and MIDI Health now expose the same action-surface summary in copy text, reports, and structured payloads.

Future extensions: Wire this directly to visible Settings/QA buttons. The same state-machine pattern should be reused for render receipts, hardware setup checks, SysEx restore proof, Quasar captures, VST scan decisions, and any school-lab deployment checklist where a button must say exactly what kind of evidence it creates.

2026-07-12 - Evidence Needs A Ledger, Not A Clipboard

Task: Add the serializable MIDI QA receipt store model behind the receipt-store contract.

What connects creatively: A clipboard packet is useful for humans, but it is not memory. The receipt ledger lets SpaceAge start treating QA proof like a project artifact: something appended, restored, reviewed, and exported. That same idea can later support render proof, Quasar capture proof, hardware setup proof, VST scan decisions, school-lab deployment checks, and release-candidate signoffs.

Architecture choice: MidiProtocolQaReceiptStore now owns an append-only project.midi.qaReceipts model. It accepts only save-ready PASS/FAIL/BLOCKED receipts, marks appended receipts as saved, preserves older evidence for the same persistentStateKey, derives latest-key counts, and round-trips through toVar() / fromVar(). MIDI Protocol Coverage and MIDI Health now report the model separately from the contract and separately from actual saved QA evidence.

Future extensions: Wire SAVE QA RECEIPT and REVIEW QA RECEIPT into a visible Settings/QA panel, then let project archives include copied receipt records so collaborators and future testers know exactly what was proved, blocked, or still unverified.

2026-07-12 - A Receipt Store Needs Rules Before Buttons

Task: Add the MIDI closeout QA receipt store contract to Protocol Coverage and MIDI Health.

What connects creatively: A receipt button without storage rules is a trap. It can make the user feel like proof exists while the app is only holding temporary prose. The store contract gives SpaceAge a small but important constitution: receipts are keyed by persistent state, saved as project/export evidence, appended as history, and never silently overwritten.

Architecture choice: MidiProtocolCoverageReport::currentFinishLineQaReceiptStoreContractSummary() is the single source. COPY QA, COPY CLOSEOUT, the full Protocol report, MIDI Health next steps/full report, and structured payloads all reuse it. The contract names project.midi.qaReceipts, persistentStateKey, required fields, append/latest policy, review/save actions, export inclusion, and the cold safety boundary.

Future extensions: The same append-only evidence pattern can serve render receipts, Quasar package captures, hardware profile tests, SysEx restores, VST scan decisions, school deployment audits, and beta-tester bug receipts.

2026-07-12 - A Receipt Form Is Not A Receipt

Task: Add a MIDI closeout QA receipt-persistence summary to Protocol Coverage and MIDI Health.

What connects creatively: SpaceAge is developing a useful habit: separating intention, scaffolding, and proof. A Hardware Passport template is not a working QY-70 session. A SysEx packet is not a successful restore. Likewise, a QA receipt template is not a saved PASS/FAIL/BLOCKED result. That honesty protects the product from inflated claims and protects the tester from wondering whether "ready" means "proved."

Architecture choice: MidiProtocolCoverageReport::currentFinishLineQaReceiptPersistenceCloseoutSummary() is the single source. COPY QA, COPY CLOSEOUT, the full Protocol report, MIDI Health next steps/full report, and structured payloads all reuse it. The summary counts templates, durable saved receipts, unsaved templates, ready-to-save forms, and missing-field rows, then names the missing product step: wire COMPLETE QA RECEIPT / SAVE QA RECEIPT to durable project or exported QA state.

Future extensions: This should become the visible receipt store for every major product surface: MIDI closeout, render/export, Quasar capture, VST hosting, Linux builds, school lab deployments, and hardware editor support.

2026-07-12 - A Tester Needs A Flight Plan

Task: Add an ordered MIDI closeout QA run summary to Protocol Coverage and MIDI Health.

What connects creatively: The MIDI closeout model now knows a lot: category priority, owner surface, route proof, safety class, QA checks, receipt readiness, hardware evidence, and the current critical path. That is powerful, but too much undirected truth can feel like a pile of cockpit lights. A run order turns the same facts into a flight plan: test this first, here is the door, here is the first proof cue, then move down the list.

Architecture choice: MidiProtocolCoverageReport::currentFinishLineQaRunOrderSummary() is the single source. Protocol Coverage copy/report paths, MIDI Health next steps/full report, and structured payloads all reuse it. No MIDI routing, playback, recording, SysEx, automation editing, or hardware behavior changed.

Future extensions: This can become a visible QA checklist panel with PASS/FAIL/BLOCKED receipts, a progress bar, and safe-door buttons. The same pattern should be reused for Render QA, Quasar capture QA, VST hosting QA, Linux packaging, and school-deployment test plans.

2026-07-12 - A Work Order Needs One Critical Path

Task: Add the MIDI Protocol Coverage Critical path sentence to MIDI Health COPY STEPS, the full Health report, and the structured Health payload.

What connects creatively: COPY STEPS is the musician-facing work order. It already says what the app sees, what it trusts, what proof is missing, and what receipt action is next. The missing emotional piece was the one-line triage cue: "this is the thing most likely to unblock the whole closeout." Without that line, a tester could copy the short report and still have to infer priority from the longer protocol dump.

Architecture choice: MIDI Health now reuses MidiProtocolCoverageReport::criticalCloseoutPathSummary() directly. No second priority model, no duplicated strings, and no behavior change. The Release self-test protects the readable Health reports and the structured criticalCloseoutPathSummary property.

Future extensions: Let the Health panel show this as a compact top card beside FIX NEXT, and eventually let persistent QA receipts mark whether the critical-path item is PASS, FAIL, or BLOCKED.

2026-07-12 - Closeout Copy Should Carry The Proof Gauge

Task: Add the MIDI closeout QA receipt-readiness rollup to COPY CLOSEOUT, matching the deeper COPY QA and report surfaces.

What connects creatively: SpaceAge now has two kinds of copied MIDI text: a QA session packet and a release closeout packet. They should not feel like two different truths. COPY QA can stay deeper and template-heavy, but COPY CLOSEOUT still needs the proof gauge so a tester knows whether the closeout work has real saved evidence or only scaffolding.

Architecture choice: MidiProtocolCoverageReport::currentFinishLineCloseoutClipboardText() now includes currentFinishLineQaReceiptReadinessSummary() beside next mission, safety, route audit, and critical path. Release self-tests protect both the direct string and structured payload copy body.

Future extensions: Use the same rule for Render, Quasar, VST hosting, and school deployment checklists: the shorter copy packet can omit detailed forms, but it should never omit the proof gauge.

2026-07-12 - Cockpit Reports Should Not Hide Proof Readiness

Task: Surface the current MIDI closeout QA receipt-readiness rollup in the higher-level MIDI Health reports, not only in the deeper MIDI Protocol Coverage report.

What connects creatively: A cockpit should not hide the fuel gauge in the engine room. The Protocol Coverage object can carry the detailed truth, but the user-facing MIDI Health report is where a tired tester, support person, or future Admiral is likely to look first. The closer we put proof readiness to the surface, the less the app feels like it has secret rules.

Architecture choice: MidiProjectHealthSummary now prints currentFinishLineQaReceiptReadinessSummary() in both its next-steps and full plain-text reports, and exposes the same sentence in its structured payload. Release self-tests protect both the readable strings and the machine-readable property.

Future extensions: Use this as the model for Render, Quasar, VST hosting, Linux packaging, and school-deployment QA: the deep subsystem can own the facts, but the cockpit report should always show the proof state and the next useful action.

2026-07-12 - Receipt Readiness Is Not The Same As Proof

Task: Add a MIDI closeout QA receipt-readiness rollup to the protocol coverage report and COPY QA packet.

What connects creatively: SpaceAge keeps separating intent from proof: a queued SysEx dump is not an accepted restore, a Hardware Passport is not a successful hardware session, and a fixture test is not a real musician's rig. QA receipts need the same distinction. A receipt template says we know what evidence to ask for; a saved PASS/FAIL/BLOCKED receipt says a human actually checked it.

Architecture choice: MidiProtocolCoverageReport::currentFinishLineQaReceiptReadinessSummary() now counts active closeout categories, receipt templates, save-ready receipts, missing receipt fields, and hardware evidence rows. The plain report, structured payload, COPY QA packet, docs, and Release self-test all carry the same language.

Future extensions: Make this visible in the MIDI Protocol Coverage panel as a compact meter, then reuse the same readiness/proof split for exports, Quasar packages, Render, VST hosting, school deployments, and public release-note claim checks.

2026-07-12 - Blank Evidence Fields Waste Human Attention

Task: Add evidence-notes prompts to MIDI closeout QA session templates.

What connects creatively: We have been building SpaceAge around visible intent: selected lanes glow, Instrument Bay should name the active sound, Hardware Passports explain external gear, and Automation says what shared pattern data means. QA should follow the same rhythm. A blank Evidence notes: field makes the tester remember what they were proving; a prompt turns it into a direct question.

Architecture choice: currentFinishLineQaSessionTemplate() now prints an Evidence notes prompt for each blocker category, using the first QA check when available and the recommended focus as a fallback. The Release self-test protects the prompt so copied QA templates keep guiding the tester.

Future extensions: Reuse this for Render, Quasar capture, VST hosting, instrument preset QA, and school-lab deployment checks. Every PASS/FAIL/BLOCKED receipt should ask the human for the exact proof that matters.

2026-07-12 - QA Copy Should Also Protect The Website

Task: Add the customer-facing MIDI closeout plan and safe public MIDI claim boundary to the paste-ready COPY QA packet.

What connects creatively: QA, support, and marketing are usually treated like separate rooms, but they are all handling the same promise. A tester copying QA notes is often one step away from writing release notes or telling a collaborator what works. Putting the closeout plan and claim boundary inside the QA packet keeps SpaceAge honest without asking anybody to remember a separate doctrine.

Architecture choice: MidiProtocolCoverageReport::currentFinishLineQaClipboardText() now includes customerFacingMidiCloseoutPlanSummary() and safePublicMidiClaimSummary() before the release gate and receipt details. The Release self-test protects both strings and the explicit "universal DAW interchange" warning.

Future extensions: Use the same pattern for synth engines, render/export, VST hosting, Quasar, and Linux builds: any QA packet that could influence public language should carry a compact claim boundary.

2026-07-12 - Copyable Steps Should Behave Like A Tiny Navigator

Task: Make the copied MIDI Health next-steps report include the same QA receipt action language as the full MIDI Protocol report.

What connects creatively: SpaceAge keeps turning complex systems into guided surfaces: Instrument Bay instead of pad-proxy confusion, Automation instead of hidden controller data, Hardware Passports instead of mystery cables. The same idea belongs in copied support text. If a tester copies next steps, the text should already say where to go, what proof is missing, what button state matters, and what kind of receipt must be completed.

Architecture choice: Add the QA receipt action: COMPLETE QA RECEIPT | Complete missing QA receipt fields... line to MidiProjectHealthSummary::toPlainTextNextSteps() and protect it with the Release self-test alongside route contract, safety boundary, next mission, and Automation Final Editor assertions.

Future extensions: This pattern can become the template for build-ready QA packets: every important system should have a copyable next-action card that names the surface, the safety class, the required evidence, and the exact user-facing button that advances the work.

2026-07-12 - The Last Mile Is A User Feeling, Not A Parser

Task: Add a concise customer-facing MIDI closeout plan to MIDI Protocol Coverage so the remaining work is framed as musician workflow instead of another abstract protocol percentage.

What connects creatively: A MIDI parser can be impressive and still fail the human if the user cannot see, trust, edit, record, export, or verify what happened. SpaceAge's design language keeps trying to turn deep systems into obvious surfaces: Arrangement lanes, Chord Engine hexes, Instrument Bay choices, and now MIDI closeout. The same rule applies everywhere: power becomes real when the user can act on it calmly.

Architecture choice: Add customerFacingMidiCloseoutPlanSummary to the source-owned report. It names the remaining launch path: Automation hands-on popup editing QA through current preview strips, badges/counts, doorways, and owner-scoped popup tools; Hardware Passport bend/setup receipts; MIDI Learn conflict/feel review; guarded SysEx capture/restore proof; real-file import/export round trips; timing/live-lag validation; and evidence-backed release wording. It also keeps full expanded timeline Automation lanes, true MPE, MIDI 2.0, Motion Clips, general non-MIDI Arrangement automation, and universal hardware editors in the future layer.

Future extensions: This could become a Settings readiness card, beta-testing checklist, or private launch dashboard. It gives engineering, docs, support, and marketing one compact sentence of truth about what remains before MIDI feels release-worthy to musicians.

Visibility follow-up: MIDI Health now exposes the same sentence as CLOSEOUT PLAN. This matters because the user-facing diagnostic panel is often where a confused tester will look first; the app should explain the final mile before the human has to ask.

2026-07-12 - One Sentence Can Save A Promise

Task: Add a concise public-claim boundary to MIDI Protocol Coverage so marketing, manuals, support, and release notes can say what is true without rereading the whole checklist.

What connects creatively: Long checklists protect engineers, but short sentences protect customers. SpaceAge can proudly say it has an advanced MIDI 1.0 foundation, but the dangerous words are "complete," "MPE," "MIDI 2.0," "effortless hardware," "device-accepted restore," and "universal interchange." Those phrases should require saved proof, not optimism.

Architecture choice: Add safePublicMidiClaimSummary to the same source-of-truth report as the release gate, validation ladder, and wording audit. The safe side names what is real now: guarded import/export, routing, recording, playback, controller capture, SysEx vaulting, hardware setup scaffolding, and visible closeout reports. The unsafe side names claims blocked until receipts exist.

Future extensions: Reuse this pattern for synth engines, effects, VST hosting, Quasar, school licensing, Linux builds, and AI-related features. Every big product promise deserves a one-sentence claim boundary before it reaches a website.

2026-07-12 - Evidence Should Climb A Ladder

Task: Give MIDI Protocol Coverage a single ordered validation ladder that explains how SpaceAge moves from internal implementation to public release confidence.

What connects creatively: A self-test pass is good news, but it is not the same emotional promise as "your MiniNova, QY-70, controller, DAW import, and SysEx restore will behave." A ladder lets us celebrate each rung without smearing them together. It connects automated fixtures, visible workflow QA, saved receipts, real-file interchange, real hardware, and marketing copy into one chain of truth.

Architecture choice: Add releaseCandidateValidationLadderSummary beside the release gate and trust-boundary summaries. It names the proof order: Release self-tests, UI closeout route, saved PASS/FAIL/BLOCKED receipt, real-file DAW round trip, real controller/interface/external synth/SysEx/bend/clock/live-timing validation, then public release notes that claim only saved evidence.

Future extensions: This ladder should become the template for every launch-quality subsystem: VST hosting, Quasar capture, sample relocation, render/export, Hardware Passports, and school-lab deployments. The app should always know whether a feature is internally prepared, beta-ready, hardware-proven, or public-claim-ready.

2026-07-12 - Hardware Truth Lives Outside The App

Task: Make MIDI Protocol Coverage explicitly distinguish SpaceAge-side MIDI intent from proof that real devices accepted and behaved correctly.

What connects creatively: The MIDI implementation is now broad enough that the dangerous lie would be subtle: "our report says queued, therefore the synth obeyed." Real hardware has its own temperament: drivers, interfaces, bend ranges, SysEx pacing, clock followers, host routing, and timing feel. The honest product move is to make real-world validation a first-class boundary rather than an afterthought.

Architecture choice: Add a realHardwareValidationTrustBoundarySummary to the same report family that already owns SysEx, MIDI Learn, timing, import/export, and future-protocol trust boundaries. That gives Settings, copied reports, support bundles, tests, and docs one sentence of truth: SpaceAge-side reports prove internal intent; saved PASS/FAIL/BLOCKED checks with real controllers, MIDI interfaces, DAW hosts, external synths, files, SysEx restores, bend tests, clock/transport sync, and live timing observations prove release trust.

Future extensions: Turn this into a guided MIDI Rig Doctor pass: choose a controller, pick a hardware synth, send a test note, confirm bend range, restore one harmless SysEx snapshot, chase clock, import/export a known file, and save the receipt. The same receipt shape can later serve school labs, beta testers, and support triage.

2026-07-12 - MPE-Like Is Not MPE, And That Matters

Task: Make true MPE and MIDI 2.0 claims explicitly separate from current MIDI 1.0 expressive-data support.

Connections: SpaceAge already preserves expressive MIDI 1.0 material: pitch bend, pressure, poly pressure, timbre-style CCs, and multi-channel imported performances. That is useful for MIDI guitar, wind controllers, expressive keyboards, and future hardware editors. But those same features can tempt a product into saying "MPE" too early. This note ties MIDI Protocol Coverage, Automation, Hardware Passports, import/export, synth response, and future MIDI 2.0 work to a single honesty rule.

Architecture choice: MidiProtocolCoverageReport now exports futureProtocolTrustBoundarySummary. It states that MPE-like data preservation is not true MPE or MIDI 2.0 support. True MPE needs zone policy, master/member channels, per-note channel ownership, per-note editing, synth response, import/export validation, and real hardware testing. MIDI 2.0 needs UMP, profile exchange, property exchange, device negotiation, and compatibility tests.

Future extensions: When we do true MPE, the first customer-facing surface should probably be a lane-level Expressive Mode choice: Standard MIDI 1.0, MIDI Guitar Cleanup, Wind Controller, MPE Zone, and eventually MIDI 2.0 Profile. That keeps power visible without pretending every expressive clip is the same kind of thing.

2026-07-12 - Setup Messages Are Not Music Notes

Task: Make RPN/NRPN, Data Entry, Bank/Program, and protected channel-mode/reset trust explicit in MIDI Protocol Coverage.

Connections: This is the same class of thinking behind Hardware Passports, MIDI PATCH, SysEx Vault, Yamaha XG editing, future Roland/GS editors, and external-lane recall. These messages can change what a hardware synth is, not merely what it plays, so they need a different ritual than notes, bend, pressure, or mod wheel gestures.

Architecture choice: MidiProtocolCoverageReport now exports setupControllerTrustBoundarySummary into copied reports and structured payloads. It says setup-controller data belongs in visible MIDI PATCH / Hardware Passport flows with device/channel identity, explicit queue/send confirmation, undo-safe metadata, and external evidence.

Future extensions: Use this boundary as the customer-facing rule for XG/GS editors: parameter editing can be friendly and musical, but the app must always show target device, channel/part, queued message, confirmation, and proof state. It also protects live recording from capturing setup changes as hidden Automation curves.

2026-07-12 - Sync Moves Time, So It Needs A Captain

Task: Make MIDI sync and transport trust explicit in MIDI Protocol Coverage.

Connections: Notes make sound; sync moves the whole room. MIDI Clock, Start, Stop, Continue, Song Position, host sync, and internal sync touch playback authority, external gear, arrangement loops, and recording feel. This connects Host Sync, MIDI Timing, Hardware Passports, external lanes, transport controls, live recording, and future hardware scenes around one rule: the user should always know who is captain of time.

Architecture choice: MidiProtocolCoverageReport now exports syncTransportTrustBoundarySummary into copied reports and structured payloads. It names the release-proof fields: time authority, receive/send role, tempo source, chase behavior, loop/start policy, output device, Hardware Passport consequences, and real external-device evidence.

Future extensions: Turn this into a visible Sync Setup card with Authority, Receiving, Sending, Chase, Loop Policy, Hardware Passport, and Proof rows. The same model can later protect scene recalls, hardware clock sends, and plugin-host mode without inventing a new sync explanation each time.

2026-07-12 - Hardware Setup Should Feel Like A Ritual, Not A Trapdoor

Task: Make the first-run external MIDI hardware setup boundary explicit in MIDI Protocol Coverage.

Connections: Hardware can be wonderful, but it is also where trust gets fragile: a cable is invisible in software, a channel can be wrong, and a SysEx or reset message can affect a real machine. This connects MIDI Setup, Hardware Passports, MIDI PATCH, SysEx Vault, MIDI Timing, external lane routing, and future XG/GS editors around one principle: SpaceAge should guide hardware setup as a visible ritual, never as a hidden trapdoor.

Architecture choice: MidiProtocolCoverageReport now exports hardwareSetupWizardTrustBoundarySummary into copied reports and structured payloads. It says that external hardware is product-trusted only after input/output selection, lane role, channel policy, confirmed test notes or setup cards, and saved receipts. It also names the no-silent-send boundary for Program/Bank, RPN/NRPN, SysEx, clock, transport, and reset data.

Future extensions: Use this boundary as the checklist for the eventual Hardware Setup wizard: Pick Device, Choose Role, Choose Channel, Send Test Note, Confirm Audio, Save Passport, Optional Setup Cards, and Export Support Receipt. That would make QY-70/QY-100, CBX-K1XG, MiniNova, and other hardware feel less like a MIDI archaeology dig.

2026-07-12 - Automation Must Be Visible Before It Is Trusted

Task: Make Automation visibility and discoverability explicit in MIDI Protocol Coverage.

Connections: MIDI automation can be technically correct and still feel broken if the user cannot find it. This connects the Arrangement Canvas, Piano Roll, selected PTN/clip reporting, MIDI recording, import/export, MIDI Learn, and future Motion Clips around one principle: musical change over time must be visible where the composer expects to look.

Architecture choice: MidiProtocolCoverageReport now exports automationLaneVisibilityTrustBoundarySummary into copied reports and structured payloads. It says that backend storage/playback is not enough; Automation must be discoverable from the musical context, openable from the selected PTN/clip, labelled as shared pattern-owned data, undo-editable, and clearly separate from future clip-local or lane-local automation.

Future extensions: Use this boundary to drive a small visible AUTO or MOTION badge on clips that contain expression rows, plus a direct Open AUTO action from selected clips. Later, the same model can distinguish shared PTN automation, clip-local automation, lane automation, and full Motion Clips without confusing the user.

2026-07-12 - Mapped Controls Need Traffic Rules

Task: Make MIDI control-map conflict readiness explicit in MIDI Protocol Coverage.

Connections: MIDI Learn is not finished just because a knob can be learned. A hardware control is a tiny road entering SpaceAge, and it needs traffic rules: source, target, device/channel scope, pickup behavior, curve, range, high-resolution pairing, and conflict status. This connects MIDI Maps, direct Learn, Hardware Passports, automation assignment, controller templates, and future support reports.

Architecture choice: MidiProtocolCoverageReport now exports midiControlMappingConflictTrustBoundarySummary into copied reports and structured payloads. It distinguishes stored mappings from product-trusted mappings and names the remaining human-facing proof: duplicate target/source conflicts, destructive ranges, missing pickup, and hardware/controller feel.

Future extensions: Turn this boundary into a MIDI Maps review checklist: No duplicate surprises, Pickup tested, Range sane, 14-bit paired, Macro intentional, and Feel approved. That would let a user bless a controller map the way they might arm a track for recording.

2026-07-12 - Recording Should Have One Owner

Task: Make the live MIDI recording capture boundary explicit in MIDI Protocol Coverage.

Connections: Earlier testing exposed a painful ambiguity: sometimes it felt like the selected clip owned MIDI input, sometimes the armed lane did. The musical workflow is saner if live input has one owner. The armed Arrangement lane is the performance destination; clip selection is for editing.

Architecture choice: MidiProtocolCoverageReport now exports liveRecordingCaptureTrustBoundarySummary into copied reports and structured payloads. It states that record-time capture accepts notes plus editable performance expression, while setup payloads such as Bank/Program, RPN/NRPN, Data Entry, SysEx, clock/transport, and protected reset/channel-mode messages stay in import/review/setup flows.

Future extensions: This boundary should eventually power a visible recording preflight badge: Lane Armed, Input Channel, Captures Notes + Expression, Setup Data Review Only, and Latency Path. That would make live MIDI recording feel less mystical and more like a clean studio signal path.

2026-07-12 - Proof Is Not The Same As A Proof Form

Task: Make the QA receipt persistence trust boundary explicit in MIDI Protocol Coverage.

Connections: SpaceAge is getting good at generating QA language: session ids, state keys, missing-field lists, save-readiness labels, and PASS/FAIL/BLOCKED vocabulary. That is valuable, but it can create false confidence if the user or tester mistakes an empty receipt form for evidence. A product that respects musicians should make that distinction visible.

Architecture choice: MidiProtocolCoverageReport now exports qaReceiptPersistenceTrustBoundarySummary into copied reports and structured payloads. It says exactly what exists today and exactly what still proves a real QA pass: result, checker/timestamp, evidence notes, receipt refs, and blocking/follow-up decisions saved with the project or exported QA record.

Future extensions: Turn this into a dedicated QA drawer: each blocker can show Template Ready, Evidence Missing, Saved PASS, Saved FAIL, or Blocked. That would let testers move through MIDI closeout like a cockpit checklist instead of a pile of prose.

2026-07-12 - MIDI Files Need Field Trips

Task: Make the real-file import/export trust boundary explicit in MIDI Protocol Coverage.

Connections: Self-tests are necessary, but music software earns trust by surviving weird real files from other DAWs, hardware workstations, General MIDI/XG arrangements, dense controller performances, and warning-heavy setup data. The import/export model can be correct for known fixtures while still needing field evidence from the messy world.

Architecture choice: MidiProtocolCoverageReport now exports realFileRoundTripTrustBoundarySummary into copyable reports and structured payloads. It names the difference between fixture proof and release confidence, so future support reports cannot quietly imply that passing synthetic tests is the same as broad MIDI interchange validation.

Future extensions: Create a small curated MIDI torture-suite folder: clean DAW clips, GM/XG songs, files with overlapping notes, dense CC/pitch-bend/pressure lanes, SysEx/setup-heavy files, tempo-map files, and exported SpaceAge stems re-opened in at least one other DAW. Every row should produce a receipt.

2026-07-12 - Timing Truth Is a Product Feature

Task: Make the MIDI timing/live-lag trust boundary explicit in MIDI Protocol Coverage.

Connections: Timing problems are emotionally sharp because the player feels them immediately. The app can be technically correct about sample offsets and still feel late if the buffer, driver, interface, controller, Bluetooth path, hardware response, or duplicate monitoring path is wrong. That means SpaceAge should be honest: internal timing intent is one layer, real rig feel is another.

Architecture choice: MidiProtocolCoverageReport now exports timingLiveLagTrustBoundarySummary into copied reports and structured payloads. It sits beside bend-range, SysEx restore, MIDI Learn, and import conductor-map boundaries so support reports can say exactly what has been proven and what still needs a live-monitoring or MIDI Timing measurement pass.

Future extensions: Use this same boundary in a visible MIDI Timing wizard: buffer badge, input-path badge, controller/interface checklist, loopback measurement, manual alignment, and a short "play this and listen" confirmation. Timing should feel less like blame and more like a guided setup ritual.

2026-07-12 - Imported Tempo Maps Should Knock Before Entering

Task: Make the MIDI import conductor-map trust boundary explicit in MIDI Protocol Coverage.

What connects creatively: Imported MIDI files can carry tempo, meter, and key information that is musically meaningful in the source file but destructive in an existing SpaceAge arrangement. If the app silently reshapes the song around incoming metadata, the user loses trust in the Arrangement Canvas.

Architecture choice: Keep full source tempo/meter/key maps as reviewed receipt data until SpaceAge has a real undo-safe conductor timeline. A deliberate first-tempo/key adoption policy can remain useful, but full map adoption needs a visible structure that can be edited, undone, and understood.

Future extensions: This is the natural doorway to a Conductor Lane: tempo ramps, meter changes, key/scale regions, and song-form markers living as explicit visible objects. That lane could eventually make imported MIDI maps feel like compositional material instead of hidden global mutation.

2026-07-12 - MIDI Learn Should Feel Like A Handshake, Not A Guess

Task: Make the MIDI Learn mapping trust boundary explicit in MIDI Protocol Coverage.

What connects creatively: A learned controller mapping is a promise between a physical gesture and a musical result. SpaceAge can capture the source and bind it to a target, but the user's hand still has to approve the feel. This is especially important for 14-bit CC pairs, pedals, encoders, wind-controller expression, and controller surfaces with overlapping assignments.

Architecture choice: Keep the learn proof separate from the feel proof. The model can say, "we captured, persisted, merged companion CCs, and applied pickup/range/curve rules," while still requiring conflict review and in-context confirmation before calling the mapping excellent.

Future extensions: This points toward a MIDI Learn audition mode: wiggle the control, see the target respond, hear the musical result, then click KEEP, RANGE, CURVE, or REPLACE. That would make MIDI setup feel less like plumbing and more like fitting a musical glove.

2026-07-12 - SysEx Receipts Are Not Hardware Obedience

Task: Make the SysEx restore trust boundary explicit in MIDI Protocol Coverage.

What connects creatively: SysEx is powerful because it can resurrect an external synth exactly, but that power cuts both ways. A receipt that says SpaceAge captured, queued, or paced bytes is useful, but it is not the same as the external device saying, "I understood this and applied it." The UX has to make that difference feel obvious, not academic.

Architecture choice: Put the boundary in the report model itself: SpaceAge-side evidence is capture/framing/vault/preview/queue/receipt; hardware trust needs matching device identity, ACK/NAK/WAIT/CANCEL-style response evidence, successful restore verification, or manual confirmation. That keeps future Yamaha XG, Roland GS, and other hardware editors from accidentally implying success just because bytes moved.

Future extensions: This can become a simple visible trust ladder for SysEx snapshots: Captured, Identity Matched, Queued, Device Responded, Verified Restore. That kind of ladder could make scary old hardware workflows feel unusually friendly.

2026-07-12 - Pitch Bend Is Data Until A Destination Proves Its Width

Task: Make the hardware bend-range trust boundary explicit in the MIDI Protocol Coverage model.

What connects creatively: Pitch bend is one of the places where SpaceAge can be technically correct and still musically wrong. The raw MIDI curve can be perfectly preserved, but the listening result depends on what the destination synth thinks its bend range is. A Mininova, Yamaha XG module, SoundFont lane, and internal SpaceAge synth may all interpret the same 14-bit curve differently.

Architecture choice: Treat bend-range width as destination-owned knowledge. SpaceAge can draw, preserve, play, and export the raw bend curve, but external hardware slides are not trusted until the lane has a Hardware Passport, declared +/- bend range, and TEST BEND/manual evidence. This keeps the promise honest while still allowing powerful pitch expression.

Future extensions: The same trust ladder can become a visible badge: Raw Bend, Range Declared, Test Bend Needed, Verified. MIDI guitar, wind controller, and older Yamaha/Roland hardware workflows can then feel guided instead of mysterious.

2026-07-12 - Locked Hardware Editors Should Be Visible, Not Hidden

Task: Surface hardware-editor readiness in MIDI SETUP instead of leaving it only in backend template reports.

What connects creatively: A future Yamaha XG, Roland GS, or MiniNova editor should feel like a real instrument surface, but the user should also understand why some editors are locked. Showing the readiness state in the setup callout makes the doorway visible: SpaceAge knows this hardware family, knows that a deep editor is possible, and knows it must be manual-backed before any parameter sends become active.

Architecture choice: Keep the editor readiness state on MidiHardwareSetupDeviceTemplate, then let UI and copy reports read that same model-owned fact. This avoids another one-off warning string and keeps future hardware editor pages, Hardware Passport setup, SysEx Vault, and safe test-note workflows speaking the same language.

Future extensions: The same status can become a badge on Hardware Passports: Editor Locked, Profile Draft, Manual Verified, Queue Safe, and Ready. That gives hardware-heavy users a confidence ladder without making SpaceAge send a single risky byte automatically.

Follow-through: Copied template previews now include the manual/Data List source hint and verification checklist, not just the locked/ready label. That makes a future XG editor feel like a checklist-driven craft process instead of a vague promise.

2026-07-11 - Curve Handles Should Not Become A Second Truth

Task: Add first-pass draggable curve handles to Automation without weakening the shared-PTN safety model.

What connects creatively: Curve handles make automation feel more like a musical object and less like a spreadsheet of controller values. But if a handle drag secretly mutates the lane in a different way than APPLY CURVE, users lose trust fast. The handle should feel direct while still respecting the same preview-confirm ritual that already protects shared PTN data.

Architecture choice: FAST/SLOW handles now act as a tactile selector for the existing curve transform. Dragging chooses the curve family and strength; releasing arms the same preview-confirm APPLY CURVE path. That means the UI gets more expressive without adding a second mutation pipeline, extra MIDI sends, hidden routing changes, or hardware side effects.

Future extensions: This is a useful pattern for Motion Clips, chord strum curves, velocity shaping, filter sweeps, and future lane-local automation: make the gesture feel alive, but route the actual data change through one accountable preview/confirm/undo path.

2026-07-11 - A Cockpit Card Beats A Receipt Wall

MIDI perfection definition: For SpaceAge, MIDI 1.0 perfection is not just recognizing notes, CCs, bend, pressure, SysEx, clock, and program data. The musician-facing standard is: the app tells the user where MIDI is going, protects them from destructive setup data, preserves musical intent through import/export, makes automation editable without ownership confusion, and proves external-hardware claims with real receipts. Backend completeness and user confidence are different finish lines.

Task: Make the visible MIDI Protocol NEXT CLOSEOUT card easier to read while preserving the full audit trail.

What connects creatively: SpaceAge needs two truths at once: a musician needs to know what to do next, and QA/support needs the full receipt. Showing every receipt schema and persistence detail directly in the panel turns a useful cockpit into legal text. The better pattern is visible clarity plus copyable depth.

Architecture choice: Keep the model-owned report machinery intact, but shorten the visible card to the next focus, next test, route/proof status, hardware evidence cue, and manual run step. The full report remains copyable, so no evidence is lost.

Follow-through: The first cleanup still used the verbose critical-path summary, which carried receipt/schema detail back into the card. The visible card now uses the shorter next-focus summary instead; the critical-path receipt detail stays in copied reports where it belongs.

Health panel echo: MIDI Health gets the same rule. The visible row says NEXT FOCUS; the deeper critical path text remains in COPY CLOSEOUT.

Mission line cleanup: NEXT MISSION should be something a tester can actually do: open the surface, run the check, copy the notes, and know what proof is needed. Receipt schema and persistence-state details stay in copyable reports.

Receipt collapse: The live MIDI Health view should not show persistent-state schema, receipt schema, snapshot status, save readiness, and workflow as separate rows unless the user explicitly asks for a deep report. One QA RECEIPT line is enough in the cockpit; COPY QA and COPY CLOSEOUT carry the full receipt trail.

Route evidence depth: Route contracts, safety maps, and route audits are valuable QA evidence, but they are too forensic for the live cockpit. Keep the live MIDI Health surface focused on next focus/test/route/proof/safety/QA; leave the complete contract and audit trail in copied reports.

Evidence row depth: NEXT EVIDENCE and QA RUN STEP are important, but they duplicate the practical NEXT MISSION line in the live panel. The cockpit should show the next QA action and the receipt state; copied QA/closeout reports should carry the full evidence target and manual run-step wording.

AUTO row depth: The live MIDI Health panel should not tell the whole Automation story three times. Keep EXPRESSION for the stored-data summary and AUTO OPS for the operational readiness check; leave doorway instructions and full launch-closeout prose in copied reports.

Latency row depth: LIVE FEEL and FEEL ACTION are the musician-facing latency story. The raw LATENCY row should appear in the live cockpit only when the block size or direct input queue actually needs attention; full latency detail remains in copied reports.

Feel action depth: LIVE FEEL should stay visible because it tells the player whether the rig feels safe to perform through. FEEL ACTION should appear only when the feel verdict needs action; otherwise it becomes another always-on instruction line competing with the user's actual next step.

Input detail depth: MIDI IN should remain visible as a trust headline, but MIDI IN WHY belongs in the live cockpit only when the input trust gate is warning. Healthy routing explanations stay in copied reports where they can help support without eating daily screen space.

Sync detail depth: SYNC IN is enough as the always-visible heartbeat. SYNC TRUST earns visible space when sync traffic exists or is blocked, while SYNC NEXT and SYNC POLICY should surface only when there is a sync action/warning to resolve. The dedicated MIDI Sync panel and copied reports remain the deeper setup surface.

SysEx restore depth: HARDWARE is the right visible summary for Passport and SysEx snapshot counts. SYSEX RESTORE should appear only after restore activity has produced receipts or needs attention; otherwise it reads like a warning about a thing the user has not attempted yet.

Conditional row layout: Any live cockpit row that becomes warning-only must also update the reserved layout height. Otherwise the UI technically hides the prose but still pays for it in dead space, or worse, clips repair buttons when the conditional rows appear.

Count by inclusion, not subtraction: When a panel has conditional rows, start from the always-visible row count and add the optional rows that actually draw. Subtracting from an old total works for one edit, then becomes a trap when the cockpit changes again.

Tooltip depth: A tooltip can be detailed, but it should not become the hidden version of the receipt wall. Safe-door tooltips should explain the immediate action, route proof, safety boundary, and hardware cue; receipt schemas and persistence details belong in copied reports.

Next-closeout card density: The Protocol Coverage card should show the next focus, next test, route proof, hardware cue, and reminder that full QA details are copyable. Route summaries and manual-run paragraphs belong in reports once the card is visually cramped.

Closeout checklist density: A visible checklist should name the blocker, why it matters, where to go, and the first action. Route-openability flags, persistent-state schema, receipt schema, and save-readiness belong in COPY QA / COPY REPORT.

Priority QA map density: The visible owner-surface map should answer "where do I go and what do I do first?" rather than restating route-openability and receipt schema. Dense proof details remain valuable, but they belong in copied reports.

Hardware evidence density: The visible EVIDENCE card should teach the boundary in plain language: SpaceAge-side MIDI 1.0 closeout is not the same thing as real controller, host, file, and hardware proof. The cockpit keeps the next hardware evidence cue visible, while full validation summaries remain in copied reports.

QA card density: The visible QA CHECKS card should show the next QA action, evidence target, manual run cue, and a reminder that the full checklist is copyable. The complete checklist can remain detailed because it is meant for support and release validation, not for daily reading while composing.

Release gate density: The visible RELEASE GATE card should read like a launch status light: blocked/clear, percentage, next blocker, route, and QA receipt state. The full release-gate summary can remain pipe-delimited and forensic in copied reports, but the fixed-height card should not ask the musician to parse internal audit syntax.

Protocol row density: MIDI family rows should summarize state and point toward action. If a row needs hardware validation, it should say that proof is needed and point to EVIDENCE / COPY QA; long evidence cues belong in the dedicated evidence card or copied QA report, not inside the scrolling row footer.

Automation ownership honesty: Arrangement lane AUTO badges are useful because they put MIDI automation near the music, but they can accidentally imply lane-owned automation. Until true clip-local or lane-local automation exists, every visible doorway should say Shared PTN Data or pattern-owned MIDI automation somewhere close to the action. This preserves trust and reduces later migration pain.

Future extensions: This same pattern should guide Settings and future hardware setup pages: visible panel = action and confidence; copy/report/export = forensic detail.

2026-07-11 - Progress Labels Should Not Pick A Fight With The Backend

Task: Make the visible MIDI Protocol score labels less likely to imply backend regression.

What connects creatively: The app can track model rows, UI rows, receipts, safety, and hardware proof without making the musician think the actual MIDI message plumbing got worse. A dashboard denominator is not the same thing as engine competence, so the label should say what it really measures.

Architecture choice: The visible card now says TRACKED MODEL ROWS and MODEL READY / UI PENDING. The deeper copyable reports can keep more technical backend language because QA needs that detail, but the everyday panel should not make the user decode our internal scoring model.

Follow-through: The generated MIDI Protocol summary/report language now uses the same tracked model rows phrase, while preserving backend foundation as the separate high-90s MIDI 1.0 plumbing concept.

Future extensions: Any health/status screen should separate engine capability, user-facing workflow, and real-world proof as three distinct truths.

2026-07-11 - Short Labels Can Still Tell The Truth

Task: Align the MIDI automation doorway around Automation / Shared PTN Data without bloating the compact AUTO button.

What connects creatively: A tiny button can be useful and honest if the surrounding copy does the teaching. SpaceAge can keep the fast AUTO button for muscle memory and horizontal space, while tooltips, strip copy, setup reports, and docs explain the important boundary: these are shared pattern automation lanes today, not clip-local or lane-local Arrangement automation.

Architecture choice: Change doorway and status language rather than renaming storage classes. The code can keep using MidiExpression where it means protocol/performance data, while the user sees Automation / Shared PTN Data wherever ownership affects musical consequences.

Follow-through: The editor panel also needed the same treatment. Mixed names like MIDI AUTO, Automation, and MIDI expression make the feature feel bigger and stranger than it is. The product-facing language now treats Automation as the visible workbench and Shared PTN Data as the ownership warning, while implementation names stay private.

Future extensions: When clip-local or lane-local automation becomes real, the same naming pattern can scale cleanly: Automation / Clip Data, Automation / Lane Data, or a conversion dialog that offers Keep Shared PTN, Make Variant, and Make Clip-Local.

2026-07-11 - Imports Need Receipts After The Door Closes

Task: Preserve the latest MIDI import receipt and expose a cold copy action from MIDI TASKS.

What connects creatively: MIDI import already had a strong receipt popup, but a popup is a moment, not memory. Persisting the latest import receipt gives SpaceAge the same evidence habit as export: the user can import, close the review, keep working, and still copy the last import story from MIDI TASKS.

Architecture choice: Store the latest ordinary MIDI import receipt and MIDI stem-package import receipt on the editor, then expose a disabled-until-ready Copy Latest MIDI Import Receipt menu item. The copy action sends no MIDI, changes no routing, changes no project data, writes no file, and touches no external hardware.

Companion symmetry: MIDI TASKS can also export the selected pattern, so it now exposes Copy Latest MIDI Export Receipt beside the import receipt item. The Arranger RENDER menu remains the natural place for Arrangement export receipts; MIDI TASKS becomes the natural sequencer-side receipt desk.

Future extensions: The same slot can become an import history browser, support artifact, or collaborator-facing receipt list when archive import/export matures.

2026-07-11 - Receipts Need A Door Back Out

Task: Expose the latest single-file MIDI export receipt from the Arranger RENDER popup.

What connects creatively: A receipt stored in memory is only half a feature. The musician or tester needs to copy it at the moment they remember they need it, and the natural place to look is the same menu that exported the file. This keeps evidence retrieval close to the action without adding another permanent button to the crowded Arranger surface.

Architecture choice: Add Copy Latest MIDI Export Receipt as a disabled-until-ready menu item in the RENDER popup. The item copies the already-built completion receipt and changes no project/audio/MIDI/hardware state.

Future extensions: If export history becomes a first-class feature, this menu item can grow into Export History... with receipts for audio renders, MIDI files, stem packages, and archive packages.

2026-07-11 - Packages And Files Should Share The Same Evidence Habit

Task: Make MIDI stem package exports update the same latest-export receipt slot as single-file MIDI exports.

What connects creatively: Single MIDI files and MIDI stem packages are different artifacts, but the musician should not have to learn two different evidence workflows. The same RENDER popup doorway can now copy the latest MIDI export receipt whether the previous export was a .mid file or a folder-based stem package.

Architecture choice: Keep the processor's package README/manifest/checksum writing as the source of package truth, then add an editor-side completion receipt that points to those files and includes the reviewed MidiExportJobPlan. This avoids duplicating stem-package internals while still giving QA and collaborators a single receipt habit.

Future extensions: Export history can group audio renders, MIDI files, stem packages, and project archives under one receipt browser, with each row showing its own artifact type and proof files.

2026-07-11 - Completion Receipts Should Exist Before Buttons Ask For Them

Task: Store the latest single-file MIDI export completion receipt after pattern, clip, and Arrangement MIDI writes.

What connects creatively: Stem packages already feel more substantial because they have a progress and receipt path. Ordinary .mid exports should not be second-class citizens. Even before we add a visible COPY LAST EXPORT button, SpaceAge should know what it just wrote, where it wrote it, whether the file exists, and which reviewed plan produced it.

Architecture choice: Build a small completion receipt from the same MidiExportJobPlan used by the preview. The editor stores the latest receipt after the warm file write. No auto-copy, no modal popup, and no surprise clipboard overwrite.

Future extensions: Add a visible COPY LAST EXPORT action to the Render menu, MIDI export preview, or Settings MIDI cockpit. The same receipt can later become an export history row or a sidecar support artifact when users package stems for collaborators.

2026-07-11 - Export Plans Are Receipts Before They Are Files

Task: Add a cold COPY REPORT path to MIDI export previews.

What connects creatively: Export is a handoff to collaborators, other DAWs, schools, or future versions of SpaceAge. A user should be able to copy exactly what SpaceAge intends to write before anything touches the filesystem. That turns the preview into an audit object, not merely a pretty confirmation screen.

Architecture choice: Put the report on MidiExportJobPlan, because the model knows the recommended names, rows, warnings, readiness, and safety boundary. The UI simply copies model truth through the existing MIDI copy receipt wrapper.

Future extensions: The same report can become a saved sidecar text file in MIDI stem packages, an export history entry, or a support bundle artifact. It also gives the future export-progress window a ready-made receipt payload.

2026-07-11 - Warm File Writes Need A Second Gesture

Task: Make warning-bearing MIDI exports require an explicit second click before writing files.

What connects creatively: SpaceAge is gradually building a ritual of trust around risky actions: preview, warn, arm, commit. MIDI export is a collaboration boundary, so warnings about pitch-bend trust, hardware routes, or lane-specific data should not be hidden in a paragraph while the write button still behaves like a normal save.

Architecture choice: Keep clean exports fast, but turn warned exports into a two-step action inside the existing preview panel. The first click changes intent from review to confirmation; the second click writes. This preserves flow for ordinary exports while making high-information exports feel deliberate.

Future extensions: Use the same pattern for other warm write actions: SysEx recall packages, hardware setup apply, automation destructive transforms, and any future "send to device" workflow where the app can prepare data but the outside world must still be trusted carefully.

2026-07-11 - Future Automation Should Not Masquerade As Launch Debt

Task: Tighten MIDI AUTO closeout wording so shared PTN automation is treated as the current launch surface, while clip-local and lane-local automation remain future ownership architecture.

What connects creatively: SpaceAge can grow without confusing the present. Shared PTN automation is useful right now for reusable patterns, repeated gestures, imports, and VARIANT-based independence. Clip-local and lane-local automation will be powerful later, but if the app reports those future modes as unfinished current behavior, it makes real progress feel like a moving target.

Architecture choice: Adjust the model-owned protocol coverage and per-lane MIDI AUTO plan copy instead of patching only one UI label. This keeps Health, Protocol Coverage, copied reports, and future safe-door tooltips aligned.

Future extensions: When clip-local automation lands, introduce it as an explicit ownership choice beside shared PTN data: Keep Shared, Make Variant, or Make Clip-Local. Lane-local automation should be a separate lane/mixer promise, not a stealth change to pattern payloads.

2026-07-09 - Do Not Ask For A Feature Twice

Task: Correct MIDI AUTO closeout language so it credits existing direct hand-shaped selected-lane scope drawing and names draggable tangent-handle curve editing as the remaining future polish.

What connects creatively: A product can lose momentum when its own checklist misidentifies the problem. MIDI AUTO already lets the user draw/paint expression in the graph, so the remaining creative gap is not "can I shape automation by hand?" It is "can I sculpt curves with elegant tangent handles, destination-trust contracts, and final QA polish?"

Architecture choice: Update the model-owned protocol coverage and per-lane editor-plan strings, not just one visible label. MIDI Health, Protocol Coverage, copied MIDI AUTO reports, and tests now share the same truth boundary: direct scope drawing exists; draggable tangent-handle curves, durable external bend-range contracts, switch-edge QA, and future clip/lane-local automation remain.

Future extensions: When a checklist says something is missing, verify the actual UI and backend first. If the thing exists, narrow the checklist before coding. That preserves computation time, design sanity, and the Admiral's patience.

2026-07-09 - Import Receipts Need A Copy Button At The Moment Of Trust

Task: Add COPY RECEIPT to the styled MIDI import receipt popup.

What connects creatively: The moment after import is when the user most needs confidence. Letting them copy the exact receipt immediately turns a popup into a durable support artifact, collaborator note, classroom handoff, or QA breadcrumb. This is especially important for MIDI because imported files can contain notes, channels, expression, SysEx, setup rows, and source-map metadata.

Architecture choice: The button copies MidiImportApplyResult::toPlainTextReport() through buildMidiCopyReceipt, so the copied text inherits the same cold-copy safety language as MIDI Health, MIDI AUTO, Protocol Coverage, and package receipts.

Future extensions: Add one-click COPY RECEIPT to every warm MIDI mutation: SysEx recall, hardware setup apply, MIDI Learn map apply, export, and stem package import. A consistent receipt habit is one of the cheapest ways to make advanced MIDI feel safe.

2026-07-09 - Receipts Should Be Model Truth, Not Popup Decoration

Task: Give MIDI import apply results a reusable plain-text report and let the receipt popup render that model-owned text.

What connects creatively: A popup is temporary, but a receipt is evidence. If support, QA, collaborators, and future copy buttons all read the same plainTextReport, the user gets one trustworthy account of what happened: summary, next check, mutation counts, source-map review, actions, and warnings.

Architecture choice: Move receipt prose into MidiImportApplyResult::toPlainTextReport() and serialize it. The UI is now a renderer of model truth, not a second author of import history.

Future extensions: Add a visible COPY RECEIPT button to the styled import receipt panel that copies this exact text through buildMidiCopyReceipt, preserving the same cold-copy safety language used elsewhere in MIDI Health and Protocol Coverage.

2026-07-09 - Import Receipts Should Tell The User Where To Look

Task: Add a concrete next-check summary to MIDI import receipts and show it in the styled receipt popup.

What connects creatively: A receipt is the emotional handoff after a risky action. It should not merely say "applied"; it should point the user to the exact place where confidence is earned: Arrangement lanes, MIDI AUTO, MIDI PATCH, SysEx Vault, warning review, or a re-export round trip. This connects Import Wizard, MIDI Health, support receipts, and hardware safety into one calmer post-action flow.

Architecture choice: Put the wording in MidiImportApplyResult, not only the popup. The UI displays the same model-owned text that support/exported structured payloads can read, so future panels do not have to invent their own receipt advice.

Future extensions: Receipt lines can become direct safe buttons after import: Open MIDI AUTO, Open SysEx Vault, Open Created Lanes, or Copy Receipt. That would turn the current text into guided QA without changing the underlying import model.

2026-07-09 - MIDI Import Preview Needs A Next Test, Not Just A Plan

Task: Add a concrete next-test summary to MIDI Import Apply Preview reports and structured payloads.

What connects creatively: Import is where outside musical reality enters SpaceAge. A preview that only says what it sees still leaves the user wondering what to do next. A Next MIDI import test: line turns the preview into a short flight checklist: warning-heavy files go to disposable targets, setup/SysEx files go through receipts and MIDI PATCH/SysEx Vault review, split-lane files get lane/channel/timing checks, and expression-heavy files lead naturally into MIDI AUTO.

Architecture choice: Keep the next-test wording in MidiImportApplyPreview, beside the same action counts and evidence boundary already used by copy reports. That keeps the Import Wizard, support receipts, MIDI Health language, and future QA scripts from inventing separate advice for the same preview state.

Future extensions: The Import Wizard can render this line as a small footer callout beside COPY REPORT, then later turn it into direct navigation after import: open created lanes, open MIDI AUTO, open SysEx Vault, or open MIDI PATCH review rows depending on the imported evidence.

2026-07-09 - Progress Reports Should Say What Already Works

Task: Split MIDI closeout blocker categories into Usable now and Remaining polish summaries.

What connects creatively: A blocker category can accidentally erase progress if it only says what is missing. MIDI AUTO already has real creative value: selected-pattern lanes, point/ramp drawing, switch blocks, copy/cut/paste/delete, nudge, undo, preview-confirm curve/smoothing/thinning transforms, PTN ownership warnings, and first-pass bend/switch trust cues. Naming those finished affordances beside the remaining polish lets the app report progress without pretending the final editor is already launch-grade.

Architecture choice: Report/model metadata only. The MIDI protocol coverage categories now serialize and print usableNowSummary and remainingPolishSummary, with MIDI AUTO as the first beneficiary. This changes no MIDI storage, MIDI AUTO editing behavior, playback, export, hardware routing, or confirmation policy.

Future extensions: The same split should guide every remaining launch blocker. If a feature has a working first pass, show what can be trusted today, then show the smaller list of work needed before marketing it as finished. This will keep SpaceAge's own reports from feeling like moving goalposts.

2026-07-08 - Hardware Truth Is A Separate Ledger

Task: Keep MIDI closeout reports honest about real external hardware validation.

What connects creatively: The MIDI backend can preserve, route, and report data beautifully, but a physical synth is still a second reality. A user needs to know whether SpaceAge prepared the message, queued it, heard a response, or proved the musical result by listening. Those are different emotional trust states, not just engineering states.

Architecture choice: Add a model-owned real-hardware validation summary to MIDI Protocol Coverage and MIDI Health reports. It counts rows that target hardware/SysEx/clock/transport domains and names categories that still need listening, device-response, test-phrase, or manual-verification evidence.

Future extensions: This can become a guided hardware QA panel: pick a Passport, send a safe test phrase, listen/confirm, capture ACK-style evidence when available, then stamp the lane or device with a visible trust badge.

Design reminder: Never let a dashboard percentage imply an external device accepted, stored, or audibly applied a message. Trust needs evidence.

UI follow-through: The Protocol Coverage popup now gives one of its top cards to HW PROOF ROWS instead of treating future roadmap count as the most important companion to closeout progress. Future MPE/MIDI 2.0 still matters, but external hardware proof is the thing that can make a launch claim feel dishonest if it is hidden.

2026-07-08 - Route Proof Is Stronger Than Route Metadata

Task: Separate "this row has route labels" from "this row opens an exact user-facing surface."

What connects creatively: A breadcrumb can be useful without being a button. If a QA report says Sequencers > MIDI TASKS > Import MIDI..., that is a human path. If it says Open MIDI AUTO, that is a direct panel. Treating both as identical makes the app sound more finished than it is, and it makes testers lose time.

Architecture choice: Add routeProofStatus to MIDI protocol coverage items and have the route audit count direct proof, breadcrumb/manual paths, status-only notes, and unwired routes separately.

Future extensions: Route proof can drive QA automation: direct routes become clickable test targets, breadcrumb routes become guided instructions, and unwired routes become release blockers before a user ever sees a dead button.

Design reminder: A clear breadcrumb is honest. A fake door is not.

2026-07-08 - Route Kind Is Part Of Trust

Task: Add route-kind metadata to MIDI closeout routes.

What connects creatively: A route is not just a label. Open MIDI AUTO is a direct panel. Sequencers > MIDI TASKS > Import MIDI... is a menu path. A roadmap note is status-only. Those differences matter because a tired tester or future customer should know whether the app is opening a door for them or giving directions to a door.

Architecture choice: Store routeKind beside actionSurfaceId and actionLabel on MIDI protocol items and blocker categories. The route audit now counts direct panels, menu paths, breadcrumbs, status-only notes, and unknown routes instead of merely checking that strings are non-empty.

Future extensions: Use route kind to decide button visuals, safe-door tooltips, guided QA scripts, and automated release checks. Direct panels can be tested by click automation; menu paths need instruction validation; status-only rows should never pretend to be actionable controls.

2026-07-08 - MIDI Routes Should Be Human Doors First

Task: Make MIDI closeout reports name the user-facing route before exposing internal route IDs.

What connects creatively: A QA checklist should behave like stage directions, not like a debugger. If the next action is import validation, the user needs to see Sequencers > MIDI TASKS > Import MIDI..., not midiImportWizard. The internal route ID is still useful for support and future automated routing, but it should be secondary.

Architecture choice: Keep actionSurfaceId as the internal safe-door key, but make copied QA sessions and route labels prefer the visible menu/button path. This preserves the existing navigation model while making the report more usable for real beta testing.

Future extensions: Add route-kind metadata (directPanel, menuPath, pageBreadcrumb, statusOnly) so the app can audit whether a closeout route is a true opener or only a breadcrumb. That would let MIDI Health warn us before a report says a route is ready when it only lands on a broad page.

2026-07-08 - MIDI Health Should Not Hide Automation Readiness

Task: Surface MIDI AUTO editor-readiness and operation coverage in MIDI Health, not only in copied reports.

What connects creatively: A musician should not need to copy a support report to understand whether MIDI AUTO is ready enough to trust. The same model that names guarded point edits, grouped edits, drawing/block workflows, preview-confirm transforms, review-only setup boundaries, and remaining polish can also drive the dashboard. This connects MIDI Health, MIDI AUTO, Hardware Passport bend trust, export-readiness thinking, and beta-test triage into one shared status vocabulary.

Architecture choice: Added reusable MidiExpressionProjectSummary summaries for operation coverage and launch readiness, then wired a compact AUTO OPS row into MIDI Health. The change is reporting/UI-model only: MIDI storage, editing gestures, playback, export, routing, and hardware behavior are unchanged.

Future extensions: Use the same readiness summaries to color a MIDI AUTO launch badge, drive QA-session checklists, and eventually show per-lane ready, needs TEST BEND, review only, or future polish chips inside the automation editor itself.

2026-07-08 - MIDI AUTO Operation Coverage Should Be Reportable

Task: Add a model-owned MIDI AUTO editor operation coverage checklist to MIDI project reports.

What connects creatively: An editor can be powerful and still feel unfinished if nobody can name what it safely does. MIDI AUTO already has guarded point edits, group moves, paste collision checks, drawing, switch/block workflows, and preview-confirm transforms. Putting that operation coverage into the report turns buried code capability into customer/support confidence.

Architecture choice: Keep the operation list in one shared MIDI model helper and reuse it in structured project summaries. This avoids letting PluginEditor status strings, copied reports, Health payloads, and docs drift into separate versions of the truth.

Future extensions: Use the same pattern for Instrument Bay, Effects Rack, Quasar, synth patch editors, and future VST hosting: every complex workbench should have a small model-owned coverage summary that says what operations are available, what is guarded, and what remains launch polish.

2026-07-08 - Progress Labels Need To Name The Kind Of Truth

Task: Tighten MIDI Protocol Coverage wording so blocker means customer-facing closeout work, not a backend MIDI regression.

What connects creatively: SpaceAge now has several kinds of truth: backend protocol capability, visible workflow confidence, and real-world hardware validation. A progress meter that collapses those into one number creates needless anxiety and bad product decisions. The label has to tell the user whether they are looking at parser/routing maturity, GUI readiness, or external-device proof.

Architecture choice: Keep the live Protocol Coverage panel as the source of truth for current MIDI 1.0 closeout, but label remaining blockers as customer-facing closeout blockers. This leaves room for the backend foundation to be high-90s while still admitting that surfaces such as MIDI AUTO, SysEx, import/export, and hardware setup need launch-grade validation.

Future extensions: Use the same labeling discipline for synth readiness, effects readiness, SoundFont/Quasar readiness, and future VST support: separate "engine works," "workflow is ready," and "field-tested with real users/hardware."

2026-07-08 - Pattern Data Needs Lane Context To Become Musical Truth

Task: Let MIDI AUTO pitch-bend trust reflect the selected Arrangement clip's real lane destination when possible.

What connects creatively: A PTN can be reused in more than one lane, so the raw MIDI expression data should not pretend to own its final meaning. Pitch bend is the clearest example: the same 14-bit curve can become a two-semitone slide, a twelve-semitone dive, or hardware chaos depending on the destination. The pattern stores the gesture; the lane supplies the instrument, route, Hardware Passport, and bend-range trust.

Architecture choice: Keep pattern summaries available for pattern-only contexts, but add a clip-contextual summary path for MIDI AUTO. When the user opens automation through a real Arrangement clip, SpaceAge can enrich the expression lane with route target, Passport, declared bend range, and manual TEST BEND verification without polluting the raw MIDI event list.

Future extensions: This same pattern should guide clip decorations, Motion Clips, hardware CC automation, VST automation, and future MPE zones: the clip/pattern owns the gesture, while the lane/device context owns how that gesture becomes sound.

2026-07-08 - Painters Should Not Invent Product Truth

Task: Consolidate MIDI AUTO pitch-bend destination, trust, and curve-span cues so they read the same contextual expression-summary fields.

What connects creatively: A UI painter should draw attention, not quietly decide meaning. If the row painter, selected-lane strip, copied report, and structured payload each query hardware and routing independently, they can drift apart and make the app feel haunted by contradictory microcopy. The better pattern is to let the model/report layer carry the truth, then let every surface render that truth in its own size and style.

Architecture choice: MIDI AUTO's pitch-bend helpers now consume the lane summary's context fields for destination, Hardware Passport, declared range, and verification state. The UI still formats short badges and longer report sentences differently, but the underlying facts come from one place.

Future extensions: Apply this rule to Instrument Bay, Effects Rack, VST hosting, Quasar package state, and export/render readiness. If a surface needs a warning, it should ask a shared readiness/trust object rather than inventing a new warning from local guesses.

2026-07-08 - MIDI AUTO Bend Trust as a Shared Contract

Task: Move pitch-bend trust wording out of one-off UI copy and into the MIDI expression editor plan.

What connects creatively: Bend data is not the same as bend meaning. A 14-bit curve is universal MIDI data, but the musical interval is owned by the destination instrument. That means the same trust condition should surface in MIDI AUTO, Hardware Passport, export readiness, and future lane badges rather than being rewritten in each panel.

Architecture choice: The shared trustConditionLabel belongs to the expression editor plan, not the painter. The visible selected-lane strip, copied MIDI AUTO report, and structured payload can now agree on the same rule: external bend is trustworthy only after lane, Hardware Passport, declared +/- range, and TEST BEND/manual verification agree.

Future extensions: Promote this same field into Arrangement lane badges and export warnings so a user can see BEND TESTED, BEND RANGE ?, or INTERNAL ONLY before rendering or sending to hardware.

2026-07-08 - Closeout Reports Should Be A Test Map

Task: Make MIDI Protocol Coverage's owner-surface checklist follow release-priority order instead of alphabetical order.

The copied closeout report is not just documentation; it is the checklist a tired human will use when deciding what to test next. If the app sorts owner surfaces alphabetically, it accidentally tells the user that order does not matter. Priority order is better because it lets SpaceAge say, "start here, then move here," using the same blocker model that drives the dashboard.

This pattern should apply to every future readiness report: Instrument Bay, Effects Rack, Quasar, VST hosting, Motion Clips, and true MPE. A report should not merely list facts. It should gently organize attention.

2026-07-08 - MPE-Like Preservation Is A Bridge, Not The Destination

Task: Add a plain-English answer for what is and is not included in the current MIDI pass around MPE and MIDI 2.0.

SpaceAge's current MIDI work should win trust by being precise. Preserving multi-channel pitch bend, pressure, poly pressure, and timbre-style controller data is musically useful now, especially for MIDI guitar, wind controllers, expressive keyboards, imported files, and future hardware workflows. But preservation is not the same as true MPE ownership.

The creative connection is that this boundary actually helps product design. It tells us where the next elegant interface belongs: a future lane/device expression profile that can say Standard Keyboard, MIDI Guitar, Wind Controller, or MPE Zone and then configure channels, bend range, pressure, timbre, and synth response accordingly. Until that exists, the current honest promise is "SpaceAge keeps your expressive MIDI 1.0 data intact and visible."

MIDI 2.0 belongs to the same philosophy. UMP, Profile Exchange, Property Exchange, and higher-resolution controller domains should arrive as a designed layer with receipts, downgrade behavior, and device capability language, not as a marketing badge pasted onto MIDI 1.0 plumbing.

2026-07-08 - Automation Must Be Findable Before It Can Be Powerful

Task: Improve MIDI AUTO discoverability without changing automation behavior.

MIDI AUTO already has serious editing depth, but depth hidden behind a vague label becomes friction. The Piano Roll button and MIDI TASKS menu now make the purpose clearer: this is where PTN-owned automation lanes are viewed and created. The empty-state copy also gives the first-lane recipe directly: choose a type/controller in the CREATE strip, then ADD POINT or DRAW RAMP.

This connects to the larger SpaceAge workflow rule: advanced power should sit one clear click away, not behind detective work. The MIDI AUTO path should become the template for future Motion Clips, clip decoration, tempo-aware effect motion, and hardware CC lanes. If a user can answer "where do I make the line move?" without reading a manual, the feature has a fighting chance to become musical instead of technical.

The same naming also needs to hold across every doorway. The Arranger lane signal menu and workflow spec now say AUTO Lanes / Shared PTN Data..., matching the Piano Roll task menu while warning the user that linked clips share the same automation unless they choose VARIANT. This is a small but important product-design move: a user should not wonder whether AUTO Lanes, MIDI AUTO, MIDI expression, and automation lanes are four different systems, and they should not assume clip-local ownership before that architecture exists.

The create strip now gets real vertical space and a short embedded recipe. That is important because automation creation is not just a button action; it has routing meaning. If a lane is selected, the selected lane wins. If the user clicks CLEAR TARGET, the dropdowns create or target a different lane. That same "selected thing wins until cleared" pattern can later serve Motion Clips, clip decorations, and per-lane modulation without making users re-learn the app.

2026-07-08 - Hardware Passport Is A Contract, Not A Device Response

Task: Make Hardware Setup and Hardware Passport evidence boundaries visible in the panels where users make external-device decisions.

The Hardware Setup Guide and Hardware Passport panels now show visible evidence-boundary strips. This connects the MIDI safety language already present in reports to the places where users actually make hardware decisions. The creative principle is simple: SpaceAge can prepare a route, template, bend range, sync role, timing calibration, or test note, but the external device must still answer through a queue receipt, device response, audible test phrase, or manual verification.

This distinction should guide future hardware UX. A Passport is like a signed instruction card for an external instrument: it says what SpaceAge intends to send and how it intends to interpret that device, but it is not the synth's sworn testimony. That leaves room for future features such as Passport verification badges, per-device test rituals, "last verified with this hardware" timestamps, and setup wizards that teach the user how to prove the path instead of merely hoping the cable is doing what it should.

The same principle now applies to the compact TEST NOTE receipt in the setup guide. The receipt can say the note was queued, but it also tells the user to verify by listening or manual check. This keeps the setup assistant from accidentally making an engineering claim the hardware has not earned yet.

SysEx Vault now uses the same mental model in its visible safety strip. Stored or staged bytes are archive evidence, not restore success. Linking a snapshot to a Passport is bookkeeping; the actual trust moment belongs to device response or manual verification after the hardware has been checked.

2026-07-08 - MIDI PATCH Is The Airlock For Setup Data

Task: Improve MIDI PATCH default guidance so users understand setup-data safety before they select a row.

MIDI PATCH should feel like an airlock between imported MIDI setup messages and real hardware. It can inspect, copy, save recipes, attach Passport metadata, and queue confirmed setup cards, but it should never feel like opening the panel might silently change a synth. The cold/warm/hot model is the right teaching device here because it maps user intent to risk: cold is report-only, warm changes SpaceAge metadata, hot can touch external hardware after confirmation.

This connects MIDI import, Hardware Passport, SoundFont mapping, and future hardware templates. Imported setup data should be preserved with respect, but musical notes and performance curves belong in the sequencer/MIDI AUTO, while hardware-changing intent belongs behind explicit receipts and confirmations.

2026-07-08 - MIDI AUTO Needs To Teach Its Safety Boundary

Task: Improve the customer-facing MIDI AUTO guidance without changing automation data behavior.

MIDI AUTO is powerful enough to feel intimidating if the user cannot tell whether it is editing project data, sending live MIDI, or touching hardware setup. The panel should therefore say plainly that it is a warm PTN-owned automation editor: CC, pitch bend, pressure, sustain, and similar performance curves live here; protected setup messages live in MIDI PATCH; opening or editing this panel does not send MIDI.

This connects directly to the broader MIDI trust architecture. The app should teach by location: MIDI AUTO is for musical motion, MIDI PATCH is for device/setup intent, Hardware Passport is for destination trust, and receipts/verification are where external-hardware truth is earned.

2026-07-08 - Bend Verification Should Be Sticky, But Not Magical

Task: Add a persistent Hardware Passport field for manual pitch-bend range verification, then teach MIDI AUTO and export readiness to report verified versus merely declared bend range.

The important distinction is "SpaceAge queued a safe bend test" versus "the user or device confirmed the external synth bent by the expected musical amount." Those are not the same event. A queue receipt proves the app tried. A manual verification flag proves the human finished the hardware trust ritual.

This connects Hardware Passport, MIDI AUTO, export readiness, and future playback preflight into one trust contract. If a setup card changes the declared bend range, verification must be cleared because the old listening proof no longer applies. The next interface step should expose a deliberate Mark Bend Verified action after TEST BEND, not silently mark verification just because MIDI was sent.

The backend entry point for that UI is now markHardwareMidiProfilePitchBendRangeVerified. It is called only from an explicit TEST BEND follow-up choice after the hardware bend interval has been heard and accepted.

2026-07-08 - Bend Testing Exists, Trust Persistence Is Next

Task: Recalibrate Hardware Bend Range Protocol Coverage language so it credits the first-pass Hardware Passport range and TEST BEND path while keeping persistent trust checks on the closeout list.

The release dashboard should not say "build the road" after the road exists. The better truth is that SpaceAge can prepare a bend test and preserve raw bend data, but it still needs persistent lane/export/playback trust checks and real-device validation before we claim external synth slides are effortless.

This helps prevent duplicated work. The next pass should connect MIDI AUTO bend badges, Hardware Passport range data, export readiness rows, and playback preflight into one reusable "bend trust" contract, rather than rebuilding a second bend-test workflow somewhere else.

2026-07-08 - Sync Policy Is A Promise To Try, Not Proof Of Following

Task: Give Hardware Sync Policy Preview a top-level evidence boundary while preserving specific Clock/transport boundaries for the cases that send or chase timing.

Sync is uniquely easy to overclaim because the app can be perfectly configured and the external device can still be in the wrong mode, on the wrong port, or ignoring transport. The preview should therefore say, "SpaceAge has saved the role and will attempt this behavior," while the trust layer says, "now test the hardware path."

This same shape belongs in future hardware-friendly workflows: clock master/slave setup, Song Position Pointer support, external sequencer chase, and any future plugin-host sync bridge. A role setting is not a performance result; the receipt or the user's ears finish the sentence.

2026-07-08 - Expression Data Is Not Expression Trust

Task: Add MIDI AUTO and hardware pitch-bend evidence boundaries to the reports and structured payloads that summarize expression lanes and bend test phrases.

MIDI AUTO can preserve and edit controller, pitch-bend, pressure, switch, and setup-style data very well, but preservation is not the same thing as musical response. A pitch-bend curve may be perfectly stored as 14-bit MIDI data while the receiving synth interprets it as two semitones, twelve semitones, or something stranger. The report language needs to keep that distinction alive so the user trusts SpaceAge for what it actually knows.

This pattern should be reused anywhere raw protocol data depends on destination interpretation: mod wheel depth, breath response, aftertouch curves, filter CC ranges, RPN/NRPN setup, and future MPE dimensions. SpaceAge should say, "I preserved and prepared this accurately," then invite the user to hear or verify what the instrument did with it.

2026-07-07 - Pitch Bend Needs A Musical Translation Layer

Raw MIDI pitch bend is only a number from 0 to 16383. Musicians think in semitones, slides, scoops, and dives. Showing the raw curve span beside the destination's declared Hardware Passport bend range creates the missing translation layer: "this curve is this wide in data, and approximately this wide in sound for this destination."

This pattern should extend beyond pitch bend. Breath, filter sweeps, expression, velocity-to-filter depth, and future MPE dimensions all need the same bridge from protocol numbers to musical meaning. The best version of SpaceAge should let technical data remain precise while presenting the user with a musically legible consequence.

2026-07-07 - Switch Edges Are Doors Into Regions

Sustain-style MIDI lanes should not feel like scattered controller dots. Each edge is really a door into a block of time: from this edge forward, the pedal or switch is ON or OFF until the next edge. Naming that block context directly in the hover/selection readout makes the editor feel closer to a musical timeline and less like raw protocol surgery.

This same idea can apply later to mute automation, scene changes, pattern mutes, effect bypass automation, and any future binary automation lane. If an event changes a state, show the state region it creates, not only the event itself.

2026-07-07 - Passive Controls Should Announce Armed State

Changing a dropdown can feel like a hidden state change if the user gets no feedback. MIDI AUTO curve shaping is a good example: Smooth, Fast Start, and Slow Start are not destructive by themselves, but they arm the next preview action. Reporting the armed curve mode immediately makes the UI feel deliberate and keeps the no-MIDI/no-hardware safety contract visible before the user clicks APPLY CURVE.

This pattern should be reused anywhere SpaceAge has a "choose mode now, apply later" workflow: arpeggiator rhythm choices, quantize modes, render targets, hardware recall staging, and future automation transform tools. The status line should say what is armed, what the next action will do, and whether it is cold, warm, or hot.

2026-07-07 - Bend Range Is A Visible Contract

Hardware pitch bend is one of those places where SpaceAge can preserve the MIDI perfectly and still disappoint a musician if the destination synth interprets the curve differently. Treating the range as a visible contract lets MIDI AUTO, Hardware Passport, and future lane-level hardware routing all share one mental model: declare the destination range, test it, then trust slides. This same pattern can later help with breath-controller ranges, aftertouch scaling, and any external parameter where raw MIDI data only becomes musical after the receiving device agrees on meaning.

The audit trail needs the same vocabulary as the GUI. Old internal wording like "policy" is useful for code architecture, but customer-facing docs should say "range" or "contract" so hardware setup feels like a clear musical promise: this lane bends by this many semitones on this destination.

This document tracks how new tasks can connect intelligently to existing SpaceAge systems. The goal is to avoid isolated fixes, notice reusable patterns early, and keep the app growing as one coherent instrument instead of a pile of features.

Historical entries before the 2026-07-05 rename may use MIDI EXPR; the current customer-facing entry point is MIDI AUTO.

Historical SysEx entries may use MARK VERIFIED; the current customer-facing label is MANUAL VERIFY.

2026-07-08 - Readiness Reports Should Not Sound Like Results

Task: Add evidence boundaries to MIDI Project Readiness and MIDI Stem Package Inspection reports.

Connections: Readiness reports can accidentally sound like success reports. A project-readiness dashboard can know lanes, mappings, Hardware Passports, SysEx snapshots, and warnings, but it cannot prove a real rig behaved. A package-inspection report can verify manifest shape, file presence, sizes, and checksums, but it has not imported, repaired, or auditioned anything. Keeping those boundaries visible protects users from trusting a clipboard report more than their ears.

Future extensions: The same language should drive future progress meters and import/export dialogs: Inspect, Preview, Confirm, Apply, Verify. Those five verbs would make SpaceAge�s project and collaboration flows feel calm, reversible, and professional.

2026-07-08 - Setup Controllers Need A Hearing Test

Task: Add a shared evidence boundary to RPN/NRPN setup-card summaries, protected channel-mode summaries, guarded setup action plans, and setup queue receipts.

Connections: RPN, NRPN, and protected channel-mode messages are subtle because they look like ordinary CC traffic but can change how an instrument interprets pitch bend, tuning, pressure, omni/poly modes, or vendor-specific parameters. SpaceAge can interpret and stage those messages, and it can queue them through a guarded Hardware Passport path, but only the receiving device can prove the setting landed. The report language now keeps that distinction visible.

Future extensions: Hardware setup cards should eventually offer a small validation ritual after queueing: send setup, play a test phrase, ask the user what happened, and store the result as evidence. That would make bend ranges, NRPN synth controls, wind-controller setup, and QY-style hardware workflows feel teachable instead of mystical.

2026-07-08 - SysEx Archives Are Evidence Bags

Task: Add a stored-SysEx snapshot boundary to raw snapshot and Vault summary reports.

Connections: A SysEx Vault entry is like an evidence bag: useful, preserved, labeled, and reviewable, but not automatically trustworthy. The bytes may still belong to the wrong device, be incomplete, be duplicated, or require a device-specific restore dialect. Naming that boundary directly connects capture, archive, restore, Hardware Passport identity checks, and future librarian features into one calm mental model.

Future extensions: Add device fingerprints, checksum dialects, expected dump counts, and duplicate clustering to promote a stored snapshot from Archived to Likely Match to Verified. The Vault can become one of SpaceAge's strongest hardware-trust features if it keeps this ladder visible.

2026-07-08 - Protocol Coverage Is A Map, Not The Territory

Task: Add an evidence boundary to MIDI Protocol Coverage reports and structured payloads.

Connections: Protocol Coverage is the place where the Admiral naturally asks, "how close are we?" That question deserves a precise answer, not a magic percentage. The dashboard can report tracked MIDI 1.0 family closeout, customer-facing polish, and deferred future protocol work. It cannot prove every controller, interface, external synth, DAW host, SysEx dialect, bend range, timing chain, or MPE-like performance behaves correctly until real hardware paths and real projects are tested.

Future extensions: The dashboard should eventually separate automated self-tests, manual QA recipes, hardware-lab coverage, and customer-beta validation into separate visible rows. That would let SpaceAge say, with confidence, which parts are code-complete, which parts are UI-complete, and which parts are field-proven.

2026-07-08 - Hardware Setup Is A Draft Until The Device Answers

Task: Add one shared Hardware Setup evidence boundary to device templates, previews, test-note plans, apply plans/receipts/diffs, and assistant reports.

Connections: Hardware Setup is where SpaceAge starts to feel like a patient technician helping with a real rig. That makes the trust boundary especially important. A setup template can prepare lanes, channels, Hardware Passports, expression hints, timing guidance, and test-note plans, but none of that proves a MiniNova, QY-70, rack synth, or controller actually accepted the setup. The reports now say plainly that SpaceAge-side preparation is not external hardware truth until queue receipts, device-response evidence, a successful test phrase, or manual verification closes the loop.

Future extensions: This boundary should drive future Hardware Setup UI badges: Draft, Applied In Project, Queued To Hardware, Device Responded, and Manually Verified. The same ladder can later support VST hardware editor profiles, SysEx preset librarians, MIDI guitar/wind-controller onboarding, and school-friendly "connect your keyboard" walkthroughs.

2026-07-08 - Captured SysEx Is Evidence, Not Permission

Task: Add one shared SysEx capture evidence boundary to capture readiness, batch dry-run, capture receipt, and capture progress reports.

Connections: SysEx capture feels authoritative because the bytes are real. But real bytes can still be partial, duplicated, from the wrong device, mislabeled, or unsafe to restore. The capture side now says it proves SpaceAge observed, framed, and staged incoming data for review, while restore trust still needs device identity checks, warnings, byte evidence, and later device-response or manual verification.

Future extensions: A stronger SysEx librarian can build on this by adding device fingerprints, expected dump counts, duplicate clustering, checksum dialects, and per-device ACK/NAK parsing. The core user promise should remain simple: capture is evidence, save is archive, restore is a separate confirmed hardware action.

2026-07-08 - MIDI Learn Is A Mapping, Not A Performance Guarantee

Task: Add a control-mapping evidence boundary to MIDI Learn capture preview/receipt payloads and the MIDI Learn Dashboard report/payload.

Connections: MIDI Learn is easy to misunderstand because the moment a knob is captured, the user expects it to "work." SpaceAge can prove the source was captured, the target was stored, conflicts were resolved or warned about, and pickup/range/curve settings exist. It cannot prove the controller feels musical until the user moves it, listens, checks pickup behavior, and verifies the target response. This is especially important for high-resolution CC pairs, pitch bend as a controller source, inverted ranges, and macro-style one-source-to-many-target mappings.

Future extensions: A great MIDI Maps page should eventually include a guided "wiggle test" for every learned control: move the hardware, watch the target meter, hear the result, and mark the mapping trusted. That same ritual can later help hardware synth controls, VST parameters, touch-screen controls, and automation capture.

2026-07-08 - Collaboration Reports Need A Handoff Boundary

Task: Add explicit evidence boundaries to MIDI import preview, MIDI export readiness, and MIDI stem/package import preview/plan reports.

Connections: Import and export reports sit at the edge between SpaceAge and somebody else's DAW, hardware, or project archive. That edge is useful but not omniscient. Import preview can say what SpaceAge inspected and what it plans to create, preserve, review, or ignore; export readiness can say what SpaceAge can gather from the current project; package inspection can say what appears safe or broken. None of those reports can promise that another DAW, plugin, hardware synth, bend range, or tempo map will interpret the handoff musically until somebody opens, inspects, and auditions it.

Future extensions: This same handoff-boundary language should drive future archive export, project repair, VST preset exchange, Quasar package sharing, SoundFont relinking, and collaborator notes. Every handoff surface should answer three questions: what did SpaceAge inspect, what will change only after confirmation, and what still needs human audition or external verification?

2026-07-08 - Preserve Expressive MIDI Before Claiming MPE

Task: Add explicit evidence boundaries to MPE-like readiness and future MIDI protocol reports.

Connections: SpaceAge can already do something musically valuable with expressive MIDI: preserve and expose MIDI 1.0 pitch bend, pressure, poly pressure, and timbre-style CC data across channels. That is not the same as owning true MPE zones, master/member channel policy, per-note allocation, or MIDI 2.0 transports. Naming that boundary lets us market the honest strength now while keeping the path open for a real future MPE/MIDI 2.0 implementation.

Future extensions: When true MPE arrives, it should not be a checkbox. It needs zone setup, lane/device ownership, per-note channel allocation, pitch/timbre/pressure display rules, export/import contracts, hardware/VST validation, and a way to downgrade gracefully to MIDI 1.0 where needed. The same roadmap discipline applies to UMP, Profile Exchange, and Property Exchange.

2026-07-08 - Timing Calibration Is A Feel Contract

Task: Give MIDI Timing calibration summaries and copied timing preflight reports an explicit evidence boundary.

Connections: Timing is a place where numbers can look more authoritative than they really are. SpaceAge can know its buffer size, sample rate, record-compensation setting, loopback result, and calibration readiness, but the musician still experiences the whole chain: controller, driver, interface, instrument response, audio monitoring, and room. The report now says the data is an estimate until the user records, listens, compares loopback evidence, or manually verifies the path.

Future extensions: This should become the model for live-performance diagnostics: show precise measured facts, then ask for a musical confirmation step. Later, SpaceAge can offer guided "play this, listen back, approve feel" rituals for hardware lanes, SoundFont-heavy projects, Bluetooth warnings, and plugin-host latency compensation.

2026-07-08 - MIDI Health Is A Diagnostic Snapshot, Not Proof Of The Rig

Task: Give the overall MIDI Health report the same evidence-boundary treatment as the specialized MIDI input, output, sync, repair, queue, and SysEx reports.

Connections: MIDI Health is the dashboard a user or support person will naturally trust first. That makes it powerful, but also dangerous if it sounds like a clean health report proves the whole external rig obeyed. The report now says it is a SpaceAge-side snapshot of readiness, visible devices, live gates, sync state, and repair guidance, while hardware truth still depends on test phrases, device-response receipts, recorded-note inspection, listening, or manual verification.

Future extensions: This same wording pattern should become the template for VST/plugin hosting diagnostics, Instrument Bay readiness, sample-library repair, and future collaboration package checks. A dashboard can be confident without pretending to be omniscient.

2026-07-07 - SysEx Batch Planning Should Not Masquerade As Batch Capture

Task: Clarify the SysEx Vault batch surface so it reads as a dry-run planner plus one-dump capture workflow, not as a hidden live batch recorder.

Connections: This keeps the same safety vocabulary we are building across Hardware Passport recall and MIDI PATCH: the feature can help users plan a multi-dump hardware session, but it must not imply that SpaceAge is silently collecting a batch. The one-dump ARM CAPTURE path remains the trusted primitive. Later, true batch capture can reuse the expected count, stage label, remaining dump count, per-dump timeout, and checklist model without changing the user�s mental model.

2026-07-07 - Hardware Passport Recall Needs The Same Button Temperature

Task: Make Hardware Passport recall controls use the same cold/hot safety language as MIDI PATCH.

Connections: MIDI PATCH and Hardware Passport recall are both hardware-facing doors, so they should not teach two different safety dialects. The Hardware Passport buttons now use the same cold/hot framing: copy/report actions are cold because they only place text on the clipboard, while queue actions are hot because they can send Bank Select, Program Change, or SysEx after confirmation. The hot actions also use darker warning-family button colors, connecting the verbal safety contract to the visual one. This keeps the future hardware setup wizard, SysEx librarian, MIDI PATCH cards, and Passport recall surfaces aligned around one simple mental model: cold means observe/copy, warm means learn/prepare, hot means confirmed hardware action.

2026-07-06 - MIDI Closeout Reports Should Point To Workbenches

Task: Make MIDI Protocol Coverage reports and visible MIDI/SysEx labels point to the exact owner surfaces that still need closeout, while avoiding language that sounds like hidden hardware mutation.

What connects creatively: A progress report is most useful when it behaves like a flight checklist. "MIDI AUTO Final Editor" should not just say there is work left; it should tell us the work belongs in MIDI AUTO, what kind of editing still needs to exist, and which creative workflow it protects. Likewise, SysEx labels should make it obvious when the user is opening a Vault or changing SpaceAge metadata rather than sending bytes to a hardware instrument.

Architecture choice: Keep the owner-surface grouping in the MIDI protocol model rather than hardcoding a separate UI explanation. The copied report can now say which surface owns each blocker, while individual buttons/tooltips use calm no-send wording for navigation and metadata actions.

Future extensions: Reuse the same owner-surface checklist style for Instrument Bay readiness, VST/plugin hosting, Quasar capture/export, and Effects rack polish. A report that names the workbench, the blocker, and the first action becomes a task router for both developers and power users. Showing the same owner-surface list in the visible Protocol panel is a useful pattern: the UI can be a control room, not only a place to copy diagnostics.

2026-07-06 - Setup Steps Should Be Doors, Not Homework

Task: Make the MIDI SETUP scenario checklist rows more actionable without turning them into hidden MIDI commands.

What connects creatively: The setup guide is strongest when it feels like a guided cockpit rather than a static diagnostic report. A row that says "choose MIDI input" should be a door into the MIDI Input surface, not a vague instruction the user has to remember. At the same time, hardware actions are trust-sensitive: the guide must never blur navigation with sending notes, applying drafts, recalling programs, or restoring SysEx.

Architecture choice: Keep the row clicks inside the existing MidiSetupGuidePanel, using the same model-owned MidiHardwareSetupAssistantStep metadata and the same safe navigation callbacks as NEXT ACTION. Only rows that map cleanly to existing safe surfaces get an OPEN pill and hover state. Mutating paths such as APPLY DRAFT, TEST NOTE, recall, and SysEx restore remain separate confirmation-gated actions.

Future extensions: Reuse this "safe door row" pattern for SysEx Vault snapshot closeout cards, MIDI Import review choices, Hardware Passport repair cards, and VST/plugin scan repair. If a row only explains status, leave it as text; if it can open the precise safe surface the user needs, make it visibly clickable.

2026-07-05 - Hardware Recall Should Say Queue, Not Send

Task: Align Hardware Passport recall wording with the guarded MIDI send model.

What connects creatively: External hardware recall is one of the moments where wording can either calm the user or make them nervous. If a button says "send," it can sound instant and irreversible. If it says "queue," and the confirmation dialog also says "queue," the user understands there is a deliberate staged action with a receipt.

Architecture choice: Use QUEUE PROGRAM RECALL and QUEUE RECALL + SYSEX on the visible Hardware Passport panel because those controls stage a confirmed action instead of silently firing. Inside the confirmation dialog, the final affirmative button may say SEND PROGRAM RECALL or SEND RECALL + SYSEX so the user understands that accepting the warning can transmit hardware-changing MIDI. The backend remains the same confirmation-gated queue path.

Future extensions: Apply this wording standard to every hardware-affecting action: prepare, queue, confirm, receipt. Reserve "send" for final receipt/log lines where MIDI has actually been transmitted or queued for output.

2026-07-05 - Protocol Coverage Must Echo The Real UI

Task: Keep the MIDI Protocol Coverage model wording synchronized with the newest MIDI PATCH selected-item guidance and the two-scorecard MIDI readiness language.

What connects creatively: The Protocol Coverage panel is becoming SpaceAge's self-diagnosis page. If MIDI PATCH gains safer, clearer behavior but the scorecard still describes the older surface, the app starts contradicting itself. Keeping model-owned report language current makes the dashboard, copied support reports, docs, and release-readiness conversations all point in the same direction.

Architecture choice: Update the model-owned strings in buildMidiProtocolCoverageReport() and scorecardClarification() rather than papering over wording in the editor. The UI should render the model's truth, not maintain a separate marketing version of the truth.

Future extensions: Use this same synchronization habit for Instrument Bay, VST hosting, Quasar, and Effects pages: whenever a visible workflow changes, update the model/report layer that explains the workflow.

2026-07-05 - MIDI PATCH Needs A Cockpit Readout

Task: Make MIDI PATCH setup rows/cards explain their current safety state, next action, and disabled-button reason in place.

What connects creatively: MIDI PATCH is dealing with powerful but dangerous old-school MIDI: Program Change, Bank Select, RPN/NRPN, Local Control, Omni, All Notes Off, and reset-style messages. These are not ordinary musical notes. The user needs cockpit-style guidance, not just a pile of dimmed buttons. A selected-item decision strip turns the panel into a guided hardware workflow: "what is this, what state is it in, what can I do next, and why?"

Architecture choice: Keep the decision strip read-only and derived from existing MIDI model facts: Bank/Program summary readiness, RPN/NRPN setup-card action plans, Hardware Passport NRPN definitions, and protected channel-mode summaries. The strip sends no MIDI, mutates no project state, and does not loosen any queue guards. Its copy should explicitly separate no-send actions such as save/attach/map/copy from confirmation-gated queue actions.

Future extensions: The same decision-strip pattern can become a reusable UI idiom for SysEx Vault restore trust, MIDI Import Wizard choices, Hardware Passport setup assistants, Quasar capture status, and future VST/plugin scan repair.

2026-07-05 - Hardware Passport Needs One Public Name

Task: Clean up the visible MIDI hardware wording so users see "Hardware Passport" consistently instead of bouncing between Passport and Profile.

What connects creatively: A Hardware Passport is not just a saved setting blob; it is the musician-facing identity card for an external synth, drum machine, wind controller, guitar rig, or General MIDI module. If the app says Passport in one place and Profile in another, the concept feels like two separate systems. Keeping one public name makes the guided hardware workflow feel more like a trusted setup companion.

Architecture choice: Keep the backend class/function names stable for now, because a broad HardwareProfile refactor would be expensive and risky during MIDI closeout. Change only visible labels, buttons, picker placeholders, and status messages to "Hardware Passport." The implementation can be renamed later when the behavior is fully settled.

Future extensions: The Hardware Passport surface should eventually become the launch point for device identity, port selection, channel policy, pitch-bend range, timing calibration, SysEx snapshots, safe RPN/NRPN definitions, and hardware-specific setup recipes.

2026-07-05 - Setup Payload Must Not Sneak Into Playback

Task: Continue MIDI protocol closeout by separating review-only setup payload from performance expression during playback, MIDI export, and export/readiness reports.

What connects creatively: A MIDI import can contain musical gestures and device instructions in the same file. SpaceAge should be smart enough to preserve both without treating them as the same kind of musical object. A CC11 swell belongs in the song. A Bank Select, Program Change, or RPN/NRPN setup card belongs in a deliberate hardware setup/recall workflow. Keeping those apart protects external synths and makes SpaceAge feel like a careful studio assistant instead of a mystery box.

Architecture choice: Leave midiExpressionEvents broad enough to preserve imported/recorded setup payload for review, but make live scheduling, MIDI-file export, and export/readiness expression counts use the editable performance-expression gate. That means CC performance lanes, pitch bend, pressure, sustain, pan, volume, and similar gestures can play/export normally, while Bank/Program/RPN/NRPN/Data Entry stays visible for MIDI PATCH / Hardware Passport work until the user explicitly queues or recalls setup.

Future extensions: Rename or split the storage model later so the code vocabulary mirrors the user model more cleanly: performanceExpression versus setupPayload. Also add a dedicated "include setup recall at song start" export option only after it has confirmations, receipts, and Hardware Passport policy.

2026-07-05 - Hardware Bend Tests Need Receipts, Not Magic Buttons

Task: Add a confirmed backend receipt path for the Hardware Passport pitch-bend test phrase.

What connects creatively: A bend-test phrase is really a trust ceremony between SpaceAge and a piece of external hardware. The user is not just pressing a button; they are proving that a curve in the app means the same musical interval on the synth across the room. Turning that gesture into a receipt makes the process feel calm, auditable, and teachable instead of spooky.

Architecture choice: Keep the descriptive test plan in the MIDI model, but put the hardware-affecting queue action in the processor where it can recheck the Hardware Passport, require explicit confirmation, use the hardware output router, log each attempted message, and state exactly what was not sent. The receipt path sends only note/pitch-bend test messages; Program Change, Bank Select, SysEx, MIDI Clock, transport, and reset traffic stay out of the gesture.

Future extensions: MIDI PATCH now renders this as a TEST BEND / BEND INFO action with the same receipt style as setup cards, recall, SysEx restore, and future MPE zone validation. The same pattern can also power per-string MIDI guitar bend tests, wind-controller pressure checks, and "does this external device understand what SpaceAge thinks it understands?" setup assistants.

2026-07-05 - Import Receipts Should Prove Undo Trust

Task: Make MIDI stem-package import receipts report whether the project changed and whether undo protection exists.

What connects creatively: Importing a package is a collaboration moment: someone hands you a bundle, SpaceAge opens it, and the user needs to know whether their song was touched. A clear receipt turns a potentially scary mutation into a reversible action with evidence. This same pattern belongs in archive import, recovery restore, SoundFont relocation, future VST scan repair, and any workflow where SpaceAge changes a project on the user's behalf.

Architecture choice: Keep planning receipts honest by not claiming actual mutation. The processor-owned confirmed import path alone sets projectMutated and undoCheckpointCreated after lane stems are created under the package-import checkpoint. The receipt exposes those facts in plain text and structured payloads so UI, tests, support bundles, and future progress dialogs do not invent separate truth.

Future extensions: Add the same undo-safety proof line to archive import, missing-asset repair, arrangement form presets, batch MIDI import, and future multi-file render/import workflows. If an action is big enough to make a user nervous, it deserves a receipt that says what changed and how to undo it.

2026-07-05 - Hardware Bend Range Belongs In The Passport

Task: Add a structured Hardware Passport pitch-bend range policy instead of leaving destination bend range buried in setup-card notes.

What connects creatively: Pitch bend is one of the places where a technically correct MIDI file can still feel wrong to a musician. A curve that bends two semitones internally may bend twelve semitones on a hardware synth, or the reverse. By saving the destination's declared semitone/cents range in the Hardware Passport, SpaceAge can make slides, guitar-style bends, wind-controller gestures, and hardware export/readiness checks feel honest instead of mysterious.

Architecture choice: Store pitch-bend range as MIDI-native semitones plus cents on HardwareMidiProfile, surface it through HardwareMidiProfileSummary, and auto-fill it when a reviewed RPN 0,0 Pitch Bend Range setup card is attached to the profile. Do not parse the notes receipt as source of truth.

Future extensions: This should feed hardware setup assistants, MIDI guitar/string bend checks, MPE zone policy, external synth export warnings, and eventually a per-lane "bend target" display that compares internal clip bends against the selected hardware or instrument destination.

2026-07-05 - Guarded RPN Queueing Needs One Story

Task: Align the MIDI protocol reports and docs around the current RPN/NRPN queue policy.

What connects creatively: Hardware setup is powerful, but it is also where trust can evaporate if SpaceAge says one thing in a report and does another in a button. RPN Pitch Bend Range is useful enough to queue after confirmation; unknown NRPN and channel-mode commands are dangerous enough to keep guarded. The creative opportunity is to make hardware feel approachable without pretending hardware setup is ordinary knob doodling.

Architecture choice: Treat complete standard RPN cards as confirmed queue candidates, NRPN cards as queueable only when a Hardware Passport explicitly defines them as safe, and protected channel-mode/reset rows as copy-only until a separate policy exists. Keep this wording model-owned so MIDI PATCH, Protocol Coverage, support reports, docs, and future setup assistants describe the same behavior.

Future extensions: Hardware Passports should grow into device dictionaries with named RPN/NRPN meanings, default ranges, safe send policies, and restore receipts. Once that exists, the same card model can power guided MiniNova/QY/XG setup, MIDI guitar bend-range checks, and eventually MPE zone policy.

2026-07-05 - Pitch Bend Needs A Visible Range

Task: Continue MIDI protocol closeout by making MIDI AUTO show whether pitch bend is using the default range or an RPN-learned range.

What connects creatively: Raw pitch-bend data is precise but not self-explanatory. A musician sees a curve and hears an interval; if those do not match because the destination range is different, the app feels haunted even though the data is technically preserved. Showing INTERNAL DEFAULT or INTERNAL RANGE ... from RPN turns a hidden protocol assumption into a readable part of the musical cockpit.

Architecture choice: Keep the live per-channel bend range in the processor, mark it as observed only after standard RPN 0,0 plus Data Entry updates it, and let the MIDI AUTO graph ask the processor for one summary string. That avoids hardcoded editor guesses while keeping the hardware warning honest: external targets may still differ until Hardware Passports own destination range policy.

Future extensions: Hardware Passports should eventually declare expected bend range per device/patch, MPE zones should negotiate or display member-channel bend policy, and future pitch-slide tools should show musical semitone targets instead of only raw 14-bit values.

2026-07-05 - Protocol Completion Needs A Cockpit Checklist

Task: Continue MIDI protocol closeout by making the Protocol Coverage panel more directly actionable.

What connects creatively: A percentage dashboard is useful for us, but a musician or product owner needs a "what do we do next?" surface. The MIDI Protocol Coverage report already computes blocker categories, release roles, and first actions. Surfacing that as a visible closeout list turns the panel into a cockpit checklist instead of a passive scorecard.

Architecture choice: Reuse MidiProtocolCoverageReport::currentFinishLineCloseoutChecklist() as the source of truth. The panel now shows a compact checklist card and offers COPY CLOSEOUT for a short action list, while COPY REPORT still captures the full diagnostic report. This avoids a second hand-maintained status model.

Future extensions: The same pattern belongs in other trust-heavy areas: render/export validation, hardware setup, missing asset repair, preset packaging, and future VST scanning. Any place with scary technical state should have both a compact closeout checklist and a full support report.

2026-07-05 - Release Wording Is Part Of The Safety System

Task: Make the MIDI protocol report carry a release wording audit checklist.

What connects creatively: MIDI is both a technical promise and a marketing promise. A backend can preserve SysEx, bend, pressure, and CC data while the product still must avoid saying "MIDI complete" or "MPE-ready" too early. Treating wording as a model-owned checklist makes honesty part of the app architecture, not just a doc habit.

Architecture choice: Add MidiProtocolCoverageReport::releaseWordingAuditChecklist() beside the closeout checklist. The copied protocol report and JSON payload now carry the same truth boundaries: current UI doorway is MIDI AUTO, current expression is pattern-owned, SysEx restore receipts are visible but not fully device-specific, MPE/MIDI 2.0 is deferred, shared effects are not lane-owned sends, and broad completion claims stay forbidden.

Future extensions: Other areas should get the same protection: VST hosting, SoundFont compatibility, export/archive promises, AI helpers, hardware recall, and future collaborative/cloud features. If a feature has a claim that could embarrass us later, it deserves a wording-audit row near the code that actually knows the feature state.

2026-07-05 - MIDI Input Proof Should Refresh Without Erasing Evidence

Task: Make the focused MIDI Input panel useful during real-controller proof tests while it is already open.

What connects creatively: The MIDI Input panel is becoming a stage-tech surface: "play one note and I will tell you what SpaceAge heard." If that panel only updates when the user clears observed input, it turns proof-of-life into a self-defeating ritual. Refreshing without erasing preserves the emotional arc: play, check, trust.

Architecture choice: Add a CHECK INPUT action that re-reads the model-owned input readiness report, device inventory, and repair recommendations without calling resetObservedMidiInputChannels(). COPY REPORT also refreshes first so copied support text reflects the newest host/direct counters, observed channels, and repair guidance.

Future extensions: The same proof-refresh pattern belongs in future hardware setup assistants: test note, timing pulse, SysEx handshake, and MIDI expression calibration should all update their evidence receipts without destroying the evidence they just gathered.

2026-07-05 - MIDI Repair Text Must Share The Same Truth As Routing

Task: Continue MIDI closeout by checking whether source-policy diagnostics match the implemented host/direct input router.

What connects creatively: Troubleshooting copy is part of the instrument. If SpaceAge blocks host MIDI because DIRECT ONLY is active, the user should not have to infer that from counters. The repair card should say the plain thing: "DIRECT ONLY is ignoring host/plugin MIDI." That lets MIDI setup feel like a guided cockpit instead of a packet analyzer.

Architecture choice: Keep one source of truth for policy identity. The processor persists/report ids as strings (autoPreferDirect, hostOnly, directOnly, hostAndDirect), so model-layer repair recommendations now compare those string ids and self-test the resulting repair prose. This prevents the backend and customer-facing Health panel from drifting apart.

Future extensions: The same pattern should be reused for hardware setup proof tests. When SpaceAge asks the user to play a note, it can show whether the note arrived through host MIDI, direct MIDI, both, or neither, then offer the correct policy fix without making the user understand routing internals.

2026-07-05 - MIDI AUTO Is The Surface, MIDI Expression Is The Material

Task: Continue the MIDI closeout by tightening customer-facing language around the selected-pattern automation/expression editor.

What connects creatively: Names are part of workflow. MIDI AUTO should be the button/surface the user remembers, while "MIDI expression" describes the underlying musical material: CCs, pitch bend, pressure, sustain, and similar performance data. Keeping those separate prevents the interface from feeling like it has multiple half-overlapping MIDI editors.

Architecture choice: Current model-owned protocol reports, setup scenario actions, expression editor plans, and project expression reports now point to MIDI AUTO when they mean the visible editor. They still use "MIDI expression" where the sentence is about stored protocol/performance data.

Future extensions: When true Arrangement automation lanes arrive, they should get their own name and storage contract rather than silently absorbing MIDI AUTO. That preserves the current honesty rule: today this is selected-pattern data, tomorrow clip-local/lane-local automation must be a deliberate new model.

2026-07-05 - MIDI Source Policy Should Produce Repair Cards

Task: Continue MIDI protocol work by turning the new host/direct input policy into MIDI Health repair guidance, not just passive telemetry.

What connects creatively: MIDI routing confidence should feel like the Arrangement lane model: if SpaceAge knows the user's route is ambiguous, it should point to the exact control that resolves it. A source policy that only counts suppressed messages is useful for us, but a source policy that says "choose AUTO, HOST ONLY, DIRECT ONLY, or BOTH for this reason" is useful for a musician under pressure.

Architecture choice: Add adjustInputSourcePolicy as a model-owned MIDI repair recommendation kind. Duplicate host-plus-direct acceptance now creates a high-severity repair card, and policy-based suppression creates a lighter repair card that explains whether SpaceAge is intentionally blocking host or direct traffic. The action opens MIDI Input setup through the existing repair-action path.

Future extensions: The hardware setup wizard can reuse this recommendation when it runs a "play one note now" proof test. If the app sees both host and direct sources, it can offer a one-click policy choice instead of making the user interpret counters.

2026-07-05 - MIDI Source Policy Beats Hidden Doubles

Task: Continue MIDI protocol work by turning host-versus-direct live input handling into an explicit policy instead of an invisible side effect.

What connects creatively: This is the same design principle as SpaceAge's one-instrument-per-lane rule: when two paths can both be valid, the user needs an obvious ownership rule. A MIDI controller can arrive through the host/plugin stream and SpaceAge's direct physical router at the same time. Rather than asking a musician to diagnose doubled notes by ear, SpaceAge should say which path it is listening to and which path it is blocking.

Architecture choice: Keep the shared armed-lane live MIDI handler, but insert a source policy before channel/device filtering. AUTO keeps host MIDI normal until direct physical traffic is observed for a lane-selected device, then suppresses host-stream musical messages. HOST ONLY, DIRECT ONLY, and BOTH make the behavior explicit. The Settings MIDI Input report now shows the policy and suppression counts.

Future extensions: A hardware setup wizard can use this policy as a guided step: "Are you using SpaceAge Standalone, a plugin host, or both?" The same pattern can support future MPE devices, MIDI guitar rigs, wind controllers, and loopback calibration where duplicate paths are easy to create accidentally.

2026-07-05 - Duplicate MIDI Input Should Be A Visible Risk

Task: Continue the MIDI input work by making SpaceAge report whether live MIDI is arriving through the host/plugin stream, the direct physical-input router, or both.

What connects creatively: Controller setup gets confusing fast when the same keyboard is enabled in two places. A user might hear doubled notes, latency, or strange recording density and assume the synth is broken. The better SpaceAge answer is: "I can see both paths. Here is the evidence." That turns a spooky MIDI problem into a visible routing choice.

Architecture choice: Keep one live MIDI handler, but count host-stream and direct-input musical messages separately before they enter the shared armed-lane path. MidiInputReadinessReport now carries direct open-input ids, dropped direct-input count, observed host/direct message counts, and a duplicate-input risk note. Settings MIDI Input, MIDI Health, and lane routing can all quote the same processor-owned report.

Future extensions: Add an explicit "Prefer SpaceAge Direct Input / Prefer Host Input" policy, real-controller validation with loopback-style listening, and a guided warning when the same controller is selected both in a host wrapper and in SpaceAge's direct lane input selector.

2026-07-05 - A Scorecard Must Be Browsable

Task: Make the MIDI Protocol Coverage panel show all protocol-family rows instead of stopping at a +N more footer.

What connects creatively: The MIDI dashboard is becoming SpaceAge's trust instrument: it tells us and the user what is safe, what is implemented, and what remains unfinished. A trust instrument cannot hide the lower half of its own report. If the panel is the source of truth, every row needs to be reachable without copying text to a clipboard.

Architecture choice: Keep the report model unchanged and add a local mouse-wheel row offset to the Protocol Coverage panel. The visible list now scrolls through the existing MidiProtocolCoverageReport::items and displays a "showing X-Y of N" footer. This keeps the UI lightweight while making the whole scorecard inspectable.

Future extensions: This scrolling report pattern can be reused for future health dashboards: MIDI Maps conflicts, SysEx restore history, hardware setup receipts, import warnings, and export validation. Anywhere SpaceAge has an authoritative report, the user should be able to browse it directly before reaching for support copy.

2026-07-05 - MIDI Setup Policy Belongs At The Decision Point

Task: Make the MIDI PATCH queue rules visible in the panel itself instead of relying on tooltips and copied reports.

What connects creatively: SpaceAge has a strong safety model for hardware setup data, but a user should not have to discover that model by trial, memory, or fear. RPN, NRPN, and channel-mode/reset messages all look like "MIDI setup stuff" at first glance, yet they have different risk profiles and different allowed actions.

Architecture choice: Add a compact queue-policy strip under the existing safe-by-default banner. The strip states the three rules where the user is deciding what to do: RPN cards can queue after confirmation, NRPN cards require a queue-safe Hardware Passport definition, and channel-mode/reset rows remain copy-only and never queue from MIDI PATCH.

Future extensions: This same pattern should appear anywhere SpaceAge handles potentially hardware-affecting material: visible policy first, explicit confirmation second, copyable receipt third. It is a reusable trust pattern for SysEx restore, Hardware Passport recalls, controller maps, and future external plugin/hardware templates.

2026-07-04 - Restore Receipts Need A Visible Trail

Task: Make recent SysEx restore-verification receipts visible inside the SysEx Vault instead of requiring the user to copy a report.

What connects creatively: Hardware recall is a trust workflow. A musician needs to see the difference between "SpaceAge queued bytes," "the device acknowledged," "I manually verified it," "the device rejected it," and "the device stayed silent." Those are not decorative details; they are the memory of whether an external instrument is actually in the expected state.

Architecture choice: Reuse the existing SysExRestoreVerificationReceipt data. The Vault now renders a compact restore-history card with the latest receipts, success/warning color, receipt kind, snapshot name, trust label, and safety label. This adds confidence without sending MIDI, changing SysEx storage, or inventing device-specific response dialects prematurely.

Future extensions: The same receipt trail can grow into Hardware Passport restore history, retry guidance, per-device response parsers, backup/restore checklists, and support bundles. It also reinforces a larger SpaceAge rule: if an operation touches hardware confidence, the user should see a receipt trail.

2026-07-04 - MIDI Truth Labels Must Track Reality

Task: Clean up MIDI PATCH and MIDI Protocol Coverage language after recent SysEx and setup-card work.

What connects creatively: Hardware-facing MIDI is not just a feature set; it is a trust contract. A phrase like "review only" is useful until a safe confirmed queue path exists, and misleading after that. Likewise, the coverage panel should not keep calling visible restore history "future work" once the Vault displays restore receipts.

Architecture choice: Keep the conservative behavior but tighten the language. RPN/NRPN setup cards now present as "review first, confirm before queue," protected channel-mode rows still say copy-only/no-send, and SysEx librarian blockers now point to deeper filtering/export and device-specific polish rather than the already implemented visible receipt trail.

Future extensions: This same audit should happen whenever a MIDI surface graduates from backend-ready to customer-facing. Coverage text, button labels, copied reports, tooltips, and docs should move together so users never have to reverse-engineer what is truly safe.

2026-07-04 - Expression Points Should Move Like Notes

Task: Let MIDI EXPR points move in time by mouse drag, not only by keyboard nudging.

What connects creatively: Continuous MIDI expression is musical material, just like Piano Roll notes, Chord Markers, and Arrangement clips. If the user can see a pitch bend, mod wheel sweep, pressure point, or CC curve, they should be able to grab it and move it with the same physical confidence they use elsewhere in SpaceAge.

Architecture choice: Reuse the existing guarded expression-event mutation rules instead of adding a special-case editor path. A single point can now drag left/right for timing and up/down for value through one atomic processor helper; a lasso-selected group can drag horizontally together through the existing collision-aware group move helper. Shared-pattern protections, setup-lane review locks, stale-event checks, undo checkpointing, and collision refusals stay intact.

Future extensions: This is the bridge toward a true Piano Roll-grade expression lane: larger graph lanes, curve handles, switch blocks, pressure badges, bend-range ownership, and eventually Motion Clip editing can all inherit the same idea that visible musical control data is directly manipulable.

2026-07-04 - Readiness Should Listen To Receipts

Task: Feed SysEx restore-verification receipts into the SysEx Librarian readiness plan.

What connects creatively: The SysEx Vault, MIDI Health, and future Hardware Passport history all describe the same musical trust question: did the hardware receive what SpaceAge tried to restore? If the readiness model only reads stored snapshot summaries, it can know byte counts and estimated timing but miss the human or device evidence that was recorded later.

Architecture choice: Widen the readiness builder so it can accept receipt evidence without breaking older call sites. The model now counts device ACK, manual verification, timeout, and device rejection receipts, folds successful ACK/manual coverage into restore progress, and changes the next-action label when timeout or rejection evidence exists.

Future extensions: This gives Hardware Passports a cleaner path toward per-device restore history: stored dumps, transfer estimates, actual responses, manual confirmations, failed attempts, and retry notes can all become one coherent trust timeline instead of separate reports.

2026-07-04 - Shared Patterns Need Locked Doors, Not Just Warning Signs

Task: Tighten MIDI EXPR so shared-pattern expression edits are visibly blocked until the user chooses MAKE VARIANT or ACK SHARED.

What connects creatively: Arrangement clips and MIDI expression are both pattern-scoped right now. That is powerful, but it creates a classic clone-versus-variant trap: a user may think they are editing one clip's mod wheel or pitch bend when they are actually editing every linked use of that pattern. The backend already refused unsafe edits, but the better product move is to make the buttons themselves tell the truth before a click happens.

Architecture choice: Keep the command-level shared-pattern guards as the real safety net, then mirror that state in the button enable/tooltip layer. This gives mouse users, keyboard users, and future touch/control-surface users the same rule: either make the clip a Variant for local expression or explicitly acknowledge that the expression edit applies to every linked clip.

Future extensions: This same lock/unlock pattern should apply to Piano Roll note edits, Chord Engine edits, Motion Clips, automation lanes, and any future "linked clip" data. Clone/Variant is only trustworthy when the interface prevents accidental mutation at the moment of intention.

2026-07-04 - Verification Receipts Are Evidence, Not Features

Task: Clean up SysEx restore-trust wording after adding manual verification, timeout receipts, and response clearing.

What connects creatively: A musician restoring a hardware synth patch needs to know whether the hardware answered, whether the human verified it, or whether SpaceAge is only estimating bytes and pacing. The wording must never imply that a capability is missing when the real situation is simply that no receipt has been recorded yet.

Architecture choice: Keep the receipt vocabulary conservative: device ACK, device NAK, timeout, manual verification, and no verification are distinct states. Reports now say "no device ACK receipt recorded" and "manual receipt recorded yes/no" instead of treating the receipt layer as ready/not ready.

Future extensions: When the Hardware Passport restore history matures, this same evidence language can power per-device trust timelines: what was sent, what answered, what timed out, what the user manually confirmed, and what remains estimated-only.

2026-07-04 - Future Protocols Need A Clean Border

Task: Make MIDI Health state the MIDI 2.0/UMP/Profile Exchange boundary as clearly as the MPE boundary.

What connects creatively: SpaceAge can be ambitious without being vague. The app already preserves and edits a great deal of MIDI 1.0 expression, setup, sync, and SysEx data, but MIDI 2.0 is a different protocol layer. Naming that border directly protects trust: musicians see what is solid now, what is intentionally deferred, and why future support will be added as a designed system rather than a label pasted over MIDI 1.0 plumbing.

Architecture choice: Add MidiFutureProtocolPolicy to the shared MIDI Health model. It serializes the non-active states for MIDI 2.0 transport, UMP packets, Profile Exchange, Property Exchange, and higher-resolution controller domains, then lists the future work needed before SpaceAge can honestly claim support.

Future extensions: This object can become the seed of a true MIDI 2.0 compatibility panel later: device capability discovery, profile negotiation receipts, property exchange logs, downgrade rules for MIDI 1.0 devices, and support-ready labels for controllers, hardware synths, plugins, and exported packages.

2026-07-04 - Live Hardware Lanes Need A Visible Setup Policy

Task: Make external MIDI output readiness explain what happens to live setup-style MIDI messages.

What connects creatively: Hardware trust depends on restraint. A user should feel that live playing can be expressive and immediate, but that SpaceAge will not quietly throw Bank Select, Program Change, RPN/NRPN, Local Control, Omni, or mode-change traffic at a synth just because those messages exist in a stream.

Architecture choice: MidiExternalOutputReadinessReport now owns a compact setup-policy label plus detailed policy lines. The visible MIDI Output Preflight panel shows the headline, while copied reports carry the full rule: performance and safety messages can pass live; setup cards require MIDI PATCH, Hardware Passport, or confirmed recall action.

Future extensions: The same policy text can become a hardware setup wizard guardrail, a MIDI recording/import warning, and a per-lane "allow live setup messages" expert mode if we ever decide such a risky feature is justified.

2026-07-04 - Timing Calibration Must Become Active Compensation

Task: Make Hardware Passport timing calibration apply to the current MIDI recording session instead of only saving a number.

What connects creatively: Calibration is a promise. If a user measures round-trip timing, SpaceAge should not make them manually copy that value into another slider before the performance improves. The best workflow is receipt plus behavior: store the measurement where it belongs, then immediately let the session benefit from it.

Architecture choice: The MIDI Timing panel now receives a small session-apply callback. APPLY COMP and ACCEPT RETURNED still save MidiTimingCalibrationRecord data to the selected Hardware Passport, but they also push the suggested record-compensation value into the live REC LATENCY COMP processor setting and Settings slider.

Future extensions: This pattern should guide Hardware Passport setup cards, SysEx restore verification, MIDI clock offset, external plugin latency, and future MIDI device wizards: every measured value should have a clear owner, a receipt, and an obvious "now active" state.

2026-07-04 - Dangerous Little MIDI Messages Need Calm Cards

Task: Give protected channel-mode/reset MIDI messages a structured review model instead of leaving them as plain-text patch setup rows.

What connects creatively: Some of the smallest MIDI messages have huge real-world consequences. Local Control Off can make a hardware synth feel broken, All Sound Off can silence a device, and Omni/Mono/Poly mode can change how a whole rig receives notes. Treating these as calm, named review cards makes SpaceAge feel like a responsible hardware companion instead of a DAW that casually flings ancient commands at expensive gear.

Architecture choice: RPN/NRPN setup groups already had a card model; protected channel-mode/reset messages now get their own sibling model. They are counted, serialized, displayed in the import preview when relevant, and marked as explicit-confirmation review data. No automatic send behavior was added.

UI follow-through: MIDI PATCH now gives these protected rows their own selectable, copy-only cards. This matters because the same panel can queue confirmed RPN/NRPN cards; without a separate visual class, a user could reasonably assume every setup card is queueable. The UI now teaches the rule directly: RPN/NRPN can become hardware setup actions, protected reset/mode rows are receipts until a future dedicated confirmation workflow exists.

Future extensions: The same card model can become the Hardware Passport "apply setup" checklist: show what will change, ask for confirmation, pace the send, then produce a receipt. It also connects to SysEx Vault restore receipts and future hardware setup templates for MiniNova, QY-series, GM/XG modules, MIDI guitar rigs, and wind controllers.

2026-07-04 - Saved MIDI Devices Need Source Honesty

Task: Make MIDI Input readiness distinguish saved input-device intent from live source-device enforcement.

What connects creatively: A lane can remember "MiniNova" or "QY-100" as its intended controller, but that is not the same thing as every live MIDI event arriving with a source-device tag. Keeping those concepts separate lets SpaceAge be clearer than many DAWs: "we see your controller, this lane is armed, this channel is accepted, and true physical-source filtering is or is not enforceable in this runtime path."

Architecture choice: Reports now expose saved device id, visible-device state, armed-lane/channel enforcement, and live source-identity availability as separate facts. The direct external input router can now attach source identity for lane-referenced physical devices, while host/plugin MIDI may still arrive as one source-agnostic stream. Keeping those two paths named prevents SpaceAge from overpromising in hosts and underreporting in standalone/direct-device operation.

Implementation bridge: The processor has a source-aware sibling to the normal MidiBuffer path. The direct input router feeds it with a physical source id; the host path can still feed it with an empty id. Both paths reuse the same live note/controller routing logic.

Future extensions: The same source-identity concept can feed Hardware Passports, controller templates, MIDI guitar/wind controller profiles, per-device learn filters, and "why did this note go there?" support receipts.

2026-07-04 - Expression Editors Need Keyboard Reflexes

Task: Make the MIDI EXPR surface respond more like an editor without bypassing its safety model.

What connects creatively: Once an editor can draw, erase, transform, and copy reports, the next layer is muscle memory. Esc, Delete, and copy shortcuts are small gestures, but they make a panel feel like an instrument instead of a form. The important trick is that shortcuts must not become a second codepath that skips shared-pattern warnings or review-only setup protection.

Architecture choice: Route the keyboard actions through the same helper methods and guards as the visible buttons. The expression graph also now uses MidiExpressionLaneSelector for point replacement, so the UI and MIDI model agree on what counts as "this lane," including poly aftertouch note ownership.

Follow-on connection: A report that says +N more lanes cannot be the end of the workflow. Dense imported MIDI, MPE-like files, and hardware CC-heavy performances may produce many expression lanes; the editor now needs to browse those lanes before it can become truly trustworthy. The first paging pass uses a simple offset, wheel scrolling, and keyboard selection so the current surface can reach everything it reports.

Future extensions: The same pattern should apply when the final Piano Roll-grade expression lanes arrive: handles, lasso, smoothing previews, and curve tools should all call model-owned selectors/plans rather than inventing editor-local interpretations of CCs, pitch bend, pressure, and switch lanes.

2026-07-04 - Viewport Honesty For MIDI Expression

Task: Add a first-pass selected-lane viewport to MIDI EXPR so long imported controller curves do not have to be edited as a microscopic full-pattern graph.

What connects creatively: This is the same rule we want for Piano Roll, Arrangement, Motion Clips, sample waveforms, and future automation: the visible window must also be the editing window. If the user zooms into a time range, every draw, erase, snap, and handle gesture should operate in that same visible range.

Reusable idea: Future zoomable editors should expose a small "fit selected thing" action and keep the readout honest about the viewed range. This prevents accurate-looking gestures from secretly landing somewhere else in time.

2026-07-03 - MPE-Like Projects Need An Honest Health Light

Task: Surface MPE-like or multi-channel performance expression at the project-health level, not only during MIDI import inspection.

What connects creatively: A user may import an expressive file, save the project, and return days later. If the only MPE-like warning lived in the import dialog, the warning disappears exactly when the user needs it most. Project Health can become the calm flight console for expressive MIDI: "your bend, pressure, and timbre data are preserved, but this is not true MPE zone handling yet."

Architecture choice: Reuse existing MIDI expression lane summaries. Project Health now counts CC74/timbre lanes and detects patterns where pitch, pressure, or CC74-style timbre appears across multiple channels. It reports those as MPE-like / multi-channel expression while keeping the promise honest: SpaceAge preserves the data as MIDI 1.0 lanes until a lane or device owns a true MPE zone policy.

Future extensions: When MPE Lane mode arrives, this health light can become a migration helper: choose master/member channels, validate bend range, assign per-note ownership, map synth response, and prove import/export fidelity before the user commits.

2026-07-03 - Hardware Restore Needs A Receipt Window

Task: Make SysEx restore verification visible inside the SysEx Vault, not only in copied reports or MIDI Health.

What connects creatively: Old hardware workflows are confidence-sensitive. A user needs to know three separate facts: SpaceAge queued the dump, SpaceAge estimated paced completion, and the hardware or another device replied with something meaningful. If those collapse into one vague "done," the user cannot trust recalls. A visible receipt strip turns the Vault into a hardware passport window rather than a hidden filing cabinet.

Architecture choice: Reuse processor-owned SysExRestoreVerificationReceipt history in the Vault. The panel now refreshes active restore attempts and recent receipts on its timer, paints a compact RESTORE RESPONSE strip, and keeps COPY REPORT available when receipt history exists. MIDI Health also refreshes while open, so its SYSEX RESTORE row can follow active attempts and new receipts instead of freezing at panel launch. The old "hardware ACK is not available yet" copy now says generic replies are captured when available, preserving the estimated-progress/manual-verification distinction.

Future extensions: Device-specific Yamaha, Novation, Korg, Roland/Boss, and Sequential parsers can feed the same receipt window without new UI architecture. The strip can later become a small timeline of restore attempts, failed ACKs, WAIT responses, manual verification notes, and "try again with slower send delay" helpers.

2026-07-03 - Pattern Playback Needs A Score Copy

Task: Remove normal sequencer playback reads from mutable pattern containers.

What connects creatively: The composer can be editing notes, slicing chords, recording CCs, or importing MIDI while the song is playing. Playback should not read the sheet music off the same desk the editor is rearranging. It needs a clean score copy: one immutable pattern payload that can be read quickly, predictably, and without asking the UI/editing model to hold still.

Architecture choice: Publish PatternPlaybackSnapshot objects per pattern at edit, restore, import, and queued recording commit boundaries. processSequencer() now reads drum steps, Piano Roll notes, Chord Engine markers, expression events, and pattern lengths from those snapshots instead of taking patternMutex.

Future extensions: The same snapshot model can later feed clip mini-graphics, expression previews, ghost-note summaries, Motion Clips, and a future "what will this lane play?" inspector without each feature touching live mutable vectors.

2026-07-03 - Live Timing Needs A Clean Gauge

Task: Remove direct mutable pattern-length reads from live MIDI recording timing.

What connects creatively: When a musician is recording, SpaceAge needs a simple, trustworthy gauge for "how long is this pattern right now?" The editor can keep the rich model with inference, imports, clips, and pattern repair, but live timing should read one small instrument panel, not rummage through the workshop.

Architecture choice: Keep patternLengths as the model-facing value, and mirror every write into realtimePatternLengths. Live MIDI record-position helpers now read the atomic mirror, while editor/export/import paths keep using the locked model.

Future extensions: The same pattern works for lane arm status, selected recording target, loop-record region, punch-in/out points, and Motion Clip boundaries. The armed-lane recording route now also reads from the published playback snapshot, reinforcing the rule that a live MIDI note should be filtered, monitored, and recorded through one coherent view of the song. It is also a stepping stone toward the bigger per-pattern playback snapshot, where full drum/note/chord/expression payloads become precomputed callback-readable events.

2026-07-03 - Playback Needs A Photograph, Not A Moving Target

Task: Start moving sequencer playback topology to immutable callback-readable snapshots.

What connects creatively: The Arrangement Canvas is meant to feel alive under the user's hands: lanes move, clips clone, sections resize, and MIDI routes change. The audio callback needs the opposite temperament. It should read one stable photograph of the topology while it plays, not poke at the same live objects the editor is actively rearranging.

Architecture choice: Publish a SequencerPlaybackSnapshot whenever chain slots, lanes, clips, or Section markers change. getEffectiveBpm(), advanceStep(), and processSequencer() now read that snapshot for topology. Pattern payloads still use the old mutex path until we add a precomputed event snapshot/cache for note, chord, drum, and expression playback.

Future extensions: The same snapshot pattern should become the backbone for Motion Clips, lane-local automation, MPE expression playback, hardware-output scheduling, clip waveform/MIDI mini-drawings, and plugin-host synchronization. The next useful connection is a per-pattern/per-clip event cache so MIDI playback can be both editable and realtime-clean.

2026-07-11 - Automation Launch Contract Wording

Task: Make MIDI AUTO/Automation closeout language read like a launch contract instead of a warning about future automation architecture.

What connects creatively: Shared PTN automation is not a compromise if it is named honestly. It supports reusable patterns, repeated gestures, imported controller data, and Variant-based independence. Clip-local and lane-local Arrangement automation will be powerful later, but that future should not make today's working pattern-owned automation feel unfinished.

Architecture choice: Update the model-owned closeout and next-test strings so no-automation projects ask for one shared PTN row through Piano Roll AUTO, Arrangement AUTO+, MIDI TASKS, or Settings. When rows exist, the report now defines the current launch proof as edit, undo, playback, import/export, and VARIANT-warning behavior. True clip-local and lane-local Arrangement automation remain roadmap architecture until they receive a separate ownership model.

Future extensions: When clip-local or lane-local automation is promoted, it should get a conversion path rather than silently replacing PTN automation: Keep Shared PTN, Make Variant, Make Clip-Local, or Move to Lane Automation.

2026-07-11 - MIDI QA Language Humanization

Task: Replace remaining engineering shorthand in Automation summaries with language a tester or musician can act on.

What connects creatively: MIDI closeout is partly a trust exercise. Phrases like first-pass, launch-polish, and trust gap are useful among developers, but a musician needs to know whether the row has visible tools, whether it needs hands-on QA, and whether an external bend destination/range still needs proof. The same model can serve both audiences if the live cockpit uses human consequence language and copied reports retain deeper diagnostics.

Architecture choice: Keep the underlying counters unchanged. Only translate their presentation: visible editor coverage becomes visible editor tools, launch polish becomes final hands-on QA, and pitch-bend trust gaps become destination/range checks still needed.

Future extensions: Apply this rule to every closeout panel: internal status names can be precise, but visible labels should answer, What can I do now?, What still needs proof?, and Will this touch project data or hardware?

2026-07-03 - MIDI Health Should Name The Actual Suspects

Task: Surface SoundFont live-note risk inside MIDI Health without turning it into a panic warning.

What connects creatively: A musician should not have to guess whether a controller, interface, audio buffer, or massive SF2 is responsible for mushy live feel. MIDI Health already explains block latency and queue pressure, so SoundFont count belongs there as another diagnostic clue.

Architecture choice: Add a loaded-SoundFont count and mention it in the latency summary/action lines. This keeps the UI truthful while avoiding a false "everything is broken" warning whenever a SoundFont is loaded.

Future extensions: When the prewarmed SoundFont voice pool lands, the same report can say whether the pool is warm, how many voices are prepared, and whether a specific SF2 is exceeding the safe live-performance budget.

2026-07-03 - SoundFont Voices Need A Launch Bay

Task: Start replacing per-note TinySoundFont copying with prepared voice instances.

What connects creatively: Huge SoundFonts are musically wonderful, but they behave like heavy cargo. Live MIDI needs a launch bay: voices prepared ahead of time, ready to borrow, and returned quietly after use. That is the same mental model as an Instrument Bay, just one layer deeper inside the audio engine.

Architecture choice: Add a small prepared TSF voice pool per pad. SoundFont load, preset change, and audio-device preparation warm the pool with fixed voice counts. The live note path borrows a matching prepared voice and refuses unsafe starts if the pool is exhausted or stale.

Future extensions: MIDI Health now reports pool size, active borrowed voices, and refused live voice starts; next it should add a "large SF2 live safety" label. The same prepared-resource pattern could help Quasar multisamples, spectral instruments, and future VST/hardware proxy workflows.

2026-07-03 - Sample Layers Need A Stage Plot

Task: Reduce sample-path locking during live note start without destabilizing sample loading/editing.

What connects creatively: A stage plot tells the crew where every instrument is before the show starts. Sample layers need the same idea: voice start should already know which layers are eligible, round-robin-ready, mapped, and playable, instead of stopping the performance to ask the sample editor.

Architecture choice: Remove one redundant sampleMutex re-lock loop by carrying round-robin eligibility out of the first sample-layer scan. Keep the bigger cache refactor documented rather than doing it halfway.

Future extensions: Add a pad-layer voice-start cache updated on sample load, clear, and layer-setting edits. MIDI Health could then distinguish SoundFont refused live starts from sample-layer edit contention when diagnosing live feel.

2026-07-03 - Dead Voices Should Not Leave Luggage At The Gate

Task: Reduce live-note cleanup risk by retiring ended voice resources consistently.

What connects creatively: A voice that has finished sounding should not leave a SoundFont copy, sample handle, or mapped reader attached to an inactive slot for the next musician gesture to clean up. That is exactly the kind of tiny invisible delay that makes MIDI feel mushy even when the musical scheduling is correct.

Architecture choice: Add one shared voice-retirement helper and use it at the existing voice-finish paths. This keeps the change narrow while making the cleanup rule explicit.

Future extensions: Replace per-note SoundFont copies with a prepared voice pool so tsf_copy() and TSF destruction do not sit on the live note path. The same lifecycle idea should apply to Quasar zones, imported samples, future VST voice proxies, and any AI/spectral instrument that carries heavyweight per-note state.

2026-07-03 - MIDI Reports Need A Conductor's Baton

Task: Sort imported tempo, meter, and key review rows by musical tick.

What connects creatively: The import wizard is becoming a trust machine. If it says "First tempo row," that phrase has to mean first in the song, not first in some hidden MIDI file track order. Small honesty fixes like this make the later full conductor-map editor feel inevitable rather than bolted on.

Architecture choice: Keep this as a report-level ordering pass for now. The current project still has one active BPM/key snapshot, but review/copy surfaces no longer mislead the user when source metadata is stored in a conductor track.

Future extensions: A future MidiConductorMap can preserve tempo, meter, and key events as structured tick-indexed rows, drive project-level map adoption, feed MIDI export, and become the same timeline object used by tempo-aware Motion Clips.

2026-07-03 - Realtime MIDI Should Be A Flight Recorder, Not A Workshop

Task: Audit realtime MIDI paths for callback-safe behavior.

What connects creatively: MIDI performance should feel immediate because the audio callback records tiny facts and moves on. The workshop jobs - learning mappings, mutating patterns, sorting events, building SysEx receipts, and telling the host about automation - belong in queues and model layers that can breathe.

Architecture choice: Keep the existing MIDI control mapping runtime queue as the pattern. Expand that idea to MIDI recording and legacy performance control paths before calling the MIDI implementation product-final.

Future extensions: A unified realtime event inbox could serve live MIDI Learn, recording, expression capture, hardware diagnostics, and future MPE without each subsystem inventing its own safety story.

2026-07-03 - Legacy Performance Cutoff Goes Atomic

Task: Remove the last obvious host-parameter notification from the incoming live MIDI path by changing CC/pitch-wheel-to-performance-filter updates from setValueNotifyingHost() to realtime atomic cutoff writes.

What connects creatively: The performance cutoff was already read by DSP as raw realtime parameter state, so the live gesture did not need to become a host automation event to change the sound. This brings an older pad-performance shortcut closer to the newer MIDI Learn discipline: realtime gesture first, optional host-visible automation later.

Architecture choice: Keep the existing musical behavior, but write directly to performanceCutoffParameters from live MIDI handling. If this ever needs to be visible as automation or saved as an edit, that should happen through a deliberate non-audio bridge or recorded expression lane, not from the callback.

Future extensions: A future performance-modulation lane could record these gestures as editable expression, while the UI follows the atomic performance state with a smoothed meter. The same pattern should guide breath, wind-controller, MIDI guitar, and MPE-style expression: fast realtime state underneath, intentional editing/persistence above it.

2026-07-03 - Capture Status Should Be A Little Flight Console

Task: Add a runtime SysEx capture progress/status model.

What connects creatively: A user dumping hardware memory needs confidence that SpaceAge is listening, receiving, or waiting, not frozen. A small status object can later drive a progress panel that feels like mission control: phase, bytes, timing, warnings, and next action.

Architecture choice: SysExCaptureProgress sits between the processor's armed capture state, the current SysEx Vault capture strip, and future richer capture widgets. It reports idle, armed/listening, captured/ready, and needs-review states from the same receipt/readiness objects used by support reports.

Future extensions: Use the same object for richer batch progress, a "try again" button, capture history row, and support bundle text.

2026-07-03 - The Vault Capture Strip Is The Airlock Door

Task: Expose live SysEx capture inside the SysEx Vault panel.

What connects creatively: A capture button without state feedback would feel like throwing a cable into the dark. The Vault strip turns the action into a small, legible ritual: arm, send one dump from hardware, review the receipt, save it as a snapshot. That same ritual can become a guided Hardware Passport flow later.

Architecture choice: The UI renders SysExCaptureProgress and uses processor-owned arm/cancel/save helpers. Incoming SysEx remains outside performance recording unless the capture airlock is armed, and saving still creates a normal Vault snapshot with confirmation required.

Future extensions: Add batch-capture mode, device-specific checksum/ACK helpers, and a "capture from this Hardware Passport" shortcut that preselects source and target labels without sending MIDI.

2026-07-03 - SysEx Capture Needs An Airlock

Task: Wire SysEx capture into the processor as an explicit arm, receive, review, and vault-commit workflow.

What connects creatively: Hardware dumps are powerful but risky, especially with old synths and grooveboxes. Treating live capture like an airlock means the data can enter SpaceAge safely, be inspected, named, archived, and attached to a Hardware Passport before it ever becomes eligible for a restore action.

Architecture choice: SysEx now bypasses ordinary note/channel filtering and only lands in the capture inbox when the user has armed capture. One incoming dump creates a receipt and auto-disarms. Vault commit remains a separate reviewed action with confirmation required.

Future extensions: The same capture inbox can power a guided "receive patch from hardware" wizard, a batch-dump panel with byte progress, timeout/cancel controls, checksum/device ACK helpers, and project-archive reports that explain exactly which hardware memories are protected.

2026-07-03 - SysEx Capture Is A Specimen Jar

Task: Add a model-owned SysEx live-capture readiness plan and capture receipt.

What connects creatively: Capturing a hardware dump should feel like placing a rare specimen in a labeled jar, not like pushing a mysterious hardware-send button. The same receipt can reassure the user, support hardware troubleshooting, feed the SysEx Vault, and later become the first page of a guided "capture my hardware patch" workflow.

Architecture choice: SysExCaptureReadinessPlan describes the explicit-arm, captured-only safety contract for the current product-facing one-dump capture workflow, while SysExCaptureReceipt validates framing, classifies transfer size, estimates DIN/send timing, and states that the data was captured only, not sent.

Future extensions: Use the receipt in the live capture panel, Hardware Passport attachment flow, support bundles, project archive reports, and a future batch-dump wizard with visible byte progress, timeout/stop controls, and device-specific ACK/checksum helpers.

2026-07-03 - Hardware Templates Should Feel Like Recipes

Task: Add practical hookup checklists to MIDI hardware setup templates.

What connects creatively: A user connecting a MiniNova, QY-70/QY-100, EWI, MIDI guitar, or MPC-style pad controller does not want a MIDI lecture first. They need a recipe: connect this cable, select this lane/channel, send a test note, store dumps safely, then calibrate timing. Those same recipe steps can later become setup-wizard rows, manual pages, support copy, and onboarding prompts.

Architecture choice: MidiHardwareSetupDeviceTemplate now owns hookupChecklist, includes it in template search, serializes it in toVar(), prints it in template reports, and copies the steps into apply-preview proposed actions with a Hookup: prefix.

Future extensions: Use the checklist as the first page of a guided hardware setup wizard. Each row can become either a read-only instruction, a navigation action, or a guarded test/recall action while preserving the rule that templates never silently change routing or send MIDI.

2026-07-03 - A Test Note Is A Handshake

Task: Add a reusable safe hardware test-note plan to MIDI setup templates.

What connects creatively: The moment a user hears an external synth respond to SpaceAge, trust becomes physical. But a test note can also be scary if it secretly sends patch changes, SysEx, or transport. Treating the test note as a receipt-backed handshake lets SpaceAge say, "we are ready to send exactly this one note, on this channel, after you confirm."

Architecture choice: MidiHardwareSetupTestNotePlan owns readiness, blocked reasons, preconditions, warnings, note/channel/velocity/duration, and a plain-text report that explicitly says it sends no MIDI while being built.

Future extensions: The setup wizard can use the same plan for a TEST NOTE button, timing-calibration prompts, hardware support reports, and per-device onboarding flows. MiniNova, QY/XG modules, EWI rigs, MIDI guitars, and pad controllers can each get different default test gestures without weakening the no-hidden-sends rule.

2026-07-02 - Latency Reports Should Teach The Signal Path

Task: Add a reusable MIDI Health latency checklist.

What connects creatively: A musician feels latency as one bad thing, but the cause may be buffer size, driver behavior, Bluetooth, MIDI interface timing, controller scan rate, hardware response, or heavy processing. A good microDAW should calmly separate those layers so the user has a practical path instead of superstition.

Architecture choice: MidiProjectHealthSummary now owns latencyActionLines(), serializes those lines, and uses them in both the full Health report and compact Next Steps report.

Future extensions: The same checklist can drive a guided latency wizard, hardware setup assistant warnings, and real-device support bundles once loopback measurements and jitter profiles are more mature.

2026-07-02 - Honest MPE Boundaries Are A Feature

Task: Centralize SpaceAge's explanation of MPE-like MIDI imports.

What connects creatively: A wind controller, MIDI guitar, or MPE-ish exported clip can look magical or broken depending on how honestly SpaceAge explains what it sees. Treating that explanation as a first-class receipt gives musicians confidence: their expression was not thrown away, but the app is not pretending to understand full MPE zones yet.

Architecture choice: MidiInspectionReport now owns mpeLikeLimitationLines(), and the structured payload serializes those lines. Import Review displays the same model-owned checklist instead of repeating a single warning string.

Future extensions: When true MPE lands, this helper can become the migration hinge: zone detection, master/member channel assignment, per-note bend-range policy, and synth-response readiness can replace the current limitation checklist without rewriting every UI panel.

2026-07-02 - Every MIDI Wizard Needs A Receipt Button

Task: Continue MIDI closeout by adding a COPY REPORT action to the MIDI Import Wizard Preview.

What connects creatively: MIDI import can contain song metadata, channel-role guesses, expressive data, patch setup, SysEx, and sync messages. If something looks odd, the user should be able to copy the whole diagnosis instead of describing a screenshot. This matches the direction already taken by MIDI Health, MIDI Input, MIDI Out, MIDI Sync, MIDI Timing, MIDI Setup, MIDI Maps, and SysEx Vault.

Architecture choice: The button now copies MidiImportApplyPreview::toPlainTextReport() through the shared cold-copy helper instead of copying rendered review text. The UI can still render the review however it wants, but clipboard truth comes from the MIDI model.

Future extensions: Convert this copied receipt into a support bundle attachment, import history entry, and final wizard COPY PLAN / COPY RECEIPT pair after mutation.

2026-07-09 - Preview Copy Should Copy The Model, Not The Paint

Task: Tighten the MIDI Import Wizard Preview copy path after the receipt popup became model-owned.

What connects creatively: A preview is the user's before-picture. A receipt is the after-picture. If both are copied from model-owned reports, support, QA, and future import history can compare planned intent against actual mutation without scraping the UI.

Architecture choice: MidiImportReviewPanel::COPY REPORT now copies MidiImportApplyPreview::toPlainTextReport(), including its next-test line and action/warning summary, wrapped in the same cold-copy safety language used elsewhere.

Future extensions: Store the preview report beside the apply receipt when import history exists, so a project can later show "what SpaceAge said it would do" and "what SpaceAge actually did."

2026-07-02 - Current UI Should Reuse Future Wizard Truth

Task: Continue MIDI closeout by wiring the current MIDI import confirmation message to the same apply-preview receipt model intended for the future import wizard.

What connects creatively: The fastest path to a good wizard is not to build a separate wizard brain. It is to make today's smaller confirmation surface quote the same model-owned import plan the larger wizard will eventually render. That way the user sees the same promises now and later: create lanes, import clips, preserve expression, store SysEx, review setup data, or ignore sync.

Architecture choice: PluginEditor::buildMidiImportPreflightMessage() now inserts MidiImportApplyPreview::toPlainTextReport() rather than maintaining a parallel hand-built action summary. The editor still chooses where to show the message, but the MIDI model owns what the message means.

Future extensions: Replace the current text-heavy confirmation with a card-based import wizard without rewriting the decision logic. The same receipt can feed wizard cards, copy-to-support, undo labels, and an import progress meter.

2026-07-02 - Apply Previews Should Be Confirmation Receipts

Task: Continue MIDI closeout by making MIDI import apply previews count their planned actions and write a plain-text receipt.

What connects creatively: The import wizard should not ask a musician to trust a mysterious button. Before mutation, it should say whether it will create lanes, import one clip, preserve expression, review setup data, store SysEx, or ignore transport/sync. That makes importing a collaboration between the user and SpaceAge instead of a gamble.

Architecture choice: MidiImportApplyPreview::toVar() now carries action counts and plainTextReport, while toPlainTextReport() renders the same model-owned action list for future support, copy, and confirmation surfaces.

Future extensions: Use this for the final import confirmation dialog, undo descriptions, import history, support bundles, and an import progress meter that starts from the same planned-action count.

2026-07-02 - Import Plans Should Be Receipts

Task: Continue MIDI closeout by making MIDI import plans serializable as structured receipts.

What connects creatively: Once SpaceAge tells the user "I recommend splitting channels to lanes" or "this SysEx must be quarantined," that recommendation should be inspectable, copyable, and testable. The plan is the promise the app is making before it mutates the project, so it deserves the same durable data treatment as health reports, Vault summaries, and expression transform receipts.

Architecture choice: MidiImportPlanChoice::toVar() and MidiImportPlan::toVar() now expose recommended choices, confirmation flags, channel-role hints, lane candidates, warnings, and the nested inspection report. This turns the import plan into a transportable object for future UI, support diagnostics, undo descriptions, and import previews.

Future extensions: Use the plan receipt for a full MIDI import wizard, a "copy import diagnosis" support button, import undo summaries, per-channel lane assignment editing, and a before/after confirmation screen for hardware-sensitive files.

2026-07-02 - Import Decisions Should Explain Themselves

Task: Continue MIDI closeout by exposing MIDI import channel-role hints and lane candidates as structured dashboard data.

What connects creatively: A good import flow should not merely say "create lanes." It should say why. Channel 10 may be drums, a bend/pressure channel may be a wind controller or guitar-like performance, and setup-only channels may belong in hardware or SoundFont setup rather than a note lane. Those distinctions are the difference between a helpful assistant and a confusing file loader.

Architecture choice: MidiChannelImportHint::toVar() now serializes the channel classification, MidiImportLaneCandidate::toVar() includes readable role labels, and MidiImportReviewDashboard::toVar() carries both channelHints and laneCandidates. This keeps the import UI downstream from the MIDI model instead of making the editor invent music/protocol meaning from raw counters.

Future extensions: Use these objects for an import wizard with lane cards, "why this lane?" detail drawers, hardware setup quarantine cards, MIDI guitar/wind controller affordances, and one-click creation of lanes that already know their input channel, output channel, instrument suggestion, and expression-preservation strategy.

2026-07-02 - Import Inspection As A Truth Object

Task: Continue MIDI closeout by making imported MIDI facts available as structured data, not only as readable report text.

What connects creatively: Importing MIDI is one of the places where SpaceAge has to be calm, honest, and precise. A file might contain notes, tempo maps, key changes, SysEx dumps, hardware setup controllers, transport events, or MPE-like expression. The user needs those facts before the app mutates the project, assigns lanes, or hides device data behind a friendly button.

Architecture choice: MidiInspectionReport::toVar() now serializes the inspection report, and MidiImportReviewDashboard::inspection carries that object forward. This makes one MIDI-model-owned source of truth available to future import dashboards, support reports, hardware-passport warnings, channel-to-lane import choices, and MPE-like preservation notes.

Future extensions: Use this payload for a visual import-review panel, "safe to import" badges, lane-assignment previews, hardware setup warnings, MPE/MIDI 2.0 upgrade messaging, and one-click support diagnostics when a user's imported file behaves unexpectedly.

2026-07-02 - A Vault Needs A Dashboard

Task: Continue MIDI closeout by making the SysEx Vault report summarize the whole set of saved hardware dumps, not only individual snapshots.

What connects creatively: A musician deciding whether to restore a hardware rig does not only need the details of one dump. They need to know the whole risk profile: how many dumps are archived, how many need confirmation, whether any are bulk transfers, and approximately how long the whole operation could take. That turns the Vault from a file drawer into a dashboard.

Architecture choice: SysExVaultSummary now computes aggregate bytes, wire time, paced completion, transfer-class counts, confirmation count, archive count, warning count, and largest snapshot from SysExSnapshotSummary. The plain-text Vault report renders that model instead of owning separate math, so future UI and support reports stay aligned with the same timing facts.

Future extensions: Use these aggregate numbers for a SysEx Vault header strip, restore-progress meter, archive-validation report, and hardware setup assistant warnings such as "this project contains three bulk dumps; restore before the show, not during the count-in."

2026-07-02 - Health Reports Should Carry The Vault, Not Point At It

Task: Embed the SysEx Vault dashboard inside MIDI Health reports and structured MIDI Health payloads.

What connects creatively: MIDI Health is the future "send this to support" button. If it only says "three SysEx snapshots," support still has to ask the next question: are they tiny patch messages, risky bulk dumps, archived with the project, or long hardware sends? Carrying the Vault dashboard inside Health makes one copied report tell the whole hardware-recall story.

Architecture choice: MidiProjectHealthSummary::toPlainTextReport() now includes sysExSnapshotSummariesToPlainTextReport(), and toVar() exposes sysExVaultReport. The editor can stay dumb; the MIDI model owns the language.

Future extensions: Add a visible MIDI Health Vault card, a COPY VAULT action beside the support report, and a restore-preflight screen that reuses the same aggregate facts before any SysEx leaves the computer.

2026-07-02 - SysEx Receipts Need Time

Task: Continue MIDI closeout by making stored SysEx snapshots explain their hardware-transfer timing before they become part of a future send/restore workflow.

What connects creatively: SysEx is not just data; it is a conversation with old hardware that may need breathing room. A snapshot should feel like a labeled hardware memory object, not a mysterious byte blob. By showing transfer class, DIN wire time, and paced completion time in the vault summary, SpaceAge can teach the user why a QY-70/QY-100 or similar box may take a moment to receive a dump.

Architecture choice: SysExSnapshotSummary now owns transfer timing fields and serializes them beside byte count, delay, safety, descriptor, and confirmation fields. The snapshot report can therefore share the same trust language as hardware recall plans without requiring UI code to recalculate protocol math.

Future extensions: Use this receipt in the SysEx Vault UI, hardware setup wizard, archive validator, send-progress meter, and any future "restore hardware before playback" assistant. The user should always see "what will be sent, how long it may take, and why confirmation exists" before any hardware mutation.

2026-07-02 - Transform Receipts Should Protect Trust

Task: Continue MIDI closeout by making expression-lane transforms report not only what they changed, but what source events they left untouched.

What connects creatively: MIDI expression edits are powerful enough to feel risky. If a user trims a dense expression lane, quantizes pitch bend, or nudges pressure values, they should see evidence that other notes, CCs, bends, and setup data were preserved. That turns a destructive-looking tool into a receipt-backed musical edit.

Architecture choice: MidiExpressionTransformResult now includes an untouched-event count, serializes it, and includes it in summaries. The model owns the claim, so UI panels, copied reports, future undo descriptions, and support bundles can all use the same wording.

Future extensions: Use the same receipt pattern for Arrangement paste, clip conversion, SysEx recall queues, Motion Clip transforms, and future automation thinning. Every operation that selectively edits a subset should be able to say what it touched and what it protected.

2026-07-02 - Expression Ramps Should Replace, Not Pile Up

Task: Continue MIDI closeout by making MIDI EXPR ramp drawing feel like a musician-facing gesture instead of a raw event generator.

What connects creatively: A ramp is a phrase of controller motion. If it always starts at zero, a pitch-bend ramp becomes a plunge from full-down instead of a bend from the current value. If it piles new points over old points, the clip can contain contradictory hidden expression that is technically valid MIDI but creatively confusing.

Architecture choice: DRAW RAMP now looks up the selected lane's current/prior value at the playhead, uses that as the ramp start, and clears old editable points in the target span before writing the replacement gesture. Switch-style lanes such as sustain are kept out of ramp drawing and use point/step behavior instead.

Interaction rule: Selection should be powerful but visible. MIDI EXPR now names whether the create strip is targeting a selected lane or dropdown-defined new lane creation, and CLEAR TARGET gives the user an obvious way back to new-lane authoring.

Future extensions: Use the same replace-not-pile-up behavior for automation clips, Motion Clips, synth/effect automation, tempo-aware effect gestures, and larger piano-roll-style expression lanes with visible point handles.

2026-07-02 - Expression Editing Needs Plans Before Pixels

Task: Continue the MIDI protocol push by giving MIDI expression lanes a reusable editor plan before expanding the drawable UI.

What connects creatively: Pitch bend, sustain, pressure, breath, mod wheel, and ordinary CCs are all time-varying MIDI, but they are not the same kind of musical object. Pitch bend needs a centered 14-bit curve, sustain wants switch-like blocks, pressure wants continuous shapes, and RPN/NRPN setup data should remain protected. A plan object lets SpaceAge explain the right interaction before adding more graphics.

Architecture choice: MidiExpressionEditorPlan is built from MidiExpressionLaneSummary and reports point, curve, switch-block, thinning, warning, and review-only capabilities. The MIDI EXPR selected scope/status text and model report now use that plan instead of inventing UI-only language.

Subagent audit reminder: Faraday flagged three risks before the next full editor pass: the current drawing scope maps only the lane's existing tick range rather than the whole clip timeline, pitch-bend/switch-lane value semantics must not be flattened into generic 0-127 thinking, and pattern-owned expression still needs shared-pattern warnings until a real clip-local overlay model exists. Peirce later confirmed the same shape of issue in the selected scope: X mapping, preview scaling, and event creation needed to move into shared MIDI helpers instead of living as local editor math.

Implemented connection: Selected-scope expression drawing now uses a shared mapMidiExpressionEditorPoint() and makeMidiExpressionEventForLane() path. That means timeline X position, pitch-bend 14-bit range, sustain on/off thresholding, and CC/pressure values are one model-level promise. The large selected-lane preview also uses the selected pattern timeline, while compact rows can remain content-relative summaries.

Interaction rule: Once an expression lane is selected, nearby actions should operate on that selected musical object. ADD POINT and DRAW RAMP now follow the selected lane's channel, note row, range, and event semantics instead of behaving like a separate generic insert panel. This same rule should guide future automation, Motion Clips, and clip-edit surfaces: selection creates operational context.

Future extensions: Use the same plan shape for large Piano Roll expression lanes, Motion Clips, synth/effect automation, MPE lane previews, wind-controller breath lanes, MIDI guitar bend lanes, and support reports that explain why a performance changed over time.

2026-06-30 - Protocol Scorecards Must Age With The Product

Task: Update the MIDI Protocol Coverage model and status docs so Clock/Transport no longer appears as "UI pending" after the first-pass Sync role editor and reports were implemented.

What connects creatively: A protocol scorecard is more than internal bookkeeping; it becomes part of the product's self-knowledge. If the scorecard lags behind reality, QA chases old ghosts, support language gets stale, and we accidentally keep treating solved problems as blockers.

Architecture choice: The Clock/Transport protocol family now reports first UI, marks UI readiness true, and drops out of the product-readiness blocker list while still naming the remaining polish: MTC offsets, MMC record/locate options, and deeper diagnostics.

Future extensions: Use this scorecard as the backbone for a "MIDI Readiness" page, release notes, internal QA checklists, and customer-facing support receipts.

2026-06-30 - MIDI Expression Reports Are Performance Receipts

Task: Move the MIDI Expression panel's copyable report into a reusable MIDI model helper.

What connects creatively: Expression data is performance memory. Mod wheel, expression, pitch bend, pressure, sustain, brightness, and poly-aftertouch can make a clip feel alive, but they can also confuse a user if they are hidden or mixed with protected setup data. A model-owned report lets SpaceAge explain exactly what expression lanes exist, what range they cover, and whether they are editable or review-only.

Architecture choice: midiExpressionPreflightToPlainTextReport() composes the selected-pattern receipt from MidiEventList and MidiExpressionLaneSummary rows. The UI still decides when to show or copy it, but the model owns the vocabulary and facts.

Future extensions: Use the same receipt language in expression-lane inspectors, support bundles, MIDI package diagnostics, clip notes, hardware setup assistants, and a future "why is this clip moving?" troubleshooting view.

2026-06-30 - Timing Reports Are Trust Receipts

Task: Move the MIDI Timing preflight report into a reusable MIDI model helper while allowing the UI to pass in its current loopback-pulse setup label.

What connects creatively: Timing is one of the places where a user either relaxes or starts doubting the whole machine. A clear timing receipt connects live-controller feel, hardware loopback calibration, record compensation, MIDI Health warnings, and Hardware Passport timing labels into one story: what SpaceAge knows, what it measured, and what still needs user action.

Architecture choice: midiTimingPreflightToPlainTextReport() owns the report structure. The editor supplies the current pulse-count/spacing label because that is transient UI state, but the model layer owns the timing facts and wording.

Future extensions: Add timing receipts to support bundles, show before/after calibration diffs, store accepted timing-report snapshots with hardware profiles, and let the future setup assistant explain exactly why a device feels late or early.

2026-06-30 - MIDI Workbenches Should Share Their Receipt Language

Task: Move focused MIDI Input, MIDI Output, and MIDI Sync preflight report composition into reusable MIDI model helpers.

What connects creatively: Each MIDI workbench is a different window into the same rig. Input answers "is the controller getting in?", Output answers "can this lane reach hardware?", and Sync answers "who is leading time?" If each panel can leave a small copyable receipt, SpaceAge starts to feel like a careful studio assistant: it knows the setup, explains the setup, and never makes the user translate hidden protocol state into human support notes.

Architecture choice: midiInputPreflightToPlainTextReport(), midiOutputPreflightToPlainTextReport(), and midiSyncPreflightToPlainTextReport() compose existing model-owned readiness/runtime/policy reports. The editor remains responsible for showing buttons and copying text, not inventing diagnostic language.

Future extensions: Add a "Copy MIDI Studio Bundle" that combines Health, Input, Output, Sync, Timing, Hardware Queue, and SysEx Vault reports; let the future MIDI setup assistant quote exact report lines; and use these receipts as source material for an in-app troubleshooting agent.

2026-06-30 - MIDI Setup Scenarios As Product Memory

Task: Continue the MIDI protocol push by making common hardware setup workflows reusable instead of hard-coded Settings text.

Existing connections:

• MIDI Health already knows lane routing, armed inputs, hardware profiles, SysEx snapshots, and timing-calibration status.
• Hardware Profiles already hold device identity and output intent.
• MIDI EXPR already distinguishes expressive controllers from setup/protocol data.
• The Settings MIDI pages already need to guide users without accidentally sending hardware-changing messages.

Creative extension ideas:

• A future "New Hardware" wizard can start from these same scenario records: controller, external synth, multitimbral module, MIDI guitar, wind controller, or drum pads.
• MIDI guitar and wind-controller scenarios can preselect expression-lane defaults such as pitch bend, breath, channel pressure, and poly pressure.
• Multitimbral module scenarios can eventually generate lane/channel templates for QY-style hardware without forcing the user to remember channel maps.
• Scenario summaries can become manual pages, onboarding cards, and troubleshooting hints without rewriting the same advice.

Design reminder: Setup scenarios are guidance, not actions. They must not arm lanes, change routing, attach hardware profiles, send Program Changes, send SysEx, or mutate a project until the user deliberately chooses a concrete action.

2026-06-26 - Hardware Send Queue Progress

Task: Continue the MIDI protocol push by exposing first-pass live progress for hardware MIDI sends and confirmed SysEx/program recall queue activity.

Existing connections:

• The MIDI Hardware panel already shows profile summaries, guarded recall plans, concrete recall-message rows, and recent queue logs.
• The SysEx Vault already teaches "stored/attached is not sent"; queue progress now gives the matching feedback after the user deliberately sends.
• The hardware router already has separate live lane traffic and confirmed recall traffic, so the UI can distinguish ordinary external MIDI playback from explicit librarian-style hardware recall.

Creative extension ideas:

• The same queue-progress packet can later feed a full hardware transfer meter with bytes sent, active device, delay countdown, and failed-send recovery.
• A future Hardware Setup Assistant could show this beside a "Send test note" or "Recall patch" checklist so old external gear feels less mysterious.
• The MIDI Health page can eventually surface stuck pending sends, dropped hardware messages, or oversized SysEx dumps as actionable warnings.

Design reminder: Queue progress is not proof of hardware acknowledgement. It means SpaceAge still has messages pending in its own send queues. Generic ACK/NAK classification and active-attempt response routing improve restore trust, while deeper checksum validation, per-passport restore history, and model-specific librarian confidence remain future work.

2026-06-26 - MIDI Expression Lane Shape Preview

Task: Continue the MIDI/customer-facing push by making the Settings MIDI Expression panel show a compact shape preview for each editable expression lane.

Existing connections:

• The backend already preserves, summarizes, transforms, plays, records, and exports CC, pitch bend, channel pressure, and poly aftertouch payloads.
• The current Settings panel can already quantize, nudge, thin, and delete expression lanes, but rows were text-only and did not help the user understand the musical contour.
• Arrangement clips already gained tiny MIDI-inside graphics because visualizing contents lowers uncertainty; expression lanes deserve the same early visual language.

Creative extension ideas:

• The row preview can become the seed of a full drawable automation lane later: same matching rules, same value ranges, same transform backend.
• Clip interiors could eventually show both note contours and expression overlays, with a tasteful "modest/bold MIDI representation" user setting.
• MIDI Health could use miniature lane previews to explain why a controller-heavy imported file feels expressive or cluttered.

Design reminder: This is a preview, not an editor. It helps users recognize what data exists before we introduce direct drawing, curve tools, and clip/lane-local expression ownership.

2026-06-26 - Import Wizard Drum Rows Become Real Choices

Task: Continue the MIDI protocol/customer-facing push by making the MIDI Import Wizard expose GM channel 10 drum candidates as checkable split-import rows now that the backend supports long-form drum payloads.

Existing connections:

• The processor can already import long-form drum notes into drum lanes without truncating to the classic 64-step Drum Composer grid.
• The Import Wizard already has include/exclude rows for safe channel splitting, destination controls, and import receipts, so this is the right surface to teach the new behavior.
• The Instrument Bay workflow should not be involved for imported GM drum lanes; those rows need to say "Long-form Drum Lane" instead of pretending a drum channel is a normal synth slot.

Creative extension ideas:

• A future import choice can offer "Keep as long-form drum MIDI" versus "Convert short passages into Drum Composer step banks."
• The same row-level language can later support hardware drum modules: Channel 10 may map to internal drums, an external drum machine, or a SoundFont drum kit.
• Drum import receipts could eventually show a tiny pitch-to-pad map so users know how GM notes were translated.

Design reminder: Once the backend can safely represent a musical fact, the UI should stop describing that fact as pending or guarded. Confidence comes from honest capability plus plain language.

2026-06-26 - Long-Form Drum MIDI Import

Task: Continue the MIDI protocol push by removing the main backend blocker for channel-to-lane imports: drum channels were being detected, but then skipped because the legacy Drum Composer grid only stores 64 steps.

Existing connections:

• The Arrangement Canvas already supports clips up to maxPatternSteps, and the Piano Roll note payload already carries long note events without needing a huge fixed-size grid.
• Drum lanes still need the classic 64-step grid for fast beat programming, but imported General MIDI drum files often exceed 64 steps and should not be silently rejected.
• The export/readiness pipeline already distinguishes drum lanes from instrument lanes, so the long-form drum payload can travel through the same lane-owned MIDI channel and routing model.

Creative extension ideas:

• Long-form imported drum notes can become a separate "Imported Drum MIDI" edit view later, while hand-built Drum Composer beats keep their MPC-style grid.
• Future GM import can offer "convert to Drum Composer banks" for short/simple files and "keep as long-form drum MIDI" for full songs.
• This same hybrid-payload idea may help future hardware drum-machine imports, where the source is drum data but not necessarily a SpaceAge step grid.

Design reminder: Do not solve long files by making the old drum grid enormous. Use the right payload for the job: grid for performance composition, note vectors for imported timeline truth.

2026-06-26 - Focused MIDI Repair Buttons

Task: Continue the MIDI protocol/customer-facing push by giving the focused MIDI Input and MIDI Out panels the same guided repair-button behavior already added to MIDI Health.

Existing connections:

• MidiDeviceRepairRecommendation is now the shared language for missing inputs, missing outputs, closed hardware devices, dropped messages, unarmed input lanes, and lane-specific routing repairs.
• MIDI Health is the overview dashboard, while MIDI Input and MIDI Out are focused workbenches. The same recommendation should not feel passive in one surface and actionable in another.
• The Arrangement Lane MIDI Routing panel is the true place to alter lane-owned MIDI routing, so repair buttons should navigate there rather than mutate state from a summary panel.

Creative extension ideas:

• A future guided MIDI setup assistant can use the same recommendation actions as a checklist: detect, explain, navigate, let the user choose, then confirm.
• Focused panels can eventually remember the user's last repair path, which would make repeated hardware setup feel more like a guided checklist than a maze.
• The same pattern can later apply to audio device errors, missing samples, SoundFont relocation, and VST scan issues: advice rows become safe navigation buttons, not mystery buttons that change state behind the curtain.

Design reminder: A repair button is a door, not an autopilot. It should take the user to the correct surface and preserve consent for any routing, recall, or hardware send action.

2026-06-25 - MIDI Import Commit Boundary

Task: Continue the MIDI protocol push toward the next readiness milestone by turning MIDI import review into a processor-owned commit path rather than a UI-only action.

Existing connections:

• The MIDI Import Wizard Preview already knows about channels, lane candidates, SysEx quarantine, patch/setup data, song metadata, and transport/sync messages.
• Selected-pattern import already imports playable notes, preserves safe timeline expression, and quarantines SysEx.
• Arrangement lanes now own instrument identity and MIDI routing, so any future channel-to-lane import must be a processor operation, not an editor-side assembly of unrelated helper calls.

Creative extension ideas:

• The import wizard can become a staged cockpit: first review, then choose single clip versus channel split, then choose lane instruments/hardware profiles, then commit with a receipt.
• A future "convert to Drum Composer" option should only create classic Step Bank grids when the drum payload can honestly represent the imported length. Long GM drum files should stay in long-form drum lanes unless the user explicitly chooses a conversion.
• Expression import needs a visible ownership model. Pattern expression is safe now, but a later clip-local expression layer will make copied clips, variants, and imported MIDI arrangements less surprising.

Design reminder: Import must never look more powerful than it truly is. If the data model cannot yet represent a musical fact accurately, the UI should name that limitation rather than creating a beautiful lie.

Implemented connection: Selected-pattern MIDI import now goes through a processor-level applyMidiFileImport boundary and returns the shared import receipt model. First-pass channel-to-lane mutation now covers safe melodic/instrument rows and GM channel 10 long-form drum rows; setup-only and hardware-review rows remain guarded.

2026-06-25 - AI-Assisted Internal Patch Creation

Task: Capture the future idea of AI-assisted patch creation for SpaceAge's internal synths.

Existing connections:

• SpaceAge already has a growing family of internal engines: Redshift, Propulsion 1, Liftoff, Glass Moon, Moonshadow, Lunacy, Quasar, Physical Model, Kick Lab, Snare Lab, Hat Lab, and Classic Machines.
• The preset browser plan already wants category, preset, engine, author, and descriptive metadata; AI patch creation should write into that same preset/preset-metadata world instead of inventing a separate "AI sound" object.
• The future in-app assistant and MIDI/audio diagnostic ideas share the same principle: help the user express intent in plain language, then produce normal editable SpaceAge data.

Creative extension ideas:

• Let the user describe a target sound, then generate a normal internal patch with a short explanation of the important parameter choices.
• Analyze reference examples legally as timbral evidence rather than cloning proprietary patches: spectrum, envelope, transient, noise content, modulation rate/depth, pitch stability, stereo width, brightness, body resonance, and decay tail.
• Offer "make it brighter," "more unstable," "less detuned," "more chord-safe," or "more tape-worn" as follow-up actions that produce ordinary saved patch variants.
• Connect the idea to Quasar and future sample analysis: a reference audio file could become a descriptive target for a synth patch, a Quasar multisample candidate, or a Motion Block/effect chain suggestion.

Design reminder: AI patch creation should create editable starting points, not mysterious locked presets. The user remains the sound designer.

2026-06-25 - MIDI Controller Semantics And Hardware Safety

Task: Continue MIDI protocol work by naming RPN/NRPN, Data Entry, and channel-mode controller messages instead of treating them as generic CC traffic.

Existing connections:

• MIDI Learn, expression lanes, import review, hardware profiles, and SysEx Vault all need to distinguish normal performance gestures from setup commands.
• RPN/NRPN messages are often how external synths expose deep parameters; preserving them matters, but learning or drawing them as random CCs would confuse users and could change hardware state unexpectedly.
• The existing MIDI Health and Import Review dashboards can now use clearer labels when they encounter setup-style controller data.

Creative extension ideas:

• A future MIDI Import Wizard can group RPN MSB/LSB + Data Entry into a single readable row such as "Pitch Bend Range setup on CH 02" instead of showing four unrelated CC messages.
• Hardware Profile pages can eventually offer "capture setup changes" for devices that use RPN/NRPN heavily, then store those changes as named recall-safe setup snippets.
• MIDI guitar and wind-controller profiles can use the same semantic layer to explain which incoming messages are expression, which are setup, and which are safe to map.

Design reminder: If a MIDI byte can change how hardware behaves globally, SpaceAge should name it, preserve it carefully, and require intent before turning it into an action.

Implemented connection: The import review backend now adds readable RPN/NRPN and channel-mode setup lines to the Patch Setup detail section, so the future wizard can say what was found without making the user decode raw controller numbers.

2026-06-25 - MIDI Latency Visibility

Task: Continue MIDI work by making live MIDI latency easier to reason about without guessing at driver or hardware behavior.

Existing connections:

• Settings already has a MIDI Health/preflight area and a record-latency compensation slider.
• The processor already handles incoming MIDI before voice rendering and uses incoming sample offsets for live notes, so the immediate SpaceAge scheduling path is not obviously adding a whole extra audio block.
• The user has heard a small live-performance lag; diagnosing that requires separating SpaceAge block timing from driver/interface/OS/device latency.

Creative extension ideas:

• MIDI Health should show audio block size, sample rate, and calculated block time so a performer can see the first latency floor immediately.
• A future "Live MIDI Feel" assistant could walk the user through buffer size, driver type, input device, armed lane, and record-latency compensation without burying them in engineering terms.
• If SpaceAge later supports external hardware round-trip testing, this same health section can report measured input-to-audio response instead of only the theoretical block time.

Design reminder: Do not promise latency that the app cannot control. Show the controllable baseline plainly, then guide the user toward the next likely bottleneck.

2026-06-24 - Lane Hardware Profile Identity

Task: Continue the MIDI architecture without making a new build by letting Arrangement lane routes remember a hardware profile and by giving hardware profiles safe bank/program recall message generation.

Existing connections:

• Arrangement lanes already own MIDI input filter, playback/export channel, route target, and hardware output device, so hardware profile identity belongs on MidiTrackRoute, not in a top-row inspector.
• Hardware profiles and SysEx snapshots already persist as project data; lane profile assignment is the missing bridge between a song lane and a named external device setup.
• Program/bank recall connects to future hardware synth workflows, SoundFont preset thinking, and lane-owned Instrument identity: the user should be able to say "this lane drives that device patch" without memorizing raw MIDI numbers.

Creative extension ideas:

• A lane could eventually display a compact hardware badge: device name, MIDI channel, bank/program, and whether clock/SysEx snapshots are attached.
• The same profile model can support guided setup wizards for MIDI guitar, wind controllers, drum controllers, and legacy modules such as Yamaha QY/XG devices.
• Bank/program recall should later become a visible "Recall Hardware Patch" action with progress, throttling, error reporting, and a send log instead of happening invisibly during playback.
• The Lane MIDI Routing panel can become the first user-facing bridge to the future Hardware Profile/SysEx Vault: attach a profile now, then later reveal recall, snapshot, and setup-help actions without inventing a second workflow.
• Upsert/remove helpers turn the vault into a real record system rather than a raw vector replacement. That matters when a future dialog edits one device profile while the rest of the project keeps playing.
• A "create hardware profile from this lane" helper lets the UI start from the user's current context instead of asking them to fill an empty form. The lane already knows the output device, MIDI channel, and routing intent, so the profile wizard can begin with useful defaults.

Design reminder: Hardware recall is powerful but risky. Store intent freely; send bytes only when the user clearly asks SpaceAge to touch an external device.

2026-06-23 - MIDI Protocol Foundation

Task: Begin SpaceAge's serious MIDI phase by auditing existing MIDI behavior and adding a central protocol layer without breaking live input, recording, import, or export.

Existing connections:

• The Arrangement Canvas already owns lane identity, mixer routing, and MIDI channel output, so MIDI track routing should grow from lane state rather than from a separate top inspector.
• Existing MIDI export already uses 960 PPQ, which gives us a stable canonical tick system instead of inventing a new timing unit.
• Piano Roll notes, Drum Composer steps, Chord Engine markers, Motion Clip ideas, and future automation lanes all need a shared timing vocabulary so copy, paste, quantize, render, and export behave consistently.

Creative extension ideas:

• MIDI learn, Motion Clips, Flux Nodes, and channel-strip automation can eventually share one assignment model: choose a source, choose a target, draw or perform the movement, and keep the result editable.
• Hardware profiles can make MIDI guitar, wind controllers, drum pads, keyboards, and external synths feel guided rather than hostile. Each profile can define pitch-bend range, channel behavior, CC defaults, panic strategy, and suggested routing.
• SysEx can become a SpaceAge librarian/snapshot feature: send a named hardware preset, store notes about it, and recall the setup with explicit confirmation.
• MIDI clips can become the same payload/instance story as Arrangement clips: Clone shares a MIDI payload, Variant duplicates it, and export/stem workflows stay predictable.

Design reminder: MIDI is not a cable hanging off the side of SpaceAge. It is the language between controllers, clips, instruments, automation, hardware, and future VSTs.

2026-06-22 - EchoRay Skinned Effect Editor

Task: Turn the EchoRay delay popup from a generic flat parameter grid into a skinned SpaceAge delay editor that exposes the full parameter set.

Existing connections:

• EchoRay already used the shared EffectDetailOverlay, so the right move was to specialize that reusable editor path instead of creating a separate page or a second effect-management system.
• The same lesson from Redshift applies here: once a processor has enough parameters to shape an instrument-like personality, it needs grouped pages or grouped cards rather than microscopic controls.
• EchoRay now reinforces the emerging product pattern: compact rack cards for quick scanning, detailed skinned panels for serious sound design.

Creative extension ideas:

• The section cards used for EchoRay can become the starting vocabulary for future deep effects such as Cassette Outlander, Sonic Surgery EQ, and more advanced delay models.
• Effect editors can eventually share transport-aware controls such as synced rates, circular note-value selectors, and visual feedback for time-based motion.
• Preset browsing for effects should eventually live inside these detailed panels, letting users treat effects as named creative instruments instead of anonymous utility boxes.

Design reminder: Deep effects should feel playable and memorable, not like spreadsheets hiding in a modal.

2026-06-22 - Redshift Decorative Text Collision

Task: Fix the Redshift editor labels that were visually colliding after the multi-page redesign.

Existing connections:

• The old decorative backdrop labels made sense when Redshift was one big visual panel, but after the internal page split they became competing text inside live control zones.
• Redshift now has real page tabs, dropdown labels, knob labels, and patch readouts, so the backdrop should provide structure and atmosphere without adding redundant language.
• This is a useful rule for future synth skins: decorative panels can frame controls, but customer-facing words should come from actual UI components that participate in layout.

Creative extension ideas:

• Later synth skins can use subtle visual motifs, shapes, and gradients instead of painted text to avoid collisions when controls move or pages change.
• If section guidance is needed, make it a real header component with reserved space, not a painted caption beneath controls.

Design reminder: Visual flavor should support the signal path, not argue with it.

2026-06-22 - Redshift GUI Layout Repair

Task: Repair Redshift's synth editor layout so the rotary controls, readouts, labels, envelope graph, and dropdowns remain readable and consistently spaced.

Existing connections:

• Redshift is the first native synth to receive a more intentionally designed page, so its layout choices should become a reference point for Propulsion 1, Liftoff, Glass Moon, Moonshadow, Lunacy, and Quasar.
• The problem exposed a reusable principle: synth pages should not silently shrink meaningful controls below a usable size. If a page needs more room, the app should use scrolling, paging, or section collapse rather than turning knobs into decorative marks.
• The moon-gradient rotary style is part of the broader SpaceAge visual language, but it only works if the control footprint is large enough for the arc, pointer, and value readout to breathe.

Creative extension ideas:

• A shared synth-page layout helper could eventually support named sections such as Sound Creation, Tone Path, Motion, Envelope, and Space/Output across all tonal engines.
• Section headers could later double as collapsible panels, letting users focus on one sound-design area while preserving a consistent visual map.
• The same layout discipline can inform future effect editor popups, especially Halostar, Cassette Outlander, and the parametric EQ.

Design reminder: A synth editor is not just parameter access. It teaches the user how the instrument thinks.

2026-06-22 - PASP Research And Redshift Page Split

Task: Study Julius O. Smith's Physical Audio Signal Processing material and use it to identify practical SpaceAge DSP improvements. Also clarify Redshift's UI direction after repeated cramped one-page layouts.

Reference docs:

• docs/PASP_DSP_Application_Notes.md
• docs/DSP_Knowledge_Bank.md
• docs/Redshift_Multi_Page_UI_Plan.md

Existing connections:

• PASP-style exciter/body thinking connects directly to Physical Model, Kick Lab, Snare Lab, Hat Lab, Halostar, and future modal instruments.
• Frequency-dependent damping can improve both instruments and effects: plucks, drums, resonators, shimmer, delay, and reverb all benefit when highs and lows decay differently.
• Redshift's UI failure is part of a larger product-design lesson: deep instruments need pages, not microscopic controls.

Creative extension ideas:

• Build a shared modal resonator bank that can be used in Drum Labs, Physical Model, Redshift's Body Comb/Metal Shimmer features, and future effects.
• Treat "Motion" as a reusable concept: Redshift Motion, Chord Engine arp motion, Flux Nodes, Motion Clips, and synced effect modulation can eventually share a common vocabulary.
• Use Redshift's multi-page redesign as the first full example of SpaceAge's synth-editor design language.

Design reminder: Better synthesis is not only better algorithms. It is better translation from algorithm to musician-facing intent.

2026-06-22 - Redshift Multi-Page Implementation

Task: Convert Redshift from one crowded parameter wall into internal pages: Voice, Tone, Envelope, Motion, and Space.

Existing connections:

• This becomes the first concrete implementation of the broader synth-page design language. Future engines should prefer section pages over shrinking controls into unreadable decorative dots.
• Motion controls are not merely UI; they are part of patch identity. Redshift gate depth, rate, and pattern now need to be treated as saveable/dirty-state patch data alongside oscillator, filter, envelope, and send settings.
• Page tabs create room for stronger rotary controls, which keeps the moon-gradient knob language useful instead of fighting for survival at tiny sizes.

Creative extension ideas:

• The same internal-page structure can become a shared SynthPageNavigator pattern for Propulsion 1, Liftoff, Glass Moon, Moonshadow, Lunacy, Quasar, and future effect editors.
• Page-level headers can eventually teach the signal path: source/voice -> tone/filter -> envelope -> motion -> space/output.
• Motion-page controls can later connect to shared Motion Blocks, Flux Nodes, synchronized effect rates, and clip-level modulation without inventing unrelated UI concepts each time.

Design reminder: If a parameter can change the soul of a patch, it must be visible, saveable, and easy to return to.

2026-06-22 - Redshift Patch Ownership Cleanup

Task: Continue Redshift after the multi-page split by giving it explicit ownership of waveform selection and making Redshift patch files remember all audible Redshift-affecting controls.

Existing connections:

• Redshift still inherits some older shared synth parameters, so patch persistence must follow sound behavior rather than UI ancestry.
• The new Voice page now exposes waveform directly, which reduces the old "halfway house" feeling of needing another tab to define a Redshift patch.
• Clear Changed Values now respects the active Redshift internal page, reinforcing the same page-based mental model used for browsing controls.

Creative extension ideas:

• A future RedshiftParameterMap helper should define page ownership, patch persistence, dirty state, reset behavior, and UI labels from one source of truth.
• Other synths can avoid this class of bug by adopting the same rule: every audible parameter belongs to one page and one patch identity list.
• Shared controls can remain technically reusable, but customer-facing synth editors should make ownership obvious.

Design reminder: A patch is not a list of visible knobs. A patch is every decision needed to hear the same sound tomorrow.

2026-06-22 - Redshift Motion Ownership Pass

Task: Move Redshift Filter LFO depth to the Motion page and expose Redshift-owned combo controls for source, filter, velocity-filter, and trigger behavior.

Existing connections:

• Filter LFO belongs with modulation because it describes movement over time, not static tone. This keeps Tone focused on cutoff, resonance, drive, and velocity response.
• Redshift now surfaces older shared parameters in the Redshift editor itself, reducing the need to visit legacy tabs for sound-defining choices.
• Detaching Redshift-specific combo attachments with the rest of the synth editor attachments protects against stale pad bindings when switching targets.

Creative extension ideas:

• The Redshift page map should become a reusable pattern: every synth engine eventually needs a single ownership table for layout, patch persistence, undo/reset behavior, and documentation.
• Page-scoped reset reinforces confidence: a sound designer can clean up Motion without accidentally flattening Voice, Tone, Envelope, or Space.
• Future Motion Blocks can inherit the same mental model: every animated parameter should live near other time-shaping controls.

Design reminder: If a control changes motion, put it where the musician expects motion to live.

2026-06-22 - Redshift Complete Page Ownership

Task: Surface the remaining audible Redshift parameters inside Redshift's own pages and make legacy .sspoly save/load use the canonical Redshift parameter list.

Existing connections:

• The new Redshift pages should replace the old shared synth tabs as the musician-facing editor. If a parameter is saved in a Redshift patch, the user should be able to reach it from Redshift.
• Click controls belong on Voice because they define the attack source. Filter envelope and digital grit belong on Tone because they shape color. Internal room/delay tone belongs on Space because it is part of Redshift's spatial identity.
• Using nativeSynthPatchParameterIdsForEngine(3) for .sspoly keeps legacy compatibility while preventing Redshift save/load lists from drifting apart.

Creative extension ideas:

• Redshift can become the reference implementation for a future per-engine "parameter ownership manifest" that drives UI layout, patch saving, reset behavior, dirty state, and documentation.
• If an instrument page owns every audible parameter, the eventual skinning system can be cleaner because it will not need to decorate hidden legacy controls.
• The same ownership audit should be applied to Propulsion 1, Liftoff, Glass Moon, Moonshadow, Lunacy, and Quasar before their final skin pass.

Design reminder: A beautiful synth editor is not only pretty. It teaches the signal path by where it places decisions.

2026-06-22 - Redshift Gate and Instrument Identity Cleanup

Task: Remove legacy Pad-number wording from non-drum synth editing and make Redshift's Gate Depth/Gate Pattern read as an audible musical gate.

Existing connections:

• The Instrument Bay architecture still uses old pad slots as backing storage in some places, but the musician-facing language should now describe instruments, lanes, patches, and mixer/MIDI routing rather than "Pad 57" unless the user is actually working in the Pads/Drum Composer mindset.
• Redshift's gate controls belong to the larger Motion family: Flux Nodes, Motion Clips, synced effect rates, and future clip decoration all need obvious "turn it up and hear it" behavior.
• X-Mod should be documented as slow cross-modulated movement, not audio-rate FM. If the label creates false expectations, a later UI pass could rename it to "Cross Drift" or "Orbit Mod."

Creative extension ideas:

• Add a shared gateShapeForPattern() helper so Redshift, Propulsion, Liftoff, Glass Moon, Moonshadow, Lunacy, and future effects use the same pattern vocabulary.
• Offer two gate timing modes later: note-triggered for patch character and transport-locked for arrangement/motion precision.
• Use the synth editor title as a small but constant teaching surface: SYNTH ENGINE | Engine | Patch is clearer than exposing implementation slots.

Design reminder: Internal storage names are not product language. If a user cannot make music with the word, hide it.

2026-06-22 - Arrangement Lane Command Panels

Task: Make the Arrangement lane L/S/V buttons mutually replace their open panels instead of forcing the user to manually dismiss one panel before opening another.

Existing connections:

• The lane badge buttons are meant to feel like a compact control surface, not a sequence of modal dialogs. Their behavior should be immediate and panel-like.
• This reinforces the same UI principle used by mixer strip hidden panels: one small control cluster, multiple contextual surfaces, no unnecessary manual cleanup.
• The lane command panel can later host richer controls for lane structure, signal/routing, and view state without making the Arrangement Canvas menu row heavier.

Creative extension ideas:

• The L/S/V panel model could become a reusable "micro-panel" pattern for compact buttons elsewhere: instrument badges, mixer strips, clip controls, and future Motion Clip editors.
• The Lane View panel is a natural future home for ghost-note display, clip interior density, lane background swatches, and persistent lane-collapse choices.
• The Lane Signal panel can grow into the first friendly surface for hardware MIDI channel/filter profiles, which keeps the Instrument Bay clean.

Design reminder: If three buttons form a family, clicking one should politely replace its sibling, not make the musician clean up after it.

2026-06-22 - MIDI Expression Layer

Task: Make incoming MIDI pitch bend and mod wheel work immediately while laying the groundwork for a complete MIDI controller/automation architecture.

Existing connections:

• Arrangement lanes already own MIDI channel/export identity, so live expression must be channel-scoped rather than attached vaguely to a selected clip or pad.
• Native synths, SoundFonts, Quasar/sample playback, and future hardware automation all need one shared expression path so a controller movement and an automation clip can eventually write to the same destination.
• SoundFont vibrato already uses pitch-wheel state internally, so pitch bend and mod wheel must be combined into one expression value instead of overwriting one another.

Creative extension ideas:

• Add a future MIDI Expression Matrix where CCs, pitch bend, aftertouch, velocity, and lane automation clips can be assigned or reassigned to musical targets such as filter cutoff, vibrato depth, wavetable position, grain position, send level, or effect rate.
• Add per-lane controller profiles for keyboard, MIDI guitar, wind controller, drum pads, and hardware synths. Each profile can define pitch-bend range, CC defaults, channel filtering, mono/poly behavior, and panic behavior.
• Motion Clips and MIDI automation clips should share the same editing vocabulary: draw curves, assign target, choose snap/division, audition, copy/paste, and reassign without destroying the musical phrase.

Design reminder: MIDI data is not only note data. Treat expression as first-class musical material so hardware players feel invited rather than merely tolerated.

2026-06-22 - EchoRay Delay

Task: Turn the existing shared tempo delay into EchoRay, a SpaceAge-native vintage-digital delay with input character, tone shaping, modulation, stereo behavior, feedback safety, freeze, and send-friendly wet operation.

Existing connections:

• The current app already has a shared delay return fed by per-pad/channel delaysend, delaytime, and delayfilter controls. EchoRay should upgrade that musical path rather than create a parallel delay that makes mixer routing harder to understand.
• Channel strips, the Effects page, and future effect preset browsing all need to refer to the same effect identity. Human-facing language should say EchoRay; old parameter IDs can remain where they preserve project compatibility.
• EchoRay's tempo-synced repeats use the same BPM/transport clock as the sequencers, Arrangement Canvas, metronome, and Motion Clip ideas. This keeps rhythmic effects feeling composition-aware rather than bolted on.

Creative extension ideas:

• EchoRay presets can become the first test case for a reusable SpaceAge effect-preset browser with category, author, description, A/B, randomize, reset, and favorite metadata.
• Motion Clips could eventually target EchoRay feedback, freeze, repeat age, width, and wet level, turning delay gestures into reusable arrangement objects.
• EchoRay's freeze mode could become a performance lane action: capture a delay cloud at a Section marker, then release it on a transition.
• The input-character stage hints at future rack-inspired effects that are not strict emulations, but musical tools with SpaceAge names, controls, and visual identity.

Design reminder: An effect should be powerful in the popup and obvious in the compact rack. The send path must remain predictable: turn up a send, hear the shared effect, edit one central return.

2026-06-22 - EchoRay and Effects Performance Gating

Task: Reduce the cost of the expanded effects stack after EchoRay pushed the audio stress test over its timing ceiling.

Existing connections:

• EchoRay is a shared return, but its implementation had become pad-wide: when delay was enabled, all 64 pad delay lines were processed every sample even if most pads had no send, no input, and no audible tail.
• Channel-strip sends, Halostar, room reverb, EchoRay, octave, and modulation effects all share the same per-pad send vocabulary. Caching those send values once per block keeps the mixer behavior identical while removing repeated atomic reads inside the per-sample hot path.
• Skipping zero-send modulation writes and inactive delay pads protects CPU headroom for the bigger architectural goal: SpaceAge should feel like a creative workstation, not a synth demo that collapses when the mixer becomes interesting.

Creative extension ideas:

• The same "only process what has musical activity" rule should become a checklist item for every future effect, instrument, Motion Clip processor, and visual analyzer.
• A future effects rack can expose CPU-friendly modes such as Eco, Normal, and Render Quality without changing the musician's routing model.
• Performance telemetry could eventually identify expensive lanes/effects in the UI, helping power users make arrangement decisions before audio crackle arrives.

Design reminder: The prettiest effect in the app still has to disappear politely when nobody is sending audio through it.

2026-06-22 - EchoRay Sync Visibility

Task: Fix the EchoRay popup header collision and make the tempo-sync model visible to the user.

Existing connections:

• EchoRay's rhythmic delay values are currently per channel/pad send via each Delay Time choice, not one global delay-rate control in the shared return. This lets different lanes feed the same delay return at different note divisions.
• The detailed EchoRay popup is a global return editor, so it should explain that routing model instead of pretending all rhythmic timing lives inside the popup itself.
• The popup header needs to teach without colliding with controls. Separating the rack title, sync reminder, combo row, and toggle row keeps the effect page readable.

Creative extension ideas:

• A future EchoRay send mini-editor could open from a channel strip and show send amount, delay note value, per-send filter, and maybe per-send ducking in one compact surface.
• If we later add an optional global time mode, it should be explicit: Per Send, Locked Global, or Free ms, so users understand whether channel-specific rhythmic delays are preserved.

Design reminder: Powerful routing should not feel hidden. If timing lives on the send, the return editor must say so plainly.

2026-06-22 - EchoRay Selected Send Sync Control

Task: Put the note-value delay timing directly inside the EchoRay popup without flattening EchoRay into a single global delay-time effect.

Existing connections:

• EchoRay remains a shared delay return, but each pad/channel send can choose its own synced note value. That is more flexible than one global delay rate and matches the mixer/send architecture already in SpaceAge.
• The Effects page already has a selected-pad send bank. The EchoRay popup now respects that same selected pad/channel by exposing Selected Send Sync, so the musician can edit the rhythmic send value from the deep delay editor.
• The full delay-time list belongs here because a delay popup should show musically meaningful time values: quarter, eighth, dotted, triplet, bars, and very fast divisions.

Creative extension ideas:

• Add a future selected-send strip to every shared effect popup, showing the currently selected source channel, send amount, and any per-send character controls.
• Offer a small "follow selected lane/channel" toggle later so the EchoRay popup can update its selected send target as the musician clicks around the Arrangement or Mixer.
• This pattern can become the bridge between global effect design and per-lane/per-channel expressive routing.

Design reminder: Shared effects can be global and contextual at the same time: edit the return, but never hide the source that is feeding it.

2026-06-22 - Effects Rack Click Affordance and EchoRay Header Cleanup

Task: Make compact effect rack cards read more clearly as clickable buttons and remove the remaining EchoRay popup text collision.

Existing connections:

• The compact Effects page is becoming both a status surface and a launcher for deeper effect editors. If rack cards are clickable, they need a rollover state that behaves like the rest of SpaceAge: visible, confident, but not noisy.
• EchoRay already has a detailed popup with grouped controls. Extra explanatory copy is useful only when it does not compete with controls; the send-sync reminder belongs in the header, while the lower routing tagline was fighting the toggle row.
• The EDIT hover pill gives us a reusable affordance for future rack cards, synth cards, Instrument Bay entries, and any compact surface that opens a deeper editor.

Creative extension ideas:

• A future rack-card hover could also show the most important live status, such as active sends, CPU mode, or whether the effect is receiving signal.
• The same hover language could work for Motion Clip decorators: quiet by default, explicit when the user explores with the mouse.
• EchoRay's removed routing tagline could return later as a tooltip or help-panel sentence, where it teaches without crowding performance controls.

Design reminder: A compact UI can be minimalist and still communicative. The user should never have to guess whether a panel is decorative or interactive.

2026-06-22 - Effects Rack Header Zones

Task: Fix the Effects rack hover pill conflict, left-justify effect names, center Enable toggles, and add more breathing room between compact rack controls.

Existing connections:

• The Effects rack now has three different jobs in each card: identify the effect, toggle it, and open the deeper editor. These actions need separate visual zones so one cue does not collide with another.
• Left-justified effect names match the direction of reading and make the rack feel more like a controllable list of processors than decorative tiles.
• Centering ENABLE leaves the right side available for hover/open affordances, and the same pattern can apply to future Instrument Bay cards, synth sections, and clip decorator panels.

Creative extension ideas:

• Compact cards can eventually show a subtle signal-present glow or send-count indicator without disrupting the title/toggle/open zones.
• A shared "three-zone card header" helper would reduce layout drift as we add more rack-like surfaces.
• The larger row gaps should become a general rule: controls that invite precision need enough empty space around them to feel worth touching.

Design reminder: If a card has multiple actions, reserve visual territory for each action. Minimalism fails when important controls compete for the same pixels.

2026-06-22 - Device-Wide UI Tidying Pass

Task: Apply the Redshift/EchoRay UI cleanup rules across synth engines, drum labs, SoundFont, and the shared effects rack.

Existing connections:

• Redshift proved that instruments feel better when parameters are given section space instead of squeezed into one giant control sheet. The same lesson applies to Propulsion, Liftoff, Glass Moon, Moonshadow, Lunacy, SoundFont, Classic, Physical Model, and the Labs.
• EchoRay proved that compact cards need strict zones: title, enable, and edit/open affordance. This pass applies that thinking to the global Effects page and removes the long Stereo Reverb label in favor of the cleaner Reverb.
• Separating patch/readout rows from descriptive text keeps the GUI from creating false ambiguity. Headers tell the user where they are; control fields let the user act.

Creative extension ideas:

• Glass Moon is now less collision-prone, but it is dense enough to deserve Redshift-style pages later: operators, modulation, envelope, tone, and space.
• A shared synth-section layout helper should eventually replace repeated fixed math. This would make every future engine easier to skin, resize, and audit.
• The same three-zone card concept can later unify Instrument Bay cards, effect rack entries, lane tools, and preset-browser results.

Design reminder: Device polish is not decoration. It is the part of the instrument that teaches the musician where to look, what to touch, and what can safely be ignored.

2026-06-23 - Effects Rack Summary Hierarchy

Task: Continue the device UI polish by making the compact Effects rack readable after EchoRay and Halostar expanded the available control count.

Existing connections:

• The compact rack and the deep effect popup should not try to do the same job. The rack is for scanning, enabling, opening, and touching a few macro controls; the popup is for full sound design.
• EchoRay exposed the danger of showing every parameter everywhere. Six tiny knobs in one card made the rack less usable, even though the detailed editor already had the full parameter set.
• Reserving enough vertical room for selected-pad sends keeps the Effects page honest: global returns are edited above, source sends are managed below.
• Glass Moon and Moonshadow show the same problem in synth form: dense engines need wrapped controls or pages, not one heroic horizontal row.

Creative extension ideas:

• A future rack-card manifest could define each effect's three macro controls separately from its full popup controls.
• Rack cards could eventually show signal-present glow, send count, or CPU mode without increasing knob clutter.
• This same summary/deep-editor split should guide Instrument Bay cards, preset browser cards, lane badges, and future Motion Clip decorators.

Design reminder: A compact card is a doorway, not a storage closet. If everything is visible at once, nothing is legible.

2026-06-23 - Documentation Nomenclature Cleanup

Task: Normalize project documentation around the current product identity, Redshift naming, Halostar/Reverb/EchoRay effect names, and the lane-owned Instrument Bay architecture.

Existing connections:

• The app has crossed an architectural threshold: melodic lanes are no longer supposed to be psychologically or technically dependent on pad numbers. The docs now need to teach that truth instead of preserving the old halfway-house language.
• Redshift is the current customer-facing synth name. Keeping PolySynth wording in active docs would make preset design, support notes, and future UI copy feel internally inconsistent.
• Halostar, Reverb, and EchoRay are separate creative tools, not generic delay/reverb placeholders. The docs now reflect that separation so routing bugs are easier to spot and explain.

Creative extension ideas:

• Instrument Bay can become the language bridge between sound design, lane assignment, preset browsing, and future VST/hardware profiles.
• A future docs lint pass could flag stale names automatically: PolySynth, instrument registry, Stereo Reverb, and pad-owned melodic wording.
• The same source-of-truth discipline can later drive tooltips and onboarding text, so the user learns the app's real model from inside the app.

Design reminder: Nomenclature is interface design. If the words imply the wrong architecture, users will fight the workflow even when the code is correct.

2026-06-23 - Device Info Text Moved To Manual

Task: Remove fixed instructional lines from synth and drum lab pages while preserving the copy for a future manual/reference page. Leave Quasar's text alone because it is workflow/status guidance, not generic device description.

Existing connections:

• Redshift, Propulsion 1, Liftoff, Glass Moon, Moonshadow, Lunacy, Kick Lab, Snare Lab, and Hat Lab need their vertical space for controls. Permanent teaching copy becomes expensive once the device pages become serious instruments.
• Quasar and SoundFont are different cases. Quasar needs visible capture/package guidance, and SoundFont needs a loaded-state readout. Those lines are functional, not ornamental.
• The removed device descriptions now live in Manual_Device_Reference_Notes.md, which can seed the manual, help overlay, or future hover-info system.

Creative extension ideas:

• Every device page could eventually have a compact help icon that pulls from the manual notes instead of reserving permanent screen space.
• The same pattern can help with effects: compact rack cards stay clean, deeper help appears only when summoned.
• A future onboarding/manual page could use these entries as short "what is this thing?" blurbs beside screenshots.

Design reminder: Teaching text should be available, but not always in the musician's way. Put the explanation one click away; give the controls the stage.

2026-06-23 - Device Page Breathing Room

Task: Clean up the EchoRay deep editor, align deep effect knobs with the outer rack's orange-line style, split Glass Moon into internal pages, and remove unnecessary EQ tab separator lines.

Existing connections:

• Redshift proved that pages are better than shrinking controls. Glass Moon now follows that principle by separating operators from tone/space controls.
• EchoRay's deep editor and the outer Effects rack need to feel like the same product. The popup should expose more parameters, not switch visual languages.
• The Synth Edit EQ tab already has a strong graph and parameter layout; extra horizontal rules make it look boxed-in without helping the user understand anything.

Creative extension ideas:

• A shared DevicePage layout helper could eventually manage title rows, page buttons, combo rows, knob grids, and graph sections for every synth/effect.
• Deep effect popups could inherit a manifest of macro controls and full controls, ensuring the compact rack and detailed editor stay visually consistent.
• Glass Moon's operator/global split can become the pattern for future FM/additive/spectral engines where control count naturally grows.

Design reminder: If a control page starts needing tiny knobs, it is usually asking for another page, not another compromise.

2026-06-23 - Header-Level Clear And Generic Synth Patches

Task: Move Clear Changed Values out of the lower-right synth pages and add preset save/load support to the generic SYNTH page.

Existing connections:

• Clear Changed Values already had page-specific reset logic. Moving it to the drawer header preserves the behavior while removing repeated collision points inside crowded synth pages.
• The generic SYNTH engine can use the same native .ssynth patch format as Classic, Physical Model, Kick/Snare/Hat Labs, Propulsion, Liftoff, Glass Moon, Moonshadow, and Lunacy.
• The patch readout/dirty-state system should not care whether an engine is old or new. Engine 0 now participates in the same displayed patch identity pattern.

Creative extension ideas:

• A future unified preset browser can treat Native Synth patches as first-class historical SpaceAge sounds rather than leaving them as a legacy corner.
• Header-level commands can become a small stable command strip for active-engine actions: clear, compare, randomize-safe, save, load, and help.
• The active-tab reset pattern can be reused later for effects popups, where Reset This Page may be safer than resetting an entire complex effect.

Design reminder: If a command applies to the active device view, the header is often the safest home. It stays visible, avoids covering controls, and teaches that the command belongs to the currently selected context.

2026-06-23 - Synth And Effect Page Readability

Task: Continue the broad device UI cleanup by giving EchoRay's detailed popup more breathing room, making its knobs visually match the orange-ring rack style, and splitting Glass Moon into smaller internal pages.

Existing connections:

• Redshift's page model is proving to be the right answer for dense instruments: large controls, fewer sections per view, and page buttons that feel like instrument panels rather than emergency overflow.
• EchoRay and the outer Effects rack should look like members of the same hardware family. The popup can show more controls, but it should not switch to a smaller, stranger knob language.
• Glass Moon is naturally divided into operator work and global tone/space work. Splitting OP 1-2 from OP 3-4 keeps FM-style editing legible without throwing away the existing parameter model.

Creative extension ideas:

• A future reusable DevicePage helper could define pages, combo rows, slider grids, and ADSR/graph blocks declaratively so every new synth starts with clean geometry.
• Glass Moon's OP-page split can be reused for future FM/additive engines, especially if we add copy/paste operator tools or per-operator randomization.
• The same "compact overview, detailed page" idea can eventually apply to Motion Clips, Flux Nodes, and channel strip panels.

Design reminder: When the controls get smaller than the musician's confidence, make another page. The app should feel deep because it is organized, not because it is crowded.

2026-06-23 - Lab Headers And Effects Affordance

Task: Make the Kick/Snare/Hat Lab headers breathe better and make the Effects rack cards read more clearly as editable buttons.

Existing connections:

• The Drum Labs already have useful sound-design depth. Splitting preset identity from action buttons mirrors the direction of the Redshift page work: first show what is loaded, then show what can be done.
• The Effects rack is both a status display and an entrance into deeper controls. A persistent edit pill teaches that the boxes are interactive even before the user discovers the rollover.
• Flux Nodes made the Labs feel alive; clearer Lab headers help preserve that feature as a first-class part of the workflow rather than a crowded extra.

Creative extension ideas:

• Effect rack cards could eventually show tiny animated signal traces or send activity, making them both buttons and living time/signal objects.
• Lab headers could adopt the same command strip pattern as tonal synths: save, load, render, randomize/flux, compare.
• A reusable card-affordance helper could standardize hover, selected, bypassed, and edit states across effects, lanes, clips, and future Instrument Bay tiles.

Design reminder: A clickable card should invite the click before the tooltip has to explain it.

2026-06-23 - Device UI Regression Recovery

Task: Recover the EchoRay deep editor and dense synth pages after the previous layout pass made several pages look crowded or broken. Use smaller text and tighter text boxes to reclaim room instead of shrinking controls into unusable fragments.

Existing connections:

• EchoRay already had a usable detail-page layout. The right move was to restore that geometry and make the per-control labels smaller, not keep expanding gaps until the controls collided.
• Liftoff exposed a real layout bug: it had more controls than the hard-coded row count could display. Computing the row count from the number of controls makes the page safer as future parameters are added.
• Propulsion 1, Liftoff, Moonshadow, and Lunacy are all dense enough that they need a shared compact-control label style. This is a typography problem more than a knob-size problem.

Creative extension ideas:

• The dense-device label style should become a named look-and-feel token so future synths can opt into it deliberately instead of each page inventing spacing.
• A future device-layout audit could flag pages where controlCount > columns * rows, preventing hidden bottom-row controls before a human tester finds them.
• EchoRay's restored popup geometry is a reminder that a working page should be treated as a baseline before adding polish.

Design reminder: When a page runs out of room, first ask whether the text is too large or the grouping is wrong. Shrinking the musician's controls should be the last resort, not the first.

2026-06-23 - Instrument Language Guardrail

Task: Stop the Synth Editor from leaking pad-slot language when it was opened from an Arrangement lane. Keep the internal backing slot untouched for now, but format the visible title as lane/instrument/mixer/MIDI context.

Existing connections:

• Arrangement lane badges already teach the right mental model: one lane owns one Instrument and routes to a mixer channel/MIDI channel.
• The Synth Editor still uses pad-backed storage internally, which is acceptable scaffolding only if the user-facing language does not imply that melodic lanes are secretly Pads.
• The future Instrument Bay should replace raw 64-slot iteration with real Instrument records, but this label cleanup is a safe bridge toward that architecture.

Creative extension ideas:

• The Synth Editor title can later become a compact breadcrumb: Lane > Instrument > Engine > Patch, with each segment clickable.
• A future Instrument Bay card could reuse the same formatter so lane badges, editor titles, preset browser entries, and mixer strips all speak the same language.
• Once instrumentId records exist, the editor can show a stable human name like Instrument 12: Vega Keys without revealing any storage detail.

Design reminder: Temporary architecture should not become permanent vocabulary. Users should learn the model we intend to keep.

2026-06-23 - Effect Detail Dial Geometry

Task: Stabilize the detailed Effects popups, especially EchoRay, by separating labels, knobs, and value readouts with real breathing room while keeping the desired orange-ring/moon-dial family style.

Existing connections:

• EchoRay is the first complex effect editor that behaves more like a synth page than a simple rack card. Its layout rules should become a prototype for future detailed effects such as Cassette Outlander, parametric EQ, and advanced delays.
• Redshift taught us that "more pages, larger controls" is better than "everything at once, tiny controls." The effect detail popup should follow that same principle as soon as any effect outgrows a clean single panel.
• The outer Effects rack and deeper editor should share one knob family so the user feels they are opening the same device, not jumping into a different UI system.

Creative extension ideas:

• Future effect detail pages could expose a compact macro row at the top and deeper tabbed sections below, mirroring the synth-engine page language.
• A reusable DeviceDial component/style token could carry size, label spacing, readout placement, and moon-gradient intensity across synths, effects, channel strips, and Flux Nodes.
• Effects with tempo-aware controls can use the same geometry to host a small sync selector near the dial without crowding the main value readout.

Design reminder: A knob is not just a circle. It needs a label, a readable value, and enough empty space around it that the musician trusts it.

2026-06-23 - Processor-Owned MIDI Input Arming

Task: Move Arrangement lane MIDI input arming out of editor-only state and into processor/project state, without changing the visible lane-button workflow yet.

Existing connections:

• The Arrangement Canvas already treats lanes as musical instruments with mixer and MIDI identity. MIDI arming belongs to that same project model, not to a temporary editor variable.
• This connects directly to future hardware workflows: MIDI guitars, wind controllers, keyboard controllers, and external synths all need predictable project-owned input targets.
• Saving the armed lane means a project can reopen in the same performance-ready state, which matters once SpaceAge becomes both standalone and plugin.

Creative extension ideas:

• The lane badge could later display a small "input listening" animation when incoming MIDI is routed there.
• Hardware profiles could hang off this same lane-owned routing state: "Wind controller on channel 2," "MIDI guitar MPE-ish split," or "External XG module."
• The eventual Instrument Bay can treat arming as part of an instrument's routing card: monitor, record, MIDI channel, hardware profile, and controller-map all in one place.

Design reminder: MIDI routing is not a temporary UI mode. It is part of the song's instrument map.

2026-06-23 - Channel-Aware MIDI Recording

Task: Make MIDI recording note tracking channel-aware so overlapping notes with the same pitch on different MIDI channels do not cancel each other.

Existing connections:

• MIDI guitar workflows often use one channel per string. The same pitch can appear on multiple strings/channels, so note tracking by pitch alone is not enough.
• Wind controllers and expressive hardware may also depend on per-channel pitch bend or CC expression, so this prepares the recorder for richer expression capture.
• The Arrangement lane MIDI-channel system already treats channel as meaningful; recording needs to respect that same reality.

Creative extension ideas:

• Future Piano Roll note objects could show subtle channel badges only when a clip actually contains multiple channels.
• A "MIDI performance microscope" could inspect a recorded clip and show channels, bends, CCs, aftertouch, and sustain lanes in one focused view.
• Hardware profiles can decide whether channel information should be preserved, collapsed, or remapped during recording.

Design reminder: If the performer played it on a specific channel, SpaceAge should not casually erase that fact.

2026-06-23 - Piano Roll Note MIDI Channel Persistence

Task: Store, save/load, import, and raw-export the MIDI channel on Piano Roll notes.

Existing connections:

• The prior channel-aware recording pass prevented note-off collisions, but the resulting note still needed to remember which channel created it.
• Arrangement lanes should continue to own orchestration/output channel behavior, while raw pattern clips can preserve the performer's original channel data for hardware workflows.
• MIDI import now has a better landing zone for multi-channel files before we build full controller/expression lanes.

Creative extension ideas:

• A future inspector can offer "Respect recorded channels" versus "Force to lane channel" for advanced hardware and MIDI-guitar users.
• Piano Roll ghosting could eventually color or badge notes by channel when a clip contains multiple channels.
• Chord Engine and arpeggiator output could later choose between lane-channel output, source-channel output, or split-channel voice assignment.

Design reminder: Lanes orchestrate the song, but clips can still preserve the fingerprints of the performance.

2026-06-23 - MIDI Event Persistence Resurrection

Task: Make serialized MidiEvent records reconstruct their raw juce::MidiMessage when loaded back from JSON.

Existing connections:

• MidiEventList is intended to become the shared payload for CC, pitch bend, aftertouch, program changes, and SysEx.
• Without raw-message restoration, saved expression events would look correct in metadata but fail when rendered back into a MIDI buffer.
• This pairs naturally with future "MIDI performance microscope" tools because both the readable metadata and the original bytes survive.

Creative extension ideas:

• A future event inspector could show both musician-friendly labels and raw hex for hardware users diagnosing SysEx or controller quirks.
• Hardware profiles can use preserved raw bytes to verify that an exported or replayed performance still matches what a device originally sent.
• SysEx librarian workflows can attach names and safety notes while keeping the original data intact.

Design reminder: A MIDI event is not truly persisted unless it can become a real MIDI message again.

2026-06-23 - Pattern-Level MIDI Expression Payloads

Task: Add a processor-owned pattern payload for MIDI expression events, covering the storage layer for CC, pitch bend, aftertouch, sustain, program/bank, and later SysEx references without changing playback yet.

Existing connections:

• Piano Roll notes and Chord Markers already live as pattern payloads, while Arrangement clips are timeline instances. MIDI expression belongs with the pattern payload so CLONE/VARIANT/copy logic can carry the performance data with the musical idea.
• The Instrument Bay and lane-owned MIDI routing work better if expression is not hidden inside editor state or one-off UI controls.
• Pattern content detection now sees controller-only clips, which protects future automation/MIDI-performance clips from being overwritten by "next empty" pattern logic.

Creative extension ideas:

• Expression lanes can later become visible beneath Piano Roll notes: mod wheel, sustain, pressure, pitch bend, and arbitrary CC curves.
• Hardware profiles could filter which expression streams are recorded for a MIDI guitar, wind controller, keyboard, drum controller, or external synth.
• Chord Engine arps could render into notes plus expression payloads, creating reusable performance gestures that survive clip duplication and arrangement edits.

Design reminder: MIDI expression is part of the performance, not decorative metadata. Store it beside the notes before trying to make it pretty.

2026-06-23 - MIDI Expression Playback and Export

Task: Route stored pattern-level MIDI expression events into live playback and MIDI export using JUCE MidiMessage/MidiBuffer/MidiMessageSequence paths.

Existing connections:

• Arrangement lanes already own output-channel identity for notes and chords, so expression events now follow the same lane-channel rule during Arrangement playback/export.
• Raw pattern export preserves original MIDI channels, keeping imported performances useful for MIDI guitar, wind controller, and hardware workflows.
• The generic pending MIDI-message queue is the first reusable bridge toward visible automation lanes, controller curves, sustain lanes, aftertouch, program changes, and SysEx librarian workflows.

Creative extension ideas:

• The same event-range helper can later power "render selected clip to MIDI," clip-local automation, and hardware preset dumps.
• A future expression editor can present CC, pitch bend, aftertouch, and sustain as editable lanes without changing the storage model again.
• Clip previews could eventually show tiny controller/automation traces beneath note previews, giving MIDI clips their own living-time visual language.

Design reminder: If a lane is the instrument's patch cable, expression events must ride that cable too.

2026-06-23 - MIDI Expression Recording

Task: Record incoming controller and expression messages into the same pattern-level MIDI expression payload used by playback and export.

Existing connections:

• MIDI recording no longer treats performance expression as second-class. Notes, pitch bend, mod wheel, expression, sustain, pressure, and program-style events can now converge on one pattern payload model.
• The same payload travels through CLONE/VARIANT, project save/load, live playback, and MIDI export, which protects hardware and expressive-controller workflows from becoming separate code paths.
• This strengthens MIDI guitar and wind-controller support because those players depend on pitch bend, pressure, CC, and performance gestures as musical content, not merely automation.

Creative extension ideas:

• Visible expression lanes can now be a UI layer over real captured data instead of a future rewrite.
• A "MIDI performance microscope" could inspect recorded curves and show channel, controller type, raw value, and musical meaning.
• Hardware templates can later decide which controller streams are armed, filtered, thinned, quantized, or passed through.

Design reminder: If SpaceAge records a human performance, it should remember the hand movement, breath, wheel, pedal, and bend as faithfully as the note.

2026-06-23 - SysEx Safety Boundary

Task: Keep SysEx out of automatic performance recording, playback, and MIDI export while preserving it as a future librarian/snapshot feature.

Existing connections:

• SpaceAge is moving toward hardware-friendly workflows, but hardware friendliness cannot mean silently sending device dumps during playback.
• MIDI expression lanes are for performance gestures. SysEx belongs in an explicit, named, confirmed hardware-management workflow with throttling and device context.
• The same boundary will matter for future MIDI hardware profiles, because a safe profile can advertise exactly which message types it records, filters, and sends.

Creative extension ideas:

• A future SysEx Vault could store device snapshots beside projects without attaching them to the musical timeline.
• Hardware setup wizards could offer "capture current patch" and "send patch to device" flows with warnings, progress, and retry handling.
• Project archives could include SysEx snapshots as collaborator-safe optional assets, clearly separated from note/performance data.

Design reminder: SysEx is powerful enough to deserve ceremony.

2026-06-23 - Longer MIDI Recording Timing

Task: Move MIDI recording placement away from the old fixed step-grid assumption and toward the selected pattern's actual stored length.

Existing connections:

• Arrangement clips already support long musical spans, so the recorder must not silently compress performance data into an older 64-step mental model.
• Pattern length is now part of the MIDI performance contract: notes and expression events should live in the same time domain as the clip that will later play them.
• This directly supports imported longer MIDI files, extended Piano Roll clips, future takes, and expressive controller passes.

Creative extension ideas:

• A future take-lane recorder could capture several passes into the same long clip without rewriting the timing model again.
• Recording count-in, punch-in, and loop-recording can reuse this pattern-length awareness instead of inventing separate rulers.
• The same foundation can support MIDI guitar bends and wind-controller expression over long melodic phrases.

Design reminder: A long clip should feel long to the recorder, not just to the arranger.

2026-06-23 - MIDI Channel Release and Panic Conformity

Task: Harden live MIDI monitoring, recording preview, and panic behavior so they behave like standard MIDI systems rather than channel-blind note triggers.

Existing connections:

• Piano Roll notes already preserve MIDI channel, and arrangement lanes can force output channels. Live monitoring now follows the same rule so pitch bend and mod wheel stay tied to the voice/channel that created the note.
• Panic now resets both internal expression state and external MIDI devices with pitch bend center, mod wheel zero, All Sound Off, Reset All Controllers, and All Notes Off across all 16 channels.
• Expression payload storage now filters SysEx at the setter boundary, matching the existing record/play/export safety rule.

Creative extension ideas:

• MIDI guitar and wind-controller profiles can safely rely on overlapping same-pitch notes on different channels without one note-off killing the wrong voice.
• A future MPE-style lane could use this same per-channel discipline before we expose per-note pitch curves or pressure editing.
• A hardware panic/readiness indicator could show whether SpaceAge has sent reset traffic after a stuck-note event, turning a scary audio moment into a recoverable workflow.

Design reminder: Channel is not trivia. For expressive MIDI performers, channel is part of the instrument.

2026-06-23 - MIDI Sustain and Channel Expression Conformity

Task: Make sustain pedal, channel volume, expression, and pan affect internal playback instead of existing only as recorded/exported MIDI data.

Existing connections:

• The MIDI expression payload can already store and route CC64, CC7, CC10, and CC11, so the audio engine now listens to the same event stream that export/hardware receive.
• Arrangement lanes own MIDI-channel identity. Internal voices now use the lane channel during arrangement playback, which keeps pitch bend, mod wheel, sustain, and CC expression tied to the right lane.
• Panic and Reset All Controllers now clear the same channel state that live playback uses, making stuck-note recovery and hardware reset behavior consistent.

Creative extension ideas:

• Future visible expression lanes can expose sustain, channel volume, expression, and pan as editable performance curves without changing the playback model again.
• MIDI guitar and wind-controller profiles can add pressure and per-string/per-channel policy on top of this channel-state layer.
• Hardware setup wizards can test a lane by sending CC64, CC7, CC10, and CC11 and showing the audible result, making controller mapping feel trustworthy.

Design reminder: If SpaceAge records a controller gesture, internal playback should either honor it musically or intentionally label it as hardware-only. Silent metadata is how confusion sneaks in.

2026-06-23 - MIDI Pressure Fallback Reconstruction

Task: Make poly aftertouch and channel pressure rebuild valid JUCE MIDI messages from saved event fields when raw MIDI bytes are missing.

Existing connections:

• The MIDI event model already classifies pressure messages, and recording can store them as expression payloads.
• Older or hand-authored project data may not always carry rawMidiHex, so fallback reconstruction must not drop pressure events.
• This supports future MIDI guitar, wind controller, and MPE-like workflows where pressure is musically meaningful.

Creative extension ideas:

• Pressure can become a first-class modulation source in synth patches, mapped per lane or per instrument.
• A future expression editor can show pressure curves next to pitch bend and CC lanes.
• Hardware profiles could translate channel pressure into vibrato, filter opening, amplitude, or timbral brightness depending on the controller type.

Design reminder: Preserve the expressive data first; decide its musical routing with the user later.

2026-06-23 - Lane MIDI Input Filters and Customer-Facing Routing

Task: Separate "this lane listens to my controller" from "this lane plays/exports on this MIDI channel."

Existing connections:

• Arrangement lanes are becoming the central customer-facing place where instruments, mixer channels, MIDI channels, mute/solo, and editing entry points live.
• The Instrument Bay direction depends on lanes being self-explanatory; a global top inspector or overloaded MIDI button would pull us backward into the confusing proxy workflow we are retiring.
• MIDI guitar, wind controller, external hardware, and future plugin-host workflows all need input filtering without changing the lane's playback/export identity.

Creative extension ideas:

• A future Lane MIDI Routing card can add input device, output device, channel filter, monitor mode, and record mode without changing the storage concept introduced here.
• Hardware profiles can pre-fill input filters: a wind controller might default to Omni or one channel, while MIDI guitar profiles might use a channel range or per-string policy.
• The visible ARM / MIDI IN button can eventually show a tiny state badge for Omni vs fixed channel, giving users confidence before they record.

Design reminder: A lane should teach its own routing. The user should not need to remember a hidden inspector to know where their MIDI is going.

2026-06-23 - MIDI Routing Language Hardening

Task: Make the lane MIDI input filter, live input arm state, and playback/export channel visually distinct in menus, tooltips, status text, and lane badges.

Existing connections:

• The backend already separates midiInputChannel from midiChannel; the UI now needs to teach that separation rather than hiding it behind repeated MIDI CHANNEL labels.
• The lane badge is becoming the user's trusted routing surface, so it must show both live-input state and playback/export state without sounding like duplicate controls.
• Pattern MIDI drag/export copy now clarifies that it creates a MIDI file instead of sending live MIDI to hardware.

Creative extension ideas:

• A future Lane MIDI Routing card can group Input Device, Input CH, Monitor, Record Mode, Play/Export CH, and Hardware Profile without changing the vocabulary again.
• MIDI guitar and wind-controller presets can use the same labels to make complex input routing feel instructional instead of technical.
• Tooltips can eventually become mini routing lessons: "Input is where your hands enter; Play/Export is where the lane speaks."

Design reminder: Names are interface architecture. If two labels look the same, users will assume they do the same thing.

2026-06-23 - Incoming MIDI Policy Extraction

Task: Move the real-time incoming MIDI decision tree out of processBlock into a named helper while preserving behavior.

Existing connections:

• The lane MIDI input filter, live-note mask, expression state, recording, step input, live monitoring, pad fallback, and performance CC fallback already form one ordered policy.
• Naming that policy as handleIncomingMidiMessage gives future MIDI features one obvious place to enter without burying new behavior in the full audio render loop.
• The reset-message bypass test protects the safety rule that panic/reset traffic must still land even when a lane is listening only to a fixed input channel.

Creative extension ideas:

• A future routing card can map directly to this helper: input filter, monitor mode, record mode, and hardware profile become policy inputs rather than scattered conditions.
• Automation and Motion Clips can eventually reuse the same ordering discipline: capture first, monitor second, fallback last.
• The helper creates a natural seam for future MIDI 2.0/MPE handling without forcing us to rewrite synthesis or clip storage at the same time.

Design reminder: Real-time MIDI policy is choreography. Preserve the order before adding flair.

2026-06-23 - Lane-Owned MIDI Route Bridge

Task: Give Arrangement Lanes a normalized MidiTrackRoute while preserving the existing midiInputChannel and midiChannel fields as compatibility mirrors.

Existing connections:

• The Arrangement Lane badge is already the user's trusted place for instrument, mixer, MIDI input, mute, solo, and variant controls.
• MidiTrackRoute already existed as the richer MIDI track model; binding it to lanes turns the lane into the obvious future home for input device, input channel, monitor, record mode, playback/export channel, hardware profile, and eventual external output routing.
• Keeping the legacy integers as mirrors means old projects keep loading without asking the user to understand the migration.

Creative extension ideas:

• The L/S/V lane buttons can eventually open a Lane Routing card without inventing a top-level MIDI inspector again.
• MIDI guitarist and wind-controller presets can become lane route templates: "Guitar Omni Split," "Wind CC2 Breath," "Hardware XG Channel 1," etc.
• Motion Clips and automation lanes can attach to the same route object later, making "what plays where" and "what modulates what" part of one lane-local mental model.

Design reminder: The lane is the track. The track should own the route.

2026-06-23 - Shared MIDI Recording Position Policy

Task: Extract note-recording and MIDI-expression-recording latency compensation into one shared helper.

Existing connections:

• MIDI notes, pitch bend, modulation, sustain, and other expression messages all describe the same performance moment. They should never disagree about where that moment lands in the pattern.
• getRecordStepPosition already translates block/sample timing into musical step position; the new compensation helper is the next layer above that, applying record latency and wraparound consistently.
• The regression test records a note and CC event at the start of the block with latency compensation active, proving both wrap near the end of the pattern together.

Creative extension ideas:

• This policy object can later become the timing home for MIDI 2.0 per-note expression, MPE, and hardware controller capture.
• A future "Record Feel" panel could expose latency compensation, input quantize, and performance nudge as one musician-facing concept instead of scattering them across settings.
• The same shared timing helper can support step input, automation clips, and Motion Clips if we decide they need record-latency compensation.

Design reminder: A performance is one event stream with many kinds of data. The timing math must be shared before the UI can feel trustworthy.

2026-06-23 - Armed Lane MIDI Recording Route

Task: Make melodic MIDI recording respect the armed Arrangement Lane's instrument and MIDI output channel.

Existing connections:

• Lane badges already teach the user that ARM, MIDI IN, the lane instrument, mixer channel, and MIDI channel belong together.
• Recording through that armed lane should therefore store notes with the lane's instrument pad and route channel, not the generic Piano Roll pad or the incoming controller's channel.
• The note-on/note-off matcher still uses the incoming MIDI channel and note number, so controllers remain stable even while the recorded clip is lane-owned.

Creative extension ideas:

• This is the first backend step toward a proper Lane Recording panel: input device, input channel, monitor mode, output channel, and clip destination can all be explained in one place.
• Drum-lane recording should get a dedicated follow-up that records pad-grid steps rather than melodic notes, keeping the MPC-style paradigm honest.
• Future hardware templates can map controller input to lane-owned internal instruments or external MIDI outputs without changing the recorded clip format.

Design reminder: If a lane is armed, the user expects the lane to own the take.

2026-06-23 - Lane-Aware Selected MIDI Export

Task: Make selected Arrangement clip MIDI export obey the clip's lane route, source range, repeats, and transpose while preserving raw pattern export when no specific clip is selected.

Existing connections:

• Whole-arrangement MIDI export already treats clips as lane-owned song objects; selected clip export should not silently fall back to raw pattern channels.
• The Arrangement Lane badge now teaches instrument, mixer, MIDI input, and playback/export channel as lane-local truth, so drag/export needs to reinforce that same truth.
• Raw pattern export still matters for standalone Sequencer/Piano Roll work, so the new behavior only activates when the user has one real Arrangement clip selected.

Creative extension ideas:

• A future right-click clip menu can expose Export Clip MIDI, Export Clip Audio, and Render Clip to Sample using the same lane-aware dispatch.
• Clip export can later include ghost-note, chord-marker, and Motion Clip metadata as optional companion files without changing the core MIDI path.
• If we add external hardware lanes, this same selected-clip export rule becomes a "send this exact song object to collaborator/hardware/DAW" workflow.

Design reminder: A selected object should export as the object the user sees, not as a hidden payload with different routing.

2026-06-23 - Lane MIDI Routing Card

Task: Split Arrangement Lane MIDI routing into its own lane-local card instead of hiding input and playback/export channels inside the lane instrument chooser.

Existing connections:

• The Arrangement Lane badge already teaches the user that a lane owns its instrument, mixer channel, MIDI input state, mute/solo state, and clip destination.
• ArrangementLane::midiInputChannel, ArrangementLane::midiChannel, and the mirrored MidiTrackRoute are already normalized in the processor, so the UI can edit the existing lane truth instead of introducing a new top inspector.
• The Lane Signal button is already the right mental doorway for routing because it lives beside the lane and does not compete with pattern, clip, or synth editing controls.

Creative extension ideas:

• The same card can grow into output device selection, hardware profiles, MPE/MIDI 2.0 channel mode choices, and SysEx snapshot assignment without changing where users look.
• MIDI guitar, wind controller, and external synth workflows can become route presets on this card: input filter, performance CC expectations, output channel, and device profile as one saved object.
• A future "Record Feel" section could live here or link from here, keeping input quantize, latency compensation, and monitoring close to the lane that owns the performance.

Design reminder: Instrument choice answers "what makes sound?" MIDI routing answers "how does performance data reach it?" They belong together at the lane, but not in the same popup.

2026-06-23 - Repo-Local Build Scripts

Task: Replace long one-off build/test/package shell commands with short repo-local PowerShell scripts.

Existing connections:

• SpaceAge's iteration loop depends on building, testing, packaging, and pushing frequently; the previous long commands created approval friction and made it harder to run larger autonomous passes.
• The build output already lives in a known CMake build directory, so a small scripted wrapper can preserve the current setup without relocating the toolchain.
• Documentation in Build_Test_Package_Workflow.md gives future Codex sessions and human collaborators the same simple commands.

Creative extension ideas:

• These scripts can grow into a one-command release checklist: run tests, build, package, generate checksum, update release notes, and optionally push tags.
• CI can eventually call the same scripts, reducing the gap between local beta builds and automated release verification.
• If we add Linux builds, this folder becomes the natural place for parallel build_linux.sh and package_linux.sh scripts.

Design reminder: Developer workflow is product workflow in disguise. Less babysitting means more attention stays on the music-making experience.

2026-06-23 - Persistent Lane MIDI Route Intent

Task: Preserve richer Arrangement Lane MIDI routing data through project save/load instead of flattening every lane back to an internal-only target.

Existing connections:

• The Lane Signal card is becoming the musician-facing home for MIDI input, playback/export channel, and future hardware output. Its choices must be project state, not temporary UI decoration.
• Instrument Bay and hardware profiles will eventually need the same route identity: chosen device, input filter, output channel, target mode, and panic/reset policy.
• SysEx snapshots and hardware patch recall should attach to this lane-owned route identity later, while staying out of the automatic live MIDI path until the user explicitly asks for hardware recall.

Creative extension ideas:

• A future lane badge could show a small hardware-output glyph when the route target includes an external device.
• Hardware profiles could offer friendly labels like "QY-100 Part 04" while still storing the precise MIDI output device id and channel underneath.
• Arrangement export could eventually offer "Render MIDI for external rig" by walking these lane routes and writing clear track names/device hints into the MIDI file metadata.

Design reminder: Saving the intention to drive hardware is not the same thing as opening a MIDI output and sending data. Keep those responsibilities separate so SpaceAge stays predictable and safe.

2026-06-24 - Lane Route Target Choice

Task: Add a lane-local route target selector so users can explicitly choose whether a lane is intended for internal instruments, hardware, internal plus hardware, or export-only behavior.

Existing connections:

• This extends the Lane MIDI Routing card without bringing back the deprecated top inspector.
• The route target lives beside input filter, playback/export channel, and hardware output assignment, which keeps all performance-routing language in one lane-owned place.
• The saved route target gives the future external MIDI output sender a clear policy instead of guessing from the presence of a device id.

Creative extension ideas:

• Hardware-only lanes can later become a natural home for vintage modules, drum machines, Eurorack MIDI-to-CV boxes, and Yamaha XG devices.
• Export-only lanes could hold guide parts, chord references, or collaborator MIDI without cluttering the audio mix.
• Internal plus hardware can become a powerful layer/split workflow when paired with lane mutes, mixer routing, and future hardware profile names.

Design reminder: Explicit routing intent protects the user from surprises. The lane should always tell the truth about where its performance data is supposed to go.

2026-06-24 - Hardware MIDI Output Owner

Task: Add a processor-owned hardware MIDI output layer so generated arrangement notes/controllers can reach external devices without the audio thread opening or managing hardware.

Existing connections:

• Builds directly on lane-owned route intent instead of adding another global inspector.
• Uses the same generated MIDI queue that already feeds plugin MIDI output/export, but adds lane identity so each lane can target its own hardware output.
• Keeps hardware output distinct from live MIDI input, which prevents accidental MIDI thru loops.

Creative extension ideas:

• Hardware-only lanes can become a guided “external synth lane” workflow with device names, profile notes, and saved program-change/SysEx snapshots.
• Internal plus hardware lanes can layer Redshift/Quasar with a real module for hybrid sound design.
• The same queue/owner pattern can later serve MIDI clock out, transport sync, and carefully-confirmed SysEx dumps.

Design reminder: The app should feel effortless, but the routing underneath must be explicit. If a lane is driving hardware, the lane badge/card should say so clearly and give the user a safe off-ramp.

2026-06-24 - Lane Route Target Semantics

Task: Make the saved lane route target choices behave differently during live Arrangement playback instead of acting as labels only.

Existing connections:

• Builds on lane-owned MIDI routing and the processor-owned hardware output router.
• Keeps MIDI export independent from live playback routing so Export Only remains useful for collaborators and hardware-prep workflows.
• Protects the one-instrument-per-lane model by making the lane, not a global inspector, decide whether internal audio should sound.

Creative extension ideas:

• A future lane badge can expose concise route truth such as INTERNAL, HW, IN+HW, or EXPORT.
• Hardware-only lanes can become a clean way to drive rack synths without hearing a placeholder internal patch.
• Export-only lanes can hold guide parts, alternate orchestrations, or collaboration-only MIDI without affecting playback.

Design reminder: Naming matters only if the behavior follows the name. If a user chooses Hardware Only, the app must not sneak an internal instrument into the mix.

2026-06-24 - Hardware Profiles And SysEx Snapshot Storage

Task: Add saved project-state models for external hardware MIDI profiles and SysEx snapshots without enabling automatic SysEx transmission.

Existing connections:

• The Lane MIDI Routing card already saves input device, output device, route target, input channel, and playback/export channel. Hardware profiles are the next layer of meaning on top of that lane-owned route identity.
• MidiEventList intentionally filters SysEx out of expression payloads; SysExSnapshot gives those bytes a safer home where they can be named, documented, archived, and confirmed before any future send.
• Bank/program defaults in HardwareMidiProfile connect the hardware workflow to SoundFont and future General MIDI/XG work: patch identity belongs to the instrument/route, not to an invisible global inspector.

Creative extension ideas:

• The future Hardware Profile panel can behave like an "external instrument passport": device name, channel, output port, bank/program, clock preference, and one or more named snapshots.
• A lane could eventually show a small hardware badge that opens the exact profile attached to that lane, keeping the no-top-inspector rule intact.
• SysEx snapshots could be packaged into project archives so collaborators with the same external device can restore the exact setup, while collaborators without the device simply see readable notes.
• A future "Send Snapshot" flow should show byte count, target device, expected delay/throttle policy, and a visible log before transmitting.

Design reminder: SysEx is a librarian action, not a musical gesture. Keep it named, visible, confirmed, and out of playback until the user explicitly asks for hardware recall.

2026-06-24 - Timeline-Safe MIDI Expression Gate

Task: Centralize the definition of MIDI events that are safe to store, record, play, and export as timeline expression data.

Existing connections:

• Pattern-level MIDI expression payloads already carry CC, pitch bend, aftertouch, sustain, expression, pan, volume, bank select, and program change.
• Hardware profiles and SysEx snapshots already provide a separate home for device setup data that should not fire during ordinary playback.
• The future Automation/Motion Clip architecture will need this same boundary so drawn controller curves and recorded controller data obey one policy.

Creative extension ideas:

• The eventual expression editor can group events by type using the same predicate: performance gestures, hardware patch gestures, and excluded librarian data.
• A future import assistant can detect incoming Bank/Program events and ask whether they should remain as timeline MIDI, become hardware-profile defaults, or be ignored.
• Hardware profile recall can eventually reuse the same Bank/Program MIDI messages, but from an explicit "Recall Hardware" action rather than project load or lane selection.

Design reminder: Program Change and Bank Select are real MIDI performance data, but they are not permission to silently mutate SpaceAge's internal instruments. Keep the wire data honest and the user action explicit.

2026-06-24 - Hardware Recall Plan Builder

Task: Add a safe processor helper that assembles the Bank/Program messages and optional SysEx snapshots for a hardware profile without transmitting them.

Existing connections:

• Hardware profiles already store MIDI channel, bank/program defaults, and linked SysEx snapshot ids.
• SysEx snapshots already store named bytes, send delay, confirmation intent, and device/profile context.
• The Lane MIDI Routing panel can later ask for this plan when the user chooses an explicit hardware recall action.

Creative extension ideas:

• A future "Recall Hardware" dialog can show this plan as a checklist: Bank MSB, Bank LSB, Program Change, then each SysEx snapshot with byte count and delay.
• The same plan can power dry-run validation, project archive manifests, and hardware setup troubleshooting without touching a MIDI output.
• Hardware profiles can eventually expose a "test recall safely" mode that sends only bank/program first, then asks again before SysEx snapshots.

Design reminder: Plan first, send later. If the user can see the hardware recall payload before it leaves SpaceAge, trust goes way up.

2026-06-24 - Hardware Profile Validation

Task: Add a reusable validation helper for hardware MIDI profiles and linked SysEx snapshots.

Existing connections:

• Hardware profiles can now be created, saved, attached to lanes, and expanded into recall plans.
• A future Hardware Profile/SysEx Vault UI will need clear warnings before recall, archive, or troubleshooting actions.
• The same warnings can be used in export/archive manifests when a project references external hardware.

Creative extension ideas:

• The profile editor can show a live "ready / needs attention" badge based on this helper.
• A project preflight screen can list missing MIDI outputs, invalid SysEx bytes, and profiles with no names before a collaborator receives the file.
• The eventual guided hardware setup wizard can use these warnings as plain-language next steps.

Design reminder: Hardware users are patient with complexity when the app tells the truth. Validation should be specific, calm, and actionable.

2026-06-24 - Confirmed Hardware Recall Queue

Task: Add the backend path for explicitly confirmed hardware recall without allowing SysEx or hardware setup messages to leak into normal Arrangement playback.

Existing connections:

• buildHardwareRecallPlan() remains the dry-run/display helper for Bank MSB, Bank LSB, Program Change, and optional SysEx snapshots.
• validateHardwareMidiProfile() is now the preflight gate before any confirmed recall can queue.
• The live lane hardware output FIFO still rejects SysEx, preserving the safety boundary for generated notes and timeline expression.

Creative extension ideas:

• A future Hardware Profile dialog can show the recall plan, require confirmation, then call the confirmed queue path while rendering a progress meter and send log.
• The separate recall queue can later support cancel/pause/retry without touching the audio-thread lane queue.
• The same explicit queue can become the foundation for "send setup to external synth" and "restore hardware before render" workflows.

Design reminder: Confirmation is not decorative. Hardware recall changes external devices, so the code should make accidental sends hard even if future UI code gets enthusiastic.

2026-06-24 - Hardware Recall Log

Task: Add a bounded backend log for explicit hardware recall queue attempts.

Existing connections:

• The confirmed recall queue already knows the profile id, output device, recall labels, SysEx status, byte count, and delay.
• The future Hardware Profile / SysEx Vault UI needs to show the user what happened without re-parsing MIDI bytes.
• The log stays separate from Arrangement playback and expression payloads, reinforcing that hardware recall is an explicit librarian action.

Creative extension ideas:

• A future recall dialog can show Queued, Failed to Queue, SysEx, byte count, and delay in one readable list.
• Project preflight could surface recent hardware recall failures when a project depends on an external device.
• A troubleshooting export could include the recall log without including the raw SysEx data itself.

Design reminder: Hardware features earn trust when the app leaves a trail. A calm log beats a mysterious silent send.

2026-06-24 - MIDI System Message Classification

Task: Teach the shared MIDI model to recognize transport and sync messages such as MIDI Clock, Start, Continue, Stop, Song Position Pointer, MTC, and MMC without treating them as timeline expression data.

Existing connections:

• MidiEvent already carries raw MIDI hex, so system messages can round-trip safely when they appear in imported data.
• isTimelineExpressionMessage() remains the boundary for clip-owned performance gestures and deliberately excludes transport/sync messages.
• The hardware profile work needs these names so future sync and hardware setup UI can speak plain MIDI language.

Creative extension ideas:

• The MIDI Sync workflow can show clock/MTC/MMC capability as a separate transport/hardware layer, not as a piano-roll automation lane.
• Imported MIDI files with song position or timecode can eventually produce a preflight note: "This file contains transport metadata."
• Hardware profiles for drum machines and grooveboxes can advertise whether they respond to MIDI Clock, MMC, or Song Position Pointer.

Design reminder: Clock is not a note. Transport data deserves its own workflow so it does not surprise composers inside musical clips.

2026-06-24 - Hardware Sync Capability Flags

Task: Persist explicit hardware-profile capability flags for MIDI Clock, Song Position Pointer, MTC, MMC, transport send intent, and incoming transport chase intent.

Existing connections:

• HardwareMidiProfile already remembers identity, device ids, MIDI channel, program recall, clock preference, and linked SysEx snapshots.
• The shared MIDI model can now classify transport/sync messages without treating them as clip expression data.
• validateHardwareMidiProfile() is the single preflight helper for hardware readiness, so sync warnings belong there rather than scattered through future UI code.

Creative extension ideas:

• A future hardware setup wizard can ask "Does this device follow MIDI Clock?" and store the answer once, then use it everywhere.
• The Sync page can show friendly capability badges: Clock, Song Position, MTC, MMC, Chase.
• A future project preflight can warn "This song expects external transport chase, but the selected profile has no MIDI input."

Design reminder: Capability is not permission. A device being able to understand MIDI Clock or MMC does not mean SpaceAge should transmit those messages on load, selection, or playback without a clear user-facing sync policy.

2026-06-24 - MIDI Transport Plan Preview

Task: Add a shared dry-run transport plan builder for hardware profiles.

Existing connections:

• Hardware recall already has a "plan first, send later" model.
• Hardware sync capability flags now describe Clock/SPP/MTC/MMC readiness without sending anything.
• The shared MIDI model already classifies Start, Continue, Stop, MIDI Clock, and Song Position Pointer.

Creative extension ideas:

• A future Sync page can preview "SPP 32 -> Start -> Clock stream begins" before the user enables external sync.
• The Hardware Profile dialog can show warnings such as "starts after bar 1 but this device is not marked as responding to SPP."
• Render/export preflight can later decide whether to restore external hardware, start clocks, or stay internal-only based on the same plan structure.

Design reminder: Transport preview is a trust feature. The user should be able to read what SpaceAge intends to do before it ever asks hardware to move.

2026-06-24 - Processor Hardware Transport Plan Hook

Task: Add a processor-level wrapper that builds a MIDI transport plan from a saved hardware profile id.

Existing connections:

• buildTransportPlanForProfile() is the shared MIDI-layer dry-run helper.
• The processor owns saved hardware profiles, the effective tempo, current sample rate, and validation warnings.
• Future UI should not duplicate profile lookup, timing setup, or warning merging in editor paint/event code.

Creative extension ideas:

• The MIDI Sync workflow can call one processor method and render both the planned transport messages and the profile-readiness warnings.
• A hardware setup wizard can ask the user to test start/stop behavior while showing the same dry-run plan.
• A project preflight screen can show "external transport ready / not ready" without opening the full hardware editor.

Design reminder: Editor UI should read intent from processor helpers instead of becoming the real authority. This keeps MIDI routing and transport rules testable.

2026-06-24 - MIDI Inspection Preflight

Task: Add a shared inspection report for imported or stored MIDI data before SpaceAge converts it into clips, expression lanes, hardware setup, or sync behavior.

Existing connections:

• The shared MIDI layer already classifies channel voice, expression, SysEx, and transport/sync messages.
• Hardware profiles and recall plans need to know when imported MIDI contains bank/program or SysEx data that might belong in a profile rather than a clip.
• The Arrangement and Piano Roll import flows need a safe way to explain what is in a file before the user commits to a conversion.
• The processor now exposes file and pattern-payload inspection wrappers, so future UI can use the same policy without owning MIDI parsing.

Creative extension ideas:

• A future MIDI Import Wizard can show a friendly card: notes, channels used, tempo changes, program changes, SysEx device data, and transport metadata.
• Imported General MIDI files could offer "make lanes from channels," "create hardware profiles from program changes," or "ignore device setup data" as explicit choices.
• A collaborator preflight screen can warn that a project contains hardware-specific SysEx or program data before archiving or sharing.
• Per-channel summaries can become the bridge from raw MIDI files to SpaceAge lanes: "Channel 10 looks like drums," "Channel 1 contains melody plus program changes," or "Channel 2 has pitch bend/pressure and may be a guitar or wind-controller part."

Design reminder: Inspection is a trust layer. SpaceAge should tell the user what a MIDI file contains before it mutates the song, changes hardware assumptions, or hides useful data.

Task: Add a MIDI Import Plan that turns inspection facts into user-facing import choices.

Connections / leverage:

• The import plan can become the backbone of a calm MIDI Import Wizard: the user sees choices such as "Create lanes from channels," "Use channel 10 as drums," or "Store SysEx safely" rather than a dense diagnostic dump.
• This connects directly to the Instrument Bay/lane architecture: multi-channel MIDI can become lane candidates without recreating the old Pad-as-instrument middleman.
• Channel 10 drum detection, expression preservation, and device setup quarantine support General MIDI files, hardware modules, MIDI guitars, wind controllers, and education workflows in one shared path.
• The same plan can be used on existing clip payloads later, enabling "repair this import," "extract hardware setup," or "split this imported clip into lanes" without writing a second parser.

Design reminder: Import planning is where SpaceAge can feel unusually respectful. It should say what it plans to do, why, and what needs confirmation before any irreversible-feeling change happens.

Task: Add channel-role hints to MIDI import planning.

Connections / leverage:

• Channel hints can become the friendly row labels in the MIDI Import Wizard: "likely drums," "melodic notes," "expressive notes," "controller-only," or "device setup."
• This supports MIDI guitar and wind controller users because pitch bend/pressure channels can be treated carefully instead of flattened into generic piano-roll notes.
• General MIDI import gets a smarter default because channel 10 can land in the Drum Composer path without making that behavior mandatory.
• Hardware users benefit because bank/program-only channels can become profile/setup candidates instead of invisible data or confusing empty clips.

Design reminder: Hints should be transparent and overridable. SpaceAge can make a strong guess, but the user owns the final musical intent.

2026-06-24 - MIDI Control Mapping Foundation

Task: Add a project-persistent model for MIDI Learn and controller assignments.

Existing connections:

• The shared MIDI model already classifies CC, pitch bend, channel pressure, and poly aftertouch.
• Pattern expression payloads already preserve performance data, while hardware profiles and SysEx snapshots preserve setup intent.
• The Instrument Bay/lane architecture needs a single way to connect physical controls to synths, effects, lane parameters, future VST parameters, and hardware targets.

Creative extension ideas:

• A future MIDI Learn overlay can let a user click any knob, move a hardware control, and immediately see "Ch 03 CC 74 -> Redshift Cutoff."
• A controller assignment browser can show all learned mappings in one place, with enable toggles, source descriptions, target names, and min/max ranges.
• MIDI guitar and wind controller users can map pressure or pitch bend intentionally instead of SpaceAge treating those messages as mysterious side effects.
• Automation clips and Motion Clips can eventually reuse the same target ids, so a target can be driven by hardware, drawn automation, clip decoration, or generated motion without separate plumbing.
• VST support can land on the same surface: once plugin parameters have stable target ids, MIDI Learn does not need a special VST-only version.

Design reminder: Learn once, route everywhere. The user should never need to know whether the target is native, VST, lane-level, mixer-level, or hardware-level unless that distinction matters musically.

2026-06-24 - MIDI Learn Target Registry And Runtime Application

Task: Add automatic target discovery, learn arming/capture, and parameter application for MIDI controller mappings.

Existing connections:

• The APVTS parameter tree is already the central authority for most synth, lab, mixer, and effects controls.
• MidiControlMapping already stores source identity, target id, target label, and value range.
• The future Instrument Bay and VST wrapper will both need stable parameter target ids, so the naming scheme must not be native-synth-only.

Creative extension ideas:

• The same param:<id> target can later be driven by a hardware knob, a Motion Clip, an automation lane, a Flux Node, or a VST automation bridge.
• The MIDI Learn UI can stay simple: click any control, move hardware, then show a compact card like "Ch 04 CC 07 -> Master Volume."
• The controller assignment browser can become a power-user dashboard for live rigs, MIDI guitar, wind controllers, and hardware synth surfaces.
• Once VST parameters enter the app, their wrapper can expose param:vst:<instanceId>:<parameterId> or a sibling namespace while preserving the same mapping editor.

Design reminder: Automatic discovery is a discipline move. If a new synth or effect parameter is added correctly, it should become learnable without another bespoke MIDI task.

2026-06-24 - MIDI Mapping Diagnostics

Task: Add whole-table diagnostics for MIDI control assignments.

Existing connections:

• The MIDI Learn backend now discovers targets, captures control sources, and applies mappings.
• Hardware profile validation already uses centralized plain-language warnings.
• Future Settings and MIDI Assignments panels need a single trusted warning source.

Creative extension ideas:

• A MIDI controller setup wizard can show "you already mapped this knob to Master Volume" before overwriting or doubling the assignment.
• Motion Clips and automation lanes can later reuse the same diagnostics to catch conflicting target ownership.
• Hardware performer presets could be scored for readiness: missing output, duplicate controls, dangerous SysEx, or unassigned expression sources.

Design reminder: Diagnostics are part of UX, not just testing. When the app can explain suspicious setup choices clearly, users feel guided instead of blamed.

2026-06-24 - MIDI Assignment Summary Rows

Task: Add UI-ready summaries for learned MIDI/control assignments.

Existing connections:

• MIDI Learn already has raw mappings, target descriptors, and diagnostics.
• Hardware/profile validation already demonstrates the value of centralized, plain-language explanations.
• The Settings panel is becoming a true control center, so future MIDI pages need a stable backend readout rather than editor-local formatting.

Creative extension ideas:

• A MIDI Assignments page can group rows by Master, Redshift, EchoRay, Lane, or future VST, letting users audit a live rig at a glance.
• A controller setup wizard can show summaries before committing: "Ch 04 CC 07 -> Master Volume" with warnings if the target no longer exists.
• Preset packs for hardware controllers could ship as mapping bundles, then use the same summary row to explain what each fader/knob does.
• Motion Clips and automation targets can reuse the same target labels later, making hardware control and timeline modulation feel like two views of the same musical control system.

Design reminder: Raw mappings are for the machine. Summary rows are for the musician. Keeping that split clean will make the future UI faster to build and less brittle.

2026-06-24 - MIDI Project Readiness Report

Task: Add a project-level readiness report for MIDI routing, learned controls, hardware profiles, and SysEx state.

Existing connections:

• Lane routing already knows input arm, input channel, playback/export channel, route target, output device, and attached hardware profile.
• Hardware profiles and SysEx snapshots already have validation and recall planning.
• MIDI assignment summaries already turn learned controls into readable rows.

Creative extension ideas:

• Settings can grow a "MIDI Health" page that answers "what is armed, what talks to hardware, and what is risky?" in one glance.
• Project load can eventually show a gentle warning if a hardware-routed lane is missing its output device, instead of letting silence or misrouting feel mysterious.
• A hardware setup assistant can use the same report as its checklist: assign input, assign output, choose channel, attach profile, confirm SysEx snapshots.
• Export and collaboration workflows can include the report so another user knows which lanes need external gear or controller mappings.

Design reminder: Readiness reporting is how complex MIDI becomes humane. The app should tell the user what is true before asking them to debug invisible routing.

2026-06-24 - Direct Hardware Panic Safety

Task: Ensure Panic/reset traffic reaches direct hardware outputs, not only plugin MIDI output.

Existing connections:

• The hardware output router already knows which lanes are routed to hardware and which device slots they use.
• Panic already clears internal voices, resets controller state, and queues conservative MIDI reset messages.
• Hardware profiles and readiness reporting now make hardware routing visible, so panic behavior must match that visible promise.

Creative extension ideas:

• The future MIDI Health panel can show "Panic reaches 2 routed hardware devices" as a confidence-building status line.
• Hardware setup tests can include a "Send safe reset now" button that reuses the same conservative reset packet.
• Live-performance mode could display the Panic button as a true emergency stop because it covers internal instruments, plugin MIDI, and direct hardware devices.

Design reminder: Panic is not decorative. For hardware users, it is a trust contract: SpaceAge must be able to stop stuck notes wherever it caused or routed them.

2026-06-24 - MIDI Import Expression Preservation

Task: Make MIDI file import preserve safe timeline expression payloads instead of importing only notes.

Existing connections:

• MIDI recording already stores expression in pattern-owned midiExpressionEvents.
• MIDI export and Arrangement playback already know how to read those expression payloads.
• The shared MIDI layer already defines isTimelineExpressionMessage() as the safe boundary for CC, pitch bend, pressure, program/bank, pan, volume, sustain, and expression.

Creative extension ideas:

• The future MIDI Import Wizard can show the same preserved payload as editable lanes immediately after import: notes above, expression below.
• Program/bank events can later be offered as "convert to hardware profile recall" or "convert to SoundFont preset choice" without losing their original timing.
• A melody imported from another DAW can keep breath controller, mod wheel, sustain, and bend gestures, which matters a lot for MIDI wind, MIDI guitar, and performance-first users.
• The same import payload can become a source for Motion Clips later, letting users extract a performed expression curve and reuse it elsewhere.

Design reminder: Import should not flatten a performance into bare notes. Preserve musical expression, quarantine dangerous device data, and make the next UI layer explain the difference.

2026-06-24 - MIDI Import Preflight Dialog

Task: Route drag/drop and menu MIDI imports through a shared preflight warning before mutating the selected pattern.

Existing connections:

• planMidiFileImport() already turns raw MIDI inspection into musical choices and warnings.
• The importer now preserves safe expression while keeping SysEx and transport/sync out of clip playback.
• The UI already has JUCE-styled warning dialogs for destructive sequencer actions, so MIDI import should use the same design vocabulary.

Creative extension ideas:

• This preflight can grow into the full MIDI Import Wizard without changing the importer again: first page summary, second page channel-to-lane mapping, third page expression/program/SysEx policy.
• The same message builder can later power drag/drop previews, Library import, archive repair, and collaboration import checks.
• MIDI Health could reuse the warning language so "this file contains device setup data" means the same thing everywhere.

Design reminder: A preflight is not bureaucracy. It is the app telling the musician what is about to happen before precious work changes.

2026-06-24 - Hardware Profile And SysEx Summary Rows

Task: Add UI-ready summary rows for saved hardware MIDI profiles and SysEx snapshots.

Existing connections:

• Hardware profiles and SysEx snapshots already persist and validate as project data.
• MIDI readiness reporting already rolls profile warnings up at the project level.
• Future SysEx Vault and Hardware Profile pages need readable rows, not raw byte buffers and hidden ids.

Creative extension ideas:

• A SysEx Vault page can show "Yamaha QY-100 | 7 bytes | confirmation required" without knowing how snapshots are serialized.
• Hardware setup assistants can use the same profile summaries to list output device, channel, program recall, transport behavior, and linked snapshot count.
• Project archive/export can include these summaries as a collaborator-facing hardware manifest.
• The same summary rows can power a "Before You Play Hardware" safety checklist that shows exactly what SpaceAge may send.

Design reminder: SysEx is powerful but spooky. Summary rows turn hidden machine state into a readable trust surface.

2026-06-24 - MIDI Import Summary Surface

Task: Move MIDI import preflight wording into a backend summary object that the editor can render.

Existing connections:

• The MIDI inspection report already knows notes, expression, channels, device setup, SysEx, and transport/sync facts.
• The import plan already knows which choices are recommended and which require confirmation.
• The preflight dialog already needs this information, but editor-side string building is too easy to drift away from the MIDI policy.

Creative extension ideas:

• A future MIDI Import Wizard can show the same summary as cards: file facts, recommended action, channel roles, and safety notes.
• The Arrangement "drop MIDI here" flow and the Library import flow can share the same wording, preventing contradictory warnings.
• Project recovery could use the same summary for imported files stored as clip payloads, giving users an audit trail for where MIDI came from.
• Hardware users can trust the app because "SysEx quarantined" is a first-class summary line, not an obscure hidden rule.

Design reminder: Import is a moment of trust. The app should explain what it sees, what it recommends, and what it refuses to do automatically.

2026-06-24 - SysEx Quarantine On MIDI Import

Task: Preserve SysEx found in imported MIDI files as inert vault snapshots instead of dropping it or treating it like clip playback data.

Existing connections:

• SysExSnapshot already stores raw device data with confirmation-required recall.
• MIDI import already warns that SysEx needs quarantine.
• Expression payload import already excludes SysEx from clip automation for safety.

Creative extension ideas:

• The future SysEx Vault can show imported snapshots with names like "SongName P4 T1 #1" and let the user attach them to hardware profiles later.
• MIDI Import Wizard can offer "Keep SysEx in Vault" as a visible action that matches what the backend already does safely.
• Project archives can include imported SysEx snapshots so hardware collaborators can restore device state intentionally.
• A hardware setup assistant can detect unassigned imported snapshots and ask, "Is this for your QY-100?"

Design reminder: Preservation and execution are different promises. SysEx belongs in the vault until the user explicitly says where and when to send it.

2026-06-24 - MIDI Expression Lane Summaries

Task: Add a display-ready summary layer for recorded/imported MIDI expression payloads.

Existing connections:

• Pattern-owned MIDI expression payloads already preserve CC, pitch bend, pressure, bank select, and program change data.
• Import/export/playback already share the MidiEventList payload model.
• The future Piano Roll expression editor needs to show which editable lanes exist without parsing raw MIDI events in editor code.

Creative extension ideas:

• Piano Roll can show a compact "Expression" menu: CC11 Expression, Pitch Bend, Channel Pressure, Bank Select, Program Change.
• Imported General MIDI files can reveal patch/setup lanes separately from musical note lanes, making conversion into SoundFont or hardware mappings feel deliberate.
• Hardware/MPE workflows can eventually use the same summary rows to show per-channel or per-note expression density.
• A clip inspector can say "This clip has 5 expression lanes" before the user opens the deeper editor.

Design reminder: Expression data should feel visible and editable, not like hidden MIDI dust inside a clip.

2026-06-24 - Project MIDI Expression Readiness Counts

Task: Add expression event and expression lane counts to the project-level MIDI readiness report.

Existing connections:

• Pattern-owned MIDI expression payloads already preserve CC, pitch bend, pressure, bank select, and program change data.
• summariseMidiExpressionEvents() already turns raw event payloads into UI-ready expression lane rows.
• buildMidiProjectReadinessReport() is already the project-level MIDI dashboard/preflight source for lanes, mappings, hardware profiles, and SysEx snapshots.

Creative extension ideas:

• A future MIDI Health page can say "12 expression lanes found" before the user opens any individual clip.
• Import and archive preflight can distinguish a simple note-only project from a performance-heavy project with hidden controller data.
• The Arrangement clip inspector can use the same counts to badge clips or patterns that carry pitch bend, pressure, or controller motion.
• Hardware setup assistants can warn when imported expression data exists but no lane/controller mapping has been reviewed yet.

Design reminder: Hidden MIDI expression should become visible at the project level before it surprises the musician during export, hardware playback, or collaboration.

2026-06-24 - MIDI Project Health Summary

Task: Add one read-only backend aggregate for the future MIDI Health / MIDI Dashboard surface.

Existing connections:

• Readiness reporting already knows lane routing, armed input state, hardware warnings, SysEx snapshot counts, and expression counts.
• Controller assignment summaries already resolve raw MIDI mappings into readable source/target rows.
• Hardware profile and SysEx snapshot summaries already separate readable safety rows from raw device data.

Creative extension ideas:

• The future MIDI Health page can feel like a preflight cockpit: input lane, controller assignments, hardware safety, SysEx Vault, expression data, and export readiness in one place.
• Archive/export could include a plain-text MIDI Health manifest so collaborators know whether a project depends on hardware setup, SysEx snapshots, or expression lanes.
• The same summary can power a small top-bar warning badge: "MIDI: 2 warnings" without making the UI poll five different systems.
• MIDI guitar and wind-controller setup assistants can eventually slot into this dashboard as profile-specific health cards.

Design reminder: A dashboard should reveal state and route the user to the right editor. It should not perform hidden hardware actions just because it knows about them.

2026-06-24 - Hardware Recall Plan Summary

Task: Add a UI-ready preview layer for hardware recall plans.

Existing connections:

• Hardware profiles can already generate Bank Select MSB, Bank Select LSB, and Program Change messages.
• SysEx snapshots already store raw bytes, confirmation requirements, and safe send delays.
• queueConfirmedHardwareRecall() already enforces explicit confirmation and logs queue attempts.

Creative extension ideas:

• A future Hardware Profile page can show a tidy "Recall This Hardware" preview: bank/program rows, SysEx snapshot rows, byte counts, delay values, and warnings.
• A SysEx Vault can reuse the same summary rows when a snapshot is linked to a profile, keeping librarian language consistent.
• MIDI Health can show a warning badge like "Recall plan needs review" without exposing raw MIDI bytes first.
• Hardware setup assistants can teach users what Bank Select and Program Change mean through readable rows before they ever send a message.

Design reminder: Preview is not permission. A recall plan summary should educate and build confidence, while actual hardware sends remain behind explicit confirmation and a send log.

2026-06-24 - Hardware Transport / Sync Plan Summary

Task: Add a UI-ready summary layer for external hardware transport and sync plans.

Existing connections:

• MidiTransportPlan already predicts Song Position Pointer, Start, Continue, Stop, and MIDI Clock-stream intent.
• Hardware profiles already store clock/transport capabilities and validation warnings.
• MIDI Health is becoming the place where hardware state can be seen before it becomes an action.

Creative extension ideas:

• A future Sync page can show "what SpaceAge will send when playback starts" in plain rows before the user enables it.
• Hardware setup assistants can teach why Song Position Pointer matters when starting from the middle of an Arrangement.
• A top-bar MIDI warning could route to a specific profile row: "QY-100 transport plan needs review."
• External groovebox users can get a guided checklist instead of guessing which clock boxes to tick.

Design reminder: Sync is a trust feature. The UI should make timing intent obvious without ever making clock/transport send feel automatic or mysterious.

2026-06-24 - MIDI Expression Lane Editing Helpers

Task: Add processor-level helpers for adding one MIDI expression event, replacing one expression lane, and removing one expression lane.

Existing connections:

• Recording and MIDI import already preserve safe timeline expression data in pattern-owned payloads.
• Expression lane summaries already tell the UI which CC, pitch bend, pressure, bank, or program lanes exist.
• Playback/export already reads the same expression event list, so edits made through these helpers become audible and exportable without a second data path.

Creative extension ideas:

• Piano Roll can grow an expression editor where users paint CC11 swells, pitch-bend curves, sustain-pedal gestures, or aftertouch shapes without seeing raw MIDI bytes.
• MIDI guitar and wind-controller clips can expose their expressive curves clearly, which makes SpaceAge friendlier to players outside the keyboard/drum-pad world.
• Motion Clips can eventually reuse captured expression lanes as reusable modulation shapes: "take this breath-controller swell and apply it to filter cutoff."
• The MIDI Health page can link directly from an expression-lane count to the exact editable lane.

Design reminder: Expression editing should feel like musical drawing, not protocol surgery. Keep the backend strict so the UI can feel loose and creative.

2026-06-24 - MIDI Import Lane Candidates

Task: Add UI-ready lane candidate rows to MIDI import plans.

Existing connections:

• MIDI inspection already counts notes, expression, program/bank data, SysEx, and channel activity.
• Channel role hints already recognize likely drums, melodic notes, expressive melodic data, controller-only data, and device setup.
• The Arrangement architecture now prefers lane-owned instruments, so MIDI import needs a clean bridge from channel data to lane creation.

Creative extension ideas:

• The Import Wizard can show friendly cards: Ch 10 -> Long-form drum lane, Ch 02 -> Expressive instrument lane, Ch 05 -> Hardware setup review.
• General MIDI files can become a near-one-click starting point for education workflows: drums land in a drum lane, melodic channels land in instrument lanes, and program changes stay visible for review.
• MIDI guitar and wind-controller material can get special expressive lane treatment instead of being flattened into plain keyboard notes.
• Future SoundFont and hardware profile workflows can use the same candidate rows to suggest patches or external modules without guessing in the editor.

Design reminder: Lane candidates should guide, not decide. SpaceAge can make an excellent first guess while still letting the user choose the lane type, instrument, and routing.

2026-06-24 - MIDI Import Apply Preview

Task: Add a dry-run checklist for the final step of MIDI import.

Existing connections:

• MIDI inspection gathers facts.
• MIDI import plans turn facts into choices.
• Lane candidates translate channel roles into possible SpaceAge lanes.
• SysEx Vault and hardware profile work already prove that preview and send/mutate must be separate concepts.

Creative extension ideas:

• A polished Import Wizard can end with a clean checklist: create two lanes, preserve expression, store one SysEx snapshot, ignore transport messages.
• Users importing old General MIDI songs can see the plan before committing, which makes SpaceAge feel careful instead of magical in the bad sense.
• The same preview pattern can later be reused for archive import, hardware recall, project repair, and destructive arrangement operations.
• Education mode could explain why a file's channel 10 became drums and why SysEx is being stored rather than sent.

Design reminder: The final preview should reduce anxiety. It answers "what is about to happen?" without doing the thing yet.

2026-06-24 - MIDI Export Readiness Summaries

Task: Add UI-ready preflight summaries for pattern, selected Arrangement clip, and whole Arrangement MIDI export.

Existing connections:

• Arrangement export already knows lane channels, clip source ranges, repeats, transpose, Chord Engine markers, and expression payloads.
• Import now has a dry-run preview; export deserves the same trust-building step before writing collaborator-facing files.
• Route target and hardware profile work already frames playback/export channels as lane-owned intent.

Creative extension ideas:

• The Render dialog can say "3 lanes, 4 clips, channels 10/6/7, expression included" before the file save happens.
• Drums-only export can clearly explain that non-drum lanes are intentionally omitted.
• Hardware users can see whether an exported MIDI file is using the same channels they expect before sending it to another DAW or device.
• Education workflows can use export summaries as teaching moments: clips are timeline containers, patterns are payloads, and lanes own the playback/export channel.

Design reminder: Export is collaboration. The preview should make the file's contents predictable before the user shares it with another musician, DAW, or hardware rig.

2026-06-24 - MIDI Export Job Plans

Task: Convert MIDI export readiness summaries into UI-ready export job plans.

Existing connections:

• MIDI import already has a dry-run apply preview, so export should mirror that trust-building model.
• MidiExportReadinessSummary already counts lanes, clips, patterns, route targets, notes, chord markers, and expression data.
• Render/export UI needs a compact checklist and safe filenames without duplicating backend counting rules.

Creative extension ideas:

• The Render dialog can show "Full arrangement MIDI" plus one track row per lane, with exact channels and payload types.
• Future stem-style MIDI export can reuse the lane-track rows as separate file candidates.
• Export presets could remember whether the user usually exports a full song, drums only, or collaborator-safe guide tracks.
• A future project archive can include the job-plan summary as a small manifest for collaborators.

Design reminder: Readiness answers "what exists?" The job plan answers "what are we about to present and write?" Keep those separate so the UI stays honest.

2026-06-24 - MIDI Import Commit Requests

Task: Add a serializable request object for the final chosen MIDI import action.

Existing connections:

• MIDI import already has inspection facts, plans, summaries, lane candidates, and dry-run apply previews.
• SysEx quarantine, device setup review, and transport/sync ignore choices already need explicit user intent.
• The future Import Wizard needs a single handoff object between "the user accepted this plan" and "mutate the project."

Creative extension ideas:

• Import history can log commit requests so users can understand what a MIDI import did days later.
• Templates could store preferred import request defaults: split channels, map CH10 drums, preserve expression, ignore transport.
• A collaborator-safe import mode could force storeSysExInVault and reviewDeviceSetup on, even if a file looks simple.
• The same request pattern can later support drag/drop imports, batch imports, and AI-assisted file triage without changing the mutation code.

Design reminder: A wizard should never be a pile of checkboxes wired straight to project mutation. Build the request, show it, then apply it.

2026-06-24 - MIDI Expression Lane Transforms

Task: Add pure backend operations for editing timeline expression lanes: quantize ticks, scale values, offset values, and thin redundant events.

Existing connections:

• MIDI recording/import already preserves CC, pitch bend, pressure, bank/program, and other safe expression events.
• Expression lane summaries already identify editable lanes by message kind, channel, and controller/note number.
• Undo and preview workflows work best when operations can produce a transformed copy before processor state changes.

Creative extension ideas:

• Drawable CC lanes can use the same transform result to preview "what changed" before committing.
• MIDI guitar and wind-controller cleanup can thin dense bend/pressure streams without destroying musical intent.
• Imported MIDI files can offer one-click cleanup: snap CC ramps to musical grid, trim redundant controller spam, or scale expression curves.
• Hardware automation clips and future Motion Clips can share the same value transform model instead of building separate curve-editing logic.

Design reminder: Expression editing should feel musical, not like spreadsheet surgery. Backend transforms should stay precise and reversible so the UI can remain friendly.

2026-06-24 - MIDI Import Apply Results

Task: Add a UI-ready import receipt object that reports what a committed MIDI import did or would report after mutation.

Existing connections:

• Import inspection, planning, summary, preview, and commit requests already separate facts from intent.
• SpaceAge's safety culture around SysEx and hardware recall depends on clear after-action reporting.
• Undo/debug workflows benefit when a project can say "this import created two lanes and stored one SysEx snapshot."

Creative extension ideas:

• The Import Wizard can finish with a friendly receipt: clips imported, lanes created, expression preserved, sync ignored.
• Import history could store these receipts per project so users can audit where material came from.
• Education mode can explain why channel 10 became drums or why SysEx went to the vault instead of hardware.
• Batch import can aggregate several receipts into one collaborator-safe report.

Design reminder: Preview answers "what will happen?" A result answers "what happened?" Keep both, because trust is built before and after the action.

2026-06-24 - MIDI Lane Routing Compact Labels

Task: Extend MIDI readiness lane summaries with complete compact routing labels and device IDs.

Existing connections:

• Arrangement lanes now own instruments, mixer channels, MIDI channels, and route targets.
• MIDI Health already aggregates lane routing, hardware profiles, SysEx, and expression counts.
• The user has repeatedly pushed for workflow clarity over intermediary inspector confusion.

Creative extension ideas:

• The MIDI Dashboard can show one readable lane line: Bass | MIDI Input: Omni -> MIDI Output: Channel 06 | Internal + Hardware.
• Lane badges can reuse the same compact label for tooltips, avoiding inconsistent terminology.
• Hardware troubleshooting can show output device IDs and hardware profile names in one place.
• Import results can create lanes, then immediately hand their compact labels to the receipt screen.

Design reminder: Routing is a sentence, not a pile of protocol nouns. Make it legible at a glance.

2026-06-24 - Hardware Recall Preflight Counts

Task: Enrich hardware recall summaries with queue readiness, message counts, SysEx counts, byte totals, and delay totals.

Existing connections:

• Hardware profiles already own bank/program recall, linked SysEx snapshots, output device ids, and validation warnings.
• The SysEx vault already requires explicit confirmation and stores snapshots separately from musical clip expression.
• The future Hardware Profile UI needs a trusted packet that explains risk before any device data is sent.

Creative extension ideas:

• A hardware recall dialog can show "3 program messages, 1 SysEx, 15 bytes, confirmation required" before the user clicks send.
• The MIDI Health dashboard can flag profiles that are not ready to queue without parsing raw MIDI messages in editor code.
• Recall history can compare the exact preflight summary with the log entry after sending, giving hardware users a clean audit trail.
• Project archive/export can use the same counts to warn collaborators that external hardware setup data is present.

Design reminder: SysEx is powerful enough to be dangerous. Treat every send as an intentional librarian action with visible counts, warnings, confirmation, throttling, and a log.

2026-06-24 - MIDI Protocol Coverage Report

Task: Add a conservative backend report that describes MIDI protocol-family readiness without overstating what is product-ready.

Existing connections:

• MIDI Health already aggregates routing, mappings, hardware profiles, SysEx snapshots, and expression counts.
• The user specifically asked how close we are to "full MIDI protocol"; a vague percentage is less useful than a family-by-family truth table.
• Hardware and SysEx safety work depends on clearly separating "recognized" from "safe to send."

Creative extension ideas:

• Settings can show a friendly MIDI Readiness section: Notes ready, Controllers backend-ready, SysEx guarded, MIDI 2.0 future.
• Marketing can avoid overclaiming by saying SpaceAge has "guided MIDI 1.0 support" while the UI catches up to the backend.
• QA can use the report as a checklist before release: no family should claim UI-ready until there is an actual user-facing workflow.
• A future onboarding flow can use the report to explain why SysEx, clock, and transport require confirmation rather than behaving like normal notes.

Design reminder: Protocol completeness is not a vibe. Tell the truth by family, by backend state, by UI state, and by safety risk.

2026-06-24 - SysEx Vault Readability

Task: Enrich SysEx snapshot summaries with manufacturer/model identity, archive intent, confirmation wording, and a short hex preview.

Existing connections:

• SysEx snapshots already persist full raw bytes, notes, send delay, archive inclusion, and confirmation requirement.
• Hardware profiles already provide manufacturer/model identity when a snapshot is linked to a profile.
• MIDI Health and future SysEx Vault UI need readable summaries rather than raw device dumps.

Creative extension ideas:

• A SysEx Vault browser can show "Yamaha QY-100 | 7 bytes | confirmation required | f0 43..." in one compact row.
• Archive/export can distinguish snapshots included in collaborator packages from local-only hardware librarian data.
• Hardware troubleshooting can use hex previews as confidence fingerprints without encouraging casual editing of raw SysEx.
• Future import receipts can link directly to the vault snapshot row that was created from an imported MIDI file.

Design reminder: SysEx should feel like a vault, not a text editor. Show enough to build trust, hide enough to prevent casual damage.

2026-06-24 - MIDI Learn Mapping Dashboard

Task: Add a whole-map MIDI Learn dashboard summary and enrich each assignment row with source metadata and compact labels.

Existing connections:

• MIDI Learn already discovers APVTS-backed targets, captures CC/pitch/pressure/poly-pressure messages, persists mappings, and applies them at runtime.
• The MIDI Health summary already aggregates lane routing, protocol coverage, hardware profiles, SysEx snapshots, and warning counts.
• The UI philosophy for SpaceAge favors obvious status and guided action over asking the user to mentally audit hidden routing.

Creative extension ideas:

• A future MIDI Assignments page can open with one clean line: 3 MIDI controls | 3 enabled | 1 unresolved | 1 duplicate | needs review.
• The same dashboard can power a pre-show "performance safe?" check for users driving SpaceAge with hardware controllers.
• Assignment rows can show compact labels on hover in synth/effect GUIs, turning hardware mappings into visible affordances instead of hidden setup.
• Hardware setup assistants for MIDI guitar, wind controllers, and pad controllers can use the same source-family counts to explain what a device is actually sending.

Design reminder: A learned mapping is not just "some CC." It is a source, a target, a range, a safety status, and a trust contract with the performer.

2026-06-24 - MIDI Patch Event Summaries

Task: Add a readable summary layer for Bank Select and Program Change events in MIDI expression/setup data.

Existing connections:

• MIDI import already detects bank/program data and quarantines it as device setup intent rather than ordinary notes.
• Hardware profiles already use Bank MSB, Bank LSB, and Program Change as explicit recall messages.
• SoundFont and General MIDI workflows will need to interpret imported patch changes without silently changing lane instruments.

Creative extension ideas:

• An Import Wizard can show Ch 04 | Bank MSB 9 / LSB 22 | Program 65 (MIDI 64) and offer "map this to a SoundFont preset" or "create hardware profile recall."
• A Piano Roll expression lane can show patch-change markers as readable setup cards rather than raw CC0/CC32/program events.
• Hardware users can turn an imported patch setup into a named profile with one deliberate conversion step.
• Education mode can explain why program numbers are displayed as 1-128 while the MIDI wire value is 0-127.

Design reminder: Patch setup is useful information, not permission. Make it visible, then ask before converting it into instrument or hardware state.

Gotcha discovered: Same-tick Bank Select and Program Change can be internally sorted in a way that makes the Program Change appear first. Patch/setup summaries now interpret same-tick Bank Select before Program Change on the same channel, matching the musician's intent and avoiding false "missing bank" warnings.

2026-06-24 - MIDI Import Review Dashboard

Task: Add a consolidated backend review dashboard for MIDI import-like workflows.

Existing connections:

• The dashboard sits above MidiInspectionReport, MidiImportPlan, and MidiImportSummary, so it does not create a rival MIDI-import policy.
• It reuses patch/setup summaries for Bank Select and Program Change readability.
• It creates sections that can later drive file import, drag/drop MIDI, clipboard MIDI, pattern-payload review, hardware profile creation, and SoundFont mapping.

Creative extension ideas:

• The eventual Import Wizard can use large visual cards: Lane Plan, Expression, Patch Setup, SysEx, Song Metadata, and Transport / Sync.
• Hardware-oriented users can see SysEx and patch rows in one place before deciding whether to store, ignore, or map them.
• Education/help mode can explain why SpaceAge treats notes, expression, setup data, and sync data differently.

Design reminder: One MIDI file can contain musical notes, performance expression, hardware setup, and transport commands. Keep these visually separate so users understand intent before committing changes.

2026-06-24 - Processor-Owned MIDI Review Access

Task: Expose MIDI import review dashboards through the audio processor for files and stored pattern payloads.

Existing connections:

• The editor already calls processor helpers for import plans, so dashboard helpers follow the same ownership boundary.
• File dashboards use the shared midiEventListFromMidiFile() helper so patch/setup rows stay tied to the canonical MIDI event model.
• Pattern payload dashboards let future Piano Roll or clip-inspector UI review embedded expression, patch, and setup data without needing a source file.

Creative extension ideas:

• A single Review button could inspect either a file, a dropped MIDI fragment, or a selected clip's hidden MIDI payload.
• The same dashboard can become a teaching tool: "this file has notes, expression, patch setup, SysEx, and sync data."
• Future hardware setup assistants can launch from the Patch Setup or SysEx dashboard sections rather than from a separate intimidating hardware page.

Design reminder: Editor code should ask the processor for review dashboards. It should not reopen MIDI files, decode CC0/CC32, or invent local safety text.

2026-06-24 - External MIDI Output Readiness

Task: Add a backend preflight report for arrangement lanes routed to external MIDI hardware.

Existing connections:

• It builds from buildMidiProjectReadinessReport() instead of walking lanes a second time.
• It reuses saved lane route targets, output device ids, and hardware profile assignments.
• It complements hardware recall previews by answering a different question: "Can playback safely attempt to send external MIDI from these lanes?"

Creative extension ideas:

• A future Hardware Output Preflight panel can show green/amber rows for every hardware lane before playback or export.
• If a lane is missing a hardware profile, SpaceAge can offer "Create profile from this lane" right inside the warning row.
• If several lanes target the same output device, the UI can group them as a hardware rig rather than a random list of lanes.
• When SysEx vault recall is added to the flow, the preflight can become a launch checklist: device, channel, profile, recall, clock, then play.

Design reminder: A route that is configured well enough to attempt playback is not the same thing as a verified open OS device. Keep those two states separate in labels and error handling.

2026-06-24 - External MIDI Runtime State

Task: Report whether hardware output devices requested by external MIDI lanes are actually open, plus dropped-message counts.

Existing connections:

• It sits beside external-output readiness rather than merging configuration state with runtime state.
• It reads the processor-owned hardware output router, which already owns direct juce::MidiOutput lifetimes.
• It gives future UI the data needed to explain "your lane is routed correctly, but Windows did not open that MIDI port."

Creative extension ideas:

• A small hardware status lamp can distinguish configured, open, closed, and dropping messages.
• The same runtime report can power a troubleshooting dialog: "Reconnect device", "Choose replacement output", "Turn this lane internal only".
• Hardware performance templates can require all requested devices open before enabling a "Send Recall + Play" command.

Design reminder: Runtime device state can change underneath the user. Treat it as a status readout and recovery guide, not as saved project truth.

2026-06-24 - MIDI Device Inventory

Task: Add a backend inventory report that compares currently visible OS MIDI inputs/outputs against saved lane and hardware-profile device references.

Existing connections:

• Lane MIDI routing and hardware profiles both store device ids already; the inventory report simply makes missing references visible.
• It complements external-output readiness/runtime reports: inventory says "is this device visible?", readiness says "is the route configured?", runtime says "is the output open?"
• It gives Settings, Hardware Preflight, and future onboarding screens the same source of truth.

Creative extension ideas:

• The MIDI setup wizard can show "Seen today" and "Missing from this project" lists with replacement actions.
• Hardware templates can be portable if SpaceAge can map old device ids to newly discovered device ids.
• A future "hardware tour" could walk the user through input controller, output synth, channel, profile recall, and panic test in one guided flow.

Design reminder: Never hide a missing MIDI device behind silence. If a saved id is not visible, say so plainly and offer a replacement path.

2026-06-24 - MIDI Input Readiness

Task: Add a backend report that explains which lane receives live MIDI input and whether the selected input route can work.

Existing connections:

• It uses the project readiness report for armed lane and channel filter state.
• It uses the device inventory report to decide whether a saved input device is visible.
• It addresses the confusion between selected clip, selected lane, and MIDI-armed lane by making the input destination explicit.

Creative extension ideas:

• A top-bar "MIDI IN -> Lane Name / Channel" badge can be powered by this report.
• If the selected controller is missing, SpaceAge can offer to switch to Omni/all inputs or choose a replacement device.
• Recording, step input, chord detection, and hardware control learning can all display the same input destination language.

Design reminder: Live MIDI focus should be visible, not guessed. Selection is for editing; armed input is for performance.

2026-06-25 - Settings MIDI Preflight Readout

Task: Surface MIDI input, device inventory, external output readiness, and external output runtime reports inside Settings.

Existing connections:

• The Settings popup is already global enough to hold "is the rig ready?" information without creating another top-level inspector.
• The readout uses the processor-owned MIDI reports, so UI labels do not duplicate routing logic.
• It complements lane-level MIDI routing: lanes remain where assignments are made, while Settings becomes a quick status/preflight check.

Creative extension ideas:

• A future "Fix MIDI" button could jump from each warning line to the exact lane or device replacement flow.
• The same summaries can power a compact top-bar badge once the language is proven in Settings.
• Hardware-oriented users could eventually run a one-click "launch checklist" before a performance: input armed, output open, profile present, SysEx recall ready, clock configured.

Design reminder: Keep status and assignment separate. A preflight readout should explain what is true; lane badges and routing panels should change what is true.

2026-06-25 - Arranger Lane MIDI Warning Badges

Task: Let Arrangement lane badges show when a lane has external MIDI routing warnings.

Existing connections:

• The badge already teaches lane instrument, mixer, MIDI channel, add-clip target, and live-input target.
• The new warning state comes from the same external MIDI readiness report used by Settings, keeping the diagnosis consistent.
• It preserves the lane-first workflow: a hardware problem appears exactly where the lane lives, not in a disconnected inspector.

Creative extension ideas:

• Clicking an amber lane badge could open the lane MIDI routing panel directly to the missing device/profile field.
• Future device-replacement flows can highlight every affected lane at once.
• The visual language can eventually distinguish "configured for hardware", "hardware open", "hardware missing", and "messages dropped" using small status lamps instead of long text.

Design reminder: Warnings should live near the thing that needs action. Settings can summarize; lanes should point to the fix.

2026-06-25 - MIDI Health Dashboard

Task: Add a read-only MIDI Health callout launched from Settings.

Existing connections:

• It uses buildMidiProjectHealthSummary() instead of building another pile of local UI checks.
• It sits beside the MIDI Preflight readout, turning the compact Settings status into a deeper troubleshooting surface.
• It keeps routing changes in lane panels and future dedicated MIDI tools, preserving the "status here, action at the source" rule.

Creative extension ideas:

• The warning rows can eventually become clickable jump links to the exact lane, hardware profile, SysEx snapshot, or MIDI Learn assignment.
• A future startup/load preflight could show this panel automatically only when a saved project has missing MIDI hardware.
• Export and performance modes could reuse the same health summary as a "ready to render / ready to play live" checklist.

Design reminder: The first MIDI dashboard should make invisible protocol state legible. It should not become a junk drawer of editable controls.

2026-06-25 - SysEx Vault Viewer

Task: Add a read-only Settings callout that shows stored SysEx snapshots.

Existing connections:

• MIDI import already quarantines SysEx into project-owned snapshots; the viewer simply makes that safe storage visible.
• Hardware profile summaries already know linked profile/device identity, confirmation state, byte count, and warnings.
• It complements the future Hardware Recall workflow by showing what exists without offering a premature Send button.

Creative extension ideas:

• The next step can add "Attach to profile", "Rename", "Archive include/exclude", and "Reveal raw hex" actions inside the same viewer.
• Once recall confirmation UI is ready, a selected hardware profile can show its linked SysEx snapshots before any message leaves SpaceAge.
• For schools and hardware beginners, the Vault can explain what SysEx is in plain English: "a device setup snapshot, not a note."

Design reminder: SysEx is powerful and risky. First make it visible and named; only later make it sendable, and only with explicit confirmation.

2026-06-25 - Lane Instrument Menu Crash Guard

Task: Harden the Arrangement lane "Choose Lane Instrument" and lane synth-edit icon path after a crash report.

Existing connections:

• The lane badge, L/S/V panel, and direct synth icon all point at the same conceptual action: lane-owned instrument editing.
• The fix consolidates the editor-opening path into one guarded helper so invalid/stale lane state is handled consistently.
• Async popup menus can outlive UI refreshes, so lane validity must be checked when the user chooses a menu item, not only when the menu opens.

Creative extension ideas:

• The same helper can become the entry point for the future Instrument Bay, keeping lane-owned instruments decoupled from the old pad mental model.
• If a lane has a missing/corrupt instrument reference, the helper could offer "Repair Lane Instrument" instead of silently failing.
• Crash guards like this can power a broader project-load integrity pass that fixes old sessions before the user touches anything.

Design reminder: Lane instruments are the source of truth. Every shortcut into them should route through one safe, readable doorway.

2026-06-25 - Lane Command Panel Callback Safety

Task: Fix the remaining "Choose Lane Instrument" crash by making lane command-panel button actions defer safely until after JUCE finishes processing the click.

Existing connections:

• The L/S/V lane command panel is a reusable surface for lane structure, signal, and view actions.
• Some actions, including "Choose Lane Instrument", close or replace the panel as part of their callback.
• Deleting a component from inside one of its own child-button callbacks is fragile in JUCE; the action now posts through the message queue with a copied callback.

Creative extension ideas:

• Future lane popup panels should use the same deferred-action pattern whenever an action can close or replace the invoking panel.
• A small postUiAction() helper could become a house style for safe panel transitions.
• This also supports richer lane controls later because panels can swap into new panels without self-destruction risk.

Design reminder: Any UI action that changes the surface it came from should let the current mouse event finish first.

2026-06-25 - MIDI Learn Before Lane Filtering

Task: Continue MIDI protocol work by making live MIDI Learn capture and learned control mappings happen before armed-lane musical channel filtering.

Existing connections:

• Lane input filtering is correct for musical note capture, because a lane should decide which channel feeds its instrument or drum mapping.
• MIDI Learn and learned APVTS mappings are broader than a single lane: a hardware knob might target master volume, effect return, synth cutoff, or another global parameter even while the composer has a lane armed for note input.
• This keeps the lane-first workflow intact while making controller behavior feel predictable: notes obey the lane, control mappings obey the mapping.

Creative extension ideas:

• A future MIDI Learn UI can show "captured after live input filtering" as a quiet troubleshooting clue, and a later true global-learn mode can be designed explicitly if users need it.
• MIDI guitar and wind-controller profiles can separate expressive performance data from app-level control data without making users memorize hidden routing rules.
• The same ordering principle can guide MIDI 2.0/MPE later: capture/learn app controls first, then route musical performance streams by lane policy.

Design reminder: Musical input belongs to the selected lane. Learned controls belong to the app-wide control surface unless the user deliberately scopes them.

2026-06-25 - Guarded Hardware Transport Runtime

Task: Continue MIDI protocol work by turning hardware transport plans into conservative runtime playback-boundary messages and a guarded outgoing MIDI Clock scheduler.

Existing connections:

• Hardware profiles already store output device, clock/transport policy, SPP support, and safety warnings.
• Transport plan summaries already explain what Start, Continue, Stop, Song Position Pointer, and MIDI Clock intent would do.
• The hardware output router already queues non-SysEx MIDI to device-specific outputs on a background thread, including millisecond-delayed messages for near-future sends.

Creative extension ideas:

• The MIDI Sync workflow can expose the same policy in plain English: "send Start/Stop", "send song position", "send clock", and "chase incoming clock."
• A transport activity badge could briefly confirm when external Start/Stop was sent, avoiding mystery if a synth or drum machine starts moving.
• Clock quality could later graduate from the current millisecond-delayed hardware queue to a more explicit sync diagnostics panel that shows BPM, jitter assumptions, target devices, and chase state.

Design reminder: Hardware transport is powerful and can move other machines. Emit only when the profile is explicitly configured; keep clock behavior visible and diagnosable before promising live-rig perfection.

2026-06-25 - Incoming Sync Message Safety

Task: Keep incoming MIDI Clock, transport, song-position, MTC, MMC, and Active Sense messages out of the lane-note path until a deliberate chase workflow exists.

Existing connections:

• MIDI import already treats transport/sync as non-musical clip data.
• MIDI Learn already ignores transport/sync messages, so these global messages do not need to pass through the learned-control path.
• Lane input filtering is for musical channel streams; global realtime messages are channel-less protocol events and should not be blocked or misread by the active lane.

Creative extension ideas:

• The MIDI Sync workflow can add "Chase external transport" as a clear opt-in mode rather than letting a stray device unexpectedly start playback.
• The MIDI Health panel can eventually show recent incoming sync activity: clock present, start/stop seen, SPP seen, MTC/MMC seen.
• Hardware setup assistants can use this same detection path to confirm that a drum machine or controller is actually transmitting clock.

Design reminder: Detect first, explain second, chase only after explicit user intent. External sync should never feel haunted.

2026-06-25 - MIDI Patch Setup Ordering

Task: Continue MIDI protocol work by hardening Program Change and Bank Select behavior.

Existing connections:

• MIDI import, recording, playback, and export already preserve Bank Select and Program Change as timeline expression payloads.
• Hardware profiles already use explicit Bank MSB, Bank LSB, then Program Change ordering for confirmed recall.
• The same ordering rule now applies to stored expression events, including restored project data, so old and new clips agree with hardware convention.

Creative extension ideas:

• A future MIDI import wizard can turn detected Bank/Program rows into "set this lane's hardware preset" or "map this to a SoundFont preset" choices instead of silently changing instruments.
• The MIDI Health panel can flag patch setup data separately from musical expression so users understand why an imported file may change an external synth patch.
• SoundFont preset matching should eventually use actual SF2 bank/program metadata when available, rather than relying only on preset index display.

Design reminder: Patch setup data is powerful, but it is not ordinary performance expression. Preserve it, explain it, and only apply it to instruments after the user says that is what they want.

2026-06-25 - Incoming Sync Runtime Telemetry

Task: Carry on with MIDI protocol work by giving incoming Clock, transport, song-position, MTC, MMC, and Active Sense messages a backend health readout before implementing chase behavior.

Existing connections:

• Incoming global sync/status messages are already guarded out of the musical note, recording, and controller paths.
• MIDI Health already aggregates readiness, controller mapping, hardware profile, and SysEx state; sync activity belongs in that same diagnostic story.
• Hardware setup and MIDI Sync surfaces will need proof that a device is actually sending Clock, Start/Stop, SPP, MTC, or MMC before asking the user to trust external sync.

Creative extension ideas:

• The Sync panel can eventually show a calm live indicator: "Clock seen", "Start seen", "SPP beat 64 seen", or "No external sync detected yet."
• Hardware setup wizards can use the same counters as a handshake: "I can hear your drum machine's clock."
• If a user expects SpaceAge to chase hardware but nothing moves, the app can explain whether the missing piece is input routing, device output, profile policy, or unsupported chase mode.

Design reminder: Sync should become observable before it becomes powerful. The user should never wonder whether the app ignored a device, missed a cable, or simply has chase turned off.

2026-06-25 - SysEx Send-Delay Safety

Task: Continue MIDI protocol hardening by giving SysEx snapshots and recall plans a conservative hardware-safe send delay based on message size.

Existing connections:

• SysEx snapshots are already quarantined, confirmation-required by default, summarized, and sent only through explicit hardware recall.
• Hardware recall already uses a separate queue from live Arrangement playback, so dangerous device data does not leak into ordinary composition.
• The recall log already records message size, delay, destination, and queue success, making send timing part of the audit trail.

Creative extension ideas:

• The future SysEx Vault can show "small identity request" versus "large patch dump" with a plain-language delay recommendation.
• Hardware profiles can eventually store per-device delay multipliers for older synths that need extra breathing room.
• A progress meter for SysEx recall can use the same byte count and delay metadata to reassure the user that SpaceAge is working, not frozen.

Design reminder: SysEx is not normal musical data. Treat it like a deliberate hardware maintenance action: preview it, confirm it, throttle it, and log it.

2026-06-25 - Effects Page Starfield

Task: Add the existing Library starfield atmosphere behind the Effects page so the visual language carries into the shared rack without creating a new animation system.

Existing connections:

• The Library page already uses a lightweight JUCE-drawn StarfieldBackdrop.
• The Effects page has large dark empty regions where subtle motion can reinforce the SpaceAge identity without competing with controls.
• Reusing the same backdrop class keeps the visual feature centralized and avoids a one-off animation path.

Creative extension ideas:

• If the starfield ever becomes distracting, a future reduce-motion setting can disable both Library and Effects atmospheres together.
• The same reusable atmospheric component could later sit behind less dense modal pages or idle/listening states.
• Effects-page motion can make long listening/editing sessions feel more alive, especially when arrangements are looping while the user tweaks sends.

Design reminder: The starfield should be atmosphere, not content. Controls must remain the obvious foreground.

2026-06-25 - MIDI Protocol Coverage Panel

Task: Add a read-only MIDI Protocol panel in Settings so the project can report which MIDI protocol families are implemented, guarded, partial, or future-facing.

Existing connections:

• SpaceAgeMidi already owns the protocol coverage model, so the UI can display a single source of truth instead of duplicating status text.
• MIDI Health already summarizes readiness, warnings, mappings, hardware profiles, and SysEx snapshots; the protocol panel becomes the more detailed sibling for implementation coverage.
• SysEx Vault, Hardware Profiles, MIDI Learn, import/export, and expression lanes can each update the same report as they mature.

Creative extension ideas:

• This panel can later become a QA checklist before release: green for fully usable, blue for backend-ready, amber for dangerous/confirmation-gated, gray for future.
• The same pattern can be used for other deep systems, such as Instrument Bay readiness, Render readiness, or Export format coverage.
• A customer-facing "MIDI Confidence" page in the manual could mirror this report in plain language, making hardware users feel that SpaceAge was built for them.

Design reminder: MIDI is too broad to feel magical if it is invisible. Make the system honest, inspectable, and calm.

2026-06-25 - MIDI Learn Channel Filter Discipline

Task: Make MIDI Learn and MIDI control mappings respect the armed lane input-channel filter before capture or parameter application.

Existing connections:

• Arrangement lanes already expose MIDI input routing, channel filters, and armed input behavior.
• Learned MIDI mappings already store their source channel, but the live capture path previously happened before the lane filter.
• The MIDI Health and future MIDI Learn panels should be able to describe one simple rule: the armed lane decides what incoming channel data is accepted.

Creative extension ideas:

• Future hardware setup wizards can ask the user to play or move a control on a specific channel and reliably ignore unrelated controller noise.
• A MIDI Learn panel can display "Listening on MIDI Channel 6" when the current lane is filtered, making the process feel guided instead of mysterious.
• If we later add global mappings, they should be explicitly labeled global/omni rather than being accidental bypasses of lane routing.

Design reminder: Hardware users need trust. Input routing must mean the same thing for notes, controllers, pressure, pitch bend, and learn capture.

2026-06-25 - Live MIDI Sample-Position Scheduling

Task: Reduce live MIDI input lag by making note-on monitoring respect each incoming MIDI event's sample position inside the current audio block.

Existing connections:

• MIDI events already arrive with metadata.samplePosition, and recording already uses that position for stored note timing.
• Voices already support delayed starts for sequencer events, chord clips, and ratchets.
• Applying the same delayed-start mechanism to live MIDI keeps the playback engine unified instead of inventing a special live path.

Creative extension ideas:

• A future MIDI latency diagnostic can compare audio block size, driver latency, and sample-position scheduling so users know whether the bottleneck is SpaceAge or their audio device.
• Live MIDI recording can eventually show "monitoring sample-accurate / recording compensated X ms" as plain-language trust feedback.
• The same scheduling path could later support sample-accurate automation and expression events, not just notes.

Design reminder: Live performance has to feel immediate. If the buffer is the unavoidable limit, SpaceAge should at least avoid adding an extra block of its own.

2026-06-25 - DIN-5 MIDI Port Icon Refinement

Task: Revise the MIDI port illustration so it matches Shane's final five-pin DIN reference: dark square field, thin white outer port line, five solid white pins in the hardware arc, and the bottom key notch.

Existing connections:

• The MIDI work is becoming a major SpaceAge identity point, so the icon needs to feel like actual hardware rather than a generic circle with dots.
• The same vector language can later be reused in MIDI Settings, hardware profiles, SysEx recall dialogs, and lane MIDI badges.
• Hardware-faithful iconography helps support the "hand-holding for MIDI hardware" promise without adding explanatory text everywhere.

Creative extension ideas:

• A future animated MIDI activity indicator could briefly light the five pins when MIDI data arrives, giving users immediate visual feedback.
• MIDI input/output/thru states can reuse the same icon with tiny arrows or colored pin accents instead of inventing separate symbols.
• The SysEx Vault could use a more serious version of this icon to signal "hardware memory operation" rather than ordinary note data.

Design reminder: Cute is fine; physically recognizable is better. MIDI users know what this port looks like.

Asset note: The final vector source lives in outputs/reports/midi-din-5-final.svg, and the older five-option comparison file was replaced with the same final geometry so stale mockups do not keep circulating.

2026-06-25 - MIDI Status And Health Sync Visibility

Task: Continue MIDI protocol priorities by checking current implementation status, reconciling the written status with actual first-pass UI, and surfacing incoming sync/status observations in the MIDI Health callout.

Existing connections:

• Incoming Clock, Start, Continue, Stop, Song Position Pointer, MTC, MMC, and Active Sense are already counted by the backend, so the Health panel should expose that state instead of hiding it in diagnostics.
• The Settings MIDI preflight area is becoming the first bridge between raw protocol support and customer-facing confidence.
• This connects directly to hardware setup, sync troubleshooting, and the future MIDI Dashboard: the user should know whether SpaceAge is actually seeing external timing messages before being asked to configure chase behavior.

Creative extension ideas:

• A future MIDI Dashboard can turn the sync row into a small live activity meter: Clock pulses, Start/Stop badges, last SPP beat, and last MTC/MMC observation.
• Hardware profiles could use observed sync data to suggest "This device appears to be sending clock" or "This device is quiet; check cable or output setting."
• The same Health model can become exportable as a support snapshot when a user reports MIDI hardware trouble.

Design reminder: MIDI power becomes trustworthy when invisible protocol events are translated into calm, readable status.

2026-06-25 - MIDI Assignment Visibility

Task: Add a first-pass MIDI Maps panel to Settings so stored and learned controller assignments can be inspected before the full MIDI Learn editor exists.

Existing connections:

• The backend already knows how to summarize MIDI mappings, validate duplicate or unresolved assignments, and group targets by destination.
• MIDI Health already reports mapping counts, but counts are not enough when a user needs to know which controller is moving which parameter.
• Settings is currently the least surprising place for a read-only diagnostic surface while the final controller-assignment workflow is still being designed.

Creative extension ideas:

• This panel can grow into the full MIDI Learn editor: click a row to remap, disable, invert, constrain range, smooth, or delete.
• A future hardware setup assistant can pre-fill meaningful names like "Launchkey Mod Wheel -> RedShift Filter" so the panel reads like musical intent rather than protocol trivia.
• If SpaceAge later supports user-shareable hardware profiles, this assignment view can become a confidence check before loading another musician's controller map.

Design reminder: A mapping that cannot be seen cannot be trusted. Read-only visibility is not the final workflow, but it is the first antidote to MIDI mystery.

2026-06-25 - MIDI Sync Observer Panel

Task: Add a read-only MIDI Sync panel to Settings so incoming Clock, Start, Continue, Stop, Song Position Pointer, MTC, MMC, and Active Sense observations are visible outside the general Health summary.

Existing connections:

• The backend already counts incoming sync/status families and preserves the last observed message label.
• MIDI Health already displays a compact Sync row, but hardware troubleshooting deserves a focused panel with individual counts.
• This keeps SpaceAge honest: observing sync is not the same thing as chasing sync, and the UI should teach that distinction.

Creative extension ideas:

• The panel can become a live “MIDI radar” that pulses when clock arrives, flashes Start/Stop, and shows last SPP beat as a small transport diagnostic.
• Hardware setup wizards can use the same counts to tell the user “your synth is sending clock” or “nothing is arriving yet; check the cable/output setting.”
• When incoming chase is eventually implemented, this observer can become the safety preflight before allowing SpaceAge to follow an external master.

Design reminder: External sync is powerful but disorienting when invisible. First show the signal, then offer behavior.

2026-06-25 - MIDI Import Review Details

Task: Expand the MIDI import preflight dialog so it includes compact review-dashboard sections for lane planning, expression, patch setup, SysEx, song metadata, transport/sync, and warnings when those are present.

Existing connections:

• The backend already builds a detailed MIDI import review dashboard, but the current import confirmation only showed the shorter summary.
• The existing preflight dialog is still a lightweight AlertWindow, so the improvement must be concise until the full import wizard exists.
• This bridges immediate user safety with the future channel-to-lane wizard: the same review model can power both.

Creative extension ideas:

• The future import wizard can turn each review section into a tab: Overview, Lanes, Expression, Patch Setup, SysEx, Song Metadata, Transport/Sync.
• For General MIDI files, this could become a guided “Create Band From MIDI” workflow with drums, bass, harmony, melody, and hardware setup lanes pre-suggested.
• For collaboration, import receipts could be saved into project notes so a user remembers exactly what SpaceAge did with an imported file.

Design reminder: Imports are mutation events. If SpaceAge is going to change a project, it should explain the shape of that change before touching the song.

2026-06-25 - MIDI Export Preflight Safety

Task: Put MIDI export readiness in front of the actual file-writing path for selected patterns, selected Arrangement clips, full Arrangement MIDI, and drum-only Arrangement MIDI.

Existing connections:

• MIDI export already has backend readiness summaries for channels, lanes, clips, route targets, notes, Chord Engine markers, and expression events.
• The import side now explains questionable files before mutating a project, so export should offer the same courtesy before creating collaborator-facing files.
• Arrangement lanes own instrument/channel truth, which makes export warnings especially valuable when a lane is muted, routed strangely, or contains no exportable material.

Creative extension ideas:

• The compact warning dialog can eventually become a full Render/MIDI Export preview with one row per lane, per-file options, and "drums only / selected lanes / full song" presets.
• Export preflight could feed project archive manifests so collaborators know exactly which MIDI tracks, channels, and expression lanes were included.
• Education workflows could show "why this file is empty" or "why this lane exports on channel 4" instead of leaving beginners to diagnose protocol behavior alone.

Design reminder: Export is a promise to another context: another DAW, a hardware sequencer, a collaborator, or a future self. Warn before writing a misleading file.

2026-06-25 - MIDI Input Destination Visibility

Task: Add a focused read-only MIDI Input panel in Settings so the user can see the armed lane, input device scope, channel filter, can-receive state, visible input count, and warnings.

Existing connections:

• The backend already produces MidiInputReadinessReport, but a single compressed preflight line is not enough when troubleshooting a controller.
• SpaceAge deliberately separates selected clip, selected lane, and armed lane. That is powerful, but it needs a readable explanation surface so live input does not feel random.
• The lane architecture is now the source of truth for MIDI input, output, mixer channel, and instrument ownership, so input status belongs near the lane/hardware MIDI tools.

Creative extension ideas:

• This can become the first screen of a MIDI setup assistant: choose device, choose channel, arm lane, play a note, confirm the signal.
• A future live monitor can pulse the armed lane badge when MIDI arrives and show rejected channels as small "filtered out" hints.
• MIDI guitar and wind-controller presets could use the same readiness view to explain per-channel performance setups before recording.

Design reminder: If the user asks "why isn't my keyboard playing this sound?", the app should answer from its own state, not make them infer the answer from scattered controls.

2026-06-25 - MIDI Output Preflight Visibility

Task: Add a first-pass read-only MIDI Out panel in Settings so external-output readiness, runtime open-device status, dropped-message count, and hardware-routed lanes are visible.

Existing connections:

• The processor already separates external output readiness from runtime state. Readiness answers "is this configured?" while runtime answers "is the device actually open right now?"
• Lane routing is now the source of truth for external MIDI targets, so hardware-routed lanes can be listed without creating another inspector.
• MIDI Health already summarizes output state, but hardware users need the lane rows and runtime status without digging through a general dashboard.

Creative extension ideas:

• The future Hardware Output Preflight can grow from this panel: each lane row can become editable, with device/profile pickers and a "test note" button.
• A hardware troubleshooting assistant can use the same readiness/runtime split to say "your lane is configured, but the OS device is closed" or "this lane needs an output device."
• External MIDI export and live hardware playback can eventually share the same confidence language: channel, device, profile, and route status.

Design reminder: External MIDI should never feel like a black cable disappearing into mystery. Show the route before asking the user to trust the send.

2026-06-25 - MIDI Maps Editing First Pass

Task: Upgrade the MIDI Maps Settings callout from a read-only diagnostics panel into a first-pass editor with row-level enable/disable and delete actions.

Existing connections:

• The processor already owns persistent MIDI control mappings and exposes safe upsert/remove paths, so the UI should use those instead of duplicating mapping state.
• MIDI Learn and control mappings are global performance features; they can cause surprising behavior if a controller remains mapped accidentally.
• The MIDI Health panel already summarizes whether mappings exist, but the user needs a direct way to silence or remove a bad mapping without editing project data by hand.

Creative extension ideas:

• This row-action panel can later grow into the full MIDI Learn editor: remap, min/max range, curve shape, inversion, dead zone, and target picker.
• A future "MIDI Trouble Center" could link from a warning directly to the suspicious row in this panel.
• Mapping presets could eventually become sharable controller templates for common hardware, MIDI guitars, wind controllers, and compact keyboard controllers.

Design reminder: MIDI mapping needs an emergency brake. A control surface is only empowering if the user can quickly see and disable the invisible wires.

2026-06-25 - MIDI Learnable Target Visibility

Task: Add a compact target-discovery section inside the MIDI Maps callout so users can see how many learnable destinations SpaceAge currently exposes.

Existing connections:

• The processor already discovers APVTS-backed targets, but that information was invisible unless a developer inspected the registry.
• MIDI Learn needs two mental models: current assignments and possible destinations. Showing both in one panel makes the mapping system feel less like hidden machinery.
• Future target picking can reuse this exact concept, expanding from a summary into a searchable destination browser.

Creative extension ideas:

• The target summary can later become a filterable list grouped by synth, mixer, lane, effects, transport, and global project controls.
• A "map this target" affordance can eventually launch Learn directly from a row, so hardware setup feels conversational: pick destination, move control, confirm.
• Controller templates can use target groups to suggest sane default mappings for MIDI keyboards, pad controllers, wind controllers, and MIDI guitars.

Design reminder: Teach the user what SpaceAge can hear and what SpaceAge can control. MIDI feels effortless only when both sides of that relationship are visible.

2026-06-25 - Lane Hardware Profile Entry Point

Task: Replace the disabled "Hardware Profile (coming soon)" lane menu item with a working route into the existing MIDI Routing panel, which already exposes hardware output and profile selectors.

Existing connections:

• Lane MIDI Routing is now the natural home for input filter, playback/export channel, hardware output, route target, and hardware profile.
• A disabled item next to a working routing panel created false friction and suggested the hardware workflow was less complete than it really is.
• This keeps the lane badge as the source of truth for instrument and MIDI routing, which matches the Instrument Bay decision.

Creative extension ideas:

• The same hardware profile entry point can later expose a "create profile from this lane" action and a "send test note" action.
• Hardware profiles can become lane templates that recall Program Change, Bank Select, SysEx, output device, and channel in one move.
• A future MIDI setup assistant can open directly from this menu when the lane has hardware routing warnings.

Design reminder: Never label a door "coming soon" if another working door already reaches the room. Route the user to the clearest existing control.

2026-06-25 - Live MIDI Latency Diagnosis

Task: Audit the live MIDI note path and make the MIDI Health latency language distinguish SpaceAge's internal sample-positioned scheduling from audio-driver/interface/hardware latency.

Existing connections:

• processBlock() passes JUCE MIDI event sample positions into handleIncomingMidiMessage(), and note starts flow into voices through delayedStartSamples.
• The existing MIDI Health surface already reports block size and sample rate, so it is the right place to explain whether the live buffer is likely to feel sluggish.
• The future MIDI setup assistant can reuse this same diagnostic language instead of making users guess whether latency belongs to SpaceAge, Windows, the interface, the MIDI controller, or the audio driver.

Creative extension ideas:

• Add a small "Live MIDI Test" panel: press a key, see input device, channel, armed lane, block time, and output target in one readout.
• Add a per-session MIDI confidence meter that says "low-latency ready" only when the armed lane exists, the input device is visible, and block time is comfortably low.
• Pair latency diagnostics with recommended actions: lower buffer, use ASIO, avoid Bluetooth MIDI/audio, choose a direct interface path, or disable expensive preview effects while tracking.

Design reminder: Latency is a trust issue. The app should tell the user which part of the chain is late instead of letting the whole instrument feel haunted.

2026-06-25 - Lane Hardware Test Note

Task: Add a hardware test-note action to the lane MIDI routing panel so a user can verify external device routing without starting playback or recording.

Existing connections:

• Lane routing is now the source of truth for hardware output device, route target, MIDI channel, and hardware profile attachment.
• The hardware output router already queues explicit messages safely, so a test note can use the same queued path as recall/transport instead of inventing a new side channel.
• The MIDI Out and MIDI Health panels can report readiness, but a test note gives the user a tactile proof point: "yes, this lane speaks to that box."
• Test note queue attempts now write into the hardware recall log, which means the Settings hardware viewer can show the handshake instead of relying on user memory.

Creative extension ideas:

• Later versions can add a "Test Scale" or "Test Chord" option for hardware synths, plus a "Test Drum Map" option for external drum machines.
• The future Hardware Setup Assistant can use the same helper after device selection: choose output, choose channel, send note, ask whether the user heard it.
• For MIDI guitar/wind-controller workflows, this could grow into a response-check screen that shows incoming notes and outgoing hardware echo separately.

Design reminder: Hardware setup is easiest when the app provides small, reversible proofs. A test note is a handshake, not a commitment.

2026-06-25 - RedShift Synthwave Starting Points

Task: Add ten more RedShift starting-point presets aimed at Synthwave, keeping them chord-friendly and musically stable.

Existing connections:

• RedShift is the renamed core subtractive synth, so it should become a reliable source of immediate genre-appropriate sounds.
• The Instrument Bay and Arrangement lanes benefit when built-in presets are strong enough that beta testing feels musical without external VSTs.
• Prior "jazz horror" tuning mistakes make conservative oscillator ratios and pitch discipline part of the preset design checklist.

Creative extension ideas:

• A future preset browser can tag these as Synthwave, Chord-Safe, Bass, Lead, and Pad so they become searchable teaching material.
• The same preset families could seed template projects: "Synthwave Sketch", "Night Drive Cue", or "Retro-Future Intro".
• RedShift's multi-page GUI can eventually display a short patch note for each preset explaining what it is good for.

Design reminder: Genre presets should spark recognition quickly, but they must still respect pitch, chords, and CPU sanity.

2026-06-25 - MIDI Hardware Passport Viewer

Task: Add a Settings callout that shows saved hardware MIDI profiles, their recall-plan previews, and the recent hardware queue log without adding an automatic send command.

Existing connections:

• Hardware profiles already store device identity, output device, MIDI channel, bank/program recall, transport/sync preferences, and linked SysEx snapshots.
• SysEx snapshots already live in a safe project-owned vault and are deliberately separated from ordinary clip playback and performance expression.
• The hardware output router already logs explicit queue attempts, so the UI can show what was queued without inventing a second diagnostic path.

Creative extension ideas:

• The viewer can become the calm front door to a future Hardware Setup Assistant: choose output, pick channel, test note, preview recall, confirm send.
• The same panel can later expose "Recall Profile" only after showing bank/program/SysEx steps, delays, warnings, and a progress meter.
• External-instrument templates could package a lane route, hardware profile, safe SysEx snapshot list, and recommended MIDI input filters into one reusable setup.

Design reminder: Hardware MIDI needs ceremony. Profiles are passports, recall plans are checklists, and SysEx sending is never casual.

2026-06-25 - Lane-Owned Hardware Profile Creation

Task: Add a create-and-attach hardware profile action directly to the Lane MIDI Routing panel.

Existing connections:

• Lane MIDI Routing already owns hardware output assignment, route target, playback/export channel, and profile assignment.
• The processor already had createHardwareMidiProfileForLane(), so the UI can use that safe backend instead of inventing a separate profile pathway.
• Instrument Bay decisions taught us to avoid top-level intermediary inspectors; profile creation belongs where the user is already looking at the lane's hardware route.

Creative extension ideas:

• The same button can later open a guided profile editor immediately after creation: device name, manufacturer, model, bank/program, SysEx snapshots, and clock behavior.
• A future Hardware Setup Assistant can start from this exact action: create profile, test note, confirm audible response, then optionally capture or attach setup data.
• Lane templates could eventually store a profile plus routing defaults so a favorite external synth setup can be reused in new projects.

Design reminder: If the lane owns the instrument route, the lane should also own the external-instrument passport. No mystery top inspector.

2026-06-25 - Hardware Recall Preview Details

Task: Expand the Settings MIDI Hardware panel so each profile shows the first concrete recall messages in its preview instead of only a summary sentence.

Existing connections:

• The MIDI backend already builds ordered hardware recall plans, including Bank Select, Program Change, SysEx snapshots, byte counts, delays, and confirmation flags.
• The Settings hardware panel is intentionally observational, so adding message-level previews improves trust without adding a risky "send now" workflow.
• Lane-created hardware profiles now have a visible destination: after creation, the user can inspect whether the profile has a real recall plan or is just an identity shell.

Creative extension ideas:

• A future Hardware Setup Assistant can reuse the same compact message rows as a final confirmation checklist before sending to a synth.
• A progress meter for confirmed recall can mirror these same rows, advancing through Bank Select, Program Change, and SysEx snapshot steps.
• Hardware templates could eventually include manufacturer-specific readable labels for otherwise cryptic SysEx messages.

Design reminder: External MIDI confidence comes from seeing the exact ritual before it happens. Preview first, confirm second, send last.

2026-06-25 - SysEx Descriptor Safety Layer

Task: Add a shared MIDI-layer SysEx descriptor that classifies raw SysEx bytes into human-readable manufacturer, message-class, safety, size, and warning metadata.

Existing connections:

• The SysEx Vault already stores imported dumps safely, but raw hex alone is not enough for most users to understand what they captured.
• Hardware recall planning already treats SysEx as confirmation-required, so a descriptor gives the future confirmation dialog better language without changing send behavior.
• MIDI Health and project preflight can reuse the same descriptor to explain invalid framing, large dump risk, universal messages, and conservative delay recommendations.

Creative extension ideas:

• A future Hardware Setup Assistant can label captured responses as identity replies, patch dumps, or large bulk transfers before asking the user what to do.
• Manufacturer-specific knowledge packs could later translate known SysEx families into friendlier labels while keeping this generic parser as the safe fallback.
• The descriptor layer can feed project archive reports so collaborators know which external hardware dumps are included and why they require explicit recall.

Design reminder: SysEx should feel like a sealed hardware envelope with a clear label on it. The app can explain the envelope before anyone opens or sends it.

2026-06-25 - Hardware Panic-On-Stop Transport Plan

Task: Make hardware profiles that opt into sendPanicOnStop include panic messages in the same stop transport plan that already sends MIDI Stop.

Existing connections:

• Hardware profiles already store sendPanicOnStop, but the transport plan was not yet using it.
• Transport plans already feed both previews and queued hardware messages, so adding panic messages there keeps UI explanation and actual behavior aligned.
• The existing makePanicMessages() helper centralizes All Sound Off, Reset All Controllers, and All Notes Off in the correct channel-scoped order.

Creative extension ideas:

• The future Hardware Setup Assistant can offer a "protect this synth from stuck notes on stop" checkbox that maps directly to this profile field.
• Hardware transport previews can show the stop ritual as a readable sequence: Stop, All Sound Off, Reset Controllers, All Notes Off.
• Per-device profiles could later choose between gentle stop, panic-on-stop, or transport-only behavior depending on how old hardware responds.

Design reminder: Stuck notes are a trust killer. Hardware stop should be predictable, previewable, and boring in the best possible way.

2026-06-25 - MIDI Timing And Song Metadata Honesty

Task: Strengthen MIDI file import inspection so timing format, tempo, meter, and key metadata are visible and guarded before any project-level decision.

Existing connections:

• The import review dashboard already had a Song Metadata section, so the right move was to deepen that path rather than create another MIDI inspector.
• SpaceAge already uses 960 PPQ internally, which makes it especially important to say when an incoming file uses another PPQ value or SMPTE/timecode timing.
• The Import Wizard safety posture already protects SysEx, transport, and device setup; tempo/meter/key metadata deserves the same explicit review layer.

Creative extension ideas:

• A future "Adopt Song Metadata" dialog can use the same extracted tempo/meter/key rows to let the user import a whole song form intentionally.
• Arrangement Section markers could eventually be seeded from key/meter/tempo landmarks, giving imported MIDI files a more useful visual map.
• Collaborator import receipts could list "kept project tempo" versus "adopted source tempo map" so there is no ambiguity when exchanging files.

Design reminder: Imported MIDI should never feel like a trapdoor. Notes can become clips, but tempo maps and key maps are composer-level decisions.

2026-06-25 - MIDI Export Timing Receipts

Task: Add explicit timing context to MIDI export job rows so outgoing files report PPQ, BPM, and exported step range.

Existing connections:

• Export readiness already knows PPQ, BPM, scope, lanes, clips, and event counts; the job rows can expose that rather than making the user infer it.
• Import review now explains source timing, so export should be symmetrical: tell the user what SpaceAge is writing.
• The future export progress meter can reuse the same row/detail language while rendering pattern, selected clip, full arrangement, drum-only, and lane-track outputs.

Creative extension ideas:

• A future "MIDI Export Receipt" could save a small sidecar text/JSON report beside a .mid so collaborators know exactly what was exported.
• When tempo maps arrive later, this same line can grow from "120 BPM" into "tempo map: 4 changes" without redesigning the UI.
• Render Audio/MIDI/Stem export can share one receipt style: scope, timing, destination, lanes, warnings, and result.

Design reminder: A professional export should feel accountable. The app should tell the user what it is about to write before it writes it.

2026-06-25 - SysEx Snapshot Profile Attachments

Task: Add backend helpers for attaching and detaching SysEx snapshots from hardware MIDI profiles without sending them.

Existing connections:

• SysEx snapshots already live in a confirmation-required vault, and hardware profiles already hold sysExSnapshotIds.
• Hardware recall plans already read profile-linked snapshot IDs, so a narrow attachment helper makes that relationship explicit and testable.
• The lane-owned hardware profile workflow now has a natural next step: attach safe snapshots to the lane's external-instrument passport.

Creative extension ideas:

• The future SysEx Vault UI can show an "Attach to Profile" action beside each snapshot, followed by a recall-plan preview.
• A Hardware Setup Assistant can capture a dump, label it, attach it, and then show the profile's recall checklist without ever auto-sending it.
• Project archive reports can list which snapshots are merely stored and which are actively attached to a hardware profile.

Design reminder: Attaching SysEx is bookkeeping. Sending SysEx is ceremony. Keep those actions emotionally and technically separate.

2026-06-25 - SysEx Vault Attach/Detach Workflow

Task: Expose a first-pass SysEx Vault workflow that lets the user attach or detach a stored snapshot to a hardware profile.

Existing connections:

• The backend attachment helpers already connect SysExSnapshot records and HardwareMidiProfile records without sending anything.
• The Settings page already has both MIDI Hardware and SysEx Vault callouts, so this workflow belongs there rather than in the Arrangement lanes.
• Hardware recall previews already count profile-linked snapshots, so attachment immediately improves profile readability.

Creative extension ideas:

• The future Hardware Setup Assistant can become a guided version of this: capture/import, name, attach, preview, then optionally send with progress.
• Profile rows could later show "required on load," "optional recall," or "archive only" snapshot roles.
• A project archive report can distinguish stored SysEx from profile-attached SysEx, which matters for collaborators with different external gear.

Design reminder: A SysEx snapshot can be attached like a label on a hardware passport. That is not the same as pressing Send.

2026-06-25 - Sample-Positioned MIDI Note-Offs

Task: Give incoming live MIDI note-offs the same sample-positioned respect that note-ons already had.

Existing connections:

• Live note-ons already entered voices with a delayed start count based on MidiMessageMetadata::samplePosition.
• The voice renderer already advances per sample, so adding a delayed release counter fits the existing engine instead of requiring a full MIDI/audio interleave rewrite.
• This supports the same performance promises as MIDI Health latency reporting: internal block time should be measurable and honest.

Creative extension ideas:

• This same timing vocabulary can later apply to pitch bend, CC, sustain, and aftertouch so expression changes land sample-accurately too.
• MIDI guitar and wind-controller workflows will benefit from tighter note ends, because those controllers can generate very fast articulated events.
• A future "Live Feel" diagnostic could show note-on/note-off timing separately from driver/interface latency.

Design reminder: Human timing lives on both edges of the note. If SpaceAge respects the attack but fudges the release, musicians will feel it before they can name it.

2026-06-25 - Count-In Downbeat Recording Gate

Task: Make MIDI recording respect the exact sample where a count-in ends when that downbeat happens inside the current audio block.

Existing connections:

• Count-in already lives in processSequencer(), while MIDI input is scanned afterward in processBlock(). The fix connects those two truths with a simple activation sample stamp.
• MIDI recording already accepts sample offsets for note starts and note releases, so the count-in gate can reuse that timing vocabulary instead of adding a second recording path.
• The MIDI Health latency story depends on this: if the app says it is sample-aware, the first recorded note after count-in must land at the musical downbeat, not at the beginning of the host buffer.

Creative extension ideas:

• A future recording overlay could show "recording opens in 83 samples" or "capture armed at next bar" using the same activation sample logic.
• If SpaceAge later supports punch-in recording, the count-in gate can generalize into a reusable "record capture window" model.
• MIDI guitar and wind-controller profiles will benefit because expressive players often enter slightly before or exactly on the downbeat; the app should distinguish anticipation from actual capture.

Design reminder: Count-in is a promise. The musician waits for SpaceAge to say "now," and the code has to agree down to the sample.

2026-06-25 - Sample-Positioned Live MIDI Expression

Task: Queue incoming live MIDI expression messages to their real MidiBuffer sample position and apply them during per-sample rendering.

Existing connections:

• The audio engine already renders voices sample by sample, and voices already read channel pitch bend, mod wheel, pan, gain, expression, and sustain state from shared MIDI performance state.
• MIDI recording and Arrangement playback already store expression as timeline payloads, so live controller input should follow the same timing discipline as drawn/imported controller data.
• The MIDI Health latency promise is stronger when note-ons, note-offs, and performance expression all respect sample positions.

Creative extension ideas:

• This queue can become the foundation for drawable pitch-bend/CC/pressure automation lanes that feel identical to live controller performance.
• MIDI guitar and wind-controller profiles can later route breath, pressure, and bend into expressive synth parameters without the "block jump" feel.
• A future Motion Clips system can share this internal event scheduling pattern for tempo-locked modulation gestures.

Design reminder: Expression is performance, not bookkeeping. If a player bends or opens the mod wheel halfway through a buffer, SpaceAge should hear that gesture where it happened.

2026-06-25 - Quasar Loop On Release

Task: Track Loop on Release as a future behavior for SpaceAge's proprietary sampling format.

Existing connections:

• Quasar already stores capture settings and sustain-loop metadata in its package manifest, so release-loop behavior belongs in that same zone/manifest family rather than as an unrelated effect.
• SoundFonts and conventional samplers already teach users that loop points can be part of an instrument's identity; SpaceAge can make that idea more composer-friendly by naming the behavior plainly.
• The live MIDI note-off work matters here: release behavior only feels musical if note release timing is respected.

Creative extension ideas:

• A bowed-string, wind, reversed pad, granular texture, or tape-decay Quasar patch could sustain one loop while held, then enter a different moving release loop after note-off.
• Loop on Release could later pair with velocity, mod wheel, or aftertouch so releases bloom differently depending on performance.
• This could become part of Quasar's "instrument personality" metadata: sustain loop, release loop, release tail, round robin, and motion-safe behavior.

Design reminder: A release is not merely the end of a note. For expressive samples, the release can be the emotional punctuation.

2026-06-25 - Sample-Positioned All Notes Off

Task: Make incoming live MIDI All Notes Off respect the event's MidiBuffer sample position instead of releasing every active channel voice at the beginning of the audio block.

Existing connections:

• Live note-ons, note-offs, and expression messages now respect sample positions, so channel reset behavior should follow the same timing discipline where it affects musical note release.
• All Notes Off is a channel-mode message, not a generic performance knob; keeping it out of the expression queue avoids treating a safety/reset command as ordinary controller movement.
• This complements Panic, Stop, hardware profile reset plans, and the MIDI Health latency story.

Creative extension ideas:

• A future MIDI diagnostics panel can distinguish "panic now" from "channel note release at sample X" for deeper hardware troubleshooting.
• External hardware lanes can reuse the same distinction: destructive safety messages are explicit, while musical releases remain timing-aware.
• MIDI guitar and wind-controller profiles often send dense channel messages, so channel-level release accuracy helps those advanced workflows feel less sloppy.

Design reminder: Safety commands should be reliable, but musical reset edges should still land where the controller actually sent them.

2026-06-25 - Live MIDI Pressure Runtime State

Task: Add channel pressure and poly aftertouch to SpaceAge's sample-positioned live MIDI performance state.

Existing connections:

• SpaceAge already classifies, imports, exports, transforms, and learns pressure messages; live playback needed the same respect so protocol support is not merely archival.
• The live expression queue now has one shared path for pitch bend, pressure, mod wheel, volume, expression, pan, sustain, and reset behavior.
• Future synth modulation pages can now read pressure from processor state instead of each engine creating a private one-off pressure parser.

Creative extension ideas:

• Redshift, Liftoff, Moonshadow, and Quasar could offer simple "Pressure -> Filter", "Pressure -> Vibrato", or "Pressure -> Brightness" assignments.
• Wind-controller and MIDI-guitar profiles can treat pressure as a first-class expressive source, which supports the hardware-friendly product angle.
• Motion Clips and automation lanes can eventually draw pressure curves that use the same internal scheduling path as live controller gestures.

Design reminder: Pressure is the difference between pressing a key and leaning into a note. Treat it as a musical gesture, not just a stored MIDI number.

2026-06-25 - Guard Setup Controllers From Performance Paths

Task: Prevent live MIDI setup/channel-mode controller messages from falling through into pad triggering or the legacy performance-cutoff CC behavior.

Existing connections:

• RPN, NRPN, Data Entry, Local Control, Omni, Mono, and Poly mode messages are already classified as protocol/setup traffic rather than ordinary musical knobs.
• MIDI recording can still preserve timeline-appropriate setup data where useful, but live playback should not let those messages masquerade as note or filter gestures.
• This reinforces the Hardware Setup Assistant direction: dangerous or device-specific commands should be inspected and explained, not accidentally performed as music.

Creative extension ideas:

• Future MIDI Health can show "setup message received and ignored for live performance" rather than leaving the user to infer why nothing audible happened.
• The same guardrail can become a reusable policy for MIDI import, MIDI Learn, live input, and external hardware recall.
• Hardware profiles can later expose specific RPN/NRPN controls deliberately, with labels and ranges, instead of treating them as anonymous CC traffic.

Design reminder: MIDI protocol detail is powerful, but it should not sneak into the creative surface wearing a fake moustache.

2026-06-25 - MIDI Protocol Coverage UI

Task: Make the MIDI Protocol surface show separate backend-family and customer-facing-family coverage, plus safety notes for each MIDI family.

Existing connections:

• The backend already tracks MIDI families, import/export safety, SysEx quarantine, routing, sync, and MIDI Learn readiness. The UI now exposes that structure without pretending every musician-facing workflow is done.
• The user's requested end-of-round MIDI percentage report now has an in-app cousin: protocol family coverage is visible where the Settings MIDI tools live.
• Safety language connects directly to SysEx, transport, clock, program/bank, RPN/NRPN, and hardware profile work, all of which can harm external setups if made too automatic.

Creative extension ideas:

• The same coverage panel can later become a clickable MIDI Dashboard, where each row opens the exact unfinished workflow: SysEx Vault, Import Wizard, MIDI Learn, Sync, Hardware Preflight, or Expression Lanes.
• A release-readiness checklist could reuse these family rows and refuse to mark MIDI as "complete" until every row has both backend and customer-facing coverage.
• Support docs and tooltips can quote these same family descriptions so the product teaches MIDI safely without burying users in protocol jargon.

Design reminder: A protocol dashboard should build trust. It should say, plainly, what SpaceAge understands, what SpaceAge protects, and what still needs a human-facing control.

2026-06-25 - MIDI Import Action Preview

Task: Add an action-preview section to MIDI import confirmation so the user can see what SpaceAge recognized before clicking Import.

Existing connections:

• The MIDI backend already creates an import plan, review dashboard, dry-run preview, and recommended commit request. The confirmation dialog now exposes more of that existing knowledge instead of hiding it behind a single warning blob.
• Current selected-pattern MIDI import is intentionally narrower than the future full Import Wizard. The wording now separates the actual current command from the broader recognized actions, avoiding overpromising.
• The same preview vocabulary can later become the full wizard's checklist, where each row becomes editable rather than merely explanatory.

Creative extension ideas:

• Convert each action row into a real toggle: create lanes, preserve expression, quarantine SysEx, review tempo/meter/key, ignore transport sync.
• Store the final import decision as a receipt in project history so the user can later understand why a file became certain lanes/clips.
• Use the same preview UI for drag-and-drop MIDI import, Library import, and future hardware librarian recall.

Design reminder: Importing MIDI is not just loading notes. It is translating another studio's assumptions into SpaceAge, and the user deserves to see the translation before committing.

2026-06-25 - Designed MIDI Import Review Panel

Task: Replace the generic MIDI import warning dialog with a SpaceAge-styled review callout.

Existing connections:

• The review panel reuses buildMidiImportPreflightMessage(), so it stays connected to the same backend import plan, review dashboard, and action preview instead of inventing a separate UI-only interpretation.
• The panel uses the same visual language as other MIDI settings callouts, helping MIDI feel like a guided SpaceAge workflow rather than an operating-system interruption.
• Import still flows through importMidiFileIntoSelectedPattern(), so the safer UI does not alter the actual mutation path yet.

Creative extension ideas:

• The scrollable review body can evolve into a real wizard with toggles for lane splitting, expression preservation, SysEx vault storage, tempo/key/meter adoption, and hardware setup review.
• The Import/Cancel footer could later add "Inspect Only" and "Save Import Plan" for educational or hardware-heavy users.
• Similar styled review panels should replace future export, hardware recall, SysEx send, and destructive reset confirmations.

Design reminder: When the app is about to translate outside musical data, the dialog should feel like a calm co-pilot, not a scary interruption from Windows.

2026-06-25 - Selected-Pattern MIDI Import Receipt

Task: Route selected-pattern MIDI import status through the shared MIDI import apply-result model.

Existing connections:

• The current Import MIDI command still mutates only the selected pattern, but the backend already has MidiImportCommitRequest and MidiImportApplyResult as the future-safe vocabulary for what happened.
• importPatternMidi() already preserves safe expression payloads and quarantines SysEx snapshots, so the UI should not reduce that work to a vague "MIDI imported" line.
• The new SpaceAge-styled import review panel and the post-import receipt now speak the same backend language: selected command, expression, SysEx, metadata review, transport/sync, and warnings.

Creative extension ideas:

• Store import receipts in project history, letting users open a "Why did this import become this?" panel later.
• Let the full Import Wizard preview and final receipt sit side by side: what SpaceAge planned, what the user chose, and what actually changed.
• Use the same receipt pattern for render/export, SysEx recall, hardware setup, and destructive cleanup actions so SpaceAge feels accountable.

Design reminder: A good import workflow should not just ask permission. It should leave a receipt.

2026-06-25 - MIDI Expression Inspector

Task: Add a Settings MIDI surface that shows and safely edits expression lanes for the currently selected pattern.

Existing connections:

• The backend already preserves MIDI expression payloads as pattern-scoped MidiEventList data and can summarize them into lanes. The new inspector turns that invisible preservation into something the user can verify.
• The inspector uses the existing transform helpers for step quantizing and redundant-event thinning, so it does not create a second expression-editing logic path in the GUI.
• The panel's wording deliberately says "selected pattern" because expression payloads are not yet clip/lane-local. That honesty prevents a future workflow trap where shared patterns replay an unexpected controller history.

Creative extension ideas:

• Promote this inspector into full drawable CC, pitch bend, pressure, and program/bank lanes once the visual editor is ready.
• Add "convert expression to clip-local automation" when Arrangement clips gain independent expression payload IDs.
• Let MIDI Import Wizard decisions route expression lanes either into pattern payloads, clip-local automation, or hardware/profile review depending on the user's intent.

Design reminder: Expression data is musical gesture. The app should make it visible, editable, and accountable before it becomes complex.

2026-06-25 - MIDI Patch Setup Inspector

Task: Add a Settings MIDI surface that shows imported Bank Select and Program Change rows for the selected pattern.

Existing connections:

• The MIDI layer already summarizes patch setup through MidiPatchEventSummary; the new inspector exposes that work without creating a new parser in the editor.
• Patch setup lives beside MIDI Expression because both currently travel through selected-pattern MIDI payloads. Seeing them together helps explain what a Standard MIDI File brought into the project.
• The panel is intentionally read-only. Program and bank messages may change external hardware patch/setup state when deliberately queued, or imply SoundFont/internal preset changes, so mapping them must be explicit rather than automatic.

Creative extension ideas:

• Let the full Import Wizard convert patch rows into SoundFont preset choices, lane hardware profile defaults, or ignored setup data.
• Add a "Create Hardware Profile From Row" action once profile editing has a confirmed review step.
• Add a "Map Program To Instrument Bay Preset" workflow so General MIDI files can become SpaceAge-native lanes without silent preset mutation.

Design reminder: Patch setup is not decoration. It is somebody else's studio recall instruction, and SpaceAge should read it politely before deciding whether to obey it.

2026-06-25 - MIDI Import Wizard Boundary

Task: Reframe the existing selected-pattern MIDI import review as a first-page Import Wizard preview while preserving the current safe mutation path.

Existing connections:

• The backend already has import inspection, lane candidates, review dashboards, apply previews, commit requests, and apply receipts. The UI can therefore evolve into a full wizard without inventing a second interpretation of MIDI files.
• Current import still lands in the selected pattern through importPatternMidi(). That keeps the fragile mutation path stable while the user sees richer information about channels, expression, patch setup, SysEx, tempo/meter/key metadata, and sync.
• Ptolemy's audit confirmed that lane creation is not part of the current import mutation path. Treating the current panel as a preview prevents the UI from implying that channel-to-lane splitting already happens.

Creative extension ideas:

• Page 1 can remain the calm preflight summary; Page 2 can become channel-to-lane mapping; Page 3 can handle expression/patch/SysEx policy; Page 4 can show the final receipt.
• The same wizard structure can later be reused for SoundFont/General MIDI import, hardware librarian recall, and archived project repair.
• Let users save import decisions as templates, such as "GM song to 16 lanes", "drums only", or "hardware setup vault only".

Design reminder: The wizard should be truthful before it is powerful. First show what SpaceAge understands, then let the user decide how much translation to perform.

2026-06-25 - MIDI Import Lane-Split Guardrail Copy

Task: Make the MIDI Import Wizard Preview explicitly say when channel-to-lane splitting was detected but not committed by the selected-pattern import button.

Existing connections:

• The import backend can already inspect channels and produce lane-split preview actions. The UI now states that those actions are recognized review data, not something the current selected-pattern button silently performs.
• This connects directly to the long-form drum payload problem: if SpaceAge creates drum lanes from a long Standard MIDI File before the Drum Composer payload model can represent that length honestly, the visual clip and the audible data can disagree.
• The import button tooltip, action-preview header, and text review now use the same customer-facing boundary, reducing the chance that a user expects a full General MIDI lane explosion from a selected-pattern import.
• The disabled "Split Channels To Lanes" footer button is intentionally visible when the file supports that idea, because a visible locked path teaches the future workflow without letting the user trigger an unsafe partial implementation.

Creative extension ideas:

• Turn the guarded lane-split notice into a real wizard page with channel checkboxes, lane-type suggestions, target instruments, and "drums as long-form lane" policy once the payload model is ready.
• Add import templates such as "single pattern", "split melodic channels", "GM song", and "drums only" so expert users can move quickly without losing the protective review layer.
• Use the same "recognized but guarded" language for future hardware recall, SysEx send, and tempo-map adoption where SpaceAge can understand a request before it is safe to perform it.

Design reminder: A preview is only trustworthy if the user can tell which recognized actions will happen now and which are waiting for a fuller workflow.

2026-06-25 - MIDI Protocol Next-Actions Strip

Task: Add a compact next-actions strip to the MIDI Protocol Coverage panel so backend readiness naturally points toward the next musician-facing workflow.

Existing connections:

• The protocol coverage report already separates backend readiness from customer-facing readiness. The new strip uses that distinction to surface the first few backend-ready/UI-pending families as the next visible work.
• This gives the Settings MIDI surface a project-management quality without adding a separate backlog panel inside the app.
• It reinforces the current MIDI philosophy: SpaceAge may understand a MIDI family internally, but the user should not be asked to trust it until the workflow is visible and guided.

Creative extension ideas:

• Make each next-action phrase clickable later, opening the relevant unfinished panel: drawable expression lanes, patch mapping, SysEx recall, Import Wizard, Sync, or Hardware Preflight.
• Convert the same ranked list into release readiness criteria so the product knows what is still "protocol understood" versus "customer usable".
• Use this dashboard as a support screen: if a user asks why a MIDI feature is not editable yet, the panel can explain whether it is backend-ready, guarded, or future.

Design reminder: A dashboard should not only measure health. It should reduce uncertainty about what happens next.

2026-06-25 - MIDI Map Inversion As A Safe Performance Primitive

Task: Add an invertible direction flag to learned MIDI mappings and expose it as a first-pass INV action in Settings / MIDI Maps.

Existing connections:

• MIDI Learn already stores minimumValue and maximumValue, applies mappings at runtime, and summarizes assignment rows. Inversion extends that same model instead of creating a new controller path.
• The MIDI Maps row actions already support enable/disable and delete, so INV fits the established surface without requiring a full mapping editor yet.
• This is safer than deeper range/curve editing because it is a reversible boolean and does not alter target discovery, MIDI recording, note playback, or Arrangement data.

Creative extension ideas:

• Inversion is the first tiny piece of a larger control-shaping system: min/max range, curve, dead zone, smoothing, bipolar response, and named hardware-controller templates.
• A future MIDI Learn overlay can ask, "Did that move the wrong way?" and offer Invert immediately after capture.
• Wind controllers, expression pedals, and MIDI guitar controllers could ship with recommended mapping profiles that use inversion and range limiting to feel musical out of the box.

Design reminder: MIDI control mapping should feel like fitting a physical instrument to the player, not like debugging a hidden table.

2026-06-25 - SysEx Vault No-Autosend Guardrail

Task: Make the SysEx Vault attachment workflow more explicit about the difference between attaching a snapshot to a hardware profile and sending bytes to external hardware.

Existing connections:

• SysEx snapshots already default to confirmation-required and use conservative send-delay recommendations.
• Hardware profiles already expose recall previews without giving the user a casual automatic send button.
• The SysEx Vault already performs attach/detach as metadata bookkeeping, so the UI language should make that safe boundary impossible to miss.

Creative extension ideas:

• Use the same "No Autosend" strip style for future hardware recall, program/bank send, and firmware-dump workflows.
• Add a later dedicated Confirm + Send ceremony with byte count, target device, delay schedule, and a progress/log receipt.
• Let project archives include a "hardware recall manifest" that lists stored SysEx separately from sent SysEx history.

Design reminder: SysEx should feel powerful but sealed. The musician can label the envelope today; opening and mailing it is a separate ritual.

2026-06-25 - MIDI Hardware No-Autosend Guardrail

Task: Make the MIDI Hardware Passports panel use the same no-autosend safety language as the SysEx Vault.

Existing connections:

• Hardware passports already preview recall plans and show recent queue history.
• The runtime can queue explicit hardware test notes and guarded transport/clock messages, so user-facing panels must make clear which actions actually transmit and which only describe intent.
• Matching the SysEx Vault wording reduces the chance that a user mistakes a recall preview for a command sent to an external synth.

Creative extension ideas:

• A future hardware recall wizard can reuse this strip, then replace "preview only" with a step-by-step confirmation receipt.
• The hardware queue log could later include manual test note, clock, transport, program change, and SysEx send categories with timestamps.
• Hardware profile templates could include a "safe by default" badge when SysEx sends, transport sends, and clock sends are all disabled.

Design reminder: A hardware profile is a passport, not a launch button. It describes the destination before SpaceAge asks permission to travel there.

2026-06-26 - MIDI Expression Value Nudging

Task: Expose first-pass value up/down edits in the MIDI Expression panel using the existing backend expression offset transform.

Existing connections:

• The MIDI expression backend already supports quantize, thin, scale, and offset transforms; the panel previously exposed only quantize, thin, and delete.
• Value nudging is a small customer-facing bridge toward drawable CC, pitch bend, and pressure lanes without creating a second expression editing model.
• Pitch bend uses a larger offset step than 0-127 controller lanes, respecting the wider intrinsic range of bend data.

Creative extension ideas:

• Add a later Amount selector so value nudges can be tiny, medium, or dramatic depending on whether the user is editing CC, bend, or pressure.
• Reuse this same transform path for future selection-based edits in the Piano Roll, such as "raise selected mod wheel lane" or "soften selected breath-controller data."
• The eventual drawable expression lane can offer both direct drawing and batch actions that call this same backend transform, preserving one source of truth.

Design reminder: MIDI expression editing should grow from safe batch operations into visual editing, not fork into separate invisible systems.

2026-06-26 - MIDI Setup Data Is Not Expression

Task: Protect Bank Select, Program Change, RPN/NRPN, and Data Entry rows from the generic MIDI Expression editor while keeping them preserved and visible.

Existing connections:

• The MIDI Patch panel already exists to review Bank Select and Program Change without silently changing instruments or external hardware.
• The expression transform backend is useful for performance data, but hardware/setup messages have ordering and recall semantics that make generic value nudging dangerous.
• Marking setup rows as review-only keeps import/export fidelity intact while preventing a user from accidentally corrupting hardware recall data.

Creative extension ideas:

• Route review-only setup rows directly into a future Patch Mapping Wizard where the user can decide whether those rows target a SoundFont program, an internal preset, or an external hardware profile.
• Use the same editable/review-only distinction for future drawable lanes: performance lanes can be drawn, setup lanes need forms and confirmations.
• A future MIDI Import Wizard can show the same badges so the user learns, visually, that some MIDI data is musical gesture and some MIDI data is device instruction.

Design reminder: Performance expression is played; setup data is interpreted. The interface should never make those feel like the same kind of object.

2026-06-26 - MIDI Patch Review Strip

Task: Add a clear review-only strip to the MIDI Patch setup panel so Bank Select and Program Change rows cannot be mistaken for a live recall button.

Existing connections:

• The SysEx Vault and MIDI Hardware panels already use no-autosend language for external-device safety.
• The MIDI Expression editor now marks setup data as review-only, so MIDI Patch needs to be the place where the user sees why that data is protected.
• Patch setup rows are useful memory and import data, but they should not mutate SoundFont presets, internal synth patches, or hardware until SpaceAge has a deliberate mapping/recall workflow.

Creative extension ideas:

• Turn the review strip into a later Map These Rows... action that opens a guided wizard instead of leaving the data as passive text.
• Let the final Import Wizard use the same strip when a file contains program/bank messages, so the user learns the policy before import commit.
• Add a recall receipt later: "mapped to SoundFont preset", "attached to hardware profile", or "ignored for this project."

Design reminder: A visible safety boundary is better than a hidden promise. The musician should know when SpaceAge is only reading versus actually sending or changing something.

2026-06-26 - RPN/NRPN Setup Review In MIDI Patch

Task: Surface RPN, NRPN, Data Entry, and channel-mode setup controller rows in the MIDI Patch panel alongside Bank Select and Program Change review.

Existing connections:

• The backend already understood these setup controller messages and summarized them for import review, but the first-pass Patch panel only exposed Bank/Program rows.
• Since MIDI Expression now marks setup rows as review-only, MIDI Patch needs to become the obvious place where those rows can be inspected.
• This improves MIDI transparency without pretending SpaceAge has finished the deeper RPN/NRPN editor or hardware recall mapper.

Creative extension ideas:

• Convert these text rows into structured cards later: parameter family, selected RPN/NRPN number, Data Entry value, target device, and mapping status.
• Add a future "Attach To Hardware Profile" action for setup controller rows, mirroring the SysEx attachment workflow.
• Use RPN/NRPN review as the seed for hardware-specific setup templates, especially for older synth modules and wind/guitar controllers.

Design reminder: If a MIDI file contains device instructions, SpaceAge should show the musician what those instructions say before offering to act on them.

2026-06-26 - MIDI Map Range Scaling

Task: Add first-pass response-range controls to the MIDI Maps panel for learned continuous controls.

Existing connections:

• MidiControlMapping already stores minimum and maximum target values, and runtime mapping already scales incoming controller, pitch-bend, channel-pressure, and poly-aftertouch values through that range.
• MIDI Maps already exposes enable, invert, and delete, so adding range narrowing/widening belongs in the same assignment browser instead of a separate hidden utility.
• The processor now owns the range scaling operation, keeping future UI surfaces such as a curve editor, hardware setup wizard, or target inspector tied to one backend behavior.

Creative extension ideas:

• Replace R- and R+ later with a small response editor showing min handle, max handle, polarity, curve, and live incoming value.
• Reuse the same range-scaling contract for hardware controller templates, letting SpaceAge ship sensible defaults for expression pedals, breath controllers, mod wheels, and MIDI guitar controls.
• Add "capture current low" and "capture current high" buttons later so users can physically move a control to define its useful range.

Design reminder: MIDI Learn should move from "it works" to "it feels calibrated." A controller that reaches the right musical range is more valuable than one that merely reaches the right parameter.

2026-06-26 - MIDI Learn Target Picker In MIDI Maps

Task: Give the MIDI Maps panel a first-pass target picker so a user can arm MIDI Learn from a clear target group and target choice instead of waiting for direct control-click workflows.

Existing connections:

• The processor already owns target discovery, arming, capture, persistence, runtime mapping, and diagnostics, so the new panel controls are only a musician-facing entry point into existing backend behavior.
• The MIDI Maps panel already summarizes learned mappings and learnable targets, making it the right home for a conservative first-pass pick target -> learn -> move controller workflow.
• Group filtering reuses the same target descriptors that later can power a searchable controller-assignment editor, hardware templates, and per-synth modulation pages.

Creative extension ideas:

• Replace the simple target dropdown later with a searchable target browser that groups synth engines, effects, mixer lanes, transport, and project controls.
• Add "click a control to choose target" as a second workflow that feeds the same targetId into this arming path, avoiding duplicate MIDI Learn systems.
• A future calibration page can appear immediately after capture: show incoming value, min/max endpoints, curve, inversion, smoothing, and a friendly test meter.
• Auto-refresh after capture is a tiny version of that future calibration flow: the user should see SpaceAge respond the moment the hardware gesture is accepted.

Design reminder: MIDI Learn should feel like teaching SpaceAge a gesture. The protocol detail can stay underneath, but the user must always know what target is listening.

2026-06-26 - MIDI Learn Target Search

Task: Add text search to the MIDI Maps learn strip so users can find learnable targets by name, group, id, or parameter.

Existing connections:

• The target registry already has stable target ids, parameter ids, display names, groups, and units, so search can stay entirely inside the existing descriptor model.
• Search complements the group filter: group narrows by musical area, search narrows by user intent.
• This is a stepping stone toward the future full MIDI Learn browser without inventing another mapping system.

Creative extension ideas:

• Later, search results can show badges for target kind: continuous, toggle, stepped, bipolar, or dangerous/review-only.
• Hardware templates can pre-fill the same search query when a user says "map this pedal to cutoff" or "map breath to expression."
• A direct control-click workflow can reuse this search field as a target confirmation step: clicked target appears in the picker, search still works as fallback.

Design reminder: Search is recognition rather than recall. The musician should not need to memorize internal parameter names to map hardware.

2026-06-26 - MIDI Import Commit Policy Helpers

Task: Move selected-pattern and inspect-only MIDI import commit-request construction into the MIDI policy layer, then expose a truthful INSPECT ONLY button in the import preview.

Existing connections:

• The import backend already has a real commit boundary, import plans, action previews, receipts, and an inspect-only mode.
• The editor was manually constructing the selected-pattern request, which risked drifting away from backend policy as the full wizard grows.
• INSPECT ONLY is useful immediately because it exercises the same review/receipt path without mutating notes, lanes, patterns, or SysEx vault state.

Creative extension ideas:

• When the full wizard arrives, each page can produce a commit request through backend helper functions rather than constructing protocol policy in UI code.
• The inspect-only path can become a "Save Report" or "Import Risk Report" feature for collaborators and school settings.
• Future lane-splitting can stay disabled until a backend commit helper exists for it, keeping the UI honest by construction.

Design reminder: The wizard should never promise a mutation that the backend cannot safely perform. Honest buttons build trust.

2026-06-26 - MIDI Map Exact Range Endpoints

Task: Add exact low/high endpoint editing to MIDI Maps so learned controls can be calibrated numerically, not only narrowed or widened by repeated button presses.

Existing connections:

• MidiControlMapping already stores minimum and maximum mapped target values, and runtime performance already uses those values when applying incoming MIDI.
• The MIDI Maps panel already exposes enable, invert, target search, target picking, and range nudging, so exact endpoints belong there instead of hiding in a future inspector.
• The processor now has one setMidiControlMappingRange() path that validates continuous targets and clamps values to the target's actual parameter range.

Creative extension ideas:

• Convert the low/high editors into a richer response editor later: low handle, high handle, curve, smoothing, polarity, and live incoming-value meter.
• Add "capture low" and "capture high" buttons so a user can move a physical control to define endpoints by gesture.
• Reuse the same endpoint contract for hardware controller templates, MIDI guitar expression profiles, wind-controller breath mapping, and school-friendly setup wizards.

Design reminder: Calibration is part of musical trust. A controller assignment is not done until it reaches the right musical range without making the user fight it.

2026-06-26 - MIDI Export Preview Next Slice

Task: Record the next recommended MIDI customer-facing slice from the read-only subagent audit: build a styled MIDI Export Preview panel.

Existing connections:

• Export readiness summaries and job plans already exist for selected pattern, selected Arrangement clip, whole Arrangement, and drums-only Arrangement exports.
• Current export UI blocks empty exports and shows compact warning dialogs, but it does not yet give the musician a pleasant SpaceAge-style "what will leave the app" preview.
• The import side now has a styled preview panel, so export should gain the same level of visible confidence.

Creative extension ideas:

• Show "tracks inside this MIDI file" clearly, avoiding any implication that lane rows are separate files until multi-file export exists.
• Use the preview panel as the future home for MIDI format choice, drums-only toggles, selected-lanes export, and collaborator-safe naming.
• Add export progress once large arrangement exports or multi-file exports become meaningful.

Design reminder: Export is a trust moment. Before SpaceAge writes a collaborator-facing file, the user should understand scope, timing, channels, expression, and warnings at a glance.

2026-06-26 - MIDI Export Preview Implementation

Task: Put the export readiness/job-plan data in front of the actual MIDI save dialog for selected pattern, selected Arrangement clip, full Arrangement, and drums-only Arrangement export.

Existing connections:

• The panel reuses MidiExportReadinessSummary and MidiExportJobPlan, so the UI does not re-count lanes, clips, channels, patterns, notes, or warnings by hand.
• The existing file chooser and export writers stay unchanged; the new panel is a confidence layer before mutation, not a second export engine.
• Empty exports still surface clearly, but now in the same styled preview surface instead of a plain system alert.

Creative extension ideas:

• Add selected-lanes export and multi-file lane/stem MIDI export by extending the job plan rather than building a parallel UI.
• Save a small export receipt beside .mid files for collaborators: SpaceAge version, BPM, PPQ, channels, lane names, and warning summary.
• Reuse the same preview style for audio render, Quasar capture, and future hardware SysEx send confirmation so every "write something outside the project" action feels predictable.

Design reminder: A preview is more than a warning. It is a promise that SpaceAge can explain what it is about to do.

2026-06-26 - Confirmed Hardware Recall Send

Task: Turn the MIDI Hardware Passports panel from a read-only preview into a guarded send workflow for hardware program recall and optional attached SysEx recall.

Existing connections:

• Hardware profiles already store output device, MIDI channel, Bank MSB, Bank LSB, Program Change, and linked SysEx snapshot ids.
• buildHardwareRecallPlanSummary() already produces the user-facing rows needed for a confirmation dialog, including message descriptions, byte counts, delays, SysEx flags, and warnings.
• queueConfirmedHardwareRecall() already gates real sends behind validation and confirmation, uses the hardware recall queue rather than the live Arrangement queue, and writes a bounded recall log.

Creative extension ideas:

• The same confirmation pattern can later become a full Hardware Setup Assistant: choose output, test note, preview recall, send program, send SysEx, verify response.
• The recall log can grow into a receipt/export report for collaborators who use external hardware.
• A future progress meter can advance through the same plan items, using byte counts and delay metadata to show that a large SysEx dump is still intentionally sending rather than frozen.

Design reminder: A hardware passport is identity, not consent. SpaceAge may remember an external synth, but it should only touch that synth when the user makes a deliberate, confirmed recall request.

2026-06-26 - SysEx Vault Rename And Review Polish

Task: Give the SysEx Vault first-pass editing controls for snapshot name, notes, and exact send delay while preserving the rule that attach, detach, and edit are bookkeeping only.

Existing connections:

• SysExSnapshot already stores name, notes, raw bytes, send delay, archive intent, and confirmation requirement, so the UI can edit real project data instead of inventing a parallel librarian object.
• getSysExSnapshotSummaries() already produces descriptor, warning, byte-count, and profile-attachment rows, so the Vault can remain a review surface without parsing raw bytes in editor code.
• upsertSysExSnapshot() already enforces conservative delay recommendations for valid SysEx, keeping the exact-delay editor safely inside backend policy.

Creative extension ideas:

• The same "name, notes, delay, preview, confirm" pattern can become the design language for hardware preset librarians, Quasar package exports, and future external-device setup assistants.
• Notes on SysEx snapshots can later become searchable metadata: "factory lead bank," "QY-70 strings setup," "dangerous global dump," or "safe patch only."
• Exact delay editing is the first step toward a visible progress meter for long SysEx transfers, where SpaceAge can reassure the user that the app is intentionally pacing old hardware.

Design reminder: SysEx is powerful enough to be scary. The Vault should make it legible and calm before SpaceAge ever offers to send it.

2026-06-26 - First Safe MIDI Channel Split To Arrangement Lanes

Task: Turn the MIDI Import Wizard's channel-to-lane preview into a real first-pass commit path for safe melodic/instrument channels. Historical note: drum-channel splitting was guarded at this point, but later gained the long-form drum lane path.

Existing connections:

• MidiImportLaneCandidate already tells us which channels look like melodic lanes, expressive instrument lanes, drums, controller-only data, or setup data, so the importer can avoid guessing inside editor code.
• Arrangement lanes already have lane MIDI channels, input-channel filters, instrument backing slots, pattern payloads, and clips. The split importer now creates those pieces together instead of using a top inspector or reviving the deprecated pad-proxy workflow.
• Pattern payloads already support long melodic lengths through maxPatternSteps, while Drum Composer payloads still live inside the old 64-step pad grid. Long GM drum imports now use long-form drum lanes; conversion into editable classic Step Banks remains a separate future choice.
• SysEx Vault import already stores confirmation-required snapshots, so lane splitting can preserve external setup data without ever sending hardware messages during import.

Creative extension ideas:

• The next wizard page can expose lane names, lane type, destination instrument, input channel, play/export channel, and hardware profile for each channel before commit.
• Drum-channel imports can later choose between "classic Drum Composer grid," "long-form drum lane," or "convert to MIDI note lane" depending on the source material and user intent.
• Imported channel lanes could automatically get ghost-note suggestions enabled for adjacent melodic lanes, making imported MIDI files immediately useful as composition reference material.
• The import receipt can become a small "import history" log that lets the user jump to newly created lanes, open SysEx snapshots, or review ignored transport/sync data.

Design reminder: A MIDI file is often somebody else's whole studio in miniature. SpaceAge should open the door politely, sort the luggage, and never silently plug anything into hardware.

2026-06-26 - Honest Split Import Button Gating

Task: Tighten the MIDI Import Wizard so the Split Channels To Lanes button appears only when a safe channel can actually be imported today. Historical note: this originally meant melodic/expressive channels only; GM drum rows are now safe via long-form drum lanes.

Existing connections:

• The preview can still show controller and hardware setup candidates because those are useful review facts.
• The commit path imports melodic/instrument channels and GM drum channels; setup-only and hardware-review rows remain guarded.
• The review panel now keeps the import plan as well as the preview, so UI availability is based on real lane candidate types instead of inferred preview text.

Creative extension ideas:

• When the full wizard arrives, guarded rows can become disabled but explanatory choices: "review only," "convert to hardware setup," or "store without applying."
• Import receipts could include a "why skipped?" row per guarded channel so users feel protected rather than blocked.
• The same honest-button policy should apply to future hardware sends, sample renders, and Quasar builds: if SpaceAge cannot complete the action faithfully, the button should either explain the guard or not present itself as ready.

Design reminder: A disabled or hidden button is not a failure if it prevents a lie. The interface should only invite actions the backend can keep.

2026-06-26 - MIDI Import Receipt Callout

Task: After a split-channel MIDI import, show a styled receipt with the summary, action lines, and warnings rather than relying only on a status-line flash.

Existing connections:

• MidiImportApplyResult already contains summary text, action lines, and warnings, so the UI can display backend truth without recomputing it.
• The Export Preview and Import Preview already established a SpaceAge-styled confidence layer for risky file operations.
• The receipt follows the same plain-language model as SysEx Vault review and hardware recall confirmations.

Creative extension ideas:

• Turn receipts into an import history list where users can jump to newly created lanes, reopen stored SysEx snapshots, or inspect skipped channels.
• Save optional collaborator receipts beside exported MIDI/audio files to make SpaceAge's file exchange feel professional.
• Add "Open created lanes" or "Review skipped channels" buttons once the full import wizard has editable rows.

Design reminder: After an import, the first question is "what just happened?" SpaceAge should answer that before the user has to go hunting.

2026-06-26 - MIDI Import Channel Include Rows

Task: Give the MIDI Import Wizard Preview a first-pass channel-options area where safe melodic/instrument channels can be checked or unchecked before the split-to-lanes commit. Historical note: GM drum rows later joined this same checkable row system through long-form drum lanes.

Existing connections:

• MidiImportLaneCandidate already separates instrument, expressive instrument, drum, setup, and review-only candidates, so the UI can show honest choices without duplicating import-policy logic.
• The backend split importer already accepts sourceChannels, so the preview can narrow the commit request without adding another mutation path.
• The Import Receipt already reports what happened after commit, so checked/unchecked choices can be verified immediately after import.

Creative extension ideas:

• Expand each channel row into a full mini-routing card later: lane name, destination instrument, input channel, play/export channel, ghost-note defaults, and hardware profile.
• Let long-form drum rows eventually offer an explicit conversion choice: keep as long-form drum lane, convert short/simple passages into classic grid, or reinterpret as MIDI note lane.
• Reuse this checkbox-plus-guardrail pattern for Render stems, Quasar capture layers, SysEx recall rows, and future preset-batch import.

Design reminder: A useful wizard does not hide complexity; it organizes the safe parts into simple choices and names the risky parts before they can surprise the musician.

2026-06-26 - MIDI Import Channel Destination Options

Task: Extend the MIDI import commit request with per-channel destination options: source channel, lane name, instrument slot, play/export channel, and input channel.

Existing connections:

• The first-pass Import Wizard rows already know which safe channels the user included, so those rows can submit explicit defaults instead of only a plain source-channel list.
• Arrangement lanes already separate input channel and play/export channel, so imported MIDI can preserve the source channel now and later let users deliberately remap it.
• The Instrument Bay direction needs lane-owned instrument choices. This commit-option hook gives the future destination picker a backend target without reviving top-inspector or pad-proxy confusion.

Creative extension ideas:

• Add a "quick orchestrate" row where an imported channel can immediately choose Redshift, SoundFont, Quasar, or hardware before import.
• Let imported lanes inherit ghost-note visibility defaults based on the other checked channels in the same file.
• Offer a "keep original channels" versus "renumber from selected lane stack" toggle for collaborators who want either faithful MIDI import or clean SpaceAge routing.

Design reminder: The import wizard should become the front door to Arrangement, not a dumping chute. Destination choices belong in the same moment where the user decides what the MIDI file is supposed to become.

2026-06-26 - MIDI Import Visible Destination Controls

Task: Add compact per-channel Instrument Slot and playback/export MIDI channel controls to the MIDI Import Wizard Preview for safe melodic/instrument rows.

Existing connections:

• The backend MidiImportChannelCommitOption already accepts instrument slot and play/export channel values, so the UI can now send explicit user choices instead of hard-coded defaults.
• Arrangement lanes already display their lane instrument and MIDI channel, so the import wizard should use the same conceptual language: imported channels become lane-owned instruments, not top-inspector or pad-proxy assignments.
• The include/exclude row pattern already protects the commit path; adding destination controls to the same row keeps import decisions in one visible place.

Creative extension ideas:

• Replace plain Instrument 01 labels with full Instrument Bay names once the bay browser exposes a compact label API for import rows.
• Add duplicate-destination warnings when two imported channels point to the same instrument slot, then offer "clone instrument" or "share instrument intentionally" choices.
• Add an input-channel filter selector beside the output-channel selector when hardware workflows need source-channel remapping separate from playback/export mapping.

Design reminder: The moment of import is also the moment of orchestration. If SpaceAge asks where a channel should go before committing it, the result feels deliberate instead of mysterious.

2026-06-26 - TempoCalc Utility Page

Task: Add a SpaceAge utility page named TempoCalc for BPM-to-millisecond timing, clipboard workflows, and one-shot WAV/MIDI note exports.

What connects creatively: TempoCalc is not just a calculator. It is a bridge between composition timing, effects sound design, and the future Motion Clips idea. Delay times, LFO rates, gate pulses, envelope lengths, exported clicks, and MIDI test notes all depend on the same underlying tempo math. Centralizing that math gives us one source of truth that can later feed EchoRay, Halostar modulation sync, synth vibrato sync, Flux Nodes timing, and Motion Clips.

Architecture choice: The implementation uses a self-contained calculator/export module (TempoCalc.*) plus a first-class top-level page. That keeps the utility usable without making the main editor more tangled. It also keeps settings separate from project files so a user can keep personal TempoCalc export defaults across projects.

Boundary call: The prompt mentioned AU and CLAP formats, but SpaceAge's current CMake target is configured for VST3 and Standalone. I did not silently expand product formats during this pass. If we later want TempoCalc as a separate utility plugin, that should be a deliberate packaging target rather than a side effect of the main microDAW build.

Future extensions: Drag-to-DAW export can build on the current WAV/MIDI file writers once we decide how to present temporary generated files. A later tempo-aware “copy to device parameter” workflow could let a user click a TempoCalc value and push it directly into EchoRay, a synth LFO, or a Motion Clip rate.

2026-06-26 - MIDI Protocol Verification Baseline

Task: Continue the MIDI protocol pass after TempoCalc and reconcile the backend self-test with the newer MIDI safety behavior.

What connects creatively: The MIDI system is becoming the nervous system for SpaceAge: live performance, hardware control, imports, exports, expression lanes, SoundFonts, future VST hosting, and eventual MIDI guitar/wind-controller workflows all depend on the same protocol truth. A green protocol/readiness baseline means future musical features can lean on one tested spine instead of inventing local MIDI assumptions.

Architecture choice: The self-test now treats transport stop as a safety plan rather than a single message. MIDI Stop can be followed by channel-scoped panic/reset traffic when a hardware profile asks for panic-on-stop. Inspection also counts same-channel device setup data as channel activity, because musicians need the app to notice patch/setup traffic before it offers import, mapping, or hardware recall choices.

Boundary call: Backend coverage is not the same as finished customer workflow. The tests now prove that SpaceAge can classify, preserve, inspect, route, and plan around the MIDI data, while the UI still needs final polish for import mapping, expression editing, hardware passports, SysEx progress, and friendly controller setup.

Future extensions: The same verified readiness and protocol coverage reports can drive a MIDI Dashboard, Hardware Setup Assistant, Import Wizard, and MIDI Learn browser. That keeps advanced MIDI approachable: one source of truth, many calm doors into it.

2026-06-26 - MIDI Device Repair Recommendations

Task: Continue the MIDI protocol pass by converting raw input/output/device readiness facts into reusable, customer-facing repair recommendations.

What connects creatively: This is the beginning of a hardware setup assistant without committing to a full wizard yet. SpaceAge already knows which lanes are armed, which devices are visible, which hardware routes are blocked, and whether runtime output devices are open. Turning those facts into "next step" cards lets Settings, startup preflight, export review, and future hardware onboarding share the same calm advice instead of each inventing its own warning prose.

Architecture choice: The recommendation builder lives in the MIDI layer and receives existing readiness reports. It does not inspect editor components or mutate project state. That keeps the advice testable and lets the UI stay thin: panels can draw the recommendation, while the MIDI backend owns the meaning.

Boundary call: The first pass stops at advice. It does not automatically reassign missing devices, open replacement outputs, or change lane routing. That restraint matters because hardware MIDI is full of named devices, old synths, SysEx risks, and user-specific studio wiring. The app should recommend clearly before it acts.

Future extensions: Add action buttons beside each recommendation: "Choose replacement input," "Assign output," "Create hardware profile," "Open SysEx Vault," or "Run test note." The same model could power a first-launch "MIDI setup scan" for controllers, wind controllers, MIDI guitar, and external synth racks.

2026-06-26 - MIDI Health Next Steps

Task: Promote MIDI repair recommendations into the MIDI Health summary so the read-only dashboard can answer "what should I do next?" without requiring the user to open separate input/output panels.

What connects creatively: Health is the natural triage surface. If SpaceAge becomes a serious hardware-friendly microDAW, users will sometimes arrive tired, with cables swapped, controllers asleep, or old synths not responding. A health page that says "Reconnect this output" or "Arm a lane" is much more musical than a health page that only says "warning count: 4."

Architecture choice: The health summary now carries deviceRepairRecommendations as serialized data. That keeps exportable diagnostics, UI callouts, and future support bundles aligned with the exact advice shown on screen.

Future extensions: The same recommendation objects can become clickable repairs later: open lane MIDI settings, jump to the missing output lane, choose a replacement device, send a test note, or launch a guided MIDI hardware assistant.

2026-06-26 - MIDI Repair Action Metadata

Task: Add structured action metadata to MIDI repair recommendations so the UI can eventually turn a "next step" line into a precise guided repair.

What connects creatively: This is the quiet bridge between advice and action. A warning that says "Assign a MIDI output device" is helpful, but a warning that also knows "open the lane output panel for lane 6" can become a one-click repair without hard-coding that logic into every panel. The same action metadata can later serve Settings, first-launch MIDI setup, hardware profile editing, import review, and support diagnostics.

Architecture choice: MidiDeviceRepairRecommendation now carries an actionKind, optional target id, lane index, and compact actionSummary(). The MIDI layer still does not mutate project state or open UI. It only says what kind of surface should handle the repair and how to label the target. That keeps the backend testable and lets the editor decide how to present the button.

Future extensions: Add visible buttons beside recommendations: Fix Input, Choose Output, Open Hardware Profile, Refresh Devices, or Review Health. If we build a hardware setup assistant, it can consume the same recommendation list as a step queue.

2026-06-26 - Hardware Recall Queue Summary

Task: Add a compact hardware recall/send-log summary so confirmed program/SysEx recall attempts explain what was queued, what failed, how much SysEx data was involved, and which hardware target was last touched.

What connects creatively: This is the bridge between the SysEx Vault, Hardware Passports, and a future hardware setup assistant. Old synths are powerful but fussy; SpaceAge should make external gear feel less like superstition. A visible queue summary gives the user confidence that the app attempted the right messages, used the intended output, respected delays, and did not silently autosend anything.

Architecture choice: The processor now aggregates the existing hardware recall log into a HardwareRecallLogSummary instead of making the editor infer meaning from rows. The UI stays a reader, while the MIDI/backend layer owns counts, failure warnings, SysEx byte totals, planned delays, and latest-target metadata.

Boundary call: This is not a full progress meter for long SysEx dumps yet. It is honest session-level queue visibility. True live send progress will need deeper output-router instrumentation so the UI can report pending/active/completed bytes rather than only queued/failed attempts.

Future extensions: Add per-message retry, reveal matching hardware profile, open missing-output repair, and a full librarian send monitor with progress bars, cancel, throttling presets, checksum helpers, and device-id editing.

2026-06-26 - MIDI Health Guided Repair Buttons

Task: Turn the MIDI Health "Next Steps" rows from passive text into guided repair buttons.

What connects creatively: MIDI Health is becoming the calm cockpit for external gear. If it can see a broken route and immediately open the exact lane MIDI panel or setup surface, the user does not need to memorize where every MIDI setting lives. This is especially important for MIDI guitarists, wind-controller players, and hardware synth users, because their setup problems are often routing problems disguised as silence.

Architecture choice: The MIDI backend still only emits recommendation metadata (actionKind, target id, lane index). The editor decides how to route the action: lane-specific recommendations open the lane MIDI panel, setup recommendations open the relevant MIDI Input, MIDI Output, or MIDI Hardware surface, and refresh recommendations rescan preflight status.

Boundary call: The buttons do not silently change routing, pick replacement devices, or send hardware bytes. They navigate the user to the right repair surface. That keeps the workflow helpful without violating the hardware-safety rule.

Future extensions: Add the same repair-button pattern to the focused MIDI Input and MIDI Out panels, then build a first-launch Hardware Setup Assistant that consumes the recommendation list as an ordered checklist.

2026-06-27 - MIDI Sync Outbound Intent Preview

Task: Continue the MIDI implementation push by making the MIDI Sync surface explain outbound hardware sync intent, not just observed incoming sync/status counts.

What connects creatively: MIDI Sync is where SpaceAge starts feeling like it can lead a room full of hardware without making the user feel like they are flying blind. Incoming counts tell us what external gear is saying to SpaceAge; outbound intent tells us what SpaceAge plans to say back. Putting both in one panel creates a useful "sync cockpit" before we build the full sync assistant.

Architecture choice: The UI reads existing hardware profile and transport-plan summaries instead of inventing new send logic. That keeps this as a truthful preflight/diagnostic surface: it previews Clock/transport intent for clock-enabled hardware profiles, shows the first planned outbound messages, and summarizes the current sync policy as send-clock/send-transport/receive-clock/chase counts, while the processor and MIDI backend remain the authority on what can actually be queued.

Boundary call: This is not incoming clock chase, not MMC/MTC runtime, and not an editable sync setup page yet. It is the bridge between diagnostics and safe controls: users can see which profiles are configured for MIDI Clock or transport before playback behavior surprises them.

Future extensions: Add direct buttons for Open Hardware Profile, Test Clock, Send Stop, and Disable Clock Send; add chase-status indicators once incoming clock following exists; and reuse the same transport-plan rows in a dedicated hardware setup assistant.

2026-06-27 - MIDI Sync Policy Summary Model

Task: Move the MIDI Sync surface away from hand-counting hardware profile fields in the editor and give the processor/backend a reusable MidiSyncPolicySummary.

What connects creatively: Sync is not just a checkbox. It touches hardware profiles, transport, panic safety, external clock, incoming chase, song-position behavior, and eventually plugin-host behavior. A single policy summary lets Settings, Health, support diagnostics, and a future Sync setup assistant all tell the same truth about who sends clock, who sends transport, who listens, and who needs attention.

Architecture choice: MidiSyncPolicySummary and per-profile policy rows live in the MIDI model layer and are serialized through MIDI Health. The editor consumes that summary instead of inferring policy from raw hardware profile flags. This keeps the UI thin and gives us one testable location for sync meaning.

Boundary call: This is still a policy/diagnostic model, not incoming clock chase. It tells the user what SpaceAge is configured to do and which hardware profiles need review. The actual editable Sync page and chase engine still need their own guarded implementation.

Future extensions: Use the policy rows to power buttons like Disable Clock Send, Test Start/Stop, Open Profile, and Follow External Clock; include sync policy in support/export diagnostics; eventually expose a visual sync topology view for hardware rigs.

2026-06-27 - MIDI Sync Profile Role Rows

Task: Continue the Sync work by making the MIDI Sync panel identify which hardware profiles own each sync role, not merely how many profiles are configured.

What connects creatively: Musicians do not think in counts. They think "the Juno is following clock" or "the drum machine is receiving start/stop." Listing Passport roles turns MIDI Sync from a meter into a mental map of the studio. That will matter later when SpaceAge becomes a hand-holding hardware companion.

Architecture choice: The panel renders rows directly from MidiSyncPolicySummary::profiles, preserving the backend as the authority. Each row can show profile name, send/receive/chase roles, clock mode, input/output ids, and first warning. This is intentionally read-only for now so we do not mix diagnostics with hardware-affecting mutation.

Future extensions: Add safe buttons on each row: Open Profile, Test Stop, Test Clock, Disable Send, and later Follow This Clock. These can route to the existing hardware profile editor and transport-plan code instead of inventing new MIDI send paths.

2026-06-27 - MIDI Health Sync In vs Sync Policy

Task: Add a MIDI Health distinction between observed incoming sync/status traffic and configured sync policy.

What connects creatively: Sync bugs are maddening when the UI collapses observation and intent into one word. "Sync In" answers what the outside world has actually sent to SpaceAge. "Sync Policy" answers what SpaceAge is configured to send or chase. That split gives hardware users a quick sanity check before they blame cables, drivers, or the app.

Architecture choice: MIDI Health now reads health.syncRuntime.summary() and health.syncPolicy.summary() as separate rows. This reuses the model layer and keeps the Health panel as a preflight dashboard rather than a second sync editor.

Future extensions: Let the Health row open the focused MIDI Sync panel directly, then add guided repair actions when policy warnings exist: open profile, choose output/input, disable unsafe clock send, or test transport.

2026-06-27 - MIDI Sync Safe Setup Shortcuts

Task: Add safe navigation buttons to the MIDI Sync preflight panel without allowing the panel itself to send clock, transport, or SysEx.

What connects creatively: MIDI setup should feel like a guided cockpit, not a scavenger hunt. If the Sync panel can see that hardware profiles or MIDI output setup are the next likely repair surfaces, it should offer direct doors to those places. The useful distinction is that these are doors, not launch buttons: they help the user reach the right setup area without mutating routes or firing bytes at hardware.

Architecture choice: The Sync panel now receives callbacks from the Settings panel for OPEN HARDWARE PROFILES and OPEN MIDI OUT PREFLIGHT. The local callout dismisses itself, then triggers the existing focused setup surfaces. This keeps navigation in the editor layer and leaves the MIDI backend responsible only for policy, health, and transport-plan truth.

Boundary call: These buttons do not send MIDI Clock, Start, Stop, Song Position Pointer, program changes, or SysEx. They are intentionally safe setup shortcuts. Hardware-affecting actions must remain behind explicit profile choices and confirmations.

Future extensions: Reuse this safe-navigation pattern in a future Hardware Setup Assistant: each repair recommendation can open the right surface first, then offer explicit TEST NOTE, TEST CLOCK, or SEND RECALL actions only after the user has reviewed the target.

2026-06-27 - Lane Icon Means Edit This Lane's Native Workspace

Task: Fix the Arranger lane edit icon so drum lanes open the Drum Composer instead of doing nothing.

What connects creatively: One icon can stay consistent if its meaning is "edit the thing that makes this lane musical," not "always open a synth." For melodic lanes, that means the active instrument editor. For drum lanes, the native editing workspace is the Drum Composer. This keeps the lane badge teachable while respecting that drums and pitched instruments use different creation paradigms.

Architecture choice: The drum-lane path now selects the most relevant clip on that lane when possible, sets the selected pattern and step bank, flips Sequencers back to Drum Composer mode, and opens the Sequencers page. It avoids forcing drum lanes through the Instrument Bay/pad-synth editor path.

Future extensions: Use this same native-workspace rule for future lane classes: audio clip lanes should open the waveform/sample editor, automation lanes should open Motion Clips, chord lanes should open Chord Engine, and hardware lanes should open their hardware/profile editor.

2026-06-27 - TempoCalc Immediate Manual BPM Commit

Task: Make manually typed TempoCalc BPM values update calculations immediately instead of requiring the user to click away.

What connects creatively: TempoCalc is a utility page, so it needs to feel like a calculator, not a form. When a user enters a number and presses Enter, the whole timing table should believe them instantly. This also supports the larger SpaceAge principle that numeric music tools should be quick enough to use in the middle of composing.

Architecture choice: The manual BPM editor now updates the readout/table as valid text is typed, and Enter normalizes, saves, and releases focus. The rest of TempoCalc still uses the same TempoCalcSettings and TempoCalculator model, so exports and table copy remain aligned with the visible value.

Future extensions: Apply the same immediate-commit pattern to other single-purpose numeric utility fields where a user expects calculator behavior, while keeping more destructive music-editing fields behind explicit commit or undo checkpoints.

2026-06-27 - MIDI Expression Truth Is Pattern Truth

Task: Continue the MIDI implementation push by making MIDI Health report when expression data lives on patterns that are reused by multiple arrangement clips or multiple lanes.

What connects creatively: Controller motion is music, but it is also invisible enough to become a trap. If a pitch-bend curve, mod-wheel swell, sustain pedal, or CC expression lane belongs to a pattern, then every linked use of that pattern hears it. Surfacing that fact in MIDI Health gives SpaceAge a calm way to protect the user before they wonder why a controller edit changed another part of the song.

Architecture choice: MidiProjectHealthSummary now owns a reusable MidiExpressionProjectSummary. The processor computes expression-bearing patterns, event counts, expression lane counts, arrangement clip references, shared-pattern references, cross-lane references, and dense expression lanes. The editor merely displays the summary row and warnings, keeping the model layer as the source of truth for support diagnostics, export checks, and future MIDI assistants.

Boundary call: This does not yet make MIDI expression clip-local. It is the necessary guardrail before that deeper storage change: the app now states that expression is currently pattern-scoped and recommends making a Variant before lane-specific controller moves.

Future extensions: Move expression storage from pattern-only payloads toward clip/lane-local envelopes, add a migration path for existing pattern expression, let the Expression editor offer Make Clip-Local, and reuse this risk summary in the MIDI Import Wizard when imported CC/pitch/pressure data lands on linked material.

2026-06-27 - MIDI Patch Setup Is Recall Data

Task: Continue the MIDI implementation push by making MIDI Health report Bank Select and Program Change setup rows separately from expression data.

What connects creatively: Hardware users often think of patch recall as part of the sound, not as invisible MIDI bookkeeping. If a pattern carries Bank Select or Program Change rows, then reusing that pattern can also reuse its sound-selection intent. Surfacing this in MIDI Health makes SpaceAge safer for hardware rigs, General MIDI imports, and future lane instrument reassignment.

Architecture choice: MidiProjectHealthSummary now owns a MidiPatchProjectSummary beside the expression summary. The processor counts setup rows, complete bank/program recalls, bank-only rows, arrangement clip references, shared pattern reuse, and cross-lane reuse. This keeps patch setup separate from editable CC/pitch/pressure expression, while still allowing one Health popup to tell the whole MIDI truth.

Boundary call: This does not yet convert patch setup into a lane-local instrument assignment, nor does it send Bank/Program messages. It is a diagnostic and planning layer that warns when patch recall is incomplete or pattern-scoped in a way that could affect multiple musical locations.

Future extensions: Add an explicit Convert Patch Setup To Lane Instrument workflow, a Make Patch Setup Clip-Local command for imported MIDI, a guarded hardware send preview, and a MIDI Import Wizard choice for whether Bank/Program data should become lane instruments, hardware recall metadata, or preserved review-only setup rows.

2026-06-27 - MIDI Import Approval Must Survive Paging

Task: Let the MIDI Import Wizard review more than four channel rows without making the final split import depend only on the currently visible page.

What connects creatively: A wizard is a trust contract. If SpaceAge says a MIDI file has many useful channels, the user needs a way to inspect those channels without feeling that hidden rows are either being ignored or smuggled into the project. Paging keeps the panel compact while still honoring every checked importable channel.

Architecture choice: The import preview still builds channel rows from MidiImportLaneCandidate data, but the row controls persist behind the paged view. Safe importable rows are checked by default, guarded rows remain review-only, and the split commit request is built from all checked channel controls, not merely the four rows currently painted on screen.

Future extensions: Replace the compact pager with a richer full Import Wizard table when space allows, add saved import recipes such as GM Song, Melody Only, and Hardware Dump Review, and connect setup rows to future hardware-profile creation without ever sending Bank/Program/SysEx data during import.

2026-06-27 - MIDI Pressure Becomes A Synth Gesture

Task: Expose channel pressure and poly aftertouch as selectable internal modulation sources for synth pitch/filter routes.

What connects creatively: Pressure is the "after the note begins" part of a performance. We already preserve it for MIDI truth, but letting it open a filter, bend a pitch amount, or animate a patch gives MIDI wind controllers, expressive keyboards, and future MPE-ish workflows an immediate musical payoff. It also makes the MOD / CHOKE page feel more like a small modular matrix instead of a legacy pad utility.

Architecture choice: Mod-route source IDs remain backward-compatible: Off, Velocity, Random, and LFO keep their original numeric values, while Channel Pressure and Poly Aftertouch are appended. Runtime pitch and filter modulation now share one evaluator that reads the voice's MIDI channel and note, and saved route data is clamped on write so corrupt/out-of-range values cannot leak into rendering.

Future extensions: Add visible pressure lanes in the Piano Roll, per-lane default modulation templates for MIDI guitar/wind controller profiles, smoothing/curve choices for pressure response, and a compact "Pressure Active" meter on instrument pages while notes are being played.

2026-06-27 - MIDI Import Choices Must Be Visible Consent

Task: Continue the MIDI implementation push by exposing selected-pattern and split-channel import choices for expression, metadata, device setup, SysEx storage, and transport sync.

What connects creatively: MIDI files can carry a whole history of performance gestures, hardware setup, song metadata, and device dumps. A good microDAW should not flatten that into one scary "Import" button. The Import Wizard now behaves more like a flight checklist: SpaceAge tells the user which kinds of payload are present and lets the import request reflect visible choices before mutation.

Architecture choice: The panel still builds a MidiImportCommitRequest, but selected-pattern import and channel splitting now both read the same visible safety toggles before calling applyMidiFileImport(). This preserves the backend request/receipt model while making consent explicit in the UI.

Backend follow-through: The selected-pattern import path now honors the same request booleans as the split-channel path. Turning off editable expression prevents CC/pitch/pressure/sustain-style payloads from entering the pattern, turning off setup review prevents Bank/Program/RPN/NRPN-style setup rows from entering, and turning off SysEx storage prevents quarantine snapshots from being created. This matters because visible choices that do not reach the backend are worse than no choices at all.

Future extensions: Add a paged/scrollable full channel table, save favorite import recipes such as GM Song, Melody Only, and Hardware Dump Review, and connect setup rows to future hardware-profile creation without ever sending Bank/Program/SysEx data during import.

2026-06-27 - MIDI Import Recipes And Receipts

Task: Continue hardening the MIDI Import Wizard by adding quick import recipes, styled receipts for every commit path, and live destination labels that follow the user's current channel choices.

What connects creatively: A MIDI import wizard is part translator and part trust ritual. Recipe buttons let a user quickly say "bring everything safe," "notes only," "melodic material," or "drums" without thinking like a protocol engineer. Receipts then close the loop by showing exactly what SpaceAge did or refused to do. This matches the broader SpaceAge design language: keep the musical intent visible, keep risky device/setup data guarded, and let the user move quickly without feeling ambushed.

Architecture choice: The recipe buttons only shape the MidiImportCommitRequest; they do not mutate project data by themselves. Selected-pattern import, split-channel import, and inspect-only review all end in the same MidiImportApplyResult receipt surface. Destination text is derived from the current visible controls, so changing an instrument slot or MIDI output channel updates the row's promise before commit.

Future extensions: Save named import recipes, make GM Song, Hardware Dump Review, and Melody Only first-class presets, and reuse the receipt panel as an audit trail item in a future project history or diagnostics page.

2026-06-27 - MIDI Patch Rows Become Hardware Recall Recipes

Task: Turn reviewed Bank Select / Program Change rows in MIDI PATCH into explicit hardware profile recall recipes.

What connects creatively: A MIDI file can contain the memory of an external synth's sound choice. SpaceAge should preserve that memory without behaving like a prankster pressing buttons on the user's hardware. Saving patch rows as hardware profiles lets a future hardware workflow say, "this song probably wanted this device on this channel with this bank/program," while still requiring the user to assign outputs and confirm any actual send.

Architecture choice: The processor now owns createHardwareMidiProfileFromPatchSummary(), which converts a reviewed MidiPatchEventSummary into a HardwareMidiProfile. The MIDI PATCH panel exposes a batch save button for usable Program Change rows. The button creates profile metadata only; it does not send MIDI, attach lanes, load internal presets, or reinterpret SoundFont instruments.

Future extensions: Add row-level mapping destinations for Hardware Profile, SoundFont Preset, and Internal Instrument; add profile merge/update instead of always creating new recipes; and let the Import Wizard offer a "save patch setup as hardware recall recipes" checkbox in its receipt phase.

2026-06-27 - MIDI Sync Monitor As A Hardware Troubleshooting Surface

Task: Give the MIDI SYNC panel explicit refresh and reset controls for observed incoming sync/status messages.

What connects creatively: Hardware troubleshooting often feels like shouting into the void: is the cable working, did the external device send Start, did SpaceAge hear clock pulses, did SPP arrive? A resettable monitor turns that into a clean ritual: clear the counters, press play on the external box, and see exactly what SpaceAge observed.

Architecture choice: Incoming sync observation remains inside the processor's MIDI ingestion path. The new public mutation is only resetMidiSyncRuntimeMonitor(), which clears observed counters and last-message labels. The UI refresh button re-reads the existing project-health sync runtime summary instead of maintaining separate editor truth.

Future extensions: Add explicit chase controls for Start/Continue/Stop/SPP after the monitor workflow is trustworthy, add clock-rate stability diagnostics, and surface "last observed device/input" when JUCE input callbacks expose enough source identity for reliable reporting.

2026-06-27 - MIDI Chase Must Be A Readiness State, Not A Vibe

Task: Clarify MIDI Sync policy reporting so SpaceAge can distinguish a hardware profile that requests transport chase from one that is truly ready to chase incoming transport.

What connects creatively: Hardware synchronization is half feature and half confidence ritual. The same panel that counts incoming Start/Stop/SPP should also explain whether a connected device is merely being observed, has asked for chase, or is fully configured to become the transport authority. That creates the foundation for a future "external box drives SpaceAge" workflow without surprising the composer.

Architecture choice: MidiSyncPolicySummary now carries explicit readiness counts for receive-clock, chase-transport, and Song Position Pointer readiness. Per-profile rows report whether an input device exists, whether receive clock is ready, whether transport chase is ready, and whether SPP chase is ready. The editor consumes these model facts instead of inventing readiness in UI prose. Runtime transport chase uses cached atomic readiness counts so the audio thread does not build policy summaries or allocate strings.

Subagent insight: Parfit audited the incoming sync path and found the safe future hook: apply guarded Start/Continue/Stop/SPP chase immediately after incoming sync observation in processBlock() and before processSequencer(). The key constraint is strict gating: no random MIDI Start should hijack SpaceAge unless an explicit hardware profile is configured for receive clock, input, and chase.

Implemented boundary: Guarded Start/Continue/Stop/SPP chase now runs in the early incoming MIDI scan before sequencer processing. It requires a chase-ready hardware profile, stores pending SPP-derived steps, and suppresses outbound hardware transport while SpaceAge is responding to external transport.

Future extensions: Add an explicit editable Sync control panel, make the active chase source visible to the user, add clock-rate stability diagnostics, and only later add smoothed 24 PPQN MIDI Clock tempo derivation.

2026-06-27 - MIDI Clock Tempo Follow Needs Trust Before Speed

Task: Continue the MIDI implementation push by turning observed MIDI Clock pulses into a conservative tempo-following layer.

What connects creatively: A hardware groovebox, keyboard workstation, or future MIDI clock source should be able to pull SpaceAge into its tempo without making the user feel like the app has been hijacked. This links the Hardware Profiles workflow, MIDI Sync monitor, transport chase, and future guided hardware setup into one trust-building path: configure the source, see that it is ready, then let it drive tempo.

Architecture choice: Clock tempo-following is separate from transport chase. It requires at least one receive-clock-ready hardware profile and Host Sync must be off. The audio thread estimates BPM from 24 PPQN MIDI Clock intervals using absolute sample positions, ignores out-of-range intervals, smooths accepted pulses, and only publishes a locked BPM after a short warm-up. Diagnostics report applied/ignored clock-follow counts and the locked BPM separately from raw clock pulse counts.

Future extensions: Add a customer-facing Sync panel with source selection, lock/stability meters, jitter diagnostics, and a clear choice between Internal, Host, and MIDI Clock tempo authority. This same panel can later explain MTC/MMC support without mixing transport chase and tempo follow into one ambiguous switch.

2026-06-27 - MMC Chase Should Be Explicit, Not Magical

Task: Add guarded MIDI Machine Control runtime behavior without letting arbitrary MMC messages hijack the DAW.

What connects creatively: Some hardware speaks transport through MIDI Clock Start/Stop, some through MMC, and some through both. Treating those as one blob would create mysterious behavior. Separating MMC-ready chase from clock-ready chase lets a future hardware setup assistant say, plainly, "this box can drive SpaceAge transport by MMC" without implying it also provides tempo clock or song-position accuracy.

Architecture choice: MMC chase has its own policy count, runtime counters, and UI summary rows. Play and Deferred Play start from the current or pending SPP position; Stop and Pause stop playback and release voices; unsupported commands such as Fast Forward, Rewind, and Record are observed and counted but ignored. MMC readiness requires an input device, chaseIncomingTransport, and respondsToMmc, but it does not require Receive MIDI Clock.

Future extensions: Add user-facing source naming, supported-command badges, and eventually deliberate mappings for MMC rewind/fast-forward/record if they make sense in SpaceAge's Arrangement Canvas.

2026-06-27 - MTC Chase Is Position, Not Tempo

Task: Continue the MIDI protocol push by adding guarded MIDI Time Code runtime behavior for full-frame and assembled quarter-frame messages.

What connects creatively: MTC matters for hardware rigs, video-adjacent scoring, and external timeline setups, but it is not a groove clock. Adding it as a position authority, separate from MIDI Clock tempo-follow and MMC transport commands, keeps the future Sync page understandable: Clock answers "how fast," MTC answers "where," MMC answers "play or stop."

Architecture choice: MTC chase has its own policy count, runtime counters, and UI summary rows. Full-frame MTC can resolve immediately. Quarter-frame MTC stores the eight nibbles and only commits position after a complete 0-7 packet arrives. Readiness requires an input device, chaseIncomingTransport, and respondsToMtc; it does not require Receive MIDI Clock or MMC capability.

Boundary call: MTC chase sets the Arrangement position, but it does not start playback, stop playback, or change tempo. It converts timecode to SpaceAge steps using the current project BPM and clamps to the current transport range. Deeper source-offset controls, frame-rate display, and lock-quality meters belong in the future Sync page.

Future extensions: Add MTC source offset, drop/non-drop display, source lock/stability badges, last received timecode readout, and an explicit choice between "follow timecode position only" and future more advanced chase behaviors if real users need them.

2026-06-27 - Sync Authority Needs Three Answers

Task: Give MIDI Sync policy a shared language for clock authority, position authority, and transport authority.

What connects creatively: A musician does not want to decode whether a device is sending Clock, SPP, MTC, MMC, or some mixture of them. They want to know three plain things: who controls tempo, who can move the playhead, and who can press play/stop. Splitting those jobs lets SpaceAge say "Host controls tempo, MTC controls position, SpaceAge controls transport" without forcing the user to think like a protocol manual.

Architecture choice: The model-layer MidiSyncPolicySummary now carries the authority labels. The editor displays them, but does not invent them. This lets a future Settings Sync page, hardware wizard, or diagnostics panel reuse the same truth without duplicating policy decisions.

Future extensions: Add a source-selection page with guarded choices for Internal, Host, MIDI Clock, SPP, MTC, and MMC; add lock-quality meters; and eventually allow named sync presets for common hardware rigs.

2026-06-28 - Envelope Shape Should Be A Shared Musical Gesture

Task: Add an A-D slope control to SpaceAge ADSR controls, with the visual envelope rendered as a smooth spline rather than a hard straight segment.

What connects creatively: Envelope slope is not just a synth parameter; it is part of the musician's sense of touch. A pluck, swell, pad, bowed tone, and struck mallet can share identical attack/decay/sustain/release numbers but feel different because the fall from attack to decay bends differently. Making this a shared control connects Redshift, Liftoff, Moonshadow, Lunacy, SoundFont playback, and future samplers such as Quasar under one expressive language.

Architecture choice: The shared PolyAdsrDisplay now accepts an optional slope slider and eases the displayed curve toward the target value with a timer, so parameter changes feel animated instead of snapping. The audio engine uses the same adslope parameter to shape decay progress after the existing exponential envelope calculation, keeping the feature compatible with current patches while adding a new expressive dimension.

Future extensions: Reuse this curve/spline idea for drawable automation, Motion Clips, vibrato envelopes, filter envelopes, sample loop crossfades, and Flux Nodes. A future "curve library" could let users apply consistent ease-in/ease-out behavior across notes, clips, effects, and modulation.

2026-06-28 - MIDI Readiness Should Teach The Finish Line

Task: Continue the MIDI implementation push by making the protocol coverage report expose explicit next actions and product-readiness blockers.

What connects creatively: MIDI complexity can either feel like a swamp or like a guided hardware cockpit. If SpaceAge can tell the user, "notes are ready, compact expression drawing exists but still needs the full Piano Roll treatment, SysEx is safe but still needs librarian polish," then protocol support becomes confidence-building instead of intimidating. This same language can drive Settings, onboarding, QA, release notes, and future guided setup flows.

Architecture choice: Each MIDI coverage family now owns its nextAction and blocksProductReady state in the shared MIDI model. The editor displays that model but does not invent the interpretation. That keeps backend truth, customer-facing status, and documentation aligned as MIDI support approaches a release-quality finish.

Future extensions: Use the same next-action model to build guided MIDI setup cards for controllers, MIDI guitars, wind controllers, drum pads, hardware synths, and SysEx librarian workflows. A future MIDI Dashboard could turn each blocker into a visible "finish this" path instead of a passive diagnostic row.

2026-06-28 - MIDI Learn Response Curves Make Hardware Feel Personal

Task: Add per-mapping response curves to MIDI Learn so hardware gestures can be shaped without changing the destination parameter.

What connects creatively: A controller knob, expression pedal, mod wheel, breath controller, and aftertouch strip all have different physical personalities. A linear mapping is technically correct but often musically stiff. Fast-start and slow-start curves connect MIDI Learn to the same "feel matters" design thread as ADSR slopes, velocity drawing, Flux Nodes, and future Motion Clips: the user's hand should feel like it is touching the music, not just sending numbers.

Architecture choice: The curve lives on MidiControlMapping, beside range and inversion, so it persists with projects, appears in MIDI Maps summaries, and applies at runtime before the value reaches the target parameter. The first UI is deliberately compact: C-, LIN, and C+ buttons per mapping row. This keeps the feature discoverable without making MIDI Maps feel like a spreadsheet.

Future extensions: Replace the three nudge buttons with a small curve editor when the MIDI Dashboard gets a full-page home; add preset curve names for pedals, faders, endless encoders, breath controllers, and wind/MIDI guitar expression; and eventually let guided hardware setup suggest curve defaults by device type.

2026-06-28 - Program/Bank Recall Needs Plain-Language Trust

Task: Turn MIDI PATCH rows from raw Bank Select / Program Change facts into reusable user guidance.

What connects creatively: Program and bank messages are not glamorous, but they are where hardware confidence either blooms or dies. A user should not have to know that CC0 and CC32 are Bank MSB/LSB before deciding whether a row can recall a hardware patch. The same model label can serve the MIDI PATCH panel, the Import Wizard, future SoundFont mapping, and the Hardware Setup assistant.

Architecture choice: MidiPatchEventSummary now owns recallStatusLabel and recommendedActionLabel. The editor displays those labels rather than making local guesses. Complete bank+program rows become "ready" recipes; program-only rows are allowed but explained as bank-dependent; bank-only rows remain preserved setup data and are not converted.

Future extensions: Add a deliberate "Map to SoundFont Preset" path, a guarded "Attach to Lane Hardware Profile" path, and a future guided "This imported file wants channel 4 program 57. What should SpaceAge do with that?" dialog.

2026-06-28 - MIDI Patch Recipes Need Eligibility, Not Guesswork

Task: Make Program/Bank rows explicitly state whether they can become hardware profile recipes.

What connects creatively: This is the same design principle as one-instrument-per-lane: prevent invisible ambiguity. A Bank Select by itself is not a usable patch recall, but it is still meaningful setup data. A Program Change by itself can be useful, but only if the hardware is already in the desired bank. Treating those cases differently makes SpaceAge feel like a careful assistant rather than a raw event list.

Architecture choice: MidiPatchEventSummary now carries canCreateHardwareProfileRecipe. The MIDI PATCH save action uses that field, so future panels can make the same distinction without re-decoding Bank/Program semantics.

Future extensions: The Import Wizard can expose three buttons per row: Save Hardware Recipe, Map SoundFont Preset, and Preserve Only. Bank-only rows should show only Preserve Only until a Program Change is supplied.

2026-06-28 - MIDI Import Should Preview Patch Consequences

Task: Make Bank/Program/setup rows visible inside the MIDI Import Wizard before import.

What connects creatively: Import is a moment of trust. If SpaceAge says "I found patch setup data" but hides the actual rows until later, the user still has to leap. A compact Patch Setup Preview turns imported MIDI into a legible object: "this file wants channel 3, bank 1/2, program 25." That same clarity can later power hardware recall, SoundFont mapping, and teaching-oriented MIDI diagnostics.

Architecture choice: The wizard reuses MidiImportReviewDashboard sections and MidiPatchEventSummary recall labels instead of parsing the file again. The setup preservation toggle was renamed to PRESERVE SETUP FOR MIDI PATCH, making the consequence of disabling it much clearer.

Subagent note: Carver identified this as the safest customer-facing next slice: improve copy and preview visibility before adding row-level conversion buttons.

Future extensions: Add row-level import choices for hardware recipe, SoundFont mapping, preserve-only, and discard; then connect completed hardware recipes to the lane MIDI panel without sending anything until explicitly confirmed.

2026-06-28 - MIDI PATCH Rows Need A Deliberate Handshake

Task: Add selected-row action to MIDI PATCH so a user can convert one Program/Bank row into one hardware profile recipe without using a broad bulk command.

What connects creatively: This is the same safety instinct as "one instrument per lane" and "no SysEx without confirmation." Imported patch data is meaningful, but dangerous if SpaceAge acts like it knows the user's rig. A selected-row handshake lets the musician say, "yes, this exact row is the hardware patch I care about," while keeping every other setup event preserved but inert.

Architecture choice: MIDI PATCH remains review-first and non-sending. Row selection is visual, SAVE SELECTED PROFILE is enabled only when the model says the row can become a recipe, and SAVE ALL ELIGIBLE is kept separate for bulk cleanup. The processor still owns profile creation, so the editor never invents Program/Bank semantics.

Future extensions: Add row-level Attach to Lane, Map SoundFont Preset, and Preserve Only actions. Once those exist, imported MIDI setup data can become a guided assistant instead of a list of protocol trivia.

2026-06-28 - Hardware Profile Handoff Should Point To The Lane, Not The Air

Task: Let a selected MIDI PATCH row become a hardware profile recipe and attach directly to the current Arranger lane target.

What connects creatively: SpaceAge's lane-first architecture is strongest when every decision lands somewhere visible. A hardware patch recipe floating in a library is useful, but a recipe attached to a lane says, "this line of music wants this external sound." That keeps external hardware from feeling like a separate technical layer and brings it into the same visual song-building language as internal instruments and SoundFonts.

Architecture choice: The new SAVE + ATTACH TO LANE action still creates profile data through the processor and still sends nothing. It only binds the created profile id to the selected Arranger lane target, leaving actual recall behind the existing confirmation-gated hardware recall path.

Future extensions: After SoundFont mapping exists, the same selected-row workflow can offer three parallel destinations: hardware lane profile, SoundFont preset, or preserved setup note. That triad keeps imported MIDI flexible without reviving hidden preset mutation.

2026-06-28 - SoundFont Mapping Should Be A Door, Not A Trapdoor

Task: Add an explicit MIDI PATCH action that maps a selected Bank Select / Program Change row to the selected Arranger lane's loaded SoundFont.

What connects creatively: SoundFonts are our fastest bridge between imported MIDI and a playable workstation feel. But if imported MIDI silently changes a lane's SoundFont, the user loses trust. A visible MAP SF2 button turns protocol data into a deliberate creative choice: "this imported row probably means patch 49 strings; apply that to this lane now." It connects MIDI import, SoundFont workstation behavior, lane-first architecture, and future GM/XG workflows without recreating the old hidden Pad-proxy confusion.

Architecture choice: The action only works on a selected MIDI PATCH row and a selected Arranger lane that already has a SoundFont loaded. Program-only rows map to the 0-based SoundFont program. Bank+program rows try the existing 128-preset bank layout and fall back to program-only if the requested bank is outside the loaded SF2. Import remains review-only and does not mutate presets.

Future extensions: Add a richer mapping dialog that previews nearby SoundFont presets, supports explicit Bank MSB/LSB interpretation modes for non-GM fonts, and can create a reusable "GM import profile" for schools, hardware workstations, and large orchestral SoundFont collections.

2026-06-28 - Hardware Handoff Needs A Next Door

Task: Add a direct MIDI OUT preflight shortcut to MIDI PATCH after selected-row hardware profile attachment.

What connects creatively: A hardware profile attached to a lane is only half the story. The musician also needs to know whether the lane has an actual output device and whether the device is visible/open. Putting a MIDI OUT door inside MIDI PATCH turns a technical chain into a guided flow: review imported patch row, attach profile to lane, verify output readiness, then recall only by confirmation.

Architecture choice: The MIDI PATCH panel still sends nothing. It only dismisses itself and opens the existing MIDI OUT preflight surface, which already uses processor-owned readiness/runtime/device reports. This keeps navigation in the editor and keeps protocol truth in the MIDI model.

Future extensions: When the hardware setup assistant matures, this same handoff can become a full wizard: choose profile, choose output, test note, optional recall preview, optional SysEx queue, and saved device-repair recommendation.

2026-06-29 - SoundFont Mapping Belongs In The MIDI Model

Task: Move SoundFont Program/Bank mapping rules out of the MIDI PATCH editor and into reusable MIDI backend code.

What connects creatively: This is the same "no hidden magic" rule that governs SysEx, hardware recall, and Instrument Bay decisions. A Program Change row can become a SoundFont preset, but that conversion is a musical decision and a protocol decision at the same time. Keeping the rule in the MIDI model means the Import Wizard, MIDI PATCH, future General MIDI helpers, and school-friendly workstation templates can all speak the same language.

Architecture choice: mapMidiPatchSummaryToSoundFontPreset() now accepts a MidiPatchEventSummary plus a preset count and returns a SoundFontProgramBankMapping. The editor only applies a validated result. The backend owns plain program mapping, 128-preset bank layout mapping, fallback behavior when a bank is outside the loaded SF2, and warning text.

Future extensions: Replace the current direct MAP SF2 action with a richer Patch Mapping Wizard that previews actual preset names, supports explicit GM/GS/XG/SF2 bank interpretation modes, and can batch-map imported channels to SoundFont lanes without mutating anything until the user commits.

2026-06-29 - MIDI Latency Needs A Truthful Diagnosis

Task: Improve MIDI Health latency language so it separates internal audio-block timing from driver/interface/controller latency.

What connects creatively: A musician does not experience latency as a protocol concept. They experience it as "my fingers are ahead of the sound." SpaceAge should protect trust by being plain about which part it controls and which part comes from the audio driver, MIDI interface, controller, hardware synth, Bluetooth path, or heavy processing.

Architecture choice: MIDI Health now describes internal block time as only one part of felt latency. When the buffer is high, it becomes an explicit warning. When the buffer is low, the message explains that incoming notes are sample-positioned inside the block and points the user toward the external/driver path.

Future extensions: Add a guided latency calibration tool: play a click, record a controller response, estimate round-trip delay, and suggest record-latency compensation. This can later connect to hardware setup profiles and per-controller defaults.

2026-06-29 - MIDI Protocol Reality Audit

Task: Continue the MIDI protocol push by comparing the real implementation against practical MIDI 1.0 expectations, not just counting message families that SpaceAge can classify.

What connects creatively: MIDI is a trust layer. If SpaceAge tells a user it is ready for external synths, imported files, controllers, and hardware recall, that promise has to mean more than "we parsed the bytes." It has to mean the musician can see what will happen, change it intentionally, and avoid surprises. This audit connects MIDI Health, MIDI Protocol Coverage, MIDI PATCH, SysEx Vault, Import Wizard, Hardware Output, and future Hardware Assistant work into one truth-telling system.

Architecture choice: The protocol coverage report now separates standard musical CCs from RPN/NRPN/channel-mode setup data, marks pitch/pressure as backend-ready but editor-incomplete, calls out first-tempo MIDI import as incomplete tempo-map support, flags raw-pattern versus lane-owned export semantics, adds a Tempo/Meter/Key Maps row, and adds a Hardware Output Timing row. The report is intentionally less flattering because it is now more useful.

Subagent outcome: Hubble performed a read-only MIDI implementation audit and found the same main pressure points: direct external MIDI output is still asynchronous rather than sample-offset scheduled, MIDI file import is first-tempo based, selected-pattern export channel behavior differs from lane-aware arrangement export, SysEx is guarded but not a full librarian, and drawable expression editors remain unfinished.

Future extensions: Use this same model as the backbone of a MIDI Dashboard. Each unfinished row should eventually open the exact workflow needed to finish it: hardware timing calibration, tempo-map adoption, RPN/NRPN setup review, selected-pattern export cleanup, expression drawing, SysEx transfer progress, or Sync setup.

2026-06-29 - Hardware MIDI Timing Needs Musical Trust

Task: Continue the MIDI protocol implementation by upgrading external hardware output timing for live lane playback.

What connects creatively: A hardware synth or drum machine does not care how elegant SpaceAge looks if the notes arrive with a sloppy feel. Timing is part of the instrument. Preserving sample offsets for live external output connects Arrangement lanes, MIDI recording, controller feel, future hardware profiles, and the eventual Hardware Assistant into one promise: external gear should feel like it belongs inside the song, not like a device taped onto the side.

Architecture choice: Live Arrangement lane output now carries each due message's in-block sample offset and sample rate into the hardware router. The router uses JUCE's scheduled MidiOutput::sendBlockOfMessages() path for those live lane events. Confirmed hardware recall and SysEx remain on the existing explicit-delay queue, because setup dumps need safety, pacing, progress, and confirmation more than microtimed musical scheduling.

Future extensions: Add a hardware timing calibration panel that can test an output device, estimate felt latency, recommend record-latency compensation, and show a timing-health/jitter readout. This can eventually live beside MIDI OUT preflight and hardware profile recall, making external synth setup feel guided instead of mysterious.

2026-06-29 - Raw Pattern MIDI Export Needs A Visible Convention

Task: Normalize raw selected-pattern MIDI export channels without making it pretend to be lane-owned Arrangement export.

What connects creatively: SpaceAge has two valid export stories. A raw pattern is a portable sketch or groove: drums should land where other DAWs expect drums, Chord Engine ideas should be easy to audition, and Piano Roll channels should preserve the performer's intent. An Arrangement clip is a song object: it belongs to a lane, and the lane owns its output/export channel.

Architecture choice: Raw pattern export now uses a pattern-local convention: drum steps on General MIDI channel 10, Chord Engine markers on channel 1, and Piano Roll notes on their stored source channels. Selected Arrangement clip export remains lane-route aware, using the clip's lane playback/export channel.

Future extensions: The Render/Export dialog should eventually make this explicit with choices like Pattern Sketch, Selected Clip, Whole Arrangement, Drums Only, and MIDI Stems. That way the musician picks the musical intent rather than being forced to understand backend routing rules.

2026-06-29 - Export Labels Should Teach The Object Model

Task: Rename MIDI export preview and save-dialog wording so raw patterns, selected Arrangement clips, and full Arrangements are clearly different user-facing objects.

What connects creatively: This reinforces the lane-first architecture without forcing the user to read documentation. Pattern Sketch tells the musician they are exporting a portable idea. Selected Arrangement Clip tells them the clip's lane context matters. Whole Arrangement tells them the canvas is the source of truth. The words teach the workflow quietly.

Architecture choice: The export readiness model now produces clearer scope labels, and the selected-pattern save dialog changes its title depending on whether the export is raw pattern-local or lane-owned clip export.

Future extensions: The eventual Render/Export page can reuse these labels as primary choices, then add explanatory subtext for channel behavior, stem packaging, and DAW collaboration.

2026-06-29 - MIDI Expression Needs A First Authoring Door

Task: Add a first-stage MIDI expression authoring tool to the existing MIDI EXPR panel.

What connects creatively: Imported expression data already had a place to be inspected, cleaned, thinned, quantized, and deleted. What was missing was the small psychological bridge from "SpaceAge preserved this" to "I can create this on purpose." Adding playhead-based points and short ramps connects the MIDI backend, Piano Roll performance shaping, future automation lanes, hardware CC workflows, and controller recording into one visible idea: expression is musical material, not hidden protocol debris.

Architecture choice: The tool only creates ordinary timeline expression messages: mod wheel, expression, volume, pan, sustain, brightness CC74, pitch bend, and channel pressure. It uses the existing processor expression-event APIs and undo checkpoint path. RPN, NRPN, Data Entry, Bank/Program, and channel-mode setup messages remain review-only, because those belong in hardware setup/patch workflows rather than casual curve drawing.

Future extensions: Replace the simple point/ramp tool with drawable lanes in the Piano Roll, curve handles, selection-sensitive thinning previews, clip-local versus pattern-shared ownership choices, and grouped RPN/NRPN helpers for pitch-bend range, tuning, and hardware-specific parameters.

2026-06-29 - Poly Aftertouch Needs A Note Target

Task: Extend MIDI EXPR authoring so poly aftertouch can be created intentionally, not only preserved from imported or recorded MIDI.

What connects creatively: Poly aftertouch is one of those features that wins over expressive players because it lets one note in a chord bloom while the other notes stay still. That connects MIDI guitar, wind controller, MPE-like expectations, internal synth modulation routes, and future high-end controller marketing. The feature only makes sense if the user can choose which note receives the pressure, so a note selector is the honest UI.

Architecture choice: The same MIDI EXPR insert/ramp path now authors aftertouchChange(channel, note, value) events. The note selector is active only for Poly Aftertouch so ordinary CC, bend, and channel-pressure authoring remains simple. The events still pass through addMidiExpressionEvent() and the shared timeline-expression filter.

Future extensions: Drawable Piano Roll pressure lanes should eventually let a user paint per-note pressure directly under selected notes. That will matter for MPE-style controllers, guitar bends, wind-controller timbral swells, and hardware synths that support note pressure.

2026-06-29 - Expression Ramps Need Musical Length Choices

Task: Replace the fixed four-step MIDI EXPR ramp with selectable 1, 2, 4, 8, and 16 step ramp lengths.

What connects creatively: Ramps are not merely data entry. They are swells, filter opens, pressure blooms, pan throws, and pitch gestures. A fixed four-step ramp is useful, but it teaches the wrong lesson: expression should be shaped according to phrase length and musical intent. Selectable lengths give the first-stage expression tool a little compositional usefulness while staying far short of the future drawable automation system.

Architecture choice: The ramp still uses the same safe expression-event creation path and still starts at the playhead. Only the number of inserted points and final tick distance change. This keeps RPN/NRPN, Bank/Program, Data Entry, and channel-mode setup messages out of casual authoring.

Future extensions: The selectable ramp length can later become the default duration picker for drawable expression lanes, Motion Clips, and clip-decoration modulation patterns.

2026-06-29 - RPN/NRPN Review Should Show Selection State

Task: Improve MIDI setup review so RPN/NRPN selector messages are visible before Data Entry arrives, and orphan Data Entry is clearly flagged.

What connects creatively: RPN and NRPN are not normal knobs. They are two-step conversations with hardware: first the song says "I am editing this parameter," then Data Entry changes it. If SpaceAge only shows the Data Entry value, the user sees the punchline without the setup. Showing selector state makes imported MIDI feel less like code and more like an inspectable musical/hardware recipe.

Architecture choice: The review path now adds selector rows such as selected pitch-bend range awaiting Data Entry, labels Data Entry with no active selector as a warning, and exposes structured MidiSetupControllerSummary groups for future UI cards. This is still review-only; it does not make RPN/NRPN casual drawable expression or MIDI Learn material.

Future extensions: Promote these review rows into structured hardware setup cards with parameter name, selected RPN/NRPN number, Data Entry value, target device/profile, send safety, and recipe attachment.

2026-06-29 - Import Review Needs Structured Setup Groups

Task: Carry structured RPN/NRPN setup summaries into the MIDI Import Review Dashboard.

What connects creatively: The Import Wizard is the user's first handshake with a mysterious MIDI file. Text rows explain what was found, but structured setup groups let SpaceAge become helpful later: "this file sets pitch-bend range," "this file edits a device-specific NRPN," or "this setup row can become a hardware profile recipe." That connects import review, MIDI PATCH, hardware profiles, SysEx safety, and future guided hardware setup.

Architecture choice: MidiImportReviewDashboard now carries MidiSetupControllerSummary groups plus counts. The visible review can still show simple lines, but downstream UI no longer needs to parse those lines to understand RPN/NRPN setup.

Future extensions: Build a card-based Patch Setup Details panel where Bank/Program rows, RPN/NRPN rows, and SysEx snapshots each have clear actions: preserve, attach to lane, map to SoundFont, save as hardware profile recipe, or ignore.

2026-06-29 - Raw Controller Count Is Not Expression Count

Task: Correct MIDI inspection reporting so ordinary performance controllers and setup/channel-mode controllers are not blurred together in user-facing expression totals.

What connects creatively: MIDI uses the same Control Change message shell for very different musical intentions. Mod wheel is a performance gesture. RPN/NRPN/Data Entry can alter hidden hardware state. Bank Select changes instruments. If the app calls all of that "expression," it becomes less trustworthy. This distinction connects Import Wizard wording, MIDI Health, MIDI PATCH, future expression drawing, and hardware profile safety.

Architecture choice: Raw controllerEvents remains a protocol count of controller messages, but import summaries and expression checks now subtract Bank Select and setup-controller traffic before claiming something is musical expression. Per-channel summaries still show setup CC separately.

Future extensions: Rename preserved payload counters that currently say "expression" but intentionally preserve expression plus setup bytes. The future UI should use clearer labels such as Preserved MIDI Payload, with subcounts for expression, patch setup, and SysEx.

2026-06-29 - Import Receipts Need Payload Subcounts

Task: Add clearer MIDI import receipt counts without breaking existing UI paths that still read the older preserved-expression total.

What connects creatively: A good import receipt is a trust-builder. It tells the musician what SpaceAge did and what it deliberately did not do. Splitting preserved MIDI payload into performance expression and setup payload connects the Import Wizard, MIDI PATCH, SysEx safety, hardware profiles, and future expression lanes without forcing the user to understand raw controller bytes.

Architecture choice: preservedExpressionEventCount stays as a compatibility total, but preservedPerformanceExpressionEventCount and preservedPatchSetupPayloadEventCount are now serialized beside it. UI should prefer the subcounts when explaining an import result.

Future extensions: Rename the compatibility total after the UI has migrated, likely to preservedMidiPayloadEventCount, and show a compact receipt line such as Preserved MIDI payload: 2 expression, 4 setup.

2026-06-29 - Setup Groups Need UI-Ready Numbers

Task: Expose RPN/NRPN setup-controller groups with parameter type, combined 14-bit parameter number, combined 14-bit Data Entry value, and clear labels for complete or incomplete 14-bit parameter/value pairs.

What connects creatively: Hardware MIDI setup can look like occult bookkeeping if the UI has to show raw CC99/98/101/100/6/38 traffic. Turning that conversation into structured fields lets SpaceAge later show friendly cards like Pitch Bend Range, Fine Tuning, or Device NRPN 1234 without making the user decode controller pairs. This connects MIDI import, MIDI PATCH, hardware profiles, SysEx safety, and future guided hardware setup.

Architecture choice: The shared MIDI layer now calculates and serializes the combined 14-bit parameter/value fields inside MidiSetupControllerSummary, plus labels that distinguish complete values from MSB-only or LSB-only traffic. Display text remains useful, but it is no longer the only source of truth.

Future extensions: Build a Patch Setup Details panel where each setup group can be preserved, ignored, attached to a hardware profile recipe, or mapped to a named hardware parameter definition.

2026-06-29 - Setup Groups Need Suggested Actions

Task: Add action-state fields to RPN/NRPN setup summaries so UI can tell whether a row is ready for a hardware setup card, awaiting Data Entry, or orphaned because Data Entry arrived without a selector.

What connects creatively: This is a tiny backend field with a large UX payoff. Instead of forcing a musician to understand controller-pair logic, the future setup card can say what SpaceAge knows and what the next safe action is. It connects the Import Wizard, MIDI PATCH, Hardware Profiles, MIDI Health, and the eventual guided hardware assistant into one calmer story.

Architecture choice: MidiSetupControllerSummary now carries needsParameterSelector, needsDataEntry, readyForHardwareSetupCard, and suggestedActionLabel. Editor code should render those fields rather than duplicating readiness logic.

Future extensions: When incomplete selector-only groups are promoted into summaries, use the same fields to show Complete selector instead of adding a second status model.

2026-06-29 - Incomplete Selectors Should Not Disappear

Task: Preserve selector-only RPN/NRPN traffic as structured setup review groups even when Data Entry never follows.

What connects creatively: Imported MIDI files are often messy because hardware workflows are messy. A partial NRPN selector might be accidental, truncated, or meaningful only in relation to a hardware device's running state. If SpaceAge hides it, the user cannot make an informed decision. If SpaceAge shows it calmly as incomplete setup data, the Import Wizard earns trust.

Architecture choice: The setup summarizer now tracks partial RPN/NRPN selector traffic per channel and emits a warning group with needsParameterSelector plus a Complete parameter selector action. Switching between RPN and NRPN families flushes pending selector state so later Data Entry cannot attach to the wrong family.

Future extensions: The grouped hardware setup card can later offer to discard incomplete selectors, complete them manually, or map them to a known hardware definition.

2026-06-29 - Setup Actions Need Stable Kinds

Task: Add a machine-readable action kind beside each MIDI setup group's human action label.

What connects creatively: Human labels are for musicians; stable action kinds are for SpaceAge itself. This lets the Import Wizard, MIDI PATCH, Hardware Profiles, and future guided setup cards share the same decision state without parsing prose or breaking when we improve wording.

Architecture choice: MidiSetupControllerSummary now carries suggestedActionKind alongside suggestedActionLabel. The label can become friendlier later, while the kind remains a dependable branch point for UI.

Future extensions: Use the same action-kind approach for SysEx vault rows, Program/Bank mapping rows, hardware output preflight rows, and MIDI Health repair cards.

2026-06-30 - MIDI Timing Needs A Truthful Calibration Backbone

Task: Add a reusable MIDI timing calibration summary to MIDI Health before building another customer-facing timing panel.

What connects creatively: Controller latency is not one thing. It is audio block size, driver behavior, interface timing, controller response, hardware response, monitoring path, and sometimes user expectation. By putting calibration readiness into MidiProjectHealthSummary, SpaceAge can later show a single trustworthy card: what is known, what is guessed, what is saved, and what the user should do next. This connects Settings, MIDI Health, hardware profiles, live recording, external MIDI output, and future guided hardware setup.

Architecture choice: MidiTimingCalibrationSummary is deliberately a readiness/recommendation model, not a fake measurement model. It reports current block latency, saved record compensation, whether there is an armed input or hardware output worth calibrating, stable action kinds, human labels, and warnings. The future measurement pass can plug into this same object without changing the UI contract.

Future extensions: Add a calibration wizard that sends/records a click or loopback pulse, estimates round-trip and jitter, suggests record-latency compensation, and stores per-device/per-profile timing defaults.

2026-06-30 - Calibration Measurements Need Shared Math

Task: Add a reusable helper for pulse-based MIDI timing calibration measurements.

What connects creatively: A calibration wizard is only useful if every screen agrees on the math. Average round-trip, jitter, one-way estimate, confidence, and suggested compensation should not be reimplemented in Settings, Hardware Profiles, Import Wizard diagnostics, or support reports. One helper lets those surfaces speak the same language.

Architecture choice: buildMidiTimingCalibrationMeasurement() accepts sent and returned pulse timestamps and produces a serializable result with confidence and warnings. It does not apply the compensation by itself. That keeps measurement, user consent, and state mutation as three separate steps.

Future extensions: Store the accepted result per controller/interface/hardware profile, then use it to pre-fill REC LATENCY COMP and to warn when the current audio buffer or device path no longer matches the saved calibration.

2026-06-30 - Accepted Timing Calibration Belongs To Hardware Profiles

Task: Persist accepted MIDI timing calibration data on HardwareMidiProfile and expose it through hardware profile summaries.

What connects creatively: This turns latency from a mystery into a remembered relationship between SpaceAge and a specific hardware path. A USB keyboard, DIN interface, external synth, and audio buffer can all feel different. If SpaceAge remembers calibration at the profile level, future Settings cards can say: This device path was calibrated, this path is untested, or your buffer changed, rerun calibration without pretending one global number explains every rig.

Architecture choice: MidiTimingCalibrationRecord stores profile-associated ids, compensation, jitter, pulse count, confidence, and notes. It serializes independently and is embedded only when a hardware profile has an accepted calibration. Profile summaries expose the label, compensation, jitter, and warnings, but loading a profile still does not silently mutate global recording compensation.

Future extensions: Build a guided calibration wizard that can accept a loopback/audio pulse result, save it into the selected hardware profile, and offer an explicit Apply to recording compensation action with a clear undoable project/settings mutation.

2026-06-30 - MIDI Protocol Timing Status Must Tell The Same Truth

Task: Update the MIDI Protocol Coverage scorecard so Hardware Output Timing reflects the new calibration backbone without pretending the user-facing calibration workflow is finished.

What connects creatively: This keeps the Settings panels from becoming sales copy. SpaceAge can now say, with precision, that hardware playback is scheduled, calibration records can be remembered, and saved profile timing can warn about changed buffer latency. It also says the part a performer actually needs, the guided real-device calibration experience, is still unfinished. That kind of honesty will matter when people trust SpaceAge with external synths, MIDI guitars, wind controllers, and live recording.

Architecture choice: The protocol row now names profile-stored timing calibration as backend-ready, while preserving uiReady=false and blocksProductReady=true. Backend truth and product truth remain separate on purpose.

Future extensions: The row should eventually deep-link to the calibration wizard once it exists, then turn product-ready only after loopback/pulse measurement, apply/recalibrate actions, and jitter/health readouts are proven with real hardware.

2026-06-30 - Timing Calibration Should Be Visible Before It Is Editable

Task: Surface MIDI timing calibration status in existing Settings panels without building the full calibration wizard yet.

What connects creatively: A musician should not have to know where calibration data lives. If MIDI Health says whether timing is recommended, compensated, or idle, and Hardware Passports show whether a saved profile has calibration data, the app starts teaching the concept gently. This connects controller latency, hardware profile recall, external synth timing, and future performance recording into one visible language.

Architecture choice: Use existing MidiTimingCalibrationSummary and HardwareMidiProfileSummary::timingCalibrationLabel fields directly in the UI. No duplicate calculation, no hidden UI-only interpretation.

Future extensions: Turn the Timing Calibration row into a button that opens the real calibration wizard. Hardware Passport rows can later expose Apply, Recalibrate, and Clear actions per profile.

2026-06-30 - Timing Calibration Should Enter The Repair Model

Task: Add timing calibration as a structured MIDI Health repair recommendation when there is a real MIDI target to calibrate.

What connects creatively: The same repair model that says Reconnect this controller or Assign this hardware output can also say Run timing calibration. That keeps latency from feeling like an expert-only hidden preference. It becomes one more plain-language health item in the same list.

Architecture choice: Add a runTimingCalibration recommendation kind and a focused openMidiTiming action. The recommendation only appears when there is an armed input or hardware output path worth calibrating, so empty/internal-only projects do not nag users.

Future extensions: Once the wizard exists, keep the openMidiTiming action and make that panel host the actual calibration flow. That keeps saved support logs and UI branching stable.

2026-06-30 - Timing Needs Its Own Doorway

Task: Add a dedicated read-only MIDI Timing panel to Settings and route timing-calibration repair recommendations there.

What connects creatively: Timing is one of those subjects where musicians feel the problem before they can name it. A controller feels late, a hardware synth feels loose, or a recorded passage lands behind the beat. Giving timing its own doorway lets SpaceAge teach the difference between audio block latency, record compensation, and per-hardware-profile calibration without forcing the user to become an engineer first.

Architecture choice: The panel consumes MidiProjectHealthSummary directly. It does not recalculate timing state in the editor. MIDI Health remains the cockpit overview; MIDI Timing becomes the focused inspection surface for latency and calibration status. The full wizard still belongs later, after the backend and user consent flow are complete.

UI choice: Add navigation buttons to MIDI Health, MIDI Out, and Hardware Profiles directly inside MIDI Timing, while leaving the calibration wizard button disabled and plainly labeled as pending. This gives the user a useful path today without implying the measurement workflow is ready.

Future extensions: Add a guided Send Pulse / Record Return / Apply Compensation workflow, per-profile recalibration controls, and a support-friendly export of the timing report when users troubleshoot MIDI interfaces, controllers, or external synths.

2026-06-30 - Expression Data Needs A Scope

Task: Make MIDI EXPR show a selected-lane visual scope and export a copyable expression report.

What connects creatively: Expression data is performance, not bookkeeping. A mod wheel sweep, pitch bend gesture, or pressure swell should feel like something the composer can see and shape. The same visual language that helps clips show their note contents can also help MIDI expression feel alive and inspectable.

Architecture choice: Reuse the existing expression-lane summary and preview helpers instead of creating a second editor-only model. The selected-lane scope reads the same MidiExpressionLaneSummary payload used by the row list, and COPY REPORT serializes pattern, lane, tick, value, and editability information without mutating the project.

Future extensions: Turn the scope into a drawable lane with draggable points/curves, then reuse the same visual idiom for automation clips, Motion Clips, hardware CC lanes, and possibly Flux Nodes.

---

MIDI Expression Should Be Drawn Like Music

Task: Make the selected MIDI EXPR scope directly drawable for editable performance-expression lanes.

What connects creatively: Controller motion is not bookkeeping; it is performance. A filter swell, pitch bend, breath-controller bloom, mod-wheel rise, or sustain gesture should feel as drawable as a note. Turning the selected-lane scope into a first-pass drawing surface connects MIDI EXPR to the same human expectation behind Piano Roll notes, Motion Clips, clip decorations, and future automation lanes.

Architecture choice: The scope drawing path writes ordinary MidiEvent payloads through the same pattern-owned expression-event model already used by MIDI EXPR point and ramp authoring. It respects the existing editable/review-only boundary, so setup traffic such as RPN/NRPN, Bank Select, Program Change, and channel-mode data remains protected instead of becoming casual scribble data.

Future extensions: Promote the selected-scope drawer into full-height expression lanes with draggable points, curve handles, selection-aware thinning, clip-local versus pattern-shared ownership choices, and reusable Motion Clip capture. The same drawing grammar can later serve hardware CC lanes, synth automation, vibrato envelopes, Flux Nodes, and tempo-aware effect modulation.

---

MIDI Setup Cards Should Translate Hardware-Speak

Task: Make MIDI PATCH render RPN/NRPN setup-controller groups as structured hardware setup cards.

What connects creatively: RPN and NRPN messages are MIDI's old-school way of saying, "select this hidden hardware parameter, then change its value." If SpaceAge only shows raw CC99/98/101/100/6/38 lines, the user has to think like a protocol analyzer. Setup cards turn that into a musician-facing object: channel, parameter, value, warning, and next safe action.

Architecture choice: The panel now consumes MidiSetupControllerSummary directly for RPN/NRPN cards and keeps flat setup text only for channel-mode leftovers. Raw MIDI events still remain the persisted source of truth; the cards are recomputed views, so there is no schema churn and no hidden hardware send.

Future extensions: Let cards become editable once hardware parameter definitions exist: pitch-bend range, coarse/fine tuning, device-specific NRPNs, send preview, attach-to-profile, preserve-only, and explicit recall. The same card pattern can later appear in the Import Wizard, Hardware Profiles, SysEx Vault, and a guided hardware setup assistant.

---

Import Preview Should Reveal Hidden Hardware Intent

Task: Show grouped RPN/NRPN setup cards in the MIDI Import Wizard's Patch Setup Preview.

What connects creatively: Import is a moment of uncertainty. A file might contain a song, a hardware recipe, or both. Showing the first grouped setup card before the user commits makes SpaceAge feel like it is reading the MIDI file with them instead of asking them to trust a black box.

Architecture choice: The preview uses dashboard.setupControllerGroups, the same model consumed by MIDI PATCH. This keeps import preview, patch review, hardware profiles, and future setup assistants aligned around one interpretation of RPN/NRPN setup data.

Future extensions: Add a full Patch Setup Details page inside the Import Wizard, letting users choose preserve, ignore, attach to hardware profile, map SoundFont, or keep review-only per row before any MIDI file changes the project.

2026-06-30 - Hardware Setup Should Teach Roles First

Task: Add a Settings-level MIDI Setup guide that explains controller, one-external-synth, multitimbral-module, MIDI guitar, wind-controller, and drum-pad workflows.

What connects creatively: MIDI hardware is confusing because one box can be a keyboard, a sound module, a sequencer, a SysEx target, a clock source, or all of those at once. Teaching the role first keeps SpaceAge from feeling like a pile of ports and channels. A MiniNova-style lane can be explained as "one lane talks to one synth sound." A QY-70/QY-100-style setup can be explained as "one hardware box, many MIDI channels." That language can later become the guided setup wizard itself.

Architecture choice: Start with a read-only guide plus navigation to MIDI Input, MIDI Out, Hardware Profiles, and MIDI Timing. The guide does not mutate routing. It gives users a clear map before the future wizard creates profiles, assigns channels, stores recall data, or calibrates timing.

Future extensions: Add role templates such as Controller Only, External Synth, Multitimbral Module, Drum Module, Wind Controller, and MIDI Guitar. Those templates can pre-fill lane channel plans, hardware profile defaults, expression expectations, SysEx safety settings, and the structured primary action each setup card should open.

---

2026-06-30 - Timing Calibration Needs A Useful Manual Bridge

Task: Turn the MIDI Timing panel from read-only status into a manual hardware-profile calibration station.

What connects creatively: Automatic calibration will be the polished destination, but users with real hardware can already measure rough round-trip latency by loopback, external utility, or repeated recording tests. Letting them store that number on a hardware profile means SpaceAge can start remembering the feel of a MiniNova, QY-series box, MIDI interface, or controller rig before the full pulse wizard exists.

Architecture choice: Keep the editor as a thin UI layer. It captures profile id, round-trip milliseconds, jitter, and pulse count, then asks the processor to validate and save a MidiTimingCalibrationRecord. The panel refreshes from MidiProjectHealthSummary after saving or clearing, so the report, health cards, and hardware profile labels all stay aligned.

Future extensions: Replace or supplement manual entry with a guided Send Pulse / Listen For Return / Accept Compensation wizard. Add real device timing receipts, calibration history, jitter trend warnings, and a safe Apply to record compensation action that remains explicit rather than hidden.

SysEx Vault As Hardware Memory Bay

Task: continue MIDI protocol hardening by improving the SysEx librarian workflow.

Creative connection: SysEx snapshots are not just imported MIDI debris; they are recoverable memories for external hardware. The Vault should act like a hardware memory bay: a place to name dumps, describe the device, attach dumps to a hardware passport, preserve or omit them from project archives, and keep send confirmation explicit. This connects to the larger Instrument Bay philosophy without making pads the proxy for every instrument choice. The user thinks, "this lane talks to this instrument; this hardware passport knows how to wake the instrument up; this SysEx snapshot restores its special state."

Future extension: add device-aware checksum helpers, manufacturer/device-id matching, batch dump capture, restore preview, and visible transfer progress. For old hardware, the app should feel like a calm technician: it knows the dump is fragile, sends slowly enough, shows what is happening, and never transmits without permission.

---

2026-06-30 - Timing Pulses Should Feel Like A Hardware Handshake

Task: Add a safe loopback pulse sender to the MIDI Timing panel.

What connects creatively: Hardware timing calibration is part utility, part trust ritual. The user should not have to think like an oscilloscope operator. A profile-based pulse train turns "measure latency somehow" into a guided handshake: choose the hardware passport, send harmless C4 pulses, capture or measure the return, and let SpaceAge remember that device's timing personality.

Architecture choice: Reuse the hardware-output router and hardware recall log rather than adding a second MIDI sender. The pulses are ordinary note on/off messages, bounded by count and interval, and attached to the selected hardware profile. Manual round-trip entry remains available, while returned-pulse capture can now produce an accepted profile timing record when the user routes the loopback correctly.

---

2026-06-30 - MIDI Setup Cards Need Action Kinds, Not Just Advice

Task: Add stable scenario ids and primary action kinds to the reusable MIDI hardware setup scenarios.

What connects creatively: The MIDI Setup guide should not become another paragraph farm. If a user says, "I have a wind controller," SpaceAge should be able to highlight the expressive-data path and open the MIDI Expression page. If they say, "I have a QY-style multitimbral module," SpaceAge should lead with import/channel review and hardware profiles. Stable action kinds let the same scenario cards become real wizard steps later without rewriting the whole UI.

Architecture choice: Keep the scenario records read-only and non-mutating, but give each one a scenarioId, primaryActionKind, and primaryActionLabel. That keeps Settings, reports, tests, onboarding, and future first-run MIDI setup assistants pointed at one source of truth.

Future extensions: Convert each primary action into a real button route, then add a guarded Create Profile From This Scenario action that pre-fills channels, expression expectations, timing prompts, and SysEx safety defaults without sending hardware data.

---

2026-06-30 - Setup Wizard Logic Should Stay Non-Mutating First

Task: Add a backend MIDI hardware setup assistant plan that evaluates current readiness reports against a selected setup scenario.

What connects creatively: The best setup assistant feels like a calm stage tech: it tells you what is connected, what is missing, and what to do next without grabbing the cables out of your hands. That matters for hardware musicians because a controller, a rack module, a wind controller, and a QY-style box all need different kinds of confidence.

Architecture choice: The assistant plan consumes existing readiness reports instead of re-reading project state. That means MIDI Health, setup cards, and the future wizard can agree on the same truth. Steps are deliberately non-mutating and status-based: complete, needs action, blocked, or optional.

Future extensions: Render the plan as a guided checklist inside Settings, then let explicit buttons call existing safe actions: open MIDI Input, create/attach Hardware Profile, send a test note, run timing pulses, or open MIDI Expression.

---

2026-06-30 - MIDI Setup Cards Should Show Live Truth

Task: Render the backend MIDI setup assistant plans in the Settings MIDI SETUP popup.

What connects creatively: The user should not have to infer whether a hardware setup is ready from four separate panels. A card that says READY, NEEDS ACTION, or BLOCKED is a confidence object. It turns MIDI from a protocol maze into a preflight checklist.

Architecture choice: The popup builds the plans from processor readiness reports when opened and renders them read-only. This keeps the UI honest and avoids surprise routing/profile mutations.

Future extensions: Make each scenario card selectable and show one focused checklist with per-step buttons. The action kind is already in the data, so the next phase should route those actions instead of hard-coding new button behavior.

---

2026-06-30 - MIDI Setup Needs One Obvious Next Move

Task: Make the Settings MIDI SETUP cards selectable and add a focused NEXT ACTION button.

What connects creatively: Hardware setup is where musicians often lose momentum. The user should not have to read six cards, remember which detail mattered, close the popup, and hunt for the correct panel. Selecting a card and getting one obvious next move turns the guide into a calm preflight assistant: "you are setting up a wind controller; the next useful place is expression/health/input," or "you are setting up an external synth; the next useful place is MIDI Out or Hardware Profiles."

Architecture choice: The button reads the first actionable assistant step and routes to existing safe panels. It does not create a lane, attach a hardware profile, send MIDI, or mutate project state. That preserves the safety rule while still making the app feel helpful.

Future extensions: Replace the compact popup with a full guided setup page that expands the selected scenario into a stepper. Later steps can create profiles, assign channel templates, send safe test notes, run timing pulses, and attach SysEx snapshots, but only behind explicit user actions.

---

2026-06-30 - Setup Cards Need A Focused Readout

Task: Add a selected-scenario detail strip to the Settings MIDI SETUP popup.

What connects creatively: Six scenario cards are good for overview, but a musician under pressure needs one calm sentence: "This is the scenario, here is the first useful action, and nothing dangerous will happen from this panel." That turns MIDI setup from a wall of readiness data into a conversational workflow.

Architecture choice: The strip reads the same assistant-plan model as the cards and NEXT ACTION button. There is no new state model and no hidden write path. This keeps the guide, clipboard report, selected panel, and future wizard aligned.

Future extensions: Promote the strip into a persistent inspector on the future MIDI Setup page. It can show role-specific diagrams, last known hardware status, timing calibration age, SysEx restore readiness, and one guarded action at a time.

---

2026-06-30 - MIDI Setup Routes Should Match The Scenario Promise

Task: Route the Settings MIDI SETUP scenario actions to the full set of existing safe MIDI panels.

What connects creatively: A setup guide becomes useful when every sentence has a door. Controller setup should open MIDI Input, multitimbral modules should open MIDI Patch/Import Review, MIDI guitar and wind controller workflows should open MIDI Expression, and hardware dump workflows should be able to reach the SysEx Vault. The same guide can now serve as onboarding, troubleshooting, and future first-run hardware setup without splitting into separate fragments.

Architecture choice: Keep all routes as navigation-only callbacks into existing panels. The assistant still does not arm lanes, create profiles, map SoundFonts, send SysEx, or rewrite routing. It simply opens the right surface for the selected scenario's first safe next step.

Future extensions: Convert these callbacks into row-level action buttons on a larger MIDI Setup page, then add explicit guarded actions for profile templates, channel layouts, test-note sends, timing pulse calibration, and SysEx snapshot attachment.

---

2026-06-30 - Hardware Recall Needs Visible Time

Task: Add estimated MIDI DIN wire time, total completion time, and transfer category to hardware recall plans and active queue progress.

What connects creatively: A SysEx restore can feel like the app froze if the user sees no evidence that anything is happening. Timing estimates turn invisible protocol plumbing into confidence: a small patch recall should feel quick, a bulk dump should feel intentionally slower, and old hardware should feel respected rather than bullied by a modern computer. This connects the SysEx Vault, Hardware Profiles, MIDI Timing, future transfer progress meters, and the broader SpaceAge promise that dangerous operations explain themselves before they happen.

Architecture choice: Keep the estimate in the shared MIDI model (HardwareRecallPlanSummary and HardwareRecallQueueProgress) instead of drawing editor-only guesses. The processor computes per-item wire time from MIDI DIN's 31.25 kbit/s serial rate, rolls that into summary completion time beside explicit send delays, and serializes the same fields for UI, reports, tests, and future progress surfaces.

Future extensions: Expand the visible generic restore-response strip into per-Hardware-Passport restore history, then add manufacturer-specific acknowledgement dialects, progress bars for long transfers, manufacturer-specific pacing rules, batch bulk-dump capture, retry guidance, and hardware-profile warnings when a stored SysEx dump looks too large for an untested output path.

---

2026-06-30 - Imported Song Metadata Needs A Policy, Not A Surprise

Task: Carry an explicit MIDI import song-metadata policy through commit requests, receipts, serialization, docs, and tests.

What connects creatively: Tempo, meter, and key are not just file facts; they are the composition's gravity. If SpaceAge silently adopts a dragged-in MIDI file's tempo map, the whole song can feel like it slipped sideways while the user was trying to borrow a phrase or drum idea. Treating metadata as a policy connects MIDI Import, TempoCalc, Chord Engine key/mode logic, Arrangement section forms, and future score/export tools.

Architecture choice: Default to Keep current project tempo/meter/key while still reviewing and reporting imported tempo, meter, and key rows. The request/result model can now carry future policy choices without making today's import path destructive.

Future extensions: Add visible Import Wizard buttons for keeping the project, adopting first source values, adopting full source maps, or importing metadata into a separate tempo/form lane for review before committing.

---

2026-06-30 - MIDI Export Stem Package Truthfulness

Task: Make MIDI export job plans report lane/stem package readiness without pretending the current single-file export button writes multi-file packages.

What connects creatively: Arrangement lanes are the core orchestration object in SpaceAge. If each lane owns its instrument, mixer channel, MIDI channel, and export identity, then a future collaborator package should naturally become "one song MIDI file plus one lane/stem MIDI file per exported lane." That connects MIDI export, stem rendering, lane badges, hardware routing, future VST hosting, and project archiving into one mental model.

Architecture choice: MidiExportJobPlan now carries stemTrackCount, recommendedStemFolderName, and offersStemPackage. The preview can say exactly what is ready today: the current button writes the reviewed single MIDI file, while the lane rows prove that the backend can already name and describe the stem/package shape.

Future extensions: Add a deliberate Export MIDI Package action that creates a folder or zip containing the full Arrangement MIDI file, lane/stem MIDI files, a manifest with lane instrument/channel metadata, and optional setup files such as SysEx Vault references or hardware profile notes.

---

2026-06-30 - MIDI Stem Packages Are Lane Identity In File Form

Task: Add a backend writer for whole-Arrangement MIDI stem packages.

What connects creatively: A SpaceAge lane is more than a visual row. It owns an instrument, mixer identity, playback/export MIDI channel, and musical role. Writing one full Arrangement MIDI file plus one isolated MIDI file per lane turns that lane identity into a portable collaborator object. A producer can hand someone "the whole song" and also "just the bass lane" or "just the harmony lane" without making them dissect a crowded MIDI file.

Architecture choice: The lane files preserve absolute Arrangement timing instead of starting every lane at zero. That means a collaborator can drop stems into another DAW and retain the song's timeline alignment. This also keeps future MIDI package manifests, hardware-profile notes, SoundFont references, and VST routing metadata naturally attached to lane identity.

Future extensions: Expose the backend writer through the Render dialog, then add a manifest file with lane name, instrument engine, preset, mixer channel, MIDI channel, route target, hardware profile id, and any SysEx Vault references. Later, the same package model can support audio stems, Quasar assets, SoundFonts, and project archives.

2026-06-30 - Export Preview Should Offer The Package, Not Hide It

Task: Expose whole-Arrangement MIDI stem package export through the MIDI export preview.

What connects creatively: The export preview is becoming the trust layer between SpaceAge and the outside world. A musician should not need to remember that "stems" are hidden somewhere else; when the Arrangement is ready for collaborator delivery, the preview should say so and offer the package right there.

Architecture choice: The preview still builds from MidiExportJobPlan, so backend readiness remains the source of truth. If offersStemPackage is true, the panel enables a separate folder-based package action; if not, the package button stays disabled instead of pretending every MIDI export scope can write stems.

Future extensions: Add a receipt file beside the package with SpaceAge version, lane names, instrument engines, presets, mixer channels, MIDI channels, route targets, warnings, and any SysEx/SoundFont/Quasar references. The same receipt pattern can later unify audio stems, project archives, and hardware setup exports.

2026-06-30 - MIDI Packages Need A Manifest Before They Need Fancy

Task: Add a basic manifest.json to MIDI stem packages.

What connects creatively: A stem package is only useful if the receiving human, DAW, or future SpaceAge importer can understand what each file means. The manifest turns "a folder of MIDI files" into a small collaborator object: full song, lane stems, lane names, MIDI channels, route labels, event counts, and warnings.

Architecture choice: The manifest is written from MidiExportReadinessSummary, which is already the shared truth model for export preview, self-tests, and docs. That avoids a second export-description model and lets future package-import code trust the same facts the preview showed to the user.

Future extensions: Add SpaceAge version, project name, generated timestamp, instrument engine, preset name, mixer channel, hardware profile id, SysEx snapshot ids, source SoundFont/Quasar references, and checksums for each exported .mid file.

2026-06-30 - A Receipt Turns Export Into Communication

Task: Add a human-readable README.txt receipt to MIDI stem packages.

What connects creatively: Machine-readable metadata helps SpaceAge, but a musician opening a folder needs plain language. A receipt turns export into communication: what project this came from, what timing grid it uses, which lanes were written, which MIDI channels they use, where they route, and whether there are warnings. This connects collaborator workflow, support/debugging, future import, and the broader "confidence-building microDAW" promise.

Architecture choice: Write the receipt from the same MidiExportReadinessSummary that powers the preview and manifest. That keeps the JSON and human text from drifting into different stories.

Future extensions: Use the same receipt pattern for audio stem renders, Quasar packages, archived projects, and guarded SysEx/hardware recall bundles.

2026-06-30 - Export Feedback Should Have Phases

Task: Add staged status feedback to MIDI export actions.

What connects creatively: A musician should never wonder whether the app heard a click. Even if MIDI export is usually fast, the same export path will eventually carry bigger packages, richer manifests, SoundFont/Quasar references, SysEx notes, and collaborator bundles. Clear phases such as preparing, writing, and complete teach the user that SpaceAge is working deliberately.

Architecture choice: Keep this lightweight for now: status text is held long enough to avoid being overwritten by the Arranger readout, and the actual write begins after a short UI delay. This gives visible feedback without inventing fake progress percentages.

Future extensions: Replace staged text with a shared export progress panel when MIDI, audio stems, Quasar capture, archive packaging, and hardware SysEx bundles all share one export-task framework.

2026-06-30 - Stem Packages Need Support Receipts

Task: Expand MIDI stem packages with app version, package-file inventory, warning inventory, and a machine-readable support summary.

What connects creatively: A collaborator package is not just export output; it is a little spacecraft full of context. If a MIDI package includes what version made it, what files belong to it, what lanes created those files, and what warnings existed at export time, then the same package can help collaborators, support, future importers, and the user's own memory months later.

Architecture choice: Keep support metadata inside the existing manifest.json and mirror the important human facts in README.txt. That way the machine and the musician are reading the same package truth instead of two separate stories.

Future extensions: Add checksums for each exported file, source asset references, SoundFont/Quasar package links, hardware profile ids, SysEx snapshot ids, and eventually a one-click "repair/import this package" flow.

2026-06-30 - Checksums Make Collaborator Packages Trustworthy

Task: Add FNV-1a 64-bit checksums, byte counts, and a CHECKSUMS.txt sidecar for exported MIDI payload files inside stem packages.

What connects creatively: When a collaborator says "this MIDI file seems wrong," a checksum gives everyone a shared fact before the debate begins. It connects export, support, future import repair, archive validation, and project handoff into one simple promise: SpaceAge can say exactly which files it wrote and whether those files still match the exported package metadata.

Architecture choice: Checksum the .mid payload files, but do not pretend the manifest can honestly contain its own checksum. Keep the manifest and README listed as package files without self-referential hashes, and add CHECKSUMS.txt as a plain sidecar for humans and simple support scripts.

Future extensions: Add SHA-256 for stronger archive verification, detached package signatures, source asset references, and an import/repair dialog that warns if a package file was changed after export.

2026-06-30 - Package Inspection Is The Other Half Of Export

Task: Add a reusable MIDI stem-package inspection helper.

What connects creatively: Export creates trust only if SpaceAge can later recognize what it made. A package inspector turns a folder into a status object: format, version, project, full Arrangement file, lane stems, package files, missing files, size mismatches, checksum mismatches, and a ready-for-import answer. That same object can feed drag/drop import, Library repair, archive validation, collaborator support, and future "open package" workflows.

Architecture choice: Keep inspection in the MIDI model layer, not the editor. The helper accepts either the package folder or manifest.json, recomputes the same FNV-1a checksum used by export, and serializes a UI-ready summary without mutating project state. The UI can then decide whether to show a green import button, repair warnings, or a support report.

Future extensions: Add a visible package inspector dialog, repair missing files, optional zip packaging, source SoundFont/Quasar references, hardware profile/SysEx attachments, and a stronger SHA-256 path for release-grade archives.

2026-06-30 - Trust Before Import

Task: Expose MIDI stem-package inspection in the Library as CHECK MIDI PACKAGE.

What connects creatively: A collaborator package needs a moment of trust before it becomes project state. By letting the user inspect a package folder or manifest.json, copy a support report, and reveal the package without importing, SpaceAge teaches that external material is treated deliberately. This connects MIDI export, package repair, support, collaborator handoff, and future archive validation into one visible habit: first understand the bundle, then decide what to do.

Architecture choice: The UI renders the shared MidiStemPackageInspection object directly and does not parse the manifest itself. That keeps the Library page from becoming a second MIDI model layer and preserves a clean path for the future import/repair wizard.

Future extensions: Add a guarded package importer that starts from the inspection object, shows lane/channel/tempo/source-asset choices, creates a receipt, and can repair missing package files without guessing.

2026-06-30 - Preview Before Repair

Task: Add a backend import/repair preview for SpaceAge MIDI stem packages.

What connects creatively: A collaborator package should not jump straight from "I found a manifest" to "I changed your song." The preview layer gives SpaceAge a middle state: here is what is ready, here is what blocks import, here is what can be repaired, and here is the support report. That same action language can power Library inspection, future drag/drop package import, archive validation, support diagnostics, and a collaborator-safe repair wizard.

Architecture choice: Keep facts and policy separate. inspectMidiStemPackage() validates the package; buildMidiStemPackageImportPreview() translates those facts into user-facing action rows. The future UI consumes the preview instead of parsing JSON or inventing its own blocking rules.

Future extensions: Add a guarded import wizard, missing-file relink flow, zip package unpacking, source-asset repair, and an import receipt that records every lane, clip, channel, and repaired file.

2026-06-30 - Import Plans Should Be Sheet Music Before Performance

Task: Add a backend MIDI stem-package import plan.

What connects creatively: A package import is like handing SpaceAge a score from another room. Before the app performs it, the user should see the score: the full Arrangement reference, the lane stems, the intended channels, the event counts, the support files, and any repair blockers. This connects collaborator packages, support reports, future zip archives, and source-asset repair into one calm review ritual.

Architecture choice: Keep mutation out of the plan. Inspection answers "what is in the folder?", preview answers "is it safe to proceed?", and the import plan answers "what would be created?" A future commit request should do the actual import and produce a receipt.

Future extensions: Turn the plan into a full wizard with lane naming, channel reassignment, source-file relinking, import scope choices, progress reporting, undo grouping, and a written import receipt.

2026-06-30 - Commit Requests Are Consent Forms

Task: Add a guarded MIDI stem-package import commit request and receipt skeleton.

What connects creatively: Package import should feel like signing off on a flight plan. The plan says what would happen; the commit request says what the user chose; the receipt says what SpaceAge actually did. That pattern can later unify MIDI imports, archive imports, SoundFont relocation, Quasar packages, and hardware profile restores.

Architecture choice: Broken packages are forced to inspect-only, clean packages can recommend lane-stem import, and the first processor mutation path now consumes the request after explicit confirmation. The receipt exists so the mutation path has an audit trail from day one.

Future extensions: Add import progress, undo grouping, lane-name conflict resolution, channel reassignment, source-asset repair, and a visible receipt pane that can be copied into support messages.

2026-06-30 - Confirmed MIDI Stem Package Import

Task: Add the first real project-mutating import path for SpaceAge MIDI stem packages.

What connects creatively: The package importer should feel like a deliberate handoff between collaborators, not like dragging a mysterious file into a song and hoping for the best. Reusing the proven single-file MIDI importer per lane stem keeps the first implementation conservative: every imported lane goes through the same rules already used for channel splitting, expression preservation, SysEx vaulting, and setup review. That turns the package into a curated bundle of familiar MIDI imports rather than a risky new parser.

Creative extension ideas:

• The import receipt can become a "session provenance" artifact: where this material came from, which lanes were created, which support files were retained, and what warnings were accepted.
• A later import wizard can preview each lane stem with mute/skip checkboxes before commit, then still call the same processor mutation boundary.
• Package import now owns one undo checkpoint while its internal per-stem imports skip their own checkpoints. Preserve that as a collaboration-safety rule: a whole handoff should be reversible with one Undo.

2026-06-30 - Hardware MIDI Timing Should Speak Human

Task: Continue MIDI protocol hardening by making SysEx/hardware recall timing estimates easier to read.

What connects creatively: Old MIDI hardware is charming, but it can make modern users nervous because SysEx transfers appear invisible and slow. A human-readable duration label turns protocol math into trust: 35 ms, 1.2 s, or 12 s tells the user that SpaceAge knows roughly how long the wire transfer should take. This connects Hardware Passports, SysEx Vault, MIDI Timing calibration, future progress meters, and support receipts into one calming workflow.

Architecture choice: Keep the formatter in the MIDI model layer rather than the editor. Hardware recall summaries, queue progress, confirmation dialogs, and future transfer progress widgets now have one shared way to describe MIDI DIN transfer time.

Future extensions: Add per-device pacing rules, visual transfer bars for large SysEx dumps, manufacturer-specific warnings, retry receipts, and a "slow but safe" mode for delicate vintage devices.

2026-06-30 - Hardware Recall Plans Need Receipts Before They Send

Task: Move Hardware MIDI recall-plan prose into the shared MIDI model instead of assembling it only inside the UI popup.

What connects creatively: Sending program changes and SysEx to hardware is one of the few places where a musician can accidentally alter an external instrument. A plain-language recall plan gives SpaceAge a "read this before launch" checklist: output, mode, message count, bytes, planned delay, DIN wire time, transfer class, warnings, and every message that will be queued. This connects Hardware Passports, SysEx Vault, MIDI Health, support reports, and future hardware setup wizards.

Architecture choice: HardwareRecallPlanSummary now owns a plain-text report. The editor can display it, tests can verify it, and future progress/history surfaces can reuse it without copying dialog prose.

Future extensions: Save the report beside hardware recall logs, expose a copy button in the Hardware panel, attach it to project support bundles, and use it as the top page of a visual SysEx transfer progress dialog.

2026-06-30 - Import Stems Button Should Still Feel Like Inspection First

Task: Expose confirmed MIDI stem-package import inside the Library package checker.

What connects creatively: The package checker now becomes a confidence ritual: inspect first, then import only when the package is clean and the user presses a commit button. This keeps the Library from feeling like a file-management trap. It also previews a broader SpaceAge pattern for collaboration features: every external bundle should have a readable diagnosis, a deliberate commit, and a receipt.

Creative extension ideas:

• Turn the receipt into a saved project note after import, so collaborators can remember what was brought in.
• Let future package import show lane-stem checkboxes, channel remapping, and destination lane naming without changing the processor mutation boundary.
• Reuse this same inspect/commit/receipt pattern for Quasar packages, archives, SoundFont relocation, and hardware profile restores.

2026-06-30 - Hardware MIDI Queues Need Readable Flight Logs

Task: Add reusable plain-text reports for hardware recall logs and active hardware MIDI queue progress.

What connects creatively: Hardware MIDI has an emotional problem as much as a protocol problem: SysEx and old DIN transfers can feel like nothing is happening. A readable log and queue report turns invisible bytes into a trustworthy story: what was queued, what failed, how many SysEx bytes are involved, how much planned delay exists, and roughly how long the DIN wire transfer should take.

Architecture choice: Keep the report in the MIDI model layer and serialize it as plainTextReport, just like the recall plan. The UI, future progress meter, support bundles, and diagnostics can all quote the same source instead of building separate versions of truth. The detailed log report includes individual queued/failed entries, so a support report can show both "how many" and "exactly what."

Future extensions: Use the queue report as the body of a hardware transfer progress popup, save the recall log report into project support bundles, and attach the same style of report to Quasar renders, archive imports, SoundFont repair, and future "Load previous version" workflows.

2026-06-30 - MIDI Protocol Coverage Should Behave Like Preflight

Task: Add a copyable plain-text report and blocker summary to MIDI Protocol Coverage.

What connects creatively: MIDI is too broad for a single green/red light. A musician may care about live controller latency, a hardware user may care about SysEx recall safety, and a collaborator may care about MIDI file import/export fidelity. A copyable protocol report turns those separate concerns into a preflight checklist: which families are ready, which are UI-ready, which require confirmation, and which still block a product-ready MIDI promise.

Architecture choice: The coverage report lives in the MIDI model layer and serializes both productReadyBlockerSummary and plainTextReport. The Settings popup can copy it, tests can verify it, and future support bundles can include it without rebuilding the prose in editor code.

Future extensions: Add per-family "open repair panel" links, attach the report to bug bundles, compare reports between builds, and eventually expose a friendly "MIDI readiness assistant" that turns blocker families into guided setup or feature-completion tasks.

2026-06-30 - MIDI Readiness Reports Should Be Receipts, Not Vibes

Task: Add model-owned plain-text reports to MIDI project readiness, input readiness, external output readiness, external output runtime, and device inventory.

What connects creatively: Hardware setup problems are often invisible: the lane is armed but listening to the wrong input, the output route exists but the OS device is closed, or the project remembers a device that is not plugged in. By making every readiness object produce a readable report, SpaceAge can eventually hand the user a single "what is true right now?" receipt instead of making them inspect five panels and remember what each warning means.

Architecture choice: Keep the text beside the data model and serialize it as plainTextReport. This lets Settings panels, support bundles, future MIDI assistants, and diagnostic exports all quote the same facts about lanes, devices, warnings, and route readiness.

Future extensions: Add one-click "Copy Full MIDI Health Report," include these reports in crash/support bundles, and let future guided repair flows cite the exact report line that triggered each recommended action.

2026-06-30 - MIDI Health Should Be A Flight Recorder

Task: Promote the full MIDI Health summary into a model-owned plain-text report and expose COPY REPORT in the MIDI Health panel.

What connects creatively: A full MIDI setup is a little ecosystem: controller input, lane focus, hardware output, sync policy, timing calibration, SysEx snapshots, expression data, and repair guidance all matter together. A single copyable health report turns that ecosystem into a flight recorder. Instead of asking a user to describe every switch and device by memory, SpaceAge can capture the state as a trustworthy text packet.

Architecture choice: MidiProjectHealthSummary owns the prose and serializes it as plainTextReport. The Settings UI only copies it. This keeps support bundles, future bug reports, possible in-app AI help, and guided repair panels aligned to one source of truth.

Future extensions: Attach this report to crash/support bundles, add "Copy MIDI Health" to a future help menu, let a guided MIDI assistant summarize the report in friendlier language, and use report diffs to compare "before repair" and "after repair" setup states.

2026-06-30 - MIDI Sync Needs Its Own Preflight Receipt

Task: Give MIDI Sync runtime observations, sync policy/profile rows, and outbound transport plans model-owned plain-text reports, then expose a focused COPY REPORT action in the MIDI Sync panel.

What connects creatively: Sync is where a studio can get spooky fast: one device may be sending clock, another may be waiting for Start, and SpaceAge may be following position from SPP or MTC. A focused sync report turns that invisible conversation into a receipt: what arrived, who is allowed to follow, who is allowed to send, and what transport messages would go out. This connects MIDI Sync, Hardware Profiles, MIDI Out preflight, MIDI Health, and future hardware setup assistants into one calmer hardware workflow.

Architecture choice: Keep sync prose in the MIDI model layer. MidiSyncRuntimeSummary, MidiSyncPolicySummary, MidiSyncPolicyProfileSummary, MidiTransportPlanSummary, and transport-plan items now own copyable text alongside their structured fields. The editor simply bundles those model reports.

Future extensions: Attach the sync report to MIDI Health bundles, show before/after diffs when a hardware profile is repaired, add a "copy for support" bundle that includes Health + Sync + Hardware Queue, and eventually let the guided hardware assistant quote exact report lines when explaining why a device is not ready to chase or send transport.

2026-06-30 - Sync Editing Belongs To The Hardware Passport

Task: Add an intentional sync-role editing surface to MIDI Hardware Passports instead of making the MIDI Sync preflight panel mutate project behavior.

What connects creatively: A hardware profile is essentially a little contract between SpaceAge and a physical device. It says what the device is, which ports it uses, which channel it speaks on, what recall messages belong to it, and now what sync roles it can safely participate in. Keeping Clock, SPP, MTC, MMC, send-transport, and chase-transport decisions on that passport makes hardware setup feel like preparing a rig rather than toggling mysterious global switches.

Architecture choice: Add a narrow processor mutation helper for sync-policy fields only, then let the Hardware panel call it from an explicit SAVE SYNC POLICY button. The helper refreshes cached chase-readiness counts and ties Clock transmission permission to the Send MIDI Clock role. It does not queue recall messages or write to the hardware send log.

Future extensions: A guided setup wizard can pre-fill these fields from hardware templates, the MIDI Sync report can show before/after readiness, and the Hardware Timing wizard can nudge the user toward calibration only after a profile has a real sync role.

2026-06-30 - Expression Editing Needs A Little Eraser

Task: Add selected-lane, playhead-step cleanup to MIDI EXPR.

What connects creatively: Expression data is performance handwriting. A breath-controller swell, sustain pedal, pitch bend, aftertouch push, or mod-wheel move can be expressive everywhere except one bad moment. A CLEAR STEP action gives the musician a small eraser instead of a shredder. This connects MIDI recording, import cleanup, wind/MIDI-guitar workflows, future Motion Clips, and piano-roll automation lanes through one principle: expressive data should be editable at the same musical scale where the mistake happened.

Architecture choice: Keep range deletion in the processor and route the UI through that helper. The helper respects the same editable expression boundary as add/replace/delete-lane operations, and it now matches note-specific poly-aftertouch lanes precisely.

Future extensions: Expand from step-local cleanup to lasso/range cleanup, curve handles, thinning previews, lane ownership choices, "clear selected expression under selected notes," and Motion Clip conversion for repeated controller shapes.

2026-06-30 - MIDI Health Needs A Short Version

Task: Add a compact copyable next-steps report beside the full MIDI Health report.

What connects creatively: A full MIDI diagnostic report is useful for support, but a musician trying to make a controller or hardware synth behave needs a smaller answer: "what do I do next?" The short next-steps report turns Health recommendations, timing context, warning highlights, lane context, and device targets into a checklist. This connects MIDI Health, MIDI Setup, MIDI Timing, Hardware Passports, MIDI Out, and future in-app help without making the user decode every subsystem.

Architecture choice: The prose belongs to MidiProjectHealthSummary::toPlainTextNextSteps(), not to the editor. The UI only copies it. That keeps future support bundles, AI/help workflows, guided setup assistants, and test expectations aligned to one source of truth.

Future extensions: Add "before/after repair" copied reports, let the MIDI Setup assistant quote the first next-step item, include the short report in crash/support bundles, and let future hardware templates explain why a specific next action is recommended.

2026-06-30 - Every MIDI Preflight Panel Should Leave A Receipt

Task: Add focused copy reports to the MIDI Input and MIDI Output panels.

What connects creatively: MIDI setup is easiest to trust when every panel answers "what is true here?" in the same way. MIDI Health is the whole cockpit, but MIDI Input and MIDI Output are smaller workbenches. Giving each a copyable receipt makes troubleshooting feel local: if input is broken, copy the input truth; if hardware output is blocked, copy the output truth.

Architecture choice: The panels compose model-owned reports: readiness, runtime, inventory, and reusable repair recommendations. The editor does not invent a separate support language.

Future extensions: Add "Copy All MIDI Preflight" to Settings, attach focused receipts to support bundles, and let a future guided MIDI assistant switch between the smaller reports instead of forcing users through one giant diagnostic wall.

2026-06-30 - The MIDI Setup Guide Should Speak From The Model

Task: Move MIDI Setup Guide copy into model-owned plain-text reports.

What connects creatively: Hardware setup is a teaching surface, not just a diagnostic surface. A controller player, MIDI guitarist, wind-controller user, external synth owner, and QY-style multitimbral module user all need different first steps, but they should all receive the same kind of trustworthy receipt. By making the setup assistant plans speak for themselves, SpaceAge can reuse those steps in the visible guide, copied reports, future onboarding, support bundles, and maybe a guided in-app helper without letting the language split into separate dialects.

Architecture choice: MidiHardwareSetupAssistantPlan::toPlainTextReport() owns the selected-scenario report, and midiHardwareSetupAssistantPlansToPlainTextReport() composes the full guide. PluginEditor copies the model report instead of creating a second version of setup prose.

Future extensions: Add "Copy Selected Scenario," generate onboarding cards from the same model, let hardware templates fill in scenario defaults, and let an in-app assistant cite the exact setup-plan line that explains why a controller, external synth, or SysEx recall path is not ready.

2026-06-30 - SysEx Vault Reports Are Librarian Receipts

Task: Move SysEx Vault clipboard report text out of the editor and into the MIDI model layer.

What connects creatively: A SysEx dump is not just data; it is a promise that SpaceAge can help a musician restore an external device without panic. The report is therefore a librarian receipt: snapshot name, device/profile attachment, byte count, confirmation policy, safety class, checksum hints, send pacing, and preview bytes. Keeping that receipt beside the snapshot summary means the Vault, Hardware Passport recall plans, future bulk-dump workflows, support bundles, and the eventual AI/helper surface can all speak from the same facts.

Architecture choice: SysExSnapshotSummary::toPlainTextReport() owns per-snapshot prose, and sysExSnapshotSummariesToPlainTextReport() composes the full Vault report. PluginEditor only copies the model report.

Future extensions: Add selected-snapshot copy, batch bulk-dump receipt generation, before/after hardware restore logs, per-passport restore history, device-specific response reports, and support bundles that include SysEx Vault state without requiring a user to manually summarize their hardware librarian setup.

2026-06-30 - Timing Calibration Graduates From Missing To First UI

Task: Update MIDI Protocol Coverage so Hardware Output Timing reflects the manual and loopback calibration workflow that now exists.

What connects creatively: Latency is one of those invisible details that can make a musician distrust an otherwise beautiful instrument. Once SpaceAge can send safe timing pulses, capture returns, store compensation on a Hardware Passport, and print a timing receipt, that feature is no longer imaginary. Calling it "first calibration UI" keeps the product honest while still admitting the polish we owe: apply/recalibrate clarity, deeper jitter warnings, and real-device validation.

Architecture choice: Keep the coverage row as the single truth source for backend readiness, UI readiness, confirmation needs, and product blockers. Hardware timing now moves from product blocker to polish target because the essential musician-facing path exists, but its next action still points at the remaining refinement.

Future extensions: Add a more beautiful timing wizard with animated pulse progress, device-specific calibration receipts, jitter trend history, and an explicit "apply this compensation to recording" action that never hides a timing mutation from the user.

2026-06-30 - Routing Preflight Has A First Cockpit

Task: Update MIDI Protocol Coverage so Routing, Devices, and Preflight acknowledges the Settings panels and setup-scenario guide that already exist.

What connects creatively: A MIDI setup helper is not one panel; it is a chain of small truths: what input is open, what output exists, what lane is armed, what hardware passport knows, what timing says, and what next action is safe. Marking this as first UI recognizes that SpaceAge now has a cockpit, even though it still needs autopilot-style profile creation and device-specific recipes.

Architecture choice: Keep blocksProductReady=true because the current UI inspects and routes the user to panels, but does not yet fully create the hardware profile/channel/template setup for them. The scorecard can say "visible and useful" without pretending it is finished.

Future extensions: Add one-click scenario setup for keyboard controllers, MIDI guitars, wind controllers, drum pads, external synth modules, and multitimbral workstations. Those recipes should create profiles, assign channel filters, recommend timing calibration, and leave a copyable receipt.

2026-06-30 - MIDI Learn Has A First Mapping Surface

Task: Update MIDI Protocol Coverage so MIDI Learn reflects the actual MIDI Maps editor instead of calling response curves and range editing future work.

What connects creatively: MIDI Learn is where hardware becomes personal. Once the user can search targets, arm a mapping, move a controller, invert it, narrow its range, shape its response curve, and delete the assignment, SpaceAge has crossed from backend capability into a real teaching surface. The remaining magic is making it faster and more obvious: click the knob, move the hardware, resolve conflicts gracefully.

Architecture choice: Mark uiReady=true but keep blocksProductReady=true. That says the current editor is legitimate, while still protecting the product promise around direct control-click learning, remap/replace flow, richer high-resolution details, and friendly conflict repair.

Future extensions: Let any visible knob or slider enter learn mode directly, show live incoming values while learning, offer "replace existing mapping" when conflicts occur, and reuse the same mapping surface for internal synths, effects, VST parameters, Motion Clips, and hardware macro controls.

2026-06-30 - MIDI Export Has A First Doorway

Task: Update MIDI Protocol Coverage so MIDI File Export acknowledges the first Render/Export UI and stem-package path that already exist.

What connects creatively: Export is where SpaceAge leaves the room and collaborates with the outside world. A stem package with manifests, checksums, receipts, and validation is more than a file writer; it is the beginning of a collaboration contract. The UI is not fully polished yet, but the user already has a visible doorway into that contract.

Architecture choice: Mark export uiReady=true because warning review, job plans, and package choice exist, but keep blocksProductReady=true until progress bars, package/zip polish, visible import/repair, and broader real-project validation are finished.

Future extensions: Add a full Render/Export cockpit with progress, queue history, checksum validation, repair suggestions, one-click zip packaging, stems by lane/group, and direct support receipt copying.

2026-06-30 - MIDI Import Has A First Gate

Task: Update MIDI Protocol Coverage so MIDI File Import acknowledges the selected-pattern and split-channel import UI that already exists.

What connects creatively: Import is where outside musical history enters SpaceAge. The first gate already asks the right safety questions: which lanes, which channels, what expression to preserve, what setup data to quarantine, and what receipt to leave behind. That is real UI, even though the grander wizard still owes tempo-map adoption and deeper device-setup choices.

Architecture choice: Mark import uiReady=true while leaving blocksProductReady=true. The user can import safely today, but the product should not claim complete MIDI-file mastery until tempo/meter/key maps, setup-data decisions, and broader real-world MIDI validation are finished.

Future extensions: Add a true import cockpit with visual channel previews, tempo/meter/key adoption, per-channel instrument suggestions, hardware setup recipe creation, SysEx vault routing, and a plain-language import receipt.

2026-06-30 - RPN/NRPN Cards Need Receipts Before They Become Editors

Task: Add model-owned plain-text reports to RPN/NRPN setup-controller summaries.

What connects creatively: RPN and NRPN data is where MIDI stops looking like "notes and knobs" and starts looking like hardware dialect. A card that says "Pitch Bend Range, channel 2, parameter 14-bit 0, Data Entry 1570, ready" is far less intimidating than raw CC 101/100/6/38 rows. Giving each card its own receipt turns setup data into a supportable, explainable object before we let users edit or transmit it.

Architecture choice: MidiSetupControllerSummary::toPlainTextReport() owns the card report and serializes it through plainTextReport. UI, import review, hardware profiles, and future setup editors can copy the same interpretation instead of parsing display text or rebuilding prose.

Future extensions: The selected-card COPY CARD button now exists in MIDI PATCH, so the next creative step is making those copied receipts part of larger hardware setup workflows: editable cards for known RPNs such as pitch-bend range and tuning, device-specific NRPN maps in Hardware Passports, and guarded "attach to profile" / "send to hardware" actions with explicit confirmation.

2026-06-30 - Hardware Passports Can Carry Setup Receipts Before They Send Setup Data

Task: Add a guarded backend helper that appends an RPN/NRPN setup-card receipt to a Hardware Passport's notes.

What connects creatively: Hardware setup data is half instruction manual, half memory aid. Before SpaceAge can responsibly edit and transmit every RPN or device-specific NRPN, it can still help a musician remember that a MIDI file contained "Pitch Bend Range on channel 4" or a device setup value worth preserving. Appending the card receipt to the Hardware Passport turns imported setup traffic into a durable note attached to the right external instrument, without pretending it is an executable preset recall.

Architecture choice: appendMidiSetupCardReportToHardwareProfile() lives in the processor and accepts the model-owned MidiSetupControllerSummary. It appends the receipt to HardwareMidiProfile::notes, rejects missing profiles, and avoids duplicate receipt blocks. No MIDI is sent.

Future extensions: Add a visible attach action from either MIDI PATCH or the Hardware Passport detail pane, graduate known RPNs into editable cards, allow device-specific NRPN dictionaries, and require explicit confirmation before any setup-card data can be sent to hardware.

2026-06-30 - Hardware Passports Should Advertise Their Receipts

Task: Surface setup-card receipt counts and note previews in Hardware Passport summaries.

What connects creatively: Once a Hardware Passport can carry a setup receipt, the next humane step is letting the app notice it. A profile card that can say "this external synth already has one setup-card receipt attached" turns hidden notes into visible confidence. That same fact can later drive support exports, setup wizards, hardware recall preflights, and a friendly warning before importing duplicate setup data.

Architecture choice: Add setupCardReceiptCount, hasSetupCardReceipts, and notesPreview to HardwareMidiProfileSummary. The summary layer counts the model-owned SpaceAge RPN/NRPN Setup Card marker and never transmits hardware data.

Future extensions: Show receipt badges in Hardware Passports, add a one-click "view attached setup cards" surface, and let setup-card receipts graduate into explicit editable/safe-send hardware recipes when the device profile has enough parameter knowledge.

2026-06-30 - Setup Cards Need A Safe Attach Button Before They Need A Send Button

Task: Add a MIDI PATCH action that attaches a selected RPN/NRPN setup-card receipt to the current lane's existing Hardware Passport.

What connects creatively: RPN/NRPN setup data can be important, but it is also easy to make scary. A safe attach action lets a musician preserve the meaning of a setup card beside the external instrument it belongs to, without turning that preservation into a send operation. It is a bridge between import review and hardware librarian workflow: SpaceAge remembers what the file was trying to set up, but the user remains in charge of whether it ever reaches the synth.

Architecture choice: ATTACH CARD reuses the selected Arrangement lane target and requires that lane to already have a Hardware Passport. It calls the guarded processor helper that appends the model-owned plain-text card report to profile notes, avoids duplicate blocks, and sends no MIDI.

Future extensions: Display attached cards in Hardware Passport detail, allow known setup cards to become editable recipes, add device-specific NRPN dictionaries, and only then offer a separate confirmed SEND SETUP workflow.

2026-06-30 - Receipt Counts Need Human Labels, Not Just Numbers

Task: Add a compact setup-card receipt preview to Hardware Passport summaries.

What connects creatively: A count is useful, but it still makes the user ask, "one setup card for what?" Extracting a short label such as CH 04 Pitch Bend Range lets Hardware Passports advertise their useful memory in plain language. This is the same design logic as clip thumbnails and chord labels: the app should show enough context to reduce guessing without forcing a full detail panel.

Architecture choice: HardwareMidiProfileSummary now carries setupCardReceiptPreview, derived from the same model-owned plain-text receipt that is stored in profile notes. The summary builder extracts channel and parameter labels without sending MIDI or reinterpreting raw controller messages.

Future extensions: The same preview labels can become clickable receipt chips in the Hardware Passport editor, feed support bundles, and eventually map into editable "safe send" setup recipes once device-specific RPN/NRPN knowledge exists.

2026-06-30 - MIDI Setup Scenarios Need Template Intent Before Automation

Task: Add channel, expression, hardware, and automation-hint metadata to the reusable MIDI setup scenarios.

What connects creatively: A good setup wizard should feel like a calm assistant, not a form generator. A MIDI guitarist, wind-controller player, drum-pad performer, and QY-style module owner all need different defaults, but those defaults should be visible before SpaceAge starts offering one-click automation. Template labels let the current guide say, "this is the shape of the setup," while automation hints let future code grow into lane-arm, pad-learn, per-string, breath-curve, timing-calibration, and hardware-profile shortcuts without inventing a separate hidden playbook.

Architecture choice: MidiHardwareSetupScenario now carries read-only template labels plus automationHints, serializes them through toVar(), prints them through the model-owned plain-text report, and shows them in the selected MIDI SETUP detail strip. Nothing mutates project state, arms lanes, sends MIDI, or creates profiles from these hints yet.

Future extensions: Turn the hints into explicit wizard actions one at a time: create selected-lane hardware profiles, offer six-string channel templates, trigger pad-learn mode, default wind-controller lanes to breath expression visibility, and prompt for timing calibration only after a safe hardware note has been proven.

2026-06-30 - Fixed MIDI Channels Need Explanation, Not Panic

Task: Add a neutral channel-filter note to MIDI input readiness reports.

What connects creatively: One of the easiest live-MIDI failures is also one of the most legitimate setups: the lane is listening to channel 3, but the controller is transmitting on channel 1. That should not be colored as a broken project, because fixed channels are essential for multitimbral rigs, MIDI guitar, hardware modules, and multiple controllers. The humane move is to explain the filter in every copied report so support, future AI help, and the user can immediately see the rule.

Architecture choice: MidiInputReadinessReport now owns inputChannelFilterNote, serializes it through toVar(), and prints it in the model-owned plain-text report. It is not added to warnings, so deliberate fixed-channel routing remains clean.

Future extensions: Once SpaceAge stores last-observed incoming channels per input device, this note can become an actionable diagnosis: "I heard channel 1, but this lane only accepts channel 3. Switch the lane to Omni, change the controller transmit channel, or use MIDI Learn."

2026-06-30 - MIDI Should Report What It Actually Heard

Task: Add live observed-input-channel telemetry to MIDI readiness without changing routing behavior.

What connects creatively: The difference between "SpaceAge heard my controller" and "the armed lane accepted my controller" is the exact kind of invisible state that makes hardware feel hostile. Recording the recent channel mask before filtering lets the app say, "I heard CH 01, but this lane accepts CH 03," which turns a mysterious silence into a solvable setup mismatch.

Architecture choice: The processor now records channel-message traffic in a lightweight atomic mask before armed-lane input filtering. MidiProjectReadinessReport carries that raw observation, and MidiInputReadinessReport interprets it as a readable label plus a mismatch warning when appropriate. SysEx, MIDI Clock, SPP, MMC, MTC, and Active Sense do not pollute the channel mask.

Future extensions: Add a reset button for observed input channels, record last-observed input device identity when JUCE exposes it cleanly, and let the future MIDI Setup wizard offer one-click fixes: switch lane to Omni, match the lane channel to the controller, or create a multitimbral template from the observed channels.

2026-06-30 - Channel Mismatches Should Become Guided Repairs

Task: Convert observed MIDI input channel mismatches into a device-repair recommendation.

What connects creatively: A musician should not have to understand the difference between "MIDI reached the app" and "MIDI passed the lane filter" while trying to perform. Once SpaceAge can hear that recent traffic arrived on CH 01 while the armed lane accepts CH 09, the next humane move is to make that fact actionable: open the lane MIDI input surface and let the user choose Omni, match the lane channel, or adjust the controller.

Architecture choice: MidiDeviceRepairRecommendationKind::adjustInputChannelFilter is a guided warning, not an auto-fix. It uses the same repair model as missing devices and dropped output messages, so MIDI Health, MIDI Input, setup assistants, support reports, and future AI help can all quote one shared diagnosis.

Future extensions: Add safe one-click repair choices after the current non-mutating path is proven: Switch armed lane to Omni, Set lane to observed channel, or Create multitimbral lane template from observed channels, each with clear undo and no surprise routing changes.

2026-06-30 - Diagnostic Memory Needs A Broom

Task: Add a reset path for recently observed MIDI input channels.

What connects creatively: A diagnostic that remembers what it heard is useful until it starts feeling haunted. MIDI users often swap controllers, change transmit channels, or test a cable and then move on. A RESET OBSERVED button makes the channel monitor feel like an intentional troubleshooting tool rather than a mysterious historical record.

Architecture choice: The processor owns resetObservedMidiInputChannels(), clearing only the lightweight observed-channel mask. The MIDI Input popup calls that method, refreshes the model-owned input report and repair recommendations, and repaints without changing lane routing, recording, playback, or MIDI Learn.

Future extensions: Add a timestamp/age label for observations, per-device observed-channel memory when device identity is available, and a guided setup action that says "I just heard CH 04; do you want this lane to listen to CH 04?"

2026-07-01 - Short Reports Should Carry The Useful Clue

Task: Add recently observed MIDI input channels to the compact MIDI Health next-steps report.

What connects creatively: The full health report is for support archaeology; the short report is for the musician standing in front of a controller wondering why no note arrived. Putting "Observed input channels: CH 01" near the top of COPY STEPS makes the most actionable clue visible without forcing the user through a protocol dump.

Architecture choice: The next-steps text still comes from MidiProjectHealthSummary, not the editor. It reads the shared readiness model and adds a small comparison hint, leaving the lane filter, repair recommendations, and reset behavior owned by the existing MIDI input/reporting path.

Future extensions: When SpaceAge can reliably identify the physical input device for each observation, include "heard CH 01 from MiniNova" and let guided setup offer guarded actions such as Set armed lane to observed channel or Create a channel template from observed traffic.

2026-07-01 - Setup Should Say "I Heard You"

Task: Add observed input-channel evidence to MIDI Setup assistant plans.

What connects creatively: The first emotional hurdle in hardware setup is proof of life. If a musician plays a controller and SpaceAge can say "Recent MIDI was observed on CH 02," the setup guide becomes a calm stage tech instead of a checklist. That clue belongs in controller, wind, guitar, drum-pad, and external-synth setup, not only in a diagnostic panel.

Architecture choice: The assistant reuses MidiInputReadinessReport instead of observing MIDI directly. Matching observed channels become a completed checklist row; observed traffic blocked by a fixed lane filter becomes a non-mutating repair row that opens the lane MIDI input surface.

Future extensions: Convert the observed-channel row into a guided setup decision: Use Omni while composing, Match lane to observed channel, Create per-channel lane template, or Keep fixed channel and ignore this traffic.

2026-07-01 - 14-Bit Honesty Before 14-Bit Magic

Task: Add high-resolution CC pair awareness to MIDI Learn summaries without changing runtime mapping math yet.

What connects creatively: Expensive hardware often feels expensive because its knobs and faders send more precise data. MIDI 1.0 does this with coarse/MSB CC 0-31 and fine/LSB CC 32-63 pairs, but setup controllers such as Bank Select and Data Entry live in the same numerical neighborhood. The humane design move is to recognize the pair relationship, warn when the user learns only the fine half, and avoid pretending paired smoothing is finished.

Architecture choice: MidiControlMapping remains the single learn contract. The shared MIDI layer now exposes helper functions for learnable 14-bit CC MSB/LSB relationships, and assignment summaries serialize the companion controller number plus the explanatory note. Runtime pair state now lives inside the processor and only activates for learned MSB mappings when matching LSB traffic is observed, so plain 7-bit controllers still behave normally.

Future extensions: Add an explicit high-resolution pair mode UI that smooths paired values, shows a live 14-bit meter in MIDI Maps, and lets users choose between coarse-only reliability and paired precision.

2026-07-01 - Companion Clues Belong In The Row

Task: Surface 14-bit MIDI Learn companion-controller information inside the Settings MIDI Maps assignment row.

What connects creatively: MIDI Learn is where a user is already asking, "What did SpaceAge just hear from my hardware?" If the row merely says 14-bit MSB, it leaves the musician with trivia. Saying "fine companion CC 33" turns the same data into a small teaching moment and prepares the app for true high-resolution pair mode later.

Architecture choice: The UI reuses MidiControlAssignmentSummary instead of inventing display-only MIDI parsing. Warnings remain authoritative for risky LSB-only mappings, while clean MSB mappings replace the generic compact label with a short companion note in the existing row note line.

Future extensions: This same row can become a stateful mini-meter: coarse value, fine value, merged 14-bit value, and a toggle for coarse-only versus paired precision.

2026-07-01 - Let Expensive Knobs Feel Expensive

Task: Add automatic runtime merging for learned 14-bit MIDI CC pairs.

What connects creatively: A hardware fader that sends MSB/LSB data should feel smoother without forcing the user through a thesis on MIDI controller pairs. The musician learns the obvious controller, SpaceAge notices the fine companion when it arrives, and the mapping quietly becomes more precise.

Architecture choice: The processor keeps a per-channel, per-controller MSB/LSB cache under the existing MIDI mapping lock. Learned MSB mappings still respond normally to 7-bit traffic when no LSB has been observed; once the fine half arrives, the mapped value is calculated from the merged 14-bit number. Orphan LSB traffic does not mutate targets.

Future extensions: Add a MIDI Maps meter showing coarse/fine/merged values, optional smoothing for noisy controllers, and a user-facing control for forcing coarse-only mode when a piece of hardware sends odd or unstable fine data.

2026-07-01 - MIDI Maps Needs Proof Of Life

Task: Add a first-pass live activity meter to MIDI Maps assignment rows.

What connects creatively: MIDI setup becomes less spooky when the app visibly reacts to the hand. The same trust principle behind observed input channels, timing reports, SysEx progress, and Arrangement clip animation applies here: when the user moves a controller, SpaceAge should calmly say, "I heard that." This turns MIDI Learn from a hidden table into a living cockpit.

Architecture choice: The processor stores lightweight runtime activity beside each MIDI control mapping: normalized value, mapped value, serial, and active flag. Assignment summaries serialize those live fields so the editor draws from the model instead of re-parsing incoming MIDI. The MIDI Maps panel refreshes row summaries while open, but the live meter is intentionally non-persistent.

Future extensions: Split the single meter into explicit coarse/fine/merged 14-bit display, add pickup/soft-takeover indicators, expose conflict repair, and reuse the same mini-meter language for VST parameter learn, Motion Clips, and hardware macro controls.

2026-07-01 - Repair Should Not Punish Creativity

Task: Add safe exact-duplicate repair for MIDI Maps.

What connects creatively: A hardware knob controlling two parameters can be a feature, not a bug. That same one-to-many idea will eventually power macro controls, VST assignments, Motion Clips, and performance gestures. The repair path therefore needs to clean up accidental duplicate rows without teaching SpaceAge to erase intentional expressive routing.

Architecture choice: removeDuplicateMidiControlMappings() removes only mappings with the same enabled state, source, and target, keeping the first row. The MIDI Maps REPAIR button activates only when the dashboard reports exact duplicate source-target mappings. Broader choices such as Replace Hardware Source, Add as Macro, and Cancel belong to the direct-control learn workflow, where the user is already declaring intent.

Future extensions: Add a dedicated macro assignment model, soft takeover/pickup indicators, richer direct-control learn dialogs, and a conflict browser that distinguishes exact duplicates from intentional creative mappings.

2026-07-01 - Replace Existing Is A Consent Moment

Task: Add the processor primitive for future MIDI Learn source replacement.

What connects creatively: A reused hardware knob can mean two opposite things: "I changed my mind; replace the old assignment" or "I want one gesture to move several things." Those are workflow intentions, not technical accidents. The app should ask which one the musician means, then execute that decision cleanly.

Architecture choice: removeMidiControlMappingsForSource() removes mappings with the same MIDI source while keeping the explicitly chosen mapping. It is backend-only for now, so direct-control learn UI can later present Replace Existing, Add as Macro, and Cancel without rewriting the cleanup logic in the editor.

Future extensions: Add a conflict preview panel that lists the existing targets for the touched source, a macro assignment browser, and soft takeover/pickup behavior so replacement does not cause parameter jumps during performance.

2026-07-01 - KEEP Means Preserve The Intentional Row

Task: Expose source replacement safely inside MIDI Maps.

What connects creatively: In a row-based mapping table, KEEP describes the musician's intent better than a vague replace: "this row is the one I want." That matters because MIDI setup is abstract enough already. The button should make cleanup feel deliberate, not scary.

Architecture choice: MIDI Maps enables KEEP only when another mapping uses the same MIDI source. The editor calls removeMidiControlMappingsForSourceOfMapping(), keeping the actual source comparison in the processor instead of cloning MIDI cleanup rules in the UI.

Future extensions: Direct knob-click learn can use the same model with friendlier choices: Replace Existing, Add as Macro, and Cancel. Macro mappings can later become a visible performance feature rather than a confusing table condition.

2026-07-01 - Right Click The Thing You Mean

Task: Add first-pass direct-control MIDI Learn for APVTS-backed sliders.

What connects creatively: MIDI Maps is powerful, but hunting through a target list interrupts the body-memory flow of sound design. A musician looking at a cutoff knob should be able to say, "learn this," right there. That same interaction language can later serve VST parameters, Motion Clips, instrument macros, and hardware control surfaces.

Architecture choice: The editor adds a reusable mouse-listener binding to controls already tied to APVTS parameter IDs. Right-click or Ctrl+Alt-click opens a context menu that arms the existing processor-owned MIDI Learn request for the canonical param: target. Nothing bypasses MIDI Maps; the learned mapping still appears in the same table and inherits duplicate repair, KEEP, 14-bit pairing, and live activity meters.

Future extensions: Extend the binding to ComboBox, ToggleButton, TextButton, custom graph nodes, and VST parameter surfaces. Add the direct conflict dialog: Replace Existing, Add as Macro, and Cancel, backed by the source-cleanup primitive already in the processor.

2026-07-01 - Pickup Makes Hardware Feel Polite

Task: Add first-pass per-mapping PICK soft takeover for MIDI Learn assignments.

What connects creatively: Hardware knobs, faders, and expression controls often wake up in a different physical position than the saved SpaceAge project value. Without pickup, the first touch can yank a carefully mixed parameter somewhere ugly. With pickup, the control has to pass through the software value first, which makes external hardware feel more like it is shaking hands with the project instead of barging into the room.

Architecture choice: Pickup belongs on MidiControlMapping, not on a particular UI widget. The processor keeps transient per-mapping pickup state beside live activity meters, so the same behavior applies whether the mapping came from MIDI Maps, direct right-click learn, future VST learn, or a hardware-profile template. The UI exposes the feature as a row-level PICK toggle, and summaries report when a mapping is waiting for pickup.

Future extensions: Add global defaults for new mappings, a visible "waiting for pickup" micro-indicator beside mapped controls, and a guided hardware-control setup flow where SpaceAge recommends pickup automatically for absolute knobs but leaves relative encoders immediate.

2026-07-01 - Direct Learn Spreads Beyond Sliders

Task: Extend first-pass direct-control MIDI Learn beyond sliders into supported APVTS-backed dropdowns and toggles.

What connects creatively: A hardware assignment workflow feels best when the user can stay where their eyes already are. If the musician is staring at a Redshift waveform selector, a gate pattern dropdown, a Lunacy freeze toggle, or an effects enable switch, the app should let that visible object become the learn target without sending the user back to Settings. That reinforces SpaceAge's larger workflow language: the interface teaches through direct manipulation, and the deeper MIDI machinery remains calmly underneath.

Architecture choice: The editor continues using the same param: target registry and the same processor-owned MIDI Learn arming path. Dropdowns and toggles do not get a special mapping system; they become additional components bound to known APVTS parameter ids. Learned mappings still appear in MIDI Maps, still inherit pickup, high-resolution CC awareness, duplicate repair, and source cleanup.

Future extensions: Add direct learn to every remaining APVTS-backed ComboBox/ButtonAttachment surface, expose an inline "already mapped" indicator, and add conflict prompts for replace/add-as-macro/cancel when a direct-learn source already drives another target.

2026-07-01 - Direct Learn Gets A Replace Target Choice

Task: When direct MIDI Learn is invoked on a control that already has mappings, surface that fact and offer a focused replacement path.

What connects creatively: MIDI setup should feel like a patchbay, not a trap. Sometimes a musician wants one hardware knob to keep controlling several things as a macro. Other times they are simply changing their mind about what controls a visible parameter. Naming those choices at the moment of learning prevents mysterious duplicate mappings later.

Architecture choice: The processor now owns removeMidiControlMappingsForTarget(), a narrow helper that removes mappings aimed at one target while preserving unrelated mappings and activity-state alignment. The direct-learn popup uses it only when the user chooses Replace This Control's Mapping; the normal learn action remains additive. Source-level macro cleanup still stays in the existing KEEP/source-replacement path.

2026-07-01 - One Knob Can Mean Replacement Or Macro

Task: Bring source-conflict intent into direct-control MIDI Learn.

What connects creatively: A hardware control is a physical gesture. Sometimes the user is saying, "this knob is now cutoff." Sometimes they are saying, "this knob should sweep cutoff and delay return together." Those are both musically valid, so the interface should name the fork instead of hiding it in a mapping table.

Architecture choice: MidiLearnRequest now carries a replaceExistingSourceMappings flag. Direct-control learn defaults to the ordinary musician expectation, Replace Hardware Source, while Add as Macro preserves older mappings from that same source. The processor performs the cleanup after the learned source is known, using the same source-comparison helper already exposed by MIDI Maps.

Future extensions: Expand the post-capture receipt into a full conflict preview listing the exact older targets before capture. Later, macro mappings can become a named performance feature with saveable macro presets, pickup defaults, smoothing, and visible control-surface feedback.

2026-07-01 - Macro Sources Should Be Visible, Not Suspicious

Task: Make MIDI Maps explicitly label one hardware source controlling multiple targets.

What connects creatively: A single hardware knob sweeping filter cutoff, reverb return, and wavetable position is not merely a MIDI table oddity; it is the seed of SpaceAge macro performance. The same idea can later connect to Motion Clips, VST parameter learn, control-surface pages, and live hardware presets.

Architecture choice: Assignment summaries now carry a sharedSourceTargetCount, and the dashboard separately counts macro sources and macro assignments. Exact duplicate source-target rows remain repair-worthy, but one source feeding different targets becomes MACRO SOURCE row metadata.

Future extensions: Let users name a macro source, save it as part of a control-surface preset, add response curves per destination, and expose a single macro lane for automation/Motion Clips.

2026-07-01 - MIDI Learn Needs A Receipt

Task: Add a model-owned post-capture receipt for MIDI Learn.

What connects creatively: MIDI Learn is a trust ritual: the user moves a real object in the room and expects SpaceAge to understand the intention. If the app silently replaces old mappings or silently creates a macro, the hardware starts to feel haunted. A receipt turns the invisible patchbay move into plain language: "this knob now controls that," "one old target was removed," or "this is now a macro source."

Architecture choice: MidiLearnCaptureReceipt records the learned source, target, replacement mode, removed-source mapping count, target labels involved, resulting macro target count, and UI-ready summary/detail lines. The processor stores it beside the last learned mapping, clears it when a new Learn starts or is canceled, and MIDI Maps reads it without mutating the assignment table.

Future extensions: Expand the receipt into a full conflict preview with exact target names before capture, then let users name macro sources, set pickup defaults, and save macro maps as performance-control presets.

2026-07-01 - Hardware Setup Needs Real-World Names

Task: Add example hardware labels to MIDI setup scenarios.

What connects creatively: A scenario called "multitimbral module" is technically accurate, but a musician holding a QY-70, QY-100, MiniNova, EWI, or pad controller needs to recognize themselves immediately. Real device examples turn the guide from abstract protocol coverage into an inviting checklist. This also supports SpaceAge's future hardware-friendly marketing: the app is not merely "MIDI compatible"; it speaks in the names of the boxes people actually own.

Architecture choice: Example labels now live on MidiHardwareSetupScenario, serialize through the model, appear in copied setup reports, and are drawn in the selected scenario panel. They are deliberately descriptive only; the setup guide still never arms lanes, creates profiles, sends SysEx, or rewrites routing by itself.

Future extensions: Use these examples to seed searchable setup templates: "MiniNova", "QY-100", "EWI", "MPC pads", and so on. Later, a chosen template can pre-fill channel, bend-range, SysEx, and timing expectations while still requiring explicit confirmation before any hardware transmission.

2026-07-01 - Device Templates Turn MIDI Hardware Into A Guided Doorway

Task: Add a backend MIDI Device Template layer for recognizable hardware families.

What connects creatively: A musician does not usually think, "I need a multitimbral module setup scenario." They think, "I have a QY-100," or "I want my EWI to breathe into this synth." Searchable device templates let SpaceAge meet the user at that human phrase and translate it into lanes, channels, bend ranges, breath curves, hardware profiles, timing calibration, and SysEx safety. This same bridge can later feed Hardware Passports, MIDI import mapping, lane creation, support reports, and an onboarding wizard.

Architecture choice: MidiHardwareSetupDeviceTemplate is model-owned, serializable, searchable, and reportable, but non-mutating. It can describe MiniNova, QY/XG modules, GM modules, EWI/wind controllers, MIDI guitar, and MPC-style pads without creating routes or sending MIDI. That keeps the feature useful today while preserving the rule that hardware-affecting actions require explicit confirmation.

Future extensions: Add a visible "Search your hardware" field in MIDI SETUP, allow a template to pre-fill a new Hardware Passport draft, generate lane/channel stacks for multitimbral modules, seed breath/per-string expression defaults, and keep every send/route/create action behind a preview screen.

2026-07-01 - Show The Gear Names Where The User Is Looking

Task: Surface MIDI Device Template labels in the selected MIDI SETUP scenario and include template reports in COPY GUIDE.

What connects creatively: This is a small UI move with a big trust effect. A user who owns a MiniNova, QY-100, EWI, MIDI guitar, or pad controller should see that object reflected in the setup guide instead of translating "external synth" or "multitimbral module" from protocol-speak. It supports recognition rather than recall, one of the design principles Shane brought into the project.

Architecture choice: The UI only displays matching model-owned template labels and copies model-owned template reports. It does not create routes, profiles, channels, or SysEx send plans. That keeps the surface helpful while reserving actual hardware changes for a future preview/apply wizard.

Future extensions: Make the labels clickable once a template picker exists. A click should open a preview showing proposed lanes, channel routing, bend range, expression lanes, timing calibration, and profile fields, with a clear confirmation boundary before any state changes.

2026-07-01 - Pick The Device Without Touching The Hardware

Task: Add a read-only Device Template picker to the selected MIDI SETUP detail strip.

What connects creatively: The picker is a bridge between "I own this box" and "SpaceAge knows how this box tends to behave." That is the right emotional move for hardware users: confidence before commitment. It also gives us a reusable customer-facing pattern for future Instrument Bay and Hardware Passport flows: choose the thing, inspect the consequences, then apply only when the user explicitly says so.

Architecture choice: The UI now selects a nearest matching template when the scenario changes, lets the user browse all current templates, shows template focus/channel/expression detail, and copies only the selected template report through COPY TEMPLATE. It still does not create lanes, attach profiles, arm input, rewrite channels, perform timing calibration, or send MIDI.

Future extensions: Convert the picker into a preview wizard with proposed lane stacks, channel filters, bend range, expression lanes, Hardware Passport drafts, timing-calibration prompts, SysEx safety notes, and a final confirmation screen before any mutation.

2026-07-01 - Preview The Setup Before SpaceAge Acts

Task: Add a model-owned apply-preview object for MIDI Device Templates.

What connects creatively: Hardware setup is a confidence problem as much as a protocol problem. A preview lets SpaceAge say, "Here is what I would do for your QY-100 or EWI," while still keeping the user in command. The same preview/apply rhythm can later govern SoundFont remapping, VST setup, Instrument Bay lane creation, and even Quasar package import.

Architecture choice: MidiHardwareSetupDeviceTemplatePreview lists proposed actions, lanes, channels, expression handling, Hardware Passport work, timing prompts, warnings, and blocked mutations. It serializes and prints the plan, but its safety booleans make the current contract explicit: no lanes created, no routing rewritten, no profile created, and no MIDI sent from preview.

Future extensions: Render this preview in MIDI SETUP, then add guarded APPLY TEMPLATE only after the UI can show exactly which lanes/profiles/routes/timing records will be created and after Undo can cover the project-side changes.

2026-07-01 - Preview Where The User Can See It

Task: Expose the MIDI Device Template apply-preview in the MIDI SETUP popup.

What connects creatively: A report model is only useful if it appears at the decision point. Showing "will propose" and "blocked until apply" beside the device picker turns the template from reference copy into a guided rehearsal. This same UX pattern can later help Instrument Bay lane creation, SoundFont import repair, SysEx recall, and Quasar package loading: show the consequences first, then let the user commit.

Architecture choice: The MIDI SETUP strip now renders a compact preview from buildMidiHardwareSetupDeviceTemplatePreview() and changes the copy action to COPY PREVIEW. It still sends no MIDI, creates no lanes, attaches no Hardware Passport, and exposes no apply button.

Future extensions: Expand the compact preview into a full wizard step with side-by-side lane/channel/profile/timing diffs, then add one undoable APPLY TEMPLATE transaction once project mutations and hardware-send boundaries are fully designed.

2026-07-01 - Apply Must Be A Transaction, Not A Surprise

Task: Add a non-executable transaction-plan model for future MIDI Device Template apply.

What connects creatively: The deeper pattern here is "commitment architecture." A user can preview a hardware setup, but the moment SpaceAge starts creating lanes, assigning channels, attaching Hardware Passports, or adding timing prompts, the user deserves one named undo step. This same shape can govern future Instrument Bay imports, Quasar multisample creation, SoundFont repair, and VST hardware-control templates.

Architecture choice: MidiHardwareSetupDeviceTemplateApplyTransactionPlan translates a preview into project mutation steps, undo safety steps, blocked hardware sends, and warnings. It deliberately remains non-executable and reports that hardware sends are not part of the transaction. This keeps project edits and external device actions from being welded together.

Future extensions: Build one processor-owned apply helper that consumes this plan, opens a single UndoManager transaction, mutates only project state, and returns an apply receipt. Test notes, Program Change, Bank Select, MIDI Clock, transport, and SysEx recall should remain separate post-apply actions.

2026-07-01 - Receipts Keep Apply Honest

Task: Add a dry-run receipt model for future MIDI Device Template apply.

What connects creatively: A receipt is the musician-readable audit trail after a powerful action. If SpaceAge eventually says "I set up your QY-100," it should be able to prove exactly what it changed, what it skipped, and what it refused to send to hardware. That same pattern belongs in Quasar package builds, SoundFont repair, Instrument Bay lane creation, render/export, SysEx recall, and any future AI-assisted setup action.

Architecture choice: MidiHardwareSetupDeviceTemplateApplyReceipt serializes the apply plan, applied changes, skipped changes, blocked hardware sends, follow-up actions, warnings, and safety booleans. The current builder is deliberately a dry-run receipt: no project mutation, no hardware MIDI, and no undo entry.

Future extensions: When the real apply helper exists, populate the same receipt with created lane counts, changed routing counts, created Hardware Passport counts, expression-lane counts, and actual undo availability. Keep hardware sends in separate receipts so external gear never gets surprised by a project-side setup transaction.

2026-07-01 - Template Apply Starts As A Draft Passport

Task: Add the first processor-owned project-side Device Template draft apply helper.

What connects creatively: The safest useful first mutation is not "build the whole hardware studio for me"; it is "make a Hardware Passport draft and attach it where I can inspect it." That gives the user something concrete without turning SpaceAge into a hidden auto-router. This pattern also fits Instrument Bay, lane templates, and future external synth assistants: create a named project object first, then let the user decide when it becomes audible hardware routing.

Architecture choice: applyMidiHardwareSetupDeviceTemplateProjectDraft() requires explicit confirmation, creates one Hardware Passport draft, optionally attaches it to one lane, sets that lane's PLAY/EXPORT channel from the template, returns a receipt, and sends no MIDI. It now reports undo availability after creating both a normal project checkpoint and a processor rollback snapshot.

Future extensions: Expand the draft apply into a full setup wizard with lane-stack creation, expression-lane creation, timing prompt records, and one reviewed diff that covers every project-side mutation. Only after that should the Settings MIDI SETUP panel expose a normal APPLY TEMPLATE button.

2026-07-01 - Diffs Before Buttons

Task: Add a before/after diff model for MIDI Device Template project draft apply.

What connects creatively: SpaceAge should avoid surprise automation. A diff is the polite pause before a powerful helper touches a project: "Here is what I found, here is what I will change, here is what I refuse to send to your hardware." That same pattern belongs in Instrument Bay swaps, lane form presets, Quasar package builds, SoundFont repair, render/export, and any future AI setup assistant.

Architecture choice: MidiHardwareSetupDeviceTemplateApplyDiff serializes before rows, after rows, change rows, blocked hardware sends, undo status, and hardware-send status. The processor-owned diff helper reads the current target lane state, then delegates to the MIDI model so reports and UI previews share one source of truth.

Future extensions: Put this diff in the MIDI SETUP confirmation screen before APPLY TEMPLATE becomes visible. Once true UndoManager coverage exists, the diff should report the exact undo label and expose the receipt after apply so the user can compare "planned" versus "done."

2026-07-01 - Rollback Is The Seatbelt

Task: Add a processor-owned rollback snapshot for MIDI Device Template project draft apply.

What connects creatively: Hardware setup helpers should feel powerful without feeling spooky. A rollback slot is the seatbelt for that power: SpaceAge can help create a Hardware Passport draft and attach it to a lane, while still proving it can put the project back the way it found it. The same "snapshot before mutation" pattern belongs in Instrument Bay swaps, lane form presets, SoundFont repair, Quasar builds, and any future AI-assisted patch or setup action.

Architecture choice: The draft apply helper creates a normal project checkpoint, captures the Hardware Passport list and target lane state before mutation, then stores one rollback snapshot after a successful apply. Normal Undo and the rollback helper both restore profiles and lane routing/channel/profile state and send no hardware MIDI. This gives tests a real reversibility contract before the visible Apply Template flow exists.

Future extensions: The confirmation screen should show the diff first, then the apply receipt, then the normal Undo button should reverse the whole transaction with one label. The rollback helper can remain as a hidden test/support safety rail.

2026-07-01 - Apply Where The Diff Lives

Task: Expose MIDI Device Template project draft apply in the MIDI SETUP panel.

What connects creatively: The safest place to apply a powerful helper is beside the explanation of what it will do. The Device Template panel now follows a useful SpaceAge pattern: preview first, diff second, explicit confirmation third, receipt fourth. That pattern can become a house style for Instrument Bay swaps, SoundFont repair, Quasar package creation, render/export, lane form presets, and future AI-assisted setup.

Architecture choice: The UI keeps APPLY DRAFT beside the selected template and its diff, calls the processor mutation boundary only after confirmation, shows the receipt in the same panel, and lets the copy button include preview, diff, and receipt. The model/processor still own the facts: no hardware MIDI is sent, a normal checkpoint is created, and the rollback snapshot remains available for tests/support.

Future extensions: Turn the same preview/diff/apply/receipt pattern into a reusable component so dangerous actions across the app feel consistent. For full hardware setup, add a second explicitly labeled hardware-send phase rather than overloading the project-draft apply action.

2026-07-01 - Undo Where The Receipt Lives

Task: Add a visible UNDO DRAFT control to the MIDI Device Template apply receipt flow.

What connects creatively: If SpaceAge helps the user make a semi-automatic decision, the escape hatch should live in the same room as the decision. The MIDI SETUP panel now teaches this: choose a template, review the diff, apply the draft, read the receipt, and undo the draft without leaving the panel. This is calmer than burying reversal in a global command because it keeps the user's attention attached to the specific action they just took.

Architecture choice: UNDO DRAFT appears only after a successful draft apply with an undoable receipt. It asks for confirmation, calls the processor rollback helper, replaces the receipt with the rollback receipt, re-enables Apply Draft, disables itself, and sends no hardware MIDI. This keeps project mutation and rollback model-owned while the UI remains a clear cockpit.

Future extensions: Reuse this "receipt-local undo" pattern for Instrument Bay reassignment, SoundFont relinking, Quasar capture/package writes, clip form presets, and any future AI-assisted action that changes project state.

2026-07-01 - Target Lane Before Touching The Project

Task: Make MIDI Device Template draft apply ask where the draft should land before mutating project state.

What connects creatively: A setup assistant becomes calmer when the target is visible. "Profile only" is useful for planning; "apply this to Lane 6" is useful for action. That same split belongs in Instrument Bay swaps, lane form presets, SoundFont repair, and future AI helpers: first decide whether the assistant is creating a reusable object or attaching it to a living lane.

Architecture choice: The MIDI SETUP panel now owns a target picker populated from the readiness report's lane summaries. It defaults to the selected Arrangement lane, falls back to the armed MIDI-input lane, and otherwise stays profile-only. The preview, diff, confirmation, apply receipt, copy report, and rollback all follow the same visible target.

Future extensions: Promote this pattern into a reusable "target before action" control for any feature that can either create a reusable project object or attach it to a timeline/lane surface.

2026-07-01 - Song Metadata Is A Flight Plan Choice

Task: Expose MIDI Import Wizard song metadata policy instead of hardcoding "keep current project."

What connects creatively: Tempo maps, meter changes, and key signatures are not just trivia in a MIDI file; they are the imported song's flight plan. SpaceAge should let a musician see that flight plan and choose whether it stays informational or eventually takes over the project timeline. This connects MIDI import, Arrangement form, future score export, Chord Engine key awareness, and collaborator handoff because all of those features need to agree about what "the song's tempo/key" actually means.

Architecture choice: The Import Wizard now has a visible metadata policy selector that feeds the existing request/result model. The receipt names the selected policy. First source tempo/key adoption is now a real processor path; source meter and full tempo/key map adoption remain review-only until undo-safe project timeline-map mutation exists.

Future extensions: Add a dedicated metadata preview page with the first tempo, meter, and key rows; then implement undo-safe adoption of first source values, full tempo/meter/key maps, or a separate review-only form lane. The same policy surface can later support "transpose imported notes to current key" and "create Section markers from imported markers."

2026-07-01 - Sync Copy Should Tell The Truth Precisely

Task: Tighten MIDI Sync panel wording so clock/transport Passport roles are not confused with SysEx send confirmations.

What connects creatively: Hardware MIDI feels dangerous when the app uses vague safety language. A musician needs to know which actions are merely navigation, which actions authorize playback sync, and which actions can transmit potentially destructive data to a device. Precise copy is part of the workflow architecture: it lets MIDI Sync, Hardware Passports, SysEx Vault, MIDI Out preflight, and future hardware setup assistants speak one language.

Architecture choice: Keep mutation authority in Hardware Passports and keep the MIDI Sync panel as a preflight/report surface. The panel now distinguishes explicit clock/transport Passport roles from SysEx confirmations, matching the backend split between runtime transport/clock scheduling and confirmation-gated SysEx/recall traffic.

Future extensions: Reuse the same wording pattern in MIDI Setup receipts and hardware profile cards: "role chosen," "ready to send during playback," "requires confirmation," and "navigation only" should each mean exactly one thing across the app.

2026-07-01 - MIDI Import Metadata Must Be Honest Before It Is Powerful

Task: Turn the MIDI Import Wizard's first source tempo/key adoption choice into a real processor apply path while keeping meter and full tempo-map/key-map adoption review-only.

What connects creatively: Imported MIDI metadata is not trivia; it is the skeleton of somebody else's session. SpaceAge can safely borrow the first tempo and key today because those already have obvious homes in the project. Full tempo maps, meter maps, and key maps are more like Arrangement form data: adopting them can reshape the song's timeline, so they need a deliberate future model rather than a hidden import side effect.

Architecture choice: First-value adoption now uses the processor mutation boundary and one undo checkpoint with the selected-pattern import path. Receipts say exactly what changed: first source tempo, first source key, and a warning when source meter was only reviewed. ADOPT FULL MAPS is renamed as a review-only intent until SpaceAge has an undo-safe timeline map.

Future extensions: Build a project timeline-map model, then let MIDI import create a preview of tempo/meter/key changes before adoption. That same model can later support score export, tempo automation, form-aware Arrangement editing, imported marker tracks, and Chord Engine key transposition.

2026-07-01 - Full Source Maps Are Receipts Before They Are Timeline Edits

Task: Carry full imported tempo, meter, and key map rows into MIDI import apply receipts while keeping them review-only.

What connects creatively: A MIDI file can arrive with a whole compositional flight plan: accelerandos, meter changes, key changes, and timing-format clues. SpaceAge should preserve that intelligence for the user without pretending the Arrangement timeline can safely absorb it yet. The same receipt data will later feed a dedicated timeline-map editor, score export, Chord Engine key-map awareness, collaborator handoff, and import repair reports.

Architecture choice: MidiImportApplyResult now carries reviewed tempo/meter/key map lines. Selected-pattern and split-channel import paths both populate those rows when song metadata review is enabled. The UI says REVIEW FULL MAPS, and receipts add a Full source map review row plus a warning that full map adoption is not active yet.

Future extensions: Promote reviewed maps into a visible metadata preview table with adopt/ignore/preserve choices, then wire map adoption into one undo-safe project timeline transaction.

2026-07-01 - MIDI Scorecards Must Reward Partial Truth Without Hiding The Blocker

Task: Update the MIDI Protocol Coverage model so Tempo/Meter/Key Maps reflect the new review-ready and first-adoption reality while still blocking product readiness on full timeline-map mutation.

What connects creatively: A scorecard that only says "not ready" after real progress becomes discouraging and vague. A scorecard that says "done" before full timeline maps exist becomes dangerous. The right middle state is useful to both of us: SpaceAge can now inspect map rows, keep them in receipts, and adopt first tempo/key, but it still owes the big musical model for full tempo/meter/key maps.

Architecture choice: The Tempo/Meter/Key Maps coverage row now reports backend-ready and first UI-ready while keeping blocksProductReady true. This makes the MIDI Dashboard more honest: it rewards the completed review/adoption-partial work without letting the release checklist forget the remaining timeline-map editor.

Future extensions: Use this pattern for every MIDI family: separate recognition, preservation, first UI, partial mutation, and product-ready confidence instead of flattening everything into one vague yes/no.

2026-07-01 - MIDI Receipts Should Not Undersell Reversibility

Task: Remove stale Device Template draft-apply wording that implied normal Undo support was still future-only.

What connects creatively: The MIDI setup assistant is a trust machine. If SpaceAge says a hardware template draft can be undone, the receipt should say that plainly and consistently. Otherwise the user may believe UNDO DRAFT is a special escape hatch while the main Undo button is unsafe, even though both paths now restore the project-side Hardware Passport/lane changes.

Architecture choice: Keep the processor rollback snapshot because it anchors the focused UNDO DRAFT button in the same MIDI SETUP panel, but let the receipt acknowledge normal Undo as well. The UI can therefore offer a contextual reversal without contradicting the global project history.

Future extensions: Apply this same "receipt tells the exact reversal story" rule to MIDI stem package import, SysEx Vault edits, future Hardware Passport sends, and any AI-assisted setup actions.

2026-07-01 - RPN Setup Cards Should Interpret, Not Just Preserve

Task: Add a read-only interpretation label to RPN/NRPN setup-card summaries.

What connects creatively: A setup card that says RPN MSB 0 / LSB 0 is technically accurate, but a musician needs to know that this means Pitch bend range. Translating known RPNs into ordinary language connects MIDI import, MIDI PATCH, Hardware Passports, future hardware setup assistants, and support reports without turning review data into a risky send operation.

Architecture choice: Keep raw selector/value fields as the source of truth, then layer interpretationLabel on top. Standard RPNs such as pitch-bend range, fine tuning, coarse tuning, modulation depth range, and RPN null get human explanations. NRPNs stay explicitly device-specific unless a future Hardware Passport supplies a definition map.

Future extensions: Let Hardware Passports define named NRPN dictionaries per device, then reuse the same interpretation field in setup cards, recall plans, SysEx vault notes, and guided hardware profiles.

2026-07-01 - Hardware Setup Should Preview The Exact CC Order Before It Ever Sends

Task: Add a guarded RPN/NRPN setup action-plan model that translates a selected setup card into the ordered Control Change messages SpaceAge would queue later.

What connects creatively: Hardware workflows become trustworthy when the user can see the recipe before the oven turns on. A pitch-bend-range setup card should not merely say "RPN 0"; it should reveal the exact CC101/CC100 selector, Data Entry MSB/LSB, and safety deselect sequence. This same preview-first idea connects SysEx restore, Hardware Passports, MIDI Learn remapping, future NRPN dictionaries, and old hardware setup wizards because each risky operation needs a visible "what will happen" stage before any send.

Architecture choice: Keep the new action plan preview-only. It produces messages, labels, warnings, and a plain-text report, but it does not queue or send hardware MIDI. RPN setup plans include a safety RPN-null/deselect pair after absolute or relative value messages. NRPN setup plans remain conservative and warn that device behavior varies.

Future extensions: Surface the action plan in MIDI PATCH and MIDI SETUP as a PREVIEW ONLY card first, then later add an explicit confirmed hardware queue path with progress, timing estimates, profile receipts, and one-click rollback of SpaceAge-side documentation.

2026-07-02 - MIDI Learn Needs A Preflight Before It Learns

Task: Add a non-mutating MIDI Learn preview layer that can report source conflicts before a hardware move commits a mapping.

What connects creatively: This is the same trust pattern as SysEx restore, hardware setup templates, MIDI stem import, and Quasar package reveal: show the exact consequence before the app mutates the project. MIDI Learn is especially sensitive because one knob can be a mistake or a performance macro. The preview lets SpaceAge ask the musician whether this is replacement, macro-building, or cancellation without guessing intent.

Architecture choice: previewMidiLearnCapture() uses the currently armed Learn request plus an incoming learnable MIDI message to build a reusable MidiLearnCapturePreview. It reports source, target, replacement mode, existing targets on that source, high-resolution companion metadata, summary text, and detail text without changing the mapping table.

Future extensions: Insert the visible confirmation dialog when preview reports a conflict, then reuse the same preview/receipt pair for direct VST parameter learn, hardware macro panels, and an eventual "show me everything this controller will move" performance dashboard.

2026-07-02 - MIDI Learn Conflicts Need Three Honest Doors

Task: Expose pending MIDI Learn source conflicts as REPLACE, MACRO, and CANCEL choices inside MIDI Maps.

What connects creatively: The same physical knob can mean three very different musical intentions: replace the old assignment, become a macro control, or abort because the wrong control was touched. Treating those as three visible doors gives MIDI Learn the same safety philosophy as SysEx restore, hardware-template apply, stem import, and Quasar package reveal: nothing important happens until the user can see the consequence and commit.

Architecture choice: Conflict captures now become pending state in the processor. The UI hides the normal target picker while pending and shows only the decision buttons. Confirmation flows through the same commit helper as ordinary Learn, so receipts, dashboard counts, macro labels, duplicate repair, and high-resolution CC labels all stay aligned.

Future extensions: The same pending-decision component can later be reused for VST parameter Learn, global performance macros, MIDI controller profile templates, and an "inspect macro" view that lists every target moved by one gesture.

2026-07-02 - Readiness Scorecards Must Retire Finished Warnings

Task: Update MIDI Protocol Coverage so the MIDI Learn row recognizes the implemented REPLACE, MACRO, and CANCEL conflict-confirmation flow.

What connects creatively: The product's own status language is part of the interface. If a report says a finished trust feature is still missing, it trains us to chase old ghosts and makes the remaining work look blurrier than it is. This connects MIDI Learn, SysEx restore, hardware setup templates, Quasar package reveal, and future VST Learn because each preview/confirm workflow should be credited precisely once it exists.

Architecture choice: Keep MIDI Learn as a product-readiness blocker for the unfinished polish that still matters, but remove stale wording that named source-conflict confirmation as upcoming. The scorecard now says what is done, what remains, and why the family is not yet fully closed.

Future extensions: Add regression tests for every major readiness-row milestone so the dashboard cannot drift away from the code after a feature crosses from "planned" to "implemented."

2026-07-02 - 14-Bit MIDI Should Explain Itself Once

Task: Add a model-owned MIDI control source resolution label for learned assignments.

What connects creatively: A musician should not need to know the history of MSB/LSB controller pairs to understand why one knob is smoother than another. A summary label such as 14-bit paired when CC 33 fine is present connects MIDI Maps, MIDI Health, future controller profile templates, hardware setup reports, and support receipts through one shared explanation instead of making every panel invent its own prose.

Architecture choice: Keep the resolution label in MidiControlAssignmentSummary, beside source, target, curve, pickup, and high-resolution companion metadata. The UI consumes that fact; it does not recompute controller-pair meaning. Older serialized summaries derive the label on load so compatibility remains calm.

Future extensions: Use the same label in MIDI controller templates, performance macro inspectors, learn receipts, and eventual explicit 7-bit / 14-bit paired / coarse only user controls.

2026-07-02 - MIDI Learn Reports Should Be Copyable Receipts

Task: Give the MIDI Learn dashboard its own plain-text report and embed it inside MIDI Health.

What connects creatively: MIDI Learn is not just a list of rows; it is a setup contract between SpaceAge and the musician's hands. A copyable dashboard report lets the app explain controller count, target resolution, duplicate mappings, macro sources, source families, target groups, and warnings with the same authority as the UI. That connects Settings, support bundles, controller templates, future AI troubleshooting, and performance macro design.

Architecture choice: MidiControlMappingDashboard::toPlainTextReport() owns the prose. MIDI Health includes that report instead of reducing Learn status to one line, and serialization carries plainTextReport so future UI surfaces can copy it without reconstructing facts.

Future extensions: Add a COPY MIDI MAPS action directly to the MIDI Maps panel, include the report in project support bundles, and let future controller-template export append the same summary as a readable manifest.

2026-07-02 - MIDI Maps Should Copy The Same Receipt Health Trusts

Task: Add a direct COPY REPORT action to the MIDI Maps panel.

What connects creatively: MIDI Health is the doctor visit, but MIDI Maps is the workshop bench where the musician is actually touching knobs and cleaning assignments. Putting the same dashboard receipt in both places keeps the language consistent and reduces the user's memory burden: if a mapping looks suspicious, they can copy the report right where the suspicion happened.

Architecture choice: The UI copies MidiControlMappingDashboard::toPlainTextReport() directly. No editor-only summary is built, and the same assignment counts, source families, macro status, duplicate warnings, target groups, and unresolved-target warnings remain authoritative in Health, JSON, tests, and the live Maps panel.

Future extensions: Include the Maps receipt in support bundles, controller-template export manifests, future "performance macro" inspectors, and any AI troubleshooting prompt that needs a compact but truthful map of the user's hardware controls.

2026-07-02 - Learned Controls Need To Explain Their Feel

Task: Extend the MIDI Learn dashboard with counts for pickup/soft takeover, inverted mappings, custom ranges, and curved responses.

What connects creatively: Two knobs can both be mapped correctly and still feel completely different under the hand. One might wait for pickup, one might be inverted, one might only sweep a narrow musical range, and one might have a slow-start curve. If SpaceAge is going to be excellent for hardware users, the diagnostic report has to explain feel, not just wiring.

Architecture choice: Keep these as dashboard facts derived from assignment summaries. The mapping row remains the detailed editing surface, while MIDI Health, MIDI Maps copy reports, JSON, tests, future support bundles, and controller-profile exports can share the same performance-behavior counts.

Future extensions: Use the same counters to drive a future "controller feel audit" panel: show which mappings may surprise a performer, offer bulk pickup enable/disable, and warn before exporting a controller profile with hidden inversion or tight custom ranges.

2026-07-02 - Active Sense Is Not A Beat

Task: Make MIDI Sync runtime reports distinguish actual sync/transport activity from MIDI status chatter such as Active Sense.

What connects creatively: Old hardware can constantly whisper "I'm alive" through Active Sense. That is useful, but it is not a tempo, a location, a transport command, or a musical performance gesture. If SpaceAge treats that chatter as the same kind of evidence as Clock, SPP, MTC, or MMC, the user gets false confidence and the setup guide feels slippery.

Architecture choice: Add model-level counts for sync/transport messages versus status chatter, then let the MIDI Sync preflight surface render the difference. This keeps the distinction available to tests, Health reports, setup assistants, and future support bundles without making each UI panel rediscover MIDI status semantics.

Future extensions: If we later add System Reset, Tune Request, or richer real-time diagnostics, keep them in a similar "status/safety chatter" lane unless they are explicitly used to drive transport, clock, hardware recall, or setup mutation.

2026-07-02 - Protocol Scorecards Should Expose Workflow Debt

Task: Add product-ready percentage and backend-ready/UI-pending counts to the MIDI Protocol Coverage report.

What connects creatively: Backend MIDI support and customer-facing MIDI workflow are not the same thing. A feature can be classified, preserved, exported, or guarded internally while still lacking the human workflow that makes it feel finished. Calling out backend-ready/UI-pending families keeps our own scorecard honest and helps answer "how close are we?" without pretending that protocol preservation equals a shippable experience.

Architecture choice: Keep the counts on MidiProtocolCoverageReport, not the editor. The same scorecard can feed Settings, Health, support bundles, tests, and future release-readiness reports without rebuilding math in each surface.

Future extensions: Use this same pattern for synth engines, effects, Quasar, export/archive tools, and future VST hosting: separate "engine exists" from "workflow feels obvious, safe, and finished."

2026-07-02 - Readiness Debt Belongs On Screen

Task: Surface product-ready percentage and backend-ready/UI-pending count inside the Settings MIDI Protocol Coverage popup.

What connects creatively: A copyable report is excellent for support, but the working musician needs the same truth while making decisions in the app. Showing product readiness and UI-pending debt directly in the protocol panel connects engineering reality to customer-facing workflow: the backend may know what a MIDI family is, while the user still needs a path that feels obvious, safe, and complete.

Architecture choice: Keep the math in MidiProtocolCoverageReport and let the editor render it as a pair of compact scorecard widgets. The UI remains a view of model-owned facts, not another place where readiness logic can drift.

Future extensions: Build the same “backend exists / workflow complete / product ready” framing into synth engines, effects, export, project archive, Quasar, and VST hosting so release decisions are based on visible completion instead of optimism.

2026-07-02 - Expression Cleanup Needs A Receipt

Task: Add action labels and kept-event counts to MIDI expression transform results.

What connects creatively: Recorded MIDI expression can be messy in a human way: mod wheel flutter, breath-controller ripples, pedal bumps, or pitch-bend noise. When SpaceAge thins or quantizes that data, the app should act like a careful engineer at the console: “I matched this lane, kept these points, removed these redundant ones.” That kind of receipt turns an invisible cleanup into a trustworthy creative action.

Architecture choice: Keep the receipt on MidiExpressionTransformResult, beside matched, changed, and removed counts. The MIDI EXPR panel, tests, future piano-roll expression lanes, support reports, and possible AI troubleshooting can all quote the same model-owned result.

Future extensions: Use the same receipt shape for curve smoothing, lane thinning previews, humanization passes, controller-data scaling, and future automation/motion clips so every destructive or simplifying edit can explain what it changed before and after commit.

2026-07-02 - Intentional Silence Should Be Named

Task: Count silent export-only MIDI lanes separately in project readiness.

What connects creatively: Silence can mean failure, but it can also mean intent. A lane that is export-only should not light up the hardware-output warning machinery or send a musician searching for a missing synth. Naming it as “silent export-only” connects Arrangement routing, MIDI Health, MIDI export, collaborator handoff, and support reports with the same simple promise: this lane will not play here, but it still belongs in the MIDI file.

Architecture choice: Store the count in MidiProjectReadinessReport and derive it during the processor lane scan. Do not treat export-only lanes as hardware-output lanes, and do not add warnings for a valid export route.

Future extensions: In the Arranger lane badge, show a subtle export-only glyph or tooltip, and in MIDI export receipts list which lanes were intentionally silent during playback but included in the exported MIDI package.

2026-07-02 - Export Silence Needs Handoff Language

Task: Surface silent export-only lanes in MIDI Health, MIDI export preview, and stem-package receipts.

What connects creatively: Export-only is a compositional promise: this lane is not meant to sound inside SpaceAge right now, but it still belongs in the collaborator's MIDI file. If that intent appears only in a route dropdown, a user can forget it by the time they render or troubleshoot. Repeating the same truth in Health, preview, and package receipts turns a quiet technical route into a clear handoff contract.

Architecture choice: Keep the count in MidiProjectReadinessReport and derive export-preview/receipt notes from each lane's route target. Avoid string-parsing route labels, because labels can change while route intent should stay stable.

Future extensions: Add an export-only glyph to Arrangement lane badges, include export-only lanes in support bundles, and let MIDI Export Preview filter or highlight intentionally silent lanes before writing files.

2026-07-02 - Preflight Should Explain Its Blind Spots

Task: Add export-only exclusion counts to MIDI Output Preflight.

What connects creatively: A preflight panel is partly a checklist and partly a trust ritual. If MIDI OUT only lists hardware-routed lanes, export-only lanes disappear from that surface even though they are valid MIDI lanes. Naming the exclusion teaches the user that the panel is doing exactly what it says: checking hardware output, not judging every lane in the song.

Architecture choice: Put exportOnlyLaneCount on MidiExternalOutputReadinessReport and seed it from project readiness. The focused MIDI OUT panel, JSON, copy report, tests, and future setup assistant can all share the same count without rereading lanes in UI code.

Future extensions: Let MIDI Setup scenarios show separate pills for internal playback lanes, external hardware lanes, and export-only lanes, then allow a guided conversion if the user really meant to route an export-only lane to hardware.

2026-07-02 - Hardware Is A Choice, Not A Missing Default

Task: Remove misleading no-hardware warnings from MIDI output repair flows and add export-only awareness to the hardware setup assistant.

What connects creatively: SpaceAge is meant to welcome three equally valid MIDI intentions: internal sound, external hardware, and silent export for collaborators. If the MIDI OUT panel nags a purely internal project about missing hardware, the app feels anxious instead of intelligent. Treating hardware as a deliberate route makes the assistant calmer and helps users trust that silence can be an authored state, not a broken one.

Architecture choice: Keep this in the shared MIDI model. The external-output readiness report should describe hardware lanes that exist, not invent warnings when none exist. The setup assistant gets an optional export-only row so copied guides, Settings, tests, and future onboarding all repeat the same distinction.

Future extensions: Add a lane-route legend to MIDI Setup: Internal Playback, Hardware Output, Internal + Hardware, and Silent Export Only. That could become the bridge into a future “convert selected lanes” command without implying any one route is the normal route.

2026-07-02 - RPN Setup Cards Can Become A Confirmed Hardware Action

Task: Add a guarded QUEUE CARD path for selected RPN setup cards in MIDI PATCH.

What connects creatively: A setup card is no longer merely an import receipt; it can become a deliberate hardware action when the user is ready. This connects MIDI import review, MIDI PATCH, Hardware Passports, output preflight, and recall logs into one clear ladder: inspect the card, copy the receipt, attach it to the device, then explicitly queue the standard RPN message sequence. That is the kind of hand-holding older synth hardware deserves.

Architecture choice: Keep the queue bridge processor-owned and confirmation-gated. The UI only asks for permission and shows status; the MIDI model owns the CC action plan, and the processor requires a Hardware Passport output target before anything enters the hardware queue. Unknown NRPN remains review/copy data because device-specific NRPN meaning is too variable without a named passport dictionary; passport-defined queue-safe NRPN can use the guarded queue path.

Future extensions: Add Hardware Passport NRPN dictionaries, editable known-RPN cards, per-device setup presets, richer transfer progress, and a setup-card history view that shows whether a card was copied, attached, queued, or rejected.

2026-07-02 - NRPN Cards Need A Passport Before They Can Travel

Task: Add Hardware Passport NRPN dictionaries and allow QUEUE CARD only for passport-defined queue-safe NRPN setup cards.

What connects creatively: NRPNs are where old hardware becomes wonderfully specific and potentially hazardous. One synth's NRPN 1/2 might be filter resonance; another device may treat that same selector as something unrelated. A Hardware Passport NRPN dictionary turns that ambiguity into a named device promise: SpaceAge can say "this lane is attached to this external instrument, and this instrument says NRPN 1/2 is safe to queue." That connects MIDI PATCH, Hardware Passports, import review, setup-card receipts, recall logs, and future device templates without pretending unknown hardware dialects are universal.

2026-07-02 - Define NRPN From The Card In Front Of You

Task: Add a DEFINE NRPN path to the MIDI PATCH setup-card workflow.

What connects creatively: The safest place to teach SpaceAge a device-specific NRPN is the moment the user is reviewing the exact imported setup card. That lets a musician move from "this unknown hardware gesture was preserved" to "this particular passport knows what this selector means" without jumping into a separate database editor. It connects import review, lane selection, Hardware Passport identity, queue safety, and the later QUEUE CARD action into one discoverable sequence: review the card, define the device meaning, then queue it only when explicitly confirmed.

Architecture choice: Keep standard RPNs model-owned and queueable after confirmation, but make NRPN sendability profile-owned. Unknown NRPN cards remain copyable/attachable receipts. Queue-safe NRPN cards require the selected lane's Hardware Passport to include a matching parameter MSB/LSB definition marked queueSafe, and the processor still owns the final send boundary.

Future extensions: Build the visible NRPN dictionary editor inside Hardware Passports, let Device Templates seed known safe NRPN maps, show dictionary chips on MIDI PATCH cards, and add import helpers that suggest but do not auto-trust NRPN meanings based on a chosen hardware profile.

2026-07-02 - Shared Pattern Expression Needs A Human Pause

Task: Add an ACK SHARED guard before MIDI EXPR mutates expression data on a pattern used by multiple Arrangement clips.

What connects creatively: A repeated clip is one of SpaceAge's core composition accelerators, but shared identity cuts both ways: one edit can intentionally update every reuse, or accidentally damage a carefully arranged chorus. The guard turns a hidden architectural fact into a visible musician choice. It connects Pattern identity, Variant workflow, MIDI expression drawing, Arrangement clips, and future clip-local automation without forcing the deeper migration today.

Architecture choice: Detect sharing from Arrangement clip references, not only from MIDI Health warnings, so even the first expression event added to a reused pattern is protected. This is a UI guardrail over the current pattern-scoped storage model, not a new storage model.

Future extensions: MAKE VARIANT now covers the immediate safe-local-edit path from MIDI EXPR. The deeper future step is clip-local expression overlays, a "linked expression" badge on clips, and a batch command that intentionally propagates expression changes across selected sibling clips.

2026-07-02 - Realtime-Safe Hardware Clock Output

Task: Keep outgoing MIDI Clock away from profile locks, device discovery, and the slower setup/recall message queue.

What connects creatively: Hardware sync should feel invisible: press play and the external box locks without SpaceAge stuttering. Caching clock-capable output slots when Hardware Passports change lets the audio callback fire clock pulses by prepared slot and sample offset, while SysEx/program recall remains in the safer delayed queue.

Architecture choice: Notes, clock, and performance gestures belong in the live hardware queue. Identity requests, patch dumps, setup cards, and delayed recall belong in the recall/setup queue. The cached clock-slot path enforces that distinction and gives future realtime MIDI streams a cleaner template.

Future extensions: Add a MIDI Clock jitter monitor, display the number of prepared clock outputs in MIDI Health, and let Hardware Passports report whether clock is ready because an output is open versus merely configured.

2026-07-02 - MIDI Learn Should Not Move Knobs On The Audio Thread

Task: Defer runtime MIDI mapping parameter writes away from the audio callback.

What connects creatively: MIDI Learn only feels magical if assigned controls move smoothly without making the instrument feel fragile. A physical knob should become a SpaceAge knob, but that gesture should not ask the audio thread to lock profile data or notify host parameters directly.

Architecture choice: Incoming learnable CC/bend/pressure messages still pass through MIDI Learn first. If they are not being captured for learning, they enter a bounded runtime queue and are applied by a small worker thread using the existing mapping and pickup logic. The musical gesture stays responsive, but the risky parameter notification is no longer performed inline with audio rendering.

Future extensions: Add dropped-mapping-message counts to MIDI Health, coalesce very dense CC streams per target, and later move automation/motion clips through the same gesture queue / model-owned receipt pattern.

2026-07-02 - MIDI Export Should Tell The Truth About Time

Task: Centralize outgoing MIDI tempo/meter metadata and make export details explicitly say fixed 4/4.

What connects creatively: Collaborator MIDI files are promises. If SpaceAge exports a file that carries the current BPM and a fixed 4/4 meter, the preview and receipt should say that plainly rather than letting a user assume a hidden conductor map exists. This connects export preview, stem-package receipts, import map review, future score output, and the eventual conductor-track editor into one honest timing story.

Architecture choice: Use one processor helper for all MIDI-file metadata writing, and keep the user-facing timing wording in the MIDI model's export job plan. Do not scatter tempo meta-event creation across individual export paths. Do not turn the fixed-meter limitation into a scary warning that blocks ordinary export; present it as timing context until variable meter/tempo maps become real project data.

Future extensions: Replace the helper with a real project conductor-map writer once SpaceAge owns tempo/meter/key events. The same model should then drive MIDI export, imported map adoption, score rendering, Arrangement ruler labels, and collaborator package receipts.

2026-07-02 - MIDI Health Should Show Controller Pressure

Task: Surface runtime MIDI control-mapping dropped-message counts in MIDI Health.

What connects creatively: A controller flood should never feel like folklore. If a hardware knob, fader, wind controller, or expression pedal sends too much dense data, SpaceAge now has a place to say "the safe queue was overwhelmed" instead of making the user guess whether the controller, audio driver, synth, or MIDI Learn map is at fault. This connects live controller feel, MIDI Learn, automation capture, diagnostics, and future support bundles.

Architecture choice: Keep the audio path clean: incoming learnable control messages enter a bounded runtime queue, and MIDI Health reports pressure from that queue. That preserves realtime safety while still giving customer-facing diagnostics a concrete number to report.

Future extensions: Coalesce dense CC streams per target, expose a "thin incoming controller data" option, and let MIDI Health distinguish harmless pressure spikes from repeated workflow-breaking queue saturation.

2026-07-02 - Clock Send Needs A Ready Light

Task: Add prepared realtime MIDI Clock output counts to MIDI Sync policy reporting.

What connects creatively: External hardware sync has two states musicians care about: "I asked SpaceAge to send clock" and "SpaceAge actually has a prepared output for clock." Those are not always the same thing. Exposing the prepared count makes Sync diagnostics less mystical and gives future hardware setup flows a ready light before playback starts.

Architecture choice: Report the cached realtime clock-output slot count from the processor into the shared Sync Policy summary. The audio callback still only reads atomics and queues MIDI Clock into prepared live output slots; the UI/reporting layer only observes that prepared state.

Future extensions: Add a Sync panel badge such as CLOCK READY: 2 OUTS, warn when send-clock profiles exist but no realtime output is prepared, and include prepared-clock state in future hardware support bundles.

2026-07-02 - MPE Is A Future Policy, Not A Vibe

Task: Clarify whether MPE belongs in the current MIDI protocol finish line.

What connects creatively: MPE is exactly the kind of expressive feature SpaceAge should eventually support because it speaks to MIDI guitarists, expressive keyboardists, wind-controller players, and high-end sound-design customers. But it is also dangerous to half-promise: a multi-channel pitch-bend stream is not automatically an MPE performance unless the lane/device owns a zone policy. Naming the boundary keeps marketing honest and makes the eventual feature stronger.

Architecture choice: Keep the current MIDI 1.0 expression layer as MPE-adjacent: per-channel bend/pressure/CC data, CC74 brightness/timbre-style data, and note-specific poly aftertouch are preserved and editable. True MPE needs a separate lane-level policy for zones, master/member channels, member-channel allocation, pitch-bend range, per-note expression ownership, import/export validation, and internal synth response.

Future extensions: Add an MPE Lane mode in MIDI Setup, device-template presets for common expressive controllers, MPE-aware ghost-note/expression views, Redshift/Quasar/Lunacy response to per-note pitch/timbre/pressure, and a clear import warning when a file looks MPE-like but no lane policy has been chosen.

2026-07-02 - MPE-Like Import Detection As A Future Doorway

Task: Detect imported MIDI that looks like channel-per-note or MPE-like performance data without claiming SpaceAge has true MPE yet.

What connects creatively: This is a small warning today, but it can become a graceful on-ramp later. If a MIDI guitar, Seaboard-style controller, or expressive synth export arrives with notes spread across several channels plus bend, pressure, or CC74, SpaceAge can say, "I see what this probably is," preserve the expressive data, and eventually offer to convert it into an MPE Lane once that policy exists.

Architecture choice: Keep detection in the MIDI inspection model. The import wizard, review dashboard, support reports, and future hardware assistant can all reuse the same truth. Do not put MPE guesses in the editor or silently translate multi-channel expression into a normal lane.

Safety refinement: Multi-channel expressive MIDI that may be MPE-like now turns expression preservation into a review-required import choice. The user can still preserve the performance data, but SpaceAge makes the limitation visible before mutation instead of letting an expressive controller file feel like a normal multichannel MIDI import.

Future extensions: Add an import choice such as Create MPE Lane, a preview that shows master/member channels, bend range, and per-note expression ownership, and a validation receipt that proves export will preserve the performance before the user commits.

2026-07-02 - Pattern-Owned Expression, Future Clip-Local Overlays

Task: Clarify the ownership boundary for MIDI expression data before the next expression-lane UI pass.

What connects creatively: Expression gestures are musical events: a pedal swell, breath-controller bloom, pitch bend, aftertouch pressure, or filter sweep can define the emotional shape of a phrase. But SpaceAge also uses repeated clips as a core arrangement tool, and a hidden shared expression edit could quietly change every reuse of a pattern. Naming the ownership boundary protects the musician from invisible consequences while keeping the future open for clip-local swells and one-off arrangement gestures.

Architecture choice: Current expression payloads remain pattern-owned. The MIDI EXPR surface must keep using processor helpers, shared-edit guards, and MAKE VARIANT when the user wants a local edit on a repeated pattern. Clip-local expression is not forbidden; it is deferred until it can have its own identity, copy/paste behavior, split behavior, full-song export rules, and undo story.

Future extensions: Add clip-local expression overlays after the pattern-owned lane editor is stable. Possible UI language: Linked Expression, Local Expression, and Promote To Pattern. The same ownership model can later support Motion Clips, per-clip effect automation, MPE lanes, and arrangement-only controller curves without collapsing back into ambiguous shared state.

2026-07-02 - Current MIDI Finish Line Versus Future Protocol Ambition

Task: Make the MIDI Protocol Coverage model separate the current MIDI 1.0 product finish line from deferred expressive protocol families.

What connects creatively: SpaceAge should eventually court expressive-controller players with MPE and MIDI 2.0, but the current release needs a calm, honest answer to "is MIDI ready?" A scorecard that mixes finished MIDI 1.0 workflow with future MPE dreams makes progress look worse than it is and makes roadmap language feel slippery.

Architecture choice: Keep deferred future protocols as first-class report rows, but add model-owned current-finish-line counts and deferred-family summaries. The UI, copied reports, support bundles, and tests can then say: current MIDI 1.0 is nearing product shape, while MPE/MIDI 2.0 are visible roadmap items that do not block the present finish line.

Future extensions: When true MPE work begins, split the future family into concrete rows: zone setup, member-channel allocation, pitch-bend range negotiation, per-note expression editing, synth response, import/export validation, and MIDI 2.0 profile/property exchange. Each row should graduate into the current finish line only when the architecture and user workflow are actually being built.

2026-07-02 - MIDI Blockers Need Buckets, Not Fog

Task: Categorize active MIDI product-readiness blockers in the protocol coverage model.

What connects creatively: A flat list of blockers makes every unfinished thing feel equally heavy. Categories turn the fog into departments of work: expression editing, SysEx librarian safety, import/export flow, timeline maps, MIDI Learn polish, and hardware setup. That lets SpaceAge preserve momentum by asking "which bucket gives the user the most confidence next?" instead of just "what MIDI thing is still red?"

Architecture choice: Put the category on MidiProtocolCoverageItem and serialize a model-owned category summary. The editor, MIDI Health, copied support reports, QA checklists, and future release-readiness pages can all quote the same classification without rebuilding priority logic in UI code.

Future extensions: Use blocker categories to drive a release checklist panel, assign subagent-style work packets, and generate a focused "MIDI closeout" view that lets us collapse a whole category when its blockers become non-blocking polish.

2026-07-02 - MIDI Buckets Should Become Dashboard Objects

Task: Promote MIDI blocker categories from report text into structured model data.

What connects creatively: A blocker category is more than a label. It can become a dashboard card, a QA checklist group, a support-report section, a release milestone, or a subagent work packet. By giving each bucket its affected protocol families and next actions, SpaceAge can eventually show the user or tester a calm MIDI closeout page instead of making anyone read a wall of prose.

Architecture choice: Add MidiProtocolBlockerCategory beside the protocol coverage item model. The report now serializes category objects with category, count, families, nextActions, and summary, while the plain-text report stays readable for copy/paste support. This keeps UI code from reverse-parsing text and keeps tests honest about what the model actually exposes.

Future extensions: Build a Settings MIDI CLOSEOUT view that groups unfinished work by category: Expression Editor, SysEx Librarian, Import Wizard, Export Workflow, Timeline Map, MIDI Learn Completion, and Hardware Setup Wizard. Once a category is cleared, the UI can remove an entire bucket instead of hiding one row at a time.

2026-07-02 - Expression Lanes Are Performance Shapes

Task: Add editor-facing metadata to MIDI expression lane summaries.

What connects creatively: A CC lane, pitch-bend lane, sustain lane, and pressure lane are all "MIDI expression," but they should not feel identical to a composer. Sustain wants switch-like blocks. Pitch bend wants a centered bipolar curve. Breath, expression, mod wheel, and pressure want continuous drawing. By putting those hints in the model, SpaceAge can let the eventual editor feel musical instead of generic.

Architecture choice: Extend MidiExpressionLaneSummary with editor minimum/maximum/center values, bipolar/switch/drawable flags, edit-mode labels, and user-facing editor hints. The preflight report now carries the same facts, so tests, support reports, and future UI all share one truth.

Future extensions: Reuse this metadata for drawable MIDI lanes, wind-controller breath views, MIDI guitar bend lanes, clip-local expression overlays, Motion Clips, MPE zone previews, and automation curves for internal synth/effect parameters. The creative win is that all time-varying data can become visible "performance shapes" without flattening their different musical meanings.

2026-07-02 - Expression Curves Need A Shared Shape Preview

Task: Add serialized preview points to MIDI expression lane summaries.

What connects creatively: MIDI expression is visual time. A bend curve, sustain pedal block, pressure swell, or mod-wheel gesture should eventually read at a glance, the way Arrangement clips already hint at their note contents. Preview points give the UI a compact contour for each lane without making every future view parse raw MIDI independently.

Architecture choice: Keep preview points in MidiExpressionLaneSummary, beside editor ranges, switch/bipolar hints, and edit labels. Each point carries tick, raw value, and normalized 0-to-1 position, which means the Settings MIDI EXPR panel, a future Piano Roll lane, support reports, and Motion Clip conversion can all draw from the same model-owned data.

Future extensions: Add smarter decimation for dense curves, show switch lanes as blocks instead of dots, add selected-point ownership warnings for shared patterns, preview thinning before committing it, and let Motion Clips harvest these same shapes as reusable performance gestures.

2026-07-02 - The MIDI EXPR View Should Draw From The Same Truth It Reports

Task: Make the compact MIDI EXPR lane previews consume model-owned preview points.

What connects creatively: A preview is a promise. If the report says an expression lane is a pitch-bend curve, sustain switch lane, or pressure lane, the visual preview should come from that same interpreted model, not a private editor-side re-read of raw MIDI events. This is the same discipline we keep applying elsewhere in SpaceAge: clips, lanes, reports, exports, and future help surfaces should all describe the same musical object.

Architecture choice: MidiExpressionPanel::drawLanePreview() now consumes MidiExpressionLaneSummary::previewPoints, using the model's normalized values and switch-lane flag. The editor still owns pixels, but the model owns the musical interpretation.

Future extensions: The full Piano Roll expression editor can reuse this renderer logic with larger hit targets, point handles, curve handles, selection boxes, and ownership warnings. Because the preview already uses model data, the large editor can grow without changing import/export or playback semantics again.

2026-07-02 - Custom CCs Make Hardware Feel Invited

Task: Let MIDI EXPR create arbitrary performance CC lanes directly while keeping setup controllers protected.

What connects creatively: Custom CC authoring is the quiet bridge between SpaceAge's internal instruments and the wider hardware world. A wind controller, MIDI guitar rig, groovebox, or synth module may care about CC71, CC76, CC2, or some other expressive controller that is not one of the obvious defaults. Exposing those as first-class drawable lanes says, "bring your hardware language with you," without forcing the user to import a MIDI file first.

Architecture choice: Keep arbitrary CCs generic in the MIDI model. A CC71 lane is still controlChange + channel + controllerNumber, not a new special-case kind. MIDI EXPR only offers editable performance controllers; Bank Select, Data Entry, RPN/NRPN, and other setup traffic stay in MIDI PATCH / Hardware Passport flows where warnings, recall recipes, and hardware safety can be explicit.

Future extensions: Reuse the same custom-CC selector for Motion Clips, hardware template recommendations, wind-controller breath lanes, MIDI guitar timbre lanes, and clip-local expression overlays. The creative payoff is a single expressive-data language that can draw curves for internal synths, external synths, and future automation objects without creating separate one-off editors.

2026-07-02 - MIDI Song Metadata Must Be Truthful

Task: Tighten MIDI import/export tempo and key metadata so SpaceAge does not lie to collaborators or imported files.

What connects creatively: Tempo, meter, and key are not decoration. They are the musical weather system around every clip, chord marker, and hardware sync decision. If SpaceAge exports a beautiful Arrangement but writes generic metadata, collaborators open the file in another DAW with needless doubt. If SpaceAge imports the wrong "first" key because another track happened to be scanned earlier, the Chord Engine starts from a false premise.

Architecture choice: Keep the current implementation honest and narrow: choose earliest source tempo/key by tick across all MIDI tracks, adopt only first source tempo/key when explicitly requested, and export one current project tempo plus fixed 4/4 plus current project key signature. Do not fake full conductor-track support until the project owns real tempo, meter, and key maps.

Future extensions: The same metadata discipline should become the backbone of a future Timeline Map editor. Once SpaceAge has tempo/meter/key regions, MIDI import can offer "adopt source map," Arrangement can render form-aware tempo changes, Chord Engine transposition can become project-global, and exported MIDI can carry a complete conductor track without special-case hacks.

2026-07-02 - Expression Scopes Need Musical Landmarks

Task: Make MIDI EXPR selected-scope drawing show step/bar timing and snapped draw feedback.

What connects creatively: A controller lane is a performance line through time, not a spreadsheet of ticks. Adding grid lines and a playhead marker to the selected expression scope makes CC swells, sustain blocks, breath pressure, mod wheel, and pitch bend feel closer to the Arrangement and Piano Roll language. The user can now see "where am I in the phrase?" while drawing the gesture.

Architecture choice: Keep the editor responsible for pixels, but keep interpretation model-owned. The scope uses MidiExpressionLaneSummary::previewPoints, the existing editor plan, and the MIDI layer's point mapping. The grid is visual guidance over the same timeline math used to author the events; it does not invent a separate timing model.

Future extensions: Promote this into full piano-roll-style expression lanes with point selection, curve handles, lasso selection, snap subdivisions, clip-local versus pattern-owned expression modes, and reusable Motion Clips. The same landmark approach should eventually guide automation for synth parameters and effect sends.

2026-07-02 - Expression Editors Need Plain-Language Physics

Task: Add snap/value labels to the MIDI expression editor plan and show them in the selected scope.

What connects creatively: Pitch bend, sustain, pressure, and custom CCs all live in MIDI, but each one has a different physical feel. Pitch bend has a center and a wide 14-bit range. Sustain is a switch. Pressure is a continuous gesture. Custom CCs are general controller values. The UI should teach that instantly, so the user does not feel like every expression lane is a mysterious row of numbers.

Architecture choice: Keep snap/value wording in MidiExpressionEditorPlan, not in PluginEditor. The editor paints the label, but the MIDI layer owns the meaning. That protects future Piano Roll expression lanes, Motion Clips, hardware reports, import previews, and MIDI Health from drifting into separate explanations of the same event.

Future extensions: Let the same plan drive specialized point handles: centered handles for pitch bend, block handles for sustain, pressure curves for wind/MPE-style data, and transform tools that know whether a lane should be thinned, quantized, inverted, or left review-only.

2026-07-02 - Dense Expression Previews Need Honesty

Task: Add preview-density labels to MIDI expression editor plans and reports.

What connects creatively: A dense mod-wheel pass, breath-controller line, or pitch-bend performance can contain far more points than a compact GUI row should draw. If SpaceAge shows only a sampled preview, the user needs to know that instantly. This is the same trust contract as Arrangement clip thumbnails: the miniature should be useful, but it should never pretend to be the entire object when it has been intentionally thinned for readability.

Architecture choice: Keep previewLabel in MidiExpressionEditorPlan, beside snap and value language. The UI can draw it in the selected-scope panel, copied reports can include it, and future thinning/decimation commands can reuse the same vocabulary without each surface inventing its own "shown versus hidden" wording.

Future extensions: Turn THIN available into a previewable command with before/after point counts, preserve original imported performance data until commit, and let Motion Clips harvest dense gestures without forcing the user to manually clean every controller lane first.

2026-07-03 - Test Notes Should Feel Like A Handshake, Not A Trap

Task: Bridge MIDI SETUP device templates to a visible, confirmed hardware test-note action.

What connects creatively: The first sound from an external synth should feel like SpaceAge saying, "we found the wire." That is a tiny interaction, but it can carry a lot of trust. If test-note stays note-only, receipt-driven, and visibly confirmed, the user can diagnose routing without fearing that SpaceAge secretly changed a patch, sent clock, reset the box, or dumped setup data into vintage hardware.

Architecture choice: Keep the preflight receipt in MidiHardwareSetupTestNotePlan, then let the processor build a lane-aware version and queue only note-on/note-off after confirmation. The MIDI SETUP panel can show BLOCKED, QUEUED, or FAILED, but the model still owns readiness, channel, note, velocity, duration, warnings, and the promise that building the report sends no MIDI.

Future extensions: Reuse the same handshake pattern for MIDI timing calibration, hardware setup support reports, device-profile smoke tests, and first-run onboarding. A later wizard can chain "connect cable," "choose output," "hear test note," and "save profile" as separate visible steps instead of bundling them into one risky magic button.

2026-07-03 - The Status Report Should Credit Trust Work Precisely

Task: Update MIDI Protocol Coverage so Routing/Devices/Preflight acknowledges guarded template apply, rollback, and TEST NOTE without closing the hardware setup blocker too early.

What connects creatively: A progress report is a promise to our future selves. If it does not credit completed trust work, we waste time re-solving it. If it over-credits the work, we ship weak spots. The right middle path is to say: the safe handshake exists, but the full hardware onboarding flow is still not finished.

Architecture choice: Keep Routing, Devices, And Preflight product-blocking, but update its UI and next-action language to name device-template draft apply, rollback, and confirmed note-only test notes. The blocker remains Hardware Setup Wizard because lane stacks, role presets, device-specific repair flows, and polished timing/test receipts still need more work.

Future extensions: Use this discipline for every future closeout pass: when a feature gains a receipt, a guarded action, or an undo path, update the protocol/status model in the same change so the app's own self-knowledge stays accurate.

2026-07-03 - Live MIDI Feel Needs A Trust Receipt

Task: Make MIDI Health explicitly report SpaceAge's live-note timing path.

What connects creatively: A musician does not care whether latency is caused by the app, driver, interface, controller, Bluetooth, or hardware response; they care that playing feels late. If SpaceAge can say, "my internal live-note path is sample-positioned; here is your buffer time; now check the rest of the path," it turns an anxious mystery into a troubleshooting ritual.

Architecture choice: Add structured live-note timing fields to MidiProjectHealthSummary and populate them from the processor. The health report, JSON payload, Settings panel, support bundle, and future first-run audio/MIDI setup flow can all quote the same fact instead of each surface inventing latency language.

Future extensions: Add an Audio/MIDI Performance Doctor that combines buffer size, sample rate, input-channel evidence, dropped mapping queues, MIDI clock jitter, hardware timing calibration, and driver notes into one plain-language "why does it feel late?" checklist.

2026-07-03 - First-Pass Editors Need Honest Finish Lines

Task: Add explicit first-pass/product-gap fields to MIDI expression editor plans.

What connects creatively: MIDI expression is where a performance becomes alive: bends, pressure, breath, sustain, modulation, and custom CC gestures. SpaceAge already has a useful MIDI EXPR surface, but it should not let us confuse "I can draw a point" with "this is a world-class lane editor." Naming the surface and the missing polish keeps the user-facing experience honest while still crediting real progress.

Architecture choice: Keep the distinction in MidiExpressionEditorPlan, not scattered in the editor. Every expression lane now knows whether it has a first-pass editor surface, whether that surface is product-final, which surface owns the current gesture, and what product gap remains. Copied MIDI expression reports can carry the same truth as the UI.

Future extensions: Reuse these fields when promoting MIDI EXPR into Piano Roll-grade expression lanes, clip-local automation, Motion Clips, MPE-style per-note editors, and hardware expression recipes. The broader lesson is useful elsewhere too: every big feature should be able to say "usable now" and "not final yet" without marketing fog.

2026-07-03 - Expression Lanes Need Ownership And Density Labels

Task: Extend MIDI expression lane summaries so reports and future editors can describe lane shape and ownership without re-parsing raw MIDI.

What connects creatively: Expression data can be a single mod-wheel gesture, a dense pitch-bend stream, a sustain switch block, a note-pressure lane, or protected setup data from imported hardware files. Those are different musical objects, even though they all travel through MIDI. Naming the object type clearly helps SpaceAge feel like a musician's editor instead of a controller-code spreadsheet.

Architecture choice: Keep span, density, and ownership language on MidiExpressionLaneSummary. MIDI EXPR reports, Settings diagnostics, future Piano Roll expression lanes, Motion Clips, hardware setup cards, and AI/help surfaces can all ask the same model whether a lane is clip-local, review-only, dense, sparse, truncated, bipolar, or switch-style.

Future extensions: Use these labels to drive lane icons, filterable expression editors, thinning recommendations, "convert to Motion Clip" actions, and smart warnings when a user tries to paste dense pitch-bend or pedal data into a clip that shares pattern identity with other Arrangement clips.

2026-07-03 - MIDI Health Should Know What Kind Of Expression Lives In A Song

Task: Promote expression lane categories into project-level MIDI Health counts.

What connects creatively: A song with one sustain lane, one pitch-bend lane, and six breath/pressure lanes is a very different organism than a song with eight imported review-only setup lanes. The user should not have to infer that from raw event counts. MIDI Health can become a calm dashboard that says, in musician language, "this project has drawable performance motion" or "this project mostly has protected hardware setup data."

Architecture choice: Build project-level expression counts from summariseMidiExpressionEvents(), then serialize them through MidiExpressionProjectSummary. This keeps the health report, MIDI EXPR panel, import previews, future Piano Roll expression lanes, and support copies aligned to one classification model.

Future extensions: Use these counts for a future MIDI Closeout dashboard, a "show all expressive lanes" filter, warnings before exporting dense controller streams to hardware, and an AI/help answer that can describe why a project feels expressive, risky, or hardware-heavy.

2026-07-03 - SysEx Needs A Librarian, Not A Trap Door

Task: Add a reusable SysEx Librarian readiness plan.

What connects creatively: SysEx is how old hardware remembers itself, but it is also the part of MIDI most likely to scare a musician because a dump can alter a device in ways that are hard to see. SpaceAge can turn that anxiety into trust by treating every snapshot like a passport entry: named, attached to a device, archived deliberately, restored only after confirmation, and explained in plain language.

Architecture choice: Keep readiness language in SysExLibrarianReadinessPlan, next to the vault summaries that already know byte counts, transfer classes, wire-time estimates, confirmation policy, and warnings. Future UI can ask the model for the current surface, next action, safety label, and product gap instead of rewording SysEx status in five places.

Future extensions: Use the same model for a Settings MIDI librarian dashboard: import/capture dump, attach to Hardware Passport, preview restore, show generic ACK/NAK response trust beside estimated progress, then log a receipt. The same safety pattern can later support firmware-safe hardware profiles, bulk dump sessions, and guided setup for vintage devices.

2026-07-03 - Progress Feedback Must Name Whose Progress

Task: Add phase, trust, and next-action labels to hardware recall queue progress.

What connects creatively: A progress readout can calm the user or mislead them. For external MIDI hardware, SpaceAge can honestly know when its own queue is draining, how many bytes remain, and how much planned delay exists. A generic ACK/NAK reply can improve trust, but it still needs correlation and profile-specific knowledge before we claim a particular vintage synth accepted the dump in its own dialect. Naming that boundary turns progress from theater into trustworthy instrumentation.

Architecture choice: Keep the phase/trust/next-action language inside HardwareRecallQueueProgress, beside the actual pending queue counts. Future UI can show Queue clear, Live hardware queue draining, or Recall/librarian queue draining while also saying this is SpaceAge-side queue visibility; restore-response classification lives in a separate verification layer.

Future extensions: Generic ACK/NAK support should stay a true hardware-response layer rather than weakening the current queue model. Next, device-specific dialects can extend the same ladder: preview/no-send, estimated complete, manually verified, generic device ACK, generic device NAK, profile-specific ACK/NAK, or timed out.

2026-07-03 - SysEx Capture Gets A Transfer Capsule

Task: Move armed live SysEx capture receipt work behind a bounded runtime queue.

What connects creatively: SysEx dumps are often the largest single MIDI messages SpaceAge will ever see. Treating them like a little courier capsule protects the live MIDI path while preserving the human promise: arm capture, receive one dump, review it, then save it to the Vault without secretly sending anything back to hardware.

Architecture choice: Incoming armed SysEx bytes are copied into a fixed-size queue slot, and a worker thread builds the MemoryBlock and capture receipt under the existing capture mutex. This keeps receipt construction and heap allocation out of the live MIDI handler while staying aligned with the SysEx Vault, Hardware Passport, and no-hidden-send safety model.

Future extensions: Add visible queue pressure, timeout, batch-capture mode, oversize-dump warnings, and Hardware Passport attachment prompts. The same "transfer capsule" pattern can support future firmware-safe capture sessions and bulk librarian workflows.

2026-07-03 - Expression Recording Gets A Commit Queue

Task: Move recorded MIDI expression event insertion behind a runtime queue.

What connects creatively: A beautiful controller performance can be dense: pitch bend, mod wheel, pressure, sustain, expression, and pan may arrive in fast streams. The user should feel that fluidity while playing, but the pattern data should be written by a calmer clerk behind the counter. That keeps SpaceAge responsive during performance and protects the same expression layer used by MIDI EXPR, import, export, ghosting, and future Motion Clips.

Architecture choice: The live MIDI path now captures compact pattern/tick/message records and wakes a worker to append/sort midiExpressionEvents under patternMutex. The live expression state still updates at sample position for monitoring, but vector mutation moves out of the realtime lane.

Future extensions: Apply the same pattern to completed note recording, then expose queue-pressure diagnostics in MIDI Health. Later, clip-local automation capture and Motion Clip recording can reuse this queue instead of inventing another storage path.

2026-07-03 - Notes Should Be Heard Now And Written Calmly

Task: Move completed MIDI note insertion behind a runtime queue.

What connects creatively: Playing a note is physical and immediate; writing that note into the song is bookkeeping. SpaceAge should respect both realities. The live path starts and releases the sound at the right time, while a worker commits the finished PianoNote into the pattern after the performance moment has passed.

Architecture choice: Note-on/off matching stays in the processor's fixed recording arrays. On note-off, the completed note is placed into MidiNoteRecordingRuntimeQueue, then committed under patternMutex by a worker. This keeps pianoNotes.push_back, pattern-length inference, and last-recorded-note feedback out of the incoming MIDI handler.

Future extensions: Eventually use the same commit model for clip-local automation, punch-in takes, and overdub lanes.

2026-07-03 - Queue Pressure Should Have A Gauge

Task: Make the new realtime-safe MIDI queues visible in MIDI Health instead of letting dropped queue items disappear silently.

What connects creatively: This connects engineering safety to user trust. A musician does not need to know what an SPSC queue is, but they do need SpaceAge to say, "your controller flooded me" or "that SysEx dump was too big" in plain language. The same idea can later power a calm diagnostics strip during live recording, hardware dump capture, and MIDI Learn.

Architecture choice: MidiProjectHealthSummary now carries queue-pressure counters for control mapping, SysEx capture, expression recording, and completed-note recording. The full Health report and warning list expose those counters, giving support/debug flows one model-owned truth instead of scattered one-off logging.

Future extensions: Add compact visible queue status chips to MIDI Health and possibly to long-running capture/recording panels. For now, copied Health reports and warnings carry the truth without adding more GUI weight.

2026-07-03 - SoundFonts Need A Launch Bay, Not A New Ship Per Note

Task: Replace the normal SoundFont note-on path with a prepared voice rack.

What connects creatively: SoundFonts made SpaceAge feel like a workstation, but that power should not feel late under the fingers. The user experience we want is "press a key, hear a tone," not "press a key, wait while a giant library makes a new tiny synth." The same Instrument Bay philosophy applies inside the engine: prepare the working parts before the musician performs.

Architecture choice: SoundFont loading, preset changes, and audio-device preparation now publish an immutable prepared TSF voice rack per pad. Live note-on borrows a rack slot with atomic inUse flags instead of taking soundFontMutex. If the rack is exhausted or stale for the current sample rate, SpaceAge refuses that unsafe live voice start and increments a Health counter, which makes the problem visible instead of mysterious.

Future extensions: Reuse the same prewarm/rack language for Quasar, large sample instruments, future streaming sample engines, and VST scan/readiness reporting. If an instrument can load huge assets, it should have a visible "ready" state, a predictable realtime voice budget, and a plain-language Health warning when the budget is exceeded.

2026-07-03 - MIDI Surfaces Need Honest Labels

Task: Preserve the customer-facing MIDI audit findings from the UI/workflow pass.

What connects creatively: SpaceAge is close to MIDI 1.0 fluency, but the last few percent are not more protocol trivia. They are trust signals: does the user understand whether a setup row is only being reviewed or is safe to queue? Can a SysEx dump show progress without pretending the hardware acknowledged it? Does a compact Health card hint that there are more warnings hiding in the full report? Honest labels are design, not mere wording.

Architecture choice: Keep the truth in model-owned reports wherever possible. MIDI PATCH should distinguish review-only versus queue-safe cards; SysEx Librarian copy should name capture/save as present, generic ACK/NAK classification as available, and batch/source/checksum/device-specific helpers as future; MIDI Health/Input/Output cards should surface count cues when full reports have more warnings than the compact card shows.

Future extensions: The same pattern can become a "confidence meter" across SpaceAge: import previews, hardware sends, Quasar builds, SoundFont readiness, render progress, and future VST scans should all state what the app knows, what it is doing, and what still requires user or external-device confirmation.

2026-07-03 - Note-On Should Be A Spark, Not A Cleaning Crew

Task: Remove host-notifying pad sanitization from the live voice-start path.

What connects creatively: MIDI has to feel like touch. When a player hits a key, the app should spend that moment making sound, not sweeping up rare bad parameter values. The same design instinct that keeps the GUI uncluttered applies to the audio thread: prepare, repair, and explain outside the performance moment so the musical gesture stays immediate.

Architecture choice: startVoice() now trusts pad state that was already sanitized at load/reset/paste/edit boundaries. If a future code path can create invalid parameter values, that path should be repaired at the mutation boundary, not in the voice launcher.

Future extensions: The same "prepare before performance" rule should guide SoundFont pooling, Quasar sample readiness, hardware test-note queues, and future VST hosting scans. Anything expensive should have a visible ready state or a worker path before the musician plays.

2026-07-03 - Sample Layers Need A Ready Rack

Task: Move classic sample and one-shot voice-start data behind an immutable per-pad cache.

What connects creatively: Pads are physical. A drummer or keyboard player expects a loaded sound to answer immediately, even if SpaceAge is also managing velocity layers, one-shots, round-robin behavior, and future sample-browser metadata. The user should not feel the app checking filing cabinets at the moment of impact.

Architecture choice: Sample, bonus one-shot, and layer-setting mutation paths now publish a fresh SampleVoiceStartCache for that pad. startVoice() reads the prepared audio handles, mapped-reader handles, length/rate/channel data, and layer settings from that cache instead of taking sampleMutex. This mirrors the SoundFont pool principle: prepare the launch bay before the note arrives.

Future extensions: Reuse this cache vocabulary for the future sample browser, Quasar readiness, per-lane Instrument Bay status, and live-performance diagnostics. If a sound can be loaded, edited, or repaired, the performance path should consume a ready snapshot and the UI should eventually be able to say whether that snapshot is healthy.

2026-07-03 - Quasar Zones Should Be Charted Before Launch

Task: Move Quasar multisample zone choice out of the live note-start lock path.

What connects creatively: Quasar is meant to feel like a serious proprietary instrument format, not a fragile export trick. If a user turns a synth patch into a multisample, the resulting instrument should answer like hardware: pick the right zone instantly, round-robin naturally, and never make the player feel the file package being searched.

Architecture choice: Quasar load/clear/paste/restore paths now publish an immutable per-pad zone cache. Live note-on scans that snapshot and advances a realtime-safe round-robin cursor instead of taking quasarMutex. The old mutable vectors still serve package management, summaries, archive, and repair; the performance path gets a charted map.

Future extensions: The same idea should feed a Quasar readiness badge in the Instrument Bay: zone count, missing-zone status, loop readiness, velocity range coverage, and round-robin coverage. A future "optimize package" command could preflight a Quasar instrument the way MIDI Health preflights hardware.

2026-07-03 - Copied MIDI Health Advice Should Be Model-Owned

Task: Give MidiExpressionProjectSummary its own plain-text report and reuse it in MIDI Health copy paths.

What connects creatively: MIDI Health has two audiences: the musician who wants a short next-action checklist and the support/developer path that needs a complete report. Expression lanes are especially easy to misunderstand because pitch bend, sustain, pressure, dense CC curves, and review-only setup data all look like "MIDI stuff" until the app names them clearly. If the model owns that naming, every surface can speak with one voice.

Architecture choice: MidiExpressionProjectSummary::toPlainTextReport() now explains event counts, lane categories, dense previews, shared-pattern cautions, and suggested workflows. MidiProjectHealthSummary::toPlainTextNextSteps() and toPlainTextReport() both reuse it instead of rebuilding expression advice inline.

Future extensions: This pattern should carry into Piano Roll expression lanes, import review, export/stem reports, hardware setup cards, and automation clips. A SpaceAge object should have one trusted explanation of what it is and what the user can safely do with it.

2026-07-03 - SysEx Progress Must Not Pretend To Be Hardware Trust

Task: Make SysEx Librarian readiness distinguish estimated paced restore progress from hardware response trust.

What connects creatively: Hardware users are often anxious because a bad SysEx send can alter or overwrite real gear. A progress meter is comforting, but it becomes dangerous if it implies "the synth accepted this" when SpaceAge only knows "we paced bytes for this long." The app should feel helpful and adult: clear about what it knows, humble about what only the hardware can confirm.

Architecture choice: SysExLibrarianReadinessPlan now carries explicit trust fields for estimated-only restore progress, response-readiness, and manual verification. MIDI Health includes that readiness report beside the Vault summary in full report copy, next-steps copy, and the structured Health payload, so future UI cards and support bundles do not need to reconstruct the warning.

Future extensions: Hardware profiles can eventually add device-specific ACK parsers, request/response templates, checksum repair helpers, and per-device restore history. Until then, every SysEx workflow should preserve the distinction between "sent," "estimated complete," "generic response received," "manually verified," and "confirmed by a profile-specific device parser."

2026-07-03 - MIDI Health Should Be The Control Room

Task: Surface the current MIDI 1.0 finish-line summary and next closeout focus directly inside the MIDI Health popup.

What connects creatively: SpaceAge is accumulating powerful MIDI systems: hardware setup, Sync, SysEx, expression, import/export, timing, and MIDI Learn. If the user must copy a report to understand what matters next, the diagnostic surface is behaving like a log file instead of a helpful assistant. The Health panel should act like mission control: one glance tells the musician whether MIDI is ready, what is risky, and what the next meaningful action is.

Architecture choice: The MIDI Health popup now reuses MidiProtocolCoverageReport's model-owned currentFinishLineSummary() and nextCloseoutFocusSummary() directly. This avoids hardcoded UI guesses and keeps the copied report, structured payload, and visible dashboard synchronized.

Copy/report choice: COPY STEPS now also includes the finish-line summary, next closeout focus, and blocker-category summary before latency/action advice. The short checklist should function like a musician-facing work order, not just a troubleshooting receipt.

Future extensions: The same "next focus" idea can become a persistent Settings badge or release-readiness checklist. Eventually, SpaceAge could show one dashboard for MIDI, audio, project assets, plugin/VST readiness, and export safety without each page inventing its own language.

2026-07-03 - Expression Selection Should Mean The Same Thing After Refresh

Task: Keep MIDI EXPR's auto-selected lane status aligned with manual lane selection.

What connects creatively: A panel that changes its tone only after the user clicks something feels slippery. MIDI expression data can include performance curves and protected setup rows, so the first visible status after opening the panel should be as truthful as the status after manual selection.

Architecture choice: MIDI EXPR now reuses MidiExpressionEditorPlan's tool hint and warning state when refresh auto-selects a lane. This keeps refresh, click selection, copied reports, and future Piano Roll expression lanes in the same conceptual lane.

Future extensions: Any future auto-selection surface, such as Motion Clips, automation lanes, hardware profile rows, or import-review rows, should apply the same plan/status logic that manual selection uses.

2026-07-03 - MIDI 1.0 Needs Its Own Finish Line

Task: Make the MIDI Protocol Coverage panel distinguish current MIDI 1.0 readiness from deferred future protocol families.

What connects creatively: MPE and MIDI 2.0 matter, but they should not make the app feel unfinished when the current commercial target is rock-solid MIDI 1.0. A user, tester, or future developer should be able to open the protocol panel and instantly understand: "what must be true for this release" versus "what belongs to the roadmap."

Architecture choice: The visible protocol panel now draws a dedicated MIDI 1.0 finish-line progress row and a future/not-blocking count, both fed by MidiProtocolCoverageReport. The next-closeout card quotes nextCloseoutFocusSummary() and productReadyBlockerCategorySummary() directly instead of deriving its own shorter local wording.

Future extensions: This same split should inform release notes, QA checklists, Kickstarter promises, and the eventual public roadmap. We can promise MIDI 1.0 confidence without accidentally implying MPE or MIDI 2.0 are already part of v1.

2026-07-03 - Name The Remaining Expression Gap Precisely

Task: Update MIDI protocol wording so first-pass MIDI EXPR scope drawing gets credit without pretending the final expression-lane workflow is complete.

What connects creatively: If project reports keep saying "drawable expression lanes are missing," future work may waste time rebuilding a thing that already partly exists. If the reports say "everything is finished," we ship a cramped first-pass surface as if it were a mature composition tool. The truthful middle is the useful one: compact drawing exists; the remaining product work is bigger, more tactile, Piano Roll-grade editing.

Architecture choice: The MIDI Protocol Coverage text now names compact step-snapped selected-scope drawing as implemented for controller, pitch-bend, and pressure lanes. The blocker language now points to value feedback, curve polish, destination bend policy, switch-block trim, and the future clip/lane-local automation path.

Future extensions: This precision should guide the future Motion Clips and automation-lane work too. When a first-pass editor exists, the report should identify whether the missing piece is scale, gesture quality, ownership, safety, or visual clarity.

2026-07-03 - SysEx Capture Is Real, ACK Is The Finish Line

Task: Update MIDI protocol and SysEx readiness language so SpaceAge credits the first live one-dump capture workflow instead of reporting capture as missing.

What connects creatively: SysEx needs unusual honesty because it can change real hardware. SpaceAge now has a useful trust ladder: import or arm capture, review the dump, save it into the Vault, attach it to a Hardware Passport, and only then queue an explicit restore. The next trust layer is not "can we capture bytes?" but "can we prove the external device accepted them?"

Architecture choice: Keep SysExLibrarianReadinessPlan and SysExCaptureReadinessPlan aligned with the actual UI: ARM/CANCEL/SAVE/COPY capture exists, one complete F0...F7 dump can become a confirmation-required Vault snapshot, and restore progress remains estimated-only until a manual verification receipt or device ACK/NAK receipt covers the restore.

Future extensions: Add device-specific ACK parsers, live multi-dump batch capture/bulk-dump sessions, richer checksum/device-id helpers, and restore history receipts that distinguish sent, estimated-complete, manually verified, device-acknowledged, device-rejected, and timed-out states. The existing timeout/countdown and source-guidance work should become part of that larger guided ritual instead of being reimplemented in the editor.

2026-07-03 - Expression Targets Need One Trusted Sentence

Task: Add a model-owned MIDI EXPR target summary for copied reports and future expression UI.

What connects creatively: MIDI expression lanes are easy to make mysterious because the same drawing surface may represent a mod wheel curve, pitch bend, sustain blocks, pressure, or review-only hardware setup data. A single target sentence gives the user and the support report a clear answer: "what surface is active, what gesture belongs here, what values mean, and what is still not final?"

Architecture choice: MidiExpressionEditorPlan now owns targetSummary(), combining active surface, gesture, snap behavior, value range, preview density, product-ready status, remaining final-editor gap, and warnings. The copied MIDI Expression report consumes that summary instead of hand-assembling separate fragments in the report body.

Future extensions: The full Piano Roll expression editor, Motion Clips, MPE-style per-note lanes, and synth/effect automation should all expose a similar target summary so every drawn performance shape can explain itself without relying on tooltips or memory.

2026-07-03 - Tiny MIDI Rows Need Breadcrumbs, Not Novels

Task: Keep compact MIDI warning surfaces readable while still admitting that more detail exists.

What connects creatively: MIDI setup has a lot of nested truth: one lane can have missing hardware, an export-only route, profile mismatch, and runtime output trouble all at once. Trying to squeeze every problem into a tiny row makes the interface feel broken; hiding the detail makes the interface feel untrustworthy. The better move is a breadcrumb: show the first useful reason, then say +N more and point to the copied report or the full MIDI panel.

Architecture choice: External MIDI output lane summaries now own a compact warning label, and the Settings MIDI cards add +N detail(s) in MIDI... cues plus tooltips. This keeps the small surfaces calm while preserving the model-owned reports as the full diagnostic source.

Future extensions: The same pattern belongs anywhere SpaceAge compresses complex state: plugin scans, missing assets, project archive validation, SoundFont pool health, render preflight, and future VST hosting. Small card first, full report second.

2026-07-03 - A Dropped SoundFont Voice Is Better Than A Late One

Task: Remove the last obvious SoundFont note-start latency trap from the live MIDI path.

What connects creatively: A musician can forgive a diagnostic that says "your giant SoundFont exceeded the prepared voice pool." They will not forgive a live note arriving 40 ms late and making the whole instrument feel sluggish. MIDI Health already knows how to report SoundFont pool pressure, so the realtime path should choose honesty over hidden heroics.

Architecture choice: SoundFont live note start now borrows only from the prewarmed TSF voice pool. If that pool is exhausted or stale, SpaceAge increments the refused-live-start counter and returns no voice instead of locking soundFontMutex and cloning TinySoundFont state during note start.

2026-07-03 - Live MIDI Should Reach The Door Before The Sequencer Locks The Room

Task: Process incoming live MIDI before sequencer pattern reads can wait on patternMutex.

What connects creatively: A controller note is a physical gesture. If SpaceAge lets arrangement playback inspect pattern data first, a UI edit holding the pattern lock can make a musician feel late even though the MIDI event itself was sample-positioned correctly. The feel of the instrument begins at the first branch in the audio callback, not just at voice rendering.

Architecture choice: processBlock() now snapshots block-start timing, observes sync/chase messages, then handles incoming MIDI before calling processSequencer(). Recording placement still uses the same block-start step/sample snapshot, but live monitoring no longer waits behind sequencer pattern reads.

Future extensions: The deeper fix is an immutable sequencer playback snapshot so arrangement playback also avoids patternMutex in the callback. This pass is the correct ordering improvement; the snapshot pass is the eventual realtime-polish finish.

Future extensions: The next refinement is adaptive pool sizing per SoundFont/lane/preset, a visible "pool pressure" recommendation, and possibly a background prewarm job after sample-rate or preset changes. The important boundary remains: no huge resource cloning on the live note-start path.

2026-07-03 - Big Instruments Need Small Decisions At Note Time

Task: Move Quasar's zone selection work out of live note start.

What connects creatively: Quasar is supposed to become a beautiful proprietary multisample format, not a hidden tax on MIDI feel. If a user builds a large multisampled bass, marimba, or future "Loop on Release" instrument, the first note should not have to rummage through every zone while the player waits.

Architecture choice: Quasar now publishes a note/velocity lookup table when its package is loaded or refreshed. A live note asks for the best matches for its MIDI note and velocity, advances the existing round-robin cursor, and starts the chosen zone directly.

Future extensions: The same idea should guide Instrument Bay, SoundFont, future VST preset browsing, and sample-browser metadata: do expensive organization at load/edit time, then keep performance-time choices tiny, predictable, and explainable in MIDI Health.

2026-07-03 - Reserve The Runway Before The Aircraft Moves

Task: Keep shared send buffers from resizing during ordinary audio callbacks.

What connects creatively: Reverb, delay, chorus, and future Motion Clip sends are part of the musical performance, not backstage bookkeeping. If a host block surprises SpaceAge with a slightly larger buffer, the app should already have enough runway prepared rather than allocating memory during playback.

Architecture choice: prepareToPlay() now reserves a 32k-sample send-buffer runway for the shared effect sends and prepares Halostar/EchoRay-side processing against that larger safe size. The emergency resize path remains for truly abnormal host behavior, but normal live use should not touch it.

Future extensions: MIDI Health can eventually report if an emergency audio-callback resize ever happened, which would make driver/host weirdness visible instead of mysterious.

2026-07-03 - SysEx Capture Needs A Countdown, Not A Guess

Task: Add timeout and countdown state to armed live SysEx capture.

What connects creatively: A musician dumping a patch from old hardware needs immediate trust feedback. If SpaceAge says "armed" forever after nothing arrives, the user has to guess whether the wrong cable is connected, the hardware failed to transmit, or the app missed the dump. A countdown turns a vague wait into a clear ritual: arm, send dump, review receipt, save to Vault.

Architecture choice: Keep the timeout in the processor/model layer, not the editor. SysExCaptureReadinessPlan and SysExCaptureProgress now carry timeout length, remaining time, and timed-out state. Capture auto-disarms after the 60-second window, and late dumps are ignored unless the user arms capture again.

Future extensions: Batch capture can reuse the same clock but should count each expected dump separately. Hardware Passport source guidance, checksum/device-id helpers, generic ACK/NAK classification, and future device-specific restore progress should all preserve the same honesty: SpaceAge must say what it knows, what it is waiting for, and what the hardware must still confirm.

2026-07-03 - SysEx Capture Guidance Should Teach Without Touching Hardware

Task: Add source-guidance lines to SysEx capture readiness/progress.

What connects creatively: Hardware SysEx is one of the places where SpaceAge can feel more humane than a normal DAW. The app can tell the user what ritual to perform without acting on their behalf: cable from MIDI OUT, find the dump/transmit page, arm SpaceAge, send one dump, review the receipt, then save it. That is a guided cockpit instead of a scary blank socket.

Architecture choice: Keep source guidance in the MIDI model beside the readiness/progress report. The editor can display or copy the same lines, Hardware Passports can refine them later, and support reports can reproduce the exact instructions the user saw.

Future extensions: Device-specific Hardware Passport scripts can eventually add exact menu paths for QY-70/QY-100, MiniNova, Volca-style gear, drum machines, and future XG workflows. The same source-guidance pattern should also help MIDI input setup, timing calibration, and controller expression onboarding.

2026-07-03 - Batch SysEx Capture Starts As A Contract

Task: Add a read-only batch capture plan before wiring any live multi-dump capture behavior.

What connects creatively: Bulk SysEx capture is powerful but risky because hardware can dump whole banks, global settings, or song memory in a burst. The humane workflow is not "catch whatever arrives." It is a visible contract: what device is sending, how many dumps are expected, how long each dump window lasts, what has been captured so far, and what still requires review before anything becomes part of the Vault.

Architecture choice: SysExBatchCapturePlan is deliberately non-sending and non-mutating. It can explain expected/captured dump counts, source/target context, per-dump timeout, explicit-start policy, confirmation defaults, warnings, and missing live UI pieces while keeping batchDumpWorkflowReady false. This gives Settings, SysEx Vault, MIDI Health, tests, and future Hardware Passport scripts one model-owned vocabulary before we build the live batch inbox.

Future extensions: The real batch workflow should capture each dump into its own receipt, reset timeout per dump, detect duplicates/out-of-order sends, let the user save/skip individual dumps, and keep restore trust separate from estimated pacing until generic ACK/NAK, profile-specific ACK/NAK, or manual verification exists.

2026-07-03 - SysEx Restore Progress Needs Two Truths

Task: Add a reusable restore-progress trust plan that separates SpaceAge-side pacing from hardware acknowledgement.

What connects creatively: Vintage hardware workflows are part engineering and part reassurance. A progress readout should comfort the musician, but only if it is honest about what SpaceAge actually knows. The same philosophy applies to render progress, Quasar package builds, SoundFont repair, and future AI-assisted hardware setup: distinguish "we are doing our part" from "the outside world confirmed success."

Architecture choice: SysExRestoreProgressPlan now owns stored dump count, byte totals, DIN wire estimates, paced completion, confirmation requirements, warning counts, and ACK state. SysExLibrarianReadinessPlan can now say estimated restore progress is available while product-ready restore progress remains false. That gives future UI a clean two-lane display: SpaceAge estimated transfer progress on one side, hardware ACK/NAK or manual verification on the other.

Future extensions: Add device-specific ACK/NAK parsers, manual "verified on hardware" receipts, per-dump restore history, retry/abort language, and a restore-progress panel that never collapses estimated completion and hardware acceptance into the same visual signal.

2026-07-03 - SysEx Restore Receipts Need A Trust Ladder

Task: Add a model-owned restore verification receipt vocabulary.

What connects creatively: A hardware restore is not one event. It is a chain of confidence: SpaceAge can preview bytes, pace the send, estimate completion, wait for device response, record a timeout, or accept the user's manual confirmation that the target hardware sounds or looks correct. If those are flattened into one "success" label, old synth workflows become spooky and support conversations become muddy. Treating them as receipt states lets the future Vault and Hardware Passport UI speak like a calm engineer: "I estimated it," "you verified it," "the device ACKed it," "the device rejected it," or "the device never answered."

Architecture choice: SysExRestoreVerificationReceipt now separates no verification, manual verified, device ACK, device NAK, and timeout. Manual verification can make a restore practically usable without pretending the hardware generated an ACK. SysExRestoreProgressPlan can count manual verification coverage beside generic/device acknowledgement states, while still reporting that reports and receipts never send MIDI by themselves.

Future extensions: Add device-specific ACK/NAK parsers, checksum-repair helpers, timed retry policy, restore history per Hardware Passport, and a Vault UI that shows estimated transfer progress on one row and verification receipts on another.

2026-07-03 - Generic SysEx Replies Need A Humble Interpreter

Task: Add a conservative restore-response classifier for incoming SysEx replies after a restore attempt.

What connects creatively: Hardware support earns trust by saying exactly what happened. A generic MIDI Sample Dump ACK is useful evidence, but it is not the same thing as a Yamaha QY-specific success screen or a MiniNova-specific librarian reply. Treating ACK, NAK, WAIT, CANCEL, invalid SysEx, and unrelated valid SysEx as separate states gives SpaceAge a calm hardware cockpit: "the device answered," "the device rejected it," "wait and retry," or "that message belongs to something else."

Architecture choice: SysExRestoreResponseClassification sits between raw incoming bytes and restore receipts. It recognizes standard Sample Dump-style ACK/NAK/WAIT/CANCEL responses, builds serializable reports for UI/support, and bridges final generic outcomes into SysExRestoreVerificationReceipt without sending MIDI itself. Unrecognized valid SysEx is explicitly unrelated, so a random Identity Reply cannot inflate product-ready trust.

Future extensions: Correlate replies to active restore attempts in the UI, add retry timers for WAIT, preserve restore-response history per Hardware Passport, and let device profiles register their own response dialects without weakening the generic safety layer.

2026-07-03 - Restore Responses Should Become A Project Memory

Task: Route incoming SysEx restore replies through a processor-owned active-attempt queue and receipt history.

What connects creatively: Once SpaceAge queues a SysEx restore, an incoming ACK/NAK/WAIT/CANCEL-style reply should not vanish into live capture or raw MIDI noise. Treating it as a restore verification receipt creates project memory: "we sent this dump, this device answered, and this is what the answer meant." That memory can later surface in MIDI Health, Hardware Passport history, archive export, and support reports.

Architecture choice: Confirmed SysEx recall now registers an active restore attempt only after the message queues successfully. Incoming SysEx is copied into a bounded restore-response worker queue, classified off the live MIDI path, logged as a receipt, and clears the active attempt only on final ACK/NAK/CANCEL-style responses. WAIT stays active because the hardware has not confirmed success yet.

Future extensions: Deepen the restore-response history with filtering, export, green acknowledged / amber waiting-manual / red rejected grouping, retry timing for WAIT, and Hardware Passport vendor-specific response parsers.

2026-07-03 - MPE Honesty Belongs In The First Line

Task: Make compact MIDI Health headlines mention MPE-like / multi-channel expression when a loaded project contains it.

What connects creatively: MPE-like data is not a bug, but it is also not ordinary one-channel MIDI. If SpaceAge quietly preserves it while only burying the warning in a full report, the user may assume the project is simpler than it is. A short headline cue makes the app feel more like an attentive engineer: "I preserved this, but treat it with care until true MPE policy exists."

Architecture choice: Keep detailed detection in MidiExpressionProjectSummary, roll its warning into top-level MIDI Health, and add the MPE-like pattern count to the compact headline only when relevant. The first line stays calm for normal projects and becomes honest for channel-per-note-looking projects.

Future extensions: When SpaceAge eventually gains real MPE zones, member-channel allocation, bend-range policy, and MPE-aware synth response, this same headline slot can graduate from warning language to a proper "MPE ready" or "MPE preserved" badge.

2026-07-03 - Closeout Language Must Age With The Code

Task: Refresh MIDI Protocol Coverage next-focus wording after first-pass expression drawing and import policies landed.

What connects creatively: A stale blocker sentence can quietly mismanage the whole project. If the dashboard says "build drawable expression lanes" after a compact drawing surface already exists, we risk duplicating work instead of finishing the real gap: tactile Piano Roll-grade editing. If it says "finish channel import" after safe splitting exists, we miss the harder conductor-map/setup-data problem.

Architecture choice: Keep blocker categories stable, but make their recommended-focus copy describe the current missing layer. Expression Editor now points to full Piano Roll-grade handles/curves/ownership, and Import Wizard now points to setup-data decisions plus full tempo/meter/key map adoption.

Future extensions: Treat every closeout pass as both code work and self-knowledge work. When a first-pass surface becomes real, update the model-owned guidance so Settings, reports, QA, and future agents aim at the remaining edge instead of yesterday's hole.

2026-07-03 - MIDI Learn Is Completion Work, Not Vague Polish

Task: Rename the MIDI Learn blocker category from MIDI Learn Polish to MIDI Learn Completion.

What connects creatively: Hardware control is one of the places where "almost done" can still feel broken. A musician twisting a real knob expects it to bind clearly, resolve conflicts, respect pickup behavior, and explain high-resolution controller pairs. Calling the remaining work "polish" undersells how much trust this workflow carries.

Architecture choice: Keep MIDI Learn as a product-readiness blocker, but rename the category to MIDI Learn Completion. The status model now points to direct-control coverage, richer high-resolution diagnostics, conflict browsing, and curve polish as remaining work, while the category name still sounds like a real release gate.

Future extensions: Once complete direct learn, high-resolution diagnostics/meters, conflict browsing, and curve editing are genuinely mature, downgrade the category from blocker to normal refinement instead of letting it linger as an ambiguous nearly-finished bucket.

2026-07-03 - Expression Editing Needs A Checklist, Not A Vibe

Task: Add a model-owned final-editor checklist to MIDI expression lane plans.

What connects creatively: Continuous controller editing is going to touch several worlds at once: MIDI guitars, wind controllers, synth automation, pitch-bend slides, MPE-adjacent imports, and future Motion Clips. If the app merely says "needs polish," every future pass can interpret that differently. A checklist lets the same truth drive Settings, MIDI EXPR, Piano Roll, docs, QA, and eventual customer-facing help.

Architecture choice: MidiExpressionEditorPlan now carries finalEditorChecklist rows. Generic drawable lanes ask for clip-local ownership, Piano Roll-style lasso/multi-select, visible handles, and smoothing/thinning preview. Special lanes add their own requirements: switch-block edge handles, pitch-bend center line plus destination bend policy, bipolar center feedback, poly-aftertouch note-row ownership, and channel-pressure channel badges.

Future extensions: When the full Piano Roll-grade expression editor is built, its implementation checklist should close these rows one by one instead of inventing new criteria. The same checklist pattern can later govern Motion Clips, automation curves, Flux Nodes, and expressive hardware profiles.

2026-07-03 - Fast Expression Drawing Should Not Drop Musical Intent

Task: Interpolate selected-scope MIDI EXPR drawing between mouse drag points.

What connects creatively: A musician drawing breath, filter, pitch, or mod-wheel expression is thinking in gestures, not individual protocol events. If the mouse moves quickly and SpaceAge only writes wherever the operating system happened to deliver mouse events, the resulting curve can feel jagged or incomplete. Filling the snapped grid points between drag positions makes the compact editor feel more like a musical drawing tool and less like a debug view.

Architecture choice: The MIDI EXPR selected-scope writer now remembers the last drawn tick/value during a drag. Continuous lanes write interpolated stepped values between the old and new cursor positions; switch lanes fill the same span with the current on/off value. The implementation stays pattern-local and uses the existing checkpoint path, so it improves feel without changing ownership semantics yet.

Future extensions: This same interpolation idea should become the foundation for full Piano Roll-grade expression curves, Motion Clip envelopes, velocity-paint smoothing, and future automation lanes. Later versions can add spline handles, thinning previews, and pressure-sensitive input while preserving the same "gesture first, events second" philosophy.

2026-07-03 - Expression Erasing Should Be Local And Tactile

Task: Let the MIDI EXPR selected-scope graph erase the selected lane across the snapped steps under the mouse.

What connects creatively: Drawing expression and erasing expression are the same musical gesture family. If a user can paint breath, pitch bend, sustain, or mod wheel into a timeline, they should also be able to scrub a bad phrase out with a right-drag. This is the same philosophy behind right-click note deletion, velocity painting, and future clip/Motion Clip editing: the object under the cursor should be the object being edited.

Architecture choice: The selected-scope graph now uses the same timeline-to-step snapping logic for right-drag erasing that it uses for drawing. It fills skipped erase steps during fast drags, keeps the whole gesture under one checkpoint, and still respects shared-pattern warnings and setup-lane protection. Draw and erase status messages are restored after lane refresh so the panel tells the user where the gesture actually landed.

Future extensions: The full Piano Roll-grade expression editor should grow from this into visible point handles, block-edge handles for switch lanes, lasso selection, delete/backspace support, and spline/curve editing. The same local edit/remove pattern can later apply to Motion Clips, automation curves, Chord Engine velocity/strum lanes, and Flux Node parameter lanes.

2026-07-03 - MIDI Learn Should Let The User Narrow The Ear

Task: Expose source-type filters for the next MIDI Learn capture.

What connects creatively: A modern controller may send several kinds of MIDI from one physical gesture: a knob sends CC, a wheel sends pitch bend, a keybed may send pressure, and expressive devices may send poly aftertouch. If SpaceAge listens to everything all the time, Learn becomes fast but a little jumpy. Letting the user narrow what SpaceAge is listening for keeps Learn feeling like a focused conversation with the hardware instead of a guessing game.

Architecture choice: Keep the filter on the armed MidiLearnRequest, not as a UI-only preference. MIDI Maps now exposes CC, pitch bend, channel pressure, and poly aftertouch toggles, and the processor uses those booleans before it previews or captures a mapping. The panel restores CC if all filters are disabled so the user cannot accidentally arm a deaf Learn request.

Future extensions: Reuse this "narrow the ear" idea in a Hardware Setup wizard, per-lane MIDI input filters, MPE member-channel onboarding, and future automation capture. A user recording breath controller, guitar bend, or external synth knobs should always be able to say, "listen for this kind of movement right now."

2026-07-03 - High-Resolution MIDI Should Be A Choice, Not A Guess

Task: Add explicit Auto / 7-bit / 14-bit resolution modes to learned CC mappings.

What connects creatively: MIDI has a charming old-world problem: some controls are simple 7-bit gestures, while some transmit a coarse MSB plus a fine LSB companion for 14-bit resolution. Auto-detection is useful, but hidden auto-detection can make a hardware rig feel haunted when a controller sometimes sends fine data and sometimes does not. A tiny source-row mode switch lets SpaceAge stay helpful without becoming mysterious.

Architecture choice: Store resolution behavior on the mapping itself. AUTO keeps the existing high-resolution pairing when fine CC traffic arrives, 7BIT forces coarse behavior and ignores the fine companion, and 14BIT waits for both coarse and fine values before updating the target. The setting resets high-resolution pair state when changed, travels with the project, and shows up in MIDI Maps summaries instead of living as a temporary panel preference.

Future extensions: Reuse this "explicit mode over hidden magic" pattern for MIDI 2.0 resolution, MPE zone policies, external hardware input filters, and future automation-capture precision. When a feature has both a smart default and a professional edge case, make the default easy but keep the edge case visible.

2026-07-04 - MPE Honesty Needs A Policy Card

Task: Add a model-owned MPE Readiness Policy to MIDI Health.

What connects creatively: MPE is attractive to expressive-controller players, but it is also dangerous marketing territory if we blur the line between "we preserved the data" and "we truly own the protocol." SpaceAge already preserves multi-channel pitch, pressure, poly aftertouch, and CC74-style timbre data as MIDI 1.0 expression. The new policy card makes that honesty explicit, which lets the app feel trustworthy instead of evasive.

Architecture choice: Keep MPE readiness in the MIDI model layer next to expression health, not inside playback or the editor. MIDI Health now serializes counts, policy labels, true-MPE booleans, review guidance, warning text, and a remaining-work checklist from one MidiMpeReadinessPolicy object. This lets reports, support bundles, and future UI badges quote the same source without pretending that MPE zones, member-channel ownership, bend ranges, or synth response are finished.

Future extensions: When true MPE begins, this same card can grow into lane-level zone setup, member-channel allocation, per-note pitch/timbre/pressure ownership, bend-range negotiation, import/export validation, and MPE-aware internal synth response. The key is that the card already reserves the conceptual space without making a false promise today.

2026-07-04 - Product Readiness Scores Must Say What Product Means

Task: Tighten MIDI Protocol Coverage so readiness scores describe the current MIDI 1.0 release target instead of accidentally counting deferred MPE/MIDI 2.0 roadmap rows as product-ready.

What connects creatively: A good health report is a promise. If SpaceAge says a protocol surface is "product ready," the phrase has to map to something a musician can trust today. MPE and MIDI 2.0 should stay visible as ambitions, but the main readiness meter should answer the near-term question: "Can I make, route, import, export, learn, sync, and troubleshoot MIDI 1.0 work without fear?"

Architecture choice: Keep the deferred-family split in the model and make productReadinessPercent() mirror the current MIDI 1.0 finish-line calculation. The UI label now names that target, and expression reports use "selected-pattern" wording to match the real ownership model. This prevents a future marketing or support copy/paste from turning roadmap visibility into an accidental claim.

Future extensions: When true MPE or MIDI 2.0 becomes a release target, add a separate protocol-readiness score for that target instead of stretching the MIDI 1.0 score. The same pattern can serve future VST hosting, hardware librarian, and Motion Clip readiness dashboards: one score per promise.

2026-07-04 - Health Dashboards Should Not Repeat The Same Meter Twice

Task: Clean up the MIDI Protocol Coverage panel and reports after the current MIDI 1.0 finish-line score became the product-readiness score.

What connects creatively: A dashboard should make the next action obvious. Showing two progress bars with the same calculation creates the illusion of two separate truths and makes the user scan harder. Turning one of those rows into a blocker-count card is more useful: the musician sees the score, the number of release blockers, and the future-protocol bucket without needing to decode our internal model.

Architecture choice: Keep productReadinessPercent() as a compatibility alias for the current MIDI 1.0 finish-line score, but avoid presenting it as a second independent meter. The Settings panel now shows MIDI 1.0 BLOCKERS as a count card beside backend-ready/UI-pending work, while the finish-line progress row remains the single release-readiness meter. Expression ownership labels now say pattern-owned, matching the actual storage model and the shared-pattern guard.

Future extensions: Apply the same rule to Instrument Bay, Effects, Quasar, and future VST/MPE dashboards: avoid duplicate meters, make blockers concrete, and keep deferred roadmap items visible without letting them contaminate the current release promise.

2026-07-04 - Release Checklists Should Come From The Model

Task: Add a model-owned current MIDI 1.0 closeout checklist to the MIDI Protocol Coverage report.

What connects creatively: SpaceAge is now large enough that "what's next?" can become its own confusion trap. A release checklist generated from the same model that feeds the Settings dashboard keeps the work grounded: blocker categories, affected families, release role, recommended focus, and first action all come from one place. That turns the dashboard into a navigation instrument instead of a static scorecard.

Architecture choice: MidiProtocolCoverageReport::currentFinishLineCloseoutChecklist() walks the prioritized blocker categories and renders the current MIDI 1.0 finish-line checklist. It deliberately excludes deferred future families such as MPE/MIDI 2.0. The checklist is included in the plain-text report and serialized payload, so future UI, support bundles, or manual pages can quote it without rebuilding the logic in PluginEditor.

Future extensions: Use this same model-owned checklist pattern for Instrument Bay finalization, VST hosting, Quasar packaging, Effects Rack readiness, and MPE/MIDI 2.0 once they become explicit release targets.

2026-07-04 - Split Working Core From Launch Polish

Task: Refine MIDI Protocol Coverage so SysEx and MIDI export distinguish implemented core behavior from unfinished release polish.

What connects creatively: A protocol row that says "SysEx" or "MIDI File Export" is too broad once part of the feature is real. SpaceAge can safely import/store/capture one SysEx dump today without being a full device-specific librarian, and it can export useful MIDI today without having the whole collaborator package/repair cockpit finished. Splitting those rows keeps morale and release planning sane: we credit the working foundation without sweeping the remaining trust work under the rug.

Architecture choice: SysEx Core Safety and MIDI Export Core are now non-blocking current MIDI 1.0 rows. SysEx Device-Specific Librarian Polish and MIDI Package And Repair Polish carry the active blocker categories. The polish rows deliberately do not inflate backend-ready/UI-ready counts, because their missing work includes real model, device, validation, and user-facing behavior.

Future extensions: Apply this split whenever a large family becomes half-real: VST hosting core versus scanner/quarantine polish, Quasar package creation versus package repair, Instrument Bay selection versus preset metadata browsing, or MPE preservation versus true zone ownership.

2026-07-04 - Expression Closeout Needs A Project-Level Checklist

Task: Roll MIDI AUTO editor closeout items into the project health summary.

What connects creatively: A musician does not care that SpaceAge has a class named MidiExpressionEditorPlan; they care whether pitch bend, pressure, sustain, and CC lanes are safe to see, select, reshape, thin, and trust. By rolling the lane-level editor checklist into MIDI Health, the app can tell us what a real project actually needs before the MIDI AUTO workflow feels finished. This turns a vague "finish MIDI AUTO editor" blocker into a scoreable set of visible behaviors.

Architecture choice: Keep the checklist in the MIDI model path. PluginProcessor now asks each lane's MidiExpressionEditorPlan for its final-editor checklist, deduplicates those items, and stores them on MidiExpressionProjectSummary. Reports and structured payloads can now quote that list without reclassifying raw controller events or hardcoding UI advice in PluginEditor.

Future extensions: This same pattern can serve Instrument Bay, Quasar package repair, Effects Rack, and future MPE. If a user-facing workflow has multiple hidden subfeatures, the model should be able to name the missing pieces directly from the current project state.

2026-07-04 - Expression Handles Need Real Events, Not Sparklines

Task: Prepare MIDI EXPR selected-lane drawing for future draggable point handles without making the current freehand editor riskier.

What connects creatively: A tiny row preview is a useful glanceable sparkline, but a musician expects a handle to represent the actual thing they are about to grab. Treating capped preview points as editable handles would create a gorgeous lie: imported dense CC, bend, pressure, or aftertouch data could be visually simplified while the mouse claims precision. The selected scope should be where SpaceAge becomes trustworthy enough for surgical edits.

Architecture choice: The selected scope now builds a visible point model from expressionEvents for the current lane and viewport. Each painted point carries source event index, tick, value, duplicate/stack count, and a hit box. The row previews can remain capped and lightweight, while selected-scope editing uses the full visible event list. Dragging individual points is still deliberately withheld until hover, selection, shared-pattern safety, switch-block handling, and pitch-bend center semantics are wired around this model.

Future extensions: This point model can become the shared foundation for hover readouts, click-to-select, lasso, draggable point handles, switch-lane block edges, pitch-bend center-line snapping, and eventually Piano Roll expression lanes. It should also inform Motion Clips, because both workflows need to represent time-varying gestures without confusing the summarized overview with the editable truth.

2026-07-04 - Point Focus Before Point Mutation

Task: Add non-destructive MIDI expression point hover and selection without adding point delete/drag yet.

What connects creatively: The app should teach the user that expression points are real editable objects before it gives them sharp tools. A warm hover ring, white selected ring, and concrete readout make CC/bend/pressure points feel inspectable. That gives the same emotional clarity as selecting a note in the Piano Roll: "this is the thing under my hand." But because imported MIDI can contain legitimate stacked same-tick events, acting too soon would trade polish for risk.

Architecture choice: Hover and click selection use the selected-scope real-event point model. Esc clears point focus before lane focus. Delete clears selected-point focus with a safety message instead of deleting data. Real mutation waits for a processor-owned single-event helper that can validate lane identity, event identity, duplicate ordinal, shared-pattern safety, undo, sorting, and playback snapshot publication.

Future extensions: Once the helper exists, selected expression points can gain Delete, drag-to-move, value-only drag, keyboard nudges, and lasso. Switch lanes should probably expose block/edge handles rather than ordinary dots; pitch bend should show center-line behavior; poly aftertouch needs visible note ownership. This same pattern can become the model for Motion Clip node editing.

2026-07-04 - Pitch Bend Needs A Visible Home Base

Task: Add an explicit pitch-bend center cue to the MIDI EXPR selected-lane scope.

What connects creatively: Pitch bend is not just another 0-to-127 controller lane. It has a musical home base: no bend. Showing that center line gives the player a visual anchor similar to a horizon line. That same idea can later help Motion Clips, synth modulation pages, and any bipolar lane where "above" and "below" mean different musical intentions.

Architecture choice: The editor draws center-reference overlays from the lane summary's model-owned editor range. For pitch bend, the label says PITCH CENTER 8192 and reminds the user to confirm destination bend range. The UI does not pretend to know how far the hardware or synth will bend until lane/instrument/hardware profiles own that setting.

Future extensions: Add destination bend-range ownership to lane instruments and Hardware Passports, then translate 14-bit bend values into semitone/cents readouts. Once that exists, pitch-bend point dragging can snap to meaningful musical values instead of raw numbers only.

2026-07-04 - Preview Before Destructive Cleanup

Task: Make MIDI EXPR THIN REDUNDANT preview the exact transform counts before it removes events.

What connects creatively: Thinning controller data is the same family of action as sample cleanup, quantize strength, note slicing, and Motion Clip simplification: useful, but easy to overdo. A preview-first pattern lets SpaceAge stay fast without feeling reckless. It also teaches the user that the app understands consequences before it changes their work.

Architecture choice: The model already produces a MidiExpressionTransformResult with matched, kept, changed, removed, and untouched counts. The UI now uses that receipt as the first-click preview and stores only a lightweight confirmation key for the same lane/request. It recomputes the result on the second click, so the actual committed data still comes from the current processor state.

Future extensions: Reuse this pattern for audio cleanup, clip quantize, Motion Clip thinning, and any future destructive MIDI 2.0/MPE expression transforms. The ideal version eventually draws a before/after overlay, but the count-based receipt is already much safer than a blind button.

2026-07-04 - Pitch Bend Range Is Destination-Owned Until Proven Otherwise

Task: Make pitch-bend range ownership visible in MIDI EXPR and copied reports without adding a premature Hardware Passport schema field.

What connects creatively: This is one of those quiet MIDI gotchas that can make a musician distrust the whole app. The curve can look perfect, the raw 14-bit data can be preserved, and the note can still bend the wrong musical distance if the destination synth or external box expects a different semitone range. Making "destination-owned" visible now protects MIDI guitar, wind controller, expressive synth, and future MPE workflows from a false sense of precision.

Architecture choice: Keep the warning in MidiExpressionEditorPlan and expression reports, not scattered UI copy or a half-owned hardware profile field. SpaceAge stores pitch bend as raw 14-bit data centered at 8192, and the internal engine can now follow standard RPN 0,0 Pitch Bend Range when absolute Data Entry arrives. That still does not replace a visible lane/instrument/Hardware Passport bend-range policy, so editor reports continue to warn when the destination range is not explicitly owned by the project.

Future extensions: Add a real per-lane/per-instrument/per-hardware bend-range policy, translate trusted bend ranges into semitone/cents readouts, and decide how relative Data Increment/Decrement should behave before it changes playback. The same ownership pattern should guide MPE zones, guitar string channels, wind-controller profiles, and any Motion Clip that controls pitch.

2026-07-04 - Delete The One Point Under Your Hand

Task: Turn MIDI EXPR selected-point deletion from a focus-only placeholder into a guarded one-event delete.

What connects creatively: Expression editing should feel like note editing: select the thing, press Delete, and the thing goes away. But controller curves can contain stacked same-tick data, especially from imported files or dense hardware gestures. Deleting "the point" must mean the actual visible event the user selected, not every event nearby or every event that happens to share a tick.

Architecture choice: Add a processor-owned removeMidiExpressionEventAtIndex() helper that revalidates pattern, event index, lane identity, and tick before mutating. The editor still uses the shared-pattern guard and checkpoint path before calling it. This keeps the UI expressive without bypassing the backend safety rules that protect shared patterns, setup data, and stacked expression events.

Future extensions: Reuse this exact point-identity idea for dragging, keyboard nudging, lasso deletion, switch-block edge edits, and Motion Clip nodes. The eventual richer editor should carry stable point ids or generation stamps, but index-plus-lane-plus-tick validation is a good first safe step.

2026-07-04 - Value Drag Before Time Drag

Task: Add guarded MIDI EXPR point value-dragging while keeping the selected point locked to its original tick.

What connects creatively: This is the same discipline we learned from clip dragging, note resizing, and section-marker work: do the obvious hand motion, but avoid the hidden destructive interpretation. A musician grabbing a controller point often wants "make this higher/lower" before they want "move this to another beat." Locking the tick during the first value-drag pass turns the scope graph into a safer sonic sculpting surface and avoids accidental curve smears in dense imported MIDI.

Architecture choice: The editor now starts with a real event index, lane identity, and tick, then the processor revalidates those facts before changing the value. Undo/checkpoint happens only when the drag actually changes data. Shared patterns still require explicit acknowledgement before mutation, but simple point selection stays harmless.

Future extensions: Add horizontal point nudging only after the editor owns collision rules for same-tick events, switch-block edge handles, and pitch-bend center snapping. This same one-object-first principle should guide Motion Clip node edits, future automation curves, and any AI-assisted simplification tool that rewrites dense controller data.

2026-07-04 - Selected Points Deserve Keyboard Hands

Task: Add Up/Down keyboard nudging for selected MIDI EXPR points.

What connects creatively: Once a point can be selected and value-dragged, keyboard nudging is the natural expert accelerator. It mirrors how notes, clips, and many DAW values eventually need both mouse and keyboard access. The key is context: with a point selected, arrows sculpt the point; without a point selected, arrows keep navigating the lane list.

Architecture choice: Nudge uses the same processor-owned identity guard as point delete and point drag. It revalidates event index, lane identity, and tick, creates a checkpoint only for a real value change, and keeps pitch bend on a larger 14-bit-friendly step size while CC-style lanes use smaller 0-127 steps.

Future extensions: Add Left/Right only after horizontal point movement has collision and duplicate handling. Later, the same nudge vocabulary can serve Motion Clips, synth modulation envelopes, and clip-level automation nodes.

2026-07-04 - Time Nudging Needs Collision Manners

Task: Add Left/Right keyboard time nudging for selected MIDI EXPR points without allowing same-lane same-tick collisions.

What connects creatively: MIDI expression data can be dense and legitimate. A careless horizontal nudge could bury two controller points on the same lane and same tick, which then becomes almost impossible to explain visually in the compact editor. Refusing collisions is less magical, but it preserves trust: SpaceAge should tell the user why a move is blocked instead of hiding a stack of invisible decisions under one dot.

Architecture choice: Left/Right moves by one step; Shift+Left/Right moves by one 16-step measure. The UI preflights same-lane target collisions before checkpointing, then the processor revalidates event index, lane identity, source tick, and target collision before mutating and returning the new sorted event index.

Future extensions: A richer Piano Roll-grade expression lane can later offer horizontal drag, lasso move, and "merge/replace/stack" choices. Until then, nudge gives us precise time movement while keeping the compact MIDI EXPR editor honest.

2026-07-04 - Group Moves Before Full Lasso

Task: Add a first safe multi-point workflow to MIDI EXPR: Shift-click or Shift-drag points in the selected lane, then move the selected group left or right with the keyboard.

What connects creatively: This is the same workflow ladder we have used elsewhere in SpaceAge: make one-object editing trustworthy, then scale it up only when the model can protect the user. Shift-click grouping is less glamorous than full lasso, but it gives hardware-expression users an immediate way to move a small bend, sustain, pressure, or CC gesture without pretending the compact MIDI EXPR surface is already a full Piano Roll automation lane.

Architecture choice: The editor stores a small selected-event-index set while keeping one primary selected point for single-point value edits. Shift-click toggles individual points and Shift-drag creates a selection rectangle in the selected-lane scope. Group time moves call a processor-owned batch helper that revalidates every event index, lane identity, source tick, and expected old editor value, then refuses same-lane same-tick collisions before changing data. Group value nudging uses the same expected-state idea so stale UI data cannot overwrite the wrong point.

Future extensions: Add drag-lift movement for point groups, support proportional value scaling, provide replace/add/subtract lasso modes, and reuse the same batch-validation contract for Motion Clip nodes, tempo-map points, and any future automation curves.

2026-07-04 - Expression Copy Belongs To A Lane

Task: Add MIDI EXPR copy/paste for selected expression points, pasted at the playhead.

What connects creatively: Copy/paste is one of those quiet workflow accelerators that makes a DAW feel like it respects the user's hands. For expression data, though, it can become dangerous if the app tries to be clever too early. A pitch-bend phrase, a mod-wheel swell, and a sustain block are all "curves," but they are not musically interchangeable without a translation decision. Keeping this first version lane-local makes the feature predictable: copy the selected points, move the playhead, paste the same gesture later in the same lane.

Architecture choice: The editor owns the clipboard selection and normalizes paste timing by placing the first copied point at the current playhead. The processor owns the mutation and refuses same-lane same-tick collisions before writing anything. Ctrl+C is context-aware: selected expression points copy as MIDI expression points, while the visible COPY REPORT button remains the explicit diagnostics path.

Future extensions: A later "translate expression" dialog could copy Mod Wheel into Filter CC, scale pitch-bend into a smaller range, or paste pressure into aftertouch with musical conversion rules. This same lane-local clipboard pattern can also serve Motion Clips, tempo-map points, and synth modulation envelopes.

2026-07-04 - Select The Whole Expression Phrase

Task: Add Ctrl+A inside MIDI EXPR to select every editable point in the current expression lane.

What connects creatively: This turns expression editing from point surgery into phrase editing. A controller swell, sustain lane, breath contour, or bend gesture is often a single musical object spread across many points. Selecting the whole lane gives the user one obvious bridge into copy, paste, move, and delete without asking them to lasso a dense curve perfectly.

Architecture choice: Ctrl+A is scoped to the currently selected MIDI expression lane, not the whole pattern. Protected setup-data lanes stay review-only and produce a warning. This keeps Program/Bank/RPN/SysEx-adjacent safety language intact while making normal performance expression faster to manipulate.

Future extensions: Add selection-range commands such as select visible range, select playhead-to-loop, select same value, and select every nth point. Those can feed the same batch validation used by group moves and copy/paste.

2026-07-04 - Cut Must Copy First

Task: Add Ctrl+X for MIDI EXPR selected points.

What connects creatively: Cut is only trustworthy when paste is already trustworthy. Since Automation now has selected-row point paste, Ctrl+X becomes a natural DAW shortcut for moving an expression phrase somewhere else inside the same shared PTN row. The important emotional detail is that the user should never feel that SpaceAge deleted something before proving it knew what it was carrying.

2026-07-04 - Expression Groups Should Feel Like Notes

Task: Let selected MIDI EXPR point groups respond to Up/Down value nudges.

What connects creatively: Once expression points can be selected as a phrase, their value edits should feel like moving selected notes, clips, or chord markers. Group value nudging makes controller curves feel like musical material instead of spreadsheet entries: grab the swell, lift it, lower it, or coarse-adjust it without redrawing the whole gesture.

Architecture choice: Keep the value math in the editor, but commit the selected group through one processor-owned batch helper. The helper revalidates pattern, lane identity, source event indices, ticks, and expected old values under one lock before setting all submitted values and publishing playback once. That avoids partial nudges and stale-value overwrites while keeping undo/checkpoint behavior aligned with grouped time moves.

Future extensions: When the larger Piano Roll expression lanes arrive, this same batch-value path should power lassoed curve moves, typed value offsets, scale/compress gestures, and Motion Clip node editing.

2026-07-04 - Expression Deletes Should Be Atomic

Task: Make grouped MIDI EXPR point deletion commit as one guarded processor operation.

What connects creatively: Deleting a controller phrase should feel decisive, not brittle. If a selected bend, pressure swell, or CC gesture is going away, SpaceAge should either delete the whole selected phrase or refuse the whole operation. That keeps expression editing aligned with clip moves, note selections, and the broader "trust the edit" posture of the app.

Architecture choice: Add removeMidiExpressionEventsAtIndices() beside the existing one-point delete helper. The processor validates every selected source event index, tick, lane identity, and expected old editor value under one lock before erasing in descending index order, then sorts/publishes once. Ctrl+X and Delete now ride the same safer group-delete path when multiple points are selected.

Future extensions: This helper should become the backend for larger lasso deletes, range deletes from Piano Roll-grade expression lanes, Motion Clip node deletion, and any future "delete selected automation" command.

MIDI EXPR Mutations Should Verify The Old Value

Task: Extend stale-state protection from value edits to deletes and horizontal time moves.

What connects creatively: Expression lanes can carry multiple meaningful events close together: breath movement, pitch bend, pressure, sustain blocks, mod-wheel phrases, and future Motion Clip data. If the compact editor only checks "same lane, same tick," then a refresh-order change or same-time stack could let the user's hand act on the wrong dot. That would feel like the app betrayed their intent, especially with imported hardware performances.

Architecture choice: The processor helpers for one-point delete, grouped delete, one-point time move, and grouped time move now accept expected old editor values alongside source ticks. They validate event index, lane identity, tick, and value under patternMutex before committing. The UI gathers those values from the visible point model, so the backend remains the final authority while the user-facing gesture stays simple.

Future extensions: Use this same expected-state contract for full Piano Roll expression lanes, Motion Clip node editing, clip-local automation overlays, and any future MIDI 2.0/MPE expression surfaces where several dimensions of performance may coexist at the same musical time.

MIDI Safety Should Be Visible, Not Implied

Task: Add a guarded-edit label to MidiExpressionEditorPlan.

What connects creatively: A safety feature that only exists in code is invisible to the musician. If SpaceAge refuses stale expression edits correctly but never tells the user how the lane is being protected, the workflow still feels mysterious. The same model that tells us "draw pitch bend" or "review setup data" should also tell us whether a lane is safely editable.

Architecture choice: MidiExpressionEditorPlan now owns guardedEditLabel, and both summaries and structured payloads expose it. Editable expression lanes report that selected-point edits validate lane, tick, and expected old value before commit. Review-only lanes report that they cannot be freehand-mutated from MIDI EXPR.

Future extensions: Use this pattern in Motion Clips, SysEx librarian actions, Hardware Passport setup cards, and any destructive Arrangement operation: the model should own the safety promise, and every UI/report should reuse it.

Live MIDI Destination Must Be Explicit

Task: Make MIDI Health report the current live MIDI destination and input mode from the processor.

What connects creatively: A selected clip is where the user is looking; an armed lane is where the performance should go. Those are emotionally easy to blur, especially in a DAW that lets the user move fluidly between Arrangement, Piano Roll, Drum Composer, MIDI setup, and hardware. Reporting the live destination gives the user a small cockpit instrument: "this is where your hands are driving."

Architecture choice: Keep the performance rule in processor-owned state and expose it through MidiProjectHealthSummary. The report names the armed lane, input channel filter, play/export channel, route target, and the active note mode: recording, Step Input, Piano Roll monitoring, or drum-pad fallback. This avoids scattering slightly different explanations across Settings, lane badges, and future setup assistants.

Future extensions: Reuse this destination label in the MIDI Setup guide, lane badges, MIDI panic receipts, and recording count-in displays. When the Instrument Bay is fully independent from pads, the same rule should still hold: a lane is armed for live input; selected clips are edit targets unless the user explicitly changes the live destination.

No Armed Lane Should Be Actionable

Task: Make the "no armed MIDI lane" health repair path open the MIDI Input setup surface instead of only reporting a status message.

What connects creatively: This closes a small but important loop between diagnosis and action. If SpaceAge tells the user their controller does not have a live destination, the next click should take them to the place where that destination can be chosen. That is the difference between a report and a helpful cockpit.

Architecture choice: Keep lane arming as the live-performance truth. The Health recommendation now says plainly that selecting clips/lanes is editing context, then routes to MIDI Input setup so the user can deliberately arm the desired lane.

Future extensions: The same action could later open a focused "Arm A Lane For MIDI" wizard row, highlighting candidate lanes with instruments already loaded and warning if several lanes are trying to compete for the same controller channel.

All Sound Off Should Be Emergency-Clean

Task: Make incoming MIDI All Sound Off honor the event's sample position inside the current audio block while still behaving like an emergency hard stop.

What connects creatively: MIDI timing trust is built from many tiny promises. If normal note-offs land precisely but emergency stop messages clear voices immediately, the app has a hidden inconsistency that can show up as jitter, tails cutting early, or SoundFont cleanup weirdness. A panic-style gesture should be decisive without becoming sloppy.

Architecture choice: Add a per-voice delayed hard-stop counter and let renderVoice() retire the voice at the intended sample. The incoming MIDI handler schedules the stop just like All Notes Off schedules release, then clears the live note masks. Voice cleanup still flows through retireVoice(), so SoundFont/sample ownership stays tidy.

Future extensions: Use the same delayed-stop primitive for future per-lane panic, hardware profile panic receipts, export-safe voice flushing, and any "kill this lane now" command that needs to be musically immediate but technically predictable.

Clip Expression Timing Must Match What The Eye Sees

Task: Make generated clip/controller expression update internal synth state at the same sample offset used for plugin and hardware MIDI output.

What connects creatively: When a clip contains a bend, pressure change, sustain pedal, or CC gesture, the musician hears it as part of the clip's tiny choreography. If hardware receives it at the right place but the internal synth gets it early, SpaceAge quietly breaks the promise that the clip graphic and the sound are one object. This is especially important for future Motion Clips, visible expression lanes, and chord/arp performance shaping.

Architecture choice: Reuse the per-sample expression queue already used by incoming live MIDI. flushPendingMidiOutputEvents() now queues generated expression messages into that timing path when they are meant to affect internal state, instead of applying them immediately before audio rendering begins.

Future extensions: This timing path should become the shared bridge for Motion Clips, clip-local automation, Chord Engine strum/arp expression, and future MIDI 2.0/MPE expression dimensions.

Panic Must Cut The Hardware Line First

Task: Make Panic discard stale hardware-router queues before sending emergency reset messages.

What connects creatively: Panic is not just a button; it is a promise that SpaceAge will stop arguing and make the rig safe. If old note-ons or delayed recall messages are still queued behind the scenes, Panic can feel haunted: the user presses the red button and something old still escapes. Clearing the router queue first makes the emergency gesture emotionally and technically trustworthy.

Architecture choice: Add a router-owned queue-clear method that resets live and recall FIFOs plus their visible pending counters. Pending-counter decrements are now saturating, so MIDI Health does not report negative queue pressure if the router thread was draining while Panic cleared the backlog.

Future extensions: The same queue-clear primitive should support future per-profile panic, "stop all external hardware only," and hardware setup wizards that need to cancel a queued recall safely before starting a new one.

Hardware MIDI Should Feel Like A Patchbay With A Kill Switch

Task: Separate live hardware MIDI output from immediate recall and delayed recall/test-note traffic.

What connects creatively: External hardware is where MIDI stops being abstract and becomes a little studio full of boxes, cables, and expectations. If a test note, patch recall delay, or stale message can block live clock or sneak out after Panic, the musician loses trust. Treating the output router like a patchbay with a kill switch makes the whole hardware side feel calmer: live performance flows, setup traffic waits its turn, and Panic really means "cut the line now."

Architecture choice: The router now has separate live, immediate recall, and delayed recall queues. Enqueue operations wake the router immediately, delayed recall items use due-time scheduling instead of sleeping the thread, and immediate recall/transport messages drain before live output. Output slots carry generation tags so stale queued messages refuse to send if a device was closed or replaced. Panic clears SpaceAge queues plus JUCE scheduled messages, then broadcasts reset traffic to every open output.

Future extensions: Replace delayed recall's FIFO head-of-line behavior with a tiny due-time priority scheduler, then batch same-block hardware events per device around one shared block-origin timestamp. The same structure can feed Hardware Passport recall, MIDI timing calibration, external synth setup wizards, and future device-specific librarian workflows without making live playing feel sluggish.

Hardware Timing Calibration Needs A Metronome, Not A Countdown

Task: Fix hardware timing-calibration pulse trains so each queued pulse owns an absolute due time.

What connects creatively: Calibration is SpaceAge asking the outside world, "how late are you, really?" That question only works if SpaceAge's outgoing pulses are disciplined. A pulse train should behave like a little metronome: pulse 1 at now, pulse 2 at now plus interval, pulse 3 at now plus two intervals. If every note-off only says "wait this long from whenever I was queued," the train stops being a timing reference and becomes a pileup.

Architecture choice: Keep ordinary hardware recall and SysEx delays as conservative relative waits, but add an absolute due-time route for calibration traffic. The timing-calibration path now schedules note-on and note-off events at trainStart + pulseIndex * interval and trainStart + pulseIndex * interval + duration, while still logging the planned offset for support/progress reports.

Future extensions: Use this same absolute-time idea for any future "send a known reference pattern to hardware" workflow: MIDI latency calibration, drift measurement, external clock confidence tests, and hardware setup assistants. If a feature is meant to measure time, it needs a real timeline, not just a sequence of local delays.

Protocol Reports Should Point To Doors

Task: Add action targets to MIDI Protocol Coverage blocker rows.

What connects creatively: A report that says "Expression Editor blocker" is useful to us, but a musician needs a door. The next step should feel like cockpit guidance: "open MIDI EXPR," "open SysEx Vault," "open Import Wizard." This keeps SpaceAge from becoming a passive diagnostic wall and moves it closer to an instrument that knows how to help the user recover.

Architecture choice: The MIDI model now owns an action surface ID and label for each blocker category. The UI can render those labels without parsing English prose, copied reports become more actionable, and future dashboard buttons can route through the same model-owned metadata.

Future extensions: Make the Protocol rows clickable, let MIDI Health reuse the same action targets, and use the pattern for future diagnostics outside MIDI: broken SoundFont paths, Quasar package repair, missing samples, Motion Clip conflicts, and hardware profile mismatches.

Timing Trust Is A Chain

Task: Capture the remaining live MIDI timing risks from the timing audit.

What connects creatively: Latency is not one number. It is a chain of tiny promises: the note enters here, the controller curve lands there, transport starts at this sample, the hardware pulse leaves at that exact moment. If one link is fuzzy, the whole performance feels less physical. SpaceAge should keep turning these timing promises into named, testable contracts.

Architecture choice: This audit originally distinguished the healthiest path, incoming expression sample-draining, from then-open timing risks. Subsequent July 4 passes closed hardware-output block anchoring, incoming transport sample offsets, count-in activation ordering, live external monitoring for armed lanes, and SPP/MTC running-position chase sample offsets. The remaining risks are now sharper: real-hardware validation, jitter/offset diagnostics, and visible confidence meters.

Future extensions: A future MIDI timing cockpit could show these as separate confidence lights: input note monitor, controller expression, sequenced internal playback, sequenced hardware output, transport chase, clock follow, and record count-in. That would make advanced MIDI troubleshooting feel far less mysterious.

The Downbeat Must Count

Task: Move count-in recording activation ahead of incoming live MIDI handling for the activation block.

What connects creatively: Count-in is a psychological contract. The app says, "get ready, then play now." If the musician lands perfectly on the first real beat and SpaceAge hears it but fails to record it, the feature feels unfair even if the code is technically explainable. The downbeat has to count because the user did exactly what the app asked.

Architecture choice: Advance only the MIDI recording count-in gate before live MIDI handling. If the gate activates inside the current block, live notes at or after that sample are recorded relative to the activation point, while normal sequencer playback is still skipped for that block to preserve the old activation-block behavior.

Future extensions: The same activation-sample idea should feed visible recording countdowns, metronome flash timing, preroll, punch-in/out, loop recording, and future "record into selected clip" workflows. The user should always be able to trust that the visual start and the recorded start mean the same thing.

Hardware MIDI Needs A Shared Block Clock

Task: Anchor live hardware MIDI sample offsets to the audio block that produced them.

What connects creatively: External gear should not feel like it is being invited to the party by a sleepy assistant. If three notes belong to one chord, they need to share the same timing origin even though a background router thread is physically sending them. This connects lane playback, MIDI clock, hardware timing calibration, future external-instrument monitoring, and the user's felt sense that the hardware is really part of SpaceAge.

Architecture choice: Live hardware messages now carry both an in-block sample offset and the block-start timestamp captured in processBlock(). The hardware router uses that shared timestamp when it calls JUCE's scheduled MIDI output path, so same-block events keep their musical relationship instead of being retimed from each individual router wake-up.

Future extensions: Batch same-block hardware messages per device into one MidiBuffer, expose a jitter confidence light in MIDI Health, and compare the scheduled block anchor with accepted hardware-profile timing calibration so users can see when external devices are locked, late, or suspicious.

Transport Chase Should Happen At The Event Sample

Task: Make incoming MIDI transport edges honor their sample position inside the current audio block.

What connects creatively: Transport chase is one of those invisible features that either feels rock solid or makes the user suspicious. If a Stop arrives halfway through the buffer but SpaceAge erases the whole buffer from sample 0, the app has retroactively changed time. If a Start arrives halfway through the buffer but playback begins at sample 0, the app feels early. The command should happen where it arrived.

Architecture choice: MIDI Start/Continue now delays the first chased sequencer step to the incoming event sample, while MIDI Stop and MMC Stop/Pause set a pending in-block stop boundary. processBlock() renders sequencer material up to that boundary, then stops transport and releases voices at the same sample.

Future extensions: SPP/MTC running-position chase now uses the segmented in-block position-jump model. Remaining sync work should add MTC offset policy, measured jitter/validation, and fuller Sync/Health reporting. The same segmented model can later help punch-in/out, loop-boundary edits, and sample-accurate Arrangement marker jumps.

The Armed Lane Is The Live Patch Cable

Task: Route live MIDI input through the armed lane's external/internal target instead of treating live play as only an internal audition path.

What connects creatively: This is the bridge between "SpaceAge as an internal groovebox" and "SpaceAge as the center of a little hardware studio." The user should not have to remember a separate monitoring model for external synths. If Lane 6 is armed and says it drives a MiniNova, the controller should feel physically plugged into that lane. Selected clips remain editing context; the armed lane is the live patch cable.

Architecture choice: The live MIDI handler now snapshots the armed lane, applies its output-channel policy, and mirrors incoming notes plus performance expression/reset messages to the lane's MIDI output path at the incoming sample position when the route is External or Internal+External. Internal state updates still happen once through the sample-drained expression path, and external-only lanes suppress internal recording-monitor voices.

Future extensions: The same contract should feed visible lane monitoring meters, "monitor internal / monitor external / monitor both" UI, hardware setup assistants, and MIDI recording receipts. Program Change, Bank Select, RPN/NRPN, and other setup messages should get their own explicit live-thru policy instead of being blindly echoed from a performance gesture.

Position Chase Is A Timeline Splice

Task: Make SPP and MTC position jumps respect the MIDI event sample inside a running audio block.

What connects creatively: A hardware sequencer that sends Song Position Pointer or MTC is not politely asking SpaceAge to teleport the whole last buffer. It is moving the tape head at a specific instant. Treating that as a tiny timeline splice protects the musician's trust: pre-jump material belongs before the message, post-jump material belongs after it, and old voices should let go at the same sample where the timeline changes.

Architecture choice: Reuse the segmented transport idea from Start/Stop chase. The MIDI scan phase records an in-block jump sample and target step, processBlock() renders the segment before the jump, setSequencerAbsoluteStep() moves the timeline while scheduling voice release at that sample, and then the remaining block renders from the chased position with the correct event offsets.

Future extensions: Expose this confidence in MIDI Sync/Health as "sample-aware position chase," then add measured jitter, MTC offset, and hardware-profile calibration hints. The same segmented timeline model can later support punch-in/out, externally commanded locates, loop-boundary edits, and Arrangement marker jumps without teaching the audio engine a second timing language.

Diagnostics Should Prove Timing, Not Just Count Messages

Task: Make sample-aware SPP/MTC chase visible in MIDI Sync Preflight.

What connects creatively: A report that only says "MTC chase applied 3" is weaker than a report that says "MTC chase applied at sample 214." The same principle applies to future MIDI Clock jitter, hardware-output latency calibration, and live monitor route confidence: the UI should expose the timing fact that makes the feature trustworthy.

Architecture choice: MidiSyncRuntimeSummary now carries last SPP/MTC chase sample offsets from the processor into plain-text reports, structured payloads, and the visible preflight panel.

Future extensions: This can evolve into a compact hardware-sync confidence meter: last chase sample, observed jitter range, estimated output offset, and a warning when incoming hardware messages arrive too close to the block edge for comfortable editing feedback.

Release Velocity Belongs To The Message

Task: Preserve MIDI note-off release velocity where SpaceAge stores and reconstructs raw MIDI event data.

What connects creatively: Most musicians never think about note-off velocity until they play a keyboard, wind controller, or sample library that responds to release gestures. If SpaceAge silently flattens that detail, expressive hardware feels less alive. Preserving the message now gives future instruments, SoundFonts, Quasar packages, and hardware pass-through a truthful foundation even before we expose a dedicated editor.

Architecture choice: Keep release velocity in the existing MidiEvent::data2 slot for note-off events, the same way note-on velocity already lives there. The shared message reconstruction helper now emits a velocity-bearing note-off, and MIDI descriptions report Rel Vel so inspections and support logs show what actually exists in the data.

Future extensions: Add a Piano Roll release-velocity lane, import/export tests for nonzero release velocities, SoundFont/Quasar release-sample response, and hardware-profile notes for controllers whose release gestures matter musically.

Hardware Input Identity Needs A Real Owner

Task: Make MIDI Input readiness reports distinguish saved input-device selection from enforceable live per-event source filtering.

What connects creatively: A user with two controllers should be able to ask "which one is driving this lane?" and get an answer that is true, not merely optimistic. This same truth will matter for Hardware Passports, first-run hardware setup, AI help, troubleshooting reports, and the eventual standalone hardware manager. If the app cannot identify the physical source of each incoming event in the current path, it should say so gracefully and then explain what it can enforce today.

Architecture choice: Keep the existing lane/device fields, visibility checks, and channel filters, but give direct physical MIDI input a real processor-owned router. The router opens only lane-referenced MidiInput devices, queues callback messages by source device, and drains them in processBlock() through the same armed-lane, channel-filter, recording, expression, MIDI Learn, SysEx, and sync paths. Host/plugin MIDI can still arrive as a source-agnostic stream, so reports must explain both realities instead of pretending one path covers every host.

Future extensions: Add an explicit host-vs-direct input preference/de-dupe policy, real-hardware validation with several controllers, and a setup assistant step that proves the intended controller path before recording.

MIDI Input Choice Belongs On The Lane

Task: Expose the lane's physical MIDI input device choice in the same MIDI routing panel that already owns arm state, input channel, playback/export channel, hardware output, route target, and Hardware Passport.

What connects creatively: A lane should feel like a real cable destination: what comes in, what goes out, what channel it speaks, and whether it is internal, external, or both. Putting the physical input selector beside the arm button makes hardware routing less mystical and supports the larger Instrument Bay idea: the lane is the unit of musical responsibility.

Architecture choice: Reuse the saved midiRoute.inputDeviceId field instead of creating a parallel UI state. Selecting a visible input in the lane MIDI panel checkpoints the project, updates the lane route, refreshes the direct input router through setArrangementLane(), and leaves channel filtering as a second layer of control. The panel also reports currently opened direct inputs and dropped-message count so live input confidence starts becoming visible.

Future extensions: Add a full MIDI setup assistant page that can test input by listening for notes/controllers, warn about duplicate host/direct routing, and let a user name common controller profiles without needing to understand device identifiers.

Bend Range Should Be A Policy, Not A Guess

Task: Bridge standard RPN Pitch Bend Range into internal playback without pretending every RPN/NRPN message is now a safe runtime control.

What connects creatively: MIDI guitarists, wind-controller players, old hardware users, and future MPE customers all live or die by bend range trust. A pitch-bend curve is only musically meaningful when the destination knows how many semitones the wheel represents. Preserving raw 14-bit bend is necessary, but not sufficient; SpaceAge also needs to understand the common setup message that says, "this channel bends this far."

Architecture choice: Store both the raw pitch-wheel value and the active per-channel bend range. Standard RPN 0,0 plus absolute Data Entry MSB/LSB updates that range and immediately re-scales the current wheel position. NRPN and relative Data Increment/Decrement remain in MIDI PATCH / Hardware Passport territory because their meaning can be device-specific or policy-dependent.

Future extensions: Add visible lane/instrument/Hardware Passport bend-range policy, Data Increment/Decrement semantics only after the UX can explain them, MPE zone/member-channel bend negotiation, and tests that prove imported RPN 0,0 makes pitch-bend playback land at the intended musical interval.

Setup Payload Is Not The Same Thing As A Setup Command

Task: Continue MIDI protocol hardening by separating preservable setup payload from protected setup-only controller messages.

What connects creatively: A musician importing an old hardware-oriented MIDI file needs SpaceAge to remember useful setup intent without becoming reckless. Bank Select, Program Change, and RPN/NRPN rows can be meaningful recipe ingredients for a Hardware Passport, SoundFont mapping, or pitch-bend policy. Local Control, Omni, Mono, Poly, All Notes Off, All Sound Off, and Reset Controllers are different: they are commands that can change or silence a device. Treating both families as one blob called "setup" would make the app feel clever right up until it surprises someone.

Architecture choice: MidiInspectionReport now has separate counts for RPN/NRPN setup payload and protected setup-only messages. Import receipts can report preserved performance expression, preserved patch/setup payload, and reviewed device setup without implying that protected channel-mode/reset commands were written into clip playback. The MIDI Protocol Coverage text now states that channel-mode/reset messages are review-only unless a future explicit hardware setup workflow sends them.

Future extensions: The same distinction should drive the Hardware Passport setup-card editor, a channel-mode send policy, import receipt UI, AI support explanations, and any future "send setup to hardware" button. The button should require confirmation because it is a hardware command, not musical expression.

Hardware Templates Should Own Their Defaults

Task: Move hardware setup test-note defaults out of string inference and into the MIDI device-template model.

What connects creatively: A setup wizard should feel like it knows the thing on the desk. If the user chooses an MPC-style pad controller, a channel-10 kick-range test note makes sense; if they choose a MiniNova, middle C on channel 1 is safer. Encoding that as data makes future device profiles feel less generic and makes support reports easier to trust.

Architecture choice: MidiHardwareSetupDeviceTemplate now carries suggested output channel, test note, velocity, and duration. Template reports and structured payloads expose those defaults, test-note planning uses them unless explicitly overridden, and Hardware Passport normalization can inherit profile input/output devices when a lane has not supplied its own override.

Future extensions: Device-specific templates can later provide pitch-bend range, safe patch-audition notes, default controller maps, test phrases, role presets, and one-click �verify this hardware� flows without sprinkling special cases through UI code.

Hardware Test Notes Need Receipts, Not Vibes

Task: Turn the MIDI SETUP TEST NOTE action into a structured queued-or-blocked receipt and make the guide expose that receipt through the existing copy/report flow.

What connects creatively: A hardware test note is small, but emotionally it is the first handshake between SpaceAge and the device on the desk. If it works, the user needs proof of what was sent. If it fails, the user needs a calm explanation without guessing whether SpaceAge silently changed patches or sent setup data. This is the same trust pattern as SysEx Vault receipts, Hardware Passport recall logs, MIDI import review, and future support bundles.

Architecture choice: Keep the test-note plan as the non-sending preflight, then add a receipt object for the actual confirmed queue attempt. The receipt records confirmation, success, output device, queued note-on/off messages, blocked reasons, warnings, and an explicit list of the things not sent: Program Change, Bank Select, MIDI Clock, transport, SysEx, reset, template apply data, and timing calibration.

Future extensions: Use the same plan/receipt split for hardware clock test pulses, MIDI Thru previews, channel-mode send policies, controller-map test gestures, and device-specific Hardware Passport verification scripts.

Hardware Profile Pickers Should Not Guess

Task: Stop setup/timing Hardware Passport combo boxes from auto-selecting the first saved profile when the user has not chosen one.

What connects creatively: With one hardware synth, guessing feels convenient. With two or three, guessing becomes dangerous because it can make the UI look certain about the wrong box on the table. Leaving the picker at CHOOSE HARDWARE PASSPORT is less flashy, but it teaches the user that external hardware identity is a deliberate choice.

Architecture choice: Preserve the user's previous selection when it exists, but do not promote the first profile into a real selection just because profiles exist. This keeps the MIDI Setup guide, Timing page, Hardware Passports, and future Instrument Bay hardware lanes aligned around visible intent rather than hidden defaults.

Future extensions: Add "last used for this lane" suggestions, visible recommended-profile badges, and profile search/filtering, but make each suggestion visibly opt-in. This should also inform future SysEx restore targets and multitimbral hardware lane stacks.

Hardware Sync Roles Need A Flight Plan

Task: Add a preview/confirmation model before saving Hardware Passport sync roles that can send MIDI Clock, send transport, or chase incoming transport.

What connects creatively: Sync is powerful because it makes two machines feel like one instrument, but it is also easy to misunderstand. A checkbox that quietly arms Start/Stop or Clock on future playback can feel like a hidden trap. Treating sync-role save as a flight-plan review lets SpaceAge say exactly what will happen now, what may happen later during playback, what incoming messages may move the timeline, and what hardware families are deliberately untouched.

Architecture choice: MidiHardwareSyncPolicyPreview now summarizes proposed clock mode, future playback sends, incoming chase behavior, safety lines, and warnings. The Hardware Passport panel asks for confirmation when a saved role would arm future MIDI sends/chase or has warnings; plain non-sending capability edits remain lightweight.

Future extensions: The same preview can become a Sync Role receipt, support-bundle attachment, setup wizard review page, and eventual per-profile "armed for sync" badge before playback starts.

MIDI Truth Labels Beat Optimistic Labels

Task: Tighten MIDI protocol and readiness language so customer-facing reports match the actual routing/filtering code.

What connects creatively: MIDI is a promise-heavy part of SpaceAge. A user with a controller, synth, or old hardware box is asking the app, "What are you listening to, what are you sending, and what might move my gear?" If the answer overclaims by even a little, the app feels haunted. Precise labels make the whole experience calmer: armed lane means deterministic record/routing destination, fallback audition means "you may hear something," and preserved setup payload is not the same as editable musical expression.

Architecture choice: Keep the current code paths conservative and update the shared reports around them. MIDI Learn currently captures messages that pass live input filters, not a separate global pre-filter stream. Fixed-channel lanes filter musical notes/controllers while still honoring panic/reset-style safety messages. MPE-like detection is now described as multi-channel expressive MIDI unless a future lane/device policy owns a true MPE zone. isTimelineMidiPayloadMessage() is now the clearer broad predicate for expression plus preserved setup payload, while isTimelineExpressionMessage() remains as a compatibility alias.

Future extensions: Add an explicit global-learn mode only if the UI can make it obvious, migrate older call sites from isTimelineExpressionMessage() to isTimelineMidiPayloadMessage() when touching those areas, and keep the Protocol Coverage panel as the single source of truth for what is implemented, guarded, polished, or future-roadmap.

Song Select Is A Status Fact, Not A Secret Jump

Task: Continue MIDI protocol hardening by recognizing MIDI Song Select without letting it behave like timeline data.

What connects creatively: Old drum machines, sequencers, and workstation keyboards may send Song Select as part of their own world. SpaceAge should understand that message well enough to reassure the user, but not so much that it starts moving projects around like a haunted tape deck. The humane behavior is: "I saw Song Select 7" rather than "I silently changed your song."

Architecture choice: Add MessageKind::songSelect at the end of the persisted enum so older serialized event kinds do not shift. Provide shared helpers to detect, create, and describe F3 nn, count it in the MIDI Sync runtime monitor, and report the last observed song number. Keep it out of isTimelineMidiPayloadMessage() and make the sync chase path explicitly ignore it.

Future extensions: A hardware librarian or Hardware Passport workflow may later map Song Select to an external device's internal song memory, but that should be an explicit hardware command with preview, confirmation, and receipt. It should not be clip expression, Arrangement state, or hidden project load behavior.

MIDI Routing Needs One Visible Truth At A Time

Task: Align clip editing with live MIDI input and make the recording target readable.

What connects creatively: SpaceAge is trying to be fast, but "fast" collapses if the musician cannot predict where incoming notes will land. The same design principle applies to lane instruments, MIDI routes, ghost notes, Hardware Passports, and future MPE zones: the app should show one active musical destination clearly, or explain why edit context and performance context differ.

Architecture choice: Opening an Arrangement clip for editing now arms that clip's lane, so the visible editing context and live performance destination match by default. The MIDI record buttons also carry a REC TARGET summary that names the target clip/pattern and the currently armed lane, so a deliberate mismatch can be seen before recording rather than discovered after a bad take.

Future extensions: Use the same visible routing truth for MIDI input profiles, hardware output, VST hosting, MIDI guitar/wind-controller modes, and the future AI helper's diagnostics. If the helper can answer "where will this note go?" instantly, the human probably can too.

Lane Test Notes Are Hardware Sends

Task: Make Arrangement lane hardware TEST NOTE follow the same preflight, confirmation, and receipt pattern as the MIDI SETUP workbench.

What connects creatively: A test note is small, but it is still a physical command to something outside the app. If SpaceAge treats one hardware-send path as "safe enough to skip the receipt," the user learns that hardware behavior is inconsistent. If every hardware send has a plan and a receipt, the app starts to feel like a trustworthy studio assistant instead of a button farm.

2026-08-11 - Meters And Filters Must Tell The Truth

Task: Clarify auxiliary host-output names, center the stereo channel meters, make hard-pan metering reflect the post-pan signal immediately, and repair Redshift's cutoff/filter-mode behavior.

Creative connection: A meter and a filter selector are both promises about hidden signal flow. Using Host Out connects SpaceAge's mixer vocabulary to what a plug-in host actually exposes, while truthful left/right meters let panning become readable at a glance. Redshift now follows the same principle: Off means unfiltered, and every named mode produces its own audible response.

Architecture choice: The output names now agree in the mixer and JUCE bus declarations. Meter values remain measured after pan and strip processing; only the UI's stale silent-side hold and asymmetric geometry were corrected. Redshift owns one mode-aware filter stage, and the shared post-voice filter explicitly excludes Redshift to prevent double filtering.

Verification: SYNTH_CONTROL_QUALITY proves bypass independence from cutoff, low-pass attenuation and opening, audible high-pass/band-pass modes, finite output, and slot isolation. MIXER_LAYOUT proves exact output names, symmetric meter margins, and immediate hard-pan silent-side clearing.

Subagents: No subagent work was used. The issue crossed one synth voice path and one mixer presentation path, so direct integrated work was clearer.

Human review flag: Pan a sustained source fully left and right while watching its strip, then audition Redshift with each filter type at low and high cutoff values. Automated tests prove signal relationships; human ears and eyes remain the final presentation check.

Architecture choice: The lane MIDI Routing panel now builds a lane-local MidiHardwareSetupDeviceTemplate, asks the processor for the shared test-note plan, blocks with the model-owned report when routing is incomplete, and queues through queueConfirmedMidiHardwareSetupTestNote() after confirmation. The old direct lane queue helper was removed so future UI code has fewer ways to bypass the receipt model.

2026-07-06 wording pass: The lane-local confirmation now says SEND TEST NOTE and names the action as hot hardware. The receipt still reports the queue attempt because that is the evidence SpaceAge owns. This keeps lane testing, MIDI Setup testing, bend testing, setup cards, and Hardware Passport recall under the same verb rule.

Future extensions: Add a compact receipt drawer inside the lane MIDI panel so the user can copy the lane test result without a separate modal. Later, the same drawer can show last hardware recall, last timing pulse, last SysEx restore receipt, and "why did I not hear the device?" repair hints.

Direct MIDI Learn Should Default To The Most Likely Gesture

Task: Make direct control-click MIDI Learn default to CC/knob capture, while leaving explicit any-source options for expressive controllers.

What connects creatively: A right-click learn gesture should feel fast and predictable. Most users who right-click a synth knob, mixer send, or slider are about to move a hardware knob, fader, or pedal, not sweep pitch bend or lean into aftertouch. If a controller sends several message families during one movement, the app should bias toward the ordinary CC case unless the user clearly asks for the wider net.

Architecture choice: Reuse the existing processor-level MIDI Learn source filters instead of inventing a separate direct-learn path. The direct context menu now arms quick replace/macro captures with controllers only, and adds explicit Any Source replace/macro choices for pitch bend, channel pressure, and poly aftertouch. MIDI Maps remains the deeper surface for full source-filter control.

Future extensions: Surface the same "listen for this kind of movement" concept in lane MIDI input setup, Hardware Passport controller templates, wind-controller onboarding, MIDI guitar profiles, and any future MPE setup flow. The pattern is simple: quick defaults should match the common case, but expert intent should stay one visible choice away.

Release Velocity Is Small Until A Controller Player Notices

Task: Preserve MIDI note-off release velocity for SpaceAge-authored Piano Roll notes.

What connects creatively: Release velocity is easy to ignore if the app is mostly drawing notes with a mouse, but it matters to keyboardists, expressive controllers, and hardware synths that react to how quickly a key is released. Preserving it now gives SpaceAge a more respectful MIDI backbone before the UI exposes every expressive detail.

Architecture choice: Add releaseVelocity to PianoNote without making it part of selection identity or note editing keys. Live MIDI recording and MIDI import capture note-off velocity, project save/load persists the value with an old-project default of zero, and MIDI exports write the release velocity back through one helper so Pattern, Clip, Lane, and Arrangement exports stay consistent.

Future extensions: Add a small release-velocity lane or per-note inspector later, connect it to MIDI EXPR/motion editing language, and decide how release velocity should behave for generated chord/arp notes. The data is now present, so the future UI can be expressive without another file-format turn.

Hardware Setup Cards Need Receipts

Task: Turn confirmed RPN/NRPN setup-card queueing into a receipt-driven action rather than a silent boolean.

What connects creatively: External hardware is where confidence can evaporate fastest. If a user queues a setup card for a MiniNova, QY device, or future boutique synth, they need proof of what SpaceAge sent, where it went, and what it deliberately refused to do automatically. The receipt pattern also lines up with test notes, SysEx restore, timing calibration, and future Hardware Passport setup assistants.

Architecture choice: Add MidiSetupControllerQueueReceipt beside the existing setup-card summary and action-plan structs. The processor now reports Hardware Passport id, output device, selected card, per-message queue results, warnings, and follow-up actions. RPN stays queueable after confirmation; NRPN remains device-specific and requires a queue-safe Hardware Passport definition.

Future extensions: Replace the temporary receipt alert with a unified MIDI receipt drawer, add copy-to-clipboard from the queue result, connect queue receipts to the Hardware Recall Log display, and let the future AI helper answer "what exactly did SpaceAge send to my synth?"

Expression Curves Need Gentle Surgery

Task: Add a guarded smoothing transform to MIDI EXPR without pretending the final Piano Roll-grade automation editor is done.

What connects creatively: Smoothing is not only a MIDI cleanup tool. It is the same creative gesture as softening velocity contours, taming breath-controller data, making pitch bends less stair-stepped, and eventually shaping Motion Clips. The workflow should therefore feel surgical and reversible: preview first, then commit only when the user asks.

Architecture choice: Add smoothCurveValues to the shared MIDI expression transform model instead of making a panel-only shortcut. The transform preserves the first and last matching points, lightly averages interior values, refuses review-only/setup data through the existing lane guard, and disables itself for switch-style lanes such as sustain. This keeps it aligned with THIN REDUNDANT, undo checkpoints, shared-pattern warnings, and the protocol coverage report.

Future extensions: Reuse the same preview-confirm model for curve tension, S-curves, compression/expansion of controller ranges, breath cleanup, pitch-bend glide smoothing, and Motion Clip contour operations. When the full expression lane editor arrives, this should become one command in a richer curve toolbox rather than a special one-off button.

Hardware Silence Is Still A Receipt

Task: Make active SysEx restore attempts time out into explicit verification receipts instead of waiting indefinitely.

What connects creatively: A hardware restore is a conversation with an external machine. If the device ACKs, rejects, waits, or says nothing, all four outcomes should become visible facts. Silence is especially dangerous because it can look like SpaceAge is still doing something when the external device may have ignored the dump, the return cable may be disconnected, or the device may simply have no ACK dialect we understand yet.

Architecture choice: Reuse the existing SysExRestoreVerificationReceipt trust ladder rather than inventing a separate timeout status. Active attempts now compare the current time with each snapshot's estimated transfer completion plus a grace window, with a minimum response window for small dumps. When that window expires, SpaceAge records a Timed out receipt, removes the stale active attempt, and lets the existing SysEx Vault / MIDI Health report paths tell the user what happened.

Future extensions: Let Hardware Passports override restore-response timeout windows per device, add vendor-specific ACK/NAK dialect plugins, show a visible restore-history drawer, and provide "manual verification accepted" buttons when a device has no useful response channel but the user confirms the patch or bank arrived.

Clear The Test Bench

Task: Add a visible SysEx Vault action for clearing session restore-response receipts.

What connects creatively: Hardware restore testing is experimental by nature: old synths may answer, stay silent, or send unrelated SysEx. Once a user has tested a path, stale response history can make the next test feel ambiguous. A dedicated CLEAR RESPONSES button treats restore verification like a test bench: wipe the evidence from this run, keep the stored snapshots safe, and try again.

Architecture choice: Reuse clearSysExRestoreVerificationReceipts() instead of inventing editor-only state. The action clears the session receipt list and active wait state, then lets the existing SysEx Vault refresh, MIDI Health, and copy-report paths rebuild from processor truth. It does not mutate snapshots, profile attachments, archives, or hardware outputs.

Future extensions: Add per-Hardware-Passport restore history with filters for acknowledged, rejected, timed out, and manual verified, plus a separate clear current view action that never erases durable project history.

Human Verification Counts, But Says What It Is

Task: Expose manual SysEx restore verification from the Vault.

What connects creatively: Some beloved hardware will never give us a clean modern ACK. The user may still know the restore worked because the patch name changed, a preset sounded right, or the device display confirmed a dump. SpaceAge should honor that reality without lying about it. MARK VERIFIED turns human confirmation into evidence while still labeling it as human confirmation, not hardware acknowledgement.

Architecture choice: Add a processor-owned addManualSysExRestoreVerificationReceipt() helper that builds the existing manualVerified receipt kind for a selected snapshot. If that snapshot was actively waiting for a response, the active wait is removed because the user has supplied the missing verification. The Vault button only creates the receipt; it does not send MIDI, alter snapshots, or mutate hardware profiles.

Future extensions: Let the manual receipt capture short user notes, attach restore receipts to individual Hardware Passport history, and expose a needs manual verification filter when a project contains SysEx snapshots for devices with no known response dialect.

Send Knobs Should Wake Their Returns

Task: Make shared effects sends auto-enable their matching return effect when a send rises above zero.

What connects creatively: A send knob is a promise. If a musician turns up Halostar or EchoRay and hears nothing because the shared return is disabled somewhere else, the app feels broken even if the DSP graph is technically behaving. This is especially important while SpaceAge is moving from pad-owned instruments toward lane-owned instruments, because legacy pad/send vocabulary can already make the routing feel more abstract than it should.

Architecture choice: Keep the audio engine explicit: disabled returns still consume no send signal. Put the friendliness in the UI layer: mixer channel sends and the Effects-page selected-send bank now enable the matching shared return as soon as the send value rises above silence. This preserves intentional off states while preventing a common dead-knob trap.

Future extensions: Rename the selected-send bank around channel/lane language, show the active return state beside each send, and eventually make sends lane-owned rather than pad-indexed for non-drum instruments. Full Motion Clip and automation lanes should reuse the same rule: when a control implies audible routing, the user should see or hear the routing consequence immediately.

Pattern MIDI Automation Needs A Plain Doorway

Task: Rename the visible MIDI EXPR entry point to MIDI AUTO and explain that the current editor is pattern-owned MIDI automation/expression, not full Arrangement automation lanes.

What connects creatively: Automation is one of those words musicians understand immediately, while "expression payload" is backend language. The existing editor is already doing useful work: CCs, pitch bend, pressure, sustain, and similar controller curves can be recorded, inspected, drawn, transformed, copied, and pasted. If the entrance says MIDI EXPR, a normal musician may never know that this is where the useful automation work currently lives.

Architecture choice: Keep the data model honest. The current surface remains pattern-owned and therefore shared by every linked clip that uses that pattern. Do not pretend clip-local or lane-local automation exists yet. The UI should instead name the scope directly: Pattern MIDI Automation, with warnings when a pattern is shared and options to make a Variant before editing.

Future extensions: Promote this into a real Automation Lane system with three clear scopes: pattern automation, clip-local automation overlays, and lane/project automation. Motion Clips should grow from the same vocabulary so a user does not have to learn separate concepts for MIDI CC curves, filter sweeps, reverb throws, gates, and clip decorations.

Effects Are Shared Returns Until We Deliberately Add Clip Decorators

Task: Answer whether effects are currently applied per pattern and document the ownership boundary so future MIDI/automation work does not blur it.

What connects creatively: This is really about keeping SpaceAge's mental model crisp. Patterns own musical gestures: notes, drum steps, chord markers, and pattern MIDI automation. The Effects page is a shared studio rack: Halostar, Reverb, EchoRay, Chorus, Flanger, Phaser, Tremolo, and Octave behave like returns fed by sends. That distinction lets a musician understand why a pattern can be reused without secretly bringing its own private reverb universe along for the ride.

Architecture choice: Keep shared effects out of the pattern payload for now. Effects remain pad/channel/return-level routing, with EchoRay carrying a special hybrid detail: global character/return controls plus per-pad/channel delay memories. Arrangement lanes do not yet own independent effect-send fields. Any future per-clip effect behavior should enter through a named Clip Decoration, Motion Clip, or clip-local automation layer, not by quietly mutating the shared rack semantics.

Future extensions: Add clip-local effect throws, pattern-owned Motion Clips, and lane/project automation as explicit scopes. When those exist, a user should be able to see whether a reverb swell belongs to the clip, the pattern, the lane, or the whole mix. That clarity will matter for copy/paste, make-variant, export stems, and collaboration.

External MIDI Input Needs A Realtime-Safe Front Door

Task: Prepare the next MIDI backend move: direct external MIDI input devices should feed SpaceAge through the same lane/channel/pattern safety model as host MIDI, without doing musical work inside JUCE's MIDI callback.

What connects creatively: Hardware should feel alive, not bolted on. A controller, wind instrument, MIDI guitar, QY-70, MiniNova, or drum pad should all enter the same SpaceAge lane world: choose the lane, choose the channel policy, prove that SpaceAge sees input, then record or play without mystery. The hidden magic is that the front door must be calm and realtime-safe while the visible workflow stays friendly.

Architecture choice: Add a processor-owned external input router beside the hardware output router. JUCE MIDI input callbacks should enqueue { deviceId, message, timestamp } into a bounded FIFO and return quickly. processBlock() should drain the queue at the audio boundary, convert timestamps to sample offsets as well as practical, and then reuse the existing source-device filter, armed-lane choice, MIDI-channel filter, recording path, expression capture, and readiness reports. Do not call project mutation, UI code, allocation-heavy parsing, or hardware setup flows from the raw callback.

Future extensions: Add visible mismatch guidance when SpaceAge hears CH 01 but the lane accepts CH 03, explicit duplicate-input protection for host-plus-standalone cases, safe SysEx receive capture, and eventually MPE-zone routing. This is also the place where the future "hardware setup wizard" can become useful instead of theatrical.

External MIDI Input Should Stay Lane-Owned

Task: Implement the first backend pass of direct external MIDI input routing without creating another hidden performance path.

What connects creatively: This is where the one-instrument-per-lane philosophy meets hardware. A controller should not be "globally somewhere"; it should be feeding the lane the user armed or selected. That keeps MIDI guitar, wind controller, drum pad, and hardware sequencer workflows compatible with the same visible lane badges, channel labels, recording controls, and future automation lanes.

Architecture choice: Add a processor-owned external input router. It opens only MIDI input devices referenced by Arrangement lane routes, queues callback messages into a bounded FIFO, drains them in processBlock(), converts callback timestamps into block sample positions, and then reuses the existing source-device, armed-lane, MIDI-channel, MIDI Learn, SysEx, sync, recording, and expression paths. The MIDI callback does not mutate project state or touch UI.

Future extensions: Add explicit host-plus-standalone input de-dupe choices, richer open-input/dropped-message diagnostics in MIDI Health, and a hardware setup assistant step that proves SpaceAge is listening to the intended port before asking the user to record.

Imported MIDI Should Keep Its Musical Grid

Task: Prevent PPQ MIDI imports with tempo changes from shifting note positions while SpaceAge is only reviewing the source conductor map.

What connects creatively: A MIDI file can contain two different kinds of truth: the musical grid where notes live, and the conductor map that says how fast that grid moved in the original session. If a user imports a riff from a variable-tempo file but chooses to keep the current SpaceAge tempo, the riff should land where it belongs on the grid. The source tempo map should become visible intelligence, not a hidden force that stretches the phrase.

Architecture choice: Treat positive MidiFile::getTimeFormat() values as PPQ/tick files and convert timestamps to SpaceAge steps directly from ticks-per-quarter. Only SMPTE/timecode files go through JUCE seconds conversion before deriving steps. This keeps selected-pattern import and channel-to-lane import consistent, and it preserves the existing conductor-map review receipts without pretending full tempo-map adoption exists yet.

Future extensions: When SpaceAge gains a real timeline-map model, this same boundary should power an explicit choice: keep the imported clip on its source grid, conform it to the current project grid, or adopt the source tempo/meter/key map into the project timeline with a preview and one undo checkpoint.

Piano Roll Import Should Not Think Like A Step Bank

Task: Let direct selected-pattern Piano Roll MIDI import preserve melodic material beyond the old 64-step Drum Composer bank boundary.

What connects creatively: The Drum Composer and Piano Roll can both import MIDI, but they are not the same musical object. The Drum Composer is still a visible 64-step hardware-inspired grid; the Piano Roll is a long-form clip editor. If the direct import path silently treats a melodic phrase as a 64-step bank, the user loses later notes and expression exactly when SpaceAge is supposed to feel like a trustworthy composition environment.

Architecture choice: Use the 4096-step pattern timeline for importPatternMidi() whenever importAsPianoRoll is true, including note starts, note lengths, imported expression-event bounds, and final pattern length. Keep the 64-step limit for Drum Composer imports because those land inside the classic step-bank model. Both paths still share PPQ-vs-SMPTE timing conversion, so this fix extends the timeline without creating a second timing model.

Future extensions: When the Drum Composer eventually grows optional longer banks or lane-native percussion clips, revisit the 64-step limit there through a visible UI choice instead of silently lifting the cap in the backend.

MIDI Import Should Respect Overlapping Repeats

Task: Prevent overlapping same-channel/same-pitch MIDI notes from reusing the same imported note-off.

What connects creatively: Repeated notes are not exotic; they are the bloodstream of arpeggiators, MIDI guitar performance, piano-roll edits, and drum programming. If SpaceAge imports two C4 note-ons and lets both grab the first later C4 note-off, the second note becomes artificially short and loses its true release velocity. That kind of bug is hard for a musician to name, but it makes the app feel untrustworthy.

Architecture choice: Keep note-off pairing local to MIDI import. For each MIDI track import pass, maintain a consumed-note-off table and let a note-on claim exactly one matching same-channel/same-note note-off. Direct Piano Roll import and split-channel-to-lane import share the same helper, so they cannot drift into different interpretations of the same file.

Future extensions: If SpaceAge later adds a richer MIDI event timeline editor, expose ambiguous overlap policy as inspectable import intelligence rather than silent correction. The default should remain musician-safe FIFO pairing, while diagnostics can explain when a source file contains overlapping same-pitch notes.

Restored Sends Should Not Become Dead Paths

Task: Make restored projects wake shared effect returns when saved pad/channel or loop sends are already above silence.

What connects creatively: SpaceAge is becoming more mixer-like, which means a send amount communicates intent. If a project opens with EchoRay, Halostar, or modulation sends visibly present but the shared return is silently off, the musician experiences that as broken audio, not as a nuanced routing distinction. The app should preserve the user's mix intention when restoring a session.

Architecture choice: Keep effects as shared returns, not per-pattern inserts. On state restore, scan pad/channel sends and loop sends; if a send is nonzero, enable its matching shared return so the recalled session plays as a coherent mix. During normal live work, ENABLE still matters: users can bypass a return deliberately, and send knobs still auto-enable their return when raised from the Mixer or Effects page.

Future extensions: When SpaceAge adds clip-local effect throws or Motion Clips, give those scopes their own visible ownership labels. A reverb swell should say whether it belongs to a clip, pattern, lane, or the shared rack, because that clarity will decide how copy/paste, Variant, render stems, and collaboration behave.

SpaceAge Scenes Are Orchestration Snapshots

Task: Capture the idea that a SpaceAge Scene is a named alternative set of orchestration choices for the same project composition.

What connects creatively: A composer often wants to ask, "What if this same song were played by a different band?" That should not require duplicating the whole project, risking stale copies of notes, or disturbing the Arrangement Canvas. Scenes would let the user preserve the composition while swapping the sound world: Redshift versus SoundFont strings, Quasar marimba versus physical model, hardware MiniNova versus internal synth, dry mix versus shimmer-heavy version.

Architecture choice: Treat Scenes as project-level snapshots of lane-owned Instrument Bay assignments, preset/package ids, mixer-channel routing, hardware profile attachments, and possibly effect-send/rack states. They should not own clip payloads, Chord Engine markers, Section markers, tempo, or note data by default. That keeps them closer to "orchestration/mix alternatives" than "alternate timelines."

Future extensions: Add A/B scene audition, scene notes, render/export by scene, "copy current orchestration to new scene," and a collaboration-friendly report listing the active Scene's instruments, presets, hardware profiles, and missing assets. Later, Motion Clips and automation could optionally become scene-local only if the UI says so explicitly.

Hardware Bend Range Is Part Of The Instrument Contract

Task: Separate pitch-bend editing from external-destination pitch-bend trust in the MIDI Protocol Coverage model.

What connects creatively: Pitch bend is a musical gesture, not just a stream of 14-bit numbers. A guitarist expects a slide to land on the right pitch; a wind-controller player expects expressive bends to match the hardware patch; a synth user expects a one-octave sweep to be an octave, not two semitones. That means the Instrument Bay, Hardware Passport, MIDI AUTO, and export readiness all have to agree on what a bend curve means before SpaceAge can feel effortless with external gear.

Architecture choice: Keep MIDI AUTO responsible for drawing, smoothing, and inspecting the raw performance curve. Keep Hardware Passports responsible for the destination's bend range, with readiness/export warnings when pitch-bend expression targets hardware without a declared range. The Protocol Coverage report now names this remaining work as Hardware Bend Range so the next closeout pass does not confuse editor polish with destination trust.

Future extensions: Add a guided bend-test phrase that sends a safe note plus known bends, lets the user confirm the hardware result, and stores the range on the Hardware Passport. Later, use that same model for MPE member-channel ranges, SoundFont bend metadata, and per-scene orchestration swaps where the same MIDI phrase drives different hardware or internal instruments.

SysEx Identity Confidence Belongs Beside Restore Trust

Task: Add conservative SysEx manufacturer/device identity evidence to snapshot reports without loosening the no-hidden-send / no-false-success rules.

What connects creatively: Hardware workflows are confidence games. A user loading a QY-100 dump, MiniNova patch, or old rack-synth bulk transfer should be able to see whether the snapshot appears to belong to the attached Hardware Passport before they trust it. This is the same design instinct as ghost notes, lane badges, and MIDI Health: reveal the relevant truth at the moment doubt would otherwise appear.

Architecture choice: Preserve the raw SysEx device id in the descriptor, then let snapshot summaries compare manufacturer evidence against the linked Hardware Passport. Universal SysEx is exempt from manufacturer matching, unassigned snapshots are labeled as not compared, and meaningful mismatches become review warnings. This deliberately stops short of saying the dump is safe or restored; restore trust remains owned by verification receipts.

Future extensions: Add Hardware Passport identity parsers for device-specific reply dialects, richer checksum helpers, and a guided "capture identity first" step before bulk-dump workflows. Later, the same evidence can help the Instrument Bay or Scene reports say which external devices are required for a project to sound complete.

Hardware Bend Tests Are Tiny Trust Rituals

Task: Give Hardware Passports a reusable pitch-bend test plan so external-synth slides can be proven before users commit a performance.

What connects creatively: Pitch bend is technically simple and musically treacherous. SpaceAge can preserve the raw 14-bit curve perfectly, yet a MiniNova, QY, SoundFont, or future hardware rack may interpret that same curve as two semitones, twelve semitones, or something stranger. A guided C4 center/up/down/center test gives the user a tiny trust ritual: hear it, confirm it, then go play.

Architecture choice: The test plan lives in the MIDI model beside Hardware Passport summaries. It reports output-device readiness, declared bend range, MIDI channel, safety copy, checklist rows, and next action. It sends nothing by itself. The future UI can render a confirmed BEND TEST action from this model instead of hard-coding another one-off hardware workflow.

Future extensions: Reuse this pattern for wind-controller breath calibration, MIDI guitar per-string bend checks, MPE member-channel ranges, and hardware velocity-response tests. The broader principle is: make the user prove a tiny audible fact once, then let SpaceAge remember the trust boundary.

Instruments Make Sound, Mixer Owns Space

Task: Remove instrument-page and patch-save ownership of effect sends so synths/samplers do not compete with lane/channel mixer sends.

What connects creatively: A lane is becoming a clean mental object: instrument, MIDI data, mixer channel, optional hardware path. If a patch secretly saves reverb/delay/chorus sends, then changing from one preset to another also changes the mix, which makes the instrument feel haunted instead of expressive. Keeping sends in the Mixer lets a composer swap a bass patch, pad patch, SoundFont preset, or Quasar package without destroying the balance of the song.

Architecture choice: Preserve the underlying send parameters for existing projects and channel strips, but keep them out of native synth patch lists, factory preset application, Clear Changed Values, and visible instrument pages. Internal tone-shaping effects can remain when they are truly part of a voice, but shared rack routing belongs to Mixer/Lane state.

Future extensions: This rule helps Scene snapshots, stem rendering, external hardware profiles, and future Instrument Bay browsing. A Scene can change orchestration and mix together if explicitly designed that way, but a normal preset browser should not unexpectedly rewrite the user's effect sends.

MIDI Diagnostics As Workflow

Task: Give MIDI Input readiness a plain-English live-routing verdict instead of forcing the user to infer truth from counters.

What connects creatively: A musician should not have to decode host-stream counts, direct-input counts, policy ids, and armed-lane state just to answer, "Where is my keyboard going?" The verdict row turns diagnostics into workflow: SpaceAge can say the lane is listening to host MIDI, direct physical MIDI, both, a missing device, or no deterministic destination yet.

Architecture choice: Store the verdict in the MIDI model/report rather than editor-only text. That lets Settings MIDI Input, MIDI Health, copied support reports, future onboarding, and hardware setup cards all quote the same routing truth.

Future extensions: Feed this verdict into lane badges, setup wizards, MIDI Learn receipts, and a future "why am I not hearing this?" helper. The same pattern can serve audio routing later: show the active path first, then expose the technical counters underneath.

MIDI AUTO Needs Searchable Words, Not Only Correct Architecture

Task: Make the current MIDI AUTO surface easier to find and understand without changing the automation ownership model.

What connects creatively: A feature can be technically present and still feel missing if the user cannot name where it lives. "Automation lanes" is the musician-facing phrase; "MIDI expression payload" is the engineering phrase. The interface has to bridge both so the same data can support controller recording, pitch bends, sustain, MIDI guitar, wind-controller breath gestures, and future Motion Clips without becoming a maze.

Architecture choice: Keep MIDI AUTO pattern-owned for now. Improve the Settings tooltip, MIDI AUTO tooltip, empty state, and create-strip language so users can discover how to view or create automation points today. Do not imply clip-local or lane-local automation until the storage model exists.

Future extensions: Promote the same vocabulary into Piano Roll-grade automation lanes, Motion Clips, clip-local overlays, and lane/project automation. The important rule is that every future scope must be named at the point of editing, because copy/paste, Variant, render stems, hardware export, and collaboration all depend on knowing what owns the automation.

Hardware Setup Cards Need Exact Language

Task: Tighten MIDI PATCH wording so the visible workflow names Bank Select, Program Change, RPN, NRPN, and protected channel-mode setup data accurately.

What connects creatively: Hardware MIDI is where tiny wording mistakes become user mistrust. If a panel says only "RPN" when it also protects NRPN setup cards, a synth user with a hardware manual in hand will wonder whether SpaceAge understands their gear. The same precision that makes chord spelling feel professorial has to apply to MIDI protocol language.

Architecture choice: Keep the send model guarded. The MIDI PATCH tooltip now previews the protected setup families, and the queue guard asks for an RPN/NRPN setup card instead of an RPN-only card. RPN cards remain confirm-before-queue; NRPN cards still require a queue-safe Hardware Passport definition.

Future extensions: Add a read-only BEND INFO explanation even when no Hardware Passport exists, and add richer receipts after defining NRPN selectors so users can see exactly which Passport gained queue-safe setup knowledge.

Blocked Hardware Actions Should Teach

Task: Make MIDI PATCH BEND INFO readable even before a selected lane has a Hardware Passport attached.

What connects creatively: A disabled button creates mystery; a readable blocked action creates momentum. Hardware setup is already intimidating for many musicians, so the app should explain the next concrete setup step instead of leaving the user to infer why pitch-bend testing is unavailable.

Architecture choice: Keep the actual bend-test send path unchanged and confirmation-guarded. BEND INFO can now report missing lane/Passport/setup prerequisites, while TEST BEND only appears when the processor-owned Hardware Passport pitch-bend test plan is ready to queue.

Future extensions: Apply the same pattern to SysEx restore, hardware clock, NRPN definitions, and future MPE zone tests: blocked actions should be clickable read-only teachers, while live sends remain explicit, confirmed, and receipt-backed.

Hardware Trust Needs Receipts

Task: Give successful MIDI PATCH DEFINE NRPN actions a readable, copied receipt.

What connects creatively: Defining a queue-safe NRPN is not sound design yet; it is a trust contract between SpaceAge and a specific piece of hardware. A receipt lets the user, future support, and the project itself remember what was blessed: which lane, which Passport, which MSB/LSB selector, what the value means, and whether relative data is allowed.

Architecture choice: Keep DEFINE NRPN as a no-send operation. After confirmation and save, generate a plain-text receipt and copy it to the clipboard. The actual send remains behind QUEUE CARD, with confirmation and guarded processor receipts.

Future extensions: Convert this receipt into a structured model-owned type later so Hardware Passports can show a definition history, compare duplicate selectors, and export a clean hardware setup report for collaborators.

Nomenclature Is Product Architecture

Task: Align customer-facing MIDI setup documentation around Hardware Passport instead of drifting between profile/passport wording.

What connects creatively: The word Passport is doing more than naming a settings record. It suggests identity, permission, travel, inspection, and trust, which is exactly the emotional shape of external MIDI hardware setup. A MiniNova, QY-100, wind controller, or future rack synth should feel like it has papers SpaceAge can inspect before sending anything dangerous.

Architecture choice: Keep internal code free to use model words such as profile where they already exist, but make the user-facing spec, dialogs, tooltips, and future manual converge on Hardware Passport. That gives MIDI setup, SysEx recall, timing calibration, bend tests, and sync roles one shared concept instead of a pile of adjacent nouns.

Future extensions: Let Passports become exportable collaborator artifacts: "this song expects these external devices, these channels, these bend ranges, these SysEx snapshots, and these safety permissions." That connects neatly to project archives, Scene orchestration, hardware setup wizards, and future support diagnostics.

Reports Are Interface Too

Task: Clean stale profile/passport wording out of live MIDI reports, not just the docs.

What connects creatively: A copied MIDI Health report, protocol coverage summary, setup preview, or sync receipt is still part of the user experience. If those reports use old names, users will think there are two concepts: a Hardware Passport in the visible UI and a hardware profile somewhere mysterious underneath. Consistent report language makes support, collaboration, and self-diagnosis feel like one calm system.

Architecture choice: Keep the C++ model names stable where they are internal, but treat every string that can appear in a dialog, copied report, readiness summary, warning, or action label as product copy. Hardware Passport is now the user-facing noun for external-device identity and permission. Where the remaining work is truly device-specific, say so plainly rather than falling back to old profile phrasing.

Future extensions: Add a release-wording lint step that checks copied reports, tooltips, and manual-target docs for deprecated public terms before a build is packaged. The same pattern can protect future vocabulary such as Instrument Bay, Motion Clips, Scenes, Quasar packages, and Automation Lanes.

MIDI OUT Should Show The Boundary

Task: Make MIDI Output Preflight state the live-send/setup-send boundary visibly, not only in copied reports.

What connects creatively: External MIDI is powerful because it can make old hardware feel alive, but it is also risky because a casual Program Change, RPN, SysEx dump, or clock/transport command can change a real device. A user should see the boundary in one glance: performance messages can flow when the lane is ready; setup-changing messages need an explicit cockpit action.

Architecture choice: Keep the existing guarded behavior. Add model-owned liveSendReadinessLabel and setupMessageSafetyLabel to the output readiness report, serialize them, copy them, and render them as compact facts in the Settings MIDI OUT panel. This avoids scattering one-off explanatory text in the editor while making the safety rule visible during troubleshooting.

Future extensions: Reuse the same boundary strip in a full Hardware Output Preflight wizard, support bundles, and future hardware setup checklists. The pattern can also apply to VST automation and Motion Clips: show what passes live, what is recorded, and what requires an explicit commit.

Hardware Output Needs One Trust Gate

Task: Add a single model-owned MIDI OUT trust gate that combines route readiness, visible output devices, runtime-open devices, and dropped-message evidence.

What connects creatively: A musician should not have to mentally combine four diagnostic rows before deciding whether it is safe to play a hardware synth. A single trust gate turns scattered engineering facts into an instrument-cockpit answer: idle, blocked, or ready. That same clarity can later serve VST hosting, render/export preflight, and project archive repair.

Architecture choice: Keep readiness, runtime, and device inventory as separate fact layers, then build a read-only MidiExternalOutputTrustGateReport above them. The gate sends no MIDI. It explains the reason, next action, and boundary between live performance messages and explicit setup/sync/recall actions. The MIDI OUT popup and copied report now render that same object instead of inventing new prose in the editor.

Future extensions: Make the trust gate actionable inside a full Hardware Output Preflight wizard: route lane, choose output, attach Passport, test note, test bend, calibrate timing, then save a support-ready receipt. Similar gates can protect future MPE zones, hardware clock, and SysEx batch restores.

Hardware Input Needs The Same Cockpit Logic

Task: Add a single model-owned MIDI IN trust gate that combines armed-lane state, device visibility, source-policy filtering, channel-filter evidence, and direct-input queue health.

What connects creatively: Input trust is the emotional twin of output trust. A player sitting at a MIDI controller does not want to decode armed lane, source policy, direct router, host stream, channel mismatch, and dropped-message rows separately. They want to know whether the controller can play the chosen lane now. The trust gate turns those diagnostics into a simple cockpit verdict while still preserving the details for repair and support.

Architecture choice: Keep MidiInputReadinessReport as the detailed fact layer and build MidiInputTrustGateReport above it. The gate sends no MIDI and does not change routing. It classifies the current input state as idle, blocked, ready with caution, or ready, then exposes one next action and boundary lines. The Settings MIDI preflight and MIDI Input copied report now speak from the same model-owned object.

Future extensions: Reuse the input trust gate in the full hardware setup wizard, MIDI guitar and wind-controller onboarding, live-record latency calibration, and future MPE zone setup. The same pattern can later protect VST/plugin input, Instrument Bay audition routing, and controller-to-automation capture.

MIDI Health Should Not Reword Input Truth

Task: Carry the new MIDI Input trust gate into the broader MIDI Health model and visible Health panel.

What connects creatively: MIDI Health is the cockpit overview; MIDI Input is the focused inspection scope. If those two surfaces use different prose, users will eventually mistrust both. Feeding Health from the same MidiInputTrustGateReport lets SpaceAge answer "can I play into this thing right now?" with one shared model.

Architecture choice: Store the trust gate inside MidiProjectHealthSummary, serialize it into structured reports, include its warnings in Health warning state, and draw a MIDI IN row from that object. The older live-destination sentence remains as detail, but the status label now comes from the same source as Settings and the MIDI Input popup.

Future extensions: When the hardware setup wizard arrives, it should also consume this gate rather than inventing a third readiness model. The same approach can be reused for render/export, VST scan, SoundFont missing-file repair, and future cloud/project archive safety checks.

Trust Gates Need Self-Test Receipts

Task: Add model-level self-test coverage for MIDI Input trust-gate states.

What connects creatively: A trust gate is only useful if the app can trust itself. Since this gate will eventually guide live controller setup, MIDI guitar/wind-controller onboarding, and hardware proof tests, it needs a few simple "known truth" examples: ready, blocked, and idle.

Architecture choice: Extend the existing MIDI readiness self-test cluster instead of creating a separate test island. The same synthetic device inventory now proves the blocked missing-device/channel-mismatch case, the ready controller case, the idle no-armed-lane case, structured serialization, and Health-report inclusion.

Future extensions: Add real hardware-loopback-style tests when we have an automated rig: host-only, direct-only, both/duplicate risk, observed-channel mismatch after a live note, and queue-overflow simulation for overloaded direct input.

Next Steps Reports Should Include Input Trust

Task: Carry the MIDI Input trust-gate verdict into the compact MIDI Health Next Steps report.

What connects creatively: The short copied checklist is the thing a musician is most likely to paste into a support message or reread while setting up hardware. If it names latency, expression, and repairs but omits the live-input trust verdict, the user still has to hunt through the full report to answer the most basic question: "Can my controller play this lane right now?"

Architecture choice: Reuse MidiInputTrustGateReport inside MidiProjectHealthSummary::toPlainTextNextSteps() instead of writing editor-only copy. The full report, visible Health row, Settings preflight, MIDI Input popup, and compact Next Steps checklist now quote the same input state and next action.

Future extensions: A guided hardware setup wizard can treat this line as its first checkpoint: prove input route, prove channel, prove latency, then move on to output, clock, SysEx, and automation capture.

MIDI Health Needs Both Hardware Trust Gates

Task: Carry the MIDI Output trust-gate verdict into top-level MIDI Health beside the MIDI Input gate.

What connects creatively: A hardware workflow has two emotional questions: "Can I play into SpaceAge?" and "Can SpaceAge safely play out to my instrument?" Showing only the input gate in Health makes the cockpit feel lopsided. Putting both trust gates in the same summary connects controller setup, external synth routing, Hardware Passports, timing calibration, SysEx recall, and future guided setup into one clear readiness ritual.

Architecture choice: Store MidiExternalOutputTrustGateReport inside MidiProjectHealthSummary, populate it from the existing output readiness/runtime/device-inventory layers, include its warnings in Health state, draw a visible MIDI OUT row, and serialize/copy the same summary in full and compact Health reports.

Future extensions: The eventual Hardware Setup wizard should move through the same gates in order: MIDI IN, MIDI OUT, timing, clock/transport, SysEx restore trust, then optional MPE/future-protocol checks.

MIDI Setup Should Lead With Trust Gates

Task: Make the MIDI SETUP assistant scenario rows quote the shared MIDI IN and MIDI OUT trust gates.

What connects creatively: A setup guide should feel like a cockpit checklist, not a second diagnostic dialect. The trust gates already compress armed-lane state, device visibility, source policy, channel filters, output runtime, and dropped-message evidence into one plain verdict. Leading scenario cards with those verdicts makes controller setup, external synth setup, MIDI guitar setup, and wind-controller setup feel like variations of the same ritual.

Architecture choice: Build inputTrustGate and outputTrustGate inside buildMidiHardwareSetupAssistantPlan() and use their summaries/next actions for the MIDI input and MIDI output steps. Keep the existing detail rows, such as observed input channels, hardware lanes, timing calibration, expression data, and export-only lanes, as supporting evidence.

Future extensions: The focused setup wizard can promote these gate rows into large status tiles, then let each tile expand into the existing preflight panels without mutating routing or sending hardware messages by accident.

2026-07-05 - MIDI AUTO Needs A Natural Doorway

Task: Continue MIDI protocol/customer-facing closeout by making pattern automation easier to find.

What connects creatively: MIDI AUTO already owns the first-generation automation/expression surface, but hiding it only inside Settings makes it feel like a diagnostic tool instead of a musical tool. Placing it inside MIDI TASKS connects it to recording, step input, quantize, import, and export: the same family of actions a user reaches for while shaping a pattern.

Architecture choice: Keep one MIDI AUTO editor and open it through a one-shot Settings flag. This avoids duplicating the large expression editor or inventing a second automation model. The UI route gets friendlier, while the data remains selected-pattern MIDI expression until clip-local or lane-local automation is deliberately designed.

Future extensions: When true Arrangement automation lanes arrive, use a separate doorway and storage contract. MIDI AUTO can remain the selected-pattern performance-expression editor, while Arrangement automation can own lane/clip/global parameter curves without confusing the user about scope.

2026-07-05 - Hardware Sync Must Know Its Source

Task: Make incoming MIDI Clock, Start/Continue/Stop, SPP, MTC, and MMC chase obey the source device named by the active Hardware Passport.

What connects creatively: Hardware sync is one of those places where invisible authority matters. If a QY-70, MiniNova, MIDI interface, or controller can all talk to SpaceAge, the app needs to know which device has permission to move tempo and transport. Source-aware chase turns Hardware Passports from passive documentation into an actual cockpit permission layer.

Architecture choice: Keep host/plugin MIDI source-less and compatible, but require direct physical MIDI input to match a ready Hardware Passport before it can follow clock or chase transport. The readiness helper mirrors the same receive-clock/chase/SPP/MTC/MMC rules already used by the MIDI Sync policy summary, and it uses a non-blocking profile lock so the audio thread does not wait on Settings edits.

Future extensions: The same source-aware permission model should feed the future hardware setup wizard, MIDI clock calibration, MPE zone ownership, and device-specific sync receipts. If a user later asks "why did my timeline move?", SpaceAge should be able to answer with the exact Hardware Passport and source device that had authority.

2026-07-05 - Protected Setup Rows Need Review Persistence

Task: Preserve protected channel-mode/reset messages through import/save review without letting them enter playback/export.

What connects creatively: Local Control, Omni, Mono/Poly, All Notes Off, All Sound Off, and Reset All Controllers are not music notes, but they are musically consequential when talking to hardware. They belong in the Hardware Passport/MIDI PATCH review world, not in the performance stream. Preserving them safely lets SpaceAge become a better hardware librarian without risking "why did my synth mode change?" moments during playback.

Architecture choice: Add a narrow review-only predicate for protected channel-mode/reset messages and use it only at import/store/restore gates. Keep editable expression, playback, and export on the existing safe predicate so these rows remain copy-only/review-only unless a future explicit, confirmed hardware command sends them.

Future extensions: These rows can later become part of a richer Hardware Passport setup-card system with explicit queue confirmations, device-specific warnings, and support-ready receipts.

2026-07-05 - MIDI Receipts Should Name Protected Setup Rows

Task: Separate protected setup-only row counts from generic preserved MIDI payload counts in MIDI import apply receipts.

What connects creatively: A musician importing a hardware-oriented MIDI file should not have to infer whether "setup payload" means harmless Bank Select, editable expression, or a protected channel-mode command. Naming protected setup rows directly connects the Import Wizard, MIDI PATCH, Hardware Passports, support reports, and future setup assistants into one safety language.

Architecture choice: Add reviewedProtectedSetupOnlyEventCount to MidiImportApplyResult, populate it from MidiInspectionReport::protectedSetupOnlyEvents or per-channel equivalents, serialize it, and mention it in summary/action lines. This is only reporting/accounting; playback/export still use the editable-expression predicate.

Future extensions: Use this counter to render a small "protected rows reviewed" badge in Import Wizard receipts and MIDI PATCH, and later let a confirmed Hardware Passport setup workflow decide whether any protected row can ever be sent.

2026-07-05 - MIDI Scorecards Need Plain Language

Task: Make the MIDI Protocol Coverage panel and report explain why backend protocol completeness and release-readiness percentages can differ.

What connects creatively: A scorecard is only useful if it creates confidence instead of confusion. MIDI has an invisible engineering layer, such as parsing, routing, preservation, timing, and safety gates, and a visible musician layer, such as import decisions, setup helpers, automation editing, and hardware receipts. Naming those two meters directly connects technical progress to the user's lived experience.

Architecture choice: Add one reusable scorecardClarification() method to MidiProtocolCoverageReport, serialize it, include it in plain-text reports, and draw it in the MIDI Protocol Coverage panel. The math stays unchanged; only the human-facing interpretation becomes explicit.

Future extensions: Use the same two-meter language in release notes, diagnostics exports, and beta-test checklists so "backend foundation" and "release readiness" remain separate promises.

2026-07-05 - MIDI Source Trust Should Be Boring

Task: Harden source-aware MIDI Clock/MMC handling so the right Hardware Passport can move SpaceAge and the wrong source cannot.

What connects creatively: Hardware sync should feel uneventful when it is correct. The user should not have to memorize which controller, groovebox, or synth owns tempo and transport authority. If SpaceAge quietly enforces the chosen source, it turns a fragile studio setup into a dependable ritual.

Architecture choice: Match Hardware Passport input source IDs case-insensitively and expose a test hook that applies incoming sync messages with an explicit source ID. Self-tests now prove wrong-source MIDI Clock/MMC messages are ignored and the intended source is accepted.

Future extensions: Use the same source-trust rule in the future Hardware Setup wizard, loopback timing calibration, MPE zone ownership, and support receipts. A user asking "why did playback move?" should get the exact source device and Hardware Passport answer.

2026-07-05 - Conductor Maps Need Real Data

Task: Keep full tempo/meter/key-map adoption review-only until SpaceAge owns a structured timeline-map model.

What connects creatively: A DAW's conductor track is not just metadata; it changes where every note lives in musical time. That means it should be treated like Arrangement architecture, not like a string parsed from an import receipt. The creative upside is large: once real, this can power classical tempo curves, film-cue maps, odd-meter composition, and more faithful MIDI collaboration.

Architecture choice: Preserve reviewed tempo/meter/key rows and allow first-source tempo/key adoption, but avoid full map mutation until a ProjectTimelineMap-style model exists with serialization, undo, playback integration, and UI review.

Future extensions: The same model can support project-level key changes, section-aware tempo shifts, score export, and smarter Chord Engine transposition later.

2026-07-05 - Sync Families Need Symmetric Tests

Task: Extend source-aware sync regression coverage beyond MIDI Clock and MMC to transport chase, Song Position Pointer, and MTC.

What connects creatively: MIDI sync is a family of related authorities, not one switch. If Clock is source-safe but SPP is not, a hardware rig can still surprise the user by moving the playhead from the wrong device. Symmetric source tests make the whole transport/sync family feel like one trustworthy rule.

Architecture choice: Use the processor-owned applyIncomingMidiSyncMessageFromSource() hook for wrong-source and matching-source cases. Count wrong-source messages as observed but ignored, and prove matching-source messages work with case-insensitive Hardware Passport source IDs.

Future extensions: Apply the same symmetry rule to future MPE zones, hardware recall, external automation input, and any feature where one connected device is allowed to control something dangerous while another is not.

2026-07-05 - MIDI AUTO Needs A Bigger Musical Surface

Task: Continue MIDI closeout by making the selected-lane MIDI AUTO scope graph more usable.

What connects creatively: Controller expression is not just diagnostic data. A mod-wheel swell, sustain block, pressure curve, or pitch-bend line is a musical gesture, so the editor should give it enough visual space to feel intentional. Enlarging the selected scope keeps MIDI AUTO on its current selected-pattern contract while making it feel less like a receipt and more like a small workstation.

Architecture choice: Grow the selected expression scope using one shared height constant so painting, list layout, and hit-testing keep agreeing. This avoids inventing a second automation editor and keeps the current selected-lane draw/erase/select/copy/paste backend intact.

Future extensions: The same graph can become the seed of the eventual Piano Roll-grade expression lanes: larger handles, curve/smoothing tools, clip-local ownership, and destination-aware pitch-bend policy can all build on the same model-owned lane plans.

2026-07-05 - MIDI AUTO Graphs Should Explain Themselves

Task: Add value-range and step-span cues to the selected MIDI AUTO expression graph.

What connects creatively: A graph that only shows a curve is still asking the musician to guess what the curve means. Adding small MAX, MIN, CENTER, and STEPS badges makes MIDI expression feel closer to editing a musical object than reading a diagnostics trace. This is the same recognition-rather-than-recall principle that drives the Arrangement Canvas and Chord Engine work.

Architecture choice: Keep the labels inside the existing selected-lane scope rather than creating another inspector. The labels read from the same lane summary fields that already drive hit-testing and value mapping, so pitch bend, bipolar controls, and switch/block lanes can explain themselves without hardcoded per-controller UI.

Future extensions: These lightweight badges can evolve into draggable scale/range handles, curve-type badges, destination-aware pitch-bend range displays, and future full-height Piano Roll expression lanes without changing the expression payload model.

2026-07-05 - MIDI Points Should Feel Touchable

Task: Label hovered or singly selected MIDI AUTO graph points directly inside the graph.

What connects creatively: If a musician is shaping a mod-wheel swell, sustain block, or pitch-bend gesture, the exact point under the cursor should identify itself. This turns the graph from a passive drawing into a touchable musical surface, which fits the larger SpaceAge language of clips, section markers, chord hexes, and living time objects.

Architecture choice: Keep the local point badge purely visual. It reads the same visible ScopeDisplayPoint model already used for hit-testing and selection, then displays the step and editor value without changing the underlying expression payload or adding another inspector dependency.

Future extensions: The same badge pattern can later support point handles, curve knots, automation-tool overlays, per-note expression badges, and context-aware edit affordances in the full Piano Roll-grade expression lane editor.

2026-07-05 - MIDI Names Should Match The Doorways

Task: Align MIDI closeout wording around the current customer-facing surfaces: MIDI AUTO, MIDI PATCH, Hardware Passports, and release readiness.

What connects creatively: The more powerful MIDI becomes, the more dangerous vague labels become. If the app says "Expression Editor" while the button says "MIDI AUTO," or "send" when the workflow is deliberately queue-and-confirm, the user has to translate instead of compose. Matching the report language to the actual doorways makes the safety model feel intentional instead of bureaucratic.

Architecture choice: Keep backend code identifiers stable where they describe existing data structures, but update report-facing categories, action labels, Passport prose, and queue language so the model and UI tell the same story. The MIDI scorecard now prefers "release readiness" when describing the visible finish line, keeping it distinct from backend protocol coverage.

Future extensions: Use this same naming discipline in onboarding, support bundles, hardware setup receipts, and the eventual MIDI dashboard. Every advanced MIDI feature should answer: what is this, what state is it in, what should I do next, and why is that safe?

2026-07-05 - MIDI Setup Needs One Receipt

Task: Turn the MIDI SETUP guide's copy action into a full setup-session receipt.

What connects creatively: Hardware setup is a trust problem as much as a routing problem. A musician may not remember whether they only previewed a device template, applied a project-side draft, queued a test note, or actually sent something to hardware. A single copied session report connects scenario guidance, Hardware Passport preview, lane target, draft diff, test-note plan, receipts, and no-hidden-send promises into one artifact that can be read later without reconstructing the path from screenshots.

Architecture choice: Reuse the existing MIDI SETUP panel models instead of inventing another wizard layer. COPY SESSION composes selected scenario state, target-lane text, device-template preview, project-side diff, test-note plan, last apply receipt, last test-note receipt, and explicit safety language. It does not mutate routing, queue MIDI, or send hardware messages.

Future extensions: The same receipt shape can become an onboarding export, support bundle attachment, hardware setup checklist, and Hardware Passport validation summary. Once device-specific ACK/NAK or loopback proof exists, the session report should include that evidence next to the current SpaceAge-side queue/preflight confidence.

2026-07-05 - MIDI AUTO Should Be Visible Where Notes Are Written

Task: Add a read-only MIDI AUTO preview lane to the Piano Roll.

What connects creatively: A user writing notes should not have to leave the Piano Roll just to discover that the pattern contains mod wheel, sustain, pitch bend, pressure, or other automation. A slim preview lane teaches that expression belongs to the same musical timeline as notes, chords, and velocity while keeping the real editing tools in the guarded MIDI AUTO panel.

Architecture choice: Feed cached MidiExpressionLaneSummary data into PianoRollEditor during refreshPianoRoll() and draw preview traces from model-owned preview points. Do not query processor MIDI data from paint(), and do not imply clip-local automation: the preview remains selected-pattern MIDI AUTO data.

Future extensions: This lane can become the seed of full Piano Roll-grade expression editing: selectable lanes, larger handles, lasso, curve/spline tools, switch-block edge handles, and clear clip-local versus pattern-owned automation choices.

2026-07-05 - MIDI Doorways Should Be Actionable

Task: Turn MIDI AUTO preview/report surfaces into direct navigation doorways.

What connects creatively: A cockpit indicator should not merely announce a problem; it should put the useful control under the hand. If the Piano Roll shows MIDI automation and the protocol report says the next closeout focus is MIDI AUTO, both surfaces should let the user go there immediately. That keeps advanced MIDI from feeling like a separate maintenance mode.

Architecture choice: Reuse existing guarded Settings routes for known closeout surfaces. The Piano Roll preview lane stays read-only but clickable, and the MIDI Protocol Coverage panel receives a model-driven action button from the current blocker category. Known Settings destinations open directly; import/export/roadmap items that live outside the settings popup receive plain status cues instead of fake navigation. No new editor ownership or automation data model is introduced in this pass.

Future extensions: Apply the same pattern to MIDI PATCH, SysEx Vault, Import Wizard, Hardware Passports, and future automation lanes: every diagnostic surface should offer one obvious safe next action.

2026-07-05 - Protocol Rows Should Open Doors

Task: Make MIDI Protocol Coverage family rows clickable when they already advertise a closeout surface.

What connects creatively: A row that says "Go: Open MIDI AUTO" should behave like a doorway, not a paragraph. This is the same product philosophy as Arrangement clips, lane badges, and MIDI Health: visible state should lead directly to the next useful action.

Architecture choice: Reuse the existing actionSurfaceId route and the same guarded Settings callbacks as the top closeout button. Row clicks only navigate to review/edit surfaces or show status guidance; they do not import files, export files, send hardware MIDI, or mutate project state.

Future extensions: If the MIDI dashboard later becomes a full checklist, these row actions can become first-class task cards with completion state, help text, and repair receipts without changing the underlying protocol report model.

2026-07-05 - MIDI AUTO Must Say What It Owns

Task: Make MIDI AUTO visibly identify selected-pattern ownership, shared-pattern reuse, and destination uncertainty.

What connects creatively: Automation can become dangerous when the user thinks they are editing one clip but the data is actually pattern-owned and shared by several clips. Scope badges turn hidden architecture into visible trust language: this is PTN-owned, this PTN may feed several places, and hardware bend range depends on the destination lane.

Architecture choice: Keep the badges read-only and model-adjacent. The MIDI AUTO panel now reports pattern ownership and selected pitch-bend destination trust without changing the automation data model. This avoids pretending clip-local automation exists before we intentionally add it.

Future extensions: When clip-local automation lands, the same badge area can become the ownership switch or confirmation point: pattern-owned, clip-local, lane-default, or motion-clip source. The same trust cue can also support MPE zones and hardware bend-range passports.

2026-07-05 - SysEx Readiness Belongs Beside The Vault

Task: Bring SysEx Vault readiness and restore-trust language into the Vault itself.

What connects creatively: SysEx is one of those features where safety is part of the feature. If the no-autosend and estimated-restore boundaries only live in a copied report, the user may never see them at the moment of action. A visible readiness strip lets the Vault feel powerful without feeling sneaky.

Architecture choice: Reuse the model-owned Vault summary and Librarian readiness plan. The editor now displays the same readiness, next-action, and trust language used by reports instead of inventing another local warning.

Future extensions: This readiness strip can grow into batch capture progress, profile-specific ACK/NAK status, restore verification receipts, and hardware troubleshooting without changing the core Vault safety rule: review first, send only by explicit confirmed action.

2026-07-05 - MIDI Output Should Say The Next Move

Task: Make MIDI Output Preflight show the trust gate's next action as a visible row.

What connects creatively: Hardware output is not just a technical route; it is a confidence contract. If SpaceAge knows the next useful thing is "attach a Hardware Passport" or "refresh the output device," the panel should say that in the cockpit, not only inside a copied support report.

Architecture choice: Keep the next action model-owned in MidiExternalOutputTrustGateReport and surface it in the Output Preflight facts. This stays read-only guidance: it does not auto-fix routes, send MIDI, open devices, or mutate the project.

Future extensions: Use the same visible next-action row in future hardware setup cards, MIDI Health drilldowns, VST/plugin scan repair, and project archive repair. Every diagnostic panel should answer both "what is wrong?" and "what should I do next?"

2026-07-05 - Output Preflight Needs A Fresh Scan

Task: Add a non-destructive CHECK OUTPUT refresh to MIDI Output Preflight.

What connects creatively: Hardware setup is often a physical ritual: plug in a cable, turn on a module, change a USB port, then look back at the app. The panel should support that ritual without making the user close and reopen it. A refresh button turns the preflight page into a live confidence surface rather than a stale snapshot.

Architecture choice: Reuse the same model builders for output readiness, runtime, inventory, repair recommendations, and the output trust gate. CHECK OUTPUT only refreshes the visible snapshot; it sends no MIDI, opens no devices by itself, and mutates no routing.

Future extensions: The same refresh contract can support a guided hardware setup wizard: scan, explain, user changes hardware, scan again, then explicitly test/queue only when the user chooses a confirmed action.

2026-07-05 - MIDI Health Buttons Must Follow The Evidence

Task: Make MIDI Health refresh its repair buttons, reports, and next-step copy from the latest health snapshot.

What connects creatively: MIDI Health is the cockpit. If it updates warning text but leaves old action buttons in place, the user can reasonably lose trust in the whole panel. Hardware setup needs a calm contract: every label, button, and copied report should describe the same current reality.

Architecture choice: Add a non-destructive CHECK HEALTH refresh and make COPY REPORT / COPY STEPS refresh first. The timer now rebuilds action buttons when health evidence changes, but it still does not alter routing, open devices, send MIDI, import files, export files, or mutate project state.

Future extensions: Collapse MIDI Input, MIDI Output, MIDI Health, and MIDI Setup into a shared "preflight card" utility so every panel gets the same refresh/copy/action-button behavior without bespoke logic.

2026-07-05 - MIDI Input Needs The Same Next-Move Language

Task: Give MIDI Input Preflight its own visible next-action row and keep the panel layout aligned with the number of facts it draws.

What connects creatively: MIDI Input is often the first place a musician goes when the keyboard feels dead. The panel should not compress "current verdict" and "what to do next" into one long sentence. Separating them makes the interface feel like a setup assistant instead of a diagnostic paragraph.

Architecture choice: Reuse MidiInputTrustGateReport::nextActionLabel as a read-only fact row, refresh the visible source-policy selector from the current processor state, and reserve layout space for every fact row actually drawn. The button remains a scan/report surface only; no route, lane, or hardware state changes happen from the next-action row.

Future extensions: The shared preflight-card component should own row count, refresh, copy, next action, and action-button alignment so Input, Output, Health, and Hardware Setup cannot drift apart visually.

2026-07-05 - MIDI Health Needs One Door

Task: Add a FIX NEXT doorway to MIDI Health without adding another MIDI workflow vocabulary.

What connects creatively: MIDI Health is the cockpit view. If it can say the next closeout focus is MIDI AUTO, SysEx Vault, Hardware Passport, MIDI PATCH, MIDI Maps, or MIDI Setup, it should be able to take the user there directly. That turns the panel from "diagnostic paper" into a guided instrument panel.

Architecture choice: Reuse the same actionSurfaceId routing already owned by MIDI Protocol Coverage. FIX NEXT refreshes the health snapshot, closes the Health callout, and opens the relevant guarded setup surface. It remains navigation-only: no MIDI send, no import/export, no route mutation, and no project mutation.

Future extensions: MIDI Health can eventually become a unified task list where each blocker row has a clear owner, repair receipt, and validation result, but the first principle should remain the same: diagnostics open doors; they do not secretly do the work.

2026-07-05 - MIDI AUTO Needs A Bigger Trust Surface

Task: Make MIDI AUTO feel less like a compact diagnostic and more like a deliberate editing surface without changing its current ownership model.

What connects creatively: MIDI automation is powerful enough to cause confusing musical side effects if the user does not know what owns it. A larger focused lane view helps the musician see the curve they are touching, while the pattern-owned banner keeps the mental model honest: this edits PTN-level expression, not a private clip-local lane.

Architecture choice: Add a LANE VIEW / LIST VIEW toggle that only changes layout and graph size. It reuses the same selected-lane graph, hit testing, point editing, and model-owned MIDI expression plan. The copy now says NO AUTO-SEND rather than implying the pattern has no MIDI data.

Future extensions: This focused view can become the bridge into true Arranger/Piano-Roll-grade automation later: clip-local ownership, larger handles, curve/tangent tools, switch-block edges, and lane-specific bend policy can arrive without contradicting today's pattern-owned safety rule.

2026-07-05 - MIDI SETUP Should Be A Safe Hub, Not A Maze

Task: Make the MIDI SETUP guide expose MIDI Health as a direct safe-door destination alongside MIDI Input, MIDI Out, Hardware, Timing, MIDI PATCH, SysEx, and MIDI AUTO.

What connects creatively: A hardware setup guide should feel like a little cockpit: if the user gets lost, every important diagnostic room should be one click away. Adding Health to the direct-door row means a musician can move from "help me set up this box" to "show me the whole MIDI trust picture" without hunting through Settings again.

Architecture choice: Treat the bottom row as navigation only. The new Health door closes the setup callout and opens the existing MIDI Health panel; it does not arm lanes, change routes, create Hardware Passports, send test notes, transmit SysEx, import/export files, or mutate project data. Drafts, recalls, test notes, and SysEx remain their own confirmed actions.

Future extensions: This hub can later become a full guided setup wizard, but only if each card keeps the same rule: diagnostics and doors may guide; project writes and hardware sends must preview, confirm, receipt, and stay undoable where project state is changed.

2026-07-06 - MIDI AUTO Needs One Obvious Setup Door

Task: Tighten MIDI AUTO wording so it reads as PTN-owned performance automation, and give review-only setup rows a direct OPEN MIDI PATCH escape hatch.

What connects creatively: A musician should not have to remember our internal split between expressive automation and hardware setup recall. If MIDI AUTO shows a protected Bank/Program/RPN/NRPN row, the interface should immediately offer the correct room instead of scolding them with a dead-end warning.

Architecture choice: Keep MIDI AUTO as the PTN-owned performance editor and MIDI PATCH as the setup/recall review room. The new door closes MIDI AUTO, reopens Sequencer Settings, and launches MIDI PATCH via the same deferred open pattern already used by the Piano Roll MIDI AUTO shortcut. It is navigation-only and does not send hardware MIDI.

Future extensions: The same pattern can become a general "safe door" contract for MIDI surfaces: if the selected data belongs somewhere else, show the correct doorway without mutating the project, changing routes, or transmitting anything.

2026-07-06 - Progress Feedback Is A Trust Instrument

Task: Make MIDI package import/export feel less silent during long operations while keeping the import/project-mutation boundary honest.

What connects creatively: MIDI stem package import/export already has inspection reports and receipts, but a long synchronous operation can still feel like the app has gone blank-eyed. Progress UI is part of SpaceAge's "keep the musician calm" language, the same family as render receipts, the Quasar build window, starfields, and living time objects.

Architecture choice: Give MIDI stem package export a real cancellable progress window because it writes files and does not mutate the live project. Package import is different, so it now uses a message-thread stepper: recheck the package, import one lane stem per timer tick, update the visible receipt between stems, and let cancel mean "stop before the next stem." That gives the user feedback without mutating lanes/clips off the message thread. RECHECK is deliberately scan-only: it lets the user restore files externally and refresh the panel without closing it, but import remains a separate explicit action.

Future extensions: Create one reusable package-task progress contract for Render, MIDI packages, Quasar, sample rendering, archive repair, and future SoundFont/Quasar conversions: clear phase labels, safe cancellation, receipts, and validation after write/import.

2026-07-06 - Safe Import Needs A Temporary Airlock

Task: Guard the app while a MIDI stem package import is actively creating lanes and clips.

What connects creatively: Importing a whole package is not just a file operation; it is a small project-construction event. Treating it like an airlock keeps the user calm: SpaceAge can show progress, allow a clean stop-before-next-stem cancellation, and prevent accidental undo/load/drop actions from colliding with a partially finished arrangement.

Architecture choice: Use an editor-owned busy guard around the message-thread package stepper. The package panel still owns progress text and cancel behavior, but the editor blocks undo/redo, project loads, archive import, recovery load, selected MIDI import, file drops, and starting another package inspection until the transaction is finished.

Future extensions: Generalize this into a ProjectMutationTaskGuard for other long operations such as archive repair, Quasar capture, bulk sample import, and future SoundFont conversion so every big mutation has the same progress/cancel/undo/blocked-action language.

2026-07-06 - Hardware Recall Needs A Glass Door

Task: Let a user copy/review the selected Hardware Passport recall plan even when the actual queue buttons are blocked.

What connects creatively: A disabled button should not be a mystery. Hardware is already a trust-heavy workflow, so the app should show the musician exactly what SpaceAge would send, why it is blocked, and how SysEx changes the plan before any MIDI leaves the computer.

Architecture choice: Add a COPY PLAN button beside the recall actions. It uses the existing HardwareRecallPlanSummary model twice: program recall only, then program recall plus attached SysEx snapshots. The action copies text only and never calls the hardware recall queue.

Future extensions: This same "glass door" idea can power read-only previews for MIDI PATCH setup cards, SysEx restore batches, Motion Clip sends, and future hardware templates: show the plan, show blockers, then require a separate confirmed action to transmit or mutate anything.

2026-07-06 - MIDI Status Should Not Overclaim

Task: Recalibrate MIDI Protocol Coverage and MIDI AUTO wording so the UI says what is truly available now, what is merely guidance, and what still needs release polish.

What connects creatively: A DAW earns trust by being precise. If a button opens a panel, it can say Open. If it only points the user toward a workflow, it should say Review. That small language difference keeps SpaceAge from feeling like a maze with painted doors.

Architecture choice: Keep Protocol Coverage row clicks as navigation/status guidance only, and let MIDI AUTO reports include the same bend destination cue shown on screen. The pitch-bend cue remains informational because hardware bend correctness is destination-owned, not graph-owned.

Future extensions: This same "honest verb" rule should govern every setup surface: Open means a real guarded surface, Check means scan only, Copy means no mutation, Queue means pending confirmed send, and Send means actual hardware transmission with receipt.

2026-07-06 - SysEx Evidence Should Follow The Selected Dump

Task: Make the SysEx Vault show restore evidence for the snapshot the user is actually inspecting, not only a session-wide receipt list.

What connects creatively: A SysEx dump is like a passport stamp for a hardware state. If the user selects one dump, SpaceAge should immediately tell them whether that exact dump is archived, linked to a Hardware Passport, identity-safe, confirmation-gated, and supported by manual or device evidence. This turns the Vault from a storage shelf into a trust ledger.

Architecture choice: Add a selected-snapshot closeout card that reads existing SysExSnapshotSummary and SysExRestoreVerificationReceipt data. It never calls recall/send code and never mutates hardware. COPY REPORT includes the same selected closeout evidence so support/debug text matches the screen.

Future extensions: This pattern can grow into device-specific restore timelines, filtered receipt history, per-Hardware Passport restore notebooks, and eventually guided batch restore, but the rule stays sharp: evidence can inform confidence, while transmission remains a separate explicit confirmed action.

2026-07-06 - Scorecards Need Honest Names

Task: Rename the MIDI Protocol Coverage dashboard-family backend percentage so it does not look like the same high-90s backend-foundation estimate used in project reports.

What connects creatively: A progress meter is a promise. If two meters use similar language but different denominators, the user experiences that as a regression or a contradiction. Honest naming is part of workflow design: it keeps the app from creating emotional noise while the musician is trying to trust the tool.

Architecture choice: Keep the existing math, but change the visible and copied labels to FAMILY BACKEND READY / Tracked-family backend-ready. The scorecard note now says plainly that this dashboard-family denominator includes polish and roadmap rows, while backend foundation means lower-level MIDI 1.0 plumbing.

Future extensions: All future readiness surfaces should name their denominator explicitly: core engine, tracked family, release readiness, future roadmap, validated hardware, or customer-facing workflow. Percentages should never float free from the thing they are actually measuring.

2026-07-06 - MIDI AUTO Needs Doors Where Musicians Look

Task: Make MIDI AUTO easier to find from the Piano Roll and Arrangement lane workflow without inventing a new automation ownership model.

What connects creatively: Automation becomes useful only when a musician can find it while composing. A hidden Settings route makes MIDI AUTO feel like a maintenance panel; a visible Piano Roll button and lane-signal command make it feel like part of the musical surface alongside notes, chords, velocity, instrument choice, and MIDI routing.

Architecture choice: Add navigation-only doorways to the existing selected-pattern MIDI AUTO editor. The direct Piano Roll button lights when the selected pattern already has automation summaries, and the Arranger lane command targets a real clip on that lane before opening the same PTN-owned editor. Do not imply clip-local or lane-local Arrangement automation until that storage model exists.

Future extensions: When true Automation Lanes and Motion Clips arrive, reuse the same doorway principle but name the scope explicitly: PTN automation, clip-local automation, lane automation, project automation, or Motion Clip. The user should always know what will be affected before they draw a curve.

2026-07-06 - MIDI AUTO Should Explain Its Current Lane

Task: Make the MIDI AUTO selected-lane state more readable without expanding the feature scope.

What connects creatively: MIDI expression can be musical or dangerous setup data depending on the message. A small check strip lets the same editor teach the difference in place: editable performance lanes are welcome in MIDI AUTO, while setup/protected lanes belong in MIDI PATCH. This turns a technical safety rule into a visible workflow rule.

Architecture choice: Reuse MidiExpressionEditorPlan instead of hardcoding new panel copy. The strip labels the lane as editable or review-only and previews the first few model-owned finish-line items, keeping copied reports, status text, and panel hints aligned.

Future extensions: The same strip can later become the doorway for clip-local ownership, Motion Clip conversion, curve/tangent tools, switch-block edge handles, or Hardware Passport bend policy when those features stop being checklist items and become actual controls.

2026-07-06 - Safety Doorways Should Not Hide

Task: Keep MIDI PATCH reachable from MIDI AUTO even when the selected MIDI AUTO lane is editable.

What connects creatively: Safe navigation should be easier than risky action. If MIDI PATCH is the proper home for protected bank/program/RPN/NRPN setup data, then hiding its doorway until the exact protected row is selected teaches the wrong lesson. The always-available button makes the safety path feel like part of the workflow instead of a punishment state.

Architecture choice: Change only the button availability and tooltip. The action remains navigation-only, routes through the existing MIDI PATCH surface, and still sends no MIDI.

Future extensions: This pattern should apply to Hardware Passport, SysEx Vault, MIDI Health, and future repair surfaces: doors to review/safety panels should be visible, while actual hardware-affecting actions stay separately confirmed.

2026-07-06 - MIDI AUTO Handles Should Feel Human

Task: Make expression-point handles easier to see and grab in MIDI AUTO LANE VIEW.

What connects creatively: The model can be correct and still feel cheap if the user has to hunt tiny points. Bigger handles in focused lane view help automation feel like an instrument-editing surface rather than a spreadsheet graph, while the compact list preview can stay restrained.

Architecture choice: Increase visible point size and hit-test forgiveness only when LANE VIEW is active. This improves the first-pass editor without changing pattern ownership, export behavior, MIDI storage, or the guarded mutation path.

Future extensions: The same focused-view affordance can grow into full curve/tangent handles, switch-block edge handles, value badges, and clip-local ownership prompts once those become real controls.

2026-07-06 - SysEx Batch Capture Needs A Clipboard-First Door

Task: Add a read-only SysEx Vault action that explains the future batch-capture workflow without pretending batch capture is already finished.

What connects creatively: Hardware workflows should be previewable before they are actionable. A musician may know they need to capture several dumps from a QY, MiniNova, rack synth, or drum module, but they should see SpaceAge's safety contract before any dump enters the Vault: expected count, source device, Hardware Passport target, duplicate review, per-dump receipts, and no hidden restore/send behavior.

Architecture choice: Reuse SysExBatchCapturePlan and expose it through COPY BATCH DRY RUN. The button copies text only. It does not arm capture, save a snapshot, queue restore, send SysEx, or mutate the project. This keeps batch capture honest as a designed-but-not-finished librarian workflow.

Future extensions: When the live multi-dump inbox exists, this copied plan can become the preflight card for a full guided session: choose source, set expected dump count, capture receipts one by one, detect duplicates/out-of-order dumps, then save only approved dumps into the SysEx Vault.

2026-07-06 - MIDI AUTO Should Teach With The Cursor

Task: Improve MIDI AUTO's graph affordance so users can discover drawing, erasing, lasso selection, group selection, and point dragging before they memorize the editor.

What connects creatively: A dense MIDI automation editor should feel like a musical surface, not a hidden contract. Cursor changes and a tiny in-graph hint give immediate sensory feedback: "this space draws," "this point drags," "Shift selects groups," and "review-only setup data is protected." That helps SpaceAge stay powerful without becoming cryptic.

Architecture choice: Keep durable warnings and ownership text in the existing status strip, then add transient graph-only gesture hints that clear on mouse exit, lane changes, target clearing, and pattern refreshes. The hint system reads the current selected lane and does not change storage, ownership, export, or hardware routing.

Future extensions: Use this same interaction vocabulary for Automation Lanes, Motion Clips, clip gain fades, chord-marker resizing, SysEx librarian batch capture, and future curve/tangent handles: cursor first, transient local hint second, durable warning/status third.

2026-07-06 - Hardware Passports Need One Closeout Receipt

Task: Add a copy-only Hardware Passport closeout report that summarizes whether one selected external instrument is ready for confident use.

What connects creatively: Hardware MIDI setup can scatter truth across devices, channels, bank recipes, SysEx dumps, timing calibration, bend ranges, sync roles, and queue logs. A single closeout report gives the user a calm "mission control" readout before they trust a MiniNova, QY, rack synth, or drum machine inside a song.

Architecture choice: Build the closeout from existing Passport summaries, raw Passport data, and recall plans. The action copies text only and does not checkpoint, mutate project state, send MIDI, queue recall, or restore SysEx.

Future extensions: This can become the final card in a guided first-hardware setup assistant: create Passport, choose output, send confirmed test note, declare bend range, calibrate timing, attach SysEx/setup cards, then copy closeout before the first serious recording pass.

2026-07-06 - Hardware Setup Should Say What Happens Next

Task: Make the Hardware Passport workflow more guided without adding hidden sends or another modal wizard.

What connects creatively: External MIDI setup is where musicians can lose trust quickly, because the software, cable path, hardware channel, patch recipe, SysEx memory, timing, and bend range all have to agree. A tiny NEXT SAFE STEP on the selected Passport and a CONNECT THIS SYNTH strip in MIDI SETUP turn the workflow into a guided checklist while preserving the no-autosend contract.

Architecture choice: Reuse existing Passport summary facts and recall-plan readiness instead of creating a second setup state machine. APPLY DRAFT remains a confirmed project-side mutation, TEST NOTE remains a confirmed note-on/off send, and the Hardware Passport page remains a review/recall/sync surface.

Future extensions: The same next-step helper can evolve into a full first-hardware assistant: choose target lane, apply Passport draft, pick MIDI OUT, send confirmed test note, declare bend range, calibrate timing, attach setup/SysEx knowledge, then copy closeout. The UI should keep showing where hardware will be affected before anything is sent.

2026-07-06 - Bound Hardware Dumps Before Automating Them

Task: Add an optional expected-dumps count to the SysEx Vault batch-plan workflow.

What connects creatively: Hardware dumps need the same "visible mission boundary" philosophy as Hardware Passports. A user dumping a MiniNova, QY, rack synth, or drum module should be able to say, "I expect five dumps," then copy a plan that describes what SpaceAge will look for before any future live multi-dump inbox starts collecting data.

Architecture choice: Feed the optional EXPECTED DUMPS value and current one-dump capture evidence into the existing SysExBatchCapturePlan. The action remains clipboard-only: it does not arm capture, save a snapshot, queue restore, send SysEx, or mutate the project.

Future extensions: When true multi-dump capture arrives, this field can become the visible target for a progress meter, duplicate detector, and final save-review checklist. The same bounded-session idea should also apply to future sample imports, hardware preset scans, and batch MIDI remapping operations.

2026-07-06 - Switch Automation Should Look Like Blocks

Task: Make MIDI AUTO switch-style lanes, such as sustain, easier to understand and edit in the selected-lane graph.

What connects creatively: Continuous CC lanes are curves, but switch lanes are musical gates. Drawing them as visible on/off blocks with edge handles connects MIDI AUTO to loop ranges, section markers, clip blocks, and future Motion Clips. The user should not have to decode a tiny stair-step line to understand that a pedal or switch is held.

Architecture choice: Improve only the drawing and hit-target affordance in the existing selected-lane graph. The data remains shared PTN MIDI automation, the same event hit-testing is used, and no hardware output or MIDI export behavior changes.

Future extensions: This block vocabulary can later become editable automation blocks with left/right trim handles, modifier-key duplication, and paint-to-toggle behavior. It can also guide UI for latch/sustain controls in arpeggiators, gate patterns, Flux Nodes, and live hardware CC capture.

2026-07-06 - Pitch Bend Needs Visible Trust

Task: Make destination pitch-bend policy visible in MIDI AUTO and Hardware Passports without adding another hardware action.

What connects creatively: Pitch bend is unusual because the same MIDI data can mean different musical intervals on different instruments. A curve that sounds right on Redshift may bend wildly on a MiniNova or QY unless the destination range is known. Making BEND POLICY visible turns that invisible contract into a normal part of external-instrument setup.

Architecture choice: Surface existing model truth only. MIDI AUTO reads the selected pattern's arrangement destination and Hardware Passport bend-range policy; Hardware Passport rows already carry a pitch-bend policy summary. The UI now displays those facts more clearly, but no new MIDI is sent and no route is changed.

Future extensions: This should grow into a guided bend setup ritual: declare destination range, send a separately confirmed bend-test phrase, store the result in the Hardware Passport, and warn on clips or lanes whose pitch-bend curves target destinations without a policy.

2026-07-06 - SysEx Batch Capture Needs A Visible Preflight

Task: Show the SysEx batch-capture safety plan inside the Vault before live multi-dump batch capture exists.

What connects creatively: SysEx is one of the few parts of MIDI where the user is really interacting with a hardware instrument's memory. That makes it feel less like note editing and more like a careful transfer ritual. A visible BATCH PREFLIGHT strip turns the ritual into something understandable: source, expected dumps, captured dumps, remaining dumps, timeout, and what SpaceAge will not do behind the user's back.

Architecture choice: The visible strip uses the same SysExBatchCapturePlan model as the copied text report. That prevents two separate stories from emerging: the UI and the clipboard report now share the same expected/captured/remaining counts and the same no-autosend policy.

Future extensions: When live multi-dump batch capture arrives, the strip can grow into an inbox with one receipt per dump, duplicate/out-of-order warnings, per-dump naming, and a final "save reviewed batch" action. The important rule stays intact: every dump becomes evidence before it becomes project state.

2026-07-06 - MIDI Readiness Needs Named Trust Levels

Task: Tighten MIDI Protocol Coverage, MIDI Health, SysEx, Hardware Passport, and MPE wording so percentages and preflight states do not overpromise.

What connects creatively: MIDI is not just one protocol checkbox. There is backend understanding, customer-facing workflow, and real-world hardware acceptance. If those trust levels share loose words like "ready," a user can reasonably believe SpaceAge has proved more than it has. Clear language protects the product promise and makes the app feel more professional.

Architecture choice: Keep the math and safety models where they already live, but rename the visible/reporting layer: TRACKED BACKEND ROWS, CUSTOMER ROWS CLEAR, MIDI 1.0 CLOSEOUT PROGRESS, Preflight clean, BATCH DRY RUN, and MPE-like preservation, not true MPE. Hardware timing estimates now say they are SpaceAge queue/wire estimates, not external-device acknowledgement.

Future extensions: Use the same named-trust ladder in future VST hosting, Quasar capture, Instrument Bay scans, sample-browser metadata, and hardware librarian workflows: parsed, editable, preflight clean, queued, sent, acknowledged, manually verified, product-ready. A user should always know which rung they are standing on.

2026-07-06 - Closeout Is Not Certification

Task: Remove remaining release-readiness and product-readiness labels from the live MIDI protocol report and replace them with current MIDI 1.0 closeout language.

What connects creatively: SpaceAge can feel more trustworthy by saying exactly what kind of progress it is reporting. "Closeout" sounds like an engineering work queue: remaining blockers, next surface, next safe action. "Release readiness" sounds like a product certification claim, and it invites the same confusion that made a high-90s backend estimate look like it had moved backward.

Architecture choice: Leave the underlying blocker math intact but rename the user-facing and copy-report labels. The percentage still comes from the existing protocol-family model; the change is semantic honesty, not a new readiness calculation.

Future extensions: Apply the same vocabulary discipline to Instrument Bay, Effects, Quasar, and hardware workflows: use precise operational labels for work-in-progress surfaces, and reserve launch/certification language for documented, tested, user-visible promises.

2026-07-06 - Hardware Recall Should Be A Queue, Not A Crowd

Task: Make confirmed Hardware Passport recall queue SysEx/program messages against one rolling timeline instead of scheduling each message from "right now."

What connects creatively: External instruments often feel fragile because their memory operations happen outside the app. A recall plan should behave like a careful transfer ritual: one message, then the next, then the next. If three SysEx dumps all become due at the same moment, the UI may still look calm while the hardware receives a pileup. Serial pacing makes Hardware Passports feel more like a real studio assistant and less like a blind blast of bytes.

Architecture choice: Reuse the existing absolute-due-time router path and keep each item reporting its own per-message planned delay. The transfer estimate, pending-delay counters, and recall log stay honest, while the actual queue now places each item on a cumulative schedule.

Future extensions: Device-specific ACK/NAK matching should eventually use source/profile/device evidence rather than accepting any incoming SysEx while a restore is active. The same rolling-schedule discipline should apply to future setup-card sends, librarian batch restores, and any hardware operation where a user can attach multiple payloads.

2026-07-06 - MIDI AUTO Needs Honest Clip Context

Task: Make MIDI AUTO show the selected Arrangement clip and source-step range when the user opens automation from a lane/clip context.

What connects creatively: Arrangement clips can show only part of a longer pattern, so a user needs to know whether they are looking at a whole PTN or a specific clip slice. Showing CLIP CONTEXT beside the source steps connects MIDI AUTO to Arrangement clip previews, source ranges, Variant/Ack Shared decisions, and future clip-local automation without pretending the ownership model has changed.

Architecture choice: Add a read-only context row to the MIDI AUTO panel. Automation remains PTN-owned, shared-pattern safeguards remain intact, and no export/playback behavior changes. The UI now tells the truth: selected clip, lane, source steps, arranger steps, and the pattern that will actually be edited.

Future extensions: If SpaceAge later gets clip-local automation, this context row can become the ownership switch and migration preview: leave automation on the PTN, copy it into a clip-local layer, or create a Variant first. The same source-range vocabulary should also guide future Motion Clips, clip decorations, and per-clip effect throws.

Support/reporting pass: The copied MIDI AUTO report now includes the same selected Arrangement context shown on screen. That keeps troubleshooting and user education aligned: a support receipt can say which clip slice was visible while still saying the edit writes the underlying PTN.

Wording pass: MIDI AUTO should never sound like it is editing a free-floating Arrangement lane or private clip layer when it is still writing pattern-owned data. Customer-facing labels now lean on "MIDI AUTO" and "pattern variant" so the language matches the actual ownership model.

Switch-lane language: Sustain-style MIDI automation is technically event points, but users perceive it as ON/OFF regions. Until there is a true block editor, hover and drag text should call these switch blocks and switch edges. This keeps the mental model closer to the musical job than the storage detail.

Context resolver pass: Pitch-bend policy now asks the selected clip context first before falling back to pattern-wide lane discovery. That matters when one PTN appears in multiple lanes: the graph can show the correct destination warning for the clip the user actually opened, while still warning when no specific clip context is available.

Edit receipt pass: Copy, paste, delete, nudge, and move receipts now use switch-edge language for switch-style lanes and point language for continuous lanes. This small wording layer protects the larger architecture because the storage model can stay event-based while the user sees the musical behavior they expect.

Visual target pass: The compact Piano Roll MIDI AUTO lane should feel like an actual time object instead of a mystery strip. The lane now has a stronger labeled badge, hover affordance, and block-style switch drawing for sustain-like automation. The expanded editor also gives CLIP CONTEXT / PATTERN CONTEXT a larger card treatment so the user sees the source range and PTN ownership before touching automation.

Switch-block edge affordance pass: MIDI AUTO switch lanes should behave like blocks, not point curves. Sustain-style lanes now use tall draggable edge handles and rectangular hover/selection halos, which lets the visual language match the user's mental model: move an edge to resize or timing-shift a block, use Up/Down to toggle ON/OFF, and reserve point dots for continuous CC, bend, and pressure lanes.

Switch-aware receipt pass: The editor should not teach two models at once. Selection, lasso, drag, nudge, and selected-lane hint text now describe switch lanes as ON/OFF blocks and switch edges, while continuous lanes remain points and values. This keeps the data model event-based but lets the user's hands learn one consistent gesture language.

Source-view honesty pass: A selected Arrangement clip can focus the graph on its source range, but MIDI AUTO still writes pattern-owned automation. The UI now says SOURCE VIEW, FIT SOURCE, and front-loads edits write PTN# so the user understands the selected clip is a viewing/editing context, not a private clip-local automation layer. This protects the future architecture: true clip-local automation can still arrive later as an explicit ownership model instead of a silent behavior change.

2026-07-06 - MIDI Learn Needs Cockpit States

Task: Make MIDI Learn's state legible at a glance while preserving the existing guarded learn/confirm workflow.

What connects creatively: MIDI Learn is a trust ritual: pick a destination, move a hardware control, decide whether the source replaces an old mapping or becomes a macro. A musician should not have to parse a full sentence to know whether SpaceAge is idle, listening, reviewing a conflict, or finished. A small state badge connects MIDI Learn to the rest of SpaceAge's preflight language without adding another workflow.

Architecture choice: Add a visible state badge to the MIDI Maps learn strip: IDLE, LISTENING, REVIEW SOURCE, REVIEW CONFLICT, or MAPPED. This is UI clarity only; it does not change routing, capture filters, source-conflict policy, or the existing REPLACE/MACRO/CANCEL confirmation step.

Future extensions: Use the same state vocabulary in future direct-control learn, hardware setup wizards, VST parameter learn, Instrument Bay macros, and automation capture. The principle is durable: the app should say what state it is in before asking the user to commit.

2026-07-06 - MIDI AUTO Should Glow Where The Music Lives

Task: Make MIDI AUTO easier to discover from the Arrangement Canvas without adding another top-row button or changing automation ownership.

What connects creatively: Automation is not just a Settings feature; it is part of a lane's musical behavior. If a lane contains clips that reference patterns with MIDI AUTO data, the lane badge should quietly say so. That connects Arrangement clip interiors, Piano Roll automation, lane signal routing, and future Motion Clips into one visual grammar: the object that has time-varying behavior carries a small time/expression cue.

Architecture choice: Add a lane-level automation flag to the Arrangement Canvas draw state and render the lane Signal button as a blue A whenever any real clip on that lane references a pattern with MIDI AUTO lanes. The underlying model remains PTN-owned pattern automation; this is discoverability only.

Future extensions: The same flag can grow into richer lane badges later: clip-local automation, lane-wide automation, Motion Clips, CC density warnings, or hardware-expression warnings. If we eventually add collapsible automation lanes under each Arrangement lane, this A badge becomes the natural doorway.

2026-07-06 - Hardware Progress Must Not Overpromise

Task: Make the Hardware Passport queue panel show live transfer phase, next action, and the trust boundary directly in the UI.

What connects creatively: SysEx and hardware recall are psychological trust moments. A user needs feedback that SpaceAge is still working, but they also need to know the difference between "SpaceAge is draining its timed queue" and "the external synth accepted the data." Putting that boundary in the panel connects Hardware Passports, SysEx Vault, recall logs, and future hardware setup wizards into one honest support language.

Architecture choice: Keep send timing and queue behavior untouched. The change is presentation-only: the Hardware Passport panel now shows the queue phase, recommended next action, and a clear note that queue/wire timing is SpaceAge-side progress rather than hardware acknowledgement.

Future extensions: Device-specific ACK/NAK parsing, retry policy, and restore receipts can eventually upgrade this from estimated transfer confidence to device-confirmed confidence. Until then, every customer-facing hardware surface should say what SpaceAge knows and what it cannot yet prove.

2026-07-06 - MPE Needs Its Own Truth Line

Task: Make MIDI Health show MPE readiness as its own line instead of burying it inside generic future MIDI protocol copy.

What connects creatively: MIDI guitar, wind controllers, expressive controllers, and imported channel-per-note performances are exactly the kind of customers we want to court later. But MPE is a promise with teeth: zones, member channels, bend ranges, per-note pressure/timbre, and synth response all have to agree. A dedicated Health row lets SpaceAge say "we preserve MPE-like expression as MIDI 1.0 data" without accidentally saying "true MPE is done."

Architecture choice: Reuse the model-owned MidiMpeReadinessPolicy already produced by MIDI Health. The UI only surfaces its summary; it does not change import, export, playback, lane routing, synth behavior, or protocol support.

Future extensions: This line can eventually become the launch point for a real MPE setup surface: lane/device mode, zone layout, member-channel allocation, bend range, synth compatibility, and import/export validation. Until those pieces exist, the row protects marketing and support language from drifting into overclaim.

2026-07-06 - Short MIDI Receipts Need The Same Boundary As The Cockpit

Task: Add the MPE boundary to MIDI Health's short COPY STEPS checklist, not only the visible cockpit row and full report.

What connects creatively: The short next-steps checklist is the artifact a musician or support helper is most likely to paste into a forum, email, or bug note. If the compact receipt omits the MPE boundary, it can accidentally make SpaceAge sound closer to true MPE than it is. The little receipt needs the same honesty as the big cockpit.

Architecture choice: Reuse MidiMpeReadinessPolicy::summary() in MidiProjectHealthSummary::toPlainTextNextSteps(). This is copy text only. It does not change MIDI routing, import/export, playback, synth response, Hardware Passport behavior, or MPE support.

Future extensions: When true MPE becomes real, this one-line boundary can become a one-line readiness statement. Until then, all MIDI status surfaces should keep saying the same thing at different levels of detail: preserve expressive MIDI 1.0 data now; do not claim zone/member-channel MPE until the full behavior exists.

2026-07-06 - MIDI AUTO Is The Workbench Name

Task: Remove stale visible "expression lane" wording from the MIDI AUTO editor's musician-facing status text and tooltips.

What connects creatively: Users should not have to remember that MIDI AUTO, MIDI expression, and automation events are related but not identical terms. The button, panel, and gestures should teach one workbench name: MIDI AUTO. Lower-level docs and models can still say expression data when they mean the stored MIDI material.

Architecture choice: Patch only UI copy inside the MIDI AUTO editor. No MIDI storage, pattern ownership, clip-local policy, transform behavior, import/export, or hardware routing changed.

Future extensions: When true clip-local or lane-local automation exists, this wording discipline will matter even more. MIDI AUTO lane can remain the editor unit, while ownership labels can say PTN-owned, clip-local, or lane-local without forcing the user to learn a second product name.

2026-07-06 - Closeout Doors Should Take The User Somewhere

Task: Make MIDI Health and MIDI Protocol Coverage closeout actions navigate to the relevant workstation for import/export guidance instead of only posting a status breadcrumb.

What connects creatively: Diagnostics should behave like a useful copilot, not a trivia quiz. If SpaceAge says the next MIDI closeout item is import flow or export flow, the app should move the user to Sequencers or Arranger immediately and explain the next visible control to use. This ties Health, Protocol Coverage, MIDI TASKS, and RENDER into one discoverable support loop.

Architecture choice: Navigation-only UI routing. Import closeout now opens Sequencers and points to MIDI TASKS; export closeout opens Arranger and points to RENDER. No MIDI data, routing, project state, import/export behavior, or hardware behavior changes.

Future extensions: When dedicated import/export wizard surfaces exist, these action IDs can route directly to them. Until then, the closeout buttons should always move the user to the closest real surface rather than merely naming it.

2026-07-06 - Support Receipts Should Say What They Did Not Do

Task: Add text-only safety language to the MIDI Protocol COPY CLOSEOUT button and copied checklist.

What connects creatively: MIDI support reports often get pasted outside the app, where context is lost. If the receipt explicitly says it sent no MIDI, changed no routing, and changed no project data, then diagnostics, support, and user trust all share the same language.

Architecture choice: Tooltip and copied-text change only. The button still copies the closeout checklist; it does not touch MIDI, routing, hardware queues, imports, exports, or project state.

Future extensions: Every copy/export diagnostic receipt that deals with hardware, SysEx, routing, or project safety should include a similarly explicit "what did not happen" line.

2026-07-06 - One Command Name Per Musical Idea

Task: Rename the MIDI AUTO shared-pattern escape hatch from MAKE VARIANT to VARIANT in the button and guard copy.

What connects creatively: The Arrangement Canvas already teaches VARIANT as the word for "make this clip/pattern independent before editing." MIDI AUTO should reuse that exact word instead of reintroducing the older longer label. One name means less translation in the user's head.

Architecture choice: Copy/UI label only. The shared-pattern guard, pattern-copy behavior, ACK SHARED option, undo behavior, and MIDI AUTO ownership model are unchanged.

Future extensions: This same nomenclature discipline should be applied anywhere old command names linger: CLONE, VARIANT, FUSE, 86, MIDI AUTO, Instrument Bay, and future clip-local automation.

2026-07-06 - Manual SysEx Verification Is Evidence, Not A Device Voice

Task: Tighten the SysEx Vault MARK VERIFIED wording so it cannot be mistaken for a hardware-generated ACK.

What connects creatively: Silent vintage hardware should not trap the user in an impossible workflow. If a QY, rack synth, or other external device has no response dialect we understand, the musician still needs a way to say, "I checked the device and the restore worked." That human receipt connects Hardware Passports, SysEx Vault, support reports, and future restore-history views without pretending the external box spoke back.

Architecture choice: Copy and report wording only. MARK VERIFIED still records a manual restore-verification receipt and still sends no MIDI. The tooltip and Vault report now say to use it only after checking the hardware, and that the receipt is useful user-confirmed evidence, not a device-generated ACK.

Future extensions: Add optional manual-verification notes, per-passport restore-history filters, and device-specific guidance such as "check patch name on display" or "audition restored bank slot" before enabling the manual receipt.

2026-07-06 - SysEx Copy Buttons Should Wear Their Safety Label

Task: Add text-only safety wording to the SysEx Vault COPY REPORT affordance.

What connects creatively: The Vault report can include dangerous-looking words: SysEx, restore, ACK, NAK, Passport, device, queue. A musician should never have to wonder whether copying that report might also send something. The tooltip makes the action emotionally boring in the best way: it copies text, and nothing else happens.

Architecture choice: Tooltip only. COPY REPORT continues to copy Vault summaries, restore trust, selected snapshot detail, and recent restore receipts. It does not send SysEx, queue recall, or mutate project data.

Future extensions: Standardize this "text only" safety tooltip across every diagnostic export/copy/report button that mentions hardware, routing, restore, import, or project state.

2026-07-06 - Package Import Needs One Dangerous Button

Task: Tighten MIDI package import tooltips and confirmation copy so report, repair, reveal, and recheck helpers cannot be mistaken for project-changing actions.

What connects creatively: Collaborator handoff should feel calm. A package panel may mention missing files, checksums, stems, imports, and repairs, which can make every button feel dangerous. The interface should teach one bright rule: IMPORT STEMS is the mutating action; everything else is a text, file-location, or scan helper.

Architecture choice: Copy and tooltip changes only. COPY REPORT, COPY REPAIR STEPS, REVEAL PACKAGE, and RECHECK remain non-mutating helpers. IMPORT STEMS still re-checks and confirms before creating editable Arrangement lanes/clips.

Future extensions: The full package repair flow should eventually use the same contract: scan first, explain exactly what will change, then perform the one explicit mutating action only after confirmation.

2026-07-06 - Repair Receipts Should Be Self-Contained

Task: Add the exact REVEAL PACKAGE and RECHECK button names to copied MIDI package repair steps.

What connects creatively: A collaborator may paste repair instructions into email, chat, or a support note. The text should not require them to remember the panel layout. Naming the buttons turns the receipt into a tiny workflow: reveal folder, repair files, recheck, then import.

Architecture choice: Copied repair text only. No file repair, package inspection, import, export, checksum, or project mutation behavior changed.

Future extensions: Package repair receipts can later include one-click "copy missing file list" and "copy checksums only" variants, but every receipt should still state the next visible button in the app.

2026-07-06 - Hardware Passport Buttons Need Honest Temperature

Task: Add clearer tooltips to Hardware Passport queue and copy buttons so the user can tell which actions are harmless text copies and which actions can transmit hardware-changing MIDI after confirmation.

What connects creatively: Hardware control is powerful, but the interface should not make every button feel equally risky. COPY PLAN, COPY CLOSEOUT, COPY LOG, and COPY QUEUE are documentation/report actions. QUEUE PROGRAM RECALL and QUEUE RECALL + SYSEX are the hot buttons that can change an external synth, drum machine, or module. Naming that difference makes Hardware Passports feel professional instead of spooky.

Architecture choice: Tooltip-only change. Existing confirmation, queue scheduling, SysEx pacing, recall logs, and Hardware Passport data remain unchanged.

Future extensions: The same "button temperature" idea can drive color and grouping later: cold copy/report actions, warm setup/save actions, and hot send/restore actions.

2026-07-06 - MIDI Setup Drafts Need Button Temperature Too

Task: Add explicit tooltips to MIDI Setup's template preview, draft apply, test note, and draft undo controls.

What connects creatively: The setup guide is a teaching surface. It should explain the difference between copying a preview, changing the SpaceAge project, sending one safe note, and rolling back a draft without forcing the user to click first. This extends the same cold/warm/hot button language from Hardware Passports into the first-run hardware setup path.

Architecture choice: Tooltip-only change. Setup previews, apply confirmation, protected rollback snapshots, and the guarded one-note hardware test continue to behave as before.

Future extensions: The Settings/MIDI surfaces can eventually share a reusable safety badge or action-temperature helper so every MIDI hardware action teaches its risk level consistently.

2026-07-06 - Repair Buttons Should Teach Safe Navigation

Task: Add consistent safety language to MIDI Input, MIDI Health, and MIDI Output repair-action button tooltips.

What connects creatively: MIDI diagnostics are more useful when they move the user to the right surface. But a button labeled with a repair action can sound like it might fix routing, open ports, or send hardware MIDI automatically. The tooltip now teaches that repair buttons are safe doors: they open or refresh the relevant MIDI setup surface, and the actual setup/send choices remain explicit.

Architecture choice: Tooltip-only change across existing repair recommendation buttons. Routing, refresh behavior, Health navigation, MIDI Output/Input panels, and hardware send paths are unchanged.

Future extensions: This could become a reusable safeDoorTooltip() helper so every diagnostic doorway in SpaceAge speaks with the same calm voice.

2026-07-06 - SysEx Reports Need The Whole Paper Trail

Task: Make the SysEx Vault COPY REPORT include live-capture status and future batch-capture preflight, and add clearer capture-button safety tooltips.

What connects creatively: SysEx is one of the scariest parts of hardware integration because a dump can mean "backup," "restore," "overwrite," or "mystery blob from 1994." A copied report should gather the whole story in one place: what is stored, what capture is doing now, what batch capture can and cannot do, what restore trust exists, and what evidence is still missing.

Architecture choice: Report/tooltips only. COPY REPORT and COPY CAPTURE remain text-only; ARM CAPTURE remains a one-dump listener that sends nothing; SAVE CAPTURE changes project Vault data but still sends no MIDI, queues no restore or recall, and changes no external hardware.

Future extensions: When live multi-dump capture arrives, each dump should create its own receipt before entering the Vault, and the batch report should remain a preflight/receipt bundle rather than a hidden hardware action.

2026-07-06 - MIDI Setup Needs A Button-Temperature Legend

Task: Add explicit text-only tooltip copy to MIDI Setup COPY SESSION, add safe-door wording to NEXT ACTION, and include a button-temperature legend in copied setup sessions.

What connects creatively: Hardware setup is a sequence of small decisions, and fear comes from not knowing which buttons can change something. The session receipt now teaches the whole temperature scale: cold copy buttons, safe-door navigation buttons, warm project mutations, hot test-note sends, and undo. This matches the Hardware Passport and SysEx Vault safety language and makes setup receipts useful in support conversations.

Architecture choice: Copy and tooltip only. COPY SESSION still copies text; NEXT ACTION still navigates to the relevant surface; APPLY DRAFT, TEST NOTE, and UNDO DRAFT keep their existing confirmation and behavior.

Future extensions: The same button-temperature legend can become a small reusable visual language in Settings: cold text actions, safe doors, warm project changes, and hot hardware sends.

2026-07-06 - MIDI AUTO Source View Must Not Pretend To Be Clip Ownership

Task: Make copied MIDI AUTO reports state the ownership boundary for SOURCE VIEW and FIT SOURCE.

What connects creatively: A selected Arrangement clip can focus the graph on the clip's source range, which is useful and musician-friendly. But the data is still stored on the underlying PTN. If that distinction is not explicit, the user could edit what looks like one clip and accidentally change every linked clip. The report now says the quiet part loudly: SOURCE VIEW focuses the range; it does not create clip-local automation.

Architecture choice: Copy/status/tooltip wording only. MIDI AUTO remains PTN-owned performance automation. Shared patterns still require VARIANT for independence or ACK SHARED for intentional linked edits.

Future extensions: When true clip-local automation exists, it should be a separate ownership mode with its own label, serialization, undo rules, and conversion command rather than a silent interpretation of SOURCE VIEW.

2026-07-06 - Shared Pattern Automation Needs A Two-Step Door

Task: Make MIDI AUTO ACK SHARED require an armed second click before unlocking edits that affect every Arrangement clip sharing a PTN.

What connects creatively: SpaceAge already treats VARIANT as the creative escape hatch: make a related idea independent before reshaping it. ACK SHARED is the opposite, and therefore more dangerous. It says, "Yes, edit the shared musical DNA." That should feel deliberate. A two-step door keeps the workflow fast while preventing one nervous click from changing every chorus, verse, or clone using the same pattern.

Architecture choice: UI guard only. The automation ownership model is unchanged: MIDI AUTO remains PTN-owned. The first click arms the shared edit, changes the button to CONFIRM ACK, and warns the user. The second click unlocks shared-pattern editing.

Future extensions: If we add clip-local automation, the shared-pattern guard can become a broader ownership chooser: Variant Pattern, Edit Shared Pattern, or Create Clip Automation Layer.

2026-07-06 - A Safety Latch Must Have A Natural Escape

Task: Make the half-armed MIDI AUTO ACK SHARED state clear itself on Escape, refresh/context changes, target clear, or selecting another MIDI AUTO lane.

What connects creatively: A two-step confirmation should feel like a deliberate latch, not a trap. If a musician arms shared-pattern editing, then changes their mind, selects something else, or hits Escape, SpaceAge should behave like a calm instrument panel and disarm the latch. This keeps the guard protective without making the user feel stuck.

Architecture choice: UI state only. Confirmed shared-pattern acknowledgement remains the same once the second click happens. Only the temporary CONFIRM ACK state is reset by natural context changes.

Future extensions: Other dangerous-but-reversible UI latches, such as future hardware-send queues or destructive batch edits, should share the same pattern: arm, show the armed state, confirm, and disarm naturally on Escape or context change.

2026-07-06 - SysEx Batch Capture Must Be Labeled As A Dry Run Until It Is Real

Task: Tighten SysEx Vault copy so the multi-dump batch feature is labeled as a dry-run plan rather than live multi-dump batch capture.

What connects creatively: SysEx workflows need old-school studio caution. A musician may be backing up a synth they have owned for 30 years; the app should never imply that a future batch workflow is already doing multi-dump capture. Calling it COPY BATCH DRY RUN makes the current value clear: it is a planning and support-report surface, not a hardware action.

Architecture choice: Copy/status/tooltip wording only. The SysEx Vault still supports live one-dump capture, reviewed Vault saving, manual verification receipts, and copied batch planning. No MIDI send, restore queue, or project mutation behavior changed.

Future extensions: When real live multi-dump capture exists, preserve the same receipt-first design: each dump gets reviewed, named, and saved into the Vault explicitly instead of being silently swept into the project.

2026-07-06 - SysEx Capture Saves Need A Receipt In The User's Eye Line

Task: After saving a live SysEx capture into the Vault, show a saved-capture receipt state in the panel and include the save receipt in COPY CAPTURE.

What connects creatively: Hardware backup workflows should feel like a paper trail, not a magic trick. If a user captures a dump, saves it, and then wonders whether anything was sent back to hardware, the UI should answer immediately: project Vault data changed, no MIDI was sent, no restore was queued, and no hardware was changed.

Architecture choice: Panel state and copied support text only. The live capture engine, Vault save call, restore queue, and hardware send behavior are unchanged. The receipt clears when a new capture starts or the stored capture changes.

Future extensions: A future full librarian could keep persistent Vault save receipts per snapshot, including source device, checksum, capture time, and later verification results.

2026-07-06 - MIDI Setup Safety Must Be Visible Before The Clipboard

Task: Put the MIDI Setup button-temperature legend into the visible setup guide, not only the copied session report.

What connects creatively: The Hardware Setup guide is a trust surface. If a musician is connecting a QY-70, MiniNova, wind controller, or MIDI guitar rig, the UI should say plainly which buttons only copy text, which buttons only navigate, which buttons can mutate the SpaceAge project, and which button can actually send a note to hardware. This is the same safety language we are building into SysEx Vault, MIDI Health, and Hardware Passport.

Architecture choice: Copy-only UI wording. The panel text now summarizes cold text actions, safe-door navigation, warm project mutation, hot test-note sends, and undo behavior. It does not change routing, draft application, test-note queueing, SysEx, or recall behavior.

Future extensions: Button temperature could become a consistent visual marker in every hardware-sensitive popup: cold copy/read buttons, blue safe doors, orange project mutations, and distinct hot hardware sends.

2026-07-06 - A Queued Test Note Is Not The Same As Heard Audio

Task: Add the external-hardware trust boundary to the MIDI Setup TEST NOTE confirmation dialog.

What connects creatively: A test note is the "hello world" of MIDI hardware. It should feel friendly and confident, but not overclaim. SpaceAge can confirm that it queued a note-on/off pair; the actual audible result still depends on the cable, hardware receive channel, patch volume, audio monitoring, and device state. Naming that boundary keeps support conversations honest and helps the user debug the next physical thing.

Architecture choice: Confirmation copy only. The test-note plan, queue, receipt, routing, and hardware send behavior are unchanged.

Future extensions: If we add loopback tests, device ACK/NAK parsing, or audio input listening, the receipt can graduate from "queued" to richer verification states such as "queued," "loopback seen," "device ACK seen," or "audio detected."

2026-07-06 - Template Apply Plans Need A No-Hidden-Send Contract

Task: Add an explicit apply-boundary line to MIDI Hardware Setup device-template apply plans and tighten the matching apply confirmation wording.

What connects creatively: Hardware setup has two different kinds of action that look similar to a nontechnical musician: changing SpaceAge project setup, and sending instructions to a physical machine. The apply plan now says plainly that it is project setup only. That reinforces the same mental model as the button-temperature legend: applying a draft is warm project mutation, not a hot hardware send.

Architecture choice: Report and confirmation text only. The apply plan already has containsHardwareSends = false and blocked hardware-send rows; this adds one human-readable contract line to the plain-text report and makes the confirmation name reset/channel-mode messages too. No project mutation, MIDI queueing, routing, recall, SysEx, or test-note behavior changed.

Future extensions: Every future wizard plan that can mutate a project should include the same boundary line: what SpaceAge will change, what external hardware it will not change, and which separate confirmed action would be required to affect hardware.

2026-07-06 - Hardware Recall Must Say Send Without Claiming Acceptance

Task: Tighten Hardware Passport recall confirmation and copied plan wording so queueing is understood as a hot hardware-send action, while device acceptance remains something the user or future device-specific ACK logic must verify.

What connects creatively: Hardware recall is powerful because it can make an external synth snap back to a known patch, bank, and SysEx state. That same power means the UI must be plain-spoken: this button can send to hardware, SpaceAge can track queue/wire timing, and the actual device state still has to be checked. This protects the musician's trust and keeps support receipts honest.

Architecture choice: Wording-only trust pass. The queue scheduler, SysEx pacing, restore receipts, Hardware Passport data, and manual MARK VERIFIED path are unchanged. The confirmation button now reads as a send action, the success receipt names SpaceAge-side queueing only, and the copied plan repeats the no-device-acceptance boundary.

Future extensions: Device-specific librarians can graduate this from manual trust to stronger evidence when a machine has known ACK/NAK/WAIT/CANCEL replies. Until then, use receipts as evidence of SpaceAge's behavior and manual verification as evidence of the hardware state.

2026-07-06 - Hardware Recall Logs Are Evidence Of SpaceAge, Not The Synth

Task: Add the same hardware-acceptance boundary to Hardware Passport recall logs that already exists in recall plans and queue-progress reports.

What connects creatively: COPY LOG is likely to become the support receipt a musician sends when a MiniNova, QY unit, rack synth, or drum machine fails to recall correctly. The log should be useful evidence, but only of what SpaceAge tried to queue. It should not overclaim that the external device obeyed, changed patch, accepted SysEx, or moved into the expected state.

Architecture choice: Copy/report wording only. Hardware recall scheduling, SysEx pacing, logs, and manual verification receipts are unchanged. The log now says entries prove SpaceAge attempted to queue hardware MIDI, not that hardware accepted it, and the copied log includes a text-only safety line.

Future extensions: When device-specific ACK parsing exists, logs can include per-device evidence levels: queued, sent, generic response seen, device ACK, device NAK, timed out, or manually verified.

2026-07-06 - MIDI PATCH Setup Cards Need Hot-Action Honesty

Task: Tighten MIDI PATCH setup-card queue wording so RPN/NRPN sends are clearly hardware-changing actions, while receipts avoid claiming device acceptance.

What connects creatively: RPN and NRPN cards are powerful little packets of hardware intent: pitch-bend range, tuning, controller setup, or device-specific behavior. They should be easy to preserve and queue, but the user needs to understand when the app is merely reviewing setup data, when it is storing Hardware Passport knowledge, and when it can actually transmit to the external device.

Architecture choice: Wording-only trust pass. The existing RPN queue guard, NRPN queue-safe Hardware Passport requirement, queue path, and Hardware Recall Log integration are unchanged. The tooltip and confirmation dialog now name the hot hardware action, and the queue receipt states that SpaceAge attempted the setup-card queue without proving the device accepted or applied it.

Future extensions: Device-specific Hardware Passports could eventually know which RPN/NRPN cards deserve automatic post-send verification, suggested wait times, or known ACK/NAK parsing. Until then, the correct workflow is explicit queue, receipt, and manual device check.

2026-07-06 - Pitch-Bend Tests Need Musical Trust Boundaries

Task: Make the MIDI PATCH pitch-bend hardware test read as a confirmed hardware send, while avoiding any false claim that SpaceAge can hear or verify the external instrument.

What connects creatively: Pitch-bend testing is half protocol and half musical trust. SpaceAge can send center/up/down/center bend data, but the thing users care about is whether the hardware bends by the expected musical interval. Naming that boundary connects Hardware Passport bend policy, MIDI PATCH testing, future calibration, and real-world hardware onboarding without pretending the app has ears.

Architecture choice: The editor now labels the final confirmation as SEND BEND TEST and warns that the user must check the instrument. The MIDI receipt adds a trust-boundary line: queue evidence is SpaceAge-side proof only, not proof of external bend-range acceptance or musical correctness.

2026-07-06 - Test Notes Are Hardware Sends, Not Audio Proof

Task: Align MIDI Setup's guarded test-note workflow with the hot-action language used by bend tests, setup cards, and Hardware Passport recall.

What connects creatively: A one-note test is simple, but it is also the first moment a user expects SpaceAge to talk to a physical instrument. Clear wording here teaches the whole hardware model: SpaceAge can send a small safe phrase, but silence may still mean the wrong patch, monitoring path, volume, cable, channel, or interface.

Architecture choice: The confirmation button now says SEND TEST NOTE, while the receipt keeps the technical queued evidence. The receipt also carries the trust boundary that queue evidence is not audio proof.

2026-07-06 - Timing Pulse Trains Need The Same Consent Ritual

Task: Put MIDI Timing pulse trains behind an explicit hot-hardware confirmation instead of sending immediately from the panel button.

What connects creatively: Timing pulses are intentionally harmless notes, but they are still a burst of external MIDI. Treating them like test notes and bend tests keeps hardware workflows emotionally consistent: review what will be sent, confirm it, receive a SpaceAge-side queue result, then verify the physical return before trusting calibration.

Architecture choice: The MIDI Timing panel now opens a SEND PULSE TRAIN confirmation dialog that names pulse count, spacing, duration, and the families it will not send. The existing backend pulse scheduler is unchanged; only the consent gate and trust copy changed.

2026-07-06 - Timing Calibration Writes Need Calm Consent

Task: Add explicit confirmations to MIDI Timing calibration writes: APPLY COMP, ACCEPT RETURNED, and CLEAR CAL.

What connects creatively: Timing calibration is not a hot hardware send, but it still changes how future MIDI recording lands on the grid. That makes it a warm project/profile action: less scary than SysEx or a program recall, but important enough that the user should know SpaceAge is about to store or remove calibration data and change the live record-compensation value.

Architecture choice: The three calibration mutation buttons now use confirmation dialogs that say they send no MIDI and do not change external hardware. APPLY COMP stores manual timing and applies record compensation, ACCEPT RETURNED stores loopback timing and applies compensation, and CLEAR CAL removes the saved calibration from the selected Hardware Passport.

Future extensions: The same warm-action pattern should be reused for any future timing offset, groove capture, hardware delay compensation, or auto-latency action that silently changes how incoming performance data is interpreted.

2026-07-06 - Package Repair Is Collaboration Trust, Not MIDI Send

Task: Tighten MIDI stem-package inspection, repair-step, reveal, recheck, and progress wording so package repair feels like a collaborator handoff instead of a mysterious import or hardware action.

What connects creatively: Package repair is not glamorous, but it is one of the places where a collaborator decides whether SpaceAge feels professional. A missing stem, checksum mismatch, or moved file should produce calm instructions: open this folder, repair this item, recheck, then import only when ready. That language connects MIDI export packages, archive repair, external collaboration, and the future "send this project to another SpaceAge user" workflow.

Architecture choice: Copy/safety wording only. COPY REPAIR STEPS, REVEAL PACKAGE, and RECHECK remain non-mutating helper actions. IMPORT STEMS remains the explicit project-changing action and still does not send MIDI, queue SysEx, recall hardware, or change external devices.

Future extensions: A fuller Package Repair Wizard could add file relinking, checksum comparison, stem preview, and "fix selected missing file" actions, but each should keep the same temperature model: text-only, file-browser helper, project mutation, or hardware send.

2026-07-06 - SysEx Vault Needs Button-Temperature Honesty

Task: Tighten SysEx Vault capture, link, detach, cancel, manual-verify, and readiness wording so each button states whether it listens, writes SpaceAge project data, or sends hardware MIDI.

What connects creatively: SysEx is powerful and spooky to normal people. The Vault should feel like a carefully labeled evidence locker: arm a listener, receive one dump, save it only after review, link it to a Hardware Passport only as recall bookkeeping, and send it only through a separate confirmed recall flow. This connects live capture, Hardware Passports, recall receipts, manual verification, and future batch capture without hiding any dangerous magic behind a friendly button.

Architecture choice: Wording and report polish only. ARM CAPTURE remains listen-only, SAVE CAPTURE remains the project-data write, LINK TO PASSPORT / DETACH remain project bookkeeping, MANUAL VERIFY remains user-confirmed evidence, and no SysEx capture action sends hardware MIDI.

Future extensions: Batch capture should inherit this exact temperature model: dry-run plan, armed listener, per-dump receipt, reviewed save, optional passport link, confirmed restore, and device-specific ACK/NAK when available.

2026-07-06 - MIDI AUTO Source View Is A Camera, Not Ownership

Task: Tighten live MIDI AUTO editor wording around SOURCE VIEW, FIT SOURCE, shared-pattern ACK, and VARIANT.

What connects creatively: The user can select one Arrangement clip and focus MIDI AUTO on that clip's source range, which feels wonderfully direct. The trap is that the automation is still PTN-owned. Calling FIT SOURCE a viewport action turns the feature into a camera: useful, precise, but not a new ownership layer. That phrasing connects Arrangement clips, Pattern variants, MIDI AUTO, and the future true clip-local automation model without making today's behavior feel sneaky.

Architecture choice: UI wording only. SOURCE VIEW now says it is viewport-only, FIT SOURCE says edits still write the PTN, shared ACK says MIDI AUTO edits, and VARIANT says it creates an independent pattern before MIDI AUTO editing. Storage, undo, export, playback, clip-local ownership, and hardware routing are unchanged.

Future extensions: When clip-local automation exists, it should be introduced as a separate ownership mode with an explicit conversion path: keep shared PTN automation, create Variant PTN automation, or create clip-local automation.

2026-07-06 - One Workbench Name Beats Two Accurate Names

Task: Change MIDI AUTO project-summary report wording from lower-level expression-language to musician-facing MIDI AUTO language.

What connects creatively: The C++ model can call the data expression lanes because that is technically accurate. But the user should not have to translate "expression events" into "MIDI AUTO stuff" while trying to solve a musical problem. Reports should reinforce the workbench name that appears on the button, the Piano Roll preview lane, and the Arrangement lane badge.

Architecture choice: Report wording only. The data structures, import/export behavior, playback behavior, and MIDI event classification still use the same expression/event model internally.

Future extensions: Keep this split disciplined: technical names in code and diagnostics, product names in user workflows. The same rule will help later with Instrument Bay, Motion Clips, Quasar packages, SysEx Vault, and Hardware Passports.

2026-07-06 - MIDI AUTO Blockers Should Not Gaslight The Code

Task: Recalibrate model-owned MIDI AUTO closeout wording so it credits existing point handles, switch/block handles, guarded edits, and selected-lane scope while keeping the real finish-line gaps visible.

What connects creatively: A progress report is a promise to the team. If it says "handles are missing" after handles exist, it wastes testing energy and makes us chase ghosts. If it says "done" before clip-local ownership, curve/tangent shaping, value badges, and destination bend policy are real, it creates product risk. The sweet spot is a report that tells the truth at the same resolution as the workbench itself.

Architecture choice: Wording/report-model change only. MIDI AUTO data remains PTN-owned. Current switch/block handles, focused point handles, lasso/group edit validation, smoothing/thinning, graph-level value feedback, and source view behavior are unchanged. The blocker now names the remaining launch-grade layer: curve/tangent shaping, switch trim polish, bend-policy controls, and the future clip/lane-local automation path.

2026-07-07 refinement: The ownership part of that blocker needed more precision. The current product already has an honest PTN-owned boundary, Source View says it is viewport-only, VARIANT is the independence route, and ACK SHARED is the deliberate shared-pattern route. The remaining launch blocker is not a vague "ownership choice" popup; graph-level value feedback now exists, while curve/tangent tools, switch-block trim polish, destination bend policy, and a future explicit architecture for true clip/lane-local automation remain.

Future extensions: When each remaining item lands, update the model-owned closeout text immediately. This avoids stale docs and lets the Settings report stay the operational source of truth instead of becoming a haunted checklist.

2026-07-06 - Progress Notes Need Current-Tense Hygiene

Task: Sweep the current MIDI progress report bullets so recent summary language no longer says MIDI EXPR, expression editor, or switch-block edge resizing when the current product surface is MIDI AUTO and visible switch-block handles already exist.

What connects creatively: Documentation is not just memory; it is a steering wheel. If the docs keep old words alive, future work can accidentally resurrect old UX assumptions. This is especially dangerous in SpaceAge because MIDI AUTO is both a real editing surface and a trust boundary around pattern-owned automation.

Architecture choice: Keep historical notes where they clearly document chronology, but make current and summary bullets use the same nouns as the UI: MIDI AUTO, selected-pattern ownership, graph-level value feedback, switch-block trim polish, curve/tangent shaping, and destination-owned bend policy.

Future extensions: When a feature gets renamed, pair the code rename with a docs-surface audit. The faster the vocabulary converges, the less likely we are to design around an old mental model.

2026-07-06 - MIDI Trust Is Often A Sentence, Not A Feature

Task: Improve MIDI Learn and SysEx batch-capture confidence without changing routing, sending MIDI, or enabling new mutation paths.

What connects creatively: A musician using hardware is often worried about hidden consequences: "Did I just bind clock?", "Did that SysEx send?", "How many dumps are left?" Tiny, precise labels can remove that fear. The feature may already be safe, but the user has to feel the safety.

Architecture choice: Add report-only SysEx batch state (stageLabel and remaining dump count) and UI-only MIDI Learn wording. SysEx batch capture remains preflight-only. MIDI Learn behavior is unchanged; the interface simply names that SysEx, clock, transport, panic, and reset messages are ignored.

Future extensions: The SysEx stage label can drive a real progress bar later. The MIDI Learn safety sentence should become part of any future hardware setup wizard, so the user learns early that dangerous/control-plane traffic does not become casual knob mapping.

2026-07-06 - MIDI PATCH Needs Button Temperature At The Decision Point

Task: Make MIDI PATCH selected-item decisions label cold, warm, and hot actions directly in the strip.

What connects creatively: SpaceAge is building a hardware cockpit, not just a file parser. A user reviewing Bank Select, Program Change, RPN, NRPN, or reset data needs to know immediately whether the next move is harmless metadata, a project-side Hardware Passport definition, or a confirmed hardware send. The same safety language now connects MIDI PATCH, Hardware Passports, SysEx Vault, MIDI Setup, and future hardware repair flows.

Architecture choice: Wording and color-language only. The strip now says SAFETY instead of the vaguer STATE, and the policy banner explains cold/warm/hot before any row is selected. Bank/program rows become COLD / READY, queue-safe definitions become WARM / DEFINE, confirmed queueable setup cards become HOT / READY, and protected channel-mode/reset rows become COLD / COPY ONLY. Tooltips now repeat the same temperature model. BEND INFO is cold/blue and sends no MIDI; TEST BEND becomes a hot/dark confirmed hardware action only when the Hardware Passport plan is ready. Existing queue guards, Passport requirements, confirmation dialogs, receipts, SoundFont mapping, and no-autosend rules are unchanged.

Future extensions: Use the same temperature model in the eventual Hardware Passport wizard, MIDI 2.0 profile setup, Motion Clip hardware sends, and any device-template system where one panel contains both innocent bookkeeping and actions that can alter external gear.

2026-07-07 - MIDI AUTO Values Should Live Beside The Gesture

Task: Add stronger graph-level value feedback to MIDI AUTO selected-lane editing without changing MIDI storage, playback, export, or pattern ownership.

What connects creatively: Automation editing is a visual hand skill. If the value readout only lives in a status sentence, the user has to look away from the point or switch edge being shaped. Keeping a hovered or selected value badge inside the graph connects MIDI AUTO to the larger SpaceAge language of living time objects: clips show their contents, section markers pulse in place, ADSR curves show their shape, and automation values should answer "what am I touching?" right where the gesture happens.

Architecture choice: This is a pure affordance layer. MIDI AUTO remains PTN-owned, Source View remains a viewport, VARIANT remains the independence path, and no MIDI send/routing/export behavior changes. The graph now has a larger summary badge for hover, single selection, and selected groups so multi-editing shows count, step span, and value range.

Future extensions: Reuse this pattern for Arrangement automation lanes, Motion Clips, synth macro curves, ADSR/slope editing, and hardware CC drawing. Any future curve/tangent editor should expose the same nearby value badge plus musical units when available, such as semitones for pitch bend or ON/OFF for sustain-style switch lanes.

2026-07-07 - Switch Blocks Need To Teach Their Own Handles

Task: Tighten MIDI AUTO switch-lane wording so the selected-lane graph teaches that switch automation is edited as ON/OFF blocks with visible edge handles.

What connects creatively: Sustain pedals, mutes, gates, and future Motion Clips are not best understood as lonely dots; they are spans of time. The closer the UI language gets to "grab this edge and trim the block," the closer MIDI AUTO feels to clips, loop ranges, section markers, and other SpaceAge time objects.

Architecture choice: This is a wording/affordance pass only. Switch lanes remain PTN-owned MIDI events, the existing event handles and grouped edge edits stay intact, and no playback/export/routing behavior changes. The live closeout text now stops treating value feedback as unfinished and keeps the remaining work focused on trim polish, edge validation, curve/tangent tools, bend policy, and future clip/lane-local automation.

Future extensions: The same block vocabulary should carry into Automation Lanes, Motion Clips, clip decorations, and synth-gate editors. When true clip-local automation arrives, switch spans should migrate as spans, not as mysterious point pairs.

2026-07-07 - Pitch Bend Must Never Pretend To Be 7-Bit

Task: Tighten MIDI AUTO pitch-bend insert wording so the compact 0-127 editor control clearly maps to raw 14-bit MIDI bend centered at 8192.

What connects creatively: Pitch bend is where MIDI can quietly lie to a musician. A slider can be compact, but the mental model cannot be fuzzy: the user is drawing a 14-bit bend curve, and any external synth owns the semitone range. Clear wording protects guitar slides, wind-controller bends, hardware playback, and future MPE-like expression from becoming "why is this out of tune?" mysteries.

Architecture choice: Wording/trust pass only. The compact insert slider still uses 0-127 for UI convenience and maps 64 to raw bend center 8192. MIDI AUTO storage, playback, export, Hardware Passport bend policy, and routing behavior are unchanged.

Future extensions: The eventual full bend editor should expose raw 14-bit value, musical semitone range, destination policy, and maybe a "bend lands at +2 / +12" audition phrase in one place. This same clarity should guide MPE zones and per-note bend once that protocol layer arrives.

2026-07-07 - Hardware Bend Range Needs A Destination Contract

Task: Tighten Hardware Passport and MIDI AUTO bend-policy wording so internal synths, SoundFont/internal targets, and external hardware are not described as if they have the same trust boundary.

What connects creatively: A pitch-bend lane is only musically meaningful if the receiving instrument agrees about the semitone range. SpaceAge can know its own internal/RPN range, but a MiniNova, QY, rack synth, or other external destination is a separate contract. Naming that contract in the UI turns a technical protocol detail into a musician-facing safety promise: "declare the destination range, then trust your slides."

Architecture choice: This is wording/trust polish only. Internal targets now say the graph range is sufficient and external TEST BEND is unnecessary. Hardware targets say the Hardware Passport must include an output plus +/- bend range before slides, TEST BEND, or playback should be trusted. No MIDI storage, routing, export, playback, or hardware send behavior changes.

Future extensions: The Hardware Passport wizard should eventually make bend range a first-class setup step, with common presets like +/-2, +/-12, and guitar/wind-controller-friendly ranges. The same destination-contract idea should apply to MPE zones, MIDI 2.0 profiles, hardware articulation maps, and any future per-lane expression templates.

2026-07-07 - MIDI AUTO Curve Work Should Not Hide Existing Ramps

Task: Tighten MIDI AUTO curve closeout wording so existing point drawing, ramp drawing, preview-confirm smoothing, preview-confirm thinning, graph value feedback, and guarded point/group edits are credited before naming the remaining curve work.

What connects creatively: SpaceAge's MIDI automation editor is becoming a living-time object editor, not a raw event table. If the roadmap keeps saying "curve/tangent shaping" without crediting ramps and smoothing, we risk rebuilding the same idea under a new name. The remaining opportunity is more specific and more beautiful: direct curve-shape handles that feel like grabbing a musical contour, not typing a controller list.

Architecture choice: This pass changes language and model truth only. MIDI AUTO remains PTN-owned. Point/ramp drawing, SMOOTH, THIN, switch blocks, and selected/group edits are still the current shipped mechanisms. The release gap is now described as interactive curve-shape/tangent handles beyond point/ramp editing, plus switch-edge trim confidence, destination bend-range contract, and the future clip/lane-local automation path.

Future extensions: The eventual curve editor should reuse the same geometry language as ADSR splines, Motion Clips, clip decorations, and tempo-aware effect automation. A single curve-handle grammar across MIDI AUTO, synth envelopes, mixer automation, and Motion Clips will make SpaceAge feel designed instead of accumulated.

2026-07-07 - Switch Blocks Are Time Objects

Task: Recalibrate MIDI AUTO switch-lane closeout wording so visible switch-edge trimming is credited as present, while the remaining work is described as launch-grade confidence polish, collision messaging, and the future clip/lane-local automation path.

What connects creatively: A sustain pedal, mute, gate, or future clip decoration is closer to a Section marker than to a single MIDI dot. Treating switch data as draggable time blocks helps SpaceAge reuse the same mental model across loop ranges, section spans, automation lanes, Motion Clips, and clip-level performance gestures.

Architecture choice: This is a model-truth pass only. The existing switch handles, grouped edge edits, copy/cut/paste language, playback, export, and PTN-owned storage are unchanged. The UI hint now explicitly says left/right trims timing and up/down toggles state, which should reduce user doubt without pretending the editor has a new storage model.

Future extensions: The confidence layer should eventually include overlap/collision feedback, clearer state-preview colors, and a migration path for clip-local automation. If we do this once as a general time-span grammar, it can serve switch lanes, Motion Clips, gate patterns, ducking envelopes, and future hardware control maps.

2026-07-07 - Bend Range Is A Contract, Not A Decoration

Task: Align the live MIDI Protocol Coverage strings with the newer MIDI AUTO closeout language so the app distinguishes existing switch-edge editing from the still-needed destination bend-range contract.

What connects creatively: Slides are musical promises. If SpaceAge draws a bend curve but the destination synth thinks the range is +/-2 while the lane expects +/-12, the composer hears betrayal, not MIDI nuance. Treating bend range as a visible contract connects MIDI AUTO, Hardware Passports, pitch-bend tests, guitar/wind-controller workflows, and future MPE support into one trust model.

Architecture choice: This remains wording/model-truth polish only. No bend storage, playback, export, hardware routing, or RPN send behavior changes. The live Settings report now says the remaining bend work is a visible destination bend-range contract, while switch-edge trimming is credited as already present.

Future extensions: The same contract model should govern MPE zone setup, MIDI 2.0 profile negotiation, hardware articulation maps, and any future "test this external device" wizard. The UI should keep asking: "What does the destination believe this gesture means?"

2026-07-07 - SysEx Batch Evidence Should Accumulate

Task: Make the SysEx batch dry-run count valid Vault snapshots already linked to the selected Hardware Passport, in addition to the current unsaved one-dump live capture.

What connects creatively: Hardware backups are rarely glamorous, but they are trust objects. If a user captures a MiniNova or QY dump set over several minutes, SpaceAge should acknowledge the evidence already in the Vault instead of acting like only the last unsaved capture exists. This makes the Vault feel like a real librarian instead of a temporary clipboard.

Architecture choice: This remains dry-run/planning behavior only. Stored evidence is counted from valid SysEx snapshots linked to the selected Hardware Passport. A current unsaved live capture adds one more temporary evidence item. No live multi-dump inbox, auto-save, restore, SysEx send, or hardware mutation is introduced.

Future extensions: The eventual live multi-dump workflow can reuse this evidence model: expected count, stored count, live count, duplicate warnings, per-dump receipts, and explicit review before Vault save. This should also connect to package repair, restore-history filtering, and device-specific ACK/NAK evidence.

2026-07-07 - Accounted For Is More Honest Than Captured

Task: Make SysEx batch dry-run reports distinguish stored Vault snapshots from the current live unsaved capture instead of collapsing both into a vague "captured" number.

What connects creatively: The word "captured" sounds like the app actively gathered a batch in one operation. "Accounted for" is calmer and truer: some dumps may already be stored in the Vault, while one dump may be waiting unsaved in live capture. This distinction helps SpaceAge feel trustworthy around dangerous hardware memory data.

Architecture choice: The SysExBatchCapturePlan now carries storedEvidenceDumpCount and liveEvidenceDumpCount alongside the total accounted count. Copied reports and JSON metadata can expose the same split. This does not enable live batch capture, hidden auto-save, restore sends, or any hardware mutation.

Future extensions: When active multi-dump capture arrives, the same fields can grow into a receipt ledger: stored, live pending, duplicate, rejected, timed out, verified by hardware ACK/NAK, and manually verified by the user.

2026-07-07 - Switch Edges Need Human-Sized Handles

Task: Improve MIDI AUTO switch-edge confidence by making switch handles easier to hit, easier to lasso, and clearer in their selection/drag instructions.

What connects creatively: Switch data is binary, but editing it is spatial. A sustain pedal edge, mute edge, gate edge, section boundary, loop boundary, and future Motion Clip edge all ask the same question: "Where does this state begin or end?" Larger switch-edge targets let SpaceAge teach that shared grammar through touch instead of documentation.

Architecture choice: This pass only changes editor affordance. Switch events remain PTN-owned MIDI AUTO events, storage stays identical, playback/export stay identical, and hardware routing is untouched. The hit/lasso areas are larger for switch lanes than continuous controller lanes because the visual object is a time edge, not a tiny value point.

Future extensions: The same handle policy should eventually be reused for Section markers, clip trim edges, Arranger loop bounds, Motion Clip spans, and sample loop-on-release points. One consistent "edge handle" language would make the whole app feel more coherent.

2026-07-07 - Curve Shaping Before Tangent Handles

Task: Add a first-pass MIDI AUTO curve-shape transform so users can choose Smooth, Fast Start, or Slow Start before true draggable tangent handles exist.

What connects creatively: A curve is a gesture. It is the same musical idea whether it lives in MIDI AUTO, an ADSR slope, an LFO depth ramp, a delay feedback swell, or a future Motion Clip. Giving SpaceAge a shared "shape this contour" primitive now keeps us from inventing five incompatible curve systems later.

Architecture choice: The new transforms are preview-confirm operations, just like Smooth and Thin. They anchor the first and last matching events, reshape only the intermediate values, and keep the data PTN-owned. This moves the user experience closer to musical curve shaping without pretending we have full draggable tangent handles yet.

UI note: The first-pass UI intentionally uses one Curve Shape dropdown plus one APPLY CURVE button instead of adding separate Fast/Slow buttons. That keeps MIDI AUTO from becoming another dense button row while still exposing the new musical contour choices.

Future extensions: The eventual tangent-handle GUI can reuse this math as a backend preset: fast start, slow start, linear, S-curve, and custom handles. The same vocabulary should later appear in automation lanes, synth envelopes, Motion Clips, sample fades, and tempo-aware effect controls.

2026-07-07 - SysEx Evidence Needs One Voice

Task: Centralize SysEx batch dry-run evidence wording so the visible Vault strip, copied dry-run report, and structured payload all describe stored Vault snapshots and the current live unsaved capture the same way.

What connects creatively: Hardware backup workflows are trust rituals. If one surface says "captured," another says "stored," and a third says "remaining," the musician has to translate the app instead of trusting it. One evidence phrase connects the SysEx Vault, Hardware Passports, copied support reports, and future batch-capture progress meter into a single calm story.

Architecture choice: Add a model-owned evidenceSummaryLabel to SysExBatchCapturePlan and consume it from the UI/report layer. This is still dry-run/planning behavior only. No live multi-dump inbox, hidden auto-save, restore queue, SysEx send, or hardware mutation is introduced.

Future extensions: When real multi-dump capture lands, the same evidence label should grow into a receipt ledger: stored, live pending, duplicate, rejected, timed out, manually verified, hardware ACK, and hardware NAK.

2026-07-07 - SysEx Duplicate Evidence Should Be A Review Prompt

Task: Warn when linked SysEx Vault snapshots look like possible duplicate batch evidence.

What connects creatively: A hardware librarian is only useful if it helps users trust what is actually stored. A duplicate dump might be harmless, or it might mean the user sent the same hardware page twice and missed another one. Calling it "possible duplicate evidence" connects SysEx Vault, batch dry-runs, support reports, and future live batch capture without making the app overconfident.

Architecture choice: Use a conservative stored-snapshot heuristic: same Hardware Passport, valid SysEx, same byte count, and same hex preview. The warning is visible and copied, but it does not block capture, delete anything, send MIDI, auto-save a dump, or mutate hardware.

Future extensions: True batch capture should replace this heuristic with full dump hashes, source timestamps, device page labels, and one receipt per expected dump. For now, the prompt is useful precisely because it is humble.

2026-07-07 - SysEx Identity Belongs In The Eyeline

Task: Surface selected SysEx snapshot manufacturer/device/checksum evidence directly in the Vault closeout card and copied selected-snapshot report.

What connects creatively: A hardware restore can fail for quiet, boring reasons: wrong device id, mismatched manufacturer family, stale checksum, or a dump linked to the wrong Hardware Passport. Putting identity/checksum evidence beside restore receipts turns the Vault from a storage shelf into a cautious hardware assistant.

Architecture choice: Reuse existing descriptor data. The pass only changes visible/copy text for the selected snapshot closeout. It does not send SysEx, queue restore, mutate Hardware Passports, alter checksum algorithms, or claim device acceptance.

Future extensions: Device-specific librarian scripts should promote this line into richer per-device guidance: Yamaha XG model ids, Novation template ids, Roland address ranges/checksum rules, Korg dump classes, and user-labeled hardware memory pages.

2026-07-07 - MIDI Learn Decisions Need Resolution Context

Task: Add high-resolution CC context to the pending MIDI Learn review text before the user chooses REPLACE, MACRO, or CANCEL.

What connects creatively: A hardware knob is not always just a simple 0-127 knob. Some controllers send a coarse CC plus a fine companion, and that distinction can change how smooth a learned control feels. Putting that fact in the decision strip connects MIDI Maps, direct-control Learn, soft takeover, 14-bit resolution modes, and future hardware setup templates into one calmer explanation.

Architecture choice: Reuse the existing highResolutionControllerNote() model text in the pending capture preview. No mapping behavior changes, no source filters change, no hardware MIDI is sent, and macro/replace semantics stay exactly as they were. This is a trust-label pass.

Future extensions: The next MIDI Maps polish pass should make 7-bit/AUTO/14-bit mode previews equally visible in direct Learn receipts, hardware setup reports, and any future controller-template wizard so the user understands resolution before recording automation.

2026-07-07 - Source Filters Should Explain Their Guardrails

Task: Make the MIDI Maps Learn strip explain that one capture source always remains enabled and that unsafe/control-plane messages are ignored.

What connects creatively: MIDI Learn is a listening state. If the user turns source toggles off and the app silently restores CC, that is technically safe but emotionally odd. Explaining the guardrail connects the source-filter buttons, direct-control Learn defaults, Hardware Passport setup, and future controller templates into one honest rule: SpaceAge will not arm a listener that listens to nothing, and it will not casually learn dangerous traffic.

Architecture choice: UI wording only. The existing normalization behavior remains unchanged: if all Learn source toggles are off, CC is restored. SysEx, clock, transport, panic, and reset remain ignored for MIDI Learn. No routing, mapping, recording, or hardware-send behavior changes.

Future extensions: Put the same guardrail sentence in the future hardware setup wizard and any first-run controller onboarding, especially for devices that emit mixed CC, pressure, pitch bend, clock, or transport traffic during one physical gesture.

2026-07-07 - Macro Cleanup Should Read Like Intention

Task: Rename the MIDI Maps row-level macro cleanup action from KEEP to ONLY and make its explanation more explicit.

What connects creatively: A macro source is creative when intentional and confusing when accidental. The UI needs to distinguish those two emotional states quickly. ONLY reads like a deliberate correction: "this knob should control only this target." That connects MIDI Learn conflict review, direct-control replacement, macro mappings, and future hardware templates into one plain action language.

Architecture choice: Wording only. The existing cleanup primitive still removes other mappings driven by the same hardware source while preserving the selected row. No mapping model, routing, Learn capture, or hardware behavior changed.

Future extensions: A future MIDI Maps conflict browser could show an explicit source tree: one hardware gesture at the top, all targets beneath it, with actions for Macro, Only this, Disable, and Delete. The current ONLY wording leaves room for that richer surface.

2026-07-07 - Trust Gates Need The Why Sentence

Task: Carry MIDI Input Trust Gate live-routing detail into copied and structured reports.

What connects creatively: A trust gate should feel like a calm engineer standing beside the user, not a traffic light with no explanation. The headline says whether live MIDI can reach the armed lane; the detail sentence says why. That connects MIDI Health, MIDI Setup, Hardware Passports, source-policy choices, duplicate-route warnings, and future controller onboarding into one confidence-building diagnostic language.

Architecture choice: Add a routingDetailLabel to the model and seed it from the existing MIDI input readiness verdict detail. This is report/diagnostic plumbing only. No MIDI routing, recording, playback, Learn capture, SysEx behavior, or hardware send behavior changes.

Future extensions: The visible Health panel can eventually promote this detail into a short action card with a one-click jump to the relevant setup surface, while copied support reports retain the same exact model-owned text.

2026-07-07 - Dropped MIDI Is A Performance Emergency

Task: Promote dropped direct physical MIDI input messages into the MIDI repair recommendation list.

What connects creatively: A missed MIDI note during live recording feels like betrayal, not trivia. If SpaceAge already counted dropped direct-input messages, the app should turn that into an actionable repair card. This connects MIDI Health, MIDI Input, direct-vs-host source policy, controller troubleshooting, and future hardware onboarding around one promise: if performance data is being lost, the user sees it plainly.

Architecture choice: Add a high-severity repair recommendation when the direct input runtime reports dropped messages. The action navigates to MIDI Input setup and suggests reducing direct-input load, closing duplicate routes, or using host-routed MIDI if the physical driver/interface is unstable. No routing, recording, queue size, playback, SysEx, or hardware-send behavior changes.

Future extensions: A future performance-health meter could graph dropped MIDI over time and correlate it with duplicate routing, audio block size, controller flood events, and specific devices from the Hardware Passport inventory.

2026-07-07 - External MIDI Drops Break Playback Trust

Task: Reword external MIDI runtime dropped-message repair guidance so it covers playback trust, not only recording.

What connects creatively: Hardware output is part of the song when a user is driving external synths. If SpaceAge drops outgoing MIDI, the issue is not merely "will recording be okay?" It is "can I trust what I am hearing?" That connects MIDI OUT runtime, Hardware Passport routes, hardware print passes, external synth playback, and future export/print workflows into one honest warning.

Architecture choice: Wording only. The existing dropped-output repair card still opens MIDI Health and remains high severity. No queue sizes, output scheduling, transport, playback, export, or hardware-send behavior changed.

Future extensions: The future hardware print/export flow should refuse to call a pass clean when external MIDI drops occurred during the print window, and should offer a retry receipt with device/runtime evidence.

2026-07-07 - Repair Clicks Need Receipts

Task: Make lane-targeted MIDI repair clicks confirm the intended action as well as the lane/device target.

What connects creatively: Navigation-only safety is good, but navigation without a receipt can feel like nothing happened. Echoing the action label after a repair click connects the visible repair card, the status bar, and the opened lane-routing surface into one understandable sequence: "I clicked this repair, SpaceAge opened this safe-door, and no MIDI was sent."

Architecture choice: UI/status wording only. Lane-targeted repair clicks still navigate to the Arrangement lane routing panel and do not arm lanes, change routing, send MIDI, recall hardware, or mutate project data.

Future extensions: The same receipt pattern should apply to Hardware Passport, SysEx Vault, Timing, MIDI PATCH, and future controller-template safe doors so all diagnostic buttons share one no-surprise interaction language.

2026-07-07 - Protocol Next Needs Its Reason

Task: Make the MIDI Protocol Coverage OPEN NEXT button explain which closeout category it is opening and why that category is currently first.

What connects creatively: A closeout dashboard is only useful if it lowers doubt. A generic "open next" button can feel like a mystery door; naming the blocker category and its recommended focus turns it into a guided checklist. That connects MIDI Health, MIDI AUTO, SysEx Vault, Import/Export, Hardware Setup, and the future onboarding manual into one release-readiness language.

Architecture choice: Tooltip/status copy only. The Protocol panel still computes the next category from the model-owned blocker ranking and still performs navigation only. No MIDI is sent, no routing changes, no project data changes, and no closeout priority logic changes.

Follow-through: The compact COPY CLOSEOUT text now includes the same next-focus sentence so the clipboard version teaches the release-readiness priority before listing the checklist.

Future extensions: The same next-focus sentence can later become a tiny release-readiness breadcrumb in Settings, so the user can see not only what is unfinished but why SpaceAge thinks that item is next.

2026-07-07 - Health Fix Next Should Match Protocol Next

Task: Give MIDI Health FIX NEXT the same category/recommended-focus tooltip as the MIDI Protocol OPEN NEXT button.

What connects creatively: MIDI Health is the cockpit view; MIDI Protocol Coverage is the inspection report. If both point to the same next release blocker, they should use the same language. This keeps the user from learning two mental models for one closeout system and reinforces that repair/navigation buttons are safe doors unless explicitly labeled hot.

Architecture choice: Tooltip wording only. The Health panel still asks the protocol model for the first blocker category, still opens the model-owned action surface, and still sends no MIDI or routing changes from FIX NEXT.

Future extensions: Once the manual/onboarding pages exist, the same category/focus text can become a clickable "why this matters" explanation for each MIDI closeout family.

2026-07-07 - Optional Diagnostics Must Reserve Space

Task: Make MIDI Health layout reserve an extra row when the optional MIDI IN WHY diagnostic line is visible.

What connects creatively: A diagnostic panel should never punish itself for being more helpful. If a trust gate learns to say why, the layout engine has to know that sentence exists. This connects future expandable diagnostic details, repair-card alignment, Settings panel readability, and the broader rule that optional explanations need matching geometry.

Architecture choice: UI layout math only. The Health panel already drew the optional line; resized() now counts it before placing repair buttons. No MIDI health model, routing, repair recommendation, input policy, or hardware behavior changed.

Future extensions: Any future optional MIDI Health rows should be counted through a shared helper rather than a fixed literal so the paint and layout paths cannot drift again.

2026-07-07 - Cold Buttons Should Say They Are Cold

Task: Make MIDI Health COPY REPORT and COPY STEPS explicitly state their text-only/no-MIDI/no-routing/no-project-data boundary.

What connects creatively: A musician should not have to wonder whether copying a MIDI health report could poke hardware. Cold actions should announce their coldness. This connects the MIDI Health panel, SysEx Vault reports, Hardware Passport logs, import/export repair steps, and future support workflows into a consistent temperature language.

Architecture choice: Tooltip wording only. Clipboard actions still copy text and do not send MIDI, queue SysEx, alter routing, arm tracks, or mutate project state.

Future extensions: We should eventually make this button-temperature language visible in a small glossary/help panel so users learn that cold, safe-door, warm, hot, and undo actions have predictable meanings across the app.

2026-07-07 - MIDI Setup Is A Guided Contract

Task: Align MIDI Setup guide tooltips and visible safety text with the same action-temperature language used in MIDI Health.

What connects creatively: Hardware setup is where a user is most likely to feel nervous. Clear language about which buttons merely copy, which buttons navigate, which buttons change SpaceAge routing data, and which buttons can send one confirmed note turns the guide into a contract. This connects MIDI Setup, Hardware Passports, MIDI OUT, Timing, SysEx Vault, and future hardware onboarding into one predictable workflow.

Architecture choice: Copy/tooltips only. APPLY DRAFT is now described more accurately as a SpaceAge project-data/routing mutation after confirmation; copy and safe-door actions explicitly remain no-MIDI/no-routing/no-project-change actions. No routing, hardware send, confirmation, undo, or template behavior changed.

Follow-through: The copied setup-session report now uses the same no-routing/project-data language, so support receipts and visible tooltips cannot drift apart.

Future extensions: A future first-run hardware wizard can reuse these exact action-temperature definitions so users learn them once and then recognize them everywhere.

2026-07-07 - MIDI Output Reports Need A Cold Receipt

Task: Add explicit cold/no-mutation language to MIDI Output Preflight copy/check actions and copied reports.

What connects creatively: MIDI OUT is the bridge from SpaceAge into physical reality. A copied output report should never leave the user wondering whether it transmitted anything to hardware. This connects MIDI Output Preflight, Hardware Passports, MIDI Setup, repair recommendations, and future tech-support workflows into one calm rule: reports observe and explain; confirmed hot actions send.

Architecture choice: Tooltip and report-copy wording only. COPY REPORT copies text, CHECK OUTPUT refreshes readiness/runtime/device inventory, and neither action sends MIDI, changes routing, or mutates project data.

Future extensions: When hardware print/export arrives, output preflight reports can be attached to render receipts so collaborators know whether external MIDI playback was clean or compromised by dropped output/runtime warnings.

2026-07-07 - Repair Recommendations Are Safe-Door Guidance

Task: Add a reusable safety preface to copied MIDI repair recommendation reports.

What connects creatively: Repair lists are meant to guide the next click, not secretly perform repairs. Naming them as safe-door guidance keeps MIDI Input, MIDI Output, MIDI Health, package repair, and future hardware troubleshooting aligned around one promise: SpaceAge can suggest, but hardware-changing or project-mutating actions require the user to step through a clearly labeled door.

Architecture choice: Shared report wording only. Repair recommendation data and action callbacks are unchanged. Copying the recommendation report still sends no MIDI, changes no routing, and changes no project data.

Future extensions: The repair-card model could eventually expose an explicit action-temperature enum instead of relying on copy conventions, letting every repair row render cold/safe-door/warm/hot badges automatically.

2026-07-07 - SysEx Vault Needs Receipts Before Fear

Task: Tighten SysEx Vault tooltip and copied-report language so metadata, remove, save-capture, and copy actions clearly state their no-hidden-send boundaries.

What connects creatively: SysEx feels dangerous because it can overwrite real hardware state. The Vault should therefore over-communicate when it is only organizing data. This connects SysEx capture, metadata editing, Hardware Passport linking, recall planning, manual verification, and future batch librarian workflows into one trust posture: storing and reporting are cold/warm project actions; restore remains a separately confirmed hot path.

Architecture choice: Copy/tooltips only. Metadata save, remove, capture save, and copy report behavior is unchanged. The copied Vault report now starts with a receipt saying no SysEx was sent, no recall was queued, no routing changed, no project data changed by the copy, and no external hardware changed.

Future extensions: When multi-dump batch capture lands, every per-dump receipt should inherit this pattern: captured/listened, reviewed, saved, linked, and restored are distinct states with distinct safety temperatures.

2026-07-07 - MIDI AUTO Edits Need Project-Data Honesty

Task: Make MIDI AUTO tooltips clearly distinguish cold inspection/report actions from warm PTN automation edits.

What connects creatively: MIDI AUTO is powerful because it lets a musician draw expressive time behavior, but that also makes it easy to wonder whether a button will merely change a graph, alter linked clips, or poke external hardware. Naming the boundary directly connects MIDI AUTO, shared-pattern Variant logic, MIDI PATCH setup protection, Hardware Passports, and future clip/lane-local automation into one readable contract: expression edits change PTN automation data unless the user first makes a Variant; they do not send MIDI by themselves.

Architecture choice: Tooltip/copy only. No MIDI AUTO storage, playback, export, routing, graph editing, shared-pattern guard, or hardware-send behavior changed. The pass labels edit buttons as PTN automation-data mutations and labels copy/open/view actions as cold or navigation-only actions.

Future extensions: The eventual clip/lane-local automation system should reuse this same temperature model: viewport actions, report/copy actions, PTN edits, clip-local edits, lane-local edits, and confirmed external hardware sends should all have distinct language and, eventually, badges.

2026-07-07 - MIDI PATCH Needs A Stricter Temperature Dictionary

Task: Correct MIDI PATCH wording so cold, warm, and hot actions are not blended together.

What connects creatively: MIDI PATCH sits at the edge of the app and the outside world. A user may be reviewing imported setup data, saving a Hardware Passport recipe, mapping a SoundFont preset, defining an NRPN, or queueing a real hardware setup message. Those are not the same emotional act. A stricter temperature dictionary connects MIDI PATCH, Hardware Passports, SoundFont mapping, SysEx Vault, and MIDI Setup into one trust model: cold means copied/reviewed text only, warm means SpaceAge metadata changed, and hot means confirmed hardware MIDI may leave the app.

Architecture choice: Tooltip/status/report-copy wording only. Existing save, attach, map, define, queue, and bend-test behavior is unchanged. Clipboard copies now get a local safety receipt before the row/card report, warm actions describe the project/passport/lane metadata they alter, and hot queue statuses remind the user that SpaceAge can prove it queued messages but cannot prove external device acceptance without hardware evidence.

Future extensions: The temperature taxonomy should become model-owned instead of hand-written in each panel. Buttons could render small cold/warm/hot badges automatically, and copied receipts could be generated by one helper shared by MIDI Health, MIDI PATCH, Hardware Passport, SysEx Vault, Import/Export, and future hardware print workflows.

2026-07-07 - MIDI Learn Is A Listening Contract

Task: Tighten MIDI Learn and MIDI Maps wording so listening, committing mappings, cleaning up macro conflicts, deleting mappings, and copying reports have clear cold/warm/no-send boundaries.

What connects creatively: MIDI Learn is one of the places where hardware feels alive, which also makes it emotionally risky. A user moves a real knob and expects SpaceAge to learn, not secretly transmit, reroute, or disturb a synth. Treating Learn as a listening contract connects context-menu learning, the MIDI Maps panel, future hardware onboarding, automation assignment, and support receipts into one promise: capture listens, commit changes SpaceAge mappings, and neither action sends MIDI by itself.

Architecture choice: Tooltip/status/copy wording only. No MIDI Learn capture, mapping storage, macro behavior, duplicate cleanup, source filtering, routing, or hardware-send behavior changed. Replace Same Hardware Source, MACRO, ONLY, DEL, and the dashboard copy now explain their safety temperature in the user-facing layer.

Future extensions: The next step is to make action temperatures model-owned so Learn buttons can render small cold/warm/hot badges automatically. That would keep MIDI Learn, MIDI AUTO, MIDI PATCH, SysEx Vault, Hardware Passports, and future VST/hardware mapping from drifting into handmade wording again.

2026-07-07 - MIDI Reports Should Carry Their Own Safety Receipts

Task: Extend cold/warm/no-send language into MIDI import, input preflight, sync preflight, and MIDI Maps row-edit controls.

What connects creatively: A copied report is often what a user will paste into support, send to a collaborator, or re-read after something confusing happened. If the report itself says it was text-only, it becomes a receipt instead of just a document. This connects MIDI import, MIDI input, MIDI sync, protocol coverage, MIDI Learn, and future hardware troubleshooters into one calm pattern: reports observe; warm buttons mutate SpaceAge data; hot buttons require confirmation before hardware hears anything.

Architecture choice: Tooltip/copy/status wording only. Import preview reports, input readiness reports, and sync preflight reports now prepend safety receipts. MIDI Maps row controls explain that enable, invert, pickup, resolution, range, and curve edits change SpaceAge mapping behavior only. No MIDI import model, MIDI input monitor, sync monitor, mapping storage, routing, hardware send, or playback behavior changed.

Future extensions: We should extract a shared copySafetyReceipt() helper and an action-temperature enum. That would let every report button prepend the correct safety language automatically and would reduce the risk of new MIDI panels drifting back into one-off wording.

2026-07-07 - Late MIDI Surfaces Need The Same Temperature Discipline

Task: Continue action-temperature cleanup through MIDI Output, Hardware Passports, SysEx Vault, and MIDI AUTO.

What connects creatively: The later MIDI panels are the scary ones: output, recall, SysEx, and automation edits that can affect many clips. If the final mile uses the same cold/warm/hot language as the early setup surfaces, SpaceAge starts to feel like it has one safety personality instead of many disconnected rooms. This connects Hardware Passport recall, SysEx librarian work, MIDI AUTO editing, sync policy, and future hardware workflows into one mental model: reports are cold, SpaceAge-data edits are warm, and real external sends are hot and confirmed.

Architecture choice: Tooltip/status/copy wording only. MIDI Output preflight, Hardware Passport recall plan/log/queue reports, SysEx batch dry-run, MIDI AUTO reports, SysEx Vault metadata actions, sync policy saves, and MIDI AUTO edit controls now describe their temperature more explicitly. No MIDI output routing, recall queueing, SysEx restore, automation storage, sync policy model, playback, export, or hardware-send behavior changed.

Future extensions: The temperature model is now repeated enough that it wants to become a real UI primitive. A small action-temperature helper could generate button badges, tooltips, copied-report receipts, and even confirmation-dialog prefaces from one source of truth.

2026-07-07 - Export And Setup Receipts Complete The Trust Loop

Task: Extend action-temperature wording and copied-report safety receipts into MIDI export/package, MIDI Health, and MIDI Setup surfaces.

What connects creatively: Export/import and hardware setup are moments where musicians pause because files, projects, and external devices feel at stake. If the copy/export/setup controls explain exactly what changes and what does not, SpaceAge can feel brave without feeling reckless. This connects MIDI stem package exchange, Health support reports, Setup onboarding, Hardware Passports, and future collaborator workflows into one trust loop: cold copies document, warm file writes create artifacts, warm project edits mutate SpaceAge data, and hot actions are still reserved for confirmed hardware sends.

Architecture choice: Tooltip/copy/report wording only. MIDI export still writes files only after the user chooses a destination, package import still adds lanes/clips only after confirmation, and copy actions now prepend safety receipts without changing import/export/setup behavior.

Future extensions: A shared action-temperature model should eventually generate these receipts automatically for export, import, setup, SysEx, MIDI AUTO, Hardware Passport recall, and future VST/hardware workflows. That would keep safety language consistent while reducing copy-paste maintenance.

2026-07-07 - Cold Actions Should Always Name The Hardware Boundary

Task: Standardize remaining cold/navigation MIDI tooltips so they explicitly say they do not change external hardware when they already promise no MIDI, no routing changes, and no project-data changes.

What connects creatively: Users do not mentally separate "no MIDI sent" from "my hardware is safe" as cleanly as engineers do. Naming the external-hardware boundary directly makes SpaceAge feel more trustworthy in MIDI Input, MIDI Output, Sync, Timing, MIDI Learn, MIDI AUTO, MIDI PATCH, and Protocol Coverage. The creative connection is simple: safety language becomes part of the product's voice, not just a legalistic footnote.

Architecture choice: Copy/tooltips only. No MIDI routing, monitoring, automation, setup-card, output refresh, protocol coverage, or hardware behavior changed.

Future extensions: This should become an action-temperature helper with generated tooltip clauses. Cold actions should receive the same standard footer everywhere: no MIDI sent, no routing changed, no project data changed, no external hardware changed.

2026-07-07 - MIDI Receipts Want A Shared Voice

Task: Introduce a small shared MIDI copy-receipt helper and move the safest repeated report-copy paths through it.

What connects creatively: SpaceAge is getting enough MIDI surfaces that duplicated safety text is now a product risk, not just code mess. If each panel hand-writes its own receipt, one future edit can accidentally sound less safe or less clear than the others. A shared receipt voice connects import, export, health, timing, setup, learn, sync, MIDI AUTO, and protocol coverage into one ritual: when the user copies a report, SpaceAge says exactly what happened and what did not happen.

Architecture choice: Add one local helper in PluginEditor.cpp that wraps a title, safety sentence, and report body. This intentionally avoids a larger enum/refactor today. Domain-specific receipt wording still stays explicit at each call site, while the repeated header/body assembly moves into one function.

Future extensions: The helper can grow into an action-temperature service later: cold copy receipt, safe-door navigation, warm project edit, warm file write, and hot confirmed hardware send. That would let buttons, confirmation dialogs, copied reports, and eventual badges all derive from one model-owned source of truth.

2026-07-07 - Cold Copy Tooltips Should Not Be Handmade Forever

Task: Add a shared MIDI cold-copy tooltip helper and use it on straightforward report/copy buttons.

What connects creatively: The user experience of safety begins before a click. If every copy tooltip uses the same clause structure, the user learns a rhythm: copied reports are informational, they do not transmit, reroute, mutate project data, or change external hardware. This connects MIDI Import, MIDI Input, Health, Timing, Learn, Protocol Coverage, and Sync into one product-language pattern.

Architecture choice: Add a small helper that appends the standard cold-copy safety suffix. Domain-specific tooltips, such as stem packages, passport recall, queue progress, and SysEx, remain hand-written for now because their extra clauses matter.

Future extensions: This helper should eventually become part of a fuller action-temperature system with tooltip builders for cold copy, safe-door navigation, warm file write, warm project edit, and hot confirmed hardware send.

2026-07-07 - Safe-Door Navigation Needs One Promise

Task: Add a shared MIDI safe-door tooltip helper and use it on obvious navigation-only MIDI doors.

What connects creatively: SpaceAge has many MIDI doors now: Health, Timing, Input, Output, Hardware Passports, MIDI SETUP, Protocol Coverage, MIDI AUTO, and MIDI PATCH. If every door has a slightly different safety sentence, the user has to wonder whether a different sentence means a different risk. A shared safe-door promise makes navigation feel like navigation: the button opens the right room, but it does not send MIDI, change routing, mutate project data, or change external hardware.

Architecture choice: Keep the helper local and lightweight for now. It builds the shared navigation-only clause and accepts an extra guard sentence for cases like SysEx Vault, Hardware Passport recall, timing calibration, queued patch actions, and MIDI AUTO automation. No routing, hardware-send, setup-card, SysEx, or automation behavior changed.

Future extensions: The cold-copy and safe-door helpers are starting to outline a full action-temperature service. A later model-level enum could drive tooltips, button badges, confirmation dialogs, support receipts, and manual text from the same source of truth.

2026-07-07 - Hot Hardware Actions Need One Warning Shape

Task: Add a shared MIDI hot-hardware tooltip helper and use it on obvious confirmation-gated hardware queue buttons.

What connects creatively: MIDI hardware can feel scary because one wrong click can change a synth, fire a note, or push setup data into a device the user barely remembers configuring. Hot buttons should therefore speak in the same rhythm every time: confirmation happens first, MIDI is queued only after that, hardware may be affected, and SpaceAge can prove its queue attempt but not the device's real-world acceptance. This connects timing pulse trains, setup test notes, Hardware Passport recall, MIDI PATCH setup cards, and bend testing into one predictable trust ritual.

Architecture choice: Tooltip wording only. The helper does not change confirmations, queue paths, MIDI messages, routing, SysEx behavior, or receipts. It only standardizes the first visible warning on the hot buttons that already had guarded send paths.

Future extensions: The same helper should later feed visual badges and confirmation dialog preambles, so hot hardware actions can be recognized before click, during confirmation, and after queue receipt.

2026-07-07 - Warm MIDI Edits Need A Calm Contract

Task: Add a shared warm MIDI project-data tooltip helper and apply it to obvious no-send project/passport/vault metadata edits.

What connects creatively: Warm MIDI actions are where SpaceAge changes its own memory: timing calibration, Hardware Passport drafts, sync policy, Vault metadata, SoundFont mapping, setup-card notes, and queue-safe NRPN definitions. These actions are not harmless copies, but they also are not hot hardware sends. Naming that middle temperature clearly gives the user confidence to organize a hardware setup without fearing accidental Program Change, SysEx, or live output.

Architecture choice: Tooltip wording only. The helper describes the SpaceAge-side data scope that can change, whether routing metadata may change, and the no-MIDI/no-external-hardware boundary. Specialized confirmation messages and receipts stay explicit where they mention device acceptance, import boundaries, detailed blocked message families, or manual verification evidence.

Future extensions: The warm helper should eventually pair with actual transaction metadata: undo checkpoint available, project dirty flag, affected object id, and whether the edit lives in pattern, lane, Hardware Passport, Vault, or global project settings.

2026-07-07 - MIDI File Writes Are Warm But Not Project Mutations

Task: Add a shared warm MIDI file-write tooltip helper and apply it to the MIDI export preview's file and stem-package export actions.

What connects creatively: Export is a different kind of courage than hardware send or project mutation. The user is creating an artifact outside the project, but SpaceAge is not changing the song, routing, or hardware. Treating MIDI file writes as their own action temperature lets the app speak precisely: this button writes useful collaborator artifacts, but it will not secretly transmit or rearrange anything.

Architecture choice: Tooltip wording only. The helper is intentionally limited to MIDI export/package actions for now, not project archives, Quasar packages, or general audio renders.

Future extensions: The same pattern can later drive export progress meters and receipts: artifact path, file count, checksum, whether the project was dirtied, and whether the action created only files versus mutating the open session.

2026-07-07 - MIDI File Write Reports Should Echo The Same Safety Boundary

Task: Add a shared warm MIDI file-write safety-line helper and use it in the MIDI export preview report.

What connects creatively: Tooltips help before the click, but reports help during decision and after review. If both speak the same safety language, SpaceAge teaches a stable mental model: exporting MIDI creates files, but it does not transmit, reroute, mutate the song, or change external hardware. This connects the export preview, future progress meters, collaborator packages, and support receipts into one confidence-building voice.

Architecture choice: Keep the helper small and report-shaped rather than forcing tooltip prose into visible report text. It accepts an artifact description, so single-file exports and stem-package exports can share the same safety sentence while keeping their artifact shape distinct.

Future extensions: The same report helper can become the first line of future progress/receipt UI for MIDI packages, with file counts, destination paths, checksums, and "project dirtied: no" evidence.

2026-07-07 - Export Preview Copy Should Say Files, Not Anything

Task: Tighten the MIDI export preview header sentence from "writes anything" to "writes MIDI files."

What connects creatively: A DAW earns trust by being precise about consequences. "Anything" sounds like the app might mutate the project, send MIDI, or poke hardware. "MIDI files" tells the composer exactly what kind of artifact is about to happen and keeps the export panel aligned with the warm file-write safety line.

Architecture choice: Wording-only patch. The status lines that already say WRITING DRUM MIDI FILE and WRITING ARRANGEMENT MIDI FILE were left alone because they already match the action temperature.

Future extensions: When export progress gets a richer meter, the same language should carry into the progress body: file count, current file name, destination, and a no-send/no-project-mutation footer.

2026-07-07 - Mixed Import/Export Buttons Need Scoped Promises

Task: Tighten wording on compact MIDI entry buttons and stem-package preview text so safety promises attach to the right action.

What connects creatively: A small button can carry more than one behavior: click opens a menu, drag writes a temporary MIDI file, import changes project data, export writes an artifact. If one safety sentence casually covers all of those, the user learns the wrong risk model. Scoping the promise to the exact gesture keeps the interface honest without adding more chrome.

Architecture choice: Wording-only patch. The compact Sequencer MIDI button now says click opens import/export options, while dragging writes a temporary MIDI file with no send/routing/project/hardware side effects. Stem-package preview text now says full-arrangement MIDI file, avoiding confusion with SpaceAge project/arrangement data.

Future extensions: Multi-action buttons may eventually need small visual action-temperature badges per gesture: click menu, drag export, hot send, warm import, cold copy. For now, precise prose keeps the current minimalist button viable.

2026-07-07 - Cold Copy Helpers Need Room For Queue Boundaries

Task: Extend the shared MIDI cold-copy tooltip helper with an optional extra guard sentence and route Hardware Passport recall copy buttons plus MIDI PATCH setup-card copy through it.

What connects creatively: Hardware Passport recall is a place where "copy" and "queue" live next door to each other. If the copy buttons do not explicitly say they queue no recall, a nervous hardware user may hesitate. Letting the helper carry a small extra guard connects support/report copying, recall planning, queue progress, MIDI PATCH setup cards, and future hardware logs without giving every surface its own improvised safety dialect.

Architecture choice: The cold-copy helper remains tooltip-only and still defaults to the standard no-send/no-routing/no-project/no-hardware boundary. The new optional guard is used for recall-specific details such as Queues no recall and Cancels no MIDI and changes no queue.

Future extensions: A model-owned action-temperature descriptor could eventually include side-effect flags such as queues hardware, cancels queue, writes file, mutates project, changes routing, or sends MIDI. The helper extension is a small step toward that without refactoring the full action model today.

2026-07-07 - MIDI Copy Surfaces Should Share One Cold Voice

Task: Convert more hand-written MIDI copy/report tooltips to the shared cold-copy helper.

What connects creatively: Copy buttons are support tools, teaching tools, and trust tools. Whether the user is copying an import repair report, MIDI Setup preview, MIDI AUTO report, or MIDI PATCH setup card, the emotional contract should feel identical: this is text leaving the app, not MIDI leaving the app. Unifying that language makes SpaceAge easier to trust under pressure.

Architecture choice: Convert obvious copy-only tooltip surfaces while preserving extra domain-specific guardrails. MIDI package copies keep imports no stems and repairs no files; MIDI PATCH protected rows keep their copy-only character; SysEx-specific copy surfaces remain hand-written for now because they need sharper sends no SysEx / queues no recall language.

Future extensions: The cold-copy helper can eventually be split into MIDI, SysEx, project, and file-report variants if the wording starts to carry too many exceptions. For now, one helper plus small extra guards is the right amount of structure.

2026-07-07 - SysEx Copy Needs A Sharper Cold Voice

Task: Add a SysEx-specific cold-copy tooltip helper and use it on SysEx Vault copy/report actions.

What connects creatively: SysEx is the scary dialect of MIDI because users associate it with overwriting hardware memory. A generic "sends no MIDI" promise is technically fine, but emotionally weaker than saying the exact dangerous thing: no SysEx is sent, no restore or recall is queued, no dumps are saved, and no hardware changes. That sharper language connects SysEx Vault, Hardware Passport recall, manual verification, restore receipts, and future hardware librarian workflows.

Architecture choice: Add a separate buildSysExColdCopyTooltip() instead of stretching the generic MIDI helper. The helper is currently used for COPY REPORT, COPY CAPTURE, and COPY BATCH DRY RUN; listen-only, cancel, and warm save actions remain on their existing wording paths.

Future extensions: SysEx can eventually get a fuller action-temperature helper family: cold copy, listen-only capture, warm vault save/link/detach, and hot confirmed restore. That would keep librarian UX precise without making the generic MIDI helpers carry too much specialized fear.

2026-07-07 - SysEx Listen-Only Actions Need Their Own Contract

Task: Add a SysEx-specific listen-only tooltip helper and use it for live capture arm/cancel actions.

What connects creatively: A SysEx listener feels close to a recorder, and a recorder feels close to saving. That can make users nervous around hardware dumps. Separating listen-only from copy-only and warm save actions gives SpaceAge a clearer mental model: listening can observe the outside world, copying can describe it, saving can commit it to the project, and confirmed restore can change external hardware. Those are four different doors, and the UI should make the door labels impossible to confuse.

Architecture choice: Add buildSysExListenOnlyTooltip() next to the SysEx cold-copy helper. ARM CAPTURE now says it listens and stores nothing in the project until SAVE CAPTURE; CANCEL now says unsaved capture evidence is discarded from the listening state. Behavior is unchanged.

Future extensions: The same helper should be reused if live multi-dump batch capture gets a true listener later. A future SysEx Vault inspector could display these action temperatures visually: Listen, Copy, Save, Restore.

2026-07-07 - Copied Hardware Receipts Should Match Tooltip Boundaries

Task: Tighten Hardware Passport copied receipt safety lines so they include the same no-routing boundary as their cold-copy tooltips.

What connects creatively: A tooltip teaches the user before the click, but a copied receipt is what they may paste into a support email, manual verification log, or collaborator message. If those two artifacts disagree by omission, trust leaks out quietly. Keeping the receipt language aligned with the tooltip lets SpaceAge's MIDI safety model travel outside the app.

Architecture choice: Wording-only patch to the Hardware Passport COPY PLAN, COPY CLOSEOUT, COPY LOG, and COPY QUEUE receipt strings. No behavior changed; the copied evidence now says these actions changed no routing in addition to the existing no-send/no-queue/no-project/no-hardware promises.

Future extensions: A shared receipt builder should eventually sit beside the tooltip helpers so cold-copy actions cannot drift between button text, tooltip text, copied receipt text, and manual docs.

2026-07-07 - SysEx Batch Dry Runs Are Evidence, Not Setup

Task: Align the SysEx batch dry-run copied receipt with the cold-copy tooltip boundary.

What connects creatively: A dry run is powerful because it lets the user rehearse a scary action without doing it. For SysEx, that distinction matters doubly: a batch plan should feel like a checklist on paper, not a hidden setup operation. Saying it changes no routing preserves that rehearsal quality and keeps it separate from live capture, vault save, and hardware restore.

Architecture choice: Wording-only patch to COPY BATCH DRY RUN. The copied receipt now states that the action sends no SysEx, starts no live batch capture, saves no dumps, changes no routing, changes no project data, and changes no external hardware.

Future extensions: When true live multi-dump capture arrives, its preflight can reuse the same dry-run receipt structure and then clearly cross the line into listen-only or hot capture mode only after confirmation.

2026-07-07 - Import Preview Copy Is Not Import

Task: Align MIDI import-preview copy wording with the full cold-copy contract.

What connects creatively: Import previews sit right beside a warm action that can change project data. The copy button is a different creature: it copies the plan, not the plan's consequences. Saying it changes no routing helps the user trust that they can paste a preview into notes or support without accidentally committing any import setup.

Architecture choice: The import preview COPY REPORT tooltip now uses the default cold-copy helper boundary, and the copied receipt now includes changed no routing alongside no MIDI send, no project mutation, and no hardware change.

Future extensions: Import/export review dialogs should eventually display a small action-temperature badge on each button so COPY REPORT, IMPORT, EXPORT, and CANCEL are visually distinct before the user reads the tooltip.

2026-07-07 - Stem Package Reports Are Not Stem Imports

Task: Align MIDI stem-package copy and repair-step receipts with their cold-copy tooltip boundary.

What connects creatively: A package report is a diagnostic artifact, not a file operation. This matters because stem packages live near true warm actions that can import lanes, repair references, or write archive material. The copied report should reassure the user that it is only portable evidence: useful for support and collaboration, inert as an action.

Architecture choice: Wording-only patch to the stem-package copy receipts. They now say copied text sends no MIDI, imports no stems, changes no routing, changes no project data, repairs no files, and changes no external hardware.

Future extensions: The package importer could eventually show a mini receipt ledger: preview copied, import confirmed, repair copied, repair applied. That would make the distinction between evidence and mutation obvious across the whole archive workflow.

2026-07-07 - Receipt Cadence Should Sound Like One Product

Task: Normalize the final no-hardware clause in MIDI Health and MIDI Setup copied receipts.

What connects creatively: Users may only read these strings when something is tense: hardware is not responding, a session needs support, or a setup plan is being shared. Consistent cadence reduces micro-friction. The phrase should feel like SpaceAge speaking in one calm voice, not five nearby developers writing almost-the-same sentence.

Architecture choice: Wording-only patch to MIDI Health COPY REPORT / COPY STEPS and MIDI Setup COPY SESSION / COPY PREVIEW. The safety meaning is unchanged; the receipt text now uses the same and changed no external hardware ending as the broader cold-copy family.

Future extensions: Shared receipt builders would remove this class of grammar drift entirely. Until then, small targeted passes keep the copy trustworthy.

2026-07-07 - Repair Safe Doors Should Feel Harmless

Task: Expand MIDI repair safe-door tooltips to state the full navigation boundary.

What connects creatively: Repair buttons are tempting to fear because they appear in warning contexts. A user who sees a red or warning-colored repair action may wonder if clicking it will change routing, mutate the project, or poke hardware. The button should teach that it opens the room where repair happens; it is not the repair itself.

Architecture choice: Wording-only patch to Input, Health/device, and Output repair-button tooltips. They now say the action opens or refreshes setup surfaces only and does not send MIDI, change routing, change project data, or change external hardware by itself.

Future extensions: Safe-door navigation could eventually get a shared helper that generates both tooltip and status-line wording from the same action-temperature flags, preventing future drift.

2026-07-07 - Warm MIDI Edits Should Name The SpaceAge Data

Task: Clarify warm MIDI input-policy and MIDI Learn commit tooltips.

What connects creatively: "Warm" is only useful if the user knows what got warm. MIDI Learn commits are not hardware actions, but they do mutate SpaceAge's mapping table. Input policy is not a MIDI send, but it changes how incoming host/direct sources are resolved. Naming the specific SpaceAge data makes the safety taxonomy practical instead of decorative.

Architecture choice: Wording-only patch. The input policy dropdown now says it changes SpaceAge input routing policy only; MIDI Learn REPLACE and MACRO now say they change SpaceAge mapping data only, send no MIDI, change no routing, and change no external hardware.

Future extensions: Warm-action helpers should eventually accept a data-domain string such as mapping data, input routing policy, Passport knowledge, PTN automation, or Vault evidence. That would make these tooltips consistent without flattening their meaning.

2026-07-07 - MIDI Maps Row Controls Are Warm Mapping Edits

Task: Align MIDI Maps row-control tooltips with the warm mapping-data boundary used by MIDI Learn commits.

What connects creatively: MIDI Maps is where users will shape hardware feel: invert a knob, narrow its range, turn on pickup, change 14-bit handling, curve the response, or delete a mapping. These are not merely harmless toggles; they change the relationship between hardware gestures and SpaceAge controls. Naming them as mapping-data edits makes the page feel precise and avoids implying hardware itself is being reprogrammed.

Architecture choice: Wording-only patch to the MIDI Maps row-control family. Enable, invert, pickup, resolution, range, curve, source-cleanup, delete, and duplicate-repair tooltips now say they change SpaceAge mapping data only and send no MIDI, change no routing, and change no external hardware.

Future extensions: This page is a strong candidate for small action-temperature badges: LISTEN, MAP, COPY, and eventually SEND if hardware feedback is added. That would make advanced controller editing less intimidating.

2026-07-07 - Monitor Resets Are Session Edits, Not Project Edits

Task: Clarify MIDI input and sync monitor refresh/reset tooltips.

What connects creatively: A monitor reset is not destructive in the musical sense, but it is not nothing. It clears short-lived evidence SpaceAge gathered while listening. Calling that out as session monitor data gives users a clean mental model: refresh preserves what was observed, reset clears the observation board, and neither action sends MIDI or changes hardware.

Architecture choice: Wording-only patch to the live MIDI input monitor and incoming sync monitor controls. Refresh actions now explicitly preserve observed evidence and change no external hardware. Reset actions now say they change SpaceAge session monitor data only, while avoiding project data, routing, sync policy, MIDI sends, and external hardware changes.

Future extensions: Session monitor data should eventually get its own small visual treatment in Settings, separate from project data and hardware state. That would make diagnostics feel like a temporary flight recorder rather than a risky configuration surface.

2026-07-07 - Import Receipts Should Use Hardware Language, Not Device Ambiguity

Task: Normalize MIDI stem package import progress safety wording.

What connects creatively: Imported stem packages are warm project edits: they can add editable lanes and clips, but they should never feel like they are secretly reaching out to external gear. Using the same external hardware phrase as the rest of the MIDI safety system keeps the user's fear surface small and predictable.

Architecture choice: Wording-only patch to the MIDI stem package import progress receipt. It still says imports happen only after confirmation and may add lanes/clips, while explicitly saying the import does not send MIDI, queue SysEx, recall hardware, or change external hardware.

Future extensions: Package import receipts could eventually show two badges side by side: PROJECT EDIT and NO HARDWARE ACTION. That would make collaborator/package workflows feel powerful without feeling risky.

2026-07-07 - SysEx Closeout Evidence Must Not Sound Like Restore

Task: Expand selected-snapshot closeout report safety wording.

What connects creatively: A SysEx snapshot closeout is emotionally close to a restore action because it describes a dump, a device, timing, and verification. That proximity makes the copy-only boundary important. The user should be able to copy evidence for support without wondering whether SpaceAge just queued bytes for a synth.

Architecture choice: Wording-only patch to the selected SysEx snapshot closeout report. The no-selection and selected-snapshot states now both say the report is read-only/copy-only evidence, sends no MIDI, queues no restore or recall, changes no routing, changes no project data, and changes no external hardware.

Future extensions: The SysEx Vault could eventually use distinct headers for Evidence, Plan, and Send Queue so the user can see at a glance whether they are reading, preparing, or actually transmitting.

2026-07-07 - Warm Evidence Edits Need Their Own Data Names

Task: Clarify timing calibration confirmations and SysEx Vault evidence-button tooltips.

What connects creatively: Timing calibration, manual SysEx verification, and response clearing are all warm actions, but they mutate different kinds of SpaceAge memory. Calibration changes timing knowledge and live record compensation. Manual verification changes Vault evidence. Clearing responses changes session evidence. Naming those buckets makes hardware workflows feel orderly instead of ominous.

Architecture choice: Wording-only patch. Timing confirmation dialogs now say they change SpaceAge timing calibration/live compensation data only. MANUAL VERIFY says it changes SpaceAge Vault evidence only after the user checks hardware. CLEAR RESPONSES says it changes SpaceAge session evidence only. All three boundaries explicitly include no MIDI sends, no routing changes, and no external hardware changes.

Future extensions: The same data-bucket vocabulary should drive future undo labels and activity logs: Timing calibration changed, Vault evidence added, Session evidence cleared. This would let SpaceAge explain itself without dumping MIDI jargon onto the user.

2026-07-07 - Import Actions Should Name Their Mutation Scope

Task: Clarify MIDI package import, selected-pattern import, and split-to-lanes import tooltips.

What connects creatively: Import is where outside material crosses into the song, so the user needs to know whether the action edits a pattern, creates lanes, creates clips, or simply previews evidence. Saying "import" is not enough anymore because SpaceAge now supports pattern import, stem package import, and channel-splitting workflows.

Architecture choice: Wording-only patch. Package import is now described as a warm SpaceAge project-data edit that can add lanes/clips and package receipts after confirmation. Selected MIDI import is a warm pattern-data edit. Split-to-lanes is a warm project-data edit that may create lane MIDI routing metadata. All three keep the no-MIDI-send and no-external-hardware boundary.

Future extensions: The import preview UI can eventually expose a small scope badge before confirmation: Pattern, Project Lanes, Routing Metadata, or Report Only. That would make complex imports safer without adding a wall of copy.

2026-07-07 - Repair Handoffs Are Cold Until The User Acts

Task: Normalize MIDI package repair handoff safety wording.

What connects creatively: A repair checklist can feel like an operation because it talks about missing files and corrective steps. But the handoff itself is only a map. It should not sound like SpaceAge is fixing files, changing routing, mutating the project, or touching gear just because the user copied or read instructions.

Architecture choice: Wording-only patch to the MIDI package repair handoff. The receipt now states that it does not import stems, repair files automatically, change routing, change project data, send MIDI, queue SysEx, or change external hardware.

Future extensions: Repair handoffs could eventually be grouped under Review, Reveal, Recheck, and Apply actions. That would let the UI reserve more forceful color/confirmation language only for actions that actually mutate files or project data.

2026-07-07 - Hardware Passport Saves Are Knowledge, Not Transmission

Task: Clarify Hardware Passport recipe-save statuses, Vault capture-save receipts, and blocked bend-test safety text.

What connects creatively: A Hardware Passport is SpaceAge's memory of how to talk to a device. Saving that knowledge is different from sending instructions to the device. The wording has to preserve that boundary so users can safely build hardware profiles while knowing that actual transmission remains a confirmed, separate step.

Architecture choice: Wording-only patch. Hardware Passport recipe saves now say they change Passport data, plus lane routing metadata only when attached to a lane, and do not send MIDI or change external hardware. Vault capture saves say project Vault data changed only, with no MIDI, no restore queue, no routing change, and no external hardware change. Blocked BEND INFO reports now include the full cold/read-only no-hardware boundary.

Future extensions: The Hardware Passport UI should eventually show a persistent split between Saved Knowledge and Queued Send. That is the core trust distinction for hardware workflows.

2026-07-07 - Setup Cards Attach To Passport Knowledge

Task: Clarify MIDI PATCH setup-card attachment and NRPN definition receipts.

What connects creatively: RPN/NRPN setup cards look like MIDI instructions because they came from MIDI. But when the user attaches or defines them in SpaceAge, they are building a reference manual inside a Hardware Passport, not sending that setup to the instrument. The wording should keep those two moments separate.

Architecture choice: Wording-only patch. Setup-card attachment now says SpaceAge Passport data changed only and no external hardware changed. DEFINE NRPN now says no project data outside the selected Passport changed, with no MIDI send, no routing change, and no external hardware change.

Future extensions: Hardware Passport pages could eventually show Knowledge Stored and Ready To Queue columns, letting users distinguish reference data from active sendable setup recipes.

2026-07-07 - MIDI Setup Drafts Are Project Metadata, Not Hardware MIDI

Task: Clarify MIDI Setup device-template apply/undo text, sync-policy save failures, and SoundFont mapping status.

What connects creatively: MIDI Setup is a wizard-like surface, so its language sets the user's overall trust posture. Applying a template draft feels big because it touches lanes and Hardware Passports, but it is still a project metadata edit until the user sends a confirmed test or recall. Undoing a draft should feel equally safe: it restores project metadata, not hardware state.

Architecture choice: Wording-only patch. Apply draft now says it is a warm SpaceAge project-data edit that may update Passport and lane MIDI routing/channel/profile metadata, sends no MIDI, and changes no external hardware. Undo draft uses the same no-MIDI/no-hardware boundary. Sync-policy save failures now include no routing/no-hardware language. SoundFont patch mapping now says it changes SpaceAge SoundFont project data only, with no MIDI, no routing, and no external hardware changes.

Future extensions: MIDI Setup could show a tiny Project Draft badge while the user is previewing templates, then switch to Hot Test only on confirmed test-note or recall actions.

2026-07-07 - Package Review Is Not Package Import

Task: Clarify MIDI package reveal/recheck tooltips and review banner.

What connects creatively: A package workflow has many verbs near each other: reveal, recheck, copy repair handoff, import stems. The musician should feel free to inspect without fearing that inspection has already changed the song. This is especially important for collaboration packages where missing files may need ordinary file-system repair before SpaceAge does anything musical.

Architecture choice: Wording-only patch. REVEAL PACKAGE is now navigation-only, RECHECK is diagnostic-only, and both state they do not import stems, repair files, change routing, change project data, send MIDI, queue SysEx, or change external hardware. The package review banner now reserves project mutation for confirmed IMPORT STEMS.

Future extensions: The package review page could display a small action ladder: Reveal/Recheck = inspect, Repair handoff = instructions, Import stems = project edit. That would make archive collaboration feel safe.

2026-07-07 - Hot Queue Language Should Name External Hardware Setup

Task: Clarify MIDI PATCH QUEUE CARD hot-action wording.

What connects creatively: Hardware setup workflows are powerful because they can make SpaceAge feel like a helpful instrument librarian instead of a maze of MIDI trivia. That only works if the app is painfully clear about the difference between preparing a setup, queuing a setup, and proving that a real device accepted it.

Architecture choice: Wording-only patch. QUEUE CARD now says it may change external hardware setup after confirmation, and the receipt language preserves the evidence boundary: SpaceAge can prove it attempted the queue, but device acceptance still needs ACK evidence or manual verification.

Future extensions: The MIDI PATCH UI could eventually show a small three-state chain: Prepared, Queued, Accepted. That would make hardware setup feel confident without pretending MIDI devices are more self-reporting than they really are.

2026-07-07 - SysEx Vault Entry Is A Cold Door

Task: Tighten SysEx Vault entry and evidence-card wording.

What connects creatively: A Vault should feel like opening a drawer of stored memories, not firing a command at a synth. If the musician is just navigating into the Vault, the app should say that no dump is being sent, no recall is being queued, and no device is being touched.

Architecture choice: Wording-only patch. SysEx Vault entry points now say they send no SysEx, queue no restore or recall, change no routing, change no project data, and change no external hardware. Evidence-only cards now use the same evidence boundary: no MIDI send, no restore/recall queue, and no external-hardware change.

Future extensions: The Vault page could eventually show cold/warm/hot badges next to its buttons: Open/Copy = cold, Save Metadata = warm, Recall = hot. That would make hardware librarian work feel much less mysterious.

2026-07-07 - Passport Roles Are Metadata Until Confirmed

Task: Clarify Hardware Passport sync-role helper copy.

What connects creatively: A Passport is both a description of a device and a launchpad for behavior. Users need to know when they are merely describing what a device can do versus authorizing SpaceAge to send clock/transport or chase incoming sync.

Architecture choice: Wording-only patch. The sync-role helper now says saving changes Passport metadata only and sends no MIDI, while send/chase roles require confirmation. Older documentation phrasing was also tightened away from vague hardware-contact language and toward explicit external-hardware boundaries.

Future extensions: A future Passport editor could split the page into Device Facts, SpaceAge Roles, and Confirmed Sends, giving users a clean mental model for what is informational, what changes project behavior, and what can affect hardware.

2026-07-07 - Hot Hardware Buttons Queue, They Do Not Magically Prove

Task: Tighten Hardware Passport hot-action helper copy.

What connects creatively: A button that affects hardware needs to feel powerful and honest. Send can imply the outside box obeyed; queue is more precise because SpaceAge can prove the outbound attempt, while device acceptance still depends on ACK evidence, manual verification, or the user's ears.

Architecture choice: Wording-only patch. Hardware Passport recall/setup tooltips now say hot queue actions may change external hardware patch/setup state after confirmation. The setup strip uses customer-facing Passport roles instead of internal profile terminology, and test-note copy says it queues one short confirmed note.

Future extensions: Every hot MIDI action should eventually produce a visible receipt with the same three facts: what SpaceAge queued, what it did not queue, and what still requires device/user verification.

2026-07-07 - MIDI AUTO Confidence Is Bigger Than One Curve Widget

Task: Recalibrate MIDI Protocol Coverage and MIDI AUTO plan wording.

What connects creatively: It is tempting to turn every cool editor idea into a release blocker, but that can make the roadmap noisy. Tangent handles would be lovely, yet MIDI AUTO's deeper product promise is confidence: users should understand what pattern owns the data, see switch edges clearly, trust pitch-bend destination ranges, and know that true clip/lane-local automation is a future architecture rather than a hidden half-feature.

Architecture choice: Wording/model-truth patch only. The Protocol Coverage model and per-lane MIDI AUTO plan now describe the remaining blocker as a launch-grade confidence layer: interactive curve shaping, switch-edge feedback, durable destination bend-range contracts beyond the first-pass cue, and the documented future path for true clip/lane-local automation. MIDI storage, playback, export, PTN ownership, and routing behavior did not change.

Future extensions: When we build the next MIDI AUTO feature, prioritize the thing that reduces user doubt most: destination bend trust for external synths, switch-edge editing confidence, or a clean clip/lane-local automation architecture. Direct curve handles remain desirable, but they should serve the workflow rather than dominate the definition of readiness.

2026-07-07 - Closeout Doorways Should Be Cold Unless They Say Otherwise

Task: Clarify MIDI closeout Open Next route status messages for import/export surfaces.

What connects creatively: A dashboard button that moves the user to another page should feel like walking through a hallway, not pulling a lever. The user may be nervous because the subject is MIDI import/export, but navigation itself should remain a calm, cold action.

Architecture choice: Status-copy patch only. The MIDI Health and Protocol Coverage closeout routes that open Sequencers for MIDI Tasks or Arranger for Render choices now say they are navigation-only and do not send MIDI, change routing, change project data, or change external hardware. The actual import/export actions remain separate.

Future extensions: Any future closeout route that lands on a page rather than performing an operation should automatically append the same cold-door sentence. That keeps guided repair/navigation from feeling like accidental mutation.

2026-07-07 - Protocol Rows Need The Same Hardware Vocabulary

Task: Tighten remaining MIDI Protocol Coverage safety-row wording.

What connects creatively: The dashboard is becoming a trust surface, not just a checklist. If one row says alter device and another says changes no external hardware, users will feel the inconsistency even if they cannot name it. The words should teach the mental model: cold routes inspect, warm edits change SpaceAge data, hot queues may affect external hardware after confirmation.

Architecture choice: Wording-only patch. RPN/NRPN, Program/Bank, SysEx Core Safety, and Clock/Transport rows now use the same external-hardware vocabulary as the rest of the MIDI UI. Program/Bank wording also separates internal preset changes, SoundFont mapping, lane metadata, and external patch state so the mutation scope stays visible.

Future extensions: The Protocol Coverage model could eventually expose the cold/warm/hot state as structured data instead of prose only. That would let the UI render consistent badges, tooltips, and confirmation language from one source.

2026-07-07 - Bend Rows Should Not Re-Block Existing Drawing

Task: Correct Pitch Bend / Pressure closeout wording.

What connects creatively: Pitch bend is one of those places where the app can be technically correct and still feel untrustworthy. The user needs to know what the destination will do with raw 14-bit bend data, especially when external hardware may have a different bend range than SpaceAge expects. The wording should point at that trust problem, not pretend the first-pass graph drawing work is still missing.

Architecture choice: Wording/model-truth patch only. The Pitch Bend / Pressure row now points at durable destination bend-range contracts beyond the first-pass cue, interactive curve shaping, and real-hardware validation of the confirmed Hardware Passport bend-test workflow. No MIDI storage, playback, export, bend scaling, or hardware-send behavior changed.

Future extensions: Bend-range contracts should become visible at every point of risk: lane routing, MIDI AUTO bend lanes, Hardware Passport setup, TEST BEND receipts, import review, and export reports. That would turn pitch bend from a hidden assumption into a declared musical contract.

2026-07-07 - Current Reports Should Not Undercut Finished Affordances

Task: Recalibrate MIDI AUTO closeout wording so reports credit the first-pass switch-edge handles, selection-time guidance, and switch/block report language that now exist.

What connects creatively: If SpaceAge keeps saying "switch-edge confidence" as though no work has landed, the project starts gaslighting its own progress. Better wording matters because the reports are becoming our release cockpit. They should tell the truth twice: first, what is already real; second, what still needs validation polish before we make a product claim.

Architecture choice: Source-of-truth wording only. MIDI storage, PTN ownership, switch-edge editing behavior, drag/hit testing, playback, export, and hardware routing are unchanged. Protocol Coverage and MIDI AUTO plan text now say remaining switch work is validation polish beyond first-pass handles/guidance.

Future extensions: Apply this same honesty to every major system as it matures: Instrument Bay, VST hosting, Quasar, automation lanes, SysEx Vault, and render/export should all avoid stale "missing" language once a first-pass version has become real.

2026-07-07 - Copied Reports Should Preserve The UI's Mental Model

Task: Add MIDI AUTO lane-model boundaries to copied preflight reports.

What connects creatively: A copied report is often what future-us, support, or a collaborator will read when the UI is not in front of them. If the panel teaches that switch lanes are ON/OFF blocks and editable lanes are PTN-only/no-hardware surfaces, the copied report should carry that teaching too. Reports should not be dry dumps; they should be portable understanding.

Architecture choice: Model-owned report wording only. The underlying MIDI AUTO lanes, event storage, editor gestures, hardware routing, MIDI PATCH workflows, and confirmation guards are unchanged. midiExpressionPreflightToPlainTextReport() now writes concise boundaries for editable lanes, switch/block lanes, and review-only setup/device lanes.

Future extensions: Use copied reports as a design-pressure tool everywhere. If a workflow cannot explain itself clearly in a copied support report, the GUI probably has hidden assumptions that deserve a better label, receipt, or guided panel.

2026-07-07 - Every MIDI AUTO Edit Should Say What It Touches

Task: Add the same project/hardware safety boundary to MIDI AUTO point and switch-edge drag/nudge success messages.

What connects creatively: SpaceAge is growing powerful enough that a musician might reasonably wonder whether moving a MIDI AUTO point could affect external hardware immediately. The answer should be visible at the exact moment of action: this changed PTN data, undo exists, and no MIDI was sent. That transforms a technical safety guarantee into a felt workflow guarantee.

Architecture choice: Status-copy polish only. The processor mutation paths, undo checkpoints, shared-pattern guards, collision checks, stale-event refusals, and hardware routing remain unchanged. A small shared phrase now follows successful direct drag/nudge/timing edits.

Future extensions: Make "what did this touch?" a general interaction language across SpaceAge: clip edits, Section markers, Instrument Bay changes, Hardware Passport actions, SysEx restores, render/export, Quasar capture, and future automation clips should all have clear mutation boundaries.

2026-07-08 - Reports Must Retire Old Blocker Language

Task: Align MIDI Protocol Coverage, MIDI AUTO per-lane plans, and copied MIDI AUTO reports with the first-pass bend-span and switch block-context work that now exists.

What connects creatively: A release cockpit should not keep warning about an older version of the airplane. Once SpaceAge can show raw pitch-bend span and switch block context, the reports should stop implying those visibility layers are absent. This connects MIDI AUTO, Hardware Passport bend contracts, switch-edge editing, copied support reports, and Settings Protocol Coverage into one honest progress model.

Architecture choice: Source-of-truth wording only. MIDI storage, playback, export, hardware routing, pitch-bend scaling, switch-edge gestures, and PTN ownership are unchanged. The remaining blocker language now points at the true next layer: interactive curve shaping, switch-edge validation polish beyond first-pass handles/guidance/context readouts, durable destination bend-range contracts beyond first-pass cue/span reporting, and future clip/lane-local automation policy.

Future extensions: Add a small checklist test for report wording when MIDI AUTO features graduate from "missing" to "first-pass real." The app should not gaslight its own progress by keeping solved affordances in blocker text.

2026-07-08 - Bend Contracts Should Be A Ritual, Not A Phrase

Task: Make MIDI AUTO pitch-bend lane plans describe the concrete hardware trust steps behind "durable bend-range contract."

What connects creatively: Musicians do not buy "contracts"; they buy confidence that a slide lands where their ear expects. Naming the ritual directly makes the feature feel teachable: choose one destination lane, attach a Hardware Passport, declare the target's +/- bend range, and use TEST BEND before trusting external hardware. This connects MIDI AUTO editing, Arranger lane routing, Hardware Passport setup, MIDI PATCH bend tests, and future MPE/string-controller workflows into one visible safety ceremony.

Architecture choice: Checklist wording only. No MIDI storage, routing, playback, export, TEST BEND behavior, or pitch-bend scaling changed. The plan now credits the selected-lane cue/raw span and names the remaining persistent trust badge separately.

Future extensions: Turn this ritual into a guided badge with four states: destination chosen, Passport attached, bend range declared, TEST BEND verified. That badge could live on MIDI AUTO pitch lanes, Arranger lane badges, Hardware Passport rows, and export preflight reports.

2026-07-08 - Hardware Trust Should Belong To The Lane

Task: Clarify Hardware Passport bend-test plans so the selected Arranger lane is named as the owner of the external bend-range context.

What connects creatively: The Instrument Bay architecture says a lane owns its instrument choice, mixer destination, MIDI channel, and future hardware relationship. Pitch-bend trust should follow the same mental model. If the user wants a MiniNova bass lane to slide correctly, the contract belongs to that lane, not to a mysterious global MIDI setup room.

Architecture choice: Checklist/safety-copy wording only. No routing, Hardware Passport data, TEST BEND queue logic, MIDI send behavior, or pitch-bend math changed. The plan now starts by asking the user to choose the Arranger lane whose external instrument should own the bend range, and its safety copy says the hot test runs from that lane's Hardware Passport.

Future extensions: Add lane-level bend trust badges beside the MIDI channel/output labels: BEND ?, BEND +/-2, BEND TESTED, or BEND MISMATCH. Those badges could flow into MIDI AUTO, MIDI PATCH, Arrangement lanes, and export preflight.

2026-07-08 - Selection Should Not Masquerade As Live Routing

Task: Tighten MIDI Input destination copy so live-controller routing is clearly owned by the MIDI-armed lane, not by whichever clip or lane is visually selected.

What connects creatively: SpaceAge now separates composition context from performance destination. A selected clip says "edit me"; a MIDI-armed lane says "play me." If those two ideas blur, the whole Instrument Bay/lane architecture feels unpredictable. Naming the boundary directly connects MIDI Input, Arranger lane badges, Step Input, recording, ghost notes, and future hardware profiles into one understandable rule.

Architecture choice: Copy/report wording only. No live MIDI routing, recording, lane arming, selection behavior, playback, MIDI Learn, or hardware input behavior changed. The visible MIDI Input panel and trust-gate boundary report now say selected clips/lanes are editing context and do not steal live input.

Future extensions: Give the armed lane a stronger persistent badge and maybe a single-key "arm selected lane for MIDI input" shortcut. That would make the distinction visible before a user opens diagnostics.

2026-07-08 - Live Input Needs A Stronger Verb Than MIDI

Task: Change the armed Arrangement lane MIDI badge from MIDI IN to LIVE IN and make its tooltip explain the live-input/editing-context split.

What connects creatively: MIDI IN names a protocol pipe; LIVE IN names a performance destination. That one word helps the user understand why playing a controller follows the armed lane rather than the selected clip. It connects hardware input, lane-owned instruments, recording, Step Input, and future MIDI routing badges with a more musical verb.

Architecture choice: Label/tooltip polish only. Lane arming, MIDI routing, recording, playback, selection behavior, and Instrument Bay ownership are unchanged. The button still toggles the same armed MIDI input lane; it just reads and teaches better.

Future extensions: Treat LIVE IN as a product-level badge family. Future badges could include LIVE OUT, BEND OK, CLOCK, MPE, and EXT, each meaning one exact routing contract instead of vague MIDI presence.

2026-07-08 - Live Input Reports Should Share One Sentence

Task: Move the LIVE IN routing explanation into one shared MIDI Health summary so the visible panel, copied next steps, copied full report, and structured payload all teach the same rule.

What connects creatively: The lane badge is the user's cockpit light; MIDI Health is the mechanic's diagnostic sheet. If those two tell the story differently, hardware feels mystical again. A shared LIVE INPUT sentence connects the performer's immediate action, the Settings diagnostics, support receipts, and future manual copy around one stable concept.

Architecture choice: Add a MidiProjectHealthSummary::liveInputSummary() helper and reuse it instead of hand-writing destination/mode strings in multiple places. This changes reporting only; it does not change arming, routing, recording, selection, playback, or MIDI message handling.

Future extensions: The same helper can later include LIVE OUT, MPE zone status, external output confidence, or armed-input conflict warnings without hunting through every panel/report by hand.

2026-07-08 - Old Blocker Words Can Become False Negatives

Task: Narrow the current MIDI AUTO closeout wording from broad interactive curve shaping to the smaller remaining layer: draggable tangent-handle curve editing beyond direct scope drawing and preview-confirm transforms.

What connects creatively: A blocker name should point to the next real missing experience, not re-describe a thing that already exists. SpaceAge already has preview-confirm smoothing/easing/thinning, so the remaining curve work is more specific: give the user direct contour handles that feel like shaping a musical gesture with the mouse.

Architecture choice: Source-of-truth report wording only. MIDI AUTO storage, transforms, drawing, switch lanes, pitch-bend span reporting, playback, export, and hardware routing are unchanged. The live Protocol Coverage model now stops implying that all curve shaping is absent.

Future extensions: Use this same discipline for every progress surface: name the exact missing layer. curve editor should become Bezier handles, hardware bend should become Passport +/- range + TEST BEND receipt, and SysEx polish should become specific ACK/NAK/checksum/device-id work.

2026-07-08 - Pitch Bend Reports Need A Trust Boundary

Task: Add an explicit pitch-bend trust line to copied MIDI AUTO reports when a pitch-bend lane is selected.

What connects creatively: Pitch bend is one of those features that can look correct while sounding wrong on external hardware. The graph can prove that SpaceAge preserved the raw 14-bit gesture; it cannot prove that a MiniNova, QY, wind controller rig, or future MPE destination interprets that gesture as the same number of semitones. The copied report is where a user or support conversation needs that distinction in plain English.

Architecture choice: Report wording only. MIDI AUTO storage, playback, export, Hardware Passport data, TEST BEND behavior, and routing were unchanged. The report now repeats the trust ritual: one destination lane, attached Hardware Passport, declared +/- bend range, and TEST BEND evidence.

Future extensions: Turn this line into a compact reusable badge for MIDI AUTO, Piano Roll, Hardware Passport, export preview, and future MPE zones. The same badge can eventually display trusted, needs Passport, range mismatch, or test not verified.

2026-07-07 - Preview Means No Hardware Surprise

Task: Make MIDI AUTO smoothing, easing, and thinning previews state their safety boundary directly in the status line.

What connects creatively: Preview-confirm tools are trust tools. If a user clicks APPLY CURVE or THIN REDUNDANT, they should know whether SpaceAge is only reshaping the local PTN data or doing anything scarier. The same principle belongs to render, import, SysEx recall, Hardware Passport tests, Quasar capture, and future AI-assisted patch generation: preview should explain what changes, what stays anchored, and what definitely does not touch hardware.

Architecture choice: UI copy only. The transform engine, undo checkpoint, shared-pattern guard, endpoint-anchoring behavior, thinning math, and MIDI routing are unchanged. The editor now adds transform-specific confidence text for preview-confirm operations and an applied-state reminder that project data changed with undo available and no MIDI was sent.

Future extensions: Convert preview-confirm actions into richer mini receipts when they become more complex: before/after event counts, visible highlighted affected range, and a tiny "undo available" badge. That pattern could become a general SpaceAge language for all safe-but-destructive edits.

2026-07-07 - Switch Lanes Need To Explain Themselves Early

Task: Make MIDI AUTO switch-style lanes describe their ON/OFF block editing model as soon as the lane is selected.

What connects creatively: MIDI AUTO has more than one kind of thing inside it. A pitch bend curve behaves like a line of expressive points; sustain behaves like a row of timed switch states. If the UI treats both as generic "points," the user has to discover the difference by accident. Selection-time copy lets SpaceAge quietly teach the object before the hand reaches for the mouse.

Architecture choice: UI guidance only. The existing switch-edge hit testing, cursor feedback, paint/erase behavior, state toggling, group selection, and processor mutation guards stay unchanged. The status line and selected-lane strip now reuse the lane summary's switchLane flag to explain block painting, edge trim, Up/Down state toggling, and right-drag erasing.

Future extensions: Use the same selected-object teaching pattern for chord markers, section markers, Quasar zones, Instrument Bay routing, and future automation clips. Each selected thing should answer: "what am I, what can you safely do to me, and what should not be assumed?"

2026-07-07 - A Bend Cue Is Not Yet A Bend Contract

Task: Reconcile MIDI AUTO and Protocol Coverage wording so SpaceAge credits the selected-lane BEND RANGE cue that already exists while still keeping the larger destination bend-range contract on the closeout list.

What connects creatively: This is the difference between a road sign and a guardrail. The sign tells the user, "this lane's bend range deserves attention"; the guardrail eventually prevents the user from trusting external hardware until the destination range, Passport, and TEST BEND evidence agree. That connects MIDI AUTO, Hardware Passport, MIDI PATCH, MIDI guitar/wind workflows, and future MPE setup into one trust ritual.

Architecture choice: Source-of-truth wording only. No MIDI storage, playback, export, pitch-bend scaling, Hardware Passport model, TEST BEND behavior, or hardware-send routing changed. The code now describes the current state as first-pass selected-lane bend cue plus unfinished durable per-lane/per-destination contract.

Future extensions: Promote the cue into a reusable contract badge that can appear on Arranger lanes, MIDI AUTO pitch lanes, MIDI PATCH rows, import review, export preflight, and hardware setup receipts. A musician should never have to guess whether a slide will mean +/-2, +/-12, or something stranger on the target instrument.

2026-07-07 - Pitch-Bend Warnings Should Meet The User At Selection Time

Task: Surface the selected MIDI AUTO pitch-bend destination cue in the panel status line and treat unknown/missing Hardware Passport bend-range cases as visible warnings.

What connects creatively: A user should not have to hunt through reports to learn that a bend lane feeds hardware with an unknown range. Selection is a moment of intent: "I am about to edit this." That is exactly when SpaceAge should say whether the destination contract is trusted, missing, or ambiguous.

Architecture choice: UI confidence polish only. MIDI storage, PTN ownership, playback, export, Hardware Passport data, and hardware-send behavior are unchanged. The status line now reuses the existing selected-lane cue model, so the graph, copied report, and live status are speaking from the same source.

Future extensions: Turn this into a compact reusable contract badge for any lane gesture that depends on destination interpretation: bend range, MPE zone, breath CC mapping, drum articulation maps, external device program recall, and future MIDI 2.0 profile behavior.

2026-07-07 - Timing Polish Should Not Masquerade As A New Blocker

Task: Clarify Hardware Output Timing coverage wording.

What connects creatively: Timing is not just math; it is feel. But there is a difference between a usable timing foundation and the last layer of confidence language, diagnostics, and real-device validation. If the coverage table treats all timing polish as a blocker, the finish line feels like it moved backward. If it hides the polish, musicians will distrust the hardware story.

Architecture choice: Wording/model-truth patch only. Hardware Output Timing now says the release foundation exists: sample-positioned playback, direct-output offsets, Passport timing records, manual/loopback measurements, and timing reports. The remaining work is framed as validation polish: apply/recalibrate controls, driver/jitter diagnostics, progress/status feedback, and real-device receipt testing.

Future extensions: The timing page should eventually become a simple ritual: send pulse, hear/record return, accept measurement, see confidence. That would turn a scary hardware-latency topic into a little calibration ceremony.

2026-07-07 - Tempo Maps Need A Conductor, Not A Trapdoor

Task: Clarify Timeline Map closeout wording.

What connects creatively: Imported MIDI files often contain tempo, meter, and key information, but blindly applying that data to an existing SpaceAge song could wreck a careful arrangement. The right metaphor is a conductor timeline: a visible, undo-safe track of global musical context that can be reviewed, adopted, or rejected with intention.

Architecture choice: Wording/model-truth patch only. Timeline Map closeout now says SpaceAge needs an undo-safe conductor timeline for tempo/meter/key maps before full source-map adoption. That keeps import review honest without changing the current first-tempo/key adoption behavior.

Future extensions: The conductor timeline can later become the home for tempo automation, meter changes, key/modulation maps, chord-scale context, form presets, and imported score metadata.

2026-07-07 - Closeout Reports Need A Critical Path

Task: Add a compact critical-path summary to MIDI Protocol Coverage reports.

What connects creatively: The long MIDI report is now rich enough to be useful, but also rich enough to slow us down. A top-line critical path gives the report the same behavior we want from the app: show the next meaningful action, explain why it matters, then provide detail only after the user has orientation.

Architecture choice: Lightweight model/report addition. MidiProtocolCoverageReport now exposes criticalCloseoutPathSummary(), included in plain-text and structured reports. It uses existing blocker-category ordering and does not change priorities, MIDI routing, UI navigation, or readiness math.

Future extensions: The Settings UI could surface this string as a small NEXT BEST MIDI TASK card with an Open button and a copyable receipt. That would make the dashboard feel less like an audit log and more like a release copilot.

2026-07-07 - The Dashboard Should Say The Same Thing As The Report

Task: Surface the MIDI critical-path summary in visible panels and closeout copy.

What connects creatively: If the copied report has a clean next-best-task sentence but the on-screen dashboard still says the older broader Next Focus, the user has to reconcile two versions of truth. The visible panel should give the same orienting sentence the support/report text gives.

Architecture choice: UI/report wiring only. MIDI Health now labels the row CRITICAL PATH, the MIDI Protocol panel draws criticalCloseoutPathSummary(), and COPY CLOSEOUT includes the same line. No blocker ordering, readiness math, MIDI routing, or page navigation changed.

Future extensions: This critical-path string is now ready to become a persistent small card in Settings, perhaps with an OPEN button and a COPY button. That would give MIDI closeout a mission-control feel without burying the user in a giant audit.

2026-07-08 - SysEx Copy Reports Need Restore-Trust Boundaries

Task: Put the SysEx restore-trust boundary at the top of the SysEx Vault copied report.

What connects creatively: SysEx is not just data transfer; it is a handshake with potentially old, quiet, or idiosyncratic hardware. The user needs SpaceAge to preserve the useful evidence without pretending that a completed progress estimate means the external device accepted the dump. This connects the SysEx Vault, Hardware Passport recall, live capture, manual verification, and future hardware setup wizards into one evidence ladder.

Architecture choice: Report wording only. COPY REPORT now says that estimated queue/wire progress is not device acceptance, that ACK/NAK/WAIT/CANCEL receipts describe hardware response state, and that MANUAL VERIFY is user-confirmed evidence after checking the hardware, not a device ACK. No SysEx send, capture, recall, routing, project mutation, or hardware behavior changed.

Future extensions: Turn this trust boundary into a reusable mini-receipt that can appear anywhere a hardware restore is discussed: Passport recall queues, SysEx restore confirmation dialogs, support bundles, and device setup walkthroughs. The product should feel reassuring because it is honest.

2026-07-08 - SysEx Trust Needs An Evidence Ladder, Not A Single Word

Task: Replace narrow ACK/NAK shorthand in SysEx restore progress and selected-snapshot UI with broader restore-evidence wording.

What connects creatively: Different hardware speaks back differently. Some devices may send a recognizable ACK, some may reject, some may wait, some may say nothing, and some may require the user to confirm the restored patch by ear and eye. Treating all of that as an evidence ladder makes SpaceAge feel calm around old gear instead of brittle.

Architecture choice: Wording-only safety polish. Restore progress reports and selected-snapshot evidence cards now say proof requires a device ACK-style receipt or manual verification after checking hardware. Batch restore language now says trust depends on target-device response receipts or manual verification. No SysEx parser, queue, capture, restore, routing, or project-data behavior changed.

Future extensions: The same ladder should become a compact visual badge: estimated, waiting, device replied, rejected, timed out, manually verified. That badge can unify SysEx Vault, Hardware Passport recall, hardware setup, and support reports.

2026-07-08 - MIDI AUTO Curve Reports Should Name The Tool We Actually Have

Task: Add current curve-tool boundaries to copied MIDI AUTO reports.

What connects creatively: A report that says only "curve polish remains" undersells the tool and leaves the user wondering whether curve shaping exists at all. Naming the exact behavior turns a vague gap into a useful mental model: preview first, anchored endpoints, smooth/fast/slow transforms, then future freehand/tangent drawing later.

Architecture choice: Report wording only. MIDI AUTO copied reports now say that APPLY CURVE is preview-confirm, that Smooth rounds existing points, that Fast Start and Slow Start reshape contours between anchored endpoints, and that freehand/tangent curve drawing remains future polish. No MIDI AUTO storage, transform math, drawing, playback, routing, or hardware behavior changed.

Future extensions: When freehand/tangent editing arrives, this report line can become the place that explains the active curve mode and whether the edit is a transform, a drawn curve, or a tangent-handle operation.

2026-07-08 - Switch Lanes Are Blocks, Not Broken Curves

Task: Add current switch/block lane affordances to copied MIDI AUTO reports.

What connects creatively: Sustain-style MIDI data behaves more like a light switch than a fader. If reports only say "switch-edge polish remains," it sounds unfinished in the wrong way. The useful mental model is already there: paint blocks, drag edges, toggle state, erase snapped steps, and use normal selection shortcuts.

Architecture choice: Report wording only. MIDI AUTO copied reports now describe current switch tools directly: step-snapped ON/OFF block painting, draggable edge timing, up/down state toggling, right-drag erase, and Ctrl+A/C/X/V on selected switch edges. No event model, editing behavior, playback, routing, or hardware behavior changed.

Future extensions: The eventual automation architecture can reuse this same block model for clip mutes, gate patterns, arpeggiator enable lanes, effect bypass lanes, and other binary time objects.

2026-07-08 - Protocol Coverage Should Not Reopen Solved Switch-Lane Work

Task: Recalibrate live MIDI Protocol Coverage wording around switch/block lanes.

What connects creatively: A release dashboard is a steering wheel. If it keeps saying a first-pass switch editor is still missing, we will keep steering back into solved territory. The better framing is: the block editor exists; the remaining work is validation, UX confidence, and future clip/lane-local architecture.

Architecture choice: Model/report wording only. Protocol Coverage and MIDI AUTO plan text now describe remaining switch work as final validation/UX polish on top of the existing block editor. No MIDI event storage, switch painting, edge dragging, playback, routing, or hardware behavior changed.

Future extensions: This wording prepares the eventual automation-lane system to reuse the switch/block editor deliberately, rather than rediscovering the same binary-lane design under a different name.

2026-07-08 - Pitch Bend Needs Three Layers Of Truth

Task: Clarify pitch-bend Protocol Coverage and selected-lane warning language.

What connects creatively: Pitch bend is a tiny number with a huge musical consequence. The raw MIDI data is always 14-bit, but the meaning in semitones belongs to the destination. Naming three layers keeps musicians oriented: raw bend is preserved, internal/RPN range helps SpaceAge playback, and external Hardware Passport range is a trust contract.

Architecture choice: Model/report wording only. Protocol Coverage now says raw 14-bit bend data is preserved, internal/RPN range can be displayed for SpaceAge playback, and external slides require one lane, an attached Hardware Passport, a declared +/- range, and TEST BEND evidence before trust. No pitch-bend storage, scaling, playback, export, MIDI PATCH, or Hardware Passport behavior changed.

Future extensions: This should become a durable badge on pitch-bend lanes and export/hardware preflight: Raw preserved, Internal range known, External range trusted, or External range unknown.

2026-07-08 - Pitch Bend Trust Needs To Be A Badge, Not A Paragraph

Task: Add compact pitch-bend trust-state wording to MIDI AUTO selected-lane status and copied reports.

What connects creatively: The Protocol Coverage language is honest, but during actual editing the user needs a cockpit indicator rather than a lecture. The badge compresses the three-layer model into a quick scan: raw bend is preserved, SpaceAge can show its internal/RPN range, and external hardware is either not involved, unknown, range-declared but awaiting TEST BEND evidence, or missing Passport context.

Architecture choice: UI/report wording only. MIDI AUTO now derives a selected pitch-bend trust badge from the selected PTN's Arrangement lane context, route target, attached Hardware Passport, and declared bend-range policy. It does not change pitch-bend storage, playback, export, MIDI routing, Hardware Passport mutation, or TEST BEND queue behavior.

Future extensions: Replace the text-only badge with a small persistent visual badge on pitch-bend lanes and preflight/export panels. The same badge vocabulary can later drive warnings for MIDI guitar, wind controller, external synth, and MPE-like workflows.

2026-07-08 - Export Must Carry The Same Bend Truth As MIDI AUTO

Task: Add pitch-bend trust summaries to MIDI export readiness and lane/stem job rows.

What connects creatively: MIDI AUTO can show a bend-trust badge during editing, but export is where that trust boundary becomes portable. A collaborator, hardware module, or other DAW will receive the raw pitch-bend curve, not SpaceAge's assumptions about musical range. Export readiness should therefore say whether bends are internal-only, external-unknown, Passport-declared, or still awaiting TEST BEND evidence.

Architecture choice: Export report metadata and warning text only. Pattern, selected-clip, legacy-chain, and whole-arrangement export readiness now count pitch-bend expression and attach a trust summary to the affected lane or payload. No MIDI export event encoding, playback, routing, Hardware Passport mutation, or TEST BEND queue behavior changed.

Future extensions: The same trust summary can become a visible badge in the Render/MIDI export dialog, a stem-package manifest field, and a preflight blocker when exporting hardware-targeted MIDI stems for external devices.

2026-07-08 - MIDI Export Bend Trust Should Have One Mouth

Task: Consolidate export pitch-bend trust wording into one helper.

What connects creatively: Pattern export, selected-clip export, and arrangement export are different doorways into the same promise. If each doorway tells pitch-bend truth slightly differently, users will eventually distrust all of them. One helper means the product speaks with one voice: raw data is preserved, internal destinations own internal range, external destinations need Passport range and TEST BEND evidence.

Architecture choice: Centralized the export pitch-bend trust policy in one helper used by pattern-local payloads, selected arrangement clips, legacy chains, and full arrangement lane summaries. No MIDI file writing, event storage, routing, playback, Hardware Passport mutation, or hardware queue behavior changed.

Future extensions: Feed this same helper into the eventual Render dialog badge, stem-package manifest warning badges, and playback preflight gate so export and live hardware playback remain aligned.

2026-07-08 - Protocol Coverage Should Not Feel Like A Marketing Claim

Task: Add an evidence-boundary row to the visible MIDI Protocol Coverage panel.

What connects creatively: A percentage bar is emotionally powerful. If the Protocol Coverage panel says SpaceAge is almost done, a user can easily read that as "every controller, host, file, and external synth will behave." The new evidence row keeps the excitement honest: the dashboard tracks SpaceAge-side MIDI 1.0 closeout, while real-world trust still comes from project testing, hardware-path testing, import/export validation, or manual verification.

Architecture choice: Visible UI wording and scroll math only. Added a compact evidence row under the scorecard clarification and updated the Protocol panel row-area calculations so scrolling remains aligned. No protocol coverage scoring, MIDI routing, import/export, automation, SysEx, hardware queue, timing, or playback behavior changed.

Future extensions: Reuse this boundary in release notes, QA checklists, support exports, and any future "MIDI Ready" badge so the app never accidentally markets laboratory readiness as universal device proof.

2026-07-08 - Preflight Panels Should Teach Their Own Limits

Task: Put compact evidence-boundary language directly into the visible MIDI INPUT and MIDI OUTPUT preflight panels.

What connects creatively: The best safety copy is the copy the user sees before they make a decision. We already had honest copied reports, but requiring a copied report to learn the boundary is too hidden. These panel rows turn MIDI readiness into a cockpit-style readout: SpaceAge is prepared here, but trust still comes from recorded evidence, playback, listening, a test phrase, or manual verification.

Architecture choice: Visible UI wording/layout only. Added evidence rows to MIDI INPUT and MIDI OUTPUT preflight panels and adjusted their internal layout skip counts. No MIDI input routing, output routing, device opening, channel filtering, recording, SysEx, Hardware Passport, queue, timing, or playback behavior changed.

Future extensions: Reuse the same compact evidence rows in record take receipts, hardware lane badges, MIDI Setup wizard steps, and any future device-specific hardware checklist so the user never has to wonder whether SpaceAge is reporting readiness or verified external behavior.

2026-07-08 - MIDI AUTO Is A Composition Editor, Not A Hardware Oracle

Task: Add a visible evidence boundary to the MIDI AUTO / pattern automation panel.

What connects creatively: MIDI AUTO is where composition, performance gesture, hardware expectation, and export trust all meet. That makes it powerful, but also easy to misunderstand. A user seeing pitch bend, pressure, CC, or sustain lanes needs to know what is actually proven: the PTN contains editable performance automation. Whether an outside synth bends the right musical interval, whether an exported/imported file behaves correctly, or whether hardware follows the data still lives in playback, review, Passport bend-range trust, and manual verification.

Architecture choice: UI wording and layout only. The MIDI AUTO panel now draws a compact evidence row before the status/checklist/scope area, and the list/scope layout reserves the same height. No MIDI AUTO storage, editing behavior, copy/paste, curve shaping, switch-edge logic, playback, export/import, routing, or hardware behavior changed.

Future extensions: Make the evidence row state-aware later: show "playback verified," "export reviewed," "Passport bend range trusted," or "manual hardware verification present" badges when those receipts exist.

2026-07-08 - MIDI Import Preview Is Not Import Consent

Task: Add a visible evidence boundary to the MIDI Import Wizard Preview panel.

What connects creatively: Import is one of the riskiest-feeling actions in a DAW because a file from somewhere else can contain notes, expression, tempo/key hints, patch setup, SysEx, and sync events. The preview should feel useful without feeling like it already touched the song. This connects MIDI import, MIDI PATCH, SysEx Vault, Arrangement lane creation, classroom-safe workflows, and future collaborator handoff into the same trust model: preview first, mutate only after a clear commit.

Architecture choice: UI wording and layout only. The MIDI Import Wizard now draws a compact evidence row before the stat/action sections, and its fixed panel layout reserves the same added height. No MIDI import parsing, commit requests, split-to-lane behavior, SysEx storage, song metadata policy, routing, playback, or hardware behavior changed.

Future extensions: Make the row state-aware after import: show whether notes were imported, lanes were created, setup rows were preserved for MIDI PATCH, SysEx was quarantined, or song metadata was kept/reviewed/adopted.

2026-07-08 - Stem Package Check Is A Collaboration Doorway, Not A Mutation

Task: Add a visible evidence boundary to the MIDI Stem Package Check panel.

What connects creatively: A stem package is a collaboration handshake. It can contain a lot of persuasive detail: manifests, checksums, lane stems, support files, missing-file warnings, and import plans. The panel should make the safe state obvious: SpaceAge has inspected the package, but the song is not changed until IMPORT STEMS. This keeps collaboration features, classroom handoffs, archive repair, and future cloud/team workflows in the same cold/warm/hot safety language as ordinary MIDI import.

Architecture choice: UI wording and layout only. The MIDI Stem Package Check panel now draws a compact evidence row after the introductory text and reserves the same added height before the report text. No package inspection, checksum logic, repair steps, recheck behavior, import progress, lane creation, project mutation, routing, SysEx, or hardware behavior changed.

Future extensions: Convert the row into a small checklist after package import: manifest verified, lane stems imported, repair steps copied, missing files resolved, and collaborator package archived in project history.

2026-07-08 - Export Preview Should Not Pretend To Be Audition

Task: Add a visible evidence boundary to the MIDI Export Preview panel.

What connects creatively: Export is a portable promise. A .mid file can leave SpaceAge and enter another DAW, a collaborator's setup, a hardware sequencer, or an old synth module. The preview can honestly prove that SpaceAge found exportable MIDI and planned the file/package, but it cannot prove another destination will interpret bend ranges, tempo maps, patches, or expression musically. Bringing that sentence into the visible preview keeps export from feeling like a magic stamp of approval.

Architecture choice: UI wording and layout only. The MIDI Export Preview panel now draws a compact evidence row before the stat summary and reserves the same added height before the report box. No export readiness calculations, MIDI event writing, file chooser behavior, stem-package writing, routing, playback, Hardware Passport data, or hardware behavior changed.

Future extensions: Promote this row into a post-export checklist: file written, package written, checksums created, external DAW opened, hardware audition passed, bend range verified, and collaborator receipt attached.

2026-07-08 - MIDI Learn Should Prove Storage Before It Claims Feel

Task: Add a visible evidence boundary to the MIDI MAPS / MIDI Control Maps panel.

What connects creatively: A learned MIDI control can feel like a solved problem the moment the row appears, but the musician's body will judge the mapping by pickup behavior, range, curve, and whether the target responds musically. The panel should therefore celebrate the correct first proof -- SpaceAge heard and stored the controller route -- while nudging the user toward the physical feel-test that actually matters.

Architecture choice: UI wording and layout only. The MIDI Control Maps panel now draws a compact evidence row before the Learn strip. No MIDI Learn capture rules, mapping storage, live controller processing, pickup/range/curve behavior, routing, or hardware output changed.

Future extensions: Turn this same row into an interactive checklist later: move hardware, verify live meter, sweep min/max, confirm curve feel, then optionally stamp a mapping as user-tested for hardware profiles and classroom/support workflows.

2026-07-08 - SysEx Restore Evidence Should Have One Ladder

Task: Centralize the SysEx restore evidence boundary used by restore progress, restore receipts, and Librarian readiness reports.

What connects creatively: A SysEx restore is not just a file transfer; it is a trust ritual with a hardware box on the other end. If one report says "estimated progress," another says "ACK," and a third says "manual verify" without tying them together, the user has to become a MIDI lawyer. One shared ladder lets SpaceAge teach the difference: queue/wire timing is pacing, ACK/NAK/WAIT/CANCEL is device response evidence, and MANUAL VERIFY is human-confirmed evidence after touching the real hardware.

Architecture choice: Report wording only. Added one shared evidence-boundary helper and used it in restore progress reports, restore-verification receipts, and SysEx Librarian readiness reports. No SysEx storage, queue timing, response classification, restore attempts, Hardware Passport data, or MIDI routing behavior changed.

Future extensions: Feed this same evidence ladder into the visible Vault strip, Hardware Passport restore-history badges, per-device ACK dialect helpers, and any future restore progress bar so visual progress never pretends to be hardware acceptance.

2026-07-08 - Hardware Queue Receipts Are Not Hardware Consent

Task: Centralize the Hardware Passport queue-evidence boundary used by setup-card receipts, Hardware Setup template-apply receipts, test-note receipts, pitch-bend test receipts, recall plans, recall logs, and queue-progress reports.

What connects creatively: A queue receipt feels official, especially to nontechnical users, but it only describes SpaceAge's side of the cable. Treating that receipt as hardware consent would be a product-trust bug. The right language keeps the user oriented: queued/attempted is evidence of intent, not evidence that the synth accepted, stored, or audibly applied the change.

Architecture choice: Report/payload wording only. Added one shared hardware queue evidence helper and used it in MIDI setup-card receipts, Hardware Setup template-apply receipts, hardware test-note receipts, pitch-bend test receipts, Hardware MIDI recall plans, Hardware Recall Log reports, and Hardware MIDI Queue Progress reports. The structured payloads also expose the same evidence boundary and mark external device acknowledgement as false where applicable. No hardware queue timing, MIDI routing, Hardware Passport state, SysEx response classification, or recall behavior changed.

Future extensions: Reuse this helper anywhere SpaceAge displays hardware-send history, including Hardware Passport restore history, device-specific ACK/NAK dashboards, and future hardware automation send receipts.

2026-07-08 - Structured SysEx Evidence Must Match The Human Report

Task: Add the shared SysEx restore evidence boundary to structured SysEx Vault/restore payloads, including restore-response classification, where the plain-text reports already carry the same trust language.

What connects creatively: The visible report is only one doorway into the truth. Future badges, support exports, JSON diagnostics, and UI summaries may read structured payloads instead of the copied text. If the structure omits the evidence boundary, the app can accidentally become less honest when we make the interface prettier.

Architecture choice: Structured-report metadata only. SysEx Vault/restore payloads now expose the same restore evidence boundary used by plain-text restore progress, restore receipts, and Librarian readiness reports. No SysEx capture, restore queueing, ACK/NAK classification, manual verification, or MIDI routing behavior changed.

Future extensions: Use the structured evidence boundary directly in the visible Vault strip, restore progress badges, per-passport restore history, and any future support bundle export.

2026-07-08 - Sync Reports Should Not Pretend The Whole Rig Followed

Task: Add explicit evidence boundaries to MIDI Sync Runtime, Sync Policy, Hardware Sync Policy Preview, and Transport Plan reports.

What connects creatively: Clock and transport are conductor signals. They feel authoritative because they move time itself, but a report can only prove the side of the cable SpaceAge controls or observes. This mirrors the Hardware Passport and SysEx evidence rules: observed, chased, or queued is useful proof, but it is not the same as every external device accepting and following the command.

Architecture choice: Report/payload wording only. Sync Runtime, Sync Policy, and Hardware Sync Policy Preview reports now say observed/chased counters prove SpaceAge saw or applied timing messages internally. Transport Plan and future-playback preview reports now say queued Clock/Start/Continue/Stop/SPP messages prove SpaceAge attempted an allowed send. No clock generation, SPP scheduling, transport chase, playback, routing, or hardware queue behavior changed.

Future extensions: Reuse these boundaries in the visible sync monitor, any future transport-send receipt toast, and Hardware Passport sync-role badges so the user always knows whether they are seeing SpaceAge-side evidence or verified downstream hardware behavior.

2026-07-08 - MIDI Sync Preflight Needs The Boundary Before The Details

Task: Add a compact evidence boundary at the top of copied MIDI Sync Preflight reports.

What connects creatively: The preflight report is the thing a user is most likely to copy, archive, or send to support. If the first visible sentence says what the report proves, the later counters become useful evidence instead of implied magic. This is the same design principle as a cockpit checklist: state the flight condition before listing the instruments.

Architecture choice: Report wording only. The combined MIDI Sync Preflight copy now starts by saying it summarizes SpaceAge-side sync observation, chase policy, and outbound transport intent. No sync monitor counters, transport-plan generation, playback, queue behavior, Hardware Passport routing, or hardware-send behavior changed.

Future extensions: Use this same sentence as a compact header in the eventual visible Sync Preflight panel and any support-bundle export that includes sync/transport diagnostics.

2026-07-08 - MIDI OUT Readiness Is Not Hardware Obedience

Task: Add a shared evidence boundary to MIDI External Output readiness, runtime, trust gate, and copied preflight reports.

What connects creatively: A ready MIDI OUT gate is a confidence signal, not a spiritual guarantee that a synth on the other end smiled and did exactly what we hoped. This is the same product-trust pattern as SysEx restore and transport sync: SpaceAge can prove configuration, visible devices, runtime state, and attempted sends; the hardware outcome needs listening, test phrases, device response, or manual verification.

Architecture choice: Report/payload wording only. MIDI OUT readiness, runtime, trust gate, and copied preflight reports now expose the same boundary in plain text and structured data. No MIDI output routing, live playback send rules, device opening, dropped-message tracking, Hardware Passport data, or queue behavior changed.

Future extensions: Use this boundary in the visible MIDI OUT panel header, hardware lane badges, output test receipts, and support bundles so a user can always tell whether they are seeing SpaceAge-side readiness or verified downstream hardware behavior.

2026-07-08 - MIDI IN Readiness Is Not Perfect Capture

Task: Add a shared evidence boundary to MIDI Input readiness, trust gate, and copied preflight reports.

What connects creatively: MIDI input is the musician's handshake with SpaceAge. If the lane is armed and the input path is visible, the user should feel confident, but not misled. The boundary makes the product honest: readiness proves the path is prepared; the actual take still needs recorded-note/expression inspection, dropped/suppressed-message diagnostics, or listening back.

Architecture choice: Report/payload wording only. MIDI IN readiness, trust gate, and copied preflight reports now expose the same input evidence boundary. No input routing, armed-lane behavior, channel filtering, duplicate-source policy, dropped-message tracking, recording, or MIDI capture behavior changed.

Future extensions: Surface this as a compact hint in MIDI Input, record-arm tooltips, and take receipts, especially for MIDI guitar, wind controllers, dense CC performances, and future MPE-style workflows.

2026-07-08 - MIDI Repair Advice Is Not MIDI Repair Execution

Task: Add safe-door evidence boundaries to MIDI Device Inventory and MIDI Repair Recommendations.

What connects creatively: Repair suggestions are a map, not the trip. This matters because MIDI repair panels sit close to actions that can change routing or touch hardware, and users need to know when they are merely reading guidance versus committing a change. The same clarity helps schools, support workflows, and cautious hardware users trust the app.

Architecture choice: Report/payload wording only. Device Inventory now says it proves only OS-visible devices and missing saved references, not musical response. Repair Recommendations now say copying the guidance sends no MIDI, changes no routing/project data, and changes no external hardware. No device scanning, repair action routing, MIDI input/output state, Hardware Passport data, or confirmed action behavior changed.

Future extensions: Reuse this wording in repair buttons, support bundles, first-run hardware setup, and any future guided wizard where advice and execution must remain visibly separate.

2026-07-08 - A Closeout Dashboard Should Become A QA Map

Task: Make the MIDI Protocol Coverage owner-surface block read as a visible PRIORITY QA MAP.

What connects creatively: Once a dashboard starts telling the truth about readiness, the next humane step is to tell the tester where to put their hands. Grouping remaining MIDI closeout work by owner surface turns the report from an audit into a practical path through the app: MIDI AUTO, Hardware Setup, import/export, SysEx, sync, and lane routing become places to visit, not abstract categories to remember.

Architecture choice: UI wording and emphasis only. The Protocol Coverage panel still uses the same model-owned priority order and blocker math; it simply labels and colors the surface checklist so the release-priority path is obvious onscreen. No MIDI routing, scoring, playback, import/export, SysEx, or hardware behavior changed.

Future extensions: This same QA-map block can become a guided release checklist, an internal beta-testing worksheet, or a clickable help surface that explains why each remaining MIDI family matters before launch.

2026-07-08 - Closeout Copy Should Tell The Tester What To Do

Task: Convert the MIDI Protocol Coverage category focus text from broad roadmap language into practical test instructions.

What connects creatively: A completion dashboard should lower uncertainty, not create a new interpretive chore. When the app says "MIDI AUTO remains," the useful next sentence is not a manifesto; it is a short map of what to touch, what to listen for, what to export/import, and what still belongs to the future. This turns the dashboard into a calm beta-testing companion.

Architecture choice: Wording/model only. The blocker categories, priority math, action surfaces, MIDI routing, import/export behavior, SysEx behavior, automation behavior, and hardware workflows remain unchanged. The focus strings now separate launch-grade verification from future architecture such as true clip/lane-local automation, draggable tangent handles, and full conductor timeline adoption.

Future extensions: Reuse the same test-driven language in guided QA mode, release checklists, support-bundle summaries, and any future "what should I test next?" assistant inside SpaceAge.

2026-07-08 - The Dashboard Should Name The Next Test

Task: Add an explicit Next test: line to the visible MIDI Protocol Coverage NEXT CLOSEOUT block.

What connects creatively: A musician testing MIDI should not have to translate audit language into a first move. The next action belongs onscreen because it lowers the mental cost of helping us finish the release. This is also the seed of a future guided QA mode: the app can quietly say, "touch this next," without becoming bossy.

Architecture choice: UI wording only. The panel still uses the same blocker categories, priority math, first-action model, action surfaces, and report payloads. The only change is that the top-priority blocker category's first action is promoted into the visible dashboard block. No MIDI behavior, routing, import/export, SysEx, automation, or hardware setup behavior changed.

Future extensions: Make the Next test: line clickable, allow testers to mark a step verified, and eventually generate a release QA checklist from the same model.

2026-07-08 - Important UI Copy Should Be Model-Owned

Task: Promote the MIDI Protocol Coverage Next test: sentence into the report model as nextCloseoutTestSummary().

What connects creatively: A helpful sentence becomes product architecture the moment more than one surface needs it. If the panel says one thing, the copied report says another, and a future guided QA mode invents a third version, the user starts hearing static. Model-owned copy keeps SpaceAge's guidance calm and internally consistent.

Architecture choice: Added one report-model helper and routed the visible Protocol Coverage panel, copied closeout text, plain-text protocol report, and structured payload through it. No MIDI routing, playback, import/export, SysEx, automation, Hardware Passport, or MIDI Learn behavior changed.

Future extensions: Use this method as the first item in a future guided MIDI QA checklist, and eventually attach a verified/unverified status to each generated next-test step.

2026-07-08 - Health And Protocol Should Share One Next Test

Task: Mirror the model-owned MIDI Protocol Coverage Next test: summary inside MIDI Health.

What connects creatively: MIDI Health is the cockpit and MIDI Protocol Coverage is the inspection report. If both are meant to guide the same release closeout work, they should not make the user reconcile two phrasings. One shared Next test: line makes the app feel like one calm navigator instead of two panels comparing notes across the room.

Architecture choice: UI/report wiring only. MIDI Health now draws a NEXT TEST row, copies the same line in its short next-steps report, and exposes it in the Health structured payload. No closeout priority math, MIDI routing, playback, SysEx, automation, Hardware Passport behavior, or MIDI Learn behavior changed.

Future extensions: Let FIX NEXT display this line in a pre-navigation confirmation, and eventually allow Health to mark individual next-test items as verified for release QA.

2026-07-08 - Safe Doors Should Preview The Same Test They Open

Task: Add the model-owned Next test: sentence to the MIDI Health FIX NEXT and MIDI Protocol Coverage OPEN NEXT tooltips.

What connects creatively: Tooltips are the moment before commitment. If a button opens a closeout surface, the user should know not only where the door goes, but what test they are about to perform. Matching that hover language to the visible cockpit/report language makes the button feel like a trusted guide instead of a mystery shortcut.

Architecture choice: Tooltip-only wiring. Both buttons still use the existing safe-door behavior: navigation only, no MIDI send, no routing changes, no project mutation, and no external hardware changes. The tooltip now reuses nextCloseoutTestSummary() instead of inventing separate wording.

Future extensions: Use the same sentence in a future pre-navigation callout, release-QA checklist row, or user-facing "help me finish MIDI setup" assistant.

2026-07-08 - Long Reports Need The Same First Move

Task: Put the model-owned MIDI Next test: sentence near the top of the full MIDI Health report.

What connects creatively: Long reports are for support, but the first human question is still "what should I try next?" Putting the next test near the header keeps a support/debug artifact from becoming a haystack.

Architecture choice: Report wording only. The full Health report now prints protocolCoverage.nextCloseoutTestSummary() before the long diagnostic sections. No protocol scoring, routing, MIDI send, import/export, SysEx, automation, or Hardware Passport behavior changed.

Future extensions: Use the same first-move line in support bundles and automated bug-report exports.

2026-07-08 - Guided QA Needs A Test And A Door

Task: Add a model-owned MIDI Next route: sentence beside the existing Next test: sentence.

What connects creatively: "What should I do?" and "where do I do it?" are different questions. A good closeout dashboard answers both without making the tester infer the route from a category name. This connects MIDI Health, Protocol Coverage, copied closeout reports, safe-door buttons, and the future guided QA system around a shared pair: the next action and the doorway to reach it.

Architecture choice: Added MidiProtocolCoverageReport::nextCloseoutRouteSummary() and reused it in MIDI Health, MIDI Protocol Coverage, copied reports, and structured payloads. This is guidance/reporting only; it does not send MIDI, change routing, mutate project data, alter closeout scoring, or touch external hardware.

Future extensions: Turn the test/route pair into a guided QA card with Open, Copy, Mark Verified, and evidence attachment actions.

2026-07-08 - Safety Copy Should Be Shared Until It Needs Domain Nouns

Task: Replace generic one-off MIDI safe-door tooltip wording with the shared navigation-only helper.

What connects creatively: Safety language is product infrastructure. A button that opens or refreshes a MIDI setup surface should not teach three subtly different versions of "nothing was sent." But package import and SysEx Vault actions need their own nouns because "no MIDI sent" is not enough; the user also needs "no stems imported," "no restore queued," or "no recall queued."

Architecture choice: Wording-only consolidation. Generic MIDI refresh/repair safe-door buttons now use buildMidiSafeDoorTooltip(). Package and SysEx safety copy remains custom where import/repair/restore/recall boundaries must be named. No MIDI routing, project mutation, SysEx restore, package import, or hardware queue behavior changed.

Future extensions: Add structured safetyClass and domainBoundary fields to closeout actions so buttons can render cold/warm/hot badges and specialized domain nouns from data instead of hardcoded prose.

2026-07-08 - Cold Warm Hot Should Become Data

Task: Add structured safety metadata to MIDI Protocol Coverage closeout actions.

What connects creatively: We have spent a lot of care making safety copy humane, but prose alone is brittle. Once safetyClass and domainBoundary exist as data, future panels can render badges, tooltips, confirmations, and support reports from one truth source. This connects the Protocol dashboard, MIDI Health, safe-door buttons, SysEx Vault, Hardware Passport, MIDI PATCH, package import, and future guided QA into one safety grammar.

Architecture choice: Added safetyClass, domainBoundary, and nextCloseoutSafetySummary() to the protocol coverage model. Health/Protocol visible panels, copied reports, and structured payloads now expose the same next safety summary. No MIDI send, routing, import/export, SysEx, automation, Hardware Passport, MIDI Learn, or hardware queue behavior changed.

Future extensions: Replace hand-authored safety strings in more MIDI actions with structured safetyClass, domainBoundary, and confirmedActionKind fields so the app can consistently draw cold/warm/hot badges and confirmation receipts.

2026-07-08 - Safety Maps Beat Safety Vibes

Task: Add a compact closeout safety class summary to MIDI Protocol Coverage.

What connects creatively: The user should never have to infer whether the next MIDI closeout step is harmless review, SpaceAge data mutation, or actual external-hardware contact. A COLD / WARM / HOT map turns that from a vibe into a small dashboard grammar. The same idea can later power badges on MIDI Setup, MIDI PATCH, SysEx Vault, Hardware Passport, import/export, and automation editors.

Architecture choice: Added a model-owned closeoutSafetyClassSummary() derived from active blocker categories. It now appears in MIDI Health, Protocol Coverage, copied closeout reports, Health reports, and structured payloads. No MIDI send, import/export, routing, Hardware Passport, SysEx, MIDI Learn, automation, or project mutation behavior changed.

Future extensions: Turn the safety classes into visual chips on action buttons and row cards, then make hot actions require a visibly different confirmation shape everywhere in the app.

2026-07-08 - Route Contracts Prevent Mystery Doors

Task: Add a route-contract summary to MIDI Protocol Coverage closeout actions.

What connects creatively: A safe door is only trustworthy if the app can say exactly where it goes. By making the next closeout route report both the user-facing label and the internal actionSurfaceId, future support/debug panels can catch mismatches before they become "I clicked this and the wrong thing opened" bugs. This connects MIDI Health, Protocol Coverage, Settings safe doors, import/export routing, SysEx Vault, Hardware Passport, MIDI PATCH, MIDI AUTO, and MIDI Maps under one breadcrumb grammar.

Architecture choice: Added nextCloseoutRouteContractSummary() to the protocol coverage model and exposed it in MIDI Health, Protocol Coverage, copied closeout reports, Health reports, and structured payloads. The change only improves diagnostics and visible guidance; it does not send MIDI, mutate project data, import/export files, recall SysEx, or change routing.

Future extensions: Add automated assertions that every active blocker category with an actionSurfaceId has a live UI route, a safe-door tooltip, and a cold/warm/hot boundary before release builds.

2026-07-08 - Audit the Doors Before Customers Do

Task: Add a closeout route audit summary to MIDI Protocol Coverage.

What connects creatively: A route contract is useful, but an audit is more powerful: it lets the app inspect its own closeout map and complain if a blocker category lacks a label, destination surface, safety class, or boundary. That means future MIDI work can add routes with confidence instead of relying on memory. The same self-auditing pattern can eventually protect Instrument Bay routes, effect editors, render workflows, and hardware setup flows.

Architecture choice: Added closeoutRouteAuditSummary() to the protocol coverage model and exposed it in MIDI Health, Protocol Coverage, copied reports, Health reports, and structured payloads. No behavior changed; this is release-readiness diagnostics only.

Future extensions: Upgrade the audit from report text into a debug/test assertion that fails internal QA if a route-capable blocker is missing safety metadata or a real UI destination.

2026-07-08 - QA Checks Should Be First-Class Data

Task: Add structured QA checks to MIDI Protocol Coverage blocker categories.

What connects creatively: The closer we get to release, the less useful "do MIDI polish" becomes. Each closeout category now carries concrete test prompts, so the app can guide a human tester through the next meaningful action without reading a novel. This connects MIDI AUTO, Hardware Passport, import/export, SysEx, MIDI Learn, MIDI PATCH, Hardware Setup, and future conductor timelines into a single QA rhythm.

Architecture choice: Added qaChecks to MidiProtocolBlockerCategory, populated it from blocker-category metadata, serialized it, printed it in copied protocol reports, and surfaced nextCloseoutQaSummary() in MIDI Health and Protocol Coverage. No MIDI behavior changed.

Future extensions: Convert these QA checks into click-to-run/manual checklist rows with pass/fail notes, timestamps, evidence receipts, and optional hardware/device tags.

2026-07-08 - QA Needs Its Own Copyable Ladder

Task: Add a standalone current MIDI closeout QA checklist.

What connects creatively: A next-step sentence is useful for momentum, but a release pass needs a ladder. The same category-owned QA data now composes a dedicated checklist that can be copied, reviewed, and later converted into an interactive pass/fail test surface.

Architecture choice: Added currentFinishLineQaChecklist() beside the existing closeout and surface checklists, then wired it into MIDI Protocol reports, copied closeout notes, and structured payloads. The checklist is generated from the same blocker-category metadata, so the text cannot drift away from the product-readiness model.

Future extensions: Add persistent QA state per checklist row: untested, pass, fail, blocked, evidence note, hardware profile, and date.

2026-07-08 - QA Should Be Visible, Not Merely Copyable

Task: Surface the current MIDI closeout QA checklist inside the MIDI Protocol popup.

What connects creatively: The app is starting to teach its own testing discipline. A visible QA card turns the protocol panel from a passive scorecard into a small release cockpit: the user can see what to test next, copy the complete closeout when needed, and still jump to the relevant work surface.

Architecture choice: Reused currentFinishLineQaChecklist() rather than creating separate UI-only text. The visible card truncates to a compact preview, while COPY CLOSEOUT keeps the full checklist. The protocol panel hit-test and scroll area were corrected to match the actual painted layout after the new cards.

Future extensions: Promote each QA line into an interactive checklist row with pass/fail state, evidence notes, and optional hardware/profile tags.

2026-07-08 - QA Needs a Fast Clipboard Path

Task: Add a standalone COPY QA action to MIDI Protocol Coverage.

What connects creatively: A full closeout report is useful for release notes, but testers often need only the next practical checklist. Separating COPY QA from COPY CLOSEOUT keeps the panel fast for human testing: one button copies the short ladder, while the larger closeout copy remains available for complete audit trails.

Architecture choice: Reused currentFinishLineQaChecklist() and nextCloseoutQaSummary() directly in the MIDI Protocol panel. The new action is explicitly cold-copy only: it copies text and does not send MIDI, change routing, mutate project data, or touch external hardware.

Future extensions: Turn COPY QA into an interactive QA session export once checklist rows gain pass/fail state, evidence notes, and hardware-profile tags.

2026-07-08 - QA Sessions Should Be Paste-Ready

Task: Render MIDI closeout QA as a checkbox session template.

What connects creatively: Testers should not have to transform a prose checklist into something they can use. The same QA data now renders as a paste-ready session with owner surface, safety boundary, checkboxes, result status, and evidence notes. This bridges today's copied reports with tomorrow's in-app pass/fail tracker.

Architecture choice: Added currentFinishLineQaSessionTemplate() to the MIDI protocol report model and wired COPY QA to that output. The visible QA card stays compact, while the clipboard output becomes directly useful for manual testing.

Future extensions: Persist these fields inside SpaceAge so each MIDI closeout category can carry tested/pass/fail/blocked status, hardware profile, date, and evidence text.

2026-07-08 - QA Session Data Should Travel With Reports

Task: Add the paste-ready MIDI QA session template to plain-text and structured protocol reports.

What connects creatively: A QA template should not live only behind a button. By putting the same session output into copied reports and structured payloads, support docs, future internal debug exports, and eventual in-app QA widgets can all point to the same source of truth.

Architecture choice: Exposed currentFinishLineQaSessionTemplate() through toPlainTextReport() and toVar(). This keeps the clipboard action, protocol report, and machine-readable payload aligned without adding persistent state prematurely.

Future extensions: Replace the template text with structured QA row objects once pass/fail/blocked/evidence state becomes project data.

2026-07-08 - QA State Needs Stable Names Before Memory

Task: Add stable QA session ids to MIDI protocol blocker categories.

What connects creatively: A visible checklist can help today, but saved QA state needs durable names or it becomes fragile. If a category display label changes from "MIDI AUTO Final Editor" to something friendlier later, we still need existing pass/fail/evidence state to attach to the same conceptual test group. Stable ids are the little name tags underneath the costume.

Architecture choice: Added qaSessionId to MidiProtocolBlockerCategory, populated it through explicit category metadata, serialized it through toVar(), and printed it in QA session/report text. No QA state is saved yet; this only prepares the model for that future step.

Future extensions: Use qaSessionId as the key for persistent QA rows, release gates, hardware evidence attachments, and regression-test history.

2026-07-08 - Option B: Lane-Owned Instruments + Mixer-Owned Effects

The important connection is that lane-owned instruments, mixer-owned effects, automation, rendering stems, and future Instrument Bay browsing are all the same architectural story. If a melodic lane owns a Redshift instance, then its patch, MIDI route, automation targets, mixer channel, ghost-note identity, and rendered stem name should all point to the same lane-owned object. That makes the product easier to explain: a lane is a performer, the mixer is its signal path, and clips are the phrases it plays.

Removing effects from synth patch pages also clarifies future preset browsing. A synth preset should answer, "What is this instrument sound?" A channel strip or effect rack preset should answer, "How is this sound processed in the mix?" Keeping those separate lets us later build scenes, orchestration swaps, stem rendering, school-friendly templates, and AI patch suggestions without confusing tone design with mix decisions.

Drums remain a special case on purpose. The Drum Composer is a pad-performance instrument, so its relationship to pad banks is musically meaningful. The mistake to avoid is letting that pad logic leak into bass, harmony, melody, SoundFont, Quasar, or other lane-driven instruments.

2026-07-08 - MIDI Recording Should Follow the Lane, Not the Controller

Incoming MIDI is not automatically meaningful just because it carries a channel number. A controller might transmit everything on channel 1, while the musician intends the armed bass lane to play/export on channel 6 or a hardware synth lane to speak to channel 12. Recording notes and MIDI AUTO data through the armed lane keeps the user's visible workflow honest: choose the lane, arm it, play, and SpaceAge stores the performance as belonging to that lane.

The creative payoff is bigger than a technical channel fix. Lane-owned recording connects live performance, ghost notes, automation lanes, hardware routing, stem rendering, and future scenes/orchestration swaps into one coherent model. The controller is just the hands; the lane is the performer.

Future MIDI work should keep testing for this distinction. Any new MIDI pathway should ask: is this raw source evidence, or should it be normalized through the lane's destination policy before becoming musical project data?

2026-07-08 - MIDI Latency Needs Evidence, Not Guesswork

The live-input audit shows that incoming notes and expression are scheduled at their in-block sample positions rather than intentionally delayed until the next block. That matters because perceived MIDI lag can come from several places: audio buffer size, Windows driver mode, controller transport, direct hardware input routing, internal voice startup, or monitoring path. Treating all of that as one vague "MIDI is late" complaint would send us chasing the wrong ghosts.

The product connection is a future calibration ritual. MIDI Timing, MIDI IN readiness, Hardware Passports, live recording, and the eventual onboarding assistant can share a plain process: play a test pulse, measure or listen, apply compensation if needed, and preserve the evidence. That turns a technical anxiety into a guided setup experience.

Architecturally, SpaceAge should keep sample-position timing intact in every live MIDI path and avoid adding UI-thread or worker-thread dependencies before sound generation. If the user still feels lag, the next fix should be measurement and configuration, not random offsets buried in playback code.

2026-07-08 - Direct MIDI Input Needs A Visible Timing Boundary

Direct physical MIDI input is valuable because it preserves the identity of the actual controller, which host/plugin MIDI often flattens away. That identity matters for lane-specific hardware setups, MIDI guitars, wind controllers, SysEx workflows, and Hardware Passports. The tradeoff is timing: the direct callback bridge timestamps messages and drains them into the audio block, while host/plugin MIDI already arrives with native in-block offsets.

The creative product move is to be honest instead of mysterious. MIDI Input should say when direct physical input is active and should tell the musician what to compare: HOST ONLY versus DIRECT ONLY, audio buffer size, driver mode, and timing calibration. If one path feels tighter than the other, that is useful evidence rather than a vague complaint.

Architecture choice: put the explanation in MidiInputReadinessReport::directInputTimingNote, then render and serialize it from the same report model used by the visible MIDI Input panel. Do not bury a compensating offset in the direct-input router unless measured hardware evidence proves a stable offset for a specific device/profile path.

Follow-up: direct queue-age stats should be treated as evidence, not blame. Average/max queue age can tell us whether SpaceAge-opened physical input is waiting unexpectedly before the audio block sees it, but the app should avoid scary warnings until real hardware tests prove useful thresholds. The broader product idea is a future MIDI Rig Doctor flow: play a note, let SpaceAge observe host/direct/sync paths, then explain whether the issue is duplicate routing, audio buffer size, stale voice preparation, hardware echo, or actual direct-input queue delay.

2026-07-08 - MIDI AUTO Scope Labels Are Safety Rails

Pattern-owned automation is powerful, but it can surprise users if a shared PTN is reused in several Arrangement clips. The scope label is therefore not decorative copy. It is a safety rail that tells the musician whether they are editing one placed clip, an unplaced pattern, or every linked clip that shares the same PTN.

The useful connection is with VARIANT, Arrangement clips, future automation lanes, and eventual collaboration workflows. A collaborator looking at a copied MIDI AUTO report should see the same ownership story as the person looking at the panel. That consistency helps prevent accidental global edits while preserving the speed benefit of intentionally shared patterns.

2026-07-08 - MIDI Safety Copy Must Not Drift

When a MIDI panel says an action is warm, cold, or hot, every visible copy surface needs to tell the same risk story. A status line that says "no MIDI was sent" while the receipt says "no MIDI, no routing, no external hardware" creates tiny uncertainty at exactly the moment the user is deciding whether to trust the app around external gear.

The practical design connection is that safety language is part of the interaction model, not decoration. MIDI PATCH, MIDI AUTO, Hardware Passport, SysEx Vault, and future hardware assistants should keep using shared helpers or shared phrases wherever possible, with special cases called out only when the action genuinely changes routing metadata or can touch external hardware after confirmation.

2026-07-08 - Unknown Should Mean Truly Unknown

MIDI's older hardware messages are easy to ignore because modern beatmaking rarely asks a user to think about Tune Request or System Reset. But for SpaceAge, especially with Hardware Passports, SysEx, sync, and school/hardware workflows, these messages need names. A musician should not see "Unknown" when the app actually knows the byte and simply failed to classify it.

The useful split is safety-based: Tune Request behaves like system/sync context that should not become musical clip data, while System Reset is a protected setup message that should never be fired casually at external hardware. This keeps old hardware dialects compatible with the same cold/warm/hot trust language used by MIDI AUTO, MIDI PATCH, and the SysEx Vault.

The runtime monitor should follow that same split. If a user opens MIDI Sync Preflight while an old synth is talking, Tune Request and System Reset deserve a named row, not a mystery count. The creative connection is trust: SpaceAge can be friendly to vintage gear precisely because it names strange old messages while keeping dangerous messages out of casual playback.

2026-07-08 - Progress Reports Should Belong To The Product

When the MIDI implementation is this large, a status report should not depend on whoever happens to be explaining it. SpaceAge should own the distinction between backend protocol plumbing, dashboard-family completion, customer-facing closeout, real-hardware validation, and deferred future protocols.

The creative connection is customer confidence. A musician does not need a dissertation every time they open MIDI Health, but they do need a stable truth sentence: what works, what is still being polished, what is next, and what must not be marketed yet. That same compact summary can feed the Health panel, copied support reports, QA checklists, and eventually release notes.

2026-07-08 - Automation Reports Should Say What Kind Of Automation

MIDI AUTO can hold very different kinds of MIDI truth. A CC curve for filter motion is performance automation; pitch bend and pressure are expressive playing; sustain is a switch/block gesture; Program Change, Bank Select, RPN/NRPN, and Data Entry are setup or recall evidence. Counting all of these as one generic pile of "lanes" hides the user's real task.

The creative product move is to report the difference. A musician should know whether a project contains playable controller movement, switch gestures, pressure/bend expression, or hardware setup rows before deciding whether to draw, thin, copy, export, or open a hardware review panel. This same distinction can eventually drive icons, colors, filters, and guided QA in MIDI AUTO without changing the underlying MIDI data.

2026-07-08 - Editor Readiness Should Be Counted Against Real Lanes

A blocker like "MIDI AUTO Final Editor" can sound abstract unless the product says how many lanes already have an editor and how many still need launch polish. Counting first-pass editor lanes, launch-polish lanes, curve-capable lanes, and preview-transform-ready lanes turns the closeout from a vibe into a checklist.

The creative connection is future guided QA. Once SpaceAge can say, "This project has 4 curve lanes, 1 switch lane, and 2 launch-polish lanes," it can also guide the tester to the exact lanes that need draw/copy/paste/undo/playback/export validation. That same structure can later power release-gate checklists, support exports, and maybe a friendly MIDI Rig Doctor.

2026-07-08 - Pattern Reports Should Match Project Reports

If MIDI Health says a project has controller lanes, setup rows, and launch-polish lanes, the copied MIDI AUTO report for a specific pattern should use the same words. Otherwise the user gets two dialects for the same feature and starts wondering whether "expression," "automation," "controller," and "setup" are secretly different systems.

The useful connection is support and beta testing. A copied pattern report can now be pasted into a bug note and still tell us what kind of lane the tester touched, what kind of editor surface existed, and whether the issue belonged to performance automation or setup recall evidence. That makes debugging less like reading tea leaves and more like reading a flight recorder.

2026-07-08 - Pitch Bend Trust Is Not One Boolean

Pitch bend is a perfect example of why MIDI reports must be precise. SpaceAge can preserve raw 14-bit bend data perfectly and still be unable to promise the musical interval an external synth will play. Trust depends on context: is the pattern placed on a lane, does it feed one lane or several, is the lane internal or hardware-routed, does the Hardware Passport exist, is a +/- range declared, and has TEST BEND/manual verification happened?

The creative connection is future hardware confidence. Instead of showing a scary generic warning, SpaceAge can say exactly which trust piece is missing. That can become a guided ritual: attach Passport, declare range, run TEST BEND, verify by ear, then let exported reports and MIDI AUTO badges say the bend range is trusted.

2026-07-08 - Route Proof Should Be Visible, Not Implied

A button that opens the exact panel a tester needs is different from a button that opens a nearby page and expects the tester to follow instructions. Both can be useful, but they should not be reported as the same thing. A direct opener is a stronger promise; a breadcrumb route is a human workflow cue; a status-only row is a roadmap fact; an unwired route is unfinished work.

The product connection is release discipline. SpaceAge can keep a friendly, simple UI while still giving beta testers and support reports the sharper truth underneath: direct, breadcrumb, statusOnly, or unwired. This prevents the dashboard from overclaiming, and it gives future guided-QA tools a clean way to decide whether to open a panel, show instructions, or flag missing UI.

2026-07-08 - Hardware Proof Counts Belong Beside The Category

External hardware validation is not just a row-level detail. If a blocker category contains several rows that need a real synth, controller, interface, host, or imported file to prove the behavior, the category itself should say that. Otherwise a tester can open a QA checklist, see a friendly category name, and miss that the work requires listening, device response, test phrase, or manual verification.

The product connection is future beta discipline. A QA session can now distinguish "this category is mostly UI polish" from "this category needs real hardware time." That lets SpaceAge route human attention better: software-only closeout can move quickly, while hardware-proof categories can be batched for a deliberate studio test pass.

2026-07-08 - Hardware Passport Must Stay The Mental Model

Older docs used "hardware profile" as the generic engineering phrase. That is technically understandable, but it competes with the stronger product language: Hardware Passport. A Passport sounds like a trusted identity document for an external synth, controller, or module, which is exactly the role it plays when SpaceAge needs channel, bend-range, SysEx, timing, and setup evidence.

The creative connection is onboarding. If every customer-facing report says Hardware Passport, then MIDI Setup, SysEx Vault, MIDI PATCH, MIDI Timing, Instrument Bay, and future Scenes all feel like they are using one shared hardware identity system rather than several unrelated MIDI utilities.

2026-07-09 - Emergency MIDI Is The One Honest Exception

Most hardware-changing MIDI actions should be confirmation-gated: Program/Bank recall, SysEx restore, setup-card sends, pitch-bend tests, and timing pulse trains. PANIC is different. It is an emergency exit, so asking for confirmation would make the rescue slower and less trustworthy when a user is trying to stop a stuck note or runaway external device.

The product rule is therefore clear: PANIC may immediately send reset/all-notes-off style MIDI to open hardware outputs, but the UI and docs must say so plainly. Timing pulses are not emergency behavior, so they now use the same backend confirmation boundary as other hot hardware sends.

The creative connection is confidence. SpaceAge can be strict about accidental hardware changes without becoming timid about recovery. A future hardware safety panel can distinguish "confirmed setup/recall send" from "emergency panic broadcast" and keep both behaviors honest.

2026-07-09 - MIDI Sync Needs A Verdict, Not Just Counters

MIDI Clock, SPP, MTC, MMC, Active Sense, and transport messages are easy to count but hard for a musician to interpret quickly. A panel that says "Clock 32" is technically useful, but the practical question is, "Is SpaceAge actually following the hardware, or is it just seeing traffic?"

The useful product connection is a compact trust verdict paired with a next action. ALIVE ONLY means the device is talking but not sending timing, OBSERVED BUT BLOCKED means timing arrived but policy refused it, and FOLLOWING means SpaceAge applied tempo-follow or chase behavior. That same verdict can later power a MIDI Rig Doctor flow: plug in hardware, play/send sync, and let SpaceAge explain the next setup move without forcing the user to decode raw protocol counters.

2026-07-09 - MIDI AUTO Needs Lane-Level Honesty

Category-level progress is useful, but MIDI AUTO is made of many lane personalities: pitch bend, sustain, CC curves, pressure, poly pressure, and review-only setup evidence. A single "MIDI AUTO is almost done" label hides too much. Each lane should be able to answer three questions: what can I do now, what remains polish or future architecture, and who owns the data?

The creative connection is user trust. A pitch-bend lane can be usable today as raw 14-bit musical gesture data while still needing destination bend-range contracts before external hardware slides are trusted. A sustain lane can already behave like switch blocks while future clip/lane-local automation remains a roadmap item. A review-only Program/Bank/RPN row can be preserved and exported without becoming a drawable curve. This lets SpaceAge be ambitious without sounding slippery.

The product pattern should repeat elsewhere: Instrument Bay lanes, future automation clips, Motion Clips, Hardware Passports, and SysEx Vault entries should all expose a compact "usable now / remaining polish / ownership" truth when the object is selected or copied into a report.

2026-07-09 - MIDI AUTO Needs A Next Test, Not A Vague Remaining Work Blob

When a report says "MIDI AUTO has launch polish remaining," the user still has to decide where to click. A better report names the next useful test from the data in the project: run TEST BEND, attach a Hardware Passport, test switch-block editing, test pressure playback, apply a curve preview, or draw/export a controller lane.

The creative connection is guided beta testing. A user with a project full of sustain blocks should not receive the same next step as a user with hardware pitch bends or review-only Program Change rows. The app can become a quiet QA assistant by ranking what matters next and saying it plainly.

This same pattern should later help Instrument Bay, Effects, Quasar, Motion Clips, and hardware setup: every complex subsystem should be able to produce one next sensible test based on what actually exists in the session.

2026-07-09 - Export Readiness Should Point To The Handoff Test

An export report that says "ready" can accidentally sound like the outside world has already agreed. That is not true. SpaceAge can prove that it gathered MIDI material, wrote channels, included tempo/key context, and preserved MIDI AUTO data; it cannot prove another DAW, hardware sequencer, or collaborator's synth will interpret that material musically until the export is opened and auditioned.

The creative product connection is collaborator trust. The export surface should always suggest the next useful handoff test: add material if empty, review bend trust if slides are present, resolve warnings, export Arrangement plus stems, or re-open a selected clip/pattern to verify channel, timing, notes, chords, and automation.

This same "handoff test" grammar will matter for Quasar packages, SoundFont dependencies, archive projects, rendered stems, SysEx dumps, and future scenes. A portable file is not finished when it exists; it is finished when the receiving context can make sense of it.

2026-07-09 - Pitch Bend Trust Needs A Model Field

Pitch bend is not just another automation curve. The curve itself is raw 14-bit MIDI data, but the musical distance of that curve belongs to the destination: internal synth range, SoundFont response, hardware RPN setup, or an external synth's own bend-range setting. If that truth only lives in paragraphs, future UI work can accidentally flatten it into a misleading "safe" badge.

The product connection is structured trust. MIDI AUTO lane summaries now expose a pitchBendTrustLabel field so panels, exports, copied reports, support payloads, and future QA tools can all read the same verdict instead of re-parsing prose. The user should be able to see the ladder: raw preserved, destination known, Hardware Passport attached, +/- range declared, TEST BEND/manual verification accepted.

Future extensions should turn this into an actual playback/export gate for external hardware slides. Until then, the model field keeps the promise honest: SpaceAge can preserve bend data, but it must not pretend an external synth's semitone width is trusted until the lane, Passport, declared range, and evidence agree.

2026-07-09 - Missions Should Say What Proof Counts

A next-action line that says where to click is useful, but hardware workflows need one more promise: what kind of proof will make the test meaningful. TEST BEND listening, device ACK/NAK, loopback timing, test phrases, and manual verification are different kinds of evidence, and a tester should not have to infer which one is needed.

The product connection is guided QA. Next MIDI mission now carries hardware-proof cue text when the active closeout category requires real-world validation. This keeps Protocol Coverage, MIDI Health, SysEx, Hardware Passport, MIDI AUTO, and future Rig Doctor flows using the same evidence ladder instead of treating all tests as equal.

Future extensions should let the mission line deep-link to the exact proof capture step: run TEST BEND, arm SysEx response capture, start loopback timing, play a test phrase, or record manual verification.

2026-07-09 - Short Copies Must Not Lose Trust Language

Full reports are useful for deep audits, but testers often press the shortest button that gives them something pasteable. If COPY QA drops the mission line while COPY REPORT keeps it, the shortest path becomes the least safe path.

The product connection is consistency under pressure. The short Protocol Coverage copy actions now include the same Next MIDI mission line as the full report, so hardware-proof evidence requirements survive whether the tester copies a full audit, a closeout checklist, or a focused QA session.

The same rule should apply to future copy buttons in Quasar, Instrument Bay, SysEx Vault, Hardware Setup, Render, and Archive: compact reports may omit detail, but they must never omit safety boundaries, proof requirements, or the next meaningful test.

2026-07-09 - Health Payloads Need The Same Mission Truth

Visible text is only half the product. Once SpaceAge has Settings cards, support exports, QA tools, and maybe a future in-app assistant, those surfaces will often read structured health payloads instead of scraping the visible report.

The connection is simple: if MIDI Health can show next test, route, safety, and QA summaries but not the unified Next MIDI mission, future UI can accidentally become less precise than the source report. The health model now exposes nextCloseoutMissionSummary directly, keeping hardware-proof language available to any future panel that wants to guide the user.

The broader pattern is worth preserving: every major subsystem should have one model-owned "next meaningful action" field that is safe to display, copy, log, and hand to support without reinterpretation.

2026-07-09 - Short Status Lines Need Proof Cues Too

Long reports can carry nuance, but users often trust the short status line first. If the short line says only that hardware-proof rows exist, the user still has to open deeper reports to understand what kind of evidence matters.

The product connection is glanceable honesty. MIDI status: now carries the first concrete evidence cue for the next closeout category when hardware proof is required. That gives the quick dashboard, structured health payload, copied reports, and future assistant-style UI the same practical next clue: listen to TEST BEND, capture device response, run loopback, play a test phrase, or record manual verification.

This same approach should apply to future complex systems: Render, Quasar, Instrument Bay, Scene recall, and Archive should all let their short status strings name the first proof cue instead of forcing the user into a long report for basic confidence.

2026-07-09 - Health Reports Need The Mission Above The Fold

Long diagnostic reports are excellent for support, but the first screen still needs to answer the user's practical question: what should I test next? If Next MIDI mission only appears later inside a nested Protocol Coverage section, a tester can miss the most important instruction.

The product connection is "above the fold" confidence. The Health report now repeats the model-owned mission line in its top closeout block, directly beside route, safety, QA, and hardware evidence summaries. It is deliberately redundant in the way a cockpit is redundant: the same critical truth appears anywhere a user might reasonably look first.

This pattern should eventually shape Render, Archive, Instrument Bay, and hardware recall reports. If a subsystem has a next meaningful action or a proof requirement, show it near the top and again in the deeper report where all the details live.

2026-07-09 - Evidence Cues Should Be Structured, Not Scraped

If a UI card needs to show the first hardware-proof cue, it should not have to parse a paragraph looking for the phrase after "First evidence cue:". String scraping is fragile, and it makes future panels depend on copywriting instead of model truth.

The product connection is clean extensibility. Protocol Coverage and MIDI Health now expose nextCloseoutFirstHardwareEvidenceCue as a model field. A future Settings card, QA checklist, support export, or in-app assistant can show the cue directly while the prose remains free to become more human.

This is a general SpaceAge rule worth preserving: user-facing prose can be beautiful, but workflow decisions should read structured fields. Instrument Bay, Quasar, Render, Archive, Scenes, and Hardware Passports should all follow that split.

2026-07-09 - Cockpit Buttons Should Not Walk Category Arrays

The Protocol Coverage category array is excellent for detailed checklists, but a top-level cockpit should not have to hunt through it just to know which button to light up next. That kind of code becomes brittle as categories are renamed, reordered, or grouped differently.

The product connection is clean navigation. MIDI Health and Protocol Coverage now expose the next closeout category, action surface id, action label, route kind, safety class, and first hardware evidence cue as direct model fields. A Settings card can now say "Open MIDI AUTO", show WARM/HOT/COLD context, and name the proof cue from one stable payload.

This pattern should guide Instrument Bay, Render, Archive, Quasar, and Effects: detail arrays are for lists; cockpit fields are for immediate action.

2026-07-09 - A Button Needs A Route Verdict

An action label like "Open MIDI AUTO" is not enough by itself. A cockpit button also needs to know whether the app can truly open the target directly, whether it is only a breadcrumb path, whether it is a status-only roadmap row, or whether the route is unwired.

The product connection is avoiding false affordances. MIDI Health and Protocol Coverage now expose nextCloseoutRouteProofStatus and nextCloseoutActionIsDirectOpenable. The UI can show a real button for direct routes, a guided breadcrumb for menu paths, a status badge for roadmap items, and a repair warning for unwired categories.

This should become a house pattern for SpaceAge: every "go do this next" card needs a route verdict before it becomes clickable.

2026-07-09 - Cockpit UI Should Consume Cockpit Fields

It is not enough to create structured fields if the interface keeps deriving its own answer from lower-level lists. That recreates two truths: the report says one next action, while the button may light up based on an older category walk.

The product connection is trust under iteration. MIDI Health FIX NEXT and MIDI Protocol Coverage OPEN NEXT now consume the same model-owned next-action surface, direct-open verdict, category, route proof, and first evidence cue that copied reports expose. If the MIDI closeout model changes, the button and the report move together.

This is a useful rule for the rest of SpaceAge: Instrument Bay, Render, Quasar, Archive, Scenes, and Hardware Passports should not let visible controls re-infer workflow state when a cockpit field already exists.

2026-07-09 - Direct Open Is Not The Same As Safe Door

Direct-openable means the app can launch the exact target panel. Safe-door-openable is a little broader: it includes direct panels plus breadcrumb routes that safely open the nearest page and tell the user where to go next. Those two concepts were briefly living as UI logic, which is dangerous because a later panel could interpret the same route differently.

The product connection is honest guidance. MIDI Protocol Coverage now owns both truths: nextCloseoutActionIsDirectOpenable and nextCloseoutActionIsSafeDoorOpenable. Rows also expose actionIsSafeDoorOpenable. The UI can offer a click for direct and breadcrumb routes while still reporting the route proof honestly.

This distinction will matter outside MIDI. Render might have a direct export dialog or only a breadcrumb to Library; Instrument Bay might open the exact synth or only a lane selector; Quasar might reveal a package or only show instructions. The route truth belongs in the model.

2026-07-09 - Copied Reports Need The Same Door Verdict

Structured payload fields help the interface, but copied reports are often what a tester, support helper, or future assistant will read first. If the copied text says only proof=breadcrumb, the human still has to know the house rule that breadcrumbs are safe openers while status-only routes are not.

The product connection is portable clarity. MIDI route-contract text now prints directOpenable and safeDoorOpenable beside label, surface, route, proof, safety, category, and boundary. A pasted report can explain whether the next button should be a direct jump, a safe breadcrumb, or a non-clickable status item without borrowing hidden UI logic.

The same pattern should shape future subsystem reports. If Render, Instrument Bay, Quasar, Scenes, or Hardware Recall can open a target, their copied reports should say whether the route is exact, guided, or informational.

2026-07-09 - Rows Need Their Own Door Verdict

Top-level cockpit fields are not enough when a user is reading a long protocol-family report. Each row has its own route, proof, safety class, and hardware boundary, so each row should also say whether it is directly openable, safely openable through a breadcrumb, or only informational.

The product connection is per-row confidence. MIDI protocol-family rows now expose actionIsDirectOpenable and actionIsSafeDoorOpenable in structured payloads, and the plain report prints a compact route-openability line for every family. This means future sortable tables, support exports, and assistant-style guidance can use the same route verdict without rediscovering the rules.

This will matter when MIDI grows more visual. A future table might gray out status-only roadmap rows, show a guided arrow for breadcrumb rows, and show a strong button for direct panels. The row model now carries enough truth to do that cleanly.

2026-07-09 - Categories Need The Door Verdict Too

Blocker categories are the layer a human tester is most likely to act on: "MIDI AUTO Final Editor", "Hardware Bend Range", "Import Wizard", and so on. If rows and cockpit buttons know their route truth but the category summary does not, the report still forces the tester to jump between levels.

The product connection is continuity. MIDI blocker categories now expose direct/safe-door openability, and the category summary, QA checklist, QA session template, and structured category payload all carry that verdict. A tester can read the category header and know whether to click a direct panel, follow a breadcrumb, or treat the row as informational.

This pattern is larger than MIDI. Future Render, Instrument Bay, Quasar, Archive, and Scenes reports should let each group summary inherit the most important actionability truth from its child rows instead of hiding it in detail tables.

2026-07-09 - Audits Should Count Doors, Not Just Routes

Route metadata tells us what kind of path exists, but a tester wants a simpler answer: can I click this, can I safely follow a breadcrumb, or is this only informational? Counting direct panels and breadcrumbs is useful, but counting openable routes is what prevents false affordances.

The product connection is closeout triage. MIDI route audits now count direct-openable, safe-door-openable, and non-openable blocker categories. The critical path and closeout checklist also repeat the next action's openability verdict. This makes the shortest summaries usable without cross-reading the full protocol-family table.

The same logic belongs in future QA dashboards. Render, Archive, Instrument Bay, Quasar, Scenes, and Hardware Recall should count actionable doors separately from descriptive rows so we do not mistake documentation for workflow.

2026-07-09 - Owner Surface Maps Need Door Truth

The owner-surface map is where a tester decides where to put their hands next: MIDI AUTO, Hardware Passport, Import Wizard, SysEx Vault, and so on. If that map says "Test/fix in MIDI AUTO" but does not say whether MIDI AUTO is a direct opener or a breadcrumb, it leaves one small but annoying gap between instruction and action.

The product connection is ergonomic QA. The MIDI owner-surface checklist now includes route-openability beside each category. The map still groups work by where it happens, but it also tells the tester whether that surface can be opened directly, safely guided, or only reviewed as status.

This same shape could help broader SpaceAge navigation. A future "What needs attention?" view should group tasks by page or device, but every grouped task should carry its actionability verdict so the user never has to guess whether a row is clickable.

2026-07-09 - MIDI Safety Needs One Sentence

Every customer-facing MIDI action should be able to answer, in one sentence, whether it is cold, warm, or hot, what boundary it crosses, and whether the user can actually open it. That sentence can later become a tooltip, QA receipt line, manual row, or warning-dialog subtitle without rewriting the safety logic four different ways.

2026-07-09 - The Next Action Needs The Same Safety Sentence

A category-level safety sentence is useful, but the cockpit needs the next one without asking the UI to rummage through category lists. MIDI Protocol Coverage and MIDI Health now expose nextCloseoutSafetyBoundarySummary as a first-class next-action field. The product connection is that the visible "do this next" button can show the same safety truth as copied QA reports, avoiding separate interpretations of whether a click is cold, warm, or hot.

2026-07-09 - The UI Should Read The Richer Contract

Once a richer model field exists, the visible UI should consume it immediately. Otherwise the system has two truths: structured data knows the boundary, while the panel still shows a shorter legacy phrase. MIDI Health and Protocol Coverage now display the same next-action safety-boundary sentence that the structured payload exposes, including in tooltips and copied closeout text.

2026-07-09 - Copied Diagnostics Must Not Lose The Contract

The user often sees copied text long after the app state has moved on. That means copied MIDI diagnostics need the same safety contract as the live dashboard. MIDI Health and Protocol Coverage plain-text reports now carry Safety boundary: class=..., so a pasted report still says whether the next action is cold, warm, or hot and what it can touch.

2026-07-09 - QA Evidence Needs A Single Capture Line

A QA checklist without a proof target can still become vague: the tester knows what to click, but not what kind of evidence makes the row truly done. Each MIDI blocker category now has a compact evidence-capture sentence with the stable session id, PASS/FAIL/BLOCKED result vocabulary, expected proof types, and the same safety boundary used by the UI.

The product connection is larger than MIDI. Render, Archive, Instrument Bay, Quasar, Hardware Recall, and Scenes should eventually expose one evidence sentence per closeout category so a tester, support person, or future assistant can tell what counts as a real pass without reading the source code.

2026-07-09 - The Cockpit Needs The Next Evidence Target

Once every blocker category owns an evidence-capture sentence, the cockpit should expose the next one directly. Otherwise the user sees "NEXT QA" but still has to open the full QA template to know what counts as proof. MIDI Health and Protocol Coverage now have nextCloseoutQaEvidenceCaptureSummary, and the visible/copy/report paths carry it beside next route, safety, hardware evidence, and mission text.

The product pattern is a good one: every future closeout dashboard should show the next test, the next route, the next safety boundary, and the next evidence target. That quartet turns a vague progress meter into a practical workbench.

2026-07-09 - The Mission Sentence Should Be Self-Contained

The shortest instruction is the one most likely to be read under fatigue. Next MIDI mission now embeds the same evidence target as the QA template, so the top-level sentence says what to open, what to test, what proof to capture, and what safety boundary applies.

This is a design principle worth keeping: every "next mission" line in SpaceAge should be independently useful. A user or tester should not need to cross-reference a second panel to know what success means.

2026-07-09 - Working Lists Need Proof Targets Too

Compact closeout lists are often more useful than giant reports, but only if they do not strip away the proof contract. The MIDI critical path, closeout checklist, and owner-surface checklist now repeat the QA evidence target beside route-openability.

This makes each list independently actionable: where to go, whether the route is openable, what to do first, and what evidence counts. The same habit should guide future Render, Quasar, Instrument Bay, and hardware recall closeout panels.

2026-07-09 - QA State Needs A Stable Storage Key

Evidence text is useful for humans, but persistent QA needs a stable address. MIDI closeout categories now expose a storage-style key such as midi.closeout.qa.midi_auto_final_editor plus a schema summary for result, evidence notes, checker, timestamp, receipt references, and blocked reason.

The product connection is future-proofing. Today the line makes reports and copied QA sessions clearer; later it can become the actual saved state for in-app QA passes, support bundles, guided repair panels, or automated release checklists. The same pattern should be used for Render, Archive, Instrument Bay, Quasar, Scenes, and hardware recall closeout.

2026-07-09 - Short Status Lines Must Preserve State

Long QA templates can hold every detail, but tired humans often read only the shortest status line. If the compact summary carries only the evidence sentence and drops the persistent state key, the future in-app checklist could drift away from the human proof text.

The product connection is continuity under pressure. MIDI status, critical path, closeout checklist, and owner-surface checklist summaries now keep the QA evidence target and the QA state target together. Future SpaceAge status widgets should follow the same rule: a compact row can be short, but it should not lose the thing the app needs to remember.

2026-07-09 - Receipts Need A Shape Before Persistence

Persistent QA should not begin as a vague blob of text. It needs a stable key and a predictable receipt shape before the app starts saving pass/fail state. MIDI closeout categories now describe both: the storage-style key and the fields that make a useful QA receipt, including result, evidence notes, checker, timestamp, receipt references, blocked reason, safety class, route-proof status, and owner surface.

The product connection is trust. A future release checklist, support bundle, or in-app assistant can say "this item passed" only if it knows what was tested, who/what checked it, what proof was captured, and what boundary applied. The same pattern should eventually serve Render, Archive, Quasar packages, Instrument Bay routing, Scenes, and hardware recall.

2026-07-09 - Unsaved Receipts Are Still Useful

There is a subtle but important product distinction between "we know the receipt format" and "this test has been passed." MIDI closeout now exposes an unsaved receipt snapshot with result UNSAVED, the stable storage key, safety class, route-proof status, and owner surface. This prevents the UI from implying that QA has happened merely because the app can describe the receipt.

The same pattern should guide future QA surfaces: show the expected receipt before the work is done, then flip the result to PASS, FAIL, or BLOCKED only when the user or test harness actually saves evidence. That keeps SpaceAge honest while still making next actions concrete.

2026-07-09 - Save Readiness Should Explain The Missing Proof

A disabled or unsaved QA receipt is only helpful if it explains why. MIDI closeout receipt snapshots now carry a save-readiness sentence that names missing fields such as PASS/FAIL/BLOCKED result, evidence notes, checker, timestamp, and blocked reason when the result is BLOCKED.

This pattern should extend to any future "complete this checklist" workflow. If a Render, Archive, Quasar, Instrument Bay, or hardware setup receipt cannot be saved, the app should say exactly what proof is missing rather than leaving the user to guess.

2026-07-09 - Templates Make QA Concrete Before Persistence

The useful middle step between "we have a checklist" and "we saved a QA result" is a paste-ready receipt template. MIDI closeout now exposes the exact future receipt fields as text: session id, persistent state key, PASS/FAIL/BLOCKED result, evidence notes, checker, timestamp, receipt references, blocked reason, safety class, route-proof status, and owner surface.

The product connection is humane testing. A tired tester should not have to invent the structure of proof while also testing the feature. The app can hand them the shape, keep it visibly unsaved, and later promote the same shape into persistent QA state. Render, Archive, Instrument Bay, Quasar, Scenes, and hardware recall should all use the same pattern when their closeout dashboards mature.

2026-07-09 - Receipt State Should Be A Badge, Not A Sentence Parse

Once a QA receipt knows whether it is unsaved, ready to save, or saved, the UI should not have to infer that from a long readiness sentence. MIDI closeout receipt snapshots now expose a persistenceStateLabel and a nextActionHint, so a future dashboard can render a simple badge and one practical instruction without parsing prose.

The product connection is consistency. Any future closeout badge for Render, Archive, Quasar, Instrument Bay, Scenes, or hardware recall should have a structured state and a structured next action. The prose can remain humane, but the UI should consume stable fields.

2026-07-09 - Save Buttons Need A Boolean, Not A Guess

A label such as COMPLETE QA RECEIPT or SAVE QA RECEIPT is helpful, but it is not enough by itself. The UI also needs a plain yes/no answer for whether the receipt is actually saveable right now. Otherwise a future button could be enabled by parsing wording, which is exactly how small interface promises drift.

MIDI closeout receipt snapshots now expose canSave, and Protocol Coverage plus MIDI Health expose nextCloseoutQaReceiptCanSave. The product connection is that a future QA cockpit can disable saving until proof fields exist, while still showing the user what is missing. Render, Archive, Quasar, Instrument Bay, Scenes, and hardware recall should use the same distinction: label for humans, boolean for behavior.

2026-07-10 - Automation Must Look Like A Musical Lane

The first MIDI AUTO implementation had a solid editor, but the user-visible path still felt too much like a protocol surface. Renaming the Piano Roll preview strip to Automation and letting the top-row button report AUTO or AUTO N makes the feature read like a compositional object instead of a hidden setup dialog.

The creative connection is larger than MIDI. SpaceAge will eventually have clip-local automation, Motion Clips, Flux Nodes, and effect gestures. All of those should share the same principle: if it changes over time, represent it as a lane, strip, or living time object near the material it affects. The current PTN-owned Automation strip is the first visible bridge toward that future without pretending Arrangement-local automation is already finished.

The Arrangement Canvas now treats automation as a badge on the lane, not as a replacement for one of the L/S/V controls. That matters philosophically: status should decorate the workspace, while buttons should keep their meaning. The same rule should guide future Motion Clips, Scene badges, hardware-warning marks, and render-state indicators.

Once a badge advertises a real editable object, it should usually be a door. The Arrangement AUTO badge now opens MIDI AUTO directly, while still routing through the same shared-PTN warning path as the Signal menu. The broader principle applies to future Scene, Motion Clip, hardware warning, render-state, and clip-decoration badges: if the label tells the user something exists, clicking it should usually reveal or edit that thing.

VARIANT is the current bridge between shared-pattern automation and future clip-local automation. It copies the musical payload, including Automation, into a new pattern so the composer can safely personalize one clip. That is a good near-term workflow, but it should not become the permanent architecture for clip-local expression, because copying a whole PTN just to edit one gesture can become heavy once automation becomes dense.

The latest wording pass moved the editor away from protocol phrasing and toward consequence phrasing: SHARED PTN DATA says what matters to a composer, because linked clips will also hear the same automation unless the user chooses VARIANT. That same wording pattern should be reused when Motion Clips, clip-local effect throws, and lane-local automation arrive: name what will change, not merely where it is stored.

The doorway labels now carry the same warning before the user opens the editor. That matters because a menu item is a promise: if it says only "automation," the user may assume the selected clip owns the gesture. AUTO Lanes / Shared PTN Data... makes the risk visible early while preserving the fast path for users who already understand the model.

2026-07-10 - Automation Ownership Must Be A First-Class Choice

Task: Define the next automation ownership step without breaking the useful shared PTN automation layer.

Shared PTN automation is not wrong; it is just one ownership mode. It is perfect for a reusable pattern that should carry the same sustain pedal, filter movement, mod wheel curve, breath controller shape, or arp-related gesture everywhere it appears. The danger appears only when the user thinks they are editing one visible clip and accidentally changes every linked clone.

The creative move is to make ownership visible and selectable. The future conversion path should read like a musical choice rather than a database operation: keep this as shared pattern automation, make a variant of the pattern, or make the automation local to this one clip. That same pattern can later apply to Motion Clips, clip decorations, effect throws, and humanized performance curves.

Lane-local automation is a separate instrument/mixer promise. It should not be smuggled into pattern data. Lane volume rides, effect-send gestures, hardware CC macros, and long filter sweeps belong to the lane's timeline, surviving clip swaps while following lane reorder and channel-strip reassignment. If we keep those ownership modes clean, SpaceAge can become more powerful without turning the Arrangement Canvas into a guessing game.

2026-07-10 - Clip IDs Are Ownership Boundaries, Not Display Labels

Task: Harden Arranger clone/paste/split paths for future clip-local MIDI automation.

A copied clip should not quietly keep the same hidden identity as its parent. That might seem harmless while clips mostly point to shared PTN data, but it becomes dangerous the moment clip-local automation, Motion Clips, notes-to-self, effect gestures, or performance takes attach to the clip ID. Two visible clips with one hidden ID would make edits appear haunted.

The creative connection is broader than MIDI. SpaceAge is moving toward reusable musical objects: clips, Section markers, Scenes, Quasar packages, Flux Nodes, and Motion Clips. Any object that can own time-based expression needs a fresh identity when it becomes an independent visible object. If the user wants linkage, that should be a deliberate CLONE/shared-data behavior; if the user wants independence, the ID boundary should make that safe without explanation.

2026-07-10 - Direct MIDI Identity And Live Feel Need Different Timing Rules

Task: Reduce direct physical MIDI monitoring lag without damaging host MIDI timing or hardware sync timing.

Host/plugin MIDI and SpaceAge-opened direct MIDI are not the same timing problem. Host MIDI arrives inside JUCE's processor MidiBuffer with sample offsets that already belong to the current audio block, so preserving those offsets is the correct musical behavior. Direct physical MIDI preserves something host MIDI usually loses: the identity of the actual input device. That identity is crucial for lane-specific controllers, hardware profiles, SysEx capture, MIDI guitars, wind controllers, and guided setup.

The tradeoff is that direct physical MIDI crosses a callback bridge before the audio thread drains it. For live performance data, the humane choice is to make the next audio block speak as soon as possible: notes, bend, pressure, mod wheel, sustain, and other controllers should enter the live path at sample 0 of the drain block. For clock, transport, SPP, MTC, and MMC, timing still matters differently, so those messages keep the calculated sync timing sample.

The product connection is feel. A musician will forgive advanced MIDI plumbing they never see, but they will not forgive a keyboard that feels sluggish. The architecture now says this explicitly: keep host offsets precise, keep direct sync source-aware, and make direct live playing as immediate as the buffer allows. Any remaining latency belongs in buffer/driver/interface/hardware diagnostics or timing calibration, not in hidden performance offsets.

Queue-age diagnostics also need to be current-session truth, not fossil evidence. Resetting direct-MIDI queue-age stats when devices change keeps the Health page from blaming a new controller for an old latency spike. The broader design lesson is that diagnostics should be scoped to the user's present experiment whenever possible.

The external-hardware version of the same idea is live-thru urgency. Sequenced MIDI should honor the timeline, clock should honor timing, and recall/SysEx should honor safety pacing. But a note the user is physically playing is not a future scheduled event; it is a present-tense gesture. Routing that gesture straight into the hardware output router, while only buffering a plugin-MIDI copy when needed, keeps SpaceAge's hardware feel closer to the musician's hands.

2026-07-10 - Recording Should Follow The Armed Lane

Task: Make Arrangement MIDI recording land where the user has armed a lane, not wherever global arrangement state happens to point.

The armed lane is a promise. If the user arms a bass lane and presses record, the app should not consult unrelated drum, harmony, or melody clips to decide whether the new recording belongs at the start, the playhead, or the end. The rule should be musical: record into the clip under the playhead when one exists on that lane; otherwise create a clip on that lane at the playhead; if the lane already has material and the playhead is still at the beginning, append to the lane end; if the lane is empty, begin at measure 1.

The larger connection is Instrument Bay clarity. Lane-owned instruments, lane-owned MIDI input, lane-owned channel routing, and lane-owned recording all teach the same mental model: the lane is the musical destination. That consistency matters more than clever fallback behavior, because recording is one of the moments where the user is least tolerant of ambiguity.

2026-07-10 - Automation Doors Need Real Musical Ownership

Task: Keep Arrangement AUTO+ discoverable without letting empty lanes pretend they own automation.

An automation doorway should not be a magic portal to "whatever pattern was selected last." If the user clicks AUTO on a lane, the app should either open automation for a real clip/pattern in that lane or explain that the lane needs a clip first. That small boundary protects the user's mental model: lane selection chooses a musical destination, but automation still needs an object that can actually own the data.

The creative connection is future-proofing. Clip-local automation, lane-local automation, Motion Clips, and Scenes will all need ownership choices. Making the empty-lane case honest now prevents the future system from inheriting a vague fallback behavior that feels convenient in code but confusing in the hand.

2026-07-10 - Latency Diagnostics Should Speak Musician, Not Stopwatch

Task: Make direct MIDI lag visible where a player can actually use the information.

The app should not hide a 12 ms direct-input queue peak just because the number looks small to a programmer. Under fingers, 12 ms is already something many players can feel, and 30-50 ms is enough to make recording miserable. The creative decision is to let MIDI Health say this plainly: direct physical input queue age is part of the live-feel story, alongside audio buffer size, driver path, interface/controller behavior, SoundFont voice startup, and hardware response.

This matters beyond bug hunting. SpaceAge is trying to be friendly to MIDI guitarists, wind-controller players, hardware synth owners, and people recording live performances into Arrangement lanes. Those users need a trustworthy cockpit that tells them whether the lag looks like SpaceAge queueing, buffer size, driver/device response, or an external hardware route. Diagnostics are part of the instrument.

2026-07-10 - Automation Doors Should Appear Where Music Exists

Task: Make Arrangement MIDI AUTO creation visible without lying about ownership.

The first version of AUTO+ was cautious: it only appeared on the selected lane unless automation already existed. That protected empty lanes, but it still made first automation creation too easy to miss. A better rule is musical: if a lane has a real clip, the lane can expose an AUTO+ door; if automation already exists, it becomes AUTO; if a lane has no clip, it stays quiet.

This connects with the larger SpaceAge object model. Automation should feel attached to musical material, not to an abstract settings panel. Showing the door on every clip-bearing lane teaches the user that automation belongs near the time object it affects, while the shared-PTN warning still preserves the current truth that this is pattern-owned data until future clip-local and lane-local automation are deliberately promoted.

2026-07-10 - Automation Counts Should Count Sources, Not Clones

Task: Make Arrangement AUTO badges report how much automation exists without exaggerating repeated pattern clips.

If a lane contains four visible clips that all point to the same PTN, those clips share one automation source. Showing AUTO 4 would make the user think there are four separate automation lanes or four separate editable objects. The badge should count unique lane/pattern automation sources instead, because that reflects the real ownership model.

The creative connection is trust. SpaceAge can make shared patterns powerful only if the UI refuses to inflate them into imaginary local copies. The same counting rule should guide future Scene summaries, Motion Clip badges, clip-linked warnings, and render/export diagnostics: count what the user can meaningfully edit or break, not how many times the same object is painted on the timeline.

2026-07-10 - Recording State Belongs On The Lane

Task: Make the armed Arrangement lane show whether it is waiting for count-in, recording, or only receiving live input.

The top transport can say "recording," but the player's eyes are usually on the lane they are about to perform into. If that lane says only ARM, the user has to remember a hidden relationship between the button, the transport, the playhead, and the pending count-in. A small label change solves a real anxiety: LIVE IN means the controller plays here, COUNT means the metronome is preparing to record here, and REC IN means durable notes are landing here now.

The product connection is the same one that keeps returning in SpaceAge: the lane is the musical destination. Live input, recording, automation, channel strip, hardware route, and future Instrument Bay ownership should all reinforce that truth instead of making the user inspect a separate panel.

2026-07-11 - MIDI AUTO Needs A Launch Cockpit

Task: Make MIDI AUTO closeout status visible as a product-readiness signal, not just hidden report prose.

MIDI automation is not only about whether SpaceAge can store controller points. The user needs to know where automation can be opened, what object owns it today, what kind of lane is being edited, and what proof is still missing before we can call it launch-safe. A visible closeout summary gives us a compact answer: no lanes exist yet, first-pass lane editors exist, launch-polish remains, or hardware/destination trust still needs proof.

The creative connection is broader than MIDI. SpaceAge will eventually have Motion Clips, clip decorations, Flux Nodes, lane-local automation, and possibly AI-assisted patch/performance helpers. All of those need the same cockpit pattern: show where the feature is accessible, what it owns, what it can do now, what remains experimental, and what test would build confidence next. A model-owned status string prevents the GUI, copied reports, and future manual/help pages from drifting into contradictory folklore.

2026-07-11 - Release Gates Should Be Human-Readable

Task: Turn MIDI closeout blocker metadata into one readable release-gate sentence.

The app can already know many things at once: blocker count, next category, route proof, safety class, QA receipt state, hardware-proof requirements, and deferred future protocol boundaries. If those remain scattered across separate rows, a tester has to synthesize them mentally. A release-gate summary gives the human one answer first, then lets the deeper rows explain the evidence.

This is useful beyond MIDI. Future Quasar capture, SoundFont relocation, VST scanning, hardware recall, project archiving, and render/export flows will all benefit from the same pattern: state whether the feature is clear, blocked, waiting on user proof, or deliberately outside the current release. Product trust grows when the app speaks in release gates instead of making users infer risk from raw counters.

2026-07-11 - Switch Edges Should Behave Like Time Boundaries

Task: Make MIDI AUTO switch-edge movement refuse edits that would collapse or cross ON/OFF block boundaries.

Switch lanes are stored as MIDI events, but the user experiences them as regions of time: sustain on, sustain off, mute on, mute off, gate open, gate closed. A switch edge should therefore behave more like the edge of a clip or loop range than like a loose controller dot. Dragging or nudging an edge within its current neighboring interval is a trim; dragging it onto another edge or across a neighboring edge is a block-logic rewrite and should be refused unless we someday build an explicit advanced operation for that.

The creative connection is SpaceAge's larger language of living time objects. Arrangement clips, Section markers, loop bounds, sample loop-on-release points, Motion Clips, and switch automation all need the same tactile truth: grab an edge to trim, but do not accidentally invert the structure underneath. The MIDI AUTO editor now preflights single and grouped switch-edge moves before processor mutation, so the UI can explain the musical boundary instead of relying on a generic point-collision failure.

Architecture choice: Keep switch automation PTN-owned and event-backed for now. The new guard is editor-side validation around the existing processor mutation calls; it sends no MIDI, changes no routing, and changes no external hardware. Reports now credit guarded switch-edge validation as present, leaving tangent-handle curve editing, durable bend-range gates, and future clip/lane-local automation as the remaining MIDI AUTO closeout focus.

2026-07-11 - Pitch Bend Trust Is A Gate, Not A Sentence

Task: Convert MIDI AUTO pitch-bend trust from scattered explanatory prose into a structured model that can be reused by reports, UI, playback, and export policy.

What connects creatively: Pitch bend is one of the clearest examples of MIDI being technically preserved while musically uncertain. A raw 14-bit curve can be perfect, yet a MiniNova, QY, SoundFont engine, and internal synth may each turn that same curve into a different number of semitones. The same trust pattern will matter later for SysEx restores, Motion Clips, automation sends, and hardware scenes: SpaceAge should know the difference between "we stored the data" and "the destination is proven to respond as expected."

Architecture choice: Add MidiPitchBendTrustGate as a model-level verdict built from a MidiExpressionLaneSummary. The gate reports destination ownership, Hardware Passport presence, declared range, manual TEST BEND verification, playback/export trust, next action, and warnings. This does not send MIDI or change pitch-bend playback yet; it creates the shared truth object that future hard playback/export warnings can use without rewriting the policy in every panel.

2026-07-11 - Export Readiness Should Reuse The Same Bend Verdict

Task: Make MIDI export readiness use the same pitch-bend trust gate as the MIDI AUTO editor.

2026-07-11 - Automation Doorways Need One Name

Task: Keep MIDI automation visible without letting the UI teach multiple names for the same current workflow.

The creative connection is confidence. A composer should not have to wonder whether MIDI AUTO, Automation, Automation Lanes, and MIDI expression are four different things. The user-facing doorway is now Automation / Shared PTN Data; lower-level code can still call the stored payload MIDI expression, but the musician sees one route and one warning: this is shared PTN automation until a deliberate clip-local or lane-local model exists.

This also protects future design. When SpaceAge later adds true clip-local automation, lane-local automation, Motion Clips, or Scene-level automation, each can get its own clear doorway instead of inheriting a muddy name from the first pattern-owned implementation.

The follow-through is row language. Arrangement lanes are already instruments/mixer routes, so calling controller data "lanes" inside the current automation editor makes two unrelated concepts collide. Automation rows keeps the panel name memorable while making each editable controller/bend/pressure strip feel like a row inside that workbench, not another Arrangement lane.

2026-07-11 - Rows Are The Atoms Inside Automation

Task: Finish the row/lane wording pass inside the Automation editor and copied MIDI reports.

The creative connection is hierarchy. Automation can stay as the memorable name of the workbench, but the individual editable things inside it should be rows: one row for Mod Wheel, one row for Sustain, one row for Pitch Bend, one row for Pressure. That lets Arrangement lanes keep their stronger meaning: one musical destination with an instrument, mixer route, MIDI channel, and eventual automation scope.

Architecture choice: This is a presentation-layer correction, not a storage rewrite. Internal C++ names can still use older MidiExpressionLaneSummary structures until a deliberate backend rename is worth the churn, but visible controls, empty states, tooltips, selected-scope copy, and source-generated reports now say row where the user is manipulating pattern-owned Automation data. Future clip-local and Arrangement-lane-local automation should get a new ownership model rather than secretly borrowing the current shared-PTN rows.

2026-07-11 - Live MIDI Latency Should Tell The Truth

Task: Make live MIDI feel reporting distinguish SpaceAge routing delay from audio-buffer and hardware-path delay.

Direct physical MIDI should feel immediate, but it cannot break physics: messages arrive off the audio thread and are drained by the next audio callback. SpaceAge can avoid musical quantization and unnecessary pending-output delay, but it should also help the user understand when the remaining feel problem is an audio buffer, driver/interface, controller, SoundFont voice-start, or duplicate routing issue.

The creative connection is a future setup assistant. MIDI Health, Audio Settings, Hardware Passports, SoundFont prepared pools, and direct/host source policy can all become one confidence-building diagnostic path: "here is what SpaceAge controls, here is what the driver controls, here is what the hardware controls, and here is the next test."

What connects creatively: Export is where preserved data becomes a promise to collaborators, hardware users, and future versions of SpaceAge. If the editor says a bend range is unverified but export says only "raw data preserved," the user gets two half-truths. The same gate should travel from the editor to the export preview so a musician can tell whether a file is internally safe, externally verified, or still needs a Hardware Passport / TEST BEND step.

Architecture choice: MidiExportLaneSummary now carries a MidiPitchBendTrustGate, and the export helper builds that gate from the lane route and Hardware Passport fields instead of maintaining a parallel prose-only pitch-bend rule. Pattern-local exports still warn that no final destination range is declared, but they now also carry the structured gate payload for downstream UI/reporting.

2026-07-11 - Curve Amount Is The Bridge To Tangent Handles

Task: Make MIDI AUTO curve shaping more controllable without jumping straight to the full future tangent-handle editor.

The launch editor already has the right safety posture: curve edits preview first, endpoints stay anchored, no MIDI is sent, and undo remains available after apply. The missing piece was feel. A fixed hidden curve strength makes Smooth, Fast Start, and Slow Start seem like commands with unknowable intensity; a small Light/Medium/Strong selector turns them into musical gestures a user can audition and learn.

This connects to the larger SpaceAge workflow because Motion Clips, filter movement, velocity shaping, fade curves, and future clip decorations will all need curve-intensity language. Starting with a compact amount selector gives us a reusable control concept now, while leaving the more visual tangent-handle editor as a later precision layer.

2026-07-11 - Export Warnings Should Travel Upward

Task: Make full-file MIDI export rows inherit lane-level warnings from the Arrangement lanes they contain.

Lane rows can be precise, but a user may choose the whole-file export first. If the full-file row looks clean while one lane has untrusted external pitch-bend depth, missing hardware routing, or another lane-local MIDI warning, SpaceAge has technically documented the issue but still failed the workflow. The main export choice should carry the caution because it contains the risky lane.

This same upward-warning rule should apply elsewhere: scenes should inherit instrument-route warnings, render packages should inherit missing-asset warnings, Quasar packages should inherit sample-capture warnings, and future Motion Clip bundles should inherit automation ownership warnings. The object at the top of an action must summarize the risks of its children.

2026-07-11 - Hardware Editors Should Be Manual-Backed Instruments

Task: Turn the QY-70/QY-100, CBX-K1XG, Yamaha XG, and Roland GS idea into a concrete Hardware Passport/editor path.

What connects creatively: Older hardware has deep musical value, but its front panels and manuals can feel like small mazes. SpaceAge can make these devices feel modern by translating the official Data List into calm editor pages: Parts Mixer, Voice Select, Drum Map, Effects, System, and Librarian. That fits our larger product theme: do not bury musicians in every possible feature, but make the right feature obvious when they need it.

Architecture choice: Treat hardware editors as Hardware Passport-backed instruments, not as special-case global MIDI hacks. Normal note/expression playback remains lane-owned. Setup data, XG/GS resets, SysEx parameter writes, and bulk dumps stay confirmed and receipt-backed through MIDI PATCH / SysEx Vault flows.

Future extensions: The same profile system can serve Yamaha XG, Roland GS/Sound Canvas, Novation MiniNova, vintage rack synths, MIDI guitar converters, wind controllers, and eventually user-shareable hardware profiles.

2026-07-11 - Automation Belongs Near The Lane

Task: Make Automation easier to discover from the Arrangement Canvas.

What connects creatively: SpaceAge has been moving away from hidden pad-proxy routing and toward lane-owned instruments. MIDI automation should follow that same mental model. If a lane owns the musical destination, the lane should also offer the path to its performance data: mod wheel, pitch bend, pressure, sustain, and controller movement.

Architecture choice: Do not create a second automation system just to improve visibility. Keep the shared-PTN Automation editor as the single current automation workbench, but promote its doorway inside the lane Signal / MIDI menu and keep the AUTO / AUTO+ badge as the fast visual route. This avoids teaching multiple names while leaving room for future clip-local, lane-local, Motion Clip, and Scene automation models.

2026-07-11 - Batch SysEx Capture Needs A Ritual

Task: Make SysEx batch-capture dry-run plans describe the eventual human workflow step by step.

What connects creatively: Hardware backup/restore is less like normal editing and more like a careful studio ritual: pick the device, ask it for one dump, inspect the evidence, name it, save it, and repeat. If SpaceAge teaches that ritual before the full live batch UI exists, the eventual workflow will feel predictable instead of suddenly dangerous.

Architecture choice: Add sessionSteps to the model-owned SysExBatchCapturePlan, then expose those steps in plain reports and structured payloads. Keep batchCaptureReady false. The work improves trust and future UI readiness without pretending SpaceAge can already run a live multi-dump inbox.

Future extensions: The same session-step pattern can guide hardware setup, MIDI clock testing, device-specific editor onboarding, VST scan repair, sample relinking, and Quasar capture sessions: every high-stakes workflow should tell the user what the next human action is.

2026-07-11 - Automation Need A Ritual Too

Task: Make Automation preflight reports explain the practical editing workflow from the model layer.

What connects creatively: Automation is powerful but easy to make mysterious. The user should not have to remember whether to start in Piano Roll, Arrangement, MIDI TASKS, or Settings; all those doors should lead to the same calm ritual: choose real musical material, open Automation, pick a row, draw the movement, respect shared PTN ownership, and test the destination if it is hardware or export-sensitive.

Architecture choice: Add midiExpressionEditorWorkflowSteps() beside the operation-coverage helper and inject those steps into the preflight report. This keeps onboarding, copied diagnostics, future tooltip text, and test expectations tied to one source instead of letting each panel invent its own automation instructions.

Future extensions: The same workflow-step helper can become the seed for an in-app Automation tutorial, a contextual help card, a QA checklist, and eventually clip-local/lane-local automation migration guidance when SpaceAge grows beyond shared PTN automation.

Follow-through: The project-level Automation report now reuses the same workflow steps instead of carrying its own long suggested-workflow block. The report can still add project-specific warnings and next tests, but the basic human ritual has one source.

Follow-through: The visible Piano Roll AUTO doorway and empty Automation panel now also quote the same workflow helper. This matters because the first empty-state moment is where a user learns the feature; if that text drifts away from reports or QA language, the app teaches two subtly different versions of automation.

2026-07-11 - Closeout Rows Should Be Objects, Not Rewritten Paragraphs

Task: Keep the MIDI 1.0 "what is left?" answer consistent across normal reports, owner-surface reports, structured payloads, and future UI tables.

The creative connection is trust. A musician should be able to open the MIDI report, copy a QA checklist, or inspect a surface-organized list and see the same blocker truth: where to go, whether the route is direct, whether the action is cold/warm/hot, what evidence proves it, and what PASS/FAIL/BLOCKED state is expected.

Architecture choice: Add a category-owned closeoutChecklistRowSummary() so the row is part of the MIDI model instead of a paragraph rebuilt separately by each renderer. This keeps future cockpit widgets and support reports from inventing slightly different closeout language.

Follow-through: COPY QA and COPY CLOSEOUT now ask the MIDI report model for their complete clipboard packets. That turns the copy buttons into transport pipes instead of miniature report writers, which is exactly where we want them: the MIDI model owns truth, the UI owns presentation.

2026-07-11 - Automation Doorways Should Not Speak With Two Mouths

Task: Keep Arrangement AUTO/AUTO+ badges consistent in normal and overview lane rendering.

What connects creatively: Automation are becoming part of the core composition surface, not a hidden technical afterthought. If one badge says AUTO+, another compact badge says something slightly different, and the tooltip omits the VARIANT warning, the user has to relearn the same doorway twice.

Architecture choice: Add local badge label and tooltip helpers to the Arrangement lane component. The helper keeps compact/expanded labels aligned and pulls in the model-owned Automation workflow steps, while still reminding the user that current automation is shared PTN performance data until a VARIANT is made.

Follow-through: The click-status messages now use the same workflow helper. Hover text, after-click status, empty-state help, reports, and QA copy all point to the same Automation ritual: pick real musical material, open the workbench, choose/create a row, edit movement, and make a VARIANT before diverging linked clips.

Follow-through: A compact midiExpressionEditorWorkflowSummary() now sits beside the step-list helper. That gives short UI surfaces a single sentence source while longer reports can still enumerate the steps. The creative value is small but important: one calm story, repeated everywhere, makes automation feel like a feature instead of a technical cave.

Follow-through: The Piano Roll Automation preview strip now speaks first as a creative tool: draw expressive motion. The shared-PTN ownership detail is still there, but the first impression is no longer protocol vocabulary. This matches the larger SpaceAge design rule: musical intent first, protocol truth second, dangerous or confusing boundaries always visible.

Follow-through: The closeout blocker name is now aligned around Automation Final Editor. The subtle product-design point is that a feature name should survive the journey from button, to tooltip, to report, to test, to QA checklist. If those nouns disagree, the user feels it as friction even when the code is technically doing the right thing.

Follow-through: Automation preflight reports now use Selected row and a ROWS section header. This keeps the human-facing language consistent with the editor model: Arrangement lanes are instruments/routes, while Automation rows are controller, bend, pressure, sustain, and setup data inside the shared-PTN automation workbench.

Follow-through: The Automation insert-value control now says it edits the selected Automation row. We intentionally left Hardware Passport and route-testing text as selected lane because those actions really do target Arrangement lanes, output devices, mixer identity, and external hardware routes.

Follow-through: Automation project summaries now translate internal readiness counts into product language: visible editor rows, final QA rows, preview-transform rows, and shortened previews. The code still owns the exact counts, but the user sees a release-quality explanation instead of our construction scaffolding.

Follow-through: Selected-pattern preflight text now follows the same wording. This is small, but it matters because copied diagnostics, empty states, and live editor reports should all teach the same product truth.

2026-07-11 - Completion Scores Need Denominators

Task: Stop MIDI progress reports from sounding like the backend regressed when the customer-facing finish line expands.

What connects creatively: Trust is partly mathematical and partly linguistic. A user does not care that a hidden parser is excellent if the visible workflow still needs receipts, warnings, or hardware proof. At the same time, the developer should not feel like completed backend work vanished just because the launch checklist now includes more customer-facing evidence.

Architecture choice: Add model-owned summaries for MIDI 1.0 completion status and remaining perfection work. Backend foundation means recognition, routing, preservation, and safety plumbing. Customer-facing closeout means visible Automation QA, hardware setup/test receipts, bend-range evidence, SysEx live-device validation, real-file import/export proof, timing checks, and documentation polish. Those are two different denominators, and future UI/reports should say so directly.

2026-07-12 - Automation Needs One Ownership Truth

Task: Make MIDI closeout reports carry one model-owned sentence about what Automation owns today.

The creative connection is trust. Automation is exciting, but it becomes dangerous if one part of SpaceAge implies clip-local movement while another edits shared pattern data. The MIDI protocol report now has a single automation ownership boundary: Automation / Shared PTN Data edits shared pattern-owned rows; linked clips hear those rows until the composer makes a VARIANT; clip-local, lane-local, Motion Clip, and full Arrangement automation are future architecture.

This also gives future UI a reliable phrase to quote. The goal is not to make the app sound less powerful; the goal is to keep users from feeling tricked. When SpaceAge later grows clip-local and lane-local automation, those features should get new ownership names instead of quietly mutating the meaning of today's shared PTN rows.

2026-07-12 - Hardware Editors Need Readiness Data, Not Hope

Task: Add structured editor-readiness fields to MIDI hardware setup templates so Yamaha XG, Roland GS, GM module, and similar hardware editor pages have a safe place to grow.

What connects creatively: A Hardware Passport is already SpaceAge's trusted identity document for external gear. A device-specific editor should be a Passport-backed control surface, not a random SysEx button farm. The same safety grammar that protects test notes, program recall, SysEx Vault sends, and bend-range tests should also govern future QY/CBX/MU/Sound Canvas editors.

Architecture choice: MidiHardwareSetupDeviceTemplate now exposes editor profile label, locked/ready state, source/manual requirement, verification checklist, and deep-editor readiness as model data. Yamaha QY-70/QY-100, Yamaha CBX-K1XG, and GM/XG/GS templates start locked until exact manuals/Data Lists verify model ids, address maps, value ranges, checksums, and queue safety. This adds no hardware-sending behavior; it prevents future UI from accidentally inventing unsafe editor powers.

2026-07-12 - Two Clocks For One MIDI Gesture

A MIDI gesture has two different user expectations: it should sound immediately under the fingers, and it should land musically where it was actually played. Treating those as the same timestamp caused a design trap. The better architecture is a split clock: an earliest-possible monitor timestamp for feel, and a measured timing timestamp for recording, automation, and future humanized editing. This same idea can apply later to audio recording, motion clips, and hardware round-trip calibration.

2026-07-12 - Doorways Make Features Real

Automation already existed, but if the user cannot see the door, the feature feels theoretical. Putting Automation next to ADD CLIP connects the act of creating musical material with the act of shaping it over time. This is the same design family as lane badges, ghost-note hints, and MIDI Passport: reduce memory burden, expose intent, and keep deep power one click away.

2026-07-12 - Automation As A Visible Musical Object

MIDI automation should read like part of the composition, not like hidden engineering metadata. The new in-clip AUTO marker connects the Arrangement Canvas, Piano Roll AUTO lane, and lane command menu into one mental model: if a block has expressive motion, the block admits it visually. This is also a precedent for future clip badges: arp rendered, chord muted, hardware-routed, scene override, or motion clip attached. The trick is keeping badges informational and tiny, never turning SpaceAge into a sticker-covered control panel.

2026-07-12 - Badges As Doorways, Not Stickers

Small metadata badges become useful when they open the thing they describe. The AUTO badge is now a doorway from Arrangement thinking into performance automation thinking. This pattern can scale: ARP badges can open arp controls, hardware badges can open Hardware Passport, and future Motion Clip badges can open motion editing without forcing another always-visible panel into the workspace.

2026-07-12 - Creative Link: Timing Trust Is Workflow Trust

The direct MIDI timing split is a small backend detail with a large creative consequence. If SpaceAge lets the player hear notes immediately but records them honestly, the app feels responsive without lying to the arrangement. That same design principle should guide future performance features: always optimize feel, but never hide the truth of the captured performance.

2026-07-12 - Creative Link: The Last-Chance Drain

A live MIDI note is not just data; it is a trust signal between the player's hand and the instrument. The new last-chance direct-input drain treats the end of sequencer bookkeeping as another opportunity to catch the performer's gesture before audio is rendered. This same design shape can guide future low-latency surfaces: if a musical action can safely be admitted one more time before sound leaves the engine, give it that chance.

2026-07-12 - Last-Chance MIDI Must Be Musically Fast, Not Timeline-Clever

Task: Double-check the same-block direct MIDI lag fix and tighten it so only live performance gestures are allowed through the late path.

What connects creatively: A player's note should feel immediate, but a transport command is not a note. Clock, Start, Stop, Song Position, SysEx, and setup messages are timeline/control-plane events, so sneaking them in after the sequencer has already chosen the block's timeline creates hidden weirdness. This connects live feel, MIDI Clock trust, SysEx safety, Hardware Passport setup, and future automation recording under one rule: performance gestures can be late-fast; timeline/setup messages must stay ordered.

Architecture choice: The normal direct MIDI drain remains complete and runs before sequencer processing. The second last-chance drain now consumes only front-of-queue notes and performance expression, leaving non-performance messages queued for the next normal drain. That keeps live monitoring responsive without reordering sync or hardware setup intent.

2026-07-12 - Learned Knobs Deserve The Same Live Path

MIDI latency is not only about note-on timing. A mapped filter cutoff, vibrato depth, or expression slider can feel just as wrong if it lands one block late. Treating generic learned CCs as live performance data lets SpaceAge feel more like an instrument under the hands, while the classifier keeps hardware setup language safely separated.

2026-07-12 - Don't Let Clock Chatter Hide A Note

A useful MIDI design rule emerged here: the fastest path is not only about accelerating the obvious performance messages. It also has to recognize harmless real-time chatter that may sit in front of those messages in a FIFO. For SpaceAge, that means treating MIDI Clock and Active Sense like transparent debris in the live input path. They matter for sync/status, but they should never make the player feel a note arrive late.

2026-07-12 16:57 - MIDI Front Door Fallback

Task: Restore live MIDI input and chord readout after the direct input router became too dependent on lane-specific device selection.

What connects creatively: A controller should feel like plugging a cable into the front of the machine: if the OS can see it, SpaceAge should hear it unless the user deliberately narrows the lane. The lane-specific input selector remains powerful for hardware rigs, but the default musical act of playing notes must not require a hidden setup ritual.

Architecture choice: Open visible physical MIDI inputs by default when no lane has selected a specific input device. Keep the armed-lane channel/device gates for narrowed setups, and keep host/direct policy visible so duplicate routing can still be diagnosed instead of becoming mysterious double notes.

Future extensions: MIDI Rig Doctor can compare HOST ONLY, DIRECT ONLY, and HOST + DIRECT while showing queue age, dropped messages, and duplicate-risk evidence in one friendly setup flow.

2026-07-12 17:20 - MIDI input confidence layer

The chord readout should act as a raw MIDI confidence light before musical routing. This makes hardware setup easier: first prove the app sees notes, then decide which lane/instrument should receive them.

2026-07-12 19:16 - MIDI two-controller Auto policy refinement

• Changed MIDI Auto source arbitration so host/direct duplicate suppression is per note event instead of global. Direct MIDI is no longer suppressed merely because any host MIDI has appeared, which should allow two simultaneous controllers to coexist.
• Added a short host-note timestamp window to suppress likely duplicate host/direct echoes of the same note/channel/kind within 25 ms when no direct lane device has been intentionally selected.
• Built test package: SPACEAGE_MIDI_TWO_CONTROLLERS_20260712-191625.zip.

2026-07-12 19:24 - MIDI multi-controller source routing fix

• Fixed a two-controller regression by making MIDI Auto source arbitration message-specific instead of stream-global. Host/direct duplicate suppression now compares recent host and direct note timestamps in both directions, rather than muting all host or all direct input after one source appears.
• Direct physical MIDI discovery now opens all visible input devices. Lane-specific input-device choices are still enforced later in the live-routing gate, but discovery no longer makes a second connected controller disappear because another lane named a controller.
• Built test package: SPACEAGE_MIDI_MULTI_CONTROLLER_FIX_20260712-192341.zip.

2026-07-12 - Arrangement Recording as Context-Aware Capture

The MIDI recorder should behave like a composer-facing tape machine: the user plays against the song, not against an isolated pattern bucket. This same context-aware mapping can later power punch-in, retrospective MIDI capture, loop overdub, and clip-specific takes. The important connection is that a clip is both a visible Arrangement object and a portal into pattern-local data, so every record/edit gesture needs to know which side of that portal the user is standing on.

2026-07-13 - Live MIDI Needs A Clear Runway

Task: Continue the MIDI lag audit without destabilizing recording timing.

What connects creatively: The same principle behind Arrangement lane ownership applies to timing: a performance gesture needs a clear runway. Status chatter from interfaces is real MIDI, but it should not be allowed to sit in front of a live note like paperwork at a launch pad. Keeping harmless Clock/Active Sense messages passable in the late drain lets SpaceAge preserve protocol awareness while still feeling immediate under the fingers.

Architecture choice: The late direct-input drain remains conservative, but it now matches its intended contract: note/controller/performance messages and harmless status chatter can reach the last-chance pre-render path; setup, SysEx, transport, and guarded hardware traffic remain on the safer normal path.

Future extensions: MIDI Health should continue separating SpaceAge queue age from audio-buffer, interface, DIN, driver, and external-synth response latency so users can diagnose feel without guessing.

2026-07-12 23:58:05 - MIDI source policy as user trust design

The multi-controller fix reinforces a broader rule for SpaceAge: when routing intent is ambiguous, preserve musical input and make the uncertainty visible rather than silently deleting performance data. This same principle should guide future automation, hardware editor, and live-recording conflict handling.

2026-07-13 00:08:45 - MIDI timing is two clocks, not one

A player's gesture has two truths: when SpaceAge can render it and where the performance should land musically. The direct-router sign fix keeps those separate. That same mental model should guide future MIDI Timing UI: live feel, recorded placement, and hardware response are related, but they are not the same knob.

2026-07-13 00:17:36 - MIDI trust is partly visual

A MIDI implementation can be technically correct and still feel broken if the setup panels look cramped or contradictory. Treat MIDI diagnostic surfaces as part of the protocol experience: clear spacing, readable labels, and explicit safe-door language reduce user anxiety before a single note is recorded.

2026-07-13 00:29 - Arrangement MIDI Confidence Layer

The best user-facing MIDI workflow will only feel effortless if the invisible math is boringly correct. Today's regression suggests we should keep pairing every future MIDI UI affordance with a narrow timing receipt: what lane was armed, what clip was active, where the Arrangement playhead lived, and where the recorded note landed. That same receipt language can become a future user-facing diagnostic when a performer asks, "Why did this note land there?"

2026-07-13 00:38 - MIDI Input Trust Gate

The lane input selector can become more than a routing field: it can behave like a trust gate. If the user chooses a specific controller for a lane, SpaceAge should protect that lane from ambiguous duplicate paths. This supports a future setup wizard where a performer can intentionally assign Controller A to bass and Controller B to lead without invisible host routing creating chaos.

2026-07-13 01:05 - Arrangement Record As The Front Door

Task: Plan a Record button on the Arrangement page so users can capture melodic and harmonic parts without switching into Piano Roll first.

What connects creatively: This is the same design move as lane-owned instruments and ghost-note context: the song surface should be where the player performs. Piano Roll is the microscope; Arrangement is the room. A single Arrangement Record button can connect lane selection, MIDI input filtering, count-in, clip creation, Automation, latency compensation, and future punch-in without asking the user to understand pattern plumbing.

Architecture choice: Treat Record as a doorway into the existing lane-owned recording backend. If the playhead is over a clip, record into that clip. If it is over empty space, create a new lane-owned clip. If no lane is selected or armed, guide instead of guessing.

2026-07-13 01:02 - Arrangement REC As A Workflow Shortcut

Putting REC directly in Arrangement turns recording into a lane-first act: select the lane, set the playhead, record. This connects the Instrument Bay migration, lane-owned MIDI, and future automation capture into one visible workflow instead of forcing users to enter Piano Roll merely to perform into the song.

2026-07-13 03:20 - Automation As A Doorway, Not A Hidden Room

Automation should feel like a visible Arrangement tool, not a hidden diagnostic panel. Contextual labels such as AUTO CLIP and AUTO LANE connect clip editing, lane ownership, and MIDI performance automation into one mental model: choose musical context first, then draw motion there.

Arrangement REC As A Truth Surface - 2026-07-13

A record button is not just a transport control in SpaceAge; it is a promise about where performance data will land. By making REC name the armed-or-selected lane in its tooltip, the Arranger can teach the workflow without adding another inspector. This connects the lane-selection architecture, MIDI recording, and future automation-lane visibility into one principle: the composition surface should always explain ownership before it changes data.

2026-07-13 03:43 - Recording Destination As A Lane Truth

The Arrangement lane badge should carry record-destination truth because the lane is now the user's instrument/route home base. This connects the MIDI recording workflow to the Instrument Bay direction: fewer global inspectors, more trustworthy lane-local state. The same visual language can later support automation write/read modes without adding clutter.

2026-07-13 03:50 - Automation Doorways Should Live On The Lane

The AUTO badge belongs on the lane because automation is part of the lane's performance identity: notes, instrument, MIDI input, and expressive motion should be discoverable in one visual neighborhood. This also reinforces the Instrument Bay direction: fewer global selectors, more lane-local truth. Later, this can grow into a lane button stack for ghost notes, automation modes, and hardware routing without creating another top inspector.

2026-07-13 - Automation Ownership Should Read Before It Explains

Task: Make the Automation shared-pattern state visible as a warning/status strip, not just a sentence among other helper text.

What connects creatively: SpaceAge is increasingly full of living time objects: clips, section markers, chords, MIDI gestures, and future Motion Clips. Ownership is part of that visual language. If automation belongs to a shared PTN, the interface should announce that before the user has to parse a paragraph. The new strip connects VARIANT, ACK SHARED, and linked Arrangement clips into one immediate truth: either make this idea independent, or knowingly edit every linked copy.

Architecture choice: UI wording and paint only. MIDI AUTO remains PTN-owned; SOURCE VIEW remains a viewport; VARIANT remains the independence route; ACK SHARED remains the intentional linked-edit route. No MIDI is sent, no routing changes, no external hardware changes, and no automation playback/export semantics changed.

2026-07-13 - Destructive Shortcuts Need Smaller Blast Radius

Task: Make Automation keyboard Delete/Backspace delete selected points or switch edges only, not an entire selected row.

What connects creatively: SpaceAge is trying to feel fast without feeling booby-trapped. In a graph editor, Delete should feel like a scalpel first. Whole-row deletion is still necessary, but it belongs behind a button whose label says exactly what will happen: DELETE ROW. This connects MIDI AUTO to the larger safety language of 86, VARIANT, ACK SHARED, and protected MIDI PATCH actions.

Architecture choice: UI/input behavior only. The processor row-deletion helper remains unchanged, Undo remains processor-backed, and the existing shared-PTN guard still blocks destructive edits until VARIANT or ACK SHARED.

2026-07-13 - Copy/Paste Should Say Where The Gesture Will Land

Task: Clarify Automation copy/paste status so the user knows pasted automation returns to a PTN-owned row.

What connects creatively: Copy/paste is one of the places where a musician's hands outrun their memory. If a gesture was copied from a controller row while looking at a clip source slice, the user may intuitively think the paste belongs only to that clip. The status line now keeps the larger ownership story in view: same row, PTN-owned, guarded by VARIANT or ACK SHARED when linked clips are involved.

Architecture choice: Copy/status text only. Paste already used the shared-pattern guard; this pass made the wording match the model. No MIDI send, routing, playback, export, serialization, or hardware behavior changed.

2026-07-13 - Shared PTN Beats Pattern-Owned As Human Language

Task: Make the MIDI report/status wording agree with the current Automation mental model.

What connects creatively: The architecture can be correct and still feel wrong if the nouns drift. Pattern-owned sounds like database language; shared PTN sounds like the thing the musician actually sees on screen. That small wording change lowers cognitive load and makes the Variant workflow feel like a natural musical decision rather than a technical warning.

Future extension: When clip-local, lane-local, Motion Clip, or Scene automation arrives, keep each ownership layer named from the user's visible object: clip, lane, motion clip, scene, PTN. The UI should never ask the user to infer ownership from backend terminology.

2026-07-13 - One Ownership Noun At The Moment Of Risk

Task: Make Automation warnings, tooltips, reports, and tests use one ownership noun: shared PTN.

What connects creatively: The most important wording is the wording that appears right before risk. If a musician is about to paste, delete, acknowledge, or variant Automation data, SpaceAge should not switch between pattern-owned, PTN-owned, and shared-pattern. Shared PTN is concrete, visible, and musically actionable: it tells the user exactly why a linked clip may also change and exactly why VARIANT exists.

Future extension: Use this same rule for future automation scopes: clip-local, lane-local, Scene, Motion Clip, and Project should each be named at the moment of creation, edit, paste, delete, export, and undo. Ownership should be a first-class part of the gesture, not a footnote.

2026-07-13 - Live MIDI Needs A Flight Deck Readout

Task: Make the MIDI record target summary state the armed Arrangement lane, input filter, output MIDI channel, and edit focus.

What connects creatively: Recording confidence is partly psychological. If a user has a clip selected but a different lane armed, the app must calmly explain the truth before they play. A compact flight-deck readout turns invisible routing into visible performance confidence: this lane is armed, this channel is accepted, this instrument hears it, and selected clips are only edit focus.

Future extension: The same compact truth strip can later show MPE zone, hardware input device, MIDI Clock source, quantize/capture mode, and duplicate-input warnings without forcing the user to open Settings mid-performance.

2026-07-13 - Put The Owner Above The Diagnostics

For MIDI troubleshooting, the first useful question is not ?what device is connected?? but ?who owns the signal right now?? Putting the live input owner above device/channel details turns a maze into a flight-deck readout. Later this same pattern can grow to include device source, MPE zone, duplicate-input risk, clock source, and SysEx target without burying the user in technical fog.

2026-07-13 - Multi-Controller Clarity Is Workflow Design

A multi-controller setup should feel powerful, not haunted. The same backend behavior can be either elegant or frightening depending on whether the app explains ownership. Opening all physical inputs keeps the rig flexible; showing the armed lane, pinned input, channel filter, and multi-controller caution turns that flexibility into something a musician can trust during a take.

2026-07-13 - Recording Should Leave A Receipt

A DAW earns trust by showing evidence immediately after an invisible operation. MIDI recording is partly invisible: a controller sends data, timing is calculated, notes are mapped into a clip, and the musician hopes it went where intended. The capture receipt turns that invisible chain into a small, readable confirmation. This same idea can later serve audio recording, SysEx capture, automation recording, and Quasar sampling: every important capture should tell the user what was captured, where it landed, and whether the result is editable, linked, or destructive.

2026-07-13 - Record Buttons Should Speak In Verbs And Targets

Task: Make the Arrangement REC button stateful enough to explain whether recording is possible, counting in, or actively landing into the armed/selected lane.

What connects creatively: A record button is a promise. If the user sees ARM LANE, the missing step is obvious. If they see COUNT, they know the app is waiting on purpose. If they see REC IN, they know MIDI is being captured into the Arrangement context. This connects transport controls, lane ownership, count-in, and capture receipts into one principle: performance tools should remove doubt before the musician plays.

Future extension: The same compact state language can be reused for audio recording, automation write modes, punch-in, loop overdub, and hardware SysEx capture: unavailable state, armed state, count/prep state, active capture state, receipt state.

2026-07-13 - Automation Deserves A Receipt Too

Notes and drum hits naturally feel concrete because the user can see them immediately. Controller data, pitch bend, and pressure are more ghostly, so the interface needs to give them a receipt. This same idea can later connect to automation-lane visibility: every invisible performance gesture should have a visible breadcrumb before the user goes looking for the lane itself.

2026-07-13 - Trust Comes From Receipts And Stable Timing

The same UI idea applies to both automation receipts and record length: the composer should never have to wonder whether SpaceAge understood the gesture. A note, CC gesture, or pressure move should leave a visible receipt, and the clip it lands in should keep the length the user can see on the canvas. That consistency is what makes recording feel like an instrument instead of a slot machine.

2026-07-13: Automation as Context Receipts

The compact Automation strip should behave like a receipt for what the user will actually hear in context, not merely a pattern-level preview. This connects Arrangement clip identity, lane-level hardware/control routing, and clip-local variation into one visible cue. The same principle can later guide automation thumbnails on Arrangement clips: show effective motion, not just stored raw data.

2026-07-13: Arrangement AUTO Badges as Evidence, Not Decoration

Lane-level AUTO badges should help the user find expressive data without memorizing where it lives. Counting effective automation rows by lane connects Arrangement clips, shared PTN rows, lane-local rows, and clip-local rows into a single visible evidence cue. This is a good pattern for future clip thumbnails and Motion Clips: the surface should summarize what playback will actually use, even if the editor underneath still has separate ownership layers.

2026-07-13 08:53 - MIDI QA Evidence as Product UX

• Treating QA prompts as structured product text lets the same source power internal testing, future manual pages, and customer-facing diagnostics. Automation especially needs proof of intent: doorway used, target chosen, row type, and ownership/shared-PTN behavior. This connects engineering closeout to user trust instead of making QA a private checklist only developers understand.

2026-07-13 09:00 - Proof Language as User Trust

• Automation should not merely say rows exist; it should tell a tester what would make those rows trustworthy. Turning proof requirements into model-owned copy gives us a future path to in-app QA panels, manual text, support bundles, and user-facing confidence badges without rewriting the same logic four ways.

2026-07-13 09:07 - COPY QA as proof-workflow affordance

• MIDI Health now separates three cognitive jobs: COPY REPORT for broad diagnostics, COPY STEPS for next actions, and COPY QA for closeout evidence scaffolding.
• Keeping COPY QA cold/read-only preserves user trust: generating a template is not the same thing as claiming a pass, while still making the manual proof ritual much easier to perform consistently.

2026-07-13 09:10 - QA template plus ledger in one gesture

• The QA template explains what should be tested; the saved receipt ledger shows what has actually been captured. Putting both in COPY QA prevents the classic trap where a checklist feels complete but the evidence trail is somewhere else.
• This mirrors SpaceAge's broader UX philosophy: one obvious button, one coherent artifact, no hidden bookkeeping for the musician-tester.

2026-07-13 09:15 - Separating QA instructions from saved evidence

• COPY QA is for the tester's full ritual; COPY LEDGER is for audit review. Keeping both visible prevents SpaceAge from mixing up instructions with proof.
• This is the kind of small UX affordance that makes a technical release gate feel humane: the proof artifact is there when needed without turning MIDI Health into a spreadsheet wall.

2026-07-13 - QA Wording As Product Trust

When a feature has backend persistence but the user-facing report still says it is future work, the app teaches the tester not to trust the dashboard. Treat report wording as part of the product architecture: a DAW that can explain its own evidence boundaries calmly will feel more professional than one that hides implementation truth behind vague completion percentages.

2026-07-13 - QA Workflow Rows As Trust Language

A QA receipt has two different meanings: what state the evidence is in, and what the user should do next. Keeping those separate in the MIDI Health cockpit makes the feature feel less like a hidden developer ledger and more like a trustworthy preflight checklist. This same pattern can later apply to MIDI hardware profiles, SysEx restore receipts, and render/export validation: one row for durable state, one row for next action.

2026-07-13 - Automation Must Advertise Its Evidence

A hidden automation system feels broken even when the backend works. The current shared-PTN Automation model needs to announce itself wherever the musician is already looking: the Piano Roll strip, Arrangement clip/lane AUTO buttons, and MIDI TASKS. Count-aware labels like AUTO CLIP +2 turn automation from an invisible data structure into a discoverable musical fact, without adding another screen or a competing ownership model.

2026-07-13 - QA Scripts Turn Engineering Into Trust

A MIDI feature is not product-ready just because the backend stores data. Automation needs a musician-readable ritual: open it from every doorway, edit a row, undo it, hear it, export it, re-import it, and save a PASS/FAIL/BLOCKED receipt. This gives SpaceAge a culture of evidence instead of hope, and it keeps launch claims honest without slowing creative flow.

2026-07-13 - Hardware Proof Should Be One Sentence Away

Task: Add a compact MIDI Health summary for the gap between internal MIDI correctness and real-device proof.

Connection: SpaceAge already separates safe internal parsing/routing from external hardware acceptance through Hardware Passports, SysEx restore receipts, pitch-bend trust gates, and timing calibration. A single summary line makes that boundary harder to miss.

Creative extension: The same line can later become the header of a guided MIDI Proof Run: connect controller, test note, bend range, SysEx recall, loopback timing, then save one PASS/FAIL/BLOCKED receipt.

Design reminder: Hardware trust is not a boolean. SpaceAge should say what it knows, what it sent, what the device confirmed, and what the human still needs to verify.

2026-07-13 - Cockpit Truth Beats Dashboard Guesswork

Task: Give MIDI Health compact status fields that a UI card can display without reinterpreting the full report.

Connection: SpaceAge already has detailed MIDI evidence, but long reports are bad cockpit instruments. A musician needs one glance: severity, next action, and the reason. The same pattern can later drive Export Health, Project Health, and Hardware Passport cards.

Creative extension: The cockpit fields can become a color-coded preflight badge near Settings: READY, WARN, PROOF, LATENCY, or BLOCKED. Clicking it can open the deeper MIDI Health page, preserving a clean surface while keeping proof close.

Design reminder: Summaries must be generated from the same data as the diagnostics. No parallel truth systems.

2026-07-13 - Put The Next MIDI Truth Where The Eyes Land

Task: Surface the compact MIDI cockpit status inside the existing Settings MIDI Health panel.

Connection: The backend now knows the short status and next action. Showing those as the first rows turns MIDI Health from a wall of diagnostics into a cockpit: what state are we in, and what should happen next?

Creative extension: This pattern can be reused for future Project Health, Render Health, and Hardware Health callouts. The deep report stays available, but the first visible line should always answer the musician's actual question.

Design reminder: When a summary exists, it should be model-owned and UI-rendered, never rebuilt from UI guesses.

2026-07-13 - Automation Discovery Belongs In The Cockpit

Task: Put Automation visibility and doorway guidance directly into the MIDI Health panel.

Connection: SpaceAge already had accurate Automation summaries, but they lived mostly in copied reports. If the user asks where automation lanes are, the answer should be visible in the same cockpit that reports MIDI readiness.

Creative extension: This same pattern can later support Motion Clips and lane-local automation: every automation ownership model gets a visible doorway row, a current-scope row, and a proof/receipt row.

Design reminder: Do not silently blur automation ownership. Shared PTN data, future clip-local data, future lane-local data, and Motion Clips need separate labels even when they share editing gestures.

2026-07-13 - Visible Automation Needs Test Ownership

Task: Protect the visible Automation doorway language with regression coverage.

What connects creatively: Automation is only trustworthy when it has a visible home. The UI rows are helpful, but the deeper win is making sure the same truth appears in reports, copied support text, and structured payloads. That lets SpaceAge teach the user where performance gestures live without depending on memory or hidden implementation knowledge.

Architecture choice: The Health regression now checks the expression summary, full MIDI Health report, MIDI Next Steps report, and toVar() payload for Automation visibility and doorway instructions. No playback, routing, recording, or automation ownership behavior changed.

2026-07-13 - QA Evidence Needs One Cockpit Sentence

QA receipt data already lived in several places: workflow summaries, next-step text, action queues, receipt stores, and clipboard reports. The creative connection is to treat QA evidence like a cockpit instrument: one concise sentence that can be painted in MIDI Health, exported in structured diagnostics, and asserted in tests. That keeps future automation-lane, SysEx, hardware, and recording closeouts from becoming a scavenger hunt across reports.

2026-07-13 - Doorways Are Part Of The Feature

Task: Make Automation entry points visible as a cockpit row, not just scattered UI affordances.

Connection: SpaceAge now has several valid automation doorways: Piano Roll AUTO, MIDI TASKS, Arrangement AUTO badges, Settings, and MIDI Health. The creative connection is that a feature is not finished until the user can discover it again tomorrow without remembering a hidden route.

Creative extension: Future Motion Clips, clip-local automation, and lane-local automation can use the same pattern: a visibility row, an ownership row, and an action row. That keeps powerful systems from becoming mysterious systems.

Design reminder: Automation scope must remain explicit. Shared PTN automation is useful, but it should never masquerade as clip-local or lane-local automation.

2026-07-13 - A Feature Needs Its Test Ritual Nearby

Task: Surface the Automation hands-on QA script in MIDI Health as Automation QA.

Connection: SpaceAge already generates the QA script from project state. Putting it beside the visibility, path, doorway, and operation rows turns MIDI Health into a guided proof cockpit instead of a diagnostic filing cabinet.

Creative extension: The same pattern can later support render/export proof, synth preset proof, and hardware proof: every serious subsystem gets a visible ritual for confirming it works, not just a hidden report after the fact.

Design reminder: The visible QA script must stay model-owned. The UI should display it, not reinterpret it.

2026-07-13 - Copied Reports Should Match The Cockpit

Task: Put Automation doorway and hands-on QA wording into MIDI Next Steps, not only the full report and Health panel.

Connection: SpaceAge has three ways a tester may consume MIDI truth: visible cockpit rows, short copied next steps, and full reports. When those disagree or omit different details, confidence drops. Keeping them aligned makes the product feel intentional.

Creative extension: This same parity rule can become a release checklist item: any cockpit truth that matters must appear in the visible UI, short support copy, structured diagnostics, and tests.

Design reminder: Copy reports are product surfaces. They should be written for the musician, not just the developer.

2026-07-13 - Lag Needs A Source, Not A Vibe

Task: Add a visible MIDI lag-source classifier to MIDI Health.

What connects creatively: A musician experiences latency as one emotional problem: the hand and sound are not together. But technically it can be audio buffer, direct-input queue age, hardware-output queue age, SoundFont voice preparation, driver/interface path, DIN-vs-USB routing, duplicate input paths, or hardware response. A source classifier turns anxiety into a troubleshooting ritual: first look at what SpaceAge can measure, then test the outside path deliberately.

Architecture choice: The classifier lives in MidiProjectHealthSummary, not the editor. The Health cockpit, copied reports, support payloads, MIDI Timing, and future first-run MIDI setup can quote the same truth. No playback or recording timing behavior changed in this pass.

Future extensions: Pair this with a guided side-by-side USB-vs-DIN timing test. If a mioXL DIN route feels late while direct USB feels better, SpaceAge should help collect evidence instead of making the user guess.

2026-07-13 - Open Ports vs Active Sources

A MIDI rig can have many visible/open ports without all of them being part of the current performance. SpaceAge should keep open-port information available for setup confidence, but user-facing warnings should prioritize active musical sources: if two controllers actually send notes or controllers, that is actionable; if two ports are merely open, it is context.

2026-07-13 14:39 - Fast Diagnostic Test Doors

• MIDI trust-gate work benefits from small, named test doors. A focused readiness-only executable path lets us validate multi-controller behavior quickly, which keeps future fixes from becoming a full-suite guessing game.
• This same pattern should be reused for other fragile subsystems: recording timing, automation write/read, SysEx profile roundtrip, and audio-engine routing. Small doors, fewer mystery rooms.

2026-07-13 14:45 - MIDI Lag Truthfulness

• Felt MIDI latency is a compound truth: controller scan time, DIN/USB/interface path, driver/audio buffer, monitoring path, and recorded-event compensation all stack. SpaceAge should keep separating those layers instead of pretending one slider fixes everything.
• The health-only test door protects the language and math that tells users what to try next. That matters commercially: when a musician feels lag, the app needs to behave like a calm tech in the room, not a mystery box.

2026-07-13 - Automation As A Visible Composition Layer

MIDI automation is stronger when it is treated like a visible musical layer instead of a hidden editor. The CLIP AUTO / LANE AUTO language can later connect to Motion Clips, Flux Nodes, and hardware CC templates: all are variations of the same concept, time-shaped change attached to musical material.

2026-07-13 - MIDI Feel Is A Trust Feature

Live MIDI timing is not only math; it is a confidence ritual. If SpaceAge can tell a user whether lag is likely from audio buffer size, direct-input queue age, duplicate host/direct routing, DIN interface buffering, or SoundFont voice start cost, MIDI Health becomes a musician-facing helper rather than a developer report. This connects MIDI Health, Hardware Passports, and future guided setup into one humane workflow.

2026-07-13 - MIDI Settings Need Room To Tell The Truth

Task: Give MIDI Health and MIDI Hardware settings panels enough room to show readiness guidance without clipped text.

What connects creatively: MIDI readiness is only calming if the words are visible. The backend can be correct, but if the Health or Hardware page clips the final warning, the user experiences the system as evasive or unfinished. This connects the low-latency work, multi-controller diagnostics, Hardware Passport guidance, SysEx safety boundaries, and future onboarding into one rule: serious technical guidance needs physical space in the interface.

Architecture choice: UI layout only. The panels gained height and the Health diagnostic rows became slightly denser. No MIDI routing, recording, SysEx, hardware-output, input-filtering, timing-compensation, or automation-lane behavior changed.

Follow-through: Rebuilt and reran the focused readiness, health, and record-timing test doors. All passed. Remaining trust still comes from real hardware testing on USB and DIN paths.

2026-07-13 - MIDI Chatter As A First-Class Performance Reality

A controller performance is rarely just notes. Mod wheels, expression pedals, pitch bend, active sensing, and clock-like messages create a living stream. Treating that stream as normal rather than exceptional keeps SpaceAge closer to hardware reality: the app should feel like it is listening to the player, not forcing the player to wait behind invisible housekeeping.

2026-07-13 - Controllers As Named Performers

A MIDI input device is not just a wire; in a composition workflow it can behave like a named performer. If SpaceAge knows which performer owns a lane, same-channel traffic from another performer should not sneak into the take. This is a good conceptual bridge toward Hardware Passports, guided setup, and future per-controller performance profiles.

2026-07-13 - Expression Belongs To The Performer, Not Just The Channel

A MIDI channel alone is not enough identity in a real studio. Two controllers can share channel 1, but only one of them may be the intended performer for a lane. SpaceAge should treat device identity as part of the musical gesture so notes, bends, pedals, and CC sweeps arrive from the same intentional source.

2026-07-13 - Setup Payloads As Musical Memory

A take is not just notes plus expressive curves. For hardware and workstation workflows, bank/program/setup messages are part of the memory of what the performer intended to hear. Treating those messages as review-only timeline payload lets SpaceAge stay friendly to hardware without turning every setup event into a confusing drawable automation lane.

2026-07-13 - Consequence-First Automation Copy

Automation are powerful, but they sit on shared PTN data. The creative UI lesson is that we should not merely expose the editing surface; we should teach ownership at the moment of entry. The Arrangement doorway now tells the user that linked clips hear the edit until VARIANT is made. This same pattern should be reused wherever SpaceAge exposes shared data through an object that visually looks local.

2026-07-13 - Preventing Phantom Feature Drift

The Automation docs briefly implied clip-local and lane-local automation existed because that is the architecture we want eventually. That is dangerous: good product language must describe the present truth and reserve future ambition for explicitly marked future sections. The creative connection is that every powerful shared-data feature needs a visible ownership label, otherwise users and developers both start believing the wrong object owns the behavior.

2026-07-13 - Shared Data Needs Shared Language

The phrase shared PTN is doing more product work than pattern-owned. Pattern-owned is a programmer truth; shared PTN is a musician truth because it tells the composer why linked clips change together. This wording cleanup connects Automation to the same mental model as CLONE and VARIANT: reuse is powerful, but independence must be deliberate.

2026-07-13 - Proof Gates Are Part Of The Instrument

The focused MIDI gates are becoming part of SpaceAge's personality. Record timing, readiness, and health checks are not merely developer safety nets; they are the future shape of user-facing confidence. If a musician records four measures, SpaceAge should know how to prove those measures landed where the hands intended. The same idea can later apply to render proof, SoundFont relocation proof, hardware restore proof, and automation ownership proof.

2026-07-13 - Vocabulary Is Part Of The Architecture

Automation are technically pattern-backed today, but the musician-facing truth is shared PTN data. Repeating that phrase in status text, gotchas, glossary entries, and answers keeps the user from thinking a visible clip owns private automation when it does not. This is not cosmetic cleanup; it is an architectural guardrail expressed in language.

2026-07-13 - Count-In Is A Trust Door

Task: Add a regression for the case where a performer starts a note before the count-in recording window opens and releases it after recording opens.

What connects creatively: Count-in is a promise that SpaceAge is listening, but only committing at the musically intended moment. The app should let the performer warm into the first downbeat without accidentally stamping a ghost note into the clip. This same capture-window idea can later serve punch-in, loop recording, and pre-roll.

2026-07-14 - A Clipboard Must Be Musical Memory, Not A Pointer

Task: Make Arranger copy/paste preserve clip-local Automation even if the source clip is edited or deleted after Copy.

What connects creatively: A musician expects Copy to freeze the intention of that moment. Treating the clipboard as a snapshot connects clip automation to the same dependable mental model as copied notes, chord markers, and future Motion Clips. This also gives SpaceAge a reusable rule for scenes, orchestration alternatives, and preset transfers: temporary creative memory must own its payload instead of borrowing a live identity from the project.

2026-07-14 - A Split Clip Must Divide Its Performance Memory

Task: Make every Arranger split partition clip-local Automation into the child clips that actually own those source ranges.

What connects creatively: Clip cutting, timeline insertion, and Ctrl+U now share one range rule instead of behaving like unrelated tools. The same range extractor can later support partial scene capture, Motion Clip slicing, loop extraction, and non-destructive comping. Keeping ticks in source coordinates also means a child can move without rewriting its musical phrasing.

2026-07-14 - Lane Identity Is Musical Identity, Not Screen Position

Task: Make lane-local MIDI automation survive save/load, lane-order changes, duplicate-owner repair, and orphan cleanup.

What connects creatively: A lane is a musical role, not merely the row where it happens to be drawn today. Giving it a permanent identity lets future lane reordering, collapse states, SpaceAge Scenes, mixer routing, hardware profiles, and VST hosting follow the instrument instead of a screen coordinate. Restoring owners before their payloads also establishes a reusable project rule: saved creative data may attach only to a verified musical owner.

2026-07-14 - Performance capture as a two-speed system

Task: Move MIDI recording document commits away from the audio callback without weakening timing or Arrangement length.

What connects creatively: SpaceAge can treat performance as two synchronized layers: the immediate layer makes sound and preserves feel, while the archival layer safely writes notes, drum hits, and expression into the project. The same bounded handoff can later support Motion Clips, retrospective recording, take lanes, and performance diagnostics without asking the audio thread to become a file clerk. Carrying the clip-length contract alongside each note also establishes a broader rule: asynchronous creative data must bring enough ownership context to remain musically correct when it arrives.

2026-07-14 - Two hands, two controllers, one pitch

Task: Let two physical controllers play and record the same MIDI channel and note without stealing each other's release or timing.

What connects creatively: A source session is not only defensive routing data; it preserves the identity of simultaneous performers. That same identity can later support independent sustain pedals, per-controller expression, split performance roles, hardware Scenes, and diagnostics that say which physical path produced a gesture. The implementation stays fixed-size and allocation-free so richer collaboration does not tax the audio thread.

2026-07-14 - One pedal should belong to one performer

Task: Make sustain and channel-mode controls safe when several MIDI controllers share channels and pitches.

What connects creatively: Source-aware controller state turns a technical fix into a future performance model. SpaceAge can eventually remember which keyboard, wind controller, guitar controller, or pedal produced each gesture; expose per-controller diagnostics; build hardware Scenes; and preserve independent expression during collaborative performance. Separating input control channels from routed output channels also prepares lane instruments to receive expressive hardware without forcing the external device to mirror the lane's destination channel.

Subagents: Averroes audited source lifecycle and remapped-channel semantics. Herschel designed the two-controller regression matrix. Their findings were integrated into the processor and focused Release gates.

2026-07-14 - A disconnected controller should leave no ghost performer

Task: Retire a physical MIDI controller's notes, sustain, expressive state, and recording ownership as soon as its router generation disappears, while preserving every other connected performer.

What connects creatively: Source generation is becoming SpaceAge's durable notion of a live performer. The same compact identity can later power per-controller diagnostics, guided hardware setup, controller-specific mappings, collaborative performances, hardware Scenes, and clear recovery messages such as "This pedal disappeared; Controller B is still active." Safe slot reuse also gives future hot-plug workflows a predictable foundation instead of treating reconnection as a global Panic event.

Subagents: Dalton audited the zero-allocation router-to-processor retirement boundary and memory ordering. Peirce designed the disconnect, stale-queue, unaffected-controller, and slot-reuse regression matrix. Their findings were integrated and all focused Release MIDI gates pass.

2026-07-14 - Hardware should remain present when the window disappears

Task: Keep physical MIDI unplug/reconnect discovery active when the SpaceAge editor is closed, without moving device work onto the audio thread.

What connects creatively: A controller is part of the performance, not part of the window. Processor-owned discovery makes hardware behavior match that musical truth and gives future guided setup, controller health, hardware Scenes, and reconnect coaching one durable source of device state. The locked route-demand snapshot also establishes a reusable rule for the app: UI and project objects publish compact intent, while one runtime owner performs scarce external-resource work.

Subagents: Banach audited JUCE message-thread lifetime, shutdown ordering, and single-owner constraints. Ramanujan designed the no-editor, unchanged-device, unplug, stale-event, unaffected-controller, and shutdown regression matrix. Their findings shaped the implementation and verification boundary.

2026-07-14 - Treat hardware setup as one musical sentence

Task: Safely turn a reviewed RPN or NRPN setup card into hardware-bound MIDI without leaving a synth in a half-selected parameter state.

What connects creatively: A setup card is not a pile of unrelated CC messages. It is one intention: select a parameter, provide a value, then leave the controller state safe for whatever comes next. Publishing that intention atomically creates a reusable transaction model for future Yamaha XG editors, hardware Scenes, guided device setup, and SysEx workflows. Receipts describe what SpaceAge actually knows - queue acceptance - while leaving external-device verification to the performer and the hardware.

Subagents: Descartes audited the existing queue, receipt, and Hardware Passport contracts. Planck designed the adversarial atomicity, ordering, policy, and evidence matrix. Their findings were integrated into the production path and focused Release tests.

2026-07-15 - A captured dump is an inbox item, not a command

Task: Let SpaceAge receive one hardware SysEx dump safely, review it, preserve it, and associate it with the right Hardware Passport without creating an accidental send path.

What connects creatively: Treating incoming SysEx as mail creates one reusable language for patch librarians, Yamaha XG editing, hardware backup, project archives, and guided recovery. A capture receipt says what SpaceAge truly knows: these bytes arrived and passed structural checks. Later device-specific parsers can add names, checksums, and acknowledgement meaning without weakening that honest boundary.

2026-07-15 - A control gesture belongs to the intention that heard it

Task: Keep MIDI Learn and mapped host control responsive without allowing an old queued controller movement to capture a newly armed target.

What connects creatively: The Learn-generation token makes intent part of the gesture. That same rule can later govern automation write passes, hardware Scene capture, temporary controller assignments, and retrospective performance capture: delayed data may complete only the creative action that owned it when it arrived.

Subagent: Locke audited the realtime MIDI control path and identified the discarded queue plus audio-callback mutex/host-notification hazard. The finding was integrated as a bounded worker/message-thread handoff with an adversarial focused gate.

2026-07-15 - Hardware replies are part of a conversation

Task: Connect confirmed SysEx restores to incoming hardware ACK, NAK, WAIT, CANCEL, and timeout evidence without confusing capture, queue acceptance, or device state.

What connects creatively: Treating a restore as a conversation gives Hardware Passports, Yamaha XG editors, hardware Scenes, patch librarians, and guided recovery one shared interaction model: SpaceAge sends an intention, waits without blocking music, and records what the hardware actually said. WAIT preserves the conversation, ACK or rejection closes it, and silence remains visible rather than becoming imaginary success. The same model can later drive friendly UI language such as "waiting for QY-100," "device asked for more time," and "restore rejected - review this passport."

Subagents: Kept local for this closeout because the final work crossed processor runtime, MIDI Health, and focused tests in one narrow dependency chain. No subagent result was integrated in this pass.

2026-07-15 - A physical control should meet the software before taking control

Task: Make high-resolution MIDI Learn expressive enough for careful sound design while preventing a hardware knob from making a loaded project jump on first touch.

What connects creatively: Soft takeover turns controller movement into a handshake: the hardware first reaches the sound as it currently exists, then assumes authorship. That same interaction can later support automation write passes, Scene morphing, synth-patch editing, and temporary performance macros. Canonical MSB learning also keeps the interface simple: the user learns one control while SpaceAge quietly incorporates its fine LSB partner when the hardware provides it.

Subagents: Kept local because the mapping graph, realtime pairing state, host notification boundary, summaries, and existing tests formed one tightly coupled change. No subagent result was integrated in this pass.

2026-07-15 - Selection is the edit contract

Task: Restore reliable Arranger clip-length editing and lane instrument replacement.

What connects creatively: A visible selection should be the single source of truth for every contextual editor. Clicking a clip now transfers authorship from the playhead to that clip, so geometry, notes, automation, and future clip decorations can all follow one predictable contract. Choosing an Instrument Bay sound also behaves like docking a sound into the lane's own Instrument Bay berth: the musical character is copied, but the lane keeps its identity, mixer route, and independent future.

Subagents: Kept local because clip selection, inspector targeting, lane identity, backing instrument state, mixer routing, and Undo formed one tightly coupled correction.

2026-07-15 - Hardware conversations need an address

A SysEx response is not meaningful merely because it arrived after a send. In a studio with several connected instruments, the response must belong to the same hardware conversation. SpaceAge now treats input-device identity as part of the restore transaction, not incidental diagnostic metadata.

This pattern should be reused for live dump capture, hardware timing calibration, patch librarians, and future XG/DX editors: every hardware conversation should name its source, destination, safety boundary, and evidence. That turns multi-device support from a collection of global listeners into a dependable set of addressed conversations.

2026-07-15 - A hardware inbox also needs an address

Task: Prevent a one-shot SysEx capture armed for one Hardware Passport from accepting a valid dump emitted by another connected device.

What connects creatively: Source-pinned capture and source-pinned restore are now two sides of the same addressed hardware conversation. The pattern can power patch librarians, Yamaha XG editors, timing calibration, hardware Scenes, and guided recovery: every inbound artifact belongs to a named physical source, while unbound Passports remain visibly generic. The same pass attaches an intention generation to queued capture data, so a message heard before Cancel/rearm cannot complete a newer capture.

Subagents: Kept local because the callback queue, capture state, readiness wording, and focused regression formed one small atomic dependency chain. No subagent result was integrated in this pass.

2026-07-15 - QA evidence should travel with the music

Task: Make MIDI closeout PASS/FAIL/BLOCKED evidence durable without turning test scaffolding into imaginary proof.

What connects creatively: A project-owned evidence ledger can become more than an engineering checkbox. The same append-only, source-labeled structure can later support guided hardware setup histories, restore conversations, latency-calibration receipts, collaborator diagnostics, and support bundles. The crucial distinction is preserved: a template suggests what to test, while only a completed and explicitly saved receipt records what was actually observed.

Subagents: Kept local because the receipt model, processor mutex ownership, project serialization, and focused regression formed one narrow atomic dependency chain. No subagent result was integrated in this pass.

2026-07-15 - QA receipts as a SpaceAge flight log

The append-only MIDI QA ledger can become more than engineering bookkeeping. It is a project flight log: each saved result preserves what was tested, by whom, when, against which device/log evidence, and under which safety boundary. The same model can later support support bundles, release-candidate certification, classroom lab verification, and hardware-profile confidence badges without inventing a second evidence system.

The UI deliberately presents one next unsatisfied category instead of a wall of forms. That connects the existing MIDI Health cockpit, FIX NEXT routing, and persistent project state into one progressive workflow. REVIEW never silently edits old evidence; a retest appends another record under the same persistent key so history remains inspectable.

2026-07-15 - The latest flight check owns readiness

Task: Make durable MIDI QA receipts advance or reopen customer-facing protocol closeout.

What connects creatively: An append-only ledger can preserve history without trapping the product in yesterday's result. The newest valid result becomes the present-tense flight check: PASS closes one category, while a later FAIL or BLOCKED reopens it. This same pattern can later support per-device confidence badges, support bundles, classroom lab certification, and release-candidate audits. Build revision, device identity, and firmware provenance would be valuable future dimensions, but they should extend this ledger rather than create a second proof system.

Subagent: Bohr performed a read-only review of receipt semantics and UI consumers. It found that MIDI Protocol bypassed receipt projection and that FAIL/BLOCKED evidence incorrectly disabled retesting. Both findings were integrated; Bohr edited no files.

2026-07-15 - Hardware Passports as conversation contracts

Task: Replace generic SysEx manufacturer guesses with explicit, persistent Hardware Passport response policy.

What connects creatively: A Passport can become the contract for every hardware conversation: which physical ports participate, which dialect is spoken, which device address is expected, which checksum family is verified, and whether SpaceAge may act automatically. The same declarative model can later power Yamaha XG editors, DX patch librarians, Roland parameter editors, guided setup, support bundles, and per-device confidence badges without scattering product-specific assumptions through the MIDI parser.

The conservative default is part of the design, not missing polish. Unknown hardware stays useful through capture and manual inspection while automatic behavior is earned by verified policy and evidence.

Subagent: Bohr performed a read-only policy-boundary audit. Its finding that generic Roland checksum inference overclaimed support was integrated, along with normalization of both bulk and single-profile setters. Bohr edited no files.

2026-07-15 - One repeatable audio contract for every instrument

Task: Verify that every self-contained synth and drum lab can instantiate, accept a note, emit finite non-silent audio, release cleanly, and retire its voices, with dedicated coverage for the new TG55 engine.

What connects creatively: A shared processor-level audio contract turns the instrument collection into a dependable Instrument Bay rather than a collection of special cases. The same focused gate can later collect peak, tail, CPU, tuning, sustain, pitch-bend, and modulation evidence without inventing separate test machinery for each engine. Voices now latch the engine that created them, so changing an instrument affects future notes without transforming notes already sounding.

Asset-backed SoundFont and Quasar playback remain a separate contract: a valid asset is required, and an all-silent render is a failure rather than a successful sample export.

Subagents: Curie inventoried the complete engine registry and audio paths. Hubble audited TG55's render lifecycle and focused tests. Their findings were integrated into the registry cleanup, TG55 voice retirement, direct drum note-off handling, state sanitization, and the focused audio smoke gate.

2026-07-15 - Mixer subpages are temporary inspection state

Task: Close every channel-strip subpage when the user leaves Mixer so returning to Mixer restores the meter-first overview.

What connects creatively: Meter activity is the Mixer's system-status language, while compressor, saturation, EQ, and send pages are temporary inspection tools. Resetting only their presentation state on page exit preserves every sound and routing decision while making each Mixer return immediately legible. The same rule can guide future transient inspectors: keep authored data persistent, but restore the workspace's primary overview after the user leaves its page.

Subagent: Boyle traced the authoritative page transition and confirmed that mixerMoreVisible alone owns open/closed presentation state. Its recommendation to preserve the inert mixerPanelMode, bank choice, APVTS attachments, and audio state was integrated. Boyle edited no files.

2026-07-15 - A Hardware Passport becomes useful through a safe handshake

Task: Continue the Mixer closeout and reconnect Hardware Setup project drafts to a truthful, target-aware test note.

What connects creatively: The Hardware Passport is becoming the address book and contract for an external instrument. A template can suggest safe defaults, but only the living lane supplies musical intent, only the Passport supplies hardware identity, and only an explicit output route supplies a destination. Keeping the review plan cold and making the confirmed Note On/Note Off pair atomic creates a reusable handshake for pitch-bend tests, timing calibration, patch librarians, Yamaha XG editors, and guided hardware onboarding.

The short-lived rollback follows the same intent model: it can undo the draft it owns, but it expires as soon as newer project intent appears. The Mixer change applies that distinction visually: authored mix data persists, while temporary inspection panels reset when the user leaves the workspace.

Subagents: Hegel ranked the remaining compatibility stubs and confirmed that the target-aware test note was the immediate dependency, followed by the MIDI import commit bridge. Lorentz audited the MIDI documents, identified prior overstatement of the test-note bridge, and supplied the correction and rollback-lifetime wording integrated here. Both agents were read-only.

2026-07-15 - Reviewed MIDI import is a transaction, not a shortcut

Task: Replace the compatibility importer with one truthful inspect/apply path that honors reviewed channel, expression, setup, SysEx, metadata, split-lane, and Undo choices.

What connects creatively: The review plan is now a cold contract. Inspect-only can power previews, diagnostics, and future drag/drop review without touching the song. Commit applies that same contract under one outer checkpoint and returns a receipt based on what was actually created. This pattern can be reused by stem-package import, hardware patch librarians, scene recall, and future project conversion tools.

Musical time remains PPQ-native during import, so tempo-map changes do not bend note positions. Melodic payloads use the 4,096-step clip timeline rather than the 64-step drum surface. Split-channel import allocates lane-owned payloads without treating obsolete pattern-chain references as song ownership. JUCE's inserted retrigger safety note-offs are recognized before FIFO pairing so overlapping same-pitch notes retain their original lengths and release velocities.

Subagents: Boyle traced the legacy mutator, checkpoint boundary, and PPQ risks. Noether audited the request/result contract and required receipt semantics. Both were read-only; their findings were integrated into the transaction bridge and regression coverage.

2026-07-15 - A MIDI stem package is a portable, reversible project boundary

Task: Replace the compatibility stem-package placeholders with real isolated-lane export, inspectable support files, repair blocking, and one-transaction re-import.

What connects creatively: A package is more useful than a pile of MIDI files when it carries enough evidence to explain itself. The full Arrangement file gives collaborators a single timing reference; isolated lane stems preserve orchestration choices; the manifest gives SpaceAge a machine-readable contract; the README gives a human the same story; and standard checksums let outside tools verify the payload. That same package/inspection/commit pattern can later serve scenes, hardware setup bundles, chord-progression libraries, Quasar instruments, and project recovery without inventing unsafe one-off importers.

Import reuses the reviewed MIDI-file transaction and one outer checkpoint. Missing or altered files block mutation, inspect-only remains cold, and cancellation cannot masquerade as completion. The checksum implementation now uses the published FNV-1a-64 offset basis, backed by the canonical hello test vector, so SpaceAge evidence agrees with external tools.

Subagents: Volta audited the export contract and found the active placeholder, missing compiled lane exporter, fake historical checksums, and the FNV offset-basis defect. Franklin was assigned the independent import/repair audit, but its task context was unavailable after the session transition; the import path was therefore verified locally against the active plan/result models and behavioral regression suite.

Follow-up: safety is part of the package format

Capacity is now checked before the import checkpoint, so a package that cannot fit remains a reviewable artifact rather than creating empty Undo history. Export cancellation has a behavioral contract too: cancelling after payload work has begun removes the app-created partial folder. These same two rules should govern Quasar packages, hardware librarians, scene bundles, and future recovery archives.

2026-07-15 - A green happy path is not a transaction boundary

Task: Close the stem-package edge cases found by independent review.

What connects creatively: Portability requires refusal to be as trustworthy as success. SpaceAge now reserves lane, clip, and pattern capacity before mutation; rechecks package integrity immediately before each stem; and restores project plus Undo/Redo state if cancellation or failure occurs after work starts. Overlong stems are refused visibly instead of being silently truncated. This all-or-nothing model should be reused by Quasar capture, hardware librarians, scene recall, and project conversion.

Subagent: Turing independently reviewed the completed path and found the long-timeline truncation, pattern-capacity, cancellation-checkpoint, integrity time-of-check/time-of-use, enharmonic-key, cleanup, and manifest self-size risks. The actionable findings were integrated or explicitly bounded; Turing edited no files.

2026-07-15 - One MIDI route should explain input, recording, playback, and export

Task: Repair raw-pattern channel export and armed-lane live-input channel filtering after the broad regression suite exposed disagreement between audio, diagnostics, and recorded expression.

What connects creatively: A lane's route is not merely an output preference. It is the shared contract that answers four user questions: which controller channel may enter, which instrument hears it, which channel gets recorded, and which channel leaves through playback/export. SpaceAge now observes incoming channel voice messages before filtering so the MIDI Health view can explain both rejected and accepted input, while authored notes and expression are normalized to the same lane output route. Raw patterns deliberately remain portable outside the Arrangement: General MIDI drums use channel 10, Piano Roll notes preserve their authored channels, and Chord Engine material uses channel 1.

This same observation-before-policy rule can support a future guided hardware setup assistant: show what physically arrived, explain why a lane rejected it, and offer a one-click route correction without silently changing the project.

Subagent: Chandrasekhar independently audited the raw exporter, confirmed that the fixture matched the documented convention, and identified the missing key-signature event in addition to the channel literals. The findings were integrated; the agent edited no files.

2026-07-15 - Preserve setup payloads without pretending they are automation

• Task: Close the pressure/aftertouch, expression persistence, and long channel-10 import failures in the MIDI foundation suite.
• Creative connection: SpaceAge can use one timeline payload container for both editable performance expression and recall-oriented setup messages, provided the UI exposes editability as a property rather than deleting non-editable rows. This keeps bank/program/RPN/NRPN data available to future Hardware Passport editors while preventing accidental curve editing of device setup.
• Long-form drum connection: A channel-10 file longer than the Drum Composer's 64-step surface now remains a full Arrangement payload. The classic grid stays focused, while the shared note model supplies linear playback beyond that surface.
• Subagent: Mendel traced the persistence loss to the setter and summary predicates; serialization itself was sound.

2026-07-15 - A route should explain itself, not merely work

Task: Close the final broad MIDI readiness failures after Hardware Passport, SysEx, setup-card, routing, recording, import/export, and sync behavior were already passing.

What connects creatively: Live MIDI diagnostics now name the path that owns the armed lane: host, direct physical controller, deliberately combined host plus direct, blocked input, or no armed lane. The same route contract drives monitoring, recording, health reports, and support language, so the user does not have to infer why a controller is silent or duplicated. This pattern can later support one-click repair actions and a guided hardware setup assistant without inventing a second routing model.

A copied health report also carries a cached headline. Tests that deliberately mutate a copy must invalidate that headline before asserting recomputed wording; production reports remain immutable snapshots. That distinction applies to future render receipts, scene summaries, Quasar packages, and hardware librarian evidence.

Subagent: Raman independently classified the remaining failures. It confirmed the Hardware Passport/SysEx and setup-card failures were stale log entries already fixed, identified the missing production live-routing verdict, and isolated the cached-headline test-fixture error. Raman edited no files; the findings were integrated on the main path.

2026-07-15 - Automation ownership also owns a clock

Task: Correct MIDI-expression playback, editing, and export where Shared PTN, Clip Local, and Lane Local data had been merged despite using different timelines.

What connects creatively: Ownership is not only about who may edit data; it also defines when that data exists. Shared PTN and Clip Local gestures repeat with their musical source. Lane Local gestures live on the absolute Arrangement timeline, continue through silent clip gaps, and must not restart at every clip boundary. That distinction gives future Motion Clips a clean architectural choice: attach motion to reusable musical material, one placed clip, or the lane-level performance timeline without inventing another ambiguous automation system.

Arranger mutation follows the same clarity principle. CUT, paste, and clone now preflight required pattern, clip, and section capacity before creating one Undo checkpoint and before changing state. A refusal leaves the project untouched. Duplicate unreachable paste paths were removed so one reviewed implementation owns the behavior.

Subagents: Harvey independently identified the mixed timing-domain defect and specified the owner contract. Dalton independently found mutation-before-capacity risks, preserved-gap fragment risks, and duplicate paste paths. Their findings were integrated; neither agent edited files.

2026-07-16 - A fixed finish line protects the product from its own imagination

Task: Convert the remaining SpaceAge concerns into one stable release-readiness contract instead of continuing to report percentages against changing scopes.

What connects creatively: SpaceAge is intentionally fertile; a new instrument, hardware editor, Motion Clip idea, or visual flourish can appear at any time. That creative strength needs a boundary that does not punish progress. Release Readiness Checklist 1.0 fixes the current shipping denominator at 72 named checks. New ideas can enter the backlog without silently moving today's finish line, while a future checklist revision can deliberately adopt a larger promise.

The companion convergence runner maps existing automated tests to checklist evidence IDs. It keeps automated proof useful without confusing a green backend fixture with a complete human workflow. This same evidence vocabulary can later power an internal release dashboard, GitHub release checks, customer support receipts, and school/site deployment certification.

2026-07-16 - Changing an instrument must not remix the song

Task: Separate a lane's instrument identity from its mixer-owned state when the user chooses a replacement sound.

What connects creatively: Instrument choice and mix choice are orthogonal creative decisions. A composer should be able to audition a bass, bell, SoundFont, or future VST without losing the gain staging, panorama, sends, EQ, compression, or saturation already shaping that lane. The same boundary also protects the explicit Pad Settings clipboard. This becomes the ownership rule for the future Instrument Bay: copy sound-generation state into the lane instance, preserve lane/mixer state, and never make auditioning destructive.

2026-07-16 - Repeated clips carry two honest clocks

Task: Make every Arrangement consumer agree on the duration of a repeated clip without destroying its reusable source-cycle identity.

What connects creatively: A repeated clip has two valid lengths: the source cycle the Piano Roll edits, and the occupied duration the Arrangement displays, moves, overlaps, exports, navigates, and automates. SpaceAge now names that distinction in one canonical helper instead of letting each feature improvise its own arithmetic. That same model can later support visible repeat braces, per-repeat variation, loop-count handles, and a deliberate Flatten Repeats command without changing the underlying clip contract.

Operations that would require materializing repeats are now honest about that boundary. CUT on a repeated clip and paste through the middle of a repeated clip refuse before mutation rather than silently producing incorrect playback. A future Flatten Repeats command can turn the occupied performance into explicit source material, after which ordinary CUT and interior paste become unambiguous.

Subagents: Sagan classified duration ownership across the processor and editor and found the drum-chain double-multiplication defect. Ramanujan supplied the regression matrix covering geometry, overlap, gaps, copy/paste, CUT, persistence, and timeline boundaries. Their findings were integrated on the main path; neither agent edited files.

2026-07-16 - Timeline Edges Are Product Constraints, Not Drawing Limits

What connects creatively: A fixed arranger boundary is part of the musical data contract, not merely the right edge of a canvas. SpaceAge now validates a clip by its occupied performance (start + source-cycle length x repeats) at the processor boundary, so UI edits, project restore, export, playback, and future remote-control surfaces cannot disagree about whether a clip exists. Exact fits ending at step 4096 remain valid; anything beyond it is refused without mutation.

Compound edits need a second layer of prediction. A move, resize, clone, paste, section-assisted move, or snap can be individually valid yet force a later clip beyond the boundary when overlap resolution pushes the lane forward. The editor now simulates the resolved lane before creating an Undo checkpoint. Refusal therefore preserves the project and Redo history instead of creating a no-op transaction.

Deferred Design: Flatten Repeats

Flatten Repeats should be a deliberate, single-checkpoint operation, not an implicit side effect of CUT or paste. It will replace one repeated clip with explicit repeat instances whose source-cycle length, source offset, lane ownership, instrument ownership, expression ownership, and total occupied duration are preserved. Capacity and timeline-boundary checks must succeed for the entire result before any clip is written. Only after that conversion should interior CUT, per-cycle variation, and paste-through-repeat operations become available. This design is recorded now; no half-working customer command is exposed.

2026-07-16 - Refusals Are Not Transactions

Task: Harden Arranger additions, section assignment, and lane rename so impossible or unchanged actions do not consume Undo history.

What connects creatively: Undo is part of the composer's trust model. A refused action is feedback, not a project edit; a same-value selection is inspection, not a project edit. SpaceAge now validates the final clip landing position before checkpointing or clearing a fresh payload, section assignment checkpoints only when capacity exists and the label will change, and a lane-rename dialog revalidates its lane when SAVE is pressed. This protects Redo, preserves the eight meaningful Undo slots, and gives future Motion Clips, automation edits, scene changes, and hardware librarian actions one reusable transaction rule: validate the complete intent, prove there is a delta, checkpoint once, then commit.

The focused Arranger gate now constructs the real editor, fills the drum lane exactly to step 4096, invokes the actual + ADD DRUM CLIP callback, and proves the refusal changes neither clip storage nor Undo history. The broad application self-test also passed afterward.

Subagents: Kepler audited editor mutation paths and identified the high-risk checkpoint-before-refusal cases. Noether designed a broader right-edge gesture fixture; its canvas-resize portion is intentionally deferred, while its recommendation to test the real editor path was adopted. Neither subagent edited files.

2026-07-16 - One Gesture, One Musical Decision

Task: Make Arranger inspector edits, notes, lane states, section/clip gestures, and chain reordering obey one predictable Undo transaction model.

What connects creatively: A composer's physical gesture is the natural transaction boundary. A slider drag may emit dozens of values, but it expresses one decision; typing a note across several keystrokes is one annotation session; clicking a snapped object without moving it is no decision at all. SpaceAge now checkpoints the first accepted delta in a slider or notes session, groups every later update into that same action, and refuses to consume history for unchanged values, stale targets, preserved gaps, or snapped no-ops. The same policy can govern future automation drawing, Motion Clips, scene orchestration, and hardware-librarian edits.

The audit also connected UI vocabulary to persistence. The full Classical Thinking section catalog was visible but an older 73-label processor clamp meant the newest labels could not survive model writes. The label range now has one processor-owned maximum of 105, used by direct edits, form application, paste, and save/load. A customer-facing choice must be real all the way down.

Subagents: Kepler mapped inspector no-op, stale-target, slider-lifecycle, section-range, and note-edit risks. Noether independently audited lane mute/solo, chain reorder, and snapped section/clip gestures. Their findings were integrated on the main path; neither subagent edited files.

2026-07-16 - Preflight the Whole Musical Decision

Arranger bulk commands should behave like rehearsed musical decisions, not sequences of hopeful mutations. Song forms, clip cloning, and preserved-time removal now construct or reserve their complete result before touching the model. This connects Undo quality, timeline safety, pattern ownership, and user trust: one click either produces one coherent reversible result or changes absolutely nothing.

The same pattern can guide future orchestration scenes, arrangement templates, clip-group transforms, and render preparation. Their previews can reuse the canonical plan that execution validates, making user-facing summaries and backend safety describe the same proposed operation.

2026-07-16 - Automation Objects Must Be Singular And Atomic

Task: Remove an unreachable Arranger mutation surface and harden Automation point/group editing.

What connects creatively: A hidden control is still architecture. The obsolete eight-row chain editor was permanently invisible but continued to construct callbacks that bypassed the current transaction contract. Removing it reduces ambiguity and ensures future work extends the visible Arrangement Canvas rather than accidentally reviving a second, contradictory editor.

Automation points now behave as singular timeline objects: one editable lane may have only one point at a given tick after a move. Single and group moves refuse occupied targets, and stale group selections are all-or-none rather than partially moving whichever members still resolve. This same model rule can support future Motion Clips, hardware-controller automation, and scene morphing because correctness no longer depends on which UI initiated the edit.

Undo follows musical intent. CLEAR STEP and graph erasure checkpoint only when matching data is actually present, and ADD POINT refuses an already occupied lane/tick before checkpointing. Empty gestures therefore remain empty, preserving meaningful history.

Subagents: Arendt proved the old direct chain row was permanently unreachable and catalogued its dormant transaction violations. Beauvoir audited Automation and identified collision, partial-group, duplicate-point, and empty-checkpoint risks. Their findings were integrated on the main path; neither agent edited files.

2026-07-16 - Armed-lane source identity as a trust contract

AUTO routing is now intentionally boring: an armed lane with a pinned physical input receives only that direct device; an armed lane without one receives the host/plugin MIDI stream. Merely opening or previously observing another controller can no longer change the source behind the musician's back. This same lane-owned identity contract can later anchor controller maps, hardware editor profiles, MPE zones, and per-device automation without creating another competing routing system.

Equal-tick MIDI insertion order is preserved as musical data. That makes compound protocol gestures such as RPN/NRPN selection and data entry deterministic, while SysEx Passport ownership and capture cancellation now follow atomic, explicit lifecycle rules. UI edit preflights apply the same principle to automation: a stale selection cannot manufacture an empty Undo action.

2026-07-16 - Performance MIDI Has Two Clocks

Incoming performance MIDI needs two related but distinct coordinates. Playback uses the event's exact sample inside the current audio block so notes, releases, sustain, bend, and modulation reach the instrument together at the musician's intended instant. Recording uses the compensated capture position so the written note remains aligned to the performance after device and buffer latency are considered. Collapsing those coordinates into one value either makes monitoring late or records the wrong rhythm.

SpaceAge now accepts and routes each incoming event once, then preserves it in one bounded, insertion-ordered performance queue until the renderer reaches that sample. This same ordered-event contract can later support MPE dimensions, automation capture, hardware echo, and per-note expression without creating parallel timing systems.

Subagents: Kant audited sample-order and protocol-order hazards. Ohm designed the regression matrix for delayed events, sustain, expression, equal-time stability, direct hardware, and two-controller ownership. Neither subagent edited files.

2026-07-16 - Authored Expression Must Reach The Same Sample As The Music

Task: Preserve exact sub-block timing for sequencer-authored MIDI expression while keeping plugin and hardware output timestamps unchanged.

What connects creatively: Shared PTN, Lane Local, and Clip Local expression are not merely editor drawings; they are timed musical events. A controller move at sample 1200 must begin affecting the instrument at sample 1200, just as a note or accent does. SpaceAge now stages due internal expression in one fixed-capacity, stable queue and applies it immediately before rendering the matching sample. Live incoming performance remains later in the same-sample precedence order, so a musician can override authored automation without a second control system.

This event boundary can serve future Motion Clips, per-note expression, chord-articulation gestures, and MPE dimensions. They can share one sample-domain dispatch contract instead of each feature inventing a block-level approximation.

Subagents: Hooke audited sequencer-expression timing and identified the premature block-start state update. Laplace audited hardware-output cancellation and found route, queue, panic-priority, delay, and device-lifetime races. Neither subagent edited files.

2026-07-16 - Prepared hardware routes and a priority safety path

The hardware MIDI router now treats a lane route as one published capability: endpoint slot, target, output channel, and route epoch travel together. That same structure can later support MPE member-channel allocation, external-automation destinations, hardware-scene recall, and per-lane device status without teaching each feature a separate routing model.

The new priority safety queue is useful beyond Panic. It establishes a general emergency path for operations that must outrank musical traffic, including transport stop cleanup, device disconnect recovery, project replacement, and future controller-profile changes. Ordinary delayed messages can no longer hold safety work hostage.

The next creative and engineering connection is a virtual MIDI-output harness with a manual clock. It will let us prove reroute cancellation, reset cancellation, panic priority, and equal-deadline ordering deterministically. That same harness can later power hardware-editor simulations and regression tests for Yamaha XG, Roland SysEx, and MPE without requiring physical gear on every development machine.

2026-07-16 - Virtual hardware as a reusable MIDI laboratory

The manual-clock virtual-output harness turns hardware MIDI behavior into deterministic software evidence. SpaceAge can now simulate named destinations, advance time deliberately, and inspect the exact messages that would have crossed a cable. This closes the immediate scheduler proof and creates a foundation for future Yamaha XG editors, Roland device profiles, MPE zone routing, scene recalls, and failure-recovery tests without requiring every physical device on every development machine.

The scheduler contract is now explicit: route/reset epochs retire stale traffic, safety commands outrank future musical deadlines, and equal-deadline messages retain insertion order across live and recall queues. These are protocol-building blocks, not one-off test accommodations.

2026-07-16 - Coalesced safety intent and stable device identity

Emergency hardware actions are now stored as coalesced intent rather than a small queue of duplicate messages. Repeated Panic and reroute requests collapse by device generation and channel, so the commands that prevent stuck notes cannot be crowded out by their own duplicates. This same pattern can support future transport-stop cleanup, hardware-scene transitions, and MPE zone release.

Hardware routes now combine a stable operating-system device ID with a lifetime generation. The timer reconciles disappearance and return outside the audio callback; old-generation musical and safety traffic cannot cross into a replacement endpoint. Lanes, MIDI Clock, recall, and future hardware editors should all reuse this identity contract instead of caching raw output slots independently.

Subagents: James audited safety capacity, shared-route effects, and progress reporting. Dalton audited endpoint lifetime, disconnect/reconnect, clock-route identity, and stale scheduler accounting. Neither subagent edited files.

2026-07-16 - Expression Recording Must Respect Clip Shape

Task: Fix the focused MIDI record-timing regression where a note recorded correctly into a 64-step Arrangement clip, but same-block CC/pitch expression could shrink the pattern length back to the last expression tick.

What connects creatively: Notes, pitch bend, aftertouch, and CC gestures are one performance, not separate bureaucracies. If a musician records a bass line with mod wheel movement into a clip, the automation should inherit the same clip-local Arrangement promise as the notes. This same rule should guide future Motion Clips, scene variations, and any per-lane performance capture: the expressive layer follows the musical container.

Architecture choice: MIDI expression recording now carries the same minimum pattern-length floor as note recording and commits by preserving the larger of existing length, clip-local source length, and inferred event length. The quick SPACEAGE_MIDI_RECORD_TIMING_ONLY gate now proves the processBlock Arrangement recording case stays at 64 steps.

2026-07-16 - Effective Automation Should Tell The Same Truth Everywhere

Task: Close the gap between Automation ownership, restore, readiness, export, and effective clip display.

What connects creatively: Automation is not a sidecar doodle; it is part of the clip's musical weather. Shared PTN, Lane Local, and Clip Local data must layer the same way whether the user is looking at a badge, exporting MIDI, restoring a project, or opening Automation. This same rule should guide future Motion Clips, scene orchestration, and hardware controller lanes: each surface may have different controls, but they must describe one effective musical reality.

Architecture choice: The effective clip view now layers Shared PTN, Lane Local, then Clip Local automation. Tests were corrected where they still assumed the older Shared+Clip-only preview. The remaining trust boundary is not software plumbing; it is human/hardware evidence on real USB/DIN rigs.

2026-07-16 - MIDI Closeout Digest as a Product Compass

A compact closeout digest is more than internal QA text: it can become the spine of a customer-facing or beta-tester confidence panel. The same machinery can eventually drive an in-app 'What should I test next?' helper, a release-readiness checklist, or a guided MIDI setup assistant that explains not only what is broken, but where to go, what evidence matters, and whether an action is cold, warm, or hot. Keeping this digest report-only preserves safety while letting the UI become more intelligible.

2026-07-16 - One-Line MIDI Closeout As A Trust Signal

Task: Make the MIDI 1.0 finish-line state immediately readable without forcing the user or developer to parse a long diagnostic report.

What connects creatively: A good music app should not make its own development and setup status feel like a mystery. The same one-line closeout headline can later become a beta tester prompt, a guided setup breadcrumb, or a support receipt header. It turns technical readiness into a visible cockpit instrument: percent ready, what remains, where to go next, and how dangerous the next action is.

Architecture choice: The headline is report-only and safely derived from existing protocol coverage data. It does not touch live MIDI timing, routing, playback, recording, or hardware sends.

2026-07-16 - Automation QA As Musical Ownership Proof

Task: Tighten the Automation closeout checklist so it tells a tester exactly what must be proven.

What connects creatively: Automation ownership is not merely a code model; it is a composing promise. Shared PTN is for linked musical identity, Clip Local is for one-off variation, and Lane Local is for arrangement-time expression that floats above clips. Those three ideas can later power Motion Clips, scene orchestration, and hardware control lanes if we keep the ownership language concrete now.

Architecture choice: The checklist now requires tests that mirror how a musician will think: clones should share, variants should diverge, local edits should stay local, lane gestures should follow lane time, and pitch bend should remain raw and honest unless a Hardware Passport proves an external range.

2026-07-16 - Compact Proof Cues As UX Safety Rails

A short QA summary can function like UI microcopy: it should not merely say what area is next, it should remind the tester what kind of reality must be proven. The Automation cue now behaves like a tiny checklist embedded in the readiness model. The same idea could later help user-facing expert tools: compact summaries beside dangerous or high-context workflows can say exactly what will be affected before the user commits.

2026-07-16 - Make Proof Visible, Not Hidden

A diagnostic panel should not force the tester to copy a report before seeing what matters. Adding the QA run cue to the Health panel turns invisible process knowledge into visible product guidance. This same principle should guide future expert panels: show the next meaningful proof/action in the interface, then let deeper copy/export tools carry the full transcript.

2026-07-16 - Test What The User Actually Reads

A backend truth is not enough if the user-facing report loses the same truth. For MIDI closeout, we now test the text a musician or tester would actually copy/read. This pattern should be reused for other high-trust systems: prove the model, then prove the visible language that explains the model.

2026-07-16 - Export Receipts As Trust Objects

• The MIDI export write receipt can become a reusable trust object across future export types: audio renders, stems, Quasar packages, MIDI stem packages, and collaborator handoff dialogs can all share the same language of attempted write, byte proof, validation still required, and user-facing next test.
• This connects to the broader SpaceAge philosophy: the app should never imply that a file is musically correct just because it exists; it should tell the composer what is proven and what remains to be heard or inspected.

2026-07-16 - Recording Timing As A Confidence Feature

• The record-timing gate should eventually surface as musician-facing reassurance: after recording, SpaceAge can explain what lane was armed, what source was accepted, whether any data was suppressed or dropped, and whether the take needs timing calibration review.
• This connects recording, MIDI Health, and Automation into one confidence loop: play, capture, inspect, fix if necessary, then keep creating.

2026-07-16 23:01 - MIDI record target as confidence UX

A protocol-correct MIDI recorder still feels broken if the UI implies multiple possible destinations. The lane badge should be treated as a musical patch point: choose the lane, it lights/arms, and every record affordance speaks in that same language. This can later connect cleanly to hardware profiles, automation lanes, and per-lane MIDI channel assignments because they all share the same visible owner: the lane.

2026-07-16 23:06 - Stable Feature Nouns

A feature name is a landmark. Automation should not disappear behind clever context labels like CLIP AUTO or LANE AUTO, because users who are learning the app need one noun to remember. Context still belongs in tooltips, status, badges, and counts; the doorway itself should stay stable. This same rule should guide future Instrument Bay, Motion Clips, MIDI Patch, and Hardware Passport surfaces.

2026-07-17 00:01 - Status Clarity As Product UX

When a feature has a strong backend but incomplete launch evidence, SpaceAge should show three truths side by side: coded capability, visible workflow readiness, and release-proof evidence. This prevents the app, the manual, and marketing copy from accidentally implying that hardware/SysEx/timing promises are fully proved before real-device receipts exist. The same pattern can later apply to synth engines, render/export, plugin hosting, and hardware editors.

2026-07-17 00:17 - Creative Link: QA Receipts as Release Evidence

A deterministic QA receipt fingerprint can become more than backend bookkeeping. Later, the MIDI Health page could show a small copyable receipt badge beside each PASS/FAIL/BLOCKED result, and exported support bundles could include those fingerprints so a user, tester, or school IT admin can prove exactly which MIDI scenario was validated. This connects the current MIDI closeout work to release notes, beta tester reports, classroom deployments, and hardware-specific setup guides.

2026-07-17 - Creative connection: fingerprints as trust handles, not marketing claims

The QA receipt fingerprint work connects MIDI validation, release notes, and future customer support. If a user reports a hardware issue later, SpaceAge can point to a saved receipt fingerprint as the exact evidence bundle that was tested, while still keeping public copy honest: a fingerprint proves a receipt exists, not that every device on Earth behaves the same way.

This same pattern can later apply to render/export receipts, hardware setup recipes, SysEx restore sessions, and automation-lane transformations. The creative through-line is a product that feels musical, but also keeps a forensic trail when the outside world gets messy.

2026-07-17 - Creative connection: health cockpit as trust cockpit

The MIDI Health page is becoming more than diagnostics; it is a trust cockpit. The same idea can guide future render, hardware editor, SysEx, and automation panels: every send-capable or release-critical feature should tell the user what is prepared, what has been verified, and what still needs real-world evidence. That reduces fear for musicians and reduces support ambiguity for us.

2026-07-17 - Creative connection: the proof ritual as onboarding

The hardware proof run order can double as onboarding copy later. The same six-step ritual teaches users what SpaceAge means by a trustworthy hardware path: Passport, timing, test phrase, SysEx verification, DAW round trip, saved receipt. That turns a scary engineering checklist into a musician-readable confidence ritual.

2026-07-17 - Creative connection: proof rituals as UI objects

• The hardware proof ritual should not stay as static text forever. Treating it as structured data lets SpaceAge display it as a checklist, onboarding strip, or cockpit card later. This connects the technical MIDI closeout work to the app's design philosophy: reduce anxiety by making invisible trust boundaries visible.

2026-07-17 - Creative connection: cockpit labels reduce doubt

• The compact hardware proof summary is a tiny UX move with a big psychological job. It names the ritual before asking the user to follow it. That helps SpaceAge feel less like a diagnostic dump and more like a calm assistant saying, 'here is how we prove this instrument path is real.'

2026-07-17 - Creative connection: proof rituals become interface objects

The hardware-proof checklist is more than a MIDI QA artifact. It is a pattern we can reuse for other high-trust workflows: render export proof, audio-device setup, sample relinking, and external hardware recall. The lesson is that scary technical steps become calmer when SpaceAge presents them as visible cockpit objects with evidence prompts instead of hidden engineering assumptions.

2026-07-17 - Creative connection: show the next confident action

A proof checklist is only calming if it tells the user what to do next. Adding status and nextAction turns MIDI Health from a diagnostic report into a guided ritual: the user does not need to remember the order, the missing evidence, or the safety boundary. SpaceAge can point at the next confident action and reduce the emotional tax of hardware setup.

2026-07-17 - Creative connection: one next action beats six instructions

The hardware proof ritual has six steps, but a user should not have to mentally rank them. Surfacing the first needed proof item turns a checklist into a guided cockpit: the app can say one thing clearly, at the moment it matters, and keep the user moving.

2026-07-17 - Creative connection: progress badges calm the cockpit

Counts are small, but they change the emotional shape of the workflow. A user can see needed falling and done rising, which makes hardware setup feel like progress instead of fog. This pattern can later apply to export readiness, sample relinking, and release checklists.

2026-07-17 - Creative connection: one small badge, less mental load

The compact hardware-proof badge is the cockpit version of "tell me what matters first." It can sit near the MIDI Health heading and communicate whether the next meaningful action is a Passport, timing calibration, TEST BEND, SysEx proof, DAW round trip, or saved receipt. This same pattern should guide future expert workflows: give the user one clear status object, then let deeper panels explain the details.

2026-07-17 - Creative connection: visible proof beats hidden truth

A status field only matters if the musician can see it at the moment of doubt. Moving the hardware-proof badge into the MIDI Health cockpit turns a backend truth into a visible product promise: SpaceAge can say exactly what is missing before anyone reaches for marketing language or release claims. This should guide future trust surfaces for rendering, sample relinking, and hardware editors.

2026-07-17 - Creative connection: cockpit first, receipt detail second

The Health cockpit should stay scannable, but copied support reports can carry more proof detail. Keeping one visible HW PROOF row while adding checklist counts to the copied report is a useful pattern: the user gets calm status in the app, and support gets the fuller evidence trail when needed.

2026-07-17 08:26 - Automation Proof As A Cockpit Instrument

A dense diagnostic panel can become counterproductive when the user only needs to know whether the system is safe to trust. The Automation proof badge turns a bundle of workflow facts into one cockpit instrument: rows exist, rows are editable, QA remains or clears, and pitch-bend trust is not silently assumed. This same pattern can be reused for Instrument Bay, hardware passports, render readiness, and future Motion Clips: show one honest proof label first, then let deeper reports explain the machinery.

2026-07-17 08:35 - Health Rows Need To Be Receipts, Not Decorations

Every visible diagnostic row should have a model-backed receipt behind it. AUTO OPS and AUTO TOOLS are not just labels in a panel; they are promises about what the user can do. Locking those promises into serialization and regression tests keeps the interface honest as MIDI grows more complex.

2026-07-17 - Badge Labels as Model Truth

When a workflow badge matters to user confidence, its wording should live in the data/model layer instead of being invented by whichever UI draws it. MIDI setup status labels are now reusable by Settings, reports, health panels, automation helpers, and future onboarding walkthroughs without vocabulary drift.

2026-07-17 - Doorways as Product Contracts

For workflow-heavy features, every doorway is part of the feature. Automation is stronger when the model can name its entry points directly, because future UI changes can be tested against that contract instead of relying on memory. This same pattern should apply to Instrument Bay, Hardware Passport, SysEx Vault, and future Motion Clips.

2026-07-17 - Separate The Signpost From The Instruction

Automation benefits from two different text layers: a compact signpost (Automation doors) that proves where the workflow can be found, and a longer run-step (AUTO STEP) that tells the user what to do next. This split is a useful pattern for other dense systems: Instrument Bay, Hardware Passport, TempoCalc, SysEx Vault, and future Motion Clips.

2026-07-17 - Creative connection: proof gates belong where trust changes

The synth audio-output audit should not interrupt every MIDI refactor, but it absolutely belongs before a public build. That distinction matters: MIDI can keep advancing without pretending SoundFont and Quasar asset cases are proven, while the release checklist keeps a visible promise that every playable engine will be heard, routed, stopped, and panic-tested before SpaceAge asks outsiders to trust it.

2026-07-17 - Creative connection: one honest sentence can prevent false confidence

MIDI has enough moving parts that a percentage alone can mislead. Exposing one model-owned Remaining MIDI 1.0 perfection sentence lets the app explain the current frontier in plain language: what works, what still needs evidence, and which future protocols are deliberately out of scope. That same pattern should later help render readiness, Instrument Bay health, and project archive checks.

2026-07-17 - Creative connection: copy packets are product instruments

A complete QA packet is more than debug text. It is a portable ritual: what to test, how to mark PASS/FAIL/BLOCKED, where the risk boundary lives, and what the app is allowed to claim. Making the packet top-level in MIDI Health means future UI can offer one obvious action instead of making testers hunt through protocol machinery.

2026-07-17 - Creative connection: visible uncertainty is a feature

A Health cockpit that only shows proof rows can accidentally sound finished. Adding MIDI LEFT gives the user a calm, visible boundary: this is what remains before SpaceAge should claim MIDI 1.0 release confidence. That pattern matters for other systems too: render readiness, synth audio-output checks, sample relinking, and future VST hosting should each show both proof and remaining risk in the same place.

2026-07-17 - Creative connection: copied steps should carry the honest boundary

When a tester copies next steps, they are probably about to leave the cockpit and work from pasted text. That text must include the same MIDI LEFT truth as the app itself, otherwise the copied handoff becomes less honest than the visible UI. This applies broadly: any future copyable workflow packet should carry both the next action and the claim boundary.

2026-07-17 - Creative connection: file proof is different from fixture proof

A MIDI fixture can prove SpaceAge understands its own model, but a musician judges interchange by opening files in other real tools. The FILE PROOF row makes that difference visible without weakening the software confidence we already have. This same split should guide render export, SoundFont packages, Quasar packages, and future VST preset exchange: internal proof first, external round-trip proof before public claims.

2026-07-17 11:10 - Import/Export Proof Symmetry

• Import and export should teach the same mental model: bytes and model mutations are not enough; the user needs visible validation steps that say what to re-open, audition, compare, and receipt.
• This checklist can later feed a guided import wizard: SpaceAge can turn each checklist item into a checkable QA row after an import, especially for hardware-heavy MIDI files with SysEx and setup-controller data.

Creative Thinking - Import Receipts as Trust Objects

Treating committed imports as receipts, not just status messages, gives the user a safer mental model for MIDI. The same pattern can later power a friendly "Import Proof" drawer: clips, lanes, Automation, SysEx Vault, and setup-review rows could each get clickable checkmarks that guide a musician through proof without making them read a technical report.

Creative Thinking - Package Receipts As Collaboration Contracts

A MIDI stem package is not merely a file bundle; it is a contract between collaborators. The receipt/checklist pattern can become a friendly "handoff confidence" panel later, where SpaceAge shows lane stems, full Arrangement reference, manifest/checksum files, undo status, and round-trip status as visible proof tiles instead of burying that trust work in text.## Creative Thinking - Recording Proof Should Wait For The Whole Gesture

A recorded MIDI gesture is not fully proven when the first related event appears. Notes, CCs, bends, pressure, and lane ownership may commit through different queues, so future recording QA panels should think in terms of complete gestures: note start/end, expression curve, armed lane, source controller, latency compensation, and undo should all become green together.

Creative Thinking - Treat Test Executables As Evidence Objects

A regression result is only meaningful when the source, build script, and executable path form one chain of custody. For SpaceAge, that suggests a future QA footer or copied receipt could include the exact executable path, timestamp, and focused gate name. It is not glamorous, but it prevents phantom failures from stealing creative oxygen.

Creative Thinking - One Rail For Build Evidence

The app itself is becoming evidence-rich: receipts, health panels, and QA packets. The build process needs the same clarity. A single default build rail makes regression proof feel less like archaeology and more like a cockpit readout: build here, run here, trust this result.

Creative Thinking - Make The Test Ritual Memorable

Named gates turn internal MIDI proof into a repeatable ritual: MIDI_RECORD_TIMING, MIDI_CLOSEOUT, MIDI_HEALTH, and friends read like cockpit switches instead of environment-variable trivia. This same idea should guide customer-facing diagnostics: the user should choose the proof they want, not memorize the machinery behind it.

Creative Thinking - A Take Is Notes Plus Motion

A recorded performance should preserve both the notes and the expressive gestures that made it feel human. That means Arrangement recording cannot treat controller data as a later accessory; CC, bend, pressure, and other expression should arrive in the same musical container as the played notes, with the same lane routing and timing expectations. This connects directly to future visible automation lanes: when the user records a phrase, SpaceAge should be able to show the melody and its motion as one coherent musical event.

Creative Thinking - Proof Should Be Easy To Repeat

A professional MIDI stack is not only code; it is a repeatable ritual for proving the code. Pulling the focused proof gates into the shared runner turns MIDI closeout from folklore into a menu: run the gate, read the receipt, move on. This connects to the eventual customer-facing Health panel too: if our internal proof paths are clear, the user-facing diagnostics can become clearer without inventing a second language.

Creative Thinking - The Test Runner Is A Cockpit

The shared test runner is starting to act like the engineering version of a cockpit: one switch for each proof domain, one clear result, no ritual incantations. That matters creatively because it lets us move faster without getting sloppy. The same idea can influence the app itself: MIDI Health should feel like a cockpit too, with direct access to each proof category rather than a wall of prose.

Creative Thinking - One Doorway, Many Owners

Automation is easier to trust when the doorway name stays stable and the complexity lives one level deeper. A musician should not have to understand Clip Local versus Lane Local before finding the tool; they should click Automation, then choose the ownership that matches the musical intention. This pattern can help future Motion Clips, Instrument Bay routing, and hardware editors: one clear front door, explicit ownership inside.

Creative Thinking - A Button Should Not Borrow Proof

When a MIDI proof button opens a form, its tooltip should say that. When it saves evidence, it should say that. This tiny distinction matters because SpaceAge is building user trust around receipts, hardware proof, and external validation. The same rule should apply to render/export, SysEx restore, Hardware Passport tests, and future VST scan workflows: the button should name the actual state transition, not the desired final state.

Creative Thinking - The Door Should Name The Room

A repair button that always says FIX NEXT asks the musician to hover, read, and remember. A button that says Automation or PASSPORT teaches the structure of the app while preserving the same safe-door contract. This pattern should guide future diagnostics: keep the model as the source of truth, then let the visible doorway borrow the model's plain-language action label.

Creative Thinking - Labels Are Data Too

A button label is not just decoration when it tells the musician where the app is taking them next. Moving Automation/PASSPORT/SYSEX-style labels into the MIDI model means reports, tests, and UI can agree on the same doorway. This pattern should apply to future Health surfaces, render/export status, and hardware setup flows: if a label carries workflow meaning, it belongs near the workflow model, not only inside paint code.

Creative Thinking - One Model, Many Cockpits

A MIDI status label is not just decoration; it is part of the user's mental map. When the Health panel and Protocol panel use the same compact action label from the same model, the UI starts to feel like one cockpit instead of several panels arguing about the same flight plan. This same pattern should apply to future automation, hardware, and export surfaces: detailed reports can be verbose, but buttons should be compact, consistent, and model-owned.

Creative Thinking - Cockpit Labels Need Two Voices

MIDI status language needs a full sentence for trust and a tiny command label for quick navigation. Giving the model both forms lets SpaceAge speak clearly in reports while still feeling fast on button-sized surfaces. This pattern should carry into Automation, Hardware Passport, and future Instrument Bay status chips: full explanation for confidence, compact label for motion.

Creative Thinking - MIDI Feel Starts With Honest Time

A live MIDI note should not merely be acknowledged quickly; it should carry its timing truth into the synth engine. Preserving timestamp-derived sample positions makes SpaceAge feel less like a polling app and more like an instrument. This same philosophy should guide future automation and hardware workflows: preserve the user's gesture timing first, then explain any external latency the app cannot control.

Creative Thinking - Recording Confidence Is a Product Feature (2026-07-17)

The user should never need to understand whether a note came from host MIDI, USB direct MIDI, or a DIN controller behind an interface. The Arrangement Canvas should feel like one honest tape machine: arm a lane, press record, play in time, get notes in the right place. Every routing distinction we add for hardware power users has to disappear emotionally at the performance layer.

Creative Thinking - Doorways Should Know Where The Music Is (2026-07-17)

Automation is powerful enough that hiding it behind a generic Settings detour makes it feel like an engineer's tool instead of a musician's tool. A better doorway first asks, "What lane or clip is the user actually working on?" and opens that context. The same design rule should apply to future Motion Clips, hardware editors, and effect automation: open the musical object first, explain ownership second.

2026-07-17 16:23 - REC as a confidence surface

• Record buttons should behave like a cockpit annunciator: compact label for action, dynamic hover/status text for exact destination. This avoids adding another permanent inspector while still teaching the user where incoming MIDI will land.

2026-07-17 16:28 - UI reports must share one truth

• MIDI confidence depends on every visible reporter agreeing: lane highlight, status text, button state, and tooltip. Even small mismatches between selected pattern and recording pattern can make the app feel slippery, so record-state UI should always query the active recording transaction first.

2026-07-17 16:33 - Fewer doorway names, more confidence

• A music tool should avoid making one concept look like several different concepts. AUTO as a stable doorway lets the user learn one target, while context-specific detail can live in hover text, status text, and row counts.

Creative Thinking - A Good Test Should Listen Like A Musician (2026-07-17)

A timing test should care that the played note lands where the musician played it, not that it happened to be the seventh internal trace item this week. Replacing brittle index assumptions with event-identity checks makes the proof closer to the user's experience: did the note-on arrive at the correct sample, did the note-off create the right length, and did setup chatter stay out of the musical take? This same idea should guide future automation and hardware tests.

Creative Thinking - Diagnostics Should Become Checklists (2026-07-19)

A one-line diagnostic is useful when space is tight, but musicians troubleshoot with steps, not paragraphs. Turning LIVE DIAG into structured rows lets SpaceAge eventually show a calm checklist: audio buffer, direct input queue, hardware output queue, sample-position proof, and SoundFont pool. The creative connection is that the same model can feed compact UI, copied support reports, onboarding, and future guided hardware setup without inventing another truth system.

Creative Thinking - A Diagnostic Needs A Headline (2026-07-19)

Structured rows are the evidence, but a musician still needs the headline. The LIVE DIAG row summary turns several measurements into one cockpit sentence: how many checks exist, how many need attention, and what to try first. This pattern should carry into automation, render, hardware, and SoundFont diagnostics: rows for proof, a headline for human momentum.

Creative Thinking - A Cockpit Line Beats A Hidden Receipt (2026-07-19)

If a diagnostic only exists in a copied report, it is useful for support but not for the musician in the moment. Surfacing LIVE ROWS beside LIVE DIAG makes latency troubleshooting feel less like digging through paperwork and more like reading an instrument panel. The same rule should apply to future automation, render, SoundFont, and hardware-send surfaces: the report can be deep, but the cockpit should name the next useful truth.

Creative Thinking - Troubleshooting Needs A Trail (2026-07-19)

A cockpit headline tells the musician what to try first, but a support report needs the trail of evidence. The LIVE DIAG row-detail report turns buffer, direct input queue, hardware output queue, sample-position proof, and SoundFont pool state into a readable checklist. This gives SpaceAge a future pattern for all expert features: headline for action, rows for evidence, copied report for accountability.

Creative Thinking - The First Problem Should Be Clickable (2026-07-19)

A summary sentence helps Shane and support understand the first live MIDI concern, but a structured first-attention row lets the app eventually attach a button to it. Audio buffer, direct input queue, hardware output, sample-position proof, and SoundFont pool can each become a small guided action instead of a paragraph. This is the same design language as Instrument Bay and Automation: the model names the next doorway, the UI decides how handsome that doorway looks.

Creative Thinking - Diagnostic Rows Want Doorways (2026-07-19)

Once SpaceAge knows the first live MIDI issue as structured data, the next humane step is a small action card. The row says what is wrong; the card says where to go next without sending MIDI, changing routing, or mutating the project. This pattern can unify audio setup, hardware setup, SoundFont pool warnings, render diagnostics, and future automation diagnostics: evidence row first, safe doorway second.

Creative Thinking - Reports Should Carry The Same Button (2026-07-19)

When MIDI Health knows the next safe doorway, copied reports should say the same thing the UI will eventually show. Adding an action-card summary to both Health and Next Steps keeps support, future buttons, and user-visible diagnostics aligned. The deeper idea is product trust: if a button is safe because it sends no MIDI and mutates no project state, that safety should be explicit in the report too.

Creative Thinking - The Cockpit Should Show The Door (2026-07-19)

A diagnostic report is useful after the fact, but the Health panel is where the musician is already standing. Surfacing LIVE ACTION beside LIVE FIRST makes the next safe doorway visible without forcing the user to copy a report or interpret engineering language. This is the same design principle we should apply to render status, import repair, and hardware setup: once the model knows a safe next move, the cockpit should show it.

Creative Thinking - Row Budgets Are Part Of The Instrument Panel (2026-07-19)

Fixed row counts are quiet layout contracts. When we add a cockpit line like LIVE ACTION, the row budget has to change with it or the panel risks clipping the very guidance we just made visible. Any future Health, render, or hardware cockpit should treat row-count updates as part of the feature, not as layout cleanup after the fact.

Creative Thinking - Full Reports Need The Same Next Button (2026-07-19)

A short Next Steps report is where a musician looks for immediate action, but the full Health report is what support and future QA will archive. If Next Steps says which QA receipt button to press and the full report omits it, the two surfaces quietly diverge. MIDI closeout reports should always carry both the proof detail and the next button.

2026-07-19 - QA Receipt Copy Should Not Echo Itself

Task: Remove a duplicated QA receipt action-surface line from MIDI Health Next Steps.

Architecture choice: Keep the QA action sentence in every required surface, but only once per copied checklist. Repetition makes a launch checklist feel less precise, and precision is part of the trust contract for MIDI hardware workflows.

Future extensions: Any new copyable cockpit report should get a quick duplicate-line scan before release, especially when it mirrors Protocol Coverage wording into MIDI Health.

2026-07-19 - MIDI Health Rows Need Layout Truth

Task: Reconcile the MIDI Health popup layout budget with the number of rows it actually paints.

Architecture choice: Treat visible diagnostic rows as a layout contract. The Health panel now reserves space for the full always-visible row set instead of the older pre-QA/live-diagnostic count, so buttons and recommendation controls do not creep into report content.

Future extensions: Any new Health, render, SysEx, or automation cockpit row should update the row budget in the same pass, or move to a measured layout that derives reserved height from row definitions instead of a hand-maintained number.

2026-07-19 - MIDI Health Payloads Should Be Self-Contained

Task: Mirror extCloseoutFocusSummary at the top level of the MIDI Health serialized payload.

Architecture choice: The visible Health panel and copied reports already show the next closeout focus. The structured Health payload should expose the same model-owned sentence directly so future UI, support bundles, and QA receipts do not have to drill into nested Protocol Coverage data for the headline.

Future extensions: Treat MIDI Health as the customer-support cockpit payload. Nested models can remain available, but headline route/action/focus facts should be mirrored when they are visible or copyable at the Health level.

MIDI Health Closeout Payload Contract - 2026-07-19 10:03

The MIDI Health cockpit is now treated as a self-contained status payload: if it exports route-contract, safety, and hardware-evidence summaries, regression tests must prove those fields remain present and human-readable. This connects backend closeout accounting to customer-facing trust: the same data can later feed status badges, manual QA screens, or a release-readiness export without re-threading hidden assumptions.

MIDI Health Breadcrumbs As Product Navigation - 2026-07-19 10:08

The MIDI Health payload now treats closeout breadcrumbs as part of the product contract, not throwaway report text. Test, route, route-proof, QA, and manual-run summaries are the connective tissue between backend readiness and a musician finding the next safe action. This same pattern should guide future dense systems: diagnostics should say what to do, where to go, and what proof makes the claim trustworthy.

Automation Doorway Names Should Match - 2026-07-19 10:13

A user should not have to learn that AUTO means Automation in one place and Automation means the same thing elsewhere. The Piano Roll doorway now uses the full feature name, matching Arrangement, reports, QA text, and Health. This is the same naming discipline we need for Instrument Bay, Hardware Passport, SysEx Vault, and future Motion Clips: clever compression is less valuable than a stable landmark when the feature is deep.

2026-07-19 - Automation Names As Trust Glue

Connection: The Piano Roll button now says Automation, so the health reports, run-step text, and QA checklist need to say the same thing. This is small vocabulary work, but it protects a larger product promise: a user should never have to translate between the button they see and the diagnostic/help text that tells them what to do next.

2026-07-19 - Tests Should Read Like The Interface

Connection: A substring assertion can accidentally approve the old label while the GUI has moved on. For SpaceAge's MIDI closeout, tests should speak the same nouns the user sees, especially around discoverability doors like Automation. This makes the automated safety net part of the product language, not just an engineering convenience.

2026-07-19 - Long Labels And Button Labels Can Both Be True

Connection: MIDI closeout action cards now protect both sides of a useful UI distinction: reports can explain the feature as Automation, while the actual action button stays compact as AUTO. This is a good pattern for SpaceAge generally: use short, muscular buttons, but preserve longer explanatory wording in receipts, health panels, and manuals.

2026-07-20 - Validation Matrix Turns Proof Into A Product Habit

Every MIDI claim should have a matching artifact: a real controller note, a hardware receipt, a DAW file round trip, a SysEx acknowledgement, or a wording audit. The launch matrix keeps this habit visible so SpaceAge can feel musician-friendly while still behaving like a professional product with receipts.

2026-07-20 - The Next Proof Should Be Obvious

A validation checklist becomes far more useful when the app can say, "do this next." The next-receipt selector turns MIDI QA into a guided path: capture one artifact, save one receipt, then move to the next proof bucket. That keeps beta testing humane instead of turning it into archaeology.

2026-07-20 - Proof Should Have A Button Shape

When a system tells a musician or tester what remains, the next action should have the same shape everywhere: label, evidence target, safety class, and whether it can mutate anything. Reusing the MIDI QA receipt action model for launch validation keeps the app from splitting into separate proof languages.

2026-07-20 - Teach At The Moment Of Entry

• Automation is becoming a recurring SpaceAge pattern: advanced editors should open with the safest first action visible, not buried in a manual.
• The same pattern can later help Instrument Bay, MIDI PATCH, Hardware Passports, and automation curve editors: state ownership, state first action, state whether anything sends live MIDI.

2026-07-20 - Validation Should Feel Like A Checklist, Not A Mystery

• The launch-validation matrix is most useful when it behaves like a cockpit checklist: how many receipts are passed, what is next, and what action opens the proof path.
• This same pattern can guide future export, hardware, and automation QA: every important capability should eventually have a visible proof state and a next action.

2026-07-20 - One Visible Next Thing

• When a cockpit row says what is next, the nearest button should do that thing. The MIDI Health QA button now follows that rule for launch-validation receipts.
• This is a useful pattern for future SpaceAge UX: the most visible unresolved proof item should own the most obvious action path.

2026-07-20 - Proof Context As User Trust

Launch readiness should feel like a checklist with receipts, not an abstract warning light. Carrying proof bucket/artifact data all the way into the MIDI Health cockpit means the app can eventually say, in plain human terms, �record this Automation proof next� or �test this hardware bend response next,� without making the user decode engineering status.

2026-07-20 - Copied Reports As Launch Receipts

A launch-health report is more than debug text; it is a trust artifact. If copied reports show the exact proof bucket and artifact, beta testers and future support conversations can stay practical: what was tested, what remains, and what public promise is safe. This keeps SpaceAge honest without making the user interpret backend percentages.

2026-07-20 - One Card For Launch Trust

A single MIDI launch-validation card is more than a report convenience: it can become the UI primitive behind a future Launch Proof panel, release checklist, status badge, and copied support report. This connects MIDI QA, customer-facing honesty, and marketing restraint into one mechanism, so SpaceAge can say exactly what is proven without hand-wavy claims.

2026-07-20 - Proof Rows As UI Material

The launch-proof card is now close to a reusable UI object: a progress percentage, rows, next action, and public-claim safety state. That same idea can later power export-readiness, hardware-passport readiness, and project-health dashboards: one structured card per musician decision, no scattered mystery status text.

2026-07-20 - One Structured Card, Many Surfaces

The MIDI launch-validation card now feeds the visible Health cockpit, copied reports, serialized payloads, and tests. That is the pattern to reuse for dense SpaceAge systems: build one model-owned card with progress, next action, and proof state, then let UI, support reports, and QA receipts render the same truth without each surface inventing its own arithmetic.

2026-07-20 - The Nearest Button Should Fulfill The Visible Promise

A cockpit row that says what to do next should not hand off to an older routing system. The MIDI Health FIX NEXT button now uses the same action surface as the visible status row, which is the right habit for future dense pages: the model names the action, the UI renders it, and the nearest button performs exactly that action.

2026-07-20 - Route IDs Are Product Architecture, Not UI Trivia

The MIDI cockpit now names its safe-door route as data. That matters because SpaceAge has many deep features that will need status cards, proof receipts, and one-click doors: Instrument Bay, Hardware Passport, Automation, SysEx Vault, export proof, and future VST scanning. If the model owns the route ID, the UI can stay beautiful and dumb in the best way: render the card, open the named door, do not guess.

2026-07-21 - Delay Sync Labels Should Teach Musical Time

Adding half-note and whole-note choices to the channel-strip delay menu connects EchoRay sends to the same musician-facing language as the rest of SpaceAge's tempo-aware controls. This same pattern should guide future delay, tremolo, gate, vibrato, and Motion Clip rate menus: visible musical divisions, correct parameter IDs underneath, and no hidden mismatch between what the user chooses and what the DSP receives.

2026-07-21 - Arrangement Overview And Timing Feel

• Connected the O shortcut to a smarter Arrangement overview: fit the existing song horizontally at the largest usable scale, while only compressing lane height when the lane stack cannot fit vertically.
• Reduced unnecessary Arrangement canvas repaint pressure by adding no-op guards to timeline, loop-range, and layout setters. This keeps living-time visuals expressive while reducing GUI work that could contribute to perceived timing unease around measure boundaries.
• Future connection: the same "fit everything at maximum useful size" rule should guide Piano Roll overview, automation lanes, and any future clip-detail pages so navigation feels like one shared SpaceAge language.

2026-07-21 - Lane-Owned Instruments vs. Private Backing Slots

Task connection: Arrangement lanes should teach the user that instruments live on lanes, not on drum Pads. The current engine parameter store is still pad-indexed internally, so the practical bridge is to treat those indexes as private backing slots for non-drum lane instruments while removing Pad language from the user-facing lane workflow.

Creative linkage: This makes the future Instrument Bay cleaner. The Arrangement lane badge becomes the visible authority for choosing, editing, routing, and recording an instrument. Pads remain the MPC-style drum/percussion surface, while lane instruments can later move behind a true instrument registry without changing the user's learned behavior.

2026-07-21 18:31 - MIDI Sample-Position Trust

Task: Preserve queued incoming MIDI sample positions through the live/record path.

Connection: A DAW earns trust when what the player feels, hears, sees, and records all agree. Keeping sample offsets alive through the queue connects live monitoring, Arrangement recording, Piano Roll editing, controller latency diagnostics, and future hardware-passport receipts. This same discipline should apply anywhere SpaceAge schedules time-sensitive events: automation lanes, loop edges, transport chase, arps, and external MIDI output.

2026-07-21 18:52 - Live Input Feel as a Trust Surface

Task: Reduce avoidable app-side MIDI monitoring delay with a final pre-render direct-input drain.

Connection: SpaceAge's live feel is part of its composition UX. The same trust rule that governs MIDI recording also belongs to auditioning synth patches, using the chord readout, playing SoundFonts, recording Arrangement lanes, and future hardware setup wizards: respond as early as the engine safely can, then explain the rest of the latency chain honestly.

2026-07-21 - Recording Stop as Musical Commit

Task: Close held MIDI notes from Arrangement recording in clip-local musical time.

Connection: Stopping record is not merely a transport action; it is the moment a performance becomes editable musical material. If SpaceAge maps that final held-note boundary correctly, the Piano Roll becomes a faithful memory of what the player meant. The same idea should guide future automation capture, pedal recording, pitch-bend sweeps, and MPE gestures: every recorded gesture needs a clear local timeline before it becomes something the user edits.

2026-07-21 - One Timeline Translation Layer

Task: Route note recording, expression recording, and recording closeout through one Arrangement clip mapper.

Connection: SpaceAge has several musical clocks: the song timeline, clip-local source time, repeated clip playback, Piano Roll editing, and future automation lanes. The user should never feel those clocks fighting each other. A single translation layer is the architectural pattern to repeat for automation, audio clips, Motion Clips, and any future scene/orchestration system.

2026-07-21 - Lane Badge As Recording Truth

Task: Make MIDI lane arming update the selected Arrangement destination and reject stale cross-lane recording clip IDs.

Connection: The lane badge should be the user's truth surface for instrument, MIDI input, recording, automation, and routing. This same principle should guide Instrument Bay finalization, hardware Passport routing, future VST hosting, and automation lanes: the place that visually says �this lane owns the sound� should also own the input path.

Creative Thinking: Visible Doorways Need One Home

Automation only feels approachable when its doorway is stable. Keeping Automation in one predictable command-row position reinforces the Arrangement Canvas as the place where performance motion is discovered, edited, and trusted.

Creative Thinking: Automation Belongs Where the User Clicks

When a user clicks an AUTO badge on a clip, they are making a direct statement of intent: edit this clip's performance motion. That interaction should outrank global context like the playhead, because it reinforces SpaceAge's visual promise that clips are living objects with editable contents.

2026-07-21 - MIDI Timing Trust Needs Two Clocks

Task: Fix direct hardware MIDI record placement by separating queue-age diagnostics from signed event offset.

Connection: A musician experiences one thing: hand-to-sound trust. The app needs two clocks underneath that feeling: one for when to monitor the note as quickly as possible, and another for where to write the performance into the song. Keeping those clocks separate connects MIDI Health, Arrangement recording, latency compensation, and future hardware setup assistants into a more honest workflow.

2026-07-21 - Diagnostics as Future Guardrails

Task: Align MIDI Health wording with the direct-input timing implementation.

Connection: Good diagnostic copy is not decoration. In SpaceAge, the text can teach both the user and future developers which clock is responsible for which part of performance trust: monitoring latency, queue health, and recorded musical placement.

2026-07-21 - Performance Feel Is Architecture

Task: Remove duplicated live-MIDI voice delay after sample-dispatch.

Connection: Latency is not just a buffer-size problem; it is also a trust problem. Separating event placement from voice delay keeps MIDI recording precise while making the instrument feel closer to the player�s hand, which supports future hardware setup helpers and live performance workflows.

2026-07-21 - Recording Should Survive Curiosity

Task: Make MIDI recording stop paths use the processor-owned recording target.

Connection: A musician should be allowed to look around while recording without corrupting the take. This connects Arrangement recording, clip selection, quantize, and UI freedom: selection can be exploratory, but recording target must remain anchored until the take ends.

2026-07-22 - Identity Lets the UI Stay Calm

When the user records into the Arrangement Canvas, the app should feel like it knows exactly where the performance belongs. Hidden clip identity is the quiet architecture that makes that possible: the visible UI can stay simple, while the backend keeps track of the exact musical object through gap cleanup, normalization, copy/paste, and future automation-lane work.

2026-07-22 - One Gesture, One Musical Meaning

MIDI input can be physical and immediate, but the app still has to decide what kind of musical object the gesture becomes. A pad hit in a Drum lane should become a drum step; a keypress in an Instrument lane should become a pitched note. Keeping that boundary clean makes the Arrangement Canvas easier to trust and keeps future features like ghost notes, automation lanes, and clip rendering from inheriting ambiguous data.

2026-07-22 - Timing Trust Comes From One Clock Door

The player should never have to wonder whether a note came from USB, DIN, a host plugin, or a late-arriving direct callback. All of those gestures should enter the musical timeline through one clear door per audio block. That makes the instrument feel calmer, makes recording easier to trust, and gives future diagnostics a cleaner story to tell.

2026-07-22 - MIDI Timing as a Feel Feature

The more SpaceAge treats every incoming MIDI gesture as a precisely timed musical event, the less the user has to think about routing internals. This timing work is not just protocol hygiene; it is part of the tactile feel of the instrument, especially for hardware players coming from DIN devices, wind controllers, and finger-drumming controllers.

2026-07-22 - Drums Can Be Grid Music and Timeline Music

The Drum Composer is a performance grid, but the Arrangement Canvas is a timeline. Preserving both representations lets SpaceAge keep the immediate MPC-style drum workflow while still treating drum clips like grown-up Arrangement citizens for long phrases, exports, thumbnails, and future automation.

2026-07-22 - Automation Needs a Door Handle

Automation is powerful enough that hiding it behind a menu makes it feel theoretical. The lane badge can now act like a visible handle: selected lanes invite the user to create automation, lanes with existing rows advertise that fact, and empty lanes avoid pretending there is data to edit. This keeps the Arrangement Canvas self-teaching without adding another inspector workflow.

2026-07-22 - MIDI Confidence Is Also Layout

Hardware workflows already carry enough cognitive weight. A MIDI setup page that overlaps text teaches the user to distrust the page before they even send a test note. The layout now keeps the selected scenario, template controls, bottom safety copy, and navigation buttons in separate zones, which is mundane engineering but important product trust.

2026-07-22 - Diagnostic Panels Should Be Cockpits, Not Encyclopedias

The MIDI Health surface is most useful when it gives the musician a readable status cockpit and sends full forensic detail to COPY REPORT. This same rule should guide future diagnostic surfaces: show what matters now, keep deep receipts exportable, and avoid crowding the user with every internal proof row at once.

2026-07-22 - MIDI Proof Has Two Layers

The live MIDI path can be mechanically correct while the proof cockpit still fails. Treat those as separate products: the musician must get tight recording and live feel, while the diagnostic/report layer must clearly explain what is proven, what is merely modeled, and what still needs real hardware receipts. Future development should avoid mixing those two definitions of "done" in a single percentage.

2026-07-22 - Test Gates Are Product Language

The name of a test gate teaches the team what kind of confidence it represents. A protocol-only gate should prove protocol mechanics and stop there; launch readiness should include receipts, real hardware, and visible UX proof. Keeping those gates separate makes the status reports more honest and keeps us from overreacting to unrelated smoke-test noise.

2026-07-22 - Repeatable Gates Reduce Human Drag

A powerful test is less useful if it depends on a remembered environment variable. Promoting the MIDI protocol-only boundary into the normal test runner turns it into a repeatable ritual: build, run named gate, save report, compare. That same pattern should guide future launch-proof tasks so beta testing feels procedural instead of mystical.

2026-07-22 - Launch-Proof Cue As Product UX

A protocol test result is useful to us, but a launch-proof cue is useful to a human tester. The new nextProofCue turns the proof matrix into a musician-facing instruction: what to validate next, what artifact to capture, and whether public claims are still blocked. This can later become a compact progress card in Settings or a release-readiness dashboard without changing the underlying receipt model.

2026-07-22 - Test Runner As User-Trust UX

Even developer tooling affects product confidence. A long silent test run feels broken in the same way a long silent project load feels broken to a musician. Streaming the gate report makes our own validation workflow behave more like SpaceAge should behave: visible status, incremental proof, and no mystery pause where trust leaks out.

2026-07-22 - Direct Input Handoff And Hardware-Proof Claim Gate

• Direct MIDI input slot reuse now retires stale held-note ownership at the timestamped current recording step, including wrap-safe end-of-loop handoffs. This prevents an old controller/generation from closing notes at step 0 when the same device slot is reused mid-recording.
• MIDI health wording now distinguishes launch-proof completion from hardware-proof release readiness. A project can show launch receipts complete while still refusing public "MIDI 1.0 shippable" language until saved hardware/file/host proof clears.
• Verified with Release compile, MIDI_HEALTH, and MIDI_RECORD_TIMING on 2026-07-22.

2026-07-22 - MIDI Focused Gate Sweep

• Ran the focused MIDI closeout sweep after the direct-input handoff and hardware-proof claim-gate fixes.
• PASS: MIDI_READINESS, MIDI_CLOSEOUT, MIDI_HEALTH, MIDI_RECORD_TIMING, MIDI_PROJECT_READINESS, MIDI_CONTROL_QUEUE, MIDI_SETUP_QUEUE, SYSEX_CAPTURE, SYSEX_RESTORE_RESPONSE, AUTOMATION_OWNERSHIP, AUTOMATION_RESTORE, MIDI_QA_RECEIPT, MIDI_TEMPLATE_DRAFT, and MIDI_LATENCY_WRAP.
• MIDI_PROTOCOL streamed through to MIDI protocol-only gate: passed; the outer shell timeout landed at the end of the long report, so the protocol assertions are green but the long-run wrapper still deserves ergonomic patience/timeout tuning.
• Current interpretation: MIDI 1.0 backend and model contracts are strong. Remaining work is field proof on real devices, customer-facing Automation comfort, hardware setup polish, and careful validation on Shane's DIN-via-mioXL path before public MIDI completion claims.

2026-07-22 - Synth GUI Cleanup + Lane-Owned Instruments

• Shared synth-engine control labels now get a compact bold treatment in the drawer while it is visible. This is intentionally boring code with useful reach: Redshift, SoundFont, Labs, TG-55, and the other engine pages benefit from one consistent readability rule instead of one-off page tweaks.
• The Arrangement lane instrument menu now teaches the intended architecture: non-drum lanes choose a lane-owned instrument first, while old pad-backed material is framed as copying from an existing pad sound. This connects the future Instrument Bay to the present storage layer without reintroducing a top inspector.
• Creative bridge: the same lane-owned identity should eventually drive MIDI input, automation ownership, stem names, ghost-note source labels, and future scene/orchestration swaps. If a user changes a lane instrument, every surface should say the lane changed, not that a pad changed.

2026-07-22 - Explicit Drum vs Instrument Lane Creation

The Add Lane action now asks for lane intent before creating anything. This connects directly to the Instrument Bay migration: instrument lanes can still use the transitional hidden instrument slot, while drum lanes remain attached to the Drum Composer/pad-grid paradigm. The useful creative connection is that future lane templates can hang from the same choice point: Drum, Instrument, Hardware MIDI, Automation, Motion Clip, or Scene lane can all become first-class choices without adding more top-level buttons.

2026-07-22 - Lane Instrument Language Cleanup

The Synth Engine title now resolves the active drawer target through the lane-aware formatter, so a non-drum lane should read as the lane/instrument relationship instead of exposing a hidden backing slot. This supports the larger Instrument Bay direction: the GUI teaches lanes own instruments, while pads remain a performance/drum surface rather than a required mental bridge for every synth.

2026-07-22 - Instrument Slot As A Transitional Dock

The hidden instrument slot is now best understood as a temporary docking bay for a lane-owned instrument, not as a user-facing Pad. That gives us a migration bridge: the UI can teach the correct mental model today while the backend keeps using stable pad-slot plumbing until we deliberately replace it with true lane-owned patch storage, mixer routing, and automation scope.

2026-07-22 10:14 - Slot Language As Product Hygiene

Cleaning the remaining processor call sites from pad language to slot language is small mechanically, but important conceptually: it keeps future Instrument Bay work pointed toward lane-owned instruments while preserving the stable sound path. This is the kind of transition layer that lets us remove confusion without ripping out the floorboards mid-song.

2026-07-22 10:25 - Lane Context As Orientation

A lane-owned instrument editor should feel like opening the instrument from the lane, not like being teleported to an invisible pad. Carrying source-lane context into the Synth Engine drawer lets the same editor serve Pads and Arrangement lanes without confusing the user's mental model. This same pattern can later help effect editors, automation editors, and Instrument Bay detail views report their true owner.

2026-07-22 - Long Clip Editing as Arrangement Literacy

• A 256-step melody should feel like a real musical object, not a stretched drum-machine page. Long Piano Roll clips need navigation that teaches duration visually while preserving quick sketch space for shorter patterns.

2026-07-22 - Instrument Bay as a Source, Not a Crutch

• The Instrument Bay should feel like choosing a sound for a lane, not like secretly routing through Pads. Menus should lead with creation and use existing sounds as optional material to copy forward.

2026-07-22 - Living Time Without Timing Debt

The pulsing/animated interface is becoming part of SpaceAge's identity, but the visual layer has to behave like a passenger, not a driver. The right architecture is cached musical state flowing outward to the UI, with no downbeat-triggered layout rebuilds or heavy scans. That gives us the gadget feel without making the groove pay rent.

2026-07-22 - Block-Level MIDI Timing Margin

The app's timing feel is part of the instrument. Every bit of repeated background work competes with the first note of the measure, which is exactly where musicians notice weakness. The useful design principle is to let the audio thread read prepared state, not rediscover it. That same idea should guide automation lanes, motion clips, and living-time visuals: prepare richly, render lightly.

2026-07-22 - Render-Loop MIDI Timing Trim

Timing polish often comes from removing tiny repeated decisions, not from dramatic new systems. For SpaceAge, the compositional features can be rich as long as the render loop behaves like a disciplined player: read the chart once, then perform without looking back every note.

2026-07-22 - Block Meter Publication

Meters are important because they make the mixer feel alive, but they should behave like windows into the audio path, not extra machinery inside it. Publishing block-level peaks preserves that living feedback while keeping the musician's touch ahead of the visual layer.

2026-07-22 13:05 - Automation as a Visible Composition Object

Making Automation visible from the lane badge connects MIDI expression data to the same place users already inspect instruments, routing, mute/solo, and clip targets. This should become the bridge between hidden MIDI protocol correctness and future Motion Clips: the user learns that expressive time-based data lives beside the musical lane, not in a mystery inspector.

2026-07-22 13:11 - Naming as Workflow

Automation should stay named as Automation wherever there is room. Short labels are useful only after the user has learned the object. For a feature as important as MIDI expression, explicit wording teaches the workflow and reduces the need for tooltips or memory.

2026-07-22 - Automation ownership should follow musical focus

Automation becomes less dangerous and more musical when it follows the object the composer is actually touching. A lane or clip entry point should lead to local automation first, while Shared PTN remains a deliberate power-user choice for linked repetitions.

2026-07-23 - Final Instrument Bay Split From Drum Pads

Task connection: The user wants non-drum Arrangement lanes to own instruments directly, while Drum Composer remains pad-bank based. The current UI mostly teaches that model, but the backend still stores lane instruments in transitional pad-backed slots.

Creative integration: Treat Drum Pads and Lane Instruments as two different inventory systems that can share engine code but not identity. A future InstrumentInstance pool should own engine type, patch state, mixer channel, MIDI route, and display metadata. Drum pads can still host engines for MPC-style performance, but non-drum lanes should reference instrumentId directly and never require a hidden pad number. This will make scenes, orchestration swaps, MIDI hardware routing, stem rendering, and preset browsing cleaner because a Lane Instrument becomes a real object rather than a disguised pad.

Implementation guardrail: Do this as a backend migration-free refactor because legacy files do not matter right now. First replace lane playback/record/edit lookups with instrumentId-backed records, then remove customer-facing pad-slot menu paths, then delete or quarantine transitional helper names like findNextUnusedArrangementInstrumentPad once all internal call sites are gone.

2026-07-23 - Lane Identity As Creative Metadata

When a lane owns the musical role, patch names and rendered assets should inherit that role whenever possible. A bass lane that produces a Quasar package should naturally create a bass-named package, not a hidden-slot package. This strengthens future preset-browser metadata: CATEGORY / PRESET / INFO can start from the musical job the user assigned to the lane.

2026-07-23 - Lane Lock As Teaching UI

• A disabled control can still teach the wrong mental model if its value says the wrong thing. Lane-owned clips should always read as lane-owned, even in controls that are currently hidden or disabled.
• This same principle should guide future automation lanes: when the user is editing a lane-scoped object, every nearby label should reinforce the lane as the musical container.

2026-07-23 - Copying As Orchestration

• Copying an existing instrument into a lane is not really about copying a source slot; it is about borrowing an orchestration choice. Labels should therefore name the engine, patch identity, and mixer destination.
• This same idea can become powerful later for SpaceAge Scenes: scene variations can describe orchestration swaps in musician language rather than storage language.

2026-07-23 - Action Targets Should Follow Visual Context

• When a user is looking at a lane-owned synth editor, copy/paste should follow that visible editor target. Hidden global selection state is a classic source of “why did it change that?” bugs.
• This principle should apply to future Instrument Bay and automation tools: action buttons should derive their target from the panel that owns them, not an unrelated historical selection.

2026-07-23 - Instrument Copy Should Not Copy The Mix

• A composer who duplicates an instrument is asking for the sound-making machine, not the channel-strip context. Mixer gain, sends, mute/solo, output, compression, saturation, and EQ should remain lane/channel concerns.
• This clean split supports future SpaceAge Scenes: orchestration choices can change without accidentally rewriting the mix.

2026-07-23 - Editing Should Preserve Creative Location

When a composer asks to edit the sound for a lane or clip, SpaceAge should preserve their mental location. Opening the Synth Editor as an overlay on Arranger or Piano Roll keeps the user inside the musical context they were already thinking about. This same pattern can later support effect editors, automation editors, and clip decoration editors without forcing page jumps.

2026-07-23 - Copying A Sound Should Name Its Musical Owner

A copied instrument is not just a storage slot; it is usually a sound already living in a lane. Naming the lane first helps the user think musically: copy the Harmony sound, duplicate the Bass sound, make this lane a variant. This keeps the future Instrument Bay path clean while the code still uses transitional backing slots internally.

2026-07-23 - Lanes Teach Ownership Faster Than Slot Numbers

A composer should learn by looking: a lane's label, mixer destination, MIDI channel, and instrument name should tell the story without forcing them to remember a hidden slot number. The transitional backing slot can keep the project compiling, but the surface language should already behave like the final design: a lane owns an instrument; the pad grid is for drum/performance behavior, not a proxy instrument rack for every musical part.

2026-07-23 - Ownership As A First-Class Feeling

The app gets calmer when ownership is explicit. A lane-owned instrument should feel like a named object in the song, not like a technical address. Exposing laneOwned is tiny in code, but it lets future UI say: this belongs to this musical lane, this is merely available, and this is a drum/performance pad context. That distinction is part of making SpaceAge feel deliberate rather than improvised.

2026-07-23 13:21 - Lane Ownership as One Visual Truth

Centralizing lane ownership lookup supports the larger Instrument Bay idea: the lane badge should teach the user what instrument is active, which mixer channel receives it, and where MIDI will go. Keeping this logic in one place makes future visual treatments safer, including lane color states, ghost-note eligibility, and direct edit buttons.

2026-07-23 13:25 - Label Language as Workflow Design

Changing the Synth Editor title prefix from generic SYNTH ENGINE to LANE INSTRUMENT for owned slots is small, but it reinforces the final workflow: compose by choosing instruments on lanes, use pads for drum/MPC behavior, and let labels teach the architecture without adding tutorial clutter.

2026-07-23 - Lane Instruments And Cognitive Load

• Treating non-drum lanes as lane-owned instruments, even while backed by transitional slots, gives the user one obvious place to inspect and change sound: the lane badge itself.
• Drum lanes remain a deliberate exception: their identity is a grid of pad assignments, not a single melodic instrument. The UI should keep teaching that difference without making non-drum lanes feel pad-bound.

2026-07-23 - Choosing Instruments Should Teach The Architecture

• A lane badge should teach that a lane owns an Instrument. Copying from another lane is musically understandable: borrow that sound, keep this lane independent. Listing raw hidden slots teaches the wrong model and creates the old pad-proxy confusion.
• This also sets up future Scenes: orchestration swaps can operate on lane-owned Instrument identities rather than pad-slot bookkeeping.

2026-07-23 - Mixer Visual Redesign And PRINT Semantics

Task: Begin implementing the cleaner mixer visual direction from the latest mockup: calmer blue metering, orange send controls, slimmer channel faders, and clearer send visibility.

What connects creatively: The mixer is the place where SpaceAge stops being only a composition toy and starts feeling like a serious workstation. Keeping send controls visually simple and shared reinforces the rule that instruments make sound while the mixer shapes the mix. PRINT should mean rendering the whole mix to an audio file, matching studio language without confusing it with MIDI recording.

Architecture choice: This pass is UI-only: existing mixer send parameters and attachments stay in place, but mixer gain faders and send bars now opt into reusable look-and-feel paths. That keeps the styling reusable for future Mixer, Effects, and automation surfaces without changing routing.

Future extensions: Add a dedicated PRINT/render surface with a progress meter, scope choices, stem options, hardware-print preflight, and a receipt. The same visual meter/fader language can later serve bus strips, aux returns, and scene-based orchestration comparisons.

2026-07-23 - Mixer Strip Readability Pass

The mixer redesign should keep visual pleasure tied to operational clarity: blue meters identify signal, orange send bars identify ambience/effect routing, and the main fader stays visually quiet so channel gain remains legible instead of decorative. The first hidden channel-strip page now treats Halostar, Reverb, and EchoRay as distinct destination blocks, which connects directly to the larger Instrument Bay rule: instruments make sound, mixer strips shape and route it.

Mixer Card Redesign Must Be Visible

Task: Make the mixer look meaningfully different from the old presentation, not merely polish existing internals.

What connects creatively: The mixer is where SpaceAge starts to feel like a finished workstation instead of a prototype. A visible card-backed channel-strip system, calmer blue meters, orange send controls, and taller gain faders reinforce the mental model that instruments live in lanes while sound-shaping and routing live in the mixer. This same card language can later support larger channel-strip editors, automation lanes, and hardware routing without changing the user's basic understanding.

Mixer Ergonomics and Lane Insertion

Task: Keep the restored mixer look, but make channel-strip gain easier to dial in by extending fader travel, shortening the meter area, and enlarging the three lower strip buttons. Also make fresh Instrument lanes insert at the top of the Arrangement stack while Drum lanes continue grouping near Drum lanes.

What connects creatively: This reinforces two SpaceAge workflow rules. First, mixing should feel precise without making the user type numbers; a taller gain throw gives the hand more resolution while the meter remains present but less dominant. Second, arrangement lanes should teach orchestration: new melodic/harmonic instruments appear above the stack, while new Drum lanes stay with the drum family. That helps the GUI arrange itself according to musical hierarchy without making the user clean up after every add action.

2026-07-23 - Arrangement Overview, Mixer Master Boundary, and True Window Max

• Arrangement overview should behave like a composer-level navigation aid: fit width to the song, then only compress lane height when the lane stack actually exceeds available height. This preserves readability while still supporting dense sessions.
• A subtle Master divider in the mixer reinforces the classic separation between channel strips and the final bus without redesigning the mixer.
• MAX should respect the OS work area instead of pretending fullscreen is the same thing as maximize. That keeps the app feeling native and avoids taskbar/window chrome weirdness.

2026-07-23 - Clip Preview Truthfulness

Long Arrangement clips need miniature note graphics that communicate the whole musical span, not just the first stored events. Sampling preview events across the clip length keeps dense 128-step variants honest at a glance, and it pairs well with future preview density settings like modest/bold MIDI representation.

2026-07-23 - Lane Birth Should Include Sound-Source Intent

A new instrument lane should be born with the user's sound-source choice already attached. Asking for the engine at creation time avoids corrective UI work, reinforces that instrument lanes are not pad proxies, and prepares the future Instrument Bay browser to create lanes directly from engine/category/preset records.

2026-07-23 - Mixer Destination Is A Lane Decision

Instrument choice and mixer destination are separate musical decisions. A user may want to swap Redshift for SoundFont without losing the mix lane, or route several auditioned sounds through the same channel-strip treatment while comparing them. Making mixer channel a lane-owned field is the small architectural move that enables that workflow, and it also prepares future Scenes to swap orchestration without rewriting the mix.

2026-07-24 - Source Slot And Mixer Destination Are Different Concepts

A lane-owned instrument needs two hidden truths: where the sound generator lives internally, and where its audio lands in the mixer. Those should not be the same customer-facing idea. Splitting Voice::pad from Voice::mixerChannel lets SpaceAge preserve the temporary backing-slot bridge while teaching the final workflow: the lane owns the instrument, and the lane chooses its mixer strip. This also connects to future Scenes, because orchestration can change independently from the mix.

2026-07-24 - Preview Must Match Playback

Live MIDI preview is part of the composition contract. If a lane is routed to Mixer Channel 12, the user must hear Channel 12 while playing a controller, not only after playback. Adding live-input mixer routing avoids the "it sounded different when I recorded it" problem and keeps the lane badge honest as the control center for instrument identity, MIDI input, and mixer destination.

2026-07-24 - Mixer Channel As A Docking Port

Treating lane mixer destinations as independent docking ports opens the door to cleaner orchestration scenes: the same lane instrument can be re-routed, grouped, or compared without changing the musical clip or the hidden backing instrument instance. This also supports future scene/orchestration switching where composition stays fixed and mixer/instrument choices can be auditioned as alternate realities.

2026-07-24 - Recording Should Not Change The Room

Recording controls should avoid surprising the user with unrelated monitoring changes. Count-in is a deliberate cue, and record-only metronome is an explicit preference; outside those cases, pressing record should honor the current session state. That principle connects MIDI capture, Arrangement recording, and future hardware recording: SpaceAge should help the musician enter the performance, not change the environment without consent.

2026-07-24 - Edit Context As A Clean Break From Pads

Renaming the editor's current Piano Roll source from pad language to instrument-slot language is small, but it points at the larger product move: non-drum lanes need an edit context that says "this lane owns this instrument" while Pads remain the MPC-style drum/performance surface. The creative opportunity is that the same edit context can later power Instrument Bay, lane-level preset browsing, orchestration Scenes, and hardware/VST routing without teaching four different mental models.

2026-07-24 - Active Instrument Context

The Synth Drawer is becoming a shared editor for lane-owned instruments and pad-owned sounds. The creative payoff is that the same deep sound-design surface can serve MPC-style pads, ordinary instrument lanes, and future Instrument Bay records without teaching users three different editors. The engineering rule is simple: the drawer needs a single active edit context, and Pads selection should be just one possible source of that context, not the master switch for everything.

2026-07-24 - One Editor, Many Owners

A single Synth Drawer can remain elegant if ownership is explicit: Pad-owned sounds, lane-owned instruments, Quasar captures, and future hardware templates should all arrive at the same editor through a small active-context gateway. That lets the UI feel simple while the backend stops pretending every musical object is a drum Pad.

2026-07-24 - Creative Link: Lane-Owned Instruments As The User's Mental Anchor

A lane should teach the user what sound is active, where it is routed, and what will receive MIDI. Keeping non-drum synth editing independent from Pad selection reinforces the larger Instrument Bay idea: Pads can remain performance objects, while melodic/harmonic lanes become composition objects. This same separation can later support Scenes, orchestration swaps, per-lane ghost-note visibility, and MIDI hardware profiles without making the user think in hidden Pad numbers.

2026-07-24 - Creative Link: Instrument Bay As A Future Preset Browser

The same lane-owned instrument slot that now avoids Pad selection can become the anchor for the future preset browser: CATEGORY, PRESET, INFO, engine name, author, and lane launch target. The user should eventually feel they are choosing a sound for a lane, not loading a sound onto an invisible Pad. Pads can still be their own performance/sampling universe.

2026-07-24 - Instrument Slot Language as Architecture

Separating lane-owned instruments from pad terminology is more than a label cleanup: it lets Arrangement lanes become the user's stable musical actors, while Pads remain performance-oriented drum/sample launch surfaces. This should make future Instrument Bay, mixer reassignment, MIDI hardware routing, and Scenes/alternative orchestration features easier to reason about because a lane owns an instrument slot and a mixer route, not a borrowed pad identity.

2026-07-23 - Slot Language as Guardrail

Renaming the lane-owned backing concept from Pad to Slot is not just tidying. It prevents future UI and MIDI features from assuming that every melodic lane must pass through an MPC-style pad. The creative opportunity is that Pads can remain an expressive drum/performance surface, while Instrument Bay becomes the calmer place where lanes choose persistent synth, sampler, hardware, or future VST identities.

2026-07-23 - Slot First, Registry Next

The slot API is a bridge: it lets us keep the working voice engine while training the codebase to think in Instrument Bay language. The creative payoff is that a future lane can become a stable musical actor with its own instrument, mixer route, MIDI route, automation, and patch identity, while Pads remain a playable grid rather than the hidden owner of every synth.

2026-07-23 22:23 - Creative Connection: Slot Wrappers as a Product Boundary

The slot-wrapper layer is not merely nomenclature cleanup. It creates a useful boundary where Arrangement lanes can behave like real instrument tracks while Drum Composer and Pads retain their MPC-style identity. This boundary can later host the Instrument Bay browser, lane-level MIDI channel assignment, scene-based orchestration swaps, and future VST instrument routing without leaking Pad language into the user's mental model.

2026-07-23 22:32 - Creative Connection: Reserved Drum Surface

Keeping Pads 1-16 reserved for drum-minded interaction makes the app easier to teach: the bottom drum surface stays tactile and MPC-like, while Arrangement lanes can evolve toward an Instrument Bay model. This sets up future UI language where Drum Lanes choose kits/pads and Instrument Lanes choose instruments/presets/scenes.

2026-07-24 - Creative Link: Private Instrument Slots as a Bridge to Instrument Bay

The temporary private slot policy gives SpaceAge a cleaner user story immediately: pads can feel like pads, while lanes feel like instruments. Later, the same boundary can become the seam where true Instrument Bay records replace the 64-slot pad-backed plumbing without changing the user-facing workflow again.

2026-07-23 23:32 - Recording As A Take, Not A Box

Arrangement recording should feel like capturing a human performance into a lane, not like filling a fixed drum-machine bucket. The same principle can connect later to comping, takes, loop-on-release sampling, and automation capture: the user's gesture defines the musical span, and the container should reveal that span clearly unless the user deliberately constrains it.

2026-07-24 - Import Mapping Should Teach The Lane Model

MIDI import is a first-contact workflow for outside musical material, so its labels should reinforce SpaceAge's lane-owned instrument model. Calling a destination a lane instrument tells the user what will happen musically; showing a raw backing slot number teaches the wrong mental model and resurrects the old pad-proxy confusion.

2026-07-24 - Backend Contracts Should Match The User's Mental Model

Once the GUI teaches that imported melodic material becomes lane-owned instruments, the backend has to enforce that story even when old/custom requests contain stale values. This is a broader design rule for SpaceAge: labels, routing, persistence, and import/export receipts should all describe the same musical object, or users will eventually discover a contradiction under pressure.

2026-07-24 - Central Guardrails Make The Workflow Trustworthy

Task connection: Shane wants pads to behave like pads and instrument lanes to behave like lane-owned instruments. The most reliable way to protect that mental model is not just UI language, but central backend guardrails. If old or sloppy code hands a melodic lane a visible drum-pad slot, the processor should quietly correct the data before playback, export, MIDI recording, or mixer routing sees it. That makes future UI experiments safer because the core model resists drifting backward.

2026-07-24 - Import Should Preserve The Composer's Mental Map

A MIDI import dialog is often a user's first test of whether SpaceAge understands an outside composition. If imported melodic channels secretly become drum-pad assignments, trust drops immediately. Clamping melodic imports into lane-owned instruments makes import feel like orchestration: drums go to drum lanes, tonal material goes to instrument lanes, and the user's song map stays readable.

2026-07-24 - Standalone Sketching Should Still Teach The Final Model

Even when the user is sketching in the Piano Roll outside an Arrangement lane, the interface can rehearse the final SpaceAge model: drums live on pads, tonal material lives on instruments. Restricting that selector to lane-instrument space avoids a tiny but meaningful cognitive snag where a melody appears to be authored by a drum pad.

2026-07-24 - Helper Code Is Part Of The Interface

A user's workflow is shaped not only by labels and menus, but by the invisible helper routines that respond after a click. If those helpers preserve the old pad-based model, the app will feel inconsistent even when the surface language is right. Aligning helper clamps with lane-owned instruments makes the interface and backend tell the same story.

2026-07-24 - Public API Names Shape Future Work

Renaming step input from Pad to Instrument Slot is not cosmetic housekeeping. It keeps new work pointed at the final architecture: tonal lanes and Piano Roll behaviors target instruments, while pads remain a deliberate drum/MPC interface. That makes future MIDI automation, preset browsing, and hardware routing less likely to inherit the wrong mental model.

2026-07-24 - Presets Follow The Instrument, Not The Surface

Preset application is part of the composer's trust contract: when a lane-owned instrument is open, choosing a preset should change that lane's sound, not the last pad the user touched. Routing preset writes through the active edit context lets the same beautiful synth editor serve Pads, lanes, and future Instrument Bay records without making users think about hidden backing slots.

2026-07-24 - Trust Comes From Every Layer Saying The Same Thing

The user-facing model is simple: drums live on Pads, songs live in lanes, and lane instruments belong to lanes. A small playback guardrail supports that larger creative promise because the sound engine now agrees with the UI, import, and save-state layers instead of merely trusting them. This is the kind of hidden consistency that makes a music app feel calm under pressure.

2026-07-24 - Hidden Tests Protect The Visible Promise

The user-facing promise is simple: instrument lanes are not Pad proxies. The hidden engineering trick is making every layer repeat that promise, including playback snapshots that the user never sees. This kind of regression is creatively useful because it lets us keep simplifying the visible workflow while hardening the invisible contract underneath it.

2026-07-24 - Undo Should Follow The Human Gesture

A user thinks of “duplicate this instrument into a new lane” as one act, even though the app performs multiple internal moves. The architecture should keep these bundled: private synth state, lane identity, clip creation, mixer routing, and selected-lane feedback should undo together so SpaceAge feels trustworthy instead of procedural.

2026-07-24 - Instrument Editing Should Feel Like Direct Manipulation

The lane badge says “this is the instrument.” Every editor action opened from that badge should touch exactly that instrument, no matter which Pad was selected earlier. This keeps the future Instrument Bay concept honest: Pads can remain expressive drum objects, while lanes become clear, private orchestration choices.

2026-07-24 - Hidden Panels Are Still Part Of The Instrument

The Instrument Bay design only feels direct if every related editor follows the same target. Flux Nodes, used-tab indicators, preset tools, and future modulation editors should all behave like extensions of the visible instrument, not like separate global/pad utilities.

2026-07-24 - Language Teaches Architecture

The Instrument Bay transition is not just code; the words teach the product. Calling a melodic lane target an Instrument instead of a Pad prevents the user from forming the wrong mental model, which will make the later full registry refactor feel obvious rather than disruptive.

2026-07-24 - Lane Authority And Variants

A lane should feel like the owner of its sound, but shared musical material needs respect. This suggests a future UX improvement: when a shared pattern is detected during instrument changes, offer a clear Make Variant and Retarget action so the user can intentionally split orchestration from composition.

2026-07-24 - Lane Authority And Variants

The lane can safely act as the user's visible instrument authority only when pattern payload ownership is clear. A future refinement could offer a one-click prompt: Make Variant And Retarget, turning a shared clip into a lane-private clip before changing its instrument metadata.

2026-07-24 - One Gesture, One Model Update

The visible user gesture is simple: choose an instrument for a lane. The model should absorb the hidden chores: slot normalization, private pattern retargeting, and shared-pattern protection. This same pattern should guide future mixer reassignment and Hardware Passport routing.

2026-07-24 - Explicit Drum/Piano Worlds

The more SpaceAge separates Drum Composer pads from Piano Roll instruments, the easier the user story becomes: pads are playable objects in the MPC world; instrument lanes are orchestration objects in the Arrangement world. A future bridge can be intentional, not accidental.

Creative Thinking - Explicit Slot Worlds

The app gets easier to teach when the user can infer object type from location: Drum pads belong to the Drum Composer, while lane instruments live in the Instrument Bay. Keeping ownership lookup honest lets future UI labels and routing helpers say less because the model itself is less ambiguous.

Creative Thinking - Sound Design Without Focus Theft

A user should be able to design a drum pad while a melody lane remains armed, or tweak a private lane instrument without disturbing the drum grid. This supports a future split-screen workflow where Pad Lab and Piano Roll can coexist without hidden routing surprises.

Creative Thinking - Labels Are Architecture

The sound engine can keep a transitional backing store, but the product language should tell the future truth: lanes own instruments. Sanitizing default Pad labels in private Instrument Bay records keeps the GUI, docs, MIDI workflow, and future preset browser pointed at the same mental model.

2026-07-24 - Instrument Copy As Sound Promotion

Copying between lane-owned instruments should stay lane-to-lane by default. If we later want a creative gesture such as "promote this pad sound into the Arrangement," it should become an explicit Import From Pad command with clear wording and confirmation rather than a generic InstrumentSlot copy. A melodic lane should never overwrite or silently depend on a visible Drum Composer pad by accident, because that blurs the clean Drum Composer versus Instrument Lane model we are finishing.

2026-07-24 - Clear API Boundaries Teach The Product

A boring backend rule can become a better product rule: Pad APIs are for the drum surface, InstrumentSlot APIs are for lane-owned instruments. Keeping that vocabulary honest in code makes it easier later to replace the bridge with a true Instrument Bay registry without changing how users think about the app.

2026-07-24 - Selection State Should Be Honest Or Absent

A lane-owned instrument should not pretend to be a selected pad. But when the user is actually working in a pad-like context, selection state should be complete and coherent: pad plus bank/page. This keeps both mental models clean instead of letting them smear together.

2026-07-24 - Honest Focus Improves Musical Confidence

Separating private instrument edit focus from visible pad selection is more than cleanup: it lets SpaceAge teach the user that lanes are instruments while pads are drum-performance surfaces. The same pattern can later support a proper Instrument Bay browser where edit, audition, record-arm, and mixer routing are explicit, independent facets instead of hidden side effects.

2026-07-24 - Lane Instruments As Identity Anchors

• The more SpaceAge treats a lane as the home of an instrument, the easier it becomes to make later features feel obvious: MIDI routing, mixer assignment, patch editing, automation, ghost notes, and export naming can all point back to the lane instead of forcing the user to remember a hidden Pad proxy.

2026-07-24 - Automation As A First-Class Lane Companion

Automation needs to feel like part of composition rather than a hidden MIDI utility. Naming the visible entry points as AUTOMATION/AUTOMATION LANES connects CC, bend, pressure, sustain, and expressive curves to the same mental model as clips, chords, and arrangement lanes. Longer term, this opens a clean bridge to Motion Clips and tempo-aware effectors without forcing users to think in raw MIDI jargon first.

2026-07-24 - AUTO Input Should Behave Like A Welcoming Door

A musician who plugs in two controllers expects the armed lane to hear them unless they have explicitly narrowed the lane to one physical input. The better default is permissive but honest: accept direct controllers when no input is pinned, warn about duplicate host/direct paths in MIDI Health, and become strict only when the lane names a device. That keeps casual sketching fluid while preserving professional source identity for hardware rigs.

2026-07-24 - Direct Monitoring Without Throwing Away Musical Time

The useful split is human-facing immediacy plus machine-facing accuracy: live MIDI should sound now, while the recorder should still remember when the player actually struck the key. That same idea can guide automation recording later: render feedback instantly, but store the authored gesture at its proper timeline position.

2026-07-24 - Mixer Routing Is Not Instrument Identity

A lane can own an instrument, choose a MIDI channel, and feed a mixer channel, but those are three different creative choices. Keeping the fallback behavior lane-based instead of hidden-slot-based protects future workflows like re-orchestration, scenes, and user-assigned mixer routing without resurrecting the old Pad-as-instrument-proxy confusion.

2026-07-24 - Label Cleanup Protects The Mental Model

Small string details can still shape the product. If default Pad labels leak into lane-owned instrument displays, the user starts thinking about hidden pad assignments again. Fixing the padding logic keeps the Instrument Bay transition pointed at the desired mental model: drums use Pads, Arrangement lanes own Instruments.

2026-07-24 - Recording Confidence For Long Musical Ideas

Long clips are not just larger containers; they are trust objects. If a player records into the second half of a 256-step idea, SpaceAge must prove it can preserve the human performance exactly where it happened. This connects MIDI timing, Arrangement zoom/navigation, and future automation lanes: every timeline object needs to keep faith with late-position input, not quietly pull the user back to bar one.

2026-07-24 - Copy Semantics Teach The Instrument Bay Model

A small backend rule can teach the larger product idea: if instrument lanes only copy from other instrument lanes, the app reinforces that Pads are for MPC-style drum/percussion work while Instrument Bay choices are lane-owned sound sources. That separation will make future preset browsers, scenes, and mixer reassignments easier to explain because users will not wonder whether a melodic lane secretly belongs to PAD 23.

2026-07-24 - Clipboard Boundaries Teach The Instrument Bay

Copy and paste can be a teaching surface. Keeping Pad clipboard operations separate from lane-owned instrument paste tells the user, through behavior, that Pads are performance cells and Arrangement lanes are instruments. If we later add an "Import From Pad" action, it should be named, intentional, and probably useful as a creative bridge from Drum Composer sound design into a melodic lane.

2026-07-24 - Keeping Instruments Pure And Mix Decisions Reversible

Removing effect-send and channel-strip writes from generator presets strengthens the Instrument Bay idea: choosing or randomizing an instrument should not secretly redesign the mix. This also makes future Scenes cleaner, because orchestration choices can swap instruments while mixer routing remains a deliberate, visible decision.

2026-07-24 - Removing Fossils Protects Future Workflow

Small dead-code removals matter here because SpaceAge is still shedding the old pad-as-instrument bridge. Every stale helper name that says Pad in a lane context is a future invitation to rebuild confusion. Removing those fossils keeps the code's vocabulary closer to the product's intended mental model: lanes own Instruments; Pads remain the drum/MPC surface.

2026-07-24 - Recording Should Follow The Playhead, Not The User's Wandering Eye

A musician may select something for editing, then move the playhead to perform into another spot. SpaceAge should honor the musical time cursor over visual curiosity. This same rule can shape future automation recording, punch-in, and comping: the playhead and armed lane define capture, selection defines editing.

2026-07-24 - Names Are Part Of The Instrument Bay UI

The Instrument Bay migration is not only data plumbing. Every stale Pad label around a lane-owned synth editor teaches the wrong workflow. Refreshing labels immediately makes the interface feel calmer: the user sees the lane, its Instrument, its mixer route, and its MIDI channel as one coherent object.

2026-07-24 - Automation Naming And MIDI Gate Pass

Automation needs one clear product word. The compact badge can say AUTO when space is tight, but the tooltip and opened panel should consistently teach Automation as the musical object: recorded or drawn movement over time. That lets the same concept connect Arrangement lanes, Piano Roll expression, future Motion Clips, MIDI CC editing, and hardware-controller capture without inventing a separate mental model for each surface.

2026-07-24 - Instrument Bay Wording Cleanup

The app should reserve Pad for MPC-style drum/sampler interaction and use Instrument for lane-owned melodic/harmonic sound generators. This keeps the user model simple: Drum lanes talk to pads; instrument lanes talk to instruments. The Instrument Bay can still use the same underlying slot machinery, but the GUI should not reveal that implementation detail unless it helps diagnose routing.

2026-07-24 - Automation Editor Button Clarity

Action buttons should name the physical gesture or musical result, not the internal category. ADD POINT and DRAW RAMP are better than AUTO POINT and AUTO RAMP because they connect directly to future Motion Clips, synth modulation curves, tempo-synced FX movement, and any other place where the user draws change over time.

2026-07-24 - Recording As A Contract Between Lane And Playhead

Recording should have one obvious owner and one obvious time cursor. The lane says what instrument receives the performance; the playhead says where the performance lands. That same contract can later power punch-in recording, Arrangement automation capture, and clip-level takes without asking the user to remember which object was last selected for editing.

2026-07-24 - Recording Copy Should Prevent Wrong Mental Models

A tooltip can prevent an entire class of user mistrust if it names the hidden rule before the user trips over it. Saying that selection does not steal live input connects Arrangement recording to the Instrument Bay model: lanes are the performance destination, while selected clips are editing objects. This same wording pattern should guide punch-in, automation recording, and hardware capture later.

2026-07-24 - Recording State As A Visible Contract

Recording is not just backend transport state; it is a trust contract. If SpaceAge is recording, counting in, or armed for a lane, the visual system must say so immediately. This connects the MIDI engine, Arrangement Canvas, REC button, and lane badge into one mental model: lane chooses instrument/input, playhead chooses time, REC state says whether capture is pending or live.

2026-07-24 - Automation Discoverability Is Naming Plus Location

A feature can be implemented and still feel invisible if the naming changes by page. SpaceAge should treat Automation as the plain-language doorway, while compact AUTO badges act as space-saving icons. The user should not need to decode whether AUTO, A2, MIDI expression, or automation means a different system unless ownership truly differs.

2026-07-24 - Full Labels Where The Eye Has Room

Automation can use compact shorthand inside clips, but primary buttons should use full language when there is enough room. This lets SpaceAge teach the feature name every time the user scans the Piano Roll, while keeping dense clip interiors uncluttered.

2026-07-24 07:51 - Automation Naming Discipline

• Treat Automation as the musician-facing concept and AUTO as compact telemetry. This keeps the UI teachable while preserving short status badges where space is tight.

2026-07-24 07:58 - Lane Instruments Without Implementation Trivia

• The cleanest public model is not 'private slot' or even 'Instrument Bay slot'; it is simply the Lane Instrument. The Instrument Bay is where instruments are chosen and managed, while each lane owns an instrument instance. That distinction will matter later for scenes, orchestration swaps, preset browsing, and hardware routing.

2026-07-24 08:06 - Language As Architecture

A product model becomes real when every tiny label obeys it. Calling private backing records Lane Instruments instead of raw instrument numbers helps musicians understand SpaceAge as lanes owning playable instruments, while Pads remain the tactile MPC/drum surface.

2026-07-24 08:11 - Preset Names As Product Truth

The preset name is often more visible than the explanatory text. If an empty private instrument says Init Redshift, the user hears 'fresh patch'; if it says Instrument 59, the user hears 'hidden pad slot.' Small words shape workflow trust.

2026-07-24 08:15 - Automation Naming Stability

A stable doorway name lowers cognitive load. Compact AUTO badges are useful as tiny canvas glyphs, but prose should say Automation so users understand the feature without learning an internal nickname first.

2026-07-24 08:47 - MIDI Health As A User Confidence Surface

Latency reports are not just QA output; they are part of the user's trust loop. Keeping Latency checks inside Next Steps turns a scary symptom like controller lag into a small checklist: lower buffer, compare routes, prefer wired paths, and use MIDI Timing only for recorded placement. The same design principle should guide future MIDI troubleshooting UI.

2026-07-24 08:57 - Automation As One Landmark

A deep feature needs one memorable doorway. Moving the MIDI expression workbench language toward Automation makes it easier to connect visible lane badges, Piano Roll editing, MIDI Health receipts, export/import proof, and future Motion Clips under one mental object. Compact labels can still exist where pixels are scarce, but reports and help text should teach the clearest noun.

2026-07-24 09:05 - Automation Target Language As Workflow Glue

When a button can legally target more than one owner, the UI should name how it chose the owner. The Arrangement Automation button now makes the implicit targeting rule visible in the tooltip without adding another control. This keeps the surface minimal while reducing the user's need to memorize selection/playhead/fallback behavior.

2026-07-24 09:10 - Menus Should Begin With Current Reality

Instrument and routing menus are safer when they begin by reporting the current state before offering changes. The lane instrument menu now starts with a CURRENT receipt, which makes the lane-owned Instrument Bay migration easier to understand without adding a new permanent UI widget.

2026-07-24 09:14 - Avoiding Cross-Domain Words

A word can be musically correct and still be product-confusing. Pad is a valid synth preset family, but SpaceAge also has a concrete PADS surface for MPC-style drum/performance work. Renaming pad-like Piano Roll preset categories to Atmosphere keeps the creative invitation while protecting the one-instrument-per-lane mental model we are trying to teach.

2026-07-24 09:18 - Atmosphere As A Product Word

Atmosphere is doing useful double duty: it still tells musicians that a preset can occupy pad-like harmonic/background space, but it avoids colliding with SpaceAge's concrete PADS page. This is the kind of vocabulary discipline that helps the app feel internally obvious instead of requiring users to memorize exceptions.

2026-07-24 09:23 - Automation Needs To Teach Ownership Before Editing

Automation is powerful enough to be scary if the user cannot predict who owns the move. The lane badge is an important tiny teacher: it should say that SpaceAge previews the effective layered result, then lets the user choose Shared PTN, Clip Local, or Lane Local before writing. That keeps expressive MIDI from feeling like hidden magic.

2026-07-24 10:52 - Backend Defaults Should Teach the Workflow

When import, recording, or lane creation happens without explicit user choices, the backend should make the same musical assumption the UI would teach: drums remain pad-backed; melodic lanes receive independent private instruments. Tests should protect stable behavior and user-facing clarity, not brittle internal wording that changes as the product matures.

2026-07-24 11:08 - Imported MIDI Should Not Create Hidden Shared Instruments

A multichannel import is a songwriting act, not a storage act. Even when two imported channels ask for the same private backing slot, SpaceAge should preserve the lane-first mental model by giving each melodic lane its own instrument instance. If the composer wants shared orchestration later, that should be an explicit copy/scene/orchestration workflow, not an accidental import side effect.

2026-07-24 11:16 - Helper APIs Should Not Leak Transitional Storage

Even compatibility helpers need to speak the final product language. If a backing slot is private and only exists because the bridge still stores instruments in pad-shaped arrays, default Pad labels should be treated as invisible storage defaults. Real user names remain visible; accidental implementation names do not teach the wrong workflow.

2026-07-24 11:35 - A Take Needs a Trust Badge, Not Just Counters

When MIDI recording drops events, the important user-facing question is not the exact queue statistic first; it is whether the take can be trusted. The new Recording Queue Trust line can later connect to Arrangement clip badges, post-recording dialogs, and automated retake prompts: if a take is untrusted, the clip could carry a small warning marker until repaired or rerecorded.

2026-07-24 11:55 - Take Reliability Can Become a Creative Safety Net

The new Recording Take Reliability verdict can become more than diagnostics. Later, Arrangement clips recorded from MIDI can inherit a tiny reliability badge: clean takes stay invisible, timing-suspect takes invite calibration, and untrusted takes ask for retake or repair. This connects backend health to the composer's lived workflow without making them read engineering counters.

2026-07-24 12:12 - Diagnostics Should Point the Hands

The Recording Take Action line is a small example of SpaceAge's desired temperament: do not merely tell the user something is wrong, tell their hands what to do next. This same pattern can later apply to clips, synth patches, failed renders, hardware setup, and import repair: diagnose, then offer the shortest safe next move.

2026-07-24 12:35 - Proof Work Should Be Actionable

A proof checklist is only useful when it tells the next human action. The launch validation matrix already knew the required evidence, but the Health surface needed a compact translation: what to capture, where to capture it, and what receipt key proves it later. This pattern should be reused anywhere SpaceAge creates trust gates: show the verdict, the next physical/composer action, and the evidence object that will make the claim true.

2026-07-24 12:52 - Reports Should Not Leak Storage Names

Health reports may be copied into support emails, release notes, screenshots, and Shane's own planning notes, so they need to sound like SpaceAge rather than a database dump. Keeping internal keys in structured payloads while translating them into human receipt names in prose gives us both auditability and polish.

2026-07-24 13:06 - Rows Now, Lanes Later

Automation is already a big word. Calling the current MIDI expression controls Automation rows keeps today's feature honest and leaves room for the later full Arrangement automation-lane concept. The naming ladder becomes: Automation doorway -> rows inside the editor -> future lanes in the Arrangement canvas.

2026-07-24 13:24 - A Doorway Can Be Honest While Still Clickable

An empty lane can still offer a helpful Automation doorway if it teaches why editing cannot start yet. The important distinction is visual honesty: blue means a real clip-backed target is ready; grey means the selected lane is a context, but the user needs to add or select a clip before MIDI Automation rows have an owner.

2026-07-25 00:12 - Receipts Are Part Of The Interface

A setup receipt is a miniature UI: users may copy it, trust it, or use it to remember what still needs doing. If a receipt says AUTO LANES while the app says Automation, the user has to wonder whether those are different features. Keeping receipt vocabulary current is low glamour, high trust work.

2026-07-25 00:34 - Labels Are Architecture Lessons

The lane badge is not just decoration. It teaches the ownership model every time the user looks at the Arrangement Canvas: lane, mixer channel, MIDI channel, instrument. Guarding that text in tests helps SpaceAge stop sliding back into the old pad-proxy mental model even when the storage layer still uses pad-shaped arrays internally.

2026-07-25 00:58 - Doorways Need One Compass

Automation is already abstract, so its doorway must feel predictable. A button that sometimes opens the selected clip and sometimes opens the playhead clip is acceptable only if the rule is shared by the label, tooltip, status text, and click path. One resolver turns that behavior into a product promise instead of a coincidence.

2026-07-25 01:18 - Recording Needs One Finger Pointing

Live recording is not ordinary editing. The selected clip can remain the editing object, but the armed lane plus playhead must be the performance target. This keeps the musician's body logic intact: choose the lane, move the playhead, press REC, play. The test now protects that simple mental model so future MIDI and Instrument Bay work can build from it.

2026-07-25 01:42 - Status Lines Are Mini Manuals

The status line is a teaching surface, not just a receipt. When a user arms MIDI input, the app should immediately repeat the important truth: which lane, which mixer channel, which MIDI channel, and which input filter. That small sentence can later connect to lane badges, MIDI Health, recording receipts, and Hardware Passport setup so all of SpaceAge speaks with one route vocabulary.

2026-07-25 02:03 - Navigation Should Not Erase Confidence

Opening a clip is a context switch, and context switches are where users lose certainty. Carrying the armed MIDI route summary into the clip-open status is a small UX move with architectural consequences: edit focus and live-performance focus can coexist in one sentence instead of competing for the status line.

2026-07-25 02:31 - Receipts Can Become Tiny Debugging Instruments

A recorded note receipt should be useful to a musician and a tester at the same time. If it says lane, mixer channel, MIDI channel, input filter, pitch, timing, and velocity, the user can immediately see whether the take landed in the intended musical place. Later this same receipt style can feed clip badges, MIDI Health evidence, undo labels, and hardware-support screenshots.

2026-07-25 15:17 - One Route Sentence Beats Five Half-Truths

MIDI routing has enough invisible state that small wording drift can become a usability bug. The shared route summary is not glamorous, but it creates a reliable "cockpit sentence" the app can reuse anywhere MIDI input, output, recording, or hardware filtering is touched. This same pattern could later power a small hover-card on lane MIDI badges: one line for input source, one for output destination, one for record readiness.

2026-07-25 15:31 - Hardware Routing As A Confidence Loop

External MIDI is scary because sound can fail for reasons outside SpaceAge: wrong device, wrong channel, wrong passport, wrong target mode, silent export-only routing, bad cable, or a hardware patch that ignores the message. The UI can reduce that dread by repeating the same route truth every time the user changes one piece. Later, the lane badge could become a tiny "flight plan" display: input, target, output, passport, and timing confidence.

2026-07-25 15:33 - Hot MIDI Actions Need A Black Box Recorder

When SpaceAge sends something to hardware, the receipt should behave like a black box recorder: what was sent, from which lane, to which output, through which Passport, on which channel, and what the user still has to verify with ears and eyes. That same pattern can later power test-note workflows, SysEx recall, external patch editors, Yamaha XG panels, and MIDI timing calibration without making any one panel feel exotic.

2026-07-25 16:05 - A Lane Is A Musical Promise, Not A Storage Explanation

The Instrument Bay migration keeps revealing the same design principle: users should see musical promises, not storage mechanics. Instrument is the promise; private backing slots are the scaffolding. This connects directly to future Scenes and orchestration swaps: if each lane clearly owns an Instrument and a Mixer Channel, then alternate orchestrations can become a high-level creative feature instead of a risky patch/pad reassignment trick.

2026-07-25 16:27 - Import Is Also Onboarding

MIDI import is not just a utility; it is often a user's first proof that SpaceAge understands existing musical work. If import rows say Instrument and MIDI Channel, the user learns the lane-first model immediately. Later, that same import screen can become a graceful bridge into Hardware Passports, SoundFont assignment, Scenes, and orchestration presets without exposing any of the temporary pad-shaped storage underneath.

2026-07-25 16:48 - Availability Is A Better Word Than Readiness

Available Instrument feels like a shelf in the Instrument Bay; Lane-ready Instrument feels like a private engineering category. That distinction matters because SpaceAge is trying to make sophisticated routing feel obvious. The word available can later scale to presets, hardware ports, mixer channels, Quasar packages, and Scenes without dragging users into storage mechanics.

2026-07-25 - Names Are Ownership Boundaries

Separating private Instrument labels from visible Pad labels is more than bookkeeping. It means the composer can trust the lane badge as the truth of the arrangement, while the Pad grid remains a tactile drum/performance surface. This same pattern should guide the final Instrument Bay registry: one object owns sound identity, one object owns timeline role, and one object owns mixer routing. The fewer hidden aliases between them, the less surprising SpaceAge becomes.

2026-07-25 - A Lane Owns The Instrument, But The Instrument Is The Noun

The temptation to say Lane Instrument everywhere is understandable, because the architecture really does attach an Instrument instance to a Lane. But the user-facing grammar should stay cleaner: choose an Instrument for this Lane. That lets Instrument Bay become the future browser/dock, Pads remain the MPC surface, and Mixer Channels remain the output destination. Separating private Instrument labels from visible Pad labels is a small backend step that supports that cleaner mental model.

2026-07-26 - Shared Editors Need Target-Aware Hands

Any editor shared by Pads and lane-owned Instruments must behave like it has target-aware hands. The control can look identical, but the object being touched is different: a visible Pad in Drum Composer, or an Instrument owned by an Arrangement lane. This pattern can later connect to Instrument Bay, SoundFont relocation, Quasar imports, and hardware patch editors: the same button can remain simple if the target resolver is honest.

2026-07-26 - Layer Editors Are Also Instrument Workflows

Sample layers are easy to mistake for Pad-only machinery because the old architecture grew from Pads outward. But Liftoff, Lunacy, Quasar, SoundFonts, and future samplers all need layer/source editing to feel like Instrument work when opened from a lane. The reusable pattern is now clearer: shared editors should ask "what is my active musical target?" before touching storage. That same question can later drive preset save states, file relocation prompts, sample browser metadata, and hardware patch editors without making the user learn separate workflows.

2026-07-26 - Source Is A Bridge Word

Source is useful while SpaceAge is between the old Pad-shaped storage and the final Instrument Bay model. It lets one control describe either a drum pad or a lane-owned Instrument without lying to the user. That word should be temporary but helpful: eventually the cleanest customer-facing language is likely Instrument, Drum Pad, and Mixer Channel, each used only where it is literally true.

2026-07-26 - Labels Should Carry The Same Truth Everywhere

The Effects source chooser can become a quiet confidence builder if it repeats the same identity the Arranger and Mixer already teach: Drum Pad, Instrument, Mixer Channel, MIDI Channel, patch. This connects the shared effects rack to the Instrument Bay model without adding a tutorial. The user sees one object described consistently in multiple rooms of the app, and the mental map gets stronger.

2026-07-26 - The Mixer Is A Receiving Bay

Mixer strips should describe what they receive, not where the old storage model came from. A strip fed by a lane-owned Instrument can simply say Mixer 02 and reveal the lane, patch, and MIDI channel in its tooltip. That same receiving-bay idea can later support user-chosen mixer reassignment, stem rendering, Scenes, and hardware returns because the strip identity is about signal flow rather than Pad ancestry.

2026-07-26 - Tooltips Are Tiny Architecture Diagrams

Hover text is easy to treat as decoration, but in SpaceAge it is often the smallest possible architecture diagram. If Reset Audio says pads only, it teaches the wrong signal model even if the code is correct. The better pattern is short and literal: lane instruments, drum pads, mixer channels, master bus. That language can scale into a future onboarding overlay without rewriting the product vocabulary.

2026-07-26 - A Disabled Selector Can Still Teach

When a Piano Roll clip belongs to an Arrangement lane, the instrument selector should not invite the user to reroute the clip from above. But it should still teach the target: lane name, Instrument, Mixer Channel, MIDI Channel. A disabled receipt is a cleaner teaching object than a second control path, and the same pattern can later help automation popups, hardware routing panels, and clip editors show context without stealing ownership from the lane badge.

2026-07-26 - Fast Gates Protect Creative Flow

The full MIDI recording suite is valuable, but if it takes several minutes before giving feedback, it becomes too blunt for daily iteration. A smaller record-capture core gate protects the musician-facing essentials first: long clips, first-measure capture, and multi-measure timing. The creative link is simple: development rhythm affects product quality. Faster proof loops make it more likely that live-recording bugs get fixed before they become folklore.

2026-07-26 - Live MIDI Should Obey The Lane Like Playback Does

The user does not think, "send this note to a hidden pad-shaped backing slot." The user thinks, "I armed this lane, so my hands should play this lane." That means live monitoring, hardware echo, recording, playback, export, and Automation all need to honor the same lane-owned route truth: Internal, External, or both; chosen output device; forced MIDI channel; chosen Instrument; chosen Mixer Channel. This is a small code path with a large trust footprint.

The useful product connection is that hardware setup can become less mysterious. If a lane badge says External | mioXL | MIDI Channel 05, then playing the controller, recording a take, drawing pitch bend, and sending a test note should all prove that one simple sentence. The lane badge becomes the contract.

2026-07-26 - Two Controllers Should Feel Like A Choice, Not A Trap

Some users will have a USB controller, a DIN controller through an interface, a hardware sequencer, and maybe a wind controller all connected at once. SpaceAge should not treat that as chaos. The armed lane's input assignment should be a simple traffic rule: this lane listens to this source. That same rule can later drive friendlier UI, such as a starred list of recently active controllers, a "wrong controller ignored" diagnostic, and a hardware setup wizard that teaches the user why a lane is or is not responding.

2026-07-28 - A Locked Editor Can Still Build Trust

For vintage hardware, a disabled deep editor is not a failure if it explains itself beautifully. Showing Yamaha XG source-proof requirements inside MIDI Setup turns a limitation into a trust signal: SpaceAge is willing to help route, test, and draft the Hardware Passport now, but it will not pretend to know MU/QY SysEx tables until the official sources and real-device receipts exist. That same pattern can later apply to Roland GS, Korg, Ensoniq, or any hardware family where legal source hygiene and physical proof matter.

2026-07-28 - Source Tables Are Instruments Too

A hardware editor parameter table should be treated like a musical instrument definition: it has identity, range, behavior, authorship/source evidence, and a safe route to sound. If SpaceAge imports Yamaha XG rows as first-class verified definitions instead of hand-coded guesses, the same importer can later serve Roland GS, DX-style SysEx editors, MIDI effect units, and user-shared hardware profiles. The creative connection is that external boxes become part of the Instrument Bay philosophy without sacrificing legal hygiene.

2026-07-28 - Status Should Be A Cockpit, Not A Weather Report

MIDI completion has several meanings: parser/routing backend, customer-facing UI, receipts, real hardware, real files, and live feel. A single percentage collapses those into mush. The better pattern is a compact cockpit line that says exactly which launch blockers remain. This same status design can later help exports, rendering, VST hosting, and Instrument Bay migration: give the user and developer a plain receipt, not an emotional forecast.

The follow-through matters: Health and Protocol Coverage should not paraphrase each other into disagreement. If one panel has receipt-aware launch truth and another only has low-level coverage truth, the user will reasonably suspect the app is confused. Passing the full health snapshot into Protocol Coverage keeps the cockpit honest without duplicating logic.

2026-07-28 - Proof Scripts Are Product Design

A launch proof script is not merely QA paperwork. It is the first draft of how a serious user will learn to trust a feature. Automation has many invisible concepts: ownership, shared patterns, clip-local data, lane-local data, bend range, review-only setup rows, import/export survival. Turning those into a copyable run sheet gives testers a ritual and gives future UI designers a map for onboarding. If the proof script is clear, the feature has a better chance of becoming clear.

2026-07-28 - The Best Receipt Lives Where The Work Happens

Automation proof is most useful inside Automation itself. If the tester has to leave the editor to find the checklist, the proof system becomes another maze. Putting the launch-proof run sheet into the editor's own copy report connects documentation, QA, and workflow: the same panel that creates the movement also explains how to trust it.

2026-07-28 - One Proof, Multiple Doorways

The same Automation launch-proof script is now reachable from Automation and MIDI Health. That matters because different users will think from different directions: one person starts from the feature, another starts from the diagnostic page. The larger design idea is to keep proof blocks model-owned and let the UI expose them wherever they reduce doubt.

2026-07-28 - Full Report Versus Focused Proof

Automation now separates the big context report from the smaller launch-proof run sheet. That distinction feels worth repeating elsewhere: some buttons should answer "what is true about this whole system?", while adjacent buttons answer "what exactly do I test next?" A professional workflow benefits from both, especially when the user is tired and only needs the next reliable action.

2026-07-28 - A Proof Script Should Name Its Instruments

The Automation proof script now names both the human test ritual and the automated guardrails. That is a useful design habit: if a copied proof says what gates protect it, what receipts certify it, and what boundaries remain human-only, the app starts to feel like a serious studio tool rather than a pile of hidden assumptions. This can apply to future export, SoundFont, Instrument Bay, hardware editor, and VST-hosting proofs as well.

2026-07-28 - Proof Should Be Findable From The Cockpit

If a proof script is important enough to gate launch, it should be visible from the diagnostic cockpit, not hidden only inside the feature editor. The new Health AUTO PROOF row is a small example of a broader SpaceAge pattern: every serious workflow should have a clear action surface, a clear receipt surface, and a clear "this sends nothing dangerous" boundary. That same model can help Render, Hardware Passport, SysEx Vault, Quasar capture, and future VST scanning.

2026-07-28 - Copy Doors Are Part Of The Interface

Copy buttons sound boring until the app has serious proof obligations. At that point, COPY QA, COPY CLOSEOUT, COPY LAUNCH, and feature-specific proof buttons become user-facing architecture. They tell the tester or power user what kind of evidence they are holding. The same pattern could become a polished "Session Report" feature later: one button for musical notes, one for technical proof, one for collaborator handoff, and one for release/archive evidence.

2026-07-28 - Percentages Need Captions

A percentage without a denominator is a little machine for creating confusion. MIDI can be backend-strong while launch-proof work remains unfinished, because those are not the same measurement. SpaceAge should make that distinction visible wherever it shows score-like status: backend foundation, visible workflow, real hardware proof, real-file proof, and public launch permission. The design lesson extends beyond MIDI to synth quality, rendering, VST hosting, and export reliability.

2026-07-28 - One Command Should Prove A Spine

When the same proof ritual must be repeated many times, the ritual itself should become a tool. The MIDI closeout fast runner is small, but the larger product idea is important: launch confidence improves when verification is one deliberate action instead of a handful of easy-to-misremember steps. This same pattern can later serve render proof, synth-output proof, VST scan proof, and hardware editor proof.

2026-07-28 - Tools Should Advertise Their Own Rituals

A proof tool is more useful when the product tells the user it exists. By making MIDI Health display the fast gate runner, SpaceAge starts turning engineering rituals into visible trust architecture. The creative connection is broader than MIDI: every serious subsystem can eventually have a visible proof path, a copyable receipt, and one repeatable command behind it.

2026-07-28 - Copied Proof Should Not Lose Context

A diagnostic report is often read away from the app, later, by someone tired or skeptical. If the report says what failed but not what to do next, it becomes archaeology. The MIDI plain-text reports now carry the same finish-line handoff as the cockpit: category, action, route, proof, QA key, next receipt, and fast verification command. That pattern should travel into Render, VST scan, Instrument Bay, Quasar, and hardware editors: every copied proof should include its next move.

2026-07-28 - A Run Order Needs A Compass

A launch run order is useful, but only if it tells the tester where they are standing right now. Adding the current proof handoff to COPY LAUNCH turns the packet from a list into a compass: current blocker, action doorway, proof artifact, QA receipt, and fast gate. That same design should guide any future high-stakes checklist, especially render/export, hardware setup, VST scanning, and release packaging.

2026-07-28 - Reports Should Be A Control Surface Too

A report is not just paperwork if it tells the user where the next safe action lives. By making Next Steps and MIDI Health carry the same proof-door names as the clipboard buttons, the diagnostic text becomes a navigational surface instead of a disconnected summary.

2026-07-28 - One Door, One Name

When a proof button appears in several contexts, its label should stay exact. Calling the same QA doorway COPY QA in one place and COPY QA elsewhere makes the diagnostic layer feel like a maze; exact naming turns it back into signage.

2026-07-28 - A Clipboard Packet Is A Product Contract

If a button copies evidence, the model should own the evidence. UI-built proof packets are easy to let drift because the button silently becomes a second source of truth. Moving COPY QA into MidiProjectHealthSummary gives the app one contract for the closeout QA packet, and the interface merely exposes it. This same rule should apply later to render receipts, hardware setup reports, Quasar packages, VST scan results, and release-build summaries.

2026-07-28 - Copy Feedback Is Part Of Trust

When a button copies evidence, the user needs two things immediately: an honest description before the click and a clear receipt after the click. Updating Protocol COPY QA from “checklist” to “QA session packet” avoids underselling what is actually copied, while COPIED feedback closes the loop. This tiny interaction pattern should apply to every future proof/export/report surface.

2026-07-28 - Ledger Buttons Should Not Be Tiny Report Writers

A ledger copy button feels harmless, but if it builds its own report text in the editor it becomes another little source of truth. Moving COPY LEDGER behind MidiProjectHealthSummary keeps the cockpit honest: buttons expose model-owned facts, and the model decides what the evidence packet contains. This same discipline should guide future export ledgers, crash reports, VST scan reports, hardware passport receipts, and release checklists.

2026-07-29 - Compact Labels Need Deep Tooltips

Sometimes the interface needs a short label because pixels are real. That is fine as long as the shortened label does not become the source of truth. The QA receipt button now keeps its compact surface while borrowing its deeper explanation from the receipt action model. This is a useful pattern for crowded SpaceAge controls: short visible language, model-owned tooltip, copyable receipt, and test coverage behind the scenes.

2026-07-29 - Public Claims Need Live Signage

A proof copy button is safest when it says the current boundary before the click. COPY CLAIM now carries the live safe-public-claim status in its tooltip, which turns a static report button into a small piece of launch discipline. That pattern can also guide future About-page claims, Kickstarter copy, export confidence badges, VST-hosting readiness, and hardware editor marketing language.

2026-07-29 02:54 - One Proof Door Beats Nine Partial Hints

When a complex feature has many valid status summaries, the user should not have to decide which one matters next. The next-proof packet turns MIDI closeout into a single callable idea: open this door, run this proof, save this receipt. The same pattern can later help export, automation, hardware editors, and sample-library QA.

2026-07-29 03:01 - Proof Packets As Workflow Objects

The NEXT PROOF packet is a small product-design pattern: whenever SpaceAge asks for real-world validation, it should carry the proof target and public-claim boundary in one object. That prevents scattered truth and keeps QA, docs, and UI speaking with one voice.

2026-07-29 03:13:25 -05:00 - Receipts as UX guardrails

• The MIDI closeout flow should behave like a launch checklist: once a proof receipt is saved, every visible instruction must advance together. This same pattern can later protect render validation, hardware setup, and preset export/import workflows from stale guidance.

2026-07-29 03:29:01 -05:00 - Trust signals for launch proof

• A tiny consistency flag can prevent a large user-confidence failure: if a proof card, receipt form, and copied report disagree, the app should know before Shane or a beta tester has to discover it by reading three places manually.

2026-07-29 03:38:22 -05:00 - Proof requirements as workflow copy

• When a validation task requires hardware, a real file, or live-performance feel, the UI should say that directly. This same pattern can later help render/export, SoundFont relocation, and hardware editor workflows tell users exactly what physical-world evidence is still missing.

2026-07-29 - Proof text as workflow design

• Treat MIDI closeout evidence like a guided workflow, not a spreadsheet: the app should tell the tester which surface to open, which bucket is being proven, what counts as PASS, and when a simulator is not enough. This same pattern can later power user-facing hardware setup wizards and release-candidate checklists.

2026-07-29 - Evidence as a user experience

• The MIDI proof checklist pattern should influence future hardware workflows: every risky or evidence-dependent feature should have a compact action card, a pasteable checklist, a PASS threshold, and an explicit boundary for what the app is not claiming yet.

2026-07-29 - One card, one truth

• For complex proof workflows, prefer one authoritative card object over scattered status strings. That same pattern should guide Instrument Bay, hardware setup, and future export/render diagnostics: the user sees a clear state, a next action, and a copyable proof trail from the same payload.

2026-07-29 - Readiness labels beat percentages

• A percentage alone keeps causing confusion. Structured readiness labels plus explicit blockers are more honest: users and testers need to know whether they are blocked by missing receipts, hardware proof, real-file proof, live feel, or public-claim boundaries.

2026-07-29 - Badges for proof types

• Small proof-type badges are a better cockpit language than another paragraph. Hardware, real file, and live-performance badges can eventually guide the tester through the exact remaining evidence without making the MIDI page feel like a compliance spreadsheet.

2026-07-29 - Proof badges as honesty UI

• The MIDI cockpit proof badges should become a small honesty dashboard: not scary, not legalistic, just three compact lights showing whether hardware, real project files, and live performance feel have been proven.
• This pattern can later apply to other launch-critical systems: export, project recovery, plugin hosting, and hardware editors could each show "software ready / human proof pending" without burying the truth in docs.

2026-07-29 - Proof rituals as product UX

• Turning proof work into checklist rows is more than QA plumbing: it hints at a product pattern where difficult setup flows become calm guided rituals.
• The same structure can later serve MIDI hardware setup, XG editor onboarding, sample-library relinking, export validation, and plugin scan recovery.

2026-07-29 - Checklists that move the user

• A checklist that only informs still leaves the user hunting for the next button. Adding doorway and button metadata turns the MIDI proof checklist into a guided action surface.
• This pattern should be reused for hardware setup, SoundFont relinking, missing sample recovery, export validation, and eventually SpaceAge's first-run onboarding.

2026-07-29 - Dashboard before widgets

• A display-ready cockpit dashboard gives SpaceAge a graceful bridge between raw backend proof data and a fully designed UI. The editor can first show clear lines, then later upgrade those lines into badges, cards, and buttons without changing the proof model.

2026-07-29 - One dashboard, many surfaces

When a proof system exists in both structured data and prose, drift becomes a product risk. The better pattern is one canonical cockpit payload that feeds badges, summary panels, clipboard text, and old-fashioned plain reports. This is boring in the best way: the user sees the same truth everywhere, and future UI polish can become a presentation problem rather than a logic rewrite.

2026-07-29 - Proof checklists as guided performance

A MIDI proof step should feel like a tiny guided performance, not a scavenger hunt. Turning the target, script, evidence, and save-result ritual into reusable lines means the app can teach the tester what to do while also teaching us where the UI still needs a proper button, panel, or receipt. This same pattern could later serve render tests, hardware setup, SoundFont relocation, and project recovery.

2026-07-29 - MIDI Launch Proof as a Single UI Object

• The MIDI proof cockpit should behave like an airlock checklist: dashboard first, then proof checklist, then proof cards, then one primary action. Exposing midiLaunchValidationUiHandoff lets the GUI render that flow consistently and keeps customer-facing MIDI readiness from being scattered across unrelated report strings.
• The primary action can intentionally be stronger than a checklist row. Example: the checklist can say OPEN PROOF, while the main button says COMPLETE LAUNCH PROOF, teaching the user that opening the surface and completing the proof are related but not identical actions.

2026-07-29 05:59 - Creative Thinking: MIDI Proof As A Guided Control Surface

The MIDI launch validation work can become a compact, trustworthy Settings panel rather than a developer-only report. By exposing a fixed uiSections order, SpaceAge can present MIDI readiness like a guided preflight checklist: what is ready, what proof remains, what button to press next, and what marketing claims are still locked. This same pattern can later be reused for hardware setup wizards, XG editor readiness, sample-library relink workflows, and render/export preflight checks.

2026-07-29 06:09 - Creative Thinking: Public MIDI Claim Gate

The MIDI proof system should feel like a cockpit warning lamp, not a buried engineering note. The new claim-gate handoff lets the eventual MIDI Health page tell the user, tester, or marketer exactly what can be said safely: proof still pending, software proof pass but hardware proof pending, MIDI 1.0-only claim, or evidence-backed. This same pattern can become a broader SpaceAge release-safety design: exports, cloud/sync, hardware editors, and future plugin hosting can each expose an honest claim gate before we call a feature finished.

2026-07-29 06:22 - Creative Thinking: Proof Progress As A Visible Trust Meter

The MIDI proof handoff is becoming a customer-facing trust meter: progress, next action, proof badges, and public-claim lock state all have dedicated UI contracts now. This can become the pattern for other risky workflows: render/export progress, project repair, SoundFont relinking, hardware setup, and future plugin-hosting validation can each show a simple progress card plus proof badges rather than hiding important status inside logs.

2026-07-29 06:31 - Creative Thinking: Proof Action As A Single Card

The MIDI Health page should not make the user hunt for the next move. The new action-panel handoff lets the UI render one authoritative action card: where to go, what to press, what evidence is required, and what script to follow. This pattern can later become SpaceAge's general guided-workflow surface for hardware setup, XG editor device tests, export validation, and project repair.

2026-07-29 - Hardware Proof Needs Its Own Instrument Panel

The launch proof cockpit can now say PASS while the product still should not make public hardware claims. That distinction is too important to leave buried in prose. A dedicated hardware proof gate gives the future MIDI Health page a small, clear instrument panel: where to go, what remains, how many proof steps are done, and why public wording is still locked.

The creative connection is trust choreography. Hardware Passport, SysEx Vault, MIDI Timing, TEST BEND, MIDI file round-trip, and public release wording are not separate chores; they are one ritual for proving external gear honestly. By making that ritual a structured UI card, SpaceAge can feel calm and professional even when the answer is still, "not proven yet."

2026-07-29 - Beta Readiness As A Project Cockpit

Turning the beta roadblocks into a serialized health gate gives SpaceAge a useful future cockpit pattern: docs can remain reflective, while the app exposes the same blocker logic as actionable cards. This same pattern can later drive release checklists, instrument QA sweeps, preset-pack readiness, school-license onboarding, and hardware-editor unlock workflows without inventing a new checklist style each time.

2026-07-29 - Instrument QA As A Product Cockpit

Instrument audio QA should become more than a developer checklist. The same rows can later power a pre-beta dashboard where SpaceAge shows which engines have been auditioned in the current release candidate, which asset-backed engines need fixture files, and which instruments are still waiting for human ears.

Creative connection: this can eventually dovetail with the Instrument Bay. Each Instrument Bay card could show a tiny readiness badge: Factory QA, Needs Asset, CPU Watch, or Chord-Safe Proof. That turns boring QA into user-facing confidence without making the interface feel technical.

2026-07-29 - Instrument Bay Proof As A Design Compass

The lane-independence checklist can become a practical design compass rather than only test data. If a future UI action touches sound identity, it should be classifiable as one of these rows: create, copy, variant, replace, route, record, load resource, or edit language. If it cannot be classified, that is a warning that the feature may be sneaking the old Pad-proxy workflow back into the app.

Creative connection: once the final Instrument registry exists, Instrument Bay cards can show the same facts visually: owned by Lane 4, routed to Mixer 12, MIDI Channel 05, Chord-Safe, CPU Watch, Asset Missing, or Ready. That gives users clarity without exposing private storage mechanics.

2026-07-29 - Visual QA As A Product Promise

The UI readability checklist is more than a bug list. It connects screenshots, beta readiness, and support communication into one visible contract: SpaceAge should feel intentionally designed at the exact places where the user makes musical decisions. A clipped label in a synth, a cramped MIDI page, or a hidden automation control is not cosmetic if it makes the user doubt what the app is doing.

A useful extension later would be a small internal QA mode that walks through every surface in this checklist, opens the relevant panels, and captures a screenshot set for review. That would turn human visual testing into a repeatable ritual instead of a scavenger hunt.

2026-07-29 - Arrangement UX As Trust Infrastructure

Arrangement and automation are not just features; they are the user's mental map of the song. If a loop starts somewhere unexpected, automation continues after it looks deleted, or a long clip preview shows only half the content, the user stops trusting the map. The checklist turns those experiences into named obligations.

The creative connection is that the same checklist can later drive an in-app guided beta tour: SpaceAge could ask the tester to create a loop, draw automation, move a chorus, record four measures, and render the result. That would turn QA into a small composition ritual instead of a sterile test script.

2026-07-29 - Save/Load As Emotional Safety

Save/load is the least glamorous feature until it fails; then it becomes the whole product. Treating it as a beta-readiness checklist reframes project persistence as emotional safety for the composer. A musician should feel that SpaceAge remembers the room exactly as they left it: tempo, instruments, mixer routes, automation, dirty patches, and assets.

A later creative extension could be a Project Memory report: after loading, SpaceAge could quietly say what it restored and what needs attention, such as missing SoundFonts or unresolved samples. That would make recovery feel like helpful guidance instead of forensic debugging.

2026-07-29 - Render As The Promise Leaving The Room

Rendering is the moment SpaceAge hands the song to the outside world. The checklist connects Arrangement truth, Mixer routing, automation, effects, asset-backed instruments, MIDI export, and progress feedback into a single product promise: what the user sees and hears inside SpaceAge is what leaves the app.

A later useful feature would be an Export Receipt: after render, SpaceAge could show duration, range, included lanes, active effects, automation count, stem count, and file path. That would make exporting feel professional and calm rather than mysterious.

2026-07-29 - Release Hygiene As Brand Trust

Packaging and legal work can feel far away from music, but it is part of the emotional frame of a product. A clean installer, consistent naming, honest claims, and a clear license story make SpaceAge feel like a real instrument rather than a prototype accidentally placed in public.

A useful future feature would be a Release Cockpit page for us, not for customers, showing build version, third-party ledger status, asset status, proof receipts, and known launch blockers. That keeps the project calm as it grows.

2026-07-30 - A Sound Is Not A Mix

Preset portability becomes much more useful when a sound remains a sound and the Mixer remains the room it is playing through. The new Pad Vault boundary means the same saved kick, sampler setup, or synth patch can be auditioned through different channel-strip treatments without silently carrying yesterday's ambience, pan, compression, or EQ into today's arrangement.

This rule can unify future preset formats: Instrument Bay records describe the generator and its assets; Lane records describe composition ownership and routing; Mixer records describe gain, space, dynamics, and tone after the source. Keeping those three identities separate makes future Scenes, orchestration swaps, stem rendering, and collaboration packages far easier to reason about.

2026-07-30 - Sixty-Four Pads Need Their Own Airlock

The overlap between customer-facing Pads 17-64 and private lane-Instrument backing slots is more than a storage bug; it is a broken product metaphor. Drum Composer should own a stable 64-pad universe, while Instrument Bay should own an independent source universe. A hard boundary between them lets a future conversion dialog intentionally translate a Pad sound into an Instrument or vice versa, instead of allowing accidental aliasing to perform an invisible conversion.

2026-07-30 - Three Domains, One Understandable Signal Path

The 64 Drum sources, 16 lane-owned Instrument sources, and 64 Mixer channels are now explicit domains rather than one overloaded index. That creates a useful product grammar: a musician creates sound at a source, owns composition in a Lane, and chooses where that sound arrives in the Mixer. Future Instrument Bay cards can show those three facts without exposing storage numbers: Redshift / Harmony / Mixer 12.

Compact Instrument Undo connects naturally to orchestration Scenes. Because an Instrument replacement can now be captured independently from the whole project, a future Scene can store a set of lane-Instrument snapshots and Mixer destinations without duplicating note data. The same mechanism can support quick A/B orchestration, safe preset auditions, and a return to previous Instrument action.

The hard cardinality types are also a design aid. New features should declare whether they operate on Drum sources, Instrument sources, Arrangement lanes, or Mixer channels. A feature that cannot answer that question is likely rebuilding the old Pad-proxy confusion.

2026-07-30 - Identity Without Index Arithmetic

A private Instrument's source slot and its Mixer channel are independent identities. Resolving that relationship through the owning Lane, instead of calculating source + 1, makes routing visible, intentional, and reassignable. This same relationship can power Instrument Bay summaries, stem names, hardware destinations, and future orchestration Scenes without exposing internal storage numbers.

Load-time repair and Undo also belong to different moments in the product. Repair restores a valid project invariant and must remain invisible to the musician; Undo records intentional creative choices. Keeping those paths separate prevents a user's first Undo after loading from mysteriously changing an Instrument assignment.

2026-07-30 - One Clean-Instrument Definition Enables Safer Auditioning

Centralizing fresh Instrument reset does more than remove duplicated cleanup code. It creates a reusable boundary for future Instrument Bay actions such as New Instrument, safe preset audition, orchestration Scene swaps, and temporary A/B sound design. Each action can replace the sound identity without touching the lane's notes, Mixer destination, or channel processing.

The hostile-routing proof can also become a foundation for flexible re-orchestration. Because source identity and Mixer destination are demonstrably independent, a future Scene may swap Redshift for Quasar while keeping the same fader, pan, automation, effects, and stem destination. That is the musical benefit of the architectural cleanup: changing the player does not rebuild the room.

2026-07-30 - One Route Makes Preview Trustworthy

Auditioning a patch, drawing a Piano Roll note, previewing a chord, and playing the Arrangement should sound through the same channel. A shared source-to-Mixer resolver connects those experiences, which means future Instrument Bay preview cards can audition candidate sounds through the lane's actual automation and channel processing without committing the replacement first.

That same route can later support a deliberate preview dry option: the default preview remains honest to the song, while a temporary dry audition can isolate the Instrument for sound design. The distinction becomes an explicit musical choice rather than an accidental consequence of old source-index arithmetic.

2026-07-30 - A Preset Changes The Player, Not The Mixing Desk

Separating patch state from Mixer state turns preset browsing into a dependable orchestration tool. A composer can try a Redshift bass, Lunacy texture, or SoundFont instrument while the lane keeps its established fader, pan, EQ, automation, and effect relationships. This same contract is the foundation for future SpaceAge Scenes: swap the players while preserving the arrangement and the room.

Strict reviewed MIDI destinations also make import receipts meaningful. What the review panel says is what the project creates. If the available Instrument Bay changes before commit, asking for a fresh review is musically safer than improvising a different routing decision behind the user's back.

2026-07-30 - Import Review Should Only Offer Real Destinations

A reviewed MIDI import is already a small orchestration decision: each source channel becomes a player in the project. Its Instrument destination menu should therefore behave like an honest seating chart. Occupied Arrangement instruments are omitted, unclaimed Instrument slots remain available, and two selected source channels cannot claim the same seat. This connects the MIDI importer directly to the lane-owned Instrument Bay contract and prevents a technically valid-looking choice from becoming a silent fallback or an unexpected reroute during commit.

2026-07-30 - The Player Shapes The Sound; The Mixer Places It

Removing the shared EQ page from the Synth Engine is more than reclaiming a tab. It teaches a stable mental model: Instrument controls answer "what is this sound?" while Mixer controls answer "where does it sit in the song?" Engine filters and timbral drive remain part of the player's identity; channel EQ, fader, pan, automation, and sends remain part of the room.

That separation makes future orchestration Scenes, patch auditioning, stem rendering, and Instrument replacement easier to trust. A musician can exchange the player without accidentally moving the chair, rewriting the acoustics, or erasing the mix decisions already attached to the lane.

2026-07-30 - A Feature Map Can Become Product Navigation

The bird's-eye-to-worm's-eye feature outline is more than a marketing inventory. Its hierarchy mirrors the way SpaceAge can teach itself: begin with the song workflow, enter a workspace, choose a musical object, and reveal detailed controls only when they matter. The same structure can later drive the manual, searchable in-app help, onboarding, tooltips, feature comparison tables, and a first-run guided tour.

The outline also exposes a useful release discipline. Broad product capabilities may be implemented while their final proof remains incomplete. Keeping the feature and its certification boundary together allows marketing language to grow progressively: internal implementation, private-beta capability, hardware-proven workflow, and finally an unconditional public claim.

2026-07-30 - Asset Repair Should Restore The Music, Not Merely The Path

An external multisample instrument is part sound and part promise. Saving its folder path is insufficient; SpaceAge must notice when the package has moved, explain what is absent, accept a replacement, and prove that the Instrument is playable again through its owning Lane and Mixer route. The new synthetic Quasar regression joins those steps into one contract: package load, finite audio, voice retirement, project round trip, missing-asset receipt, relink, and restored audio.

This contract can become the common repair language for SoundFonts, Quasar packages, samples, loop tracks, imported wavetables, and future spectral sources. A later Project Memory panel could list each repaired asset alongside its Lane and Instrument, turning a stressful missing-file problem into a calm checklist of restored players. The test fixture remains generated from first principles so automated proof does not quietly depend on Shane's private sample library or add a licensing burden.

2026-07-30 - A Tiny Standards-valid Instrument Can Protect A Huge Library

The SoundFont regression does not need a commercial orchestral bank to prove the dangerous boundaries. A generated one-preset SF2 can exercise the same parser, private Instrument ownership, Mixer route, voice lifecycle, project serialization, missing-file report, and relink path used by a multi-gigabyte General MIDI collection. This separates format correctness from musical-content QA and keeps the automated suite fast, reproducible, and legally clean.

The same idea can become a general fixture workshop for SpaceAge. Small generated files can certify future wavetable, MIDI, SysEx, Quasar, archive, and spectral formats, while larger human-owned assets remain listening and performance tests. That gives us two honest layers of confidence: deterministic engineering proof and musician-in-the-chair product proof.

2026-07-30 - A Chord Is A Better CPU Question Than A Benchmark Scream

Musicians do not experience CPU as an abstract loop count. They experience it when one lush chord makes the transport crackle, a pad patch steals the rest of the arrangement's headroom, or a sampler hesitates under ordinary polyphony. The new release gate therefore asks a musical question: can a lane-owned Instrument play an eight-note chord, produce finite audible output, retire every voice, and still leave most of the real-time window available for the song around it?

This measurement can later become a factory-preset design tool. Presets could carry an internal cost class such as Light, Standard, or Cinematic, derived from the same reproducible workload rather than guesswork. Instrument Bay could then warn about an unusually expensive orchestration, offer an Eco quality switch, or recommend Quasar capture/freeze while preserving the original editable Instrument. Performance evidence becomes a creative workflow rather than merely a release spreadsheet.

2026-07-30 - The Whole Band Is The Real Instrument

An Instrument can pass a solo benchmark while the song around it still fails. The new Arrangement workload connects the previously separate proofs: drum synthesis, five independent lane-owned Instruments, Mixer routing, lane automation, shared Halostar/EchoRay/chorus returns, loop timing, finite output, and voice retirement all run inside one measured musical scene. This is closer to what a composer actually asks of SpaceAge than either an isolated oscillator or a synthetic stress scream.

That test immediately found something creatively useful: Liftoff's temporary additive oscillator was spending its time rebuilding up to 48 harmonics for every oscillator, unison voice, sample, and note. Replacing that realtime resynthesis with prepared band-limited wavetable mip levels did more than make a test green. It bought back enough headroom for richer orchestration while preserving table position, spectral warp, user-wave import, and unison. The same principle can guide future Instruments: expensive analysis belongs in preparation or import; the audio thread should mostly read, interpolate, and express.

This evidence could later feed an Arrangement heat map or Instrument Bay cost badge, but it should remain musician-facing rather than diagnostic clutter. A quiet warning such as Cinematic CPU or a one-click Capture to Quasar action would turn performance knowledge into a creative choice instead of a punishment.

2026-07-30 - The Return Must Earn Its Place

An enabled effect is not proof that an effect works. Whole-song output can remain audible through the dry path while a shared return is disconnected, silent, or ignoring its controls. SpaceAge's release evidence should therefore treat each shared effect as a musical transformation with three obligations: it changes the source, it produces its expected time-domain tail, and its defining control changes the result.

This connects DSP verification to the Mixer design language. A return card that visibly says Halostar, Reverb, or EchoRay should have a matching automated identity test, so customer-facing naming, routing, and audible behavior cannot quietly diverge. The same pattern can later cover modulation returns, the master limiter, and future Orbit effects without relying on one enormous end-to-end test to diagnose every failure.

2026-07-30 - Spend CPU Only Where Sound Lives

A shared effect can support many Mixer channels without paying the full processing cost for every theoretical channel on every sample. EchoRay now builds a bounded active-channel list once per audio block from channels with a nonzero send, a living delay tail, loop input, or intentional noise. Its musical memory remains independent per channel, but dormant histories no longer occupy the hottest inner loop.

This idea can become a general return-rack policy. Halostar, future Orbit processors, per-lane analyzers, and motion visualizers should all distinguish between being available and being active. The user can keep a rich routing environment ready without SpaceAge charging the CPU as though every cable is carrying sound.

2026-07-30 - Focused Gates Diagnose, Broad Gates Reunite

Focused tests are how SpaceAge finds a defect quickly; the complete suite is how it proves that the repair still belongs to the whole instrument. After EchoRay's scheduler was optimized and its musical tail was protected, the complete monolithic Release test exercised that code beside old Pad workflows, lane-owned Instruments, hardware MIDI queues, automation, import/export, Mixer navigation, sample repair, and final WAV rendering.

The two layers should remain permanent release infrastructure. A focused gate answers "what broke?" A broad gate answers "did the repair quietly break something far away?" Later, the same pairing can support VST hosting, Scenes, Motion Clips, XG hardware editors, and any feature whose local correctness is not enough to guarantee a trustworthy session.

The first run justified the stricter contract immediately. Halostar and Reverb behaved correctly, but EchoRay put its per-channel delay line to sleep before a longer synchronized tap could emerge from a short note. Its activity horizon now spans the supported musical delay window, and the regression explicitly compares a half-note repeat with a sixteenth-note alternate. This is a useful connection between tempo-aware workflow and DSP lifecycle: musical time, not an arbitrary sample-by-sample decay constant, determines how long the return must remain alive.

2026-07-30 - Blank Means The Previous Session Has Truly Left

A fresh project is not merely an empty drawing surface. It is a promise that the prior session's performers, hardware instructions, missing files, modulation, and audio-thread memories no longer influence the next idea. Treating Blank Project as a hard lifecycle boundary connects user trust, hearing safety, external MIDI safety, recovery policy, and deterministic testing in one place.

That boundary also sharpens the meaning of recovery. A SoundFont or Quasar package can be the heart of a sound-design session even before the first note is drawn, so asset references count as recoverable creative state. Conversely, SpaceAge's canonical 64-step Section and starter Drum clip are scaffolding, not authorship. Distinguishing those cases lets autosave protect real work without presenting phantom recovery files for untouched projects.

2026-07-30 - A Failed Load Should Be Boring

The best damaged-project experience is deliberately uneventful: SpaceAge refuses the file, explains the problem, and the song already open remains exactly where the musician left it. Format identity, structural validation, and atomic replacement turn persistence from a hopeful file operation into a transaction with a clear boundary.

That same boundary can later power a Project Inspector before loading. SpaceAge could report format version, song length, lane count, required assets, missing-file risk, and recovery age without touching the current session. The infrastructure built for safe rejection therefore connects naturally to safer archive import, previous-version browsing, cloud synchronization, and a future Load Previous Versions dialog.

2026-07-30 - Recovery Is A Curated Timeline, Not A Junk Drawer

A recovery list should communicate confidence: these are real SpaceAge snapshots, they contain meaningful work, and the newest useful choices have been preserved. Treating every file with the same extension as disposable retention inventory violates that promise. The recovery system now recognizes its own generated names, validates project structure, checks for creative content, and leaves unrelated projects alone.

That policy creates a clean foundation for a future visual recovery timeline. Snapshots could show age, lane count, song length, missing assets, and a compact Arrangement preview before the musician loads anything. The same preflight mechanism can support Last Project, Load Previous Versions, archive inspection, and cloud history without risking the session already open. File safety becomes part of workflow clarity rather than an invisible maintenance concern.

2026-07-30 - A Portable Project Is A Promise, Not A ZIP Button

When a musician archives a SpaceAge song, the implied promise is larger than compression: the music will reopen somewhere else, its private source paths will not leak, its sample-based Instruments will still speak, and a damaged package will not harm the song already open. Staging, validation, placeholder remapping, atomic replacement, and hostile-input inspection turn that promise into one transactional boundary.

This architecture can grow into a useful Project Passport. Before import, SpaceAge could show song name, format version, lane count, asset count, package size, expected expanded size, missing or unusual content, and whether the archive passed inspection. After import, the same receipt could list where assets were restored and which Instruments were verified audible. That connects archive safety to the existing MIDI Health, Hardware Passport, Render receipt, and future QA cockpit language.

The missing-asset identity guard has a broader application. Any async chooser or dialog that outlives the state it displayed should commit against a stable identity and expected old value, not an array index. The same rule belongs in Instrument replacement, preset deletion, automation editing, hardware-profile selection, and future VST repair workflows.

2026-07-31 - A Port Should Be The Same Spacecraft, Not A Replica

Planning a Raspberry Pi version exposes portability boundaries that improve the Windows product too. Audio/MIDI backends, filesystem dialogs, shell actions, preferences, and packaging should meet the musical engine through narrow platform adapters. That keeps project identity, Instrument behavior, timing, and Mixer semantics stable while the operating system changes underneath them.

The same discipline could eventually make SpaceAge a dedicated composition appliance: a small ARM computer, audio interface, controller, and focused display. That should remain one product and one project format, with performance capabilities stated from measured musical workloads rather than hardware enthusiasm.

2026-07-31 - A Beta Limit Can Be Honest Without Becoming Permanent

The current 16-lane Arrangement ceiling and 16 private Instrument sources fit exactly. Treating a dynamic Instrument registry as mandatory before beta would spend architectural risk without increasing the number of songs the present Arrangement can express. Declaring the limit clearly lets beta testing concentrate on trust: every lane must remain independent, routable, recoverable, and audibly correct.

Later, removing the lane ceiling and introducing a dynamic registry can happen together as one coherent scalability feature. That future registry can also become the common home for VST instances, hardware definitions, reusable orchestration Scenes, and Instrument-level resource reporting rather than being built prematurely as an isolated storage rewrite.

2026-07-31 - One Gate, Two Kinds Of Truth

SpaceAge already knew the difference between automated proof and human proof, but that knowledge was trapped inside the MIDI health model. The Human Beta QA Matrix now turns the same categories into a practical listening and workflow run. This keeps engineering truth and product-design truth connected: a regression can prove that an event was serialized correctly, while a musician must still prove that the result feels immediate, comprehensible, and trustworthy.

The 16-lane Instrument ceiling is also useful design information rather than merely a technical limit. Beta can present it honestly as a bounded composition environment with complete lane independence. If later users demonstrate a real need for more lanes, an unbounded registry can be introduced as a deliberate scale expansion rather than rushed into the beta path.

Packaging Is Part Of The Instrument

The release archive is the user's first physical encounter with SpaceAge, so packaging should behave like a carefully labeled hardware box rather than an accidental folder dump. Keeping identity, notices, binaries, and documentation together creates a reusable foundation for future themes, instrument packs, educational editions, and platform ports without weakening the core product's provenance.

2026-07-31 - Exports Are Musical Contracts

An export is not merely a file writer. It is a promise that SpaceAge's musical time, routing, setup state, and project identity survive outside the live session. Variable-tempo WAV duration now follows the same Arrangement slot multipliers as playback, MIDI setup messages travel with their lane while unsafe SysEx remains guarded, and output files replace earlier work only after the staged result proves readable and complete.

The checksummed MIDI stem package connects this contract to collaboration: each lane can leave SpaceAge as an independently verifiable musical part while the complete arrangement remains alongside it. Audio stems are a separate future feature rather than a name applied loosely to MIDI packages. The same receipt architecture can later serve Scenes, portable projects, Quasar captures, XG hardware exchanges, and render history without making the composer guess what was actually preserved.

2026-07-31 - Comments Mark Contracts; Whiteboards Mark Journeys

This documentation task connects two different maintenance tools without making either one carry the whole codebase. Source comments should mark the dangerous architectural edge nearest the code: ownership, thread, timing unit, stable identity, transaction behavior, hardware safety, or proof gate. The Whiteboard should show how a musician's intent crosses those edges from the interface to durable state, realtime playback, files, and external devices.

That pairing serves human and AI maintainers in the same way. A maintainer begins with the user journey, follows the named source anchors, reads a short contract at the boundary, and verifies the claim through a focused regression gate. Historical progress journals remain evidence, while the commenting guide and Whiteboard stay compact statements of current truth.

The independent audits also exposed a useful discipline: documentation must not turn intended architecture into a false claim about current code. The snapshot, local-automation publication, mixed-timebase automation, synchronous file-I/O, undo, and long-operation gaps are therefore recorded as implementation blockers. Fixes should come first; source comments should then preserve the behavior proven by those fixes.

2026-07-31 - Comments Must Describe Proven Boundaries

The first production-comment tranche demonstrates a useful maintenance rule: a comment may describe an intended contract and still honestly name the migration work that prevents the current implementation from satisfying it. That is more valuable than either silence or false reassurance. Snapshot publication, automation timebases, hardware generations, stable logical identities, and project staging now have searchable boundaries, while known gaps remain visibly marked for repair.

This also connects directly to beta work. The best comments identify where a user-facing promise can fail and point maintainers toward a focused proof. As those blockers are fixed, their migration warnings should be replaced with concise permanent contracts rather than allowed to become stale archaeology.

2026-07-31 - A Hardware Confirmation Must Describe The Exact Future

The sync-policy repair connects four surfaces that could otherwise drift apart: the Hardware Passport controls, the confirmation report, the persisted policy, and realtime MIDI Clock/transport output. The values shown in a safety preview are now captured as one proposal and committed unchanged after confirmation. Receive-clock roles are included because incoming timing can affect the session even when SpaceAge sends nothing.

This same proposal-preview-commit pattern should be reused for XG editors, SysEx restore, hardware Scenes, program recall, and any future AI-assisted hardware setup. A musician should never confirm one description while the app later rereads mutable controls and performs something else.

2026-07-31 - One Visible Automation Edit, One Audible Generation

Automation editing, undo, copy/paste, project loading, live playback, and MIDI export are different views of the same musical intent. Treating the immutable audio snapshot as a published generation means a drawn change becomes audible as one atomic event instead of letting the interface and engine disagree. The same principle can later support Motion Clips, modulation previews, and hardware-editor transactions: prepare a complete generation, then publish it once.

The three automation owners intentionally use two clocks. Shared Pattern and Clip Local events travel with source material; Lane Local events belong to the song timeline. Keeping those clocks explicit lets a chorus be moved or repeated without corrupting lane-wide automation, while an orchestration or mixer gesture can remain fixed to the Arrangement. Future transformations should declare which clock they consume before any event lists are combined.

2026-07-31 - Import As A Published Musical Decision

A MIDI import should become audible like one edit, not like a fast series of erases and inserts. Parsing first and publishing one completed Pattern generation lets the user, the undo stack, and the audio thread agree on when the imported musical decision happened.

Stable lane and clip identities are the companion rule. A property panel may change routing, timing, names, or sound assignment, but it must not quietly turn the edited object into a different automation owner. New identity belongs to creation, duplication, or explicit replacement workflows.

The SysEx Vault remains intentionally separate from Pattern playback state. Quarantining hardware data can succeed without replacing musical content, but this is not a claim that the Pattern and vault share one cross-lock transaction.

2026-07-31 - Delete One Identity, Publish One Reality

A Hardware Profile referenced by a lane is shared project identity, not a detached registry row. Deleting it must make the registry, lane editor, realtime snapshot, readiness policy, and next save agree at one publication boundary. The clock-output refresh belongs after that boundary because external device work is an effect of the committed state, not part of the state mutation itself.

Live MIDI routing has an equally important split identity. The input channel owns the musician's gesture and therefore owns sustain, expression, note release, and channel-mode messages. The lane output channel owns where the resulting sound or outbound MIDI is addressed. A Channel 4 controller routed to Channel 15 should still release when Channel 4 sends sustain-off.

Together these repairs reinforce a useful product rule: routing may transform destination, but it must not rewrite ownership.

2026-07-31 - A Restore Starts A New Recording Reality

Recording workers finish bookkeeping after the performance callback, but undo and project restore can replace the musical world before those workers arrive. A monotonic recording epoch gives each queued note, drum hit, and expression event a statement of origin: commit only if this is still the world that captured me.

Restore therefore cancels recording directly instead of manufacturing note-offs. Held-note bookkeeping is retired with the epoch while the restored Pattern remains exactly the saved or undo-selected decision. Any older worker can still wake safely, but it no longer has authority to publish.

Long-form Arrangement recording needs the same respect for context. Quantization belongs to the Pattern horizon that received the take, not the 64-step drum-grid constant. Timing correction should tighten a performance without transporting bar 49 back into bar 16.

2026-07-31 - Finish The Block, Preserve The Passport Evidence

A count-in boundary is a position inside an audio callback, not permission to discard the rest of that callback. When the downbeat arrives at sample 6000 of an 8192-sample block, the scheduler should transfer authority from count-in to normal playback at that offset and let step zero occupy the remaining 2192 samples. The same offset can anchor recording and the metronome without inventing a second timebase.

Hardware Passport deletion has a different boundary: customer intent may remove device identity and lane routing, but attached SysEx is independent evidence. A single editor helper owns confirmation outcome, checkpoint, mutation, and refresh. If SysEx is attached, deletion stops and explains the explicit Vault action required. Safety here means preserving evidence, not guessing that detachment was intended.

2026-07-31 - Recording Reads Are Published, Recording Writes Are Queued

Live capture should read one coherent immutable generation, never reconstruct routing by locking mutable project state inside the callback. Pattern horizon, lane ownership, and clip mapping travel together; note, drum, and expression mutations remain bounded queue work. Record-arm is the inverse transaction: prove that a destination exists first, checkpoint at the first successful mutation, then commit UI and model state together.

2026-07-31 - A Loop Edit Becomes Audible At A Block Boundary

A loop edit is one complete musical decision, not a sequence of asset, volume, reverse, and processor changes leaking into playback independently. Publishing those values as an immutable generation lets the current block finish with the world it captured while the next block begins with the new world. Keeping DSP history in audio-owned runtime state preserves continuity without making the UI own realtime motion, and deferred retirement turns asset lifetime into an explicit part of the musical contract.

Realtime Instrument Assets: Publication Is Not Retirement - 2026-07-31

Atomic publication answers which complete asset generation a new voice sees; it does not decide which thread destroys the old one. The durable model is therefore two-part: a voice owns the generation it captured, and each non-audio writer owns displaced generations until no callback or voice can still reference them.

This applies equally to ordinary sample layers, mapped samples, Liftoff/Lunacy user sources, Quasar zones, and prepared SoundFont racks. Leaf handles may be dropped during realtime completion, but the containing generation remains alive through that operation. A later model publication performs reclamation off the callback.

The deterministic release gate proved old-generation output after clear/replacement, new-generation selection by the next voice, finite output, zero scoped callback lifetime diagnostics, and eventual writer-side mapped and TSF reclamation. Process-wide allocator/lock interception and physical rapid-replacement soak remain separate beta evidence.

2026-07-31 - Source Identity Is Not Audible Destination

Automation carries two truths that should not be collapsed. The stored MIDI channel says which authored controller row the gesture belongs to; the Shared Pattern, Clip Local, or Lane Local owner says which musical objects hear it. Only after resolving that owner should the lane route choose the internal output channel.

That distinction makes reassignment musical instead of destructive. Channel 4 automation can keep its identity while a lane moves to Channel 12, and deleting the row clears Channel 12 so the old pan, volume, expression, modulation, bend, or sustain value cannot linger audibly. Multiple lanes aimed at one internal channel are one destination, while an external-only owner must not leak into an unrelated internal source channel.

2026-07-31 - A Release Receipt Belongs To A Commit

A green development workspace and a reproducible release candidate are different artifacts. The clean-checkout runner binds evidence to one exact SHA, derives the source and package inputs that must exist there, and refuses to borrow uncommitted dependencies from the developer's machine. Its temporary worktree and build can disappear; the receipt preserves which candidate was actually proven.

This also keeps automated and human truth honest. Deterministic convergence can certify code, generated fixtures, ownership, and lifecycle boundaries. Hardware feel, rendered sound, private libraries, installers, and target-machine behavior still require their own evidence rather than being implied by a clean build.

2026-07-31 - A Selected Clip Is A Recording Permission Boundary

Selecting an Arrangement clip for recording is more than choosing a convenient coordinate origin. It grants one precise playable interval permission to mutate its Pattern. Once the playhead passes that interval, continuing to write would create invisible shared data that a longer linked clip could reveal on another lane, turning a harmless late gesture into cross-talk.

Repeats do not weaken that boundary. Positions inside length * repeats still fold through the clip's source range, preserving musical repetition, while positions after the final repeat are rejected and made visible through take diagnostics. The small pre-roll allowance remains deliberately one-sided so the first downbeat is captured without granting a matching post-end overrun.

Release provenance as a product feature

The release-candidate manifest connects engineering discipline to customer trust: the same app that emphasizes visible ownership for lanes, automation, and instruments should also make ownership of source, assets, licenses, and test evidence explicit. Clean-checkout convergence turns reproducibility into a durable capability rather than a one-time cleanup ritual.

Auditable factory sound generation

The TG55 provenance gap suggests a reusable product capability: factory wave memories should be generated by a tracked deterministic tool that emits the audio, recipe, seed, hash, and listening-approval record as one transaction. The same mechanism can later support Drum Labs, Quasar factory instruments, wavetable banks, and AI-assisted patch creation without losing the boundary between inspiration and distributable first-party content.

Short proof paths are part of Windows reproducibility

A clean checkout can be logically isolated and still fail for an irrelevant environmental reason if generated JUCE and MSBuild paths cross Windows' legacy path limit. The release runner now uses a short, guarded workspace beneath the user's temporary directory. This same rule should guide future plugin scans, package verification, and disposable compatibility builds: preserve isolation and deletion guards while keeping tool-generated paths short enough for the least capable supported filesystem behavior.

2026-07-31 - Exact-Snapshot Automation Ownership Proof

• The clean-checkout release proof exposed a stale broad-test expectation rather than a playback defect: clip-effective Automation contains Shared PTN plus Clip Local events, while Lane Local Automation remains in absolute Arrangement time and is applied separately.
• That separation is essential. Folding Lane Local data into every clip would repeat lane-wide gestures at each clip boundary and could double-apply them during playback or export.
• Release convergence now verifies the intended ownership model from the exact committed snapshot instead of preserving an obsolete count from the earlier combined model.

2026-07-31 - Support Evidence Without Musical Surveillance

A useful support bundle should explain the machine and routing state without quietly becoming a copy of the composer's work. The deliberately small archive contract makes privacy review comprehensible: three text files, no project data, no audio, no samples, and path redaction before anything is compressed.

That same boundary can later support crash recovery. A crash marker, rotating application log, and MIDI-health receipt can flow into the bundle, while notes, chords, presets, and assets remain excluded by construction. The support tool therefore becomes part of SpaceAge's visible-ownership philosophy rather than an opaque diagnostic dump.

2026-07-31 - A Visual System Can Teach Ownership

SpaceAge's visual cleanup can do more than make screenshots attractive. The same semantic state language can explain the entire product: blue means selected or live data, ember means musical motion or commitment, brown identifies a record target or scoped mode, and rust-red means recording or destructive intent. A composer who learns those meanings in the Arrangement should recognize them immediately in Automation, MIDI setup, Mixer channels, and Instrument editors.

Centralized visual tokens also connect seemingly separate goals. They make themes feasible without spreadsheet-driven one-off replacements, let accessibility modes change contrast and motion safely, give screenshot tests stable geometry, and prevent future synth or effect pages from inventing another private control language. The theme system therefore becomes maintenance architecture, not decoration.

The lane badge is the best first proving ground because it joins composition, routing, MIDI, Instrument Bay, and Mixer ownership in one small space. If identity, destination, instrument, preset, record state, and actions are readable there without clutter, the same hierarchy can shape Hardware Passports, preset records, automation headers, and rendered-stem naming.

Motion should follow the same principle. One transport snapshot can drive clip interiors, Section pulses, meters, metronome lights, reels, and automation cursors. Sharing musical truth removes drift, reduces redraw work, and turns animation into useful feedback rather than unrelated spectacle.

2026-08-01 - Closing A Window Is A Musical Action Too

A composer should be free to dismiss a chooser, close a plugin editor, or quit SpaceAge without leaving background work holding a dead control surface. Safe callback ownership connects apparently unrelated features such as MIDI import, Pad Vault maintenance, Quasar loading, rendering, and TempoCalc export: they all share the same promise that delayed work only acts on a living destination.

The same idea extends below the interface. A MIDI queue is not merely a thread; it is a temporary borrower of the processor's musical world. Stopping producers and joining those borrowers before destruction turns shutdown into a defined transaction. That foundation can later support an honest unclean-session report, safer plugin-host editor closure, and recovery evidence without collecting the user's music.

2026-08-01 - Detached Creative Surfaces As Borrowers

Task: Begin converting detached CallOutBox panels from implicit raw ownership to explicit JUCE lifetime guards.

Connection: A floating editor is a temporary borrower of the musical world, just like an asynchronous MIDI queue. Giving both the same resolve-before-use contract makes shutdown behavior teachable and reusable across MIDI setup, automation, hardware editors, Flux Nodes, and future VST surfaces.

Architecture choice: Processor-only panels use weak references; editor-driven panels use component safe pointers. The owner invalidates access first, then shuts down producers. Static report panels retain copied snapshots and require no live owner.

Subagents: Schrodinger mapped all detached callouts and their raw references. A second independent lifecycle audit verified JUCE 8 CallOutBox ownership, SafePointer behavior, timer risks, and the need to invalidate processor weak references before teardown work. Both were read-only.

2026-08-01 - Health Surfaces Must Be Honest About Their Own Health

Task: Complete detached ownership for the MIDI Health surface.

Connection: A diagnostic panel that outlives the system it diagnoses can become the crash it was meant to explain. Requiring both a living processor and a living editor turns the Health panel into a self-validating borrower: it refreshes while its musical world exists and quietly retires when that world closes.

Reuse: The same transitive-owner rule applies to future Hardware Passport inspectors, VST diagnostics, render progress, and recovery surfaces. A safe intermediate panel is not enough when it forwards work to another owner.

Subagent: Aristotle independently audited MIDI Health, MIDI Maps, and SysEx Vault. Its editor-lifetime finding was integrated into this slice; the remaining two panel maps are retained as the next implementation checklist.

2026-08-01 - MIDI Maps As A Live Patch Bay

Task: Remove implicit editor ownership from the detached MIDI Maps surface.

Connection: MIDI Maps behaves like a live patch bay: its rows appear static, but every controller movement and mapping edit crosses a changing ownership boundary. Giving each generated control the same resolve-before-use rule as the timer makes the whole patch bay transactional rather than merely making its outer frame safe.

Reuse: This generated-row pattern can be reused by automation parameter lists, hardware profile editors, VST parameter maps, and future user-defined macro panels.

2026-08-01 - SysEx Vault ownership as a reusable hardware-editor rule

The SysEx Vault lifecycle fix establishes a reusable pattern for future Yamaha XG, Roland, and other hardware-editor surfaces: detached hardware tools should behave like temporary observatories, not owners of the audio engine. They may poll and display live evidence while the project exists, but they must quietly stop and close when that project disappears. Applying the same weak-owner boundary to future librarian, patch-editor, and diagnostic panels lets SpaceAge add deep hardware workflows without making project closing fragile.

2026-08-01 - Hardware Passports as docking documents

Hardware Passports are best understood as docking documents between a SpaceAge project and an external instrument. A docking document can describe, preview, and confirm a relationship, but it should never keep the project alive or assume the project still exists after a user closes it. The weak-owner conversion makes that metaphor technically real and gives future XG editors, device librarians, and recall assistants a reliable lifecycle pattern to inherit.

2026-08-01 - MIDI Patch as a temporary hardware flight plan

Task: Make the detached MIDI Patch surface safe when its editor or parent Settings surface closes during a confirmation.

Connection: MIDI Patch is not the hardware and it is not the project. It is a temporary flight plan between imported setup evidence, a Hardware Passport, and an explicitly confirmed outbound action. Treating every UI layer as a borrower keeps the safety story consistent with SysEx Vault and Hardware Passport.

Reuse: Future Yamaha XG editors, patch librarians, VST parameter inspectors, and device-test dialogs should inherit the same rule: copied reports can outlive the editor, but live project reads and hardware-changing actions must resolve every owner at the moment of use.

Subagent note: Curie was assigned a narrow independent audit, but the agent launcher stalled before returning an agent identity. The stalled launch was terminated; no unreviewed agent output or code entered this checkpoint.

2026-08-01 - Automation is a temporary lens, not an owner

Task: Close the raw-ownership boundary in the detached Automation editor without changing musical ownership or live response.

Connection: Automation can belong to a shared Pattern, one clip, or an Arrangement lane. The popup is only a temporary lens over that data. Making the lens self-invalidating reinforces SpaceAge's broader visual language: the musical object owns the performance data; an editor merely visits it.

Reuse: Motion Clips, VST parameter editors, MIDI 2.0 per-note expression, hardware control maps, and future graphical modulation editors can share this exact contract. Each surface may provide many gestures, but every gesture resolves a living project/editor and a visible musical owner before it acts.

Subagent note: No agent output was used in this slice. The local conversion remained on the critical path after the immediately preceding agent-launch attempt stalled.

2026-08-01 - A support bundle should be a dashboard, not a diary

Task: Prevent composer-authored and hardware-authored names from entering support archives.

Connection: SpaceAge already treats MIDI Health as a cockpit: counts, timing, readiness, and visible boundaries matter more than a wall of internal prose. The support bundle now follows the same idea. It exports instrument-panel readings, not the musician's diary: queue age, dropped-message counts, route readiness, visible/open-device counts, and safe-send state without names, notes, projects, or hardware identities.

Reuse: The same typed-snapshot pattern should govern the upcoming standalone session journal, render diagnostics, project-load health, and future installer reports. Each should use a small versioned schema with closed enums, numbers, and booleans rather than sanitizing arbitrary logs after collection.

Subagent note: No subagent output was used. The immediately preceding narrow agent launch stalled before returning an identity and was terminated; implementation and verification remained local and reviewable.

2026-08-01 - Session evidence as a black box with the microphone removed

Task: Add honest standalone interruption evidence without collecting the composer's work.

Connection: Recovery, support, shutdown safety, and privacy all need the same small fact: did the prior standalone lifetime reach its explicit clean-shutdown checkpoint? A per-instance lock makes that fact compatible with multiple open SpaceAge windows, while a closed three-field record keeps it independent from projects, instruments, hardware, MIDI, and user-authored text.

Reuse: This evidence can later guide a recovery prompt, annotate a support bundle with one closed enum, or prioritize recovery snapshots without ever becoming an activity log. The same lock-plus-typed-state pattern can protect future render journals and installer transactions.

Subagent note: Kepler was assigned a read-only JUCE lock review, but the agent launcher did not return an identity and was terminated. No subagent output or code entered this change; the lock semantics were verified directly against the bundled JUCE 8.0.8 Windows and POSIX implementations.

2026-08-01 - One ownership root beats twelve defensive leaves

Task: Close the remaining lifetime ambiguity shared by the Sequencer Settings family without changing any customer-facing MIDI workflow.

Connection: Parenting the Settings callout to the editor establishes one structural truth: the root cannot remain after its editor disappears. Safe pointers and weak references still protect delayed child work, because a child action may return after the panel was dismissed even while the editor survives. The combination is stronger and easier to reason about than scattering raw checks across every button.

Reuse: Future Instrument Bay inspectors, VST editors, XG device pages, and nested setup assistants should begin with parent ownership, then use safe component pointers for delayed UI work and weak processor ownership for audio-engine work. When an owner disappears, reads return closed default reports and writes become no-ops.

Subagent note: Kepler was assigned a read-only detached-panel audit, but the launcher stalled before returning an agent identity. The launch was terminated; no subagent output or code entered this pass.

2026-08-01 - The package button should be a customs checkpoint

Task: Prevent a technically successful build from becoming a legally unsafe public package.

Connection: Instrument Bay already distinguishes an available engine from a user-chosen instrument, and Hardware Passports distinguish known configuration from trusted hardware evidence. Asset packaging needs the same honesty: a resource may exist and work in development without being cleared to cross the public distribution boundary.

Reuse: The machine-readable clearance manifest can later cover factory presets, splash variants, tutorial projects, SoundFonts, impulse responses, and theme packs. A future installer or storefront export can consume the same statuses instead of inventing a separate legal checklist.

Subagent note: Dirac independently audited the CMake-linked code, embedded resources, and package notices. It confirmed the TG55 distribution block and identified missing JUCE, VST3, and JUCE-transitive notices; no agent edits were accepted directly.

2026-08-01 - The customer executable is a test surface

Task: Fix the standalone startup stack overflow and make launching the exact copied executable a release requirement.

Connection: SpaceAge's processor/editor tests and VST3 path can be healthy while the standalone wrapper has a different process-stack boundary. Treating the customer executable as its own test surface connects build engineering to the actual first user experience: a build is not usable merely because its DSP tests pass; it must create a window and shut down normally.

Reuse: The launch-smoke contract can later expand to startup-progress, blank/last/project-file choices, audio-device failure recovery, and installer verification. Package staging now tests the copied executable, so future signing or installer steps can inherit the same prove-the-artifact-you-ship rule.

Subagent note: Goodall independently inspected Windows crash evidence and the compiled executable. It confirmed exception 0xC00000FD, two startup frames larger than the former 1 MiB stack, copy integrity, and the absence of any customer-executable launch gate.

2026-08-01 - The number 1 is a musical landmark

Task: Add a dedicated Arranger control and plain 1 shortcut that always returns the playback head to measure 1, step 1.

Connection: SpaceAge already has context-aware Play behavior, loop starts, draggable playhead targets, Rewind, and fit/overview gestures. The new control is deliberately context-free: it is a hard navigation landmark that never changes a Pattern, clip, lane, loop, or selection. That distinction makes transport behavior easier to learn and gives future accessibility and hardware mappings one unambiguous command to invoke.

Reuse: The same explicit-landmark action can later back a MIDI Learn target, a hardware transport command, a command palette entry, and a first-measure marker without duplicating transport logic.

Subagent note: Sagan independently mapped the transport regression gaps. The implementation adds direct processor/editor proof that the action lands at Arrangement step zero even when a loop is active.

2026-08-01 - A fresh instrument should be a promise, not a surprise

Task: Audit all internal instrument startup states while improving Propulsion layout and synth-control drag behavior.

Connection: Lane-owned Instruments, patch saving, Instrument Bay, chord playback, and the Mixer all depend on one shared promise: choosing a fresh tonal engine should immediately produce a stable, tuned, chord-friendly sound. A neutral initialization contract prevents prior detune, spread, motion, gating, modulation, or granular pitch variance from leaking into a new lane.

Reuse: The contract can become a factory-preset validator and a future AI patch-creation guardrail. Every generated patch can be checked for A440 tracking, finite output, bounded CPU, note release, and explicitly intentional pitch offsets before it enters a preset bank.

Subagent note: Kepler audited every engine's startup state and shared voice-retirement path. It confirmed strong panic/release handling and identified the asset-backed fresh-engine and parameter-leak risks corrected in this pass.

2026-08-01 - Chord movement is performance, not mixing

Task: Give every Chord Marker its own pan position and provide one deliberate action that applies the current position to every Chord Marker in the project.

Connection: Chord gain, voice velocity, strum, and arp behavior already describe how a Chord Marker performs. Pan belongs in that same performance layer. Keeping it out of lane and Mixer state lets a composer move individual chords while the lane still has one predictable orchestral placement and one predictable channel strip.

Reuse: The project-wide action establishes a reusable bulk-transform pattern for future chord performance controls such as articulation, voicing spread, humanization, and arp emphasis. The per-voice pan offset also gives future Motion Clips and MIDI 2.0 expression a safe additive layer without rewriting the instrument or Mixer pan.

Subagent note: No subagent was used for this focused ownership change. Implementation and regression proof remained local so the audio, MIDI, persistence, undo, and UI paths could be reviewed as one transaction.

2026-08-01 - One physical gesture should mean one musical decision

Task: Make continuous Mixer edits participate in SpaceAge Undo/Redo with the same one-gesture transaction boundary already used by Synth controls.

Connection: Mixer faders, pan, sends, channel dynamics, saturation, and EQ are all performance-critical controls, but they previously bypassed the project Undo stack while Synth knobs entered it. A shared slider-gesture boundary makes the interface teach one rule: press, drag, and release is one reversible decision regardless of whether the musician is shaping an Instrument or its channel strip.

Reuse: This gesture boundary is also the correct future grouping point for automation write. Automation can record the continuous values while Undo still treats the entire held gesture as one edit, avoiding hundreds of tiny history entries.

Subagent note: No subagent was used. The change and its real-editor regression were kept together because attachment order, project checkpoints, and Mixer-bank navigation form one interaction contract.

2026-08-01 - A displayed difference is a user decision

Task: Make discrete Mixer changes participate in project Undo without turning attachment refreshes into phantom edits.

Connection: JUCE buttons and menus display parameter state, but SpaceAge owns the musical history. Comparing the newly displayed control value with the still-current parameter value distinguishes an intentional toggle or choice from a parameter-driven repaint. That gives mouse, keyboard, and accessibility activation the same transaction rule while preserving Mixer bank refresh and Undo restoration.

Reuse: The displayed-value-versus-model-value rule can be applied to other attached discrete controls, including instrument modes, effect algorithms, filter types, and future VST parameter menus. It is a general bridge between JUCE attachments and SpaceAge's bounded project history.

Subagent note: No subagent was used. The implementation and real-editor regression were kept together because JUCE listener ordering, APVTS quantization, Mixer bank attachment, and project Undo form one interaction contract.

2026-08-01 - History should remember the musician, not the widget class

Task: Bring every Master-channel continuous control into Mixer Undo and prove mixed fader, toggle, and routing history as one ordered user story.

Connection: A musician does not think in separate slider, button, and menu histories. Master volume, channel mute, and output routing are successive mix decisions, so Undo must walk backward through those decisions regardless of which JUCE control produced them. The mixed regression turns that expectation into a system-level contract.

Reuse: The same ordered-history proof can later cover automation gestures, effect-algorithm changes, instrument replacement, and hardware-control edits. New controls should be tested inside a mixed musical sequence, not only as isolated widgets.

Subagent note: No subagent was used. This was a focused integration change across the Master controls, shared project history, and the existing real-editor regression surface.

2026-08-01 - Effects history should follow the signal decision

Task: Make compact Effects controls, selected-source sends, and deep effect-editor controls participate in project Undo/Redo.

Connection: A send move can automatically enable its destination return. Those two parameter changes are one audible decision, so they must enter history as one transaction rather than forcing the musician through two unrelated Undo steps. Compact rack controls and deep editor controls now follow the same rule.

Reuse: The displayed-value-versus-model-value guard prevents attachment refreshes from manufacturing history and can be reused by future effect algorithms, instrument modes, and VST parameter menus. JUCE's slider gesture also covers typed-value commits and double-click reset, keeping every input modality under one transaction boundary.

Subagent note: No subagent was used. The production changes and real-editor mixed-history regression were kept together to verify parameter attachments, automatic return enabling, deep-editor lifetime, and project history as one system.

2026-08-01 - Undo should follow a musical decision across the whole app

Task: Close project-history gaps across Pad, Instrument Bay, automation, Arrangement, Effects, Mixer, and Master controls.

Connection: The meaningful unit is not a widget or page; it is the musician's decision. A synth mode change, clip resize, automation edit, and fader move must occupy one ordered history even though they come from different subsystems. The cross-system contract now verifies that shared language directly.

Reuse: Future VST parameters, Motion Clips, hardware-editor controls, and scene orchestration should enter this same transaction layer. Continuous movement is one gesture; discrete state changes checkpoint only when model and display genuinely differ.

Subagent note: Newton audited the customer-facing control surface and identified the Pad, Instrument Bay, TG55, project-volume, and performance-control gaps. Integration and regression design remained in the main task so one owner could preserve ordering across JUCE attachments and SpaceAge project history.

2026-08-01 - A project file is a promise, not merely parseable JSON

Task: Reject unsupported SpaceAge project formats before they can alter the open session.

Connection: A file chooser saying a document is valid creates the same kind of trust as audible Undo or a stable transport. Format identity and compatibility therefore belong at the boundary, before restoration, whether state arrives from SpaceAge's project loader or from a plugin host.

Reuse: The explicit compatibility gate is the starting point for future migrations. When format 2 exists, its conversion can be deliberate and tested instead of allowing a newer schema to drift through old restoration code. The same preflight-before-mutation rule belongs in presets, Quasar packages, hardware profiles, and future Scene files.

Subagent note: Faraday found the unsupported-version gap in the save/recovery audit. Newton ranked remaining beta risks and identified a joined Golden Project Lifecycle regression as the next highest-value automated proof. Both audits were read-only; integration remained with LT.

2026-08-01 - Green parts must also make a green song

Task: Join project persistence, lane-owned Instruments, Mixer routing, Chord Engine playback, automation, shared effects, realtime playback, and WAV export in one Golden Project Lifecycle proof.

Connection: Isolated regressions can all pass while the handoff between them fails. The representative fixture now saves a real three-lane Arrangement, destroys the source processor, reopens the project, plays it through the production callback, and renders through the production exporter. A late note, lane-local pan automation, two independent Instrument sources, a Chord Marker, distinct Mixer routes, a stored loop, and an audible Halostar tail all have to survive together.

Reuse: This becomes the backbone for future golden-song tests involving Scene orchestration, VST hosting, hardware recall, tempo maps, Quasar assets, and installation migrations. New subsystems should extend the same musical story instead of creating another disconnected green island.

Subagents: Maxwell mapped reusable fixtures and warned that notes and chords must explicitly target their lane-owned private Instrument slots. Kepler audited production export behavior and found the live-versus-captured tempo race and missing non-finite buffer rejection. LT integrated both findings and the lifecycle gate.

2026-08-01 - A failed save must preserve the last good truth

Task: Make invalid project destinations fail before staging and prove that failure cannot damage the last valid project.

Connection: Save As, project export, preset storage, Scene files, and future hardware snapshots all make the same promise: a failed destination must not become the new truth. SpaceAge now rejects a directory disguised as a project file and a destination whose parent cannot become a folder before creating a temporary project.

Reuse: The regression pattern is reusable for presets, Quasar packages, archives, rendered audio, and Scene orchestration: preserve a known-good target, force a deterministic destination failure, compare bytes, reopen the prior artifact, and confirm the live session remains unchanged.

Subagent note: The subagent service stalled before accepting this pass's audit assignments. The save-path audit, implementation, and regression were completed locally rather than leaving the critical path idle.

2026-08-01 - Recovery should feel like a trustworthy alternate timeline

Task: Make recovery snapshots collision-proof, preserve every meaningful minimal state, and identify restored work as unsaved.

Connection: SpaceAge already treats Sections, clips, lane Instruments, Drum Pads, and external assets as parts of one composition. Recovery should preserve that same whole-project identity even when the useful edit is only a renamed Pad, a changed Section, or one shortened clip. The snapshot is an alternate timeline, not a replacement for the last deliberately saved project.

Reuse: The unique immutable snapshot identity and explicit unsaved state are the foundation for a future Recovery Center: preview snapshot time and musical contents, compare against the current project, restore selected components, and promote a chosen snapshot only through an explicit Save As. The same model can later support project versions and SpaceAge Scenes without confusing experimentation with committed work.

Subagents: Kuhn audited recovery creation, discovery, retention, and restoration and found the collision and useful-state mismatch. Mendel audited release evidence and human QA and found the missing dedicated recovery gate and failure-path checks. Both audits were read-only; LT integrated the implementation, regression, and documentation.

2026-08-01 - A malformed project should behave like a locked airlock

Task: Prevent internally malformed but syntactically valid project state from partially changing the open song.

Connection: Recovery, project loading, plugin-host recall, future Scene files, and eventual project-version browsing all ask the same trust question: is this complete musical state safe to admit? One semantic preflight now answers that question before the mutating restore path begins.

Reuse: The validator can become the foundation for a future Project Doctor that explains which lane, clip, note, Pad layer, or automation payload is damaged without opening it. The same validation vocabulary should be reused by presets, Quasar packages, hardware profiles, and project migrations so corrupted content produces an actionable repair report rather than mysterious defaults.

Subagent note: Two review-only audit assignments were attempted, but the subagent service did not return agent identities and the stalled dispatch was terminated. The validator audit, hostile-state regression, and evidence wording were therefore completed locally.

The final structural pass treats completeness as part of validity. A shortened Pad bank is not a small project, a mismatched layer count is not a suggestion, and a clip cannot point into an imaginary lane. Those checks prevent a damaged file from borrowing leftover state from the song already open. The same exact-cardinality rule belongs anywhere SpaceAge stores fixed hardware banks, modulation slots, multisample layers, or future Scene orchestration records.

2026-08-02 - Preset recall is an audible-and-visible transaction

Task: Guarantee that loading an Instrument or Drum Lab preset updates every visible slider, rotary control, selector, and custom envelope/source display to the recalled settings.

Connection: Preset recall, Undo, automation, MIDI Learn, future Scenes, and hardware patch editing all share one trust rule: the control surface must describe the state that is actually producing sound. SpaceAge now completes factory and file-based recall through one presentation refresh instead of relying on incidental repaint timing.

Reuse: The same transaction boundary can later refresh VST editors, Yamaha XG panels, Scene orchestration choices, and AI-created patches. Any new engine should attach ordinary controls to the parameter tree and register custom visualizations with the shared recall refresh.

Subagent note: Curie and Faraday were assigned the engine-loader and regression audits, but the subagent launcher stalled and was terminated. LT completed the audit, implementation, and verification locally.

2026-08-02 - Project-load feedback is a reversible state

Long-operation feedback must never become a modal trap. Project loading, recovery loading, preset loading, and Blank Project all share one rule: if a competing MIDI package import prevents the operation from starting, SpaceAge must immediately restore the prior startup choices or remove the ordinary busy overlay. This same helper can govern future mutually exclusive offline jobs so every refusal has a matching UI-release path.

Preset recall follows a similar truth contract. Native patches, SoundFont programs, Quasar packages, Piano Roll preset choices, and MIDI-assisted SoundFont mapping should all converge through one presentation refresh so the audible source, lane badge, preset identity, selectors, and visible controls agree in the same transaction.

2026-08-02 - Pad And Instrument APIs Should Describe Different Musical Objects

Task: Close the final public API ambiguity between Drum Pads and lane-owned Instruments.

Connection: Pads are tactile performance cells; Instruments are sound generators owned by Arrangement lanes. They may reuse source-parameter infrastructure internally, but code that asks for one should never receive the other by clamping an integer. Treating those APIs as type boundaries reinforces the same three-part model the GUI teaches: source identity belongs to the Instrument, composition belongs to the Lane, and gain/effects/routing belong to the Mixer Channel.

Reuse: This boundary gives future VST hosting, hardware editors, Scenes, stem naming, and Instrument Bay cards a trustworthy identity model. A Yamaha module, a VST, Redshift, or Quasar can all become lane Instruments without pretending to occupy a Drum Pad; deliberate conversion or copying can remain an explicit creative action.

Verification: L01-A and SOURCE_CARDINALITY jointly prove lane creation, Pad isolation, independent Instrument IDs and sources, routing, copy/Variant behavior, Automation and recording targets, maximum-lane persistence, and audible private-Instrument playback.

Subagent note: Kepler was assigned a read-only API-boundary audit and Faraday a release-evidence audit. The launcher again stalled before returning either identity, so neither agent consumed project work; LT completed both audits locally and terminated the stuck dispatch.

2026-08-02 - A lane is both the musical owner and the landing target

Task: Close the release contracts for changing a lane Instrument and adding clips to a selected lane.

Connection: Instrument choice and clip placement look like separate gestures, but both depend on the same ownership truth: the lane is the stable musical actor. Changing its sound should update what is heard and what the editor displays without moving the composition or its Mixer route. Adding material should land on that same selected actor, with the playhead expressing time rather than secretly choosing ownership.

Reuse: This contract can govern future VST instruments, Yamaha XG destinations, Scenes, ghost-note sources, automation lanes, and stem rendering. Each feature can ask two simple questions: which lane owns this object, and at what timeline position should it begin? That is a much safer foundation than reconstructing intent from Pad selection, hidden source slots, or global clip counts.

Verification: L02-A proves audible replacement, editor/badge/preset agreement, Mixer-route preservation, and save/load identity. L03-A proves empty-lane, append, playhead insertion, cross-lane, and Drum-lane placement through the real UI callbacks. The complete Release suite passes through final WAV export.

Subagent note: Two read-only audit dispatches were attempted for Instrument replacement and clip insertion. One initialized late as Hubble only when the stalled dispatch was being terminated; the other never initialized. Neither returned findings or contributed changes, so LT completed the audits, integration, and verification locally and closed the idle agent.

2026-08-02 - A Lane Route Is One Musical Decision

Task: Close lane Mixer assignment and MIDI input/output policy as one dependable workflow.

What connects creatively: Choosing a performer, its Mixer channel, its incoming controller, and its outgoing hardware destination are different views of one orchestration decision. Keeping them synchronized makes Instrument Bay, live recording, hardware editors, Scenes, stems, and future VST routing easier to understand because each can ask the lane for one authoritative route.

Architecture choice: Mixer reassignment now refreshes normalized route metadata, armed live input, Piano Roll audition routing, lane presentation, status feedback, playback snapshots, and persistence in one operation. The proof fixture joins the visible route to its saved input device/channel, output device/channel, target, Passport, and Mixer destination.

Future extensions: Use the same transaction boundary when adding drag-to-route Mixer assignment, Scene orchestration recall, VST buses, stem destinations, and hardware-editor launch actions. Do not let any of those surfaces write only half of a lane route.

2026-08-02 - Lane Type Is The Orchestration Boundary

Task: Close the remaining Drum-versus-Instrument contamination risk after movable lane insertion made lane zero an unreliable proxy for Drums.

What connects creatively: Lane order is visual orchestration and should remain freely rearrangeable. Lane type is musical identity and must remain stable. Separating those ideas lets composers group or reorder instruments without changing which sequencer, source, preview, editor, or playback engine owns their clips.

Architecture choice: The owning ArrangementLane.type is authoritative. Clip type is a normalized persisted mirror, not an independent vote, and no production path may infer Drum identity from lane == 0.

Future extensions: The same boundary can drive lane templates, multiple percussion lanes, Scene orchestration, stem naming, VST classification, hardware drum modules, and conversion dialogs. Reordering becomes harmless because ownership travels with the lane record.

Verification: L01-A lane-owned Instrument workflow reports drumBoundary=1 after Instrument-at-zero creation, Drum-lane insertion, contradictory metadata normalization, Pad/Instrument sentinel isolation, and save/reopen. SOURCE_CARDINALITY independently keeps audible private-Instrument and Drum boundaries green.

Subagent note: Kepler and Noether were assigned read-only production and evidence audits. The agent service stalled during initialization and returned no work; both calls were terminated, and LT completed the audit and verification locally.

2026-08-02 - Clone Repeats A Score; Variant Writes A New One

Task: Make CLONE and VARIANT communicate dependable, musically useful ownership rather than merely drawing similar clips.

Connection: A pattern is the score, a lane is the performer, and a clip is one placement of that performance in time. CLONE places the same score again, so editing its notes or chords improves every linked occurrence. Clip-local automation remains a performance decision, allowing the repeated phrase to pan, articulate, or evolve differently at each occurrence. VARIANT deliberately forks the score when the composer wants a fill, turnaround, reharmonization, or melodic development.

Reuse: The same ownership language can drive future Scene orchestration, Motion Clips, VST instances, chord-progression libraries, stems, and collaborative editing. Shared content should always be visibly linked; local performance data should remain local; creative divergence should always be explicit.

Efficiency: CLONE no longer wastes an empty pattern merely to duplicate a placement. VARIANT consumes a new pattern only when independence is requested.

Verification: The release gate uses the real CLONE and VARIANT controls, compares exact notes, chords, shared and clip-local automation, proves independent edits in both directions, preserves complete lane routing and patch identity, and saves/reopens before and after the fork.

Subagent note: Noether independently audited the first regression and identified missing convergence, exact-content, lane-identity, and real persistence proof. Those findings were integrated. A second audit dispatch stalled and was terminated without contributing changes.

2026-08-02 - A Lane Stem Is The Sound Of One Musical Role

Task: Turn the one-Instrument-per-lane architecture into predictable collaborator-ready audio stems.

Connection: A lane already owns a musical role, Instrument, Mixer destination, MIDI route, name, and mute/solo state. Stem export should report that same identity in audio rather than inventing a separate export routing model. This makes a stem the audible receipt of the lane architecture.

Architecture choice: Isolate the Arrangement lane before event scheduling, then let its normal Mixer channel(s), shared sends, effects, and Master path render unchanged. Mixer solo alone cannot isolate a Drum lane because one Drum lane may use many Pad channels. Every output file begins at song zero and has the same duration, so collaborators can drag the package into another DAW without manual alignment.

Creative extensions: The manifest can later power Scene comparisons, collaborator handoff, frozen Instrument lanes, render-in-place, stem relinking, cloud review, and selective project archives. Silent stems remain useful evidence: they explain muted, solo-excluded, empty, or external-only lanes instead of making a collaborator wonder whether export lost material.

Verification: L08-A proves stable ownership metadata through save/reopen, unique human-readable filenames, exact stereo 24-bit/48 kHz alignment, audible Drum isolation, silent-state policy, progress, cancellation cleanup, and refusal to overwrite an existing package.

Subagent note: Huygens audited render ownership, routing, and naming; Boole designed hostile verification. Both independently found that production audio stems did not exist and that Mixer-only isolation would be wrong for Drum lanes. Their findings shaped the lane-event isolation and manifest contracts.

2026-08-02 - A Clip Is A Window Onto A Score

Task: Make resize and split preserve musical content, ownership, automation, history, and persistence across long Instrument clips.

Connection: Resizing should feel like changing the frame around an idea, not erasing the part of the composition that no longer fits inside the frame. Splitting then creates two movable performances of adjacent source ranges. The score remains shared, while each piece receives its own performance identity and Clip Local automation.

Reuse: The same source-window model can support future loop extraction, comping, Scene capture, Motion Clip slicing, non-destructive trim handles, and audio regions. Each feature can separate three questions cleanly: what source exists, which window is visible, and which performance data belongs to this placement?

Boundary policy: Notes and chords belong to the piece containing their start. A cut does not manufacture a duplicate note-on for a sustain that began earlier. This keeps MIDI ownership deterministic; a future explicit Consolidate or Render operation may create independently self-contained source material when desired.

Verification: A05-A drives the real length and Ctrl+U callbacks, checks exact notes, chords, repeats, offsets, text, shared and local automation, Undo/Redo, invalid-operation refusal, and save/reopen. Canonical named convergence passes 25/25.

Subagent note: Dalton performed a read-only ownership audit. It identified the stale 64-step paste-split ceiling, missing combined source-range validation, ambiguous split linkage, and insufficient customer-operation coverage. Those findings were integrated; its boundary-note observation is now an explicit product policy and human beta check.

2026-08-02 - Empty Time Is A First-Class Arrangement Object

Task: Close shorter, equal, and longer replacement behavior for preserved Arrangement gaps across Instrument and Drum workflows.

Connection: A gap is not a muted clip and not an erased score. It is a neutral promise that a precise span of song time remains available. Making that distinction explicit lets REMOVE preserve composition structure, lets paste consume only the space it actually needs, and prevents old pattern, repeat, transpose, note, or automation identity from lingering invisibly underneath new material.

Reuse: The same time-container model can support future comping, take lanes, scene insertion previews, loop capture, audio-region replacement, and non-destructive arrangement templates. The chain-to-Arrangement projection rule also gives future multiple Drum lanes a clean boundary: the first lane may mirror the legacy chain, while every additional Drum lane remains a native independent lane.

Verification: A06-A drives the real copy, REMOVE, selected-gap paste, Undo, and Redo callbacks. It proves shorter, equal repeated-span, longer adjacent-gap, and primary Drum-chain cases through save/reopen; preserves notes, chords, clip annotations, Shared/Clip Local/Lane Local automation, Section markers, unrelated Instrument clips, and a second Drum lane; and rejects overlap or duplicate-gap outcomes. Canonical convergence passes 28/28 named gates, including neighboring A04, A05, L08, automation, persistence, recovery, golden lifecycle, standalone launch, and the complete application self-test.

Subagents: Huygens audited the production mutation paths and separated A06 replacement from A02 ripple-insertion concerns. Boole audited release coverage, identified the unreachable Drum clipboard and missing real UI scenarios, and proposed the ownership/sentinel matrix integrated here. Neither subagent edited files.

2026-08-02 - Capacity Describes The Finished Song State

Task: Close A07 by making cut, paste, and clone either complete fully or refuse without altering the project or Undo/Redo history.

Connection: Preserved gaps made capacity a musical-layout problem rather than a container-count problem. One incoming clip may replace one gap yet leave two meaningful pieces of empty time. The same principle connects Instrument paste, Drum-chain projection, recording creation, and future Scene or comping operations: capacity belongs to the final canonical model, not to an intermediate mutation.

Reuse: The pure final-layout projection can become the preview engine for drag ghosts, Scene insertion, comping, template expansion, and eventually audio-region edits. The coupled Drum check also establishes a pattern for any feature whose customer command spans two representations: validate both, checkpoint once, then commit both.

Verification: A07-A drives real clone/shift-clone, paste, cut, and Drum-paste callbacks at exact and over-capacity boundaries. Refusals begin with a populated Redo stack and prove byte-identical project state plus exact history preservation. Neighboring A04, A05, A06, automation ownership, project persistence, golden lifecycle, and MIDI recording timing pass independently before canonical convergence.

Subagents: Huygens audited production mutation and projection paths, identifying recording and coupled Drum capacity risks. Boole independently designed hostile exact-fit/one-short cases and identified the need to seed real Redo history. Their read-only findings were integrated; the separate Drum clip-ID/Clip Local automation projection concern remains visible for the next ownership contract.

2026-08-02 - Move The Musical Thought, Not Separate Decorations

Task: Close A08 by moving selected Section markers and clips as one exact Arrangement decision without hidden ripple or repair behavior.

Connection: Section markers describe the musical thought represented by clips below them. A shared selection should therefore behave like one rigid object during a horizontal move, while clip IDs and automation ownership remain stable. This turns the existing magnetic lift/target interaction into an honest preview of the single model transaction that follows.

Reuse: The exact preflight-and-commit primitive can support chorus duplication, Scene placement, comping, template insertion, and future audio-region groups. Persistent Chain projection IDs establish the same identity rule for any future generated or mirrored Arrangement view: projection updates may change content and position, but they must not casually replace ownership identity.

Verification: A08 covers clip-led and Section-led multi-selection moves, stationary sentinels, exact Undo/Redo, save/reopen, collision refusal with Redo survival, primary Drum projection refusal, and stable Chain projection identity with Clip Local automation. The complete application self-test passes after legacy assertions are aligned to the explicit ownership contract.

Subagents: Huygens found the split publication, unequal-delta, hidden-ripple, and missing-boundary risks in joint moves. Boole found unsafe nearest-ID matching in Drum projection and proposed persistent per-slot projection identity plus explicit primary-lane ownership. Their read-only findings were integrated into one atomic contract.

2026-08-02 - A Gesture Is One Musical Decision

Task: Make Drum Composer entry, selection, step properties, deletion, and Clear predictable and undoable.

Connection: A continuous slider drag is one musical decision even though it emits many values. The same gesture checkpoint rule can serve Piano Roll velocity, automation curves, synth controls, Mixer faders, Motion Clips, and future MPE editing without flooding Undo history.

Reuse: The Drum Composer now distinguishes visible active notes from empty cells, preserves shared pattern duration when clearing only Drum content, and uses the same lane-ownership boundary as Arrangement editing. That pattern can guide any future editor that modifies one payload inside a shared musical container.

Verification: S01-A exercises production callbacks, multi-value slider drags, bank-scoped deletion, Clear scope, Undo/Redo, and melodic/chord preservation. Canonical Release convergence passes 29/29. Huygens audited callback ownership and history branching; Boole supplied hostile customer workflows and identified entry-selection and duration-preservation gaps. Neither subagent edited files.

2026-08-02 - Piano Roll Gestures Are Musical Transactions

Task: Close S02 note creation, movement, resize, velocity, erase-paint, duplicate selection, long-source navigation, and Undo/Redo behavior.

Connection: The Piano Roll now treats a mouse gesture as one musical thought rather than a stream of tiny model writes. That same transaction language already helps Drum Composer and can become the common interaction grammar for Chord Markers, Automation curves, Mixer faders, Motion Clips, and future MPE gestures.

Reuse: Index-authoritative selection prevents identical stacked notes from collapsing into one identity. The broader lesson is that equal musical values are not equal musical objects; future chords, automation points, and layered events need stable ownership identity as well. The source-window calculation also gives long clips and offset clip fragments one timeline rule reusable by split, repeat, and comping tools.

Verification: S02-A drives production callbacks for create, multi-update move/resize/velocity, erase painting, duplicate-note selection, FIT/reset, full MIDI range, a 512-step pattern, an offset source window, and Drum ownership refusal. Neighboring S01, A04, and P04 pass; canonical Release convergence is 30/30. Euler and Laplace supplied read-only architecture and hostile-workflow audits; neither edited files.

2026-08-02 - Chords Are Performance Objects, Not Labels

Task: Close the S03 Chord Engine reliability block across marker editing, typed entry, performance shaping, rendering, persistence, and MIDI export.

What connects creatively: A Chord Marker is simultaneously a harmonic label, a time object, a performance generator, and a portable MIDI source. Treating those as separate features creates the exact kind of hidden inconsistency SpaceAge is trying to remove. The same marker must retain its gain, pan, six voice velocities, strum, humanize, arp, mute/reference state, and ownership whether the user drags it, splits it, clones it, reopens the project, or exports it.

Architecture choice: Chord Marker gestures now use the same lazy one-checkpoint transaction contract as Piano Roll notes. Floating performance and suggestion panels capture their opening pattern and Instrument context, so a later UI context change cannot redirect an edit into another clip. Typed chord parsing rejects ambiguity instead of silently clamping or truncating it.

Verification: S03-A drives production callbacks for create, move/resize, erase, Clone, split, parser aliases and refusal cases, all performance fields, exact persistence, arp render/reference conversion, MIDI export, and Drum ownership refusal. S01, S02, A04, and P04 remain green; canonical Release convergence is 31/31. Euler and Laplace supplied read-only ownership/persistence and hostile-workflow audits; neither edited files.

Future extensions: The same captured-context transaction can protect future chord suggestion preview/commit mode, borrowed-key palettes, chord-progression libraries, transposition, notation, and Motion Clip transformations without adding a second ownership model.

2026-08-02 - A Recording Take Is One Captured Musical Event

Task: Close Arrangement recording reliability from the first performed attack through Undo, save/reopen, and Piano Roll inspection.

Connection: A recorded take joins three systems that must agree: real-time input ownership, Arrangement time geometry, and editable score publication. Treating those as separate conveniences causes lost first notes, wrong-cycle notes, stolen note-offs, or a saved project that trails what the musician just heard. The take is therefore one musical transaction with immutable target geometry and an explicit publication fence.

Architecture choice: Active notes are owned by input source, MIDI channel, and note. The selected clip's source start and source-cycle length are captured at note-on and retained until closure. Latency compensation is constrained to that source window; exact repeated-clip endpoints map to one cycle endpoint. Note and expression queues expose a bounded drain fence before state-sensitive transitions, and one pre-take checkpoint gives the user one honest Undo decision.

Creative reuse: The same transaction can power future take lanes, comping, loop capture, retrospective record, performance receipts, and MPE note-expression capture. Immutable target geometry also gives future audio recording and Motion Clips a common answer to the question: what musical span did the performer believe they were recording into?

Verification: S04-A proves measure-one capture, fractional timing, attack/release velocity and channel, two-controller same-pitch ownership, retrigger preservation, offset and repeated source windows, interruption closure, audible lane route, Undo/Redo, persistence, and Piano Roll truth. M04-A, no-lock recording, restore-boundary, persistence, and the complete application self-test remain green; canonical convergence is 32/32.

Subagents: Euler identified queue/state races, source-window compensation, exact repeat-end mapping, and held-note target changes. Laplace independently attacked retrigger, ownership, interruption, persistence, and UI-truth assumptions. Their read-only findings were integrated into the recording fence and hostile regression matrix; neither edited files.

2026-08-02 - One Transport Language, Two Honest Workspaces

Task: Close S05 by making Play, Pause, Spacebar, rewind/forward, ruler clicks, loops, count-in, and the metronome agree without pretending that the Piano Roll and Arrangement share the same coordinate system.

Connection: The Arrangement owns song position; an isolated sequencer owns pattern position. A transport command first resolves which workspace has authority, then applies one start, pause, or boundary operation. This prevents a stale Arrangement cursor from hijacking isolated editing while allowing a Piano Roll opened from an Arrangement clip to place the real song playhead precisely.

Reuse: The same authority contract can govern future audio editors, Motion Clips, notation, hardware transport chase, retrospective recording, and Scene audition. Mutual exclusivity between the local step loop and Arrangement loop also establishes a reusable rule: one playback engine may expose several loop editors, but only one loop range can own transport at a time.

Verification: S05-A proves exact pause/resume, Piano Roll cursor resolution, restart and measure-one behavior, Arrangement and isolated rewind/forward, loop exclusivity, count-in cancellation with exact transactional rollback, refused-arm Redo preservation, absolute metronome accenting, and project persistence. S04 recording, count-in boundary, Piano Roll, Drum Composer, MIDI sync policy, golden reopen/export, and canonical 33/33 convergence pass.

Subagents: Mill mapped split transport APIs, stale-target leaks, persistence omissions, and message/audio-thread mutation risks. Euclid supplied hostile workflows for count-in cancellation, loop conflict, pause/resume, and cross-workspace targeting. Their read-only findings were integrated; neither edited files. Physical MIDI Stop/MMC while recording remains explicit hardware beta evidence because editor-owned transaction cleanup must never be forced synchronously through the audio callback.

2026-08-03 - Long Clips Need Four Separate Coordinates

Task: Close S06 so long and offset Instrument clips remain understandable, navigable, editable, loopable, and persistent without forcing Drum Composer beyond its intentional 64-step source cycle.

Connection: Long-clip failures came from treating four different ideas as one number: a pattern's complete source extent, the source window exposed by one clip, that clip's occupied song span, and the Piano Roll viewport. SpaceAge now keeps those domains separate. The Arrangement owns clip placement and visible length; the Piano Roll edits only the selected source window; the viewport is merely a camera; and Drum clips may repeat their 64-step authored source without pretending that the source itself became 128 or 512 steps.

Creative reuse: This coordinate model can support imported long MIDI, comping, take windows, notation pages, audio-region slip editing, Motion Clips, and non-destructive source crops. Tiled clip previews use the same source-cycle truth, so a repeated phrase reads as repetition rather than one artificially stretched drawing.

Interaction choice: FIT shows the complete editable source window. Selection FIT centers selected material. Zoom and pan stay inside the window. During playback, the view follows only when the playhead leaves a zoomed viewport; a complete FIT view remains still. Selection and mutations are constrained to the editable window so hidden notes in another excerpt cannot be changed accidentally.

Verification: S06-A proves a 512-step pattern, a nonzero 128-step source window, late-note editing, bounded Ctrl+A and nudging, source-to-song cursor and loop translation, playback following, standalone long loops, and save/reopen. Neighboring Piano Roll, Arrangement resize/split, Clone/Variant, persistence, and transport gates remain green; canonical Release convergence is 34/34.

Subagents: Mill separated the coordinate and ownership risks and identified FIT, zoom-anchor, loop, and preview contradictions. Euclid attacked late edits, persistence, playback following, Drum repetition, and edge workflows. Their read-only findings were integrated; neither edited files. Shift-drag edge auto-scroll and Arrangement-level follow/reveal remain tactile human-beta items rather than hidden claims of completion.

2026-08-03 - Clear Is A Local Eraser, Not A Hidden Reset

Task: Close S07 so each sequencer's Clear command erases only what the musician can see and understand in that workspace.

Connection: Notes, Chord markers, Drum steps, automation, pattern duration, and Arrangement placement can all share one Pattern identity without becoming one destructive domain. Piano Roll Clear therefore removes notes and Chord markers together; Drum Composer Clear removes Drum steps. Automation remains in the Automation editor, and clip geometry remains in the Arrangement.

Architecture choice: Confirmation captures the exact Pattern before the dialog opens and reports how many Arrangement clips and Drum-chain slots reference it. The committed operation cannot be redirected by a later selection change. Piano content is removed under one processor lock and one playback publication; Drum clearing retains explicit duration without rewriting Chain repeats or clip placement.

Creative reuse: This pinned-target, disclosed-reference pattern should govern future destructive operations such as deleting automation lanes, replacing Instruments, clearing Motion Clips, removing samples, or applying project-wide chord changes. A warning should describe the object that will actually change, and confirmation should never look up a newer selection.

Verification: S07-A covers all three automation scopes, mixed payloads, Undo/Redo, no-op history, wrong ownership, linked clips versus an independent Variant, a 4,096-step target, selection drift, repeated Drum blocks, and exact geometry preservation. All 35 canonical Release gates pass.

Subagents: Bacon found shared-pattern disclosure, Chain ownership, and atomic-publication gaps. Faraday exposed the asynchronous selection-retarget bug, repeated-Drum geometry mutation, and missing hostile tests. Their read-only findings were integrated; neither edited files.

2026-08-03 - One Shortcut Event, One Command

Task: Make SpaceAge keyboard shortcuts consistent, discoverable, and harmless while a musician is typing or editing a focused control.

What connects creatively: Keyboard shortcuts are a performance surface. The same discipline used for MIDI input applies here: one physical gesture should enter one canonical path exactly once. Polling Arranger copy/paste in the timer while also accepting normal key events creates the keyboard equivalent of a doubled MIDI note, so the polling path is retired.

Architecture choice: The main dispatcher now yields to focused text editors, combo boxes, sliders, and buttons. Escape remains available as the universal dismissal gesture. This lets local controls own typing, caret movement, numeric entry, and their own undo/copy/paste behavior without firing transport or project edits behind them.

Future extension: Reuse the same focus contract when Motion Clips, plugin hosting, and future device editors add searchable browsers or parameter tables. New shortcut surfaces should route through named commands, not key-state polling.

Completed architecture: Focus ownership is now key-specific rather than a blanket rule. Text entry receives a complete editing vocabulary; menus and sliders receive navigation and value keys; passive buttons cannot silently capture Space transport. Piano Roll notes and Chord Markers share one transpose transaction, command preflights avoid false Undo records, and empty copy attempts leave useful clipboard content intact.

Verification: S08-A covers focused controls, global transport/history access, exactly one Arranger paste, Escape selection cleanup, stale-target refusal, clipboard preservation, plain-versus-modified dismiss keys, and no-op history. Neighboring editor and automation gates pass, and canonical Release convergence is 36/36.

Subagents: Einstein mapped command routing and duplicate paths. Confucius attacked focus ownership, modifier collisions, and hostile text/value workflows. Carver independently found stale selection targets, empty-copy clipboard destruction, and incidental Piano Roll focus divergence. Pauli performed the final read-only consistency audit. Their findings were integrated into one dispatch and transaction contract; none edited files.

2026-08-03 - The Arrangement Selection Is One Magnetic Object

Task: Close A01 by making clip, Section, lasso, collision, cancellation, and edge-scroll behavior agree from the first pointer movement through the final project mutation.

Creative connection: SpaceAge already treats a Section as a non-destructive compositional guide and a clip as lane-owned musical material. Selecting both should create a temporary higher-level object: one magnetic arrangement block. That object can lift, travel, snap, refuse, and remain selected without inventing a permanent container or changing either underlying ownership model.

Architecture choice: The canvas is authoritative for visible selection at the commit boundary. Moved clips are recovered by stable IDs rather than coincidental musical properties. Exact preflight is shared by single and grouped moves, so preview and mutation describe the same destination. Refusal republishes processor truth; Escape restores temporary canvas geometry before it clears the selection.

Reusable interaction: Timer-driven edge scrolling now serves clips, Sections, and lasso selection. The same mechanism can later support note drags, automation-point groups, Motion Clips, sample regions, and notation selections without waiting for repeated mouse events. Exact-preview-or-refuse is equally reusable for paste, resize, time insertion, and cross-lane conversion dialogs.

Verification: A01-A proves long-distance group movement, exact Undo/Redo, single and grouped collision refusal, Redo preservation, stable selection and clip IDs, visible-selection authority, save/reopen, and edge boundaries. Neighboring Arranger edit, long-clip, shortcut, and automation gates pass. Canonical Release convergence is 37/37.

Subagents: Galileo found silent single-clip relocation, stale refusal visuals, stalled edge scrolling, and incomplete Section-led previews. Planck specified the dedicated gate and stable-ID assertions. Euler exposed stale cross-layer selection, Escape-after-drag commitment, Ctrl-click reselection, and future timeline-boundary risks. Their read-only findings were integrated; none edited files.

2026-08-03 - Paste Creates Time For The Whole Song

Task: Make an explicit playhead paste useful for copying a chorus or other multi-lane musical block into the middle of a developed Arrangement without misaligning lanes that were silent or absent from the selection.

Creative connection: A copied chorus is not merely a bag of clips; it temporarily becomes a time-shaped compositional object. Its widest member defines the amount of song time that must be created. This connects the magnetic group-selection language from A01 with the non-destructive Section language and the ownership-aware automation system: clips, Sections, and Lane Local curves all move as different representations of the same inserted musical time.

Architecture choice: Primary Drum time remains a chain concern while secondary Drum lanes use native Arrangement clips. One preflight constructs the future chain, clip edits and splits, Section layout, and Lane Local automation shifts before any checkpoint. One deferred publication prevents the audio thread from observing an intermediate half-shifted song.

Safety boundary: SpaceAge may split preserved silence because silence carries no inaccessible musical source. It does not split a real primary Drum block in the middle because the current chain model has no trustworthy source-offset representation for that half-pattern. The user gets an exact-edge instruction and unchanged history rather than a plausible-looking corruption.

Future extension: The same global-span transaction can power Insert Measures, duplicate song-form blocks, paste-special choices, and future Motion Clip ripple insertion. A later explicit Drum-pattern split feature can relax the edge-only boundary once Drum source offsets have a real model and tests.

Verification: A02-A proves mixed Instrument/primary Drum/secondary Drum/Section insertion, silent-lane shifting, Lane and Clip Local automation, one-step Undo, atomic refusal, and save/reopen. S08-A proves one keyboard paste and preserved clipboard behavior. Neighboring edit, gap, automation, persistence, standalone, and complete-application gates pass; canonical convergence is 38/38.

Subagents: Pasteur mapped the mixed clipboard and primary/secondary Drum ownership defects. Archimedes attacked span calculation, Section crossings, automation ownership, capacity, and snapshot safety. Popper specified the release-gate scenarios and caught the shortcut-contract interaction. Their read-only findings were integrated; none edited files.

2026-08-03 - Delete Removes Music, Not Time

Task: Close A03 by making ordinary Arrangement deletion preserve the complete song timeline across clips, Drum-chain blocks, Sections, and automation ownership.

Creative connection: A preserved gap is not merely an empty rectangle. It is a promise that the rest of the composition remains where the musician placed it. That same promise links delete, replacement paste, orchestration experiments, Section planning, and future SpaceAge Scenes: musical content may change while the song's temporal skeleton remains stable.

Architecture choice: The deletion transaction resolves selected native clips by stable identity and primary Drum blocks by chain projection. Secondary Drum lanes deliberately join the native Arrangement model. Mixed Sections and clips commit together, while Shared Pattern, Clip Local, and Lane Local automation follow their actual owners instead of visual proximity.

Future extension: A later Ripple Delete must be a separately named, previewed command that explicitly shows the amount of time to be removed and every lane, Section, automation curve, and primary Drum block that will move. It must never be hidden behind normal Delete or a modifier users can trigger accidentally.

Verification: A03-A includes an intentionally overlapping unselected sentinel, mixed primary/secondary Drum and melodic clips, Section removal, automation ownership, one-step Undo/Redo, atomic refusal, and persistence. Neighboring A02, A06, and A07 gates, the complete application self-test, and canonical Release convergence 39/39 remain green.

Subagents: Three read-only review roles were prepared for transaction safety, adversarial edge cases, and gate sufficiency. The current subagent dispatcher did not return from initialization on two attempts, so the requests were terminated and those reviews were completed locally rather than left consuming time.

2026-08-03 - A Project Is A Sealed Creative World

Task: Close P02 and P03 by making project load, Save As, and Save Over trustworthy across editor state, processor state, file identity, history, external assets, and failure paths.

Creative connection: A SpaceAge project is more than serialized notes. It is a sealed creative world with one current identity, one Undo timeline, explicit external dependencies, and a complete visual/audible state. Treating load as a true boundary connects project trust to future SpaceAge Scenes, templates, portable project archives, version history, and collaboration: each can deliberately create or adopt a new world without carrying invisible state from the old one.

Architecture choice: Every successful customer load converges on one editor adoption path after the processor accepts the project. Failed loads never enter that path. The processor clears project-local history only after a valid external restore, preserves deliberately disabled shared returns, refuses working-directory-dependent asset references, and records undecodable files for repair.

Future extension: Save As independence is the foundation for named versions and “Load Previous Version.” The same atomic adoption contract can later power project templates, archive imports, cloud copies, and Scene branches. Asset receipts can evolve into a preflight manifest that distinguishes missing, corrupt, relocated, and intentionally external resources before a collaborator presses Play.

Verification: P02-P03-A covers representative state, production editor adoption, source-independent Save As, targeted Save Over, source deletion, unrelated working directory, foreign Undo/Redo clearing, exact effect-enable restoration, corrupt-asset receipts, relative-path refusal, and failed-load isolation. The complete application test and canonical Release convergence pass 39/39 after the changes (reports/p02-p03-project-trust-convergence-20260803.out).

Subagents: Kuhn traced project identity and Undo leakage. Pauli audited effect restoration, asset decoding, and path ambiguity. Harvey designed hostile Save As, source-deletion, failure-isolation, preference, and working-directory scenarios. All three worked read-only; their findings were integrated by LT.

2026-08-03 - Project Loading Is A Trust Conversation

Task: Close P06 by ensuring every project-load gesture is acknowledged immediately, remains honest about progress, blocks conflicting commands, and ends with a readable result.

Creative connection: Loading feedback is not decoration; it is a conversation about custody of the musician's work. The same loading boundary can later serve templates, SpaceAge Scenes, portable archives, sample relinking, Quasar packages, and cloud copies. Every route should tell the same story: “I heard you, I am working on this exact session, and I will either adopt it completely or leave your current work untouched.”

Architecture choice: SpaceAge uses indeterminate progress until restoration has measurable work units. Startup and busy-overlay routes share one command boundary, delayed completion carries a generation token, and success/failure receipts outlive the Arrangement status timer. A remembered path remains available through temporary drive absence. Archive extraction hands directly into a visible activation phase rather than creating a silent gap.

Future extension: Truly smooth large-library loading should stage immutable decoded assets and a validated load plan on a worker, then perform a short atomic message-thread commit. That architecture could provide real work-based progress and cancellation. Moving the current mutable restore call to a worker would be unsafe and is explicitly rejected.

Verification: P06-A, project persistence, and the golden lifecycle pass. Canonical Release convergence is 40/40 with receipt reports/p06-project-load-feedback-convergence-20260803.out.

Subagents: Volta traced every project-load route and found the fabricated elapsed-time percentage plus the archive activation gap. Euler audited message-thread, callback-generation, cursor, and command-boundary risks. Herschel designed the focused acknowledgement, indeterminate-state, stale-callback, command-blocking, and durable-status regression. All three worked read-only; LT integrated and verified the changes.

2026-08-03 - Relinking Is Dependency Repair, Not Guesswork

Task: Close P07 by proving that a project containing every external asset class can be repaired safely after its dependencies move.

Creative connection: Missing-asset repair is the same trust problem as hardware recall, archive import, and future VST scanning: SpaceAge should identify one intended object, explain uncertainty, and mutate only after the identity is unambiguous. A refusal is useful when it protects the musician from silently connecting the wrong snare, bank, loop, or multisample package.

Architecture choice: Folder repair accepts one exact candidate and skips zero or multiple candidates. Quasar discovery paths are deduplicated because one package naturally appears both as a directory and through its manifest. Individual chooser callbacks carry an immutable dependency receipt, so an older callback cannot repair whichever list row happens to occupy the same index later. A successful repair ends with a visible reminder to save the project.

Future extension: The same dependency ledger can grow into a preflight panel showing found, ambiguous, corrupt, and intentionally external assets before opening, archiving, collaborating, rendering stems, or switching SpaceAge Scenes. Checksums and audition previews could later distinguish same-named files without turning automatic repair into a guess.

Verification: P07-C combines velocity layer, one-shot, loop, SoundFont, and Quasar relocation; deliberate duplicate-name ambiguity; unique repair; stale-receipt rejection; finite audio; and repaired-project save/reopen. Existing I04-A and I05-A remain the deeper SoundFont and Quasar audio/release proofs. Canonical Release convergence passes 41/41 in reports/p07-missing-asset-repair-convergence-20260803.out.

Subagents: Three read-only P04/P07/P08 review assignments were attempted, but the dispatcher did not initialize and returned no agent identities. The P07 audit, implementation, and adversarial verification were therefore completed locally rather than left consuming time invisibly.

2026-08-03 - A Clean Exit Is A Runtime Boundary

Task: Close P08 by making normal shutdown, relaunch, standalone startup ownership, and hosted editor reopen one explicit lifecycle contract.

Creative connection: Silence after closing is part of the instrument's trustworthiness. The same ordered boundary protects hardware players from hanging notes, protects songwriters from a stale recording state, protects recovery from false clean-session evidence, and protects the startup experience from an invisible framework snapshot choosing a song on the musician's behalf.

Architecture choice: SpaceAge stops producers, retires musical ownership, drains routed safety MIDI, closes output devices, and only then records a clean session. Standalone startup ignores JUCE's implicit wrapper state and remains governed by SpaceAge's explicit Last/Blank/File decision. Hosted plugin state remains host-owned and skips standalone startup surfaces.

Future extension: This terminal transaction can become the foundation for an honest shutdown-progress surface, cancellable long-job close policy, plugin-scan cleanup, render-journal recovery, and hardware disconnect coaching. Each future runtime owner must join the same ordered exit rather than adding a private destructor guess.

Verification: P08-A begins with active playback, recording, sustain, note ownership, queued future output, and open hardware routes. It proves repeated release is safe, all owners retire, 96 safety messages drain, standalone relaunch begins at SpaceAge's startup choices, and VST3 host state still restores. Canonical Release convergence passes 42/42.

Subagents: Kepler traced shutdown ownership and found the hidden standalone-state and release-order boundaries. Noether designed the adversarial close/relaunch matrix. Sagan audited the visible startup and hosted-editor promises. All three worked read-only; LT integrated and verified the changes.

2026-08-03 - Recovery Is A Project Lifecycle, Not A File List

Task: Close the software contract for discovering, explaining, restoring, and preserving interrupted standalone work without confusing recovery with an ordinary saved project.

Creative connection: Recovery joins startup evidence, project loading, missing-asset repair, Save As, and clean shutdown into one trust loop. The musician does not need to understand snapshot folders. They need SpaceAge to recognize that useful work exists, describe it in human terms, restore that exact creative state, and keep it separate from the last deliberately saved song until they choose a destination.

Architecture choice: The startup chooser and Library share one restore path. Eligibility comes from the complete project model, including sound design, explicit pattern length, routing, Flux, and MIDI state, rather than a display summary. Hosted plugin editors cannot compete for the standalone recovery folder. Unchanged snapshots are discarded before retention is applied, delayed callbacks carry a generation token, and the temporary fallback directory remains part of discovery.

Reusable connection: The same unsaved-adoption state can later serve imported archives, templates, SpaceAge Scenes, older-version rescue, and crash-journal replay. The human timestamp and semantic summary can grow into a version browser without making filenames part of the customer experience.

Verification: P04-C proves snapshot identity, eligibility, retention, malformed-file cleanup, and unrelated-file isolation. P04-D proves startup discovery, broad change eligibility, exact restore, unsaved identity, Last Project preservation, malformed-load atomicity, and independent Save As. Canonical Release convergence includes both gates. Physical forced termination and real missing-library repair remain hands-on Windows QA.

Subagents: Carson exposed narrow eligibility, global hosted-editor ownership, duplicate churn, and fallback-discovery risks. Banach identified the missing startup action, misleading summaries, and unsaved-state wording needs. Lovelace drove generation guards and the hostile interruption test boundary. Their read-only audits were integrated by LT.

2026-08-03 - Patches Describe Instruments; The Mixer Describes The Mix

Task: Close X04 by proving that a native synth patch cannot secretly alter the lane's Mixer effects, level, pan, EQ, mute, output, or routing state.

Creative connection: This boundary lets one sound travel safely through different arrangements. A preset-browser audition, Instrument Bay replacement, SpaceAge Scene, orchestration experiment, stem render, or future AI-created patch can change the instrument without quietly rewriting the mix. Conversely, Mixer templates can reshape a production without corrupting reusable sound design.

Architecture choice: Native patch serialization and loading use engine-specific allowlists that exclude every Mixer-owned parameter. Hostile legacy fields are ignored. Intrinsic source processing remains patch-owned but is labeled VOICE SHAPING; shared reverbs, delays, modulation returns, EQ, gain, pan, mute, and output remain lane/Mixer-owned.

Future extension: The preset browser can expose two explicit operations: replace the Instrument patch, or deliberately apply a separate Mixer-channel preset. SpaceAge Scenes may then store orchestration and mix choices independently, and Quasar/AI patch generation can publish clean instruments that never carry hidden routing.

Verification: X04-A loads adversarial Redshift and Propulsion files through production paths, compares Mixer sentinel state, audits all native patch allowlists, and verifies the customer-facing tab vocabulary. Focused evidence is reports/x04-synth-patch-mixer-ownership-20260803.out; canonical convergence passes 44/44.

Subagents: None ran for this pass. The ownership audit, implementation, and convergence proof were completed locally.

2026-08-03 - Mixer Banks Are Windows, Not Alternate Mixes

Task: Close X01/X02 by proving exact Lane-to-Mixer routing and preserving authored Mixer state across banks, pages, and project restoration.

Creative connection: A Mixer bank is only a window onto a larger console. Changing the visible sixteen channels must feel like looking left or right across the desk, never like loading another mix. That stable identity is foundational for future orchestration Scenes, Mixer templates, stem naming, Instrument Bay audition, and hardware routing: changing the player or the view must not rewrite the room.

Architecture choice: Lane Instruments resolve through their published lane route, while Drum sources retain direct Pad-channel identity. Audio-thread readers consume one immutable Arrangement generation. Bank controls detach completely before being rebound, preventing two channels from briefly sharing one knob. Hidden Solo remains real and disclosed; Reset Audio is the explicit recovery action.

Future extension: The same receiving-bay contract can support channel presets, Scene comparisons, multi-output host buses, and per-lane render receipts. A future overview may disclose every hidden Mute/Solo without changing it, preserving both safety and authorship.

Verification: X01-A exercises four private Instruments routed across four banks with exact meters, pan, channel Mute/Solo, immediate lane Mute/Solo of already-sounding voices, and route round trip. X02-A preserves gain, pan, mute, solo, output, and routing through bank/page changes and project restore. Audio/stem export verifies that rendered metadata follows the same Mixer truth. The exact rebuilt source passes final canonical convergence 46/46 in reports/release-convergence-x01-x02-final-20260803.out.

Subagents: Kierkegaard traced live/isolated routing and exposed private-source fallback, mutable-lane races, stale reset snapshots, and missing stem-state considerations. Pauli traced Mixer parameter ownership and found destructive bank Solo clearing, unsafe delayed restoration, and incomplete persistence evidence. Both worked read-only; LT corrected and verified the production boundaries.

2026-08-03 - Reset Is A Reversible Rescue; Panic Is Runtime-Only

Reset Audio and Panic sound similar to a musician because both can recover a troubled session, but they belong to different authorship layers. Reset Audio deliberately changes Mixer and routing choices, so it must be one visible, reversible Undo transaction. Panic only stops live sound and clears transient MIDI state, so it must never rewrite the song. Encoding that distinction as a regression contract makes future recovery tools easier to classify before they acquire confusing side effects.

The same deterministic audio fixture now connects master-volume safety, limiter transparency, limiter ceiling, loop continuity, and page/bank navigation. This reduces duplicated test setup and gives future DSP work one stable reference signal. A future true-peak limiter can replace the current sample-peak implementation without weakening the surrounding project-volume and continuity contracts.

Subagent note: Curie and Faraday were assigned read-only audio-safety audits, but the dispatcher did not initialize either agent and both stalled spawn attempts were terminated. No unreported subagent result was used; the audit, implementation, and verification were completed locally.

2026-08-03 - Variation Is An Authored Range, Not Chaos

Flux Nodes are strongest when they communicate a musician's intention: which dimensions may move, how far they may move, and how often a new variation may occur. The random value is disposable performance detail; the enabled nodes, ranges, and cadence are authored project data and therefore must save, reopen, copy, reset, and render predictably.

That distinction connects Flux to future Motion Clips without turning either feature into a bag of unrelated randomizers. Both can share the same conceptual grammar: destination, bounded depth, temporal policy, preview, and ownership. Flux remains per-hit drum timbre variation, while Motion Clips can become visible time-authored modulation. The common model is controlled change over time.

Render to Sample creates a useful bridge between generative and fixed workflows. A lively Flux performance can be explored as synthesis, captured as audio when a particular result feels right, then edited, layered, exported, or placed in Quasar without keeping the random engine active. SpaceAge can therefore offer both repeatable project intent and the delight of finding an unplanned sound.

The corresponding engineering rule is precise: persist the authored controls exactly, clamp them at the model boundary, allow the per-hit draw to vary, and never call the random audio itself deterministic unless a future seed is deliberately part of the user contract.

Subagents: Curie and Faraday were assigned read-only audio-safety work earlier in this pass but stalled during initialization and were terminated. No subagent result was used for the Instrument/Drum Lab work.

2026-08-03 - One Control Gesture, One Musical Decision

Task: Close I07 by making native synth controls precise, readable, undoable, and geometrically trustworthy across every engine page.

Creative connection: The same interaction should serve a broad oscillator sweep and the last fraction of filter tuning without asking the musician to change tools. Slow movement now behaves like a precision instrument, faster movement traverses the range, exact text entry remains available, and one continuous drag remains one Undo decision. This control grammar can later support hardware mapping, Motion Clips, and accessibility preferences without each synth inventing another feel.

Architecture choice: One shared helper configures native controls rather than scattering sensitivity constants through engines. A dedicated contract opens all customer-facing pages, including every Redshift and Glass Moon subpage, and inspects visible bounds, labels, readouts, interaction flags, gesture checkpoints, and real Undo behavior. SoundFont's thirteenth control exposed a hard-coded twelve-control grid; the row count now derives from the bank size.

Future extension: User-selectable control sensitivity can become one global preference because the engines already share a policy boundary. The geometry visitor can also become the basis for supported-window and display-scaling screenshots in release QA.

Verification: I07-A passes with 295 visible controls, geometry, fine interaction, readouts, gesture ownership, and Undo. Adjacent native patch, Drum Lab Flux/render, and factory audio gates pass. Canonical Release convergence passes 50/50 in reports/release-convergence-instrument-controls-final-20260803.out; the subsequent complete factory-preset contract raises canonical convergence to 51/51.

Subagents: None ran for this pass. The interaction policy, geometry diagnosis, correction, and full convergence proof were completed locally.

2026-08-03 - A Preset Name Is A Behavioral Promise

Task: Close I03 by auditing every customer-visible factory preset for tuning intent, deterministic recall, parameter safety, voice retirement, and representative CPU headroom.

Creative connection: Categories are part of the instrument's teaching language. A musician choosing Keys, Pads, Plucks, Leads, Organs, or Bells is accepting a promise that ordinary chords will remain musically legible. Texture and Atmosphere may deliberately wander, but their names should announce that freedom. This same category vocabulary can later improve the preset browser, school-oriented guidance, AI patch creation, and automatic audition material.

Architecture choice: The UI itself is the manifest. The safety fixture enumerates each engine's customer-visible ComboBox, rejects invalid indices before production applicators can clamp them, and checks all 619 choices. Every recall must reset shared movement state before applying its recipe. Lunacy's tonal families now clear inherited vibrato and gate settings and use restrained pitch spread; experimental families retain their broader identity.

Future extension: Preset metadata can expose machine-readable promises such as tonal, chord-safe, monophonic, experimental, CPU class, intended register, and audition phrase. The same data can drive browser filtering, target-machine warnings, classroom explanations, AI patch constraints, and regression selection without duplicating engine knowledge.

Verification: I03-A now includes five-unison Propulsion alongside Redshift, four-unison Liftoff, Glass Moon, Moonshadow, Lunacy, SoundFont, and Quasar. I03-B exercises a wet five-lane Arrangement. I03-C checks 619/619 visible factory choices with zero failures. Canonical Release convergence passes 51/51 in reports/release-convergence-preset-safety-final-20260803.out. Human listening and target-machine profiling remain explicit QA.

Subagents: Ramanujan identified Lunacy's inherited vibrato/gate state, tonal-family spread risks, and the highest-cost voice configurations. Aristotle counted the complete 619-choice visible manifest and exposed how clamping applicators could hide stale preset indices. Both audits were read-only; LT integrated the corrections and regression contracts.

2026-08-03 - A Default Patch Is The Instrument's Handshake

Task: Prove that every self-contained factory Instrument says something useful immediately, retires its voices, and tells the same tuning truth through the real lane-owned path that a musician uses.

Creative connection: A default is the first conversation between an Instrument and its player. Audibility is only the floor: the sound should be safe, tuned where tonal, responsive across registers, and clear about whether it is melodic or percussive. This contract can later power Instrument Bay preview phrases, classroom tuning demonstrations, preset metadata, AI patch constraints, and an automatic “healthy Instrument” receipt after installation.

Architecture choice: The fixture loads the first visible preset, opens the engine on a private Instrument Lane, auditions through that lane's source identity, and measures output, pitch, and retirement. SoundFont and Quasar take the asset-backed branch rather than pretending an empty sampler is a failed synth. Lunacy now uses grain age as its sole pitch clock and preserves grain position as a source offset.

Future extension: The Quasar builder should become a first-class production boundary with progress, cancellation, portable names, exact zone mapping, and immediate reload proof. Resource failures should produce typed receipts that distinguish missing, corrupt, unsupported, ambiguous, and unsafe paths while preserving the last valid Instrument state.

Verification: I01-B passes all thirteen self-contained engines; canonical Release convergence passes 52/52 in reports/release-convergence-i01b-20260803.out. Human listening still decides whether each handshake sparks confidence and musical curiosity.

Subagents: Ramanujan identified the untested production Quasar builder as the next producer/consumer boundary. Aristotle identified hostile instrument-resource failure isolation as the highest remaining fully automatable release risk. Both audits were read-only; LT integrated the present gate and recorded their recommendations for the next passes.

2026-08-03 - A Quasar Build Freezes A Sound Into A Portable Instrument

Task: Make production Quasar capture a trustworthy transaction rather than a live feed from an Instrument that may keep changing while the build runs.

Creative connection: One frozen source snapshot lets a musician keep shaping the song while Quasar finishes the sound they actually launched. The published package can then travel into Scenes, seed or preserve an AI-generated patch, and move between collaborators without private paths or machine-specific filenames changing its identity.

Architecture choice: Capture source state once, render every requested root, velocity layer, and round robin into a private staging folder, write the manifest there, and atomically publish the complete package. Cancellation wins only before that commit; after publication, successful completion wins. Progress reaches 100% only after publish, and completion auto-loads the package only when the active source slot, engine, and patch fingerprint still match the launch state.

Portable contract: Sample paths use deterministic ASCII filenames and forward-slash package-relative paths. The manifest and files must prove exact root-range, velocity-layer, and round-robin coverage so sharing a Quasar package means sharing one complete, independently loadable Instrument rather than a partial local capture.

2026-08-03 - An Instrument Replacement Is A Private Audition Before A Public Commitment

Task: Make hostile SoundFont and Quasar files unable to damage a working Instrument while preserving a useful repair workflow.

Creative connection: Loading a new sound should feel like auditioning a candidate, not surrendering the current performance. The same private-candidate/public-commit pattern can protect future VST scans, imported sample maps, archive contents, AI-generated patches, Scene orchestration choices, and hardware-editor setup files.

Architecture choice: SoundFont receives bounded structural preflight before its third-party parser. Quasar receives strict manifest typing, path containment, finite-range checks, aggregate decode budgets, and complete sample preparation. Only a fully prepared candidate replaces live state. Cross-engine publication explicitly retires the stale external engine, and asynchronous repair receipts carry a project epoch.

Future extension: Failure receipts should evolve from a generic rejection into typed, actionable guidance such as corrupt table, unsupported version, unsafe path, missing sample, or allocation limit. The transaction boundary remains the same even as the explanation improves.

Verification: The hostile matrix proves malformed/truncated SF2, malformed/unsafe/corrupt Quasar, failed-replacement preservation, later valid replacement, cross-engine exclusivity, save/reopen, repair, and ABA-stale receipt rejection. Focused receipt: reports/hostile-instrument-resource-i08b-final.out. The subsequently strengthened same-project reload coverage is canonical in reports/release-convergence-i08c-final-20260803.out at 54/54.

Subagents: Pascal audited parser trust, cross-engine stale-state risks, receipt lifetime, cumulative decode bounds, and lane ownership. Godel audited the release, beta, QA, gotcha, creative, and whiteboard evidence surfaces. Both were read-only; LT integrated the implementation and documentation.

2026-08-03 - A Broken File Does Not Have To Silence A Living Instrument

Task: Close the same-project reload gap left after hostile replacement isolation: an external SoundFont or Quasar is already decoded and audible, its disk file becomes corrupt, and the musician reloads the project without leaving the session.

Creative connection: The decoded Instrument is not merely a cache; during a repairable failure it is the musician's last known-good performance object. SpaceAge can preserve creative continuity while still telling the truth about the broken disk asset. This same keep-playing/repair-later language can later protect sample maps, VST state, hardware librarian snapshots, Scene orchestrations, and cloud assets.

Architecture choice: Restore snapshots live external resources before clearing mutable project fields, validates the incoming disk candidate privately, and republishes the snapshot only for the exact same resource identity. The repair flag keeps the missing-asset receipt alive even though audio remains available. Unclaimed caches are retired after adoption, and Quasar round-robin cursors remain part of the retained performance state.

Verification: The strengthened hostile-resource matrix corrupts a live SoundFont and Quasar in place, reloads the same saved project, and proves exact cache generations, serialized state, lane/Instrument ownership, Mixer/MIDI routing, finite audio, two independent receipts, independent repair, and final audible recovery. Focused receipt: reports/hostile-instrument-resource-i08c.out; canonical Release convergence remains 54/54 in reports/release-convergence-i08c-final-20260803.out.

Subagents: Pascal found the premature SoundFont cache retirement and the Quasar cursor-state omission. Godel challenged project-adoption atomicity, cache ownership, receipt typing, and history boundaries. Both worked read-only; LT integrated the repairable-project contract rather than rejecting an otherwise usable project.

2026-08-03 - An Effects Rack Must Prove Every Door Opens

Task: Extend X03 from its three flagship returns to every shared effect that a musician can enable and feed from a Mixer channel.

Connection: Halostar, Reverb, and EchoRay legitimately need tail evidence because their musical identity includes sound after the source stops. Chorus, Flanger, Phaser, Tremolo, and Octave are transformations of active input; requiring a reverb-style tail from them would encode the wrong product behavior. The shared regression therefore uses one routing and finiteness contract while applying effect-family-specific acceptance: audible tail plus character response for ambience/delay, and audible transformation plus control response for modulation/pitch effects.

Creative extension: This same effect-family metadata can eventually drive customer-facing help, render-tail policy, CPU sleep behavior, and preset categorization. One truthful classification can therefore improve testing, workflow language, and realtime efficiency instead of becoming test-only knowledge.

2026-08-03 - A Render Is A Second Performance Of Frozen Truth

Task: Promote whole-song export from file-shape evidence to live/offline musical parity.

Creative connection: Offline export is a second performance of one frozen project state. It should agree with live playback in timing, routing, gain, pan, automation, effects, and silence boundaries. The production exporter and audio callback may run at different speeds, but they should tell the same musical story.

Future extension: Every long-running derivation can carry a source-state identity. WAV renders, stems, Quasar captures, freeze operations, and future Scene bounces could report which immutable state they rendered. That identity makes stale completions rejectable and gives support diagnostics a precise answer to “what version of the song produced this file?”

Verification: X05-A compares normal processBlock output with the production 24-bit WAV from the same captured state, proves late material and a Halostar tail, and preserves an existing destination when cancelled. Focused receipt: reports/x05-offline-render-parity-20260803.out.

2026-08-04 - A SoundFont Is A Library Of Performers, Not Merely A File That Opened

Task: Strengthen the SoundFont release contract without turning Shane's private library into a test dependency.

What connects creatively: SoundFont preset identity belongs to the same lane-owned Instrument truth as Redshift patches, Quasar packages, Hardware Passports, and future VST presets. A file-path success is only the outer shell. The musician needs the named performer, the selected program, its source controls, its Mixer route, and its recovery identity to agree after save, reopen, and relocation.

Architecture choice: The generated fixture now contains three independently selectable presets with deliberately different audio levels over a moderate sample payload. The gate isolates cutoff, attack, decay, sustain, and release through normal audio rendering, then saves the selected preset, trigger mode, and patch controls before exercising missing-file repair. Relink must reproduce peak, early/mid RMS, and the retirement block rather than merely producing any sound. Large real banks stay in human QA because synthetic size inflation cannot honestly prove vendor-bank character, disk behavior, or performance on release hardware.

Verification: Focused I04-A evidence is recorded in reports/i04-soundfont-controls-final-20260804.out; the exact source then passed canonical 54/54 Release convergence in reports/release-convergence-i04-controls-final-20260804.out.

Subagent challenge: Pascal worked read-only and found that the first three-preset fixture changed names without proving program-dependent audio, combined several filter variables, measured only attack behavior, accepted any post-relink sound, and covered only the upper clamp. The final contract closes all five evidence gaps instead of lowering its thresholds; Pascal's final read-only audit found no remaining material gap in that matrix.

2026-08-04 - A Release Manifest Should Behave Like A Patch Receipt

The same principle that protects a musician from a stale SoundFont relink should protect Sample Squad from a stale license assumption. A dependency name in a Markdown table is helpful memory, but it does not prove that the reviewed header, font, or notice is still the file entering the build. The new dependency manifest therefore joins identity, purpose, license, source URL, repository path, and SHA-256 evidence into one checkable record.

This connects legal provenance to SpaceAge's existing ownership language. Clips know their lane, Instruments know their Mixer route, automation knows its owner, external assets know their repair receipt, and now third-party code knows its license receipt. A future JUCE, VST3, font, or SoundFont-engine update must become an explicit reviewed transaction instead of silently inheriting yesterday's paperwork. Human rights decisions remain human; the software's job is to make it hard to forget, substitute, or package around them.

2026-08-04 - A Public Build Is A Verifiable Claim

Task: Turn release packaging from file copying into a fail-closed statement about exact source, exact binaries, and documented rights.

What connects creatively: SpaceAge already treats a saved song, rendered stem package, Quasar instrument, and missing-asset repair as evidence-bearing objects. A public build deserves the same treatment. The archive should explain where it came from and what it contains instead of asking the customer to trust a timestamped folder name.

Architecture choice: Dependency evidence, embedded assets, and customer binaries are SHA-256 bound. The JUCE fallback names an exact commit. Packaging refuses dirty source, blocked assets, incomplete legal approval, stale product identity, or a copied executable that cannot launch. A generated release manifest binds the archive to its source commit, runtime expectations, binaries, notices, and human signoffs.

Future extensions: The same receipt can anchor code signing, installer verification, update channels, crash-report build IDs, reproducible-build comparison, and a public checksum page. Factory preset provenance is deliberately separate because technically valid parameter values do not prove authorship.

2026-08-04 - A Preset Library Is Part Of The Instrument Binary

Task: Make the factory collection an exact release artifact instead of a remembered count.

Creative connection: A preset is customer-facing behavior encoded as data. Treating the 619 presets like source and sample assets means a release can answer which sounds it shipped, detect accidental edits, and later support trustworthy preset-library updates without confusing them with application updates.

Architecture choice: The safety sweep deterministically hashes bank identity, ordered preset identity, and sorted normalized parameter state. The same fingerprint lives in runtime verification and a package inventory; the package manifest then SHA-256 binds that inventory to the archive. Human authorship stays a separate signoff because byte identity cannot establish creative rights.

Verification: Two independent Release processes each checked 619 presets with zero failures and produced FNV-1a-64 fingerprint b6081fe2b9d1f579.

2026-08-04 - A Public Package Must Not Remember Yesterday's Binary

Task: Remove the public-package stale-build escape hatch and make Windows runtime dependencies explicit.

Creative connection: The same exact-source rule that protects a project from stale asynchronous receipts should protect the customer archive from stale build-tree state. Runtime imports are also part of product truth: support should know what a clean machine must provide before a customer discovers it by failure.

Architecture choice: Development tests may still reuse a freshly verified executable, but public packaging always rebuilds after clean-commit verification. PE import inspection rejects unknown DLL dependencies, requires the reviewed Visual C++/Universal CRT family, and writes the observed imports into the release manifest.

2026-08-04 - Trust The Archive, Not The Staging Folder

Task: Prove the finished ZIP still contains the exact release that passed preflight.

Creative connection: Compression is another publication boundary, much like saving a project, rendering a song, or building a Quasar Instrument. Success before that boundary does not prove the published object survived it unchanged. Treating the archive as newly arrived, untrusted input reuses SpaceAge's private-candidate/public-commit philosophy at the final commercial boundary.

Architecture choice: Reopen the ZIP, reject unsafe paths and expansion abuse, verify exact source identity, re-hash all customer binaries and release evidence, confirm runtime imports are recorded, then publish a SHA-256 sidecar. The synthetic test deliberately corrupts the executable after manifest creation and requires rejection.

Hardening extension: Every staged file now has canonical path, byte size, and SHA-256 evidence. Exact set equality rejects accidental private notes or stale payloads. Random private staging and .partial.zip publication prevent an unverified archive from looking final, while extracted binaries repeat identity, dependency, VST3-structure, and launch checks.

2026-08-04 - Prove The Framework, Then Prove The Exact Box

Task: Remove the last trust-by-filename assumptions from the JUCE dependency and final human release approval.

Creative connection: A synth preset, a project archive, a dependency tree, and a customer ZIP are all versions of the same idea: named objects whose names are weaker than their contents. SpaceAge's strongest workflows already bind intent to exact state. Applying that philosophy to the framework and release approval makes commercial governance feel like the rest of the product architecture rather than separate paperwork.

Architecture choice: The complete local JUCE tree is fingerprinted after an independent comparison with its official pinned commit, then rechecked offline before every public build. Pre-build rights decisions have stable IDs that cannot be silently deleted; post-build approval is a different record generated with the exact ZIP name, SHA-256, and source commit. Toolchain identity travels in the release manifest without exposing the developer's private filesystem path.

Exact-source extension: Public packaging also consumes the detached clean-checkout convergence receipt for the same commit, copies it into the archive, and binds it by SHA-256. This joins source isolation, build evidence, and final archive review into one traceable chain without pretending that any single gate proves all three.

Future connection: The same attestation shape can later bind Authenticode signatures, installers, update-channel metadata, public checksum pages, and reproducible-build comparisons.

2026-08-04 - One Honest Release Answer

Task: Replace scattered release warnings with one read-only candidate-status report.

Creative connection: SpaceAge's MIDI Health work proved that deep technical state becomes useful only when the musician or maintainer can see one honest summary and the next concrete action. Release governance needs the same design language. The status command does not weaken any gate; it translates them into a single answer that can later power a non-technical release dashboard.

Architecture choice: The report derives source cleanliness, exact-SHA convergence evidence, JUCE source proof, asset clearance, legal approval, and binary identity from their canonical validators. It never creates a build, edits a signoff, or invents progress. JSON output is available for a future GUI while the plain report remains usable by humans and agents today.

2026-08-04 - Reproducible Meaning, Not Matching ZIP Timestamps

Task: Prove that two independently built release candidates contain the same product even when container timestamps differ.

Creative connection: Musical rendering distinguishes the composition from the wrapper file carrying it. Release comparison should do the same. Byte-identical ZIPs are useful but are not the only honest test; the commercially meaningful invariant is identical customer binaries, evidence, runtime requirements, and package contents from the same source and toolchain.

Architecture choice: Both archives first pass the complete hostile-input validator. Their manifests are then normalized without generatedUtc or ZIP metadata and compared exactly. A stable payload fingerprint records the result while separately reporting whether the ZIP bytes themselves happened to match.

Proof refinement: The contract test now creates two independently compressed candidates whose generation timestamps deliberately differ, proving that harmless packaging time does not create a false failure. It also creates a third otherwise-valid candidate with changed toolchain evidence and requires the comparator to reject it. This guards both sides of the promise: irrelevant container variation is tolerated, while commercially meaningful drift is not.

2026-08-04 - One Readiness Ledger, One Truth

Task: Prevent release decisions from relying on a checklist whose prose and checkboxes silently contradict one another.

What connects creatively: SpaceAge already treats musical routing, archive contents, and dependency evidence as typed contracts. Release readiness deserves the same discipline. The nine eight-item groups now form one canonical 72-ID ledger, while detailed human observations remain supporting evidence rather than duplicate pseudo-checks.

Architecture choice: test-release-readiness-ledger.ps1 requires exactly one instance of every P01..R08 ID, reports PASS/open totals, and can enforce complete closure. The consolidated candidate report consumes that structured result, so a candidate cannot be reported ready merely because legal and archive gates pass while musician-facing QA remains open.

Publication boundary: The public packaging command invokes the ledger with -RequireComplete. This does not obstruct ordinary developer builds or test binaries, but it makes the customer archive a deliberate promotion event: the package cannot outrun the human MIDI, UI, host, installer, rights, and documentation evidence represented by those 72 decisions.

2026-08-04 - Embedded Brand Art Is a Product Boundary

Task: Remove the deprecated external splash-folder workflow and make the release privacy promise enforceable.

What connects creatively: Splash rotation and commercial asset protection are the same design problem. SpaceAge can retain visual variety by alternating between compiled first-party images without teaching the executable to ingest arbitrary marketing artwork from Documents, OneDrive, or folders beside the binary.

Architecture choice: SplashPanel now selects only from BinaryData and stores only the previous numeric choice. test-release-resource-privacy.ps1 proves both images remain embedded, external override vocabulary is absent, and common private-development path signatures do not appear in shipping source. This gate is part of release hygiene and the detached clean-checkout dependency set.

2026-08-04 - Support Evidence Must Agree With Startup Truth

Task: Include prior-session interruption evidence in the support bundle without turning it into a privacy risk or pretending SpaceAge captured a crash stack.

What connects creatively: The startup chooser and support workflow observe the same lifecycle event for different reasons. Startup uses it to offer recovery; support uses it to distinguish an ordinary close from an interruption. Sharing the typed state prevents contradictory customer guidance while preserving the honest boundary that an interruption is not automatically a diagnosed crash.

Architecture choice: BundleContext carries an enum rather than free-form text. The archive advances to the closed spaceage-support-v3 schema and emits one allowlisted value under application.previous_session_state; the focused support test requires that value alongside the exact three-file archive contract. This improves actionable diagnostics without admitting exception messages, project identity, hardware names, or private paths.

2026-08-04 - Progress Is A State Contract Before It Is An Animation

Task: Close the release check for long-operation progress without confusing automated state proof with human perception QA.

What connects creatively: Project restore, whole-song rendering, and Quasar capture are three versions of the same publication workflow: acknowledge intent, expose honest in-progress state, reject stale completion, preserve the previous good destination when cancelled or failed, and publish success only after commit. A shared readiness vocabulary lets support distinguish missing progress plumbing from progress that merely needs visual refinement.

Architecture choice: The Beta Readiness model now exposes three typed, completed progress rows tied to P06-A, X05-A, and I05-B. The model records the exact software proof and a separate large-work human follow-up for each operation. U06 closes on those production contracts while viewport readability, responsiveness, wording, and cancellation feel remain explicitly open in the Human Beta QA Matrix.

Verification: The MIDI project-readiness self-test requires all three row identities, zero software-contract gaps, the ready status, and the retained genuinely-large-work disclaimer. The canonical 72-check ledger must move by exactly one check, from 49/72 to 50/72.

Subagents: None used. This pass integrated existing production evidence locally so no delegated task could silently reinterpret release status.

2026-08-04 - Public Copy Is A Versioned Product Surface

Task: Prevent historical development prose and aspirational feature language from becoming accidental customer claims.

What connects creatively: A public sentence can drift just like a preset, dependency, project asset, or release binary. Binding customer copy to exact bytes and typed evidence lets SpaceAge apply the same state-integrity discipline to marketing that it already applies to audio, MIDI, and packaging.

Architecture choice: The obsolete changelog-style shipping README was replaced with a concise beta document. Present-tense claims cite only passed IDs in the canonical 72-check ledger. Conditional Instrument and MIDI statements cite the open checks that constrain them and must retain their qualifiers. Future protocol and plug-in-hosting boundaries are explicit negative statements. Internal marketing, synth-lineup, and feature-outline documents carry non-public disclaimers and exact hashes.

Publication boundary: test-public-claims.ps1 validates the complete reviewed source inventory, hashes, exact claim text, evidence state, qualifiers, and future boundaries. Public packaging additionally requires human approval and includes the claims registry and audit in its release evidence. R08 remains open until the actual README, About, website/store/Kickstarter, manual, and release notes are compared by a human.

Subagents: None used. The stale shipping README and evidence mapping were inspected and corrected locally.

2026-08-04 - Crash Evidence Should Be A Flight Phase, Not Surveillance

Task: Make support evidence more useful after an interrupted SpaceAge session without collecting the musician's work or claiming a crash diagnosis that the app does not possess.

What connects creatively: SpaceAge already treats startup recovery as an honest state transition. The support bundle can use that same truth as a small flight recorder: did the process start, did audio prepare, did the editor become ready, did the app reach steady state, or had shutdown begun? That immediately narrows a support conversation while remaining comprehensible to a musician.

Architecture choice: The standalone writes only a fixed lifecycle enum and timestamps through atomic marker replacement. Support schema spaceage-support-v4 exposes the prior clean/interrupted state and the last completed stage. It deliberately excludes exception prose, stack traces, project content, MIDI content, hardware names, asset names, and private paths. Older v1 markers remain readable, while new evidence uses the v2 session-marker schema.

Future extensions: The same closed vocabulary can guide recovery wording, startup-health QA, installer/update transactions, long render journals, and a future support assistant. Any richer crash system should remain opt-in and independently privacy-reviewed rather than silently expanding this small contract.

Subagent note: No subagent was used for this focused lifecycle-evidence pass; implementation, privacy review, tests, and documentation stayed together to avoid schema drift.

2026-08-04 - Support Needs The Buffer Truth, Not The Studio Identity

Task: Make a support report distinguish standalone from hosted operation and expose the actual sample-rate/block-size conditions behind audio and MIDI feel.

What connects creatively: A reported 2.67 ms block is useful, but 48 kHz at 128 samples is the actionable fact an engineer or guided setup assistant can compare with the user's audio settings. Likewise, hosted explains an ownership boundary without collecting the DAW's name. These facts connect MIDI latency troubleshooting, audio setup, lifecycle evidence, and future first-run guidance.

Architecture choice: Advance the closed support contract to spaceage-support-v5 with one fixed runtime enum and two numeric audio-format fields. Keep host names, audio-device names, hardware identities, projects, musical content, and paths outside the API entirely.

Future extensions: A future support viewer can translate these facts into plain guidance such as "128 samples is suitable for live input" while keeping diagnosis separate from evidence. The same fields can inform a setup wizard without creating another source of audio-state truth.

Subagent note: No subagent was used; the schema, producer wiring, privacy boundary, regression, and documentation were changed together.

2026-08-04 - Minimum Size Is A Product Contract

Task: Stop native Synth Engine pages from passing UI tests only because the test window is unusually roomy.

Creative connection: A supported viewport is like an advertised polyphony count: it is a customer promise, not a suggestion. The same route manifest that keeps Instrument pages discoverable can drive a visual contract across every engine and subpage, turning one-off screenshot complaints into repeatable coverage.

Architecture choice: Run the native control-quality sweep at both 1800x1000 and the declared 1100x800 minimum. Inspect every visible slider, selector, button, and meaningful label for containment while retaining fine-drag, readable-value, gesture, and Undo checks. The resulting 590-control sweep exposed Liftoff's fixed-width fifth selector and justified a responsive five-column layout.

Future extension: Reuse this viewport matrix for Effects editors, Settings, automation popups, Arrangement badges, Mixer strips, startup dialogs, and localization stress strings. Automated geometry should narrow human QA to comfort and aesthetics, never claim to replace eyesight.

Subagent note: No subagent was used. The failing minimum-size proof, responsive correction, rerun, and evidence update stayed in one ownership path.

2026-08-04 - Doorways Must Share The Airlock

Task: Keep every customer doorway in the Sequencer Settings root reachable at the minimum supported window size.

Creative connection: Settings is the launch bay for SpaceAge's deeper MIDI and workflow systems. A button that exists in code but is pushed beyond the panel is functionally the same as a disconnected hardware port: the capability is present but the musician cannot reach it.

Architecture choice: Replace fixed doorway widths with responsive row columns, then probe the real production Settings component at 1100x800. The contract checks 39 visible controls for containment and preserves practical button hit targets instead of relying on duplicated layout arithmetic or screenshots alone.

Future extension: Reuse this production-component probe for deep MIDI pages, Effects editors, automation popups, startup dialogs, and any future Instrument Bay browser. Geometry should establish reachability first; human QA then judges comfort, hierarchy, and language.

Subagent note: No subagent was used. The production layout, focused regression, full convergence run, and evidence updates stayed in one ownership path.

2026-08-04 - Release Proof Must Run On The Release Machine

Task: Restore release-hygiene verification under the Windows PowerShell and .NET runtime actually available on the development machine.

Creative connection: A legal fingerprint that only works in a newer shell is not a dependable release lock. Tool compatibility is part of product reproducibility: another maintainer should be able to verify the same source tree without first guessing which modern runtime supplied one convenience method.

Architecture choice: Replace newer static hexadecimal/hash helpers with longstanding BitConverter, SHA256.Create, and ComputeHash equivalents in the release scripts. Re-fetch the pinned official JUCE commit, compare all 4,249 files directly, and record the resulting cross-runtime fingerprint rather than weakening or skipping verification.

Future extension: Keep release scripts compatible with stock Windows PowerShell unless a newer runtime becomes an explicit, packaged build prerequisite. Exact framework source, legal evidence, and candidate reproducibility can then remain one repeatable chain.

Subagent note: No subagent was used. Compatibility repair, official-source verification, manifest correction, and hygiene rerun stayed together.

2026-08-04 - Keep The Instrument Panel Large, Move The Viewport

Task: Make oversized Settings destinations reachable without shrinking their readable controls.

Creative connection: A deep control panel and a small application window should not fight over which one gets to remain usable. The same viewport idea used for long musical timelines applies here: preserve the meaningful object at its natural scale and move the viewing frame around it.

Architecture choice: Cap the Settings callout shell at 1040x740, keep destination panels at their natural dimensions up to the current 1320x940 designs, and let a viewport provide horizontal or vertical access only when needed. Route all 13 deeper Settings destinations through this one shell so new pages cannot quietly invent another clipping policy.

Future extension: Reuse the shell for unusually deep Effects editors, future Instrument Bay browsers, support diagnostics, and any panel whose readability matters more than forcing everything into one static rectangle.

Subagent note: Two read-only sidecar assignments were attempted, but the subagent dispatcher stalled before returning agent IDs. No delegated result was produced; implementation, verification, and documentation were completed locally.

2026-08-04 - Overview Should Be A Calculation, Not A Costume

Task: Make the Arrangement overview show the whole song at the largest practical scale without needlessly shrinking ordinary lane stacks.

Creative connection: Overview is not a special visual mode so much as a framing decision. The composer wants the largest readable version of the complete object, whether that object is four lanes or sixteen. Treating overview as measured framing connects FIT, O, Ctrl+O, Shift+4, project-load fitting, and future zoom-to-selection behavior under one expectation.

Architecture choice: Exercise all four customer entry points through the production editor. Preserve the full 88-pixel lane height whenever the viewport can hold it; otherwise divide the available height across the actual lane count, use compact chrome only below its readability threshold, fit the authored song width, and return to the timeline origin.

Future extension: The same maximum-useful-scale rule can govern Piano Roll fit, waveform editors, automation views, score pages, and future Motion Clip editors. The visible result should always answer: what is the largest truthful view of the material the user asked to see?

Subagent note: Two read-only audits were assigned, but the dispatcher stalled before returning agent IDs. No delegated work was produced; the overview contract, focused gate, full convergence run, and evidence update were completed locally.

2026-08-04 - State Is A Promise, Not Decoration

Task: Prove that Arrangement lane selection, MIDI input arm, Mute, and Solo communicate different truths rather than merely changing internal flags.

Creative connection: A lane badge is the composer's compact status surface. Selection answers where the next edit lands, MIDI arm answers where a performance goes, and Mute/Solo answer what reaches the mix. Treating those as one visual-state vocabulary connects Arrangement workflow, live recording confidence, Mixer expectations, and future accessibility themes.

Architecture choice: Render the real production Arrangement canvas for neutral and selected states, then drive the production arm, Mute, and Solo controls. Compare actual rendered badge pixels and published control colours and wording, while restoring the lane state after the probe. Keep the test tolerant of theme evolution by checking meaningful distinction rather than one frozen hex value.

Future extension: Apply the same state-truth contract to page tabs, record/count-in, Mixer and Effects enablement, automation ownership, disabled controls, and future theme packs. Automated distinction should guard regressions; human beta still decides whether the hierarchy is attractive, comfortable, and immediately legible.

Subagent note: No subagent was used. The production render probe, focused gate, canonical convergence, and evidence updates stayed in one ownership path.

2026-08-04 - Reproducibility Includes The Sort Order

Task: Make the JUCE source lock produce one answer under both stock Windows PowerShell and PowerShell 7.

Creative connection: A release fingerprint is a tiny score for an enormous source tree: identical notes in a different traversal order still produce a different performance. Making path order explicit connects dependency provenance, clean-machine builds, legal evidence, and future AI-agent maintenance under one reproducible rule.

Architecture choice: Normalize every relative path, sort with StringComparer.Ordinal, and only then feed path, length, and file hash records into SHA-256. Verify the result in both PowerShell runtimes and against a fresh checkout of the exact official JUCE commit instead of blessing whichever hash one machine happened to emit.

Future extension: Use the same ordinal-record pattern for any future dependency, factory asset, preset, or release archive inventory that must remain stable across machines and shells.

Subagent note: No subagent was used. The mismatch was diagnosed from the captured release receipt and resolved across both verifier implementations and their documentation.

2026-08-04 - Navigation Must Publish Ownership

Task: Make the primary page row and shared Effects toggles communicate active ownership without relying on memory or page content.

Creative connection: A top-level page button is the application's map legend. If PADS and SEQUENCERS retain the same appearance after navigation, the user must infer location from the content below. Publishing one active state connects navigation confidence, note-input identity, future themes, keyboard focus, and accessibility under one reusable state rule.

Architecture choice: Keep PADS and SEQUENCERS in the requested blue note-input family, but give their active state a measured brighter value. Give every other public page one active orange state and one idle state, and publish that truth through both the visible colour and the JUCE toggle state. Apply the same off/on vocabulary to all eight shared-effect enable controls. The production regression cycles all six public pages, requires exactly one visible and active owner, and measures active/inactive colour separation rather than freezing the theme to one screenshot.

Future extension: Reuse this contract for record/count-in controls, disabled-state alpha and wording, Mixer processors, automation write/read ownership, popup modality, and theme packs. The component state and the pixels should always tell the same story.

Subagent note: No subagent was used. The navigation policy, Effects state styling, focused contract, 58-gate canonical convergence, and evidence updates remained one tightly coupled change.

2026-08-04 - An Effects Editor Is A Small Instrument Surface

Task: Turn the Effects detail pages from screenshot-reviewed layouts into production geometry contracts at every supported viewport.

Creative connection: A deep effect editor and a synth page solve the same human problem: many meaningful controls must remain readable, reachable, and visibly grouped without losing musical context. The same containment language can serve future Orbit racks, Motion Clip editors, device panels, and parametric EQ detail views.

Architecture choice: Audit the real EffectDetailOverlay after its production resized() pass rather than duplicating its geometry in a test. Open all eight effects through the customer callback at 1800x1000 and 1100x800; require panel containment, minimum target sizes, label/control separation, and correct EchoRay section ownership. Keep human readability and Windows scaling open because component rectangles cannot judge visual comfort.

Future extension: Promote the audit vocabulary into a reusable popup-surface helper once a second complex overlay needs the same checks. Add screenshot-difference evidence only after the visual theme is stable enough that pixel changes carry meaning rather than creating noisy tests.

Subagent note: No subagent was used. The component audit, focused gate, 59-gate convergence run, and release evidence were one cohesive change.

2026-08-04 - Focus Modes Should Exchange Surfaces, Not Crush Them Together

Task: Make Automation ROW VIEW genuinely focused and protect its layout with production-path regression proof.

What connects creatively: A focus command is a promise to trade peripheral information for working space. Merely shrinking the hidden information to zero while continuing to draw it creates visual debris and breaks that promise. The same principle applies to Mixer detail panels, Piano Roll zoom-to-selection, collapsed Arrangement lanes, full-screen sample views, and future Motion Clip editors.

Architecture choice: Focused Automation mode now stops painting after the selected-lane scope and insert panel. The regression opens the real Settings doorway, exercises compact and focused modes, audits 29 controls plus the scrolling shell, and separately checks painted-area contracts that child bounds cannot reveal.

Future extensions: Give every future focused view an explicit surface inventory: what remains, what disappears, what expands, and how the user exits. Reuse that inventory in both layout code and automated geometry tests so a focus mode cannot quietly become a pile of zero-height leftovers.

2026-08-04 - Scroll Before You Crush; Paint What You Lay Out

Task: Make the Mixer and startup chooser remain trustworthy at SpaceAge's minimum supported viewport.

Creative connection: A dense workstation should preserve the musician's control vocabulary even when the window shrinks. Mixer strips, Instrument Bay cards, Library records, Piano Roll inspectors, and future Motion Clip editors all benefit from the same rule: protect a readable unit, then reveal more units through scrolling. The startup chooser adds a companion rule: the visual container and the interaction container are one promise, so painting and layout must derive from the same geometry.

Architecture choice: Mixer strips retain an 80-pixel minimum owner width and the viewport scrolls when sixteen channels exceed the available width. The Master column adopts a compact vertical rhythm without collapsing controls. StartupChoicePanel exposes one responsive card boundary used by painting, layout, and regression inspection.

Verification: U01-C audits 2,306 Mixer controls and U01-D audits 20 startup/loading controls at roomy and minimum viewports. Canonical Release convergence passes 63/63 in reports/release-convergence-u01-library-layout-20260804.out.

Subagents: Hopper and Sagan were assigned read-only startup-dialog and Library audits, but the delegation service stalled before either task started. They produced no findings and changed no files. LT completed the Mixer and startup work locally.

2026-08-04 - A Library Should Read Like A Decision Tree

Task: Preserve the Library's save-first hierarchy while making every project, bank, recovery, starting-point, and generated-project action usable at the supported minimum viewport.

Creative connection: The Library is not merely a file list. It is the project's memory desk: save current work, manage files, recover work, then choose a starting point. Responsive grouping lets that same hierarchy serve a future Instrument Bay preset browser, sample metadata browser, template chooser, and SpaceAge Scene manager without becoming one endless menu axis.

Architecture choice: Keep Save Kit / Project as a centered hero action. Place secondary actions into semantic responsive grids with roomy and compact column counts rather than shrinking every control into one fixed row. Test the production page at both 1800x1000 and 1100x800, including containment, minimum dimensions, and pairwise overlap.

Verification: U01-E audits 58 Library control instances and passes its focused LIBRARY_LAYOUT gate. Canonical Release convergence passes 63/63 in reports/release-convergence-u01-library-layout-20260804.out.

Subagents: Hopper was assigned a Library wording/hierarchy audit and Sagan a minimum-viewport geometry audit. The delegation service stalled before returning task IDs, so neither agent started or changed files. LT completed the implementation, tests, convergence run, and documentation locally.

2026-08-04 - Chord Pan Is Performance Motion, Not A Mix Move

Task: Document the completed per-ChordClip tempo-synced Chord Pan surface in the Chord Performance popup.

Creative connection: Static pan gives a chord its place; motion lets that place breathe with the song. Treating the static value as the motion center makes the feature feel like part of the Chord performance alongside strum, voicing, and arp behavior, while leaving the lane's actual mix position alone.

Architecture choice: Each ChordClip owns its static pan plus motion on/off, synced rate, depth, and shape. Rate selection reuses SpaceAge's shared tempo-grid language: bars, whole, half, quarter, eighth, and sixteenth values with dotted and triplet variants. The shared division model keeps popup labels, real-time playback, MIDI export, and offline audio rendering on one musical clock instead of creating a private Chord-only timing table.

Confirmed behavior: The Chord Performance popup edits the complete recipe, and APPLY TO ALL propagates it across ChordClips as one undoable/redoable project operation. Save/reopen preserves it; Clone retains the linked score behavior; Variant copies the complete recipe into its independent fork. Playback applies shaped depth around the static-pan center, MIDI export writes the motion as CC10, and audio render reproduces the audible movement.

Ownership boundary: Chord Pan is clip performance modulation, never Mixer or lane pan. It must not rewrite, automate, or masquerade as a lane, Instrument, pad, or Mixer balance control.

2026-08-06 - One Start Command Should Have One Meaning Everywhere

Task: Put the Measure-1 control before every active transport cluster and remove horizontal scrolling from the Automation editor.

Creative connection: Transport confidence and editor legibility solve the same workflow problem: the musician should never have to reinterpret a familiar action because the current page changed. The 1 button, keyboard 1, Piano Roll, Drum Composer, and Arrangement now share one measure-one command. Automation keeps its full designed width, so drawing and reading expressive data no longer requires sideways navigation.

Architecture choice: Reuse returnArrangementPlayheadToMeasureOne() rather than introducing page-local transport state. Preserve the Automation editor's 1320-pixel working surface and widen the shared callout ceiling to 1360 pixels; smaller popups remain unchanged, while vertical scrolling remains available on shorter screens.

Future extension: Treat transport actions as shared commands with multiple views, not separate per-page implementations. Apply the same responsive-surface rule to future Motion Clip, Instrument Bay, hardware editor, and parametric-EQ popups: fit the primary work axis, then scroll only the secondary axis when necessary.

Subagent note: Two delegation attempts were made for independent read-only audits, but the subagent service did not return task IDs. No subagent changed files; LT completed the implementation and regression work locally.

2026-08-06 - Release Confidence Must Be Visible Inside The Product

Task: Give Settings a direct Beta Readiness doorway backed by the same structured release-gate object used by automated tests and project-health reporting.

Creative connection: SpaceAge already knows which parts of the product are software-proven and which still need ears, hands, hardware, files, or legal signoff. Making that knowledge visible turns release preparation into an in-app workflow instead of a hunt through engineering documents. The same pattern can later serve instrument listening passes, clean-machine checks, hardware passports, support triage, and post-beta release candidates.

Architecture choice: Render MidiProjectHealthSummary::betaReadinessGate() directly. The Settings panel must not calculate its own readiness status or maintain a second checklist. It presents each blocker, its authoritative status, and its next action; a cold-copy action exports the complete structured checklist without changing project data, routing, MIDI, or hardware. MIDI-specific diagnosis remains a separate doorway into MIDI Health.

Future extension: Add human QA receipts only when the receipt schema can carry tester, build identity, machine/audio settings, evidence, and pass/block/fail state. A checkbox without evidence would make the dashboard look complete while weakening trust.

Subagent note: No subagent was used. This change is a tightly coupled Settings/UI/test/documentation pass over an existing authoritative model.

2026-08-06 - Dialogs Are Part Of Instrument Trust

A warning box is not separate from the musical instrument; it is part of the moment when a musician decides whether SpaceAge is safe to trust. Routing sample-load results and MIDI hardware/setup failures through one SpaceAge-owned JUCE dialog path connects visual identity, plain-language safety, and future accessibility work. The same central helper can later gain consistent Escape handling, copyable diagnostic details, or action severity without hunting through unrelated workflows.

This pass deliberately does not claim that a source scan proves every sentence is friendly or every dialog feels good. It removes the obvious Windows-native rupture and creates a regression boundary; human review remains the authority for tone and comprehension.

Subagent note: Kepler was assigned an independent readiness-ledger audit, but the subagent service never returned an initialized session. No delegated findings were incorporated; the U07 decision came from the local ledger and source audit.

2026-08-06 - A Readiness Dashboard Should Hand You The Next Experiment

Task: Turn the remaining human-only beta blockers into a usable in-app QA path without inventing a competing checklist.

Creative connection: A blocker card should behave like a musical inspector: selecting it should reveal the exact next meaningful action, not merely repeat that work remains. This connects release management to SpaceAge's existing context-first philosophy in Arrangement, Automation, Instrument Bay, and MIDI Health.

Architecture choice: Keep MidiProjectHealthSummary::betaReadinessGate() authoritative. Beta Readiness selects directly from its eight blocker records and maps each selection back to the existing detailed checklist array. COPY NEXT TEST exports that one evidence packet; COPY FULL CHECKLIST remains the broad handoff. No editable checkbox or local pass state is allowed because human proof needs a tester, build, machine, evidence, and result before it can be trusted.

Future extension: The same selection-to-evidence pattern can drive structured beta receipts, instrument listening assignments, clean-machine installation runs, and hardware passport certification. Those extensions should attach evidence to the authoritative record rather than adding another dashboard.

Subagent note: No subagent was used. The delegation service failed to initialize the previous audit, and this pass stayed tightly scoped to one existing model, one Settings surface, one focused contract, and documentation.

2026-08-06 - Evidence Must Be Harder To Fake Than To Record

Task: Let a human beta tester record build-scoped results without letting convenient UI weaken release truth.

Creative connection: SpaceAge already treats a musical edit as authored history rather than a disposable visual state. Human QA deserves the same respect. A receipt chain connects beta testing, support bundles, clean-machine certification, instrument listening, MIDI hardware passports, and future release-candidate comparisons without putting engineering metadata inside a musician's project.

Architecture choice: Keep readiness verdicts authoritative and immutable from this surface. Store human observations separately, bind them to the executable, require an explicit result, and preserve ordered history with SHA-256 linkage. Re-read before append so two open SpaceAge instances cannot erase each other's work. If the ledger is damaged, stop and explain rather than starting over silently.

Privacy choice: Do not prefill the Windows account name. Store only tester-supplied identity and an editable environment summary, and warn that the file is plaintext. Evidence references should be useful paths or filenames, never secrets, serial numbers, or unnecessary personal directories.

Subagent note: Curie performed a read-only trust audit. Its findings directly caused the removal of preselected PASS, replacement of misleading append-only language, ledger-integrity validation, save lockout on corruption, interprocess append locking, stronger build identity, backup/post-write verification, privacy guidance, and clearer HUMAN QA REPORTED wording. Curie changed no files; LT integrated and verified the changes.

2026-08-07 - Focus Should Be Visible Without Becoming Another Selection State

Task: Begin Section 8's accessibility and cosmetic-polish pass at the shared control layer.

Creative connection: Keyboard focus is navigation context, not musical selection. A thin SpaceAge-blue outline lets keyboard and assistive-technology users see where the next action will land without competing with orange active states, white clip selection, or lane-arm colors. The same distinction can serve future Instrument Bay browsing, hardware editors, Motion Clips, and preset search.

Architecture choice: Improve the shared CleanLookAndFeel rather than restyling pages independently. Buttons now have clearer hover feedback and quieter disabled presentation; buttons and combo boxes receive a restrained keyboard-focus ring. A recursive metadata pass publishes accessible names from visible button text, existing component names/IDs, or tooltip copy, and carries tooltip guidance into JUCE accessibility help. Settings callout contents receive the same treatment before they are wrapped for scrolling.

Verification: The freshly rebuilt PRIMARY_UI_VISUAL_STATE gate passes and now requires representative primary controls to accept keyboard focus and publish non-empty accessibility titles. This is software proof only; minimum-window visual review and a real Windows screen-reader pass remain human QA.

Subagents: Curie and Eames were assigned independent read-only accessibility and visual-system audits. The delegation call did not return task IDs or findings, so no delegated output was incorporated and no subagent changed files. LT implemented and verified the shared layer locally.

2026-08-07 - A Popup Should Close The Same Way Wherever It Appears

Task: Make shared Settings popups consistently reachable and dismissible while extending visible keyboard focus to sliders and rotary controls.

Creative connection: A popup is a temporary workspace, not a trap. Esc should mean "return me to the music" whether the user is inspecting MIDI hardware, routing, beta readiness, shortcuts, or future Instrument Bay metadata. The same focus language should continue from buttons into faders and synth knobs so keyboard navigation feels like one uninterrupted path.

Architecture choice: Put dismissal and focus ownership in SettingsScrollableCalloutContent, the shared wrapper already responsible for popup reachability. Preserve JUCE's click-away dismissal and vertical scrolling. Do not force transactional MIDI import/export panels through this wrapper because they have deliberate commit/cancel rules. Extend the shared LookAndFeel focus outline to ordinary sliders, Mixer faders/sends, and both rotary styles.

Verification: Fresh compilation passes SETTINGS_ROOT_LAYOUT; no-build regressions pass PRIMARY_UI_VISUAL_STATE, SETTINGS_ROOT_LAYOUT, EFFECTS_DETAIL_LAYOUT (312 controls), and AUTOMATION_EDITOR_LAYOUT (29 controls, no horizontal scrolling).

Subagents: Curie was assigned the popup inventory, but the delegation call remained stuck before returning a task ID and was terminated. Eames could not be launched behind that stalled call. Neither changed files or produced findings; LT completed the audit and implementation locally.

2026-08-07 - Visible Parameter Names Should Become Shared Product Vocabulary

Task: Make synth, lab, Mixer, effect-detail, and ordinary slider interaction feedback consistent, then prove native synth controls are keyboard and screen-reader reachable.

Creative connection: The label beside a knob should not be disposable paint. Reusing that exact musician-facing name as the control's accessibility title creates one vocabulary for screen readers, keyboard navigation, MIDI Learn, Automation, manuals, preset metadata, and future in-app guidance. A control called CUTOFF should remain CUTOFF everywhere rather than becoming an anonymous slider in one subsystem and a private parameter ID in another.

Architecture choice: Keep hover and drag feedback in the shared LookAndFeel so new sliders inherit it automatically. Native synth control setup now publishes each existing visible parameter label as its title and description; only deliberately unlabeled internal controls receive a stable engine-and-index fallback. The synth-quality gate requires every visible synth slider to accept keyboard focus and publish a non-empty title.

Verification: Fresh Release compilation passes SYNTH_CONTROL_QUALITY with geometry, interaction, and accessibility all true: 590 visible controls and 590 accessible controls. PRIMARY_UI_VISUAL_STATE, EFFECTS_DETAIL_LAYOUT, AUTOMATION_EDITOR_LAYOUT, and MIXER_LAYOUT also pass after the shared hover treatment.

Subagents: Eames and Curie were assigned independent read-only UI audits, but the delegation service stalled before returning either task ID. The stalled request was terminated; neither subagent changed files or supplied findings. LT completed and verified the work locally.

2026-08-07 - Density Modes Need Their Own Honest Usability Contract

Task: Continue Section 8 by protecting critical Arrangement lane controls, untangling Pad-card actions, and auditing the Drum Composer grid at both roomy and minimum supported viewports.

Creative connection: Control size should follow musical consequence. ARM, Mute, Solo, preset management, and instrument editing are deliberate commands and deserve comfortable targets. Compact Drum Composer is different: its promise is seeing all 64 steps without paging, so its cells may be narrower while still retaining a tested minimum height and width. This semantic sizing model can later guide Motion Clips, Automation nodes, Mixer compact views, and hardware-editor matrices without forcing every surface into one blunt dimension.

Architecture choice: Keep ordinary critical controls at a 24-pixel minimum height, separate Pad performance/preset/edit actions into distinct rows, and make the Pad top row responsive rather than allowing labels and selectors to collide. Give the standard 16-step grid a comfortable minimum while documenting a narrower domain-specific minimum for the explicit Compact 64-step mode. Both modes must remain fully contained at 1800x1000 and 1100x800.

Verification: Fresh Release compilation passes ARRANGEMENT_LANE_VISUAL_STATE with roomy and minimum targets true. PRIMARY_UI_VISUAL_STATE passes Pad target, row-separation, containment, standard-grid, compact-grid, and grid-containment checks. ARRANGEMENT_OVERVIEW_LAYOUT also remains green.

Subagent note: Lorentz completed a read-only audit and changed no files. Its findings identified the untested 22-pixel Arrangement ARM/M/S row, Pad-card crowding, and the absence of a deliberate compact-grid contract. LT integrated the production and regression changes, while rejecting a generic 24-pixel-width rule that would have broken Compact Drum Composer's explicit 64-step workflow.

2026-08-07 - Dense Musical Objects Need One Roving Keyboard Focus

Task: Continue Section 8 by making the Chord Suggestion honeycomb, Chord Create/Performance panels, Piano Roll canvas, Flux Nodes, and Automation editor more legible to keyboard and assistive-technology users.

Creative connection: A dense visual surface does not need dozens of tab stops to become accessible. One roving focus can preserve the honeycomb's compact musical character while arrow keys browse, Space auditions, Enter commits, and Escape returns the user to the song. The same pattern can later serve Automation points, Motion Clip nodes, hardware-editor matrices, and other painted musical objects.

Architecture choice: Keep semantic actions on the existing production components. Publish musician-facing names directly on controls, update Automation's accessible description when its selected row changes, and give painted canvases an explicit identity. Do not turn every painted note, hex, or curve point into an independent JUCE child component; preserve rendering performance and use a single focus owner with keyboard traversal.

Verification: Fresh Release compilation passes PRIMARY_UI_VISUAL_STATE with honeycomb accessibility/navigation true and AUTOMATION_EDITOR_LAYOUT with 29 named controls, root guidance, geometry, dismissal, and no-horizontal-scroll checks. SYNTH_CONTROL_QUALITY remains green with 590/590 accessible native controls.

Subagent note: Lorentz completed a read-only audit and changed no files. It independently identified the mouse-only honeycomb, unnamed Chord and Automation controls, absent Piano Roll canvas identity, and the need for a shared non-transactional popup contract. LT implemented the bounded production changes and deferred single-note keyboard traversal as a separate, higher-risk Piano Roll interaction task.

2026-08-07 - Patch Changes Are Scoped Audio Transactions

Task: Restore trustworthy patch editing, export reachability, loop manipulation, chord editing, navigation labels, and rotating startup artwork without contaminating unrelated instruments or transport state.

Creative connection: The same principle connects all seven fixes: an edit should affect only the musical object the user touched. Changing one lane patch retires voices only for that instrument slot; resizing a loop changes boundaries without relocating a running transport; opening a chord editor selects without auditioning; startup art and About art remain separate collections.

Architecture choice: Reserve popup action footers before laying out descriptive content, keep page-label counts tied to page counts, model live loop resizing separately from transport-start decisions, and perform patch changes as scoped voice retirement followed by state application and visible UI refresh. Register every embedded first-party image in the release asset ledger.

Verification: Added a live-loop-resize regression, retained existing transport and automation coverage, and prepared the changes for Release compilation, focused gates, and exact staged-executable launch testing.

2026-08-08 - One Visible Action Needs One Truthful Page and One Live Preview

Task: Restore the TempoCalc page, add explicit Spacebar chord audition in Chord Performance, make single-note Piano Roll resizing draw continuously, and give Piano Roll O an honest whole-clip overview distinct from selection-aware F.

Creative connection: These fixes share one product rule: the visible object should be the immediate source of truth. A public tab must own a visible page, a popup should audition only when the musician asks, a dragged note must follow the pointer before the edit is committed, and a navigation shortcut should communicate one stable framing intention. The same rule can guide Motion Clip editing, Automation curves, hardware editors, and future Instrument Bay panels.

Architecture choice: Register TempoCalc in the same public-page arrays used by visibility, layout, and regression checks. Keep Chord Performance silent on open and bind Space to an explicit audition callback. During note gestures, update the Piano Roll's local display model before sending the processor callback. Preserve F for selection-aware framing and use O for the complete editable clip, including Chord Markers.

Verification: Fresh Release compilation and focused PRIMARY_UI_VISUAL_STATE / PIANO_ROLL_WORKFLOW gates cover seven public pages, Spacebar chord audition, selection-independent whole-clip overview, and the established note-edit workflow.

2026-08-08 - Readability Is A Containment Contract, Not A Font-Size Guess

Task: Improve beta-facing readability wherever the current geometry can support larger text without creating clipping, overlap, or hidden controls.

Creative connection: One shared type vocabulary can serve the GUI, accessibility metadata, MIDI Learn, Automation, manuals, preset browsing, and future theme scaling. A readable selector should not become tiny merely because it appears in a different workstation. This pass therefore strengthens common controls first, then treats genuinely dense surfaces as explicit exceptions rather than letting every page invent its own compromise.

Architecture choice: Raise ComboBox, popup-menu, tooltip, JUCE tab, sequencer-lane, preset-name, and Arrangement instrument-selector typography through the shared LookAndFeel. Raise dense Mixer labels only where the production geometry contract proves containment at both supported viewports. Leave high-density timeline and 64-step-grid glyphs unchanged until their scaling behavior can be reviewed visually; larger is useful only while the information remains fully visible.

Verification: A fresh Release build passes PRIMARY_UI_VISUAL_STATE with the shared typography contract and MIXER_LAYOUT with the Mixer typography contract. The broader SYNTH_CONTROL_QUALITY, EFFECTS_DETAIL_LAYOUT, SETTINGS_ROOT_LAYOUT, AUTOMATION_EDITOR_LAYOUT, ARRANGEMENT_OVERVIEW_LAYOUT, ARRANGEMENT_LANE_VISUAL_STATE, STARTUP_DIALOG_LAYOUT, and LIBRARY_LAYOUT gates also pass. The Mixer audit covers 2,306 controls; the native-synth audit covers 590 controls.

Human-eye follow-up: Confirm long preset and lane names at non-default Windows display scaling, then review painted Arrangement ruler labels, compact Drum Composer cells, and other dense timeline glyphs before enlarging those domains.

Subagents: No subagent tools were available in this pass. LT completed and verified the bounded typography changes locally.

2026-08-08 - Automation Must Remain Legible At Every Lane Density

Task: Continue beta UI and workflow refinement by improving Automation readouts and the Arrangement-lane doorway without adding another inspector or competing ownership model.

Creative connection: Automation is movement attached to musical material, so its doorway should live beside the lane and clip that own it. A readable AUTOMATION badge in a full lane and a compact blue status marker in an extremely dense overview preserve that relationship. The same adaptive rule can serve future Motion Clips, expression maps, Hardware Passport state, and other lane-owned time data.

Architecture choice: Keep the existing full AUTOMATION Arrangement action and lane-local badge. Raise normal lane badge height to 20 pixels with 9.5-point bold text. In overview mode, reserve badge space in the lane-name layout, draw a 16-pixel AUTO badge when the lane is tall enough, and degrade to a compact blue status marker only when the entire lane is too short to contain readable text. Automation graph operational readouts now use 10-point text and axis/status microcopy uses 9.5-point text.

Verification: Fresh Release compilation completed. ARRANGEMENT_LANE_VISUAL_STATE passes with the new Automation readability contract, AUTOMATION_EDITOR_LAYOUT passes with 29 contained controls and no horizontal scrolling, and PRIMARY_UI_VISUAL_STATE passes all page, control, honeycomb, and typography checks. MIDI_PROJECT_READINESS also passes; its remaining warning correctly reflects missing real external-hardware evidence rather than a software-contract failure.

Subagents: Kepler and Noether were assigned read-only beta-roadblock and typography audits. The delegation service stalled before returning task IDs and was terminated. Neither changed files or produced findings; LT completed the bounded audit and implementation locally.

2026-08-08 - History Restores Must Refresh Effective Automation, Not Every Stored Row

Task: Continue beta-readiness work by making Automation Delete, Undo, and Redo restore both the drawing and the actually sounding controller state across Shared Pattern, Lane Local, and Clip Local ownership.

Creative connection: Automation ownership behaves like a musical inheritance system. A Clip can override its Lane, and a Lane can override the Shared Pattern. History should therefore reveal the next surviving musical intention, not replay every stored layer in an arbitrary serialization order. The same least-specific-to-most-specific restoration rule can later serve Motion Clips, expression maps, orchestration Scenes, and hardware-editor state.

Architecture choice: Full-state Undo/Redo now compares audible MIDI-row fingerprints before and after restoration, refreshes only rows whose sounding content changed, and applies those rows in Shared -> Lane -> Clip order. This prevents unrelated history actions from resending controller data and guarantees that the most specific surviving owner is the final live result. External MIDI safety bursts remain separate from Automation CC assertions.

UI trust: The Automation popup sizes against the display that actually contains its anchor, carries a deterministic 1100x800 reachability contract, returns a scrolled destructive action to a visible deletion receipt, uses the 9.5-point graph-annotation floor, and describes live internal/external refresh truthfully.

Verification: AUTOMATION_OWNERSHIP, AUTOMATION_HARDWARE_HISTORY, AUTOMATION_RESTORE, AUTOMATION_EDITOR_LAYOUT, and MIDI_CLOSEOUT pass. Hardware proof confirms exactly one effective CC10 for Delete, Undo, and Redo, and zero Automation CC10 sends for an unrelated Undo.

Subagents: Aquinas audited layered external-hardware fallback and identified missing exact-send, point/group-delete, and range-delete evidence. Dalton audited minimum-size and mixed-display popup behavior and identified the target-monitor, receipt-visibility, and final microtype gaps. Both audits were read-only; LT integrated the bounded production and regression changes.

2026-08-08 - Automation Deletion Must Preserve Effective Ownership

Task: Close Automation deletion trust across single points, grouped points, painted ranges, whole rows, Undo/Redo, and external MIDI for Shared Pattern, Lane Local, and Clip Local owners.

Creative connection: Automation ownership is a layered performance stack. Removing a Shared point must not erase a Clip-level intention above it, just as removing a Lane instruction must reveal the surviving Clip or Shared instruction instead of inventing a neutral state. This same ownership-aware deletion model can later support Motion Clips, hardware-editor state, and orchestration Scenes.

Architecture choice: Destructive APIs now create an Undo checkpoint only after all identities, indices, and ranges validate and an actual mutation is possible. After a partial edit, the live value is resolved from the complete Shared -> Lane -> Clip stack. Right-drag painting consolidates each interpolated snapped span into one range mutation and reports the cumulative step span and removal count.

UI trust: Stale, duplicate, and empty deletion requests are atomic no-ops that preserve Redo. Receipts distinguish single, grouped, range, and whole-row edits, and DELETE ROW language now clearly names the selected owner.

Verification: AUTOMATION_DELETE_MATRIX proves all three ownership identities, refusal atomicity, reversed/end-exclusive ranges, Undo/Redo, and exact external-MIDI fallback. AUTOMATION_HARDWARE_HISTORY, AUTOMATION_OWNERSHIP, AUTOMATION_EDITOR_LAYOUT, and MIDI_CLOSEOUT also pass.

Subagents: Newton found the partial Shared/Lane ownership-priority defect and the missing exact deletion matrix. Noether found the incomplete right-drag receipt and DELETE ROW tooltip defect. Both audits were read-only; LT implemented and verified the fixes.

2026-08-08 - Customer-Facing State Copy Must Be Exercised

Task: Continue beta-readiness work after Automation deletion closeout by identifying the next bounded software defect rather than manufacturing backend work for human-only MIDI proof rows.

Creative connection: Status language is part of the instrument. When a musician changes Automation ownership, the resulting sentence teaches where the movement lives. Treating that sentence as executable UI state means the same approach can protect future Motion Clip, Hardware Passport, Scene, and Instrument Bay ownership cues.

Architecture choice: The Automation production layout contract now invokes the real owner-selection callback and verifies that the resulting status states that changes remain with the selected owner without the malformed arrow fragment. This is stronger than a source-text scan because it exercises the callback that a customer actually triggers.

Verification: A fresh Release compile and AUTOMATION_EDITOR_LAYOUT pass with 29 contained controls. PRIMARY_UI_VISUAL_STATE and the complete MIDI_CLOSEOUT gate also pass.

Beta boundary: The remaining open MIDI checklist rows are hands-on evidence: measured USB/DIN latency, simultaneous controllers, external clock/transport devices, real DAW file round trips, SysEx devices, reconnect behavior, and Hardware Passport comprehension. These cannot be honestly marked complete from simulation alone.

Subagents: Two read-only audits were assigned for MIDI reliability and UI/accessibility. The delegation service stalled before returning task identities and was terminated; no subagent changed files or produced findings. LT completed the bounded audit and implementation locally.

2026-08-08 - Test Doorways And Evidence Receipts Are Different Jobs

Task: Make the first physical-controller MIDI proof understandable from Settings > MIDI Health without pretending that automated tests can supply human evidence.

Creative connection: A launch checklist should behave like a guided studio assistant. The main action takes the musician to the surface where the test is performed; the proof action records what happened afterward. This same perform-then-document pattern can later guide SoundFont relinking, render listening, Instrument audio QA, hardware-editor verification, and clean-machine setup.

Architecture choice: Launch-proof actions now route by receipt type. Automation opens Automation, controller latency and live timing open MIDI Timing, external expression opens Hardware Passport, RPN/NRPN opens MIDI Maps, SysEx restore opens the SysEx Vault, file round trips open MIDI Import, and project round trips open Beta Readiness. The dedicated QA action remains responsible for saving PASS, FAIL, or BLOCKED evidence.

Verification: MIDI_HEALTH passes all focused health, latency, recording, Automation-doorway, hardware-proof, and claim-honesty checks. MIDI_CLOSEOUT and SETTINGS_ROOT_LAYOUT also pass from the freshly rebuilt test binary.

Subagents: Two read-only audits were assigned for the physical-controller workflow and viewport accessibility. The delegation service stalled before returning task identities and was terminated; no subagent changed files or produced findings. LT completed and verified the bounded change locally.

2026-08-08 - Hardware Proof Should Capture Reproducible Conditions

Task: Tighten the first physical-controller proof so a PASS cannot be recorded without the context needed to reproduce USB-versus-DIN timing behavior.

Creative connection: A QA receipt can become the seed of a future guided Hardware Passport. Controller identity, connection path, buffer size, measured latency, compensation, and recorded placement are useful not only for beta proof, but also for troubleshooting presets and recommended low-latency configurations.

Architecture choice: Controller-latency and live-timing receipts now provide a structured evidence template in the existing notes field. PASS validates every required detail. FAIL and BLOCKED remain available, but an untouched blank template is not accepted as evidence. The template is derived from the receipt identity and serialized for UI/report consumers without creating duplicate persistent state.

Verification: Fresh MIDI_QA_RECEIPT compilation and persistence proof pass. Final compiled MIDI_HEALTH and MIDI_CLOSEOUT pass; MIDI_RECORD_TIMING and MIDI_LIVE_INPUT_HEALTH also pass, including four-measure note/expression capture and simultaneous-controller ownership.

Subagents: Two read-only audits were assigned for wording/accessibility and persistence risk. The delegation service stalled before returning agent identities and was terminated; no subagent changed files or produced findings. LT performed both audits locally.

2026-08-08 - Critical Proof Must Be Visible Before It Can Be Useful

Task: Continue MIDI beta closeout by making release-critical proof visible in the MIDI Health cockpit and correcting misleading proof doorways.

Creative connection: The MIDI Health cockpit is not merely a report. It is a guided flight checklist: the most important unresolved action must be visible without scrolling, and its button must open the exact place where the musician can perform the test. This pattern can later guide render listening, missing-asset repair, Instrument Bay verification, and clean-machine setup.

Architecture choice: The launch card, proof state, verdict, run identity, proof detail, and next action now occupy the first nine summary rows. A compile-time guard prevents those release-critical rows from silently falling below the visible viewport again. RPN/NRPN proof opens MIDI Patch; public wording now says CAPTURE REVIEW. Inspect-only MIDI import also reports nonmutation even when optional adoption flags are hostile.

Verification: MIDI_QA_RECEIPT, MIDI_HEALTH, MIDI_CLOSEOUT, SETTINGS_ROOT_LAYOUT, MIDI_RECORD_TIMING, MIDI_PROTOCOL, and MIDI_IMPORT_TRANSACTION pass. The import transaction reports inspectTruth=1.

Subagents: Rawls identified the inspect-only reporting mismatch and the larger future conductor-map extension. Goodall identified the hidden launch rows, incorrect RPN/NRPN doorway, and misleading public-wording action. Neither subagent changed files.

2026-08-08 - Validation Must Not Erase Human Evidence

Task: Preserve a musician's complete MIDI launch-proof or QA receipt when validation finds missing fields.

Creative connection: Evidence entry should behave like musical editing: a refused commit must leave the work available for correction. This same retain-correct-retry pattern should guide future Hardware Passport forms, render listening notes, missing-asset repair, and beta observation workflows.

Architecture choice: MIDI Health now holds one temporary receipt draft after a failed save. The warning explains what is missing and returns to a repopulated form. Result, evidence notes, reviewer, references, blocked reason, and Automation doorway/owner/index/workflow/ownership fields are restored. Cancel still discards the temporary draft deliberately.

Verification: Fresh Release compilation and SETTINGS_ROOT_LAYOUT pass. MIDI_QA_RECEIPT, MIDI_HEALTH, and the complete MIDI_CLOSEOUT gate pass from that binary.

Subagents: Accessibility and header-layout audits were delegated, but the delegation service stalled before returning task identities and was terminated. No subagent changed files or contributed unverified findings in this pass.

2026-08-08 - Health Proof Must Be Readable And Speakable

Task: Finish the MIDI Health presentation pass by preventing header collisions, improving critical-row legibility, and exposing release status to accessibility clients.

Creative connection: MIDI Health now behaves more like an inclusive flight-status board. The same pattern can later make render progress, missing-asset repair, Instrument Bay state, and project recovery both visually scannable and screen-reader useful without duplicating business logic.

Architecture choice: The title owns one row and all ten commands share a second width-responsive row. Summary rows grew from 18 to 20 pixels; labels and values use materially larger fonts and stronger minimum scaling. The panel exposes one dynamic accessibility group summary containing cockpit status, next action, proof count, verdict, and action guidance, refreshed whenever the health snapshot changes.

Verification: Fresh Release compilation and SETTINGS_ROOT_LAYOUT pass. PRIMARY_UI_VISUAL_STATE, MIDI_QA_RECEIPT, MIDI_HEALTH, and the complete MIDI_CLOSEOUT gate pass from the compiled binary.

Subagents: Accessibility and responsive-layout audits were delegated, but the delegation service stalled before returning task identities and was terminated. No subagent changed files or supplied findings; LT completed both audits locally.

2026-08-08 - Presentation Rules Should Be Executable

Task: Protect the completed MIDI Health accessibility and responsive-header work from future UI regressions.

Creative connection: A layout rule is more durable when production and test code share the same geometry calculator. This pattern can later protect dense transport rows, Instrument Bay cards, effect racks, and render dialogs without relying only on screenshots.

Architecture choice: MIDI Health command geometry and its spoken summary are now shared pure helpers. The Settings gate tests full and compact command rows for containment, gap consistency, target width, and height, and tests the semantic summary for cockpit, next action, proof, verdict, and action fields.

Verification: Fresh SETTINGS_ROOT_LAYOUT compilation reports scrollShell=1, midiHealthCommands=1, and midiHealthAccessibility=1. PRIMARY_UI_VISUAL_STATE, MIDI_HEALTH, and the complete MIDI_CLOSEOUT gate also pass.

Subagents: Two read-only release/workflow audits were assigned. The delegation service again stalled before returning task identities, so the calls were terminated; no subagent changed files or supplied findings. LT completed the release-status audit locally.

2026-08-08 - Popup Dismissal Is A Shared Interaction Contract

Task: Close the explicit beta gap for consistent Escape dismissal without weakening dialogs that protect destructive or consequential actions.

Creative connection: A predictable exit is part of the app's musical flow. The same reusable callout behavior can support future Instrument Bay, render, missing-asset, and sound-design popups while preserving specialized confirmation rules where a careless dismissal could hide unfinished work.

Architecture choice: Ordinary popup content now inherits one focus-aware Escape behavior. MIDI export preview, MIDI import review, MIDI import receipt, and Piano Roll grid color use it and publish accessible names plus closing guidance. JUCE retains click-away ownership; guarded package-import and explicit confirmation workflows keep their existing specialized behavior.

Verification: Fresh PRIMARY_UI_VISUAL_STATE reports popupEscape=1; AUTOMATION_EDITOR_LAYOUT, SETTINGS_ROOT_LAYOUT, and the complete MIDI_CLOSEOUT regression pass.

Subagents: Two read-only audits were assigned for Arrangement/Automation and instrument/audio readiness. Both delegation calls stalled before returning identities and were terminated; no subagent changed files or supplied findings. LT completed the bounded beta-gap audit locally.

2026-08-08 - Long Clip Previews Must Preserve The Musical Span

Task: Prevent dense 128/256-step Arrangement thumbnails from visually omitting their latter material.

Creative connection: A miniature should communicate contour across time, not merely prove that a clip contains notes. The same endpoint-preserving reduction can later support waveform overviews, Automation summaries, Quasar zone maps, and other compressed musical displays.

Architecture choice: Notes and Chord markers now share one evenly distributed representative-index selector. It retains every item when there are 32 or fewer, and guarantees the first and final musical events when denser content must fit the 32-mark preview budget.

Verification: ARRANGEMENT_LANE_VISUAL_STATE reports previewCoverage=1. ARRANGEMENT_OVERVIEW_LAYOUT, PRIMARY_UI_VISUAL_STATE, and the complete MIDI_CLOSEOUT suite pass.

Subagents: Arrangement/Automation and Instrument-readiness audits were delegated, but the delegation service stalled before returning identities. The attempts were terminated; no subagent supplied findings or changed files. LT completed the bounded audit locally.

2026-08-08 - Presentation Tests Must Cross The Production Boundary

Task: Strengthen the long-clip thumbnail fix and the full MIDI/lane closeout verdict before moving to another beta risk.

Creative connection: A pure selector test proves useful mathematics, but a musician experiences stored notes flowing through the editor refresh and into the Arrangement canvas. Testing that whole path protects future note previews, Chord previews, waveform summaries, and Automation miniatures from integration drift.

Architecture choice: The self-test build can inspect the actual canvas preview after refreshChain(). A real 256-step pattern with dense early-to-late notes now verifies the production path retains both temporal endpoints within the 32-mark budget. The full closeout verdict also explicitly includes clip placement, clip preview, lane instrument presentation, Mixer reassignment, and MIDI policy presentation contracts that previously lived only in a narrower slice.

Verification: ARRANGEMENT_LANE_VISUAL_STATE, ARRANGEMENT_OVERVIEW_LAYOUT, PRIMARY_UI_VISUAL_STATE, FACTORY_INSTRUMENT_DEFAULT, and the strengthened MIDI_CLOSEOUT suite pass. The factory sweep confirms every tested internal engine recalls its default, produces finite audio, releases, and keeps tonal defaults at concert pitch within the existing tolerance.

Subagents: Kepler and Faraday were assigned read-only Arrangement and instrument-readiness audits. The delegation service stalled before returning identities or findings; no subagent changed files. LT completed the production-boundary and readiness audit locally.

2026-08-08 - Active Arrangement Loop Render Is A Deliberate Product Contract

Task: Close the release gap for exporting a precise musical subsection without allowing playback-loop state to silently redefine full-song rendering.

Creative connection: The Arrangement loop now serves two compatible jobs without ambiguity: a reversible playback focus and an explicit render source. This makes fast sketch sharing possible while preserving the trustworthiness of full-song export. The immutable-boundary pattern can later serve selection render, freeze/bounce, Quasar capture ranges, and Motion Clip printing.

Architecture choice: Full Arrangement WAV remains loop-immune. A separate Render Active Arrangement Loop to WAV command is enabled only for a valid loop. The UI captures inclusive loop endpoints once, converts them to an end-exclusive processor contract, and hands those immutable values to the background renderer. The renderer clears live loop state, starts at the captured first step, calculates duration from only the overlapped tempo segments, renders the fixed effects tail after transport stops, and publishes atomically.

Verification: CHAIN_AUDIO_EXPORT proves exact four-step musical duration, 24-bit stereo output, range-relative silence and in-range transient timing, monotonic progress, invalid-range destination preservation, full-song live/offline parity, cancellation safety, and time-aligned stems. ARRANGEMENT_OVERVIEW_LAYOUT, PRIMARY_UI_VISUAL_STATE, and the complete MIDI_CLOSEOUT gate pass from the rebuilt binary.

Subagents: Planck identified selection/loop audio render as the highest-value software-verifiable beta gap and mapped the missing public/UI/test contracts. Schrodinger audited Instrument audio continuity and identified source-backed Liftoff/Lunacy patch recall as the next bounded risk: a patch can report load success while its source asset is unavailable. Neither subagent changed files; LT integrated and verified this pass.

2026-08-08 - Portable Sources Are Part Of The Patch

Task: Make Liftoff and Lunacy patches portable without allowing a missing WAV to create a misleading hybrid sound.

Creative connection: Treating the source as an atomic part of the patch connects today's patch library to the future preset browser, project archive, relink, sharing, and Quasar package workflows. The same rule can later govern impulse responses, user wavetables, analysis files, and any other sound-design dependency.

Architecture choice: A source-backed patch now resolves its bundled relative WAV before an original absolute path, validates decoding before changing Instrument state, and refuses the whole patch if no usable source exists. Saving uses an atomic staged copy and explicitly handles the case where the active source already is the patch's bundled file.

Verification: INSTRUMENT_PATCH_LIFECYCLE proves Liftoff and Lunacy portable recall, bundle precedence over a stale/corrupt original, same-file save-over preservation, parameter recall, and atomic refusal that leaves the existing source, parameters, and patch name unchanged. FACTORY_INSTRUMENT_DEFAULT, AUDIO_SAFETY_CONTINUITY, MIDI_CLOSEOUT, and RECOVERY_WORKFLOW also pass.

Subagents: Planck found the self-delete save-over edge case and mapped deterministic source-lifecycle regressions. Schrodinger defined the truthful customer contract and identified project-level semantic relink labels as the next bounded follow-up. LT implemented and verified the atomic patch contract.

2026-08-08 - Project Repair Understands Instrument Sources

Task: Close the project-level missing-source gap for Liftoff and Lunacy without treating their dependencies as generic Pad samples.

Creative connection: A semantic repair ledger joins project recovery, portable patches, the Instrument Bay, and future asset types under one truthful dependency model. The same contract can later identify impulse responses, user wavetables, spectral analyses, and Motion Clip source material by musical purpose rather than storage location.

Architecture choice: Missing Liftoff and Lunacy sources receive distinct receipt types and Instrument-facing descriptions. Existing-but-undecodable files count as unavailable. Engine-specific Load Source and Clear Source actions explicitly rescan the ledger and refresh both the active source label and Library repair display, so stale warnings disappear immediately.

Verification: MISSING_ASSET_REPAIR passes all seven asset classes plus ambiguity, stale-receipt, audible repair, save/reopen, direct replacement, and intentional-clear contracts. INSTRUMENT_PATCH_LIFECYCLE, RECOVERY_WORKFLOW, FACTORY_INSTRUMENT_DEFAULT, and MIDI_CLOSEOUT also pass.

Subagents: The delegation service did not initialize Planck or Schrodinger during this pass, so neither produced findings or changed files. LT completed both processor-ledger and customer-facing audits locally.

2026-08-08 - Complete Project Means Every Instrument Source

Task: Make complete-project export genuinely self-contained for source-backed Arrangement Instruments, not only for visible Drum Pads.

Creative connection: The Instrument Bay broke the old assumption that every sound source lives on one of 64 Pads. Project portability therefore has to follow musical ownership rather than a legacy GUI range. The same all-source boundary can carry future impulse responses, user wavetables, spectral analyses, Motion Clip sources, and AI-assisted patch assets without inventing another archive mechanism.

Architecture choice: Complete-project publication begins by rescanning the dependency ledger and refuses with a repair-or-clear instruction if anything is unavailable. Healthy export then enumerates all source slots and deduplicates their files. Staging replaces absolute source paths with controlled internal placeholders; semantic validation accepts only the two recognized archive namespaces with nonempty traversal-free suffixes. Import remaps those assets before the project is adopted.

Verification: The focused PROJECT_ARCHIVE gate now packages an ordinary Pad sample, private Liftoff and Lunacy sources, a deterministic SoundFont, and a deterministic Quasar package. It first removes the Lunacy, SoundFont, and Quasar resources and proves publication refuses all three missing dependencies. After restoration it redacts both archive namespaces, removes every original, imports five remapped references, verifies every restored path lives under the import destination, and renders Liftoff, Lunacy, SoundFont, and Quasar with finite nonzero audio. MISSING_ASSET_REPAIR, SOUNDFONT, RECOVERY_WORKFLOW, HOSTILE_INSTRUMENT_RESOURCE, and MIDI_CLOSEOUT also pass.

Creative extension: Complete Project is now a portable Instrument Bay transaction rather than a ZIP convenience. The same proof pattern can absorb future impulse responses, user wavetables, spectral analyses, and Motion Clip assets: remove the originals, import elsewhere, validate ownership, then demand audible or semantically usable output from the restored resource.

Subagents: Planck and Schrodinger were assigned software-risk and customer-workflow audits, but the delegation service stalled before returning task identities. Neither subagent produced findings or changed files; LT completed the archive and workflow audits locally.

2026-08-09 - Portability Must Survive The Next Ordinary Save

Task: Prove that a Complete Project import remains portable after the musician resumes normal work, saves the imported session as an ordinary project, closes it, and reopens it again.

Creative connection: Import is not the end of portability; it is a handoff into everyday composition. Treating the first post-import save as another publication boundary connects Complete Project, ordinary Save, recovery, relink, and the Instrument Bay under one ownership rule: restored resources must become normal project resources without falling back to the original machine or retaining archive-only placeholders.

Architecture choice: The focused archive regression now saves the activated imported project, constructs a fresh processor, reopens the ordinary project, requires an empty repair ledger, verifies four ordinary assets plus one Quasar package still live below the imported root, and renders Liftoff, Lunacy, SoundFont, and Quasar again.

Verification: PROJECT_ARCHIVE reports resave=1/1/1. PROJECT_PERSISTENCE, GOLDEN_PROJECT_LIFECYCLE, RECOVERY_WORKFLOW, MISSING_ASSET_REPAIR, and MIDI_CLOSEOUT also pass. Zeno and Curie were assigned independent production and regression audits; their findings are reviewed separately before any further change.

2026-08-09 - A Complete Project Must Contain Loadable Resources

Task: Close the gap between a referenced file existing and that file being usable after Complete Project export/import, then prove recovery and relink preserve mixed resource provenance.

Creative connection: Archive publication, recovery, Library repair, and ordinary Save are one chain of custody. A trustworthy package cannot merely contain bytes with the right filename; those bytes must activate through the same loaders used by the Instrument Bay. Recovery must then repair one broken external dependency without rewriting a healthy imported dependency.

Architecture choice: Export stages the current project and loads it in a fresh processor before publication. Import builds a temporary project bound to extracted staging paths and loads it before committing the destination. Unreadable audio, SoundFont, or Quasar resources therefore refuse atomically. Folder repair recognizes the archive's three-digit filename prefix, while manual repair now includes FLAC.

Verification: PROJECT_ARCHIVE passes missing-resource refusal, corrupt audio/SoundFont/Quasar export refusal, corrupt packaged-audio import refusal, five-resource import, ordinary resave/reopen, and mixed-provenance recovery/relink/save/reopen with both sources audible. MISSING_ASSET_REPAIR proves indexed audio and Quasar names reconnect to their original names. PROJECT_PERSISTENCE, RECOVERY_WORKFLOW, GOLDEN_PROJECT_LIFECYCLE, and MIDI_CLOSEOUT remain green.

Subagents: Zeno identified the corrupt-resource publication defect, archive-prefix relink defect, and missing FLAC filter. Curie independently identified the mixed-provenance recovery gap. Neither edited files; LT implemented and integrated the production and regression changes.

2026-08-09 - Validate the Published Artifact

• Archive planning and archive publication are different trust boundaries. A resource can change after the plan is created, so the temporary ZIP must pass the production import validator before it is allowed to replace an existing archive.
• The same principle applies to plugin delivery. Processor-level and standalone tests cannot prove that the VST3 wrapper scans, instantiates, processes MIDI, restores state, or reopens its editor. The exact built and staged wrapper now receives that proof.
• Host validation runs in a separate process with a hard timeout. A plugin crash or deadlock therefore produces bounded evidence instead of taking the release runner with it.
• These checks connect recovery safety and release safety through one rule: validate the bytes and wrapper that the customer will actually receive, as late as possible before publication.

2026-08-09 - Collapse Many Blocked Files Into Human Decisions

• A release ledger should not make sixteen blocked files feel like sixteen unrelated investigations when they belong to two ownership decisions.
• Grouping artwork as one attestation workflow and TG55 as one inseparable factory-bank workflow reduces cognitive load without weakening byte-level enforcement.
• The status command remains read-only. It explains what evidence is missing but cannot mark an asset cleared, preserving the boundary between engineering proof and human legal authority.
• Reproducible bytes establish lineage, not permission. Technical reproduction and commercial-rights authority must be recorded as separate facts so one cannot be mistaken for the other.

2026-08-09 - Release Proof Must Resist False Confidence

Task: Harden release convergence and VST3 packaging against inherited test selectors, no-op state restoration, and stale bundle contents.

Creative connection: The release system is itself a customer-facing feature because every false pass becomes uncertainty at installation time. Selector isolation applies the same explicit-ownership rule used by Instrument lanes: each gate chooses its own scope. Semantic state restoration applies the same truth rule used by patch recall: a changed control must return changed, not merely serialize bytes. The VST3 allowlist applies the same controlled-package rule used by Complete Project archives.

Architecture choice: Convergence now clears every process variable matching SPACEAGE_*_ONLY, including selectors added in the future. The VST3 host changes a real automatable parameter, proves the saved state differs from default, restores it into a new instance, and verifies both byte and parameter truth. VST3 bundles may contain exactly the module metadata and x64 binary; hidden, stale, or foreign files refuse packaging.

Configuration now travels through every artifact resolver, native gates have bounded execution and cleanup, packaging rechecks source cleanliness after the build, and final archives include hidden files. VST3 audio proof compares note-driven output against a silent pre-note baseline rather than accepting arbitrary startup noise as Instrument response.

Subagents: Mill audited release asset authority and separated reproducible provenance from commercial permission. Lagrange audited release and VST3 evidence, identifying selector leakage, stale bundle copying, and no-op state round trips. LT integrated the bounded fixes and verification.

2026-08-10 - Reopen Means A Real Window, Reproducible Means The Same Bytes

Task: Replace two reassuring-but-incomplete release checks with evidence closer to the customer's actual experience.

Creative connection: VST editor lifecycle and release packaging share the same principle used by project portability: validate the final form, not an internal approximation. A constructed editor is not yet a hosted window, just as a valid folder is not yet a reproducible archive.

Architecture choice: The VST3 harness now attaches the editor to a native desktop peer, pumps the JUCE message queue, tears it down, and repeats the full lifecycle. Release ZIP creation moved into one shared deterministic writer with sorted hidden-aware entries and fixed ZIP timestamps. The release manifest's generation time is bound to the source commit, making repeated candidates from the same source and toolchain byte-identical.

Verification intent: The archive contract requires identical ZIP hashes for identical candidates and separately rejects generation-time and toolchain drift. Packaging refuses any fallback to nondeterministic archive APIs.

Subagents: Mill and Lagrange were assigned independent VST-host and archive audits, but the delegation service stalled before returning task identities. Neither produced findings or changed files; LT completed both audits locally.

2026-08-10 - Open Rows Need Accountable Evidence, Not More Percentages

Task: Convert the remaining release-readiness rows into a governed human closeout plan.

Creative connection: MIDI Health, Beta Readiness, legal clearance, host testing, and UI review are all evidence-capture workflows. Giving each open row one owner, one action, and one acceptable receipt turns the final beta push into a sequence of finite missions rather than an ambiguous feeling that the app is almost done.

Architecture choice: Resources/ReleaseHumanEvidencePlan.json must match the canonical open ledger exactly. A release test rejects duplicate, missing, stale, or unclassified rows. The candidate-status command now reports open IDs and evidence groups without promoting partial software proof into a human PASS.

2026-08-10 - Focused MIDI Proof Belongs In The Canonical Release Run

Connection: SpaceAge already had focused tests for latency accounting, concurrent-input health, the MIDI 1.0 protocol boundary, mapping/learn behavior, setup and control queues, clock policy, SysEx capture/restore, and transactional MIDI import. Leaving those tests outside release convergence made strong engineering work easy to overlook and allowed a release run to omit relevant regressions.

Architecture choice: these focused selectors are now named M01-A through M07-A supporting gates in tools/run-release-convergence.ps1. They remain supporting software evidence: they reduce the hardware and human test surface but cannot replace USB/DIN measurements, real-device acceptance, real-file DAW round trips, or musician judgment.

Future extension: The same plan can feed an in-app Admiral dashboard, printable QA packets, and release-candidate history while retaining the append-only Beta QA receipt chain already used inside SpaceAge.

2026-08-10 - Recording State Must Never Depend On A Hidden Lane

Task: Make the Arrangement record action communicate four distinct truths: no target, ready, count-in pending, and actively recording.

Creative connection: Recording confidence, lane ownership, and visual accessibility are one problem. ARM LANE should teach the missing action, blue REC should confirm a valid destination, amber COUNT should explain intentional waiting, and dark orange REC IN should confirm that durable notes are landing. This reuses the same truthful-state language already established for lane selection, MIDI arm, Mute, Solo, page tabs, and shared Effects.

Architecture choice: The visible lane destination is now authoritative. Clearing it also clears the hidden compatibility selector instead of allowing that selector to silently restore Lane 1. Record readiness no longer falls back to an unselected lane. A focused contract exercises all four text, enabled/alpha, color, and hit-target states at both 1800x1000 and 1100x800, then restores the prior editor and recording state.

Future extension: The same explicit-state model can drive a compact preflight strip showing lane, Instrument, MIDI source, count-in, and monitoring before a take. It can also feed accessibility announcements without inventing a second recording-state calculation.

Subagents: Two delegated workers were assigned a UI-state audit and Settings reachability audit, but the delegation service did not initialize either task. Neither produced findings or changed files; LT completed this focused contract locally.

2026-08-10 - A Doorway Is Not Proven Until It Opens The Right Room

Task: Replace generic Settings-shell confidence with executable proof of every customer-visible destination.

Creative connection: Settings, Instrument Bay, Effects editors, and lane detail buttons all share a navigation truth problem: a button can look healthy while its callback is absent, duplicated, or aimed at stale content. The new doorway contract treats navigation as a typed route rather than decorative UI. That same pattern can later protect Instrument Bay engine launches and every L/S/V lane panel.

Architecture choice: The self-test build can intercept the shared Settings callout launch point without creating desktop windows. At 1100x800, it presses the 14 production destination buttons twice in opposing order and requires each to remain visible, enabled, correctly labeled, usable, and wired to exactly one stable, distinct destination component. Each destination is wrapped by the production scrolling shell and checked for bounded reachability, keyboard focus, and Escape handling. The complete sweep must leave serialized project state unchanged. Production builds do not compile the interception path.

Verification: Fresh SETTINGS_DESTINATION_REACHABILITY passes with 28/28 launches and projectStateCold=1. SETTINGS_ROOT_LAYOUT, PRIMARY_UI_VISUAL_STATE, AUTOMATION_EDITOR_LAYOUT, and the complete MIDI_CLOSEOUT regression also pass.

Subagents: Sartre and Curie were assigned independent Settings and hidden-selector audits. The delegation service stalled before returning task identities, so neither produced findings or changed files. LT completed the bounded audit and integration locally.

2026-08-10 - Settings Controls Need Names, Not Merely Geometry

Task: Extend the Settings destination proof from doorway reachability into the interactive controls inside every destination.

Creative connection: A Hardware Passport selector, calibration field, or SysEx metadata editor should use the same plain-language identity in the GUI, accessibility layer, manual, test receipts, and future in-app help. Naming the control once turns accessibility metadata into a durable vocabulary rather than a late cosmetic annotation.

Architecture choice: The U04-B probe now recursively inspects every visible Button, ComboBox, Slider, and TextEditor after each of the 14 Settings destinations opens. Every control must have nonempty contained geometry, a usable minimum target, and a customer-facing accessible title. The audit initially exposed 16 genuinely unnamed controls in MIDI Timing, MIDI Setup, Hardware Passports, and SysEx Vault; production titles and explanatory tooltips were added to those exact controls rather than weakening the gate.

Verification: Fresh SETTINGS_DESTINATION_REACHABILITY passes with 28/28 destination launches, 306/306 named controls, valid geometry, and projectStateCold=1. SETTINGS_ROOT_LAYOUT, PRIMARY_UI_VISUAL_STATE, AUTOMATION_EDITOR_LAYOUT, and the complete MIDI_CLOSEOUT regression pass from the rebuilt binary.

Human follow-up: Test Settings with Windows Narrator or another supported accessibility client, keyboard-only navigation, display scaling, and human eyes. Automated metadata and geometry proof narrows that session but does not replace it.

Subagents: Hopper and Shannon were assigned read-only Settings accessibility and target-size audits. The delegation service stalled before returning task identities and was terminated; neither produced findings or changed files. LT completed and verified the work locally.

2026-08-10 - One Visual Language Across Every Workstation

Task: Assess SpaceAge from top to bottom, identify the highest-value visual improvements, and implement a bounded professional-polish pass without changing workflow or audio behavior.

Creative connection: A single state language is more than cosmetic. The same idle, hover, pressed, selected, disabled, and keyboard-focus recipes can serve native instruments, future VST hosting, Yamaha XG hardware editors, automation targets, and accessibility clients. One visual grammar makes unfamiliar future features feel learnable because the user already understands how SpaceAge communicates.

Architecture choice: The shared LookAndFeel now owns more of the app's button, selector, toggle, popup, tooltip, and callout anatomy. Effects cards were connected to that language through conventional click-release behavior and keyboard activation. This reduces page-specific styling drift and gives future skins a smaller, safer control surface.

Deferred connection: The remaining fixed-width toolbar pressure in Piano Roll, Arranger, and Synth Engine should be solved with a reusable responsive toolbar grammar. That same mechanism will improve smaller laptops, Linux ports, Raspberry Pi experiments, and future high-DPI or touch-oriented layouts without inventing page-specific compromises.

Verification: The rebuilt visual contract passed PRIMARY_UI_VISUAL_STATE, EFFECTS_DETAIL_LAYOUT, SETTINGS_ROOT_LAYOUT, AUTOMATION_EDITOR_LAYOUT, MIXER_LAYOUT, and SYNTH_CONTROL_QUALITY. Human screenshot review remains required for compact selectors, dense checkbox rows, starfield contrast, and Windows scaling.

Subagents: Lovelace audited hierarchy and typography across the principal workstations. Halley audited controls, cards, state language, Settings, Mixer, Effects, and Synth Engine. Both returned usable read-only findings; neither changed files. LT implemented and verified the shared visual foundation.

2026-08-10 - Compact Workspaces Should Recompose, Not Collapse

Task: Remove fixed-width pressure from the Piano Roll, Arranger, and Synth Engine headers while preserving the control order musicians learn through repetition.

Creative connection: Responsive layout is part of performance workflow. Transport muscle memory should survive a smaller laptop, Linux machine, Raspberry Pi experiment, or high-DPI display. Contextual controls may move as intact groups, but they should not shrink into ambiguity or disappear. This same group-aware grammar can later organize Motion Clips, hardware editors, and VST hosting without inventing a new toolbar for each feature.

Architecture choice: Piano Roll and Arranger now switch between explicit wide and compact row compositions. Their transport groups retain stable horizontal positions, while musical context, grid editing, automation, rendering, and form controls wrap as meaningful units. Hidden Drum Composer utilities no longer consume Piano Roll width.

The first Synth Engine experiment used two header rows, but the adjacent quality gate proved that the extra height reduced 31 controls below usable size. Compact Synth mode therefore retains one row and shortens only action labels, preserving full tooltips and the complete editing surface. The failure was treated as design evidence rather than accepted as a cosmetic tradeoff.

Future connection: Engine selection and secondary editing destinations still compete in one tab strip. The next navigation pass should make the engine selector authoritative and reserve tabs for shared views such as Layers, One-Shots, Envelope / Filter, and Voice Shaping.

Verification: PRIMARY_UI_VISUAL_STATE now checks containment, pairwise overlap, target size, row composition, and stable transport positions at 1800x1000 and 1100x800. SYNTH_CONTROL_QUALITY passes all 590 controls with zero undersized targets. ARRANGEMENT_RECORDING_VISUAL_STATE and ARRANGEMENT_OVERVIEW_LAYOUT remain green.

Subagents: Galileo and Poincare independently audited the Piano Roll / Arranger toolbars and Synth Engine header. Their findings identified the exact width overcommit, missing compact-width test coverage, and the remaining dual-authority engine navigation problem. LT integrated the bounded responsive layout and regression gates.

2026-08-10 - One Engine Selector, Eight Honest Destinations

Task: Replace the crowded Synth Engine name tabs with one authoritative engine selector and a compact set of shared editing destinations.

Creative connection: Instrument choice and editing destination are different questions. The engine selector answers what is making the sound; the eight destination buttons answer which part of that sound or source the musician is editing. Separating those concerns creates a navigation grammar that can also serve future VST instruments, hardware editors, and Instrument Bay launches without adding another competing inspector.

Architecture choice: The existing 22-page editor deck remains intact as a private implementation detail. The public surface now exposes ENGINE, LAYERS, ONE-SHOTS, NOISE / TRANSIENT, ENVELOPE / FILTER, VOICE SHAPING, MOD / CHOKE, and ACCENT. The active Instrument parameter is the authority for engine routing; the ComboBox is a view of that state, not a second owner. All production entry points route through the same view helper.

Truthful state: Exactly one destination is selected. Separate, restrained used-state coloring shows which shared destinations contain work without pretending they are active. Keyboard preview follows the logical destination rather than a raw hidden-tab number.

Architectural dividends: The expanded quality sweep exposed old shared controls in Layers, One-Shots, and Mod / Choke plus an incomplete TG-55 reset path. Those controls now share the native fine-drag, undo, keyboard, and accessibility contract, and TG-55 reset is explicit.

Verification: PRIMARY_UI_VISUAL_STATE passes at 1800x1000 and 1100x800, including all eight destinations and an explicit 15-engine routing registry. SYNTH_CONTROL_QUALITY passes 710/710 visible controls with zero undersized targets. INSTRUMENT_PATCH_LIFECYCLE and SYNTH_PATCH_MIXER_OWNERSHIP also pass.

Subagents: Newton mapped the production entry routes and identified stale-selector and hidden-used-state risks. Fermat audited reset, coverage, accessibility, and patch-ownership regressions. Both returned useful read-only findings and changed no files; LT integrated and verified the work.

2026-08-10 - Mixer Detail Doors Must Name Their Rooms

Task: Replace the Mixer channel strip's three anonymous detail bars with readable, keyboard-accessible destinations without changing channel audio, parameter ownership, or project state.

Creative connection: SND, DYN, and EQ establish a compact destination grammar that can be reused wherever SpaceAge needs several deep editors inside a narrow owner: Mixer strips, Instrument Bay rows, hardware editor parts, and future plugin racks. The labels carry meaning without asking color to do semantic work, while the common midnight-blue surface keeps the three choices visually related.

Architecture choice: The existing per-strip mixerPanelMode and mixerMoreVisible state remains authoritative. No processor parameters, automation targets, or serialization were added. The three destinations now have distinct labels, IDs, titles, descriptions, tooltips, white text, 24-pixel target heights, and a common visual family. Opening a destination moves keyboard focus to BACK; closing returns focus to the originating destination. Leaving Mixer still closes detail pages as previously designed.

Verification: MIXER_LAYOUT passes at 1800x1000 and 1100x800, auditing 2,306 controls plus real SND/DYN/EQ/BACK callback behavior. PRIMARY_UI_VISUAL_STATE and MIXER_STATE_PERSISTENCE also pass, proving the presentation change did not alter durable channel values.

Subagents: Raman mapped existing detail ownership, bank attachment behavior, persistence risks, and missing navigation assertions. Epicurus independently audited target sizes, color-only meaning, accessibility, focus behavior, and compact geometry. Both performed read-only audits and changed no files; LT implemented and verified the bounded navigation pass.

2026-08-10 - Grouping Is A Map, Not Decoration

Task: Give Settings and Library a professional hierarchy without changing audio behavior, project state, file actions, or destination callbacks.

Creative connection: Settings cards and Library headings are the same kind of promise as Mixer detail doors and Synth Engine destinations: they tell the musician what kind of decision lives behind a control. That grammar can later organize Instrument Bay filters, Yamaha hardware-editor regions, plugin racks, and motion tools without relying on a growing inventory of unrelated button colors.

Architecture choice: Settings keeps its existing controls and state semantics but now divides them into DISPLAY / EDITING and PLAYBACK / RECORDING, renames the root SPACEAGE SETTINGS, and traverses controls in visible order. Library keeps Save dominant while adding four non-interactive headings, meaningful selector accessibility names, and a visible-order focus path. No callbacks, serialized values, audio routing, or file formats changed.

Verification: SETTINGS_ROOT_LAYOUT passes 40 controls, SETTINGS_DESTINATION_REACHABILITY passes 28/28 launches and 306/306 named controls, LIBRARY_LAYOUT passes 66 controls with hierarchy preserved at 1800x1000 and 1100x800, and PRIMARY_UI_VISUAL_STATE remains green.

Subagents: Raman audited Settings naming, grouping, compact geometry, destination overlap, and keyboard risks. Epicurus audited Library hierarchy, compact headroom, action inventory, selector accessibility, and focus order. Their read-only findings directly shaped this bounded pass; neither changed files.

Deferred connections: Positive wording for inverted switches, more task-oriented MIDI destination bands, destructive styling for Delete Recovery, and state-aware disabling of Load Selected remain appropriate later passes. They were not mixed into this low-risk hierarchy change.

2026-08-10 - Task Maps Should Match Consequences

Task: Turn the remaining Settings MIDI doorway matrix and Library action states into trustworthy customer-facing maps without changing destination callbacks, MIDI behavior, project formats, or audio.

Creative connection: Setup, performance, diagnostics, and advanced tools are different mental modes. Keeping each mode in a stable four-button row lets future Instrument Bay, hardware editor, and plugin-rack destinations use the same task-map grammar. Library state truth follows the same principle: an action should look available only when it can succeed, and permanent actions should look and behave differently from ordinary navigation.

Architecture choice: Settings now presents SETUP / ROUTING, PERFORMANCE / DATA, DIAGNOSTICS, and ADVANCED / HELP as four equal rows of four doorways. Shorter customer-facing labels, complete help text, accessible titles, and explicit row-major focus order all describe the existing destinations; no callback was replaced. Library now disables empty preset and recovery selectors, disables Repair when assets are healthy, names asset status for accessibility, uses the established destructive color for recovery deletion, and confirms deletion against the captured snapshot file.

Verification: SETTINGS_ROOT_LAYOUT protects the 4 x 4 row composition, geometry, accessibility, help text, and focus order. SETTINGS_DESTINATION_REACHABILITY still passes 28/28 launches, 306/306 destination controls, and cold project state. LIBRARY_LAYOUT passes 66 controls with hierarchy=1 and actionState=1 at both supported viewports. PRIMARY_UI_VISUAL_STATE remains green.

Subagents: Raman independently recommended the four-equal-row Settings task map, literal label cleanup, complete tooltips, and stronger row/focus tests. Epicurus identified empty preset actions, immediate recovery deletion, asset-status accessibility, and compact bottom-reserve risks. Both audits were read-only; LT integrated and verified the bounded changes.

Future connection: A dedicated Library action-state test can eventually simulate confirmation cancellation and confirmation acceptance with temporary snapshots. The current pass protects the visible state contract and production confirmation path without adding a desktop-dependent test.

2026-08-10 - Visible Work Owns Space; Actions Own The Floor

Task: Keep the Arranger inspector usable at compact sizes and repair MIDI import dialogs whose action rows could collapse to zero height.

Creative connection: An inspector and a dialog are both temporary decision surfaces. SpaceAge now treats them with the same rule: only visible work reserves space, and irreversible or closing actions keep a stable floor while explanatory content flexes around them. This rule can also guide future Instrument Bay inspectors, hardware editors, effect detail pages, and preset browsers.

Architecture choice: The Arranger inspector selects a wide, medium, or narrow row composition from available width. The Notes pane reserves width only while visible, and hidden Notes controls receive empty bounds. MIDI import receipt/review panels reserve their action rows from the bottom before assigning the remaining rectangle to scrollable text. Conditional lane-split geometry is cleared when unavailable so stale bounds cannot survive state changes.

Verification: PRIMARY_UI_VISUAL_STATE passes at 1800x1000 and 1100x800, including all Arranger inspector controls with Notes both hidden and visible. ARRANGEMENT_OVERVIEW_LAYOUT, ARRANGEMENT_LANE_VISUAL_STATE, ARRANGEMENT_RECORDING_VISUAL_STATE, and MIDI_IMPORT_TRANSACTION pass. A guarded source recovery was also validated against 1,165 preserved pre-edit source lines with zero mismatches before rebuilding.

Subagents: Ampere identified compact inspector collapse, permanently reserved hidden Notes width, and missing inspector-surface coverage. Hooke identified zero-height MIDI import action rows plus broader popup dismissal/accessibility work. Both audits were read-only; LT integrated and verified the bounded fixes.

Next connection: The remaining popup family should converge on one callout-host contract for Escape, click-away, focus return, and accessible dynamic controls. That work should be centralized rather than repeated panel by panel.

2026-08-10 - Temporary Panels Must Leave Cleanly

Task: Make Arrangement lane overlays and MIDI export keyboard traversal behave like trustworthy temporary work surfaces.

Creative connection: Lane commands, MIDI routing, export review, future Instrument Bay inspectors, and hardware editors all need the same interaction promise: the visible work is reachable in visual order, Escape leaves without changing data, an outside click closes non-modal overlays, and focus returns to the musical workspace. A predictable exit is part of creative flow because it lets the user inspect or adjust something without mentally tracking hidden UI state.

Architecture choice: ArrangementLaneCanvas now publishes one pre-edit canvas-click callback. The editor uses it only to dismiss an open lane overlay, so existing selection, drag, loop, and clip callbacks remain intact. Escape dismisses an open lane overlay before the existing Escape-to-clear-selection behavior. Lane command and MIDI routing controls publish accessible names and explicit focus order. MIDI export uses one focus-order helper matching its visible COPY REPORT -> EXPORT -> EXPORT STEMS -> CANCEL sequence.

Verification: PRIMARY_UI_VISUAL_STATE now reports lanePopup=1 and exportFocus=1, proving Escape dismissal, outside-click dismissal, metadata publication, and visible-order traversal. ARRANGEMENT_LANE_VISUAL_STATE and ARRANGEMENT_RECORDING_VISUAL_STATE remain green at both supported viewports. git diff --check passes for the touched source.

Subagents: Ampere's earlier overlay audit located the missing Escape/click-away lifecycle and focus-return gap. Hooke's accessibility audit found the MIDI export visual/focus mismatch and unnamed runtime routing controls. Both audits were read-only; LT implemented and verified this bounded pass.

Future connection: This establishes the behavior to extract into a shared popup host when Instrument Bay and hardware editors add more overlay families. The present change stays local to avoid a broad ownership refactor during beta convergence.

2026-08-10 - Color Is A Named Choice, Not A Mystery Button

Task: Finish the next bounded popup-accessibility pass for the Piano Roll grid palette and MIDI stem-package inspector.

Creative connection: Color palettes, package inspectors, future preset browsers, and hardware editors all create controls from runtime data. Their visual compactness should not make them anonymous. A dynamic choice needs a human name, selected-state truth, a short consequence, and a stable place in keyboard order.

Architecture choice: Every Piano Roll grid swatch now publishes an ordinal, a plain-language color name, its selected state, a consequence-focused description, keyboard focus, and row-major focus order. The MIDI package inspector now identifies itself and its read-only report, and its actions traverse from the project-changing import decision through report/repair helpers to Close. Import safety and dismissal guards are unchanged.

Verification: PRIMARY_UI_VISUAL_STATE reports packageFocus=1 and gridColourA11y=1 while the existing popup, toolbar, arranger, synth-navigation, and typography contracts remain green.

Subagents: Ampere and Hooke were assigned popup inventory and accessibility-risk reviews, but the subagent service did not return an assignment receipt after repeated waits. LT completed the bounded audit, implementation, and verification locally rather than blocking the pass.

Future connection: The same metadata helper pattern can name preset tiles, routing destinations, and user-defined palette entries without forcing visible labels into compact interfaces. Cross-check finding: The full MIDI closeout sweep caught a responsive-layout overwrite that renamed lane-owned actions as COPY PAD SETTINGS / PASTE PAD SETTINGS after opening the instrument drawer. The controls still targeted the lane instrument, but the words lied. The layout now preserves COPY INSTRUMENT / PASTE INSTRUMENT, and the closeout diagnostic reports each contributing predicate if this contract fails again. The focused instrument-UI slice and full MIDI closeout gate both pass.

2026-08-10 - Modal Choices Need A Single Reading Order

Task: Bring Pad Vault choices, pattern fusion, and Library favorite selection into the same keyboard and accessibility contract without changing what any choice applies.

Creative connection: Runtime-generated choices appear throughout SpaceAge: saved sounds, presets, patterns, routing destinations, hardware profiles, and future Instrument Bay records. One helper now gives these controls a consistent vocabulary of purpose, consequence, focus eligibility, and visible-order traversal. This lets compact dialogs remain visually light while still being understandable to keyboard and assistive-technology users.

Architecture choice: JUCE's existing modal launch option remains the sole Escape-to-cancel owner, avoiding duplicate close callbacks. Each panel now publishes its title, purpose, and cancellation behavior. Every generated Vault choice, pattern choice, favorite toggle, and supporting action has a readable title, consequence-focused description, and unique focus order. Modal click-away remains intentionally disabled because these dialogs stage multi-step decisions; Cancel or Escape leaves without applying work.

Verification: PRIMARY_UI_VISUAL_STATE reports selectionDialogs=1, constructing all three panels and recursively proving complete metadata plus contiguous focus order. LIBRARY_LAYOUT and ARRANGER_EDIT_CONTRACT remain green. git diff --check reports no whitespace errors.

Subagents: Ampere and Hooke were assigned independent lifecycle and accessibility audits, but the subagent service did not return assignment receipts. LT stopped the attempt and completed the bounded audit, implementation, and verification locally so the pass did not stall.

Future connection: Instrument Bay pickers, Yamaha XG parameter lists, and plugin/preset browsers should use the same helpers rather than creating another local tab-order convention.

2026-08-10 - Every Parameter Must Occupy Real Space

Task: Repair the Loop Processor callout so every audible parameter is visible, reachable, named, and dismissible without changing loop DSP or saved settings.

Creative connection: Hidden controls are more dangerous than missing controls because the audio engine can express a state the interface cannot explain. The same geometry-and-meaning contract now used by dynamic dialogs can protect effect editors, Instrument Bay inspectors, hardware editors, and future motion panels: an interactive parameter must have non-empty contained bounds, a readable name, a consequence, and a stable keyboard position.

Architecture choice: The twelve existing loop processors and fade curve retain their current processor ownership and immediate update callbacks. The first three columns remain three rows; the final column now has four rows for Width, Fade In, Fade Out, and Curve. The callout is taller rather than shrinking controls. Escape dismisses it, click-away keeps JUCE's existing callout behavior, and all thirteen controls follow one explicit order.

Verification: PRIMARY_UI_VISUAL_STATE reports loopProcessor=1, recursively rejecting empty or out-of-bounds interactive geometry as well as incomplete metadata or focus order. REALTIME_LOOP_SNAPSHOT remains green with zero callback locks, allocations, or destruction. KEYBOARD_SHORTCUT_WORKFLOW remains green.

Subagents: Ampere and Hooke were assigned independent lifecycle and accessibility audits, but the subagent service again failed before returning assignment receipts. LT stopped the attempt and completed the bounded audit, implementation, and verification locally.

Human review flag: Confirm the 980 x 236 callout's four-column rhythm, label breathing room, and screen-edge placement at Windows scaling values of 100%, 125%, and 150% before release packaging.

2026-08-10 - Visual Modality Must Be Behavioral

Task: Make the welcome splash, startup choice, project-loading feedback, and About page behave like the layers they visually claim to be.

Creative connection: A modal surface is a temporary world. While it is visible, the song beneath it must not react to stray shortcuts, and the user must always know the next safe action. This rule connects startup, About, import/export review, future Instrument Bay browsers, hardware editors, and long-running render feedback.

Architecture choice: The welcome splash now spans the editor as a true input shield while retaining a centered 16:9 artwork card. Its Continue action is named, described, and focused. Startup actions publish a recovery-first visible focus order and move focus to the first available safe choice. During project loading, disabled actions cannot be re-triggered and focus moves to the non-dismissible startup surface. About focuses Close when opened, Escape closes it, and focus returns to About. Unhandled keys are consumed by these surfaces instead of changing the workspace behind them.

Verification: STARTUP_DIALOG_LAYOUT reports geometry=1, accessibility=1, modalGuards=1, and coverage=1 at both supported viewports. PROJECT_LOAD_FEEDBACK remains green for honest indeterminate progress and stale-completion protection. PRIMARY_UI_VISUAL_STATE remains fully green.

Subagents: The subagent service had failed twice before this pass without creating agents, so the critical path stayed local. LT performed separate lifecycle and accessibility reviews and integrated both into one bounded change.

Human review flag: Confirm welcome-card spacing, background shielding, focus outline visibility, and About focus return at Windows scaling values of 100%, 125%, and 150%.

2026-08-10 - Persistent Chrome Must Reflow Before It Shrinks

Task

Make the high-use header and page-navigation surfaces remain truthful, legible, and keyboard-accessible across SpaceAge's supported window widths.

Connected thinking

• A responsive header is not cosmetic. It protects transport truth, project identity, hearing-safety controls, and page navigation from competing for the same pixels.
• Reserving global actions before distributing page-tab width establishes a reusable layout rule for future tabs, translated labels, plugin-host controls, and accessibility scaling.
• Explicit left-to-right keyboard focus makes the visual hierarchy usable without a mouse and prevents future controls from silently entering an arbitrary tab order.
• The compact header's second row reduces page height, so every underlying workspace must be checked as part of the same change. That connection exposed and corrected the Library's bottom-reserve regression.

Implementation

• Wide windows retain a single-row information header.
• Windows below 1580 px use two deliberate rows: identity/session actions above, transport/status below.
• Navigation allocates Multi-Out, Reset Audio, Panic, Undo, and Redo first, then evenly distributes the seven page tabs through the remaining width.
• Persistent controls now publish an explicit 18-stop keyboard focus order.
• The compact Library instruction area and top margin were tightened without removing controls or reducing their tested minimum readable sizes.

Evidence

PRIMARY_UI_VISUAL_STATE, LIBRARY_LAYOUT, SETTINGS_ROOT_LAYOUT, ARRANGEMENT_OVERVIEW_LAYOUT, and MIXER_LAYOUT pass at the tested wide and minimum-supported geometries.

Human review still useful

Inspect the 1100 px header at 100%, 125%, and 150% Windows scaling, especially long project names and the time/beat readouts. Automated geometry proves containment and ordering, but human eyes remain the authority on perceived balance.

Responsive synth follow-through

The compact header revealed that responsive work cannot stop at page boundaries. SoundFont's 13 controls were redistributed from five rows to four; Propulsion's lower globals became a two-row nine-column bank; Liftoff and Moonshadow use wider grids with fewer vertical rows; Mod/Choke route selectors gained sufficient vertical target area. This preserves every parameter while preventing the final rows from being clipped at the minimum supported viewport.

Connection: the same available rectangle first, control count second rule should govern future synth pages and plugin editors. Fixed row heights are acceptable only when their cumulative height is proven against the smallest supported editor.

2026-08-10 - Diagnostic Cockpits Need Command Decks, Not Button Ribbons

Task

Remove MIDI Health header crowding without changing any diagnostic, routing, proof, or MIDI behavior.

Connected thinking

• A diagnostic cockpit has two hierarchies: the next action and the supporting evidence actions. Compressing both into one horizontal ribbon makes every action look equally important and forces labels into abbreviation.
• The five-by-two command deck preserves the existing semantic order while giving each action enough width to remain readable. The first row contains immediate health/proof operations; the second row contains supporting copy and handoff operations.
• The panel's natural width now fits inside the 1100-pixel display contract, so the report scrolls vertically without making users chase controls horizontally.
• Explicit focus order follows the same row-major order, connecting the visual hierarchy to keyboard and assistive-technology behavior.
• This pattern can be reused by future Hardware Passport, SysEx, and XG editor cockpits: group commands by task sequence, keep deep evidence vertically scrollable, and never turn ten meaningful actions into ten tiny pills.

Evidence

SETTINGS_ROOT_LAYOUT reports command geometry, accessibility summary, scroll-shell reachability, and minimum-display viewport compliance. SETTINGS_DESTINATION_REACHABILITY, MIDI_HEALTH, MIDI_CLOSEOUT, and PRIMARY_UI_VISUAL_STATE remain green, proving the visual reorganization did not mutate project or MIDI behavior.

Human review still useful

Inspect the two command rows at 100%, 125%, and 150% Windows scaling. Confirm the first-row/second-row hierarchy feels natural and that vertical-only scrolling is comfortable with real MIDI warnings and repair recommendations populated.

2026-08-10 - Hardware Setup Is A Journey Map, Not A Button Ribbon

Task: Replace the MIDI Hardware Setup Guide's ten cramped top-level commands with a readable, responsive command deck.

What connects creatively: The Setup Guide already acts like a calm stage technician: it identifies a controller or external instrument workflow, shows evidence boundaries, and opens the exact diagnostic room needed next. Presenting all ten doors as a single narrow ribbon made that mental map harder to scan. The same 5 x 2 command-deck language now used by MIDI Health turns both surfaces into related cockpits: the first row establishes or checks the route, and the second row moves into diagnosis, patch data, SysEx, Automation, or a cold session copy.

Architecture choice: The change is layout-only. A shared deterministic bounds contract distributes ten commands over five columns and two 28-pixel rows with six-pixel gaps. The panel's natural width is 1016 pixels, fitting inside the 1100-pixel supported display allowance without horizontal scrolling. Its intentionally deep content remains vertically scrollable. Keyboard traversal follows the visible rows, then continues through template and target-lane controls.

Verification: Fresh SETTINGS_ROOT_LAYOUT compilation reports setupGuideCommands=1 and setupGuideViewport=1. SETTINGS_DESTINATION_REACHABILITY, PRIMARY_UI_VISUAL_STATE, MIDI_HEALTH, and complete MIDI_CLOSEOUT also pass. No MIDI, project, routing, template, or external-hardware behavior changed.

2026-08-10 - Persistent Chrome As A Trust Surface

Task: Make the application header readable, truthful, and context-aware at both wide and minimum supported layouts.

What connects creatively: The persistent header is not decoration; it is the user's instrument panel. Product identity establishes place, the project and status areas confirm consequences, the chord readout quietly teaches theory, and window controls must describe actions the current host can actually perform. This same policy can guide future variable-font work, transport simplification, and every compact feedback surface in SpaceAge.

Architecture choice: Status receipts now use a fitted one-line label while retaining the complete message in tooltip and accessibility metadata. Navigation typography responds to available width without falling below a readable floor. Hosted plug-in instances omit standalone window controls entirely, while the standalone app exposes truthful MIN and MAX/RESTORE actions. The original header height was preserved so sequencer and editor workspaces do not lose vertical room.

Verification: PRIMARY_UI_VISUAL_STATE, SETTINGS_ROOT_LAYOUT, SETTINGS_DESTINATION_REACHABILITY, MIDI_HEALTH, and MIDI_CLOSEOUT pass. Human review remains useful for unusually long project names, dense chord spellings, mixed-DPI displays, and maximize/restore behavior on a second monitor.

2026-08-10 - Identity And Context Must Outrank Decoration

Task: Close the next bounded beta-readability risks after the persistent-header pass: long project identity, decorative starfield layering, and the sequencer editing-context receipt.

What connects creatively: These surfaces answer three different versions of the same customer question: Where am I? The project label names the musical world, the sequencer receipt names the material and editing state, and the Effects/Library starfields establish atmosphere without being allowed to obscure either interaction or meaning. This hierarchy can guide future Motion Clip animation, Instrument editor decoration, and every other living-time visualization in SpaceAge.

Architecture choice: Project and editing-context labels now fit a single line while retaining their complete source text in tooltip and accessibility metadata. The Piano Roll editing receipt expands into the unused first-row space at compact widths and receives a larger bounded allocation at wide widths; Drum Composer receives the same treatment. Animated starfields retain their existing brightness and timing, but the Effects starfield is reasserted as the lowest child after card ordering so hover, focus, border, and EDIT feedback always paint above it.

Verification: PRIMARY_UI_VISUAL_STATE reports chromeText=1, backdropLayering=1, and editingContext=1 at 1800x1000 and 1100x800. EFFECTS_DETAIL_LAYOUT, LIBRARY_LAYOUT, SETTINGS_ROOT_LAYOUT, and complete MIDI_CLOSEOUT also pass. Human review remains useful for unusually long project/clip names, dense loop-range text, and starfield contrast at mixed Windows scaling.

2026-08-10 - One Instrument Authority, Honest Readiness, Visible State

Task

Close three bounded beta-trust gaps: contradictory Instrument choices, disappearing compact patch identity, and an undersized Mixer meter readout.

Connected thinking

• Lane creation and lane reassignment are two doors into the same Instrument Bay. They must use one authoritative tonal-engine list or customers learn two conflicting versions of what SpaceAge can play.
• SoundFont and Quasar are valid Instruments but require user content. Separating Ready To Play from Load Your Source After Adding preserves their discoverability without pretending they can sound immediately.
• Patch identity and meter values are receipts, not decoration. A compact layout that preserves knobs but hides the loaded patch or dB value still fails to communicate musical state.
• The same pattern can guide future VST and hardware entries: advertise capability, state readiness honestly, and preserve complete identity semantically when visible space becomes constrained.

Implementation

• Add Lane and lane reassignment now share one ten-engine Arrangement Instrument authority.
• Add Lane groups native engines into ready-to-play and source-backed choices; SoundFont and Quasar are offered with explicit source-loading guidance.
• Compact Classic Synth moves its patch receipt to a full-width second row while wide layouts retain the established single row.
• Every native patch receipt publishes the complete engine, patch, saved/modified state, and active-Instrument context through tooltip and accessibility metadata.
• Mixer channel meters use the available strip width for their dB receipt while preserving all fader, M/S, output, panel, routing, and DSP geometry.

Evidence

PRIMARY_UI_VISUAL_STATE reports laneEngineChoices=1. SYNTH_CONTROL_QUALITY reports patchIdentity=1 across 712 controls at 1800x1000 and 1100x800. MIXER_LAYOUT reports meterReadout=1 across 2,306 surfaces. Arrangement overview, Arrangement recording, and complete MIDI closeout gates also pass.

Human review still useful

Inspect Add Lane wording, Classic patch identity, and Mixer dB values at 100%, 125%, and 150% Windows scaling. Confirm that source-backed Instrument wording feels instructional rather than punitive and that the wider meters remain visually calm.

2026-08-10 - Destination Actions Must Name Their Owner

Task: Close two bounded beta-trust gaps: indistinguishable Pad CREATE controls and incomplete next-action guidance after assigning a fresh source-backed Instrument.

Creative connection: A compact icon and a status receipt solve the same human problem: they must identify the destination and explain the consequence. That rule connects Pad actions, Arrangement lane reassignment, future Instrument Bay entries, hardware-editor commands, and every source-backed device SpaceAge may add later.

Architecture choice: Each visible Pad CREATE action now publishes its absolute Pad number, custom Pad name, current source, unique component identity, and row-major focus order. The metadata is rebuilt by the existing Pad refresh authority, so bank changes, renames, and source replacement cannot leave stale accessibility text. SoundFont and Quasar now share one source-backed next-action formatter across Add Lane and Replace Instrument workflows. Ready-to-play engines deliberately return no load warning.

Verification: PRIMARY_UI_VISUAL_STATE checks all 64 Pad CREATE destinations and reports padSynthA11y=1; it also pins SF2, Quasar-package, and ready-engine guidance. Complete MIDI_CLOSEOUT passes, including fresh lane Instrument replacement, clip preservation, private Instrument identity, Mixer/MIDI routing, live input targeting, editor targeting, and project round-trip.

Subagents: Raman found the duplicated Pad CREATE accessibility identity. Leibniz found the missing Quasar follow-up receipt and independently confirmed that lane creation, selection, Add Clip targeting, and ownership paths were otherwise coherent.

Human review flag: Use Narrator or NVDA to traverse each Pad bank after renaming a Pad and replacing its source. Confirm the announcements are concise and that row-major focus feels natural at 100%, 125%, and 150% Windows scaling.

2026-08-10 - Visibility And Ownership Are Data-Integrity Features

Task: Close two remaining beta-trust failures: large Pad Vault categories hiding saved sounds and empty drum lanes opening Drum Composer against a stale pattern.

Creative connection: A saved sound that exists but cannot be reached feels deleted; an editor that displays one lane while mutating another feels corrupt. Both failures come from separating visible context from the data authority underneath it. The same rule should govern future preset browsers, Instrument Bay search, hardware patch librarians, Motion Clip collections, and every contextual editor: all owned data must remain reachable, and every editor must have one explicit owner before it can open.

Architecture choice: Pad Vault retains its compact four-column appearance but places the natural-height choice grid inside a vertical viewport. Keyboard focus reveals the focused sound automatically, and the first, middle, and final entries of a 64-sound fixture must remain actionable. Drum Composer now refuses an empty-lane editor request before changing lane destination, clip, pattern, page, or musical state; its receipt directs the user to Add Clip.

Library language: Missing-asset guidance now describes referenced audio and Instrument sources rather than implying that only samples and loops can be repaired.

Verification: PRIMARY_UI_VISUAL_STATE, the focused Instrument UI closeout slice, LIBRARY_LAYOUT, MISSING_ASSET_REPAIR, and complete MIDI_CLOSEOUT pass. The closeout reports emptyDrumLaneGuard=1.

Subagents: Leibniz identified the Pad Vault overflow and missing 64-entry regression. Raman identified the empty drum-lane stale-pattern ownership path. Both audits were read-only; integration and verification remained centralized.

2026-08-10 - Selection Ownership And File Moves Are Transactions

Task: Close two beta-trust failures: a newly added Instrument clip could appear selected while immediate Piano Roll edits still targeted the previous pattern, and Pad Vault Move could report success after a partial or invalid file operation.

Creative connection: Visual selection, musical ownership, and the next edit target are one user action. Treating them as one transaction makes Add Clip, future drag-and-drop imports, duplicate/variant workflows, and Instrument Bay creation predictable. The same transaction principle applies to user files: validate, stage, verify, commit, then remove the original. This model can be reused for preset moves, project relocation, sample-browser organization, and future hardware librarian operations.

Architecture choice: Successful Add Clip now commits the new clip's pattern, Arrangement selection, lane-owned Instrument route, sequencer refresh, and editor refresh together. Pad Vault Move now refuses malformed sources, writes and reparses a temporary destination, commits a unique verified file, and deletes the source last. A failed source deletion rolls back the destination so the operation cannot silently become a copy while claiming to be a move.

Verification: PAD_VAULT_TRANSACTION passes malformed-input refusal, simulated write rollback, simulated source-delete rollback, and successful move. Complete MIDI_CLOSEOUT passes with arrangementClipPlacement=1, including an immediate note edit after Add Clip while a stale pattern was previously selected. PRIMARY_UI_VISUAL_STATE and LIBRARY_LAYOUT also pass.

Subagents: Leibniz found the Pad Vault false-success/data-loss path. Raman found the stale Add Clip editing target. Integration and verification remained centralized.

2026-08-10 - Destinations Must Not Rewrite Ownership

Task: Protect existing MIDI exports from failed replacement and keep hardware-output selection from silently changing a lane's explicit playback target.

Creative connection: A destination answers where data goes; it must not redefine what the data belongs to or which sound source is authoritative. That principle connects file export, lane MIDI routing, Instrument Bay assignment, Mixer reassignment, project relocation, and future hardware librarian transfers. Each workflow should stage and verify a destination change while preserving the user's explicit ownership decision.

Architecture choice: Every current MIDI writer now uses one shared transaction: write to a hidden temporary file, close and reparse it, then atomically replace the destination. Pattern, clip, lane, Arrangement/chain, drum Arrangement, and TempoCalc exports no longer delete an existing customer file first. In the Arrangement lane MIDI panel, changing the hardware output changes only the output device; INTERNAL ONLY, INTERNAL + HARDWARE, or HARDWARE ONLY remains an independent explicit choice.

Verification: MIDI_EXPORT_ATOMIC_REPLACE simulates write, staging, and pre-commit failures and proves the previous destination remains byte-for-byte intact with no abandoned temporary file. Successful replacement reparses as valid MIDI. MIDI_EXPORT, MIDI_HEALTH, and complete MIDI_CLOSEOUT pass; closeout reports outputRouteOwnership=1 for a real panel interaction that changes the device while preserving HARDWARE ONLY.

Subagents: Leibniz identified the delete-before-write export family and specified the preservation contract. Raman identified hardware-output selection rewriting route ownership and specified the real-panel regression. Integration and verification remained centralized.

2026-08-10 - Saved Sound Design Is A Multi-File Transaction

Task: Close two P1 patch-integrity gaps: Liftoff/Lunacy save-over could publish a replacement waveform before the patch document committed, and Instrument variants could preserve modified audio while falsely describing the copied patch as saved.

Creative connection: A synth patch is more than a row of knob values. Source-backed engines own a small package whose document and audio must agree, while a variant owns both an audible state and an honest provenance receipt. The same transaction boundary can guide Quasar packages, future multisample formats, VST preset capture, sample-browser relocation, hardware librarians, and SpaceAge Scenes.

Architecture choice: Source-backed saves now stage a uniquely named WAV, verify that JUCE can decode it, commit the .ssynth document last, and remove the formerly referenced bundled source only after success. Failure at source copy, source verification, or document commit preserves the old patch and old waveform byte for byte and removes the new staged asset. Instrument copy and Variant paths now transfer patch name, engine, dirty provenance, and saved comparison fingerprint alongside processor-owned sound state.

Verification: INSTRUMENT_PATCH_LIFECYCLE passes failure injection at all three publication boundaries and successful replacement of both package halves. PAD_VAULT_TRANSACTION, SYNTH_CONTROL_QUALITY, and complete MIDI_CLOSEOUT pass; closeout reports laneInstrumentVariantWorkflow=1 while preserving clips, notes, chords, Mixer assignment, MIDI ownership, independent Instrument ID, copied parameters, and PATCH | Name *.

Subagents: Leibniz identified the cross-file save-over corruption window and specified its rollback contract. Raman identified the editor-owned patch provenance omitted by Instrument Variant and specified the customer-facing regression. Integration, failure injection, and full closeout verification remained centralized.

Human review flag: Save over a real Liftoff and Lunacy patch using a different same-named WAV, reload it, and confirm the expected source and controls. Modify a named Redshift patch, make the lane a Variant, and confirm both Instrument editors retain the asterisk until each is independently saved.

2026-08-10 - A Fresh Instrument Must Be Truthful Before It Is Clean

Task: Prove that Add Instrument Lane produces the promised engine, patch identity, audible state, and clean presentation rather than merely applying a factory preset in an isolated test.

Creative connection: The first sound from a new lane teaches the customer what Instrument Bay ownership means. The lane label, editor patch receipt, audible model, Mixer route, and unsaved-state marker therefore form one onboarding transaction. This same rule can guide future VST defaults, hardware profiles, templates, and SpaceAge Scenes: finish the actual sounding state first, then publish its clean identity.

Architecture choice: Fresh native Instruments now complete all engine-specific initialization before capturing the clean patch fingerprint. Physical Modeling genuinely starts as the labeled Callisto Marimba rather than a generic membrane, and TG-55's initial patch is honestly named Io Bell. The startup path no longer shows an immediate false * merely because initialization continued after the fingerprint was taken.

Verification: FACTORY_INSTRUMENT_DEFAULT now creates real Arrangement lanes for every ready-to-play native engine and verifies engine ownership, neutral lane pitch, exact patch label, no false dirty marker, finite audible output, bounded peak, and complete voice release. FACTORY_PRESET_SAFETY passes all 619 factory presets with deterministic fingerprint 4d2ddc400437c5d6. SYNTH_CONTROL_QUALITY, AUDIO_SAFETY_CONTINUITY, MIDI_CLOSEOUT, and MIDI_HEALTH also pass.

Subagents: Kepler and Hubble were assigned independent startup-state and coverage audits, but the subagent dispatcher stalled before returning agent IDs. No subagent result was used; implementation and verification remained local.

2026-08-10 - Technical Depth Should Scroll, Not Shrink

Task: Continue the U01/U02/U03 presentation pass by improving dense MIDI setup surfaces without hiding controls, adding horizontal scrolling, or changing MIDI behavior.

Creative connection: Hardware guidance is part of the musical workflow, not a diagnostic afterthought. The same visual rule can connect MIDI setup, patch librarians, Quasar capture, missing-asset repair, and future VST scanning: retain a calm fixed width, use a readable row rhythm, and let deep evidence move vertically. A scroll gesture is recoverable; microscopic text is not.

Architecture choice: The MIDI Hardware Setup Guide now has a larger natural vertical canvas inside the established Settings scroll shell. Scenario cards use taller rows and a 9.5-point minimum for tertiary text, 10-point detail text, and 10.5-point body text. OPEN actions, state badges, selected-scenario guidance, template previews, and safety receipts no longer rely on 7-to-9-point text. MIDI Sync Preflight receives the same treatment for verdict, next-action, last-observed, empty-state, and safety text while leaving its compact numeric rows intact.

Verification: Fresh Release compilation passes. SETTINGS_ROOT_LAYOUT reports setupGuideTypography=1 and syncPreflightTypography=1; SETTINGS_DESTINATION_REACHABILITY passes 28/28 launches with 306/306 named controls and cold project state. PRIMARY_UI_VISUAL_STATE, AUTOMATION_EDITOR_LAYOUT, MIDI_HEALTH, and complete MIDI_CLOSEOUT remain green.

Subagents: Kepler, Hubble, and Wegener were assigned Synth/Effects, Arrangement/Mixer, and Settings/Library audits. The dispatcher stalled before returning an agent ID, so no subagent output was used. Implementation, integration, and verification remained local.

Human review flag: Inspect the MIDI Hardware Setup Guide and MIDI Sync Preflight at 100%, 125%, and 150% Windows scaling. Confirm that vertical scrolling feels deliberate and that long hardware/profile names remain comfortable rather than merely technically contained.

2026-08-10 - Destructive Dialogs Must Look And Feel Like SpaceAge

Task: Remove the remaining route by which clear, rename, and Instrument-change dialogs could fall back to generic JUCE or Windows presentation.

Creative connection: A warning is part of the instrument, not an operating-system interruption. The same calm visual language that makes the Arrangement Canvas and Synth Engine understandable should carry through destructive decisions, patch changes, missing-asset recovery, hardware setup, and future plug-in scanning. Consistency at the moment of risk helps the customer trust both the action and its consequence.

Architecture choice: The shared SpaceAge look-and-feel now owns alert background, text, outline, title, message, control, and button typography. Asynchronous clear confirmations are explicitly associated with the main editor, while rename and Instrument-change windows explicitly receive the editor look-and-feel. This prevents ownership ambiguity from selecting a generic presentation.

Verification: PRIMARY_UI_VISUAL_STATE now reports alertPresentation=1 and rejects missing palette values or undersized alert typography. SEQUENCER_CLEAR_SCOPE, SETTINGS_ROOT_LAYOUT, AUTOMATION_EDITOR_LAYOUT, MIDI_HEALTH, and complete MIDI_CLOSEOUT all pass. No customer build was produced.

Subagents: No subagent work was used in this pass; the issue was concentrated in one presentation ownership path and was implemented and verified locally.

2026-08-10 - Safety Language Needs A Visual Home

Task: Extend the SpaceAge dialog contract beyond the principal clear/rename workflows to every discovered import, Pad Vault, Pad Bank, timing, hardware recall, RPN/NRPN, pitch-bend, SysEx, and beta-evidence confirmation.

Creative connection: SpaceAge often explains not only what an action will do, but what it deliberately will not do. That safety language is part of the hardware-handholding advantage. Giving it a stable visual owner connects cosmetic polish to MIDI safety, project trust, accessibility, and future device editors: the customer should never have to wonder whether a generic-looking window belongs to SpaceAge or to another layer of the computer.

Architecture choice: Every discovered MessageBoxOptions confirmation now names its associated SpaceAge component. Informational alerts use one owner-requiring helper instead of JUCE's ownerless convenience path. Custom Pad Vault and beta-evidence AlertWindows explicitly inherit the active SpaceAge look-and-feel. Behavior, routing, and confirmation wording remain unchanged.

Verification: PRIMARY_UI_VISUAL_STATE reports alertPresentation=1; all 28 Settings destinations and 306 visible interactive controls remain reachable and named. MIDI_HEALTH and complete MIDI_CLOSEOUT pass, including hardware-route ownership, live automation, recording targets, lane Instrument ownership, and safety receipts. No customer build was produced.

Subagents: No subagent work was used in this pass. The bounded ownership migration and its cross-system verification remained local.

2026-08-10 - Onboarding Should Use The Instrument, Not Describe It From Afar

Task: Give a first-time musician a complete, discoverable start-to-song path inside SpaceAge without adding another permanent toolbar control.

Creative connection: The About page already occupies a calm, optional surface and the startup chooser already begins every standalone session. Connecting those surfaces turns branding into orientation without interrupting composition. The guide also becomes a compact statement of the architecture: a lane is the performer, a clip is musical material, Piano Roll/Drum Composer/Chord Engine are writing tools, Arrangement establishes form, Mixer owns processing, and Library/Render preserve or publish the result. Future templates, tutorials, contextual help, and an in-app support agent should all reuse this vocabulary.

Architecture choice: About is now an explicit hub rather than an artwork-sized hidden website link. START SONG GUIDE opens six large workflow cards; WEBSITE is a separate deliberate action; BACK TO ABOUT, X, and Escape provide predictable exits. The screen-reader description names the actual controls and workspaces. No song state, routing, transport, or audio behavior changes.

Verification: STARTUP_DIALOG_LAYOUT opens the production About hub at 1800x1000 and 1100x800, enters and leaves the guide through the real callbacks, verifies control containment and minimum sizes, requires the complete accessible workflow vocabulary, and confirms Escape dismissal. Neighboring primary UI, shortcut, MIDI Health, and MIDI closeout gates remain part of the pass.

Subagents: No subagent result was used. This was a bounded presentation and onboarding integration implemented and verified locally.

Human review flag: Read the guide at 100%, 125%, and 150% Windows scaling. Follow it from a blank project without relying on remembered SpaceAge behavior, and record any step whose wording does not match the visible control.

2026-08-10 - A Startup Choice Must Complete A Real Action

Task: Remove the first-run LOAD TEMPLATE dead end while preserving a useful path into reusable musical material.

Creative connection: Full song templates and smaller Starting Points belong to one future Library family, but they are not the same promise. A Starting Point can be a kit, Instrument, or prepared sound source; a project template can later add lanes, routing, form, tempo, and Mix state. Keeping those categories honest now lets the Library grow into a broader launch catalog without teaching the customer to click controls that do nothing.

Architecture choice: The startup chooser now offers BROWSE STARTING POINTS, describes the ready-made kits and Instruments that actually exist, opens the real Library catalog, reports the next action, and places keyboard focus on its first usable choice. No project format or musical state was changed.

Verification: STARTUP_DIALOG_LAYOUT invokes the production callback and requires truthful copy, Library navigation, visible/enabled Starting Points, and a useful status receipt. LIBRARY_LAYOUT, PRIMARY_UI_VISUAL_STATE, KEYBOARD_SHORTCUT_WORKFLOW, PROJECT_LOAD_FEEDBACK, MIDI_HEALTH, and complete MIDI_CLOSEOUT all pass from the rebuilt Release test binary.

Subagents: No subagent work was used. The defect and destination were both contained in the startup/Library presentation path.

Human review flag: Launch standalone at 100%, 125%, and 150% Windows scaling, choose Browse Starting Points with mouse and keyboard, and confirm that the Library destination and first choice feel immediate. Future full-project templates should join this catalog only when they load a complete, real session.

2026-08-10 - Roadmap Ideas Do Not Belong In Working Menus

Task: Remove disabled coming soon commands and correct the L/S/V lane-badge guidance so every advertised Arrangement action is real.

Creative connection: The lane command badges are compact enough to become a durable home for advanced workflow, but only after each feature exists. Keeping the menu executable protects the same focused-power philosophy as the startup chooser and Instrument Bay. Future lane ordering, persistent collapse, colors, ghost shortcuts, and clip-detail options can return one at a time with their implementation, Undo contract, persistence, accessibility, and regression proof.

Architecture choice: Lane Structure now exposes Rename, Add Clip Target, and Full Lane View. Lane Signal/MIDI retains its five working Automation, routing, input-arm, Instrument, and Passport actions. Lane View exposes Full Lane View without claiming ghost, color, or display controls that are not wired there. Tooltips describe this exact production behavior.

Verification: PRIMARY_UI_VISUAL_STATE opens all three production lane panels and rejects disabled, coming soon, or unavailable items. ARRANGEMENT_LANE_VISUAL_STATE, ARRANGEMENT_OVERVIEW_LAYOUT, KEYBOARD_SHORTCUT_WORKFLOW, and complete MIDI_CLOSEOUT pass from the rebuilt Release test binary.

Subagents: No subagent work was used. The stale promises and their regression owner were localized to the lane command surface.

Human review flag: Open L, S, and V from several Instrument and Drum lanes at supported Windows scaling. Confirm their shorter menus feel intentional and that each action's consequence is obvious.

2026-08-10 - A Starting Point Name Is A Sound Promise

Task: Correct the two Library Starting Points whose visible names did not match the sound families their callbacks loaded.

Creative connection: Starting Points can become the approachable front door to Instrument Bay presets, teaching material, and future project templates. That only works when the label, callback, underlying model, and resulting sound all describe the same idea. Truthful names make auditioning faster and also give future metadata, search, and educational descriptions a dependable identity.

Architecture choice: The physical-model bank callbacks remain unchanged: the tuned-bar bank is now labeled CHROMATIC MARIMBA, and the physical bass bank is labeled STACCATO BASS. The Library regression requires both exact labels, live callbacks, Starting Points ownership, and the expected group heading without mutating the customer's project during the test.

Verification: LIBRARY_LAYOUT reports startingPointIdentity=1. STARTUP_DIALOG_LAYOUT, PRIMARY_UI_VISUAL_STATE, MIDI Health, MIDI Protocol, Automation Ownership/Restore, and complete MIDI_CLOSEOUT all pass from the rebuilt Release test binary.

Subagents: No subagent work was used. The mismatch and its release owner were localized to the Library Starting Points surface.

Human review flag: Audition CHROMATIC MARIMBA and STACCATO BASS across several registers and confirm each result sounds like the name customers selected.

2026-08-10 - Quiet Builds Make Real Problems Audible

Task: Remove a bounded set of first-party compiler warnings from text measurement, synthesis math, EchoRay activity tracking, MIDI Learn pickup state, and offline sample rendering.

Creative connection: Compiler output is an engineering meter. If routine first-party warnings are allowed to accumulate, a new conversion, lifetime, or state-shadowing defect is easier to miss among familiar noise. A quieter build gives future human and AI maintainers a much clearer signal when a real regression appears.

Architecture choice: The 86 button now measures glyph geometry with JUCE's supported GlyphArrangement; the physical-model decay conversion is explicit; local activity iterators identify the state they own; and the offline renderer's block constant no longer masks JUCE processor state. No parameter range, serialized state, audio algorithm, MIDI policy, or customer workflow changed.

Verification: The rebuilt Release test target emitted none of the corrected first-party warnings. MIDI_PROTOCOL, SYNTH_CONTROL_QUALITY (712/712 controls), all three DRUM_LAB_FLUX_RENDER paths, PRIMARY_UI_VISUAL_STATE, and complete MIDI_CLOSEOUT pass.

Subagents: No subagent work was used. Each warning had a small, directly traceable owner and required one integrated verification pass.

Human review flag: None specific to this internal cleanup. The existing human checks for the 86 button, synth sound, MIDI pickup feel, and rendered Drum Lab files remain authoritative.

2026-08-11 - Song Form Is A Non-Destructive Map

Task: Prove every customer-visible Arrangement Form preset through the production APPLY FORM callback rather than relying on the single Modern Pop example.

Creative connection: Form presets are compositional scaffolding, not an auto-arranger. They can help a songwriter see Intro, Verse, Chorus, AABA, Blues, or through-composed proportions immediately while preserving every authored clip below. Keeping that boundary exact leaves room for future form libraries and teaching material without turning a visual planning tool into a destructive composition command.

Architecture choice: The regression now selects all eight advertised forms by their real ComboBox IDs and labels. It verifies every Section type, start, and length; proves an Instrument clip and Drum clip remain byte-identical; confirms reapplying the same form creates no extra Undo transaction; restores the original form with one Undo; and reopens the final through-composed form plus untouched clips from saved project state. Production behavior required no change.

Verification: ARRANGER_EDIT_CONTRACT, ARRANGEMENT_OVERVIEW_LAYOUT, PROJECT_PERSISTENCE, PRIMARY_UI_VISUAL_STATE, and complete MIDI_CLOSEOUT pass from the rebuilt Release test binary.

Subagents: No subagent work was used. The form catalog and its production callback were localized and the cross-system proof belonged in the existing Arranger transaction gate.

Human review flag: Apply each form to a populated musical project and judge whether the chosen proportions and Section vocabulary are musically useful and immediately understandable. Automated proof protects non-destruction, not taste.

2026-08-11 - Starting Points Must Be Playable Promises

Task: Extend Library Starting Point verification beyond labels and layout into the sound banks produced by every visible action.

Creative connection: A Starting Point is the shortest route from curiosity to music. Treating each one as a playable promise connects onboarding, sound design, synthesis safety, and Library truthfulness: the button name, configured engine, pad labels, and audible result must agree before the customer invests attention in the bank.

Architecture choice: Added the dedicated LIBRARY_STARTING_POINT_AUDIO gate. It invokes all nine production button callbacks, understands that Drunk Color Wheel intentionally fills 16 slots while the other collections fill 64, validates 528 configured pad slots, checks engine-family identity and finite core parameters, renders a representative sound from every collection, and calls Panic between banks so test voices cannot contaminate the next result.

Verification: All nine collections are audible and finite. LIBRARY_LAYOUT, FACTORY_INSTRUMENT_DEFAULT, FACTORY_PRESET_SAFETY (619 presets), AUDIO_SAFETY_CONTINUITY, PRIMARY_UI_VISUAL_STATE, and complete MIDI_CLOSEOUT also pass from the rebuilt Release test binary.

Subagents: No subagent work was used. The visible Library callbacks and their processor state were directly testable in one integrated gate.

Human review flag: Audition each collection for musical usefulness, sensible loudness, and whether its customer-facing name matches its character. Automated rendering proves function and safety, not artistic quality.

2026-08-11 - A Build Is A Product Only After It Opens

Task: Produce a customer test build after the mixer-meter and Redshift filter corrections, and remove a recurring VST3 packaging failure.

Creative connection: A successful compile is an engineering event; a launchable standalone and host-loadable plug-in are customer experiences. Treating artifact verification as part of the build connects coding, packaging, and trust into one repeatable action.

Architecture choice: The Release pipeline now normalizes only JUCE 8.0.8's generated trailing commas in moduleinfo.json, validates the result as JSON, and then runs the existing exact-inventory and real-host smoke tests. The verifier remains strict; normalization happens before verification rather than teaching the verifier to accept malformed metadata.

Verification: The full Release pipeline passes. The standalone opens and exits cleanly; the VST3 bundle contains exactly the expected files and passes scan, instantiation, audio at 44.1/48 kHz, state mutation/restoration, and editor reopen. The copied customer-test artifacts pass the same smoke checks.

Subagents: No subagent work was used. This was a localized packaging correction on the critical path to the requested build.

Human review flag: Exercise the mixer pan meters and Redshift filter modes in the packaged standalone. Automated tests prove signal behavior and launchability, while the final visual and musical judgment remains human.

2026-08-11 - Redshift Becomes A Deliberate Two-Oscillator Instrument

Task: Repair Redshift's apparently inert cutoff, expand its waveform vocabulary, and make the current startup artwork set authoritative.

Creative connection: Independent oscillator choices make timbre a compositional relationship instead of a hidden alternate-wave shortcut. A contextual SHAPE control can now mean pulse width, waveform morph, or harmonic emphasis according to the selected source, which creates depth without multiplying controls. The same explicit-state principle applies to startup artwork: the first impression must come from the curated marketing set, not a forgotten embedded image.

Architecture choice: Redshift now exposes twelve musical waveform families independently for Oscillator 1 and Oscillator 2. Discontinuous shapes use PolyBLEP edges; additive shapes omit harmonics beyond Nyquist. The filter is a stable topology-preserving state-variable design with explicit Off, low-pass, high-pass, and band-pass behavior. Factory presets select an audible filter mode rather than storing expressive cutoff values behind a bypass. Startup rotation embeds exactly the current four-image set; About artwork remains separate.

Verification: Focused regressions measure cutoff attenuation and mode output, require all waveform choices to remain finite and audible, prove Oscillator 2 independence and contextual SHAPE behavior, and reject factory Redshift patches whose filter is bypassed.

Subagents: Kepler was assigned shipping-art metadata and documentation; Herschel was assigned Redshift regression coverage. Agent startup did not complete reliably, so the primary task integrated and verified both scopes directly rather than waiting.

Human review flag: Audition every waveform across low, middle, and high registers; judge aliasing, relative loudness, useful SHAPE ranges, filter resonance, and whether existing preset identities remain musically satisfying.

2026-08-11 - Stable Identity And Isolated Proof Make Responsive UI Safer

Task: Converge the launch matrix without weakening tests or mistaking fixture contamination for product behavior.

Creative connection: Stable component IDs serve accessibility, automation, support diagnostics, and regression testing at once. Visible wording and responsive layout can evolve without making the control impossible to identify. Isolated audio fixtures serve the same principle in DSP: every measurement should hear only the source it claims to test. Deterministic VST metadata normalization then extends that identity discipline to the packaged plug-in.

Architecture choice: Mixer and Synth Editor tests now target explicit component IDs instead of obsolete labels or anonymous controls. Audio brightness renders retire prior voices before each measurement. JUCE-generated VST3 metadata is normalized identically after development and Release builds, with strict JSON validation still required before inventory and host smoke tests.

Verification: reports/broad-selftest-launch-readiness-green-20260811.out records a complete broad-suite pass. reports/release-convergence-named-green-20260811.out records 79/79 named automated gates passing, including standalone launch and strict VST3 host smoke.

Subagents: No subagent work was used. These failures crossed test identity, audio-fixture lifetime, build tooling, and packaging, so one integrated pass kept the evidence chain coherent.

Human review flag: Human beta still owns tactile control feel, musical quality, supported-display readability, real-device timing, installer/clean-machine behavior, and all rights attestations.

2026-08-11 - Exact Checkouts Must Prove The Same Product

Task: Close the two proof-only failures exposed by running the complete release matrix from an exact detached commit.

Creative connection: Reproducibility is a product feature for future maintainers. A human or AI coder should be able to retrieve one commit on another Windows machine and obtain the same legal evidence, dependency identity, and host-loadable plug-in without inheriting the original developer's working-tree quirks.

Architecture choice: Tracked text now has an explicit LF materialization policy while audio, artwork, fonts, archives, and binaries remain binary. One shared legal/provenance helper canonicalizes text for dependency, embedded-asset, TG55, and public-claims ledgers while preserving byte-exact binary hashes. Clean JUCE fallback acquisition pins both the upstream commit and Git line-ending behavior, and its verified fetched source is passed explicitly to release convergence. The clean runner also normalizes JUCE-generated VST3 metadata before strict inventory and host verification, matching every other build path.

Verification: Warm release hygiene passes; a fresh configure-only detached checkout fetches 4,249 JUCE files at the exact approved fingerprint f10e738b0d374847daba65784a9739b199b0a801dc8bf9fcc26cff73f02cac67; VST3 inventory and real-host scan/instantiate/process/state/editor smoke pass after normalization. The final exact-commit convergence run remains the authoritative closing proof.

Subagents: No subagent work was used. The defects crossed Git checkout semantics, dependency acquisition, legal evidence hashing, and generated VST3 metadata, so one integrated owner kept the proof chain consistent.

Human review flag: None for the proof tooling itself. Installer, named-host, physical MIDI, mixed-DPI, listening, first-song, and rights attestations remain explicitly human-owned release evidence.

2026-08-11 - A Control Must Either Shape Sound Or Leave The Instrument

Task: Continue the synth audit by finding registered controls that had no runtime audio consumer.

Creative connection: Parameter honesty connects sound design, preset trust, automation clarity, and maintainability. A control that merely moves and recalls teaches the musician a false model of the instrument, while also creating useless project state and future migration work.

Architecture choice: A registry-to-runtime reference audit identified two orphans. The generic Synth PHYSICAL MODEL knob was removed because the real Physical Model is a dedicated engine, not an undefined blend. The hidden Strip Compressor Amount was removed because the Mixer already exposes the complete compressor model. The active compressor controls remain unchanged.

Verification: SYNTH_CONTROL_QUALITY now rejects either retired parameter if it reappears. Focused Mixer, patch lifecycle, preset, audio-safety, MIDI, and release-hygiene gates cover the affected boundaries.

Subagents: Kepler was assigned beta-blocker ranking and Banneker was assigned remaining weak-control review. The dispatcher stalled before returning either identity, so both attempts were terminated and no findings were used.

Human review flag: Confirm that the generic Synth page no longer displays PHYSICAL MODEL, and that the Mixer Dynamics panel still presents Enable, Threshold, Ratio, Attack, Release, and Makeup with no missing function.

2026-08-11 - Three Independent Paths Make A Synth Claim Harder To Fake

Task: Continue beta-readiness work by strengthening audible proof for the native tonal engines without confusing parameter registration with musical effect.

Creative connection: A reusable engine should be testable from three different directions: source identity, a defining synthesis control, and a shaping or motion control. That pattern can later govern effects, Motion Clips, hardware editors, and modulation routing. It catches the class of defect where a knob is visible, persistent, and wired to a variable, yet its practical range contributes no meaningful sound change.

Architecture choice: The native synth audibility gate now adds a third measured path for every covered engine: Propulsion unison, Liftoff warp, Glass Moon brightness, Moonshadow brightness, Lunacy grain size, Physical Model damping, and TG-55 character. Each comparison requires finite audible output and a measurable change in RMS, high-frequency motion, or deterministic signal signature.

Subagents: Raman and Popper were assigned independent readiness and source-risk audits. Both remained running without returning findings, so they were shut down and no delegated result was used. The bounded audio-contract work remained local.

Human review flag: Sweep these seven controls on sustained notes and chords in low, middle, and high registers. The automated gate proves effect, not taste; ranges that feel abrupt, weak, or useful only at an extreme still need human refinement.

2026-08-11 - Test Controls In The Context That Gives Them Meaning

Task: Continue the native-engine audit by proving controls that depend on stereo direction, a short transient, an active synthesis mode, or motion over time.

Creative connection: This same context-aware contract can govern future modulation routing, Motion Clips, hardware editors, and effects. A pan control should prove direction, an envelope control should prove time shape, and a mode-dependent control should prove both its active behavior and its inactive explanation.

Architecture choice: The audio fixture now retains separate left/right energy and an eight-millisecond transient derivative while preserving its steady-state metrics. Eight specialized A/B scenarios activate the exact DSP context required by each control instead of pretending one generic waveform comparison can answer every question.

Verification: SYNTH_CONTROL_QUALITY reports all eight specialized paths green (contextAware=11111111) alongside 710/710 visible control accessibility and the existing Redshift, shared-filter, source, motion, and ordinary-range proofs.

Subagents: Avicenna mapped the DSP consumers and recommended context-correct A/B pairs. Hooke audited factory values, UI ranges, chord safety, and main-versus-advanced placement. Their findings informed both the regression and the FREEZE SCAN clarification.

Human review flag: Judge Propulsion's perceived loudness while panning, Moonshadow's transient usefulness, and Lunacy Freeze Scan over longer musical phrases. The test proves behavior, not taste.

2026-08-11 - One Choice Should Produce One Predictable Instrument State

Task: Correct technically connected synth controls whose stereo, recall, or mode presentation remained misleading.

Creative connection: Constant-power placement is useful beyond Propulsion: the same contract can govern sample-layer placement, Motion Clip pan modulation, and future hardware-editor previews. Deterministic factory recall connects preset trust to education and support; two users choosing the same factory voice should hear the same starting point. Context-aware control presentation can become the shared rule for every mode-dependent synth, effect, and hardware editor.

Architecture choice: Propulsion retains independent oscillator pan through a normalized mid/side transport rather than collapsing three positions into one average. TG-55 factory selection is a full neutral transaction, while user patch loading remains a full edited-state transaction. Classic FM controls hide outside FM models; Glass Ratio/Fixed fields remain spatially stable but visibly disable when inactive.

Verification: Synth Control Quality passes 698/698 active controls, exact context presentation, equal-power Propulsion renders, and all native audio paths. Factory Preset Safety passes 619 presets after deliberately dirtying TG-55 state. Audio Safety, MIDI Health, and complete MIDI Closeout remain green.

Subagents: Avicenna derived and checked the Propulsion pan law and its measurable acceptance limits. Hooke audited TG-55 recall semantics and Classic/Glass inactive-control behavior. The primary task integrated both findings and added executable contracts.

Human review flag: Sweep each Propulsion oscillator pan while holding single notes and chords; confirm stable perceived loudness. Switch repeatedly between heavily edited TG-55 sounds and factory choices; confirm every factory voice begins consistently.

2026-08-11 - Drum Lab patches as complete instruments

• Connected patch saving to Flux Nodes because controlled per-hit variation is part of the authored Kick, Snare, or Hat instrument, not an unrelated project preference.
• Expanded each Lab patch contract to include the hidden/shared synthesis controls that audibly shape a Lab voice, while continuing to exclude Mixer gain, pan, EQ, inserts, and sends.
• Missing fields in an older patch now resolve to registered parameter defaults; missing Flux data resolves to disabled, zero-range Flux. Loading therefore cannot inherit unrelated state from the previously edited instrument.
• Added a contamination-first lifecycle test: hidden parameters and Flux state are deliberately changed, then patch loading must reconstruct the saved sound-design state exactly.

2026-08-11 - Factory sounds as reproducible instruments

• Factory preset recall now begins from a defined instrument-owned baseline before applying Internal Engine, Classic Machines, Physical Model, or Redshift values.
• This connects the factory browser to the same principle used by saved patches: a named sound must reproduce the whole audible instrument rather than inherit invisible values from the previous edit.
• Mixer state remains outside the sound. Loading a factory preset cannot unmute a lane or rewrite its gain, pan, routing, EQ, inserts, or sends.
• Native modulation routes are reset because they are part of the instrument's timbre. Lane identity, sample assets, choke/retrigger policy, and Mixer decisions remain intact.
• The regression test intentionally contaminates every owned parameter, all four modulation routes, and the routed Mixer controls, then verifies exact order-independent recall without crossing the instrument/Mixer ownership boundary. This test pattern can be reused for every future factory bank.

2026-08-11 - Retaining an asset must not make it audible

Task: Complete deterministic factory recall across every native tonal engine and Drum Lab without deleting user assets or crossing into Mixer ownership.

Creative connection: A loaded resource and an active sound source are different concepts. Keeping that distinction explicit lets a musician move between generated synthesis, imported source material, and layered playback without destructive clearing. The same rule can later govern Quasar zones, SoundFont programs, Motion Clip sources, hardware-editor previews, and scene-based orchestration: existence is durable project state; participation is an intentional routing choice.

Architecture choice: All native factory banks begin from one engine-owned baseline, then apply their recipe. Modulation routes reset with the sound. Drum Lab Flux resets, while choke and retrigger policy survive because they describe performance interaction. Samples, bonus shots, and SoundFonts survive recall. The voice allocator now consults retained audio only when explicit sample blending or a Liftoff/Lunacy imported-source mode requests it, and source-import engines allocate one primary source voice rather than every eligible layer.

Verification: FACTORY_PRESET_SAFETY passes all 619 presets with zero failures and fingerprint 4d2ddc400437c5d6. SOURCE_CARDINALITY proves retained assets remain present yet dormant, generated and imported Liftoff/Lunacy paths allocate one voice, and TG-55 remains single-source. SYNTH_CONTROL_QUALITY, SYNTH_PATCH_MIXER_OWNERSHIP, DRUM_LAB_FLUX_RENDER, AUDIO_SAFETY_CONTINUITY, MIDI_HEALTH, and MIDI_CLOSEOUT all pass.

Subagents: Avicenna audited Drum Lab/Flux ownership and found that choke/retrigger must survive sound recall. Hooke audited tonal-engine factory state and documented the broader deterministic-recall contract. The primary task integrated their findings, corrected Lunacy/Liftoff source activation, added source-cardinality proof, and reconciled the documentation.

Human review flag: Audition factory changes on lanes that already hold imported Liftoff/Lunacy sources and bonus shots. Confirm the assets remain available, generated presets sound clean and single-sourced, imported-source mode resumes correctly, and Drum Lab choke behavior remains unchanged.

2026-08-12 - A Playback Block Should Tell One Arrangement Story

Task: Continue beta-readiness work by closing realtime state mixing, responsive synth-label collisions, and stale factory-release evidence.

Creative connection: The same generation boundary that keeps an Arrangement edit from tearing through playback can later govern SpaceAge Scenes, Motion Clips, hardware-editor snapshots, and orchestration alternatives. A visual layout contract is the UI equivalent: one supported viewport should tell one readable story, without a label becoming part of a knob simply because the window became smaller. Exact preset identity ties both ideas to support: the state a musician hears, sees, and reports must be the state the release evidence names.

Architecture choice: processBlock() now acquires one immutable Sequencer Playback Snapshot and passes it through the scheduler. Legacy Chain-position mapping and lane audibility no longer consult mutable Arrangement containers. Redshift knob sizing responds to available compact-page space instead of forcing a desktop minimum through neighboring labels. Release inventory, provenance, current reports, runtime enforcement, and hygiene retain one exact locked fingerprint.

Verification: The realtime barrier holds an in-flight block while a new loop and Arrangement generation are published; the held block renders the captured generations and the next block renders the replacements with no callback locks, allocations, or destruction. SYNTH_CONTROL_QUALITY covers 628 visible controls at 1800x1000 and 1100x800 with zero label/control collisions. FACTORY_PRESET_SAFETY passes all 619 presets at fingerprint 4d2ddc400437c5d6; release hygiene, Arranger edit, audio continuity, and complete MIDI closeout also pass.

Subagents: Avicenna audited remaining audio/synth release risks and identified the stale fingerprint chain plus the missing all-preset rendered-audio matrix. Hooke audited customer-facing/runtime risks and identified the remaining direct Arrangement reads, synchronous project I/O, and an export-parity composition gap. The primary task closed the fingerprint and realtime-snapshot findings and added the responsive layout regression; all-preset audio rendering, asynchronous project I/O, and automation-plus-effects export parity remain ranked follow-ups.

Human review flag: At compact window size, inspect all four Redshift pages for visual comfort, not merely non-overlap. During playback, toggle lane mute/solo and edit clips while listening for discontinuities. Automated generation isolation proves coherence but cannot judge whether an intentional edit transition sounds musically graceful.

2026-08-12 - One Controller Burst, One Settled Public Value

Task: Remove host/listener work from the realtime MIDI performance-filter path without making controller response feel delayed.

Creative connection: This establishes a reusable two-speed control pattern for SpaceAge: the audio engine receives the newest gesture through fixed atomic state immediately, while the user interface, automation host, and support-visible parameter state receive one settled update after the audio block. The same boundary can later serve high-rate MPE expression, Motion Clip modulation, hardware-editor streams, and dense automation playback.

Architecture choice: Incoming mapped CC and pitch-wheel messages update a fixed per-pad cutoff override and serial number. The audio callback reads that override directly. A 64-bit block-change mask is consumed at the end of processBlock(), which requests message-thread publication once per changed block. The publisher scans active serials rather than a stale dirty snapshot: the latest gesture wins, a superseded publication cannot clear a newer value, and an already-settled request produces no duplicate host notification. JUCE parameter publication may run concurrently with audio, as intended, but it never executes on the realtime callback thread.

Verification: REALTIME_PERFORMANCE_FILTER floods one 512-sample block with 128 mapped controller values, then drives two adjacent blocks to different cutoffs before publication. Audio receives each newest value immediately, the final 4.3876 kHz gesture wins, parameter listeners receive no callback-thread notification, one deferred update publishes the settled value, and a second drain produces no duplicate. The complete broad application self-test also passes through hardware scheduling, project lifecycle, and audio export.

Subagents: Hooke found the original realtime host-notification hazard and later challenged the first deferred-publication design for cross-block coalescing and stale-test risk. Avicenna independently identified the broad test's obsolete immediate-APVTS expectation and specified the immediate-DSP/deferred-publication assertion order. The primary task integrated both reviews into the serial-aware publication contract and expanded regression.

Human review flag: Sweep the mapped controller slowly and rapidly through USB and 5-pin DIN paths. Confirm immediate audible response, smooth UI settling, no stuck final value, and no increase in measured monitor latency.

2026-08-12 - Exports Should End When The Sound Ends

Task: Close the release gap where full-song and stem exports always stopped after a fixed five-second tail, even when active Halostar or EchoRay settings remained audible longer.

Creative connection: A shared effect-tail budget connects sound design, rendering, progress reporting, stems, and future effect plugins through one truthful duration contract. The same processor-owned query can later drive export estimates, waveform previews, freeze warnings, and third-party effect-tail declarations without teaching each export surface a separate approximation.

Architecture choice: The processor derives one deterministic project-wide tail from enabled returns, active sends, Halostar decay/predelay/shimmer feedback, Reverb size, and EchoRay's slowest active tempo division plus feedback. The old five-second floor remains for compatibility; infinite or unsafe feedback is bounded at 45 seconds. Full mix and every stem use the same result, and the stem manifest reports the duration actually rendered.

Verification: CHAIN_AUDIO_EXPORT now requires a Halostar fixture whose derived tail exceeds five seconds, compares the entire offline render with the production live path, proves audible early decay and digital silence in the final second, and verifies identical stem duration. GOLDEN_PROJECT_LIFECYCLE derives its expectation from the same production contract and remains green.

Subagents: Mencius audited project load/save/archive responsiveness and identified synchronous message-thread preparation as the next larger responsiveness refactor. Carver audited live/offline automation and effects parity and isolated the fixed five-second export tail as the immediate bounded musical defect. The primary task implemented and verified the export correction; the asynchronous project-I/O work remains the next larger architectural candidate.

Human review flag: Export songs with long Halostar tails, slow whole-note or multi-measure EchoRay divisions, and stems. Confirm the rendered ending feels complete without an excessive silent wait, especially when Freeze or unsafe feedback is active.

2026-08-12 - Recovery Without Freezing The Musician

Task: Move recovery autosave file work away from the user-interface thread while preserving exact project state, bounded storage, and safe shutdown.

Creative connection: An autosave is a persistence transaction, not a live-session operation. Capturing one immutable project document creates a reusable boundary for later explicit Save and project-package preparation: session-owned MIDI queues and engine state settle and serialize once, then file verification, deduplication, and retention can proceed without touching the working song. The same one-active/one-latest-pending pattern can later keep waveform caches and library indexing responsive without allowing stale background work to accumulate.

Architecture choice: Live processor state is captured and serialized on the message thread because project capture flushes session-owned MIDI edits and JUCE project values are not deeply immutable by type. A low-priority worker receives only immutable JSON plus file paths; it owns every file read, transactional write, semantic verification, duplicate comparison, and retention prune. One running job may hold one replaceable pending request, so repeated timer ticks retain the newest state without creating an unbounded queue. Editor shutdown stops and joins the worker before the editor and processor references can disappear.

Verification: RECOVERY_RETENTION proves immutable capture, semantic validation, transactional replacement, malformed-write rejection without damage to the existing target, exact note round-trip, collision-proof naming, invalid-file cleanup, and eight-file retention. RECOVERY_WORKFLOW invokes the production background worker, restores tempo and lane identity, and proves that an unchanged second autosave creates no duplicate. The complete broad application self-test passes after the change.

Subagents: Wegener defined the thread-ownership and shutdown boundary, including the requirement that workers never retain live processor, editor, or UI references. Hilbert mapped the existing recovery coverage and identified immutable capture, failure preservation, duplicate suppression, coalescing, and shutdown as the critical evidence. The primary task implemented and integrated that contract.

Human review flag: Work continuously while autosave intervals pass, especially on a slower or externally synchronized drive. Confirm no visible hitch, no duplicate recovery clutter, and clean application shutdown. Recovery-list parsing still occurs after completion on the message thread; it is bounded to the retained snapshot set, but remains the next small optimization if profiling finds a measurable pause.

2026-08-13 - Save The Captured Song, Not The Moving Screen

Task: Move customer-facing complete-project Save, Save As, and portable archive preparation away from the user-interface thread without allowing ongoing edits or project changes to corrupt the result.

Creative connection: One immutable project document can serve ordinary Save, Save As, recovery, portable archives, future project duplication, freeze preparation, and cloud synchronization. Treating the captured document as the transaction boundary means the musician can continue working while slower disks, large resource maps, and archive compression proceed independently.

Architecture choice: SpaceAge captures and serializes the project once on the message thread, where session-owned MIDI queues can settle safely. A low-priority Save worker owns only the destination, immutable JSON, and project-generation receipt. Archive preparation owns the same immutable document, loads it into a private verifier, validates resources, remaps portable paths, compresses, and verifies the finished package without consulting the live editor or processor. A generation mismatch allows the file copy to finish but prevents an older completion from replacing the identity of a newly loaded or blank session.

Verification: PROJECT_PERSISTENCE invokes the production background Save path, continues editing immediately, and proves the saved file contains the exact click-time tempo and lane identity while the live project retains later edits. PROJECT_ARCHIVE captures at 112.5 BPM, mutates the live project to 198.75 BPM, and proves the archive contains 112.5 BPM. Missing, unreadable, changed-after-planning, unsafe, corrupt, and mismatched archive fixtures remain rejected. Project-load feedback, recovery workflow, and the complete broad application suite pass.

Subagents: Two read-only review delegations were attempted for thread ownership and customer workflow, but the delegation transport was interrupted before returning usable agent identities or findings. The primary task completed the final lifetime, shutdown, stale-completion, and production-entry-point review locally rather than claiming unreceived work.

Human review flag: Save and Save As a large project to a slow drive while playing and editing; confirm the interface remains responsive and the saved file represents the moment Save was pressed. Load or create another project before a slow Save completes and confirm the old copy finishes without renaming the new session. Export a mixed-resource portable archive and confirm progress, cancellation expectations, and exact reopening. The small last-project preference write and bounded Library refresh still occur after completion on the message thread. Portable archive import remains the next larger background-I/O refactor.

2026-08-13 - Prepare Elsewhere, Adopt Here

Task: Move portable project archive import preparation away from the live processor and prevent a completed background import from replacing a newer session.

Creative connection: Project import, cloud restore, template opening, future collaboration downloads, and SpaceAge Scene recall all share the same two-stage contract: prepare a complete candidate away from the active song, then ask the visible session whether the candidate still belongs there. This keeps slow storage and validation work independent while making ownership changes explicit and testable.

Architecture choice: Archive unpacking, project recognition, manifest validation, resource verification, and path remapping now consume files and immutable JSON only. The worker retains no editor or active processor reference. A private verifier remains responsible for proving that packaged instruments and assets load cleanly. Import captures the current project-generation receipt when launched; both worker completion and delayed message-thread activation compare that receipt before adoption. A project save blocks import launch, and a newer project, recovery, or blank session causes the prepared import to be deleted rather than silently replacing the musician's work.

Verification: PROJECT_ARCHIVE passes complete resource remapping and audible restoration, immutable import preparation, corrupt resource refusal, path traversal rejection, malformed project rejection, manifest mismatch rejection, and the new same-generation/stale-generation activation predicate. PROJECT_PERSISTENCE, PROJECT_LOAD_FEEDBACK, and RECOVERY_WORKFLOW pass. The complete broad application self-test passes across MIDI, synthesis, Arrangement, Mixer, project lifecycle, archive, recovery, and export.

Subagents: Delegation remained off the critical path for this pass because recent subagent transport was unreliable. The primary task performed the ownership trace, implementation, review, and verification directly.

Human review flag: Import a large mixed-resource archive while the current song is playing. During a second import, deliberately load another project before preparation completes and confirm SpaceAge preserves the newer session, discards the prepared import, and reports why. Also verify that Save-in-progress and archive-import-in-progress messages are clear on a slow drive.

2026-08-13 - Index The Library Without Holding The Door

Task: Remove the remaining recursive preset-Library disk scan from project adoption and other customer-facing UI actions while preserving immediate asset-status feedback and deterministic shutdown.

Creative connection: Preset discovery, future sample-browser metadata, Instrument Bay search, theme catalogs, and hardware-profile registries all need the same split: background workers discover immutable entries; the message thread adopts one settled snapshot. A latest-request-wins index prevents rapid filter or project changes from making the visible catalog travel backward in time.

Architecture choice: refreshLibrary() now updates missing-asset status immediately, advances a Library request generation, and starts one low-priority index worker. The worker owns only the preset folder, favorite-filter value, and request receipt; it recursively discovers .sskit files and favorite sidecars without touching editor controls or processor state. One active scan may retain one replaceable pending request. The message-thread timer applies only the newest completed result, preserves the selected preset when possible, and joins the worker during editor shutdown. The last-project preference receipt remains synchronous: it is one short transactional path write with no recursive enumeration or project parsing, so additional asynchronous ordering would cost more complexity than it removes.

Verification: LIBRARY_LAYOUT uses an isolated two-preset fixture, issues back-to-back all/favorites-only requests, proves the latest request wins, proves favorite sidecar filtering, restores the complete list, waits for the production worker to settle, and retains the 66-control responsive layout contract. PROJECT_PERSISTENCE, PROJECT_LOAD_FEEDBACK, STARTUP_DIALOG_LAYOUT, RECOVERY_WORKFLOW, and PRIMARY_UI_VISUAL_STATE pass. The complete broad application self-test passes.

Subagents: Delegation remained off the critical path because recent subagent transport was unreliable. The primary task traced, implemented, reviewed, and verified this bounded worker directly.

Human review flag: Populate the Library with a large nested preset collection, then load projects and toggle Favorites Only rapidly while playback continues. Confirm the visible list settles on the newest request, selection does not jump unnecessarily, missing-asset status remains immediate, and closing SpaceAge during a scan is clean.

2026-08-13 - Read The Project Before Touching The Song

Task: Remove project-file reading, JSON parsing, and semantic preflight from the UI thread while preserving exact live-session ownership and recovery behavior.

Creative connection: Normal project open, Load Last, recovery, Library project presets, portable archives, future templates, and SpaceAge Scene recall all benefit from one candidate/adoption protocol. A project is first treated as inert data with a request receipt; only a current, valid candidate earns permission to touch the audible session. That same boundary can later accept cloud downloads or collaboration revisions without letting slow storage work own the song.

Architecture choice: SpaceAge now separates prepareProjectSnapshot from loadPreparedProjectSnapshot. A low-priority worker owns the chosen file, reads it, parses its JSON, performs the complete recognizable-project semantic preflight, and returns an immutable juce::var candidate plus request and session-generation receipts. Load Last, Load Project, Library project presets, and recovery snapshots use this path. The message-thread poller rejects cancelled, malformed, superseded, or stale candidates before the live processor is touched; successful candidates alone enter the existing restoration boundary. Editor shutdown invalidates the request, signals the worker, joins it, and releases its candidate. Archive activation and deterministic internal tests retain the synchronous wrapper, which now delegates through the same prepare/adopt primitives.

Verification: PROJECT_LOAD_FEEDBACK now proves an honestly indeterminate loading UI, a disabled transport boundary, production background candidate adoption, malformed-candidate state preservation, and stale-session rejection. PROJECT_PERSISTENCE, PROJECT_ARCHIVE, RECOVERY_WORKFLOW, RECOVERY_RETENTION, and LIBRARY_LAYOUT pass. The complete broad application self-test passes across MIDI, native instruments, Arrangement, Mixer, project lifecycle, recovery, archives, Library, and export. Verification report: reports/background-project-load-preparation-20260813.out.

Subagents: Delegation remained off the critical path because recent subagent transport was unreliable. The primary task performed the ownership map, implementation, adversarial review, and verification directly.

Human review flag: Open a large project and a large recovery snapshot from a slow or removable drive while observing the radar/progress feedback. Confirm the window remains repaintable during file preparation, invalid files leave the current song unchanged, closing during preparation is clean, and the final instrument/resource adoption pause is acceptable. The remaining synchronous resource adoption is intentionally not moved to a worker until decoded sample, SoundFont, Quasar, and loop resources have a dedicated lock-safe handoff.

2026-08-13 - Decode The Orchestra Before Opening The Airlock

Task: Remove SoundFont validation, decoding, and voice-pool prewarming from final project adoption so a large SF2 does not make a successful background project load appear frozen at the last moment.

Creative connection: Instrument Bay project loading, future template previews, SpaceAge Scenes, cloud restores, and portable archives all need resources to arrive as prepared cargo rather than instructions for the visible session to unpack. An opaque prepared-project candidate can gradually carry each expensive resource family while preserving one strict adoption gate.

Architecture choice: The project-load worker now owns JSON preflight plus SoundFont structure validation, TinySoundFont decoding, preset resolution, output-rate configuration, and all 48 prepared voice instances for every requested source slot. It returns an opaque candidate containing immutable project state and shared resource ownership, never a live processor reference. The message thread rejects cancelled, malformed, superseded, stale-session, path-mismatched, and sample-rate-mismatched candidates before adoption. Matching resources are published by pointer transfer with a fresh live generation; missing or corrupt files preserve the existing exact known-good resource and produce the normal repair receipt. A rate mismatch deliberately falls back to the established synchronous loader rather than publishing a cache prepared for the wrong audio device.

Verification: PROJECT_LOAD_FEEDBACK, SOUNDFONT, RECOVERY_WORKFLOW, MISSING_ASSET_REPAIR, REALTIME_INSTRUMENT_ASSET_RETIREMENT, PROJECT_PERSISTENCE, and PROJECT_ARCHIVE pass. The complete broad application self-test passes across MIDI, native synthesis, Arrangement, Mixer, automation, project lifecycle, recovery, archive, Library, effects, and export. Verification report: reports/background-soundfont-project-preparation-20260813.out.

Subagents: Avicenna and Hooke were assigned read-only ownership and adversarial audits, but the subagent transport stalled and was terminated before returning identities or findings. No unreceived work is credited. The primary task completed the ownership trace, implementation, review, and verification directly.

Human review flag: Load the previously proven approximately 1.9 GB GM SoundFont project during playback, close during preparation, switch projects before completion, and change audio-device sample rate during preparation. Confirm the interface remains repaintable, stale work cannot replace the newer session, audio remains stable, and the final adoption pause is materially reduced. Samples, Quasar packages, and arrangement loop audio remain the next resource families for candidate-based preparation.

2026-08-13 - Load The Samples Before They Reach The Stage

Task: Remove ordinary sample-layer and bonus one-shot decoding from final project adoption while preserving long-file streaming, repair receipts, and live-voice ownership.

Creative connection: Pads, private Instrument slots, future sample-browser previews, Quasar capture, freeze, and project templates all rely on the same underlying promise: audio assets should be decoded once into immutable ownership and then published, not repeatedly rediscovered while the visible song waits. The shared decoder also prevents manual sample loading and project loading from growing incompatible rules.

Architecture choice: One cancellable decoder now serves manual loading and prepared project candidates. Short WAV/AIFF resources decode in 65,536-sample chunks with cancellation checks; long eligible files retain the established memory-mapped path. The project worker prepares every referenced layer and one-shot without touching the processor. Restore adopts exact-path assets, restores sanitized per-layer settings, and publishes one immutable sample generation per source slot instead of republishing after every item. Missing or corrupt files retain only the exact same known-good prior resource, including memory-mapped audio; a different missing path can no longer expose unrelated stale sound.

Verification: REALTIME_INSTRUMENT_ASSET_RETIREMENT, PROJECT_PERSISTENCE, MISSING_ASSET_REPAIR, HOSTILE_INSTRUMENT_RESOURCE, PROJECT_ARCHIVE, RECOVERY_WORKFLOW, PROJECT_LOAD_FEEDBACK, and GOLDEN_PROJECT_LIFECYCLE pass from the rebuilt binary. The complete broad application self-test passes, including hybrid disk-backed long samples, sample/one-shot playback, private Instrument sample routing, stems, and export. Verification report: reports/background-sample-project-preparation-20260813.out.

Subagents: Avicenna and Hooke were assigned bounded read-only ownership and regression audits. The subagent transport again stalled before returning agent IDs or findings and was terminated; no unreceived work is credited. The primary task completed the implementation and repeated adversarial review locally, including the memory-mapped fallback correction found after the first focused run.

Human review flag: Load a sample-heavy project during playback using short WAV/AIFF layers, one-shots, and several files longer than ten seconds. Cancel or close during decode, supersede the load with another project, remove one exact resource, and replace a stored path with a different missing file. Confirm responsive repainting, clean cancellation, exact-resource fallback, honest silence for unrelated missing files, and no delayed final adoption hitch. Peak memory can temporarily include both the current live resources and the prepared incoming project; profile unusually large all-memory projects before beta sign-off.

2026-08-13 - Assemble Quasar Before Opening The Bay

Task: Remove Quasar manifest parsing, hostile-path validation, zone decoding, and finite-sample scanning from final project adoption without weakening package safety or repair behavior.

Creative connection: Quasar is both an Instrument and a portable package format. Preparing it through the same candidate boundary as SoundFont, Layers, and One-Shots turns project opening into a consistent backstage assembly process: every asset-backed Instrument is validated and made playable before the visible song changes. That same boundary can later support Instrument Bay previews and preflight estimates without instantiating a live lane.

Architecture choice: The Quasar decoder is now a static, live-state-free preparation function. It validates the manifest and every zone path, decodes and scans audio in 65,536-sample cancellable chunks, and returns an owned package candidate. Final restore uses one adoption boundary to publish zones, reset round robin state, clear an incompatible SoundFont payload, and select the Quasar engine. Legacy interactive loading still calls the same decoder and adoption boundary. Missing or corrupt packages retain only an exact-path known-good prior generation and remain visible to asset repair.

Verification: The rebuilt binary passes PROJECT_PERSISTENCE, QUASAR_PRODUCTION_BUILD, HOSTILE_INSTRUMENT_RESOURCE, MISSING_ASSET_REPAIR, PROJECT_LOAD_FEEDBACK, REALTIME_INSTRUMENT_ASSET_RETIREMENT, PROJECT_ARCHIVE, and GOLDEN_PROJECT_LIFECYCLE. The archive gate proves that a prepared mixed-resource project reopens with audible Quasar output.

Subagents: No subagent work is credited in this pass. The previous bounded dispatch transport stalled before returning agent identities, so the ownership review, implementation, and regression audit were completed directly rather than risking another idle delegation.

Human review flag: Load and supersede genuinely large Quasar projects during playback, cancel while a long zone is decoding, close SpaceAge during preparation, and corrupt one zone after a known-good package is live. Confirm responsive repainting, no partial adoption, exact-resource fallback, an honest repair receipt, stable round-robin playback, and no audible replacement by a stale completion.

Broad-suite receipt: The complete application self-test passes against the rebuilt binary. Report: reports/background-quasar-project-preparation-20260813.out.

2026-08-13 - Prepare The Loop Bank Before The Downbeat

Task: Remove arrangement loop-audio mapping and decoding from final project adoption, and prevent playback from observing a partially restored loop bank.

Creative connection: Arrangement loops, future audio clips, freeze files, rendered stems, and sample-browser audition assets all benefit from the same candidate protocol: prepare immutable audio ownership away from the visible session, then publish one complete generation. This turns storage latency into backstage work and gives future audio-clip features a reusable atomic handoff rather than another special-case loader.

Architecture choice: A cancellable loop-resource decoder now validates format metadata, preserves WAV/AIFF memory mapping, decodes other supported formats in bounded chunks, checks read success, and rejects non-finite decoded audio without touching live processor state. The project worker prepares every referenced loop. Restore retains the currently published loop snapshot while preparation is underway, builds the incoming bank from prepared resources and sanitized settings, accepts only exact-path known-good fallback for missing or corrupt files, advances each track generation once, and publishes the complete bank once. Interactive loop loading uses the same decoder and keeps its existing direct adoption behavior.

Verification: REALTIME_LOOP_SNAPSHOT passes with zero audio-callback locks, allocations, and destruction. PROJECT_PERSISTENCE, PROJECT_LOAD_FEEDBACK, MISSING_ASSET_REPAIR, PROJECT_ARCHIVE, RECOVERY_WORKFLOW, and GOLDEN_PROJECT_LIFECYCLE pass. The complete broad application self-test reaches every normal broad checkpoint, including project lifecycle and export. Receipt: reports/background-loop-project-preparation-20260813.out.

Subagents: No subagent work is credited. Recent delegation transport has stalled repeatedly, so the ownership trace, implementation, adversarial review, and verification remained on the primary task.

Human review flag: Load projects containing long memory-mapped WAV/AIFF loops and compressed loops while playback continues. Cancel, supersede, and close during preparation; remove an exact prior file and substitute a different missing path. Confirm responsive repainting, no partial loop-bank state, honest missing-asset receipts, exact-resource fallback only, and no audible hitch beyond the single final adoption boundary.

2026-08-13 - Assemble The Score Before Raising The Curtain

Task: Remove per-item note, chord, Drum-step, expression, and pattern-length publication from final project adoption.

Creative connection: Project loading, future templates, SpaceAge Scenes, collaboration revisions, and alternate orchestrations all need the same rule: assemble a complete musical model privately, validate it with the same rules as interactive editing, and publish only the settled result. This also makes a future project-diff preview practical because the candidate bank exists independently before it becomes audible.

Architecture choice: Piano notes, Chord Engine clips, and MIDI expression payloads now use shared sanitizers for both interactive setters and restore. Project adoption constructs a private pattern bank, restores every Drum step, note, chord, and shared expression lane into it, infers spans after all content exists, reapplies explicit saved lengths as authoritative, then replaces the mutable bank under one lock and publishes exactly one immutable snapshot per pattern. The old path repeatedly copied each growing note/chord vector and republished the full pattern after every item, producing quadratic work on real songs.

Verification: PROJECT_PERSISTENCE proves populated and empty patterns each publish exactly once while preserving notes, chords, automation, exact pattern length, malformed-state rejection, Save As, reopen, and undo-history retirement. PROJECT_LOAD_FEEDBACK, MISSING_ASSET_REPAIR, GOLDEN_PROJECT_LIFECYCLE, and MIDI_CLOSEOUT pass. The complete broad application self-test passes across MIDI, synthesis, Arrangement, Mixer, project lifecycle, recovery, archive, effects, and export. Receipt: reports/batched-pattern-project-adoption-20260813.out.

Subagents: Kepler was assigned a bounded read-only invariant and regression review. The subagent transport stalled without returning usable findings, so no unreceived work is credited. The primary task completed the implementation, local adversarial review, and full verification.

Human review flag: Open dense projects containing long Piano Roll performances, many Chord Engine markers, Drum patterns, and automation. Compare the final adoption pause against the previous build, then confirm the first playback after load reproduces exact clip lengths and expression ownership without an intermediate partial pattern becoming audible.

2026-08-14 - Publish The Arrangement Only After The Song Exists

Task: Prevent chain, lane, clip, and Section restoration from publishing a growing sequence of incomplete Arrangement snapshots while a project is being adopted.

Creative connection: Project loading, templates, alternate orchestrations, and future SpaceAge Scenes all need the same theatrical rule: construct the whole arrangement backstage, then raise the curtain once. The same boundary can later support project-diff previews and cancellable template adoption without letting playback observe half of the old song and half of the new one.

Architecture choice: Project restoration now opens one Arrangement mutation batch before adopting serialized state and closes it through a scope guard. Intermediate setters may still request publication, but those requests collapse into one final immutable sequencer generation after chains, lanes, clips, Sections, loop state, and expression ownership are settled. Chain slots are assembled directly during restore and pass through the same shared sanitizer used by interactive and replacement paths, avoiding a Drum projection rebuild for every restored slot while preserving all existing validation rules.

Verification: PROJECT_PERSISTENCE proves the restored song advances the sequencer snapshot generation exactly once while retaining tempo, loop, routing, Mixer, clip, note, chord, automation, malformed-state rejection, Save As, background Save, and Undo-history behavior. PROJECT_LOAD_FEEDBACK, MISSING_ASSET_REPAIR, GOLDEN_PROJECT_LIFECYCLE, and MIDI_CLOSEOUT pass from the rebuilt binary. The broad suite reached its final project-lifecycle/export checkpoint without a failed regression in the first run; later attempts to capture a second shell exit receipt were interrupted by task continuation messages rather than by a product failure.

Subagents: No subagent work is credited. Recent bounded delegation transport has repeatedly stalled, so the ownership trace, implementation, review, and regression audit were completed directly.

Human review flag: Load dense songs with many Sections and mixed Drum/instrument lanes, then begin playback immediately after adoption. Confirm there is no partial visual arrangement, no first-playback mismatch, no lane/clip identity drift, and a shorter final load pause than the prior build.

2026-08-14 - Do Not Replace Silence With Identical Silence

Task: Stop project restoration from allocating and exchanging a new immutable sample-start cache for every empty source slot.

Creative connection: The same identity rule can later reduce churn in templates, Instrument Bay swaps, Scenes, and alternate orchestrations: if a published immutable resource already expresses the exact desired absence of content, preserving its generation is both faster and more truthful than announcing a change that never happened.

Architecture choice: Final sample-cache adoption now compares the incoming mutable slot with its currently published immutable cache. A slot that gains audio publishes; a slot that loses audio publishes an explicit empty cache; an empty-to-empty slot preserves its generation. SoundFont and Quasar ownership remain unchanged, and active voices retain their captured generations through the established retirement system.

Verification: PROJECT_PERSISTENCE preloads one private source slot, restores a source-free project, and proves that slot publishes a real clear while a second untouched empty slot keeps its generation. HOSTILE_INSTRUMENT_RESOURCE, MISSING_ASSET_REPAIR, REALTIME_INSTRUMENT_ASSET_RETIREMENT, PROJECT_ARCHIVE, and GOLDEN_PROJECT_LIFECYCLE pass from the rebuilt binary.

Subagents: No subagent work is credited. This was a narrow ownership and generation change completed directly to avoid delegation overhead.

Human review flag: Load sparse and sample-heavy songs repeatedly during playback. Confirm that empty banks remain silent, removed samples disappear immediately, retained voices finish cleanly, and project adoption feels more responsive without stale source audio.

2026-08-15 - Invalidate The Echo, Prepare The Controls

Task: Shorten final project adoption without exposing stale EchoRay history or moving unsafe work onto the audio thread.

Creative connection: Panic, project replacement, effect disable, template adoption, and future SpaceAge Scene changes all need the same semantic operation: the old delay history must become inaudible immediately. Treating that as generation validity rather than bulk memory erasure makes the operation constant-time and reusable wherever a large circular history must be retired instantly. Preparing the parameter tree alongside audio resources extends the same backstage-candidate model to control state.

Architecture choice: Each per-channel delay line now tracks how much contiguous history behind its write head belongs to the current generation. Reset paths invalidate that horizon in O(1); reads remain silent until enough new samples exist for the requested delay time, so stale tails cannot leak. Project preparation also parses and validates the serialized parameter tree before final adoption, allowing restore to publish the prepared tree instead of reparsing XML during the visible handoff.

Verification: PROJECT_PERSISTENCE and SHARED_EFFECTS_SIGNAL pass from the rebuilt Release binary. The full Release build passes standalone launch plus VST3 discovery, audio at 44.1/48 kHz, parameter mutation, state restoration, and editor reopen. The staged user executable has SHA-256 930A0A52D15FEF458C71C8D0FB5210C16A830E18EFD562BAB282BE716818FC1F.

Human review flag: During playback, load a dense project with active EchoRay sends, use Panic, disable/re-enable EchoRay, and switch projects repeatedly. Confirm a shorter final adoption pause, immediate silence from invalidated history, no stale echo returning later, and normal new delay buildup after each reset.

2026-08-15 - Trust The Prepared Candidate Once

Task: Remove the remaining duplicate project preflight from final prepared-project adoption.

Creative connection: A prepared project, template, archive import, or future SpaceAge Scene should cross one explicit trust boundary: validate and assemble the candidate off-thread, then adopt that exact typed candidate once. Revalidating it at the curtain wastes the preparation work and makes the user wait twice for the same proof.

Architecture choice: The typed PreparedProjectSnapshot adoption overload now requires its already validated object state and prepared parameter tree, then adopts directly. Raw juce::var, host-state, recovery, and file-preflight paths retain full recognition and semantic validation. The optimization therefore changes no untrusted-input boundary; it removes only a redundant second project walk and parameter XML parse from an internally produced candidate.

Verification: Four rebuilt PROJECT_PERSISTENCE runs pass. Before this change, warm final adoption measured 127-132 ms with a 141 ms cold run. Afterward, repeated final adoption measured 72.6-78.5 ms, about 42% lower for this fixture. SHARED_EFFECTS_SIGNAL also passes with finite Halostar, Reverb, EchoRay, modulation, and octave output.

Human review flag: Compare dense real projects against the prior user build, especially projects with many patterns, lanes, Instruments, and EchoRay sends. Confirm the shorter final handoff, exact restored state, no stale delay tails, and no malformed or hostile project being accepted through any public load route.

2026-08-15 - Publish Only Pattern Changes

Task: Avoid replacing immutable playback snapshots for patterns whose restored state remains identically empty.

Creative connection: Snapshot generations should communicate meaningful musical change. Preserving an unchanged empty generation reduces project-load work today and gives future templates, Scenes, and alternate orchestrations a cleaner identity model: silence is republished only when content was actually cleared or its duration changed.

Architecture choice: Bulk project adoption now compares each mutable pattern with its currently published snapshot. Populated patterns publish, formerly populated patterns publish a real clear, and length changes publish. Empty-to-empty patterns with unchanged lengths retain their existing immutable snapshot. The audio thread still sees only complete immutable generations.

Verification: PROJECT_PERSISTENCE proves that populated content republishes once, a stale populated pattern republishes an empty clear once, and a truly untouched empty pattern does not republish. Warm final adoption for the regression fixture improved from 72.6-78.5 ms to 61.2-63.0 ms, with a first run of 67.3 ms. MIDI_RECORD_TIMING, AUTOMATION_RESTORE, AUTOMATION_OWNERSHIP, and GOLDEN_PROJECT_LIFECYCLE pass.

Human review flag: Load sparse and dense projects, start playback immediately, and confirm exact Drum, Piano Roll, Chord Engine, and MIDI-expression content with no stale notes in patterns that became empty.

2026-08-15 - Parse The Parameter Tree Once

Task: Remove duplicate parameter-tree parsing from typed project preparation.

Creative connection: SpaceAge's prepared-project boundary should produce all validated control and resource state in one pass. The same output-bearing validator pattern can later serve template import, recovery, archive activation, and Scene preparation without making each caller repeat expensive conversion work.

Architecture choice: Project recognition now optionally returns the validated ValueTree it creates. Typed preparation parses JSON, validates format and semantics, and captures that exact parameter tree in one operation. Boolean-only callers retain the same public behavior, and hostile or malformed projects cross no weaker trust boundary.

Verification: Three rebuilt PROJECT_PERSISTENCE runs pass with exact restore and rejection behavior. Preparation fell from about 93.9 ms to 45.5-47.6 ms in the regression fixture. HOSTILE_INSTRUMENT_RESOURCE and GOLDEN_PROJECT_LIFECYCLE pass, including known-good fallback, repair state, live playback, and full export.

Human review flag: Compare projects with small and very large parameter trees, missing assets, SoundFonts, Quasar packages, and malformed copies. Confirm faster preparation, exact control restoration, and unchanged refusal/repair behavior.

2026-08-15 - Make The Shipping Boundary Executable

Task: Reconcile the release-license ledger with the actual CMake-embedded dependency and asset inputs.

Creative connection: SpaceAge's artistic identity and its legal identity should be driven by the same source of truth. A hash-locked shipping boundary lets future themes, factory instruments, educational editions, and platform ports inherit known provenance instead of rebuilding trust from memory.

Architecture choice: The existing machine-readable manifests remain authoritative because they exactly cover the current build: eleven dependency families, fourteen dependency/license artifacts, and sixteen embedded assets. Public packaging continues to fail closed when an artifact changes or remains blocked. User-loaded SoundFonts and samples remain outside the bundled-content grant.

Verification: test-release-hygiene.ps1 passes the complete identity, dependency, notice, archive, privacy, claims, toolchain, and reproducibility contract. test-release-asset-clearance.ps1 -AuditOnly reports 16/16 embedded assets tracked and hash-locked, with one cleared and fifteen intentionally blocked. The unresolved set is five first-party artwork files awaiting ownership confirmation plus nine TG55 WAVs and their catalog awaiting generation/provenance evidence.

Human review flag: Record first-party ownership for the five artwork files. For TG55, recover and rerun the generator, obtain a creator attestation, or replace the waves with newly generated and tracked assets. Complete the commercial JUCE and VST3 license decisions before public packaging.

2026-08-15 - Prove The Commit Without Borrowing The Workshop

Task: Prove that the current source commit can configure, build, launch, host, and pass the complete automated release suite from a detached clean checkout.

Creative connection: A trustworthy SpaceAge release, educational edition, platform port, or future open-source handoff must be reproducible from the repository itself. A clean-checkout proof turns the source tree into a durable product asset: it detects undeclared local files, stale build products, hidden machine dependencies, and tests that pass only inside the developer's long-lived workspace.

Architecture choice: The convergence tool creates a guarded temporary worktree at the exact candidate SHA, performs a fresh JUCE configure and Release build, builds the standalone application, VST3, focused evidence runner, and audio self-test, then exercises standalone launch, VST3 discovery/audio/state/editor behavior, and all named automated release gates. It never imports binaries or generated resources from the working checkout.

Verification: Candidate 699cfb95a3ab7feb049d49dd785cc4584638e30a passed the detached proof with 83/83 automated gates. Every one of 619 factory presets rendered finite, audible, bounded audio; all seven native tonal engines and the SoundFont/Quasar paths passed; MIDI recording, multi-controller ownership, SysEx, RPN/NRPN, automation, project persistence/recovery, exports, UI geometry, standalone launch, and VST3 host smoke passed. Receipt: test-reports/clean-checkout-convergence-699cfb95a3ab-20260815-120107.out.

Human review flag: This proof establishes software reproducibility, not permission to distribute blocked assets. Public packaging remains closed until the five artwork files, ten TG55 bank files, commercial JUCE/VST3 decisions, and the remaining physical/human release checks are evidenced.

2026-08-15 - Make Every Effect Control Earn Its Space

Task: Audit the shared effects for dead controls, misleading ranges, reversed behavior, and changes that do not produce a useful musical result.

Creative connection: Effect controls should follow the same product rule as Instrument Bay choices and Chord Engine helpers: the center of the control should be immediately useful, subtle work should have enough physical travel, and extremes may become adventurous without consuming most of the range. This makes sound design faster and gives future Motion Clips and automation a predictable response surface.

Architecture choice: Halostar Tail now uses a curved time mapping that devotes more travel to practical rooms and halls while retaining very long upper-range decays. Chorus, Flanger, Phaser, and Tremolo have effect-specific rate ranges and squared depth curves for finer low-depth work. Tremolo returns a gain delta so the Mixer dry path is attenuated rather than reinforced. EchoRay now uses its full Brightness range, differentiates Dual and Haas behavior, honors Link L/R, applies Drift across modulation shapes, gives character modes distinct coloration, maps Safe feedback across the full visible control, and prevents Noise from waking every unused delay path.

Verification: SHARED_EFFECTS_SIGNAL now proves audible finite output plus Halostar tail range, EchoRay brightness, character, stereo linking, and Tremolo depth response. AUDIO_SAFETY_CONTINUITY, SYNTH_PATCH_MIXER_OWNERSHIP, MIXER_STATE_PERSISTENCE, and POLYPHONIC_CPU pass from the rebuilt binary.

Human review flag: Audition each effect with drums, bass, sustained chords, and transient melodic material. Confirm useful center positions, smooth subtle travel, intentional extremes, EchoRay stereo distinctions, and true Tremolo attenuation.

2026-08-15 - Replace The Octave Shortcut With A Musical Shifter

Task: Complete the shared-effects audit by proving the remaining controls independently and replacing the Octave return's rough rectifier/zero-crossing shortcut.

Creative connection: Halostar already contained a useful crossfaded delay-window pitch technique. Recasting that knowledge as a dedicated Octave return makes the product more internally coherent: one proven DSP idea now serves both atmospheric shimmer and deliberate parallel octave color, while retaining separate state and lifecycle ownership.

Architecture choice: Octave now uses a stereo, preallocated, dual-window pitch shifter for -2, -1, +1, and +2 octaves. It performs no callback allocation, invalidates history in constant time, starts clean after disable/re-enable, and uses a restrained return gain. Reverb damping/width, modulation rate/depth, and all Octave choices now have isolated response checks rather than relying on paired preset differences.

Verification: The expanded SHARED_EFFECTS_SIGNAL gate proves independent Reverb damping and width, isolated Chorus rate, Flanger depth, Phaser rate, Tremolo rate, and four distinct finite/bounded Octave choices. AUDIO_SAFETY_CONTINUITY, POLYPHONIC_CPU, PROJECT_PERSISTENCE, and GOLDEN_PROJECT_LIFECYCLE pass.

Human review flag: Audition the Octave return monophonically on bass, lead, kick, tom, and voice-like material. The new algorithm is substantially smoother, but complex polyphonic sources can still expose the familiar texture of time-domain octave shifting; treat that as an effect character rather than transparent offline transposition.

2026-08-15 - Close The Mixer And Master Effects Loop

Task: Extend the musical-effects audit through the actual channel-strip and master processors rather than similarly named controls inside individual sound engines.

Creative connection: Mixer compression, saturation, EQ, and master shaping are the final shared layer through which every instrument can pass. Giving these controls the same useful-center and audible-proof standard as Halostar and EchoRay makes future automation and Motion Clips dependable: a movement lane can only feel intentional when the destination control has predictable travel.

Architecture choice: Channel and master compressor Ratio controls now devote more physical travel to everyday 1:1-6:1 work while retaining 20:1 at the extreme. Saturation Tone uses a proper exponential one-pole coefficient and logarithmic control mapping, so it remains responsive across the complete 40 Hz-20 kHz range instead of reaching an internal ceiling early. The existing compressor, three-band musical EQ, master compressor, master low-pass, and limiter ownership boundaries remain intact.

Verification: SHARED_EFFECTS_SIGNAL now renders isolated control pairs for strip Compressor, Saturation, Musical EQ, master Compressor, and master Low Pass. Measured differences were 0.0151197 / 0.0509335 / 0.00902025 for the strip processors and 0.0154346 / 0.000879741 for the master processors; all were finite and audible. AUDIO_SAFETY_CONTINUITY, SYNTH_PATCH_MIXER_OWNERSHIP, MIXER_STATE_PERSISTENCE, and POLYPHONIC_CPU pass.

Human review flag: Audition channel compression and saturation at low, center, and high settings on drums, bass, and sustained harmony. Confirm that Saturation Tone now moves continuously from dark to open, compressor ratios remain easy to dial in the lower range, and master Low Pass remains useful as a performance control rather than a precision EQ.

2026-08-15 - Make Effect State And Controls Tell The Truth

Task: Close the remaining shared-effects trust gaps in bypass state and detailed-editor interaction.

Creative connection: A bypass switch is a musical boundary, not merely a drawing state. Clearing internal modulation history when an effect is disabled gives future automation, Scenes, and live performance a deterministic starting point. Matching the detailed editor's fine-control and reset language to the rest of SpaceAge also means the same physical gesture carries the same expectation everywhere.

Architecture choice: Chorus, Flanger, Phaser, and Tremolo now detect enabled-to-disabled transitions. The stateful modulation processors reset immediately and Tremolo's phase returns to a known origin, preventing old modulation memory from resurfacing after re-enable. Detailed effect knobs now use velocity-sensitive precision, a practical drag distance, Shift fine adjustment, parameter-specific tooltips, and double-click restoration to each APVTS parameter's actual designed default.

Verification: EFFECTS_DETAIL_LAYOUT passes all 312 controls at supported window sizes. SHARED_EFFECTS_SIGNAL proves finite, audible, independently responsive effects and Mixer/master processors. AUDIO_SAFETY_CONTINUITY and MIXER_STATE_PERSISTENCE pass.

Human review flag: Toggle Chorus, Flanger, Phaser, and Tremolo off during active material and back on after silence; confirm no stale sweep or phase discontinuity returns. In every detailed effect editor, confirm broad dragging, Shift fine adjustment, and double-click default restoration feel consistent.

2026-08-15 - Keep EchoRay Honest As A Shared Return

Task: Remove insert-style dry controls from EchoRay and make its customer-facing contract match its Mixer send/return architecture.

Creative connection: SpaceAge now has a clearer signal-language rule: instruments own their dry sound, Mixer channels own sends, and shared effects contribute processed returns. The same rule can guide future Orbit racks, Motion automation targets, export stems, and additional auxiliary buses without hidden gain duplication.

Architecture choice: EchoRay is permanently wet-only. The obsolete Dry Level and Kill Dry parameters, processor pointers, DSP branch, editor toggle, editor knob, and test setup were removed rather than hidden. Wet Level remains the internal processed-delay level, Output Gain remains the final EchoRay output trim, and Return remains the shared-rack level, so each surviving stage has one distinct purpose.

Verification: EFFECTS_DETAIL_LAYOUT passes with 306 contained controls across both supported test sizes. SHARED_EFFECTS_SIGNAL proves the two obsolete parameters are absent while EchoRay remains finite, audible, and independently responsive. AUDIO_SAFETY_CONTINUITY, PROJECT_PERSISTENCE, and GOLDEN_PROJECT_LIFECYCLE pass.

Human review flag: Audition EchoRay with its channel send at unity. Confirm that changing Wet Level, Output Gain, and Return has predictable staged behavior without thickening or duplicating the dry source before the first repeat.

2026-08-15 - Prove Every Halostar Dimension

Task: Complete the Halostar and standard Reverb closeout with isolated evidence for every musically meaningful Halostar dimension instead of relying on one combined alternate patch.

Creative connection: Halostar is both a shared ambience return and SpaceAge's first native pitch-cloud effect. Proving its reverb, spatial, pitch, feedback, and timing dimensions separately establishes a reusable acceptance pattern for future Orbit effects: every visible control must create a distinct bounded result before automation, Scenes, or Motion Clips are allowed to target it.

Architecture choice: The Halostar DSP already maps controls in the expected direction, so no speculative retuning was introduced. The shared-effects regression now renders and compares damping extremes, mono/wide spread, shimmer off/up, Up/Down/Dual octave modes, low/high shimmer feedback, and short/long pre-delay. Existing tail proof and standard Reverb damping/width proof remain in the same gate.

Verification: SHARED_EFFECTS_SIGNAL passes. Measured Halostar differences were damping 0.000990941, shimmer 0.00143284, mode pairs 0.00160312 / 0.00105259, pre-delay 0.00143644, and mono/wide stereo spread 0.000517142 / 0.00136437. High shimmer feedback raised late-tail RMS from 0.00120472 to 0.00976216 while remaining finite.

Human review flag: Audition Halostar on transient, sustained, and harmonically dense material. Confirm that Damping reads naturally from bright to dark, Width reaches focused and spacious endpoints, Up/Down/Dual are musically identifiable, and high Feedback remains exciting without becoming uncontrollable.

2026-08-15 - Close Shared Return Level And Silence Contracts

Task: Prove the remaining Reverb and EchoRay level stages independently and verify that zero-level or disabled shared returns cannot leak residual audio.

Creative connection: A send effect is trustworthy only when both halves of its behavior are dependable: a control must make an audible change when engaged, and it must contribute absolutely nothing when disabled or set to zero. This same contract can govern future auxiliary effects, stem rendering, Scene recall, and automation cleanup.

Architecture choice: No DSP retuning was needed. EchoRay retains three non-duplicate wet stages: Wet Level before output shaping, Output Gain as the post-effect dB trim, and Return as the shared-rack fader. The focused regression now proves each stage independently, proves Reverb Size independently, and checks zero late-tail energy for Halostar, Reverb, and EchoRay when their return level is zero or the effect is disabled.

Verification: SHARED_EFFECTS_SIGNAL passes. All seven shared-return silence captures reported exactly zero late-tail RMS. Reverb Size produced difference RMS 0.012371; EchoRay Wet, Output, and Return stages produced 0.0126664 / 0.0220867 / 0.0137072 respectively.

Human review flag: Audition each shared return at zero, center, and unity while toggling Enable. Confirm that the three EchoRay level stages feel understandable in practice and that disabling any return never brings back an old tail.

2026-08-15 - Close Modulation And Octave Return Contracts

Task: Complete the shared-return audit for Chorus, Flanger, Phaser, Tremolo, and Octave by proving both active Return response and inactive output behavior.

Creative connection: These five processors bridge conventional auxiliary effects and future Motion behavior. A single acceptance rule now spans both: active depth/rate/shift controls must reshape sound, active Return controls must reach the mix, and zero or disabled states must leave the direct instrument path effectively unchanged.

Architecture choice: Existing DSP and reset ownership were retained. The regression now renders zero-Return and disabled states for all five effects, compares them against the dry-source variance ceiling, and separately proves each active Return rises clearly above that floor. An older joined declaration in the test source was also separated for human readability.

Verification: SHARED_EFFECTS_SIGNAL passes. All ten inactive-state differences remained between 0.000190764 and 0.000201105, below the 0.001 ceiling. Active Return differences were Chorus 0.00515413, Flanger 0.00424063, Phaser 0.00760095, Tremolo 0.000905263, and Octave 0.00255979.

Human review flag: Audition each effect at zero, center, and unity Return, then disable/re-enable during playback. Confirm that Tremolo behaves as gain movement rather than added signal, Octave remains a parallel color, and modulation returns do not produce level surprises.

2026-08-15 - Keep Effects Automation At The Correct Ownership Boundary

Task: Verify that every shared-effect parameter is writable, discoverable, and persistent without incorrectly turning the MIDI Expression editor into a global effects editor.

Creative connection: SpaceAge now has two complementary movement systems with distinct ownership. Arrangement AUTOMATION belongs to MIDI performance data and can follow Shared PTN, Lane Local, or Clip Local ownership. Shared-rack sound design belongs to JUCE parameters, while Mixer sends belong to their source channels. Preserving that distinction makes future Motion Clips and Scenes easier to design because they can target a named parameter or send without quietly changing every clip that shares a pattern.

Architecture choice: Keep the Arrangement AUTOMATION editor focused on CC, pitch bend, pressure, sustain, and related MIDI expression. Shared effects remain processor-owned APVTS parameters available to host automation and SpaceAge MIDI controller mapping. Per-lane effect movement should target Mixer sends; global effect movement should target the shared return explicitly.

Verification: PROJECT_PERSISTENCE now enumerates all 70 fx_ shared-effect parameters, proves every one is host-automatable, proves every one resolves through SpaceAge's MIDI controller-target registry, writes legal non-default probe values, and proves exact project recall. SHARED_EFFECTS_SIGNAL, EFFECTS_DETAIL_LAYOUT (306 controls), AUDIO_SAFETY_CONTINUITY, and GOLDEN_PROJECT_LIFECYCLE also pass from the same compiled checkpoint.

Human review flag: In a future VST-host test, record automation for representative continuous, Boolean, and choice parameters. In standalone SpaceAge, map hardware controls to representative Reverb, Halostar, EchoRay, modulation, and Octave parameters and confirm smooth live response.

2026-08-15 - Smooth The Return, Preserve The Off Switch

Architectural connection

Shared effects belong to the Mixer and host-automation boundary, so their audible output stages need one consistent real-time contract. Halostar, Reverb, EchoRay, Chorus, Flanger, Phaser, Tremolo, and Octave now move their return gains through short audio-rate ramps instead of jumping once per audio block. EchoRay combines Return, Wet Level, and Output Gain at that smoothed boundary so three customer controls cannot create three independent gain discontinuities. Its block-aligned envelope is reused across every contributing Mixer channel, so adding lanes cannot make automation run faster.

Creative extensions

The same return-stage primitive can later support tempo-aware scene morphs, Mixer snapshots, and SpaceAge Scenes without adding effect-specific interpolation code. Character-changing controls remain independent; a return ramp should smooth loudness, not blur the identity of an effect.

Verification and human review

A 5 ms ramp retained the established zero/disabled silence contract and the usable contrast between all effect settings. SHARED_EFFECTS_SIGNAL, PROJECT_PERSISTENCE, AUDIO_SAFETY_CONTINUITY, and GOLDEN_PROJECT_LIFECYCLE pass. Human beta listening should still sweep returns during sustained material and confirm that the response feels immediate without ticks.

Agent contributions

No subagents were used in this pass.

2026-08-15 - Smooth The Channel Once, Not Once Per Voice

Architectural connection

Instrument voices now leave synthesis without owning Mixer gain or pan. SpaceAge resolves the assigned Mixer channel at the routing boundary, advances one five-millisecond gain/pan smoother per channel and sample, and applies that shared result to every voice entering the channel. This keeps polyphony from changing control behavior and gives live fader, pan, MIDI, and automation movement one audible ownership point.

Creative extensions

The same channel-boundary pattern is the right foundation for future scene morphing, grouped Mixer gestures, control-surface pickup, and Motion Clip modulation. Those systems can target channel values without reaching backward into instrument voices.

Verification and human review

The first processed block primes from the exact current parameter values so project load and prepared hard-pan states do not fade in from defaults. MIXER_LANE_ROUTING, MIXER_STATE_PERSISTENCE, AUTOMATION_OWNERSHIP, POLYPHONIC_CPU, SHARED_EFFECTS_SIGNAL, and GOLDEN_PROJECT_LIFECYCLE pass. A human beta audition should still sweep gain and pan during sustained polyphonic audio and confirm smooth motion without clicks or sluggishness.

Agent contributions

No subagents were used. LT audited, implemented, reviewed, corrected, built, and verified this boundary directly.

2026-08-15 - One Send Gesture, Eight Consistent Destinations

Architectural connection

All channel-strip sends now share one sample-rate-aware smoothing bank at the Mixer boundary. Halostar, reverb, EchoRay, octave, chorus, flanger, phaser, and tremolo keep their distinct processors and enable rules, but no longer disagree about how a live send gesture reaches audio.

Creative extensions

This common boundary can later support linked sends, scene morphing, hardware pickup, and Motion Clip modulation without adding effect-specific gesture code. It also provides one place to tune response time if human audition finds five milliseconds too quick or too soft.

Verification and human review

The full shared-effects signal matrix, automation ownership, lane routing, and Mixer persistence gates pass. Human beta review should sweep every send over sustained audio and confirm responsive, click-free transitions while return tails remain natural.

Agent contributions

No subagents were used. LT implemented, reviewed, repaired formatting artifacts, built, and verified the complete send family.

2026-08-15 - Hearing Protection Must Not Click

Architectural connection

The project-level volume control now uses the same five-millisecond sample-rate-aware smoothing philosophy as channel gain, pan, sends, and shared returns. Its target remains the stored decibel parameter, but conversion and interpolation happen at the final master gain stage sample by sample.

Creative extensions

A stable final gain boundary supports future monitor dim, scene fades, project fade-outs, and hardware master controls without duplicating ramp logic or risking block-edge discontinuities.

Verification and human review

The full shared-effects and Mixer/master processor matrix, Mixer persistence, and Golden Project Lifecycle gates pass. Human beta review should move the project-level volume rapidly over sustained full-spectrum audio and confirm click-free response with no sluggish safety behavior.

Agent contributions

No subagents were used. LT audited the remaining live-control path, implemented the master smoother, rebuilt, and ran the broad audio and lifecycle gates.

2026-08-15 - Dynamics Controls Should Move Like Mixing Decisions

Architectural connection

The channel compressor and saturation stages now read eight shared, channel-owned smooth states rather than raw parameter jumps inside each rendered voice. Threshold, ratio, attack, release, makeup, drive, tone, and mix all follow the same five-millisecond response contract as channel gain, pan, and sends; enable switches remain immediate because bypass is a discrete decision.

Creative extensions

A single channel-processor control bank can later serve hardware pickup, linked-strip editing, scene morphs, and automation thinning. It also prevents polyphony from changing the apparent speed of a compressor or saturation gesture.

Verification and human review

The complete effects/Mixer/master processor matrix, Mixer persistence, and automation ownership gates pass. Human beta review should sweep each compressor and saturation control on sustained and transient-rich material, checking both click resistance and useful responsiveness.

Agent contributions

No subagents were used. LT implemented the shared bank, caught a self-referential target error during review, repaired it before compilation, and verified the resulting audio contracts.

2026-08-15 - Master Motion Can Be Smooth Without Softening Safety

Architectural connection

The master compressor threshold, ratio, and makeup plus the master low-pass cutoff now share the five-millisecond, sample-rate-aware control contract used by Mixer gain, pan, sends, and dynamics. The low-pass performs coefficient calculations per sample only while its cutoff is moving, returns to one calculation per block once settled, and becomes a true bypass at its fully open endpoint.

Creative extensions

This establishes a reusable distinction for future master processors and automation: tonal and dynamics controls may interpolate for clean gestures, while protective controls use asymmetric timing. The limiter applies stricter gain reduction immediately whenever the ceiling is threatened, then releases smoothly toward unity so hearing protection is never traded for cosmetic smoothness.

Verification and human review

The complete shared-effects signal matrix, Mixer state persistence, and Golden Project Lifecycle gates pass. Human beta review should sweep compressor threshold, ratio, makeup, and low-pass cutoff over sustained and transient-rich material, then drive the limiter and confirm clean recovery without ceiling overshoot.

Agent contributions

No subagents were used. LT reviewed the master path, preserved limiter safety, optimized settled-filter processing, rebuilt, and verified the result through the broad audio and lifecycle gates.

2026-08-15 - Modulation Should Breathe, Not Step

Architectural connection

Chorus, flanger, phaser, and tremolo rate/depth controls now share a five-millisecond sample-rate-aware motion contract. Tremolo consumes the ramp sample by sample; JUCE's block processors consume 32-sample control slices, keeping parameter motion sub-millisecond at common sample rates without rebuilding effect state for every individual sample.

Creative extensions

The shared modulation-control bank gives future tempo-sync transitions, hardware pickup, scene morphing, and Motion Clip modulation one predictable response boundary. Rate and depth retain their existing musical curves and effect-specific character mappings rather than becoming a generic lowest-common-denominator control.

Verification and human review

The full shared-effects signal matrix, Automation Ownership, Mixer state persistence, and Golden Project Lifecycle gates pass. Human beta review should sweep rate and depth for all four effects on sustained and transient sources, listening for zippering, phase discontinuity, and excessive lag.

Agent contributions

No subagents were used. LT audited the modulation family, implemented shared control ramps with bounded processor slicing, reviewed formatting, compiled, and verified the result.

2026-08-15 - EchoRay Gestures Belong Inside The Echo

Architectural connection

EchoRay now advances nine continuous controls at audio rate: Input Gain, Feedback, Mod Rate, Mod Depth, Wow/Flutter, Drift, Ducking, Width, and L/R Offset. These controls enter the delay-line, feedback, modulation, ducking, or stereo calculations at the sample where their smooth value exists rather than arriving as one abrupt value for an entire audio block.

Creative extensions

This makes EchoRay a reliable destination for hardware control, host automation, Motion Clips, and future tempo-aware morphs. Discrete identity and safety decisions remain immediate: Character, Stereo Mode, Mod Shape, Freeze, Safe, Link L/R, Noise, and Limiter are not blurred into halfway states.

Verification and human review

The full shared-effects signal matrix, Automation Ownership, Mixer state persistence, and Golden Project Lifecycle gates pass. Human beta review should sweep all nine controls over audible repeats, with special attention to Feedback safety, Width/Offset mono behavior, and modulation continuity.

Agent contributions

No subagents were used. LT separated continuous gestures from discrete choices, implemented sample-level smoothing, caught and repaired a mechanical identifier collision before compilation, and verified the complete effect and project contracts.

2026-08-15 - Halostar Should Bloom Under The Hand

Architectural connection

Halostar now owns smooth state for Size, Damping, Width, Tail, Shimmer, Shimmer Feedback, and Predelay. Controls are primed from the exact first processed settings and then advance in 32-sample slices, keeping loaded sound identity exact while avoiding block-boundary jumps and unnecessary per-sample control recomputation.

Creative extensions

Keeping the smoothing inside Halostar makes the reverb independently reusable and gives future hardware mapping, tempo-aware predelay, scene morphing, and Motion Clip modulation a stable processor-owned boundary. Shimmer Mode remains immediate because it selects an algorithmic voice rather than a continuous amount.

Verification and human review

The full shared-effects matrix, Automation Ownership, Mixer persistence, and Golden Project Lifecycle gates pass, including dedicated Halostar tail, damping, width, shimmer, mode, feedback, and predelay contrasts. Human beta review should sweep each continuous control across drums, chords, and sustained sources while listening for zippering or unnatural tail discontinuities.

Agent contributions

No subagents were used. LT moved Halostar's continuous motion into the processor, preserved discrete mode behavior, compiled, and verified every available sound and project contract.

2026-08-15 - A Simple Reverb Still Deserves Smooth Hands

Architectural connection

The standard Reverb now owns smooth Size, Damping, and Width motion through the same five-millisecond contract used elsewhere in the Mixer. JUCE's reverb receives bounded 32-sample processing slices, while Return remains independently sample-smoothed and Enable remains an immediate routing decision.

Creative extensions

This creates consistent tactile behavior between the approachable standard Reverb and the deeper Halostar without pretending they are the same processor. The boundary is ready for hardware mapping, scene morphing, tempo-aware workflows, and host automation without adding UI-specific audio code.

Verification and human review

The complete shared-effects matrix, Automation Ownership, Mixer persistence, and Golden Project Lifecycle gates pass, including dedicated Size, Damping, Width, silence, and tail evidence. Human beta review should sweep all three character controls across active tails and compare their response against Halostar.

Agent contributions

No subagents were used. LT added processor-bound smoothing, preserved independent Return and Enable semantics, compiled, and verified every available effect and project contract.## 2026-08-15 - Octave Choices Should Change Without Tearing

Architectural connection

The shared Octave return now moves between its four fixed pitch ratios through a dedicated eight-millisecond audio-rate transition. The selector still represents exact -2, -1, +1, and +2 octave destinations; only the discontinuity between destinations is softened.

Creative extensions

This makes octave changes safer for hardware mapping, host automation, scenes, and live sound design without introducing a second pitch engine or callback allocation. It also establishes a useful distinction for future controls: continuous destinations may be smoothed, while discrete algorithms remain immediate unless their transition itself creates an audible fault.

Verification and human review

The complete shared-effects matrix, Automation Ownership, Mixer persistence, and Golden Project Lifecycle gates pass. Human beta review should change the Octave selector during sustained bass, lead, voice-like, and drum material, listening for clicks and judging whether the brief transition feels immediate rather than glide-like.

Agent contributions

No subagents were used. LT audited the time-domain shifter, selected the lower-complexity real-time-safe transition, implemented it without allocation, compiled, and verified the effect and project contracts.

2026-08-15 - EchoRay Character Can Move Without Losing Its Identity

Architectural connection

EchoRay now smooths Drive, Color, Headroom, Brightness, and Grit through processor-owned five-millisecond state. Their combined saturation and brightness response is refreshed in bounded 32-sample slices, avoiding buffer-boundary jumps without placing repeated transcendental coefficient work on every sample.

Creative extensions

These five controls can now support hardware gestures, host automation, scenes, and future Motion Clips as a coherent input-character surface. Character remains an immediate mode choice because it selects the underlying flavor; the continuous controls shape that flavor without blurring mode identity.

Verification and human review

The complete shared-effects matrix, Automation Ownership, Mixer persistence, and Golden Project Lifecycle gates pass, including EchoRay brightness and character contrasts. Human beta review should sweep the five controls over active input and repeats, checking tactile response, tonal usefulness, and freedom from zippering.

Agent contributions

No subagents were used. LT grouped the remaining EchoRay input-character controls, implemented bounded processor-side smoothing, compiled, and verified the effect and project contracts.

2026-08-15 - EchoRay Repeats Should Age Gracefully

Architectural connection

EchoRay now smooths Feedback Tone, Feedback High Pass, Feedback Low Pass, Feedback Saturation, and Repeat Age through processor-owned five-millisecond state. Filter coefficients and the combined aging drive refresh in the same bounded 32-sample slices as the input-character controls, keeping the circulating repeat path coherent and CPU-conscious.

Creative extensions

The repeat loop can now be performed as an instrument: hardware gestures, host automation, scenes, and future Motion Clips may darken, thin, saturate, or age echoes without abrupt coefficient jumps. Safe, Freeze, and Stereo Mode remain immediate decisions because they govern routing and protection rather than continuous color.

Verification and human review

The complete shared-effects matrix, Automation Ownership, Mixer persistence, and Golden Project Lifecycle gates pass. Human beta review should sweep all five controls over long feedback tails, listening for zippering, unstable gain changes, excessive lag, and ranges that cease to feel musically useful.

Agent contributions

No subagents were used. LT grouped EchoRay's circulating feedback controls, implemented synchronized bounded smoothing, compiled, and verified all available effect and project contracts.

2026-08-15 - Finish EchoRay As A Performable Instrument

Architectural connection

EchoRay now smooths Noise Floor amount, Mod Phase, Pre High Pass, Pre Low Pass, and Wet Tilt through processor-owned five-millisecond state. Their coefficients and derived values refresh in the same bounded 32-sample slices as EchoRay's character and feedback paths. Noise Enable remains immediate: the amount can move smoothly while the switch still silences or restores the noise contribution without an ambiguous half-enabled state.

Creative extensions

The complete continuous EchoRay surface is now suitable for hardware gestures, host automation, scenes, and future Motion Clips. A performer can reshape the input spectrum, stereo modulation relationship, output darkness, and noise texture while active repeats continue, using one consistent real-time contract across the device.

Verification and human review

The complete shared-effects matrix, Automation Ownership, Mixer persistence, and Golden Project Lifecycle gates pass. Human beta review should sweep these five controls over long repeats and stereo material, checking phase movement, filter continuity, tilt behavior around zero, noise-floor usefulness, and CPU stability.

Agent contributions

No subagents were used. LT completed EchoRay's continuous-control audit, preserved immediate switch semantics, implemented bounded smoothing, compiled, and verified all available effect and project contracts.

2026-08-15 - Silent Effects Still Need Honest State

Architectural connection

Disabled Chorus, Flanger, Phaser, and Tremolo now advance their rate, depth, and return smoothers toward the visible settings while their processors remain silent. Disabled Octave adopts the selected fixed ratio immediately after its pitch memory is reset and advances its return level silently. Re-enabling therefore begins from the current UI state rather than replaying stale hidden ramps.

Creative extensions

This strengthens scenes, automation, hardware control, and live preparation: a musician can configure an effect while it is off, then enable it with predictable sound. The same contract can guide future processors: disabling audio need not freeze customer-facing continuous state unless frozen behavior is an intentional feature.

Verification and human review

The complete shared-effects matrix, Automation Ownership, Mixer persistence, and Golden Project Lifecycle gates pass. Human beta review should alter modulation and Octave controls while disabled, then enable each effect during playback and confirm that the first audible result matches the visible controls without stale sweeps or pitch remnants.

Agent contributions

No subagents were used. LT audited shared-effect disable/re-enable state, repaired the stale-smoother paths, compiled, and verified all available effect and project contracts.

2026-08-15 - Halostar Wakes Up Where The Controls Are

Architectural connection

Halostar now synchronizes Size, Damping, Width, Return, Tail, Shimmer, Shimmer Feedback, and Predelay while the processor is disabled. Its audio memory still clears on bypass, but the lightweight control path primes or advances every smoother without running the reverb network. Re-enabling therefore starts from the visible settings rather than stale hidden values.

Creative extensions

This completes a consistent shared-effects contract for scenes, automation, hardware control, and live preparation: musicians may configure effects while silent and trust the first audible result. Future processors should separate silent parameter-state upkeep from expensive signal processing whenever bypassed controls remain editable.

Verification and human review

The complete Shared Effects Signal, Automation Ownership, Mixer State Persistence, and Golden Project Lifecycle gates pass. Human beta review should change all Halostar controls while disabled, enable it during playback, and confirm immediate agreement with the interface without stale sweeps, revived tails, or unexpected CPU activity.

Agent contributions

No subagents were used. LT audited Halostar's bypass lifecycle, added the silent synchronization path, compiled, and verified all available effect and project contracts.

2026-08-15 - EchoRay Sleeps Lightly

Architectural connection

Disabled EchoRay now advances all 24 continuous control smoothers once per audio block while skipping its 32-sample coefficient refreshes and per-sample smoother consumption. Delay memory and filter state still clear on bypass, so silence remains deterministic; the visible control state remains current without paying the active delay processor's control-rate cost.

Creative extensions

This preserves reliable live preparation, scenes, hardware control, automation, and future Motion Clips while making the effects rack scale more honestly. An effect may be fully configured while off, yet expensive tonal and modulation calculations should awaken only when its audio path is enabled.

Verification and human review

The complete Shared Effects Signal, Automation Ownership, Mixer State Persistence, and Golden Project Lifecycle gates pass. Human beta review should edit EchoRay while disabled, enable it during playback, confirm immediate agreement with the interface, and compare idle CPU with EchoRay enabled and disabled.

Agent contributions

No subagents were used. LT traced EchoRay's full 24-control lifecycle, removed unnecessary disabled processing, compiled, and verified all available effect and project contracts.

2026-08-15 - Bypass Means A Fresh Signal History

Architectural connection

Bypassed mixer-strip compressors now clear their detector envelopes once per audio block, bypassed strip saturators clear their left/right tone-filter memories, and the bypassed master compressor clears its detector envelope. Continuous controls continue settling through the established smoothing paths, but re-enable decisions are based on current audio rather than peaks or filter samples captured before bypass.

Creative extensions

This makes effect auditioning, scenes, automation, and live mixing more trustworthy. A musician can bypass processing to compare or prepare settings, then restore it without a mysterious initial level dip or stale tonal smear. The broader reusable rule is that visible parameter state may persist across bypass, while signal-history state should persist only when tail continuation is an explicit musical feature.

Verification and human review

The complete Shared Effects Signal, Automation Ownership, Mixer State Persistence, and Golden Project Lifecycle gates pass. Human beta review should drive a channel and the master compressor hard, bypass during the loud passage, wait for quieter material, then re-enable and confirm that no obsolete gain reduction appears. Repeat with saturation and listen for stale tone-filter transients.

Agent contributions

No subagents were used. LT audited master and strip dynamics state, caught and corrected an initially inefficient reset location before compilation, then verified all available effect and project contracts.

2026-08-15 - A Limiter Ceiling Must Be A Promise

Architectural connection

The master limiter now derives one stereo-linked gain target for every sample instead of deriving one target from the peak of an entire audio block. Gain reduction attacks immediately whenever either channel would cross the selected ceiling, while the existing five-millisecond smoother handles release. This preserves stereo position and guarantees the finite sample ceiling even when a transient arrives late in a block.

Creative extensions

A trustworthy limiter makes aggressive drum synthesis, Flux Nodes, automation, sound-design scenes, and render workflows safer to explore. The same principle applies to future protection processors: safety constraints must be verified against adversarial timing, not only steady tones.

Verification and human review

The Audio Safety and Continuity test now uses a quiet tone followed by a late full-level transient, specifically covering the old block-timing weakness. AUDIO_SAFETY_CONTINUITY, SHARED_EFFECTS_SIGNAL, AUTOMATION_OWNERSHIP, MIXER_STATE_PERSISTENCE, and GOLDEN_PROJECT_LIFECYCLE all pass. Human beta review should test isolated transients, dense mixes, ceiling automation, and perceived release behavior.

Agent contributions

No subagents were used. LT identified the block-release ceiling weakness, strengthened the adversarial regression, corrected its initialization order, and verified the complete safety and project matrix.

2026-08-16 - Finite Audition, Passive Selection, Embedded Identity

Architectural connection

Selecting an existing Piano Roll note now uses the same finite audition path as note creation and note dragging. Arrangement clip selection no longer rebuilds sequencer or step-editor playback state while transport is running; selection remains a visual/editor action instead of silently changing note ownership. The complete 45-image SpaceAge splash collection is embedded as immutable binary application data and selected without immediately repeating the previous image.

Creative extensions

The finite-audition contract can be reused by chord suggestions, preset browsers, the Instrument Bay, and future sample browsers: every preview must own a bounded note lifetime and a reliable release. The passive-selection rule can likewise protect live arrangement editing, scene auditioning, and automation selection from disturbing active music. Embedded launch artwork preserves the intended product identity and prevents missing or stale external folders from changing the customer experience.

Verification and human review

All 45 embedded PNG files match the supplied originals byte-for-byte. The standalone application builds and launches cleanly. AUDIO_SAFETY_CONTINUITY, SHARED_EFFECTS_SIGNAL, AUTOMATION_OWNERSHIP, MIXER_STATE_PERSISTENCE, and GOLDEN_PROJECT_LIFECYCLE pass. Human review should select existing Piano Roll notes and confirm a short preview, then repeatedly select mixed chord/note clips during playback and confirm there are no hanging notes or changes to playback.

Agent contributions

No subagents were used. LT traced both interaction paths, reused the established finite preview callback, isolated playback from passive clip selection, embedded the supplied artwork, and completed build and regression verification.

2026-08-16 - Audition and Selection Are Now Enforceable Contracts

Architectural connection

The regression suite now drives the same callbacks used by a person clicking an existing Piano Roll note or selecting an Arrangement clip. The note-preview proof includes audio-engine preparation, voice creation on the private lane instrument, and automatic release. The clip-selection proof enters through the Arrangement Canvas while transport is active and verifies that playback ownership and position remain untouched.

Creative extensions

These tests establish reusable rules for future chord, preset, sample, and Instrument Bay audition features: previews must be finite, and passive selection must remain sonically inert. New interactive surfaces can inherit those contracts instead of inventing separate safety behavior.

Verification and human review

KEYBOARD_SHORTCUT_WORKFLOW, ARRANGER_EDIT_CONTRACT, AUDIO_SAFETY_CONTINUITY, and SYNTH_PATCH_MIXER_OWNERSHIP pass. Human review should still judge preview level and repeatedly select mixed chord/note clips during playback to confirm the experience feels calm and predictable.

Agent contributions

No subagents were used. LT added narrow editor test hooks, corrected the isolated audio fixture, verified finite voice lifetime and transport-safe selection, and ran the maintained neighboring gates.

2026-08-16 - MIDI Transfer Panels Share A Responsive Contract

Architectural connection

MIDI export preview and MIDI import review now use one responsive sizing policy instead of unrelated fixed dialog heights. At the supported 1100x800 minimum window, export remains 1020x676 and import contracts to 980x736; both preserve their complete action rows, while the import review retains its full dashboard and bounded review text. The shared helper is exercised by a dedicated release-convergence gate.

Creative extensions

The same geometry policy can govern future render receipts, hardware setup reviews, SysEx restore previews, and Quasar package confirmations. Transactional surfaces should reserve room for the decision first, then let explanatory material flex or scroll without hiding the action that completes the work.

Verification and human review

MIDI_TRANSFER_LAYOUT, SETTINGS_ROOT_LAYOUT, AUTOMATION_EDITOR_LAYOUT, and STARTUP_DIALOG_LAYOUT pass. Human beta review still needs to judge typography, scanning comfort, and Windows display scaling; the release checklist remains open for that evidence.

Agent contributions

No subagents were used. LT identified the minimum-window overflow, unified the two transfer-panel sizing paths, added a focused geometry contract, and verified the neighboring popup systems.

2026-08-16 - Release Cockpit Fits Before It Scrolls

Architectural connection

Beta Readiness now treats horizontal space as a hard readability boundary at the supported minimum editor width. Long evidence remains vertically scrollable, but the decision surface no longer asks the user to pan sideways to understand launch status. The real Settings doorway test now protects that distinction.

Creative extensions

This establishes a useful hierarchy for the remaining expert MIDI pages: summary and decision controls should fit in one horizontal view, while dense tables may reflow into cards or use intentional detail views. That approach can improve MIDI Maps, Hardware Passports, and Patch Data without hiding controls or shrinking type.

Verification and human review

SETTINGS_DESTINATION_REACHABILITY and SETTINGS_ROOT_LAYOUT pass at the supported 1100x800 contract. Human review should confirm comfortable scanning under Windows scaling before the release-readiness row is closed.

Agent contributions

No subagents were used. LT inspected the shared Settings shell, rejected unsafe container-only shrinking for dense MIDI pages, implemented the safe Beta Readiness slice, and added doorway-specific regression coverage.

2026-08-16 - Hardware Passports as a Two-Column Dock

Architectural connection

Hardware Passports now treats its two information cards as equal occupants of the available doorway rather than fixed-width panels. The action rows keep their established controls, the history keeps vertical scrolling, and the Settings doorway test protects the result at the supported minimum window size.

Creative extensions

This fluid two-column pattern can support future device identity, MIDI-CI, SysEx library, and hardware-editor summaries. Dense editors such as MIDI Maps and Patch Data should use deliberate toolbar reflow or secondary detail views rather than merely shrinking controls to fit.

Verification and human review

SETTINGS_DESTINATION_REACHABILITY, SETTINGS_ROOT_LAYOUT, and MIDI_SYNC_POLICY pass. Human review should confirm the card balance and control readability at the Windows scaling values used by beta testers.

Agent contributions

No subagents were used. LT reduced the Hardware Passport doorway to the supported width, made its cards fluid, compacted the synchronization action row, and extended the real destination regression.

2026-08-16 - MIDI Patch Uses a Two-Row Action Dock

Architectural connection

MIDI Patch now groups its ten transactional controls into two readable rows instead of forcing one oversized toolbar through the Settings viewport. Profile, lane, mapping, and copy actions occupy the first row; attachment, definition, queue, bend-test, and output actions occupy the second. The patch-review list retains its full vertical capacity and scroll contract.

Creative extensions

This establishes a reusable action-dock pattern for SysEx librarians, hardware editors, preset transfer tools, and other dense transactional pages. Controls can reflow according to purpose while preserving their size, labels, keyboard access, and safety ordering. The same pattern is preferable to tiny buttons or horizontal panning whenever actions form coherent groups.

Verification and human review

SETTINGS_DESTINATION_REACHABILITY, SETTINGS_ROOT_LAYOUT, and MIDI_SETUP_QUEUE pass. Human review should confirm comfortable grouping and typography under the Windows scaling values used by beta testers.

Agent contributions

No subagents were used. LT reorganized the MIDI Patch actions, preserved the dynamic review area, extended the real doorway-fit contract, and verified the neighboring setup-safety path.

2026-08-16 - MIDI Maps Reflows by Editing Task

Architectural connection

MIDI Control Maps now treats horizontal room as a readability budget. Target selection, capture filtering, mapping state, numerical range, response shaping, ownership, and deletion remain the same underlying operations, but the interface groups them into task-oriented tiers rather than one oversized row. The mapping model and MIDI queue are unchanged.

Creative extensions

This tiered mapping card can become the shared visual language for automation binding, hardware-editor assignments, Motion Clip destinations, and future MPE expression routing. A user can learn one sequence: choose a destination, capture a source, define its range, then shape and own the relationship.

Verification and human review

SETTINGS_DESTINATION_REACHABILITY, SETTINGS_ROOT_LAYOUT, and MIDI_CONTROL_QUEUE pass. Human review should confirm comfortable scanning, button spacing, and editor widths under the Windows scaling values used by beta testers.

Agent contributions

No subagents were used. LT reflowed the learn toolbar and mapping actions, restored evidence width, added MIDI Maps to the real doorway-fit regression, and verified control accessibility and MIDI queue behavior.

2026-08-17 - Arranger FUSE, drum-inclusive movement, and harmonic vocabulary

• Generalized FUSE reuses the established pattern-payload model: selected clips from one compatible lane become one independent payload while their real timeline offsets, rests, note lengths, chord markers, transpose values, and drum steps remain meaningful.
• Refusing mixed-lane FUSE protects the one-instrument-per-lane architecture. Refusing a fuse that would silently discard clip automation turns an ambiguous destructive operation into an explicit next design task.
• Removing the legacy primary-drum move veto makes group movement obey one shared arranger rule without weakening lane compatibility or collision checks.
• Full scale names connect accessibility and music education: the same readable vocabulary belongs in dropdowns, theory documentation, preset metadata, and future search.
• Chord coverage should be compositional rather than a permanently expanding flat list: base quality plus added/altered/omitted degrees, slash bass, voicing, and optional upper structure. The typed-chord and custom-cluster input is the open-ended escape hatch.

2026-08-17 - Standalone startup state ownership

Architectural connection

SpaceAge project files already own musical session state. The JUCE standalone wrapper was redundantly serializing the complete processor into its preferences file, producing a 1.95 MB hidden filterState that blocked the message thread before the application window appeared. The standalone shell now owns only device and window preferences, while SpaceAge remains the sole owner of project/session restoration.

Creative extensions

This clean boundary supports future startup recovery, project-version diagnostics, and safe-mode launching without conflating a user's audio hardware preferences with their composition. It also gives the standalone application a deliberate home for launch progress and recovery UX without changing VST3 behavior.

Verification and human review

The repaired executable was tested against the exact failing preferences file. It opened responsively, reduced the preferences from 1,950,223 bytes to 3,585 bytes, retained audioSetup, closed normally, and reopened without recreating filterState.

Agent contributions

No subagents were used. LT isolated the failure to JUCE standalone state persistence, implemented the custom wrapper, and completed the two-launch recovery test.

2026-08-17 - Verification Progress Is Part Of Product Trust

A long silent verification phase creates the same uncertainty as a long silent project load. Timing and naming expensive test phases turns apparent hangs into evidence, makes regressions easier to localize, and keeps release work attached to observable contracts. The factory-groove sweep now reports its start, combination count, and elapsed time; the Arranger movement workflow also has a direct gate instead of requiring the entire suite.

2026-08-17 - Shared Returns Sleep Until First Feed

Architectural connection

Reverb and Halostar are shared Mixer returns, so merely enabling them must not consume their full DSP budget before any lane sends audio. Each return now remains asleep until its send buffer receives a real signal. That first feed wakes the processor and preserves its complete musical tail until the effect is disabled, Panic is used, the audio engine is reset, or the project is cleared.

Creative extensions

The same wake-on-first-feed contract can be reused by future shared reverbs, delays, convolution returns, and expensive spectral effects. Retirement based on guessed time or a brief silent output window is deliberately excluded: predelay, sparse diffusion, feedback, modulation, and freeze-like designs can all produce valid sound after apparent silence. A future sleep-after-tail feature should use explicit internal-energy telemetry supplied by the effect itself.

Verification and human review

Before the fix, enabled but unfed Reverb and Halostar measured about 15.23% of the benchmark window. Three corrected runs measured 12.39%, 12.53%, and 12.85%, with only 0.00%, 0.27%, and 0.78% overhead versus explicitly disabling both returns. SHARED_EFFECTS_SIGNAL, three PERFORMANCE_SMOKE runs, and AUDIO_SAFETY_CONTINUITY pass. Human review should compare CPU in the same project before and after this change and confirm that first-send wakeup is inaudible.

Agent contributions

No subagents were used. LT isolated the idle shared-return cost, rejected an unsafe guessed-tail timeout after regression testing, implemented the conservative wake lifecycle, and added repeatable performance coverage.

2026-08-17 - Visible Pages Own Their Visual Heartbeats

Architectural connection

SpaceAge's editor heartbeat still owns global transport, MIDI-recording feedback, autosave, chord recognition, render progress, and recovery state. Page-specific drawing now belongs to the page that can actually be seen: Arranger geometry and clip animation sleep outside Arranger, Pad activity colours sleep outside Pads, Mixer meters sleep outside Mixer, and TempoCalc host polling sleeps outside TempoCalc. The Synth Engine's heavier patch and navigation maintenance also sleeps whenever its drawer is closed.

Creative extensions

This ownership rule can become a reusable visibility contract for future analyzers, sample waveforms, automation editors, hardware panels, and Motion Clips. A visual device should wake when presented and catch up from authoritative processor state; it should not burn message-thread time merely because its component still exists behind another page.

Verification and human review

PERFORMANCE_SMOKE, AUDIO_SAFETY_CONTINUITY, and PROJECT_LOAD_FEEDBACK pass. The broad PRIMARY_UI_VISUAL_STATE gate retains one unrelated pre-existing editing-context accessibility failure; every page, toolbar, synth-navigation, Arranger, alert, and typography sub-check passes. Human review should compare the same project and audio settings across pages, especially while playback is running, and confirm lower CPU without stale first-frame visuals after page changes.

Agent contributions

No subagents were used. LT classified heartbeat work by ownership, cached the transport-running state once per tick, stopped hidden-page repaint traffic, and preserved all global timing and safety paths.

2026-08-17 - Musical Events Drive Large Visual Grids

Architectural connection

Drum Composer can expose as many as 1,024 step cells, but its musical grid changes only when the playback step, pattern, page, compact mode, or edited data changes. The editor now refreshes that large snapshot on those meaningful transitions instead of rereading and restyling every cell twenty times per second. The much smaller pad-activity layer and playhead remain live, so visual responsiveness is preserved without tying UI cost to grid size.

Creative extensions

This split between stable content and lightweight motion can serve Piano Roll notes, automation curves, waveform previews, chord markers, spectral displays, and future Motion Clips. Static geometry should be cached and invalidated by semantic edits; cursors, meters, pulses, and hover states can animate independently. Accessibility text follows the same principle and updates only when its meaning changes.

Verification and human review

Performance, audio-continuity, and project-load gates must pass together. Human review should open Drum Composer while stopped, switch patterns and pages, edit steps, start and stop playback, and confirm that the grid catches up immediately while pad activity and the playhead remain fluid.

Agent contributions

No subagents were used. LT separated the Drum Composer snapshot from its live activity layer, guarded unchanged tempo and Arrangement animation repaints, and stopped hidden transport controls and unchanged chord accessibility text from being rewritten on every heartbeat.

2026-08-17 - Control-Rate Islands Preserve Audio-Rate Intent

Architectural connection

Mixer gain, pan, send, compressor, and saturation targets are user controls rather than audio events. SpaceAge now samples and smooths those 1,152 control values in bounded 16-sample slices instead of reloading every value for every audio sample. The slice coefficient is derived from the original per-sample coefficient, preserving the intended smoothing curve while cutting redundant audio-thread work. MIDI note, expression, transport, and recording events remain sample-accurate.

Creative extensions

The same control-rate island can serve synth macro controls, effect parameters, meters, and future Motion Clip destinations. Every adoption must explicitly distinguish performance events that require sample accuracy from slowly moving controls that tolerate a sub-millisecond update interval.

Verification and human review

PERFORMANCE_SMOKE improved from about 48.51% to 39.55% of its realtime window, an 8.95 percentage-point reduction and roughly 18.5% less measured load. AUDIO_SAFETY_CONTINUITY and MIDI_RECORD_TIMING also pass. Human review should automate fast mixer moves while playing a dense arrangement and confirm that control response remains smooth and immediate.

Agent contributions

No subagents were used. LT isolated the all-channel per-sample control reload, retained sample-accurate musical event handling, applied mathematically equivalent slice smoothing, and verified performance, continuity, and recording timing together.

2026-08-17 - Cache Derived DSP State, Not Musical State

Architectural connection

The channel-strip compressor and saturation processors still react to every audio sample, but their expensive control-derived constants do not need to be rebuilt for every voice on every sample. Threshold and makeup gains, attack and release coefficients, saturation drive normalization, tone coefficients, and enabled states now update inside the existing 16-sample control slice. Envelope detection, gain reduction, nonlinear shaping, and tone-filter state remain at audio rate.

Creative extensions

This division is reusable across SpaceAge: filters can cache coefficients when cutoff or resonance changes, tempo-aware devices can cache division-derived rates when tempo changes, and synth engines can precompute waveform or modulation constants without weakening note timing. The useful rule is not simply "run controls slowly"; it is to cache deterministic transformations of control state while keeping all signal-dependent state at the rate the sound requires.

Verification and human review

Three PERFORMANCE_SMOKE runs measured 38.34%, 37.84%, and 38.47% of the realtime window, down from the preceding 39.55%-40.03% range. SHARED_EFFECTS_SIGNAL confirms audible compressor and saturation transformations, while AUDIO_SAFETY_CONTINUITY and the full MIDI_RECORD_TIMING matrix pass. Human review should automate compressor and saturation controls on dense polyphonic material and confirm immediate, smooth response without zippering.

Agent contributions

No subagents were used. LT separated control-derived math from signal-derived work, prevented disabled strip processors from paying coefficient costs, and verified CPU, audible effect behavior, audio safety, and MIDI timing together.

2026-08-17 - A Channel Strip Hears The Whole Lane

Architectural connection

Compressor and saturation controls belong to the Mixer channel, so they now process the stereo sum of every voice routed to that channel. Voice generation, envelopes, panning, choke fades, and retirement tails remain note-local; those results are accumulated first, then the shared strip processes the combined lane signal exactly once. Meters, hardware/main outputs, and shared-effect sends all observe that post-strip result.

Creative extensions

This boundary gives future sidechains, bus processing, lane freeze, stems, and hardware inserts one coherent signal to inspect. Voice stealing deliberately retains a pre-strip per-note magnitude because note allocation needs to compare individual voices, not the compressed lane. Silent strips perform only the state decay needed to avoid stale compressor or saturation memory, preserving clean wake-up without visiting their full routing path.

Verification and human review

The focused regression renders two overlapping pitches on one channel. Their dry level rises to 1.40563 times the single-note level, while the shared compressor holds the rise to 0.90919, directly proving post-sum behavior. SHARED_EFFECTS_SIGNAL, AUDIO_SAFETY_CONTINUITY, the full MIDI_RECORD_TIMING matrix, and PERFORMANCE_SMOKE pass; performance measured 37.5532% of the realtime window. Human review should play dense chords through channel compression and saturation, then compare meters, sends, and rendered output with the live Mixer.

Agent contributions

No subagents were used. LT moved shared strip dynamics to the real channel boundary, preserved note-local allocation evidence, added silent-state decay, and wrote a polyphonic regression that distinguishes post-sum processing from per-voice processing.

2026-08-18 - One Stereo EQ Belongs To One Lane

Architectural connection

The Mixer presents one stereo channel per routed lane, so its strip EQ and six-band parametric EQ now process that summed stereo signal once. Notes retain their own synthesis, envelope, pan, choke, and retirement state, but they no longer carry copies of Mixer-owned filter history. Independent left and right biquad state preserves stereo placement, while coefficient calculations occur at block boundaries rather than inside every voice.

Creative extensions

This gives SpaceAge a trustworthy insertion point for future analyzers, sidechains, lane freeze, stems, hardware inserts, and draggable EQ visualizations. The same ownership rule can guide every future processor: if a control appears on one Mixer strip, its DSP should hear that strip's complete signal rather than a collection of isolated notes.

User experience connection

Dense chords now pass through the same EQ curve a user sees on the Mixer, regardless of voice count. Live meters, shared sends, hardware/main outputs, and rendered audio all hear the same post-EQ result. This makes tonal decisions predictable and removes polyphony-dependent EQ behavior that could make a patch change character as more notes were played.

Verification and human review

SHARED_EFFECTS_SIGNAL now proves both strip and parametric EQ alter the signal and remain finite. AUDIO_SAFETY_CONTINUITY and the complete MIDI_RECORD_TIMING matrix pass. Three PERFORMANCE_SMOKE runs measured 42.25%, 47.52%, and 42.44% of the realtime window. Human review should automate both EQ families on a stereo, polyphonic lane and compare live playback, sends, meters, and rendering.

Agent contributions

No subagents were used. LT removed the old per-voice EQ implementation, introduced independent stereo Mixer state, preserved the established musical curves and processor order, added tail/reset safeguards, and expanded the shared-effects regression.

2026-08-18 - One Active-Clip View Per Musical Boundary

Architectural connection

Arrangement playback previously rediscovered the same active clips separately for shared-pattern expression, clip-local expression, and note playback. The scheduler now creates one fixed-size active-clip view at the current song step and reuses it across those stages. Lane expression remains between shared and clip-local expression, preserving the established Shared Pattern -> Lane -> Clip Local precedence. The audio block's immutable sequencer snapshot and computed step duration are also reused rather than reacquired or recalculated.

Creative extensions

This active-view pattern can support future chord playback, Motion Clips, automation evaluation, clip thumbnails, and render scheduling without multiplying timeline searches. A later spatial index or interval structure can replace the bounded scan behind the same interface if song scale demands it. The key is that every musical subsystem should consume one agreed view of "what is active now," preventing both wasted work and contradictory boundary decisions.

User experience connection

The optimization targets the exact moments where a periodic workload spike is most audible: measure starts, section boundaries, loop wraps, and stacks of clips entering together. It does not loosen event timing or move expression to a slower rate. The intended result is steadier playback while dense arrangements retain sample-accurate notes, recording, and expression precedence.

Verification and human review

AUDIO_SAFETY_CONTINUITY, the complete MIDI_RECORD_TIMING matrix, REALTIME_LOOP_SNAPSHOT, AUTOMATION_OWNERSHIP, and ARRANGEMENT_MOVE_WORKFLOW pass. The five-tonal-lane Arrangement workload passed at 61.69% of its realtime window. Three general PERFORMANCE_SMOKE runs measured 42.70%, 42.54%, and 50.26%. Human review should loop a dense section transition and listen for intermittent hesitation on beat one while watching that automation and clip-local expression still win in the expected order.

Agent contributions

No subagents were used. LT consolidated the Arrangement scheduler's repeated timeline scans, preserved expression semantics, reused block-owned control state, and verified timing, loop, automation, movement, continuity, and CPU behavior together.

2026-08-18 - One Pattern Revision Per Audio Block

Architectural connection

Several active Arrangement clips may point to the same pattern, while shared expression and note playback both need that pattern's immutable data. The scheduler now acquires each pattern playback snapshot on first use and retains that exact revision for the rest of the audio block. This removes repeated atomic shared_ptr traffic at step boundaries and prevents one block from combining expression from one published revision with notes from another.

Creative extensions

The same bounded, block-owned lookup can serve future chord playback, arpeggiator data, Motion Clips, and per-pattern performance metadata. It also establishes a clean contract for later worker-thread preparation: publish complete immutable pattern payloads, then let the audio callback consume one coherent generation without locks or allocation.

User experience connection

This work targets intermittent hesitation where many clips begin together and patterns are shared across an arrangement. It does not delay edits beyond the current audio block, alter event order, or weaken sample-accurate scheduling. Notes and expression remain synchronized to the same pattern state throughout each callback.

Verification and human review

AUDIO_SAFETY_CONTINUITY, the complete MIDI_RECORD_TIMING matrix, REALTIME_LOOP_SNAPSHOT, AUTOMATION_OWNERSHIP, and ARRANGEMENT_MOVE_WORKFLOW pass. The five-tonal-lane Arrangement workload passed at 64.10% of its realtime window, within ordinary variance of the preceding 61.69% result. Three general PERFORMANCE_SMOKE runs tightened to 40.92%, 40.22%, and 40.33%, improving on the preceding 42.54%-50.26% spread. Human review should loop dense shared-pattern transitions and confirm that edits, notes, and expression stay coherent without beat-one hesitation.

Agent contributions

No subagents were used. LT introduced the fixed-size per-block pattern snapshot cache, traced a transient quantize-policy test failure to a clean rerun, and verified timing, loop snapshots, automation ownership, arrangement movement, continuity, and repeated CPU behavior before accepting the change.

2026-08-18 - One Lane Playback Context Per Needed Audio Block

Architectural connection

Arrangement playback repeatedly needed the same lane facts while scheduling shared-pattern expression, lane expression, clip expression, drums, chords, and piano notes. The scheduler now derives those facts once into a bounded stack-owned context and reuses them everywhere in that block. Preparation is lazy, so audio blocks that do not cross an Arrangement step boundary do not pay for it.

Creative extensions

This context becomes a natural attachment point for future per-lane automation, Instrument Bay identity, hardware profiles, MPE zones, Motion Clips, and render metadata. Those systems can extend one coherent lane description rather than introducing independent lookups that disagree about routing or audibility. The same structure could eventually be prepared alongside the immutable sequencer snapshot if profiling proves that useful.

User experience connection

The change reduces repeated control work where dense arrangements are most vulnerable: beat one, measure starts, loop wraps, and section transitions. It preserves the exact same mute/solo, drum-versus-instrument, MIDI destination, Mixer channel, and expression-precedence behavior while making the scheduler's decisions easier to audit.

Verification and human review

The dense five-lane Arrangement workload improved from a 64.10% baseline to 60.42% of its realtime window. General performance runs remained inside their existing noisy range at 40.79%-42.60%. AUDIO_SAFETY_CONTINUITY, REALTIME_LOOP_SNAPSHOT, AUTOMATION_OWNERSHIP, and ARRANGEMENT_MOVE_WORKFLOW pass. MIDI_RECORD_TIMING exposed a pre-existing knife-edge fixture that accepted a timestamp below or above 192.5 but always expected 193; the fixture now derives the expected rounded value from the captured timestamp while retaining deterministic below-tie, above-tie, and exact-tie policy checks.

Agent contributions

No subagents were used. LT consolidated lane routing facts into one lazy block context, rejected invalid clip lane indices instead of clamping them onto another lane, measured dense and general workloads separately, and corrected the timing fixture rather than misreporting an intermittent host-scheduling failure as a product regression.

2026-08-18 - Chord Playback Prepared Per Source Step

Architectural connection

Chord Engine playback previously visited every chord in a pattern at every source step and asked the full voicing, arpeggiator, strum, and pan-motion path whether anything belonged there. Immutable pattern snapshots now publish a per-step chord index alongside the chord data. Both isolated pattern playback and Arrangement playback consume that same prepared schedule, so the audio thread enters chord synthesis only when an event can exist on the current source step.

Creative extensions

This is the first prepared event schedule inside the pattern snapshot. The same model can later support Motion Clips, generated articulation, chord-humanization events, and other sparse musical processes without scattering independent scans through the callback. The schedule remains an index into immutable musical data, so future features can add metadata without copying mutable objects into realtime code.

User experience connection

The reduction targets dense harmony and arpeggiator passages at measure starts and loop boundaries. Plain and strummed chords remain start-step events; arpeggiated chords and chords with active pan motion retain every occupied source step. Muted and silent-reference chords never enter the realtime schedule. The musical output is unchanged, but the callback avoids work that could never produce sound or MIDI.

Verification and human review

The focused regression reduced the fixture from 320 legacy chord callbacks to 8 relevant callbacks while proving exact plain, arp, animated-pan, muted, silent-reference, and bounds behavior. AUDIO_SAFETY_CONTINUITY, the complete MIDI_RECORD_TIMING matrix, REALTIME_LOOP_SNAPSHOT, AUTOMATION_OWNERSHIP, and ARRANGEMENT_MOVE_WORKFLOW pass. The broad five-tonal-lane Arrangement workload, which intentionally contains no Chord Engine data, passed at 60.35% and is treated only as a regression alarm.

Agent contributions

No subagents were used. LT prepared the immutable chord schedule, connected both playback consumers, added focused structural evidence, and ran the surrounding timing and ownership suites before accepting the optimization.

2026-08-18 - Five Small Controls, One Ownership Model

Architectural connection

Moon knobs now treat hover and drag as the interaction contract without drawing a keyboard-focus rectangle. Stereo meter presentation derives its visual balance from the already-panned channel levels without changing audio. Chord extraction uses the existing lane-owned instrument and pattern-copy systems: the source lane receives a private chord-free payload, while the new lane receives its own private instrument and chord payload. Opening a synth editor now clears active voices before changing the editor target and refreshes controls under the existing refresh guard.

Creative extensions

Chord extraction establishes a reusable score-separation operation. The same private-payload transform can later separate bass voices, generated arpeggios, or imported MIDI articulations without compromising the source phrase. The editor voice-reset boundary can also protect future instrument swaps and Scene changes.

User experience connection

The five changes reduce visual friction, make extreme panning readable, give composers a one-step orchestration split, and prevent opening an editor from turning a useful patch into a runaway sound. The extraction dialog keeps melody in place by default and makes copying notes an explicit choice.

Verification and human review

Compilation, focused safety gates, a packaged standalone build, and a launch smoke test are required before this group is handed to the user. Human review should compare hard and near-hard pan positions, extract both chord-only and chord-plus-notes variants, and open synth editors during sustained playback.

Agent contributions

No subagents were used. LT implemented and reviewed the five requested tasks as one ownership-focused pass.

2026-08-18 - Chord Separation That Preserves Arrangement Geography

Architectural connection

Chord extraction now treats lane order and Mixer ownership as part of the musical result. The new chord lane is inserted directly below its source, receives its own instrument instance and private pattern payload, and claims a channel only after both tonal-lane routes and drum-pad routes have been excluded.

Creative extensions

This same adjacency-and-ownership rule can support future operations such as extracting generated arpeggios, bass voices, counterlines, or articulation layers. Each operation can create a nearby orchestration lane without creating hidden Mixer collisions.

User experience connection

The new lane appears where the composer expects to find it, and changing its instrument or processing cannot disturb the originating melody or an existing kick channel. Failure is explicit when every Mixer channel is occupied.

Verification and human review

Automated checks cover the 90/10 pan-meter presentation and the existing Mixer layout contract. Human review should extract chords from lanes above and below other tonal lanes, verify immediate adjacency, and confirm that the assigned Mixer channel was silent and unclaimed before extraction.

Agent contributions

No subagents were used. LT removed the channel-1 fallback, added drum-aware Mixer allocation, corrected lane insertion, unified rotary interaction styling, and locked direct pan-percentage presentation into the UI audit.

2026-08-18 - Direct Mixer Control, Chord Registers, Extraction Choices, and Lane Collapse

Architectural connection

Mixer faders now behave like physical faders: only the rail or handle accepts a drag, and the control does not retain a visual keyboard-selection box. This interaction contract can be reused anywhere precision controls sit inside dense panels.

Chord register is stored with each Chord Marker as an octave displacement. Quality and inversion remain intact, while audition, live playback, MIDI export, project persistence, and the visible voicing all consume the same value.

Chord-lane extraction now shares the existing lane insertion and unused-mixer allocation architecture. MOVE separates harmony from the source; COPY creates an orchestration branch while preserving the original harmony. Either path can optionally copy Piano Roll notes, so melodic work is never moved implicitly.

Shift+O is an explicit compact-lane state rather than another spelling of Fit. This keeps O, Ctrl+O, and Shift+4 predictable while giving composers a deliberate way to expose an entire vertical arrangement for broad selections.

Executable contract

The Arranger regression suite now invokes the production extraction command directly. It proves both orchestration paths: copying chords while leaving source harmony and notes intact, and moving chords while optionally copying Piano Roll notes. Both paths must place the destination immediately below its source, allocate a different unused Mixer channel and private instrument, and remap every extracted chord and note to that destination instrument.

Creative extensions

• The octave field can later support per-chord voice-range warnings without altering harmonic identity.
• Copy extraction provides a natural foundation for Scene-style alternative orchestration and chord-to-arp experimentation.
• The compact-lane state could later be stored as workspace preference rather than project composition data.

2026-08-18 - Neutral DSP Must Be Computationally Neutral

Architectural connection

SpaceAge exposes deep sound design without requiring every patch to pay for every available processor. Controls at their neutral value should bypass mathematically irrelevant work while retaining state needed for immediate live changes.

Reusable rule

The transient and compressor paths now skip their exponential and saturation calculations when their contribution is exactly zero. This rule can guide future instrument and effect reviews: first prove that a neutral control is audibly identical, then bypass only the expensive operation, and finally verify the complete signal path with executable audio tests.

Verification

All eight engines in the polyphonic CPU matrix pass, the effects-heavy performance smoke test passes, and audio-safety plus shared-effect signal gates remain green. No sample-accurate MIDI expression or automation read was moved out of the per-sample path.

2026-08-18 - Proof Before Polish

Architectural connection

Beta work now has a broad executable checkpoint spanning composition ownership, project persistence, Mixer routing, automation lifecycle, synth controls, effects audio, MIDI timing, and responsive layout. This makes the test matrix a map of the product rather than a collection of isolated bug reproductions.

Creative discipline

Optimization and cosmetic work should begin from a measured failure or a human observation. A tempting voice-path shortcut was deliberately left untouched because skipping inactive-looking work can change live automation, random progression, or delay history when a control moves during a note. Preserving musical immediacy is more valuable than manufacturing a lower benchmark.

Reusable release practice

Future passes can run this checkpoint first, then spend engineering time only where evidence turns red. Human beta sessions should mirror the same categories, allowing subjective reports such as drag feel, readability, latency, and musical usefulness to attach to an already-proven ownership and persistence foundation.

2026-08-18 - Embedded Marketing Art Is A Release Interface

Architectural connection

The startup rotation is part of the executable, not a loose marketing folder. Its CMake list, binary-resource names, hashes, provenance record, and legal clearance state therefore form a release interface that must change together.

Reusable rule

Treat every embedded image, font, sample bank, and catalog like a dependency: enumerate it exactly, lock its content hash, identify its owner and evidence, and fail packaging when any side disagrees. Repository-only alternates may remain available for design work, but they must never enter the shipping manifest implicitly.

Product connection

This preserves the rich rotating splash experience while making future artwork replacement deliberate. A designer can update the collection without touching startup behavior, and release engineering can prove precisely which images entered a particular executable.

2026-08-18 - Legal Scope Is Part Of The Binary Contract

Task: Reconcile release paperwork after the startup artwork expanded to 45 embedded images.

Architecture choice: The asset manifest remains the byte-level source of truth. Release hygiene now derives the first-party artwork count from that manifest and requires the human legal record to name the complete numbered startup range, About artwork, matching hash count, and manifest reference. This connects visual branding, CMake resources, package privacy, provenance, and legal review without asking a human to remember how many splash files shipped in an earlier build.

Result: The action plan now reports 57 embedded assets, 56 blocked decisions, and two coordinated closure paths. The legal signoff covers 46 artwork files rather than the retired five-image set. No rights decision was invented or marked complete.

2026-08-18: Readable Arrangement Fit and Scalable Editors

• Adaptive fit without destructive compression: Arrangement O/Ctrl+O now treats readable lane controls as a hard constraint. This same pattern can govern future waveform, spectrum, and automation views: fit as much as possible, then scroll rather than making controls illegible.
• Clip-scoped bulk editing: Chord register can be changed for one chord or applied across the current clip. This is a reusable model for future chord voicing, velocity, strum, and articulation commands: preserve detailed editing while adding explicit, narrowly scoped bulk actions.
• Paginated dense devices: EchoRay's single-page functional panels create room for larger controls without hiding parameters. The same page architecture can be reused by other deep effects and synths instead of shrinking controls to unusable sizes.
• Compact rack versus detailed editor: The Octave rack card uses a space-efficient horizontal Return control while its popup remains unchanged. Compact summaries and full editors should be designed as distinct surfaces sharing the same parameter source.

2026-08-19: Readable Temporary Workspaces and Honest UI Work

• Popups are temporary workspaces: Settings and its destination panels can use substantially more screen area than permanent toolbars. A shared bounded, scrollable shell gives text and controls room while preserving Escape and click-away dismissal.
• Documentation should follow the visible workflow: The automation tutorial is organized around owner, parameter, points, playback, deletion, and troubleshooting. That structure can later become contextual help without inventing a second workflow.
• CPU improvements should begin with needless presentation work: The main editor timer now avoids resetting unchanged CPU and transport labels. This is a reusable rule for meters, badges, status labels, and animated surfaces: compute what is needed, but repaint only when visible output changes.
• Polish before expansion: The next product gains should come from consistent spacing, trustworthy state feedback, predictable editing, and repeatable regression checks rather than adding more features.

2026-08-19 - One Musical Session As Cross-System Evidence

A beta smoke session should resemble songwriting rather than a collection of isolated engineering exercises. One short arrangement can intentionally cross launch, project adoption, instrument ownership, contextual MIDI recording, page changes, editing, Mixer routing, automation, shared effects, save/reopen, render, and recovery. That makes failures easier to reproduce because the report captures one coherent musical context instead of several unrelated fixtures.

The new Beta_Session_Smoke_Checklist.md connects each human action to the existing governed evidence IDs without pretending that a checkbox is proof. This lets the same session contribute useful observations to UI, MIDI, Arrangement, host, and support readiness while preserving the stricter candidate-bound evidence-pack process for actual release decisions.

2026-08-19 - Release Checks Need Visible Progress Too

The product principle behind project-load, render, and Quasar progress applies to development tooling as well: a long silent operation creates doubt even when it is healthy. The release-candidate checker now announces each major stage during interactive use while preserving clean JSON for automation. This makes a stalled rights audit, source check, receipt scan, or binary check immediately distinguishable without weakening any gate.

2026-08-19 - A Release Queue Should Be Derived, Not Retyped

The governed human-evidence plan already knows who owns every open readiness check, what action is required, and what evidence closes it. The release-candidate command now offers a detailed view derived directly from that plan. This avoids another checklist drifting away from the fixed 72-item ledger while giving a tester an immediately actionable queue. Grouped status remains concise by default, detailed output is opt-in, and JSON retains the complete structured entries for future dashboards or evidence tooling.

2026-08-19 - Human Evidence Must Belong To Audible Bits

A commit hash and build label identify intent, but a musician tests executable bits. The evidence pack now binds the human session to the exact standalone file and complete VST3 bundle through deterministic hashes. This connects subjective listening, timing, readability, and workflow judgments to the same immutable artifact identity used by packaging. It also creates a reusable rule for future installers and platform ports: evidence follows the artifact, not its filename or somebody's memory of which build was launched.

2026-08-19 - One Door Into Candidate Testing

Release evidence is most trustworthy when the ordinary workflow is also the safest workflow. The guarded candidate-testing command discovers canonical artifacts, rejects dirty source, prints immutable identities, and creates the complete evidence packet. This joins build output, source state, human listening, and release review without asking a tester to reconstruct paths by hand.

2026-08-19 - A Dashboard Is Part Of The Safety System

A release report is not merely presentation. If its totals, artifact locations, human queue, or ready state can drift from their authoritative sources, it can direct careful people toward the wrong binary or imply safety that has not been proven. The candidate-status contract therefore treats reporting logic like production logic: every derived claim must reconcile with Git, the fixed readiness ledger, and the exact evidence plan before packaging can proceed.

2026-08-19 - Test Sessions Should Reuse Context, Not Conclusions

A connected controller rig, representative song, external DAW, or clean machine is expensive to prepare. The release runbook therefore groups evidence by shared setup while preserving one receipt and one reviewer decision per readiness row. This saves human time without allowing a successful note-recording test to imply that SysEx, host automation, UI readability, or public claims also passed.

The same pattern can improve future product QA: organize work around realistic creative sessions, but keep acceptance boundaries narrow and machine-checkable. Rights and public claims remain last because presentation should follow verified capability, not lead it.

2026-08-19 - Evidence Entry Should Be Easy; Approval Should Stay Deliberate

Structured evidence is valuable only when humans can record it without wrestling with JSON syntax. SpaceAge now treats observation entry and approval as two connected but distinct actions. The tester command validates paths and captures the observation; the reviewer command verifies that a PASS has complete surviving evidence. If the observation changes, approval disappears automatically. This applies the same principle used elsewhere in the app: streamline the common action while making consequential state changes explicit.

2026-08-19 - Human Evidence As A Release Transaction

The final readiness handoff now uses the same deliberate transaction idea as project adoption: collect evidence, review it without mutation, preview the exact consequence, then explicitly apply it. Keeping the review report immutable while producing a separate ledger-application receipt makes later release audits reproducible and prevents a convenient UI or script from quietly turning incomplete observations into shipping claims.

2026-08-19 - Test The Consequence, Not Only The Preview

-WhatIf proves intent, but a release system also needs proof of the real write. The ledger application now runs end to end inside a disposable repository, where the test can safely verify exact-row mutation, preservation of unrelated work, receipt identity, and replay rejection.

This pattern is reusable for destructive-looking product operations such as lane extraction, project recovery adoption, asset relinking, and future Scene changes: build an isolated fixture, execute the same production command, and prove both the intended mutation and the data that must remain untouched.

2026-08-19 - A Receipt And Its Mutation Are One Transaction

A release receipt is not useful if the authoritative ledger can change without it. Human-evidence application now prepares both artifacts first, records the ledger identity on each side of the change, and retains a rollback copy until receipt publication succeeds. An occupied receipt destination is treated as evidence of an earlier application rather than as a file to overwrite.

2026-08-19 - Prove The Parachute Opens

Task: Exercise the human-evidence ledger rollback branch instead of trusting an unexecuted recovery path.

What connects creatively: Release tooling has the same integrity problem as project saving, preset replacement, MIDI export, and Quasar package creation: the user should never receive half of a transaction. A rollback design becomes trustworthy only after a deterministic test interrupts it at the dangerous boundary.

Architecture choice: A hidden contract-test switch throws immediately after the readiness ledger is committed and before its receipt is published. The disposable-repository test requires byte-identical ledger restoration, no false receipt, no temporary debris, and a clean tracked worktree before proceeding to the normal success and replay-refusal cases. The switch is absent from ordinary documentation and has no customer-facing path.

Future application: Reuse this exact failure-injection pattern where SpaceAge publishes two or more related artifacts, especially project-plus-recovery metadata, rendered audio plus manifests, portable patch bundles, and future release installers.

2026-08-19 - Quiet Data, Honest Console

Task: Verify whether the consolidated release JSON was actually contaminated by dry-run narration.

What connects creatively: A release command serves two audiences at once: humans watching an audit and automation parsing a contract. Those channels should not be confused. Human progress can remain visible while the success pipeline stays structurally pure.

Architecture choice: The status contract now captures -AsJson before parsing, requires exactly one success-stream item, and requires that item to begin as a JSON object. A separate all-stream probe confirms no redirectable warning, verbose, debug, information, error, or success record contaminates the payload. PowerShell's native interactive-host What if: painting is documented as host rendering rather than falsely described as JSON output.

Future application: Apply the same single-payload contract to artifact identity, support bundles, MIDI Health exports, and any future CI-facing SpaceAge report.

This same boundary should govern future consequential workflows: chord-lane extraction plus Mixer assignment, Quasar package publication, project recovery adoption, Scene changes, and external-hardware librarian writes. The visible result and its durable explanation should either both commit or both remain unchanged.

2026-08-19 - A Safety Test Must Belong To The Gate

Task: Connect the human-evidence mutation and rollback contract to the release-hygiene suite instead of relying on someone to remember a separate command.

What connects creatively: SpaceAge already treats musical routing, instrument ownership, and release evidence as explicit systems rather than scattered conventions. Test ownership should work the same way: a safety property belongs to the highest-level gate whose claim depends on it.

Architecture choice: Release hygiene now requires, parses, and runs the disposable-repository application contract. The deliberately destructive fault branch is additionally barred from the canonical repository, preserving strong failure coverage without making normal maintenance more dangerous.

Future application: When a new contract protects project recovery, MIDI recording, rendering, patch publication, or hardware librarian writes, wire it into the relevant aggregate gate in the same change. A passing leaf test is evidence; an aggregate gate that owns it is policy.

Arranger Identity and Inspector Simplification - 2026-08-19

Stable lane-local labels such as A1, A2, and A3 turn clip relationships into visible musical structure without adding candy-store colors. A clone retains its family and revision, a variant advances the revision, and a fused result begins a new family. Persisting that identity with the project also gives future arrangement, scene, and comparison tools a reliable concept of related material.

Removing Repeats, Tempo, Fill, and Swing from the Arranger inspector prevents clip-local transformations from silently competing with the pattern, Piano Roll, and automation systems. Length remains the structural edit, while Transpose remains an intentional musical edit and is now visible on the clip itself.

The expanded-lane bottom padding, compact EchoRay pagination, and vertically stacked modulation sends all follow the same UI rule: preserve a readable control surface before adding density. These layout decisions should remain covered at minimum supported window sizes so future controls cannot quietly compress existing ones into unusable fragments.

Mixer Width Connections

• Channel width should be built as reusable mid/side DSP, but every channel keeps independent settings. The same core can later support mastering analysis, mono-safe previews, and effects without coupling their parameter state.

2026-08-20 - One Control Slice, One Channel Traversal

Task: Reduce avoidable realtime overhead in the Mixer without changing its sound or control response.

What connects creatively: Gain, pan, effect sends, compression, and saturation are separate musical concepts, but at control rate they all ask the same 64 channels for their next smoothed value. Treating that shared timing boundary as one operation removes bookkeeping while preserving each control's independent state.

Architecture choice: The per-slice Mixer update now traverses the channel array once instead of three times. Every smoother still receives the same target and cadence, while all first-run priming flags remain false until the entire channel set has been initialized.

Future application: New channel-strip controls should join this consolidated control-slice pass when they share its cadence. This pattern can also inform future active-lane caches, modulation updates, and meter publication, provided audio-rate work and display-rate work remain separate.

2026-08-20 - Prepare Only The Effect Paths That Can Speak

Task: Remove avoidable EchoRay setup work from the realtime block without changing routing or tails.

What connects creatively: An effect being available in the rack is not the same as it being active in the signal graph. SpaceAge can keep a rich effects vocabulary while making the silent case cheap by preparing only paths that can contribute audio.

Architecture choice: EchoRay delay-time and filter-coefficient preparation now occurs only while EchoRay is enabled. Active-path discovery shares the existing channel-send traversal instead of scanning all 64 channels again. Auto-pan remains independent, and an already-active EchoRay tail remains eligible for processing until it retires naturally.

Future application: Use this enable-and-activity boundary for other shared effects, modulation engines, meters, and lane processors. Do not skip state needed for a live tail, and do not couple independent processors merely because their controls happen to share a page.

Release Evidence As A Guided Queue

The human release-evidence pack now behaves more like an operational queue than a folder of forms. get-next-release-human-evidence.ps1 connects the governed phase plan, receipt templates, structured results, and reviewer approval state to identify the next legitimate action. This pattern can later support an in-app beta dashboard without creating a second readiness model: the GUI would remain a view over the same files and rules used by the command-line release gate.