# Feature 2 – Skapa uppgifter

## Status

Färdig och mergad till `main`.

## Bakgrund

Efter införandet av aktiv användare behövde HemHub en första gemensam
uppgiftsmodell och en enkel bräda för att skapa och visa uppgifter.

## Mål

Låta en aktiv användare se tre statuskolumner, skapa en uppgift med titel och
valfri beskrivning samt se den sparade uppgiften efter omladdning.

## Omfattning

- persistent uppgiftsmodell och Flyway-migrering;
- API för att skapa och lista uppgifter;
- bräda med Väntande, Pågående och Klart;
- modal för att skapa uppgifter;
- laddnings-, validerings- och felhantering;
- automatiserade backend- och frontendtester.

## Avgränsningar

Ingen ändring av status, drag-and-drop, tilldelning, användarrelation, poäng,
deadline, återkommande uppgift, redigering, radering, sökning, filtrering eller
paginering infördes.

## Beslut

Alla användare ser samma uppgifter; uppgiftsmodellen har ingen relation till en
användare. Backend väljer alltid status `WAITING` vid skapande. Listningen
sorteras i backend efter `createdAt ASC, id ASC`, och frontend bevarar den
ordningen.

## Implementerad lösning

JPA-entiteten `Task` innehåller UUID, titel, valfri beskrivning, status och
skapandetid. Backend genererar UUID och `createdAt` med en UTC-klocka.

Frontend visar uppgiftsbrädan när ett giltigt aktivt användarval finns. Uppgifter
hämtas vid montering, grupperas efter status och visas med endast titel och
eventuell beskrivning. Tomma kolumner saknar tomlägestext.

## API-förändringar

- `GET /api/tasks` returnerar samtliga uppgifter, äldst först och med UUID som
  sekundär sorteringsnyckel.
- `POST /api/tasks` skapar en uppgift och returnerar `201 Created`.

Titel trimmas, är obligatorisk och får omfatta högst 100 Unicode-kodpunkter.
Beskrivning trimmas, får omfatta högst 500 Unicode-kodpunkter och lagras som
`null` om den är tom. Ogiltiga anrop ger `400` med felkoden `INVALID_TASK`.

## Databasförändringar

Flyway-migreringen `V2__create_tasks.sql` skapade tabellen `task`:

- `id UUID PRIMARY KEY`;
- `title VARCHAR(100) NOT NULL`;
- `description VARCHAR(500)`;
- `status VARCHAR(20) NOT NULL`;
- `created_at TIMESTAMP WITH TIME ZONE NOT NULL`.

Status lagras som text genom `@Enumerated(EnumType.STRING)`. Databasen har ingen
check constraint för enumvärden.

## Frontendförändringar

Feature 1:s tillfälliga aktiva vy ersattes med uppgiftsbrädan. Sidhuvudet visar
aktiv användares namn, Logga ut och Ny uppgift.

Skapandemodalen innehåller titel och valfri beskrivning. Titelfältet får fokus
när modalen öppnas. När inget submit-anrop pågår kan den stängas med kryss,
Escape eller klick på bakgrunden. Normal stängning avmonterar komponenten och
nollställer därmed formuläret.

Vid submit gör frontend samma grundläggande längdkontroller, skickar trimmade
värden och blockerar uppenbara dubbelsubmit. Vid fel stannar modalen öppen med
bevarad inmatning. Vid framgång läggs API-svaret sist i den befintliga listan,
vilket placerar den nya `WAITING`-uppgiften längst ned i Väntande utan att
sortera om backendens ordning.

## Tester och verifiering

Backendens integrationstester verifierar skapande, `WAITING`, trimning, tom
beskrivning som `null`, längdvalidering samt sorteringen `createdAt ASC, id ASC`.

Frontendtesterna verifierar bräda och statusgruppering, tomma kolumner,
modalöppning och fokus, skapande, ordning efter skapande, bevarad formulärdata
vid API-fel samt utloggning. Parametriserade testfall verifierar också stängning
med kryss, Escape och bakgrundsklick samt att formuläret är rensat när modalen
öppnas igen.

## Kända begränsningar

Statusvärden utöver `WAITING` kan visas om de redan finns i databasen, men inget
nuvarande API eller gränssnitt kan flytta en uppgift mellan kolumnerna. Det
finns ingen koppling mellan uppgifter och skapande eller aktiv användare.
Modalen har ingen fokusfälla eller explicit fokusåterställning.

## Relaterade commits

- `3f152eecccdd88f840066543bf9321b81b4cead8` – `feat: add task creation board`
- `2f7b99fb21c57c2e9c5f019a2b5073458e41c939` – merge till `main`