feat: add task points

docs/architecture.md

@@ -63,9 +63,9 @@ Aktuella endpoints:
 
 ### Databas och migreringar
 
-Lokal körning använder en filbaserad H2-databas under `backend/data`. Katalogen
-ignoreras av Git. Automatiska backendtester använder en separat H2-databas i
-minnet.
+Lokal körning använder en H2-databas i minnet. Databasen finns under
+backendprocessens livstid och lokal utvecklingsdata återställs när backend
+startas om. Automatiska backendtester använder en separat H2-databas i minnet.
 
 Båda anslutningarna använder H2:s `MODE=PostgreSQL`,
 `DATABASE_TO_LOWER=TRUE` och `DEFAULT_NULL_ORDERING=HIGH`. Det är en verifierbar
@@ -76,6 +76,7 @@ Flyway kör migreringarna:
 
 - `V1__create_users.sql`
 - `V2__create_tasks.sql`
+- `V3__add_task_points.sql`
 
 Hibernate är konfigurerat med `ddl-auto=validate`; Flyway skapar schemat och
 Hibernate validerar entiteterna mot det.
@@ -102,11 +103,13 @@ En uppgift lagras i tabellen `task` med:
 - `title`: obligatorisk titel, högst 100 tecken;
 - `description`: valfri beskrivning, högst 500 tecken;
 - `status`: `WAITING`, `IN_PROGRESS` eller `COMPLETED`;
+- `points`: obligatoriskt heltal mellan 1 och 99;
 - `created_at`: en `Instant`, lagrad som `TIMESTAMP WITH TIME ZONE`.
 
 Status lagras som enumens textvärde genom `EnumType.STRING`. Nya uppgifter får
-alltid status `WAITING`. Det finns ingen relation mellan uppgifter och
-användare; alla aktiva användare ser samma uppgiftslista.
+alltid status `WAITING`. Poängintervallet skyddas i backend och med en
+databasconstraint. Det finns ingen relation mellan uppgifter och användare;
+alla aktiva användare ser samma uppgiftslista.
 
 ### Aktiv användare
 

docs/features/003-task-points.md

@@ -2,7 +2,7 @@
 
 ## Status
 
-Planerad.
+Pågående.
 
 ## Bakgrund
 
@@ -315,17 +315,16 @@ Detta innebär att Feature 3 inte behöver migrera verkliga befintliga
 utvecklingsposter. En ny databas skapas direkt med det obligatoriska
 poängfältet.
 
-Codex ska kontrollera repositoryts faktiska konfiguration. Om H2 för närvarande
-är filbaserad ska den ändras till in-memory och relevant
-utvecklingsdokumentation ska uppdateras.
+Före Feature 3 var lokal H2 filbaserad. Feature 3 ändrar utvecklingsanslutningen
+till in-memory och uppdaterar utvecklingsdokumentationen i samma ändring.
 
 ## Schemahantering och framtida migrering
 
 Att lokal utvecklingsdata inte bevaras innebär inte att framtida
 produktionsdata kan återställas vid varje release.
 
-När HemHub börjar använda en beständig Postgres-databas med data som ska bevaras
-måste schemaändringar hanteras med kontrollerade migreringar.
+När HemHub börjar använda en beständig PostgreSQL-databas med data som ska
+bevaras måste schemaändringar hanteras med kontrollerade migreringar.
 
 Feature 3 behöver inte införa eller färdigställa hela den framtida
 produktionsstrategin om den ännu inte finns i repositoryt.

docs/roadmap.md

@@ -38,16 +38,16 @@ 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;
+- gemensamma uppgifter med titel, valfri beskrivning, status och poäng;
 - 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.
+Det finns ännu inga 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 3 – Uppgiftspoäng är pågående.**
 
 ## Featureöversikt
 
@@ -56,7 +56,7 @@ Nuvarande användarval är inte autentisering.
 | 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 |
+| 3 – Uppgiftspoäng | Pågående | 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 |
@@ -109,7 +109,7 @@ interaktiv brädhantering införs.
 
 ### Feature 3 – Uppgiftspoäng
 
-**Status:** Planerad
+**Status:** Pågående
 
 **Beroenden:** Feature 2
 
@@ -124,10 +124,9 @@ interaktiv brädhantering införs.
 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.
+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
 
@@ -422,8 +421,6 @@ Nuvarande aktiva användarval är uttryckligen inte autentisering.
 
 ## Ö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?