Zum Inhalt

JDL — Context-Modell

Status: Draft, konsolidierte Kernfassung Geltung: Was ein Context ist, wie er zur Effect Row steht, wie Grenzen zwischen Contexts verlaufen und welche Rolle Engines darin spielen. Ersetzt: jdl-runtime-descriptor-context-engine-notiz-v2 §16–21. Die Notiz bleibt Materialquelle für alles andere. Nicht hier: Effect-Row-Semantik (jdl-effect-rows-und-throw), Scheduler-Mechanik (jdl-vm-scheduler-spec), Constitution (spec-constitution-system), Resource-/Autoritätssemantik (spec-resource-model), Bridge-Details (spec-context-bridge), Storage/MemoryRegion (jdl-storage-memoryregion-empfehlung), Multi-Entrypoints (design-context-entrypoints), Meta-/Envelope-v0.2 (addendum-context-meta-v0.2).

Kennzeichnung

Marke Bedeutung
[N] normativ, gilt
[D] Entscheidung dieser Fassung
[O] offen

Syntaxbeispiele sind spekulativ, solange die betreffenden Grammatiken nicht normiert sind.

Stand 2026-09-23: Diese Fassung ergänzt Context-Components und ihre Beitragsalgebra (§12a). Der zugrunde liegende Kompositionsmechanismus steht in jdl-blueprint-spec v0.4.0 §4 und ist dort als Ganzes noch Vorschlag. Die hier getroffenen Entscheidungen gelten unter der Voraussetzung, dass er übernommen wird.

Inhaltsverzeichnis

0. Auf einen Blick

0.1 Der eine Satz

Ein Context ist die geprüfte, descriptor-materialisierte Umgebungsgrenze einer Ausführungsdomäne.

Er sagt, was hier existieren darf. Eine Engine sagt, was gerade passiert. Die Maschinenarbeit machen weder er noch sie — die bleibt bei VM, JME, RuntimeBus und Scheduler-Kern.

0.2 Die Aufteilung

Ebene Frage Rolle
Context Was darf hier existieren und benutzt werden? geprüfte Umgebungsgrenze
Engine Was geschieht innerhalb dieser Grenze? Ausführungssemantik
Ring 0 Wer führt es mechanisch aus? VM, JME, RuntimeBus, Scheduler

Es gibt eine Art Context. Drei Beziehungen können zwischen zweien bestehen — Feld, Spezialisierung, Ableitung (§10). Wo eine echte Grenze liegt, ist eine Bridge der einzige Pfad darüber (§9).

0.3 Der Weg dorthin

Context-Blueprint
    ↓  ContextEngine — validiert, prüft gegen Elternteil
ContextDescriptor
    ↓  gelesen von
ContextApi · Engines · JME · Scheduler

Derselbe Weg wie bei Typen, Constitutions und allem anderen: beschreiben, prüfen, materialisieren. Kein neuer Mechanismus.

Teil I — Was ein Context ist

1. Grundsatz [N]

Ein Context ist keine neue Runtime und kein globaler Service-Locator.

Statisch ist sein Vertrag, nicht notwendig seine Materialisierung: Ein Context kann beim Übersetzen fertig sein, beim Laden entstehen oder erst zur Laufzeit adressiert werden (§5). Was in jedem Fall gilt, ist die Prüfung — sie wandert mit dem Descriptor, nicht mit der Uhr.

Er beantwortet statisch:

Welche Services sind sichtbar?
Welche Resource-Bindungen werden bei Aktivierung materialisiert?
Welche Engines dürfen laufen?
Welche Scheduler-Strategie gilt?
Welche Storage-Rollen sind wie gebunden?
Welche Runtime-Typprojektionen werden exportiert?
Welche Kommunikationswege sind erlaubt?
Was gibt der Elternteil frei?

Er führt nichts davon aus. Er liefert die geprüfte Verdrahtung.

2. Context ist ein Blueprint [D]

// spekulativ
type WebContext : blueprint {
    services:     ServiceSet
    resourceBindings: ResourceBindingSpec
    engines:      EngineSet
    storage:      StorageBindingSpec
    scheduler:    SchedulerConfig
    bridges:      [BridgeSpec]
    reification:  ReificationProfile
    limits:       ContextLimits
    parentExpose: ExposeSpec
} :> ExtensibleVia(ContextContribution)

messaging steht nicht mehr im Root [D]. Nachrichtenversand braucht nicht jeder Context; er wird voraussichtlich eine Component (§12a). Was inhaltlich dazugehört, ist offen (§C-13).

:> ExtensibleVia(ContextContribution) macht den Context-Blueprint erweiterbar: Weitere Fähigkeiten docken als Components an, statt als Felder im Root zu stehen (§12a).

resourceBindings beschreibt ausschließlich, wie Resources bei der Aktivierung einer Context-Instanz provisioniert, übernommen, gebunden oder attenuiert werden. Konkrete Handles sind Runtime-Zustand und gehören nicht in den kanonischen Descriptor. Die allgemeine Resource-/Autoritätssemantik steht in spec-resource-model.

Es gibt kein Schlüsselwort context blueprint. Es gibt blueprint; die Rolle ergibt sich aus Struktur, Refinements und Provides — genau wie bei der Constitution.

Die materialisierende ContextEngine ist eine DescriptorEngine: Sie beschreibt und prüft den ContextDescriptor, besitzt aber keinen eigenen Engine-instantiate-Pfad. Zur Laufzeit kann der Descriptor eine ContextInstance aktivieren; diese Aktivierung erzeugt Umgebung, Bindings und Runtime-Zustand, aber keinen „laufenden Context-Code“.

2.1 Die Wurzel zur Laufzeit [D]

Der Root-Context ist der deklarative Einstiegspunkt. Für v0.1 entdeckt Compiler/Loader ihn in main.jdl:

// spekulativ — Form aus jdl-design-note §3.4
type Main : blueprint {
    api:    ApiService { ... }
    db:     DbPoolSpec { ... }
    actors: ActorSpec  { ... }
} :> ResourceLimits { maxTasks: 10000 }

Das ist kein zweites Konstrukt neben dem Context, sondern derselbe: Services, Engines, Limits, dasselbe Schema.

Der Context wird also nicht in main() aufgebaut, sondern ist der Einstiegspunkt. Würde main() ihn im Rumpf aufmachen, wäre die Wurzelumgebung eine Anweisung; als Blueprint ist sie eine Beschreibung, die vor dem ersten Befehl geprüft ist.

Für einfache Programme bleibt der imperative Einstieg def main() ->{} i32. Dort gilt der Default-Root-Context.

