Atlas Admin Shell: Admin-Konsole, zur Laufzeit komponiert

Problem und Rahmenbedingungen

Atlas Admin Shell ist die Art Admin-Konsole, die eine große Organisation über mehrere Teams hinweg betreibt: Identitäts- und Zugriffsverwaltung, Feature Flags und ein Audit-Log, jeweils im Besitz eines anderen Domänenteams. Der schwierige Teil sind nicht die Ansichten. Es ist, jede Domäne für sich bauen, testen und deployen zu lassen, während die Nutzenden eine einzige Konsole sehen, ohne einen Release-Zug durch die Shell. Das Repository nennt als Ergebnis die Architektur, nicht die Features, und seine eigenen Dokumente nennen es auch eine Microfrontend-Steuerebene.

Vier Rahmenbedingungen prägten es. Alle Teilnehmer der Federation nutzen eine exakt gepinnte Angular-Version, sodass sich die Shell und die drei Remotes zur Laufzeit ein Framework teilen. Domänengrenzen erzwingt der Build, nicht eine Konvention: Ein Remote kann kein anderes Remote importieren, nur geteilte Bibliotheken überqueren die Grenze. Die Konsole muss ohne Backend und ohne Identitätsanbieter laufen, damit ein frischer Checkout, ein Review und die Testsuite kein Konto brauchen. Und jede wesentliche Entscheidung ist ein ADR mit einem Verification-Abschnitt aus datierten Belegen; wenn ein Beleg nicht mehr stimmt, sagt der ADR das, statt umgeschrieben zu werden.

Es nutzt kein LLM.

Architektur

Atlas läuft als vier Cloudflare-Worker auf vier Origins: einer für die Shell und einer pro Remote (IAM, Feature Flags, Audit Logs). Die Remotes liegen absichtlich auf fremden Origins, damit die Import Map, die CORS-Header und die Fehlergrenze in der Produktion so arbeiten, wie der Entwurf sie beschreibt.

Beim Start lädt die Shell federation.manifest.json, ungecacht, und initialisiert Native Federation daraus: ES-Module und eine Import Map, keine Bundler-eigene Laufzeit. Jeder Eintrag nennt die Einstiegs-URL, die Route, den Anzeigenamen, das Icon, das exponierte Modul und die erforderliche Rolle eines Remotes, und die Shell baut daraus Routen und Navigation. Eine Domäne hinzuzufügen oder umzuleiten ist eine Änderung an dieser Datei und ein Upload, kein Neubau der Shell. Ein canMatch-Guard prüft die Rolle, bevor ein Remote überhaupt geladen wird. Ein Remote, das nicht lädt, schickt die Nutzenden auf eine Fehlerseite, die der Shell gehört, mit einem erneuten Versuch, der in der Seite funktioniert, statt eines gecachten Fallbacks, den der Router nie wieder versuchen würde.

Jede App ist zonenloses Angular 21 auf Signals. Jedes Remote besitzt seine NgRx Signal Stores, und nur zwei Dinge überqueren eine Grenze: AtlasAuth, der Auth-Dienst, den jedes Remote als dieselbe Instanz injiziert, und ein typisierter Event-Bus, dessen Payloads einen Typ und eine Version tragen und durch Vertragstests festgelegt sind. Remotes importieren einander nie, und eine Lint-Regel von Nx erzwingt das.

