# Software Factory — PRs que se revisan en dos minutos

> Tres agentes (@plan, @build, @check) trabajan tu repo desde el chat de Teams; tú firmas el plan y el PR. Cómo se instala, cómo se pide y qué trae cada PR.

URL: https://www.ghosty.studio/docs/fabrica

La **Software Factory** es un equipo de tres agentes que trabaja tu repositorio de GitHub desde un room de [Ghosty Teams](/docs/canales/teams). Tú escribes lo que necesitas como se lo dirías a una persona y firmas dos veces: el **plan** y el **PR**. Lo demás lo hacen ellos.

Escribir código ya es barato; revisarlo no. Por eso la fábrica no se mide por cuántos PRs abre, sino por **cuántos apruebas a la primera**: cada PR llega con su riesgo, qué leer primero y cómo se ve.

## Los roles

| Rol | Qué hace | Qué no hace |
|---|---|---|
| **@plan** | Lee el repo y escribe el plan: historia con criterios de aceptación, brief técnico, riesgos y lo que no se hará. | No edita, no crea ramas. |
| **@build** | Construye el plan firmado: rama nueva, código, pruebas, PR en borrador. | No improvisa otro diseño. |
| **@check** | Revisa el PR contra el plan con **otro modelo**: escribe sus propias pruebas de aceptación, prueba la preview y mira que el código siga siendo fácil de cambiar. | Nunca edita ni empuja: si algo falta, se lo regresa a `@build` (hasta 3 vueltas). |
| **@eval** | *Opcional.* Juez de los [evals](/docs/fabrica/evals). | No participa en los pedidos. |

Cada rol es un **agente de Studio** que eliges tú (motor, modelo y llaves se cambian en `/app/agents`). El mismo agente puede ser `@ghosty` en otro room y `@build` aquí: el rol le llega por turno. Un `@check` de otro motor que `@build` revisa mejor, porque no comparte sus puntos ciegos.

## Instalar

1. **Teams → Ajustes → Apps → Software Factory** (sólo el dueño del espacio).
2. Elige el repo y qué agente de Studio hace cada rol. Conecta tu GitHub para firmar.
3. Se crean el room de la fábrica y su tablero de Tasks. **Todo room con repos es una fábrica**: puedes ligar más repos a otros rooms.
4. En `/factory`, **«Listo para agentes»** califica el repo y **«Preparar repo»** abre un solo PR con lo que falta: CI, `AGENTS.md`, `CODEOWNERS` y Dependabot. Con GitHub Pro o Team (o repo público), **«Proteger main»** activa la regla de que nada entra sin aprobación.

## Pedir un cambio

```text
@plan agrega exportar citas a CSV desde la agenda
```

1. `@plan` publica la **tarjeta del plan**. Fírmala con el botón, con «✅» en el hilo, o pide ajustes con «cambios: …».
2. Al firmar, `@build` construye con **tu** GitHub y abre el PR en borrador.
3. `@check` lo revisa. Si pasa, la plataforma saca el PR de borrador y publica la **tarjeta del veredicto**.
4. Tú revisas y haces merge (desde la tarjeta o en GitHub). El pedido se cierra solo al mezclarse.

Otras entradas: asignar una tarea a `@plan` en Tasks, **«¿Qué quieres lograr?»** en `/factory` (lo parte en un sprint de 3 a 8 tickets), «Sugerir pedidos» y revisiones programadas en «Automático».

## La tarjeta del veredicto

Lo que necesitas para revisar en dos minutos, sin reconstruir el cambio:

- **Riesgo.** La plataforma lo marca por lo que toca el PR, no por la palabra del agente: autenticación, migraciones, dependencias, API pública, `.github/` o más de 400 líneas → **alto**. `@check` puede subirlo por lógica delicada, nunca bajarlo.
- **Lee primero.** Hasta cinco `archivo:líneas` con el porqué, lo más delicado arriba.
- **Capturas.** Si el repo tiene preview, la pantalla que cambió en escritorio y móvil.
- **Cambios, CI y revisión:** archivos y líneas, estado del CI (verificado en GitHub) y cuántas vueltas dio con `@check`.
- **Detalle:** lo que dijo `@check`, plegado.

## Qué se mide

En `/factory`, por room:

| Número | Qué es |
|---|---|
| Pasan a la primera | De los PRs que ya revisó una persona, cuántos aprobó sin pedir cambios (o mezcló directo). **La métrica que importa.** |
| Tiempo de revisión | Mediana de «PR listo» a la primera revisión humana. |
| Se concretan | Mezclados entre los pedidos cerrados. |
| Correcciones de @check | Vueltas promedio antes de aprobar. |
| Del pedido al PR | Mediana del pedido al PR listo. |

## Siguiente

- [Equipo por repo](/docs/fabrica/equipo-por-repo): `.ghosty/factory.md` y «@build con opus».
- [Base de conocimiento](/docs/fabrica/conocimiento): lo que los agentes deben saber de tu repo, en tu repo.
- [Evals](/docs/fabrica/evals): comparar agentes y modelos con tus propios pedidos.