Regel X-13. Ein Artefakt hat genau einen Einstiegspunkt. Beide Formen zugleich sind ein Fehler, keine Ergänzung.

Wie der Compiler Main als Context-Blueprint erkennt — über einen reservierten Namen in main.jdl, über ein Protokoll oder über ein provide — ist nicht entschieden (§C-8).

Die leere Row von main ist der Beweis, nicht der Mechanismus. ->{} sagt: Nichts blieb ungebunden. Was darunter {Db} verlangte, hat der Root-Context eingelöst. Die Signatur ist die Stelle, an der Regel X-2 zuschnappt.

Daraus folgt auch, was main nicht hat: keine Service-Parameter. Ein main(io: Io) wäre eine Bindung als Argument statt über die Umgebung.

Offen (§C-9): Der Rückgabetyp steht in den Dokumenten dreifach — i32, i64 und ExitCode.

2.2 Die Wurzel der Meta-Phase [D]

Auch Meta-Code läuft in einer Umgebung: Sie legt fest, welche db-Operationen erlaubt sind, welche Storage-Rollen gebunden sind und welche Host-Resources überhaupt erreichbar sind.

Sie wird nicht vom Nutzer deklariert. Was Meta-Code darf, ist die Grenze, die die Ringschichtung zieht; könnte ein Projekt sie selbst aufmachen, könnte es sie verschieben. Der Meta-Context wird in der Stdlib deklariert und ist nicht überschreibbar — dieselbe Bauart wie bei jade build: kein eingebauter Sonderfall, sondern ein privilegierter Lieferant.

Der Zirkel und seine Auflösung. Der Meta-Context müsste existieren, bevor der erste Meta-Aufruf läuft — entsteht aber aus einem Blueprint, und Blueprint-Materialisierung ist Meta-Arbeit.

Regel X-7. Der Meta-Context ist ein Seed-Eintrag. Er wird einmal in JDL beschrieben, beim Prägen materialisiert und danach von Zig nur noch gelesen.

Damit baut Zig ihn nicht zusammen, sondern liest einen Deskriptor — dasselbe Muster wie bei den Primitiven, und ohne einen zweiten Bootstrap-Zustand.

Die Alternative wäre ein zweistufiger Bootstrap: ein minimaler, in Zig verdrahteter Meta-Context, gerade groß genug, um den eigentlichen zu materialisieren. Sie ist verworfen, weil sie bei jedem Start durchlaufen werden müsste — für eine Umgebung, die sich nie ändert.

Ein Projekt, das den Meta-Context verschärfen will, tut das über seine Constitution. Das ist der Ort dafür.

2.3 Meta und Laufzeit laufen nebeneinander [D]

Der Meta-Context ist keine Vorstufe, die endet, wenn die Laufzeit beginnt. Es gibt keinen Umschaltpunkt.

Weil Meta-Werte JME-Werte sind, läuft beim Übersetzen bereits eine VM (12 §7.1). Der Laufzeit-Context entsteht neben dem Meta-Context, nicht an seiner Stelle.

Am deutlichsten in der REPL: Dort existieren beide gleichzeitig und dauerhaft, und es wird ständig zwischen ihnen gearbeitet. Ein Sprachserver hat überhaupt kein Ende der Übersetzung — sein Meta-Context lebt so lange wie der Prozess.

3. Profile sind Ausgangspunkte, keine Kategorien [D]

Context-Profile sind vordefinierte Ausprägungen eines Schemas, keine eigenen Konstrukte.

Sie sind auch kein Menü, aus dem man eines wählt. Sie sind Bausteine, die man spezialisiert (§10.2): Ein AdminContext ist ein WebContext mit einer zusätzlichen Fähigkeit als Component, ein WorkerContext ein ActorContext mit anderer Scheduler-Strategie als gesetztem Wert.

Achtung, Namenskollision: „Profil“ heißt hier eine vordefinierte Context-Ausprägung. In jdl-blueprint-spec §3.6 heißt „Blueprint-Profil“ eine Ableitung, die nur Werte setzt. Das sind zwei verschiedene Dinge (§C-14).

ApplicationContext   allgemeiner Rahmen
WebContext           HTTP, Routing, Middleware, Request-Scopes
CliContext           Args, StdIO, ExitCode, Config
ReplContext          Compilerkontext, Debug, Inspection
PluginContext        isolierte Plugin-Ausführung
FfiContext           ABI, Marshal, Hostgrenze
TestContext          deterministischer Scheduler, Seeds, Mock-Bridges
ActorContext         Mailbox, Isolation, Message Passing

Die Liste ist beispielhaft und keine geschlossene Menge. Ein Profil rechtfertigt sich nur, wenn §20 tatsächlich eine eigene Ausführungsgrenze begründet.

Teil II — Die Naht zur Effect Row

Dies ist der Teil, der bisher fehlte. Effect Rows und Contexts beschrieben dasselbe von zwei Seiten und trafen sich nirgends.

4. Ein Context ist ein deklarierter Handler-Satz [D]

Regel X-1. Der ContextDescriptor ist die äußerste Service-Handler-Installation. Seine Service-Bindungen eliminieren die verbleibenden Service-Elemente der Row. Resource-Bindings beschreiben zusätzlich, welche laufzeitgebundenen Resources in dieser Domäne erreichbar oder materialisierbar sind; sie sind selbst keine Row-Elemente (§6.2).

Eine Row wird von innen nach außen abgebaut: Jede Handler-Installation eliminiert die Elemente, die sie beantwortet. Was oben ankommt, hat niemand beantwortet.

Der Context ist das Oben. Er installiert keine Handler in Form von Code, sondern deklariert, welche gebunden sind. Der Unterschied zu einem geschriebenen Handler ist die Schreibweise, nicht die Wirkung.

Damit ist die Naht keine neue Maschinerie, sondern eine Benennung: Dasselbe, was ein with-Block lokal tut, tut ein Context für seine Domäne.

5. Wann geprüft wird [D]

Regel X-2. Was eine Row an der Grenze eines Contexts noch enthält, muss der ContextDescriptor binden. Sonst ist es ein Fehler.

Wann er auftritt, hängt davon ab, wie viel statisch bekannt ist:

Lage Zeitpunkt Form
Context statisch bekannt Übersetzung Compilerfehler
Context erst beim Laden bekannt Ladezeit Ladefehler
Context erst zur Laufzeit adressiert Laufzeit Trap am Context-Gate

Die dritte Zeile ist kein Rückfall. Sie ist die Lesart der Zusage aus der Charta: Kein Wert existiert, bevor sein Descriptor geprüft ist — die Prüfung wandert mit dem Descriptor, nicht mit der Uhr.

