docs: align completed feature status

docs/features/003-task-points.md

@@ -2,7 +2,7 @@
 
 ## Status
 
-Pågående.
+Färdig och mergad till `main`.
 
 ## Bakgrund
 
@@ -343,7 +343,7 @@ Repositoryts faktiska arkitektur och dokumentation har företräde.
 
 ## Backendtester
 
-Feature 3 ska minst verifiera att:
+Backendtesterna verifierar att:
 
 - en uppgift kan skapas med ett giltigt `points`;
 - det skapade API-svaret innehåller samma `points`;
@@ -356,12 +356,12 @@ Feature 3 ska minst verifiera att:
 - negativa värden ger `400 Bad Request`;
 - `points: 100` ger `400 Bad Request`.
 
-Testerna ska följa befintlig teststil och utöka nuvarande tester där det är
-lämpligt.
+Testerna följer den befintliga teststilen och utökar de tidigare
+uppgifts-API-testerna.
 
 ## Frontendtester
 
-Feature 3 ska minst verifiera att:
+Frontendtesterna verifierar att:
 
 - skapandedialogen öppnas med poängvärdet `1`;
 - ett giltigt poängvärde skickas i create-anropet;
@@ -373,11 +373,11 @@ Feature 3 ska minst verifiera att:
 - ett uppgiftskort visar uppgiftens dynamiska poängbadge;
 - badgen visar värdet från uppgiftsdata, exempelvis `7 p`.
 
-Testerna ska inte vara beroende av en viss pixelplacering eller detaljerad CSS.
+Testerna är inte beroende av en viss pixelplacering eller detaljerad CSS.
 
 ## Manuell verifiering
 
-Följande ska verifieras manuellt:
+Följande verifierades manuellt:
 
 1. Starta frontend och backend enligt projektets utvecklingsinstruktioner.
 2. Skapa en uppgift utan att ändra poängfältet.
@@ -436,3 +436,8 @@ Dokumentation, implementation och tester ska uppdateras tillsammans.
 
 Codex ska inte committa, pusha, skapa pull request eller merga utan uttrycklig
 instruktion.
+
+## Relaterade commits
+
+- `059d4da9214969ed3e28592178160da6de614b4d` – `feat: add task points`
+- `2e62261f49bb3142e28882483e41e0250ab11c5f` – merge till `main`

docs/features/004-task-assignment.md

@@ -2,7 +2,7 @@
 
 ## Status
 
-Pågående.
+Färdig och mergad till `main`.
 
 ## Bakgrund
 
@@ -95,7 +95,7 @@ create-requestens `assigneeId`, kortens redigerbara och statiska lägen,
 tilldelningsrequest, vänteläge, serverbekräftad uppdatering, av-tilldelning och
 fel utan optimistisk ändring.
 
-Manuell verifiering ska omfatta skapande med och utan ansvarig, tilldelning,
+Manuell verifiering genomfördes för skapande med och utan ansvarig, tilldelning,
 byte, av-tilldelning, bevarad status, omladdning, statiska kontroller för andra
 statusar, felrespons och projektets normala desktop- och mobilbredder.
 
@@ -119,4 +119,5 @@ det tidigare värdet ligger kvar tills backend svarar.
 
 ## Relaterade commits
 
-Fylls i när featuren har committats.
+- `aaebe888f3bae43b3413e9fa3893fec90afac8b4` – `feat: add task assignment`
+- `d78611f5f77374228f1f69b66734931a988f8355` – merge till `main`

docs/roadmap.md

@@ -34,21 +34,24 @@ Följande statusvärden används:
 
 ## Nuvarande läge
 
-Feature 0–2 är klara. Den aktuella applikationen har:
+Feature 0–4 ä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, status och poäng;
 - skapande och listning av uppgifter;
+- valfri tilldelning av högst en ansvarig användare per uppgift;
+- tilldelning, byte och borttagning av ansvarig för väntande uppgifter;
 - en bräda med Väntande, Pågående och Klart;
 - nya uppgifter som alltid skapas med status `WAITING`.
 
-Tilldelning av högst en ansvarig användare per uppgift är under utveckling. Det
-finns ännu inga statusändringar, drag-and-drop, redigeringar, raderingar,
-deadlines eller återkommande uppgifter.
+Tilldelning och status är separata egenskaper; tilldelningsflödet ändrar inte
+uppgiftens status. Det finns ännu inga statusändringar, drag-and-drop,
+redigeringar, raderingar, deadlines eller återkommande uppgifter.
 Nuvarande användarval är inte autentisering.
 
-**Feature 4 – Tilldelning av uppgifter är pågående.**
+**Feature 5 – Statusändring och statusregler är nästa planerade
+produktfeature.**
 
 ## Featureöversikt
 
@@ -57,8 +60,8 @@ 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 | Pågående | 2 | Poäng på uppgifter |
-| 4 – Tilldelning | Pågående | 1–2 | Valfri ansvarig användare |
+| 3 – Uppgiftspoäng | Klar | 2 | Poäng på uppgifter |
+| 4 – Tilldelning | Klar | 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 |
@@ -110,7 +113,7 @@ interaktiv brädhantering införs.
 
 ### Feature 3 – Uppgiftspoäng
 
-**Status:** Pågående
+**Status:** Klar
 
 **Beroenden:** Feature 2
 
@@ -131,7 +134,7 @@ databasen har inget permanent defaultvärde.
 
 ### Feature 4 – Tilldelning av uppgifter
 
-**Status:** Pågående
+**Status:** Klar
 
 **Beroenden:** Feature 1 och Feature 2
 
@@ -162,7 +165,9 @@ senare måste ha en ansvarig. Hur borttagna användare ska hanteras är fortsatt
 
 `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.
+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.
 
 **Öppna frågor:**
 
@@ -430,5 +435,7 @@ Nuvarande aktiva användarval är uttryckligen inte autentisering.
 
 ## Ändringshistorik
 
+- 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.