DEEPPLUCK / "JUST A LIL' PLUCKSYNTH"
V0.12.75 - STANDALONE VIRTUAL MIDI KEYBOARD
VERBINDLICHER IMPLEMENTIERUNGS-MASTERPROMPT - REVISION 2

Repository:
D:\0A_VST_Development

Zielversion:
0.12.75

Dieser Text ist die spaeter direkt auszufuehrende Implementation Order. Fuehre
bei seiner Ausfuehrung den Milestone vollstaendig aus. Erstelle dann nicht nur
einen weiteren Plan oder Masterprompt. Der gegenwaertige Auftrag, mit dem diese
Datei erzeugt wurde, erlaubt dagegen ausdruecklich noch keine Implementierung.

===============================================================================
0. EXECUTION CONTRACT
===============================================================================

Arbeite ausschliesslich im vorhandenen Repository und auf Basis des beim Start
tatsaechlich vorhandenen Arbeitsstands. Bewahre jede legitime spaetere Arbeit.
Erzwinge keinen aelteren Commit, setze nichts zurueck, verwende keinen Stash und
raeume den Arbeitsbaum nicht durch Loeschen oder Verschieben fremder Dateien auf.

Implementiere als einzigen neuen Produktumfang ein kompaktes virtuelles
MIDI-Keyboard unterhalb der bestehenden GUI der Standalone-Anwendung. Die VST3-
Variante bleibt ohne Keyboard und behaelt exakt ihre bisherige Groesse und ihr
bisheriges Layout. Das Keyboard speist echte MIDI-Ereignisse in den bestehenden
Produktionspfad ein. Es ist kein Synthese-, Parameter-, Preset- oder State-
Feature.

Verbindliche Arbeitsregeln:

1. Lies zuerst AGENTS.md und das Sound Manifest vollstaendig.
2. Fuehre danach das Initial Audit und das Pre-Milestone Reconciliation Gate aus.
3. Beginne keine V0.12.75-Produktarbeit, bevor der Start-HEAD eindeutig und
   nachvollziehbar hergestellt wurde.
4. Bearbeite niemals Dateien unter JUCE/.
5. Schuetze alle untracked Benutzerdateien. Nicht veraendern, verschieben,
   loeschen, stagen oder committen.
6. Verwende C++20 und die offizielle JUCE-9-CMake-API.
7. Halte den Audio-Thread realtime-sicher: keine Allokation, keine Sperre, kein
   Dateisystem, kein Logging, keine GUI und keine APVTS-Suche im Hot Path.
8. Installiere oder kopiere nichts automatisch in Systemordner. Lasse
   COPY_PLUGIN_AFTER_BUILD deaktiviert.
9. Kein Push.
10. Keine neuen Abhaengigkeiten und kein Projucer-Projekt.
11. Keine Funktion eines spaeteren Milestones vorwegnehmen.
12. Stelle keine manuelle Abnahme als bestanden dar, bevor der User sie real
    durchgefuehrt und bestaetigt hat.
13. Stoppe nur bei einem echten externen Blocker oder wenn eine erforderliche
    Benutzerentscheidung neue Autoritaet erfordert. Dokumentiere dann exakt:
    Blocker, Evidenz, bereits ausgefuehrte sichere Pruefungen und die eine
    konkrete Entscheidung, die zum Fortsetzen fehlt.

===============================================================================
1. AUTHORITATIVE INPUTS AND PRECEDENCE
===============================================================================

Lies vor Planung und Aenderung mindestens vollstaendig:

- D:\0A_VST_Development\AGENTS.md
- D:\0A_VST_Development\Docs\Sound\DeepPluck_Sound_Manifest_v1.0.md
- diesen Masterprompt
- README.md
- ARCHITECTURE.md
- CMakeLists.txt
- die aktuellen Processor-, Editor-, Synthesiser- und GUI-Quellen
- die aktuellen Test- und Evidence-Skripte
- die Implementierungsreports und relevanten Masterprompts von V0.11.25,
  V0.11.5, V0.12.0 und V0.12.5

Das Sound Manifest ist fuer Sound, Produktfokus, GUI-Ruhe, CPU-/Qualitaets-
Abwaegungen und Feature-Scope normativ. Dieses Keyboard besteht den darin
geforderten Feature-Test nur als unmittelbare Standalone-Spiel- und Testhilfe.
Es darf DeepPluck nicht zu einem allgemeinen MIDI-Workstation-Featurekomplex
erweitern.

Prioritaet bei Konflikten:

1. ausdruecklich genehmigte Anforderungen dieses Milestones;
2. AGENTS.md und der eingefrorene V0.11.0-Kompatibilitaetsvertrag;
3. Sound Manifest;
4. tatsaechliche neueste, legitime Repository-Architektur;
5. fruehere Dokumentation.

Wenn Dokumentation und Code auseinanderliegen, veraendere nicht blind den Code
nach einer alten Beschreibung. Klaere den realen Stand, bewahre legitime neuere
Arbeit und aktualisiere die Dokumentation gemeinsam mit der Implementierung.

Provenienz des Erstellungsauftrags dieser Revision:

- Audit-Datum: 2026-09-04, Europe/Berlin
- SHA-256 des urspruenglichen V0.12.75-Auftragstexts:
  14671b0de652e662d714c783bb53a356cae3d177399a15848564731e8b02dbd4
- SHA-256 des beim Audit gelesenen Sound Manifests:
  12506dd262024dc38007e9676e6d1389f06afcb10c64125eacaef3f89abe3378

Die Hashes sind Provenienz, kein Befehl, einen alten Zustand auszuchecken.

===============================================================================
2. VERIFIED INITIAL AUDIT - SNAPSHOT, NICHT CHECKOUT-ANWEISUNG
===============================================================================

Beim Erstellen dieses Masterprompts wurde folgender reale Stand verifiziert:

- Branch: master
- Git HEAD: 4b4d0e5867799f66b9e3db95eb70cad195b57d33
- Kurzform: 4b4d0e5 docs: add V0.11.25 implementation report
- project(... VERSION ...) in HEAD: 0.11.25
- project(... VERSION ...) in der Working Copy: 0.12.5
- Index: leer
- 18 tracked Dateien modifiziert
- 58 untracked Top-Level-Eintraege vorhanden
- JUCE/ unveraendert
- build/ und Artifacts/ ignoriert
- COPY_PLUGIN_AFTER_BUILD: FALSE

Die tracked Aenderungen betreffen beim Snapshot:

- ARCHITECTURE.md, README.md und CMakeLists.txt;
- Effects, GUI, Processor, Preset Manager, Oscillator und Voice;
- Smoke-, Versions-, Artifact-, Tone- und zentrale Testquellen.

Die untracked Eintraege enthalten sowohl legitime Projektarbeit als auch
geschuetzte Benutzerdaten. Zur legitimen Projektarbeit gehoeren insbesondere:

- CMake/FactoryContent.cmake und .gitattributes;
- der freigegebene 116-Preset-Factory-Bestand samt Katalog;
- Factory-Library-/Codec-Quellen;
- CPU-/Factory-Testwerkzeuge und Preset-Tools;
- Implementierungsreports von V0.11.5, V0.12.0 und V0.12.5.

Als geschuetzte Benutzerdateien wurden insbesondere erkannt:

- CubaseTest/ und die dortige Cubase-Projektdatei;
- Screenshots und Referenzbilder unter Docs/;
- historische beziehungsweise vom User bereitgestellte Masterprompt-Dateien;
- jede weitere nicht eindeutig als Milestone-Projektdatei zuordenbare
  untracked Datei.

