rely/docs/client-audit-relationship-app.md

# Client Audit: Relationship Assistant App

Date: 2026-04-01

## Current implementation summary

The client is a Flutter app using Riverpod for state management and a single
`MaterialApp` rooted at `lib/main.dart`. Authenticated users land in a custom
shell with index-based navigation across dashboard, people, moments, signals,
ideas, reminders, sync, and settings.

The app is already local-first in practice. Product state lives in
`LocalRepository` and is persisted through a `LocalDataStore` abstraction with
Hive as the default backend and shared preferences as a fallback/migration
path. There is also background sync scaffolding, notification scheduling, and a
fake backend mode for offline development.

Share intake exists, but the implementation is narrow. Flutter-side logic
supports a WhatsApp-oriented share parser, source-link resolution, and a manual
share inbox. Native platform wiring is incomplete for production-grade cross-app
sharing, especially on iOS and likely also on Android for text share intents.

## A. Current implementation inventory

| Feature Area | Current State |
| --- | --- |
| Client technology | Flutter |
| State management | Riverpod (`Notifier`, `AsyncNotifier`, provider overrides in tests) |
| Navigation | Single `MaterialApp`, custom shell, route pushes for secondary flows |
| Local persistence | Hive by default, shared preferences fallback/migration |
| Auth | Local/fake-friendly sign-in flow with token-store abstractions |
| People list/detail | Implemented, responsive, searchable, editable |
| Person creation/editing | Implemented with validation and duplicate-name warning |
| Notes/profile context | Implemented as a single freeform notes field plus tags |
| Moments/captures | Implemented |
| Ideas | Implemented |
| Reminders | Implemented with local notification scaffold |
| Shared message history | Implemented per profile |
| Share intake | Implemented in Flutter, but WhatsApp-specific and not fully generalized |
| Share inbox | Implemented for unresolved profile matching |
| Source linking | Implemented for repeated source-to-profile matching |
| Preference inference | Implemented locally from shared chat text |
| Search/filtering | Implemented for people; limited elsewhere |
| Theming/design system | Implemented via `AppTheme`, custom frosted cards, responsive layouts |
| Tests | Good targeted widget/unit coverage, no true end-to-end native share tests |
| Backend sync readiness | Good scaffolding, still fake/offline-friendly |
| Privacy/trust UX | Limited; local-first behavior exists more in code than in user-facing copy |
| Cross-platform share viability | Partial; Flutter layer exists, native integration incomplete |

## B. Grading

| Feature Area | Status | Grade | Notes | Risk / Missing Pieces | Recommended Next Step |
| --- | --- | --- | --- | --- | --- |
| App architecture | Present | B | Clear enough separation between UI, local repository, sync, and integrations | Some large UI files, especially `PeopleView` | Add smaller share/fact modules instead of broad refactors |
| Local-first persistence | Present | A- | Hive-backed state with migration path and test coverage | Still JSON-in-Hive rather than richer queryable store | Keep current approach for this iteration |
| People management | Present | B | Good responsive UI, editing, duplicate warning, merge flow | Person model is too thin for relationship intelligence | Extend model with aliases, facts, dates, timestamps |
| Moments / history | Present | B | Useful local activity log | History is not yet strongly typed for preferences/dates/fact provenance | Add structured facts on top rather than replacing moments |
| Ideas / reminders | Present | B | Solid founder-mode utility already | Not tightly connected to share capture | Reuse future share classification to feed these areas later |
| Share intake pipeline | Partial | C | Flutter-side ingest and inbox exist | WhatsApp-specific, no generic text/URL pipeline, native wiring incomplete | Generalize payload normalization and improve clarification UX |
| Person resolution | Partial | B- | Exact/near-match logic and source links already exist | Resolution is tied to sender matching and not broader share assignment | Add explicit assign/create/save-to-inbox review flow |
| Inbox / triage | Partial | C+ | Resolves ambiguous source matching | Cannot yet classify into structured facts/dates/preferences | Add fact classification and later reassignment/edit support |
| Search / discoverability | Partial | C+ | People search/filter exists | No real inbox/fact/date search | Keep scope limited; prepare data for later search expansion |
| Privacy / trust UX | Weak | D | Local-first architecture exists | App does not clearly explain on-device storage or future AI sharing controls | Add clear local-first settings copy and sensitive-data affordances |
| Cross-platform share readiness | Weak | D | Plugin added, listener implemented | Android manifest missing share intent filters; iOS share extension not configured | Fix Android now, document iOS as deferred native work |
| Test posture | Present | B+ | Good unit/widget coverage for local repo and share inbox | Missing tests for generalized share parsing and structured triage | Add targeted parser/repository/widget tests |

## C. Product readiness assessment

### Solo founder daily use

Current usefulness is moderate. The app already supports keeping people,
captures, reminders, and ideas locally, which is enough for founder testing.
However, the most important real-world capture path, sharing snippets from other
apps, is not yet strong enough to rely on daily.

### Friction of data entry

Manual entry is acceptable. Cross-app capture still has too much friction
because it is optimized around one parser path instead of a general intake
flow. Ambiguous content can be saved, but not yet shaped into structured,
reviewable facts.

### Trust / privacy feel

The implementation is local-first, but the UX does not communicate that clearly
enough. For a relationship app, trust is part of the product. The app should
say what stays on device, what is not yet shared, and how users can correct or
delete imported facts.

### Extensibility for future LLM support

Reasonably good. The repository pattern, fake backend mode, and local inferred
preference signals create a workable foundation. The main gap is data shape:
profile context is still too flat, and shared content is not normalized into a
recommendation-ready structure.

### Cross-platform viability

Good at the Flutter layer, incomplete at the native share-entry layer. Android
needs explicit share intent wiring. iOS still lacks a real share extension.

### Likely adoption blocker

The biggest blocker is not “AI quality”; it is capture friction. If sharing a
snippet from WhatsApp, Safari, Notes, or Messages into the app is unreliable or
too manual, the product will not accumulate enough high-value context to become
habit-forming.

## D. Top implementation priorities

1. Generalize share capture into a platform-aware text/URL pipeline with a
   clear internal payload model and Android native entry wiring.
2. Add an inbox-first clarification flow that lets the user assign to an
   existing person, create a new person quickly, or save unresolved data for
   later.
3. Extend the local person knowledge model with aliases, structured facts,
   important dates, timestamps, and source traceability.
4. Upgrade the inbox from “resolve person only” to “triage into note / like /
   dislike / date / idea-ish fact”.
5. Improve privacy/trust wording and make correction paths more obvious.

## Recommended scope for this iteration

Implement a disciplined client-only slice:

- generic shared text / URL normalization
- Android text share intent support
- share clarification sheet for assign/create/inbox
- richer local fact/date models with provenance
- inbox triage into structured facts or important dates
- person detail UI for reviewing captured facts/dates
- targeted tests

Explicitly defer:

- native iOS share extension target work
- real backend sync of new fact/date entities
- real LLM or recommendation calls
- large navigation or persistence rewrites