Stuck runs and why a run failed

The platform watches every @plan, @build and @check turn while it runs. It doesn't ask the agent how it's doing: it looks at the tools it uses and applies fixed rules.

What counts as stuck

Legitimate waits don't count: sleep, gh run watch, an until … sleep or waiting for CI.

What happens when it gets stuck

1. The run's thread gets a ⏳ saying which role and which command.
2. The role is told what to check. It gets it as soon as the command returns, which is when it decides whether to wait for it again.
3. From the second stuck pattern in the same run, whoever asked gets a push.

The same pattern isn't reported twice within 30 minutes. The platform never kills a command or stops the turn on its own.

Why it failed

When a run closes, escalates or is cancelled without being healthy (stuck patterns, @build over 30 min, @check→@build loops, red CI), the thread gets a 🩺 with three lines: what happened, the critical step and what to change next time. A healthy run gets nothing.

The full analysis, from the terminal:

ghosty factory runs why 13 --workspace mercadito-verde# #13 missing_service · impact high · deepseek-v4-flash# @build spent 69 of 72 working minutes and installed PostgreSQL with apt…# Critical step#   17:53 @build  node t5.mjs "apt-get install -y postgresql"# Next time#   role_rules In ## @build and ## @check of .ghosty/factory.md: run seed-db <db> before the tests…

Categories are fixed: environment, missing_service, dependencies, unresolved_build_or_tests, fixed_strategy, missing_verification, premature_stop, ambiguous_spec, ci. Actions say where the change goes: role_rules (a rule in .ghosty/factory.md), repo_setup (something in the repo), skill or prompt.

To see times and stuck patterns step by step: ghosty factory runs show 13 --timing. See commands.