# 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)

## 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`).

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]

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

## Policy-kobling
Før deploy:
1. Bekræft at tester ikke er aktiv (ingen aktiv smoke-run).
2. Deploy til staging skal lykkes.
3. Først derefter må release-tag oprettes (se docs/RELEASE_POLICY.md).