DEEPPLUCK - MASTER IMPLEMENTATION SPECIFICATION
MILESTONE V0.2.0b - FIRST MUSICAL PLUCK
REVISION 2

Verbindlicher Entwicklungsauftrag für Codex
Dokumentstatus: vollständig, eigenständig, copy-ready
Zielsprache des Codes: Englisch
Zielsprache der Projektdokumentation: bestehende Projektsprache beibehalten

===============================================================================
0. DOKUMENTCHARAKTER UND AUFTRAG
===============================================================================

Dieses Dokument ist eine vollständig neu geschriebene Master-Spezifikation.
Es ist weder ein Patch noch ein Nachtrag zu Revision 1. Frühere Prompts dienen
nur als historische Referenz. Für Milestone V0.2.0b ist ausschließlich dieses
Dokument maßgeblich.

Du arbeitest als verantwortlicher C++-/JUCE-Audioentwickler im vorhandenen
lokalen Git-Repository von DeepPluck. Implementiere V0.2.0b vollständig auf
Basis des tatsächlich vorgefundenen und validierten V0.2.0a-Stands.

V0.2.0b soll aus einer technisch stabilen Engine erstmals ein Instrument
machen, das unmittelbar musikalisch reagiert. Technische Korrektheit und
musikalische Qualität sind gleichwertige Abnahmekriterien.

Arbeite selbstständig und bis zur vollständigen automatisierbaren Definition
of Done. Erfinde keine Ergebnisse. Ein nicht selbst ausgeführter Hör-, GUI-
oder Cubase-Test ist exakt als

MANUAL VERIFICATION REQUIRED

zu kennzeichnen. Behaupte niemals einen erfolgreichen Build, Test, Benchmark,
Host-Test, Hörtest oder eine Sichtprüfung, wenn er nicht tatsächlich stattfand.

Keine Systeminstallation, kein Download, kein Push und keine Änderung außerhalb
des Repositorys. JUCE nicht verändern. Das VST3 nicht automatisch in einen
Systemordner installieren. Bestehende Benutzeränderungen niemals verwerfen,
verstecken oder ungefragt überschreiben.


===============================================================================
1. PROJECT VISION UND ENTWICKLUNGSPHILOSOPHIE
===============================================================================

DeepPluck ist ein spezialisiertes Softwareinstrument für inspirierende,
hochwertige Pluck-Sounds in Deep House, Melodic House, Organic House,
Progressive House und angrenzenden Stilen.

DeepPluck ist kein allgemeiner Synthesizer und keine Technologie-Demonstration.
Die Anzahl der Features ist kein Qualitätsmerkmal. Das Instrument soll warm,
weich, fokussiert, kontrolliert, emotional und sofort spielbar wirken.

Jede Entscheidung muss mindestens einem dieser Ziele dienen:

- bessere musikalische Ausdruckskraft
- bessere trockene Klangqualität
- klarerer Workflow
- höhere Stabilität oder Wartbarkeit

Bei zwei technisch korrekten Lösungen gewinnt die hörbar musikalischere
Lösung, sofern Realtime-Sicherheit, Stabilität und Kompatibilität gewahrt sind.
Mathematische Eleganz allein rechtfertigt keine schlechter klingende Lösung.

Verbindliche Priorität:

1. Sicherheit und Schutz vorhandener Arbeit
2. Realtime-Sicherheit
3. musikalische Qualität und Sound Manifest
4. technische Korrektheit und Stabilität
5. Rückwärtskompatibilität
6. Wartbarkeit und Lesbarkeit
7. messbare Performance
8. Feature-Wachstum

Der trockene Grundklang hat Vorrang. Effekte dürfen später veredeln, aber nie
einen schwachen Grundklang kaschieren.


===============================================================================
2. NORMATIVE DOKUMENTE UND PRIORITÄT
===============================================================================

Vor Planung, Codeänderung oder Build vollständig lesen:

- AGENTS.md
- Docs/Sound/DeepPluck_Sound_Manifest_v1.0.md
- README.md
- ARCHITECTURE.md
- vorhandene V0.2.0a- und V0.2.0b-Masterprompts als Historie
- CMakeLists.txt
- alle betroffenen produktiven Dateien unter Source/
- alle vorhandenen Tests und die CTest-Registrierung
- .gitignore

Das Sound Manifest ist ein normatives Produkt- und Klangdokument. Es ist keine
optionale Inspiration. Oszillator, Envelope, Dynamik, Defaults, Headroom,
Presets, GUI und Qualitätsentscheidungen müssen erkennbar darauf einzahlen.

Priorität bei echten Widersprüchen:

1. Sicherheit, aktuelle Benutzeranweisung und bindende AGENTS.md
2. Sound Manifest für Produkt-, Klang- und Musikalitätsentscheidungen
3. diese Master-Spezifikation
4. validierte bestehende Architektur und Kompatibilitätsverträge
5. lokale JUCE-9-API und vorhandener Projektstil

Wenn der fokussierte Scope die vollständige Sound-Vision noch nicht erreichen
kann, dokumentiere die Grenze ehrlich. Baue keine ungeplanten Filter, Effekte
oder Klangkosmetik ein.

Der Abschlussbericht muss beantworten:

Does this make DeepPluck a better instrument for emotional Deep House plucks?


===============================================================================
3. LESSONS LEARNED FROM V0.2.0a
===============================================================================

Diese Erkenntnisse sind für V0.2.0b verbindlich:

1. Die vorhandene Grundarchitektur ist stabil. Sie wird erweitert, nicht neu
   erfunden.

2. Plugin-Laden, Entladen, Automation, State-Restore und Projekt-Rückruf bilden
   eine wertvolle Basis und dürfen nicht regressieren.

3. ADSR-Snapshots pro Note sind technisch vorhersehbar, aber musikalisch zu
   starr. Ein Instrument muss auf relevante Parameterbewegungen während des
   Spielens reagieren.

4. Manuelle Tests in Cubase haben musikalische Fehler sichtbar gemacht, die
   normale Unit-Tests nicht entdeckten. Listening Acceptance Tests sind daher
   Pflicht.

5. Ein Note-Off ist ein musikalisches Ereignis mit sofortiger Wirkung. Es darf
   weder Attack noch Decay erst zu Ende spielen lassen.

6. Eine laufende Release-Phase darf ihre beim Note-On erfasste Zeit nicht
   unveränderlich einfrieren. Verkürzen und Verlängern müssen hörbar und weich
   auf bereits ausklingende Stimmen wirken.

7. Realtime-Sicherheit wurde erreicht und bleibt absolut verbindlich.

8. Der Schwerpunkt verschiebt sich von „Engine bauen“ zu „Instrument bauen“.
   Grüne Tests allein bedeuten nicht, dass ein Milestone musikalisch fertig ist.

9. Das Sound Manifest ist ein dauerhaftes Kerndokument des Projekts.

10. Kleine, klar begrenzte Milestones führen zu besseren Entscheidungen als
    paralleles Feature-Wachstum.


===============================================================================
4. AUSGANGSZUSTAND, BESTANDSAUFNAHME UND SCHUTZREGELN
===============================================================================

