Para equipos que construyen con agentes de IA: una app en el navegador para modelar el negocio con historias, reglas que se ejecutan y escenarios que las prueban, todo guardado en git. Cuando el modelo no deja dudas, el código sale exacto, y si no, FDN te lo dice.
En la cabeza, en el código, en un manual o en el chat del agente.
Lo que nadie decidió se decide en un if.
El event storming no se ejecuta ni se revisa.
Negocio, ingeniería y operaciones trabajan juntos, cada quien con su agente preferido.
agenteNada dice quién es el jefe del viaje: cualquiera podría autorizarlo. Te dejé una propuesta.
require estatus = enviado
require actor = jefe del viaje
Aplicar
túTiene sentido. La apruebo.
FDN revisa el modelo en cada cambio y marca lo que no cuadra; tu agente lo lee y propone cambios a través de MCP, el protocolo con el que los agentes de IA usan herramientas. Tú los revisas y decides cuáles se aplican.
Event storming: las historias del negocio como una línea de tiempo de post-its.
DDD: las reglas de cada parte del negocio. Un motor las ejecuta, así que los escenarios Given, When, Then corren sin una línea de código.
La forma exacta de lo que entra y sale, agnóstica a la tecnología.
fdn trace revisa que nada del modelo falte en el código y que nada sobre.fdn verify corre los mismos escenarios contra tu código, por un adaptador ligero que también escribe tu agente. Si tu código dice otra cosa que el modelo, falla.Node 22.18 o posterior.
npm install -g @fdn-dev/cli
En la carpeta que contiene tus repositorios. Se abre en tu navegador, y cada repositorio guarda su modelo en .foundation/, legible y con su diff en cada PR.
fdn --open
Cualquier cliente MCP, en http://127.0.0.1:4848/mcp. Con Claude Code:
claude mcp add --transport http fdn http://127.0.0.1:4848/mcp
Con un servidor del equipo, negocio y operaciones entran desde el navegador, sin instalar nada.
No. Ingeniería instala FDN una vez en un servidor del equipo; negocio y operaciones entran desde el navegador con la cuenta de su empresa, y su agente se conecta al mismo lugar. Lo que aprueban llega a git como commits, e ingeniería lo revisa en un PR.
Ayuda, pero no es requisito. Tu agente modela contigo y FDN revisa el modelo en cada cambio: te dice, en el lenguaje del negocio, qué falta o qué no cuadra.
Sí. El modelo vive aparte, en .foundation/ del mismo repositorio, y no toca tu código. FDN no deduce el modelo del código que ya tienes: se modela a partir de las historias del negocio.
Cualquier cliente MCP: por HTTP en http://127.0.0.1:4848/mcp, o por stdio con fdn mcp si tu cliente no se conecta por HTTP. FDN no trae IA propia ni cobra por usarla.
No. FDN corre en tu máquina o en el servidor de tu equipo, nunca en uno nuestro; el modelo vive en tu git y FDN no envía telemetría. Tu agente solo propone: aplicar un cambio lo decide una persona.
Tu modelo: un archivo JSON legible por contexto dentro de .foundation/, con su historial en git. Es tuyo y se lee sin FDN.
Una especificación en Markdown la lee tu agente una vez, y nadie comprueba que el código la siga. Gherkin ejecuta sus escenarios contra el código, así que el código tiene que existir primero. En FDN los escenarios corren sobre el modelo y pasan o fallan antes de que exista el código; FDN avisa en cada cambio lo que deja de cuadrar, y después fdn verify corre los mismos escenarios contra tu código.
Son buenas formas de darle a tu agente una especificación antes de escribir código. FDN va un paso antes: el modelo del negocio se ejecuta, se revisa en cada cambio y comprueba el código con fdn verify. Se pueden usar juntos.
No. Las herramientas model-driven generaban el código desde el modelo, y había que mantener el generador y vivir con lo que producía. En FDN el código lo escribe tu agente, en tu lenguaje y con tu estilo; el modelo no lo genera, lo comprueba, con fdn trace y fdn verify.