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)

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.
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."
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."
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."
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.
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/<project>/ 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.
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.
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<n>, 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.
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 (ben.stull/rfc-app#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/<project>/c/<collection>/e/<slug> (explicit c/ to avoid collision with reserved project-level segments) rather than /p/<project>/<collection>/…. Storage shape confirmed; exact URL grammar not explicitly asked.
Default-collection / single-X redirects — added /p/<project>/ → 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/<project>/e/<slug>→
/p/<project>/c/<default>/e/<slug>. 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.

8.3 KiB Raw Blame History Unescape Escape