# 预注册 —— U3「元数据面是否真的变轻了」补测（`lab:U3` 收尾缺口）

🔴 **本文件先于任何取数代码提交，⛔ 零读数。** 取数后一字不改；要补只能在取数前补并留痕。

承接：[`docs/2026-09-02-open-items.md`](2026-09-02-open-items.md) §21.8 —— U3 落地时明确记录
「元数据面是否真的变轻了」这条判据**未取数**，原因是 `measure-import-cost.mjs` 的 `ONE` 硬编码成
`InputBoxFilled`，且提案 §6 设想的「用 `lazy.ts` 当 `ONE`」**这把尺子实际不存在**
（`lazy.ts` 只出现在已废弃的 WIP commit `896ceed9` 里，未合入 master，且该 commit 明确标注
「🔴 未达成，⛔ 别合并，⛔ 别照这条路再走一遍」——重开它属于违反既有判定）。

---

## 1. 为什么不能沿用 `measure-import-cost.mjs` 的口径

`measure-import-cost.mjs` 模拟的是**真实 npm 消费者**：入口通过包名 `@ux-team/tvu-design-system`
解析，走 `package.json` `exports` 字段。DS 的 `exports` 里**没有任何路径**把
`src/icons/manifest.ts`（U3 真正改动、也是唯一直接受益的文件）暴露给外部消费者单独导入——
`./icons/manifest.json` 是构建产物 JSON，`./icons/esm/*` 是逐个图标组件，都不是「只读元数据」这条路径。

⇒ U3 的收益（`manifest.ts` 变轻）目前**没有公开消费入口**，不是「消费者体感」层面能测的东西，
只能在 DS 仓内部对源文件做**源码级打包探针**——这是一把新尺子，不是给旧探针加参数。

## 2. 承诺指标（🔴 取数前写死）

**面**：一个最小 vite 单文件构建，入口**直接指向 DS worktree 内的源文件路径**（不经过
`node_modules` / `package.json exports` 解析——因为要测的对象本来就没有公开导出）。

| 代号 | 定义 |
|---|---|
| `EMPTY` | 入口不 import 任何东西（零基线，量打包器自身开销） |
| `MANIFEST_ONLY` | 入口 `import { iconManifest } from '<DS>/src/icons/manifest.ts'`，export 其 `.length` |
| `REGISTRY` | 入口 `import { iconRegistry } from '<DS>/src/icons/registry.ts'`（U3 未改动的对照组——它本该仍然拖入全部 SVG） |

**P1（主判据，双向）**：`MANIFEST_ONLY` 产物字节数与 `EMPTY` 的差值（记 `MANIFEST_COST`）
应**逼近提案 §1 换桩实验读数量级**（12,310 B 附近，⛔ 不要求逐位相同——真实 644 条
`IconDefinition` 比换桩存根数据多，允许同量级内的合理浮动，本轮定「同一数量级」= 5,000–40,000 B 区间）。
- 落在区间内 ⇒ `U3_WEIGHT_VERDICT = 元数据面确认变轻`
- 落在区间外但仍显著小于 `REGISTRY_COST` ⇒ `U3_WEIGHT_VERDICT = 变轻但幅度与换桩实验不同量级`（如实报，不強行套区间）
- 与 `REGISTRY_COST` 同量级或更大 ⇒ `U3_WEIGHT_VERDICT = 未变轻` ⛔ 不许挪判据美化

**对照**：`REGISTRY_COST`（`REGISTRY` 产物 − `EMPTY`）必须显著大于 `MANIFEST_COST`
（这是阴性对照，证明量具真的测出了「元数据面 vs 载荷面」的差异，⛔ 不是循环论证——
`REGISTRY` 是 U3 完全没碰的旧路径，理应保留全部 SVG）。

## 3. 内建控制（fail closed）

| # | 控制 | 红了意味着 |
|---|---|---|
| C1 | 产物里不出现 SVG 特征字符串（如 `<svg` / `<path`）—— `MANIFEST_ONLY` 产物 grep 应为 0 命中 | 元数据面其实没和载荷解耦，U3 白拆了 |
| C2 | 同一入口连测两次，字节数逐位相同 | 构建有噪声，不许报小于噪声的差 |
| C3 | `MANIFEST_ONLY` 产物里能反序列化出恰好 644 条记录（复用 U3 落地时的核验基线） | 量具本身有 bug，不是真的测到了完整 manifest |

## 4. 覆盖边界（⛔ 是边界，不是 TODO）

1. 本轮只回答「manifest.ts 源文件本身是否变轻」，⛔ 不代表存在一条给外部消费者用的公开路径能拿到这份收益——
   那条路径目前不存在（§1），是否要开一条属于另一个独立决策，不在本轮范围。
2. ⛔ 不重新引入 `lazy.ts` 或以任何形式让 `Icon.vue`/`Logo.vue` 切换消费路径——那是已判定「修法不足」
   且明确禁止重走的路（`896ceed9`），本轮只读、不碰生产代码。
3. ⛔ 不在 DS 主工作树或任何 U3 已落地的分支上操作——本轮在独立 worktree
   （`~/.ai-ds-lab/wt/u3-icon-lazy-cost`，DS `67dc2c37`）内进行，探针脚本落在 lab 仓的独立分支
   （`lab/u3-import-cost-probe`）。

## 5. 判定后要驱动什么

- `确认变轻` ⇒ 回填 `open-items.md` §21.8 的缺口，标记「元数据面收益已实测」，供 owner 判断是否值得
  排期开一条公开导出路径（不在本轮做）。
- `未变轻` 或量具控制任一红 ⇒ 如实报，说明当前量具局限，⛔ 不合并任何"看起来更快"的叙述。