Motivation

ADR-0001 §4 explicitly limits the Settings Hooks sync surface to dev mode:

The web UI currently supports Settings Hooks sync only. Future expansion
[...]

This is enforced in the front-end via if (STATE.uiMode === 'dev') gate
in packages/memtomem/src/memtomem/web/static/context-gateway.js:93-94.
The Settings card simply doesn't render for prod users.

The original gate was conservative: Settings Hooks (Phase D) was the
newest sync surface and we wanted local-dev exposure before prod
deployment. With Phase A/B/C (Skills, Commands, Agents) shipped to prod
and stable, the dev-only gate on Settings is now the only thing keeping
prod users from a complete Context Gateway feature set. The asymmetry
also makes the UI inconsistent: prod users see four sync surfaces but
can only act on three.

Current state

• Backend context_settings.py (read + write + diff routes) already
  prod-callable — the gate is purely UI-side.
• ADR-0001 §4 still describes Settings as the "currently supported" GUI
  surface, but the §5 phase table doesn't mark prod-readiness.
• No incident or rollback has been logged against the Settings flow
  since its introduction (verify via gh issue list --search "settings hooks").

Proposed change

1. Define stability criteria (this RFC's main contribution): what
   does "ready for prod" mean for a Context Gateway phase? Suggested
   gates:
   • No P0/P1 issues open against the surface for ≥2 weeks.
   • At least one round-trip integration test (write → diff → import-back)
     in the Python suite.
   • i18n key parity (en + ko) verified by test_i18n.py.
   • 409 conflict path covered by a test fixture.
2. Apply gates to current Settings impl — gap-list anything missing
   and ship those tests as their own PRs before the gate flip.
3. Update ADR-0001 §4 / §5 to reflect Settings prod-ready status.
4. Remove the STATE.uiMode === 'dev' gate in the same PR as the
   ADR update. Per feedback_staged_default_flip.md, consider a
   MEMTOMEM_WEB__CONTEXT_GATEWAY__SETTINGS_DEV_ONLY env override
   for one release as a kill-switch in case the prod surface
   reveals a regression.

Alternatives considered

• Skip the criteria step, just flip the gate. Rejected — without
  explicit criteria, we'd repeat this same RFC for the next phase.
  The criteria are the durable artifact; the flip is a one-line diff.
• Always-prod from day-zero (delete the gate). Rejected — the gate
  has caught at least one real-world UX issue during its dev-only
  window (see gh issue list for context-gateway label). Future
  phases benefit from the same warm-up.

Open questions

• Should the criteria live in ADR-0001 (one ADR per phase, evolving)
  or a new ADR-0009 (cross-phase release-readiness contract)?
• Does the kill-switch env var add enough value to justify the config
  surface, or should we lean on git revert if a regression appears?
• Are there test gaps in Skills/Commands/Agents that would also fail
  these criteria? If so, the criteria need to be backfilled against
  what's already in prod, not just gating Settings.

Out of scope

• mtime conflict UX (covered by RFC ci: add release workflow for PyPI publish via Trusted Publishers #9).
• Error taxonomy (covered by RFC docs: bump action count (63→64) and test count (886→891) #8).
• Folder picker / cascade / overwrite UX (covered in PR #TBD).