Die historische Referenzbasis ist der bestätigte V0.2.0a-Stand mit:

- JUCE-9-CMake-Projekt für Windows x64
- VST3 und Standalone
- Instrument ohne Audioeingang, Stereoausgang, MIDI-In, kein MIDI-Out
- 16 vorab erzeugten Stimmen und einem DeepPluckSound
- samplegenauer MIDI-Unterteilung
- pro Stimme einem Phase-Accumulator-Saw und einer Amp-Envelope
- linearer Velocity-Amplitude
- Tune-Smoothing pro aktiver Stimme
- Output-Gain-Smoothing nach der Stimmsumme
- APVTS-Parameter-Cache und Block-Snapshot
- State-Migration aus V0.1.0
- Debug-/Release-Tests und lokalen Artefaktkonventionen

Ein historischer Commit-Hash ist niemals ein Reset-Auftrag. Prüfe den realen
Stand. Vor jeder Änderung mindestens:

- Git-Status, letzte Commits, unstaged und staged Diff erfassen
- Projektstruktur außerhalb generierter Verzeichnisse erfassen
- normative Dokumente und betroffenen Code vollständig lesen
- Parameterlayout, State-Migration, Voice-Lifecycle, MIDI-Aufteilung,
  Oszillator, Envelope, Synthesiser, Editor und Tests verstehen
- vorhandene Build- und Artefaktkonventionen prüfen
- bestehende Debug-/Release-Tests soweit sicher ausführbar als Baseline laufen
- Abweichungen zwischen Spezifikation und realem Code notieren

Keine Benutzeränderung zurücksetzen, automatisch stashen, ungefragt formatieren
oder in einen Milestone-Commit aufnehmen. Bei Überschneidungen den kleinsten
sicheren Patch wählen. Bei nicht sicher lösbarer Kollision stoppen und den
konkreten Konflikt melden.


===============================================================================
5. PRODUKTIDENTITÄT UND KOMPATIBILITÄT
===============================================================================

Produktname: DeepPluck
Hersteller: ToneTrax
Bundle Identifier: de.tonetrax.deeppluck
Plugin-Typ: Instrument
Formate: VST3 und Standalone
Milestone: V0.2.0b - First Musical Pluck

Bewahre kompatibilitätsrelevante Identitäten, Codes, Formate, Buslayout und
MIDI-Vertrag. Cubase muss das Ergebnis als dasselbe Plugin erkennen.

CMake erhält eine numerische Version 0.2.0, falls das vorhandene System dies so
führt. Sichtbare Entwicklungskennzeichnung: „Development Build V0.2.0b“.

Die stabilen Parameter-IDs bleiben exakt:

- outputGain
- masterTune
- ampAttack
- ampDecay
- ampSustain
- ampRelease

Keine ID umbenennen, neu verwenden oder stillschweigend semantisch brechen.


===============================================================================
6. MILESTONE-ZIEL, SCOPE UND LIEFERUMFANG
===============================================================================

Ein Musiker soll DeepPluck laden und innerhalb von zehn Sekunden im Default-
Zustand einen überzeugenden, trockenen Pluck spielen können.

Verbindlicher Scope:

1. naiven Saw durch einen bandbegrenzten PolyBLEP-Saw ersetzen
2. Amp-Envelope musikalisch und live reaktiv machen
3. Note-Off aus Attack, Decay oder Sustain sofort in Release führen
4. laufende Release-Stimmen auf Release-Änderungen weich reagieren lassen
5. musikalisches, deterministisches Voice-Stealing einführen
6. Voice-Pegel, Output-Smoothing und Headroom sauber abstimmen
7. sinnvolle Defaults bereitstellen
8. vier erste trockene Factory-Presets integrieren
9. minimale Presetauswahl in der Entwicklungs-GUI integrieren
10. automatisierte DSP-, State-, Preset- und Lifecycle-Tests ergänzen
11. Listening Acceptance Tests und Cubase-Validierung durchführen bzw. exakt
    als manuell erforderlich ausweisen
12. Dokumentation, Artefakte, Git und Abschlussbericht vervollständigen

Der Milestone umfasst nur Änderungen, die hierfür notwendig sind.


===============================================================================
7. ANTI GOALS UND NICHT-ZIELE
===============================================================================

Nicht in V0.2.0b implementieren:

- Filter oder Filter-Envelope
- zweiten Oszillator, Noise, FM, Ringmodulation oder Wavetables
- Unison, Chord Memory, Arpeggiator oder Sequencer
- Modulationsmatrix, LFO-System oder Macro-System
- Chorus, Delay, Reverb, Distortion, Saturation, Compressor oder Limiter
- Oversampling als Nebenprojekt
- Preset-Browser oder externe Preset-Dateiformate
- neues GUI-Designsystem, Animationen, Meter oder Visualizer
- neue Hostparameter außerhalb der sechs bestehenden
- Architektur-Rewrite oder parallele Engine
- generischen Synthesizer-Funktionsumfang

DeepPluck soll nicht Serum, Massive, Vital, Pigments oder Phase Plant nachbauen.
Der Benutzer soll mehr Zeit spielen als konfigurieren.

Der detaillierte CPU-Benchmark aus Rev1 gehört nicht zum kritischen Scope
dieses Milestones. Realtime- und CPU-Plausibilitätsprüfung bleiben Pflicht; ein
reproduzierbares Benchmark-System folgt, wenn Filter, Unison oder Effekte eine
messbare Vergleichsbasis schaffen.


===============================================================================
8. VERBINDLICHE ARCHITEKTUR UND SIGNALFLUSS
===============================================================================

Bestehende Verantwortungstrennung erhalten:

MIDI
  -> DeepPluckAudioProcessor
  -> DeepPluckSynthesiser, maximal 16 Stimmen
  -> DeepPluckVoice
       PolyBLEP Saw
       -> Amp Envelope
       -> Velocity
       -> fester Voice Gain
  -> Stereo-Stimmensumme
  -> geglätteter globaler Output Gain
  -> Stereo Output

Genau ein globaler Output Gain liegt nach der kompletten Stimmsumme. Keine GUI-
Logik, Presetlogik oder dynamische Speicherverwaltung gehört in die Sample-
Schleife.

DeepPluckEnvelope ist die projektspezifische Abstraktionsgrenze für Amplituden-
Hüllkurven. V0.2.0b muss die geforderten Live- und Event-Verträge dort oder in
einer gleichwertig klar getrennten Klasse implementieren. Keine Envelope-Logik
in PluginEditor und keine verstreuten Stage-Sonderfälle in PluginProcessor.

Langfristig soll DeepPluckEnvelope zu einer eigenen, vollständig kontrollierten
Pluck-Envelope wachsen, die später als Grundlage für Amp-, Filter- und
Modulationshüllkurven dienen kann. V0.2.0b soll diese Richtung vorbereiten,
aber keine allgemeine Modulations-Engine bauen.


===============================================================================
9. PARAMETER, BEREICHE UND MUSIKALISCHE DEFAULTS
===============================================================================

