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.

To prove that Leo itself can inspect one lifecycle state through the real GatewayRunner while remaining bound to a disposable full-data clone, run the checkpoint on the VPS as teleo while that clone exists:

sudo -u teleo install -d -m 700 /home/teleo/leo-checkpoint-reports
sudo -u teleo HOME=/home/teleo \
  /home/teleo/.hermes/hermes-agent/venv/bin/python \
  scripts/run_leo_clone_bound_handler_checkpoint.py \
  --container <disposable-container> \
  --db teleo \
  --prompt-id <stable-id> \
  --prompt "<m3taversal-style KB question>" \
  --expected-state approved \
  --copy-model-auth \
  --output /home/teleo/leo-checkpoint-reports/leo-clone-bound-checkpoint.json

The supplied clone must have Docker label com.livingip.leo.checkpoint=disposable, network mode none, no published ports, no mount source shared with production, and a PostgreSQL system identifier distinct from production. The harness resolves the name once, pins all operations to the full container ID, and fails if the name is rebound.

--copy-model-auth copies only auth.json into a private UUID-scoped profile and binds only the configured provider's env-backed credential in memory. The receipt records provider/variable names, never credential values or hashes. The gateway runs in a dedicated process group with no delivery adapters and only skills_list, skill_view, and a terminal handler restricted to the temporary clone-bound wrapper's read-only verbs. The terminal subprocess must not inherit the model credential. A timeout must terminate the child process group before the profile is removed.

The checkpoint must observe at least one successful teleo-kb call bound to the supplied container/database, remove the profile, and prove production row counts plus row-content fingerprints, gateway state, and live bridge hashes are unchanged. Every model tool call must be in the allowlist and every KB call must complete successfully for a clean pass. A correct answer after a failed call and retry is recovered behavior, not a clean reliability pass. The checkpoint does not review, approve, apply, restart, post to Telegram, or mutate production.

After that read-only checkpoint is clean, prove the lower-level pending-to-canonical lifecycle in the same kind of disposable clone:

sudo -u teleo HOME=/home/teleo \
  /home/teleo/.hermes/hermes-agent/venv/bin/python \
  scripts/run_leo_clone_lifecycle_checkpoint.py \
  --container <disposable-container> \
  --db teleo \
  --copy-model-auth \
  --operator-review \
  --guarded-apply \
  --output /home/teleo/leo-checkpoint-reports/leo-clone-lifecycle-checkpoint.json

This command gives Leo only one deterministic staging verb. The harness, not Leo, owns review and guarded apply. A pass requires exact structured receipts for conversation memory, pending, approved-but-unapplied, and applied state; exact linked claim/source/evidence rows; an isolated handler reopen using the same persisted session; zero rejected or nonzero terminal calls; and unchanged production DB fingerprints, service state, and live bridge hashes. It is a mutation primitive, not proof that Leo can extract knowledge from arbitrary documents or tweets.

For the real source-composition checkpoint, first create a fresh full-data clone with the same disposable label/network/mount rules, then install the gate and separated ephemeral clone credentials into a private run directory:

sudo -u teleo HOME=/home/teleo \
  /home/teleo/.hermes/hermes-agent/venv/bin/python \
  scripts/bootstrap_clone_kb_gate.py \
  --container <fresh-disposable-container> \
  --db teleo \
  --output-dir <private-run-directory>

The bootstrap must verify both kb_review and kb_apply logins and emit only credential file paths, never secret values or hashes. Then run:

sudo -u teleo HOME=/home/teleo \
  /home/teleo/.hermes/hermes-agent/venv/bin/python \
  scripts/run_leo_clone_composition_checkpoint.py \
  --container <fresh-disposable-container> \
  --db teleo \
  --copy-model-auth \
  --operator-review \
  --guarded-apply \
  --review-secrets-file <private-run-directory>/kb-review.env \
  --apply-secrets-file <private-run-directory>/kb-apply.env \
  --output <private-run-directory>/reports/composition-current.json

A pass requires model-driven dedupe search and extraction from supplied source bytes, exact source hashes and excerpts, linked claims/evidence/conflict edges, no row change before staging, deterministic normalization, separated review and apply, exact clone deltas, a new handler process reasoning over exact canonical rows without supplied IDs, session-marker recall, nonce-bound tool receipts, unchanged production DB/service/bridge state, and complete clone/profile/secret cleanup. The retained current receipt is docs/reports/leo-working-state-20260709/leo-source-composition-clone-checkpoint-current.json. It is not Telegram-visible proof and does not authorize production apply.

Blocker Format

Do not say "blocked" without:

• current_canary
• attempted_routes
• exact_gate
• clear_CTA
• next_non_user_action