Context

RFC #304 proposes
nesting memory_dir categorization under a vendor/product hierarchy.
Its body lists open design questions that must be resolved before
any code change (Phase 1 server-side provider field, Phase 2 UI
tree, Phase 3 codex rename) can land.

As of #313, the category vocabulary is locked against silent
expansion (_VALID_PROVIDER_CATEGORIES + import-time assert), so
RFC #304 can stay OPEN indefinitely without contributors pre-empting
its outcome by adding a fourth regex row.

This issue is a working space for those questions. Answer each in
comments; once all have an owner-agreed answer, this issue closes and
RFC #304 is updated with the resolutions before any Phase 1 code PR
begins. The RFC body itself stays as the design document — discussion
happens here to keep it clean as a reference.

Questions to resolve

Numbered so comments can reference by Q#. Statements are verbatim
from RFC #304.

Q1. Axis: vendor vs source. Is the parent level "who made this
tool" (claude, openai, ...) or "who supplied this path"
(user-provided vs provider-provided)? If "source", user is a peer
of claude/openai. If "vendor", user has no natural vendor and
needs either a synthetic user bucket or a mixed tree/flat renderer.

Q2. Where does user live? Top-level peer of the vendor groups,
or an escape-hatch bucket common to all vendors? Peer = simpler tree,
smaller blast radius.

Q3. Wire format. Three options:

• Keep category: "claude-memory" string, add sibling
  provider: "claude" string (additive, no type change, easy client
  migration).
• Switch to path-style category: "claude/memory" (single field,
  splits client-side).
• Switch to category: {provider: "claude", product: "memory"}
  object (most type-strict, largest client diff, breaks existing
  consumers).

Q4. Collapse semantics. Does collapsing a parent hide all
children? Does each child still remember its own collapse state?
What's the default open/closed for parent vs child on first load?

Q5. Group reindex scope. "Reindex group" on the parent = reindex
all children. On a child summary = reindex just that child. Both
present simultaneously, or parent-only when children exist?

Q6. Codex migration. If we adopt a vendor hierarchy, is codex
moved to openai/codex in the same change, deferred (flat
exception), or left at its current name to keep the PR minimal?

Gemini is already marked out-of-scope in RFC #304 and is not
re-opened here.

Not in scope for this issue

• The provider field (Phase 1) code change — blocked on Q1/Q3.
• UI tree render (Phase 2) — blocked on Q2/Q4/Q5.
• Codex rename (Phase 3) — blocked on Q6.
• Re-opening Gemini — intentionally excluded per RFC RFC: nested provider/product hierarchy for memory_dir categorization #304 body.

Definition of done

• Q1–Q6 each have an owner-agreed answer in comments.
• A short summary comment lists the answers.
• RFC RFC: nested provider/product hierarchy for memory_dir categorization #304 body is updated with the resolutions (small follow-up PR
  or in-place edit).
• This issue closes, final comment links to the resolved RFC.

Related

• RFC: RFC: nested provider/product hierarchy for memory_dir categorization #304
• Vocabulary lock (prep): fix(config): lock provider category vocabulary (RFC #304 prep) #313
• Prior lineage: fix: memory_dirs editable widget with per-dir index status #295 → Promote memory_dirs management to Sources tab (follow-up to #295) #297 / feat(web): promote memory_dirs widget to Sources tab (closes #297) #300 → Consolidate memory_dir categorization: server-returned field instead of client mirror #299 / feat(web): return memory_dir category from server (closes #299) #301 / feat(cli): wizard appends matching namespace rules for accepted providers (closes #296) #312