Stabile Bereiche und neue Defaults:

1. outputGain
   Bereich: -60.0 bis +6.0 dB
   Default: -3.0 dB
   Smoothing: 20 ms nach der vollständigen Stimmsumme

2. masterTune
   Bereich: 420.0 bis 460.0 Hz
   Default: 440.0 Hz
   Smoothing: bestehendes klickfreies Verhalten erhalten

3. ampAttack
   Bereich: 0.001 bis 5.000 s
   Default: 0.003 s
   GUI-/Host-Skalierung: musikalisch sinnvoll logarithmisch/skewed

4. ampDecay
   Bereich: 0.001 bis 5.000 s
   Default: 0.320 s
   GUI-/Host-Skalierung: musikalisch sinnvoll logarithmisch/skewed

5. ampSustain
   Bereich: 0.0 bis 1.0
   Default: 0.0
   GUI-Darstellung: 0 bis 100 Prozent zulässig

6. ampRelease
   Bereich: 0.001 bis 10.000 s
   Default: 0.180 s
   GUI-/Host-Skalierung: musikalisch sinnvoll logarithmisch/skewed

„Deep Pluck“ entspricht exakt den APVTS-Defaults. Ein neuer Plugin-Start und
Reset auf Defaults ergeben denselben Klang wie dieses Preset.

Parameterregeln:

- alle sechs Parameter bleiben automatisierbar, speicherbar und rückrufbar
- keine neuen Parameter für Kurvenform, Voice Gain oder Presetname
- Parameterpointer außerhalb des Hot Path binden
- jeden Hostparameter pro Audioblock höchstens einmal atomar laden
- nicht-finite Werte sicher ersetzen, technische Grenzen clampen
- alte gespeicherte Werte niemals durch neue Defaults überschreiben
- jede Parameterbewegung muss einen klaren musikalischen Zweck haben


===============================================================================
10. POLYBLEP-SAW
===============================================================================

Ersetze den naiven aufsteigenden Saw

rawSaw = 2 * phase - 1

durch einen PolyBLEP-korrigierten Saw. Normalisierte Phase [0, 1),
dt = frequencyHz / sampleRate, Phase vor dem Advance verwenden.

Referenz:

polyBLEP(t, dt):
    if dt <= 0: return 0
    if t < dt:
        x = t / dt
        return x + x - x*x - 1
    if t > 1 - dt:
        x = (t - 1) / dt
        return x*x + x + x + 1
    return 0

sample = (2 * phase - 1) - polyBLEP(phase, dt)

Eine algebraisch gleichwertige, getestete Form ist zulässig.

Verträge:

- setFrequency ändert Frequenz und dt ohne Phasenreset
- Frequenz sicher auf 0 bis 0.49 * sampleRate begrenzen
- nicht-finite oder nichtpositive Frequenz erzeugt sichere Stille ohne DC
- reset normalisiert jede finite Phase robust in [0, 1)
- processSample ist noexcept, endlich, bounded und allokationsfrei
- Phase nach jedem Sample robust wrappen
- keine dynamische Tabelle, kein Oversampling, keine harte Ausgangsbegrenzung
  als Ersatz für korrekte Mathematik
- Tune-Smoothing darf die Phase nicht resetten
- deterministisches Note-On-Verhalten erhalten

Klanglich müssen aliasartige inharmonische Hochfrequenzanteile gegenüber
V0.2.0a deutlich sinken, besonders bei hohen Noten. Der Saw bleibt präsent,
klingt aber weniger kratzig und digital. PolyBLEP ist eine Näherung; keine
vollständige Aliasfreiheit behaupten.


===============================================================================
11. LIVE DEEPPLUCK ENVELOPE - ZUSTÄNDE UND GRUNDVERTRÄGE
===============================================================================

Stages:

- idle
- attack
- decay
- sustain
- release

Allgemein:

- Ausgabe immer endlich und in [0, 1]
- Stage-Wechsel ohne Pegelsprung
- keine Klicks, Zipper-Artefakte oder Envelope-Neustarts durch Automation
- keine exp()/pow()-Berechnung pro Sample
- keine Allokation, Locks oder unbeschränkte Arbeit
- Koeffizienten nur bei prepare, Parameterübernahme, Event oder Stage-Wechsel
  aktualisieren
- kleine feste Mathematik pro Block oder Event ist zulässig
- reset deterministisch; Hard Stop setzt sofort idle und 0
- nach Release-Ende exakt 0, idle und isActive false
- Denormals vermeiden

Kurvenziel:

- Attack: monoton von 0 nach 1, schneller musikalischer Beginn und weiches
  Annähern an den Peak; Attack Target Ratio 0.30
- Decay: monoton vom aktuellen Peak zum Sustain-Level, schnellerer Beginn und
  weicher Tail; Decay Target Ratio 0.0001
- Sustain: stabiler oder weich zum live geänderten Ziel wandernder Pegel
- Release: monoton und weich vom exakt aktuellen Level nach 0; Release Target
  Ratio 0.0001

Eine Target-Ratio-Rekurrenz ist geeignet:

value = target + coefficient * (value - target)

Dokumentiere Formel, Timingdefinition und Target Ratios in ARCHITECTURE.md.


===============================================================================
12. LIVE-PARAMETERVERHALTEN DER ENVELOPE
===============================================================================

Die bisherige Regel „ADSR-Änderungen gelten nur für die nächste Note“ wird
ersetzt. Attack, Decay, Sustain und Release müssen musikalisch auf bereits
aktive Stimmen wirken.

Kontinuitätsgrundsatz:

Bei jeder Änderung bleibt der aktuelle Envelope-Pegel der erste Wert der neuen
Berechnung. Es gibt keinen Sprung zum Anfang einer Stage, keinen Neustart und
keine rückwirkende Neuberechnung bereits ausgegebener Samples.

Attack live:

- Wird Attack während Attack verkürzt, nähert sich die Stimme ab ihrem aktuellen
  Pegel kontrolliert schneller dem Peak.
- Wird Attack verlängert, wird der verbleibende Anstieg ab aktuellem Pegel
  kontrolliert verlängert.
- Die Stage darf nicht auf 0 zurückspringen und den Peak nicht überschießen.
- Nach Verlassen der Attack-Stage darf eine Attack-Änderung die Stimme nicht in
  Attack zurückversetzen.

Decay live:

- Wird Decay während Decay verkürzt oder verlängert, passt sich die verbleibende
  Stage ab dem aktuellen Pegel weich an.
- Keine Rückkehr zum Peak, kein Sprung auf Sustain.
- Sustain-Änderungen während Decay ändern das Ziel weich und monoton soweit
  musikalisch möglich. Bei Zielkreuzung muss die Implementierung stabil und
  ohne Oszillation in Sustain übergehen.

Sustain live:

- Änderungen während Sustain fahren den Pegel über eine kurze, definierte,
  samplegenaue Glättung auf den neuen Zielwert.
- Empfohlene Sicherheitsrampe: 10 bis 20 ms, unabhängig von Blockgröße.
- Sustain 0 ist ein gültiger Zielwert.