Sie ist auch der Ausnahmefall, nicht der Normalfall. Wo Context-Blueprints ineinander verschachtelt sind (§10), liegen beide Deskriptoren beim Materialisieren nebeneinander: Die Monotonieprüfung und die Auflösung des Parent-Expose laufen statisch, bevor irgendetwas startet. Ein Trap am Gate bleibt für Contexts, die erst zur Laufzeit adressiert werden — ein nachgeladenes Plugin etwa.

6. Was nicht in einer Row steht [D]

6.1 Throw bindet kein Context

Ein Throw[E] wird nicht von einem Context gebunden. Fehler werden durch catch eliminiert, nicht durch eine Umgebung.

Regel X-3. Ein Context bindet Service-Elemente. Abortive Elemente muss der Code selbst behandeln.

Ein Context, der Throw binden könnte, wäre ein globaler Fehlerhandler — genau die Sorte unsichtbarer Kontrollfluss, die Jade an anderer Stelle ausschließt.

6.2 Resources und Autorität stehen nicht in der Row [D]

Regel X-8. Eine Row führt Services. Laufende Resources und die von ihnen getragene Autorität sind keine Row-Elemente.

Row         semantische Abhängigkeit
Resource    laufzeitgebundene Entität
Autorität   Eigenschaft einer autoritätstragenden Resource / ihres Handles

Eine Funktion schreibt beispielsweise ->{FileSystem}. Ob der gebundene Service auf einer DirectoryResource, einem Remote-Endpoint oder rein internem Zustand arbeitet, gehört zur Materialisierung seiner Umgebung.

Die allgemeine Regel lautet: Nicht jede Resource trägt sicherheitsrelevante Autorität; konkrete Runtime-Capability wird jedoch nur über einen Resource-Träger ausgeübt. Details, Attenuation und Transfer gehören in spec-resource-model.

7. Was der Context nicht abnimmt

Er bindet Elemente, er erfindet keine. Eine Funktion mit {Db} in der Row braucht diesen Eintrag weiterhin in ihrer Signatur; der Context macht ihn nur einlösbar.

Das ist der Unterschied zu einer Ambient-Umgebung: Die Anforderung bleibt sichtbar, nur die Erfüllung wandert an einen Ort.

Teil III — Grenzen

8. ContextApi — lokales Gate [N]

Die ContextApi ist die interne Gate-Oberfläche, über die Engines und Runtime-Komponenten gegen den materialisierten Context arbeiten. Ihre konkrete API ist offen.

Sie prüft insbesondere:

Service-Binding
Resource-Slot / gebundene Resource
Handle-Adressierbarkeit
Lifetime- und Resource-Policy
Scheduler-/Storage-Limits

Regel X-20. Die ContextApi ist kein ambienter Resource-Service-Locator für gewöhnlichen JDL-Code. Autorität entsteht nicht durch ambienten Resource-Lookup, sondern durch explizite Bindung, legitime Ableitung oder expliziten Transfer eines Handles.

9. ContextBridge — Grenze zwischen Domänen [N]

Eine Bridge ist die ausdrücklich deklarierte, typisierte und policy-geprüfte Kommunikationsoberfläche zwischen isolierten Context-Domänen. Ohne Bridge gibt es keinen Kommunikationspfad.

Gewöhnliche Werte und lebende Resources sind verschieden:

Wert       → Codec / Kopie / Nachricht
Resource   → Lease / Transfer / SharedHandle nach expliziter Transferpolicy

Die vollständige Gruppen-, Richtungs-, Distanz-, Codec- und Transfersemantik steht in spec-context-bridge.

10. Drei Beziehungen zwischen Contexts [D]

Es gibt eine Art Context. Was sich unterscheidet, ist, wie zwei davon zueinander stehen — so wie ein Typ einen anderen als Feld tragen, von ihm abgeleitet sein oder Instanzen erzeugen kann, ohne dass es drei Typsysteme bräuchte.

Beziehung Contexts Grenze dazwischen Wofür
Feld (§10.1) zwei ja echte Isolation
Spezialisierung (§10.2) einer nein ein Profil an eine Domäne anpassen
Ableitung (§10.3) einer plus n ja, pro Instanz Request-, Task-, Session-Scopes

Alle drei entstehen aus vorhandenen Sprachmitteln. Keine ist ein eigenes Konstrukt.

Die englischen Kurzformen, falls sie in Diagrammen gebraucht werden: Composition, Profile Specialization, Scoped Derivation.

10.1 Feld — der Context enthält einen anderen

// spekulativ
type ApplicationContext : blueprint {
    web:    WebContext
    plugin: PluginContext
}

Es entstehen zwei Contexts mit zwei Deskriptoren. Zwischen ihnen gilt alles aus §9 und §11: Der innere sieht den äußeren nicht automatisch. Umgebungsbindung nach unten braucht Parent-Expose; Kommunikation nach der Aktivierung braucht eine Bridge.

Die Identität bleibt getrennt. Wer einen WebContext erwartet, nimmt keinen ApplicationContext an.

Diese Form ist richtig, wenn zwischen beiden tatsächlich eine Grenze liegen soll — etwa weil der innere einen engeren erreichbaren Resource-Graphen haben soll. Sie ist falsch, wenn man nur mehr Felder wollte: Dann hat man eine Grenze gebaut, die niemand braucht, und §20 spricht dagegen.

10.2 Spezialisierung — der Context ist ein erweiterter anderer

// spekulativ
newtype AdminContext = WebContext & Audit & { audit.retention = 90.days }
  • WebContext ist der Root und steht links.
  • & Audit dockt eine Fähigkeit als Component an (§12a).
  • & { ... } setzt Werte, hier ein Feld der Component.

Es entsteht ein Context. Ein Deskriptor, flacher Zugriff, keine innere Grenze.

Spezialisierung hat damit zwei Handgriffe [D]: Werte ändern ist ein Profil im Sinne der Blueprint-Spec (& { }, nur var-Felder). Fähigkeiten hinzufügen ist eine Component (& Audit). Die frühere Form WebContext & { audit: AuditService } fügte über & { } ein neues Feld hinzu und widersprach damit der Profil-Regel; sie entfällt.

Die Identität ist trotzdem neu, weil newtype eine eigene TypeId vergibt. Ein Alias wäre transparent, ist hier aber ausgeschlossen: Eine anonyme Form auf der rechten Seite eines Alias ist nicht zulässig (spec-namespaces-und-module).

Warum nicht „Verfeinerung". :> ist das Meta-Refinement; es verändert die Meta-Beschreibung eines Subjekts. Was hier passiert, ist etwas anderes: Aus einem Profil entsteht ein neuer Typ. Denselben Begriff für beides zu benutzen wäre genau die Doppelbelegung, die an anderen Stellen aufgeräumt wurde.

