easysdd-issue-report
这一阶段做两件事：把用户脑子里的问题落成结构化记录，顺便判断这个问题该走标准路径还是快速通道。
写报告的部分有一条核心原则：只记现象不记根因。用户开始说"我觉得是 XX 组件的问题"时——记下"用户怀疑 XX 组件"作为线索，但不要顺着聊根因。根因要在阶段 2 通过实际读代码确认，不靠脑子里的猜测。混进根因猜测的报告会带偏阶段 2 的分析方向，让分析人围着错误线索绕。
共享路径与命名约定看easysdd/reference/shared-conventions.md第 0 节和easysdd-issue的"文件放哪儿"节。
启动检查
1. 确认是 bug 不是新功能需求
如果用户描述的是"想加一个 X 功能"，告诉他走 easysdd-feature 工作流（由根技能路由到合适的阶段）。
2. 看有没有相关 issue 目录
Glob easysdd/issues/ 下的子目录，看有没有同类问题已经记录过。有的话先和用户确认是新建还是更新已有 report。
3. 快速通道判断（这是唯一正式判定点）
根据用户描述的线索先读一下相关代码（用 Grep / Read 定位），判断能不能一眼确定根因：
- 能——根因明确（能给出
{文件}:{行号}）、修复改动小（1-2 处）、无跨模块影响风险 → 告诉用户："我已经看到问题所在，可以走快速通道：直接告知根因和修复方案，你确认后我立刻修，修完你验证，然后只写一份{slug}-fix-note.md。" 用户同意后触发easysdd-issue-fix（快速通道模式）。 - 不能——根因有多个候选 / 不确定 / 需要更多复现信息 → 继续走下面的标准路径，做完整问题报告。进入标准路径后默认不再二次改判。
4. 确定 issue 目录名
跟用户商定 slug，日期前缀用今天的日期（从环境信息查 currentDate）。目录不存在就创建。快速通道也要建 issue 目录，{slug}-fix-note.md 放在那里。
必答 5 问
按顺序逐个问，不要一次抛 5 个——一次抛多个问题用户大概率只回最容易的，深的就漏了。每个问题做一次模糊度检查，不通过继续追问。
1. 问题是什么？能描述一下你看到的现象吗？
期待具体的异常表现："点击提交按钮后弹出了空白弹窗"比"提交功能有问题"有用一百倍。
模糊信号："有时候会出错"、"感觉不对" → 追问"具体什么时候"、"具体什么不对"。
红线：不要让用户描述根因。出现"应该是因为 XXX"、"可能是 YYY 导致的"——记现象，根因留给阶段 2。
2. 怎么复现？
期待一组最小复现步骤。例如：
- 进入 XX 页面
- 输入 YY 内容
- 点击 ZZ 按钮
- 看到问题现象
模糊信号："不稳定复现"、"有时候能有时候不能" → 追问复现频率和条件差异（"什么情况下能复现"）。如果确实不稳定，写明已知触发条件和复现率。
"无法复现"也是有效回答——写明"目前无法稳定复现，只在 X 情况下观察到一次"，别勉强凑步骤。
3. 期望行为 vs 实际行为
期待两句话：
- 期望：我以为做了 A 之后应该发生 B
- 实际：但实际发生的是 C
不要合并成一句。期望和实际显式分开写，审查者才能快速判断问题边界——合在一句"按钮没正常工作"里，分析的人不知道你期望的"正常"长什么样。
4. 环境信息
最低要整理：在哪个模块 / 功能区域发现的、相关文件或函数（如果用户知道）。
可选但有价值：操作系统、浏览器版本、运行环境（dev / prod）、最近有没有改过相关代码。
如果用户说"我不知道在哪个文件"——没关系，写"待定"，阶段 2 分析时会查。
5. 严重程度与优先级
参考标准（给用户选）：
- P0 - 阻塞：核心功能完全失效，影响所有用户，必须立刻修
- P1 - 严重：核心功能受损，有绕过方法，需要尽快修
- P2 - 中等：非核心功能受损或影响少数用户，计划内修
- P3 - 轻微：UI 瑕疵、边界情况、有更好的实现，按空闲修
用户不确定就帮他根据前几问的描述推荐一个，但让用户最终拍板。
问题报告模板
回答完后写进文件（路径见 easysdd-issue 的"文件放哪儿"节）：
---
doc_type: issue-report
issue: {issue 目录名}
status: draft
severity: P0 | P1 | P2 | P3
summary: {问题现象一句话}
tags: []
---
# {问题简述} Issue Report
## 1. 问题现象
{用户描述的具体异常表现，纯现象描述，不含根因推测}
## 2. 复现步骤
1. {步骤 1}
2. {步骤 2}
3. {步骤 3}
4. 观察到：{问题现象}
复现频率：{稳定复现 / 概率复现（约 X%） / 暂无法稳定复现}
## 3. 期望 vs 实际
**期望行为**：{做了 A 应该发生 B}
**实际行为**：{但实际发生了 C}
## 4. 环境信息
- 涉及模块 / 功能：{模块名或功能描述}
- 相关文件 / 函数：{已知文件:行号，或"待定"}
- 运行环境：{dev / staging / prod / 不确定}
- 其他上下文：{OS、浏览器、最近改动等，没有就写"无"}
## 5. 严重程度
**{P0 / P1 / P2 / P3}** — {一句话说明理由}
## 备注
{可选：用户额外补充的上下文、截图描述、日志片段等}退出条件
写完文件后跟用户做一次"出阶段 1"确认：
- YAML frontmatter 存在，
doc_type=issue-report、issue跟当前 issue 目录一致、severity和summary非空、tags至少 1 个 - 5 个问题都有具体答案，没有"待定"（环境中的相关文件可以是"待定"）
- 问题现象是纯现象描述，没混入根因推测
- 期望 vs 实际显式分开写
- 复现步骤可执行（哪怕是"暂无法稳定复现"也有说明）
- 用户明确说"report 可以了，进下一步"
- 用户确认后，frontmatter 的
status已改成confirmed
退出后
告诉用户："问题报告已就绪。下一步是阶段 2：根因分析。可以触发 easysdd-issue-analyze 技能开始分析。"
别自己顺手开始分析根因——阶段间的人工 checkpoint 是工作流的硬约束。
容易踩的坑
- 用户说"可能是 XX 组件的问题"，你顺着聊起根因——错，那是阶段 2，现在只问"看到什么现象"
- 复现步骤太模糊（"在用户界面操作一下"）就放行——逼出可执行的步骤
- 期望行为和实际行为混在一段话里——必须显式分开
- 严重程度留空——给个默认值或写"无"，但别空着
- 一口气把 5 个问题列成清单丢给用户填——逐题对话，否则深的全漏