15f9133920
- Distinguish source synchronization from service, migration, worker, and database state changes. - Bound GCP claims to current VM, Cloud SQL inventory, logs, and serial evidence. - Keep the operating pack reliable with 14 skill validations and 809 passing tests. `.agents/skills/teleo-gcp-parity-ops/SKILL.md` `.agents/skills/teleo-infra-provenance/SKILL.md` `.agents/skills/teleo-kb-db-change-workflow/SKILL.md` `.agents/skills/teleo-leo-onboarding/SKILL.md` `.agents/skills/teleo-vps-runtime-ops/SKILL.md` `docs/reports/leo-working-state-20260709/current-truth-index.md` `docs/reports/leo-working-state-20260709/gcp-leo-runtime-observability-current.json` `docs/reports/leo-working-state-20260709/gcp-leo-runtime-observability-current.md` `docs/reports/leo-working-state-20260709/pr72-vps-auto-deploy-runtime-nonchange-current.json` `docs/reports/leo-working-state-20260709/pr72-vps-auto-deploy-runtime-nonchange-current.md` `docs/reports/leo-working-state-20260709/skill-pack-manifest.json` `docs/reports/leo-working-state-20260709/skill-pack-readme.md` `tests/test_repo_skill_pack.py`
120 lines
3.8 KiB
Markdown
120 lines
3.8 KiB
Markdown
---
|
|
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.
|
|
|
|
## Blocker Format
|
|
|
|
Do not say "blocked" without:
|
|
|
|
- `current_canary`
|
|
- `attempted_routes`
|
|
- `exact_gate`
|
|
- `clear_CTA`
|
|
- `next_non_user_action`
|