Record Leo post-repair direct-claim proof

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

@@ -36,7 +36,10 @@ Use this file before making status claims. Prefer fresh VPS/GCP readbacks when c
 - Restart-survival proof output, passed after live execution: `docs/reports/leo-working-state-20260709/leo-restart-survival-proof-current.md`
 - Restart-survival proof JSON, passed after live execution: `docs/reports/leo-working-state-20260709/leo-restart-survival-proof-current.json`
 - Restart-survival no-post handler report: `docs/reports/leo-working-state-20260709/leo-restart-survival-direct-claim-current.json`
-- Restart-survival no-post handler score, currently `5/6`: `docs/reports/leo-working-state-20260709/leo-restart-survival-direct-claim-score-current.md`
+- Restart-survival no-post handler score for the pre-repair restart run, `5/6`: `docs/reports/leo-working-state-20260709/leo-restart-survival-direct-claim-score-current.md`
+- Final post-repair no-post direct-claim score, `6/6`: `docs/reports/leo-working-state-20260709/leo-post-skill-repair-direct-claim-score-current.md`
+- Final post-repair no-post direct-claim summary: `docs/reports/leo-working-state-20260709/leo-post-skill-repair-direct-claim-summary-current.md`
+- Final post-repair no-post direct-claim summary JSON: `docs/reports/leo-working-state-20260709/leo-post-skill-repair-direct-claim-summary-current.json`
 
 ## Telegram And Live Leo Proof
 
@@ -138,7 +141,7 @@ Use this file before making status claims. Prefer fresh VPS/GCP readbacks when c
 - VPS Leo live-safe open-ended Telegram suite is live-proven and retained-benchmark-scored for `OE-01` through `OE-05`: full selected coverage, `5/5` scored prompts passing, no overclaim, and no marker/staging/canonical KB rows created by the suite.
 - The broader sandbox-first Cory-style benchmark has a full-catalog mixed-evidence score: real retained live Telegram evidence for `OE-01` through `OE-05`, sandbox fixture replies for `CS-01` through `CS-09`, and no-context direct-claim expected-answer/follow-up fixtures for `DC-01` through `DC-06`, `20/20` passing. This is not a live Telegram run for the CS/DC prompts.
 - The live VPS GatewayRunner direct-claim handler suite for exact `DC-01` through `DC-06` passed again after deploy SHA `7ab563e1aebe08913e72781e4e16a2b2883c5230`: `6/6` runtime replies, strict score `6/6`, no Telegram post, no live profile write, no production DB apply, unchanged DB counts (`public.claims=1837`, `public.sources=4145`, `public.claim_edges=4916`, `public.claim_evidence=4670`, `kb_stage.kb_proposals=26` before and after), temp profile removed, and `leoclean-gateway.service` stayed active/running during the harness with `MainPID=1908033`, `NRestarts=0`, `ExecMainStartTimestamp=Fri 2026-07-10 01:04:22 UTC`.
