Session 0071.0 — Transcript

App: ohm Start: 2026-06-04T05-24 (PST) End: 2026-06-04T06-31 (PST) Type: coding Mode: autonomous (yolo, default)

Launch prompt

/goal get to the point where the RFC app supports multiple projects and we can migrate the ecomm bdd app to natively run on the rfc and retire the planner app

Plan

Goal (operator): rfc-app supports multiple projects → migrate the ecomm BDD corpus to run natively as a project on rfc-app → retire the standalone BDD Release Planner app.

Discovery finding: this is an already-architected program — rfc-app's §22 multi-project track (rfc-app/docs/design/multi-project-spec.md, Part C 7-slice plan). M1 (spine, migration 026), M2 (project-scoped authz), M3-backend Plan A (registry mirror, /api/deployment, /api/projects/:id; META_REPO retired) already shipped (rfc-app ≤ v0.33.0). rfc-app origin/main was v0.34.0.

Goal → slices: (1) "supports multiple projects" → M3-frontend + M4; (2) "migrate ecomm BDD natively" → M5 (bdd type surface) + stand up ecomm as a bdd project (corpus = 1,238 Gherkin scenarios in wiggleverse-ecomm-meta/research/shopify; app.json already declares projectSlug: ecomm); (3) "retire planner" → after M5 + onboarding, retire wiggleverse-ecomm-bdd-release-planner-app. The slices are a dependency chain → multi-session program.

This session's target: implement + ship M3-frontend (the design-merged, now-unblocked frontier).

Pre-state

