解决 GitHub 议题

使用本流程把 GitHub 议题转化为根因修复、经过验证的回归测试和可提交项目审查的拉取请求。理解失败路径前，不要把持续集成表面症状当成修复目标。

接收议题

1. 从用户请求确定议题：
   • 用户给出编号或网址时，读取指定议题；
   • 用户说“最近”“最新”或没有给编号时，列出 rcore-os/tgoskits 最近的开放议题，选择错误类议题，不选择功能需求。
2. 完整读取议题正文、评论、关联拉取请求、检查日志、失败片段、标签和日期。记录精确失败命令、体系结构、目标、测试名和错误现象。
3. 修改前检查失败测试或工作流程，确定它要证明的行为、发现它的运行器，以及成功和失败标记的含义。
4. 议题涉及 Starry 或 ArceOS 测试套件文件时，同时使用 starry-test-suit 或 arceos-test-adapter 等匹配的项目技能。

未指定议题时的选择规则

用户没有指定议题时，优先选择证据充分且可以执行的错误类议题。良好候选通常包含日志网址、体系结构、板卡或 QEMU 目标、测试用例、内核恐慌或错误文本、复现步骤。

除非用户明确要求，否则避开功能需求或规划议题。标题或正文主要由 feat、支持、新增、实现、提案、计划、方案、项目、总括跟踪、路线图或剩余工作构成时，应继续检查更早的开放议题。找不到可执行的错误类议题时，报告结果并询问是否改为处理功能需求。

先定位根因

• 用户明确要求子代理，或独立调查能缩短路径时使用子代理。适合拆分为：测试语义与运行器行为；内核或库调用链及直接错误来源；Linux、可移植操作系统接口、征求意见稿或虚拟输入输出规范等外部语义；最终补丁独立复核。
• 从用户可见错误向内追踪到第一个产生该错误的来源，再多追一层，解释为什么会到达该来源。
• 除非根因证明原预期错误，否则不得只放宽匹配规则、增加超时、在测试中重试、忽略 EINTR 或削弱断言。
• 修复时保留相邻契约，例如非阻塞输入输出返回 WouldBlock、为事件轮询就绪状态登记唤醒器、系统调用重启语义，以及 Starry 分组测试的失败传播。

回归测试

1. 按 test-quality 查找根因所属的完整功能证明，优先复用或增强现有测试，仅在缺少独立行为证明时新增。选择能够真实触发根因的最小充分层级；运行时错误不能用宿主伪实现替代。
2. 用先失败后通过的检查证明测试有效：
   • 在真实被测实现中恢复错误逻辑或使用尚未修复的实现，不以替身自行模拟错误代替根因；
   • 运行同一个窄测试，确认它因预期原因失败；
   • 恢复修复，再确认同一个测试通过。
3. 可行时保留议题原始命令作为端到端验证，尤其是 Starry 或 ArceOS 的 QEMU 议题。
4. 较低层无法确定性触发根因时，使用能触发真实错误的集成或系统功能测试。仍无法取得确定性红绿证据时，说明具体缺口和未完成项，不以新增概率性测试宣称完成。

实现与验证

• 只做解决根因所需的最小代码改动，不混入无关重构。

• 修改代码后运行 cargo fmt。

• 修改软件包后运行定向静态检查，优先使用：

  cargo xtask clippy --package <crate>
  

• 运行窄回归测试和议题原始复现命令。Starry、ArceOS 和 Axvisor 的构建、测试与运行优先使用 cargo xtask。

• 发布前运行 git diff --check。

拉取请求流程

1. 为议题创建或使用范围单一的分支，不带入无关改动。
2. 按约定式提交格式提交，通常使用 fix(<crate-or-area>): <summary>。
3. 默认创建可直接审查的拉取请求。只有用户明确要求草稿、验证有意未完成，或存在必须阻止审查的已知问题时才创建草稿。
4. 标题使用英文；正文使用中文并包含：
   • 问题和根因；
   • 修改内容，以及每一步为何必要；
   • 同一确定性回归测试先失败后通过的证据；
   • 本地验证命令和结果；
   • Fixes #<issue>，使合并后自动关闭议题。
5. 拉取请求分支增加或修改提交后，同步更新拉取请求描述。

最终报告

报告议题编号、根因、行为变化、回归测试证据、验证命令、分支、提交、拉取请求网址，以及是否包含 Fixes #<issue>。跳过任何验证时说明具体原因。