- scripts/seed.ts: idempotent pnpm db:seed inserts "Home" household if none exists (powered by tsx)
- signIn callback: first member of household gets owner role, subsequent users get member
- src/lib/session.ts: getCurrentSession() returns { user, household, role }, throws if unauthenticated or unmembered
- /settings/household: member list for all roles; rename form gated to owner only (server action also enforces)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Multi-stage Dockerfile (pnpm fetch/offline, standalone output, non-root
nextjs user), deploy/compose.yaml with famapp + famapp-db + full Authentik
stack on famapp_net, Caddyfile.snippet for fam/auth.ginnoir.com, and
.env.production.example. Added .dockerignore and public/.gitkeep.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Implements the extensibility foundation: ModuleManifest/DashboardWidget/EntityTypeRegistration types in _core/module.ts, a plain-Map registry singleton with registerModule/getRegistry/getEntityType/getWidget, and stub manifests for calendar/lists/notes. Root layout imports src/modules/index.ts for side-effect registration; AppNav reads the registry to render nav links. /debug/registry dumps the full registry JSON in dev using zod v4 + z.toJSONSchema(). Adding a fourth module requires one folder + one line in index.ts.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Architecture refinements before module work begins:
- Calendars become first-class entities (mirror of lists). Each
calendar has its own visibility (private | household) and is
independently shareable. Updated CLAUDE.md data model and task 10.
- Drop the singleton/parameterized split for dashboard widgets. Every
widget declares a configSchema + defaultConfig + resolveConfigOptions
and every placement is an independent instance — same widgetId can
appear multiple times on one dashboard pointed at different things.
Updated task 04 contract; tasks 11/12 widget sections aligned.
- Add tasks 25 (multiple dashboards per user) and 26 (customizable
layout + widget configuration). Replaces the previously-considered
three-task plan with a cleaner two-task split that the uniform
contract enables. Phase 3 index updated; STATUS records the rationale.
- Task 20 reframed as a single-dashboard MVP that exercises the new
contract end-to-end before the customization layer lands.
Multi-theme × {light, dark} per-user theming, switchable on the fly.
Slots into phase 1 before modules start so the token system is the
foundation rather than a retrofit. Update STATUS to point at task 03
correctly and reflect 08 in the phase 1 roadmap.
ginnoir