DEV Community: Lutz Leonhardt

Frankenstein Meeting Room: Three Apps in One Browser Tab

Lutz Leonhardt — Tue, 12 May 2026 21:26:07 +0000

🇩🇪 Auf Deutsch lesen: Frankenstein Meeting Room: Drei Apps in einem Browser-Tab

Live demo: lutzleonhardt.de/frankenstein-meeting-room
Code: GitHub

1. Intro — Why Frankenstein?

The 2010s were the great frontend war. Many new UI frameworks emerged in this period and disappeared again. You can see this in today's enterprises' legacy applications. Many have Angular, React, Vue, or Svelte in use for various use cases. If you want to use these applications not as islands but in their entirety, the only option is usually to migrate to a common framework. A long-running and error-prone process. A better option can be to let the apps communicate with each other via a common orchestrator platform. That is the starting point for our Frankenstein Meeting Room based on Native Federation v4.

2. What the app does

The setup is meant to show how a heterogeneous web app landscape (Angular, React, Svelte) can be integrated via Native Federation. The project simulates a legacy enterprise landscape in miniature. Concretely: In an Angular 21 calendar (shell), meetings can be selected. The linked information is displayed in a Svelte 5 Mermaid diagram (Remote 1) as well as a React 18 Excalidraw whiteboard (Remote 2). When switching the meeting, the data is saved and loaded (LocalStorage).

The demo runs at lutzleonhardt.de/frankenstein-meeting-room, the code is on GitHub.

3. Starting point and workflow

In the previous article I already presented the specification of the implementation and the UI mockup (Claude Design).

The original UI mockup from Part 1, generated with Claude Design. The lab notebook look made it into the finished app.

For the implementation I used my Skill Kit for agentic workflows together with the code agents Claude Code and Codex in tandem. The agents translated the specification into individual milestone plans — in the end 18 tasks across 6 milestones. Each milestone plan was broken down into tasks. The advantage of this approach: each milestone produces a verifiable artifact that the developer can validate and review in isolation. The result then serves as the basis for the next step. For each task not only the code is produced, but also a task log: what was tried, what was discarded, which hypotheses died along the way. This negative information is almost always lost in normal commit bodies — while writing this post I had to look things up there most often.

The NF builder doesn't release the process. At your own terminal you don't notice it. You hit Ctrl-C and move on. In the agentic workflow this becomes a problem: the agent doesn't know that the work is done and keeps waiting. The workaround was a small wrapper script: delete the artifact beforehand, start ng build, poll for the artifact, then send SIGKILL to the entire process group.

4. Native Federation: Shell, Remotes, Bus

At the center of Native Federation is the shell (also called host), which loads the other web apps or exported UI components as remotes from remote endpoints. In our case the remotes are standalone web apps (Svelte, React), each of which exports a custom element for the shell.

Since no internal binding can be used for communication between the heterogeneous frameworks, an agnostic messaging pattern must be established. In the case of Frankenstein Meeting Room I decided on a simple, self-implemented pub-sub bus. The topology is star-shaped: the remotes cannot communicate with each other.

The bus implementation lies in the shared area of the monorepo, shell and remotes each import the functionality themselves. The actual bus is attached as a singleton to globalThis (window). The BusEvents were typed as DeepReadonly<T> to prevent accidental mutation across the framework boundary at compile time. A deep clone would be too costly: the entire Excalidraw data structure would have had to be cloned.

// packages/shared/src/bus.ts
type BusEvents = {
  'context:request': {};
  'event:selected': { meetingId: string; initialData: Meeting };
  'drawing:changed': { meetingId: string; excalidrawData: ExcalidrawDemoData };
  'diagram:changed': { meetingId: string; mermaidSource: string };
};
const bus = (globalThis.frankensteinBus ??= new EventTarget()) as EventTarget;
export function emit<K extends keyof BusEvents>(
  name: K, payload: DeepReadonly<BusEvents[K]>,
) {
  bus.dispatchEvent(new CustomEvent(name, { detail: payload }));
}

Star-shaped topology: all bus communication goes through the center, persistence lives with the host. Rendered live in the Svelte Mermaid editor of the demo itself.

5. M1 — Monorepo, shared package, shell skeleton

In the first milestone I set up the pnpm monorepo and implemented the types as well as the bus in the shared package. Via a Native Federation schematic the Angular project is then converted into a Native Federation shell. At the core, the project gets an adapted build, a slightly modified bootstrap process, and a federation configuration. The bootstrap runs in two stages: the shell first loads the federation manifest, injects the import map, and only then starts the actual Angular app. The configuration defines which dependencies are shared between shell and remotes.

That's another advantage of Native Federation: depending on the configuration, libraries are loaded only once, even if multiple remotes and the shell use them.

6. M2 — Host complete: calendar, meeting service, panels

In milestone 2 I completed the shell by adding the calendar (Schedule-X). There is also a meeting service that manages the current meetings based on signals, receives messages via the event bus, and sends data, for example to initialize the remotes with the active meeting. Initially the meetings are populated by a seed. On changes they are saved in LocalStorage and loaded from there again on start. In the shell there are two more Angular components: the detail view for the active meeting as well as an overview of the bus messages. The layout is three-column: calendar on the left, remotes in the middle, detail view and bus log on the right.

A small detail in the meeting service: the remotes debounce their updates (500 ms), and without a guard a meeting switch in the middle of the debounce would lead to the old draft overwriting the new meeting. The fix: every applyDrawingChange/applyDiagramChange in the service checks the meetingId against currentMeeting and drops stale updates. One line of code, without which the bus would have had subtle data corruption.

private applyDrawingChange(p: DrawingChangedPayload): void {
  if (p.meetingId !== this.currentMeeting()?.id) return; // stale-update guard
  // ... persist
}

In the middle area of the shell the React and Svelte applications now still need to be integrated.

7. M3 & M4 — Whiteboard and Mermaid as remotes

In milestones 3 and 4 I implemented the React whiteboard (Excalidraw) and the Svelte Mermaid diagram each as a remote. For both I proceeded the same way: first the standalone app, then placed the federation configuration on top. That way I could develop and test Excalidraw or the Mermaid diagram in isolation before the remote was integrated into the shell. The same UI project (react, svelte) continues to run under its own port as a standalone app and can at the same time be loaded by the host as a remote — for the federation loading, however, the built JavaScript chunks plus remoteEntry.json as static assets are sufficient, a running dev server is not necessary (only for the standalone test).

@frankenstein/shared as devDependency, not as dependency. That way shareAll skips the package, and the globalThis singleton from Section 4 stays intact — the conceptually most important build-mode decision of the project.

Excalidraw spam without real changes. Excalidraw's onChange fires even without real changes. When resizing the window I got ~8 drawing:changed events in 11 seconds without anyone having drawn anything. I had already built in the 500 ms debounce at the sender — but it only groups the events together, it doesn't recognize whether anything has actually changed. The real fix was a fingerprint over ${element.id}:${element.version}: Excalidraw only bumps version on real changes, not on cosmetic reflows. With that the empty events fall out before the debounce, and afterwards it only takes care of the frequency of real edits.

const fp = elements.map(e => `${e.id}:${e.version ?? 0}`).join('|');
if (fp === prevFingerprintRef.current) return; // skip cosmetic re-renders
prevFingerprintRef.current = fp;
// → 500ms debounce → emit('drawing:changed', …)

Firefox canvas limit. Firefox caps <canvas> at ~11180 px edge length. Since Excalidraw's stylesheet was only loaded after the React mount, the container was briefly large; Excalidraw computed a canvas size beyond the limit, and the first setTransform call threw an exception with a stack trace in the console — Excalidraw didn't even boot. Chromium doesn't have the limit: classic "works on my machine" bug. Solved by injecting the stylesheet into the head already at module init and having the first render wait for its load event.

The federation configuration is set up the same way for both remotes: a federation.config.mjs in which it is specified what the remote exports and which libraries are shared. Shared libraries are usually loaded as singletons — exactly one instance for shell and all remotes, even though each project brings them in as a dependency itself. Version conflicts are resolved at build time, transitive sub-dependencies are explicitly shared or excluded. With that the federation configuration ultimately also determines how many JavaScript chunks are produced per application.

React jsx-runtime as CJS. React still ships some modules as CommonJS, which Native Federation converts to ESM during the build. With one specific pattern — react/jsx-runtime — this translation doesn't work cleanly: the jsx function was undefined at runtime and Excalidraw blew up on the first render. Fixable via path mapping in the federation configuration, which skips the problematic intermediate step and points directly to React's pre-compiled CJS file.

