feat: add task assignment

docs/features/004-task-assignment.md

@@ -0,0 +1,122 @@
+# Feature 4 – Tilldelning av uppgifter
+
+## Status
+
+Pågående.
+
+## Bakgrund
+
+HemHub har centralt lagrade användare och gemensamma uppgifter. För att senare
+kunna införa regler för pågående arbete behöver en uppgift kunna ha en ansvarig
+användare, utan att tilldelning samtidigt ändrar uppgiftens status.
+
+## Mål
+
+- välja en valfri ansvarig när en uppgift skapas;
+- visa ansvarig på uppgiftskortet;
+- tilldela, byta eller ta bort ansvarig på en väntande uppgift;
+- lagra tilldelningen centralt så att alla användare ser samma värde.
+
+## Omfattning
+
+En uppgift kan vara otilldelad eller tilldelad exakt en befintlig användare.
+`Ingen` är standard vid skapande och den aktiva browseranvändaren förväljs
+inte. Frontend återanvänder användarlistan som redan hämtas vid appstart.
+
+På ett otilldelat väntande kort öppnar `Ta uppgift` ett användarval. Ett
+tilldelat väntande kort visar namnet och öppnar samma val. Ändringen skickas
+direkt till backend och kortet uppdateras först med den bekräftade responsen.
+Vid fel behålls den tidigare tilldelningen och ett lokalt felmeddelande visas.
+
+För `IN_PROGRESS` och `COMPLETED` visas ansvarig eller `Otilldelad` utan
+redigerbar kontroll.
+
+## Produktregler
+
+- En uppgift har högst en ansvarig.
+- Ansvarig är valfri och måste motsvara en befintlig användare.
+- Endast uppgifter med status `WAITING` får få ändrad ansvarig.
+- Tilldelning ändrar aldrig status, titel, beskrivning eller poäng.
+- Vem som helst kan välja valfri ansvarig; aktiv användare är inte
+  autentisering eller behörighetskontroll.
+
+## API-förändringar
+
+`POST /api/tasks` accepterar det valfria fältet `assigneeId`. Saknat fält eller
+`null` skapar en otilldelad uppgift. Ett UUID som inte motsvarar en användare
+ger `404 Not Found`.
+
+`PUT /api/tasks/{taskId}/assignee` ändrar endast ansvarig:
+
+```json
+{"assigneeId": "d56b54dd-31b0-4d71-8a10-82464be59a61"}
+```
+
+`{"assigneeId": null}` tar bort tilldelningen. Fältet måste finnas i requesten.
+Responsen är den uppdaterade uppgiften. Task-responser innehåller:
+
+```json
+{"assignee": {"id": "d56b54dd-31b0-4d71-8a10-82464be59a61", "name": "Anna"}}
+```
+
+Otilldelade uppgifter har `"assignee": null`. Ogiltigt UUID eller saknat fält
+ger `400`, okänd uppgift eller användare ger `404` och ändring av en uppgift
+som inte väntar ger `409`. Felen använder det befintliga formatet med `code`
+och `message`.
+
+## Databasförändringar
+
+`V4__add_task_assignee.sql` lägger till `task.assignee_id UUID NULL` med en
+främmande nyckel till `app_user.id`. Befintliga uppgifter blir otilldelade.
+Migreringen använder varken `ON DELETE CASCADE` eller `ON DELETE SET NULL`.
+
+JPA-modellen använder en lazy `ManyToOne`. Repositoryts listning och
+id-hämtning använder en entity graph för att hämta ansvarig tillsammans med
+uppgiften och undvika N+1-frågor när responsen byggs.
+
+## Frontendförändringar
+
+Skapandedialogen innehåller ett tilldelningsval med `Ingen` och samtliga
+användare. Valet bevaras tillsammans med övriga formulärvärden vid fel.
+
+Väntande kort har en separat tilldelningskontroll. Kontrollen är inaktiverad
+medan just det kortets request pågår; övriga delar av brädan förblir
+interaktiva. Serverns task-respons ersätter motsvarande uppgift i den befintliga
+listan utan att ändra ordningen.
+
+## Tester och verifiering
+
+Backendens integrationstester täcker skapande med och utan ansvarig,
+responsformat, okända id:n, tilldelning, byte, av-tilldelning, statuskonflikt
+och att övriga uppgiftsfält inte ändras.
+
+Frontendtesterna täcker standardval och användarlista i skapandedialogen,
+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,
+byte, av-tilldelning, bevarad status, omladdning, statiska kontroller för andra
+statusar, felrespons och projektets normala desktop- och mobilbredder.
+
+## Avgränsning mot Feature 5
+
+Feature 4 inför inget API eller UI för statusändring och inte regeln att
+`IN_PROGRESS` måste ha en ansvarig. Tilldelning leder inte automatiskt till
+`IN_PROGRESS`, och av-tilldelning leder inte automatiskt till `WAITING`.
+
+## Ingår inte
+
+Flera ansvariga, statusändring, drag-and-drop, generell redigering, radering,
+deadlines, återkommande uppgifter, poänghistorik, användaradministration,
+autentisering, behörighetskontroll och automatisk tilldelning ingår inte.
+
+## Kända begränsningar
+
+Användare kan ännu inte raderas, så relationens framtida beteende vid
+användarradering är inte beslutat. Frontend har ingen optimistisk uppdatering;
+det tidigare värdet ligger kvar tills backend svarar.
+
+## Relaterade commits
+
+Fylls i när featuren har committats.