M10: Password-loze inlog via QR-pairing — backlog + implementatie-plan (#11)

* docs(ST-1001..1008): add M10 — QR-pairing login milestone to backlog

Plant acht stories ST-1001..ST-1008 voor password-loze inlog via QR-pairing.
Mobiele bevestiging met UA+IP, demo-blokkade, paired-sessie 8u TTL.
Security-uitgangspunt: mobileSecret reist alleen via QR-fragment + POST-body,
desktop-SSE/claim via HttpOnly pre-auth cookie — geheim materiaal nooit in
URL-paden, querystrings, access logs of browsergeschiedenis. Twee gescheiden
hashes in DB (secret_hash + desktop_token_hash). Bouwt voort op M8 LISTEN/NOTIFY-
infra met eigen channel scrum4me_pairing.

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

* chore(ST-1001..1008): teach backlog parser about M9 + M10

M9 (Actief Product Backlog) was bij eerdere merge per ongeluk overgeslagen in
de drie milestone-maps; viel terug op fallbacks. Nu expliciet, samen met M10
(QR-pairing). Parser self-test toont 12 milestones / 118 stories / 190 tasks.

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

* docs(ST-1001..1008): document QR-login flow in functional spec + persona

Voeg F-01b (Inloggen via mobiel via QR-pairing) toe aan de functional spec met
acceptatiecriteria, randgevallen en datamodel. Beveiligingsuitgangspunt
expliciet: mobileSecret in URL-fragment en HttpOnly desktop-cookie zodat geheim
materiaal nooit in URL-paden of access logs belandt.

Lars-persona krijgt de bijbehorende use-case (publieke/geleende laptops bij
klantbezoek of familie) zodat de feature een herkenbare aanleiding heeft in v1.

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

* docs(ST-1001..1008): add M10 implementation plan + link from backlog

Volledig implementatie-plan per story (Bestanden / Stappen / Aandachtspunten /
Verificatie) in dezelfde stijl als M9. Citeert de patronen uit
docs/patterns/iron-session.md, route-handler.md en server-action.md, en
hergebruikt het LISTEN/NOTIFY-pattern uit app/api/realtime/solo/route.ts.

Bevat ook commit/branch-strategie per laag, reseed-stap voor de MCP-context, en
verificatie-acceptatie inclusief log-controle dat geheim materiaal niet in
access logs belandt.

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

* 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>

---------

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

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**