hemhub/docs/roadmap.md

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–7 är klara och finns på main. 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, status och poäng;
• skapande och listning av uppgifter;
• valfri tilldelning av högst en ansvarig användare per uppgift;
• tilldelning och byte av ansvarig i samtliga statusar;
• borttagning av ansvarig i WAITING och COMPLETED;
• backendstyrda statusändringar mellan WAITING, IN_PROGRESS och COMPLETED;
• automatisk tilldelning till aktiv användare när en otilldelad uppgift påbörjas;
• drag-and-drop mellan statuskolumner med optimistisk flytt och rollback;
• serverbekräftad permanent radering med bekräftelsedialog;
• en bräda med Väntande, Pågående och Klart;
• nya uppgifter som alltid skapas med status WAITING.

Tilldelning och status är separata egenskaper; tilldelningsflödet ändrar inte uppgiftens status. Alla direkta statusövergångar är tillåtna och IN_PROGRESS kräver ansvarig. Det finns ännu ingen redigering, deadline eller återkommande uppgift. Nuvarande användarval är inte autentisering.

Feature 8 – Redigera uppgift ä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	Klar	2	Poäng på uppgifter
4 – Tilldelning	Klar	1–2	Valfri ansvarig användare
5 – Statusändring	Klar	4	Backendstyrda statusövergångar
6 – Drag-and-drop	Klar	5	Kortflytt via status-API
7 – Radera uppgift	Klar	2	Bekräftad permanent 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.

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.

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.

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: Klar

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.

Poängskalan är beslutad till alla heltal mellan 1 och 99. V3-migreringen ger eventuella befintliga uppgifter värdet 1 innan kolumnen görs obligatorisk; databasen har inget permanent defaultvärde.

Feature 4 – Tilldelning av uppgifter

Status: Klar

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 och har högst en ansvarig. Tilldelning införs före statusändring eftersom en pågående uppgift senare måste ha en ansvarig. Hur borttagna användare ska hanteras är fortsatt öppet tills användarradering införs.

Feature 5 – Statusändring och statusregler

Status: Klar

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. Feature 5 återanvänder Feature 4:s tilldelningsmodell och särskilda API för ansvarig; statusändring sker i ett separat statusflöde.

En otilldelad uppgift som sätts till IN_PROGRESS tilldelas automatiskt den aktiva browseranvändaren. En befintlig ansvarig behålls. Ansvarig kan bytas men inte tas bort medan uppgiften är pågående.

Feature 6 – Drag-and-drop

Status: Klar

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.

Drag-and-drop använder en kontrollerad optimistisk flytt. Vid fel återställs hela den tidigare task-versionen. En otilldelad uppgift som dras till Pågående använder Feature 5:s befintliga automatiska tilldelning till aktiv användare. Serverns fullständiga task-respons ersätter alltid det optimistiska värdet. Statusknapparna förblir tills vidare serverbekräftade. Implementation och automatisk samt manuell verifiering är genomförda, och featuren är mergad till main.

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: Klar

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.

Feature 7 använder permanent fysisk radering genom DELETE /api/tasks/{taskId}. En bekräftelsemodal visas före anropet och frontend behåller kortet tills backend har bekräftat raderingen. Operationen använder samma låsning per task-id som status, tilldelning och drag-and-drop. Ett 404 TASK_NOT_FOUND tar bort ett känt inaktuellt lokalt kort. Implementation samt automatisk och manuell verifiering är genomförda, och featuren är mergad till main.

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. 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

• 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-27: Feature 7 verifierades och mergades. Permanent, serverbekräftad radering infördes, och Feature 8 blev nästa planerade produktfeature.
• 2026-07-27: Feature 6 verifierades och mergades. Optimistisk drag-and-drop med full rollback infördes, och Feature 7 blev nästa planerade produktfeature.
• 2026-07-27: Feature 5 verifierades och mergades. Backendstyrda statusövergångar, automatisk tilldelning vid påbörjande och statusberoende tilldelningsregler infördes. Feature 6 blev nästa planerade produktfeature.
• 2026-07-26: Feature 3 och Feature 4 markerades som klara efter verifiering och merge. Feature 5 blev nästa planerade produktfeature.
• 2026-07-26: Roadmapen etablerades. Feature 0–2 markerades som klara, Feature 3–16 planerades och Feature 17 markerades som villkorad.