feat: add task drag and drop

Reviewed-on: #9

README.md

@@ -11,6 +11,8 @@ 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, lista, tilldela och ändra status på gemensamma hushållsuppgifter.
+Uppgiftskort kan flyttas mellan brädans statuskolumner med drag-and-drop eller
+med de befintliga statusknapparna.
 
 ## Starta backend
 

docs/architecture.md

@@ -23,14 +23,15 @@ byggprocess.
 
 ### Frontend
 
-Frontend finns i `frontend/` och använder React 19, TypeScript, Vite och pnpm.
+Frontend finns i `frontend/` och använder React 19, TypeScript, Vite, pnpm och
-Den ansvarar för:
+dnd-kit-ekosystemets aktuella React-adapter. Den ansvarar för:
 
 - hämtning och presentation av användare och uppgifter;
 - lokalt val av aktiv användare;
 - formulär för att skapa användare och uppgifter;
 - val och visning av ansvarig användare på uppgifter;
 - serverbekräftade statusändringar genom knappar på uppgiftskorten;
+- optimistiska statusflyttar genom drag-and-drop mellan brädans kolumner;
 - klientnära validering och begripliga felmeddelanden;
 - uppgiftsbrädan med kolumnerna Väntande, Pågående och Klart.
 
@@ -148,7 +149,12 @@ otillåtna tilldelningsändringar till `409 Conflict`.
 Frontend skiljer mellan fel vid hämtning och skapande. Hämtfel kan
 återförsökas. Formulärfel visas nära formuläret och inmatningen behålls vid
 misslyckade API-anrop. Status- och tilldelningsfel visas lokalt på berört kort;
-kortet uppdateras först med backendens bekräftade respons.
+statusknappar och tilldelning uppdateras först med backendens bekräftade
+respons. Drag-and-drop flyttar kortet optimistiskt men återställer hela den
+tidigare uppgiften vid fel. Vid framgång ersätts alltid det lokala värdet med
+backendens fullständiga respons. Status- och tilldelningsanrop delar låsning per
+task-id, så det berörda kortet blockeras utan att resten av brädan låses.
+Drag-and-drop återanvänder backendens befintliga status-API oförändrat.
 
 ### Teststrategi
 
@@ -160,7 +166,9 @@ Backend har JUnit 5-tester:
 
 Frontend använder Vitest, jsdom och React Testing Library. `fetch` och
 `localStorage` ersätts i testerna, så frontendtesterna kräver inte en körande
-backend. Produktionsbygget kör TypeScript-kompilering följt av Vite.
+backend. Drag-and-drop-adaptern översätter bibliotekshändelser till task-id och
+status, så stateflöden kan testas utan att simulera fysisk layout i jsdom.
+Produktionsbygget kör TypeScript-kompilering följt av Vite.
 
 ### Produktionsdeployment
 

docs/features/005-task-status.md

@@ -2,7 +2,7 @@
 
 ## Status
 
-Färdig och verifierad på feature-branchen; ännu inte mergad till `main`.
+Färdig och mergad till `main`.
 
 ## Bakgrund
 
@@ -114,10 +114,11 @@ införs.
 
 Aktiv användare är ett lokalt browserval och inte autentisering. Backend kan
 verifiera att id:t finns, men inte vem som faktiskt använder browsern.
+
 Statusknapparna är ett första gränssnitt före Feature 6. Det finns ingen
 versionskontroll för konkurrerande uppdateringar utöver transaktioner och
 aktuell serverlogik.
 
 ## Relaterade commits
 
-Fylls i efter implementation och merge.
+- `65a6488c0b268f49b1361591f025bdea8d67f754` – `feat: add task status transitions`

docs/features/006-task-drag-and-drop.md