Auch dieser V0.12.75-Masterprompt ist beim spaeteren Start kein Bestandteil
eines frueheren Reconciliation-Commits. Er gehoert, falls committed, erst zur
V0.12.75-Dokumentation.

Weitere verifizierte Ausgangsfakten:

- Aktuelle VST3- und Standalone-Artefakte existieren in Debug und Release und
  melden 0.12.5.
- Die aktuelle Suite umfasst im Snapshot 39 CTests.
- Die V0.12.5-Evidence dokumentiert Debug 39/39, Release 39/39 sowie jeweils
  696/696 finale Renderfaelle, finite Ausgaben und ruhige Tails.
- Der freigegebene Factory-Katalog umfasst 116 Presets; SHA-256 des beim Audit
  gelesenen Katalogs:
  6bdf7dcdaa2423b6aed6691c0bdf4c0b9a408280905ec9d7b86f5d03c93aa8e2
- V0.12.5-Evidence-Root:
  Artifacts/V0.12.5/20260904T172424Z/
- Die Scripts fuer finale Factory-Evidence erlauben beim Snapshot nur Roots
  unter Artifacts/V0.12.0 und Artifacts/V0.12.5. Fuer V0.12.75 ist diese
  Whitelist eng um Artifacts/V0.12.75 zu erweitern; beliebige Pfade bleiben
  verboten und die positiven/negativen Pfadtests werden angepasst.

Reale Architektur beim Audit:

- DeepPluckEditor ist fest auf 1536 x 900 Pixel eingestellt und nicht
  resizable.
- Header, Oszillatorbereich, Navigation, Seiten und Footer werden im Editor
  angeordnet; ein virtuelles Keyboard existiert dort noch nicht.
- processBlock() laesst den bestehenden DeepPluckSynthesiser den eingehenden
  MidiBuffer rendern und fuehrt danach die globalen FX und den Output aus.
- DeepPluckSynthesiser verarbeitet MIDI-Events mit samplegenauer Unterteilung
  zwischen den Eventpositionen.
- Es bestehen exakt 16 vorallokierte Stimmen. Der 17. Note-On nutzt das
  bestehende Voice-Stealing.
- Ein zweiter Note-On derselben Note und desselben Kanals retriggert nach der
  bestehenden Semantik die passende Stimme. Note-Off beendet die passende
  Note. V0.12.75 fuehrt keine Source-Referenzzaehlung ein.
- releaseResources() stoppt bestehende Stimmen hart und setzt FX/Meter zurueck.
- Das Developer-Audition-Tool enthaelt bereits ein erprobtes Konzept mit
  juce::MidiKeyboardState und juce::MidiKeyboardComponent. Es darf als
  Referenz dienen, wird aber nicht als zweiter Synthpfad in das Produkt kopiert.
- JUCEs Standard-Standalone-Wrapper besitzt einen StandalonePluginHolder mit
  AudioProcessorPlayer und dessen MidiMessageCollector. Der Collector ist
  bereits der richtige gemeinsame Eingang fuer externes und virtuelles MIDI,
  bevor processBlock() aufgerufen wird.

Wiederhole das Audit beim realen Ausfuehrungsstart. Der Snapshot ist eine
Orientierung und Provenienz, aber kein Vorwand, legitime inzwischen erfolgte
Aenderungen zu verwerfen.

===============================================================================
3. PRE-MILESTONE RECONCILIATION GATE
===============================================================================

Dieses Gate ist zwingend und kommt vor jeder V0.12.75-Quellcodeaenderung.

3.1 Vollstaendige Bestandsaufnahme

1. Erfasse Branch, HEAD, Index, git status --short, git status --ignored sowie
   tracked und untracked Diff-Uebersichten.
2. Sichere die Ausgabe als Berichtsdaten, nicht durch Veraenderung des
   Arbeitsbaums.
3. Pruefe insbesondere jede der beim Snapshot genannten tracked Dateien sowie
   alle inzwischen hinzugekommenen Aenderungen.
4. Ordne jede tracked Aenderung anhand von Code, Reports, Evidenz und Historie
   einer Kategorie zu:
   - V0.11.5 CPU Profiling / DSP Optimization;
   - V0.12.0 Factory Presets;
   - V0.12.5 Welcome / About / UX Polish;
   - andere bekannte legitime Arbeit;
   - unbekannt oder nicht sicher zuordenbar.
5. Klassifiziere untracked Dateien getrennt in legitime Projektarbeit und
   geschuetzte User-Dateien. Im Zweifel bleibt eine Datei geschuetzt.
6. Veraendere in diesem Audit nichts.

3.2 Validierung frueherer Arbeit

Pruefe, ob der exakte vorhandene Stand zu den vorhandenen Reports und Evidence-
Roots passt. Bereits gueltige, vergleichbare Evidence darf wiederverwendet
werden. Starte nicht allein fuer die Reconciliation unnoetig den gesamten
696-Faelle-Corpus neu. Fehlende oder nicht mehr zum Quellstand passende
gezielte Validierungen muessen jedoch nachgeholt werden.

Verifiziertes bekanntes Problem, das nicht verschwiegen werden darf:

- Der V0.11.5-Report weist den harten Realtime-/D96-64-Performance-Gate nicht
  als bestanden aus. Eine Bestaetigungsrunde enthielt 11 Candidate Misses;
  D96/64 blieb als technischer Befund OPEN beziehungsweise deferred.
- Die spaetere praktische User-Bestaetigung, dass alles funktioniert und die
  Roadmap fortgesetzt werden soll, ist eine Funktionsabnahme. Sie darf nicht
  rueckwirkend als gemessener Performance-PASS ausgegeben werden.
- V0.12.0 und V0.12.5 besitzen umfangreiche funktionale und Audio-Evidence,
  die diesen Performance-Befund ebenfalls nicht stillschweigend aufhebt.

Vor einem Reconciliation-Commit und vor V0.12.75 gilt daher:

A. Wenn der D96/64-Gate inzwischen mit gueltiger vergleichbarer Evidenz
   nachweislich erfuellt wurde, dokumentiere die Evidenz und fahre fort.

B. Wenn er weiterhin offen ist, benoetigst du eine ausdrueckliche
   Benutzerfreigabe, den Befund als bekannte, dokumentierte technische
   Einschraenkung fuer die gemeinsame Baseline zu deferieren. Frage genau
   danach. Behaupte dabei weder einen PASS noch eine erfolgreiche CPU-
   Optimierungsabnahme.

C. Ohne A oder B ist die Reconciliation nicht abgeschlossen. Implementiere
   V0.12.75 noch nicht. Melde den echten Autoritaets-/Baseline-Blocker.

Eine passende knappe Freigabefrage lautet sinngemaess:

"Der bekannte V0.11.5-D96/64-Performance-Befund ist technisch weiterhin offen.
Darf ich ihn als dokumentierte bekannte Einschraenkung deferieren und den
validierten gemeinsamen V0.11.5-bis-V0.12.5-Arbeitsstand als lokale Baseline
sichern, ohne den Performance-Gate als bestanden zu bezeichnen?"

3.3 Reconciliation-Commits

Erstelle Checkpoint-Commits nur fuer abgeschlossene und ausreichend validierte
fruehere Projektarbeit. Stage explizite Pfade; verwende wegen der geschuetzten
untracked Dateien kein pauschales git add . oder git add -A.

