teleo-infrastructure/docs/reports/leo-working-state-20260709/leo-restart-survival-proof-current.md
twentyOne2x 63278b6354
Some checks are pending
CI / lint-and-test (push) Waiting to run
Record Leo post-repair direct-claim proof
2026-07-10 06:22:11 +02:00

57 lines
3.1 KiB
Markdown

# Leo Restart-Survival Proof
Generated UTC: `2026-07-10T03:26:33Z`
Status: `pass`
Survives restart: `true`
## What Ran
- Restart command: `systemctl restart leoclean-gateway.service`
- Command return code: `0`
- Restart start: `2026-07-10T03:24:42.746875+00:00`
- Restart end: `2026-07-10T03:24:43.605395+00:00`
- Deployed repo: `/opt/teleo-eval/workspaces/deploy-infra`
- Deploy HEAD: `741f1d6782340bcbba633e7b3affa345308c0726`
- `.last-deploy-sha`: `741f1d6782340bcbba633e7b3affa345308c0726`
## Service Readback
- Before restart: `ActiveState=active`, `SubState=running`, `MainPID=1908033`, `NRestarts=0`, `ExecMainStartTimestamp=Fri 2026-07-10 01:04:22 UTC`
- After restart: `ActiveState=active`, `SubState=running`, `MainPID=2845730`, `NRestarts=0`, `ExecMainStartTimestamp=Fri 2026-07-10 03:24:43 UTC`
- After handler smoke: `ActiveState=active`, `SubState=running`, `MainPID=2845730`, `NRestarts=0`, `ExecMainStartTimestamp=Fri 2026-07-10 03:24:43 UTC`
## DB Invariant
Counts were unchanged before restart, after restart, and after the handler smoke:
- `public.claims=1837`
- `public.sources=4145`
- `public.claim_evidence=4670`
- `public.claim_edges=4916`
- `kb_stage.kb_proposals=26`
## Handler Smoke
- Command: `sudo -u teleo -H /home/teleo/.hermes/hermes-agent/venv/bin/python scripts/run_leo_direct_claim_handler_remote.py --turn-timeout 300 --remote-report-path /tmp/leo-restart-survival-direct-claim-current.json`
- Return code: `0`
- Runtime pass: `true`
- Prompt IDs: `DC-01`, `DC-02`, `DC-03`, `DC-04`, `DC-05`, `DC-06`
- All replies nonempty: `true`
- Evidence tier: `live_vps_gatewayrunner_temp_profile`
- Handler report: `docs/reports/leo-working-state-20260709/leo-restart-survival-direct-claim-current.json`
- Strict score for retained post-restart replies: `5/6`
- Strict score report: `docs/reports/leo-working-state-20260709/leo-restart-survival-direct-claim-score-current.md`
- Current scorer failure: `DC-06` missed explicit row-level proof language even though it correctly separated `SOUL.md` runtime edits from canonical DB identity.
- Repair in this branch: VPS/GCP KB bridge skills now require the `SOUL.md` direct-claim answer to include a row-level proof sentence naming current readback, new/updated row IDs, canonical `public.*` or identity rows, and postflight/render-sync proof.
## Safety Boundaries
- Posted to Telegram: `false`
- Production DB apply ran: `false`
- Live profile changed: `false`
- Temp profile removed: `true`
- New temp profile leftovers: `[]`
## Claim Ceiling
This proves Leo survives an intentional `leoclean-gateway.service` restart on the VPS, keeps canonical DB counts unchanged, and still answers the no-post Cory-style direct-claim suite after restart. This retained restart-run score was pre-repair and strict-scored `5/6`. A later deployed repair at `090becae1621436467610e529d6328d70964d11f` strict-scored the same no-post direct-claim suite `6/6`; see `leo-post-skill-repair-direct-claim-summary-current.md`. This still does not prove Telegram-visible DC-01..DC-06 group delivery, production application of the rich approved packets, autonomous apply-worker production readiness, or GCP parity.