# PR #77 VPS Auto-Deploy Runtime Readback

Observed UTC: `2026-07-12T00:11:37Z`

## Result

The VPS auto-deploy timer fast-forwarded
`/opt/teleo-eval/workspaces/deploy-infra` and
`/opt/teleo-eval/.last-deploy-sha` from merge `3b534abd` to PR #77 merge
`1a0abd882d00c1b58fe203f42de42d4eeea61cbf`.

This was a source-checkout synchronization, not a live Leo feature or process
change:

- The auto-deploy journal says `No Python changes - services not restarted`.
- The deploy checkout is clean on `main...github/main`.
- `leoclean-gateway.service` remains active/running on PID `2999690`, with
  `NRestarts=0` and start time `2026-07-10T03:47:11Z`.
- `teleo-kb-apply-worker.service` remains disabled, inactive, and dead, with
  no main process and no restart.
- `teleo-kb-apply-worker.timer` remains disabled, inactive, and dead, with no
  last trigger.

## Auto-Deploy Journal

```text
2026-07-12T00:08:03+00:00 New commits: 3b534abd -> 1a0abd88
2026-07-12T00:08:10+00:00 Syntax check passed
2026-07-12T00:08:11+00:00 Files synced
2026-07-12T00:08:11+00:00 No Python changes - services not restarted
2026-07-12T00:08:11+00:00 Deploy complete: 1a0abd8 Merge pull request #77 from living-ip/codex/gcp-canonical-clone-proof-20260711
```

## Claim Ceiling

PR #77 is present in the VPS deploy checkout, but the live Leo gateway did not
restart and the KB apply worker stayed disabled. This proves the hardening
scripts did not change the currently running VPS Leo. It does not prove a
future restart would preserve behavior, and it does not prove the hardened GCP
replay until that replay runs against the disposable Cloud SQL database.