coulomb-social/docs/release/storage-release-review-2026-10-31.md

Refreshed storage release — founder terminal steps

Founder executed and independently verified on 2026-10-31; Helm revision 18. This replaces the held October 29 proposal, which correctly refused after current data changed. The old capsule is preserved.

Exact proposal: sha256:5fd7ccd8f68057346367d81efb82b48280a16dd31d87683a5bd83e60e3d1837e. Execution decision: 9b320990-0688-4fa9-a947-4b54cf01f5c7.

Verified execution return

The founder ran the exact attended command below. The durable native receipt completed at 00:29:28Z in 99.527 seconds with storage_candidate_deployed_verified. Independent native postflight verifies the same deployment UID, one Ready replica on image51281946, Helm revision18/deployed, migration0003 and both uniqueness constraints. All92business rows and86content files have the same hashes as before deployment; all40owner pages render and40unsaved-outsider requests are denied. The installed snapshot helper hash matches the sealed replacement4ff81b79 and its server dry-run passes. The unchanged paired worker retains hash43e119ac. All73packaged source files match source17d0eb6 exactly. No timer was activated and no production data was restored. The original sealed manifest remains historical, including its prepared approval-status field; it is not rewritten.

Evidence: storage-release-receipt-2026-10-31.json, storage-release-independent-postflight-2026-10-31.json and storage-release-source-provenance-2026-10-31.json. The founder command below is historical and must not be replayed: the durable journal already exists.

Deployment-owner source reconciliation is committed/pushed at railiance-apps 8434134: only the image tag/digest changed in tracked values, plus the native receipt. Helm lint passes and the owner render exactly matches the sealed candidate manifest hash865b6a22. The product release-unit image/source pins now name the verified live image51281946/source17d0eb6.

Current data and recovery

The founder ran the existing admitted paired backup at 2026-10-30T23:50:40Z. The node receipt matches the reported primary version 1793404296527269 and ciphertext hash 59c2724399f067fabaa53550ffe52205e4752c91a5064e173b59859f9dea4744. The app resumed and has one Ready replica on its existing image. A separate mirror publication and independent reader retrieval match this exact point. The dedicated decryption identity was fetched separately from its protected escrow; no personal Console session or identity on the production node was used.

Isolated recovery compares all 13 SQL tables, 113 rows and sequence state with the dump, plus all 86 content files with the archive. The release baseline excludes migration bookkeeping: 12 business tables and 92 business rows. The recovered aggregate hashes equal the fresh production preflight. All 40 pages render through actual views; owner access, synthetic viewer restrictions and ungranted-member denials pass. Synthetic changes roll back.

The packaged candidate passes forward migration, cross-tenant slug collision refusal, reverse migration, refusal of a deliberately colliding legacy dataset and reapply, preserving all business rows and content. The old packaged image also renders all 40 pages and preserves access denials after the migration.

A complete refreshed kit containing encrypted data, images and recovery tools is retained in the protected provider bucket without automatic expiry. The final drill independently retrieves that kit, verifies all 2,098 members, fetches the identity from separate escrow, loads retained images and restores the app in 42.651 seconds. It uses an existing Docker daemon, preinstalled scoped API bootstrap client and an internal network without published ports. It does not establish recovery of the operator account or a real-browser OIDC journey. The proof is separately protected and independently read back.

The isolated drill exposed an intermittent restore-readiness issue. A synthetic native PostgreSQL startup observation shows the initialization Unix socket can be ready before the target database is usable over TCP. The recovery helper now waits for a successful query against that final database and accepts an explicit protected work root. The corrected helper is in the final kit. The earlier kit whose drill failed is preserved for owner disposition; it is not the accepted recovery reference. No production helper was replaced by these changes.

Exact release scope

The candidate, chart, values, launcher, node executor, probe and snapshot-helper bytes are unchanged from the October 29 code reviewed at railiance-apps 45d6178. Only the proposal metadata, recovered-data baseline and independent recovery references changed. The 12-member capsule is bound by the new digest. Its source manifest is retained in storage-release-proposal-2026-10-31.json. The four exact rehearsal evidence files named there live under storage-release-evidence-2026-10-31/; their bytes match the sealed hashes.

Target: existing coulomb-social Helm revision 17 on railiance01. Candidate source 17d0eb67f397e3d1f5b9b63880df5054aa263c5a, image sha256:512819463a1902b43a615beee14be7bf97e6a05e016385082b9380692ad1a8cd. It introduces global slug constraint 0003 and the previously reviewed storage hardening. Later source-only OIDC/UserInfo fixes are outside this image and need their own subsequent reviewed release.

The attended command rechecks the exact cluster/deployment/PVC/Helm/data baseline, readiness/headroom, absence of Argo adoption and rendered manifests. It performs another fresh admitted paired backup and immutable primary readback, then rechecks data before atomic Helm deployment. It verifies migration, full business/content aggregates, actual owner/outsider views and public/static postflight before refreshing the root-owned snapshot helper's image pin. Existing PVC, resources, configuration and secret references are preserved. No account/grant, sender, DNS/apex, timer or production-data restore is included.

The fresh sealed read-only preflight passes at 2026-10-31T00:16:13Z: node requests 68% CPU/76% memory, current spec/Helm and data match, server/client/Helm dry-runs pass. Execution repeats those checks and refuses further data drift. Source gate: make check 396 passed, zero skips; release safety gate: 10 passed. The safety gate had one pytest cache-permission warning, with no failed cases.

The backup normally pauses the app for about a minute; the image upgrade then uses the existing five-minute atomic wait/rollback. Automatic rollback restores the prior image, preserving subsequent writes; the added uniqueness constraint can remain. Its SQL inverse and old-image compatibility are rehearsed. A failed or uncertain attempt needs journal inspection rather than blind replay.

Founder execution (completed; do not replay)

From the existing remote SSH prompt, run exit to return to your workstation. Then run:

python3 /tmp/csoc-storage-release-owner-20261031/tools/coulomb-storage-release.py \
  --execute \
  --expect-digest sha256:5fd7ccd8f68057346367d81efb82b48280a16dd31d87683a5bd83e60e3d1837e \
  --output /tmp/csoc-storage-release-result-20261031.json

At the confirmation prompt enter:

DEPLOY sha256:5fd7ccd8f68057346367d81efb82b48280a16dd31d87683a5bd83e60e3d1837e

Keep the terminal open, then return the final JSON result. The agent must inspect the durable node receipt and postflight before accepting the release. Its journal is /var/lib/coulomb-social-backup/releases/5fd7ccd8f68057346367d81efb82b48280a16dd31d87683a5bd83e60e3d1837e/receipt.json.

The founder-run step follows the deployment supervision rule documented in the October 29 packet: “Every live change needs the founder's go-ahead” and “The agent cannot approve itself.” Execution acceptance follows the actual attended release and independently verified native receipt. Earlier backup/custody/schedule admissions remain valid. Recurring activation, retention/capacity, historical-copy disposition, service evidence and productive user verdicts remain their existing workplan tasks.