implement-issue

实施 issue

针对当前仓库端到端解决该 issue，或通过证据确认无需实施。

门槛

• 在作出决定前，阅读 issue、项目说明、愿景、贡献指南、Definition of Ready、Definition of Done、相关领域技能、实际项目命令、受影响的代码路径、测试和复现步骤。
• 在提出方案前，务必执行并记录网络搜索，以获取当前证据。优先采用官方和一手来源，并结合检出版本进行核对；仅将记忆中的链接作为搜索线索。如果搜索无法找到与决策相关的当前证据，则停止。
• 在自动模式之外，必须具备已注册的 grilling 和 render-html 技能，以及 Python 3。如果任何依赖不可用，则停止。使用实际的 grilling 决策流程；不要用临时提问来模仿它。
• 在提出方案前，从 issue、仓库、复现过程、项目约定、当前网络调研和共享当前状态资料中整理一份中立的证据摘要。所有方案都必须基于同一份摘要推导。
• 在评分前，根据 issue 的预期结果、限制和要求制定一套比较标准。每个可行方案都必须经过同等且与决策相关的验证：
  • 对于 UI/UX 差异，展示每种实质不同的体验；
  • 对于架构或工作流差异，展示每种相关流程；
  • 对于交互密集型或技术性主张，如果静态证据不足以作出判断，则使用可比较的短期原型或测量结果。 等同检查不意味着实现工作量必须相同。标明观察到的事实、拟议行为和仅用于原型的简化方案。
• 如果某个方案暴露了证据缺口，则对每个受影响的方案执行相同的相关检查。如果无法做到，则披露证据不均衡，并在比较前降低置信度。
• 原型必须在本地临时使用；只保留可供审查的记录和发现，并在比较结束时删除。不得部署或发布原型。只有获得用户明确批准后，才能保留或提升原型；在 git-workflow 同步门槛通过之前，已批准的原型材料必须放在所选工作树之外。
• 根据声明的标准比较 2 到 4 个真正不同且可行的方案，然后推荐一个并等待用户选择，自动模式除外。附上精简的证据摘要，其中包含最相关的来源链接、已核查的项目版本、评分和未解决的不确定性。
• 在自动模式之外，使用 render-html 在 grilling 决策流程开始前，将比较内容呈现为临时交互式影响报告。报告须包含共享结构化证据、声明的比较标准、各方案的影响、优缺点、评分、不确定性，以及可复制的讨论提示。推荐方案必须放在所有中立方案之后的结尾部分。
• 如果当前证据明确表明无法达到必需的原型或就绪门槛，则报告并停止；不要询问是否可以绕过门槛。
• 选定方案或进入自动模式后，即使用户询问状态、要求诊断、提出更正或门槛检查失败，也要继续执行已获授权的实施工作。只有在工作完成、外部阻碍耗尽了安全且范围内的进展，或继续执行需要新的授权或解决重大未决决策时，才交还控制权。已知的修复方案或建议不构成终止条件。
• 对任何代码或测试更改，都必须针对该 issue 重复执行 /code-review fix-all 和黑盒测试，直到二者在同一份未更改的实现上均通过；随后完成项目门槛并执行 /create-pr。

项目定义

将最近且适用的 DEFINITION_OF_READY.md 和 DEFINITION_OF_DONE.md 视为规范依据。如果经过实际查找后发现其中任一文件缺失， 请说明一次，并在计划和 PR 中体现这一缺口；仅使用工作流内置的检查以及仓库实际声明的命令。

自动模式

仅当原始提示中写有 automatic 或明确提出此要求时，才适用自动模式。该模式会跳过交互式 HTML 报告和 grilling 环节，但不会豁免任何其他关卡。共享资料包、预先声明的评分标准和等效检查全部完成前，不要选择任何选项。如果比较仍未完成，请报告这一缺口及其对置信度的影响，而不要将初始偏好视为已验证。任何重大的产品、架构、安全、范围或愿景决策都会禁用自动模式。

工作流

1. 获取 issue，包括评论和标签；确认它处于打开状态，已具备实现条件，且不是 PR、重复项、受阻项或已拒绝项。
2. 加载适用的项目规范和专用技能。
3. 从入口点到症状追踪完整行为，并尽可能运行所引用的复现步骤或检查相关产物。充分搜索调用方、同类路径、测试、配置和历史记录，以确定真正的问题层。务必执行当前网络搜索，并将搜索结果与当前检出内容核对。
4. 如果该行为已无法复现，请区分以下情况：
   • 已修复且有测试覆盖：建议关闭 issue，并提供修复代码／提交和测试证据；
   • 已修复但没有回归测试覆盖：仅补充缺失的测试；
   • 共享根因导致的同类路径仍受影响：仅纳入这些路径。
5. 整理中立的证据包和比较标准，得出备选方案，并用同等且与决策相关的检查验证每个方案。先比较，之后再提出建议。
6. 在自动模式之外，创建一个位于工作树之外的临时目录。遵循 render-html 规范，并在那里呈现方案比较。打开报告进行审阅。如果无法在宿主环境中预览内嵌内容，请提供报告的绝对路径并继续。使用报告和共享证据，一次讨论一个决策点，随后等待用户在聊天中选择。用户选择后，删除临时报告及其输入文件，除非用户明确要求保留。
7. 用户作出选择后，复用或创建专用分支／工作树，并在编辑前执行 git-workflow 远程默认分支同步门禁。
8. 在正确的问题层实施最小且完整的变更。根据 issue 和项目规范更新所需的测试和文档。
9. 对于 UI／UX 工作，呈现所有受影响的状态；捕获可供审阅的前后对比证据；检查无障碍性、响应式行为、主题和设计系统一致性；将证据附加到 PR。
10. 开发过程中运行针对性检查。修复失败项，不要弱化检查。
11. 针对需求、完成定义、项目约定、分支差异和可复现行为运行 /code-review fix-all。解决所有已验证且属于范围内的问题。若出现实质性的新决策，或仍有未解决的阻塞级或重要问题，则暂停。如果无法使用 /code-review，则直接执行同等范围的审查和修复。
12. 如果可用，运行 /test-against-spec fix。否则直接执行同等的黑盒测试：使用明确的 issue 需求，不以源代码作为证明；优先使用与当前修订版本完全一致的预览部署（如可用），否则使用本地环境。记录每项需求及其观察到的结果或限制。
13. 如果步骤 11 或 12 更改了实现或报告有未完成工作，则继续实现并从步骤 11 重新开始。重复此过程，直到代码审查和行为测试均在同一份未更改的实现上通过。若穷尽可用环境后仍无法验证必需行为，则暂停并询问；除非用户明确接受该限制，或请求创建草稿 PR 以获取缺失的预览环境。
14. 运行适用的完成定义和仓库门禁。如果修复门禁失败项导致实现发生变化，则返回步骤 11。不要在行为测试步骤中重复执行范围较广的门禁。
15. 使用 /create-pr，注明 Closes #<issue>，传递当前的完成证据，并且只报告观察到的结果。
16. 在任何更早的返回之前，执行活动实现终止检查。如果尚未满足任何终止条件，则继续执行下一个安全且已获授权的操作。