Zum Inhalt

JDL — Addendum v0.2: Meta-abgeleitete Contexts und Context Envelopes

Status: Zukunfts-Addendum für eine mögliche Context-Modell-v0.2. Abhängigkeiten: spec-context-model, spec-resource-model, spec-context-bridge. Geltung: Erweiterung des Context-Modells um Meta-abgeleitete Context-Semantik, typisierte Context-Transformationen und das daraus ableitbare Muster eines Context Envelope. Nicht normativ für v0.1: Die Regeln dieses Anhangs ändern die v0.1-Invarianten nicht unmittelbar. Sie benennen, welche Erweiterung später kohärent möglich sein soll und welche v0.1-Entscheidungen diesen Weg nicht unnötig verbauen dürfen. Nicht hier: Die konkrete Syntax von Meta-Funktionen gehört in jdl-meta-phase; die genaue Query-, Patch- und Commit-Mechanik in die CompilerDB-Spec; konkrete Ordnungen für Scheduler-, Storage- und andere Policies in ihre jeweiligen Specs.

Dieses Addendum baut auf zwei Gedanken auf:

Ein Context muss nicht zwingend unmittelbar aus einer handgeschriebenen Quelltextdeklaration stammen. Entscheidend ist, dass seine Semantik über die CompilerDB-Fassade ausdrückbar und vor Verwendung durch dieselben Context-Invarianten materialisiert wurde.

und:

Ein Context Envelope ist kein zweiter Context-Mechanismus. Er ist ein Meta-Muster, das über die CompilerDB-Fassade eine äußere und eine innere Context-Domäne samt ihrer Beziehung konstruiert und anschließend durch den normalen Context-Materialisierungspfad prüfen lässt.

Damit bleibt die Architektur einspurig:

handgeschriebene Semantik ─────┐
                               │
Meta über CompilerDB-Fassade ──┼─→ ContextEngine → Materializer → ContextDescriptor
                               │
andere zulässige Ableitungen ──┘

Die Runtime sieht in allen Fällen materialisierte Context-Semantik. Die Entstehungsgeschichte ist Provenance, keine zweite Runtime-Semantik.

Inhaltsverzeichnis

E.1 Motivation

v0.1 denkt einen Context überwiegend von einer expliziten Blueprint-Deklaration her:

// spekulativ
type ApplicationContext : blueprint {
    ...
}

Das ist für den Anfang richtig. Discovery, Prüfung und Fehlermeldungen bleiben dadurch überschaubar.

Mit einer leistungsfähigen Meta-Phase entsteht jedoch ein zweiter legitimer Bedarf: Bereits bekannte Context-Semantik soll abgeleitet, kombiniert oder unter eine zusätzliche Grenze gestellt werden können, ohne Quelltext zu generieren und anschließend wieder einzulesen.

Beispiele:

ApplicationContext
    ↓ benchmarked(...)
Benchmark(ApplicationContext)

ApplicationContext
    ↓ sandboxed(...)
Sandbox(ApplicationContext)

WorkerContext
    ↓ traced(...)
Traced(WorkerContext)

Eine solche Ableitung kann unter anderem:

Policies verschärfen
Service-Bindings ersetzen
äußere Instrumentierung hinzufügen
Bridges für eine äußere Domäne definieren
Scheduler-Limits verändern
Storage auf Scratch-/Shadow-Bereiche umlenken
zusätzliche Context-Grenzen konstruieren
bestehende Context-Beziehungen zusammensetzen

Der Architekturgewinn entsteht nur, wenn dafür kein zweiter Konstruktionspfad eingeführt wird.

Nicht:

SourceContext
GeneratedContext
EnvelopeContext
SandboxRuntimeContext
...

sondern:

CompilerDB-Semantik
        ↓
ContextEngine
        ↓
ContextDescriptor

Die Meta-Phase erweitert damit nicht die Zahl der Context-Arten. Sie erweitert die Zahl der Wege, auf denen gültige Context-Semantik über die vorhandene CompilerDB-Oberfläche beschrieben werden kann.

E.2 Die CompilerDB-Fassade ist die Grenze der Meta-Konstruktion

Die zentrale Grenze ist nicht eine Liste dessen, was Meta „darf“ oder „nicht darf“.

Die CompilerDB-Fassade definiert positiv, welche Compilersemantik Meta lesen und konstruieren kann. Was die Fassade nicht ausdrücken kann, kann Meta nicht konstruieren.

Damit ist die Meta-Autorität strukturell gegeben:

Meta-Code
   │
   ▼
CompilerDB-Fassade
   │
   ├── lesbare Queries
   ├── ausdrückbare semantische Änderungen
   ├── materialisierbare Ableitungen
   └── sonst nichts

Eine zweite Verbotsmatrix neben dieser Fassade wäre doppelte Buchhaltung und langfristig gefährlich: Neue CompilerDB-Fähigkeiten müssten sonst zusätzlich in einer separaten Meta-Policy freigeschaltet werden, obwohl die Fassade bereits die Autoritätsgrenze ist.

E.2.1 Ausdrückbarkeit ist Autorität

Wenn die v0.2-Fassade etwa Operationen oder semantisch äquivalente Möglichkeiten für Folgendes bereitstellt:

Context-Subject lesen
Service-Bindings ableiten
Resource-Bindings entfernen oder attenuieren
Scheduler-Policy setzen
StorageSpec ableiten
Bridge-Bindungen konstruieren
Parent-Expose festlegen
Context-Limits setzen
Context-Beziehungen erzeugen

kann Meta diese Dinge konstruieren.

Fehlt eine solche Ausdrucksmöglichkeit, existiert sie für Meta nicht als konstruktive Operation.

Das gilt allgemein und nicht nur für Contexts. Ein Runtime-Handle, eine Scheduler-Queue oder ein offener Filedeskriptor brauchen keine zusätzliche Regel „Meta darf das nicht erzeugen“, solange solche lauf-lokalen Objekte schlicht nicht Teil der CompilerDB-Fassade sind.

Sollte die Fassade irgendwann bewusst eine neue semantische Operation exponieren, erweitert sich damit auch die konstruktive Macht der Meta-Phase. Das ist kein Umgehen der Architektur, sondern genau der vorgesehene Erweiterungspunkt.

E.2.2 Ausdrückbarkeit ist nicht Gültigkeit

