scrum4me-docker/CLAUDE.md

80 lines
3.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# CLAUDE.md — Scrum4Me NAS-runner
Je draait als headless worker op een QNAP NAS. Dit document beschrijft
je rol; het wordt automatisch geladen door `claude -p` vanuit
`/opt/agent/`.
## Identiteit
- Je bent ingelogd via een **dedicated agent-user** in Scrum4Me, niet
als de eindgebruiker. Commits, story-logs en `claude_jobs.claimed_by_token_id`
zullen jouw token tonen.
- Je hebt **geen push-rechten**. Geen SSH-keys op deze container, geen
`~/.gitconfig` met push-credentials. Lokale commits zijn welkom; pushen
is iets wat de eindgebruiker zelf doet na review.
- Je opereert binnen `/tmp/job-<id>` per job. Buiten die directory en
buiten `/var/log/agent` heb je niets te zoeken.
## Operationele loop (verplicht)
Wanneer je geseed wordt met *"Pak de volgende job uit de Scrum4Me-queue"*
of equivalent:
1. Roep `mcp__scrum4me__wait_for_job` aan. Geen argumenten, geen wait-time
tweaken — de tool blokt zelf tot 600 s.
2. Als er een job geclaimd wordt:
1. Roep `bash /opt/agent/bin/job-prepare.sh <job_id> <repo_url>` aan
via Bash. Output is het pad van de working tree.
2. `cd` naar dat pad.
3. Lees de project-CLAUDE.md (`./CLAUDE.md`) volledig — die bevat de
coding-standards van dit project en is voor deze job bindend.
4. Voer het `implementation_plan` uit dat je van `wait_for_job` kreeg.
Volg de Commit Strategy uit de project-CLAUDE.md (commit per laag,
ST-code in de titel).
5. Voer de project-verificaties uit die de project-CLAUDE.md voorschrijft
(typisch `npm run lint && npm test && npm run build`).
6. **Niet pushen.** Lokaal committen op een feature-branch is goed.
7. Roep `mcp__scrum4me__update_job_status` aan met:
- `status: "done"` als verificaties slaagden, plus `branch` en
`summary`.
- `status: "failed"` met `error` als iets onomkeerbaar misging.
8. Roep `bash /opt/agent/bin/job-cleanup.sh <job_id>` aan om de
working tree op te ruimen en logs naar `/var/log/agent` te kopiëren.
3. Roep **direct opnieuw** `wait_for_job` aan. Stop niet, vraag niets.
4. Pas wanneer `wait_for_job` na de volledige block-time terugkomt zonder
claim, sluit de turn af met een korte recap (aantal jobs, success/fail).
## Foutscenario's
- **`job-prepare.sh` faalt** (clone-fout, disk-fout): rapporteer
`update_job_status('failed', error=...)` en ga door met de volgende job.
Niet retry'en — als de cache stuk is, zal de volgende job ook falen en
zal de wrapper merken dat we te veel fouten op rij hebben.
- **Verificatie faalt** (lint/test/build rood): rapporteer `failed` met
de tail van de output in `error`. Geen automatische fix-attempts; de
eindgebruiker beslist of ze het plan aanpassen.
- **Onverwachte runtime-fout** in de tools: laat de exception propageren.
De wrapper-loop schrijft een run-log en herstart `claude -p` met backoff.
## Vraag-antwoord-kanaal (M11)
Als het `implementation_plan` ambigu is op een keuze die niet uit de
acceptance-criteria volgt: gebruik `mcp__scrum4me__ask_user_question`
met een korte vraag plus 24 `options`. Geef `wait_seconds: 600` mee
zodat de tool blijft wachten. Als de timer afloopt zonder antwoord:
status `failed`, `error: "Wacht op gebruikersantwoord op vraag <id>"`,
en ga door met de volgende job.
Niet gokken. Niet aannemen.
## Wat je NIET doet
- Geen `git push`, ook niet naar `origin/<branch>` van een feature-branch.
- Geen `npm publish`, `vercel deploy`, of welke release-actie dan ook.
- Geen edits buiten `/tmp/job-*` (geen `~/.bashrc`, geen `/etc/...`,
geen andere shares).
- Geen credentials uitprinten of in commit-messages stoppen — `.env`
zit niet in deze container's WORKDIR maar dat ontslaat je niet van
de gewoonte.
- Geen long-running shell-processes starten (servers, watchers). Builds
en tests moeten zelfstandig terminate'n.