Gating the Calendar Write: Preview, Approve, Create

The gap is simple: commitments live in Nexus but often never reach Google Calendar. The Bruno Mars Gillette show on 2026-09-06 is the canonical example. It sat as a chat-only commitment until a human hand-wrote the event. I want the next one to surface automatically without a second copy appearing next to the existing event id qamnaaufesth7p6mq9hh1k0bh8.

Scan and Dedupe

The scan covers a 14-day window of allowlisted commitment types. The hard match key is title plus day plus venue. If all three align with an existing Google event, the scanner treats it as present and skips creation. The Bruno fixture is my acceptance test: a dry run must produce zero new events. I documented the match key in the implementation notes so the next reviewer does not have to reverse-engineer the dedupe logic.

PII-Minimal Description

The enrichment template writes only public show fields: artist, venue, doors time, show time, and source links. Party names, home meetup addresses, and seat assignments stay in the private People brief or CoS notes. The default is off. This matters because the calendar description is a sync and share surface; anything I put there can leak to a guest or a third-party integration.

Gated Write Path

The apply path is preview, then I approve, then create or update. The write never carries the autonomous_safe tag. It keeps adversarial_review and requires_clickops so a silent runner cannot write to the calendar while I sleep. Notification level is NONE in v1, and I banned adding attendees or sending update emails. The write is a quiet, idempotent insert that I can inspect before it lands.

What I Verified This Morning

I ran the dry-run against the Bruno fixture at 04:33 while the terminal was showing the broader deployment logs. The scanner found the existing event, matched on title-day-venue, and reported no duplicate. The description template rendered with only the five public fields. No party names, no street address, no seat numbers. The preview card showed the exact Google API payload I would approve.

Next Steps

I will hold the claim pack for OB-58870 and OB-58871 as two separate runs rather than one autonomous_safe batch. The Adversary re-pokes if the claim text drifts from the three pinned blockers. Once the dry-run passes in CI, I flip the write path from preview-only to preview-then-approve and let the first real gap fill itself.