ai-project-manage-cli 4.0.22 → 5.0.1

package/template/skills/apm-refine/apm-refine-template.md

@@ -1,73 +0,0 @@
-# 需求文档模板
-
-执行润色时 **Read 本文件**，按下列骨架与写法组织 `prd.md`。
-
-## 正文骨架
-
-```markdown
-# [需求标题]
-
-## 背景与目标
-
-（1 ～ 3 句：业务背景、要解决的问题、预期效果）
-
-## 范围
-
-- **包含**：…
-- **不包含**：…
-
-## 需求说明
-
-### 需求点 1：[简短名称]
-
-- …
-- …
-
-### 需求点 2：…
-```
-
-按需追加（材料中确有相关内容时）：
-
-- **非功能与约束** — 性能、权限、兼容、埋点等
-- **待确认** — 补充信息里用户原文写明的待定项，每条 `[ ]` 一行
-
-## 需求点怎么写
-
-每条 bullet 写清一个可验收点，优先覆盖：
-
-| 类型      | 写法要点                                               |
-| --------- | ------------------------------------------------------ |
-| 展示/选项 | 展示或隐藏；保留/去掉哪些选项；新建默认值              |
-| 文案      | 原名称 → 新名称；界面、提示、校验文案一并统一          |
-| 按钮      | 场景 + 按钮名 + 行为（对照哪个既有按钮、是否仅改文案） |
-| 校验      | 场景 + 字段展示条件 + 必填时机（暂存 / 提交分别怎样）  |
-| 边界      | **不考虑** …（历史数据、迁移、导出等明确排除项）       |
-
-材料中的技术名可译为业务表述，例如：`audit1` → 一级审批；保存不推进流程 → **暂存**；办理并推进流程 → **提交**。
-
-## 示例
-
-```markdown
-### 需求点 2：新增/编辑弹窗底部操作
-
-- 在**新增、编辑**场景下，弹窗底部新增 **「暂存」** 按钮。
-- **「暂存」**：沿用原 **「确定」** 按钮的业务逻辑（含校验与保存/流程行为），**仅将按钮展示文案改为「暂存」**。
-
-### 需求点 3：「科室医德考评小组人员名单」字段
-
-- 原字段展示名 **「科室医德考评人员名单」** 统一改为 **「科室医德考评小组人员名单」**；凡界面、提示、校验文案等涉及该名称处**一并修改**。
-- 当流程处于 **一级审批** 且该字段**展示**时，须校验为**必填**（在展示场景下触发，而非所有保存入口一律校验）。
-```
-
-## 落盘前自检
-
-- [ ] 含 **背景与目标、范围、需求说明** 三章，叙述完整
-- [ ] 2 分钟内可通读；每个需求点 2 ～ 5 条 bullet，一层列表
-- [ ] 场景、按钮行为、校验时机表述清楚，前后一致
-- [ ] 「范围」与需求点中的 **「不考虑」** 口径一致
-- [ ] 全文使用业务语言，术语统一
-- [ ] 仅材料明确涉及时才有「非功能」「待确认」
-
-## 局部替换
-
-只改部分段落时：保留未改章节，替换涉及段落为完整段落；结构仍符合上文骨架。

package/template/skills/apm-review/SKILL.md

