workover of the mojo plan

MOJO.md

@@ -21,6 +21,9 @@ Der Umbau darf deshalb nur stufenweise erfolgen. Der bestehende native Metal-Pfa
 5. Korrektheit wird vor Performance geprüft. Ein schnellerer Pfad mit abweichender DS4-Semantik ist nicht akzeptabel.
 6. Das Performanceziel lautet auf jeder Hardware separat: Mojo ist bei der End-to-End-Inferenz mindestens so schnell wie der dortige native Referenzpfad. Mac und DGX Spark werden nicht gegeneinander bewertet.
 7. Jeder tatsächlich verwendete Inferenzbaustein erhält einen isolierten Korrektheits- und Performancevergleich. Zusätzlich folgt ein vollständiger Modellvergleich beider Pfade.
+8. DS4Server bleibt so weit wie technisch möglich unter offenen, permissiven Lizenzen. Eigener Code bleibt MIT; bevorzugte Fremdkomponenten sind Apache-2.0-/LLVM-, MIT- oder BSD-lizenziert.
+9. Eine nur source-available oder anderweitig einschränkende Laufzeit darf weder verpflichtende Produktabhängigkeit noch Bestandteil eines Release-Artefakts werden, solange ihre konkrete Notwendigkeit, Redistributierbarkeit und eine offene Alternative nicht dokumentiert und vom Benutzer ausdrücklich freigegeben sind.
+10. Lizenzgrenzen werden am tatsächlich gelinkten und gebündelten Artefakt geprüft, nicht aus Paketnamen oder einzelnen Quellheadern abgeleitet.
 
 ## Heutiger Ausgangspunkt
 
@@ -50,7 +53,7 @@ Damit ist „eine Quelle“ realistisch, „ein universelles Binärartefakt“ a
 
 | Benötigter Bereich | Verfügbarer Stand | Entscheidung für DS4Server |
 | --- | --- | --- |
