docs(issue-251): make 3-batch SPA lane execution-ready

docs/ISSUE-251-RELEASE-OFTEN-SPA-MVP-BATCH-PLAN.md

@@ -9,81 +9,116 @@ Denne plan dækker kun planlægning/acceptance for den kommende SPA MVP-lane.
 Implementering af de konkrete features sker i efterfølgende PRs.
 
 ## Hard acceptance criteria for issue #251
-- [ ] Der findes en dokumenteret plan med præcis **3 batches**.
-- [ ] Hver batch har:
-  - [ ] mål og afgrænsning
-  - [ ] konkrete leverancer (kodeområder)
-  - [ ] test/checks før merge
-  - [ ] "ikke med i denne batch" for at undgå scope creep
-- [ ] Batch-rækkefølgen er dependencies-sikker (batch 2 bygger på batch 1, batch 3 på batch 2).
-- [ ] Hver batch kan merges uafhængigt uden at blokere drift på `main`.
+- [x] Der findes en dokumenteret plan med præcis **3 batches**.
+- [x] Hver batch har:
+  - [x] mål og afgrænsning
+  - [x] konkrete leverancer (kodeområder)
+  - [x] test/checks før merge
+  - [x] rollback-note
+  - [x] "ikke med i denne batch" for at undgå scope creep
+- [x] Batch-rækkefølgen er dependencies-sikker (batch B bygger på batch A, batch C på batch B).
+- [x] Hver batch kan merges/releaseres uafhængigt uden at blokere drift på `main`.
+- [x] Planen linker til konkrete dev-opgaver for lane-kørsel.
 
 ## Batch-plan (merge-klare micro-PRs)
 
-### Batch 1 — SPA shell + routing baseline
+### Batch A — SPA shell + routing baseline
 **Mål:** Et stabilt SPA-skelet med route-struktur og guard-basics.
 
-**Leverancer**
-- Frontend shell-komponenter og route-konfiguration for host/player entrypoints.
-- Baseline route guards (kun ikke-destruktive sikkerhedschecks).
-- Feature-flag/kompatibilitet så eksisterende flow ikke brydes.
+**Leverancer (kodeområder)**
+- `frontend/angular/src/app/app.routes.ts` (host/player entry routes + fallback)
+- `frontend/angular/src/app/session-route-context.ts` (baseline route guards)
+- `frontend/angular/src/app/app.component.*` (shell-nav + route outlet wiring)
+- `lobby/templates/lobby/spa_shell.html` (kompatibel shell-entry ved SPA cutover)
+
+**Done-kriterier**
+- Host- og player-entry routes kan åbnes uden runtime-fejl i samme SPA-shell.
+- Route guards afviser ugyldige parametre deterministisk (ingen hard crash).
+- `USE_SPA_UI=false` fortsætter med legacy-flow uden regression.
 
 **Checks før merge**
-- Frontend build/lint/test grøn.
-- Smoke: host route og player route kan åbnes uden runtime-fejl.
-- Ingen regression i eksisterende server-rendered/default flow.
+- `cd frontend/angular && npm test -- --run src/app/app.routes.spec.ts src/app/session-route-context.spec.ts`
+- `cd frontend/angular && npm run build`
+- Manual smoke: `/lobby/ui/host` + `/lobby/ui/player` (både `USE_SPA_UI=false` og `true`).
 
-**Ikke med i batch 1**
+**Rollback-note**
+- Sæt `USE_SPA_UI=false` og redeploy; verificér legacy routes svarer 200.
+
+**Ikke med i batch A**
 - Fuld gameplay-state synkronisering.
 - Audio/polish og i18n finpudsning ud over baseline wiring.
 
 ---
 
-### Batch 2 — Session-state + host/player sync MVP
+### Batch B — Session-state + host/player sync MVP
 **Mål:** Korrekt synkronisering af session-state mellem host og spillerklient.
 
-**Leverancer**
-- Klient-state wiring til eksisterende backend events/endpoints.
-- Deterministiske overgangstilstande for centrale faser (join/lobby/round/score).
-- Guardrails mod race conditions i route/session handoff.
+**Leverancer (kodeområder)**
+- `frontend/angular/src/app/features/host/host-shell.component.ts`
+- `frontend/angular/src/app/features/player/player-shell.component.ts`
+- `frontend/src/api/angular-client.ts` (MVP-kald for status/phase-overgange)
+
+**Done-kriterier**
+- Host handlinger (`start`, `show`, `mix`, `score`, `next`, `finish`) afspejles hos player uden side-reload.
+- Session-phase transitions er deterministiske i happy-path (`lobby -> question -> score -> next/finish`).
+- Guardrails reducerer race-condition regressions ved hurtige phase-skift.
 
 **Checks før merge**
