agentworkshop 0.7.71 → 0.8.1

package/.output/server/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agentworkshop-prod",
-  "version": "0.7.71",
+  "version": "0.8.1",
   "type": "module",
   "private": true,
   "dependencies": {

package/README-zh.md

@@ -28,7 +28,7 @@
 
 **[English](./README.md)** · **[在线文档](https://kingdol666.github.io/AgentWorkShop)** · **[版本发布](https://github.com/kingdol666/AgentWorkShop/releases)** · **[更新日志](./changelog.md)** · **[插件 API](./docs/plugins.md)** · **[SDK](./docs/sdk.md)**
 
-<sub><b>v0.7.71</b> · 14 个执行引擎 · 6 种现场协议（5 内置 + 串口插件）+ MES REST 集成（镜像与直连双路径）· 数据分析台账（产线级权限隔离）· 工艺参数优化器（过程模型 → AML → OSQP 求解 → 治理下发）· 工具调用参数/绑定预检 · 92 个宿主工具 · 126 个运行时设置项 · 双语文档（简体中文 / English）</sub>
+<sub><b>v0.8.1</b> · 14 个执行引擎 · 6 种现场协议（5 内置 + 串口插件）+ MES REST 集成（镜像与直连双路径）· 数据分析台账（产线级权限隔离）· 工艺参数优化器（过程模型 → AML → OSQP 求解 → 治理下发）· **本体服务 + AI 先行模型闭环**（本体 · 孪生 · 求解器 · AML 采纳）· 104 个宿主工具 · 126 个运行时设置项 · 双语文档（简体中文 / English）</sub>
 
 <br />
 
@@ -176,6 +176,17 @@ AgentWorkShop 起家于**多智能体软件工作坊**——Channel 内的编码
 | **生产化硬化（v0.7.58）** | 保写心跳生命周期根治——失败写不占位（心跳不再直发幻影指令值）、驱动/连接/产线变更即清值、停线自动挂起保写；mock 静默兜底封堵（未知协议显式报错，插件卸载不再假成功）；帧像素 sha256 完整性指纹 + 对象存储按天 GC（删前 DB 交叉校验防误删）；Timescale 按天 chunk + 列存压缩（TSL）；堆水位监控 + 崩溃/失联/水位三重自动重生；写保持窗与试验节拍落盘（重启不绕频控）；grant 运行时复核并入频道绑线（撤权即失活无死角）。 |
 | **Agent 自查工具** | `line_context`、`ops_log`、`recipe_log`、`recipe_versions`、`dcw_journal`——Agent 清楚自己操控的产线/产品/配方，谁做过什么，每个值怎么变。 |
 
+#### 模型闭环 —— AI 先行（本体 · 孪生 · 求解器 · AML，v0.8.0）
+
+| 能力 | 为何重要 |
+|---|---|
+| **面向控制的本体服务** | 10 类实体、**8 种封闭关系**（`influences / measures / actuates / hasPart / precedes / observedBy / constrainedBy / basedOn`），标注**三级证据**（`candidate_influence → observed_correlation → validated_control`）与**五态生命周期**（`proposed → reviewed → validated → approved_for_control`，第二人批准台账 + 单管理员审计豁免）。**编译器**产出四类工件——过程模型、ProblemIR 增量、场景契约补丁、控制守卫集——带**只收紧**不变量与逐规则 Rule Trace。运行守卫对状态未知 fail-closed；本体引用与求解器 ProblemIR 哈希**分域**，本体改动不会伪装成求解相关变更（漂移显式 409）。 |
+| **Agent 亲手创建虚拟模型** | 训练面频道上，Agent 用工具走完整创建链：`twin_scene_discover`（从**自己真实绑定**推断场景）→ `twin_scene_compile`（SceneContract 草稿）→ `twin_scene_freeze`（须人 `approved_by` + 确认令牌）→ `twin_physics_spec_draft / validate / compile`（声明式 Provider **候选**，绝不自动注册）→ `twin_snapshot_create`（服务端 `auto_daq` 采数，Agent 自报样本拒收）→ `twin_trial_run`（recommendation-only，`candidateExecuted=false`）。同一份物理骨架交由 AML `hybrid_residual` 训练校准（stage A 拟合 τ/增益）。 |
+| **模型进化 = 受治理的采纳** | 训练新模型（数据集 → 资格报告 → AML 作业 → 模型注册）只是半程。`optimizer_profile_propose` 让 **Agent 提议**把新工件采纳进求解 Profile：校验兼容性（模型 × 求解器矩阵，不兼容 422）并挂 HITL 卡。批准是**单一咽喉**：发布 v(n+1) + **重绑旧版本上的全部绑定**（revision+1，在飞求解 `BINDING_STALE` fail-closed），下一次 `optimizer_solve` 即用新模型；拒绝/超时零写。每轮留 `adopt_propose(agent)` + `adopt(user)` 审计行，旧版本保留可回退。 |
+| **人做修正，不只是点批准** | 管理者直接编辑本体草稿（乐观锁 `rev` + 活体校验），亲自走规则生命周期；版本台账给四段 diff（`entities / relations / rules / bindings`）。Profile 版本、孪生场景谱系（冻结场景 + Provider）、守卫决策在 `/ontology`、`/optimizer`、`/aml` 均可视——与 Agent 同源数据，不经 Agent 转述。 |
+| **可读模型 + 草稿自修复** | 三类模型都有可被 Agent 写入的人读元数据：本体文档/实体/规则描述、AML 模型 `label` + `description`（`aml_model_annotate`）、求解器 Profile `name` + `description`（经采纳携带）。本体草稿支持一键**自动修复**（`ontology_draft_autofix`、`POST /drafts/:id/autofix`）：补描述、量纲跟随单位、作用域回填、悬空引用与重复 id 修复、证据不足的硬规则状态回退；部分修复在乐观锁 + 审计下落库，`validated_control` 证据**永不伪造**。 |
+| **IDD × RAG × 本体 组合** | 同一会话内，Agent 可调 `ontology_scene_inspect / ontology_rule_explain`、经插件桥跑 IDD 诊断（CI 用 mock 快速筛查，生产用真实 LLM 意图）、再写 `analysis_save` 台账条目**同时引用**本体规则与诊断 run id——组合全程可审计。RAG `kb_agent` 入库属写类工具，必须过 HITL 审批；平台另提供**读桥**（`/api/plugins/rag-bridge/search`）直连 RAG 两阶段检索。 |
+
 #### 治理、配置与扩展
 
 | 能力 | 为何重要 |
@@ -191,7 +202,7 @@ AgentWorkShop 起家于**多智能体软件工作坊**——Channel 内的编码
 | **双模式优化闭环** | 专属频道模板把闭环**结构性拆开**：*aml-training* 频道拿建模面（数据集、作业、场景编译、物理 spec、建模任务——无产线写入、无 MPC），*aml-optimization* 频道拿执行面（快照、试验、门禁、MPC、贝叶斯寻优 `twin_bayes_optimize`、受治理微写 `optimization_explore`）——边训边优在结构上不可能。**探索**模式走治理链写入并做响应回读配对（每笔写入落 `optimization_explorations` 台账）；**生产**模式要求绑定过门禁的模型（`aml` 模式，实例化时给 `boundModelId`）。 |
 | **运行时可观测** | `GET /api/system/monitor` 把 Agent 团队内部暴露成数字：根队列深度、看门狗介入次数、Harness 会话复用、记忆 outbox 积压——每项都有对应的文档化回退开关，新机制可以不重新部署就关掉。 |
 | **产线操作单页（`/operations`）** | 一页看全对产线的每一次触碰：实时操作流水（REST 快照 + WS 推流）把写控、数采、建模、配方、回退、报警、产线、人工、系统动作归入**九类分类**，写控行渲染结构化 **前值 → 后值 diff 徽章**（失败标红），并直接从事件流推断**闭环阶段**（监视 → 探索·小步 → 推荐搜索 → 影子验证 → 生产）。同一数据面也供工作台控制台的「产线作业」面板使用。 |
-| **外部 MCP 网关** | `aw mcp` 启动零依赖的 **stdio MCP 服务**（38 个工具），自动发现运行中的实例（环境变量 → 锁文件 → 配置文件），把产线、配方（含 mark-good）、受治理 DCW 写入、工艺参数语义映射、数采查询、频道、团队供给、模型晋升、判卷/回退与插件管理暴露给任意 MCP 客户端——受 `mcp.enabled` 运行时设置门控，附 `--doctor` 与 `--print-config` 辅助指令。此外每个 Channel 成员实例都有**专属的全量工具 stdio 桥**（92 个宿主工具 + 插件工具，按该 Agent 的角色/绑定面编译视图；ETag/304 增量轮询 + `tools/list_changed`），codex / dsh / opencode 等引擎以 MCP 形态拿到与原生注入完全同链的治理（token 自证 → 五层复核）。 |
+| **外部 MCP 网关** | `aw mcp` 启动零依赖的 **stdio MCP 服务**（41 个工具），自动发现运行中的实例（环境变量 → 锁文件 → 配置文件），把产线、配方（含 mark-good）、受治理 DCW 写入、工艺参数语义映射、数采查询、频道、团队供给、模型晋升、判卷/回退与插件管理暴露给任意 MCP 客户端——受 `mcp.enabled` 运行时设置门控，附 `--doctor` 与 `--print-config` 辅助指令。此外每个 Channel 成员实例都有**专属的全量工具 stdio 桥**（104 个宿主工具 + 插件工具，按该 Agent 的角色/绑定面编译视图；ETag/304 增量轮询 + `tools/list_changed`），codex / dsh / opencode 等引擎以 MCP 形态拿到与原生注入完全同链的治理（token 自证 → 五层复核）。 |
 | **全量配置驱动运行时** | 全部运行旋钮（记忆预算、上下文压缩、回退护栏、保留策略、备份、日志级别、系统时区、MCP 开关…）在设置描述符注册表声明一次，优先级 **config.yml < runtime-settings < env**——**126 个设置项、19 组**（42 live / 84 restart），代码零硬编码默认。 |
 | **可配置系统时区** | 一个 `time.timeZone` 设置项（IANA 时区，live 热生效）统一驱动人读时间——日志、聊天、审计、Agent 记录与定时任务；机器时间轴（数采样本、`timestamptz`）仍保存绝对时间。 |
 | **可配置节拍** | 采样与查询的默认值/下限全部是 **live 设置**（`daq.sampling.*`、`daq.query.*`）：热重载、create/patch 时钳制，Agent 工具描述实时携带当前值。 |
@@ -394,7 +405,7 @@ aw update --check                      # 只报告，不安装
 npm install -g agentworkshop@latest    # 手动等效
 ```
 
-版本遵循 semver。每次 `aw start` 都会校验配置根，并把 `home` 之前的旧版 `data/` 布局迁移进来（以最新文件为准），因此数据可以跨版本存活。SQLite schema 迁移在服务端启动时执行。当前版本：**v0.7.71**——见[版本发布](https://github.com/kingdol666/AgentWorkShop/releases)。
+版本遵循 semver。每次 `aw start` 都会校验配置根，并把 `home` 之前的旧版 `data/` 布局迁移进来（以最新文件为准），因此数据可以跨版本存活。SQLite schema 迁移在服务端启动时执行。当前版本：**v0.8.1**——见[版本发布](https://github.com/kingdol666/AgentWorkShop/releases)。
 
 ### 第一次「Agent × 产线」会话（约 2 分钟）
 
@@ -443,7 +454,7 @@ aw config set daq.query.minBucketMs 500             # 查询下限（samples/产
 | `aw stop` | 依单实例锁终止运行中的 aw 服务实例 |
 | `aw config list · get · set · unset · reset` | 读写运行时设置（schema 校验 + 原子写盘） |
 | `aw plugin list · create · enable · disable` | 跨三种作用域管理插件：查看、脚手架（默认 project 作用域；`--global` 为 user 作用域）、启停（写状态文件，运行中的服务约 1 秒热重载） |
-| `aw mcp` | 工业 MCP stdio 服务（38 个工具，覆盖平台 REST：产线、配方、DCW 写入、参数映射、数采、频道、团队、模型晋升、插件）——自动发现运行实例；`--doctor` 一次讲清发现/健康/鉴权，`--print-config` 直出可粘贴的 MCP 客户端配置 |
+| `aw mcp` | 工业 MCP stdio 服务（41 个工具，覆盖平台 REST：产线、配方、DCW 写入、参数映射、数采、频道、团队、模型晋升、插件）——自动发现运行实例；`--doctor` 一次讲清发现/健康/鉴权，`--print-config` 直出可粘贴的 MCP 客户端配置 |
 | `aw home` | 查看/初始化配置根 `.AgentWorkShop` |
 | `aw init <dir>` | 脚手架一个可运行的新项目（含完整配置系统与 CLI） |
 | `aw register <路径\|URL\|npm:包名>` | 注册一条新指令——项目级或 `--global` 用户级 |
@@ -513,6 +524,17 @@ export async function run(argv, ctx) {
 - **双模式优化闭环**：随包附带两个频道模板——`chtpl-aml-training-default`（建模面：22 个工具，无产线写入、无 MPC）与 `chtpl-aml-optimization-default`（执行面：快照/试验/门禁/MPC/贝叶斯寻优，外加 `optimization_explore`——受治理微写，每笔设定值与响应回读配对落 `optimization_explorations` 台账）。两面按频道互斥注入；优化频道实例化时可选**探索**模式（治理小步，无需模型）或 **aml** 模式（必须给 `boundModelId`——过门禁的模型先绑定，执行面才解锁）。
 - **孪生 Provider 插件 SDK（热加载）**：工业场景的物理主干 / 场景包 / 目标 / 求解器经 `ctx.twin` 注册进 **Twin Provider Registry**（`registerPhysicsProvider` / `registerScenePack` / `registerObjectiveProfile` / `registerTrainingAdapter` / `registerSolverAdapter`，另有 `listProviders` / `getProviderHealth` / `resolveProvider` / `validateProvider` / `retireProvider` / `isRegistryAvailable`）。孪生工具按 `SceneContract.physicsProfileId` 解析 Provider（解析不到回退内置 `twin-injection-default`），**换场景不改工具与频道**；热重载按 **generation** 装载新代、排空旧代，试验与 MPC 持租约 ⇒ 在飞工作不被作废，`retireProvider` 等引用归零才下线。系统自带注塑 Provider 走的正是这套外部契约（`server/plugins-builtin/twin-injection-default/`），装法与其它插件同址、停用或热重载无需重启。清单字段与可运行示例见 [`docs/plugins.md`](./docs/plugins.md)「混合孪生 Provider 插件」，SDK 面见 [`docs/sdk.md`](./docs/sdk.md) §4.10。
 
+### 本体与 AI 先行模型闭环（v0.8.0）
+
+第三层建模资产——让整个闭环**自描述**。
+
+- **创作面**：`POST /api/workshop/ontology` 开草稿（乐观锁 `rev`），整份文档（实体/关系/规则/语义绑定）双重校验——schema/量纲 + **对真实 DAQ/DCW/配方对象的活体绑定校验**。规则走五态生命周期（`proposed → reviewed → validated → approved_for_control → deprecated`），控制级批准需要批准单（第二人；单管理员部署有审计留痕的 solo 豁免），`publish` 拒绝未到控制级批准的硬约束。版本不可变——发布即新版本，`GET /versions/{id}/compare` 给四段 diff；`/ontology` 六 tab 渲染图、编译产物、Rule Trace、绑定与版本台账。十件 Agent 工具覆盖同一面（`ontology_scene_inspect / node_neighbors / draft_create / draft_validate / draft_update / rule_explain / compile_preview / publish_propose / version_compare / draft_autofix`），外部 MCP 服务镜像其中四件只读工具。`/ontology` 的图 tab 渲染可交互节点-边视图（自绘 SVG，MV/CV/结构分道），点击节点抽屉可加载直接与 2 跳邻接（草稿维度子图 API）。
+- **编译不变量**：每版本四类产物——过程模型增量（特征候选、τ = D/v 时滞先验、单调性）、ProblemIR 增量、场景契约补丁、控制守卫集；**只收紧不放宽**、PLC 层隔离（联锁编译为 `PLC_LAYER_REQUIRED` 决策而非软件守卫）、不支持形式编译期拒绝（非线性 QP/线性耦合）、**哈希域分离**：`ontologyRefs` 进 Profile 内容哈希但**永不进**求解器 `ProblemIR` 哈希，本体改动表现为 `409 ONTOLOGY_PACK_DRIFTED` 而不是伪造的 IR 变更。
+- **运行时真正生效的只有四处**：下发时的**节点意图守卫**（`evaluateOntologyGuardsForNodes` → `409 ONTOLOGY_GUARD_BLOCKED`，状态未知 fail-closed）、供数据集/训练规划消费的**训练先验派生**、孪生消费的**场景/守卫补丁**、以及 Profile `ontologyRefs` 钉住的**已发布版本谱系校验**（下发时复核）。其余都是可审阅的元数据。
+- **采纳环——模型进化而不只是参数调优**：`optimizer_profile_propose` 打通「训练 → 求解」最后一公里：Agent 复制最新**已发布** Profile、换上新模型工件、生成 v(n+1) 草稿并挂 HITL 卡（`optimizer-profile:<id>@<版本>`）。批准与裁决两入口同路由——批准 ⇒ 发布草稿（冻结哈希）+ **自动重绑基线版本上的全部绑定**（revision+1，在飞求解按 `BINDING_STALE` fail-closed）+ 审计 `optimizer.profile.adopt`；拒绝/超时 ⇒ 零写。兼容性（工件种类 × 求解器族，D21）在提议时校验，Agent 只能在自身绑定面内提议。真机连续两轮进化（v1 → v2 → v3）验证，每轮后 `optimizer_solve` 均在新工件上 optimal。
+- **实测**：531 单测 · 44 服务层本体断言 · **72/72** 本体真机 e2e · **46/46** 模型闭环真机 e2e（孪生创建链 + 两轮采纳 + 零设备写入）· 14 条 MCP 断言。报告：[`docs/audit/2026-10-24-ontology-acceptance.md`](./docs/audit/2026-10-24-ontology-acceptance.md)、[`docs/audit/2026-10-24-ontology-live-report.md`](./docs/audit/2026-10-24-ontology-live-report.md)、[`docs/audit/2026-10-24-model-loop-acceptance.md`](./docs/audit/2026-10-24-model-loop-acceptance.md)。规范：[`docs/plans/2026-10-24-ontology-service-plan.md`](./docs/plans/2026-10-24-ontology-service-plan.md)、[`docs/plans/2026-10-24-closed-loop-acceptance.md`](./docs/plans/2026-10-24-closed-loop-acceptance.md)。
+- **边界（显式）**：ProblemIr 增量已编译但尚未作为求解约束消费；执行结果回写推荐台账的 outcome 回路、逐回合本体 prompt 注入属下一轮；RDF/OWL/SHACL 导出未交付。
+
 ---
 
 ## 使用说明
@@ -653,7 +675,7 @@ AgentWorkShop/
 │   ├── mcp/                    # MCP 服务（25 个工具，进程内 workshop 面）
 │   ├── plugins-builtin/        # 随包发布的插件（serial-bridge · rag-bridge · diag-bridge · twin-injection-default）
 │   └── plugins/                # 运行时装配（单例）
-├── mcp/                        # aw mcp —— 零依赖 stdio MCP 网关（38 个工具，实例自动发现）
+├── mcp/                        # aw mcp —— 零依赖 stdio MCP 网关（41 个工具，实例自动发现）
 ├── sdk/                        # agentworkshop/sdk——插件上下文、钩子总线、REST 客户端、浏览器 SDK
 ├── tui/                        # 终端工作台（aw tui）
 ├── shared/
@@ -870,7 +892,7 @@ Informatics 匿名评审稿,IEEEtran 双栏 10 页)。源文件、编译稿与
 | 任意场景混合孪生建模闭环：场景发现 → 编译 → 冻结 → 物理 spec 起草/校验/编译 → 参考训练器作业（物理校准 + 残差集成 + conformal UQ）、模型驱动试验、持续校准 worker | 已交付 |
 | 双模式优化闭环：`aml-training` / `aml-optimization` 专属频道模板、互斥工具面、探索 ↔ 生产双模式、带回读配对的治理微写 | 已交付 |
 | 产线操作流水：`/operations` 单页 + 工作台控制台面板，九类操作时间线、结构化写控 diff、闭环阶段推断 | 已交付 |
-| 外部 MCP 网关：`aw mcp` stdio 服务（38 个工具）、实例自动发现、`mcp.enabled` 运行时门控 | 已交付 |
+| 外部 MCP 网关：`aw mcp` stdio 服务（41 个工具）、实例自动发现、`mcp.enabled` 运行时门控 | 已交付 |
 | 可配置系统时区（`time.timeZone`，live 热生效）+ 配方参数级单步限幅 `stepLimit` + 配方 `description` 元字段 | 已交付 |
 | 生产硬化：TLS、MQTT 鉴权、OPC UA 签名+加密缺省、结构化审计日志 | 规划中 |
 | 边缘部署形态：独立 edge-agent + 中心 broker | 规划中 |

package/README.md

@@ -28,7 +28,7 @@
 
 **[简体中文](./README-zh.md)** · **[Documentation](https://kingdol666.github.io/AgentWorkShop)** · **[Releases](https://github.com/kingdol666/AgentWorkShop/releases)** · **[Changelog](./changelog.md)** · **[Plugin API](./docs/plugins.md)** · **[SDK](./docs/sdk.md)**
 
-<sub><b>v0.7.71</b> · 14 engines · 6 field protocols (5 built-in + serial plugin) + MES REST integration (mirror & live) · data-analysis ledger with line-scoped permissions · process optimizer (process model → AML → OSQP solver → governed dispatch) · per-call tool parameter/binding preflight · 92 host tools · 126 runtime settings · bilingual docs (简体中文 / English)</sub>
+<sub><b>v0.8.1</b> · 14 engines · 6 field protocols (5 built-in + serial plugin) + MES REST integration (mirror & live) · data-analysis ledger with line-scoped permissions · process optimizer (process model → AML → OSQP solver → governed dispatch) · **ontology service + AI-first model loop** (ontology · twin · solver · AML adoption) · 104 host tools · 126 runtime settings · bilingual docs (简体中文 / English)</sub>
 
 <br />
 
@@ -177,6 +177,17 @@ Recorded against a running instance: real DAQ history, real write control, real
 | **Production hardening (v0.7.58)** | Hold-heartbeat lifecycle fixed — failed writes never occupy the setpoint (no phantom re-dispatch), driver/connection/line changes clear the value, line stop suspends hold automatically; silent mock fallback blocked (unknown protocols fail loudly, plugin unload can't fake success); frame pixel sha256 fingerprints + day-directory object GC (DB cross-check before delete); Timescale daily chunks + columnstore compression (TSL); heap-watermark watch with crash/liveness/watermark auto-respawn; write-hold windows & trial cadence persisted across restarts; runtime grant re-checks include the channel-bound line (revocation takes effect everywhere). |
 | **Agent self-audit tools** | `line_context`, `ops_log`, `recipe_log`, `recipe_versions`, `dcw_journal` — agents see exactly which line/product/recipe they control, who did what, and how every value changed. |
 
+#### Model loop — AI-first (ontology · twin · solver · AML, v0.8.1)
+
+| Capability | Why it matters |
+|---|---|
+| **Control-oriented ontology service** | Entities (10 kinds) and **eight closed relation kinds** (`influences / measures / actuates / hasPart / precedes / observedBy / constrainedBy / basedOn`) annotated with **three evidence levels** (`candidate_influence → observed_correlation → validated_control`) under a **five-state lifecycle** (`proposed → reviewed → validated → approved_for_control`, second-person approval ledger, solo-operator exemption audited). The **compiler** emits four artifacts — process model, ProblemIR delta, scene-contract patch, control-guard set — under a **tighten-only** invariant, with a row-level Rule Trace per rule. Runtime guards fail closed on unknown state; ontology refs live in a **hash domain separate from the solver's ProblemIR hash**, so ontology edits never masquerade as solver-relevant changes (drift is an explicit 409). |
+| **Agents build the virtual model** | On a training-face channel the agent runs the whole creation chain with tools: `twin_scene_discover` (scene inferred from *its real node bindings*) → `twin_scene_compile` (SceneContract draft) → `twin_scene_freeze` (needs a human `approved_by` + confirmation token) → `twin_physics_spec_draft / validate / compile` (declarative provider **candidate**, never auto-registered) → `twin_snapshot_create` (server-side `auto_daq` sampling; agent-supplied samples rejected) → `twin_trial_run` (recommendation-only, `candidateExecuted=false`). The same generated physics skeleton feeds AML `hybrid_residual` calibration (τ/gain fitted in stage A). |
+| **Model evolution is governed adoption** | Training a new model (dataset → eligibility report → AML job → registry) is only half the loop. `optimizer_profile_propose` lets the **agent propose adopting** that artifact into the solver profile: it validates compatibility (model × solver matrix, 422 on mismatch) and opens a HITL card. Approval is the **single throat** that publishes profile v(n+1) and **rebinds every agent** on the old version (revision+1; in-flight solves fail closed with `BINDING_STALE`), so the next `optimizer_solve` runs on the new model. Reject/timeout = zero writes. Every round leaves `adopt_propose(agent)` + `adopt(user)` audit rows; old versions remain for rollback. |
+| **Humans correct, not just approve** | Managers edit the ontology draft directly (optimistic-lock `rev`, live schema + binding validation) and walk the rule lifecycle themselves; the version ledger shows a four-part diff (`entities / relations / rules / bindings`). Profile versions, twin scene lineage (frozen scene + provider) and guard decisions are visible on `/ontology`, `/optimizer` and `/aml` — the same data the agent sees, without agent mediation. |
+| **Readable models & self-repairing drafts** | All three model kinds carry human-readable metadata the agent can write: ontology document/entity/rule descriptions, AML model `label` + `description` (`aml_model_annotate`), and solver-profile `name` + `description` (carried through adoption). Ontology drafts get a one-click **auto-fix** (`ontology_draft_autofix`, `POST /drafts/:id/autofix`): descriptions, unit-following dimensions, scope backfill, dangling-reference and duplicate-id repair, and a hard-rule status downgrade when evidence is insufficient — partial fixes persist under optimistic lock + audit, and `validated_control` evidence is **never fabricated**. |
+| **IDD × RAG × ontology composition** | In one session an agent can call `ontology_scene_inspect` / `ontology_rule_explain`, run IDD diagnosis through the plugin bridge (mock quick-screen in CI, real LLM intents in production), and write an `analysis_save` ledger entry citing **both** the ontology rule and the diagnosis run id — the composition is auditable end-to-end. RAG `kb_agent` ingestion sits behind a HITL approval (write-class tool), while the platform exposes a **read bridge** (`/api/plugins/rag-bridge/search`) into the RAG service's two-stage retrieval. |
+
 #### Governance, configuration & extension
 
 | Capability | Why it matters |
@@ -192,7 +203,7 @@ Recorded against a running instance: real DAQ history, real write control, real
 | **Two-mode optimization loop** | Dedicated channel templates split the loop **structurally**: an *aml-training* channel gets the modeling face (datasets, jobs, scene compile, physics specs, training plans — no plant writes, no MPC) and an *aml-optimization* channel gets the acting face (snapshots, trials, gate, MPC, Bayesian search `twin_bayes_optimize`, governed micro-writes `optimization_explore`) — training-while-optimizing is impossible by construction. **Exploration** mode writes through the governed chain with response read-back pairing (every write lands in an `optimization_explorations` ledger); **production** mode requires a bound model that cleared the twin gates (`aml` mode, `boundModelId` at instantiate time). |
 | **Runtime observability** | `GET /api/system/monitor` exposes the agent-team internals as numbers: root queue depth, watchdog interventions, harness session reuse, pending memory outbox — each guarded by a documented rollback switch, so new machinery can be turned off without a redeploy. |
 | **Line operations feed (`/operations`)** | One page for every touch on the plant: a live operation feed (REST snapshot + WS stream) classifies writes, DAQ, AML, recipe, rollback, alarm, line, manual and system actions into **nine categories**, renders structured **before → after diff badges** on write rows (failures marked red), and infers the **closed-loop phase** (monitor → exploration · small-step → recommendation search → shadow verification → production) straight from the event stream. The same feed powers a line-operations panel inside the workshop console. |
-| **External MCP gateway** | `aw mcp` starts a zero-dependency **stdio MCP server** (38 tools) that discovers a running instance automatically (env → lock file → config file) and exposes lines, recipes (incl. mark-good), governed DCW writes, semantic parameter mapping, DAQ queries, channels, team provisioning, model promotion, judge/rollback and plugin management to any MCP client — gated by the `mcp.enabled` runtime setting, with `--doctor` and `--print-config` helpers. Additionally, **every channel member instance gets a dedicated full-tool stdio bridge** (92 host tools + plugin tools, compiled per agent from its role/binding face; ETag/304 incremental polling + `tools/list_changed`) so engines like codex / dsh / opencode consume MCP with the exact same governance chain as native injection (token self-assertion → five-layer re-verification). |
+| **External MCP gateway** | `aw mcp` starts a zero-dependency **stdio MCP server** (41 tools) that discovers a running instance automatically (env → lock file → config file) and exposes lines, recipes (incl. mark-good), governed DCW writes, semantic parameter mapping, DAQ queries, channels, team provisioning, model promotion, judge/rollback and plugin management to any MCP client — gated by the `mcp.enabled` runtime setting, with `--doctor` and `--print-config` helpers. Additionally, **every channel member instance gets a dedicated full-tool stdio bridge** (104 host tools + plugin tools, compiled per agent from its role/binding face; ETag/304 incremental polling + `tools/list_changed`) so engines like codex / dsh / opencode consume MCP with the exact same governance chain as native injection (token self-assertion → five-layer re-verification). |
 | **Fully config-driven runtime** | Every runtime knob (memory budgets, compaction, rollback guardrails, retention, backups, log level, system timezone, MCP gate…) is declared once in the settings descriptor registry with precedence **config.yml < runtime-settings < env** — **126 settings across 19 groups** (42 live / 84 restart), no hardcoded defaults in code. |
 | **Configurable system timezone** | One `time.timeZone` setting (IANA id, live-applied) drives human-facing timestamps — logs, chat, audit, agent records and schedules — through a single formatter; machine timelines (DAQ samples, `timestamptz`) stay absolute. |
 | **Configurable cadences** | Sampling and query defaults/floors are **live settings** (`daq.sampling.*`, `daq.query.*`): hot-reloaded, clamped on node create/patch, and agent tool descriptions always carry the current values. |
@@ -385,7 +396,7 @@ aw update --check                      # only report; nothing is installed
 npm install -g agentworkshop@latest    # manual equivalent
 ```
 
-Releases follow semver. `aw start` verifies the config root on every launch and migrates the legacy pre-`home` `data/` layout into it (newest file wins), so data survives upgrades. SQLite schema migrations run server-side at boot. Current version: **v0.7.71** — see [Releases](https://github.com/kingdol666/AgentWorkShop/releases).
+Releases follow semver. `aw start` verifies the config root on every launch and migrates the legacy pre-`home` `data/` layout into it (newest file wins), so data survives upgrades. SQLite schema migrations run server-side at boot. Current version: **v0.8.1** — see [Releases](https://github.com/kingdol666/AgentWorkShop/releases).
 
 ### Your first agent × line session (~2 minutes)
 
@@ -504,6 +515,17 @@ The modeling half of the loop: `/aml` builds **datasets** out of tagged telemetr
 - **Two-mode optimization loop**: `aw` ships two channel templates — `chtpl-aml-training-default` (modeling face: 22 tools, no plant writes, no MPC) and `chtpl-aml-optimization-default` (acting face: snapshot/trial/gate/MPC/Bayesian search plus `optimization_explore`, the governed micro-write that pairs every setpoint with its response read-back in an `optimization_explorations` ledger). The faces are mutually exclusive per channel; optimization channels instantiate either in **exploration** mode (governed small steps, no model required) or **aml** mode (`boundModelId` required — a gate-cleared model must be bound before the acting face unlocks).
 - **Twin provider plugin SDK (hot-loaded)**: an industrial scene's physics core / scene packs / objectives / solvers register through `ctx.twin` into the **Twin Provider Registry** (`registerPhysicsProvider` / `registerScenePack` / `registerObjectiveProfile` / `registerTrainingAdapter` / `registerSolverAdapter`, plus `listProviders` / `getProviderHealth` / `resolveProvider` / `validateProvider` / `retireProvider` / `isRegistryAvailable`). Twin tools resolve providers via `SceneContract.physicsProfileId` (falling back to the bundled `twin-injection-default`), so **swapping scenes changes neither tools nor channels**; a hot reload stages a new **generation** and drains the old one while trials and MPC hold leases, so in-flight work is never invalidated and `retireProvider` only unloads at zero references. The bundled injection provider ships through that same external contract (`server/plugins-builtin/twin-injection-default/`), and plugins live in the usual scopes with no restart for disable/reload. Field tables and a runnable example: [`docs/plugins.md`](./docs/plugins.md) → "Hybrid-twin provider plugins"; SDK surface: [`docs/sdk.md`](./docs/sdk.md) §4.10.
 
+### Ontology & the AI-first model loop (v0.8.0)
+
+The third modeling layer — and the one that makes the loop *self-describing*.
+
+- **Authoring surface.** `POST /api/workshop/ontology` opens a draft (optimistic-lock `rev`); the full document (entities, relations, rules, semantic bindings) is validated twice — schema/dimension checks plus **live binding checks against real DAQ/DCW/recipe objects**. Rules then walk a five-state lifecycle (`proposed → reviewed → validated → approved_for_control → deprecated`); control approval needs an approval-ledger entry (second person; single-admin deployments get an audited solo-operator exemption) and `publish` refuses hard rules that never reached it. Versions are immutable — publishing creates a new version, `GET /versions/{id}/compare` returns a four-part diff, and `/ontology` renders graph, compile artifacts, Rule Trace, bindings and version ledger across six tabs. Ten agent tools cover the same surface (`ontology_scene_inspect / node_neighbors / draft_create / draft_validate / draft_update / rule_explain / compile_preview / publish_propose / version_compare / draft_autofix`); four read-only ones are mirrored on the external MCP server. The `/ontology` graph tab renders an interactive node-edge view (self-drawn SVG, MV/CV/structural lanes) with a node drawer that loads direct and 2-hop neighbourhoods from the draft-scoped subgraph API.
+- **Compilation with invariants.** Four artifacts per version — process-model delta (feature candidates, τ = D/v delay priors, monotonicity), ProblemIR delta, scene-contract patch, control-guard set — under **tighten-only** (rules narrow, never widen), PLC-layer separation (interlocks compile to `PLC_LAYER_REQUIRED` traces, not software guards), compile-time rejection of unsupported forms (nonlinear QP, linear coupling), and **hash-domain separation**: `ontologyRefs` are part of the profile content hash but never of the solver's `ProblemIR` hash, so ontology edits surface as `409 ONTOLOGY_PACK_DRIFTED` instead of a bogus IR change.
+- **Runtime effect.** Exactly four things execute: dispatch-time **node-intent guards** (`evaluateOntologyGuardsForNodes` → `409 ONTOLOGY_GUARD_BLOCKED`, fail-closed on unknown state), **training-prior derivation** for dataset/planning, the **scene/guard patch** consumed by the twin, and the **published-version lineage check** pinned in the profile's `ontologyRefs` (re-checked at dispatch). Everything else is reviewable metadata.
+- **The adoption loop — model evolution, not parameter tuning.** `optimizer_profile_propose` closes training → solving: the agent copies the latest *published* profile, swaps in a newly trained model artifact, creates draft v(n+1) and opens a HITL card (`optimizer-profile:<id>@<version>`). Both approval entries route to one service — approve ⇒ publish the draft (frozen hash) + **rebind every binding on the base version** (revision+1; in-flight solves fail closed with `BINDING_STALE`) + audit `optimizer.profile.adopt`; reject/timeout ⇒ zero writes. Compatibility (artifact kind × solver family, D21) is enforced at proposal time, and an agent can only propose inside its own binding face. Verified live in two consecutive evolution rounds (v1 → v2 → v3), each followed by an optimal `optimizer_solve` on the new artifact.
+- **Verified.** 531 unit tests · 44 service-level ontology assertions · **72/72** ontology live e2e · **46/46** model-loop live e2e (twin creation chain + two adoption rounds + zero device writes) · 14 MCP assertions. Reports: [`docs/audit/2026-10-24-ontology-acceptance.md`](./docs/audit/2026-10-24-ontology-acceptance.md), [`docs/audit/2026-10-24-ontology-live-report.md`](./docs/audit/2026-10-24-ontology-live-report.md), [`docs/audit/2026-10-24-model-loop-acceptance.md`](./docs/audit/2026-10-24-model-loop-acceptance.md). Specs: [`docs/plans/2026-10-24-ontology-service-plan.md`](./docs/plans/2026-10-24-ontology-service-plan.md), [`docs/plans/2026-10-24-closed-loop-acceptance.md`](./docs/plans/2026-10-24-closed-loop-acceptance.md).
+- **Boundaries (explicit).** ProblemIR-delta bounds are compiled but not yet consumed as solve constraints; the outcome write-back loop (execution result → recommendation ledger) and per-turn ontology prompt injection remain next-round items; RDF/OWL/SHACL export is not shipped.
+
 ---
 
 ## Usage
@@ -896,7 +918,7 @@ Re-run the paper pipeline locally: set `AW_BENCH_MODE=1` and follow
 | Any-scene hybrid-twin modeling loop: scene discover → compile → freeze → physics-spec draft/validate/compile → reference-trainer job (physics calibration + residual ensemble + conformal UQ), model-backed trials, continuous-calibration worker | Shipped |
 | Two-mode optimization loop: dedicated `aml-training` / `aml-optimization` channel templates, mutually exclusive tool faces, exploration ↔ production modes with governed read-back-paired micro-writes | Shipped |
 | Line operations feed: `/operations` page + workshop-console panel, nine-category operation timeline, structured write diffs, closed-loop phase inference | Shipped |
-| External MCP gateway: `aw mcp` stdio server (38 tools), instance auto-discovery, `mcp.enabled` runtime gate | Shipped |
+| External MCP gateway: `aw mcp` stdio server (41 tools), instance auto-discovery, `mcp.enabled` runtime gate | Shipped |
 | Configurable system timezone (`time.timeZone`, live) + recipe `stepLimit` per-parameter single-step bound + recipe `description` metadata | Shipped |
 | Production hardening: TLS, MQTT auth, OPC UA sign+encrypt defaults, structured audit log | Planned |
 | Edge deployment shape: standalone edge-agent + central broker | Planned |

package/app/components/AppSidebar.vue

@@ -49,6 +49,7 @@ const menuGroups = computed<MenuGroup[]>(() => [
       { key: '/studio', icon: 'i-tabler-chart-dots', label: t('menu.studio'), motion: 'im-pop' },
       { key: '/aml', icon: 'i-tabler-flask', label: t('menu.aml'), motion: 'im-pop' },
       { key: '/optimizer', icon: 'i-tabler-math-function', label: t('menu.optimizer'), motion: 'im-pop' },
+      { key: '/ontology', icon: 'i-tabler-sitemap', label: t('menu.ontology'), motion: 'im-pop' },
     ],
   },
   {

package/app/components/aml/AmlModelsTable.vue

@@ -79,6 +79,11 @@ const { fmtTime, fmtNum, shortId } = useAmlFormat()
               :title="m.description || m.label"
             >
               <span class="label-text">{{ m.label || '--' }}</span>
+              <span
+                v-if="m.description"
+                class="desc-text"
+                :title="m.description"
+              >{{ m.description }}</span>
             </td>
             <td class="mono dim">
               {{ shortId(m.productId) }}

package/app/components/ontology/OntologyGraph.vue

@@ -0,0 +1,356 @@
+<script setup lang="ts">
+/**
+ * 本体节点-边可视化(自绘 SVG,零第三方图库)。
+ *
+ * 布局纪律:不做物理模拟 —— 按编译器口径分三道(与 compiler.ts 的 roleBucket 同源):
+ *   MV = control / disturbance / feature
+ *   CV = target / observation
+ *   结构/状态 = state / guard / 无 role
+ * 同道具内按文档顺序均布,因此布局确定性、可被 e2e 用 bounding box 断言。
+ */
+import { computed, useId } from 'vue'
+import type { OntologyEntityDto, OntologyRelationDto } from '@/app/pages/ontology/types'
+
+const props = defineProps<{
+  entities: OntologyEntityDto[]
+  relations: OntologyRelationDto[]
+  selectedKey?: string
+}>()
+
+const emit = defineEmits<{ select: [key: string] }>()
+
+const { t } = useI18n()
+const uid = useId().replace(/[^a-zA-Z0-9_-]/g, '')
+
+const WIDTH = 980
+const NODE_R = 7
+const LANE_X = [150, 490, 830]
+
+type Lane = 0 | 1 | 2
+const LANE_OF_ROLE: Record<string, Lane> = {
+  control: 0,
+  disturbance: 0,
+  feature: 0,
+  target: 1,
+  observation: 1,
+  state: 2,
+  guard: 2,
+}
+
+function laneOf(entity: OntologyEntityDto): Lane {
+  return LANE_OF_ROLE[entity.role ?? ''] ?? 2
+}
+
+function shortKey(key: string): string {
+  const tail = key.includes('.') ? key.slice(key.indexOf('.') + 1) : key
+  return tail.length > 18 ? `${tail.slice(0, 17)}…` : tail
+}
+
+const laneLabels = computed(() => [
+  t('ontology.graph.lane.mv'),
+  t('ontology.graph.lane.cv'),
+  t('ontology.graph.lane.structural'),
+])
+
+const laneMembers = computed<OntologyEntityDto[][]>(() => {
+  const lanes: OntologyEntityDto[][] = [[], [], []]
+  for (const entity of props.entities) lanes[laneOf(entity)]!.push(entity)
+  return lanes
+})
+
+const height = computed(() => {
+  const maxCount = Math.max(1, ...laneMembers.value.map(list => list.length))
+  return Math.max(360, Math.min(760, maxCount * 46 + 96))
+})
+
+const positions = computed(() => {
+  const map = new Map<string, { x: number, y: number, lane: Lane }>()
+  laneMembers.value.forEach((members, lane) => {
+    const count = members.length
+    members.forEach((entity, index) => {
+      const span = height.value - 96
+      const y = count === 1 ? 48 + span / 2 : 48 + (span * index) / (count - 1)
+      map.set(entity.key, { x: LANE_X[lane]!, y, lane: lane as Lane })
+    })
+  })
+  return map
+})
+
+const entityKeys = computed(() => new Set(props.entities.map(e => e.key)))
+
+const visibleRelations = computed(() => props.relations.filter(
+  relation => entityKeys.value.has(relation.srcKey) && entityKeys.value.has(relation.dstKey),
+))
+
+const edgePaths = computed(() => visibleRelations.value.flatMap((relation, index) => {
+  const from = positions.value.get(relation.srcKey)
+  const to = positions.value.get(relation.dstKey)
+  if (!from || !to) return []
+  const tier = relation.properties?.evidenceTier ?? 'candidate_influence'
+  const sameLane = from.lane === to.lane
+  const curve = sameLane ? 46 + index * 6 : 0
+  const x1 = from.x + (to.x >= from.x ? NODE_R : -NODE_R)
+  const x2 = to.x + (to.x >= from.x ? -NODE_R : NODE_R)
+  const cx1 = sameLane ? from.x + curve : (x1 + x2) / 2
+  const cx2 = sameLane ? to.x + curve : (x1 + x2) / 2
+  return [{
+    id: relation.id,
+    kind: relation.kind,
+    tier,
+    d: `M ${x1} ${from.y} C ${cx1} ${from.y}, ${cx2} ${to.y}, ${x2} ${to.y}`,
+    labelX: (x1 + x2) / 2,
+    labelY: (from.y + to.y) / 2,
+    src: relation.srcKey,
+    dst: relation.dstKey,
+  }]
+}))
+
+const tierClass = (tier: string): string => `tier-${tier.replace(/_/g, '-')}`
+
+function onSelect(key: string): void {
+  emit('select', key)
+}
+</script>
+
+<template>
+  <div
+    class="ontology-graph"
+    data-testid="ontology-graph"
+  >
+    <svg
+      class="graph-svg"
+      :viewBox="`0 0 ${WIDTH} ${height}`"
+      :style="{ height: `${height}px` }"
+      role="img"
+      :aria-label="t('ontology.graph.aria')"
+    >
+      <defs>
+        <marker
+          :id="`ont-arrow-${uid}`"
+          viewBox="0 0 10 10"
+          refX="9"
+          refY="5"
+          markerWidth="6"
+          markerHeight="6"
+          orient="auto-start-reverse"
+        >
+          <path
+            d="M 0 0 L 10 5 L 0 10 z"
+            class="edge-arrow"
+          />
+        </marker>
+      </defs>
+
+      <g
+        v-for="(label, index) in laneLabels"
+        :key="label"
+        class="lane"
+      >
+        <line
+          :x1="LANE_X[index]"
+          y1="30"
+          :x2="LANE_X[index]"
+          :y2="height - 30"
+          class="lane-line"
+        />
+        <text
+          :x="LANE_X[index]"
+          y="18"
+          class="lane-label"
+        >{{ label }}</text>
+      </g>
+
+      <g
+        v-for="edge in edgePaths"
+        :key="edge.id"
+        :data-edge-id="edge.id"
+        :data-src="edge.src"
+        :data-dst="edge.dst"
+        :data-kind="edge.kind"
+        :data-tier="edge.tier"
+        class="edge"
+        :class="tierClass(edge.tier)"
+      >
+        <title>{{ edge.id }} · {{ edge.kind }}</title>
+        <path
+          :d="edge.d"
+          class="edge-line"
+          :marker-end="`url(#ont-arrow-${uid})`"
+        />
+      </g>
+
+      <g
+        v-for="entity in entities"
+        :key="entity.key"
+        :data-node-key="entity.key"
+        :data-role="entity.role ?? ''"
+        :data-kind="entity.kind"
+        class="node"
+        :class="{ selected: entity.key === selectedKey }"
+        role="button"
+        tabindex="0"
+        :aria-label="`${entity.key} · ${entity.name}`"
+        @click="onSelect(entity.key)"
+        @keydown.enter="onSelect(entity.key)"
+        @keydown.space.prevent="onSelect(entity.key)"
+      >
+        <title>{{ entity.key }} · {{ entity.name }}{{ entity.unit ? ` (${entity.unit})` : '' }}</title>
+        <circle
+          v-if="entity.key === selectedKey"
+          :cx="positions.get(entity.key)?.x ?? 0"
+          :cy="positions.get(entity.key)?.y ?? 0"
+          :r="NODE_R + 5"
+          class="node-halo"
+          data-role="selection-halo"
+        />
+        <circle
+          :cx="positions.get(entity.key)?.x ?? 0"
+          :cy="positions.get(entity.key)?.y ?? 0"
+          :r="NODE_R"
+          class="node-dot"
+        />
+        <text
+          :x="(positions.get(entity.key)?.x ?? 0) + NODE_R + 6"
+          :y="(positions.get(entity.key)?.y ?? 0) + 4"
+          class="node-label"
+        >{{ shortKey(entity.key) }}</text>
+      </g>
+    </svg>
+
+    <div class="legend">
+      <span class="legend-item candidate_influence">{{ t('ontology.graph.tier.candidate') }}</span>
+      <span class="legend-item observed_correlation">{{ t('ontology.graph.tier.observed') }}</span>
+      <span class="legend-item validated_control">{{ t('ontology.graph.tier.validated') }}</span>
+    </div>
+  </div>
+</template>
+
+<style scoped>
+.ontology-graph {
+  border: 1px solid var(--line);
+  border-radius: 10px;
+  padding: 8px 10px 4px;
+  background: var(--paper-raised);
+  overflow-x: auto;
+}
+
+.graph-svg {
+  width: 100%;
+  min-width: 720px;
+  display: block;
+}
+
+.lane-line {
+  stroke: var(--line);
+  stroke-width: 1;
+  stroke-dasharray: 2 6;
+}
+
+.lane-label {
+  fill: var(--ink-faint);
+  font-size: 11px;
+  text-anchor: middle;
+  letter-spacing: 0.08em;
+  text-transform: uppercase;
+}
+
+.edge-line {
+  fill: none;
+  stroke-width: 1.4;
+}
+
+.edge-arrow {
+  fill: var(--ink-faint);
+}
+
+.edge.tier-candidate-influence .edge-line {
+  stroke: var(--ink-faint);
+  stroke-dasharray: 3 4;
+  opacity: 0.7;
+}
+
+.edge.tier-observed-correlation .edge-line {
+  stroke: var(--tone-info-dot);
+}
+
+.edge.tier-validated-control .edge-line {
+  stroke: var(--tone-success-dot);
+  stroke-width: 2.2;
+}
+
+.node {
+  cursor: pointer;
+}
+
+.node-dot {
+  fill: var(--paper-raised);
+  stroke: var(--line-strong);
+  stroke-width: 1.6;
+}
+
+.node[data-role='control'] .node-dot,
+.node[data-role='disturbance'] .node-dot,
+.node[data-role='feature'] .node-dot {
+  stroke: var(--tone-info-dot);
+}
+
+.node[data-role='target'] .node-dot {
+  stroke: var(--tone-success-dot);
+}
+
+.node[data-role='guard'] .node-dot {
+  stroke: var(--tone-danger-dot);
+}
+
+.node-halo {
+  fill: none;
+  stroke: var(--focus-ring);
+  stroke-width: 1.3;
+  stroke-dasharray: 3 3;
+}
+
+.node-label {
+  fill: var(--ink-soft);
+  font-size: 11px;
+  font-family: var(--font-mono, ui-monospace, monospace);
+}
+
+.node.selected .node-label {
+  fill: var(--ink);
+}
+
+.node:focus-visible .node-dot {
+  stroke: var(--focus-ring);
+  stroke-width: 2.4;
+}
+
+.legend {
+  display: flex;
+  gap: 14px;
+  padding: 2px 4px 6px;
+  font-size: 11px;
+  color: var(--ink-faint);
+}
+
+.legend-item::before {
+  content: '';
+  display: inline-block;
+  width: 18px;
+  height: 0;
+  margin-right: 5px;
+  vertical-align: middle;
+  border-top: 1.4px solid var(--ink-faint);
+}
+
+.legend-item.candidate_influence::before {
+  border-top-style: dashed;
+}
+
+.legend-item.observed_correlation::before {
+  border-top-color: var(--tone-info-dot);
+}
+
+.legend-item.validated_control::before {
+  border-top: 2.2px solid var(--tone-success-dot);
+}
+</style>

package/app/pages/aml/styles.css

@@ -169,6 +169,7 @@ h1 { margin: 2px 0 4px; font-size: 28px; font-weight: 600; letter-spacing: -0.02
 .note-cell { max-width: 260px; }
 .label-cell { max-width: 220px; }
 .label-cell .label-text { display: inline-block; overflow: hidden; width: 100%; text-overflow: ellipsis; white-space: nowrap; }
+.label-cell .desc-text { display: block; margin-top: 2px; color: var(--ink-faint, #8b98a5); font-size: 11px; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; max-width: 320px; }
 .note { display: inline-block; overflow: hidden; width: 100%; text-overflow: ellipsis; white-space: nowrap; }
 .kind {
   margin-left: 6px;

package/app/pages/ontology/api.ts

@@ -0,0 +1,18 @@
+/** Ontology 页面 REST 封装(与 Agent 工具/MCP 共用同一服务层)。 */
+import { apiFetch } from '~/composables/workshop/apiClient'
+
+type JsonInit = Omit<RequestInit, 'body'> & { body?: unknown }
+
+function withJson(init?: JsonInit): RequestInit | undefined {
+  if (!init) return undefined
+  const { body, ...rest } = init
+  if (body === undefined) return rest
+  return {
+    ...rest,
+    headers: { 'content-type': 'application/json', ...(rest.headers as Record<string, string> | undefined) },
+    body: JSON.stringify(body),
+  }
+}
+
+export const ontologyApi = <T>(path: string, init?: JsonInit) =>
+  apiFetch<T>({ base: '/api/workshop/ontology', path, init: withJson(init) })