Svelte twice in the tab. In the Mermaid remote it was the other way around: Svelte couldn't be shared cleanly at all. Its internal code references itself via relative paths that the federation mechanism can't reach — in the end two Svelte runtimes ended up in the tab in parallel, and Mermaid threw effect_orphan at runtime. Pragmatically solved: Svelte out of the share map and bundled directly into the Mermaid bundle. With only one Svelte app the size doesn't matter — the ~160 kB ends up on the client either way, whether as a shared chunk next to the bundle or as part of it. Only from two Svelte remotes onwards would the duplication start to bite.

8. Islands instead of components

In a homogeneous landscape — that is, when all apps use the same UI framework — you would export components directly and use them in the shell. In a heterogeneous landscape this doesn't work: if I only exported the React component from the React project, the Angular shell could not load it because the React runtime is simply missing in the tab. A pure component has no platform underneath it.

The solution is islands: each remote exports not just the component, but the complete app including its framework. In the tab one UI framework then runs per island, fully encapsulated. Technically this happens via native custom elements: the remote defines a <whiteboard-remote> (or <mermaid-remote>), the shell renders the tag like any other DOM element, and in the connectedCallback the embedded framework boots. That's exactly how whiteboard and Mermaid are implemented in milestones 3 and 4.

class WhiteboardRemote extends HTMLElement {
  connectedCallback() {
    this.root = createRoot(this);
    this.unsubs.push(on('event:selected', ({ initialData }) => {
      this.render(initialData);
    }));
    emit('context:request', {});
  }
  disconnectedCallback() {
    this.unsubs.forEach(u => u());
    this.root?.unmount();
  }
}
customElements.define('whiteboard-remote', WhiteboardRemote);

React DevTools see the full component tree (left). Wappalyzer finds no React (right). The island works.

9. Bus access and events

Shell and remotes each import the bus directly from the shared package (see Section 4). The central, non-trivial part is the init handshake between remote and host: On mount a remote doesn't yet know which meeting is currently active — the host holds the state. So after its initialization the remote sends a context:request over the bus and gets back from the host an event:selected with the current meeting. Only with that does it know which whiteboard or Mermaid data it should load. The two remaining events (drawing:changed, diagram:changed) are pure change notifications from the remotes towards the host.

The event bus log live: context:request on mount of a remote, event:selected as host response, then drawing:changed for an actual whiteboard change.

Deliberately not in the setup: creating or editing meetings via the bus. That would have pulled CRUD wiring through all three frameworks without adding anything to the integration pattern itself. What is possible with Native Federation can be shown clearly with this minimal event set as well.

10. M5 & M6 — Polish and deployment

The last two milestones were about polish and deployment. M5 was fine-tuning: improved the CSS, did cleanups, created a representative seed. The seed has a small punchline: instead of lorem ipsum meetings, the demo meeting is an "Architecture Review" of the demo itself. The whiteboard draws three boxes plus bus, Mermaid shows the sequence diagram of the bus flow. The hero image of the post follows from that on its own.

M6 was the deployment to https://lutzleonhardt.de/frankenstein-meeting-room/ — all static under a subpath, no backend, plus the two remotes separately under /whiteboard/ and /mermaid/ as standalone apps. During development each remote ran via its own standalone dev server, the federation manifest pointed to localhost URLs accordingly. After the build the remotes migrate as static assets into the subpaths of the host, and the manifest is adjusted to match.

11. Take-away

The whole setup stood in 10 to 12 hours of net effort, with the help of the agentic process and consistent curation. Extending it is easy: further React applications can be plugged in just like an additional framework, for example Vue. That makes Native Federation a good fit for bringing a grown heterogeneous legacy landscape together onto one platform without having to pull off a big migration.

What the setup deliberately does not cover: authentication and authorization, cross-origin hardening, multi-user collaboration, contract versioning between host and remotes, e2e tests across island boundaries, mobile layouts. These are not the hard NF topics — but the topics that come in addition to NF in a real enterprise migration. The full delimitation is in the README.

Particular pitfalls exist mainly when multiple versions of the same framework run in parallel — for example Angular 15 and Angular 17 in the same platform. Then you have to pay close attention to shared dependencies, sub-dependencies, and transitive dependencies. The loading of dependencies runs centrally via the native import map, though, which keeps it manageable. In contrast to Webpack Module Federation, where the remote map was buried deep in the code.

Conclusion: the friction between three frameworks in one tab is not where you would expect it. Bus and loading ran without problems. Complications arose with the Firefox CSS, the React CJS wrapper, and a Svelte compiler that ran twice in the same page. The code is at github.com/lutzleonhardt/FrankensteinMeetingRoom.

If you have such a landscape in front of you yourself and don't know whether to migrate or federate — write to me on LinkedIn. The problem points that don't come up in standard talks interest me the most.

Lutz Leonhardt is a member of the Native Federation Advisory Board. More at lutzleonhardt.de.

Frankenstein Meeting Room: Drei Apps in einem Browser-Tab

Lutz Leonhardt — Tue, 12 May 2026 16:38:59 +0000

🇬🇧 Read in English: Frankenstein Meeting Room: Three Apps in One Browser Tab

Live demo: lutzleonhardt.de/frankenstein-meeting-room
Code: GitHub

1. Einstieg - Warum Frankenstein?

Die 2010er Jahre waren der große Frontendkrieg. Viele neue UI-Frameworks entstanden in dieser Zeit und verschwanden wieder. Das sieht man heutigen Enterprises an ihren Legacy-Anwendungen an. Viele haben Angular, React, Vue oder Svelte für verschiedene Use Cases im Einsatz. Wenn man diese Anwendungen nicht als Inseln, sondern in ihrer Gesamtheit nutzen möchte, bleibt normalerweise nur die Möglichkeit, auf ein gemeinsames Framework zu migrieren. Ein langfristiger und fehleranfälliger Prozess. Eine bessere Möglichkeit kann es sein, die Apps über eine gemeinsame Orchestrator-Plattform miteinander kommunizieren zu lassen. Das ist die Ausgangslage für unseren Frankenstein Meeting Room auf Basis von Native Federation v4.

2. Was die App macht

Der Aufbau soll zeigen, wie man eine heterogene Web-App-Landschaft (Angular, React, Svelte) über Native Federation integrieren kann. Das Projekt simuliert im Kleinen eine Legacy-Enterprise-Landschaft. Konkret: In einem Angular-21-Kalender (Shell) können Meetings ausgewählt werden. Die verknüpften Informationen werden in einem Svelte-5-Mermaid-Diagramm (Remote 1) sowie einem React-18-Excalidraw-Whiteboard (Remote 2) dargestellt. Beim Wechsel des Meetings werden die Daten gespeichert und geladen (LocalStorage).

Die Demo läuft unter lutzleonhardt.de/frankenstein-meeting-room, der Code liegt auf GitHub.

3. Ausgangslage und Workflow

Im vorherigen Artikel habe ich bereits die Spezifikation der Umsetzung und das UI-Mockup (Claude Design) vorgestellt.

Das ursprüngliche UI-Mockup aus Teil 1, generiert mit Claude Design. Der Lab-Notebook-Look hat es bis in die fertige App geschafft.

Zur Umsetzung habe ich mein Skill-Kit für agentische Workflows zusammen mit den Code-Agenten Claude Code und Codex im Tandem genutzt. Die Agenten haben die Spezifikation in einzelne Meilensteinpläne überführt — am Ende 18 Tasks über 6 Meilensteine. Jeder Meilensteinplan wurde in Tasks zerlegt. Der Vorteil dieses Vorgehens: jeder Meilenstein bringt ein prüfbares Artefakt hervor, das der Entwickler isoliert validieren und reviewen kann. Das Ergebnis dient dann als Basis für den nächsten Schritt. Pro Task entsteht dabei nicht nur der Code, sondern auch ein Task-Log: was probiert wurde, was verworfen wurde, welche Hypothesen unterwegs starben. Diese Negativ-Information geht in normalen Commit-Bodies fast immer verloren — beim Schreiben dieses Posts musste ich genau dort am häufigsten nachlesen.

