refactor(bitrix24): rename "Path B" framing to maintainer-specified naming [B24:2794]

Per maintainer hard rule #10 (no generic "Path A/B" framing) from PR #1061
review. The Bitrix24 MCP auto-onboard flow is Bitrix-specific glue
("Bitrix24 OAuth -> existing mcp_user_credentials bridge"), NOT a generic
MCP architecture pattern.

Naming convention applied consistently:
- First mention per file: full "Bitrix24 OAuth -> existing
  mcp_user_credentials bridge" (matches maintainer comment verbatim).
- Subsequent mentions in same file: shortened "mcp_user_credentials bridge".
- Test/log context referencing literal endpoint /api/auto-onboard: keep
  "auto-onboard" reference (it's the actual API endpoint name).

Changes are documentation-only:
- Rename in code comments + test descriptions + plan docs.
- Clarify framing in mcp_client.go + provisioner.go doc comments to
  emphasize Bitrix-specific glue (not generic MCP infra).
- Reuse existing mcp_user_credentials table + MCPServerStore methods
  (no schema / store / abstraction change).

Files:
- cmd/gateway.go (factory registration doc)
- internal/channels/bitrix24/{channel,factory,mcp_client,provisioner}.go
- internal/channels/bitrix24/{mcp_client,provisioner}_test.go
- plan/goclaw-mcp-integration.md (21 occurrences)

Verified: go build + MCP-related tests pass (TestProvision*,
TestInitMCPProvisioner*, TestMCPClient*).

Phase 1 of Path C execution per
plans/reports/decision-log-260519-1555-bitrix24-pr-fork-decision.md.

Author: DangTinh311

cmd/gateway.go

@@ -481,8 +481,10 @@ func runGateway() {
 		// lazy per-user credential provisioning (via mcp_server_name +
 		// mcp_base_url in their instance config) can reach the partner's
 		// MCPServerStore. The MCP server authenticates each onboard call
-		// via the caller-supplied Bitrix access_token (Path B) — no shared
-		// admin secret is required. Channels with none of those set operate
+		// via the caller-supplied Bitrix access_token (the "Bitrix24
+		// OAuth → existing mcp_user_credentials bridge" — Bitrix-specific
+		// glue, not a generic MCP architecture pattern) — no shared admin
+		// secret is required. Channels with none of those set operate
 		// identically to before — the MCPStore arg is nil-safe inside the
 		// factory.
 		instanceLoader.RegisterFactory(channels.TypeBitrix24, bitrix24.FactoryWithPortalStoreAndMCP(pgStores.BitrixPortals, pgStores.MCP, bitrixEncKey))

internal/channels/bitrix24/channel.go

@@ -61,9 +61,10 @@ type Channel struct {
 	//
 	// mcpStore comes from the MCP-aware factory variant; mcpClient is
 	// built at Start() iff config has mcp_server_name + mcp_base_url and
-	// the named mcp_servers row exists. Path B: the MCP server
-	// authenticates each onboard call via the caller-supplied Bitrix
-	// access_token — no shared admin secret is required. mcpServerID is
+	// the named mcp_servers row exists. Bitrix24 OAuth → existing
+	// mcp_user_credentials bridge: the MCP server authenticates each
+	// onboard call via the caller-supplied Bitrix access_token — no
+	// shared admin secret is required. mcpServerID is
 	// resolved once at Start() via mcpStore.GetServerByName and then
 	// cached — avoids looking up the server on every inbound message.
 	mcpStore     store.MCPServerStore

internal/channels/bitrix24/factory.go

@@ -94,9 +94,11 @@ type bitrixInstanceConfig struct {
 	//   2. Channel looks up MCPUserCredentials(serverID, senderID). Present
 	//      → skip. Absent → POST /api/auto-onboard on MCPBaseURL forwarding
 	//      U's OAuth tokens. MCP server authenticates the call via Bitrix
-	//      `profile` against the supplied access_token (Path B — no shared
-	//      admin secret required) and responds with a per-user api_key,
-	//      which channel stores via SetUserCredentials.
+	//      `profile` against the supplied access_token — no shared admin
+	//      secret required — and responds with a per-user api_key, which
+	//      channel stores via SetUserCredentials (the "Bitrix24 OAuth →
+	//      existing mcp_user_credentials bridge" — Bitrix-specific glue,
+	//      not a generic MCP architecture pattern).
 	//   3. Agent pipeline downstream reads those creds naturally.
 	//
 	// Best-effort: if any step fails, channel logs a warning and forwards
@@ -146,8 +148,10 @@ func FactoryWithPortalStore(portalStore store.BitrixPortalStore, encKey string)
 // provisioning: on first message from each user, it POSTs to
 // {mcp_base_url}/api/auto-onboard to mint per-user MCP credentials,
 // which downstream agent pipeline reads naturally. The MCP server
-// authenticates each call via the caller-supplied Bitrix access_token
-// (Path B) — no shared admin secret is required.
+// authenticates each call via the caller-supplied Bitrix access_token —
+// no shared admin secret is required (Bitrix24 OAuth → existing
+// mcp_user_credentials bridge; Bitrix-specific glue, not a generic
+// MCP architecture pattern).
 //
 // Pass nil mcpStore to disable provisioning even if config has the fields.
 // Half-config (only one of mcp_server_name / mcp_base_url set) fails fast.

internal/channels/bitrix24/mcp_client.go

@@ -14,16 +14,23 @@ import (
 
 // mcpClient talks to an MCP server's /api/auto-onboard endpoint.
 //
+// This is Bitrix-specific glue ("Bitrix24 OAuth → existing
+// mcp_user_credentials bridge"), NOT a generic MCP architecture pattern —
+// other channels (Telegram, Discord, …) currently require admins to set
+// per-user MCP credentials manually via the HTTP admin API. Bitrix
+// automates the same flow because Bitrix events naturally carry user
+// OAuth tokens.
+//
 // When a Bitrix24 user sends their first message, the bitrix24 channel
 // doesn't yet know which per-user MCP API key that user should use. It POSTs
 // to the MCP server — which is the authoritative identity provider for this
 // integration — with the triggering user's OAuth tokens (access_token +
 // refresh_token + expires_in) harvested from the Bitrix event auth block.
 // The MCP server verifies the access_token against Bitrix `profile` to
-// confirm the caller actually owns bitrix_user_id (Path B — no shared admin
-// secret required), then upserts its own tenants + bitrix_users tables keyed
-// by (domain, bitrix_user_id) and returns the per-user api_key we persist
-// via mcp_user_credentials.
+// confirm the caller actually owns bitrix_user_id — no shared admin secret
+// required — then upserts its own tenants + bitrix_users tables keyed by
+// (domain, bitrix_user_id) and returns the per-user api_key we persist via
+// mcp_user_credentials.
 //
 // The client is deliberately thin:
 //   - No retries on 4xx (auth config wrong → operator must fix).
@@ -48,7 +55,7 @@ var ErrTenantNotInstalled = errors.New("mcp auto-onboard: tenant_not_installed")
 
 // newMCPClient builds a client pointed at baseURL. The MCP server
 // authenticates each auto-onboard call via the caller-supplied Bitrix
-// access_token (Path B) — no shared admin secret is required.
+// access_token — no shared admin secret is required.
 // baseURL MUST be the MCP server root (e.g. https://mcp.example.com) — we
 // append /api/auto-onboard internally so channel config stays minimal.
 func newMCPClient(baseURL string, timeout time.Duration) *mcpClient {

internal/channels/bitrix24/mcp_client_test.go

@@ -51,10 +51,10 @@ func TestMCPClient_AutoOnboard_Success(t *testing.T) {
 	if gotPath != "/api/auto-onboard" {
 		t.Fatalf("wrong path: %q", gotPath)
 	}
-	// Path B: no Authorization header — MCP server authenticates via the
-	// caller-supplied Bitrix access_token in the body, not a bearer token.
+	// Auto-onboard contract: no Authorization header — MCP server authenticates
+	// via the caller-supplied Bitrix access_token in the body, not a bearer token.
 	if gotAuth != "" {
-		t.Fatalf("expected no Authorization header under Path B, got: %q", gotAuth)
+		t.Fatalf("expected no Authorization header for auto-onboard, got: %q", gotAuth)
 	}
 	if gotCT != "application/json" {
 		t.Fatalf("wrong content-type: %q", gotCT)

internal/channels/bitrix24/provisioner.go

@@ -72,12 +72,13 @@ var (
 //  2. Instance config has both mcp_server_name and mcp_base_url set.
 //  3. The mcp_servers row exists (looked up by name).
 //
-// Path B authentication (see mcp_client.go doc): the MCP server
-// authenticates each /api/auto-onboard call via the caller-supplied Bitrix
-// access_token by calling Bitrix `profile` and matching the token-owner
-// ID against bitrix_user_id — no shared admin secret is required, so
-// multi-tenant isolation holds naturally (each portal's users authenticate
-// with their own per-portal OAuth tokens).
+// Bitrix24 OAuth → existing mcp_user_credentials bridge (Bitrix-specific
+// glue — see mcp_client.go doc): the MCP server authenticates each
+// /api/auto-onboard call via the caller-supplied Bitrix access_token by
+// calling Bitrix `profile` and matching the token-owner ID against
+// bitrix_user_id — no shared admin secret is required, so multi-tenant
+// isolation holds naturally (each portal's users authenticate with their
+// own per-portal OAuth tokens).
 //
 // Any single missing piece leaves the channel usable but with
 // provisioning off — that's the operator's "staged rollout" path: install

internal/channels/bitrix24/provisioner_test.go

@@ -558,7 +558,7 @@ func TestProvisionIfMissing_MissingAuthBlock(t *testing.T) {
 // Each case should leave mcpClient nil + mcpServerID zero, so
 // provisionIfMissing returns ErrProvisionDisabled.
 //
-// Path B auth note: there is no longer an admin-token branch to test —
+// Auto-onboard auth note: there is no longer an admin-token branch to test —
 // the MCP server authenticates each /api/auto-onboard call via the
 // caller-supplied Bitrix access_token, not a shared bearer.
 func TestInitMCPProvisioner_DisabledModes(t *testing.T) {

plan/goclaw-mcp-integration.md

@@ -2,10 +2,10 @@
 
 > Kế hoạch tích hợp MCP `mcp-bx-syn` với GoClaw chatbot để enforce per-user ACL khi user chat với bot Bitrix24.
 >
-> **Status**: ✅ Both sides implemented. Path B (access_token as auth anchor) shipped end-to-end. Remaining work is operational (backfill, marketplace rollout, Phase E shared-credential support for Open Channel).
+> **Status**: ✅ Both sides implemented. "Bitrix24 OAuth → existing `mcp_user_credentials` bridge" (auto-onboard via access_token as auth anchor — Bitrix-specific glue, not a generic MCP architecture pattern) shipped end-to-end. Remaining work is operational (backfill, marketplace rollout, Phase E shared-credential support for Open Channel).
 >
 > **Owner**: dangt
-> **Last updated**: 2026-04-23 (rev5: Path B shipped — ADMIN_TOKEN removed, mapping table dropped, notify + rate limit + audit log added)
+> **Last updated**: 2026-04-23 (rev5: mcp_user_credentials bridge shipped — ADMIN_TOKEN removed, mapping table dropped, notify + rate limit + audit log added)
 
 ---
 
@@ -14,7 +14,7 @@
 **Mục tiêu**: Mỗi user trong Bitrix chat với bot GoClaw → MCP `mcp-bx-syn` gọi Bitrix REST với token của **chính user đó** (enforce ACL tự nhiên). Triển khai an toàn ở quy mô marketplace: mỗi portal cài app độc lập, không có shared secret giữa MCP và GoClaw.
 
 **Phạm vi (đã triển khai)**:
-- Endpoint `POST /api/auto-onboard` trên MCP (Path B — xác thực bằng Bitrix `access_token` thay vì `ADMIN_TOKEN`)
+- Endpoint `POST /api/auto-onboard` trên MCP (mcp_user_credentials bridge — xác thực bằng Bitrix `access_token` thay vì `ADMIN_TOKEN`)
 - Lazy provisioning hook trong custom Bitrix24 channel của GoClaw
 - Persist per-user OAuth tokens vào MCPUserCredentials để MCP proxy gọi REST API theo user
 - Rate limit + audit log trên endpoint
@@ -35,7 +35,7 @@
 
 ## 2. Quyết định đã chốt (Rev5)
 
-- ✅ **Path B**: MCP xác thực mỗi call `/api/auto-onboard` bằng cách gọi Bitrix `profile` với `access_token` do caller supply, so khớp `profile.ID` với `bitrix_user_id`. Không cần `ADMIN_TOKEN` shared giữa GoClaw và MCP.
+- ✅ **mcp_user_credentials bridge**: MCP xác thực mỗi call `/api/auto-onboard` bằng cách gọi Bitrix `profile` với `access_token` do caller supply, so khớp `profile.ID` với `bitrix_user_id`. Không cần `ADMIN_TOKEN` shared giữa GoClaw và MCP.
   - Đổi so với Rev4 (dùng `ADMIN_TOKEN` Bearer) vì không scale cho marketplace: mỗi portal chạy GoClaw riêng không thể share 1 secret với MCP worker.
 - ✅ **Reject 404 `tenant_not_installed`** nếu portal chưa cài MCP app.
 - ✅ **Idempotent theo `(tenant.domain, bitrix_user_id)`** — lần 2 refresh tokens, trả cùng USR_.
@@ -115,23 +115,23 @@ Agent gọi MCP tool → Manager.resolveServerCredentials() inject
 | MCP `profile` (không `user.get`) vì không yêu cầu `user` scope | ✅ | `src/auth/bitrix-user-verify.ts` |
 | `ensureFreshToken` re-verify hourly + dismiss khi fail | ✅ | `src/auth/token-manager.ts` |
 | GoClaw KHÔNG còn phụ thuộc ADMIN_TOKEN | ✅ | commit `07b48ef0` (goclaw-deploy/dev) |
-| GoClaw channel đã wire Path B từ commit phase C | ✅ | commit `ea09c1ba` (goclaw-deploy/dev) |
+| GoClaw channel đã wire mcp_user_credentials bridge từ commit phase C | ✅ | commit `ea09c1ba` (goclaw-deploy/dev) |
 
 ---
 
 ## 4. Data model
 
 ### 4.1 MCP side — schema (không migration mới)
 
-Schema gốc đã đủ. Các bảng Path B dùng:
+Schema gốc đã đủ. Các bảng mcp_user_credentials bridge dùng:
 
 | Bảng | Cột liên quan | Dùng cho |
 |---|---|---|
 | `tenants` | `domain UNIQUE` | `findTenantByDomain` — 404 gate |
 | `users` | `tenant_id`, `bitrix_user_id TEXT`, `UNIQUE(tenant_id, bitrix_user_id)`, `access_token`, `refresh_token`, `token_expires_at`, `token_version` | Upsert theo (tenant, bitrix_user_id); lưu OAuth tokens để proxy Bitrix REST |
-| `users` (Phase 04 columns, reuse) | `user_status` (`active`/`dismissed`), `last_verified_at` (unix seconds) | Đã có từ Phase 04; Path B reuse cho `ensureFreshToken` re-verify + dismiss flow |
+| `users` (Phase 04 columns, reuse) | `user_status` (`active`/`dismissed`), `last_verified_at` (unix seconds) | Đã có từ Phase 04; mcp_user_credentials bridge reuse cho `ensureFreshToken` re-verify + dismiss flow |
 | `api_keys` | `user_id`, `key`, `label`, `active` | Mint USR_ label `"goclaw-bot"`; `deactivateUserApiKeys` set `active=0` khi dismiss |
-| `auto_onboard_audit` (mới — Path B) | `id`, `domain`, `bitrix_user_id`, `event`, `actor`, `metadata`, `created_at` | Audit trail cho `/api/auto-onboard` — mọi call (success + fail) ghi 1 row. Event taxonomy: `success`/`rate_limited`/`invalid_bitrix_user`/`bitrix_unreachable`/`tenant_not_installed`/`bad_request` |
+| `auto_onboard_audit` (mới — mcp_user_credentials bridge) | `id`, `domain`, `bitrix_user_id`, `event`, `actor`, `metadata`, `created_at` | Audit trail cho `/api/auto-onboard` — mọi call (success + fail) ghi 1 row. Event taxonomy: `success`/`rate_limited`/`invalid_bitrix_user`/`bitrix_unreachable`/`tenant_not_installed`/`bad_request` |
 
 ### 4.2 GoClaw side — schema (KHÔNG migration mới) ✅
 
@@ -148,7 +148,7 @@ Schema gốc đã đủ. Các bảng Path B dùng:
 
 ## 5. MCP side — `/api/auto-onboard` endpoint ✅ IMPLEMENTED
 
-### 5.1 HTTP contract (rev5 — Path B)
+### 5.1 HTTP contract (rev5 — mcp_user_credentials bridge)
 
 **Route**: `POST /api/auto-onboard`
 
@@ -223,7 +223,7 @@ Content-Type: application/json
 
 ### 5.3 Re-verify defence-in-depth (`src/auth/token-manager.ts`)
 
-Path B xác thực 1 lần lúc onboard; nhưng nếu user bị deactive trên Bitrix sau khi onboard, USR_ vẫn sống. Mitigation:
+mcp_user_credentials bridge xác thực 1 lần lúc onboard; nhưng nếu user bị deactive trên Bitrix sau khi onboard, USR_ vẫn sống. Mitigation:
 
 - `ensureFreshToken()` chạy trên **mỗi** MCP call (via `resolveApiAuth` → `OAuthAuthContext`).
 - Nếu `last_verified_at > 1h` → gọi `verifyBitrixActive` lại:
@@ -238,11 +238,11 @@ Kết quả: user bị xoá khỏi Bitrix → trong vòng 1h MCP key của họ
 
 | File | Action | Status |
 |---|---|---|
-| `src/api/auto-onboard.ts` | Rewrite — Path B (verify + rate limit + audit) | ✅ |
+| `src/api/auto-onboard.ts` | Rewrite — mcp_user_credentials bridge (verify + rate limit + audit) | ✅ |
 | `src/auth/bitrix-user-verify.ts` | Create — `verifyBitrixActive` via `profile` | ✅ |
 | `src/auth/token-manager.ts` | Modify — hook re-verify vào `ensureFreshToken` | ✅ |
 | `src/db/queries.ts` | Modify — thêm `logAutoOnboardEvent`, `updateUserVerifyStatus`, `deactivateUserApiKeys` | ✅ |
-| `src/db/schema.sql` | Modify — thêm bảng `auto_onboard_audit` (Path B audit). `users.user_status` + `last_verified_at` đã có từ Phase 04 | ✅ |
+| `src/db/schema.sql` | Modify — thêm bảng `auto_onboard_audit` (mcp_user_credentials bridge audit). `users.user_status` + `last_verified_at` đã có từ Phase 04 | ✅ |
 | `src/api/api-router.ts` | Modify — route `POST /auto-onboard` (no auth gate) | ✅ |
 | `wrangler.toml` | Modify — `RATE_LIMIT_KV` binding + drop `ADMIN_TOKEN` dependency | ✅ |
 
@@ -405,7 +405,7 @@ Không đụng health state — channel vẫn Green vì routing vẫn work.
 |---|---|---|
 | `internal/channels/bitrix24/channel.go` | Modify — add `mcpStore/mcpClient/mcpServerID/mcpProvMu/mcpDebounce/notifyMu/notifyDebounce/nameCacheMu/nameCache` fields | `ea09c1ba` (phase C) |
 | `internal/channels/bitrix24/factory.go` | Modify — `FactoryWithPortalStoreAndMCP` variant + half-config validation; `bitrixCreds` empty struct | `ea09c1ba`, `07b48ef0` |
-| `internal/channels/bitrix24/mcp_client.go` | Create — thin HTTP client; Path B no-auth | `ea09c1ba`, `07b48ef0` |
+| `internal/channels/bitrix24/mcp_client.go` | Create — thin HTTP client; mcp_user_credentials bridge no-auth | `ea09c1ba`, `07b48ef0` |
 | `internal/channels/bitrix24/provisioner.go` | Create — `provisionIfMissing` + `notifyUserOfMCPIssueOnce` + sentinel errors | `ea09c1ba`, `07b48ef0` |
 | `internal/channels/bitrix24/contact_enrich.go` | Create — lazy `user.get` cache cho display_name | `ea09c1ba` |
 | `internal/channels/bitrix24/handle.go` | Modify — call `provisionIfMissing` trước `HandleMessage` | `ea09c1ba` |
@@ -452,7 +452,7 @@ Không đụng health state — channel vẫn Green vì routing vẫn work.
 | Secret | Dùng cho | Rev5 status |
 |---|---|---|
 | `BITRIX_CLIENT_ID` / `BITRIX_CLIENT_SECRET` | OAuth dance (install + refresh) | Giữ nguyên |
-| ~~`ADMIN_TOKEN`~~ | ~~Auth `/api/auto-onboard`~~ | **Bỏ** (Path B không cần) |
+| ~~`ADMIN_TOKEN`~~ | ~~Auth `/api/auto-onboard`~~ | **Bỏ** (mcp_user_credentials bridge không cần) |
 | `ENCRYPTION_KEY` | D1 field encryption | Giữ nguyên |
 | KV binding `RATE_LIMIT_KV` | Rate limit `/api/auto-onboard` | **Mới** |
 
@@ -470,7 +470,7 @@ Không cần env var riêng cho MCP integration. Tất cả config sống trong
 
 ## 8. Test plan
 
-### 8.1 Unit test MCP side (Path B)
+### 8.1 Unit test MCP side (mcp_user_credentials bridge)
 
 1. Body invalid JSON → 400 `bad_request` + audit row `reason:"invalid_json"`
 2. Thiếu `domain` / `bitrix_user_id` / `access_token` / `refresh_token` → 400 + audit `missing:"<field>"`
@@ -531,10 +531,10 @@ Không cần env var riêng cho MCP integration. Tất cả config sống trong
 
 ## 9. Rollout sequence
 
-### ✅ Phase A — MCP Path B shipped
+### ✅ Phase A — MCP mcp_user_credentials bridge shipped
 - [x] Schema: thêm bảng `auto_onboard_audit` (Phase 04 đã có sẵn `user_status` + `last_verified_at` — reuse, không migrate lại)
 - [x] `verifyBitrixActive` via `profile` (thay cơ chế `user.get?FILTER[ID]=…&ACTIVE=true` cũ)
-- [x] `/api/auto-onboard` rewrite Path B (bỏ Bearer ADMIN_TOKEN gate)
+- [x] `/api/auto-onboard` rewrite mcp_user_credentials bridge (bỏ Bearer ADMIN_TOKEN gate)
 - [x] Rate limit KV + audit log
 - [x] Hook `verifyBitrixActive` vào `ensureFreshToken` (re-verify hourly — cơ chế hourly đã có Phase 04, chỉ đổi backend verify)
 - [x] Deploy + smoke test (end-to-end user#62)
@@ -567,7 +567,7 @@ Không cần env var riêng cho MCP integration. Tất cả config sống trong
 
 ## 10. Security considerations
 
-### 10.1 Path B auth anchor
+### 10.1 mcp_user_credentials bridge auth anchor
 
 - **Trust boundary**: MCP tin `access_token` là thật vì Bitrix `profile` xác nhận nó thuộc user nào. Attacker muốn mint USR_ cho user X phải có access_token hợp lệ của user X — mà access_token chỉ leak được nếu Bitrix portal đã bị compromise (trong trường hợp đó attacker đã có quyền cao hơn nhiều so với USR_).
 - Không còn "master key" → không có rotate periodic; cũng không có single point of credential leak.
@@ -616,7 +616,7 @@ Không cần env var riêng cho MCP integration. Tất cả config sống trong
 
 ## 12. Changelog
 
-- **2026-04-23 (rev5)**: Path B shipped end-to-end. Bỏ ADMIN_TOKEN.
+- **2026-04-23 (rev5)**: mcp_user_credentials bridge shipped end-to-end. Bỏ ADMIN_TOKEN.
   - MCP side: `/api/auto-onboard` rewrite dùng `verifyBitrixActive(profile)` làm auth anchor thay vì Bearer ADMIN_TOKEN. Thêm rate limit KV (600/min IP + 120/min domain), audit log `auto_onboard_audit`. Hourly re-verify trong `ensureFreshToken` để revoke USR_ của user bị dismiss khỏi Bitrix.
   - GoClaw side: `mcpClient` bỏ `adminToken` field + Authorization header. `provisioner.go` bỏ `resolveMCPAdminToken` + 2 env consts (`GOCLAW_BITRIX_MCP_ADMIN_TOKEN`, `BITRIX_MCP_ADMIN_TOKEN`). `bitrixCreds` chuyển về empty struct. UI form drop `mcp_admin_token` field. (commit `07b48ef0`)
   - Bỏ bảng mapping `bitrix_mcp_user_mapping` khỏi plan — reuse partner's `mcp_user_credentials` store. Tiết kiệm ~300 LOC: interface + 2 store impls + migration + SchemaVersion bump.