Live 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:

Operating Rules

1. Do not trust memory. Inspect the live service state every time.
2. 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.
3. 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.
4. Compare the live process checkout and commit against the commit you think is deployed.
5. If the database schema is involved, run migrations against the live service database, not the shell default.
6. 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.
7. 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.