CalCalist/TODO.md

# Roadmap

Milestones from the implementation plan. See SPECS.md for the architecture and the
sync semantics these items implement.

## M0 — skeleton (done)

- [x] Initialise jj colocated with git; `.gitignore` written before the first build
- [x] `devbox.json` pinning Rust 1.97.1, pimsync 0.5.11, jujutsu 0.44.0, radicale 3.7.8
- [x] Configuration model with referential validation, reporting every problem in one pass
- [x] `calcalist doctor` — pimsync presence and version series, state directory, configuration
- [x] Define the full CLI surface; unimplemented commands exit 2 rather than pretend
- [x] SPECS.md: Rust naming conventions, `devbox run check` gate, recorded sync semantics

## M1 — bidirectional sync

Core modules:

- [x] `state.rs` — JSON sidecar, atomic temp + fsync + rename; records each aggregate's
      resolved target endpoint id **and** backend type
- [x] `vdir.rs` — read and write vdir directories
- [x] `ical.rs` — surgical line-level `.ics` editing (UID rewrite, property injection),
      respecting RFC 5545 folding; no parse-and-reserialize
- [x] `provenance.rs` — deterministic `blake3(aggregate_id, source_id, source_uid)` UIDs
- [x] `mirror.rs` — the to-aggregate and to-source transforms (added; not in the
      original plan, which folded these into `reconcile`)
- [x] `reconcile.rs` — the aggregation engine; pure, no I/O
- [x] `sync.rs` — one cycle over the local vdirs, applying what `reconcile` decides
- [x] `pimsync.rs` — generate `pimsync.conf` (with `on_empty skip` and `on_delete skip`),
      drive one-shot `pimsync sync` bracketing the reconcile step
- [x] `doctor` asks `pimsync check` to validate the generated config, since pimsync's
      parser does not always match its documentation
- [x] `google/auth.rs` — OAuth loopback flow with PKCE, refresh, keyring-sourced secrets
- [x] `google/convert.rs` — JSON to iCalendar, including recurrence and timezones
- [x] `google/api.rs` — incremental pull by syncToken, and push by import / update
      / delete with notification suppressed
- [x] Reintroduce `SchedulingSuppression` in `config.rs` (removed in M0 as dead code)

Safety-critical behaviour:

- [x] **`events.import` gate** — settled from Google's own API discovery document:
      `events.import` accepts no `sendUpdates` parameter at all, while `insert`,
      `update` and `delete` all do, and it is documented as adding "a private copy of
      an existing event". Confirmed live that attendees and alarms survive an import.
      Creation goes through `import`; update and delete pass `sendUpdates=none`.
- [x] `sync` refuses to run on aggregate target drift, before reconciliation
- [x] `aggregate retarget` — flush unrouted creations against the old target, then
      re-materialise; keep old orphans by default
- [x] Mass-deletion guard (`max_delete_fraction`), overridable with `--force`, with an
      absolute floor so deleting a couple of events is never refused
- [x] Echo suppression: derived UIDs are never re-ingested as source events

Tests:

- [x] `reconcile` table-driven cases: create/update/delete each direction, both-sides-changed,
      routing, echo suppression, mass-delete abort
- [x] `ical` round-trip fixtures: recurring with overrides, all-day, TZID, unknown `X-` props
- [ ] Integration against Radicale plus a `file://` WebCal fixture; assert idempotence
- [x] Safety (unit level): no live `ATTENDEE`/`ORGANIZER` on a CalDAV-targeted mirror,
      `VALARM` intact, `PARTSTAT: DECLINED` maps to `TRANSP: TRANSPARENT`, bulk deletion aborts
- [ ] Safety (integration): the same against a real Radicale instance with an SMTP sink,
      proving no mail is emitted
- [x] Retarget: drift makes `sync` exit non-zero having written nothing and losing no source
      event; purge is bounded by the derivation; an unrouted creation reaches a sink first

### Verified live, end to end

Two Google calendars aggregating into a Posteo CalDAV calendar, against real accounts:
fan-in from both sources with provenance intact; an edit in the aggregate reaching the
originating Google calendar; an event created in the aggregate routed to a chosen
source by a description marker; deletion propagating from the aggregate through to
Google; and the mass-deletion guard refusing a 100% removal until `--force`.

### Known gaps carried out of M1

- [ ] A recurring series' *exceptions* are not pushed to Google. Google models them
      as separate events against an already existing series, so they need
      `events.instances` plus a patch per exception. Reported per sync rather than
      dropped silently.
- [x] `push` deleting an event remotely — verified live: deleting a mirror in the
      CalDAV aggregate removed the origin event from Google.
- [ ] A failed Google pull aborts the whole cycle, including the CalDAV side. Safe —
      reconciling against a stale snapshot could read as mass deletion — but it means
      a lapsed token stops everything.

## M2 — interface and packaging

- [ ] axum configuration UI, bound to 127.0.0.1
- [ ] OAuth loopback redirect handler
- [ ] systemd user units: `calcalist.service` (oneshot) and `calcalist.timer`