Merge pull request #73 from living-ip/codex/teleo-skill-pack-live-truth-20260710

Teach Teleo skills current VPS and GCP runtime truth

.agents/skills/teleo-gcp-parity-ops/SKILL.md

@@ -15,6 +15,8 @@ Control-plane inventory alone is not database or Leo parity.
 - Project: `teleo-501523` (`Teleo`).
 - Authenticated Console account: redacted `b***@livingip.xyz` via `authuser=5`.
 - VM: `teleo-prod-1`, running in `europe-west6-a`.
+- VM shape: Debian 12, `e2-standard-4`, 4 vCPU, 16 GB; OS Login metadata is
+  present. Treat the displayed API scope as metadata, not IAM authorization.
 - Cloud SQL: exactly one instance, `teleo-pgvector-standby`.
 - Database engine: PostgreSQL `16.14`, Enterprise.
 - Region/zone: `europe-west6` / `europe-west6-c`, single-zone.
@@ -22,12 +24,21 @@ Control-plane inventory alone is not database or Leo parity.
 - Connection name: `teleo-501523:europe-west6:teleo-pgvector-standby`.
 - Cloud SQL Studio loads, but the observed session exposes no enabled existing
   IAM DB principal and selects built-in password authentication.
+- Cloud Logging has guest/platform logs but zero seven-day entries matching
+  `leoclean`, `hermes`, `gateway`, `postgres`, or `teleo-kb`; Ops Agent is not
+  installed.
+- Read-only serial output is current through `2026-07-10T15:57:54Z`. It proves
+  recurring successful `leoclean-cloudsql-memory-sync.service` cycles. The last
+  exact `leoclean-gcp-prod-parallel.service` lifecycle event in the retained
+  buffer is a Hermes start on July 9 with no later exact stop/failure. This is
+  not a current PID, process, or deployed-SHA readback.
 
 Read these before refreshing:
 
 - `docs/reports/leo-working-state-20260709/gcp-cloud-sql-t3-live-readonly-current.json`
 - `docs/reports/leo-working-state-20260709/gcp-cloudsql-studio-parity-gate-current.json`
 - `docs/reports/leo-working-state-20260709/gcp-parallel-delegation-current.json`
+- `docs/reports/leo-working-state-20260709/gcp-leo-runtime-observability-current.json`
 
 ## Browser Rule
 
@@ -84,5 +95,7 @@ sanitized results, and close the agent-created tab.
 ## Claim Ceiling
 
 Current proof covers the GCP project, VM, Cloud SQL instance, health, version,
-and private routing surface. It does not cover DB contents, VPS-vs-GCP schema or
+private routing surface, and bounded serial unit activity. It does not prove
-row parity, application connectivity, GCP Leo behavior, or cutover.
+current gateway PID/restarts, deployed SHA, profile, model/auth, Telegram bot
+identity, selected canonical DB, DB contents, VPS-vs-GCP schema/row parity,
+safe no-post Cory answers, or cutover.

.agents/skills/teleo-infra-provenance/SKILL.md

@@ -33,6 +33,8 @@ Prevent incorrect assumptions about where Leo/Teleo code, runtime state, DB stat
 
 - Repo-local evidence pack: `docs/reports/leo-working-state-20260709/`
 - VPS deploy/source area: `/opt/teleo-eval/workspaces/deploy-infra`
+- VPS deploy stamp: `/opt/teleo-eval/.last-deploy-sha`
+- Auto-sync: `teleo-auto-deploy.timer` checks `main` every two minutes.
 - VPS profile reports: `/home/teleo/.hermes/profiles/leoclean/kb_stage/reports/`
 - Live service: `leoclean-gateway.service`
 
@@ -42,13 +44,19 @@ Before claiming provenance:
 
 1. `git -C <path> status --short --branch`
 2. `git -C <path> rev-parse HEAD`
-3. service `WorkingDirectory` and `User`
+3. `/opt/teleo-eval/.last-deploy-sha`
-4. file checksum if comparing script deployment
+4. latest `teleo-auto-deploy.service` journal decision
-5. latest retained report artifact timestamp
+5. service PID, start timestamp, restart count, `WorkingDirectory`, and `User`
+6. commit delta and file checksums for the runtime paths being compared
+7. latest retained report artifact timestamp
 
 ## Common Failure
 
-Do not say the repo/deploy split is the direct cause of a Leo outage unless evidence ties it to the active failure. The split can be a reproducibility/parity risk without being the immediate runtime cause.
+Do not say the repo/deploy split is the direct cause of a Leo outage unless
+evidence ties it to the active failure. The split can be a
+reproducibility/parity risk without being the immediate runtime cause. A commit
+present in the deploy checkout or stamp does not prove a gateway restart,
+runtime-profile change, permission migration, worker enablement, or DB apply.
 
 ## Output
 

.agents/skills/teleo-kb-db-change-workflow/SKILL.md

@@ -96,8 +96,14 @@ The retained generic and Helmer v3 receipts each pass `37/37`. Generic proves
 restarts during those runs.
 
 This proves current-source behavior in disposable PostgreSQL and unchanged live
-count/service endpoints. It does not prove byte-for-byte live content, code
+count/service endpoints. PR #72 source later auto-synchronized to the VPS
-deployment, the production permission migration, or Helmer application.
+checkout without a gateway restart or profile-source delta; the production
+permission migration was not applied, the apply worker remained disabled and
+inactive, and Helmer remained unapplied. Checkout synchronization alone is not
+proof of any of those later state changes. It does not prove byte-for-byte live
+content.
 
 Read `docs/reports/leo-working-state-20260709/approve-claim-clone-canary-current.md`
 and both JSON receipts before making a current claim.
+Read `docs/reports/leo-working-state-20260709/pr72-vps-auto-deploy-runtime-nonchange-current.md`
+before describing the VPS deployment state.

