Refresh Leo production apply authorization gate

docs/reports/leo-working-state-20260709/current-truth-index.md

@@ -158,7 +158,7 @@ Use this file before making status claims. Prefer fresh VPS/GCP readbacks when c
 - The authorized apply operator runbook is generated and ready-not-executed: it gives preflight/apply/postflight/rollback command templates in manifest order, requires `TELEO_DATABASE_URL`, and now also includes a post-apply regression command bundle plus required production-apply receipt fields and an offline receipt validator. It still does not authorize or execute production SQL.
 - The authorized apply session plan is generated and ready-not-executed: it maps concrete output log paths for pre-apply validation, preflight, apply, postflight, post-apply regression, service readback, cleanup readback, receipt validation, and rollback. Apply and rollback steps require explicit authorization; non-apply steps are marked non-mutating.
 - The production apply authorization packet is generated and ready-to-request, not authorized/executed: all evidence gates pass, it names the exact integrated packet order and the operator authorization template, requires a fresh deployed-SHA readback at apply time, and keeps `production_apply_executed=false` plus `production_apply_authorization_present=false`.
-- The production apply authorization verifier currently refuses the apply window in the committed artifact: `deployed_sha_shape=false`, `fresh_deployed_sha_required=true`, `authorization_text_present=false`, `operator_identity_present=false`, `authorization_text_matches_expected=false`, `safe_to_enter_apply_window=false`, and `production_apply_executed=false`. At apply time, it must be rerun with a fresh deployed-SHA readback.
+- The production apply authorization verifier currently refuses the apply window in the committed artifact with fresh deployed SHA `a717965b4527819e6d06e3a779e4855629058318`: `deployed_sha_shape=true`, `fresh_deployed_sha_required=false`, `authorization_text_present=false`, `operator_identity_present=false`, `authorization_text_matches_expected=false`, `safe_to_enter_apply_window=false`, and `production_apply_executed=false`. It now fails only on missing exact authorization text/operator identity, not stale deploy ambiguity.
 - The live production preflight baseline now passes through the read-only collector: `5/5` preflight files executed on the VPS with `begin transaction read only`, `mutates_production_db=false`, `applies_production_packet=false`, and `production_apply_executed=false`. Current production still has generated base rows `0/0/0/0`, Helmer rows `0/0/0/0/0`, no generated governance/concept tables, and dependent Rio/cross-surface/governance base rows absent before any apply, as expected.
 - The production apply receipt template is generated but intentionally invalid as a final receipt: `production_apply_executed=false`, `valid_production_receipt=false`, and it names the fields that must only be filled after authorized apply execution (`explicit_authorization_record`, `operator_identity`, `apply_output_paths`, `postflight_output_paths`, `actual_after_apply_counts`, `telegram_or_handler_regression_paths`, `service_readback`, `cleanup_readback`).
 - The production apply receipt assembler currently refuses final receipt emission: `receipt_ready=false`, `authorization_verified=false`, `all_session_artifacts_exist=false`, `actual_counts_match_expected=false`, no apply/postflight/regression/service/cleanup logs exist, and `production_apply_executed=false`.

docs/reports/leo-working-state-20260709/working-leo-current-state-20260709.md

@@ -189,7 +189,7 @@ A working Leo, for Cory/m3taversal's current expectation, is a Telegram-facing a
   - `safe_to_enter_apply_window=false`
   - `production_apply_executed=false`
   - `production_apply_authorization_present=false`
-  - the committed verifier artifact keeps `<DEPLOYED_SHA_READBACK>` as a placeholder and refuses because a fresh deployed SHA, authorization text, and operator identity are absent
+  - the committed verifier artifact uses deployed SHA `a717965b4527819e6d06e3a779e4855629058318` and refuses because exact authorization text and operator identity are absent
 - Live production preflight baseline is now retained:
   - the collector ran on the VPS with `--transport local-docker`, `execute_requested=true`, `mutates_production_db=false`, `applies_production_packet=false`, `production_apply_executed=false`, and `readonly_transaction_wrapper=true`
   - `5/5` preflight SQL files returned `ok=True`

docs/reports/leo-working-state-20260709/working-leo-execution-plan-current.md

@@ -105,7 +105,7 @@ Claim ceiling: VPS Telegram memory/KB audit, full live-safe open-ended Telegram
 
 ## WL-EXEC-06B - Integrated production-order packet rehearsal
 - Status: `done_integrated_clone_ready_not_executed`
