4.4 KiB
Session 0067.0 — Transcript
App: ohm Start: 2026-06-03T20-31 (PST) Status: PLACEHOLDER — claimed at session start; finalized at session end.
This file reserves session ID 0067 for ohm. The driver replaces this body with the full transcript and renames the file to its final SESSION-0067.0-TRANSCRIPT-2026-06-03T20-31--.md form at session end.
Launch prompt
Session-init → goal proposal selected §22 M3 (next slice after M1+M2). Operator invoked brainstorming to design it.
Plan
Goal: Design (this session) the backend half of §22 slice M3 — multi-project
registry mirror + data spine + runtime-config APIs. Roadmap: ohm-rfc/ROADMAP.md
defers to framework slicing plan in rfc-app/docs/design/multi-project-spec.md Part C.
Brainstorming decisions:
- Scope split at the backend/frontend seam — this session = M3-backend; routing/branding/directory/switcher = a later M3-frontend spec.
- Build the full
initial_state/unreviewedreview plumbing now. - Config hard cut:
REGISTRY_REPOrequired,META_REPOremoved. - Re-stamp
default→ config slug by rewritingproject_ideverywhere (folded into the 12-table PK rebuild). - Registry mirror in a self-contained
app/registry.py(Option A), driven by the existing webhook +Reconciler.sweep().
Deliverable: design spec at
rfc-app/docs/superpowers/specs/2026-06-03-m3-backend-design.md (committed on
branch m3-backend-registry-spine, 6f356d3) → user review → writing-plans →
implementation.
Planning discoveries (folded into spec):
- Re-stamp must be a Python startup step — pure-SQL migrations can't read
DEFAULT_PROJECT_ID(same constraint that forced M1'sseed_default_project). - The 12-table PK rebuild has a wide blast radius (~10
ON CONFLICTsites + every RFC/branch writer needsproject_idthreading, FK-bomb post-re-stamp). Operator chose to split M3-backend into two plans: Plan A (registry mirror + APIs- initial_state/unreviewed + additive migration 027 — no rebuild/re-stamp/
threading) ships first; Plan B (PK rebuild + threading + re-stamp) lands
before M4 / before public
/p/URLs.
- initial_state/unreviewed + additive migration 027 — no rebuild/re-stamp/
threading) ships first; Plan B (PK rebuild + threading + re-stamp) lands
before M4 / before public
Deliverables (committed, branch m3-backend-registry-spine):
- Spec:
docs/superpowers/specs/2026-06-03-m3-backend-design.md(6f356d3, refined) - Plan A:
docs/superpowers/plans/2026-06-03-m3-backend-plan-a.md(dd72f91) — 9 TDD tasks, each green-on-commit.
State: Plan A IMPLEMENTED via subagent-driven development (9 tasks, each implementer → spec review → code-quality review, fixes looped until approved).
Cut state (Plan A implementation)
Branch m3-backend-registry-spine, off dd72f91 (spec+plan commits). Full suite
434 passed. Version bumped 0.32.0 → 0.33.0. Final whole-implementation
review (opus): Ready to integrate, no critical/important issues.
Task commits:
- T1 entry review fields —
597f6bc - T2 migration 027 (additive) —
2d9022b - T3 cache review mirror —
8f21dc5 - T4 registry.py module —
27a0a04(+ review fixesf7bd466) - T5 hard-cut META_REPO + wire mirror —
cecc6c0(+ fixes48fd6f9) - T6 runtime-config APIs —
c386b05(+ 404 fix07e003e, + tests/guarde8ce3cd) - T7 initial_state honoring —
fe47eef(+ resolver fixup2fe2a71) - T8 mark-reviewed + catalog filter —
76207bb(+ fixes69fd0cb,8004b2a) - T9 release 0.33.0 —
a2dc29a(+ changelog fixesf114af8)
What lands on the operator's plate
- Integrate the branch (finishing-a-development-branch): PR or merge
m3-backend-registry-spine→main. NOT yet pushed/merged as of this note. - Deploy upgrade (when shipping): create a registry repo, author
projects.yaml(id: default, content_repo = old META_REPO), set REGISTRY_REPO, remove META_REPO, add registry webhook — per CHANGELOG 0.33.0 upgrade steps.
Plan B follow-ups (deferred by design, tracked for next slice before M4)
- 12-table PK rebuild (migration 028) + project_id in every ON CONFLICT target.
- project_id writer-threading through every RFC/branch writer — concrete known instances surfaced in final review: the mark-reviewed and propose write sites currently hardcode the default content_repo (safe in Plan A's single project; wrong once project #2 exists).
- default→slug re-stamp (rides the rebuild's ON UPDATE CASCADE).
- two-project isolation tests; project archival from the registry.