Phase 1: Foundation + Broker Spike - Discussion Log

Audit trail only. Do not use as input to planning, research, or execution agents. Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.

Date: 2026-06-04 Phase: 1-Foundation + Broker Spike Areas discussed: Personal-cal spike & fallback, Member color assignment, Infra validation scope

Area Selection

Option	Selected
Personal-cal spike & fallback	✓
Member color assignment	✓
Phase 1 landing scope	(skipped → Claude's discretion)
Infra validation scope	✓

Personal-cal spike & fallback

Where the wife's personal calendar lives

Option	Description	Selected
Fastmail	Fastmail-hosted collection; broker can reach it	✓
iCloud / Apple Calendar	Broker cannot read; CAL-08 degrades
Not sure yet	Confirm before spike
Both / mixed	Define overlay target

User's choice: Fastmail Notes: Removes the iCloud "unreachable" risk; CAL-08 is technically achievable.

Broker access model

Option	Description	Selected
Single broker token + share	One token; share+accept per member
Per-member app passwords	Each member's own app password; broker holds N creds	✓
Prove single-token, keep per-member ready	Hybrid

User's choice: Per-member app passwords Notes: Eliminates the unconfirmed cross-account CalDAV ACL discovery risk (the project's original highest risk). Spike simplifies to confirming an app password reads its own account.

Spike credential sequencing

Option	Description	Selected
Just mine now	Prove broker with Lucas's app password; wife's added Phase 2	✓
Both before Phase 1 done	Get wife's password too; fully close CAL-08 now

User's choice: Just mine now Notes: Phase 1 not blocked on coordinating with wife. CAL-08 structurally proven via N-credential broker.

Credential storage

Option	Description	Selected
DB table, encrypted at rest	Keyed by oidc_sub, key from env; supports later onboarding	✓
Env vars / secrets file	Simple, but redeploy to add/rotate

User's choice: DB table, encrypted at rest Notes: Supports adding wife later with no redeploy; backend-only, never exposed to frontend.

Member color assignment

Option	Description	Selected
Auto-assign from palette	Assign on first login, persist on user row	✓
User-pickable in settings	Default + settings color-picker
Hardcoded per account	Fixed color in config per oidc_sub

User's choice: Auto-assign from palette Notes: No settings UI in Phase 1; stable across sessions; works for future members. Pickable color deferred.

Infra validation scope

Deployment scope

Option	Description	Selected
Deploy through Pangolin	Real tunnel + Authelia; validate OIDC topology day one	✓
Local docker-compose only	Localhost; defer tunnel validation

User's choice: Deploy through Pangolin Notes: Avoids "worked locally, broke in prod" OIDC failure; same-parent-domain cookies (Pitfall 17).

Pangolin SSE smoke test

Option	Description	Selected
Fold it in now	Trivial SSE endpoint over public URL; de-risk Phase 4	✓
Defer to Phase 4	Keep Phase 1 strict to its 5 criteria

User's choice: Fold it in now Notes: Cheap while stack+tunnel are up; a failure changes Phase 4 transport but does not block Phase 1.

Claude's Discretion

Phase 1 landing page: thin authenticated shell that also displays the one cached event as broker proof.
Color palette: small set of visually-distinct, accessible hues, round-robin by join order.
Broker internals (sync-token vs ctag, poll interval), Drizzle schema, OIDC middleware wiring, encryption helper.
Stack libraries/versions per locked research stack.

Deferred Ideas

User-pickable member color (settings color-picker) — future settings/profile phase.
Single-token broker via share+accept — not chosen; alternative on record only.
Wife's app-password onboarding UX/endpoint — Phase 2 (the encrypted credential table is built in Phase 1 to support it).

4.4 KiB Raw Blame History