# mode=verify：TypeScript 语法预检 + 自动修复

**Checkpoint 恢复检查**（仅在 `lpm --cwd "<projectRoot>" ai state get` 有输出时；输出为空 = 无 checkpoint）：
- `lastCommand` 含 `tsc` + `"success"` → 语法已通过，跳到 V4（扫代理路由 + 判定后端那一半）
- `lastCommand` 含 `tsc` + `"failed"` + `context.tscRound=1` → 从第 2 轮修复继续
- `lastCommand` 含 `tsc` + `"failed"` + `context.tscRound=2` → 进入 V3 降级兜底
- 其他 → 从 V1 开始

## V1：执行 tsc --noEmit 预检（L1）

**Checkpoint**：执行前写入 `{ nextCommand: "tsc --noEmit", nextStep: "V1 语法预检", lastCommandStatus: "running", context: { ..., tscRound: 0 } }`

在工程根目录执行：
```bash
npx tsc --noEmit
```

预期耗时约 10s，通过 SSE 展示实时输出。

### 成功（exit code 0）

**Checkpoint**：`{ lastCommand: "tsc --noEmit", lastCommandStatus: "success", nextStep: "V4 扫代理路由 + 判定后端那一半" }`

```
✅ TypeScript 语法检查通过，代码质量 L1 合格
   下一步：V4 —— 扫 fetch('/api/proxy/*') + 判定这个 feature 要不要后端那一半
```

### 失败（有语法错误）→ 进入 L2 自动修复

**Checkpoint**：`{ lastCommand: "tsc --noEmit", lastCommandStatus: "failed", context: { ..., tscRound: 0 } }`

## V2：AI 自动修复（L2，最多 2 轮）

**第 1 轮修复**：

**Checkpoint**：修复代码后、重新 tsc 前写入 `{ nextCommand: "tsc --noEmit", nextStep: "V2 第 1 轮修复后重检", lastCommandStatus: "running", context: { ..., tscRound: 1 } }`

1. 读取 tsc 完整错误输出（文件名 + 行号 + 错误类型）
2. AI 分析错误原因（import 路径错误、类型不匹配等）
3. 生成修复后的代码，覆盖写入对应 `src/features/<id>/index.tsx`
4. 重新执行 `tsc --noEmit`

若第 1 轮成功 → **Checkpoint**：`{ lastCommand: "tsc --noEmit", lastCommandStatus: "success", context: { ..., tscRound: 1 } }` → 通过，进 V4。

**第 2 轮修复**：

**Checkpoint**：`{ nextCommand: "tsc --noEmit", nextStep: "V2 第 2 轮修复后重检", lastCommandStatus: "running", context: { ..., tscRound: 2 } }`

若第 1 轮仍失败，再尝试一次（方法同上）。

若第 2 轮成功 → **Checkpoint**：`{ lastCommand: "tsc --noEmit", lastCommandStatus: "success", context: { ..., tscRound: 2 } }` → 通过，进 V4。

## V3：降级兜底（L3）

若 2 轮自动修复后仍有错误：

```
⚠️ 代码存在语法错误，AI 自动修复未能完全解决。

错误详情：
  • src/features/page/main/index.tsx:12 - 类型 'string' 不可分配给类型 'number'
  • ...

建议：
1. 下载代码 zip，在本地用 VS Code 手动修复
2. 本地修复后：npm install && npx tsc --noEmit 验证
3. 修复完成后：lpm release 发布

[下载代码 zip]
```

**L3 降级时不阻止用户继续**：用户可以选择忽略错误强制发布（webpack 会再做一次报错），或下载本地修复。

## V4：扫代理路由 + 判定是否需要后端那一半

verify 通过后，先做一次收尾扫描——把 code.plan 没列全的代理路由也收进来：

- 在生成的 `src/features/<id>/*.tsx` 里搜 `fetch('/api/proxy/`，列出所有路径
- 汇总"这个 feature 需要后端那一半吗"：
  - config.plan（P5）判出有 **webhook 形态点位** → 需要
  - code.plan（P3.5）或上面这次扫描列出了 **`/api/proxy/*` 代理路由** → 需要
  - 两者都没有 → 不需要，走 V5 完成态

**需要后端那一半** → 按 [`feature-overview.md`](feature-overview.md) 「→ 后端那一半（relay）」编排走（A 后端就绪：汇总契约 + scope 就绪 → 产交接包【交接点】→ 联调收口 → 发布）：契约 = 代理路由清单（路径 + 出入参形态）+ webhook 端点（来自 config.plan）+ `originalRequirement`；后端代码「怎么写」由接手的后端会话取 `meegle-plugin-backend` skill（本 skill 不 Read）。跑完后回到本流程的完成态（前端已就绪 + 后端联调通过 + 引导 publish）。

## V5：引导本地调试（完成态）

**有前端产物且不需要后端那一半**（V4 判定无 webhook 形态点位、无代理路由）→ 引导用户启动调试：

```bash
lpm --cwd "<projectRoot>" start --auto
```

`--auto` 参数会自动根据 `getLocalConfig` 中的当前域名拼接调试 URL，并在浏览器中打开调试页面。

```
✅ TypeScript 语法检查通过，代码质量合格

下一步：启动本地调试服务器
  运行：lpm start --auto
  CLI 将自动打开浏览器调试页面
```

用户在浏览器中确认插件效果后，进入下一步：publish phase 发布插件。

> 既有前端、又有后端那一半 → 先按 V4 走后端那半的编排（relay：A 后端就绪 汇总契约+scope就绪 → 产交接包【交接点】→ 联调收口 → 发布），再回这里引导前端本地调试；publish 在后端联调通过后做。