@lark-project/cli/skills/meegle-plugin/references/workflow-phase-3-release.md

飞书项目插件开发工具

# Phase 3：发布上线

完善插件元信息并发布到 Meegle 市场。用户在 publish 不可逆动作前必须显式确认。

> **Checkpoint**：本阶段每个子步骤执行前后都需要更新 `.lpm-cache/state.json`。

## 3.1 完善信息 → 进入 polish 子阶段

**Checkpoint 写入**：`{ "phase": 3, "step": "3.1", "stepName": "polish 子阶段", "nextStep": "3.1 完善插件名称/描述/分类" }`

**恢复检查**：`lastCommand` 含 `update-description` + `status="success"` → 跳到 3.2。

**进入 polish 子阶段**（**不要** Skill()，本 skill 内 Read 推进）：按序 Read

1. [`polish-analyze.md`](polish-analyze.md)（扫 `point.config.local.json` + `src/` 提取功能摘要）
2. [`polish-generate.md`](polish-generate.md)（AI 生成名称/短描述/详情/分类）
3. [`polish-confirm.md`](polish-confirm.md)（展示给用户确认或修改）
4. [`polish-apply.md`](polish-apply.md)（调 `lpm update-description` 落盘）

polish 子阶段自维护 analyze → generate → confirm → apply；编排层不复述子流程、不代为确认。完成后进入 3.2。

> **被 workflow 编排时**：polish 子阶段在 §3.1 进入，工程刚跑完 Phase 2 的 Stage Code，`src/` 必非空 → router 的「D1 src/ 空 gate」此处天然 OK，跳过该检查。

## 3.2 发布前二次确认（不可逆护栏 — 不可跳过）

polish 完成后，**MUST** 跑 `lpm check diff` 生成发布前总检清单、把 stdout 原样转呈用户并等待显式确认，才能进入 3.3 publish。

```bash
lpm --cwd "<projectRoot>" check diff
```

`lpm check diff` 产出 CLI 锚定的四段总检：**① 基本信息（名称/短描述/分类/点位/站点/版本）/ ② 配置覆盖（本地→远端最新草稿的点位增删改）/ ③ 权限变更 / ④ 运行时 URL 健康**。本节在 3.3 的 `update`（A1）之前，本地配置尚未推上远端，故②配置覆盖（本地→远端最新草稿的点位增删改）段此时有效、能看出本次发布会改什么。

- 本步输出 = 三段，按序：① 一句引入 ② 一个 ``` 代码块 ③ 发布确认问句。
- 代码块内容 = `lpm check diff` stdout 的逐字副本：**命令打印几行、块里就几行**，每行字符与原文一致——`═` 边框行、行尾带 `…` 的行、"（注：…折叠）"那行，都是 stdout 的行，照抄进块里即可。
- `lpm check diff` 自身 `exit≠0`（取数失败）→ 视为**致命**，展示错误并终止，**不得**盲发。

**AI 硬约束**：
- ❌ **禁止**在用户未明确回复"确认发布" / "OK发布" / "好，发布吧"等肯定意图前执行 publish
- ❌ **禁止**把"开始 Phase 3"当作发布确认——Phase 3 开头的"开始吗"是 polish 的前置，不是 publish 的前置
- ✅ **必须**接受用户对四段中任一项的修改请求：改名称/分类 → 回 3.1 polish；权限不对 → `lpm perm apply`；URL 是占位 → 改配置后 `lpm local-config set`。改完回到 3.2 重跑 check diff 重新确认
- ✅ **必须**接受用户"取消"，终止 workflow（保留 checkpoint 供后续续跑）

只有用户明确同意发布后，才进入 3.3。

## 3.3 发布 → 进入 publish 子阶段

**前置**：3.2 的"确认发布"必须刚刚通过；从 checkpoint 恢复直插本节时，由 publish-apply 的 **A3 恢复护栏**重跑一次 `lpm check diff` 补确认（与 3.2 同源），未确认前不得执行 publish（W47）。

**Checkpoint 写入**：`{ "step": "3.3", "stepName": "publish 子阶段", "nextStep": "3.3 执行发布" }`

**进入 publish 子阶段**（**不要** Skill()，本 skill 内 Read 推进）：按序 Read

1. [`publish-pre-check.md`](publish-pre-check.md)（tsc 预检 + L1/L2/L3 自动修复；CLI `lpm publish` 已硬卡 metadata 完整性，PC0 异常 → 转 polish 子阶段后回流。注意闸门只在 publish——`lpm release` 零登录态、不做元信息预检）
2. [`publish-apply.md`](publish-apply.md)（A0 check diff 确认 → A1 update → A2 release → **A3 publish**；A0 与 3.2 同样跑 `lpm check diff`——3.2 刚走过故 A0 可跳过，但**从 checkpoint 恢复直插 A3 时，A3 的恢复护栏会重跑一次 `lpm check diff` 补确认**）
3. [`publish-verify.md`](publish-verify.md)（确认发布成功 + 分享链接格式）

publish 子阶段自维护 pre-check → apply → verify 的 checkpoint、恢复逻辑、版本号/描述默认值；编排层不复述、不传参。

## 3.4 完成

发布成功后删除 `.lpm-cache/state.json`，把 publish 输出的分享链接转呈用户。