* docs(ST-1101..1108): add M11 — Claude question-channel milestone to backlog
Plant acht stories ST-1101..ST-1108 voor het persistente vraag-antwoord-kanaal
tussen Claude (MCP) en de actieve gebruiker. Eerste concrete uitwerking van
de AI-driven dev-flow-richting (strategisch besluit "B" uit overleg na M10).
Beveiligingsuitgangspunt: atomic answer via updateMany WHERE status='open',
demo-blok op write-tools, access-check via productAccessFilter in DB-query én
SSE-filter, cron-endpoint via Bearer-secret, geen vraag/antwoord-tekst in logs.
Hergebruikt bestaande scrum4me_changes-channel (uitgebreid met entity:'question')
en het LISTEN/NOTIFY+ReadableStream-pattern uit M8/M10. Nieuw: user-scoped SSE
op /api/realtime/notifications zodat de bell globaal werkt over producten heen.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* chore(M11): swap demo-active sprint from M10 to M11
M10 is gemerged en afgesloten — M11 wordt de nieuwe demo-actieve milestone
zodat get_claude_context (via MCP) ST-1101 als next-story teruggeeft.
Drie maps in parse-backlog.ts uitgebreid: M11 priority=4, goal omschrijving,
sprint_status='ACTIVE'. M10 → COMPLETED.
Vereist npx prisma db seed na deze commit zodat de live DB de nieuwe
sprint-state weerspiegelt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* docs(ST-1108): add F-11b — Claude question-channel to functional spec
Voegt feature-omschrijving toe naast bestaande F-11 (Claude Code REST API).
Beschrijft het verloop (Claude → MCP-tool → DB → trigger → SSE → user → answer
→ trigger → Claude polls), acceptatiecriteria (8 items), randgevallen (offline-
Claude, assignee-change, expiry, abuse) en datamodel (claude_questions tabel).
Persona Lars als primair, Dina secundair voor klant-werk.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* chore(M11): drop parser ACTIVE-flip; sprint goes via UI from now on
Bij M9/M10 hebben we de seed-flip (MILESTONE_SPRINT_STATUS pivot) gebruikt om
nieuwe stories als IN_SPRINT in een verse sprint te krijgen. Dat werkt maar
is fragiel:
- npm run seed wist user-data
- de "sprint" die de seed maakt is geen echte planning-actie
- bij multi-product scenario's breekt het model
Vanaf M11 gebruiken we de bestaande Sprint-creatie-UI van Scrum4Me. Stories
voor M11 worden via scripts/insert-milestone.ts (idempotent insert, geen
seed-reset) aan de DB toegevoegd; de gebruiker maakt zelf een Sprint aan in
/products/[scrum4me]/sprint en sleept ST-1101..1108 ernaartoe.
Parser-map M11 dus terug naar COMPLETED zodat een eventuele re-seed niet meer
een fake sprint aanmaakt voor M11-stories.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* feat(ST-1101): add ClaudeQuestion model + notify_question_change trigger
Schema (prisma/schema.prisma):
- Nieuw model ClaudeQuestion: id (cuid), story_id (FK Cascade), task_id?
(FK SetNull), product_id (FK Cascade — gedenormaliseerd uit story.product_id
voor SSE-filter zonder join), asked_by (FK Restrict — Claude-token-houder),
question (Text), options (Json? — string[] voor multi-choice), status
('open'|'answered'|'cancelled'|'expired'), answer (Text?), answered_by
(FK SetNull), answered_at?, created_at, expires_at
- Indexes: (story_id, status), (product_id, status), (status, expires_at)
- Back-relations: User.asked_questions (ClaudeQuestionAsker),
User.answered_questions (ClaudeQuestionAnswerer), Story.claude_questions,
Task.claude_questions, Product.claude_questions
Migratie (20260427224849_add_claude_questions):
- Prisma-gegenereerde DDL voor claude_questions + indexes + 5 FK's
- Toegevoegde notify_question_change() functie + claude_questions_notify trigger
op AFTER INSERT/UPDATE
- Emit op BESTAANDE scrum4me_changes-channel met entity:'question' (i.t.t. M10
dat eigen scrum4me_pairing-channel kreeg) — solo-route in ST-1104 moet
entity='question' wegfilteren om regressie op solo-board te voorkomen
- Trigger leest story.assignee_id voor "wacht op jou"-emphase in payload
- DELETE niet ondersteund — questions gaan naar answered/cancelled/expired
Verification: Node pg-client roundtrip via DATABASE_URL toonde correcte payloads
bij INSERT (op=I, status=open) en UPDATE (op=U, status=answered) met alle FK-IDs
en assignee_id correct uit story-join.
Volgende stap M11: ST-1102 — vier MCP-tools in scrum4me-mcp-repo
(ask_user_question, get_question_answer, list_open_questions, cancel_question).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* feat(ST-1103): add answerQuestion server action
actions/questions.ts:
- answerQuestion(questionId, answer) — auth + Zod + demo-blok + access-check
via productAccessFilter (anyone met product-membership mag antwoorden,
consistent met Scrum self-organizing — niet alleen story-assignee)
- Atomic prisma.claudeQuestion.updateMany WHERE id + status='open' +
expires_at>now → status='answered'; concurrent dubbele submit: één wint
(count=1), rest count=0 met disambiguatie via second findFirst
- revalidatePath('/', 'layout') refresh't NavBar bell-count voor SSR-paths;
realtime updates voor andere clients gaan via SSE in ST-1104/1105
- Begrijpelijke NL-foutmeldingen voor elk faalpad
Tests __tests__/actions/questions.test.ts (6 cases):
- happy: status update + revalidatePath called
- demo-block: error + geen DB-call + geen revalidate
- geen access: error + geen update
- al-answered: race-error 'is al answered'
- expired: race-error 'is verlopen'
- lege answer: Zod-validatie
Quality gates: lint 0 errors, tsc clean, vitest 145/145 (17 files).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* feat(ST-1104): add user-scoped /api/realtime/notifications + filter solo-route
Twee delen:
1. Solo-route filter (1-regel-fix in app/api/realtime/solo/route.ts):
- NotifyPayload uitgebreid met entity:'question'
- shouldEmit returnt direct false bij entity='question'
Voorkomt dat solo-clients M11 question-events ontvangen (geen lekkage naar
het Solo-bord; geen onnodig netwerk-verkeer; loose coupling tussen features).
2. Nieuwe SSE-route app/api/realtime/notifications/route.ts:
- User-scoped (geen ?product_id=); query alle accessible product-IDs één keer
bij connect via productAccessFilter
- LISTEN scrum4me_changes; filter entity='question' && product_id ∈ accessible
- Initial-state-event NA LISTEN actief (race-fix conform M10 ST-1004):
query open vragen voor deze user's accessible products, stuur als event:state
met summary (id, story_code/title, assignee_id, question, options, expires_at)
- Hergebruikt het pg.Client + ReadableStream + heartbeat 25s + hard-close 240s +
abort-cleanup-pattern uit solo-route
Tests __tests__/api/notifications-stream.test.ts:
- 401 zonder iron-session cookie (en geen DB-call)
- Solo-route filter wordt visueel/E2E gedekt in ST-1108-acceptatie
Quality gates: lint 0 errors, tsc clean, vitest 146/146 (18 files).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* feat(ST-1105): add NavBar bell + sheet + answer-modal + Zustand store + SSE hook
UI-volledig voor de Claude vraag-antwoord-flow (M11). Bel-icon links van avatar
in NavBar; klik opent slide-over rechts met openstaande vragen; klik op een vraag
opent een modal voor antwoord. Story-assignee = current user krijgt visuele
"voor jou"-emphase met primary-container accent en error-color badge-ring.
Bestanden:
- stores/notifications-store.ts — Zustand store met init/upsert/remove +
openCount/forYouCount selectors (vereenvoudigd vs solo-store: geen pendingOps,
geen optimistic-echo-onderdrukking)
- lib/realtime/use-notifications-realtime.ts — EventSource hook met state-
event en message-event handling, exponential-backoff reconnect, Page
Visibility pause-resume
- components/notifications/notifications-bridge.tsx — Server Component die
initial open-questions fetcht via productAccessFilter
- components/notifications/notifications-realtime-mount.tsx — tiny client
island dat de store hydrateert + de hook activeert
- components/notifications/notifications-sheet.tsx — shadcn Sheet met item-
lijst, "voor jou"-accent voor assignee-vragen, lege staat
- components/notifications/answer-modal.tsx — Dialog met options-radio of
free-text Textarea (max 4000), char-counter, demo-blok via Tooltip; bij
succes optimistisch remove + sheet blijft open zodat meerdere vragen
achter elkaar te beantwoorden zijn
- components/shared/notifications-bell.tsx — Bell-icon met badge (count >9 → "9+"),
ring-accent als forYouCount > 0, ARIA-label voor screenreaders
Wiring:
- components/shared/nav-bar.tsx — <NotificationsBell /> rechts naast <UserMenu>
- app/(app)/layout.tsx — <NotificationsBridge /> naast <SoloRealtimeBridge />,
user.id (server-side) als prop
base-ui-aanpassingen: SheetTrigger/TooltipTrigger gebruiken render-prop ipv
asChild (geen Radix).
Quality gates: lint 0 errors, tsc clean, vitest 146/146, npm run build groen.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* test(ST-1106): add cross-product access-isolation test for notifications SSE
Demo-policy + assignee-emphase zaten al in eerdere stories:
- answerQuestion demo-blok in actions/questions.test.ts (ST-1103)
- AnswerModal demo-tooltip in components/notifications/answer-modal.tsx (ST-1105)
- requireWriteAccess in MCP write-tools (ST-1102)
Deze story voegt expliciet een access-isolation-test toe op de notifications-
SSE-route: productAccessFilter wordt met de echte userId aangeroepen, en
prisma.product.findMany filter't op archived=false + user_id-scope. Dat
garandeert dat een gebruiker geen question-events ontvangt voor producten waar
hij geen membership op heeft.
Story-assignee-emphase blijft visueel-only (NotificationsBell ring-accent +
Sheet primary-container) — toegang werkt product-membership-breed zodat een
team-lid kan invallen als de assignee niet beschikbaar is.
Quality gates: lint 0 errors, tsc clean, vitest 147/147 (was 146).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* feat(ST-1107): add Vercel cron expire-questions (+ M10 pairing cleanup)
POST /api/cron/expire-questions:
- Auth via Authorization: Bearer ${CRON_SECRET} (Vercel injecteert dit
automatisch wanneer de env-var op de project-omgeving staat); 401 als secret
niet matcht of niet is gezet (faal-veilig — geen open endpoint in dev)
- updateMany op claude_questions WHERE status='open' AND expires_at<now →
'expired'
- Bonus: zelfde route ruimt M10 login_pairings op (status='pending' AND
expires_at<now → 'cancelled'). Eén cron-job is goedkoper qua Vercel-budget
en houdt cleanup-strategie centraal — opvolg-actie uit M10 dat geparkeerd was.
Config:
- vercel.json: crons-entry { path: '/api/cron/expire-questions', schedule: '0 */6 * * *' } (4x/dag)
- lib/env.ts: CRON_SECRET als optional in Zod-schema
- .env.example: documentatie + openssl rand-tip
Tests __tests__/api/cron-expire-questions.test.ts (4 cases):
- 401 zonder Authorization-header
- 401 met verkeerde secret
- 401 als CRON_SECRET niet is gezet (faal-veilig)
- 200 met juiste secret: response { expired_questions, expired_pairings, ran_at }
+ beide updateMany WHERE/data correct
Quality gates: lint 0 errors, tsc clean, vitest 151/151.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* docs(ST-1108): document M11 question-channel — API + architecture + pattern
docs/API.md — twee nieuwe secties:
- 'Notifications' met /api/realtime/notifications SSE-endpoint (event-shapes,
filter-rules, voorbeeld)
- 'Cron — Expire questions' met /api/cron/expire-questions (Bearer-auth,
schedule, response-shape, manual curl)
docs/scrum4me-architecture.md — nieuw hoofdstuk 'Vraag-antwoord-kanaal Claude
↔ user' tussen QR-pairing-flow en Projectstructuur:
- Mermaid sequence-diagram (Claude → DB → trigger → SSE → user → answer →
trigger → Claude polls)
- Threat-model-tabel (race, demo-misbruik, cross-product leak, cron-misbruik,
growth, log-leakage)
- Subsectie 'Waarom hergebruik scrum4me_changes-kanaal' met trade-off vs M10's
eigen-kanaal-aanpak
docs/patterns/claude-question-channel.md — herbruikbaar pattern 'Bidirectionele
async-comms tussen MCP-agent en interactieve user' met de vier eindpunten,
vier security-uitgangspunten, channel-strategie-tabel, TTL-richtlijn, en
sjabloon-bestanden per laag (DB / server / client / MCP-tools).
CLAUDE.md — extra rij in Implementatiepatronen-tabel die naar het nieuwe
pattern-doc verwijst.
Acceptatie 6 scenario's:
1. Sync happy path (MCP wait_seconds + UI submit) — handmatig getest tijdens
ST-1105 acceptance-loop met de q-test injection
2. Async happy path — gedekt door get_question_answer-tool in ST-1102 +
list_open_questions
3. Demo-block — actions/questions.test.ts (case 2: demo-user) + AnswerModal
tooltip (visueel)
4. Access-isolation — notifications-stream.test.ts (case 'access-isolation')
5. Expiry — cron-expire-questions.test.ts (case '200 met juiste secret')
6. Race — actions/questions.test.ts (case 'al-answered' via atomic updateMany)
Quality gates: lint 0 errors, tsc clean, vitest 151/151 (19 files), npm run
build groen.
M11 is hiermee feature-compleet. feat/M11-claude-questions heeft 12 commits
lokaal, klaar voor user-acceptatie en PR.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(ST-1107): cron schedule daily — Vercel Hobby allows only 1 run/day
Vercel deploy faalde met:
> Hobby accounts are limited to daily cron jobs.
> This cron expression (0 */6 * * *) would run more than once per day.
Schedule van 4×/dag (0 */6 * * *) naar 1×/dag (0 4 * * * — 04:00 UTC, rustig
tijdstip). Functioneel acceptabel: ClaudeQuestion TTL is 24u, dus daily
cleanup pakt alles dat in de afgelopen 24u verlopen is. Login-pairings TTL
is 2 min — die zijn al onbruikbaar zodra ze expiren, cron is alleen voor
status-housekeeping.
Schedule-referenties consistent bijgewerkt in docs (API.md, architecture,
backlog M11-sectie, plan-doc, pattern-doc) + comment in route.ts. Vermelding
overal dat dit een Hobby-plan-beperking is en Pro fijnmaziger ondersteunt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
494 lines
14 KiB
Markdown
494 lines
14 KiB
Markdown
# Scrum4Me REST API
|
|
|
|
REST-API contract voor Claude Code en andere clients.
|
|
|
|
## Authenticatie
|
|
|
|
Alle endpoints behalve `GET /api/health` vereisen een Bearer-token:
|
|
|
|
```
|
|
Authorization: Bearer <token>
|
|
```
|
|
|
|
Tokens beheer je via Instellingen → Tokens (`/settings/tokens`). Een token is gekoppeld aan één gebruiker; een demo-account-token kan lezen maar niet schrijven (`403`).
|
|
|
|
## Status-enums
|
|
|
|
De API gebruikt **lowercase** statussen. De database gebruikt UPPER_SNAKE; de vertaling gebeurt op de boundary.
|
|
|
|
| Entiteit | Waarden |
|
|
|---|---|
|
|
| Task status | `todo`, `in_progress`, `review`, `done` |
|
|
| Story status | `open`, `in_sprint`, `done` |
|
|
|
|
## Foutcodes
|
|
|
|
| Code | Betekenis |
|
|
|---|---|
|
|
| `200` | OK |
|
|
| `201` | Created |
|
|
| `400` | Malformed body (bv. ongeldige JSON) |
|
|
| `401` | Token ontbreekt of ongeldig |
|
|
| `403` | Token heeft geen toegang (demo-account, geen lid van product) |
|
|
| `404` | Resource niet gevonden |
|
|
| `422` | Validatiefout — body is wel-gevormd maar niet acceptabel |
|
|
| `500` | Onverwachte serverfout |
|
|
|
|
---
|
|
|
|
## Endpoints
|
|
|
|
### `GET /api/health`
|
|
|
|
Health-probe. Geen authenticatie vereist.
|
|
|
|
**Query params:** `?db=1` voegt een DB-ping toe.
|
|
|
|
**Response (200):**
|
|
```json
|
|
{ "status": "ok", "version": "0.3.x", "time": "2026-04-26T20:00:00Z" }
|
|
```
|
|
|
|
Met `?db=1`:
|
|
```json
|
|
{ "status": "ok", "version": "0.3.x", "time": "...", "database": "ok" }
|
|
```
|
|
|
|
`database` is `"ok"` of `"down"`. De endpoint zelf retourneert altijd `200`.
|
|
|
|
```bash
|
|
curl https://scrum4me.app/api/health?db=1
|
|
```
|
|
|
|
---
|
|
|
|
### `GET /api/products`
|
|
|
|
Lijst van actieve producten waar de tokengebruiker eigenaar of lid van is.
|
|
|
|
**Response (200):**
|
|
```json
|
|
[
|
|
{
|
|
"id": "cmofu...",
|
|
"code": "SCRUM4ME",
|
|
"name": "Scrum4Me",
|
|
"description": "...",
|
|
"repo_url": "https://github.com/...",
|
|
"definition_of_done": "..."
|
|
}
|
|
]
|
|
```
|
|
|
|
```bash
|
|
curl -H "Authorization: Bearer $TOKEN" https://scrum4me.app/api/products
|
|
```
|
|
|
|
---
|
|
|
|
### `GET /api/products/:id/claude-context`
|
|
|
|
Bundled context voor Claude Code: product, actieve sprint, volgende story (met tasks) en open todos van de tokengebruiker — in één call.
|
|
|
|
**Response (200):**
|
|
```json
|
|
{
|
|
"product": { "id", "code", "name", "description", "repo_url", "definition_of_done" },
|
|
"active_sprint": { "id": "...", "sprint_goal": "...", "status": "ACTIVE" } | null,
|
|
"next_story": {
|
|
"id", "code", "title", "description", "acceptance_criteria",
|
|
"priority", "status",
|
|
"tasks": [
|
|
{ "id", "code", "title", "description", "implementation_plan",
|
|
"priority", "sort_order", "status" }
|
|
]
|
|
} | null,
|
|
"open_todos": [
|
|
{ "id", "title", "description", "created_at" }
|
|
]
|
|
}
|
|
```
|
|
|
|
`open_todos` is gelimiteerd op 50 items, gesorteerd op `created_at` asc. Demo-tokens kunnen dit endpoint lezen.
|
|
|
|
```bash
|
|
curl -H "Authorization: Bearer $TOKEN" \
|
|
https://scrum4me.app/api/products/$PRODUCT_ID/claude-context
|
|
```
|
|
|
|
---
|
|
|
|
### `GET /api/products/:id/next-story`
|
|
|
|
Hoogst geprioriteerde open story in de actieve sprint.
|
|
|
|
**Response (200):**
|
|
```json
|
|
{
|
|
"id": "...",
|
|
"code": "ST-356",
|
|
"title": "Solo Kanban-bord met DnD en Zustand",
|
|
"description": "...",
|
|
"acceptance_criteria": "...",
|
|
"status": "in_sprint",
|
|
"tasks": [
|
|
{
|
|
"id": "...",
|
|
"code": "ST-356.1",
|
|
"title": "Store stores/solo-store.ts",
|
|
"description": "...",
|
|
"implementation_plan": null,
|
|
"priority": 2,
|
|
"sort_order": 1,
|
|
"status": "todo"
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
**Foutcodes:** `404` als geen actieve sprint of geen open stories.
|
|
|
|
---
|
|
|
|
### `GET /api/sprints/:id/tasks`
|
|
|
|
Lijst taken van de sprint, geordend op `(story.sort_order, task.priority, task.sort_order)`.
|
|
|
|
**Query params:** `?limit=N` (default 10, max 50)
|
|
|
|
**Response (200):**
|
|
```json
|
|
[
|
|
{
|
|
"id": "...",
|
|
"code": "ST-356.1",
|
|
"title": "...",
|
|
"description": "...",
|
|
"implementation_plan": null,
|
|
"story_id": "...",
|
|
"story_code": "ST-356",
|
|
"priority": 2,
|
|
"sort_order": 1,
|
|
"status": "todo"
|
|
}
|
|
]
|
|
```
|
|
|
|
---
|
|
|
|
### `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.
|
|
Toegestane status-waarden zijn `todo`, `in_progress` en `done`. `review`
|
|
wordt door deze endpoint geweigerd zolang de sprint-UI die state niet
|
|
rendert — gebruik de Kanban-board voor REVIEW-overgangen.
|
|
|
|
**Body:**
|
|
```json
|
|
{ "status": "in_progress", "implementation_plan": "..." }
|
|
```
|
|
|
|
**Response (200):**
|
|
```json
|
|
{
|
|
"id": "...",
|
|
"status": "in_progress",
|
|
"implementation_plan": "..."
|
|
}
|
|
```
|
|
|
|
**Foutcodes:** `422` bij ongeldige body of onbekende status. `403` bij demo-token.
|
|
|
|
---
|
|
|
|
### `POST /api/stories/:id/log`
|
|
|
|
Activiteit vastleggen op een story.
|
|
|
|
**Body — IMPLEMENTATION_PLAN:**
|
|
```json
|
|
{
|
|
"type": "IMPLEMENTATION_PLAN",
|
|
"content": "Plan: ...",
|
|
"metadata": { "branch": "feat/x" }
|
|
}
|
|
```
|
|
|
|
**Body — TEST_RESULT:**
|
|
```json
|
|
{
|
|
"type": "TEST_RESULT",
|
|
"content": "Alle tests groen",
|
|
"status": "PASSED",
|
|
"metadata": { "ci_run": "..." }
|
|
}
|
|
```
|
|
|
|
**Body — COMMIT:**
|
|
```json
|
|
{
|
|
"type": "COMMIT",
|
|
"content": "Werk afgerond",
|
|
"commit_hash": "abc123",
|
|
"commit_message": "feat(ST-XXX): ...",
|
|
"metadata": { "branch": "feat/x" }
|
|
}
|
|
```
|
|
|
|
`metadata` is optioneel, vrij JSON-object. **Response (201):**
|
|
```json
|
|
{ "id": "...", "created_at": "..." }
|
|
```
|
|
|
|
---
|
|
|
|
### `POST /api/todos`
|
|
|
|
Nieuwe todo voor de tokengebruiker.
|
|
|
|
**Body:**
|
|
```json
|
|
{
|
|
"title": "Een ding doen",
|
|
"description": "Optionele uitleg, max 2000 tekens",
|
|
"product_id": "cmof..."
|
|
}
|
|
```
|
|
|
|
**Response (201):**
|
|
```json
|
|
{ "id": "...", "title": "...", "description": "...", "created_at": "..." }
|
|
```
|
|
|
|
---
|
|
|
|
### `GET /api/realtime/solo?product_id=...`
|
|
|
|
Server-Sent Events stream voor het Solo Paneel. Wordt gebruikt door de browser-UI (`useSoloRealtime`); voor Claude Code zelden relevant, maar gedocumenteerd voor volledigheid.
|
|
|
|
**Auth:** iron-session cookie of Bearer-token. Demo-tokens mogen lezen.
|
|
**Query params:** `product_id` (verplicht).
|
|
**Response:** `text/event-stream`. Stream blijft open tot de client sluit of de server na 240s een hard-close doet (client herconnect dan transparant).
|
|
|
|
**Events:**
|
|
- `event: ready` — eenmalig direct na connect, met `{ product_id, sprint_id }` als payload.
|
|
- `event: error` — bij interne fouten (pg connect mislukt e.d.).
|
|
- `data: {...}` — task/story mutaties die binnen scope vallen (zie hieronder). Payload-shape:
|
|
|
|
```json
|
|
{
|
|
"op": "I" | "U" | "D",
|
|
"entity": "task" | "story",
|
|
"id": "cmof...",
|
|
"story_id": "cmof...",
|
|
"product_id": "cmof...",
|
|
"sprint_id": "cmog..." ,
|
|
"assignee_id": "cmof..." ,
|
|
"task_status": "TO_DO" | "IN_PROGRESS" | "REVIEW" | "DONE",
|
|
"task_title": "...",
|
|
"task_sort_order": 1,
|
|
"changed_fields": ["status", "updated_at"]
|
|
}
|
|
```
|
|
|
|
Niet alle velden zijn altijd aanwezig — `task_*` alleen voor `entity: "task"`, idem `story_*`. `task_status` gebruikt de **DB-enum** (UPPER_SNAKE), niet de lowercase API-vorm.
|
|
|
|
- `: heartbeat` — SSE-comment elke 25s, om proxies keep-alive te houden. Kan genegeerd worden.
|
|
|
|
**Server-side filter:**
|
|
- `product_id` matcht de query-param
|
|
- `sprint_id` matcht de actieve sprint van het product
|
|
- `assignee_id` is gelijk aan de ingelogde user (of `null` voor unassigned-story claims)
|
|
|
|
Niet-matchende events worden gedropt — clients ontvangen geen irrelevante data.
|
|
|
|
**Voorbeeld (browser):**
|
|
```js
|
|
const source = new EventSource('/api/realtime/solo?product_id=cmof...')
|
|
source.onmessage = (e) => console.log(JSON.parse(e.data))
|
|
```
|
|
|
|
---
|
|
|
|
## Auth — QR-pairing (M10)
|
|
|
|
Drie anonieme/cookie-geauthenticeerde endpoints voor de password-loze inlog
|
|
via QR-pairing. Worden door de browser gebruikt (niet door Claude Code) —
|
|
gedocumenteerd voor volledigheid en voor handmatige curl-tests.
|
|
|
|
**Cookie-mechaniek:** `pair/start` zet een korte `s4m_pair`-HttpOnly-cookie
|
|
(`Path=/api/auth/pair`, `Max-Age=300`, `SameSite=Lax`, `Secure` in productie).
|
|
`pair/stream` en `pair/claim` authenticeren tegen die cookie. Geheim materiaal
|
|
zit nooit in URL-paden of querystrings — `mobileSecret` reist alleen via QR-
|
|
fragment (`#s=…`) en POST-body, `desktopToken` alleen via cookie.
|
|
|
|
### `POST /api/auth/pair/start`
|
|
|
|
Anon. Maakt een nieuwe `LoginPairing` aan en zet de pre-auth cookie.
|
|
|
|
**Auth:** geen.
|
|
**Body:** geen.
|
|
**Rate-limit:** 10 per IP per minuut (zelfde patroon als `/login`).
|
|
|
|
**Response 200:**
|
|
```json
|
|
{
|
|
"pairingId": "cmoh...",
|
|
"mobileSecret": "<43-char base64url>",
|
|
"expiresAt": "2026-04-27T20:30:00.000Z",
|
|
"qrUrl": "https://.../m/pair#id=cmoh...&s=<mobileSecret>"
|
|
}
|
|
```
|
|
Plus `Set-Cookie: s4m_pair=<desktopToken>; HttpOnly; Path=/api/auth/pair; Max-Age=300; SameSite=Lax`.
|
|
|
|
**Foutcodes:** `429` bij rate-limit overschreden.
|
|
|
|
**Voorbeeld:**
|
|
```bash
|
|
curl -i -X POST -c /tmp/jar http://localhost:3000/api/auth/pair/start
|
|
```
|
|
|
|
---
|
|
|
|
### `GET /api/auth/pair/stream/:pairingId`
|
|
|
|
Server-Sent Events stream die de desktop opent direct na `pair/start` om op
|
|
de approve-bevestiging van de mobiel te wachten.
|
|
|
|
**Auth:** `s4m_pair`-cookie. Werkt vanuit `EventSource` met `withCredentials: true`.
|
|
**Path:** `pairingId` is niet vertrouwelijk; cookie is het bewijs.
|
|
**Stream-duur:** maximaal 240s (Vercel-buffer onder de 300s `maxDuration`); sluit
|
|
zodra status `consumed` of `cancelled` doorkomt.
|
|
|
|
**Events:**
|
|
- `event: state` — eenmalig direct na connect, met `{ pairing_id, status }` (status van pairing op moment van connecten — voorkomt race wanneer approve net vóór SSE-open landt).
|
|
- `data: {...}` — bij elke status-overgang. Payload:
|
|
```json
|
|
{ "op": "I" | "U", "pairing_id": "cmoh...", "status": "pending" | "approved" | "consumed" | "cancelled" }
|
|
```
|
|
- `: heartbeat` — SSE-comment elke 25s.
|
|
|
|
**Foutcodes:** `401` zonder/foute cookie, `404` als pairing onbekend, `410` als pairing verlopen.
|
|
|
|
**Voorbeeld:**
|
|
```bash
|
|
curl -N -i -b /tmp/jar http://localhost:3000/api/auth/pair/stream/<pairingId>
|
|
```
|
|
|
|
---
|
|
|
|
### `POST /api/auth/pair/claim`
|
|
|
|
Cookie-auth. Atomisch consume van een approved pairing → schrijft de echte
|
|
`scrum4me-session` cookie zodat de desktop is ingelogd.
|
|
|
|
**Auth:** `s4m_pair`-cookie.
|
|
**Body:** `{ "pairingId": "cmoh..." }`.
|
|
|
|
**Response 200:** `{ "ok": true }` plus
|
|
- `Set-Cookie: scrum4me-session=...; HttpOnly; SameSite=Lax` — paired-sessie met `paired: true` en `pairedExpiresAt = now + 8h` payload-velden.
|
|
- `Set-Cookie: s4m_pair=...; Max-Age=0` — pre-auth cookie wordt gewist.
|
|
|
|
**Foutcodes:**
|
|
- `400` bij ontbrekende of malformed body
|
|
- `401` zonder cookie of bij hash-mismatch (cookie matcht geen pairing)
|
|
- `410` als pairing al consumed/cancelled is (replay) of verlopen
|
|
|
|
**Voorbeeld:**
|
|
```bash
|
|
curl -i -X POST -b /tmp/jar -c /tmp/jar \
|
|
-H "Content-Type: application/json" \
|
|
-d '{"pairingId":"<pairingId>"}' \
|
|
http://localhost:3000/api/auth/pair/claim
|
|
```
|
|
|
|
---
|
|
|
|
## Notifications — Vraag-antwoord-kanaal (M11)
|
|
|
|
Endpoints voor de Claude vraag-antwoord-flow. De **MCP-tools** in de scrum4me-mcp-repo (`ask_user_question`, `get_question_answer`, `list_open_questions`, `cancel_question`) zijn de primaire schrijf-interface; de endpoints hieronder zijn voor de browser-UI en cron.
|
|
|
|
### `GET /api/realtime/notifications`
|
|
|
|
Server-Sent Events stream voor de notifications-bell in de NavBar. **User-scoped** — geen `product_id`-param; filtert server-side op alle producten waar de gebruiker eigenaar of teamlid is.
|
|
|
|
**Auth:** iron-session cookie. Demo-gebruikers mogen lezen.
|
|
**Response:** `text/event-stream`. Stream blijft open tot client sluit of server na 240s een hard-close doet (client herconnect).
|
|
|
|
**Events:**
|
|
- `event: state` — eenmalig direct na connect, met `{ questions: [...] }` als payload (zelfde shape als de live updates).
|
|
- `data: {...}` — bij elke status-overgang in `claude_questions`. Payload-shape:
|
|
```json
|
|
{
|
|
"op": "I" | "U",
|
|
"entity": "question",
|
|
"id": "cmoh...",
|
|
"product_id": "cmoh...",
|
|
"story_id": "cmoh...",
|
|
"task_id": "cmoh..." | null,
|
|
"assignee_id": "cmoh..." | null,
|
|
"status": "open" | "answered" | "cancelled" | "expired"
|
|
}
|
|
```
|
|
Het is een delta — voor de volledige vraag-tekst en options reconnect de client (initial-state-event levert ze opnieuw).
|
|
- `: heartbeat` — SSE-comment elke 25s.
|
|
|
|
**Server-side filter:**
|
|
- `payload.entity === 'question'` (`task` en `story` events horen op `/api/realtime/solo`)
|
|
- `payload.product_id` zit in de set producten met user-access (productAccessFilter)
|
|
|
|
**Voorbeeld:**
|
|
```js
|
|
const source = new EventSource('/api/realtime/notifications', { withCredentials: true })
|
|
```
|
|
|
|
---
|
|
|
|
## Cron — Expire questions
|
|
|
|
### `POST /api/cron/expire-questions`
|
|
|
|
Vercel cron handler die dagelijks draait. Markeert verlopen open vragen als `expired` en verlopen pending login_pairings als `cancelled`.
|
|
|
|
**Auth:** `Authorization: Bearer ${CRON_SECRET}` — header die Vercel automatisch injecteert wanneer de env-var op de project-omgeving staat. Zonder secret of bij mismatch: 401.
|
|
|
|
**Schedule:** `0 4 * * *` (dagelijks om 04:00 UTC; Vercel Hobby-plan staat alleen daily crons toe — Pro ondersteunt fijnmazigere schedules).
|
|
|
|
**Response 200:**
|
|
```json
|
|
{
|
|
"expired_questions": 0,
|
|
"expired_pairings": 0,
|
|
"ran_at": "2026-04-28T00:00:00.000Z"
|
|
}
|
|
```
|
|
|
|
**Voorbeeld (handmatige trigger):**
|
|
```bash
|
|
curl -X POST -H "Authorization: Bearer $CRON_SECRET" \
|
|
https://your-app.vercel.app/api/cron/expire-questions
|
|
```
|
|
|
|
---
|
|
|
|
## Voorbeeldworkflow voor Claude Code
|
|
|
|
1. **Probe:** `GET /api/health?db=1` — bevestig dat de service en DB bereikbaar zijn.
|
|
2. **Context:** `GET /api/products/$ID/claude-context` — haal product, sprint, volgende story en todos op in één call.
|
|
3. **Plan vastleggen:** `POST /api/stories/$STORY_ID/log` met `type: IMPLEMENTATION_PLAN`.
|
|
4. **Per task:** `PATCH /api/tasks/$TASK_ID` met `status: "in_progress"`, daarna met `status: "done"` plus eventueel `implementation_plan`.
|
|
5. **Test:** `POST /api/stories/$STORY_ID/log` met `type: TEST_RESULT` en `status: PASSED|FAILED`.
|
|
6. **Commit:** `POST /api/stories/$STORY_ID/log` met `type: COMMIT`, `commit_hash`, `commit_message`, optioneel `metadata: { branch }`.
|