docs(agent-workflows): reject-siblings approval policy proposal (Deny/Stop/steer)#5444
docs(agent-workflows): reject-siblings approval policy proposal (Deny/Stop/steer)#5444ardaerzin wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Answers the open question in the sessions-takeover handoff (§6): what rejecting one approval card should do to its siblings.
Proposal: keep per-card rejection as the default, don't adopt an inferred cascade, and make scope explicit — Deny (per card) + Stop (turn-level, ≥2 cards) + steer (reject-with-message → model feedback).
Why not an inferred cascade: siblings are real (Pi parks a parallel batch as N cards) and can be heterogeneous — a
bashwrite next to a Gmail send — keyed only bytoolCallId, no danger/grouping signal on the wire. The runner can't tell related from unrelated, so "reject → stop all" guesses wrong exactly in the dangerous case.Feasibility checked: warm Stop is feasible-but-unbuilt — park/resume already ends a turn without disposing the session. v1 Stop = deny-all-via-resume (warm, no runner work); v2 = true cancel (task 5). The one unexercised Claude-ACP path is the acceptance test for v2, not a blocker.
Full reasoning + file:line evidence in the doc. Requesting a ruling on the model before building.