GENERATOR-B DEVELOPMENT REPRESENTATION COMPLETION

Auftrag und Identität
Version: egb-development-representation-completion-v1.
Bestehender Eingabevertrag: egb-finite-boolean-v1, unveränderte Operatorsemantik.
Dies ist eine neue, gesondert autorisierte Ergänzung durch denselben ursprünglichen
Generator-B-Testautor. Die 64 zusätzlichen Development-Darstellungen gehören
nicht zum ursprünglichen eingefrorenen Artefaktsatz. Es entstehen keine neuen
semantischen Kerne, Fälle mit geänderter Evidenz, Claims, Ground Truth oder Labels.

Quellen und Transformationslogik
Allein die bestehenden 32 Development-Eingaben, privaten Development-Daten und
der Development-Index sind semantische Datenquellen. Ihre vollständigen Dateien
werden bytegleich in archive/ übernommen. Eigene eingefrorene Vertrags-, Methodik-
und Grenzendokumente werden ebenfalls unverändert archiviert. Die neue Freigabe
wird bytegleich als ORIGINAL-INSTRUCTION.txt archiviert.

Aus generate.py werden ausschließlich die bestehenden Funktionsdefinitionen
evaluate, support und encode unverändert extrahiert. format-functions.py enthält
diese Definitionen und das benötigte Standardbibliotheksimport itertools.
Aus verify.py werden ausschließlich require, formula_mask, indexes und check_case
unverändert extrahiert. formal-functions.py enthält nur diese Definitionen.
Die vollständigen alten Module werden nicht ausgeführt. Insbesondere werden
weder development(), build(), sealed_tests(), test_families() noch verify(root)
der alten Module aufgerufen. Kein Testkorpus wird geöffnet oder erzeugt.
Die neuen Quelltexte enthalten keine Testkonstruktion und keinen Zielzugriff.
Quellfile- und Funktionshashes sowie Auswahlnamen stehen in SOURCE-PROVENANCE.json.

Deterministische Konstruktion
Jedes ursprüngliche Baumobjekt wird unverändert im neuen Eingabearray übernommen.
Die ursprüngliche case_id bleibt für diese klar ausgewiesene Kopie erhalten.
Für jeden bestehenden Kern werden genau zwei weitere Objekte erzeugt. Unverändert
bleiben contract, universe, Atome und Atomreihenfolge, Evidenzanzahl und -reihenfolge
sowie Evidenz-/Claimsemantik. Nur case_id und die Form der Formelcodierung samt
evidence.representation wechseln für die neuen Darstellungen.

Postfix ist die bestehende Postorder-Codierung jeder Originalformel: Referenzen
werden push-Tokens, danach folgen Operator-Tokens mit Arity und unveränderten
Parametern. Die festgelegte Operandenreihenfolge wird erhalten. Die strukturelle
Rücktransformation ergibt zusätzlich exakt dieselben Originalbäume.

Relation ist die bestehende extensionale Codierung jeder einzelnen Originalformel.
Der Scope folgt der ursprünglichen Universumsreihenfolge auf den Formelatomen.
true_rows enthält genau die lokalen Belegungen, bei denen die Originalformel wahr
ist, in der vorhandenen deterministischen Produktreihenfolge false vor true.
Einzelne Evidenzconstraints bleiben getrennt. Der Claim wird separat codiert.
Verlustfreiheit bedeutet hier die exakt erhaltene Wahrheitsfunktion jeder Formel
auf sämtlichen vollständigen Welten. Eine Relation allein hat keine eindeutige
syntaktische Baumumkehrung; die unverändert archivierten Originalobjekte und
Zuordnungen bewahren außerdem die vollständige ursprüngliche Problemstruktur.

IDs, Konfiguration und Zeit
Neue IDs: BDRC- plus die ersten 24 Hexzeichen des SHA-256 des kanonischen JSON-
Arrays [completion_version, original_case_id, representation]. Hashserialisierung:
UTF-8, sort_keys=true, ensure_ascii=false, indent=2, abschließendes einzelnes LF.
Originale IDs, neue IDs, Darstellungsart und original_core_id werden im separaten
development/representation-index.json geführt, nicht als neue semantische
Inputfelder. Es wird kein Zufall verwendet und kein Seed benötigt. Der bekannte
ursprüngliche Development-Seed ist lediglich archivierte Provenienz; er wird
nicht zur Generierung neuer Kerne verwendet. Die Herstellungszeit steht in
SOURCE-PROVENANCE.json, die Versiegelungszeit in SEAL.json. Zeitangaben gehören
zur Verpackung, nicht zur Transformationsentscheidung.

