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
Some checks are pending
CI / lint-and-test (push) Waiting to run
Document Working Leo three-day outcomes
This commit is contained in:
twentyOne2x
GitHub
commit
64142ee3fc
8 changed files with 2601 additions and 5 deletions
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
|
|
@ -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
|
||||
}
|
||||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
}
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
Loading…
Reference in a new issue