teleo/teleo-infrastructure
8
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions 1

Merge pull request #134 from living-ip/codex/leo-three-day-outcome-20260714
Some checks are pending
CI / lint-and-test (push) Waiting to run
Details

Browse source 
Document Working Leo three-day outcomes
This commit is contained in:
twentyOne2x 2026-07-14 02:38:47 +02:00 committed by GitHub
commit 64142ee3fc
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
8 changed files with 2601 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
docs/kb-rebuild-and-recompile.md
View file

@ -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.

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

@ -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

1396
docs/reports/leo-working-state-20260709/telegram-handler-m3taversal-oos-suite-current.json Normal file
View file

File diff suppressed because it is too large Load diff

568
docs/reports/leo-working-state-20260709/telegram-handler-m3taversal-oos-suite-score-current.json Normal file
View file

@ -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
}

36
docs/reports/leo-working-state-20260709/telegram-handler-m3taversal-oos-suite-score-current.md Normal file
View file

@ -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.

176
docs/reports/leo-working-state-20260709/telegram-handler-v3-proposal-readback-post-restart-current.json Normal file
View file

@ -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
}

3
docs/reports/leo-working-state-20260709/working-leo-three-day-delivery-summary-20260713.md
View file

@ -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

377
docs/reports/leo-working-state-20260709/working-leo-three-day-outcome-and-forward-path-20260714.md Normal file
View file

@ -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.