auth-method-matrix: `change-email` and `delete-user` are booked as mounted in `auth-route-ledger.ts` but plugin-auth never configures better-auth's `user.changeEmail` / `user.deleteUser` — no switch to enable them

[huangyiirene]

Symptom

Two core-auth routes are advertised as mounted but are dead:

• POST /api/v1/auth/change-email answers 400 CHANGE_EMAIL_DISABLED.
• POST /api/v1/auth/delete-user answers 404.

Both are booked in the route ledger (packages/plugins/plugin-auth/src/auth-route-ledger.ts): line 118 { route: 'POST /api/v1/auth/change-email', … client: 'auth.changeEmail' } and line 120 { route: 'POST /api/v1/auth/delete-user', … client: 'auth.deleteUser' } — yet neither can be enabled through any product switch.

Root cause

plugin-auth never configures better-auth's user.changeEmail / user.deleteUser options. On origin/main, changeEmail/deleteUser appear only inside auth-route-ledger.ts (the two ledger rows at 118/120, plus the disabled-route list at 247/249 and a /delete-user/callback entry at 196) — zero configuration hits anywhere else in plugin-auth/src (or dist). Because better-auth ships these features off by default and nothing turns them on, the routes are mounted-but-disabled with no lever to flip.

The fix is either to configure better-auth's user.changeEmail / user.deleteUser (with whatever verification/confirmation policy the platform wants) so the ledgered routes actually work, or to stop booking them as mounted until they are wired.

Reproduction

1. Boot the app; inspect auth-route-ledger.ts — both routes are booked mounted.
2. POST /api/v1/auth/change-email {newEmail} → 400 CHANGE_EMAIL_DISABLED.
3. POST /api/v1/auth/delete-user → 404.
4. Grep plugin-auth/src (and dist) for changeEmail / deleteUser → the only hits are in auth-route-ledger.ts; no better-auth user.* configuration enables them.

Source

Extracted from the QA run #7663 (framework 92f26f7, console 09987b680).

[os-help]

PM review (domain:identity seat, #6022, session session_01BVc1ekPpi6yaWywAUhfzfd): pm:queue → needs-user-decision. The card's own two options are a product fork, and the "build it" branch cannot be dispatched without a policy this seat is not entitled to invent.

(A) Wire the two capabilities. Configure better-auth's user.changeEmail / user.deleteUser so the ledgered routes work. This is not a switch-flip: each needs a policy decision that becomes platform-visible contract.

• change-email: does the confirmation email go to the OLD address, the NEW one, or both? Is the change reversible within a window? What happens to sessions on the old identity, and to sys_member/audit attribution keyed on it?
• delete-user: this is self-service account deletion. Its blast radius is the same referential thicket admin-lifecycle: remove-user is non-atomic and can never succeed — 409 leaks as a bodyless HTTP 500, credential rows deleted without rollback #7724 is filed for (sys_member.user_id is a required FK with no cascade, so a self-delete hits the same restrict the admin path does), plus the retention/GDPR question of whether "delete" means erase or tombstone. Shipping self-service delete on top of an admin delete that provably cannot succeed today would be building the second floor first.

(B) De-book them. Remove the two rows from auth-route-ledger.ts (and reconcile the disabled-route list and the /delete-user/callback entry), so the ledger stops advertising routes that answer 400 CHANGE_EMAIL_DISABLED / 404. Cheap, honest, and reversible; the cost is that the platform visibly does not offer change-email.

Seat recommendation: (B) now, and split (A) into its own scoped card(s) if the capabilities are wanted for v17. Reasons: the ledger's job is to state what is mounted, and it is currently wrong — that is the defect actually filed, and (B) fixes it in a day. (A) is feature work whose delete-user half is blocked behind #7724's cascade/rollback fix regardless of what is decided here. Note this card is not target:v17-labelled and does not look like one of the four blocking classes: the routes have never worked, so nothing regresses by shipping v17 without them.

Deciding questions for the maintainer: do change-email and self-service delete-user ship as platform capabilities (and under what confirmation/retention policy), or does the ledger get corrected to match reality? Once ruled, the execution card(s) queue in this lane.

---

Generated by Claude Code

[huangyiirene]

Maintainer ruling — 2026-08-12

裁定:changeEmail 配置开启,delete-user 摘掉 mounted 记账。

要点:

• user.changeEmail 在 plugin-auth 配置开启,带验证流程(变更需确认,策略按 better-auth 常规);改邮箱是账号面的 table stakes,ledger 已把它记为 mounted,补上配置让记账为真。
• delete-user 从 ledger 摘掉 mounted 记账(记为 disabled/未接线,诚实状态)。⛔ 不配置 user.deleteUser:B2B 多租户下自助删号牵连记录归属与租户数据,而 admin 侧 remove-user(admin-lifecycle: remove-user is non-atomic and can never succeed — 409 leaks as a bodyless HTTP 500, credential rows deleted without rollback #7724)本身还是坏的(非原子、409 漏成 500)——先修那个;自助删号需要一次 deliberate 设计,不由一张 QA 卡带出来。
• 顺序依赖记录:若 admin-lifecycle: remove-user is non-atomic and can never succeed — 409 leaks as a bodyless HTTP 500, credential rows deleted without rollback #7724 的修复改变了删除语义,自助删号的将来设计以那个为基础。

裁定人:维护者 huangyiirene(2026-08-12,接受 PM 综合分析后批准);由 PM 会话 session_01GZKbx4xyF7U5WXj6ch49BM 代笔落卡。转 pm:queue。

---

Generated by Claude Code