Dass Meta etwas über die Fassade ausdrücken kann, bedeutet nicht, dass das Ergebnis gültig ist.

Meta-Funktion
    ↓
CompilerDB-Fassade
    ↓
semantischer Ableitungsinput
    ↓
ContextEngine
    prüft Context-Invarianten
    ↓
Materializer
    prüft Kohärenz, Ring, Constitution, Konflikte
    ↓
Commit oder Ablehnung

Damit liegen zwei verschiedene Fragen an zwei verschiedenen Stellen:

CompilerDB-Fassade:
    Kann Meta diese Semantik überhaupt formulieren?

ContextEngine / Materializer:
    Ist die formulierte Semantik gültig und commitfähig?

Die Meta-Funktion braucht also kein Sonderrecht, einen ContextDescriptor „für gültig zu erklären“. Es gibt dafür schlicht keinen alternativen Commit-Pfad.

E.2.3 Keine separate Negativliste für Meta

v0.2 sollte deshalb keine Architekturregel nach dem Muster pflegen:

Meta darf A
Meta darf B nicht
Meta darf C nur teilweise
Meta darf D nur für Contexts

Die belastbarere Regel lautet:

Meta-Autorität ist die Oberfläche seiner CompilerDB-Fassade. Validität entsteht durch die zuständigen Engines und den Materializer.

Damit kann die Meta-Phase mächtiger werden, ohne dass ihre Sicherheits- und Konsistenzgrenzen an immer mehr Stellen dupliziert werden.

E.3 ContextSubject: die sinnvolle semantische Grenze

Für Context-Transformationen braucht es begrifflich ein Subjekt, auf dem Meta arbeiten kann.

Dieses Addendum verwendet dafür den Arbeitsbegriff ContextSubject:

Ein ContextSubject ist ein semantisches Blueprint-Subjekt, das von der ContextEngine als Context-Beschreibung akzeptiert und materialisiert werden kann.

Der Begriff führt keinen neuen TypeKind ein. Er benennt eine Rolle gegenüber der ContextEngine und der CompilerDB-Fassade.

v0.1 kann faktisch nur explizit deklarierte Context-Blueprints als solche Subjects liefern. v0.2 könnte zusätzlich Meta-abgeleitete Subjects zulassen:

source-declared Blueprint ─┐
                          ├─→ ContextSubject → ContextEngine
meta-derived Blueprint ───┘

Damit bleibt die Aussage aus §2 im Kern erhalten:

Ein Context ist semantisch ein Blueprint.

Geändert wird nur die Herkunftsannahme.

Nicht mehr zwingend:

Jeder Context stammt unmittelbar aus einer handgeschriebenen Blueprint-Deklaration.

Sondern:

Jeder Context liegt der ContextEngine als gültig adressierbares Blueprint-Subject vor; dieses Subject kann aus Source oder aus einer zulässigen Meta-Ableitung stammen.

E.4 Typisierte Context-Transformationen

Eine Context-Transformation ist eine Meta-Ableitung, die über die CompilerDB-Fassade aus einem oder mehreren ContextSubjects neue Context-Semantik konstruiert.

Als rein spekulative Lesart:

// NICHT normativ
def sandboxed[T: ContextSubject](ctx: T)
    ->Meta{} ContextSubject

Der tatsächliche Rückgabetyp ist hier absichtlich nicht festgelegt. Die Meta-Funktion könnte über die CompilerDB-Fassade einen neuen semantischen Subject-Eintrag erzeugen und lediglich dessen Referenz liefern. Ein eigener Pflicht-Typ ContextSpec oder ContextForm ist für dieses Modell nicht notwendig.

Semantisch zählt:

ContextSubject C
      ↓ Meta
CompilerDB-Fassade
      ↓
abgeleitetes Subject C'
      ↓
ContextEngine
      ↓
geprüfte Context-Semantik

E.4.1 Transformation bedeutet nicht Mutation

Eine Context-Transformation verändert keinen bereits committeten ContextDescriptor an Ort und Stelle.

C ──transform──► C'

bedeutet:

C bleibt C
C' ist eine neue semantische Ableitung

Bei gleichem semanticPayload kann Interning wieder denselben kanonischen Descriptor liefern. Bei verändertem Inhalt entsteht ein anderer semantischer Eintrag.

Das ist notwendig für:

contentHash
Caching
Early Cutoff
Provenance
stabile Referenzen
reproduzierbare Artefakte

E.4.2 Transformationen sind komponierbar

Meta-Transformationen dürfen auf bereits abgeleiteten ContextSubjects arbeiten:

C
↓ benchmarked
B(C)
↓ sandboxed
S(B(C))

oder:

C
↓ sandboxed
S(C)
↓ benchmarked
B(S(C))

Die beiden Formen müssen nicht semantisch gleich sein.

Ein Benchmark kann etwa Performance-Counter benötigen, während eine Sandbox deren Nutzung begrenzt. Reihenfolge ist dann Semantik, keine kosmetische Decorator-Liste.

Jede Stufe bleibt eine gewöhnliche Meta-Ableitung mit gewöhnlichen CompilerDB-Abhängigkeiten.

E.4.3 Keine eigene Transformationssprache nötig

Die Schreibweise

E₂(E₁(C))

ist nützlich, weil sie Komposition sichtbar macht. Daraus folgt keine Verpflichtung, eine neue Algebra oder eigene Context-Transformationssprache zu normieren.

Für v0.2 reicht:

Meta liest semantische CompilerDB-Fakten
Meta konstruiert über die Fassade neue Semantik
ContextEngine prüft
Materializer committet oder lehnt ab

Mehr Mechanik wäre erst dann gerechtfertigt, wenn reale Anwendungsfälle sie erzwingen.

E.5 Context Envelope als Envelope-Meta-Muster

Der Begriff Context Envelope bleibt sinnvoll, aber nicht als eigener Runtime-TypeKind und nicht als zweiter Materialisierungspfad.

Ein Context Envelope ist das Ergebnis einer typisierten Meta-Transformation, die über die CompilerDB-Fassade eine äußere Context-Domäne um eine innere Context-Domäne konstruiert und ihre Beziehung anschließend durch die normale ContextEngine prüfen lässt.

Beispiel:

BenchmarkEnvelope
└── ApplicationContext

oder komponiert:

SandboxEnvelope
└── BenchmarkEnvelope
    └── ApplicationContext

