用途：面向已有定制 UI 的产品（应用、网站或功能），产出一份可执行的设计系统采纳计划——清点现状、映射替代组件、估算工作量、编排分波次排期。
主要能力：分为四阶段。阶段1拆解现有 UI 清单，输出 BASELINE.md；阶段2将每个产品模式映射到设计系统替代品，输出 MAPPING.md；阶段3为每个映射估算工作量，并入 MAPPING.md；阶段4生成分阶段计划 plans/<date>-adoption-plan.md。映射处置类型包括：Swap（直接替换）、Compose（用系统部件拼装）、Recipe candidate（建议上游收录）、System gap（系统缺失，先登记再规划）、Delete（死代码删除）、Keep（有意保留的定制或第三方代码）。
使用方式：支持三种模式——完整运行、单阶段运行、进度重跑。运行时会读取或生成 adoption-plan/ 目录下的文件：GARAGE.md（产品档案与设计系统目录访问方式）、BASELINE.md、MAPPING.md、plans/。目录访问按链条进行：优先设计系统自身的 MCP/CLI，其次机器可读目录导出（如 custom-elements.json、token JSON），再看文档站点，最后通过访谈获得（标为 [reported]）。若无法写文件，可在对话中输出同样产物供用户保存。
限制与规则：结论需有证据，分为 [verified]（直接看到代码、运行产品或系统目录）与 [reported]（用户口述无法确认）；映射只有在核对目标组件真实 API 后才算已验证。以源码而非构建产物为清点对象。目录中标注的“不要这样用”与无障碍说明优先于直觉命名。系统缺失记为系统发现而非产品问题，并单独安排受阻波次。已存在于问题跟踪器的发现要引用而非重复创建，新建问题需经人工批准。优先级与最终排期由团队决定。
适用场景：需要在既有产品上推进设计系统落地，或分波次逐步替换定制 UI 的团队。
暂未提供：具体价格、平台支持范围、各阶段耗时基准以及确定性扫描器的具体名称。