From a2ed8a64d6e1f3d65add33f7994fbb4fc6efd7cb Mon Sep 17 00:00:00 2001 From: Urban Modig Date: Sun, 26 Jul 2026 14:48:05 +0200 Subject: [PATCH] docs: establish HemHub feature roadmap --- AGENTS.md | 4 + README.md | 1 + docs/development.md | 23 ++- docs/roadmap.md | 439 ++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 458 insertions(+), 9 deletions(-) create mode 100644 docs/roadmap.md diff --git a/AGENTS.md b/AGENTS.md index 3c8be0b..1ad942f 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -13,3 +13,7 @@ under `docs/`. - En feature ska uppdatera berörda dokument så att repositoryt förblir projektets facit även efter att feature-branchen har raderats. +- Nästa feature ska väljas från `docs/roadmap.md`. +- Roadmapen ska uppdateras innan en feature delas, flyttas, ersätts eller läggs + till. En enskild dialog får inte etablera en alternativ featureplan utan att + repositoryts roadmap uppdateras. diff --git a/README.md b/README.md index b5e7f76..2a91969 100644 --- a/README.md +++ b/README.md @@ -56,6 +56,7 @@ Projektets aktuella arkitektur, utvecklingsprocess, övergripande beslut och featurehistorik finns i [`docs/`](docs/): - [arkitektur](docs/architecture.md) +- [roadmap och planerad featureordning](docs/roadmap.md) - [utvecklingsprocess](docs/development.md) - [arkitekturbeslut](docs/decisions/) - [implementerade features](docs/features/) diff --git a/docs/development.md b/docs/development.md index 372a6e1..3e1c99e 100644 --- a/docs/development.md +++ b/docs/development.md @@ -10,6 +10,9 @@ projektets läge begripligt utan tidigare dialoger eller raderade branches. - Skapa branchen från en uppdaterad `main`. - En feature per ChatGPT-dialog är en praktisk arbetsform, inte en dokumentationskälla. +- Välj nästa feature från [`roadmap.md`](roadmap.md). +- Uppdatera roadmapen innan en feature delas, flyttas, ersätts eller läggs till. + En dialog får inte skapa en parallell featureplan som saknas i repositoryt. - Skapa eller uppdatera feature-dokumentet inom samma feature. - Ge Codex en tydligt avgränsad specifikation. - Implementera endast uttryckliga krav och undvik spekulativ funktionalitet. @@ -25,15 +28,17 @@ kunna raderas utan att projektkunskap går förlorad. ## Rekommenderad featureprocess 1. Uppdatera `main`. -2. Skapa en avgränsad branch. -3. Skapa eller uppdatera feature-dokumentet. -4. Implementera specifikationen. -5. Kör relevanta automatiska tester och bygge. -6. Gör manuell verifiering där det är relevant. -7. Uppdatera dokumentationen så att den beskriver den faktiska lösningen. -8. Commit och push efter uttrycklig instruktion. -9. Merge efter verifiering. -10. Radera den mergade branchen. +2. Välj nästa feature från roadmapen och dokumentera först eventuell ändring av + planen. +3. Skapa en avgränsad branch. +4. Skapa eller uppdatera feature-dokumentet. +5. Implementera specifikationen. +6. Kör relevanta automatiska tester och bygge. +7. Gör manuell verifiering där det är relevant. +8. Uppdatera dokumentationen så att den beskriver den faktiska lösningen. +9. Commit och push efter uttrycklig instruktion. +10. Merge efter verifiering. +11. Radera den mergade branchen. ## Verifiering före merge diff --git a/docs/roadmap.md b/docs/roadmap.md new file mode 100644 index 0000000..4d4e703 --- /dev/null +++ b/docs/roadmap.md @@ -0,0 +1,439 @@ +# HemHub roadmap + +## Syfte + +Roadmapen är HemHubs styrande plan för val och ordning av kommande features. Den +utgår från den faktiska implementationen efter Feature 2 och från beslut som +dokumenterats i arkitektur- och beslutsdokumenten. + +Planen är ändringsbar. Ordningen uttrycker nuvarande prioritering och beroenden, +inte ett löfte om att alla features måste genomföras oförändrade. + +## Regler för användning + +- Nästa feature ska väljas från denna roadmap. +- Feature 0–2 behåller sina nummer och sin historiska betydelse. +- Ändra roadmapen innan en feature delas, flyttas, ersätts eller läggs till. +- Dokumentera motiv och beroendeförändringar innan utveckling påbörjas. +- En ChatGPT- eller Codex-dialog får inte skapa en alternativ featureplan utan + att roadmapen först uppdateras i repositoryt. +- Håll varje feature tillräckligt liten för separat implementation och + verifiering. +- Beskriv mål och affärsregler här; bindande implementationsdetaljer hör till + feature-specifikationen och relevanta beslutsdokument. +- En designfeature producerar dokument och beslut, inte produktionskod, om inget + annat uttryckligen beslutas. + +Följande statusvärden används: + +- **Klar** – implementerad, verifierad och mergad. +- **Planerad** – ingår i nuvarande ordning men har inte påbörjats. +- **Pågående** – utveckling pågår i en aktiv feature. +- **Villkorad** – genomförs endast om det angivna villkoret uppfylls. +- **Ersatt** – har ersatts av en dokumenterad annan feature eller plan. + +## Nuvarande läge + +Feature 0–2 är klara. Den aktuella applikationen har: + +- ett monorepo med separat React/Vite-frontend och Spring Boot-backend; +- centralt lagrade användare och ett lokalt browserval av aktiv användare; +- gemensamma uppgifter med titel, valfri beskrivning och status; +- skapande och listning av uppgifter; +- en bräda med Väntande, Pågående och Klart; +- nya uppgifter som alltid skapas med status `WAITING`. + +Det finns ännu inga poäng, uppgiftstilldelningar, statusändringar, +drag-and-drop, redigeringar, raderingar, deadlines eller återkommande uppgifter. +Nuvarande användarval är inte autentisering. + +**Feature 3 – Uppgiftspoäng är nästa planerade produktfeature.** + +## Featureöversikt + +| Feature och namn | Status | Beroenden | Huvudsakligt resultat | +| --- | --- | --- | --- | +| 0 – Projektgrund | Klar | – | Körbar frontend, backend och lokal API-koppling | +| 1 – Användarval | Klar | 0 | Centrala användare och lokalt aktivt användar-id | +| 2 – Skapa uppgifter | Klar | 0–1 | Gemensamma uppgifter och trekolumnsbräda | +| 3 – Uppgiftspoäng | Planerad | 2 | Poäng på uppgifter | +| 4 – Tilldelning | Planerad | 1–2 | Valfri ansvarig användare | +| 5 – Statusändring | Planerad | 4 | Backendstyrda statusövergångar | +| 6 – Drag-and-drop | Planerad | 5 | Kortflytt via status-API | +| 7 – Radera uppgift | Planerad | 2 | Bekräftad radering | +| 8 – Redigera uppgift | Planerad | 3 | Titel, beskrivning och poäng | +| 9 – Deadline | Planerad | 2 | Valfri deadline och förseningsmarkering | +| 10 – Sökning och filtrering | Planerad | 2; 4 för ansvarig; 9 för deadline | Sökning och filter på brädan | +| 11 – Design av återkommande uppgifter | Planerad | 3–5, 9 | Beslut och plan, ingen produktionskod | +| 12 – Återkommande uppgifter | Planerad | 5, 9, 11 | Implementerad återkommandemodell | +| 13 – Poänghistorik och summering | Planerad | 3–5, 12 | Slutförandehistorik och summering | +| 14 – PostgreSQL | Planerad | 0–13 | Verifierad produktionsdatabas | +| 15 – Dockerpaketering | Planerad | 14 | Images och produktionslik lokal körning | +| 16 – Pipeline och deployment | Planerad | 15 | Bygge, publicering och drift på Biff | +| 17 – Autentisering | Villkorad | 16, extern åtkomst | Säker internetexponering | + +## Genomförda features + +### Feature 0 – Projektgrund + +**Status:** Klar + +Feature 0 etablerade monorepot, React/Vite-frontend, Spring Boot-backend, +health-endpoint, lokal Vite-proxy och grundtester. Den faktiska lösningen +beskrivs i +[`000-project-foundation.md`](features/000-project-foundation.md). + +### Feature 1 – Användarval + +**Status:** Klar + +Feature 1 införde skapande och listning av användare, val av aktiv användare och +lokal lagring av användarens id. Lösningen är ett browserlokalt användarval, +inte riktig autentisering. Den faktiska lösningen beskrivs i +[`001-user-selection.md`](features/001-user-selection.md). + +### Feature 2 – Skapa uppgifter + +**Status:** Klar + +Feature 2 införde en grundläggande uppgiftsmodell, API för att lista och skapa +uppgifter samt en bräda med tre statuskolumner. Uppgifter har titel, valfri +beskrivning och status; nya uppgifter skapas som `WAITING`. Den faktiska +lösningen beskrivs i +[`002-task-creation.md`](features/002-task-creation.md). + +## Fas 1 – Komplettera den centrala uppgiftsmodellen + +Fasen lägger till den domändata och de backendregler som behövs innan mer +interaktiv brädhantering införs. + +### Feature 3 – Uppgiftspoäng + +**Status:** Planerad + +**Beroenden:** Feature 2 + +**Mål:** + +- lägga till obligatoriska poäng på uppgifter; +- välja och dokumentera poängskala; +- ange poäng vid skapande; +- visa poäng på uppgiftskort; +- migrera befintliga uppgifter kontrollerat. + +Feature 3 ligger först eftersom poäng blir ett centralt uppgiftsfält som senare +ska kunna redigeras och historikföras. + +**Öppna frågor:** + +- exakt poängskala; +- standardvärde för befintliga uppgifter. + +### Feature 4 – Tilldelning av uppgifter + +**Status:** Planerad + +**Beroenden:** Feature 1 och Feature 2 + +**Mål:** + +- lägga till en valfri ansvarig användare; +- tillåta ansvarig vid skapande; +- visa ansvarig på uppgiftskort; +- kunna ändra ansvarig på en befintlig uppgift. + +En väntande uppgift får vara tilldelad eller otilldelad. Tilldelning införs före +statusändring eftersom en pågående uppgift senare måste ha en ansvarig. + +**Öppna frågor:** + +- om en uppgift ska ha endast en ansvarig; +- hur borttagna användare ska hanteras när användarradering införs. + +### Feature 5 – Statusändring och statusregler + +**Status:** Planerad + +**Beroenden:** Feature 4 + +**Mål:** + +- införa backend-API för statusändring; +- stödja `WAITING`, `IN_PROGRESS` och `COMPLETED`; +- säkerställa statusregler i backend; +- ge ett enkelt UI för statusändring före drag-and-drop. + +`IN_PROGRESS` kräver en ansvarig användare. Statusflödet införs före +drag-and-drop så att affärsregeln och API:t kan verifieras utan att samtidigt +bygga en komplex interaktion. + +**Öppna frågor:** + +- vad som sker när en otilldelad uppgift sätts till `IN_PROGRESS`; +- om aktiv användare ska föreslås automatiskt; +- vad som sker om ansvarig tas bort från en pågående uppgift. + +### Feature 6 – Drag-and-drop + +**Status:** Planerad + +**Beroenden:** Feature 5 + +**Mål:** + +- flytta uppgiftskort mellan statuskolumner; +- använda status-API:t från Feature 5; +- hantera serverfel och återställning av UI; +- hantera en otilldelad uppgift som flyttas till Pågående. + +Drag-and-drop kommer efter det enklare statusflödet för att återanvända +verifierade backendregler. + +**Öppna frågor:** + +- optimistisk eller serverbekräftad uppdatering; +- exakt tilldelningsflöde vid flytt till Pågående. + +## Fas 2 – Hantering av uppgifter + +Fasen kompletterar livscykeln för enskilda uppgifter efter att den centrala +modellen och statusreglerna finns. + +### Feature 7 – Radera uppgift + +**Status:** Planerad + +**Beroenden:** Feature 2 + +**Mål:** + +- införa backend-API för radering; +- radera en uppgift från brädan; +- kräva bekräftelse före radering. + +Radering hålls separat från redigering så att databorttagning och dess +konsekvenser kan verifieras isolerat. + +**Öppen fråga:** + +- permanent radering eller mjuk radering. + +### Feature 8 – Redigera uppgift + +**Status:** Planerad + +**Beroenden:** Feature 3 + +**Mål:** + +- ändra titel; +- ändra beskrivning; +- ändra poäng. + +Featuren ligger efter poäng för att redigeringsflödet ska omfatta den då +aktuella uppgiftsmodellen. Ansvarig ska fortsatt ändras genom +tilldelningsflödet från Feature 4 och status genom statusflödet från Feature 5. + +### Feature 9 – Deadline + +**Status:** Planerad + +**Beroenden:** Feature 2 + +**Mål:** + +- lägga till en valfri deadline; +- stödja beslutad representation av datum och eventuell tid; +- visa deadline på uppgiftskort; +- markera försenade uppgifter. + +Deadline införs före återkommande uppgifter eftersom framtida förekomster måste +kunna ärva eller beräkna deadlines. + +**Öppna frågor:** + +- datum utan tid eller datum och tid; +- tidszonshantering; +- definition av en försenad uppgift. + +### Feature 10 – Sökning och filtrering + +**Status:** Planerad + +**Beroenden:** Feature 2; Feature 4 för ansvarigfilter; Feature 9 om +deadlinefilter ska ingå + +**Mål:** + +- söka på titel och beskrivning; +- filtrera på ansvarig och status; +- eventuellt filtrera på deadline. + +Datamängden i ett familjehushåll är sannolikt liten. Klientbaserad sökning kan +därför vara tillräcklig initialt, men valet ska göras i feature-specifikationen. +Sökning på titel och beskrivning samt statusfiltrering kan byggas från Feature +2. Filtrering på ansvarig kräver Feature 4, och deadlinefilter kräver Feature 9 +om det ska ingå. + +**Öppen fråga:** + +- klientbaserad eller serverbaserad sökning. + +## Fas 3 – Återkommande arbete och historik + +Fasen kräver först ett uttryckligt modellbeslut, eftersom återkommande arbete +påverkar status, deadline, ansvarig och poäng. + +### Feature 11 – Design av återkommande uppgifter + +**Status:** Planerad + +**Typ:** Designfeature + +**Beroenden:** Beslutade modeller från Feature 3–5 och Feature 9 + +**Ingen produktionskod ska implementeras i denna feature.** + +**Mål:** + +- besluta skillnaden mellan uppgiftsmall och konkret förekomst; +- definiera hur nästa förekomst skapas; +- definiera vad slutförande betyder; +- definiera hur en förekomst hoppas över; +- definiera hur ändringar påverkar framtida förekomster; +- definiera hur ansvarig, poäng och deadline ärvs. + +Resultatet ska vara ett beslutsdokument och en avgränsad implementationsplan för +Feature 12. Designsteget ligger före implementationen för att undvika att +domänbeslut byggs in implicit. + +### Feature 12 – Implementera återkommande uppgifter + +**Status:** Planerad + +**Beroenden:** Feature 5, Feature 9 och Feature 11 + +**Mål:** + +- implementera modellen som beslutades i Feature 11. + +### Feature 13 – Poänghistorik och summering + +**Status:** Planerad + +**Beroenden:** Feature 3, Feature 4, Feature 5 och Feature 12 + +**Mål:** + +- registrera vem som slutförde en uppgift; +- registrera när uppgiften slutfördes; +- summera poäng per användare och period; +- visa enkel historik. + +Historik ligger efter status, poäng och återkommande uppgifter eftersom +slutförandet måste vara en backendvaliderad händelse med ett definierat +poängvärde och en definierad konkret förekomst. + +**Öppna frågor:** + +- om tilldelad och slutförande användare kan vara olika; +- om poäng delas ut vid varje återkommande förekomst; +- hur återöppnade uppgifter påverkar historik. + +## Fas 4 – Produktion + +Produktionsfasen realiserar den beslutade riktningen i +[`005-production-deployment-direction.md`](decisions/005-production-deployment-direction.md). +Inget i denna fas är implementerat i nuläget. + +### Feature 14 – PostgreSQL och produktionsdatabas + +**Status:** Planerad + +**Beroenden:** Föregående produktfeatures vars persistens ska produktionssättas + +**Mål:** + +- lägga till produktionskonfiguration för PostgreSQL; +- verifiera Flyway-migreringar mot PostgreSQL; +- införa PostgreSQL-baserade integrationstester, exempelvis med Testcontainers; +- behålla en enkel lokal utvecklingsupplevelse. + +PostgreSQL införs före paketering för att databasdrivrutin, migreringar och +konfiguration ska vara verifierade innan en produktionslik stack byggs. + +**Öppen fråga:** + +- om lokal utveckling fortsatt ska kunna använda H2. + +### Feature 15 – Dockerpaketering + +**Status:** Planerad + +**Beroenden:** Feature 14 + +**Mål:** + +- skapa en backend-image; +- skapa en frontend-image; +- stödja produktionslik lokal körning; +- ge same-origin `/api` via Nginx. + +Paketeringen kommer före pipelinearbetet så att images kan byggas och verifieras +lokalt. + +### Feature 16 – Pipeline och deployment + +**Status:** Planerad + +**Beroenden:** Feature 15 + +**Mål:** + +- skapa en Drone-pipeline; +- publicera images till ett privat registry; +- driftsätta på Ubuntu-servern Biff; +- uppdatera tjänster med Watchtower; +- införa nödvändig Nginx-konfiguration; +- hantera secrets utanför Git. + +Exakta miljödetaljer ska beslutas inom featuren och känsliga värden ska inte +committas. + +## Fas 5 – Eventuell extern åtkomst + +### Feature 17 – Autentisering och internetexponering + +**Status:** Villkorad + +**Beroenden:** Beslut att exponera HemHub mot internet och en säker +produktionsgrund, normalt Feature 16 + +Featuren ska endast genomföras om HemHub ska göras åtkomlig från internet. +Nuvarande aktiva användarval är uttryckligen inte autentisering. + +**Mål:** + +- införa riktig autentisering; +- införa behörighetsregler; +- använda säker sessions- eller tokenhantering; +- konfigurera TLS och extern exponering; +- säkerhetsgranska API och deployment. + +## Öppna tvärgående frågor + +- Vilken poängskala ska användas och vilket standardvärde får befintliga + uppgifter? +- Ska uppgifter raderas permanent eller mjukt? +- Hur ska datum, tider och tidszoner representeras? +- Ska H2 behållas för lokal utveckling efter PostgreSQL-införandet? +- Hur ska användare senare kunna redigeras eller raderas, särskilt när de är + ansvariga för eller har slutfört uppgifter? +- Vid vilken typ av extern åtkomst krävs riktig autentisering? +- Hur ska UI-designen från befintliga skisser införas inkrementellt utan att + blanda in framtida funktionalitet? + +## Ändringshistorik + +- 2026-07-26: Roadmapen etablerades. Feature 0–2 markerades som klara, Feature + 3–16 planerades och Feature 17 markerades som villkorad. -- 2.49.0