- Wenn die Aenderungen sicher trennbar sind, verwende getrennte Commits mit
  ehrlichen Nachrichten.
- Wenn CMake, Dokumentation, Processor und zentrale Tests technisch verflochten
  sind, erzwinge keine riskante Hunk-Zerlegung. Nach erteilter Freigabe darf ein
  gemeinsamer Baseline-Commit verwendet werden, zum Beispiel:
  chore: reconcile V0.11.5 through V0.12.5 working baseline
- Eine solche Nachricht und der Report muessen den offenen D96/64-Befund
  ausdruecklich erhalten. Verwende nicht "performance passed" oder
  "completed optimization", wenn die Evidence das nicht traegt.
- Schliesse geschuetzte Dateien, build/, Artifacts/ und diesen V0.12.75-
  Masterprompt aus den frueheren Checkpoints aus.
- Pruefe vor jedem Commit den staged Diff und nach jedem Commit den Hash.

3.4 Reconciled Baseline / Start HEAD

Nach der Reconciliation:

1. Erfasse den neuen HEAD.
2. Pruefe, dass keine unbekannten tracked Aenderungen uebrig sind.
3. Geschuetzte untracked Dateien duerfen und sollen weiterhin vorhanden sein.
4. Dokumentiere eventuell bewusst verbleibende, eindeutig zugeordnete tracked
   Aenderungen. Ein solcher Zustand ist nur zulaessig, wenn er die V0.12.75-
   Abgrenzung nicht unklar macht.
5. Dieser dokumentierte HEAD ist der einzige V0.12.75-Start-HEAD.
6. Bestaetige, dass keine fruehere Benutzerarbeit verloren, ueberschrieben oder
   in einen falschen Commit aufgenommen wurde.

===============================================================================
4. MILESTONE GOAL AND PRODUCT BOUNDARY
===============================================================================

Ergaenze die Standalone-Anwendung am unteren Rand um ein kleines, direkt mit der
Maus spielbares virtuelles MIDI-Keyboard. Es dient dem schnellen Spielen und
Testen ohne externen MIDI-Controller.

Verbindliches Ergebnis:

- nur Standalone zeigt und aktiviert das Keyboard;
- VST3 bleibt optisch und funktional ohne Keyboard;
- Mausaktionen erzeugen echte MIDI-Note-On-/Note-Off-Ereignisse;
- externe und virtuelle MIDI-Eingabe koexistieren im vorhandenen JUCE-
  Produktionspfad;
- Oct - und Oct + verschieben den sichtbaren Bereich in 12-Halbton-Schritten;
- kein neuer Host-Parameter, keine State-/Preset-Aenderung, kein neuer DSP;
- unbenutzt ist der Sound unveraendert.

===============================================================================
5. HARD COMPATIBILITY CONTRACT
===============================================================================

Der eingefrorene V0.11.0-Vertrag fuer die 62 Parameter mit den Indizes 0..61
bleibt byte- und bedeutungstreu. Veraendere nichts an:

- Anzahl, Index, ID, Hostname oder Typ;
- Version Hint;
- Range, Interval, Choice-Reihenfolge, Default oder Skew/Mapping;
- Raw Unit/Meaning oder Textsemantik;
- APVTS-Layout und Attachments;
- Preset-Schema, Factory-Inhalt, User-/Pack-Presets;
- Host-State-Semantik und Migration;
- Randomization, Locks und Undo;
- Product- und Host-Identitaet.

Identitaet bleibt exakt:

- Product / Host Name: DeepPluck
- Manufacturer Code: Tntx
- Plugin Code: DpV1
- Bundle ID: de.tonetrax.deeppluck
- Instrument: kein Audio-Input, Stereo-Output, MIDI-Input, kein MIDI-Output

Keyboard, sichtbare Oktave und gedrueckte Tasten duerfen nie in APVTS,
Automation, Presets, State, Randomization, Lock oder Undo auftauchen. Es gibt
keine Migration, weil kein persistierter Keyboard-Zustand eingefuehrt wird.

===============================================================================
6. STANDALONE-ONLY AND WRAPPER CONTRACT
===============================================================================

Nutze ausschliesslich die echte JUCE-Wrapper-Identitaet. Keine Datei-, Prozess-,
Executable-, Fenstertitel- oder Pfaderkennung.

Verbindliche Erkennung:

- Pruefe audioProcessor.wrapperType gegen
  juce::AudioProcessor::wrapperType_Standalone.
- Erzeuge und verbinde den Keyboard-Bereich nur in diesem Fall.
- Bei wrapperType_VST3, wrapperType_Undefined und allen anderen Typen wird
  weder eine Keyboard-Komponente erzeugt noch Flaeche reserviert noch auf den
  StandalonePluginHolder zugegriffen.
- Verifiziere im Standalone-Fall, dass der gefundene Holder wirklich denselben
  Processor besitzt wie der Editor, bevor der MIDI-Collector verbunden wird.

Kein eigener Standalone-Wrapper und keine Aenderung unter JUCE/. Verwende den
offiziellen JUCE-9-Standalone-Wrapper.

===============================================================================
7. BINDING KEYBOARD ARCHITECTURE
===============================================================================

Verwende JUCEs vorhandene Bausteine:

- juce::MidiKeyboardState
- juce::MidiKeyboardComponent in horizontaler Darstellung
- juce::MidiMessageCollector des bestehenden Standalone AudioProcessorPlayer

Lege eine fokussierte projektinterne GUI-Klasse an, sinngemaess
DeepPluckStandaloneKeyboardPanel. Sie besitzt primaer:

- MidiKeyboardState;
- MidiKeyboardComponent;
- Oct-- und Oct+-Buttons;
- aktuellen niedrigsten sichtbaren MIDI-Key;
- eine klar begrenzte Listener-/Collector-Verbindung;
- idempotente Cleanup-Logik.

Der Editor orchestriert nur Sichtbarkeit und Layout. Der Processor bleibt DSP-
und State-Eigentuemer. Der Editor besitzt weiterhin keinen DSP.

Produktionsverbindung:

1. Nur im Standalone-Modus den aktiven
   juce::StandalonePluginHolder::getInstance() abfragen.
2. Pruefen, dass holder != nullptr und holder->processor.get() auf genau den
   Processor des Editors zeigt.
3. Den MidiMessageCollector von holder->player.getMidiMessageCollector() als
   MidiKeyboardState::Listener registrieren.
4. Der Collector versieht die GUI-Ereignisse mit Zeitstempeln und fuehrt sie im
   bereits vorhandenen AudioProcessorPlayer mit externen MIDI-Ereignissen
   zusammen, bevor DeepPluckAudioProcessor::processBlock() beginnt.
5. processBlock(), DeepPluckSynthesiser, Voice und DSP muessen fuer diese
   Funktion unveraendert bleiben.

Isoliere den Zugriff auf den globalen StandalonePluginHolder in einer kleinen
GUI-seitigen Adapter-/Connector-Grenze. Stelle fuer Tests eine explizite
Injection-Seam bereit, ueber die ein Fake-MidiKeyboardState-Listener verwendet
werden kann. Tests duerfen weder einen realen Audio-Device-Start noch globale
User-Preferences voraussetzen.

Falls die offizielle JUCE-Header-/Target-Grenze eine kleine projektinterne
Adapterdatei erforderlich macht, fuehre sie in CMake explizit auf und beweise,
dass Shared Code, VST3 und Standalone sauber bauen. Erfinde keinen zweiten
Wrapper.

