teleo-infrastructure/docs/reports/leo-working-state-20260709/pr77-vps-auto-deploy-runtime-nonchange-current.md

1.6 KiB

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

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.