@stalfh233/omc-cli 0.4.15 → 0.4.16

package/skills/omc-requirement-vocabulary.md

@@ -1,51 +1,51 @@
----
-name: omc-requirement-vocabulary
-description: Chinese cue → OMC capability lookup. Disclosed reference for requirement-analysis steps 1–2.
----
-
-# Requirement Vocabulary (需求线索词表)
-
-Reference for `omc-requirement-analysis.md` step 1. A flat peer-set: match each
-Chinese cue in the requirement to the OMC capability it implies, then read that
-capability's coverage/tools/boundaries from `omc-capabilities`.
-
-## 结构面 — structure
-
-| 中文线索 | Domain / Capability |
-| --- | --- |
-| 客户、联系人、供应商 | Customer |
-| 项目、合同、金额 | Project |
-| 产出、申报、月度、累计 | Output declaration / Cumulative amount |
-| 模型、对象、表、主数据 | Model |
-| 字段、属性、列 | Field |
-| 文本、长文本、数字、日期、时间、人员、部门、地址、附件、字典、关联、公式 | Field family (text-extension / numeric-logical / date-time / people-department / address-attachment / dictionary-enum / relevance / formula EXPRESSION-only) |
-| 表单、页面、布局、控件、必填、只读、显示 | Default form + form control binding |
-| 列表、视图、查询、筛选列 | List view |
-
-## 行为面 — behavior
-
-| 中文线索 | Capability |
-| --- | --- |
-| 规则、自动、校验、触发、事件 | businessrule graph (B 平面) |
-| create / update / delete 事件、按钮、定时任务 | Business-rule trigger |
-| 通知、站内通知、站内信、消息、提醒、报警、告警、ANDON | Business-rule **MESSAGE** 动作节点（站内通知，配置能力，非二开） |
-| 流程、审批、工作流、节点、待办 | Workflow template |
-| 脚本、联动、前端行为、onLoad、onValidate、预览 | Online JS (form-level) |
-
-## 集成面 — integration
-
-| 中文线索 | Capability |
-| --- | --- |
-| 集成、接口、服务、回调、对接外部系统 | B2 业务集成服务 (`service.register`)；二开接口 = 扩展模块写 REST 接口 + RESTFUL 服务指向它；自定义协议适配器 SPI 非常规、不在支持面 |
-| 数据、提交、保存、删除、查记录 | M2 runtime data |
-
-## 横切面 — landscape and boundaries
-
-Coverage status and boundaries for every capability (including 权限/子表/聚合/
-上线/内联/OCR) live in **`omc-capabilities`** — its 能力索引 table and
-[边界] section are the authority; read the relevant section there rather than a
-copy here. In particular, **跨模型/子表聚合、汇总、求和是配置能力**（表单「计算」
-FORMULA），不要当二开。
-
-Cue → capability is a starting point, never a substitute for 定面. A cue that
-could name two faces is resolved by the 定面表 in the parent skill.
+---
+name: omc-requirement-vocabulary
+description: Chinese cue → OMC capability lookup. Disclosed reference for requirement-analysis steps 1–2.
+---
+
+# Requirement Vocabulary (需求线索词表)
+
+Reference for `omc-requirement-analysis.md` step 1. A flat peer-set: match each
+Chinese cue in the requirement to the OMC capability it implies, then read that
+capability's coverage/tools/boundaries from `omc-capabilities`.
+
+## 结构面 — structure
+
+| 中文线索 | Domain / Capability |
+| --- | --- |
+| 客户、联系人、供应商 | Customer |
+| 项目、合同、金额 | Project |
+| 产出、申报、月度、累计 | Output declaration / Cumulative amount |
+| 模型、对象、表、主数据 | Model |
+| 字段、属性、列 | Field |
+| 文本、长文本、数字、日期、时间、人员、部门、地址、附件、字典、关联、公式 | Field family (text-extension / numeric-logical / date-time / people-department / address-attachment / dictionary-enum / relevance / formula EXPRESSION-only) |
+| 表单、页面、布局、控件、必填、只读、显示 | Default form + form control binding |
+| 列表、视图、查询、筛选列 | List view |
+
+## 行为面 — behavior
+
+| 中文线索 | Capability |
+| --- | --- |
+| 规则、自动、校验、触发、事件 | businessrule graph (B 平面) |
+| create / update / delete 事件、按钮、定时任务 | Business-rule trigger |
+| 通知、站内通知、站内信、消息、提醒、报警、告警、ANDON | Business-rule **MESSAGE** 动作节点（站内通知，配置能力，非二开） |
+| 流程、审批、工作流、节点、待办 | Workflow template |
+| 脚本、联动、前端行为、onLoad、onValidate、预览 | Online JS (form-level) |
+
+## 集成面 — integration
+
+| 中文线索 | Capability |
+| --- | --- |
+| 集成、接口、服务、回调、对接外部系统 | B2 业务集成服务 (`service.register`)；二开接口 = 扩展模块写 REST 接口 + RESTFUL 服务指向它；自定义协议适配器 SPI 非常规、不在支持面 |
+| 数据、提交、保存、删除、查记录 | M2 runtime data |
+
+## 横切面 — landscape and boundaries
+
+Coverage status and boundaries for every capability (including 权限/子表/聚合/
+上线/内联/OCR) live in **`omc-capabilities`** — its 能力索引 table and
+[边界] section are the authority; read the relevant section there rather than a
+copy here. In particular, **跨模型/子表聚合、汇总、求和是配置能力**（表单「计算」
+FORMULA），不要当二开。
+
+Cue → capability is a starting point, never a substitute for 定面. A cue that
+could name two faces is resolved by the 定面表 in the parent skill.

