Session 0055.0 — Transcript

Date: 2026-06-01 Start: 2026-06-01T03-00 (PST implied) Goal (as it emerged): not launched as an OHM driver session — opened as a conceptual Q&A comparing the OHM/flotilla self-hosted stack against a PaaS like Vercel. It became a flotilla SPEC design session: the "which Vercel wins could we adopt?" thread converged on per-PR preview environments, and the operator asked for that to be specified.

Outcome: Added a fully-fleshed §19.2 candidate — "Per-PR preview environments" — to ohm-rfc-app-flotilla/SPEC.md, committed on a branch, merged --no-ff to main, and pushed to origin. Two design decisions were settled into the entry by the operator: (1) the §10 deploy audit trail is production-only — neither per-PR previews nor PPE write to it; and (2) previews use SQLite only, the same engine as production, which is exactly what makes them cheap — no dual-engine/Postgres path. Along the way we assessed (and rejected, for now) the idea of dual SQLite+Postgres support in rfc-app.

Scope note (transcript-honest): this is pure-flotilla doc work with no OHM actuation — no deploy, no §13 record edit, no ohm-rfc operation. Per SESSION-PROTOCOL the transcript expectation softens for exactly this case; this transcript exists because the operator asked for one at session end. The ID was therefore claimed at publish time (the protocol's late-claim path), not at true session start.

Timestamp caveat: the 03-00 start is anchored to the first commit of the session (912e828 at 03:03) and the preceding Q&A; the work actually opened a few minutes earlier. A concurrent session published 0054 (03-24/03-25) while this one was already in flight — expected under advisory numbering; the claim-session-id.sh push allocated 0055 race-free.

Pre-session state

ohm-rfc-app-flotilla at main = 70ba3b0 (flotilla v1.6.0 merged), clean tree. SPEC.md at 1875 lines; §19.2 held the post-v1 candidate queue.
rfc-app checkout present at ~/projects/wiggleverse/rfc-app (HEAD a3f48ba), used read-only this session to assess the DB layer.
No preview-environment concept anywhere in flotilla; v1 has two long-lived environments only (production VM + PPE, a single serialized lane).

Arc

Arc 1 — Q&A: the OHM/flotilla stack vs. Vercel

Walked the advantages (ownership/no-lock-in, real persistent backend, flat predictable cost, secret discipline under operator control, mission-fit sovereignty, arbitrary architecture) against where Vercel wins (zero ops, push-deploy + preview envs + instant rollback, edge CDN, autoscaling, frontend DX). Bottom line: the app's shape (stateful backend, modest predictable traffic) is the opposite of Vercel's sweet spot; flagged Cloud Run as the "Vercel-like ergonomics without leaving the sovereignty model" middle path.

Arc 2 — Which Vercel wins to adopt

Ranked the adoptable ones: per-PR previews (highest value), one-command rollback (flotilla half-has it via pinning), edge CDN via the existing Cloudflare relationship (cheapest win), atomic/zero-downtime deploys. Operator zeroed in on per-PR deployments with synthetic data in a DB — PPE's single lane can't do parallel/isolated review.

Arc 3 — Draft the spec

Read SPEC §3/§5/§8/§10/§12/§13/§19.2 to match conventions, then added the "Per-PR preview environments" §19.2 candidate (placed after its cousin "Private-branch deploys"): problem statement, proposed preview up/down/ list/show verb surface, runtime options (Cloud Run recommended over VM-containers), seeded-DB model, test-secret posture (zero real secret bytes — strengthens §3 invariant 1), the invariant-5 trigger tension, and the cross-section touchpoints.

Arc 4 — Decision: audit trail is production-only

Explained the §10 deploy-history audit trail's purpose (append-only provenance: who/what/when/which-config for every prod deploy, secret-redacted; combined with git log .rfc-app-version + gcloud secrets versions list for full reconstruction) — and disambiguated it from the unrelated flotilla audit Patchwatch radar (§12.4). Operator decided: previews and PPE never write the §10 trail — production only, so deploy log stays high-signal. Recorded as settled in the entry.

Arc 5 — Dual SQLite+Postgres? Investigated, rejected for now

Operator asked how hard it'd be to support both engines. Inspected rfc-app's DB layer: raw stdlib sqlite3 (no ORM) in backend/app/db.py with a module-level singleton connection; 23 raw .sql migrations (~1,300 lines) and 28 of 43 app modules issuing raw SQL. Quantified the SQLite-isms at the query sites (datetime()/strftime in 21 files, lastrowid in 12, ON CONFLICT in 8, INSERT OR REPLACE/IGNORE in 3, case-sensitive-LIKE hazard in 3), plus the structural mismatches (strict vs. dynamic typing, placeholder style, the singleton-conn-vs-pool concurrency model). Conclusion: dual-support is medium-high effort + a permanent maintenance tax, and rfc-app §4.2 already frames Postgres as a future one-way migration, not a dual-support goal.

Arc 6 — Decision: stay SQLite; previews are cheap because of it

Operator: remove the Postgres framing entirely. Rewrote the candidate's DB paragraph — previews bake a seeded .sqlite (synthetic data) into the image and die with the container; prod and previews share one engine, which is precisely what makes per-PR previews cheap. No dual-engine/Postgres path to build or maintain; Postgres remains a hypothetical future one-way migration, never a prerequisite for previews.

Arc 7 — Ship

Confirmed the entry internally consistent. Committed 912e828 on branch spec/preview-environments-candidate, merged --no-ff (4c6781f) to main, deleted the branch, pushed 5cf5ecd..4c6781f to origin/main.

Artifacts

ohm-rfc-app-flotilla/SPEC.md §19.2 — new "Per-PR preview environments" candidate (+85 lines). Merge commit 4c6781f on main, pushed to origin.

What this session did NOT do

No OHM deploy, no §13 deployment-record edit, no ohm-rfc operation, no rfc-app release. rfc-app was read-only (DB-layer assessment).
Did not start the preview feature's build — it remains a §19.2 candidate that "earns its session" when concurrent PR review becomes PPE's bottleneck.
Did not act on the two open forks (Cloud Run vs VM-container runtime; the invariant-5 trigger question) — left for the build session by design.

Handoff

The preview-environments candidate is specced and on main. When it earns a build session, the two open decisions are runtime (Cloud Run strongly favored — also the on-ramp for a broader Cloud Run migration, gated on containerizing rfc-app) and the invariant-5 trigger (operator-typed preview up --pr=N first cut, deferring auto-on-PR to the hosted-flotilla shift). The DB and audit-trail questions are already settled (SQLite-only; production-only trail).

6.9 KiB Raw Blame History