===============================================================================
DEEPPLUCK / "JUST A LIL' PLUCKSYNTH"
V0.13.0 - RELEASE CANDIDATE
VERBINDLICHER IMPLEMENTIERUNGS-MASTERPROMPT - REVISION 1
===============================================================================

Repository:
D:\0A_VST_Development

Zielversion:
0.13.0

Erforderlicher späterer Implementierungsbericht:
D:\0A_VST_Development\Docs\
DeepPluck_V0.13.0_Release_Candidate_Implementation_Report.md

DOKUMENTGRENZE

Dieser Text ist die später direkt auszuführende Implementation Order. Bei seiner
Ausführung ist V0.13.0 vollständig umzusetzen, zu prüfen und zu dokumentieren.
Der Auftrag, mit dem diese Datei erstellt wurde, erlaubt ausdrücklich noch keine
Implementierung. Die Erstellung dieser Datei ist deshalb kein V0.13.0-Build,
kein Testlauf, keine Versionsänderung, kein Release und kein Git-Commit.

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

Arbeite ausschließlich im vorhandenen Repository und auf Basis des beim Start
tatsächlich vorhandenen legitimen Arbeitsstands. V0.13.0 ist ein
Release-Candidate-/Hardening-Milestone, kein Feature-Milestone.

Verbindlich:

1. Lies zuerst AGENTS.md und das Sound Manifest vollständig.
2. Lies anschließend alle Authoritative Inputs aus Abschnitt 1.
3. Führe vor jedem V0.13.0-Schreibzugriff das Initial Audit und das
   Pre-Milestone Reconciliation Gate aus.
4. Verwende den realen aktuellen Stand. Erzwinge keinen in diesem Dokument
   genannten historischen Commit.
5. Setze nichts zurück. Verwende weder reset, clean, checkout alter Dateien,
   Rebase noch Stash, um den Arbeitsstand zu vereinfachen.
6. Bewahre jede legitime neuere Arbeit.
7. Verändere, verschiebe, lösche, stage oder committe keine geschützte
   untracked/ignored Benutzerdatei.
8. Bearbeite niemals Dateien innerhalb JUCE/.
9. Verwende C++20 und die offizielle JUCE-9-CMake-API. Kein Projucer-Projekt.
10. Schütze den Audio-Thread: keine Allokation, Sperre, Datei-/Netzwerkzugriffe,
    GUI-Zugriffe, Logs oder String-/APVTS-Lookups im Hot Path.
11. Keine neue Abhängigkeit, Toolchain, Anwendung oder Systemkomponente
    installieren oder aktualisieren.
12. COPY_PLUGIN_AFTER_BUILD bleibt FALSE.
13. Kopiere oder installiere VST3/EXE nicht automatisch in System- oder
    Benutzer-Anwendungsordner. Nur projektlokale Artifacts sind zulässig.
14. Kein Push, Tag, Upload, Installer oder finaler V1.0-Release.
15. Keine Tests, Grenzwerte, Warnungsregeln oder Kompatibilitätsprüfungen
    entfernen, abschwächen oder umgehen.
16. Verwende während der Iteration Fast-/Targeted-Tests. Starte den vollständigen
    696-Fälle-Factory-Corpus nur nach den Regeln in Abschnitt 19.
17. Stelle keine Cubase-, Standalone-Geräte-, DPI-, Hör- oder sonstige manuelle
    Abnahme als bestanden dar, bevor der User sie tatsächlich bestätigt hat.
18. Stoppe nur bei einem echten externen Blocker, einem ungelösten
    Blocker/Major-Bug oder einer erforderlichen neuen Benutzerentscheidung.
    Dokumentiere dann konkrete Evidenz und die genau fehlende Entscheidung.

Erlaubte V0.13.0-Änderungen:

- nachgewiesene Bugfixes und Regression-Fixes;
- Sicherheits-, Stabilitäts- und Realtime-Fixes;
- klar begrenzte Performance-Regressionsfixes;
- kleine risikoarme GUI-, DPI-, Layout-, Text- und UX-Korrekturen;
- Test-, Validierungs-, Versions-, Artifact-, Packaging- und
  Dokumentationskorrekturen.

Nicht erlaubt:

- neue Features, Klangerweiterungen oder Produktkonzepte;
- spekulative Refactorings;
- eine neue Optimierungsrunde ohne belegtes RC-Problem;
- musikalische Neugestaltung der Factory Library.

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

Vor Planung und Implementierung vollständig lesen:

1. D:\0A_VST_Development\AGENTS.md
2. D:\0A_VST_Development\Docs\Sound\
   DeepPluck_Sound_Manifest_v1.0.md
3. diesen Masterprompt
4. README.md
5. ARCHITECTURE.md
6. CMakeLists.txt, CMake/FactoryContent.cmake, .gitignore und .gitattributes
7. die vollständige aktuelle Parameter- und State-Implementierung:
   - Source/Parameters/DeepPluckParameters.h/.cpp
   - Source/Parameters/DeepPluckParameterState.h/.cpp
