用途：对某一“连贯的产品界面”执行只读审计，把它与真正约束它的设计系统做对比，保留产品原有识别度，优先复用既有实现归属；宁可无发现，也不给出无证据支持的发现。只对用户选定的改动编写方案，方案由另一个智能体执行。
主要能力：选择审计界面并沿路由与布局追踪渲染路径（组合、共享组件、变体、解析后的 token 与样式）；重建局部设计系统（查找 DESIGN.md、仓库指南、界面本地设计文档，并区分现行与草稿/提案）；对每个候选发现施加三重证明门槛——契约（有约束力的设计决策或同一任务内用户可见呈现的直接矛盾）、运行时（被引用的归属、值或行为经追踪路径确实到达该界面）、修正（由证据要求的一处明确改动）；再由复查环节尝试证伪并删除不合格条目，按置信度、用户影响、影响面与修正成本排序，最多保留三条。
使用方式：给出范围；范围过宽时先选定一个可部署应用中的一个界面族并说明选择。确认是否有现行设计文档并只检查追踪路径相关的 token、变量、主题、原语、变体与组合。发现筛选后停在报告阶段，询问哪些发现要转为计划；若用户已指定某项或明确要求对所述改进出方案，则继续该范围。编写方案前阅读 references/plan-template.md，每个选定改动写一份计划（非每个症状一份），并记录当前提交、可复用原语与范例、受影响界面。
限制：绝不修改产品源码，只在 design-plans/ 下创建或编辑文件；不安装依赖、不运行格式化工具、不提交、不推送、不改动工作树；不更新设计文档（可接受的文档改动写入计划交由执行者）；仅当用户提供渲染证据或明确要求视觉检查时才使用渲染证据；计划必须自包含，执行者不携带审计或对话上下文。仅凭源码可证明 token、排版、颜色、间距、布局、文案、组件变体、响应式呈现和明确的设计契约违规；层级、突出度、密度、清晰度、可发现性、可用性与整体协调感需要渲染或用户证据。功能行为、状态管理、交互正确性不能转成设计发现。除用户明确要求外，丢弃无障碍与 HTML/ARIA 语义发现，以及坏路由、重定向、数据接线、操作失败、元数据、包 API、性能、架构与代码质量类发现。“偏好”“通常”、名称、遗漏、重复、缺少例外都不构成契约。仓库未提供时不得臆造取值；仅在证明既有系统无法表达该决策并指明应共享的消费者后才引入原语。若无候选通过证明，报告写“未发现受支持的发现”与“无受支持建议”。计费、价格、平台与效果等资料暂未提供。