D1 – Präregistrierung abgeschlossen, STOP

Diese Phase liefert ausschließlich Architekturspezifikation, Development-Vertrag, fixes Budget, Acceptance Criteria, D0-Regressionsplan und Auditplan. Kein D1-Code und keine Development- oder Testausführung.

Die Prüfgrenze umfasst vollständige Originaldarstellung, Interpretation, interne Evidenz und epistemische Diagnose. Interne Kanonisierung ist erlaubt. Ein externer Ersatz der Originalformen vor dem geprüften System ist ausgeschlossen. D0 bleibt bytegleich eingefroren und wird als epistemischer Kern wiederverwendet; keine neue Known/Unknown-Logik.

Der menschlich gesondert freigegebene isolierte Testautor hat die fehlenden Development-Repräsentationen ergänzt. Das Präregistrierungsroster bindet jetzt genau 96 zertifizierte Darstellungen aus denselben 32 Kernen: jeweils Baum, Postfix und Relation. Die 64 Zusätze sind klar als nachträgliche Development-Artefakte ausgewiesen; die ursprünglichen Dateien bleiben unverändert. D1-Entwicklung hat diese Daten nicht entworfen. Manifest- und Einzelobjekthashes sowie konkrete Reihenfolge sind fixiert.

Development-Budget: maximal drei Runden (Erstimplementierung plus höchstens zwei Reparaturrunden), maximal 96 Originalform- und 48 historische native Regressionsdiagnosen je Runde, höchstens 432 Diagnoseversuche insgesamt. Je Payload/Runde ein Versuch, keine fallweise Reparatur. Unveränderte vorhandene Limits: 5 Sekunden pro Diagnose einschließlich Interpretation, maximal 65.536 Input- und 262.144 Outputbytes, höchstens 32 interne Evidenzfaktoren, 16 Variablen und Domaingröße 3. Kein SEARCH, Memory oder Task-Lösungsjob.

Vier separate Acceptance-Achsen: Representation Correctness 96/96; Epistemic Correctness 96/96; D0-Regression vollständiger Antworten 48/48; Cross-Representation Consistency 32/32 Tripel. Gleiche falsche Antworten sind kein Erfolg. Die Einheit unabhängiger Development-Evidenz sind 32 Kerne, nicht 96 Darstellungen.

Nur nachgewiesene Implementationsfehler des neuen Intake/der formalen Interpretation sind reparierbar. Kriterien, Formate, Daten, epistemischer Kern und Limits bleiben fix. Eine notwendige semantische Kernänderung führt unmittelbar zu D1 REPRESENTATION EXTENSION NOT SUFFICIENT. Leakage, unklare Referenz, Integritätsbruch oder ausgeschöpftes Budget führen ebenfalls STOP herbei.

Der D0-Regressionsplan bindet genau die 48 bereits ausgeführten historischen Pilotfälle samt Input-/Rohresultathashes. Er verwendet keine Generator-B/E006-Testfälle. Die 60 versiegelten E006-Datensätze bleiben jedem Prüfling vorenthalten. Ihre Ground Truth darf nicht zur Implementation verwendet werden. Development-private Daten gehören ausschließlich zur Auditseite, nicht zum Prüfling oder zur Intake-Konstruktion.

Alle Runden, Fehler und begründeten Reparaturen müssen später getrennt und unveränderlich persistiert werden. Erfolge überschreiben keine Fehler. Die Zugriffskontrolle wird mit ihren tatsächlichen Grenzen dokumentiert; geteilte Filesystemrechte werden nicht als OS-Isolation dargestellt.

Erfolg dieser Phase ist der fixierte, prüfbare Entwicklungsvertrag. Er ist weder 'D1 funktioniert' noch 'E006 PASS'. Alle vier Acceptance-Achsen sind NOT RUN. Erst nach ausdrücklicher separater Freigabe darf die Implementation und ausschließlich registrierte Development-Ausführung beginnen. Der E006-Test benötigt in jedem Fall eine weitere eigene Freigabe.

STOP.
