FREIGABE:
GENERATOR-B DEVELOPMENT REPRESENTATION COMPLETION

ZIEL

Vervollständige ausschließlich die Repräsentationen der bereits bestehenden
32 Generator-B-Development-Kerne.

Keine neuen semantischen Problemkerne erzeugen.

Der versiegelte E006-Test bleibt unangetastet.


1. AUTORSCHAFT

Bevorzugt soll dieselbe isolierte Generator-B-Autorinstanz bzw. deren
eingefrorene Generatorlogik die zusätzlichen Darstellungen erzeugen.

Die D1-Entwicklungsinstanz darf die zusätzlichen Development-Darstellungen
nicht selbst entwerfen.

Generator B erhält keine Informationen über:

- D0
- D1
- Diagnosecode
- Bridge-Analyse
- bisherige Diagnoseergebnisse
- geplante D1-Implementierung


2. AUSGANGSMENGE

Exakt die bestehenden 32 Development-Kerne verwenden.

Für jeden Kern existiert bereits eine Baumdarstellung.

Erzeuge zusätzlich exakt:

- eine Postfix-/Stackdarstellung
- eine extensionale Relationsdarstellung

Damit entstehen:

32 Baum
32 Postfix
32 Relation

= 96 Development-Darstellungen.

Keine zusätzlichen Kerne.


3. SEMANTISCHE IDENTITÄT

Die neuen Darstellungen müssen exakt denselben semantischen Kern und
denselben Claim repräsentieren wie die vorhandene Baumdarstellung.

Nicht verändern:

- Evidenz
- Claim
- Ground Truth
- epistemischen Status
- Problemstruktur

Nur die Repräsentation darf wechseln.


4. KEINE MUTATION ZUR VARIANZERHÖHUNG

Nicht erlaubt:

- neue Distraktoren
- neue Operatoren
- zusätzliche Evidenz
- entfernte Evidenz
- veränderte Claims
- Schwierigkeitsanpassung
- neue Problemvarianten
- neue Minimalpaare

Dies ist ausschließlich Representation Completion.


5. DETERMINISMUS

Die Transformation muss:

- deterministisch
- reproduzierbar
- formal spezifiziert
- verlustfrei

sein.

Seeds und Konfiguration archivieren, soweit relevant.


6. SEMANTISCHE ZERTIFIKATE

Für jeden der 32 Kerne formal prüfen:

TREE ≡ POSTFIX ≡ RELATION

bezüglich:

- Evidenz
- Claim
- Ground Truth
- epistemischer Klassifikation

Die Prüfung darf NICHT durch D0 oder D1 erfolgen.

Sie gehört zu Generator B bzw. dessen unabhängiger formaler Validierung.


7. TESTKORPUS BLEIBT TABU

Unter keinen Umständen:

- einen der 20 versiegelten Testkerne öffnen
- Testdarstellungen neu erzeugen
- Testdaten verändern
- Testdaten gegen D0 oder D1 ausführen
- Test-Ground-Truth für Development verwenden

Die 60 versiegelten Testdatensätze bleiben unverändert.


8. NEUE DEVELOPMENT-ARTEFAKTE

Die zusätzlichen 64 Development-Darstellungen sind neue,
klar gekennzeichnete Development-Artefakte.

Sie dürfen NICHT nachträglich als ursprünglich eingefrorene Generator-B-
Artefakte dargestellt werden.

Provenienz dokumentieren:

- ursprünglicher Development-Kern
- ursprüngliche Baumdarstellung
- erzeugte Postfixdarstellung
- erzeugte Relationsdarstellung
- Generatorversion
- Zeitpunkt
- Hash
- Äquivalenzzertifikat


9. NACH ERZEUGUNG

Nach erfolgreicher formaler Prüfung:

- alle 96 Development-Darstellungen hashen
- Manifest erzeugen
- Development-Satz erneut einfrieren

Danach keine weitere Änderung.


10. NOCH KEIN D1-DEVELOPMENT

Nach Erzeugung der zusätzlichen Darstellungen:

D1 NICHT implementieren.

D1 NICHT ausführen.

Keine Development-Darstellung an D1 übergeben.

Zunächst ausschließlich berichten:

- 32/32 Kerne vollständig?
- 96/96 Darstellungen vorhanden?
- 32/32 semantische Äquivalenzzertifikate bestanden?
- Provenienz vollständig?
- Hashes vollständig?
- versiegelter E006-Test unverändert?


11. STOP

Nach erfolgreicher Representation Completion:

STOP.

Bericht vorlegen.

Erst danach separate Freigabe für die eigentliche D1-Implementierung.
