teleo-infrastructure/.agents/skills/teleo-vps-runtime-ops/SKILL.md

name	description
teleo-vps-runtime-ops	Use for Leo VPS navigation, service health, Docker/Postgres readbacks, clone DB rehearsals, report sync, and runtime stability verification without changing live Leo behavior.

Teleo VPS Runtime Ops

Job

Navigate and verify the VPS safely, with exact readbacks and no surprise live-runtime changes.

Trigger Phrases

• "Leo on VPS"
• "check VPS stability"
• "navigate Teleo VPS"
• "leoclean service"
• "run DB rehearsal on VPS"
• "sync reports to VPS"

Known Surfaces

• Host: 77.42.65.182
• SSH user: root
• Local key path is available; never print private key contents.
• Service: leoclean-gateway.service
• DB container: teleo-pg
• DB: teleo
• Last retained count endpoints: claims 1837, sources 4145, evidence 4670, edges 4916, reasoning tools 17, proposals 26. Treat these as stale until refreshed.
• Profile reports: /home/teleo/.hermes/profiles/leoclean/kb_stage/reports/
• Deploy/source area: /opt/teleo-eval/workspaces/deploy-infra

Required Fresh Readbacks

Before claiming runtime state, read:

systemctl show leoclean-gateway.service -p ActiveState -p SubState -p MainPID -p NRestarts -p ExecMainStartTimestamp -p User -p WorkingDirectory

Before claiming DB state, use docker exec teleo-pg psql -U postgres -d teleo and query exact tables/rows. Wrap verification queries in begin transaction read only; ... rollback;.

Before claiming cleanup, query disposable DBs:

select datname from pg_database where datname like 'teleo%rehearsal%20260709' or datname like 'teleo%packet%20260709';

Auto-Deploy Semantics

teleo-auto-deploy.timer checks main every two minutes. A changed checkout HEAD or .last-deploy-sha does not by itself prove that Leo restarted or that canonical data changed. For each synchronized commit, also read:

1. journalctl -u teleo-auto-deploy.service for the exact deploy decision;
2. the commit delta under hermes-agent/leoclean-bin/ and hermes-agent/leoclean-skills/vps/;
3. gateway PID, start timestamp, and restart count;
4. teleo-kb-apply-worker.service enablement and active state;
5. canonical count endpoints in a read-only transaction.

Treat source checkout sync, runtime profile sync, service restart, permission migration, worker enablement, and canonical DB apply as separate state changes.

Mutating Boundaries

Allowed when needed:

• read-only service/DB inspection,
• disposable clone DB creation and drop for rehearsal,
• SQL rollback transactions,
• syncing report artifacts to the report directory,
• no-secret file checks.

Not allowed from this skill alone:

• restarting or changing the live Leo service,
• changing live runtime config,
• production DB commit/apply,
• exposing secret contents,
• deleting non-disposable data.

Rehearsal Rules

For DB rehearsals:

1. Capture production preflight counts.
2. Create a disposable DB from live state.
3. Run commit SQL only in the disposable DB.
4. Run postflight counts.
5. Run delete rollback if applicable.
6. Drop the disposable DB.
7. Verify production counts stayed unchanged.
8. Verify the disposable DB no longer exists.

For the guarded claim-bundle lifecycle, prefer the retained isolated wrapper:

scripts/run_approve_claim_isolated_container_canary.sh \
  --output docs/reports/leo-working-state-20260709/approve-claim-clone-canary-current.json

It must use a disposable unexposed PostgreSQL container, bind its receipt to current source hashes, compare exact payload projections and table deltas, read live count/service endpoints without writing them, and independently prove the container/workdir are absent afterward. Do not install the candidate code into the live Leo deploy merely to run this canary.

Blocker Format

Do not say "blocked" without:

• current_canary
• attempted_routes
• exact_gate
• clear_CTA
• next_non_user_action