Forem: Lutz Leonhardt

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. GTD 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.

The next thing that breaks in a system like this is not the model. It's the prompt design for consistency. Specifically: how do you write rules that survive long conversations, parallel sessions, and the model's natural urge to be helpful when "helpful" is exactly what you don't want? That's Post #2.

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 a series. The build follows in subsequent posts.

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/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."

What's Next

This post is part 1. The repo will host the spec and the build, milestone by milestone:

M1 — Workspace scaffolded, Angular host with empty federation manifest running on :4200
M2 — Calendar, meeting service with persistence, three-column layout, event-bus log
M3 — React Whiteboard remote — first federation stitching live
M4 — Svelte Mermaid remote — both remotes federated, the money-shot becomes recordable
M5 — Polish, README, optional CRUD niceties

Each milestone produces a usable artifact you can stop at and demo. The next post will follow M1 + M2 — the host shell, why the two-phase bootstrap matters, and what „the host is also a remoteEntry.json" actually means.

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

If your enterprise frontend looks more like a museum than a monolith, this is the pattern that makes that a feature, not a problem.

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.