Verbotene Alternativen:

- direkter GUI-Aufruf von Synthesiser oder Voice;
- kopierter Test-Synth oder zweite Voice-Engine;
- GUI-Komponente im Audio-Thread;
- MidiKeyboardState::processNextMidiBuffer() aus DeepPlucks processBlock();
- projektinterne lockende oder allokierende MIDI-Queue im Audio-Callback;
- Timer-Polling fuer gespielte Noten;
- Host-MIDI-Aenderungen am VST3.

Wenn der offizielle Collector-Weg nach nachweislicher Pruefung technisch nicht
verwendbar ist, stoppe vor einem audioseitigen Fallback und dokumentiere den
externen Architekturblocker. Fuehre nicht stillschweigend eine riskante Queue
oder einen neuen MIDI-Vertrag ein.

===============================================================================
8. MIDI INJECTION AND SAMPLE-ACCURACY CONTRACT
===============================================================================

Die Bildschirmtasten erzeugen auf MIDI-Kanal 1 normale Note-On-/Note-Off-
Nachrichten. Die JUCE-Mouse-Velocity darf verwendet werden, muss aber in 0..1
begrenzt und praktisch sinnvoll initialisiert sein. Keine Velocity-Control-GUI.

Erhalte unveraendert:

- den bestehenden eingehenden MidiBuffer des Processors;
- Event-Samplepositionen und die vorhandene samplegenaue Renderunterteilung;
- Note-On-/Note-Off-Reihenfolge;
- bestehende Sustain-/Controller-Semantik externer MIDI-Quellen;
- 16 vorallokierte Stimmen und bestehendes Voice-Stealing;
- no-input/stereo-output und kein MIDI-Output.

Der Standard-Standalone-Collector ist die Merge-Stelle. Fuehre im Plugin keinen
zweiten Merge durch. Ohne virtuelle Ereignisse muss der an DeepPluck gelieferte
MIDI-/Audiopfad identisch zum Ausgangsstand bleiben.

===============================================================================
9. EXTERNAL + VIRTUAL MIDI COEXISTENCE
===============================================================================

Externes MIDI darf weder ersetzt noch deaktiviert werden. Teste in Standalone:

- externe Quelle allein;
- virtuelle Quelle allein;
- beide Quellen mit verschiedenen ueberlappenden Noten;
- Akkorde und schnelle Retrigger;
- dieselbe Note/derselbe Kanal aus beiden Quellen;
- Note-Off-Reihenfolgen;
- 16 Stimmen und eine 17. Note;
- Cleanup bei noch gehaltenen virtuellen Noten.

Bewahre die bestehende Synthesiser-Semantik fuer gleiche Note/Kanal. Fuehre
keine Source-Referenzzaehlung ein. Dokumentiere im Report, dass die Quellen als
normaler gemeinsamer MIDI-Stream behandelt werden: ein erneuter gleicher
Note-On retriggert nach bestehender Semantik, und ein passender Note-Off beendet
die Note. Entscheidend sind deterministisches Verhalten und keine haengenden
Noten, nicht eine neue Multi-Source-Lifecycle-Semantik.

===============================================================================
10. MOUSE INTERACTION
===============================================================================

Verbindlich:

- Mouse-down auf einer weissen oder schwarzen Taste erzeugt Note-On;
- Mouse-up erzeugt Note-Off;
- Drag ueber Tasten nutzt das musikalisch sinnvolle JUCE-Standardverhalten;
- schnelle wiederholte Klicks hinterlassen keine aktive Note;
- Verlassen der Komponente beziehungsweise Abbruch einer Mouse-Geste wird durch
  JUCE-State und explizites Cleanup sicher behandelt;
- Mehrfachklicks oder Drag ausserhalb gueltiger MIDI-Keys erzeugen keine
  ungueltigen Nachrichten.

Schreibe keine eigene Piano-Hit-Test- oder Tasten-Engine.

===============================================================================
11. OCTAVE CONTROLS
===============================================================================

Verwende zwei kleine Buttons mit sichtbaren Texten:

- Oct -
- Oct +

Festgelegtes Verhalten:

- Sie verschieben den niedrigsten sichtbaren Key um exakt 12 Halbtoene.
- Verfuegbarer MIDI-Bereich ist 0..127.
- Startwert ist MIDI-Note 36 (C2).
- Der niedrigste sichtbare Key liegt nur auf Oktavgrenzen im Bereich 0..60.
- Der aktuelle Wert wird auf diesen Bereich begrenzt.
- Oct - ist bei 0 disabled; Oct + ist bei 60 disabled.
- Buttons beeinflussen nur die dargestellten und per Maus spielbaren Noten,
  nicht externes MIDI und keine Synth-Transposition.
- Der Zustand wird nicht persistiert. Jeder neue Editor startet bei 36.
- Kein Host-Parameter, keine Preference-Datei und keine neue Persistence-
  Architektur.

Setze den MidiKeyboardComponent-Range auf 0..127, verstecke interne Scroll-
Buttons und halte die gewaehlte sichtbare Lage durch die eigenen Octave-
Controls eindeutig.

===============================================================================
12. OPTIONAL COMPUTER KEYBOARD GATE - DECISION FOR REV2
===============================================================================

Die Computer-/QWERTZ-Tastatursteuerung wird in V0.12.75 bewusst DEFERRED.

Gruende:

- sie ist fuer das Ziel nicht erforderlich;
- MidiKeyboardComponent aktiviert standardmaessig Key-Mappings und kann Fokus
  anfordern;
- Parameter-Textfelder, Shortcuts und Host-Fokus duerfen nicht gestoert werden;
- die Mausloesung ist vollstaendig und risikoarm.

Verbindlich fuer Produktion:

- keyboard.setWantsKeyboardFocus(false);
- vorhandene Computer-Key-Mappings des MidiKeyboardComponent loeschen;
- keine KeyListener-/QWERTZ-Belegung hinzufuegen.

Dokumentiere die bewusste Defer-Entscheidung im Implementation Report. Fuehre
keine optionalen Computer-Keyboard-Tests aus, weil das Feature nicht existiert.

===============================================================================
13. ALL-NOTES-OFF AND CLEANUP SAFETY
===============================================================================

Die Keyboard-Verbindung hat eine explizite, idempotente Lebensdauer.

Reihenfolge bei Panel-/Editor-Cleanup:

1. Auf dem Message Thread keine neuen Mouse-Ereignisse mehr annehmen.
2. Solange der Listener noch verbunden ist, ueber MidiKeyboardState alle dort
   aktiven virtuellen Noten auf Kanal 1 freigeben. Dadurch entstehen regulaere
   Note-Off-Ereignisse fuer genau die vom Keyboard gehaltenen Noten.
3. Erst danach den Listener entfernen.
4. State und Component zerstoeren.

Keine pauschale Controller-All-Notes-Off-Nachricht waehrend eines normalen
laufenden Editor-Detach senden, wenn sie externe gehaltene Noten unnoetig
abschneiden wuerde. Beim echten Standalone-Shutdown beziehungsweise Audio-
Device-Reset bleibt der vorhandene harte Voice-Stopp in releaseResources() die
letzte Sicherheitsstufe.

Pruefe:

- Schliessen bei gehaltener virtueller Note;
- Editor-Zerstoerung;
- wiederholten Cleanup-Aufruf;
- Audio-Device stop/start und releaseResources();
- Holder-/Processor-Lebensdauer;
- Listener wird nie nach Zerstoerung dereferenziert;
- keine haengende Voice und kein Use-after-free.

