.projectstore / método / 3
Muchas sesiones. Muchas personas. Un vault.
El contexto es del equipo, no del chat de un desarrollador. Los ADR y las specs pasan por pull requests, como el código. Lo que se revisa es el razonamiento.
Cuatro formas de trabajar
Varias sesiones, un vault
Dos agentes o dos personas en un mismo vault a la vez es lo normal. Cada sesión sabe de las demás, y unas pocas reglas sencillas evitan que se pisen.
- Nada se sobrescribe en silencio. Antes de guardar un archivo nuevo, ProjectStore comprueba que aún no existe. Dos sesiones sobre el mismo tema se topan con un conflicto, no con dos copias.
- Cada línea de estado muestra su propio trabajo. 2–6 sesiones en paralelo ven, cada una, exactamente su propia épica e historia.
- Los nombres de sesión se proponen, no se imponen. Cuando una sesión se centra en un único trabajo, se le propone un nombre. Pocas veces: como mucho dos por sesión, 12 propuestas en nueve sesiones registradas.
dev A trabaja en CHECKOUT desde las 13:35. abres una segunda sesión: ⚠ Multi-session warning — 1 other projectstore session active. Run /projectstore:search <topic> before creating new artifacts. más tarde, cuando tu trabajo se centra en «Las tarjetas guardadas se listan al pagar»: projectstore: this session looks like "checkout-las-tarjetas-guardadas-se-listan-al" → /rename checkout-las-tarjetas-guardadas-se-listan-al
Cada uno ve más que su propia parte.
El desarrollador, el tech lead y QA trabajan con las mismas decisiones y los mismos criterios. Quien no usa agente solo necesita GitHub o un editor de Markdown: son simples archivos.
El contexto está disponible para todo el equipo, no solo para el dueño del chat.
Contratos compartidos. Áreas de trabajo separadas.
En un mismo proyecto, los equipos de API, Web y Plataforma llevan sus propias épicas sobre la base de ADR y specs compartidos. Un cambio en un contrato compartido se discute en la revisión con los equipos que lo usan. ProjectStore muestra qué historias dependen de él.
Quién es dueño de qué artefactos y quién da el visto bueno a los contratos lo decide el equipo.
Distintos ejecutores. Bases compartidas.
El planificador lee las decisiones y el mapa de código. El implementador lee la historia y la spec. El revisor lee el diff y los criterios. Cada uno recibe el contexto que necesita, no todo el historial de la sesión de otro. Las sesiones sobre un mismo vault se avisan entre sí.
Lanzar agentes y pasar el trabajo de uno a otro es tarea de tu harness u orquestador.
Un ejemplo de organización del trabajo, no de orquestación en vivo
Cómo se ve en git
Configuración de equipo, paso a paso
- 01
Un repo aparte para el vault
Un repositorio de documentos de proyecto por proyecto, no por persona. Vive junto al repositorio de código.
- 02
Copias propias, un vault
Cada persona clona el repositorio del vault, ejecuta
npx projectstore setupen su propia copia del código e indica ese clon como vault. El vínculo se queda en esa máquina y no se incluye en ningún commit. - 03
Una rama y un pull request
Una persona revisa cada decisión antes de que se acepte. El critic la comprueba antes del pull request; tu equipo la revisa dentro de él.
- 04
Doctor en CI
npx projectstore doctor --jsonse ejecuta en CI sin agente y sin tokens. Si encuentra problemas, hace fallar el paso.reconcile --writetambién puede reconstruir allí el tablero.
Claude Code y Codex pueden trabajar en un mismo proyecto a la vez: comparten el vínculo, y cada uno guarda sus propios modelos de agente y su estado de sesión.