Context
requestInfo() (#1740) is a conversation, not a flow movement: the request stays pending, the record stays locked, the same approver keeps the slot, and the submitter can only reply text on the thread. Good enough for "clarify something", not for "the material is wrong — fix it and resubmit", which mainstream approval centers model as 退回修改 / send back for revision.
Target semantics
approval node (suspended)
└─ revise → flow follows a "revise" out-edge to a wait point
├─ record unlocks; submitter edits the data
└─ submitter resubmits → flow re-enters the approval node
└─ a NEW approval request opens (round 2)
What this needs (engine-level, hence not bundled into UI iterations)
- A third resume branch on the approval node — decisions today resume down
approve/reject out-edges (APPROVAL_BRANCH_LABELS); the edge router must learn revise. - Back-edge re-entry — the flow graph gets a cycle (approval → wait → back to approval). The engine is DAG traversal + suspend/resume; re-entering a node a second time needs defined semantics for the suspended-run snapshot, variable overwrites, and round-numbered audit (round 1 sent back, round 2 approved). Note the flow spec docs already anticipate this: "back-to-previous rejection → a back-edge to an earlier node" — the model allows it, the executor doesn't implement it yet.
- Loop guards — a max-revision count (e.g. auto-reject after N send-backs) so instances cannot orbit forever.
- Lock lifecycle — the record-lock hook is keyed on a pending request; the revise window must unlock for the submitter, then re-lock on resubmit.
Test matrix is the real cost: multi-round revision × unanimous behavior × lock states × recall crossing a revise window.
Suggested pairing
Plan together with Studio flow-designer support for authoring the revise edge, so the capability is reachable without hand-editing flow JSON.
References
🤖 Generated with Claude Code
Context
requestInfo()(#1740) is a conversation, not a flow movement: the request stays pending, the record stays locked, the same approver keeps the slot, and the submitter can only reply text on the thread. Good enough for "clarify something", not for "the material is wrong — fix it and resubmit", which mainstream approval centers model as 退回修改 / send back for revision.Target semantics
What this needs (engine-level, hence not bundled into UI iterations)
approve/rejectout-edges (APPROVAL_BRANCH_LABELS); the edge router must learnrevise.Test matrix is the real cost: multi-round revision ×
unanimousbehavior × lock states × recall crossing a revise window.Suggested pairing
Plan together with Studio flow-designer support for authoring the
reviseedge, so the capability is reachable without hand-editing flow JSON.References
requestInfoin feat(approvals): thread interactions — reassign, remind, request-info, comment + SLA & step progress #1740APPROVAL_BRANCH_LABELS(packages/spec/src/automation/approval.zod.ts)🤖 Generated with Claude Code