Found while implementing #13909 slice 2 (PR #13951). ⛔ Not filed as a defect in that slice's own work — the gap predates it and is wider than one verb.
The reading
AutomationEngine has two deliberate, operator-initiated run-lifecycle verbs:
Neither is reachable by an operator. Measured on origin/main plus PR #13951:
- ⛔ No REST route. The automation run surface exposes
resume, the run list, run detail and the paused-run screen. There is no cancel route and no repair route, so a deployment operator holding only HTTP cannot invoke either.
- ⛔ No CLI command.
packages/cli has no run commands at all.
- ⛔ Neither is declared on
IAutomationService (packages/spec/src/contracts/automation-service.ts), so a host that holds only the service contract cannot call them either — only one holding the concrete engine can.
⇒ Both are host-only primitives. For cancelRun that has been survivable because plugin-approvals calls it in-process on the revise-window recall path. For the repair verb there is no in-process caller by design — it is meant to be asked for by a person.
Why this is worth its own card rather than a rider
Adding a door is not a line of routing. It needs a permission model of its own, and the wrong one is worse than none: a repair verb re-arms a run the platform recorded as terminally failed, so "who may do this" is a real question and not the same answer as "who may resume". #13909's own posture (⛔ never a door that returns success to hide the condition) applies to whatever this becomes.
A trap for whoever takes it — do NOT ship a plain lister
The obvious companion, "list the runs an operator could repair", is the one shape that must not be built naively. #13909's whole premise is that ⭐ the one inspector that should have caught this class reported all clear. A lister backed only by the engine's in-memory journal answers zero in any process that did not itself strand the run — which is almost every process an operator is looking at — and a confident zero is exactly the failure the parent card is about. PR #13951 deliberately does not ship one for that reason. A correct lister is a QUERY over sys_automation_run terminal rows carrying a restorable snapshot, not a read of engine memory.
Not measured
How many deployments have wanted either verb is unknown from this repo, and so is how many runs are in the repairable state (that needs an operator census — see #13909). This card records a reachability gap, not a demand estimate; whether it is worth building is a triage call.
Related
#13909 (the repair verb and its measurement) · PR #13951 (which adds the verb, engine-level, and states this gap as an explicit non-goal) · #13937 (the resume-ordering decision; unruled)
Generated by Claude Code
Found while implementing #13909 slice 2 (PR #13951). ⛔ Not filed as a defect in that slice's own work — the gap predates it and is wider than one verb.
The reading
AutomationEnginehas two deliberate, operator-initiated run-lifecycle verbs:cancelRun(runId, reason)— end a suspended run (ADR-0044);restoreConsumedSuspension(runId, options)— put back a suspension a failed resume consumed (service-automation: a resume consumes the pause BEFORE running downstream nodes, so any node that throws leaves the run terminally unresumable — and the only inspector for it reports all clear #13909 slice 2).Neither is reachable by an operator. Measured on
origin/mainplus PR #13951:resume, the run list, run detail and the paused-run screen. There is no cancel route and no repair route, so a deployment operator holding only HTTP cannot invoke either.packages/clihas no run commands at all.IAutomationService(packages/spec/src/contracts/automation-service.ts), so a host that holds only the service contract cannot call them either — only one holding the concrete engine can.⇒ Both are host-only primitives. For
cancelRunthat has been survivable becauseplugin-approvalscalls it in-process on the revise-window recall path. For the repair verb there is no in-process caller by design — it is meant to be asked for by a person.Why this is worth its own card rather than a rider
Adding a door is not a line of routing. It needs a permission model of its own, and the wrong one is worse than none: a repair verb re-arms a run the platform recorded as terminally failed, so "who may do this" is a real question and not the same answer as "who may resume". #13909's own posture (⛔ never a door that returns success to hide the condition) applies to whatever this becomes.
A trap for whoever takes it — do NOT ship a plain lister
The obvious companion, "list the runs an operator could repair", is the one shape that must not be built naively. #13909's whole premise is that ⭐ the one inspector that should have caught this class reported all clear. A lister backed only by the engine's in-memory journal answers zero in any process that did not itself strand the run — which is almost every process an operator is looking at — and a confident zero is exactly the failure the parent card is about. PR #13951 deliberately does not ship one for that reason. A correct lister is a QUERY over
sys_automation_runterminal rows carrying a restorable snapshot, not a read of engine memory.Not measured
How many deployments have wanted either verb is unknown from this repo, and so is how many runs are in the repairable state (that needs an operator census — see #13909). This card records a reachability gap, not a demand estimate; whether it is worth building is a triage call.
Related
#13909 (the repair verb and its measurement) · PR #13951 (which adds the verb, engine-level, and states this gap as an explicit non-goal) · #13937 (the resume-ordering decision; unruled)
Generated by Claude Code