liveness 台账把「消费端存在读取代码」当作 live 的证据,会漏掉「没有任何生产者传值」的死键(Seed.env 即如此)

[claude]

发现于 #4704 的修复过程,与该 issue 本身无关,故按 Prime Directive #10 单独记录、不在那个 PR 里顺手改。

现象

packages/spec/liveness/seed.json 把 Seed.env 标为:

• "status": "live"
• "evidence": "packages/metadata-protocol/src/seed-loader.ts:91"
• 备注:「filterByEnv drops datasets whose env list excludes the running environment」

而在 #4704 修复之前,这句话是不成立的:第 91 行确实存在 filterByEnv(request.seeds, config.env),但全仓六处构造 SeedLoaderRequest 的调用点没有一处传 env,于是 config.env 恒为 undefined、filterByEnv 第一行直接返回全量、dataset.env 一次都没被读到。台账给的证据行是消费端,而这个键失效的原因在生产者/调用点。

(#4704 已修复接线,所以 env 现在确实是 live 的;本 issue 针对的不是那个键的状态,而是得出该状态的方法。)

为什么值得单独记

这正是 AGENTS.md Prime Directive #10 结尾那句话所警告的形态 —— 「A case label is not enforcement; check the call site」(#3106 的教训)。liveness 台账如果按「消费端是否存在读取该键的代码」来判定 live,那么任何「消费端写好了、但没有任何生产者传值」的键都会被判成 live,并且在所有 gate 全绿的情况下长期存活。Seed.env 就是被这样掩护了若干个版本。

同族佐证:packages/runtime/src/seed-loader.test.ts:327 一直有一个 should handle environment filtering 测试并且长期通过 —— 因为它显式传了 config.env: 'prod'。消费端机制一直是对的,坏的只有接线,而单测和台账都只看了消费端。

建议

1. 复核 packages/spec/liveness/ 下其它条目:凡是证据行指向「消费端读取处」而该值来自某个 optional config 的,都需要补一条「谁来填这个 config」的核对。风险最高的是带默认值的 optional 配置项 —— 它们在类型上永远「有值」,在运行时却可能永远是 undefined。
2. 考虑给台账条目增加一个「call-site evidence」字段(或在 _note 里强制要求写明生产者),让「消费端存在」与「生产者确实传值」成为两条独立证据。
3. seed.json 里 env 那条的 evidence/note 可顺手改为指向调用点(Seed.env is authorable but never enforced: the app seeding path never sets SeedLoaderConfig.env, so env: ['dev'] seeds into production too #4704 之后是 SeedLoaderService.load 内的环境解析)。

未指派 —— 仅作记录。判断第 1 条的工作量与优先级需要维护者定夺。

---

Generated by Claude Code

[os-zhuang]

存量裁决轮（维护者 2026-08-06 委托，session_01LeEfA7CFwbJb7JJmXm2KM3）：裁定入队，并按落点锚定改标 domain:engine-core → domain:spec（台账文件面在 packages/spec/liveness，spec 单一所有者）。前提经 origin/main 核实仍成立：seed.json 的 env 条目 evidence 仍指向消费端读取（seed-loader.ts:91），「消费端读取即 live」的方法论缺陷未动——台账判错会误导退役流程，restore-invariant 类。范围：复核 evidence 指向消费端的条目并补 call-site 证据纪律。分诊座位如认为锚定有误请改回。

---

Generated by Claude Code