ADR: "Sovereign Lifestyle Engine" expansion review — keep / reshape / kill

Date: 2026-07-18 · Status: Accepted (direction) · Type: strategy / roadmap guardrail. Records the outcome of a founder-proposed scope expansion ("Highly Leverageable Sovereign Lifestyle Engine": ZK P2P sync, a hidden adult intimacy track, AlternativeSensual avatar assets with a client-side "Modest Fallback", a Godot canvas, a deferred-jackpot economy, and a pre-launch three-product engine) and the reshaped, honest version we will actually pursue.

The one hard line (non-negotiable)

rewhaven ships DISCLOSED. No feature is concealed from app review or from the user, and no roadmap is staged to slip content past review after an all-ages install base exists. The proposed "Release 1 = The Mask → Release 3 = inject AlternativeSensual assets via R2 after review" sequence is rejected outright: it is a bait-and-switch that (a) is the textbook Apple 2.3.1 / Google deceptive-behavior ban trigger — developer-account level, not a soft reject; (b) routes adult assets onto the devices of children already using a chore app, with a client-side "Modest Fallback" as the only guard — which violates our load-bearing dual-gate rule (client-side gating is not a gate; a child with an APK extractor or view-source on the web build reaches the real assets); and (c) would permanently end the clinical/OT/COPPA brand the product's entire thesis depends on. This line holds regardless of how tame the underlying content is — tame content does not need a mask, so keeping the mask can only mean something is still being hidden.

Content clarification that reshaped the decision

The founder clarified the "intimacy track" is relationship-HEALTH check-ins + recommendations (connection check-ins, decompression / co-regulation routines, appreciation/affirmation prompts) — NOT explicit intimacy how-to. That is a mainstream wellness category (cf. Paired, Lasting, Gottman). Because it is tame, it can be built OPENLY, which removes the only justification the concealment machinery ever had. The sensual avatar cosmetics + body-proportion sliders are a SEPARATE decision from the relationship text and are cut from the core product (see below).

Decisions

KEEP — moves into the real roadmap

Item	Home / timing
Digital-twin room canvas (interactive rooms, avatar idle loops, multi-room "collage" for ND broad-task visualization) — the strongest idea in the proposal	Rive (not Godot), evolving the existing DsHorizonHouse + rooms model; post-companion. The multi-room collage is a real ND differentiator.
Therapist "Sovereign Clearance" sharing — expiring, scope-limited share tokens streaming specific routine-compliance data to an outside therapist without giving up DB ownership	Buildable on the CURRENT stack via RLS-scoped, time-boxed share tokens (no ZK needed). Strengthens the clinical channel. Near-term candidate.
Biometric / PIN adult gate	UX-layer defense-in-depth ON TOP of server enforcement, never instead of it. Already scoped as the kid-mode PIN follow-up.
Full-featured PG avatar creator — rich identity customization INCLUDING body proportions (height/build), skin, hair, face, outfits; child-appropriate defaults (2026-07-18 refinement: full customization breadth is fine at PG; the cut is sexualization, not breadth)	Rive state machines; feeds the companion/identity track. Does not move the age rating on its own (local, non-shared, PG).
E2EE user-owned backups (client-encrypted-at-enclave before leaving the device)	Compatible with today's architecture; real sovereignty story, cheap.
Parent Relationship-Wellness track (tame, disclosed)	Parent-only section behind the adult gate. See "reshaped" below.

RESHAPE

• Relationship-Wellness track: tame relationship-health check-ins + recommendations ONLY (no intimacy how-to, no metrics on sex acts, no sensual assets). Parent-profile + adult-gate gated. Disclosed to app review; honestly rated (likely bumps rewhaven to 12+/Teen — an app-store-counsel question on final content). Default: lives IN the one rewhaven app as a parent zone — NOT a second app and NOT hidden — precisely because it is tame. A partner "couple-connection" surface (date-night scheduling, decompression routines, partner appreciation/kudos) is on-brand family/co-regulation wellness.
• Local-first / privacy: we already ARE local-first (Drift write-through cache is the production design — keep executing). Adopt the shippable subset of the sovereignty vision (E2EE backups, therapist tokens). Do NOT rewrite to zero-knowledge — see KILL.

