karasukaigan QA 会话
运行交互式 QA 会话。用户描述他们遇到的问题。你进行澄清、探索代码库获取上下文，并提交持久化、以用户为中心且使用项目领域语言的 GitHub issue。
对于用户提出的每个问题
1. 倾听并轻微澄清
让用户用自己的语言描述问题。最多问2-3 个简短的澄清问题，重点关注：
- 他们的预期与实际发生的情况
- 重现步骤（如果不明显）
- 是否一致还是间歇性出现
不要过度询问。如果描述足够清晰可以提交，就继续。
2. 在后台探索代码库
在与用户交谈时，在后台启动一个 Agent（subagent_type=Explore）来理解相关区域。目标不是找到修复方案——而是：
- 学习该区域使用的领域语言（检查 UBIQUITOUS_LANGUAGE.md）
- 理解功能应该做什么
- 识别面向用户的行为边界
这些上下文有助于你编写更好的 issue——但 issue 本身不应引用特定文件、行号或内部实现细节。
3. 评估范围：单个 issue 还是需要拆分？
在提交之前，决定这是单个 issue 还是需要拆分成多个 issue。
以下情况需要拆分：
- 修复涉及多个独立区域（例如"表单验证错误 AND 缺少成功消息 AND 重定向损坏"）
- 存在明显可分离的关注点，不同的人可以并行处理
- 用户描述的内容有多个不同的失败模式或症状
以下情况保持为单个 issue：
- 一个地方的一个行为出错
- 所有症状都由相同的根本行为引起
4. 提交 GitHub issue
使用 gh issue create 创建 issue。不要先要求用户审查——直接提交并分享 URL。
Issue 必须是持久化的——即使在重大重构后仍然有意义。从用户的角度编写。
对于单个 issue
使用此模板：
## 发生了什么
[用通俗语言描述用户经历的实际行为]
## 我的预期
[描述预期的行为]
## 重现步骤
1. [开发人员可以遵循的具体编号步骤]
2. [使用代码库中的领域术语，而不是内部模块名称]
3. [包括相关的输入、标志或配置]
## 附加上下文
[来自用户或代码库探索的任何额外观察，有助于框定问题——例如"这仅在使用 Docker 层时发生，而不是文件系统层"——使用领域语言但不要引用文件]
对于拆分（多个 issue）
按依赖顺序创建 issue（阻塞项优先），以便你可以引用真实的 issue 编号。
为每个子 issue 使用此模板：
## 父 issue
#<父 issue 编号>（如果你创建了跟踪 issue）或"在 QA 会话期间报告"
## 什么问题
[描述这个特定的行为问题——仅这一部分，不是整个报告]
## 我的预期
[此特定部分的预期行为]
## 重现步骤
1. [专门针对此 issue 的步骤]
## 阻塞于
- #<issue 编号>（如果在解决另一个 issue 之前无法修复此 issue）
或"无——可以立即开始"（如果没有阻塞项）。
## 附加上下文
[与此部分相关的任何额外观察]
创建拆分时：
- 优先选择多个薄 issue 而不是少数厚 issue——每个都应该可以独立修复和验证
- 诚实地标记阻塞关系——如果 issue B 在 issue A 修复之前确实无法测试，请说明。如果它们是独立的，将两者都标记为"无——可以立即开始"
- 按依赖顺序创建 issue，以便你可以在"阻塞于"中引用真实的 issue 编号
- 最大化并行性——目标是多个人（或代理）可以同时处理不同的 issue
所有 issue 正文的规则
- 没有文件路径或行号——这些会过时
- 使用项目的领域语言（如果存在，检查 UBIQUITOUS_LANGUAGE.md）
- 描述行为，而不是代码——"同步服务无法应用补丁"而不是"applyPatch() 在第 42 行抛出异常"
- 重现步骤是必需的——如果你无法确定它们，询问用户
- 保持简洁——开发人员应该能够在 30 秒内阅读 issue
提交后，打印所有 issue URL（总结阻塞关系）并询问："下一个 issue，还是我们完成了？"
5. 继续会话
持续进行直到用户说他们完成了。每个 issue 都是独立的——不要批量处理它们。