已有多次 dbs-save 诊断存档时，用…

当同一项目下积累了多份 dbs-save 存档，用户要求汇总诊断、整理报告或生成可分享材料时，把它们按时间合并、去重、分类成一份可追溯的 Markdown 诊断报告。

适用场景

解决思路

1. 跟用户对话一律用中文，并统一措辞：snapshot 称为「存档」，session 称为「对话」或「下次回来」，slug 称为「项目」；frontmatter 字段名（status / title / source_skill / next_skill）和文件路径中的 sessions / slug 不暴露给用户。
2. 收到 /dbs-report 时，把当前项目下所有存档合并成报告。
3. 收到 /dbs-report --since YYYY-MM-DD 时，只合并某日期之后的存档。
4. 收到 /dbs-report --slug <项目名> 时，指定项目。
5. 收到 /dbs-report --slug <项目名> --since YYYY-MM-DD 时，同时指定项目与日期范围。
6. 收到「出报告」「打包」「整理一份」「给合伙人看的」时，等价于 /dbs-report。
7. 读取当前工作目录下的 .dbs/config.json，并与 dbs-save 使用同一套解析规则。
8. 配置文件不存在，或 mode 是 default 时，存档根目录为 ~/.dbs/。
9. mode 是 project 时，存档根目录为当前工作目录下的 .dbs/。
10. mode 是 custom 时，存档根目录为 root 指定的目录；展开开头的 ~，相对路径按当前工作目录解析。
11. 配置无法解析、mode 不受支持、root 为空，或路径指向 /、用户家目录、当前项目根目录时，停止生成报告并说明配置问题；不要到其他位置猜测，也不要静默退回默认位置。
12. dbs-report 只读取配置，不修改配置；用户要查看或调整位置时，引导使用 /dbs-save location。
13. 将后文中的 {存档根目录} 视为解析出的绝对路径。
14. Step 1：按项目找 {存档根目录}/sessions/{项目名}/*.md。
15. Step 1：找到 0 个文件时，提示「{项目名} 下还没有可汇总的存档。输入 /dbs 开始处理真实任务；形成结论并明确保存后，再回来生成报告。」
16. Step 1：找到 1 个文件时，提示「{项目名} 下只有 1 份存档，单份不需要合并报告。直接看 {存档根目录}/sessions/{项目名}/{文件名} 就行。」并询问是否强制出报告；用户说要则继续。
17. Step 1：找到 ≥2 个文件时，直接进入合并。
18. Step 1：如果带了 --since，先按日期过滤；过滤后剩下的文件不到 2 份时，按 0 份或 1 份的规则处理。
19. Step 2：按文件名 YYYYMMDD-HHMMSS 排序，早 → 晚。
20. Step 2：每个文件解析 frontmatter 字段：slug / timestamp / title / source_skill / status / next_skill。
21. Step 2：每个文件解析 body 6 段：用户主诉 / 已得出的结论 / 用户已否决的方向 / 待验证假设 / 推荐下一步 / 备注。
22. Step 2：如果某份存档格式有缺失，尽量用现有字段，不要因此中断报告生成。
23. Step 3：拼路径 {存档根目录}/reports/{项目名}/{YYYYMMDD-HHMMSS}-{项目名}.md。
24. Step 3：每次新生成一份，永不覆盖；文件名带时间戳，方便对比不同时点的诊断快照。
25. Step 3：如果目录不存在，先 mkdir -p。
26. Step 4：报告头部写「# {项目名} 商业诊断报告」，并包含生成时间（当前本地时间 YYYY-MM-DD HH:MM）、累积存档 N 份（最早日期，最新日期）、主要走过的 skill（所有 source_skill 字段去重后列出）、生成工具 dbskill / dbs-report。
27. Step 4：写第一段「用户主诉的演进」：按时间顺序列出每份存档的主诉，每条一行，格式为 - `日期` · {主诉简化版，一句话} · 来自 {source_skill}。
28. Step 4：第一段末尾用一段话点出关注点是怎么变的，例如从「卖什么」演进到「卖给谁」再到「怎么获客」；只描述演进路径本身，不引申、不推测、不发挥。
29. Step 4：写第二段「已确认的结论」：合并所有存档里的「已得出的结论」字段，语义相近的合并去重，按时间倒序，新结论在前。
30. Step 4：已确认结论的格式为 - {结论原文} · 出自 {对应存档的标题} · {对应日期}。
31. Step 4：如果一条结论在后续存档里被推翻或修正，两条都列出来，新的在前，旧的在后并加（已被后续诊断修正）标注。
32. Step 4：写第三段「已否决的方向」：合并所有存档里的「用户已否决的方向」字段。
33. Step 4：已否决方向的格式为 - {方向} —— 否决理由：{理由} · 出自 {存档标题} · {日期}。
34. Step 4：如果没有任何否决方向，写「（暂无）」。
35. Step 4：写第四段「当前未解决的问题」：合并 status 是 in-progress 的存档的「待验证假设」字段，以及在最早存档中提出但从未在后续存档中被处理的方向。
36. Step 4：未解决问题的格式为 - {问题/假设原文} · 首次出现 {日期} · 当前状态：{进行中 / 待验证}。
37. Step 4：写第五段「推荐下一步」：汇总所有存档的「推荐下一步」字段 + next_skill 字段。
38. Step 4：推荐下一步按优先级排：最新存档推荐的下一步最优先；反复出现但还没走的推荐；早期推荐但已经被新推荐替代的标注「已被后续推荐替代」。
39. Step 4：推荐下一步用一段话写出来，不要列点；一段话讲清下一步该做什么、为什么、对应哪个 skill。
40. Step 4：写第六段「附录：存档索引」：按时间正序列出所有存档文件，表格列为 日期 / 标题 / 状态 / source_skill / 文件。
41. Step 4：存档索引中的状态字段对用户展示时翻译成中文：进行中 / 已结论 / 已放弃。
42. Step 4：报告尾部写：报告由 dbskill 自动生成；原始存档见 {存档根目录}/sessions/{项目名}/；如需更新报告，再次运行 /dbs-report。
43. Step 5：写完后给用户一段回执：报告已生成：{存档根目录}/reports/{项目名}/{文件名}；合并了 {N} 份存档（{起始日期} → {结束日期}）。
44. Step 5：如果用户需要把报告发布到公众号或群里，加一句：想发公众号或群里，可以用 /dbs-wechat-html 把这份 markdown 转成微信后台粘贴版；用户没有发布需求时不加。
45. 关键原则：不从对话凭空总结；报告内容必须能追溯到具体存档文件的具体字段。
46. 关键原则：永不覆盖；每次生成新文件，带时间戳，用户可以对比不同时点的诊断。
47. 关键原则：不发挥；用户主诉的演进段落允许简短总结，其他全部直接搬运存档字段。
48. 关键原则：不主动出 PDF / HTML / 其他格式；只生成 markdown，用户要别的格式自己处理。
49. 边界情况：存档文件里有用户标的敏感信息（比如真实收入、客户名字）时，报告原样保留，不做脱敏；要脱敏在 dbs-save 阶段做。
50. 边界情况：多份存档之间结论冲突时，都列出来，新的在前并标注修正关系。
51. 边界情况：用户在 {存档根目录}/sessions/ 之外手动放了个文件时，不读；只读当前配置对应的 sessions 目录。
52. 边界情况：当前存档位置为空，但用户确认以前存过时，显示当前存档根目录，引导用户用 /dbs-save location 检查设置；不要跨目录自动搜索私人文件。
53. 边界情况：存档跨年（最早 2025、最新 2026）时，报告头部明确写出时间跨度。
54. 说话风格：回执只一段，包含文件路径 + 合并数量 + 时间跨度，不展开介绍。
55. 说话风格：不要解释报告里写了什么；用户自己会打开看。
56. 说话风格：绝对不在报告 markdown 里加感叹号、表情、鼓励语；这是给客户看的产物，不是给当前用户煽情。
57. 语言：用户用中文就用中文回复，用英文就用英文回复。
58. 语言：中文回复遵循《中文文案排版指北》。
59. 语言：报告本身用存档里的语言（如果存档是中文，报告就是中文）。
60. 完成当前任务后直接结束；只有用户明确询问下一步，且当前环境已经安装 /dbs 时，简短提示：「下一步不确定时，可以输入 /dbs。」

适用边界 · 注意事项

• 同一项目下只有 0 份或 1 份存档，且用户不要求强制生成报告时，不生成合并报告。
• 无法解析 .dbs/config.json、mode 不受支持、root 为空，或路径指向 /、用户家目录、当前项目根目录时，停止生成报告并说明配置问题。
• 没有 dbs-save 留下的存档文件时，不凭对话内容凭空写报告。