在不改变产品身份的前提下审计现有界面并输出可执行改进计划

当你需要审查、优化或清理某个产品界面，且必须保留其原有设计身份、只做只读审计并交给其他代理执行时使用。

适用场景

解决思路

1. 严格只读产品源码：只在 `design-plans/` 目录下创建或编辑文件，绝不修改产品源码。
2. 不要安装依赖、运行格式化工具、提交、推送或对工作树做任何变更。
3. 不要更新设计文档；把已接受的设计文档变更记录到计划中，交由执行者处理。
4. 仅当用户提供渲染证据或明确要求视觉检查时，才使用渲染证据。
5. 让每份计划自包含，因为执行者没有审计或对话的上下文。
6. 尊重用户给定的范围；若请求过于宽泛，选择一个可部署应用和一个连贯的界面族（代表主要产品任务），并说明选择，不要把整个仓库综合成一个产品。
7. 从界面的路由和布局入手，沿渲染路径追踪组合、共享组件、变体、解析后的 token 和样式；不要一开始就全仓库搜索不一致。
8. 只有当连接通过渲染、导入、props、解析后的配置、CSS 继承或被界面加载的生成产物得到证明时才认定其存在；共享命名、相似 token、仓库邻近性和概念关系都不算连接。
9. 排除其他应用、预览、配置器、生成的注册表、遗留系统和企业变体，除非它们参与被追踪的路径。
10. 检查 `DESIGN.md`、仓库指南和界面本地设计文档；只有证明某来源是当前有效且管辖所选界面后才使用它；草稿、提案、迁移和任务列表描述的是未来意图，除非明确接受且当前有效。
11. 设计文档缺失不构成发现。
12. 只检查与追踪路径相关的 token、变量、主题、原语、变体和组合；把别名和变体解析到其定义。
13. 只有当仓库明确说明时，才把某个实现归类为本地或遗留。
14. 记录设计语言：审计的界面、设计来源、已记录的决策、管辖的所有者与消费者、显式例外；除非被引用来源明确标识为例外，否则在 `Explicit exceptions` 下写 `None documented`。
15. 在应用证明门槛前，检查每个被追踪界面的用户可见标签、激活态呈现、响应式分支和同级变体是否存在内部矛盾；结果仅作为候选。
16. 只有当修正主要改变视觉呈现、界面文案、布局、组件样式或对已记录设计规则的符合性时，该发现才在范围内；若修正主要改变产品行为是否可用，则拒绝。
17. 搜索结果、重复和实现差异只产生候选，不产生发现；只有同时具备以下三个证明时才保留候选：契约（引用针对该属性和范围的约束性设计决策，或同一任务内用户可见呈现或内容的直接矛盾）、运行时（证明所引用的所有者、值或行为通过追踪的运行时路径到达受影响界面）、修正（陈述证据要求的一项变更，若依赖现有 token、变体、原语或范例则精确命名；若证据无法确定正确选择、意图条件模糊、提案含备选方案或修正需要发明产品意图，则拒绝）。
18. 源码只能证明 token、排版、颜色、间距、布局、文案、组件变体、响应式呈现和显式设计契约违规；不能把功能行为、状态管理或交互正确性变成设计发现；层级、突出度、密度、清晰度、可发现性、可用性和感知一致性需要渲染或用户证据。
19. 除非用户明确要求，否则丢弃无障碍和 HTML/ARIA 语义发现；除非用户要求或有产品特定设计契约管辖，否则丢弃坏路由、重定向、数据接线、操作失败、元数据、包 API、性能、架构和代码质量发现。
20. 只有在所有证明通过后才分配置信度；当证据支持时复用现有所有者，不要仅凭重复就创建共享原语。
21. 报告前重新打开每个被引用来源并尝试证伪每个候选；当问题与所引用实现不完全匹配、规则不管辖该属性和界面、反证表明差异有效或有意、证据支持多种修正、修正发明产品意图，或另一发现描述同一根因时，删除该候选。
22. 只让通过证伪的发现进入表格，按置信度、用户影响、影响范围和修正成本排序，最多保留三个。
23. 使用指定结构报告：`## Design language`（审计的界面、设计来源、已记录的决策、管辖的所有者与消费者、显式例外）、`## Findings` 表格（#、Problem、Evidence、Proposed change、Scope、Confidence）、`## Improve first`（最高杠杆发现及原因，或无支持建议）。
24. 证据必须确立契约、运行时关系和确定性的界面后果；提议变更必须只包含一项修正；返回前删除不支持或重叠的行。
25. 删除任何缺少必需列（包括 Confidence）的发现。
26. 在 `Improve first` 下选择一个证据最强、杠杆最高的存活发现；绝不合并发现。
27. 若没有候选存活，在 `## Findings` 下写 `No supported findings were found.`，在 `## Improve first` 下写 `No supported recommendation.`。
28. 若有发现存活，停下来询问要把哪些转成计划；若用户已选择某个发现或明确要求为所述改进制定计划，则按该范围继续；若被要求直接修复或改进，只提供计划，绝不实现。
29. 阅读 [references/plan-template.md](references/plan-template.md)；每个选定的变更写一份计划，绝不按症状写计划。
30. 写计划前重新打开每个被引用来源，在可用时记录当前提交，识别精确可复用的原语和范例，并追踪受影响界面；协调现有计划而不是重复它。
31. 当仓库提供 token 或组件契约时不要发明值；只有在证明现有系统无法表达该决策以及哪些消费者应共享它之后，才引入原语。
32. 若被要求协调，对照当前源码和已记录决策重新检查现有计划；更新过时证据、受影响界面和状态。

适用边界 · 注意事项

• 需要修改产品源码、安装依赖、运行格式化工具、提交或推送时。
• 需要把功能行为、状态管理、交互正确性、无障碍、性能、架构或代码质量作为设计发现时（除非用户明确要求或有产品特定设计契约管辖）。
• 没有渲染或用户证据却要判断层级、突出度、密度、清晰度、可发现性、可用性或感知一致性时。