Created July 29, 2026 · Version 1.0

From working foundation to both app stores.

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.remii Stack: Expo 57 · React Native · Firebase Owner: Dave / Krampus Limited Design: 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.

Expo mobile appiOS + Android · one codebase
Firebase AuthParent + child email/password
Firestore + StorageHousehold records and files
Callable FunctionsChild identity, AI, billing webhooks
Security RulesDefault deny · household membership
+
FCM / NotificationsRequests, chores, events, reminders
+
AI providerServer-side tools · confirmations
+
RevenueCatHousehold subscription entitlement

Execution phases

Ordered by dependency. Checkboxes are saved to the shared backend and drive the progress meter for everyone.

CompleteNextLaterRelease gate
00

Current baseline

The verified foundation already in the repository.

CompleteJuly 29
OutcomeA real Expo 57 app that visually matches the approved prototype and compiles for both platforms.
EvidenceESLint, TypeScript, Expo Doctor, iOS simulator, Android/iOS bundles, browser interaction checks.
Alex
Build
Build
Build
Build
Build
Alex
Build
01

Production identity & Firebase foundation

Separate Dave-owned cloud and store identity before product data exists.

Week 1Critical path
Exit gateBoth dev builds boot against a separate Remii Firebase project with emulator-backed rules tests and no private key in the mobile bundle.
Commit rhythmIdentity → Firebase client → emulator/rules → EAS profiles → CI, each as a verified commit.
Dave + Alex
Alex
Alex
Build
Build
Build
Build
Build
Alex
Build
Build
Build
02

Household identity, roles & child accounts

The security model every later feature depends on.

Backend smoke completePhysical-device matrix deferred
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
Build Parent-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.
Build Parent-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
Build RED-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.
Build All 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
Build Parent-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.
Build RED-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.
Build RED-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.
Build Parent-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
Build Child 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.
Build RED-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.
Build Emergency 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
Build Hostile 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.
Build Handler 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.
Build Export 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.

#ScreenProduction behaviorPrimary dataNative / external dependencyTarget
1HomeCurrent shell existsLive household summary, schedule, requests, chores, notices, announcementsCross-domain projectionsPush deep linksWeek 4
2CalendarCurrent shell existsInternal events, recurrence, assignment, reminders, conflicts, filterseventsOptional device calendarWeek 4
3GroceryCurrent local interactionRealtime list, categories, quantities, favorites, history, child requestsgroceryItems, groceryRequestsBarcode scan, pushWeek 4
4ChoresCurrent local interactionRecurring assignments, proof, approvals, rewards, wallet ledgerchores, completions, walletEntriesCamera, pushWeek 4
5MoreCurrent tile indexRole-filtered navigation and accurate live status for every moduleCross-domain countsNoneWeek 4–7
6FamilyHousehold roster, invitations, roles, important dates, removalmembers, invitationsShare linksWeek 2–4
7MemberProfile, permissions, credentials, preferences, Kid Mode contextmembersPhoto pickerWeek 2–4
8School HubSchools, teachers, classes, assignments, activities, files, remindersschoolItemsFiles, calendar, pushWeek 5
9Document VaultSecure upload, categories, preview, expiration, access, deletiondocuments + StorageCamera, filesWeek 7
10Home MaintenanceAssets, recurring service, warranty, contacts, costs, historyhomeAssets, maintenanceTasksCamera, pushWeek 5
11VehiclesProfiles, registration, insurance, mileage, service and remindersvehicles, vehicleServicesCamera, pushWeek 5
12Bills & ExpensesRecurring bills, due/paid state, month view, owner, remindersbillsPushWeek 5–6
13SubscriptionsHousehold services, renewal, price, cancellation notes, alertshouseholdSubscriptionsPushWeek 6
14Medical CenterMember-scoped organizational records, providers, appointments, filesmedicalRecords + StorageFiles, calendar, pushWeek 7
15Pet CenterProfiles, care, medications, appointments, supplies, recordspets, petCareCamera, calendar, pushWeek 6
16Vacation PlannerTrips, itinerary, bookings, packing, files, travelers, countdownstrips, tripItemsFiles, calendar, locationWeek 6
17Gift PlannerPrivate ideas, occasions, budgets, purchase/wrap stategiftsShare sheet optionalWeek 6
18Family TimelineMemories, photos, dates, people, captions, visibilitymemories + StorageCamera, media libraryWeek 6
19Emergency ModeSelected contacts/info, offline availability, explicit activationemergencyProfilePhone, maps, offline cacheWeek 7
20PlansReal products, household entitlement, purchase, restore, manageentitlementsRevenueCat, storesWeek 9–10
21ChatAuthorized cross-domain answers and structured actions with confirmationauthorized domain reads, AI receiptsAI FunctionsWeek 8–9

What “100% feature complete” means

This is the finish line—not “all screens render.”

Product completeness

  • All 21 prototype routes exist in the native app and preserve approved design/behavior.
  • Every advertised action is real; no dead tiles, fake sync, or demo-only success.
  • Home and Remii unify the entire household rather than acting as isolated apps.
  • Mom, Dad, and child can complete intended journeys on their own devices.

Identity & authorization

  • Separate email/password identities with parent-managed child credentials.
  • Household and role authorization enforced in Rules/Functions—not only UI.
  • Parent act-as-child is clearly labeled and keeps actor/effective attribution.
  • Cross-household access is denied and emulator-tested for every collection.

Data & reliability

  • Realtime multi-device updates, offline behavior, retries, and rollback are tested.
  • Uploads and sensitive records follow least privilege, retention, export, and deletion.
  • Firebase config, indexes, rules, functions, secrets, budgets, backup, and recovery are documented.
  • No private credential ships in the app or repository.

AI & billing

  • Remii reads only authorized data and uses server-side structured tools.
  • Sensitive AI actions require confirmation and produce audit receipts.
  • Subscriptions purchase, restore, renew, expire, refund, and switch accounts correctly.
  • Children cannot access billing or parent-only data through UI, API, or AI.

Quality & compliance

  • Lint, strict TypeScript, tests, Rules/Functions emulator, Expo Doctor, and EAS builds pass.
  • Critical Maestro journeys pass on iOS and Android store-like builds.
  • Privacy policy, terms, deletion, child-data handling, medical positioning, Apple labels, and Google Data Safety match the code.
  • Accessibility and low-end Android performance meet release criteria.

Deployment & ownership

  • Apple App Store status is Ready for Sale and Google production release is available.
  • Fresh live-store installs pass auth, sync, notifications, files, AI, and purchase smoke tests.
  • 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.

Short videos: export as GIF under 5 MB

Previous reports