Skip to content

门测量的重合度 bridge 有残余假可达面:整形状由共享叶子组成的「小形状」恒为 1.0,任何阈值都排不掉 #5828

Description

@baozhoutao

观察类发现,来自 #5056 的实测。今天没有任何真实 spec 形状命中,不影响用户;记录在案,免得后面某个批次把它当成新 bug 重新发现一次。

事实

#5056 把 derived-clone bridge 从「任意单属性命中」换成整形状重合度 ≥ 0.5,WidgetManifestSchema 的假可达因此被正确排除(2/19 = 0.105)。

但重合度的分母是候选形状自己的键数。于是一个键数很少、且每个键都是仓内共享叶子的形状,重合度恒为 1.0:

z.object({
name: SnakeCaseIdentifierSchema.describe('Machine name'),
label: I18nLabelSchema.describe('Display label'),
})

实测 cloneOverlap = 1.0000,判定 derived-clone可达。而它跟任何活 schema 都没有派生关系,只是两个键碰巧都是被 .describe() 过的共享叶子(.describe() 复用接收者实例的 _zod.def,见 #5056)。

对照:同样两个共享叶子 + 3 个普通键 → 0.4000 → 正确判为不可达。所以命中条件是形状小,不是共享的绝对数量。

为什么阈值调不掉

(0, 1] 里没有哪个阈值能排除它:真·派生也会打到 1.0 —— 实测 ObjectListViewSchema.strip() 重合度就是 1.0000,且必须保持可达。两者在「重合度」这一个维度上不可分。要分开需要另一个判据(例如要求共享的属性里至少有一个是结构性节点而非叶子,或要求候选与基形状的键集双向覆盖),那是对仪器契约的改动,不该顺手塞进 #5056 的测试层 PR。

影响面(今天为零)

误差方向仍然只朝假可达一侧 —— 也就是仍然只可能让某个批次对死形状做收紧(#4583 的「precisely validated dead slot」)。触发需要:被测形状键数很少(约 ≤ 4),且几乎每个键都是共享叶子。

  • WidgetManifestSchema 19 键 → 0.105,不命中
  • 批 16 / 批 15 / 批 14 已测的形状均不命中

现状

已在 #5056 的 PR 里作为具名 pin 钉住(packages/spec/src/ui/door-reachability.testkit.test.ts,用例名以 KNOWN BOUND 开头),所以这条边界是被测量、被断言的,不是潜伏的。本 issue 只负责让后续批次在遇到小形状时知道该去读那条 pin。

建议给后续批次(17-22)的操作

测到一个 derived-clone 判定时,如果目标形状键数很少,先看 cloneOverlap 和键数,再决定信不信这扇门。

参考:#5056 · #4001 · #4583

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions