automation: the revise-window `wait` pause is service-owned but type-keyed gating can't see it

[os-zhuang]

Found while implementing the resume gate for #3801 (PR #3822). Adjacent seam, same
trust boundary, different shape — filing rather than widening that PR.

Reasoned from code, not demonstrated — no repro was written, same caveat as
#3801.

Requirement

#3822 gates POST /api/v1/automation/:name/runs/:runId/resume on the node type
that produced the suspension: a descriptor may declare resumeAuthority: 'service',
and approval does, so an approval pause continues only through ApprovalService.

ADR-0044's revise window is the same trust boundary in a shape that key cannot
see. Send-back resumes the run down the revise edge onto an ordinary wait node
(signal flavor) placed by the flow author (ADR-0044 §D3: "The revise edge targets an
ordinary wait node — the durable pause already shipped for timers/signals"). The run
parks there until ApprovalService.resubmit, which enforces submitter-only, refuses
a colliding pending request, and audits a resubmit action before resuming.

Nothing enforces that path. wait is resumeAuthority: 'any' — correctly, since a
signal-flavored wait is meant to be resumable by an external producer — so a raw
resume of a run parked in a revise window walks the declared back-edge into the
approval node, opening round N+1 with no sys_approval_action row and none of
resubmit's checks. Lower severity than the approval bypass #3801 closed (it forces a
resubmit rather than an approval), but it is the same class: a service-owned
continuation reachable around the service.

Why the #3822 mechanism doesn't extend to it

The gate keys on the node's registry type, and the type here is a generic wait
indistinguishable from every other author-placed wait in the system. Gating all wait
nodes would break the documented signal/webhook/manual resume contract.

Closing it needs a per-suspension owner claim rather than a per-type one — the
suspension itself recording that a service owns this particular pause. Sketch, for
discussion rather than a settled design: let a resume signal carry an owner claim that
is persisted onto the continuation, so the service that drove the run into the wait
also owns driving it out; the type-keyed declaration then becomes the default when no
claim is recorded.

Refs #3801, #3822. Context recorded in the 2026-07-28 addendum to
ADR-0019.

[os-zhuang]

Now demonstrated, and the severity in the description above is understated. Repro built on the existing approval-revise.test.ts harness (real engine + real ApprovalService), run against main @ 93f267f81.

Confirmed: unauthorized resubmit, no audit row

A raw resume(runId) on a run parked at the revise-window wait:

code:            undefined          ← not refused; `wait` is resumeAuthority 'any'
round-2 request: opened (new id)    ← the back-edge fired, the approval node re-entered
audit trail:     ['submit', 'revise']   ← no 'resubmit' row, ever

Two corrections to the description: it needs no branchLabel (an empty body works — the labelled back-edge is walked either way, verified both ways), and it bypasses resubmit's submitter-only check as well as the audit row.

Not in the description: it can permanently kill the run

ApprovalService.resubmit refuses with DUPLICATE_REQUEST when another request is already pending on the same record, and the code comment says exactly why:

A colliding pending request on the same record … would make the approval node's re-entry fail AFTER the engine consumed the suspension — permanently killing the run. Refuse up front instead.

That guard lives in the service, and the raw resume goes around it:

service.resubmit(...)   → throws DUPLICATE_REQUEST, run still suspended (1)
automation.resume(runId) → { success: false,
                             error: "Node 'review' failed: … DUPLICATE_REQUEST: a pending
                                     approval already exists for fin_expense/x1" }
                           suspended runs: 0        ← consumed, run terminally dead

The approval is then unresolvable: the round-1 request stays returned, the run that owned it is gone, and no resubmit can ever reach it. Opportunistic (it needs a colliding pending request to exist, which an ordinary user can often cause — a record-change trigger re-firing inside the revise window is the documented case), but it is remote run destruction, not just a missing audit row.

This changes the recommended fix

The description sketches a per-suspension owner claim. Having looked harder, the simpler option is the one ADR-0044 considered and rejected — "Approval node re-suspends itself in a 'revise mode' (no wait node)" — or an equivalent dedicated node type. Either makes the revise pause typed as service-owned, so the existing resumeAuthority gate covers it with no new machinery. ADR-0044 chose the generic wait for reuse; what we know now is that a generic node sitting in a service-owned position is exactly what a type-keyed gate cannot see.

The owner-claim design is still the more general answer, but it needs care the sketch didn't account for: an approval whose approve branch leads to a screen must NOT inherit the claim, or the UI can no longer advance that screen. Blanket inheritance breaks screen flows downstream of an approval.

Refs #3801, #3853, #3879.

---

Generated by Claude Code