# Session 0072.0 — Transcript > App: ohm > Start: 2026-06-05T02-34 (PST) > End: 2026-06-05T07-05 (PST) > Type: spec > Status: **FINALIZED.** > Branch: `spec/three-tier-projects-collections` → PR #18 (open, unmerged). ## Launch prompt > Let's re-examine the roadmap for the RFC app. We need to refactor the > relationship between projects and RFC collections. A project should be able to > have any number of RFC collections, and each RFC collection is of the type > document or BDD, etc. Exists at the global level like they do now, plus at the > project level, plus at the RFC collection level. At the global level, are just > about managing projects and the global settings. The project level is just > about managing RFC collections and the project settings. The RFC collection > level is closer to what we originally managed for all of OHM. Users can be > invited to an RFC collection role at the project scope (in which case they > have that role for all RFC collections in the project), or to specific rfc > collections. There is no option to grant someone a role to RFC collections at > the project level and revoke it at a child RFC collection level (too complex). > Anyone at the project level with permission to create an RFC collection can do > so, and specify the type and subfolder. After we have this model in place (we > don't need to get all permissions right yet - just have Owner at all levels, > and RFC Contributor at the global, project, and RFC collection level). Follow-ups during the session: "Generate the BDDs for the scenarios where these roles are used, how users are invited, and empty-state experiences; add to the spec" · "continue" · "different words for the same things maybe?" (roles reconciliation) · "ideally each session ends with a usable thing, or roadmap slices marked with which BDD scenarios are complete after a slice" · "Finalize now, including /wgl-session-finalize." ## Plan Spec session — re-examine the §22 multi-project roadmap and develop a spec for a **three-level model**: global (deployment) → project → RFC collection (the typed corpus). Reconcile roles to `{owner, contributor}` × three scopes. Re-slot the in-flight §22 work. Develop the spec locally; finalize submits/PRs. ## Pre-state - §22 multi-project was believed (per memory) to be mid-build: M3-backend Plan A merged (v0.33.0), Plan B + M3-frontend "not shipped / deferred." **This was stale** — see the arc. - Clean, pushed `main` @ v0.39.0. No spec-RFC content repo configured for `ohm`. ## The arc (turn-by-turn) 1. **Session gate / init.** Classified as a **spec** session (operator invoked `/wgl-session-spec-init`). Claimed ID **0072** (`--type spec`); no concurrent sessions. Clean `main` baseline. No BDD corpus configured for `ohm`, so the discovery input is the launch prompt + the existing §22 draft. 2. **Orientation.** Read the current §22 draft (`docs/design/multi-project-spec.md`): a two-tier model where a "project" IS a typed corpus. Recognized the operator's refactor as **inserting a middle tier**: project becomes a grouping; the corpus becomes an "RFC collection." 3. **Brainstorming (superpowers).** Settled the forks via AskUserQuestion: - Storage: **project owns one content repo; collections = typed subfolders.** - Collection config: **git-truth via `.collection.yaml` manifests**; in-app create wraps a bot commit. - Project creation: **in-app create wrapping a registry commit** (symmetric). - Roadmap strategy (FIRST pass, on a STALE premise): "fold into not-yet- shipped Plan B + M3-frontend." 4. **Design presented + approved** (structure, then roles). Reconciled the accumulated role vocabulary (`owner`/`admin`/`project_*`) onto **one `{owner, contributor}` enum × {global, project, collection}** — "different words for the same things." 5. **Spec written** — `docs/design/2026-06-05-three-tier-projects-collections.md` (Parts A–E) with 23 **BDD/Gherkin scenarios** (Part C) for role usage, invitation, empty states. Self-review fixed 3 internal inconsistencies. 6. **CORRECTION (the pivot).** Writing the impl plan, re-checked the code and found the memory was stale by ~6 minors: **the entire two-tier model is SHIPPED @ v0.39.0** — migration 028 (slug PK `(project_id, slug)`), v0.35.0 `/p//` routing + live URLs, v0.37/0.38 per-project read+propose. The strategy the operator had picked was built on a false premise. Stopped, neutralized the wrong claims in the spec, **fixed the stale memory at the source**, and re-presented the decision. 7. **Re-decision (correct facts).** Operator chose: **add a collection grain *beneath* today's project** — `projects` stays the group tier (keeps content_repo), new `collections` table holds per-corpus fields, entries re-key `(project_id,slug)` → `(collection_id,slug)`, `project_members` → polymorphic `memberships`. Migration 029. 8. **Usable, BDD-tagged slicing.** Per operator ("each session ends with a usable thing / mark which BDD scenarios complete after a slice"): tagged all 23 scenarios `@S`, re-cut Part E from layer-by-layer (N1–N6) into **usable increments S1–S6** with a slice→scenario index. Answered the in-session question: bundled as **S1**, the coupled migration + threading + redirect is one right-sized first session. 9. **Finalize.** Pushed the branch; opened **PR #18 (left open, unmerged)** as the review vehicle (operator deferred review); surfaced the no-spec-RFC-repo gap; updated memory; published this transcript. ## Cut state (what landed) - **Branch `spec/three-tier-projects-collections`**, 4 commits, pushed. **PR #18 open / unmerged** (https://git.wiggleverse.org/ben.stull/rfc-app/pulls/18). - `31d680b` initial three-tier spec + roles + BDDs - `9c0e3b6` correction (two-tier already shipped @ v0.39.0) - `87279fc` decided migration-029 strategy (Part E) - `2f5d09a` re-cut Part E into usable BDD-tagged slices S1–S6 - **Spec:** `docs/design/2026-06-05-three-tier-projects-collections.md` — complete and internally consistent (Parts A–E + 23 `@S`-tagged BDDs). - **Memory updated:** `project_rfc_app_multiproject.md` + `MEMORY.md` — stale "Plan B deferred" notes corrected to "two-tier shipped @ v0.39.0"; session 0072 state recorded. - **No code changed** — this is a spec session; implementation (S1) is a future coding session. ## Deferred decisions _Autonomous-mode low-confidence calls the driver made and would have liked operator input on._ - **Routing `/c/` segment** — chose `/p//c//e/` (explicit `c/` to avoid collision with reserved project-level segments) rather than `/p///…`. Storage shape confirmed; exact URL grammar not explicitly asked. - **Default-collection / single-X redirects** — added `/p//` → sole collection and `/` → sole project conveniences for the N=1 case. Inferred from the existing M3-frontend N=1 behavior. - **`project_viewer` collapse** — mapped M2's `project_viewer` to a read grant folded into visibility (not a membership role) for this pass, per the operator's `{owner, contributor}`-only scope. Reversible. - **create-collection needs project-scope** — a collection-scope grant cannot create sibling collections (creation is a project-level act). Followed from "anyone at the project level." - **Disposition: PR left open, not merged** — operator deferred review to another session, so the draft spec was pushed + PR'd but NOT auto-merged (vs. the autonomous default of merging), to preserve their review. ## Next-session prompt ``` /goal Write + execute the S1 plan for the §22 three-tier refactor: migration 029 (add `collections` table, move per-corpus fields down from `projects`, one default collection per project, re-key entry-scoped tables (project_id,slug)→(collection_id, slug) via the 028 rebuild pattern, project_members→memberships) + thread collection_id through app/auth.py·projects.py·cache.py·api_* + 308 /p//e/→ /p//c//e/. Acceptance: @S1 scenarios green; N=1 unchanged. Read docs/design/2026-06-05-three-tier-projects-collections.md (Part E / §A.6) and memory project_rfc_app_multiproject.md first. PR #18 carries the spec (review/merge it first if approved). VERIFY shipped state from CHANGELOG+migrations, not memory. ```