-- Result: Applied the full prepared packet set in one disposable clone in dependency order: mapped base, cross-surface anchor, Rio strategy context, governance/concept schema, and Helmer 7 Powers. Expected integrated footprint was `12` claims, `28` sources, `18` claim edges, `34` claim evidence rows, `1` reasoning tool, `2` Rio strategy nodes, `5` Rio strategy anchors, `1` concept map, `1` concept link, `2` governance links, one Helmer ledger row marked applied, and one cross-surface anchor update. Reverse rollback restored all generated rows/schema to zero/absent, restored the cross-surface anchor to the old claim, restored the Helmer ledger to `approved`, dropped the disposable DB, removed temp files, and left production unchanged. The apply-readiness verifier now passes over the retained manifest/files/logs with `ready_for_authorized_production_apply_packet=true`, `production_apply_executed=false`, and `production_apply_authorization_present=false`. The authorized apply runbook now emits preflight/apply/postflight/rollback command templates in manifest order, a read-only pre-apply production baseline collector, a post-apply regression command bundle, a required production-apply receipt schema, and an offline receipt validator with `status=ready_not_executed`. The authorized apply session plan maps concrete output paths for pre-apply validation, preflight, apply, postflight, post-apply regression, service readback, cleanup readback, receipt validation, and rollback; apply and rollback steps require explicit authorization, non-apply steps are non-mutating, and `production_apply_executed=false`. The production apply authorization packet now passes all evidence gates and retains the operator authorization template plus fresh deployed-SHA requirement while keeping `production_apply_executed=false` and `production_apply_authorization_present=false`. The committed authorization verifier keeps `<DEPLOYED_SHA_READBACK>` as a placeholder and refuses the apply window with `safe_to_enter_apply_window=false` because fresh deployed SHA, authorization text, and operator identity are absent. The receipt assembler now proves no final receipt can be emitted yet: `receipt_ready=false`, `authorization_verified=false`, `all_session_artifacts_exist=false`, `actual_counts_match_expected=false`, and `production_apply_executed=false`. The live production preflight baseline ran through `begin transaction read only` and passed `5/5` with no production apply executed.
+- Result: Applied the full prepared packet set in one disposable clone in dependency order: mapped base, cross-surface anchor, Rio strategy context, governance/concept schema, and Helmer 7 Powers. Expected integrated footprint was `12` claims, `28` sources, `18` claim edges, `34` claim evidence rows, `1` reasoning tool, `2` Rio strategy nodes, `5` Rio strategy anchors, `1` concept map, `1` concept link, `2` governance links, one Helmer ledger row marked applied, and one cross-surface anchor update. Reverse rollback restored all generated rows/schema to zero/absent, restored the cross-surface anchor to the old claim, restored the Helmer ledger to `approved`, dropped the disposable DB, removed temp files, and left production unchanged. The apply-readiness verifier now passes over the retained manifest/files/logs with `ready_for_authorized_production_apply_packet=true`, `production_apply_executed=false`, and `production_apply_authorization_present=false`. The authorized apply runbook now emits preflight/apply/postflight/rollback command templates in manifest order, a read-only pre-apply production baseline collector, a post-apply regression command bundle, a required production-apply receipt schema, and an offline receipt validator with `status=ready_not_executed`. The authorized apply session plan maps concrete output paths for pre-apply validation, preflight, apply, postflight, post-apply regression, service readback, cleanup readback, receipt validation, and rollback; apply and rollback steps require explicit authorization, non-apply steps are non-mutating, and `production_apply_executed=false`. The production apply authorization packet now passes all evidence gates and retains the operator authorization template plus fresh deployed-SHA requirement while keeping `production_apply_executed=false` and `production_apply_authorization_present=false`. The committed authorization verifier now uses deployed SHA `a717965b4527819e6d06e3a779e4855629058318` and refuses the apply window with `safe_to_enter_apply_window=false` because exact authorization text and operator identity are absent. The receipt assembler now proves no final receipt can be emitted yet: `receipt_ready=false`, `authorization_verified=false`, `all_session_artifacts_exist=false`, `actual_counts_match_expected=false`, and `production_apply_executed=false`. The live production preflight baseline ran through `begin transaction read only` and passed `5/5` with no production apply executed.
 - Next action: If production apply is explicitly authorized, use the generated runbook order, run every postflight SQL file, run the post-apply regression bundle, retain the production receipt, and then rerun any user-visible Telegram canary needed for the demo/meeting tier.
 - Not done condition: Production canonical rows/schema remain unapplied until explicit production apply authorization.
 - Evidence:

