docs: add project orientation notes
This commit is contained in:
Rijad Zuzo
@@ -0,0 +1,139 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user