# Atascos y por qué falló un pedido

> Cómo avisa la Software Factory cuando un rol se atora, qué cuenta como atasco y cómo leer por qué un pedido salió mal.

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

La plataforma vigila cada turno de `@plan`, `@build` y `@check` mientras corre. No le pregunta al agente si va bien: mira las herramientas que usa y aplica reglas fijas.

## Qué cuenta como atasco

| Regla | Cuándo |
|---|---|
| `long_command` | un comando lleva 8 min o más sin terminar |
| `repeat` | el mismo comando 4 veces con el mismo resultado |
| `repeat_error` | el mismo comando falla 3 veces |
| `ping_pong` | va y viene entre dos acciones (6 seguidas) |
| `apt_install` | instala paquetes del sistema a mano dentro de una caja |

Las esperas legítimas no cuentan: `sleep`, `gh run watch`, un `until … sleep` o esperar el CI.

## Qué pasa cuando se atora

1. En el hilo del pedido aparece un **⏳** que dice qué rol y en qué comando.
2. Al rol se le dice qué revisar. Le llega en cuanto regresa el comando, que es cuando decide si lo vuelve a esperar.
3. Desde el segundo atasco del mismo pedido, quien lo pidió recibe un **push**.

El mismo atasco no se avisa dos veces en 30 minutos. La plataforma nunca mata un comando ni corta el turno por su cuenta.

## Por qué falló

Cuando un pedido cierra, se escala o se cancela **sin haber sido sano** (atascos, `@build` de más de 30 min, vueltas `@check`→`@build`, CI rojo), el hilo recibe un **🩺** con tres renglones: qué pasó, el paso crítico y qué cambiar para la próxima. Un pedido sano no recibe nada.

El análisis completo, desde la terminal:

```bash
ghosty factory runs why 13 --workspace mercadito-verde
# #13 missing_service · impacto alto · deepseek-v4-flash
# @build consumió 69 de los 72 min de trabajo e instaló PostgreSQL con apt…
# Paso crítico
#   17:53 @build  node t5.mjs "apt-get install -y postgresql"
# Para la próxima
#   role_rules En ## @build y ## @check de .ghosty/factory.md: corre seed-db <base> antes de las pruebas…
```

Las categorías son fijas: `environment`, `missing_service`, `dependencies`, `unresolved_build_or_tests`, `fixed_strategy`, `missing_verification`, `premature_stop`, `ambiguous_spec`, `ci`. Las acciones dicen dónde va el cambio: `role_rules` (una regla en [`.ghosty/factory.md`](/docs/fabrica/equipo-por-repo)), `repo_setup` (algo del repo), `skill` o `prompt`.

Para ver los tiempos y los atascos paso por paso: `ghosty factory runs show 13 --timing`. Ver [comandos](/docs/cli/comandos#fabrica).