Release live - absolut verbindlich:

- Wird Release verkürzt, während Stimmen bereits in Release sind, beginnt ab
  dem aktuellen Pegel unmittelbar eine kürzere, weiterhin weiche Restphase.
- Wird Release verlängert, verlängert sich die Restphase ab aktuellem Pegel
  natürlich.
- Der Pegel darf nicht springen, steigen, neu starten oder abrupt verstummen.
- Release-Automation muss über Blockgrenzen und bei unterschiedlichen
  Buffergrößen stabil bleiben.
- Die neue Zeit beschreibt die musikalisch erwartete verbleibende Zeit vom
  aktuellen Pegel bis 0, nicht eine eingefrorene Gesamtdauer vom Note-On.

Die Implementierung darf Zeit-/Koeffizientenänderungen intern glätten, muss aber
spürbar auf Benutzerbewegungen reagieren. Eine zehnsekündige alte Release-Zeit
darf nach der Änderung auf 0.05 s nicht weiter zehn Sekunden auslaufen.


===============================================================================
13. NOTE-OFF - NICHT VERHANDELBARER EVENTVERTRAG
===============================================================================

Ein Note-Off führt jede betroffene aktive Stimme sofort in Release, unabhängig
davon, ob sie sich in Attack, Decay oder Sustain befindet.

Erlaubt:

Attack -> Release
Decay -> Release
Sustain -> Release

Verboten:

- Attack erst fertig spielen und danach Release starten
- Decay erst fertig spielen und danach Release starten
- Note-Off bis zum nächsten regulären Stage-Ende ignorieren
- Release am Peak oder Sustain-Ziel statt am aktuellen Pegel beginnen

Release beginnt exakt und kontinuierlich am aktuellen Envelope-Level.

Edge Cases:

1. Note kürzer als Attack:
   Note-Off startet sofort Release aus dem aktuellen Attack-Pegel.

2. Note kürzer als Decay:
   Note-Off startet sofort Release aus dem aktuellen Decay-Pegel. Der restliche
   Decay wird niemals zuerst ausgespielt.

3. Note länger als Decay, Sustain > 0:
   Note-Off startet Release aus dem aktuellen Sustain-Pegel.

4. Note länger als Decay, Sustain = 0:
   Wenn die Envelope bereits exakt oder praktisch 0 erreicht hat, existiert
   keine Energie für einen hörbaren Release. Die Stimme darf sauber enden. Es
   darf kein künstlicher Mindestpegel und keine versteckte Restenergie erfunden
   werden. Dies ist etwas anderes als das verbotene Ignorieren eines Note-Off
   während Decay.

5. Note-Off und Release-Automation im selben Block:
   samplegenaue Event-Reihenfolge respektieren, endliche kontinuierliche Ausgabe.

Mehrfaches Note-Off, All Notes Off und verlorene/verspätete Events dürfen keine
hängenden Stimmen erzeugen.


===============================================================================
14. VOICE-LIFECYCLE UND MUSIKALISCHES VOICE-STEALING
===============================================================================

Maximal 16 vorab erzeugte Stimmen bleiben bestehen. Kein Wachstum im Audio-
Thread. Auswahl bleibt deterministisch.

Priorität beim Anfordern einer Stimme:

1. freie/idle Stimme
2. Stimme in Release mit niedrigstem aktuellem hörbaren Pegel
3. andere nahezu stille aktive Stimme
4. bei vergleichbarem Pegel die musikalisch am wenigsten auffällige, danach
   die älteste Stimme als deterministischer Tie-Breaker

Laut hörbare Stimmen dürfen nicht gestohlen werden, wenn eine deutlich leisere
Stimme verfügbar ist. Der Vergleich soll den effektiven Amp-Pegel inklusive
Envelope und Velocity berücksichtigen, ohne teure Analyse.

Stealing darf keine Klicks, NaNs, Pegelspitzen oder hängenden Noten erzeugen.
Falls eine hörbare Stimme unvermeidbar ist, verwende eine sehr kurze, feste,
allokationsfreie Sicherheitsüberblendung bzw. einen Residual-Tail, während die
neue Note ohne unmusikalische Verzögerung startet. Keine dynamische Stimme und
kein blockierendes Warten.

All Notes Off/Panic muss alle Stimmen zuverlässig beenden. Ein Host-Hard-Stop
darf eine kurze feste Sicherheitsrampe verwenden, wenn dadurch Klicks vermieden
werden. Keine neue sichtbare Panic-GUI in diesem Milestone.


===============================================================================
15. VELOCITY, OUTPUT-SMOOTHING UND HEADROOM
===============================================================================

Velocity bleibt linear und musikalisch nachvollziehbar:

velocityGain = clamp(velocity, 0, 1) * voiceGain

Zielwert für den festen Voice Gain: 0.08. Falls reale Render- und Hörtests eine
kleine Abweichung verlangen, ist sie nur mit dokumentierter Messung und
musikalischer Begründung zulässig.

Output Gain:

- genau einmal nach der kompletten Stimmsumme
- 20 ms samplegenaues Smoothing bleibt aktiv
- rasche Automation ohne Clicks oder Zipper Noise
- kein Reset des Smoothers an Blockgrenzen

Headroom:

- Default outputGain -3.0 dB
- keine Normalisierung nach aktiver Stimmenzahl
- kein Limiter, Kompressor, Softclipper, verstecktes Auto-Gain oder DC-Blocker
  als Reparatur eines falschen Pegeldesigns
- Factory-Presets verwenden -4.0 bis -2.5 dB Output Gain
- definierter 16-Voice-Worst-Case-Render bleibt endlich und unter 1.0
- Zielgrenze für den automatisierten Factory-Headroom-Test: Peak <= 0.95
- Benutzer darf den bestehenden Bereich bis +6 dB bewusst nutzen

Prüfe Mono und Stereo. Keine unnötige Pegelerhöhung durch Dual-Mono-Ausgabe.


===============================================================================
16. FACTORY-PRESETS UND DEFAULT SOUND
===============================================================================

Vier interne Factory-Presets, nur mit den sechs bestehenden Parametern:

1. Deep Pluck
   outputGain -3.0 dB
   masterTune 440.0 Hz
   ampAttack 0.003 s
   ampDecay 0.320 s
   ampSustain 0.000
   ampRelease 0.180 s
   Rolle: verbindlicher Default und zentrale Klangidentität

2. Soft Pluck
   outputGain -3.0 dB
   masterTune 440.0 Hz
   ampAttack 0.012 s
   ampDecay 0.450 s
   ampSustain 0.020
   ampRelease 0.280 s
   Rolle: weichere Ansprache, intimerer Ausklang

3. Tight Pluck
   outputGain -2.5 dB
   masterTune 440.0 Hz
   ampAttack 0.001 s
   ampDecay 0.160 s
   ampSustain 0.000
   ampRelease 0.075 s
   Rolle: kurze rhythmische Figuren

4. Long Pluck
   outputGain -4.0 dB
   masterTune 440.0 Hz
   ampAttack 0.006 s
   ampDecay 0.700 s
   ampSustain 0.030
   ampRelease 0.450 s
   Rolle: emotionaler, längerer Pluck