Wenn die Welcome-Ansicht aktiv ist, darf das darunterliegende Keyboard keine
Mouse-Eingaben erhalten. Beim Umschalten darf keine aktive Note haengen bleiben.

===============================================================================
14. GUI LAYOUT CONTRACT
===============================================================================

Ausgangsgroesse der Haupt-GUI: 1536 x 900.

Festgelegte Groessen:

- VST3: exakt 1536 x 900, unveraendert, nicht resizable.
- Standalone: 1536 x 980, nicht resizable.
- Bestehender Hauptbereich in Standalone: exakt Bounds (0, 0, 1536, 900).
- Neuer Keyboard-Strip: exakt Bounds (0, 900, 1536, 80).

Die bestehenden Header-, Oscillator-, Tab-, Page- und Footer-Bounds werden in
einem expliziten 1536-x-900-Main-Rectangle berechnet. Komprimiere, skaliere oder
verschiebe kein bestehendes Control. VST3 reserviert keine 80 Pixel.

Keyboard-Strip:

- Keyboard zentral und ueber nahezu die gesamte Breite;
- Oct - links, Oct + rechts;
- kleine konsistente Innenabstaende;
- horizontale JUCE-Pianotastatur;
- Key-Width ungefaehr 36 bis 40 Pixel, nach realem Rendering so waehlen, dass
  der Bereich kompakt und gut bedienbar ist;
- keine Scrollbars und keine abgeschnittenen Tasten/Buttons;
- keine neue GUI-Skalierung, kein Responsive-/Reflow-System.

Die vorhandene Welcome-Overlay-Komponente deckt in Standalone die gesamte
Editorflaeche einschliesslich Keyboard-Strip ab oder blockiert diesen eindeutig,
damit das Keyboard nicht unsichtbar hinter der Welcome-Seite spielbar ist. In
VST3 bleibt ihr bisheriges 1536-x-900-Verhalten unveraendert.

===============================================================================
15. VISUAL LANGUAGE, ACCESSIBILITY AND FOCUS
===============================================================================

Verwende die bestehende DeepPluck-LookAndFeel-Sprache:

- dunkler Petrol-Grund;
- klare helle und dunkle Piano-Tasten;
- Teal/Petrol fuer Rahmen, Hover und neutrale Aktivitaet;
- zurueckhaltendes Amber fuer gedrueckte Tasten oder kleine Akzente;
- keine Gaming-Neon-Optik, kein starker Glow, kein 3D-Piano;
- funktional klarer und ruhiger als die Haupt-Synth-Controls.

Nutze JUCE-Colour-IDs beziehungsweise eine kleine fokussierte Darstellungsklasse
statt einer eigenen Tasten-Engine. Pruefe Kontrast in normal, hover, pressed,
focused und disabled.

Accessibility-/Focus-Vertrag:

- Octave-Buttons erhalten eindeutige Namen, Component IDs und Tooltips;
- ausreichende Mouse-Hit-Targets;
- sinnvolle Tab-Reihenfolge fuer die beiden Buttons;
- das Piano selbst fordert keinen Keyboard-Fokus an;
- Computer-Key-Mappings sind deaktiviert;
- bestehende Parameter-Textfelder und Shortcuts bleiben bedienbar;
- keine Fokus-Schleife und kein verschluckter Texteingabe-Key;
- Focus-Wechsel verursacht keine haengende virtuelle Note.

===============================================================================
16. VST3 NON-REGRESSION AND SOUND NEUTRALITY
===============================================================================

VST3 erhaelt:

- keine Keyboard-Komponente;
- keinen Standalone-Holder-Zugriff;
- keine zusaetzliche Flaeche;
- keine Groessen-, Layout-, Fokus- oder Control-Aenderung;
- keinen MIDI-, State-, Preset-, Parameter- oder Audio-Pfad-Unterschied.

Standalone ohne virtuelle Eingabe und VST3 mit identischer externer MIDI-
Sequenz muessen gegen einen unveraenderten Referenzpfad identisch bleiben, soweit
die bestehende deterministische Evidence dies erlaubt. Das Keyboard darf weder
Pitch, Velocity, Voice-Parameter, Filter, Envelope, FX noch Output beeinflussen,
solange es nicht gespielt wird.

Veraendere keine DSP-, Processor-, Synthesiser-, Voice-, Filter-, Envelope-,
Oscillator-, Modulations-, FX- oder Parameterfunktion nur fuer dieses Feature.
Wenn eine unerwartete produktionsseitige Audioaenderung erforderlich scheint,
stoppe und eskaliere den Scope-Konflikt.

===============================================================================
17. REALTIME SAFETY AND PERFORMANCE
===============================================================================

Die neue Logik laeuft auf Message-/Wrapper-Ebene. Der vorhandene JUCE-
AudioProcessorPlayer sammelt MIDI vor dem Processor-Callback.

Verbindlich:

- keine neue Allokation oder Sperre in DeepPlucks Audio-Callback;
- keine GUI-, Holder-, KeyboardState- oder Component-Abfrage im Audio-Thread;
- keine APVTS-Suche im Sample-/Voice-Pfad;
- keine Datei-, Netzwerk-, Logging- oder Timerarbeit im Audio-Thread;
- kein hochfrequentes Polling;
- keine praktisch relevante Idle-CPU-Last durch das Keyboard;
- keine neue CPU-Optimierungsrunde.

Bewahre die V0.11.5-Optimierungen und dokumentiere den bekannten D96/64-Status
ehrlich. V0.12.75 darf ihn nicht verschlechtern und nicht umetikettieren.

===============================================================================
18. IMPLEMENTATION ORDER
===============================================================================

Arbeite nach dem erfolgreichen Reconciliation Gate in dieser Reihenfolge:

1. Baseline erfassen
   - Start-HEAD und sauberen/nachvollziehbaren Status protokollieren.
   - relevante vorhandene Fast-Tests einmal ausfuehren.
   - VST3-Groesse, Standalone-Groesse, 62 Parameter und State/Preset-Vertrag als
     Baseline festhalten.

2. Testbare Layout-/Runtime-Entscheidung isolieren
   - eine kleine reine Entscheidung fuer Standalone versus Nicht-Standalone
     und die beiden Zielgroessen bereitstellen;
   - keine Dateinamen- oder Prozessheuristik.

3. Standalone-Keyboard-Panel implementieren
   - MidiKeyboardState, MidiKeyboardComponent, Octave-Buttons;
   - Range, Startnote, Clamp, Focus, Farben, Tooltips und Cleanup;
   - testbare Listener-/Collector-Injection.

4. Offiziellen Standalone-Collector verbinden
   - Holder/Processor-Identitaet pruefen;
   - Listener nur in Standalone anhaengen;
   - Produktionsprocessor und processBlock unveraendert lassen.

5. Editor-Layout erweitern
   - VST3 1536 x 900;
   - Standalone 1536 x 980;
   - Main-Bounds unveraendert, Strip unten;
   - Welcome-Overlay und Hit-Testing sicher behandeln.

6. Fast-/Targeted-Tests hinzufuegen und waehrend der Iteration verwenden.

7. Representative Plugin/Audio Smokes ausfuehren.

8. Version auf 0.12.75 aus der zentralen CMake-Version propagieren und
   Evidence-Whitelists eng erweitern.