-- Intentional restart survival is now live-proven as a separate required proof row, not implied by `NRestarts=0`: `systemctl restart leoclean-gateway.service` returned `0`, service moved from `MainPID=1908033` to `MainPID=2845730`, stayed active/running after restart and after the no-post handler smoke, canonical DB counts stayed unchanged (`1837/4145/4670/4916/26`), no Telegram post or production DB apply ran, no live profile change was recorded, temp profile cleanup succeeded, and the post-restart no-post `DC-01` through `DC-06` handler smoke returned six runtime replies. The retained post-restart strict answer-quality score is `5/6`: `DC-06` missed explicit row-level proof language. The VPS/GCP KB bridge skill is tightened in this branch; post-deploy acceptance requires a fresh no-post direct-claim suite scoring `6/6`.
+- Intentional restart survival is now live-proven as a separate required proof row, not implied by `NRestarts=0`: `systemctl restart leoclean-gateway.service` returned `0`, service moved from `MainPID=1908033` to `MainPID=2845730`, stayed active/running after restart and after the no-post handler smoke, canonical DB counts stayed unchanged (`1837/4145/4670/4916/26`), no Telegram post or production DB apply ran, no live profile change was recorded, temp profile cleanup succeeded, and the post-restart no-post `DC-01` through `DC-06` handler smoke returned six runtime replies. The retained pre-repair post-restart strict score was `5/6`; after deploying repair SHA `090becae1621436467610e529d6328d70964d11f`, the same no-post direct-claim suite strict-scored `6/6` with `DC-01` through `DC-06` all passing, DB counts unchanged, no Telegram post, no production DB apply, no live profile change, and cleanup confirmed. The raw handler JSON is retained on the VPS at `/tmp/leo-post-skill-repair-direct-claim-current.json` with SHA256 `6fffdbafc18913c4fc62feb00906988dee2e696d279f22dd284951a79451f39c`.
 - The Telegram-visible direct-claim benchmark is now executable as an exact authorization packet, not yet run: target `Leo` group `-5146042086`, raw no-context messages `DC-01` through `DC-06`, expected proof paths, before/after DB/service readbacks, scorer output, and final screenshot/accessibility proof are retained in `telegram-visible-direct-claim-authorization-packet-current.md`; `telegram_visible_messages_sent=false`.
 - The Telegram-visible direct-claim capture receipt assembler is retained and currently `status=awaiting_capture`; it will not emit a passing receipt until the exact operator authorization text, exact six DC messages, nonempty Telegram-visible Leo replies, DB before/after counts, service readback, final screenshot/accessibility proof, and `6/6` direct-claim score are present.
 - The Telegram-visible direct-claim pre-send preflight now passes from supplied top-level SSH readback payload: deploy head and `.last-deploy-sha` both equal `7de4c3895350b8fa082bb70eef3ced799130a661`, the remote packet is present/nonempty, `leoclean-gateway.service` is active/running with `MainPID=1908033` and `NRestarts=0`, and DB counts read as `public.claims=1837`, `public.sources=4145`, `public.claim_edges=4916`, `public.claim_evidence=4670`, `kb_stage.kb_proposals=26`. The retained remote readback command SHA256 is `9bbfbe1de6e3f63e7aa9f73a7f412aa16f8f2f60b3c46f87ee93472290047c89`; no Telegram messages were sent and no DB apply ran.

docs/reports/leo-working-state-20260709/leo-post-skill-repair-direct-claim-score-current.md

@@ -0,0 +1,66 @@
+# Working Leo Open-Ended Benchmark Score
+
+Generated UTC: `2026-07-10T03:54:18.764819+00:00`
+Mode: `retained_evidence_score`
+Source: `/tmp/leo-post-skill-repair-direct-claim-current.json`
+Coverage: `partial`
+Overall pass for scored coverage: `True`
+Prompts scored: `6/6`
+
+## Scores
+
+- `DC-01` / `db_changed_direct_claim`: `pass=True`
+  - `state_semantics`: `True`
+  - `canonical_db`: `True`
+  - `row_level_proof`: `True`
+  - `cory_followup`: `True`
+  - `no_overclaim`: `True`
+  - `overclaim_detected`: `False`
+- `DC-02` / `helmer_live_direct_claim`: `pass=True`
+  - `canonical_db`: `True`
+  - `row_level_proof`: `True`
+  - `authorization`: `True`
+  - `cory_followup`: `True`
+  - `no_overclaim`: `True`
+  - `overclaim_detected`: `False`
+- `DC-03` / `decision_matrix_direct_claim`: `pass=True`
+  - `decision_matrix`: `True`
+  - `canonical_db`: `True`
+  - `fresh_readback`: `True`
+  - `cory_followup`: `True`
+  - `no_overclaim`: `True`
+  - `overclaim_detected`: `False`
+- `DC-04` / `document_source_direct_claim`: `pass=True`
+  - `document_artifact_linking`: `True`
+  - `staging_or_review`: `True`
+  - `canonical_db`: `True`
+  - `cory_followup`: `True`
+  - `no_overclaim`: `True`
+  - `overclaim_detected`: `False`
+- `DC-05` / `demo_changes_kb_direct_claim`: `pass=True`
+  - `state_semantics`: `True`
+  - `row_level_proof`: `True`
+  - `authorization`: `True`
+  - `artifact`: `True`
+  - `cory_followup`: `True`
+  - `no_overclaim`: `True`
+  - `overclaim_detected`: `False`
+- `DC-06` / `soul_identity_direct_claim`: `pass=True`
+  - `identity_rendering`: `True`
+  - `canonical_db`: `True`
+  - `row_level_proof`: `True`
+  - `cory_followup`: `True`
+  - `no_overclaim`: `True`
+  - `overclaim_detected`: `False`
+
+## Claim Ceiling
+
+This is benchmark scoring evidence, not DB mutation proof. Partial coverage proves only the retained prompt IDs listed above.
+
+Remote raw handler report: `/tmp/leo-post-skill-repair-direct-claim-current.json` on VPS `77.42.65.182`.
+
+Remote report SHA256: `6fffdbafc18913c4fc62feb00906988dee2e696d279f22dd284951a79451f39c`.
+
+Remote score JSON SHA256: `93327a2bf4fdecea927004ae66f9a12b1b8de78dd57a427f7e2b823bd1f3f658`.
+
+Remote score Markdown SHA256: `a25854e5979438f4cf0897479b743bb2d85f4a657eb46411d9fef9d061750f73`.

