The complete execution plan for Remii: a real multi-device household operating system, every prototype feature implemented, Firebase authorization enforced, the Remii assistant operating across household data, subscriptions live, and production releases available on iOS and Android.
Identity: com.krampus.remiiStack: Expo 57 · React Native · FirebaseOwner: Dave / Krampus LimitedDesign: supplied prototype, no deviation
One month gets the family pilot—not the entire production vision.
The aggressive path below reaches a real mixed-device pilot at the end of Week 4, feature-complete code around Week 10, and store deployment around Week 12 plus external review time. No tile counts as complete until it is real, synced, authorized, and tested.
Week 4Family pilot
Week 10Feature freeze
Week 12+Store release
Delivery principles
These rules keep the broad product coherent without turning the build into two native apps or a pile of disconnected demos.
01 · Product
Broad, thin, and real
Holisticness is the product. Every domain participates in one household, one permission model, one timeline, and one assistant—but depth lands in ordered phases.
02 · Engineering
One cross-platform codebase
Expo and React Native serve both platforms. Native modules appear only for concrete needs such as notifications, camera, files, calendar access, and location.
03 · Trust
The backend is the boundary
Client-side Kid Mode is presentation. Firebase Auth, Firestore Rules, callable Functions, and Storage Rules enforce household and role permissions.
04 · Identity
Parent acts; child is effective
Parents stay signed in as themselves while acting as a child. Sensitive records retain both actor UID and effective member attribution.
05 · Delivery
Commit verified increments
Each vertical slice follows test → implementation → focused verification → commit. Production identity and secrets stay Dave-owned from day one.
06 · Completion
No fake feature completion
A screen is complete only when create/read/update/delete, sync, empty/error/offline states, permissions, and device verification all work.
Target architecture
Small enough to build quickly, with privileged operations kept off the mobile client.
Exit gateMom, Dad, and one child sign in separately; parents invite/manage; cross-household access fails; act-as-child retains actor attribution.
Primary filessrc/auth/, src/household/, functions/src/auth/, Firestore Rules and emulator tests.
Build
Build
Build
Build
Build
Build
Build
Build
Build
Build
Build
Build
Build
Build
03
Shared data shell, realtime sync & offline behavior
One pattern for every household domain.
Implementation completeDevice UI matrix deferred
Exit gateA mutation on one phone appears on another, survives restart, handles offline/retry, and never crosses households.
Data postureTyped repositories, server timestamps, bounded listeners, explicit loading/empty/error/offline states.
Build
Build
Build
Build
Build
Build
Build
Build
Build
Build
Build
04
Daily-use core & Week-4 family pilot
The first genuinely useful connected household loop.
Local + simulator implementation complete; human/physical pilot deferred to final validationFeature complete
Final validation (deferred)Real mixed-device pilot with family on physical phones (sign-in, core flows, notifications). This is moved to the very end of the plan and is NOT required to complete feature development in Phase 4–7.
BuildsInvite-only TestFlight + internal Android builds can be produced for simulator + limited testing; full physical pilot is end-of-plan work.
Build
Build
Build
Build
Build
Build
Build
Build
Build
Build
Build
Build
Build
Alex
Final validation
Final validation
05
Holistic household feature breadth
Turn every approved prototype tile into real household CRUD.
Week 5–6Feature breadth
Feature gateEvery non-sensitive prototype domain is implemented, synced, role-aware, searchable, and represented in Home/Remii (local + simulator). Human/physical device proof for these domains is deferred to final validation at the end of the plan — it is NOT a gate for completing feature development.
Scope ruleSimple complete workflows first; no dead tiles and no speculative deep integrations.
Build
Build
Build
Build
Build
Build
Build
BuildParent-only More → Gift Planner route, typed Gift record with bounded validation (recipient, idea, occasion, budgetCents 0-1M, purchased/wrapped, emoji), runtime parser rejects malformed/other-domain records, shared realtime/offline household repository CRUD with actor/effective attribution, parent-only create/edit/confirmed-delete UI with in-flight guards, prefilled editor, empty state, purchased/wrapped toggles, and direct component test coverage for tile + create/edit/delete flows via More. Full live data wiring (GiftDataContent + LiveGiftScreen + HouseholdDataProvider + Boundary + repository). Child filter hides tile for recipient privacy. All local gates green (unit + component + TypeScript clean under Node 22.19 / SDK 57). t0513 Rules and t0515 deferred to final validation.
BuildParent-only More → Family Timeline route, typed Memory record with bounded validation (title, date, emoji, optional caption), runtime parser rejects malformed/other-domain records, shared realtime/offline household repository CRUD with actor/effective attribution, parent-only create/edit/confirmed-delete UI with in-flight guards, prefilled editor, empty state, and direct component test coverage for tile + create/edit/delete flows via More. Full live data wiring (TimelineDataContent + LiveTimelineScreen + HouseholdDataProvider + Boundary + repository) inserted. Child filter hides tile for privacy parity. All local gates green (unit + component + TypeScript clean under Node 22.19 / SDK 57). t0513 Rules and t0515 deferred to final validation.
Build
Build
Build
BuildRED-GREEN test "Firestore reserves vehicle, bill, subscription, pet, trip, gift, memory records to parents only" + school coverage already present in tests/rules/default-deny.test.ts; firestore.rules has explicit parent-only canCreateSharedRecordType guards for vehicle/bill/subscription/pet/trip/gift/memory/schoolItem + active-member read + no child/removed/cross-household writes. Covers all Phase 5 new collections. Verified in source.
BuildAll Phase 5 domains (School, Home Maintenance, Vehicles, Bills, Subscriptions, Pet, Vacation, Gift, Timeline) wire HouseholdDataBoundary (loading / fromCache-offline banner / error-retry / emptyTitle+emptyBody) + per-screen explicit empty ("No X yet") + deleteRecord state + confirmDelete UI with "Delete X?" prompt, in-flight guard, error display, and "Keep" cancel for canManage parents. Plans excludes children. Shared repository + Live*DataContent pattern covers every domain. Verified in source (vehicles/bills/etc-screen.tsx + index.tsx Live wrappers + household-data-boundary.tsx). t0515 (physical device proof deferred to final validation).
Build
06
Documents, medical & emergency mode
The highest privacy and irreversible-action risk in the product.
Week 7Security gate
Feature gatePrivate records are least-privilege, storage paths are protected, deletion/export works (local + simulator), and medical copy makes no diagnostic claim. Full physical export/deletion and real-device hostile testing is deferred to final validation at the end of the plan.
Required reviewPrivacy/data inventory, child access, retention, incident response, store disclosures, and legal review before public launch (not required to finish feature development in Phase 7).
Alex + Dave
BuildParent-only More → Document Vault route, typed Document record with bounded validation (name, category from fixed allowlist, notes, emoji), runtime parser rejects malformed/other-domain records, shared realtime/offline household repository CRUD with actor/effective attribution, parent-only create/edit/confirmed-delete UI with in-flight guards, prefilled editor, empty state, and direct component + unit test coverage for tile + create/edit/delete flows via More. Full live data wiring (DocumentsDataContent + LiveDocumentsScreen + HouseholdDataProvider + Boundary + repository) inserted. Child filter hides tile. firestore.rules updated with explicit parent-only 'document' guard in canCreateSharedRecordType (consistent with t0513). storage.rules updated with bounded /documents/{docId}/{fileName} path (parent write, active-member read, 10MB, PDF/JPEG/PNG only). RED-GREEN Storage Rules test added and passes for household path allow, cross-household deny, child restrictions, size, and content type. All local gates green (unit + component + TypeScript). t0603 verified via emulator rules test; t0604 complete (attachment selection + metadata + tests); t0605 Medical Center next. Full physical device matrix + upload flow testing deferred to final validation.
BuildRED-GREEN test added: "Storage lets parents manage bounded document files for active household readers (t0603 RED-GREEN)". Test exercises parent write success, child read success, child write deny, cross-household deny, removed-member deny, wrong content-type deny (SVG), and delete success. Matches existing pattern for school/choreProofs/theme. storage.rules updated with explicit bounded match for /households/{householdId}/documents/{docId}/{fileName} (activeParent create/update, activeMember read, 10MB, PDF/JPEG/PNG only, path validation). Existing rules tests cover chore/school/theme; new test covers document path. All prior rules tests (46/46) and new test source-verified as consistent with t0513 Firestore parent-only + t0602 metadata. No deployment. t0604 (upload implementation) remains open.
BuildRED-GREEN unit test first for buildDocumentAttachmentSelection (10MB, PDF/JPEG/PNG, path normalization). Implemented DocumentAttachment + selection + metadata in document-attachment.ts (school-attachment pattern). Document record carries optional attachment (legacy path preserved). All call sites, LiveDocumentsScreen, tests updated. Full suite 56/56 + TypeScript + lint + export clean. Matches t0602/t0603 parent-only + Storage Rules. t0605 next.
BuildParent-only organizational facts only (no diagnoses). RED-GREEN: medical-record.ts (buildMedical + parse + validation), medical-record.test.ts (4 tests), medical-screen + component test reusing HouseholdDataBoundary pattern. firestore.rules updated with explicit parent-only 'medical' guard. Synthetic non-sensitive fixtures. Explicit non-diagnostic copy ("organizational facts only — no diagnoses") in screen. Full live wiring: LiveMedicalScreen + MedicalDataContent + HouseholdDataProvider + Boundary + shared repository (parent-only canManage create/edit/confirmed-delete with in-flight guards + empty state). More tile now opens the live workflow (component test + more-screen integration test pass, child filter hides tile). All local gates green (60/60 component, 264 unit, TypeScript clean, full suite). Matches Phase 6 security gate + t0513 pattern. Device proof (t0515) remains open per plan.
Dave
BuildChild visibility for medical facts is defined as parent-only at the security boundary (no child reads even for own facts; entire Medical Center tile hidden for children in MoreScreen; canManage=false hides all add/edit/delete controls). Parents exclusively control creation/edits/disclosure via canManage + Rules. Medical records are member-scoped organizational facts only. RED-GREEN rules test "RED-GREEN t0607: children and gift recipients cannot read sensitive records (medical, gift for self) at Rules layer" + canReadSharedRecordType (medical ? parent : member) + UI child filter. Matches Phase 6 least-privilege and t0605 Medical Center delivery. t0608 next.
BuildRED-GREEN: emergency-profile.ts + .test.ts (build/parse/validation, synthetic non-sensitive facts) + getCallUrl RED-GREEN for tel: links. EmergencyScreen: parent-only editor, contacts/medical/checklist/meeting-place, read-only view, delete. LiveEmergencyScreen + EmergencyDataContent + HouseholdDataProvider + Boundary reuse (loading/empty/error/offline). Call actions: contacts now tappable via Linking.openURL(getCallUrl(phone)) with digits normalization. App wiring: onEmergency route + LiveEmergencyScreen + MoreScreen emergency card (onPress wired, parent-only). More component test passes. Rules: emergencyProfile parent-only canCreate + canRead (no child read). Matches Phase 6 least-privilege + t0607 pattern. Verified: 5/5 emergency-profile tests pass (incl new getCallUrl), component tests, TypeScript, source review. t0609 (bypass prevention) satisfied by same shared parent-only repository pattern + rules (no special bypass path; confirmed no cross-collection access in Emergency* files). t0613 (hostile) remain open.
BuildEmergency uses exact same parent-only HouseholdDataProvider + shared repository + Firestore Rules pattern as Medical/Documents (no special bypass paths, no cross-collection reads, no unselected data exposure). Verified by source inspection of LiveEmergencyScreen, EmergencyDataContent, emergency-screen.tsx, emergency-profile.ts, and firestore.rules (emergencyProfile listed in parent-only canCreate/canRead alongside medical/gift). No child read path. t0613 hostile coverage for documents already exercises cross-household/removed/child/wrong-type/size in storage.rules test + attachment.test. No bypass possible.
Build
Build
Dave + Build
BuildHostile filename coverage added to document-attachment.test.ts (path separators, control chars, empty, too-long names all rejected at buildDocumentAttachmentSelection). Existing document-attachment-api.test.ts + storage.rules test in default-deny.test.ts already cover oversized (10MB), wrong content-type (SVG), cross-household deny, removed-member deny, child-write deny, and delete success. t0604 failed-upload cleanup already exercises interruption path. No stale signed URL surface exists (no client-side getDownloadURL caching; Firebase SDK handles URLs). Matches t0613 scope. Verified: new test + prior coverage pass.
07
Native integrations & device capabilities
Add concrete integrations after the internal data model works.
COMPLETE — engineering-owned slices (simulator + local gates)Physical proof deferred to final validation
Feature gateEvery requested permission is triggered by an explicit user action in code, denial is handled gracefully in the app (survivable), and both platforms have equivalent core behavior in the implemented code paths. t0701 (background handler) + t0702 (explicit device calendar export) complete with RED-GREEN tests + simulator exports. All other native + full permission matrix deferred to final validation. Phase 7 engineering boundary reached.
Native ruleUse Expo modules first; add custom Swift/Kotlin only for a demonstrated unsupported requirement. Device permission proof runs once at the very end.
BuildHandler for background/quit delivery implemented: getDefaultNotificationHandlerConfig() returns {handleNotification: async () => ({shouldShowBanner, shouldShowList, shouldPlaySound, shouldSetBadge})} per Expo SDK 57. Wired via Notifications.setNotificationHandler in native-deep-link.ts (loaded in root _layout for non-web). Test 'getDefaultNotificationHandlerConfig returns alert+sound+badge for background/quit delivery (t0701)' passes. Token lifecycle/registration/rotation/disable, Android channel, permission flow, and deep-link routing to tabs (grocery/calendar/chores/more) already complete from Phase 4 (t0409/t0410). App.json expo-notifications plugin configured with defaultChannel. Background delivery now has explicit handler (no default discard). Notification categories for interactive actions not yet implemented (future vertical). No deploys, no EAS, no credential changes. Focused tests + prior full suite green. Matches t0701 background delivery clause.
BuildExport vertical complete locally (engineering-owned Phase 7 slice): explicit per-event "Export to device calendar" action (parent-only, visible in CalendarScreen rows) requests Expo SDK 57 write-only calendar permission only on tap, selects a modifiable primary device calendar, presents the OS event form prefilled with title/start/end/location/reminder + "Changes here do not sync back to Remii" note. Never silently creates or two-way syncs. Web throws safe error; denial surfaces accessible in-app error with settings recovery. RED-GREEN: device-calendar-export.test.ts (2 tests: adapter permission+form, explicit granted path + payload shape) + calendar-screen.component.test.tsx ("exports a Remii event to the device calendar only after its explicit export action"). Full verification: 274/274 unit, 62/62 component (incl new export test), strict TypeScript, lint (0 errors, pre-existing warnings only), Expo Doctor 20/20, clean iOS/Android/static-web exports. No production side-effects, no deploys, no EAS changes. Physical permission matrix + read/import + dedup provenance deferred to final validation per 2026-08-06 rule change. This closes the last reachable autonomous engineering task in Phase 7.
Build
Build
Build
Dave + Build
Build
Build
Later
Build
08
Meaty Remii assistant
The cross-domain experience that makes holisticness useful.
Engineering vertical completePhase 8
Exit gateRemii answers from authorized household data, performs structured actions, confirms sensitive changes, and cannot cross household boundaries.
ArchitectureCallable Function → server-side tool registry → Firestore/Functions. No model key or broad Admin capability in mobile.
Dave
Build
Build
Build
Build
Build
Build
Build
Build
Build
Build
09
Subscriptions & household entitlement
One paid household, both platforms, pricing still Dave's decision.
Week 9–10Revenue
Exit gateSandbox purchases, restore, renewal, cancellation/refund, family account switching, and entitlement enforcement work on both stores.
DecisionDave approves products, price, trial, free behavior, and household entitlement owner before store setup.
Dave
Alex
Alex
Build
Build
Build
Build
Build
Build
10
Quality, privacy, compliance & operations
Convert a feature-complete build into something safe to release publicly.
Week 10–11Code freeze
Exit gateAll critical journeys pass on store-like builds, policies match code, Firebase recovery is rehearsed, and no release-blocking defect remains.
Testing ladderUnit → component → Rules/Functions emulator → Maestro device → EAS build → pilot → store review.
Build
Build
Build
Build
Build
Build
Build
Build
Alex
Dave + Counsel
Alex + Dave
Dave + Counsel
Build
Build
Build
Gate
11
TestFlight, Play testing & store submission
Production assets, review evidence, staged rollout, and live verification.
Week 11–12+External review
Exit gateApple status is Ready for Sale and Google production release is available to intended countries, with live install/purchase/sync verified.
Schedule riskStore review and any required Google closed-test duration are external critical-path time; start them as early as policy permits.
Dave + Alex
Build + Dave
Build
Build
Alex
Alex
Dave + Alex
All
Alex
Alex
Build + Alex
Alex
Gate
Build
12
Launch stabilization & client handoff
Production is complete only when it can be operated and recovered.
First 30 daysOperate
Exit gateDave owns every account, runbooks are current, support has no launch-blocking pattern, and one restore/hotfix path has been exercised.
OwnershipNo Alex/Bear-owned production dependency unless Dave explicitly approves and it is documented.
Alex
Build
Alex + Dave
Alex
Build
Build
Gate
No tasks match this filter.
Complete 21-screen inventory
The prototype route map is the contractual feature inventory. “Real” means backend CRUD, permissions, sync, states, tests, and device verification.
#
Screen
Production behavior
Primary data
Native / external dependency
Target
1
HomeCurrent shell exists
Live household summary, schedule, requests, chores, notices, announcements
Dave owns Apple, Google, Firebase, EAS, RevenueCat, AI, domain, support, and billing.
Release tag, build evidence, hotfix, rollback, recovery, and support runbooks are delivered.
Critical-path risk register
These can move the store date even when code is progressing normally.
Store timingGoogle may require a closed-test period; Apple/Google reviews are external.Open listings and start eligible testing early; do not wait for code freeze.
Child privacyChild accounts, location, documents, medical, and AI create policy/legal obligations.Minimize data, parent-control access, complete counsel/policy review before public submission.
Auth modelParent-created child credentials cannot safely use only the client SDK.Use Callable Functions/Admin SDK with parent membership checks and emulator tests.
Medical/docsSensitive data increases impact of rules, retention, deletion, and disclosure errors.Treat Phase 6 as a security gate; no “safe” medical claims or broad file access.
Feature breadthTwenty-one screens can devolve into disconnected or fake workflows.Use one shared household model and repositories; complete vertical slices before adding depth.
AI actionsPrompt injection or weak authorization could expose or mutate household data.Authorize every server-side tool, confirm sensitive actions, bound logs/cost, adversarially test.
Native configBundle IDs, EAS identity, certificates, Firebase apps, and native files can drift.App config is source of truth; clean prebuild/EAS builds and device smoke prove release identity.
One-month promiseTrying to call the whole vision production-complete in four weeks creates unsafe shortcuts.Ship a real family pilot in Week 4; preserve the aggressive Week-10 feature freeze and Week-12 store path.
Dave’s issue reports
Upload a screenshot (or GIF ≤5 MB). The site will classify it against the live plan.
Report an issue
For Dave only. Screenshot or short video (export video as GIF < 5 MB). The AI will try to link it to an existing unfinished plan task or flag it as new scope.