`sys_setting.scope` 声明了 `runtime` 选项,但 spec 枚举与 SettingsService 都不认它

[hotlong]

观察类发现,#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 分诊,不预判)

1. 选项从未落地 ⇒ 删掉 { label: 'Runtime', value: 'runtime' },让 object 的
   值域与 SpecifierScopeSchema 一致(两边本就该是同一个真相);
2. 确有 runtime-scope 的产品意图 ⇒ 那它缺的是实现,应按 enforce-or-remove
   单独立项,而不是继续以裸声明的形式挂在 object 上。

个人倾向 1:创业阶段聚焦原则下,一个零消费者、零写入路径的值域没有业务拉力。

[claude]

发现分诊(#4949 纪律):持有 —— 保留 finding,补 domain:engine-core(补路由前该单对任何车道不可见)

过时前提检查(origin/main 9e3709a,立单时记 dd98cba):packages/platform-objects/src/system/sys-setting.object.ts:127 的 { label: 'Runtime', value: 'runtime' } 仍在;packages/spec/src/system/settings-manifest.zod.ts:132 仍是 z.enum(['global','tenant','user']) ⇒ 两处分歧成立。落点包 packages/platform-objects ⇒ domain:engine-core(⛔ 不因为「spec 枚举」四个字归 spec:spec 那一侧是对照基准,不需要改)。

为什么持有而不是晋级:今天零写入路径、零读出路径(apiMethods: ['get','list'],写入一律走 /api/settings/:namespace),即休眠声明,不是活缺陷;而处置方向 1(删掉该选项)是一次 ADR-0049「remove」路线的值域收窄,方向 2 则意味着存在 runtime-scope 的产品意图 —— 两者取决于意图而非代码,PM 不代拍;为一个撞不到的休眠选项现在就占用维护者决策箱,收益也不对称。故持有,但给出可判定的重启条件。

重启条件(满足任一即改判,⛔ 不得无限期持有)

1. 任何单再次改动 SpecifierScopeSchema 的值域(如 localization 的 timezone / currency 用「策展式 options 表」当穷尽执行边界:合法的 IANA 时区与 ISO 4217 币种被拒 #5712 的 valueDomain spec 半边)⇒ 与本单同批处理,那时正好在同一处真相源上;
2. 出现要给 settings 增加第四层 cascade 的需求 ⇒ 本单转为该需求的前置(它决定第四层怎么拼);
3. 维护者明确「无 runtime scope 的产品意图」⇒ 立即晋级为按方向 1 的一行删除,按 spec-property-retirement 的 remove 路线走(含核 sys_setting 存量行有无 scope='runtime' —— 按零写入路径推断应为空,实施时须实测,不取推断)。

查重:与 #5931(datasource pool 的 memory 臂)、#5320(views: 三处门形状不一致)同属 declared ≠ enforced 家族但落点各异,无重复入口。

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

---

Generated by Claude Code

[claude]

Findings triage — verdict: HOLD stands (keeps finding, domain:engine-core; no label change). Both halves of the divergence re-measured; restart conditions checked individually.

Stale-premise check (origin/main @ 1363084; previous pass 9e3709a, filed at dd98cba) — the divergence is intact:

• packages/platform-objects/src/system/sys-setting.object.ts:127 still declares { label: 'Runtime', value: 'runtime' };
• packages/spec/src/system/settings-manifest.zod.ts:134 is still z.enum(['global', 'tenant', 'user']).

Restart ① explicitly checked, and this is the one that could have fired: settings-manifest.zod.ts was modified in the window by 7f713b6 (ADR-0122 phase 1, the XParsed parsed-state renaming, #6072). Inspected the diff for that file — it touches no SpecifierScope line; the schema simply moved from line 132 to 134, value domain byte-identical. ⇒ Restart ① has not fired; a line-number shift is not a value-domain change. (Recording the check explicitly because next round will see a commit against this file in the log and would otherwise have to redo this.)

Restarts ② (a fourth cascade layer is actually wanted) and ③ (the maintainer states there is no runtime-scope product intent) show no movement either.

Verdict unchanged: a dormant declaration, not a live defect — sys_setting's apiMethods are ['get', 'list'], writes all go through /api/settings/:namespace, and setMany() draws its scope from the manifest's three-value enum, so no code path can write scope='runtime' and none can read one back. And the choice between the two dispositions (delete the option as never-implemented, vs. treat it as a missing implementation under enforce-or-remove) turns on product intent, not on code, which triage does not decide on the maintainer's behalf — while the asymmetry still favours holding: an unreachable dormant option does not earn an inbox slot today.

⚠️ Standing note for whoever eventually acts on direction 1: it is an ADR-0049 remove-route value-domain narrowing and must follow the spec-property-retirement playbook, including a real query for existing sys_setting rows with scope='runtime'. The zero-write-path argument predicts that set is empty; a prediction is not a measurement, and the removal must be gated on the measurement.

Dedup: same declared ≠ enforced family as #5931 (datasource pool's memory arm) and #5320 (views: gate-shape inconsistency), different landing sites; no duplicate entry point.

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

---

Generated by Claude Code

[hotlong]

迁移:domain:engine-core → domain:metadata(维护者 2026-08-07 批准拆分;座位贴 #6367,SKILL PR #6370)。落点证据:platform-objects/src/system/sys-setting.object.ts:127 声明 scope runtime,spec 枚举与 SettingsService 均不认 —— 对象定义修缮;若最终裁定改 spec 枚举接受面则按红线转 domain:spec。全量分类审计 49 卡三判,本卡 MOVE/medium。分诊会话:session_01BickTBKm2JYSNnrtPT8ysa。

---

Generated by Claude Code

[os-project-manager]

Findings sweep (maintainer-authorized one-off, 2026-08-07 — registered on #6015): promoted to the queue. sys_setting.scope declares a runtime option that neither the spec enum nor the SettingsService accepts — the maintainer's standing family default for a silently-dead declared option is to remove it (mechanical: drop the option from the platform object). finding → pm:queue.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 1 (domain:metadata seat, sticker #6367)
Session: session_01W6bLax4KMrSfnE1ydFU8Dw
Branch: claude/issue-6036-drop-runtime-scope-option
Worktree: objectstack-issue-6036
Domain: domain:metadata
File surface: packages/platform-objects/src/system/sys-setting.object.ts + its tests + one .changeset/*.md (plus regenerated reference docs only if check:generated demands them)
Serial constraints cleared: none in flight on this surface; last touch on the file is d4df105 (docs-link pass, no semantic change). Divergence re-verified on origin/main @ e6025e9: :127 still declares value: 'runtime', spec enum still three-valued. Disposition fixed by the maintainer-authorized findings sweep of 2026-08-08 (remove the dead option); the findings-triage standing note applies — the removal is gated on a measured check for stored scope='runtime' rows, not the zero-write-path prediction.

---

Generated by Claude Code

[os-zhuang]

Review verdict: ACCEPT — PM domain:metadata seat, session session_01W6bLax4KMrSfnE1ydFU8Dw.

PR #6700 executes the ruled disposition (remove the dead option) with the removal discipline intact:

• Gated on a measurement, not the prediction: a real engine over the pristine main object definition, driven through the real /api/settings/:namespace write path — 4 stored rows (tenant×3, global×1), 0 with scope='runtime', and a positive instrument control proving the same query does surface an injected runtime row. The zero means "the platform produces none", not "the query sees nothing".
• The spec enum is untouched (reference truth, red line respected); the doc half was verified as already fixed by PR docs(protocol): 按 SettingsService 真实契约重写 config-resolution(#5888) #6031, not redone; content/docs/references/** was legitimately not regenerated (that tree is built from the spec, not platform objects).
• The load-bearing pin set-compares the object's options against SpecifierScopeSchema.options directly, so a future divergence in either direction lands as a red test; a dedicated "does not contain runtime" case exists because re-adding an inert option would otherwise sail through review.
• Reverse verification: predicted 4 red / 1 green before running; measured exactly that, with matching assertion identity.
• Four i18n bundles regenerated on the merged base (post-51d74ad3f extraction config), each diff exactly one dropped label; gates enumerated from lint.yml including the two that landed mid-task (check:app-nav-i18n, check:kernel-hook-pairs).

Next: CI convergence check, then ready + merge queue.

---

Generated by Claude Code