Formale Validierung
Der originale bitparallele Prüfer wertet jeden einzelnen Constraint und den Claim
in allen drei Formen über alle 16 bzw. 32 vollständigen Development-Welten aus.
Die Wahrheitsmasken jeder Formel müssen paarweise identisch sein; geprüft wird
mehr als lediglich die Gleichheit des abschließenden epistemischen Labels.
Die vollständigen ursprünglichen privaten Development-Welten, Survivor-Schritte,
Weltpartitionen und Zeugen müssen für jede Darstellung unverändert gültig sein.
Nur case_id und representation werden zur lokalen Prüferzuordnung neu annotiert;
private semantische Felder werden nicht verändert oder neu erzeugt.

Ein Zertifikat pro Originalkern enthält sämtliche Formelwahrheitsmasken, die
gleichen admissiblen Welten, die Claimpartitionen und Referenzen/Hashes der
unveränderten ursprünglichen Ground Truth und Labels. Damit gibt es genau
32 Zertifikate und 96 geprüfte Eingabeobjekte. Die neuen Tripel sind reine
Darstellungszuordnungen, keine neuen Minimalpaare oder semantischen Varianten.

Zwei unabhängige reine Completion-Aufrufe aus denselben archivierten Objekten
werden byteweise für sämtliche fünf Ergebnisdateien verglichen. Die gespeicherten
Dateien werden danach gegen eine solche exakte Rekonstruktion zurückgelesen.
Es wird keine ursprüngliche Korpusgenerierung oder vollständige Korpusprüfung
ausgeführt. REPRODUCTION-REPORT.json bindet die reproduzierten Payloadbytes.

Transport und Hashes
development/inputs.json enthält genau 96 eindeutige Darstellungseinträge, davon
32 unveränderte Originalbaumobjekte und 64 neue Darstellungseinträge.
archive/original-development-inputs.json ist zusätzlich die bytegleiche Archivkopie
der ursprünglichen Liste mit ihren 32 Objekten. Diese Archivkopie sind keine
weiteren Development-Darstellungen und darf nicht zusätzlich gezählt werden.
development/representation-index.json und das Manifest hashen sämtliche 96
Inputobjekte anhand der festgelegten kanonischen Serialisierung. Originalfilehashes
und Originalobjekthashes sind getrennt dokumentiert. Alle Code-, Archiv-, Prüf-,
Konfigurations-, Zertifikats- und Dokumentationsdateien erhalten außerdem Filehashes.

MANIFEST.json bindet alle Payloadfiles einschließlich ACCESS-LEDGER.json und alle
96 Objekthashes. SEAL.json bindet den Manifesthash. SHA256SUMS.txt bindet die
Payloads sowie Manifest und Seal; der Hash dieses äußeren Hashverzeichnisses wird
separat im Handoff genannt. Damit entstehen keine rekursiven Selbsthashbehauptungen.
Nach der Versiegelung werden durch diesen Autor keine Dateien mehr verändert.

Nur lesbare erneute Prüfung in einer gesondert autorisierten Empfangsprüfung:
python3 -B -I -S completion.py verify
Nur lesbare erneute deterministische Rekonstruktion und Gleichheitsprüfung:
python3 -B -I -S completion.py reproduce
Beide Kommandos lesen ausschließlich die neuen Archive/Formatfunktionen und
Development-Ergebnisse. Sie schreiben weder Payloads noch den eingefrorenen
Autorledger. Eine empfangende Instanz führt hierfür ihren eigenen Zugriffsaudit.
Diese Dokumentation ist keine Freigabe zur jetzigen Ausführung durch einen Prüfling.

Nach Handoff STOP. Keine Implementierung oder Ausführung von D1 oder anderem
Prüfling, keine Weitergabe einer Development-Darstellung an einen Prüfling.
