Skip to main content

Onboarding + Invite + Account-Management Vision (owner brainstorm, 2026-07-22)

Status: Vision capture — needs a brainstorm → spec → phased plan before any build. NOT yet designed.

Origin: Triggered by a live bug — the More-tab "Join with an invite code" sheet only calls accept_invite (adult/email-bound), so a child attach code can't be redeemed there; and the code the owner tried was a stale/rotated one (child attach codes hash-rotate on every "Generate"). The accept/link cloud RPCs themselves work. The owner reframed the fix into a broader capability set.

The vision (owner's words, decomposed)​

  1. Invite-code-first onboarding (unify join into onboarding). After a Sign-up button → SSO/email sign-in, the FIRST onboarding page asks for an invite code — before asking for a household name.

    • No code (new user) → continue the normal new-household onboarding.
    • Enter a valid code → join the existing household and SKIP the rest of onboarding (no household creation).
    • This becomes the single entry for all invited users (co-parent, other adult, child) instead of separate surfaces.

  2. Share-link/code ↔ existing member binding. When generating a share/invite code, optionally associate it with an existing household member (a shadow profile) so the joining user is auto-linked to that profile on redemption. (Generalizes today's child-attach code to any member.)

  3. Multi-household membership + switching. A user may belong to more than one household (A and B). They must be able to switch between households (distinct from the existing within-household member switcher). Load-bearing architectural question — see below.

  4. Delete-and-merge. A user can delete a household they created and merge into another (consolidate when they created a stray household then joined a real one).

  5. Account/User-management admin. Expand the existing Roles & Consents page (/governance) into a full Account/User management surface where invites, member↔account linking, roles/consents, and switching are managed.

Immediate small fix (separable, may be superseded by #1): the More-tab sheet's generic "expired/mistyped" error is misleading for a child code; and the admin should show the current active code (with copy + last-generated) so users don't paste a rotated one.

The load-bearing decision — RESOLVED (owner, 2026-07-22)​

A single auth account belongs to MULTIPLE households (true multi-household membership). The owner confirmed this is already decided: "long-term a user can belong to multiple households. we already decided that." This is NOT a single-active-switch model — it is a real schema/identity change enabling capabilities #3 (switch between A and B) and #4 (merge). Today's More-tab sheet copy ("will make it your active household") reflects the old single-active framing and will need to change.

  • Membership is many-to-many (account ↔ household), not one-active-at-a-time. There is a currently-active household (the one the UI is scoped to) that the user switches, but membership persists across all their households.
  • Connects to prior post-MVP architecture thinking: kids.identity_id, the "divorce-clone with continuous kid identity", and account-linked roles (see [[homebase-post-mvp-architecture]]).
  • Still to design (not the model, but its mechanics): the membership schema (join table vs. account_id on member rows), how "active household" is stored/selected, how switching interacts with the existing within-household member switcher, and how delete-and-merge (#4) reconciles duplicated members/ledgers across two households. These are spec-time questions — the model (multi-household) is locked.

Sequencing note​

This is a multi-subsystem initiative (onboarding, invite/link, identity/multi-household, admin) — it needs decomposition into sub-project specs, each producing working software on its own. It is NOT a quick fix and should not be built blind. Interacts with: the catalog restructure (Phases C/D still queued), the COPPA gate (child self-signup NOT launch-ready — a child code in onboarding re-raises the VPC/consent gate, see [[rewhaven-coppa-legal-gate-deferred]]), and the add-an-adult admin-create path (already shipped/deployed).

Next step​

Brainstorm this as its own initiative — the multi-household model is now resolved (true multi-household membership), so brainstorming starts from that and focuses on membership schema, active-household selection, switching UX, and merge mechanics — then spec → phased plan. Sequenced AFTER catalog Phases C/D (owner, 2026-07-22).