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

Issue #251 — Release-often lane for SPA MVP (3 micro-PR batches)

Formål

Bryde SPA MVP-arbejdet op i 3 merge-klare micro-PRs med tydelige acceptance criteria, så vi kan levere værdi oftere, reducere review-risiko og holde main grøn.

Scope (issue-bound)

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
  • rollback-note
  • "ikke med i denne batch" for at undgå scope creep
• Batch-rækkefølgen er dependencies-sikker (batch B bygger på batch A, batch C på batch B).
• Hver batch kan merges/releaseres uafhængigt uden at blokere drift på main.
• Planen linker til konkrete dev-opgaver for lane-kørsel.

Batch-plan (merge-klare micro-PRs)

Batch A — SPA shell + routing baseline

Mål: Et stabilt SPA-skelet med route-struktur og guard-basics.

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

• 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).

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 B — Session-state + host/player sync MVP

Mål: Korrekt synkronisering af session-state mellem host og spillerklient.

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

• 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.

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

• 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.

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.