Skip to main content

Roles & permissions

Status: 🔨 To build (SDK-ready)

Scope​

The role model (MemberKind ∈ {parent, coParent, otherAdult, child}, MemberRole ∈ {admin, helper, member}, the owner flag, MemberStatus) is defined and shipped in the SDK. This feature covers the Admin UI to assign and change roles, the invitation flow (email or link), and the SDK service methods (setMemberRole, inviteMember, etc.). The capability matrix is documented in Personas.

Roles + the owner flag are per-household membership. They live on the HouseholdMember record, so the same person can be admin in one household and a plain member in another. One subscription is per account (an account may manage N homes); the zero-admin / zero-owner guards are enforced per household.

Open questions​

  • Can an admin promote another member to admin without both having isParental kind? Deferred — MVP-1 keeps admin ⇒ isParental; non-parental admin is bound to self-governed mode (backlog HS-3).
  • What is the helper invite flow — full account registration or a time-limited link/PIN? (Deferred, backlog DF-1 — reuses the MemberAccess expiry window.)
  • Can a helper role expire (e.g. babysitter's access auto-revokes after 24 hours)? The MemberAccess expiry model exists in the SDK; the standalone time-boxed helper invite is deferred.

Resolved: the at-least-one-admin invariant is enforced (per household, in the service AND a schema trigger), alongside a zero-owner guard + transfer-ownership flow.

Relationship​

Personas — the access matrix lives there; this file covers the build surface.