Framein - la couche d’état de travail sous les agents de code IA, ni cockpit, ni proxy, ni harness

Ces derniers temps, je fais l’essentiel de mon coding avec des agents en terminal. J’ouvre côte à côte Claude Code, Codex et Gemini CLI dans VS Code, je confie l’implémentation de base à Claude, puis je demande à Codex de relire quand j’ai besoin d’un regard extérieur, par exemple sur la sécurité ou les régressions. Le problème, c’est qu’à chaque changement de modèle, je devais réexpliquer quel était l’objectif, ce qu’il ne fallait pas casser, et ce que le modèle précédent avait tenté avant d’échouer. Au final, j’étais devenu le presse-papiers humain entre trois terminaux.

En cherchant des outils similaires, j’en ai trouvé beaucoup. Des cockpits qui affichent plusieurs agents dans une seule fenêtre (du type Claude Squad ou Orch term), des proxys qui permettent d’appeler d’autres modèles depuis un même harness (du type opencodex ou oh-my-free-models), et même des orchestrateurs qui répartissent le travail par rôles (du type Oh My OpenCode). Mais le problème que je rencontrais vraiment — faire en sorte que le travail lui-même ne soit pas interrompu quand on change de modèle — était étonnamment peu traité de front. La plupart des outils cherchent surtout à « mieux gérer le handoff ».

Plutôt que d’améliorer le handoff, Framein a choisi de faire en sorte qu’il ne soit tout simplement plus nécessaire. Ce n’est ni un nouvel IDE, ni un cockpit, ni un proxy, ni encore un autre harness. C’est une fine couche locale d’état de travail (work-state) placée sous les agents que vous utilisez déjà. Comme trois agents lisent dans le repo le même contrat de travail, le même historique de décisions et les mêmes résultats de vérification, l’action même de « passer le relais » cesse d’être une étape distincte. Le modèle suivant ne lit pas les faits que j’ai résumés, il lit directement les faits eux-mêmes.

La boucle tient en quatre verbes. Ici, « lead » désigne le modèle qui prend effectivement en charge l’implémentation à l’instant T. Le terme sert à le distinguer du modèle chargé de la review.

• start : avant que l’implémentation ne dérive, on fige la demande sous forme de contrat de travail (objectif, conditions d’acceptation, zones protégées, non-goal).
• challenge : on demande à un autre modèle une objection ciblée sur un périmètre restreint, le lead répond une seule fois, puis je tranche. Quand un modèle affirme avec assurance « j’ai entièrement terminé l’implémentation », c’est le moment où un autre modèle, ayant lu le même contrat et le même diff, vient demander « quel risque manque dans ce plan ? ».
• capsule : on prépare les faits que le lead suivant devra lire (contrat, diff, vérifications, ADR, ledger).
• ship : on ne clôt pas le travail parce qu’un modèle dit « c’est fini », mais parce qu’il passe réellement les gates de build, de test et de risque.

On peut l’appeler directement depuis le terminal, via des commandes slash /fr:* dans Claude/Gemini, ou via des skills $fr-* dans Codex. Quel que soit le point d’entrée, tout lit et écrit dans le même moteur local et le même état. L’idée est de conserver les harness, skill packs et personas existants, et d’ajouter en dessous uniquement les contrats, le ledger et les gates.

Voici les points auxquels j’ai particulièrement fait attention dans la conception.

• Les historiques de décisions (ADR) sont en append-only. On ne modifie ni ne supprime ; on remplace uniquement par un nouvel enregistrement. À mes yeux, un historique de décisions qu’on peut discrètement réécrire perd toute valeur dès l’instant où un deuxième modèle s’y fie.
• Le système ne collecte pas d’identifiants. Il ne relaie pas de tokens, ne fait pas de pooling d’abonnements et ne scrape pas les entrées/sorties du terminal. L’authentification reste gérée telle quelle par chaque CLI officiel, et le système se contente de les appeler en local quand nécessaire. (C’est pour cela qu’il se situe à une autre couche que les proxys.)
• Il n’y a aucune dépendance runtime. Il n’utilise que node:sqlite intégré à Node 22 et le test runner intégré. Le store SQLite sert de cache et la source de vérité est un snapshot JSON compatible avec git ; il n’y aura donc pas d’installation cassée dans six mois à cause d’un changement de dépendances.

Le projet est actuellement en pre-release v0.0.6, et le cœur est déjà implémenté : store, projection de CLAUDE.md/AGENTS.md/GEMINI.md, contrats de travail, gates verify/risk/ship, wrappers /fr:*·$fr-*, ainsi que serveur MCP. Il passe actuellement 249 tests. Les points encore en cours de finition sont le parcours de signature de code Windows, la distribution d’exécutables signés et notariés, la validation de l’installation sur des machines propres, et les workflows multi-développeurs.

L’installation se fait avec npm install -g framein (Node 22.5+ requis), sous licence MIT. Le nom vient d’un terme de cinéma. Quand le sujet sort du champ, c’est un frame-out ; le faire revenir dans l’image, c’est un frame-in. Le nom exprime l’idée de faire entrer trois agents dispersés dans un seul cadre.

Même si vous utilisez déjà un cockpit, un proxy ou un harness, si vous avez l’impression que l’état de travail fuit sans cesse en dessous, ou si vous travaillez en passant d’au moins deux agents de code à l’autre, j’aimerais beaucoup avoir votre avis pour savoir si Framein comble ce manque.

Site web : https://www.framein.dev/ko
GitHub : https://github.com/framein-dev/framein
Note du développeur (pourquoi l’avoir créé) : https://www.framein.dev/ko/why