@@ -0,0 +1,545 @@
+# Feature 6 – Drag-and-drop
+
+## Status
+
+Färdig och verifierad på feature-branchen, ännu inte mergad till `main`.
+
+## Bakgrund
+
+Feature 5 införde backendstyrda statusövergångar mellan `WAITING`,
+`IN_PROGRESS` och `COMPLETED`, ett särskilt status-API samt ett första
+knappbaserat gränssnitt för statusändring.
+
+Feature 6 ska komplettera detta med drag-and-drop mellan brädans
+statuskolumner. Featuren ska återanvända den befintliga statusmodellen,
+status-API:t, tilldelningsreglerna och frontendens hantering av vänteläge och
+lokala fel. Den ska inte skapa en parallell statusmekanism.
+
+## Mål
+
+Feature 6 ska:
+
+- låta användaren dra uppgiftskort mellan statuskolumner;
+- använda status-API:t från Feature 5;
+- ge omedelbar visuell återkoppling genom optimistisk flytt;
+- återställa kortet om backend avvisar statusändringen;
+- hantera automatisk tilldelning när en otilldelad uppgift dras till Pågående;
+- behålla befintliga statusknappar som ett tillfälligt alternativ;
+- fungera med mus och på en rimlig nivå med touch;
+- hålla dragmekanik, statuslogik och kortlayout tillräckligt separerade för
+  framtida ändringar.
+
+## Omfattning
+
+Feature 6 är primärt en frontendfeature.
+
+Backendens befintliga endpoint används:
+
+```http
+PUT /api/tasks/{taskId}/status
+```
+
+Requesten innehåller målstatus och kan innehålla aktiv användares id:
+
+```json
+{
+  "status": "IN_PROGRESS",
+  "activeUserId": "d56b54dd-31b0-4d71-8a10-82464be59a61"
+}
+```
+
+Backend ska endast ändras om granskning av den faktiska implementationen visar
+att en mindre korrigering behövs för att det befintliga kontraktet ska kunna
+återanvändas korrekt.
+
+## Implementerad lösning
+
+Frontend använder `@dnd-kit/react` 0.5.0 som aktuell React-adapter och
+`@dnd-kit/dom` 0.5.0 för en konfigurerad pointer-sensor. Legacy-paketen
+`@dnd-kit/core` och `@dnd-kit/sortable` används inte. Sortable-stöd behövs inte
+eftersom kort inte ordnas inom kolumner.
+
+`TaskDragAndDrop.tsx` avgränsar bibliotekskopplingen. Adaptern:
+
+- registrerar uppgiftskort som draggable och statuskolumner som droppable;
+- översätter ett lyckat drop-event till task-id och målstatus;
+- ignorerar avbrutna dragningar och ogiltiga mål;
+- använder sex pixlars aktiveringsavstånd för mus och penna;
+- använder 250 millisekunders fördröjning med åtta pixlars tolerans för touch;
+- behåller dnd-kits standardplugins och tangentbordssensor;
+- förlitar sig på sensorns standardskydd mot dragstart från interaktiva
+  element.
+
+Ingen särskild `touch-action`, collision detector eller drag-overlay har lagts
+till. Den befintliga responsiva layouten är oförändrad.
+
+`TaskBoard` har fortsatt en gemensam requestväg och låsning per task-id för
+statusändringar. Ett presentationsval avgör beteendet:
+
+- statusknappar använder `server-confirmed` och flyttar inte kortet före svar;
+- drag-and-drop använder `optimistic`, sparar hela tidigare uppgiften och
+  flyttar kortet direkt;
+- lyckade anrop ersätter uppgiften med hela serverresponsen;
+- misslyckade optimistiska anrop återställer hela rollback-värdet och visar
+  felet lokalt.
+
+När en otilldelad uppgift dras till `IN_PROGRESS` visar det optimistiska värdet
+den aktiva användarens id och namn. En befintlig ansvarig behålls. Backendens
+befintliga status-API och Feature 5-regler återanvänds utan backendändringar.
+
+Frontendens 44 tester, TypeScript-kompilering, Vites produktionsbygge och
+`git diff --check` passerar på feature-branchen. Manuell browserverifiering av
+de centrala drag-, server- och rollbackflödena är genomförd.
+
+## Avgränsningar
+
+Feature 6 ska inte införa:
+
+- en ny statusmodell;
+- ett nytt eller parallellt status-API;
+- manuell sortering inom en kolumn;
+- persistent kortordning;
+- generell redigering av uppgifter;
+- radering;
+- deadlines;
+- återkommande uppgifter;
+- status- eller poänghistorik;
+- undo-funktion;
+- flera ansvariga;
+- autentisering eller behörigheter;
+- realtidsuppdatering mellan browsers;
+- en ny global state-lösning;
+- horisontell scrollning som ett särskilt mobilkoncept;
+- ett specialbyggt tangentbordsflöde för drag-and-drop.
+
+Att flytta ett kort inom samma kolumn ska inte ändra någon ordning och ska inte
+ge ett backend-anrop.
+
+## Befintliga statusregler
+
+Feature 6 ska behandla följande regler som redan beslutade:
+
+- statusarna är `WAITING`, `IN_PROGRESS` och `COMPLETED`;
+- alla direkta statusövergångar är tillåtna;
+- samma målstatus är giltig och idempotent;
+- `IN_PROGRESS` kräver ansvarig;
+- `WAITING` och `COMPLETED` får vara otilldelade;
+- när en otilldelad uppgift sätts till `IN_PROGRESS` skickar frontend aktiv
+  användares id;
+- backend tilldelar då användaren och ändrar status atomärt;
+- om uppgiften redan har en ansvarig behålls denna;
+- statusoperationen byter aldrig en befintlig ansvarig;
+- backend returnerar hela den uppdaterade uppgiften;
+- serverns fullständiga task-respons är slutlig sanning.
+
+## Uppdateringsstrategi
+
+Drag-and-drop använder en kontrollerad optimistisk uppdatering.
+
+När ett kort släpps i en annan statuskolumn ska frontend:
+
+1. spara hela den nuvarande task-versionen som rollback-värde;
+2. skapa ett optimistiskt lokalt task-läge;
+3. visa kortet omedelbart i målkolumnen;
+4. markera kortet som upptaget;
+5. skicka statusanropet;
+6. vid framgång ersätta den optimistiska uppgiften med serverns fullständiga
+   respons;
+7. vid fel återställa hela den tidigare task-versionen;
+8. visa felet lokalt på det återställda kortet.
+
+Rollback ska återställa hela uppgiften, inte enbart statusfältet. Detta är
+viktigt eftersom en optimistisk flytt till `IN_PROGRESS` även kan innehålla en
+tillfällig antagen ansvarig.
+
+Ingen generell infrastruktur för optimistiska uppdateringar ska införas.
+Lösningen ska hållas lokal till uppgiftslistan och drag-and-drop-flödet.
+Feature 5:s statusknappar ska fortsatt vara serverbekräftade: kortet ligger kvar
+i sin aktuella kolumn tills backend svarar.
+
+## Otilldelad uppgift till Pågående
+
+När en otilldelad uppgift dras till `IN_PROGRESS` ska frontend:
+
+- skicka målstatus `IN_PROGRESS`;
+- skicka aktiv användares id;
+- optimistiskt visa aktiv användare som ansvarig;
+- låta backend tilldela användaren och ändra status i samma transaktion.
+
+Om uppgiften redan har en ansvarig ska frontend inte optimistiskt ersätta denna
+med den aktiva användaren. Serverresponsen ersätter alltid det optimistiska
+antagandet.
+
+Drag-and-drop ska inte visa ett nytt ansvarigval.
+
+## Drag-and-drop-bibliotek
+
+Feature 6 ska använda dnd-kit-ekosystemets aktuella stabila React-lösning.
+Featuredokumentet låser inte exakta paket eller API:n. Codex ska vid
+implementation verifiera den aktuella officiella dokumentationen, vilka paket
+som är aktuella respektive legacy, kompatibilitet med repositoryts
+React-version samt påverkan på Vitest/jsdom och React Testing Library.
+
+Den valda lösningen ska stödja:
+
+- draggable-kort;
+- droppable-statuskolumner;
+- pointer- och touchinteraktion;
+- aktiveringsvillkor;
+- avbruten dragning;
+- identifiering av målkolumn.
+
+Biblioteket ska inte användas för:
+
+- sortering inom kolumner;
+- persistent ordning;
+- egen domänmodell;
+- generell state-hantering;
+- parallell statuslogik.
+
+Dragbibliotekets händelser ska översättas till en gemensam,
+bibliotekoberoende ingång till statusflödet.
+
+## Statusknapparnas roll
+
+Feature 5:s statusknappar behålls tills vidare som ett fullt fungerande
+alternativ. De betraktas inte som en permanent del av målbilden. Den
+ursprungliga visuella designen innehåller inte statusknappar, och de ska därför
+enkelt kunna tas bort efter utvärdering.
+
+Implementation ska följa dessa principer:
+
+- drag-and-drop får inte byggas ovanpå knappkomponenterna;
+- draglogik får inte placeras i knapparna;
+- statuslogik får inte dupliceras mellan knappar och drag-and-drop;
+- båda ska dela underliggande requestlogik, låsning per task-id, felhantering
+  och ersättning med serverrespons;
+- drag-and-drop använder optimistisk visuell flytt, medan statusknapparna
+  förblir serverbekräftade och låter kortet ligga kvar tills backend svarar;
+- den visuella presentationsstrategin får därför skilja sig mellan
+  interaktionerna;
+- vänteläge, felhantering och serverrespons ska höra till uppgiften och det
+  delade statusflödet, inte dupliceras per kontroll;
+- kortlayouten får inte strukturellt förutsätta att knapparna alltid finns.
+
+Att ta bort statusknapparna senare ska inte kräva ändringar i status-API,
+dragmekanik, rollback eller task-state. Statusarkitekturen får inte vara kopplad
+till att knapparna finns kvar.
+
+## Vänteläge
+
+När statusanropet pågår ska det optimistiskt flyttade kortet tonas ned lätt.
+Ingen text som `Flyttar…` och ingen spinner krävs i första versionen.
+
+Under vänteläget ska just detta kort inte kunna:
+
+- dras igen;
+- initiera en ny statusändring;
+- ändra ansvarig.
+
+Övriga kort ska förbli interaktiva.
+
+Flera olika kort får ha statusanrop pågående samtidigt. Låsning, nedtoning,
+rollback och fel hanteras per task-id.
+
+## Fel och återställning
+
+Vid ett misslyckat statusanrop ska:
+
+- hela den tidigare task-versionen återställas;
+- kortet återgå till ursprungskolumnen;
+- tidigare ansvarig återställas;
+- nedtoningen tas bort;
+- felet visas lokalt på kortet;
+- målkolumnen inte behålla någon tillfällig markering.
+
+Tidigare klientdata ska inte delvis blandas med det misslyckade optimistiska
+tillståndet. Ett fel på ett kort ska inte blockera resten av brädan.
+
+## Serverrespons
+
+Vid lyckat statusanrop ska frontend alltid ersätta den optimistiska uppgiften
+med hela serverresponsen.
+
+Det gäller även om serverresponsen skiljer sig från frontendens antagande vad
+gäller exempelvis:
+
+- status;
+- ansvarig;
+- andra returnerade task-fält.
+
+Servern är slutlig sanning.
+
+## Dragyta
+
+Kortets icke-interaktiva yta ska fungera som dragyta. Knappar, select och andra
+interaktiva element ska inte initiera dragning.
+
+Implementation får avgöra sensoruppsättning, aktiveringströskel samt avstånd,
+fördröjning och tolerans. Vanliga klick och små fingerrörelser får inte
+oavsiktligt starta dragning, och kortets interaktiva kontroller ska fungera
+normalt.
+
+Dragmekaniken ska implementeras så att ett separat draghandtag senare kan
+införas utan att statusoperation, API-anrop, rollback eller task-state behöver
+ändras. Det bör räcka att flytta bibliotekets draglisteners och tillhörande
+attribut från kortets rot till handtaget.
+
+## Målkolumner
+
+Kolumnerna behöver ingen stark eller permanent drop-markering. Den kolumn som
+kortet befinner sig över kan vid behov få en mycket diskret hover-effekt,
+exempelvis:
+
+- en svag bakgrundsförändring;
+- en tunn kant;
+- annan lågmäld visuell återkoppling.
+
+Feature 6 ska inte införa stora färgade drop-zoner eller en generell redesign
+av brädan. Om manuell verifiering visar att ingen markering behövs kan även den
+diskreta hover-effekten utelämnas.
+
+## Drop i samma kolumn
+
+Om ett kort släpps i kolumnen som motsvarar dess nuvarande status ska
+operationen vara no-op.
+
+Det innebär:
+
+- inget API-anrop;
+- ingen statusändring;
+- ingen ändring av ordning;
+- inget vänteläge;
+- inget felmeddelande.
+
+## Avbruten dragning
+
+Om en dragning avbryts eller avslutas utanför en giltig målkolumn ska
+operationen vara no-op. Kortet ska återgå till sin normala position utan
+API-anrop eller felindikering.
+
+## Desktop och touch
+
+Desktop är det primära användningsfallet för Feature 6.
+
+Touch ska fungera på en rimlig grundnivå, men featuren ska inte införa en
+särskild mobil Kanban-design. Brädans befintliga responsiva layout ska
+behållas. Feature 6 ska inte införa horisontell scrollning. På smala skärmar
+får kolumnerna fortsätta använda repositoryts nuvarande responsiva layout,
+även om de staplas vertikalt.
+
+Implementation får avgöra sensoruppsättning, aktiveringsvillkor, eventuell
+`touch-action`, collision detection och drag-overlay. Valen måste bevara normal
+vertikal scrollning på mobil och får inte göra interaktiva kortkontroller
+svåranvända.
+
+Draglogiken ska:
+
+- identifiera mål genom status, inte genom en fast skärmposition;
+- inte förutsätta att kolumnerna ligger horisontellt;
+- hållas separerad från layout-CSS;
+- kunna fortsätta fungera om kolumnlayouten senare ändras.
+
+Om manuell verifiering visar att dragning mellan staplade kolumner fungerar
+dåligt kan mobilbeteendet ändras senare utan att status- eller rollbacklogiken
+görs om. Statusknapparna finns kvar som alternativ, särskilt där dragning är
+opraktisk.
+
+## Tangentbord och tillgänglighet
+
+Tangentbordsstyrd drag-and-drop ingår inte som grundkrav i Feature 6.
+Statusknapparna ska fortsatt ge en fungerande tangentbordsväg för
+statusändring. Drag-and-drop får därför inte vara den enda möjliga vägen.
+
+Feature 6 ska ändå uppfylla grundläggande tillgänglighetskrav:
+
+- interaktiva kontroller ska fortsatt gå att nå med tangentbord;
+- ett upptaget kort ska inte kunna aktiveras igen;
+- fokus ska inte tappas oförklarligt efter lyckad operation eller rollback;
+- begripliga etiketter ska bevaras;
+- dragbibliotekets standard-ARIA får användas;
+- ingen omfattande speciallösning för tangentbordsdragning ska byggas.
+
+Förbättrat tangentbordsstöd för själva dragningen kan införas i en senare
+uppdatering.
+
+## Gemensamt statusflöde
+
+Frontend ska ha ett gemensamt, kontrolloberoende statusflöde för den
+underliggande statusändringen.
+
+Det delade flödet ska ansvara för:
+
+- kontroll av pågående operation för task-id;
+- requestformat;
+- aktiv användares id vid behov;
+- per-kort-vänteläge;
+- ersättning med serverrespons;
+- lokalt statusfel.
+
+Drag-and-drop-flödet ska därutöver beräkna den optimistiska task-versionen,
+spara rollback-värdet och återställa hela den tidigare uppgiften vid fel.
+Statusknapparna ska inte göra en optimistisk flytt.
+
+Drag-and-drop och statusknappar är separata sätt att ange målstatus till det
+delade flödet, men får använda olika visuell presentationsstrategi.
+Tilldelningskontrollen ska återanvända samma per-kort-låsning så att status och
+tilldelning inte kan ändras samtidigt på samma uppgift.
+
+## Frontendtester
+
+Frontendtesterna verifierar beteende och state utan att förutsätta fysisk
+layout eller exakta pointer-koordinater i jsdom. Dragadaptern mockas i
+brädtesterna, medan den bibliotekoberoende mappningen från draghändelse till
+task-id och målstatus testas separat.
+
+Testerna täcker bland annat:
+
+- korrekt statusanrop och optimistisk flytt till en annan kolumn;
+- låsning och nedtoning per task-id medan anropet pågår;
+- att andra kort kan ha samtidiga operationer;
+- automatisk optimistisk tilldelning till aktiv användare;
+- att en befintlig ansvarig behålls;
+- att hela serverresponsen ersätter det optimistiska värdet;
+- fullständig rollback och lokalt fel vid misslyckande;
+- no-op för samma status, avbruten dragning och ogiltigt mål;
+- att statusknapparnas befintliga serverbekräftade beteende är bevarat.
+
+Totalt passerar 44 frontendtester. TypeScript-kompileringen och Vites
+produktionsbygge passerar också.
+
+## Backendtester
+
+Backend ändrades inte. Feature 5:s befintliga tester fortsätter därför att
+utgöra verifiering av:
+
+- direkta statusövergångar;
+- idempotens;
+- automatisk tilldelning;
+- bevarad befintlig ansvarig;
+- statusvalidering;
+- statusberoende tilldelningsregler;
+- oförändrade övriga task-fält.
+
+## Manuell verifiering
+
+Manuell browserverifiering är genomförd. Följande verifierades:
+
+- drag-and-drop mellan statuskolumner fungerar;
+- kortet flyttas optimistiskt och tonas ned under statusanropet;
+- en otilldelad uppgift som flyttas till Pågående får aktiv användare som
+  ansvarig;
+- en befintlig ansvarig behålls;
+- serverns svar ersätter det optimistiska värdet;
+- statusknapparna fungerar fortsatt;
+- ett blockerat statusanrop visar
+  `Det gick inte att ändra status. Försök igen.`;
+- kortet återställs till ursprungskolumnen vid fel;
+- tidigare ansvarig återställs, nedtoningen försvinner och kortet blir
+  interaktivt igen;
+- övriga kort förblir interaktiva under operationen.
+
+## Dokumentation
+
+Feature 6 ska dokumenteras i:
+
+```text
+docs/features/006-task-drag-and-drop.md
+```
+
+Vid implementation ska även följande uppdateras när det är relevant:
+
+```text
+README.md
+docs/architecture.md
+docs/roadmap.md
+```
+
+Roadmapen behåller statusen `Pågående` tills featuren har mergats, eftersom
+roadmapens status `Klar` även kräver merge.
+
+Ett nytt ADR behövs endast om biblioteksvalet bedöms vara ett övergripande,
+långlivat frontendbeslut som påverkar fler delar av applikationen än Feature
+6. Om `dnd-kit` endast används lokalt för denna feature bör beslutet normalt
+dokumenteras i feature- och arkitekturdokumentationen.
+
+## Acceptanskriterier
+
+Feature 6 är klar när:
+
+- kort kan dras mellan olika statuskolumner;
+- dragningen använder Feature 5:s status-API;
+- kortet flyttas optimistiskt till målkolumnen;
+- kortet tonas ned under serveranropet;
+- samma kort är låst för status, dragning och tilldelning under anropet;
+- andra kort förblir interaktiva;
+- otilldelad uppgift till Pågående använder aktiv användares id;
+- befintlig ansvarig behålls;
+- serverresponsen ersätter det optimistiska tillståndet;
+- fel återställer hela tidigare task-versionen;
+- kortet återgår till ursprungskolumnen vid fel;
+- felet visas lokalt på kortet;
+- drop i samma kolumn är no-op;
+- avbruten dragning är no-op;
+- ingen manuell eller persistent kortordning har införts;
+- statusknapparna fungerar fortsatt men är arkitekturellt frikopplade;
+- statusknapparna förblir serverbekräftade medan drag-and-drop är optimistisk;
+- statusknapparna kan tas bort senare utan att drag- eller statuslogiken byggs
+  om;
+- kortets icke-interaktiva yta fungerar som dragyta;
+- interaktiva kortkontroller initierar inte dragning;
+- ett senare draghandtag kan införas utan ändring av statusflödet;
+- normal vertikal scrollning på mobil bevaras;
+- ingen horisontell scrollning har införts;
+- desktop fungerar väl;
+- touch fungerar på rimlig grundnivå;
+- tangentbordsdragning inte krävs;
+- statusändring fortsatt är möjlig med tangentbord genom statusknapparna;
+- frontendtesterna täcker centrala stateövergångar och felfall;
+- manuell verifiering täcker dragkänsla, touch, layout och rollback;
+- backend är oförändrad om inget konkret behov av justering hittas;
+- relevant dokumentation är uppdaterad.
+
+## Implementationsprinciper
+
+Vid implementationen användes följande dokumentation som tekniskt underlag:
+
+```text
+AGENTS.md
+README.md
+docs/architecture.md
+docs/development.md
+docs/roadmap.md
+docs/decisions/
+docs/features/004-task-assignment.md
+docs/features/005-task-status.md
+```
+
+Relevant frontendkod och tester granskades särskilt avseende:
+
+- aktuell React-version;
+- frontendens installerade beroenden;
+- aktuell officiell dnd-kit-dokumentation;
+- vilka dnd-kit-paket som är aktuella respektive legacy;
+- dnd-kit-lösningens kompatibilitet med React-versionen;
+- påverkan på Vitest/jsdom och React Testing Library;
+- aktuell task-typ;
+- brädans kolumnstruktur;
+- uppgiftskortets komponentstruktur;
+- befintliga statusknappar;
+- statusanropets requestformat;
+- hur aktiv användare representeras;
+- hur tasks ersätts i state;
+- det gemensamma vänteläget per kort;
+- status- och tilldelningsfel;
+- tilldelningskontrollens inaktiveringslogik;
+- aktuell teststil;
+- vilka pointer- och draghändelser testmiljön stödjer.
+
+Repositoryts faktiska kod och dokumentation har företräde framför antaganden i
+denna featurebeskrivning.
+
+Kod, tester och relevant dokumentation ska uppdateras tillsammans.
+
+Codex ska inte committa, pusha, skapa pull request eller merga utan uttrycklig
+instruktion.

