---
name: teleo-vps-runtime-ops
description: 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:

```bash
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:

```sql
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:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

```bash
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`