qa

QA 会话

运行交互式 QA 会话。用户描述他们遇到的问题。你负责澄清问题、探索代码库以了解背景，并提交持久、以用户为中心且使用项目领域术语的 GitHub issue。

针对用户提出的每个问题

1. 倾听并适度澄清

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

• 用户预期的结果与实际发生的情况
• 复现步骤（如果不明显）
• 问题是稳定出现还是间歇性出现

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

2. 在后台探索代码库

与用户交流时，在后台启动一个 Agent（subagent_type=Explore），了解相关领域。目标不是寻找修复方案，而是：

• 了解该领域使用的术语（查看 GLOSSARY.md）
• 理解该功能应该如何工作
• 确定面向用户的行为边界

这些背景信息有助于你写出更好的 issue，但 issue 本身不应提及具体文件、行号或内部实现细节。

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

提交前，判断这是一个单个 issue，还是需要拆分为多个 issue。

以下情况应拆分：

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

以下情况应保留为单个 issue：

• 同一处的某个行为有误
• 所有症状都由同一个根本行为导致

4. 提交 GitHub issue

使用 gh issue create 创建 issue。不要先让用户审核，直接提交并分享 URL。

Issue 必须持久有效，即使经过重大重构，仍然有意义。请从用户的角度撰写。

单个 issue

使用此模板：

## 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]

拆分（多个 issue）

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

每个子 issue 使用此模板：

## 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]

拆分时：

• 优先创建多个精简 issue，而不是少数内容庞杂的 issue——每个 issue 都应能独立修复和验证
• 如实标明阻塞关系——如果修复 issue A 之前确实无法测试 issue B，请说明。如果两者相互独立，则都标注为“None — can start immediately”
• 按依赖顺序创建 issue，以便在“Blocked by”中引用真实的 issue 编号
• 最大限度提高并行性——目标是让多个人员（或 Agent）可以同时处理不同的 issue

所有 issue 内容均须遵守的规则

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

提交后，打印所有 issue URL（并概述阻塞关系），然后询问：“下一个问题，还是我们就到此为止？”

5. 继续会话

持续进行，直到用户表示结束。每个问题都是独立的，不要将它们批量处理。