qa

QA 会话

开始一次交互式 QA 会话。用户描述他们遇到的问题。你负责澄清、了解代码库上下文，并提交持久有效、以用户为中心且使用项目领域术语的 GitHub 问题。

用户提出的每个问题

1. 倾听并适度澄清

让用户用自己的话描述问题。最多提出 2-3 个简短的澄清问题，重点关注：

• 预期结果与实际结果
• 复现步骤（如果不明显）
• 是稳定发生还是间歇性发生

不要过度追问。如果描述已足够清晰，可以提交，就继续下一步。

2. 在后台探索代码库

在与用户沟通的同时，在后台启动一个 Agent (subagent_type=Explore)，以了解相关区域。目标不是寻找修复方案，而是：

• 学习该区域使用的领域术语（检查 UBIQUITOUS_LANGUAGE.md）
• 了解该功能应有的行为
• 确定面向用户的行为边界

这些上下文有助于写出更好的问题，但问题本身不应引用具体文件、行号或内部实现细节。

3. 判断范围：单个问题还是拆分？

提交前，判断这应是单个问题，还是需要拆分为多个问题。

在以下情况下拆分：

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

在以下情况下保留为单个问题：

• 某个位置上的单一行为有误
• 所有症状均由同一根本行为导致

4. 提交 GitHub 问题

使用 gh issue create 创建问题。不要先请用户审核——直接提交并分享 URL。

问题必须持久有效——即使经过大规模重构后仍然说得通。以用户视角撰写。

单个问题

使用此模板：

## What happened

[Describe the actual behavior the user experienced, in plain language]

## What I expected

[Describe the expected behavior]

## Steps to reproduce

1. [Concrete, numbered steps a developer can follow]
2. [Use domain terms from the codebase, not internal module names]
3. [Include relevant inputs, flags, or configuration]

## Additional context

[Any extra observations from the user or from codebase exploration that help frame the issue — e.g. "this only happens when using the Docker layer, not the filesystem layer" — use domain language but don't cite files]

拆分为多个问题

按依赖顺序创建问题（先创建阻塞项），以便引用真实的问题编号。

每个子问题使用此模板：

## Parent issue

#<parent-issue-number> (if you created a tracking issue) or "Reported during QA session"

## What's wrong

[Describe this specific behavior problem — just this slice, not the whole report]

## What I expected

[Expected behavior for this specific slice]

## Steps to reproduce

1. [Steps specific to THIS issue]

## Blocked by

- #<issue-number> (if this issue can't be fixed until another is resolved)

Or "None — can start immediately" if no blockers.

## Additional context

[Any extra observations relevant to this slice]

拆分问题时：

• 优先拆成多个范围小的问题，而不是少数范围大的问题——每个问题都应能独立修复和验证
• 如实标记阻塞关系——如果问题 B 在问题 A 修复前确实无法测试，就说明这一点。如果两者相互独立，则将两者都标为“无——可立即开始”
• 按依赖顺序创建问题，以便在“被阻塞于”中引用真实的问题编号
• 最大化并行处理——目标是让多个人员（或 Agent）能够同时领取不同的问题

所有问题正文规则

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

提交后，输出所有问题 URL（并总结阻塞关系），并询问：“下一个问题，还是到此为止？”

5. 继续会话

持续进行，直到用户表示完成。每个问题都是独立的——不要批量处理。