@@ -1,111 +0,0 @@
----
-name: apm-review
-description: 结合本仓库上下文对需求做结构化评审，只有当用户主动提及该技能时才可被使用，该技能调用依赖需求 ID。
----
-
-# 需求评审
-
-用户仅提供 **需求 ID**（workitem id）。缺 ID 时索要，不猜测。
-
-## 评审目标
-
-帮助产品经理**梳理需求边界、发现文档中未写清的口径**，并在实现难度较高时给出提示。**不是**为了凑问题而提问——PRD 已足够清晰且无高难度改造时，可只输出少量锚定条目，不必强行列出待澄清项。
-
-## 评审立场
-
-每轮评审从 **前端 / 后端 / 全栈** 中择定一种立场，按该视角输出 **YAML 行级评审**，并执行一次 `apm comment --format=structured`。
-
-### 如何确定立场
-
-1. **用户明示**：用户说明「前端 / 后端 / 全栈 / 仅 UI / 仅接口」等，以用户为准。
-2. **用户未说明**：阅读仓库中与该需求相关的现有代码，推断评审者更贴近哪一端；仍无法判断时，**默认前端**，并在 `reviewer.stance` 使用 `frontend`。
-3. **全栈**：在同一轮评审中同时覆盖 UI 与流程/数据关注点；同一业务点若需澄清，合并为**一条** `clarify`（不要拆成两句重复问题）。
-
-### 各端关注点（互斥优先，减少并行评审重复）
-
-| 维度           | 前端                                                                       | 后端                                                                      |
-| -------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
-| **核心关注**   | 页面、弹窗、Tab、按钮、文案、显隐、交互顺序、校验在界面上的反馈            | 流程节点、业务规则、数据落库、字段口径、汇总/计算逻辑、权限与校验时机     |
-| **典型待澄清** | 哪些页面要改、按钮在什么场景出现、暂存/提交时界面如何提示、只读/可编辑范围 | 默认值与枚举、必填校验在暂存/提交下是否不同、主子表关系、汇总取哪一级数据 |
-| **尽量不提**   | 表结构、API 契约、payload 字段名（留给技术评审）                           | 组件名、具体控件选型、Tab 顺序（除非 PRD 已涉及且影响校验规则）           |
-
-**去重规则**（按立场选用）：
-
-- **前端立场**：只写界面与交互侧待澄清，不写落库/API 契约类问题。
-- **后端立场**：只写流程、规则与数据侧待澄清，不写控件选型、Tab 布局等纯 UI 问题。
-- **全栈立场**：同一业务点合并为一条 `clarify`，**不要**拆成两句意思重复的问题。
-
-## 表述规范（产品经理可读）
-
-1. **产品语言优先**：用「医德考评弹窗」「行风办审批页」等说法；**禁止**用文件路径、组件名、函数名作为论据主体（行号锚定除外）。
-2. **后端可略宽**：必要时可写**表名 / 主表字段名**帮助产品理解数据口径，但仍避免贴大段代码或接口路径。
-3. **锚定 PRD**：每条 `items[]` 必须写 **`anchor: { start, end }`**，与 Read 读到的 `prd.md` 行号一致；**不**在 `body` 里复述该段需求原文。
-4. **问题 = 文档缺口**：只写 PRD **未写清**且**影响本端理解边界**的点。已写清楚的规则不要重复质疑。
-
-## 禁止输出的内容（不要写入 items）
-
-以下内容**一律跳过**，不得创建任何评审条目（**禁止**使用已废弃的 `coordination` 类型）：
-
-- 接口字段名、请求体结构、子表编码、API 路径
-- 前后端谁传哪个参数、与现网实现对齐的改造方案
-- 「联调依赖」「需与后端/前端对齐接口」类事项
-
-上述问题属于**技术评审**范畴，由研发在技术评审阶段处理，本产品评审只面向产品经理可回答的业务澄清。
-
-## 允许的 kind
-
-仅可使用以下三种（YAML 小写）：
-
-| `kind`       | 含义       | 何时使用                         |
-| ------------ | ---------- | -------------------------------- |
-| `clarify`    | 待澄清     | 文档未写清、影响本端理解边界     |
-| `difficulty` | 实现难度高 | 仅改造面大或业务逻辑影响大时     |
-| `business`   | 业务合理性 | 仅方案与业务目标明显冲突或非较优 |
-
-## 评审原则
-
-1. **产品视角优先**：用户侧影响、业务闭环、边界与风险。
-2. **与仓库对齐（能力边界）**：阅读 `AGENTS.md`、`.apm/product-capability-inventory` 及与需求相关的代码，判断改造面。**禁止**用代码证明 PRD 对错；口径不清归入 `clarify`。
-3. **`kind: business`**：仅当方案与业务目标明显冲突或明显非较优解时使用。
-4. **`kind: difficulty`**：仅当改造面大或业务逻辑影响大时使用。
-5. **澄清优先但不泛问**：不阻塞理解则不提问。
-
-## 执行步骤
-
-### 步骤 1：读取 `prd.md`
-
-1. 使用 **Read** 读取 `.apm/workitems/<需求ID>/prd.md`。
-2. 当 PRD 涉及到图片链接时，自动下载对应的图片，存放在 `.apm/workitems/<需求ID>/images/<对应图片名称>.png`，并理解图片内容。
-3. 若 Read **失败**：本步骤记为失败，**终止**，不执行后续步骤。
-
-### 步骤 2：读代码
-
-阅读仓库源码以及 `.apm/product-capability-inventory` 中与需求相关的条目，用于**理解现网能力与边界、判断改造面**。
-
-### 步骤 3：评审与提交
-
-1. **锁定立场**，填入 YAML `reviewer.stance`（`frontend` / `backend` / `fullstack`）。
-2. **拆条**：每条对应 `prd.md` 连续行号；按需设置 `kind`（`clarify` / `difficulty` / `business`）与 `body`。
-3. **成文**：按 **[output-template.md](./output-template.md)** 写 YAML。
-4. 使用 **Write** 写入临时文件（建议 `/tmp/apm-review-<需求ID>.yaml`）。
-5. **自检**：
-   - 每条均有 `anchor`，且无全篇评审；
-   - `stance` 与立场一致；
-   - `clarify` 均为产品可回答的业务问题；
-   - **未**出现 `coordination` 或联调/API 契约类条目；
-   - 无重复语义的条目。
-6. 在项目根目录执行：
-
-   `apm comment <需求ID> --file=<临时文件绝对路径> --format=structured --model=<模型名>`
-
-7. 命令结束后 **删除临时文件**（失败时若需排错可保留，默认仍删除）。
-
-### 步骤 4：回复用户
-
-对用户可见回复 **仅限一张 Markdown 表格**，汇总各步**结果**。**不得**在表格外输出其他内容。
-
-| 步骤              | 结果        | 说明                                                                            |
-| ----------------- | ----------- | ------------------------------------------------------------------------------- |
-| 1. 读取 prd.md    | 成功 / 失败 | 实际路径；失败时写原因                                                          |
-| 2. 评审与 comment | 成功 / 失败 | 临时文件；`apm comment` 情况；**注明 stance**（frontend / backend / fullstack） |
-| 3. 清理临时文件   | 成功 / 失败 | —                                                                               |

