Ground Leo direct claims in structured DB readback

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.

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.

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