docs/roadmap.md

@@ -34,24 +34,31 @@ Följande statusvärden används:
 
 ## Nuvarande läge
 
-Feature 0–4 är klara. Den aktuella applikationen har:
+Feature 0–5 är klara. Feature 6 är implementerad och verifierad på sin
+feature-branch men ännu inte mergad. Den aktuella applikationen på
+feature-branchen 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;
+- tilldelning och byte av ansvarig i samtliga statusar;
+- borttagning av ansvarig i `WAITING` och `COMPLETED`;
+- backendstyrda statusändringar mellan `WAITING`, `IN_PROGRESS` och `COMPLETED`;
+- automatisk tilldelning till aktiv användare när en otilldelad uppgift påbörjas;
+- drag-and-drop mellan statuskolumner med optimistisk flytt och rollback;
 - en bräda med Väntande, Pågående och Klart;
 - nya uppgifter som alltid skapas med status `WAITING`.
 
 Tilldelning och status är separata egenskaper; tilldelningsflödet ändrar inte
-uppgiftens status. Statusändring och regeln att `IN_PROGRESS` kräver ansvarig
+uppgiftens status. Alla direkta statusövergångar är tillåtna och
-är under utveckling. Det finns ännu ingen drag-and-drop, redigering, radering,
+`IN_PROGRESS` kräver ansvarig. Det finns ännu ingen redigering, radering,
-deadline eller återkommande uppgift.
+deadline eller återkommande uppgift. Nuvarande användarval är inte
-Nuvarande användarval är inte autentisering.
+autentisering.
 
