QA会话

针对用户提出的每个问题

1. 倾听并适度澄清

• 预期结果与实际发生情况的差异
• 重现步骤（如果不明确）
• 问题是持续出现还是间歇性的

2. 在后台探查代码库

• 学习该区域使用的领域术语（可查看UBIQUITOUS_LANGUAGE.md）
• 理解功能的预期用途
• 明确用户可见的行为边界

3. 评估范围：单个问题还是拆分问题？

• 修复工作涉及多个独立领域（例如：“表单验证错误、成功消息缺失且重定向失效”）
• 存在明显可分离的关注点，不同人员可并行处理
• 用户描述的问题包含多种不同的故障模式或症状

• 仅一处行为出现错误
• 所有症状均由同一根源行为导致

4. 创建GitHub Issue(s)

gh issue create

单个问题的情况

## 问题现象

[用平实语言描述用户遇到的实际行为]

## 预期结果

[描述预期的行为]

## 重现步骤

1. [开发者可遵循的具体、编号步骤]
2. [使用代码库中的领域术语，而非内部模块名称]
3. [包含相关输入、标志或配置]

## 额外上下文

[来自用户或代码库探查的额外观察信息，帮助理解问题——例如：“仅在使用Docker层时出现，文件系统层无此问题”——使用领域术语，但不要引用文件]

拆分问题的情况

## 父级Issue

#<父级Issue编号>（如果创建了跟踪Issue）或“QA会话期间报告”

## 问题内容

[描述该具体行为问题——仅针对此部分，而非整个报告]

## 预期结果

[针对此部分的预期行为]

## 重现步骤

1. [针对此Issue的具体步骤]

## 依赖阻塞

- #<Issue编号>（如果此问题需等待其他问题修复后才能解决）

若无阻塞，填写“无——可立即开始处理”

## 额外上下文

[与该部分相关的额外观察信息]

• 宁多勿少——每个Issue应可独立修复和验证
• 如实标记依赖关系——如果Issue B确实需在Issue A修复后才能测试，如实标注。若两者独立，则均标记为“无——可立即开始处理”
• 按依赖顺序创建Issue——以便在“依赖阻塞”部分引用真实的Issue编号
• 最大化并行性——目标是让多个人（或Agent）可同时处理不同的Issue

所有Issue内容的规则

• 不包含文件路径或行号——这些信息会过时
• 使用项目的领域术语（若存在UBIQUITOUS_LANGUAGE.md可参考）
• 描述行为而非代码——例如：“同步服务无法应用补丁”而非“applyPatch()在第42行抛出异常”
• 重现步骤为必填项——若无法确定，询问用户
• 保持简洁——开发者应能在30秒内读完Issue

5. 继续会话