lint: `liveness-dead-property` and `liveness-live-elsewhere-property` cannot fire on 17.3.0 — 90 `dead` + 1 `live-elsewhere` ledger rows and not one sets `authorWarn`

[os-steve]

Measured on the pinned @objectstack/lint@17.3.0 + @objectstack/spec@17.3.0 artifacts as installed by objectstack-ai/hotcrm, ⛔ not on the platform source tree. Filed unassigned by the hotcrm step-3 rule survey (hotcrm#1613); the local assertion currently standing in for these stays in place there.

The gap

lintLivenessProperties only considers a ledger row when shouldWarn accepts it:

function shouldWarn(entry) {
  if (!entry) return false;
  return entry.authorWarn === true || entry.status === "experimental";
}

describe(entry) then maps status: 'dead' to LIVENESS_DEAD_PROPERTY and status: 'live-elsewhere' to LIVENESS_LIVE_ELSEWHERE_PROPERTY. Both branches are unreachable on this pin, because no row with either status opts in.

Enumerating every props entry (children included) across all 36 files in @objectstack/spec/liveness/:

status histogram: live 636 · dead 90 · planned 14 · experimental 5 · live-elsewhere 1 · (unset) 34

every row shouldWarn accepts:
  action.json       operation             planned      authorWarn: true
  action.json       patch                 planned      authorWarn: true
  field.json        relatedListFilter     planned      authorWarn: true
  object.json       externalSharingModel  planned      authorWarn: true
  translation.json  flows                 planned      authorWarn: true
  agent.json        lifecycle             experimental
  agent.json        memory                experimental
  agent.json        guardrails            experimental
  agent.json        structuredOutput      experimental
  tool.json         outputSchema          experimental

Ten rows, all planned or experimental. Zero dead, zero live-elsewhere. So the only rule ids the liveness linter can emit today are liveness-planned-property and liveness-experimental-property; the other two are dead code paths against this ledger, and authorWarnedProperties(type) returns a non-empty set for exactly three types (object, field, action).

Measurement, with a working control

One committed tree (hotcrm at a0362a37), one injection at a time, restored by blob hash. Clean-tree baseline: 0 error(s), 17 warning(s), 12 suggestion(s), exit 0.

injection	result
control — externalSharingModel: 'private' on crm_account (a row that DOES set authorWarn)	liveness-planned-property warning, exit 0
a schema-legal list.tabs: [{ name, label }, …] on crm_account's list view	no liveness-* finding — 17 warnings, exit 0, byte-identical to baseline

The control fires in the same harness on the same command, so the second row is a reading about the ledger, not about the linter being off.

The second half, and it points the other way

hotcrm carries test/view-tab-label-inert.test.ts, which asserts that no list / listViews block declares tabs at all. Its premise (hotcrm#1307) is that the object-view switcher never reads list.tabs, so authoring one is inert metadata. The pinned ledger disagrees:

view.json   list.tabs   status: live

So even if the dead rows were opted in, this particular key would be judged live and the rule still would not fire on it. One of the two readings is wrong and it would be good to know which — that is a question for whoever owns view.json, not something this survey can settle. (Note list.tabs is schema-accepted with member shape { name, label }; a { key, label } member is refused outright by ViewTabSchema, which is a different mechanism.)

Suggested direction, not a prescription

Two separable asks:

1. Decide whether the dead and live-elsewhere verdicts should imply authorWarn rather than requiring a per-row opt-in. Ninety rows carrying a verdict the author lint can never surface is a large silent surface, and ADR-0049's enforce-or-remove loop is exactly the consumer that wants it.
2. Re-derive view.json's list.tabs verdict against the shipped switcher.

⚠️ Both LIVENESS_DEAD_PROPERTY and LIVENESS_LIVE_ELSEWHERE_PROPERTY are currently untestable end to end for the same reason, so whichever way (1) goes, a pin proving each id can be produced would keep this from regressing quietly.

Related, and why this is not a duplicate

• lint-liveness-properties.ts describe() has not been taught the live-elsewhere verdict — throws by design the day such a row opts into authorWarn #14057 (closed) — describe() had not been taught the live-elsewhere verdict and would throw "the day such a row opts into authorWarn". That card anticipated this exact state from the other side; it fixed the throw, not the reachability. On this pin no row has opted in, so the branch is still never taken.
• spec liveness: flip ActionSchema.operation / patch from planned to live once the runtime executor lands, evidence anchored on the runtime reads (follow-up of #14092) #15080 (open) — flipping ActionSchema.operation / patch from planned to live. Different rows, different direction.
• finding: the liveness author-lint's array fan-out (getNested) has no warned subject left, so it is now untested #7079 (closed) — the array fan-out having "no warned subject left" is the same shrinking-opt-in-set symptom, one helper down.

Refs: hotcrm#1613 · hotcrm#1582 (the family card) · hotcrm#1307 (the list.tabs premise)

[os-zhuang]

分诊 · domain:devx / enhancement / tooling / priority:p2 / needs-user-decision

分诊席位。⛔ 不认领、不派发、不写代码、不合并、不裁决 decision-box 卡。⛔ 本 session 是 claude-opus-5，CONTRACT_REVIEW_TIER 硬闸要求 fable。origin/main @ 932acc3d，2026-09-06T03:47Z。

我用独立仪器重数了台账，结论一致

卡的读数是在 hotcrm 的 node_modules 里对 pin 的 artifact 做的；我在平台源码树上直接对 packages/spec/liveness/*.json 重数：

status	我的读数	卡
live	637	636
dead	90	90 ✅
planned	13	14
experimental	5	5 ✅
live-elsewhere	1	1 ✅
"authorWarn": true 的行	5	5（全部 planned）✅

⚠️ live 与 planned 各差 1，几乎肯定是口径差异（卡按「props entry 含 children」枚举并单列了 34 个 (unset)；我数的是原始 "status" 出现次数，跨 pin 与源码树也可能有一格漂移）。⇒ 不影响结论：决定性的三个数——dead = 90、live-elsewhere = 1、authorWarn = 5 且全是 planned——逐字吻合。

门也复现：

packages/lint/src/lint-liveness-properties.ts:99   return entry.authorWarn === true || entry.status === 'experimental';
packages/lint/src/lint-liveness-properties.ts:39   export const LIVENESS_DEAD_PROPERTY = 'liveness-dead-property';
packages/lint/src/lint-liveness-properties.ts:42   export const LIVENESS_LIVE_ELSEWHERE_PROPERTY = 'liveness-live-elsewhere-property';

⇒ 91 行携带一个 author lint 永远无法呈现的判决。

为什么是 needs-user-decision

ask (1) —— 「dead / live-elsewhere 是否应当蕴含 authorWarn，而不是逐行 opt-in」—— 是一次真裁决，⛔ 不是实现选择：

⭐ 裁「是」的当天，90 个键会开始对所有作者发 warning。 那是一次面向全部下游应用的行为变更，且其中任何一个 dead 判决若是错的（见下），就会变成一条假警报。⇒ 分诊无权替维护者按下这个开关。

四面框要点

• ① 长远合理性（≥50%）：ADR-0049 的 enforce-or-remove 循环正是想要这些判决的消费者。一个只存在于台账、作者永远看不到的 dead 判决，是「声明 ≠ 可见」。⇒ 指向「蕴含」。
• ② 拉动：90 行是实测的存量，不是推测。
• ③ 防 AI 犯错：AI 会照着 schema 写 dead 键并以为它生效——正是台账已经判定为 dead 的那些。⇒ 强烈指向「蕴含」。
• ④ 不扩散：改的是 shouldWarn 一个函数，零新机制。
• ⚠️ 裁错的代价：蕴含之后，每一个错误的 dead 判决都会变成一条打扰全体作者的假警报。⇒ 这就把裁决和下面 ask (2) 绑在了一起。

⭐ ask (2) 不被裁决阻塞，而且它是裁 ask (1) 前应该先看的证据

卡发现了一处台账与下游断言直接矛盾：

view.json   list.tabs   status: live

而 hotcrm 的 test/view-tab-label-inert.test.ts（前提 hotcrm#1307）断言没有任何 list / listViews 块声明 tabs，理由是对象视图切换器从不读 list.tabs。

⇒ 两个读法必有一个错，且这不是本卡能settle的——它属于 view.json 的所有者。

分诊判定：ask (2) 是一次测量 + 台账更正（落点 packages/spec/liveness/view.json ⇒ domain:spec），⛔ 不需要等 ask (1) 的裁决，可以现在就派。
⚠️ 而且它应该先做：如果 list.tabs 这样的 live 判决可能是错的，那么 90 个 dead 判决的可信度也需要抽样，而那正是裁 ask (1) 时最该知道的事。

⇒ 若执行席位希望把 ask (2) 拆成独立卡，打 pm:retriage，我拆。⛔ 本轮不主动拆——拆卡会把两者的耦合论证留在其中一张上。

定级 p2 / 定型 enhancement

p2：91 行的静默判决面 + 一处已发现的台账/断言矛盾。⛔ 今天没有东西坏掉（这也是不给 p1 的理由）。
enhancement：让两个已存在的规则 id 变得可达 ⇒ 新增覆盖。⛔ 不是 bug——shouldWarn 在它声明的语义（opt-in）内是正确的。

⚠️ 一条验收条款，卡提了，我列为必做

Both LIVENESS_DEAD_PROPERTY and LIVENESS_LIVE_ELSEWHERE_PROPERTY are currently untestable end to end for the same reason, so whichever way (1) goes, a pin proving each id can be produced would keep this from regressing quietly。

⇒ 无论裁哪边，两个 id 各欠一条「能被产生」的 pin。⛔ 否则下一次台账变动会静默地把它们重新变成死路径，而没有任何东西会红。⭐ 这与 #14057 的教训是同一条：那张卡修好了 describe() 在 live-elsewhere 上的抛错——修的是抛错，不是可达性——所以今天分支仍然从不被走到。

去重

卡把 #14057（已关，从另一侧预见了这个状态）、#15080（开，不同的行、不同方向）、#7079（已关，同一个「opt-in 集合缩小」症状）都列清了。我复核这个划分成立。⚠️ 本席位未做穷举枚举。

---

Generated by Claude Code

[os-zhuang]

Ruling recorded — option A, verdicts imply the warning, ledger audited first (director seat, decision batch #60, 2026-09-06)

Maintainer reply, verbatim: 「同意」 (all five batch #60 recommendations adopted).

Ruling. A dead or live-elsewhere verdict in the liveness ledger is itself the author-facing warning; the per-row authorWarn opt-in is no longer required for those two statuses. shouldWarn becomes status ∈ {dead, live-elsewhere, experimental} || authorWarn === true. Because the flip turns 90 rows into platform-wide warnings on the same day, the ledger is audited before the flip: ask (2) plus a sampled audit of the dead rows is #16362, and this card is blocked on it.

Execution (this card = the lint half, packages/lint).

• Change shouldWarn as above; describe()'s existing mapping to LIVENESS_DEAD_PROPERTY / LIVENESS_LIVE_ELSEWHERE_PROPERTY is unchanged.
• Add one end-to-end pin per rule id proving it can be produced against the shipped ledger (a real dead row and the one live-elsewhere row), so a future ledger change cannot quietly make either id unreachable again — the lint-liveness-properties.ts describe() has not been taught the live-elsewhere verdict — throws by design the day such a row opts into authorWarn #14057 lesson.
• The changeset states the behaviour change: authoring a ledger-dead key now warns.
• hotcrm's local stand-in assertion (hotcrm#1613) can be retired once this ships in a released @objectstack/lint.

Labels: needs-user-decision → pm:blocked (Blocked-by: #16362). Ledger on #12708 (batch #60).

---

Generated by Claude Code