Product Family Overview — "Life" Suite

Consolidation of two Claude-web briefs into one coherent program. Sources: briefs/organizer-brief.md (the Organizer, codename Lodestar) and briefs/nutrition-brief.md (the Nutrition/Body face, codename Repast). Names are placeholders.

This is the top-level map. It does not replace the two briefs — it states how they are one product family on one substrate, and fixes the build order.

1. The thesis (why these are not two projects)

One focused app per life domain. One shared private substrate. One Guide voice across all of them.

The Nutrition brief is explicit: it is not a new project. It is the Body/Nutrition domain getting its own face on the substrate the Organizer already specifies — same E2EE local store, same on-device model, same encrypted CRDT sync, same Guide voice, same DailyBlock/calendar entities. A meal is a DailyBlock. The Guide can reflect across domains (work over-ran three evenings and dinner got skipped → one nudge about a real break).

Life domain App Status

Money

Finia

Exists, separate

Time / Life

Organizer (Lodestar)

Build first — owns the substrate

Body / Nutrition

Nutrition (Repast)

Second face, reuses substrate

Relationships

Contacts

Roadmap

…​future domains

…​

Roadmap

Consequence for the build: the substrate is built once, inside the Organizer MVP, then the Nutrition app is a thin domain face on top. This is the single most important sequencing fact and it drives the plan in development-plan.md.

2. The shared substrate (built once)

Everything below is built during the Organizer MVP and reused verbatim by Nutrition and every later face:

  • E2EE local store — client-side encrypted at rest; passphrase + per-device keys.

  • Key handling + recovery — recovery codes for MVP (social/Shamir later).

  • On-device inference — one capable small model for MVP (Rust: candle or mistral.rs), behind a thin intent interface. No router/adapter swarm in v1.

  • Local RAG — the model reasons over the user’s own decrypted data.

  • Encrypted CRDT sync — Automerge/Yjs-style; server stores ciphertext only.

  • The calendar-block entity — DailyBlock/ScheduledBlock + CalendarAccount

    • ExternalEvent; native two-way calendar integration (CalDAV first).

  • The Guide — voice (Truth · Turn · Do · Footnote), entries, trigger system; surfaces contextually, including cross-domain.

3. The two faces (what is unique to each)

Organizer (build first): Life & Free-Time layer (domains + budgets, Goal → Intention → Block hierarchy, the free-time defense engine = move-or-sacrifice rule, weekly rhythm loop); Work-day structuring (brain-dump → time-blocked day, clarifying-question logic, shutdown + estimate calibration, publish membrane).

Nutrition (build second): the fidelity ladder (L0 marker, L1 freeform NL, L4 barcode+weight for MVP; L2 photo deferred); range-only estimates (always a band, never a point); no mandatory goal; local Open Food Facts mirror for offline barcode lookup; meals land on the shared DailyBlock timeline.

4. Tech stack (confirmed)

  • Rust end-to-end.

  • Tauri v2 shell (native barcode scanning already proven in prior Ersthelfer work).

  • Leptos client (Rust/WASM frontend).

  • candle or mistral.rs for on-device inference (model + lib choice is an open decision — see §6).

  • Monorepo, Cargo workspace: a shared substrate crate + per-app crates.

5. Repository layout (target — confirmed direction, finalized by architecture phase)

life/  (cargo workspace)
├─ crates/
│  ├─ substrate/        # store, crypto, keys, sync(CRDT), inference, calendar, guide
│  ├─ guide/            # Guide entries + trigger engine (may live under substrate)
│  └─ domain-core/      # shared domain entities (Domain, DailyBlock, Goal …)
├─ apps/
│  ├─ organizer/        # Tauri v2 + Leptos — Lodestar (built first)
│  └─ nutrition/        # Tauri v2 + Leptos — Repast (built second)
├─ docs/                # briefs, this overview, BMAD planning artifacts
└─ _bmad/               # BMAD method install (do not edit by hand)

The exact crate split is ratified by bmad-create-architecture, not fixed here. This is the intended shape, recorded so the architecture phase starts from the agreed monorepo + shared-substrate direction rather than re-litigating it.

6. Open decisions to resolve early (carried from both briefs)

These are flagged so the PRD/architecture phases resolve them deliberately:

  1. On-device model + quantization, and candle vs mistral.rs. (Organizer §11)

  2. Calendar sync: CalDAV-first vs per-provider APIs for v1. (Organizer §11)

  3. Key-recovery UX for MVP. (Organizer §11)

  4. Single-device MVP vs sync in v1. (Organizer §11)

  5. Product names clear of the "Hitchhiker’s Guide" trademark. (both briefs)

  6. Open Food Facts packaging: full local mirror vs syncable slimmed subset. (Nutrition §4)

7. Non-goals (both apps)

Not cloud-first (local is the entire point). Not a work-throughput maximizer. Not an invoicing tool (Organizer: connector only, post-MVP). Not a calorie-target / red-green diet app (Nutrition: awareness, not optimization). Not a household coordinator in v1 (individual-first; sharing later).