StructAI MCP Server

仓库：github.com/lkxlzx/StructAI-MCP-Server

MIDAS Open API 的**机器可读端点注册表（Endpoint Registry）**与配套开发文档、参考实现。

本仓库是 StructAI 多结构工程软件一体化 MCP（Model Context Protocol）Server 的知识层： 把 MIDAS 官方手册（Help Center JSON API、Civil NX 手册、Civil Designer 手册、GitHub 韩文整理版） 交叉合并为可直接被程序加载的 Registry，并用真实 MIDAS 实例逐端点实测验证。

---

0. 🔴 会话边界（硬性原则）

一个批次 = 一个会话。

每完成 docs/07 §12 的一个批次（P01 / P02 / …），必须新建对话， 不得在同一窗口继续下一批 —— 否则上下文超长会稀释架构红线等早期约束。

• 完整规则 / 交接协议 / 批次状态表 / 可复制的续接提示词 → docs/08_会话交接与续接提示词_v1.0.md
• 每个新会话的第一个入口就是 docs/08；不要重读 docs/01–06 全文（90.5 万字符）

---

目录

registry/          Endpoint Registry（636 端点定义 + 625 JSON Schema + 索引 + 实例矩阵）
examples/          参考客户端与冒烟测试（midas_client.py / smoke_test.py / cases.json）
app/               Core 实现（P01 起逐步落地；进度见 docs/08 §3）
pyproject.toml     依赖与工具链配置（冻结于 docs/07 §3.1–§3.2）· .env.example 环境变量样例
docs/              V2 规范 01–06 + 通读报告 00 + 开发方案 07   ← 唯一开发依据
archive/legacy_v1/ 非规范性历史资料（V1 文档与实测留痕，不作依据）
MIDAS_API_*.md     MIDAS 官方手册整理（外部厂商资料）

---

1. Registry

字段与用法见 registry/README.md。

实测验证状态（availability）：verified 514 · unverified 23 · untested 126。

⚠️ P176 / R168：verified +2（DOC.EXPORT / DOC.IMPORT 真机收口）· untested +27（「导出可见但未登记」的表补登，方法集未逐表实测 ⇒ 如实留在 untested）。

1.1 主指标：接口层端到端（docs/07 §15.6.3）

⚠️ availability 是端点级、次指标。产品对外的单位是 Operation， 故主指标是接口层端到端与生产路径可用 Operation（docs/07 §15.6.3）。

证据 = registry/live/{interface_path_probe,interface_read_probe,flagship_chain_probe}.json； 生成器 = registry/tools/probe_interface_paths.py / probe_flagship_chain.py（均可 --check 离线复算）。

⚠️ R158（P165-b 更正）：主指标不再手写 —— 它由 python registry/tools/check_operation_availability.py --check 可执行复算。 旧值 62 / 71（「6 个端点 → 9 个 Operation」）是错的：它把 DESIGN.CODE_CHECK 算成可用，而该 Operation 的 7 条路由全部被挡（steel 的末步 POST.STEELCODECHECK 仍是 PARTIAL；concrete:* / src:* 需原生崩溃护栏拦住的 *-ANAL）。⇒ R158 的真实值 = 61 / 71、挡点端点 15 个。手写的指标必然漂。

⚠️ 上表「接口层读路径端到端」是 P153 的基线（在空专用项目上测得 ⇒ 取报表族 必然 FAILED：原生回 400 "[empty] Cannot generate table data…"）。 ✅ P167 / R160 在有分析结果的自建项目上另测了一次生产路径（见 §5.1）—— 两处判据不同、项目不同，不互相覆盖。

✅ R159（P166 收口）：单点最大杠杆 VIEW.RESULTGRAPHIC 已收口 —— 找到纯 API 进结果视图（post）的路径（成因 = 原请求体缺 TYPE_OF_DISPLAY； TYPE_OF_DISPLAY..OPT_CHECK = true 才是把结果图形打开的开关）， 效果判据 7 / 7 PASSED（33438 → 81236 字节；换 CURRENT_MODE → 84494； 阳性对照 40211 vs 33438）⇒ untested → verified ⇒ 它挡住的 6 个 VIEW.* Operation 解锁 ⇒ 主指标 61 / 71 → 67 / 71（被挡 10 → 4 · 挡点端点 15 → 14）。 证据 = registry/live/view_result_post_probe.json； 生成器 = registry/tools/probe_view_result_post.py（可 --check 离线复算）。

