solve-workflow

八阶段问题解决工作流

一个八阶段 PDCA 流程。第 1、3、4、5 阶段为只读。第 2 阶段的分析方法位于 analysis-core（包括临时变更门禁）。默认采用手动模式；说“自动模式”或“自动分析”即可自动运行完整流程。完成后进入第 7 阶段；如果第 8 阶段得出的结论是目标未达成，则返回“分析问题”／“探索方案”／“审查方案”进行下一轮。 输出模板：各阶段的输出格式见 reference.md。

调用约定

• 触发词（按 description）：明确问题、分析问题、探索方案、审查方案、制定计划、执行计划、检查验证、复盘改进（别名：回顾总结）；继续分析、深入分析、修改方案、完善方案、优化方案、更新计划、修订计划、修改计划；自动模式、自动分析、自动解决；ai-proxy 模式、AI 代理模式、切换 ai-proxy
• 命令形式：/solve-workflow xxx、/solve xxx，其中 xxx 是后续内容
• 默认行为：当 xxx 不含上述任何触发词时，默认进入第 1 阶段（明确问题），将 xxx 视为待分析的问题描述
• 匹配规则：只要触发词出现在 xxx 的任意位置，就视为匹配 — 无需完全符合原句
• 不适用情形：单步编辑（例如重命名一个变量），或用户只想要快速建议而非完整流程时，跳过此工作流，直接处理

强依赖项（frontmatter dependencies；启动时必须通过下方的前置技能检查，否则流程中止）：

• staged-review-flow（第 4 阶段的审查编排；依赖 solution-review 和 code-design-review）
• hybrid-debug / runtime-evidence-debug / browser-debug-toolkit（通过 analysis-core 委派使用的调试技能；第 2 阶段 + 第 7 阶段）
• analysis-core（第 2 阶段方法的唯一事实来源：临时变更门禁／默认入口为 runtime-evidence-debug 的插桩调试／分析步骤骨架／分析门禁输出块／调试验证循环）
• learn-and-improve（第 8 阶段的复盘与知识沉淀）
• workflow-mode-lifecycle（手动／自动模式生命周期）、clarifying-question-discipline（严格的澄清问题规范和调查优先原则）、known-issue-research（第 2 阶段的研究路由／已知问题快速搜索／行业范围评估）、competitive-research（分析期间对用户可见的竞品行为；方法保留在该技能中）
• test-suite-ensure（第 6 阶段的测试完成：存在测试基础设施时生成并运行测试；不存在时经用户确认后搭建）
• test-first-discipline（第 6 阶段：行为变更先编写失败测试；与 test-suite-ensure 不同）
• design-approval-gate（第 6 阶段之前：未经批准不得进行生产实现；设有明确命名的自动／热修复例外）
• delivery-discipline（第 8 阶段：结束前可选择提交，并新建／更新 PR/MR；并非每次运行都会交付）
• feature-branch-closeout（第 8 阶段：验证后的分支处理菜单；使用合并时委派给 merge-discipline）
• decision-fog-discipline（探索方案之前：先消除模糊之处／创建决策工单）
• git-worktree-discipline（第 6 阶段之前：工作树门禁 + 可选的隔离工作区）
• domain-language-discipline（明确／分析问题：涉及领域术语时使用项目术语表／CONTEXT.md）
• node-version-discipline（第 7 阶段运行测试前对齐 Node 版本）
• figma-pixel-implement / figma-pixel-verify（忠实还原 Figma 导出稿并进行测量验证；必须已安装；当目标、卡片、问题或计划中包含 figma.com 或 node-id=，或用户要求按像素还原时调用）

相关技能（仅供参考，不是强依赖项）：perf-optimize-workflow（专用性能优化范式）、jira-fix-workflow（包含此工作流的端到端 Jira 修复流程）

前置技能检查

启动时，在进入阶段 1 之前，针对 frontmatter dependencies 中声明的每一项强依赖执行此检查。

