feat: add task points

Reviewed-on: #5

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.

README.md

@@ -6,8 +6,8 @@ innehåller två separata applikationer:
 - en backend byggd med Java 21, Spring Boot och Maven
 - en frontend byggd med React, TypeScript, Vite och pnpm
 
-Backend använder en lokal filbaserad H2-databas i `backend/data`. Databasschemat
-hanteras med Flyway. Databasfilerna är lokala och ignoreras av Git.
+Backend använder en lokal H2-databas i minnet. Databasschemat hanteras med
+Flyway, och lokal utvecklingsdata återställs när backend startas om.
 
 API:t innehåller endpoints under `/api/users` för användare och `/api/tasks` för
 att skapa och lista gemensamma hushållsuppgifter.
@@ -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/)

backend/src/main/java/se/rubble/hemhub/task/CreateTaskRequest.java

@@ -1,5 +1,14 @@
 package se.rubble.hemhub.task;
 
-public record CreateTaskRequest(String title, String description) {
-}
+import tools.jackson.databind.JsonNode;
 
+public record CreateTaskRequest(String title, String description, JsonNode points) {
+
+    Integer integerPoints() {
+        if (points == null || !points.isIntegralNumber() || !points.canConvertToInt()) {
+            return null;
+        }
+
+        return points.intValue();
+    }
+}

backend/src/main/java/se/rubble/hemhub/task/Task.java

@@ -27,6 +27,9 @@ class Task {
     @Column(nullable = false, length = 20)
     private TaskStatus status;
 
+    @Column(nullable = false)
+    private int points;
+
     @Column(name = "created_at", nullable = false)
     private Instant createdAt;
 
@@ -38,11 +41,18 @@ class Task {
             String title,
             String description,
             TaskStatus status,
+            int points,
             Instant createdAt) {
+        if (points < 1 || points > 99) {
+            throw new InvalidTaskException(
+                    "Poäng måste vara ett heltal mellan 1 och 99.");
+        }
+
         this.id = id;
         this.title = title;
         this.description = description;
         this.status = status;
+        this.points = points;
         this.createdAt = createdAt;
     }
 
@@ -62,8 +72,11 @@ class Task {
         return status;
     }
 
+    int getPoints() {
+        return points;
+    }
+
     Instant getCreatedAt() {
         return createdAt;
     }
 }
-

backend/src/main/java/se/rubble/hemhub/task/TaskController.java

@@ -30,7 +30,7 @@ public class TaskController {
     public TaskResponse create(@RequestBody(required = false) CreateTaskRequest request) {
         return taskService.create(
                 request == null ? null : request.title(),
-                request == null ? null : request.description());
+                request == null ? null : request.description(),
+                request == null ? null : request.integerPoints());
     }
 }
-

backend/src/main/java/se/rubble/hemhub/task/TaskResponse.java

@@ -8,6 +8,7 @@ public record TaskResponse(
         String title,
         String description,
         TaskStatus status,
+        int points,
         Instant createdAt) {
 
     static TaskResponse from(Task task) {
@@ -16,7 +17,7 @@ public record TaskResponse(
                 task.getTitle(),
                 task.getDescription(),
                 task.getStatus(),
+                task.getPoints(),
                 task.getCreatedAt());
     }
 }
-

backend/src/main/java/se/rubble/hemhub/task/TaskService.java

@@ -33,7 +33,10 @@ class TaskService {
     }
 
     @Transactional
-    TaskResponse create(String requestedTitle, String requestedDescription) {
+    TaskResponse create(
+            String requestedTitle,
+            String requestedDescription,
+            Integer requestedPoints) {
         String title = requestedTitle == null ? "" : requestedTitle.trim();
         String description = normalizeDescription(requestedDescription);
 
@@ -47,11 +50,17 @@ class TaskService {
                     "Beskrivningen får innehålla högst 500 tecken.");
         }
 
+        if (requestedPoints == null) {
+            throw new InvalidTaskException(
+                    "Poäng måste vara ett heltal mellan 1 och 99.");
+        }
+
         Task task = new Task(
                 UUID.randomUUID(),
                 title,
                 description,
                 TaskStatus.WAITING,
+                requestedPoints,
                 Instant.now(clock));
 
         return TaskResponse.from(taskRepository.save(task));
@@ -70,4 +79,3 @@ class TaskService {
         return value.codePointCount(0, value.length());
     }
 }
-

backend/src/main/resources/application.properties

@@ -1,7 +1,6 @@
-spring.datasource.url=jdbc:h2:file:./data/hemhub;MODE=PostgreSQL;DATABASE_TO_LOWER=TRUE;DEFAULT_NULL_ORDERING=HIGH
+spring.datasource.url=jdbc:h2:mem:hemhub;MODE=PostgreSQL;DATABASE_TO_LOWER=TRUE;DEFAULT_NULL_ORDERING=HIGH;DB_CLOSE_DELAY=-1
 spring.datasource.username=sa
 spring.datasource.password=
 spring.jpa.hibernate.ddl-auto=validate
 spring.jpa.open-in-view=false
 spring.flyway.enabled=true
