| name | live-ops |
| description | Operate Pawrrtal as a live service: prove the running commit, local origins, Cloudflared public URL, database schema, Telegram channel, and shutdown state. Use when checking whether Pawrrtal is live, deployed, reachable, healthy, broken in Telegram, safe to restart, or safe to take down. |
| stages | ["debug","deploy"] |
| benefits-from | ["paw","systematic-debugging","diagnose","cloudflared-tunnel-ops"] |
Pawrrtal Live Ops
Use this skill when the question is about the real running Pawrrtal service, not just the code in the checkout. The rule is: live process, live environment, live logs, live HTTP checks, then code.
How It Works
Treat the running service as authoritative. The local shell may be on the wrong branch, may have the wrong DATABASE_URL, or may run a different Paw CLI profile than the user-facing service.
On the VPS production deployment, the authoritative unit is usually root
pawrrtal.service with working directory
/mnt/HC_Volume_105512717/deploy/pawrrtal. The older user unit
pawrrtal-dev.service is a dev-service fallback only; do not assume it exists
or owns production unless live checks prove it.
Cookbook
Read the relevant cookbook before acting:
| Task | Cookbook | Use When |
|---|
| Live audit | cookbook/live-audit.md | Prove what is running and whether local/public origins are healthy. |
| Functional verification | cookbook/verify.md | Prove user-visible flows such as login, chat, providers, and frontend checks. |
| Telegram diagnosis | cookbook/telegram.md | Telegram receives no reply, commands fail, polling/webhook is suspect, or bindings look wrong. |
| Runner operations | runner-ops skill | Start, stop, lock, clean, or inspect self-hosted GitHub Actions runners. |
| Shutdown | cookbook/take-down.md | Stop Pawrrtal cleanly, disable it, or prove it is down. |
Operating Rules
- Do not trust memory. Inspect the live service state every time.
- Do not print tokens, credential JSON, origin certs, database URLs, service tokens, bot tokens, generated passwords, or reset passwords. Do not send passwords through Telegram or another chat channel as an ops shortcut.
- Prefer
paw for user-visible verification, but if paw fails before HTTP due to local env drift, switch to live process logs and raw HTTP checks.
- Compare the live process checkout and commit against the commit you think is deployed.
- If the database schema is involved, run migrations against the live service database, not the shell default.
- Use real provider/channel/browser proof when the user-visible claim depends on real integrations. Simulated Telegram, direct outbound sends, or mocked provider tests are not enough to claim live inbound behavior.
- After touching self-hosted runners for CI or verification, use
runner-ops and prove runner location, labels, processes, services, and disk state.
Fast Triage
For most incidents, run these in order:
ROOT=${PAWRRTAL_ROOT:-/mnt/HC_Volume_105512717/deploy/pawrrtal}
cd "$ROOT"
git rev-parse --abbrev-ref HEAD
git rev-parse HEAD
git status --short
systemctl status pawrrtal.service --no-pager || systemctl --user status pawrrtal-dev.service --no-pager
ss -ltnp '( sport = :8000 or sport = :3000 or sport = :53001 )'
curl -fsS http://127.0.0.1:8000/api/v1/health
curl -fsS http://127.0.0.1:8000/api/v1/health/ready
If sandbox-local curl cannot reach loopback while systemd logs show the host
service is bound, rerun the HTTP probes at host level before declaring the app
down. If Telegram is the complaint, go directly to
cookbook/telegram.md after the service status and
health check.
