UNPKG

@lark-project/cli

Version:

飞书项目插件开发工具

108 lines (69 loc) 5 kB
# 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 在后端联调通过后做。