@xdxer/dingtalk-agent 0.1.4-beta.15 → 0.1.4-beta.16

package/README.md

@@ -2,747 +2,165 @@
 
 # dingtalk-agent
 
-**所有钉钉数字员工共享的行为内核。**
+**让数字员工继承同一套可验证的行为底座。**
 
 [![npm](https://img.shields.io/npm/v/%40xdxer%2Fdingtalk-agent?logo=npm&color=cb3837)](https://www.npmjs.com/package/@xdxer/dingtalk-agent)
 [![CI](https://github.com/D1-2004/dingtalk-agent/actions/workflows/ci.yml/badge.svg)](https://github.com/D1-2004/dingtalk-agent/actions/workflows/ci.yml)
 [![Node.js](https://img.shields.io/node/v/%40xdxer%2Fdingtalk-agent)](https://nodejs.org/)
 [![License](https://img.shields.io/badge/license-MIT-2ea44f)](LICENSE)
 
-[定位](#定位) · [快速开始](#两分钟开始) · [所有 Agent](#从一个-agent-到所有-agent) · [双半闸门](#闸门的两半) · [三层记忆](#三层语义记忆) · [真实联调](#真实世界联调)
+[快速开始](#快速开始) · [工作方式](#工作方式) · [支持范围](#支持范围) · [文档](#文档)
 
-[English](README.en.md) · 简体中文
+简体中文 · [English](README.en.md)
 
 </div>
 
-## 定位
+`dingtalk-agent`（`dta`）是钉钉数字员工的 **Skill-first 行为内核与交付工具链**。它把角色定义、公共行为、岗位能力和执行门禁装配成一个可创建、测试、发布和审计的 Agent Project。
 
-**DWS 给 Agent 钉钉的系统调用；dingtalk-agent（dta）给所有 Agent 一套可继承、可冻结、可验证的员工行为内核。** 它不负责事件从哪里来，也不复制钉钉能力；它从标准化 Invocation 开始，把员工定义、感知补齐、响应资格、Session/Run 状态、Action 闸门和效果证据组织为一个 Skill-first 行为容器。
+> **Skill 劝，CLI 拦，DWS 做。** Skill 判断何时、为何行动；CLI 固定身份、目标、预算、幂等与回读；DWS 执行钉钉能力。
 
-![dingtalk-agent 当前 Skill-first 运行架构](docs/architecture/dingtalk-agent-blueprint.svg)
+![从 Agent 定义到两类身份交付的完整路径](docs/assets/agent-delivery-lifecycle.svg)
 
-```text
-Agent Host + dta Kernel + Agent Definition + Basic Behavior + Role Skills + DWS
-    = 一个可以持续工作的钉钉数字员工
-```
-
-| 层 | 负责什么 | 不负责什么 |
-|---|---|---|
-| **Agent Definition** | 我是谁、负责什么、服务谁、能用哪些 Skill/资源/权限 | 不保存当前 Run，不从消息正文猜 ID |
-| **Basic + Role Skills** | 何时说/问/静默，以及岗位任务怎么做 | 不绕过身份、目标和副作用门禁 |
-| **dta Kernel** | Invocation、感知补齐、Session/Run/Wait、Action Gate、Receipt | 不内置模型，不监听所有事件，不复制 DWS |
-| **DWS** | 消息、文档、待办、日历、表格等平台能力 | 不替 Agent 决定应不应该做、对谁做 |
-
-Claude Code、Codex 或其他 Agent Host 都能使用这套内核；触发 Adapter、模型、沙箱、岗位 Skill 与存储 Provider 都可以替换。
-
-## 为什么需要它
-
-如果开发者只是偶尔手工调用一次钉钉能力，DWS 已经足够；如果要把 Agent 逐步发展成真正干活的数字员工，还必须长期维护**员工本体 + 员工状态 + 受约束的行动边界**。“会调用钉钉 API”不等于“会像员工一样工作”，真实协作还要求 Agent：
+## 快速开始
 
-- 群里未被提及时默认不抢话，被 `@` 或私聊时才获得响应资格；
-- 信息完整就直接交付，只有真正阻塞时才问一个问题；
-- 不从消息正文猜收件人、身份、文档 ID 或权限；
-- 长任务能确认收到、等待依赖、从下一条事件继续，而不是假装一直在线；
-- 区分“命令执行过”“平台写入成功”“回读可见”和“对方确认”；
-- 将任务状态、长期记忆、运行时锁和幂等回执放在正确的介质。
-
-本项目把这些约束从巨型 Prompt 中拆出来：**Skill 劝，CLI 拦，DWS 做。** 必须成立的规则进入代码；需要语义判断的行为留在 Skill；具体钉钉产品能力继续由 DWS 执行。
-
-> `0.1.4-beta.11` 已进入发布流程（npm `beta` dist-tag、Git Tag 与 GitHub Pre-release）。beta.10 移除上一代遗留死代码并对齐入口文档；beta.11 默认安装全部内置 Skill（基础行为 + 装配）、修复装配 Skill 的触发描述，并引入 managed agent platform 归属抽象（已支持 multica-dingtalk，deap 敬请期待；deploy/promote/observe 需先归属，平台技能包按选择安装）。此前 beta.9 完成 Basic 0.10.0/0.9.4 模型回归、宿主签发 Completion Evidence、远端语义状态冷启动与 Live-ready runner、开发者 Golden Path、已有仓库安全 enhance、Provider-bound Workspace W1–W5、Completion grader 加固、Phase 9 personal-event Live-ready runner 与隔离安装验收，合同评测现为 61 个确定性场景。Phase 8 的已记录样本通过当时的安全和产物硬门禁，但未证明 0.10.0 有稳定模型增益；Phase 15 又把矛盾完成声明和增益判定收紧为显式 fail-closed 策略，且不重写历史分数。本次 beta 明确豁免真实 personal-event、远端状态与 Multica Live 作为发布门禁，不把本地或 fake-Provider 证据冒充真实平台通过，也没有创建 Trigger 或钉钉/Multica 副作用。
-
-## 两分钟开始
-
-> 要求 Node.js 18.3+。CLI 固定安装到用户目录 `~/.local`，不依赖系统级写权限。
+要求 Node.js 18.3+。
 
 ```bash
 npm install --global --prefix "$HOME/.local" \
   --registry=https://registry.npmjs.org @xdxer/dingtalk-agent@beta
-"$HOME/.local/bin/dta" setup --skip-cli-install
-```
-
-这里不使用 `npx @xdxer/dingtalk-agent...` 启动自身。Why：机器上已有旧版 `dta` 时，npm exec 可能复用 PATH 中的旧 binary；`npm install --prefix` 会确定性替换用户级版本，随后绝对路径不依赖当前 shell 是否已刷新 PATH。
 
-`setup` 会按顺序完成四件事：
-
-1. 将 CLI 安装到用户目录 `~/.local/bin`，必要时幂等补充 shell PATH；
-2. 检查 Node.js、DWS 版本和 `dws auth status`；
-3. 安装并验证内置 Skill（Basic Behavior 基础行为 + Compose 装配）；
-4. 报告 Claude Code、Codex、OpenCode 是否能够发现 Skill。
-
-当前终端尚未加载新 PATH 时，setup 会打印一条可直接执行的 `export PATH=...`。验证结果：
-
-```bash
-dta --version
+"$HOME/.local/bin/dta" setup --skip-cli-install
 dta doctor
 ```
 
-之后升级不再重复安装步骤，直接运行：
-
-```bash
-dta upgrade                       # beta 版默认继续跟随 beta
-dta upgrade --channel latest      # 显式切换稳定通道
-dta upgrade --dry-run             # 只查看目标版本和将执行的命令
-```
-
-升级完成后，新的 CLI 会自动重新执行 setup，复核 PATH、DWS、Skill 与三个 Agent 客户端。
-
-从源码准备 beta 时，使用确定性 release readiness：
-
-```bash
-npm run release:check
-```
-
-它会生成真实 npm tarball，在全新 HOME/prefix 中离线安装，再运行 `setup/doctor/bootstrap/lab eval` plan、同 tarball 强制升级和显式回滚 dry-run。测试只用 fake DWS 和 fake skills installer，不发送钉钉消息、不访问 Multica、不创建 Trigger，也不执行 npm publish、Tag 或 GitHub Release。
-
-安装后推荐使用短命令 `dta`；完整名称 `dingtalk-agent` 与它完全等价。错误会同时输出原因和一条可复制的 `提示:`，命令或子命令拼错时会给出最接近的建议。
-
-安装后，Skill 只有一份 canonical copy：
-
-```text
-~/.agents/skills/dingtalk-basic-behavior/     # Codex、OpenCode 直接发现
-~/.claude/skills/dingtalk-basic-behavior      # Claude Code → canonical 相对链接
-```
-
-如果只想临时运行、不做用户级安装，任何命令都可以通过 npm exec 执行：
-
-```bash
-"$HOME/.local/bin/dta" doctor
-"$HOME/.local/bin/dta" skill install
-```
-
-也兼容开放的 `skills` CLI。仓库有访问权限时，可只安装 Skill 到三个客户端：
-
-```bash
-npx skills add D1-2004/dingtalk-agent \
-  --skill dingtalk-basic-behavior --global --yes \
-  --agent claude-code --agent codex --agent opencode
-```
-
-从本地 checkout 安装则使用：
-
-```bash
-npx skills add ./skills/core/dingtalk-basic-behavior \
-  --global --yes --agent claude-code --agent codex --agent opencode
-```
-
-`dta skill install` 内部也直接委托 `npx skills add`，不再维护独立的复制、软链、marker 或卸载链路。`npx skills` 只安装行为说明，不安装 `dingtalk-agent` CLI，也不检查 DWS；需要真实执行钉钉动作时仍应运行 `setup` 或 `doctor`。完整排障见 [安装与首次使用](docs/INSTALLATION.md)。
-
-普通 Agent 会话无需初始化项目。进入任意目录后可直接发现上下文：
-
-```bash
-dta bootstrap --json
-```
-
-只有可信事件宿主需要冻结目标并建立 Prepared Run：
-
-```bash
-mkdir fde-coach && cd fde-coach
-dta init
-dta prepare --event-file event.json --json
-```
-
-## 核心模型
-
-### 三种运行模式
-
-| 模式 | 初始化 | 上下文 | 适用场景 |
-|---|---:|---|---|
-| **Direct Session** | 不需要 | 当前请求与宿主提供的信息 | 普通 Claude Code / Codex 会话 |
-| **Mounted Session** | 不需要 | 本地 Markdown 或钉钉文档快照 | 带身份、记忆和知识的长期员工 |
-| **Prepared Run** | Workspace 一次性初始化 | 可信事件冻结的目标、身份与策略 | 自动化事件处理和强可靠外发 |
-
-本地内容直接挂载，不复制：
+`setup` 安装 Basic Behavior 与 Compose Skills，并检查 DWS 认证和常见 Agent Host。普通会话无需初始化 Workspace。
 
-```bash
-dingtalk-agent bootstrap --storage local-dir:/path/to/workspace --json
-
-# 等价的新名称；GitHub 仓库先由宿主 checkout
-dingtalk-agent bootstrap --agent local-dir:/path/to/checkout --json
-```
-
-远端内容由 DWS 探测并拉成隐藏的只读快照：
-
-```bash
-dingtalk-agent bootstrap \
-  --storage 'dingtalk-doc:<node-id-or-url>' \
-  --state-dir /path/to/session-state \
-  --json
-```
-
-本体、岗位 Skill 和持久化可以独立路由，不要求绑死在同一介质：
-
-```bash
-dta bootstrap \
-  --agent local-dir:/path/to/agent \
-  --skills local-dir:/path/to/agent/skills \
-  --memory local-md:MEMORY.md \
-  --knowledge 'dingtalk-doc:<knowledge-node>' \
-  --artifacts local-dir:/path/to/artifacts --json
-```
-
-也可以由宿主 context、环境变量或 Workspace 提供。优先级固定为：**CLI 显式参数 > 宿主 context > 环境变量 > Workspace > 目录约定**。环境变量为 `DTA_AGENT_SOURCE`、`DTA_MEMORY_STORAGE`、`DTA_KNOWLEDGE_STORAGE`、`DTA_SKILLS_SOURCE`、`DTA_ARTIFACTS_STORAGE`、`DTA_STATE_DIR`、`DTA_DWS_PROFILE` 和 `DTA_EXPECTED_USER_ID`；输出中的 `definition.configuration` 会保留每项来源。
-
-### 四个消息原子行为
-
-Prepared Run 只开放四个消息动作：
-
-```bash
-dingtalk-agent act ack
-dingtalk-agent act reply --text-file reply.txt
-dingtalk-agent act ask --text "一个真正阻塞的问题"
-dingtalk-agent act silence --reason unmentioned
-```
-
-| 动作 | 员工语义 | 关键边界 |
-|---|---|---|
-| `ack` | 看到了，确实需要时间处理 | 不等于接单、承诺或完成 |
-| `reply` | 已有可交付结果 | 只回复原消息，CLI 没有 `--to` |
-| `ask` | 缺少阻塞信息 | 一次只问一个问题，随后释放沙箱等待事件 |
-| `silence` | 有意识地不打扰 | 仍留下结构化 reason 和本地回执 |
-
-文档写入、待办创建等能力继续由 DWS 提供。只有当一个员工意图需要固定作用域、权限、幂等、回读、状态迁移或跨产品组合时，才值得包装成新的 CLI 动作。
-
-## 架构
+## 为什么需要它
 
-![dingtalk-agent 通用 Agent 行为内核拓扑](docs/architecture/general-agent-kernel-topology.svg)
+模型会说话，不等于数字员工能可靠工作。`dta` 把最容易漂移的部分变成可继承、可验证的合同：
 
-dta 的边界从标准化 `InvocationContext` 开始。消息监听、定时器、Webhook 或其它触发器在外部；它们只需提供可信 actor、target、conversation、mode 与 sessionKey。没有可信事件时默认进入 `direct`，Agent 仍像正在和用户对话的员工一样正常工作，但不会凭空获得一个可外发的钉钉目标。
+- **会判断**：先判断是否该回复，再判断说什么；群聊未 `@` 默认安静。
+- **不越权**：身份、目标、权限、授权和回复渠道不能从正文或模型记忆猜测。
+- **不虚报**：命令成功、平台可见、消息送达和人类接受是不同的完成层级。
+- **可复用**：新 Agent 继承公共行为，只补岗位差异，不复制巨型 Prompt。
 
-## 从一个 Agent 到所有 Agent
+## 工作方式
 
-任何数字员工都绕不开四件事：**感知、身份、执行记忆、受约束的行动**。因此，复制一个 Agent 不应复制整套 Prompt 和脚本，而应组装同一个内核：
+一个 Agent 由四层合同组成：
 
-| 可共享 | 按 Agent 叠加 |
+| 层 | 负责什么 |
 |---|---|
-| Basic Behavior、Invocation、Session/Run/Wait、双半闸门、Receipt 协议 | 身份、职责、服务对象、Role Skills、知识源、业务事实源、权限 allowlist |
+| **`AGENTS.md`** | 定义角色、岗位底线、做事范式和常犯错误；声明每轮先应用 Basic |
+| **Basic Behavior** | 所有数字员工共享的响应资格、作用域、授权、隐私、完成与记忆协议 |
+| **Role Skills** | 某个岗位的专业判断、流程、禁区和验收标准 |
+| **Gate + Receipt** | 把身份、目标、预算、幂等、状态迁移和平台回读变成硬约束 |
 
-`Agent Definition` 是这组差异的一等合同，至少描述：
+Prompt 只保留必须常驻、必须严格定义的内容；完整行为树进入 Skill；不能依赖模型自觉的约束进入 Gate。
 
-```text
-identity + responsibilities + serviceScope + roleSkills
-+ storageBindings + authority + refusalBoundaries
-```
-
-Session 创建时冻结 Definition 与 Skill snapshot；在线 Run 可以提出记忆或 Skill candidate，但不能热修改当前身份、权限和已启用 Skill。这样 FDE 教练、招聘助理与运维助手可以共用内核，又不会互相污染职责和数据。
-
-### 角色身份、执行身份与委托
-
-**我们的一个 Agent = 角色本体或委托 + 沙箱中的实际 DWS 执行身份 + Workspace/Skills + 可恢复状态；机器人、真实 IM 或标准大脑只是输入渠道，不是 Agent 本体。**
+### 创建 → 测试 → 发布
 
-这里有两条必须分开的身份轴：
-
-| 身份轴 | 回答什么 | 可能形态 |
+| 阶段 | 关键产物 | 门禁 |
 |---|---|---|
-| **角色/委托身份** | 我是什么角色、要完成什么、服务谁、受谁委托、允许做什么 | 固定岗位；代表某人/团队工作的受托 Agent |
-| **DWS 执行身份** | 沙箱里实际由哪个钉钉账号读取或写入 | 跟随当前聊天者；固定为专用员工/服务账号 |
-
-两者相同时，Agent 是以自己的平台身份履行自己的职责，可视为“本体模式”；两者不同时，是明确的委托关系。委托不会扩大权限：动作必须同时满足角色职责、委托范围和实际 DWS 身份权限，平台回执也必须记录真实执行者，不能把“代表谁”写成“实际由谁执行”。
-
-当前 `agent-definition@1` 会把 `authority.dwsProfile/expectedUserId` 冻结到 Session。固定身份直接来自 Workspace；“跟随聊天者”由可信宿主在 Session 创建前通过 context/显式配置注入，进入 Session 后同样不可漂移。角色、委托方和职责目前由 `AGENTS.md`/Role Skill 表达；后续若要自动审计委托链，应再把 principal、delegator 和 binding mode 升级为结构化合同，而不是从自然语言或消息正文猜测。
-
-无论消息来自机器人 connector、真实 personal-event，还是另一个标准化大脑/Agent Host，进入 dta 后都应归一成 Invocation。机器人渠道下也仍像同事一样回复；渠道只决定可获得的 envelope 和谁拥有外发权，不改变角色本体。
-
-### 用仓库或文件夹定义钉钉数字员工 Agent
-
-最小可工作装配只有两组输入：
-
-```text
-本体：本地 AGENTS.md + Basic Behavior + 本地 Role Skills
-路由：memory + knowledge + artifacts + private state + DWS authority
-```
-
-GitHub 作为版本化发布面：宿主负责 clone、凭证和更新，dta 从本地 checkout 读取本体并记录 HEAD；普通文件夹直接挂载。memory/knowledge 可以继续留在本地，也可以路由到专用钉钉文档；`agent.bindings.json` 把这些选择固化为 [`agent-bindings@1`](docs/schemas/agent-bindings.schema.json)。Prepared Session 首次创建时冻结 [`AgentDefinition`](docs/schemas/agent-definition.schema.json)，后续消息生成 [`InvocationContext`](docs/schemas/invocation.schema.json)。
-
-需要让 Agent 辅导已有材料按这个范式补齐时，可额外安装装配 Skill：
-
-```bash
-dta skill install dingtalk-agent-compose
-```
-
-它会辅导并安全补齐 `AGENTS.md`、Role Skill、storage bindings、Agent Project 和 OpenCode exposure，再由 `dta agent audit` 输出稳定的 `agent-audit@1`、`ready/partial` 与逐项修复动作；不会自动初始化 Workspace，也不把监听、定时器或 Webhook 收进 dta。
-
-已有仓库先用 `agent enhance`，不要直接复制模板覆盖文件：
-
-```bash
-# 默认只生成 agent-enhancement-plan@1，不写文件、不访问 DWS
-dta agent enhance --project-name release-agent \
-  --role-skill release-manager --dry-run --json
-
-# 审阅 operations / blockers / semanticReview 后，使用计划返回的当前 planId
-dta agent enhance --project-name release-agent \
-  --role-skill release-manager \
-  --plan-id <current-plan-id> --yes --json
-```
-
-apply 只修改本地 Agent 目录；更新旧文件前会备份到 `.dingtalk-agent/backups/agent-enhance/<operationId>/`，自定义 `stateDir` 会同步进入 `.gitignore`，输入漂移、过期 plan、非法 Role 路径、未知 OpenCode instruction、路径越界或 symlink 会在覆盖前失败。新建模板仍含待填写的岗位语义，所以 Receipt 的 audit 会保持 `partial`：只有真实身份、职责、交付物、拒绝边界、Role SOP 与验收都填完，`definition.semantic-contract` / `skill.role.<name>.semantic` 才通过。换句话说，`enhance plan ready` 只是“可以安全装修”，不是“数字员工已经毕业”。计划与 Receipt 分别遵循 [`agent-enhancement-plan@1`](docs/schemas/agent-enhancement-plan.schema.json) 和 [`agent-enhancement-receipt@1`](docs/schemas/agent-enhancement-receipt.schema.json)。
-
-对 OpenCode，`ready` 还有一个硬条件：`.agents/skills/dingtalk-basic-behavior/SKILL.md` 只是项目 exposure，必须再由 `opencode.json#instructions` 强制注入正文。OpenCode 原生 Skill 默认按需加载，而 Basic Behavior 每条消息都必须生效；因此不能用“目录存在”或“`debug skill` 能看到”冒充已加载。compose 会要求 resolved config、项目路径/hash/version 和随机 load probe 四项证据；Role Skills 仍按岗位任务触发。
-
-最短验收链路是：
-
-```bash
-dta bootstrap --bindings agent.bindings.json --json
-
-# 纯本地静态审计：零模型、零 DWS；缺口返回 partial 和退出码 2
-dta agent audit --bindings agent.bindings.json \
-  --require-skill <role-skill-name> --json
-
-# 只运行隔离 OpenCode load probe；仍不访问钉钉
-dta agent audit --bindings agent.bindings.json \
-  --require-skill <role-skill-name> --verify-load --yes --json
-```
-
-这条链路已经用 `examples/agents/release-manager` 做过一次真实本地 dogfood：OpenCode 1.17.14 + `deepseek/deepseek-chat` 的 with-skill 随机探针精确加载 1/1，without-skill 未猜中 1/1，最终 audit 从只缺 `host.load-probe` 的 `partial` 收敛为 `ready`。这只证明“组装与加载链路可走通”，不证明岗位任务质量或稳定行为增益；脱敏证据见 [`agent-enhance-opencode-dogfood-summary.json`](evals/baselines/2026-07-17/agent-enhance-opencode-dogfood-summary.json)。
-
-远端 memory/knowledge 不会因“本地缓存存在”直接变成 ready：必须先用授权的 storage eval 验证 DWS 身份、文档类型、hash、独立回读和模型使用，再通过 `--remote-report` 绑定证据。Wait、generation、幂等键、Receipt 与凭据始终留在宿主原子存储。
-
-### 一个 Project，多个开发 Workspace
-
-`agent.bindings.json` 描述 Agent 本体与存储路由；项目根的 [`dingtalk-agent.json`](docs/schemas/project.schema.json) 进一步声明“同一份 Agent 在哪些开发环境中工作”。一个 Development Workspace 只绑定一个 Host Provider，但 memory/knowledge/artifacts 仍可分别使用不同 Storage Provider：
-
-```text
-Agent Project
-├── local-dev   ── Host: OpenCode ── Storage: local-md/local-dir
-├── multica-dev ── Host: Multica  ── Storage: dingtalk-doc/local-dir
-└── legacy-prepared ── 旧 workspace@1 的只读兼容视图
-```
-
-W1 提供完全只读的发现与诊断：
-
-```bash
-dta info --json
-dta workspace list --json
-dta workspace show local-dev --json
-dta workspace doctor local-dev --json
-```
-
-CLI 会从任意子目录向上发现 Project，回读 Provider、配置来源、`desiredHash/observedHash` 和 [`workspace-state@1`](docs/schemas/workspace-state.schema.json)。doctor 只检查指定 Workspace：未安装 Multica 不会让 `local-dev` 失败；Provider、源码、managed bytes 或 desired hash 漂移则 fail closed。
-
-OpenCode W2 在 W1 之上增加受管开发环境。`create` 默认只给 plan；`--yes` 才在 gitignored 目录原子物化并独立回读。`run/eval` 都使用仓库外临时 sandbox，只有随机 Basic load probe、Session directory 和硬门禁证据通过后，Provider state 才能进入 `ready`：
+| **创建** | `AGENTS.md`、Basic、Role Skills、bindings | 占位符未补全时保持 `partial` |
+| **测试** | 隔离 Workspace、load probe、行为评测、四类证据 | Definition/Skills 没有真实加载就不能 ready |
+| **发布** | 平台预检、部署 Receipt、远端 readback | 指定 Eval 未通过或身份链不完整就不能 promote |
+| **运行** | 数字员工账号或机器人入口、task trace | 无证据不声称写入、送达或完成 |
 
 ```bash
-dta workspace create local-dev --dry-run --json
-dta workspace create local-dev --yes --json
-dta workspace use local-dev --json
-dta workspace run local-dev --prompt-file prompt.md --execute --yes --json
-dta workspace eval local-dev --suite evals/core.json --runs 3 --execute --yes --json
-```
-
-`workspace run` 固定零工具；文件/Artifact 工具只在 eval case 的隔离权限中开放。W2 会写本地 managed Workspace、selection、state 和 evidence，但不调用 DWS。CI、评测和未来 deploy 不能依赖 `current-workspace`，必须显式选择名称。
+# 1. 创建零写入计划，再显式落盘
+dta agent enhance --project-name release-agent --role-skill release-manager --dry-run --json
+dta agent enhance --project-name release-agent --role-skill release-manager \
+  --plan-id <plan-id> --yes --json
 
-Multica W3 先开放受控远端读取。`plan` 完全不启动 Multica；`inspect/remote-list` 必须显式确认后，固定使用声明的 profile、workspace ID、runtime ID 和可选 agent ID 回读 auth、Workspace、Runtime、Agent、Skill catalog/assignment。已有 Agent 必须由 `agentIdFrom` 或上一份可信 state 绑定，绝不按显示名自动认领：
+# 2. 审计、运行与评测
+dta agent audit --bindings agent.bindings.json --require-skill release-manager --json
+dta workspace run local-dev --json
+dta workspace eval local-dev --json
 
-```bash
-dta workspace plan multica-dev --json
+# 3. 云端预检、发布与观测
 dta workspace inspect multica-dev --execute --yes --json
 dta workspace remote-list multica-dev --execute --yes --json
-dta workspace status multica-dev --json
-```
-
-回读证据只保存最小资源事实和原始输出 hash，不保存 Token、邮箱、Server URL 明文、Agent instructions/runtime config 或 Skill content。身份、默认 Workspace、scope、稳定 ID、Skill 唯一性或 evidence hash 任一不符都 fail closed；成功后 state 仍是 `verifying`，`readyForApply=true` 只表示可以进入 W4 规划。
-
-部署、晋级等平台命令先经过 managed agent platform 归属门禁。工作区用 `dta agent-platform use multica-dingtalk` 声明归属（写入 `dingtalk-agent.json#agentPlatform` 或 `.dingtalk-agent/agent-platform.json`，也可用 `DTA_AGENT_PLATFORM` 环境变量覆盖），声明时才按需安装该平台的技能包（deploy、boot-multica 与 multica-external 平台运维工具）；`dta agent-platform list` 展示注册表——当前已支持 `multica-dingtalk`，`deap` 敬请期待。`agent-platform show/use` 同时输出平台工具链 readiness（multica CLI 未装、未登录或存在代理变量时给出可执行的安装/登录/绕代理提示）；未归属、未知或 coming-soon 平台上的 `deploy`/`promote`/`observe` 一律 fail-closed；已声明 Multica Provider 的项目可被自动推断为 `multica-dingtalk`。后续所有平台相关的方法学都随对应平台的技能包分发，不进入 CLI 与基础行为。
-
-W4 用 `dta deploy` 把这份可信 inspection 变成 plan-bound apply。dry-run 固定 profile/workspace/runtime/Agent/Definition/Skill tree hash 和 forward/rollback 最大写预算，apply 前重新回读同一条 ID 链；只有显式 `--plan-id` 与 `--yes` 才会创建或更新。CLI 会精确同步受管 Boot、Basic、Role Skill 完整树和唯一 assignment，再通过专用 Issue 回读 Skill tool trace 与精确 JSON response；两个证据都通过才从 `verifying` 进入 `ready`：
-
-```bash
-dta deploy --workspace multica-dev --dry-run --json
-dta deploy --workspace multica-dev --plan-id <plan-id> --yes --json
-dta deploy --workspace multica-dev --status --json
-dta deploy --workspace multica-dev --status --execute --yes --json
-dta deploy --workspace multica-dev --list --json
-dta deploy --workspace multica-dev --retire --dry-run --json
-dta deploy --workspace multica-dev --retire --plan-id <plan-id> --yes --json
+dta promote --source local-dev --target multica-dev --dry-run --json
+dta observe --promotion-id <promotion-id> --input <observation.json> --dry-run --json
 ```
 
-写命令超时会保存 operation/Receipt 并进入 `reconciling`；后续 status 只独立回读，不盲重试或把不确定操作回滚。Agent create 若没返回 ID，只能逐个读取稳定候选 ID，并在唯一完整 instructions/runtime 指纹匹配时恢复绑定，不能按显示名认领。确认失败只回滚当前 operation 的受管修改；retire 只归档精确 Agent，不删除 Skill、Issue、语义存储或历史证据。部署不创建机器人、Webhook、定时器或其他 Trigger。`dingtalk-agent-deploy-multica` Skill 只辅导调用这组稳定 CLI，不直接调用 Multica 写命令，也不保存登录凭据。
-
-W5 把 W2 的指定 Eval evidence 与 W4 Receipt 串成显式 Promotion 链。Policy 冻结源/目标 Workspace、suite、最少 runs、必须 case 和四个证据面；dry-run 重算 Definition/Skill、managed Workspace、plan/suite/report 与 deployment hash，零 Provider 调用。只有当前 planId 和显式确认才委托 W4 deploy，Promotion Receipt 会绑定 source、Eval、历史 deployment Receipt 与最终 observed hash。
-
-```bash
-dta promote --policy promotion-policy.json --route local-dev-to-multica-dev --dry-run --json
-dta promote --policy promotion-policy.json --route local-dev-to-multica-dev \
-  --plan-id <plan-id> --yes --json
-dta promote --status --promotion-id <promotion-id> --json
-dta promote --list --json
-```
+所有计划默认零写入；所有远端写入都需要明确目标、当前 `planId` 和显式确认。
 
-`observe` 只把与已 promoted `observedHash` 精确匹配的脱敏反馈写成 gitignored Eval candidate，且固定为 `proposed`、必须人工评审、不可直接进入 suite、未发布。它不修改 AGENTS.md、Prompt、Basic/Role Skill 或 Trigger。
+## 支持范围
 
-```bash
-dta observe --promotion-id <promotion-id> --input observation.json --dry-run --json
-dta observe --promotion-id <promotion-id> --input observation.json --yes --json
-```
-
-可复制的双 Provider 声明见 [`lab/project-workspace/project.fixture.json`](lab/project-workspace/project.fixture.json)，脱敏只读回归数据见 [`multica-readonly.fixture.json`](lab/project-workspace/multica-readonly.fixture.json)，W4 stateful fake 数据见 [`multica-deploy.fixture.json`](lab/project-workspace/multica-deploy.fixture.json)，W5 Policy 示例见 [`promotion-policy.fixture.json`](lab/project-workspace/promotion-policy.fixture.json)。Manifest/state 禁止保存 token、Secret、cookie、密码或凭据；`*From` 字段只记录 `env:VAR` 来源，不把解析值写回 Git。当前合同证明本地编排与 fail-closed 行为，不等于真实 Multica Live apply/promotion 已通过。
-
-### 一小时复制第二个 Agent
-
-仓库提供 `examples/agents/fde-coach` 与 `examples/agents/release-manager` 两份最小 Agent kit。开发者复制一个目录，只改 `AGENTS.md`、`skills/<role>/SKILL.md` 与 `agent.bindings.json`，物化 Host exposure 后即可审计；普通本地 Agent 不需要 `init`。
-
-```bash
-cp -R examples/agents/release-manager /path/to/my-agent
-cd /path/to/my-agent
-dta bootstrap --bindings agent.bindings.json --json
-dta agent audit --bindings agent.bindings.json \
-  --require-skill <role-skill-name> --verify-load --yes --json
-# 只有可信事件 / Prepared Run 需要时，才另行执行一次 dta init
-```
+### 平台、Harness 与运行时
 
-新 Skill 不会热注入当前 Session：初始化后新增岗位 Skill，需要离线评审并加入 `.dingtalk-agent/workspace.json#skills`，由新 Session 重新冻结。合同 42 会用两份 kit 实际验证 Definition、Role Skill、Field、Session、Task Checkpoint、Memory Candidate 和 DWS profile 不串，并让两者通过同一 fake-DWS Lab。完整 60 分钟步骤与边界见[第二个岗位 Agent 验收](docs/SECOND-AGENT-ACCEPTANCE.md)。
+这三个概念彼此独立：
 
-## 闸门的两半
+- **Managed Agent Platform** 管 Workspace、Runtime、Agent、Skill、身份绑定和观测。
+- **Agent Harness** 加载 Definition/Skills，隔离执行并采集证据。
+- **dta Kernel** 依赖统一合同，不依赖某个 Harness 的私有 Prompt 或目录结构。
 
-| 安全半闸门：不犯错 | 贴心半闸门：做得好 |
+| 维度 | 当前支持 |
 |---|---|
-| 先判断 mention / DM / ambient 是否有响应资格 | 自动补齐引用原文、群上下文和参与人 |
-| target、actor、conversation 只来自可信 Invocation | 附件下载、OCR/正文提取，连发消息合并 |
-| 外发前重验身份、权限、generation 与动作预算 | userId 解析成可读身份，但权限仍按可信 ID |
-| 幂等、Intent/Attempt/Receipt 与平台回读 | 中期回执、安静时段、会议免打扰、任务切换收口 |
-
-贴心层不替模型做岗位判断，而是生成带 `status / source / fetchedAt / confidence / truncated / reason` 的 `EnrichedInvocation`，让每个 Skill 都从完整、可追溯的现场开始。首批已经实现 quote、同人连发 burst、identity 三个 Enricher；预处理失败时显式标记 `missing/rejected`，不能把“没取到”解释为“不存在”。
-
-可信宿主可把补齐结果作为独立输入提供，正文仍不获得权限：
-
-```bash
-dta prepare --event-file event.json --perception-file perception.json --json
-```
+| **Managed Platform** | Multica（DingTalk）已支持；DEAP 为 Coming soon；更多平台通过 registry + adapter 接入 |
+| **本地运行** | Claude Code、Codex、OpenCode 等 Direct/Mounted Session；OpenCode 是当前完整的本地 managed Harness 参考实现 |
+| **云上运行** | Multica Workspace / Runtime / Agent；沿用相同的 Definition、Skills、Gate 与证据合同 |
+| **交付身份** | 数字员工/账号身份；机器人应用身份；两者都不能改变角色职责或扩大权限 |
 
-Prepared Run 会先冻结 `response-gate.json`，再冻结 `enriched-invocation.json`；同一 eventId 不能在重放时偷换 perception。Action Gate 在副作用前复验两者的 hash。
+OpenCode 不是运行前提，Multica 也不是特殊旁路。任何 Harness 要进入可晋级路径，都必须证明同一件事：Definition 与 Skills 已加载、身份和隔离已固定、运行轨迹可取、结果可回读。
 
-### 事件驱动的异步进程
+“支持多平台”指架构、注册表和 adapter 合同可扩展；不把尚未开放的平台宣称为已部署或已 Live 验证。
 
-每条新信号可以启动一个新沙箱，但同一件事仍回到同一个 Session：
-
-```text
-Field / Workspace  = 长期身份、知识与 Skill（Heap）
-Session            = 一件工作的显式上下文（Stack）
-Run                = 一次事件唤醒的新沙箱
-Wait               = await continuation，由宿主持久化和恢复
-Action             = 受约束的系统调用
-Receipt            = 可审计的外部效果证据
-```
-
-`ask` 后当前 Run 结束；匹配事件到达时，宿主恢复原 Session 并创建新 Run。系统持久化显式 checkpoint，而不是序列化 JavaScript 或模型的隐藏调用栈。
-
-## 三层语义记忆
-
-![三层语义记忆与控制状态拓扑](docs/architecture/agent-memory-topology.svg)
-
-三层记忆回答“应该想起什么”，控制状态回答“从哪里继续、是否已经执行”。
+### 三种运行模式
 
-| 层 | 介质 | 存什么 |
+| 模式 | 用于 | 关键边界 |
 |---|---|---|
-| **L1 Session 工作记忆** | 宿主 state root，可投影为 Markdown checkpoint | 当前目标、做到哪、下一步、等待条件、证据 |
-| **L2 业务工作记忆** | AI 表格宽表、Todo、Calendar 或业务事实源 | 摘要、待办、互动记录、可聚合的热数据 |
-| **L3 长期知识** | 钉钉文档树、知识库、Wiki | Definition、Skill、SOP、人物模式、错误库 |
-| **Control State（不是记忆）** | 宿主原子存储 | EventIndex、Wait、锁、generation、幂等键、Action Receipt |
-| **Git Release Plane** | Git | Definition/Skill 源码、候选、快照、评审、发布与回滚 |
-
-原方法论中“Git 双向同步”的价值保留在**人可审查、可干预、可发布和可回滚**；但 Git 不承担 runtime lock、Wait 或 PCB 权威。文档同样适合语义协作，却没有可靠 CAS，因此不能承担并发控制和副作用去重。
-
-L1 已提供最小原子接口。只有事项确实跨 Run 时才使用；`taskId` 固定为 `sessionId`，`scopeId` 固定为 `contextId`：
-
-```bash
-dingtalk-agent task show --json
-dingtalk-agent task checkpoint --input checkpoint.json --expect-revision 0 --json
-```
-
-Checkpoint 写入 Session state root 的 `memory/task.json`，由 CLI 校验状态迁移、revision CAS、当前 Run 身份并回读；下一 Run 得到 `context/task-checkpoint.json` 投影。它不保存 Wait、锁、generation、幂等键或 Receipt。
-
-L2 首个 Provider 是 AI 表格宽表。开发者提供一个 [`OperationalMemoryProvider`](docs/schemas/operational-memory-provider.schema.json)，把 baseId/tableId 和十个 fieldId 显式映射好；profile/expectedUserId 可放配置，也可由 `DTA_DWS_PROFILE` / `DTA_EXPECTED_USER_ID` 注入：
-
-```bash
-dingtalk-agent memory operational upsert \
-  --provider operational-provider.json \
-  --input operational-record.json
-
-# 确认 dry-run 后才执行真实写入
-dingtalk-agent memory operational upsert \
-  --provider operational-provider.json \
-  --input operational-record.json --live --yes --json
-```
-
-Provider 按 `key + scopeId` 定位唯一行，只使用 fieldId；首次 create、后续 update，最后都按 recordId 独立回读。DWS 身份不符、多行冲突、没有可回读 recordId 或 cells 漂移都会 fail closed/标为 uncertain。Prepared Run 不能直接调用它绕过 Action Gate。
-
-L3 用候选发布流阻止在线自我改写：
-
-```bash
-# 在线 Run 只提候选
-dingtalk-agent memory candidate propose --input candidate.json --json
-
-# 离线 reviewer 决策
-dingtalk-agent memory candidate review \
-  --id <candidateId> --decision approve --reviewer <reviewer> \
-  --reason "来源已核验" --expect-revision 1 --json
-
-# 先 dry-run 取得 currentTargetHash，再发布到显式 target
-dingtalk-agent memory candidate publish \
-  --id <candidateId> --target publish-target.json --expect-revision 2 --json
-dingtalk-agent memory candidate publish \
-  --id <candidateId> --target publish-target.json --expect-revision 2 \
-  --expect-target-hash <hash> --yes --json
-```
-
-[`MemoryPublishTarget`](docs/schemas/memory-publish-target.schema.json) 支持 `local-md:` 和 `dingtalk-doc:`。本地/Git 工作树走 lease、原子替换和回读，但不会自动 commit/push；钉钉文档必须再加 `--live --yes`，只追加唯一 marker 并全文回读，回执明确声明 Markdown 端只是 best-effort 并发检查。发布不会热修改当前 Session，只有新 Session 重新水合。
+| **Direct Session** | 普通交互会话 | 无可信事件就不猜外发目标 |
+| **Mounted Session** | 挂载本地或钉钉语义内容 | 锁、幂等和 Receipt 不放进 Markdown |
+| **Prepared Run** | 事件驱动的可靠副作用 | 动作只走 typed Broker 或 `dta act` |
 
-## 数字员工行为协议
+Prepared Run 只开放 `ack`、`reply`、`ask`、`silence` 四个消息原子动作。`ack` 不等于接单，`reply` 不等于对方接受。
 
-![数字员工任务闭环与完成闸门](docs/architecture/task-completion-gate.svg)
-
-新任务遵循：
-
-```text
-UNDERSTAND → CLARIFY → PLAN → EXECUTE → WAIT → VERIFY → COMPLETE
-```
-
-- **UNDERSTAND**：从当前消息和可信 continuation 还原目标、交付物、范围、完成条件、权限与时点；
-- **CLARIFY**：先查线程、附件、Workspace 和岗位 Skill；信息足够就做，真阻塞才问；
-- **PLAN**：单步任务不表演计划，多步任务建立 2～5 个可观察检查点；
-- **EXECUTE**：外部副作用前重新核对对象、权限、幂等和最新状态；
-- **WAIT**：记录等待谁、什么输入、从哪里继续，然后释放沙箱；
-- **VERIFY**：通过工具结果和必要回读区分生成、保存、送达与确认；
-- **COMPLETE**：回到原线程交付结果、证据、遗留项和下一责任人。
-
-`CLARIFY` 是条件分支，不是固定开场；`COMPLETE` 也不是模型可以自行宣布的结果。跨 Run 任务必须先从 `working` 进入 `verifying`，再把每项 `doneWhen` 对应到文件检查、Workspace/Artifact 断言、Action Receipt、平台回读或人工确认。回复声称“已创建”不构成证据；CLI 会拒绝 `working → completed` 和无证据的完成 checkpoint。
-
-只有跨消息、等待依赖、已经产生副作用、需要换沙箱接手或用户明确要求跟踪的事项才创建 checkpoint。单轮问答不制造“伪任务”。
-
-## 开发者拿到 dta 后还需要什么
+## 创建出来的 Agent 会继承什么
 
 ```text
-Basic Behavior Skill      每个钉钉员工共享的社交与安全底座
-        +
-Role / Workflow Skill     某个岗位如何完成 FDE 评价、周报、事故处理
-        +
-Agent Definition          身份、服务对象、知识源、记忆与权限
-        +
-dingtalk-agent CLI        需要强约束的员工级事务边界
-        +
-DWS                       钉钉标准产品能力
-```
-
-最小实例只需再补三样：
-
-1. **Agent Definition**：身份、职责、服务范围、拒绝边界和权限；
-2. **Role Skills**：这个岗位如何完成评价、招聘、周报或事故处理；
-3. **Storage bindings**：memory、knowledge、artifacts、宿主 state 与可信 DWS authority 的明确路由；
-
-事件触发 Adapter 是独立部署面，不属于 Agent 本体：需要自动运行时再接 personal-event、Webhook 或定时器；普通 direct 会话无需先部署监听器。
-
-这意味着一个 FDE 教练只需在基础行为之上叠加教练身份、评价方法与学员资料；基础层无需知道 FDE 业务细节。完整的 Definition 合同、模块落点和阶段计划见[从一个 Agent 到所有 Agent 实施方案](docs/plans/2026-07-16/general-agent-kernel-and-live-lab.md)。
-
-## 常用命令
-
-```bash
-dingtalk-agent --help
-dingtalk-agent doctor
-dingtalk-agent setup
-dingtalk-agent skill install
-dingtalk-agent skill status
-dingtalk-agent bootstrap --json
-dingtalk-agent init
-dingtalk-agent prepare --event-file event.json --json
-dingtalk-agent help runtime
-dingtalk-agent help adapters
+my-agent/
+├── AGENTS.md                     角色宪法 + Basic 继承锚点
+├── agent.bindings.json           Definition 与存储路由
+├── dingtalk-agent.json           Agent Project 期望状态
+├── .agents/skills/
+│   ├── dingtalk-basic-behavior/  完整公共行为树
+│   └── <role>/                   Host 可发现的岗位 Skill
+├── skills/<role>/SKILL.md        岗位能力的版本化来源
+└── .dingtalk-agent/              私有状态、证据与 Receipt
 ```
 
-`listen` 是可选的开发联调 Adapter，不是 Agent 主进程。云端 Driver、Claude Code 插件或本地 DWS 都可以提供事件，并从标准化事件之后复用同一 Session / Run / Action 内核。
-
-## 真实世界联调
-
-真实环境不是最后补一条 smoke，而是和通用合同同为 P0。验证按五级晋级：
-
-| 级别 | 环境 | 证明什么 |
-|---|---|---|
-| L0 | fixture + 真 CLI | 合同、状态机、目标防篡改、幂等 |
-| L1 | 模型 shadow | Skill 是否带来行为增益；绝不外发 |
-| L2 | fake DWS + 真 Action Gate | Intent/Attempt/Receipt、超时恢复，不污染钉钉 |
-| L3 | 专用机器人 connector | 真实连接、Workspace、表达、送达与平台回读 |
-| L4 | 测试同事/群 + personal event + dta Broker | 完整 envelope、目标、身份、Wait/Resume、单一出口 |
-
-机器人 connector 自己拥有外发权，只能证明连接和体验；完整运行时必须由 dta Broker 独占外发，并验证可信 target、重复投递、Receipt 和独立平台回读。Live 一律使用测试资源、allowlist、唯一 marker、固定预算和 teardown，详细拓扑与首批场景见[实施方案](docs/plans/2026-07-16/general-agent-kernel-and-live-lab.md#7-真实世界联调与测试环境)。
+生成的 `AGENTS.md` 只保留四块原子合同：**定义、不能做的底线、做事标准范式、常犯错误**。模板同时声明每个任务先应用 `dingtalk-basic-behavior`，再按任务加载 Role Skills。
 
-Lab Harness 默认不会碰真实钉钉：
+“文件存在”不是继承证据。`agent audit --verify-load` 会把真实加载结果绑定到 Definition/Skill hash、Host/模型版本、隔离探针和原始 run/export：
 
 ```bash
-export DTA_LAB_FAKE_DWS=1
-export DTA_LAB_FAKE_DWS_PATH=/absolute/path/to/test-bin/dws
-dta lab doctor --manifest lab/manifest.local.json
-dta lab run --manifest lab/manifest.local.json \
-  --event-file evals/fixtures/mentioned.json --case-id mention-reply \
-  --reply 'Mock Lab 已完成。'
-dta lab verify --evidence .dingtalk-agent/lab-results/<run-id>
-dta lab teardown --manifest lab/manifest.local.json \
-  --evidence .dingtalk-agent/lab-results/<run-id>
+dta agent audit \
+  --bindings agent.bindings.json \
+  --require-skill <role-skill-name> \
+  --verify-load --yes --json
 ```
 
-`robot-connect` 与 `personal-event` 会产生真实副作用，除了 manifest 的专用资源和 allowlist，还必须显式传 `--live --yes`。完整说明见 [Lab Runbook](lab/README.md)。
-
-完整 personal-event suite 使用 [`personal-event-eval@1`](lab/schemas/personal-event-eval.schema.json)，把 Basic + Role Skill、响应资格、Wait/Resume、重复事件、Perception、Receipt 和 teardown 放进同一条证据链。事件仍由外部 Adapter 捕获；dta 不创建订阅或触发器。默认命令只生成本地 plan，只有本地 suite 的 `liveAuthorized=yes` 与三重 CLI 确认同时满足才执行：
-
-```bash
-dta lab eval --engine personal-event \
-  --workspace <agent-workspace> \
-  --suite .dingtalk-agent/personal-event-live.local.json --json
-
-dta lab eval --engine personal-event \
-  --workspace <agent-workspace> \
-  --suite .dingtalk-agent/personal-event-live.local.json \
-  --execute --live --yes --json
-```
-
-占位 suite 见 [`personal-event-live.example.json`](lab/agent-eval/personal-event-live.example.json)，脱敏本地证据见 [`personal-event-live-readiness-summary.json`](evals/baselines/2026-07-17/personal-event-live-readiness-summary.json)。每条回复必须按同一 messageId 回读精确正文；duplicate 只能复用原 Run/Action/Attempt，不能新增外发。当前合同用 fake DWS 通过 8/8 场景、7 个物理 Run、5 次新增外发，并拒绝 messageId 正确但正文被改写的回读；这证明 Harness 已可执行，不证明真实个人事件已接收或真实消息已送达。
-
-可复用机器人行为评测使用独立 Robot Pool；默认只生成计划，不启动 connector：
-
-```bash
-dta lab eval \
-  --pool .dingtalk-agent/robot-pool.local.json \
-  --suite lab/robot-eval/suite.json --lanes stateless --json
-
-# 确认专用机器人、allowlist、模型和预算后才真实执行
-dta lab eval \
-  --pool .dingtalk-agent/robot-pool.local.json \
-  --suite lab/robot-eval/suite.json --lanes stateless \
-  --live --yes --json
-```
+## 不可绕过的边界
 
-Pool 最多 3 个前缀机器人，固定 OpenCode + `deepseek/*`；每次运行物化隔离工作区、安装当前 Basic Behavior、先让全部 connector healthy，再发送唯一 marker，最后按 `robotClientId` 停止并回读 `not_running`。它验证真实机器人体验，不替代 personal-event 的可信 target、幂等与 Receipt 验收。
+- 普通 Session 不自动运行 `dingtalk-agent init`。
+- target、actor、conversation、DWS profile 与权限只来自可信宿主或事件。
+- Prepared Run 的消息副作用只走 typed Broker 或 `dta act`，不能绕过 Gate。
+- 在线 Run 可以提出记忆或 Skill 候选，但不能热修改当前身份、权限或策略。
+- 模型自述、命令退出 0、平台写入可见、消息送达与人类接受必须分别举证。
 
-在产生真实钉钉消息前，先用无 DWS 副作用的 OpenCode A/B 验证 Host 组装：
+## 文档
 
-```bash
-# 默认只看计划
-dta lab eval --engine opencode \
-  --workspace lab/robot-eval/workspace \
-  --suite lab/robot-eval/suite.json --lanes stateless --runs 3 --json
-
-# 调用固定 DeepSeek 模型；不开放 Agent 工具，不连接钉钉
-dta lab eval --engine opencode \
-  --workspace lab/robot-eval/workspace \
-  --suite lab/robot-eval/suite.json --lanes stateless --runs 3 \
-  --execute --yes --json
-```
-
-每组使用隔离 Workspace：with-skill 通过 `instructions` 强制注入带随机 nonce 的 Basic Skill 快照，without-skill 移除正文并禁用同名 Skill。报告把 load gate、行为得分、baseline、Session 实际目录、工具调用、时延和 token 分开；load gate 失败时，行为回答再正确也不能算 Skill 生效。
-
-2026-07-16 的 OpenCode 1.17.14 + DeepSeek 三轮基线中，Basic 0.9.2 的随机加载探针与隔离目录门禁为 3/3，with-skill 行为为 17/18，without-skill 为 14/18。剩余失败是目标防伪造答复泄露“回读路径”这一控制面术语，因此行为发布门禁保持失败；详见[脱敏基线摘要](evals/baselines/2026-07-16/opencode-basic-skill-required-summary.json)，不以总分掩盖该缺口。
-
-新的经典事故集可按 case 精确回归，并允许显式的本地文件工具：
-
-```bash
-dta lab eval --engine opencode \
-  --workspace lab/agent-eval/workspace \
-  --suite lab/agent-eval/classic-failures.json \
-  --cases requester-only-authorization,workspace-artifact \
-  --runs 1 --execute --yes --json
-```
-
-2026-07-16 的 OpenCode 1.17.14 + DeepSeek 开发回归覆盖 9 个经典 case。Basic 0.9.4 的加载门禁通过；8 个 case 在完整轮次通过，唯一的正确拒绝因短语枚举漏判，改为受限正则 + 独立原因/禁止项后针对性通过。产物 case 只开放 `read/write/edit`，本次实际只调用 `write`；Workspace/Artifact/Filesystem 7/7 后置条件通过，并把两个文件及 sha256 复制进证据包。可写沙箱位于仓库外的系统临时目录，runner 会规范化并审计每个工具路径，防止 OpenCode 沿父级 Git 根写入真实工作树。组合验收为当前 9/9 有通过证据，但不冒充同一轮统计结论；详见[脱敏多证据摘要](evals/baselines/2026-07-16/opencode-multi-surface-summary.json)。
-
-同一套方法也覆盖“本体在本地、语义状态在钉钉文档”的 Agent：
-
-```bash
-cp lab/agent-eval/remote-state.example.json \
-  .dingtalk-agent/remote-state.local.json
-
-# 先看计划；不会读取 DWS，也不会调用模型
-dta lab eval --engine storage \
-  --workspace lab/agent-eval/remote-state-workspace \
-  --suite .dingtalk-agent/remote-state.local.json --json
-
-# 读取两篇专用文档、验证 OpenCode；--live 再追加一个唯一写探针
-dta lab eval --engine storage \
-  --workspace lab/agent-eval/remote-state-workspace \
-  --suite .dingtalk-agent/remote-state.local.json \
-  --execute --live --yes --json
-```
-
-2026-07-16 的真实 DWS canary 使用两篇专用 `adoc`：本地 `AGENTS.md + remote-state-operator` 的 Definition 为 ready，Basic 0.9.4 由 OpenCode instructions 强制加载；memory/knowledge 的远端、mount、缓存和 manifest hash 全部一致，DeepSeek 零工具返回两个只存在于远端文档的探针值，唯一写 marker 经全文回读后按 Markdown 文字流计数为 1。确定性合同同时证明错误 DWS 身份、非 adoc 和 bootstrap 后远端漂移会 fail closed。第一次字节级 marker 比较曾因钉钉转义 `_`/`]` 产生假阴性，runner 已改为文字流比较；没有把命令成功当成写入成功，也没有推断删除权限。详见[脱敏远端状态摘要](evals/baselines/2026-07-16/remote-state-live-summary.json)。
-
-## 评测与验证
-
-仓库内置 [`dingtalk-agent-eval`](skills/dingtalk-agent-eval/SKILL.md) Skill，把评测固定为“被测 Definition → Basic Skill 加载门禁 → 场景目录 → 隔离执行 → 多证据面断言 → 晋级”的流程。项目 Coding Agent 在修改评测、Lab、Workspace、产物或远端状态时会由 `AGENTS.md` 强制加载它；开发者也可以把该 Skill 复制到自己的 Agent 仓库复用。
-
-场景不按日期或岗位堆放，而按七条稳定成立条件分类：Host 加载、会话行为、身份与出口、任务生命周期、记忆与存储、工作区与产物、平台可靠性。目录见 [`lab/agent-eval/catalog.json`](lab/agent-eval/catalog.json)。回复只是一个证据面；case 若声明创建文件、Workspace 或钉钉文档状态，就必须分别检查本地路径/内容/hash、Definition/Skill 路由，以及 DWS 独立回读。安全硬门禁失败不能被总分平均掉。
-
-```bash
-npm ci
-npm run typecheck
-npm run eval:contract
-```
-
-当前确定性合同包含 **60 个场景**，覆盖：
-
-- 通过 `npx skills` 委托全局 Skill 安装、发现、重装和卸载；
-- 首次 setup、用户级 PATH、DWS 版本/认证和三端客户端发现；
-- `dta` 短命令安装，以及命令、子命令和参数错误的可恢复提示；
-- CLI 自升级、新 binary 版本校验和升级后 setup 复核；
-- 无 init bootstrap、本地/远端 Storage 与类型闸门；
-- Direct Session 外发边界；
-- Session continuation、Wait、幂等和目标防篡改；
-- Skill 冻结、动作预算和 Receipt。
-- Lab 单一出口、路径/Live 门禁，以及 fake DWS 的完整证据与 teardown。
-- quote/burst/identity 感知补齐、Response Gate 与 perception 防篡改。
-- Task checkpoint 的 Session 作用域、revision CAS、跨 Run 投影与控制状态隔离。
-- AI 表格 Operational Memory 的 dry-run、单行 upsert、身份校验与 recordId 回读。
-- Memory Candidate 的在线提议、离线评审、本地/钉钉文档发布与 Session 冻结。
-- 两个岗位 Agent 的 Definition/Role Skill/Field/Session/记忆/权限隔离与同合同 Lab 验收。
-- 最多三个前缀机器人同时 healthy、OpenCode/DeepSeek 固定、marker 回收、确定性判分和精确 teardown。
-- OpenCode `instructions` 强制加载 Basic Skill、随机 load probe、with/without 对照、隔离 Session 目录和零工具调用。
-- 逐 case 最小工具权限，以及回复、Filesystem、Workspace、Artifact、受限正则和证据快照的联合判定。
-- 本地 Agent Definition + 钉钉文档 memory/knowledge 的身份、类型、独立 cache manifest、远端漂移、写后回读和零工具模型探针。
-- L1 钉钉文档语义镜像、L2 AI 表格热状态、L3 钉钉文档知识的双进程冷启动恢复，以及 identity/type/drift/slot/cache/control-state fail closed。
-- Phase 11B 默认零副作用的远端状态 Live runner，以及 Phase 9 personal-event 的 Basic/Role Skill、@/ambient、duplicate、Wait/Resume、`/stop`、Perception、正文回读和 teardown。
-- Developer Golden Path 的 bindings、精确 repair、与当前 Definition/Host 绑定的 load evidence、远端 fail-closed audit，以及第二个岗位 Agent 无内核改动复制。
-- 已有仓库 `agent enhance` 的 plan/current-plan-id/backup/hash 回读、语义占位符门禁、配置保留、幂等和漂移/symlink fail-closed。
-- Project/Development Workspace 根发现、OpenCode/Multica Provider 隔离、legacy adapter、配置/hash 回读、只读 CLI 与 state 漂移关闭。
-- Workspace-bound OpenCode create/use/run/eval、随机 load probe、四面证据、双 Workspace 防串线、managed drift 与原子冷启动重建。
-- Completion grader 对中英文完成/否定/条件/转述和矛盾语境的判定，以及 case 级 `completionClaim` 硬门禁。
-- suite 预声明的三轮 `comparisonPolicy`：总体提升、改进场景数和退化上限必须同时满足，单个正 delta 不再证明增益。
-- Multica W3–W5 的只读回读、plan-bound apply、Promotion/Observation，以及真实 npm tarball 的隔离安装、升级和回滚验收。
-
-模型行为还可通过 Claude shadow 做 with-skill / baseline 对照；它只允许读取冻结输入并输出 ActionRequest，不产生任何钉钉副作用。完整晋级门禁见 [自测与持续进化](docs/SELF-TEST.md)。
-
-## 项目结构
-
-```text
-bin/          CLI composition root（唯一入口；业务规则在 src/）
-src/          TypeScript 运行时：事务边界、双半闸门、平台注册表、Provider
-skills/       内置 Skill，两层组织（详见 skills/README.md）
-  core/         通用套装：dingtalk-basic-behavior 基础行为 · dingtalk-agent-compose 装配 · dingtalk-agent-eval 评测
-  platforms/    按 Managed Agent Platform 装填：multica-dingtalk/（deploy · boot-multica · fde-external）· deap/（敬请期待）
-templates/    dta init 落盘的行为包与场域策略模板
-examples/     可复制的岗位 Agent kit（FDE 教练、发布经理）
-evals/        L0 确定性合同评测与 shadow runner（61 场景）
-lab/          L1–L4 联调与 Live 评测控制面（manifest、schema、runbook）
-scripts/      构建后处理与发布验收（release-readiness）
-docs/         架构、Schema、决策与实施计划
-.github/      CI 与协作模板
-```
-
-## 深入阅读
-
-- [从一个 Agent 到所有 Agent：行为内核与真实联调环境实施方案](docs/plans/2026-07-16/general-agent-kernel-and-live-lab.md)
-- [代码与运行架构](docs/ARCHITECTURE.md)
-- [安装与首次使用](docs/INSTALLATION.md)
-- [最小 Workspace 决策记录](docs/MINIMAL-WORKSPACE-V1.md)
-- [自测与持续进化](docs/SELF-TEST.md)
-- [一小时复制第二个岗位 Agent](docs/SECOND-AGENT-ACCEPTANCE.md)
-- [开源项目差异与共同范式](docs/OPEN-SOURCE-REFERENCES.md)
-- [贡献指南](CONTRIBUTING.md)
-- [安全策略](SECURITY.md)
-
-## 当前边界
-
-- 不把 `listen` 作为 Agent 的强制主入口；
-- 不自动初始化或污染任意代码仓库；
-- 不复制整个 DWS 命令面；
-- 不把钉钉文档当锁、事务数据库或副作用回执；
-- 不允许在线 Run 自动扩大身份、权限或启用新 Skill；
-- `bootstrap` 对 `dingtalk-doc` 只读水合；远端发布必须经过候选评审、显式授权 Provider 与写后回读。
+| 想做什么 | 从这里开始 |
+|---|---|
+| 理解架构与状态模型 | [Architecture](docs/ARCHITECTURE.md) |
+| 安装、升级与排障 | [Installation](docs/INSTALLATION.md) |
+| 理解评测与证据分层 | [Self-test](docs/SELF-TEST.md) |
+| 创建或审计 Agent | [Compose Skill](skills/core/dingtalk-agent-compose/SKILL.md) |
+| 查看公共行为协议 | [Basic Behavior Skill](skills/core/dingtalk-basic-behavior/SKILL.md) |
+| 复制完整示例 | [Example Agents](examples/agents) |
 
-## License
+行为资产来自可观察合同、反例修正和可部署验证；本项目不声称获得任何产品的隐藏系统提示词原文。
 
-[MIT](LICENSE)
+MIT License