Framein - ni cockpit, ni proxy, ni harness: la capa de estado de trabajo debajo del agente de programación con IA

Últimamente hago la mayor parte de mi programación junto con agentes de terminal. Tengo Claude Code, Codex y Gemini CLI abiertos lado a lado dentro de VS Code; dejo la implementación base en manos de Claude y, cuando necesito una mirada externa para cosas como seguridad o regresiones, le pido a Codex que lo revise. Pero cada vez que cambiaba de modelo tenía que volver a explicar cuál era el objetivo, qué no se podía romper y qué había intentado el modelo anterior antes de fallar. Al final, yo mismo me había convertido en un portapapeles humano entre tres terminales.

Buscando herramientas parecidas, vi que ya existían muchas. Desde cockpits que muestran varios agentes en una sola ventana (como Claude Squad o la línea de Orch term), hasta proxies que permiten llamar otros modelos desde un mismo harness (como opencodex u oh-my-free-models), e incluso orquestadores que reparten el trabajo por roles (como Oh My OpenCode). Pero, curiosamente, había muy pocas que abordaran de frente el problema que yo estaba viviendo: que el trabajo en sí no se interrumpa aunque cambie el modelo. La mayoría iba más por la dirección de “hacer mejor el handoff”.

Framein, en vez de mejorar el handoff, eligió hacer que el handoff deje de ser necesario. No es un IDE nuevo, ni un cockpit, ni un proxy, ni otro harness más. Es una capa local y ligera de estado de trabajo (work-state) que se coloca debajo de los agentes que ya usas. Como los tres agentes leen dentro del repo el mismo contrato de trabajo, el mismo registro de decisiones y los mismos resultados de verificación, la acción de “pasarlo” deja de ser un paso separado. El siguiente modelo no lee los hechos resumidos por mí, sino los hechos tal cual.

El loop se compone de cuatro verbos. Aquí, "lead" se refiere al modelo que en ese momento está a cargo de la implementación real. Es una forma de distinguirlo del modelo encargado de revisar.

• start : fija la solicitud como un contrato de trabajo (objetivo, criterios de aceptación, áreas protegidas y non-goal) antes de que la implementación empiece a desviarse.
• challenge : le pide a otro modelo una objeción de alcance acotado, deja que el lead responda una sola vez y luego yo tomo la decisión. Es el momento en que, cuando un modelo dice con seguridad “ya completé toda la implementación”, otro modelo que leyó el mismo contrato y el mismo diff pregunta “¿qué riesgo falta en este plan?”.
• capsule : prepara los hechos que leerá el siguiente lead (contrato, diff, verificación, ADR y ledger).
• ship : no cierra el trabajo porque el modelo diga “ya terminé”, sino mediante build/test/revisiones de riesgo reales.

También se puede invocar directamente desde la terminal; dentro de Claude o Gemini, mediante comandos slash /fr:*, y en Codex, mediante skills $fr-*. No importa desde cuál se llame: todos leen y escriben sobre el mismo motor local y el mismo estado. La idea es mantener intactos el harness, los paquetes de skills y las personas existentes, y poner debajo únicamente contratos, ledger y gates.

Estos son los puntos a los que puse especial atención en el diseño.

• El registro de decisiones (ADR) es append-only. En lugar de editar o borrar, solo se reemplaza con un nuevo registro. Consideré que un registro de decisiones que se puede corregir silenciosamente pierde valor en el momento en que un segundo modelo decide confiar en él.
• No recolecta credenciales. Tampoco hace relay de tokens, pooling de suscripciones ni scraping de entrada/salida de terminal. La autenticación sigue estando en cada CLI oficial, y solo se las invoca localmente cuando hace falta. (Por eso está en una capa distinta a la de los proxies.)
• Tiene 0 dependencias de runtime. Usa únicamente node:sqlite, que viene integrado en Node 22, y el test runner también integrado. El store en SQLite es caché y la fuente de verdad son snapshots JSON amigables con git, así que dentro de seis meses no se te va a romper la instalación por cambios en las dependencias.

Actualmente está en pre-release v0.0.6. Ya están implementados el core (store, proyección de CLAUDE.md/AGENTS.md/GEMINI.md, contrato de trabajo, gates de verify/risk/ship, wrappers /fr:* y $fr-*, y servidor MCP), y pasa 249 tests. Lo que todavía estoy puliendo es la ruta de code signing en Windows, la distribución de ejecutables firmados y notarizados, la verificación de instalación en máquinas limpias y los flujos de trabajo con múltiples desarrolladores.

Se puede instalar con npm install -g framein (requiere Node 22.5+) y tiene licencia MIT. El nombre viene de un término cinematográfico. Cuando el sujeto desaparece fuera del encuadre se llama frame out, y volver a meterlo en pantalla es frame in. Lo elegí con la idea de traer tres agentes dispersos dentro de un solo frame.

Incluso si ya usan cockpit, proxy o harness, si han sentido que el estado de trabajo se sigue filtrando por debajo, o si ya trabajan alternando entre dos o más agentes de programación, me gustaría recibir feedback sobre si Framein llena ese espacio que faltaba.

Sitio web : https://www.framein.dev/ko
GitHub : https://github.com/framein-dev/framein
Notas del desarrollador (por qué lo hice) : https://www.framein.dev/ko/why