RollingUpdate maxSurge cannot schedule a second 50m pod on a node
packed to 99% CPU requests. Recreate replaces in place; the Service
already has no ready endpoints.
Image sha256:ec15f63d… is commit bc3d80f. Local release check passed
against disposable Postgres. No schema migration. Live Ready still
depends on a fresh runtime lease from ESO/OpenBao.
Assistant: grok
Assistant-Session: 01a0a182-bab7-7f11-b32b-d06f3af52082
Live receiver now reports custody_class=operational with a cited
30-day recoverable window (sha256:05fe1c06). Next workplan is
integrity verification so tamper_evidence can become honest.
SET ROLE during migrate so tables are not owned by a disposable lease.
Current image sha256:aec5575. T02/T03 recorded done after live rotation
and rollout undo. T05 remote run is partial (port-forward dropped).
Database leases come from ClusterSecretStore openbao-audit-core-database
(one extract, one lease). Senders are minted in-cluster. Secret mounts
use fsGroup 10001. Schema 0001-0004 applied after dropping the isolation
stub events table. /readyz reports custody_class=archive.
VaultDynamicSecret pulls database/creds/* so a rotating lease is not frozen
into KV. Runtime sets AUDIT_CORE_AUTO_MIGRATE=0; schema is a Job with the
migration lease. Image base is digest-pinned. Namespace and NetworkPolicies
are on the cluster; Deployment waits for the attended OpenBao ESO token.