1. 扫描可用技能（检查 <available_items> 或使用 skill 工具）
2. 全部存在 → 继续
3. 存在缺失项 → 打印缺失依赖通知（格式见 reference.md § 前置技能检查 — 缺失通知），并立即中止

禁止降级原则：缺失强依赖时必须中止流程，绝不能回退到简化版审查。这样可以确保 solve-workflow 在所有环境中的审查深度一致。

---

触发条件与模式

表述	模式	说明
"分析问题", "探索方案", /solve xxx	👤 手动	默认模式；各阶段之间暂停并等待确认
"自动分析 xxx", "自动解决 xxx", "自动模式"	🤖 自动	无需确认，运行完整流程
"ai-proxy 模式", "AI 代理模式", "切换 ai-proxy"	overlay	自动承载模式；先进行轻量冻结，再按 ai-proxy-discipline 接管

模式检测：overlay 触发条件（「ai-proxy 模式」「AI 代理模式」「切换 ai-proxy」 / "ai-proxy mode" / "switch to ai-proxy"）根据 workflow-mode-lifecycle 请求 overlay — 如果同时出现自动触发条件和 overlay 触发条件，则优先执行 overlay+freeze，而不是单独自动模式。否则，包含“自动”（auto）的触发条件会选择自动模式；其他情况为手动模式。运行期间可使用：“切换自动模式” / “切换手动模式” / “切换 ai-proxy”。👤 手动模式在每个阶段结束时暂停并等待确认；🤖 自动模式会持续推进，只有在阶段 4 的审查循环超过 3 轮时才会暂停；overlay 会在轻量冻结后，按照 ai-proxy-discipline 接管这些阶段出口。

模式生命周期

核心规则（自动模式始终恢复为手动模式 / 仅允许显式重新进入 / 隐式继续永不重新激活 / 批处理场景）位于强依赖 workflow-mode-lifecycle 中（前置检查保证其可用），此处不再重复。solve-workflow 特定规则：“完整流程完成”指阶段 8 正常结束（包括在阶段 3/4 回到新的 PDCA 循环，默认切换为手动模式）。失败中止、用户主动停止，以及审查轮数上限暂停后终止，均视为中断并恢复为手动模式。

---

⚡ 快速参考（执行前阅读；阶段变更时同步更新）

本表概述各阶段的关卡；规则细节以各阶段正文为准。

阶段	工具权限	👤 手动停止点	必需输出
1 澄清问题	❌ Read/Grep（阶段 1 正文中的例外情况除外）	⛔ 输出后停止，等待确认	问题重述 / 关键要素 / 待解问题
2 分析问题	根据 analysis-core（Read/Grep/WebSearch；Edit/Write 仅限 analysis-assist）	继续进入阶段 3	是否存在 / 根因 / 影响 / 临时变更回滚验证（格式遵循 analysis-core）
3 探索方案	✅ Read；❌ Edit/Write	对比表完成后停止，等待用户选择	方案对比表（≥2 个选项）
4 审查方案	✅ Read；❌ Edit/Write	审查报告完成后停止，等待用户判定	审查报告 + 通过/未通过
5 制定计划	✅ Read；❌ Edit/Write/Bash	计划完成后停止，等待确认	文件变更清单 + 顺序
6 执行计划	✅ 全部	执行顺利完成后自动进入阶段 7	执行报告
7 验证	✅ Bash；❌ Edit/Write	结果完成后停止，等待确认	验证结果
8 回顾总结	❌ Edit/Write（除非用户确认编写、交付或启动新循环）	结束 / 或回到阶段 3/4	可选交付内容 + 收尾 + 改进建议

---

通用原则

⚠️ 澄清问题

⚠️ 遵循 clarifying-question-discipline（每轮只问一个问题；不清楚时进行多轮澄清；先澄清，不要急于作答）。涉及领域术语时，还需遵循 domain-language-discipline（术语表 / CONTEXT.md）。