Presetregeln:

- unveränderliche, fest kompilierte Daten in kleiner klarer Struktur
- keine externe Datei und keine neue Abhängigkeit
- Anwendung nur auf Message Thread
- APVTS-Werte JUCE-konform mit Host-Benachrichtigung und Gestures setzen
- gespeicherte Parameter sind klangliche Wahrheit; Presetname muss nicht in
  den State
- exakter Match zeigt Presetnamen, sonst „Custom“
- Editoröffnung darf niemals Parameter verändern
- alte States dürfen nicht von der sichtbaren Presetauswahl überschrieben werden
- Presets sind Produktions-Startpunkte, keine Extremwert-Demos
- jedes Preset muss trocken klar unterscheidbar und musikalisch brauchbar sein

Wertabweichungen nur nach Hörtest, innerhalb bestehender Bereiche, mit genauer
Begründung im Abschlussbericht. Namen, Anzahl und Rollen nicht ändern.


===============================================================================
17. GUI, STATE, AUTOMATION UND RÜCKWÄRTSKOMPATIBILITÄT
===============================================================================

GUI-Scope:

- Versionszeile „Development Build V0.2.0b“
- kompakte Factory-Preset-ComboBox mit Custom und vier Presets
- alle sechs bestehenden Controls und Attachments erhalten
- nur notwendige Layoutkorrekturen
- keine Animation, Meter, neue Bilder, Fonts oder neues Designsystem
- Audio-Thread greift nie auf GUI-Komponenten zu

State-Verträge:

- V0.1.0: gespeicherte bekannte Werte behalten; fehlende ADSR-Werte erhalten
  V0.2.0b-Defaults
- V0.2.0a: alle sechs gespeicherten Werte exakt wiederherstellen, auch alte
  Defaults
- V0.2.0b: vollständiger Roundtrip aller sechs Werte
- ungültiges XML, falscher Root und nicht-finite Werte verursachen keinen Crash
- Editor öffnen/schließen verändert keinen State

Automation:

- Write/Read und, wo vom Host angeboten, Touch/Latch
- Output und Tune bleiben geglättet
- ADSR-Automation wirkt gemäß Live-Vertrag auf aktive Stimmen
- Blockgröße darf das Ergebnis nicht qualitativ verändern
- Presetwahl erzeugt nachvollziehbare Host-Parameterbewegungen
- Undo/Redo und Projekt-Restore bleiben stabil


===============================================================================
18. REALTIME-, C++20- UND CODEQUALITÄTSREGELN
===============================================================================

Im Audio-Thread absolut verboten:

- Heap-Allokation oder Containerwachstum
- Mutex, Critical Section, Wait oder blockierende Synchronisation
- Datei-, Netzwerk- oder Prozesszugriff
- Logging und Stringformatierung
- GUI-Zugriff
- Exceptions als Kontrollfluss
- unbeschränkte Schleifen oder Arbeit abhängig von unbekannter Eingabegröße

Zulässig sind feste Buffer, vorab reservierte Strukturen, Atomics,
Stackvariablen, Parameter-Snapshots und deterministische bounded DSP-Arbeit.

Codequalität:

- vorhandenen C++20-/JUCE-Stil respektieren
- klare Verantwortungen und verständliche Namen
- kurze Funktionen, keine monolithische Processor-Klasse
- Kommentare erklären WHY, nicht offensichtliches WHAT
- keine Magic Numbers; musikalische Konstanten benennen
- const correctness, noexcept wo fachlich korrekt
- keine Warnungen unterdrücken
- keine Tests entfernen, abschwächen oder künstlich grün machen
- lesbarer Code vor Mikrooptimierung, solange Realtime-Budget eingehalten wird


===============================================================================
19. AUTOMATISIERTE TESTS
===============================================================================

Alle bestehenden Tests bleiben aktiv. Ergänze mindestens:

PolyBLEP:

- Phase bleibt normalisiert und deterministisch
- Frequenz/Pitch bei mehreren Sampleraten korrekt
- endliche Ausgabe bei Grenz- und Fehlerwerten
- kein relevanter DC-Drift
- spektraler Vergleich zeigt deutlich weniger aliasartige Energie als naive Saw
- Blockgröße ändert das Ergebnis nicht

Envelope-Grundverträge:

- Attack/Decay/Release monoton und zeitlich innerhalb definierter Toleranz
- Sustain stabil, Ausgabe in [0, 1], keine Denormals/NaNs
- Note-Off während Attack startet im selben Eventzeitpunkt Release
- Note-Off während Decay startet sofort Release und beendet nicht erst Decay
- Note-Off während Sustain startet sofort Release
- Release beginnt am aktuellen Pegel ohne Sprung
- Hard Stop endet sicher

Live-Envelope:

- Attack während Attack kürzer und länger stellen: kontinuierlich, kein Reset
- Decay während Decay kürzer und länger stellen: kontinuierlich
- Sustain während Sustain von 0 auf 1 und 1 auf 0: geglättet
- Release 5.0 -> 0.05 s während Release: Tail verkürzt sich deutlich, kein
  Pegelsprung
- Release 0.05 -> 5.0 s während Release: Tail verlängert sich, kein Sprung
- wiederholte schnelle Release-Automation bleibt endlich und endet
- Verhalten bei Buffer 1, 16, 64, 128, 512 vergleichbar
- Note-Off und Parameteränderung im selben Block respektieren Event-Reihenfolge

Voice-Lifecycle:

- maximal 16 Stimmen, keine Allokation
- bei 17. Note wird eine leisere Release-Stimme vor einer lauten Stimme gewählt
- deterministischer Tie-Break
- kein Hanging Voice nach Release, All Notes Off oder Panic
- Voice-Steal-Übergang ohne unzulässige Spitze

Parameter/State/Preset:

- IDs, Bereiche und Defaults exakt
- alte State-Migration und neuer Roundtrip
- Deep Pluck entspricht Defaults
- alle Presets setzen exakte Werte; Custom-Matching korrekt
- Editor-/Presetanzeige verändert State nicht unbeabsichtigt

Headroom und Robustheit:

- 1, 2, 4, 8 und 16 Stimmen bei Factory-Werten
- definierter Worst Case Peak <= 0.95
- keine nicht-finiten Samples
- verschiedene MIDI-Eventpositionen und Buffergrößen

Tests müssen deterministisch, kurz, aussagekräftig und in Debug wie Release
ausführbar sein. Spektraltests mit robusten Toleranzen statt fragiler exakter
Samplevergleiche formulieren.


===============================================================================
20. LISTENING ACCEPTANCE TESTS
===============================================================================

Diese Hörtests sind Pflicht. Automatisierte Tests ersetzen sie nicht.

Testumgebung dokumentieren: Build, Samplerate, Buffergröße, Host/Standalone,
Audiointerface/Kopfhörer oder Monitore und getestetes Preset.

Default Sound:

