观察类发现,#5888 取证途中顺带测到,不在该 issue 的申报文件面内,故单独登记不随 PR #6031 修改。
事实(origin/main @ dd98cba)
packages/platform-objects/src/system/sys-setting.object.ts:127 给 scope 字段声明了四个选项:
{ label: 'Global', value: 'global' },
{ label: 'Tenant', value: 'tenant' },
{ label: 'User', value: 'user' },
{ label: 'Runtime', value: 'runtime' },
但另外两处只认三个:
packages/spec/src/system/settings-manifest.zod.ts:132
export const SpecifierScopeSchema = z.enum(['global', 'tenant', 'user']);SettingsService 全包对 'runtime' 零命中
(grep -rn "'runtime'" packages/services/service-settings/src/ = 0)。
get() 的 cascade 只走 env → global → tenant → user → default;
setMany() 的 scope 取自 reg.scopes.get(key),而它来自 manifest,
值域就是上面那个三元枚举 —— 没有任何代码路径能写出一行 scope='runtime'。
同一文件顶部的注释也只列了五层 resolution order,不含 runtime。
为什么按 observation-class 登记(finding,不带 pm:queue)
今天没有用户能撞到:sys_setting 的 apiMethods 只有 ['get', 'list'],
Setup 里那张栅格是 diagnostic-only,写入一律走 /api/settings/:namespace,
所以这个选项既写不进去也读不出来 —— 它是休眠的声明,不是活的缺陷。
登记而不是放过,是因为它正好是 ADR-0049「declared ≠ enforced」那一类:
一个声明出来、没有任何实现兑现的值域,后来者读 object 定义时会当成平台支持
第四层 scope。#5888 那页文档写「六层 cascade、含 runtime 层」,很可能就是
从这里(或同一个早期设想)抄下去的 —— 已在 PR #6031 中按五层改正。
两种可能的处置(交 PM 分诊,不预判)
- 选项从未落地 ⇒ 删掉
{ label: 'Runtime', value: 'runtime' },让 object 的
值域与 SpecifierScopeSchema 一致(两边本就该是同一个真相);
- 确有 runtime-scope 的产品意图 ⇒ 那它缺的是实现,应按 enforce-or-remove
单独立项,而不是继续以裸声明的形式挂在 object 上。
个人倾向 1:创业阶段聚焦原则下,一个零消费者、零写入路径的值域没有业务拉力。
观察类发现,#5888 取证途中顺带测到,不在该 issue 的申报文件面内,故单独登记不随 PR #6031 修改。
事实(origin/main @
dd98cba)packages/platform-objects/src/system/sys-setting.object.ts:127给scope字段声明了四个选项:但另外两处只认三个:
packages/spec/src/system/settings-manifest.zod.ts:132export const SpecifierScopeSchema = z.enum(['global', 'tenant', 'user']);SettingsService全包对'runtime'零命中(
grep -rn "'runtime'" packages/services/service-settings/src/= 0)。get()的 cascade 只走 env → global → tenant → user → default;setMany()的 scope 取自reg.scopes.get(key),而它来自 manifest,值域就是上面那个三元枚举 —— 没有任何代码路径能写出一行
scope='runtime'。同一文件顶部的注释也只列了五层 resolution order,不含 runtime。
为什么按 observation-class 登记(
finding,不带pm:queue)今天没有用户能撞到:
sys_setting的apiMethods只有['get', 'list'],Setup 里那张栅格是 diagnostic-only,写入一律走
/api/settings/:namespace,所以这个选项既写不进去也读不出来 —— 它是休眠的声明,不是活的缺陷。
登记而不是放过,是因为它正好是 ADR-0049「declared ≠ enforced」那一类:
一个声明出来、没有任何实现兑现的值域,后来者读 object 定义时会当成平台支持
第四层 scope。#5888 那页文档写「六层 cascade、含 runtime 层」,很可能就是
从这里(或同一个早期设想)抄下去的 —— 已在 PR #6031 中按五层改正。
两种可能的处置(交 PM 分诊,不预判)
{ label: 'Runtime', value: 'runtime' },让 object 的值域与
SpecifierScopeSchema一致(两边本就该是同一个真相);单独立项,而不是继续以裸声明的形式挂在 object 上。
个人倾向 1:创业阶段聚焦原则下,一个零消费者、零写入路径的值域没有业务拉力。