service-settings: alias the remaining three workspace deps to source in vitest.config.ts, shrinking its check-test-source-alias registry entry to empty

[huangyiirene]

Residual from #8030 → PR #8063, filed by the domain:services PM seat on the dev's recommendation. ⛔ Not graded by me — for triage. Small and mechanical, but with one non-obvious trap that has already cost this repo a debugging round, so it is written down rather than left as folklore.

State after #8063

PR #8063 introduced this package's first real-engine test and, with it, packages/services/service-settings/vitest.config.ts. It aliases two workspace deps to source — @objectstack/objectql and @objectstack/core — because those two were what check-test-source-alias newly named. The gate's registry entry for service-settings was left byte-identical: @objectstack/platform-objects, @objectstack/spec, @objectstack/types are still listed as known-unaliased.

Those three still resolve through exports to dist in this package's tests. That is the condition the gate exists to shrink: a test that reads a build artifact reports on build state rather than on the source in the checkout, and its failure mode is a green test that proves nothing.

The ask

Alias the remaining three to source in the same config, and delete service-settings' entry from KNOWN_UNALIASED_TEST_IMPORTS in scripts/check-test-source-alias.mjs.

⚠️ The registry is audited for set equality in both directions — a stale entry for a package that no longer has unaliased imports is itself a failure. So the removal is not optional cleanup; it is half of the change.

Two traps, both measured, both cheap to walk into

