dic-workflow-kit 1.1.1 → 1.1.3

package/README.zh-CN.md

@@ -1,6 +1,6 @@
 # 设计—实现一致性 Workflow Kit
 
-版本：`1.1.1`
+版本：`1.1.3`
 
 [更新日志](CHANGELOG.md)
 
@@ -12,28 +12,30 @@ Design-Implementation Consistency Workflow Kit，简称 DIC Workflow Kit，是
 
 ## 通过 npm 安装
 
-npm 包完整包含 7 个 Skills 和 9 个 Subagents，并支持 Codex、Claude Code、OpenCode 和 MiMo Code 的原生目录结构。
+npm 包完整包含 7 个 Skills 和 9 个 Subagents，并支持 Codex、Claude Code、OpenCode、MiMo Code 和 BitFun 的原生目录结构。
 
 Codex 仍是默认宿主，原命令保持兼容：
 
 ```text
-npx dic-workflow-kit@1.1.1 install
+npx dic-workflow-kit@1.1.3 install
 ```
 
 安装到其他宿主时显式指定 `--host`：
 
 ```text
-npx dic-workflow-kit@1.1.1 install --host claude-code
-npx dic-workflow-kit@1.1.1 install --host opencode
-npx dic-workflow-kit@1.1.1 install --host mimo-code
+npx dic-workflow-kit@1.1.3 install --host claude-code
+npx dic-workflow-kit@1.1.3 install --host opencode
+npx dic-workflow-kit@1.1.3 install --host mimo-code
+npx dic-workflow-kit@1.1.3 install --host bitfun
 ```
 
 默认是用户级安装；若只希望当前仓库使用，则增加 `--scope project`：
 
 ```text
-npx dic-workflow-kit@1.1.1 install --host claude-code --scope project
-npx dic-workflow-kit@1.1.1 install --host opencode --scope project
-npx dic-workflow-kit@1.1.1 install --host mimo-code --scope project
+npx dic-workflow-kit@1.1.3 install --host claude-code --scope project
+npx dic-workflow-kit@1.1.3 install --host opencode --scope project
+npx dic-workflow-kit@1.1.3 install --host mimo-code --scope project
+npx dic-workflow-kit@1.1.3 install --host bitfun --scope project
 ```
 
 | 宿主 | 用户级目录 | 项目级目录 |
@@ -42,13 +44,16 @@ npx dic-workflow-kit@1.1.1 install --host mimo-code --scope project
 | Claude Code | `~/.claude/{skills,agents}` | `.claude/{skills,agents}` |
 | OpenCode | `~/.config/opencode/{skills,agents}` | `.opencode/{skills,agents}` |
 | MiMo Code | 平台配置根目录下的 `mimocode/{skills,agents}` | `.mimocode/{skills,agents}` |
+| BitFun | 平台原生的 BitFun 数据/配置目录 | `.bitfun/{skills,agents}` |
 
-Windows 上 MiMo Code 的用户级根目录为 `%LOCALAPPDATA%\mimocode`；适用时也会读取 `MIMOCODE_HOME` 和 `XDG_CONFIG_HOME`。安装器以仓库中的 `agents/` 为唯一来源，并按宿主转换 Subagent frontmatter，避免维护四套重复内容。
+Windows 上 MiMo Code 的用户级根目录为 `%LOCALAPPDATA%\mimocode`；适用时也会读取 `MIMOCODE_HOME` 和 `XDG_CONFIG_HOME`。BitFun 的用户级 Skills 安装到平台数据目录下的 `BitFun/skills`，Subagents 安装到 BitFun 配置根目录下的 `bitfun/agents`；项目级安装统一使用 `.bitfun`。安装器以仓库中的 `agents/` 为唯一来源，并按宿主转换 Subagent frontmatter，避免维护多套重复内容。
+
+对于 BitFun，安装器会生成其原生 custom-agent schema。检查和规划角色保持只读，只有 `code-repairer` 与 `validation-runner` 获得职责所需的写入和命令工具。
 
 也可以先全局安装 CLI：
 
 ```text
-npm install --global @tonyclaw/dic-workflow-kit@1.1.1
+npm install --global @tonyclaw/dic-workflow-kit@1.1.3
 dic-workflow-kit install --host opencode
 ```
 
