# Approved Claim Bundle Isolation Canary

Status: `pass`

## Working Target

A Cory-approved strict bundle must move through a separate reviewer credential,
an immutable approval snapshot, and a narrow apply credential before exact
claim/source/evidence/edge/reasoning-tool rows become canonical. A stale payload,
replay, hash collision, or direct privilege bypass must leave no partial rows.

## Final Runtime Proof

- Generic bundle: `37/37` checks passed. Its exact payload-controlled projection
  and exact table deltas were `2` claims, `2` sources, `2` evidence links, `1`
  edge, and `1` reasoning tool.
- Real Helmer bundle: `37/37` checks passed. Its exact payload-controlled
  projection and exact table deltas were `5` claims, `13` sources, `17`
  evidence links, `7` edges, and `1` reasoning tool.
- Helmer source proposal: `a64df080-8502-42e2-98f4-9bbdecb8da73`; strict child
  proposal in the final isolated run: `87344d36-5005-5d88-a04c-067aeceda3c3`.
- `kb_review` approved the exact pending type and full JSON payload as mapped
  reviewer `m3ta`; the immutable approval row matched the proposal ledger.
- `kb_apply` could not directly update proposal status/payload, immutable
  approval rows, or existing `claim_evidence` rows.
- Mutating the approved ledger after SQL generation made the stale apply fail
  before canonical writes; restoring the ledger left the immutable approval
  unchanged.
- Replay was refused. A different source ID reusing an existing source hash was
  refused, and its proposal/approval remained intact with zero partial rows.
- Every payload-controlled persisted field, including weights, roles, owners,
  tags, hashes, and relationships, matched the reviewed payload. Exact table
  deltas also exclude unexpected extra rows under unrelated IDs.
- The migration readback proves one expected signature per gate function, no
  legacy overload, no protected-role membership, no object owned by a login
  role, and the exact reviewer/apply execute split.

## Isolation And Cleanup

- Both runs used a new unexposed `postgres:16` container built from a read-only
  schema/reference copy of live `teleo`; no cluster-wide role was created in the
  production `teleo-pg` instance.
- The wrapper issued read-only queries to live `teleo-pg`; endpoint counts were
  identical before and after each final run, with zero deltas for all six tables:
  `claims=1837`, `sources=4145`, `claim_evidence=4670`, `claim_edges=4916`,
  `reasoning_tools=17`, `kb_proposals=26`. This is endpoint-count evidence, not
  a claim that every live row byte was compared.
- `leoclean-gateway.service` stayed `active/running`, `MainPID=2999690`,
  `NRestarts=0`.
- Inner clone databases, outer Postgres containers, temporary workdirs, and the
  remote source bundle were removed. Independent name/path readbacks found no
  residue after cleanup.
- Both receipts retain repo-relative SHA-256/size bindings for the apply,
  approval, prerequisite SQL, inner canary, and isolation wrapper source files;
  a local recomputation matched every retained hash.
- No Telegram message, production canonical apply, production permission
  migration, service restart, or runtime-profile write occurred.

## Reproduce

Generic bundle:

```bash
scripts/run_approve_claim_isolated_container_canary.sh \
  --output docs/reports/leo-working-state-20260709/approve-claim-clone-canary-current.json
```

Real normalized Helmer bundle:

```bash
scripts/run_approve_claim_isolated_container_canary.sh \
  --normalization-json docs/reports/leo-working-state-20260709/helmer-approve-claim-normalization-current.json \
  --output docs/reports/leo-working-state-20260709/helmer-approve-claim-clone-canary-current.json
```

## Evidence And Claim Ceiling

- Generic receipt: `approve-claim-clone-canary-current.json`
- Helmer receipt: `helmer-approve-claim-clone-canary-current.json`
- Lossless normalization: `helmer-approve-claim-normalization-current.json`
- Inner harness: `scripts/run_approve_claim_clone_canary.py`
- Isolation wrapper: `scripts/run_approve_claim_isolated_container_canary.sh`

This proves the repo-owned review/apply lifecycle at isolated runtime tier. It
does not mean the new code, reviewer/apply roles, or permission migration are
deployed on VPS production, and it does not mean Helmer is canonical there.
`kb_apply` remains an operator-only trusted canonical writer; the proof covers
the supplied tool and privilege matrix, not a compromised apply credential.