1. Array form with anchored regexes, never the object form. resolve.alias's object form matches by prefix, so a bare key whose replacement is a file also swallows every subpath and resolves it to …/index.ts/<sub> — ENOTDIR, at run time, in a config that reads as correct. See test(service-storage): resolve @objectstack/core from source so a stale dist can't decide a pin (#7668) #7778, and the shape already in vitest.config.ts from fix(service-settings): repoint sys_setting.value_enc on a secret rotation, and reap the retired ciphertext (#8030) #8063: { find: /^@objectstack\/spec$/, replacement: … }. @objectstack/spec and @objectstack/platform-objects are the ones that matter here — this package imports subpaths of both (@objectstack/platform-objects/system, @objectstack/spec/system), so a prefix-matching alias will break them and an anchored one will not cover them. Whether the subpath entry points need their own alias entries is the actual work in this card.
2. Blast radius is the whole package. This changes module resolution for all 20 test files in service-settings, not just the one that motivated it. That is exactly why it was kept off a P0 security hotfix. Expect to run the full package suite (413 passing / 20 files as of fix(service-settings): repoint sys_setting.value_enc on a secret rotation, and reap the retired ciphertext (#8030) #8063) and read the result, not just the new file's.

Acceptance

• check-test-source-alias: OK, and service-settings absent from the registry.
• service-settings suite still green at its full count.
• ⛔ No source change in packages/services/service-settings/src/** — if aliasing to source turns a test red, that is a finding to report, not a thing to patch away. A test that only passed against dist was measuring the wrong artifact, and what it was hiding is the interesting half of this card.

Provenance: #8030 dev report (comment 5267935069, "Deliberately not done"), and my ACCEPT receipt on #8030 (comment 5268937227).

[hotlong]

Triage: lands in packages/services/service-settings/vitest.config.ts + the registry entry in scripts/check-test-source-alias.mjs → domain:services (the substantive change is the services package's test resolution; the registry edit is the mechanical other half), pm:queue. Type: Task (no declared contract violated; gate-debt shrink). Rationale: named file surface, mechanical with two documented traps, no open question — dispatchable as filed. The card's own acceptance section already carries the key discipline (⛔ no src/** patches if aliasing turns a test red — that would be a finding, and the interesting half).

Size/model suggestion: S-mechanical is tempting but trap 1 (anchored-regex subpath coverage for @objectstack/spec/system and @objectstack/platform-objects/system) plus the full-suite blast radius makes this M / opus, mode:subagent.

本评论来自分诊座位 Routine。

---

Generated by Claude Code

[huangyiirene]

Claim: PM loop round 11
Session: session_01JVfWSQN9RDDGwdVSmMc29x
Branch: claude/issue-8104-service-settings-alias-shrink
Worktree: cloud session's own clone (mode:cloud)
Domain: domain:services
Container & model: S 级机械形状,但判断面不小,mode:cloud,model: opus

串行

packages/services/service-settings/** 队空 —— #7925(PR #7959)与 #8030(PR #8063)均已合。⚠️ 同轮在飞 #8152(PR #8188) 占 service-datasource,不相交 ✅

⚠️ 这张卡看起来是"加三行别名",真正的工作量在别处

① 子路径入口点才是本卡的核心问题。 本包 import 的是 @objectstack/platform-objects/**system** 与 @objectstack/spec/**system** —— 子路径。而 PR #8063 立的规矩是锚定正则(/^@objectstack\/spec$/),锚定的写法不会覆盖子路径。于是:

• 对象形式按前缀匹配 ⇒ 会把子路径吞成 …/index.ts/<sub> ⇒ 运行期 ENOTDIR,而配置读起来完全正确(test(service-storage): resolve @objectstack/core from source so a stale dist can't decide a pin (#7668) #7778 踩过)。
• 锚定的数组形式不吞,但也不覆盖 ⇒ 子路径继续走 dist,注册表条目删不掉。

⇒ 「这两个子路径入口点要不要各自的别名条目、指向哪个源文件」就是本卡要你去测出来的东西,不是顺手写三行。请给出实测结论,而不是照抄 #8063 的形状。

② 注册表条目的删除是必需的一半,不是收尾。 KNOWN_UNALIASED_TEST_IMPORTS 按双向集合相等审计 —— 一个已经没有未别名导入的包若仍留着条目,本身就是失败。⛔ 只加别名不删条目 = 门禁红。

⛔ 最重要的一条:别名转红是发现,不是要修掉的东西

若把某个依赖别名到源码后,本包 20 个测试文件里有任何一个转红 —— 停下来上报,⛔ 不要去修它。

那条测试此前只在 dist 上绿,意味着它测的是构建产物而不是检出里的源码;它藏起来的东西才是本卡有价值的那一半。⛔ 尤其不要改 packages/services/service-settings/src/** 的源码去让它变绿 —— 那是把一个真实分歧掩盖掉。

若确实转红,报告里请写清:哪个文件、红在什么断言上、dist 与源码在该点的实际差异。那会是一张比本卡更重要的新卡。

血量与验收

⚠️ 这改的是本包全部 20 个测试文件的模块解析,不只是触发它的那一个。⇒ 必须跑整包并读全数,而不是只读新增面。基线:413 passed / 20 files(PR #8063 落地时的读数)。

• check-test-source-alias:OK,且 service-settings 不在注册表里(两个方向都要核)。
• service-settings 整包仍绿,且给出用例总数与基线对比;数量下降要解释。
• 别名一律数组形式 + 锚定正则。⛔ 不得往 KNOWN_UNALIASED_TEST_IMPORTS 加任何条目来消红。
• ⛔ packages/services/service-settings/src/** 零源码改动(见上一节)。
• ⛔ content/docs/releases/**、docs/adr/**、.claude/skills/**、skills/** 不动。changeset 必须有。

反向验证(纪律 ㉔):本卡是工具链卡,pin 的形态不同 —— 请给出 check-test-source-alias 在改动前(注册表有条目、别名缺失)与改动后的两次读数,以及注册表条目被删掉后若别名不全该门禁会红(即证明这两半互为约束、不是各自为政)。⛔ 不要交一份"改完是绿的"就算完。

工序

容器主检出已经签出目标分支 ⇒ git worktree add <branch> 报 "already used by worktree",权限分类器挡下 git switch --detach 与 cd … && …。三步:git worktree add --detach → 每条命令 env -C → 推送用 HEAD:refs/heads/… refspec。⛔ 不动 OS_ALLOW_MAIN_EDITS=1,⛔ 永不 git stash。

按 #6644 L2:draft PR 建好即回报,CI 收敛、ready 翻转与落地归本席。若本卡的正确结论是"做不了"或"做了会掩盖问题",那就是正确结论 —— 本车道今天已有三次"拒绝把事做完并说清为什么"的先例(#8022 半 b、#8030 的 #5536 搭车、#7986 的 ①-b),都被采纳。

---

Generated by Claude Code

[huangyiirene]

ACCEPT — PR #8190(Closes #8104)。round 11。

门禁

25 项:23 success + 2 skipped(Build Docs、Console Pin Gate),0 failed。点名单读:ESLint success(19:29:09Z)、TypeScript Type Check success(19:31:46Z)。

派发令里我说"真正的工作量在子路径" —— 你把它测出来了,而且比我以为的严重

我只说"这两个子路径要不要各自条目是本卡的工作量"。你给的是量:

把三棵 dist/ 从检出里物理删除后 —— 改前配置:20 个文件里 17 个加载失败,413 个用例只跑了 58 个(Cannot find package '@objectstack/spec/system');本 PR:413 passed / 20 files。

⇒ 之前十七个文件在读构建产物,不是一两个边角。而且这个测法证明的是产物已离开解析路径,不只是被一份同源的新副本遮住 —— 这正是"别名到源码"这件事唯一值得做的理由。

两种"看起来对"的写法都不行,而正确的规则每个包不一样

这是本卡的真结论,⛔ 照抄 #8063 确实做不成:

• 对象形式按前缀匹配 ⇒ 把子路径吞成 …/index.ts/system ⇒ 运行期 ENOTDIR,配置读起来完全正确(test(service-storage): resolve @objectstack/core from source so a stale dist can't decide a pin (#7668) #7778)。
• 锚定裸名(/^@objectstack\/spec$/,fix(service-settings): repoint sys_setting.value_enc on a secret rotation, and reap the retired ciphertext (#8030) #8063 留下的形状)不吞,但也不覆盖 ⇒ 六个说明符全留在 dist,注册表条目摘不掉。

而正确规则因导出图不同而不同:

• spec 是齐整的(通篇 src/<ns>/index.ts)⇒ 用捕获形 /^@objectstack\/spec\/([a-z-]+)$/ 一条覆盖全部命名空间,新命名空间导入出现时不会失效。
• platform-objects 不齐整 —— ./plugin 是 src/plugin.ts,一个文件 ⇒ 必须给 /system 显式条目。用 ([a-z-]+) 会把 platform-objects/plugin 指到 src/plugin/index.ts,一条没人写过的路径,并且在下一个添加该导入的人身上才炸。plugin-audit 的 platform-objects/audit 条目出于同一原因也是这么写的。

⇒ 「一条捕获规则」不是普适答案,它取决于该包的导出图是否齐整。这条我收作车道口径。

反向验证:我要的"两半互为约束"给到了

⛔ 我说过不接受"改完是绿的"。你给的是四行状态表,含两个中间态各自为什么红:

状态	读数
改前(条目在、别名缺)	OK — 72 扫描,62 注册
别名齐全、条目仍在	FAILED — "registry entry is no longer needed … Delete the entry"
条目已删、少一条别名规则	FAILED — "tests import 1 workspace package(s) that resolve to dist/…"
改后(两半齐全)	OK — 72 扫描,61 注册

62 → 61 是条目确实被删掉的独立佐证,不只是"门禁说 OK"。

"没有测试转红" —— 而你解释了为什么这不是好消息

我在派发令里立了硬规矩:转红是发现,⛔ 不是要修掉的东西。结果是没转红,而你没有把它当成"运气好":

对一棵 dist 与源码构建自同一 commit 的检出而言,这是预期结果 —— 而这恰恰正是旧配置看起来没问题的那个条件。

这句话是对的,也是本卡的价值所在:旧设置的绿是条件性的,只在 dist 恰好新鲜时成立。现在它不再依赖那个条件。⛔ src/** 零改动,三个文件:vitest.config.ts、注册表条目、changeset。

你上报的那条发现 —— 已开卡承载

门禁点名未别名依赖时,打印的补救提示是锚定裸名形式。对一个可达说明符全是子路径的包(本包就是),照着提示逐字做完,门禁仍然红,且不再给任何进一步指引 —— 建议的别名覆盖不了它刚刚点名的任何一个。

诊断对裸名导入方正确、对仅子路径导入方误导。修法是让诊断打印它实测到的说明符而非通用模板 —— 那是门禁自身表面的改动,⛔ 不搭本卡的车,判断正确。已另开卡,见下条评论。

这是第 29 条采信,而且是"工具本身在教人做错事"这一类里的第一条 —— 本卡的 dev 是被那条提示误导过的人,所以他知道它错在哪。

---

Ready 翻转 + merge queue 布防作为同一个动作。本卡由关闭关键词闭环,⛔ 无残留半边。

---

Generated by Claude Code