---

路径选择

根据任务复杂度选择路径，并在阶段 1 确认问题时声明：

路径	适用情况	要求
完整	新功能开发、多模块协作、需求不明确	完整执行阶段 1–8
增量	修改现有代码的行为、重构、常规 Bug	执行阶段 1–8，但解决方案和计划可以精简
精简	热修复、单文件且高度确定的更改	精简输出；1 个解决方案加一条风险说明即可，计划可以并入解决方案描述。绝不跳过阶段 7/8

如果执行过程中范围扩大，请升级路径：精简 → 增量，增量 → 完整。在手动模式下，升级需要获得用户确认。

精简路径下，阶段 3（探索解决方案）可以只输出 1 个解决方案加一条风险说明，阶段 5（制定计划）可以并入解决方案描述。绝不跳过阶段 7（验证）和阶段 8（回顾）。

---

无人值守代理退出

如果本次运行契约或任务卡记录了 Stage-exit policy: ai-proxy（自动承载；队列子任务足够，但并非必需），则上述每个手动停止点都会根据 ai-proxy-discipline 成为代理检查点。精简冻结（口头触发 ≠ 已入驻）在此生效。在执行前审批点，代理的有界预授权将取代 design-approval-gate 中单纯的自动放行；合并、不可逆操作和受保护分支的决策仍仅由人工处理（遇到此类情况时暂停并创建工单）。其他任何策略值或未设置策略 → 行为与当前完全一致。

停止点预测：如果本次运行开始时已有冻结契约（含问题和冻结决策的队列子任务，或已写入的独立精简冻结），则在分析前先给出预测——逐一列出每个手动退出点，注明是已由冻结决策覆盖，还是会新建工单。如果在运行中途请求叠加层，则在精简冻结后预测剩余退出点，然后继续当前阶段（不要从分析重新开始）。

阶段 1：明确问题

⚠️ 在此阶段禁止编辑/写入。仅输出你对问题的理解——不要修改任何文件。

原则：先明确问题，再进行技术分析；此阶段仅用于就问题达成一致，不涉及实现逻辑。

领域路由：如果问题属于性能领域（缓慢 / 卡顿 / 资源增长），建议进入 perf-optimize-workflow——其基于证据门控的范式适用于该领域；其分析结果可回流到此工作流以执行修复。注意：其优化活动会创建项目级产物（基准测试日志 + 测试框架，以及预置的 code-insight/code-optimizer 技能）；优化-验证循环还需要环境循环运行器——分析阶段始终会运行。这只是参考信息，并非依赖项。

[🤖 自动] 跳过此阶段，直接进入阶段 2，并将用户输入视为已确认的问题描述。

[👤 手动] 必须完成此阶段并经用户确认后，才能进入阶段 2。

1. 重述问题——用你自己的话描述用户的问题
2. 提取关键要素——目标、约束、背景、预期结果
3. 列出待确认问题——需要确认的事项；如果要询问用户，每次只问最关键的一个问题（参见“通用原则”中的严格要求），得到回答后再问下一个问题
4. 拆分范围（如适用）——当问题涉及多个相互独立的子系统（例如“聊天 + 文件存储 + 计费”）时，先协助拆分：独立模块、依赖关系、建议顺序——然后分析第一个子问题。此步骤仍属于阶段 1：不得主动探索代码；可以阅读用户已引用的内容，拆分主要依据用户的描述。
5. 等待用户确认

工具限制：禁止使用 Read/Grep/SemanticSearch，但以下情况除外：

• 用户消息中包含 @file-path（可选带行号，例如 @SKILL.md:83-89）
• 用户粘贴了代码片段
• 用户明确指出了“函数/类 + 所在文件”

