# Roadmap: HouseHoldKeaper

## Overview

Four phases build the app bottom-up along its natural dependency chain. Phase 1 lays the technical foundation every subsequent phase relies on. Phase 2 delivers complete room and task management — the core scheduling loop. Phase 3 surfaces that data as the daily plan view (the primary user experience) and adds the cleanliness indicator. Phase 4 adds notifications and completes the v1 feature set. After Phase 3, the app is usable daily. After Phase 4, it is releasable.

## Phases

**Phase Numbering:**
- Integer phases (1, 2, 3): Planned milestone work
- Decimal phases (2.1, 2.2): Urgent insertions (marked with INSERTED)

Decimal phases appear between their surrounding integers in numeric order.

- [x] **Phase 1: Foundation** - Project scaffold, database, state management, theme, and localization infrastructure (completed 2026-03-15)
- [x] **Phase 2: Rooms and Tasks** - Complete room CRUD, task CRUD with auto-scheduling, and bundled templates (completed 2026-03-15)
- [x] **Phase 3: Daily Plan and Cleanliness** - Primary daily plan screen with overdue/today/upcoming, cleanliness indicators per room (completed 2026-03-16)
- [x] **Phase 4: Notifications** - Daily summary notification with configurable time and Android permission handling (completed 2026-03-16)

## Phase Details

### Phase 1: Foundation
**Goal**: The app compiles, opens, and enforces correct architecture patterns — ready to receive features without accumulating technical debt
**Depends on**: Nothing (first phase)
**Requirements**: FOUND-01, FOUND-02, FOUND-03, FOUND-04, THEME-01, THEME-02
**Success Criteria** (what must be TRUE):
  1. App launches on Android without errors and shows a bottom navigation bar with Home, Rooms, and Settings tabs
  2. Light and dark themes work correctly and follow the system setting by default, using the calm Material 3 palette (muted greens, warm grays, gentle blues)
  3. All UI strings are loaded from ARB localization files — no hardcoded German text in Dart code
  4. The Drift database opens on first launch with schemaVersion 1 and the migration workflow is established (drift_dev make-migrations runs without errors)
  5. riverpod_lint is active and flags ref.watch usage outside build() as an analysis error
**Plans**: 2 plans
Plans:
- [x] 01-01-PLAN.md — Scaffold Flutter project and build core infrastructure (database, providers, theme, localization)
- [x] 01-02-PLAN.md — Navigation shell, placeholder screens, Settings, and full app wiring

### Phase 2: Rooms and Tasks
**Goal**: Users can create and manage rooms and tasks, mark tasks done, and trust the app to schedule the next occurrence automatically
**Depends on**: Phase 1
**Requirements**: ROOM-01, ROOM-02, ROOM-03, ROOM-04, ROOM-05, TASK-01, TASK-02, TASK-03, TASK-04, TASK-05, TASK-06, TASK-07, TASK-08, TMPL-01, TMPL-02
**Success Criteria** (what must be TRUE):
  1. User can create a room with a name and icon, edit it, reorder rooms via drag-and-drop, and delete it (with confirmation that removes all associated tasks)
  2. User can create a task in a room with name, description, frequency interval (daily through yearly and custom), and effort level; tasks can be edited and deleted with confirmation
  3. When creating a room, user can select from bundled German-language task templates for the chosen room type (all 14 room types covered) and they are added to the room as tasks
  4. User can mark a task done (tap or swipe), which records the completion and sets the next due date correctly based on the interval
  5. Overdue tasks are visually highlighted with a distinct color or badge on room cards and in task lists; tasks within a room are sorted by due date by default
  6. Each room card shows its name, icon, count of due tasks, and cleanliness indicator
**Plans**: 5 plans
Plans:
- [x] 02-01-PLAN.md — Data layer: Drift tables, migration v1->v2, DAOs, scheduling utility, domain models, templates, tests
- [x] 02-02-PLAN.md — Room CRUD UI: 2-column card grid, room form, icon picker, drag-and-drop reorder, providers
- [x] 02-03-PLAN.md — Task CRUD UI: task list, task row with completion, task form, overdue highlighting, providers
- [x] 02-04-PLAN.md — Template selection: template picker bottom sheet, room type detection, integration with room creation
- [x] 02-05-PLAN.md — Visual and functional verification checkpoint

### Phase 3: Daily Plan and Cleanliness
**Goal**: Users can open the app and immediately see what needs doing today, act on tasks directly from the plan view, and see a room-level health indicator
**Depends on**: Phase 2
**Requirements**: PLAN-01, PLAN-02, PLAN-03, PLAN-04, PLAN-05, PLAN-06, CLEAN-01
**Success Criteria** (what must be TRUE):
  1. The Home tab shows today's tasks grouped by room, with a separate highlighted section at the top for overdue tasks
  2. User can mark a task done directly from the daily plan view via swipe or checkbox without navigating to the room
  3. User can see upcoming tasks (tomorrow and this week) from the daily plan screen
  4. A progress indicator shows completed vs total tasks for today (e.g., "5 von 12 erledigt")
  5. When no tasks are due, an encouraging "all clear" empty state is shown instead of an empty list
  6. Each room card displays a cleanliness indicator derived from the ratio of overdue tasks to total tasks in that room
**Plans**: 3 plans
Plans:
- [x] 03-01-PLAN.md — Data layer: DailyPlanDao with cross-room join query, providers, and localization keys
- [x] 03-02-PLAN.md — Daily plan UI: HomeScreen rewrite with progress card, task sections, animated completion, empty state
- [x] 03-03-PLAN.md — Visual and functional verification checkpoint

### Phase 4: Notifications
**Goal**: Users receive a daily summary notification reminding them of today's task count, and can control notification behavior from settings
**Depends on**: Phase 2
**Requirements**: NOTF-01, NOTF-02
**Success Criteria** (what must be TRUE):
  1. User receives one daily notification showing the count of tasks due today, scheduled at a configurable time
  2. User can enable or disable notifications from the Settings tab, and the change takes effect immediately
  3. Notifications are correctly rescheduled after device reboot (RECEIVE_BOOT_COMPLETED receiver active)
  4. On Android API 33+, the app requests POST_NOTIFICATIONS permission at the appropriate moment and degrades gracefully if denied
**Plans**: 3 plans
Plans:
- [ ] 04-01-PLAN.md — Infrastructure: packages, Android config, NotificationService, NotificationSettingsNotifier, DAO queries, timezone init, tests
- [ ] 04-02-PLAN.md — Settings UI: Benachrichtigungen section with toggle, time picker, permission flow, scheduling wiring, tests
- [ ] 04-03-PLAN.md — Verification gate: dart analyze + full test suite + requirement confirmation

## Progress

**Execution Order:**
Phases execute in numeric order: 1 -> 2 -> 3 -> 4

Note: Phase 4 depends on Phase 2 (needs scheduling data) but can be developed in parallel with Phase 3.

| Phase | Plans Complete | Status | Completed |
|-------|----------------|--------|-----------|
| 1. Foundation | 2/2 | Complete    | 2026-03-15 |
| 2. Rooms and Tasks | 5/5 | Complete    | 2026-03-15 |
| 3. Daily Plan and Cleanliness | 3/3 | Complete   | 2026-03-16 |
| 4. Notifications | 3/3 | Complete   | 2026-03-16 |