package/skills/omc-start-here.md

@@ -1,82 +1,82 @@
----
-name: omc-start-here
-description: Onboarding router — use on first contact with the OMC CLI, or when unsure which methodology topic and command ladder a task needs. Maps a task to its topic sequence and the first commands to run.
----
-
-# Start Here (从这里开始)
-
-Router for the `omc` CLI. Two jobs: the **first-contact command ladder**, and the
-**task → topic map**. This package's `skills/` directory is the authoritative
-shipped copy; a downstream distribution snapshot is only a mirror and must not
-be treated as a second source. Read this, then follow the topics it names.
-
-## 最小路径（先读这段就能开始）
-
-1. `omc next "<目标>"`：先看返回的 `mode` 决定读/写与路径——
-   - `read`（读回/盘点/查询/检查）→ 只给**读工具**（`field.list`/`rule.get`/`workflow.get_draft`/`data.load`…），`write:false`；这是「读回现状、为下一步或写代码取证据」的入口，别回写工具。**读全一个模型用 `model.inspect <schemaCode>`（一次拿字段/表单/列表/规则/数据规则/流程摘要），别逐面 6 次调用**；`field.list` 默认只返业务字段（`all:true` 取全）。
-   - `whole-package`（做应用/系统、从零搭）→ 带 `intent` 块：写声明式意图文件，`omc intent validate/plan/apply/readback` 按依赖顺序合成原生结构，比逐能力拼装更省、更不易漂移；`intent: partial` 未覆盖的（应用/字典/集成/运行数据）再用 `call` 补。
-   - `build`/`modify` → 按阶梯内联的**写工具 + 必填参数**执行。
-   - `scout`（能不能/怎么写/是否支持）→ 先探边界（`omc-capability-scouting`），别直接写。若 `next` 返回 **`boundary`**（`match.kind:"boundary"`，如 `ocr-e-signature`/`release-prod`/`inline-coding`），说明需求**不在覆盖内**（`write:false`）：如实报告、用 `omc capabilities` 核对，**不要**用相近能力伪造实现。
-   阶梯步骤已内联工具必填参数（`route.ladder[].tools`/`readTools`）与命中 recipe 的 `describe <tool> --example <id>`；据此直接执行——**不要再逐能力 `commands --lane`**，也不要先扫 `commands --json`/全部 `contract`/全部 `describe --full`。
-   方法论按 `route.readSections` 逐节读：对每条 `{topic, section}` 执行 `omc help <topic> --section "<section>"`（单节 0.4–3.4KB）。**不要 `omc help <topic>` 读整篇**（5–14KB，读一次就留在后续每一轮窗口）。
-2. 写前只需读 `omc-config-draft-review`（人审门）与 `omc-five-piece-flow`（发现→草稿→权限→执行→回读）；`omc-business-configuration` 按命中的能力分节读（见 `next` 的 `readSections`），不要整篇预取。
-3. 环境名以 `omc doctor` 的「环境=」或 `.omc-env` 为准；工具不确定先用默认 `describe`/`--example`，只有单个工具缺形状才用 `--full`；`describe` 带 `exampleHint`/`recipeHint` 时优先 `--example`。
-4. 只有工具不在 `next` 命中能力内、或要看 purpose/枚举时，才补一次 `commands --json --compact --lane <lane>`。非显然形状（规则图、流程模板、表单布局、RESTFUL）才单独 `describe --example`。
-5. 键名按对象不同：模型 `schemaCode`、默认表单 `sheetCode`（可省略，默认 == 模型 code）、流程 `workflowCode`/`code`——报错会提示同义键；字段族名认不出会给「最接近的族」。
-6. **写操作串行**：同一环境不要并发写；`write-lock-held` 是瞬态，等几秒重试一次即可。
-7. **单个对象优先高阶编排工具**：模型+字段用 `configure_model`（一次含全部字段），表单用 `configure_form`，列表用 `listview.configure`（**默认视图已存在，省略 code 即配置它，不要 `listview.create`**）。原子工具留给单点修改。
-8. 拿到 `detailArtifactId` 先 `artifact get <id> --summary` 看结构，再 `--keys/--jq` 取所需；`field.list`/`workflow.*` 默认面已给清单与节点摘要；`workflow.get_draft` 默认面已含 `edges`，改流程只需传 `activities`+`routes`。
-9. 每个 section 读一次即可；同一 topic 不要反复读。
-10. **复杂流程先预检角色**：读 `org.role.list`/`org.user.search`，用真实可解析对象；缺独立角色就报告阻塞，不伪造。主子表条件按规则行 `schemaCode` 回所属子模型验证。
-11. **验收不只看回读**：配置后用 opt-in `npm run test:live`（`OMC_LIVE=1`），验设计器控件/条件 Set、门户字段/列表列/选项/流程；业务规则走 `data.save(workflowCode)`→`workitem.list`→`data.submit`→`data.load`。门户断言硬重载≥2次。
-
-
-Run in a **clean project directory** (not the OMC dev repo). Start from the goal:
-
-```bash
-omc next "<目标>"                          # goal → ordered route (offline)
-omc doctor                                  # environment name and readiness
-omc call discover_environment --env <env> --args '{}'
-omc capability <selected-id>               # only the selected capability
-omc describe <tool> --example <recipe-id>   # recipe first; default describe otherwise
-omc help <topic> --section "<heading>"       # one methodology section, not all
-```
-
-Discovery precedes every write. 预算档位见 `omc-tool-selection` 的「Discovery 成本档位」；裸 `omc commands` 是有界索引，全量目录须显式 `commands --json`。
-
-Fallback faces: `omc capabilities`, `omc capability <id-or-alias> --executable`, `omc commands --json --compact`, `omc contract <lane>`, `omc describe <tool>`.
-
-## 1. Task → topic map
-
-| Your task | Read, in order |
-| --- | --- |
-| "能不能做 X" / 某能力覆盖什么 | `omc-capabilities`（能力总表；判"是否二开"前先自证） |
-| Fuzzy Chinese requirement, unknown scope | `omc-requirement-analysis` → `omc-requirement-vocabulary` |
-| Configure a business model end to end | `omc-config-draft-review` → `omc-business-configuration` → `omc-write-hazards` |
-| Unsure which tool / atom vs orchestration | `omc-tool-selection` |
-| About to write anything | `omc-config-draft-review` (human gate) → `omc-five-piece-flow` |
-| A write was refused / a status looks wrong | `omc-refusals` |
-| Cover a face the manifest doesn't have yet | `omc-capability-scouting` |
-| Decide whether the work is accepted | `omc-acceptance-criteria` |
-| A term is unclear | `omc-glossary` |
-
-The core loop behind all of them: **discover → draft → permission check →
-execute → readback/cleanup** (`omc-five-piece-flow`).
-
-## 2. The two gates every write passes
-
-1. **Human gate (conversational)** — `omc-config-draft-review`: present the
-   change package in plain language and get explicit approval.
-2. **Machine gate (environment)** — the profile's `writable` permission; a
-   production environment additionally requires `confirmProduction:true` per
-   write.
-
-There is no approval token, no `--yes`, and no self-approval switch. If a call
-refuses, work out which gate or boundary produced it from `omc-refusals`.
-
-## 3. Boundaries
-
-Out-of-coverage, blocked, or unsupported faces refuse with a manifest citation —
-that refusal is the answer, not an obstacle to route around with another tool.
-Non-8.6 (or missing version evidence) fails writes closed. `uncertain` is never
-`ok`.
+---
+name: omc-start-here
+description: Onboarding router — use on first contact with the OMC CLI, or when unsure which methodology topic and command ladder a task needs. Maps a task to its topic sequence and the first commands to run.
+---
+
+# Start Here (从这里开始)
+
+Router for the `omc` CLI. Two jobs: the **first-contact command ladder**, and the
+**task → topic map**. This package's `skills/` directory is the authoritative
+shipped copy; a downstream distribution snapshot is only a mirror and must not
+be treated as a second source. Read this, then follow the topics it names.
+
+## 最小路径（先读这段就能开始）
+
+1. `omc next "<目标>"`：先看返回的 `mode` 决定读/写与路径——
+   - `read`（读回/盘点/查询/检查）→ 只给**读工具**（`field.list`/`rule.get`/`workflow.get_draft`/`data.load`…），`write:false`；这是「读回现状、为下一步或写代码取证据」的入口，别回写工具。**读全一个模型用 `model.inspect <schemaCode>`（一次拿字段/表单/列表/规则/数据规则/流程摘要），别逐面 6 次调用**；`field.list` 默认只返业务字段（`all:true` 取全）。
+   - `whole-package`（做应用/系统、从零搭）→ 带 `intent` 块：写声明式意图文件，`omc intent validate/plan/apply/readback` 按依赖顺序合成原生结构，比逐能力拼装更省、更不易漂移；`intent: partial` 未覆盖的（应用/字典/集成/运行数据）再用 `call` 补。
+   - `build`/`modify` → 按阶梯内联的**写工具 + 必填参数**执行。
+   - `scout`（能不能/怎么写/是否支持）→ 先探边界（`omc-capability-scouting`），别直接写。若 `next` 返回 **`boundary`**（`match.kind:"boundary"`，如 `ocr-e-signature`/`release-prod`/`inline-coding`），说明需求**不在覆盖内**（`write:false`）：如实报告、用 `omc capabilities` 核对，**不要**用相近能力伪造实现。
+   阶梯步骤已内联工具必填参数（`route.ladder[].tools`/`readTools`）与命中 recipe 的 `describe <tool> --example <id>`；据此直接执行——**不要再逐能力 `commands --lane`**，也不要先扫 `commands --json`/全部 `contract`/全部 `describe --full`。
+   方法论按 `route.readSections` 逐节读：对每条 `{topic, section}` 执行 `omc help <topic> --section "<section>"`（单节 0.4–3.4KB）。**不要 `omc help <topic>` 读整篇**（5–14KB，读一次就留在后续每一轮窗口）。
+2. 写前只需读 `omc-config-draft-review`（人审门）与 `omc-five-piece-flow`（发现→草稿→权限→执行→回读）；`omc-business-configuration` 按命中的能力分节读（见 `next` 的 `readSections`），不要整篇预取。
+3. 环境名以 `omc doctor` 的「环境=」或 `.omc-env` 为准；工具不确定先用默认 `describe`/`--example`，只有单个工具缺形状才用 `--full`；`describe` 带 `exampleHint`/`recipeHint` 时优先 `--example`。
+4. 只有工具不在 `next` 命中能力内、或要看 purpose/枚举时，才补一次 `commands --json --compact --lane <lane>`。非显然形状（规则图、流程模板、表单布局、RESTFUL）才单独 `describe --example`。
+5. 键名按对象不同：模型 `schemaCode`、默认表单 `sheetCode`（可省略，默认 == 模型 code）、流程 `workflowCode`/`code`——报错会提示同义键；字段族名认不出会给「最接近的族」。
+6. **写操作串行**：同一环境不要并发写；`write-lock-held` 是瞬态，等几秒重试一次即可。
+7. **单个对象优先高阶编排工具**：模型+字段用 `configure_model`（一次含全部字段），表单用 `configure_form`，列表用 `listview.configure`（**默认视图已存在，省略 code 即配置它，不要 `listview.create`**）。原子工具留给单点修改。
+8. 拿到 `detailArtifactId` 先 `artifact get <id> --summary` 看结构，再 `--keys/--jq` 取所需；`field.list`/`workflow.*` 默认面已给清单与节点摘要；`workflow.get_draft` 默认面已含 `edges`，改流程只需传 `activities`+`routes`。
+9. 每个 section 读一次即可；同一 topic 不要反复读。
+10. **复杂流程先预检角色**：读 `org.role.list`/`org.user.search`，用真实可解析对象；缺独立角色就报告阻塞，不伪造。主子表条件按规则行 `schemaCode` 回所属子模型验证。
+11. **验收不只看回读**：配置后用 opt-in `npm run test:live`（`OMC_LIVE=1`），验设计器控件/条件 Set、门户字段/列表列/选项/流程；业务规则走 `data.save(workflowCode)`→`workitem.list`→`data.submit`→`data.load`。门户断言硬重载≥2次。
+
+
+Run in a **clean project directory** (not the OMC dev repo). Start from the goal:
+
+```bash
+omc next "<目标>"                          # goal → ordered route (offline)
+omc doctor                                  # environment name and readiness
+omc call discover_environment --args '{}'   # 单环境项目（.omc-env 在位）可省 --env；多环境才显式传
+omc capability <selected-id>               # only the selected capability
+omc describe <tool> --example <recipe-id>   # recipe first; default describe otherwise
+omc help <topic> --section "<heading>"       # one methodology section, not all
+```
+
+Discovery precedes every write. 预算档位见 `omc-tool-selection` 的「Discovery 成本档位」；裸 `omc commands` 是有界索引，全量目录须显式 `commands --json`。
+
+Fallback faces: `omc capabilities`, `omc capability <id-or-alias> --executable`, `omc commands --json --compact`, `omc contract <lane>`, `omc describe <tool>`.
+
+## 1. Task → topic map
+
+| Your task | Read, in order |
+| --- | --- |
+| "能不能做 X" / 某能力覆盖什么 | `omc-capabilities`（能力总表；判"是否二开"前先自证） |
+| Fuzzy Chinese requirement, unknown scope | `omc-requirement-analysis` → `omc-requirement-vocabulary` |
+| Configure a business model end to end | `omc-config-draft-review` → `omc-business-configuration` → `omc-write-hazards` |
+| Unsure which tool / atom vs orchestration | `omc-tool-selection` |
+| About to write anything | `omc-config-draft-review` (human gate) → `omc-five-piece-flow` |
+| A write was refused / a status looks wrong | `omc-refusals` |
+| Cover a face the manifest doesn't have yet | `omc-capability-scouting` |
+| Decide whether the work is accepted | `omc-acceptance-criteria` |
+| A term is unclear | `omc-glossary` |
+
+The core loop behind all of them: **discover → draft → permission check →
+execute → readback/cleanup** (`omc-five-piece-flow`).
+
+## 2. The two gates every write passes
+
+1. **Human gate (conversational)** — `omc-config-draft-review`: present the
+   change package in plain language and get explicit approval.
+2. **Machine gate (environment)** — the profile's `writable` permission; a
+   production environment additionally requires `confirmProduction:true` per
+   write.
+
+There is no approval token, no `--yes`, and no self-approval switch. If a call
+refuses, work out which gate or boundary produced it from `omc-refusals`.
+
+## 3. Boundaries
+
+Out-of-coverage, blocked, or unsupported faces refuse with a manifest citation —
+that refusal is the answer, not an obstacle to route around with another tool.
+Non-8.6 (or missing version evidence) fails writes closed. `uncertain` is never
+`ok`.