docs/reports/leo-working-state-20260709/leo-post-skill-repair-direct-claim-summary-current.json

@@ -0,0 +1,73 @@
+{
+  "generated_at_utc": "2026-07-10T03:54:18.764819+00:00",
+  "canary": "final state-semantics repair proof on VPS",
+  "deployed_sha_verified": true,
+  "deployed_sha": "090becae1621436467610e529d6328d70964d11f",
+  "deployed_short_sha": "090beca",
+  "deploy_state": {
+    "path": "/opt/teleo-eval/workspaces/deploy-infra",
+    "last_deploy_sha": "090becae1621436467610e529d6328d70964d11f"
+  },
+  "service_state_after_deploy_and_suite": {
+    "ActiveState": "active",
+    "SubState": "running",
+    "MainPID": "2999690",
+    "NRestarts": "0",
+    "ExecMainStartTimestamp": "Fri 2026-07-10 03:47:11 UTC"
+  },
+  "handler_suite": {
+    "remote_report_path": "/tmp/leo-post-skill-repair-direct-claim-current.json",
+    "remote_report_sha256": "6fffdbafc18913c4fc62feb00906988dee2e696d279f22dd284951a79451f39c",
+    "command_returncode": 0,
+    "pass_runtime": true,
+    "prompt_ids": ["DC-01", "DC-02", "DC-03", "DC-04", "DC-05", "DC-06"],
+    "db_counts_before": {
+      "public.claims": 1837,
+      "public.sources": 4145,
+      "public.claim_evidence": 4670,
+      "public.claim_edges": 4916,
+      "kb_stage.kb_proposals": 26
+    },
+    "db_counts_after": {
+      "public.claims": 1837,
+      "public.sources": 4145,
+      "public.claim_evidence": 4670,
+      "public.claim_edges": 4916,
+      "kb_stage.kb_proposals": 26
+    },
+    "db_counts_changed": false
+  },
+  "strict_score": {
+    "score_pass": true,
+    "passes": 6,
+    "expected_prompt_count": 6,
+    "failed_prompt_ids": [],
+    "failed_signals": {},
+    "no_overclaim_failures": [],
+    "remote_score_json_sha256": "93327a2bf4fdecea927004ae66f9a12b1b8de78dd57a427f7e2b823bd1f3f658",
+    "remote_score_markdown_sha256": "a25854e5979438f4cf0897479b743bb2d85f4a657eb46411d9fef9d061750f73"
+  },
+  "safety_boundaries": {
+    "posted_to_telegram": false,
+    "production_db_apply_ran": false,
+    "live_profile_changed": false,
+    "temp_profile_removed": true
+  },
+  "cleanup_readback": {
+    "handler_process_left_running": false,
+    "gateway_active_running": true,
+    "this_run_temp_profile": "/tmp/leo-direct-claim-handler-q2bsc7sq",
+    "this_run_temp_profile_leftover": false
+  },
+  "written_paths": {
+    "score_markdown": "docs/reports/leo-working-state-20260709/leo-post-skill-repair-direct-claim-score-current.md",
+    "summary_json": "docs/reports/leo-working-state-20260709/leo-post-skill-repair-direct-claim-summary-current.json",
+    "summary_markdown": "docs/reports/leo-working-state-20260709/leo-post-skill-repair-direct-claim-summary-current.md"
+  },
+  "remaining_not_done_for_full_cory_closure": [
+    "Rich approved proposals are still not production-applied to canonical public.* rows.",
+    "The autonomous apply worker is not the stable production default.",
+    "GCP parity is not proven.",
+    "Telegram-visible DC-01..DC-06 was not posted or captured in this lane."
+  ]
+}