KILL (unsalvageable as proposed)

• "The Mask" roadmap + post-review R2 asset injection + client-side Modest Fallback substitution. Deceptive by construction; child-safety theater.
• Sexualized avatar layer — AlternativeSensual-tagged cosmetics (chokers, leather cuffs) and any body slider tuned/framed as titillation — inside the family product. Cut. Refinement (2026-07-18): full PG body-proportion customization (height/build as identity, non-sexualized) IS allowed — what is cut is the SEXUALIZATION, not the customization breadth (see the KEEP row). The client-side Modest Fallback is therefore moot: a PG avatar has nothing to hide. If a sexualized avatar layer is ever pursued, only as a separate, adults-only, honestly-17+-rated product — never smuggled into rewhaven, never via a shared binary.
• Zero-knowledge / blind-courier server rewrite. Deletes the security wall we just live-verified: RLS IS the enforcement (2026-06-12 topology ADR). A blind server cannot enforce the child-consent freeze, run the COPPA delete-if-no-consent reaper (it can't see who's pending), or stop a compromised client. ZK + children (key mgmt for a 7-year-old, VPC with a blind server, single-parent-phone recovery) is the hardest possible combo. The margin argument optimizes the wrong cost (Supabase is ~$0–25/mo at this scale; the scarce resource is build time). Park behind explicit revival triggers like rewhaven-services; the good parts (E2EE backups, therapist tokens, local-first) don't require it.
• Godot canvas / second game engine. Rive is already a design_system dependency with a researched companion art budget; Godot-in-Flutter is experimental interop, tens of MB of runtime, near-certain death for the web build (our only current deploy target), and a second art pipeline. Same visual dream, no new engine.
• Silent/deferred "Gold Rush" economy (FR-5) — track achievements silently, then unleash a historical-currency backlog. Inverts the dossier's strongest findings (immediate ADHD dopamine timing — we shipped Beat 1; the fade is a graduation you EARN, not a starting condition) and the currency windfall is textbook reward inflation that undercuts the fade-to-intrinsic MOAT. The correct version of the underlying instinct is the ADR'd 4-phase fade protocol. Silent internal ANALYTICS (measuring before surfacing) is fine.
• Pre-launch three-product "engine" hardening (TTRPG companion + story workspace on a shared core, before rewhaven has launched). Classic solo-founder trap: abstractions guessed for hypothetical product #2 tax product #1's velocity and are usually the wrong abstractions. The mappings are clever (room grid ≅ inventory grid; chore tree ≅ scene tree) — capture them in a vision doc, spend ZERO architecture on them, and EXTRACT the engine from product #2 when it exists (rule of three). What's already legitimately reusable — design_system, config-driven SDK, flow-test harness, guard-RPC house style — reuses as copied packages/patterns today at no extra cost.

Load-bearing principles reaffirmed

1. Dual-gate everywhere (service authz AND RLS). Child-safety must never rest on a client-side filter — the Modest Fallback proposal is the canonical anti-pattern.
2. Disclosure > cleverness. Anything an app store or user would be surprised to find is a defect, not a feature.
3. Ship the product before the platform. Reuse via patterns now; extract the engine from the second real product, not an imagined one.

Open follow-ups (not decided here)

• Exact age rating for the tame relationship-wellness zone → app-store counsel.
• Whether the relationship-wellness track is enough of its own thing to ever warrant a sibling app (default: no; it stays an in-app parent zone).
• Sequencing of the KEEP items into the engagement build order (therapist sharing + parent gate + E2EE backups are near-term; digital-twin rooms are post-companion).