符合例外情况时：只读取用户直接引用的文件和行——不要扩展到其他文件。 读取结果仅用于理解问题——此阶段输出中不得出现技术分析结论。

输出格式

输出格式见 reference.md § 阶段 1 — 明确问题。

⛔ [手动模式 — 阶段 1 结束] 输出此内容后立即停止，等待用户明确确认理解无误后再进入阶段 2。 🤖 [自动模式] 跳过阶段 1，直接从阶段 2 开始。

危险信号

• 在阶段 1 完成前，用户未引用任何内容时使用 Read/Grep 探索代码
• 因为“用户已经说得足够清楚”而跳过阶段 1
• 以“边澄清边分析”为由，在阶段 1 完成前探索代码
• 以“先看看代码再确认”为由，在阶段 1 完成前探索代码
• 在阶段 1 的“问题重述”或“待确认问题”中混入技术分析结论（根因判断、修复建议）
• 在阶段 1 一次性向用户提出多个待确认问题（违反“澄清问题”的严格要求）——每次只问最关键的一个问题，得到回答后再问下一个

上述任何行为都会违反此阶段的约定。[👤 手动] 必须完成阶段 1 并经确认后才能进入阶段 2。[🤖 自动] 跳过阶段 1 不受此限制。

---

阶段 2：分析问题

方法论的唯一事实来源：analysis-core。此阶段不会留下任何实现变更——修复属于阶段 6。

委派给 analysis-core

加载强依赖 analysis-core 并运行其 §§1–3。此工作流的映射（编号 + 名称）：

• {next-stage} = 阶段 3「探索解决方案」
• {root-cause step} = 步骤 5「根本原因」；{impact-assessment step} = 步骤 7「影响」；{upstream-eval step} = 步骤 6「上游依赖修复评估」

输出格式遵循 analysis-core 和 known-issue-research/reference.md；输出必须以分析门控输出块（analysis-core §5）结尾——缺少该块将阻止进入阶段 3。如果做过任何临时更改，须在该块的临时更改行中列出更改并附上回滚验证。当预期结果是用户可见或可操作的内容时，同一次加载还要运行 competitive-research，具体按 analysis-core 执行。不要复述其方法。

---

阶段 3：探索解决方案

原则：基于阶段 2 的分析，提供 2–5 种解决方案；剔除非必要功能和过度设计（YAGNI）。如果方向仍不明确，在解决方案表之前遵循 decision-fog-discipline。

架构边界预检（决策顺序）：当候选解决方案跨越进程或层级边界时，先回答预检问题，再权衡短期成本（更改规模／复用／单仓库）——（1）运行时初始化位置：哪个进程／层级负责初始化被调用的能力；（2）边界合法性：跨层导入是否会将被调用方的依赖树拉入调用方的打包器依赖图（打包器的静态预扫描会使动态 require／import 无法作为变通方法）；（3）所有权分类：系统能力、数据／产品能力，还是调用层的定位。边界判定须通过比较表体现，并作为自动模式选择的门槛。方法论：code-design-review 的 A 层依赖方向维度。单层解决方案无需触发此预检。

[🤖 自动模式] 解决方案选择

自动生成 2–5 种解决方案；AI 推荐并选择最佳方案（优先级：更彻底的修复 > 符合最佳实践 > 提升代码质量 > 更小的改动），然后直接进入阶段 4。

[👤 手动模式] 解决方案选择

输出解决方案比较表，并等待用户选择后再进入阶段 4。

输出格式

1. 开篇：解决方案列表（每项包含编号 + 名称）
2. 中间部分：详细展开每种解决方案（见下方「每种解决方案均须包含」）
3. 结尾：解决方案比较表（仅出现一次，且紧邻决策点）

解决方案	描述	优点	缺点	复杂度	推荐度
解决方案 1	...	...	...	低/中/高	⭐⭐⭐⭐⭐
解决方案 2	...	...	...	低/中/高	⭐⭐⭐

每种解决方案均须包含

