Framein – weder Cockpit noch Proxy noch Harness, sondern die Work-State-Schicht unter AI-Coding-Agenten

In letzter Zeit erledige ich den Großteil meiner Programmierarbeit zusammen mit Terminal-Agenten. In VS Code habe ich Claude Code, Codex und Gemini CLI parallel geöffnet, lasse die grundlegende Implementierung von Claude übernehmen und bitte Codex um Reviews, wenn ein externer Blick nötig ist, etwa bei Sicherheit oder Regressionen. Dabei musste ich bei jedem Modellwechsel immer wieder neu erklären, was das Ziel ist, was auf keinen Fall kaputtgehen darf und woran das vorherige Modell gescheitert ist. Am Ende war ich selbst die menschliche Zwischenablage zwischen drei Terminals.

Als ich nach ähnlichen Tools gesucht habe, stellte sich heraus: Davon gibt es bereits viele. Cockpits, die mehrere Agenten in einem Fenster anzeigen (wie Claude Squad oder Orch term), Proxys, mit denen sich aus einem Harness andere Modelle aufrufen lassen (wie opencodex oder oh-my-free-models), und sogar Orchestratoren, die Rollen aufteilen und Arbeit verteilen (wie Oh My OpenCode). Aber das Problem, das ich tatsächlich hatte – dass die Arbeit selbst nicht abreißt, auch wenn das Modell wechselt –, wird überraschend selten direkt adressiert. Die meisten Lösungen gehen eher in die Richtung, „Handoffs besser zu machen“.

Framein hat sich statt besserer Handoffs dafür entschieden, Handoffs als separaten Schritt überflüssig zu machen. Es ist weder eine neue IDE noch ein Cockpit, ein Proxy oder noch ein weiteres Harness. Es ist eine dünne lokale Work-State-Schicht, die unter den Agenten liegt, die man ohnehin schon benutzt. Drei Agenten lesen im selben Repo denselben Arbeitsvertrag, dieselbe Entscheidungsdokumentation und dieselben Verifikationsergebnisse, sodass das „Übergeben“ selbst kein eigener Schritt mehr ist. Das nächste Modell liest nicht von mir zusammengefasste Fakten, sondern die Fakten selbst.

Der Loop besteht aus vier Verben. Mit „Lead“ ist hier das Modell gemeint, das gerade tatsächlich die Implementierung übernimmt. Der Begriff dient zur Abgrenzung vom Modell, das das Review übernimmt.

• start : Bevor die Implementierung ins Wanken gerät, wird die Anfrage als Arbeitsvertrag fixiert (Ziele, Abnahmekriterien, geschützte Bereiche, Non-Goals).
• challenge : Ein anderes Modell wird um einen eng abgegrenzten Einwand gebeten, der Lead darf genau einmal darauf antworten, danach entscheide ich. Wenn ein Modell selbstbewusst sagt: „Die Implementierung ist vollständig abgeschlossen“, dann ist das der Moment, in dem ein anderes Modell, das denselben Vertrag und denselben Diff gelesen hat, fragt: „Welches Risiko fehlt in diesem Plan?“
• capsule : Bereitet die Fakten vor, die der nächste Lead lesen soll (Vertrag, Diff, Verifikation, ADR, Ledger).
• ship : Die Arbeit endet nicht damit, dass ein Modell „fertig“ sagt, sondern durch echte Build-/Test-/Risk-Gates.

Es lässt sich direkt im Terminal aufrufen, in Claude/Gemini über /fr:*-Slash-Commands und in Codex über $fr-*-Skills. Egal, von wo aus es aufgerufen wird: Gelesen und geschrieben wird immer auf dieselbe lokale Engine und denselben Zustand. Bestehende Harnesses, Skill-Packs und Personas bleiben unverändert; darunter wird lediglich eine Schicht aus Vertrag, Ledger und Gates gelegt.

Auf diese Punkte wurde im Design besonders geachtet.

• Entscheidungsdokumentation (ADR) ist append-only. Sie wird nicht bearbeitet oder gelöscht, sondern nur durch neue Einträge ersetzt. Ich halte Entscheidungsaufzeichnungen, die stillschweigend überschrieben werden können, in dem Moment für wertlos, in dem ein zweites Modell ihnen vertraut.
• Es werden keine Zugangsdaten gesammelt. Es gibt weder Token-Weiterleitung noch Subscription-Pooling oder Scraping von Terminal-Ein- und -Ausgaben. Die Authentifizierung bleibt bei den offiziellen CLI-Tools und wird bei Bedarf nur lokal aufgerufen. (Deshalb ist es eine andere Schicht als Proxy-Lösungen.)
• Es gibt 0 Runtime-Abhängigkeiten. Verwendet werden nur node:sqlite aus Node 22 und der eingebaute Test-Runner. Der SQLite-Store ist ein Cache, die maßgebliche Quelle sind git-freundliche JSON-Snapshots – dadurch bricht die Installation nicht in einem halben Jahr wegen geänderter Abhängigkeiten.

Aktuell ist es ein Pre-Release v0.0.6. Der Core ist bereits implementiert – darunter Store, Projektion von CLAUDE.md/AGENTS.md/GEMINI.md, Arbeitsvertrag, verify/risk/ship-Gates, /fr:*- und $fr-*-Wrapper sowie ein MCP-Server – und 249 Tests laufen erfolgreich durch. Noch in Arbeit sind der Pfad für Windows-Code-Signing, die Verteilung signierter und notariell beglaubigter Executables, die Installationsvalidierung auf sauberen Geräten und Workflows für mehrere Entwickler.

Die Installation erfolgt mit npm install -g framein (Node 22.5+ erforderlich), lizenziert unter MIT. Der Name stammt aus der Filmsprache. Wenn ein Motiv aus dem Bildausschnitt verschwindet, ist das frame out; es wieder ins Bild zu holen, ist frame in. Der Name soll ausdrücken, dass drei verstreute Agenten in einen gemeinsamen Frame geholt werden.

Auch wenn Sie bereits Cockpits, Proxys oder Harnesses einsetzen: Wenn Sie das Gefühl haben, dass darunter ständig Arbeitszustand verloren geht – oder wenn Sie zwischen zwei oder mehr Coding-Agenten wechseln –, würde ich gern Feedback dazu bekommen, ob Framein genau diese Lücke füllt.

Website : https://www.framein.dev/ko
GitHub : https://github.com/framein-dev/framein
Entwicklernotiz (warum es gebaut wurde) : https://www.framein.dev/ko/why