docs/reports/leo-working-state-20260709/working-leo-production-apply-authorization-verification-current.json

@@ -6,15 +6,15 @@
     "auth_packet_ready": true,
     "authorization_text_matches_expected": false,
     "authorization_text_present": false,
-    "deployed_sha_shape": false,
+    "deployed_sha_shape": true,
     "operator_identity_present": false,
     "telegram_visible_post_not_authorized": true
   },
   "claim_ceiling": "This verifier only checks whether an authorization string is valid for the current deployed SHA. It does not run SQL, does not mutate production, and does not prove canonical rows were changed.",
-  "deployed_sha": "",
-  "expected_authorization_text": "I authorize production DB apply for the integrated Working Leo packet set on VPS using deployed commit <DEPLOYED_SHA_READBACK> in this order: mapped-rich-base, cross-surface-anchor, rio-strategy-context, governance-concept-schema, helmer-7powers. Run preflight immediately before each phase, run the authorized apply SQL, run every postflight, run the non-posting direct-claim regression and scorer, capture service and cleanup readbacks, validate the production receipt, and do not post Telegram-visible messages unless separately authorized.",
-  "fresh_deployed_sha_required": true,
-  "generated_at_utc": "2026-07-10T02:35:01.535934+00:00",
+  "deployed_sha": "a717965b4527819e6d06e3a779e4855629058318",
+  "expected_authorization_text": "I authorize production DB apply for the integrated Working Leo packet set on VPS using deployed commit a717965b4527819e6d06e3a779e4855629058318 in this order: mapped-rich-base, cross-surface-anchor, rio-strategy-context, governance-concept-schema, helmer-7powers. Run preflight immediately before each phase, run the authorized apply SQL, run every postflight, run the non-posting direct-claim regression and scorer, capture service and cleanup readbacks, validate the production receipt, and do not post Telegram-visible messages unless separately authorized.",
+  "fresh_deployed_sha_required": false,
+  "generated_at_utc": "2026-07-10T04:27:18.845143+00:00",
   "mode": "authorization_verification_only",
   "next_action_if_verified": [
     "Re-run production preflight immediately before each packet phase.",
@@ -27,5 +27,5 @@
   "production_apply_executed": false,
   "provided_authorization_text_hashable_length": 0,
   "safe_to_enter_apply_window": false,
-  "status": "missing_fresh_deployed_sha"
+  "status": "missing_authorization_text"
 }

docs/reports/leo-working-state-20260709/working-leo-production-apply-authorization-verification-current.md

@@ -1,12 +1,12 @@
 # Working Leo Production Apply Authorization Verification
 
-Generated UTC: `2026-07-10T02:35:01.535934+00:00`
+Generated UTC: `2026-07-10T04:27:18.845143+00:00`
 Mode: `authorization_verification_only`
-Status: `missing_fresh_deployed_sha`
+Status: `missing_authorization_text`
 Safe to enter apply window: `False`
 Production apply executed: `False`
 Production apply authorization present: `False`
-Deployed SHA: ``
+Deployed SHA: `a717965b4527819e6d06e3a779e4855629058318`
 Operator identity: ``
 
 ## Checks
@@ -16,13 +16,13 @@ Operator identity: ``
 - `auth_packet_ready`: `True`
 - `authorization_text_matches_expected`: `False`
 - `authorization_text_present`: `False`
-- `deployed_sha_shape`: `False`
+- `deployed_sha_shape`: `True`
 - `operator_identity_present`: `False`
 - `telegram_visible_post_not_authorized`: `True`
 
 ## Expected Authorization Text
 
-I authorize production DB apply for the integrated Working Leo packet set on VPS using deployed commit <DEPLOYED_SHA_READBACK> in this order: mapped-rich-base, cross-surface-anchor, rio-strategy-context, governance-concept-schema, helmer-7powers. Run preflight immediately before each phase, run the authorized apply SQL, run every postflight, run the non-posting direct-claim regression and scorer, capture service and cleanup readbacks, validate the production receipt, and do not post Telegram-visible messages unless separately authorized.
+I authorize production DB apply for the integrated Working Leo packet set on VPS using deployed commit a717965b4527819e6d06e3a779e4855629058318 in this order: mapped-rich-base, cross-surface-anchor, rio-strategy-context, governance-concept-schema, helmer-7powers. Run preflight immediately before each phase, run the authorized apply SQL, run every postflight, run the non-posting direct-claim regression and scorer, capture service and cleanup readbacks, validate the production receipt, and do not post Telegram-visible messages unless separately authorized.
 
 ## Next Action If Verified