• 核心思路（1–2 句话）
• 要更改的文件／模块
• 实施难度、潜在风险、适用场景

工具限制：禁止使用 Edit/Write；允许使用 Read 检查代码细节

⛔ [手动模式——阶段 3 退出] 比较表后立即停止，等待用户选择解决方案编号后再进入阶段 4。 🤖 [自动模式] 自动选择最佳解决方案并直接进入阶段 4。

危险信号

• 只提供 1 种解决方案，并以「方向已经很明确」为由跳过比较
• [👤 手动] 用户尚未选择解决方案就进入评审

---

阶段 4：评审解决方案

加载 staged-review-flow 并运行其完整评审约定。此工作流的映射：{next-stage} = 阶段 5「制定计划」；{artifact-sink} = 阶段 4 评审报告（格式见 reference.md）；{extra-dimensions} = 无；{batch-overcap-behavior} = N/A。工具限制：禁止使用 Edit/Write；允许使用 Read 检查代码细节。

---

阶段 5：制定计划

原则：制定详细、可执行的修改计划——仅输出计划文本，不执行任何代码更改。

1. 目标方案回顾 — 已审查并确认方案的核心思路
2. 文件变更清单 — 文件路径、位置和具体变更说明
3. 变更顺序 — 根据依赖关系确定执行顺序

输出格式

输出格式见 reference.md § 阶段 5 — 制定计划。

工具限制：禁止使用 Edit/Write/Bash；允许使用 Read 确认细节

⛔ [手动模式 — 阶段 5 退出] 计划完成后立即停止，等待用户确认后再进入阶段 6。 🤖 [自动模式] 自动确认并直接进入阶段 6。

更新计划（子阶段）

当用户说“更新计划”／“修订计划”／“修改计划”时，重新运行本阶段，并额外说明变更对比和变更原因。

---

阶段 6：执行计划

原则：严格按计划执行，完成后确认。生产环境编辑前，遵循 design-approval-gate（手动模式：用户通过；自动／精简模式：具名豁免并留痕）。首次进行非平凡写入（文档或代码）前，加载 git-worktree-discipline（工作树门控 + 可选隔离）。

上下文预算：根据 context-budget-discipline 评估阶段边界重置和压缩阈值（路径清单来自阶段 5 的计划）；任何重置都必须先有完整的清单条目。

Figma 像素保真度： 如果目标、卡片、议题或计划文本包含 figma.com 或 node-id=，或者用户要求像素级还原，就加载 figma-pixel-implement 并遵循其要求。这些子串即为范围事实。将这些行设为硬性要求；即使任务还会检查行为，也不要将它们归入软性要求或人工检查。检查可见文本、可见性标志或列表长度均不能通过像素要求。如果同一文本还包含 参考、match the existing 或 same as，则将该事实传递给 verify，以便把指定控件的交互状态列为检查项。实现工作只有在目标仓库中有持久化的清单和规范路径时才算完成。在同一次运行中，该技能会继续进入 figma-pixel-verify，直至整体通过，或测量命令无法运行。此处不再重述其方法。

执行流程

1. 按计划中的顺序修改文件
2. 每完成一项更改后，说明已完成的内容
3. 如果阶段 5 的计划采用复选框格式（- [ ]／- [x]），则每完成一项就立即将对应的 [ ] 改为 [x]——不要等到最后再批量更新
4. 全部完成后，输出执行报告
5. 自动进入阶段 7：如果执行顺利且没有阻碍，报告后立即进入阶段 7；如果出现问题或需要作出决定，则先向用户确认

执行报告

• 修改文件列表及关键变更
• 建议的测试步骤
• 与计划的任何偏差（如适用，说明原因）
• 供阶段 7 使用的验证清单

先测试，再确保测试套件（执行报告前）