Die Monotonie gegen einen Elternteil hat hier nichts zu prüfen — es gibt keine zwei Ebenen. Stattdessen gelten die Merge-Regeln: Was der Spezialisierungsteil setzt, gewinnt gegen das Profil. Zwischen Benutzerwerten und Component-Anträgen gilt „Explizitheit vor Annahme“ (§12a.5). Bei scheduler und limits ist das eine echte Entscheidung, keine Formalie; dort überschreibt man Policies.

Die Identität über newtype ist mit jdl-blueprint-spec §3.6 noch nicht abgeglichen (dort offener Punkt 8).

Dies ist die Form, für die die Profile aus §3 gedacht sind.

10.3 Ableitung — der Context erzeugt viele kurzlebige

WebContext        eine Instanz, lange Lebensdauer
  └─ RequestContext   viele Instanzen, eine Anfrage lang

Ein RequestContext ist weder Feld noch Spezialisierung. Er entsteht pro Anfrage, lebt kürzer, und es gibt viele davon.

Das ist keine Blueprint-Komposition, sondern eine Lebensdauerbeziehung. Der Blueprint des Kindes steht trotzdem statisch fest — die Instanzen entstehen zur Laufzeit, der Deskriptor beim Übersetzen.

Regel X-6. Die statische Relation zwischen Parent- und Child-Descriptor wird einmal an der Beschreibung geprüft. Laufzeitlich provisionierte oder abgeleitete autoritätstragende Resources müssen ihre eigene Ableitungs-/Attenuationsregel beim Binden oder Erzeugen weiterhin einhalten; dafür wird nicht der gesamte Context-Vertrag pro Instanz neu analysiert.

Ein RequestContext kann also tausendmal instanziiert werden, ohne tausendmal seine Struktur neu zu beweisen. Ein dynamisch aus einer Root-Resource abgeleitetes Handle bleibt trotzdem an die Resource-Invarianten gebunden.

11. Parent-Expose gegen Bridge [D]

Zwischen Contexts gibt es zwei Wege, und sie sind verschieden. Ohne klare Trennung werden daraus zwei fast gleiche Türen mit unterschiedlichen Griffen.

Parent-Expose Bridge
Richtung nach unten, vom Elternteil zum Kind zwischen zwei Domänen
Was fließt Bindungen — Services, ResourceBindingSpecs, Policies Nachrichten, Queries, Commands; Resources nur über explizite Transferform
Vertrauenslage innerhalb derselben Vertrauensdomäne zwischen isolierten Domänen
Form eine Liste freigegebener Bindungen eine typisierte Oberfläche mit Policy
Beispiel WebContext gibt Logger an RequestContext ApplicationContext ↔ PluginContext

Regel X-9. Parent-Expose ist Aktivierungsbindung nach unten, keine Kommunikation. Eine Bridge ist Kommunikation nach beziehungsweise zwischen aktivierten Domänen.

11.0 Struktur ist keine Vertrauensbeziehung [D]

§10.1 zeigt einen PluginContext als Feld eines ApplicationContext. Genau dort ist Isolation der Zweck — und dann darf aus „ist Feld meines Contexts" nicht folgen „ist mein vertrauenswürdiges Kind".

Regel X-11. Feldkomposition erzeugt nur strukturelle Parentage. Sie verleiht keine Vertrauensbeziehung. Parent-Expose ist nur zulässig, wenn der Kindcontext als Trust-Descendant materialisiert wurde; sonst ist ausschließlich eine Bridge zulässig.

Ohne diese Regel wäre die Bridge umgehbar: Der Elternteil könnte dem Plugin Bindungen direkt zuschieben, statt sie über die geprüfte Oberfläche zu geben — und die ganze Isolation wäre eine Empfehlung.

Was offen bleibt: Woran ein Context als Trust-Descendant erkennbar ist. Der Kindcontext müsste es erklären, nicht der Elternteil — sonst hätte der Elternteil die Wahl, und die Regel wäre wieder weich. Ein PluginContext-Profil wäre seiner Natur nach isoliert. Wo dieser Marker sitzt, ist nicht entschieden (§C-5).

Ein Kindcontext sieht den Elternteil nicht automatisch. Der Elternteil muss gezielt exposen. Das gilt für §10.1 und §10.3; bei §10.2 gibt es keinen Elternteil, weil es keine zweite Ebene gibt.

11.1 Parent-Resource-Binding ist kein Runtime-Transfer [D]

Parent-Expose kann beim Aufbau einer vertrauenswürdigen Child-Domäne Services, Policies und ResourceBindingSpecs bereitstellen. Es darf jedoch nicht zum allgemeinen Kanal werden, über den nach der Aktivierung beliebige Handles nachgereicht werden.

Parent Resource
    ↓ bind / attenuate bei Aktivierung
Child Resource Slot

Regel X-10. Laufende Resource-Handles sind context-gebunden. Neuer Cross-Context-Transfer nach Aktivierung erfolgt nur über eine explizite Bridge-Transferform.

Die genaue Handle-, Attenuations- und Transfersemantik steht in spec-resource-model und spec-context-bridge.

12. Monotonie der Resource-Autorität [D]

Regel X-4. Monoton ist nicht die Anzahl der Resources, sondern die Autorität ihrer Herkunft und Ableitung. Ein Child darf neue lokale Resources erzeugen, aber keine stärkere privilegierte Autorität minten als seine legitimen Quellen erlauben.

Parent: Directory("/srv", read-write)
Child:  Directory("/srv/assets", read-only)   ✓
Child:  Directory("/", read-write)            ✗

Services darf ein Child lokal ergänzen. Eine neue Service-Bindung darf jedoch keine privilegierte Resource aus dem Nichts erzeugen.

Die formale Autoritätsableitung und Attenuation gehört in spec-resource-model.

12a. Context-Components und Beitragsalgebra [D]

12a.1 Warum Components für Contexts

Der Context-Blueprint ist der Blueprint mit den meisten unabhängigen Interessenten: Web, CLI, Plugins, Tests, Telemetrie. Ohne Komposition wächst er zu einem Feld pro Fähigkeit. Mit Components bleibt der Root klein, und Fähigkeiten docken an, ohne dass die ContextEngine angefasst wird.

Das beantwortet die Richtung von §C-1: Kern ist, was im Root steht. Was nicht jeder Context braucht, wird Component. Welche Felder im Einzelnen Kern bleiben, ist damit noch nicht vollständig entschieden.

Components passen zu §10.2, nicht zu §10.1: Eine Component ist Teil desselben Contexts, ohne innere Grenze. Ein Context als Feld bleibt ein eigener Context mit eigener Grenze.

