Address the P1 review finding on PR #1085: --members lets one call remove
up to 30 USER/DEPT/CONVERSATION/TAG members, where departments, chats,
and role groups can indirectly affect many more users, yet the remove
branches called the MCP tool right after argument parsing with Safety
confirmation=not_required.
- drive permission remove, doc permission remove, and wiki member remove
now declare confirmation=user_required. DeclareLeafMetadata installs
the ConfirmSafety gate automatically (deferred to the first
deps.Caller.CallTool so flag validation still fails first), so an
unconfirmed invocation exits with the typed confirmation_required
error and performs zero MCP calls; --yes, an interactive yes, or
--dry-run previews remain the supported paths.
- Pass framework confirmation errors through WrapErrorWithOperation
verbatim (new apperrors.IsConfirmationRequired). Text classification
misrouted them: command paths containing "permission" (drive/doc
permission remove) were re-reported as AUTH_PERMISSION_DENIED while
other paths (wiki member remove) lost their reason and degraded to
UNCLASSIFIED.
- Tests: TestPermissionMemberRemoveRequiresConfirmationBeforeToolCall
covers all three entry points for both --members and legacy --users —
unconfirmed rejects with zero MCP calls, --yes dispatches exactly one
call with the complete precise arguments, --dry-run previews without
calls. Existing remove tests inject root --yes for the assembly
assertions; blank --users still fails validation before confirmation.