# Staging runbook (Issue #20)

## Mål
Staging-miljø for WPP i Proxmox LXC, så release-klar kode kan deployes og smoke-testes sikkert.

## Miljø
- LXC: CT 143 (wpp-staging)
- App path: /opt/wpp-staging/app
- Service: wpp-staging.service
- Health endpoint: GET /healthz
- Database: MySQL (staging må ikke bruge SQLite, issue #133)
- Aktuel MVP UI-path: legacy host/player UI (`USE_SPA_UI=false`)

## MVP env-kontrakt
Staging skal mindst have følgende release-relevante env vars sat:

- `DB_ENGINE=django.db.backends.mysql`
- `CHANNEL_REDIS_HOST` + `CHANNEL_REDIS_PORT`
- `USE_SPA_UI=false`
- `WPP_SPA_ASSET_BASE=/static/frontend/angular/browser`
- `WPP_SPA_ASSET_VERSION=<release-tag eller sha>`

`USE_SPA_UI=true` er ikke del af den primære MVP release-gate. Det hører til separat cutover-verifikation.

## Verifikation
Kør fra devops-shell med Proxmox-adgang:

    ssh proxmox-lan "sudo -n pct status 143"
    ssh proxmox-lan "sudo -n pct exec 143 -- systemctl is-active wpp-staging.service"
    ssh proxmox-lan "sudo -n pct exec 143 -- curl -fsS http://127.0.0.1:8000/healthz"

Forventet:
- CT er running
- service er active
- healthz returnerer JSON med ok=true

Smoke-suite skriver nu et gameplay-artifact som JSON under `/opt/wpp-staging/app/artifacts/smoke/` (kan overrides via `ARTIFACT_DIR`/`ARTIFACT_FILE`).

Før manuel UI-smoke anbefales følgende bootstrap på staging-app'en:

    python manage.py bootstrap_mvp

Det sikrer en host-bruger og aktiv demo-kategori/spørgsmål uden ad hoc admin-oprettelse.

For den automatiske MVP bootstrap + smoke artifact flow bruges den kanoniske kommando:

    ./infra/staging/run_mvp_smoke.sh

Kommandoen kører i staging-CT via Proxmox, loader staging-env, kører `bootstrap_mvp`, og derefter `smoke_staging --artifact ...`.
Som default håndhæver den MVP-pathen `USE_SPA_UI=false`. Brug kun `ALLOW_SPA_CUTOVER=1` ved separat SPA-cutover.

For release-lignende "én kommando" execution bruges wrapperen:

    ./infra/staging/deploy_and_smoke_staging.sh [ref] [artifact-path]

Efter deploy validerer scriptet, at `DB_ENGINE` ikke er `django.db.backends.sqlite3` før migrations køres.

Deploy-scriptet bruger en release-candidate mappe og promoverer først til `/opt/wpp-staging/app` efter succesfuld `migrate`. Det reducerer schema/code drift ved afbrudte deploys (issue #130) og understøtter release-readiness gate (issue #90).

## Deploy (canonical execution context)
Deploy skal altid køres via Proxmox host over SSH (ikke fra lokal coder-shell med direkte sudo pct).

Officiel kommando:

    ./infra/staging/deploy_staging.sh [ref]

Anbefalet release-wrapper:

    ./infra/staging/deploy_and_smoke_staging.sh [ref] [artifact-path]

Scriptet bruger default PROXMOX_HOST=proxmox-lan og kører sudo -n pct exec på hosten.

Eksempler:

    ./infra/staging/deploy_staging.sh
    ./infra/staging/deploy_staging.sh v0.3.0
    PROXMOX_HOST=proxmox-prod ./infra/staging/deploy_staging.sh main
    ./infra/staging/deploy_and_smoke_staging.sh main
    ./infra/staging/deploy_and_smoke_staging.sh v0.3.0 /opt/wpp-staging/app/artifacts/smoke/release-smoke.json

## Smoke (canonical execution context)
MVP smoke skal køres via Proxmox host over SSH, ligesom deploy:

    ./infra/staging/run_mvp_smoke.sh

Eksempler:

    ./infra/staging/run_mvp_smoke.sh
    ./infra/staging/run_mvp_smoke.sh /opt/wpp-staging/app/artifacts/smoke/manual-smoke.json
    PROXMOX_HOST=proxmox-prod CT_ID=222 ./infra/staging/run_mvp_smoke.sh
    ALLOW_SPA_CUTOVER=1 ./infra/staging/run_mvp_smoke.sh

## Policy-kobling
Før deploy:
1. Bekræft at tester ikke er aktiv (ingen aktiv smoke-run).
2. Kør helst `./infra/staging/deploy_and_smoke_staging.sh` for release-kandidater.
3. Hvis wrapper ikke bruges: deploy til staging og kør derefter `./infra/staging/run_mvp_smoke.sh`.
4. Bekræft MVP UI-smoke på legacy UI (`/lobby/ui/host` + `/lobby/ui/player`).
5. Først derefter må release-tag oprettes (se docs/RELEASE_POLICY.md).