platepilot

User flows

Status and principles

Onboarding, photo/manual meal logging, water entry, Today, day history, and offline recovery are implemented locally through M1 Task 7. Planning, household, subscription, and full settings flows remain specifications.

• Adults only (18+); no child or dependent path.
• General wellness only; no diagnosis, prescription, emergency, or guaranteed outcome.
• Manual entry is a first-class path, not a degraded experience.
• Automated estimates remain provisional until reviewed.
• One adult’s private data is not exposed merely because they share a household.
• Offline, pending, provisional, confirmed, and failed states use distinct labels.

Onboarding

1. Adult opens PlatePilot and reads a short purpose statement.
2. Adult confirms they are at least 18. If not, stop onboarding without creating a profile.
3. Show the wellness disclaimer and a plain-language privacy summary.
4. Explain metadata stripping, immediate raw-quarantine deletion, the 1-day fallback for quarantine/ and sanitized processing/ objects, optional 365-day diary/ retention, and provisional analysis.
5. Adult chooses units and simple or detailed presentation. The choices are stored securely for that adult, restored after restart, and never reused for another adult.
6. Adult may skip optional preferences and reach an empty Today view.

Exceptions: interrupted onboarding resumes without duplicating consent; network failure preserves only non-sensitive local choices; consent versions are recorded only after server identity exists.

Photo meal

1. Adult selects Log meal then Use a photo.
2. Explain camera/library permission immediately before the platform prompt.
3. Adult captures or selects an image, reviews it, and can crop the current image, choose another library image, retake with the camera, or remove it. Crop never silently reopens the library.
4. Adult sees that the API deletes the raw upload after creating a metadata-free processing copy, with a 1-day lifecycle fallback, and may explicitly choose 365-day sanitized diary retention.
5. If online, upload and analysis proceed asynchronously; the diary remains usable. Once a job ID exists, navigation may remove the app-owned image while preserving the encrypted job handle.
6. Today and History show an adult-scoped pending record with check, cancel, and retry rules plus an Enter manually instead action in the photo flow.
7. On completion, show source and a clear Estimate—review before saving label.
8. Adult edits, removes, or adds items, then confirms the meal.
9. If analysis fails or times out, preserve the adult’s draft and offer retry or manual entry.

Privacy edge cases: remove unnecessary metadata; never show a public object URL; warn before leaving an unsubmitted image on a shared device; retain the preview when that warning is cancelled; copy picker output into a dedicated app-owned temporary directory before processing; sweep that directory on startup and sign-out; delete app-owned camera, sanitized, and cropped copies on replacement or discard; never delete the adult’s original library asset; do not silently change retention after upload.

Manual meal

1. Adult selects Log meal then Enter manually.
2. Choose recent/custom entry or, in a future adapter, search a food-data source.
3. Enter an amount and unit; do not require calorie or macro targets.
4. Add more items, review the record, and save.
5. Show whether the record is local, pending sync, or synced.

Provider search outage must not block custom entry. Corrections preserve provenance without shaming language.

Water

1. Adult selects a preset amount or enters a custom amount.
2. Show the selected unit and a reversible confirmation.
3. Update Today when locally accepted; distinguish pending sync.
4. History allows the owning adult to edit or remove an accidental entry.

Do not diagnose dehydration or present a universal target as medical fact.

Dashboard

1. Today opens with the adult’s own date and unit preferences.
2. Show meals, water, pending work, and plans using neutral summaries.
3. Adult can switch simple/detailed presentation.
4. Selecting a saved record opens its full editor with its public ID and current server version. Today and History show textual source and provisional/confirmed labels and expose conflict-aware edit/delete controls. Edit/delete are disabled with a textual reason while the target operation is pending, retrying, or conflicted. A newly confirmed local water entry can be undone only when doing so cannot enqueue a guaranteed-stale command.
5. Household summaries appear only where an explicit sharing rule allows them.

Empty and partial days are normal. Avoid streak pressure, red failure states, or “good/bad day” scoring.

Planning

1. Adult opens Plan and selects a date or week.
2. Add a custom planned meal or copy an adult-owned prior item.
3. Move, edit, replace, or remove the plan item.
4. At log time, confirm what was actually consumed; do not auto-convert a plan into a diary fact.
5. Shared planning requires an explicit household sharing setting and identifies the author.

Plans are organizational suggestions, never prescriptions.

Household

1. An authenticated adult chooses Invite an adult and sees what can and cannot be shared.
2. Create a single-use, expiring invitation for one other adult; do not expose diary data in the invitation.
3. The second independently authenticated adult reviews and accepts or declines.
4. Both adults can inspect current sharing settings and membership.
5. Either adult can revoke optional sharing or leave, subject to clear handling of genuinely shared records.
6. High-risk actions—export, deletion, credentials, subscription ownership—remain per adult unless a separately documented rule applies.

The product must not reveal one adult’s raw photos or private diary by default. Safety research must test coercion, ambiguous ownership, and post-separation access.

Subscription

1. Explain trial allowance before starting: target policy is 30 analyses during trial.
2. Explain paid allowance and renewal terms before purchase: target policy is 300 analyses per household per month.
3. Use the approved platform/provider purchase flow.
4. Verify entitlement on the server before enabling paid analysis.
5. Support restore and manage actions and show pending/provider-outage states.
6. If entitlement cannot be verified, preserve existing records and manual entry; do not fabricate active status.

Allowances are policy targets pending implementation and commercial/legal approval.

Settings

1. Adult can change units, information density, appearance, accessibility preferences, and future notification choices.
2. Privacy area explains photo retention and applies changes prospectively unless a separate deletion action is confirmed.
3. Household area shows membership and sharing.
4. Subscription area shows server-verified status.
5. Data area starts per-adult export or deletion with re-verification and an impact summary.
6. About/help shows the adult-only wellness disclaimer, data-source provenance, app version, and support route.

Offline and recovery

The Task 7 mobile flow uses the encrypted local command queue, keeps pending/failure/conflict states visible, and preserves manual fallback. It implements these requirements:

• Allow safe local drafts where platform storage has been reviewed.
• Never imply a server-side save while offline.
• Queue idempotent commands with visible status.
• Apply the same acknowledgement path during immediate saves and cold-start replay: acknowledged creates/updates retain the entry with canonical server data/version, while acknowledged deletes remove it.
• Replace failed meal, water, and photo creates atomically at the original queue position.
• Replay due commands after connectivity restoration, app foreground, and the earliest retry deadline; sign-out removes the session listeners and timers.
• Resolve cross-adult conflicts explicitly rather than using last-write-wins.
• Keep replacement operation identity attached to the visible entry through retries and repeated conflicts; a missing stale operation is never presented as synchronized.
• Keep manual entry available when photo analysis, food search, billing, or notification providers fail.
• Persist only safe, strict UI metadata with commands; corrupt persisted metadata blocks recovery rather than being ignored.
• On permanent authentication failure, offer only a confirmed Discard local data and sign out action. Do not label destructive sign-out as reauthentication or promise the operation will resume.

Same-adult token renewal and delayed reauthentication remain future requirements.