THE OPERATIONAL PROBLEM
A green trigger is not operational visibility.
Production automations often hide the exact step that failed, whether a retry recovered, whether work was duplicated, or which run needs a person. Loopwatch models that missing control surface around a bounded local workflow.
CONTROL PATH
Every run ends in an explicit state.
- 01Record
Store the run, its steps, timestamps, and stable identifiers.
- 02Recover
Retry only within a visible budget and record a successful recovery.
- 03Stop
Promote exhausted work to an explicit terminal failure.
- 04Review
Queue judgment-sensitive work before any external write.
VERIFICATION EVIDENCE
What was actually checked.
- 5 API tests passHealth, run visibility, simulation, retry behaviour, and review-queue paths.
- Failure is inspectableSeeded and simulated failures remain explicit; the demo reports zero silent failures.
- Review work appears immediatelyA simulated
human_reviewrun is visible in the approval queue. - Responsive interface checkedDesktop and mobile views were inspected without horizontal overflow or console errors.
- Reproducible packageFastAPI, SQLite, deterministic seed data, non-root Docker user, and a container healthcheck.
HONEST LIMITS
This proves a control pattern—not production readiness.
Loopwatch is not a production service and not a client result. The reference build has no authentication, multi-tenancy, durable worker queue, external alert delivery, migrations, or secret management. A real deployment would validate those controls against the client environment and failure modes.