15 KiB
Life Management System — Implementation Phases
Phase Overview
| Phase | Name | Description | Dependencies |
|---|---|---|---|
| 0 | Design Documents | Architecture docs, schema, API design, wireframes | None |
| 1 | Foundation | Monorepo scaffold, NestJS + PG, domains/tasks/goals, React shell | Phase 0 |
| 2 | Core Features | Habits, scheduling, time blocks, calendar, daily plan | Phase 1 |
| 3 | Domain Extensions | Income, health, contacts, projects, encryption | Phase 1 |
| 4 | Chat Assistant | Conversations, LLM integration, WebSocket streaming | Phase 2 |
| 5 | Voice Communication | TTS/STT proxy, VAD, interrupt flow | Phase 4 |
| 6 | Analytics & Polish | Charts, ADHD features, animations, suggestions | Phase 2 + 3 |
Phases 2 and 3 can run in parallel after Phase 1.
Phase 0: Design Documents
Goal: Comprehensive design documentation for all system components.
Deliverables:
docs/architecture.md— System overview, monorepo layout, service boundaries, package dependenciesdocs/schema.md— Full database schema with all entities, relationships, indexes, encryptiondocs/api.md— REST API endpoints grouped by module, request/response shapes, WebSocket eventsdocs/frontend.md— Route tree, page wireframes (ASCII), component hierarchy, state managementdocs/chat-assistant.md— LLM integration, model routing, context injection, streaming protocoldocs/voice.md— Voice architecture, WebSocket proxy, VAD strategy, interrupt flow, Chatterbox integrationdocs/adhd-ux.md— ADHD-friendly UX patterns, energy system, quick wins, suggestion algorithmdocs/phases.md— This file
Verification:
- All 8 docs written and internally consistent
- Schema doc matches API doc entity shapes
- Frontend routes match API endpoints
- Voice doc correctly references Chatterbox protocol
Phase 1: Foundation
Goal: Working monorepo with backend API, frontend shell, and core CRUD for domains, tasks, and goals.
Backend
-
Scaffold monorepo
pnpm-workspace.yamlwithpackages: [backend-api, frontend, shared]turbo.jsonwith build → typecheck → test pipelineservices.yamlwith port allocations.env.examplewith all environment variables
-
Docker Compose
- PostgreSQL 16 on port 25470 with pgcrypto extension
- Redis Stack on port 6379
init.sqlfor extension creation
-
NestJS application
main.tsusing@lilith/service-nestjs-bootstrapbootstrap()AppModulewithTypeOrmConfigModule,PgCryptoModule,HealthModule- Global prefix
/api, Swagger at/api-docs GET /healthreturning OK
-
DomainsModule
Domainentity- CRUD endpoints:
GET /api/domains,GET /api/domains/:id,POST /api/domains,PATCH /api/domains/:id,DELETE /api/domains/:id - Seed migration for 8 initial domains
-
TasksModule
Taskentity with self-referencing parent_id for subtasks- CRUD with domain filtering, status transitions, energy level
- Query:
GET /api/tasks?domainId=&status=&priority=&energyLevel=&isQuickWin=
-
GoalsModule
Goalentity with self-referencing parent_id for hierarchy- CRUD with domain filtering, level filtering
- Hierarchical tree endpoint:
GET /api/goals/tree?domainId=
Frontend
-
React application
main.tsxusing@lilith/service-react-bootstrapbootstrap()- Vite config with proxy to backend
- ThemeProvider (cyberpunk default)
- BrowserRouter with route definitions
-
Layout shell
- Navigation sidebar with
@lilith/ui-navigation - Route links to all planned pages
- Responsive layout with
@lilith/ui-layout
- Navigation sidebar with
-
Pages (basic)
/today— Basic version: task list filtered by today, morning assessment card/domains— Domain grid showing all 8 domains with colors/icons/domains/:slug— Domain dashboard placeholder
Shared
- Shared types package
- Enums:
DomainType,TaskStatus,Priority,EnergyLevel,GoalLevel,GoalStatus - DTO interfaces matching backend shapes
- Enums:
Verification Criteria
docker compose up -d— PostgreSQL starts on port 25470pnpm dev— Backend on :3700, Frontend on :5700GET http://localhost:3700/health→{ "status": "ok" }GET http://localhost:3700/api/domains→ 8 seeded domainsPOST http://localhost:3700/api/tasks→ Creates taskGET http://localhost:3700/api/goals/tree?domainId=...→ Goal tree- Frontend loads with cyberpunk theme, navigation sidebar visible
/todayshows tasks and morning assessment/domainsshows 8 domain cards- Swagger UI at
http://localhost:3700/api-docslists all endpoints
Phase 2: Core Features
Goal: Habit tracking, scheduling, time blocks, calendar view, and full daily plan.
Backend
-
HabitsModule
HabitandHabitCheckInentities- CRUD for habits + check-in creation
- Streak calculation (daily cron via
@nestjs/schedule) GET /api/habits/due-today— Habits due today based on frequencyPOST /api/habits/:id/check-in— Record check-in
-
SchedulingModule
TimeBlockandDailyPlanentities- TimeBlock CRUD with date range queries
- DailyPlan CRUD (one per day, upsert pattern)
GET /api/scheduling/day/:date— Full day view (plan + blocks)
-
TodayModule (aggregation)
GET /api/today— Unified endpoint returning:- Daily plan (energy, mood, intention)
- Time blocks for today
- Priority tasks (filtered by energy level, overdue first)
- Quick wins (tasks < 5 min)
- Habits due today with check-in status
- Domain quick stats
Frontend
-
/todayfull implementation- Morning assessment card (energy, mood, intention setter)
- Time block timeline (color-coded by domain)
- Task list with energy-based filtering
- Quick wins section
- Habit check-in buttons
- Domain quick stats row
-
/habitsdashboard- All habits grouped by domain
- Streak counters with visual indicators
- Check-in history calendar heatmap
- Create/edit habit forms
-
/calendarview- Week and month views
- Time blocks displayed as calendar events
- Click to create new time block
- Color coding by domain
-
Task list enhancements
- Filtering by status, priority, energy level, domain
- Sorting options
- Subtask expansion/collapse
- Quick status toggle
Verification Criteria
- Create habit → check in daily → streak increments
- Skip a day → streak resets (via cron job)
GET /api/todayreturns aggregated daily view/todaypage shows full daily plan with all sections/habitsshows all habits with streak indicators/calendarshows time blocks in week view- Time blocks have correct domain colors
Phase 3: Domain-Specific Extensions
Goal: Income tracking, health/medical, contacts, sprints, content calendar — all with encryption where needed.
Backend
-
IncomeModule (encrypted)
IncomeEntryandBillableEntryentities- pgcrypto encryption on amount and description
GET /api/income?domainId=&startDate=&endDate=— Filtered income listGET /api/income/summary?period=month— Income aggregation- Billable entry CRUD with invoicing status
-
HealthModule (encrypted)
MeasurementandMedicalEntryentities- pgcrypto encryption on medical details
GET /api/health/measurements?type=weight&startDate=&endDate=GET /api/health/medical?type=hrt_dose
-
ContactsModule (encrypted)
Contactentity with encrypted phone and notes- CRUD with domain filtering
GET /api/contacts?domainId=&type=&isActive=
-
ProjectsModule
SprintandContentCalendarItementities- Sprint CRUD with task association
- Content calendar CRUD
GET /api/projects/sprints?domainId=&status=GET /api/projects/content?domainId=&status=&platform=
Frontend
-
Domain dashboard specialization
- Software domains → Sprint board widget
- Income domains (escort/OF/client) → Income chart widget
- Physical/modeling → Measurement chart widget
- Content → Content calendar widget
-
/incomecross-domain view- Income trends chart (line/area)
- Revenue by domain (pie chart)
- Monthly/weekly/daily breakdowns
- Billable hours summary
-
Domain-specific pages
/domains/:slug/income— Income dashboard/domains/:slug/contacts— Contact list/domains/:slug/sprints— Sprint board/domains/:slug/content— Content calendar/domains/:slug/measurements— Measurement charts/domains/:slug/medical— Medical entry timeline
Verification Criteria
- Income entry created → stored encrypted in DB → decrypted on read
SELECT amount_encrypted FROM income_entriesreturns bytea (not plaintext)- Medical details encrypted at rest
- Contact phone/notes encrypted at rest
/incomeshows cross-domain revenue charts- Sprint board shows tasks in columns (todo/in_progress/done)
- Content calendar shows items by status
Phase 4: Chat Assistant
Goal: AI chat assistant with conversation persistence, context injection from app modules, and streaming responses.
Backend
-
ChatModule
ConversationandMessageentities- CRUD: list conversations, get messages, create conversation
POST /api/chat/conversations— Start conversationGET /api/chat/conversations/:id/messages— Get messages
-
AssistantModule
- LLM orchestration service
- Model routing: simple queries → fast local model, complex → reasoning model or Claude
- Context injection pipeline:
- Daily plan state (energy, mood)
- Pending tasks count per domain
- Overdue items
- Habit streaks
- Income summary for current period
- System prompt template with injected context
- Streaming response via
openainpm package
-
ChatGateway (WebSocket)
- Extends
BaseGatewayfrom@lilith/websocket-server - Namespace:
/chat - Events:
send_message→ process through AssistantModule → streammessage_chunkeventsconversation:join→ join conversation roomconversation:leave→ leave room
- Extends
Frontend
-
/chatpage- Conversation list sidebar (
@lilith/ui-messagingThreadList) - Chat feed with streaming (
ChatFeed+MessageBubble) - Message input with send (
MessageComposer) - New conversation button
- Model selector (optional)
- Conversation list sidebar (
-
Mini chat widget on
/today- Collapsed FAB-style button
- Expands to inline chat panel
- Quick queries: "What should I do next?", "Summary of today"
-
WebSocket integration
useWebSocket+useChatfrom@lilith/websocket-client- Streaming message rendering
- Typing indicator via
@lilith/ui-realtime
Verification Criteria
- Open
/chat→ new conversation → type message → streaming response from local LLM - Ask "what tasks are overdue?" → assistant queries tasks module → returns real task data
- Ask "what's my income this month?" → assistant queries income module → returns summary
- Conversation persisted in DB → reload page → conversation history intact
- Mini chat widget on
/todayworks - Streaming tokens appear incrementally (not all at once)
Phase 5: Voice Communication
Goal: Interruptible 2-way voice via Chatterbox TTS/STT with WebSocket proxying through the backend.
Backend
-
VoiceModule
- VoiceGateway extends
BaseGateway - Namespace:
/voice - Proxies to Chatterbox TTS WebSocket (
ws://localhost:41222/ws) - Proxies to Chatterbox STT WebSocket (
ws://localhost:41222/ws/stt)
- VoiceGateway extends
-
TTS streaming proxy
- Receives text from AssistantModule
- Sentence-splits before sending to Chatterbox (low-latency trick)
- Relays binary audio chunks from Chatterbox back to client
- Handles
tts_stopon interrupt
-
STT streaming proxy
- Receives base64 audio from client
- Relays to Chatterbox STT WebSocket
- Returns transcription events
-
Interrupt handler
- Client sends
voice:interrupt→ sendstts_stopto Chatterbox → cancels current TTS → starts new STT cycle
- Client sends
Frontend
-
AudioWorklet VAD
- Energy-based voice activity detection
- Runs in AudioWorklet (off main thread)
- Detects speech start/end
- During TTS playback: speech detected → interrupt
-
Voice FAB
- Floating action button (uses
@lilith/ui-fab) - Tap to start listening
- Visual waveform indicator showing who's speaking
- Activation/deactivation sounds via
@lilith/ui-effects-sound
- Floating action button (uses
-
Audio playback
- WebSocket binary → AudioContext for gapless playback
- Queue-based chunk playback
- Interrupt on VAD detection
Verification Criteria
- Click voice FAB → mic activates (browser permission) → speak
- Speech transcribed → appears as user message → LLM responds → audio plays
- Speak during audio playback → TTS interrupted → new response cycle begins
- Voice conversation stored as messages in conversation entity
- Activation/deactivation sounds play
- Waveform indicator shows during speech/playback
Phase 6: Analytics & Polish
Goal: Cross-domain analytics, ADHD-friendly UX features, and visual polish.
Backend
-
AnalyticsModule
- Aggregation queries across all modules
GET /api/analytics/overview— Cross-domain summaryGET /api/analytics/domain/:id— Domain-specific analyticsGET /api/analytics/trends?metric=income&period=monthGET /api/analytics/habits/adherence?period=month
-
Suggestion engine
GET /api/today/next-action— Algorithmic "what should I do next?"- Factors: energy level, time of day, priority, overdue status, domain balance
- Simple scoring algorithm (no ML needed)
Frontend
-
/analyticsdashboard- Income trends (area chart via
@lilith/ui-charts) - Habit adherence rates (bar chart)
- Goal progress overview
- Tasks completed this week/month
- Domain activity distribution (pie chart)
- Income trends (area chart via
-
ADHD features
- Energy-based task filtering on
/today(linked to morning assessment) - Quick wins prominence when energy is low
- Break reminder timer (configurable Pomodoro, Toast notifications)
- "What should I do next?" button on
/today - Time-of-day awareness (auto-scroll to current time period)
- Urgency color coding: overdue=red, today=amber, upcoming=neutral, quick-win=green
- Energy-based task filtering on
-
Visual polish
- Completion animations via
@lilith/ui-motion(task done, habit checked in) - Streak counter celebrations (milestones at 7, 30, 100 days)
- Drag-and-drop time block rearrangement via
@lilith/ui-dnd - Domain quick stats on today page (income, streaks, sprint progress)
- Weekly wins summary
- Completion animations via
Verification Criteria
/analyticsshows charts for income, habits, goals, tasks- "What should I do next?" returns context-appropriate suggestion
- Break reminder fires after configured time (e.g., 25 min Pomodoro)
- Completing a task triggers animation
- Hitting a streak milestone triggers celebration
- Time blocks draggable to rearrange
- Low energy → quick wins section becomes prominent
- Overdue tasks have red indicator