11 — Bootstrapping, Seeding und Prägung¶

Status: Normativer Konsolidierungsentwurf
Version: 0.2
Geltungsbereich: Jade-VM-Build, Bootstrap Core, Type Engine, Memory Engine, VM-Initialisierung, Plugin Loader
Ergänzt: 00-ontology-types-tags-phantoms.md, 01-refinements-meta-tags.md, 04-axiomatics-truthprofile.md, 07-compilerdb-tag-subsystem.md, 08-grammar-sketch.md, 08-intrinsics-vm-api.md, Plugin-System-Spezifikation

1. Zweck¶

Dieses Kapitel definiert, wie Jade vor dem Laden der Stdlib in einen initial gültigen Zustand versetzt wird.

Der zentrale Begriff ist der Bootstrap Seed.

Der Bootstrap Seed ist kein ausführbares Modul, kein Plugin und keine Stdlib. Er ist die initiale Wahrheitstabelle der Jade VM.

Er beschreibt nicht, was Jade tut. Er beschreibt, was Jade zuerst weiß.

Ohne diese Festlegung bleibt unklar, wie Type Engine, Memory Engine, VM und Plugin Loader überhaupt genug gemeinsame Begriffe besitzen, um die Stdlib zu laden. Genau diese Lücke schließt dieses Kapitel. Man könnte sagen: Die VM bekommt hier ihren ersten Personalausweis, bevor sie anfängt, fremde Programme zu beurteilen. Bürokratie, aber nützlich.

Das Henne-Ei-Problem¶

Jede VM mit einem Typsystem steht vor einem fundamentalen Zirkel: Die Type Engine braucht TypeDescriptors um Typen zu verstehen — aber TypeDescriptors sind selbst typisierte Datenstrukturen. Die Memory Engine braucht Layout-Informationen um Speicher zu verwalten — aber Layout-Informationen setzen Typ-Wissen voraus. Die VM braucht Intrinsic-IDs um Intrinsics aufzurufen — aber Intrinsic-IDs sind erst nach der Registrierung sinnvoll.

Die meisten VMs lösen dieses Problem durch hardcodierte C/C++-Tabellen: die JVM hat eine Menge fest verdrahteter Klassen in hotspot/src/share/vm, die CLR hat einen hardcodierten mscorlib-Bootvorgang, CPython hat object und type als zirkulär erzeugte Singletons. Keine dieser Lösungen ist formal spezifiziert — sie sind historisch gewachsen und schwer zu ändern.

Jade löst den Zirkel durch den Bootstrap Seed: ein versioniertes, validiertes, deterministisch erzeugtes Artefakt das zur Build-Zeit des Jade-Teams aus JDL-Quellcode generiert wird. Der Seed bricht den Zirkel, indem er die erste Wahrheitstabelle liefert — danach können die Subsysteme aufeinander aufbauen, weil sie eine gemeinsame Datenbasis haben.

Architektonische Rolle im Self-Hosting-Modell¶

Der Bootstrap Seed ist nicht nur ein Implementierungsdetail — er ist die architektonische Voraussetzung für Jades Self-Hosting-Vision. Das Ziel ist, dass ~90% von Jade in JDL selbst implementiert werden: Parser, IR-Validatoren, IR-Pass-Pipelines, der Code Generator, Teile des Compilers. Damit das funktioniert, muss die VM beim Start genug über sich selbst wissen, um JDL-Code laden und ausführen zu können — ohne dass dieser JDL-Code bereits geladen ist.

Der Seed ist die minimale Wissensbasis die diesen Sprung ermöglicht. Ohne ihn müsste der gesamte Compiler in D geschrieben sein, weil es kein JDL-fähiges Fundament gäbe auf dem JDL-Code stehen könnte.

Die 24 Intrinsics in 08-intrinsics-vm-api.md sind die stabile D/JDL-Grenze zur Laufzeit. Der Bootstrap Seed ist die stabile D/JDL-Grenze zur Initialisierungszeit. Zusammen bilden sie die beiden einzigen Stellen an denen D und JDL einander berühren.

2. Grundentscheidung¶

Der Bootstrap Core wird als normales JDL-Quellpaket im reservierten Namespace jade::core::bootstrap beschrieben.

Dieses Paket wird nicht beim Benutzer kompiliert.

Es wird ausschließlich während des Jade-VM-Builds im speziellen Build-Ziel BootstrapSeedBuild verarbeitet. Das Ergebnis ist kein ausführbares VM-Artefakt, sondern ein statisches BootstrapSeed-Artefakt, das in die Jade-VM eingebettet wird.

Beim Start der VM wird dieses Artefakt gelesen und zur Initialisierung der Subsysteme verwendet.