9. README.md, ARCHITECTURE.md, Testdokumentation und Implementation Report
   gemeinsam aktualisieren.

10. Erst am finalen Quellstand den kompletten Debug-/Release-/Corpus-Gate
    ausfuehren.

11. Explizit stagen, staged Diff pruefen, Milestone-Commit erstellen und finalen
    Status/Hash erfassen.

===============================================================================
19. THREE-LEVEL TEST STRATEGY
===============================================================================

Keine Tests entfernen, abschwaechen oder durch oberflaechliche Assertions
ersetzen. Der grosse Corpus wird waehrend reiner GUI-Iteration nicht wiederholt.

19.A FAST / TARGETED

Lege eine fokussierte CTest-Suite an, vorzugsweise
DeepPluck.standalone_keyboard, oder erweitere die bestehende Testarchitektur
gleichwertig. Sie muss ohne reale Audio-Hardware, User-Preferences oder
interaktive Fenster reproduzierbar laufen.

Mindestens automatisieren:

1. Standalone-Erkennung erzeugt genau ein Keyboard-Panel.
2. VST3 und Undefined erzeugen keines und reservieren keine Flaeche.
3. VST3-Groesse bleibt 1536 x 900.
4. Standalone-Groesse ist 1536 x 980; die 1536-x-900-Main-Bounds sind identisch.
5. Keyboard-Bounds sind nur in Standalone vorhanden.
6. Host-Parameteranzahl bleibt 62 und das komplette eingefrorene Manifest ist
   unveraendert.
7. Kein Keyboard-Zustand erscheint in Processor State oder Preset-Daten.
8. Mouse/State Note-On erzeugt am injizierten Listener Kanal 1, gueltige Note
   und begrenzte Velocity.
9. Note-Off wird fuer dieselbe Note erzeugt.
10. Wiederholte Note-On/Off-Folgen enden ohne aktive virtuelle Note.
11. Mehrere Noten/Akkord werden vollstaendig ein- und ausgeschaltet.
12. Drag-artige Folge besitzt deterministische On-/Off-Reihenfolge.
13. Oct -/+ bewegt exakt um 12; Start ist 36.
14. Untere Grenze 0 und obere Grenze 60 werden geclamped; Buttons sind dort
    korrekt disabled; es entstehen nur MIDI-Noten 0..127.
15. Computer-Key-Mappings und Keyboard-Fokus sind deaktiviert.
16. Virtuelle und externe Events lassen sich durch den Collector in einem
    gueltigen MidiBuffer koexistierend abholen; Samplepositionen bleiben im
    Blockbereich und ihre Reihenfolge ist deterministisch.
17. Gleiche Note aus beiden Quellen folgt der bestehenden Retrigger-/Note-Off-
    Semantik und endet ohne Stuck Note.
18. Cleanup gibt alle virtuell aktiven Noten frei, bevor der Listener detached.
19. Cleanup ist idempotent; Editor-/Panel-Zerstoerung erzeugt kein Use-after-free.
20. releaseResources() beendet verbleibende Stimmen sicher.
21. 16-Voice-Akkord funktioniert; die 17. Note nutzt Voice-Stealing ohne NaN,
    Inf oder haengende Stimme.
22. Ohne virtuelle Events bleibt der bestehende Audio-/State-Referenzpfad
    bitidentisch beziehungsweise exakt innerhalb der bereits verbindlichen
    deterministischen Vergleichssemantik.
23. Factory-, User- und Pack-Preset-Laden sowie State Restore bleiben
    unveraendert.
24. Evidence-Root-Tests akzeptieren ausschliesslich die explizit erlaubten
    V0.12.0-, V0.12.5- und V0.12.75-Unterbaeume und lehnen Pfad-Escapes ab.

Nutze fuer reine Listener-Tests einen Fake-Listener. Nutze fuer die
Collector-Integration JUCEs echten MidiMessageCollector ohne Audio-Device.
Teste Produktionsentscheidungen, nicht nur eine davon losgeloeste Kopie.

Fuehre diese schnellen Tests nach relevanten Codeaenderungen aus. Starte dabei
nicht den vollen 696-Corpus.

19.B REPRESENTATIVE PLUGIN / AUDIO SMOKE

Nach groesseren Integrationsschritten und vor dem Final Gate:

- Release Standalone starten und normal schliessen;
- ueber die produktionsnahe Test-Seam beziehungsweise reale UI virtuelle
  Note-On/Offs einspeisen und finite Audioausgabe bestaetigen;
- weisse und schwarze Note, Akkord, schnelle Retrigger und Voice-Stealing
  repraesentativ pruefen;
- externes MIDI allein und zusammen mit virtuellem MIDI pruefen;
- VST3-Bundle mit nativer Factory laden und externes MIDI rendern;
- bestaetigen, dass VST3 kein Keyboard und keine zusaetzliche Flaeche hat;
- Preset Load und State Restore smoke-testen;
- NaN/Inf, unbounded Peak und haengende Tails ausschliessen.

Halte diese Auswahl klein und repraesentativ. Ein GUI-Farb- oder Layoutfix
rechtfertigt keinen Full-Corpus-Lauf.

19.C FINAL FULL REGRESSION GATE

Der volle circa 696-Faelle-Corpus wird am finalen unveraenderten Quellstand
genau einmal pro akzeptierter Konfiguration ausgefuehrt: einmal Debug mit
696/696 und einmal Release mit 696/696, soweit die vorhandene finale
Factory-Audit-Struktur weiterhin pro Konfiguration arbeitet. Das sind zwei
konfigurationsspezifische finale Ausfuehrungen, keine Iterationslaeufe.

Ein zusaetzlicher voller Lauf ist nur zulaessig, wenn:

- der erste Lauf wegen eines realen Fehlers unvollstaendig war; oder
- nach dem Lauf produktionsrelevanter Audio-/DSP-Code geaendert wurde.

Dokumentiere Anzahl, Konfiguration, Evidence-Root, Ergebnis und Grund jedes
zusaetzlichen Laufs. Nach ausschliesslichen Dokumentationsaenderungen oder
Keyboard-Farben/-Bounds wird der Corpus nicht erneut gestartet.

===============================================================================
20. FINAL AUTOMATED GATE
===============================================================================

Vor frischer Konfiguration die Toolchain wie in Abschnitt 23 initialisieren.
Dann mindestens:

cmake --fresh -S . -B build -G "Visual Studio 18 2026" -A x64
cmake --build build --config Debug --parallel
ctest --test-dir build -C Debug --output-on-failure
cmake --build build --config Release --parallel
ctest --test-dir build -C Release --output-on-failure

Zusaetzlich am selben finalen Quellstand:

- alle neuen Fast-/Targeted-Tests in Debug und Release;
- genau die final vorgesehenen Debug-/Release-696-Corpus-Laeufe;
- Release Standalone Smoke mit normalem Close;
- VST3 Bundle Validation und native Factory Load;
- VST3 externes MIDI Audio-Smoke;
- Artifact-Version- und Generated-Version-Pruefungen;
- Debug und Release VST3/Standalone sowie lokale Kopien vorhanden;
- alle echten Artefakte melden 0.12.75;
- keine Compilerfehler und keine neuen Compilerwarnungen;
- keine automatische Installation in Systemordner;
- Build- und Artifact-Dateien bleiben ignoriert und unstaged;
- JUCE/ hat keinen Diff;
- geschuetzte User-Dateien sind unveraendert und unstaged.

