Atascos y por qué falló un pedido

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

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:

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), 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.