@xtalpi/agentic-lab-skills 0.0.9 → 0.0.11

package/skills/lab-flow-designer/references//344/270/232/345/212/241/346/265/201/347/250/213/346/226/207/346/241/243/346/240/207/345/207/206.md

@@ -1,208 +1,216 @@
-# 业务流程文档标准
-
-本文约定**流程说明类 Markdown**（下称「流程文档」）须具备的结构、字段与写法，便于人工或工具检查文档完整性，并提高下游（如流程注册包生成、门控实现）的**正确性与稳定性**。
-
-**结构对齐参考**（不要求逐字一致）：与本 skill 内 [`embedded-template/valves/示例数据与校验门控.md`](../embedded-template/valves/示例数据与校验门控.md) 及 [`embedded-template/SKILL.md`](../embedded-template/SKILL.md) 所示范的章节与表格粒度保持一致即可。
-
----
-
-## 1. 文档级要求
-
-| 项 | 要求 |
-|----|------|
-| 顶层标题 | 须有明确流程名称（可与 `# 业务执行手册描述` 等总标题共存）；读者能一眼识别**哪条业务流程**。 |
-| 章节编号 | 一级章节建议使用 **`## 1.` … `## 6.`** 数字标题，顺序与下表「必备章节」一致；子章节用 `### 2.1` 等形式。 |
-| 分隔与排版 | 大节之间可用 `***` 等分隔；表格列对齐可读即可。 |
-| 术语一致 | **数据池**在正文与 YAML 中须与「数据池表」中的**显示名称**逐字一致（含标点、中间点「·」等）。 |
-| 门控名称 | 拓扑边、YAML `name`、各小节标题中的门控名称须**完全一致**。 |
-| 门控逻辑与能力边界 | 门控内的**条件、分支、依赖、所调 API 与字段**须满足下文 **§3.1～§3.3**：逻辑可判定、能力在 SDK 内有据、涉及 Process/SDK 时参数与格式可校验；**禁止**依赖未文档化或本 skill **不支持**的接口与字段。 |
-
----
-
-## 2. 必备章节（按顺序）
-
-### 2.1 `## 1. 流程元信息`（必备）
-
-使用 **Markdown 表格**，至少包含下列**属性列**（列名可微调，但语义须覆盖）：
-
-| 建议列「属性」 | 建议含义 |
-|----------------|----------|
-| 流程标识 | 机器可读 ID（如 `fragment`），稳定、唯一。 |
-| 流程名称 | 人类可读名称。 |
-| 版本 | SemVer 或文档版本号。 |
-| 业务摘要 | 1～3 句说明业务目标与边界。 |
-
-**检查点**：四行均有非空「值」；流程标识与目录/工程命名策略一致（若下游有约定）。
-
----
-
-### 2.2 `## 2. 记录（Record）`（必备）
-
-须说明：
-
-1. **记录**的业务定义（最小流转单元是什么）。  
-2. **入口字段**与**富化字段**的区分。  
-3. **入口字段表**：建议列 **`字段名` | `类型` | `必填`（Y/N）| `说明`**；说明中可写默认值、单位、枚举取值提示。  
-4. **按门控分组的富化字段**（推荐）：对每个会写回记录的门控，使用独立小节，例如  
-   `### 2.x 门控「<门控显示名称>」可能写入的字段`  
-   表格建议列：**字段名 | 类型 | 说明**；枚举/布尔/多分支须在说明或单独「属性」中写清。
-
-**检查点**：每个在 §5 出现且会修改记录的门控，在 §2 中有对应富化字段说明（或可显式写「无新增字段」）。  
-**检查点**：同一字段在全篇命名一致（中英混排时避免同一语义两个不同列名）。
-
----
-
-### 2.3 `## 3. 数据池（Stash / Pool）`（必备）
-
-使用 **Markdown 表格**，建议列：
-
-| 显示名称 | 逻辑 ID | 角色 | 池中记录的业务含义 |
-|----------|---------|------|---------------------|
-
-**角色**建议取值：`入口池` / `中间池` / `异常池` / `终点池` 等，与拓扑一致。
-
-**检查点**：每个在拓扑与门控 YAML 中出现的池，表中有一行；**显示名称**与 YAML `input`/`output` 中的池名一致。  
-**检查点**：**逻辑 ID** 在同一文档内唯一（如 `stash_input`），且仅使用字母、数字、下划线（便于下游映射）。
-
----
-
-### 2.4 `## 4. 池间流转（拓扑）`（必备）
-
-须同时包含：
-
-1. **图示**：`mermaid` 或 `graph` / `plain` 代码块，表达**有向边**；边上标注**门控显示名称**（与 §5 一致）。  
-2. **文字补充**：用列表说明每个门控的**入口池集合**、**出口分支语义**；合流门控须写明多入口来源。
-
-**检查点**：图中每条边在「文字补充」中可追溯到业务含义；无悬空池（除明确废弃外）；终点池可达。
-
----
-
-### 2.5 `## 5. 门控（Valve）`（必备）
-
-#### 5.1 门控总述（建议独立小节）
-
-说明门控的**检查—路由**语义；并统一约定 YAML 字段含义，建议至少包含：
-
-| 键 | 含义 |
-|----|------|
-| `valve_id` | **可选**。若提供，须为文档内稳定、唯一的 ID（如 `valve_1`），便于脚本与配置引用；不提供时下游可用 `name` + `order` 等推导门控实例。 |
-| `name` | **必备**。与拓扑、§2 小节标题一致的门控显示名称。 |
-| `order` | **必备**。整数顺序，与依赖关系一致。 |
-| `input` | **必备**。`primary` 必填；合流时增加 `secondary`（及文档中说明是否可同时进单）。 |
-| `output` | **必备**。列表；每项含**目标池**与**路由条件**（自然语言须与 §2 字段名可对读）。 |
-
-若文档约定**列表查询 limit/offset** 等实现参数，须写在本节「查询约定」或各门控下，便于生成脚本照抄。
-
-#### 5.2 每个门控子节（必备结构）
-
-对每个门控，建议按下列顺序组织（可合并标题，但**信息不得缺**）：
-
-1. **门控标题**：`### 5.x <门控显示名称>`（编号与 `order` 建议一致或递增）。  
-2. **YAML 代码块**：`yaml`，须含 `name`、`order`、`input`、`output`；**`valve_id` 可选**（若写则全文档唯一）。  
-   - 目标池键名可使用 `Stash:` 等非标准键，但须在总述或脚注说明与实现侧 **pool 显示名称** 的对应关系。  
-3. **化合物 / 外部数据查询方式**（若本门控需要）：说明查哪类库、用哪些入口字段作键、汇总规则等。  
-4. **字段映射表**（若存在库表/API 列与门控加工字段对应）：两列表头清晰（如「门控加工数据 | 库字段」）。  
-5. **数据处理规则表**（强烈推荐）：列至少包含 **`序号` | `规则摘要` | `条件要点` | `业务动作或结果`**；序号建议 **章内连续小数编号**（如 `1.1`、`1.2`，与门控章节号前缀一致），便于脚本注释逐条对应。  
-6. **操作员步骤**（若为人工门控）：编号列表，步骤可执行、可验收。
-
-**Process 批量提交（可选）**：若门控需触发 **Rhea / 设备侧批量提交任务**，须在流程文档中写明调用时机、**`items` 每条**中的 **`process`（流程模板名，即 process_name 语义）**、**`params` / `table_objects` 等如何从业务数据拼装**，以及 **`baseURL`（服务根地址）的语义来源**（配置、环境变量、订单字段等，由集成解析为字符串 URL）。**path、HTTP 方法** 由 SDK 固定，流程文档**不要求**写 path / method；生成脚本时映射为 SDK 中对应方法（见 [`references/agentic-lab-sdk.md`](agentic-lab-sdk.md)；Wire 细节见 [`references/rhea-api/execute_process_batch.md`](rhea-api/execute_process_batch.md) 供预检对照 `items[]` 形状）。
-
-**检查点**：每个 `output` 条件互斥或可判定优先级在文中有说明；缺料/失败等异常分支有定义。  
-**检查点**：`input.secondary` 存在时，§4 文字补充中已描述合流。
-
----
-
-### 2.6 `## 6. 知识库 / 外部主数据`（按需）
-
-若规则依赖**库外主数据**（如化合物知识库），使用表格列出**逻辑键、含义、类型/枚举**即可；具体 API 与表名可由实现文档补充，但流程文档须写清**业务字段语义**与**与记录字段的对应关系**。
-
-无外部依赖时可写「本节不适用」或省略，但须在 §1 或概述中说明。
-
----
-
-## 3. 数据与规则质量要求
-
-### 3.0 表格（通用）
-
-| 项 | 要求 |
-|----|------|
-| 枚举与布尔 | 「枚举」类型须在说明或属性列列出可选值；布尔字段说明 `true`/`false` 业务含义。 |
-| 单位与格式 | 质量、体积等字段注明单位（如 mg）；日期/批次格式若影响规则，在说明或「属性」中写明。 |
-| 规则可执行 | 「条件要点」应能映射到 §2 字段或外部查询结果；避免纯口语无字段锚点。 |
-| 编号稳定 | 规则序号在全篇不重复；门控内 `1.1` 与门控 `2` 的 `2.1` 可并存，但同一门控内不重复。 |
-
-### 3.1 门控逻辑须严谨、禁止模糊定义
-
-合规预检与人工评审须能**逐条判定**门控行为，下列情形视为**不通过（阻断）**或须改为可判定表述后再生成：
-
-- **不可判定的条件**：`output` 条件、数据处理规则中的「条件要点」依赖「视情况」「酌情」「必要时」「由业务决定」等**无唯一真值**的措辞，且文中**未**给出可操作定义或枚举。  
-- **无字段锚点**：条件仅停留在口语（如「资源够」）而未绑定 §2 字段、外部查询结果或 YAML 中可解析的键。  
-- **分支冲突**：同一门控多条 `output` 在相同数据状态下可同时为真，且文档**未**说明互斥、优先级或求值顺序。  
-- **不完备**：文档已描述业务异常（缺料、超时、失败）但**无**对应出口池或规则行，导致路由语义不完整。
-
-**建议写法**：每条规则写清「若 **字段 A** 与 **字段 B** 满足 **关系 R**，则 **动作** / **路由到池 P**」；比较类写明单位与边界（如 `≤`、严格小于、闭区间）。
-
-### 3.2 依赖项、API 能力、数据字段须可支持（须提前拦截）
-
-预检时须将流程文档中出现的**依赖与调用**，与 skill 内 **[`references/agentic-lab-sdk.md`](agentic-lab-sdk.md)**（及与 Rhea 等 **[`references/rhea-api/`](rhea-api/)** 中已列 Wire）**逐项对照**：
-
-| 类别 | 检查 | 不通过时的处理 |
-|------|------|----------------|
-| **外部依赖** | 设备、第三方 HTTP、未在 SDK 出现的内部服务等：须写清**对接边界**（谁调谁、成功/失败判据）；仅有名称无契约的，**阻断**并要求补「数据从哪来、失败怎么办」。 |
-| **SDK / `this.context` 能力** | 文档中「调用××」须对应 **agentic-lab-sdk 已列举**的方法名与语义；若出现**未在 SDK 文档出现**的方法、臆造 RPC、或超出已文档化能力的描述，须 **阻断**，在《流程文档合规问题与优化建议》中写明 **「不支持的 API：…」** 并给出 **可替换的已支持能力** 或要求**删改流程**。 |
-| **数据字段** | 规则、映射、YAML 条件中引用的字段须在 **§2** 或映射表中有定义，且**全篇拼写一致**；引用不存在字段或与 Schema 明显冲突的，**阻断**。 |
-
-### 3.3 Process / 任务提交 / 其它 SDK 调用的参数与格式
-
-凡流程文档出现 **Process 执行、批量任务提交、或任何明确绑定 SDK 的写操作/查询参数**，除满足 **§2.5 Process 批量提交** 小节外，还须满足（否则预检 **不通过**）：
-
-1. **方法名**：与 [agentic-lab-sdk.md](agentic-lab-sdk.md) 中条目一致，且用途与文档叙述一致。  
-2. **请求体与类型**：对 **Process 批量提交**，须能整理出 **`items[]`**（与 **[`rhea-api/execute_process_batch.md`](rhea-api/execute_process_batch.md)** 请求体中 `items` 一项同形）：每条至少含 **`process`**、**`params`**（键、类型、默认值或来源字段）；若流程需绑定业务表记录，则须说明 **`table_objects`**（表名、主键与 ticket 明细的对应）；并须说明 **`baseURL`** 如何得到；**禁止**仅写「组装 JSON」而无键级说明。  
-3. **查询类接口**：分页策略须与 [agentic-lab-sdk.md](agentic-lab-sdk.md) 中该方法的分页方式一致或显式写出分页参数；**`filter`** 须说明字段名与算子意图，避免无法落地的自然语言。  
-4. **Process 批量提交与 HTTP**：流程文档约束 **`items`**、**`baseURL` 语义**及任务参数；**不要求**写 path / HTTP 方法（由 SDK 封装）。
-
-**预检产出**：凡属 **§3.2 / §3.3** 的不通过项，须在《流程文档合规问题与优化建议》中单独列出 **「不支持或不可生成项」**，避免进入代码生成阶段才发现无法对接。
-
----
-
-## 4. 合规检查清单（自检用）
-
-打印或复制下列清单，对目标流程文档逐项打勾：
-
-- [ ] **§1 流程元信息**表四要素齐全。  
-- [ ] **§2** 含入口字段表；每个会写数的门控有富化字段小节或显式无字段说明。  
-- [ ] **§3** 数据池表覆盖拓扑与 YAML 中全部池名；逻辑 ID 唯一。  
-- [ ] **§4** 含图 + 文字补充；合流与多出口均有叙述。  
-- [ ] **§5** 每个门控有 YAML；`name`、`order`、`input`、`output` 完整；`name` 与 §4 边标签一致；若提供 `valve_id` 则全文档无重复。  
-- [ ] 需查询库的门控含**查询方式**；需映射的含**字段映射表**。  
-- [ ] 含计算/判定的门控含**数据处理规则表**及稳定**序号**。  
-- [ ] 人工门控含**操作员步骤**（如适用）。  
-- [ ] **§6** 或显式声明无外部主数据依赖。  
-- [ ] 全文**池名、门控名、字段名**与 YAML、表格、图示无冲突。  
-- [ ] **§3.1**：门控规则与 `output` 条件可判定，无未定义模糊用语；分支互斥或优先级已说明。  
-- [ ] **§3.2**：所提依赖、**SDK/API**、字段均在 **agentic-lab-sdk**（及已列 rhea-api）与 §2 中有依据；**无不支持或未文档化的 API**。  
-- [ ] **§3.3**：凡 **Process / 任务提交 / SDK 调用**，**`items`** 与 **`baseURL` 语义**可对照 **agentic-lab-sdk + rhea-api** 校验；其它查询的分页与 **filter** 意图可落地；**不**要求流程写 path/HTTP 方法。
-
----
-
-## 5. 与流程注册包生成的关系
-
-使用 skill **`lab-flow-designer`** 时：**仅「初次从流程说明生成整包」**须先按主 `SKILL.md` 中 **「流程文档合规预检」** 对照本标准执行；不通过则不得写入产出目录，并须给出《流程文档合规问题与优化建议》（结构见该节）。**对已有流程注册包做增量修改**的会话不要求流程文档预检（可选自行对照本标准做人工评审）。
-
-生成器依赖（初次生成路径）：
-
-- §3 → `pools/*.md` 文件名与 Schema；  
-- §4 + §5 → 根 `SKILL.md` 流程图与**连接关系**列表；  
-- §5 → `valves/*.md`、`scripts/*.js` 及规则注释序号；  
-- §2、字段映射、查询方式 → 脚本内 `ticket.detail` 与按 [agentic-lab-sdk.md](agentic-lab-sdk.md) 调用对应方法；  
-- 流程中若需 **Process 批量提交** → 脚本内按 SDK 对应方法执行（参数以流程文档为准，见 `references/agentic-lab-sdk.md` 与 `references/rhea-api/execute_process_batch.md`）。
-
-主 `SKILL.md` 中 **门控脚本编写指引** 约定：生成 `scripts/*.js` 与 `pools/*.md` Schema 时，**仅实现或收录流程文档在本门控逻辑或池字段描述中明确写出的**查询、回写、路由与字段行，**禁止**为对齐 embedded 示例而附加未文档化的代码或字段。
-
-**流程文档越符合本标准，生成结果越稳定**；检查清单亦可作为 PR / 评审附件使用。
-
----
-
-## 6. 修订与版本
-
-本标准随 `lab-flow-designer` skill 与常见流程说明实践演进可修订；建议在文末或 Git 记录中保留**修订日期与变更摘要**。
+# 业务流程文档标准
+
+本文约定**流程说明类 Markdown**（下称「流程文档」）须具备的结构、字段与写法，便于人工或工具检查文档完整性，并提高下游（如流程注册包生成、门控实现）的**正确性与稳定性**。
+
+**结构对齐参考**（不要求逐字一致）：与本 skill 内 [`embedded-template/valves/示例数据与校验门控.md`](../embedded-template/valves/示例数据与校验门控.md) 及 [`embedded-template/SKILL.md`](../embedded-template/SKILL.md) 所示范的章节与表格粒度保持一致即可。
+
+---
+
+## 1. 文档级要求
+
+| 项 | 要求 |
+|----|------|
+| 顶层标题 | 须有明确流程名称（可与 `# 业务执行手册描述` 等总标题共存）；读者能一眼识别**哪条业务流程**。 |
+| 章节编号 | 一级章节建议使用 **`## 1.` … `## 6.`** 数字标题，顺序与下表「必备章节」一致；子章节用 `### 2.1` 等形式。 |
+| 分隔与排版 | 大节之间可用 `***` 等分隔；表格列对齐可读即可。 |
+| 术语一致 | **数据池**在正文与 YAML 中须与「数据池表」中的**显示名称**逐字一致（含标点、中间点「·」等）。 |
+| 门控名称 | 拓扑边、YAML `name`、各小节标题中的门控名称须**完全一致**。 |
+| 门控逻辑与能力边界 | 门控内的**条件、分支、依赖、所调 API 与字段**须满足下文 **§3.1～§3.3**：逻辑可判定、能力在 SDK 内有据、涉及 Process/SDK 时参数与格式可校验；**禁止**依赖未文档化或本 skill **不支持**的接口与字段。 |
+
+---
+
+## 2. 必备章节（按顺序）
+
+### 2.1 `## 1. 流程元信息`（必备）
+
+使用 **Markdown 表格**，至少包含下列**属性列**（列名可微调，但语义须覆盖）：
+
+| 建议列「属性」 | 建议含义 |
+|----------------|----------|
+| 流程标识 | 机器可读 ID（如 `fragment`），稳定、唯一。 |
+| 流程名称 | 人类可读名称。 |
+| 版本 | SemVer 或文档版本号。 |
+| 业务摘要 | 1～3 句说明业务目标与边界。 |
+
+**检查点**：四行均有非空「值」；流程标识与目录/工程命名策略一致（若下游有约定）。
+
+---
+
+### 2.2 `## 2. 记录（Record）`（必备）
+
+须说明：
+
+1. **记录**的业务定义（最小流转单元是什么）。  
+2. **入口字段**与**富化字段**的区分。  
+3. **入口字段表**：建议列 **`字段名` | `类型` | `必填`（Y/N）| `说明`**；说明中可写默认值、单位、枚举取值提示。  
+4. **按门控分组的富化字段**（推荐）：对每个会写回记录的门控，使用独立小节，例如  
+   `### 2.x 门控「<门控显示名称>」可能写入的字段`  
+   表格建议列：**字段名 | 类型 | 说明**；枚举/布尔/多分支须在说明或单独「属性」中写清。
+
+**检查点**：每个在 §5 出现且会修改记录的门控，在 §2 中有对应富化字段说明（或可显式写「无新增字段」）。  
+**检查点**：同一字段在全篇命名一致（中英混排时避免同一语义两个不同列名）。
+
+---
+
+### 2.3 `## 3. 数据池（Stash / Pool）`（必备）
+
+使用 **Markdown 表格**，建议列：
+
+| 显示名称 | 逻辑 ID | 角色 | 池中记录的业务含义 |
+|----------|---------|------|---------------------|
+
+**角色**建议取值：`入口池` / `中间池` / `异常池` / `终点池` 等，与拓扑一致。
+
+**检查点**：每个在拓扑与门控 YAML 中出现的池，表中有一行；**显示名称**与 YAML `input`/`output` 中的池名一致。  
+**检查点**：**逻辑 ID** 在同一文档内唯一（如 `stash_input`），且仅使用字母、数字、下划线（便于下游映射）。
+
+**模型引用（可选）**：若数据池关联 3D 模型，须在该池的描述中包含 `模型引用` 标题子节，写明模型名称与版本。无关联模型时省略。
+
+---
+
+### 2.4 `## 4. 池间流转（拓扑）`（必备）
+
+须同时包含：
+
+1. **图示**：`mermaid` 或 `graph` / `plain` 代码块，表达**有向边**；边上标注**门控显示名称**（与 §5 一致）。  
+2. **文字补充**：用列表说明每个门控的**入口池集合**、**出口分支语义**；合流门控须写明多入口来源。
+
+**检查点**：图中每条边在「文字补充」中可追溯到业务含义；无悬空池（除明确废弃外）；终点池可达。
+
+---
+
+### 2.5 `## 5. 门控（Valve）`（必备）
+
+#### 5.1 门控总述（建议独立小节）
+
+说明门控的**检查—路由**语义；并统一约定 YAML 字段含义，建议至少包含：
+
+| 键 | 含义 |
+|----|------|
+| `valve_id` | **可选**。若提供，须为文档内稳定、唯一的 ID（如 `valve_1`），便于脚本与配置引用；不提供时下游可用 `name` + `order` 等推导门控实例。 |
+| `name` | **必备**。与拓扑、§2 小节标题一致的门控显示名称。 |
+| `order` | **必备**。整数顺序，与依赖关系一致。 |
+| `input` | **必备**。`primary` 必填；合流时增加 `secondary`（及文档中说明是否可同时进单）。 |
+| `output` | **必备**。列表；每项含**目标池**与**路由条件**（自然语言须与 §2 字段名可对读）。 |
+
+若文档约定**列表查询 limit/offset** 等实现参数，须写在本节「查询约定」或各门控下，便于生成脚本照抄。
+
+#### 5.2 每个门控子节（必备结构）
+
+对每个门控，建议按下列顺序组织（可合并标题，但**信息不得缺**）：
+
+> **标题层级**：下列各项标题文字（如「触发方式」「模型引用」等）的 Markdown 层级（`##` / `###` / `####`）取决于门控在文档中的嵌套深度，以标题文字匹配为准，不要求固定 `#` 数量。
+
+1. **门控标题**：`### 5.x <门控显示名称>`（编号与 `order` 建议一致或递增）。  
+2. **YAML 代码块**：`yaml`，须含 `name`、`order`、`input`、`output`；**`valve_id` 可选**（若写则全文档唯一）。  
+   - 目标池键名可使用 `Stash:` 等非标准键，但须在总述或脚注说明与实现侧 **pool 显示名称** 的对应关系。  
+3. **触发方式**（推荐，缺省为人工触发）：`触发方式` 标题，取值 `自动触发` 或 `人工触发`。未指定时默认按**人工触发**处理。自动触发门控无人工处理阶段，脚本实现 `run`；人工触发门控脚本实现 `start` + `complete`。
+4. **化合物 / 外部数据查询方式**（若本门控需要）：说明查哪类库、用哪些入口字段作键、汇总规则等。  
+5. **字段映射表**（若存在库表/API 列与门控加工字段对应）：两列表头清晰（如「门控加工数据 | 库字段」）。  
+6. **数据处理规则表**（强烈推荐）：列至少包含 **`序号` | `规则摘要` | `条件要点` | `业务动作或结果`**；序号建议 **章内连续小数编号**（如 `1.1`、`1.2`，与门控章节号前缀一致），便于脚本注释逐条对应。  
+7. **操作员步骤**（若为人工门控）：编号列表，步骤可执行、可验收。
+8. **模型引用**（若本门控关联 3D 模型）：`模型引用` 标题，写明模型名称与版本。无关联模型时省略。
+
+**Process 批量提交（可选）**：若门控需触发 **Rhea / 设备侧批量提交任务**，须在流程文档中写明调用时机、**`items` 每条**中的 **`process`（流程模板名，即 process_name 语义）**、**`params` / `table_objects` 等如何从业务数据拼装**，以及 **`baseURL`（服务根地址）的语义来源**（配置、环境变量、订单字段等，由集成解析为字符串 URL）。**path、HTTP 方法** 由 SDK 固定，流程文档**不要求**写 path / method；生成脚本时映射为 SDK 中对应方法（见 [`references/agentic-lab-sdk.md`](agentic-lab-sdk.md)；Wire 细节见 [`references/rhea-api/execute_process_batch.md`](rhea-api/execute_process_batch.md) 供预检对照 `items[]` 形状）。
+
+**检查点**：每个 `output` 条件互斥或可判定优先级在文中有说明；缺料/失败等异常分支有定义。  
+**检查点**：`input.secondary` 存在时，§4 文字补充中已描述合流。
+
+---
+
+### 2.6 `## 6. 知识库 / 外部主数据`（按需）
+
+若规则依赖**库外主数据**（如化合物知识库），使用表格列出**逻辑键、含义、类型/枚举**即可；具体 API 与表名可由实现文档补充，但流程文档须写清**业务字段语义**与**与记录字段的对应关系**。
+
+无外部依赖时可写「本节不适用」或省略，但须在 §1 或概述中说明。
+
+---
+
+## 3. 数据与规则质量要求
+
+### 3.0 表格（通用）
+
+| 项 | 要求 |
+|----|------|
+| 枚举与布尔 | 「枚举」类型须在说明或属性列列出可选值；布尔字段说明 `true`/`false` 业务含义。 |
+| 单位与格式 | 质量、体积等字段注明单位（如 mg）；日期/批次格式若影响规则，在说明或「属性」中写明。 |
+| 规则可执行 | 「条件要点」应能映射到 §2 字段或外部查询结果；避免纯口语无字段锚点。 |
+| 编号稳定 | 规则序号在全篇不重复；门控内 `1.1` 与门控 `2` 的 `2.1` 可并存，但同一门控内不重复。 |
+
+### 3.1 门控逻辑须严谨、禁止模糊定义
+
+合规预检与人工评审须能**逐条判定**门控行为，下列情形视为**不通过（阻断）**或须改为可判定表述后再生成：
+
+- **不可判定的条件**：`output` 条件、数据处理规则中的「条件要点」依赖「视情况」「酌情」「必要时」「由业务决定」等**无唯一真值**的措辞，且文中**未**给出可操作定义或枚举。  
+- **无字段锚点**：条件仅停留在口语（如「资源够」）而未绑定 §2 字段、外部查询结果或 YAML 中可解析的键。  
+- **分支冲突**：同一门控多条 `output` 在相同数据状态下可同时为真，且文档**未**说明互斥、优先级或求值顺序。  
+- **不完备**：文档已描述业务异常（缺料、超时、失败）但**无**对应出口池或规则行，导致路由语义不完整。
+
+**建议写法**：每条规则写清「若 **字段 A** 与 **字段 B** 满足 **关系 R**，则 **动作** / **路由到池 P**」；比较类写明单位与边界（如 `≤`、严格小于、闭区间）。
+
+### 3.2 依赖项、API 能力、数据字段须可支持（须提前拦截）
+
+预检时须将流程文档中出现的**依赖与调用**，与 skill 内 **[`references/agentic-lab-sdk.md`](agentic-lab-sdk.md)**（及与 Rhea 等 **[`references/rhea-api/`](rhea-api/)** 中已列 Wire）**逐项对照**：
+
+| 类别 | 检查 | 不通过时的处理 |
+|------|------|----------------|
+| **外部依赖** | 设备、第三方 HTTP、未在 SDK 出现的内部服务等：须写清**对接边界**（谁调谁、成功/失败判据）；仅有名称无契约的，**阻断**并要求补「数据从哪来、失败怎么办」。 |
+| **SDK / `this.context` 能力** | 文档中「调用××」须对应 **agentic-lab-sdk 已列举**的方法名与语义；若出现**未在 SDK 文档出现**的方法、臆造 RPC、或超出已文档化能力的描述，须 **阻断**，在《流程文档合规问题与优化建议》中写明 **「不支持的 API：…」** 并给出 **可替换的已支持能力** 或要求**删改流程**。 |
+| **数据字段** | 规则、映射、YAML 条件中引用的字段须在 **§2** 或映射表中有定义，且**全篇拼写一致**；引用不存在字段或与 Schema 明显冲突的，**阻断**。 |
+
+### 3.3 Process / 任务提交 / 其它 SDK 调用的参数与格式
+
+凡流程文档出现 **Process 执行、批量任务提交、或任何明确绑定 SDK 的写操作/查询参数**，除满足 **§2.5 Process 批量提交** 小节外，还须满足（否则预检 **不通过**）：
+
+1. **方法名**：与 [agentic-lab-sdk.md](agentic-lab-sdk.md) 中条目一致，且用途与文档叙述一致。  
+2. **请求体与类型**：对 **Process 批量提交**，须能整理出 **`items[]`**（与 **[`rhea-api/execute_process_batch.md`](rhea-api/execute_process_batch.md)** 请求体中 `items` 一项同形）：每条至少含 **`process`**、**`params`**（键、类型、默认值或来源字段）；若流程需绑定业务表记录，则须说明 **`table_objects`**（表名、主键与 ticket 明细的对应）；并须说明 **`baseURL`** 如何得到；**禁止**仅写「组装 JSON」而无键级说明。  
+3. **查询类接口**：分页策略须与 [agentic-lab-sdk.md](agentic-lab-sdk.md) 中该方法的分页方式一致或显式写出分页参数；**`filter`** 须说明字段名与算子意图，避免无法落地的自然语言。  
+4. **Process 批量提交与 HTTP**：流程文档约束 **`items`**、**`baseURL` 语义**及任务参数；**不要求**写 path / HTTP 方法（由 SDK 封装）。
+
+**预检产出**：凡属 **§3.2 / §3.3** 的不通过项，须在《流程文档合规问题与优化建议》中单独列出 **「不支持或不可生成项」**，避免进入代码生成阶段才发现无法对接。
+
+---
+
+## 4. 合规检查清单（自检用）
+
+打印或复制下列清单，对目标流程文档逐项打勾：
+
+- [ ] **§1 流程元信息**表四要素齐全。  
+- [ ] **§2** 含入口字段表；每个会写数的门控有富化字段小节或显式无字段说明。  
+- [ ] **§3** 数据池表覆盖拓扑与 YAML 中全部池名；逻辑 ID 唯一。  
+- [ ] **§4** 含图 + 文字补充；合流与多出口均有叙述。  
+- [ ] **§5** 每个门控有 YAML；`name`、`order`、`input`、`output` 完整；`name` 与 §4 边标签一致；若提供 `valve_id` 则全文档无重复。  
+- [ ] 需查询库的门控含**查询方式**；需映射的含**字段映射表**。  
+- [ ] 含计算/判定的门控含**数据处理规则表**及稳定**序号**。  
+- [ ] 人工门控含**操作员步骤**（如适用）。  
+- [ ] **§6** 或显式声明无外部主数据依赖。  
+- [ ] 全文**池名、门控名、字段名**与 YAML、表格、图示无冲突。  
+- [ ] **§3.1**：门控规则与 `output` 条件可判定，无未定义模糊用语；分支互斥或优先级已说明。  
+- [ ] **§3.2**：所提依赖、**SDK/API**、字段均在 **agentic-lab-sdk**（及已列 rhea-api）与 §2 中有依据；**无不支持或未文档化的 API**。  
+- [ ] **§3.3**：凡 **Process / 任务提交 / SDK 调用**，**`items`** 与 **`baseURL` 语义**可对照 **agentic-lab-sdk + rhea-api** 校验；其它查询的分页与 **filter** 意图可落地；**不**要求流程写 path/HTTP 方法。
+- [ ] **触发方式**（推荐）：建议每个门控含 `触发方式` 标题（`自动触发` 或 `人工触发`）；未指定时默认为人工触发。自动触发门控无操作员步骤与人工处理章节。
+- [ ] **模型引用**：关联 3D 模型的数据池或门控含 `模型引用` 标题（模型名称、模型版本）；无关联模型时可省略。
+
+---
+
+## 5. 与流程注册包生成的关系
+
+使用 skill **`lab-flow-designer`** 时：**仅「初次从流程说明生成整包」**须先按主 `SKILL.md` 中 **「流程文档合规预检」** 对照本标准执行；不通过则不得写入产出目录，并须给出《流程文档合规问题与优化建议》（结构见该节）。**对已有流程注册包做增量修改**的会话不要求流程文档预检（可选自行对照本标准做人工评审）。
+
+生成器依赖（初次生成路径）：
+
+- §3 → `pools/*.md` 文件名与 Schema；  
+- §4 + §5 → 根 `SKILL.md` 流程图与**连接关系**列表；  
+- §5 → `valves/*.md`、`scripts/*.js` 及规则注释序号；  
+- §2、字段映射、查询方式 → 脚本内 `ticket.detail` 与按 [agentic-lab-sdk.md](agentic-lab-sdk.md) 调用对应方法；  
+- 流程中若需 **Process 批量提交** → 脚本内按 SDK 对应方法执行（参数以流程文档为准，见 `references/agentic-lab-sdk.md` 与 `references/rhea-api/execute_process_batch.md`）。
+
+主 `SKILL.md` 中 **门控脚本编写指引** 约定：生成 `scripts/*.js` 与 `pools/*.md` Schema 时，**仅实现或收录流程文档在本门控逻辑或池字段描述中明确写出的**查询、回写、路由与字段行，**禁止**为对齐 embedded 示例而附加未文档化的代码或字段。
+
+**流程文档越符合本标准，生成结果越稳定**；检查清单亦可作为 PR / 评审附件使用。
+
+---
+
+## 6. 修订与版本
+
+本标准随 `lab-flow-designer` skill 与常见流程说明实践演进可修订；建议在文末或 Git 记录中保留**修订日期与变更摘要**。