


按最新文档修改控制台 UI 工具包,并在真实画面中检查
用于大改版后的控制台 UI 工具包:遵循当前仓库文档而不是旧习惯,把测试放到正确的位置,并录制运行中的终端来检查 UI 改动。
要使用这个AI规则
## 遵循当前仓库文档,而不是旧版本的写法
- 当项目声明正在进行重大重写时,即使名称看起来熟悉,也应假定过去学到的模式可能并不兼容。
- 在设计、编辑或审查代码之前,先阅读仓库当前的迁移入门文档。
- 使用版本化源码文档中的当前最小应用模式、术语、生命周期和兼容性说明。
- 相比记忆或早期版本的示例,应优先遵循项目章程、贡献指南、机器可读上下文和嵌套规则。
- 如果当前文档与既有知识不一致,应遵循当前仓库并记录差异,不要混合两种设计。
## 开始前先分清是做应用还是修改工具包本身
- 首先将请求分类为应用构建、工具包贡献、缺陷修复,或可视化记录与验证。
- 面向使用方的应用应采用专用应用指南和模式手册。
- 库功能和缺陷应采用贡献者工作流。
- 可见的 UI 变更和交互证据应采用录制工作流。
- 在更改生命周期、视图层级、布局、可取消事件和领域术语相关区域之前,先阅读对应的关键概念文档。
- 不得将仅供贡献者使用的内部机制套用到应用示例,也不得将应用层的捷径用于核心库工作。
## 每次编辑前和写完代码后都过一遍检查清单
- 每次编辑文件前,都要按照仓库的刷新检查清单检查常见错误和本地约束。
- 编写或修改代码后,执行完整的生成后验证清单。
- 阅读所有受影响主题的详细规则,包括格式、类型声明、构造语法、事件模式、Unicode 文本、代码布局、文档、测试、诊断和脆弱区域。
- 在规划模式下,在指定的计划目录中创建 Markdown 计划,列出实现步骤、受影响文件、复用机会和验证方式。
- 让计划与实际范围保持一致;当证据改变实现路径时,应同步更新计划。
## 新测试默认放进可并行运行的测试套件
- 恢复依赖项,只构建一次;只要构建结果仍是最新的,就在不重新构建的情况下运行聚焦测试。
- 新测试默认应放入可并行执行的测试套件。
- 只有无法避免进程级静态状态时,才可使用非并行套件,并说明这一依赖关系。
- 绝不得向计划重写或移除的旧版套件添加新覆盖。
- 迭代期间只选择单个方法或类;聚焦结果通过后,再扩展到相关项目。
- 在选择集成、压力、基准、并行或非并行覆盖之前,先查阅测试清单。
## 录制运行中的终端,检查 UI 改动
- 未观察运行中的界面,不得交付可视化变更。
- 在伪终端中运行应用,注入有代表性的按键输入,并捕获渲染后的会话。
- 逐帧读取机器可读的录制内容,验证实际出现的画面,不要只相信人工预览。
- 当审查者需要评估外观或交互时,应附上可视化产物。
- 对确定性断言,使用进程内输入注入、虚拟时间和驱动层屏幕捕获。
- 按变更影响的层级验证布局、焦点、输入处理、Unicode 字素、取消和重绘行为。
## 遵守仓库规定的空格和类型写法
- 保持仓库对调用与索引周围空格、花括号位置和空行的要求。
- 除本地指南允许的少量内置原始类型外,均使用显式类型。
- 在有要求时,优先使用目标类型推断的构造方式和集合表达式语法。
- 每个文件只放置一个 public 或 internal 类型。
- 按代码布局规则排列成员和后备字段。
- 对未使用的回调参数,采用仓库规定的弃元约定。
- 运行仓库格式化工具和生成后检查;不得将样式差异轻描淡写为纯粹的外观问题。
## 使用提前返回,并统一使用项目术语
- 优先使用守卫子句和提前退出;应反转条件,不要把成功路径包裹在深层嵌套中。
- 对方法、回调和循环采用相同的提前退出规则。
- 始终一致地使用项目规定的包含关系术语,并将通用关系术语保留给非包含引用。
- 添加注释前,先通过名称、类型和结构让代码自行解释意图。
- 在参考、操作指南和 API 文档中,先说明目标,再直接以祈使句给出操作。
- 按仓库规定的文档格式记录公共契约、可取消工作流行为、Unicode 字素处理和不明显的不变量。
## 不减少覆盖率,补充防止问题复发的测试
- 使用仓库认可的代理与模型注解标记代理生成的测试。
- 绝不得为了让变更通过而降低覆盖率。
- 除非相关行为明确需要进程级状态,否则不要在测试中执行全局应用初始化。
- 优先采用隔离的设置、确定性输入、虚拟时间和可观察断言。
- 每项测试都应放入与其状态模型匹配的套件,而不是仅按最接近的文件名归类。
- 为用户可见的缺陷或行为添加回归覆盖,并在相关时纳入布局和事件顺序场景。
## 使用仓库的日志功能,不碰脆弱或无关的代码
- 使用仓库的日志、测试日志和跟踪设施;不得从库代码或测试代码直接写入控制台。
- 不得以顺手清理为由重构文档标明为脆弱的子系统。
- 实现聚焦功能或修复时,不得修改无关代码。
- 不得引入新的编译器、分析器、文档或测试警告。
- 报告完成前,重新检查差异中的格式、术语、测试位置和意外的范围扩大。
- 如果必须更改脆弱区域,应将编辑隔离为必要的最小范围,并先验证该区域的专属行为,再运行更广泛的测试。
