CLI 启动直读 process.env.OS_SMS_PROVIDER / OS_EMAIL_PROVIDER,完全绕过 settings 的 options 表 —— #5204 的闸门看不到这条路

[os-zhuang]

在 #5204(env 覆盖过 options 表)的实现中发现,记录下来交 triage。不在 #5204 的完成范围内——#5204 修的是 SettingsService 的 env 分支,而这条路根本不经过 SettingsService,所以那道闸门对它无效。

事实

packages/cli/src/commands/serve.ts 在装配 capability plugin 时直接读 process.env,把 provider 名字原样塞进插件构造参数:

• :2346

  const provider = (process.env.OS_SMS_PROVIDER || cfgSms.provider || 'log').toLowerCase();
  

• :3121(resolveEmailCapabilityArg)

  const provider = String(env.OS_EMAIL_PROVIDER || cfgEmail.provider || 'log').toLowerCase();
  

两处都没有拿 provider 去比对任何 options 表。sms settings 命名空间的 provider specifier 是带 options 表的 select(packages/services/service-settings/src/manifests/sms.manifest.ts:24),mail 同理(mail.manifest.ts:62),但这段代码取的是构造期的 env,发生在 settings 服务存在之前——代码注释自己写明了这一点:「constructor opts cover pre-settings boot and hosts without the settings service」。

所以 OS_SMS_PROVIDER=twilo(拼错的 twilio)在启动时不会被任何枚举拦住。#5204 关掉的是 SettingsService.get() 那扇门;这是另一扇。

为什么算一类问题

这与 #5204 是同一个形状(declared ≠ enforced:一个声明了合法值集的配置项,存在一条从 env 到消费方、不经过该值集的路径),只是发生在更早的生命周期阶段,因此不能用同一个修法。可能的方向:启动期用同一份 option 表(或 provider 注册表)校验并响亮拒绝/忽略;或者让插件在 kernel:ready 自己断言 provider 已注册。

未核实的部分(诚实标注)

我没有追下去看 SmsServicePlugin / 邮件插件拿到一个未知 provider 之后会怎样——是响亮失败、还是静默落回 log、还是拼进某个 URL。这决定了本条的严重度,但追查它属于 #5204 之外的范围扩张,所以停在这里。如果插件本身已经响亮拒绝未知 provider,那本条降为「消息质量」问题;如果它静默降级,那就是 #5204 的同级缺陷。

相关

• env 来源的 settings 值绕过 manifest 的 options 表校验 —— #5094 在写入 API 上堵住的洞，在 OS_* 覆盖这一侧原样敞开 #5204 / PR fix(service-settings): gate OS_* env overrides on the manifest's declared options table (#5204) #5711 —— 关掉 SettingsService env 分支这扇门(已修)。
• service-settings: select 型 specifier 的 options 在保存期完全不校验 —— 声明的枚举不被强制 #5131 —— 写入路径的 options 表执行(已修)。

[os-zhuang]

分诊:入队 pm:queue + domain:cli。

• 域锚定:落点 packages/cli/src/commands/serve.ts(:2346 sms 臂、:3121 resolveEmailCapabilityArg)⇒ cli 车道。
• 过时前提检查(origin/main):两处 env 直读仍在、均未对照 options 表;serve-email-capability.test.ts 只断言 env→provider 的接通性,不含合法值校验;env 来源的 settings 值绕过 manifest 的 options 表校验 —— #5094 在写入 API 上堵住的洞，在 OS_* 覆盖这一侧原样敞开 #5204/PR fix(service-settings): gate OS_* env overrides on the manifest's declared options table (#5204) #5711 修的是 SettingsService 的 env 分支,与本条构造期路径不重叠 —— 前提成立。
• 给认领方两点:① 正文「未核实」段是本单第一步 —— 先测定未知 provider 在 SmsServicePlugin / 邮件插件侧的失败方向(响亮失败 or 静默降级),它决定严重度与修法选型(启动期对表校验响亮拒绝 vs 插件在 kernel:ready 断言 provider 已注册);② options 表在 packages/services/service-settings/src/manifests/,若修法需要从 services 包导出共享表供 CLI 消费,涉跨域文件面,认领评论请申报。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[baozhoutao]

认领:PM 循环第 1 轮(cli 车道,继任会话)
会话:session_01DWUR56YsttL5sTF72Q75TQ
分支:claude/issue-5713-serve-env-provider-options
Worktree:objectstack-issue-5713
域:domain:cli
文件面:packages/cli/src/commands/serve.ts(:2346 sms 臂、:3121 resolveEmailCapabilityArg)+ 对应测试 + changeset(越界即停,报告说明)

执行注记:①按分诊指示,第一步先测定未知 provider 在 SmsServicePlugin / 邮件插件侧的失败方向(响亮失败 or 静默降级),它决定严重度与修法选型;②若修法需要改动 packages/services/service-settings(如新导出共享 options 表),那是跨域文件面 —— 停手报告,⛔ 不直改(仅 import 既有导出不算);③churn:serve.ts 近日被 #5618(turso Phase A)动过,以最新 origin/main 为准。

---

Generated by Claude Code

[baozhoutao]

认领解除(cli 车道 PM,session_01DWUR56YsttL5sTF72Q75TQ,2026-08-06 04:1xZ):03:19Z 派发的 dev 被维护者手动中止(宿主明确回报 stopped by the user、不会恢复)。零推送、无远端分支,无需回滚。摘 assignee 与 pm:dispatched,回 pm:queue。是否重派等维护者示意。认领评论中的执行注记(第一步测未知 provider 失败方向、services 包边界、churn)对下次派发仍然有效。

---

Generated by Claude Code

[baozhoutao]

恢复认领 + 重派(cli 车道 PM,session_01DWUR56YsttL5sTF72Q75TQ,2026-08-06 04:2xZ):维护者已示意「重派,继续循环」,04:1xZ 中止门解除。分支 claude/issue-5713-serve-env-provider-options、worktree、执行注记(第一步测未知 provider 失败方向、services 包边界)全部沿用 03:19Z 认领评论;基线取最新 origin/main(现 889ae47)。

---

Generated by Claude Code