package/template/skills/apm-review/output-template.md

@@ -1,60 +0,0 @@
-# 评审输出模板（YAML · structured）
-
-使用 **YAML** 文件提交行级评审；每条必须锚定 `prd.md` 行号。全文使用**产品经理可读**的表述；**不**在 `body` 里复述需求原文。
-
-## 文件示例
-
-```yaml
-reviewer:
-  model: Auto
-  stance: frontend # frontend | backend | fullstack
-
-items:
-  - anchor: { start: 44, end: 55 }
-    kind: clarify
-    body: |
-      - 「类型」隐藏后，统计分析页的「分类」筛选是否一并去掉，导出是否统一走临床模板
-
-  - anchor: { start: 59, end: 67 }
-    kind: clarify
-    body: |
-      - （PRD 已写清且无缺口时可省略该条，不要写「仅锚定」空条目）
-
-  - anchor: { start: 83, end: 106 }
-    kind: business
-    body: |
-      - 方案与业务目标冲突的原因；可给替代思路
-
-  - anchor: { start: 108, end: 132 }
-    kind: difficulty
-    body: |
-      - 用产品语言说明改造面：涉及哪些页面/流程/规则，为何面大
-```
-
-## kind 与技能表述
-
-| `kind`（YAML 小写） | 含义       | 说明                         |
-| ------------------- | ---------- | ---------------------------- |
-| `clarify`           | 待澄清     | 文档未写清、影响本端理解边界 |
-| `difficulty`        | 实现难度高 | 仅改造面大或业务逻辑影响大时 |
-| `business`          | 业务合理性 | 仅方案明显不合理时           |
-
-**禁止**使用 `coordination`（联调依赖已废弃）：接口/联调类事项不要写入评审。
-
-## 字段规则
-
-| 字段              | 规则                                                       |
-| ----------------- | ---------------------------------------------------------- |
-| `reviewer.stance` | 必填：`frontend` / `backend` / `fullstack`                 |
-| `reviewer.model`  | 建议填写；可被 CLI `--model` 覆盖                          |
-| `anchor`          | 必填 `{ start, end }`，1-based 闭区间，与 Read `prd.md` 行号一致 |
-| `body`            | 必填；产品语言；**禁止**全篇评审（必须有行号）             |
-| 同区间多类型      | 可拆成多条 `items`（例如同时 `clarify` 与 `difficulty`）   |
-
-## 提交命令
-
-```bash
-apm comment <需求ID> --file=/tmp/apm-review-<需求ID>.yaml --format=structured --model=<模型名>
-```
-
-`.yaml` / `.yml` 扩展名在未指定 `--format` 时默认按 structured 解析。