.agents/skills/teleo-leo-onboarding/SKILL.md

@@ -24,8 +24,9 @@ Orient the worker before action. Build a current, proof-linked understanding of
 - Leo is the operator-facing agent expected to answer in Telegram, remember operator context, reason from canonical KB state, stage concrete KB changes, and support approved changes becoming canonical DB rows with proof.
 - The immediate July 9 issue is not generic bot liveness. It is Cory/m3taversal's expectation that approved KB changes move beyond proposal state when appropriate.
 - The VPS is the currently proven Telegram-visible Leo surface.
-- GCP is a separate lane. Project, VM, and private Cloud SQL inventory are now
+- GCP is a separate lane. Project, VM, private Cloud SQL inventory, and bounded
-  current; DB contents, runtime parity, Cory answers, and cutover are not.
+  serial unit activity are current. Current gateway PID/SHA/model/auth,
+  canonical DB rows, Cory answers, and cutover are not proven.
 
 ## Read First
 
@@ -38,6 +39,7 @@ From the repo root, read:
 5. `docs/reports/leo-working-state-20260709/approve-claim-clone-canary-current.md`
 6. `docs/reports/leo-working-state-20260709/gcp-cloud-sql-t3-live-readonly-current.md`
 7. `docs/reports/leo-working-state-20260709/gcp-cloudsql-studio-parity-gate-current.md`
+8. `docs/reports/leo-working-state-20260709/gcp-leo-runtime-observability-current.md`
 
 ## Required Status Split
 

.agents/skills/teleo-vps-runtime-ops/SKILL.md

@@ -49,6 +49,22 @@ 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:

docs/reports/leo-working-state-20260709/current-truth-index.md

@@ -123,6 +123,8 @@ Use this file before making status claims. Prefer fresh VPS/GCP readbacks when c
 - Current GCP Cloud SQL live inventory JSON: `docs/reports/leo-working-state-20260709/gcp-cloud-sql-t3-live-readonly-current.json`
 - Current GCP Cloud SQL Studio parity gate: `docs/reports/leo-working-state-20260709/gcp-cloudsql-studio-parity-gate-current.md`
 - Current GCP Cloud SQL Studio parity gate JSON: `docs/reports/leo-working-state-20260709/gcp-cloudsql-studio-parity-gate-current.json`
+- Current GCP Leo runtime observability: `docs/reports/leo-working-state-20260709/gcp-leo-runtime-observability-current.md`
+- Current GCP Leo runtime observability JSON: `docs/reports/leo-working-state-20260709/gcp-leo-runtime-observability-current.json`
 - Prior auth-capable GCP blocker: `docs/reports/leo-working-state-20260709/gcp-db-parity-current-blocker-20260709.json`
 
 ## Images
@@ -158,7 +160,7 @@ Use this file before making status claims. Prefer fresh VPS/GCP readbacks when c
 - The public Argus KB diagnostics HTTP probe passes from live `curl` payloads captured at `2026-07-10T02:47:53Z`: `3` approved proposals are visible (`14fa5ecc`, `ac036c9d`, `a64df080`), all are `approved_needs_apply_payload`, `worker_applyable_count=0`, and the endpoint is read-only. This supports Leo's expected answer that the approved KB work is not yet directly applyable/canonical, but it is not Docker/Postgres row-count or gateway-service proof.
 - The highest-risk direct-claim cases are now green at handler level: `DC-02` recognizes approved Helmer staging row `a64df080-8502-42e2-98f4-9bbdecb8da73` as approved/unapplied, `DC-03` says the decision-matrix path is not shipped while matrix tables are absent, `DC-04` avoids a single-cause document pointer diagnosis, `DC-05` separates staging demo from authorized canonical apply, and `DC-06` separates `SOUL.md` runtime edits from canonical DB identity.
 - A strict canonical `add_edge` apply canary is live-proven.
-- The repo-owned normal apply path now supports an atomic, insert-only `approve_claim` bundle behind separate `kb_review` and `kb_apply` credentials, a DB-role-to-reviewer principal mapping, and an immutable approval snapshot. Final source-bound isolated-container receipts pass `37/37` for both the generic bundle (`2` claims, `2` sources, `2` evidence rows, `1` edge, `1` reasoning tool) and the real losslessly normalized Helmer bundle (`5/13/17/7/1`). They prove exact payload-controlled projections and table deltas, reviewer/apply separation, denied direct proposal/evidence mutation, stale-payload refusal before canonical writes, replay refusal, source-hash rollback, exact agent/external-claim seeding, hardened role/function/ACL state, and independent inner/outer cleanup. Read-only live count endpoints stayed `1837/4145/4670/4916/17/26` and the gateway stayed PID `2999690`/`NRestarts=0`; this is not a byte-for-byte live-row comparison. The code and production permission migration are not deployed, and Helmer remains unapplied on production.
+- The repo-owned normal apply path now supports an atomic, insert-only `approve_claim` bundle behind separate `kb_review` and `kb_apply` credentials, a DB-role-to-reviewer principal mapping, and an immutable approval snapshot. Final source-bound isolated-container receipts pass `37/37` for both the generic bundle (`2` claims, `2` sources, `2` evidence rows, `1` edge, `1` reasoning tool) and the real losslessly normalized Helmer bundle (`5/13/17/7/1`). They prove exact payload-controlled projections and table deltas, reviewer/apply separation, denied direct proposal/evidence mutation, stale-payload refusal before canonical writes, replay refusal, source-hash rollback, exact agent/external-claim seeding, hardened role/function/ACL state, and independent inner/outer cleanup. PR #72 source later auto-synchronized to the VPS checkout and deploy stamp at merge commit `771679061f0a0b6463fb7d9cf530eb9d2d4e5440`; the timer journal says no Python changes and no service restart, the commit had no delta under the Leo profile source paths, the gateway stayed PID `2999690`/`NRestarts=0`, the apply worker stayed disabled/inactive, and read-only count endpoints remained `1837/4145/4670/4916/17/26`. This is a source checkout sync, not proof that the production permission migration ran, the worker was enabled, canonical rows changed, or byte-for-byte live content stayed equal. Helmer remains unapplied on production. See `pr72-vps-auto-deploy-runtime-nonchange-current.md`.
 - Helmer 7 Powers is full-coverage packet and ledger clone-proven, not production-applied.
 - Mapped rich approved proposal packet is clone/rehearsal-proven for the supported subset, not production-applied.
 - The strategy-anchor companion write for mapped rich proposal `14fa5ecc` is clone-proven and reversible, not production-applied.