12a.2 Anträge statt Behauptungen

Die Andockstelle ist ein Protokoll mit genau einer Beitragsmethode:

// spekulativ
protocol ContextContribution[C] {
    def contribute(component: C) ->Meta{Throw[DiagnosticSet]} ContextDescriptorFragment
}
  • C ist die Component, component enthält nur ihre eigenen Werte.
  • Das Ergebnis ist für alle Components dasselbe Formular, das ContextDescriptorFragment.

Das Fragment ist keine kleine Kopie des ContextDescriptors. Es enthält Anträge. Eine Component sagt nicht „der Context hat jetzt Netzwerkzugriff“, sondern „für meine Bedeutung wird Netzwerkzugriff benötigt“. Ob das bewilligt wird, entscheidet die ContextEngine gegen Elternteil, Monotonie (X-4) und Constitution.

Anträge auf Autorität heißen Resource-Anträge. Den Begriff „Capability“ verwendet das Fragment nicht; Autorität wird nur über Resource-Träger ausgeübt (§6.2).

Component → Provider → Fragment (Anträge) → ContextEngine → PatchSet → Materializer → ContextDescriptor

Die ContextEngine bleibt die einzige semantische Autorität über den Context. Sie kennt die Components nicht, nur die Anträge im Fragment.

Regel X-22. Der Context-Blueprint ist über ContextContribution erweiterbar. Beiträge von Components sind Anträge; über ihre Bewilligung entscheidet die ContextEngine.

12a.3 Vier Arten des Zusammenführens

Art             bei zwei Beiträgen                          
───             ──────────────────                          
Sammeln         beide kommen rein                           
Einer           gleich → einmal, verschieden → Konflikt     
Engste gewinnt  der strengere Wert gilt                     
Nur Kern        Components dürfen nicht beitragen

Alle vier liefern in jeder Reihenfolge dasselbe Ergebnis (jdl-blueprint-spec §4.10).

12a.4 Zuordnung

Teil Art Bemerkung
services Sammeln, pro Service Einer identische Bindung zählt einmal, verschiedene sind ein Konflikt
engines Sammeln, pro Engine Einer gleiche Engine mit anderer Konfiguration ist ein Konflikt
storage Sammeln, pro Rolle Einer Budgets darin: Engste gewinnt
scheduler Strategie Nur Kern der Context wählt die Strategie (§16)
scheduler Obergrenzen Engste gewinnt Components dürfen nur verschärfen
bridges Sammeln jede einzeln geprüft und sichtbar (§12a.6)
reification Einer
limits Engste gewinnt Components dürfen nur verschärfen
resourceBindings eigene Regel §12a.5
parentExpose Nur Kern
Trust-Descendant-Marker Nur Kern §C-5

Regel X-23. Scheduler-Strategie, Parent-Expose und Vertrauensstatus sind Kern. Components können dazu nichts beantragen.

Regel X-27. Beantragen zwei Components dieselbe Service-Bindung identisch, zählt sie einmal. Verschiedene Bindungen desselben Service sind ein Konflikt.

parentExpose und der Vertrauensstatus sind Kern, weil sie genau das regeln, was X-11 streng halten will: was an Kinder weitergereicht wird und wer als vertrauenswürdig gilt. Eine Component könnte sich sonst selbst zum Familienmitglied erklären.

Für Untergrenzen der Scheduler-Nutzung (§16.2, §C-7) ist noch keine Art festgelegt.

12a.5 Resources, Limits und Vorrang

Regel X-24. Resource-Anträge werden getrennt gebunden, nicht zusammengelegt. Jede Component erhält genau die beantragte Bindung, jede einzeln gegen die Autorität ihrer Herkunft geprüft.

Component A  →  /srv/data  lesen              → eigene Bindung A
Component B  →  /srv/data  lesen + schreiben  → eigene Bindung B

Zusammenlegen zur weitesten Berechtigung gäbe A Schreibrechte, die A nie beantragt hat. Das widerspricht X-4: Monoton ist die Autorität, nicht die Anzahl der Bindungen.

Vorrang. Es gilt „Explizitheit vor Annahme“ aus jdl-blueprint-spec §4.7: Benutzerwert vor Component-Antrag vor Vorgabewert des Roots. Bei limits heißt das: Beantragt eine Component maxTasks = 100 und setzt der Benutzer im Root ausdrücklich 10_000, gilt 10_000, mit Hinweis. Der Benutzer gewinnt gegen die Component, nicht gegen die Invarianten: Auch sein Wert wird gegen den Elternteil geprüft.

Regel X-26. Components dürfen Limits nur verschärfen. Ein ausdrücklich gesetzter Benutzerwert gewinnt gegen einen Component-Antrag, ein Component-Antrag gegen einen Vorgabewert des Roots.

12a.6 Sichtbarkeit autoritätsrelevanter Anträge

Eine Component wird nie heimlich angehängt; der Benutzer schreibt & Irgendwas selbst. Was sie beantragt, sieht er dabei aber nicht.

Regel X-25. Jeder autoritätsrelevante Antrag einer Component — Resource-Anträge und Bridges — wird dem Benutzer angezeigt, sinngemäß: „Diese Component beantragt eine Bridge zu X und Lesezugriff auf Y.“ Die Constitution kann solche Anträge zusätzlich verbieten.

Components aus Plugins dürfen Bridges beantragen. Jede Bridge wird einzeln geprüft und angezeigt.

Wie die Anzeige aussieht (Diagnose, Übersicht im Werkzeug, Eintrag in Mission Control), ist offen.

12a.7 Was damit nicht gelöst ist

Die ContextEngine prüft alle Anträge beim Übersetzen. Ob Ring 0 beim Binden noch einmal nachprüft, ist offen: spec-resource-model R-8 lässt den Ring-0-Mechanismus unbestimmt, R-O5 verschiebt die Durchsetzung. Solange das so ist, ist die ContextEngine der einzige Türsteher. Components ändern die Frage nicht, erhöhen aber den Einsatz, weil Anträge nun auch aus Plugins kommen (§C-12).

Teil IV — Engines

13. Foundation Engine Set v0.1 [D]

Eine Engine ist fundamental, wenn spezialisierte Engines ihre mechanischen Invarianten nicht selbst implementieren dürfen, sondern über sie beziehen müssen.

Das folgende Set erfüllt dieses Kriterium nach heutigem Stand. Es ist keine geschlossene ontologische Menge — ob etwa die CodecEngine im selben Sinn fundamental ist wie die SchedulerEngine, ist nicht erwiesen. Ein Engine-System, dessen wahre Grundklassen fest eingebrannt sind, wäre kein offenes.

