Sprint: Stories en taken krijgen één voorspelbare volgorde gekoppeld aan hun code; drag-and-drop herordening voor stories/taken verdwijnt, priority wordt puur label. (#201)

* feat(code): add parseCodeNumber helper to lib/code.ts

Pure helper that extracts the trailing numeric sequence from a code string
(ST-007 → 7, T-42 → 42). Non-conforming codes fall back to Number.MAX_SAFE_INTEGER
so they sort to the end. Includes 5 unit tests.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* feat(tasks): add code field to BacklogTask type and all task selects

Adds `code: string | null` to BacklogTask interface and includes it in
all Prisma task.findMany selects (backlog API, stories tasks API, page
hydration routes). Updates coerceTaskPayload and test fixtures to match.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* feat(sort-order): derive story/task sort_order from parseCodeNumber(code)

All create paths (createStoryAction, saveTask, createTaskAction,
materializeIdeaPlanAction) and code-edit paths (updateStoryAction, saveTask
update) now set sort_order = parseCodeNumber(code) instead of last+1.
Removes stale last-record queries from create paths.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* fix(sort-order): decouple sprint membership actions from sort_order

createSprintAction and addStoryToSprintAction no longer write sort_order
when adding stories to a sprint. sort_order is derived from code via
parseCodeNumber, so membership should only set sprint_id + status.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* refactor(ordering): remove priority from all story/task orderBy

Story- en taak-ordering is nu puur sort_order asc (created_at als
tiebreaker). PBI-ordering (priority + sort_order) blijft ongewijzigd.

Gewijzigd: backlog/route, pbis/stories/route, claude-context/route,
next-story/route, workspace/route, tasks/route, sprint-runs (query +
in-memory sort), solo-workspace-server, page.tsx (app + mobile + sprint),
store compareStory, actions/sprints story-query, next-story test.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* refactor(dnd): remove drag-and-drop reorder for stories and tasks

- Remove reorderStoriesAction, reorderTasksAction, reorderSprintStoriesAction
- Delete REST route app/api/stories/[id]/tasks/reorder/route.ts
- Remove DnD from backlog story-panel and task-panel (flat list)
- Remove reorder-within-sprint branch from sprint-board-client handleDragEnd
- Switch SortableSprintRow to plain SprintRow using useDraggable (membership drag kept)
- Remove all DnD from task-list (status toggle + edit kept)
- Remove story-order/task-order/sprint-story-order/sprint-task-order mutation types and store handlers
- Remove related tests for deleted reorder route; fix sprint store tests

* feat(backlog): toon code-badge op backlog-taakkaarten

Geeft code={task.code} door aan <BacklogCard> in TaskCard (task-panel.tsx).
BacklogCard rendert de CodeBadge al conditionally — alleen de prop ontbrak.

* feat(migration): backfill story/task sort_order from code numeric suffix

One-time Prisma migration that sets sort_order = trailing numeric part
of code for all existing stories and tasks, consistent with
parseCodeNumber (fallback = Number.MAX_SAFE_INTEGER for non-conforming
codes). PBIs are intentionally excluded.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* docs+tests(sort-order): update for code-binding order on stories/tasks

- Rewrite docs/patterns/sort-order.md: float-insertion PBI only; story/task
  sort_order = parseCodeNumber(code), never drag/membership mutated
- Update plan-to-pbi-flow.md: sort_order auto, sprint_id param, priority=label
- Update make-plan.md: priority=label, array order = execution order
- Update rest-contract.md: fix sprint-tasks ordering, remove reorder endpoint
- Add ADR-0011: code is bindende volgordesleutel voor stories/taken
- Regenerate docs/INDEX.md via npm run docs
- Remove reorderStoriesAction/reorderTasksAction mocks from backlog tests
- Remove dnd-kit mocks from task-panel test (panel no longer uses dnd)
- Extend materializeIdeaPlanAction test: assert sort_order=parseCodeNumber(code)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

docs/INDEX.md

@@ -18,6 +18,7 @@ Auto-generated on 2026-05-14 from front-matter and headings.
 | 0007 | [ADR-0007: Agent ↔ user question channel via persistent table + LISTEN/NOTIFY](./adr/0007-claude-question-channel-design.md) | accepted |
 | 0008 | [ADR-0008: Agent instructions in CLAUDE.md + topical runbooks](./adr/0008-agent-instructions-in-claude-md.md) | accepted |
 | 0010 | [ADR-0010: Eén product = één repo; cross-product planning vereist (later) een Initiative-laag](./adr/0010-product-per-repo-cross-product-planning.md) | accepted |
+| 0011 | [ADR-0011: code is de bindende volgordesleutel voor stories en taken; priority is label](./adr/0011-code-volgordesleutel-stories-taken.md) | accepted |
 
 ## Specifications
 
@@ -74,7 +75,7 @@ Auto-generated on 2026-05-14 from front-matter and headings.
 | [Realtime NOTIFY payload — veldnaam-contract](./patterns/realtime-notify-payload.md) | active | 2026-05-03 |
 | [Route Handler (REST API)](./patterns/route-handler.md) | active | 2026-05-08 |
 | [Server Action](./patterns/server-action.md) | active | 2026-05-08 |
-| [Float sort_order (drag-and-drop volgorde)](./patterns/sort-order.md) | active | 2026-05-03 |
+| [sort_order — PBI drag-and-drop vs. code-bindende volgorde voor stories/taken](./patterns/sort-order.md) | active | 2026-05-14 |
 | [Story met UI-component](./patterns/story-with-ui-component.md) | active | 2026-05-03 |
 | [Web Push](./patterns/web-push.md) | active | 2026-05-07 |
 | [Workspace-store + realtime — bounded-context patroon](./patterns/workspace-store.md) | active | 2026-05-10 |

docs/adr/0011-code-volgordesleutel-stories-taken.md

@@ -0,0 +1,58 @@
+# ADR-0011: code is de bindende volgordesleutel voor stories en taken; priority is label
+
+## Status
+
+accepted
+
+## Context
+
+Vóór dit besluit werden stories en taken geordend op `[priority ASC, sort_order ASC]`.
+Gebruikers konden de volgorde via drag-and-drop aanpassen (float-insertion in `sort_order`).
+Dit leidde tot meerdere problemen:
+
+1. **Onvoorspelbare uitvoervolgorde voor de AI-agent**: een agent die taken aanmaakt via
+   `create_task` (in call-volgorde) zag die volgorde ongedaan gemaakt zodra een andere
+   agent of gebruiker de `priority` aanpaste.
+2. **Divergentie tussen `code` en `sort_order`**: `code` reflecteerde de aanmaak-volgorde
+   (`T-1`, `T-2`, …), maar `sort_order` kon na herordening compleet anders zijn.
+3. **DnD-reorder voor stories/taken was overbodig**: de enige betekenisvolle volgorde voor
+   een AI-gedreven sprint is de creatie-volgorde van taken — handmatige herordening voegde
+   verwarring toe zonder toegevoegde waarde.
+
+## Beslissing
+
+- **`code` is de bindende volgordesleutel** voor stories en taken.
+- **`sort_order` is een numerieke spiegel van `code`**, berekend via `parseCodeNumber(code)`
+  uit `lib/code.ts`. Hierbij extraheert `parseCodeNumber` het trailertal van de code-string
+  (bijv. `"ST-042"` → `42`, `"T-7"` → `7`).
+- **`sort_order` wordt automatisch gezet** bij `create` (server berekent de waarde) en bij
+  code-edit (PATCH met nieuw `code`). Sprint-membership-acties laten `sort_order` ongemoeid.
+- **Drag-and-drop herordening van stories en taken is verwijderd.** Enkel PBI-ordering
+  gebruikt nog float-insertion (zie ADR-0002).
+- **`priority` is een puur label** (urgentie-aanduiding voor de gebruiker). Geen enkele
+  `orderBy` op stories of taken gebruikt nog `priority`.
+
+## Gevolgen
+
+### Positief
+
+- De uitvoervolgorde van taken is deterministisch en gelijk aan de aanroep-volgorde van
+  `create_task` — agents kunnen dit betrouwbaar afleiden zonder extra queries.
+- `code` en `sort_order` zijn altijd in sync — geen divergentie meer na herordening.
+- Minder complexiteit: geen reorder-route, geen reorder-server-actions, geen DnD-context
+  in backlog-story-panel en task-panel.
+
+### Negatief
+
+- Gebruikers kunnen de volgorde van stories en taken niet handmatig herordenen via slepen.
+  Volgorde aanpassen vereist nu het wijzigen van de `code` (of het aanmaken in de gewenste
+  volgorde). Dit is een bewuste trade-off ten gunste van voorspelbaarheid voor de agent.
+- `parseCodeNumber` retourneert `0` voor codes zonder numeriek suffix (bijv. `"CUSTOM-FOO"`).
+  Zulke codes clusteren bij positie 0 — vermijdbaar door codes met een numeriek suffix te
+  gebruiken.
+
+## Zie ook
+
+- [ADR-0002: float sort_order voor drag-and-drop (PBI-ordering)](./0002-float-sort-order.md)
+- [docs/patterns/sort-order.md](../patterns/sort-order.md) — implementatiepatroon
+- `lib/code.ts` — `parseCodeNumber`-helper

docs/api/rest-contract.md

@@ -169,7 +169,7 @@ Hoogst geprioriteerde open story in de actieve sprint.
 
 ### `GET /api/sprints/:id/tasks`
 
-Lijst taken van de sprint, geordend op `(story.sort_order, task.priority, task.sort_order)`.
+Lijst taken van de sprint, geordend op `(story.sort_order, task.sort_order)` — code-volgorde, geen priority.
 
 **Query params:** `?limit=N` (default 10, max 50)
 
@@ -193,19 +193,6 @@ Lijst taken van de sprint, geordend op `(story.sort_order, task.priority, task.s
 
 ---
 
-### `PATCH /api/stories/:id/tasks/reorder`
-
-Volgorde van taken binnen een story aanpassen.
-
-**Body:**
-```json
-{ "task_ids": ["task-id-a", "task-id-b", "task-id-c"] }
-```
-
-Alle IDs moeten bij de story horen. **Foutcodes:** `422` bij Zod-fouten of als een task_id niet tot de story behoort.
-
----
-
 ### `PATCH /api/tasks/:id`
 
 Status of implementation_plan bijwerken. Minstens één van beide is verplicht.
@@ -537,7 +524,7 @@ worden. Tot dan retourneert de stub-default in vitest een lege response.
 |---|---|---|---|
 | `ensureProductLoaded(productId)` | `GET /api/products/:id/backlog` | **ontbreekt** | T-870 (Story 7) |
 | `ensurePbiLoaded(pbiId)` | `GET /api/pbis/:id/stories` | **ontbreekt** (en `/api/pbis` route-folder bestaat nog niet) | T-870 (Story 7) |
-| `ensureStoryLoaded(storyId)` | `GET /api/stories/:id/tasks` | **ontbreekt** (alleen `tasks/reorder` bestaat) | T-870 (Story 7) |
+| `ensureStoryLoaded(storyId)` | `GET /api/stories/:id/tasks` | **ontbreekt** | T-870 (Story 7) |
 | `ensureTaskLoaded(taskId)` | `GET /api/tasks/:id` | **ontbreekt** (alleen `PATCH` bestaat) | T-870 (Story 7) |
 
 Vereisten voor de toe te voegen routes:

docs/patterns/sort-order.md

@@ -1,15 +1,22 @@
 ---
-title: "Float sort_order (drag-and-drop volgorde)"
+title: "sort_order — PBI drag-and-drop vs. code-bindende volgorde voor stories/taken"
 status: active
 audience: [ai-agent, contributor]
 language: nl
-last_updated: 2026-05-03
-when_to_read: "When implementing drag-and-drop reordering or inserting between items."
+last_updated: 2026-05-14
+when_to_read: "When implementing ordering for PBIs (drag-and-drop) or stories/tasks (code-binding)."
 ---
 
-# Patroon: Float sort_order (drag-and-drop volgorde)
+# Patroon: sort_order — PBI vs. Story/Taak
 
-## Berekening bij tussenvoeging
+`sort_order` heeft voor PBI's een andere betekenis dan voor stories en taken.
+
+---
+
+## PBI — float-insertion (drag-and-drop)
+
+PBI's ondersteunen drag-and-drop herordening. `sort_order` is een `Float` die via de
+midpoint-formule wordt berekend bij tussenvoeging:
 
 ```ts
 function getSortOrder(before: number | null, after: number | null): number {
@@ -20,9 +27,9 @@ function getSortOrder(before: number | null, after: number | null): number {
 }
 ```
 
-## Herindexeer als precisie opraakt
+### Herindexeer als precisie opraakt
 
-Trigger wanneer het kleinste verschil tussen twee opeenvolgende items < 0.001 is.
+Trigger wanneer het kleinste verschil tussen twee opeenvolgende PBI's < 0.001 is:
 
 ```ts
 async function reindexIfNeeded(items: { id: string; sort_order: number }[]) {
@@ -37,12 +44,62 @@ async function reindexIfNeeded(items: { id: string; sort_order: number }[]) {
 }
 ```
 
-## Reorder Server Actions
+### Reorder Server Action (PBI-only)
 
-Een drag-and-drop reorder stuurt altijd client-controlled ID-lijsten naar de server. Behandel die lijst als onbetrouwbaar.
+Een drag-and-drop reorder stuurt client-controlled ID-lijsten naar de server.
+Behandel die lijst als onbetrouwbaar:
 
 - Weiger dubbele IDs.
-- Haal alle IDs op met de parent-scope, bijvoorbeeld `product_id`, `pbi_id`, `sprint_id` of `story_id`.
+- Haal alle IDs op met de parent-scope (`product_id`).
 - Weiger de operatie als het aantal gevonden records niet exact gelijk is aan het aantal aangeleverde IDs.
 - Update pas daarna `sort_order` in een transactie.
 - Gebruik bij priority changes dezelfde parent uit de database, niet een los meegegeven `productId`.
+
+---
+
+## Story / Taak — code-bindende volgorde (geen drag-and-drop)
+
+Voor stories en taken is `sort_order` een **numerieke spiegel van `code`**, berekend via
+`parseCodeNumber(code)` uit `lib/code.ts`. Drag-and-drop herordening bestaat niet voor
+stories en taken.
+
+### Wanneer `sort_order` wordt gezet
+
+| Moment | Wat er gebeurt |
+|---|---|
+| `story.create` / `task.create` | `sort_order = parseCodeNumber(code)` |
+| Idea-materialisatie (`materializeIdeaPlanAction`) | idem — stories en taken krijgen `sort_order = parseCodeNumber(storyCode / taskCode)` |
+| Code-edit (PATCH met nieuw `code`) | `sort_order = parseCodeNumber(newCode)` wordt bijgewerkt |
+| Sprint-membership-acties | `sort_order` wordt **niet** aangeraakt |
+
+### `parseCodeNumber`
+
+Extraheert het trailertal uit een code-string:
+
+```ts
+// lib/code.ts
+export function parseCodeNumber(code: string): number {
+  const match = code.match(/(\d+)$/)
+  return match ? parseInt(match[1], 10) : 0
+}
+```
+
+Voorbeelden: `"ST-042"` → `42`, `"T-7"` → `7`, `"CUSTOM-FOO"` → `0`.
+
+### Ordering queries
+
+Stories en taken worden **uitsluitend** op `sort_order` geordend — nooit op `priority`:
+
+```ts
+// stories binnen een sprint
+orderBy: [{ sort_order: 'asc' }]
+
+// taken binnen een story
+orderBy: { sort_order: 'asc' }
+
+// taken binnen een sprint (story-volgorde eerst)
+orderBy: [{ story: { sort_order: 'asc' } }, { sort_order: 'asc' }]
+```
+
+`priority` is een **label** (urgentie-aanduiding voor de gebruiker), geen
+sorteerkriteria voor stories of taken.

docs/runbooks/plan-to-pbi-flow.md

@@ -80,14 +80,15 @@ plan goedgekeurd
 ### 2. `create_story`
 
 ```
-{ pbi_id, title, description?, acceptance_criteria?, priority, sort_order? }
+{ pbi_id, sprint_id, title, description?, acceptance_criteria?, priority }
 ```
 
 - **`title`** — concreet, in user-story stijl als dat past ("Als developer wil ik …")
 - **`description`** — technische context, scope-grenzen, niet-doelen
 - **`acceptance_criteria`** — markdown checklist (`- [ ] …`); bepaalt wanneer de Story `DONE` is
 - `product_id` wordt afgeleid uit de PBI — niet meegeven
-- **Sprint-koppeling:** de story wordt aan de actieve OPEN-sprint gehangen (de zojuist aangemaakte). Als er meerdere OPEN-sprints bestaan: bevestig eerst met de gebruiker welke sprint geldt, of breidt `create_story` uit met een expliciete `sprint_id` parameter (apart PBI).
+- **`sprint_id`** — geef de zojuist aangemaakte sprint mee. Als er meerdere OPEN-sprints bestaan: bevestig eerst met de gebruiker welke sprint geldt.
+- **`sort_order`** — NIET meegeven. De server berekent `sort_order = parseCodeNumber(code)` automatisch. De volgorde van stories = de volgorde van hun codes (= aanroep-volgorde); niet priority.
 - Status start op `OPEN`
 
 > **Eén story per PBI** is de gebruikelijke verhouding. Splits alleen op in meerdere stories als het plan logisch in onafhankelijk-shipbare delen valt — let op dat dit dan ook meerdere sprints betekent.
@@ -95,17 +96,17 @@ plan goedgekeurd
 ### 3. `create_task` (één call per taak)
 
 ```
-{ story_id, title, description?, implementation_plan?, priority, sort_order? }
+{ story_id, title, description?, implementation_plan?, priority }
 ```
 
 - **`title`** — werkwoord-vorm: "Implementeer …", "Verplaats …", "Voeg test toe voor …"
 - **`description`** — wat de taak afdekt, in 1-3 zinnen
 - **`implementation_plan`** — **belangrijk**: markdown met de daadwerkelijke stappen + file-paths + reuse-pointers; dit is wat de Implementation-agent later inleest
-- **`sort_order`** — leeg laten voor de eerste call; daarna server-side `last + 1`, of expliciet meegeven om volgorde af te dwingen
+- **`sort_order`** — NIET meegeven. De server berekent `sort_order = parseCodeNumber(code)` automatisch. De uitvoervolgorde = de aanroep-volgorde (= code-volgorde); niet priority.
 - `sprint_id` wordt geërfd van de Story — niet meegeven
 - Status start op `TO_DO`
 
-> De gebruiker werkt taken af in **sort_order**. Zet voorbereidende taken (data-model, types) vóór UI-taken; tests komen ná de feature-implementatie tenzij TDD expliciet is afgesproken.
+> De uitvoervolgorde van taken is gelijk aan de **aanroep-volgorde** van `create_task` (= code-volgorde). `priority` is een label (urgentie), géén sorteerkriteria. Zet voorbereidende taken (data-model, types) vóór UI-taken; tests komen ná de feature-implementatie tenzij TDD expliciet is afgesproken.
 
 ---