- direkt nach Laden überzeugender, spielbarer Pluck
- warm, weich, fokussiert, kontrolliert und ausdrucksstark
- kein EQ, Compressor oder Effekt nötig, um brauchbar zu sein
- kein aggressiver Pegel und keine übertriebene Helligkeit

PolyBLEP:

- tiefe, mittlere und hohe Noten gegen V0.2.0a vergleichen
- hohe Noten zeigen weniger aliasartiges Pfeifen/Kratzen
- kein hörbarer Pitch-Fehler, DC-Pop oder neue Mattheit

Attack/Decay/Sustain:

- sehr kurze Attack ohne Click oder übermäßige Transientenspitze
- lange Attack live verkürzen und verlängern: weich und spielbar
- Decay natürlich, nicht mechanisch oder pumpend
- Decay live kurz/lang ändern: kein Sprung
- Sustain live 0 -> 0.5 -> 0: weiche Bewegung

Entdeckte Note-Off-Edge-Cases:

A. Attack 1 s, Taste nach 100 ms loslassen:
   Release beginnt sofort; Attack läuft nicht zum Peak weiter.

B. Decay 500 ms, Sustain 0, Taste nach 100 bis 300 ms loslassen:
   Release beginnt sofort aus dem aktuellen Decay-Pegel. Der übrige Decay wird
   nicht zuerst ausgespielt.

C. Decay 500 ms, Sustain > 0, Taste länger als Decay halten:
   Release beginnt beim Note-Off aus Sustain.

D. Decay 500 ms, Sustain 0, Taste deutlich länger als Decay halten:
   Ist der Pegel bereits 0, bleibt es sauber still; kein künstlicher Tail.

Release live:

E. Release 5 s, Note loslassen, während Tail auf 0.05 s verkürzen:
   Resttail reagiert unmittelbar, wird weich kürzer, ohne Click, Sprung,
   Neustart oder plötzliches hartes Stummschalten.

F. Release 0.05 s, Note loslassen, während Tail auf 5 s verlängern:
   Resttail verlängert sich natürlich ohne Pegelsprung.

G. Release während mehrerer unterschiedlich lauter Stimmen bewegen:
   alle betroffenen Release-Stimmen reagieren stabil und musikalisch.

Velocity/Polyphonie/Stealing:

- Velocities 0.1, 0.25, 0.5, 0.75 und 1.0 sind sinnvoll abgestuft
- 2, 4, 8 und 16 Noten bleiben ausgewogen und clipfrei
- 17. Note löst musikalisch unauffälliges Stealing aus
- keine Clicks, hängenden Noten oder unkontrollierten Peaks

Presets:

- alle vier mit derselben Phrase hören
- jedes trocken brauchbar und klar unterscheidbar
- Deep Pluck liefert beste erste Produktidentität

Langtest:

- fünf Minuten wechselnd kurze/lange Noten, Akkorde, Automation, Stop/Start,
  Sustain-Pedal und All Notes Off
- keine Instabilität, hängenden Stimmen, wachsende CPU-/Speicherauffälligkeit

Ein misslungener verpflichtender Hörtest bedeutet: Milestone nicht fertig.


===============================================================================
21. CUBASE-VALIDIERUNG
===============================================================================

Cubase-Prüfung ist manuell und muss, falls nicht ausgeführt, unter
MANUAL VERIFICATION REQUIRED vollständig aufgelistet werden.

Installation nur manuell nach erfolgreichem Release-Build. Cubase vorher
schließen, vollständiges VST3-Bundle kopieren, danach Rescan und sicherstellen,
dass die aktuelle V0.2.0b-Binary geladen ist.

Pflichtmatrix:

Plugin/GUI:

- laden, entladen, Instanz entfernen, Editor mehrfach öffnen/schließen
- Versionszeile, sechs Controls, Presetauswahl, keine Überlappung
- Editoröffnung verändert State nicht

Audio/MIDI:

- Einzelnoten über relevanten Keyboardbereich
- kurze/lange Noten, schnelle Wiederholungen, gleiche Note wiederholt
- 2/4/8/16/17 Noten, Sustain-Pedal, All Notes Off/Panic
- Stop/Start, Plugin deaktivieren/aktivieren
- keine Clicks, Dropouts, NaNs oder Hanging Notes

Live-Envelope:

- alle Tests A bis G aus Abschnitt 20 in Cubase wiederholen
- insbesondere Note-Off während Attack und Decay
- insbesondere Release 5 s -> 0.05 s und 0.05 s -> 5 s während Tail
- Attack, Decay und Sustain während aktiver Stimmen automatisieren

Automation:

- alle sechs Parameter in Write/Read
- Touch/Latch, soweit angeboten
- Undo/Redo, schnelle Output-/Tune-Bewegungen, Presetwechsel
- Buffer 64, 128, 256 und 512 soweit verfügbar

State/Preset:

- alle vier Presets und Custom
- Projekt speichern, Cubase schließen, neu laden
- V0.2.0a-Projekt öffnen und gespeicherte Werte erhalten
- erneute Presetwahl setzt alle sechs Werte

Audioqualität/Performance:

- Mono/Stereo, Echtzeit und Offline-Bounce
- Bounce reimportieren und auf Artefakte prüfen
- mehrere Instanzen
- Factory-Konfigurationen clippen bei Testphrasen nicht
- Default gegen Sound Manifest bewerten

Ergebnisse als PASS, FAIL oder MANUAL VERIFICATION REQUIRED dokumentieren.


===============================================================================
22. BUILD, ARTEFAKTE UND VERIFIKATIONSABLAUF
===============================================================================

Referenzumgebung aus dem realen Repository ermitteln. Historische Basis:

- Windows 11 x64
- Visual Studio Generator
- C++20
- lokale JUCE-9-Einbindung per add_subdirectory(JUCE)
- Debug und Release
- VST3 und Standalone

Kein FetchContent, Paketmanager, Download oder Projucer-Projekt.

Verbindliche Reihenfolge:

1. Bestandsaufnahme und Dokumentlektüre
2. bestehenden Teststand als Baseline ausführen
3. kleinsten Architekturplan erstellen
4. PolyBLEP mit Tests implementieren
5. Live-Envelope und Note-Off-Verträge mit Tests implementieren
6. Voice-Stealing und Headroom mit Tests implementieren
7. Defaults, Presets und GUI integrieren
8. State-/Automationstests vervollständigen
9. frische Konfiguration, Debug Build und vollständiger Debug CTest
10. Release Build und vollständiger Release CTest
11. Warnungen, Hot Path, Artefakte und Bundles prüfen
12. Standalone-Smoke-Test, soweit sicher automatisierbar
13. Listening Tests und Cubase-Validierung ausführen oder manuell ausweisen
14. Dokumentation, Diff, Status und Definition of Done prüfen
15. erst danach einen fokussierten Milestone-Commit erstellen

Artefakte gemäß bestehender Konvention bereitstellen. Vollständiges VST3-Bundle,
nicht nur eine einzelne Binary. Keine generierten Buildverzeichnisse committen.


===============================================================================
23. DEEPPLUCK STANDARD
===============================================================================

