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。