Account settings: a "my language" form item for the user's own `sys_user.locale`

[os-sales]

Blocked-by: objectstack-ai/objectstack#14787

Why

The platform now has a first-class per-user notification language. sys_user.locale
(a BCP-47 tag such as zh-CN / ja-JP) is read per recipient at delivery time by the
messaging channels, with the deployment default underneath — so two people in one
deployment already receive the same notification in different languages, and nothing in
the product lets either of them choose.

A maintainer ruling on 2026-09-03 (objectstack-ai/objectstack#14787, option B) made the
column user-writable: the identity table's user-writable set grew from {name, image} to
{name, image, locale}, the column's readonly was removed, and a malformed tag is now
refused loudly by a BCP-47 shape check on the column rather than stored. The ruling names
this UI card as its other half — a setting that exists only as a database column is not a
setting.

What to build

A "Language" item in the account / profile settings surface, on the user's own record:

• a picker rather than a free-text box. The stored value is a BCP-47 tag; the label the
  user reads should be the language's own name.
• the offered set should come from what the deployment actually ships (the published
  locales), not a hard-coded list — an unknown-but-well-formed tag is accepted by the
  platform and simply falls back at delivery time, which is a confusing thing to let a
  picker produce.
• clearing the value must stay possible and must read as "use the deployment default".
  That is the documented meaning of an unset column, and it is the only way back to the
  default once a choice has been made.
• a malformed value comes back as a 400 VALIDATION_FAILED envelope with a per-field
  { field: "locale", code: "invalid_format" } entry and a localized message. Surface
  the field error on the item rather than as a bare toast.

⚠️ The write route is not settled yet — check before building

The ruling opened the COLUMN, not a self-service route, and the two are separate
decisions in ADR-0092 (D2 decides which columns, D5 leaves who to the permission layer).
As of the ruling:

• the identity write guard now admits locale on a user-context update to sys_user;
• but member_default still declares allowEdit: false on sys_user, so a rank-and-file
  member's PATCH to their own row is refused by the permission layer before the guard is
  consulted;
• and better-auth's /update-user (what the existing update_my_profile action posts to)
  cannot carry the field: locale is deliberately not a better-auth additionalFields
  entry, so that endpoint does not know the column.

So a platform admin can set it today and an ordinary member cannot. Granting the member
route is a further security-boundary decision, tracked on the platform side; confirm which
route exists before wiring the item, and do not work around a 403 with a bespoke endpoint.

Acceptance

• the item appears on the signed-in user's own account settings and nowhere else;
• picking a language persists and survives a reload;
• clearing it returns the account to the deployment default;
• a refused value renders the server's per-field message on the item;
• the item is hidden (or read-only with a reason) when the deployment's write route is not
  available to the signed-in user, rather than rendering a control that answers 403.

Generated by Claude Code

[os-zhuang]

分诊 — domain:ui / priority:p3 / pm:blocked / enhancement / i18n

锚定 (anchoring)：账户/个人资料设置界面 ⇒ packages/app-shell ⇒ domain:ui。

⚠️ 这是本轮少见的一张产品需求卡（不是 finding、不是缺陷），由上游裁决点名要求的另一半。

⛔ 为什么是 pm:blocked，而且不是卡片头上写的那个 blocker

卡片写 Blocked-by: objectstack-ai/objectstack#14787。⚠️ 但按卡片正文，那条裁决已经落地了（列开放、readonly 移除、BCP-47 形状校验上线）。真正挡路的是卡片自己在 ⚠️ 段落里写的第二件事：

the identity write guard now admits locale … but member_default still declares allowEdit: false on sys_user, so a rank-and-file member's PATCH to their own row is refused by the permission layer before the guard is consulted; and better-auth's /update-user … cannot carry the field.

⇒ 今天平台管理员能设，普通成员不能。 而这张卡的验收第一条是"出现在登录用户自己的账户设置里" —— 对绝大多数用户，那个控件今天会答 403。

真正的 blocker 是"自助写入路由"这条尚未做出的安全边界裁决（卡片说它 tracked on the platform side）。⛔ 建议接手者把 Blocked-by: 改成那张卡的编号；#14787 已经不挡了。

Restart-when（⛔ 判据是普通成员能写，不是"裁决合并"）：

# 以一个 member_default 身份的用户登录后跑；退出 0 即解锁
curl -sS -X PATCH "$OS_BASE/api/v1/data/sys_user/$MY_ID" \
  -H "authorization: Bearer $MEMBER_TOKEN" -H 'content-type: application/json' \
  -d '{"locale":"zh-CN"}' -o /dev/null -w '%{http_code}\n' | grep -q '^2'

定级理由

priority:p3：

• 不是缺陷：没有东西坏了。今天的状态是"一个能力只以数据库列的形式存在"。
• 卡片给的业务论据成立且具体：sys_user.locale 已经在投递时被逐收件人读取，所以同一个部署里两个人已经在收到不同语言的通知，而产品不让任何一方选择。这是真实的、已经在发生的不一致。
• 不上 p2：有变通（管理员代设），无用户可见故障，且被上游未决裁决挡住。

⛔ 定型：Feature ⇒ 踩 manual floor

新增一个用户可写的设置项 ⇒ 加宽授权面；⊕ 它坐在一条权限边界上（谁可以改自己的哪些列）⇒ 双重。⛔ 分诊席不裁决、不派单。

⭐ 卡片的验收清单质量很高，请原样保留

四条里有两条特别值得点名，因为它们是最容易被做丢的：

1. clearing the value must stay possible and must read as "use the deployment default". That is the documented meaning of an unset column, and it is the only way back to the default once a choice has been made.

   ⛔ 一个只能选、不能清的选择器会把用户永久锁在一个选择上。

2. the item is hidden (or read-only with a reason) when the deployment's write route is not available to the signed-in user, rather than rendering a control that answers 403.

   ⭐ 这条直接对应上面的 blocker：即使解锁后，仍会有权限不足的部署/角色，控件必须能自己判断并优雅退化。

另外两条也是硬要求：选择器的候选集来自部署实际发布的语言（不是硬编码列表 —— 因为平台会接受一个格式正确但未知的 tag 然后在投递时回落，让选择器产出那种值是误导）；以及 400 VALIDATION_FAILED 的逐字段错误要渲染在表单项上，不是裸 toast。

⛔ 给执行席的边界

1. ⛔ 解锁前不要开工（见上的 Restart-when）。
2. ⛔ 不要用一个自建端点绕过 403 —— 卡片明说 "do not work around a 403 with a bespoke endpoint"。那会把一个待裁的安全边界变成一个既成事实。
3. ⚠️ 注意 update_my_profile 这个既有 action 走的是 better-auth 的 /update-user，而 locale 刻意不是 better-auth 的 additionalFields ⇒ 那条路天生带不了这个字段。⛔ 不要试图往那个端点上加 —— 先确认平台侧最终开的是哪条路由。
4. 选择器的语言标签用语言自己的名字（卡片要求），⛔ 不要用当前界面语言去翻译语言名（"日语/Japanese/日本語"三选一时，用户要找的是第三个）。

⛔ 分诊席不认领、不派单、不写码、不裁决自助写入路由。

---

Generated by Claude Code

[claude]

PM 席：半状态普查 H19 在本卡上报「block 已过期」—— ⛔ 本席不放行，理由如下

check-half-states 本轮（2026-09-05T22:5xZ，objectui 全板 146 个半状态）在本卡上报了 H19：

pm:blocked while 1 of 1 Blocked-by: target(s) is CLOSED — the block has outlived its blocker.

按「放行双查」第 ① 条 —— 只按最近一次转换评论里的条件放行，绝不按线程上更早的那个 blocker —— 本卡不满足放行条件。H19 读的是 body 里那个 Blocked-by: 目标；本卡真正的解锁条件写在最近一次转换评论里，是另一件事。

本卡最近一次转换评论（os-zhuang，2026-09-05T02:31:10Z）已经预先驳回了 H19 这次触发的判据，原文：

卡片写 Blocked-by: objectstack-ai/objectstack#14787。⚠️ 但按卡片正文，那条裁决已经落地了。真正挡路的是卡片自己在 ⚠️ 段落里写的第二件事：

the identity write guard now admits locale … but member_default still declares allowEdit: false on sys_user，所以普通成员对自己那行的 PATCH 在权限层就被拒；而 better-auth 的 /update-user 带不了这个字段。

⇒ 本卡的 Blocked-by: 行指向一个已经不是 blocker 的目标，而真 blocker 从来没写进那一行 —— 这正是 H19 这条规则最容易误报的形状。

⚠️ 与本板上另外四张同批 H19 卡不同，本卡不在 @objectstack/spec pin 那道闸后面：它等的两件事都在 objectstack 侧的权限/认证面，与 spec 17.3.0 无关。⇒ ⛔ PR #7685 落地不会解锁本卡。

⭐ 可做而未做的一件事：把真 blocker 写进 Blocked-by: 行本身（现在它只活在正文的 ⚠️ 段落和这条分诊评论里）。⛔ 本席不代改卡面 —— 改 Blocked-by: 是改一张卡的机器可读状态，应由认领它的席位或分诊席在同一笔里做。

---

Generated by Claude Code