@@ -182,3 +184,4 @@ Use this file before making status claims. Prefer fresh VPS/GCP readbacks when c
 - Latest cleanup readback found no leftover rehearsal/clone/staging database names on the VPS Postgres container and did not mutate production DB or post to Telegram.
 - A live Telegram regression canary should be rerun after any production apply; no production apply has been authorized or executed.
 - GCP control-plane Chrome readback now proves project `teleo-501523`, running VM `teleo-prod-1` in `europe-west6-a`, and one available private-only PostgreSQL `16.14` Cloud SQL instance, `teleo-pgvector-standby`, in `europe-west6-c`. Cloud SQL Studio is reachable but exposes no enabled existing IAM database principal and requires built-in password authentication; no credential was submitted and no SQL ran. Database-row/runtime/DC-01-through-DC-06 parity therefore remains unproven. The exact next gate is an already-existing authenticated Studio principal or a separately authorized IAM/database-user enablement window.
+- GCP Console observability now separately proves `teleo-prod-1` is running and that serial output through `2026-07-10T15:57:54Z` contains recurring successful `leoclean-cloudsql-memory-sync.service` cycles. The latest exact `leoclean-gcp-prod-parallel.service` lifecycle event in the retained serial buffer is a Hermes start on July 9 with no later exact stop/failure. Cloud Logging has `92` guest/platform records over seven days but zero matches for `leoclean`, `hermes`, `gateway`, `postgres`, or `teleo-kb`, and Ops Agent is absent. This is bounded unit-activity evidence, not current PID/restart/SHA/profile/model/auth/Telegram/DB-row parity; no-post Cory execution remains unsafe and was not attempted. The agent-created Console tab was closed and no GCP/DB/service/IAM/deploy/credential/Telegram mutation occurred.

docs/reports/leo-working-state-20260709/gcp-leo-runtime-observability-current.json

