搜索/按最新文档修改控制台 UI 工具包,并在真实画面中检查

按最新文档修改控制台 UI 工具包,并在真实画面中检查

用于大改版后的控制台 UI 工具包:遵循当前仓库文档而不是旧习惯,把测试放到正确的位置,并录制运行中的终端来检查 UI 改动。

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