Die Bezeichnung Envelope beschreibt die beabsichtigte und verifizierbare Relation, nicht eine neue Sorte laufenden Objekts.

E.5.1 Envelope Meta

Ein Envelope sollte generell durch eine Meta-Funktion beziehungsweise einen Meta-Provider konstruiert werden.

Spekulativ:

// NICHT normativ
def benchmarked[T: ContextSubject](subject: T)
    ->Meta{} ContextSubject

oder:

// NICHT normativ
def sandboxed[T: ContextSubject](subject: T)
    ->Meta{} ContextSubject

Die Funktion kann über die CompilerDB-Fassade beispielsweise:

einen äußeren Context ableiten oder erzeugen
den inneren Context als eingeschlossene Domäne referenzieren
Parent-Expose konfigurieren
Bridges der äußeren Domäne definieren
Service-Bindings substituieren
Limits verschärfen
Scheduler-/Storage-Policies setzen
Lifetime-Beziehungen beschreiben
Provenance der Ableitung hinterlegen

Sie bekommt dafür keine Envelope-Sonderrechte. Alles, was sie konstruiert, muss mit denselben CompilerDB-Operationen ausdrückbar sein, die Meta allgemein zur Verfügung stehen.

Das ist der entscheidende Vorteil: Ein Envelope ist keine privilegierte Hintertür in das Context-System, sondern eine wiederverwendbare Meta-Abstraktion über dessen normale Semantik.

E.5.2 Wann etwas wirklich ein Envelope ist

Nicht jede Context-Transformation ist ein Envelope.

WebContext
↓ maxTasks von 1000 auf 500 ändern
RestrictedWebContext

kann eine gewöhnliche Spezialisierung sein: ein Context, keine zusätzliche Grenze.

Ein echtes Envelope-Muster liegt vor, wenn die Meta-Ableitung eine äußere, eigenständige Context-Domäne erhält beziehungsweise konstruiert:

OuterContext
    │ kontrolliert / begrenzt
    ▼
InnerContext

Es existieren also weiterhin zwei Context-Domänen mit einer echten Grenze dazwischen.

Der Envelope-Begriff ist damit an einer überprüfbaren Aussage festzumachen:

zwei Context-Domänen
+ explizite äußere/innere Relation
+ kontrollierte Lifetime
+ normale Expose-/Bridge-Grenzen
+ keine unzulässige Resource-Autoritätserweiterung nach innen

E.5.3 Envelope erzeugt keinen Sonderpfad

Zwischen äußerem und innerem Context gelten weiterhin ausschließlich die normalen Regeln:

Parent-Expose        vererbte Bindungen innerhalb zulässiger Trust-Beziehung
Bridge               Kommunikation zwischen isolierten Domänen
ContextApi           lokale Admission
JME-/Handle-Regeln   tatsächliche Adressierbarkeit

Ein Envelope erhält keine geheime Zugriffsmöglichkeit auf den eingeschlossenen Context und der eingeschlossene Context keine Ambient-Sicht auf die Hülle.

Würde Envelope einen besonderen Zugriffskanal besitzen, wäre es keine Meta-Abstraktion mehr, sondern eine zweite Context-Mechanik mit einem freundlicheren Namen.

E.6 Die zentrale Envelope-Garantie: keine Resource-Autorität einschleusen

Für eine innere Domäne C unter einem Envelope E muss die effektive Resource-Autorität monoton bleiben.

Als Leitformel:

effectiveResourceAuthority(C under E)
    ≤
allowedResourceAuthority(C)

Das Symbol ≤ bedeutet hier „nicht permissiver als“ und noch keine allgemeine, bereits normierte Authority-Algebra.

Der Envelope darf Resources der inneren Domäne erhalten, durch attenuierte Ableitungen ersetzen oder entfernen. Er darf allein durch die Einhüllung keine neue Hostautorität nach innen minten.

Beispiel:

ApplicationContext
    DirectoryResource("/data", read-write)
    NetworkRoot("api.example.com:443")

zulässig:

Sandbox(ApplicationContext)
    DirectoryResource("/data/public", read-only)

nicht zulässig, wenn keine entsprechende Quelle existiert:

Sandbox(ApplicationContext)
    DirectoryResource("/data", read-write)
    RawPerformanceCounterSession   ← neue Autorität aus dem Nichts

Das ist keine neue Envelope-Regel neben §12, sondern eine Anwendung der bestehenden Resource-Autoritätsmonotonie auf eine Meta-abgeleitete Context-Struktur.

E.6.1 Eigene Autorität des äußeren Contexts

Die äußere Domäne darf eigene autoritätstragende Resources besitzen, ohne sie dem inneren Context zu verleihen.

Beispiel:

BenchmarkEnvelope
├── PerformanceCounterSession
├── CpuBindingResource
├── HighResolutionClockResource
│
└── ApplicationContext
    ├── Db
    └── Network

Die Messautorität liegt in den Resources des Benchmark-Contexts. Daraus folgt nicht, dass ApplicationContext deren Handles erreichen darf.

Daraus ergeben sich zwei getrennte Mengen beziehungsweise Graphen:

resources(outer)
resources(exposed-to-inner)

Nur weil eine Resource im ersten Graph erreichbar ist, darf sie nicht automatisch im zweiten erscheinen.

E.6.2 Prüfung am materialisierten Verhältnis

Die Garantie darf nicht davon abhängen, dass die Envelope-Meta „vernünftig programmiert“ wurde.

Die Meta-Funktion konstruiert lediglich Semantik. Die ContextEngine prüft das resultierende Verhältnis:

Meta erzeugt Vorschlag
      ↓
ContextEngine berechnet effektive Bindings / Resource-Erreichbarkeit
      ↓
Attenuation- und Monotonieprüfung
      ↓
zulässig oder Fehler

Dadurch bleibt auch fremde oder fehlerhafte Envelope-Meta innerhalb der normalen Compilerregeln.

E.7 Service-Bindings und Substitution

Ein Envelope kann Service-Bindings der inneren Domäne gezielt ableiten oder ersetzen, sofern der resultierende Vertrag gültig bleibt.

Beispiel:

ApplicationContext
    Db → PostgresDb

unter einem Benchmark-Envelope:

Benchmark(ApplicationContext)
    Db → InstrumentedDb(PostgresDb)