8. die vollständige aktuelle Preset-/Factory-Implementierung:
   - Source/Presets/*
   - Presets/Factory/catalog.json
   - alle explizit katalogisierten Presets/Factory-Dateien
   - relevante Tools/Presets/*
9. Random-/Lock-/Undo-Implementierung:
   - Source/Randomization/*
   - zugehörige Processor-/Editor-Pfade
10. PluginProcessor, PluginEditor und sämtliche produktiven Source-Pfade,
    insbesondere Synth, Effects, Metering und GUI.
11. Standalone-spezifische Implementierung:
    - Source/GUI/DeepPluckStandaloneKeyboard.h/.cpp
    - Wrapper-/Holder-/Collector-Integration im Editor
12. alle aktuellen Tests und Hilfsprogramme:
    - Tests/TestMain.cpp
    - Tests/ToneVoicingAudit.cpp/.md
    - Tests/CPUProfilingBenchmark.md und Benchmark-Skripte
    - Tests/FactoryPresets.md und Factory-Skripte
    - Tests/StandaloneVirtualMidiKeyboard.md
    - Tests/SmokeStandalone.ps1
    - Tests/SmokeVST3Factory.ps1
    - Tests/VerifyGeneratedVersion.ps1
    - Tests/VerifyArtifacts.ps1
13. die vollständigen Masterprompts und Implementation Reports von:
    - V0.11.0 Parameter Range Review & Compatibility Freeze
    - V0.11.25 Tone & Voicing Refinement
    - V0.11.5 CPU Profiling & DSP Optimization
    - V0.12.0 Factory Presets
    - V0.12.5 Welcome / About / Final UX Polish
    - V0.12.75 Standalone Virtual MIDI Keyboard
14. Git-Historie und alle seit dem unten dokumentierten Snapshot hinzugekommenen
    legitimen Reports, Commits und Evidence-Verweise.

Konfliktpriorität:

1. ausdrückliche Anforderungen dieses V0.13.0-Auftrags;
2. AGENTS.md und der eingefrorene V0.11.0-Kompatibilitätsvertrag;
3. Sound Manifest;
4. tatsächliche neueste legitime Repository-Architektur;
5. frühere Dokumentation.

Das Sound Manifest ist für Produktfokus, Klang, DSP, GUI-Ruhe sowie
CPU-/Qualitätsentscheidungen normativ. In diesem RC legitimiert es keine neue
Klangarbeit. Bei einem Konflikt den realen Stand und die Grenzen prüfen.
Keine Regel umschreiben und keine neue Produktentscheidung selbst treffen.

===============================================================================
2. VERIFIED CREATION SNAPSHOT - PROVENIENZ, KEIN CHECKOUT-ZIEL
===============================================================================

Bei Erstellung dieses Masterprompts wurde am 2026-09-05 read-only festgestellt:

- Repository: D:\0A_VST_Development
- Branch: master
- HEAD: fedb8ac7665cc43e956fd15900b1199596699dbf
- HEAD-Betreff:
  DeepPluck V0.12.75 Standalone Virtual MIDI Keyboard
- Index: leer
- tracked Working Tree: unverändert
- nicht ignorierte untracked Einträge: 19
- darunter CubaseTest/, historische/user-supplied Masterprompts und
  Referenz-/Screenshot-PNGs unter Docs/
- JUCE/: kein Git-Diff
- build/ und Artifacts/: ignoriert
- project(... VERSION ...): 0.12.75
- CMake-Cache: Visual Studio 18 2026, x64, Projektversion 0.12.75
- COPY_PLUGIN_AFTER_BUILD: FALSE

Dieser neue V0.13.0-Masterprompt ist ein ausdrücklich angefordertes
Projekt-Dokument. Er darf beim späteren Milestone nur als V0.13.0-Dokument
behandelt werden. Alle anderen bereits vorhandenen untracked/ignored
Benutzerdateien bleiben geschützt.

Reale Toolchain bei Erstellung:

- Windows 11 x64
- Visual Studio Community 2026, Installation 18.9.2 / 18.9.12120.119
- Generator Visual Studio 18 2026
- x64 cl.exe:
  C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\
  14.51.36231\bin\Hostx64\x64\cl.exe
- MSVC 19.51.36256
- VCTools 14.51.36231
- Windows SDK 10.0.26100.0
- CMake 4.4.3
- JUCE 9.0.1
- C++20

Reale Produktbasis bei Erstellung:

- Product / Host Name: DeepPluck
- sichtbare Marke: Just A Lil' PluckSynth
- COMPANY_NAME im Build: ToneTrax
- sichtbarer Credit: Tonetrax
- Manufacturer Code: Tntx
- Plugin Code: DpV1
- Bundle ID: de.tonetrax.deeppluck
- VST3 Component CID:
  ABCDEF019182FAEB546E747844705631
- VST3 Controller CID:
  ABCDEF011234ABCD546E747844705631
- Instrument: kein Audio-Input, Stereo-Output, MIDI-Input, kein MIDI-Output
- genau 16 vorallokierte musikalische Stimmen
- globale Effekte nach der vollständigen Voice-Summe
- exakt 62 eingefrorene Host-Parameter, Index 0..61, Version Hint jeweils 1
- Host-State-Root: DeepPluckState
- Presetformat: JustALilPluckPreset, schemaVersion 1
- Packformat: JustALilPluckPack
- Random: 60 Soundparameter, zehn Module; Output und Master Tune ausgeschlossen
- ein Schritt Random Undo; Laufzeit-Locks sind nicht Teil des Host-State
- VST3-GUI: fest 1536 x 900, kein virtuelles Keyboard
- Standalone-GUI: fest 1536 x 980, Haupt-GUI 1536 x 900 plus
  Standalone-only Keyboard-Strip 80 Pixel
- Standalone-Keyboard: JUCE MidiKeyboardState/MidiKeyboardComponent,
  Channel 1, Start MIDI 36 (C2), Oct -/+ je 12 Halbtöne, Sichtbereich 0..60,
  Noten 0..127, kein Computer-/QWERTZ-Keyboard
- Welcome, Preferences, Settings und About sind vorhanden
- GUI-Preferences liegen außerhalb von APVTS/Host-State unter
  User Application Data/ToneTrax/DeepPluck/GUI.properties

Reale Factory-Basis bei Erstellung:

- Status des Katalogs: approved
- aktive Factory-Presets: exakt 116
- Kategorien und aktive Counts:
  - Deep Plucks: 14
  - Warm & Soft: 13
  - Bright & Present: 12
  - Emotional: 15
  - Atmospheric: 17
  - Arp & Sequence: 10
  - Chord & Poly: 19
  - Experimental: 16
- alle 116 aktiven Presets wurden vom User bereits angehört und freigegeben
- die früheren vier aktiven Presets sind im Browser ersetzt
- factory:0..3 bleiben mit ihren ursprünglichen Sounds ausschließlich als
  interne Legacy-Kompatibilitätsdaten ladbar
- User-/Pack-/Imported-Verhalten und Dateipreset-Identität bleiben vom
  selbstenthaltenen Host-State getrennt

Reale Testbasis bei Erstellung:

- 40 registrierte CTests pro Konfiguration:
  - evidence_paths
  - tone_voicing
  - factory_profiles
  - factory_files
  - factory_factory
  - factory_integration
  - factory_final_content
  - benchmark_manifest
  - benchmark_determinism
  - audio_equivalence
  - benchmark_quick
  - parameters
  - oscillator
  - envelope
  - filter
  - filter_envelope
  - transient_noise
  - transient_noise_integration
  - oscillator2
  - oscillator2_integration
  - unison
  - unison_integration
  - headroom
  - performance
  - synthesiser
  - sample_accuracy
  - matrix
  - gui
  - standalone_keyboard
  - smoothing_stability
  - modulation
  - modulation_integration
  - waveform
  - waveform_integration
  - effects
  - effects_integration
  - randomization
  - preset_files
  - preset_integration
  - artifact_version
- tone_voicing umfasst 669 Full-Processor-Fälle plus 42 Partition-Fälle.
- Der finale Factory-Audio-Corpus ist kein CTest. Er umfasst pro
  Konfiguration genau:
  116 Presets x 3 Sample Rates x dry/wet = 696 Fälle.
- Der Factory-Corpus verwendet die reale Preset-Audit-Engine, Full Scene,
  Buffer 128 sowie 44.1/48/96 kHz.
- V0.12.75 dokumentiert Debug 40/40 und Release 40/40 sowie je einen finalen
  696/696-Lauf.
- Native Standalone-Smokes, native VST3-Factory-Loads und
  Artifact-/Version-Checks bestehen für V0.12.75.

Bekannter historischer Performance-Befund:

- Die V0.11.5-Optimierung ist praktisch vom User bestätigt und in der
  gemeinsamen Baseline enthalten.
- Der formale harte D96/64-Deadline-Gate ist NICHT als bestanden dokumentiert.
- Eine Bestätigungsserie enthielt elf Candidate-Deadline-Misses.
- Eine spätere saubere 39-Fälle-Matrix und praktische Funktionsabnahmen heben
  diese Messung nicht rückwirkend auf.
- Der User hat am 2026-09-04 ausdrücklich erlaubt, diesen Befund als bekannte,
  dokumentierte technische Einschränkung zu deferieren und die gemeinsame
  V0.11.5-bis-V0.12.5-Baseline zu sichern, ohne Performance-PASS zu behaupten.
- V0.12.75 bewahrt diesen Status als OPEN/deferred.

Alle Snapshotangaben beim späteren Start neu prüfen. Neuere legitime Änderungen
werden übernommen und dokumentiert; der Snapshot ist keine Reset-Anweisung.

===============================================================================
3. INITIAL AUDIT
===============================================================================

Vor dem ersten V0.13.0-Schreibzugriff:

[ ] Repository-Pfad, Branch, vollständigen HEAD und HEAD-Betreff erfassen.
[ ] git status einschließlich staged, unstaged, untracked und relevanter
    ignored Dateien erfassen.
[ ] vollständigen tracked Diff lesen.
[ ] alle untracked Einträge klassifizieren: autorisierte Projektarbeit oder
    geschützte Benutzerdatei; im Zweifel geschützt.
[ ] geschützte Dateien mit Pfad, Größe und SHA-256 inventarisieren.
[ ] JUCE-Status und JUCE-Version prüfen.
[ ] build/ und Artifacts/ mit check-ignore prüfen.
[ ] COPY_PLUGIN_AFTER_BUILD prüfen.
[ ] Git-Historie seit fedb8ac7665cc43e956fd15900b1199596699dbf prüfen.
[ ] alle Authoritative Inputs vollständig lesen.
[ ] aktuelle zentrale Projektversion prüfen.
[ ] Plugin-/Host-Identität einschließlich realer VST3-Class-IDs prüfen.
[ ] Bus-, MIDI-, Voice- und Wrapper-Verträge prüfen.
[ ] vollständiges 62-Parameter-Istmanifest aus Code und Tests erfassen.
[ ] State-, Migration-, Preset-, Random-, Lock- und Undo-Verträge erfassen.
[ ] Factory-Katalog, alle 116 Dateien, Kategorien, Hashes und Approval-Metadaten
    prüfen.
[ ] User-/Pack-/Imported-Dateigrenzen und sichere Dateiverarbeitung prüfen.
[ ] aktuelle VST3-/Standalone-/Welcome-/Settings-/About-/Keyboard-Architektur
    prüfen.
[ ] alle registrierten CTests und externen Smokes/Corpora inventarisieren.
[ ] verfügbare gültige V0.12.75-Build-/Test-/Artifact-Evidence identifizieren.
[ ] D96/64-Historie und aktuellen Status ohne Umdeutung erfassen.
[ ] reale Toolchain gemäß Abschnitt 24 ermitteln.

Das Initial Audit ist read-only. Fehlende Dateien suchen, nicht erfinden.

===============================================================================
4. PRE-MILESTONE RECONCILIATION GATE
===============================================================================

Dieses Gate liegt vor jeder V0.13.0-Produkt-, Versions- oder Build-Systemänderung.

4.1 Wenn tracked und staged unverändert sind

Wenn der spätere Start weiterhin einen sauberen tracked Stand auf einem
legitimen V0.12.75- oder neueren Commit zeigt:

1. dokumentiere ursprünglichen Branch, HEAD und Status;
2. dokumentiere die geschützten untracked/ignored Dateien;
3. bestätige, dass kein Reconciliation-Commit nötig ist;
4. verwende diesen HEAD als V0.13.0 Start-HEAD.

4.2 Wenn tracked Änderungen vorhanden sind

Nicht resetten, stashen, verwerfen, überschreiben oder stillschweigend in
V0.13.0 aufnehmen.

1. Erfasse vollständigen Status und Diff.
2. Ordne jede Änderung zu:
   - V0.11.5;
   - V0.12.0;
   - V0.12.5;
   - V0.12.75;
   - andere legitime Arbeit;
   - unbekannt.
3. Prüfe anhand von Reports, Tests und Evidence, ob sie abgeschlossen und
   ausreichend validiert ist.
4. Abgeschlossene valide Alt-Arbeit darf mit expliziten Pfaden in separaten
   lokalen Reconciliation-/Checkpoint-Commits gesichert werden.
5. Diese Commits sind nicht der V0.13.0-RC-Commit.
6. Unvollständige Alt-Arbeit zuerst sauber abschließen; V0.13.0 noch nicht
   implementieren.
7. Bei unbekannter oder überlappender Benutzerarbeit nicht raten. Benenne den
   Konflikt und fordere die eine nötige Entscheidung an.

4.3 Reconciliation-Schutz

- Kein git add ., git add -A oder pauschales Staging.
- Vor jedem Commit staged Dateiliste und staged Diff prüfen.
- Keine geschützte Datei, build/, Artifacts/ oder JUCE-Datei aufnehmen.
- Den bekannten D96/64-Befund nicht als PASS umformulieren.
- Keine frühere Benutzerarbeit verlieren.

4.4 Abschluss

Nach Reconciliation erneut Status erfassen und einen eindeutigen
V0.13.0-Start-HEAD dokumentieren. Erst danach darf RC-Arbeit beginnen.

===============================================================================
5. RECONCILED RC BASELINE
===============================================================================

Erzeuge nach dem Reconciliation Gate eine maschinenlesbare und im Report
zusammengefasste RC-Baseline.

Mindestens:

- Branch und V0.13.0 Start-HEAD;
- Source-/Build-System-Inventar;
- geschützte Dateien und JUCE-Status;
- Toolchain;
- Projektversion;
- Host-Identität und Class-IDs;
- 62-Parameter-Manifest;
- State-/Preset-/Migration-Verträge;
- 116 Factory-Presets und acht Kategorien;
- GUI-/Wrapper-/Standalone-Keyboard-Vertrag;
- Testkatalog und externe Testwerkzeuge;
- aktuelle Artifact-Pfade und Versionen;
- bekannte offene Befunde.

Vorhandene V0.12.75-Evidence darf wiederverwendet werden, wenn Source-Stand,
Binaries, Konfiguration, Toolchain, Eingaben und Hashes eindeutig vergleichbar
sind. Historische Ergebnisse bleiben historische Baseline-Evidence und werden
nicht als neuer V0.13.0-Lauf ausgegeben.

Wenn der Startstand nicht ausreichend validiert ist, führe vor RC-Änderungen
eine proportionale Baseline aus. Kein vollständiger Corpus nur aus Gewohnheit.

===============================================================================
6. MILESTONE GOAL AND FEATURE FREEZE
===============================================================================

V0.13.0 ist der Release Candidate. Behandle den finalen Stand technisch so, als
könnte exakt dieser Commit Grundlage des separat zu spezifizierenden V1.0.0-
Final-Release-Milestones werden.

Ziele:

- Stabilität;
- Rückwärtskompatibilität;
- Regression-Hardening;
- Host-/Standalone-Sicherheit;
- Preset-/State-Sicherheit;
- GUI-/DPI-Hardening;
- Audio-/Realtime-Sicherheit;
- Performance-Regressionsprüfung;
- konsistente Versionen und Artifacts;
- saubere projektlokale Packaging-Vorbereitung;
- realitätsgetreue Dokumentation;
- letzte echte Bugs risikoarm beheben.

FEATURE FREEZE:

NO NEW FEATURES.

Neue Ideen als Post-V1.0-Ideen im Implementation Report notieren, sofern dies
hilfreich ist. Nicht implementieren. Eine umfangreiche Änderung ist ein Signal,
dass der Stand noch nicht RC-reif ist, und benötigt eine konkrete Begründung.

===============================================================================
7. HARD COMPATIBILITY CONTRACT
===============================================================================

Der V0.11.0 Compatibility Freeze ist vollständig bindend.

7.1 Parameter

Exakt 62 Host-Parameter, Index 0..61. Nicht ändern:

- Anzahl oder Reihenfolge;
- ID oder Wiederverwendung einer ID;
- Hostname;
- konkreter Parametertyp;
- Version Hint;
- Range, Intervall oder Choice-Reihenfolge;
- Default;
- Skew/Normalized Mapping;
- Raw Unit oder Raw Meaning;
- Text-/Parsersemantik;
- Automatisierbarkeit.

Keinen Parameter einfügen, anhängen, verbergen, aliasen oder entfernen.
Vergleiche maschinell jedes Feld gegen den eingefrorenen Vertrag und den
V0.13.0 Start-HEAD.

7.2 State, Automation und Presets

Unverändert bleiben:

- DeepPluckState/APVTS-Semantik;
- aktuelle Writer- und Reader-Semantik;
- Legacy-/Partial-State-Migration;
- Attack-Kanonisierung und alle sonstigen bestehenden Fallbacks;
- Automation und bestehende Host-Lanes;
- JustALilPluckPreset schemaVersion 1;
- JustALilPluckPack;
- vollständige 62-Wert-Presetsemantik;
- Factory/User/Pack/Imported-Kategorien;
- Host-Restore unabhängig von einer Presetdatei;
- factory:0..3-Legacy-Snapshots mit ursprünglicher Bedeutung;
- Random-Verteilungen, Amount, zehn Module, Locks und One-Step Undo.

Eine RC-Korrektur darf keine neue Migration erfinden. Wenn ein echter
Kompatibilitätsbug gefunden wird, minimal fixen, mit realen Vorher-/Nachher-
Fixtures absichern und vollständig dokumentieren.

7.3 Produktidentität

Unverändert:

- Product / Host Name: DeepPluck
- Manufacturer Code: Tntx
- Plugin Code: DpV1
- Bundle ID: de.tonetrax.deeppluck
- vorhandene VST3 Component-/Controller-Class-IDs
- kein Audio-Input, Stereo-Output, MIDI-Input, kein MIDI-Output
- VST3 und Standalone
- genau 16 Stimmen

Keine Umbenennung und keine neue Plugin-Identität für den RC.

===============================================================================
8. RC PRODUCT AUDIT
===============================================================================

Erstelle vor Änderungen eine vollständige read-only Produktinventur und wiederhole
die betroffenen Teile am finalen Stand.

Mindestens erfassen:

- Version und zentrale Versionsquelle;
- Host-/Bundle-/Class-Identität;
- Bus- und MIDI-Konfiguration;
- Voice-Anzahl und Voice-Stealing;
- Synth-/Filter-/Envelope-/Transient-/Noise-/Unison-/LFO-Kern;
- globales FX-Rack und alle sechs Orders;
- Parameterzahl und Attachments;
- State, Migration und Automation;
- Factory/User/Pack/Imported-Presets;
- aktive Factory-Anzahl, Kategorien und Legacy-Kompatibilität;
- Random, Amount, Locks und Undo;
- Preset-Navigation, Refresh, Save, Save As, Delete und Folder;
- GUI-Tabs MAIN, MODULATION, FX und SETTINGS;
- Welcome, Preferences und About;
- Hover Help, Focus und Tooltips;
- Output Meter, Envelope- und Waveform-Displays;
- VST3-/Standalone-Größen und Wrapper-Abgrenzung;
- Standalone Virtual Keyboard;
- aktuelle CTests, Smokes, Corpora und Benchmark-Suites;
- Versionierungs-, Artifact- und lokale Kopierprüfungen.

Keine bestehende Funktion allein wegen fehlender Dokumentation entfernen.

===============================================================================
9. RC BUG POLICY
===============================================================================

Jeden gefundenen Fehler vor seiner Behebung reproduzieren und klassifizieren.

Severity A - Blocker:

- Crash oder Hang;
- korrupter/nicht restaurierbarer State;
- hängende Noten;
- fehlendes Audio;
- NaN/Inf oder schwere DSP-Instabilität;
- ungültige/falsch versionierte Artifacts;
- nicht ladbare aktive Factory-Presets;
- gebrochene Host-Identität oder Parameterkompatibilität.

Muss vor RC-Abschluss behoben werden.

Severity B - Major:

- klarer Funktionsfehler;
- defektes Control;
- relevante Host-Inkompatibilität;
- erheblicher GUI-/DPI-/Standalone-Fehler;
- reproduzierbare relevante Performance-Regression;
- erheblicher Preset-/Workflow-Fehler.

Soll vor RC-Abschluss behoben werden. Bleibt er offen, ist der technische
Readiness-Status NOT READY.

Severity C - Minor:

- kleiner Abstand;
- kosmetische Unschärfe;
- unkritischer Textfehler.

Nur beheben, wenn Änderung klein, lokal, sicher und durch zielgerichtete Prüfung
abgedeckt ist. Keine riskante Architekturarbeit wegen eines Minor Issues.

Für jeden Fix dokumentieren:

- Reproduktion und Severity;
- betroffene Verträge;
- kleinste sichere Änderung;
- relevante Fast Tests;
- ob Audio/DSP betroffen ist und welcher Final-Gate-Umfang dadurch nötig wird.

===============================================================================
10. DAW / HOST HARDENING
===============================================================================

Automatisiere mit vorhandener Architektur, soweit hardware- und hostfrei sinnvoll:

- wiederholte Processor-Erzeugung und -Zerstörung;
- Prepare/Release/Prepare in mehreren Zyklen;
- mehrere unabhängige Instanzen;
- State Save/Restore und wiederholter Roundtrip;
- Legacy-/Partial-State-Load;
- Preset Load und Wechsel;
- Parameterautomation mit schnellen, legalen Änderungen;
- MIDI Note On/Off, Retrigger und harte Stops;
- 16 Stimmen und 17. Note für Voice-Stealing;
- Reset und Tail-Ende;
- 44.1/48/96 kHz;
- repräsentative Buffer 64/128/256/512;
- finite Ausgabe und begrenzte Peaks.

Keinen künstlichen Test-Host bauen, wenn vorhandene Processor-/VST3-/Standalone-
Smokes dieselbe Grenze ausreichend prüfen. Kein externer DAW-Download.

Native VST3-Prüfung:

- vorhandenen Bundle-/Artifact-Vertrag vollständig prüfen;
- reale x64 VST3-Binary laden;
- InitDll/GetPluginFactory/countClasses/release/ExitDll/FreeLibrary prüfen;
- genau die erwarteten zwei Klassen und unveränderte Class-IDs prüfen;
- wiederholtes Load/Unload risikoarm ergänzen, falls nicht bereits abgedeckt;
- dies nicht als vollständigen Cubase- oder offiziellen Steinberg-Validator-PASS
  darstellen.

Cubase bleibt primäre manuelle Host-Abnahme gemäß Abschnitt 29.

===============================================================================
11. PRESET / STATE / MIGRATION HARDENING
===============================================================================

Prüfe mindestens:

- alle 116 aktiven Factory-Presets;
- factory:0..3-Kompatibilitätsrestore;
- User Presets;
- Pack Presets;
- Imported-Kategorie;
- Preset-Navigation vor/zurück;
- Refresh;
- Save;
- Save As;
- Delete-Regeln und Schutz nicht löschbarer Quellen;
- Open Preset Folder;
- Category Handling;
- sichere Namen, Pfade, Dateigrößen und Traversal-Abwehr;
- transaktionales Parsing ohne teilweise Anwendung;
- State Roundtrip;
- alte kompatible State-/Preset-Prefixe;
- V0.12.x-State/Preset-Load;
- Random nach Preset Load;
- Locks nach Preset Load;
- Undo nach Random;
- Amount 0 und repräsentative Zwischen-/Maximalwerte;
- FX Order;
- Presetdatei-Unabhängigkeit des Host-State.

Preset-Scanning, Parsing, Speichern, Löschen und Ordnerzugriffe bleiben außerhalb
jedes Audio-Callbacks.

Keine Preset-Migration stillschweigend ändern. Keine Factory-Sounds neu gestalten.
Ein technisch defektes aktives Factory-Preset darf nur gezielt, minimal und mit
neuer ausdrücklicher User-Autorisierung für den geänderten Sound/Hash ersetzt
werden. Ohne diese Freigabe den Fehler als Blocker melden.

===============================================================================
12. FACTORY LIBRARY RC CHECK
===============================================================================

Der reale V0.13.0-Ausgangspunkt enthält nicht 48, sondern 116 vom User
freigegebene aktive Factory-Presets. Der frühere 48-/sechs-pro-Kategorie-Plan ist
überholt und darf nicht wiederhergestellt werden.

Verbindlich prüfen:

- exakt 116 aktive Einträge;
- exakt acht Kategorien mit Counts 14/13/12/15/17/10/19/16 in der in
  Abschnitt 2 genannten Reihenfolge;
- eindeutige stabile IDs und Namen;
- exakt katalogisierte sichere relative Pfade;
- jede Datei vorhanden;
- Dateihash entspricht Kataloghash und Approval-Hash;
- status approved, decision approved, approver user;
- keine Candidate-, User-, Pack-, Benchmark- oder sonstige Datei eingebettet;
- alle 62 Werte gültig und kanonisch;
- alle technisch ladbar;
- Browser zeigt 116, nicht 120;
- die vier Legacy-IDs bleiben unsichtbare Kompatibilitätsdaten mit unverändertem
  ursprünglichem Klang;
- Factory-Inhalt wird nicht durch globbing bestimmt.

Der bereits dokumentierte Satz ist für den unveränderten 116er-Bestand wahr:

"Every active Factory preset was manually auditioned and approved by the user."

Wenn irgendein Preset in V0.13.0 klanglich verändert wird, gilt diese Freigabe
für die geänderte Datei nicht automatisch. Ohne neue echte User-Abnahme bleibt
sie OPEN und der alte Approval-Hash darf nicht weiterverwendet werden.

===============================================================================
13. GUI / DPI / UX HARDENING
===============================================================================

Keine neue GUI, kein Responsive Framework und kein Resizing-System bauen.
Die bestehenden festen Größen bleiben, sofern kein realer lokaler RC-Bug eine
kleine Korrektur verlangt.

VST3 und Standalone getrennt prüfen:

- abgeschnittene oder überlappende Controls/Texte;
- Header, Preset-Bereich, Tabs und Footer;
- MAIN, MODULATION, FX und SETTINGS;
- About und Credits;
- exakte Website www.tonetrax-music.de;
- Welcome-Overlay und dessen Lifecycle;
- Preferences und gespeicherte sichere Defaults;
- Hover Help und Tooltips;
- Focus-Reihenfolge und sichtbarer Focus;
- Disabled States;
- Kontrast und Lesbarkeit;
- Random-/Lock-/Undo-Icons;
- Output Meter mit -60 bis +6 dB-Skala;
- Envelope- und Waveform-Displays;
- FX-Rack und FX-Order-Bedienung;
- Standalone Keyboard, Tasten und Octave Controls;
- Versionsanzeige aus der zentralen Version.

DPI-/Windows-Scaling:

- vorhandene reale Scaling-Unterstützung zuerst feststellen;
- Layout-Assertions und vorhandene Snapshots für sichere Regressionen verwenden;
- reale Prüfung bei Windows 100 %, 125 % und 150 % als manuell markieren;
- keine sichtbare Prüfung aus einem Headless-/Snapshot-Test erfinden;
- keine bislang bewusst feste Fenstergröße als resizable ausgeben.

Website-Tests dürfen URL und Control prüfen, aber keinen Browser automatisch
öffnen. Kein Netzwerkzugriff, Prefetch, Telemetrie oder Tracking.

===============================================================================
14. STANDALONE RC CHECK
===============================================================================

Der bestehende Standalone-only-Vertrag bleibt:

- Standalone Editor 1536 x 980;
- unveränderte Haupt-GUI in 0,0,1536,900;
- Keyboard-Strip in 0,900,1536,80;
- VST3 exakt 1536 x 900 ohne Keyboard und ohne reservierte Zusatzfläche;
- Erkennung nur über audioProcessor.wrapperType;
- StandalonePluginHolder gehört zum selben Processor;
- virtuelle und externe MIDI-Ereignisse treffen sich im bestehenden
  MidiMessageCollector;
- DeepPlucks processBlock erhält keine zweite GUI-MIDI-Queue;
- Channel 1, Noten 0..127, Start MIDI 36, sichtbarer Clamp 0..60;
- Oct -/+ ändern nur den sichtbaren Bereich um 12;
- keine Persistenz in APVTS/Presets/Automation;
- kein Computer-/QWERTZ-Keyboard;
- Cleanup sendet State-owned Note-Offs vor Listener-Detach;
- Welcome-Freigabe verhindert versteckte gehaltene virtuelle Noten;
- releaseResources bleibt harter finaler Device-/Shutdown-Reset.

Automatisiert prüfen:

- Wrapper-Erkennung und Größen;
- Panel nur in Standalone;
- Note On/Off, Drag-artige Reihenfolge, schnelle Retrigger, Akkord;
- Octave-Clamps;
- externer und virtueller MIDI-Pfad gleichzeitig;
- Same-Note-Semantik;
- idempotenter Cleanup;
- Zerstörung während/kurz nach gehaltenen Noten;
- 16 Stimmen und Voice-Stealing;
- unbenutztes Keyboard verändert State und Audio nicht;
- keine neue Idle-/Audio-CPU-Arbeit.

Native Standalone-Smoke:

- richtige EXE und Version;
- Prozessstart;
- exaktes eigenes Hauptfenster;
- plausible Client-/Editorgröße;
- GUI input-idle;
- normaler Close;
- Exit 0;
- kein Force-Kill und kein verbleibender eigener Prozess.

Audio Device Setup, echte Geräte, externe Hardware und subjektive Bedienung
bleiben manuell.

===============================================================================
15. AUDIO STABILITY
===============================================================================

Prüfe mit vorhandenen produktiven Klassen:

- keine NaNs oder Infs;
- keine ungeklärten Floating-Point-Ausnahmen;
- keine Denormal-Probleme im realen Pfad;
- keine hängenden Stimmen;
- kein unendlicher FX-Tail;
- sichere Reset-/Prepare-/Release-Zyklen;
- Voice-Stealing;
- schnelle Automation;
- Filter bei Cutoff-/Resonance-/Drive-Grenzen;
- Resonanzkompensation bleibt begrenzt und maskiert keine Instabilität;
- LFO Free/Sync, Restart und Ziele;
- Unison 1..4, Detune und Spread;
- Osc2 Bypass/Level/Tuning/Waveforms;
- Transient und Noise;
- alle FX einzeln und gemeinsam;
- sechs FX Orders;
- Delay/Reverb-Tails;
- normale und ausdrücklich als Stress markierte Headroom-Fälle;
- 44.1/48/96 kHz und Buffer 64/128/256/512.

Keine neue Audio-Engine-Arbeit. Nur reproduzierte Bugs minimal beheben.
Kein Limiter, Clipper, Auto-Gain oder heimliches Absenken, um einen Test zu
bestehen. Vorbestehende extreme Rohpeaks nicht als neue Regression ausgeben,
aber reale neue Peaks nicht verschweigen.

Wenn nach Start-Baseline produktiver Audio-/DSP-Code geändert wird:

- unveränderte authentische Vorher-Referenz sichern;
- feste identische MIDI-/Parameter-/State-Eingaben verwenden;
- Raw-Audio nicht normalisieren;
- relevante bitexakte oder vorab definierte numerische Vergleiche ausführen;
- vollständigen finalen Audio-Gate-Umfang entsprechend Abschnitt 19 auslösen.

===============================================================================
16. PERFORMANCE REGRESSION AND HISTORICAL D96/64 POLICY
===============================================================================

V0.11.5 ist die Performance-Referenz. V0.13.0 startet keine neue umfassende
Optimierungsrunde.

16.1 Normale RC-Prüfung

Verwende die vorhandene repräsentative Benchmark-Suite. Behalte genügend
unabhängige Fälle, um getrennt zu beurteilen:

- Polyphonie 1/4/8/16;
- Unison 1/2/4;
- Buffer 64/128/256/512;
- 44.1/48/96 kHz;
- FX Off/Chorus/Delay/Reverb/All;
- Typical DeepPluck;
- Dense Chord;
- vorab definierter Worst Case;
- mehrere Instanzen soweit mit kleinem reproduzierbarem Smoke sinnvoll;
- Standalone Keyboard unbenutzt.

Nutze kurze Warm-up- und Messfenster für RC-Smokes. Profile nur Typical, Dense
und Worst, und nur wenn ein aktueller reproduzierbarer Verdacht die Profile
fachlich nötig macht. Keine vollständige kartesische Monster-Matrix.

Vergleiche V0.13.0 gegen den eindeutig gesicherten V0.13.0 Startstand mit
gleichen Binaries/Quellen, Eingaben, Reihenfolge, Umgebung und Statistik.
Compiler-, FP-, ISA-, Prioritäts-, Affinitäts- oder Energieeinstellungen nicht
ändern, um Zahlen zu verbessern.

Wenn kein aktuelles Problem oder keine Regression vorliegt: nichts optimieren.
Nur klar belegte, isolierte Regressionen beheben. Jede Änderung benötigt
Audio-/State-Äquivalenz und zweimalige repräsentative Bestätigung.

16.2 D96/64-Wahrheitspflicht

Der historische harte 96-kHz-/64-Sample-Deadline-Befund bleibt OPEN/deferred,
bis eine dafür geeignete, vorab definierte Evidenz ihn wirklich klärt.

Verboten:

- spätere günstige Läufe als rückwirkendes Löschen der elf Misses ausgeben;
- Ausreißer ohne Kausalnachweis Windows/Scheduler/Treiber zuschreiben;
- Median-Verbesserung als harten Deadline-PASS ausgeben;
- Grenzwerte lockern, Messungen entfernen oder beliebig oft wiederholen;
- die praktische User-Funktionsabnahme in Performance-PASS umdeuten.

Für V0.13.0:

1. Übernimm den historischen Befund und die dokumentierte Defer-Autorisierung.
2. Prüfe mit einem vorab festgelegten, begrenzten repräsentativen Lauf, ob
   V0.13.0 gegenüber dem V0.13.0 Startstand eine neue relevante
   Performance-Regression einführt.
3. Wenn produktiver DSP unverändert ist und der Vergleich keine neue Regression
   zeigt, darf der RC technisch als "keine neue Performance-Regression"
   bewertet werden. Das ist weiterhin kein D96/64-PASS.
4. Wenn der alte Deadline-Befund reproduzierbar bleibt, führe ihn als bekannte
   technische Einschränkung. Für die endgültige Aussage
   READY FOR V1.0 RELEASE PREPARATION ist eine ausdrückliche Userentscheidung
   nötig, dass dieser bereits bekannte, unverändert offene Release-Risikobefund
   akzeptiert wird, oder eine echte technische Klärung/Fix-Evidence.
5. Ohne diese Entscheidung oder Klärung darf das automatable RC-Hardening
   ansonsten vollständig sein, die Readiness-Aussage muss jedoch
   NOT READY FOR V1.0 RELEASE PREPARATION lauten.
6. Zeigt V0.13.0 eine neue relevante Regression oder neue Deadline-Verletzungen,
   klassifiziere und behebe sie gemäß RC Bug Policy; andernfalls NOT READY.

Ein echtes fehlendes Profilingrecht oder nicht verfügbares externes Hostgerät
ist getrennt als Umgebungs-/Manual-Limit zu dokumentieren, nicht als
nachgewiesene DSP-Ursache.

===============================================================================
17. THREE-LEVEL TEST STRATEGY
===============================================================================

17.A FAST / TARGETED

Nach jedem kleinen Fix nur die relevanten vorhandenen oder eng ergänzten Tests.

Beispiele:

- Parameter/State-Fix:
  parameters, preset_files, preset_integration, audio_equivalence
- Factory/Preset-Fix:
  factory_*, factory_final_content, preset_files, preset_integration
- Random/Lock/Undo-Fix:
  randomization, preset_integration
- Processor/MIDI/Voice-Fix:
  synthesiser, sample_accuracy, matrix, standalone_keyboard
- Oscillator/Unison/LFO-Fix:
  oscillator, oscillator2, unison, modulation und Integration-Suites
- Filter/Envelope/Headroom-Fix:
  filter, filter_envelope, envelope, smoothing_stability, headroom
- FX-Fix:
  effects, effects_integration, preset_integration
- GUI/About/DPI-Fix:
  gui und gezielte Snapshot-/Bounds-Prüfung
- Standalone-Keyboard-Fix:
  standalone_keyboard plus native Standalone-Smoke
- Version/Artifact/Packaging-Fix:
  evidence_paths, generated-version, artifact_version,
  native VST3-/Standalone-Smokes
- Dokumentation:
  nur relevante statische Konsistenzchecks; kein Audio-Corpus

Keine bloße Testkopie der Implementierung. Tests müssen Produktverträge an
realen Integrationsgrenzen prüfen.

17.B REPRESENTATIVE RC SMOKE

Nach größeren Integrationsschritten:

- VST3 native load/unload;
- Standalone launch/normal close;
- Processor prepare/release/prepare;
- MIDI Note On/Off und Voice-Stealing;
- Preset Load;
- State Roundtrip;
- Random/Lock/Undo;
- finite representative audio render;
- FX off/on und Tail;
- kleine Sample-Rate-/Buffer-Auswahl;
- CPU quick;
- GUI/Welcome/About/Keyboard-Smoke;
- Artifact-/Version-Smoke.

17.C FULL RELEASE-CANDIDATE GATE

Erst wenn Source, Buildsystem, Tests und Dokumentation für den RC eingefroren
sind, Abschnitt 21 vollständig ausführen.

===============================================================================
18. FAST AND REPRESENTATIVE TEST DESIGN
===============================================================================

Ergänze Tests nur für tatsächlich gefundene Lücken oder Bugs. Keine Tests allein
für eine höhere Testzahl.

Wenn neue RC-Tests nötig sind:

- deterministisch;
- hardwarefrei, soweit die Produktgrenze dies erlaubt;
- ohne reale User-Preferences oder User-Preset-Ordner;
- alle Testdateien ausschließlich unter build/TestData oder erlaubtem
  Artifacts/V0.13.0-Evidence-Root;
- finite/raw Werte prüfen;
- negative Fälle und Cleanup prüfen;
- keine Änderung von Produktionscode nur zur Umgehung eines Tests;
- keine Netzwerk-/Systeminstallation;
- kurze Timeouts und klare Exitcodes;
- bestehende Testnamen/-semantik bewahren.

Sample-Rate-/Buffer-RC-Matrix:

- 44.1, 48 und 96 kHz;
- Buffer 64, 128, 256 und 512;
- keine pauschale vollständige Kreuzung jedes Presets, jeder Stimme, jedes FX
  und jeder Automation;
- getrennte, repräsentative Fälle, die jede Skalierungsdimension abdecken.

===============================================================================
19. FULL 696-CASE FACTORY AUDIO GATE
===============================================================================

Der große aktuelle Corpus ist exakt zu identifizieren als:

- Tool/Workflow: RunFactoryFinalContentAudit.ps1 mit der realen
  DeepPluckPresetAudit-Engine;
- 116 user-approved aktive Factory-Presets;
- 44.1, 48 und 96 kHz;
- dry und wet;
- Full Scene;
- Buffer 128;
- 116 x 3 x 2 = 696 Fälle pro Konfiguration;
- getrennte finale Debug- und Release-Ausführung.

Er ist NICHT identisch mit:

- den 669 Tone-Voicing-Full-Processor-Fällen;
- den 42 Tone-Voicing-Partition-Fällen;
- dem historischen 7.920-Fälle-CPU-Inventar;
- der aktuellen repräsentativen 39-Fälle-CPU-Suite;
- den 40 CTests.

Laufregel:

1. Nicht nach kleinen RC-Fixes, About-Text, Credits, Dokumentation,
   risikoarmen Layout-/DPI-Fixes oder Packaging-Text ausführen.
2. Genau einmal pro Konfiguration am finalen akzeptierten RC-Quellstand:
   Debug 696/696 und Release 696/696.
3. Zusätzlich nur:
   - nach unvollständigem/fehlgeschlagenem Corpus-Lauf; oder
   - nach einer späteren produktionsrelevanten Audio-/DSP-/Preset-Content-
     Änderung.
4. Jeder zusätzliche Lauf erhält eigenen Evidence-Root und dokumentierten Grund.
5. Ergebnisse nicht überschreiben oder aus Teilresultaten erfinden.
6. Alle 696 erwarteten eindeutigen Cases, native Exitcodes, Input-/Preset-
   Hashes, finite Ausgabe, Peak-Gate und ruhige Tails prüfen.
7. Kein Normalisieren, Limiting, Clipping oder Output-Absenken zur
   Ergebnisverbesserung.

===============================================================================
20. STATIC / REALTIME CODE REVIEW
===============================================================================

Führe vor finaler RC-Freigabe einen fokussierten Code-Review durch:

- DeepPluckAudioProcessor::processBlock;
- einmalige validierte Parametersnapshot-Erfassung pro Block;
- gebundene APVTS-Raw-Pointer;
- DeepPluckSynthesiser Event-Partitionierung;
- Voice-Renderloop und Voice-Stealing;
- Oscillator-/Unison-/Envelope-/Filter-/Transient-/Noise-/LFO-Loops;
- globales FX-Rack nach der Voice-Summe;
- Output Gain und Metering;
- Standalone Virtual-MIDI-Collector-Pfad;
- State-/Preset-/Factory-/Preference-Code außerhalb Audio-Thread;
- Prepare/Reset/Release/Lifecycle.

Im Audio-Callback verboten:

- Mutex oder blockierende Sperre;
- Heapallokation;
- dynamisches Containerwachstum;
- Datei-, Netzwerk- oder Preference-Zugriff;
- GUI-Aufruf;
- Logging;
- vermeidbare Stringarbeit;
- APVTS-ID-Suche;
- Preset-Parsing oder Scanning.

Keine großflächigen Stil-Refactorings. Ein statischer Review ist kein
Performance- oder Host-PASS; Befunde mit Tests oder klarer Code-Evidenz belegen.

===============================================================================
21. FINAL AUTOMATED RC GATE
===============================================================================

Am eingefrorenen finalen V0.13.0-Quellstand und in bestätigter Toolchain:

1. Frisch konfigurieren:

   cmake --fresh -S . -B build -G "Visual Studio 18 2026" -A x64

2. Debug:

   cmake --build build --config Debug --parallel
   ctest --test-dir build -C Debug --output-on-failure

3. Release:

   cmake --build build --config Release --parallel
   ctest --test-dir build -C Release --output-on-failure

4. Zusätzlich ausführen und belegen:

- alle Fast-/Targeted-Tests in beiden relevanten Konfigurationen;
- vollständige registrierte Debug-CTest-Suite;
- vollständige registrierte Release-CTest-Suite;
- finaler Debug Factory-Corpus 696/696;
- finaler Release Factory-Corpus 696/696;
- Parameter-Manifest- und Attachment-Vertrag;
- State Roundtrip und Legacy-/Partial-Migration;
- Preset Roundtrip, Factory/User/Pack/Imported;
- Random/Amount/Lock/Undo;
- FX Order;
- Voice-Stealing, Reset und Sample Accuracy;
- finite output, NaN/Inf und Headroom/Stability;
- Sample-Rate-/Buffer-Smokes;
- repräsentativer Performance-Vergleich;
- Standalone-Keyboard-Suite;
- Debug und Release Standalone native Process-Smoke;
- Debug und Release native VST3 Factory/Bundle Load;
- Generated-Version-Check;
- Artifact-Version-Check einschließlich negativer stale/missing/wrong-class-
  Proben;
- Windows VERSIONINFO;
- projektlokale Artifact-Kopien und Byteidentität;
- Packaging-Allowlist und Ausschlussprüfung;
- komplette Buildlogs auf Compiler-/Linker-/Build-Warnungen.

Finale Anforderungen:

- keine Compilerfehler;
- keine neuen Compilerwarnungen;
- Tests nicht abgeschwächt;
- keine neue relevante CPU-Regression;
- keine NaNs/Infs oder reproduzierbare DSP-Instabilität;
- kein Blocker/Major-Bug offen;
- keine Systeminstallation;
- COPY_PLUGIN_AFTER_BUILD FALSE;
- build/ und Artifacts/ ignoriert und unstaged;
- JUCE/ unverändert;
- geschützte User-Dateien unverändert und unstaged;
- kein Push.

Die erwartete Ausgangsanzahl beträgt 40 CTests pro Konfiguration. Wenn durch
legitime RC-Regressionstests mehr registriert werden, im Report die tatsächliche
Anzahl und jeden neuen Test nennen. Niemals eine niedrigere Zahl still als
vollständige Suite ausgeben.

===============================================================================
22. AUDIO REFERENCE AND TEST REUSE POLICY
===============================================================================

Vorhandene Ergebnisse behalten und wiederverwenden, soweit sie gültig,
vollständig, unverändert und vergleichbar sind.

Gültige Wiederverwendung verlangt:

- identischen relevanten Source-Stand;
- identische produktive Binary oder nachgewiesene bit-/audioäquivalente Basis;
- gleiche Konfiguration, Toolchain und Inputs;
- vollständige Receipts/Hashes;
- unveränderte Testsemantik und Grenzwerte.

Unvollständige Einzelmessungen dürfen neu gestartet werden. Alte Ausgaben nicht
überschreiben. Jeden Neustart begründen.

Für das V0.13.0-Final-Gate müssen neue finale Builds, CTests, Artifacts und die
beiden 696-Läufe auf dem finalen Stand erzeugt werden. Historische V0.12.75-
Ergebnisse sind Baseline, kein Ersatz für den finalen RC-Nachweis.

Nach ausschließlich nachgelagerten Dokumentationsänderungen muss ein bereits auf
dem finalen Produktcode bestandener 696-Lauf nicht wiederholt werden. Source-/
Build-/Teständerungen nach dem Lauf fachlich bewerten und den Grund dokumentieren.

===============================================================================
23. VERSION / ARTIFACT CONTRACT
===============================================================================

Setze project(DeepPluck VERSION 0.13.0 LANGUAGES C CXX) als einzige autoritative
aktuelle Versionsquelle. Keine zweite manuelle Versionskonstante.

0.13.0 muss konsistent und aus realen Ausgaben nachweisbar erscheinen in:

- CMake PROJECT_VERSION;
- JUCE Target-Version;
- VST3 Bundle und beiden VST3-Klassen;
- Debug Standalone;
- Release Standalone;
- generated JUCE-Makros;
- Windows FileVersion/ProductVersion;
- allen versionierten Test-/Tool-Targets;
- About;
- Footer;
- projektlokalen Debug-/Release-Kopien;
- Implementation Report.

Stale, fehlende, falsch konfigurierte oder unterschiedlich versionierte
Artifacts blockieren die Acceptance.

Physisch prüfen:

- Debug VST3 Bundle;
- Debug Standalone EXE;
- Release VST3 Bundle;
- Release Standalone EXE;
- Artifacts/Debug und Artifacts/Release;
- vollständige Bundle-Mitglieder;
- Byteidentität von Build-Ausgabe und lokaler Kopie;
- native x64;
- Produkt-/Host-Identität und Class-IDs.

Evidence-Skripte dürfen nur eng um Artifacts/V0.13.0 erweitert werden.
Bestehende V0.12.0-/V0.12.5-/V0.12.75-Evidence-Pfade nicht beschädigen.
Pfad-Escapes und beliebige externe Roots weiter ablehnen.

===============================================================================
24. TOOLCHAIN / BUILD CONTRACT
===============================================================================

Bestätigte Referenz:

- Windows 11 x64
- Visual Studio Community 2026 18.9.2
- Visual Studio 18 2026 Generator
- MSVC 19.51.36256
- 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. installierte bestätigte Visual-Studio-2026-Instanz mit vorhandener Discovery
   lokalisieren;
2. deren x64 MSVC Developer Environment initialisieren;
3. where cl prüfen und Pfad dokumentieren;
4. cl ausführen und Compilerbanner dokumentieren;
5. VCToolsVersion prüfen;
6. WindowsSDKVersion prüfen;
7. cmake --version prüfen;
8. Verfügbarkeit des Generators Visual Studio 18 2026 prüfen;
9. CMAKE_GENERATOR/CMAKE_GENERATOR_PLATFORM und vorhandene relevante Cache-
   Einstellungen konsistent behandeln;
10. erst danach cmake --fresh ausführen.

Nicht Generator, Compiler, Toolset oder SDK wechseln, weil eine normale Shell
cl nicht findet. Visual Studio 2022 ist nicht die Referenz und wird nicht
installiert. Andere Toolchains gelten als ungetestet.

Erfasse native Exitcodes, vollständige Logs, Laufzeiten und Warnungsanzahl.
Ein Sandbox-/FileTracker-Zugriffsfehler vor Compilation ist getrennt von einem
Compilerfehler zu dokumentieren und in derselben bestätigten Toolchain sauber
neu auszuführen, sofern der erforderliche Zugriff autorisiert ist.

===============================================================================
25. RELEASE PACKAGING PREPARATION
===============================================================================

Bereite ausschließlich projektlokal eine Release-Candidate-Struktur unter einem
eindeutigen ignorierten Unterpfad von Artifacts/V0.13.0 vor.

Verwende eine explizite Allowlist. Zulässige Endnutzerkandidaten:

- Release DeepPluck.vst3 als vollständiges Bundle;
- Release DeepPluck Standalone EXE;
- tatsächlich vorhandene endnutzerrelevante README-/Installations-/Lizenztexte,
  sofern sie geprüft und für Distribution bestimmt sind.

Nicht aufnehmen:

- build/;
- Debug-Binaries;
- Preset Candidates oder Audition-Daten;
- Benchmark-CSV/JSON;
- Profiler-Traces, ETL oder PDBs;
- Developer Tools und Testprogramme;
- Testdaten, Referenz-Audio oder Fixtures;
- Logs und Evidence;
- private/absolute Pfade;
- Cubase-Projekte;
- untracked Benutzerdateien;
- Source-Dumps;
- temporäre Dateien;
- Git-Metadaten;
- Installer oder Updater.

Erzeuge ein maschinenlesbares Packaging-Manifest mit relativen Pfaden, Größen
und SHA-256. Prüfe, dass alles innerhalb des erlaubten Projekt-Artifact-Roots
liegt und nur Release-Dateien enthält.

Keine Signierung behaupten, sofern sie nicht ausdrücklich autorisiert und real
ausgeführt wurde. Kein Installer, keine Systemkopie und kein Upload.

===============================================================================
26. END-USER AND PROJECT DOCUMENTATION
===============================================================================

Aktualisiere gemeinsam mit der Implementierung mindestens:

- README.md;
- ARCHITECTURE.md;
- relevante Tests/*.md;
- Release-/Packaging-Dokumentation, falls sie real benötigt wird;
- Docs/DeepPluck_V0.13.0_Release_Candidate_Implementation_Report.md.

README muss die reale Endnutzerlage klar beschreiben:

- DeepPluck / Just A Lil' PluckSynth;
- Version 0.13.0;
- Windows 11/64-bit Referenz;
- VST3 und Standalone;
- manuelle VST3-Installation, ohne automatische Systeminstallation;
- Standalone-Nutzung und Audio-/MIDI-Gerätekonfiguration;
- Standalone-only virtuelles Keyboard und Grenzen;
- Factory/User/Pack-Presetkonzept;
- User-Preset-Pfad und sichere Bedienung;
- Credits:
  prompted & directed by Tonetrax
  coded by ChatGPT/Codex
- Website www.tonetrax-music.de;
- Systemanforderungen nur soweit bestätigt;
- bekannte Einschränkungen;
- Build-/Testbefehle für Entwickler getrennt von Endnutzeranweisungen.

ARCHITECTURE muss reale Verträge dokumentieren:

- 62-Parameter-Freeze;
- Processor/Voice/Editor-Ownership;
- Audio-/MIDI-/Bus-Pfad;
- FX nach Voice-Summe;
- Preset/State/Random-Grenzen;
- Factory-Embedding;
- VST3-/Standalone-Abgrenzung;
- Standalone Keyboard;
- Realtime-Regeln;
- Version/Artifact/Packaging;
- Teststrategie und 696-Corpus.

Keine nicht vorhandenen Features, Plattformen, DAW-Kompatibilität, Signierung,
Installer oder Performance-Garantie dokumentieren. Kein Marketing-Superlativ
als technische Tatsache.

===============================================================================
27. KNOWN LIMITATIONS
===============================================================================

Ermittle reale aktuelle Einschränkungen und dokumentiere nur zutreffende.

Beim Snapshot bekannte Kandidaten:

- Windows-only; kein bestätigter macOS-/Linux-Build;
- kein Installer;
- keine automatische Update-Funktion;
- kein MPE;
- kein Pitch Bend;
- keine Modulationsmatrix;
- festes, nicht resizable Plugin-/Standalone-Layout;
- virtuelles Keyboard nur in Standalone;
- kein Computer-/QWERTZ-Keyboard;
- historischer D96/64-Deadline-Befund OPEN/deferred;
- manuelle Cubase-, Geräte-, DPI- und Hörabnahme bis Userbestätigung OPEN.

Diese Liste beim realen Start prüfen. Nicht erfüllte Featurewünsche sind nur
dann eine bekannte Einschränkung, wenn sie für den Endnutzer relevant sind.
Keine Probleme erfinden und keinen offenen technischen Befund verschweigen.

===============================================================================
28. MANUAL USER ACCEPTANCE PRINCIPLE
===============================================================================

Automatisierte Tests ersetzen keine manuelle Abnahme.

Der Implementation Report enthält jeden Punkt mit Status:

- PASS - nur nach ausdrücklicher tatsächlicher Userbestätigung;
- FAIL - reproduziert und beschrieben;
- OPEN - noch nicht ausgeführt oder nicht eindeutig bestätigt;
- NOT APPLICABLE - nur mit konkreter Begründung.

Die frühere Userbestätigung von V0.12.75 bleibt historische Abnahme des damaligen
Stands. Sie darf nicht automatisch als manuelle Freigabe eines geänderten
V0.13.0-Builds ausgegeben werden.

===============================================================================
29. MANUAL ACCEPTANCE CHECKLIST
===============================================================================

29.A Cubase

[ ] VST3 wird als dieselbe DeepPluck-Identität erkannt.
[ ] VST3 lädt und GUI öffnet/schließt stabil.
[ ] Exakt 62 Automationsparameter in unveränderter Reihenfolge.
[ ] MIDI Note On/Off und Spielbetrieb.
[ ] Presetwechsel Factory/User/Pack.
[ ] Automation Write und Read.
[ ] Projekt speichern.
[ ] Projekt schließen.
[ ] Projekt erneut öffnen.
[ ] Alle Parameter und Soundzustände korrekt restauriert.
[ ] Alte kompatible Projekte/States laden.
[ ] Mehrere Instanzen.
[ ] Host Bypass/Disable/Enable.
[ ] Plugin entfernen und erneut laden.
[ ] Kein Crash, Hang oder hängender Ton.
[ ] Realtime-Wiedergabe.
[ ] Offline Bounce.
[ ] Bounce erneut importieren und auf offensichtliche Artefakte prüfen.
[ ] FX-Tails und Stop/Start.

29.B Standalone

[ ] Start und erneuter Start.
[ ] Audio Device Setup.
[ ] reale Audioausgabe.
[ ] externer MIDI-Eingang.
[ ] virtuelles Keyboard sichtbar.
[ ] weiße und schwarze Tasten.
[ ] Mouse Note On/Off und Drag.
[ ] Akkorde und schnelle Retrigger.
[ ] Oct - und Oct + einschließlich Grenzen.
[ ] externes und virtuelles MIDI gleichzeitig.
[ ] Presetwechsel während Spiel.
[ ] Welcome, Settings und About.
[ ] Schließen während gehaltener virtueller Note.
[ ] Audio Stop/Start beziehungsweise Device Restart.
[ ] kein hängender Ton.
[ ] normaler Shutdown.

29.C GUI / DPI / UX

[ ] MAIN ohne Clipping/Overlap.
[ ] MODULATION ohne Clipping/Overlap.
[ ] FX ohne Clipping/Overlap.
[ ] SETTINGS ohne Clipping/Overlap.
[ ] Welcome vollständig sichtbar.
[ ] About, Credits, Version und Website korrekt.
[ ] Website öffnet erst nach Klick die exakte HTTPS-Adresse.
[ ] Hover Help und Tooltips.
[ ] Focus-/Tab-Verhalten.
[ ] Disabled States verständlich.
[ ] VST3 100 %, 125 % und 150 % Windows Scaling.
[ ] Standalone 100 %, 125 % und 150 % Windows Scaling.
[ ] VST3 zeigt kein virtuelles Keyboard.
[ ] Standalone zeigt vollständiges Keyboard ohne abgeschnittene Controls.

29.D Sound

[ ] Default Sound.
[ ] repräsentative Presets aus allen acht Factory-Kategorien.
[ ] Dry und Wet.
[ ] Mono und Stereo.
[ ] kurze und lange Hüllkurven.
[ ] Unison 1..4.
[ ] Filter/Drive/Resonance.
[ ] Transient/Noise.
[ ] Chorus/Delay/Reverb und verschiedene Orders.
[ ] keine offensichtlichen Klicks oder Pegel-/Klangregressionen.
[ ] keine hängenden Tails.

29.E Performance

[ ] normales Cubase-Projekt.
[ ] mehrere Instanzen.
[ ] 44.1/48/96 kHz soweit reales Setup verfügbar.
[ ] kleine und normale ASIO-Buffer.
[ ] keine unerwarteten CPU-Spikes oder Dropouts.
[ ] bewusste Entscheidung zum dokumentierten D96/64-Release-Risiko,
    falls es technisch weiterhin offen ist.

===============================================================================
30. OUT OF SCOPE
===============================================================================

V0.13.0 enthält nicht:

- Pitch Bend;
- neue Host-Parameter;
- Parameteränderungen;
- neue Oszillatoren oder Waveforms;
- neue Filtertypen oder Slopes;
- neue Modulationsziele;
- Modulationsmatrix;
- neue FX;
- neue Tone-/Voicing-Arbeit;
- neue Factory-Preset-Generation oder musikalisches Retuning;
- Preset Generator GUI im Produkt;
- neue umfassende CPU-Optimierungsrunde;
- großes GUI-Redesign;
- Responsive Layout oder Resizing;
- neue MIDI- oder Keyboard-Funktionen;
- Computer-/QWERTZ-Keyboard;
- MPE;
- Arpeggiator;
- Sequencer;
- Chord Memory;
- Installer;
- Updater;
- Signierungsinfrastruktur ohne separaten Auftrag;
- Cloud, Accounts, Telemetrie oder Marketplace;
- finale V1.0.0-Veröffentlichung.

===============================================================================
31. BINDING IMPLEMENTATION ORDER
===============================================================================

1. Authoritative Inputs vollständig lesen.
2. Initial Audit read-only abschließen.
3. Reconciliation Gate abschließen.
4. eindeutigen V0.13.0 Start-HEAD dokumentieren.
5. geschützte Inputs und unveränderte JUCE-Basis hashen.
6. gültige V0.12.75-Evidence und bekannte offene Befunde zuordnen.
7. reconciled RC baseline erfassen.
8. reale Produkt-, Host-, Preset-, GUI-, Standalone-, Audio-, Performance-,
   Test-, Version- und Artifact-Inventur erstellen.
9. Feature Freeze festhalten.
10. fehlende Fast-/Targeted-Regressionstests nur für reale Lücken ergänzen.
11. RC-Smokes ausführen und gefundene Bugs reproduzieren/klassifizieren.
12. Blocker/Major-Bugs nacheinander minimal beheben; nach jedem Fix nur
    relevante Fast Tests.
13. risikoarme Minor-Fixes nur bei klarer RC-Relevanz umsetzen.
14. nach größeren Integrationsschritten Representative RC Smoke ausführen.
15. D96/64-Status gemäß Abschnitt 16 behandeln.
16. Version zentral auf 0.13.0 setzen, wenn der Stand als RC-Kandidat bereit ist.
17. Artifact-/Evidence-Pfade eng um V0.13.0 erweitern.
18. Packaging-Allowlist und Manifest projektlokal vorbereiten.
19. README, ARCHITECTURE, Testdokumentation und Report synchronisieren.
20. Realtime-Code-Review abschließen.
21. Source/Build/Teststand einfrieren.
22. Toolchain-Preflight ausführen.
23. finale frische Debug-/Release-Builds und vollständige CTests ausführen.
24. finale native VST3-/Standalone-/Version-/Artifact-/Packaging-Smokes.
25. genau je einen finalen 696-Lauf in Debug und Release ausführen.
26. bei danach nötiger Audio-/DSP-/Preset-Content-Änderung betroffene Gates
    einschließlich Corpus regelkonform wiederholen.
27. vollständigen Implementation Report schreiben.
28. Definition of Done und Readiness ehrlich entscheiden.
29. Schutz-, JUCE-, Ignore-, Staging- und Git-Status prüfen.
30. Nur nach vollständigem automatable DoD explizite RC-Dateien stagen,
    staged Diff prüfen und kleine nachvollziehbare lokale Commits erstellen.
31. Nach Commits finalen HEAD/Status erfassen. Kein Push.
32. Manuelle Checkliste mit PASS/FAIL/OPEN übergeben.

===============================================================================
32. AUTOMATABLE DEFINITION OF DONE
===============================================================================

V0.13.0 ist automatable-complete nur wenn alle zutreffenden Punkte belegt sind:

REPOSITORY / SCOPE

[ ] Initial Audit vollständig.
[ ] Reconciliation Gate vollständig.
[ ] klarer V0.13.0 Start-HEAD dokumentiert.
[ ] keine legitime Benutzerarbeit verloren oder überschrieben.
[ ] Feature Freeze eingehalten.
[ ] nur RC-Hardening, keine neuen Features.

COMPATIBILITY

[ ] exakt 62 Host-Parameter unverändert.
[ ] vollständiger Feld-für-Feld-Parametervergleich PASS.
[ ] Plugin-/Host-/Class-Identität unverändert.
[ ] Bus-/MIDI-Vertrag unverändert.
[ ] State-/Automation-/Migration-Kompatibilität PASS.
[ ] Preset-Schema und Semantik unverändert.
[ ] Random/Amount/Locks/Undo unverändert und PASS.
[ ] genau 16 Stimmen.

PRESETS

[ ] Factory/User/Pack/Imported funktionieren.
[ ] exakt 116 aktive Factory-Presets.
[ ] acht Kategorien und exakte Counts.
[ ] Katalog-/Approval-/Dateihashes PASS.
[ ] keine Candidate-/User-/Pack-Datei eingebettet.
[ ] factory:0..3-Kompatibilität unverändert.
[ ] alle 116 technisch ladbar.

PRODUCT / AUDIO

[ ] VST3 initialisiert/lädt/entlädt stabil.
[ ] Standalone startet/schließt stabil.
[ ] Standalone Keyboard technisch PASS.
[ ] VST3 zeigt kein Keyboard.
[ ] Voice-Stealing, Reset und Tails stabil.
[ ] keine NaNs/Infs.
[ ] keine reproduzierbare DSP-Instabilität.
[ ] keine hängenden Stimmen/Noten.
[ ] keine neue relevante Performance-Regression.
[ ] keine bekannte offene Severity-A-/Severity-B-RC-Regression.
[ ] historischer D96/64-Status unverfälscht dokumentiert.

BUILDS / TESTS

[ ] Debug Build PASS.
[ ] Release Build PASS.
[ ] keine Compilerfehler.
[ ] keine neuen Compilerwarnungen.
[ ] vollständige Debug CTest Suite PASS.
[ ] vollständige Release CTest Suite PASS.
[ ] tatsächliche CTest-Anzahl je Konfiguration dokumentiert, mindestens
    bestehende 40 sofern keine bewusst dokumentierte Testarchitekturänderung.
[ ] Debug Factory Audio 696/696 PASS.
[ ] Release Factory Audio 696/696 PASS.
[ ] Anzahl und Gründe aller Corpus-Läufe dokumentiert.
[ ] Standalone-Smokes PASS.
[ ] native VST3 Factory/Bundle Validation PASS.
[ ] Sample-Rate-/Buffer-Smokes PASS.
[ ] Realtime Review ohne offenen Blocker/Major-Befund.

VERSION / ARTIFACT / PACKAGE

[ ] project VERSION ist einzige aktuelle Versionsquelle.
[ ] alle echten Zielartefakte melden exakt 0.13.0.
[ ] Windows VERSIONINFO exakt 0.13.0.
[ ] About/Footer exakt aus zentraler Version.
[ ] Debug/Release VST3 und Standalone vorhanden.
[ ] projektlokale Kopien vorhanden und byteidentisch.
[ ] stale/missing/wrong-class-Negativtests PASS.
[ ] projektlokales RC-Package enthält nur Allowlist-Inhalt.
[ ] Packaging-Manifest mit Größe/SHA-256 PASS.
[ ] keine Debug-/Developer-/Candidate-/Private-Datei im Package.

DOCUMENTATION / PROTECTION

[ ] README und ARCHITECTURE entsprechen der Realität.
[ ] Test-/Packaging-Dokumentation aktuell.
[ ] Implementation Report vollständig.
[ ] Known Limitations ehrlich.
[ ] manuelle Punkte nicht als automatisch bestanden markiert.
[ ] JUCE/ unverändert.
[ ] geschützte User-Dateien unverändert und unstaged.
[ ] build/ und Artifacts/ ignoriert und unstaged.
[ ] COPY_PLUGIN_AFTER_BUILD FALSE.
[ ] keine Systeminstallation.
[ ] kein Push.

Ein offener manueller Cubase-/Standalone-Geräte-/DPI-/Hörpunkt verhindert nicht
die Bezeichnung automatable-complete, muss aber OPEN bleiben. Er kann die
endgültige V1.0-Readiness je nach Punkt weiterhin blockieren.

===============================================================================
33. IMPLEMENTATION REPORT REQUIREMENTS
===============================================================================

Der Report muss mindestens enthalten:

IDENTITÄT UND GIT

1. Datum und Zeitzone.
2. ursprünglicher Branch, HEAD, Betreff und vollständiger Git-Status.
3. staged/unstaged/untracked/ignored Klassifikation.
4. geschützte Dateien mit Vorher-/Nachher-Prüfung.
5. vorhandene Alt-Arbeit und deren Zuordnung.
6. Reconciliation-Ergebnis und eventuelle Checkpoint-Commits.
7. finaler V0.13.0 Start-HEAD.
8. End-HEAD und End-Git-Status.
9. Bestätigung, dass keine Benutzerarbeit verloren ging.

BASELINE

10. Toolchain mit realen Versionswerten.
11. Produktversion und Host-/Class-Identität.
12. Parameterzahl und vollständiger Freeze-Nachweis.
13. State-/Preset-/Migration-/Automation-Verträge.
14. Factory-Anzahl, Kategorien, Counts und Approval-Status.
15. GUI-Struktur, Welcome/Settings/About.
16. VST3-/Standalone-Größen und Standalone Keyboard.
17. Test-Suite, CTest-Namen und Corpus-Abgrenzung.
18. verwendete historische Evidence und Vergleichbarkeit.

RC FINDINGS AND FIXES

19. jeden gefundenen Bug mit Reproduktion und Severity.
20. behobene Bugs mit Dateien und minimaler Lösung.
21. bewusst offene Minor Issues.
22. Feature-Freeze-/No-Creep-Nachweis.
23. State/Preset/Automation-Ergebnis.
24. Factory/User/Pack/Imported-Ergebnis.
25. Random/Lock/Undo/FX-Order-Ergebnis.
26. GUI-/DPI-/Welcome-/About-Ergebnis.
27. Standalone-/Keyboard-Ergebnis.
28. VST3-/Host-Smoke-Ergebnis.
29. Audio-Stability-/Headroom-/Tail-Ergebnis.
30. Realtime-Code-Review.
31. Performance-Vergleich.
32. historischer D96/64-Status, neue RC-Evidence und keine falsche PASS-Aussage.
33. Packaging-Inhalt und Ausschlussprüfung.
34. Known Limitations.

TESTS UND ARTEFAKTE

35. alle Fast-/Targeted-Runs mit Config, Exit und Ergebnis.
36. alle Representative RC Smokes.
37. finaler Fresh Configure.
38. vollständiger Debug Build und CTest-Anzahl/Dauer.
39. vollständiger Release Build und CTest-Anzahl/Dauer.
40. Warnungsbilanz gegen Baseline.
41. jeder vollständige 696-Lauf mit Config, Root, Dauer, Ergebnis,
    Peak/Tail/finite-Status und Grund.
42. Begründung jedes zusätzlichen Corpus-Laufs.
43. Standalone-Smokes.
44. VST3 Factory-/Bundle-Validation.
45. Generated-/Artifact-Version-Checks.
46. reale Artifact-Pfade, Größen, SHA-256 und ausgelesene Versionen.
47. Byteidentität lokaler Kopien.
48. Packaging-Manifest und SHA-256.

MANUAL

49. vollständige Cubase-Checkliste mit PASS/FAIL/OPEN.
50. vollständige Standalone-Checkliste mit PASS/FAIL/OPEN.
51. vollständige GUI-/DPI-Checkliste mit PASS/FAIL/OPEN.
52. vollständige Listening-Checkliste mit PASS/FAIL/OPEN.
53. vollständige Performance-/Release-Risiko-Checkliste.
54. keine erfundene Userabnahme.

ABSCHLUSS

55. JUCE unchanged.
56. protected files unchanged.
57. build/Artifacts ignored and unstaged.
58. COPY_PLUGIN_AFTER_BUILD FALSE.
59. no system install.
60. no push.
61. technische automatable DoD Entscheidung.
62. eindeutige V1.0 Readiness Decision mit Begründung.

Evidence bleibt projektlokal und ignoriert unter einem eindeutigen
Artifacts/V0.13.0-Unterpfad. Report-Kernaussagen dürfen nicht ausschließlich von
ignorierten Dateien abhängen; wesentliche Resultate, Counts, Hashes und offene
Punkte stehen lesbar im versionierten Report.

===============================================================================
34. RECONCILIATION AND RC COMMIT RULES
===============================================================================

34.A Reconciliation-/Checkpoint-Commits

- nur für vorbestehende, abgeschlossene, valide Alt-Arbeit;
- vor V0.13.0-Produktarbeit;
- explizite Dateipfade;
- ehrliche inhaltsspezifische Nachricht;
- kein V0.13.0-RC-Code im Alt-Commit;
- keine geschützten Dateien, JUCE, build oder Artifacts;
- D96/64 nicht als bestanden bezeichnen.

34.B RC-Commits

- klein und nachvollziehbar;
- getrennt nach tatsächlichem Zweck, soweit sicher:
  - fix: konkrete RC-Bugs
  - test: RC regression coverage
  - docs: RC documentation
  - chore: version/artifact/package validation
- keine unrelated Änderungen;
- kein pauschales git add . oder git add -A;
- nur ausdrücklich autorisierte Projektpfade stagen;
- dieser V0.13.0-Masterprompt darf als autorisiertes V0.13.0-Dokument
  aufgenommen werden; andere historische untracked Masterprompts bleiben
  geschützt;
- vor jedem Commit git diff --cached und staged Dateiliste prüfen;
- keinen RC-Milestone-Commit vor vollständigem automatable DoD;
- nach jedem Commit Hash erfassen;
- nach Abschluss git status prüfen;
- kein Push.

Wenn ein automatisches Pflichtgate fehlschlägt, kein Abschlusscommit und keine
Erfolgsmeldung. Bereits sinnvolle lokale Fix-Commits dürfen nur dann bestehen
bleiben, wenn sie klar gekennzeichnet sind und keine falsche RC-Freigabe
behaupten.

===============================================================================
35. V1.0 READINESS DECISION
===============================================================================

Der Report muss exakt eine technische Hauptaussage enthalten:

READY FOR V1.0 RELEASE PREPARATION

oder

NOT READY FOR V1.0 RELEASE PREPARATION

READY ist nur zulässig, wenn:

- automatable DoD vollständig bestanden;
- keine Severity-A-/Severity-B-Regression offen;
- Version/Artifacts/Package gültig;
- keine Kompatibilitätsverletzung;
- erforderliche manuelle Release-kritische Abnahmen bestätigt;
- der historische D96/64-Befund entweder technisch geklärt/behoben oder vom
  User ausdrücklich als bekanntes Release-Risiko akzeptiert wurde.

Eine frühere Defer-Autorisierung zum Fortsetzen der Roadmap ist kein automatisch
erneuertes V1.0-Release-Risiko-Acceptance.

Wenn NOT READY:

- jeden konkreten Blocker mit Severity/Evidenz nennen;
- zwischen automatischem Fehler, manuell offenem Punkt, bekanntem Risiko und
  echtem externen Blocker unterscheiden;
- keine vage Formulierung;
- keine automatische V1.0-Arbeit beginnen.

Wenn READY:

- nur Bereitschaft für den separat zu spezifizierenden
  V1.0.0-Final-Release-Milestone behaupten;
- keinen Release, Installer, Push, Tag oder Upload vorwegnehmen.

===============================================================================
36. FINAL HANDOFF FORMAT
===============================================================================

Berichte am Ende knapp, aber vollständig in dieser Reihenfolge:

1. Status
   - automatable-complete oder BLOCKED/INCOMPLETE
   - READY oder NOT READY FOR V1.0 RELEASE PREPARATION

2. Reconciliation
   - ursprünglicher Branch/HEAD/Status
   - Alt-Arbeit und Zuordnung
   - Checkpoint-Commits
   - V0.13.0 Start-HEAD
   - Bestätigung, dass nichts verloren ging

3. RC-Arbeit
   - gefundene Bugs und Severities
   - behobene Bugs
   - offene Minor Issues
   - geänderte Dokumentation
   - Feature-Freeze-Nachweis

4. Compatibility
   - 62-Parameter-Vertrag
   - Identity/Class-IDs
   - State/Automation/Migration
   - Presets/Factory/User/Pack
   - Random/Lock/Undo

5. Tests
   - Fast/Targeted
   - Representative RC Smokes
   - Debug Build und vollständige CTests
   - Release Build und vollständige CTests
   - Debug/Release 696/696 und Anzahl der Corpus-Läufe
   - Warnungen
   - Realtime-/Performance-Ergebnis
   - D96/64-Status

6. Artifacts und Package
   - reale Debug/Release VST3-/Standalone-Pfade
   - lokale Kopien
   - ausgelesene Version 0.13.0
   - Packaging-Inhalt/Manifest
   - keine Systeminstallation

7. Git und Schutz
   - RC-Commit-Hashes
   - End-HEAD und Endstatus
   - protected files/JUCE unchanged
   - build/Artifacts ignored and unstaged
   - no push

8. Manual OPEN/PASS/FAIL
   - Cubase
   - Standalone
   - GUI/DPI
   - Listening
   - Performance-/D96/64-Releaseentscheidung

Bei einem Blocker keine Erfolgsaussage erfinden. Nenne die Evidenz, bereits
erledigte sichere Arbeit und genau den nächsten notwendigen Schritt.

===============================================================================
APPENDIX A - FROZEN 62-PARAMETER ID ORDER
===============================================================================

Diese Index-/ID-Liste ist nur eine zusätzliche RC-Prüfhilfe. Verbindlich ist der
vollständige V0.11.0-Vertrag einschließlich Name, Typ, Version Hint, Range,
Intervall/Choices, Default, Skew/Mapping, Raw Unit/Meaning und Textsemantik.
Beim Start gegen Code, ARCHITECTURE und eingefrorene Tests prüfen.

 0 outputGain
 1 masterTune
 2 ampAttack
 3 ampDecay
 4 ampSustain
 5 ampRelease
 6 filterEnabled
 7 filterCutoff
 8 filterResonance
 9 filterDrive
10 filterKeyTracking
11 filterEnvAmount
12 filterAttack
13 filterDecay
14 filterSustain
15 filterRelease
16 transientEnabled
17 transientLevel
18 transientDecay
19 transientTone
20 noiseEnabled
21 noiseLevel
22 noiseDecay
23 noiseTone
24 osc2Enabled
25 osc2Level
26 osc2Octave
27 osc2Semitone
28 osc2FineTune
29 unisonVoices
30 unisonDetune
31 stereoSpread
32 lfoRate
33 lfoSync
34 lfoSyncDivision
35 lfoWaveform
36 lfoRestartMode
37 lfoFilterAmount
38 lfoPitchAmount
39 lfoSpreadAmount
40 osc1Waveform
41 osc1PulseWidth
42 osc2Waveform
43 osc2PulseWidth
44 chorusBypass
45 chorusRate
46 chorusDepth
47 chorusWidth
48 chorusMix
49 delayBypass
50 delaySync
51 delayTime
52 delaySyncDivision
53 delayFeedback
54 delayTone
55 delayMix
56 reverbBypass
57 reverbSize
58 reverbPreDelay
59 reverbDamping
60 reverbMix
61 fxOrder

===============================================================================
APPENDIX B - CREATION-SNAPSHOT WARNINGS
===============================================================================

1. Die 116 aktive Factory Library ist die reale freigegebene Basis. Nicht auf
   den überholten 48er-Plan reduzieren.
2. Der 696-Corpus ist ein externer Factory-Audio-Final-Gate pro Konfiguration,
   kein einzelner CTest und nicht der Tone-/CPU-Corpus.
3. Die V0.12.75-Basis enthält 40 CTests pro Konfiguration.
4. Die praktische Nutzerfreigabe früherer Milestones ist keine erfundene
   Detailfreigabe des späteren V0.13.0-Stands.
5. Der D96/64-Befund bleibt OPEN/deferred und ist für READY ausdrücklich zu
   klären oder vom User als Release-Risiko zu akzeptieren.
6. Dieser Snapshot rechtfertigt keinen Checkout oder Reset.
7. Bei Erstellung dieses Dokuments wurde V0.13.0 nicht implementiert, nicht
   gebaut, nicht getestet, nicht committed und nicht veröffentlicht.

===============================================================================
END OF BINDING V0.13.0 RELEASE CANDIDATE IMPLEMENTATION ORDER
===============================================================================
