Skip to main content

Self-governed household modes — single-user & peer/friends (DEFERRED — research note)

Status: DEFERRED — captured for future reference + research. Not in scope for MVP. Date: 2026-06-25 Related: [rewhaven-member-roles-and-goals memory], docs/decisions/2026-06-22-northstar-poc-domain-gaps.md, the auth/identity post-MVP notes, North Star "fade to intrinsic motivation".

The idea (pin this discussion)​

Today Rewhaven assumes a parent-governed household: a parental member (MemberKind.isParental) gates the human-in-the-loop steps — approving chore completions, approving requested goals, granting roles — and zero-trust RLS is split into member_household_ids() (any member) vs parental_household_ids() (parents only).

The user wants two self-governed variants documented as future directions. Both stay an extension of the existing household (same economy, rooms, catalog, zero-trust scoping) — what changes is the governance model: there is no parent/child authority gradient; members govern themselves (and/or each other) as peers.

  • Single-user mode — one self-governing user. A personal token-economy / habit space: you set your own goals, define your own chores/bounties, and there is no separate approver. Plausibly the natural graduation state of the North Star "fade to intrinsic motivation" (a teen/adult who has internalized the loop and no longer needs an external approver).
  • Peer / friends mode — a small group of friends (or roommates, or an adult co-op) sharing one household. All members are self-governed peers: no parental gate. Governance is mutual or self — e.g. peer endorsement, mutual approval, or no approval at all (auto). Think shared-accountability group, not a family.

Why defer​

  • The whole approval/goal/RLS stack currently encodes the parental gate. A self-governed mode is a cross-cutting governance change, not a feature add.
  • MVP is the family case; single-user and peer are adjacent markets, not the core wedge. Documenting now (cheap) keeps the door open without diluting MVP.

Open research questions (the meat for a future spec)​

  1. Who approves? Invariant 4 (human-in-the-loop) routes completions through an Approval. Single-user ⇒ self-approve (the existing ApprovalPolicy.auto is a likely seam — every chore auto-approves). Peer ⇒ self-approve, any-peer approve, or quorum? Decide per-mode defaults and whether they are configurable.
  2. Goals. requestGoal → approveGoal is parental. Self-governed ⇒ goals are created already-active (no request step), or peer-endorsed. The GoalStatus.requested state may be unused in these modes.
  3. Roles vs kinds. Current split: MemberKind (relationship, immutable) vs MemberRole {admin, helper, member} (permissions) vs MemberStatus. In a peer house everyone is effectively admin/member with no isParental relationship. Does "self-governed" become a household-level mode flag, or is it emergent from "all members are admins / none are parental"? A mode flag is cleaner and avoids overloading MemberKind.
  4. Zero-trust / RLS. Still household-scoped (extension of the house), so member_household_ids() policies hold. But parental_household_ids() gates lose meaning — they must either no-op (every member is "parental" in a self-governed house) or be replaced by a mode-aware policy. Needs a migration story; keep the policy functions mode-aware rather than per-household-hardcoded.
  5. Token economy semantics. Does a self-governed economy still issue/spend tokens, or does single-user mode lean toward streaks/intrinsic tracking with tokens optional? Ties directly to the fade-to-intrinsic thesis — research whether single-user is "tokens off by default."
  6. Identity / accounts. Peer mode ⇒ several accounts, each auth_user_id linked to its own member profile (the existing linkAccountToMember / account-first path). Invites become peer invites, not co-parent invites (relates to the deferred co-parent OAuth-scope work).
  7. Onboarding & positioning. Single-user (personal habit tracker), peer (friends/roommates accountability co-op), family (parent-child) are three distinct onboarding flows and value props from the same core. Market research: which adjacent segment is worth a real flow first.

Architectural touchpoints (where a future implementation would land)​

  • SDK: ApprovalService / ApprovalPolicy (self/auto-approve), EconomyService goal lifecycle (skip requested), a household-level governanceMode field.
  • Schema/RLS: mode-aware parental_household_ids() (or a governance_mode column on households consulted by the policy functions).
  • App: mode-specific onboarding + hiding the parent-only surfaces (approval queue, goal-approve) when self-governed.

Next step when revived​

Brainstorm → spec a single governanceMode { familyGuardian, peer, solo } on the household, with per-mode approval/goal/RLS behavior, rather than three forked codebases. Single-user and peer are then two values of one axis, not two features.