docs: create roadmap (4 phases)
This commit is contained in:
@@ -91,34 +91,34 @@ Which phases cover which requirements. Updated during roadmap creation.
|
||||
|
||||
| Requirement | Phase | Status |
|
||||
|-------------|-------|--------|
|
||||
| DATA-01 | — | Pending |
|
||||
| DATA-02 | — | Pending |
|
||||
| DATA-03 | — | Pending |
|
||||
| DATA-04 | — | Pending |
|
||||
| REFAC-01 | — | Pending |
|
||||
| REFAC-02 | — | Pending |
|
||||
| REFAC-03 | — | Pending |
|
||||
| DB-01 | — | Pending |
|
||||
| DB-02 | — | Pending |
|
||||
| DB-03 | — | Pending |
|
||||
| BULK-01 | — | Pending |
|
||||
| BULK-02 | — | Pending |
|
||||
| SRCH-01 | — | Pending |
|
||||
| SRCH-02 | — | Pending |
|
||||
| SRCH-03 | — | Pending |
|
||||
| SRCH-04 | — | Pending |
|
||||
| INDIC-01 | — | Pending |
|
||||
| INDIC-02 | — | Pending |
|
||||
| INDIC-03 | — | Pending |
|
||||
| INDIC-04 | — | Pending |
|
||||
| A11Y-01 | — | Pending |
|
||||
| A11Y-02 | — | Pending |
|
||||
| DATA-01 | Phase 1 | Pending |
|
||||
| DATA-02 | Phase 1 | Pending |
|
||||
| DATA-03 | Phase 1 | Pending |
|
||||
| DATA-04 | Phase 1 | Pending |
|
||||
| REFAC-01 | Phase 2 | Pending |
|
||||
| REFAC-02 | Phase 2 | Pending |
|
||||
| REFAC-03 | Phase 2 | Pending |
|
||||
| DB-01 | Phase 3 | Pending |
|
||||
| DB-02 | Phase 3 | Pending |
|
||||
| DB-03 | Phase 3 | Pending |
|
||||
| BULK-01 | Phase 4 | Pending |
|
||||
| BULK-02 | Phase 4 | Pending |
|
||||
| SRCH-01 | Phase 4 | Pending |
|
||||
| SRCH-02 | Phase 4 | Pending |
|
||||
| SRCH-03 | Phase 4 | Pending |
|
||||
| SRCH-04 | Phase 4 | Pending |
|
||||
| INDIC-01 | Phase 4 | Pending |
|
||||
| INDIC-02 | Phase 4 | Pending |
|
||||
| INDIC-03 | Phase 4 | Pending |
|
||||
| INDIC-04 | Phase 4 | Pending |
|
||||
| A11Y-01 | Phase 4 | Pending |
|
||||
| A11Y-02 | Phase 4 | Pending |
|
||||
|
||||
**Coverage:**
|
||||
- v1 requirements: 22 total
|
||||
- Mapped to phases: 0
|
||||
- Unmapped: 22 ⚠️
|
||||
- Mapped to phases: 22
|
||||
- Unmapped: 0
|
||||
|
||||
---
|
||||
*Requirements defined: 2026-03-23*
|
||||
*Last updated: 2026-03-23 after initial definition*
|
||||
*Last updated: 2026-03-23 after roadmap creation*
|
||||
|
||||
80
.planning/ROADMAP.md
Normal file
80
.planning/ROADMAP.md
Normal file
@@ -0,0 +1,80 @@
|
||||
# Roadmap: DiunDashboard
|
||||
|
||||
## Overview
|
||||
|
||||
This milestone restores data trust and then extends the foundation. Phase 1 fixes active bugs that silently corrupt user data today. Phase 2 refactors the backend into a testable, interface-driven structure — the structural prerequisite for everything that follows. Phase 3 adds PostgreSQL as a first-class alternative to SQLite. Phase 4 delivers the UX features that make the dashboard genuinely usable at scale: bulk dismiss, search/filter, new-update indicators, and accessibility fixes.
|
||||
|
||||
## 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.
|
||||
|
||||
- [ ] **Phase 1: Data Integrity** - Fix active SQLite bugs that silently delete tag assignments and suppress test failures
|
||||
- [ ] **Phase 2: Backend Refactor** - Replace global state with Store interface + Server struct; prerequisite for PostgreSQL
|
||||
- [ ] **Phase 3: PostgreSQL Support** - Add PostgreSQL as an alternative backend via DATABASE_URL, with versioned migrations
|
||||
- [ ] **Phase 4: UX Improvements** - Bulk dismiss, search/filter, new-update indicators, and accessibility fixes
|
||||
|
||||
## Phase Details
|
||||
|
||||
### Phase 1: Data Integrity
|
||||
**Goal**: Users can trust that their data is never silently corrupted — tag assignments survive new DIUN events, foreign key constraints are enforced, and test failures are always visible
|
||||
**Depends on**: Nothing (first phase)
|
||||
**Requirements**: DATA-01, DATA-02, DATA-03, DATA-04
|
||||
**Success Criteria** (what must be TRUE):
|
||||
1. A second DIUN event for the same image does not remove its tag assignment
|
||||
2. Deleting a tag removes all associated tag assignments (foreign key cascade enforced)
|
||||
3. An oversized webhook payload is rejected with a 413 response, not processed silently
|
||||
4. A failing assertion in a test causes the test run to report failure, not pass silently
|
||||
**Plans**: TBD
|
||||
|
||||
### Phase 2: Backend Refactor
|
||||
**Goal**: The codebase has a clean Store interface and Server struct so the SQLite implementation can be swapped without touching HTTP handlers, enabling parallel test execution and PostgreSQL support
|
||||
**Depends on**: Phase 1
|
||||
**Requirements**: REFAC-01, REFAC-02, REFAC-03
|
||||
**Success Criteria** (what must be TRUE):
|
||||
1. All existing tests pass with zero behavior change after the refactor
|
||||
2. HTTP handlers contain no SQL — all persistence goes through named Store methods
|
||||
3. Package-level global variables (db, mu, webhookSecret) no longer exist
|
||||
4. Schema changes are applied via versioned migration files, not ad-hoc DDL in application code
|
||||
**Plans**: TBD
|
||||
|
||||
### Phase 3: PostgreSQL Support
|
||||
**Goal**: Users running PostgreSQL infrastructure can point DiunDashboard at a Postgres database via DATABASE_URL and the dashboard works identically to the SQLite deployment
|
||||
**Depends on**: Phase 2
|
||||
**Requirements**: DB-01, DB-02, DB-03
|
||||
**Success Criteria** (what must be TRUE):
|
||||
1. Setting DATABASE_URL starts the app using PostgreSQL; omitting it falls back to SQLite with DB_PATH
|
||||
2. A fresh PostgreSQL deployment receives all schema tables via automatic migration on startup
|
||||
3. An existing SQLite user can upgrade to the new binary without any data loss or manual schema changes
|
||||
4. The app can be run with Docker Compose using an optional postgres service profile
|
||||
**Plans**: TBD
|
||||
**UI hint**: no
|
||||
|
||||
### Phase 4: UX Improvements
|
||||
**Goal**: Users can manage a large list of updates efficiently — dismissing many at once, finding specific images quickly, and seeing new arrivals without manual refreshes
|
||||
**Depends on**: Phase 2
|
||||
**Requirements**: BULK-01, BULK-02, SRCH-01, SRCH-02, SRCH-03, SRCH-04, INDIC-01, INDIC-02, INDIC-03, INDIC-04, A11Y-01, A11Y-02
|
||||
**Success Criteria** (what must be TRUE):
|
||||
1. User can dismiss all pending updates with a single button click
|
||||
2. User can dismiss all pending updates within a specific tag group with a single action
|
||||
3. User can search by image name and filter by status, tag, and sort order without a page reload
|
||||
4. A badge/counter showing pending update count is always visible; the browser tab title reflects it (e.g., "DiunDash (3)")
|
||||
5. New updates arriving during active polling trigger a visible in-page toast, and updates seen for the first time since the user's last visit are visually highlighted
|
||||
6. The light/dark theme toggle is available and respects system preference; the drag handle for tag reordering is always visible without hover
|
||||
**Plans**: TBD
|
||||
**UI hint**: yes
|
||||
|
||||
## Progress
|
||||
|
||||
**Execution Order:**
|
||||
Phases execute in numeric order: 1 → 2 → 3 → 4
|
||||
|
||||
| Phase | Plans Complete | Status | Completed |
|
||||
|-------|----------------|--------|-----------|
|
||||
| 1. Data Integrity | 0/? | Not started | - |
|
||||
| 2. Backend Refactor | 0/? | Not started | - |
|
||||
| 3. PostgreSQL Support | 0/? | Not started | - |
|
||||
| 4. UX Improvements | 0/? | Not started | - |
|
||||
63
.planning/STATE.md
Normal file
63
.planning/STATE.md
Normal file
@@ -0,0 +1,63 @@
|
||||
# Project State
|
||||
|
||||
## Project Reference
|
||||
|
||||
See: .planning/PROJECT.md (updated 2026-03-23)
|
||||
|
||||
**Core value:** Reliable, persistent visibility into which services need updating — data never disappears, and the dashboard is the one place you trust to show the full picture.
|
||||
**Current focus:** Phase 1 — Data Integrity
|
||||
|
||||
## Current Position
|
||||
|
||||
Phase: 1 of 4 (Data Integrity)
|
||||
Plan: 0 of ? in current phase
|
||||
Status: Ready to plan
|
||||
Last activity: 2026-03-23 — Roadmap created; ready to begin Phase 1 planning
|
||||
|
||||
Progress: [░░░░░░░░░░] 0%
|
||||
|
||||
## Performance Metrics
|
||||
|
||||
**Velocity:**
|
||||
- Total plans completed: 0
|
||||
- Average duration: —
|
||||
- Total execution time: —
|
||||
|
||||
**By Phase:**
|
||||
|
||||
| Phase | Plans | Total | Avg/Plan |
|
||||
|-------|-------|-------|----------|
|
||||
| - | - | - | - |
|
||||
|
||||
**Recent Trend:**
|
||||
- Last 5 plans: —
|
||||
- Trend: —
|
||||
|
||||
*Updated after each plan completion*
|
||||
|
||||
## Accumulated Context
|
||||
|
||||
### Decisions
|
||||
|
||||
Decisions are logged in PROJECT.md Key Decisions table.
|
||||
Recent decisions affecting current work:
|
||||
|
||||
- Fix SQLite bugs before any other work — data trust is the #1 priority; bug-fix tests become the regression suite for the refactor
|
||||
- Backend refactor must be behavior-neutral — all existing tests must pass before PostgreSQL is introduced
|
||||
- No ORM or query builder — raw SQL per store implementation; 8 operations across 3 tables is too small to justify a dependency
|
||||
- `DATABASE_URL` present activates PostgreSQL; absent falls back to SQLite with `DB_PATH` — no separate `DB_DRIVER` variable
|
||||
|
||||
### Pending Todos
|
||||
|
||||
None yet.
|
||||
|
||||
### Blockers/Concerns
|
||||
|
||||
- Phase 3: Verify `pgx/v5/stdlib` import path against pkg.go.dev before writing PostgreSQL query strings
|
||||
- Phase 3: Re-confirm `golang-migrate` v4.19.1 `database/sqlite` sub-package uses `modernc.org/sqlite` (not `mattn/go-sqlite3`) at implementation time
|
||||
|
||||
## Session Continuity
|
||||
|
||||
Last session: 2026-03-23
|
||||
Stopped at: Roadmap created; STATE.md initialized
|
||||
Resume file: None
|
||||
Reference in New Issue
Block a user