Household Profiles for Managing Dependents Under One Account

Summary

Introduce a household mode where one authenticated account can manage multiple dependent profiles (e.g., child, parent, spouse) with strict per-profile data isolation, profile switching, and scoped reminder/calendar views.

Problem / Opportunity

SymptomSync currently centers on a single-user record model. In real care workflows, one person often manages medications, appointments, and logs for multiple family members. Without dependent profiles, users either create separate accounts (high friction) or mix records (unsafe and confusing).

Proposed Feature

Add a first-class Household capability:

• A primary account can create/manage dependent profiles.
• Data entities (medications, appointments, logs, files, notifications) are attached to a specific profile.
• UI includes a global profile switcher and profile-scoped dashboard/calendar/notifications.
• Chatbot and reminder workflows become profile-aware by default.

Scope

1. Data model and policies

• Add tables for household membership and dependent profiles.
• Attach all health data rows to a profile_id (or equivalent) while preserving owner linkage.
• Implement RLS policies that enforce access by household relationship + profile scope.

2. Frontend profile-aware experience

• Add a profile switcher in main navigation.
• Show active-profile badges on key pages (Dashboard, Calendar, Medication, Documents, Chat).
• Ensure create/edit flows always target the active profile.

3. Reminder and notification routing

• Include profile context in reminder generation and notification payloads.
• Ensure realtime updates are filtered to current profile unless user opts into household-wide feed.

4. AI/chatbot profile context

• Pass active profile context into chatbot tool/action execution.
• Prevent cross-profile actions unless explicitly switched.

5. Migration + backward compatibility

• Provide a migration path from current single-profile users to a default primary profile.
• Keep existing users functional without manual setup.

Acceptance Criteria

• A signed-in user can create at least one dependent profile and switch between profiles.
• Medication/appointment/log/document operations are isolated to the active profile.
• Calendar and notifications can be filtered by profile with no data leakage.
• RLS tests verify cross-profile reads/writes are denied.
• Chatbot actions execute only for the active profile context.
• Existing single-profile users are automatically mapped to a default profile after migration.

Non-Goals

• Full cross-household collaboration network.
• Insurance or billing-family account logic.
• Public profile sharing links.

Dependencies / Risks

• Cross-cutting schema changes across supabase/ and mirrored database/ SQL surfaces.
• High regression risk in pages with broad data assumptions (dashboard, calendar, reminders, chatbot actions).
• Requires strict validation in web/lib/* query builders and API routes to avoid context bleed.

Open Questions

• Should household owners be able to grant limited profile-level access to secondary caretakers?
• Do notifications default to active profile only or aggregated household feed?
• Is dependent profile identity limited to first name + birth year for privacy-by-default?