FREIGABE: D1 DEVELOPMENT – RUNDE 1

Representation Completion und D1-Präregistrierung sind bestätigt.

Ab jetzt darf D1 gemäß der eingefrorenen Präregistrierung implementiert
werden.

Diese Freigabe gilt ausschließlich für:

D1-Implementierung
+
Development-Runde 1

Sie ist KEINE Freigabe für Runde 2 oder E006.


============================================================
1. PRE-DEVELOPMENT BASELINE
============================================================

Vor jeder Implementierung:

- D0-Hash bestätigen
- D1-Präregistrierungs-Hash erfassen
- Development-Manifest bestätigen
- 96 Development-Darstellungen bestätigen
- E006-Testmanifest und Hashes bestätigen
- aktuellen Quellzustand dokumentieren

Diesen Zustand als:

D1_PRE_DEVELOPMENT_BASELINE

persistieren.

Bei Abweichung:
STOP.


============================================================
2. D1 IMPLEMENTIEREN
============================================================

Implementiere D1 exakt nach der präregistrierten Spezifikation.

Prüfgrenze:

ORIGINALDARSTELLUNG
→ Representation Intake
→ deterministische Interpretation
→ finite_provided_evidence
→ bytegleich eingefrorener D0-Kern
→ Diagnose

Unterstützte Originalformen:

- Baum
- Postfix / Stack
- extensionale Relation


============================================================
3. D0 IST UNANTASTBAR
============================================================

D0 darf nicht:

- verändert
- erweitert
- repariert
- parametrisch angepasst
- ersetzt
- semantisch nachimplementiert

werden.

Der tatsächlich verwendete D0-Kern muss bytegleich dem eingefrorenen
Referenzartefakt entsprechen.

Vor und nach Runde 1 Hash prüfen.


============================================================
4. KEIN FALLSPEZIFISCHER CODE
============================================================

D1 darf keine Regeln enthalten, die aus konkreten Development-Fällen
abgeleitet wurden.

Keine:

- Fall-IDs
- Lookup-Tabellen
- Sonderbehandlungen einzelner Kerne
- Ground-Truth-Abkürzungen
- Generator-B-spezifischen Lösungsmuster

Implementiert werden ausschließlich die präregistrierten
Repräsentationssemantiken.


============================================================
5. IMPLEMENTIERUNG VOR AUSFÜHRUNG EINFRIEREN
============================================================

Nachdem D1 implementiert wurde, aber BEVOR der erste Development-Fall
ausgeführt wird:

- D1-Code hashen
- Konfiguration hashen
- Abhängigkeiten dokumentieren
- Implementierungsbericht erzeugen

Danach D1 für Runde 1 einfrieren.

Keine Änderungen während der 96 Diagnosen.


============================================================
6. DEVELOPMENT RUNDE 1
============================================================

Führe exakt eine vollständige Baseline-Runde aus:

32 Baum
32 Postfix
32 Relation

= exakt 96 Development-Diagnosen.

Jede Darstellung exakt einmal.

Keine Retries.

Keine Reparatur zwischen Fällen.

Keine Änderung nach Teilergebnissen.

Keine vorzeitige Optimierung.


============================================================
7. PRO FALL PERSISTIEREN
============================================================

Für jede der 96 Ausführungen mindestens:

- Fall-ID
- Kern-ID
- Darstellungsart
- Intake-Status
- Interpretationsergebnis
- erzeugtes finite_provided_evidence
- Zertifikatsvergleich der Interpretation
- D0-Ausgabe
- epistemische Bewertung
- Fehlerklasse
- Laufstatus

Rohresultate unverändert persistieren.


============================================================
8. FEHLERLOKALISATION
============================================================

Fehler mindestens trennen in:

INTAKE_ERROR

INTERPRETATION_ERROR

INTERNAL_EVIDENCE_MISMATCH

EPISTEMIC_ERROR_AFTER_CORRECT_INTERPRETATION

TECHNICAL_INVALID

Keine Fehlerklassen zusammenlegen.


