cc-fix

# Fix > **流程主权声明**：本技能是用户显式调用的修复/调试工作流，已包含 Fix Mode 和 Debug Mode 两套独立流程。 > 禁止在本流程执行期间调用任何会接管修复/调试流程的外部 skill；本技能自己就是调试流程，无需再嵌套一层。 > 业务领域类 skill（如 `cc-redis-safety`、`cc-api-contract-safety`、`cc-external-system-debugging`、`cc-payment-callback-safety`、`cc-time-zone-safety` 等触发条件匹配的安全/规范类技能）正常按需加载，仅作防御性参考，不接管流程。 > 本声明依据用户显式指令优先原则：显式调用 `$cc-fix` 时，本技能拥有修复/调试主流程控制权。 当用户明确要求修复问题、定位 bug 或进入 debug 流程时，使用本技能。 不要用于： - 普通功能实现 - 语言或框架风格规范 - 正式 code review - 环境级风险判断 ## 模式 进入 fix 前，若项目内已有主线任务处于 `进行中`，且本次 fix 只是临时插入事项，先用 `cc-task-state` 或直接在主线任务文件里补“中断记录”，写明当前做到哪、为何切出、恢复入口和下一步，再进入修复流程。 ### Fix Mode 适用于问题边界较清楚、可以直接修复的场景。 1. 确认期望行为和当前症状。 2. 阅读相关代码路径。 3. 做最小有效修复。 4. 对原始问题路径做定向验证。 5. 说明残余风险。 ### Debug Mode 适用于症状明确但根因不清楚的场景。 1. 复现或描述症状。 2. 提出具体假设。 3. 用低成本检查验证假设。 4. 基于证据做最小修复。 5. 回测原始问题路径。 ## 补充检查 - 遇到前后端联调、列表页、分页、筛选项或详情页异常时，补充使用 `cc-api-contract-safety` - 遇到浏览器、编辑器、CDN/WAF、剪贴板、IM 平台、第三方 SaaS 等外部黑盒系统异常，或连续 2 轮凭代码推理修复 no-op 时，补充使用 `cc-external-system-debugging`，先抓真实数据再推理 - 若 fix 会打断当前主线任务，优先记录 checkpoint；只有范围独立、可能跨多轮的插入修复才单独建任务 - 先核对真实接口返回、统一成功响应格式和分页结构，再决定修后端根因还是保留前端临时兼容 - 若保留兼容分支，必须说明退出条件，不把双格式兼容长期固化 ## 输出要求 - 明确区分症状、假设、修复和验证。 - 若本次修复打断了主线任务，明确说明是否已补 checkpoint，以及主线如何恢复。 - 没有证据时，不声称已经找到根因。 - 不因调试过程顺手扩大问题范围。 ## 按需展开 - 直接修复：`references/fix-mode.md` - 结构化排查：`references/debug-mode.md` - 修复后验证：`references/verification-after-fix.md`