用途：面向 bug、回归、异常行为或生产问题报告，提供一套带门禁的结构化修复流程，避免在证据不足时猜测原因或直接改代码。
主要能力与流程：先做仓库资格检查（读取 ~/.ways/config.yaml 黑名单，命中则询问是否例外处理）；随后进入 Phase 0 发现与受理，阅读 PRD.md、docs/ 文档、docs/bugs/ 既有报告，必要时读取 docs/requirements/{slug}/TICKET.md，澄清现象、预期、影响范围、环境、严重度与缺失信息，并定位相关模块、提交与可能共享回归的其他仓库。之后依次为：Phase 1 记录 BUG.md；Phase 2 分析并写 ANALYSIS.md；Phase 3 编写必须失败的复现测试；Phase 4 编写 FIX_PLAN.md 并等待用户确认；Phase 5 按计划实现；Phase 6 验证；Phase 7 提交 PR。
使用方式：先选择隔离方式——当前检出中的分支（git switch develop、git pull --ff-only、git switch -c fix/{slug}）或独立 worktree（git fetch origin develop、mkdir -p .worktrees、git worktree add .worktrees/fix-{slug} -b fix/{slug} origin/develop）。状态写入 .ways/state.json，遵循 ways/v1alpha1 状态契约，flow 为 bug，门禁为 fix-plan 与 pr。文档路径为 docs/bugs/{slug}/BUG.md、ANALYSIS.md、FIX_PLAN.md。复现测试需先失败，命令示例为 pnpm test；实现与验证阶段运行 pnpm typecheck && pnpm lint && pnpm test，验证还包含 pnpm test:e2e、pnpm build 以及 Snyk SAST、Snyk SCA、SonarQube 扫描。提交与开 PR 建议通过 incu-way-prepare-pr 完成，不自行提交或合并。
适用场景：需要可追溯证据、根因分析与修复计划的缺陷处理，尤其是生产问题、回归和高严重度缺陷。
限制：修复计划未获用户确认前不得写修复代码；不得超出计划范围改动；无法复现时须在 ANALYSIS.md 说明并询问；不得直接操作 develop 或 main；不得自行合并；扫描工具不可用时须记录并询问，不能谎报为通过。其他收费、平台支持等信息暂未提供。