当前 source 有两套不同 registry：
- 18 个 shared primitive 是 capability negotiation 使用的跨设备 vocabulary。
- 42 个 Web-only widget 在 Web runtime 可用，但不构成其他 renderer 的可移植性承诺。
这些数量只是当前 checkout 的事实，不是永久 API-size 保证。要做可移植性声明时，应查看 primitive 名称和目标支持矩阵，而不是看某个 widget 是否长得像原生控件。
小心地加入 custom 名称
blocklet 可以声明 custom primitive 名称，或者 ARC 扫描 Web Component manifest，让 DSL 与结构验证接受这些名称。它只扩大作者可用的名称集合，不会为每种设备自动创建 renderer 实现、添加 degradation chain，或授予 component 特权 data/action capability。
当 target 及其 component contract 本来就是产品的一部分时，可使用 custom type。语义已符合现有可移植合同则用 shared primitive。不要只因页面需要某个 Web-only widget 就把它叫作“primitive”。
分开三种 component 概念
| 概念 | 负责什么 | 不代表什么 |
|---|---|---|
| AUP shared primitive | 可移植的语义意图 | 所有地方都有相同原生呈现 |
| Web widget | Web runtime 能力 | 每个设备 renderer 都支持 |
| Web Device component | 可复用的站点 HTML/CSS/交互呈现 | 新的跨设备 AUP primitive |
没有 degradation chain 的未知/custom type 会原样通过，不会自动变成 text。发布 custom-type 示例前应规划具体 target 的验收。
见Primitive 类型分类与证据；站点 component 层属于目标的 Web Device 文档，不是这份可移植 primitive reference 的一部分。