-

backend/src/main/resources/db/migration/V3__add_task_points.sql

@@ -0,0 +1,8 @@
+ALTER TABLE task ADD COLUMN points INTEGER;
+
+UPDATE task SET points = 1 WHERE points IS NULL;
+
+ALTER TABLE task ALTER COLUMN points SET NOT NULL;
+
+ALTER TABLE task
+    ADD CONSTRAINT ck_task_points_range CHECK (points BETWEEN 1 AND 99);

backend/src/test/java/se/rubble/hemhub/task/TaskApiTest.java

@@ -9,6 +9,7 @@ import org.springframework.beans.factory.annotation.Autowired;
 import org.springframework.boot.test.context.SpringBootTest;
 import org.springframework.http.MediaType;
 import org.springframework.test.web.servlet.MockMvc;
+import org.springframework.test.web.servlet.ResultActions;
 import org.springframework.test.web.servlet.setup.MockMvcBuilders;
 import org.springframework.web.context.WebApplicationContext;
 
@@ -41,7 +42,8 @@ class TaskApiTest {
                         .content("""
                                 {
                                   "title": "  Dammsuga  ",
-                                  "description": "  Bottenvåningen  "
+                                  "description": "  Bottenvåningen  ",
+                                  "points": 7
                                 }
                                 """))
                 .andExpect(status().isCreated())
@@ -49,7 +51,12 @@ class TaskApiTest {
                 .andExpect(jsonPath("$.title").value("Dammsuga"))
                 .andExpect(jsonPath("$.description").value("Bottenvåningen"))
                 .andExpect(jsonPath("$.status").value("WAITING"))
+                .andExpect(jsonPath("$.points").value(7))
                 .andExpect(jsonPath("$.createdAt").isString());
+
+        mockMvc.perform(get("/api/tasks"))
+                .andExpect(status().isOk())
+                .andExpect(jsonPath("$[0].points").value(7));
     }
 
     @Test