Engine Zuständigkeit
SchedulerEngine Tasks, Yield, Join, Cancellation, Fairness, Backpressure
ConcurrencyEngine Taskgrenzen, Share/Send/Sync, Channels, Mailboxes
ResourceEngine with, Scopeable-Lifecycle, Cleanup, Drop-Garantien und Scope-Ende
StorageEngine MemoryRegion-, StorageRole- und StorageProfile-Semantik; Auflösung von Region-Bindungen
DispatchEngine statischer, generischer und dyn-Dispatch, Function Unions
CodecEngine Wire, Serde, Schema, Reification-Profile
EffectEngine Effektwerte, Service-Bindings, Handler-Kontext
TransportEngine Nachrichtenbewegung zwischen Contexts und Nodes

Offen (§C-6): Welche dieser acht das Fundamentalitätskriterium wirklich erfüllen und ob welche fehlen.

14. Engines komponieren, sie erben nicht [N]

HttpEngine  = RouteBlueprint + Scheduler + Codec + Resource + Middleware
ActorEngine = FunctionUnion  + Scheduler + Concurrency + Dispatch + MailboxPolicy
RpcEngine   = FunctionUnion  + Codec + Transport + Dispatch + Resource

Spezialisierte Engines besitzen nicht die ganze Welt selbst. Sie orchestrieren fundamentale Engines innerhalb eines Contexts.

Erweitert wird eine Engine über Protokolle und provide, nicht über Vererbung. Ihr Blueprint wird über Components erweitert (jdl-blueprint-spec §4, für Contexts §12a). Ein Provide darf keine fremden Descriptoren schreiben, keine Ring-0-Facts ändern und keine Host-Resource oder Resource-Autorität aus dem Nichts erzeugen.

15. Vier Ebenen des Wortes „Engine" [N]

EngineDefinition     JDL-Semantik und Provide-Implementierung
EngineDescriptor     materialisierter Vertrag aus Blueprint plus Refinements
EngineRuntimeConfig  Ring-0-Schedulerdaten: Limits, Timer-Wheel, Resource-/Execution-Bindings
EngineInstance       laufendes Ergebnis, sichtbar über ein Handle

Eine EngineDefinition darf keinen Ring-0-Zustand besitzen: keine Scheduler-Queues, keine Handle-Tabellen, keinen JME-Speicher, keine Filedeskriptoren, keinen RuntimeBus-Zustand, keine CompilerDB-Storage-Interna.

16. Der Scheduler bleibt dumm [N]

Der Scheduler kennt ausschließlich engineId → EngineRuntimeConfig. Er kennt keine semantische Engine.

Die Konfiguration entsteht über describe() beziehungsweise run(). Reduction-Limits und Timer-Wheels hängen an dieser Config, nicht an der Definition.

Die Scheduler-Konfiguration eines Contexts ist damit ein Feld im ContextDescriptor, das in EngineRuntimeConfig-Einträge zerfällt. Der Context wählt die Strategie, der Scheduler führt sie aus, und keiner von beiden kennt die Semantik des anderen.

16.1 Ein Scheduler, viele Contexts [D]

Es entsteht kein eigener Deskriptor pro Context. Die Aufteilung folgt dem Vier-Ebenen-Modell aus §15:

SchedulerEngineDescriptor    beschreibt die Mechanik:
                             welche Policies es gibt, welche Konfiguration
                             gültig ist, welche Invarianten gelten

ContextDescriptor.scheduler  beschreibt die Governance:
                             wie dieser Context diese Mechanik benutzen darf

Viele Contexts verweisen auf denselben Scheduler und bringen jeweils ihre eigene Konfiguration mit:

SchedulerEngineDescriptor
        ↑ referenziert
   ┌────┴────┬─────────┐
Context A  Context B  Context C
max 8      max 2      max 32
        └────┬────────┘
             ↓
      ein Scheduler, ein Worker-Pool

Ein Scheduler pro Context wäre verschwenderisch — jeder RequestContext bekäme einen Threadpool. Und ein Deskriptor pro Context nur wegen abweichender Limits würde Beschreibung und Deployment-Konfiguration vermischen; das Interning legte sie ohnehin wieder zusammen, sobald zwei Contexts dieselben Werte haben.

Der SchedulerEngineDescriptor beschreibt die Maschine. Der ContextDescriptor beschreibt, wie diese Ausführungsdomäne sie benutzen darf.

16.2 Eine Obergrenze ist keine Zusage [O]

Teilen sich mehrere Contexts einen Pool und hat jeder nur ein maxParallelism, können sie sich gegenseitig aushungern: Ein Context mit hohem Limit belegt den Pool, während ein anderer wartet.

Für einen Sprachserver ist das folgenlos — er darf warten. Für einen PluginContext, dem ausdrücklich nicht getraut wird, oder für einen Context mit Zeitanspruch ist es der Unterschied zwischen Isolation und Hoffnung.

Wer eine Untergrenze braucht, braucht ein anderes Feld: eine Reservierung, ein Gewicht oder eine Fairness-Klasse. Welche Form davon, ist offen (§C-7) — festzuhalten ist nur, dass sie in den ContextDescriptor gehört und nicht in die Scheduler-Implementierung. Sonst existierte eine Reservierung, die im Deskriptor nicht sichtbar ist, und niemand könnte prüfen, ob ein Context sie hat.

Für den Scheduler ändert das nichts. Er liest weiterhin nur EngineRuntimeConfig und führt aus; ob dort eine Obergrenze, ein Gewicht oder eine Reservierung steht, ändert seine Rolle nicht.

Teil V — Storage

17. Storage-Bindung im Context, mechanische Hoheit bei der JME [N]

Der Context wählt keine Typ-MemoryPolicy und besitzt keinen Allocator. Er bindet semantische StorageRoles an geprüfte Storage-Profile beziehungsweise materialisierte Regionen.

ContextDescriptor
└── storageBindings
    ├── Default  -> GeneralProfile
    ├── Scratch  -> ScratchProfile
    └── Request  -> RequestProfile

Die Speichermechanik selbst ist orthogonal beschrieben:

MemoryRegion
├── Backing
├── Allocation
├── Reclamation
├── Lifetime
├── Budget
├── Accounting
└── Guarantees

Rc und Weak gehören zur Ownership-Achse, nicht zur Allocation-Achse. Arena und Pool sind zusammengesetzte Region-/Allocation-/Reclamation-Muster, keine gleichrangigen Typ-Memory-Modi.

Regel X-21. Der Context bindet Storage-Rollen; die operative Speicherhoheit bleibt bei JadeME/Ring 0. Die vollständige Semantik steht in jdl-storage-memoryregion-empfehlung.

