用途：面向值得长期留痕的工程变更（需求、根因、行为变更、技术权衡、任务清单、验证结果），把 solve-workflow 的八阶段 PDCA 纪律与 OpenSpec/OPSX 工件持久化结合。OpenSpec 作为事实来源与归档系统回答“做什么、为什么”，阶段门控回答“何时可进入下一步”。
主要能力：阶段 0 环境检查与路径选择（full/incremental/lean，范围扩大需升级路径）；阶段 1 澄清问题（主动提问、领域路由，禁止读写代码，除非用户直接引用文件或片段）；阶段 2 分析问题（委托 analysis-core，输出分析门控块）；阶段 3 探索方案（2-5 个方案、YAGNI、架构边界预检，经 openspec-continue-change 生成 proposal.md 与 delta specs）；阶段 4 评审方案（staged-review-flow，生成 design.md）；阶段 5 制定计划（tasks.md）；阶段 6 执行（更新 tasks.md 复选框，允许写代码，调用 test-suite-ensure）；阶段 7 检查验证（禁止写代码，用 openspec-verify-change 或 openspec validate）；阶段 8 复盘归档（更新 openspec/specs/ 并移入 archive）。
使用方式：触发词包括 opsx解决、OpenSpec解决、规范化解决、创建OpenSpec变更、用OpenSpec分析/修复、opsx自动解决、opsx-solve、opsx-solve-workflow 等。默认手动模式，阶段 1、2、3、4、5、7、8 的关键出口需用户确认；含“自动”的触发进入自动模式，自动推进至验证，阶段 4 评审循环最多 3 轮后暂停。ai-proxy 模式为叠加触发，合并、不可逆与受保护分支决策仍须人工。启动时须通过前置技能检查，缺失强依赖即中止，不得降级。
适用场景：长期行为契约、团队评审、并发变更、需求审计或后续可追溯的任务。快速修复、单文件轻量编辑或无长期留痕需求时，建议改用普通 solve-workflow。
限制：需要已完整初始化的 OpenSpec 工作区，无降级路径；阶段 1-5 禁止修改业务代码；阶段 7 禁止写代码；归档完成后模式自动回退手动；归档中断也视为流程中断。具体输出模板见 reference.md，收费、价格与平台信息暂未提供。