Status: Leitdokument / Charta Priorität bei Konflikt: Normative Fachspezifikationen (
00bis11, CompilerDB-, Meta-Phasen-, Engine-/Descriptor- und Runtime-Specs) gelten im Detail. Dieses Dokument definiert die übergreifenden Architekturprinzipien. Ausgelagert: Die Regelsprache des Constitution-Systems — Regelform, Selektor, Prädikat, Trigger, Monotonie, Vererbung — steht inspec-constitution-system. Hier bleibt nur die Einordnung (§9).
Jade Design Constitution v2.3¶
Status: Grundsatzdokument und Charta Zielgruppe: Mitwirkende, fortgeschrittene Nutzer und interessierte Leser Umfang: Architekturprinzipien von Jade VM, JDL, Ringen, Descriptoren, CompilerDB, RuntimeBus und Constitution-Enforcement.
0. Zweck dieses Dokuments¶
Jade ist ein langfristiges Projekt. Code, Implementierungen, Stdlib-Strukturen und Werkzeuge werden sich ändern. Die Constitution hält fest, welche Architekturentscheidungen dabei stabil bleiben müssen.
Dieses Dokument ist nicht die einzige normative Quelle. Jade besitzt ein ausführbares Constitution-Modell:
ConstitutionSpec deklarativer Blueprint
ConstitutionEngine validiert und materialisiert Regeln
ConstitutionDescriptor geprüfter Regelvertrag pro Ring und Namespace
Compilerphasen konsumieren Descriptoren an Enforcement-Gates
Die Prosa-Charta erklärt die Struktur. Die konkrete Durchsetzung erfolgt über Constitution-Blueprints und materialisierte ConstitutionDescriptoren. Das klingt bürokratisch, ist aber immerhin maschinenlesbare Bürokratie. Menschen haben Schlimmeres mit YAML getan.
Wenn eine zukünftige Designentscheidung dieser Charta widerspricht, gibt es nur zwei legitime Optionen:
- Das Design wird so geändert, dass es zur Charta passt.
- Die Charta wird explizit geändert, mit Begründung und Versionseintrag.
1. Architekturformel¶
Jade folgt einer festen Schichtung:
Ring 0 / Zig = JME-zentrierter Maschinenkern und Trust Anchor
Ring 1 / jade:: = JDL-seitige Semantik- und Descriptor-Schicht
Ring 2 / jdl:: = user-facing Stdlib, Services, Blueprints, Engines
Ring 2 / User = Anwendungscode, Projekt-Constitutions, Plugins
Blueprint = deklarative Beschreibung
Engine = Auswertung einer Beschreibung
Descriptor = materialisierter Vertrag zwischen Semantik und Maschine
Constitution = deklarativer Regelvertrag über erlaubte Semantik
Der wichtigste Satz lautet:
Zig besitzt Mechanik. JDL besitzt Semantik. Descriptoren verbinden beides.
Jade strebt kein vollständiges Self-Hosting-Dogma an. JME, VM-Loop, Scheduler-Kern, RuntimeBus, CompilerDB-Storage, Bootstrap Seed, Intrinsic Dispatch und Host-Integration bleiben Ring 0. So viel Semantik wie möglich wandert in JDL; so wenig Mechanik wie nötig bleibt in Zig.
Für Compilersemantik folgt daraus eine zusätzliche Grenze: Ring 0 besitzt den Query-/Provider-Mechanismus, nicht das semantische Vokabular der Analysen. Eine neue Analyseeigenschaft rechtfertigt für sich allein keine View-spezifische Zig-Primitive. Wenn ihr Query-Vertrag durch die CompilerDB darstellbar ist, gehört ihre Bedeutung in JDL. Bootstrap-Provider in Ring 0 dürfen denselben Query-Vertrag vorübergehend tragen; sie machen dessen Semantik nicht zu Ring-0-Semantik. Damit auch neue Query-Verträge selbst ohne Hostcode definiert werden können, braucht die CompilerDB einen generischen, datengetriebenen Weg, Query-Verträge zu beschreiben und zu registrieren. Die derzeitige CompilerDB-Fachspezifikation normiert diesen Weg noch nicht.
Die Schnittstelle zwischen beiden ist keine Bibliotheksgrenze, sondern eine Zeitgrenze: Bis die Maschine steht, ist alles Daten. Danach ist alles Blueprint.
2. Identität und Umfang von Jade¶
2.1 Jade ist VM-first¶
Jade ist eine sprachzentrierte virtuelle Maschinenplattform für JDL mit eigenem typisiertem Mid-Level-IR, eigener VM, eigener Memory Engine, eigenem Effektsystem und eigener Descriptor-Pipeline.
Jade ist nicht zuerst:
- ein offenes IR für jede beliebige Sprache,
- ein universelles Backend für jede CPU-Architektur,
- ein Ersatz für LLVM,
- ein allgemeines Plugin-System mit Sprachsyntax.
Es kann später breiter werden. Der Ausgangspunkt bleibt JDL auf der Jade VM.
2.2 Linux als einzige Zielplattform¶
Jade unterstützt bewusst ausschließlich Linux. macOS und Windows sind keine Zielplattformen und werden nicht präventiv abstrahiert. Eine Erweiterung auf andere Betriebssysteme wäre eine ausdrückliche Änderung dieser Charta, keine implizite Folge portabler Ring-0-Komponenten.
2.3 Internes IR zuerst¶
Jade verwendet ein internes typisiertes IR als Compiler- und Optimierungsrepräsentation. Dieses IR ist zunächst Implementierungsdetail. Es wird erst stabilisiert, wenn mehrere Frontends oder mehrere Backends diese Stabilität tatsächlich brauchen. Ewige IRs auf Vorrat sind eine bewährte Methode, sich selbst frühzeitig einzubetonieren.
3. Kein undefiniertes Verhalten¶
Jade lehnt undefiniertes Verhalten als Designwerkzeug ab.
Kein Wert existiert, bevor sein Descriptor geprüft ist.
Diese Zusage bindet an den Descriptor, nicht an einen Zeitpunkt. Das ist Absicht: Ein Compilerkontext kann in einem laufenden Programm geöffnet werden — für einen eingebauten Sprachserver, für ein nachgeladenes Plugin, für einen Node, der SystemSpecs konsumiert. Dort gibt es kein Ende der Übersetzung, hinter dem man eine Grenze ziehen könnte.
Die Beweislast bleibt davon unberührt. Ein Descriptor, der zur Laufzeit entsteht, durchläuft dieselben Prüfungen wie einer, der beim Bauen entsteht — es gibt keinen zweiten, weicheren Weg. Dynamik heißt in Jade, dass die Prüfung später stattfindet, nicht dass sie entfällt.
Jedes Programm, das die Ausführungsstufe erreicht, befindet sich damit in einem von zwei Zuständen:
Gültiges IR
Alle Struktur-, Typ-, Policy-, Effekt- und Ringregeln sind erfüllt.
Verhalten ist definiert.
Ungültiges IR
Eine Invariante ist verletzt.
Der Verifier lehnt das Programm ab.
Laufzeitfehler sind Traps mit definierter Semantik. Division durch Null, ungültiger Indexzugriff, geschlossener Handle oder gescheiterte Runtime-Policy führen zu kontrollierten Fehlern, nicht zu semantischem Nebel.
3.1 Offene Flanke: Prüfung in einem laufenden Kontext¶
Was passiert, wenn die Prüfung eines Descriptors fehlschlägt, während das Programm bereits läuft, ist nicht festgelegt.
Beim Bauen ist die Antwort einfach — der Verifier lehnt ab, es entsteht kein Artefakt. In einem laufenden Kontext gibt es kein Artefakt, das man zurückhalten könnte. Die naheliegende Antwort ist eine Trap mit lokaler Fehlergrenze nach §11, aber sie steht nirgends, und sie ist Voraussetzung dafür, dass ein Node oder ein nachgeladenes Plugin scheitern darf, ohne den Prozess mitzunehmen.
3.2 Offene Flanke: das Speichermodell¶
Kein undefiniertes Verhalten ist heute eine Aussage über einen Ausführungsstrang. Sobald zwei Tasks denselben Wert sehen — jeder Share(Sync)-Typ, jeder Kanal, jedes Actor-Postfach — kommt eine zweite Frage dazu: in welcher Reihenfolge ein Task die Schreibvorgänge eines anderen beobachtet.
Diese Frage ist nicht beantwortet. Solange sie offen ist, entscheidet der Generator nach Gutdünken, was er über atomare Operationen hinweg umordnet, und lock-freier Code ist bestenfalls zufällig richtig.
Der Mindestbedarf ist klein: eine Zusage, dass ein atomarer Schreibvorgang alles veröffentlicht, was der Strang vorher geschrieben hat, plus die Anweisung an den Generator, über atomare Operationen hinweg nicht umzusortieren. Das ist eine halbe Seite und gehört in die Runtime-Spec, bevor der Generator geschrieben wird.
Mit einem Compilerkontext im laufenden Prozess wird sie außerdem früher akut als gedacht: Der DescriptorStore ist dann keine reine Compilerstruktur mehr, sondern etwas, das gelesen wird, während geschrieben wird.
4. Core, Extended und Backends¶
4.1 Core-Instruktionen¶
Der Execution Core ist klein, stabil und direkt ausführbar. Jedes ausführbare Jade-Programm wird am Ende vollständig in Core-Instruktionen ausgedrückt.
Core-Instruktionen dürfen nicht leichtfertig erweitert werden. Eine Core-Instruktion ist ein Vertrag mit der VM, dem Verifier und allen zukünftigen Tools. So etwas fügt man nicht hinzu, weil einem ein Lowering-Pass gerade müde vorkommt.
4.2 Extended-Instruktionen¶
Extended-Instruktionen sind High-Level-Formen für Frontends, Optimierung und Lesbarkeit. Sie müssen vor Verifikation und Ausführung zu Core gelowert werden.
Plugins dürfen Extended-Instruktionen ergänzen, aber niemals Core-Instruktionen verändern oder deren Semantik überschreiben.
4.3 Backends bleiben dünn¶
Backends übersetzen bereits bewiesene und gelowerte Repräsentationen. Sie erfinden keine neue Semantik, keine neuen Effekte und keine neuen Safety-Regeln. Optimierung und Semantik leben im Jade-IR und in der Pass-/Descriptor-Pipeline, nicht im Backend.
5. Pass-Pipeline, IR-Invarianten und Verifier¶
Ein Pass ist eine Analyse oder Transformation über IR oder eine daraus abgeleitete Repräsentation.
Jeder Pass deklariert:
preconditions welche Invarianten vorher gelten müssen
postconditions welche Invarianten danach garantiert sind
invalidations welche Invarianten gebrochen werden können
Der Verifier ist Gatekeeper. Er prüft an definierten Pipeline-Grenzen:
- nach Frontend-/IR-Erzeugung,
- nach großen Pass-Gruppen,
- vor Lowering zu Core,
- vor Ausgabe oder Laden ausführbarer Artefakte.
Diese Grenzen sind Punkte in der Pipeline, nicht Punkte in der Zeit. In einem Compilerkontext, der in einem laufenden Programm geöffnet wurde (§7.2), gelten dieselben vier — sie werden nur wiederholt durchlaufen, statt einmal.
Compilernahe Engines wie IRBuilderEngine oder GeneratorEngine dürfen Artefakte erzeugen, aber keine Type-, Effect-, Dispatch-, FFI- oder Constitution-Semantik nachträglich erfinden.
6. Speichermodell und JME¶
6.1 Ring 0 ist JME-zentriert¶
Ring 0 ist die JME-zentrierte Maschinen- und Integritätsebene.
Die JME besitzt die zentrale Autorität über:
Speicheridentität
Handles
Generation Counter
Refcounts
Arenen und Pools
Layoutbindung zur Runtime
Drop-/Lifetime-Durchsetzung
Handle-Gültigkeit
VM-Loop, Scheduler-Kern, RuntimeBus, Intrinsic Dispatch, FFI/JadeValue Bridge, CompilerDB-Storage und Bootstrap Seed sind ebenfalls Ring-0-nahe mechanische Substrate. Sie sind aber nicht gleichrangige semantische Autoritäten über Speicher. Für Speicher- und Handle-Wahrheiten ist die JME der Eigentümer.
6.2 Handles statt roher Pointer¶
JDL kennt keine rohen Pointer. JDL-Code arbeitet mit typisierten Handles, Werten und Descriptoren. Pointer existieren nur unterhalb der Sprachgrenze, insbesondere in FFI- und Ring-0-Mechanik.
Handles sind opak. Operationen auf Handles laufen über JME-vermittelte Regeln. Kein Usercode, Plugin oder Ring-2-Code darf JME-Tabellen direkt manipulieren.
Der Preis dieser Entscheidung wird an einer Stelle sichtbar: Datenstrukturen, die Kontrolle über die physische Speicherplatzierung brauchen — Cache-Zeilen-Ausrichtung, lock-freie Ringpuffer — sind in JDL nicht ausdrückbar. Sie werden in Zig gebaut und über Handles angeboten. Das ist keine Lücke, sondern dieselbe Grenze, die Jade seine Handles und Generationszähler überhaupt erst ermöglicht.
6.3 TypeEngine gegen JME¶
Die TypeEngine ist semantische Autorität über Typbeschreibung. Die JME ist operative Autorität über Runtime-Repräsentation und Speicherintegrität.
TypeEngine erzeugt TypeDescriptor, LayoutDescriptor, Policy-/Meta-Descriptoren
JME konsumiert diese Descriptoren und verwaltet Runtime-Zustand
Die TypeEngine verwaltet keine Runtime-Typen direkt. Sie erzeugt Verträge. Die JME erzwingt sie.
7. Effekte und Runtime-Grenzen¶
Effekte sind Teil von Typ- und IR-Semantik. Effektgrenzen sind harte Constraints für Optimierungen, Scheduling und Ausführung.
Jade unterscheidet zwei Phasen, nicht zwei Sprachen:
Beide sind gewöhnliche def-Deklarationen. Was sie trennt, ist die Phase am Pfeil — nicht ein eigenes Schlüsselwort. Ein separates typefn-Konstrukt existiert nicht mehr.
Die CompilerDB ist Query-/Descriptor-Substrat. Der RuntimeBus ist Command-Substrat. Beide sind kontrollierte Zugangspunkte zu tieferen Ringen. Usercode greift auf keinen von beiden direkt zu.
Effects referenzieren Services und deklarierte Dependencies, nicht native Symbole oder rohe Intrinsics.
7.1 Meta-Werte sind JME-Werte¶
Meta-Code ist gewöhnlicher JDL-Code. Ein MetaRecord ist ein JME-Objekt wie jedes andere. Daraus folgt, dass beim Übersetzen eine VM läuft: Der erste Meta-Aufruf setzt Generator, JME und VM-Schleife voraus.
Das ist der Grund, warum der Bootstrap Seed in Zig entsteht und keine Meta-Auswertung enthält. Er ist der einzige Punkt, an dem noch keine VM existiert, die Meta auswerten könnte.
An der Grenze zur CompilerDB wird aus dem JME-Objekt wieder eine kanonische Bytefolge. Query-Ergebnisse dürfen keine Handles enthalten — ein Handle ist lauf-lokal wie ein Arena-Index und taugt in keinem persistierten Schlüssel.
7.2 Compilerkontext zur Laufzeit¶
Weil der Compiler ein VM-Prozess ist, kann ein laufendes Jade-Programm einen zweiten, getrennten Compilerkontext öffnen. Das ist die Voraussetzung für einen eingebauten Sprachserver, für nachgeladene Plugins und für einen Node, der SystemSpecs konsumiert.
Ein solcher Kontext ist kein Sonderweg. Es sind derselbe Seed, dieselben Engines, dieselben Descriptoren und derselbe Verifier — nur ein zweites Mal, mit eigenem Bestand.
Die Naht liegt dort, wo das System ohnehin eine hat:
geteilt Bootstrap Seed — unveränderlich nach dem Prägen
getrennt alles darüber: Descriptoren, Query-Ergebnisse, Kanten, Namensräume
Die Trennung muss geprüft sein, nicht nur gemeint. Eine Query im zweiten Kontext darf außer dem Seed nichts aus dem ersten sehen — sonst analysiert ein Sprachserver versehentlich sich selbst, und das zeigt sich an Ergebnissen, die niemand erklären kann.
Die Einthreadigkeit des Compilers gilt damit pro Kontext, nicht pro Prozess.
Ein Sprachserver braucht keine dynamisch erzeugten Typen. Er übersetzt permanent: Er hält eine CompilerDB offen, setzt bei jedem Tastendruck neue Inputs und lässt die Queries neu laufen. Die Typen entstehen dabei zur Übersetzungszeit — es gibt bloß keinen Zeitpunkt, an dem die Übersetzung aufhört. Genau dafür sind lazy Revalidierung, Early Cutoff, Durability und Cancellation gebaut.
Der davon verschiedene Fall — ein Programm legt Werte eines Typs an, den es selbst gerade erst gebaut hat — ist die Erweiterung, an die §3 die Zusage bindet. Sie ist für Jade 0.1 nicht nötig und für JadeOS absehbar unvermeidlich.
8. Blueprints, Engines und Descriptoren¶
8.1 Blueprint¶
Ein Blueprint ist eine getypte, deklarative Beschreibung. Er beschreibt Absicht, nicht Ausführung.
Blueprints sind serialisierbar und enthalten keine gefangene Runtime-Closure mit verstecktem Zustand. Handler-Slots müssen über qualifizierte Funktionsreferenzen oder capture-freie Funktionen modelliert werden.
8.2 Engine¶
Eine Engine ist eine typisierte Auswertungsinstanz für ein Blueprint- oder Descriptor-Subject. Sie validiert, beschreibt, materialisiert oder instanziiert.
Die Engine-Abstraktion ist ring-neutral. Eine konkrete EngineDefinition gehört jedoch zu einem Ring-Kontext:
Ring 1 Engines
ParserEngine, TypeEngine, MetaEvaluator, ProtocolDispatcherEngine,
FfiBindingEngine, IRBuilderEngine, GeneratorEngine, ConstitutionEngine
Ring 2 Engines
HttpEngine, TestEngine, ActorEngine, EffectRuntime, TransportEngines,
User-/Plugin-Engines, App-spezifische Runtime-Engines
Der alte Satz „Engines sind Ring-2-Code" ist damit falsch. Manche Engines sind Ring 2. Compilernahe Engines sind Ring 1. Die Fachwelt atmet erleichtert auf, falls sie jemals davon erfahren sollte.
8.3 Descriptor¶
Descriptoren sind die materialisierte Mitte:
Blueprint / TypeSubject / ConstitutionSpec
-> Engine / MetaEvaluator / ConstitutionEngine
-> Descriptor / Patch
-> Materializer / Runtime / Ring-0-Domäne
Ring-0-Domänen konsumieren Descriptoren. Sie interpretieren keine hohe JDL-Semantik.
8.4 Wann eine semantische Zusage vollständig ist¶
Der Satz aus §1, „Zig besitzt Mechanik. JDL besitzt Semantik. Descriptoren verbinden beides“, ist nur dann mehr als eine schöne Formel, wenn man ihn prüfen kann. Diese Prüfung ist fünf Fragen lang:
1. Wer beschreibt die Zusage?
2. Wer leitet daraus etwas ab und prüft, ob die eigene Beschreibung in sich stimmt?
3. Wer entscheidet über das Zusammenspiel mit allem anderen und über Autorität?
4. In welchem materialisierten Vertrag wird die Zusage festgehalten?
5. Welche tiefere Schicht setzt diesen Vertrag mechanisch durch?
Keine semantische Zusage ist vollständig, solange nicht gezeigt ist, wo sie materialisiert wird und welche tiefere Schicht sie erzwingt.
Ein neuer Mechanismus, eine neue Engine oder ein neuer Blueprint-Vertrag muss alle fünf Fragen beantworten, bevor er als fertig gilt.
Die Antworten ergeben eine feste Kette:
Beschreibung → Ableitung → Entscheidung → materialisierter Vertrag → Durchsetzung
Blueprint Provider Engine Descriptor Ring 0
Drei Befunde sind möglich, wenn eine Antwort fehlt oder schief ist:
- Eine Stufe fehlt. Das Design ist nicht fertig.
- Zwei Stufen beanspruchen dieselbe Verantwortung. Die Abstraktion ist wahrscheinlich falsch geschnitten. Insbesondere darf die Ableitung nicht zur Entscheidung werden: Ein Provider darf Nein zu seiner eigenen Beschreibung sagen, aber nie zu fremden Beiträgen und nie zu Autorität.
- Eine obere Stufe verspricht, was unten niemand ausdrücken oder erzwingen kann. Die Zusage existiert nur auf Papier.
Frage 4 und Frage 5 finden verschiedene Fehler. Frage 4 findet eine fehlende Darstellung: Der Vertrag hat keinen Platz für die Zusage. Frage 5 findet eine fehlende oder widersprechende Mechanik: Der Platz existiert, aber niemand setzt ihn durch, oder eine andere Regel arbeitet dagegen. Eine reine Descriptor-Checkliste findet nur die erste Sorte.
Das Beispiel, an dem die Prüfung entstanden ist. Eine FFI-Component beantragte „dieses Handle ist an einen Thread gebunden“. Beschreibung, Ableitung und Entscheidung waren sauber. Frage 4 scheiterte, weil die FFI-Descriptoren keinen Platz für Thread-Bindung hatten. Frage 5 scheiterte doppelt: Ring 0 hatte keine Mechanik dafür, und der Scheduler verschob Tasks sogar aktiv zwischen Threads. Beides ist inzwischen behoben (jdl-vm-scheduler-spec v0.3.0, FFI-Spec v0.2.0, 06-jme-handles-tags §12). Gefunden wurde es nur, weil bis Ring 0 durchgefragt wurde.
9. Constitution — Einordnung¶
9.1 Was sie ist¶
Eine Constitution ist ein deklarativer Regel-Blueprint, der von einer ConstitutionEngine geprüft und in einen ConstitutionDescriptor materialisiert wird.
ConstitutionSpec
-> ConstitutionEngine
-> ConstitutionDescriptor
-> RuleIndex / EnforcementHooks
-> Compilerphasen
Die ConstitutionEngine führt keine beliebige Programmlogik aus. Sie normalisiert deklarative Regeln in eine endliche, querybare Rule-Algebra. Freie Callbacks als Verfassungsrecht wären nur ein Plugin-System mit Perücke.
Ein eigener TypeKind : constitution existiert nicht. Eine Constitution ist ein blueprint — sonst bräuchte es eine zweite Sorte Engine für eine Sache, die dasselbe tut.
9.2 Vier Ebenen¶
Ring0Constitution
Ursprung: Bootstrap Seed / Zig / JME
Status: sealed
Durchsetzung: Ring 0, nicht über die Engine
Inhalt: Speicher, Handles, Runtime-Facts, Intrinsics, VM-Fundamente
Ring1Constitution
Ursprung: jade::constitution
Validierung: gegen Ring0Constitution
Inhalt: Meta-Funktionen, EngineProvider, Descriptor-Materialisierung,
CompilerDB-Regeln
Ring2StdlibConstitution
Ursprung: jdl::constitution
Validierung: gegen Ring0 + Ring1
Inhalt: user-facing Stdlib, Services, Blueprints, Effects, Runtime-Engines
Ring2UserConstitution
Ursprung: Package-/Projekt-Constitution
Validierung: gegen Ring0 + Ring1 + jdl::
Inhalt: lokale Projektregeln, restriktive Policies, Team-Invarianten
9.3 Monotonie¶
niedriger Ring / übergeordneter Namespace setzt Grenze
höherer Ring / untergeordneter Namespace darf nur weiter einschränken
Ring 2 darf sich selbst fesseln. Ring 2 darf sich keine Schlüssel für Ring 0 malen.
9.4 Wo sie steht¶
Constitutions werden in constitution.jdl deklariert oder über mod.jdl benannt. prelude.jdl ist nicht der richtige Ort für Autorität; Prelude ist Bequemlichkeit, Constitution ist Recht. Diese Dinge zu vermischen wäre eine sehr effiziente Methode, zukünftige Leser zu verärgern.
9.5 Die offene Naht¶
Die Ring-1-Constitution wird von der ConstitutionEngine geprüft, und die ist selbst eine Ring-1-Engine. Für Ring 2 ist das unproblematisch, weil die prüfende Instanz eine Ebene tiefer sitzt. Für Ring 1 fehlt diese Ebene.
Auflösung vermutlich wie beim Seed: Die Ring-1-Constitution wird beim Prägen mitgegeben und in Zig geprüft; die JDL-Fassung ist dann Spezifikation statt Durchsetzung. Entschieden ist das nicht.
9.6 Sichtbarkeit ist Verfassungssache¶
JDL kennt keine Sichtbarkeits-Keywords. Es gibt kein pub und kein package.
Alles ist standardmäßig unsichtbar. Was ein Modul nach außen gibt, steht in seiner Constitution — an einer Stelle, vollständig lesbar, statt über den Baum verstreut.
Das ist die einzige Stelle, an der eine Constitution nicht einschränkt, sondern gewährt. Es bricht die Monotonie trotzdem nicht: Geöffnet wird aus dem Zustand „nichts", und eine untergeordnete Constitution kann nur öffnen, was die übergeordnete ihr zu öffnen erlaubt.
Was dabei entfällt: pub, package und die Re-Export-Semantik von mod.jdl als Mittel, eine Oberfläche zu formen. Vier Mechanismen für eine Frage werden einer.
Was bleibt: internal als Pfadsegment. Es ist eine harte Barriere, die unabhängig von jeder Constitution greift — und ein Netz für den Fall, dass jemand seine Verfassung falsch schreibt.
Der Preis ist ehrlich zu benennen: Wer eine Datei aufschlägt, sieht nicht mehr, ob eine Definition freigegeben ist. Der Ausgleich liegt beim Compiler — eine Änderung an einer freigegebenen Definition muss gemeldet werden, im Moment der Änderung. Das ist mehr, als ein Keyword je geleistet hat; ein Keyword steht nur da und warnt niemanden.
9.7 Abgrenzung zum Typsystem¶
Die Constitution sagt nichts über einen einzelnen Typ, das der Typ nicht auch selbst sagen könnte. Sie sagt es nur für alle auf einmal, und ohne dass man es vergessen kann.
Sobald eine Regel genau einen Typ meint, gehört sie an den Typ. Ohne diese Grenze hätte Jade zwei Systeme für dieselbe Frage.
Alles Weitere — Regelform, Selektor, Prädikat, Trigger, Vererbung, Katalogbindung — steht in
spec-constitution-system.
10. Namespaces und Zugriffshierarchie¶
Anwendercode, Plugins
│ erreichbar: jdl::
│ gesperrt: jade:: und alle Zweige darunter
▼
jdl:: user-facing Stdlib
│ erreichbar: jade:: samt allen Zweigen
▼
jade:: privilegierte Systemmodule
└ jade::intrinsics Zweig darin — spricht mit RuntimeBus / Ring 0
Die Aufstellung nennt Grenzen für Außenstehende, keine Erlaubnisleiter. Innerhalb von jade:: gibt es keine Grenze zu ziehen: jade::intrinsics ist kein eigener Namensraum, sondern ein Zweig, und die Constitution über jade:: vererbt sich ohnehin dorthin. Ein Namensraum braucht keine Erlaubnis, in sich selbst zu greifen.
Die Grenze läuft also einmal — zwischen Anwenderraum und jade::. jdl:: ist die Schicht, die sie überschreiten darf, und der Grund, warum es sie gibt.
jade:: ist Ring-1-nahes JDL: Systemschicht, Intrinsic-Wrapping, EngineProvider, Descriptor-nahe Implementierungen. Es ist keine dünne Naht und wird es nicht bleiben.
jdl:: ist Ring-2-Stdlib: user-facing Types, Protocols, Blueprints, Services, Effects, Collections, Engines ohne direkten Maschinenkontakt.
Die Kette gilt für Importe und für vollqualifizierte Namen gleichermaßen. Die einzige Ausnahme für Anwendercode ist der implizite Prelude, der Option und Result samt Varianten bereitstellt, ohne den Namensraum zu öffnen.
Usercode ist ebenfalls Ring 2, darf aber die jdl::-Constitution nur weiter einschränken, nicht lockern.
Details in spec-namespaces-und-module.
11. Graceful Degradation¶
Jade kennt definierte Traps und lokale Fehlergrenzen.
Ein Laufzeitfehler invalidiert den lokalen Scope, nicht automatisch das Gesamtsystem. Arenas und Handles liefern natürliche Fehler- und Cleanup-Grenzen.
Vollständiger Prozessabbruch ist nur legitim bei:
Ring-0-Korruption
JME-Invariantverletzung
Verifier-/DescriptorStore-Korruption
nicht wiederherstellbarer VM-interner Zustand
Meta-, Constitution-, Provider- oder Userland-Fehler sind normalerweise Diagnostics, Build-Fehler, Traps oder lokal isolierte Runtime-Fehler. Sie sind kein Freifahrtschein zum Prozessabbruch.
12. Debug als Referenz¶
Debug-Ausführung ist die Referenzsemantik. Release-Ausführung muss beobachtungsäquivalent sein.
Unterschiede bei beobachtbarem Verhalten sind Compiler-, VM- oder Runtime-Bugs. Optimierung darf Semantik nicht neu erfinden, nur vorhandene Semantik effizienter darstellen. Tragisch, dass man das überhaupt aufschreiben muss, aber Optimierer sind bekanntlich optimistisch bis zur Strafbarkeit.
13. JadeOS und Jade Node¶
JadeOS ist initial kein eigener Kernel. JadeOS ist die verteilte Betriebsform von Jade Nodes:
Jade Node = ausführende Zelle
JadeOS = Mesh aus Nodes, SystemSpecs, ContentStore, Policies und Generations
Ein Node konsumiert Blueprints, SystemSpecs und Artefakte, materialisiert Descriptoren, prüft Policies und führt Services aus.
Langfristige Bare-Metal- oder eigene Kernel-Unterlagen sind nicht ausgeschlossen, aber nicht der Kern der JadeOS-Idee. Die Charta darf JadeOS nicht als Vorwand nutzen, um Jade 0.1 mit zukünftiger Kernel-Fantasie zu belasten. Erst die Node- und Mesh-Schicht muss tragen.
14. Versionierung und Änderungen¶
Diese Fassung ist v2.3.
Änderungen an der Charta müssen enthalten:
- Versionsnummer,
- betroffene Prinzipien,
- Grund der Änderung,
- Auswirkungen auf bestehende Specs,
- Migrationshinweise für ConstitutionDescriptoren, falls relevant.
15. Glossar¶
Ring 0¶
JME-zentrierter Maschinen- und Integritätskern in Zig. Enthält die JME als zentrale Autorität sowie mechanische Substrate wie VM-Loop, Scheduler-Kern, RuntimeBus, Intrinsic Dispatch, CompilerDB-Storage, Bootstrap Seed und Host-Integration.
Ring 1¶
JDL-seitige Semantik- und Descriptor-Schicht. Enthält compilernahe Engines und Systemmodule in jade::.
Ring 2¶
User-facing Stdlib (jdl::) und Anwendungscode. Darf weiter einschränken, aber keine tieferen Ringregeln lockern.
Blueprint¶
Getypte deklarative Beschreibung. Beschreibt Absicht, nicht Ausführung. Serialisierbar, ohne gefangene Closures.
Engine¶
Typisierte Auswertungsinstanz. Ring-neutraler Begriff; konkrete EngineDefinitions gehören zu konkreten Ring-Kontexten.
Descriptor¶
Geprüfter materialisierter Vertrag zwischen JDL-Semantik und Ring-0-/Compiler-/Runtime-Mechanik.
Meta-Phase¶
Die Compile-Zeit-Phase, in der def ... ->Meta{...} läuft. Meta-Werte sind gewöhnliche JDL-Werte; die Phase steht am Pfeil, nicht am Schlüsselwort.
MetaContext¶
Compile-Time-Kontext einer Meta-Funktion. Enthält die eingeschränkte db-Fassade, das Ziel-Subject bei Refinements und den Proof-/Diagnostic-Kontext.
Semantic View¶
Typisierte semantische Projektion eines Compiler-Subjects für eine Analyseachse. Technisch eine gewöhnliche Derived Query mit kanonischem Ergebnis, kein eigener Ring-0-Mechanismus und kein Sprachkeyword.
Proof Obligation¶
Eine konkrete Aussage, die eine Proof-Regel zusätzlich nachweisen muss. Sie wird über vorhandene Fakten beziehungsweise weitere CompilerDB-Queries erfüllt oder bleibt unbewiesen.
Proof¶
Nachvollziehbare Ableitung einer semantischen Aussage aus Fakten und erfüllten Obligations. Provenance erklärt die Ableitung; sie ist nicht Teil der ausführungsnotwendigen Semantik.
ConstitutionSpec¶
Blueprint, der Regeln für einen Ring oder Namespace deklariert.
ConstitutionDescriptor¶
Materialisierte, geprüfte und indexierte Regelbasis, die Compilerphasen konsumieren.
MaterializationPatch¶
Geprüfte Änderungsabsicht an Meta-, Type-, Provide-, Dispatch-, Constitution- oder Artifact-Descriptoren. Patches werden durch den Materializer atomar committed.
Änderungsprotokoll¶
Version 2.3¶
- Betroffenes Prinzip: §1, „Descriptoren verbinden Semantik und Mechanik“. Neu §8.4 macht daraus eine Prüfung mit fünf Fragen und hält fest, dass eine semantische Zusage erst vollständig ist, wenn ihr materialisierter Vertrag und ihre mechanische Durchsetzung benannt sind.
- Grund: Beim Entwurf der Blueprint-Components und des nativen Ausführungsvertrags erfüllte eine Zusage alle oberen Stufen und hatte trotzdem weder Platz im Descriptor noch Mechanik in Ring 0. Die Prüfung hat beim ersten Einsatz beide Fehlerklassen gefunden.
- Auswirkungen auf Specs: keine unmittelbaren Änderungen. Neue Mechanismen müssen die fünf Fragen beantworten. Bereits betroffen und nachgezogen:
jdl-vm-scheduler-specv0.3.0, FFI-Spec v0.2.0,06-jme-handles-tags§12,jade-fehlermodellv0.4.0. - Migrationshinweise für ConstitutionDescriptoren: keine.
- Offen: §8.2 nennt die FFI-Engine
FfiBindingEngine, die FFI-SpecFfiEngine.
Version 2.2¶
-
§2.2 an die bereits getroffene Linux-only-Entscheidung angeglichen; die ältere POSIX-Formulierung war zu weit.
-
§1 schärft die Self-Hosting-Grenze: Ring 0 besitzt Query-/Provider-Mechanik, nicht das semantische Vokabular von Analysen.
- §1 präzisiert Semantic Views/Proof-Semantik als JDL-seitiges Analysevokabular über der generischen CompilerDB-Mechanik; kein View-spezifischer Ring-0-Typ und kein neues Sprachkeyword. Vollständig JDL-definierbare neue Query-Verträge setzen jedoch eine noch zu schließende generische CompilerDB-Vertragsregistrierung voraus.
- Proofs werden als JDL-seitige Ableitungen aus Views/Fakten und Proof Obligations eingeordnet. Proof-Judgements bleiben fachdomänenspezifisch; ein fehlender Beweis ist kein Gegenbeweis.
- CompilerDB-Query-Zyklen bleiben Fehler. Fachanalysen, die einen lokalen Fixpunkt benötigen, müssen ihn als begrenzte, terminierende Berechnung innerhalb eines Providers ausführen.
- Glossar um Semantic View, Proof Obligation und Proof ergänzt.
Version 2.1¶
- Ring 0 auf Zig umgestellt. Betrifft §1, §6.1, §9.2 und das Glossar. Die vorige Fassung nannte durchgehend D.
typefnals eigenes Konstrukt entfernt. §7 beschreibt stattdessen die Meta-Phase am Pfeil;TypeFnEvaluatorheißtMetaEvaluator,TypeFnContextheißtMetaContext.- §3 an den Descriptor gebunden statt an einen Zeitpunkt: „Kein Wert existiert, bevor sein Descriptor geprüft ist." Die frühere Formulierung setzte ein Ende der Übersetzung voraus, das es in einem laufenden Kontext nicht gibt.
- §3.1 neu: Was bei einer fehlgeschlagenen Prüfung im laufenden Kontext passiert, ist offen.
- §3.2 neu: Das fehlende Speichermodell als offene Flanke von „kein undefiniertes Verhalten".
- §5 ergänzt: Die Verifier-Grenzen sind Punkte in der Pipeline, nicht in der Zeit.
- §7.1 neu: Meta-Werte sind JME-Werte, mit der Folge, dass beim Übersetzen eine VM läuft — und mit der Begründung, warum der Seed davon ausgenommen ist.
- §7.2 neu: Compilerkontext zur Laufzeit, geteilter Seed, getrennter Bestand. Dazu die Abgrenzung, warum ein Sprachserver keine dynamischen Typen braucht.
- §9 auf Einordnung reduziert. Regelform, Selektor, Prädikat, Trigger und Vererbung stehen jetzt in
spec-constitution-system. - §9.1 ergänzt: Der TypeKind
: constitutionexistiert nicht. - §9.5 neu: Die Ring-1-Constitution prüft sich unter Self-Hosting selbst. Offen.
- §9.6 neu: Sichtbarkeit ist Verfassungssache.
pubundpackageentfallen als Keywords. - §9.7 neu: Abgrenzung zum Typsystem.
- §6.2 ergänzt: Was die Handle-Entscheidung kostet, und warum das kein Mangel ist.
- §10 auf das Grenzmodell umgestellt — eine Grenze zwischen Anwenderraum und
jade::, keine Erlaubnisleiter. Gilt auch für FQN.
Version 2.0¶
Constitution als blueprint-basiertes System eingeordnet, Ringe geschärft, ConstitutionEngine eingeführt, Monotonie definiert, JadeOS als Mesh korrigiert.
Version 1.3¶
Historische Fassung mit Blueprint-Engine-Architektur und alter Ring-2-Engine-Zuordnung.
Ende der Jade Design Constitution v2.2