package/template/theater-skills/README.md

@@ -1,13 +0,0 @@
-## 剧场技能
-
-供剧场（Theater）会话中各角色 Agent 使用的技能，由 `apm init` 复制到 `.apm/theater-skills/`，可用 `apm update-theater-skills` 从 CLI 内置模板重置。
-
-`THEATER_JOB` 开始时会自动 `pull-session`，将平台会话文档下载到 `.apm/theater-sessions/<sessionId>/docs/`。`docs/` 下文档变更后通过 `apm sync-session-document` 同步到平台；**Agent 对话日志不上传**。
-
-## 目录
-
-| 技能                   | 说明                                                                                                     |
-| ---------------------- | -------------------------------------------------------------------------------------------------------- |
-| `apm-theater-prd/`     | 产品经理：维护会话 PRD（`.apm/theater-sessions/<sessionId>/docs/prd.md`）并同步到平台                    |
-| `apm-theater-backend/` | 后端：`docs/backend.md`（技术评审实现思路）、`docs/api.md`（前端联调接口说明）；增删改查与同步规则同 PRD |
-| `apm-theater-dev/`     | 开发：按 `sessionId` 全自动编码（切分支、Quick/Spec、提交推送、同步 `docs/` 文档）                       |

package/template/theater-skills/apm-theater-backend/SKILL.md