✅ R160（P167 收口）：POST.TABLE 的 TABLE_TYPE 枚举来源从「help center 一篇文章的 json_schema（2 个取值）」换成两个可复算来源的并集 —— ① registry/manifest.json 里 已登记的 POST.TABLE.* 端点取值（194）∪ ② 上游手册全部 json_schema 声明的 TABLE_TYPE.enum（121）= 225（严格包含旧枚举 ⇒ 只增不减）。 效果判据 PASSED（原生 POST /POST/TABLE {TABLE_TYPE: "DISPLACEMENTG"} ⇒ 200 · HEAD 9 列 · DATA 63 行；经 MCP Tool 契约的规范化结果 rows = 63； 伪 token 零请求仍被 spec_guard 拦）⇒ untested → verified ⇒ 它挡住的 1 个 RESULT.ANALYSIS.SUMMARY（通用取表入口）解锁 ⇒ 主指标 67 / 71 → 68 / 71 （被挡 4 → 3 · 挡点端点 14 → 13）。 证据 = registry/live/post_table_enum_probe.json； 生成器 = registry/tools/probe_post_table_enum.py（可 --check 离线复算）； 枚举生成器 = registry/tools/sync_table_type_enum.py（--check 断言「已落盘 == 机械结果」）。

✅ R161（P168 收口）：枚举来源普查抓到一件比「某个枚举太窄」严重得多的事 —— spec_guard（R140）对 104 / 225 个「带枚举约束」的 Schema 文件一个字段都不检查 （registry/schema/** 有 393 / 625 个文件的根键就是包装键，而闸门的下钻约定是 schema["properties"][包装键]）⇒ 盲区。 修法 = 核心 1 行（用户已授权）：adapter._build 的 spec_guard 由 registry.schema_json(key) 改用 registry.effective_schema(key)（P09 的 unwrap_schema()） ⇒ 可下钻 121 → 225（盲区 104 → 0，已可见的 121 个零回归）。 ⚠️ 可见性是放大器：恢复后窄枚举立刻变成「拦住合法调用」的事故 ⇒ 同批先补枚举： ① VIEW.RESULTGRAPHIC 的 CURRENT_MODE（R155 留缺的缺枚举）补 36 个取值； ② 6 个变体端点的 TABLE_TYPE（来源太窄）追加登记表的 token。 效果判据 PASSED（6 / 6 个登记 token 原生 200；RESULT.NODE.DISPLACEMENT 经生产路径 取到 63 行 ⇒ 真的走了变体文件的枚举；合法 CURRENT_MODE 真的发出去且三张截图 32023 → 79969 → 83282 字节两两不同；非法 CURRENT_MODE 零请求被拦）。 ⚠️ 主指标 68 / 71 不变 —— 本批的价值在防事故（R140 的目的），不在抬主指标。 证据 = registry/live/spec_enum_audit.json（普查）· registry/live/spec_enum_probe.json（真机）； 工具 = registry/tools/check_spec_enums.py（四分类 + 三标志 + 台账，--check 零请求）· 生成器 = registry/tools/sync_result_graphic_modes.py · registry/tools/sync_table_type_variant_enum.py。

✅ R169（P176 收口）—— 设计规范是运行时数据**，不是接口层的常量**： 接口层原先写死了「生效规范 / 配置端点的字段集 / 材料库名」。根因是设计规范三处必须同族 —— DRC.DGNCODE（规范码）· MATL.STANDARD（材料库名，如 GB/T10(RC)，不是规范码）· MDGN.CONC_CODE（配筋材料码）；只切一处 ⇒ 引擎跳过所有单元 （⚠️ 不崩，只是 400 failed:LoadCombination + *-TABLE 0 行）。 三条实测事实：① 路径段是固定路由名（/design/RC/GB-T50010-10/DCO → 404） ⇒ 规范码不能进 URI，切换只能靠 DRC.DGNCODE；② 配置端点字段集随规范变化 （KDS 12/13、GB/T50010-10 0），而 GET /info/... 在两种规范下返回同一份 13 字段 ⇒ 自省不能作来源，只能实测（registry/live/design_code_field_sets.json）； ③ DCO 可选（为空时设计链照常跑通）。 ⇒ 主指标 71 / 73 不变（本批不改任何裁定）—— 价值在去硬编码与归因更正 （推翻 P164-c 的「BD-ANAL 必崩」：同 build 实测不崩且设计真的产出）。 ⚠️ 新登记 R170：spec_guard 对 patternProperties 下的枚举一个都不检查 （21 个文件 / 90 个枚举节点 100% 盲区；两相对照：DESIGN.RC.DRC 的 DGNCODE="TOTALLY-BOGUS" 不拦，同一取值在 OPE.LCOM-CONC 拦） —— 如实留缺，修它须用户授权（核心闸门改动）。 细节 = registry/README.md §8.31 · docs/07 §16.1 R169 / R170。

✅ R166（P174 收口）：POST.STEELCODECHECK 真机实测收口 ⇒ 它挡住的 DESIGN.CODE_CHECK（钢铁路由）解锁 ⇒ 主指标 68 / 71 → 69 / 71 （被挡 3 → 2 · 挡点端点 13 → 4）。 判据 = 效果（铁律 ⓪，不是状态码）：同一个请求体（空体 {}）—— 无设计结果时 0 行 · CODE-ANAL 跑完后 2 行（根键 vSECT / vELEM） ⇒ 输出真的跟着设计状态走；防回显（R157 的仪器有效性）：取值 ELEM 1 / RAT 8.0846，而手册 json_schema 示例是 ELEM 10 / RAT 0.6119、本模型没有 单元 10 ⇒ 不是 schema 回显。 ⚠️ 本端点对 Argument 完全不敏感：空体 / 自名 TABLE_TYPE / 逐字照 CODE-TABLE / 伪取值，四者答复逐字节同形 ⇒ 「坏取值被拦」这一形态的阴性对照结构上不可用 ⇒ 改用状态对照（如实记录，不硬凑假对照）。 证据 = registry/live/steelcodecheck_probe.json； 生成器 = registry/tools/probe_steelcodecheck_p174.py（可 --check 离线复算）。

⚠️ R169 / R170（P176 / P177）—— 设计规范是运行时数据；闸门仍有一处盲区： 上表「谁能修」是端点可用性的归因，不覆盖「为什么某个设计链跑不出结果」。 P176 实测的根因是配置不同族（DRC.DGNCODE / MATL.STANDARD / MDGN.CONC_CODE 三处 必须同族；⚠️ MATL.STANDARD 的合法值是材料库名，不是规范码）⇒ 只切一处时 引擎跳过所有单元（⚠️ 不崩，只是 400 failed:LoadCombination + *-TABLE 0 行） ⇒ 不要据此判定「产品不支持」。三条实测事实（路径段是固定路由名 / 字段集随规范变化 且自省不反映 / DCO 可选）见 registry/README.md §8.31。 ⚠️ R170 如实留缺：spec_guard 对 patternProperties 下的枚举一个都不检查 （21 个文件 / 90 个枚举节点 100% 盲区）⇒ DESIGN.RC.DRC 的 DGNCODE="TOTALLY-BOGUS" 不拦，而同一取值在 OPE.LCOM-CONC（枚举在 properties 下）拦。 ⇒ 这 21 个文件的枚举约束目前只是文档，不是闸门；修它须用户授权（核心闸门改动）。 主指标不受影响（仍 71 / 73）。

⚠️ R166（P173，归因）：主指标的缺口归因也不手写 —— python registry/tools/check_operation_availability.py --attribution（零请求）给出 每个挡点端点卡在谁（我方 / MIDAS 侧）。⚠️ 收口 POST.STEELCODECHECK 后， 我方的可拿下项已全部收口 ⇒ 剩余 4 个挡点端点全部是 MIDAS 侧（崩溃族）。 ⇒ 「下一步该做什么」见 §5.1。

---

2. 文档

2.1 规范性文档（唯一开发依据）

docs/04 §14 的 66 条种子全部为 PARTIAL，生产路径会被 RegistryMappingNotVerified 拒绝； 涉及 MIDAS API 一律以 registry/ 为准。

2.2 非规范性历史资料（不作开发依据）

⚠️ archive/legacy_v1/ 下全部文件不作为开发依据，不作为准则，仅用于来源追溯与审计核对。 索引与约束见 archive/legacy_v1/README.md。

2.3 外部证据输入（第三方 SDK 对照，不作开发依据）

⚠️ 上列内容全部是外部证据，不是本仓库的实测结论。 依 §8.2 的既定口径，凡涉及 products / 必填性 / 类型的变更，均需我方实例实测 + 显式裁决。 导入工具默认只预演；本批次未改动 registry/ 任何数据。

---

3. 参考实现与冒烟测试

cd examples
$env:MIDAS_BASE_URL = "http://localhost:3030/gen"
$env:MIDAS_MAPI_KEY = ""

python smoke_test.py                                    # dry-run（离线结构校验）
python smoke_test.py --live --expect-product GEN_NX     # 真实调用（默认只调 GET）

smoke_test.py 会输出结构化报告（smoke_report_*.json），区分 OK / OK_EMPTY / INDETERMINATE / ENDPOINT_NOT_FOUND / CLIENT_NOT_CONNECTED 等状态。

---

4. 安全约定

• MAPI-Key 只经环境变量传入，本仓库不包含任何真实密钥。
• 客户端内置破坏性调用护栏：
  • NX 系 DELETE 必须给路径 key（DELETE {uri}/{key}）——不带路径 key 会删除全表（官方手册 + 实测确认）；
  • Civil Designer 的 DELETE 空主体 / Type=0 表示删除全部，需显式开关放行。

---

5. 已知边界

⚠️ 本节按 docs/07 §15.6.3 的指标层级写：主指标 = 接口层端到端 / 生产路径可用 Operation； availability 计数与缺口账本属次指标 / 账本，不驱动优先级。

5.1 🔴 主指标上的剩余缺口：4 个端点 → 2 个 Operation（收口即 71 / 71）

⚠️ R158 更正：本节旧值写「6 个端点 → 9 个 Operation」（62 / 71）， 漏了 DESIGN.CODE_CHECK 与 POST.STEELCODECHECK，且只列了 BD/BC 两个变体、 没算 CD/BRD/WD/CC。⇒ R158 的真实值 = 61 / 71。 ✅ R159 收口：单点最大杠杆 VIEW.RESULTGRAPHIC 已解锁 6 个 Operation ⇒ 值 = 67 / 71。 ✅ R160 收口：通用取表入口 POST.TABLE 已解锁 RESULT.ANALYSIS.SUMMARY ⇒ 值 = 68 / 71。 ✅ R166 收口：POST.STEELCODECHECK 已解锁 DESIGN.CODE_CHECK（钢铁路由， 真机实测；判据 = 效果）⇒ 当时现值 = 69 / 71（后由 R168 抬到 71 / 73，见下）， 逐条由 python registry/tools/check_operation_availability.py 复算。

✅ R168（P176 新增并收口）：新增 MODEL.EXPORT / MODEL.IMPORT 两条 Operation —— 模型 ↔ JSON 的官方通道。端点 DOC.EXPORT / DOC.IMPORT 由 untested 真机实测收口为 verified，判据 = 效果（铁律 ⓪）：导出真的落盘 （4 708 字节 ∧ DBG 218 张表 ∧ 10 项哨兵逐表与读回同形）； 导入后新编号按写入值读回（节点 9001 → X = 100）。 ⇒ 主指标 69 / 71 → 71 / 73（分子分母各 +2；被挡仍 2 · 挡点端点仍 4）。 探针 = registry/tools/probe_model_doc_p175.py · 证据 = registry/live/model_doc_probe.json。

⚠️ R166 的关键：我方不依赖崩溃族 *-ANAL 的可拿下项已全部收口 （--attribution 的 ours 现为空）⇒ 剩余 4 个挡点端点全部卡在 MIDAS 侧。 即：python registry/tools/check_operation_availability.py --attribution 现在会打印 「我方不依赖 *-ANAL 的可自己拿下的一格：（已全部收口）」。

⚠️ R165（P172，2026-10-15）—— 收益映射本身也曾是手写的，于是漂了： 上表第三行原先照抄 docs/reports/P160e-a §1 的「0（单独收口不解锁）」， 理由是「DESIGN.CODE_CHECK 还需 12 个 RC/SRC 端点」。实测（离线可复算）： DESIGN.CODE_CHECK 的 steel 路由 = CODE-ANAL → CODE-TABLE → POST.STEELCODECHECK， 前 2 步已 VERIFIED ⇒ 只有末步挡着 ⇒ 收口它 ⇒ 解锁 DESIGN.CODE_CHECK （主指标 68 → 69 · 被挡 3 → 2 · 挡点端点 13 → 4）。 ⇒ 与 R158 同一类教训（那次漂的是主指标，这次漂的是收益映射）⇒ 把它变成可执行判定：python registry/tools/check_operation_availability.py --benefit。

⚠️ 顺带澄清一个口径**：挡点个数**（13）不是解锁代价 —— routes 是替代路线 ⇒ 解锁 DESIGN.CODE_CHECK 只要 1 个端点、 DESIGN.CONCRETE / DESIGN.SRC 各 2 个、全部 3 个只要 4 个 （BD-ANAL + BD-TABLE + BC-ANAL + BC-TABLE）。 ⚠️ 但可实施性卡在产品侧：那 4 个里有 2 个 *-ANAL 是崩溃族 （BD-ANAL 实测打崩 GenNX.exe，R154）⇒ 「多花几个端点就能绕开」不成立。 ⚠️ 另：零边际收益 ≠ 没用 —— 6 个 *-TABLE 单独收口收益为 0， 但成组收口（BD-ANAL + BD-TABLE）真的解锁 DESIGN.CONCRETE + DESIGN.CODE_CHECK。

⚠️ 收益 +1 ≠ 马上能做（代价那一半，零请求可复算）：POST.STEELCODECHECK 的 请求体来源在本仓不成立 —— ① 手册条目没有 Request Examples / Response Examples 两节（它是 13 个挡点端点里唯一缺的；对照 POST.TABLE / POST.TEXT 都有）； ② 手册的 json_schema 根键 = vSECT / vELEM（规格表写的是 Combined Strength Ratio / Slenderness Ratio / Deflection ⇒ 结果量）⇒ 那是响应形状，不是请求形状； ③ 我们落盘的 Schema 与它逐字节同形且没有 properties ⇒ spec_guard 对它 一个字段都不检查。⇒ 收口须一次有副作用的授权测量（R151 的教训： 不按示例体硬凑 —— 这里连示例体都没有）。

⚠️ R166（P173，2026-10-16）—— 收益 ≠ 可实施性：上表「谁能修」那一列现在算出来： python registry/tools/check_operation_availability.py --attribution（零请求）。 机械结果：13 个挡点端点里 12 个卡在 MIDAS 侧、1 个（POST.STEELCODECHECK）是我方的。 ⚠️ 两个反直觉的机械事实**： ① 修好整个崩溃族，主指标一格都不动**（仍 68 / 71）—— 因为剩下的挡点是 6 个 *-TABLE

• POST.STEELCODECHECK，而 *-TABLE 要读的设计结果只能由崩溃族的 *-ANAL 产出 （-ANAL = 执行分析并写结果，-TABLE = 读那份结果；两个端点 YAML 的标题逐字如此） ⇒ 「卡在 MIDAS 侧」是结构性的，不是「多收口几个端点就能绕开」； ② --benefit 的每一条路线都至少含一个 *-ANAL（含 DESIGN.SRC 的最短选项 BC-ANAL + BC-TABLE）⇒ 不碰 *-ANAL 就拿不下任何一格 —— 唯一例外是 steel 路由 （这正是 DESIGN.CODE_CHECK 最小代价 = 1 的成因）。 ⇒ 下一个可执行动作仍是 POST.STEELCODECHECK ✅ R166（P174）已兑付 —— 那次授权测量做完了（判据 = 效果：0 行 → 2 行 ∧ 取值不等于手册示例） ⇒ 主指标 71 / 73，且我方可拿下项已全部收口（--attribution 的 ours 为空）。 细节 = registry/README.md §8.28 / §8.29 · docs/07 §16.1 R166。

✅ 已收口（R159，2026-10-15）：VIEW.RESULTGRAPHIC（挡 6） —— 纯 API 进结果视图（post）的路径 = POST /VIEW/CAPTURE 的 Argument.SET_MODE: "post" （粘性切换视图模式）+ TYPE_OF_DISPLAY..OPT_CHECK = true（结果图形的开关）； 结果图形也可由独立的 POST /VIEW/RESULTGRAPHIC（持久）配置。 ⚠️ R157 的「静默 200」成因 = 请求体缺 TYPE_OF_DISPLAY —— 不是原生空转。

✅ 已收口（R160，2026-10-15）：POST.TABLE（挡 1） —— 拦住 RESULT.ANALYSIS.SUMMARY 的不是原生，而是核心 spec_guard（R140）手里那份只有 2 个取值的 TABLE_TYPE 枚举（来自 help center 一篇文章）。枚举来源换成 登记表（194）∪ 手册声明（121）= 225（生成器 sync_table_type_enum.py）后， 真机实测：原生 POST /POST/TABLE {TABLE_TYPE: "DISPLACEMENTG"} ⇒ 200 · HEAD 9 列 · DATA 63 行；经 MCP Tool 契约（生产口径，无旁路）规范化结果 rows = 63；伪 token 仍零请求被拦（R140 的保护未丢）。 证据 = registry/live/post_table_enum_probe.json。

⚠️ R161（P168，2026-10-15）—— 主指标不变，但闸门的覆盖面变了： 普查发现 spec_guard 对 104 / 225 个带枚举的 Schema 文件一个字段都不检查 （盲区：文件根键就是包装键 ⇒ 下钻约定取不到）；核心 1 行改用 effective_schema() 后 盲区归零（104 → 0，零回归）。⚠️ 可见性恢复 ⇒ 窄枚举立刻会拦住合法调用 ⇒ 同批先补枚举（CURRENT_MODE 36 个取值 + 6 个变体 token）， 效果判据 PASSED。本节的主指标数字不受影响（68 / 71）—— 本批的价值在防事故。 细节 = registry/README.md §8.22 · docs/07 §16.1 R161； 证据 = registry/live/spec_enum_audit.json。

⚠️ 上表端点全是纯写端点（methods = POST）⇒ 不能只读收口，必须真机写 + 读回验效果。 ⚠️ 剩余 3 个被挡 Operation 的 13 个挡点端点分两组（逐条由 tests/test_midas_operation_availability_p165b.py::test_p165b_the_remaining_blockers_are_split_by_recovery_condition 钉住）： 6 个 *-ANAL = 实测崩溃族（NATIVE_CRASH_ENDPOINTS，R154 ⇒ MIDAS 侧修 wg_db.dll）； 7 个（6 个 *-TABLE + POST.STEELCODECHECK）= availability: untested （*-TABLE 要先有设计结果 ⇒ 依赖上面那 6 个；POST.STEELCODECHECK 我方可以收口， 且 R165 更正 R152：收口它真的解锁 DESIGN.CODE_CHECK —— +1，不是 0）。

⚠️ 上表「挡住」列是挡点个数**，不是解锁代价（R165 澄清）：因为 routes 是 替代路线，解锁 DESIGN.CODE_CHECK 只要 1 个端点、DESIGN.CONCRETE / DESIGN.SRC 各 2 个、全部 3 个只要 4 个。逐端点收益与最小代价由 python registry/tools/check_operation_availability.py --benefit 可执行复算 （⚠️ 该脚本 --check 会逐条断言收益映射与最小代价 —— 手写的映射必然漂）。

5.2 🟡 次指标：数据侧可达性上限与 Schema 覆盖

• 写路径模板：71 个端点 / 115 个 body（全部来源可复算：check_write_templates.py --check 全绿）。
• 11 个端点无 JSON Schema：DB.LCOM · DOC.CLOSEALL · DOC.EXIT · OPE.{CPCREATE,CPEXPORT,CPUPDATEMODEL,CPUPDATERESULT,PROJECTSTATUS,SECTPROP,STORYPROP} · VIEW.SELECT。 ⚠️ 其中 DB.LCOM / OPE.PROJECTSTATUS / OPE.SECTPROP / VIEW.SELECT 属无请求体端点 （docs/07 §16 R5 的裁决），不建 Schema 文件是如实留缺，不是遗漏。
• availability 分档：untested 的 102 个里，绝大多数在现有实例上结构性不可达 （-M1 家族 21 个 · unavailable_on: gen-local · CIVIL_DESIGNER 独有而 designer-cloud 宕机） ⇒ docs/07 §15.6.2 的 P4 已明确降级，不再消耗批次预算。

5.3 环境与安全

• DOC.CLOSEALL、DOC.EXIT 等不可回滚操作明确未测。
• 云端中继存在间歇性掉线（client does not exist），客户端已用 CLIENT_NOT_CONNECTED 区分。
• 已实测的静默失败形态（铁律 ⓪ 的由来）：原生返回 200 却什么都不做至少 7 次 （R128 ITEMS 外层键无效 · R145 DOC.NEW 忽略路径 · R146 DOC.SAVE 不写盘 · P160c 事故 A SAVEAS 体被拆 · P164-c 的 DELETE 响应体回显删除前状态 · R159 VIEW.RESULTGRAPHIC 缺 TYPE_OF_DISPLAY 时静默不画结果）。 ⇒ 判据必须是「再读的效果」，不能是状态码。

详见 docs/07 §15.6（指标层级）· docs/08 §3（批次状态）· registry/README.md（字段与口径）。