Der Compiler muss weiterhin beweisen:

InstrumentedDb provides Db

und anschließend prüfen, ob die konkrete Bindung ausschließlich mit Resources arbeiten kann, die im resultierenden Context legitim erreichbar oder zulässig ableitbar sind.

Der Envelope erzeugt damit keinen Ambient-Service-Locator. Er konstruiert gewöhnliche, explizite Context-Bindings über die CompilerDB-Fassade.

E.7.1 Shadow- und Test-Bindings

Dasselbe Muster erlaubt:

Db → ShadowDb
Clock → DeterministicClock
Network → MockNetwork
Storage → ScratchStorage

Damit lassen sich Test-, Benchmark- oder Experimentalvarianten bilden, ohne den Anwendungscode mit Betriebsmodus-Abfragen zu durchziehen.

Die Grenze bleibt §20: Eine kleine Produktoption rechtfertigt noch lange keine neue Context-Domäne.

E.8 Scheduler-, Storage- und Ressourcenpolicies

Für einige Policies ist „nicht permissiver“ trivial:

maxTasks:       100 ≤ 1000
maxMemory:      512 MiB ≤ 1 GiB
allowedCpus:    {2,3} ⊆ {0,1,2,3}

Für andere ist die Ordnung domänenspezifisch. Zwei Scheduler-Strategien lassen sich nicht automatisch durch einen Zahlenvergleich ordnen.

v0.2 sollte deshalb keine universelle Envelope-Policy-Algebra erfinden.

Stattdessen gilt:

Jede Policy-Domäne, deren Werte auf Monotonie geprüft werden müssen, definiert selbst, wann eine materialisierte Policy gegenüber einer anderen gleich oder restriktiver ist.

Die ContextEngine orchestriert diese Prüfungen; sie sollte die Semantik der einzelnen Policy-Domänen nicht duplizieren.

Damit wird das Envelope-Modell zu einem zusätzlichen Verbraucher einer Fähigkeit, die das Context-System ohnehin benötigt.

E.9 Bridges und Kommunikationswege

Ein äußerer Context kann eigene Bridges besitzen, ohne sie dem inneren Context sichtbar zu machen.

BenchmarkEnvelope
    │
    ├── Bridge → BenchmarkCollector
    │
    └── ApplicationContext
            kein Pfad zum Collector

Daraus folgt:

outer-owned bridges
≠
inner-visible bridges

Eine Meta-Ableitung darf natürlich Bridge-Semantik konstruieren, sofern die CompilerDB-Fassade dies zulässt. Die normale Bridge- und Context-Prüfung entscheidet anschließend, ob diese Bindung gültig ist.

E.9.1 Kein automatisches Durchreichen

Weder Services noch Resources noch Bridges des äußeren Contexts werden allein durch die Envelope-Relation nach innen sichtbar.

Sichtbarkeit entsteht weiterhin ausschließlich über die bestehenden Mechanismen:

Parent-Expose
Bridge
explizite zulässige Bindung

Sonst könnte ein Envelope spec-context-model X-10 beziehungsweise die Bridge-Regel „ohne Bridge kein Pfad“ indirekt aushebeln.

E.10 Lebensdauer

Ein echtes Envelope-Muster besitzt eine Lebensdauerbeziehung zur inneren Domäne.

Als starke Ausgangsregel:

lifetime(inner) ⊆ lifetime(outer)

Der eingeschlossene Context darf die Governance-Domäne, unter der er materialisiert wurde, nicht unkontrolliert überleben.

Beispiel:

BenchmarkEnvelope endet
        ↓
ApplicationContext unter diesem Envelope ist beendet
oder bereits vorher beendet

Andernfalls könnten Bindings, Limits oder Bridges verschwinden, während der vermeintlich eingeschlossene Context einfach weiterläuft.

E.10.1 Kein Live-Wrapping bestehender Instanzen

Dieses Addendum behandelt ausdrücklich nicht:

laufende ContextInstance C
        ↓
wrap(C)
        ↓
C läuft plötzlich unter neuer Grenze weiter

Ein solches Live-Wrapping müsste vorhandene Tasks, Handles, Bridges, Service-Caches, Scheduler-Zustand und Ressourceneigentum migrieren.

Das ist kein kleines Envelope-Feature, sondern ein eigenes Lifecycle- und Migrationsproblem.

Für v0.2 gilt daher:

Meta-Transformation vor Aktivierung; keine nachträgliche Mutation der Sicherheits- und Ressourcenhülle einer laufenden Context-Instanz.

E.11 Verifikationsweg eines Envelopes

Der Envelope-Pfad sollte vollständig aus vorhandenen Compilermechanismen bestehen.

Ein möglicher Ablauf:

1. inneres ContextSubject über CompilerDB-Fassade auflösen
2. Envelope-Meta ausführen
3. Meta liest benötigte CompilerDB-Fakten über die Fassade
4. Meta konstruiert über dieselbe Fassade:
      - äußeres Context-Subject
      - Beziehung zum inneren Subject
      - Bindings / Expose / Bridges
      - Policies / Limits / Lifetime
5. ContextEngine prüft die resultierende Context-Semantik:
      - Services
      - Resource-Bindings / Autorität
      - Parent-Expose
      - Bridges
      - Scheduler-Policy
      - Storage-Policy
      - ResourceLimits
      - Lifetime-Beziehung
      - Monotonie
6. Materializer prüft:
      - Ring-Ebene
      - Kohärenz
      - Patch-/Commit-Konflikte
      - Constitution
7. atomarer Commit oder vollständige Ablehnung
8. Provenance hält Query- und Transformationsweg fest

Wichtig ist, was nicht vorkommt:

kein Envelope-Loader
keine Envelope-Runtime
kein Envelope-Sonderstore
keine zweite Resource-Autoritätsprüfung
keine zweite Bridge-Semantik

Ein fehlgeschlagener Envelope bleibt dadurch erklärbares Compilerwissen:

sandboxed(ApplicationContext)
    ↓
Failed(ContextEngine)

reason:
    transformed binding requires HostPerfCounter
    resource authority not admissible under resulting policy

Mission Control oder :why kann genau diese Ableitung darstellen.

E.12 Verhältnis zu den drei Context-Beziehungen aus §10

v0.1 kennt:

Feld             zwei Contexts, echte Grenze
Spezialisierung  ein Context, keine innere Grenze
Ableitung        ein Context plus kurzlebige Instanzen

Meta-Transformationen ersetzen diese Beziehungen nicht. Sie können sie konstruieren.

E.12.1 Meta erzeugt Spezialisierung

Eine Transformation kann einen vorhandenen Context semantisch spezialisieren:

WebContext
    ↓ restrict(...)
RestrictedWebContext

Es entsteht weiterhin ein Context ohne zusätzliche innere Grenze.

E.12.2 Meta erzeugt Feldkomposition

Eine Envelope-Meta kann zwei Contexts mit echter Grenze konstruieren:

BenchmarkContext
└── ApplicationContext

Die resultierende Struktur benutzt die normale Feld-/Grenzsemantik aus §10.1 und §11.

E.12.3 Meta erzeugt Scoped Derivation

Eine Meta-Ableitung kann auch eine Lebensdauerbeziehung vorbereiten:

WebContext
└── RequestContext

Die Instanziierung bleibt Runtime-Arbeit; Meta beschreibt die zulässige semantische Beziehung.

E.12.4 Envelope ist deshalb zunächst keine vierte Grundbeziehung

Context Envelope bezeichnet eine häufige und wichtige Kombination aus:

Meta-Transformation
+ äußerer Context
+ innerer Context
+ explizite Governance-/Lifetime-Beziehung
+ normale Context-Grenzen

Solange alle dafür nötigen Invarianten über vorhandene Context-Semantik ausdrückbar und prüfbar sind, braucht Jade keine vierte fundamentale Runtime-Beziehung.

Ein eigener Grundmechanismus wäre erst gerechtfertigt, wenn eine echte, nicht anders ausdrückbare Maschineninvariante auftaucht.

E.13 Die Runtime bleibt herkunftsblind

Nach erfolgreicher Materialisierung darf die Runtime nicht unterscheiden müssen, ob ein Context aus:

handgeschriebener Source
Meta-Ableitung
Envelope-Meta
Stdlib-Generator
Compiler-internem Seed

entstanden ist.

Sie konsumiert materialisierte Semantik:

ContextDescriptor
EngineRuntimeConfig
BridgeDescriptor
StorageDescriptor
...

Die Herkunft gehört in Provenance.

Das ist wichtig für die Architekturgrenze:

Compiler erklärt, wie die Semantik entstand.
Runtime führt die materialisierte Semantik aus.

Würde die Runtime einen Sonderfall if generated_by_envelope benötigen, wäre das ein starkes Zeichen dafür, dass der Envelope doch neue Runtime-Semantik eingeführt hat.

E.14 CompilerDB, Caching und Provenance

Meta-abgeleitete Contexts passen unmittelbar zum Query-Modell der CompilerDB.

Konzeptionell:

ApplicationContext
    ↓ query / meta transform
Benchmark(ApplicationContext)
    ↓ query / meta transform
Sandbox(Benchmark(ApplicationContext))

Die CompilerDB kann dabei wie gewohnt:

Abhängigkeiten aufzeichnen
Ergebnisse cachen
bei unveränderten Inputs Early Cutoff anwenden
bei geänderten Inputs nur abhängige Ableitungen invalidieren
Provenance getrennt vom semanticPayload führen

Ändert sich nur die Benchmark-Policy, muss der ursprüngliche ApplicationContext nicht semantisch neu entstehen. Geändert werden nur die davon abhängigen Meta-Ableitungen.

E.14.1 Herkunft ist keine semantische Identität

Wenn zwei Wege denselben kanonischen Context-Inhalt ergeben:

handgeschriebenes C
Meta-abgeleitetes C

und ihr semanticPayload identisch ist, sollte auch ihre semantische Identität identisch sein.

Unterschiedlich bleibt die Provenance:

Provenance A: SourceSpan → ContextEngine
Provenance B: Query → Meta-Funktion → CompilerDB-Fassade → ContextEngine

Das hält die bestehende Trennung sauber:

Semantik   bestimmt Identität und Ausführung
Provenance erklärt Entstehung

E.15 Zusammenspiel mit Entrypoints und InitialInvocation

Anhang D ist für v0.1 ebenfalls nur Zukunftsnotiz. Beide Erweiterungen passen jedoch natürlich zusammen.

Ein Entrypoint müsste langfristig nicht zwingend einen handgeschriebenen Root-Context adressieren:

app@stable
    → ApplicationContext

app@benchmark
    → benchmarked(ApplicationContext)

app@sandbox
    → sandboxed(ApplicationContext)

app@benchmark-sandboxed
    → sandboxed(benchmarked(ApplicationContext))

Eine InitialInvocation wählt dann einen materialisierten Startvertrag; wie dieser Context-Vertrag entstanden ist, interessiert den Launcher nicht.

Damit lassen sich Varianten bilden, ohne für jede Kombination einen neuen, handgeschriebenen Blueprint zu duplizieren.

E.15.1 Praktische Folge

Ein Artefakt könnte später semantisch mehrere Aktivierungsziele tragen:

ApplicationArtifact
├── app@stable
├── app@beta
├── benchmark@1
├── monitoring@2
└── worker@1

Ein Teil dieser Ziele kann auf direkt deklarierte Contexts zeigen, ein anderer auf Meta-abgeleitete Contexts oder Envelope-Kompositionen.

Die Invocation wählt einen Startvertrag. Die Meta-Ableitung wurde vorher geprüft und materialisiert.

E.16 Typische v0.2-Anwendungsfälle

E.16.1 Benchmarking

BenchmarkEnvelope
└── ApplicationContext

Der äußere Context kann besitzen:

HighResolutionClock
PerformanceCounters
CpuAffinity
BenchmarkCollector
spezielle Scheduler-Policy
ScratchStorage

Die Anwendung muss diese Autorität nicht sehen. So kann ein Entwickler Nutzer gezielt Benchmarks unter realer Hardware ausführen lassen, ohne Benchmark-Instrumentierung in die normale Anwendungsdomäne einzubauen.

E.16.2 Sandboxing

SandboxEnvelope
└── PluginContext

Die Meta-Transformation kann Resource-Bindings entfernen oder attenuieren, Limits verschärfen, Storage umlenken und Bridges filtern. Die ContextEngine beweist danach die resultierende Grenze.

E.16.3 Tracing und Profiling

TracingEnvelope
└── WorkerContext