@@ -1,115 +0,0 @@
----
-name: apm-theater-backend
-description: 剧场会话后端文档：在 .apm/theater-sessions/<sessionId>/docs/ 维护 backend.md（技术评审用实现思路）与 api.md（前端联调用接口说明），落盘后同步到平台会话文档。仅当用户 @ 本技能时使用。
-disable-model-invocation: true
----
-
-# 剧场会话后端文档
-
-在剧场会话上下文中维护后端交付文档：
-
-| 文件                  | 用途                                                         |
-| --------------------- | ------------------------------------------------------------ |
-| **`docs/backend.md`** | **后端技术文档**：如何实现该需求，实现思路写清，供技术评审   |
-| **`docs/api.md`**     | **接口联调文档**：涉及接口与参数，给前端；多接口协作须写清楚 |
-
-本地路径均在 **`.apm/theater-sessions/<sessionId>/docs/`**；落盘后须通过 CLI 同步到平台「会话文档」。
-
-`THEATER_JOB` 开始时会自动 pull 平台文档到本地。Agent **对话日志不上传**；仅 `docs/` 下业务文档在变更后同步。
-
----
-
-## 输入
-
-| 字段            | 规则                                                                                   |
-| --------------- | -------------------------------------------------------------------------------------- |
-| **`sessionId`** | **必填**。剧场会话 ID，与 `.apm/theater-sessions/<sessionId>/` 目录名一致。            |
-| **目标文档**    | 按用户意图选择 `backend.md` 或 `api.md`；未指明时结合上下文判断，仍不明则询问。        |
-| **会话上下文**  | 若由 `THEATER_JOB` 触发，`theaterSessionId` 即 `sessionId`；缺省时向用户索要，不猜测。 |
-
----
-
-## 文件路径
-
-以下规则对 **`backend.md`**、**`api.md`** 均适用（将 `<文件名>` 替换为对应文件）：
-
-| 操作     | 路径 / 方式                                                                           |
-| -------- | ------------------------------------------------------------------------------------- |
-| **新增** | 创建 `.apm/theater-sessions/<sessionId>/docs/<文件名>`（`docs` 目录不存在时一并创建） |
-| **编辑** | 更新上述文件（Write / StrReplace）                                                    |
-| **查阅** | 使用 **Read** 工具阅读上述文件                                                        |
-| **删除** | **不支持**。不要删除该文件，也不要尝试从平台删除对应文档。                            |
-
----
-
-## 同步到平台（新增 / 编辑后必做）
-
-本地文档 **新增或内容变更后**执行：
-
-```bash
-apm sync-session-document <sessionId> --file docs/backend.md
-apm sync-session-document <sessionId> --file docs/api.md
-```
-
-- 命令会调用平台接口 **新增或更新** 该会话的产物文档（按 `fileName` 幂等）。
-- **查阅**（Read）**不需要**执行同步。
-- **不要**同步 Agent 对话日志（`sessions/` 等）；仅同步 `docs/` 业务文档。
-- 同步失败时：在回复中说明错误，**不要**声称已写入平台。
-
----
-
-## 撰写要求
-
-撰写前建议 **Read** `.apm/theater-sessions/<sessionId>/docs/prd.md`（若存在），与需求范围对齐。
-
-### `backend.md`（技术评审）
-
-须 **Read** [apm-theater-backend-template.md](./apm-theater-backend-template.md)，按模板**章节粒度**组织正文（需求摘要 → 方案总览 → 库表 → 分层 → 核心流程 → 实现状态 → 待办 → 风险）。核心是 **实现思路写清楚**；接口参数明细放 `api.md`。
-
-### `api.md`（前端联调）
-
-须 **Read** [apm-theater-api-template.md](./apm-theater-api-template.md)，按模板**章节粒度**组织正文（基础约定 → 数据模型 → 接口清单 → 接口明细 → 页面配合 → 错误场景 → 联调清单）。写清每个功能的**方法、路径、参数、响应**；多接口协作须写**步骤、顺序、副作用与前端展示规则**。
-
----
-
-## 流程
-
-### 1. 锚定会话与文档
-
-确认 **`sessionId`** 与目标文件（`backend.md` / `api.md`）。
-
-### 2. 查阅（只读）
-
-**Read** `.apm/theater-sessions/<sessionId>/docs/<文件名>`。
-
-- 文件不存在：说明尚未创建，询问是否新建；**不要**编造正文。
-
-### 3. 新增 `backend.md`
-
-1. **Read** `prd.md`（若存在）与 [apm-theater-backend-template.md](./apm-theater-backend-template.md)。
-2. **Write** 落盘至 `.apm/theater-sessions/<sessionId>/docs/backend.md`。
-3. **`apm sync-session-document <sessionId> --file docs/backend.md`**。
-
-### 4. 新增 `api.md`
-
-1. **Read** `prd.md`、必要时 `backend.md`，以及 [apm-theater-api-template.md](./apm-theater-api-template.md)。
-2. **Write** 落盘至 `.apm/theater-sessions/<sessionId>/docs/api.md`。
-3. **`apm sync-session-document <sessionId> --file docs/api.md`**。
-
-### 5. 编辑
-
-1. **Read** 现有文件与对应模板（若本会话尚未读过）。
-2. **Write** 或 **StrReplace** 落盘。
-3. **`apm sync-session-document <sessionId> --file docs/<文件名>`**。
-4. 简要说明变更要点。
-
----
-
-## Guardrails
-
-- **不要删除** `backend.md`、`api.md`，也不要删除平台会话文档。
-- **不要**在无 `sessionId` 时写入任意目录。
-- **新增或编辑后必须同步** `docs/` 文档；仅 Read 时不同步。
-- **不要**上传或同步 Agent 对话日志。
-- 同步失败时如实报告，不假装成功。
-- `backend.md` 与 `api.md` 分工明确：方案在 backend，接口契约在 api；待确认项写入文档，避免阻塞主文。

package/template/theater-skills/apm-theater-backend/apm-theater-api-template.md