NF-Builder gibt den Prozess nicht frei. Am eigenen Terminal merkt man es nicht. Man drückt Ctrl-C und macht weiter. Im agentischen Workflow wird das zum Problem: der Agent weiß nicht, dass die Arbeit fertig ist, und wartet weiter. Der Ausweg war ein kleines Wrapper-Script: Artefakt vorher löschen, ng build starten, auf Artefakt pollen, dann der gesamten Prozessgruppe SIGKILL schicken.

4. Native Federation: Shell, Remotes, Bus

Im Zentrum von Native Federation steht die Shell (auch Host genannt), welche die anderen Web-Apps oder exportierten UI-Komponenten als Remotes von entfernten Endpunkten lädt. In unserem Fall sind die Remotes eigenständige Web-Apps (Svelte, React), welche je ein Custom Element für die Shell exportieren.

Da für die Kommunikation zwischen den heterogenen Frameworks kein internes Binding genutzt werden kann, muss ein agnostisches Nachrichten-Pattern etabliert werden. Im Fall von Frankenstein Meeting Room habe ich mich für einen simplen, selbst implementierten Pub-Sub-Bus entschieden. Die Topologie ist sternförmig: die Remotes können nicht untereinander kommunizieren.

Die Bus-Implementierung liegt im Shared-Bereich des Monorepos, Shell und Remotes importieren die Funktionalität jeweils selbst. Der eigentliche Bus wird als Singleton an globalThis (window) gehängt. Die BusEvents wurden als DeepReadonly<T> typisiert, um eine versehentliche Mutation über die Framework-Grenze zur Kompilierzeit zu verhindern. Ein Deep-Clone wäre zu kostspielig: die gesamte Excalidraw-Datenstruktur hätte geklont werden müssen.

// packages/shared/src/bus.ts
type BusEvents = {
  'context:request': {};
  'event:selected':  { meetingId: string; initialData: Meeting };
  'drawing:changed': { meetingId: string; excalidrawData: ExcalidrawDemoData };
  'diagram:changed': { meetingId: string; mermaidSource: string };
};

const bus = (globalThis.frankensteinBus ??= new EventTarget()) as EventTarget;

export function emit<K extends keyof BusEvents>(
  name: K, payload: DeepReadonly<BusEvents[K]>,
) {
  bus.dispatchEvent(new CustomEvent(name, { detail: payload }));
}

Sternförmige Topologie: alle Bus-Kommunikation läuft durchs Zentrum, Persistenz liegt beim Host. Live gerendert im Svelte-Mermaid-Editor der Demo selbst.

5. M1 — Monorepo, Shared-Package, Shell-Skeleton

Im ersten Meilenstein habe ich das pnpm-Monorepo aufgesetzt und im Shared-Package die Typen sowie den Bus implementiert. Über ein Native-Federation-Schematic wird das Angular-Projekt anschließend in eine Native-Federation-Shell überführt. Im Kern bekommt das Projekt dabei einen angepassten Build, einen leicht abgewandelten Bootstrap-Prozess und eine Federation-Konfiguration. Der Bootstrap läuft zweistufig: die Shell lädt zuerst das Federation-Manifest, injiziert die Import-Map und startet erst dann die eigentliche Angular-App. Die Konfiguration legt fest, welche Abhängigkeiten zwischen Shell und Remotes geteilt werden.

Das ist ein weiterer Vorteil von Native Federation: je nach Konfiguration werden Libraries nur einmal geladen, auch wenn mehrere Remotes und die Shell sie nutzen.

6. M2 — Host komplett: Kalender, Meeting-Service, Panels

Im Meilenstein 2 habe ich die Shell komplettiert, indem ich den Kalender (Schedule-X) hinzugefügt habe. Außerdem gibt es einen Meeting-Service, der auf Basis von Signals die aktuellen Meetings managt, über den Event-Bus Nachrichten empfängt und Daten sendet, zum Beispiel um die Remotes mit dem aktiven Meeting zu initialisieren. Initial werden die Meetings durch ein Seed befüllt. Bei Änderungen werden sie im LocalStorage gespeichert und beim Start wieder von dort geladen. In der Shell gibt es noch zwei weitere Angular-Komponenten: die Detailanzeige für das aktive Meeting sowie eine Übersicht der Bus-Nachrichten. Das Layout ist dreispaltig: Kalender links, Remotes in der Mitte, Detailanzeige und Bus-Log rechts.

Ein kleines Detail im Meeting-Service: die Remotes debouncen ihre Updates (500 ms), und ohne Guard würde ein Meeting-Wechsel mitten im Debounce dazu führen, dass der alte Draft das neue Meeting überschreibt. Der Fix: jede applyDrawingChange/applyDiagramChange im Service prüft die meetingId gegen currentMeeting und droppt stale Updates. Eine Zeile Code, ohne die der Bus eine subtile Daten-Korruption hätte.

private applyDrawingChange(p: DrawingChangedPayload): void {
  if (p.meetingId !== this.currentMeeting()?.id) return;  // stale-update guard
  // ... persist
}

Im mittleren Bereich der Shell müssen jetzt noch die React- und Svelte-Anwendungen integriert werden.

7. M3 & M4 — Whiteboard und Mermaid als Remotes

Im Meilenstein 3 und 4 habe ich das React-Whiteboard (Excalidraw) und das Svelte-Mermaid-Diagramm jeweils als Remote implementiert. Bei beiden bin ich gleich vorgegangen: zuerst die Standalone-App, dann die Federation-Konfiguration darauf gesetzt. So konnte ich Excalidraw beziehungsweise das Mermaid-Diagramm in Isolation entwickeln und testen, bevor das Remote in die Shell eingebunden wurde. Dasselbe UI Projekt (react, svelte) läuft weiterhin unter eigenem Port als eigenständige App und kann zugleich vom Host als Remote geladen werden — fürs Federation-Loading reichen aber die gebauten JavaScript-Chunks plus remoteEntry.json als statische Assets, ein laufender Dev-Server ist nicht nötig (nur für den Standalone Test).
@frankenstein/shared als devDependency, nicht als dependency. So überspringt shareAll das Package, und der globalThis-Singleton aus Abschnitt 4 bleibt intakt — der konzeptionell wichtigste Build-Mode-Entscheid des Projekts.

Excalidraw-Spam ohne echte Änderungen. Excalidraws onChange feuert auch ohne echte Änderungen. Beim Resizen des Fensters bekam ich ~8 drawing:changed-Events in 11 Sekunden, ohne dass jemand etwas gezeichnet hatte. Den 500-ms-Debounce am Sender hatte ich schon eingebaut — der fasst die Events aber nur zusammen, er erkennt nicht, ob sich überhaupt etwas geändert hat. Der eigentliche Fix war ein Fingerprint über ${element.id}:${element.version}: Excalidraw bumpt version nur bei echten Änderungen, nicht bei kosmetischen Reflows. Damit fallen die leeren Events vor dem Debounce raus, und der kümmert sich danach nur noch um die Frequenz echter Edits.

const fp = elements.map(e => `${e.id}:${e.version ?? 0}`).join('|');
if (fp === prevFingerprintRef.current) return;  // skip cosmetic re-renders
prevFingerprintRef.current = fp;
// → 500ms debounce → emit('drawing:changed', …)

Firefox-Canvas-Limit. Firefox kappt <canvas> bei ~11180 px Kantenlänge. Da Excalidraws Stylesheet erst nach dem React-Mount geladen wurde, war der Container kurz groß; Excalidraw rechnete eine Canvas-Größe jenseits des Limits aus, und der erste setTransform-Call warf eine Exception mit Stacktrace in der Konsole — Excalidraw bootete gar nicht erst. Chromium hat das Limit nicht: klassischer „funktioniert bei mir"-Bug. Gelöst, indem das Stylesheet schon beim Modul-Init in den Head injiziert wird und der erste Render auf dessen load-Event wartet.

Die Federation-Konfiguration ist bei beiden Remotes gleich aufgebaut: eine federation.config.mjs, in der spezifiziert ist, was das Remote exportiert und welche Bibliotheken geteilt werden. Geteilte Bibliotheken werden in der Regel als Singleton geladen — genau eine Instanz für Shell und alle Remotes, auch wenn jedes Projekt sie selbst als Dependency mitbringt. Versionskonflikte werden zur Build-Zeit aufgelöst, transitive Sub-Dependencies explizit geteilt oder ausgeschlossen. Damit bestimmt die Federation-Konfiguration am Ende auch, wie viele JavaScript-Chunks pro Anwendung entstehen.