Bewerte Warnungen anhand kompletter Build-Logs und der vor dem Milestone
erfassten Baseline. Verschweige keine neue Warnung.

===============================================================================
21. MANUAL STANDALONE / VST3 CHECKLIST
===============================================================================

Diese Punkte kann der User nach technischem Handoff real pruefen. Markiere jeden
nicht persoenlich vom User bestaetigten Punkt OPEN:

- Standalone oeffnet korrekt.
- Keyboard ist unten sichtbar.
- VST3 zeigt kein Keyboard und behaelt exakt sein bisheriges Layout.
- weisse Tasten funktionieren.
- schwarze Tasten funktionieren.
- Mouse Note-On und Note-Off sind korrekt.
- Drag ueber mehrere Tasten ist musikalisch sinnvoll.
- Akkorde und mehrere schnelle Noten funktionieren.
- Oct - funktioniert.
- Oct + funktioniert.
- tiefste und oberste Lage bleiben im gueltigen MIDI-Bereich.
- externes MIDI funktioniert gleichzeitig.
- Preset-Wechsel waehrend des Spielens funktioniert.
- keine haengenden Noten.
- Fenster schliessen waehrend gehaltener virtueller Note ist sicher.
- Audio stoppen/starten ist sicher.
- Standalone erneut oeffnen funktioniert.
- GUI und Keyboard sind vollstaendig sichtbar, nichts ist abgeschnitten.
- Keyboard passt optisch zur DeepPluck-GUI.
- keine stoerenden Focus-Probleme.
- Cubase laedt das VST3 unveraendert und externes MIDI funktioniert.
- manuelle Klangkontrolle bestaetigt Soundneutralitaet ohne Keyboard-Eingabe.

Computer-Tastatur wird in Rev2 nicht implementiert und ist daher kein
Abnahmepunkt.

===============================================================================
22. VERSION AND ARTIFACT CONTRACT
===============================================================================

Setze ausschliesslich project(... VERSION 0.12.75 ...) als autoritative
Versionsquelle. Keine zweite manuelle Versionskonstante einfuehren.

0.12.75 muss konsistent erscheinen in:

- CMake-Projekt und JUCE Target-Version;
- VST3;
- Debug Standalone;
- Release Standalone;
- generated JUCE-Makros;
- Windows VERSIONINFO;
- About-Ansicht;
- lokalen Projekt-Artefakten;
- Implementation Report.

Die vorhandenen Pre-Build- und Artifact-Pruefungen muessen bei stale Versionen
weiterhin hart fehlschlagen. Erweitere sie nur so weit, wie 0.12.75 und die neue
Standalone-Groesse es erfordern. Keine Quellen duplizieren, um einen Test zu
umgehen.

Erweitere die gebundenen Factory-Evidence-Pfade von V0.12.0/V0.12.5 um genau
V0.12.75. Fehlertexte und TestEvidencePaths werden konsistent aktualisiert.
Artifacts bleiben ausserhalb Git.

===============================================================================
23. BUILD AND TOOLCHAIN CONTRACT
===============================================================================

Referenzumgebung:

- Windows 11 x64
- Visual Studio Community 2026
- Developer Command Prompt 18.9.2
- Generator: Visual Studio 18 2026
- MSVC 19.51.36256.0
- VCTools 14.51.36231
- Windows SDK 10.0.26100.0
- CMake 4.4.3
- JUCE 9.0.1
- C++20

Vor jeder frischen CMake-Konfiguration:

1. tatsaechlich installierte bestaetigte Visual-Studio-2026-Instanz lokalisieren;
2. deren x64 MSVC Developer Environment initialisieren;
3. where cl pruefen;
4. cl ausfuehren und Version dokumentieren;
5. cmake --version pruefen;
6. Generator-Verfuegbarkeit pruefen;
7. Windows SDK pruefen;
8. erst dann cmake --fresh ausfuehren.

Wechsle nicht Generator, Compiler, Toolset oder SDK, nur weil eine normale
Shell cl nicht kennt. Visual Studio 2022 ist nicht die Referenz und soll nicht
installiert werden. Andere Toolchains sind ungetestet.

===============================================================================
24. DOCUMENTATION CONTRACT
===============================================================================

Aktualisiere gemeinsam mit der Implementierung mindestens:

- README.md: Standalone-Keyboard, Standalone-/VST3-Groessendifferenz,
  Bedienung, Build/Test und offene manuelle Abnahme;
- ARCHITECTURE.md: Wrapper-Erkennung, Holder/Collector-Verbindung,
  Thread-/Ownership-Grenzen, MIDI-Koexistenz und Cleanup;
- relevante Test-/Workflow-Dokumentation: drei Testebenen und finale
  Corpus-Regel;
- CMake-/Quellkommentare nur dort, wo sie einen nicht offensichtlichen Vertrag
  erklaeren;
- Docs/DeepPluck_V0.12.75_Standalone_Virtual_MIDI_Keyboard_Implementation_Report.md.

Behaupte keine QWERTZ-Unterstuetzung und keine manuell ungepruefte Kompatibilitaet.

===============================================================================
25. OUT OF SCOPE
===============================================================================

Nicht implementieren:

- Pitch Bend oder Pitch-Bend-Range-Parameter;
- Sustain-/Hold-Button oder neuer Sustain-Parameter;
- neue oder geaenderte Host-Parameter;
- Parameter-Range-/Default-/Skew-/Text-Aenderungen;
- Preset-/State-Schema oder neue Factory-Preset-Arbeit;
- Oszillatoren, Waveforms, Filter, Modulationsziele/-matrix oder FX;
- Tone-/Voicing-Aenderungen;
- neue CPU-Optimierungsrunde;
- grosses GUI-Redesign, Responsive Layout oder Resizing;
- VST3-On-Screen-Keyboard;
- QWERTZ-/Computer-Keyboard in dieser Revision;
- MIDI Output, MIDI Learn, Arpeggiator, Sequencer oder Chord Memory;
- MPE;
- Installer, Updater, Cloud, Netzwerk oder Telemetrie;
- RC-Arbeit aus V0.13 oder Final-Release-Arbeit aus V1.0.

===============================================================================
26. DEFINITION OF DONE
===============================================================================

V0.12.75 ist automatable-complete nur wenn alle folgenden Punkte belegt sind:

- Reconciliation Gate abgeschlossen;
- offener V0.11.5-D96/64-Status entweder technisch geloest oder ausdruecklich
  als bekannte Einschraenkung autorisiert und ehrlich dokumentiert;
