Product Brief — Personal Organization App

Working codename: Lodestar (placeholder — replace. Do not ship under "Hitchhiker’s Guide"; that name is trademarked. Borrow the voice, not the name.)

Purpose of this document: a single, coherent brief to hand to Claude Code + BMAD. It supersedes the five working outlines and resolves the contradictions between them. Structure favors decomposition into epics and stories.

1. Vision

A personal organization app that helps a person structure their whole life — work and private — entirely on their own device, end-to-end encrypted, with a local AI that turns a messy brain-dump into a planned day and a protected week, and a Guide companion that offers perspective on how to learn and live.

Where Motion and Reclaim optimize your job on someone else’s servers, this organizes your life, of which work is one domain — and your data never leaves your control.

2. Positioning

  • vs Motion / Reclaim / Sunsama: they maximize work throughput in the cloud. This organizes the entire life, locally and privately.

  • vs Cozi / TimeTree: those coordinate a household. This is the individual’s private operating system (sharing is a later, opt-in concern).

  • The wedge: securely think through and structure your real life — work and private — without any of it living on anyone else’s server.

3. Ecosystem thesis (why "more like that" is coherent, not sprawl)

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

Life domain App

Money

Finia (exists, separate — not invoicing)

Time / Life

this app (the Organizer)

Relationships

Contacts (roadmap, §8)

…​future domains

…​

The shared substrate — encryption, on-device inference, sync, and the Guide voice — is built once; each app is a face on it. This is the principle that keeps the suite from becoming five unrelated side projects: the life-domain model in §5.1 is the product-family map.

4. Architecture

Local-first, E2EE, zero-knowledge server.

  • On-device inference (target): a small base model resident in memory with hot-swappable LoRA adapters (scheduler · NL-capture · decomposition · Guide-voice) behind a tiny intent router. MVP simplification: ship with a single capable small model; grow into the router+adapter design post-MVP. Don’t build the swarm in v1.

  • Local RAG: the model reasons over the user’s own data, decrypted on-device. The model is the engine; the user’s data is the knowledge. Keeps models small.

  • Optional cloud (roadmap): per-task, explicit opt-in; client-side PII anonymization with a local token map; show the exact payload before it sends; routes only to self-hosted infrastructure. Be honest: such a request is not E2EE. Hard-disabled for work-tagged items.

  • Sync: encrypted CRDT updates (Automerge/Yjs-style); server stores ciphertext only.

  • Keys: passphrase + per-device keys. Recovery is the hard problem — recovery codes for MVP, social/Shamir recovery later. Lose the key, lose the data.

  • Stack: Rust + Tauri v2 + Leptos client; candle or mistral.rs for on-device inference.

5. Core modules

5.1 Life & Free-Time layer — the container

  • Domains (Work, Health, Family/Relationships, Learning, Service, Creative/Play, Rest, Admin), each with a weekly target_share, a derived actual_share, and a health_signal.

  • Hierarchy: Goals → Weekly Intentions → Daily Blocks, fully traceable upward, so every block knows why it exists.

  • Free-time defense engine (the differentiator):

    • protected blocks are first-class, locked like meetings;

    • free time can only be moved or knowingly sacrificed — never silently dropped, and every sacrifice is logged;

    • drift detection warns when work eats protected domains across days (the anti-burnout core);

    • ideal-week template; friction asymmetry (easy to protect, deliberate to override).

  • Rhythm loop: weekly review → daily plan → daily shutdown → back to weekly.

5.2 Work-day structuring — a module inside the Work domain

  • Brain-dump session → extracted items with estimates, energy, dependencies.

  • Clarifying-question logic: ask only when it changes the plan; prefer confirming a guess over an open question; hard cap of 3 per session; always a "good enough — schedule it" escape.

  • Shutdown review → estimate calibration: track actual/estimate by (type, project, time-of-day, energy); converge on the user’s real pace.

  • Publish membrane — "private process, published outcomes": raw dump, energy, clarifications, roll-over counts never leave; only an edited, client-facing description + minutes + project cross over.

  • Billing is an optional export connector only (Invoice Ninja / ERPNext / Odoo via API/MCP), off by default, freelancer slice only. The app never becomes an invoicing tool.

5.3 Guide companion

  • Voice: dry, warm, cosmically humbling, never preachy; leaves the reader relieved.

  • Entry template: Truth · Turn · Do · Footnote, where Do is a single action the planner can schedule directly.

  • Taxonomy: states · acts · domains (domains map to the life layer).

  • Surfaces contextually on life events (over-served work, skipped block, intention met). 10 starter entries already drafted.