@@ -61,11 +66,28 @@ dic-workflow-kit install
 
 使用 `--dry-run` 预演目标目录，使用 `--install-root <path>` 指定隔离的宿主根目录；Codex 仍兼容 `--marketplace-root <path>`。首次创建 Skills 或 agents 目录后，请重启或重新加载对应 Coding Agent 会话。
 
+### 检查、升级与卸载
+
+每次成功安装都会写入 `.dic-workflow-kit-install.json`，记录包版本、宿主目录、受管理文件及其 SHA-256。使用 `doctor` 检查是否存在文件缺失或被修改：
+
+```text
+dic-workflow-kit doctor --host bitfun --scope project
+dic-workflow-kit doctor --host opencode
+```
+
+只移除当前安装清单管理的文件：
+
+```text
+dic-workflow-kit uninstall --host bitfun --scope project
+```
+
+安装器不会默认覆盖未受管理或已被本地修改的文件；卸载器也不会默认删除已修改的受管理文件。请先检查报告中的路径，仅在确认这些修改可以丢弃时使用 `--force`。`install`、`doctor` 和 `uninstall` 都支持 `--json`，可供 CI 或自动化脚本消费。
+
 ## 用户如何使用
 
 ### 1. 在项目根目录启动 Coding Agent
 
-安装完成后，进入需要检查的代码仓库，重新启动 Codex、Claude Code、OpenCode 或 MiMo Code。第一次安装新 Skills/agents 目录时，已有会话可能无法立即发现它们。
+安装完成后，进入需要检查的代码仓库，重新启动 Codex、Claude Code、OpenCode、MiMo Code 或 BitFun。第一次安装新 Skills/agents 目录时，已有会话可能无法立即发现它们。
 
 ```text
 cd /path/to/your-project
@@ -73,7 +95,7 @@ cd /path/to/your-project
 
 ### 2. 用自然语言启动工作流
 
-下面这条提示词适用于四种宿主：
+下面这条提示词适用于五种宿主：
 
 ```text
 使用 DIC Workflow Kit 检查当前项目的设计—实现一致性。
@@ -146,7 +168,10 @@ knowledge-openspec 检查当前 OpenSpec 变更。
 ### 常见问题
 
 - **找不到 Skill/Subagent**：重启 Coding Agent，并使用 `--dry-run` 检查安装目标。
-- **只想当前仓库使用**：Claude Code、OpenCode、MiMo Code 安装时增加 `--scope project`。
+- **检查安装完整性**：使用与安装时相同的宿主、scope 和根目录参数运行 `doctor`。
+- **安装提示冲突**：先检查报告中的文件，保存或重命名用户内容后再考虑 `--force`。
+- **卸载拒绝删除修改文件**：可以保留当前安装；只有备份修改后才应使用 `--force`。
+- **只想当前仓库使用**：Claude Code、OpenCode、MiMo Code、BitFun 安装时增加 `--scope project`。
 - **项目没有 OpenSpec**：仍可使用设计文档、API、Schema、README 或产品需求作为权威设计源。
 - **缺少验证工具**：记录缺失的命令和环境原因，最终状态应为 `BLOCKED` 或 `PARTIAL`，不要伪造成功。
 - **测试通过是否等于一致**：不等于。还必须确认需求、分支、状态迁移、副作用及集成流程符合设计。
