docs: establish project documentation baseline

docs/features/000-project-foundation.md

@@ -0,0 +1,76 @@
+# Feature 0 – Projektgrund
+
+## Status
+
+Färdig och mergad till `main`.
+
+## Bakgrund
+
+HemHub behövde en minimal projektgrund för inkrementell utveckling av en
+webbapplikation med separat frontend och backend.
+
+## Mål
+
+Skapa körbara React- och Spring Boot-applikationer, koppla ihop dem lokalt och
+etablera grundläggande tester och dokumentation.
+
+## Omfattning
+
+- monorepo med `backend/` och `frontend/`;
+- Java 21, Spring Boot och Maven Wrapper;
+- React, TypeScript, Vite och pnpm;
+- health-endpoint och en tillfällig frontendstatus;
+- Vite-proxy och grundtester;
+- `README.md`, `AGENTS.md` och `.gitignore`.
+
+## Avgränsningar
+
+Feature 0 införde ingen databas, domänmodell, autentisering, deployment,
+containerkonfiguration eller produktionskonfiguration.
+
+## Beslut
+
+Frontend och backend skapades som separata applikationer i samma repository.
+Frontend använder relativa `/api`-adresser, och Vite proxar dem lokalt till
+backend på port 8080. Ingen generell CORS-konfiguration infördes.
+
+## Implementerad lösning
+
+Backend skapades med Spring Boot 4.1.0, Java 21, Spring Web och Maven Wrapper.
+Frontend skapades med React 19, TypeScript, Vite och pnpm.
+
+Den ursprungliga startsidan anropade health-endpointen och visade backendstatus
+eller ett anslutningsfel. Senare features har ersatt denna startsida, men
+health-endpointen och dess test finns kvar.
+
+## API-förändringar
+
+`GET /api/health` infördes och returnerar:
+
+```json
+{"status":"UP"}
+```
+
+## Databasförändringar
+
+Inga.
+
+## Frontendförändringar
+
+En minimal startsida visade rubriken HemHub, att frontend hade startat och
+resultatet från `/api/health`. Vite konfigurerades att proxya `/api` till
+`http://localhost:8080`.
+
+## Tester och verifiering
+
+Ett MockMvc-test verifierar status 200 och `status: UP`. Det ursprungliga
+frontendtestet verifierade rubriken HemHub med mockat API-anrop.
+
+## Kända begränsningar
+
+Projektgrunden innehöll ingen användar- eller uppgiftsfunktionalitet. Den
+ursprungliga health-vyn är inte längre appens aktiva vy.
+
+## Relaterade commits
+
+- `9957383e88b08dc006d2eaeb2a513c7769bd5705` – `Initialize HemHub project foundation`

docs/features/001-user-selection.md

@@ -0,0 +1,99 @@
+# Feature 1 – Användarval
+
+## Status
+
+Färdig och mergad till `main`.
+
+## Bakgrund
+
+HemHub behövde centralt lagrade användare och ett enkelt sätt att välja vem som
+använder applikationen, utan att införa autentisering.
+
+## Mål
+
+Göra det möjligt att lista och skapa användare, välja en aktiv användare,
+återanvända valet i samma browser och lämna den aktiva vyn.
+
+## Omfattning
+
+- persistens, API och validering för användare;
+- startflöden för tom och befintlig användarlista;
+- lokalt lagrad aktiv användare;
+- användarval, skapande och felhantering;
+- automatiserade backend- och frontendtester.
+
+## Avgränsningar
+
+Ingen autentisering, lösenord, roll, behörighet, e-post, avatar,
+hushållsrelation, redigering eller radering infördes.
+
+## Beslut
+
+Backend är slutlig auktoritet för namnvalidering. Namn normaliseras separat för
+skiftlägesokänslig unikhet. Frontend lagrar endast UUID under
+`hemhub.activeUserId` och verifierar det mot den hämtade användarlistan.
+
+## Implementerad lösning
+
+Vid appstart hämtar frontend alltid användarna. En tom lista leder direkt till
+formuläret Skapa användare. Om användare finns men inget giltigt lokalt val
+finns visas Vem är du?.
+
+Val eller lyckat skapande sparar användarens id och aktiverar användaren. Ett
+ogiltigt lagrat id rensas utan tekniskt fel. Feature 1:s tillfälliga startsida
+och kontrollen Byt användare ersattes i Feature 2 av uppgiftsbrädan och
+kontrollen Logga ut; lagringsmekanismen är oförändrad.
+
+## API-förändringar
+
+- `GET /api/users` returnerar alla användare.
+- `POST /api/users` skapar en användare och returnerar `201 Created`.
+
+API-responsen innehåller `id`, `name` och `createdAt`. `normalizedName` exponeras
+inte.
+
+Tomt namn eller namn längre än 50 Unicode-kodpunkter ger `400` med
+`INVALID_USER_NAME`. Ett dubblettnamn utan hänsyn till stora och små bokstäver
+ger `409` med `USER_NAME_ALREADY_EXISTS`.
+
+## Databasförändringar
+
+Flyway-migreringen `V1__create_users.sql` skapade tabellen `app_user`:
+
+- UUID som primärnyckel;
+- `name VARCHAR(50)`;
+- unikt `normalized_name VARCHAR(150)`;
+- `created_at TIMESTAMP WITH TIME ZONE`.
+
+Lokalt används filbaserad H2 och i tester H2 in-memory. Backend genererar UUID
+och `createdAt` med en UTC-klocka.
+
+## Frontendförändringar
+
+Frontend fick laddnings-, fel-, användarvals- och användarskapandevyer.
+Skapandeformuläret trimmar namnet, gör en enkel längdkontroll, blockerar
+dubbelsubmit och behåller inmatningen vid fel.
+
+Nuvarande utloggning tar bort `hemhub.activeUserId`, rensar aktiv användare och
+visar Vem är du? även om endast en användare finns.
+
+## Tester och verifiering
+
+Backendens integrationstester verifierar tom lista, skapande och listning,
+trimning, ogiltiga namn, skiftlägesokänsliga dubbletter och alfabetisk
+sortering.
+
+Frontendtesterna verifierar tom lista, användarval, automatisk aktivering efter
+skapande, bevarad inmatning vid fel, hämtfel med återförsök, ogiltigt lagrat id
+och utloggning. API-anropen mockas.
+
+## Kända begränsningar
+
+Aktiv användare är ett lokalt gränssnittsval, inte säker autentisering. Valet
+synkroniseras inte mellan browsers eller enheter. Användare kan inte redigeras
+eller raderas.
+
+## Relaterade commits
+
+- `1ec7a729085d456d3185a1c74d02f99f40de0e8d` – `feat: add user selection flow`
+- `050f248857a01db2dc236a0ca35982fd70dab3d6` – merge till `main`

docs/features/002-task-creation.md

@@ -0,0 +1,108 @@
+# 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`