record deployed KB replay receipt proof

This commit is contained in:
twentyOne2x 2026-07-14 03:36:39 +02:00
parent 7634fc9208
commit 60a98545c1
3 changed files with 25 additions and 8 deletions

View file

@ -8,8 +8,10 @@ The current canonical handoff is
`working-leo-three-day-outcome-and-forward-path-20260714.md`. This section
supersedes the July 13 verdict below.
- VPS deploy and stamp both equal merge
`aa1246c603020bef07a575e4aebf4f2d2ed5db0c`; gateway PID `366950`,
- VPS gateway behavior was restart-proven at merge
`aa1246c603020bef07a575e4aebf4f2d2ed5db0c`; the deploy-infra workspace is now
at operator-script merge `7634fc9208f1b43a0037d6c2e246112e18c841fd`.
The script-only delivery did not restart the gateway: PID `366950`,
`NRestarts=0`, active/running, start `2026-07-14 00:25:49 UTC`.
- Live counts are claims `1837`, sources `4145`, edges `4916`, evidence `4670`,
proposals `29`; proposal states are applied `2`, approved `3`, pending review

View file

@ -1,8 +1,16 @@
{
"artifact": "kb_apply_replay_receipt_live_recovery_canary",
"claim_ceiling": "The guarded apply path now has a private row-level receipt and receipt-only recovery implementation. The live VPS canary proved recovery for the existing strict add_edge proposal without a database write. Other supported apply types are covered by static tests but still require disposable-clone lifecycle proof. This does not yet provide a complete genesis-plus-ledger blank-database runner.",
"current_canary": "Recover the exact canonical rows and immutable reviewed payload for an already-applied strict proposal, write a mode-0600 private receipt, and leave the production database and Leo gateway unchanged.",
"generated_at_utc": "2026-07-14T01:08:23Z",
"current_canary": "Using the merged VPS deployment and real teleo service user, recover the exact canonical rows and immutable reviewed payload for an already-applied strict proposal, write a mode-0600 private receipt, and leave the production database and Leo gateway unchanged.",
"deployment": {
"auto_deploy_completed": true,
"deployed_commit": "7634fc9208f1b43a0037d6c2e246112e18c841fd",
"deployed_script_present": true,
"executed_as_user": "teleo",
"receipt_owner": "teleo:teleo",
"receipt_path_was_default": true
},
"generated_at_utc": "2026-07-14T01:35:09Z",
"live_vps_read_only": {
"actual_row_counts": {
"claim_edges": 1

View file

@ -144,9 +144,12 @@ unchanged, and removed its temporary profile.
### 5. Prove restart and named-proposal readback
The deployed VPS is at merge `aa1246c603020bef07a575e4aebf4f2d2ed5db0c`.
After the managed restart, `leoclean-gateway.service` was active with PID
`366950`, `NRestarts=0`, and start timestamp `2026-07-14 00:25:49 UTC`.
The gateway behavior was restart-proven at merge
`aa1246c603020bef07a575e4aebf4f2d2ed5db0c`. The deploy-infra workspace is now
at script-and-document merge `7634fc9208f1b43a0037d6c2e246112e18c841fd`;
that operator-only delivery did not restart the gateway. `leoclean-gateway.service`
remains active with PID `366950`, `NRestarts=0`, and start timestamp
`2026-07-14 00:25:49 UTC`.
The exact post-restart question claimed that the V3 document was already live
because a proposal existed. The live handler correctly answered `No` and
@ -181,8 +184,12 @@ recent source-to-answer chain is:
| `#131` | retained V3 document lifecycle proof |
| `#132` | named/versioned document proposal matching and readback |
| `#133` | live response-validator compatibility for that readback |
| `#134` | canonical three-day VPS/GCP/rebuild outcome handoff |
| `#135` | current post-V3 snapshot and exact local rebuild proof |
| `#136` | private row-level replay receipts for guarded applies |
All seven are merged. The VPS managed deploy stamp matches `#133`.
All ten are merged. The VPS gateway restart proof matches `#133`; the current
deploy-infra operator workspace matches `#136` without a gateway restart.
## VPS: What Works Now