Die äußere Domäne kann Probes, Timing-Services oder Export-Bridges besitzen, ohne den Worker selbst mit diesen Services aufzublähen.

E.16.4 Testen

TestEnvelope
└── ApplicationContext

Mögliche Substitutionen:

Clock → DeterministicClock
Db → FixtureDb
Network → MockNetwork
Scheduler → DeterministicPolicy

E.16.5 Beta- und Experimentalvarianten

Stable(Application)
Beta(Application)
Experimental(Application)
Benchmark(Beta(Application))

Solche Varianten können andere Bindings, Engines oder Ressourcenpolicies verwenden. Das ist stärker als ein gewöhnliches Feature-Flag, weil die Variante als eigener geprüfter Ausführungsvertrag sichtbar wird.

Nicht jede Produktvariation rechtfertigt einen Context. Ein anderer Buttontext bleibt ein Buttontext; §20 gilt unverändert.

E.17 Was sich für Context-Modell v0.2 gegenüber v0.1 ändern müsste

Wird dieses Addendum später normativ, muss die v0.1-Grundarchitektur nicht ersetzt werden. Einige Formulierungen müssen jedoch präziser werden.

E.17.1 §0.3 — der Weg dorthin wird allgemeiner

v0.1:

Context-Blueprint
    ↓ ContextEngine
ContextDescriptor

v0.2:

ContextSubject
├── source-declared Blueprint
└── meta-derived Blueprint
        ↓
ContextEngine
        ↓
ContextDescriptor

Meta-Ableitung selbst läuft dabei über die CompilerDB-Fassade.

E.17.2 §2 — „Context ist ein Blueprint“ bleibt, „wird deklariert“ wird präziser

Die Aussage

Ein Context ist ein Blueprint.

kann erhalten bleiben.

Zu präzisieren wäre:

Ein Context wird als Blueprint deklariert.

zu:

Ein Context liegt der ContextEngine als Blueprint-Subject vor. Dieses Subject kann explizit deklariert oder über die CompilerDB-Fassade durch zulässige Meta-Ableitung erzeugt worden sein.

E.17.3 §3 — Profile bleiben Profile

Context-Transformer sind keine neuen Profile.

WebContext                 Profil / Blueprint
sandboxed(WebContext)      Meta-abgeleitete Context-Semantik

Ein Profil ist ein benannter Ausgangspunkt; eine Meta-Transformation ist eine Ableitung über konkrete Semantik.

E.17.4 §10 — Beziehungen bleiben bestehen

Die drei Beziehungen aus §10 werden nicht ersetzt.

v0.2 ergänzt:

Die Struktur dieser Beziehungen darf auch aus einer Meta-Ableitung über die CompilerDB-Fassade hervorgehen.

Ein Envelope bleibt zunächst ein Muster über diesen Beziehungen.

E.17.5 §12 — Monotonie wird vollständig herkunftsunabhängig

v0.2 sollte ausdrücklich sagen:

Die Monotonieprüfung gilt für das materialisierte Verhältnis unabhängig davon, ob seine Beschreibung aus Source, Meta-Ableitung oder Envelope-Meta stammt.

E.17.6 Anhang A, Invariante 2

v0.1:

Ein Context wird als Blueprint deklariert und von einer DescriptorEngine materialisiert.

v0.2:

Ein Context besitzt ein Blueprint-Subject und wird von der ContextEngine materialisiert. Das Subject kann explizit deklariert oder über die CompilerDB-Fassade durch zulässige Meta-Ableitung erzeugt sein.

E.17.7 Neue v0.2-Invarianten

Kandidaten für eine spätere normative Fassung:

1. Die CompilerDB-Fassade definiert die konstruktive Autorität von Meta.
2. Was über diese Fassade nicht ausdrückbar ist, kann Meta nicht als Compilersemantik konstruieren.
3. Ausdrückbarkeit ersetzt keine Validierung; ContextEngine und Materializer prüfen auch Meta-abgeleitete Semantik vollständig.
4. Context-Transformation mutiert keinen bereits committeten Descriptor.
5. Source- und Meta-Herkunft sind Provenance und ändern bei gleichem semanticPayload nicht die Runtime-Bedeutung.
6. Context Envelope ist ein Meta-Muster, kein eigener Runtime-TypeKind.
7. Envelope-Meta benutzt ausschließlich die gewöhnliche CompilerDB-Fassade; sie besitzt keine Sonderautorität.
8. Ein Envelope darf die effektive Resource-Autorität des eingeschlossenen Contexts nicht unzulässig erweitern.
9. Zwischen äußerem und innerem Context gelten normale Parent-Expose-, Bridge-, Handle- und ContextApi-Regeln.
10. Ein Envelope wird vor Aktivierung materialisiert; Live-Wrapping gehört nicht zu diesem Modell.

E.18 Was v0.1 heute nicht verbauen darf

Der eigentliche Nutzen dieses Addendums für v0.1 liegt nicht darin, v0.2 vorweg zu implementieren. Er liegt darin, ein paar falsche Festlegungen zu vermeiden.

E.18.1 Die ContextEngine darf nicht dauerhaft an AST-Herkunft gebunden sein

Kurzfristig kann die v0.1-Implementierung natürlich von einem AST-Knoten starten.

Ihre semantische Kernprüfung sollte aber nicht davon abhängen, dass der Input zwingend aus genau diesem Syntaxpfad stammt.

Langfristig soll gelten:

semantisches ContextSubject
        ↓
ContextEngine

nicht:

konkreter AST-Knoten in main.jdl
        ↓
ContextEngine

E.18.2 ContextDescriptor darf Source-Herkunft nicht als Semantik benötigen

Ein ContextDescriptor darf für seine Bedeutung nicht benötigen:

SourceSpan
AST-Knoten-ID
Dateiname
Parser-Objekt
Meta-Aufrufrahmen

Solche Informationen gehören in Provenance.

E.18.3 Die CompilerDB-Fassade muss der einzige Meta-Konstruktionsweg bleiben

v0.1 sollte keinen parallelen Meta-Schreibpfad etablieren, etwa:

Meta → interner DescriptorStore
Meta → ContextEngine-Interna
Meta → Ring-0-Strukturen

Nicht weil dafür jeweils ein zusätzliches Verbot gepflegt werden soll, sondern weil die Fassade selbst die positive Autoritätsgrenze ist.