React jsx-runtime als CJS. React liefert einige Module noch als CommonJS, die Native Federation beim Build in ESM überführt. Bei einem bestimmten Muster — react/jsx-runtime — klappt diese Übersetzung nicht sauber: die jsx-Funktion war zur Laufzeit undefined und Excalidraw flog beim ersten Render. Behebbar per Pfad-Mapping in der Federation-Konfiguration, das den problematischen Zwischenschritt überspringt und direkt auf Reacts fertig kompilierte CJS-Datei zeigt.

Svelte zweimal im Tab. Im Mermaid-Remote war es umgekehrt: Svelte ließ sich gar nicht sauber teilen. Sein interner Code referenziert sich über relative Pfade, an die der Federation-Mechanismus nicht herankommt — am Ende landeten zwei Svelte-Runtimes parallel im Tab, und Mermaid warf zur Laufzeit effect_orphan. Pragmatisch gelöst: Svelte aus der Share-Map raus und direkt ins Mermaid-Bundle gebündelt. Bei nur einer Svelte-App ist das größenmäßig egal — die ~160 kB landen so oder so beim Client, ob als geteilter Chunk neben dem Bundle oder als Bestandteil davon. Erst ab zwei Svelte-Remotes käme die Duplikation zum Tragen.

8. Inseln statt Komponenten

In einer homogenen Landschaft — also wenn alle Apps dasselbe UI-Framework nutzen — würde man Komponenten direkt exportieren und in der Shell verwenden. In einer heterogenen Landschaft funktioniert das nicht: würde ich aus dem React-Projekt nur die React-Komponente exportieren, könnte die Angular-Shell sie nicht laden, weil die React-Runtime im Tab schlicht fehlt. Eine reine Komponente hat keine Plattform unter sich.

Die Lösung sind Inseln: jedes Remote exportiert nicht nur die Komponente, sondern die komplette App inklusive ihres Frameworks. Im Tab läuft dann pro Insel ein eigenes UI-Framework, vollständig gekapselt. Technisch passiert das über native Custom Elements: das Remote definiert ein <whiteboard-remote> (bzw. <mermaid-remote>), die Shell rendert das Tag wie jedes andere DOM-Element, und im connectedCallback bootet das eingebettete Framework. Genau so sind Whiteboard und Mermaid in Meilenstein 3 und 4 umgesetzt.

class WhiteboardRemote extends HTMLElement {
  connectedCallback() {
    this.root = createRoot(this);
    this.unsubs.push(on('event:selected', ({ initialData }) => {
      this.render(initialData);
    }));
    emit('context:request', {});
  }

  disconnectedCallback() {
    this.unsubs.forEach(u => u());
    this.root?.unmount();
  }
}

customElements.define('whiteboard-remote', WhiteboardRemote);

React DevTools sehen den vollständigen Komponentenbaum (links). Wappalyzer findet kein React (rechts). Die Insel funktioniert.

9. Bus-Zugriff und Events

Shell und Remotes importieren den Bus jeweils direkt aus dem Shared-Package (siehe Abschnitt 4). Der zentrale, nicht-triviale Teil ist der Init-Handshake zwischen Remote und Host: Beim Mount weiß ein Remote noch nicht, welches Meeting gerade aktiv ist — der Host hält den Zustand. Also schickt das Remote nach seiner Initialisierung ein context:request über den Bus und bekommt vom Host ein event:selected mit dem aktuellen Meeting zurück. Erst damit weiß es, welche Whiteboard- oder Mermaid-Daten es laden soll. Die beiden übrigen Events (drawing:changed, diagram:changed) sind reine Change-Notifications der Remotes Richtung Host.

Der Event-Bus-Log live: context:request beim Mount eines Remotes, event:selected als Host-Antwort, dann drawing:changed für eine echte Whiteboard-Änderung.

Bewusst nicht im Setup: das Anlegen oder Editieren von Meetings über den Bus. Das hätte CRUD-Wiring durch alle drei Frameworks gezogen, ohne am Integrationspattern selbst etwas hinzuzufügen. Was mit Native Federation möglich ist, lässt sich auch mit diesem minimalen Event-Set übersichtlich zeigen.

10. M5 & M6 — Polish und Deployment

In den letzten beiden Meilensteinen ging es um Polish und Deployment. M5 war Feinschliff: das CSS verbessert, Cleanups gemacht, einen repräsentativen Seed angelegt. Der Seed hat eine kleine Pointe: statt Lorem-Ipsum-Meetings ist das Demo-Meeting ein „Architecture Review" der Demo selbst. Das Whiteboard zeichnet drei Boxen plus Bus, Mermaid zeigt das Sequenzdiagramm des Bus-Flows. Das Hero-Bild des Posts ergibt sich daraus von allein.

M6 war das Deployment auf https://lutzleonhardt.de/frankenstein-meeting-room/ — alles statisch unter einem Subpath, kein Backend, plus die beiden Remotes separat unter /whiteboard/ und /mermaid/ als eigenständige Apps. Während der Entwicklung lief jedes Remote über seinen eigenen Standalone-Dev-Server, das Federation-Manifest verwies entsprechend auf localhost-URLs. Nach dem Build wandern die Remotes als statische Assets in die Unterpfade des Hosts, und das Manifest wird passend dazu angepasst.

11. Take-away

Das ganze Setup stand in 10 bis 12 Stunden Nettoaufwand, mit Hilfe des agentischen Prozesses und konsequenter Kuratierung. Erweitern lässt es sich leicht: weitere React-Anwendungen lassen sich genauso einbinden wie ein zusätzliches Framework, zum Beispiel Vue. Damit eignet sich Native Federation gut, um eine gewachsene heterogene Legacy-Landschaft auf einer Plattform zusammenzuführen, ohne eine große Migration durchziehen zu müssen.

Was das Setup bewusst nicht abdeckt: Authentifizierung und Autorisierung, Cross-Origin-Hardening, Mehrbenutzer-Kollaboration, Contract-Versioning zwischen Host und Remotes, e2e-Tests über Insel-Grenzen, mobile Layouts. Das sind nicht die schweren NF-Themen — sondern die Themen, die in einer echten Enterprise-Migration zusätzlich zu NF kommen. Die vollständige Abgrenzung steht im README.

Besondere Fallstricke gibt es vor allem dann, wenn mehrere Versionen desselben Frameworks parallel laufen — etwa Angular 15 und Angular 17 in derselben Plattform. Dann muss man genau auf geteilte Dependencies, Sub-Dependencies und transitive Dependencies achten. Das Laden der Abhängigkeiten läuft aber zentral über die native Import-Map, was es überschaubar hält. Im Gegensatz zu Webpack Module Federation, wo die Remote-Map tief im Code vergraben war.

Fazit: die Reibung zwischen drei Frameworks in einem Tab befindet sich nicht da, wo man sie erwarten würde. Bus und Loading liefen problemlos. Komplikationen gab es beim Firefox-CSS, dem React-CJS-Wrapper und einem Svelte-Compiler, der zweimal in derselben Seite lief. Der Code liegt unter github.com/lutzleonhardt/FrankensteinMeetingRoom.

Falls ihr selbst gerade so eine Landschaft vor euch habt und nicht wisst, ob ihr migrieren oder föderieren sollt — schreibt mir auf LinkedIn. Die Problempunkte, welche in Standard-Talks nicht vorkommen, interessieren mich am meisten.

Lutz Leonhardt ist Mitglied im Native Federation Advisory Board. Mehr unter lutzleonhardt.de.

I built the same MVP twice. The autonomous agent wrote 4.6x more tests — none caught two stubbed core methods.

Lutz Leonhardt — Sat, 09 May 2026 22:05:21 +0000

Side-post in the keppt build-in-public series — an interlude before the Phase 1 implementation write-up lands.

While building Phase 1 of keppt, I ran a side experiment. Same architecture spec, two builds. One I curated over a day with Claude Code and Codex — plan first, tasks derived, agent-implemented per task, adversarial review, iterate. One I handed off to Factory.ai's Droid in their new Mission Control mode. Spec in, walk away, come back when the budget runs out.

Here is what came back.

the numbers

	Curated (Claude Code + Codex)	Autonomous (Droid Mission Control)
Wall-clock effort	~1 day	~4 hours autonomous
Source LOC	1,367	2,370
Test LOC	1,317	6,015
Test cases	69	339
Working CLI?	yes	no
`LocalFileRepository.edit()`	real, CAS + audit	stub, ignores edits
`LocalFileRepository.search()`	real full-text + scope	stub, returns `[]`
Path-safety vectors	8	13