ohm-rfc: clean main, pinned rfc-app 0.31.5. No OHM session in flight (claim peeked clean). CLAUDE.md missing the org-context import stub.
rfc-app: origin/main v0.34.0; M3-frontend design merged (#10) but unimplemented; M3-backend Plan A (registry, the two runtime-config APIs) shipped v0.33.0 → M3-frontend's only dependency satisfied.

Session arc (turn-by-turn)

Init. Claimed session ID 0071 (race-free push). Verified clean main baseline. Added the @~/.claude/wiggleverse.md stub to CLAUDE.md. No memory resume pointer (first session tracking this program).
Discovery (parallel Explore agents + reads). Mapped the three pillars: rfc-app §22 state (v0.33.0, M1/M2/M3-backend done; design docs + docs/superpowers/specs/2026-06-03-m3-frontend-design.md), the planner app (FastAPI+React+SQLite multi-project Gherkin clustering/release-planning tool, deployed at rfc.wiggleverse.org), and the ecomm corpus (wiggleverse-ecomm-meta/research/shopify). Resolved a worktree version discrepancy: canonical rfc-app origin/main = v0.34.0. Frontier = M3-frontend.
M3-frontend implementation (worktree rfc-app-m3-frontend, fresh branch feat/m3-frontend-impl off origin/main):
- Backend (TDD): /api/deployment gains default_project_id (the guard contract); server-side 308s /rfc/<slug>, /rfc/<slug>/pr/<n>, /proposals/<n> → /p/<default>/… (api_deployment.make_router(config)). nginx (testing/web.nginx.conf + deploy/nginx/*.conf) routes /rfc/ and /proposals/ to the backend. 3 new tests; 438 backend pass.
- Frontend: DeploymentProvider (boot /api/deployment), ProjectLayout (+ProjectContext, per-project theme apply/reset, the §4 guard), Directory, ProjectSwitcher, NotServedPlaceholder, lib/entryPaths.js. App.jsx route table → /p/:projectId/* + /e/<slug>, DeploymentLanding (N=1 redirect / directory), header brand + switcher. VITE_APP_NAME hard cut (vite.config, index.html, 6 brand reads → runtime config). A subagent converted ~30 internal /rfc·/proposals links across 9 components to project-scoped paths. 11 Vitest tests (incl. a vitest config fix: esbuild.jsx automatic). Clean build with no VITE_APP_NAME.
Ship rfc-app v0.35.0: VERSION + package.json bump, CHANGELOG entry with RFC-2119 upgrade steps, PR #12 → merged to main, tagged v0.35.0, pushed origin + benstull mirror.
Recorded the program: ohm-rfc ROADMAP Phase G (slice status + the OHM cutover milestone) + CLAUDE.md stub committed/pushed.
Designed the next slice: authored + merged (PR #13) the M3-backend Plan B design spec (docs/superpowers/specs/2026-06-04-m3-backend-planb-design.md).
Then (after the Stop hook + "keep going") shipped rfc-app v0.36.0 — §22 M3-backend Plan B (1/2): the slug-keyed PK/UNIQUE rebuilds that activate project #2 (migration 028, 13 tables incl. composite FKs to cached_rfcs(project_id, slug)), a migration-runner -- migrate:no-foreign-keys capability (the runner couldn't toggle PRAGMA foreign_keys mid-txn — added it, with foreign_key_check after), and ON CONFLICT target updates so the app's upserts match the new composite indexes. foreign_key_check caught a 3rd FK-referencing table I'd missed (rfc_invitations); the full suite caught the ON CONFLICT coupling (81→0 failures after the fixes). 442 backend tests green; two-project same-slug coexistence proven. No behavior change. PR #14 merged, tagged, mirrored. Design §2 marked shipped. Split off per-project serving (Plan B 2/2) for migration hygiene.

Cut state

rfc-app main = v0.36.0 (origin + benstull), tags v0.35.0 + v0.36.0 pushed. Two releases shipped this session:
- v0.35.0 — M3-frontend (routing/branding/directory/308s). PR #12. 438 backend + 11 Vitest, clean build.
- v0.36.0 — M3-backend Plan B (1/2): slug-keyed PK rebuilds (migration 028)
  - runner FK-off capability + ON CONFLICT updates. PR #14. 442 backend (incl. 4 new migration tests). No behavior change.
rfc-app M3-backend Plan B design merged (PR #13), §2 marked shipped.
ohm-rfc main: ROADMAP Phase G + CLAUDE.md stub pushed. Pin unchanged at 0.31.5 (OHM not deployed on the multi-project stack — see below).
No open PRs; both repos in sync with origin.

Deferred decisions

Did NOT deploy 0.35.0 to OHM this session. OHM is pinned 0.31.5; the whole §22 stack (0.32 test-foundation, 0.33 breaking registry cutover, 0.34 containerize, 0.35 M3-frontend) is undeployed, and no OHM registry repo exists. Deploying means a breaking, multi-version live cutover requiring net-new infra (registry repo + projects.yaml + REGISTRY_REPO overlay + Gitea webhook + nginx routes) on ohm.wiggleverse.org; with META_REPO retired the app refuses to start if REGISTRY_REPO is wrong → outage risk. Judged a deliberate operator-gated milestone. Next deploy step needs operator go-ahead (ROADMAP Phase G has the runbook). rfc-app v0.35.0 itself is shipped.
ecomm-meta's "no code-sharing with rfc-app" decision (its ROADMAP) is treated as superseded by the §22 design (bdd project type) + the goal. Worth an explicit operator confirm.
M5 open Q (future): bdd scenarios free-form markdown vs parsed Given/When/Then — shapes how much planner logic moves into rfc-app.
Playwright e2e for M3-frontend deferred — Tier-1 REGISTRY_REPO unset; the dockerized backend can't boot post-0.33.0 without a seeded registry. Covered this slice by Vitest (11) + backend redirect tests. Plan B's design names the Tier-1 registry seed as its first task (unblocks both e2e gaps).

Next-session prompt

/executing-plans Execute M3-backend Plan B (2/2) per rfc-app/docs/superpowers/specs/2026-06-04-m3-backend-planb-design.md §1 + §3–§5 (§2 PK rebuilds already shipped v0.36.0). Make a 2nd project's corpus actually serve+render. First task: seed a Tier-1 registry repo + projects.yaml and set REGISTRY_REPO in testing/.env.tier1 (unblocks M3-frontend + Plan B Playwright e2e). Then: default-project-id re-stamp (§22.13 step 1, via the reconciler) + per-project RFC serving (path-scoped /api/projects/{pid}/rfcs… endpoints, per-project cache/bot/webhook dispatch over each content_repo, scoped frontend api calls, REMOVE the M3-frontend NotServedPlaceholder guard). Ship rfc-app v0.37.0. Read memory multi-project-program.md + ohm-rfc ROADMAP Phase G first. Do NOT do the OHM live cutover without operator go-ahead.

Operator plate (needs you)

Go/no-go on the OHM multi-version cutover (ROADMAP Phase G runbook) — it needs a registry repo, projects.yaml, REGISTRY_REPO overlay, a webhook, and nginx routes on the live site; it's breaking and outage-sensitive.
Confirm the direction overrides ecomm-meta's "no code-sharing" note (ecomm BDDs as a bdd project on rfc-app; retire the planner).

8.4 KiB Raw Blame History