Die richtige Reserve lautet:

Meta
  ↓
CompilerDB-Fassade
  ↓
zuständige Engines / Materializer
  ↓
kanonische Compilersemantik

Wenn v0.2 Context-Ableitungen braucht, wird die Fassade um die nötigen semantischen Operationen erweitert. Die Meta-Phase bekommt keinen zweiten Kanal.

E.18.4 Context-Discovery nicht dauerhaft mit Source-Discovery gleichsetzen

Tooling darf in v0.1 bequem „deklarierte Contexts“ über Source finden.

Die langfristige semantische Query sollte aber eher lauten:

welche materialisierten Subjects erfüllen die Context-Rolle?

und nicht:

finde alle Syntaxknoten type X : blueprint in main.jdl

Sonst würden LSP, Mission Control und Compiler später Meta-abgeleitete Contexts übersehen.

E.18.5 Keine geschlossene Enumeration von Context-Arten

v0.1 sollte nicht fest verdrahten:

ContextKind = Web | Cli | Worker | Test | Plugin | ...

Profile sind Ausgangspunkte, keine Ontologie. Meta-Ableitungen verstärken diese Entscheidung.

E.18.6 Monotonie nicht nur an Quelltext-Vererbung implementieren

Wenn Resource-Autoritätsprüfung nur deshalb funktioniert, weil zwei konkrete Syntaxbäume nebeneinanderliegen, wird Meta-Ableitung später unnötig teuer.

Die Prüfung sollte gegen normalisierte beziehungsweise materialisierte Werte formulierbar bleiben:

parent/effective policy
child/effective policy

E.18.7 Policy-Vergleiche erweiterbar halten

v0.1 muss keine allgemeine isNoMorePermissiveThan-Abstraktion besitzen.

Es sollte aber vermeiden, alle Monotonieentscheidungen als verstreute Sonderfälle tief in der ContextEngine zu vergraben.

Wo eine Policy-Domäne ihre eigene Ordnungslogik besitzt, sollte diese später dort wohnen können.

E.18.8 ContextDescriptor kanonisch und lauf-unabhängig halten

Meta-Ableitungen funktionieren nur sauber, wenn ContextDescriptoren weiterhin:

unveränderlich
kanonisch serialisierbar
internbar
frei von lauf-lokalen Runtime-Identitäten

bleiben.

E.18.9 Loader und Runtime konsumieren Descriptoren, keine Herkunft

v0.1 sollte beim Aktivieren eines Contexts materialisierte Semantik benötigen, nicht deren Source-Herkunft.

Nicht:

Loader öffnet main.jdl erneut
Loader rekonstruiert Context aus Source

sondern:

Loader liest projizierte Context-Semantik
Runtime materialisiert Ausführung daraus

E.18.10 Provenance muss Ableitungen unterscheiden können

Wenn später gilt:

ApplicationContext
    ↓ benchmarked
    ↓ sandboxed
ResultContext

muss :why diesen Weg erklären können.

Provenance darf deshalb nicht auf „SourceSpan des deklarierenden Blueprints“ reduziert werden.

E.18.11 Entrypoints dürfen semantische Context-Ziele adressieren

Falls Anhang D später umgesetzt wird, sollte ein Entrypoint nicht dauerhaft eine Quelltextposition adressieren müssen.

Besser:

EntryPointDescriptor
    → stabil referenzierbare Context-Semantik

Dann kann dieselbe Aktivierungsarchitektur auch Meta-abgeleitete Root-Verträge adressieren.

E.18.12 Kein Runtime-TypeKind Envelope vorsorglich einführen

v0.1 sollte keinen EnvelopeContext, WrappedContext oder ähnlichen Runtime-Sondertyp vorsehen.

Das Addendum geht gerade davon aus, dass Envelope-Meta vorhandene Context-Semantik konstruiert.

Ein Runtime-Sondertyp wäre erst gerechtfertigt, wenn eine konkrete, nicht anders ausdrückbare Maschineninvariante auftaucht.

E.18.13 Keine mutierbaren ContextDescriptoren

Zukünftige Transformationen sollten nicht so vorbereitet werden:

ContextDescriptor desc;
desc.resources.remove(...);
desc.services.replace(...);

Sondern:

alter Descriptor bleibt unverändert
Meta-Ableitung konstruiert neuen semantischen Zustand

Nur so bleiben Caching, contentHash, Provenance und bestehende Referenzen korrekt.

E.19 Was v0.1 ausdrücklich noch nicht implementieren muss

„Nicht verbauen“ heißt nicht, vorsorglich v0.2 zu bauen.

v0.1 braucht für dieses Addendum nicht:

keine öffentliche Context-Transformer-Syntax
kein `ContextSubject`-Keyword
keinen eigenen `ContextSpec`- oder `ContextForm`-Typ
keinen `Envelope`-TypeKind
keinen Runtime-Wrap-Mechanismus
keine generische Policy-Algebra
keine fertige Benchmark-/Sandbox-Stdlib
keine Multi-Entrypoints
keine allgemeine Envelope-Meta-Bibliothek

Für v0.1 reicht die strukturelle Reserve:

Meta bleibt auf die CompilerDB-Fassade beschränkt
ContextEngine kann auf semantischem Input arbeiten
Materializer bleibt Commit-Grenze
ContextDescriptor bleibt kanonisch und herkunftsneutral
Runtime konsumiert Descriptor-Semantik
Monotonie bleibt semantisch formulierbar
Provenance bleibt allgemeiner als ein SourceSpan

Das ist wenig zusätzliche Implementierung und verhindert mehrere später teure Sackgassen.

E.20 Verständliches Glossar

CompilerDB-Fassade — Die semantische Oberfläche, über die Meta-Code Compilerwissen liest und neue Compilersemantik ausdrücken kann. Sie ist die positive Autoritätsgrenze der Meta-Phase: Was sie nicht ausdrückt, kann Meta nicht konstruieren.

ContextSubject — Arbeitsbegriff für ein Blueprint-Subjekt, das von der ContextEngine als Context verstanden und materialisiert werden kann. Kein neuer TypeKind und kein notwendiges Schlüsselwort.

Meta-abgeleiteter Context — Ein Context, dessen semantisches Subject vollständig oder teilweise durch Meta-Code über die CompilerDB-Fassade erzeugt wurde, bevor die normale ContextEngine- und Materializer-Prüfung läuft.