@@ -1,146 +0,0 @@
-# 接口联调文档模板
-
-**定位**：给**前端**联调用的接口说明——写清涉及到的接口、参数、响应与页面配合方式；若某功能需**多个接口配合**（如先上传再绑定），须写清**步骤、顺序与副作用**。
-
-撰写前建议 **Read** `prd.md`、必要时 **Read** `backend.md`，与需求及后端方案对齐。
-
----
-
-## 正文骨架
-
-按下列章节组织（编号可依项目调整，但**顺序与粒度**保持一致）：
-
-```markdown
-# [需求标题] — 接口联调文档
-
-> 后端模块：`XxxController`（`/模块前缀`）
-
-## 1. 基础约定
-
-### 1.1 Base URL
-
-（开发/测试示例地址；是否带 context-path）
-
-### 1.2 鉴权
-
-（Header / Token 名称；本期是否有额外权限参数）
-
-### 1.3 统一响应体
-
-（字段表 + 成功/失败 JSON 示例；写明业务数据在哪个字段，如 `result` / `data`）
-
-### 1.4 特殊接口说明（若有）
-
-（如：文件流下载无 JSON 包装、预览返回路径给现网组件等）
-
----
-
-## 2. 数据模型 `[实体名]`
-
-列表、详情、编辑共用的核心字段表（字段 | 类型 | 说明）；**前端展示规则**写进说明列（如某字段为 `null` 时列表留空）。
-
----
-
-## 3. 接口清单
-
-| 方法 | 路径 | 说明 |
-| ---- | ---- | ---- |
-| …    | …    | …    |
-
-未落地接口在说明列标 **待后端实现/提供**。
-
----
-
-## 4. 接口明细
-
-### 4.1 [接口名称]
-
-**[METHOD]** `完整路径`
-
-**Query / Body 参数表**（参数 | 必填 | 默认 | 说明）
-
-**响应**（`result` / `data` 结构；复杂时给 JSON 示例）
-
-**前端展示/交互要点**（与本接口直接相关的 UI 规则）
-
-**说明**（业务副作用、与 PRD 的对应关系）
-
-### 4.2 …
-
-#### 多步骤协作（如「行内上传 + 绑定」）
-
-分步骤写清，每步单独小节：
-
-1. **步骤 1**：上传接口 — 入参、成功时哪个字段是后续要用的路径
-2. **步骤 2**：编辑/保存接口 — Body 示例（首次 / 更换两种）、副作用（如是否更新 `submitDate`）、成功后是否刷新列表
-
-**注意**：只读页面不调写接口等 PRD 约束写在本节。
-
-### 4.x 易混淆接口对比（若存在）
-
-用表格对比「入口 | 接口 | 内容」，避免前端联调混用。
-
----
-
-## 5. 前端页面与接口配合
-
-按页面用缩进树或列表写调用链，例如：
-
-### 5.1 列表页
-
-加载列表 → GET /list
-├─ 新增 → …
-├─ 删除 → …
-└─ 某列操作 → 多步 upload → edit
-
-### 5.2 新增页 / 详情页
-
-…
-
----
-
-## 6. 错误场景
-
-| 场景 | 表现                                    |
-| ---- | --------------------------------------- |
-| …    | `success=false` 的 message 或 HTTP 状态 |
-
----
-
-## 7. 联调检查清单
-
-- [ ] …
-- [ ] …
-```
-
----
-
-## 写法要点
-
-| 类型       | 写法要点                                                                    |
-| ---------- | --------------------------------------------------------------------------- |
-| 接口清单   | 先总表后明细；路径、方法、一句话说明齐全                                    |
-| 单接口     | 参数表 + 响应结构 + **前端展示要点**；复杂 Body 给完整 JSON 示例            |
-| 多接口协作 | 分步骤编号；每步写清入参、成功判据、传给下一步的字段；写副作用与是否刷新    |
-| 数据模型   | 共用实体一次定义；`null` / 空值的 UI 处理写在字段说明或列表要点里           |
-| 页面配合   | 按列表/新增/详情分节；用树状流程串起接口，不只堆接口表                      |
-| 易混淆能力 | 同类下载/预览等多入口时，用对比表说明差异                                   |
-| 待实现     | 明确标 **待后端实现**；错误场景与检查清单可预留项                           |
-| 项目约定   | 遵循目标项目既有风格（如 Jeecg `Result`、APM `{ data }`）；不擅自改路径规范 |
-
----
-
-## 落盘前自检
-
-- [ ] 含 **基础约定、数据模型、接口清单、接口明细、页面配合、错误场景、联调清单**
-- [ ] 每个 PRD 功能点在「页面配合」或明细中能找到对应接口
-- [ ] 多步骤流程（上传+保存等）顺序与字段传递写清
-- [ ] 列表/详情/空值展示规则前端可直接照做
-- [ ] 与 `backend.md` 不矛盾；未实现接口已标注
-- [ ] 检查清单覆盖 PRD 关键验收点
-
----
-
-## 局部替换
-
-只改部分接口或页面时：同步更新 **§3 清单**、**§4 明细**、**§5 页面配合** 与 **§7 检查清单** 中相关条目。