Explizite Kontrolle über eine Storage-Region kann über den Storage-Service in einer Effect Row sichtbar werden. Gewöhnliche implizite Allokation erzeugt allein deshalb keinen Storage-Eintrag in jeder Row.

Teil VI — Abgrenzungen

18. Context gegen Constitution [D]

Beide sind deklarative Regelwerke, beide monoton, beide über einen Blueprint materialisiert. Sie unterscheiden sich in Zeitpunkt und Gegenstand.

Die Trennung liegt nicht im Zeitpunkt. Ein Context kann vollständig beim Übersetzen materialisiert und geprüft sein (§5, §10). Sie liegt im Gegenstand.

Constitution Context
Gegenstand Programmstruktur Ausführungsumgebung
Frage Was darf hier deklariert werden? Was darf hier existieren und erreichbar sein?
frühester Prüfpunkt Übersetzung Übersetzung
spätester Prüfpunkt Artifact Emit Context-Aktivierung oder Gate
Wirkung zulassen oder verbieten binden oder begrenzen
Reichweite ein Namensraum samt allem darunter eine Ausführungsdomäne

Die Trennlinie: Die Constitution regelt, wie ein Programm entsteht. Der Context regelt, worin es läuft.

Eine Regel gehört nicht deshalb in die Constitution, weil sie dort früher greift. Derselbe Satz kann auf beiden Ebenen etwas Verschiedenes bedeuten, und beides kann zugleich gelten:

Constitution:  Dieses Projekt darf keinen Context deklarieren, der eine NetworkRoot-Resource bindet.
Context:       Diese Ausführungsdomäne besitzt keinen erreichbaren NetworkRoot.

Regel X-12. Eine Constitution kann einschränken, welche Context-Beschreibungen zulässig sind. Sie ersetzt keine Context-Invariante. Entscheidend ist der Gegenstand der Regel, nicht der früheste Prüfzeitpunkt.

Das ist dieselbe Haltung wie in §5: Die Prüfung wandert mit dem Descriptor, nicht mit der Uhr.

19. CompilerInstance ist eine privilegierte Resource [D]

Ein laufendes Programm kann einen zweiten Compilerbestand öffnen (12 §7.2) — Voraussetzung für einen eingebauten Sprachserver, für nachgeladene Plugins und für Nodes.

Regel X-5. Eine laufende CompilerInstance ist eine Resource. Zugriff auf Compilerautorität entsteht durch ein erreichbares CompilerInstance-Handle beziehungsweise einen ausdrücklich gebundenen Provider, nicht durch ein Boolean-Flag im ContextDescriptor.

Damit ist Compilerzugriff kein eigener Sondermechanismus und keine zweite Berechtigungsachse. Ein ReplContext kann eine entsprechende ResourceBindingSpec erhalten; ein gewöhnlicher Context nicht automatisch.

Eine Child- oder Plugin-Domäne erhält diese Autorität nicht automatisch. Soll eine CompilerInstance über eine Context-Grenze geteilt, geleast oder übertragen werden, greifen dieselben Resource-/Bridge-Regeln wie bei anderen autoritätstragenden Resources (spec-resource-model, spec-context-bridge).

Die genaue API, über die neue CompilerInstances erzeugt oder abgeleitet werden, ist damit noch nicht festgelegt. Entscheidend ist nur der Träger: konkrete Compilerautorität hängt an einer Resource und ihrer legitimen Bindungs-/Ableitungskette.

20. Context-Flut vermeiden [N]

Ein neues Context-Profil ist nur gerechtfertigt, wenn eine echte Grenze vorliegt:

eigene Resource-/Autoritätsgrenze
eigene Scheduler-Strategie
eigene Storage- oder Ressourcenpolicy
eigene Trust- oder Plugin-Grenze
eigene Kommunikationsform
eigener Compilerkontext

Kein neuer Context für Logging, JSON, Auth, Metrics oder einzelne Middleware. Das sind Services, Engines, Refinements, Policies oder Components.

Beispiel Metriken [D]: Domänen-Metriken meldet der Code über einen Service, den der Context bindet. Das Laufzeitverhalten wird von außen beobachtet. Ein Envelope ist dafür nur nötig, wenn unbeeinflussbar von außen gemessen werden soll, etwa bei einem Benchmark. Ausgeliefert werden Metriken über einen gewöhnlichen Endpoint.

Dasselbe gilt für Bridges. Eine Bridge, wo Parent-Expose gereicht hätte (§11), ist derselbe Fehler wie ein Context zu viel — und teurer, weil sie zusätzliche Wire-, Transfer- und Lifetime-Regeln erzwingt.

Context-Flut ist nur globale Unordnung mit besseren Substantiven.

21. Die Namensfrage [O]

Vier Dinge heißen heute „Kontext", und sie sind verschieden:

Heute Was es ist Vorschlag
Context Laufzeitumgebung einer Ausführungsdomäne behält den Namen
MetaContext Aufrufrahmen einer Meta-Funktion MetaFrame
Staging-Kontext Transaktion einer Plugin-Aktivierung StagingTransaction
Compilerkontext Instanz einer CompilerDB CompilerInstance

Unabhängig davon kollidiert „Profil“: Context-Profil (§3) und Blueprint-Profil (jdl-blueprint-spec §3.6) sind verschiedene Dinge (§C-14).

Der Laufzeit-Context sollte den Namen behalten, weil er der einzige ist, für den „Umgebung" die zutreffende Beschreibung ist. Die anderen drei sind Rahmen, Transaktion und Instanz.

Es sind vier Umbenennungen in vier Dokumenten.

Der Fall dafür ist stärker geworden, seit Context eine präzise Bedeutung hat. Ohne die Bereinigung liest man irgendwann: „Der MetaContext läuft im Meta-Context des Compilerkontexts während des Staging-Kontexts." Die Entscheidung liegt trotzdem beim Autor, nicht bei dieser Spec.

