用途：在编写组件代码之前，列出必须遵守的无障碍要求及其规范依据。产物是设计输入，不是代码，因此没有可评分的对象。
主要能力：SC 挂在内容性质而非组件上，因此筛选走“名称→性质→SC”两跳，能处理 Coachmark、SegmentedControl 等陌生名称。最终输出一份 reports/<component>.md。
流程：0. 侦察 base-ui 文档（https://base-ui.com/react/components/<组件>，kebab-case）与 API 参考，填写四项；1. 只读 references/properties.md（23 个性质词表）打性质标签；2. 用 APG 模式与 MDN ARIA role 文档填 role、状态、属性、键交互、焦点管理、可访问名称六格，无 APG 模式时明确标注；3. 用 references/sc-map.md（SC 全量→性质反查表，60 行）按性质触发筛选 SC；4. 把采纳的 SC 分入基础实现体委派、vapor 自身实现、共同（通道）、消费者四区；5. 按 references/verify.md 收集证据（base-ui 实测或原生元素查规范）；6. 按 references/report-template.md 结构写文档，正文只放需求表，附录放依据与判断。
适用场景：组件实现前的无障碍设计输入、责任划分与需求文档产出。
限制：仅使用表中行，表外 SC 视为非 A/AA 或不存在；无 APG 模式的组件不得借用相似模式，否则会把不存在的属性强加为需求；委派需证据，无证据的 SC 只能标为无法确认。具体命令、价格、平台等信息暂未提供。