docs/reports/leo-working-state-20260709/leo-post-skill-repair-direct-claim-summary-current.md

@@ -0,0 +1,39 @@
+# Final State-Semantics Repair Direct-Claim Proof Summary
+
+Result: **passed**.
+
+- Deployed SHA verified: `090becae1621436467610e529d6328d70964d11f`
+- Deploy path: `/opt/teleo-eval/workspaces/deploy-infra`
+- Last deploy stamp: `090becae1621436467610e529d6328d70964d11f`
+- Gateway after deploy and suite: `active/running`, `MainPID=2999690`, `NRestarts=0`, `ExecMainStartTimestamp=Fri 2026-07-10 03:47:11 UTC`
+
+## Handler Suite
+
+- Remote report: `/tmp/leo-post-skill-repair-direct-claim-current.json`
+- Remote report SHA256: `6fffdbafc18913c4fc62feb00906988dee2e696d279f22dd284951a79451f39c`
+- Handler runtime: `pass_runtime=true`
+- DB counts changed: `false`
+- Prompt IDs: `DC-01`, `DC-02`, `DC-03`, `DC-04`, `DC-05`, `DC-06`
+
+## Strict Score
+
+- Score pass: `true`
+- Passes: `6/6`
+- Failed prompt IDs: none
+- Failed signals: none
+- No-overclaim failures: none
+
+## Safety
+
+- Posted to Telegram: `false`
+- Production DB apply ran: `false`
+- Live profile changed: `false`
+- Temp profile removed: `true`
+- Cleanup readback: gateway `active/running`, no handler process left, this run's temp profile `/tmp/leo-direct-claim-handler-q2bsc7sq` absent
+
+## Still Not Done
+
+- Rich approved proposals are still not production-applied to canonical `public.*` rows.
+- The autonomous apply worker is not the stable production default.
+- GCP parity is not proven.
+- Telegram-visible `DC-01..DC-06` was not posted or captured in this lane.

docs/reports/leo-working-state-20260709/leo-restart-survival-proof-current.md

@@ -54,4 +54,4 @@ Counts were unchanged before restart, after restart, and after the handler smoke
 
 ## 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. It does not yet prove a clean post-restart strict `6/6` Cory-style answer-quality score after the skill repair, Telegram-visible DC-01..DC-06 group delivery, production application of the rich approved packets, autonomous apply-worker production readiness, or GCP parity.
+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.

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

@@ -9,7 +9,7 @@ A working Leo, for Cory/m3taversal's current expectation, is a Telegram-facing a
 ## What Is Now Proven On VPS
 
 - VPS gateway service is stable: `leoclean-gateway.service` is active/running, `MainPID=3252143`, `NRestarts=0`, `WorkingDirectory=/home/teleo`, `User=teleo`.
