Why

Settings → Namespaces (NS list, color, description, rules editing) is dev-mode only:

// web/static/settings-namespaces.js: loadNamespacesTab() and loadNamespaceDropdowns()
if (STATE.uiMode !== 'dev') return;

The Search NS filter dropdown is gated by the same flag (handled separately in #582 as 4.10a — that's a 1-line ungating, no model change). The deeper question is what mental model do prod users actually need for namespaces? Today the model is implicit:

• enable_auto_ns=true → folder name → NS, on the fly during indexing.
• default_namespace → fallback when no rule matches.
• NS rules in config.json → glob → NS, power-user only.

Prod users see NS chips appear in Sources after indexing but have no way to curate, rename, color-code, or pre-define them. The dev gating today implicitly says "namespaces are an implementation detail of indexing, not a user-facing primitive." Whether that's the right product position is a real decision.

This issue is an ADR placeholder. First task: draft the ADR; implementation follows.

Decisions the ADR needs to make

1. Model — auto-create only, predefine + auto-create, or predefine-only? Each has different onboarding and discoverability implications.
2. Editing scope — color/description (cosmetic, low risk) only, or also rename (which needs chunk migration)? Bulk delete? Bulk re-tag?
3. Empty state — should prod show an "empty" Namespaces panel with first-time CTA, or hide entirely until at least one NS exists?
4. NS rules editor — config-level rules editor in GUI, or stay in config.json / CLI?
5. Migration on rename — if rename is in scope, what's the ergonomic affordance? (Chunks reference NS by string; rename = bulk update.)

Tasks (gating)

• Draft docs/adr/000N-namespace-crud-prod-exposure.md, covering the five decisions above. Status = Proposed initially.
• Review pass — call out the implicit "NS = indexing detail" position vs. "NS = user-facing primitive" position.
• Promote to Accepted (or Rejected with rationale).
• Implementation PRs follow per the chosen design — could be lean prod panel (read + cosmetic edit) or full CRUD ungating.

References

All paths under packages/memtomem/src/memtomem/.

• Namespaces dev gate (frontend): web/static/settings-namespaces.js: loadNamespacesTab(), loadNamespaceDropdowns() (~59-99)
• Namespaces endpoint (no backend gating, verified for feat(web): Index tab mid-priority follow-ups (each ships as its own PR) #582): web/routes/namespaces.py: list_namespaces() (~21)
• NamespaceConfig: config.py: NamespaceConfig (~353)
• _resolve_namespace priority: indexing/engine.py: IndexEngine._resolve_namespace() (~474)
• Companion: feat(web): Namespace cluster — placeholder/echo/hot-reload/default polish (single PR) #581 (NS cluster — placeholder/echo/hot-reload, no model change), feat(web): Index tab mid-priority follow-ups (each ships as its own PR) #582 4.10a (Search dropdown ungating, decided separately)

Out of scope (until ADR Accepted)

• Implementation PRs.
• Search NS dropdown ungating (4.10a in feat(web): Index tab mid-priority follow-ups (each ships as its own PR) #582 — different decision axis, settled).
• Rename + chunk migration mechanics (depends on whether rename is in scope at all).

🤖 Generated with Claude Code