# Analyze 详细规则

## 目标

验证需求完整性，分析代码现状，为后续方案设计提供稳定输入。

## 总流程

```text
Phase A (步骤 1-4) -> 检查评分 >= require_score?
  ├─ 是 -> Phase B (步骤 5-6) -> 输出摘要
  └─ 否 -> 检查 auto_decide
       ├─ true  -> 补充假设后继续
       └─ false -> 发起追问并等待用户输入
```

## Phase A：需求评估

### 步骤 1：检查知识库状态

- 判定条件：存在项目代码，且需求不是“新项目初始化”。
- 执行方式：检查 `.sopify-skills/` 是否存在。
- 异常标记：若不存在，标记需初始化知识库。

### 步骤 2：获取项目上下文

- 优先读取 `.sopify-skills/user/preferences.md` 与知识库文件。
- 信息不足时再扫描代码。
- 详细知识库策略以 `kb` skill 为准。

偏好应用规则：

1. 只使用用户明确声明的长期偏好。
2. 当前任务明确要求优先于历史偏好。
3. 无匹配偏好时按默认规则执行。

### 步骤 3：需求类型判定

候选类型：

1. 新项目初始化
2. 新功能开发
3. 功能修改/增强
4. Bug 修复
5. 重构优化
6. 技术变更

### 步骤 4：需求完整性评分

评分维度（总分 10）：

- 目标清晰：0-3
- 预期结果：0-3
- 边界范围：0-2
- 约束条件：0-2

评分处理规则：

- `score >= require_score`：进入 Phase B。
- `score < require_score` 且 `auto_decide=true`：显式补充假设后继续。
- `score < require_score` 且 `auto_decide=false`：发起追问（模板见 `assets/question-output.md`）。

追问规则：

1. 不问可从代码直接获得的信息。
2. 只问用户相关关键缺口（业务、目标、约束）。
3. 问题数量 3-5 个。
4. 不重复追问已在长期偏好里明确的信息。

## Phase B：代码分析

### 步骤 5：提取关键目标

- 把需求压缩成一句话核心目标。
- 先区分用户给的是“目标”还是“实现路径”。
- 若当前输入主要是路径而不是目标，把路径记为候选方案，不直接当成成功标准。
- 给出可验证成功标准，并按 SMART 风格收口交付物、边界、约束、验证方式与下一停点。

### 步骤 6：代码分析与技术准备

- 估算项目规模与改动规模。
- 定位相关模块与关键文件。
- 做基础质量检查（过时信息、安全风险）。
- 必要时补充外部文档检索。

稳定子规则：

1. 目标模糊时优先补关键事实；只有 `auto_decide=true` 才允许带显式假设继续。
2. 若已知当前路径明显次优，在分析摘要中至少给出 1 个更低成本或更低风险的替代路径。
3. 替代路径必须说明 tradeoff，避免只给结论不给理由。
4. `quick_fix`、纯状态解释和轻咨询场景不强制展开深度挑战。

## 路由判定（adaptive）

- 简单任务（<=2 文件且需求明确）：直入快速修复。
- 中等任务（3-5 文件）：进入 light 方案。
- 复杂任务（>5 文件或架构变更）：进入完整方案设计。

## 阶段转换

- 评分不足且不可自动决策：循环追问直到达标或取消。
- `workflow.mode=strict`：达标后输出摘要并等待确认。
- `workflow.mode=adaptive`：达标后按复杂度自动推进。
- 用户输入“取消”：按取消模板结束流程。
