zerg-hosted-debug

# Zerg Hosted Debug Use this when the question is about a live hosted tenant, not local `make dev`. For hosted 502s, slow Runtime Host startup, large tenant SQLite files, WAL growth, or disk pressure, use the SQLite path in this skill before touching the database. Longhouse history is the product value; do not prune archived session logs as a recovery shortcut unless the maintainer approves data loss. ## Default Path Start with the repo helper: ```bash bash scripts/ops/hosted-session-debug.sh --subdomain <subdomain> --session <session-id> --limit 20 bash scripts/ops/hosted-session-debug.sh --subdomain <subdomain> --session <session-id> --logs bash scripts/ops/hosted-session-debug.sh --subdomain <subdomain> --session <session-id> --json ``` It does the right order automatically: - resolve the tenant via the control plane - query the tenant SQLite DB on the host data path - summarize `sessions`, `events`, runtime `session_observations`, `session_runtime_state`, and `session_turns` - summarize recent WriteSerializer pressure and request counts from tenant logs Prefer this over ad hoc `ssh` + guessed DB paths + nested heredoc quoting. ## Canonical Paths - Host data root: `/var/app-data/longhouse/<subdomain>` - Tenant container mount: `/data` - Tenant DB: `/data/longhouse.db` This is an explicit Longhouse exception on the runtime host; do not assume the generic VPS `/var/lib/docker/data/...` layout. ## Auth / Control Plane The helper expects `CONTROL_PLANE_ADMIN_TOKEN`...