-- Relevante unit/integration tests for state transitions grøn.
-- Smoke: host handling afspejles hos spiller indenfor forventet latenstid.
-- Ingen 500/JS runtime errors i happy-path MVP flow.
+- `cd frontend/angular && npm test -- --run src/app/features/host/host-shell.component.spec.ts src/app/features/player/player-shell.component.spec.ts`
+- `cd frontend && npm test -- --run tests/angular-api-client.test.ts`
+- Manual smoke: host action -> player phase sync indenfor forventet latenstid.
 
-**Ikke med i batch 2**
+**Rollback-note**
+- Slå `USE_SPA_UI=false`, redeploy, og kør hurtig gameplay-smoke i legacy flow.
+
+**Ikke med i batch B**
 - Avanceret UX-polish/animation.
 - Udvidet observability udenfor MVP-kritiske logs.
 
 ---
 
-### Batch 3 — UX hardening + release readiness
-**Mål:** Gøre SPA MVP release-klar med fokus på stabilitet og driftssikkerhed.
+### Batch C — Lobby/join/start minimal flow + release readiness
+**Mål:** Gøre SPA MVP release-klar med fokus på stabilitet og driftssikkerhed omkring det minimale flow.
 
-**Leverancer**
-- Error/empty/loading states for kritiske skærme.
-- Dokumenteret smoke-run + opdaterede release-noter/changelog input.
-- Endelig cutover-checkliste for MVP-lane.
+**Leverancer (kodeområder)**
+- `frontend/angular/src/app/i18n-mvp-flow-smoke.spec.ts` + relevante shell-tests
+- `docs/UI_SMOKE.md` + `docs/STAGING_GAMEPLAY_SMOKE_ARTIFACT.md`
+- `CHANGELOG.md` release-input for SPA MVP lane
+
+**Done-kriterier**
+- End-to-end minimal flow (`lobby -> join -> start`) er dokumenteret PASS i SPA.
+- Fejl-/empty-/loading states for flowets kritiske skærme er verificeret.
+- Driftsteam kan udføre cutover + rollback uden tvetydighed.
 
 **Checks før merge**
-- End-to-end MVP smoke-pass (host + mindst én spiller).
-- Definerede fallback-paths ved manglende data/event-delay verificeret.
-- Release artefakter opdateret (relevant docs/changelog-input).
+- `cd frontend/angular && npm test -- --run src/app/i18n-mvp-flow-smoke.spec.ts`
+- `python manage.py test lobby.tests.LobbyFlowTests`
+- Opdateret staging-smoke artifact med UTC tidsstempler og gate-resultat.
 
-**Ikke med i batch 3**
+**Rollback-note**
+- Brug eksisterende playbook i `docs/spa-cutover-flag.md` (`USE_SPA_UI=false` + asset-version rollback).
+
+**Ikke med i batch C**
 - Post-MVP featureudvidelser.
 - Større refactors uden direkte release-værdi.
 
+## Rækkefølge og parallel-kørsel
+- **Dependency-rækkefølge:** A -> B -> C.
+- **Kan køres parallelt uden konflikt:**
+  - Test-/doc-forberedelse til C kan startes parallelt med B (ingen blokering af runtime-kode), men merges først efter B.
+  - Drift-smoke templates kan opdateres tidligt, så længe de ikke ændrer runtime-adfærd.
+- **Må ikke køre parallelt:**
+  - Runtime routing/guard ændringer i A og session-sync logik i B på samme filer uden feature-flag koordinering.
+
+## Konkret lane-opgavebinding (dev-opgaver)
+- Batch A PR: `feat/issue-251-batch-1-spa-shell-routing`
+- Batch B PR: `feat/issue-251-batch-2-session-sync`
+- Batch C PR: `feat/issue-251-batch-3-lobby-join-start-release-readiness`
+
+Hver PR skal linke tilbage til issue #251 og inkludere test-evidence + rollback-check.
+
 ## Merge-gate for alle 3 batches
 - Små PRs (mål: reviewbar størrelse, helst < ~300 netto-linjer når muligt).
 - Grøn CI/checks før review-request.
 - Tydelig PR-beskrivelse med: scope, test evidence, out-of-scope.
 - Ingen skjulte sideeffekter på tværs af apps/domæner.
-
-## Foreslået branch/PR navngivning
-- `feat/issue-251-batch-1-spa-shell-routing`
-- `feat/issue-251-batch-2-session-sync`
-- `feat/issue-251-batch-3-ux-hardening-release`
-
-Denne issue-PR (#251) er plan-PRen, som gør lane-kørsel merge-klar.