Equipo por repo y por pedido

Quién hace cada rol se decide en tres niveles. Gana el más específico:

mensaje > .ghosty/factory.md del repo > equipo del espacio

Equipo del espacio

En /factory → «Equipo del espacio» (sólo el dueño): qué agente de Studio es @plan, @build y @check por defecto, y el @eval opcional. Es lo que usan todos los repos que no dicen otra cosa.

Desde el CLI: ghosty agents teams on <id> <equipo> --factory plan,build,check le pasa esos roles a un agente (cada rol conserva su nombre y avatar). ghosty agents teams ls <id> enseña qué roles lleva en cada equipo.

Si nadie pide modelo, @plan y @check corren en Opus 5.5 cuando su agente es de Claude; @build usa el modelo de su agente. Con otro motor, cada rol usa el modelo de su agente.

.ghosty/factory.md en el repo

Un archivo en el repo con frontmatter por rol y, debajo, las convenciones que deben saber los tres roles:

---plan: { agent: Planeador }build: { agent: Constructor, model: opus }check: { agent: Revisor, model: flash }---Convenciones de este repo que deben saber @plan, @build y @check:- Las pruebas se corren con `pnpm test` y usan Vitest.- No se tocan las migraciones ya aplicadas en `prisma/migrations/`.
## @checkUn cambio a `.github/workflows/` o a `prisma/` sin prueba es hallazgo.

• agent: nombre o id de un agente de Studio de tu espacio.
• model: alias (opus, sonnet, fable, pro, flash, sol, terra, luna) o id completo. Tiene que ser del motor de ese agente: cambiar de motor es cambiar de agente.
• Un rol que no aparece usa el del espacio. El cuerpo viaja en cada turno de la fábrica y le gana a lo genérico.
• Una sección ## @plan, ## @build o ## @check va sólo a ese rol: ahí van, por ejemplo, las reglas de revisión de este repo. Termina en el siguiente ## .
• Se lee con caché de 5 minutos; en /factory, «Equipo en este repo» → ↻ la refresca y dice de dónde sale cada rol («del repo» o «del espacio»).

Entorno de pruebas: setup:

Si las pruebas del repo piden base de datos, Redis o variables, decláralo en el mismo frontmatter. @build y @check reciben la llamada exacta que deja su caja de trabajo lista antes de cada corrida:

---build: { agent: Constructor }setup:  services: [postgres, redis]  db: fruteria  script: .ghosty/setup.sh  env:    JWT_SECRET: test-actions-jwt-secret---

• services: postgres y redis (vienen instalados y apagados en la caja dev). Otros se ignoran.
• db: nombre de la base y de su usuario (la contraseña es el mismo nombre). Se borra y recrea en cada corrida, así que la suite siempre arranca con la base vacía. La conexión llega como DATABASE_URL; Redis como REDIS_URL.
• env: variables de prueba, las mismas que usa tu CI. Nunca secretos reales: los del repo siguen en la bóveda.
• script: se corre desde la raíz del repo con ese env cargado (migraciones, semillas).
• Si el repo no lo trae y el pedido toca pruebas con base de datos, @plan lo propone a partir de los services: de .github/workflows/.

Caja por pedido

Cada pedido tiene su propia computadora (4 GB) desde que firmas el plan hasta que se mezcla o se cancela: ahí construye @build, ahí prueba @check (en un clon limpio del PR) y ahí sale la preview. Si nadie la usa, se duerme; al cerrar el pedido se borra. Tu plan de fábrica tiene lugares de ejecución (F1: 2, F2: 4, F3: 6) que comparten los pedidos y las previews de PRs sin pedido. Un pedido nuevo desplaza a una preview suelta; una preview suelta nueva reemplaza a la más vieja; si todos los lugares son pedidos en curso, el pedido o la preview esperan («En espera de lugar») y arrancan solos en cuanto se libera uno.

En el mensaje

@build con opus@plan en agenda@plan en blissito/agenda con sonnet

• «con <modelo>» cambia el modelo de ese rol en ese hilo: los relevos siguientes del mismo pedido lo heredan.
• «en <repo>» elige el repo cuando el room tiene varios.
• Un modelo de otro motor o un agente que no existe no se corre: el hilo dice por qué.

El pie de cada respuesta dice el modelo que corrió ese turno, no sólo el configurado.