Calendar

[michielbdejong]

Context

Audit of the current Google Calendar integration, to decide whether it could replace Google's own Calendar UI as the daily-driver calendar. Short answer: not yet — see gaps and phased plan below.

The plugin spans three repos:

• localthought/atomic-plugins (this repo) — mirror of integrations/, including the undeployed integrations/localthought/calendar-proxy.patch. Work on this plan happens here.
• ontola/atomic-server — host: LocalThought browser OAuth/PKCE flow, WASM Syncables engine, generic CalendarView UI. See planning/google-calendar-import-gaps.md and docs/imports/google-calendar-gap-report.md there for the existing (thorough) internal audits this plan builds on.
• localthought/devonian (platform-lenses/google-calendar/) — the actual lens: projection, recurrence, and two-way edit logic (sync.ts, import.ts, lens/*.ts). Pulled in as a pinned GitHub dependency, not vendored.

A companion service, localthought/integration-proxy, also needs a deploy (see Phase 1).

Current status

Import (read path) — solid.

• Browser-only OAuth/PKCE via LocalThought, no server secrets.
• Bounded date-range import or "keep recurring series" mode; live-verified against a real Google account (2026-09-09: 22 calendars, 32 events).
• All-day vs. timed events projected correctly (exclusive end dates, civil-date handling, DST-safe).
• Recurrence: daily/weekly/monthly/yearly RRULE with INTERVAL/COUNT/UNTIL/BYDAY/BYMONTHDAY/BYMONTH/BYSETPOS/WKST, RDATE/EXDATE, exceptions and cancellations.
• Auto-refresh every 5 min while a tab is open; stable identity across re-imports; local edits and Atomic-only fields preserved.

Two-way sync — implemented but narrow and not live-deployed.

• previewCalendarEdits / applyCalendarEdit (devonian sync.ts) cover only 5 fields: name/summary, description, location, start, end — with ETag/If-Match conflict detection, including individual recurring instances.
• No create-event or delete-event path exists at all — only editing fields on events already imported from Google.
• The proxy change required for writes (calendar.events scope, If-Match CORS forwarding) is an unmerged/undeployed patch (integrations/localthought/calendar-proxy.patch in this repo). Production OAuth scope is still calendar.readonly, so write-back doesn't function yet even though the client code exists.

Missing outright:

• No RSVP/attendee management, no reminders/notifications, no conferencing links usable, no calendar colors, no special event-type handling (birthdays, OOO, focus time, working location).
• No combined multi-calendar agenda/day/week view with per-calendar visibility — each Google calendar becomes its own Atomic table.
• No incremental sync (persisted syncToken); every refresh is a bounded re-fetch, deletions inferred only from tombstones inside the fetched window.
• No ICS/CSV import or export.
• No event-creation dialog / recurrence-authoring UI (raw table-cell edits and raw JSON only).

Why it can't yet replace Google's Calendar UI

1. No event create/delete from Atomic — anything new or canceled must be done in Google's own UI first, then pulled in on next sync.
2. Write scope isn't deployed — even editing an existing imported event's time/title doesn't currently reach Google in production.
3. No reminders/notifications and no RSVP handling — anything involving other people or alerts still needs Google's app.

Phased plan

Phase 1 — Close the write-back gap (small: mostly deployment)

• Deploy calendar-proxy.patch to integration-proxy (or land it as a real PR there); flip OAuth scope in production; require existing connections to reconnect.
• Live-verify applyCalendarEdit against a real account (currently mock-tested only).

Phase 2 — Event creation & deletion (medium — the actual blocker)

• Add insertEvent / deleteEvent to the devonian lens (Google events.insert / events.delete), mapped from new-row / row-deletion in an imported calendar table.
• Build a proper event editor dialog (title, description, location, start/end, all-day toggle) so projected fields and the outbound payload can't disagree — this is P0 in the existing gap doc too.

Phase 3 — Make it feel like a calendar, not an event table (largest chunk)

• Unified multi-calendar agenda/week/day view with per-calendar color and visibility toggles, built on existing per-calendar identity.
• Reminders/notifications (surface Google's reminder minutes; browser notification at trigger time as a stretch).
• Attendees/RSVP: read-only display first, write-your-own-RSVP as a follow-up.

Phase 4 — Reliability for daily-driver use

• Incremental sync via Google's syncToken, proper tombstone/deletion handling, recovery from HTTP 410.
• Recurrence editing UI ("this event" / "this and following" / "entire series") — currently raw-JSON only.

Phase 5 — Nice-to-haves

• Special event types (OOO, focus time, working location, birthdays) rendered distinctly instead of as generic meetings.
• ICS import/export as a fallback path independent of the Google API.

Suggested order of work

Phases 1–2 are the minimum to stop needing Google's UI for basic scheduling; Phase 3 is what makes it pleasant enough to actually prefer day to day.

---

Moved from ontola/atomic-server#1602 — GitHub doesn't support issue transfer across different-owner repos, so that issue was closed with a pointer here.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01LjCR6idtt6BFaKCiB3JDnb

[michielbdejong]

Phase 1 progress: write-back gap traced and closed at the catalog level

Started on Phase 1 ("deploy calendar-proxy.patch"), and it turned out the patch itself is stale — integration-proxy has since moved from a static per-platform providers.rs list to a dynamic OpenAPI+Overlay catalog fetched at runtime from localthought/overlays. The CORS/If-Match forwarding and calendar.events/calendar.calendarlist.readonly OAuth scopes the patch wanted are already generic, already-shipped behavior in integration-proxy today — not gated behind that patch.

The actual remaining blocker was narrower and one level up: the composed google-calendar catalog document only ever declared GET operations (the base spec is explicitly titled "read-only subset"), so Catalog::allows() rejected every PATCH regardless of scope or CORS. Devonian's lens (planCalendarEdit/applyCalendarEdit) has been sending PATCH .../events/{id} with If-Match and a partial body (summary/description/location/start/end) all along — nothing in the catalog ever let it through.

Opened two PRs closing that gap:

• localthought/overlays#166 — adds the patch operation, its x-crud metadata, and the event.etag schema field devonian reads for If-Match. Reuses the calendar.events scope already requested for GET, so no new consent is needed.
• localthought/integration-proxy#75 — bumps the deployed DEFAULT_CATALOG_PATH pin to it, per integration-proxy's own AGENTS.md platform-fix workflow.

Both are tested (Python composition/validation tests in overlays; the full Rust suite plus the two network-gated pinned-fixture tests in integration-proxy, all green) but not merged or deployed — that, and restarting the integration-proxy service, are deliberately left for a human to pull the trigger on, along with live-verifying a write against a real Google account (still mock-only, as the plan noted).

In this repo: removed the now-inapplicable calendar-proxy.patch and pointed integrations/localthought/README.md's deployment-requirement note at the two PRs above instead (4d08162 on claude/zealous-heisenberg-dvw2uy).

What's left for Phase 1 specifically, once those two PRs are reviewed and merged: restart integration-proxy, reconnect a real Google account if the calendar.events scope wasn't already exercised in this deployment, and confirm a live applyCalendarEdit round-trip. Phases 2–5 (event create/delete, unified calendar view, reminders/RSVP, incremental sync, ICS) are unstarted.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YZYTjDU1jrJXXfQB1YPYLA

---

Generated by Claude Code

[miracle73]

Hi Michiel, I reviewed your Phase 1 update. I can take ownership of a paid production rollout and reliability milestone: deploy and restart integration-proxy, reconnect OAuth, verify live PATCH updates with ETag conflict handling, add an automated smoke test, and document rollback procedures.

After that, I can implement incremental synchronization using syncToken, including deletion handling and HTTP 410 recovery. This would turn the current mock-tested integration into reliable production behaviour. Would you be open to agreeing on a fixed budget before I begin?

[michielbdejong]

Google Calendar OAD migration

ontola/openapi-directory removed APIs/googleapis.com/google-calendar/v3/openapi.yaml — the hand-written, read-only "Reflector subset" of Calendar v3 the previous Phase 1 write-back work (overlays#166) was built against — and replaced it with a regenerated APIs/googleapis.com/calendar/v3/openapi.yaml, converted straight from Google's own Calendar Discovery document (their reasoning: "the generated calendar/v3 document is the same API, complete"). localthought/openapi-directory's pinned copy at the old path keeps resolving by SHA, but the path is gone from both forks' default branches, so #166 was quietly stale.

Migrated the whole chain:

• localthought/overlays#168 — repoints the composed google-calendar catalog at the new base document; replaces Pin atomic-server to 69602364b (#1755 re-publisher read, #1756 well-known 404) #166's hand-written PATCH operation with a one-line security override on the operation the full spec already defines natively (it always had insert/patch/update/delete on events — the old subset was deliberately trimmed to read-only); drops the now-redundant schema-overlay.yaml (the fields it hand-added — recurrence, originalStartTime, etag — are already on the generated Event schema). Also widens security narrowing to the ~30 other operations the full spec brings along (ACL/color/freebusy/settings/channel management this platform never calls), since integration-proxy's oauth_provider() validates every operation in the composed document, not just the ones this platform tags via x-crud. Worth flagging: Catalog::allows() checks path/method existence only, not x-crud, so this does widen what the proxy will forward for this platform — Google's own per-scope enforcement on the actually-granted token remains the real boundary underneath that (superseded Pin atomic-server to 69602364b (#1755 re-publisher read, #1756 well-known 404) #166 and an interim Host API requirements to complete the server protocol plugins #167 that turned out to be based on main's tip, which has an unrelated, separately-broken clockify catalog entry).
• localthought/integration-proxy#76 — bumps DEFAULT_CATALOG_PATH to the migrated pin and regenerates the checked-in composed-document fixtures (supersedes the now-merged Bump atomic-server to b875d4a31 and lift the plugin-system e2e quarantine #75, which pointed at the doomed base path).
• atomic-plugins#24 (this repo) — repoints the Calendar README's deployment-requirement note at the new PRs.

All three verified: the overlays composition validates and its test suite passes against the live pushed branch; integration-proxy's full cargo test suite (100 tests) plus the three network-gated catalog-pin tests pass against the live new pin end to end.

Bonus finding for whoever picks up Phase 2 (event create/delete): the new base document already defines insert/delete on events (POST/DELETE, already security-narrowed by #168), so unlocking those is now purely a crud-causality-overlay.yaml (x-crud) exercise, not a schema- or security-authoring one — smaller than the plan originally scoped it.

Still pending, unchanged from the previous update: #168/#76/#24 need review and merge, then integration-proxy needs a restart to pick up the pin, and a live applyCalendarEdit round-trip against a real Google account remains unverified (mock-tested only).

🤖 Generated with Claude Code