@@ -0,0 +1,259 @@
+{
+  "schema": "teleo.gcpLeoRuntimeObservability.v1",
+  "captured_at_utc": "2026-07-10T16:03:00Z",
+  "source_thread_id": "019f47af-f2cc-7c10-b928-a9283afa2621",
+  "current_canary": "Open GCP VM observability and Logs Explorer for teleo-prod-1 with authuser=5 and retain current read-only Leo runtime evidence or a precise no-log result.",
+  "required_tier": "T3_live_readonly",
+  "current_tier": "T3_live_readonly",
+  "status": "done_verified",
+  "overall_runtime_parity_status": "partial_unproven",
+  "strongest_claim_allowed": "teleo-prod-1 is currently RUNNING and its read-only serial-port output is current through 2026-07-10T15:57:54Z. Serial evidence proves recurring successful leoclean Cloud SQL memory-sync unit activity and shows the latest exact leoclean GCP gateway unit lifecycle event was a Hermes service start on 2026-07-09T07:00:04Z with no later exact stop or failure in the retained serial buffer. Cloud Logging has guest-agent/platform logs but zero seven-day entries matching leoclean, hermes, gateway, postgres, or teleo-kb. This does not prove a current gateway PID, deployed repo SHA, profile, model/auth capability, Telegram bot identity, selected canonical DB backend, or safe no-post handler execution.",
+  "capture": {
+    "surface": "authenticated Google Cloud Console through Chrome",
+    "account": "b***@livingip.xyz",
+    "project_id": "teleo-501523",
+    "authuser": 5,
+    "cli_used": false,
+    "ssh_or_iap_used": false,
+    "cloud_shell_used": false,
+    "secret_values_captured": false,
+    "raw_serial_or_log_payload_retained": false
+  },
+  "instance": {
+    "name": "teleo-prod-1",
+    "instance_id": "6202458246232531966",
+    "status": "RUNNING",
+    "creation_time_ui": "2026-07-07 03:57:37 UTC+02:00",
+    "zone": "europe-west6-a",
+    "machine_type": "e2-standard-4",
+    "vcpus": 4,
+    "memory_gb": 16,
+    "cpu_platform": "Intel Broadwell",
+    "labels": [],
+    "deletion_protection": false,
+    "confidential_vm": false,
+    "shielded_vm": {
+      "secure_boot": false,
+      "vtpm": true,
+      "integrity_monitoring": true
+    },
+    "boot": {
+      "source_image": "debian-12-bookworm-v20260609",
+      "architecture": "X86_64",
+      "disk_name": "teleo-prod-1",
+      "disk_size_gb": 150,
+      "disk_type": "Balanced persistent disk",
+      "mode": "read_write",
+      "delete_with_instance": true,
+      "snapshot_policy": "teleo-daily-7d-snapshots",
+      "snapshot_schedule_ui": "daily between 03:00 and 04:00"
+    },
+    "network": {
+      "interface": "nic0",
+      "vpc": "teleo-staging-net",
+      "subnetwork": "teleo-staging-europe-west6",
+      "internal_ip": "10.60.0.3",
+      "external_ip": "34.65.143.148",
+      "external_ip_allocation": "ephemeral",
+      "network_tier": "Premium",
+      "ip_forwarding": false
+    },
+    "identity_and_access": {
+      "service_account_redacted": "sa-teleo-prod-vm@t***.iam.gserviceaccount.com",
+      "service_account_full_identity_retained": false,
+      "cloud_api_access_scope_ui": "Allow full access to all Cloud APIs",
+      "scope_is_not_iam_authorization_proof": true,
+      "os_login_metadata": true
+    }
+  },
+  "observability": {
+    "platform_metrics_present": [
+      "CPU utilization",
+      "network traffic",
+      "new connections",
+      "disk throughput",
+      "disk IOPS"
+    ],
+    "ops_agent": {
+      "installed": false,
+      "evidence": "The VM Observability page displayed Install Ops Agent and marked memory and disk-space utilization as requiring the Ops Agent.",
+      "installation_attempted": false
+    },
+    "vm_manager": {
+      "enabled": false,
+      "os_info_available": false,
+      "evidence": "OS Info displayed Enable VM Manager to view OS info.",
+      "enablement_attempted": false
+    },
+    "interactive_serial_console": {
+      "enabled": false,
+      "evidence": "Connect to serial console was disabled on the VM details page."
+    },
+    "serial_output_readable_without_enablement": true
+  },
+  "cloud_logging": {
+    "time_window": "P7D",
+    "timezone_ui": "CEST",
+    "base_query": "resource.type=\"gce_instance\"\nresource.labels.instance_id=\"6202458246232531966\"",
+    "base_result_count": 92,
+    "severity_counts": {
+      "INFO": 82,
+      "NOTICE": 5,
+      "DEFAULT": 4,
+      "ERROR": 1
+    },
+    "distinct_log_name_count": 7,
+    "visible_top_log_names": [
+      {
+        "name": "GCEGuestAgent",
+        "count": 53
+      },
+      {
+        "name": "GCEGuestAgentManager",
+        "count": 26
+      },
+      {
+        "name": "diagnostic-log",
+        "count": 4
+      },
+      {
+        "name": "compute.googleapis.com/shielded_vm_integrity",
+        "count": 3
+      }
+    ],
+    "combined_runtime_query_with_systemd": "resource.type=\"gce_instance\"\nresource.labels.instance_id=\"6202458246232531966\"\n(SEARCH(\"leoclean\") OR SEARCH(\"hermes\") OR SEARCH(\"gateway\") OR SEARCH(\"systemd\") OR SEARCH(\"postgres\") OR SEARCH(\"teleo-kb\"))",
+    "combined_runtime_query_result_count": 5,
+    "combined_result_summary": "Five INFO records, all boot-time systemd network/login/SSH initialization. No Leo application or agent record was present.",
+    "runtime_query_without_systemd": "resource.type=\"gce_instance\"\nresource.labels.instance_id=\"6202458246232531966\"\n(SEARCH(\"leoclean\") OR SEARCH(\"hermes\") OR SEARCH(\"gateway\") OR SEARCH(\"postgres\") OR SEARCH(\"teleo-kb\"))",
+    "runtime_query_without_systemd_result_count": 0,
+    "precise_no_log_result": "Over the full seven-day window, Cloud Logging contains zero entries for this exact VM matching leoclean, hermes, gateway, postgres, or teleo-kb.",
+    "interpretation": "Guest/platform logs are ingested, but Leo application/systemd journal logs are not present in Cloud Logging. The missing Ops Agent is consistent with the absent application log stream, while read-only serial output independently contains Leo service events."
+  },
+  "serial_port_1_sanitized": {
+    "interactive_console_enabled": false,
+    "output_page_readable": true,
+    "text_bytes_observed": 1046328,
+    "line_count_observed": 3304,
+    "earliest_timestamp_in_loaded_output": "2026-07-09T04:00:21.793108Z",
+    "latest_timestamp_in_loaded_output": "2026-07-10T15:57:54.111434Z",
+    "relevant_unit_names": [
+      "leoclean-cloudsql-memory-sync.service",
+      "leoclean-gcp-prod-parallel.service"
+    ],
+    "term_facts": {
+      "leoclean": {
+        "matching_line_count": 3042,
+        "latest_timestamp": "2026-07-10T15:57:54.111434Z"
+      },
+      "hermes": {
+        "matching_line_count": 1881,
+        "latest_timestamp": "2026-07-10T15:57:54.111434Z"
+      },
+      "gateway": {
+        "matching_line_count": 38,
+        "latest_timestamp": "2026-07-10T12:14:52.972390Z"
+      },
+      "teleo-kb": {
+        "matching_line_count": 4,
+        "latest_timestamp": "2026-07-09T06:49:14.505121Z"
+      },
+      "postgres": {
+        "matching_line_count": 0,
+        "latest_timestamp": null
+      }
+    },
+    "cloudsql_memory_sync": {
+      "latest_finished_timestamp": "2026-07-10T15:57:54.094689Z",
+      "latest_started_timestamp": "2026-07-10T15:57:54.111434Z",
+      "latest_cycle_finished_successfully": true,
+      "description_from_safe_systemd_text": "Sync leoclean Hermes state database to the current Cloud SQL snapshot",
+      "claim": "The VM is currently executing a recurring leoclean memory-sync unit that completes successfully and starts its next cycle. This proves an existing host-to-Cloud-SQL sync path, not canonical teleo-kb DB selection or schema/count parity."
+    },
+    "gateway_unit": {
+      "exact_unit_matching_line_count": 30,
+      "latest_exact_unit_event": "started",
+      "latest_exact_unit_event_timestamp": "2026-07-09T07:00:04.363359Z",
+      "latest_exact_event_mentions_hermes": true,
+      "failed_events_in_exact_unit_sequence": 0,
+      "later_exact_stop_or_failure_present": false,
+      "claim": "The latest exact gateway-unit lifecycle record in the loaded serial buffer is a Hermes service start, with no later exact stop or failure. This is indirect liveness evidence only; it is not a current PID/systemctl/process readback."
+    },
+    "raw_lines_retained": false,
+    "secret_values_retained": false
+  },
+  "no_post_cory_handler_decision": {
+    "safe_to_run_from_this_evidence": false,
+    "handler_run_attempted": false,
+    "reason": "The Console proves VM and serial-service activity but does not prove the current gateway PID, deployed SHA, leoclean profile, model/auth booleans, Telegram token/identity state, selected canonical DB backend, or a no-write harness route.",
+    "missing_preconditions": [
+      "current process or systemd PID and restart readback",
+      "deployed repo SHA and deploy stamp on GCP",
+      "profile and model/provider names with auth-presence booleans",
+      "Telegram enabled/token-presence and local non-secret bot identity",
+      "selected DB backend plus before/after counts",
+      "verified no-post, no-profile-write, no-DB-write handler invocation and cleanup path"
+    ]
+  },
+  "vps_comparison_corrected": {
+    "deploy_checkout_and_stamp": "771679061f0a0b6463fb7d9cf530eb9d2d4e5440",
+    "fast_forward_observed_utc": "2026-07-10T15:53:13Z_to_2026-07-10T15:53:20Z",
+    "journal_readback": "No Python changes — services not restarted",
+    "leo_code_delta_in_merge": false,
+    "gateway": {
+      "main_pid": 2999690,
+      "nrestarts": 0,
+      "started_at_utc": "2026-07-10T03:47:11Z"
+    },
+    "db_count_tuple_as_supplied": "1837/4145/4670/4916/17/26",
+    "apply_worker": "disabled/inactive",
+    "interpretation": "This is source-checkout synchronization only, not a Leo runtime behavior change and not production permission migration/application."
+  },
+  "delivery_context": {
+    "repo_work": "merged_pr",
+    "pull_request": 72,
+    "gcp_deployment_status": "unproven",
+    "vps_source_checkout_synced": true,
+    "vps_live_leo_runtime_changed_by_pr": false,
+    "gcp_deployed_sha_proven": false,
+    "note": "PR #72 source synchronized to the VPS deploy checkout, but it did not restart or change the VPS Leo runtime. GCP deployment status is unproven because no GCP SHA was available."
+  },
+  "not_proven": [
+    "current leoclean gateway PID or NRestarts on GCP",
+    "current deployed repo SHA or deploy stamp on GCP",
+    "current leoclean profile path",
+    "current model/provider/auth capability booleans",
+    "current Telegram bot identity or token presence",
+    "selected canonical database/backend and row counts",
+    "safe no-post Cory handler execution",
+    "runtime parity with the corrected VPS baseline"
+  ],
+  "actions": [
+    "Opened the authenticated Compute Engine VM inventory and exact teleo-prod-1 details page.",
+    "Read current instance, machine, boot disk, networking, service-account, and metadata fields without entering edit mode.",
+    "Opened VM Observability and verified platform metrics plus absent Ops Agent.",
+    "Opened OS Info and verified VM Manager is not enabled without enabling it.",
+    "Opened Logs Explorer for the exact instance ID and ran seven-day read-only searches for leoclean, hermes, gateway, systemd, postgres, and teleo-kb.",
+    "Opened the already-readable serial-port-1 output without enabling interactive serial access and extracted only allowlisted unit/timestamp/count facts."
+  ],
+  "cleanup_readback": {
+    "browser_tab_finalized": true,
+    "browser_tab_disposition": "agent-created Console tab closed; no handoff tab kept",
+    "gcp_writes": 0,
+    "database_writes": 0,
+    "service_restarts": 0,
+    "deploys": 0,
+    "iam_changes": 0,
+    "credential_or_key_creation": 0,
+    "ssh_or_iap_sessions": 0,
+    "cloud_shell_sessions": 0,
+    "telegram_sends": 0,
+    "ops_agent_installations": 0,
+    "vm_manager_enablements": 0,
+    "serial_console_enablements": 0
+  },
+  "evidence_paths": [
+    "/Users/user/Documents/Codex/2026-07-10/leo-gcp-runtime-parity/outputs/gcp-leo-runtime-observability-current.json",
+    "/Users/user/Documents/Codex/2026-07-10/leo-gcp-runtime-parity/outputs/gcp-leo-runtime-observability-current.md",
+    "/Users/user/Documents/Codex/2026-07-10/leo-gcp-control-plane/outputs/gcp-cloud-sql-t3-live-readonly-current.json"
+  ]
+}

