@lark-project/cli
Version:
飞书项目插件开发工具
108 lines (69 loc) • 5 kB
Markdown
# 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 在后端联调通过后做。