Diese dauerhaften Regeln gelten für diesen und künftige Milestones:

1. DeepPluck ist ein Musikinstrument, keine Technologie-Demo.
2. Jeder Regler hat einen hörbaren musikalischen Zweck.
3. Der Default liefert immer den bestmöglichen ersten Eindruck.
4. Features verbessern Musikalität, Workflow, Klang oder Stabilität.
5. DeepPluck bleibt fokussiert und wird kein General-Purpose-Synth.
6. Trockene Klangqualität hat Vorrang vor Effekten.
7. Presets zeigen musikalischen Nutzen, nicht technische Extreme.
8. CPU-Effizienz zählt, aber nicht auf Kosten hörbarer Qualität.
9. Neue Module integrieren sich ohne Hacks und duplizierte Logik.
10. Jeder Milestone hinterlässt das Projekt sauberer und verständlicher.
11. Realtime-Sicherheit ist absolut.
12. Musikalische Fehler sind echte Fehler, auch wenn Unit-Tests grün sind.


===============================================================================
24. GOLDEN RULES
===============================================================================

1. Realtime safety comes first.
2. Musical quality is equal to technical correctness.
3. The Sound Manifest is mandatory.
4. Note-Off is immediate from every active pre-release stage.
5. Live controls must feel alive, never frozen.
6. Every parameter shall have an audible purpose.
7. Dry sound quality always comes before effects.
8. Default settings shall already sound inspiring.
9. Future compatibility shall be preserved without premature complexity.
10. DeepPluck exists to inspire musicians.


===============================================================================
25. FUTURE ARCHITECTURE RULES
===============================================================================

Künftige Module sollen ergänzt werden können, ohne bestehende DSP-Kerne neu zu
schreiben:

- Filter und Filter-Envelope
- Oscillator 2 und Noise
- Unison
- Modulationsquellen
- FX Rack
- Preset-Browser

Regeln:

- DSP, GUI, Parameter, Presets, Tests und Dokumentation getrennt halten
- neue Oszillatoren ändern nicht die Envelope-Implementierung
- neue Envelopes ändern nicht den Oszillator
- Effekte sind nach der trockenen Voice-/Synth-Engine einfügbar
- Modulation erhält klare Quellen/Ziele und schreibt nicht wild in Voices
- keine monolithischen Klassen oder versteckten globalen Zustände
- keine Abstraktion ohne aktuellen Nutzen; Schnittstellen jedoch bewusst setzen

DeepPluckEnvelope soll langfristig projektspezifische musikalische Kurven,
Retrigger-Modi und weitere Pluck-Eigenschaften kontrolliert unterstützen. Diese
Zukunftsrichtung rechtfertigt heute keine zusätzlichen Hostparameter.


===============================================================================
26. FUTURE EFFECT PHILOSOPHY
===============================================================================

Effekte gehören nicht zu V0.2.0b. Für spätere Milestones gelten dauerhaft:

1. Jeder Effekt besitzt einen eigenen Wet/Dry-Regler. Kein Effekt ist nur als
   vollständig nasser Zwangspfad ausgelegt.

2. Der Benutzer kann die Reihenfolge der Effekte konfigurieren. Routing wird
   explizit, speicherbar und nachvollziehbar; keine versteckte feste Reihenfolge
   als dauerhafte Architekturannahme.

3. Das FX-Routing besitzt eine Reset-Funktion, die eine dokumentierte sinnvolle
   Standardreihenfolge wiederherstellt.

4. Reset betrifft Routing/FX-Defaults kontrolliert und darf nicht ungefragt den
   gesamten Synth-State oder Preset-Sound zerstören.

5. Wet/Dry, Reihenfolge und Reset müssen host-, state- und automationstauglich
   entworfen werden, sobald sie implementiert werden.

6. Bypass und Wet/Dry erzeugen keine Clicks, Phasensprünge oder Tail-Abbrüche.

7. Effekte verbessern einen bereits guten trockenen Sound. Sie kompensieren
   weder Aliasing, schlechte Envelope-Kurven noch falsches Gain Staging.

8. Routing bleibt verständlich. Keine freie modulare Kabelumgebung und keine
   unnötige Komplexität.


===============================================================================
27. REGRESSION POLICY
===============================================================================

Ein früher validierter Vertrag darf nicht stillschweigend regressieren.

Pflicht:

- jeder gefundene Bug erhält, soweit automatisierbar, zuerst oder zusammen mit
  dem Fix einen Regressionstest
- Note-Off-in-Attack, Note-Off-in-Decay und Live-Release werden permanente
  Regressionstests
- bestehende Tests nicht löschen oder lockern, nur weil neuer Code scheitert
- State-, Automation-, Plugin-ID-, Bus- und Preset-Kompatibilität bewahren
- Build und vollständige relevante Tests nach jeder materiellen DSP-Änderung
  erneut ausführen
- Hörregressionen gegen Default, Presets und Sound Manifest dokumentieren
- bekannte manuelle Tests in künftige Milestones übernehmen, bis sie sauber
  automatisierbar sind

Wenn eine bewusste Verhaltensänderung nötig ist, muss sie vorab aus der neuen
Spezifikation folgen, dokumentiert, getestet und migriert werden.


===============================================================================
28. ROADMAP
===============================================================================

Die Reihenfolge ist richtungsweisend, kein Auftrag zum Vorziehen:

V0.2.0b - First Musical Pluck
PolyBLEP, Live Amp Envelope, Note-Off-Korrektheit, musikalisches Voice-Stealing,
Headroom, Defaults und erste Presets.

Nächster fokussierter Klang-Milestone
Musikalischer Filter plus Filter-Envelope, eng am Sound Manifest, ohne FX.

Danach
Oscillator 2/Noise oder Unison, jeweils als eigener mess- und hörbarer Milestone.

Spätere Instrumentreife
Modulationsquellen, ausgereifte DeepPluckEnvelope, Preset-Infrastruktur und
stabiler Workflow.

FX-Phase
Kleines hochwertiges Rack gemäß Future Effect Philosophy: jeder Effekt Wet/Dry,
benutzerkonfigurierbare Reihenfolge, speicherbares Routing und Reset.

Qualitäts-/Performance-Phase
Reproduzierbarer CPU-Benchmark, Profiling unter realistischen Polyphonie-,
Filter-, Unison- und FX-Szenarien; Optimierung nur anhand Messdaten.

V1.0
Ein fokussiertes, stabiles, inspirierendes DeepPluck-Instrument mit eigener
Klangidentität, nicht eine Ansammlung konkurrierender Features.

Jeder Milestone: ein primäres Ziel, stabile Basis, vollständige Regression und
musikalische Abnahme.


===============================================================================
29. STRENGTHENED DEFINITION OF DONE
===============================================================================

V0.2.0b ist nur fertig, wenn ALLE zutreffenden Pflichtpunkte erfüllt sind.

Architektur:

- bestehende V0.2.0a-Basis inkrementell erweitert
- keine unnötige Neuschreibung, keine Kompatibilitätsregression
- klare DeepPluckEnvelope- und Voice-Verantwortung

