sentinel
sentinel
The chain gates correctness at ship and then goes blind. review-pass is a one-time gate, /run is a one-time demo, and after pr-craft nothing is watching. sentinel is the stage that watches, and its only output is an intent file — the same artifact grill-me writes, so a problem found in production re-enters the pipeline as ordinary planned work rather than as an interrupt.
It decides nothing about how to fix anything. It files findings; a human picks up the intent file and routes it through /dev-flow like any other task. That division is deliberate: the detector runs unattended, so the moment it could also change code it would need a level of trust no scheduled job has earned.
Two tiers
Run tier 1 always. Add tier 2 per project, only where the signal justifies the credential.
| Tier | Source | Cost | Catches |
|---|---|---|---|
| 1 — history | the repo's own git log | nothing | recurring fix classes, reverts, fix-rate drift |
| 2 — prod | a live telemetry API you configure | one scoped read token per project | error-rate and latency breaches, the outcome metric a feature was supposed to move |
Tier 1 is lagging and coarse — it tells you a file keeps breaking, days or weeks after users noticed. Tier 2 is the one that catches an incident while it's happening. Neither replaces the other, and tier 1 alone is still worth scheduling because it costs nothing and needs no wiring.