Jade-Team Build-Zeit:

    jade::core::bootstrap/*.jdl
        -> normaler JDL Parser / Resolver / Bootstrap-Checker
        -> BootstrapSeedBackend
        -> bootstrap_seed.d oder bootstrap_seed.bin
        -> Einbettung in die VM-Binary

Benutzer-Laufzeit:

    VM startet
        -> eingebetteten BootstrapSeed lesen
        -> Subsysteme prägen / seeden
        -> Plugin Loader starten
        -> Stdlib laden
        -> User-Code laden / kompilieren / ausführen

Warum JDL-Quelle statt hardcodierter D-Tabellen?¶

Die Alternative wäre, die Primitive, Core-Typen und Tag-Domains direkt als D-Datenstrukturen zu definieren — als immutable Arrays in einem D-Modul. Das wäre einfacher, hätte aber drei Nachteile:

Erstens: Duplizierte Wahrheitsquellen. Die Typ-Semantik von i32 wäre einmal in der D-Tabelle definiert und ein zweites Mal implizit in der Type Engine, die diese Tabelle interpretiert. Jede Änderung an der Semantik muss an beiden Stellen nachgezogen werden — und Inkonsistenzen fallen erst zur Laufzeit auf.

Zweitens: Keine Validierung durch den eigenen Compiler. Wenn der Bootstrap Core als JDL-Quelle vorliegt, kann der JDL-Parser und -Resolver ihn syntaktisch und semantisch prüfen. Fehler im Seed werden als Compile-Fehler sichtbar, nicht als mysteriöse VM-Abstürze beim Start. Der Bootstrap-Checker kann zusätzlich strengere Regeln anwenden als der normale Compiler und sicherstellen, dass nur zulässige Konstrukte im Seed landen.

Drittens: Konsistenz mit der Sprachphilosophie. Jade definiert Typen und ihre Semantik in JDL — das gilt für User-Typen, Stdlib-Typen, und mit dem Bootstrap Core auch für die grundlegendsten Primitive. Die Sprache beschreibt sich selbst, soweit es der Zirkel erlaubt.

Normativ:

Der Bootstrap Core ist JDL-Quelle.
Der Bootstrap Core ist kein normales User-Modul.
Der Bootstrap Core wird nur im Jade-Team-Build verarbeitet.
Das erzeugte BootstrapSeed-Artefakt wird beim Benutzer nicht neu kompiliert.
Der Benutzer kann den Namespace jade::core::bootstrap nicht überschreiben oder erweitern.

3. Bootstrapping¶

Bootstrapping bezeichnet den gesamten Vorgang, durch den Jade von einer reinen Host-Engine in einen Jade-fähigen Anfangszustand überführt wird.

Vor dem Bootstrapping existieren die Subsysteme nur als D-Implementierung — leere Datenstrukturen ohne Jade-spezifisches Wissen:

D-Objekte vorhanden:
    TypeEngine         — kann Typen verwalten, kennt aber noch keinen einzigen Typ
    MemoryEngine       — kann Speicher verwalten, kennt aber noch kein Layout
    VM                 — kann Bytecode ausführen, kennt aber noch keine Intrinsics
    PluginLoader       — kann Plugins laden, weiß aber noch nicht was ein Plugin ist
    SymbolRegistry     — kann Symbole zuordnen, hat aber noch keine Zuordnungen
    IntrinsicRegistry  — kann Intrinsics dispatchen, hat aber noch keine Registrierungen

Jade-Welt noch nicht vorhanden:
    keine TypeIds für Primitives
    keine Core-TypeDescriptors
    keine Tag-Domains
    keine Option/Result-Struktur
    keine minimalen Diagnostics
    keine Stdlib

Der Zustand „Constructed" ist ein leeres Gerüst. Die D-Subsysteme sind initialisiert, aber sie können noch keine sinnvolle Jade-Frage beantworten. typeEngine.lookup("i32") wäre ein Fehler, weil i32 noch nicht registriert ist. vm.dispatch(INTRINSIC, subcode, ...) wäre ein Fehler, weil die Intrinsic-Dispatch-Table leer ist.

Nach erfolgreichem Bootstrapping besitzt Jade genug Wissen, um die Stdlib zu laden.

Normativ:

Bootstrapping findet vor dem normalen Plugin-Lifecycle statt.
Bootstrapping lädt kein externes Plugin.
Bootstrapping führt keinen User-Code aus.
Bootstrapping verwendet ausschließlich das eingebettete, vertrauenswürdige BootstrapSeed-Artefakt.
Bootstrapping muss deterministisch sein — identischer Seed produziert identischen Zustand, unabhängig von Plattform oder Startzeitpunkt.

4. Seeding¶

Seeding bezeichnet die konkrete Befüllung der Jade-Subsysteme aus dem BootstrapSeed.

Der Seed enthält kanonische Deskriptoren. Aus diesen Deskriptoren erzeugt der BootstrapInitializer die subsystem-spezifischen Tabellen:

BootstrapSeed
    -> SymbolRegistry.seed(...)       Schritt 1: Namen registrieren
    -> TypeEngine.seed(...)           Schritt 2: Typen, Tags, TypeFns registrieren
    -> MemoryEngine.seed(...)         Schritt 3: Layouts und Policies ableiten
    -> VM.seed(...)                   Schritt 4: PrimitiveOps, Intrinsics, Boundaries
    -> IntrinsicRegistry.seed(...)    Schritt 5: Intrinsic-Dispatch-Table aufbauen
    -> TagEngine.seed(...)            Schritt 6: Tag-Domains für Label-Inferenz

Single Source of Truth¶

Der Seed enthält keine mehrfachen, unabhängig gepflegten Wahrheiten. Er enthält kanonische Deskriptoren, aus denen abgeleitete Tabellen deterministisch erzeugt oder validiert werden.

Ein einzelner PrimitiveDescriptor(i32) liefert alle Informationen die die verschiedenen Subsysteme über i32 brauchen — aber jedes Subsystem extrahiert nur seinen Anteil:

PrimitiveDescriptor(i32)
    -> TypeEngine:   TypeId, TypeDescriptor, PrimitiveClass, Label-Defaults
    -> MemoryEngine: size=4, align=4, representation=Immediate64
    -> VM:           PrimitiveOpClass=SignedInteger, BoundaryClass=Immediate64

Es gibt keine separate D-Tabelle die unabhängig behauptet „i32 ist 4 Bytes groß". Die Memory Engine erhält diese Information ausschließlich aus dem Seed, über den Pfad TypeEngine → computeCoreLayouts() → Memory Engine. Wenn sich die Größe von i32 jemals änderte (auf einer hypothetischen Plattform), müsste nur der Seed-Deskriptor geändert werden — alle Subsysteme würden ihre Tabellen deterministisch daraus ableiten.

Normativ:

Die Type Engine ist die Quelle der Typsemantik. Alle anderen Subsysteme empfangen Typ-Wissen, sie erzeugen es nicht.
Die Memory Engine erhält Speicher-, Layout- und Policy-Informationen, aber keine eigene konkurrierende Typsemantik.
Die VM erhält Repräsentations-, Boundary-, Intrinsic- und Primitive-Operation-Informationen.
Abgeleitete Tabellen müssen deterministisch aus dem Seed erzeugbar sein.
Vor Abschluss des Seedings dürfen normale Compiler-/Runtime-Operationen nicht ausgeführt werden.

5. Prägung¶

Prägung bezeichnet den semantischen Effekt des Seedings.

Der Seed führt nichts aus, aber er prägt Jade mit den ersten Begriffen, über die Type Engine, Memory Engine und VM sprechen können. Die Metapher der Prägung ist bewusst gewählt: wie eine Münze geprägt wird — die Form wird einmal eingedrückt und ist danach stabil. Der Seed verändert sich nach der Initialisierung nicht.

Nach der Prägung kann Jade grundlegende Fragen beantworten:

Was ist i32?                              → TypeDescriptor mit PrimitiveClass(SignedInteger)
Wie groß ist bool?                        → Size(1), Align(1)
Was ist Option[T]?                        → Parametrischer Enum mit Some(T) | None
Was ist Result[T, E]?                     → Parametrischer Enum mit Ok(T) | Err(E)
Welche Tag-Domain enthält Unique?         → OwnPolicy { Unique, Shared, Weak }
Was bedeutet Memory(Value) als Meta-Eintrag? → MemoryPolicy-Tag → Label Memory(Value)
Welche PrimitiveClass hat u64?            → UnsignedInteger
Welche Intrinsic-ID hat jade::vm::trap?   → ID 1, Domain VM
Welche Intrinsic-ID hat jade::vm::spawn?  → ID n, Domain Scheduler

Die Prägung bedeutet ausdrücklich nicht, dass die Stdlib bereits vorhanden ist. Nach der Prägung kann Jade noch nicht notwendigerweise beantworten:

Wie rendere ich einen User?               → braucht Protocol Renderable (Stdlib)
Wie materialisiere ich einen Generator?    → braucht Generator-Framework (Stdlib)
Wie führe ich einen Effect aus?            → braucht Effect-Engine (Stdlib)
Wie öffne ich eine Datei?                  → braucht IO-Subsystem (Stdlib + FFI)
Wie lade ich ein HTTP-Modul?               → braucht Netzwerk-Stack (Plugin/Stdlib)

Diese Fragen gehören zur Stdlib oder zu Plugins. Der Seed liefert die Grammatik, die Stdlib liefert das Vokabular, User-Code schreibt die Sätze.

Prägung der Intrinsics¶

Ein wesentlicher Teil der Prägung ist die Registrierung der 24 Scheduling-, Handle-, Signal-, Introspection-, FFI-, Messaging- und Closure-Intrinsics aus 08-intrinsics-vm-api.md. Der Seed muss für jeden Intrinsic eine IntrinsicDesc enthalten die den Subcode, die Parameter-Typen, den Return-Typ und die CmdDomain festlegt. Erst nach dieser Registrierung kann die VM-Loop den INTRINSIC subcode, a, b, c-Opcode korrekt dispatchen.

Ohne die Intrinsic-Prägung wäre jade::vm::spawn ein unbekanntes Symbol — die Stdlib könnte keine Tasks erzeugen, keine Channels bauen, kein async/await implementieren. Die 24 Intrinsics sind damit ein integraler Bestandteil des Seeds, nicht ein optionaler Komfort.

Merksatz:

Der Bootstrap Seed ist keine Berechnung.
Der Bootstrap Seed ist die erste Datenbasis.

6. Runtime-Stufen¶

Die VM führt intern einen expliziten Initialisierungszustand. Jede Stufe schaltet bestimmte Operationen frei und verbietet vorzeitige Zugriffe:

enum RuntimeStage {
    Constructed,     // D-Subsysteme existieren, Jade-Welt ist leer
    Seeded,          // Core-Deskriptoren geladen, Plugin Loader bereit
    StdlibLoaded,    // Stdlib als privilegiertes Plugin geladen
    Ready            // User-Programme zugelassen
}

Stufenbeschreibung¶

Constructed — Die D-Objekte (TypeEngine, MemoryEngine, VM, PluginLoader, SymbolRegistry, IntrinsicRegistry) sind als D-Structs konstruiert. Ihre internen Tabellen sind leer. Kein Jade-spezifisches Wissen ist vorhanden. Der einzige erlaubte Übergang von hier ist das Seeding.

Seeded — Der BootstrapSeed wurde geladen und validiert. Die Subsysteme kennen jetzt Primitive, Core-Typen, Tags, Intrinsics und Boundaries. Der Plugin Loader darf starten, weil er jetzt die TypeIds und SymbolIds hat die er braucht um Plugin-Module zu interpretieren. Die Stdlib darf als erstes privilegiertes Plugin geladen werden.

StdlibLoaded — Die Stdlib ist geladen. Jade kennt jetzt Protocols (Add, Copyable, Renderable), Collections (Array, Map), das Effect-System, Channels, Actors und alle weiteren Stdlib-Abstraktionen. User-Code der Stdlib-Symbole referenziert (was fast jeder User-Code tut, allein durch das Prelude) darf jetzt kompiliert werden.

Ready — User-Programme dürfen geladen, kompiliert und ausgeführt werden. Dies ist der normale Betriebszustand der VM. Alle Subsysteme sind vollständig initialisiert, der RuntimeBus ist aktiv, der Scheduler läuft.

Stufenwächter¶

Normativ:

PluginLoader.start vor Seeded ist ein harter Fehler — der Loader kann ohne TypeIds und SymbolIds keine Module interpretieren.
Stdlib.load vor Seeded ist ein harter Fehler — die Stdlib referenziert Core-Typen wie Option[T] die erst nach dem Seeding existieren.
UserCode.compile vor StdlibLoaded ist ein harter Fehler, sofern der Compile-Pfad Stdlib-Symbole oder Prelude-Symbole benötigt.
Subsystem-Queries, die Seed-Daten voraussetzen, sind vor Seeded unzulässig.
RuntimeStage-Übergänge sind strikt monoton: Constructed → Seeded → StdlibLoaded → Ready. Kein Rücksprung, kein Überspringen.

Fehlerszenarios¶

Ein Seed-Validierungsfehler in der Constructed → Seeded-Transition ist ein harter VM-Startfehler — die VM kann nicht starten, weil ihre Wissensbasis beschädigt oder inkompatibel ist. Der Benutzer sieht eine Diagnostic wie BOOT-SEED-001: Seed schema version mismatch und muss die VM-Installation reparieren.

Ein Stdlib-Ladefehler in der Seeded → StdlibLoaded-Transition ist ebenfalls ein harter Fehler — ohne Stdlib ist Jade nicht nutzbar. Externe Plugins hingegen dürfen in der StdlibLoaded → Ready-Transition fehlschlagen, ohne die VM zu crashen — ein fehlendes optionales Plugin ist ein Diagnostic, kein Startfehler.

7. BootstrapInitializer¶

Der BootstrapInitializer ist der D-seitige Initialisierungspfad, der das eingebettete Seed-Artefakt liest und die Jade-Subsysteme befüllt.

Konzeptionell:

void initializeBootstrap(ref JadeRuntime rt) {
    assert(rt.stage == RuntimeStage.Constructed);

    // 1. Seed laden und gegen Schema-Version validieren
    auto seed = embeddedBootstrapSeed();
    validateSeed(seed);

    // 2. Symboltabelle — muss zuerst stehen, weil TypeEngine
    //    Symbole referenziert (z.B. "i32", "Option", "Result")
    rt.symbols.seed(seed.symbols);

    // 3. Type Engine — Primitives, Core-Typen, Tags, TypeFns
    //    Die Type Engine ist die Quelle der Typsemantik.
    rt.typeEngine.seed(seed.types, seed.primitives);
    rt.typeEngine.seedTags(seed.tags, seed.tagDomains);
    rt.typeEngine.seedTypeFns(seed.typeFns);

    // 4. Layouts — deterministisch aus Type Engine berechnet,
    //    nicht separat im Seed gespeichert (Single Source of Truth)
    auto layouts = rt.typeEngine.computeCoreLayouts();

    // 5. Memory Engine — erhält Layouts und Policies
    //    Keine eigene Typsemantik, nur Speicher-/Allokationswissen
    rt.memoryEngine.seed(layouts, seed.memoryPolicies);

    // 6. VM — PrimitiveOps, Intrinsics, Boundaries
    //    Damit kann die VM-Loop Bytecode für Core-Operationen ausführen
    rt.vm.seed(seed.primitiveOps, seed.intrinsics, seed.boundaries);

    // 7. Stage-Transition
    rt.stage = RuntimeStage.Seeded;
}

Reihenfolgenabhängigkeiten¶

Die Seeding-Reihenfolge ist nicht beliebig — sie folgt einer Abhängigkeitskette:

Symbole zuerst — Die Type Engine referenziert Symbole per SymbolId. Ohne registrierte Symbole kann sie keine Typen benennen.
Types vor Layouts — Layouts werden aus TypeDescriptors berechnet. Die Type Engine muss die Deskriptoren kennen bevor sie Layouts ableiten kann.
Layouts vor Memory Engine — Die Memory Engine braucht Size/Align-Informationen um Allokationsstrategien zuzuordnen.
Intrinsics vor VM-Ready — Die VM-Loop braucht die Intrinsic-Dispatch-Table bevor sie einen INTRINSIC-Opcode korrekt verarbeiten kann.

Ein Verstoß gegen diese Reihenfolge ist kein undefiniertes Verhalten — es ist ein deterministischer Fehler, weil die D-Subsysteme bei Zugriff auf nicht-gesetzte Tabellen trappen.

Der konkrete D-Code ist Implementierungsdetail. Normativ ist die oben beschriebene Reihenfolge und die Invariante, dass jede abgeleitete Tabelle deterministisch aus dem Seed erzeugbar sein muss.

8. RuntimeBus-Bezug¶

Der BootstrapInitializer ist nicht der normale RuntimeBus.

Der RuntimeBus arbeitet innerhalb einer bereits initialisierten Runtime-Welt. Er ist für Runtime-Commands zuständig — typisierte Structs die über rt.cmd(...) dispatcht werden, mit Routing über CmdDomain an die zuständigen Ports (JmePort, SchedulerPort, SignalPort etc.). Der BootstrapInitializer baut diese Welt erst auf.

Normativ:

Tags und Tag-Domains bleiben compile-time-only und gehören in Type Engine / CompilerDb, nicht in den RuntimeBus.
Der BootstrapInitializer darf Subsysteme direkt initialisieren, bevor der RuntimeBus aktiv ist.
Nach Seeded dürfen spätere runtime-relevante Registrierungen über RuntimeBus oder Plugin-Lifecycle laufen.

Begründung:

Der RuntimeBus selbst setzt ein Mindestmaß an initialisierten Subsystemen voraus — allein die CmdDomain-Enum-Auflösung braucht die registrierten Ports. Ihn für seine eigene erste Existenz zu verwenden wäre elegant im selben Sinn, in dem ein Kreisverkehr im Wohnzimmer elegant ist.

Übergang zum RuntimeBus nach Seeding¶

Nach Seeded ist der RuntimeBus aktiv und übernimmt alle weitere Kommunikation. Wenn die Stdlib als Plugin geladen wird, registriert sie neue Typen, Protocols und Funktionen — diese Registrierungen laufen über den normalen Plugin-Lifecycle, nicht über den BootstrapInitializer. Der Initializer hat nach der Seeded-Transition seine Arbeit getan und wird nicht erneut aufgerufen.

Spätere Operationen wie jade::vm::spawn (Task erzeugen), jade::vm::pin (Handle schützen), oder jade::vm::signal_register (Event-Handler registrieren) sind Runtime-Commands die über den RuntimeBus laufen — aber sie setzen alle voraus, dass die Intrinsic-Dispatch-Table bereits durch den Seed befüllt wurde.

9. Inhalt des Bootstrap Seeds¶

Der Bootstrap Seed enthält nur transitive Notwendigkeiten für:

Initialisierung von Type Engine, Memory Engine und VM.
Start des Plugin Loaders.
Laden der privilegierten Stdlib.

Zulässige Inhalte¶

PrimitiveDescriptoren — bool, i8..i64, u8..u64, f32, f64, str, (). Das sind die Typen deren Semantik nicht in JDL ausdrückbar ist, weil sie auf direkten VM-Operationen aufbauen.
Minimale Core-TypeDescriptoren — TypeId, SymbolId, HandleId. Interne Identifikatoren die die Subsysteme brauchen um über Typen, Symbole und Handles sprechen zu können.
Core-Symbol-IDs — Symbolnamen für Primitive und Core-Typen, damit die Type Engine sie per Name auflösen kann.
Option[T] und Result[T, E] — Unverzichtbar weil der Plugin Loader und die Type Engine selbst fehlbare Operationen haben und deren Ergebnisse typisiert ausdrücken müssen.
Minimale Diagnostic-/Error-Codes — BootstrapDiagnostic, Severity, BootstrapPhase. Damit Fehler beim Laden der Stdlib strukturiert reportet werden können, bevor die Stdlib selbst existiert.
Tag-Domains — OwnPolicy { Unique, Shared, Weak }, SharePolicy { Local, Send, Sync }, MemoryPolicy { Value, Rc, Arena, Pool }, DropKind { Trivial, Custom }. Die Label-Inferenz (04a-label-inferenz-regeln.md) braucht diese Domains um Strukturregeln und Kombinationsregeln anwenden zu können. Ohne sie könnte der Compiler kein Memory(Value) von Memory(Rc) unterscheiden.
TypeFns — PrimitiveClass(kind), Bits(n), Size(n), Own(policy), Share(policy), Memory(policy), Drop(kind) etc. Meta-Record-Fragmente die der Compiler braucht um Typ-Deklarationen zu interpretieren.
Intrinsic-IDs und PrimitiveOp-IDs — Die 24 Intrinsics aus 08-intrinsics-vm-api.md müssen mit IDs und Signaturen registriert sein, damit der Compiler @intrinsic-Annotationen auflösen und die VM die Dispatch-Table aufbauen kann. PrimitiveOps (i32.add, u64.mul etc.) müssen auf VM-bekannte Operationsklassen abgebildet sein.
Boundary-/Representation-Klassen — Immediate64, InlineValue, Handle. Die VM braucht diese Klassen um zu wissen wie Werte an Call-/Return-/FFI-Grenzen repräsentiert werden.

Nicht zulässige Inhalte¶

Collections wie Array, Map, Set — gehören in die Stdlib.
Generator / Collect — gehören in die Stdlib.
Services — gehören in die Stdlib.
Effect-Komposition — gehört in die Stdlib.
Wire/Serde — gehört in die Stdlib.
FFI-Deklarationen — gehören in die Stdlib.
Allgemeine Protocol-Implementierungen — gehören in die Stdlib.
Komfortfunktionen — gehören in die Stdlib.
Normale User-Funktionskörper — der Seed erzeugt Deskriptoren, keinen ausführbaren Code.
Logging, IO, HTTP, Scheduler-Komfort — gehören in die Stdlib oder in Plugins.

Entscheidungsregel¶

Wenn der Plugin Loader ohne X nicht starten kann, gehört X möglicherweise in den Seed.
Wenn X nur bequem wäre, gehört X nicht in den Seed.

Komfort ist der natürliche Feind jedes Bootstraps. Das klingt theatralisch, ist aber leider wahr. Jeder Typ der in den Seed wandert, weil "er ja eh gebraucht wird", macht den Seed schwerer zu validieren, schwerer zu versionieren, und — wenn er sich als falsche Abstraktion herausstellt — schwerer zu ändern, weil er in die VM-Binary eingebettet ist. Der Seed ist die härteste Schicht des Systems. Was hier drin steht, steht fest.

10. Bootstrap Core als JDL-Quelle¶

Der Bootstrap Core liegt im reservierten Namespace:

module jade::core::bootstrap

Er darf normale JDL-Syntax verwenden, soweit diese im BootstrapSeedBuild-Modus zugelassen ist.

Bootstrap-Checker-Einschränkungen¶

Der Bootstrap-Checker darf strengere Regeln anwenden als der normale Compiler. Die folgenden Einschränkungen sind architektonisch motiviert — der Seed soll Deskriptoren erzeugen, nicht Programme:

Keine Funktionskörper — Der Seed deklariert Typen und Metadata, er implementiert keine Logik. Funktionssignaturen für Intrinsics sind erlaubt (sie beschreiben die Schnittstelle), aber Funktionskörper sind es nicht.
Keine Closures — Closures haben Captures, und Captures setzen ein laufendes Typsystem voraus das die Capture-Umgebung analysieren kann. Zur Seed-Zeit existiert dieses Typsystem noch nicht.
Keine Effekte — Das Effect-System ist eine Stdlib-Abstraktion die auf dem Seed aufbaut, nicht umgekehrt.
Keine provide-Blöcke — Protocol-Implementierungen sind Stdlib-Territorium.
Keine with-Blöcke — Arena-Scoping und Ressourcen-Management setzen eine laufende Runtime voraus.
Parametrische Typen nur für Option[T] und Result[T, E] — Allgemeine Generics setzen die vollständige Type Engine voraus. Option und Result sind explizite Ausnahmen weil sie für den Plugin Loader unverzichtbar sind.

Normativ:

Der normale JDL-Parser darf zur Verarbeitung des Bootstrap Core verwendet werden.
Der Bootstrap Core ist dennoch kein normales User-Paket.
Der Bootstrap-Checker darf die oben genannten Einschränkungen erzwingen.
Nur das Backend BootstrapSeedBackend darf aus diesem Paket ein Artefakt erzeugen.
Der normale VM-/Bytecode-Generator ist für den Bootstrap Core nicht das primäre Ziel.

Der Bootstrap Core ist also keine zweite Sprache. Er ist ein reservierter, privilegierter Build-Kontext — dieselbe Grammatik, strengere Regeln, anderes Backend.

11. BootstrapSeedBackend¶

Das BootstrapSeedBackend ist ein spezielles Generator-Backend.

Input: Typed AST / TypeDescriptors / Meta-normalisierte Core-Definitionen aus dem Bootstrap-Checker.

Output: Ein statisches Seed-Artefakt, entweder als D-Modul oder als Binärblob.

Das Backend erzeugt kein ausführbares VM-Modul. Es erzeugt keine Protos, keinen Bytecode, keine Callstacks. Es erzeugt Tabellen.

Ausgabeformat: D-Modul¶

module jade.bootstrap_seed;

// Generiert aus jade::core::bootstrap/*.jdl
// Schema-Version: 3
// Jade-Version: 0.1.0
// Descriptor-Hash: 0xA3F7...

immutable PrimitiveDesc[] primitiveDescs = [ ... ];
immutable TypeDesc[]      typeDescs      = [ ... ];
immutable TagDesc[]       tagDescs       = [ ... ];
immutable TypeFnDesc[]    typeFnDescs    = [ ... ];
immutable IntrinsicDesc[] intrinsicDescs = [ ... ];
immutable SymbolDesc[]    symbolDescs    = [ ... ];

Vorteil: Compile-Zeit-Verifikation durch D-Compiler. Typfehler in Deskriptoren werden beim VM-Build erkannt. Kein Runtime-Parsing nötig.

Ausgabeformat: Binärblob¶

BootstrapSeedBlob
    magic:           "JADE" (4 Bytes)
    schemaVersion:   u32
    jadeVersion:     u32[3]  (major, minor, patch)
    descriptorHash:  u64     (deterministischer Hash über alle Deskriptoren)
    primitiveTable:  [PrimitiveDesc...]
    typeTable:       [TypeDesc...]
    tagTable:        [TagDesc...]
    typeFnTable:     [TypeFnDesc...]
    intrinsicTable:  [IntrinsicDesc...]
    symbolTable:     [SymbolDesc...]

Vorteil: Plattformunabhängig. Kann in die VM-Binary eingebettet werden ohne D-Recompilation. Nachteil: Runtime-Parsing und -Validierung nötig.

Beide Formate können koexistieren — das D-Modul für Development-Builds (schnellerer Turnaround), der Blob für Release-Builds (plattformunabhängige Distribution).

Normativ:

Das Ausgabeformat muss versioniert sein (schemaVersion).
Das Ausgabeformat muss deterministisch sein — identischer Input erzeugt identischen Output.
Der Seed muss beim VM-Start validiert werden — descriptorHash gegen Neuberechnung prüfen, schemaVersion gegen erwartete Version prüfen.
Ein Seed-Schema-Mismatch ist ein harter Startfehler der VM.

12. Primitive im Bootstrap Core¶

Primitive sind keine normalen Userland-Typen. Sie können im Bootstrap Core als JDL-Deklarationen beschrieben werden, aber normale User-Module dürfen keine neuen Primitive definieren.

Beispielhafte Form:

type i32 : primitive
    :> PrimitiveClass(SignedInteger)
    :> Bits(32)
    :> Size(4)
    :> Align(4)
    :> Register(Immediate64)
    :> Boundary(Immediate64)
    :> Literal(Integer)
    :> Overflow(Trap)
    :> Default(0)
    :> Min(-2147483648)
    :> Max(2147483647)
    :> Memory(Value)
    :> Drop(Trivial)

Diese Form erzeugt keinen normalen Userland-Typkörper. Sie erzeugt einen PrimitiveDescriptor — eine Datenstruktur die alles beschreibt was die Subsysteme über i32 wissen müssen, ohne dass i32 als normaler Struct oder Enum existiert.

Primitive-Operationen¶

Ein PrimitiveDescriptor allein beschreibt nur die Existenz und die Eigenschaften eines Typs. Er beschreibt nicht, wie Operationen auf diesem Typ abgesenkt werden. Memory(Value) sagt "i32 lebt auf dem Stack" — aber es sagt nicht, wie i32 + i32 funktioniert.

Primitive-Operationen brauchen eine separate Abbildung auf VM-bekannte Operationsklassen:

coreop i32.add {
    symbol: "+"
    lhs: i32
    rhs: i32
    result: i32
    lowering: CoreIntAdd     // VM-interne Operationsklasse
    overflow: Trap           // Arithmetik-Überlauf ist ein VM-Trap
}

Die VM weiß was CoreIntAdd bedeutet — es ist eine fest verdrahtete D-Funktion in der VM-Loop. Der Seed sagt der VM nur "wenn jemand i32 + i32 schreibt, verwende CoreIntAdd". Die Zuordnung zwischen JDL-Operator und VM-Operation entsteht im Seed, die Implementation der VM-Operation lebt in D.

Normativ:

primitive als TypeBody ist nur im BootstrapSeedBuild-Modus zulässig.
primitive-Definitionen dürfen nur im Namespace jade::core::bootstrap vorkommen.
PrimitiveDescriptoren müssen gegen eine feste Menge erlaubter PrimitiveClasses, RegisterClasses und BoundaryClasses geprüft werden.
Primitive-Operationen entstehen nicht durch Meta-Records allein. Sie müssen auf VM-/Generator-bekannte Operationen oder Intrinsics abbildbar sein.

13. TypeKinds und Seed¶

Der Seed darf keine neuen TypeKinds erfinden. Er darf nur konkrete Instanzen bereits VM-/Compiler-bekannter TypeKinds beschreiben.

Die TypeKinds sind hardcoded in Jade — sie definieren die fundamentalen Kategorien von Typen die die VM unterscheiden kann:

ValueTypeKind:
    Primitive    — VM-native Typen (i32, bool, str, ...)
    Struct       — Produkt-Typen mit benannten Feldern
    Enum         — Summen-Typen mit Varianten
    Union        — untagged Unions (für FFI)
    Function     — Funktions-Signaturen
    Tuple        — anonyme Produkt-Typen
    Blueprint    — deklarative Orchestrierungs-Beschreibungen
    Flags        — Bitflag-Typen (erst nach separater Spezifikation)

Hinweis: Dyn[P] ist kein TypeKind, sondern ein parametrischer Typ-Konstruktor, der jeden TypeKind hinter einem Protocol-Interface löscht. Dyn[P] ist orthogonal zu TypeKinds — ein Dyn[Serializable] kann ein Struct, ein Enum oder ein Blueprint sein. Die Semantik von Dyn[P] wird in der dedizierten Spec dyn-protocol-values.md definiert.

Der Seed kann beschreiben:

i32         : Primitive
Option[T]   : Enum
Result[T,E] : Enum
HandleId    : Struct
TypeId      : Struct
SymbolId    : Struct

Der Seed kann nicht beschreiben:

new TypeKind MagicResource
new TypeKind CoroutineButOnlySometimes
new TypeKind PleaseCompilerGuess

Die TypeKinds sind die ontologischen Kategorien der Sprache — sie definieren wie Typen existieren können. Neue Kategorien zu erfinden wäre eine Änderung an der Sprache selbst, nicht am Seed. Wenn ein neuer TypeKind nötig wird, muss er in der VM-Implementierung (D) und im Compiler-Frontend implementiert werden, und dann kann der Seed Instanzen davon beschreiben.

Eine Sprache braucht Grenzen. Schockierend, aber langfristig gesund.

14. Beziehung zur Stdlib¶

Nach erfolgreichem Seeding wird die Stdlib als erstes privilegiertes Plugin geladen.

Die Stdlib ist das erste echte JDL-Artefakt, das auf der geprägten Jade-Welt aufsetzt. Sie ist selbst in JDL geschrieben und wird vom JDL-Compiler kompiliert — aber sie hat Privilegien die normale Plugins nicht haben: sie darf auf Seed-Symbole direkt zugreifen und sie darf Typen und Protocols definieren die der Compiler als eingebaute Sprach-Features behandelt.

Abgrenzung der Verantwortlichkeiten¶

Der Seed stellt bereit:

Option[T], Result[T, E]     — fundamentale algebraische Typen
Primitives                  — bool, i8..i64, u8..u64, f32, f64, str, ()
Core-Tags                   — OwnPolicy, SharePolicy, MemoryPolicy, DropKind
Core-TypeFns                — Own(...), Share(...), Memory(...), Drop(...)
Intrinsic-Registrierungen   — die 24 Intrinsics mit IDs und Signaturen
PrimitiveOps                — Abbildung von Operatoren auf VM-Operationen
minimale Diagnostics        — BootstrapDiagnostic, Severity, BootstrapPhase

Die Stdlib stellt bereit:

Protocols                   — Add, Copyable, Renderable, Scopeable, ...
Collections                 — Array, Map, Set, ...
Generatoren                 — Generator/Collector-Framework
Task-Abstraktion            — Task[T], JoinHandle[T], Channel[T], Actor[S,M]
Services                    — Service-Deklaration, DI, ...
Effects                     — Effect-Deklaration, Effect-Komposition
Casts und Komfort-APIs      — CastTo, Narrow, Widen, ...
Wire/Serde                  — Serialisierung/Deserialisierung
FFI-Frontends               — extern-Block-Abstraktion
Runtime-Utilities           — Timer, IO, Logging, ...

Self-Hosting-Implikationen¶

Die Stdlib ist der Ort an dem das Self-Hosting-Modell seine volle Kraft entfaltet. Weil die Stdlib in JDL geschrieben ist, können IR-Validatoren, IR-Pass-Pipelines, und Teile des Code Generators als JDL-Module in der Stdlib leben. Das bedeutet: der JDL-Compiler ist (teilweise) ein JDL-Programm das auf der Jade VM läuft. Änderungen an der Compiler-Pipeline erfordern keine D-Recompilation — sie sind JDL-Code-Änderungen die durch die normale JDL-Toolchain gehen.

Normativ:

Die Stdlib darf auf Seed-Symbole vertrauen — sie sind stabil und versioniert.
Der Seed darf nicht auf Stdlib-Symbole angewiesen sein — er existiert bevor die Stdlib geladen wird.
Der Plugin Loader darf nur Seed-Symbole voraussetzen.
Externe Plugins dürfen erst nach der Stdlib geladen werden, sofern sie Stdlib-Symbole referenzieren.

15. Versionierung und Kompatibilität¶

Der Bootstrap Seed ist ein versioniertes Artefakt. Änderungen am Seed-Schema sind Breaking Changes die eine neue VM-Version erfordern.

Schema-Versionierung¶

Jedes Seed-Artefakt trägt eine schemaVersion. Der BootstrapInitializer prüft beim VM-Start ob die schemaVersion des eingebetteten Seeds mit der erwarteten Version der VM übereinstimmt. Ein Mismatch ist ein harter Startfehler.

Seed-Schema-Änderungen entstehen wenn:

Neue Primitive hinzugefügt werden (z.B. i128).
Neue Tag-Domains hinzugefügt werden.
Neue Intrinsics registriert werden (z.B. jade::vm::await_any).
Die Deskriptor-Formate sich ändern (z.B. neue Felder in PrimitiveDescriptor).
TypeKinds hinzugefügt werden.

Forward- und Backward-Kompatibilität¶

Zwischen Tag-Domains im Seed und dem Compiler besteht eine implizite Kompatibilitätsannahme: der Compiler der User-Code kompiliert muss dieselben Tag-Domains kennen wie der Seed. Wenn eine neuere Compiler-Version eine Tag-Domain erwartet die im Seed einer älteren VM nicht existiert, ist das ein Schema-Mismatch.

In der Praxis bedeutet das: die VM-Version und die Compiler-Version müssen zueinander passen. Das ist eine bewusste Einschränkung — Seed-Kompatibilität über Versionen hinweg zu garantieren würde die Seed-Validierung massiv komplexer machen und den Vorteil der strikten Versionierung zunichtemachen.

Normativ:

Seed-Schema-Änderungen sind Breaking Changes.
Die VM prüft schemaVersion beim Start.
Compiler- und VM-Version müssen zum selben Schema kompatibel sein.

16. Diagnostik¶

Fehler im Bootstrap Core sind Jade-Team-Buildfehler, keine User-Fehler. Fehler beim Laden des eingebetteten Seeds sind VM-Startfehler.

Diagnostik-Codes¶

BOOT-SEED-001: Seed schema version mismatch.
    — Die schemaVersion im Seed passt nicht zur erwarteten Version der VM.
    — Ursache: VM-Binary und Seed-Artefakt aus unterschiedlichen Builds.

BOOT-SEED-002: Unknown PrimitiveClass in embedded seed.
    — Ein PrimitiveDescriptor referenziert eine PrimitiveClass die die VM nicht kennt.
    — Ursache: Seed enthält einen Deskriptor für ein Primitiv das diese VM-Version nicht unterstützt.

BOOT-SEED-003: PrimitiveDescriptor has invalid size/align combination.
    — Size und Align eines Primitiv-Deskriptors sind inkonsistent (z.B. align > size, oder align keine Zweierpotenz).

BOOT-SEED-004: Core type references missing symbol.
    — Ein Core-TypeDescriptor referenziert eine SymbolId die in der Symboltabelle nicht existiert.
    — Ursache: Symboltabelle und TypeDescriptor-Tabelle im Seed sind inkonsistent.

BOOT-SEED-005: Stdlib requested before runtime reached Seeded stage.
    — Code versucht die Stdlib zu laden, obwohl das Seeding noch nicht abgeschlossen ist.
    — Ursache: Stufenverletzung in der Initialisierungsreihenfolge.

BOOT-SEED-006: User module attempted to define jade::core::bootstrap symbol.
    — User-Code versucht den reservierten Namespace jade::core::bootstrap zu beschreiben.
    — Ursache: absichtlicher oder versehentlicher Namespace-Hijacking-Versuch.

BOOT-SEED-007: Descriptor hash mismatch.
    — Der descriptorHash im Seed-Header stimmt nicht mit dem berechneten Hash überein.
    — Ursache: korruptes Seed-Artefakt oder Manipulation.

BOOT-SEED-008: Intrinsic ID conflict.
    — Zwei Intrinsic-Deskriptoren im Seed haben dieselbe ID.
    — Ursache: Fehler im BootstrapSeedBackend.

BOOT-SEED-009: Missing required core type.
    — Ein zwingend benötigter Core-Typ (Option, Result, HandleId) fehlt im Seed.
    — Ursache: unvollständiger Bootstrap Core.

Normativ:

User-Code darf jade::core::bootstrap nicht definieren.
User-Code darf Seed-Symbole nur importieren wenn sie über öffentliche Stdlib-/Prelude-Oberflächen re-exportiert wurden.
Interne Seed-Deskriptoren sind keine normale User-API.

17. Testen des Bootstrap Seeds¶

Der Bootstrap Seed ist die härteste Schicht des Systems — ein Fehler hier betrifft jede Jade-Instanz. Entsprechend muss er rigoros getestet werden.

Build-Zeit-Tests¶

Der Bootstrap-Checker und das BootstrapSeedBackend sollten eigene Testsuiten haben die sicherstellen:

Alle Primitive haben konsistente Size/Align/Bits-Kombinationen.
Alle Core-Typen referenzieren existierende Symbole.
Alle Intrinsic-IDs sind eindeutig und lückenlos.
Alle Tag-Domains sind konsistent mit der Label-Inferenz-Spec (04a-label-inferenz-regeln.md).
Das Seed-Artefakt ist deterministisch — zweimaliges Generieren produziert bitidentische Ausgabe.
Der descriptorHash ist korrekt berechnet.

Laufzeit-Validierung¶

Beim VM-Start wird der Seed validiert — aber diese Validierung sollte nicht übermäßig teuer sein, weil sie bei jedem Programmstart läuft. In der Praxis reicht:

Schema-Version prüfen (O(1)).
Descriptor-Hash prüfen (O(n) über alle Deskriptoren, einmalig).
Kritische Invarianten spot-checken (Option muss existieren, Result muss existieren, HandleId muss existieren).

Aufwändigere Validierungen (vollständige Konsistenzprüfung aller Cross-Referenzen) sollten nur im Debug-Build oder über ein explizites --validate-seed-Flag laufen.

Regressionstests¶

Jede Änderung am Bootstrap Core sollte einen Regressionstestzyklus auslösen: Seed generieren → VM bauen → Stdlib laden → Stdlib-Testsuite ausführen. Damit wird sichergestellt dass eine Seed-Änderung nicht die Stdlib oder den Compiler bricht.

18. D-Kernschicht und ihre Grenzen¶

Der Bootstrap Seed ermöglicht dass ~90% von Jade in JDL implementiert werden. Die verbleibenden ~10% in D sind die VM-Execution-Loop, der JME mit atomarem Refcounting, der Scheduler mit Task-Deskriptor-Management, die FFI-Bridge mit ABI-Compliance, und der BootstrapInitializer selbst.

Diese D-Kernschicht ist klein, aber sie ist das Fundament auf dem die gesamte Korrektheit des Systems steht. Der Seed validiert sich beim Start, aber die D-Runtime unter ihm validiert sich nie selbst — sie muss durch D-seitige Tests, Reviews und statische Analyse abgesichert werden.

Das Self-Hosting-Argument "wir können fast alles in JDL machen" darf nicht dazu führen, dass die D-Kernschicht als erledigt betrachtet wird. Sie enthält den Code wo ein einziger Bug zu Use-After-Free, Data Races oder stillem Memory Corruption führt — und wo D's @nogc nothrow-Annotationen das einzige Sicherheitsnetz sind.

Normativ:

Die D-Kernschicht muss eigenständig testbar sein, unabhängig von JDL-Code.
D-seitige Speicherfehler dürfen nicht durch JDL-seitige Checks kaschiert werden.
Änderungen an der D-Kernschicht erfordern dasselbe Review-Niveau wie Änderungen am Seed.

19. Normative Regeln¶

BSP-1:  Der Bootstrap Seed ist kein ausführbares Modul.
BSP-2:  Der Bootstrap Seed ist kein Plugin.
BSP-3:  Der Bootstrap Seed ist die initiale Wahrheitstabelle der Jade VM.
BSP-4:  Der Bootstrap Core liegt im reservierten Namespace jade::core::bootstrap.
BSP-5:  Der Bootstrap Core wird nur im BootstrapSeedBuild-Modus verarbeitet.
BSP-6:  Das BootstrapSeedBackend erzeugt Deskriptoren, keinen ausführbaren Bytecode.
BSP-7:  Beim Benutzer wird das Seed-Artefakt gelesen, nicht neu kompiliert.
BSP-8:  Seeding muss vor Plugin Loader und Stdlib-Laden abgeschlossen sein.
BSP-9:  RuntimeBus ist nicht der primäre Mechanismus für initiales Seeding.
BSP-10: Tags bleiben compile-time-only und werden über Type Engine / CompilerDb behandelt.
BSP-11: Der Seed darf nur transitive Bootstrap-Notwendigkeiten enthalten.
BSP-12: Die Stdlib darf auf Seed-Symbole bauen; der Seed darf nicht auf Stdlib-Symbole bauen.
BSP-13: Primitive-Definitionen im Seed erzeugen PrimitiveDescriptoren und sind im Userland verboten.
BSP-14: Der Seed darf keine neuen TypeKinds definieren.
BSP-15: Der Seed muss versioniert, deterministisch und validierbar sein.
BSP-16: Seed-Schema-Änderungen sind Breaking Changes.
BSP-17: Compiler- und VM-Version müssen zum selben Seed-Schema kompatibel sein.
BSP-18: Die D-Kernschicht muss eigenständig testbar sein, unabhängig von JDL-Code.
BSP-19: Die 24 Intrinsics aus 08-intrinsics-vm-api.md sind integraler Bestandteil des Seeds.
BSP-20: RuntimeStage-Übergänge sind strikt monoton: Constructed → Seeded → StdlibLoaded → Ready.

20. Merksatz¶

Der Bootstrap Seed beschreibt nicht Jade-Programme.
Er beschreibt die erste Form, in der Jade über Programme sprechen kann.

Oder weniger feierlich:

Seed rein, Tabellen raus, Stdlib drauf, los geht's.

Änderungsprotokoll¶

Version 0.2 — Erweiterungen: - §1: Henne-Ei-Problem und Self-Hosting-Architektur als Motivation ergänzt. - §2: Begründung der Designentscheidung "JDL-Quelle statt D-Tabellen" hinzugefügt. - §3: Zustand vor Bootstrapping konkretisiert. - §4: Single-Source-of-Truth-Prinzip mit Beispiel ausformuliert. - §5: Prägung der 24 Intrinsics als wesentlichen Seed-Bestandteil ergänzt. - §6: Stufenwächter und Fehlerszenarios hinzugefügt, monotone Übergangsinvariante normativ festgehalten. - §7: Reihenfolgenabhängigkeiten mit Begründungen dokumentiert. - §8: Übergang zum RuntimeBus nach Seeding beschrieben. - §9: Begründungen für Zulässigkeit/Unzulässigkeit bei jedem Eintrag ergänzt. - §10: Bootstrap-Checker-Einschränkungen konkretisiert (keine Funktionskörper, keine Closures, keine Effekte etc.). - §11: Trade-offs zwischen D-Modul und Binärblob beschrieben. - §15 (neu): Versionierung und Kompatibilität als eigenständiger Abschnitt. - §16: Diagnostik-Codes mit Beschreibungen und Ursachen erweitert, BOOT-SEED-007/008/009 hinzugefügt. - §17 (neu): Teststrategie für den Bootstrap Seed. - §18 (neu): D-Kernschicht und ihre Grenzen. - BSP-16 bis BSP-20: Neue normative Regeln.

Version 0.1 — Initiale Definition. 17 Abschnitte, 15 normative Regeln.