-| GPU-Kontext, Layouts, Speicher und Profiling | Die [MAX accelerator library](https://docs.modular.com/stable/api/mojo/) enthält GPU-, Layout-, Linalg-, NN-, Quantisierungs-, KV-Cache- und Benchmark-Pakete. | Verwenden, sofern die gepinnte Version auf beiden Zielsystemen reproduzierbar baut. Keine eigene allgemeine GPU-Laufzeit bauen. |
+| GPU-Kontext, Layouts, Speicher und Profiling | Die [MAX accelerator library](https://docs.modular.com/stable/api/mojo/) enthält GPU-, Layout-, Linalg-, NN-, Quantisierungs-, KV-Cache- und Benchmark-Pakete. | Apache-lizenzierte Quellen bevorzugt verwenden. `DeviceContext` und jede native Runtime erst nach dem Artefakt- und Lizenzaudit übernehmen; andernfalls den vorhandenen projektnativen Host-/GPU-Pfad als Laufzeitgrenze behalten. Keine allgemeine Ersatzlaufzeit auf Vorrat bauen. |
 | Matrixeinheiten | MAX bietet eine einheitliche [MMA-Schnittstelle](https://docs.modular.com/stable/api/mojo/max/gpu/compute/) mit [architekturspezifischen Implementierungen](https://docs.modular.com/api/mojo/max/gpu/compute/arch/), einschließlich Apple-MMA und Blackwell/SM100. | Als Basis nutzen. Tile- und Pipeline-Policies je Architektur zur Compile-Zeit wählen. |
 | Attention | Es existieren [Flash-Attention-Kernel](https://docs.modular.com/mojo/kernels/nn/flash_attention/) einschließlich KV-Cache- und Split-KV-Varianten sowie MHA-/MLA-Bausteine im NN-Paket. | Zuerst benchmarken und anpassen. DS4s rohe, komprimierte und indexierte Attention sowie genaue Masken-/Cache-Semantik dürfen nicht als Drop-in-Kompatibilität angenommen werden. |
 | KV-Cache | Das [KV-Cache-Paket](https://docs.modular.com/stable/api/mojo/kv_cache/) enthält paged/sparse Cache- und Index-Remapping-Primitiven. | Layout- und Remapping-Code wiederverwenden, wenn Byte-/Index-Semantik, Kontextzählung und Checkpoint-Restore nachweislich identisch bleiben. Das persistente DS4-Checkpointformat bleibt in Rust. |
@@ -65,6 +68,8 @@ Damit ist „eine Quelle“ realistisch, „ein universelles Binärartefakt“ a
 
 Der Quellcode der relevanten Pakete liegt im [Modular-Repository](https://github.com/modular/modular), unter anderem für [Flash Attention](https://github.com/modular/modular/blob/main/max/kernels/src/nn/flash_attention.mojo) und [Quantisierung](https://github.com/modular/modular/tree/main/max/kernels/src/quantization). Eine vollständige fertige Mojo-Implementierung der von DS4Server verwendeten DeepSeek-V4-Engine wurde in den geprüften Primärquellen nicht gefunden. Für Qwen3.8-27B existiert noch kein geprüfter DS4Server-Drop-in-Pfad, aber die bereits ausgelieferten MAX-Qwen3.5-/GDN-Komponenten passen zur architektonischen Grundlage von Qwen3.8 und reduzieren das Risiko deutlich. Auch außerhalb der offiziellen Modular-Quellen ergab die Recherche keinen überzeugenden, gepflegten Komplettbaustein, der ohne die hier geforderten Paritätstests übernommen werden sollte.
 
+DS4Server interessiert sich aus MAX nur für die Accelerator-Bausteine `layout`, `linalg`, `nn`, `quantization`, `kv_cache`, `state_space`, die benötigten `max.gpu.compute`-Primitiven und Entwicklungswerkzeuge für Benchmarking/Profiling. MAX Serve, Python-Modellpipelines, Modellregistry, REST-Server und allgemeine Graph-/Serving-Orchestrierung sind keine Zielabhängigkeiten.
+
 Vor Übernahme muss geprüft werden:
 
 - welche Teile Quellcode, Bibliothek oder Laufzeitabhängigkeit werden sollen;
@@ -72,6 +77,40 @@ Vor Übernahme muss geprüft werden:
 - welche konkrete Mojo/MAX-Version auf macOS und DGX Spark identisch reproduzierbar ist;
 - ob die benötigten APIs stabil genug sind oder in einer kleinen projektnahen Kompatibilitätsschicht gekapselt werden müssen.
 
+### Lizenz- und Offenheitsstrategie
+
+Die aktuelle Lizenzlage ist komponentenbezogen:
+
+- Mojo 1.0 einschließlich Sprache, Compiler, Standardbibliothek und Werkzeugen ist laut [aktuellem Modular-Lizenztext](https://www.modular.com/legal/mojo) unter Apache 2.0 mit LLVM Exceptions veröffentlicht. Die LLVM-Ausnahme erlaubt, beim Kompilieren eingebettete Teile in Objektcode weiterzugeben, ohne dadurch das eigene Programm unter Apache stellen zu müssen.
+- Das Modular-Repository und die geprüften MAX-Kernelquellen unter `max/kernels` tragen gemäß [Repository-Lizenz](https://github.com/modular/modular/blob/main/LICENSE) Apache-2.0-/LLVM-Header. Das gilt ebenso für geprüfte Mojo-Wrapper wie [`max.gpu.host.DeviceContext`](https://github.com/modular/modular/blob/main/max/mojo/max/gpu/host/device_context.mojo).
+- MAX als ausgeliefertes Paket ist trotzdem keine einheitlich Apache-lizenzierte Einheit. Teile der nativen Runtime, des Graph Compilers und weiterer Device-/Runtime-Komponenten fallen unter die [Modular MAX Community License](https://www.modular.com/legal/community/). Separat gekennzeichnete Apache-Komponenten behalten gemäß Abschnitt 1.4 dieser Lizenz ihre offene Lizenz.
+- Der Apache-lizenzierte `DeviceContext` ist laut Quelle C++-gestützt und ruft externe `AsyncRT_DeviceContext_*`-Symbole auf. Deshalb beweist ein Apache-Header im importierten Mojo-Modul nicht, dass das resultierende Binärartefakt ausschließlich offene Komponenten benötigt.
+- Jede transitive Drittbibliothek aus dem Python-/uv-Paket besitzt ihre eigene Lizenz und wird separat erfasst.
+
+Für DS4Server gelten daraus folgende Regeln:
+
+1. Eigener Rust-, Mojo-, Metal- und CUDA-Code bleibt MIT.
+2. Apache-lizenzierte MAX-Kernel werden importiert oder aus einem exakt gepinnten Modular-Commit gebaut. Vendoring erfolgt nur, wenn eine Änderung zwingend ist; dann bleiben Header, Lizenz und Änderungsvermerk erhalten.
+3. MCL-bedeckter Quellcode wird nicht in das DS4Server-Repository kopiert, übersetzt oder als Grundlage für eine Ersatzimplementierung verwendet.
+4. Eine lokale Entwicklungsinstallation von `max` darf für den Spike verwendet werden. Daraus folgt keine Freigabe, ihre Runtime-Dateien in eine DS4Server-App zu übernehmen.
+5. Ein Release darf nur Bibliotheken enthalten, deren Lizenz, Redistributierbarkeit, Notices und Herkunft für genau die gepinnte Version belegt sind.
+6. Falls der Standard-MAX-Ausführungspfad eine MCL-Runtime benötigt, ist die bevorzugte Lösung, Apache-lizenzierten Mojo-/MAX-Device-Code über den vorhandenen projektnativen Metal-Pfad beziehungsweise einen projektnativen CUDA-Hostpfad auszuführen. Eine MCL-Runtime wird nur erwogen, wenn diese offene Variante technisch oder leistungsmäßig nachweislich nicht trägt und der Benutzer die Abhängigkeit ausdrücklich freigibt.
+7. DS4Server bleibt als eigener Code MIT-lizenziert. Fremdkomponenten werden in einem Release als separat lizenzierte Bestandteile ausgewiesen; ihre Bedingungen werden nicht als DS4Server-Lizenz ausgegeben.
+
+Für jede potenzielle Laufzeit- oder Kernelabhängigkeit entsteht vor Übernahme ein Eintrag im Lizenzinventar mit:
+
+- Paket, Version, Quellcommit und exaktem Quellpfad;
+- Lizenzkennung und unverändertem Lizenztext;
+- Verwendung als Build-Werkzeug, Quellimport, statisch eingebetteter Code oder dynamische Laufzeit;
+- den tatsächlich verteilten Dateien;
+- benötigten NOTICE-/Attributionspflichten;
+- einer offenen Ersatzoption und den Kosten ihres Einsatzes;
+- Ergebnis `build-only`, `redistributable`, `nicht redistributable` oder `ungeklärt`.
+
+`ungeklärt` und `nicht redistributable` sind harte Release-Blocker. Für Community-Lizenz-Komponenten genügt nicht die allgemeine Erlaubnis, Anwendungen auszuliefern: Es muss belegt sein, dass genau die betreffende Datei ein erlaubter „Redistributable Component“ ist. Die zum Pin gehörende Lizenzfassung wird zusammen mit dem Inventar archiviert, weil nach Abschnitt 9 der Community License die beim Bezug einer konkreten Version geltenden Bedingungen maßgeblich bleiben.
+
+Das Artefaktaudit läuft nach jedem Toolchain-Upgrade erneut. Auf macOS werden mindestens `otool -L` und `nm -u`, auf Linux `readelf -d`, `ldd` und `nm -u` auf die Mojo-Bibliothek und die fertige Anwendung angewendet. Alle nicht-systemischen Bibliotheken und alle `AsyncRT`, `MAX`, `KGEN` oder `Modular` zuordenbaren undefinierten Symbole werden bis zur bereitstellenden Datei und deren Lizenz zurückverfolgt. Ein erfolgreicher Quellbuild allein ist kein Lizenznachweis.
+
 ## Zielarchitektur
 
 ```text
@@ -124,6 +163,59 @@ Die ABI muss klein und explizit bleiben. Als minimale Form werden nur diese Klas
 
 Der konkrete Exportmechanismus (`@export`, Shared Library oder der von der gepinnten Mojo-Version vorgesehene stabile Weg) wird in einem frühen Spike bewiesen. Ein Prozessaufruf pro Token ist ausgeschlossen. Die ABI ist nur eine Sprachgrenze; sie macht das Zielprodukt nicht zu einer C-Anwendung.
 
+## Build- und Packaging-Architektur
+
+Cargo bleibt der maßgebliche Build-Einstiegspunkt. Mojo erhält keinen parallelen, manuell zu synchronisierenden Produktbuild.
+
+### Gepinnte Toolchain
+
+Im Repository liegen:
+
+- `pyproject.toml` mit den direkt benötigten, exakt gepinnten Mojo-/MAX-Buildabhängigkeiten;
+- `uv.lock` als plattformübergreifender Auflösungsstand;
+- der Mojo-Quellbaum unter `mojo/`;
+- `.venv/` ausschließlich lokal und ignoriert.
+
+Für den ersten lokalen Spike werden nur `mojo` und das kleinste Paket installiert, das die benötigten MAX-Accelerator-Imports bereitstellt. `max[all]`, `max[serve]` und das Python-/CLI-Extra `max[benchmark]` werden nicht verwendet; benötigte Apache-lizenzierte Mojo-Benchmarkbausteine bleiben davon unberührt. `uv sync --frozen` ist der explizite Bootstrap-Schritt auf einer frischen Maschine; der eigentliche Cargo-Build läuft danach ohne Auflösung oder Netzwerkzugriff.
+
+### Cargo-Integration
+
+Das vorhandene `build.rs` wird wiederverwendet:
+
+1. Es beobachtet `mojo/`, `pyproject.toml` und `uv.lock` über `cargo:rerun-if-changed`.
+2. Es ruft den gepinnten Compiler über `uv run --frozen --offline --no-sync mojo build` auf.
+3. Es erzeugt nativ für das aktuelle Ziel eine Shared Library im Cargo-`OUT_DIR`: auf macOS `libds4_mojo.dylib`, auf Linux `libds4_mojo.so`.
+4. Es meldet Cargo den nativen Link-Suchpfad und `ds4_mojo` als dynamische Bibliothek.
+5. Es setzt nur die für das jeweilige Ziel nötigen RPaths. Absolute Pfade in `.venv`, Benutzerverzeichnisse oder den Build-Checkout dürfen nicht im Release verbleiben.
+6. Der bestehende Objective-C-/Metal-Build bleibt macOS-spezifisch. Der Mojo-Build muss vor dem heutigen frühen Nicht-macOS-Return liegen, damit dieselbe Quelle auf DGX Spark für CUDA gebaut werden kann.
+
+Die Shared Library ist zunächst die bevorzugte Form, weil `mojo build --emit shared-lib` dokumentiert unterstützt ist. Der experimentelle Objektdatei-Pfad wird nicht als Produktbasis gewählt, nur um das Packaging zu umgehen. Cross-Linking zwischen Mac und DGX ist nicht vorgesehen; beide Zielartefakte werden nativ aus demselben Commit und Lockfile gebaut.
+
+### ABI
+
+`mojo/src/api.mojo` exportiert mit `@export` und `abi("C")` ausschließlich feste Integer-/Floattypen, opake Handles sowie Pointer-plus-Länge. Mojo-`String`, `List`, Exceptions oder interne Layouttypen überschreiten die ABI nicht. Jede exportierte Funktion initialisiert die Mojo-Laufzeit selbst idempotent oder die ABI erzwingt eine einmalige, getestete Initialisierung vor allen anderen Aufrufen. Rust kapselt alle `unsafe extern "C"`-Deklarationen in einem kleinen sicheren Modul und übersetzt Fehler explizit.
+
+Die erste ABI enthält nur Lebenszyklus, Tensortransfer, einen residenten Matmul-Aufruf, Ergebnis-/Fehlerabfrage und Zeitmessung. Load, Prefill, Decode, Verify und Cache-Transfer werden erst ergänzt, wenn der Spike Build, Laufzeit und Lizenzgate bestanden hat.
+
+### App-Bundle und Linux-Artefakt
+
+`make bundle` bleibt der macOS-Produktbuild. Nach `cargo build` und `cargo packager`, aber vor `codesign`, kopiert er die Mojo-Bibliothek und ausschließlich freigegebene transitive Runtime-Bibliotheken nach `DS4Server.app/Contents/Frameworks`, normalisiert Install-Namen auf `@rpath` und prüft das fertige Bundle erneut mit `otool -L`. Die App muss auf einem System ohne Projekt-`.venv` und ohne Build-Checkout starten. `codesign` bleibt der letzte mutierende Schritt.
+
+Das Linux-/DGX-Artefakt erhält dieselbe Prüfung mit `readelf` und `ldd`; RPaths dürfen nur auf den relativen, ausgelieferten Bibliotheksort oder Systembibliotheken zeigen. Für beide Plattformen wird aus dem geprüften Abhängigkeitsabschluss die Third-Party-Lizenzbeilage erzeugt beziehungsweise aktualisiert.
+
+Der Produktbuild schlägt fehl, wenn:
+
+- `uv.lock` nicht zum Manifest passt oder die Umgebung nicht synchronisiert ist;
+- Mojo-Warnungen als Fehler gemeldet werden;
+- eine erwartete Bibliothek fehlt;
+- ein absoluter Entwicklungs-RPath verbleibt;
+- eine nicht inventarisierte nicht-systemische Bibliothek auftaucht;
+- eine benötigte Datei lizenzseitig `ungeklärt` oder `nicht redistributable` ist.
+
+### Plattformminimum
+
+DS4Server deklariert derzeit macOS 13, während die aktuelle Mojo/MAX-Toolchain macOS 15 und Apple Silicon voraussetzt. Der Spike darf lokal auf unterstützter Hardware laufen, aber eine Produktintegration muss entweder das Deployment-Ziel nachvollziehbar auf macOS 15 erhöhen oder mit einem reproduzierbaren Artefakttest beweisen, dass der vollständig offene erzeugte Pfad auf macOS 13 unterstützt und lauffähig ist. Eine stillschweigende Anhebung oder ein offiziell nicht unterstütztes Release ist ausgeschlossen.
+
 ### Bedeutung von „eine Mojo-Implementierung“
 
 Erlaubt:
@@ -463,13 +555,15 @@ MTP/speculative decode, Steering und SSD-Streaming werden zunächst deaktiviert,
 Ergebnisse:
 
 - Mojo/MAX-Version, Modular-Quellcommit, Rust-Toolchain und Zielcompiler pinnen;
-- Lizenz-/Redistributionsprüfung dokumentieren;
+- `pyproject.toml` und `uv.lock` für die minimale Build-Toolchain anlegen und einen frischen Offline-Folgebuild beweisen;
+- komponentengenaues Lizenzinventar einschließlich der zum Pin gehörenden Lizenztexte anlegen;
+- Apache-Kernelquellen von MCL-bedeckten Runtime-/Device-Komponenten trennen und für jede benötigte native Datei die Redistributierbarkeit klären;
 - aktuelle Metal-Baseline mit Rohdaten erstellen;
 - auf DGX Spark einen gepinnten nativen CUDA-Referenzlauf herstellen;
 - Modell-, Prompt-, Hardware- und Messmanifeste festlegen;
 - vollständiges Operationsinventar erzeugen.
 
-Gate: Baselines sind wiederholbar; die Lauf-zu-Lauf-Streuung ist klein genug, um einen realen Performanceverlust zu erkennen. Ohne CUDA-Referenz keine CUDA-Paritätsaussage.
+Gate: Baselines sind wiederholbar; die Lauf-zu-Lauf-Streuung ist klein genug, um einen realen Performanceverlust zu erkennen. Ohne CUDA-Referenz keine CUDA-Paritätsaussage. Ohne geschlossenes Lizenzinventar für die Build-Toolchain beginnt kein Release-Packaging.
 
 ### Phase 1: Backendauswahl und gemeinsamer Harness
 
@@ -486,13 +580,17 @@ Gate: Native-Metal-Läufe vor und nach Einführung des Selektors sind statistisc
 
 Nur der kleinste vertikale technische Nachweis:
 
-- Rust lädt eine Mojo-Bibliothek und behandelt Fehler sauber;
+- `build.rs` baut aus dem gepinnten uv-Lockfile eine Mojo-Shared-Library für das aktuelle Ziel;
+- Rust lädt beziehungsweise linkt die Mojo-Bibliothek und behandelt Fehler sauber;
 - Mojo erkennt Metal beziehungsweise CUDA;
-- ein repräsentativer Tensortransfer und ein MMA-/Matmul-Kernel laufen;
+- ein repräsentativer Tensortransfer und bevorzugt ein vorhandener Apache-lizenzierter MAX-MMA-/Matmul-Kernel laufen;
 - Speicher bleibt über mehrere Decode-Schritte resident;
-- GPU- und Wallclock-Messung funktionieren auf beiden Plattformen.
+- GPU- und Wallclock-Messung funktionieren auf beiden Plattformen;
+- `otool`/`nm` beziehungsweise `readelf`/`ldd`/`nm` liefern den vollständigen nativen Abhängigkeitsabschluss;
+- jede gefundene Datei ist im Lizenzinventar klassifiziert;
+- der Spike dokumentiert getrennt, ob nur Apache-/MIT-/BSD-Komponenten benötigt werden oder eine MCL-Runtime technisch in den Pfad gelangt.
 
-Gate: Kein Prozess-pro-Token, keine Synchronisation pro elementarem Operator und kein ungeklärter ABI-/Packaging-Blocker.
+Gate: Kein Prozess-pro-Token, keine Synchronisation pro elementarem Operator und kein ungeklärter ABI-, Packaging- oder Lizenzblocker. Benötigt der Pfad eine MCL-Runtime, wird vor Phase 3 zuerst der offene Host-/Dispatch-Pfad geprüft; die MCL-Abhängigkeit wird nicht stillschweigend zur Produktbasis.
 
 ### Phase 3: Risikofrüher vertikaler Schnitt
 
@@ -599,10 +697,12 @@ Mojo wird zunächst opt-in, dann nach bestandener Matrix Standard. Native Pfade
 
 Die Implementierung soll keine große neue Abstraktionshierarchie erzeugen. Voraussichtlich genügen:
 
+- `pyproject.toml` und `uv.lock` für die exakt gepinnte Build-Toolchain;
+- die Erweiterung des vorhandenen `build.rs` statt eines zweiten Produktbuildsystems;
 - ein kleiner Rust-Backendselektor an der bestehenden Executorgrenze;
 - ein Mojo-Quellbaum mit gemeinsamen Modell-/Operatorfunktionen und kleinen Architektur-Policies;
 - ein gemeinsamer A/B-Harness;
-- ein Operations-/Fixture-Manifest;
+- ein Operations-/Fixture-Manifest und ein komponentengenaues Lizenzinventar;
 - maschinenlesbare Benchmarkresultate und daraus erzeugte Berichte.
 
 Die oben definierte Top-Level-Struktur ist verbindlich; einzelne Dateien dürfen zusammengelegt werden, wenn sie sonst nur Weiterleitungen enthalten. Der genaue ABI-Export wird festgelegt, nachdem der Mechanismus in Phase 2 funktioniert. Es wird keine Factory-, Plugin- oder allgemeine Accelerator-Schicht auf Vorrat gebaut.
@@ -629,11 +729,15 @@ Der vorhandene MAX-GDN-Pfad ist ein wertvoller Startpunkt, seine sequenzielle Re
 
 Mojo/MAX entwickelt sich schnell. Reproduzierbarkeit verlangt einen exakten Pin, lokale Artefakt-Caches und eine bewusste Upgrade-Politik. Ein Upgrade wird wie eine Performanceänderung behandelt und muss die relevante Matrix erneut bestehen.
 
-### 6. Hardwarezugang ist Teil der Definition of Done
+### 6. Gemischte MAX-Lizenzgrenze
+
+Die benötigten MAX-Kernel sind überwiegend Apache-lizenziert, ihr üblicher Hostpfad kann aber externe AsyncRT-/MAX-Runtime-Symbole einführen. Das Risiko wird nicht durch eine pauschale Annahme über das `max`-Paket gelöst, sondern durch den Abhängigkeitsabschluss des erzeugten Artefakts. Wenn eine offene Auslieferung nur mit einer MCL-Runtime möglich wäre, bleibt der native Referenzpfad bestehen und die Architektur wird vor weiterer Portierung neu bewertet.
+
+### 7. Hardwarezugang ist Teil der Definition of Done
 
 CUDA-Performance kann nicht auf dem Mac simuliert und Metal-Performance nicht aus CUDA-Ergebnissen abgeleitet werden. Jede relevante Phase braucht reale Apple- und DGX-Spark-Läufe. Ohne beide Systeme bleibt die Phase unvollständig.
 
-### 7. Keine Vorabgarantie von Token/s
+### 8. Keine Vorabgarantie von Token/s
 
 Quellvereinheitlichung ist technisch plausibel; Performanceparität ist eine empirische Eigenschaft. Der Plan reduziert dieses Risiko durch den schwierigen vertikalen Schnitt in Phase 3. Scheitert er, bleiben die nativen Pfade erhalten und es wurde noch nicht die gesamte Engine portiert.
 
@@ -654,9 +758,14 @@ Der Umbau ist erst abgeschlossen, wenn alle folgenden Aussagen belegt sind:
 - Prefill, erster Token, stabiler Decode, lange Kontexte, Speicher, Checkpoints, Streaming, Steering und MTP sind getrennt verifiziert, soweit sie unterstützt werden.
 - Es gibt keine stillen Fallbacks, keine gemischten Benchmarkpfade und keine ungeklärten Performanceausnahmen.
 - Build, Tests und Benchmarkberichte sind aus gepinnten Toolchains und Manifesten reproduzierbar.
+- Ein frischer Build benötigt nach `uv sync --frozen` keinen Netzwerkzugriff und erzeugt auf jedem Ziel nativ dasselbe fachliche Mojo-Backend.
+- Das fertige macOS-/Linux-Artefakt enthält keine absoluten Entwicklungs-RPaths und läuft ohne Projekt-`.venv`.
+- Jede nicht-systemische Binärabhängigkeit besitzt einen geprüften Lizenzinventareintrag und die erforderliche Lizenz-/NOTICE-Beilage.
+- Der Produktpfad hängt nur von MIT-, Apache-2.0-/LLVM-, BSD- oder vergleichbar permissiv lizenzierten Komponenten ab, sofern der Benutzer keine dokumentierte Ausnahme ausdrücklich freigegeben hat.
+- Keine MCL-bedeckte Quelle wurde in das DS4Server-Repository übernommen oder zur Erzeugung eines MAX-Ersatzes verwendet.
 
 ## Unmittelbar erster Implementierungsschritt
 
-Der nächste Agent soll nicht mit einer breiten Portierung beginnen. Er soll Phase 0 und Phase 1 abschließen und danach in Phase 2 den kleinsten Rust-Mojo-GPU-Spike bauen. Erst wenn auf Mac und DGX Spark dieselbe Mojo-Quelle einen residenten Matmul-Pfad über die schmale ABI ausführt und messbar ist, beginnt der schwierige quantisierte vertikale Schnitt aus Phase 3.
+Der nächste Agent soll nicht mit einer breiten Portierung beginnen. Er soll Phase 0 und Phase 1 abschließen und danach in Phase 2 den kleinsten Rust-Mojo-GPU-Spike bauen. Dazu gehören der gepinnte uv-Build über `build.rs`, eine schmale C-ABI, ein bevorzugt vorhandener Apache-lizenzierter MAX-Matmul, residenter Speicher sowie der vollständige Binär- und Lizenzaudit auf Mac und DGX Spark. Erst wenn dieselbe Mojo-Quelle auf beiden Zielen messbar läuft und der Produktpfad keine ungeklärte oder unfreigegebene MCL-Abhängigkeit besitzt, beginnt der schwierige quantisierte vertikale Schnitt aus Phase 3.
 
 Das ist der früheste Punkt, an dem belastbar entschieden werden kann, ob die angestrebte Quellvereinheitlichung ohne Performanceverlust für diese konkrete Engine erreichbar ist.