docs: enforce one-branch-per-milestone policy to limit Vercel builds
Vercel preview-deployments worden bij elke push naar een feature-branch getriggered en kosten op het Hobby-account budget. Voeg expliciete Branch & PR Strategy toe aan CLAUDE.md: één branch per milestone, commits accumuleren lokaal, push + PR pas na handmatige gebruiker-acceptatie. Uitzonderingen voor planning-only PR's (alleen docs) en hotfixes. Update tegelijk de branch/commit-strategie-tabel in het M10-implementatieplan zodat die de nieuwe policy weerspiegelt (één branch feat/M10-qr-login, chronologische commits per stap, push pas bij groene happy-path-acceptatie). Bevat een 'Wanneer aanpassen'-sectie zodat de regel makkelijk teruggedraaid kan worden zodra het account naar Pro gaat. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
8ef4edecc8
commit
a35edc97f5
2 changed files with 57 additions and 13 deletions
31
CLAUDE.md
31
CLAUDE.md
|
|
@ -133,6 +133,37 @@ SESSION_SECRET="" # openssl rand -base64 32
|
|||
|
||||
---
|
||||
|
||||
## Branch & PR Strategy (STRICT — kostenbeheersing)
|
||||
|
||||
> **Core rule: één branch per milestone, PR alleen na gebruikerstest**
|
||||
|
||||
Elke `git push` naar een feature-branch triggert een Vercel preview-deployment. Op het huidige Hobby-account zijn die schaars en kosten geld; we minimaliseren preview-builds tot er werkelijk iets te reviewen valt.
|
||||
|
||||
### Wel doen
|
||||
|
||||
- Eén branch voor de hele milestone — `feat/M{N}-{slug}` (bv. `feat/M10-qr-login`); voor losse stories zonder milestone blijft `feat/ST-XXX-{slug}` geldig
|
||||
- Commits accumuleren lokaal volgens de Commit Strategy hieronder — één commit per stap, ST-code in de titel
|
||||
- Pushen + PR openen **pas nadat de gebruiker de milestone handmatig heeft getest en goedgekeurd** — vraag expliciet om bevestiging vóór `git push`
|
||||
- Tussentijdse "klaar voor jouw test"-momenten markeren met een lokale tag of een berichtje in chat, niet met een push
|
||||
|
||||
### Niet doen
|
||||
|
||||
- Pushen na elke story of commit
|
||||
- Een PR per story openen tijdens de implementatie
|
||||
- "Just-in-case" pushen om backup te hebben — gebruik `git stash`, een lokale tag, of meerdere lokale branches
|
||||
- `--force-push` om eerdere preview-builds "weg te toveren" (kost dezelfde build opnieuw bij hercreatie)
|
||||
|
||||
### Uitzonderingen
|
||||
|
||||
- Een **planning-PR** zonder code-wijzigingen (alleen docs in `docs/plans/` of `docs/`) mag direct gepusht worden — die triggert geen functional regressie en is goedkoop te bouwen
|
||||
- Een **bugfix-hotfix** op `main` met aantoonbare productie-impact mag direct gepusht worden
|
||||
|
||||
### Wanneer aanpassen
|
||||
|
||||
Zodra het Vercel-account naar Pro (of andere omgeving zonder per-build-kosten) gaat: vervang deze regel door "branch + PR per story" zoals oorspronkelijk in dit document stond. Werk deze sectie bij én documenteer de wijziging in `docs/agent-instruction-audit.md`.
|
||||
|
||||
---
|
||||
|
||||
## Commit Strategy (STRICT)
|
||||
|
||||
> **Core rule: één commit = één verantwoordelijkheid**
|
||||
|
|
|
|||
|
|
@ -838,24 +838,37 @@ ST-1006 staat bij de API-laag (niet bij UI) omdat het een Route Handler is; ST-1
|
|||
|
||||
## Branch- en commit-strategie
|
||||
|
||||
Per CLAUDE.md één commit per laag, één story per branch (zo veel mogelijk). Voorstel:
|
||||
Per [CLAUDE.md → Branch & PR Strategy](../../CLAUDE.md#branch--pr-strategy-strict--kostenbeheersing): **één branch voor de hele milestone**, PR pas na handmatige acceptatie door de gebruiker. Reden: elke push triggert een Vercel preview-build, en op het Hobby-account zijn die schaars.
|
||||
|
||||
| # | Branch | Stories | Commit-titles |
|
||||
|---|---|---|---|
|
||||
| 1 | `feat/ST-1001-login-pairing-schema` | ST-1001 | `feat(ST-1001): add LoginPairing model` + `feat(ST-1001): add pg_notify trigger on scrum4me_pairing channel` |
|
||||
| 2 | `feat/ST-1002-pairing-helpers` | ST-1002 | `feat(ST-1002): add pairing helpers and pre-auth cookie` + `feat(ST-1002): extend SessionData with paired flag` + `feat(ST-1002): guard expired paired sessions in app layout` |
|
||||
| 3 | `feat/ST-1003-pair-start-endpoint` | ST-1003 | `feat(ST-1003): add /api/auth/pair/start with rate-limit and pre-auth cookie` |
|
||||
| 4 | `feat/ST-1004-pair-stream-sse` | ST-1004 | `feat(ST-1004): add SSE /api/auth/pair/stream with cookie auth` |
|
||||
| 5 | `feat/ST-1005-mobile-confirmation` | ST-1005 | `feat(ST-1005): add pairing server actions` + `feat(ST-1005): add mobile pair confirmation page with hash-fragment client island` |
|
||||
| 6 | `feat/ST-1006-pair-claim-endpoint` | ST-1006 | `feat(ST-1006): add /api/auth/pair/claim with atomic consume` |
|
||||
| 7 | `feat/ST-1007-desktop-qr-login` | ST-1007 | `chore(ST-1007): add qrcode.react dependency` + `feat(ST-1007): add QR login button on /login with SSE listener` |
|
||||
| 8 | `feat/ST-1008-qr-login-docs` | ST-1008 | `docs(ST-1008): document QR-pairing endpoints in API.md` + `docs(ST-1008): add QR-pairing flow and threat-model to architecture` + `docs(ST-1008): add qr-login pattern doc` |
|
||||
**Branch:** `feat/M10-qr-login` — afgesplitst van `main` na merge van de planning-PR (#11). Alle ST-1001..ST-1008-werk landt op deze branch.
|
||||
|
||||
Elke story → eigen PR. Reviewbaar in volgorde; ST-1007 hangt af van ST-1003 t/m ST-1006 (kan niet runtime-getest zonder), maar landen in stuk-en-stuk PR's blijft mogelijk omdat de UI alleen rendert achter de "Inloggen via mobiel"-knop.
|
||||
**Commits** in chronologische volgorde, één per stap, ST-code in de titel. Voorbeeld-progressie:
|
||||
|
||||
```
|
||||
feat(ST-1001): add LoginPairing model
|
||||
feat(ST-1001): add pg_notify trigger on scrum4me_pairing channel
|
||||
feat(ST-1002): add pairing helpers and pre-auth cookie
|
||||
feat(ST-1002): extend SessionData with paired flag
|
||||
feat(ST-1002): guard expired paired sessions in app layout
|
||||
feat(ST-1003): add /api/auth/pair/start with rate-limit and pre-auth cookie
|
||||
feat(ST-1004): add SSE /api/auth/pair/stream with cookie auth
|
||||
feat(ST-1005): add pairing server actions
|
||||
feat(ST-1005): add mobile pair confirmation page with hash-fragment client island
|
||||
feat(ST-1006): add /api/auth/pair/claim with atomic consume
|
||||
chore(ST-1007): add qrcode.react dependency
|
||||
feat(ST-1007): add QR login button on /login with SSE listener
|
||||
docs(ST-1008): document QR-pairing endpoints in API.md
|
||||
docs(ST-1008): add QR-pairing flow and threat-model to architecture
|
||||
docs(ST-1008): add qr-login pattern doc
|
||||
```
|
||||
|
||||
**Push + PR**: pas nadat ST-1008-acceptatie-scenario 1 (happy path, end-to-end op localhost) handmatig groen is bevonden door de gebruiker. Tussentijdse "klaar voor jouw test"-momenten markeren we lokaal — niet met een push.
|
||||
|
||||
**Pre-merge gates** (uit CLAUDE.md DoD):
|
||||
- `npm run lint && npm test && npm run build` groen op CI
|
||||
- Schema-wijziging in ST-1001 → wekelijkse drift-check `trig_015FFUnxjz9WMuhhWNGBQKFD` mag niet rood staan; `vendor/scrum4me` submodule in scrum4me-mcp meebewegen
|
||||
- Schema-wijziging in ST-1001 → wekelijkse drift-check `trig_015FFUnxjz9WMuhhWNGBQKFD` mag niet rood staan; `vendor/scrum4me`-submodule in scrum4me-mcp meebewegen na merge
|
||||
|
||||
**Wanneer dit aanpassen:** zodra het Vercel-account naar Pro gaat — zie CLAUDE.md.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue