Commit Approval
The ONLY execution path. A human click in the approval card approves (→ the write runs) or rejects a pending proposal. App-only — a compliant host never exposes it to the model.
Overview
MCP tool commit_approval (_meta.ui.visibility:["app"], destructiveHint). Requires the per-card widget token (constant-time compared; dispensed only via Get Card DataGet Card DataQueryv0.1.0Approval-card bootstrap: the proposal's summary, payload and the per-card widget token the Accept/Send button needs. App...Ownervisionary-engineeringSchemaMapView docs) and resolves the approver role from the authenticated session — never from a tool argument, so a proposer can never self-approve (§14.1).
Sequence on approve: RBAC check (canApprove(role, kind)) → atomic pending→approved claim (lost race = 409, no double-apply) → the kind’s applier service executes → Mutation AppliedMutation AppliedEventv0.1.0The approved mutation executed against its vendor system; the applier's result (e.g.Ownervisionary-engineeringMapView docs or Mutation FailedMutation FailedEventv0.1.0The applier threw (vendor down, validation, auth) — recorded as status `failed` with the error, surfaced to the card as ...Ownervisionary-engineeringMapView docs. On reject → Proposal RejectedProposal RejectedEventv0.1.0A cleared human rejected the proposal.Ownervisionary-engineeringMapView docs.
Under WRITE_MODE=disabled (beta posture) an approve is refused at this choke point even for proposals already durable in the store; rejections stay allowed.
Input schema
Architecture diagram
Input (from the zod tool schema)
1approve rejectThe per-card token from get_card_data
1AR-collections only: subject/body edited at send