修改界面组件库，并检查有没有改坏

## 用仓库规定的包管理工具，从根目录运行命令 仅使用代码仓库声明的软件包管理器和工作区命令形式。应从根目录通过管理器的工作区筛选器执行限定于软件包的操作，不要进入软件包目录后调用其他工具。 只在必要时安装依赖项。迭代期间，优先使用范围最窄的软件包构建、测试、代码检查或类型检查命令；代码仓库全量构建应留给集成验证或发布验证。 将文档开发、软件包构建、文档构建、单元测试、浏览器测试、端到端测试、视觉回归测试、格式化、代码检查和类型检查作为彼此独立的工作流。 ## 新组件先放在实验区，内部软件包不对外公开 将库划分为核心组件、样式系统、实验性组件、图标或资源、共享实用程序、样式引擎抽象层和未发布的内部软件包。遵守哪些软件包面向公众，哪些仅用于支持工作区的界限。 新组件或不稳定组件应先引入指定的实验区域，再提升到稳定软件包。共享样式和主题行为应放在样式层中，不要在各组件之间重复实现。 不得通过公共入口点暴露内部软件包，也不得基于特定实现的假设绕过已配置的样式引擎抽象层。 ## 整理组件文件，导入时只引入需要的部分 实现、声明、测试、样式类和公共导出应遵循代码仓库的组件文件布局。将每项职责保留在其归属文件中，使`API`文档、测试和摇树优化保持可预测。 公共组件属性应使用代码仓库要求的声明形式，并从组件模块导出命名一致的属性接口。保留路径别名和公共导出约定。 如果宽泛的聚合入口导入会把整个软件包纳入打包产物，请在工作区内使用范围较窄的单层软件包导入。应将导入形式视为性能和打包契约，而不是样式偏好。 ## 写出说明发生了什么、该怎样修复的错误信息 公共软件包抛出的每个错误都必须说明发生了什么、为何重要，以及调用方可以如何修复。使用规定的库前缀和可读的消息构造方式；存在仍在维护的指南时，应附上文档链接。 将代码仓库规定的错误压缩标记应用于受支持的错误构造器，使生产包能够以稳定代码替换长消息，同时让开发环境中的内容保持易懂。 添加或更改公共错误后，应重新生成错误代码目录。如果语义和参数数量未变，应更新现有目录条目，而不是为同一错误契约创建新代码。 ## 按用户实际点击和输入的方式测试组件 使用代码仓库共享的渲染器和断言实用程序，使组件测试与受支持的环境一致。与底层事件分发或直接修改属性相比，应优先采用无障碍查询和完整的用户交互。 使用已配置的匹配器测试可观察行为、状态转换、警告和错误。单元测试应保持聚焦；迭代期间可以使用名称筛选器，但不得把筛选后的通过结果误认为已经完整覆盖。 如果测试需要模拟`DOM`中无法提供的布局、浏览器`API`或渲染行为，应将其限定在受支持的真实浏览器环境中，并在测试条件里记录原因。 ## 关闭截图检查时，不连带关闭无障碍检查 代码仓库共享同一会话时，应在既有的浏览器回归循环中运行无障碍分析。将截图和无障碍断言视为独立控制项：演示可以停用其中一项，但这并不意味着另一项也随之停用。 明确说明无障碍规则的覆盖范围。按演示和规则记录通过、失败及未完成结果，包含适用的无障碍标准标签；除非配置了范围狭窄且理由充分的例外，否则应保留必要断言。 如果集成回归框架已经负责导航、渲染、截图和无障碍分析，就不要启动单独的浏览器工作流。 ## 排好例外规则的顺序，跳过一个演示时不影响其他演示 使用稳定的演示标识符匹配回归配置。如果规则在不继承的情况下采用“最后匹配者优先”的优先级，应把范围较窄的覆盖项放在宽泛规则之后，并重新声明该覆盖项需要保留的每个字段。 针对单个演示使用范围较窄的模式；只有完整组件组才能使用更宽泛的模式。停用单个演示的规则不得意外停用同组的其他演示，也不得继承过时的例外字段。 更改规则后，应重新生成结构化无障碍产物和视觉产物。持续集成应拒绝过时的生成报告，不得默默接受从未实际运行过的配置。 ## 开发中只测相关部分，推送前运行全部测试 使用测试运行器的名称筛选器限制本地回归运行，使不匹配的测试不会操控浏览器或改写无关产物。确认筛选器与测试名称中嵌入的路由或演示标识符匹配。 请注意，筛选运行只会刷新匹配组件的报告。推送前应运行不带筛选器的回归命令，使每份报告、截图和无障碍结果都保持最新。 如果代码仓库的工作流有此要求，应让回归服务器和运行器保持为两个独立进程，并保留软件包管理器文档规定的参数转发语法。 ## 修改组件后，重新生成API文档和演示 更改组件属性或类型声明后，应运行属性提取生成器和`API`文档生成器。将生成的公共`API`差异与源代码变更一并审查。 将指定的类型化演示作为事实来源，并通过受支持的格式化程序或转换器生成其他语言变体。不得仅靠手动编辑生成的演示变体来完成修复。 演示或`Markdown`发生变化时，应运行相应的演示生成、文档构建、行文风格和语法检查。将专门的集成指南保存在自成体系的本地指令模块中；执行样式、主题、渲染或框架集成工作时，应加载相关模块。 ## 做完这次修改需要的检查，并说明没做的检查 审查前，应格式化已更改文件，运行代码检查和类型检查，执行有针对性的单元测试，并根据受影响的行为扩展到真实浏览器、端到端、视觉、无障碍、`API`文档或行文检查。 相关源文件发生变化时，应验证生成的错误代码、`API`参考资料、演示变体、截图和无障碍报告。不得将部分验证表述为完整验证；应报告任何受阻或未运行的门禁。 审查应聚焦于该组件，并使用代码仓库规定的变更标题格式：先写稳定的组件或文档范围，再写祈使句说明。