docs/reports/leo-working-state-20260709/gcp-leo-runtime-observability-current.md

@@ -0,0 +1,113 @@
+# GCP Leo Runtime Observability — T3 Live Read-Only
+
+Captured UTC: 2026-07-10T16:03:00Z
+
+## Outcome
+
+The Console-only observability canary passed at T3_live_readonly.
+
+teleo-prod-1 is currently running. Its serial-port output is current through 2026-07-10T15:57:54Z and proves recurring successful leoclean-cloudsql-memory-sync.service cycles. The latest exact lifecycle event for leoclean-gcp-prod-parallel.service is a Hermes service start at 2026-07-09T07:00:04Z, with no later exact stop or failure in the loaded serial buffer.
+
+That is useful runtime evidence, but it is not full Leo parity. The current gateway PID, deployed SHA, profile, model/auth, Telegram identity, selected canonical DB backend, and safe no-post handler route remain unproven.
+
+Required tier: T3_live_readonly
+
+Current tier: T3_live_readonly for control/runtime observability
+
+Overall runtime parity: partial_unproven
+
+## Current VM
+
+| Field | Live Console readback |
+| --- | --- |
+| VM / instance ID | teleo-prod-1 / 6202458246232531966 |
+| Status / zone | RUNNING / europe-west6-a |
+| Created | 2026-07-07 03:57:37 UTC+02:00 |
+| Machine | e2-standard-4, 4 vCPU, 16 GB, Intel Broadwell |
+| Image | debian-12-bookworm-v20260609, X86_64 |
+| Boot disk | 150 GB balanced persistent disk, read/write, daily snapshot policy |
+| Network | teleo-staging-net / teleo-staging-europe-west6 |
+| Addresses | 10.60.0.3 internal; 34.65.143.148 ephemeral external |
+| Service account | sa-teleo-prod-vm@t***.iam.gserviceaccount.com |
+| Access metadata | OS Login enabled; UI shows full Cloud API scopes, which is not IAM authorization proof |
+
+No full service-account identity, token, cookie, password, or raw credential was retained.
+
+## Observability And Logging
+
+- Base CPU, network, connection, disk-throughput, and disk-IOPS metrics are present.
+- Ops Agent is not installed. The page offers Install Ops Agent; memory and disk-space utilization explicitly require it. Nothing was installed.
+- VM Manager is not enabled, so OS Info is unavailable. Nothing was enabled.
+- Interactive serial-console access is disabled, but the existing serial-port output page is readable.
+
+The exact VM filter returned 92 Cloud Logging records over seven days:
+
+- severity: INFO 82, NOTICE 5, DEFAULT 4, ERROR 1;
+- seven distinct log names;
+- visible top sources: GCEGuestAgent 53, GCEGuestAgentManager 26, diagnostic-log 4, and shielded-VM integrity 3.
+
+Exact runtime search:
+
+    resource.type="gce_instance"
+    resource.labels.instance_id="6202458246232531966"
+    (SEARCH("leoclean") OR SEARCH("hermes") OR SEARCH("gateway") OR SEARCH("postgres") OR SEARCH("teleo-kb"))
+
+Result: 0 entries over seven days.
+
+Adding SEARCH("systemd") returns five INFO records, all boot-time network/login/SSH initialization. It does not surface a Leo application or gateway record.
+
+Precise interpretation: guest/platform logs are ingested, but Leo application/systemd journal logs are absent from Cloud Logging. The missing Ops Agent is consistent with that gap. Serial output independently contains Leo unit activity.
+
+## Sanitized Serial Evidence
+
+The loaded serial-port-1 buffer contained 3,304 lines, from 2026-07-09T04:00:21Z through 2026-07-10T15:57:54Z. Raw lines were not retained.
+
+Observed unit names:
+
+- leoclean-cloudsql-memory-sync.service
+- leoclean-gcp-prod-parallel.service
+
+Current memory-sync evidence:
+
+- latest successful finish: 2026-07-10T15:57:54.094689Z;
+- next start: 2026-07-10T15:57:54.111434Z;
+- safe systemd description: syncing the leoclean Hermes state database to the current Cloud SQL snapshot.
+
+Gateway-unit evidence:
+
+- 30 exact unit lifecycle lines;
+- repeated stop/start cycles on July 9;
+- latest exact event: started at 2026-07-09T07:00:04.363359Z;
+- no exact failed event and no later exact stop in the loaded buffer.
+
+This supports “last known started and not subsequently stopped in serial evidence.” It does not replace a current PID, systemctl, process, or deployed-SHA readback.
+
+## Exact Claim Ceiling
+
+VM/control-plane: current and live-proven.
+
+Serial lifecycle/sync: current within the loaded 2026-07-09T04:00:21Z–2026-07-10T15:57:54Z timestamp window.
+
+Gateway active state/PID/SHA/model/auth/DB rows: still unproven.
+
+No-post Cory canary: not safe to run and not attempted.
+
+## Corrected VPS Baseline
+
+The VPS deploy checkout and stamp fast-forwarded to 771679061f0a0b6463fb7d9cf530eb9d2d4e5440 between 15:53:13–15:53:20Z.
+
+The journal says “No Python changes — services not restarted.” The merge has no delta under the Leo bin/skill paths. Gateway remains PID 2999690, NRestarts=0, started 03:47:11Z; DB count tuple remains 1837/4145/4670/4916/17/26; the apply worker remains disabled/inactive.
+
+This is source-checkout synchronization only—not a Leo runtime behavior change, deployment of PR #72 to GCP, or production permission migration/application.
+
+## Cleanup
+
+- No SSH, IAP, Cloud Shell, password, OTP, key, IAM, metadata, DB, service, deployment, or Telegram action occurred.
+- Ops Agent, VM Manager, and serial-console access were not enabled.
+- PR #72 source auto-synchronized to the VPS checkout, but it did not restart or change the VPS Leo runtime. Its GCP deployment status is unproven because no GCP SHA was available.
+- The agent-created Console tab was finalized and closed.
+
+## Evidence
+
+- outputs/gcp-leo-runtime-observability-current.json
+- /Users/user/Documents/Codex/2026-07-10/leo-gcp-control-plane/outputs/gcp-cloud-sql-t3-live-readonly-current.json

