Sesión cero

Después de init, el brain está vacío a propósito. La puerta lo dice y apunta a la skill de multivac; la skill hace la única pregunta que importa:

¿Este ecosistema ya existe como código, o partimos desde cero?

Dos flujos, un solo destino: una ley anclada, puertas en cada repo y cada decisión posterior entrando como un change.

Ecosistema existente: sync → seed → preguntas → entrevista → ley

El seeder lee y pregunta; un humano responde; el agente redacta; el humano promulga. Nunca te saltes al humano.

0. Sync

$ mvac repos sync

Declara repos: antes del primer commit del brain y luego haz sync. Clona cada repo declarado con una url que no esté en disco e instala el SDD declarado en el brain, donde se escriben las specs de cada cambio, de modo que nada se redacte sobre un repo que nadie puede leer. mvac repos check nombra lo que todavía falta.

1. Seed

$ mvac seed
seed: wrote .multivac/seed-report.md — 1 repo(s) inventoried
seed: next — take the open questions to a maintainer, then draft proposed claims (see the multivac skill)

seed es un inventario determinista de dónde vive la arquitectura del ecosistema, agrupado por categoría para cada repo declarado: compuertas de política (semgrep, pre-commit, eslint/biome/ruff, CODEOWNERS — la ley del proyecto ya escrita en forma de máquina), grafo de workspace / build (pnpm-workspace, turbo, go.work, .sln/.csproj), manifiestos de despliegue (kubernetes, helm, kustomize, skaffold), decisiones / intención (ADRs, AGENTS.md, CONTRIBUTING — antecedentes, léelos primero), además de modelos/esquema, migraciones, configuración de runtime, rutas, protobuf, graphql, sql, especificaciones de API, docker, terraform, ci, manifiestos de paquetes y ejemplos de env. Los fixtures de prueba, examples/ y los árboles vendorizados se excluyen; cada categoría lista como máximo 25 archivos más un conteo. Sin LLM, sin red. El reporte, abreviado; cierra con las preguntas abiertas y un puntero ## next:

# seed report

Deterministic boundary inventory, generated by `multivac seed`.
Nothing here is law: the agent drafts `proposed` rows from it; a human enacts.

## api (../acme-api)

### policy gates (1)

- .pre-commit-config.yaml

### migrations (1)

- sql/migrations/001_accounts.sql

El brain también recibe una sección ### setup, para el documento de proyecto del SDD, que es del brain: se reporta una sola vez — en una sección propia cuando el brain no contiene código, en la entrada del brain cuando sí:

## brain (the brain itself, no code)

### setup

- project document .specify/memory/constitution.md: template (byte-identical to the template recorded in .specify/memory/.constitution-template.json) → run /speckit.constitution in your agent …

Un repo declarado que falta en local aparece bajo ## skipped, con una indicación de ejecutar mvac repos sync para clonarlo, y la línea de resumen lo cuenta como N skipped.

2. Lee por categoría, no por repo

Todas las compuertas de política de todos los repos, luego todos los manifiestos de despliegue, luego todos los modelos. Una lectura por categoría deja ver el contrato entre repos — la API que llama el cliente web, la tabla que comparten dos servicios. Una lectura repo por repo oculta justamente eso.

3. Lleva las preguntas abiertas a un humano

El reporte trae las tres preguntas que ningún lector externo puede responder, instanciadas con lo que encontró seed:

1. ¿Deuda o intención? — el código viola una regla escrita; ¿la violación es deuda o la regla está muerta?
2. ¿Ley o gusto? — ¿qué reglas en prosa se hacen cumplir y cuáles son preferencias?
3. ¿Qué autoridad gana? — semgrep vs AGENTS.md, helm vs kustomize: cuando las fuentes discrepan, ¿quién tiene la razón?

Cada una es una respuesta de cinco segundos para un maintainer e imposible de resolver sin él. Estas preguntas son la entrada de la entrevista: ejecuta el protocolo de entrevista con ellas antes de redactar. Una respuesta adivinada se vuelve ley equivocada, y ninguna métrica lo mostrará.

4. Redacta el mapa y la ley propuesta

Páginas de mapa: qué existe, qué llama a qué, qué contrato expone cada superficie. Breves y factuales — sin adjetivos, sin historia que no tengas. El mapa es la única capa que escala con el ecosistema.

Afirmaciones (claims) propuestas: por cada frontera que parezca deliberada, una fila de afirmación más un ancla tentativa. Un REVOKE UPDATE en una migración sugiere “nadie escribe en accounts” — sugiere. No sabes por qué está ahí; el humano sí.