-**Feature 5 – Statusändring och statusregler är pågående.**
+**Feature 6 – Drag-and-drop är färdig och verifierad på feature-branchen men
+står kvar som Pågående tills den har mergats.**
 
 ## Featureöversikt
 
@@ -62,8 +69,8 @@ Nuvarande användarval är inte autentisering.
 | 2 – Skapa uppgifter | Klar | 0–1 | Gemensamma uppgifter och trekolumnsbräda |
 | 3 – Uppgiftspoäng | Klar | 2 | Poäng på uppgifter |
 | 4 – Tilldelning | Klar | 1–2 | Valfri ansvarig användare |
-| 5 – Statusändring | Pågående | 4 | Backendstyrda statusövergångar |
+| 5 – Statusändring | Klar | 4 | Backendstyrda statusövergångar |
-| 6 – Drag-and-drop | Planerad | 5 | Kortflytt via status-API |
+| 6 – Drag-and-drop | Pågående | 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 |
@@ -152,7 +159,7 @@ senare måste ha en ansvarig. Hur borttagna användare ska hanteras är fortsatt
 
 ### Feature 5 – Statusändring och statusregler
 
-**Status:** Pågående
+**Status:** Klar
 
 **Beroenden:** Feature 4
 
@@ -175,7 +182,7 @@ inte tas bort medan uppgiften är pågående.
 
 ### Feature 6 – Drag-and-drop
 
-**Status:** Planerad
+**Status:** Pågående
 
 **Beroenden:** Feature 5
 
@@ -189,10 +196,14 @@ inte tas bort medan uppgiften är pågående.
 Drag-and-drop kommer efter det enklare statusflödet för att återanvända
 verifierade backendregler.
 
-**Öppna frågor:**
+Drag-and-drop använder en kontrollerad optimistisk flytt. Vid fel återställs
-
+hela den tidigare task-versionen. En otilldelad uppgift som dras till Pågående
-- optimistisk eller serverbekräftad uppdatering;
+använder Feature 5:s befintliga automatiska tilldelning till aktiv användare.
-- exakt tilldelningsflöde vid flytt till Pågående.
+Serverns fullständiga task-respons ersätter alltid det optimistiska värdet.
+Statusknapparna förblir tills vidare serverbekräftade. Implementation och
+automatisk samt manuell verifiering är färdiga på feature-branchen; statusen
+förblir `Pågående` tills merge eftersom `Klar` enligt roadmapen även kräver att
+featuren är mergad.
 
 ## Fas 2 – Hantering av uppgifter
 