Anhang A — Normative Invarianten

  1. Ein Context ist eine geprüfte, descriptor-materialisierte Umgebungsgrenze, keine Runtime und kein Service-Locator.
  2. Ein Context wird als Blueprint beschrieben und von einer DescriptorEngine materialisiert.
  3. Der ContextDescriptor ist die äußerste Service-Handler-Installation.
  4. Verbleibende Service-Row-Elemente müssen an der Context-Grenze gebunden sein.
  5. Throw wird nicht vom Context gebunden.
  6. Rows führen Services; laufende Resources und Autorität sind keine Row-Elemente.
  7. ResourceBindingSpec beschreibt Aktivierungsbindung; lebende Handles gehören zur ContextInstance.
  8. ContextApi ist kein ambienter Resource-Locator für gewöhnlichen JDL-Code.
  9. Ohne Bridge gibt es zwischen isolierten Context-Domänen keinen Kommunikationspfad.
  10. Parent-Expose ist Aktivierungsbindung; Bridge ist Kommunikation und späterer Cross-Context-Transfer.
  11. Laufende Resource-Handles sind context-gebunden.
  12. Resource-Autorität darf bei Ableitung oder Transfer nicht verstärkt werden.
  13. Es gibt eine Art Context und drei Grundbeziehungen: Feld, Spezialisierung, Ableitung.
  14. Eine EngineDefinition besitzt keinen Ring-0-Zustand.
  15. Spezialisierte Engines komponieren fundamentale Engines.
  16. Der Scheduler kennt nur engineId → EngineRuntimeConfig.
  17. Der Context bindet Storage-Rollen; die Speichermechanik gehört in MemoryRegion/StorageProfile und wird von JadeME ausgeführt.
  18. Eine CompilerInstance ist eine privilegierte Resource.
  19. Ein neues Context-Profil braucht eine echte Ausführungsgrenze.
  20. Der Meta-Context ist ein Seed-Eintrag und nicht überschreibbar.
  21. Meta- und Laufzeit-Context können nebeneinander existieren.
  22. Eine Constitution schränkt zulässige Context-Beschreibungen ein; sie ersetzt keine Context-Invariante.
  23. Context-Components liefern Anträge, keine Behauptungen; die ContextEngine entscheidet.
  24. Scheduler-Strategie, Parent-Expose und Vertrauensstatus sind Kern und nicht beitragbar.
  25. Resource-Anträge werden getrennt gebunden, nie zu einer weiteren Berechtigung zusammengelegt.
  26. Autoritätsrelevante Anträge einer Component sind für den Benutzer sichtbar.
  27. Components dürfen Limits nur verschärfen; ein ausdrücklicher Benutzerwert gewinnt gegen einen Antrag, nicht gegen Invarianten.

Anhang B — Entscheidungsregister

Nr. Entscheidung
X-1 ContextDescriptor ist äußerste Service-Handler-Installation
X-2 Row-Reste an der Context-Grenze müssen gebunden sein
X-3 Throw wird nicht vom Context gebunden
X-4 Monoton ist Resource-Autorität, nicht Resource-Anzahl
X-5 CompilerInstance ist privilegierte Resource
X-6 Monotonie wird am Blueprint/Descriptor-Verhältnis geprüft, nicht pro gewöhnlicher Instanz
X-7 Meta-Context ist Seed-Eintrag
X-8 Rows führen Services; Resources/Autorität nicht
X-9 Parent-Expose ist Aktivierungsbindung, Bridge Kommunikation
X-10 Laufende Resource-Handles sind context-gebunden; späterer Transfer nur explizit
X-11 Feldkomposition verleiht kein Vertrauen
X-12 Constitution gegen Context wird nach Gegenstand getrennt
X-13 v0.1 besitzt genau einen Einstiegspunkt pro Artefakt
X-20 ContextApi ist kein ambienter Resource-Locator
X-21 Context bindet StorageRole/Profile; JadeME besitzt Speichermechanik
X-22 Context-Blueprint ist über ContextContribution erweiterbar; Beiträge sind Anträge
X-23 Scheduler-Strategie, Parent-Expose und Trust-Status sind nicht beitragbar
X-24 Resource-Anträge werden getrennt gebunden
X-25 Autoritätsrelevante Anträge sind sichtbar; Constitution kann sie verbieten
X-26 Limits nur verschärfbar; Vorrang Benutzerwert vor Antrag vor Root-Vorgabe
X-27 Gleiche Service-Bindung zählt einmal, verschiedene sind ein Konflikt

Anhang C — Offene Punkte

C-1 [O] ContextDescriptor-Schema. Richtung entschieden (§12a.1): Kern ist, was im Root steht, der Rest wird Component. Welche Felder im Einzelnen Kern bleiben, ist offen.

C-2 [O] Kanonische Form. Der ContextDescriptor braucht eine lauf-unabhängige kanonische Serialisierung.

C-3 [O] ContextApi. Konkrete interne Gate-Oberfläche ohne ambienten Resource-Lookup.

C-4 [O] Parent-Expose. Syntax und gespeicherte Form für Services, ResourceBindingSpecs und Policies.

C-5 [O] Trust-Descendant. Woran eine Domäne als zulässiger Empfänger von Parent-Expose erkennbar ist.

C-6 [O] Foundation Engine Set. Welche der derzeit acht Engines das Fundamentalitätskriterium wirklich erfüllen.

C-7 [O] Scheduler-Untergrenzen. Reservierung, Gewicht oder Fairness-Klasse.

C-8 [O] Root-Context-Discovery. Reservierter Name, Protocol oder provide.

C-9 [O] main-Rückgabetyp. i32, i64 oder ExitCode.

C-10 [O] Meta-Context-Name. Fester Stdlib-Ort/Name noch nicht vergeben.

C-11 [O] Begriffsbereinigung. MetaContext/MetaFrame, StagingTransaction und CompilerInstance konsistent migrieren.

C-12 [O] Durchsetzung beim Binden. Ob Ring 0 Resource-Autorität beim Binden nachprüft oder die ContextEngine der einzige Prüfer bleibt (§12a.7, spec-resource-model R-8, R-O5).

C-13 [O] Messaging. Was eine Messaging-Component enthält.

C-14 [O] Namenskollision „Profil“. Context-Profil und Blueprint-Profil brauchen verschiedene Namen.

C-15 [O] Syntaxabgleich. Die Beispiele in §2 und §2.1 (Felder ohne val/var, Initialisierung wie ApiService { ... }, ResourceLimits { maxTasks: 10000 }) folgen noch nicht jdl-blueprint-spec v0.4.0.

Bridge-spezifische offene Punkte stehen in spec-context-bridge; Resource-/Authority-Punkte in spec-resource-model; Storage-Fragen in jdl-storage-memoryregion-empfehlung; Multi-Entrypoints in design-context-entrypoints; Meta-/Envelope-v0.2 in addendum-context-meta-v0.2.

Änderungsprotokoll

2026-09-23 — Neu §12a Context-Components und Beitragsalgebra (X-22 bis X-27). messaging aus dem Root-Beispiel entfernt, Root als ExtensibleVia(ContextContribution) markiert. §10.2 auf zwei Handgriffe umgestellt (Werte per Profil, Fähigkeiten per Component); das alte Beispiel verletzte die Profil-Regel. §20 um das Beispiel Metriken ergänzt. Invarianten 23 bis 27, offene Punkte C-12 bis C-15, C-1 präzisiert.