| INV-07 | Only `billing_role` may write `accounts.balance`. | proposed | proposed | 2026-08-13 | seed |
<!-- @anchor INV-07 api:sql/migrations/*.sql /revoke[[:space:]]+update[[:space:]]+on[[:space:]]+accounts/i -->

Ancla al sitio del contrato que acabas de inventariar — es lo que leíste y a la vez lo que menos se mueve. Gramática completa: Escribir anclas.

5. Registra todo como proposed

Los tramos de las filas proposed nunca bloquean verify; solo una línea de ancla que no se puede interpretar, o que nombra una clave de repo que nadie declaró, sigue haciendo fallar la ejecución. El brain se mantiene honesto sobre lo que está validado y lo que no. El agente nunca marca una fila como active por sí mismo.

6. Valida en lotes por radio de impacto

Ordena las filas propuestas según lo que más se rompe si la afirmación es falsa: primero las superficies de dinero y pérdida de datos, luego las promesas publicadas externamente, luego los contratos internos, luego las convenciones. Lotes pequeños, tres resultados por fila:

• aceptar — el humano promulga: estado → active, autoridad fijada por él.
• corregir — el enunciado o el ancla estaban mal; arregla y vuelve a presentar.
• descartar — elimina la fila; un accidente no es ley.

Lo que la sesión no alcance a cubrir queda como proposed: visible, y sus tramos nunca bloquean. Nunca aceptes en bloque para terminar más rápido — una mentira promulgada es peor que una verdad sin validar.

7. Escribe el documento de proyecto del brain

Después del primer lote, escribe el documento de proyecto del brain si su SDD declara uno, como la constitution de spec-kit. El ecosistema tiene uno: el SDD vive en el brain, y a ningún repo de código se le pide el suyo. Sale de las respuestas del humano y cita las filas que reformula. Donde él y una fila activa discrepan, gana la fila. change plan rechaza mientras falte, esté vacío o siga siendo la plantilla. Cuando se enmienda más adelante, el reporte que /speckit.constitution escribe para revisión se elimina antes del commit; git guarda el registro.

8. Proyecta las puertas

$ mvac doors
brain: door + hooks updated
brain: .multivac/flow.md — what your declarations oblige, sorted; generated, binds nothing
api: door + hooks updated

Escribe la puerta del brain, el .multivac/flow.md generado y la puerta de cada repo consumidor (solo el bloque gestionado — el contenido escrito a mano a su alrededor no se toca), e instala los hooks de git en cada repo declarado que esté en disco — salvo uno de solo lectura, declarado managed: false o un clon superficial, que no recibe nada. Desde aquí ejecuta mvac verify para la línea base; cada decisión siguiente es un mvac change new.

Desde cero: entrevista → primer cambio

No hay código que leer. La ley vive en la cabeza de la persona y la entrevista la saca a la luz. La entrevista es un protocolo que la skill lleva y que tu propio agente ejecuta — multivac nunca llama a un modelo por sí mismo.

Obtén la información en este orden:

1. El ciclo del producto. Qué ocurre de punta a punta en el camino feliz — un párrafo en sus palabras, leído de vuelta en una frase. Mientras el ciclo no esté enunciado, no preguntes nada más.
2. Las fronteras. Servicios, almacenes, APIs externas, clientes; qué habla con qué. Se convierte en la primera página de mapa y, más adelante, en el registro repos:.
3. Los innegociables, y por qué. “¿Qué nunca debe pasar, incluso si el código lo permitiera?” Quién lo decidió; qué se rompe si se viola. Una regla sin un porqué es una convención, no ley. Insiste una vez — “¿es una preferencia o una promesa?” — y luego acepta la respuesta.
4. Lo que se publica o se promete externamente. Páginas de precios, docs de API, contratos, SLAs. Estos pesan más que todo lo interno; márcalos con la máxima autoridad del proyecto.

Una pregunta a la vez; lo concreto sobre lo abstracto (“un usuario paga dos veces — ¿qué pasa?”). Lee de vuelta cada regla candidata con tus palabras y consigue un sí a la reformulación. Captura los buenos porqués textualmente.

Detente en la primera rebanada. Ciclo, lista de fronteras, innegociables con sus porqués, una rebanada delgada de punta a punta — y detente. Todo lo demás se decide dentro de cambios futuros, cuando la realidad responda. Una spec especulativa es un brain que miente desde el primer día, justo lo que verify existe para evitar.

El resultado queda así: el ciclo y la lista de fronteras en la puerta del brain, FUERA del bloque gestionado — doors regenera lo que hay entre los marcadores, completo, desde .multivac/config.yml en cada ejecución, así que todo lo escrito dentro de ellos desaparece en el siguiente multivac doors; una página de mapa; cada innegociable como una fila proposed (en su mayoría sin anclar — todavía no hay código; es legal y se cuenta). Luego:

mvac change new "first slice"

Declara los repos — puede que no existan; apply en greenfield los crea con primer commit y puerta —, el orden de aterrizaje y las afirmaciones que la rebanada vuelve verdaderas. El brain precede al código: la primera sesión del agente dentro de cualquier repo nuevo ya conoce la ley. Desde aquí: Ejecutar cambios.