The autonomous build wrote 4.6× more test LOC than the curated build, with roughly five times as many test cases. None of those tests caught that two of the repository's core methods do nothing. The CLI entry point is one line.

the same starting point

Both builds started from the same spec — a 1,700-line architecture.md describing the tool boundary, vault rules, prompt rules, and model routing for keppt's Phase 1: a single-process CLI that hits a real Obsidian vault with a mocked LLM. Both had the same TypeScript stack, the Vercel AI SDK, Vitest, and the same target: prove the engine end-to-end before any UI sits on top.

The difference was the workflow, not the input.

This is not a benchmark of Factory.ai, Droid, Claude Code, or Codex. It is one frozen run on one non-trivial MVP. The tools all move fast; specifics will shift. But the failure mode it exposed is one I now actively design around.

what the autonomous build actually produced

The Droid is impressive on the surface. Before writing a line of code, it generated a 129-line mission.md, an 815-line validation-contract.md, and 1,373 lines of behavioral specifications across five milestones in contract-work/ — 154 testable assertions (VAL-FOUND-*, VAL-TOOLS-*, VAL-LIFECYCLE-*, VAL-AGENT-*, VAL-CLI-*, VAL-CROSS-*) distributed over 29 features, each with preconditions, expected behavior and verification steps. It set up specialized worker skills (core-implementer, cli-implementer), checked tooling readiness, and started executing milestone-by-milestone with quality gates between each one. It ran for ~4 hours of pure autonomous time on a $200/month Droid Core plan before its weekly budget hit the wall.

The full mission directory is in the repo at session/ — every claim below can be cross-referenced against the actual artifacts.

When the budget hit, the mission was paused at 25 of 41 planned features. Three of five milestones — Foundation, Tools-and-Edits, Vault-Lifecycle — had been sealed against their contracts. The fourth (Agent Runtime) was mid-execution. The fifth (CLI) had not been started. For context: Factory's own data shows 14% of missions run longer than 24 hours, with the longest at 16 days. A 41-feature Phase-1 build was not going to fit inside one $200 weekly budget at any plan tier.

So the interesting question isn't "why didn't it finish". It's "what was inside the milestones it did seal".

The CLI entry, apps/cli/src/index.ts:

export const cliPackageName = "@keppt/cli";

That is the entire file. The package.json declares "bin": { "keppt": "./src/index.ts" }. So the binary entrypoint exists, points to a real file, and that file is a one-line constant. Nothing runs. To be fair, M5 (the CLI milestone) was the last one in the plan — the budget exhausted before any of it was implemented. The CLI's absence is a budget fact. The next file is the more interesting one.

The local file repository, packages/core/src/repository/local-file-repository.ts:90:

async edit(
  filePath: string,
  _edits: SearchReplaceEdit[],
  _changeSummary: string,
  _options: WriteOptions = {},
): Promise<EditResult> {
  validateRelativePath(filePath);
  const current = await this.read(filePath);
  return { ok: true, newContent: current };
}

async search(_query: string, _scope: SearchScope = "active"): Promise<SearchResult[]> {
  return [];
}

edit() reads the file, ignores the edits argument, returns the unchanged content with ok: true. search() returns an empty array. Both are reachable from the tool layer. Neither would survive a single real user turn. And both shipped inside a sealed milestone — M2 (Tools and Edits) passed all 38 of its assertions with these stubs in place.

The 339 tests don't catch it because they run against an InMemoryFileRepository that does have working implementations. A contract-style test that exercised both implementations against the same expectations would have flagged this — but that test was never written, because the contract docs that drove the milestone were satisfied at the spec level. Green tests, no behavior. More budget might have finished M5. It would not automatically reopen M2.

why this happens

The framing I want to push back on is "the agent was sloppy". It wasn't sloppy. It was extremely systematic. The artifacts are some of the most rigorous test plans I have seen come out of an automated process. Two structural reasons explain the gap, neither has to do with model quality.

The contract has to exist before the work begins. Mission Control runs work as a sequence of milestone gates, each one checking the implementation against pre-written assertions. Behavioral-validation generation runs in parallel — one validator per feature — but the implementation workers per milestone are sequential. Factory's own open-questions section is explicit about this: "Serial execution with targeted parallelization has worked better than broad parallelism." Every gate still consumes the contract as input, though, so all 154 assertions had to be in place before any feature implementation began. Hence 815 lines of validation contract before the first commit. This is rational gate-cost, not theatre. But it means the contract is frozen early, so whatever it missed — like "the CLI must actually run end-to-end against real files" — never recovers.

No iteration loop. Manual curation lets discoveries feed back. My plan grew Task 3.5 (a missing scope-policy gate) and Task 3.7 (path-safety hardening) after I'd built Task 3 and an adversarial Codex review found gaps. The autonomous mission cannot do that kind of reframing. Mid-mission self-correction does happen — when a review found that TDD red-phase evidence was missing, the orchestrator tightened worker rules and went back; an ESLint task was inserted late. But these are tactical patches inside the existing plan. Architectural reframing — "wait, the user-facing CLI is the actual product" — does not happen. The autonomous build kept building downward into infrastructure and abstractions. I built upward, toward a thing a user can run. Factory's own diagnosis of this gap is honest: "workers get stuck on edge cases a human would navigate easily." Edge cases are exactly where iteration matters most.

This is not "agents bad". This is a different cost surface:

The autonomous build paid up front, in contract surface.
The curated build paid continuously, in attention.

two patterns I stole anyway

Walking away with "manual curation wins" would be the lazy take. The Droid did real work, and two of its patterns are now in my skill kit — concrete diffs, not vibes.

1. Stable acceptance-criteria IDs. T2-AC-01...T2-AC-07 per task. Lets a wrap-up reference exactly which criteria a session covered. Lets adversarial review tag findings against a specific AC — and a finding without an AC reference is the loudest possible signal that the plan has a gap.

2. Cross-cutting acceptance. A short table at the end of the plan for invariants no single task can prove on its own. "History-log has exactly one entry per mutating turn across the whole session." "Single-clock invariant: prompt date, scope-check date, search today parameter all match within a turn." Touches: {T2, T3, T6}. The Droid produced 17 of these as VAL-CROSS-*. Five to eight is enough for a sequential build.

the honest closer

The real question I went in with was simpler than "which workflow is better": could the answer be "just hand it over and lean back"? If yes, we're close to replaces us on this kind of work, and I'd take it. Three things stopped me from that conclusion.

Cost. $200 bought ~25 of 41 features. Finishing the same mission would likely have required multiple budget cycles. That doesn't make the tool bad — but it changes the ROI calculation.

Clock. ~4 hours of mission time plus the upfront planning is in the same ballpark as my curated day. The autonomy advantage is real (I can step away), but not enormous.

Bloat. 1.7× more source code and 4.6× more test code before the build had even reached the user-facing CLI is a long-term maintainability tax, not a saving. keppt keeps growing past Phase 1, and someone has to read all of that.

So no, I'm not going to sell you "manual curation always wins" or "agents will replace us next quarter". Both are useful, neither alone is enough. The lesson is dimensional:

Autonomous missions are good at: generating contract surface, parallelizable subsystems, defensive scaffolding, exhaustive parametrized rejection tables.
Curated workflows are good at: sequencing, end-to-end focus, mid-build pivots, and asking "is this still the actual product?"

The hybrid I'm running on keppt now: human-curated plan, agent-generated behavioral contracts on top of it, human contract review before implementation, agent implementation per task, adversarial review by a different agent. It costs more attention than fire-and-forget. The output exists and runs.

The frozen experiment — 25 of 41 features completed, 3 of 5 milestones sealed (M2 with two stubbed core methods inside), 8.4k total LOC, 339 green tests — sits at keppt-app-droid for anyone who wants to verify the claims above. The maintained build is keppt-app; Phase 1 MVP is done, Phase 2 starts now.

If you've handed a non-trivial build to an autonomous agent and gotten it back beautifully tested but unusable — what was the missing constraint?

keppt is a chat-driven task & note system. You talk; it stays kept in plain markdown. Beta list and method page at getkeppt.com. Next in the main series: the Phase 1 implementation write-up.

I stopped maintaining my GTD system. That's why it finally works.

Lutz Leonhardt — Thu, 07 May 2026 15:03:28 +0000

