janpeter/Scrum4Me
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Scrum4Me/docs/backlog/product-historical.md
Janpeter Visser 7e45bbdbc0
docs: AI-optimized docs restructure (Phases 1–8) (#61) 
* docs(dialog-pattern): add generic entity-dialog spec

Introduceert docs/patterns/dialog.md als bron-of-truth voor elke
create/edit/detail-dialog in Scrum4Me, ongeacht het achterliggende
dataobject. Bevat 14 secties: uitgangspunten, stack, component-
architectuur, layout, validatie, drielaagse demo-policy, submission,
dialog-gedrag, theming, footer, triggers/URL-state, per-entiteit
profile-template, out-of-scope, en een verificatie-checklist.

Registreert het patroon in CLAUDE.md "Implementatiepatronen"-tabel
zodat Claude (en mensen) de spec verplicht raadplegen voor elke
nieuwe dialog.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs(dialog-pattern): convert task spec + add pbi/story entity-profiles

Reduceert docs/scrum4me-task-dialog.md van 507 naar ~140 regels: alle
gedeelde regels verhuisd naar docs/patterns/dialog.md, dit document
bevat nu alleen Task-specifieke velden, URL-pattern, status-veld,
server actions, triggers en bewuste out-of-scope-keuzes.

Voegt twee nieuwe entity-profielen toe voor bestaande dialogen:
- docs/scrum4me-pbi-dialog.md (PbiDialog: state-based, code+title-rij,
  PbiStatusSelect, geen delete in v1)
- docs/scrum4me-story-dialog.md (StoryDialog: state-based, header met
  status/priority badges, inline activity-log, demo-readonly-fallback,
  inline-delete-confirm i.p.v. AlertDialog)

Beide profielen documenteren expliciet de "Bekende gaps t.o.v.
generieke spec" zodat opvolgende PR's de afwijkingen kunnen
rechtzetten of bewust kunnen accorderen.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Added pdevelopment docs

* docs(plans): add docs-restructure plan for AI-optimized lookup

Audit of existing 39 doc files (~10.700 lines) and a phased restructure
proposal aimed at minimising the tokens an AI agent has to read to find
the right reference. Captures resolved decisions on language (English),
ADR template (Nygard default with MADR escape-hatch), index generator
(node script), and folder taxonomy. Proposal status — fase 1 to follow.

* docs(adr): add ADR scaffolding (templates, README, meta-ADR)

Set up docs/adr/ as the canonical home for architecture decisions:

- templates/nygard.md — default four-section format (Status, Context,
  Decision, Consequences) for one-way-door decisions.
- templates/madr.md — MADR v4 with YAML front-matter and explicit
  Considered Options for decisions where rejected alternatives matter.
- README.md — naming convention (NNNN-kebab-case), template-selection
  guidance (Nygard default; MADR for auth, queue mechanics, agent
  integration), status lifecycle, and ADR roster.
- 0000-record-architecture-decisions.md — meta-ADR establishing the
  practice itself, in Nygard format.

Backfilling existing implicit decisions (base-ui-over-radix, float
sort_order, demo-user three-layer policy, etc.) is fase 6 of the
docs-restructure plan.

* feat(docs): add docs index generator + initial INDEX.md

scripts/generate-docs-index.mjs walks docs/**/*.md, parses YAML
front-matter (or first H1 fallback) and a Nygard-style ## Status
section, then writes docs/INDEX.md with grouped tables for ADRs,
Specs, Plans (with archive subsection), Patterns, and Other.

Pure Node 20 (no external deps); idempotent — running it twice
produces byte-identical output. Excludes adr/templates/, the ADR
README, INDEX.md itself, and any *_*.md sidecar file.

Wire-up:
- package.json: docs:index → node scripts/generate-docs-index.mjs

Initial run indexed 35 docs across the existing structure; the
generated INDEX.md is committed so the table is reviewable in the
PR before hooking generation into a pre-commit step.

* chore: ignore Obsidian vault and personal sidecar files

Add .obsidian/ (Obsidian vault config) and _*.md (personal sidecar
notes) to .gitignore so the docs/ tree can serve as canonical source
of truth while still being usable as an Obsidian vault for personal
authoring. The docs index generator already excludes the same _*.md
pattern from INDEX.md.

* docs(plans): add PBI bulk-create spec for docs-restructure

Machine-parseable spec for an executor that calls the scrum4me MCP
(create_pbi → create_story → create_task) to seed the docs-restructure
work into the DB.

- Section 1 (Context) is the PBI description; serves as task-context
  via mcp__scrum4me__get_claude_context.
- Section 2 lists the 6 resolved decisions (English, MD3+styling
  merged, solo-paneel merged, .Plans archived, Nygard ADR default,
  node index script).
- Section 3 records what already shipped on this branch so the
  executor doesn't duplicate the ADR scaffolding or index generator.
- Section 4 carries the structured YAML graph: 1 PBI, 8 stories
  (one per phase), 39 tasks. product_id is REPLACE_ME — fill before
  running.
- YAML validated with PyYAML; field schema sanity-checked.

* docs(junk-cleanup): remove stub patterns/test.md

* docs(junk-cleanup): archive .Plans/ to docs/plans/archive/

* docs(front-matter): add YAML front-matter to docs/ root

* docs(front-matter): add YAML front-matter to patterns/

* docs(front-matter): add YAML front-matter to plans + agent files

* docs(index): regenerate INDEX.md after front-matter pass

* docs(naming): drop scrum4me- prefix from doc filenames

* docs(naming): lowercase API.md and MD3 filenames

* docs(naming): rename plan file to kebab-case ASCII

* docs(naming): rename middleware.md to proxy.md (next 16)

* docs(naming): polish CLAUDE.md doc-index after renames

* docs(taxonomy): scaffold topical folders under docs/

* docs(taxonomy): move spec files into docs/specs/

* docs(taxonomy): move design/api/qa/backlog/assets into folders

* docs(taxonomy): move agent-instruction-audit into decisions/

* docs(split): break architecture.md into 6 topical files

* docs(split): merge solo-paneel-spec into specs/functional.md

* docs(split): merge md3-color-scheme into design/styling

* docs(trim): extract branch/commit rules into runbook

* docs(trim): extract MCP integration into runbook

* docs(adr): add 0001-base-ui-over-radix

* docs(adr): add 0002-float-sort-order

* docs(adr): add 0003-one-branch-per-milestone

* docs(adr): add 0004-status-enum-mapping

* docs(adr): add 0005-iron-session-over-nextauth

* docs(adr): add 0006-demo-user-three-layer-policy

* docs(adr): add 0007-claude-question-channel-design

* docs(adr): add 0008-agent-instructions-in-claude-md + update README index

* docs(index): regenerate after ADR 0001-0008

* docs(glossary): add docs/glossary.md

* chore(docs): regenerate INDEX.md in pre-commit hook

* docs(readme): link INDEX + glossary + agent instructions

* feat(docs): add doc-link checker script

* chore(docs): wire docs:check-links and docs npm scripts

* ci(docs): block merge on broken doc links

* docs(links): fix broken cross-references after restructure

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-03 03:21:59 +02:00

462 lines
21 KiB
Markdown
Raw Blame History

---
title: "DevPlanner — Product Backlog"
status: active
audience: [maintainer]
language: nl
last_updated: 2026-05-03
---
# DevPlanner — Product Backlog
**Versie:** 0.1 — april 2026
**Product:** DevPlanner
**Beschrijving:** Een lichtgewicht Scrum-gebaseerde projectplanner voor solo developers en kleine Scrum Teams die meerdere softwareprojecten parallel beheren. De app organiseert werk hiërarchisch (product → PBI → story → taak), biedt een visuele planningslaag en integreert met Claude Code voor geautomatiseerde implementatieflows.
**Git repo:** https://github.com/devplanner/devplanner
**Definition of Done:** Feature is geïmplementeerd, getest (unit + integratie), gedocumenteerd in code, en gedeployed naar de staging-omgeving zonder regressies.
---
## Prioriteiten
| Prioriteit | Betekenis |
|---|---|
| 1 — Kritiek | Blokkeert alle andere functionaliteit. Moet eerst. |
| 2 — Hoog | Core waarde van het product. MVP vereiste. |
| 3 — Middel | Verhoogt bruikbaarheid significant. v1 wenselijk. |
| 4 — Laag | Waardevol maar niet blokkerend. v2 kandidaat. |
---
## PBI-01 — Authenticatie & gebruikersbeheer
**Prioriteit:** 1 — Kritiek
**Omschrijving:** Het Scrum Team kan een account aanmaken en inloggen met gebruikersnaam en wachtwoord. Een demo-gebruiker heeft alleen leesrechten. Gebruikers kunnen één of meerdere Scrum-rollen aannemen.
### Stories
**S-01-01: Account aanmaken**
Als bezoeker wil ik een account aanmaken met gebruikersnaam en wachtwoord, zodat ik toegang krijg tot de app.
Acceptatiecriteria:
- Gebruikersnaam en wachtwoord zijn verplicht
- Gebruikersnaam is uniek; dubbele aanmelding geeft foutmelding
- Wachtwoord heeft minimaal 8 tekens
- Na aanmaken wordt de gebruiker direct ingelogd
- Geen e-mailverificatie vereist in v1
**S-01-02: Inloggen**
Als geregistreerde gebruiker wil ik inloggen met gebruikersnaam en wachtwoord, zodat ik mijn projecten kan beheren.
Acceptatiecriteria:
- Incorrecte combinatie geeft generieke foutmelding (geen onderscheid gebruikersnaam/wachtwoord)
- Na inloggen wordt de gebruiker doorgestuurd naar het dashboard
- Sessie blijft actief totdat de gebruiker uitlogt
**S-01-03: Uitloggen**
Als ingelogde gebruiker wil ik kunnen uitloggen, zodat mijn sessie veilig afgesloten wordt.
Acceptatiecriteria:
- Uitlogknop altijd zichtbaar in de navigatie
- Na uitloggen wordt de gebruiker naar de loginpagina gestuurd
- Sessiedata wordt gewist
**S-01-04: Demo-gebruiker (read-only)**
Als bezoeker wil ik kunnen inloggen als demo-gebruiker, zodat ik de app kan verkennen zonder een account aan te maken.
Acceptatiecriteria:
- Vaste inloggegevens voor de demo-gebruiker zijn beschikbaar op de loginpagina
- Demo-gebruiker ziet alle data maar kan niets aanmaken, aanpassen of verwijderen
- Alle actieknoppen (aanmaken, bewerken, verwijderen) zijn zichtbaar maar uitgeschakeld met tooltip "Niet beschikbaar in demo-modus"
- Demo-gebruiker kan niet van rol wisselen
**S-01-05: Roltoewijzing**
Als gebruiker wil ik één of meerdere Scrum-rollen kunnen aannemen (Product Owner, Scrum Master, Developer), zodat de app weet in welke context ik werk.
Acceptatiecriteria:
- Gebruiker kan bij registratie of in instellingen rollen selecteren
- Minimaal één rol is verplicht
- Alle drie de rollen tegelijk zijn toegestaan
- Rolkeuze is zichtbaar in de navigatie/profielbalk
- Rolkeuze heeft in v1 geen effect op zichtbare functionaliteit (voorbereiding op v2)
---
## PBI-02 — Productbeheer
**Prioriteit:** 1 — Kritiek
**Omschrijving:** Het Scrum Team kan producten aanmaken, bekijken, bewerken en archiveren. Een product heeft een naam, beschrijving en koppeling naar een git-repository.
### Stories
**S-02-01: Product aanmaken**
Als Product Owner wil ik een nieuw product aanmaken met naam, beschrijving en git-repo URL, zodat ik een werkruimte heb voor de Product Backlog.
Acceptatiecriteria:
- Naam is verplicht en uniek per gebruiker
- Beschrijving is optioneel (vrije tekst)
- Git-repo URL is optioneel maar wordt gevalideerd als geldige URL
- Product is direct zichtbaar in de productenlijst na aanmaken
**S-02-02: Product bewerken**
Als Product Owner wil ik de naam, beschrijving en git-repo URL van een product kunnen aanpassen, zodat de informatie actueel blijft.
Acceptatiecriteria:
- Alle velden zijn bewerkbaar
- Wijzigingen worden opgeslagen zonder de pagina te verlaten
- Lege naam geeft validatiefout
**S-02-03: Product archiveren**
Als Product Owner wil ik een product kunnen archiveren, zodat het niet meer in het overzicht verschijnt maar de data bewaard blijft.
Acceptatiecriteria:
- Gearchiveerde producten verschijnen niet in de standaardlijst
- Er is een optie om gearchiveerde producten te tonen
- Archiveren is omkeerbaar (product kan worden hersteld)
**S-02-04: Productenlijst bekijken**
Als gebruiker wil ik een overzicht zien van alle actieve producten, zodat ik snel naar het juiste product kan navigeren.
Acceptatiecriteria:
- Lijst toont naam, beschrijving (ingekort) en git-repo link
- Klikken op een product opent de Product Backlog van dat product
- Lege staat toont een prompt om een product aan te maken
---
## PBI-03 — Product Backlog
**Prioriteit:** 1 — Kritiek
**Omschrijving:** Het Scrum Team kan de Product Backlog beheren via een gesplitst scherm: links de PBI's, rechts de bijbehorende stories. Items kunnen aangemaakt, bewerkt, geprioriteerd en gerangschikt worden via drag-and-drop (dnd-kit).
### Stories
**S-03-01: PBI aanmaken**
Als Product Owner wil ik een PBI aanmaken in de Product Backlog, zodat ik nieuwe functionaliteit kan definiëren.
Acceptatiecriteria:
- PBI heeft een titel (verplicht) en omschrijving (optioneel)
- PBI krijgt een prioriteit (1 t/m 4)
- Nieuw PBI verschijnt onderaan de lijst voor de gekozen prioriteit
- Aanmaken via knop in de navigatiebar van het linkerpaneel
**S-03-02: PBI bewerken**
Als Product Owner wil ik de titel, omschrijving en prioriteit van een PBI kunnen aanpassen.
Acceptatiecriteria:
- Dubbelklikken of via contextmenu opent bewerkingsmodus
- Alle velden zijn inline bewerkbaar
- Prioriteitswijziging herplaatst het PBI visueel
**S-03-03: PBI verwijderen**
Als Product Owner wil ik een PBI kunnen verwijderen, zodat irrelevante items de backlog niet vervuilen.
Acceptatiecriteria:
- Verwijderen vereist bevestiging
- Verwijderen van een PBI verwijdert ook alle bijbehorende stories (cascade)
- Actie is niet ongedaan te maken; bevestigingsdialoog waarschuwt hiervoor
**S-03-04: PBI prioriteit instellen**
Als Product Owner wil ik per PBI een prioriteit kunnen instellen (1 t/m 4), zodat de volgorde van de backlog de businesswaarde weerspiegelt.
Acceptatiecriteria:
- Prioriteit is instelbaar via dropdown of inline label
- PBI's worden gegroepeerd per prioriteit in de lijst
- Visuele scheiding per prioriteitsgroep (kleurband of scheidingslijn)
**S-03-05: PBI volgorde aanpassen via drag-and-drop**
Als Product Owner wil ik de volgorde van PBI's binnen dezelfde prioriteit kunnen aanpassen via drag-and-drop, zodat ik fijnmazige prioritering kan doen.
Acceptatiecriteria:
- Drag-and-drop werkt vloeiend (60fps) via dnd-kit
- Volgorde wordt direct opgeslagen na loslaten
- Drag over prioriteitsgrens wisselt de prioriteit van het PBI
- Visuele placeholder toont de doelpositie tijdens het slepen
**S-03-06: PBI filteren**
Als gebruiker wil ik PBI's kunnen filteren op prioriteit of status, zodat ik me kan focussen op het relevante werk.
Acceptatiecriteria:
- Filteropties beschikbaar in de navigatiebar van het linkerpaneel
- Filter werkt realtime (geen herlaadactie)
- Actief filter is duidelijk zichtbaar; eenvoudig te wissen
**S-03-07: Gesplitst scherm Product Backlog**
Als gebruiker wil ik de Product Backlog bekijken als gesplitst scherm (PBI's links, stories rechts), zodat ik snel kan navigeren tussen PBI's en hun stories.
Acceptatiecriteria:
- Scherm is standaard 50/50 verdeeld
- De splitter is horizontaal versleepbaar
- Elk paneel heeft een eigen navigatiebar met acties
- Selecteren van een PBI links toont de bijbehorende stories rechts
- Geselecteerde PBI is visueel gemarkeerd
---
## PBI-04 — Story-beheer
**Prioriteit:** 1 — Kritiek
**Omschrijving:** Stories kunnen worden aangemaakt, bewerkt, geprioriteerd en gerangschikt binnen een PBI. Stories worden weergegeven als blokken van circa 10% schermbreedte, gerangschikt op prioriteit.
### Stories
**S-04-01: Story aanmaken**
Als Product Owner wil ik een story aanmaken binnen een PBI, zodat ik de functionaliteit kan uitwerken in uitvoerbare eenheden.
Acceptatiecriteria:
- Story heeft een titel (verplicht), omschrijving (optioneel) en prioriteit
- Aanmaken via navigatiebar van het rechterpaneel
- Nieuwe story verschijnt als blok rechts, in de juiste prioriteitsgroep
**S-04-02: Story weergave als blokken**
Als gebruiker wil ik stories zien als compacte blokken (~10% schermbreedte), zodat ik snel een overzicht heb van alle stories per PBI.
Acceptatiecriteria:
- Elk blok toont: storytitel, prioriteit, status
- Blokken zijn gerangschikt op prioriteit (hoog naar laag, links naar rechts)
- Elke nieuwe prioriteitsgroep heeft een visuele scheiding (kleurband of lijn)
- Blokken zijn klikbaar voor detail/bewerking
**S-04-03: Story prioriteit instellen**
Als Product Owner wil ik per story een prioriteit instellen, zodat de Developer weet wat als eerste opgepakt moet worden.
Acceptatiecriteria:
- Prioriteit instelbaar via het storyblok (dropdown of label)
- Prioriteitswijziging herplaatst het blok in de juiste groep
**S-04-04: Story volgorde aanpassen via drag-and-drop**
Als Product Owner wil ik de volgorde van stories binnen dezelfde prioriteit aanpassen via drag-and-drop, zodat ik de uitvoeringsvolgorde kan finetunen.
Acceptatiecriteria:
- Drag-and-drop werkt via dnd-kit tussen en binnen prioriteitsgroepen
- Volgorde wordt direct opgeslagen
- Slepen over een prioriteitsgrens wijzigt de prioriteit
**S-04-05: Story bewerken**
Als Product Owner wil ik de titel, omschrijving en prioriteit van een story kunnen aanpassen.
Acceptatiecriteria:
- Bewerkbaar via klikken op het storyblok
- Wijzigingen opgeslagen zonder paginaverversing
**S-04-06: Story verwijderen**
Als Product Owner wil ik een story kunnen verwijderen.
Acceptatiecriteria:
- Verwijderen vereist bevestiging
- Cascade verwijdering van gekoppelde taken
- Niet ongedaan te maken; waarschuwing in dialoog
---
## PBI-05 — Todo-lijst
**Prioriteit:** 2 — Hoog
**Omschrijving:** Gebruikers kunnen een snelle todo-lijst bijhouden voor ongeplande of kortstondige taken. Een todo-item kan worden gepromoveerd naar een PBI of story.
### Stories
**S-05-01: Todo-item aanmaken**
Als gebruiker wil ik snel een todo-item aanmaken zonder het aan een product te koppelen, zodat ik losse gedachten kan vastleggen zonder de planningsflow te onderbreken.
Acceptatiecriteria:
- Todo heeft alleen een titel (verplicht)
- Aanmaken via een snel-invoerveld (Enter om op te slaan)
- Todo's zijn zichtbaar in een aparte todo-sectie of zijpaneel
**S-05-02: Todo-item afvinken**
Als gebruiker wil ik een todo-item kunnen afvinken, zodat ik bij kan houden wat klaar is.
Acceptatiecriteria:
- Afgevinkte items zijn visueel doorgestreept
- Afgevinkte items blijven zichtbaar maar kunnen worden gearchiveerd
**S-05-03: Todo promoveren naar PBI**
Als Product Owner wil ik een todo-item promoveren naar een PBI in een bestaand product, zodat losse ideeën in de formele backlog terechtkomen.
Acceptatiecriteria:
- Promoten opent een dialoog om product en prioriteit te kiezen
- Het todo-item wordt omgezet naar een PBI en verdwijnt uit de todo-lijst
- De PBI-titel is gelijk aan de todo-titel (bewerkbaar in dialoog)
**S-05-04: Todo promoveren naar story**
Als Product Owner wil ik een todo-item promoveren naar een story binnen een bestaand PBI, zodat ik snel nieuwe stories kan toevoegen vanuit losse notities.
Acceptatiecriteria:
- Promoten opent een dialoog om product, PBI en prioriteit te kiezen
- Todo wordt omgezet naar een story en verdwijnt uit de todo-lijst
---
## PBI-06 — Sprint Backlog & Sprint Planning
**Prioriteit:** 2 — Hoog
**Omschrijving:** Het Scrum Team kan een Sprint aanmaken met een Sprint Goal, stories uit de Product Backlog naar de Sprint Backlog slepen, en de volgorde bepalen.
### Stories
**S-06-01: Sprint aanmaken**
Als Scrum Master wil ik een nieuwe Sprint aanmaken met een Sprint Goal, zodat het Scrum Team een duidelijk doel heeft voor de komende Sprint.
Acceptatiecriteria:
- Sprint heeft een Sprint Goal (verplicht, vrije tekst)
- Sprint is gekoppeld aan een product
- Er kan maar één actieve Sprint per product zijn
**S-06-02: Sprint Backlog scherm (gesplitst)**
Als gebruiker wil ik de Sprint Backlog kunnen beheren via een gesplitst scherm (Sprint Backlog links, stories per PBI rechts), zodat ik snel stories kan toevoegen aan de Sprint.
Acceptatiecriteria:
- Links: Sprint Backlog met geselecteerde stories in volgorde
- Rechts: stories uit de Product Backlog, gegroepeerd per PBI
- Splitter is horizontaal versleepbaar
- Elk paneel heeft eigen navigatiebar
**S-06-03: Story naar Sprint slepen**
Als Developer wil ik een story vanuit de Product Backlog naar de Sprint Backlog kunnen slepen, zodat ik bepaal wat we deze Sprint gaan oppakken.
Acceptatiecriteria:
- Drag-and-drop werkt via dnd-kit tussen rechterpaneel en linkerpaneel
- Story verschijnt in de Sprint Backlog op de gesleepte positie
- Story in de Product Backlog krijgt visuele markering "In Sprint"
- Een story kan maar aan één actieve Sprint gekoppeld zijn
**S-06-04: Volgorde stories in Sprint bepalen**
Als Developer wil ik de volgorde van stories in de Sprint Backlog kunnen aanpassen via drag-and-drop, zodat ik de uitvoeringsvolgorde bepaal.
Acceptatiecriteria:
- Drag-and-drop werkt binnen de Sprint Backlog
- Volgorde wordt direct opgeslagen
- Volgorde is onafhankelijk van de prioriteit in de Product Backlog
**S-06-05: Story uit Sprint verwijderen**
Als Developer wil ik een story uit de Sprint Backlog kunnen verwijderen (terugplaatsen in de Product Backlog), zodat we de Sprint scope kunnen aanpassen.
Acceptatiecriteria:
- Story verdwijnt uit de Sprint Backlog
- Story is weer beschikbaar in de Product Backlog
- Actie vereist geen bevestiging (is niet destructief)
---
## PBI-07 — Sprint Planning (taken per story)
**Prioriteit:** 2 — Hoog
**Omschrijving:** Tijdens Sprint Planning worden stories opgedeeld in taken. Hetzelfde gesplitste scherm wordt gebruikt: stories links, taken rechts. Taken kunnen geprioriteerd en gerangschikt worden.
### Stories
**S-07-01: Sprint Planning scherm**
Als Developer wil ik een Sprint Planning scherm zien met stories links en taken rechts, zodat ik per story taken kan aanmaken en rangschikken.
Acceptatiecriteria:
- Links: stories in de Sprint Backlog in volgorde
- Rechts: taken van de geselecteerde story
- Selecteren van een story links toont de bijbehorende taken rechts
- Gesplitst scherm is horizontaal versleepbaar
**S-07-02: Taak aanmaken**
Als Developer wil ik een taak aanmaken onder een story, zodat ik het uitvoerbare werk kan definiëren.
Acceptatiecriteria:
- Taak heeft een titel (verplicht), omschrijving (optioneel) en prioriteit
- Aanmaken via navigatiebar van het rechterpaneel
- Nieuwe taak verschijnt onderaan de takenlijst van de story
**S-07-03: Taak prioriteit instellen**
Als Developer wil ik per taak een prioriteit instellen, zodat de uitvoeringsvolgorde duidelijk is.
Acceptatiecriteria:
- Prioriteit instelbaar via taakregel (dropdown of label)
- Taken gegroepeerd en gerangschikt op prioriteit
**S-07-04: Taak volgorde aanpassen via drag-and-drop**
Als Developer wil ik de volgorde van taken binnen een story kunnen aanpassen via drag-and-drop, zodat de uitvoeringsvolgorde precies klopt.
Acceptatiecriteria:
- Drag-and-drop via dnd-kit binnen de takenlijst
- Volgorde direct opgeslagen na loslaten
**S-07-05: Taakstatus bijhouden**
Als Developer wil ik de status van een taak kunnen bijhouden (To Do, In Progress, Done), zodat de voortgang van de Sprint zichtbaar is.
Acceptatiecriteria:
- Status is instelbaar via de UI (dropdown of knoppen)
- Statuswijziging is direct zichtbaar in het Sprint Planning scherm
- Story toont een voortgangsindicator op basis van taakstatussen
---
## PBI-08 — Claude Code integratie
**Prioriteit:** 2 — Hoog
**Omschrijving:** Claude Code kan via een REST API (en later MCP) stories en taken ophalen, de volgorde beoordelen, een implementatieplan opstellen, tests uitvoeren en committen. Elk resultaat wordt vastgelegd in de story.
### Stories
**S-08-01: REST API — story ophalen**
Als Developer (via Claude Code) wil ik de hoogst geprioriteerde open story van een product kunnen ophalen via een API-endpoint, zodat Claude Code weet wat er gedaan moet worden.
Acceptatiecriteria:
- Endpoint: `GET /api/products/:id/next-story`
- Retourneert: story-id, titel, omschrijving, acceptatiecriteria, gekoppelde taken
- Authentiseerd via API-token
- Geeft 404 als er geen open stories zijn
**S-08-02: REST API — eerste 10 taken ophalen**
Als Developer (via Claude Code) wil ik de eerste 10 taken van de Sprint Backlog kunnen ophalen, zodat Claude Code de volgorde kan beoordelen en zo nodig aanpassen.
Acceptatiecriteria:
- Endpoint: `GET /api/sprints/:id/tasks?limit=10`
- Retourneert taken in huidige volgorde met id, titel, prioriteit, status
- Claude Code kan de volgorde aanpassen via een apart endpoint
**S-08-03: REST API — taakvolgorde aanpassen**
Als Developer (via Claude Code) wil ik de volgorde van taken kunnen aanpassen via de API, zodat Claude Code een optimale uitvoeringsvolgorde kan bepalen.
Acceptatiecriteria:
- Endpoint: `PATCH /api/stories/:id/tasks/reorder`
- Accepteert een geordende lijst van taak-id's
- Volgorde wordt direct weerspiegeld in de UI
**S-08-04: Implementatieplan vastleggen**
Als Developer (via Claude Code) wil ik een implementatieplan kunnen schrijven naar een story, zodat de ontwerpbeslissingen traceerbaar zijn.
Acceptatiecriteria:
- Endpoint: `POST /api/stories/:id/log`
- Veld: `type: "implementation_plan"`, `content: string`
- Log-entry verschijnt in de story-activiteitenlog in de UI
**S-08-05: Teststatus vastleggen**
Als Developer (via Claude Code) wil ik de uitkomst van testruns kunnen vastleggen in een story, zodat kwaliteitsbewijs per story bewaard blijft.
Acceptatiecriteria:
- Endpoint: `POST /api/stories/:id/log`
- Veld: `type: "test_result"`, `content: string`, `status: "passed" | "failed"`
- Teststatus zichtbaar in de story-activiteitenlog
**S-08-06: Commit-hash vastleggen**
Als Developer (via Claude Code) wil ik de commit-hash na een succesvolle commit kunnen vastleggen in een story, zodat code en planning direct gekoppeld zijn.
Acceptatiecriteria:
- Endpoint: `POST /api/stories/:id/log`
- Veld: `type: "commit"`, `hash: string`, `message: string`
- Commit-hash is klikbaar en linkt naar de git-repo (indien geconfigureerd)
**S-08-07: Story activiteitenlog in UI**
Als gebruiker wil ik per story een activiteitenlog zien met alle vastgelegde implementatieplannen, testresultaten en commits, zodat ik de volledige uitvoeringsgeschiedenis op één plek heb.
Acceptatiecriteria:
- Log toont alle entries in chronologische volgorde
- Elk type entry heeft een eigen visuele stijl (plan, test, commit)
- Log is zichtbaar in de story-detailweergave
- Log is read-only in de UI (schrijven gebeurt via API)
---
## PBI-09 — Infrastructuur & deployment
**Prioriteit:** 1 — Kritiek
**Omschrijving:** De app is deployable op Vercel + Neon (cloud) én volledig lokaal draaibaar zonder externe afhankelijkheden.
### Stories
**S-09-01: Cloud deployment (Vercel + Neon)**
Als Developer wil ik de app deployen op Vercel met een Neon PostgreSQL-database, zodat de app beschikbaar is via een URL.
Acceptatiecriteria:
- `next build` slaagt zonder fouten
- Database-migraties worden uitgevoerd via Prisma
- Environment variables zijn gedocumenteerd in `.env.example`
**S-09-02: Lokale modus**
Als Developer wil ik de app lokaal kunnen draaien met een Neon PostgreSQL-database, zodat de lokale setup overeenkomt met productie.
Acceptatiecriteria:
- `npm run dev` start de app lokaal zonder Vercel of Neon account
- Database wordt aangemaakt via `prisma db push`
- README bevat stap-voor-stap instructies voor lokale setup
**S-09-03: API-token authenticatie**
Als Developer wil ik een API-token kunnen genereren in de app, zodat Claude Code veilig kan communiceren met de REST API.
Acceptatiecriteria:
- Gebruiker kan een API-token aanmaken in de instellingenpagina
- Token wordt eenmalig getoond en daarna niet meer zichtbaar
- Token kan worden ingetrokken
- Alle API-endpoints vereisen een geldig token via `Authorization: Bearer`
---
## Backlog — v2 kandidaten (niet in v1)
| PBI | Omschrijving |
|---|---|
| Daily Scrum scherm | Voortgang per story bijhouden tijdens de Sprint |
| Sprint Review scherm | Demo en feedback vastleggen per story |
| Sprint Retrospective scherm | Reflectie vastleggen per Sprint |
| Meerdere gebruikers per Scrum Team | Uitgebreide auth met rol-gebaseerde permissies |
| Automatische statusupdate na commit | Story op Done zetten via API-aanroep |
| Velocity tracking | Statistieken over meerdere Sprints |
| Notificaties / reminders | Push of e-mailmeldingen |
| Timeline / kalenderweergave | Sprint-planning op kalender |
| Definition of Done per product configureerbaar | Nu vaste instelling; later flexibel |
| Integratie GitHub Issues / Linear | Import/export van PBI's en stories |
---
*Dit document dient als testdata voor de eerste implementatie van de datastructuur.*
*Versie 0.1 — te updaten na Sprint 1 Review.*
Reference in a new issue View git blame Copy permalink