Después de escribir o cambiar un ADR, una spec, una épica, una historia o un diseño
Busca puntos débiles, contrasta cada afirmación con la fuente y se pregunta cómo podría fallar el plan. Sin halagos.
opus · max.projectstore / método / 1
Un bucle con una revisión independiente dentro.
Los agentes escriben código rápido, y vuelven a decidir lo ya resuelto igual de rápido: cada sesión nueva llega vacía. La solución no es un agente más listo. Es reunir contexto → actuar → verificar, aplicado al proyecto y no solo al código.
El bucle
Ocho pasos. Dos de ellos son revisiones de un agente que no escribió el borrador.
- 01Dices lo que quieres. El agente abre un artefacto antes de abrir un editor.
- 02Un ADR cuando hay algo que decidir, una épica e historias para el trabajo, una spec cuando el «cómo» no es obvio. Con vista previa, y se escribe con tu sí.
- 03Un critic con contexto limpio y sin nada en juego en el borrador lo ataca. Cuenta con un «revisar».
- 04Apruebas las correcciones. El artefacto se marca como revisado y pasa al backlog.
- 05Un agente toma una historia. El planner lee cómo llegaron al código las épicas anteriores y dice dónde encaja este cambio.
- 06Código y tests, siguiendo el plan de la historia.
- 07Un reviewer con contexto limpio contrasta el diff con cada criterio de aceptación y pide evidencia.
- 08Hecho, con evidencia bajo cada criterio. El tablero, el mapa de enlaces y el mapa de código se regeneran.
Los agentes
6 agentes. Todos menos uno solo pueden leer.
Los asesores comprueban, planifican y ponen orden, sin cambiar nada. Un único clerk guarda solo lo que aprobaste, después de tu Sí.
Antes de empezar a trabajar en una historia (story plan)
Mira dónde viven en el código las épicas anteriores. Dice dónde va el cambio, qué reutilizar, con qué tener cuidado y en qué orden trabajar.
opus · maxDespués del código, antes del commit o de story close
Pide evidencia para cada criterio de aceptación, incluidos los de la spec. Después comprueba la corrección, las regresiones y los tests.
opus · maxDe vez en cuando, antes de los releases, cuando el vault crece rápido
Encuentra lo que ninguna regla detecta: notas de investigación que contradicen un ADR aceptado, duplicados, enlaces que faltan, documentos listos para archivar.
opus · maxUna vez, tras vincular una base de código existente
Encuentra decisiones que nadie puso por escrito, en el código, los archivos de configuración y el historial de git. Propone ADR para ellas, con evidencia.
opus · maxSolo dentro del flujo de un comando, solo después de tu Sí
Guarda exactamente lo que aprobaste, nada más. Después reconstruye el tablero y ejecuta las comprobaciones. No escribe nada propio ni pregunta nada.
sonnet · maxLos modelos por defecto son los de Claude Code. En Codex, cada rol es un skill homónimo que pide a Codex que inicie el rol, como $projectstore-critic para el critic; usa el modelo de la sesión salvo que configures otro.
Las salvaguardas
Lo sostienen los mecanismos, no la disciplina.
Sin historia, un aviso
A un agente que empieza a editar código sin una historia abierta se le recuerda que abra una. Un cambio del tamaño de una funcionalidad empieza en el vault.
Lo que está sin revisar sigue marcado
Un artefacto que necesita revisión lleva review_status: pending hasta que se aplica una pasada del critic. «Aún sin revisar» es un estado que las herramientas pueden leer, no algo que alguien deba recordar.
Un doctor sin IA
doctor comprueba de forma determinista la coherencia mecánica del vault. En CI se ejecuta sin agente y sin tokens.
Dónde mirar, generado
graph.md guarda los enlaces de cada artefacto en ambos sentidos; code-map.md dice dónde vive el código de cada épica. Antes de una decisión de arquitectura, al agente se le indica primero el índice de ADR.
Tras /compact, el vault vuelve
En Claude Code, tras un /compact que ejecutes, la sesión vuelve a empezar con la orientación del vault y con los archivos del vault que la conversación había tocado.
Se avisa a la segunda sesión
Una sesión que empieza mientras otra trabaja sobre el mismo vault se abre con un aviso de varias sesiones: busca antes de crear nada nuevo.
Hecho significa demostrado
Una historia se cierra con evidencia bajo cada criterio.
--- type: story epic: "CHECKOUT" title: "Las tarjetas guardadas se listan al pagar" status: done code_refs: ["src/billing/cards/", "tests/cards.test.ts"] closed_at: "2026-07-14T16:02:11Z" --- ## Criterios de aceptación - [x] Las tarjetas guardadas salen primero — evidencia: tests/cards.test.ts:21 - [x] Una tarjeta rechazada muestra el motivo del banco — evidencia: tests/cards.test.ts:58 - [x] Ningún número de tarjeta llega a los logs — evidencia: tests/cards.test.ts:73
El planner dijo dónde encaja el cambio antes del código, y el plan quedó escrito en la historia con tu sí; el reviewer contrastó después el diff con cada criterio. Cada línea de prueba es un test, un comando que se ejecutó o una línea de código.
Cualquier agente puede leer este registro, con el plugin o sin él: a través de la CLI, que responde con JSON y no gasta tokens, o a través de las 8 herramientas de solo lectura del servidor MCP.
- orientation
- search
- status
- get_artifact
- lineage
- neighbors
- code_refs
- doctor
La letra pequeña
La letra pequeña
- Ejecutar el bucle cuesta tokens: los borradores, el critic y el reviewer usan el modelo que ya pagas. El README lo mide.
- El critic y el reviewer son agentes separados con contexto limpio en Claude Code. En Codex los roles son skills.
- ProjectStore es contexto de proyecto compartido y una forma de trabajar. No es un orquestador de agentes: lanzar agentes es tarea de tu harness.