feat: add task drag and drop
This commit is contained in:
Urban Modig
545
docs/features/006-task-drag-and-drop.md
Normal file
545
docs/features/006-task-drag-and-drop.md
Normal file
@ -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.
|
||||
Reference in New Issue
Block a user