package/template/theater-skills/apm-theater-backend/apm-theater-backend-template.md

@@ -1,132 +0,0 @@
-# 后端技术文档模板
-
-**定位**：说明后端**准备如何实现该需求**，实现思路写清楚，供**技术评审**。接口参数与前端联调细节放在 `api.md`，本文聚焦方案、数据、流程与实现状态。
-
-撰写前须 **Read** `.apm/theater-sessions/<sessionId>/docs/prd.md`（若存在）。
-
----
-
-## 正文骨架
-
-```markdown
-# [需求标题] — 后端技术方案
-
-> 关联 PRD：[prd.md](./prd.md)
-
-## 1. 需求摘要
-
-（一段话概括本期做什么；**本期不做**单独列出）
-
----
-
-## 2. 方案总览
-
-| 项       | 说明              |
-| -------- | ----------------- |
-| 模块     | …                 |
-| 数据表   | …                 |
-| 接口前缀 | …                 |
-| 实现风格 | …                 |
-| 代码现状 | 已落地 / 待完善项 |
-
-（与同类既有模块的差异、核心设计决策 1 ～ 3 句）
-
----
-
-## 3. 数据库设计
-
-（迁移脚本路径若有则写）
-
-| 字段 | 类型 | 说明 |
-| ---- | ---- | ---- |
-| …    | …    | …    |
-
-**索引**、**约束**、注释与命名注意点。
-
----
-
-## 4. 后端分层结构
-
-（目录树或包结构：entity / mapper / service / controller）
-
----
-
-## 5. 核心业务流程
-
-按 PRD 场景分小节（如 5.1 新增、5.2 行内上传…），每节写清：
-
-1. 步骤顺序
-2. 校验规则与 **不做什么**
-3. 副作用（写库、写文件、更新时间等）
-4. **待实现** 项单独标出
-
-多接口协作写清与通用能力（如上传）的组合方式；易混淆能力用表格对比。
-
----
-
-## 6. 接口能力对照（实现状态）
-
-| 能力 | 状态         | 备注 |
-| ---- | ------------ | ---- |
-| …    | ✅ / ⚠️ / ❌ | …    |
-
-（评审用速览表；细节不在此重复，见 `api.md`）
-
----
-
-## 7. 菜单与权限（若涉及）
-
----
-
-## 8. 配置与部署
-
-| 配置 | 说明 |
-| ---- | ---- |
-| …    | …    |
-
----
-
-## 9. 待办清单（开发任务）
-
-1. …
-2. …
-
----
-
-## 10. 风险与注意点
-
-- …
-```
-
-按需删减章节（如无独立菜单配置可省略 §7）；**核心业务流程**与 **待办清单** 不可省。
-
----
-
-## 写法要点
-
-| 类型       | 写法要点                                                                |
-| ---------- | ----------------------------------------------------------------------- |
-| 需求摘要   | 与 PRD 一一对应；**本期不做** 写清，避免评审范围漂移                    |
-| 方案总览   | 模块、表、接口前缀、与存量模块关系；**代码现状** 如实（已做/待补）      |
-| 数据库     | 字段业务含义、NULL 语义、何时写入；索引与 PRD 约束（如不做唯一性）对齐  |
-| 核心流程   | 分场景编号；写清两步/多步协作、副作用、与 PRD 差异；**待实现** 醒目标注 |
-| 实现状态表 | 能力粒度与 PRD 验收点对齐；用 ✅ ⚠️ ❌ 或文字状态                       |
-| 待办清单   | 可执行任务，与 §6 中未完成项对应                                        |
-| 风险       | 安全、磁盘、与相似模块混淆等；不写接口 JSON                             |
-
----
-
-## 落盘前自检
-
-- [ ] 评审人不读代码也能理解**怎么做、差什么**
-- [ ] 与 `prd.md` 范围一致，「本期不做」无遗漏
-- [ ] 核心流程覆盖 PRD 各场景，含多步协作与副作用
-- [ ] §6 实现状态与 §9 待办一致
-- [ ] 接口契约细节在 `api.md`，本文不重复参数表
-- [ ] 未臆造已完成功能；待做项已列出
-
----
-
-## 局部替换
-
-只改部分能力时：同步更新 **§5 流程**、**§6 状态表**、**§9 待办** 与 **§10 风险** 中相关条目。