docs/reports/leo-working-state-20260709/pr72-vps-auto-deploy-runtime-nonchange-current.json

@@ -0,0 +1,58 @@
+{
+  "schema": "working-leo.vps-auto-deploy-runtime-readback.v1",
+  "generated_at_utc": "2026-07-10T16:00:14Z",
+  "mode": "read_only_vps_verification",
+  "source_pr": "https://github.com/living-ip/teleo-infrastructure/pull/72",
+  "merge_commit": "771679061f0a0b6463fb7d9cf530eb9d2d4e5440",
+  "auto_deploy": {
+    "service": "teleo-auto-deploy.service",
+    "started_at_utc": "2026-07-10T15:53:12Z",
+    "completed_at_utc": "2026-07-10T15:53:20Z",
+    "checkout": "/opt/teleo-eval/workspaces/deploy-infra",
+    "checkout_head": "771679061f0a0b6463fb7d9cf530eb9d2d4e5440",
+    "stamp_path": "/opt/teleo-eval/.last-deploy-sha",
+    "stamp_sha": "771679061f0a0b6463fb7d9cf530eb9d2d4e5440",
+    "journal_result": "No Python changes - services not restarted"
+  },
+  "leo_runtime_source_delta": {
+    "paths": [
+      "hermes-agent/leoclean-bin",
+      "hermes-agent/leoclean-skills/vps"
+    ],
+    "changed_between_first_parent_and_merge": false
+  },
+  "gateway": {
+    "service": "leoclean-gateway.service",
+    "active_state": "active",
+    "sub_state": "running",
+    "main_pid": 2999690,
+    "nrestarts": 0,
+    "start_timestamp_utc": "2026-07-10T03:47:11Z",
+    "restarted_by_pr72_auto_deploy": false
+  },
+  "apply_worker": {
+    "service": "teleo-kb-apply-worker.service",
+    "load_state": "loaded",
+    "unit_file_state": "disabled",
+    "active_state": "inactive",
+    "sub_state": "dead",
+    "main_pid": 0
+  },
+  "database_counts": {
+    "public.claims": 1837,
+    "public.sources": 4145,
+    "public.claim_evidence": 4670,
+    "public.claim_edges": 4916,
+    "public.reasoning_tools": 17,
+    "kb_stage.kb_proposals": 26
+  },
+  "actions_not_taken": [
+    "no manual deploy",
+    "no service restart",
+    "no production permission migration",
+    "no worker enablement",
+    "no canonical database apply",
+    "no Telegram send"
+  ],
+  "strongest_claim_allowed": "PR #72 source and repo-native skills were automatically synchronized to the VPS deploy checkout. The Leo gateway process and its committed profile source paths were not changed by that commit, the apply worker remained disabled and inactive, and canonical database counts remained unchanged. This does not prove byte-for-byte database equality or future behavior after a service restart."
+}

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

