@stalfh233/omc-cli 0.4.102 → 0.5.1

package/skills/omc-capabilities.md

@@ -1,214 +1,214 @@
----
-name: omc-capabilities
-description: The OMC capability catalogue — what each capability can do, its tools, recipes, and boundaries. Use to answer "can OMC/platform do X?" and to find the tool for X before discovery.
----
-
-# Capability Catalogue (能力总表)
-
-The one place that says **what OMC can configure and what each capability
-covers**. Read it when you need to answer "能不能做 X？/ 用哪个能力？" yourself —
-before you escalate the question to the user, and before you decide "X 要二开".
-
-This topic is the **prose authority** for capability coverage; `omc capabilities`
-/ `omc next` / `omc capability <id>` are its machine-readable projection over the
-same 15 capabilities (a `verify` test fails if the two drift). A concrete wire
-shape is always reached by `omc describe <tool> --example <recipe>` — this
-catalogue only names the tool and the recipe, never re-specifies the payload.
-
-**How to read it (progressive disclosure):** scan the 能力索引 table, then read
-only the section for the capability you need —
-`omc help omc-capabilities --section "<能力>"`. Do not load every section.
-
-## 能力索引
-
-| 能力 | 一句话 | 能做哪些事（需求线索） | 读哪节 |
-| --- | --- | --- | --- |
-| 环境治理 `environment` | 环境发现/指纹/就绪 | 环境、指纹、版本、连接、登录、就绪、发现 | [环境治理](#环境治理-environment) |
-| 应用 `app` | 应用包生命周期 | 应用、门户、分组、app 建删移 | [应用](#应用-app) |
-| 应用目录（分组）`folder` | 应用树目录/分组 | 目录、分组、文件夹、应用树、移动模型到目录 | [应用目录](#应用目录分组-folder) |
-| 数据字典 `dictionary` | 字典与字典记录 | 字典、选项来源、树型、键值、字段下拉来源 | [数据字典](#数据字典-dictionary) |
-| 业务模型 `model` | 模型生命周期 | 模型、对象、表、主数据、改名、物理删除 | [业务模型](#业务模型-model) |
-| 字段 `field` | 字段族 + 子表 + **计算字段** | 字段、属性、子表、明细、下拉、单选、多选、附件、人员、部门、日期、数值、关联、**公式/计算/求和/汇总/合计/回主表** | [字段](#字段-field) |
-| 默认表单 `form` | 表单布局与发布 | 表单、页面、布局、控件、只读、显示 | [默认表单](#默认表单-form) |
-| 列表视图 `listview` | 列表表头与列 | 列表、视图、查询列、筛选、表头、甘特 | [列表视图](#列表视图-listview) |
-| 字段级规则 `datarule` | 字段级控件规则 | 字段级规则、控件规则、校验规则、计算拼接、显示规则、条件必填/只读/显示 | [字段级规则](#字段级规则-datarule) |
-| 业务规则 `businessrule` | 图形规则图 + **定时任务** | 业务规则、触发器、规则图、事件、BRANCH、BIZ_ACTION、**定时任务/定时/每天/周期/调度** | [业务规则](#业务规则-businessrule) |
-| 规则生命周期 `rule-lifecycle` | 规则启停删 | 启用规则、停用规则、删除规则、规则启停 | [规则生命周期](#规则生命周期-rule-lifecycle) |
-| 流程模板 `workflow` | 审批流程模板 | 流程、工作流、审批、节点、待办、流转、参与人、审批人、表单操作按钮 | [流程模板](#流程模板-workflow) |
-| 表单在线 JS `onlinejs` | 表单脚本发布/回读 | 在线js、脚本、联动、onload、onvalidate | [表单在线 JS](#表单在线-js-onlinejs) |
-| 业务集成 `bizservice` | 集成服务与方法 | 集成、接口、服务、回调、对接、外部系统、datasql、restful | [业务集成](#业务集成-bizservice) |
-| 报表 `report` | 报表页 + BI 图表（**仅显式要求时**） | 报表、图表、看板、bi、dashboard（用户点名的才做） | [报表](#报表-report) |
-| 运行数据 `data` | 业务记录读写 | 运行数据、提交数据、保存记录、查记录 | [运行数据](#运行数据-data) |
-
-**边界**（不在覆盖内）见 [边界](#边界boundaries)。**落点判据**（配置 vs 二开）
-的唯一权威源是 `cpdocs-guide` 的「落点」。
-
----
-
-## 环境治理 `environment`
-
-- **能做哪些事**：读环境指纹与版本桶（决定证据版本）；就绪自检（登录/许可证/最小路径），写入开关与生产授权在 `omc setup`。
-- **工具**：`discover_environment`、`environment.fingerprint`
-- **边界 / 陷阱**：只读；不进 intent（用 `omc setup` / `discover_environment`）。写前一律先确认环境真相。
-
-## 应用 `app`
-
-- **能做哪些事**：列出应用包、创建、改名/分组移动、删除（删除级联其模型）；**应用树目录（分组）的建/改名/挂载/删**，以及把模型放进目录。
-- **工具**：`app.list`、`app.create`、`app.update`、`app.delete`、`folder.tree`、`folder.create`、`folder.update`、`folder.delete`
-- **边界 / 陷阱**：**目录（分组）是应用树节点**：`folder.create` 省略 `parentId` 建的是顶层目录（平台默认挂应用根）、平台**不校验重名**（工具默认按同父同名拒绝）、`folder.delete` **非递归**（有子节点回 `DIRECTORY_NOT_EMPTY`）、树是嵌套 `children`（`folder.tree` 已递归展平给 `path/depth`，只看顶层会误判“没建成”）。模型进目录用 `model.move`。环境已带默认 `applicationCode`，建模**不必**先建应用；`app` 未进 intent 声明式面。**要把 intent 落到新应用**：`omc call app.create`（原子面）→ 把该环境的 `applicationCode` 指向新应用（`omc setup` 重配或改 `~/.config/omc/` 环境配置）→ 再 `intent plan/apply`，模型即落在新应用（用户实测摩擦：曾误以为应用能进 intent）。
-
-## 应用目录（分组）`folder`
-
-- **能做哪些事**：读应用树（目录 + 模型，递归展平带 `path/depth`）、建目录、改名/挂载、删除空目录；配合 `model.move` 把模型放进目录。
-- **工具**：`folder.tree`、`folder.create`、`folder.update`、`folder.delete`、`model.move`；自定义页面（同一棵应用树）：`custompage.list`、`custompage.get`、`custompage.create`、`custompage.update`、`custompage.content.get`、`custompage.content.update`、`custompage.content.publish`、`custompage.delete`
-- **边界 / 陷阱**：`folder.create` 省略 `parentId` 建的是**顶层目录**（平台默认挂应用根）；平台**不校验重名**（工具默认同父同名拒绝，并列同名传 `allowDuplicate:true`）；`folder.delete` **非递归**（有子节点即拒 `folder-not-empty`）；应用树是**嵌套** `children`，`folder.tree` 已展平并给 `path/depth`——只看顶层会误判"目录没建成"。模型进目录用 `model.move {schemaCode, folderId}`，`folderId` 必须是目录 **id**（给名字回 `folder-not-found` / 跨应用回 `folder-other-application`）。**自定义页面是两行**：应用树节点（AppFunction type=Page，`custompage.create` 需要 `parentId`；`menuPointType` 平台必填，省略会 NPE→50000，工具默认 `CUSTOM_PAGE`）+ 页面正文（`draftContent`/`publishedContent`）。**必须先建节点再写正文**：`/page/content/*` 先按 code 查 AppFunction，缺节点回 `BIZ_SCHEMA_NOT_EXIST`。门户读的是 `publishedContent`——`content.update` 只写草稿，上线要 `content.publish`（或 update 传 `publish:true`）。页面 JS 若要复用平台对象，按在线 JS 的宿主对象约定写，别假设 `window.axios`。
-
-## 数据字典 `dictionary`
-
-- **能做哪些事**：字典与字典记录全生命周期（键值型/树型、启停）；作为选择字段的选项来源；字典分类。
-- **工具**：`dictionary.list`、`dictionary.type`、`dictionary.names`、`dictionary.get`、`dictionary.records`、`dictionary.save`、`dictionary.status`、`dictionary.usage`、`dictionary.parent`、`dictionary.classes`、`dictionary.class.save`、`dictionary.class.delete`
-- **recipe**：`omc describe dictionary.save --example dictionary-key-value`
-- **边界 / 陷阱**：选择字段有三种选项来源——`custom` / `dictionary` / `businessModel`；关联单选/多选支持 `searchFormula` 与 `conditions` JSON 筛选。
-
-## 业务模型 `model`
-
-- **能做哪些事**：模型创建、改名、**移动到目录/分组**、物理删除（`absent:true` 回读）、存在性、批量删除、摘要；一次建模型+字段+表单用 `configure_model`。**应用目录（分组）本身**：`folder.tree` / `folder.create` / `folder.update` / `folder.delete`。
-- **工具**：`model.list`、`model.inspect`、`model.create`、`model.delete`、`model.deleteMany`、`model.setSummary`、`model.update`、`model.move`、`configure_model`、`folder.tree`、`folder.create`、`folder.update`、`folder.delete`
-- **recipe**：`omc describe configure_model --example model-with-fields-form`
-- **边界 / 陷阱**：`model.inspect <schemaCode>` 一次拿全字段/表单/列表/规则/流程摘要，别逐面 6 次调用。**目录（分组）**：`folder.create` 省略 `parentId` 建的是**顶层目录**（平台默认挂应用根）；`folder.delete` **非递归**（有子节点即拒 `folder-not-empty`）；应用树是**嵌套**的，`folder.tree` 已递归展平并给 `path/depth`（只看顶层会误判“目录没建成”）。移动模型用 `model.move {schemaCode, folderId}`，`folderId` 必须是目录 **id**（给目录名会 `folder-not-found`）。**保留 code**：字段 code 用 `name` 会被平台占用，须避开。**每个模型都必须建并发布默认表单**——只建模型不建/不发布表单则无法录入查看（`configure_form` 或 `form.draft(rebuild:true)` + `form.publish`）。**「汇总/统计/按月」类需求**：常见做法是**一张汇总表**（独立业务模型，如 `x_monthly_summary`）接住结果，用定时任务/规则把源数据汇总写进去——**但这按需求定**，不是写死的规则。需求确认时把"汇总表"作为常规选项提出来跟用户确认，别默认往报表或二开上引。
-
-## 字段 `field`
-
-- **单据号/自动编号（原生，勿二开）**：单据号是表单 **Serial Number 控件**（字段类型 100 SequenceNo）的 `options.seqNoSetting` 分段构建器（CONSTANT/DATE/SEQNO/DATAITEM/UID 段），SEQNO 段 `resetDate:DAY/MONTH/YEAR` 原生按期重置——`describe field.update --example field-serial-number`。**不要落 SequenceService SPI 二开**（r5-crm 实证重造轮子）；编号生成时机=submit（`data.save` 不生成）。
-
-- **能做哪些事**：字段族全链 create→publish→表单绑定；**CHILD_TABLE 子表**（子列是 schemaCode=父字段 code 上的普通字段）；**计算字段**（默认用普通字段 + 「计算规则」，见下）。
-- **工具**：`field.list`、`field.create`、`field.update`、`field.publish`、`field.delete`
-- **recipe**：
-  - `omc describe field.create --example numeric-two-decimals`（数值 + scale）
-  - `omc describe field.create --example dictionary-backed-single-select`
-  - `omc describe field.create --example minimal-child-table`（子表 + 标量子列）
-  - `omc describe field.create --example business-model-dropdown`
-- **边界 / 陷阱**：
-  - **计算类需求默认走「普通字段 + 计算规则」，不要建「计算公式」字段类型（FORMULA）**：建一个**数值/单行文本**业务字段，再配一条**字段级计算规则**（`datarule.create` `dataRuleType:2`，`options.shortTextStitch={"formula","editorText","editorMark"}`）。理由：平台约定用正常业务字段承载、顺带配计算规则（真机 2026-10-08 production 表单核验 + 设计器弹窗显示）。「计算公式」字段类型不是默认，仅当确需一列专用公式时才用。
-  - **计算规则公式引用**：同类字段裸 `{字段code}`（`{a}+{b}`）；**子表列用 `{子表字段code.子列code}`**（`{Sub_item_information_table.taxInclusiveAmount}`）；子表求和 `SUM({子表.子列})`；支持 `IF(cond,a,b)`、`CASE(v,c1,r1,c2,r2)`、`VALUE()`、`AND`、比较 `=`、字符串字面量与运算符空格。recipe：`omc describe datarule.create --example field-compute-rule|field-compute-subtable-sum|field-compute-child-column`。
-  - 计算规则（`dataRuleType:2`）**在 REST 路径上不会执行也不会回填**（r17 2026-10-25 复核：`data.submit`/`data.update` 后目标字段仍为传入值）。
-  - **跨模型汇总可以用 FORMULA(100) + AGGREGATION，REST 能回算**（r17 真机 100→105）：`omc describe field.create --example formula-aggregation-cross-model`；`queryConditions` 必须给 DYNAMIC 条件（propertyCode=来源字段、currentPropertyCode=目标字段），空条件静默得 0。
-  - **同模型（含自己的子表）聚合不可用**：`field.publish` 必抛 305003（`aggregation-self-schema-cycle`，平台 `checkCycleOfAggregation:1032` 逻辑成环）。
-  - 只有 `FORMULA`（计算公式，`propertyType:100`）字段是**门户前端**计算、API 不回填（旧证据 2026-09-25/10-07，仅覆盖该字段类型）。
-  - 子表列支持标量族 + WORK_SHEET 关联列（需 `relativeCode`+options）；**子表套子表平台本身不存在**（一级子表就是上限），`MULT_WORK_SHEET` / `RELEVANCE_DATA` 不覆盖。
-
-## 默认表单 `form`
-
-- **能做哪些事**：表单 draft-first 布局、发布、`publishedHtmlJson` 绑定读回；把已发布字段绑进默认表单；**表单工具栏按钮**（`options.customButtonJson` → publish 生成 FORM 按钮）与按钮执行。
-- **工具**：`form.get`、`form.draft`、`form.publish`、`configure_form`、`form.runButton`
-- **按钮脚本（JS）读写**：`form.get --buttonScripts` 回 `scriptData`/sha；写用 `form.publish --buttonScripts [{code,script}]`（只改已有按钮脚本），或在 `buttons[]` 里给 `script`。**视图（列表）本身没有 JS 面**（`h_biz_query` 无脚本列）；脚本只有三处：表单在线JS、按钮JS、自定义页面 JS。
-- **recipe**：`omc describe configure_form --example publish-default-form`
-- **边界 / 陷阱**：默认表单已存在，用 `configure_form`/`form.draft(rebuild)`/`form.publish(rebuild:true)` 改它，不要新建；改字段形状后刷新表单一调用 `form.publish rebuild:true`。
-  - **每个模型交付前其默认表单必须已发布**：只建草稿=用户无法录入/查看。用 `configure_form` 或 `form.draft(rebuild:true)`+`form.publish` 发布。
-  - **发布态以 `form.get` 的 `published`/`existDraft` 布尔为准**，不要看 `publishedControlCodes` 是否非空（草稿字段也非空，会误判）。交付前列出每个模型的 `form.get.published` 核对。
-  - **写业务数据的前提是先发布模型+表单**：正确顺序 = 建模型 → 发布字段（`field.publish`）→ 建并**发布**默认表单（`form.publish`）→ 才 `data.save`/`data.submit`。不要在建/未发布状态下写业务数据。
-  - **表单按钮**：`form.publish {buttons:[…]}` 写 `options.customButtonJson` 并生成 `h_biz_button(triggerType=FORM)`；表单页显示还取决于流程节点 `buttonPermission.customBtns[].enabled`（设计器「表单操作」勾选）。执行用 `form.runButton`（带整条记录，区别于列表按钮的 `rule.run`）。
-
-## 列表视图 `listview`
-
-- **能做哪些事**：视图表头列、排序、筛选条件生命周期（create/configure/delete）。
-- **工具**：`listview.get`、`listview.list`、`listview.create`、`listview.configure`、`listview.delete`
-- **按钮脚本（JS）读写**：`listview.get --buttonCode <code>`（或 `--buttons`）直接回 `scriptData`/`scriptBytes`/`scriptSha256`，不用翻 artifact；写用 `listview.configure --buttonScripts [{code,script}]` 只改脚本（保留其它字段），或在 `buttons[]` 里用 `script` 简写（= `actionConfig.scriptData`）。
-- **recipe**：`omc describe listview.configure --example configure-default-list`
-- **边界 / 陷阱**：默认视图已存在，`listview.configure` 省略 code 即配置默认视图。**按字段分组（queryLayer）未取证**——别猜写。
-
-## 字段级规则 `datarule`
-
-- **能做哪些事**：字段级数据规则（bizdatarule）create/update/delete；条件必填（type4）、条件只读（type5）、条件显示（type3）、计算拼接（type2）等，按平台校验器闭环。
-- **工具**：`datarule.list`、`datarule.create`、`datarule.update`、`datarule.delete`
-- **recipe**：
-  - `omc describe datarule.create --example datarule-conditional-required`
-  - `omc describe datarule.create --example datarule-conditional-readonly`
-  - `omc describe datarule.create --example datarule-conditional-display`
-- **边界 / 陷阱**：目标字段必须已发布；同一字段多条规则时 update/delete 必须带 `dataRuleType` 去歧义。
-
-## 业务规则 `businessrule`
-
-- **能做哪些事**：图形规则图（nodeGraph）——数据事件（Create/Update/Delete）触发、按钮/流程触发、动作节点（UPDATE/CREATE/DELETE/QUERY/ASSIGN/MESSAGE/BIZ_ACTION/GET_LIST…）、BRANCH 条件分支、**定时任务 TIMING_TASK**（每天/周期，SCHEDULER 节点）。
-- **工具**：`rule.list`、`rule.get`、`rule.references`（跨规则引用检索：谁引用了服务/模型/字段）、`rule.save`、`rule.node.update`
-- **recipe**：
-  - `omc describe rule.save --example standard-business-rule-graph`
-  - `omc describe rule.save --example business-rule-branch-conditional`
-  - `omc describe rule.save --example rule-timing-task`（**每天/周期定时执行**）
-- **边界 / 陷阱**：
-  - **「每天定时执行」= 定时任务 TIMING_TASK，是平台原生配置，不是外部定时器、不是在线 JS、无需二开**；`nodeGraph.bizRuleType:2` + SCHEDULER 节点 + `nodeGraph.schedulerSetting`。
-  - 数据事件只分发到平台预置 code 行（Create/Update/Delete）；自定义 ruleCode 需按钮/流程/定时/显式触发。
-  - 保存 ≠ 可见，需 `rule.enable`（见 rule-lifecycle；绑流程事件前必须 enable，否则运行时 Business rule does not exist——r3-wms 实测）。BRANCH 多出口是「全部命中即走」，分级互斥用嵌套 BRANCH。
-  - **无存在性/计数判定原语**：BRANCH 不能按「QUERY 是否返回行」分支（PRE_OUT 分支不接收 QUERY 空结果，r3-wms 实测）。因此**硬拦保存做不到**（重复校验只能降级为打标，且**规则图内 QUERY→UPDATE 打标会静默空转**（8.6.26 UPDATE 的 inputParam 只认触发行 `_input`，`_QN_output` 引用被忽略——r4-fin 双跑实证 2026-10-09）。唯一可靠路径=改写预置 Create 规则挂 BIZ_ACTION 自调二开 markDuplicates（见 `describe rule.save --example data-duplicate-flag`））。
-
-## 规则生命周期 `rule-lifecycle`
-
-- **能做哪些事**：业务规则的启用、停用、批量停用、删除、手动执行（按钮规则验收）。
-- **工具**：`rule.enable`、`rule.disable`、`rule.delete`、`rule.disableMany`、`rule.run`、`configure_rule`
-- **边界 / 陷阱**：`enabled` 是运行时真相，`status` 可能滞后。`rule.disableMany` 默认含预置行，`customOnly:true` 只停自定义。`rule.run` 只跑自定义 code 且须 enabled（预置行被拒）；返回 data 是执行前快照，副作用用 `data.load` 另读；被更新行须 COMPLETED（引擎不查 DRAFT）。
-
-## 流程模板 `workflow`
-
-- **能做哪些事**：流程模板 get_draft/get_published、create、update、publish、bindRule（事件处理器规则绑定）、delete、workitem.list、workflow.instanceActivity（实例节点状态诊断）；参与人用组织对象。
-- **工具**：`workflow.get_draft`、`workflow.setButtons`（节点「表单操作」按钮勾选）、`workflow.get_published`、`workflow.validate`、`workflow.create`、`workflow.update`、`workflow.publish`、`workflow.bindRule`、`workflow.delete`、`workflow.permissions`、`workflow.addPermission`、`workflow.removePermission`（发起权限：发布流程不会自动建这一行，缺它一律 40009）、`configure_workflow`、`workitem.list`、`workflow.instanceActivity`、`org.role.list`、`org.department.list`、`org.user.search`、`org.role.users`、`org.role.userScope`、`org.roleGroup.create`、`org.role.create`、`org.role.update`、`org.role.addUsers`、`org.role.removeUsers`、`org.role.setUserScope`、`org.department.create`、`org.department.update`、`org.department.delete`、`org.department.users`、`org.user.create`、`org.user.update`、`org.user.delete`、`org.user.info`、`org.user.departments`、`org.role.delete`、`org.roleGroup.delete`、`org.user.transferDepartment`
-- **recipe**：`omc describe workflow.bindRule --example workflow-handler-binding`
-- **边界 / 陷阱**：greenfield 首版；`publish`/`bindRule` 不得在 `ValidateMessage[]` 拒绝时报告成功。运行时 workitem（提交/审批）走 `data.submit`；想知道实例停在哪/是否错派，用 `workflow.instanceActivity`（无 status=1=真停，参与人全是发起人=解析为空退回）。
-
-## 表单在线 JS `onlinejs`
-
-- **能做哪些事**：表单在线 JS 的 compose 六元素骨架、`draftHtmlJson.customScript`、发布与 SHA-256 回读；**读现存脚本**（`onlinejs.get` 抽 customScript innerHTML 原文+SHA-256，不必拉 form.get --full 六份 JSON）（脚本**编写**不在 CLI 范围，遵循项目在线 JS 规范或向用户索取定稿 source）。
-- **工具**：`onlinejs.get`、`onlinejs.compose`
-- **边界 / 陷阱**：仅表单在线 JS；后端在线开发（`/api/api/programming` Java 源码）用二开扩展包，不在 CLI 范围。INCREMENTAL 合并对同内容重发幂等；同头注释的整文件修订会被拒（`onlinejs-revision-replace-required`），走 `onlinejs.get` 取回 → 改 → `replace:true`。
-
-## 业务集成 `bizservice`
-
-- **能做哪些事**：业务服务与方法注册（RESTFUL/DATA_SQL/DATA_TABLE/SAP/KAFKA/SOAP）、服务清单（按分类/关键词，凭据不回显）、方法增改删、分类/连接池、导入导出、设计器测试。
-- **工具**：`service.list`、`service.get`、`method.get`、`method.update`、`method.create`、`method.delete`、`service.category.list`、`service.category.create`、`service.category.update`、`service.category.delete`、`service.dbconnpool.list`、`service.dbconnpool.create`、`service.dbconnpool.update`、`service.dbconnpool.delete`、`service.adapter_config`、`service.table_list`、`service.table_sql`、`service.register`、`service.update`、`service.delete`、`service.export`、`service.check`、`service.import`、`method.test`
-- **recipe**：`omc describe service.register --example restful-query-service`
-- **边界 / 陷阱**：方法 `configJson` 走 AES-128-ECB；**二开接口 = 扩展模块写 REST 接口 + RESTFUL 服务指向它**（页面/规则引用）；RESTFUL/DATA_SQL 绑定前须带适配器必需配置（否则是注册壳）。
-
-## 报表 `report`
-
-- **能做哪些事**：报表树/元数据读取、报表页建改删、BI dashboard 配置、图表增改删、图表数据查询、数据集读取/关联。
-- **工具**：`report.tree`、`report.get`、`report.chartdata`、`report.datasource.list`、`report.datasource.link`、`report.create`、`report.update`、`report.delete`、`report.configure`
-- **边界 / 陷阱**：
-  - **`report` 是"按需出现"的能力：只有用户显式要求报表 / 图表 / 看板 / dashboard 时才使用。常规开发流程不产出报表——不要在方案/存疑清单里对"统计/汇总/按月"之类的需求主动引入 `report`。**
-  - **跨对象统计聚合（如"按月按客户统计金额"）默认不落 `report`**：先看能否用字段/查询配置表达；表达不了就落二开聚合接口（扩展写接口 + RESTFUL），**不要默认引 BI/报表**。报表是另一条独立交付物，需用户点名。
-  - 报表页走 `/api/api/report/*`；BI 走 `/dashboard/v1/*`（无 errcode 信封，body 必带 `config:{token,reportCode,appCode}`，缺则静默 no-op）；外层 `corpId` 是真实查询键，默认 `"a"`。
-
-## 运行数据 `data`
-
-- **能做哪些事**：业务记录列出、加载、保存、更新、删除、提交（工作流）。
-- **工具**：`data.list`、`data.load`、`data.save`、`data.update`、`data.delete`、`data.submit`
-- **recipe**：
-  - `omc describe data.save --example workflow-backed-data-save`
-  - `omc describe data.submit --example workflow-backed-data-submit`（有流程）
-  - **正式数据一律 data.submit**（业务约定；save 的新建永远是 DRAFT 草稿）：
-    - 无流程模型一调：`data.submit {schemaCode, formData}`（无 id=新建并提交，COMPLETED，触发 Create 规则）——示例 `omc describe data.submit --example plain-data-submit`
-    - 已存草稿直提：`data.submit {schemaCode, bizObjectId, formData}`
-    - 流程模型两段式：`data.save {workflowCode}`（返回 workItemId）→ `data.submit {bizObjectId, workflowInstanceId, workItemId}`（workflow-backed-data-submit）
-    - `data.save` 定位=草稿/暂存；其 `submit:true` 便捷参数仍在（无流程模型等同直提），但按约定优先直接 data.submit
-- **边界 / 陷阱**：读实际业务记录是 OMC 独有能力。**计算字段（FORMULA/子表计算）不由 API 回填**——写测试数据带预算值，公式正确性人工前台确认；带子表计算字段的模型 API 写可能 50000（服务端重算 NPE），前台正常。
-
----
-
-## 边界（boundaries）
-
-这些面**不在配置覆盖内**。被挡/不支持是**明确的答复**，不是要绕过的障碍——如实报告，不要用相近能力伪造。
-
-| 面 | 状态 | 说明 |
-| --- | --- | --- |
-| 权限 / 授权矩阵 | blocked | 授权矩阵不在配置面 |
-| 嵌套子表（子表套子表） | 平台不存在 | 平台本身就是一级子表：主表可多子表，子表不能再套子表；不是 CLI 缺口，不要按此设计 |
-| OCR / 电子签章 / 发票识别 | unsupported | 不在平台配置覆盖内 |
-| 应用发布 / 环境上线 / 生产发布 | unsupported | CLI 只做配置，不做环境发布 |
-| 在线后端编码 / EXECUTE_CODE / ONLINE_DEVELOP | unsupported | 用二开扩展包，不用在线 JS 伪造 |
-
-> `blocked` / `unsupported` 是**原生配置**的判定，通常把行为路由到另一个代码所有者（`配置 + 后端扩展`），**不等于**需求不可交付。把 blocked face 编译成「做不了、留人工」是失败模式。
-
-## 相关 topic
-
-- 需求分析（定面/归类/选路）：`omc-requirement-analysis`；线索词表：`omc-requirement-vocabulary`
-- 用哪个工具最省：`omc-tool-selection`；写前人审门：`omc-config-draft-review`
-- 被拒/状态异常：`omc-refusals`；新面取证：`omc-capability-scouting`
-- 每能力的配置怎么配：`omc-business-configuration` 的对应节；写入风险：`omc-write-hazards`
+---
+name: omc-capabilities
+description: The OMC capability catalogue — what each capability can do, its tools, recipes, and boundaries. Use to answer "can OMC/platform do X?" and to find the tool for X before discovery.
+---
+
+# Capability Catalogue (能力总表)
+
+The one place that says **what OMC can configure and what each capability
+covers**. Read it when you need to answer "能不能做 X？/ 用哪个能力？" yourself —
+before you escalate the question to the user, and before you decide "X 要二开".
+
+This topic is the **prose authority** for capability coverage; `omc capabilities`
+/ `omc next` / `omc capability <id>` are its machine-readable projection over the
+same 15 capabilities (a `verify` test fails if the two drift). A concrete wire
+shape is always reached by `omc describe <tool> --example <recipe>` — this
+catalogue only names the tool and the recipe, never re-specifies the payload.
+
+**How to read it (progressive disclosure):** scan the 能力索引 table, then read
+only the section for the capability you need —
+`omc help omc-capabilities --section "<能力>"`. Do not load every section.
+
+## 能力索引
+
+| 能力 | 一句话 | 能做哪些事（需求线索） | 读哪节 |
+| --- | --- | --- | --- |
+| 环境治理 `environment` | 环境发现/指纹/就绪 | 环境、指纹、版本、连接、登录、就绪、发现 | [环境治理](#环境治理-environment) |
+| 应用 `app` | 应用包生命周期 | 应用、门户、分组、app 建删移 | [应用](#应用-app) |
+| 应用目录（分组）`folder` | 应用树目录/分组 | 目录、分组、文件夹、应用树、移动模型到目录 | [应用目录](#应用目录分组-folder) |
+| 数据字典 `dictionary` | 字典与字典记录 | 字典、选项来源、树型、键值、字段下拉来源 | [数据字典](#数据字典-dictionary) |
+| 业务模型 `model` | 模型生命周期 | 模型、对象、表、主数据、改名、物理删除 | [业务模型](#业务模型-model) |
+| 字段 `field` | 字段族 + 子表 + **计算字段** | 字段、属性、子表、明细、下拉、单选、多选、附件、人员、部门、日期、数值、关联、**公式/计算/求和/汇总/合计/回主表** | [字段](#字段-field) |
+| 默认表单 `form` | 表单布局与发布 | 表单、页面、布局、控件、只读、显示 | [默认表单](#默认表单-form) |
+| 列表视图 `listview` | 列表表头与列 | 列表、视图、查询列、筛选、表头、甘特 | [列表视图](#列表视图-listview) |
+| 字段级规则 `datarule` | 字段级控件规则 | 字段级规则、控件规则、校验规则、计算拼接、显示规则、条件必填/只读/显示 | [字段级规则](#字段级规则-datarule) |
+| 业务规则 `businessrule` | 图形规则图 + **定时任务** | 业务规则、触发器、规则图、事件、BRANCH、BIZ_ACTION、**定时任务/定时/每天/周期/调度** | [业务规则](#业务规则-businessrule) |
+| 规则生命周期 `rule-lifecycle` | 规则启停删 | 启用规则、停用规则、删除规则、规则启停 | [规则生命周期](#规则生命周期-rule-lifecycle) |
+| 流程模板 `workflow` | 审批流程模板 | 流程、工作流、审批、节点、待办、流转、参与人、审批人、表单操作按钮 | [流程模板](#流程模板-workflow) |
+| 表单在线 JS `onlinejs` | 表单脚本发布/回读 | 在线js、脚本、联动、onload、onvalidate | [表单在线 JS](#表单在线-js-onlinejs) |
+| 业务集成 `bizservice` | 集成服务与方法 | 集成、接口、服务、回调、对接、外部系统、datasql、restful | [业务集成](#业务集成-bizservice) |
+| 报表 `report` | 报表页 + BI 图表（**仅显式要求时**） | 报表、图表、看板、bi、dashboard（用户点名的才做） | [报表](#报表-report) |
+| 运行数据 `data` | 业务记录读写 | 运行数据、提交数据、保存记录、查记录 | [运行数据](#运行数据-data) |
+
+**边界**（不在覆盖内）见 [边界](#边界boundaries)。**落点判据**（配置 vs 二开）
+的唯一权威源是 `cpdocs-guide` 的「落点」。
+
+---
+
+## 环境治理 `environment`
+
+- **能做哪些事**：读环境指纹与版本桶（决定证据版本）；就绪自检（登录/许可证/最小路径），写入开关与生产授权在 `omc setup`。
+- **工具**：`discover_environment`、`environment.fingerprint`
+- **边界 / 陷阱**：只读；不进 intent（用 `omc setup` / `discover_environment`）。写前一律先确认环境真相。
+
+## 应用 `app`
+
+- **能做哪些事**：列出应用包、创建、改名/分组移动、删除（删除级联其模型）；**应用树目录（分组）的建/改名/挂载/删**，以及把模型放进目录。
+- **工具**：`app.list`、`app.create`、`app.update`、`app.delete`、`folder.tree`、`folder.create`、`folder.update`、`folder.delete`
+- **边界 / 陷阱**：**目录（分组）是应用树节点**：`folder.create` 省略 `parentId` 建的是顶层目录（平台默认挂应用根）、平台**不校验重名**（工具默认按同父同名拒绝）、`folder.delete` **非递归**（有子节点回 `DIRECTORY_NOT_EMPTY`）、树是嵌套 `children`（`folder.tree` 已递归展平给 `path/depth`，只看顶层会误判“没建成”）。模型进目录用 `model.move`。环境已带默认 `applicationCode`，建模**不必**先建应用；`app` 未进 intent 声明式面。**要把 intent 落到新应用**：`omc call app.create`（原子面）→ 把该环境的 `applicationCode` 指向新应用（`omc setup` 重配或改 `~/.config/omc/` 环境配置）→ 再 `intent plan/apply`，模型即落在新应用（用户实测摩擦：曾误以为应用能进 intent）。
+
+## 应用目录（分组）`folder`
+
+- **能做哪些事**：读应用树（目录 + 模型，递归展平带 `path/depth`）、建目录、改名/挂载、删除空目录；配合 `model.move` 把模型放进目录。
+- **工具**：`folder.tree`、`folder.create`、`folder.update`、`folder.delete`、`model.move`；自定义页面（同一棵应用树）：`custompage.list`、`custompage.get`、`custompage.create`、`custompage.update`、`custompage.content.get`、`custompage.content.update`、`custompage.content.publish`、`custompage.delete`
+- **边界 / 陷阱**：`folder.create` 省略 `parentId` 建的是**顶层目录**（平台默认挂应用根）；平台**不校验重名**（工具默认同父同名拒绝，并列同名传 `allowDuplicate:true`）；`folder.delete` **非递归**（有子节点即拒 `folder-not-empty`）；应用树是**嵌套** `children`，`folder.tree` 已展平并给 `path/depth`——只看顶层会误判"目录没建成"。模型进目录用 `model.move {schemaCode, folderId}`，`folderId` 必须是目录 **id**（给名字回 `folder-not-found` / 跨应用回 `folder-other-application`）。**自定义页面是两行**：应用树节点（AppFunction type=Page，`custompage.create` 需要 `parentId`；`menuPointType` 平台必填，省略会 NPE→50000，工具默认 `CUSTOM_PAGE`）+ 页面正文（`draftContent`/`publishedContent`）。**必须先建节点再写正文**：`/page/content/*` 先按 code 查 AppFunction，缺节点回 `BIZ_SCHEMA_NOT_EXIST`。门户读的是 `publishedContent`——`content.update` 只写草稿，上线要 `content.publish`（或 update 传 `publish:true`）。页面 JS 若要复用平台对象，按在线 JS 的宿主对象约定写，别假设 `window.axios`。
+
+## 数据字典 `dictionary`
+
+- **能做哪些事**：字典与字典记录全生命周期（键值型/树型、启停）；作为选择字段的选项来源；字典分类。
+- **工具**：`dictionary.list`、`dictionary.type`、`dictionary.names`、`dictionary.get`、`dictionary.records`、`dictionary.save`、`dictionary.status`、`dictionary.usage`、`dictionary.parent`、`dictionary.classes`、`dictionary.class.save`、`dictionary.class.delete`
+- **recipe**：`omc describe dictionary.save --example dictionary-key-value`
+- **边界 / 陷阱**：选择字段有三种选项来源——`custom` / `dictionary` / `businessModel`；关联单选/多选支持 `searchFormula` 与 `conditions` JSON 筛选。
+
+## 业务模型 `model`
+
+- **能做哪些事**：模型创建、改名、**移动到目录/分组**、物理删除（`absent:true` 回读）、存在性、批量删除、摘要；一次建模型+字段+表单用 `configure_model`。**应用目录（分组）本身**：`folder.tree` / `folder.create` / `folder.update` / `folder.delete`。
+- **工具**：`model.list`、`model.inspect`、`model.create`、`model.delete`、`model.deleteMany`、`model.setSummary`、`model.update`、`model.move`、`configure_model`、`folder.tree`、`folder.create`、`folder.update`、`folder.delete`
+- **recipe**：`omc describe configure_model --example model-with-fields-form`
+- **边界 / 陷阱**：`model.inspect <schemaCode>` 一次拿全字段/表单/列表/规则/流程摘要，别逐面 6 次调用。**目录（分组）**：`folder.create` 省略 `parentId` 建的是**顶层目录**（平台默认挂应用根）；`folder.delete` **非递归**（有子节点即拒 `folder-not-empty`）；应用树是**嵌套**的，`folder.tree` 已递归展平并给 `path/depth`（只看顶层会误判“目录没建成”）。移动模型用 `model.move {schemaCode, folderId}`，`folderId` 必须是目录 **id**（给目录名会 `folder-not-found`）。**保留 code**：字段 code 用 `name` 会被平台占用，须避开。**每个模型都必须建并发布默认表单**——只建模型不建/不发布表单则无法录入查看（`configure_form` 或 `form.draft(rebuild:true)` + `form.publish`）。**「汇总/统计/按月」类需求**：常见做法是**一张汇总表**（独立业务模型，如 `x_monthly_summary`）接住结果，用定时任务/规则把源数据汇总写进去——**但这按需求定**，不是写死的规则。需求确认时把"汇总表"作为常规选项提出来跟用户确认，别默认往报表或二开上引。
+
+## 字段 `field`
+
+- **单据号/自动编号（原生，勿二开）**：单据号是表单 **Serial Number 控件**（字段类型 100 SequenceNo）的 `options.seqNoSetting` 分段构建器（CONSTANT/DATE/SEQNO/DATAITEM/UID 段），SEQNO 段 `resetDate:DAY/MONTH/YEAR` 原生按期重置——`describe field.update --example field-serial-number`。**不要落 SequenceService SPI 二开**（r5-crm 实证重造轮子）；编号生成时机=submit（`data.save` 不生成）。
+
+- **能做哪些事**：字段族全链 create→publish→表单绑定；**CHILD_TABLE 子表**（子列是 schemaCode=父字段 code 上的普通字段）；**计算字段**（默认用普通字段 + 「计算规则」，见下）。
+- **工具**：`field.list`、`field.create`、`field.update`、`field.publish`、`field.delete`
+- **recipe**：
+  - `omc describe field.create --example numeric-two-decimals`（数值 + scale）
+  - `omc describe field.create --example dictionary-backed-single-select`
+  - `omc describe field.create --example minimal-child-table`（子表 + 标量子列）
+  - `omc describe field.create --example business-model-dropdown`
+- **边界 / 陷阱**：
+  - **计算类需求默认走「普通字段 + 计算规则」，不要建「计算公式」字段类型（FORMULA）**：建一个**数值/单行文本**业务字段，再配一条**字段级计算规则**（`datarule.create` `dataRuleType:2`，`options.shortTextStitch={"formula","editorText","editorMark"}`）。理由：平台约定用正常业务字段承载、顺带配计算规则（真机 2026-10-08 production 表单核验 + 设计器弹窗显示）。「计算公式」字段类型不是默认，仅当确需一列专用公式时才用。
+  - **计算规则公式引用**：同类字段裸 `{字段code}`（`{a}+{b}`）；**子表列用 `{子表字段code.子列code}`**（`{Sub_item_information_table.taxInclusiveAmount}`）；子表求和 `SUM({子表.子列})`；支持 `IF(cond,a,b)`、`CASE(v,c1,r1,c2,r2)`、`VALUE()`、`AND`、比较 `=`、字符串字面量与运算符空格。recipe：`omc describe datarule.create --example field-compute-rule|field-compute-subtable-sum|field-compute-child-column`。
+  - 计算规则（`dataRuleType:2`）**在 REST 路径上不会执行也不会回填**（r17 2026-10-25 复核：`data.submit`/`data.update` 后目标字段仍为传入值）。
+  - **跨模型汇总可以用 FORMULA(100) + AGGREGATION，REST 能回算**（r17 真机 100→105）：`omc describe field.create --example formula-aggregation-cross-model`；`queryConditions` 必须给 DYNAMIC 条件（propertyCode=来源字段、currentPropertyCode=目标字段），空条件静默得 0。
+  - **同模型（含自己的子表）聚合不可用**：`field.publish` 必抛 305003（`aggregation-self-schema-cycle`，平台 `checkCycleOfAggregation:1032` 逻辑成环）。
+  - 只有 `FORMULA`（计算公式，`propertyType:100`）字段是**门户前端**计算、API 不回填（旧证据 2026-09-25/10-07，仅覆盖该字段类型）。
+  - 子表列支持标量族 + WORK_SHEET 关联列（需 `relativeCode`+options）；**子表套子表平台本身不存在**（一级子表就是上限），`MULT_WORK_SHEET` / `RELEVANCE_DATA` 不覆盖。
+
+## 默认表单 `form`
+
+- **能做哪些事**：表单 draft-first 布局、发布、`publishedHtmlJson` 绑定读回；把已发布字段绑进默认表单；**表单工具栏按钮**（`options.customButtonJson` → publish 生成 FORM 按钮）与按钮执行。
+- **工具**：`form.get`、`form.draft`、`form.publish`、`configure_form`、`form.runButton`
+- **按钮脚本（JS）读写**：`form.get --buttonScripts` 回 `scriptData`/sha；写用 `form.publish --buttonScripts [{code,script}]`（只改已有按钮脚本），或在 `buttons[]` 里给 `script`。**视图（列表）本身没有 JS 面**（`h_biz_query` 无脚本列）；脚本只有三处：表单在线JS、按钮JS、自定义页面 JS。
+- **recipe**：`omc describe configure_form --example publish-default-form`
+- **边界 / 陷阱**：默认表单已存在，用 `configure_form`/`form.draft(rebuild)`/`form.publish(rebuild:true)` 改它，不要新建；改字段形状后刷新表单一调用 `form.publish rebuild:true`。
+  - **每个模型交付前其默认表单必须已发布**：只建草稿=用户无法录入/查看。用 `configure_form` 或 `form.draft(rebuild:true)`+`form.publish` 发布。
+  - **发布态以 `form.get` 的 `published`/`existDraft` 布尔为准**，不要看 `publishedControlCodes` 是否非空（草稿字段也非空，会误判）。交付前列出每个模型的 `form.get.published` 核对。
+  - **写业务数据的前提是先发布模型+表单**：正确顺序 = 建模型 → 发布字段（`field.publish`）→ 建并**发布**默认表单（`form.publish`）→ 才 `data.save`/`data.submit`。不要在建/未发布状态下写业务数据。
+  - **表单按钮**：`form.publish {buttons:[…]}` 写 `options.customButtonJson` 并生成 `h_biz_button(triggerType=FORM)`；表单页显示还取决于流程节点 `buttonPermission.customBtns[].enabled`（设计器「表单操作」勾选）。执行用 `form.runButton`（带整条记录，区别于列表按钮的 `rule.run`）。
+
+## 列表视图 `listview`
+
+- **能做哪些事**：视图表头列、排序、筛选条件生命周期（create/configure/delete）。
+- **工具**：`listview.get`、`listview.list`、`listview.create`、`listview.configure`、`listview.delete`
+- **按钮脚本（JS）读写**：`listview.get --buttonCode <code>`（或 `--buttons`）直接回 `scriptData`/`scriptBytes`/`scriptSha256`，不用翻 artifact；写用 `listview.configure --buttonScripts [{code,script}]` 只改脚本（保留其它字段），或在 `buttons[]` 里用 `script` 简写（= `actionConfig.scriptData`）。
+- **recipe**：`omc describe listview.configure --example configure-default-list`
+- **边界 / 陷阱**：默认视图已存在，`listview.configure` 省略 code 即配置默认视图。**按字段分组（queryLayer）未取证**——别猜写。
+
+## 字段级规则 `datarule`
+
+- **能做哪些事**：字段级数据规则（bizdatarule）create/update/delete；条件必填（type4）、条件只读（type5）、条件显示（type3）、计算拼接（type2）等，按平台校验器闭环。
+- **工具**：`datarule.list`、`datarule.create`、`datarule.update`、`datarule.delete`
+- **recipe**：
+  - `omc describe datarule.create --example datarule-conditional-required`
+  - `omc describe datarule.create --example datarule-conditional-readonly`
+  - `omc describe datarule.create --example datarule-conditional-display`
+- **边界 / 陷阱**：目标字段必须已发布；同一字段多条规则时 update/delete 必须带 `dataRuleType` 去歧义。
+
+## 业务规则 `businessrule`
+
+- **能做哪些事**：图形规则图（nodeGraph）——数据事件（Create/Update/Delete）触发、按钮/流程触发、动作节点（UPDATE/CREATE/DELETE/QUERY/ASSIGN/MESSAGE/BIZ_ACTION/GET_LIST…）、BRANCH 条件分支、**定时任务 TIMING_TASK**（每天/周期，SCHEDULER 节点）。
+- **工具**：`rule.list`、`rule.get`、`rule.references`（跨规则引用检索：谁引用了服务/模型/字段）、`rule.save`、`rule.node.update`
+- **recipe**：
+  - `omc describe rule.save --example standard-business-rule-graph`
+  - `omc describe rule.save --example business-rule-branch-conditional`
+  - `omc describe rule.save --example rule-timing-task`（**每天/周期定时执行**）
+- **边界 / 陷阱**：
+  - **「每天定时执行」= 定时任务 TIMING_TASK，是平台原生配置，不是外部定时器、不是在线 JS、无需二开**；`nodeGraph.bizRuleType:2` + SCHEDULER 节点 + `nodeGraph.schedulerSetting`。
+  - 数据事件只分发到平台预置 code 行（Create/Update/Delete）；自定义 ruleCode 需按钮/流程/定时/显式触发。
+  - 保存 ≠ 可见，需 `rule.enable`（见 rule-lifecycle；绑流程事件前必须 enable，否则运行时 Business rule does not exist——r3-wms 实测）。BRANCH 多出口是「全部命中即走」，分级互斥用嵌套 BRANCH。
+  - **无存在性/计数判定原语**：BRANCH 不能按「QUERY 是否返回行」分支（PRE_OUT 分支不接收 QUERY 空结果，r3-wms 实测）。因此**硬拦保存做不到**（重复校验只能降级为打标，且**规则图内 QUERY→UPDATE 打标会静默空转**（8.6.26 UPDATE 的 inputParam 只认触发行 `_input`，`_QN_output` 引用被忽略——r4-fin 双跑实证 2026-10-09）。唯一可靠路径=改写预置 Create 规则挂 BIZ_ACTION 自调二开 markDuplicates（见 `describe rule.save --example data-duplicate-flag`））。
+
+## 规则生命周期 `rule-lifecycle`
+
+- **能做哪些事**：业务规则的启用、停用、批量停用、删除、手动执行（按钮规则验收）。
+- **工具**：`rule.enable`、`rule.disable`、`rule.delete`、`rule.disableMany`、`rule.run`、`configure_rule`
+- **边界 / 陷阱**：`enabled` 是运行时真相，`status` 可能滞后。`rule.disableMany` 默认含预置行，`customOnly:true` 只停自定义。`rule.run` 只跑自定义 code 且须 enabled（预置行被拒）；返回 data 是执行前快照，副作用用 `data.load` 另读；被更新行须 COMPLETED（引擎不查 DRAFT）。
+
+## 流程模板 `workflow`
+
+- **能做哪些事**：流程模板 get_draft/get_published、create、update、publish、bindRule（事件处理器规则绑定）、delete、workitem.list、workflow.instanceActivity（实例节点状态诊断）；参与人用组织对象。
+- **工具**：`workflow.get_draft`、`workflow.setButtons`（节点「表单操作」按钮勾选）、`workflow.get_published`、`workflow.validate`、`workflow.create`、`workflow.update`、`workflow.publish`、`workflow.bindRule`、`workflow.delete`、`workflow.permissions`、`workflow.addPermission`、`workflow.removePermission`（发起权限：发布流程不会自动建这一行，缺它一律 40009）、`configure_workflow`、`workitem.list`、`workflow.instanceActivity`、`org.role.list`、`org.department.list`、`org.user.search`、`org.role.users`、`org.role.userScope`、`org.roleGroup.create`、`org.role.create`、`org.role.update`、`org.role.addUsers`、`org.role.removeUsers`、`org.role.setUserScope`、`org.department.create`、`org.department.update`、`org.department.delete`、`org.department.users`、`org.user.create`、`org.user.update`、`org.user.delete`、`org.user.info`、`org.user.departments`、`org.role.delete`、`org.roleGroup.delete`、`org.user.transferDepartment`
+- **recipe**：`omc describe workflow.bindRule --example workflow-handler-binding`
+- **边界 / 陷阱**：greenfield 首版；`publish`/`bindRule` 不得在 `ValidateMessage[]` 拒绝时报告成功。运行时 workitem（提交/审批）走 `data.submit`；想知道实例停在哪/是否错派，用 `workflow.instanceActivity`（无 status=1=真停，参与人全是发起人=解析为空退回）。
+
+## 表单在线 JS `onlinejs`
+
+- **能做哪些事**：表单在线 JS 的 compose 六元素骨架、`draftHtmlJson.customScript`、发布与 SHA-256 回读；**读现存脚本**（`onlinejs.get` 抽 customScript innerHTML 原文+SHA-256，不必拉 form.get --full 六份 JSON）（脚本**编写**不在 CLI 范围，遵循项目在线 JS 规范或向用户索取定稿 source）。
+- **工具**：`onlinejs.get`、`onlinejs.compose`
+- **边界 / 陷阱**：仅表单在线 JS；后端在线开发（`/api/api/programming` Java 源码）用二开扩展包，不在 CLI 范围。INCREMENTAL 合并对同内容重发幂等；同头注释的整文件修订会被拒（`onlinejs-revision-replace-required`），走 `onlinejs.get` 取回 → 改 → `replace:true`。
+
+## 业务集成 `bizservice`
+
+- **能做哪些事**：业务服务与方法注册（RESTFUL/DATA_SQL/DATA_TABLE/SAP/KAFKA/SOAP）、服务清单（按分类/关键词，凭据不回显）、方法增改删、分类/连接池、导入导出、设计器测试。
+- **工具**：`service.list`、`service.get`、`method.get`、`method.update`、`method.create`、`method.delete`、`service.category.list`、`service.category.create`、`service.category.update`、`service.category.delete`、`service.dbconnpool.list`、`service.dbconnpool.create`、`service.dbconnpool.update`、`service.dbconnpool.delete`、`service.adapter_config`、`service.table_list`、`service.table_sql`、`service.register`、`service.update`、`service.delete`、`service.export`、`service.check`、`service.import`、`method.test`
+- **recipe**：`omc describe service.register --example restful-query-service`
+- **边界 / 陷阱**：方法 `configJson` 走 AES-128-ECB；**二开接口 = 扩展模块写 REST 接口 + RESTFUL 服务指向它**（页面/规则引用）；RESTFUL/DATA_SQL 绑定前须带适配器必需配置（否则是注册壳）。
+
+## 报表 `report`
+
+- **能做哪些事**：报表树/元数据读取、报表页建改删、BI dashboard 配置、图表增改删、图表数据查询、数据集读取/关联。
+- **工具**：`report.tree`、`report.get`、`report.chartdata`、`report.datasource.list`、`report.datasource.link`、`report.create`、`report.update`、`report.delete`、`report.configure`
+- **边界 / 陷阱**：
+  - **`report` 是"按需出现"的能力：只有用户显式要求报表 / 图表 / 看板 / dashboard 时才使用。常规开发流程不产出报表——不要在方案/存疑清单里对"统计/汇总/按月"之类的需求主动引入 `report`。**
+  - **跨对象统计聚合（如"按月按客户统计金额"）默认不落 `report`**：先看能否用字段/查询配置表达；表达不了就落二开聚合接口（扩展写接口 + RESTFUL），**不要默认引 BI/报表**。报表是另一条独立交付物，需用户点名。
+  - 报表页走 `/api/api/report/*`；BI 走 `/dashboard/v1/*`（无 errcode 信封，body 必带 `config:{token,reportCode,appCode}`，缺则静默 no-op）；外层 `corpId` 是真实查询键，默认 `"a"`。
+
+## 运行数据 `data`
+
+- **能做哪些事**：业务记录列出、加载、保存、更新、删除、提交（工作流）。
+- **工具**：`data.list`、`data.load`、`data.save`、`data.update`、`data.delete`、`data.submit`
+- **recipe**：
+  - `omc describe data.save --example workflow-backed-data-save`
+  - `omc describe data.submit --example workflow-backed-data-submit`（有流程）
+  - **正式数据一律 data.submit**（业务约定；save 的新建永远是 DRAFT 草稿）：
+    - 无流程模型一调：`data.submit {schemaCode, formData}`（无 id=新建并提交，COMPLETED，触发 Create 规则）——示例 `omc describe data.submit --example plain-data-submit`
+    - 已存草稿直提：`data.submit {schemaCode, bizObjectId, formData}`
+    - 流程模型两段式：`data.save {workflowCode}`（返回 workItemId）→ `data.submit {bizObjectId, workflowInstanceId, workItemId}`（workflow-backed-data-submit）
+    - `data.save` 定位=草稿/暂存；其 `submit:true` 便捷参数仍在（无流程模型等同直提），但按约定优先直接 data.submit
+- **边界 / 陷阱**：读实际业务记录是 OMC 独有能力。**计算字段（FORMULA/子表计算）不由 API 回填**——写测试数据带预算值，公式正确性人工前台确认；带子表计算字段的模型 API 写可能 50000（服务端重算 NPE），前台正常。
+
+---
+
+## 边界（boundaries）
+
+这些面**不在配置覆盖内**。被挡/不支持是**明确的答复**，不是要绕过的障碍——如实报告，不要用相近能力伪造。
+
+| 面 | 状态 | 说明 |
+| --- | --- | --- |
+| 权限 / 授权矩阵 | blocked | 授权矩阵不在配置面 |
+| 嵌套子表（子表套子表） | 平台不存在 | 平台本身就是一级子表：主表可多子表，子表不能再套子表；不是 CLI 缺口，不要按此设计 |
+| OCR / 电子签章 / 发票识别 | unsupported | 不在平台配置覆盖内 |
+| 应用发布 / 环境上线 / 生产发布 | unsupported | CLI 只做配置，不做环境发布 |
+| 在线后端编码 / EXECUTE_CODE / ONLINE_DEVELOP | unsupported | 用二开扩展包，不用在线 JS 伪造 |
+
+> `blocked` / `unsupported` 是**原生配置**的判定，通常把行为路由到另一个代码所有者（`配置 + 后端扩展`），**不等于**需求不可交付。把 blocked face 编译成「做不了、留人工」是失败模式。
+
+## 相关 topic
+
+- 需求分析（定面/归类/选路）：`omc-requirement-analysis`；线索词表：`omc-requirement-vocabulary`
+- 用哪个工具最省：`omc-tool-selection`；写前人审门：`omc-config-draft-review`
+- 被拒/状态异常：`omc-refusals`；新面取证：`omc-capability-scouting`
+- 每能力的配置怎么配：`omc-business-configuration` 的对应节；写入风险：`omc-write-hazards`

package/skills/omc-capability-scouting.md

@@ -1,55 +1,55 @@
----
-name: omc-capability-scouting
-description: Scout a NEW CloudPivot config face honestly. Use when a capability isn't in the coverage manifest yet and you must prove it before promising it.
----
-
-# Capability Scouting (扒配置方法论)
-
-How to scout a new CloudPivot configuration face honestly: the output feeds the
-coverage manifest, and a manifest promise is always evidence-backed.
-
-## Phase 0 — 定面
-
-Name the face first. The same Chinese/English word often names two engines
-(businessrule B-plane vs field-level dataRuleType; app-tree node id vs schema
-record id). The wrong face wastes everything after it.
-
-## Phase 1 — 静态三角定位
-
-1. **Enum scan** — the platform is enum-driven. The `*Type.java` enums are the
-   complete universe of a concept.
-2. **Endpoint chain** — Controller → FacadeImpl → Service along the lifecycle
-   (save/publish/delete/get_*). The gate methods ("when is this refused") are
-   half the contract.
-3. **DTO archaeology** — decompiled model fields and defaults are the request
-   shape; chase nested options JSON to leaf types.
-4. **Designer cross-check** — search the admin dist chunks by control code,
-   label, or write-mapping. The UI's write-mapping is the true wire contract.
-5. **DB persistence face** — the `h_*` tables are final truth; the API face
-   leaks. A dbsweep once caught orphans invisible to every API.
-
-## Phase 2 — 合同成形
-
-6. Grade every fact: `observed` (from source lines) vs `inferred` (from chunk
-   reverse-engineering). Keep the confidence tiers apart.
-7. Split open points into statically-closeable vs live-only.
-8. Design negative controls — a contract has discriminative power only when a
-   forged payload is refused for the right reason.
-
-## Phase 3 — live 收口
-
-9. Treat the static contract as a hypothesis and interrogate it live, item by
-   item — half the wire facts in this project came from live corrections
-   (gateway double-prefix, int enums, Void envelope, tree-node ids,
-   form/load as authoritative readback).
-10. Prefer a real traffic sample; capture designer requests when possible.
-11. Guard against false PASS: read the full green chain; "called" ≠ "passed".
-12. Before blaming the platform, retry with a different authoritative id
-    source and compare against designer traffic.
-
-## Output
-
-Per open point: evidence (file+lines / chunk anchor) → conclusion
-(observed/inferred) → verdict; close with a go/no-go and the residual
-human-decision list. A capability enters the coverage manifest only with live
-evidence; everything else stays `blocked` / `static-only` / `unsupported`.
+---
+name: omc-capability-scouting
+description: Scout a NEW CloudPivot config face honestly. Use when a capability isn't in the coverage manifest yet and you must prove it before promising it.
+---
+
+# Capability Scouting (扒配置方法论)
+
+How to scout a new CloudPivot configuration face honestly: the output feeds the
+coverage manifest, and a manifest promise is always evidence-backed.
+
+## Phase 0 — 定面
+
+Name the face first. The same Chinese/English word often names two engines
+(businessrule B-plane vs field-level dataRuleType; app-tree node id vs schema
+record id). The wrong face wastes everything after it.
+
+## Phase 1 — 静态三角定位
+
+1. **Enum scan** — the platform is enum-driven. The `*Type.java` enums are the
+   complete universe of a concept.
+2. **Endpoint chain** — Controller → FacadeImpl → Service along the lifecycle
+   (save/publish/delete/get_*). The gate methods ("when is this refused") are
+   half the contract.
+3. **DTO archaeology** — decompiled model fields and defaults are the request
+   shape; chase nested options JSON to leaf types.
+4. **Designer cross-check** — search the admin dist chunks by control code,
+   label, or write-mapping. The UI's write-mapping is the true wire contract.
+5. **DB persistence face** — the `h_*` tables are final truth; the API face
+   leaks. A dbsweep once caught orphans invisible to every API.
+
+## Phase 2 — 合同成形
+
+6. Grade every fact: `observed` (from source lines) vs `inferred` (from chunk
+   reverse-engineering). Keep the confidence tiers apart.
+7. Split open points into statically-closeable vs live-only.
+8. Design negative controls — a contract has discriminative power only when a
+   forged payload is refused for the right reason.
+
+## Phase 3 — live 收口
+
+9. Treat the static contract as a hypothesis and interrogate it live, item by
+   item — half the wire facts in this project came from live corrections
+   (gateway double-prefix, int enums, Void envelope, tree-node ids,
+   form/load as authoritative readback).
+10. Prefer a real traffic sample; capture designer requests when possible.
+11. Guard against false PASS: read the full green chain; "called" ≠ "passed".
+12. Before blaming the platform, retry with a different authoritative id
+    source and compare against designer traffic.
+
+## Output
+
+Per open point: evidence (file+lines / chunk anchor) → conclusion
+(observed/inferred) → verdict; close with a go/no-go and the residual
+human-decision list. A capability enters the coverage manifest only with live
+evidence; everything else stays `blocked` / `static-only` / `unsupported`.