3 · Drip on a Google Calendar

Use case · the want as a person would post it:

PARTIAL The drip machinery exists and runs live (30-day schedules, minutely dispatcher, r208 finish gate). Contract 2.15 and the Google Calendar adapter now provide the bridge shape: scoped authorization, frozen action, execution, and receipt. This page has not proven production OAuth configuration or one live Calendar action.

WALKED LIVE 2026-09-02, night — event half in progress After L1 (the connection), CalendarSpecimen filed three calendar.event.create acts through the connector door using only its bearer token (POST /api/bench/connector-actions): three practice sessions, Google-shaped start/end, one hour each. All three landed pending against the authorization the grant minted (cap 3, read + create). Two defects on the person’s side, found before the first approval: (D1) the act cards render inside the Access drawer at the bottom of the want page, not on the step the person is working — a person watching step 3 sees nothing to approve; (D2) the card prints the raw payload (START {"dateTime": ...}, uppercase keys) instead of plain words (“Practice session 1 · Thu Sep 3, 6:00–7:00 PM”). Both are the ACT card design (rule 212): one first-class card on the step, plain words, Approve = execute.

WORKS TODAY — walked to the calendar 2026-09-02 22:30 UTC Steven approved all three (22:27). Under the route as it stood, Approve only marked them approved and the agent still had to call /execute — the exact gap rule 212 names; the foreman ran the three executions through the agent’s door at 22:30 and read the calendar back through the connection: Practice session 1 Thu Sep 3 6:00 PM, 2 Fri Sep 4 6:00 PM, 3 Sat Sep 5 10:00 AM — on Steven’s real Google Calendar, three receipts, the agent never holding a token. (D3) Approve did not execute: fixed the same night — the decision route now executes on approval and the act cards moved onto the step in plain words. Rules 210 and 211 flip on this walk; 212 waits for a fleet agent to file an act unprompted. The proof, in Steven’s own calendar (his screenshot, 22:36 UTC): Thu 6pm · Fri 6pm · Sat 10am, Practice sessions 1–3, next to the receipts on the ledger.

RULE 213 — the send-back that had nowhere to go, 2026-09-03 The agent filed its outcome (three sessions, in words — and first with a 26-character receipt id after each line, which Steven cut: nobody cares about the receipt, it belongs on the ledger, now law in the skill doc). Steven pressed Request changes to change a time. The agent could not act: the grant was read + create with a cap of 3, all three spent, the authorization closed as exhausted, and change or remove were never in it — and there was no way to ask for more mid-deal. Ruled and built the same night: create carries change. Every add grant implies change and remove of the agent’s own additions for the life of the deal, own resources only, each approved; the cap counts adds; exhausted is not revoked. Live on prod with a backfill that rebuilt the three event ids from the receipts, so this very grant can now move or remove exactly those three. The grant card says it in plain words: “Add up to 3 events, and change or remove the ones it added (each one only after you say yes).” The green chip waits for one change to land on the calendar through that door. Found on the way: after a send-back the agent cannot post a check-in (progress may not go backward from its earlier 100; 100 needs an outcome) — a sent-back step must reset progress; queued.

The walk, step by step

Gaps & what to build

HAR Reference · updated 2026-08-30 from target_walk.py, connector_broker.py, connector_registry.py, and connector_executors.py · staging is source of truth