- keine fruehere legitime Arbeit verloren;
- V0.12.75-Start-HEAD und eventuelle Checkpoint-Hashes dokumentiert;
- virtuelles MIDI-Keyboard nur in Standalone vorhanden;
- VST3 besitzt kein Keyboard, keine Zusatzflaeche und bleibt 1536 x 900;
- Standalone ist 1536 x 980, Haupt-GUI darin unveraendert 1536 x 900;
- Mouse Note-On, Note-Off, Drag, schnelle Noten und Akkorde funktionieren;
- Oct -/+ arbeiten in 12er-Schritten und clamping 0..60/Noten 0..127 ist sicher;
- externes und virtuelles MIDI koexistieren im Standard-JUCE-Collector;
- gleiche Note, Retrigger, 16 Stimmen und 17.-Voice-Steal enden ohne Stuck Note;
- Cleanup, Editorzerstoerung, release/reset und Shutdown sind sicher;
- Computer-Key-Mappings/Fokus sind deaktiviert;
- Processor-, Synthesiser- und DSP-Audiopfad fuer das Feature unveraendert;
- 62-Parameter-Manifest, APVTS, Presets, State und Hostidentitaet unveraendert;
- unbenutztes Keyboard veraendert Audio nicht;
- keine neue relevante Idle-/Audio-CPU-Last;
- alle Fast-/Targeted-Tests bestehen in Debug und Release;
- Representative Plugin-/Audio-Smokes bestehen;
- komplette Debug-CTest-Suite besteht;
- komplette Release-CTest-Suite besteht;
- finaler Debug-Corpus 696/696 und Release-Corpus 696/696 bestehen;
- Outputs sind finite, ohne NaN/Inf, unbounded Peaks oder haengende Tails;
- Standalone-Smoke und VST3-Validation bestehen;
- VST3, Standalone und lokale Kopien existieren in Debug und Release;
- alle echten Artefakte melden 0.12.75;
- keine Compilerfehler und keine neuen Compilerwarnungen;
- Evidence liegt nur in erlaubten Artifacts/V0.12.75-Unterpfaden;
- build/ und Artifacts/ sind ignoriert und unstaged;
- kein Systeminstall, kein Push, JUCE/ unveraendert;
- geschuetzte untracked Dateien unveraendert und unstaged;
- Dokumentation und Implementation Report vollstaendig.

Manuelle Standalone-, VST3-, Cubase-, Focus- und Hoerchecks bleiben OPEN, bis
der User sie real bestaetigt. Ihr offener Status verhindert nicht die ehrliche
Bezeichnung automatable-complete, darf aber nicht als finale manuelle Abnahme
ausgegeben werden.

===============================================================================
27. IMPLEMENTATION REPORT REQUIREMENTS
===============================================================================

Der Report muss mindestens enthalten:

1. Datum, Branch und Referenztoolchain.
2. Urspruenglichen HEAD beim ersten Audit.
3. Vollstaendigen urspruenglichen Git-Status und Indexstatus.
4. Tabelle aller urspruenglichen tracked Aenderungen mit Zuordnung zu
   V0.11.5/V0.12.0/V0.12.5/anderer/unklarer Arbeit.
5. Klassifikation legitimer und geschuetzter untracked Dateien.
6. Verwendete fruehere Reports/Evidence und deren Vergleichbarkeit.
7. Ehrlichen D96/64-Status und entweder neue Pass-Evidence oder Wortlaut/Datum
   der ausdruecklichen Defer-Freigabe.
8. Reconciliation-/Checkpoint-Commits mit Nachricht und vollem Hash.
9. Finalen V0.12.75-Start-HEAD.
10. Bestaetigung, dass keine fruehere Benutzerarbeit verloren ging.
11. Reale Ausgangsarchitektur und geaenderte Dateien.
12. Wrapper-Erkennung und Nachweis, dass VST3 keinen Holder-Zugriff ausfuehrt.
13. MidiKeyboardState-/MidiKeyboardComponent-Ownership.
14. Holder/AudioProcessorPlayer/MidiMessageCollector-Injection und Test-Seam.
15. Beibehaltung der samplegenauen Produktionsverarbeitung.
16. Externes+virtuelles MIDI und dokumentierte Same-Note-Semantik.
17. Layout: VST3 1536x900, Standalone 1536x980, Strip 80 Pixel.
18. Octave-Verhalten, Clamp und nicht persistierter Startwert.
19. Cleanup-/All-Notes-Off-/Lifecycle-Strategie.
20. Computer-Keyboard DEFERRED mit Focus-Begruendung.
21. Realtime- und Performance-Entscheidung.
22. Fast-/Targeted-Tests je Konfiguration mit Namen und Resultaten.
23. Representative Plugin-/Audio-Smokes.
24. Vollstaendige Debug- und Release-CTest-Ergebnisse, Anzahl und Dauer.
25. Jeden 696-Corpus-Lauf mit Konfiguration, Root, 696/696, Peak/Tail/finite-
    Resultat und Grund; zusaetzliche Laeufe gesondert begruenden.
26. Standalone-Smoke, VST3 Factory/Bundle Check und State/Preset-Smokes.
27. Gefundene echte Debug-/Release-Artefakte und ausgelesene Versionen.
28. Compilerfehler-/Warning-Bilanz gegen Baseline.
29. Dokumentationsaenderungen.
30. End-HEAD und End-git-status einschliesslich weiterhin geschuetzter
    untracked Dateien.
31. JUCE unchanged, protected files unchanged, no install, no push.
32. Alle OPEN manuellen Checks exakt und ohne behauptete Abnahme.

===============================================================================
28. COMMIT RULES
===============================================================================

Unterscheide strikt:

A. Reconciliation-/Checkpoint-Commits

- nur abgeschlossene/validierte fruehere Projektarbeit;
- vor V0.12.75-Produktarbeit;
- ehrliche, inhaltsspezifische Nachricht;
- keine geschuetzten Dateien, keine Artifacts/build, kein V0.12.75-Code;
- bei offen deferiertem D96/64-Befund nicht "performance passed" behaupten.

B. V0.12.75-Milestone-Commit

- erst nach komplett bestandenem automatable DoD;
- explizite Pfade stagen, niemals pauschal alle untracked Dateien;
- staged Diff und staged file list vor Commit pruefen;
- geeignete Nachricht:
  DeepPluck V0.12.75 Standalone Virtual MIDI Keyboard
- Commit-Hash danach erfassen;
- kein Push.

Fuehre nach dem Commit erneut git status aus. Build-/Artifact-Dateien duerfen
nicht vorgemerkt sein. Geschuetzte untracked Dateien duerfen sichtbar bleiben.
Wenn ein automatischer Gate fehlschlaegt, erstelle keinen Milestone-Commit.

===============================================================================
29. FINAL HANDOFF FORMAT
===============================================================================

Berichte am Ende knapp, aber vollstaendig in dieser Reihenfolge:

1. Status: automatable-complete oder BLOCKED.
2. Reconciliation:
   - urspruenglicher HEAD;
   - Checkpoint-Commits;
   - V0.12.75-Start-HEAD;
   - D96/64-Behandlung.
3. Implementierung:
   - Standalone-Keyboard;
   - MIDI-Collector-/Cleanup-Architektur;
   - VST3-Nichtaenderung;
   - geaenderte Dokumentation.
4. Tests:
   - Fast/Targeted Debug und Release;
   - Representative Smokes;
   - volle Debug-/Release-Suite;
   - Corpus-Laeufe und 696/696-Ergebnisse;
   - Warnings.
5. Artefakte:
   - Debug/Release VST3 und Standalone;
   - lokale Kopien;
   - ausgelesene Version 0.12.75;
   - keine Systeminstallation.
6. Git:
   - Milestone-Commit-Hash;
   - Endstatus;
   - protected files/JUCE unchanged;
   - no push.
7. OPEN: vollstaendige verbleibende manuelle Standalone-, VST3-, Cubase-,
   Focus- und Hoercheckliste.

Bei BLOCKED nenne statt Erfolgsaussagen den exakten Blocker, die Evidenz und
die eine erforderliche naechste Benutzerentscheidung. Ein fehlgeschlagener
Test, offene manuelle Abnahme oder bekannter D96/64-Befund darf nie als PASS
kaschiert werden.

===============================================================================
END OF BINDING IMPLEMENTATION ORDER
===============================================================================