@@ -0,0 +1,40 @@
+# PR #72 VPS Auto-Deploy Runtime Readback
+
+Observed UTC: `2026-07-10T16:00:14Z`
+
+## Result
+
+The VPS auto-deploy timer fast-forwarded `/opt/teleo-eval/workspaces/deploy-infra`
+and `/opt/teleo-eval/.last-deploy-sha` to merge commit
+`771679061f0a0b6463fb7d9cf530eb9d2d4e5440` at `15:53:13-20Z`.
+
+This was a source-checkout synchronization, not a live Leo behavior change:
+
+- The auto-deploy journal says `No Python changes - services not restarted`.
+- PR #72 changed neither `hermes-agent/leoclean-bin` nor
+  `hermes-agent/leoclean-skills/vps`.
+- `leoclean-gateway.service` remained active/running on PID `2999690`, with
+  `NRestarts=0` and start time `2026-07-10T03:47:11Z`.
+- `teleo-kb-apply-worker.service` remained disabled, inactive, and dead.
+- No production permission migration or canonical proposal apply ran.
+
+## Database Readback
+
+The read-only transaction returned:
+
+| Table | Rows |
+| --- | ---: |
+| `public.claims` | 1837 |
+| `public.sources` | 4145 |
+| `public.claim_evidence` | 4670 |
+| `public.claim_edges` | 4916 |
+| `public.reasoning_tools` | 17 |
+| `kb_stage.kb_proposals` | 26 |
+
+## Claim Ceiling
+
+PR #72 source and repo-native skills are present in the VPS deploy checkout.
+The gateway process was not restarted, its committed profile source paths were
+unchanged by the commit, the apply worker stayed disabled, and the count
+endpoints stayed unchanged. This is not byte-for-byte database proof and does
+not predict behavior after a future restart.

docs/reports/leo-working-state-20260709/skill-pack-manifest.json