@@ -433,6 +444,11 @@ Nuvarande aktiva användarval är uttryckligen inte autentisering.
 
 ## Ändringshistorik
 
+- 2026-07-27: Feature 6 implementerades och verifierades automatiskt och
+  manuellt på feature-branchen. Den behåller statusen Pågående tills merge.
+- 2026-07-27: Feature 5 verifierades och mergades. Backendstyrda
+  statusövergångar, automatisk tilldelning vid påbörjande och statusberoende
+  tilldelningsregler infördes. Feature 6 blev nästa planerade produktfeature.
 - 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

frontend/package.json

@@ -9,6 +9,8 @@
     "test": "vitest run"
   },
   "dependencies": {
+    "@dnd-kit/dom": "0.5.0",
+    "@dnd-kit/react": "0.5.0",
     "react": "19.2.8",
     "react-dom": "19.2.8"
   },

frontend/pnpm-lock.yaml

@@ -8,6 +8,12 @@ importers:
 
   .:
     dependencies:
+      '@dnd-kit/dom':
+        specifier: 0.5.0
+        version: 0.5.0
+      '@dnd-kit/react':
+        specifier: 0.5.0
+        version: 0.5.0(react-dom@19.2.8(react@19.2.8))(react@19.2.8)
       react:
         specifier: 19.2.8
         version: 19.2.8
@@ -115,6 +121,27 @@ packages:
     resolution: {integrity: sha512-QxULHAm7cNu72w97JUNCBFODFaXpbDg+dP8b/oWFAZ2MTRppA3U00Y2L1HqaS4J6yBqxwa/Y3nMBaxVKbB/NsA==}
     engines: {node: '>=20.19.0'}
 