Im Worker der Shell geht /api/* an ein Edge-BFF, jeder andere Pfad wird als statische Datei ausgeliefert. Das BFF prüft JWTs mit jose gegen das JWKS des Identitätsanbieters und erzwingt, was ein Browser nicht kann: Flag-Änderungen nur für Admins, den Schutz des letzten Admins, keine Selbstherabstufung, idempotente Schreibzugriffe und einen Audit-Trail, den der Server aus dem geprüften Token schreibt. Ob die Remotes es aufrufen, ist eine Umgebungsangabe: apiMode im Manifest ist mock oder http, und sein auth-Block wählt den Identitätsanbieter, Mock-Personas oder Nhost mit GitHub-Anmeldung. Ohne beides läuft die Konsole mit Mock-Daten und Mock-Anmeldung und braucht überhaupt keinen Server. Die Entscheidungen dahinter stehen im Entscheidungsprotokoll weiter unten, jeweils mit der Alternative, gegen die sie sich durchgesetzt haben.

Behauptungen, die nicht hielten

Das Repository hält seine Korrekturen in den ADRs fest, statt sie umzuschreiben, und sie gehören zu seinen nützlichsten Teilen.

Die Angular-Version: ADR-0002 pinnte Angular 21 LTS, weil Nx, NgRx und Storybook Angular 22 nicht innerhalb ihrer erklärten Peer-Bereiche folgen konnten. Spätestens am 22. Oktober 2026 konnten es alle, und der ADR hatte die alte Ursache monatelang weiter behauptet. Die Entscheidung bleibt, ihr Grund hat sich geändert: Angular 22 hat kein LTS-Tag, nichts darin schließt eine Lücke dieser Codebasis, und es ändert die canMatch-Signatur, auf der die Fehlergrenze aufbaut. Die Migration ist nach Kosten und Nutzen zurückgestellt, nicht blockiert.

Der Manifest-Validator sollte strenger sein als die Laufzeitprüfung der Shell. Als apiMode in den Vertrag kam, lernte es nur die Laufzeitprüfung, also passierte ein Manifest mit einem Tippfehler von einem Buchstaben das Gate und startete eine Konsole mit null Remotes. Ein Test prüft jetzt über erzeugte Mutationen, dass der Validator alles ablehnt, was die Laufzeitprüfung ablehnt, und ein zweiter Test scheitert, wenn die Fixture hinter den Feldern zurückbleibt, die die Laufzeitprüfung liest.

Der erste Lighthouse-Lauf maß die föderierte Route fast genau wie die Shell (LCP 1.446 vs. 1.444 ms), was nicht stimmen kann, wenn eine von beiden ein Remote lädt. Die angemeldete Persona war nie im eigenen Browser-Kontext von Lighthouse angekommen, also leitete die Shell auf eine leere Übersicht um, und der Runner maß diese. Jetzt meldet er nichts, solange der Lauf nicht auf der angeforderten URL gelandet ist und tatsächlich die Chunks eines Remotes geladen hat.

Zwei Schutzmechanismen bestanden jede Suite, während sie fehlten. Das BFF akzeptierte ein Token ohne Ablauf-Claim für immer, weil die Tests nie eines erzeugten. Und nichts im Workspace gestaltete den Tastaturfokus, während axe auf jeder Ansicht bestand, weil axe keine Regel hat, die einen Fokusindikator misst. Beides ist behoben, und jede Korrektur wurde geprüft, indem sie wieder entfernt wurde und der neue Test scheiterte.

Ergebnisse

Die Slices 1 und 2 der vier im Fahrplan sind fertig. Slice 3 (BFF und Deployments) ist bis auf PR-Previews fertig; in Slice 4 (Feinschliff) sind Lighthouse, der axe-Durchgang und die schriftliche Architektur fertig, das Demo-Video und die Migration auf Angular 22 offen. Alle vier Worker wurden am 25. Oktober 2026 neu deployt, und das BFF der Live-Shell lehnt eine nicht authentifizierte Anfrage an /api/flags mit einem JSON-401 ab.

Die Live-Konsole zeigt die Komposition und eine echte Anmeldung, nicht die Sicherheit am Edge. Seit dem 25. Oktober 2026 trägt ihr deploytes Manifest den Nhost-Block, und eine GitHub-Anmeldung gelang dort, von Hand; kein automatisierter Test führt sie aus, und eine Token-Erneuerung in der Produktion ist nicht beobachtet. apiMode steht weiter auf mock, also sind die Daten Mock-Daten, und nichts, was Besuchende tun, erreicht das BFF: Am Edge ist noch keine echte Anfrage geprüft. PR-Previews brauchen einen Edge-Router, der jedes Remote unter einem Origin einhängt, und den gibt es noch nicht; das Demo-Video ist nicht aufgenommen.

Die Zahlen oben stammen aus ADR-0012, gemessen am 6. September 2026 als Median aus drei Desktop-Läufen am Produktions-Build. Die Shell allein erreichte 0,96 bei einem LCP von 1.445 ms, die föderierte Route /flags 0,94 bei 1.629 ms. Ein Remote zur Laufzeit einzubinden kostet rund 318 ms FCP und 184 ms LCP: der Preis des manifestgesteuerten Entwurfs, gemessen statt angenommen. Der Testserver lieferte ohne Komprimierung und ohne Caching aus, die Werte sind also eine Untergrenze auf localhost, keine Zahlen aus der Produktion.

Die Prüfungen laufen lokal. Die Minuten für GitHub Actions bei privaten Repositories waren am 22. Oktober 2026 aufgebraucht, also sind die gehosteten Workflows CI und Deploy deaktiviert, und alle vierzehn Gates laufen mit einem Befehl, pnpm run ci:local: ein Wächter gegen zone.js, Prüfungen von Manifest und Design-Tokens, Lint, Typecheck, Unit- und Vertragstests, die Builds, Wrangler-Prüfungen, eine Bundle-Prüfung, axe über Storybook, End-to-End-Tests der Federation gegen Produktions-Builds, das BFF über HTTP und Lighthouse. Die jüngsten Pull Requests des Repositorys halten fest, dass alle vierzehn bestanden; das ist eingefügte Ausgabe vom Rechner des Autors, keine Prüfung, die GitHub ausgeführt hat.

Lehren

Ein Beleg verfällt. Die Begründung aus ADR-0002 stand monatelang im README, nachdem sie nicht mehr stimmte, in einem Repository, dessen erste Regel lautet, dass eine Behauptung einen Beleg braucht. Jede Prüfung zu datieren machte den Verfall auffindbar; es brachte niemanden dazu, nachzusehen. Belege erneut zu prüfen ist eine Aufgabe, nichts, was man bekommt, weil man sie geschrieben hat.

Das Schweigen eines Gates ist keine Abdeckung. Der Algorithmus-Pin, die Ablaufprüfung, die Origin-Prüfung des Interceptors und der Fokusrahmen bestanden alle jede Suite, während sie kaputt waren oder fehlten, weil kein Test den Fehlerfall erzeugen konnte. Die Korrektur war jedes Mal dieselbe: den Schutz absichtlich brechen und zusehen, wie genau die neuen Tests scheitern und keine anderen.

Planen Sie das Budget für die Architektur ein, die Sie gewählt haben. Laufzeit-Federation kostet Anfragen, bevor die erste Domäne erscheint, und ein Lighthouse-Budget, das streng genug ist, um zu beeindrucken, wäre ein Argument gegen den Entwurf gewesen. Die Shell und eine föderierte Route getrennt zu messen, machte diese Kosten zu einer Zahl.

Gehostete CI zu verlieren ist ein Problem der Disziplin, nicht der Rechenleistung. Die Gates lokal auszuführen, behielt jedes einzelne und führt mehr aus, als die gehostete Pipeline ausgeführt hat, aber nichts hält einen Merge auf, den niemand geprüft hat. Der ADR sagt das, statt etwas anderes vorzugeben.