SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillspawrrtal-live-ops

pawrrtal-live-ops

Data & analytics

View repository

Updated 10-16 07:24

About this skill

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 pawrrtal-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

  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, or bot tokens.
  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 or mocked provider tests are not enough to claim live behavior.
  7. After touching self-hosted runners for CI or verification, use pawrrtal-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.