Context-Transformation — Eine Meta-Ableitung, die aus einem oder mehreren ContextSubjects neue Context-Semantik konstruiert. Sie mutiert keinen bestehenden Descriptor.

Envelope Meta — Eine Context-Transformation, die über die CompilerDB-Fassade eine äußere Context-Domäne und deren kontrollierte Beziehung zu einer inneren Context-Domäne konstruiert. Sie besitzt keine Sonderrechte gegenüber anderer Meta-Semantik.

Context Envelope — Das semantische Muster beziehungsweise Ergebnis einer Envelope-Meta: eine äußere Context-Domäne materialisiert oder begrenzt eine innere unter expliziten Governance-, Ressourcen-, Instrumentierungs- oder Isolationsregeln. Kein eigener Runtime-TypeKind.

äußerer Context — Der Context, der in einem Envelope die Governance-Domäne bildet. Die Bezeichnung ist eine Rolle in dieser konkreten Ableitung, keine Context-Art.

innerer Context / Subject — Der eingeschlossene Context. Er erhält durch die Envelope-Relation nicht automatisch Zugriff auf Resources, Services oder Bridges des äußeren Contexts.

autoritätstragende Resource — Eine Resource, deren Handle konkrete Runtime-Autorität verkörpert, etwa ein Directory-Handle, ein BridgeEndpoint oder eine CompilerInstance. Nicht jede Resource fällt in diese Kategorie.

Capability — Bezeichnung für konkrete Runtime-Autorität einer autoritätstragenden Resource beziehungsweise ihres Handles; keine globale Context-Berechtigungsachse.

effektive Resource-Autorität — Die Maschinenautorität, die aus den in einer Context-Domäne tatsächlich erreichbaren autoritätstragenden Resources und ihren attenuierten Ableitungen folgt.

Monotonie — Die Regel, dass eine untergeordnete oder eingeschränkte Domäne keine stärkere Resource-Autorität hinzugewinnt. Für Envelopes heißt das insbesondere: äußere Resources werden nicht automatisch nach innen übertragen, und abgeleitete autoritätstragende Resources dürfen ihre Quelle nur attenuieren.

Policy-Ordnung — Die domänenspezifische Aussage, ob eine Policy gegenüber einer anderen gleich oder restriktiver ist.

Herkunftsblindheit der Runtime — Die Eigenschaft, dass Loader und Runtime gültige materialisierte Context-Semantik gleich behandeln, unabhängig davon, ob sie aus Source oder Meta-Ableitung stammt.

Provenance — Die Erklärung, wie Semantik zustande kam. Bei Meta-abgeleiteten Contexts enthält sie insbesondere Queries, Meta-Transformationen und Ableitungsschritte; sie ist nicht Teil des semantischen contentHash.

Live-Wrapping — Nachträgliches Einhüllen einer bereits laufenden Context-Instanz. Dieses Addendum schließt es für die vorgeschlagene v0.2 aus; es wäre ein eigenes Lifecycle-/Migrationsproblem.

E.21 Vorläufige Architekturregeln für v0.2

Wenn dieses Addendum später normativ wird, lässt sich sein Kern auf wenige Regeln verdichten:

E-1. Ein Context bleibt semantisch ein Blueprint-Subject. Das Subject darf explizit deklariert oder durch zulässige Meta-Ableitung erzeugt werden.

E-2. Die CompilerDB-Fassade definiert die konstruktive Autorität von Meta. Was über diese Fassade nicht ausdrückbar ist, kann Meta nicht als Compilersemantik konstruieren.

E-3. Ausdrückbarkeit bedeutet nicht Gültigkeit. Meta-abgeleitete Context-Semantik durchläuft dieselben ContextEngine-, Materializer-, Constitution- und Kohärenzprüfungen wie handgeschriebene Semantik.

E-4. Eine Context-Transformation erzeugt neue semantische Ableitung und mutiert keinen bereits committeten Descriptor.

E-5. Source- und Meta-Herkunft sind Provenance. Gleicher semanticPayload besitzt dieselbe Runtime-Bedeutung.

E-6. Context Envelope ist ein durch Envelope-Meta konstruiertes Muster über vorhandener Context-Semantik und kein eigener Runtime-TypeKind.

E-7. Envelope-Meta benutzt ausschließlich die gewöhnliche CompilerDB-Fassade und besitzt keine zusätzliche Autorität.

E-8. Ein Envelope darf eigene autoritätstragende Resources besitzen, ohne sie dem inneren Context zu verleihen. Die effektive Resource-Autorität des inneren Contexts darf durch die Einhüllung nicht unzulässig erweitert werden.

E-9. Zwischen äußerem und innerem Context gelten ausschließlich die normalen Parent-Expose-, Bridge-, Handle- und ContextApi-Regeln.

E-10. Ein Envelope wird vor Aktivierung materialisiert. Live-Wrapping oder Mutation einer laufenden Context-Instanz gehört nicht zu diesem Modell.

E-11. Policy-Monotonie wird gegen semantische Werte geprüft; die jeweilige Policy-Domäne definiert ihre Ordnungsrelation.

E-12. Loader und Runtime konsumieren materialisierte Context-Semantik und benötigen keinen Sonderpfad für Meta-abgeleitete Contexts oder Envelopes.

E.22 Minimale v0.1-Reserve

Falls von diesem gesamten Addendum für v0.1 nur sechs Dinge hängenbleiben, sollten es diese sein:

1. Meta-Autorität ausschließlich über die CompilerDB-Fassade definieren.
2. ContextEngine nicht dauerhaft an einen konkreten AST-Knoten koppeln.
3. ContextDescriptor herkunftsneutral und unveränderlich halten.
4. Materializer als kanonische Commit-Grenze beibehalten.
5. Monotonie gegen Semantik prüfen können, nicht nur gegen Quelltextform.
6. Runtime und Loader nur auf materialisierte Context-Semantik festlegen.

Mehr muss v0.1 für diese Erweiterung nicht können.

Damit bleibt der Weg offen von:

handgeschriebener Context

zu:

handgeschriebener oder Meta-abgeleiteter Context

und weiter zu:

Envelope-Meta(Context)

ohne später einen zweiten Context-, Loader- oder Runtime-Mechanismus danebenstellen zu müssen.