Problem: #4806's own closing PR (#5806) shipped only the decision core: evaluateEscalation() (in packages/loopover-engine/src/loop-escalation.ts) decides whether a loop needs a human, and buildFleetSummary() (packages/loopover-engine/src/loop-fleet-summary.ts) can summarize a fleet's escalation status on demand. Neither is ever called automatically today -- the only ways to see an escalation decision are the manually-invoked loopover_evaluate_escalation MCP tool, or a human proactively calling buildFleetSummary() themselves. Nothing runs on a schedule, and nothing notifies anyone. #4806's own acceptance criteria ("a simulated escalation reaches a human-reviewable state within a defined target time") is not actually met end-to-end.
Area: Platform / Ops
Proposal: Add a scheduled sweep (reusing this repo's existing cron infrastructure, e.g. the pattern in src/review/sweep-watchdog.ts) that periodically evaluates the active rented-loop fleet's escalation status and pushes a notification (reusing src/services/notify-discord.ts's existing webhook pattern, or src/review/alerts.ts's throttled-alert pattern) when something needs a human.
Deliverables:
- A scheduled job that periodically calls the fleet's escalation evaluation and fires a real notification (not just a queryable status) when
shouldEscalate is true.
Acceptance criteria:
Boundaries:
- Not in scope: changing
evaluateEscalation's decision logic itself (already shipped, correct) or building a new notification channel (reuse notify-discord.ts / alerts.ts's existing pattern).
Found while researching #4810's real blocking chain (the launch-readiness pilot's own acceptance criteria requires every milestone item to be confirmed working end-to-end, not just individually merged -- this is exactly the kind of gap that check exists to catch). Part of #4778.
Problem: #4806's own closing PR (#5806) shipped only the decision core:
evaluateEscalation()(inpackages/loopover-engine/src/loop-escalation.ts) decides whether a loop needs a human, andbuildFleetSummary()(packages/loopover-engine/src/loop-fleet-summary.ts) can summarize a fleet's escalation status on demand. Neither is ever called automatically today -- the only ways to see an escalation decision are the manually-invokedloopover_evaluate_escalationMCP tool, or a human proactively callingbuildFleetSummary()themselves. Nothing runs on a schedule, and nothing notifies anyone. #4806's own acceptance criteria ("a simulated escalation reaches a human-reviewable state within a defined target time") is not actually met end-to-end.Area: Platform / Ops
Proposal: Add a scheduled sweep (reusing this repo's existing cron infrastructure, e.g. the pattern in
src/review/sweep-watchdog.ts) that periodically evaluates the active rented-loop fleet's escalation status and pushes a notification (reusingsrc/services/notify-discord.ts's existing webhook pattern, orsrc/review/alerts.ts's throttled-alert pattern) when something needs a human.Deliverables:
shouldEscalateis true.Acceptance criteria:
Boundaries:
evaluateEscalation's decision logic itself (already shipped, correct) or building a new notification channel (reusenotify-discord.ts/alerts.ts's existing pattern).Found while researching #4810's real blocking chain (the launch-readiness pilot's own acceptance criteria requires every milestone item to be confirmed working end-to-end, not just individually merged -- this is exactly the kind of gap that check exists to catch). Part of #4778.