Build Log · June 22, 2026
Hearth: Multi-Member Foundation
Designed and built the household-first multi-member architecture for Hearth — schema, access helpers, and verified backfill.
- Hearth
- Schema
- Architecture
- Multi-tenant
- new tables
- 4
- profiles created
- 6
- spaces created
- 8
- access helpers
- 5
new tables
profiles created
spaces created
access helpers
Timeline
Start
Architecture design
Designed and iterated household-first multi-member model with Zeb + chat review
1h
Schema written
householdMembers, profiles, spaces, calendarSources + expanded routeItems
1.5h
Access helpers built
lib/access.ts — requireHouseholdMember, visibility queries, mutation guard
2h
Schema pushed + backfill verified
db:push clean, backfill confirmed 1 member / 6 profiles / 8 spaces
What shipped
householdMembers table — authenticated users in a household, UNIQUE(householdId, userId)
profiles table — household subjects (adult, child, pet, house, vehicle), optional member link
spaces table — shared/personal/profile rooms with partial uniqueness constraints
calendarSources table — replaces calendarSyncSettings, UNIQUE(householdId, externalCalendarId)
routeItems expanded — spaceId, visibility, source, createdByMemberId, subjectProfileId, assignedToMemberId, sourceExternalId, calendar dedup index
lib/access.ts — requireHouseholdMember, getCurrentMember, getSharedHearthItems, getMemberPersonalItems, getProfileItems, validateItemVisibility
lib/db/backfill-members-spaces.ts — idempotent backfill for existing households
docs/hearth-architecture.md — full architecture reference
forgehome/IMPLEMENTATION_PLAN.md — phased build checklist
Schema pushed to Neon DB — verified clean
Backfill run — Zeb as owner member, 6 profiles, 8 spaces, all route items in Shared Hearth
“Hearth should not be a calendar app wearing a family sweater. It is a household memory system with calendars as one of its senses.”