6. Unified data model

Life layer: Domain, Goal, WeeklyIntention, DailyBlock, IdealWeekTemplate, DriftSignal, SacrificeLog. Work module: Session, RawCapture, Item, Clarification, PublishRecord. Shared: ScheduledBlock/DailyBlock unify into one calendar-block entity; CalendarAccount + ExternalEvent for sync. Guide: GuideEntry, GuideTrigger. Roadmap (Contacts): Contact, Interaction, RelationshipCadence.

All entities client-side encrypted; derived signals computed locally.

7. MVP scope (v1)

In:

  • E2EE local store; key setup + recovery codes.

  • Single on-device model: capture → decompose → schedule.

  • Native calendar integration — read/write the user’s existing calendars (CalDAV, Google, Apple, Outlook). Foundational, not optional.

  • Daily brain-dump → time-blocked day.

  • Daily shutdown + basic estimate calibration.

  • Basic life domains + protected blocks + the move-or-sacrifice rule (the soul of the product — must be in v1).

  • Weekly intentions + a simple weekly review.

  • Guide: starter entries + contextual surfacing on a few triggers.

Out (deferred to roadmap): router/adapter swarm, cloud path, drift-detection refinement, billing connector, Contacts app, robust multi-device sync, social key recovery.

8. Roadmap (post-MVP)

  • R1 — Architecture: router + LoRA adapter swarm; harden multi-device CRDT sync.

  • R2 — Intelligence: full drift detection + ideal-week templates; expand the Guide library.

  • R3 — Optional cloud: per-task opt-in anonymized self-hosted inference with payload confirmation.

  • R4 — Contacts app (structured relationship manager): contacts that hold who someone is, not just a number — how you know them, important dates, family, preferences, shared history, a relationship graph, last-contact and a desired cadence. It is the data backbone of the Family/Relationships domain, not a standalone: the planner can protect and suggest time for the people who matter, and the Guide can nudge on neglected relationships (On Relationships). Same E2EE/local substrate; relationships are intimate data, so privacy is a feature, not a checkbox.

  • R5 — Billing connector: export published billable items to Invoice Ninja / ERPNext / Odoo.

  • R6 — Further domain apps: the rest of "more like that," each mapped to a life domain on the shared substrate.

9. Consolidated epics (for BMAD)

Each is independently shippable; AC = acceptance criteria.

Foundation

  1. E2EE local store + keys. AC: data is encrypted at rest; a user can set a passphrase and recover via a recovery code.

  2. On-device model integration. AC: a brain-dump string is turned into structured items locally, with no network call.

  3. Native calendar integration. AC: the app reads existing events and writes new blocks back to the user’s chosen calendar (CalDAV first), two-way.

Life layer

  1. Domain model & budgets. AC: define domains, set weekly targets, see a live served/under/over signal from scheduled + logged time.

  2. Goal → Intention → Block hierarchy. AC: any block resolves its domain and goal; a goal shows its contributing blocks and time-to-date.

  3. Free-time defense engine. AC: a protected block can’t be overwritten by the scheduler without an explicit override, and every override is logged.

  4. Weekly rhythm loop. AC: a weekly review completes in under 3 minutes and writes next week’s protected scaffold.

Work module

  1. Brain-dump session + clarifying questions. AC: ≤3 questions, each a tappable confirm-a-guess, with a schedule-anyway escape.

  2. Shutdown review + estimate calibration. AC: actuals captured per block; future estimates apply a per-bucket multiplier from history.

  3. Publish membrane. AC: only the edited description + minutes + project can cross out; raw private fields never can.

Guide

  1. Guide entries + contextual triggers. AC: defined life events map to entries and render in-context; the Do field can become a scheduled block.

(Post-MVP epics: adapter swarm, cloud path, drift refinement, Contacts, billing connector — see §8.)

10. Non-goals

  • Not an invoicing tool (connector only).

  • Not a work-throughput maximizer — the goal is a life well-spent.

  • Not a household/family coordinator in v1 (individual-first; sharing later).

  • Not cloud-first. Local is the default and the entire point.

11. Open decisions (resolve before/early in the build)

  • Which small on-device model, quantization, and candle vs mistral.rs.

  • Calendar sync: CalDAV-first vs per-provider APIs for v1.

  • Key-recovery UX for MVP.

  • Single-device MVP vs. sync included in v1.

  • Product name (clear of the trademark).