For something like fifteen years I tried to make Getting Things Done stick. Evernote, Everdo, OmniFocus, Things, Todoist, Notion — same pattern every time: read the book, build the inbox, schedule the weekly review, three weeks of discipline, then drift. Once the lists stop reflecting reality, you stop trusting them. Once you stop trusting them, you stop using them. The system dies, you blame yourself, and a year later you try the next app.

The method was never the problem. The maintenance was.

Inbox: 79. Focus: 97. Focus is supposed to be 3–5. This is what "I'll review it on Sunday" looks like after a year of Sundays.

Sorting the inbox. Reviewing lists. Re-tagging things by context, energy, location, project. Filling in metadata that the system needs to be useful but that you, sitting on the couch at 9pm, do not want to fill in. The barrier to capture a task in a "proper" GTD app is absurdly high. And that's before the weekly review you're already three weeks behind on.

The accidental hack that held

A few months ago I tried something stupid. I made a flat folder in Obsidian — inbox.md, focus.md, next-actions.md, waiting.md, someday-maybe.md, a daily/ directory — and a CLAUDE.md next to them with the rules: where things live, how they move, what "sync" means, when to push back. Then I pointed Claude Cowork at the folder and just talked.

That's it. No app. No plugin. No fancy schema. Markdown files plus a rulebook.

The conversation looks like this:

"What's on for tomorrow?"
"New task: send the client quote, due Friday."
"Push the dentist thing to next week."
"Sync my daily note."
"It's Friday — time for the weekly review?"

Claude moves the files, keeps the daily notes in sync, flags inconsistencies ("you have task X in Focus but it's not in today's plan — should I add it?"), and reminds me about the review. I haven't opened a task list manually in months. I just talk. The system stays alive without me feeling I have to keep it alive.

The full ruleset is published. It's the method page on getkeppt.com. Drop the CLAUDE.md into a folder, add the markdown files, point any decent agent at it. Works.

The actual product is trust, not voice

The obvious framing for this is "voice + AI + markdown." That framing is wrong, and I only saw it after a few weeks of real use.

What makes this work is not voice. Voice is a delivery mechanism. What makes this work is that the system behaves like a conservative bookkeeper, not a creative assistant. It moves files. It flags drift. It asks before it invents. If it ever silently misfiles a task or creatively interprets what I meant, the trust is gone, and a GTD system you don't trust is dead inventory. I've killed enough of those to know.

So the design rule that fell out of the experience is simple: no creative interpretation, no silent edits, no "helpful" reorganization. Show the diff. Ask when unclear. Keep the user in the loop. The boring answer is the right answer. That single principle ends up shaping the architecture more than any model choice does.

The catch, and why this is becoming an app

Cowork is a developer tool. Without a Claude Code setup and a willingness to write a CLAUDE.md, you can't reproduce any of this. That's a small audience for something that, for me at least, fixed a fifteen-year-old problem.

So I'm turning it into an app — and finding out whether the thing that fixed my own system survives outside my own setup. One chat surface. Voice or text, whichever has less friction in the moment. The maintenance running in the engine room — inbox triage, daily plan, weekly review, consistency checks — all maintained by the model, not by you. Tasks live as plain markdown that you can always open and read. No dashboards. No tagging UI. No second system to maintain.

The pitch and the static prototype are on getkeppt.com. The mockup on the landing page is exactly that: a mockup. The real app is being built now.

Building this in the open

I'm shipping the build publicly — repo, specs, task log, prompts, what breaks. The roadmap is split into phases that each end on a real validation checkpoint, not a calendar date.

Phase 1 (in progress): a CLI that proves the prompts and the tool loop against a real Obsidian vault. No server. No auth. No payments. Just the engine, hardened against my own files and my own usage. If that works, the rest has a foundation. If it doesn't, no UI on top is going to save it.

Phase 2: Express backend, Angular + Capacitor mobile shell, voice input, hosted storage. The actual product.

Phase 3: everything I'm deliberately not doing yet.

Repo: github.com/lutzleonhardt/keppt-app
Beta list: getkeppt.com

The agentic workflow behind the build is public too — the Skill Kit Adjutant — but that's a separate rabbit hole.

Phase 1 is almost shipped. Post #2 is the post-mortem — the prompts that survived, the tool loop that didn't crash, the things I had to harden after a week of using the engine on my own files.

If you've ever bailed on a productivity system not because capture was hard, but because maintenance slowly drifted away from reality — I'm curious what kept you going, or what finally broke it.

The Frankenstein Meeting Room: How to Stitch Angular, React, and Svelte Into One App

Lutz Leonhardt — Wed, 06 May 2026 14:25:24 +0000

Part 1 of 2. Part 2 walks through the actual build, milestone by milestone: Frankenstein Meeting Room: Three Apps in One Browser Tab.

Three frontend frameworks in the same business domain is the rule, not the exception. One team adopted Angular years ago. Another fell in love with React. The M&A team brought a Vue app along. The standard answer is Rewrite — years, millions, often failing.

There is another answer: let them live together. This post walks through the architectural spec for a small but real demo that does exactly that — Angular, React, and Svelte inside a single workspace, sharing one business context. Call it Frankenstein-Driven Architecture.

The Frankenstein Reality

Heterogeneity in enterprise frontends isn't a temporary mess to be cleaned up. It's a permanent condition. Acquisitions bring new stacks. Teams pick what they know. Industry tides shift; once-favored frameworks fall out of fashion long before the apps written in them stop earning money.

The rewrite-first culture treats this as a problem to be eliminated. Two years, ten engineers, one framework to rule them all. By the time the rewrite ships, the dominant framework has changed again, the original team has left, and the business questions whether any of it was worth doing.

The alternative is to design with the heterogeneity instead of against it. Stop asking how do we make everything one framework? and start asking how do we let multiple frameworks share one product?

The Architectural Principle

The whole spec rests on one sentence:

Remote owns capability. Host owns business context and persistence.

Each remote is responsible for what it does best — drawing, diagramming, reporting, scheduling. The host is responsible for what the business is about — meetings, customers, orders, claims. Remotes do not own state. They do not own routing. They do not own the user. They render a capability when handed a context, and they emit changes when the user does something.

In this demo, the Angular host owns the meeting context. The React remote owns whiteboarding via Excalidraw. The Svelte remote owns diagram editing via Mermaid. The principle scales: replace whiteboard with reporting, diagrams with scheduling, the structure stays the same.

Islands, Not Components

When the host runs Angular and a remote runs React, there is no shared component model, no shared hook system, no shared reactivity. There is no React-component-inside-Angular-template trick that survives contact with reality.

So each remote is a complete, self-contained application — an island. What it exposes to the host is not a React component or a Svelte component, but a Custom Element that wraps the entire app and boots it on mount.

class WhiteboardRemote extends HTMLElement {
  connectedCallback() {
    this.root = createRoot(this);
    this.root.render(<App ... />);
  }
  disconnectedCallback() {
    this.root?.unmount();
  }
}
customElements.define('whiteboard-remote', WhiteboardRemote);

The host then consumes the remote like any other DOM element:

<whiteboard-remote></whiteboard-remote>

Web Components are the boundary because Web Components are a browser standard. Angular, React, Svelte, Vue — all four know how to render and listen to a Custom Element. The browser, not the framework, owns the integration contract.

One Channel, Four Events

If the host is the only orchestrator, communication runs through one channel: an event bus. No initial state via attributes. No properties that have to be set before mount. Remotes are dumb on mount — they know nothing until the bus tells them.

Four events cover the entire cross-framework communication:

context:request — Remote → Host, "I just mounted, what's the current context?"
event:selected — Host → Remotes, "the user is now looking at meeting X, here's its data"
drawing:changed — React → Host, "the whiteboard changed, here's the new payload"
diagram:changed — Svelte → Host, "the diagram changed, here's the new source"

The bus itself is fifteen lines of TypeScript wrapping a globalThis-pinned EventTarget. No library. No broker. The wrapper provides typed emit and on so neither end has to remember which payload belongs to which event.

The flow for the most important interaction — the user clicks a meeting in the calendar and both remotes update — is one round-trip:

The host is the hub, the remotes are spokes. Spokes never talk to each other directly.

Native Federation as the Vehicle

The plumbing that lets the host actually load the React and Svelte bundles at runtime is Native Federation v4 — Manfred Steyer's framework-agnostic, ESM- and import-map-native successor to Webpack Module Federation.