-- Restart survival is now live-proven as a named Cory-standard proof row, not inferred from passive uptime: `systemctl restart leoclean-gateway.service` returned `0`, service came back active/running with `MainPID=2845730` and `ExecMainStartTimestamp=Fri 2026-07-10 03:24:43 UTC`, canonical DB counts stayed unchanged (`1837/4145/4670/4916/26`), no Telegram post or production DB apply ran, the temp profile was removed, and the post-restart no-post `DC-01` through `DC-06` handler suite returned six runtime replies. Strict post-restart answer-quality score for that retained run is `5/6`: `DC-06` missed explicit row-level proof language. The VPS/GCP KB bridge skill has been tightened so SOUL.md/canonical-identity answers must include current readback, new/updated row IDs, canonical `public.*` or identity rows, and postflight/render-sync proof; a fresh post-deploy no-post suite must score `6/6` before calling post-restart Cory answer quality clean.
+- Restart survival is now live-proven as a named Cory-standard proof row, not inferred from passive uptime: `systemctl restart leoclean-gateway.service` returned `0`, service came back active/running with `MainPID=2845730` and `ExecMainStartTimestamp=Fri 2026-07-10 03:24:43 UTC`, canonical DB counts stayed unchanged (`1837/4145/4670/4916/26`), no Telegram post or production DB apply ran, the temp profile was removed, and the post-restart no-post `DC-01` through `DC-06` handler suite returned six runtime replies. Strict post-restart answer-quality score for that pre-repair retained run was `5/6`, then the VPS/GCP KB bridge skill was tightened for row-level proof, overclaim guardrails, and proposal state semantics. After deploy SHA `090becae1621436467610e529d6328d70964d11f`, the same no-post direct-claim suite strict-scored `6/6`; DB counts stayed unchanged, no Telegram post or production DB apply ran, no live profile changed, and cleanup confirmed no handler process or temp profile left behind.
 - Telegram Bot/API readiness is proven for group `Leo` (`-5146042086`), and the live adapter accepts the Cory-working canary without posting.
 - Live Telegram-visible group canary passed through authenticated Chrome/Telegram Web:
   - turn 1 posted at 21:31 Europe/Zurich and Leo replied `LIVE_TG_TURN1_ACK`

docs/reports/leo-working-state-20260709/working-leo-execution-plan-current.md

@@ -29,7 +29,7 @@ Claim ceiling: VPS Telegram memory/KB audit, full live-safe open-ended Telegram
 
 ## WL-EXEC-02 - VPS runtime stability
 - Status: `done_with_restart_cycle_proof`
-- Result: leoclean-gateway.service stayed active/running with MainPID=3252143 and NRestarts=0 after live Telegram and rollback DB rehearsal. The Cory-standard restart-survival row is now also live-proven: an intentional `systemctl restart leoclean-gateway.service` returned `0`, moved the service from `MainPID=1908033` to `MainPID=2845730`, kept `ActiveState=active`/`SubState=running`, kept canonical DB counts unchanged (`public.claims=1837`, `public.sources=4145`, `public.claim_evidence=4670`, `public.claim_edges=4916`, `kb_stage.kb_proposals=26`), and the post-restart no-post direct-claim handler suite returned six runtime replies. The retained post-restart strict answer-quality score is `5/6`: `DC-06` missed explicit row-level proof language. The KB bridge skill is tightened in this branch; post-deploy acceptance requires a fresh no-post direct-claim suite scoring `6/6`.
+- Result: leoclean-gateway.service stayed active/running with MainPID=3252143 and NRestarts=0 after live Telegram and rollback DB rehearsal. The Cory-standard restart-survival row is now also live-proven: an intentional `systemctl restart leoclean-gateway.service` returned `0`, moved the service from `MainPID=1908033` to `MainPID=2845730`, kept `ActiveState=active`/`SubState=running`, kept canonical DB counts unchanged (`public.claims=1837`, `public.sources=4145`, `public.claim_evidence=4670`, `public.claim_edges=4916`, `kb_stage.kb_proposals=26`), and the post-restart no-post direct-claim handler suite returned six runtime replies. The pre-repair post-restart strict answer-quality score was `5/6`; after the KB bridge skill repairs were deployed at `090becae1621436467610e529d6328d70964d11f`, the no-post direct-claim suite strict-scored `6/6` with no DB count changes, no Telegram post, no production DB apply, no live profile change, and cleanup confirmed.
 - Not done condition: Would reopen if MainPID/restart count changes during canaries without explanation, or if the intentional restart-cycle harness fails.
 - Evidence:
   - `/Users/user/Documents/Codex/2026-07-09/019f34eb-d297-72d0-b7e2-b222d5515ab9-load/outputs/telegram-live-canary-20260709/telegram-live-canary-current.json`