diff --git a/docs/kb-rebuild-and-recompile.md b/docs/kb-rebuild-and-recompile.md index 7d9ec0f..2c1bde1 100644 --- a/docs/kb-rebuild-and-recompile.md +++ b/docs/kb-rebuild-and-recompile.md @@ -25,17 +25,21 @@ Run: --output /tmp/teleo-canonical-rebuild-receipt.json ``` -The 2026-07-13 live canary restored a fresh, network-isolated Postgres in 3.81 -seconds and then removed it. The restored target matched the source across all -39 manifest tables and all 52,164 rows, with no schema, data, constraint, role, -or performance mismatch. Key rows included: +The newest retained 2026-07-13 canary restored a fresh, network-isolated +Postgres and then removed it. The restored target matched the source across all +39 manifest tables and all 52,165 rows, with no schema, data, constraint, role, +or performance mismatch. Total runtime was 12.35 seconds, including 2.97 +seconds for `pg_restore`. Key rows included: - 1,837 claims; - 4,145 sources; - 4,670 claim-evidence links; - 4,916 claim edges; - 17 reasoning tools; -- 26 proposals. +- 27 proposals. + +This snapshot predates the completed V3 source canary. The live VPS now has 29 +proposals, so a new snapshot is required before claiming current GCP parity. This is the fastest disaster-recovery path. It does not require Leo to re-extract or relearn the corpus. diff --git a/docs/reports/leo-working-state-20260709/current-truth-index.md b/docs/reports/leo-working-state-20260709/current-truth-index.md index 734ec4f..2a20dfa 100644 --- a/docs/reports/leo-working-state-20260709/current-truth-index.md +++ b/docs/reports/leo-working-state-20260709/current-truth-index.md @@ -2,6 +2,42 @@ Use this file before making status claims. Prefer fresh VPS/GCP readbacks when cheap; this directory is the retained July 9 evidence snapshot committed to the Teleo infrastructure repo. +## Live Addendum - 2026-07-14 + +The current canonical handoff is +`working-leo-three-day-outcome-and-forward-path-20260714.md`. This section +supersedes the July 13 verdict below. + +- VPS deploy and stamp both equal merge + `aa1246c603020bef07a575e4aebf4f2d2ed5db0c`; gateway PID `366950`, + `NRestarts=0`, active/running, start `2026-07-14 00:25:49 UTC`. +- Live counts are claims `1837`, sources `4145`, edges `4916`, evidence `4670`, + proposals `29`; proposal states are applied `2`, approved `3`, pending review + `16`, canceled `8`. +- The current broad no-post VPS GatewayRunner suite passes `15/15`, including + database composition, same-session memory, source intake boundaries, current + schema, and exact `m3taversal` participant identity. DB and service state were + unchanged and the temporary profile was removed. +- The real V3 document canary is proposal + `10bc0719-1c2b-5f42-a41e-86e6478692cb`, `pending_review`, `applied_at: NULL`. + The deployed post-restart handler finds that exact proposal and correctly + refuses to call it canonical. No production apply ran. +- Visible Telegram proof for the current broad suite is still pending and must + use authenticated Google Chrome only. +- Prior GCP parity remains valid at its historical proof point (`39` tables, + `52,164` rows), but current parity is pending. A newer `52,165`-row, + `27`-proposal VPS dump restored locally with zero mismatches; it predates the + live `29`-proposal V3 state and has not yet been restored to GCP. +- Exact snapshot recovery works. Full source-to-blank-database recompilation is + partial; see `../../kb-rebuild-and-recompile.md`. + +Newest artifacts: + +- `working-leo-three-day-outcome-and-forward-path-20260714.md` +- `telegram-handler-m3taversal-oos-suite-score-current.md` +- `telegram-handler-v3-proposal-readback-post-restart-current.json` +- `leo-v3-document-source-lifecycle-current.md` + ## Live Addendum - 2026-07-13 The whole-system m3taversal-standard verdict remains **not fully yet**. This diff --git a/docs/reports/leo-working-state-20260709/telegram-handler-m3taversal-oos-suite-current.json b/docs/reports/leo-working-state-20260709/telegram-handler-m3taversal-oos-suite-current.json new file mode 100644 index 0000000..6e1bcb4 --- /dev/null +++ b/docs/reports/leo-working-state-20260709/telegram-handler-m3taversal-oos-suite-current.json @@ -0,0 +1,1396 @@ +{ + "before_service": { + "ActiveState": "active", + "ExecMainStartTimestamp": "Mon 2026-07-13 19:50:24 UTC", + "MainPID": "2826463", + "NRestarts": "0", + "SubState": "running" + }, + "changed_live_profile": false, + "database_context_all_ok": true, + "database_context_injection_count": 16, + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "demo_capability_readback" + ], + "contract_sha256": "28fb670425862f512082618eea335bec6d3a1bba5e96c6f2ec27096dfac2158a", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:25:27.197525+00:00", + "injected": true, + "query_sha256": "541d4fd4051dd99a69de7e01b7da921d495f4d7f3bf74a76abab47654a28b1f2", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "demo_capability_readback", + "reply_budget" + ], + "delivered_response_sha256": "aa5c738d45787efcc505e4f81bf916bb1bb38387bc5a9af18678a7230c5f6b5f", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:25:44.662055+00:00", + "issues": [ + "missing_demo_claim_ceiling", + "missing_demo_state:applied", + "missing_demo_state:approved", + "missing_demo_state:pending_review", + "missing_demo_term:artifact", + "missing_demo_term:authorization", + "missing_demo_term:postflight", + "missing_live_count_readback:demo_capability_readback", + "missing_proof_changing_followup" + ], + "query_sha256": "541d4fd4051dd99a69de7e01b7da921d495f4d7f3bf74a76abab47654a28b1f2", + "response_sha256": "c235cb7a89526694981b3f388145d0d313da193aa5f889db1bd394374a0815dc", + "status": "ok", + "transformed": true, + "validated": true + }, + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "source_intake" + ], + "contract_sha256": "eb5769dffc910bd50ff9e9ed9c7de43b0b86eddd5c45275ca943cb7c7e15a3bb", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:25:44.863437+00:00", + "injected": true, + "query_sha256": "6cc38b795088d0ef2cbc989b910293291542d865ef52bcc783bf31a510885724", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget", + "source_intake" + ], + "delivered_response_sha256": "677a58bc969f7fddf5ffada4fed992a365ff7f70d4d1fb6fbb89546d6322952a", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:25:56.958399+00:00", + "issues": [ + "missing_real_source_identity", + "reply_budget_exceeded" + ], + "query_sha256": "6cc38b795088d0ef2cbc989b910293291542d865ef52bcc783bf31a510885724", + "response_sha256": "8c634aa00b7f277af680557a642b28def4c6953e1cba2b208400af6f0d879ff4", + "status": "ok", + "transformed": true, + "validated": true + }, + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "identity_canonicality_readback", + "runtime_persistence" + ], + "contract_sha256": "9984a54603131c9e7c1d8ff5a395585694ce7b8dee6a2becb8b86d885201a0ff", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:25:57.128655+00:00", + "injected": true, + "query_sha256": "066f3fa52d5a2cb2fdb3b507086da3f423fc4a4a3aecef3198a629e835684c13", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "identity_canonicality_readback", + "reply_budget", + "runtime_persistence" + ], + "delivered_response_sha256": "89e3ebc4e6b99c0f63006f0dd8cd5dcc7e859acbac7e356c80661104f95cb059", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:26:07.687710+00:00", + "issues": [ + "missing_identity_canonicality_boundary", + "missing_identity_renderer_ceiling", + "missing_identity_term:canonical postgres rows", + "missing_identity_term:render/sync", + "missing_live_count_readback:identity_canonicality_readback", + "missing_proof_changing_followup" + ], + "query_sha256": "066f3fa52d5a2cb2fdb3b507086da3f423fc4a4a3aecef3198a629e835684c13", + "response_sha256": "0ccad0807802655ba1c07c9239be99707e6f942bc3ffce67d6e95e17fd82de55", + "status": "ok", + "transformed": true, + "validated": true + }, + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "proposal_state_readback", + "proposal_apply_readiness" + ], + "contract_sha256": "bac94305e31846b462d1e88f2d38f8a5dabdac969ad552655327caa7e24a4946", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:26:07.998667+00:00", + "injected": true, + "query_sha256": "e77c4943900cf44790d3e04b3042d15bd59af90b7c4ac8f77960a88a67e1a393", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "proposal_apply_readiness", + "proposal_state_readback", + "reply_budget" + ], + "delivered_response_sha256": "1bf46c88cb320a76c98cf6f5ac58eb5de4c9067b340f08ad718cf8d230969958", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:26:19.111434+00:00", + "issues": [ + "missing_live_count_readback:proposal_state_readback", + "missing_live_proposal_state:applied", + "missing_live_proposal_state:approved", + "missing_live_proposal_state:canceled", + "missing_live_proposal_state:pending_review", + "missing_proof_changing_followup", + "missing_proposal_apply_boundary" + ], + "query_sha256": "e77c4943900cf44790d3e04b3042d15bd59af90b7c4ac8f77960a88a67e1a393", + "response_sha256": "a0a8e090e4139be266799e40d5ca7d4faf6b7b984300be26318a7acfe5979259", + "status": "ok", + "transformed": true, + "validated": true + }, + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "source_link_audit" + ], + "contract_sha256": "69a06bd10a27e7cb3267fd78bcaa6a5e2d367aba01585f1201d2d234ac0a2c60", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:26:19.284029+00:00", + "injected": true, + "query_sha256": "fb6760b0c24c59549d1e05dc5aae6b86de68417a0a9ba8a123317e39b2b75542", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget", + "source_link_audit" + ], + "delivered_response_sha256": "384324a281dd9ee8ece2e770332bcda93256e0b85acc5d87e05bf429425dbad9", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:26:31.559398+00:00", + "issues": [ + "missing_live_count_readback:source_link_audit", + "missing_live_source_link_audit", + "missing_proof_changing_followup", + "missing_source_link_causality_boundary", + "reply_budget_exceeded" + ], + "query_sha256": "fb6760b0c24c59549d1e05dc5aae6b86de68417a0a9ba8a123317e39b2b75542", + "response_sha256": "581de943ce900a50422580b0d17dec8a7021afae9fc9a991f0944bc193c14c3b", + "status": "ok", + "transformed": true, + "validated": true + }, + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "mixed_packet_composition" + ], + "contract_sha256": "e93a0c035e7d4084a197d71f11bf293c695024b05944cae01d58a57eb0d595bf", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:26:31.725089+00:00", + "injected": true, + "query_sha256": "13c255fda3a35cd913ba92960bcda1b4dbcf55a38f3301bdc2a74a8eb040df23", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "mixed_packet_composition", + "reply_budget" + ], + "delivered_response_sha256": "a5ce84cd29cfb460e51e0aa0f279838b887f192b6e53b6359fd56050031290cc", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:26:41.005105+00:00", + "issues": [ + "missing_approve_claim_boundary" + ], + "query_sha256": "13c255fda3a35cd913ba92960bcda1b4dbcf55a38f3301bdc2a74a8eb040df23", + "response_sha256": "72af0639bb5b0bce6d2dde707f77a33365e96668e00865fce72e7652725ba1b2", + "status": "ok", + "transformed": true, + "validated": true + }, + { + "compiled_response_available": false, + "contract_ids": [ + "reply_budget" + ], + "contract_sha256": "6e1f1ca2cc9e2e1bd7b0e47613b528138dbb8f49481fc8f66d28d0c5a570c6ff", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:26:41.881107+00:00", + "injected": true, + "query_sha256": "1023e68558de7a9b1f8c18aab2d6d27b6343f1015f59e62e1ba20d413df9b029", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": false, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget" + ], + "delivered_response_sha256": "8ad825b7452be4e45f65b9ba4160264c82c801ea366ae971aa4b398c30ef44e8", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:26:48.202194+00:00", + "issues": [], + "query_sha256": "1023e68558de7a9b1f8c18aab2d6d27b6343f1015f59e62e1ba20d413df9b029", + "response_sha256": "8ad825b7452be4e45f65b9ba4160264c82c801ea366ae971aa4b398c30ef44e8", + "status": "ok", + "transformed": false, + "validated": true + }, + { + "compiled_response_available": false, + "contract_ids": [ + "reply_budget" + ], + "contract_sha256": "6e1f1ca2cc9e2e1bd7b0e47613b528138dbb8f49481fc8f66d28d0c5a570c6ff", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:26:52.024606+00:00", + "injected": true, + "query_sha256": "f82177233e13e13653edbcc962802b8f3431ac6e5304c2acc87aaf49a85aa877", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": false, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget" + ], + "delivered_response_sha256": "6fe482d58f144c3521c73d298cee5856b112962b9ecb2bb99e68768c3cdc9c9e", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:26:58.092766+00:00", + "issues": [], + "query_sha256": "f82177233e13e13653edbcc962802b8f3431ac6e5304c2acc87aaf49a85aa877", + "response_sha256": "6fe482d58f144c3521c73d298cee5856b112962b9ecb2bb99e68768c3cdc9c9e", + "status": "ok", + "transformed": false, + "validated": true + }, + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "telegram_participant_identity" + ], + "contract_sha256": "5e1f8d07f99442d63190f815c7e21fe272945399a802d812a5b770489ba87e21", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:27:02.195858+00:00", + "injected": true, + "query_sha256": "fb4d59cf637d1cbc16fe86e32c2b29121cd797bc6f2315d910f3f6be5eb01baa", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget", + "telegram_participant_identity" + ], + "delivered_response_sha256": "0dd5eb52bbb341322bf3bc219a7042b0b1ba22b4d671d3eb5ab581bd9f6b6ed0", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:27:08.843034+00:00", + "issues": [], + "query_sha256": "fb4d59cf637d1cbc16fe86e32c2b29121cd797bc6f2315d910f3f6be5eb01baa", + "response_sha256": "93ca109617e2851a37ebc393c0f17b87636b3faf9c815a59662f2c857ab6c3b6", + "status": "ok", + "transformed": true, + "validated": true + }, + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "runtime_persistence" + ], + "contract_sha256": "7a45eee16b75b8ba7b784442255c6be46c5f8cb130f1a3e7d896586afabbedd5", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:27:12.342019+00:00", + "injected": true, + "query_sha256": "8c415f38c4817520142cea8f71cbc7070dd0bd38d038a3262b9d5ec342538b08", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget", + "runtime_persistence" + ], + "delivered_response_sha256": "51ffcd1edaa855dff9142254a766a8afab96d53becf365ca37d9ce5256428111", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:27:26.256308+00:00", + "issues": [], + "query_sha256": "8c415f38c4817520142cea8f71cbc7070dd0bd38d038a3262b9d5ec342538b08", + "response_sha256": "f0708f46a30ff243d86199a64ef730d66be11ef0257313728bbcfa06d228592c", + "status": "ok", + "transformed": true, + "validated": true + }, + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "shared_claims_agent_positions" + ], + "contract_sha256": "d26c3c84ae833a789a166b5992fd46baf3d09912ef63f9c44e47f6f0ca422418", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:27:26.545088+00:00", + "injected": true, + "query_sha256": "eb10809662bb0cfdd194b9fdad8f84a0a93e116757b15910d454cbe9f3ffca1c", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_available": false, + "contract_ids": [ + "reply_budget" + ], + "contract_sha256": "6e1f1ca2cc9e2e1bd7b0e47613b528138dbb8f49481fc8f66d28d0c5a570c6ff", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:27:26.561869+00:00", + "injected": true, + "query_sha256": "bc56893688699c692181e4f5744061380fdf28b8132de50f67b3a9548efccdc7", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget", + "shared_claims_agent_positions" + ], + "delivered_response_sha256": "d9014065c29746c501d390c7dc39687fd6d13d64910660871b33ef3c827c2152", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:27:34.005993+00:00", + "issues": [], + "query_sha256": "eb10809662bb0cfdd194b9fdad8f84a0a93e116757b15910d454cbe9f3ffca1c", + "response_sha256": "3b44da79224c523c7b79d45643f030dbb0f4693f5228bec256d0aadd77625eea", + "status": "ok", + "transformed": true, + "validated": true + }, + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "forecast_resolution_schema" + ], + "contract_sha256": "06560b820cb3f7a20d74ff8cd99507423b5d9c476fb707e7405b335f41d4106f", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:27:36.653434+00:00", + "injected": true, + "query_sha256": "4bd553c55c0532cc0b2e606bc77e737055aa048d24b2b97f3271ab8dc301d912", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": false, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget" + ], + "delivered_response_sha256": "bb1db4a8cdb051c267036db7a811748dff001825383f223ef222c61aa9ddc377", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:27:38.994798+00:00", + "issues": [], + "query_sha256": "bc56893688699c692181e4f5744061380fdf28b8132de50f67b3a9548efccdc7", + "response_sha256": "bb1db4a8cdb051c267036db7a811748dff001825383f223ef222c61aa9ddc377", + "status": "ok", + "transformed": false, + "validated": true + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "forecast_resolution_schema", + "reply_budget" + ], + "delivered_response_sha256": "1ca0adb52dde593664e4a8fab5dfa825eaadab30cd75e1696785269f592642eb", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:27:47.469019+00:00", + "issues": [], + "query_sha256": "4bd553c55c0532cc0b2e606bc77e737055aa048d24b2b97f3271ab8dc301d912", + "response_sha256": "1bbe32c1df768cfb953ac8a2c5f94ba4e14cf5d457b1fab9efa0233664ff2887", + "status": "ok", + "transformed": true, + "validated": true + }, + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "telegram_delivery_proof" + ], + "contract_sha256": "452a547040417d2082f28a49b760775935143baeec1cf56b193033edf14ea682", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:27:47.644720+00:00", + "injected": true, + "query_sha256": "8e01f80a6eaf3e86337f8b91846ac4e40b97010c635b6e82b2ae067f8aea9406", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget", + "telegram_delivery_proof" + ], + "delivered_response_sha256": "7f47a618bcc33d0bf37ea35795e8b6a0fed6377dbfe7a4ea85144636a3df69bd", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:27:53.776725+00:00", + "issues": [], + "query_sha256": "8e01f80a6eaf3e86337f8b91846ac4e40b97010c635b6e82b2ae067f8aea9406", + "response_sha256": "4f1f01343a069f0372fb4abc17bcd84190d59da9dc190e12fa4286c12b211323", + "status": "ok", + "transformed": true, + "validated": true + }, + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "source_intake" + ], + "contract_sha256": "eb5769dffc910bd50ff9e9ed9c7de43b0b86eddd5c45275ca943cb7c7e15a3bb", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:27:57.791354+00:00", + "injected": true, + "query_sha256": "45141620c3405af992012e2bd5000cabd8a6bffbc784082e856ea1a18b6aec06", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget", + "source_intake" + ], + "delivered_response_sha256": "677a58bc969f7fddf5ffada4fed992a365ff7f70d4d1fb6fbb89546d6322952a", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:28:04.244511+00:00", + "issues": [], + "query_sha256": "45141620c3405af992012e2bd5000cabd8a6bffbc784082e856ea1a18b6aec06", + "response_sha256": "d55bbac5d9e94689f3cf10e4e333b7e3d08fd02fe28dcf1abdaf445347811f3d", + "status": "ok", + "transformed": true, + "validated": true + }, + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "claim_supersession_schema" + ], + "contract_sha256": "b919eb1012e4ea17feb215010ace5ba0ffd4d8a2b36bc221eec85ecaa1e961ea", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:28:07.946249+00:00", + "injected": true, + "query_sha256": "fa31de2bb07e50436ab09cf3c81660a1ab28ecfeb2427f4cd50522c0a1b9eaff", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "claim_supersession_schema", + "reply_budget" + ], + "delivered_response_sha256": "88ca8fd199c5dc1e7feb3b0beb95dcb0236b9f8c6783fb06c824321ea6616896", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:28:15.674969+00:00", + "issues": [], + "query_sha256": "fa31de2bb07e50436ab09cf3c81660a1ab28ecfeb2427f4cd50522c0a1b9eaff", + "response_sha256": "3548db49666f729b5073f9a874ce52cdd4cd020715594daef18605ffe9c23c44", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "database_response_transform_count": 13, + "database_response_validation_all_ok": true, + "database_response_validation_count": 16, + "db_counts_after": { + "kb_stage.kb_proposals": 29, + "public.claim_edges": 4916, + "public.claim_evidence": 4670, + "public.claims": 1837, + "public.sources": 4145 + }, + "db_counts_before": { + "kb_stage.kb_proposals": 29, + "public.claim_edges": 4916, + "public.claim_evidence": 4670, + "public.claims": 1837, + "public.sources": 4145 + }, + "db_counts_changed": false, + "generated_at_utc": "2026-07-13T20:25:23.252596+00:00", + "handler": { + "authorized": true, + "session_key": "agent:main:telegram:group:-5146042086:9070919", + "temp_profile": "/tmp/leo-direct-claim-handler-y547pi6u/profile" + }, + "harness_notes": [ + "Broad out-of-sample m3taversal prompts plus randomized memory and participant-identity checks.", + "The harness uses a temporary copy of the leoclean profile and does not post to Telegram.", + "This proves handler-level live VPS GatewayRunner behavior, not human-visible Telegram delivery." + ], + "mode": "live_vps_gatewayrunner_temp_profile_m3taversal_out_of_sample_suite", + "mutates_kb_by_harness": false, + "pass_runtime": true, + "posted_to_telegram": false, + "remote_report_path": "/tmp/leo-m3taversal-oos-handler-report-fdb197a80862.json", + "remote_returncode": 0, + "remote_run_id": "fdb197a80862", + "results": [ + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "demo_capability_readback" + ], + "contract_sha256": "28fb670425862f512082618eea335bec6d3a1bba5e96c6f2ec27096dfac2158a", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:25:27.197525+00:00", + "injected": true, + "query_sha256": "541d4fd4051dd99a69de7e01b7da921d495f4d7f3bf74a76abab47654a28b1f2", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "demo_capability_readback", + "reply_budget" + ], + "delivered_response_sha256": "aa5c738d45787efcc505e4f81bf916bb1bb38387bc5a9af18678a7230c5f6b5f", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:25:44.662055+00:00", + "issues": [ + "missing_demo_claim_ceiling", + "missing_demo_state:applied", + "missing_demo_state:approved", + "missing_demo_state:pending_review", + "missing_demo_term:artifact", + "missing_demo_term:authorization", + "missing_demo_term:postflight", + "missing_live_count_readback:demo_capability_readback", + "missing_proof_changing_followup" + ], + "query_sha256": "541d4fd4051dd99a69de7e01b7da921d495f4d7f3bf74a76abab47654a28b1f2", + "response_sha256": "c235cb7a89526694981b3f388145d0d313da193aa5f889db1bd394374a0815dc", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "dimension": "demo_pressure_without_ids", + "ended_at_utc": "2026-07-13T20:25:44.751691+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "m3taversal walks in now and says, 'Leo's database has not learned anything useful since yesterday and I cannot demo this.' Do not ask me for row IDs. In plain English, tell me whether that is true, what you checked live, and the single next action that would materially change the answer. Keep this read-only: do not stage, approve, apply, or edit anything.", + "prompt_id": "OOS-01", + "reply": "Not proven.\nFresh live readback.\nDB readback: claims: 1837; sources: 4145; claim_edges: 4916; claim_evidence: 4670; kb_proposals: 29.\nProposal states are applied: 2, approved: 3, pending_review: 16. This current snapshot does not prove what changed since yesterday, so the demo claim is limited to current readback. Existing receipt artifacts identify applied types add_edge and attach_evidence, but not a time-window delta. Approved is not applied; 3/3 approved rows are approved_needs_apply_payload and not directly applyable.\n\nNext proof-changing follow-up: build and review a strict apply_payload for the highest-impact approved proposal, then seek explicit apply authorization. Until its applied_at, public.* before/after row IDs or hashes, and postflight readback exist, do not claim the canonical database changed.", + "started_at_utc": "2026-07-13T20:25:23.990361+00:00", + "turn": 1 + }, + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "source_intake" + ], + "contract_sha256": "eb5769dffc910bd50ff9e9ed9c7de43b0b86eddd5c45275ca943cb7c7e15a3bb", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:25:44.863437+00:00", + "injected": true, + "query_sha256": "6cc38b795088d0ef2cbc989b910293291542d865ef52bcc783bf31a510885724", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget", + "source_intake" + ], + "delivered_response_sha256": "677a58bc969f7fddf5ffada4fed992a365ff7f70d4d1fb6fbb89546d6322952a", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:25:56.958399+00:00", + "issues": [ + "missing_real_source_identity", + "reply_budget_exceeded" + ], + "query_sha256": "6cc38b795088d0ef2cbc989b910293291542d865ef52bcc783bf31a510885724", + "response_sha256": "8c634aa00b7f277af680557a642b28def4c6953e1cba2b208400af6f0d879ff4", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "dimension": "multi_surface_knowledge_ingestion", + "ended_at_utc": "2026-07-13T20:25:56.989029+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "I give you a PDF, a Telegram discussion, and five tweets that all make overlapping claims about a market shift. Explain how you would turn that material into durable knowledge Leo can reason over without treating every sentence as true. Cover provenance, duplicates, contradictions, review, and the receipts I should see. Explain only; do not stage or mutate the KB.", + "prompt_id": "OOS-02", + "reply": "- VPS filesystem document preparation and source-to-proposal staging are shipped; automatic Telegram attachment capture is not shipped. Sending a report in chat does not by itself create a proposal or persistent knowledge. The Telegram attachment downloader is not connected to the filesystem preparation command.\n\n- The live bounded path is to place a text-like artifact or supplied UTF-8 extraction under the private kb-source-inbox root, then run teleo-kb prepare-source; it retrieves canonical candidates and emits an exact-quote manifest with no DB write, then run teleo-kb propose-source to validate and stage a pending_review proposal. It writes only kb_stage.kb_proposals. A chat label, filename, attachment reference, or source_ref is not provenance. Before review, deduplicate overlaps and retain exact excerpts, source caveats, uncertainty, and contradictory interpretations. Candidates are not canonical until reviewed and applied, and no public.sources or other public.* rows are created during staging.\n\n- Explicit approval begins before guarded canonical public.* apply, not before mechanical capture/staging. Receipt: locator and content hash, proposal ID/status, reviewed payload, applied_at, created row IDs, and postflight readback. Next proof-changing follow-up: run teleo-kb prepare-source, inspect its exact-quote and duplicate judgments, then run teleo-kb propose-source and review the staged candidates.", + "started_at_utc": "2026-07-13T20:25:44.766849+00:00", + "turn": 2 + }, + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "identity_canonicality_readback", + "runtime_persistence" + ], + "contract_sha256": "9984a54603131c9e7c1d8ff5a395585694ce7b8dee6a2becb8b86d885201a0ff", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:25:57.128655+00:00", + "injected": true, + "query_sha256": "066f3fa52d5a2cb2fdb3b507086da3f423fc4a4a3aecef3198a629e835684c13", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "identity_canonicality_readback", + "reply_budget", + "runtime_persistence" + ], + "delivered_response_sha256": "89e3ebc4e6b99c0f63006f0dd8cd5dcc7e859acbac7e356c80661104f95cb059", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:26:07.687710+00:00", + "issues": [ + "missing_identity_canonicality_boundary", + "missing_identity_renderer_ceiling", + "missing_identity_term:canonical postgres rows", + "missing_identity_term:render/sync", + "missing_live_count_readback:identity_canonicality_readback", + "missing_proof_changing_followup" + ], + "query_sha256": "066f3fa52d5a2cb2fdb3b507086da3f423fc4a4a3aecef3198a629e835684c13", + "response_sha256": "0ccad0807802655ba1c07c9239be99707e6f942bc3ffce67d6e95e17fd82de55", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "dimension": "identity_restart_truth", + "ended_at_utc": "2026-07-13T20:26:07.718433+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "I corrected Leo's worldview in chat and someone also edited SOUL.md. Will that correction be part of Leo's canonical identity tomorrow after a restart? Give me the exact truth test from database row to runtime artifact. Do not change either surface.", + "prompt_id": "OOS-03", + "reply": "No.\nDB readback: claims: 1837; sources: 4145; claim_edges: 4916; claim_evidence: 4670; kb_proposals: 29.\nA direct SOUL.md edit is a runtime/profile change; it does not change canonical Postgres rows in personas, strategies, beliefs, strategy_nodes, or strategy_node_anchors. A chat correction is also not canonical until it is staged, reviewed, and applied as exact identity rows. No active general DB-to-SOUL.md renderer automation is currently proven, so neither surface should be assumed to survive as identity after restart.\n\nNext proof-changing follow-up: audit the intended canonical identity rows and proposal UUID/status/applied_at, stage the exact change, review it, apply it with authorization, run or verify render/sync, then compare SOUL.md hash/content and restart readback.", + "started_at_utc": "2026-07-13T20:25:56.989524+00:00", + "turn": 3 + }, + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "proposal_state_readback", + "proposal_apply_readiness" + ], + "contract_sha256": "bac94305e31846b462d1e88f2d38f8a5dabdac969ad552655327caa7e24a4946", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:26:07.998667+00:00", + "injected": true, + "query_sha256": "e77c4943900cf44790d3e04b3042d15bd59af90b7c4ac8f77960a88a67e1a393", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "proposal_apply_readiness", + "proposal_state_readback", + "reply_budget" + ], + "delivered_response_sha256": "1bf46c88cb320a76c98cf6f5ac58eb5de4c9067b340f08ad718cf8d230969958", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:26:19.111434+00:00", + "issues": [ + "missing_live_count_readback:proposal_state_readback", + "missing_live_proposal_state:applied", + "missing_live_proposal_state:approved", + "missing_live_proposal_state:canceled", + "missing_live_proposal_state:pending_review", + "missing_proof_changing_followup", + "missing_proposal_apply_boundary" + ], + "query_sha256": "e77c4943900cf44790d3e04b3042d15bd59af90b7c4ac8f77960a88a67e1a393", + "response_sha256": "a0a8e090e4139be266799e40d5ca7d4faf6b7b984300be26318a7acfe5979259", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "dimension": "partner_demo_claim_ceiling", + "ended_at_utc": "2026-07-13T20:26:19.145284+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "Three changes have reviewer approval and the partner demo starts in an hour. Can I honestly say the knowledge database is updated? Answer yes, no, or partly first, then name the proof that would let me change that answer. Do not apply anything.", + "prompt_id": "OOS-04", + "reply": "No.\nFresh live readback.\nDB readback: claims: 1837; sources: 4145; claim_edges: 4916; claim_evidence: 4670; kb_proposals: 29.\nProposal states are applied: 2, approved: 3, pending_review: 16, canceled: 8. Approved is not applied, and 3/3 approved rows are approved_needs_apply_payload and not directly applyable. An applied proposal receipt alone does not identify the exact public.* rows changed.\n\nNext proof-changing follow-up: choose the proposal or time window, return its UUID/status/applied_at, compare the affected public.* row IDs or before/after hashes, and for approved rows normalize and review the strict payload before requesting explicit guarded-apply authorization.", + "started_at_utc": "2026-07-13T20:26:07.719276+00:00", + "turn": 4 + }, + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "source_link_audit" + ], + "contract_sha256": "69a06bd10a27e7cb3267fd78bcaa6a5e2d367aba01585f1201d2d234ac0a2c60", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:26:19.284029+00:00", + "injected": true, + "query_sha256": "fb6760b0c24c59549d1e05dc5aae6b86de68417a0a9ba8a123317e39b2b75542", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget", + "source_link_audit" + ], + "delivered_response_sha256": "384324a281dd9ee8ece2e770332bcda93256e0b85acc5d87e05bf429425dbad9", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:26:31.559398+00:00", + "issues": [ + "missing_live_count_readback:source_link_audit", + "missing_live_source_link_audit", + "missing_proof_changing_followup", + "missing_source_link_causality_boundary", + "reply_budget_exceeded" + ], + "query_sha256": "fb6760b0c24c59549d1e05dc5aae6b86de68417a0a9ba8a123317e39b2b75542", + "response_sha256": "581de943ce900a50422580b0d17dec8a7021afae9fc9a991f0944bc193c14c3b", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "dimension": "source_pointer_needs_canonical_link_audit", + "ended_at_utc": "2026-07-13T20:26:31.591776+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "A proposal points to a Telegram attachment and its extracted text exists on disk. Does that mean the claim already has canonical evidence? Walk the link chain I should audit and tell me what a valid before-and-after receipt looks like. Read-only only.", + "prompt_id": "OOS-05", + "reply": "No. The attachment does not itself create canonical evidence; neither does extracted text on disk.\nDB readback: claims: 1837; sources: 4145; claim_edges: 4916; claim_evidence: 4670; kb_proposals: 29.\nThe live row-link audit found 19 pending/approved proposals: 19 have source_ref and 0 exactly match a public.sources ID, URL, or storage_path. Pending status therefore is not by itself proof of a bad document pointer.\n\nAudit telegram_file_refs/raw files -> document_evaluations -> kb_proposals.source_ref -> public.sources -> claim_evidence. Canonical linkage and provenance quality are separate: a canonical link can still point to a weak, untraceable source with no URL/storage_path or raw artifact. Before/after receipt: proposal UUID/status/source_ref, source and claim_evidence row IDs, locator/hash, applied_at, and postflight. Next proof-changing follow-up: list each broken layer, then stage only the missing guarded source/evidence contract.", + "started_at_utc": "2026-07-13T20:26:19.145938+00:00", + "turn": 5 + }, + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "mixed_packet_composition" + ], + "contract_sha256": "e93a0c035e7d4084a197d71f11bf293c695024b05944cae01d58a57eb0d595bf", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:26:31.725089+00:00", + "injected": true, + "query_sha256": "13c255fda3a35cd913ba92960bcda1b4dbcf55a38f3301bdc2a74a8eb040df23", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "mixed_packet_composition", + "reply_budget" + ], + "delivered_response_sha256": "a5ce84cd29cfb460e51e0aa0f279838b887f192b6e53b6359fd56050031290cc", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:26:41.005105+00:00", + "issues": [ + "missing_approve_claim_boundary" + ], + "query_sha256": "13c255fda3a35cd913ba92960bcda1b4dbcf55a38f3301bdc2a74a8eb040df23", + "response_sha256": "72af0639bb5b0bce6d2dde707f77a33365e96668e00865fce72e7652725ba1b2", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "dimension": "database_composition_judgment", + "ended_at_utc": "2026-07-13T20:26:41.745714+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "Suppose a new research packet contains factual observations, a strategic framework, a disputed interpretation, a governance rule, and a correction to an old belief. How should Leo compose the database so it can reason over the packet later without flattening it all into claims? Give the review and apply sequence too, but do not write anything now.", + "prompt_id": "OOS-06", + "reply": "- Map factual observations and disputed interpretations to claims plus sources and evidence; keep competing claims queryable through claim-to-claim edges. Store the strategic framework in reasoning_tools. Put the governance rule in behavioral_rules using rule, rationale, category, rank, and agent_id unless it defines criteria, an evidence_bar, and a pass_condition, in which case use governance_gates. Stage the correction to the old belief as a beliefs update; claim_edges never point to reasoning_tools or beliefs.\n\n- Stage one typed pending_review proposal with exact rows and no canonical writes. Review mappings, evidence, claim-only edge endpoints, and unsupported changes. After explicit authorization, approve_claim applies only claims, sources, evidence, edges, and reasoning_tools. approve_claim supports neither behavioral_rules nor governance_gates; those tables, belief updates, and existing-row updates remain staged until a separate reviewed apply capability exists. The contract keeps behavioral_rules, governance_gates, belief updates, and existing-row updates outside this apply.\n\n- Receipt: proposal-level applied_at, created or updated row IDs, and a postflight readback. Until those exist, staged or approved content is not live canonical knowledge.", + "started_at_utc": "2026-07-13T20:26:31.593167+00:00", + "turn": 6 + }, + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": false, + "contract_ids": [ + "reply_budget" + ], + "contract_sha256": "6e1f1ca2cc9e2e1bd7b0e47613b528138dbb8f49481fc8f66d28d0c5a570c6ff", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:26:41.881107+00:00", + "injected": true, + "query_sha256": "1023e68558de7a9b1f8c18aab2d6d27b6343f1015f59e62e1ba20d413df9b029", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": false, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget" + ], + "delivered_response_sha256": "8ad825b7452be4e45f65b9ba4160264c82c801ea366ae971aa4b398c30ef44e8", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:26:48.202194+00:00", + "issues": [], + "query_sha256": "1023e68558de7a9b1f8c18aab2d6d27b6343f1015f59e62e1ba20d413df9b029", + "response_sha256": "8ad825b7452be4e45f65b9ba4160264c82c801ea366ae971aa4b398c30ef44e8", + "status": "ok", + "transformed": false, + "validated": true + } + ], + "dimension": "same_session_memory_set", + "ended_at_utc": "2026-07-13T20:26:51.889010+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "From everything you checked in this conversation, pick the single highest-impact demo blocker. For the next question, remember it under the temporary label demo-ledger-08ceb27e. State the label and blocker now. This is chat memory only; do not write it to the KB.", + "prompt_id": "OOS-07", + "reply": "Label: demo-ledger-08ceb27e\n\nBlocker: All 3 approved proposals are in approved_needs_apply_payload state. No apply has run. public.* row counts are unchanged from session open. You cannot honestly tell a partner the knowledge database is updated until at least one approved proposal completes a guarded apply with a confirmed applied_at, affected row IDs, and postflight readback.", + "started_at_utc": "2026-07-13T20:26:41.747107+00:00", + "turn": 7 + }, + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": false, + "contract_ids": [ + "reply_budget" + ], + "contract_sha256": "6e1f1ca2cc9e2e1bd7b0e47613b528138dbb8f49481fc8f66d28d0c5a570c6ff", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:26:52.024606+00:00", + "injected": true, + "query_sha256": "f82177233e13e13653edbcc962802b8f3431ac6e5304c2acc87aaf49a85aa877", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": false, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget" + ], + "delivered_response_sha256": "6fe482d58f144c3521c73d298cee5856b112962b9ecb2bb99e68768c3cdc9c9e", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:26:58.092766+00:00", + "issues": [], + "query_sha256": "f82177233e13e13653edbcc962802b8f3431ac6e5304c2acc87aaf49a85aa877", + "response_sha256": "6fe482d58f144c3521c73d298cee5856b112962b9ecb2bb99e68768c3cdc9c9e", + "status": "ok", + "transformed": false, + "validated": true + } + ], + "dimension": "same_session_memory_recall", + "ended_at_utc": "2026-07-13T20:27:02.047890+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "Without re-reading my previous wording, what temporary label did I give the demo blocker, what blocker did you associate with it, and what exact proof would close it? Do not mutate anything.", + "prompt_id": "OOS-08", + "reply": "Label: demo-ledger-08ceb27e\n\nBlocker: All 3 approved proposals are stuck in approved_needs_apply_payload. No guarded apply has run. public.* row counts are unchanged from session open \u2014 claims 1837, sources 4145, claim_evidence 4670.\n\nProof that closes it: one approved proposal completes a guarded apply and returns a confirmed applied_at timestamp, the specific created or updated public.* row IDs, and a postflight readback showing at least one of those counts has moved. Until those three receipts exist together, the demo claim \"the knowledge database is updated\" remains false.", + "started_at_utc": "2026-07-13T20:26:51.890215+00:00", + "turn": 8 + }, + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "telegram_participant_identity" + ], + "contract_sha256": "5e1f8d07f99442d63190f815c7e21fe272945399a802d812a5b770489ba87e21", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:27:02.195858+00:00", + "injected": true, + "query_sha256": "fb4d59cf637d1cbc16fe86e32c2b29121cd797bc6f2315d910f3f6be5eb01baa", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget", + "telegram_participant_identity" + ], + "delivered_response_sha256": "0dd5eb52bbb341322bf3bc219a7042b0b1ba22b4d671d3eb5ab581bd9f6b6ed0", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:27:08.843034+00:00", + "issues": [], + "query_sha256": "fb4d59cf637d1cbc16fe86e32c2b29121cd797bc6f2315d910f3f6be5eb01baa", + "response_sha256": "93ca109617e2851a37ebc393c0f17b87636b3faf9c815a59662f2c857ab6c3b6", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "dimension": "telegram_participant_identity", + "ended_at_utc": "2026-07-13T20:27:12.200634+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "The current visible Telegram sender is @m3taversal. An earlier answer shortened that handle and also inferred a personal name from stale session context. What should Leo call this participant, which identity sources are allowed, and how should Leo avoid mixing identities when another user replies? Answer in four lines. Do not write to memory or the KB.", + "prompt_id": "OOS-09", + "reply": "Call the current Telegram sender m3taversal, exactly as their visible handle identifies them.\nAllowed identity sources: the current message sender handle and that participant's explicit in-chat correction.\nDo not use stale session context, environment labels, inferred personal names, or another participant's profile.\nWhen another user replies, never transfer or mix identities; re-anchor to that message's visible sender handle.", + "started_at_utc": "2026-07-13T20:27:02.048932+00:00", + "turn": 9 + }, + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "runtime_persistence" + ], + "contract_sha256": "7a45eee16b75b8ba7b784442255c6be46c5f8cb130f1a3e7d896586afabbedd5", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:27:12.342019+00:00", + "injected": true, + "query_sha256": "8c415f38c4817520142cea8f71cbc7070dd0bd38d038a3262b9d5ec342538b08", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget", + "runtime_persistence" + ], + "delivered_response_sha256": "51ffcd1edaa855dff9142254a766a8afab96d53becf365ca37d9ce5256428111", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:27:26.256308+00:00", + "issues": [], + "query_sha256": "8c415f38c4817520142cea8f71cbc7070dd0bd38d038a3262b9d5ec342538b08", + "response_sha256": "f0708f46a30ff243d86199a64ef730d66be11ef0257313728bbcfa06d228592c", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "dimension": "runtime_vs_canonical_causality", + "ended_at_utc": "2026-07-13T20:27:26.304658+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "The five database totals are unchanged after a restart. Does that prove Leo's answer behavior is unchanged and that every fact from the prior session was erased? Explain which persisted and deployed surfaces can affect the answer, and separate the proof tiers. Read-only; keep it under 180 words.", + "prompt_id": "OOS-10", + "reply": "No. Unchanged database totals do not prove unchanged rows or unchanged answer behavior, and a restart does not necessarily erase prior-session facts. Compare row IDs, timestamps, and hashes, not counts alone; balanced inserts, updates, or deletes can leave totals unchanged.\n\nPersisted or deployed answer inputs include Postgres rows, skills, runtime config, SOUL.md, state.db, and session JSONL. state.db/session JSONL can preserve durable session continuity across a restart, while a changed skill or runtime artifact can change the answer with identical database totals.\n\nProof tiers: 1) canonical: public.* row/hash readback; 2) handler: the deployed runtime answers the same prompt with retained trace; 3) Telegram: a visible reply with message ID, timestamp, and chat/sender readback. Only a reviewed apply plus row-level postflight proves a database mutation.", + "started_at_utc": "2026-07-13T20:27:12.201683+00:00", + "turn": 10 + }, + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "shared_claims_agent_positions" + ], + "contract_sha256": "d26c3c84ae833a789a166b5992fd46baf3d09912ef63f9c44e47f6f0ca422418", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:27:26.545088+00:00", + "injected": true, + "query_sha256": "eb10809662bb0cfdd194b9fdad8f84a0a93e116757b15910d454cbe9f3ffca1c", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_available": false, + "contract_ids": [ + "reply_budget" + ], + "contract_sha256": "6e1f1ca2cc9e2e1bd7b0e47613b528138dbb8f49481fc8f66d28d0c5a570c6ff", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:27:26.561869+00:00", + "injected": true, + "query_sha256": "bc56893688699c692181e4f5744061380fdf28b8132de50f67b3a9548efccdc7", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget", + "shared_claims_agent_positions" + ], + "delivered_response_sha256": "d9014065c29746c501d390c7dc39687fd6d13d64910660871b33ef3c827c2152", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:27:34.005993+00:00", + "issues": [], + "query_sha256": "eb10809662bb0cfdd194b9fdad8f84a0a93e116757b15910d454cbe9f3ffca1c", + "response_sha256": "3b44da79224c523c7b79d45643f030dbb0f4693f5228bec256d0aadd77625eea", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "dimension": "shared_claims_agent_positions", + "ended_at_utc": "2026-07-13T20:27:36.515033+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "Two agents read the same evidence and reach different conclusions. Should Leo duplicate the factual claim once per agent, or keep shared knowledge and represent agent-specific positions elsewhere? Give the current-schema answer and how disagreement remains queryable. Do not write anything.", + "prompt_id": "OOS-11", + "reply": "Store one factual claim once as shared knowledge with shared sources/evidence; do not duplicate the claim per agent. Record each agent-specific position in public.beliefs with agent_id, statement, confidence, falsifier, and status.\n\nThe current-schema gap matters: public.beliefs has no claim-ID foreign key and there is no belief-edge table. claim_edges connects claims only, so do not invent belief-to-claim or belief-to-belief edges. Disagreement remains queryable by retrieving the shared factual claim/evidence and semantically matching each agent's belief rows; a future reviewed schema proposal can add an explicit link if needed.", + "started_at_utc": "2026-07-13T20:27:26.306784+00:00", + "turn": 11 + }, + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "forecast_resolution_schema" + ], + "contract_sha256": "06560b820cb3f7a20d74ff8cd99507423b5d9c476fb707e7405b335f41d4106f", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:27:36.653434+00:00", + "injected": true, + "query_sha256": "4bd553c55c0532cc0b2e606bc77e737055aa048d24b2b97f3271ab8dc301d912", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": false, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget" + ], + "delivered_response_sha256": "bb1db4a8cdb051c267036db7a811748dff001825383f223ef222c61aa9ddc377", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:27:38.994798+00:00", + "issues": [], + "query_sha256": "bc56893688699c692181e4f5744061380fdf28b8132de50f67b3a9548efccdc7", + "response_sha256": "bb1db4a8cdb051c267036db7a811748dff001825383f223ef222c61aa9ddc377", + "status": "ok", + "transformed": false, + "validated": true + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "forecast_resolution_schema", + "reply_budget" + ], + "delivered_response_sha256": "1ca0adb52dde593664e4a8fab5dfa825eaadab30cd75e1696785269f592642eb", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:27:47.469019+00:00", + "issues": [], + "query_sha256": "4bd553c55c0532cc0b2e606bc77e737055aa048d24b2b97f3271ab8dc301d912", + "response_sha256": "1bbe32c1df768cfb953ac8a2c5f94ba4e14cf5d457b1fab9efa0233664ff2887", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "dimension": "forecast_resolution_without_rewriting_history", + "ended_at_utc": "2026-07-13T20:27:47.504390+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "An old claim recorded a 60% forecast but never defined resolution criteria. The event is now over. What may Leo record in the current database without rewriting history, and what needs a schema proposal? Do not apply anything.", + "prompt_id": "OOS-12", + "reply": "Preserve the original 60% forecast; do not overwrite it. Because it defined no resolution criteria, its outcome remains ambiguous. Leo may add a sourced explanatory claim about the observed event, but must not retroactively label the forecast resolved.\n\nCurrent public.claims columns are id, type, text, status, confidence, tags, created_by, superseded_by, created_at, and updated_at; there is no forecast-resolution or resolved_at field. Current public.claim_edges columns are id, from_claim, to_claim, edge_type, weight, created_by, and created_at; there is no `resolves` edge type. Stage a reviewed schema proposal for explicit criteria, outcome, resolved_at, resolver/provenance, and a valid link contract. Do not apply or invent those fields in v1.", + "started_at_utc": "2026-07-13T20:27:36.516895+00:00", + "turn": 12 + }, + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "telegram_delivery_proof" + ], + "contract_sha256": "452a547040417d2082f28a49b760775935143baeec1cf56b193033edf14ea682", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:27:47.644720+00:00", + "injected": true, + "query_sha256": "8e01f80a6eaf3e86337f8b91846ac4e40b97010c635b6e82b2ae067f8aea9406", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget", + "telegram_delivery_proof" + ], + "delivered_response_sha256": "7f47a618bcc33d0bf37ea35795e8b6a0fed6377dbfe7a4ea85144636a3df69bd", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:27:53.776725+00:00", + "issues": [], + "query_sha256": "8e01f80a6eaf3e86337f8b91846ac4e40b97010c635b6e82b2ae067f8aea9406", + "response_sha256": "4f1f01343a069f0372fb4abc17bcd84190d59da9dc190e12fa4286c12b211323", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "dimension": "handler_is_not_telegram_delivery", + "ended_at_utc": "2026-07-13T20:27:57.654096+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "A temporary-profile GatewayRunner answered every test prompt, but the run explicitly posted nothing to Telegram. Can I tell a partner the Telegram path is proven live? Answer first, then state exactly what this run proves and the smallest test that closes the gap.", + "prompt_id": "OOS-13", + "reply": "No. A temporary-profile GatewayRunner response proves handler execution, model/plugin integration, and reply construction only. Because it posted nothing, it does not prove Telegram delivery or a Telegram-visible reply.\n\nThe smallest closing test is one explicitly authorized test message in the intended chat, followed by Leo's visible reply. Retain a delivery receipt with the outgoing and reply message IDs, timestamps, chat ID/title, sender handle, reply linkage, and a post-send readback. Then remove the temporary profile and verify no orphan process remains.", + "started_at_utc": "2026-07-13T20:27:47.505628+00:00", + "turn": 13 + }, + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "source_intake" + ], + "contract_sha256": "eb5769dffc910bd50ff9e9ed9c7de43b0b86eddd5c45275ca943cb7c7e15a3bb", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:27:57.791354+00:00", + "injected": true, + "query_sha256": "45141620c3405af992012e2bd5000cabd8a6bffbc784082e856ea1a18b6aec06", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "reply_budget", + "source_intake" + ], + "delivered_response_sha256": "677a58bc969f7fddf5ffada4fed992a365ff7f70d4d1fb6fbb89546d6322952a", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:28:04.244511+00:00", + "issues": [], + "query_sha256": "45141620c3405af992012e2bd5000cabd8a6bffbc784082e856ea1a18b6aec06", + "response_sha256": "d55bbac5d9e94689f3cf10e4e333b7e3d08fd02fe28dcf1abdaf445347811f3d", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "dimension": "autonomous_source_intake_boundary", + "ended_at_utc": "2026-07-13T20:28:07.796628+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "I hand Leo a document and say: absorb this as far as safely possible without making me approve every mechanical step. What can Leo capture and stage immediately, what real source identity must be retained, and where does explicit approval begin? Explain only; do not ingest this prompt.", + "prompt_id": "OOS-14", + "reply": "- VPS filesystem document preparation and source-to-proposal staging are shipped; automatic Telegram attachment capture is not shipped. Sending a report in chat does not by itself create a proposal or persistent knowledge. The Telegram attachment downloader is not connected to the filesystem preparation command.\n\n- The live bounded path is to place a text-like artifact or supplied UTF-8 extraction under the private kb-source-inbox root, then run teleo-kb prepare-source; it retrieves canonical candidates and emits an exact-quote manifest with no DB write, then run teleo-kb propose-source to validate and stage a pending_review proposal. It writes only kb_stage.kb_proposals. A chat label, filename, attachment reference, or source_ref is not provenance. Before review, deduplicate overlaps and retain exact excerpts, source caveats, uncertainty, and contradictory interpretations. Candidates are not canonical until reviewed and applied, and no public.sources or other public.* rows are created during staging.\n\n- Explicit approval begins before guarded canonical public.* apply, not before mechanical capture/staging. Receipt: locator and content hash, proposal ID/status, reviewed payload, applied_at, created row IDs, and postflight readback. Next proof-changing follow-up: run teleo-kb prepare-source, inspect its exact-quote and duplicate judgments, then run teleo-kb propose-source and review the staged candidates.", + "started_at_utc": "2026-07-13T20:27:57.656468+00:00", + "turn": 14 + }, + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "claim_supersession_schema" + ], + "contract_sha256": "b919eb1012e4ea17feb215010ace5ba0ffd4d8a2b36bc221eec85ecaa1e961ea", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-13T20:28:07.946249+00:00", + "injected": true, + "query_sha256": "fa31de2bb07e50436ab09cf3c81660a1ab28ecfeb2427f4cd50522c0a1b9eaff", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "claim_supersession_schema", + "reply_budget" + ], + "delivered_response_sha256": "88ca8fd199c5dc1e7feb3b0beb95dcb0236b9f8c6783fb06c824321ea6616896", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-13T20:28:15.674969+00:00", + "issues": [], + "query_sha256": "fa31de2bb07e50436ab09cf3c81660a1ab28ecfeb2427f4cd50522c0a1b9eaff", + "response_sha256": "3548db49666f729b5073f9a874ce52cdd4cd020715594daef18605ffe9c23c44", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "dimension": "schema_valid_supersession", + "ended_at_utc": "2026-07-13T20:28:17.947449+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "A canonical claim is wrong. I want the replacement, an explanation, and the old claim visibly retired. In current v1, which exact claim and edge fields exist, which requested writes fit approve_claim, and which require a separate reviewed apply capability? Do not mutate anything.", + "prompt_id": "OOS-15", + "reply": "Current public.claims fields: id, type, text, status, confidence, tags, created_by, superseded_by, created_at, and updated_at. Current claim_edges fields: id, from_claim, to_claim, edge_type, weight, created_by, and created_at; the edge has no rationale field, and `supersedes` is valid in the live edge_type enum.\n\napprove_claim can insert the replacement claim and a claim-to-claim supersedes edge using from_claim, to_claim, edge_type, weight, and created_by. Put the explanation in sourced evidence or an explanatory claim. Updating the existing old claim's status or superseded_by to visibly retire it requires a separate reviewed apply capability; approve_claim does not update those fields. Receipt: proposal applied_at, new claim/edge IDs, old-claim before/after, and postflight readback.", + "started_at_utc": "2026-07-13T20:28:07.798119+00:00", + "turn": 15 + } + ], + "service_before_after": { + "after": { + "ActiveState": "active", + "ExecMainStartTimestamp": "Mon 2026-07-13 19:50:24 UTC", + "MainPID": "2826463", + "NRestarts": "0", + "SubState": "running" + }, + "before": { + "ActiveState": "active", + "ExecMainStartTimestamp": "Mon 2026-07-13 19:50:24 UTC", + "MainPID": "2826463", + "NRestarts": "0", + "SubState": "running" + }, + "unchanged_from_preexisting_live_readback": true + }, + "source": { + "chat_id": "-5146042086", + "chat_name": "Leo", + "chat_type": "group", + "platform": "telegram", + "user_id": "9070919", + "user_name": "codex handler direct claim" + }, + "source_report_path": "/private/tmp/teleo-source-reference-repair-20260713/docs/reports/leo-working-state-20260709/telegram-handler-m3taversal-oos-suite-current.json", + "temp_profile_removed": true +} diff --git a/docs/reports/leo-working-state-20260709/telegram-handler-m3taversal-oos-suite-score-current.json b/docs/reports/leo-working-state-20260709/telegram-handler-m3taversal-oos-suite-score-current.json new file mode 100644 index 0000000..c26f804 --- /dev/null +++ b/docs/reports/leo-working-state-20260709/telegram-handler-m3taversal-oos-suite-score-current.json @@ -0,0 +1,568 @@ +{ + "database_context_all_ok": true, + "database_context_injection_count": 16, + "database_response_transform_count": 13, + "database_response_validation_all_ok": true, + "database_response_validation_count": 16, + "db_counts_changed": false, + "generated_at_utc": "2026-07-13T20:28:22.009570+00:00", + "memory_token": "demo-ledger-08ceb27e", + "mode": "working_leo_m3taversal_out_of_sample_live_vps_handler_score", + "posted_to_telegram": false, + "production_db_apply_ran": false, + "score": { + "expected_prompt_count": 15, + "expected_prompt_ids": [ + "OOS-01", + "OOS-02", + "OOS-03", + "OOS-04", + "OOS-05", + "OOS-06", + "OOS-07", + "OOS-08", + "OOS-09", + "OOS-10", + "OOS-11", + "OOS-12", + "OOS-13", + "OOS-14", + "OOS-15" + ], + "failures": [], + "memory_continuity": { + "recall_overlap_terms": [ + "apply", + "approved", + "approved_needs_apply_payload", + "counts", + "from", + "guarded", + "open", + "proposals", + "public", + "session", + "unchanged" + ], + "required_overlap": 3, + "same_blocker_recalled": true, + "source_blocker_clause": "All 3 approved proposals are in approved_needs_apply_payload state. No apply has run. public.* row counts are unchanged from session open. You cannot honestly tell a partner the knowledge database is updated until at least one approved proposal completes a guarded apply with a confirmed applied_at, affected row IDs, and postflight readback.", + "source_blocker_terms": [ + "affected", + "applied_at", + "apply", + "approved", + "approved_needs_apply_payload", + "cannot", + "completes", + "confirmed", + "counts", + "database", + "from", + "guarded", + "honestly", + "knowledge", + "least", + "open", + "partner", + "postflight", + "proposal", + "proposals", + "public", + "readback", + "session", + "state", + "tell", + "unchanged", + "until", + "updated" + ], + "source_reply_sha256": "8ad825b7452be4e45f65b9ba4160264c82c801ea366ae971aa4b398c30ef44e8" + }, + "missing_prompt_ids": [], + "pass": true, + "passes": 15, + "prompt_count": 15, + "scores": [ + { + "behavioral_rule_schema_issues": [], + "broad_semantic_issues": [], + "composition_capability_issues": [], + "concepts": { + "canonical_readback": true, + "live_check": true, + "material_action": true, + "state_boundary": true + }, + "current_schema_overclaims": [], + "custom_signals": {}, + "dimension": "demo_pressure_without_ids", + "invalid_count_invariant_detected": false, + "legacy_pass": true, + "legacy_signals": { + "canonical_db": true, + "fresh_readback": true, + "next_action": true, + "no_overclaim": true, + "state_semantics": true + }, + "max_response_words": 220, + "overclaim_detected": false, + "pass": true, + "prompt_id": "OOS-01", + "proposal_readiness_issues": [], + "response_issue_detected": false, + "response_too_long": false, + "source_evidence_semantic_issues": [], + "source_intake_issues": [], + "word_count": 113 + }, + { + "behavioral_rule_schema_issues": [], + "broad_semantic_issues": [], + "composition_capability_issues": [], + "concepts": { + "candidate_before_canonical": true, + "contradiction": true, + "deduplication": true, + "provenance": true, + "receipt": true, + "staged_review_apply": true + }, + "current_schema_overclaims": [], + "custom_signals": {}, + "dimension": "multi_surface_knowledge_ingestion", + "invalid_count_invariant_detected": false, + "legacy_pass": true, + "legacy_signals": { + "canonical_db": true, + "caveat_retention": true, + "document_artifact_linking": true, + "next_action": true, + "no_overclaim": true, + "staging_or_review": true + }, + "max_response_words": 220, + "overclaim_detected": false, + "pass": true, + "prompt_id": "OOS-02", + "proposal_readiness_issues": [], + "response_issue_detected": false, + "response_too_long": false, + "source_evidence_semantic_issues": [], + "source_intake_issues": [], + "word_count": 191 + }, + { + "behavioral_rule_schema_issues": [], + "broad_semantic_issues": [], + "composition_capability_issues": [], + "concepts": { + "identity_chain": true, + "identity_rows_beyond_claims": true, + "receipt": true, + "state_boundary": true + }, + "current_schema_overclaims": [], + "custom_signals": {}, + "dimension": "identity_restart_truth", + "invalid_count_invariant_detected": false, + "legacy_pass": true, + "legacy_signals": { + "canonical_db": true, + "identity_rendering": true, + "no_overclaim": true, + "row_level_proof": true + }, + "max_response_words": 220, + "overclaim_detected": false, + "pass": true, + "prompt_id": "OOS-03", + "proposal_readiness_issues": [], + "response_issue_detected": false, + "response_too_long": false, + "source_evidence_semantic_issues": [], + "source_intake_issues": [], + "word_count": 115 + }, + { + "behavioral_rule_schema_issues": [], + "broad_semantic_issues": [], + "composition_capability_issues": [], + "concepts": { + "canonical_readback": true, + "receipt": true, + "state_boundary": true + }, + "current_schema_overclaims": [], + "custom_signals": {}, + "dimension": "partner_demo_claim_ceiling", + "invalid_count_invariant_detected": false, + "legacy_pass": true, + "legacy_signals": { + "artifact": true, + "canonical_db": true, + "no_overclaim": true, + "row_level_proof": true, + "state_semantics": true + }, + "max_response_words": 220, + "overclaim_detected": false, + "pass": true, + "prompt_id": "OOS-04", + "proposal_readiness_issues": [], + "response_issue_detected": false, + "response_too_long": false, + "source_evidence_semantic_issues": [], + "source_intake_issues": [], + "word_count": 94 + }, + { + "behavioral_rule_schema_issues": [], + "broad_semantic_issues": [], + "composition_capability_issues": [], + "concepts": { + "canonical_evidence_boundary": true, + "evidence_provenance_quality": true, + "receipt": true, + "source_evidence_chain": true, + "staged_review_apply": true + }, + "current_schema_overclaims": [], + "custom_signals": {}, + "dimension": "source_pointer_needs_canonical_link_audit", + "invalid_count_invariant_detected": false, + "legacy_pass": true, + "legacy_signals": { + "canonical_db": true, + "document_artifact_linking": true, + "no_overclaim": true, + "row_level_proof": true, + "staging_or_review": true + }, + "max_response_words": 220, + "overclaim_detected": false, + "pass": true, + "prompt_id": "OOS-05", + "proposal_readiness_issues": [], + "response_issue_detected": false, + "response_too_long": false, + "source_evidence_semantic_issues": [], + "source_intake_issues": [], + "word_count": 131 + }, + { + "behavioral_rule_schema_issues": [], + "broad_semantic_issues": [], + "composition_capability_issues": [], + "concepts": { + "behavioral_rule_storage": true, + "heterogeneous_types": true, + "receipt": true, + "reviewed_policy_apply": true, + "staged_review_apply": true + }, + "current_schema_overclaims": [], + "custom_signals": {}, + "dimension": "database_composition_judgment", + "invalid_count_invariant_detected": false, + "legacy_pass": false, + "legacy_signals": { + "canonical_db": true, + "caveat_retention": false, + "next_action": false, + "no_overclaim": false, + "staging_or_review": false + }, + "max_response_words": 220, + "overclaim_detected": false, + "pass": true, + "prompt_id": "OOS-06", + "proposal_readiness_issues": [], + "response_issue_detected": false, + "response_too_long": false, + "source_evidence_semantic_issues": [], + "source_intake_issues": [], + "word_count": 162 + }, + { + "behavioral_rule_schema_issues": [], + "broad_semantic_issues": [], + "composition_capability_issues": [], + "concepts": { + "blocker_definition": true + }, + "current_schema_overclaims": [], + "custom_signals": { + "memory_token": true + }, + "dimension": "same_session_memory_set", + "invalid_count_invariant_detected": false, + "legacy_pass": false, + "legacy_signals": { + "next_action": false, + "no_overclaim": false + }, + "max_response_words": 220, + "overclaim_detected": false, + "pass": true, + "prompt_id": "OOS-07", + "proposal_readiness_issues": [], + "response_issue_detected": false, + "response_too_long": false, + "source_evidence_semantic_issues": [], + "source_intake_issues": [], + "word_count": 54 + }, + { + "behavioral_rule_schema_issues": [], + "broad_semantic_issues": [], + "composition_capability_issues": [], + "concepts": { + "blocker_definition": true, + "receipt": true + }, + "current_schema_overclaims": [], + "custom_signals": { + "closure_proof": true, + "memory_token": true, + "same_blocker_recalled": true + }, + "dimension": "same_session_memory_recall", + "invalid_count_invariant_detected": false, + "legacy_pass": false, + "legacy_signals": { + "next_action": false, + "no_overclaim": false, + "row_level_proof": true + }, + "max_response_words": 220, + "overclaim_detected": false, + "pass": true, + "prompt_id": "OOS-08", + "proposal_readiness_issues": [], + "response_issue_detected": false, + "response_too_long": false, + "source_evidence_semantic_issues": [], + "source_intake_issues": [], + "word_count": 84 + }, + { + "behavioral_rule_schema_issues": [], + "broad_semantic_issues": [], + "composition_capability_issues": [], + "concepts": {}, + "current_schema_overclaims": [], + "custom_signals": { + "current_update_identity_boundary": true, + "exact_participant_handle": true, + "no_cross_participant_identity_bleed": true, + "no_unverified_alias": true + }, + "dimension": "telegram_participant_identity", + "invalid_count_invariant_detected": false, + "legacy_pass": false, + "legacy_signals": { + "no_overclaim": false + }, + "max_response_words": 100, + "overclaim_detected": false, + "pass": true, + "prompt_id": "OOS-09", + "proposal_readiness_issues": [], + "response_issue_detected": false, + "response_too_long": false, + "source_evidence_semantic_issues": [], + "source_intake_issues": [], + "word_count": 58 + }, + { + "behavioral_rule_schema_issues": [], + "broad_semantic_issues": [], + "composition_capability_issues": [], + "concepts": { + "durable_session_continuity": true, + "proof_tiers": true, + "row_content_proof": true, + "runtime_inputs": true + }, + "current_schema_overclaims": [], + "custom_signals": {}, + "dimension": "runtime_vs_canonical_causality", + "invalid_count_invariant_detected": false, + "legacy_pass": false, + "legacy_signals": { + "canonical_db": true, + "no_overclaim": false + }, + "max_response_words": 180, + "overclaim_detected": false, + "pass": true, + "prompt_id": "OOS-10", + "proposal_readiness_issues": [], + "response_issue_detected": false, + "response_too_long": false, + "source_evidence_semantic_issues": [], + "source_intake_issues": [], + "word_count": 129 + }, + { + "behavioral_rule_schema_issues": [], + "broad_semantic_issues": [], + "composition_capability_issues": [], + "concepts": { + "agent_specific_positions": true, + "contradiction": true, + "shared_knowledge_commons": true + }, + "current_schema_overclaims": [], + "custom_signals": {}, + "dimension": "shared_claims_agent_positions", + "invalid_count_invariant_detected": false, + "legacy_pass": false, + "legacy_signals": { + "canonical_db": true, + "caveat_retention": false, + "no_overclaim": true + }, + "max_response_words": 220, + "overclaim_detected": false, + "pass": true, + "prompt_id": "OOS-11", + "proposal_readiness_issues": [], + "response_issue_detected": false, + "response_too_long": false, + "source_evidence_semantic_issues": [], + "source_intake_issues": [], + "word_count": 91 + }, + { + "behavioral_rule_schema_issues": [], + "broad_semantic_issues": [], + "composition_capability_issues": [], + "concepts": { + "forecast_history": true, + "forecast_schema_gap": true, + "staged_review_apply": true + }, + "current_schema_overclaims": [], + "custom_signals": {}, + "dimension": "forecast_resolution_without_rewriting_history", + "invalid_count_invariant_detected": false, + "legacy_pass": false, + "legacy_signals": { + "canonical_db": true, + "caveat_retention": false, + "no_overclaim": false, + "staging_or_review": false + }, + "max_response_words": 220, + "overclaim_detected": false, + "pass": true, + "prompt_id": "OOS-12", + "proposal_readiness_issues": [], + "response_issue_detected": false, + "response_too_long": false, + "source_evidence_semantic_issues": [], + "source_intake_issues": [], + "word_count": 106 + }, + { + "behavioral_rule_schema_issues": [], + "broad_semantic_issues": [], + "composition_capability_issues": [], + "concepts": { + "delivery_receipt": true, + "handler_not_telegram": true + }, + "current_schema_overclaims": [], + "custom_signals": {}, + "dimension": "handler_is_not_telegram_delivery", + "invalid_count_invariant_detected": false, + "legacy_pass": false, + "legacy_signals": { + "artifact": true, + "next_action": false, + "no_overclaim": true + }, + "max_response_words": 220, + "overclaim_detected": false, + "pass": true, + "prompt_id": "OOS-13", + "proposal_readiness_issues": [], + "response_issue_detected": false, + "response_too_long": false, + "source_evidence_semantic_issues": [], + "source_intake_issues": [], + "word_count": 82 + }, + { + "behavioral_rule_schema_issues": [], + "broad_semantic_issues": [], + "composition_capability_issues": [], + "concepts": { + "bounded_intake_tier": true, + "real_source_identity": true, + "staged_review_apply": true, + "staging_without_apply_authorization": true + }, + "current_schema_overclaims": [], + "custom_signals": {}, + "dimension": "autonomous_source_intake_boundary", + "invalid_count_invariant_detected": false, + "legacy_pass": true, + "legacy_signals": { + "artifact": true, + "authorization": true, + "no_overclaim": true, + "staging_or_review": true + }, + "max_response_words": 220, + "overclaim_detected": false, + "pass": true, + "prompt_id": "OOS-14", + "proposal_readiness_issues": [], + "response_issue_detected": false, + "response_too_long": false, + "source_evidence_semantic_issues": [], + "source_intake_issues": [], + "word_count": 191 + }, + { + "behavioral_rule_schema_issues": [], + "broad_semantic_issues": [], + "composition_capability_issues": [], + "concepts": { + "apply_capability_boundary": true, + "current_edge_schema": true, + "valid_supersession": true + }, + "current_schema_overclaims": [], + "custom_signals": {}, + "dimension": "schema_valid_supersession", + "invalid_count_invariant_detected": false, + "legacy_pass": false, + "legacy_signals": { + "canonical_db": true, + "no_overclaim": false, + "row_level_proof": true, + "staging_or_review": false + }, + "max_response_words": 220, + "overclaim_detected": false, + "pass": true, + "prompt_id": "OOS-15", + "proposal_readiness_issues": [], + "response_issue_detected": false, + "response_too_long": false, + "source_evidence_semantic_issues": [], + "source_intake_issues": [], + "word_count": 106 + } + ], + "unexpected_prompt_ids": [] + }, + "service_unchanged": true, + "source_results_json": "/private/tmp/teleo-source-reference-repair-20260713/docs/reports/leo-working-state-20260709/telegram-handler-m3taversal-oos-suite-current.json", + "temp_profile_removed": true +} diff --git a/docs/reports/leo-working-state-20260709/telegram-handler-m3taversal-oos-suite-score-current.md b/docs/reports/leo-working-state-20260709/telegram-handler-m3taversal-oos-suite-score-current.md new file mode 100644 index 0000000..203ebd7 --- /dev/null +++ b/docs/reports/leo-working-state-20260709/telegram-handler-m3taversal-oos-suite-score-current.md @@ -0,0 +1,36 @@ +# Working Leo m3taversal Out-of-Sample Score + +Generated UTC: `2026-07-13T20:28:22.009570+00:00` +Pass: `True` +Prompts: `15/15` +DB counts changed: `False` +Service unchanged: `True` +Temporary profile removed: `True` +Database context injections: `16` +Database context all OK: `True` +Database response validations: `16` +Database response validation all OK: `True` +Database-composed replacements: `13` +Posted to Telegram: `False` + +## Prompt Scores + +- `OOS-01` / `demo_pressure_without_ids`: `pass=True` +- `OOS-02` / `multi_surface_knowledge_ingestion`: `pass=True` +- `OOS-03` / `identity_restart_truth`: `pass=True` +- `OOS-04` / `partner_demo_claim_ceiling`: `pass=True` +- `OOS-05` / `source_pointer_needs_canonical_link_audit`: `pass=True` +- `OOS-06` / `database_composition_judgment`: `pass=True` +- `OOS-07` / `same_session_memory_set`: `pass=True` +- `OOS-08` / `same_session_memory_recall`: `pass=True` +- `OOS-09` / `telegram_participant_identity`: `pass=True` +- `OOS-10` / `runtime_vs_canonical_causality`: `pass=True` +- `OOS-11` / `shared_claims_agent_positions`: `pass=True` +- `OOS-12` / `forecast_resolution_without_rewriting_history`: `pass=True` +- `OOS-13` / `handler_is_not_telegram_delivery`: `pass=True` +- `OOS-14` / `autonomous_source_intake_boundary`: `pass=True` +- `OOS-15` / `schema_valid_supersession`: `pass=True` + +## Claim Ceiling + +A pass proves broad out-of-sample and same-session-memory behavior through the live VPS GatewayRunner using a temporary profile, with no Telegram post and no DB count change. It does not prove human-visible Telegram delivery, production DB apply, or GCP parity. diff --git a/docs/reports/leo-working-state-20260709/telegram-handler-v3-proposal-readback-post-restart-current.json b/docs/reports/leo-working-state-20260709/telegram-handler-v3-proposal-readback-post-restart-current.json new file mode 100644 index 0000000..18c9b37 --- /dev/null +++ b/docs/reports/leo-working-state-20260709/telegram-handler-v3-proposal-readback-post-restart-current.json @@ -0,0 +1,176 @@ +{ + "before_service": { + "ActiveState": "active", + "ExecMainStartTimestamp": "Tue 2026-07-14 00:25:49 UTC", + "MainPID": "366950", + "NRestarts": "0", + "SubState": "running" + }, + "changed_live_profile": false, + "database_context_all_ok": true, + "database_context_injection_count": 1, + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "proposal_state_readback" + ], + "contract_sha256": "e7c0b07ae30ff5cd38e62e5de3ebd7efaa05830448fb11c8e588c143fa33f873", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-14T00:27:26.227305+00:00", + "injected": true, + "query_sha256": "4de6976f5e757d40e5f97a4f98c52ffcdc9261e412d23d5ab35efddceb19785d", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "proposal_state_readback", + "reply_budget" + ], + "delivered_response_sha256": "0c501444d51851cdf706ca64c6646d9183841fc322d9b80f54d2dca9c371f9af", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-14T00:27:38.562438+00:00", + "issues": [ + "missing_live_count_readback:proposal_state_readback", + "missing_live_proposal_state:applied", + "missing_live_proposal_state:approved", + "missing_live_proposal_state:canceled", + "missing_live_proposal_state:pending_review", + "missing_matching_proposal_readback", + "missing_proof_changing_followup", + "missing_proposal_apply_boundary" + ], + "query_sha256": "4de6976f5e757d40e5f97a4f98c52ffcdc9261e412d23d5ab35efddceb19785d", + "response_sha256": "a82929d36f5767f370587c068964cb29c0cbeed25e6dadeccf507bf1ed646d03", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "database_response_transform_count": 1, + "database_response_validation_all_ok": true, + "database_response_validation_count": 1, + "db_counts_after": { + "kb_stage.kb_proposals": 29, + "public.claim_edges": 4916, + "public.claim_evidence": 4670, + "public.claims": 1837, + "public.sources": 4145 + }, + "db_counts_before": { + "kb_stage.kb_proposals": 29, + "public.claim_edges": 4916, + "public.claim_evidence": 4670, + "public.claims": 1837, + "public.sources": 4145 + }, + "db_counts_changed": false, + "generated_at_utc": "2026-07-14T00:27:23.161266+00:00", + "handler": { + "authorized": true, + "session_key": "agent:main:telegram:group:-5146042086:9070919", + "temp_profile": "/tmp/leo-direct-claim-handler-wxc88297/profile" + }, + "harness_notes": [ + "One broad no-context post-restart state-semantics probe; no Telegram post and no DB mutation.", + "The harness uses a temporary copy of the leoclean profile and does not post to Telegram.", + "This proves handler-level live VPS GatewayRunner behavior, not human-visible Telegram delivery." + ], + "mode": "live_vps_gatewayrunner_temp_profile_v3_post_restart", + "mutates_kb_by_harness": false, + "pass_runtime": true, + "posted_to_telegram": false, + "remote_report_path": "/tmp/leo-v3-post-restart-88c0cf0dfef1.json", + "remote_returncode": 0, + "remote_run_id": "88c0cf0dfef1", + "results": [ + { + "claim_ceiling": "Live VPS GatewayRunner reply from temp leoclean profile; no Telegram post; no production DB apply authorized.", + "database_context_trace": [ + { + "compiled_response_available": true, + "contract_ids": [ + "reply_budget", + "proposal_state_readback" + ], + "contract_sha256": "e7c0b07ae30ff5cd38e62e5de3ebd7efaa05830448fb11c8e588c143fa33f873", + "event": "pre_llm_call", + "generated_at_utc": "2026-07-14T00:27:26.227305+00:00", + "injected": true, + "query_sha256": "4de6976f5e757d40e5f97a4f98c52ffcdc9261e412d23d5ab35efddceb19785d", + "source": "kb_tool.py --local context", + "status": "ok" + }, + { + "compiled_response_enforced": true, + "compiled_response_issues": [], + "contract_ids": [ + "proposal_state_readback", + "reply_budget" + ], + "delivered_response_sha256": "0c501444d51851cdf706ca64c6646d9183841fc322d9b80f54d2dca9c371f9af", + "event": "post_llm_call", + "fail_closed": false, + "generated_at_utc": "2026-07-14T00:27:38.562438+00:00", + "issues": [ + "missing_live_count_readback:proposal_state_readback", + "missing_live_proposal_state:applied", + "missing_live_proposal_state:approved", + "missing_live_proposal_state:canceled", + "missing_live_proposal_state:pending_review", + "missing_matching_proposal_readback", + "missing_proof_changing_followup", + "missing_proposal_apply_boundary" + ], + "query_sha256": "4de6976f5e757d40e5f97a4f98c52ffcdc9261e412d23d5ab35efddceb19785d", + "response_sha256": "a82929d36f5767f370587c068964cb29c0cbeed25e6dadeccf507bf1ed646d03", + "status": "ok", + "transformed": true, + "validated": true + } + ], + "dimension": "pending_document_is_not_canonical", + "ended_at_utc": "2026-07-14T00:27:38.671539+00:00", + "evidence_tier": "live_vps_gatewayrunner_temp_profile", + "mutates_kb": false, + "ok": true, + "prompt": "Someone says the V3 architecture document is already part of Leo's live knowledge because a proposal exists. What is actually true right now, what would you inspect, and what must happen before those claims are canonical? Do not mutate anything.", + "prompt_id": "V3-POST-RESTART-01", + "reply": "No.\nFresh live readback.\nDB readback: claims: 1837; sources: 4145; claim_edges: 4916; claim_evidence: 4670; kb_proposals: 29.\nDB readback: proposal: 10bc0719-1c2b-5f42-a41e-86e6478692cb; status: pending_review; applied_at: none; source_ref: normalized:12e38cb0-b72b-557c-95e5-ffc789a29f62:72895c9b58b79d41; readiness: needs_human_review.\nProposal states are applied: 2, approved: 3, pending_review: 16, canceled: 8. Approved is not applied. The matching proposal remains pending_review and applied_at is empty, so it has not reached canonical apply. A proposal row is not canonical knowledge without the guarded apply receipt and row-level public.* postflight.\n\nNext proof-changing follow-up: inspect the matching proposal payload and exact source binding, complete human review, obtain explicit guarded-apply authorization, then return non-null applied_at plus the created public.* row IDs and hashes.", + "started_at_utc": "2026-07-14T00:27:23.632357+00:00", + "turn": 1 + } + ], + "service_before_after": { + "after": { + "ActiveState": "active", + "ExecMainStartTimestamp": "Tue 2026-07-14 00:25:49 UTC", + "MainPID": "366950", + "NRestarts": "0", + "SubState": "running" + }, + "before": { + "ActiveState": "active", + "ExecMainStartTimestamp": "Tue 2026-07-14 00:25:49 UTC", + "MainPID": "366950", + "NRestarts": "0", + "SubState": "running" + }, + "unchanged_from_preexisting_live_readback": true + }, + "source": { + "chat_id": "-5146042086", + "chat_name": "Leo", + "chat_type": "group", + "platform": "telegram", + "user_id": "9070919", + "user_name": "codex handler direct claim" + }, + "source_report_path": "/tmp/leo-v3-post-restart-handler.json", + "temp_profile_removed": true +} diff --git a/docs/reports/leo-working-state-20260709/working-leo-three-day-delivery-summary-20260713.md b/docs/reports/leo-working-state-20260709/working-leo-three-day-delivery-summary-20260713.md index 2cfba4c..51f36f1 100644 --- a/docs/reports/leo-working-state-20260709/working-leo-three-day-delivery-summary-20260713.md +++ b/docs/reports/leo-working-state-20260709/working-leo-three-day-delivery-summary-20260713.md @@ -1,5 +1,8 @@ # Working Leo: Three-Day Delivery Delta +> Historical July 13 checkpoint. The current outcome and forward path is +> `working-leo-three-day-outcome-and-forward-path-20260714.md`. + Window: `2026-07-10 00:00` through `2026-07-13` current delivery wave. ## Executive Verdict diff --git a/docs/reports/leo-working-state-20260709/working-leo-three-day-outcome-and-forward-path-20260714.md b/docs/reports/leo-working-state-20260709/working-leo-three-day-outcome-and-forward-path-20260714.md new file mode 100644 index 0000000..7c42043 --- /dev/null +++ b/docs/reports/leo-working-state-20260709/working-leo-three-day-outcome-and-forward-path-20260714.md @@ -0,0 +1,377 @@ +# Working Leo: Three-Day Outcome And Forward Path + +Current as of `2026-07-14 00:28 UTC`. + +This is the current high-level handoff for what the July 10-14 delivery wave +achieved, what is working on the VPS, what still has to move to GCP, and how the +database can be recovered or rebuilt without repeatedly teaching Leo through +chat prompts. + +## Executive Verdict + +**Whole-system answer: not fully complete yet.** + +**VPS answer: materially working at the database-grounded handler tier.** Leo +can answer broad questions without supplied claim IDs, read current canonical +and proposal state, distinguish staged/reviewed/applied knowledge, remember a +same-session fact, identify `m3taversal` correctly, explain uncertainty, prepare +one source document into exact grounded candidates, stage a review proposal, +and survive a gateway restart. The current broad no-post suite passes `15/15`. + +**GCP answer: prior parity is proven, current parity is not.** A July 12 GCP +copy matched the VPS across `39` tables and `52,164` rows and passed an +adapter-free no-send model replay. A newer July 13 VPS dump with `52,165` rows +and `27` proposals restored and verified locally, but it has not yet been +restored to GCP. The live VPS now has `29` proposals after the V3 document +canary, so the latest VPS state is ahead of the last GCP proof. + +**Database rebuild answer: exact recovery works; semantic recompilation is +partial.** A verified snapshot can recreate the current Postgres database in +seconds. Rebuilding a blank database from every retained document, extraction, +review decision, and apply receipt is not yet complete because historical rows +predate a complete replay ledger. + +## What Working Leo Means + +The target is not merely that Leo replies fluently. A working Leo must: + +1. Query the current Postgres knowledge base before making a database claim. +2. Find relevant claims, sources, evidence, edges, and proposals without being + handed row IDs. +3. Separate chat memory, runtime files, staged proposals, reviewer approval, + and canonical applied rows. +4. Turn a new source into grounded candidate knowledge with exact provenance, + deduplication, contradiction handling, and review boundaries. +5. Apply only an explicitly reviewed and authorized payload, then return exact + row IDs, hashes, `applied_at`, and postflight state. +6. Preserve the relevant behavior and knowledge across a fresh process or + restart. +7. Produce the same truth-grounded behavior on GCP against a verified copy. + +The work moved Leo from prompt-shaped answers toward this database-driven +lifecycle. + +## Three-Day Movement + +### 1. Turn vague failure reports into executable tests + +The initial report was simply that Leo was not working and could not manipulate +the knowledge base. We reconstructed expected behavior from the Telegram +history, converted it into direct-claim and open-ended questions, and retained +separate proof tiers for: + +- runtime reply; +- database truth; +- Telegram-visible delivery; +- proposal staging; +- canonical apply; +- restart persistence; +- GCP parity. + +This stopped a passing unit test, a hidden handler reply, and a visible Telegram +reply from being treated as the same result. + +### 2. Make current database truth automatic + +The VPS Hermes runtime now injects fresh database contracts for questions that +depend on current state. A response validator checks the answer against the +same receipt and replaces an unsupported model draft with a deterministic safe +answer when necessary. + +This covers proposal lifecycle, named proposal packets, source/evidence links, +decision-matrix claims, identity canonicality, source intake, schema limits, +and the distinction between handler execution and Telegram delivery. + +### 3. Make source preparation real + +The shipped VPS path is now: + +```text +private source artifact +-> canonical duplicate retrieval +-> bounded extraction of atomic candidates +-> exact source-fragment binding +-> provenance and uncertainty manifest +-> deterministic strict proposal payload +-> pending_review proposal +``` + +The V3 identity architecture document was the real canary. It exposed and led +to repairs for three failures: + +1. model-copied quotes were not byte exact; +2. physical line IDs could refer to blank lines; +3. exact source wording was incorrectly planned as canonical claim text. + +After those repairs, the document produced three atomic candidate claims, exact +source bindings, canonical duplicate readback, and corrected proposal +`10bc0719-1c2b-5f42-a41e-86e6478692cb`. + +Current state of that proposal: + +- status: `pending_review`; +- `applied_at`: database `NULL`; +- source identity: + `document:sha256:59d596e70d26fbc491b4de3228251c308eb9c83cb86ea2dccc9b3342801c5be7`; +- no V3 candidate was written to canonical `public.*` tables; +- the flawed predecessor `a9eb4158-5aa2-5484-b5a7-3d249588b3ec` is canceled. + +### 4. Harden broad reasoning instead of only narrow prompts + +An early blind 12-question run exposed schema invention, wrong edge semantics, +memory used as provenance, excessive answer length, and participant-name bleed. +Those failures were repaired as runtime contracts and regression tests. + +The current broad out-of-sample VPS GatewayRunner suite passes `15/15`, covering: + +- partner-demo pressure without supplied IDs; +- multi-surface source ingestion; +- identity and restart truth; +- source/evidence linkage; +- heterogeneous database composition; +- same-session memory set and recall; +- exact `m3taversal` participant naming; +- runtime versus canonical causality; +- shared claims versus agent-specific positions; +- forecast resolution without rewriting history; +- handler versus Telegram delivery; +- autonomous source-intake limits; +- schema-valid claim supersession. + +The suite changed no DB counts, posted nothing to Telegram, left the service +unchanged, and removed its temporary profile. + +### 5. Prove restart and named-proposal readback + +The deployed VPS is at merge `aa1246c603020bef07a575e4aebf4f2d2ed5db0c`. +After the managed restart, `leoclean-gateway.service` was active with PID +`366950`, `NRestarts=0`, and start timestamp `2026-07-14 00:25:49 UTC`. + +The exact post-restart question claimed that the V3 document was already live +because a proposal existed. The live handler correctly answered `No` and +returned: + +- claims: `1837`; +- sources: `4145`; +- claim edges: `4916`; +- claim evidence: `4670`; +- proposals: `29`; +- matching proposal: `10bc0719-1c2b-5f42-a41e-86e6478692cb`; +- status: `pending_review`; +- `applied_at`: `none`; +- required next state: review, explicit guarded-apply authorization, then + public row IDs and hashes. + +The response validator passed, DB counts remained unchanged, no Telegram +message was posted, the live profile was unchanged, the service stayed on the +same PID, and the temporary profile was removed. + +### 6. Deliver the work rather than leave it local + +There are `49` merge commits in the delivery window beginning July 10. The most +recent source-to-answer chain is: + +| PR | Outcome | +| --- | --- | +| `#127` | VPS document preparation and pending-review staging | +| `#128` | byte-exact source reference restoration | +| `#129` | dense nonempty source fragment IDs | +| `#130` | atomic canonical claim text separated from exact quote text | +| `#131` | retained V3 document lifecycle proof | +| `#132` | named/versioned document proposal matching and readback | +| `#133` | live response-validator compatibility for that readback | + +All seven are merged. The VPS managed deploy stamp matches `#133`. + +## VPS: What Works Now + +An operator can now rely on the VPS for these bounded outcomes: + +- ask a broad database question and receive current counts and state boundaries; +- inspect whether a named proposal is pending, approved, applied, or canceled; +- distinguish a proposal from live canonical knowledge; +- search canonical claims, evidence, sources, and graph edges; +- retain a same-session fact without treating it as database provenance; +- address `m3taversal` only by the visible handle; +- prepare one text-like source artifact and stage a grounded proposal; +- run repeatable no-post handler tests without changing the live profile or DB; +- restart the gateway and preserve current database-backed behavior. + +## VPS: What Is Not Yet Proven + +- The current broad suite has not yet been repeated as visible messages in the + real Telegram group. Any Telegram work must use the authenticated Google + Chrome instance only. +- The V3 proposal has not been reviewed or canonically applied. +- A complete production source-to-apply lifecycle has not been authorized and + run on the live database. +- Arbitrary Telegram attachments and tweets are not automatically downloaded, + extracted, and staged by the shipped path. +- A general scheduled DB-to-`SOUL.md` identity renderer is not proven. + +## GCP: What Prior Work Proved + +The earlier GCP vertical slice proved that: + +- a VPS canonical snapshot could be restored to private Cloud SQL; +- all `39` tables and `52,164` rows matched at that proof point; +- schema, constraints, indexes, functions, types, triggers, views, policies, + extensions, roles, row hashes, and bounded performance checks matched; +- the real GCP GatewayRunner could answer the six direct database questions + without an adapter and without sending or mutating state; +- false printed counts are rejected unless they equal the database receipt. + +That remains valid historical proof. It does not prove that GCP currently has +the July 13-14 source compiler, V3 proposal, named-proposal readback, or the same +`29`-proposal database state. + +## GCP: Current Forward Path + +A fresh July 13 source dump is retained at: + +```text +/private/tmp/working-leo-gcp-refresh-20260713/teleo-canonical.dump +``` + +Its SHA-256 is: + +```text +3fc686ccc423651e86d1f0ad052fa89877215b634a07267a7e26a28e1c2bebe8 +``` + +It contains `39` tables and `52,165` rows with `27` proposals. A disposable +local restore passed with zero parity mismatches and complete cleanup. Because +the V3 lifecycle later moved the VPS to `29` proposals, this dump is useful but +is not the newest possible source state. + +The next GCP sequence is: + +1. complete Google Cloud CLI reauthentication through the existing Google + Chrome sign-in tab; +2. bootstrap the least-privilege IAP/operator identities from the merged repo; +3. capture a new post-V3 VPS snapshot; +4. restore it into a disposable GCP staging database; +5. verify schema, constraints, row counts, hashes, roles, private connectivity, + and bounded performance; +6. deploy the current Leo compute/runtime against that copy; +7. replay the same 15-question broad suite plus the exact V3 proposal question; +8. prove no send, no canonical write, cleanup, and no orphan resources. + +Until this sequence runs, current GCP parity must be reported as pending rather +than inferred from the earlier green proof. + +## Rebuilding The Database On Demand + +There are two different meanings of rebuild. + +### Exact snapshot recovery: working + +This is the reliable disaster-recovery path today: + +```bash +.venv/bin/python ops/run_local_canonical_postgres_rebuild.py \ + --dump /private/path/teleo-canonical.dump \ + --source-manifest /private/path/source-manifest.jsonl \ + --output /tmp/teleo-canonical-rebuild-receipt.json +``` + +The July 13 canary restored a network-isolated Postgres instance, verified all +`39` tables and `52,165` rows, checked structural and row hashes, roles and +performance, and removed the container. Total runtime was `12.35` seconds, +including `2.97` seconds for `pg_restore`. + +This recreates the database exactly. It does not re-extract knowledge from the +source corpus. + +### Semantic source recompilation: partial + +The desired long-term path is: + +```text +immutable documents/posts/tweets plus hashes +-> deterministic extraction and source binding +-> duplicate and contradiction checks +-> reviewed typed proposals +-> append-only accepted apply payloads and receipts +-> canonical Postgres +-> identity/render sync +-> restart and answer benchmark +``` + +The new `prepare-source` and `propose-source` commands prove this path for one +bounded document through `pending_review`. Disposable clone canaries separately +prove review, guarded apply, and later rediscovery. They are not yet one complete +blank-database corpus runner. + +Historical reconstruction still lacks explicit replay provenance for: + +- `30` canonical claims created outside the mapped import; +- `284` mapped sources without a retained staged source row; +- `416` evidence links requiring source-synthesis or later-change provenance; +- `38` edges requiring later-change receipts or explicit replay rules; +- historical duplicate multiplicity and old applied proposals that do not + identify every row they changed. + +The practical policy is therefore: + +1. keep the verified snapshot as genesis recovery; +2. require every new accepted change to retain a strict replayable payload and + row-level postflight receipt; +3. continue reconstructing historical import rules without allowing the gap to + grow; +4. combine genesis plus the accepted ledger into one blank-database compiler; +5. compare the result against the canonical manifest and answer benchmark. + +This is how Leo improves by composing its database rather than by repeatedly +training its chat style. + +## Current Outcome Matrix + +| Outcome | Current tier | Verdict | +| --- | --- | --- | +| Broad VPS database reasoning | live no-post GatewayRunner, `15/15` | Working | +| Same-session memory | live no-post GatewayRunner | Working | +| Exact `m3taversal` naming | live no-post GatewayRunner | Working | +| Restart survival | managed restart plus exact V3 post-restart readback | Working | +| Source document preparation | live VPS private files, exact manifest | Working | +| Proposal staging | live VPS `pending_review` | Working | +| V3 canonical apply | production DB | Not run or authorized | +| Telegram-visible broad suite | real group through Google Chrome | Not yet run | +| Prior GCP copy and six-question replay | private Cloud SQL and GCP runtime | Proven historically | +| Current GCP parity with VPS `29` proposals | fresh staging replay | Not yet run | +| Exact snapshot rebuild | disposable local Postgres | Working | +| Full source-to-blank-DB recompilation | complete corpus plus ledger | Partial | + +## Immediate Execution Order + +1. Commit this context, the `15/15` broad report, and the exact V3 post-restart + handler receipt. +2. Use only authenticated Google Chrome for visible Telegram tests and capture + the actual replies. +3. Complete Google Cloud CLI reauthentication, bootstrap IAP operator access, + and capture a new post-V3 snapshot. +4. Restore and replay the current suite on GCP staging, then clean it up. +5. Run one explicitly reviewed source proposal through guarded apply in a + disposable clone first; seek production apply authorization only with the + exact payload and receipt plan visible. +6. Build the combined genesis-plus-ledger semantic recompiler. + +## Evidence Index + +- `telegram-handler-m3taversal-oos-suite-current.json` +- `telegram-handler-m3taversal-oos-suite-score-current.json` +- `telegram-handler-m3taversal-oos-suite-score-current.md` +- `telegram-handler-v3-proposal-readback-post-restart-current.json` +- `leo-v3-document-source-lifecycle-current.json` +- `leo-v3-document-source-lifecycle-current.md` +- `gcp-refresh-local-rebuild-current.json` +- `../../kb-rebuild-and-recompile.md` + +## Final Claim Ceiling + +The last three days delivered a stable, testable, database-grounded Leo on the +VPS at the handler tier and a real source-to-review proposal path. They did not +finish current GCP parity, Telegram-visible broad proof, a production canonical +apply, or complete source-derived reconstruction of the entire historical +database. Those are the remaining outcome rows, not reasons to repeat the work +that is already merged and live.