DSP:

- PolyBLEP implementiert und technisch wie hörend validiert
- Live Attack/Decay/Sustain/Release implementiert
- Note-Off wechselt aus Attack, Decay und Sustain sofort in Release
- Release-Verkürzung und -Verlängerung wirkt auf laufende Releases
- musikalisches deterministisches Voice-Stealing
- Output-Smoothing und Headroom nachgewiesen

Parameter/State/Preset:

- sechs IDs, Bereiche, Automation und Restore korrekt
- neue Defaults und vier Presets exakt
- alte States kompatibel
- Editoröffnung verändert keinen State

Build/Tests:

- frischer Debug- und Release-Build erfolgreich
- VST3 und Standalone erfolgreich
- alle alten und neuen Tests erfolgreich, keine übersprungenen Tests
- keine neuen Compiler-/Linkerwarnungen
- Artefakte vollständig und plausibel

Realtime:

- Audio-Hot-Path geprüft
- keine Allokationen, Locks, Logs, Datei-/Netzwerk- oder GUI-Zugriffe
- bounded, deterministische Arbeit

Musikalische Abnahme:

- verpflichtende Listening Acceptance Tests bestanden
- Default wirkt innerhalb von zehn Sekunden inspirierend
- vier Presets trocken musikalisch brauchbar und unterscheidbar
- keine hörbaren Clicks bei Edge-Cases und Live-Änderungen
- Sound Manifest erkennbar erfüllt, verbleibende filterlose Grenze ehrlich
  dokumentiert

Cubase:

- vollständige Matrix bestanden oder jeder nicht ausgeführte Punkt exakt unter
  MANUAL VERIFICATION REQUIRED ausgewiesen
- ein manueller Pflicht-Fail bedeutet nicht „Completed“

Dokumentation/Git:

- README, ARCHITECTURE und relevante Dokumente aktuell
- keine generierten Dateien oder fremden Benutzeränderungen committed
- fokussierter Commit erst nach automatisierbarer Verifikation
- finaler Status und Commit dokumentiert

Abschlussregel:

Grüne technische Tests allein schließen den Milestone nicht ab. Ein technisch
korrektes, aber hörbar schlechteres oder unmusikalisches Ergebnis ist nicht
fertig. Technische Korrektheit und musikalische Qualität sind gleich verpflichtend.


===============================================================================
30. FINAL IMPLEMENTATION REPORT
===============================================================================

Der Abschlussbericht muss exakt diese Bereiche enthalten:

1. Overall Result
   COMPLETED oder NOT COMPLETED, mit kurzer Begründung.

2. Starting Point
   realer Ausgangsstand, vorbestehende Änderungen, relevante Abweichungen.

3. Files
   erstellt, geändert, gelöscht; Zweck jeder materiellen Datei.

4. Architecture
   Verantwortungen, Signalfluss, DeepPluckEnvelope, Voice-Lifecycle.

5. DSP and Musical Benefit
   PolyBLEP, Live-Envelope, Note-Off, Voice-Stealing, Gain/Headroom; jeweils
   technische Umsetzung UND musikalischer Nutzen.

6. Sound Manifest
   konkrete Übereinstimmungen, ehrliche Grenzen und Antwort auf die Manifest-
   Frage aus Abschnitt 2.

7. Parameters, State and Presets
   IDs, Defaults, Migration, Automation, vier Presets, Custom-Matching.

8. Realtime Review
   geprüfte Hot Paths, Allokationen, Locks, bounded Work, Denormals.

9. Builds and Artifacts
   genaue Befehle/Umgebung, Debug, Release, VST3, Standalone, Artefaktpfade.

10. Automated Tests
    Suites, Ergebnisse, neue Regressionstests; keine pauschale Aussage.

11. Listening Acceptance
    Umgebung und Ergebnis jedes Tests A bis G sowie Default, PolyBLEP,
    Velocity, Polyphonie, Presets und Langtest.

12. Cubase Validation
    Ergebnis je Gruppe; nicht ausgeführte Punkte unter MANUAL VERIFICATION
    REQUIRED, keine erfundenen PASS-Werte.

13. Headroom and Performance
    gemessene Peaks, Szenarien, CPU-Plausibilität und bekannte Grenzen.

14. Regression Review
    welche früheren Verträge geprüft wurden und welche permanenten Tests
    hinzugekommen sind.

15. Known Limitations and Technical Debt
    ehrlich, konkret, ohne Scope-Erweiterung zu verstecken.

16. Git
    Commit-Hash, Commit-Message, finaler Status, bewusst nicht gestagte Dateien.

17. Design Review
    - Did the implementation improve musical quality? Why?
    - Did complexity increase, and was it justified?
    - Does it follow the Sound Manifest? How?
    - Would a musician immediately hear or feel the improvement?
    - Keep, refactor or revert? Why?

18. Next Milestone Recommendation
    ein fokussierter nächster Schritt mit Begründung; nichts vorab implementieren.


===============================================================================
31. FEHLERBEHANDLUNG UND ZULÄSSIGE ABWEICHUNGEN
===============================================================================

Bei Fehlern:

1. vollständige relevante Fehlermeldung lesen
2. Ursache bestimmen
3. kleinste fachlich korrekte Änderung vornehmen
4. betroffenen Test erneut ausführen
5. vollständige relevante Debug-/Release-Prüfung wiederholen

Compiler-, Linker- oder Testfehler sind keine externen Blocker. Keine Warnung
deaktivieren, keinen Test entfernen und keine Anforderung umdeuten.

Materielle Abweichungen sind nur zulässig, wenn der reale Code eine
gleichwertige oder bessere, kompatible Integration verlangt. Jede Abweichung
muss im Abschlussbericht enthalten:

- ursprüngliche Anforderung
- reale Ursache
- gewählte Lösung
- technische und musikalische Auswirkung
- Testnachweis

Scope-Erweiterung ist keine zulässige Abweichung.


===============================================================================
32. ABSCHLIESSENDE ARBEITSANWEISUNG
===============================================================================

Lies zuerst, verstehe den realen Stand und schütze vorhandene Arbeit. Plane den
kleinsten kohärenten Eingriff. Implementiere nicht nur mathematisch korrekten
DSP, sondern ein musikalisch reagierendes Instrument.

Die drei wichtigsten Regressionen dieses Milestones sind dauerhaft verboten:

1. Note-Off während Attack wird ignoriert.
2. Note-Off während Decay wartet auf das Decay-Ende.
3. Bereits laufende Release-Stimmen ignorieren eine neue Release-Zeit.

Beende den Auftrag erst, wenn technische und musikalische Definition of Done
erfüllt sind oder ein konkretes externes Hindernis verbleibt. Weise manuelle
Prüfungen ehrlich aus. Liefere danach den vollständigen Final Implementation
Report.

DeepPluck V0.2.0b soll nicht nur funktionieren.
Es soll sich erstmals wie DeepPluck anfühlen.

===============================================================================
END OF DEEPPLUCK V0.2.0b MASTER IMPLEMENTATION SPECIFICATION - REVISION 2
===============================================================================