package/skills/omc-tool-selection.md

@@ -1,119 +1,119 @@
----
-name: omc-tool-selection
-description: Choose the right OMC CLI tool for a goal. Use when unsure whether a task needs a high-level orchestration or a low-level atom.
----
-
-# Which Tool When (何时用哪个工具)
-
-## Discovery 成本档位（按量级选，别一上来就点大档）
-
-实测：一条重难业务里，agent 对**发现面**的重复读占了任务上下文的大头。先走小档，缺形状再逐级放大。
-（round14 已把各面瘦身，下表为当前实测。）
-
-| Face | ~size | 用途 |
-| --- | ---: | --- |
-| `omc next "<goal>"` | 2–5 KB | 目标→路线（首选） |
-| `omc commands --json --compact --lane <lane>` | ~1 KB | 单能力工具行（最省的枚举面） |
-| `omc describe <tool>` / `--example <id>` | 1.5–2.5 KB | 单工具形状 |
-| `omc commands` | ~8 KB | 有界索引（name/lane/kind） |
-| `omc commands --json --compact` | ~13 KB | 全量紧凑行 |
-| `omc capabilities` | ~6 KB | 14 能力总览；`next` 已给路线时可省 |
-| `omc commands --json` | ~20 KB | 全量目录（回退面，尽量避免） |
-| `omc describe <tool> --full` | 7–19 KB | 仅当 schema 需要；不再重发 recipes（用 `--example` 取可运行参数） |
-
-裸 `omc commands` 只是索引；**全量目录必须显式 `--json`**。同一 face 不要反复读。
-
-## Minimal-path cheat sheet（最小路径速查）
-
-一条需求先问"它属于哪一类"，直接走对应的最小调用，别一上来铺工具：
-
-| 你要做的事 | 一次调用（最小路径） |
-| --- | --- |
-| 读全**一个模型**的配置（字段/表单/列表/规则/数据规则/流程摘要） | `omc call model.inspect --args '{"schemaCode":"<m>"}'`（`all:true` 含系统字段） |
-| **列模型** | `omc call model.list --args '{"filter":"<词>"}'` |
-| 读**某条业务规则**的图 | `omc call rule.get --args '{"schemaCode":"<m>","ruleCode":"Create"}'`（不必先 list 取 id） |
-| 读某模型的**流程**（只知模型码） | `omc call workflow.get_draft --args '{"schemaCode":"<m>"}'` |
-| **改规则一个节点/分支阈值** | `omc call rule.node.update --args '{"schemaCode":"<m>","ruleCode":"Create","nodeCode":"Branch_1","patch":{...}}'`（改完 `rule.enable` 生效） |
-| 从零**建一个流程**并发布 | `omc call configure_workflow --args '{"schemaCode":"<m>","name":"…","code":"<wf>","template":{...}}'` |
-| **建模型+字段+表单+列表** | `omc call configure_model --args '{"name":"…","code":"<m>","fields":[...],"publishForm":true,"listview":{"fieldCodes":[...]}}'` |
-| publish 流程前**只读预检** | `omc call workflow.validate --args '{"schemaCode":"<m>"}'` |
-| **批量停用**某模型规则 | `omc call rule.disableMany --args '{"schemaCode":"<m>"}'`（默认含预置行；`customOnly:true` 只停自定义） |
-| 字段清单（去噪） | `omc call field.list --args '{"schemaCode":"<m>","published":true}'`（默认业务字段，`all:true` 取全） |
-
-**业务键优先**：`rule.get`/`datarule.update`/`datarule.delete`/`workflow.get_*` 接受业务键
-（schemaCode+ruleCode / schemaCode+propertyCode / schemaCode），免去先 list 取 id。
-
-**先看 `omc next` 的 `mode`**：`read` 只给读工具；`whole-package` 给 intent 声明式指引；
-`build`/`modify` 给写工具；`scout`（能不能/怎么写）先探边界。
-
-**纯读不必先发现**：已知读哪一面就直接 `omc call <读工具>`（上表），省掉 `next`/`discover_environment`；只有选不出工具时才用 `next`。发现仪式（`next`/`capabilities`/`discover_environment`）是写前与选不出工具时的路径。
-
-## High layer — orchestrated CLI calls
-
-| Goal | Tool |
-| --- | --- |
-| Inspect environment health | `get_status` |
-| Full first look | `discover_environment` |
-| New model to usable state (model → field → field.publish → form.draft → form.publish) | `configure_model`（+ `listview` 参数到列表） |
-| Bind fields into the default form and publish | `configure_form` |
-| Business rule saved and enabled | `configure_rule` |
-| New workflow: create → update → publish (+ bind rules) | `configure_workflow` |
-| Health chain (config → credential → login → version family → fingerprint) | `doctor` |
-| Configure in-session with the human | `setup.start` → `setup.commit` |
-
-## Low layer — atoms for fine control
-
-Reads: `environment.fingerprint`, `field.list`, `form.get`, `rule.list`,
-`data.list`, `data.load`, `service.get`, `app.list`, `coverage.manifest`,
-`workflow.get_draft`, `workflow.get_published`.
-
-Writes:
-
-- Model: `model.create`, `model.delete`
-- Applications: `app.create`, `app.delete` (deleting cascades its models)
-- Fields: `field.create`, `field.update`, `field.publish`, `field.delete`
-- Forms: `form.draft`, `form.publish`
-- Rules: `rule.save`, `rule.enable`, `rule.disable`, `rule.delete`
-- Workflow templates: `workflow.create`, `workflow.update`, `workflow.publish`, `workflow.bindRule`, `workflow.delete`
-- Online JS: 本 CLI 只**发布/回读**（`onlinejs.compose`，平台模板保真）；脚本**编写**不在 CLI 范围——遵循当前项目自带的在线 JS 编写规范（若有），否则向用户/设计者索取已定稿 `source`。后端的在线开发（Java 源码）用二开扩展包，也不在本 CLI 范围
-- M2 data: `data.save`, `data.submit`, `data.delete`
-- B2 services: `service.register`, `service.delete`
-- List views: `listview.create`, `listview.configure`, `listview.delete`
-
-## Decision rules
-
-1. Default to the high layer; drop to atoms only to compose what the orchestration doesn't cover.
-2. Preview any write with `dryRun:true`; it returns the plan and executes nothing.
-3. `writable:false` refuses before any wire. A production write additionally requires `confirmProduction:true`.
-4. Out-of-coverage desire (permissions, nested child tables, OCR, app publish)? The refusal cites the manifest entry — that is the answer. Check `coverage.manifest`.
-5. If any call returns `uncertain`, stop writing and re-run discovery before the next write.
-
-## Key-name table (同一对象在不同工具里的键名)
-
-The same object is addressed under different keys. A wrong key is dropped silently
-by the Tool-input gate and then reported only as `X: Required` — it never says
-"the field you sent was ignored". Check here first.
-
-| Object | Tools | Key |
-| --- | --- | --- |
-| Model | `model.*`, `field.*`, `form.*`, `datarule.*`, `rule.*` | `schemaCode` |
-| Workflow template | `workflow.get_draft`, `workflow.get_published`, `workflow.bindRule` | `workflowCode`（或 `schemaCode`，工具内部解析） |
-| Workflow template | `workflow.create`, `workflow.update`, `workflow.publish`, `workflow.delete` | `code`（+ `schemaCode`） |
-| Default form | `form.get`, `form.draft`, `form.publish`, `configure_form` | `schemaCode`（必填）+ `sheetCode`（可选，默认=schemaCode） |
-| Field | `field.create`, `field.update`, `field.delete` | `code` |
-
-**业务键优先（identity seam）**：多个只读/改写工具现在接受业务键，免去先 list 取 id：
-
-- `rule.get` 接受 `schemaCode + ruleCode`（返回**当前生效行**，不用先 `rule.list` 拿 id）。
-- `datarule.update` / `datarule.delete` 接受 `schemaCode + propertyCode(+dataRuleType)`（同一字段多条规则时必须带 `dataRuleType` 去歧义）。
-- `workflow.get_draft` / `workflow.get_published` 接受 `schemaCode`（不是每个模型都有流程；没有则 `exists:false`）。
-
-**按工具别名（同一对象换个键名也收）**：`workflow.create/update/publish/delete` 的 `code`
-也接受 `workflowCode`；`field.create/update/delete` 的 `code` 也接受 `propertyCode`。
-别名只在规范键缺失时补入，不会覆盖；它**按工具声明**（不是全局），因为同一个 `code`
-在不同工具里可能指不同对象。
-
-精确 `id` 仍然可用，旧调用不受影响。`workflowCode` 与 `code` 指同一流程：读/绑定工具用
-`workflowCode`，写工具用 `code`（写工具现已同时接受 `workflowCode`）；读工具现在也可直接给 `schemaCode`。
-
-Fixture discipline: one-shot `omc_mcp_*` fixtures, cleaned up in reverse order, zero residue.
+---
+name: omc-tool-selection
+description: Choose the right OMC CLI tool for a goal. Use when unsure whether a task needs a high-level orchestration or a low-level atom.
+---
+
+# Which Tool When (何时用哪个工具)
+
+## Discovery 成本档位（按量级选，别一上来就点大档）
+
+实测：一条重难业务里，agent 对**发现面**的重复读占了任务上下文的大头。先走小档，缺形状再逐级放大。
+（round14 已把各面瘦身，下表为当前实测。）
+
+| Face | ~size | 用途 |
+| --- | ---: | --- |
+| `omc next "<goal>"` | 2–5 KB | 目标→路线（首选） |
+| `omc commands --json --compact --lane <lane>` | ~1 KB | 单能力工具行（最省的枚举面） |
+| `omc describe <tool>` / `--example <id>` | 1.5–2.5 KB | 单工具形状 |
+| `omc commands` | ~8 KB | 有界索引（name/lane/kind） |
+| `omc commands --json --compact` | ~13 KB | 全量紧凑行 |
+| `omc capabilities` | ~6 KB | 14 能力总览；`next` 已给路线时可省 |
+| `omc commands --json` | ~20 KB | 全量目录（回退面，尽量避免） |
+| `omc describe <tool> --full` | 7–19 KB | 仅当 schema 需要；不再重发 recipes（用 `--example` 取可运行参数） |
+
+裸 `omc commands` 只是索引；**全量目录必须显式 `--json`**。同一 face 不要反复读。
+
+## Minimal-path cheat sheet（最小路径速查）
+
+一条需求先问"它属于哪一类"，直接走对应的最小调用，别一上来铺工具：
+
+| 你要做的事 | 一次调用（最小路径） |
+| --- | --- |
+| 读全**一个模型**的配置（字段/表单/列表/规则/数据规则/流程摘要） | `omc call model.inspect --args '{"schemaCode":"<m>"}'`（`all:true` 含系统字段） |
+| **列模型** | `omc call model.list --args '{"filter":"<词>"}'` |
+| 读**某条业务规则**的图 | `omc call rule.get --args '{"schemaCode":"<m>","ruleCode":"Create"}'`（不必先 list 取 id） |
+| 读某模型的**流程**（只知模型码） | `omc call workflow.get_draft --args '{"schemaCode":"<m>"}'` |
+| **改规则一个节点/分支阈值** | `omc call rule.node.update --args '{"schemaCode":"<m>","ruleCode":"Create","nodeCode":"Branch_1","patch":{...}}'`（patch 后自动 save；带 `"publish":true` 则保存+发布一调完成，生效仍需 `rule.enable`） |
+| 从零**建一个流程**并发布 | `omc call configure_workflow --args '{"schemaCode":"<m>","name":"…","code":"<wf>","template":{...}}'` |
+| **建模型+字段+表单+列表** | `omc call configure_model --args '{"name":"…","code":"<m>","fields":[...],"publishForm":true,"listview":{"fieldCodes":[...]}}'` |
+| publish 流程前**只读预检** | `omc call workflow.validate --args '{"schemaCode":"<m>"}'` |
+| **批量停用**某模型规则 | `omc call rule.disableMany --args '{"schemaCode":"<m>"}'`（默认含预置行；`customOnly:true` 只停自定义） |
+| 字段清单（去噪） | `omc call field.list --args '{"schemaCode":"<m>","published":true}'`（默认业务字段，`all:true` 取全） |
+
+**业务键优先**：`rule.get`/`datarule.update`/`datarule.delete`/`workflow.get_*` 接受业务键
+（schemaCode+ruleCode / schemaCode+propertyCode / schemaCode），免去先 list 取 id。
+
+**先看 `omc next` 的 `mode`**：`read` 只给读工具；`whole-package` 给 intent 声明式指引；
+`build`/`modify` 给写工具；`scout`（能不能/怎么写）先探边界。
+
+**纯读不必先发现**：已知读哪一面就直接 `omc call <读工具>`（上表），省掉 `next`/`discover_environment`；只有选不出工具时才用 `next`。发现仪式（`next`/`capabilities`/`discover_environment`）是写前与选不出工具时的路径。
+
+## High layer — orchestrated CLI calls
+
+| Goal | Tool |
+| --- | --- |
+| Inspect environment health | `get_status` |
+| Full first look | `discover_environment` |
+| New model to usable state (model → field → field.publish → form.draft → form.publish) | `configure_model`（+ `listview` 参数到列表） |
+| Bind fields into the default form and publish | `configure_form` |
+| Business rule saved and enabled | `configure_rule` |
+| New workflow: create → update → publish (+ bind rules) | `configure_workflow` |
+| Health chain (config → credential → login → version family → fingerprint) | `doctor` |
+| Configure in-session with the human | `setup.start` → `setup.commit` |
+
+## Low layer — atoms for fine control
+
+Reads: `environment.fingerprint`, `field.list`, `form.get`, `rule.list`,
+`data.list`, `data.load`, `service.list`, `service.get`, `app.list`, `coverage.manifest`,
+`workflow.get_draft`, `workflow.get_published`.
+
+Writes:
+
+- Model: `model.create`, `model.delete`
+- Applications: `app.create`, `app.delete` (deleting cascades its models)
+- Fields: `field.create`, `field.update`, `field.publish`, `field.delete`
+- Forms: `form.draft`, `form.publish`
+- Rules: `rule.save`, `rule.enable`, `rule.disable`, `rule.delete`
+- Workflow templates: `workflow.create`, `workflow.update`, `workflow.publish`, `workflow.bindRule`, `workflow.delete`
+- Online JS: 本 CLI 只**发布/回读**（`onlinejs.compose`，平台模板保真）；脚本**编写**不在 CLI 范围——遵循当前项目自带的在线 JS 编写规范（若有），否则向用户/设计者索取已定稿 `source`。后端的在线开发（Java 源码）用二开扩展包，也不在本 CLI 范围
+- M2 data: `data.save`, `data.submit`, `data.delete`
+- B2 services: `service.register`, `service.delete`
+- List views: `listview.create`, `listview.configure`, `listview.delete`
+
+## Decision rules
+
+1. Default to the high layer; drop to atoms only to compose what the orchestration doesn't cover.
+2. Preview any write with `dryRun:true`; it returns the plan and executes nothing.
+3. `writable:false` refuses before any wire. A production write additionally requires `confirmProduction:true`.
+4. Out-of-coverage desire (permissions, nested child tables, OCR, app publish)? The refusal cites the manifest entry — that is the answer. Check `coverage.manifest`.
+5. If any call returns `uncertain`, stop writing and re-run discovery before the next write.
+
+## Key-name table (同一对象在不同工具里的键名)
+
+The same object is addressed under different keys. A wrong key is dropped silently
+by the Tool-input gate and then reported only as `X: Required` — it never says
+"the field you sent was ignored". Check here first.
+
+| Object | Tools | Key |
+| --- | --- | --- |
+| Model | `model.*`, `field.*`, `form.*`, `datarule.*`, `rule.*` | `schemaCode` |
+| Workflow template | `workflow.get_draft`, `workflow.get_published`, `workflow.bindRule` | `workflowCode`（或 `schemaCode`，工具内部解析） |
+| Workflow template | `workflow.create`, `workflow.update`, `workflow.publish`, `workflow.delete` | `code`（+ `schemaCode`） |
+| Default form | `form.get`, `form.draft`, `form.publish`, `configure_form` | `schemaCode`（必填）+ `sheetCode`（可选，默认=schemaCode） |
+| Field | `field.create`, `field.update`, `field.delete` | `code` |
+
+**业务键优先（identity seam）**：多个只读/改写工具现在接受业务键，免去先 list 取 id：
+
+- `rule.get` 接受 `schemaCode + ruleCode`（返回**当前生效行**，不用先 `rule.list` 拿 id）。
+- `datarule.update` / `datarule.delete` 接受 `schemaCode + propertyCode(+dataRuleType)`（同一字段多条规则时必须带 `dataRuleType` 去歧义）。
+- `workflow.get_draft` / `workflow.get_published` 接受 `schemaCode`（不是每个模型都有流程；没有则 `exists:false`）。
+
+**按工具别名（同一对象换个键名也收）**：`workflow.create/update/publish/delete` 的 `code`
+也接受 `workflowCode`；`field.create/update/delete` 的 `code` 也接受 `propertyCode`。
+别名只在规范键缺失时补入，不会覆盖；它**按工具声明**（不是全局），因为同一个 `code`
+在不同工具里可能指不同对象。
+
+精确 `id` 仍然可用，旧调用不受影响。`workflowCode` 与 `code` 指同一流程：读/绑定工具用
+`workflowCode`，写工具用 `code`（写工具现已同时接受 `workflowCode`）；读工具现在也可直接给 `schemaCode`。
+
+Fixture discipline: one-shot `omc_mcp_*` fixtures, cleaned up in reverse order, zero residue.