@@ -1,13 +1,13 @@
 {
   "pack": "leo-teleo-skill-pack",
   "created_date": "2026-07-09",
-  "last_updated_utc": "2026-07-10T15:47:17Z",
+  "last_updated_utc": "2026-07-10T16:09:07Z",
   "status": "repo_native_validated",
   "contains_secrets": false,
   "production_mutation_authorized": false,
   "repo_skill_root": ".agents/skills",
   "optional_local_install_target": "/Users/user/.codex/skills",
-  "claim_ceiling": "Repo-native onboarding and operations skills. Generic and Helmer guarded-apply canaries pass 37/37 in disposable PostgreSQL; the production permission migration and Helmer apply remain undeployed. GCP control-plane inventory is live-proven, while DB row/runtime parity remains gated on an existing database principal.",
+  "claim_ceiling": "Repo-native onboarding and operations skills. Generic and Helmer guarded-apply canaries pass 37/37 in disposable PostgreSQL. PR #72 source auto-synchronized to the VPS checkout without a gateway restart or profile-source delta; the permission migration was not applied, the apply worker remained disabled/inactive, and Helmer remained unapplied. GCP project, VM, Cloud SQL inventory, and bounded serial unit activity are live-proven; current gateway PID/SHA/model/auth, DB rows, Cory answers, and cutover remain unproven.",
   "skills": [
     {
       "name": "teleo-leo-onboarding",
@@ -56,7 +56,9 @@
     "docs/reports/leo-working-state-20260709/fable-leo-teleo-onboarding.md",
     "docs/reports/leo-working-state-20260709/approve-claim-clone-canary-current.md",
     "docs/reports/leo-working-state-20260709/gcp-cloud-sql-t3-live-readonly-current.md",
-    "docs/reports/leo-working-state-20260709/gcp-cloudsql-studio-parity-gate-current.md"
+    "docs/reports/leo-working-state-20260709/gcp-cloudsql-studio-parity-gate-current.md",
+    "docs/reports/leo-working-state-20260709/pr72-vps-auto-deploy-runtime-nonchange-current.md",
+    "docs/reports/leo-working-state-20260709/gcp-leo-runtime-observability-current.md"
   ],
   "validation": "tests/test_repo_skill_pack.py"
 }

docs/reports/leo-working-state-20260709/skill-pack-readme.md

@@ -19,15 +19,17 @@ This is the repo-native skill set under `.agents/skills/`. It is evidence-linked
 
 - VPS Leo Telegram memory, KB audit, and staged write canaries are live-proven.
 - A strict canonical `add_edge` apply canary is live-proven.
-- Generic and real Helmer guarded-apply canaries pass `37/37` with exact payload projections/table deltas, current-source hashes, and cleanup proof; neither the new permission migration nor Helmer is production-applied.
+- Generic and real Helmer guarded-apply canaries pass `37/37` with exact payload projections/table deltas, current-source hashes, and cleanup proof. PR #72 source auto-synchronized to the VPS checkout without a gateway restart or profile-source delta; the permission migration was not applied, the apply worker stayed disabled/inactive, and Helmer was not production-applied.
 - The live VPS runtime behavior should not be changed while the DB apply path is stabilized.
-- GCP project, VM, and private Cloud SQL inventory are live-proven. Cloud SQL row/schema parity is not: Studio requires an already-existing authenticated DB principal.
+- GCP project, VM, private Cloud SQL inventory, and bounded serial unit activity are live-proven. Current gateway PID/SHA/model/auth and DB row/schema parity are not; Studio requires an already-existing authenticated DB principal.
 
 ## Key References
 
 - Current truth index: `docs/reports/leo-working-state-20260709/current-truth-index.md`
 - Operator surface map: `docs/reports/leo-working-state-20260709/operator-surface-map.md`
 - Fable onboarding prompt: `docs/reports/leo-working-state-20260709/fable-leo-teleo-onboarding.md`
+- PR #72 VPS auto-deploy/runtime readback: `docs/reports/leo-working-state-20260709/pr72-vps-auto-deploy-runtime-nonchange-current.md`
+- GCP Leo runtime observability: `docs/reports/leo-working-state-20260709/gcp-leo-runtime-observability-current.md`
 - Skill manifest: `skill-pack-manifest.json`
 
 ## Discovery

tests/test_repo_skill_pack.py

@@ -21,6 +21,8 @@ def test_manifest_indexes_valid_repo_native_skills() -> None:
     assert manifest["repo_skill_root"] == ".agents/skills"
     assert manifest["validation"] == "tests/test_repo_skill_pack.py"
     assert "37/37" in manifest["claim_ceiling"]
+    assert "auto-synchronized" in manifest["claim_ceiling"]
+    assert "apply worker remained disabled/inactive" in manifest["claim_ceiling"]
 
     for entry in manifest["skills"]:
         path = ROOT / entry["path"]
@@ -36,6 +38,7 @@ def test_manifest_indexes_valid_repo_native_skills() -> None:
 
 def test_db_change_skill_tracks_guarded_v2_runtime_proof() -> None:
     text = _skill("teleo-kb-db-change-workflow")
+    squashed = " ".join(text.split())
 
     for required in (
         "`approve_claim` v2",
@@ -51,13 +54,19 @@ def test_db_change_skill_tracks_guarded_v2_runtime_proof() -> None:
     ):
         assert required in text
 
-    assert "does not prove byte-for-byte live content" in text
+    assert "does not prove byte-for-byte live content" in squashed
-    assert "production permission migration" in text
+    assert "production permission migration" in squashed
+    assert "pr72-vps-auto-deploy-runtime-nonchange-current.md" in text
 
 
 def test_gcp_skill_uses_current_cloud_sql_truth_and_exact_gate() -> None:
     text = _skill("teleo-gcp-parity-ops")
     squashed = " ".join(text.split())
+    observability = json.loads(
+        (REPORT_DIR / "gcp-leo-runtime-observability-current.json").read_text(
+            encoding="utf-8"
+        )
+    )
 
     for required in (
         "teleo-pgvector-standby",
@@ -68,6 +77,9 @@ def test_gcp_skill_uses_current_cloud_sql_truth_and_exact_gate() -> None:
         "GCP Studio authenticated",
         "begin transaction read only",
         "DB contents",
+        "gcp-leo-runtime-observability-current.json",
+        "leoclean-cloudsql-memory-sync.service",
+        "zero seven-day entries",
     ):
         assert required in text
 
@@ -75,16 +87,24 @@ def test_gcp_skill_uses_current_cloud_sql_truth_and_exact_gate() -> None:
     assert "IAM DB principal" in squashed
     assert "Do not submit a raw password" in text
     assert "AppleScript" in text
+    assert observability["delivery_context"]["gcp_deployment_status"] == "unproven"
+    assert observability["delivery_context"]["gcp_deployed_sha_proven"] is False
 
 
 def test_vps_onboarding_and_cory_skills_point_to_current_proof() -> None:
     vps = _skill("teleo-vps-runtime-ops")
+    provenance = _skill("teleo-infra-provenance")
     onboarding = _skill("teleo-leo-onboarding")
     cory = _skill("working-leo-cory-outcomes")
 
     assert "reasoning tools `17`" in vps
     assert "current source hashes" in vps
+    assert "`teleo-auto-deploy.timer`" in vps
+    assert "separate state changes" in vps
+    assert "/opt/teleo-eval/.last-deploy-sha" in provenance
+    assert "does not prove a gateway restart" in " ".join(provenance.split())
     assert "gcp-cloud-sql-t3-live-readonly-current.md" in onboarding
+    assert "gcp-leo-runtime-observability-current.md" in onboarding
     assert "GCP Studio authenticated" not in onboarding
     assert "37/37" in cory
     assert "Approved is not the same as applied" in cory