@@ -161,7 +186,7 @@ knowledge-openspec 检查当前 OpenSpec 变更。
 `package.json` 是唯一版本源。版本脚本会同步 Codex 插件清单、工作流脚本、全部 Skills、全部 Subagents 和中英文 README：
 
 ```text
-npm run release:set-version -- 1.1.1
+npm run release:set-version -- 1.1.3
 npm run release:plan
 npm run release:dual:dry-run
 npm run release:dual
@@ -209,7 +234,7 @@ DIC Workflow Kit 将这个问题转换为一条可重复执行的证据链：
 | 01 | `workflow-intake` | 工作流方法 | Subagent 启动前 | 识别设计源、实现目录、测试目录、保护路径、验证命令和 Adapter 线索。 |
 | 02 | `workflow-profile` | 工作流方法 | Subagent 启动前 | 将 Intake 证据规范化为所有下游角色共同消费的项目画像。 |
 | 03 | `knowledge-openspec` | 知识包 | 读取设计源时；检测到 OpenSpec 才加载 | 理解 proposal、design、spec、scenario、task、active change 和 archived capability。 |
-| 04 | `knowledge-bdd` | 知识包 | 契约确认后；需要行为覆盖时 | 从已确认设计规则和流程契约生成 Given–When–Then 验收场景。 |
+| 04 | `knowledge-bdd` | 知识包 | 存在 `.feature` 或需要行为覆盖时 | 解释已挂载的 Gherkin 契约，或从已确认设计中生成受来源约束的 Given–When–Then 场景。 |
 | 05 | `workflow-repair` | 工作流方法 | 审计、修复与最终审核阶段 | 控制有来源的检查、修复计划、最小变更、验证循环和证据更新。 |
 | 06 | `knowledge-repair-distill` | 知识包 | 修复规划或模型跑偏时 | 提供缺口分类、收敛策略、模型引导提示和验证门槛。 |
 
@@ -268,6 +293,108 @@ validation-runner -> final-reviewer
 
 Skills 提供全局控制或阶段知识；Subagents 消费边界明确的输入并产出类型化证据。少量但有效的 Handoff，优于没有产物被消费的装饰性 Agent 链。
 
+## 本体驱动的一致性
+
+DIC 将一次运行建模为可移植的语义图，而不是互相独立的 Agent 总结。
+`reports/ontology-snapshot.json` 保存类型化对象（设计源、需求、场景、实现单元、
+缺口、修复动作、验证和证据）以及它们之间的明确关系。
+
+每个对象都有稳定 ID、生命周期和来源证据。Agent 通过
+`schemas/ontology-action.schema.json` 定义的受控动作改变状态。最终审查者根据
+图上的不变量计算 PASS：有效义务必须有来源，需求必须有实现处置，义务必须有
+当前验证证据，并且不能存在未关闭的阻断缺口。
+
+本体默认以文件保存，不依赖图数据库，因此可跨 Codex、Claude Code、OpenCode、
+MiMo Code 和 BitFun 使用；后续可以增加 SQLite 或图服务索引而不改变语义契约。
+
+发布后的单文件 CLI 已内置动作校验和审计能力，但不会发布运行时源码：
+
+```text
+dic-workflow-kit ontology-check --root . --status PASS
+dic-workflow-kit action-check --root . --action reports/actions/repair.json
+dic-workflow-kit action-record --root . --action reports/actions/repair.json
+dic-workflow-kit ontology-reconcile --root .
+dic-workflow-kit ontology-ledger-check --root . --json
+dic-workflow-kit ontology-evidence-check --root . --json
+dic-workflow-kit ontology-validation-check --root . --json
+dic-workflow-kit ontology-implementation-check --root . --json
+dic-workflow-kit ontology-query --root . --query impact --id <object-id>
+dic-workflow-kit ontology-drift --root .
+dic-workflow-kit ontology-plan --root . --json
+dic-workflow-kit ontology-explain --root . --id <object-id> --json
+dic-workflow-kit ontology-report --root . --status PASS
+dic-workflow-kit ontology-attest --root . --status PASS --summary "已验证"
+dic-workflow-kit ontology-attestation-check --root .
+```
+
+`action-record` 将带 SHA-256 的不可变记录追加到
+`reports/ontology-actions.jsonl`，并拒绝越权角色、无效目标、缺失证据、
+保护路径重叠和 Action ID 冲突。
+
+新记录采用 v2 Ledger：包含序号、前一记录哈希、基准 Snapshot 修订、Action
+哈希和整条记录哈希，可检测重排、插入、修改和过期状态落账，同时兼容连续的
+v1 历史前缀。使用 `ontology-ledger-check` 查看链头和整文件哈希。
+
+完成态 Action 必须携带声明式 `ontologyPatch`。每种 Action 只能增加被允许的对象、
+关系和生命周期迁移。`ontology-reconcile` 会校验 Ledger 哈希、跳过已经应用的
+Action、重放剩余 Patch、重新计算不变量，并且只在候选状态完整有效时替换快照。
+
+`ontology-query` 提供四类查询：未覆盖义务、开放 Gap、无证据验证，以及从指定
+对象出发的有限深度影响链。
+
+`ontology-evidence-check` 会验证当前 Validation 所需的每个 Evidence 是否指向
+项目内真实文件，以及当前字节是否匹配记录的 SHA-256。只有生命周期有效且
+`properties.status: PASS` 的 Validation 才能通过 `VERIFIED_BY` 满足 PASS。
+
+`ontology-validation-check` 用来堵住“旧绿灯日志批准新代码”的漏洞。每个
+Validation 必须记录 `executedAt`，并通过 `{ objectId, contentHash }` 绑定本次
+运行实际消费的 DesignSource 与 ImplementationUnit。输入缺失或哈希过期会阻断
+PASS，并使最终 Attestation 失效。
+
+`ontology-implementation-check` 会将每个必需 ImplementationUnit 与项目内文件及
+记录的 SHA-256 比较。既有代码通过 `ObserveImplementation` 记录；
+`ApplyRepair` 只表示获批修复实际创建或修改的实现。
+
+`ontology-drift` 会将设计源当前内容与快照中的 SHA-256 来源记录进行比较；
+变更或丢失的设计源返回非零状态，其对象 ID 可以直接用于影响链查询。
+
+`ontology-plan` 将设计源、实现文件、Evidence 漂移和影响链组合成最小重跑计划。
+设计变化从 Intake/Contract 重跑，实现漂移从 Inspection/Validation 重跑，
+仅 Evidence 漂移则只重跑 Validation 与 Final Review。
+
+生成或重放后的快照包含规范化 `snapshotRevision`。直接修改语义状态会导致修订
+哈希失效；Reconcile 也会拒绝覆盖执行期间已经发生变化的快照。设计源漂移已经
+接入 PASS 门禁，因此旧的绿色验证证据不能批准已经变化的设计。
+
+`ontology-explain` 会返回对象属性、来源、直接关系和有限深度证据链，便于说明
+某个结论来自哪一行设计、对应哪个实现、Gap、Repair、Validation 和 Evidence。
+
+`ontology-report` 直接从快照生成高信息密度 Markdown 视图。
+`ontology-attest` 生成内容寻址的终态证明，将结论绑定到快照修订、Action Ledger
+哈希、设计源哈希、Evidence 制品哈希、ImplementationUnit 哈希和门禁结果；
+`ontology-attestation-check` 会重新计算这些绑定，因此设计源、实现文件、
+证据文件、Ledger、快照或证明被改动后都会失败关闭。
+应将输出的 `contentHash` 保存到 CI 或 Release 元数据，并通过
+`--expected-hash` 进行外部锚定；仅在同一文件内保存哈希只能证明完整性，
+不能证明真实性。
+
+## BDD 作为本体入口
+
+源码 Helper 会识别常见 feature、BDD、spec 和 test 目录中的 `.feature` 文件，
+并支持英文及常见中文 Gherkin 关键字：
+
+- Feature/功能映射为 Requirement。
+- Scenario/场景和 Scenario Outline/场景大纲映射为 Scenario。
+- Background/背景步骤继承到每个场景。
+- Examples 表、标签、行号和来源哈希完整保留。
+- `DERIVED_FROM` 连接设计源，`REFINES` 连接 Feature Requirement。
+
+场景被解析不代表验证通过；仍需通过 `RunValidation` 和 `AttachEvidence` 挂载
+当前执行证据。
+
+显式选择某个 OpenSpec Change 时，只挂载被该 Change 引用的 Feature 文件；
+其他检测到的文件保持可发现，但不会静默扩大 Change 的义务范围。
+
 ## OpenSpec 适配重点
 
 | OpenSpec 文件 | 使用方式 |
@@ -285,6 +412,10 @@ Skills 提供全局控制或阶段知识；Subagents 消费边界明确的输入
 reports/project-profile.json
 reports/contract-obligations.json
 reports/contract-obligations.md
+reports/ontology-snapshot.json
+reports/ontology-actions.jsonl
+reports/ontology-report.md
+reports/ontology-attestation.json
 reports/implementation-gaps.md
 reports/repair-plan.md
 reports/final-consistency-report.md

package/adapters/bdd/README.md

@@ -0,0 +1,21 @@
+# BDD Adapter
+
+Detects Gherkin `.feature` files under conventional feature, BDD, spec, and test
+roots.
+
+The source helper mounts:
+
+- `Feature` / `功能` as a source-backed `Requirement`
+- `Scenario`, `Scenario Outline`, `场景`, and `场景大纲` as `Scenario`
+- `Background` / `背景` steps as inherited acceptance clauses
+- `Examples` / `示例` tables as structured scenario properties
+- Given/When/Then/And/But and common Chinese equivalents as normalized clauses
+
+BDD sources remain protected design inputs. A parsed scenario is an acceptance
+contract, not validation evidence; `VERIFIED_BY` is added only after the
+Validation Runner executes current tests and records durable evidence.
+
+When intake is explicitly scoped to one OpenSpec Change, only Feature files
+referenced by that Change's documents or delta specs are mounted. Other detected
+Feature files remain available in `availableBddSources` without widening the
+Change contract.

package/adapters/bitfun/README.md

@@ -0,0 +1,40 @@
+# BitFun Adapter
+
+Install into BitFun with:
+
+```text
+npx dic-workflow-kit@1.1.3 install --host bitfun
+```
+
+For repository-local discovery:
+
+```text
+npx dic-workflow-kit@1.1.3 install --host bitfun --scope project
+```
+
+The project-level layout is:
+
+```text
+.bitfun/
+  skills/
+  agents/
+```
+
+The installer keeps every `SKILL.md` portable and converts each canonical
+Subagent definition to BitFun custom-agent schema version 1. Inspection and
+planning roles are read-only. `code-repairer` and `validation-runner` receive
+the write and command tools required to repair code and capture validation
+evidence.
+
+Restart or reload BitFun after first installation so it can rediscover the
+new Skills and Subagents.
+
+Verify or remove the project installation with:
+
+```text
+dic-workflow-kit doctor --host bitfun --scope project
+dic-workflow-kit uninstall --host bitfun --scope project
+```
+
+The generated installation manifest protects locally modified files from
+silent overwrite or removal.

package/agents/code-repairer.md

@@ -1,6 +1,6 @@
 ---
 name: code-repairer
-version: 1.1.1
+version: 1.1.3
 description: Implement approved repair slices while preserving contracts, minimizing blast radius, and avoiding unrelated refactors.
 mode: subagent
 ---
@@ -13,5 +13,12 @@ Mission:
 - Keep changes small and source-backed.
 - Preserve frozen contracts.
 - Record changed files and repair rationale.
+- Execute only an approved `ApplyRepair` action.
+- Enforce its targets, allowed paths, preconditions, and postconditions.
+- Link the completed repair to its gap; do not close the gap without validation evidence.
+- Run `action-check` before editing and append the completed action with `action-record` when the runtime is available.
+- Materialize repair-produced `ImplementationUnit` and `IMPLEMENTED_BY` facts through the action patch, then reconcile.
+- Record the repaired file's project-relative path and post-repair SHA-256 with the `ContentAddressed` interface.
+- Do not use `ApplyRepair` merely to describe code that already existed; that belongs to `ObserveImplementation`.
 
 If a compile failure appears, re-check the governing source rule before applying follow-up fixes.

package/agents/contract-oracle.md

@@ -1,6 +1,6 @@
 ---
 name: contract-oracle
-version: 1.1.1
+version: 1.1.3
 description: Convert source requirements, OpenSpec scenarios, and feedback hypotheses into source-confirmed implementation obligations.
 mode: subagent
 ---
@@ -13,5 +13,8 @@ Mission:
 - Confirm each obligation against source files.
 - Reject or mark non-applicable candidates with evidence.
 - Route confirmed obligations to flow audit or implementation inspection.
+- Confirm lifecycle and provenance for requirement and scenario objects.
+- Record confirmation through a `ConfirmObligation` action; do not edit implementation.
+- Express confirmation as a permitted lifecycle transition in `parameters.ontologyPatch`.
 
 Do not use knowledge packs as source truth.

package/agents/final-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: final-reviewer
-version: 1.1.1
+version: 1.1.3
 description: Perform the final consistency gate across source coverage, protected paths, validation evidence, residual risks, changed files, and output artifacts.
 mode: subagent
 ---
@@ -15,5 +15,18 @@ Mission:
 - Check validation/result consistency.
 - Check final artifacts.
 - Reject decorative subagent usage that produced no consumed evidence.
+- Recompute `reports/ontology-snapshot.json` invariants for the requested status.
+- Reject PASS when an active obligation lacks `DERIVED_FROM`, `IMPLEMENTED_BY`, or `VERIFIED_BY` evidence.
+- Reject PASS while a blocking `Gap` remains open.
+- Run `ontology-check --status PASS`; a blocking invariant failure is terminal evidence, not a suggestion.
+- Reject a stale snapshot revision or any changed, missing, or out-of-project tracked design source.
+- Generate `reports/ontology-report.md` from the current snapshot; do not hand-copy semantic conclusions into prose.
+- Create `reports/ontology-attestation.json` only after the requested gate passes.
+- Run `ontology-attestation-check` immediately before publishing the final result; reject a stale snapshot, ledger, source, or content hash.
+- Run `ontology-ledger-check`; reject a broken sequence, hash chain, action hash, or record hash.
+- Run `ontology-evidence-check`; reject a non-PASS Validation or any required Evidence artifact whose current bytes do not match provenance.
+- Run `ontology-validation-check`; reject a Validation that does not bind the current DesignSource and ImplementationUnit hashes.
+- Run `ontology-implementation-check`; reject inactive, missing, changed, untracked, invalid, or out-of-project ImplementationUnit artifacts.
+- When CI or release metadata provides an attestation digest, pass it as `--expected-hash`; a self-recomputed hash is not an external trust anchor.
 
 Final quality is measured by evidence, not by agent count.

package/agents/flow-auditor.md

@@ -1,6 +1,6 @@
 ---
 name: flow-auditor
-version: 1.1.1
+version: 1.1.3
 description: Audit business and use-case flow completeness, including lifecycle, branches, state transitions, side effects, integration paths, and failure handling.
 mode: subagent
 ---

package/agents/impl-inspector.md

@@ -1,6 +1,6 @@
 ---
 name: impl-inspector
-version: 1.1.1
+version: 1.1.3
 description: Inspect implementation against source-confirmed obligations without editing files.
 mode: subagent
 ---
@@ -13,3 +13,9 @@ Mission:
 - Identify missing, partial, contradictory, or over-broad implementation.
 - Inspect tests only as evidence, not as source truth.
 - Produce a gap report for repair planning.
+- Record existing code through `ObserveImplementation`; do not misclassify observation as `ApplyRepair`.
+- Give every ImplementationUnit a project-relative path, SHA-256 provenance hash, and `ContentAddressed` interface.
+- Add `IMPLEMENTED_BY` only when the current file resolves and its bytes match provenance.
+- Open typed `Gap` objects for missing, partial, contradictory, or over-broad behavior.
+- Do not repair code or mark a gap resolved.
+- Emit `Gap` plus `VIOLATES` as an `OpenGap` ontology patch.

package/agents/profile-builder.md

@@ -1,6 +1,6 @@
 ---
 name: profile-builder
-version: 1.1.1
+version: 1.1.3
 description: Build a normalized project profile from repository evidence so downstream agents stop guessing paths, tools, and source hierarchy.
 mode: subagent
 ---

package/agents/repair-planner.md

@@ -1,6 +1,6 @@
 ---
 name: repair-planner
-version: 1.1.1
+version: 1.1.3
 description: Create small, source-backed repair slices with target files, validation commands, stop conditions, and fallback plans.
 mode: subagent
 ---
@@ -15,3 +15,12 @@ Mission:
 - Avoid decorative subagent chains.
 
 Every repair item must include source anchor, target area, expected behavior, validation command, and stop condition.
+
+Represent each item as a proposed `RepairAction` using
+`schemas/ontology-action.schema.json`. Include explicit targets, preconditions,
+postconditions, allowed paths, validation evidence requirements, rollback, and
+the current `expectedSnapshotRevision`.
+Planning does not authorize execution.
+
+The completed `ProposeRepair` action adds a `RepairAction` and its `RESOLVES`
+link through `parameters.ontologyPatch`.

package/agents/spec-reader.md

@@ -1,6 +1,6 @@
 ---
 name: spec-reader
-version: 1.1.1
+version: 1.1.3
 description: Read authoritative design, OpenSpec, API, schema, README, and configuration sources and produce a source-backed requirement brief.
 mode: subagent
 ---
@@ -13,6 +13,8 @@ Mission:
 - Summarize requirements with file anchors.
 - Separate stable requirements from examples.
 - Mark ambiguity as `VERIFY`, not as implementation freedom.
+- Propose `DesignSource`, `Requirement`, and `Scenario` objects with stable source locators and revisions.
+- Do not create implementation, repair, or final-decision facts.
 
 Output a handoff with:
 
@@ -21,3 +23,4 @@ Output a handoff with:
 - protected paths
 - unresolved questions
 - next recommended agent
+- proposed ontology object IDs and `DERIVED_FROM` / `REFINES` links

package/agents/validation-runner.md

@@ -1,6 +1,6 @@
 ---
 name: validation-runner
-version: 1.1.1
+version: 1.1.3
 description: Discover, run, and summarize project validation commands using evaluator-readable evidence.
 mode: subagent
 ---
@@ -14,3 +14,13 @@ Mission:
 - Store logs under `logs/trace/validation/`.
 - Wrap results into machine-readable summaries.
 - Classify missing tools as environment evidence.
+- Create `Validation` objects with command, revision, exit status, `executedAt`, and log provenance.
+- Record `properties.inputs` as `{ objectId, contentHash }` for every DesignSource and ImplementationUnit actually consumed by the run.
+- Set `properties.status` to the actual result; only `PASS` satisfies coverage.
+- Create every Evidence object with a project-relative `properties.path`, SHA-256 `provenance.contentHash`, and `ContentAddressed` interface.
+- Run `ontology-evidence-check` after reconciliation and reject missing, changed, untracked, inactive, or out-of-project artifacts.
+- Run `ontology-validation-check` after reconciliation; reject missing, duplicate, or stale causal inputs.
+- Add `VERIFIED_BY` only when the evidence applies to the current source and implementation revisions.
+- Do not infer PASS from a successful command that lacks obligation coverage.
+- Record completed `RunValidation` and `AttachEvidence` actions in the ontology action ledger.
+- Add `Validation`, `Evidence`, `VERIFIED_BY`, and `PRODUCES` only through permitted action patches.