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.

.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/`.

• 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.
• 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»).

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.