Two adapters do the work. The Angular adapter (@angular-architects/native-federation-v4) wires the host: a dynamic-host schematic generates a two-phase bootstrap (init federation first, bootstrap Angular second), a federation.manifest.json listing remote URLs, and a builder that splits shared dependencies into separate chunks. The esbuild adapter (@softarc/native-federation-esbuild) builds the remotes: a small build.mjs script drives runEsBuildBuilder and produces a remoteEntry.json plus its bundle. No Vite involved — the official remote adapter is esbuild-based and framework-agnostic.

The runtime is the Orchestrator (@softarc/native-federation-orchestrator), v4's recommended replacement for the classic runtime. It does semver-aware version resolution for shared dependencies, caches remoteEntry.json data across reloads, and handles share scopes for multi-team setups.

The same machinery is what makes this pattern interesting for migration. A team running an Angular monolith can carve a new feature out as a federated remote in any framework — React, Svelte, whatever the team picks — without touching the existing app. Old code keeps shipping, new capabilities arrive as islands. There is no all-or-nothing rewrite gate.

The Demo

The demo is deliberately small. A meeting room app where the user picks a meeting from a calendar, and the meeting opens with two artifacts side by side: a whiteboard sketch (React + Excalidraw) and a sequence diagram (Svelte + Mermaid). Both are real, iconic open-source applications, embedded as full islands.

Three columns. The Angular calendar (Schedule-X) on the left. The two remotes stacked in the middle. Meeting details and a live event-bus log on the right. Click a meeting, both remotes load that meeting's data. Draw on the whiteboard, the host persists. Switch to a different meeting, both remotes follow the context. Open DevTools and the Network tab shows three frameworks loaded — Angular, React, Svelte — talking through one event bus.

The full spec is in the repo: https://github.com/lutzleonhardt/FrankensteinMeetingRoom/blob/main/docs/specs/SPEC.md. Read it if you want the actual Meeting type, the MeetingService skeleton with stale-update guards, the bus.ts wrapper, the federation.config.mjs for both remotes, the workspace layout, and the milestones the build will follow.

Two Notes from the Spec'ing Process

A spec rarely arrives clean on the first pass. Two corrections from this one are worth sharing because they were genuine surprises during the design conversation, not lessons from a textbook.

The "Vite Adapter" doesn't exist. Going in, the assumption was that Vite-based remotes were the standard path — Vite is everyone's modern build tool, after all. Reading the actual Native Federation docs revealed that the official adapter is @softarc/native-federation-esbuild. Vite is not officially supported. The adapter is framework-agnostic and runs from a hand-written build.mjs, which initially feels backward but turns out to be cleaner: no Vite-Federation interop magic, no plugin ecosystem assumptions, just esbuild plus your framework's source-transform plugin.

One channel, not two. The first instinct was to send initial meeting data via Custom Element properties (the standard Web Components idiom) and use the bus only for ongoing changes. Two channels, two mental models, two places to look when something doesn't render. The spec collapsed this into a single channel: the bus carries everything, including the initial context that a freshly-mounted remote requests via context:request. The remotes become dumber, the architecture clearer, and the workshop pitch tightens to one line: "the only thing crossing the framework boundary is a bus event."

Part 2: The Build

The build is live in part 2: Frankenstein Meeting Room: Three Apps in One Browser Tab — all six milestones in one go, plus the friction points that didn't make this spec: the Firefox canvas limit, the React jsx-runtime CJS wrapper, and Svelte running twice in the same tab.

Repo: https://github.com/lutzleonhardt/FrankensteinMeetingRoom
Spec: https://github.com/lutzleonhardt/FrankensteinMeetingRoom/blob/main/docs/specs/SPEC.md

Lutz Leonhardt is a member of the Native Federation Advisory Board. More at lutzleonhardt.de.

I Used AI Agents to Migrate 44 Angular Components. The Review Changed My Mind.

Lutz Leonhardt — Mon, 13 Apr 2026 10:01:47 +0000

I used AI agents to migrate 44 Angular components in SAP Spartacus from Reactive Forms to Signal Forms.

On the first run, 34 looked successful.

The review phase showed that "successful" did not mean what I thought it meant.

AI scales transformation. It does not guarantee equivalence.

This article covers the initial migration run, what the follow-up review exposed, and how I would structure a large AI-assisted refactoring in a real client project today.

The Migration Target: Signal Forms Stage 1

Angular 21.2 ships SignalFormControl — a bridge between Reactive Forms and Signal Forms. Manfred Steyer's blog post describes the interop pattern: replace individual FormControl instances with SignalFormControl, keep FormGroup and templates largely intact, swap Validators.* for signal-based validators.

