From e8d1a0fe3b08f4a7f15b3254d40c96d1aa5e6d07 Mon Sep 17 00:00:00 2001 From: twentyOne2x Date: Sun, 12 Jul 2026 10:25:15 +0200 Subject: [PATCH] Ground Leo direct claims in structured DB readback --- .../gcp/teleo-kb-bridge/SKILL.md | 40 +++++++++++---- .../vps/teleo-kb-bridge/SKILL.md | 51 +++++++++++++------ tests/test_hermes_leoclean_skill_surfaces.py | 14 +++-- 3 files changed, 75 insertions(+), 30 deletions(-) diff --git a/hermes-agent/leoclean-skills/gcp/teleo-kb-bridge/SKILL.md b/hermes-agent/leoclean-skills/gcp/teleo-kb-bridge/SKILL.md index 71f6dbd..e61c469 100644 --- a/hermes-agent/leoclean-skills/gcp/teleo-kb-bridge/SKILL.md +++ b/hermes-agent/leoclean-skills/gcp/teleo-kb-bridge/SKILL.md @@ -121,11 +121,16 @@ proof language below. These are behavioral examples, not feature changes. - "Can I demo Leo changes the KB?": lead with `staging yes, canonical KB change not safe to demo from chat`. Include `demo tier` language. A safe demo can show a real staging write to `kb_stage.kb_proposals` and read it back. - Canonical mutation of - `public.claims`, `public.sources`, `public.claim_evidence`, or - `public.claim_edges` is not provable from chat and is not yet, blocked on - apply tooling until explicit operator/admin authorization, an apply tool, and - before/after postflight readback exist. + Canonical mutation is not provable from chat alone and is not a normal chat + command. State the exact current tier: + the strict existing-ID `add_edge` path is live-proven on VPS; guarded + `approve_claim` bundles and the rich packet set are clone-proven behind + separate reviewer and apply roles; equivalent GCP execution is not yet + proven. Current approved legacy packets without strict `apply_payload` are + not worker-applyable. A canonical demo therefore still requires explicit + operator/admin authorization, the matching reviewed apply path, and retained + before/after postflight readback. Never collapse that into the false global + statement that no apply tooling exists. - "Did editing SOUL.md change canonical identity?": answer `no`. `SOUL.md` is a runtime/rendered artifact, not canonical Postgres, not the source of truth, not a canonical commit, and not collective truth; canonical identity requires @@ -137,10 +142,19 @@ proof language below. These are behavioral examples, not feature changes. postflight/render-sync proof; without those rows, canonical identity is unchanged.` -Every direct-claim answer must include row-level proof vocabulary such as -`current readback`, `row-link audit`, `row IDs`, `new or updated rows`, -`applied_at`, `kb_stage.kb_proposals`, `public.*`, and `postflight proof` -where relevant. End with exactly one final line beginning +Before every direct-claim answer, run a fresh bridge read. Use `status` for +canonical counts, `search-proposals` followed by `show-proposal` for a named +proposal, and `decision-matrix-status` for matrix questions. Never invent or +reuse a stale count. + +Every direct-claim answer must contain one compact line beginning `DB readback:` +and copy either (a) a full UUID plus observed `status` and `applied_at`, or (b) +exact observed counts for the relevant `claims`, `sources`, `claim_edges`, +`claim_evidence`, and `kb_proposals` tables. Short eight-character IDs and +phrases such as `current readback` are not structured proof by themselves. +Also use row-level proof vocabulary such as `row-link audit`, `row IDs`, +`new or updated rows`, `public.*`, and `postflight proof` where relevant. End +with exactly one final line beginning `Next Cory-style follow-up:` that asks for or offers the next proof-changing action. @@ -277,5 +291,9 @@ raw container shell commands. Prefer one of: before/after readback. When applying is requested, inspect `teleo-kb --help` and the proposal first, -then state the exact available apply path. If no apply command exists, say that -the proposal is staged and needs the reviewer/operator apply path. +then state the exact available apply path and proof tier. The normal chat bridge +does not expose an apply command, but repository apply tooling exists; VPS +existing-ID apply is live-proven, richer bundles are clone-proven, and GCP +execution remains unproven. Name the missing production migration, worker, +strict payload, authorization, or GCP proof instead of saying globally that +apply tooling does not exist. diff --git a/hermes-agent/leoclean-skills/vps/teleo-kb-bridge/SKILL.md b/hermes-agent/leoclean-skills/vps/teleo-kb-bridge/SKILL.md index b0901a0..cb00e11 100644 --- a/hermes-agent/leoclean-skills/vps/teleo-kb-bridge/SKILL.md +++ b/hermes-agent/leoclean-skills/vps/teleo-kb-bridge/SKILL.md @@ -113,11 +113,16 @@ proof language below. These are behavioral examples, not feature changes. - "Can I demo Leo changes the KB?": lead with `staging yes, canonical KB change not safe to demo from chat`. Include `demo tier` language. A safe demo can show a real staging write to `kb_stage.kb_proposals` and read it back. - Canonical mutation of - `public.claims`, `public.sources`, `public.claim_evidence`, or - `public.claim_edges` is not provable from chat and is not yet, blocked on - apply tooling until explicit operator/admin authorization, an apply tool, and - before/after postflight readback exist. + Canonical mutation is not provable from chat alone and is not a normal chat + command. State the exact current tier: + the strict existing-ID `add_edge` path is live-proven; guarded `approve_claim` + bundles and the rich packet set are clone-proven behind separate reviewer and + apply roles; the production permission migration and apply worker remain + disabled. Current approved legacy packets without strict `apply_payload` are + not worker-applyable. A canonical demo therefore still requires explicit + operator/admin authorization, the matching reviewed apply path, and retained + before/after postflight readback. Never collapse that into the false global + statement that no apply tooling exists. - "Did editing SOUL.md change canonical identity?": answer `no`. `SOUL.md` is a runtime/rendered artifact, not canonical Postgres, not the source of truth, not a canonical commit, and not collective truth; canonical identity requires @@ -129,10 +134,20 @@ proof language below. These are behavioral examples, not feature changes. postflight/render-sync proof; without those rows, canonical identity is unchanged.` -Every direct-claim answer must include row-level proof vocabulary such as -`current readback`, `row-link audit`, `row IDs`, `new or updated rows`, -`applied_at`, `kb_stage.kb_proposals`, `public.*`, and `postflight proof` -where relevant. End with exactly one final line beginning +Before every direct-claim answer, run a fresh bridge read. Use +`search-proposals` followed by `show-proposal` for a named proposal and +`decision-matrix-status` for matrix questions. If those bridge commands do not +return the exact canonical counts needed for the question, use the documented +read-only Postgres fallback. Never invent or reuse a stale count. + +Every direct-claim answer must contain one compact line beginning `DB readback:` +and copy either (a) a full UUID plus observed `status` and `applied_at`, or (b) +exact observed counts for the relevant `claims`, `sources`, `claim_edges`, +`claim_evidence`, and `kb_proposals` tables. Short eight-character IDs and +phrases such as `current readback` are not structured proof by themselves. +Also use row-level proof vocabulary such as `row-link audit`, `row IDs`, +`new or updated rows`, `public.*`, and `postflight proof` where relevant. End +with exactly one final line beginning `Next Cory-style follow-up:` that asks for or offers the next proof-changing action. @@ -240,10 +255,13 @@ it does not directly mutate canonical `public.*` rows from normal chat. If a reviewer explicitly asks for proposal status reconciliation or canonical application, inspect the proposal first, use the narrowest available bridge or -admin apply path, and retain before/after readback. If no `teleo-kb apply-*` -command exists, say that the proposal is staged and needs reviewer/operator -apply tooling rather than inviting ad hoc SQL from chat. Do not treat a chat -statement, runtime memory, or a staged proposal as canonical truth. +admin apply path, and retain before/after readback. The normal chat bridge does +not expose `teleo-kb apply-*`, but the repository contains a live-proven strict +existing-ID `add_edge` path and clone-proven guarded `approve_claim` tooling. +Name which exact operation/tier is available, and say when the production +permission migration, worker, strict payload, or explicit authorization is +still missing. Do not invite ad hoc SQL from chat or treat a chat statement, +runtime memory, or staged proposal as canonical truth. Never end a normal Telegram answer by offering to run direct `INSERT`, `UPDATE`, or transaction SQL from chat. Even if the user is authorized, the product flow is @@ -255,6 +273,7 @@ before/after rows; let a reviewer approve, reject, edit, or run a dedicated apply tool with retained readback. ``` -If the current bridge lacks a dedicated apply command, say exactly that and stop -at a reviewable apply plan. The next thing Leo may offer from chat is to draft or -refresh the admin review packet, not to mutate canonical tables directly. +Because the current chat bridge has no apply command, stop at the exact reviewed +operator path and its authorization boundary. The next thing Leo may offer from +chat is to draft or refresh the admin review packet, not to mutate canonical +tables directly. diff --git a/tests/test_hermes_leoclean_skill_surfaces.py b/tests/test_hermes_leoclean_skill_surfaces.py index 9526227..4c25f0c 100644 --- a/tests/test_hermes_leoclean_skill_surfaces.py +++ b/tests/test_hermes_leoclean_skill_surfaces.py @@ -27,7 +27,11 @@ def test_gcp_kb_skill_uses_cloudsql_bridge_not_vps_docker() -> None: assert "not applied" in text assert "canonical KB change not safe to demo from chat" in squashed assert "not provable from chat" in text - assert "not yet, blocked on apply tooling" in squashed + assert "equivalent GCP execution is not yet proven" in squashed + assert "false global statement that no apply tooling exists" in squashed + assert "DB readback:" in text + assert "full UUID plus observed `status` and `applied_at`" in squashed + assert "Short eight-character IDs" in text assert "canonical identity requires DB rows plus" in squashed assert "not canonical Postgres" in text assert "not the source of truth" in text @@ -68,7 +72,11 @@ def test_vps_kb_skill_keeps_vps_scope_explicit() -> None: assert "not applied" in text assert "canonical KB change not safe to demo from chat" in squashed assert "not provable from chat" in text - assert "not yet, blocked on apply tooling" in squashed + assert "production permission migration and apply worker remain disabled" in squashed + assert "false global statement that no apply tooling exists" in squashed + assert "DB readback:" in text + assert "full UUID plus observed `status` and `applied_at`" in squashed + assert "Short eight-character IDs" in text assert "canonical identity requires DB rows plus" in squashed assert "not canonical Postgres" in text assert "not the source of truth" in text @@ -79,7 +87,7 @@ def test_vps_kb_skill_keeps_vps_scope_explicit() -> None: assert "I cannot claim canonical DB changed" in text assert "explicit operator/admin authorization" in text assert "Do not call an approved proposal \"implemented\"" in text - assert "needs reviewer/operator apply tooling rather than inviting ad hoc SQL from chat" in squashed + assert "repository contains a live-proven strict existing-ID `add_edge` path" in squashed assert "Never end a normal Telegram answer by offering to run direct `INSERT`, `UPDATE`" in text assert "Next admin-panel action" in text assert "draft or refresh the admin review packet" in squashed