listpage_cli 0.0.313 → 0.0.314

package/bin/adapters/cli-interaction.js

@@ -176,6 +176,9 @@ function printHelp() {
         `    备注: ${helpColor("默认会清理并拉取镜像；传入 --skip-image 时只执行容器相关步骤（假定镜像已是最新且已存在）", "yellow")}`,
         `          ${helpColor("参数优先级为 CLI > profile > base", "yellow")}`,
         "",
+        `    用法: ${helpColor("listpage_cli project all [tag] [--profile dev] [--platform linux/amd64] [--env KEY=VALUE] [--skip-image]", "dim")}`,
+        "    说明: 串行执行 build -> release -> deploy，任一步失败即中断并返回对应错误",
+        "",
         `  ${helpColor("lark", "green")}`,
         `    用法: ${helpColor("listpage_cli lark read <doc_token>", "dim")}`,
         `          ${helpColor("listpage_cli lark check-todo <doc_token> <todo_index>", "dim")}`,

package/bin/commands/project-command.js

@@ -18,8 +18,19 @@ function createProjectCommandHandler(deps) {
                 return release(input);
             case "deploy":
                 return deploy(input);
+            case "all": {
+                const buildResult = await build(input);
+                if (!buildResult.ok) {
+                    return buildResult;
+                }
+                const releaseResult = await release(input);
+                if (!releaseResult.ok) {
+                    return releaseResult;
+                }
+                return deploy(input);
+            }
             default:
-                return (0, command_result_1.commandError)("错误: 未知的子命令。目前仅支持: build, release, deploy", "invalid_subcommand", 1);
+                return (0, command_result_1.commandError)("错误: 未知的子命令。目前仅支持: build, release, deploy, all", "invalid_subcommand", 1);
         }
     };
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "listpage_cli",
-  "version": "0.0.313",
+  "version": "0.0.314",
   "private": false,
   "bin": {
     "listpage_cli": "bin/cli.js"

package/templates/backend-template/package.json.tmpl

@@ -25,7 +25,7 @@
     "class-transformer": "^0.5.1",
     "class-validator": "~0.14.2",
     "rxjs": "^7.8.1",
-    "listpage-next-nest": "~0.0.313"
+    "listpage-next-nest": "~0.0.314"
   },
   "devDependencies": {
     "@nestjs/schematics": "^11.0.0",

package/templates/frontend-template/package.json.tmpl

@@ -5,13 +5,13 @@
   "type": "module",
   "scripts": {
     "build": "rsbuild build",
-    "dev": "rsbuild dev --open",
+    "dev": "rsbuild dev",
     "format": "prettier --write .",
     "preview": "rsbuild preview"
   },
   "dependencies": {
-    "listpage-http": "0.0.313",
-    "listpage-components": "0.0.313",
+    "listpage-http": "0.0.314",
+    "listpage-components": "0.0.314",
     "antd": "6.3.1",
     "ahooks": "^3.9.5",
     "@ant-design/icons": "~6.0.2",

package/templates/rush-template/AGENTS.md

@@ -0,0 +1,36 @@
+# 项目说明
+
+本仓库使用 **Rush monorepo** 管理，**不要**按普通 npm 项目执行命令。
+
+## 常用命令（Rush）
+
+### 依赖管理
+
+- **安装依赖**：`rush install`（在仓库根目录执行，对应 `npm install`）
+- **更新依赖 / 锁文件**：`rush update`（修改 package.json 或依赖后执行）
+- **添加依赖到某个项目**：
+  - `cd apps/fe && rush add -p package-name`：给前端加依赖
+  - `cd servers/be && rush add -p package-name`：给后端加依赖
+- **添加 dev 依赖**：`rush add -p package-name --dev`（同样需先 `cd` 到目标项目目录）
+
+**不要使用** `npm install`、`pnpm add` 等在子项目中直接安装依赖。
+
+### 项目脚本
+
+- **前端开发**：`cd apps/fe && rushx dev`
+- **后端开发**：`cd servers/be && rushx dev`
+- **构建**：`rush build`（根目录，会构建所有项目）
+
+### Prisma（后端 schema 变更后）
+
+- **生成 Prisma 客户端**：`cd servers/be && rushx prisma:gen`（或 `npx prisma generate`）——更新本地依赖
+- **同步到远程数据库**：`cd servers/be && npx prisma db push`——将 schema 改动推到数据库
+
+### 项目自带命令
+
+
+## 子项目说明
+
+- `apps/fe`：前端（详见 apps/fe/AGENTS.md）
+- `servers/be`：后端（详见 servers/be/AGENTS.md）
+

package/templates/skills-template/feishu-prd-reviewer/SKILL.md

@@ -6,22 +6,18 @@ description: 评审飞书 PRD（支持评审后结合待办反向澄清需求）
 # Feishu PRD Reviewer（产品视角）
 
 ## 触发条件
-
 - 用户要求处理该飞书 PRD（评审或补齐待办），并明确提供文档地址（URL）或 `doc_token`
 - 通过 `npx listpage_cli lark read <doc_token>` 能成功读取到文档内容
 
 ## 输入
-
 - 飞书 PRD URL（用于解析 `doc_token`）
 - 或用户直接提供 `doc_token`
 
 ## 输出
-
 - PRD 含待办：结合“AI 评审章节 + 待办问题”逐条处理待办，更新需求清单描述并回写对应区块、将待办标记为 done；随后结束
 - PRD 不含待办：生成产品经理易读的评审结论并回写区块；随后结束
 
 ## 核心原则
-
 - **互斥执行**：一次仅执行一个模式。
   - 有待办：只做“待办处理”，不做任何新的需求评审与结论生成（但可读取既有 AI 评审章节作为待办处理输入）。
   - 无待办：只做“需求评审”，不进行待办处理流程（不创建 requirements.md）。
@@ -31,7 +27,6 @@ description: 评审飞书 PRD（支持评审后结合待办反向澄清需求）
 - 约束强执行：待办处理阶段严格遵循标题层级与提示语移除规则（见“待办处理约束”）
 
 ## 执行流程
-
 1. 获取 `doc_token`：从 URL 提取，或直接使用用户提供的 token
 2. 读取需求文档：在项目根目录执行
    - `npx listpage_cli lark read <doc_token>`
@@ -44,14 +39,14 @@ description: 评审飞书 PRD（支持评审后结合待办反向澄清需求）
      - 文件路径示例：`.listpage/lark/<doc_token>/requirements.md`
      - 标题约束：严禁使用 H1/H2，所有标题必须从 H3 开始
      - 内容约束：移除提示语“下面部分由产品经理编写，内容为准备评审的需求点”
-   - 内容来源：以原文档中“需求清单”作为基底，并结合“AI 评审章节（如 robot_face 回写的评审结论）”与待办问题进行澄清改写；去掉“需求清单”标题与相关提示语
+    - 内容来源：以原文档中“需求清单”作为基底，并结合“AI 评审章节（如 robot_face 回写的评审结论）”与待办问题进行澄清改写；去掉“需求清单”标题与相关提示语
    - 循环处理每条待办
      1. 读取待办事项内容
-   2. 同步读取对应需求点的 AI 评审内容（需求描述/问题/可行性/风险点）
-   3. 以“待办问题 + AI 评审结论”共同作为输入，改写 `requirements.md` 中对应需求点，让需求描述更清晰、可执行
-   4. 如 AI 评审与待办口径冲突，以“待办明确的新口径”优先，并在需求描述中消除歧义
-   5. 回写时只更新需求清单内容，不改变既定回写命令和回写目标区块
-   6. 直到所有待办处理完成
+    2. 同步读取对应需求点的 AI 评审内容（需求描述/问题/可行性/风险点）
+    3. 以“待办问题 + AI 评审结论”共同作为输入，改写 `requirements.md` 中对应需求点，让需求描述更清晰、可执行
+    4. 如 AI 评审与待办口径冲突，以“待办明确的新口径”优先，并在需求描述中消除歧义
+    5. 回写时只更新需求清单内容，不改变既定回写命令和回写目标区块
+    6. 直到所有待办处理完成
    - 回写飞书文档（待办全部完成后）
      - 执行：`npx listpage_cli lark update-block <doc_token> woman "<markdown_file_path>"`
    - 更新待办状态
@@ -59,66 +54,64 @@ description: 评审飞书 PRD（支持评审后结合待办反向澄清需求）
      - 将待办标记为完成（done）
 5. 流程结束：待办处理完成后停止，不再执行后续步骤
 6. 代码评审与结论生成（无待办时执行）
-
-- 目标：先把“需求点列表”固定到 `review.md`，再对每条需求点按序逐条评审并回写，避免一次性把所有需求点塞进上下文导致爆炸
-- 阶段 A：需求点提炼并写入 `review.md`（仅拆条，不写评审）
-  - 从步骤 2 读取到的 PRD 内容中，提取“需求清单”区段的全部需求点（包含图片/补充信息的隐含诉求）
-  - 将需求拆成 N 条“可执行条目”，为每条生成稳定编号（例如 `i=1..N`）
-  - 在本地创建/覆盖 Markdown：`.listpage/lark/<doc_token>/review.md`
-  - 在 `review.md` 顶部添加一个“执行待办清单”（仅用于阶段 B 驱动逐条处理）
-    - 格式示例（必须是 Markdown checklist）：`- [ ] 需求点 1`
-    - 对每条生成一行：`- [ ] 需求点 i`
-    - 阶段 A 不把任何条目标为已完成
-  - 每条使用固定区块边界，格式示例：`### 需求点 i`（注意：仅要求禁止 H1/H2，H3 允许）
-  - 仅在每个 `### 需求点 i` 区块内写“需求描述”，并严格复用 `example.md` 的字段与缩进/子 bullet 结构（产品视角）
-  - 阶段 A 不写“问题/可行性/风险点”，只负责把每个需求点的“需求描述”结构固定下来，避免一次性输出过多评审内容导致上下文爆炸
-  - 格式约束：严禁使用 H1/H2 标题或表格；允许使用列表与加粗字段
-- 阶段 B：逐条评审并回写 `review.md`（按序、只处理一条）
-  - 对 i = 1..N 循环执行，直到全部条目完成
-    1. 只读取 `review.md` 中两处内容：
-       - 执行待办清单里第 i 行（`- [ ] 需求点 i` 或 `- [x] 需求点 i`）
-       - `### 需求点 i` 对应的区块（不要把其它条目的内容也纳入本轮处理）
-    2. 只基于 PRD 需求本身进行判断，不做“结合代码去猜口径/猜实现”的推断；并且收紧“问题”触发条件：
-       - 只有当 PRD 信息不足以形成“开发可执行的需求描述”（关键落点/口径/范围/汇总规则无法确定）时，才输出 `**问题：**`（不写 `可行性/风险点`）
-       - 如果基于该需求点本身已足够做出“可以实现”的判断（即使仍存在非关键细节，也不阻塞落地），则不要问问题：直接输出 `**可行性：**`（成本等级 + 精简的必要说明）
-    3. 将输出严格复用 `example.md` 的区块结构，并回写到对应 `### 需求点 i` 区块，保持其它区块不变：
-       - 不新增其它字段/标题/正文块
-       - 仅按需要填写 `需求描述` / `问题` / `可行性` / `风险点`（这些字段与缩进/子 bullet 结构必须与 `example.md` 一致）
-       - 不允许出现代码/组件/函数/文件名；不要根据代码猜口径（需求不清晰就只提问题）
-    4. 把执行待办清单里第 i 行从 `- [ ] 需求点 i` 更新为 `- [x] 需求点 i`（作为“本条已完成”的唯一状态）
-- 阶段 C：最终回写飞书
-  - 等循环全部完成后，在本地生成“回写版”文件：`review_writeback.md`
-    - `review_writeback.md` 最顶部新增 `### 评审人` 标题，并下一行写 `<当前模型名称>`（格式与 `example.md` 一致）
-    - 该文件同时保留 `### 评审人` 区块与所有 `### 需求点 i` 区块
-    - 必须删除顶部的“执行待办清单”（`- [ ]/- [x] 需求点 i` 那一段及其所在行），确保飞书里不出现 checklist 待办格式
-  - 执行飞书回写时，仅使用 `review_writeback.md`：
-    - `npx listpage_cli lark update-block <doc_token> robot_face "review_writeback.md"`
+  - 目标：先把“需求点列表”固定到 `review.md`，再对每条需求点按序逐条评审并回写，避免一次性把所有需求点塞进上下文导致爆炸
+  - 阶段 A：需求点提炼并写入 `review.md`（仅拆条，不写评审）
+    - 从步骤 2 读取到的 PRD 内容中，提取“需求清单”区段的全部需求点（包含图片/补充信息的隐含诉求）
+    - 将需求拆成 N 条“可执行条目”，为每条生成稳定编号（例如 `i=1..N`）
+    - 在本地创建/覆盖 Markdown：`.listpage/lark/<doc_token>/review.md`
+    - 在 `review.md` 顶部添加一个“执行待办清单”（仅用于阶段 B 驱动逐条处理）
+      - 格式示例（必须是 Markdown checklist）：`- [ ] 需求点 1`
+      - 对每条生成一行：`- [ ] 需求点 i`
+      - 阶段 A 不把任何条目标为已完成
+    - 每条使用固定区块边界，格式示例：`### 需求点 i`（注意：仅要求禁止 H1/H2，H3 允许）
+    - 仅在每个 `### 需求点 i` 区块内写“需求描述”，并严格复用 `example.md` 的字段与缩进/子 bullet 结构（产品视角）
+    - 阶段 A 不写“问题/可行性/风险点/业务合理性”，只负责把每个需求点的“需求描述”结构固定下来；业务合理性在阶段 B 的第一步再写（仅不合理时出现）
+    - 格式约束：严禁使用 H1/H2 标题或表格；允许使用列表与加粗字段
+  - 阶段 B：逐条评审并回写 `review.md`（按序、只处理一条）
+    - 对 i = 1..N 循环执行，直到全部条目完成
+      1. 只读取 `review.md` 中两处内容：
+         - 执行待办清单里第 i 行（`- [ ] 需求点 i` 或 `- [x] 需求点 i`）
+         - `### 需求点 i` 对应的区块（不要把其它条目的内容也纳入本轮处理）
+      2. 第一步（业务合理性）：结合仓库内可读的产品/业务上下文（如 AGENTS、领域约定、既有能力边界）判断该需求点是否合理——用户是否想清楚、提出的方案是否当下较优、是否与既有业务目标或流程冲突。**仅当**判定为「不合理、需再商榷、或用户方案非当下较优」时，在本条区块内增加 `- **业务合理性：**:`（说明理由、风险或更可取的替代思路）；合理则**不**增加该字段。判断时避免引用具体代码路径/函数/文件名；不写实现猜测。
+      3. 第二步（信息完备性 + 落地性）：只基于 PRD 需求本身进行判断，不做“结合代码去猜口径/猜实现”的推断；并且收紧“问题”触发条件：
+         - 只有当 PRD 信息不足以形成“开发可执行的需求描述”（关键落点/口径/范围/汇总规则无法确定）时，才输出 `**问题：**`（不写 `可行性/风险点`）
+         - 如果基于该需求点本身已足够做出“可以实现”的判断（即使仍存在非关键细节，也不阻塞落地），则不要问问题：直接输出 `**可行性：**`（成本等级 + 精简的必要说明）
+      4. 将输出严格复用 `example.md` 的区块结构，并回写到对应 `### 需求点 i` 区块，保持其它区块不变：
+         - 不新增其它字段/标题/正文块（`业务合理性` 为**仅在不合理时**允许的例外字段，见 `example.md`）
+         - 仅按需要填写 `需求描述` / `业务合理性` / `问题` / `可行性` / `风险点`（这些字段与缩进/子 bullet 结构必须与 `example.md` 一致）
+         - 不允许出现代码/组件/函数/文件名；不要根据代码猜口径（需求不清晰就只提问题）
+      5. 把执行待办清单里第 i 行从 `- [ ] 需求点 i` 更新为 `- [x] 需求点 i`（作为“本条已完成”的唯一状态）
+  - 阶段 C：最终回写飞书
+    - 等循环全部完成后，在本地生成“回写版”文件：`review_writeback.md`
+      - `review_writeback.md` 最顶部新增 `### 评审人` 标题，并下一行写 `<当前模型名称>`（格式与 `example.md` 一致）
+      - 该文件同时保留 `### 评审人` 区块与所有 `### 需求点 i` 区块
+      - 必须删除顶部的“执行待办清单”（`- [ ]/- [x] 需求点 i` 那一段及其所在行），确保飞书里不出现 checklist 待办格式
+    - 执行飞书回写时，仅使用 `review_writeback.md`：
+      - `npx listpage_cli lark update-block <doc_token> robot_face "review_writeback.md"`
 
 ## 评审方法（无待办时）
-
 （无待办时执行第 6 步的“阶段 A/B/C”，本节仅保留总体输出原则）
-
 - 需求点提炼：从“需求清单”区段理解全部需要落地的需求点（包括图片描述与补充信息中的隐含诉求），并拆成可逐条评审的 N 条条目
+- 第一步（业务合理性，逐条）：结合现有业务与产品上下文（仓库内可读说明、领域约定、能力边界；**非**具体实现代码）判断该需求点是否合理——用户是否想清楚、用户给出的方案是否当下较优、是否与业务目标或既有流程冲突。**仅当**判定为不合理或需再商榷时，才在对应区块增加 `- **业务合理性：**:`；合理则**不**输出该字段
+- 第二步（信息完备与落地）：在业务合理性字段（若有）之后，再按信息缺口与可行性规则补充 `问题` / `可行性` / `风险点`（互斥与触发条件见下）
 - 输出模板：每个 `### 需求点 i` 区块的呈现结构必须严格复用 `example.md`
   - `- **需求描述：**:` 必须出现
+  - `- **业务合理性：**:` **仅当**第一步判定不合理/需商榷时出现；与 `问题`、`可行性`、`风险点` 的并存规则见 `example.md`
   - 仅当信息缺口会阻塞落地：才出现 `- **问题：**:`（此时不出现 `**可行性：**` 与 `**风险点：**`）
   - 其余情况（能实现/不阻塞落地）：出现 `- **可行性：**:`（可追加 `- **风险点：**:`，仅影响范围大时）
 - 澄清优先（但不泛问）：不阻塞落地时不提问；不做口径猜测
-- 禁止代码猜测：不引用仓库代码/组件/函数/文件名；也不要根据代码推断不清晰的口径（应改为提问）
+- 禁止代码猜测：不引用仓库代码/组件/函数/文件名作为“证据”；也不要根据代码推断不清晰的口径（应改为提问）。业务合理性判断允许使用**产品/业务层**上下文，与“禁止用代码猜 PRD 口径”并行不悖
 
 ## 写回文档（无待办时）
-
 - 本地写回：通过第 6 步阶段 C 生成 `review_writeback.md`
 - 格式要求：严禁使用（H1-H2）标题或表格；只保留 `### 评审人` 与所有 `### 需求点 i` 区块
 - 同步飞书：执行 `npx listpage_cli lark update-block <doc_token> robot_face "review_writeback.md"`
 
 ## 待办处理约束（强制）
-
 - 新建 requirements.md 文档禁止 H1/H2，标题从 H3 开始
 - 必须移除指定提示语，并去掉“需求清单”标题本身
 - 必须把“AI 评审章节 + 待办问题”合并后再更新需求清单，不可仅依据待办原文机械改写
 
 ## 成功标准
-
 - 有待办：所有待办均回写并标记 done；已基于“AI 评审章节 + 待办问题”完成需求清单澄清更新；仅完成待办处理相关的文档更新；不生成新的需求评审结论（也不创建新的 review.md）
-- 无待办：生成的评审结论回写成功；且回写内容满足“无 H1-H2 标题,无表格”的格式要求
+- 无待办：生成的评审结论回写成功；且回写内容满足“无H1-H2标题,无表格”的格式要求

package/templates/skills-template/feishu-prd-reviewer/example.md

@@ -34,3 +34,14 @@
 - **风险点：**
   - （风险 1：可能影响的不止是展示文案，例如统计口径/汇总逻辑/跨模块联动等）
   - （风险 2）
+
+### 需求点 5（业务合理性：仅不合理时出现）
+
+- **需求描述：**: （一句话概括要做什么，产品视角）
+- **业务合理性：**
+  - （为何不合理/与用户目标或现有业务冲突/用户方案非当下较优；可写更可取的替代思路或需产品先拍板的点）
+- **可行性：**
+  - 成本：低/中/高
+  - （仍可在指出业务问题的同时评估落地成本；若信息仍不足以落地，则改用「需求点 2」结构：业务合理性 + **问题**，不出现可行性/风险点）
+
+字段顺序与并存：`需求描述` 始终第一；`业务合理性` 仅在不合理时出现在 `需求描述` 之后。其后仍遵循「有问题则只写问题，无问题则写可行性（可加风险点）」。