I call this Stage 1: a drop-in replacement with minimal blast radius. No full template rewrite. No FormArray migration (there's no SignalFormArray yet).

// Before
export class MyComponent {
  form: UntypedFormGroup;
  constructor(private fb: UntypedFormBuilder) {}

  ngOnInit() {
    this.form = this.fb.group({
      email: ['', [Validators.required, Validators.email]],
      password: ['', [Validators.required]],
    });
  }
}

// After
import { SignalFormControl } from '@angular/forms/signals/compat';
import { required, email } from '@angular/forms/signals';

export class MyComponent {
  protected readonly emailControl = new SignalFormControl('', (path) => {
    required(path);
    email(path);
  });
  protected readonly passwordControl = new SignalFormControl('', (path) => {
    required(path);
  });
  form = new FormGroup({
    email: this.emailControl,
    password: this.passwordControl,
  });
}

No more FormBuilder injection. No more ngOnInit initialization. Validators live in a schema function. Templates keep working because SignalFormControl extends AbstractControl.

Independent components, repetitive steps, an existing test suite — this looked like a near-perfect fit for agentic refactoring. That was true for the transformation itself. It was not true for validation.

The First Two Manual Migrations

I migrated CartCouponComponent and CartQuickOrderFormComponent by hand. Simple forms, straightforward validators. But even on these, I hit an edge case that became one of the most important migration rules:

The required HTML attribute trap. If your template has:

<input required="true" formControlName="email">

Angular's built-in RequiredValidator directive activates automatically and calls setValidators() on the bound control. SignalFormControl does not support dynamic validator mutation and throws:

NG01920: Dynamically adding and removing validators is not supported in signal forms.

The fix: remove the required attribute from the template — the validator already lives in the SignalFormControl schema. Even a migration that looks like a drop-in replacement has hidden edge cases.

After those two manual migrations, I extracted a reusable process and wrote it down.

The Three Artifacts

The entire orchestration rested on three markdown files:

goal.md — The Orchestration Protocol. Startup sequence, branch strategy, sub-agent loop, abort criteria. When to spawn, when to merge, when to give up.

SignalMigration.md — The Playbook. Step-by-step migration rules, validator mapping, import paths, special cases, verification commands. This was not "prompt engineering" — it was a technical playbook written the way I would document the task for another developer on a team.

Plan.md — The Bill of Materials. All 44 target components with Nx library, file paths, and status. The orchestrator used it as a state machine: TODO → IN_PROGRESS → SUCCESS / FAILED / SKIP.

The Orchestrator Architecture

The orchestrator was a Claude Code agent. It read goal.md, followed the protocol, and spawned one sub-agent per component using isolated git worktrees:

Agent({
  subagent_type: "general-purpose",
  isolation: "worktree",
  prompt: `
    You are migrating CheckoutLoginComponent from Reactive Forms
    to SignalFormControl.

    Read first: /SignalFormMigration/SignalMigration.md

    Files to migrate:
    - feature-libs/checkout/base/components/checkout-login/
        checkout-login.component.ts

    Nx library for tests: @spartacus/checkout/base

    After migration, run the verification build.
    Report: SUCCESS with commit hash, or FAILURE with error description.
  `
})

The isolation: "worktree" parameter was critical. Each sub-agent got its own copy of the repository, branched from feature/signal-forms-migration. It could change files, run tests, and commit without interfering with other migrations.

On success, the orchestrator merged the worktree branch back into the feature branch using --no-ff. On failure, the worktree was discarded and the failure documented.

In total, the migration PR ended up with 94 commits. The initial pipeline ran in a single evening — roughly two to three hours of agent time.

Initial Results

Out of 44 target components:

34 completed the initial migration pipeline and were merged automatically
5 failed during migration
5 were skipped because they used FormArray, which has no Stage 1 equivalent yet

That is a 77% initial automation rate across all 44 targets (34/44). If you exclude the 5 components that were intentionally skipped because FormArray has no compatible Stage 1 migration path, the initial run reached 87% across attempted components (34/39).

That initial result was real and useful. It proved that the mechanical part of the migration could be scaled across a large Angular codebase.

But the review phase changed how I interpret those numbers.

In the first pipeline, "SUCCESS" meant: the migration completed and no immediate TypeScript-level blocker remained. It did not reliably mean that unit tests had run, that runtime behavior was unchanged, or that validation semantics were preserved.

The Failure Taxonomy from the Initial Run

The 5 explicit failures were already interesting because they clustered around one API boundary: SignalFormControl does not support imperative validator or error mutation.

Failure 1: CsagentLoginFormComponent — The template had required="true" on inputs. Angular's RequiredValidator directive called setValidators(), which triggered NG01920.

Failure 2: OrderGuestRegisterFormComponent — Used CustomFormValidators.passwordsMustMatch, a cross-field validator that called setErrors() on another control.

Failures 3 & 4: DeliveryModeDatePickerComponent and DateRangeModalComponent — Both routed controls through a shared date picker component using [formControl]. Internally, Angular's form setup path called setValidators().

Failure 5: VerifyRegisterVerificationTokenFormComponent — A combination of setErrors() in error handlers, form.enable() in tests, and cross-field validators using imperative patterns.

These failures were useful because they revealed a consistent incompatibility pattern: code that reaches into the control and mutates validation or error state imperatively does not map cleanly to Signal Forms.

That alone would already have made for a decent migration story. But the later review surfaced a more important lesson.

What the Review Changed

I ran an adversarial code review against the migration diff, and it found problems that the initial pipeline had missed entirely.

Example 1: Tests never ran. In several worktrees, npm install had not been executed. The @types/jasmine package was missing, so nx test could not run at all. The sub-agents noted this as a warning — and then reported SUCCESS anyway, because the TypeScript compiler showed no errors. This meant that a significant number of "successful" migrations were never actually test-verified.

Example 2: Silently changed email validation semantics. In AsmCreateCustomerFormComponent, the agent replaced Spartacus's CustomFormValidators.emailValidator with Angular's built-in signal email() validator. But these use different regular expressions. The Spartacus validator accepts addresses like email@[123.123.123.123] and rejects email@example — Angular's does the opposite. The migration silently changed which email addresses the form accepts, with no test catching the difference.

Example 3: Validator side effects triggered at wrong time. In AsmBindCartComponent, a custom validator contained a side effect (resetDeeplinkCart()) that cleared UI state. After migration to SignalFormControl, the timing of validator execution changed. The review found that this could reset a deeplink alert immediately after it was set — a regression invisible in unit tests.

These are not mechanical errors. They are semantic changes that require domain knowledge to detect. No import check or template scan would have caught them.

The honest conclusion: automated transformation is not the same as validated correctness.

What I Would Do Differently Today

If I were running this in a real client project, I would use the same core idea — playbook-driven agentic migration — but change the process significantly.

Migrate in waves of five. Instead of pushing 44 targets through one autonomous pipeline, group them into waves of 4–5 components. Mix each wave deliberately: 2 simple components alongside 2–3 with known edge cases like template required attributes or custom validators.

After each wave, the orchestrator writes a summary and stops. The human reviews the results, decides whether to update the playbook, and approves the next wave. This is a hard constraint in the orchestration protocol. Agents that are allowed to cross wave boundaries without human approval will repeat systematic mistakes across dozens of components before anyone notices.

Keep the worktrees alive. Do not discard worktrees after the agent reports success. The worktree is the crime scene. Keep it around so you can inspect the diff, run tests manually, and trace what the agent actually did versus what it claimed.

Lock unit tests before and after. Run the full test suite before the migration as a baseline. Run it again after. If tests cannot run at all — missing dependencies, broken setup — the migration gets status ABORT, not SUCCESS. Green tests confirm syntactic correctness. They say nothing about semantic equivalence. That is where review starts.

Enforce hard constraints outside the prompt. The orchestration protocol limits each sub-agent to three test runs after the migration. I enforced this through the prompt. Some agents ignored it. In a production workflow, I would wrap the agent invocation in a deterministic harness — a script that counts test executions externally and terminates the process after the limit. Prompting is a request. A wrapper script is a mechanism. Any constraint that the agent must not violate belongs outside the agent's control.

Use a second model for adversarial review. A different frontier model reading the migration diff with adversarial intent catches a different class of errors than the model that wrote the code. Tools like codex-plugin-cc or Windsurf's Codemaps can help here — the principle is what matters: structural overview and adversarial challenge from a separate perspective.

In this migration, the adversarial review flagged two real issues the pipeline had missed: a validator side effect that could reset active-cart deeplink state on every template subscription, and an email validator replacement that silently changed which addresses the form accepts. Both were invisible to unit tests. Both would have shipped.

Human review closes the loop. After the adversarial model review, a senior developer reviews the wave. The human decides whether a semantic difference is acceptable, whether a validator change matches business intent, and whether the migration is truly done.

The resulting workflow per wave:

Agent transforms 4–5 components in isolated worktrees
Unit tests gate syntactic correctness
Second model challenges semantic equivalence
Human reviews and decides
Update the playbook with new edge cases
Next wave

The Real Takeaway

At scale, the problem is not transformation. The problem is verification.

The honest result of this experiment: agentic migration works — but only inside a structured process with explicit quality gates. Run it in small waves. Keep the evidence. Let the agent do the mechanical work. Let a second model challenge it. Let a human decide.

Agent transforms. Second model challenges. Human decides.

That is the workflow. Not "fully autonomous migration." Not "human reviews everything manually." A layered process where each step catches what the previous one cannot.

Context engineering > prompt engineering. The hard part was never writing a clever prompt. It was doing the first migrations manually, extracting the right rules, documenting the edge cases, deciding what counts as "done," and designing a process where speed and trust are not in conflict.

The AI did not invent the strategy. A senior developer defined the migration model, the playbook, and the quality gates. The AI scaled the repetitive part. The review caught what scaling missed.

That is where the real leverage is: not asking an agent to "do the migration," but designing a process that makes automation fast, inspectable, and safe.

This migration builds on Manfred Steyer's blog post on SignalFormControl interop. The initial migration run is at github.com/lutzleonhardt/spartacus/pull/1. The refined wave-based orchestration protocol and migration logs are on the signal-forms-migration-v2 branch, including the full orchestration protocol.

DEV Community: Lutz Leonhardt

Frankenstein Meeting Room: Three Apps in One Browser Tab

1. Intro — Why Frankenstein?

2. What the app does

3. Starting point and workflow

4. Native Federation: Shell, Remotes, Bus

5. M1 — Monorepo, shared package, shell skeleton

6. M2 — Host complete: calendar, meeting service, panels

7. M3 & M4 — Whiteboard and Mermaid as remotes

8. Islands instead of components

9. Bus access and events

10. M5 & M6 — Polish and deployment

11. Take-away

Frankenstein Meeting Room: Drei Apps in einem Browser-Tab

1. Einstieg - Warum Frankenstein?

2. Was die App macht

3. Ausgangslage und Workflow

4. Native Federation: Shell, Remotes, Bus

5. M1 — Monorepo, Shared-Package, Shell-Skeleton

6. M2 — Host komplett: Kalender, Meeting-Service, Panels

7. M3 & M4 — Whiteboard und Mermaid als Remotes

8. Inseln statt Komponenten

9. Bus-Zugriff und Events

10. M5 & M6 — Polish und Deployment

11. Take-away

I built the same MVP twice. The autonomous agent wrote 4.6x more tests — none caught two stubbed core methods.

the numbers

the same starting point

what the autonomous build actually produced

why this happens

two patterns I stole anyway

the honest closer

I stopped maintaining my GTD system. That's why it finally works.

The accidental hack that held

The actual product is trust, not voice

The catch, and why this is becoming an app

Building this in the open

Next post

The Frankenstein Meeting Room: How to Stitch Angular, React, and Svelte Into One App

The Frankenstein Reality

The Architectural Principle

Islands, Not Components

One Channel, Four Events

Native Federation as the Vehicle

The Demo

Two Notes from the Spec'ing Process

Part 2: The Build

I Used AI Agents to Migrate 44 Angular Components. The Review Changed My Mind.

The Migration Target: Signal Forms Stage 1

The First Two Manual Migrations

The Three Artifacts

The Orchestrator Architecture

Initial Results

The Failure Taxonomy from the Initial Run

What the Review Changed

What I Would Do Differently Today

The Real Takeaway