@@ -57,7 +64,7 @@ class TaskApiTest {
         mockMvc.perform(post("/api/tasks")
                         .contentType(MediaType.APPLICATION_JSON)
                         .content("""
-                                {"title": "Dammsuga", "description": "   "}
+                                {"title": "Dammsuga", "description": "   ", "points": 1}
                                 """))
                 .andExpect(status().isCreated())
                 .andExpect(jsonPath("$.description").value((Object) null));
@@ -66,18 +73,58 @@ class TaskApiTest {
     @Test
     void rejectsBlankAndTooLongTitles() throws Exception {
         assertInvalidTask("""
-                {"title": "   "}
+                {"title": "   ", "points": 1}
                 """);
-        assertInvalidTask("{\"title\": \"%s\"}".formatted("a".repeat(101)));
+        assertInvalidTask(
+                "{\"title\": \"%s\", \"points\": 1}".formatted("a".repeat(101)));
     }
 
     @Test
     void rejectsTooLongDescription() throws Exception {
         assertInvalidTask("""
-                {"title": "Dammsuga", "description": "%s"}
+                {"title": "Dammsuga", "description": "%s", "points": 1}
                 """.formatted("a".repeat(501)));
     }
 
+    @Test
+    void acceptsPointBoundaries() throws Exception {
+        createTaskWithPoints(1)
+                .andExpect(status().isCreated())
+                .andExpect(jsonPath("$.points").value(1));
+        createTaskWithPoints(99)
+                .andExpect(status().isCreated())
+                .andExpect(jsonPath("$.points").value(99));
+    }
+
+    @Test
+    void rejectsMissingNullAndOutOfRangePoints() throws Exception {
+        assertInvalidTask("""
+                {"title": "Saknas"}
+                """);
+        assertInvalidTask("""
+                {"title": "Null", "points": null}
+                """);
+        assertInvalidTask("""
+                {"title": "Noll", "points": 0}
+                """);
+        assertInvalidTask("""
+                {"title": "Negativ", "points": -1}
+                """);
+        assertInvalidTask("""
+                {"title": "För stor", "points": 100}
+                """);
+    }
+
+    @Test
+    void rejectsNonIntegerPoints() throws Exception {
+        assertInvalidTask("""
+                {"title": "Decimal", "points": 1.5}
+                """);
+        assertInvalidTask("""
+                {"title": "Text", "points": "sju"}
+                """);
+    }
+
     @Test
     void listsTasksOldestFirstWithIdAsTieBreaker() throws Exception {
         Instant older = Instant.parse("2026-07-24T10:00:00Z");
@@ -86,17 +133,25 @@ class TaskApiTest {
         UUID secondId = UUID.fromString("00000000-0000-0000-0000-000000000002");
         UUID newestId = UUID.fromString("00000000-0000-0000-0000-000000000003");
 
-        taskRepository.save(new Task(newestId, "Nyast", null, TaskStatus.WAITING, newer));
-        taskRepository.save(new Task(secondId, "Andra", null, TaskStatus.IN_PROGRESS, older));
-        taskRepository.save(new Task(firstId, "Första", null, TaskStatus.COMPLETED, older));
+        taskRepository.save(new Task(newestId, "Nyast", null, TaskStatus.WAITING, 3, newer));
+        taskRepository.save(new Task(secondId, "Andra", null, TaskStatus.IN_PROGRESS, 2, older));
+        taskRepository.save(new Task(firstId, "Första", null, TaskStatus.COMPLETED, 1, older));
 
         mockMvc.perform(get("/api/tasks"))
                 .andExpect(status().isOk())
                 .andExpect(jsonPath("$[0].title").value("Första"))
+                .andExpect(jsonPath("$[0].points").value(1))
                 .andExpect(jsonPath("$[1].title").value("Andra"))
                 .andExpect(jsonPath("$[2].title").value("Nyast"));
     }
 
+    private ResultActions createTaskWithPoints(int points) throws Exception {
+        return mockMvc.perform(post("/api/tasks")
+                .contentType(MediaType.APPLICATION_JSON)
+                .content("{\"title\": \"Uppgift %d\", \"points\": %d}"
+                        .formatted(points, points)));
+    }
+
     private void assertInvalidTask(String body) throws Exception {
         mockMvc.perform(post("/api/tasks")
                         .contentType(MediaType.APPLICATION_JSON)

backend/src/test/java/se/rubble/hemhub/task/TaskTest.java

@@ -0,0 +1,27 @@
+package se.rubble.hemhub.task;
+
+import java.time.Instant;
+import java.util.UUID;
+
+import org.junit.jupiter.api.Test;
+
+import static org.junit.jupiter.api.Assertions.assertThrows;
+
+class TaskTest {
+
+    @Test
+    void rejectsPointsOutsideAllowedRange() {
+        assertThrows(InvalidTaskException.class, () -> taskWithPoints(0));
+        assertThrows(InvalidTaskException.class, () -> taskWithPoints(100));
+    }
+
+    private Task taskWithPoints(int points) {
+        return new Task(
+                UUID.randomUUID(),
+                "Dammsuga",
+                null,
+                TaskStatus.WAITING,
+                points,
+                Instant.parse("2026-07-26T12:00:00Z"));
+    }
+}

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

docs/features/003-task-points.md

@@ -0,0 +1,438 @@
+# Feature 3 – Uppgiftspoäng
+
+## Status
+
+Pågående.
+
+## Bakgrund
+
+HemHub ska på sikt kunna använda spelifiering för att uppmuntra
+familjemedlemmar att utföra uppgifter. Exempel på framtida funktioner kan vara
+mål, achievements och belöningar baserade på hur många poäng en användare
+samlar under en viss period.
+
+Feature 3 inför den grundläggande poänginformationen på uppgiften. Funktionen
+registrerar endast uppgiftens poängvärde. Intjäning av poäng och övrig
+spelifiering införs i senare features.
+
+## Mål
+
+Feature 3 ska:
+
+- lägga till ett obligatoriskt poängvärde på varje uppgift;
+- låta användaren ange poäng när en uppgift skapas;
+- visa poängen på uppgiftskortet;
+- validera poängen konsekvent i frontend och backend;
+- dokumentera hur lokal utvecklingsdata hanteras.
+
+## Betydelsen av poäng
+
+Poängen uttrycker uppgiftens samlade värde utifrån hur:
+
+- tidskrävande uppgiften är;
+- besvärlig uppgiften är;
+- viktig uppgiften är.
+
+När poängintjäning införs i en senare feature ska samma värde motsvara hur många
+poäng användaren får när uppgiften slutförs.
+
+Poängen är inte en exakt tidsuppskattning. En snabb men viktig uppgift kan
+därför ha ett högre poängvärde än en längre men mindre betydelsefull uppgift.
+
+Feature 3 registrerar endast poängvärdet. Den ska inte registrera:
+
+- vem som har tjänat poängen;
+- om poängen har delats ut;
+- när poängen har tjänats in;
+- någon historik över poäng.
+
+## Poängskala
+
+Poäng ska vara ett heltal mellan 1 och 99, inklusive gränsvärdena.
+
+Alla heltal i intervallet är tillåtna. Feature 3 inför inte någon fast skala med
+fördefinierade steg.
+
+Giltiga exempel:
+
+- 1
+- 7
+- 25
+- 99
+
+Ogiltiga exempel:
+
+- inget värde;
+- `null`;
+- 0;
+- negativa tal;
+- 100 eller högre;
+- decimaltal;
+- text som inte kan tolkas som ett heltal.
+
+En fast poängskala kan införas senare om erfarenhet från användningen visar att
+det är lämpligt.
+
+## Avgränsning
+
+Feature 3 omfattar endast:
+
+- uppgiftens titel;
+- uppgiftens valfria beskrivning;
+- uppgiftens obligatoriska poängvärde;
+- visning av poäng på uppgiftskortet.
+
+Feature 3 ska inte införa:
+
+- tilldelning av uppgifter;
+- ändring av uppgiftsstatus;
+- drag-and-drop;
+- redigering av befintliga uppgifter;
+- radering av uppgifter;
+- deadlines;
+- återkommande uppgifter;
+- poänghistorik;
+- användares poängsaldo;
+- topplistor;
+- statistik;
+- mål;
+- achievements;
+- belöningar;
+- automatisk utdelning av poäng när en uppgift slutförs.
+
+Dessa funktioner hanteras i senare features enligt roadmapen.
+
+## Användarflöde
+
+När användaren öppnar dialogen för att skapa en uppgift ska formuläret
+innehålla:
+
+- titel;
+- beskrivning;
+- poäng.
+
+Poängfältet ska initialt innehålla värdet `1`.
+
+Användaren kan behålla standardvärdet eller ange ett annat heltal mellan 1 och
+99.
+
+När uppgiften skapas ska frontend alltid skicka poängvärdet uttryckligen till
+backend. Backend ska inte själv fylla i ett saknat värde.
+
+Efter att en uppgift har skapats framgångsrikt ska formuläret återställas.
+Poängfältet ska då återgå till `1`.
+
+Om dialogen stängs och senare öppnas igen ska poängfältet också börja på `1`.
+
+## Skapandedialog
+
+Poäng ska anges med ett vanligt numeriskt inmatningsfält.
+
+Fältet ska ha:
+
+- etiketten `Poäng`;
+- initialt värde `1`;
+- minsta värde `1`;
+- högsta värde `99`;
+- heltalssteg.
+
+En kort hjälptext kan visas:
+
+> 1–99 poäng beroende på hur tidskrävande, besvärlig eller viktig uppgiften är.
+
+Fältet får tillfälligt vara tomt medan användaren redigerar värdet. Frontend ska
+inte automatiskt återställa värdet till `1` medan användaren skriver.
+
+Validering ska främst ske när användaren försöker skicka formuläret. Avancerad
+validering vid varje tangenttryckning ingår inte i denna feature.
+
+## Frontendvalidering
+
+Frontend ska blockera skapandeanropet om poängen inte är ett heltal mellan 1 och
+99.
+
+Vid ett ogiltigt värde ska följande meddelande visas:
+
+> Poäng måste vara ett heltal mellan 1 och 99.
+
+Samma meddelande kan användas för:
+
+- tomt värde;
+- värde under 1;
+- värde över 99;
+- decimaltal;
+- annat ogiltigt innehåll.
+
+HTML-fältets attribut för minsta värde, högsta värde och heltalssteg får användas
+som stöd, men formulärlogiken ska också kontrollera värdet explicit.
+
+Backend är alltid den slutliga garanten för valideringsreglerna.
+
+## Visning på uppgiftskortet
+
+Uppgiftens poäng ska visas på uppgiftskortet som en kompakt och dynamisk badge.
+
+Badgen ska:
+
+- renderas som en vanlig React- och HTML-komponent;
+- använda text och CSS;
+- läsa värdet från uppgiftens `points`;
+- visa värdet i formatet `{points} p`.
+
+Exempel:
+
+- `1 p`
+- `7 p`
+- `99 p`
+
+Ingen genererad bild eller statisk grafik ska användas för själva poängvärdet.
+
+Placering och visuell utformning ska följa projektets befintliga skärmbilder och
+nuvarande kortdesign. Poängindikatorn ska ligga i kortets metadataområde på
+motsvarande plats som poängindikatorn i designreferensen.
+
+Mindre justeringar får göras för att passa den faktiska kortimplementationen.
+Feature 3 ska däremot inte införa en ny övergripande design för uppgiftskortet.
+
+## API
+
+Fältnamnet ska vara `points` genomgående i API, backend och frontend.
+
+### Skapa uppgift
+
+Requesten för att skapa en uppgift ska innehålla:
+
+```json
+{
+  "title": "Töm diskmaskinen",
+  "description": "Ställ in allt i rätt skåp",
+  "points": 3
+}
+```
+
+`points` är obligatoriskt.
+
+Backend ska inte tolka ett saknat värde som `1`.
+
+### Uppgiftssvar
+
+API-svar som innehåller en uppgift ska också innehålla `points`.
+
+Exempel:
+
+```json
+{
+  "id": "00000000-0000-0000-0000-000000000000",
+  "title": "Töm diskmaskinen",
+  "description": "Ställ in allt i rätt skåp",
+  "status": "WAITING",
+  "points": 3,
+  "createdAt": "2026-07-26T12:00:00Z"
+}
+```
+
+Det gäller både:
+
+- svaret efter att en uppgift skapats;
+- listning av uppgifter.
+
+Det exakta API-formatet ska i övrigt följa den befintliga implementationen.
+
+## Backendregler
+
+En uppgift får aldrig existera med ett poängvärde utanför intervallet 1–99.
+
+Regeln ska skyddas genom hela backend, inte bara i HTTP-lagret.
+
+Beroende på repositoryts befintliga struktur ska valideringen tillämpas på
+relevanta nivåer, exempelvis:
+
+- requestvalidering;
+- applikations- eller domänlogik;
+- entitetsmodell;
+- databasens schema.
+
+Implementation ska följa projektets etablerade kodstruktur och inte introducera
+ett nytt arkitekturmönster enbart för denna feature.
+
+## Felhantering
+
+Ett ogiltigt eller saknat `points` ska ge:
+
+```text
+400 Bad Request
+```
+
+Backend ska använda projektets befintliga felformat och befintliga
+felhantering.
+
+Feature 3 ska inte introducera en separat felmodell endast för poäng.
+
+Backend får ge mer precisa valideringsdetaljer för exempelvis:
+
+- saknat värde;
+- `null`;
+- värde under 1;
+- värde över 99.
+
+Frontend behöver inte återge varje backenddetalj separat, utan kan visa det
+gemensamma användarmeddelandet:
+
+> Poäng måste vara ett heltal mellan 1 och 99.
+
+Vid andra eller oväntade backendfel ska frontend fortsätta använda projektets
+befintliga generella felhantering.
+
+## Databas
+
+Databasschemat ska innehålla ett obligatoriskt heltalsfält för uppgiftens poäng.
+
+Det logiska slutläget är:
+
+```text
+points INTEGER NOT NULL
+```
+
+Databasen ska, om den befintliga schemahanteringen stödjer det, även skydda
+intervallet 1–99 med en motsvarande constraint.
+
+Databasen ska inte ha ett permanent defaultvärde för nya uppgifter. Nya
+uppgifter ska alltid få ett uttryckligt poängvärde från applikationen.
+
+Det förvalda värdet `1` är ett frontendbeteende och inte ett sätt för backend
+eller databasen att tyst komplettera ofullständiga anrop.
+
+## Lokal utvecklingsdatabas
+
+Den lokala utvecklingsdatabasen ska vara en in-memory H2-databas.
+
+Databasen och dess innehåll ska återställas när backend startas om.
+
+Lokal utvecklingsdata betraktas därför som tillfällig. Användare och uppgifter
+som skapats manuellt under utveckling behöver inte bevaras mellan starter.
+
+Detta innebär att Feature 3 inte behöver migrera verkliga befintliga
+utvecklingsposter. En ny databas skapas direkt med det obligatoriska
+poängfältet.
+
+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 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.
+
+Projektet använder redan Flyway och versionshanterade migreringar. Feature 3 ska
+därför lägga till en ny Flyway-migrering för poängfältet och inte ändra tidigare
+migreringar. Hibernate ska fortsatt validera schemat i stället för att skapa
+det.
+
+Bytet till in-memory H2 innebär att befintliga lokala utvecklingsposter inte
+behöver bevaras eller fyllas på med poäng. Själva schemaändringen ska ändå
+hanteras som en kontrollerad migrering så att migrationshistoriken förblir
+sammanhängande inför framtida beständig data.
+
+Repositoryts faktiska arkitektur och dokumentation har företräde.
+
+## Backendtester
+
+Feature 3 ska minst verifiera att:
+
+- en uppgift kan skapas med ett giltigt `points`;
+- det skapade API-svaret innehåller samma `points`;
+- listning av uppgifter innehåller `points`;
+- gränsvärdet `1` accepteras;
+- gränsvärdet `99` accepteras;
+- saknat `points` ger `400 Bad Request`;
+- `points: null` ger `400 Bad Request`;
+- `points: 0` ger `400 Bad Request`;
+- 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.
+
+## Frontendtester
+
+Feature 3 ska minst verifiera att:
+
+- skapandedialogen öppnas med poängvärdet `1`;
+- ett giltigt poängvärde skickas i create-anropet;
+- tomt poängfält blockerar submit;
+- ett värde under 1 blockerar submit;
+- ett värde över 99 blockerar submit;
+- ett ogiltigt värde visar felmeddelandet;
+- formuläret återställs till poängvärdet `1` efter lyckad skapning;
+- 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.
+
+## Manuell verifiering
+
+Följande ska verifieras manuellt:
+
+1. Starta frontend och backend enligt projektets utvecklingsinstruktioner.
+2. Skapa en uppgift utan att ändra poängfältet.
+3. Verifiera att uppgiften får `1 p`.
+4. Skapa en uppgift med ett mellanvärde, exempelvis `7`.
+5. Verifiera att uppgiften får `7 p`.
+6. Skapa en uppgift med `99`.
+7. Verifiera att uppgiften får `99 p`.
+8. Försök skapa en uppgift med tomt poängfält.
+9. Verifiera att anropet blockeras och att rätt felmeddelande visas.
+10. Försök använda värdena `0` och `100`.
+11. Verifiera att båda avvisas.
+12. Kontrollera att poängbadgen följer projektets designreferens och fungerar
+    med ett- och tvåsiffriga värden.
+13. Starta om backend.
+14. Verifiera att den lokala utvecklingsdatan inte finns kvar.
+
+## Acceptanskriterier
+
+Feature 3 är klar när:
+
+- varje ny uppgift har ett obligatoriskt `points`;
+- `points` är ett heltal mellan 1 och 99;
+- frontendens standardvärde är `1`;
+- frontend alltid skickar `points` uttryckligen;
+- backend avvisar saknat eller ogiltigt `points`;
+- backend fyller inte automatiskt i ett saknat värde;
+- uppgiftens poäng returneras av API:t;
+- uppgiftens poäng visas dynamiskt på uppgiftskortet;
+- frontend- och backendtester täcker centrala giltiga och ogiltiga fall;
+- lokal H2 körs som in-memory och återställs vid omstart;
+- relevant dokumentation är uppdaterad;
+- Feature 3 inte inför funktionalitet som hör till senare features.
+
+## Implementationsprinciper
+
+När Feature 3 senare implementeras ska Codex först läsa:
+
+```text
+AGENTS.md
+README.md
+docs/architecture.md
+docs/development.md
+docs/roadmap.md
+docs/decisions/
+docs/features/
+```
+
+Codex ska även läsa relevant backendkod, frontendkod och befintliga tester innan
+ändringar görs.
+
+Repositoryts faktiska kod och dokumentation har företräde framför antaganden i
+denna featurebeskrivning.
+
+Dokumentation, implementation och tester ska uppdateras tillsammans.
+
+Codex ska inte committa, pusha, skapa pull request eller merga utan uttrycklig
+instruktion.

docs/roadmap.md

@@ -0,0 +1,436 @@
+# 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, 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 uppgiftstilldelningar, statusändringar, drag-and-drop,
+redigeringar, raderingar, deadlines eller återkommande uppgifter.
+Nuvarande användarval är inte autentisering.
+
+**Feature 3 – Uppgiftspoäng är pågående.**
+
+## 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 | 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 |
+| 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:** Pågående
+
+**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:** 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
+
+- 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.

frontend/src/App.test.tsx

@@ -21,6 +21,7 @@ const tasks = [
     title: 'Dammsuga',
     description: 'Bottenvåningen',
     status: 'WAITING',
+    points: 7,
     createdAt: '2026-07-24T10:00:00Z',
   },
   {
@@ -28,6 +29,7 @@ const tasks = [
     title: 'Diska',
     description: null,
     status: 'IN_PROGRESS',
+    points: 3,
     createdAt: '2026-07-24T10:01:00Z',
   },
   {
@@ -35,6 +37,7 @@ const tasks = [
     title: 'Vattna blommor',
     description: null,
     status: 'COMPLETED',
+    points: 5,
     createdAt: '2026-07-24T10:02:00Z',
   },
 ]
@@ -167,12 +170,14 @@ test('brädan visar tre kolumner och grupperar hämtade uppgifter', async () =>
 
   render(<App />)
 
-  const waiting = await screen.findByRole('region', { name: 'Väntande' })
+  await screen.findByText('Dammsuga')
+  const waiting = screen.getByRole('region', { name: 'Väntande' })
   const inProgress = screen.getByRole('region', { name: 'Pågående' })
   const completed = screen.getByRole('region', { name: 'Klart' })
 
   expect(within(waiting).getByText('Dammsuga')).toBeInTheDocument()
   expect(within(waiting).getByText('Bottenvåningen')).toBeInTheDocument()
+  expect(within(waiting).getByText('7 p')).toBeInTheDocument()
   expect(within(inProgress).getByText('Diska')).toBeInTheDocument()
   expect(within(completed).getByText('Vattna blommor')).toBeInTheDocument()
   expect(screen.queryByText(/Inga uppgifter/i)).not.toBeInTheDocument()
@@ -187,6 +192,7 @@ test('Ny uppgift öppnar modalen med fokus i titelfältet', async () => {
 
   expect(screen.getByRole('dialog', { name: 'Skapa ny uppgift' })).toBeInTheDocument()
   expect(screen.getByLabelText('Titel')).toHaveFocus()
+  expect(screen.getByLabelText('Poäng')).toHaveValue(1)
 })
 
 test.each([
@@ -220,6 +226,7 @@ test.each([
   fireEvent.change(screen.getByLabelText('Beskrivning (valfri)'), {
     target: { value: 'Bottenvåningen' },
   })
+  fireEvent.change(screen.getByLabelText('Poäng'), { target: { value: '7' } })
 
   close()
 
@@ -229,6 +236,7 @@ test.each([
 
   expect(screen.getByLabelText('Titel')).toHaveValue('')
   expect(screen.getByLabelText('Beskrivning (valfri)')).toHaveValue('')
+  expect(screen.getByLabelText('Poäng')).toHaveValue(1)
 })
 
 test('en skapad uppgift visas längst ned i Väntande och modalen stängs', async () => {
@@ -237,6 +245,7 @@ test('en skapad uppgift visas längst ned i Väntande och modalen stängs', asyn
     title: 'Putsa fönster',
     description: 'Köket',
     status: 'WAITING',
+    points: 7,
     createdAt: '2026-07-24T10:03:00Z',
   }
   window.localStorage.setItem('hemhub.activeUserId', users[0].id)
@@ -253,6 +262,7 @@ test('en skapad uppgift visas längst ned i Väntande och modalen stängs', asyn
   fireEvent.change(screen.getByLabelText('Beskrivning (valfri)'), {
     target: { value: '  Köket  ' },
   })
+  fireEvent.change(screen.getByLabelText('Poäng'), { target: { value: '7' } })
   fireEvent.click(screen.getByRole('button', { name: 'Skapa uppgift' }))
 
   await waitFor(() =>
@@ -260,14 +270,39 @@ test('en skapad uppgift visas längst ned i Väntande och modalen stängs', asyn
   )
   const waiting = screen.getByRole('region', { name: 'Väntande' })
   expect(within(waiting).getAllByRole('article').map((card) => card.textContent)).toEqual([
-    'DammsugaBottenvåningen',
-    'Putsa fönsterKöket',
+    'Dammsuga7 pBottenvåningen',
+    'Putsa fönster7 pKöket',
   ])
   expect(fetchMock).toHaveBeenLastCalledWith('/api/tasks', {
     method: 'POST',
     headers: { 'Content-Type': 'application/json' },
-    body: JSON.stringify({ title: 'Putsa fönster', description: 'Köket' }),
+    body: JSON.stringify({ title: 'Putsa fönster', description: 'Köket', points: 7 }),
   })
+
+  fireEvent.click(screen.getByRole('button', { name: 'Ny uppgift' }))
+  expect(screen.getByLabelText('Poäng')).toHaveValue(1)
+})
+
+test.each([
+  { värde: '', beskrivning: 'tomt' },
+  { värde: '0', beskrivning: 'under 1' },
+  { värde: '100', beskrivning: 'över 99' },
+  { värde: '1.5', beskrivning: 'decimaltal' },
+])('ogiltigt poängvärde ($beskrivning) blockerar submit', async ({ värde }) => {
+  window.localStorage.setItem('hemhub.activeUserId', users[0].id)
+  const fetchMock = mockUsersAndTasks(users, [])
+  render(<App />)
+
+  await waitFor(() => expect(fetchMock).toHaveBeenCalledTimes(2))
+  fireEvent.click(screen.getByRole('button', { name: 'Ny uppgift' }))
+  fireEvent.change(screen.getByLabelText('Titel'), { target: { value: 'Dammsuga' } })
+  fireEvent.change(screen.getByLabelText('Poäng'), { target: { value: värde } })
+  fireEvent.click(screen.getByRole('button', { name: 'Skapa uppgift' }))
+
+  expect(await screen.findByRole('alert')).toHaveTextContent(
+    'Poäng måste vara ett heltal mellan 1 och 99.',
+  )
+  expect(fetchMock).toHaveBeenCalledTimes(2)
 })
 
 test('formulärdata bevaras när skapande av uppgift misslyckas', async () => {
@@ -285,14 +320,17 @@ test('formulärdata bevaras när skapande av uppgift misslyckas', async () => {
   fireEvent.click(screen.getByRole('button', { name: 'Ny uppgift' }))
   const title = screen.getByLabelText('Titel')
   const description = screen.getByLabelText('Beskrivning (valfri)')
+  const points = screen.getByLabelText('Poäng')
   fireEvent.change(title, { target: { value: 'Dammsuga' } })
   fireEvent.change(description, { target: { value: 'Bottenvåningen' } })
+  fireEvent.change(points, { target: { value: '7' } })
   fireEvent.click(screen.getByRole('button', { name: 'Skapa uppgift' }))
 
   expect(await screen.findByRole('alert')).toHaveTextContent('Uppgiften är ogiltig.')
   expect(screen.getByRole('dialog', { name: 'Skapa ny uppgift' })).toBeInTheDocument()
   expect(title).toHaveValue('Dammsuga')
   expect(description).toHaveValue('Bottenvåningen')
+  expect(points).toHaveValue(7)
 })
 
 function mockUsersAndTasks(userResponse: unknown, taskResponse: unknown) {

frontend/src/TaskBoard.tsx

@@ -7,6 +7,7 @@ type Task = {
   title: string
   description: string | null
   status: TaskStatus
+  points: number
   createdAt: string
 }
 
@@ -92,7 +93,10 @@ function TaskBoard({ activeUserName, onLogOut }: TaskBoardProps) {
                 .filter((task) => task.status === column.status)
                 .map((task) => (
                   <article className="task-card" key={task.id}>
+                    <div className="task-card-header">
                       <h3>{task.title}</h3>
+                      <span className="points-badge">{task.points} p</span>
+                    </div>
                     {task.description && <p>{task.description}</p>}
                   </article>
                 ))}
@@ -122,6 +126,7 @@ type CreateTaskModalProps = {
 function CreateTaskModal({ onClose, onCreated }: CreateTaskModalProps) {
   const [title, setTitle] = useState('')
   const [description, setDescription] = useState('')
+  const [points, setPoints] = useState('1')
   const [error, setError] = useState('')
   const [isSubmitting, setIsSubmitting] = useState(false)
   const isSubmittingRef = useRef(false)
@@ -152,6 +157,7 @@ function CreateTaskModal({ onClose, onCreated }: CreateTaskModalProps) {
 
     const trimmedTitle = title.trim()
     const trimmedDescription = description.trim()
+    const numericPoints = Number(points)
 
     if (!trimmedTitle || [...trimmedTitle].length > 100) {
       setError('Titeln måste innehålla mellan 1 och 100 tecken.')
@@ -163,6 +169,16 @@ function CreateTaskModal({ onClose, onCreated }: CreateTaskModalProps) {
       return
     }
 
+    if (
+      !points.trim() ||
+      !Number.isInteger(numericPoints) ||
+      numericPoints < 1 ||
+      numericPoints > 99
+    ) {
+      setError('Poäng måste vara ett heltal mellan 1 och 99.')
+      return
+    }
+
     setError('')
     isSubmittingRef.current = true
     setIsSubmitting(true)
@@ -174,6 +190,7 @@ function CreateTaskModal({ onClose, onCreated }: CreateTaskModalProps) {
         body: JSON.stringify({
           title: trimmedTitle,
           description: trimmedDescription || null,
+          points: numericPoints,
         }),
       })
 
@@ -212,7 +229,7 @@ function CreateTaskModal({ onClose, onCreated }: CreateTaskModalProps) {
             ×
           </button>
         </div>
-        <form onSubmit={(event) => void submit(event)}>
+        <form noValidate onSubmit={(event) => void submit(event)}>
           <label htmlFor="task-title">Titel</label>
           <input
             id="task-title"
@@ -231,6 +248,22 @@ function CreateTaskModal({ onClose, onCreated }: CreateTaskModalProps) {
             onChange={(event) => setDescription(event.target.value)}
           />
 
+          <label htmlFor="task-points">Poäng</label>
+          <input
+            id="task-points"
+            type="number"
+            min="1"
+            max="99"
+            step="1"
+            value={points}
+            disabled={isSubmitting}
+            aria-describedby="task-points-help"
+            onChange={(event) => setPoints(event.target.value)}
+          />
+          <p id="task-points-help" className="field-help">
+            1–99 poäng beroende på hur tidskrävande, besvärlig eller viktig uppgiften är.
+          </p>
+
           {error && (
             <p className="error" role="alert">
               {error}

frontend/src/styles.css

@@ -174,12 +174,36 @@ textarea {
   margin: 0;
 }
 
+.task-card-header {
+  display: flex;
+  align-items: flex-start;
+  justify-content: space-between;
+  gap: 0.75rem;
+}
+
+.points-badge {
+  flex: 0 0 auto;
+  padding: 0.2rem 0.5rem;
+  border-radius: 999px;
+  color: #1e3a8a;
+  background: #dbeafe;
+  font-size: 0.8rem;
+  font-weight: 700;
+  line-height: 1.25;
+}
+
 .task-card p {
   margin-top: 0.5rem;
   color: #475569;
   white-space: pre-wrap;
 }
 
+.field-help {
+  margin: -0.25rem 0 0;
+  color: #64748b;
+  font-size: 0.85rem;
+}
+
 .modal-backdrop {
   position: fixed;
   inset: 0;