Overview

The lowest-blast-radius command in the set — which is why the go-live plan enables it first: one reversible date field on an existing QBO record, no external party sees it, naturally idempotent (re-applying the same date is a no-op), and the applier’s SyncToken re-fetch makes the optimistic-lock 409 path real (tested). The apply is two vendor operations: a QBO read for the fresh SyncToken, then the sparse update.

The flow

How it works

1. Max (agent) on claude.ai → MCP tool call
2. Propose Bill-Date Correction → queue only — no vendor write
3. Approval Bus queues the proposal → pending + widget token minted
4. Proposal Created → approval card renders
5. Cleared human reviews the card → human click — approve
6. Commit Approval (app-only) → RBAC + atomic pending→approved claim
7. Approval Bus claims + dispatches → exactly-once claim
8. Proposal Approved → dispatch by kind: bill-date-correction
9. BillDateCorrectionApplier — re-fetch SyncToken, sparse update → re-fetch bill → fresh SyncToken → one-field sparse update
10. QBO Update Bill (sparse) → the one vendor write
11. QuickBooks Online → result recorded on the proposal
12. Mutation Applied → card refreshes
13. Terminal: proposal applied (a thrown apply records failed instead — Mutation Failed)