对于会改变行为的工作，遵循 test-first-discipline（先观察到测试失败，再编写生产代码）。对于缺少测试覆盖且涉及业务逻辑的变更，另行加载 test-suite-ensure，并以 mode=advisory 调用，范围限定为本次变更涉及的逻辑文件。如果用户拒绝搭建测试脚手架，则在执行报告中将其记为非阻塞提醒。test-suite-ensure 不能替代测试优先流程。

工具权限：✅ 允许使用 Edit/Write/Bash；使用 TodoWrite 跟踪进度

阶段 7：验证（检查）

原则：仅输出验证结果——改进建议属于阶段 8。

上下文预算：如果本次运行跨越了压缩阈值，或从账本重新启动，请依据账本和产物进行验证，切勿通过重放之前会话的历史记录来验证（遵循 context-budget-discipline）。

1. 目标达成情况——阶段 1 的预期结果是否达成
2. 与计划的对比——对照阶段 5 的计划进行比较
3. 验证和测试——可引用阶段 6 的执行报告；如果涉及任何测试相关事项，就运行测试
4. 副作用验证——检查变更是否在其他地方引入了新问题或意外的行为变化（功能性副作用），以及是否产生了意外的性能／安全／可维护性影响（非功能性副作用）
5. 逻辑与流程审查——检查是否存在缺漏或遗漏
6. 调试验证循环——如果阶段 2 使用了调试技能来定位根本原因，请依照 analysis-core §4 使用同一技能验证修复（不能只依靠测试）
7. Figma 像素验证——当目标、卡片、问题或计划包含 figma.com 或 node-id=，或者本次运行是根据 Figma 实现的，请加载 figma-pixel-verify 并遵循其要求；如果缺少测量报告（当前产物的 Verify 部分，或 Spec 源文件同级的报告），则此验证阶段无法通过。Spec 缺口导致的 FAIL 不算通过验证——重新进入 figma-pixel-implement 并补全表格。若用户／计划要求进行对齐检查，但本次运行未进行实现，也请加载该技能。仅当报告的总体状态为 PASS（包括已接受的遗留问题），且其渠道是已布局的测量（storybook、isolated-harness、preview、full-app 或 layout-probe）时，此阶段才算通过。任何其他结果均表示此阶段失败，并返回实现阶段，再次进行修复／重新测量循环。此阶段还会对该报告运行 figma-pixel-verify 技能中的 scripts/check-figma-verify-report.mjs；若退出码非零，则此阶段失败。不要复述其方法。

运行测试

如果阶段 5 的计划或阶段 6 的执行报告涉及测试（单元测试、集成测试、手动验证步骤）：

对于 Node／JavaScript／TypeScript 项目，请先调用 node-version-discipline，统一 Node 版本，然后再运行测试。

验证执行遵循 runtime-verification-discipline（强依赖）：AI 在某个环境中自行执行验证，只有遇到经分类确认的真正硬性边界时，才将步骤交给用户，并说明原因。

• AI 可以执行：通过 Bash 运行测试命令（例如 npm test、pytest、go test），并将结果纳入验证结论
• 否则：按照 runtime-verification-discipline 对阻碍因素进行分类；只有真正的硬性边界才交由用户处理，并说明原因。

验证报告的真实性

遵循 staged-review-flow 的验证报告真实性规则和 completion-evidence-discipline（通过声明须有当前轮次的新证据），为每项结果标注状态。

当本轮派发内容内嵌冻结任务卡时，验证报告应包含问题、原因、已完成的修复，以及证据列表。每项证据都必须是已打开界面的检查（引用 png、jpg、jpeg 或 webp 路径），或非界面检查（注明命令及简短输出摘要）。缺失或为空的图片应标记为待处理，并说明仍需截图。不得编造图片。在已打开的界面图片用于佐证检查前，须按照 completion-evidence-discipline 检查该图片。本次运行不编写 HTML 页面，也不编写证据 HTML。

输出格式