============================================================
9. CROSS-REPRESENTATION-AUSWERTUNG
============================================================

Nach Abschluss aller 96 Fälle pro semantischem Kern vergleichen:

TREE
POSTFIX
RELATION

Berichten:

- Interpretation 3/3 äquivalent?
- interne Evidenz 3/3 semantisch äquivalent?
- epistemische Diagnose 3/3 konsistent?
- alle drei korrekt?

Gesamt:

X/32 Kerne vollständig repräsentationsinvariant.


============================================================
10. D0-REGRESSION
============================================================

Führe anschließend ausschließlich die präregistrierte Regression mit den
48 historischen Pilotfällen durch.

Keine neuen Regressionsfälle.

Prüfe:

D1/D0-Verhalten gegen den historischen Referenzzustand.

Berichten:

X/48 identisch.

Jede Abweichung einzeln dokumentieren.


============================================================
11. KRITISCHE STOP-REGEL
============================================================

Wenn ein Development-Fall:

- korrekt eingelesen wurde,
- korrekt interpretiert wurde,
- korrektes finite_provided_evidence erzeugt,

aber anschließend eine falsche epistemische Entscheidung entsteht:

als

EPISTEMIC_ERROR_AFTER_CORRECT_INTERPRETATION

klassifizieren.

NICHT reparieren.

NICHT D0 verändern.

Keine Runde 2 beginnen.

Dieser Befund kann bedeuten:

D1 REPRESENTATION EXTENSION NOT SUFFICIENT.


============================================================
12. NACH RUNDE 1 KEINE REPARATUR
============================================================

Nach vollständiger Auswertung:

NICHT:

- Code ändern
- Parser korrigieren
- Interpretation korrigieren
- Runde 2 starten
- einzelne Fälle erneut ausführen

Auch dann nicht, wenn die Ursache offensichtlich erscheint.

Die erste Baseline muss unverändert erhalten bleiben.


============================================================
13. E006 BLEIBT VOLLSTÄNDIG VERSIEGELT
============================================================

Die 60 E006-Testdatensätze dürfen nicht:

- ausgeführt
- diagnostiziert
- für Debugging verwendet
- für D1-Entwicklung gelesen
- transformiert
- probeweise verarbeitet

werden.

Auch keine einzelne Datei als Smoke-Test.


============================================================
14. AUDIT NACH RUNDE 1
============================================================

Prüfe:

- exakt 96 Development-Ausführungen
- jede Development-Darstellung exakt einmal
- keine Retries
- keine Zwischenänderung an D1
- D0 hashgleich
- Development-Daten unverändert
- E006-Test hashgleich
- keine SEARCH-Aufrufe
- keine Memory-Rückschreibung
- keine Testzugriffe


============================================================
15. BERICHT
============================================================

Bericht mindestens:

A. D1-Implementierung

B. verwendete präregistrierte Architektur

C. Pre-development Hashzustand

D. Pre-run D1-Hash

E. 96/96 Ausführungsstatus

F. Ergebnisse nach Darstellung:
   - Baum
   - Postfix
   - Relation

G. Interpretationsergebnisse

H. epistemische Ergebnisse

I. X/32 vollständig korrekte Kerne

J. Cross-Representation-Konsistenz

K. D0-Regression X/48

L. vollständige Fehlerliste

M. Auditstatus

N. unveränderte E006-Hashes

O. Einordnung ausschließlich gemäß Präregistrierung


============================================================
16. ABSOLUTER STOP
============================================================

Nach Runde 1 und Audit:

STOP.

Keine Reparatur.

Keine Development-Runde 2.

Keine E006-Ausführung.

Auf menschliche Freigabe warten.


============================================================
ERFOLGSDEFINITION DIESER PHASE
============================================================

Nicht:

"D1 erreicht 100 %."

Sondern:

"Die präregistrierte Erstimplementierung von D1 wurde einmalig und
unverändert gegen den vollständigen Development-Satz gemessen, und ihr
Fehlerprofil ist reproduzierbar dokumentiert."