Van idee tot productie: de reis van een issue

Een issue doorloopt 6 stages — van een ruw idee tot draaiende feature in productie. Elke stage heeft een duidelijke eigenaar en een Spexso command dat de overgang regelt.

De 6 stages

Stage	Wie	Wat gebeurt er	Spexso command
opportunity	Sales / functioneel	Ruw idee of klantverzoek wordt vastgelegd	/spexso-report
spec	Functioneel + tech lead	Idee wordt uitgewerkt tot volledige spec	/spexso-brainstorm
spec → build	Developer	Technisch plan wordt gemaakt, worktree opgezet	/spexso-start + /spexso-plan
build	Developer (+ AI)	TDD implementatie per taak	/spexso-build
review	AI + developer	Code review, auto-fix critical/high	/spexso-review
ship + needs::manual-test	Developer	MR automatisch gemerged, test checklist gepost	/spexso-finish
operate	Team	Live in productie, bugs worden nieuwe issues	—

Voorbeeld: van vage melding tot shipped feature

1. Een functioneel consultant meldt een probleem

De consultant zit bij een klant en hoort: "Als een medewerker van afdeling wisselt, crasht de verlofaanvraag."

/spexso-report De verlofaanvraag crasht met een 500 error als een medewerker
van afdeling is gewisseld. De manager ziet een witte pagina bij goedkeuren.

Claude analyseert de beschrijving, classificeert het als type::bug, schat size::s, en maakt een GitLab issue aan met gestructureerde bug-template. De issue krijgt label stage::opportunity.

2. De spec wordt verfijnd

De tech lead of een developer pakt de issue op en verfijnt de beschrijving met het issue ID:

/spexso-brainstorm 51

Claude stelt vragen: Welke API endpoint? Welke foutmelding exact? Welk BTP subaccount? Na 5-8 vragen genereert Claude een volledige spec met acceptance criteria, edge cases, en data model context. De issue gaat naar stage::spec.

3. Een developer pakt het op

/spexso-start 51

Spexso checkt of de issue in stage::spec staat en niet al door iemand anders geclaimd is, maakt een worktree aan (spexso/issue-51), en vraagt welke mode: yolo, pilot, of copilot.

De developer kiest pilot. De planner subagent leest de spec en maakt een takenlijst:

• Taak 1: Fix null check op afdeling lookup
• Taak 2: Voeg error handling toe voor API call
• Taak 3: Voeg test toe voor afdelingswisseling scenario

Developer keurt het plan goed.

4. TDD implementatie

/spexso-build

Per taak:

1. Tester subagent schrijft falende tests (RED)
2. Builder subagent schrijft minimale code om tests te laten slagen (GREEN)
3. Commit na elke taak

In pilot mode ziet de developer na elke taak het resultaat en keurt goed.

5. Code review

/spexso-review

De reviewer subagent checkt alle wijzigingen:

• Critical/high issues → automatisch gefixt
• Low issues → alleen commentaar

Review rapport wordt gepost op de GitLab issue.

6. Ship it

/spexso-finish

Spexso:

1. Draait de volledige test suite (gate)
2. Ververst de debt ledger (.spexso/debt.md) op basis van // spexso-debt: markers en commit die op de feature branch
3. Pusht de branch
4. Maakt een Merge Request aan (target: geconfigureerde targetBranch)
5. Merget de MR automatisch (squash) — bij conflict: rebase + retry
6. Update de issue naar stage::ship + needs::manual-test
7. Post een ✅ test checklist op het issue (gebaseerd op de acceptance criteria)
8. Post de ## Demo sectie uit de spec als comment op het issue (indien aanwezig)
9. Archiveert de spec naar specs/{id}-{titel}.md, zodat de spec blijft bestaan ook na sluiten van het issue
10. Schrijft een learning card naar docs/learning/ — een korte Socratische recap voor de developer
11. Ruimt de worktree op
12. Update de CHANGELOG

De developer opent het issue in GitLab, voert de test checklist uit, en verwijdert het needs::manual-test label wanneer alles werkt. Is er een test-hand-off ingesteld, dan blijft het issue open en doet een tester dit op DEV.

7. Live in productie

Na merge draait CI/CD: build → deploy naar DEV. Naar TST/PRD gaat het per release: de manuele prepare-release-job tagt main, en de tag-pipeline deployt automatisch naar TST en na een manuele gate naar PRD — zie CI/CD design. De issue gaat naar stage::operate.

Als er een nieuw probleem opduikt, begint de cyclus opnieuw bij stap 1.

Doorlooptijd

Een size::s bug gaat typisch in 1-2 dagen van report tot productie. Een size::m feature in 3-5 dagen. Het meeste tijdverlies zit niet in de implementatie, maar in het wachten tussen stages — daarom is async-first zo belangrijk.

Geen spec = geen code

Issues die alleen een titel hebben en geen spec komen nooit voorbij stage::opportunity. De planner weigert een plan te maken zonder acceptance criteria. Dit is by design — het dwingt kwaliteit af aan de voorkant.