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