输出格式见 reference.md § 阶段 7 — 验证结果。

工具限制：禁止 Edit/Write；✅ 允许使用 Bash 运行测试命令

⛔ [阶段 7 退出] 验证结果输出后立即停止，等待用户确认后再进入阶段 8（或者根据结论判断是否需要进行另一轮修复）。

---

阶段 8：回顾（行动）

验证后：可选交付代码 → 分支收尾 → 回顾。当本次运行可能需要提交 + PR/MR 时，加载 delivery-discipline（并非每次运行都需要 — 该技能的交付需求检查可能会跳过）。然后加载 feature-branch-closeout 显示菜单（PR / 合并 / 保留 / 继续；选择合并时加载 merge-discipline）。然后加载 learn-and-improve 进行回顾和知识沉淀。默认不要编写规则/技能文件；只有当用户明确要求编写，或开启新一轮时，才继续“制定计划 → 执行计划”。

可选交付（delivery-discipline）

加载 delivery-discipline 并遵循其要求。在有帮助时传入 {pr-body-extra} / {commit-context}。如果检查跳过交付，则继续进行收尾（用户仍可通过菜单选择创建 PR，此时会重新进入 delivery-discipline）。

分支收尾（feature-branch-closeout）

加载 feature-branch-closeout 显示收尾菜单。选择保留/继续不会触发合并规范流程。

委派给 learn-and-improve（回顾）

加载 learn-and-improve 并运行其框架；完整方法论见该技能。

solve-workflow 专属编排

• 目标未达成时的下一步：如果 learn-and-improve 的改进循环得出目标尚未达成的结论，则判断是否需要回到“分析问题”/“探索方案”/“审查方案”，再进行一轮 PDCA 循环。
• 收尾和可选总结文档：提出改进建议后，主动询问“是否需要生成总结文档？”。如果需要，生成一份总结文档（由用户指定或由 AI 推荐路径），内容涵盖：问题重述、方案选择、执行结果、未解决事项和改进建议。

输出格式

输出格式见 reference.md § 阶段 8 — 改进建议。

输出后，主动询问：“是否需要生成总结文档？” / “Do you want a summary document?”

合并前覆盖率提醒（有条件，非门槛）

⚠️ solve-workflow 不将受保护分支合并作为强制阶段步骤 — 只有收尾菜单选择合并时（通过 merge-discipline）才会进行合并。可选提交/PR 由 delivery-discipline 负责。覆盖率提醒仅供参考，不是强制门槛 — 它不会运行脚本、不会阻止流程，也不是能力发现表的条目。完整触发条件和提醒文本见 reference.md § 阶段 8 — 合并前覆盖率提醒（非门槛）。

与强制门槛的边界：solve-workflow 只会建议“合并前运行此项” — 它不会运行覆盖率脚本，也不会自行判定是否通过。强制覆盖率门槛属于 merge-discipline 的 C 部分，仅在选择合并时适用（jira-fix-workflow / opsx-* 系列也使用）。

工具限制：禁止 Edit/Write，除非是在执行用户已确认的 delivery-discipline / 收尾 Git 操作时；除非用户明确要求“写入规则”/“创建技能”/“更新文档”，或开启新一轮，否则不要编写规则/技能文件。

常见错误

错误	后果	修正方法
存在性检查得出“不存在／描述不匹配”后仍继续分析	一开始方向就错了	立即停止并报告，等待用户确认
阶段 8 默认写入规则文件或创建技能	污染长期规则；突破仅总结的边界	阶段 8 只输出沉淀建议；只有用户明确要求后，才继续“制定计划 → 执行计划”
阶段 8 将覆盖率提醒视为强制关卡（运行脚本／阻断流程）	只有在选择合并时，覆盖率偏好才属于合并规范 C 部分	提醒仅供参考：打印文本即可；仅执行 solve 时绝不运行 test-coverage-analyzer；绝不阻断流程

---