+  '@dnd-kit/abstract@0.5.0':
+    resolution: {integrity: sha512-hi13iMJgjPX/KDYVKg5VeDIhmYiV6buc9bAX+tCLYf4QdyYjPbsXjn2sPo6m7fQ6SGJBEFgHJ2PemeKDUbwBaA==}
+
+  '@dnd-kit/collision@0.5.0':
+    resolution: {integrity: sha512-xUqRn3lS7oqLkT0AnnHS/STh/Czvwe1UapZFYiLbsUGxopMsQd4teaPCzPouOThoMdGEe+dHWjfqJl6t9iG4mQ==}
+
+  '@dnd-kit/dom@0.5.0':
+    resolution: {integrity: sha512-f2xFJp5SYQ8EW/Fbtaa8iBb66hpkWc7qa8vU826KW11/tb44sH+AisZnGtwOOTWTQ0GraqBDr5ixTErww+eKXw==}
+
+  '@dnd-kit/geometry@0.5.0':
+    resolution: {integrity: sha512-ubHQS1CiSDH8ssYH2xG5BnpwPSFP1tStXXjug7/Ba6qnQdu/EUH47l6QXKIksQnnanfVfDf0aGeevRxgZlj28A==}
+
+  '@dnd-kit/react@0.5.0':
+    resolution: {integrity: sha512-abQPLI8lmfVE+v/n+pqy5WFxrw6T2Yg0UQZsL78dp5DKci7dKTVDjvLWqvass+XTFtzJmsZEjk1NdqE6xG8Jiw==}
+    peerDependencies:
+      react: ^18.0.0 || ^19.0.0
+      react-dom: ^18.0.0 || ^19.0.0
+
+  '@dnd-kit/state@0.5.0':
+    resolution: {integrity: sha512-y7XbabQqjF58Lk8YmDQuR8l6QjN+Kh4qlGEjUvHuIeasLk1QP+9L5diXS98VMxQIivyMmUtX2//f+3N7qPJX4w==}
+
   '@emnapi/core@1.11.1':
     resolution: {integrity: sha512-RSvbQmHzdKzNsLYa/wHrbc3KN4sYLKAdPZxqiM2HATqv/SBk2/ENSHpvXGaLOMcsAyz0poEGqkmmKYG3OWiJEQ==}
 
@@ -145,6 +172,9 @@ packages:
   '@oxc-project/types@0.139.0':
     resolution: {integrity: sha512-r9gHphtCs+1M7J0pw6Sn/hh/Wpa/iQrOOkrNAlVLF/gHq+/CJmHIWKKUUhdWjcD6CIa8idarspCsASiXCXvFUw==}
 
+  '@preact/signals-core@1.14.4':
+    resolution: {integrity: sha512-HNB6HYeYKhQbJ1aKl+YRjrS4+QWHLKX6qKoUsfS/m0vqzsVaEBiZiaKbG/e+NKk2ch5ALQr/ihWaMHxiCuuWHA==}
+
   '@rolldown/binding-android-arm64@1.1.5':
     resolution: {integrity: sha512-lZg8fqIv2v7FF237bwMgzGZEJvGL79/s5knJ/i6FmsGF4XXlzccZ4jb+TrFIxtSSxFtIpdsgrPZeMk1I9AFcyQ==}
     engines: {node: ^20.19.0 || >=22.12.0}
@@ -961,6 +991,45 @@ snapshots:
 
   '@csstools/css-tokenizer@4.0.0': {}
 
+  '@dnd-kit/abstract@0.5.0':
+    dependencies:
+      '@dnd-kit/geometry': 0.5.0
+      '@dnd-kit/state': 0.5.0
+      tslib: 2.8.1
+
+  '@dnd-kit/collision@0.5.0':
+    dependencies:
+      '@dnd-kit/abstract': 0.5.0
+      '@dnd-kit/geometry': 0.5.0
+      tslib: 2.8.1
+
+  '@dnd-kit/dom@0.5.0':
+    dependencies:
+      '@dnd-kit/abstract': 0.5.0
+      '@dnd-kit/collision': 0.5.0
+      '@dnd-kit/geometry': 0.5.0
+      '@dnd-kit/state': 0.5.0
+      tslib: 2.8.1
+
+  '@dnd-kit/geometry@0.5.0':
+    dependencies:
+      '@dnd-kit/state': 0.5.0
+      tslib: 2.8.1
+
+  '@dnd-kit/react@0.5.0(react-dom@19.2.8(react@19.2.8))(react@19.2.8)':
+    dependencies:
+      '@dnd-kit/abstract': 0.5.0
+      '@dnd-kit/dom': 0.5.0
+      '@dnd-kit/state': 0.5.0
+      react: 19.2.8
+      react-dom: 19.2.8(react@19.2.8)
+      tslib: 2.8.1
+
+  '@dnd-kit/state@0.5.0':
+    dependencies:
+      '@preact/signals-core': 1.14.4
+      tslib: 2.8.1
+
   '@emnapi/core@1.11.1':
     dependencies:
       '@emnapi/wasi-threads': 1.2.2
@@ -990,6 +1059,8 @@ snapshots:
 
   '@oxc-project/types@0.139.0': {}
 
+  '@preact/signals-core@1.14.4': {}
+
   '@rolldown/binding-android-arm64@1.1.5':
     optional: true
 
@@ -1476,8 +1547,7 @@ snapshots:
     dependencies:
       punycode: 2.3.1
 
-  tslib@2.8.1:
+  tslib@2.8.1: {}
-    optional: true
 
   typescript@7.0.2:
     optionalDependencies:

frontend/src/App.test.tsx

@@ -1,7 +1,33 @@
-import { cleanup, fireEvent, render, screen, waitFor, within } from '@testing-library/react'
+import type { ReactNode } from 'react'
+import { act, cleanup, fireEvent, render, screen, waitFor, within } from '@testing-library/react'
 import { afterEach, beforeEach, expect, test, vi } from 'vitest'
 import App from './App'
 
+const dragAndDrop = vi.hoisted(() => ({
+  onTaskDrop: null as ((taskId: string, status: string) => void) | null,
+}))
+
+vi.mock('./TaskDragAndDrop', () => ({
+  TaskDragDropProvider: ({
+    children,
+    onTaskDrop,
+  }: {
+    children: ReactNode
+    onTaskDrop: (taskId: string, status: string) => void
+  }) => {
+    dragAndDrop.onTaskDrop = onTaskDrop
+    return children
+  },
+  useTaskDraggable: () => ({
+    ref: () => {},
+    isDragging: false,
+  }),
+  useTaskColumnDropTarget: () => ({
+    ref: () => {},
+    isDropTarget: false,
+  }),
+}))
+
 const users = [
   {
     id: 'd56b54dd-31b0-4d71-8a10-82464be59a61',
@@ -47,6 +73,7 @@ const tasks = [
 
 beforeEach(() => {
   window.localStorage.clear()
+  dragAndDrop.onTaskDrop = null
 })
 
 afterEach(() => {
@@ -513,6 +540,174 @@ test('statusfel behåller tidigare status och ansvarig och visas på kortet', as
   expect(within(card).getByText('Ta uppgift')).toBeInTheDocument()
 })
 
+test('drag flyttar optimistiskt, låser kortet och använder hela serverresponsen', async () => {
+  const otherTask = {
+    ...tasks[0],
+    id: '00000000-0000-0000-0000-000000000010',
+    title: 'Putsa fönster',
+  }
+  const serverTask = {
+    ...tasks[0],
+    status: 'COMPLETED',
+    assignee: { id: users[1].id, name: users[1].name },
+  }
+  let resolveStatus!: (response: Response) => void
+  const statusResponse = new Promise<Response>((resolve) => {
+    resolveStatus = resolve
+  })
+  window.localStorage.setItem('hemhub.activeUserId', users[0].id)
+  const fetchMock = vi.spyOn(globalThis, 'fetch')
+  fetchMock.mockResolvedValueOnce(jsonResponse(users))
+  fetchMock.mockResolvedValueOnce(jsonResponse([tasks[0], otherTask]))
+  fetchMock.mockReturnValueOnce(statusResponse)
+  render(<App />)
+
+  await screen.findByText('Dammsuga')
+  act(() => dropTask(tasks[0].id, 'IN_PROGRESS'))
+
+  const inProgress = screen.getByRole('region', { name: 'Pågående' })
+  const optimisticCard = (await within(inProgress).findByText('Dammsuga')).closest('article')!
+  const waiting = screen.getByRole('region', { name: 'Väntande' })
+  const otherCard = within(waiting).getByText('Putsa fönster').closest('article')!
+
+  expect(within(optimisticCard).getByText('Urban')).toBeInTheDocument()
+  expect(optimisticCard).toHaveAttribute('aria-busy', 'true')
+  expect(optimisticCard).toHaveClass('task-card-pending')
+  expect(within(optimisticCard).getByRole('button', { name: 'Markera klar' })).toBeDisabled()
+  expect(
+    within(optimisticCard).getByRole('button', { name: 'Ändra ansvarig för Dammsuga' }),
+  ).toBeDisabled()
+  expect(within(otherCard).getByRole('button', { name: 'Påbörja' })).toBeEnabled()
+  expect(fetchMock).toHaveBeenLastCalledWith(`/api/tasks/${tasks[0].id}/status`, {
+    method: 'PUT',
+    headers: { 'Content-Type': 'application/json' },
+    body: JSON.stringify({
+      status: 'IN_PROGRESS',
+      activeUserId: users[0].id,
+    }),
+  })
+
+  act(() => dropTask(tasks[0].id, 'COMPLETED'))
+  expect(fetchMock).toHaveBeenCalledTimes(3)
+
+  await act(async () => resolveStatus(jsonResponse(serverTask)))
+
+  const completed = screen.getByRole('region', { name: 'Klart' })
+  const confirmedCard = (await within(completed).findByText('Dammsuga')).closest('article')!
+  expect(within(confirmedCard).getByText('Anna')).toBeInTheDocument()
+  expect(confirmedCard).not.toHaveAttribute('aria-busy')
+})
+
+test('dragfel återställer hela uppgiften och visar lokalt fel', async () => {
+  let resolveStatus!: (response: Response) => void
+  const statusResponse = new Promise<Response>((resolve) => {
+    resolveStatus = resolve
+  })
+  window.localStorage.setItem('hemhub.activeUserId', users[0].id)
+  const fetchMock = vi.spyOn(globalThis, 'fetch')
+  fetchMock.mockResolvedValueOnce(jsonResponse(users))
+  fetchMock.mockResolvedValueOnce(jsonResponse([tasks[0]]))
+  fetchMock.mockReturnValueOnce(statusResponse)
+  render(<App />)
+
+  await screen.findByText('Dammsuga')
+  act(() => dropTask(tasks[0].id, 'IN_PROGRESS'))
+
+  const inProgress = screen.getByRole('region', { name: 'Pågående' })
+  expect(await within(inProgress).findByText('Urban')).toBeInTheDocument()
+
+  await act(async () =>
+    resolveStatus(
+      jsonResponse(
+        {
+          code: 'TASK_REQUIRES_ASSIGNEE',
+          message: 'En pågående uppgift måste ha en ansvarig.',
+        },
+        409,
+      ),
+    ),
+  )
+
+  const waiting = screen.getByRole('region', { name: 'Väntande' })
+  const restoredCard = (await within(waiting).findByText('Dammsuga')).closest('article')!
+  expect(within(restoredCard).getByText('Ta uppgift')).toBeInTheDocument()
+  expect(within(restoredCard).queryByText('Urban')).not.toBeInTheDocument()
+  expect(await within(restoredCard).findByRole('alert')).toHaveTextContent(
+    'En pågående uppgift måste ha en ansvarig.',
+  )
+  expect(restoredCard).not.toHaveAttribute('aria-busy')
+})
+
+test('drag till Pågående behåller en befintlig ansvarig optimistiskt', async () => {
+  const assignedTask = {
+    ...tasks[0],
+    assignee: { id: users[1].id, name: users[1].name },
+  }
+  let resolveStatus!: (response: Response) => void
+  const statusResponse = new Promise<Response>((resolve) => {
+    resolveStatus = resolve
+  })
+  window.localStorage.setItem('hemhub.activeUserId', users[0].id)
+  const fetchMock = vi.spyOn(globalThis, 'fetch')
+  fetchMock.mockResolvedValueOnce(jsonResponse(users))
+  fetchMock.mockResolvedValueOnce(jsonResponse([assignedTask]))
+  fetchMock.mockReturnValueOnce(statusResponse)
+  render(<App />)
+
+  await screen.findByText('Dammsuga')
+  act(() => dropTask(assignedTask.id, 'IN_PROGRESS'))
+
+  const inProgress = screen.getByRole('region', { name: 'Pågående' })
+  expect(await within(inProgress).findByText('Anna')).toBeInTheDocument()
+  expect(within(inProgress).queryByText('Urban')).not.toBeInTheDocument()
+
+  await act(async () =>
+    resolveStatus(jsonResponse({ ...assignedTask, status: 'IN_PROGRESS' })),
+  )
+})
+
+test('drop i samma kolumn är no-op', async () => {
+  window.localStorage.setItem('hemhub.activeUserId', users[0].id)
+  const fetchMock = mockUsersAndTasks(users, [tasks[0]])
+  render(<App />)
+
+  await screen.findByText('Dammsuga')
+  act(() => dropTask(tasks[0].id, 'WAITING'))
+
+  expect(fetchMock).toHaveBeenCalledTimes(2)
+  expect(screen.getByText('Dammsuga').closest('article')).not.toHaveAttribute('aria-busy')
+})
+
+test('olika kort kan ha samtidiga optimistiska statusanrop', async () => {
+  const otherTask = {
+    ...tasks[0],
+    id: '00000000-0000-0000-0000-000000000010',
+    title: 'Putsa fönster',
+  }
+  const firstResponse = new Promise<Response>(() => {})
+  const secondResponse = new Promise<Response>(() => {})
+  window.localStorage.setItem('hemhub.activeUserId', users[0].id)
+  const fetchMock = vi.spyOn(globalThis, 'fetch')
+  fetchMock.mockResolvedValueOnce(jsonResponse(users))
+  fetchMock.mockResolvedValueOnce(jsonResponse([tasks[0], otherTask]))
+  fetchMock.mockReturnValueOnce(firstResponse)
+  fetchMock.mockReturnValueOnce(secondResponse)
+  render(<App />)
+
+  await screen.findByText('Dammsuga')
+  act(() => {
+    dropTask(tasks[0].id, 'IN_PROGRESS')
+    dropTask(otherTask.id, 'COMPLETED')
+  })
+
+  expect(screen.getByText('Dammsuga').closest('article')).toHaveAttribute('aria-busy', 'true')
+  expect(screen.getByText('Putsa fönster').closest('article')).toHaveAttribute(
+    'aria-busy',
+    'true',
+  )
+  expect(fetchMock).toHaveBeenCalledTimes(4)
+})
+
 test('ansvarig kan bytas i Pågående och tas bort i Klart', async () => {
   const changedInProgress = { ...tasks[1], assignee: { id: users[0].id, name: users[0].name } }
   const unassignedCompleted = { ...tasks[2], assignee: null }
@@ -690,6 +885,14 @@ function mockUsersAndTasks(userResponse: unknown, taskResponse: unknown) {
   return fetchMock
 }
 
+function dropTask(taskId: string, status: string) {
+  if (!dragAndDrop.onTaskDrop) {
+    throw new Error('Drag-and-drop-providern är inte monterad')
+  }
+
+  dragAndDrop.onTaskDrop(taskId, status)
+}
+
 function mockJsonResponse(body: unknown, status = 200) {
   return vi.spyOn(globalThis, 'fetch').mockResolvedValue(jsonResponse(body, status))
 }

frontend/src/TaskBoard.tsx

@@ -1,6 +1,10 @@
 import { FormEvent, MouseEvent, useEffect, useRef, useState } from 'react'
-
+import {
-type TaskStatus = 'WAITING' | 'IN_PROGRESS' | 'COMPLETED'
+  TaskDragDropProvider,
+  TaskStatus,
+  useTaskColumnDropTarget,
+  useTaskDraggable,
+} from './TaskDragAndDrop'
 
 type UserSummary = {
   id: string
@@ -122,11 +126,27 @@ function TaskBoard({ activeUserId, activeUserName, users, onLogOut }: TaskBoardP
     }
   }
 
-  const updateStatus = async (task: Task, status: TaskStatus) => {
+  const updateStatus = async (
+    task: Task,
+    status: TaskStatus,
+    presentation: 'server-confirmed' | 'optimistic',
+  ) => {
     if (!beginTaskRequest(task.id)) {
       return
     }
 
+    const previousTask = task
+    if (presentation === 'optimistic') {
+      replaceTask({
+        ...task,
+        status,
+        assignee:
+          status === 'IN_PROGRESS' && !task.assignee
+            ? { id: activeUserId, name: activeUserName }
+            : task.assignee,
+      })
+    }
+
     try {
       const response = await fetch(`/api/tasks/${task.id}/status`, {
         method: 'PUT',
@@ -139,6 +159,9 @@ function TaskBoard({ activeUserId, activeUserName, users, onLogOut }: TaskBoardP
 
       if (!response.ok) {
         const apiError = (await response.json().catch(() => ({}))) as ApiError
+        if (presentation === 'optimistic') {
+          replaceTask(previousTask)
+        }
         setTaskErrors((current) => ({
           ...current,
           [task.id]: apiError.message ?? 'Det gick inte att ändra status. Försök igen.',
@@ -149,6 +172,9 @@ function TaskBoard({ activeUserId, activeUserName, users, onLogOut }: TaskBoardP
       replaceTask((await response.json()) as Task)
       setEditingAssigneeTaskId(null)
     } catch {
+      if (presentation === 'optimistic') {
+        replaceTask(previousTask)
+      }
       setTaskErrors((current) => ({
         ...current,
         [task.id]: 'Det gick inte att ändra status. Försök igen.',
@@ -158,6 +184,16 @@ function TaskBoard({ activeUserId, activeUserName, users, onLogOut }: TaskBoardP
     }
   }
 
+  const dropTask = (taskId: string, status: TaskStatus) => {
+    const task = tasks.find((candidate) => candidate.id === taskId)
+
+    if (!task || task.status === status) {
+      return
+    }
+
+    void updateStatus(task, status, 'optimistic')
+  }
+
   return (
     <main className="task-app">
       <header className="app-header">
@@ -190,48 +226,25 @@ function TaskBoard({ activeUserId, activeUserName, users, onLogOut }: TaskBoardP
         </button>
       </div>
 
+      <TaskDragDropProvider onTaskDrop={dropTask}>
         <section className="board" aria-label="Uppgiftsbräda">
           {columns.map((column) => (
-          <section className="board-column" key={column.status} aria-labelledby={column.status}>
+            <TaskColumn
-            <h2 id={column.status}>{column.title}</h2>
+              column={column}
-            <div className="task-list">
+              tasks={tasks.filter((task) => task.status === column.status)}
-              {tasks
-                .filter((task) => task.status === column.status)
-                .map((task) => {
-                  const pending = pendingTaskIds.has(task.id)
-
-                  return (
-                    <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>}
-                      <AssigneeControl
-                        task={task}
               users={users}
-                        editing={editingAssigneeTaskId === task.id}
+              editingAssigneeTaskId={editingAssigneeTaskId}
-                        pending={pending}
+              pendingTaskIds={pendingTaskIds}
-                        onEdit={() => setEditingAssigneeTaskId(task.id)}
+              taskErrors={taskErrors}
-                        onChange={(assigneeId) => void updateAssignee(task, assigneeId)}
+              onEditAssignee={setEditingAssigneeTaskId}
+              onChangeAssignee={(task, assigneeId) => void updateAssignee(task, assigneeId)}
+              onChangeStatus={(task, status) =>
+                void updateStatus(task, status, 'server-confirmed')
+              }
             />
-                      <TaskStatusControls
-                        task={task}
-                        disabled={pending}
-                        onChange={(status) => void updateStatus(task, status)}
-                      />
-                      {taskErrors[task.id] && (
-                        <p className="task-error error" role="alert">
-                          {taskErrors[task.id]}
-                        </p>
-                      )}
-                    </article>
-                  )
-                })}
-            </div>
-          </section>
           ))}
         </section>
+      </TaskDragDropProvider>
 
       {showCreateTask && (
         <CreateTaskModal
@@ -247,6 +260,112 @@ function TaskBoard({ activeUserId, activeUserName, users, onLogOut }: TaskBoardP
   )
 }
 
+type TaskColumnProps = {
+  column: { status: TaskStatus; title: string }
+  tasks: Task[]
+  users: UserSummary[]
+  editingAssigneeTaskId: string | null
+  pendingTaskIds: Set<string>
+  taskErrors: Record<string, string>
+  onEditAssignee: (taskId: string) => void
+  onChangeAssignee: (task: Task, assigneeId: string) => void
+  onChangeStatus: (task: Task, status: TaskStatus) => void
+}
+
+function TaskColumn({
+  column,
+  tasks,
+  users,
+  editingAssigneeTaskId,
+  pendingTaskIds,
+  taskErrors,
+  onEditAssignee,
+  onChangeAssignee,
+  onChangeStatus,
+}: TaskColumnProps) {
+  const { ref, isDropTarget } = useTaskColumnDropTarget(column.status)
+
+  return (
+    <section
+      ref={ref}
+      className={`board-column${isDropTarget ? ' board-column-drop-target' : ''}`}
+      aria-labelledby={column.status}
+    >
+      <h2 id={column.status}>{column.title}</h2>
+      <div className="task-list">
+        {tasks.map((task) => (
+          <TaskCard
+            key={task.id}
+            task={task}
+            users={users}
+            editingAssignee={editingAssigneeTaskId === task.id}
+            pending={pendingTaskIds.has(task.id)}
+            error={taskErrors[task.id]}
+            onEditAssignee={() => onEditAssignee(task.id)}
+            onChangeAssignee={(assigneeId) => onChangeAssignee(task, assigneeId)}
+            onChangeStatus={(status) => onChangeStatus(task, status)}
+          />
+        ))}
+      </div>
+    </section>
+  )
+}
+
+type TaskCardProps = {
+  task: Task
+  users: UserSummary[]
+  editingAssignee: boolean
+  pending: boolean
+  error?: string
+  onEditAssignee: () => void
+  onChangeAssignee: (assigneeId: string) => void
+  onChangeStatus: (status: TaskStatus) => void
+}
+
+function TaskCard({
+  task,
+  users,
+  editingAssignee,
+  pending,
+  error,
+  onEditAssignee,
+  onChangeAssignee,
+  onChangeStatus,
+}: TaskCardProps) {
+  const { ref, isDragging } = useTaskDraggable(task.id, pending)
+
+  return (
+    <article
+      ref={ref}
+      role="article"
+      className={`task-card${pending ? ' task-card-pending' : ''}${
+        isDragging ? ' task-card-dragging' : ''
+      }`}
+      aria-busy={pending || undefined}
+    >
+      <div className="task-card-header">
+        <h3>{task.title}</h3>
+        <span className="points-badge">{task.points} p</span>
+      </div>
+      {task.description && <p>{task.description}</p>}
+      <AssigneeControl
+        task={task}
+        users={users}
+        editing={editingAssignee}
+        pending={pending}
+        onEdit={onEditAssignee}
+        onChange={onChangeAssignee}
+      />
+      <TaskStatusControls task={task} disabled={pending} onChange={onChangeStatus} />
+      {error && (
+        <p className="task-error error" role="alert">
+          {error}
+        </p>
+      )}
+    </article>
+  )
+}
+
 type AssigneeControlProps = {
   task: Task
   users: UserSummary[]

frontend/src/TaskDragAndDrop.test.ts

@@ -0,0 +1,18 @@
+import { expect, test } from 'vitest'
+import { resolveTaskDrop } from './TaskDragAndDrop'
+
+test.each(['WAITING', 'IN_PROGRESS', 'COMPLETED'] as const)(
+  'mappar målkolumnen %s till motsvarande status',
+  (status) => {
+    expect(resolveTaskDrop('task-1', status, false)).toEqual({
+      taskId: 'task-1',
+      targetStatus: status,
+    })
+  },
+)
+
+test('avbruten dragning och ogiltig målkolumn är no-op', () => {
+  expect(resolveTaskDrop('task-1', 'WAITING', true)).toBeNull()
+  expect(resolveTaskDrop('task-1', undefined, false)).toBeNull()
+  expect(resolveTaskDrop('task-1', 'UNKNOWN', false)).toBeNull()
+})

frontend/src/TaskDragAndDrop.tsx

@@ -0,0 +1,90 @@
+import { ReactNode } from 'react'
+import { DragDropProvider, useDraggable, useDroppable } from '@dnd-kit/react'
+import { PointerActivationConstraints, PointerSensor } from '@dnd-kit/dom'
+
+export type TaskStatus = 'WAITING' | 'IN_PROGRESS' | 'COMPLETED'
+
+type TaskDragDropProviderProps = {
+  children: ReactNode
+  onTaskDrop: (taskId: string, targetStatus: TaskStatus) => void
+}
+
+const taskStatuses = new Set<TaskStatus>(['WAITING', 'IN_PROGRESS', 'COMPLETED'])
+
+const pointerSensor = PointerSensor.configure({
+  activationConstraints(event) {
+    if (event.pointerType === 'touch') {
+      return [new PointerActivationConstraints.Delay({ value: 250, tolerance: 8 })]
+    }
+
+    return [new PointerActivationConstraints.Distance({ value: 6 })]
+  },
+})
+
+export function resolveTaskDrop(
+  sourceId: string | number | undefined,
+  targetId: string | number | undefined,
+  canceled: boolean,
+) {
+  if (
+    canceled ||
+    sourceId === undefined ||
+    typeof targetId !== 'string' ||
+    !taskStatuses.has(targetId as TaskStatus)
+  ) {
+    return null
+  }
+
+  return {
+    taskId: String(sourceId),
+    targetStatus: targetId as TaskStatus,
+  }
+}
+
+export function TaskDragDropProvider({
+  children,
+  onTaskDrop,
+}: TaskDragDropProviderProps) {
+  return (
+    <DragDropProvider
+      sensors={(defaults) => [
+        ...defaults.filter((sensor) => sensor !== PointerSensor),
+        pointerSensor,
+      ]}
+      onDragEnd={(event) => {
+        const drop = resolveTaskDrop(
+          event.operation.source?.id,
+          event.operation.target?.id,
+          event.canceled,
+        )
+
+        if (!drop) {
+          return
+        }
+
+        onTaskDrop(drop.taskId, drop.targetStatus)
+      }}
+    >
+      {children}
+    </DragDropProvider>
+  )
+}
+
+export function useTaskDraggable(taskId: string, disabled: boolean) {
+  const { ref, isDragging } = useDraggable({
+    id: taskId,
+    type: 'task',
+    disabled,
+  })
+
+  return { ref, isDragging }
+}
+
+export function useTaskColumnDropTarget(status: TaskStatus) {
+  const { ref, isDropTarget } = useDroppable({
+    id: status,
+    accept: 'task',
+  })
+
+  return { ref, isDropTarget }
+}

frontend/src/styles.css

@@ -158,8 +158,15 @@ textarea {
 .board-column {
   min-height: 20rem;
   padding: 1rem;
+  border: 1px solid transparent;
   border-radius: 0.75rem;
   background: #e5e7eb;
+  transition: border-color 120ms ease, background-color 120ms ease;
+}
+
+.board-column-drop-target {
+  border-color: #93c5fd;
+  background: #e0e7ff;
 }
 
 .board-column h2 {
@@ -180,6 +187,14 @@ textarea {
   box-shadow: 0 0.125rem 0.4rem rgb(0 0 0 / 8%);
 }
 
+.task-card-pending {
+  opacity: 0.65;
+}
+
+.task-card-dragging {
+  cursor: grabbing;
+}
+
 .task-card h3,
 .task-card p {
   margin: 0;

frontend/src/test/setup.ts

@@ -1,5 +1,15 @@
 import '@testing-library/jest-dom/vitest'
 
+class ResizeObserverStub implements ResizeObserver {
+  observe() {}
+
+  unobserve() {}
+
+  disconnect() {}
+}
+
+globalThis.ResizeObserver = ResizeObserverStub
+
 const storedValues = new Map<string, string>()
 
 Object.defineProperty(window, 'localStorage', {