Document three-day Working Leo delivery delta
This commit is contained in:
twentyOne2x
parent
c6c8a5eb31
commit
9e077e2536
5 changed files with 367 additions and 34 deletions
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
]
|
||||
}
|
||||
|
|
|
|||
|
|
@ -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."
|
||||
]
|
||||
}
|
||||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
Loading…
Reference in a new issue