From 9e077e2536e3bc27c6122c1fe6a7ab2b6163d3a2 Mon Sep 17 00:00:00 2001 From: twentyOne2x Date: Mon, 13 Jul 2026 08:56:01 +0200 Subject: [PATCH] Document three-day Working Leo delivery delta --- .../current-truth-index.md | 40 +++- .../gcp-operator-access-blocker-current.json | 36 +-- ...egram-handler-blind-oos-audit-current.json | 68 ++++++ .../working-leo-current-proof-20260712.md | 45 ++-- ...leo-three-day-delivery-summary-20260713.md | 212 ++++++++++++++++++ 5 files changed, 367 insertions(+), 34 deletions(-) create mode 100644 docs/reports/leo-working-state-20260709/telegram-handler-blind-oos-audit-current.json create mode 100644 docs/reports/leo-working-state-20260709/working-leo-three-day-delivery-summary-20260713.md diff --git a/docs/reports/leo-working-state-20260709/current-truth-index.md b/docs/reports/leo-working-state-20260709/current-truth-index.md index 5f0ee18..734ec4f 100644 --- a/docs/reports/leo-working-state-20260709/current-truth-index.md +++ b/docs/reports/leo-working-state-20260709/current-truth-index.md @@ -2,9 +2,47 @@ 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-13 + +The whole-system m3taversal-standard verdict remains **not fully yet**. This +section supersedes the July 12 status paragraph below. + +- VPS deploy before the current identity/schema repair: SHA + `48777fd984dcfc195e6c33a8d3f7d78bd0c2e344`, gateway PID `1105322`, + `NRestarts=0`, start `2026-07-13 04:26:31 UTC`. +- VPS canonical counts remain claims `1837`, sources `4145`, edges `4916`, + evidence `4670`, proposals `26`. +- Narrow direct-claim behavior and restart survival are proven at the no-post + handler tier. Earlier Telegram-visible direct answers are retained, but the + latest group transcript exposed a participant naming failure. +- Broad blind behavior is **not reliable**: a clean 12-reply no-post run left DB + and service state unchanged and removed its temporary profile, but independent + strict judges accepted only `1/12` and `2/12` outright. See + `telegram-handler-blind-oos-audit-current.json`. +- The current repair adds exact `m3taversal` naming, neutral follow-up labels, + current-v1 schema/edge guards, a participant-identity benchmark case, and + regression tests. Post-deploy Telegram-visible and blind reruns are required. +- GCP exact canonical parity is proven across `39` tables and `52,164` rows. + The adapter-free real model replay is also accepted at `6/6` with exact count + consistency and unchanged fingerprint/service/profile. +- GCP durable operation and cleanup remain open. GitHub runs `29227390073` and + `29227520353` prove the intended target service accounts are absent (`404 Gaia + id not found`); privileged password/MFA reauthentication is needed to recreate + least-privilege operator identities. The retained replay clone and run + directory must then be removed. + +Newest decision artifacts: + +- `docs/reports/leo-working-state-20260709/working-leo-three-day-delivery-summary-20260713.md` +- `docs/reports/leo-working-state-20260709/telegram-handler-blind-oos-audit-current.json` +- `docs/reports/leo-working-state-20260709/gcp-operator-access-blocker-current.json` + +Some retained filenames and immutable test markers below contain legacy labels. +They are evidence identifiers, not valid forms of address. + ## Live Addendum - 2026-07-12 -The whole-system Cory-standard verdict is **not fully yet**. Do not let older +The whole-system m3taversal-standard verdict is **not fully yet**. Do not let older sections below override this newer status. - VPS runtime: active and restart-survival proven. Latest gateway readback is diff --git a/docs/reports/leo-working-state-20260709/gcp-operator-access-blocker-current.json b/docs/reports/leo-working-state-20260709/gcp-operator-access-blocker-current.json index ec900b9..26f10cc 100644 --- a/docs/reports/leo-working-state-20260709/gcp-operator-access-blocker-current.json +++ b/docs/reports/leo-working-state-20260709/gcp-operator-access-blocker-current.json @@ -1,11 +1,11 @@ { - "schema": "teleo.gcpCoryReplayAccessBlocker.v1", - "generated_at_utc": "2026-07-13T01:26:30Z", - "status": "waiting_on_google_password_reauthentication_prepared_handoff", + "schema": "teleo.gcpReplayAccessBlocker.v2", + "generated_at_utc": "2026-07-13T06:20:00Z", + "status": "waiting_on_privileged_google_reauthentication_after_service_account_absence_proven", "current_canary": { - "operator_path": "Run DC-01 through DC-06 through the real adapter-free GCP GatewayRunner against teleo_clone_cory_20260712t1940z, require strict 6/6 plus exact count consistency, then delete the clone and run-owned files.", - "expected_result": "Six truthful replies, every printed canonical count equal to 1837/4145/4916/4670/26, unchanged clone fingerprint, unchanged GCP service/profile, no Telegram send, no DB write, and zero generated clone/run resources remaining.", - "required_tier": "GCP generated-clone live model proof" + "operator_path": "Recreate the missing least-privilege GCP operator identity, prove one passwordless status lifecycle, then delete the retained replay clone and run-owned files.", + "expected_result": "A durable no-password operator can run the bounded GCP status route; the Leo service and canonical database remain unchanged; the retained generated clone and run directory are absent.", + "required_tier": "GCP durable operator access and cleanup" }, "permission_profile": { "approval_policy": "never", @@ -21,10 +21,14 @@ "gcp_vm_external_ip": "34.65.143.148", "direct_ssh": "TCP/22 timeout before authentication", "chrome_personal_account": "billyattnmarket@gmail.com is authenticated but lacks resourcemanager.projects.get on teleo-501523", - "chrome_privileged_account": "selected Chrome tab titled Welcome is at the Google password challenge for billy@livingip.xyz; secure password field is focused and accepts typing or paste", + "chrome_privileged_account": "the prior OAuth handoff expired before the privileged password/MFA step completed; restart the command to issue a fresh URL", "github_iap_workflow_run": "29208215340", "github_iap_auth": "invalid_target: teleo-iap-operator Workload Identity provider absent, disabled, or deleted", - "existing_living_ip_github_provider": "authenticates sa-artifact-builder, but that account lacks Compute, IAM, Secret Manager, and Cloud SQL permissions" + "existing_living_ip_github_provider": "authenticates sa-artifact-builder, but that account lacks Compute, IAM, Secret Manager, and Cloud SQL permissions", + "readiness_run_29227390073": "GitHub OIDC setup passed, then service-account impersonation failed with HTTP 404 Gaia id not found for sa-teleo-iap-status; the service account is absent or deleted", + "readiness_run_29227520353": "GitHub OIDC setup passed, then service-account impersonation failed with HTTP 404 Gaia id not found for sa-teleo-readiness; the service account is absent or deleted", + "gcp_model_replay": "adapter-free GatewayRunner replay passed 6/6 with exact count consistency, unchanged fingerprint/service/profile, no send/write, and temporary profile cleanup", + "gcp_database_copy": "39 tables and 52,164 rows match the VPS canonical database with zero schema, row-content, role, extension, constraint, index, trigger, view, policy, function, type, and performance mismatches over private TLS" }, "attempted_no_approval_routes": [ "direct SSH through the retained teleo-gcp-staging alias", @@ -33,15 +37,17 @@ "merged GitHub OIDC/IAP fixed-operation workflow on main", "existing living-ip-github WIF provider with sa-artifact-builder", "authenticated Chrome console discovery without reading credentials; the personal account lacks Teleo project access", - "dedicated GCP tab sign-out recovery, privileged account email entry, and preparation of a focused pasteable password field using Computer Use", + "dedicated GCP OAuth handoff through authenticated Chrome; the URL expired before password/MFA completion", "Chrome extension route became unstable, so the prepared handoff was verified with Computer Use without AppleScript or foreground-command fallbacks", "Mullvad status/config readback; configured relay does not restore the allowed office ISP address", - "Tailscale peer/exit-node inventory; no peer offers the allowed office ISP route" + "Tailscale peer/exit-node inventory; no peer offers the allowed office ISP route", + "GitHub readiness run 29227390073 through the working shared provider; target sa-teleo-iap-status failed with 404 Gaia id not found", + "GitHub readiness run 29227520353 through the working shared provider; target sa-teleo-readiness failed with 404 Gaia id not found" ], - "exact_gate": "Google requires the current password, and any subsequent MFA or consent, for billy@livingip.xyz before Codex can rotate teleo-prod-allow-ssh-current-ip or bootstrap the missing IAP Workload Identity provider and dedicated operator service accounts.", + "exact_gate": "Both intended target service accounts are absent, and no current noninteractive principal can recreate them or grant the required least-privilege bindings. Google requires the current password and any subsequent MFA or consent for billy@livingip.xyz before that bootstrap can run.", "why_autonomous_repair_stops": "Raw passwords and MFA are human-only. The device-local Keychain item is deliberately non-retrievable and cannot satisfy OAuth. No current noninteractive principal has the required Compute/IAM permissions, and no existing network route originates from the allowed 176.108.138.1/32 address.", - "clear_CTA": "In the selected Chrome tab titled Welcome, paste or type the current password into the already-focused Enter your password field, click Next, complete any MFA or consent, then tell Codex exactly: GCP reauthenticated. Do not send the password to Codex.", - "next_non_user_action": "Rotate only teleo-prod-allow-ssh-current-ip to 99.35.221.133/32, verify passwordless SSH and service/DB invariants, bootstrap and live-test the dedicated GitHub OIDC/IAP operator, run the hardened six-response replay, retain the result, drop teleo_clone_cory_20260712t1940z, remove all run files, and verify the disabled rollback database remains zero-connection.", + "clear_CTA": "Run gcloud auth login billy@livingip.xyz --force --no-launch-browser, open the fresh URL in the dedicated Chrome GCP session, enter the password there, complete MFA/consent, paste only the resulting authorization code into the waiting terminal, then tell Codex exactly: GCP reauthenticated. Do not send the password or MFA code to Codex.", + "next_non_user_action": "Recreate the dedicated least-privilege readiness/operator service accounts and bindings, prove a passwordless bounded status run, rotate only the SSH /32 if still needed, verify service/DB invariants, drop the retained replay clone, remove the run directory, and verify the disabled rollback database remains zero-connection.", "cleanup_pending": { "generated_database": "teleo_clone_cory_20260712t1940z", "remote_run_directory": "/home/teleo/gcp-cory-model-replay-20260712t1940z", @@ -52,6 +58,8 @@ "/Users/user/Documents/Codex/2026-07-09/019f34eb-d297-72d0-b7e2-b222d5515ab9-load/outputs/gcp-staging-canonical-parity-20260712T1905Z/final-receipt.json", "/Users/user/Documents/Codex/2026-07-09/019f34eb-d297-72d0-b7e2-b222d5515ab9-load/outputs/gcp-cory-model-replay-20260712T1940Z/direct-claim-result-final.json", "/Users/user/Documents/Codex/2026-07-09/019f34eb-d297-72d0-b7e2-b222d5515ab9-load/outputs/gcp-iap-operator-failed-20260712T204135Z/gcp-iap-operator-29208215340/result.json", - "/Users/user/Documents/Codex/2026-07-09/019f34eb-d297-72d0-b7e2-b222d5515ab9-load/outputs/gcp-cory-replay-access-blocker-current.json" + "/Users/user/Documents/Codex/2026-07-09/019f34eb-d297-72d0-b7e2-b222d5515ab9-load/outputs/gcp-cory-replay-access-blocker-current.json", + "https://github.com/living-ip/teleo-infrastructure/actions/runs/29227390073", + "https://github.com/living-ip/teleo-infrastructure/actions/runs/29227520353" ] } diff --git a/docs/reports/leo-working-state-20260709/telegram-handler-blind-oos-audit-current.json b/docs/reports/leo-working-state-20260709/telegram-handler-blind-oos-audit-current.json new file mode 100644 index 0000000..87c5931 --- /dev/null +++ b/docs/reports/leo-working-state-20260709/telegram-handler-blind-oos-audit-current.json @@ -0,0 +1,68 @@ +{ + "schema": "teleo.workingLeoBlindOosAudit.v1", + "generated_at_utc": "2026-07-13T06:30:00Z", + "verdict": "not_reliable_for_unattended_m3taversal_use", + "runtime_result": { + "prompts_returned": "12/12", + "db_counts_changed": false, + "service_unchanged": true, + "temporary_profile_removed": true, + "posted_to_telegram": false, + "production_db_apply_ran": false + }, + "transcript": { + "local_path_legacy_name": "/tmp/leo-blind-cory-oos-f81d475883.json", + "sha256": "ad407186936a75893672cadb65f867e8807035bba1fb48e204ef6ec5d6594430", + "reply_words_total": 8662, + "reply_words_average": 721.8333333333334, + "reply_words_min": 26, + "reply_words_max": 1427 + }, + "independent_judges": [ + { + "method": "precommitted_strict_binary_rubric", + "pass": 1, + "partial": 0, + "fail": 11 + }, + { + "method": "independent_schema_and_outcome_audit", + "pass": 2, + "partial": 4, + "fail": 6 + } + ], + "failure_classes": [ + "Presented proposed schema fields as if they exist in current public.claims, public.sources, public.claim_evidence, or public.claim_edges.", + "Invented or misnamed current claim-edge types, including confusing the superseded_by claim column with the supersedes edge type.", + "Described an adapter-free no-post handler run as Telegram-visible proof.", + "Treated unchanged canonical row counts as a complete explanation for unchanged behavior while ignoring runtime sessions, memory, skills, configuration, and rendered identity.", + "Treated a temporary conversation-memory label as source provenance.", + "Required operator pre-approval before Leo could stage a reviewable proposal, reducing useful autonomous composition.", + "Mixed proposed forecast-resolution architecture with current v1 capability.", + "Produced answers too long for repeated Telegram operator use." + ], + "only_strict_binary_pass": "BLIND-04 packet-specific apply receipt", + "targeted_correction": { + "local_path": "/tmp/leo-schema-truth-correction-7d4c7f4996.json", + "sha256": "4f03f5aa78375c513445acd5cca640deaa2a97a09bfd044f7994d92ee47e8ff5", + "runtime_replies": "4/4", + "db_counts_changed": false, + "service_unchanged": true, + "temporary_profile_removed": true, + "what_it_proved": [ + "Leo retracts proposed-v3-as-current schema assertions when current schema truth is supplied.", + "Leo restores the autonomous-staging versus authorized-apply boundary when explicitly challenged.", + "Leo rejects an ephemeral memory token as source provenance when explicitly challenged.", + "Leo can summarize current capability more concisely after explicit correction." + ], + "claim_ceiling": "Targeted correction responsiveness is proven; broad blind reliability is not." + }, + "repair_contract": [ + "Deploy exact Telegram participant naming rules and neutral response labels.", + "Pin current v1 table columns and accepted edge types in both VPS and GCP bridge skills.", + "Fail the out-of-sample scorer when proposed architecture is stated as current without an explicit schema-gap qualifier.", + "Add a participant-identity case that requires exact m3taversal naming and rejects inferred aliases.", + "Rerun blind handler and Telegram-visible checks after deploy; do not upgrade the verdict from targeted correction alone." + ] +} diff --git a/docs/reports/leo-working-state-20260709/working-leo-current-proof-20260712.md b/docs/reports/leo-working-state-20260709/working-leo-current-proof-20260712.md index c0cb8d2..6355a9c 100644 --- a/docs/reports/leo-working-state-20260709/working-leo-current-proof-20260712.md +++ b/docs/reports/leo-working-state-20260709/working-leo-current-proof-20260712.md @@ -1,24 +1,31 @@ # Working Leo Current Proof - 2026-07-12 -## Verdict +## July 13 Superseding Verdict -Leo is **not fully at Cory's expected standard yet**. +Leo is **not fully at m3taversal's expected standard yet**. -The VPS runtime, restart survival, canonical query path, proposal-state truth, -no-send direct answers, source-composition clone, and guarded apply lifecycle are -proven. Exact VPS-to-GCP canonical DB parity is also proven. +VPS runtime, restart survival, canonical query/state truth, bounded no-post +direct answers, source-composition clone, and guarded apply lifecycle remain +proven. Exact VPS-to-GCP canonical parity and the hardened adapter-free GCP model +replay are now proven. -The two incomplete end-user rows are: +The current incomplete end-user rows are: -1. Cory-style direct-claim convergence: all six prompts are Telegram-visible, - but the hardened semantic scorer gives that retained pre-repair suite `5/6`. - The repaired VPS clean-session path passes three consecutive `6/6` trials; - a visible `DC-05` retest is the remaining Telegram gap. -2. Hardened GCP model replay plus cleanup: a nominal `6/6` run was rejected for - false printed counts; the fixed rerun waits on Google password reauthentication - because both current operator routes are unavailable. +1. Broad reasoning: a 12-question blind no-post suite was operationally clean, + but independent strict judges accepted only `1/12` and `2/12` outright. +2. Telegram participant identity: the latest visible conversation inferred an + unverified personal name and reused a shortened handle. The current repair + requires the exact visible handle `m3taversal` and a neutral follow-up label; + post-deploy visible proof remains required. +3. GCP durable operation/cleanup: the exact DB copy and hardened replay are + green, but the intended operator service accounts are absent. They must be + recreated after privileged Google reauthentication, then the retained replay + clone/run directory must be removed. -## What Cory Means By Working +See `working-leo-three-day-delivery-summary-20260713.md` and +`telegram-handler-blind-oos-audit-current.json` for the current decision. + +## What m3taversal Means By Working A working Leo must do more than answer chat messages: @@ -27,14 +34,14 @@ A working Leo must do more than answer chat messages: | Conversation memory | Remember the current operator conversation and caveats | VPS Telegram/open-ended and restart-bound memory proven | | KB query | Discover relevant claims, evidence, sources, edges, and proposals without supplied IDs | VPS and GCP DB-read routes proven | | State truth | Separate proposed, pending review, approved, applied, and canonical | VPS no-send `3/3` trials at `6/6`; retained pre-repair Telegram-visible suite `5/6`; visible `DC-05` retest open | -| Critical reasoning | Challenge weak assumptions, expose conflicts/uncertainty, and propose one useful next action | Broad suite proven; `DC-05` apply-path follow-up requires correction | +| Critical reasoning | Challenge weak assumptions, expose conflicts/uncertainty, and propose one useful next action | Narrow cases proven; fresh blind suite failed the broad bar | | Staging | Turn a grounded operator request into a concrete reviewable proposal | Live Telegram staging proven | | Composition | Ingest source bytes/excerpts, extract atomic claims, bind evidence/source rows, detect conflicts, and stage a lossless proposal | Deterministic fixture and full-data clone proven; arbitrary production source breadth not proven | | Canonical apply | Move an approved strict payload into exact `public.*` rows through separated review/apply authority | Isolated lifecycle proven; broad production packets not applied | | Graph reasoning | Reopen after restart and reason over newly applied claims/evidence/source IDs/edges | Full-data source-composition clone proven | | Identity | Treat DB rows as canonical and `SOUL.md` as rendered runtime state | Answer behavior proven; active scheduled renderer still not proven | | Stability | Survive intentional gateway restart with unchanged DB and a successful handler smoke | VPS proven | -| GCP parity | Restore exact canonical DB, use private TLS, replay Leo, and clean up | DB parity proven; hardened model rerun and clone cleanup pending | +| GCP parity | Restore exact canonical DB, use private TLS, replay Leo, and clean up | DB parity and hardened replay proven; durable operator and clone cleanup pending | | Operator proof | Produce exact rows, counts, hashes, timestamps, service state, rollback, and cleanup receipts | Proven for current isolated and parity lanes | ## Architecture Truth @@ -114,7 +121,7 @@ The Leo bridge skills were changed to require: 6. document/file/proposal-source/canonical-source separation; 7. staging-demo versus canonical-apply-demo separation; 8. DB-row plus renderer proof before calling a `SOUL.md` change canonical; -9. exactly one `Next Cory-style follow-up:` action that changes the proof; +9. exactly one `Next proof-changing follow-up:` action that changes the proof; 10. refusal to invent canonical state when a read does not expose it. The GCP harness was then hardened after a nominal false pass: @@ -178,7 +185,7 @@ The hardened direct-claim scorer passes `5/6`. Five replies contain every required signal with no overclaim. `DC-05` has the full structured readback but fails a semantic consistency check. -This is a strict-harness pass, not proof of perfect Cory-style behavior. The +This is a strict-harness pass, not proof of perfect m3taversal-style behavior. The `DC-05` follow-up imprecisely proposed using the strict canary `add_edge` apply path on one of the three approved legacy proposals. Those proposals do not all carry a strict `add_edge` apply payload, so that follow-up requires correction @@ -246,7 +253,7 @@ Then Codex will rotate only the SSH `/32`, bootstrap and live-test the durable IAP operator, run the hardened replay, delete the pending clone/run directory, and verify service/DB/rollback invariants. -## Hard Cory Benchmark Questions +## Hard m3taversal Benchmark Questions Ask these without IDs or schema hints: diff --git a/docs/reports/leo-working-state-20260709/working-leo-three-day-delivery-summary-20260713.md b/docs/reports/leo-working-state-20260709/working-leo-three-day-delivery-summary-20260713.md new file mode 100644 index 0000000..2cfba4c --- /dev/null +++ b/docs/reports/leo-working-state-20260709/working-leo-three-day-delivery-summary-20260713.md @@ -0,0 +1,212 @@ +# Working Leo: Three-Day Delivery Delta + +Window: `2026-07-10 00:00` through `2026-07-13` current delivery wave. + +## Executive Verdict + +**No, Leo is not yet working to the full m3taversal standard.** + +Leo on the VPS is now strong on narrow, proof-grounded operations: it can query +the canonical database, distinguish proposal state from canonical state, return +structured row/count receipts, survive a gateway restart, stage reviewable +changes, and exercise guarded apply/composition lifecycles in disposable clones. +The exact GCP database copy and adapter-free model replay are also proven. + +The remaining product gap is broad unattended judgment. A fresh 12-question +blind suite returned every answer without changing the DB or service, but two +independent strict judges accepted only `1/12` and `2/12` outright. The failures +included invented current schema, invalid edge types, handler proof described as +Telegram-visible, temporary memory treated as provenance, and excessive answer +length. The latest Telegram conversation also exposed participant-name +hallucination and cross-session identity bleed. This delivery wave adds exact +`m3taversal` naming, neutral follow-up labels, current-v1 schema guards, and +regression tests; post-deploy blind and Telegram-visible proof is still required. + +## Starting Point + +Three days ago the phrase "Leo is broken" had no single operational meaning. +We had fragments of evidence, but not a reliable answer to these questions: + +- Is Leo merely replying, or querying the canonical Postgres KB? +- Did reviewer approval create canonical rows, or only update + `kb_stage.kb_proposals`? +- Can Leo turn a new document/post into linked sources, evidence, claims, and + edges rather than a flat answer? +- Does a correction survive session and gateway restart boundaries? +- Is GCP an exact copy of VPS state, or merely a similar deployment? +- Can a broad operator question be answered correctly without supplying IDs and + schema hints? + +The working lane delivered `28` merged PRs from `#72`, `#73`, and `#75` through +`#100` (PR `#90` was squash-merged rather than represented by a merge commit). +That count is delivery history, not proof that all 28 changes are user-visible +features. + +## What Changed + +### July 10: Make KB Truth Executable + +- Built open-ended and no-context direct-claim benchmarks from real Telegram + questions. +- Added fresh VPS preflight, complete DB count/row receipts, overclaim guards, + and Telegram capture receipts. +- Proved an intentional gateway restart and a post-restart handler smoke. +- Added a guarded canonical claim/apply primitive and explicit authorization, + preflight, postflight, validation, rollback, and cleanup contracts. +- Shipped the first live-truth VPS/GCP/onboarding skill pack. + +**Movement:** the standard changed from "the bot replies" to "the answer names +the actual proposal/canonical state and the one proof-changing next action." + +### July 11: Prove Composition And Exact GCP Restore + +- Ran source composition against a disposable full-data VPS clone: new source + bytes were hash-bound, conflicting atomic claims were extracted, evidence and + edges were linked, a strict proposal was staged, approval/apply authority was + separated, and the new graph was rediscovered after a new handler process. +- Captured an exact canonical Postgres snapshot and restored it to GCP staging. +- Verified schema, constraints, indexes, functions, types, triggers, views, + policies, roles, extensions, row counts, row-content hashes, and bounded + performance checks. + +**Movement:** database composition and cloud restore stopped being architecture +claims. They became disposable, repeatable lifecycle proofs with cleanup. + +### July 12: Harden Readback, Apply, And GCP Replay + +- Added Cloud SQL-bound operator and full Working Leo benchmark paths. +- Repaired IAP workflow execution and retained sanitized failure receipts. +- Grounded direct claims in structured DB readback and required complete, + packet-specific receipts. +- Proved the composition/approved-apply lifecycle and corrected the false rule + that every table count must move on every valid apply. +- Hardened GCP replay after a nominal `6/6` falsely printed zero canonical + counts; printed counts must now equal the canonical status receipt. +- Replayed the real adapter-free GCP GatewayRunner with exact count consistency, + unchanged fingerprint/service/profile, no send/write, and cleanup of the + temporary profile. + +**Movement:** a plausible answer can no longer pass merely because its shape +looks right. The harness checks the answer against the database receipt. + +### July 13: Stabilize Deploy Proof And Expose The Broad Gap + +- Added a pasteable private-password helper/skill without printing or committing + secrets. +- Repeated post-deploy VPS direct-claim tests, pinned apply refusal to the exact + deployed SHA, hardened replay bootstrap, and removed heredoc deadlocks. +- Confirmed VPS deploy SHA `48777fd984dcfc195e6c33a8d3f7d78bd0c2e344`, + active gateway PID `1105322`, `NRestarts=0`, and unchanged canonical counts + `1837/4145/4916/4670/26`. +- Ran a 12-question blind suite and a four-turn targeted schema correction + challenge. The correction challenge passed operationally; the blind suite did + not meet the semantic bar. +- Proved through GitHub runs `29227390073` and `29227520353` that the expected + GCP operator/readiness service accounts are absent (`404 Gaia id not found`). + Reusing the shared identity provider alone cannot repair durable access. +- Added the exact Telegram participant rule: address `@m3taversal` only as + `m3taversal`; do not infer or transfer names; keep standard labels neutral. + +**Movement:** the work now has an honest acceptance frontier. Infrastructure and +narrow DB truth are green; broad reasoning and participant identity are red +until post-deploy live tests pass. + +## Participant-Name Leak Root Cause + +The unverified personal name came from the instruction and benchmark layer we +deployed while encoding expected operator behavior. It was not discovered from +a canonical person/profile row: + +1. Both active bridge skills explicitly said the compact answer shape existed + "so Cory gets the expected follow-up" and required every direct answer to end + with `Next Cory-style follow-up:`. +2. The shared skill folder was named `working-leo-cory-outcomes` and repeatedly + described broad questions using that label. +3. Active benchmark prompts used the same label, reinforcing it in expected + answer fixtures and handler tests. +4. The separate shortened value `m3ta` is a real legacy + `reviewed_by_handle`/proposal attribution value. Leo incorrectly generalized + that stored row value into a Telegram form of address. +5. There was no explicit rule binding participant identity to the current + Telegram update, so a session-derived identity could bleed into another + participant's reply. + +The repair changes the deployed VPS/GCP bridge skills, shared operator skill, +benchmark prompts, output labels, and tests. The only permitted address is the +exact visible handle `m3taversal`. The stored database value `m3ta` may be quoted +only when reporting the exact reviewer row, never as a nickname. Historical +artifact filenames and immutable receipts retain their old identifiers so +evidence is not rewritten. + +## Outcome Matrix + +| Dimension | Three days ago | Current evidence | Current status | +| --- | --- | --- | --- | +| Canonical lookup | Mixed memory/file/DB explanations | Complete structured VPS and GCP DB readback | Proven | +| State semantics | Approval often conflated with apply | `proposed/pending/approved/applied` plus `applied_at` and canonical rows | Proven for bounded questions | +| Restart survival | Inferred from uptime | Intentional restart, new PID, unchanged counts, successful handler smoke | Proven on VPS | +| Staging | Vague/manual | Telegram staging and clone staging receipts | Proven at bounded tier | +| Canonical apply | Packet/SQL discussion | Strict separated review/apply lifecycle with row-level postflight and rollback | Isolated proven; broad production apply not run | +| Source composition | Files and proposals not clearly connected | Full-data clone source/evidence/claim/edge composition and rediscovery | Clone-proven; arbitrary production breadth open | +| GCP copy | Similar-looking state | `39` tables, `52,164` rows, zero parity mismatches, private TLS | Proven | +| GCP model reasoning | Nominal score could hide false counts | Adapter-free `6/6` with exact count equality and unchanged state | Proven for direct-claim replay | +| GCP on-demand operation | Password/firewall/provider friction | Two missing service accounts proven; exact bootstrap gate known | Not durable; cleanup open | +| Broad reasoning | Narrow benchmark fixtures | Blind judges: `1/12` strict pass and `2 pass / 4 partial / 6 fail` | Not reliable | +| Conversation memory | Marker and restart cases | Same-session recall works, but one blind run misused memory as provenance | Partial | +| Telegram identity | No explicit participant rule | Exact `m3taversal` rule and regression tests added | Awaiting post-deploy visible proof | +| Identity composition | DB-first direction documented | Current answer contract distinguishes DB rows from rendered `SOUL.md` | Scheduled renderer lifecycle still open | + +## Why The Work Felt Endless + +Several proof tiers were previously summarized together. A passing unit suite, a +no-post GatewayRunner reply, a Telegram-visible reply, a clone apply, a +production apply, and a GCP parity receipt answer different questions. Repeating +tests without naming the tier made progress look circular. + +The current control rule is: + +1. `Runtime`: did a reply return and did the service remain stable? +2. `Truth`: did the reply match current schema and canonical rows? +3. `Delivery`: was it visible in the real Telegram group? +4. `Mutation`: were exact approved payload rows applied with postflight proof? +5. `Persistence`: did the result survive a fresh process/restart/render cycle? +6. `Parity`: does the same path work against the exact GCP copy? + +A row is green only at the tier named in the outcome matrix. + +## Current Repair Order + +1. Merge and auto-deploy the exact participant-name, neutral-label, and current + schema rules to the VPS. +2. Verify deploy SHA, gateway restart, unchanged DB counts, and no orphan + handler/profile resources. +3. Send a concise naming question and broad out-of-sample questions through the + authenticated Telegram Chrome session; capture visible replies and check that + no alias or cross-user identity appears. +4. Rerun the blind handler suite with schema hallucination and identity scoring. +5. After privileged GCP reauthentication, recreate least-privilege operator + identities, prove passwordless status, and delete the retained replay clone + and run directory. + +## Evidence + +- `telegram-handler-blind-oos-audit-current.json` +- `leo-restart-survival-proof-current.json` +- `leo-post-deploy-direct-claim-repeat-current.json` +- `telegram-visible-direct-claim-suite-current.json` +- `leo-source-composition-clone-checkpoint-current.json` +- `approve-claim-clone-canary-current.json` +- `gcp-canonical-parity-live-20260712.json` +- `gcp-operator-access-blocker-current.json` +- Root retained copy proof: + `outputs/gcp-staging-canonical-parity-20260712T1905Z/final-receipt.json` +- Root retained model replay: + `outputs/gcp-cory-model-replay-20260712T1940Z/direct-claim-result-final.json` + +## Completion Rule + +Do not answer "yes" to the whole m3taversal-standard question until the +post-deploy Telegram identity test and a fresh broad blind suite pass, with +unchanged VPS DB/service state; and the GCP durable operator/cleanup lifecycle is +complete. Narrow VPS/GCP capabilities must continue to be reported as proven at +their actual tiers rather than being downgraded or rounded up.