DingTalk DSH Assistant

dingtalk-dsh-assistant 是一组运行在 DeepSeek Harness（DSH） 中的钉钉数字员工插件。它把钉钉群聊直接接入 DSH，让 Agent 不再只是等待 @ 后回答问题的机器人，而是一个能够理解完整群聊上下文、主动参与协作并持续推进任务的团队成员。

在 DSH 与 DWS 已完成安装和登录的前提下，插件接收群消息并维护话题事实。已切换到 workflow-v2 的群先拆分、关联和判断意图，再由消息事项的原生 Agent 会话完成问答；需要持续交付的工作进入 Task 与阶段编排。各项执行独立保存进度，支持查询、等待补充、恢复和交付。

插件不是独立 Agent 平台，也不自行实现第二套 Session、Agent 或任务执行引擎。Agent 身份、工作规则与可用工具由配置的工作区及其 AGENTS.md 决定，插件本身不包含个人姓名或数字分身设定。

同一事项的后续材料、点名和开发指令可以继续原话题；名称和摘要随有效信息更新，原消息及权限来源仍分别保留。看板列表与已打开详情同步刷新，历史缺失摘要显示为空。确定的历史话题误拆可在维护排空后按受管话题修复流程处理，不重跑业务命令或发送消息。

已切换群的入站门禁统一复用未变动的封存快照核验，并持续检查文件身份；追加群不再逐条消息重读完整历史快照。历史发件的替换关系使用邻接索引核对，保留环、未知目标和分叉拒绝。

每次模型调用的执行窗口由当前 Host 显式传入并从该次节点实际领取开始，不沿用旧消息 policy 的调用时限，维护和重试排队不消耗执行窗口；真实失败按 lease 计入有界恢复次数，重复扫描不重复扣次数。无业务命令且纯状态通知已独立确认送达时，也可保留通知审计后重处理。旧消息可通过本机受控接口逐条重处理。没有业务命令、全消息澄清通知已独立确认送达且答复已接纳时，恢复会保留原通知并继承答复，不重复询问；发送结果未确认或已有业务命令时仍拒绝重处理。操作及回读要求见 本地部署说明。

本地安全重启

Windows 正式启动通过 Node 原生同步模块加载，保持原始模块解析和内容；不使用诊断采样。scripts/start-web.ps1 支持显式 -ProjectRoot，持久启动文件统一部署到 DSH_HOME/launchers。

Windows 本地重启使用 scripts/restart-web.ps1 -ProjectRoot <实际主检出路径>，先加 -Check 做零副作用预检。桌面 restart-dsh-web.ps1 委托 DSH_HOME/launchers/restart-web.ps1，独立工作树交付后将正式脚本部署到该持久位置，不让桌面入口绑定临时工作树。

等待阶段先用原生监听快照和 HTTP；就绪时仍独立核验新 PID、双端口归属与健康。脚本显示初始化等待，并输出初查、排空、停机、服务就绪、恢复与总耗时；超时保留失败及维护状态，不重复启动。操作与诊断边界见本地部署说明。

从群聊机器人到数字员工

常见的群聊机器人或 Agent 接入方式通常需要被 @ 才会唤醒，只能获得当前消息附近的片段上下文，更适合问答、检索等单次工作。dingtalk-dsh-assistant 通过 DSH 原生 Session、subagent 与 Goal，把群聊协作变成可持续、可并行、可追踪的任务闭环。

与 DSH 的关系

workflow-v2 的问答与调查

普通项目、代码、数据库问答使用 answer.objective：意图节点交付问题，执行 Agent 根据需要调用受信只读工具并组织答案，普通问答不创建业务 Task。一次问答拥有独立会话，同一执行的必要补充沿用会话；话题提供事实与来源，不维持永久增长的执行上下文。慢查询不阻塞后续消息的判断。

明确要求持续排查或独立调查交付时，由同一个持久任务执行会话直接使用登记的资料、代码、只读数据库和状态查询工具，形成结果并纠正查询错误。普通调查不再注册或调度 task-investigation，不提交独立调查结果、不为读取增加阶段；只有代码开发、文件写入/交付、数据库变更及发布等受管操作使用相应阶段。

创建消息只负责持久接纳任务并返回，命令落账后唤醒原生待办扫描，不同步等待整轮调查。Owner 复用每任务单会话与租约，最多四个任务并行，完成后立即串行应用已验收动作并补充空位；后来接纳的任务可使用空位，不等旧恢复批次结束。只以数据库待办为权威，不另建内存任务队列。服务关闭取消运行并等待应用排空，重启由现有恢复计时器从原任务账继续。

Task Owner 在同一持久会话持续负责目标、诊断和调整路径；工作流提供受管操作，不因一个节点失败就自动转人工。Host 为可纠正的只读 Agent 节点提供原会话续行，Owner 先读诊断并给出改变后的做法；成功前缀、原需求与权限保持。同一输入、同一问题再次出现时停止机械重放，交负责人换路径或定位实现问题。重复无效候选只让本轮退避，仍保留恢复责任。真实审批等待和未知外部效果沿原效果账处理；内部恢复不发群进度。设计与验证边界见 持续任务执行方案。

同一 Owner 会话已完整读取的不可变工件，可依据原生成功工具回执跨回合和重启复用；必须仍属于当前需求和阶段。新读取取得进展后可修正同一候选，重复读相同内容不算新进展。Owner 动作应用失败会保存完整诊断、已发生回执和当前计划，并反馈原会话下一轮重新选择策略；不再原样反复应用失败决定。已成功部分不回滚，已应用决定保持审计，未知效果先由原效果账对账，暂停或取消不唤醒执行。Owner 不提供工程修复或运行时流程调整能力。执行诊断交回原执行会话，按固定职责恢复失败步骤并保留成功节点；见单任务执行恢复方案。

新接纳的验收条件在消息、Web、Owner 与工程准备入口共用合同：1–32 条，每条原始长度不超过 2000 个字符，去除首尾空白后不能为空。只读工具结果由 Host 按 Task、需求版本、Owner 会话/轮次/租约保存原始证据，原生事件账支持重启读取。纯调查可以没有阶段或 Run，必须引用真实当前证据并通过逐项最终验收。受管操作的前序产物继续通过带类型、版本及生产阶段身份的 handoff 交接。退役调查的活动引用拒绝切换；已终态定义只作历史记录，不再提供兼容执行入口。

任务会话完成前核对当前需求、真实查询及受管操作证据和必交文件。Host 核验精确身份、来源、需求版本、真人批准与实际执行状态，再共享一次最终业务语义验收，生成绑定当前决定及清单的 businessValidation.status=accepted 回执。没有读取、跨任务或过期证据拒绝完成；清单 complete 仅证明结构和证据绑定，不替代业务验收或外发后的独立渠道回读。调查失败在同会话纠正，内部过程静默；必要业务问题、插件私聊审批和最终结果保留。

新通用阶段 v6、外部操作 Owner v2 和文件投递 v2 均检查分派给本领域的验收项，混合流程不跳过业务检查。通用材料整理保留确定性快速路径，其他分派项使用原生模型零工具限定判断，并独立核验逐项结果及引用；缺少模型、超限、协议异常或证据不足不放行。调查沿用显式逐项意见，工程匹配冻结原需求和实际业务用例回执。工程消费者声明支持的交接类型/版本，目录结果合同从权威 Owner 合同派生。整体完成仍要求全部验收项满足，没有新增部分成功终态。

失败诊断记录恢复类别、责任方及下一步，但不新增自动重试权限；未知外部结果继续先对账。旧定义按原摘要恢复，仅完成准入采用当前修正规则；回执分别保存冻结执行摘要与实际验收 policyDigest，不补造历史回执或重跑效果。本次合同调整不需要存储 schema 迁移，受理范围、职责和恢复边界见节点合同及升级说明。协议夹具验证不等于真实模型语义质量、部署或渠道验收。

消息处理详情显示“查询与答复”的状态、耗时和会话；结果正文与依据按需分页读取。取消问答时引用本人原问题；同一原消息有多个未完成事项时，先澄清选择，再核对身份和输入版本取消选定执行。

任务产物发送到群聊

明确要求“处理完成后把报告、Markdown、SQL或图片文件发到本群”时，工作进入同一个持久 Task。意图保存逐字引用的发送要求与完整文件清单；Owner 先生成并登记产物，再安排 task-group-file-delivery。目标绑定任务来源群与配置的 DWS profile。普通问答、Web-only 任务以及只要求生成文件的任务，不因此自动外发附件。

write-task-file 可生成精确授权名称的 .md/.txt/.sql/.csv/.json 文件，UTF-8 内容最多 64 KiB。图片、Office、PDF 等传输保留真实原字节，但必须先有真实来源及已登记的产物；传输能力不提供这些格式的生成器，不能把文字改扩展名当文档。图片首版以可下载文件附件发送，不承诺聊天气泡预览。SQL 脚本交付不执行 SQL。

已有文件可通过 import-task-file 纳入当前 Task：Host 在 workflow.generalFileRead 配置固定 root 和精确 readablePaths，Owner 输入仅为 {role,fileName,relativePath}，同时受当前任务的角色/名称及 readableFiles 授权约束。Host 只读真实来源后冻结大小/SHA-256，执行时再次核对并复制原字节到受管快照；Owner 不提供绝对根或猜摘要。导入保留真实扩展名，不能靠改名转换格式。Office、PDF、图片已有可信文件时可直接登记交付；没有源文件时仍需实际生成器。

新任务的受管快照位于 /tasks//outputs///；升级前已有任务仍使用 workflow.artifactDirectory/task-files///。快照保留中文可读名称、需求版本、生产者和 SHA-256；文件元数据独立读回，二进制不塞入 JSON。当前 Host 默认每文件 20 MiB、每批 50 MiB、20 件，这些是本地保护值，不能当作租户平台上限。全部文件先预检，再逐件通过效果账发送；ACK 后查询真实消息并下载核对大小和摘要，全部必交文件通过才允许完成。未知发送保持待对账，不能重发来消除等待。

文件发送授权必须是当前消息的精确连续原文，可含句末标点或跨句；完整源句中的否定与其他群限制仍拒绝。Owner 使用通用写入时每轮仅安排一个阶段，核验产物后下一轮追加发送。复合验收项可联合读取该项明确绑定的当前任务成功阶段证据，各领域的结构和效果仍独立校验；投递回执不能代替业务结果证明。

本节描述源码能力，正式实例须按本地部署与文件验收说明完成安装和真实渠道回读。2026-09-29，PR #142 已合并，本地正式实例已安装合并版本，并完成专用群真实文件交付验收及重启后回读；结果见最终验收报告。其他实例仍须独立完成部署与渠道验收。

一个任务一个文件目录

新任务统一使用 /tasks//：work/ 保存会话工作文件、JSON 工件、工程副本与验证记录，tmp/ 保存受管检查和验收子进程的临时文件，outputs/ 保存正式文件。逻辑任务 ID 复用现有任务关系；Web 重执行沿用同一个根目录，内部任务、节点及执行代次各自隔离。工程旁路证据位于源码副本之外。

DSH 原始会话日志和公共附件仍由宿主管理。历史任务、工件及会话原路径恢复，不自动迁移；消息问答等非任务会话仍使用原职责目录。新 JSON 引用携带 tasks// 前缀，直接定位 work/artifacts/，无需额外索引。文件下载、发送和完成验收继续核对原有 descriptor、摘要和授权。目录约定覆盖插件受管入口；外部工具显式写入的其他绝对路径与公共缓存不因此被重定向。

升级后备份必须同时保留控制库、原工件/会话目录和 Agent 工作区的 tasks/；部署参数与回退边界见任务目录部署说明。

启用 workflow 后，在线切换 Agent 工作区会被拒绝，避免会话和工件落到不同根；同根配置及模型设置仍可更新。需要换根时先停稳并制定完整迁移方案，本次不提供自动迁移。任务备份明确排除受管工程源码副本中的可再生 node_modules，恢复后按锁文件重新安装依赖。

只读资源通过 workflow.directQueries 登记，由 permissions 显式声明 Agent 自身的资源授权，与发送者身份无关。不同群成员使用同一 Agent 职责范围，每次调用仍重新校验资源权限。数据库默认使用低权限只读身份；用户明确指定使用现有 UAT 账号时，仅对显式登记的 UAT 资源启用 Host 强制只读事务模式。模型始终不能获得连接凭据或提交任意 SQL。配置合同见 Agent 查询工具，切换步骤见 本地部署说明。

旧材料分析、固定规划/执行循环及逐次只读能力阶段退出新入口；切换前必须确认没有活动引用。历史记录继续按原状态读取，不重放旧命令。以下常驻主会话与叶子 Goal 说明适用于尚未切换的旧 Resident 群。

插件直接复用以下 DSH 机制：

• Session：每个群一个常驻主会话，每个 Task 一个独立叶子会话。
• subagent：主会话只协调，叶子会话独立执行任务。
• Goal：维持叶子任务的持续执行、恢复和完成状态。
• systemPrompt.section：向主会话注入群名称、群 ID、群职责与决策协议；向叶子会话注入任务流程和证据要求。
• Agent Registry 与原生 descriptor：在 DSH Web 中展示并打开常驻会话、叶子对话和轨迹。
• 默认模型、推理深度与权限 preset：由 DSH 原生服务保存和应用。
• storage domain：持久化群订阅、消息、Task、可靠投递、人工介入事项和告警。
• attachment service：将钉钉图片作为 DSH 原生多模态附件传入会话。

插件只补充钉钉渠道和群聊工作流特有的能力：DWS 订阅与补拉、消息去重排序、任务准入与关联、可靠 outbox、人工介入、任务看板和运行告警。

UAT 部署、生产发布、数据变更与 UAT 同提交重建采用显式目标白名单和受信平台端口。UAT 部署只确认精确提交在目标环境运行；业务回归、提测与验收另行记录。 普通 UAT 构建在完整同提交扫描确认流水线已失败、且无成功或进行中的等价流水线时，保留失败收据并将节点及运行收口为失败；读取异常和未决状态继续只读对账，不重发原操作。 同提交重建也核对超时前已成功构建并部分部署的精确镜像来源；整条流水线失败不抹去已验证的构建事实。生产发布在创建 Tag 前等待真人审批，并逐段核对提交到运行镜像的来源链；新数据变更 v6 的简单加列只核对准确目标、创建 Bytebase 工单并提交插件人工审批，复杂 SQL 保留 UAT 演练；Bytebase 可能在送审时创建未执行 Rollout/Task，只有插件对本次精确 SQL 真人批准后才发送执行；Bytebase 平台审批状态不作为插件批准，生产验收通过只读连接独立回读。配置、平台只读检查与执行后回读的要求见本地受信平台接入说明；缺少任何必要能力时，流程目录保持不可发起。

DWS 群消息
→ dingtalk-dsh-assistant
→ DSH resident 主 Session（判断、沟通、协调）
→ DSH leaf Session + Goal（独立执行）
→ 主 Session（组织结果）
→ outbox + DWS 回读确认
→ 原群引用回复并 @模型从任务历史选出的相关参与人

不依赖 Agent Studio，也不要再并行启动另一套会话或任务 Runtime。

包结构

• packages/dingtalk-dsh-assistant：核心业务插件。负责 DWS 接入、群与 Session 绑定、消息处理、Task 调度、阻塞时的人工介入、可靠回复和配置页面。
• 任务表格同步：可在插件设置中绑定钉钉在线电子表格的一个工作表，由 Resident 纯脚本每 3 分钟将全部未归档 Task 全量覆盖写入；同步不调用模型，状态与失败原因在设置页单独显示。
• packages/dingtalk-dsh-observer：DSH Web 展示扩展。提供群聊会话、任务看板、归档任务、人工介入和告警页面。
• DWS 文件卡片的监听与历史回补保留 fileId 资源；同版本消息仅允许同发送者、同文件名及同 fileId 的固定下载提示展示差异，按重复接收处理，保留原始正文与版本。其他正文或身份变化仍须可信编辑版本。

同一任务通过 Web 再次执行时，看板保持一张卡片。详情只展示当前完整计划的有效步骤与结果：保留未受影响的成功前段，重执行更新对应步骤，已移除步骤从列表删除，新增步骤按当前计划加入。不同阶段的同名步骤按工作流分组独立展示，并显示真实开始时间与本次耗时；需求变化后旧结果失效。卡片与详情使用最多32字符的简短标题，详情可展开完整任务目标；卡片内步骤列表使用中文名称及本次节点耗时。详情不提供历史切换，旧任务链接打开当前详情；完整正文、产物和当前步骤会话仍可读取。关联以已保存的重执行事件为准，不按相似标题合并。新的追加、取消、重执行和归档须携带当前执行版本；归档核对整项任务均结束且操作排空，底层运行记录保留。接口见工作流节点契约。

旧版任务归档清理开发目录前核验提交已包含在 origin 当前公布的分支中，同名分支已推进或删除不等于代码未保存；无法证明提交保留、脏代码或未登记文件仍拒绝清理。目录已移除时，缺少归档摘要的登记文档只能从准确登记提交的普通文件恢复到任务专属归档目录，不使用同名文件猜测。预检不写文件，目标冲突、缺源或摘要不符会停止。

登记后在原分支继续开发的提交必须是登记提交的后代且已保存到远端，才可归档；路径、Git目录、主库、分支和 origin 身份仍须一致。清理进度记录本次核验的实际提交，文档复制后再次固定核对该提交，期间出现新提交则停止删除。
- .dsh/profiles/resident：resident Runtime 的参考 profile 与 Cordis patch。
- .dsh/profiles/web：Web contribution 的参考 profile。
- docs/spec：关键状态机和工作流设计说明。
- test：插件单元测试和 Runtime 契约测试。

环境要求

• Windows 11 与 PowerShell 7。
• Node.js 24 或更高版本。较低版本缺少 DSH Session JSONL 持久化所需的 zstd API。
• 已安装 DSH 0.1.2-rc.1，并能正常启动 dsh web。Assistant、Observer 与 DSH 核心包必须保持该版本边界，不能混装 0.1.1-rc.2 依赖树。
• 已安装并配置所选模型对应的 DSH provider。只有使用 ChatGPT/Codex 订阅时才需要 dsh-codex-connect。
• 已安装并登录 DWS。只有启用真实钉钉订阅时才需要。

网络环境需要代理时，可在插件的 Agent 配置中填写代理地址，也可以在启动前设置 HTTP_PROXY / HTTPS_PROXY。

Skill 文件路径

DSH 根据 Session 的 Agent 工作目录发现项目级 Skill，同时加载用户级 Skill。默认扫描顺序如下，靠前的同名 Skill 优先：

1. \.dsh\skills\\SKILL.md
2. \.agents\skills\\SKILL.md
3. profile 显式配置的 customSkillDirs
4. %DSH_HOME%\skills\\SKILL.md，DSH_HOME 默认是 %USERPROFILE%\.dsh
5. %DSH_AGENTS_HOME%\skills\\SKILL.md，DSH_AGENTS_HOME 默认是 %USERPROFILE%\.agents

给本机所有 DSH 项目共享的 Skill，推荐安装到 %USERPROFILE%\.agents\skills；只服务当前 Agent 工作区的 Skill，推荐安装到 \.agents\skills。DSH 不扫描 %USERPROFILE%\.codex\skills，仅安装在 Codex Skill 目录中的 write-pr、dingtalk-* 等 Skill 不会进入 resident 或叶子 Session。

复制时必须保留完整的 ` 目录，不能只复制SKILL.md，因为 Skill 可能引用同目录下的references、scripts或其他资源。目录被发现只表示 Skill 已进入会话目录；模型仍会在任务命中触发条件后调用skill工具加载完整指令。验证是否真正加载时，应在 Session JSONL 中同时确认对应的tool/call和isError: false的tool/result`，不能只检查文件存在。

安装到 DSH

从 0.5.x 升级到 1.0.0 前，先阅读大版本升级边界和更新日志。旧存储需要独立检查，不能仅替换包后直接打开。

推荐让 Web、resident Runtime 和看板运行在同一个 DSH Web 进程中，避免两个进程同时写同一份 Session JSONL 和 storage domain。

全新安装使用根发行包；它会把 Assistant Runtime、Observer 看板和对应 bundle patch 一并装入 web profile。以 1.0.0 为例，生产或验收环境固定版本：

dsh plugin --profile web add [email protected] --save-exact

安装完成后必须重启 dsh web；仅看到依赖安装成功不代表插件 Runtime 已加载。已有 profile 升级前须先确认安装形态，不能在仍直接依赖两个内部包时只添加根包。

版本历史见 CHANGELOG，发行资产见 GitHub Releases。设置页会通过 GitHub Release 检查新版本；“版本与更新”卡片提供可复制的升级提示词，引导先核对 profile、在途任务及大版本升级边界，再按本地部署规程安全切换。根包安装与旧式双内部包安装的精确命令见安装手册。检查失败会明确显示错误，不会误报为最新版本。

升级后重启 DSH Web，并依次确认：profile 中的包版本、GET http://127.0.0.1:18998/health、设置页/运行看板、真实群消息收发。四层证据不能互相替代。

若 DSH 官方默认上下文压缩在长 Session 中出现摘要范围过小、反复压缩仍无法回到阈值的问题，可选装收敛式替换插件；安装、provider 互斥、验证和回滚步骤见安装手册的上下文压缩接入章节。该插件不随本发行包自动安装。

以下源码安装方式只用于开发未发布代码；普通安装和升级不需要克隆仓库，也不需要手工添加两个内部包。

维护者发布新版本时，先将根包、assistant 和 observer 的版本号及 CHANGELOG.md 更新为同一版本并合并到 main，再推送对应的 v Tag。GitHub Actions 会在 Node.js 24.19.0 下重新构建、测试和打包，使用 npm Trusted Publishing（OIDC）按 observer → assistant → 根发行包的顺序发布；三个包回读一致后才创建 GitHub Release。发布 job 绑定 GitHub Environment NPM_PUBLISH，不再使用长期 npm publish token。首次启用和故障恢复见 npm 发布 Runbook。

源码开发安装

1. 获取源码并验证

git clone https://github.com/HiQ-AI/dingtalk-dsh-assistant.git
Set-Location .\dingtalk-dsh-assistant
pnpm install
pnpm test

2. 将插件加入 DSH Web profile

在 %USERPROFILE%\.dsh\profiles\web\package.json 中加入两个本地依赖。路径应替换为仓库的真实绝对目录：

{
"dependencies": {
"@zzusp/dingtalk-dsh-assistant": "file:D:/path/to/dingtalk-dsh-assistant/packages/dingtalk-dsh-assistant",
"@zzusp/dingtalk-dsh-observer": "file:D:/path/to/dingtalk-dsh-assistant/packages/dingtalk-dsh-observer"
},
"dsh": {
"profile": {
"bundles": [
"@deepseek-ai/dsh-base",
"@deepseek-ai/dsh-web-app",
"@zzusp/dingtalk-dsh-assistant",
"@zzusp/dingtalk-dsh-observer"
]
}
}
}

保留 profile 中原有的 DSH 依赖和 bundle，不要用上面的片段覆盖完整文件。

若使用 ChatGPT/Codex 订阅，再把 dsh-codex-connect 同时加入 dependencies 和 bundles；使用其他模型来源时保留对应 provider，不需要安装 dsh-codex-connect。

3. 装配 resident Runtime

把 .dsh/profiles/resident/cordis.patch.yml 中的 resident 配置按需合并到实际使用的 Web profile patch。Web 基础 bundle 已包含 storage 相关插件，只覆盖 storage-json 配置并插入 dingtalk-dsh-assistant/resident，不要重复插入同名 storage 项。

简单新增可空列也支持 smallint、integer、bigint 的范围内十进制整数常量默认值，例如 ADD COLUMN is_deleted integer DEFAULT 0。仍按准确表目录核对、Bytebase 送单、插件真人审批后执行；不增加 UAT 演练。函数、算术表达式、非整型默认值与 NOT NULL 不属于此路径。验收保留 column_default 的实际目录表达式，默认 0 必须核对为字符串 "0"，不能改写成无默认值。

仓库模板有意保持以下安全默认值：

groups: []
dws:
enabled: false
writesAuthorized: false

不要把个人群 ID、DWS profile、Agent 名称、工作目录或职责写入仓库模板；这些内容应保存在本机 DSH 配置和插件 storage 中。

4. 安装 profile 依赖

Set-Location "$env:USERPROFILE\.dsh\profiles\web"
pnpm install

5. 启动 DSH Web

Set-Location D:\path\to\dingtalk-dsh-assistant
pwsh -NoProfile -File .\scripts\start-web.ps1

默认 Web 地址由 DSH 提供；resident 插件监听 127.0.0.1:18998，允许从 http://127.0.0.1:3080 和 http://localhost:3080 两个等价的本机 Web 地址访问。通过 GET http://127.0.0.1:18998/health 和 GET http://127.0.0.1:18998/state/dws-bridge 分别检查 Runtime 与真实 DWS bridge 状态；完整判定和排障步骤见安装手册。

scripts/start-web.ps1 使用当前用户的 %USERPROFILE%\.dsh 作为默认 DSH_HOME；若需要隔离 profile，可在启动前显式设置 DSH_HOME。脚本从当前项目根启动，并自动发现 PATH 中的 Node.js 和全局安装的 DSH。

首次配置

启动后，在 DSH Web 的“设置 → 插件 → 钉钉个人助理”中完成配置：

1. 设置 Agent 名称和别名，多个名称使用英文逗号分隔。群职责定义本群身份关系、负责范围和介入要求；需要作为任务称呼的名字同时加入别名配置。DWS 登录人姓名不享有特殊准入或静默规则。
2. 设置 Agent 工作区绝对目录。DSH 会从该目录原生发现 AGENTS.md。

群消息协调的原生常驻会话直接以 Agent 工作区根目录启动，原生权限为“完全权限”（danger-full-access，审批策略 never），名称使用完整群聊名称。旧职责子目录会话排空后由原生派生会话完整继承日志并切换绑定，原日志和任务身份保留；正常跨轮继续恢复同一会话。其他非任务新会话仍使用 session-workspaces/ 职责目录，任务会话沿用下述任务目录。完全权限不扩大业务工具、数据库表列授权或生产审批范围。

下一轮协调前，原生模型可见历史保留原始消息、引用和附件，收紧此前重复的后台快照；本轮完整事实与任务目录照常提供，完整原始事件仍在 JSONL 中。自身通知通过同群已登记的外发消息 ID 排除回声，不依赖发送账号与任务所有者相同，也不按正文或署名忽略普通消息。长任务继续由独立 Task Owner/执行会话推进。

新任务持久接纳后向来源群发送一次“任务已开始处理。”，按逻辑Task去重，不依赖阶段或Run。补充、重评、恢复不重复开始通知；取消或已完成的旧任务不补发开场。执行期间调查/执行/验收进展、内部执行或能力受阻、群内审批等待均不自动汇报。最终完成后回复结果；明确需要用户补充业务信息或授权时才提问，插件真人审批仍走私聊。用户主动询问进展或发出控制指令时照常回复。详细过程与诊断保留在看板。通知准备与领取共用规则，升级前未发送的中间通知原生失效；已经发送或发送未知的记录仍只回读，不重发。

职责目录继承根目录指引依赖 DSH 原生 agent-instructions.projectRootMarkers：Git 工作区可使用 .git；普通工作区应将 AGENTS.md、CLAUDE.md 或已有的根标记加入该配置。插件不复制指引、不写入个人身份，也不覆盖宿主的指引配置。
3. 设置默认模型、推理深度和叶子任务并行上限，默认并行上限为 5。
4. 按需设置网络代理。
5. 已切换到 workflow-v2 的群使用代码注册的任务流程；配置页展示只读流程目录、消息处理阶段、准入状态、定义版本及节点职责。GET /state/workflows/catalog 提供该目录，不返回旧提示词正文。未切换群的旧版叶子任务配置折叠保留，历史 taskPrompts 数据不迁移或删除；只配置新流程群时，保存通用 Agent 配置不提交旧提示词字段。
6. 查询已有任务进展由平台内置 task-progress-query@1 即时流程处理：校验同群范围、检索候选、回读状态与交付标记、生成答复。定义见目录接口的 builtInWorkflows，四步摘要写入消息命令结果供审计；它不会创建任务看板任务。候选超过 8 项时回复明确说明截取范围，标题匹配不等于业务归属已确认。
7. 已切换群的身份识别读取当前 Agent 配置的 agentNames 名称和别名，状态问句、交办准入和恢复使用同一份配置；改名后不保留旧名称捷径，未配置不默认任何本机身份。通知首次准备时读取当前“会话职责”的确定性回复规则：明确指定唯一代回署名（例如 - 资料助理代回）时，持久正文末尾空一行附该署名；未指定则不自动添加，多个不同署名拒绝。要求引用回复时不允许缺来源而退化为普通群发。已保存通知的正文保持不可变，群职责后来调整不会阻断其发送或回读。第三方任务创建进展同步会静默入账，不生成追问或业务任务；引用能沿已送达通知定位唯一话题时，消息绑定该话题，否则在收信箱显示待归类。已完成的纯排查旧任务再次收到同一问题报告且没有明确修复交办时，先询问是否实施修复；肯定答复才准入新的工作流任务，不改写旧任务。澄清答复折叠进原消息后，结清答复留下的归类屏障；启动恢复以已送达澄清通知、引用消息和已解决请求三项持久证据补挂原话题，不重复派发业务任务。
8. 新消息完成话题关联后，先等待本群已收消息完成归类；同话题消息进入同一个批量意图判断，不同话题各自判断。判断中到达的同话题新消息会使旧候选失效并集合重判。已执行中的任务收到补充时，已应用动作保留，剩余动作重新判断；来源编辑使旧话题约束失效。原任务发送者明确说“暂停/取消/恢复这个任务”且目标 Task 已绑定时，可经过 Host 与持久账双重授权后越过无关消息的归类等待。新 Task 与负责会话先原子落账，初始没有业务阶段；意图节点只交接目标、验收和约束，唯一的 Task Owner 再按受信目录初始化或调整计划。Owner 可组合排查、方案、工程、UAT 和通用能力，每个阶段由独立 Run 执行，并能读取当前 Task 已成功阶段的真实产物。阶段成功不自动等于任务完成；未解决的限制或缺来源证据会阻止整体完成。任务级暂停、取消与恢复阻止旧确认或后续 Run 越过控制状态。IM 与 Web 补充均递增 Task 要求版本，运行中的旧 Run 输入保持冻结，Owner 据新版要求调整后续计划。已完成任务仅更改报告语言时，Owner 基于已核验产物重新报告，不重跑流程；纠正须指定精确报告身份。所有 Task 均可在授权范围内调用 task-general-capability，包括受信本地 Markdown 文件生成及独立回读；缺少实际调查、写入或目标验收能力时明确阻塞。旧 task-general 和 task-general-intake 仅供历史 Run 恢复。迁移及本地验证见执行底座运维说明。
9. Task 看板区分流程结果与负责会话的整体验收；最终完成须覆盖全部当前验收项和真实阶段证据。负责人接纳的最终报告经原 Outbox 发送、ACK 与回读，单个流程成功不先冒充整体完成。历史承接和阶段结果保留各自证据，新增目标不自动撤回旧消息。通知撤回或补发仍经 /workflows/notifications/operations 逐条预检、执行与回读；群负责人授权消息须单独一行写 撤回通知 <通知ID> 或 补发通知 <通知ID>。ACK 后或外部结果未知时只查询原操作，不重发。
6. 运行看板中的新任务点击后查看节点执行详情：每个节点的状态、等待原因、产出记录和任务最终结果。节点确有模型会话时可从该节点打开会话记录；旧任务继续使用原有会话入口，卡片上的任务进度样式不变。新发起的工程发现任务由“检查并提出修改”节点按需列路径、搜正文、分段读取文件，不再建立整仓目录索引或单独选文件；Host 在实际写入前校验准入目录和文件哈希。节点领取次数仅用于统计，不设持久上限。文件发现、读取及工件交接不设置插件层字节上限，模型和运行环境的实际容量仍需由节点状态回读。

叶子的 plan-confirmed 必须用 workflowAssessment 绑定当前流程组合，说明沿用证据、不适用步骤以及例外依据。流程例外必须引用固定 Topic 中明确提出该要求的原始消息；主会话生成的目标、验收标准或旧摘要不能覆盖流程。常驻主会话结合可用流程索引和选择原因核查是否漏选，按需读取候选流程；允许有明确理由的无匹配和多个流程组合，不固化业务任务类型。读完已选流程后审阅计划，冲突时返回结构化拒绝。计划、阶段、审阅提交及最终落盘都核对当前启用流程的修订号；配置修改、停用或删除立即使受影响旧审阅失效，无需等待叶子重载。失效待审项归档到执行事件，历史证据保留，重新规划后才可推进。stage-completed 每次只提交上一检查点 remainingItems 的第一项，completedItems 不是累计历史。 checkpoint 按 kind 使用同源契约：plan-confirmed 才允许 workflowAssessment；stage-completed 必须有 stageTask 和非空 evidence；scope-conflict/evidence-gap/risk-changed 可用 stageTask/stageId 标明受影响阶段，但 completedItems 必须为空，不能推进阶段。工具 JSON Schema 由同一 Zod 投影到 DSH 支持的子集，kind/status 分支保留；长度及复杂关联约束由执行时 Zod 精确校验并返回字段路径。错误推进会得到 reviewStatus=rejected 的报告回执及具体缺口，原进度不变；核对该项真实证据并按回执修正，确认接受后再推进下一阶段。
6. 通过群名称模糊搜索添加常驻群，并为每个群配置会话职责。

确认页面的环境检查显示 DWS 已安装、已登录后，再在实际 profile 中启用：

dws:
enabled: true
writesAuthorized: false

先验证真实消息能够进入固定 resident Session，再将 writesAuthorized 改为 true 开放群聊回复。修改 profile 后需要重启 DSH Web。

完整的逐步安装、页面字段说明和“先收后发”验收流程见安装插件并在 DSH Web 中完成配置。

群聊工作流

流程契约使用存储 domain v9。已有 v8 数据须按工作流存储迁移进行零写自检、独立目标转换和真实 SDK 回读；v6/v7 先按旧 Topic 迁移得到 v8，再转换到 v9。不能直接用新 Runtime 打开旧存储。活动任务迁移后停在系统等待，显式恢复并重新确认结构化计划后才继续。下文说明代码契约，不代表该版本已发布或本机 profile 已升级。

任务负责人读取成功工程阶段时，Host 先核对同一运行、候选和提交的交付证明，再提供构建检查、本地验收要求、业务结果和清理收据的原始节点引用；PR 结果不单独代表业务验收通过。此材料展开不改变已冻结的工作流或重跑成功节点。

节点接口与恢复语义见工作流节点契约。计划以稳定 criterionId/stageId、来源和版本为准；阶段产出引用产物及证据，完成提交包含逐项验收。报告 received、审阅批准、业务应用和通知送达分别记录。完成结果与通知意图同次持久化，通知失败恢复原意图，不重做业务。

已接纳 Decision 的已知本地瞬时存储错误最多尝试三次；未知错误进入 blocked，保留原 operationId 和冲突保留记录。普通消息重试不能解锁未知结果，Host 必须对账后按原操作恢复。Task 取消先保存 stopRequest，未确定的外部动作继续对账，不能把“取消已请求”显示成副作用已撤销。执行许可与 Task 状态分离，等待审阅时停止叶子并释放许可，恢复必须重新排队取得许可。

材料清单、版本和完整性检查由 Host 提前计算；只读注册检查器目前包含产物 SHA256 核验，摘要匹配不代表业务验收通过。外部动作账本只约束已注册适配器，未接入的任意 shell、SQL、部署不会自动获得去重或资源锁保障。

常驻主会话

每个群唯一绑定一个 resident Session。群名称、群 ID、职责和稳定决策协议通过 DSH systemPrompt.section 注入。消息明确指向已配置的 Agent 名称/别名、使用 cc:，或明确确认此前“是否需要我处理”的询问，并形成职责范围内的可验证目标时，主会话可以创建 Task；未明确指名但判断事项应形成任务时，主会话先在群里询问“这个事项是否需要我处理？”，收到肯定答复后再结合原消息和后续补充创建。Host 在接受 new-task 时再次校验群职责非空，并要求依据消息明确指向 Agent，或引用本插件此前持久化的 task-proposal 询问，不能只信任模型结论。主会话只负责选择 Task 路由；Runtime 使用原始群消息生成来源证据信封交给叶子，主会话生成的根因、完成度、方案优劣或排除性判断不作为叶子事实。

每条新消息先可靠持久化到 Inbox，接收接口随后返回；Resident 使用 group_topic_route_submit 对冻结的消息批次先拆分可独立补充、取消、交付、验收和反馈的事项 unit，再分别匹配持久 Topic。一个消息可包含多个 unit，每个 unit 有精确来源、唯一动作 owner 和自己的 unitId + unitRevision；四个属于同一交付目标的验收点保持一个事项，独立需求分别处理。超长路由原文通过 group_topic_route_context_get 按固定坐标读完，Host 在完整读取、范围覆盖和归属校验前不会接受部分路由。Topic 跨 turn 存在，已归类的无关话题不会使当前话题决策失效。已有 Topic 可与待路由批次交错准备决策；同群模型仍串行，有竞争时每个请求执行一个原生步骤并在工具结果落稳后让出。提交仍核对全部未知输入；返回 routing-required 后 Host 保留未接纳草稿，路由完成即按当前来源、版本和回复审阅结果重新校验提交，无需模型重算。同话题新增输入使旧草稿失效，重启则按当前输入重建。无限未分类输入下不承诺提交等待有固定上限。已接受的业务意图仍独立恢复；归类、Topic 决策与 Task 执行分别维护进度，DWS 补拉完成只证明可靠接收。

路由工具成功时只返回 status 和 requestId（重提已落盘请求另有 recovered: true），不在工具输出中复制待决策 Topic 的正文或临时 ID 映射。Host 将各 Topic 的 [GROUP_TOPIC_DECISION] 分别投递到常驻会话；accepted 仅证明路由落盘，不代表决策、Task 或群回复已完成。决策首屏优先提供本次事项、直接引用、原始点名和 Topic 摘要；同一消息的引用与原文只提供一份。超长段使用 group_decision_context_get(requestId, section, offset) 按固定请求连续续读；历史使用 group_topic_context_get 按需读取。

Topic 的 title 是对齐 Task 名称的 8–20 字短语，最多 30 字，细节保存在 summary。v6 迁移形成的历史 Topic 如果摘要为空，Runtime 会先让 Resident 根据其固定版本引用消息生成独立摘要；随后再根据摘要重新概括标题并通过 group_topic_title_submit 原子写回，禁止直接截断摘要。摘要和标题分两步提交，每步都校验 Topic 快照，过期结果不会覆盖新内容。

入站消息引用其他钉钉消息时，Steer 信封只携带稳定的引用消息 ID；正常情况下 Resident 直接使用同一会话已经收到的正文。如果该正文因消息传递异常、会话恢复或上下文压缩而不在当前可见上下文，Resident 必须加载 dingtalk-chat Skill，并使用插件配置的同一 DWS profile 执行 chat +messages-mget 主动读取；取回的消息仍有 quotedMessage.messageId 时继续向上查询，直至整条引用链结束。查询结果必须校验完整性，必要时读取链上的图片或文件。查询失败、结果不完整、未命中或检测到循环时，不得要求群成员补发原问题、正文或截图，也不得猜测并回复；本次判断进入 decision-retrying，由 Runtime 在故障恢复后自动重试。

group_decision_submit 每次提交一个 Topic 的决策，绑定 topicId、revision 和持久 decisionId。决策及每个 Task action 都携带 basisUnitRefs，Host 按事项逐动作校验 owner、当前增量和执行版本；接受一个事项不会消费同消息的其他事项。Task 仍只保存 topicRefs，固定版本读取只投影本事项的来源与共享背景。任何 Task 动作都必须带非空确认；确认先可靠写入 Outbox，再创建、续接或重开 Task，但单独确认不消费后续业务动作资格。取消仍优先发送止损信号。决策接受后保留动作回执，按固定 operationId 恢复，不通过重建 ID 重复执行。Topic 工具参数错误返回精简的 invalid-arguments 字段问题；归类请求过期时返回当前请求，已落盘的重复提交从 RouteHistory 恢复原回执，Resident 不猜测或盲目重放未知请求。

动作的条件必填字段由同一份规则生成协调工具 schema 和 Host 校验，例如 report 必须提供 language；缺参拒绝，不补默认值。

历史主会话回复候选按 Topic 决策或 Task 通知绑定并有界读取，不随全群历史重复注入。Resident 准备回复时调用 group_reply_review_get，完整审阅绑定快照；Topic ID、引用 ID 或关键词不能替代语义判断。重启后从持久的归类进度、Topic 未处理版本和已接受决策恢复；已归类话题的失败只阻塞该话题及共享 Task 的关联操作。

图片及其紧邻短消息在归类阶段共同理解；附件读取失败不能据标题或缩略图猜测正文并启动 Task。原始消息保存附件与事实版本，Topic 固定版本解析相应原始事实，重启后仍能追溯输入。

Task 完成和信息阻塞通知使用 group_reply_submit 结构化提交，绑定 Task runSequence、inputVersion、事项来源、相关 Topic 版本及回复快照。每个事项完成后立即进入自己的验收和 Outbox 链路，不等待同消息其他事项；通知请求冻结创建时已接收入站的序号边界，边界后的无关新消息不会扩展旧请求。Resident 根据所引用 Topic 的原始消息选择 replyToMessageId；省略 atOpenDingTalkIds 时，Runtime 统一从被引用消息推导发送人，显式接收人仍必须属于当前 Topic。当前事项的 Topic 或执行版本变化会使旧通知失效，并在持久协调账中进入 superseded 终态。Outbox 待投递、DWS 发送和群回读确认分别计量；通知使用提交 requestId 派生稳定 Outbox 身份，运行层重启或调用方未收到返回值时可读取已接受回执，找不到回执的未知请求不会自动重发。

Topic 决策产生非空回复时，Runtime 使用 DWS 原生引用回复，并验证选定消息属于当前 Topic 快照。原消息的引用链只提供上下文，不自动成为出站引用目标。发送人 ID 缺失时不得猜测引用参数。回读必须匹配正文与精确的引用消息 ID；同文但属于其他话题的引用回复不能认领为本次投递。

任何非空回复提交前，Resident 必须通过 group_reply_review_get 按请求 ID 读取 Runtime 绑定的历史确认、近期回复、内容相关回复和当前 Task 关联回复。Resident 根据正文、目标、动作范围和时间线判断同一事项，引用 ID 和相似度只定位候选。等价确认没有新信息时保持静默；必须补全或纠正时，完整审阅后选择当前群真实 Outbox。接纳前校验替换图，原子持久化新通知与替换关系；旧 pending 进入 superseded，不再发送，但这不证明历史从未送达。历史发送未知只核验，迟到回执仍记录实际 messageId。

替换通知先经原生幂等发送及 DWS 回读确认，再独立撤回已授权的旧消息（包括替换链）。撤回失败不再阻塞纠正通知，也不把旧消息伪标撤回：明确服务端拒绝停止自动重试；其它异常按 30 秒间隔最多尝试 3 次，之后等待核验。历史未知查询未命中保留 replacement_delivery_unknown，可由迟到回执继续恢复，不等于确认未发送。发送入口共享群级串行队列，实际外发前再原子检查旧意图未被替换。看板分别展示已替代、撤回待处理、待回读与已回读，保留审计原因。

普通发送遇到明确服务端拒绝时持久化 deliveryBlockedAt，看板显示发送待处理，停止对相同意图自动重试；读取失败或送达未知不冒充明确拒绝，继续保留原生幂等与回读保护。

无任何业务动作或投递记录的阻断通知，可由运维持证据通过 reconsider 重新决策；有副作用或结果未知的记录拒绝此操作。阶段成功事件沿用稳定身份，升级不会将相同完成观察当作新输入。若既有版本已产生重复事件，仅允许在维护排空后依据原完成决定和完全相同的事件内容原生对账，保留失败回合；不能据此重新判定业务完成。详见本地部署与恢复规程。

群聊协调决策

决策首包提供固定版本的 promptIndex 和合法 contextSections；内联消息直接复用，只有分页指针需要 group_decision_context_get。流程正文通过同一请求的 group_task_prompt_get 批量读取，已有任务用 group_task_list / group_task_context_get 查询。流程版本改变会使旧读取失效并重新调度。

同群模型保持串行。存在竞争时，决策与审阅每次可连续执行最多三步，或在累计30秒后的步骤边界让出；不会中断正在执行的模型或提交工具。路由仍在步骤边界优先，两批路由后给其他请求公平执行机会。这个预算控制轮转，不承诺真实渠道端到端30秒内完成。

活动记录恢复在后台处理固定快照，再按序接续新事件；启动不等待运行任务的历史统计完全追平。失败保留水位并可恢复，关闭仍等待已排队记录落盘。

性能观测与协调资源读取

GET /state/performance 是只读观测接口，可按 day、sessionId、groupId、taskId、requestId、submissionId 精确筛选。rows 按上海自然日返回模型和工具调用、首流事件/响应/工具耗时分布、上下文及 token 用量；分布包含 count/sum/max/p50/p95。inputTokens 是未缓存输入；totalInputTokens 合计已报告的未缓存、缓存读取和缓存写入，缺失分项另计，不能把未知用量当作已确认的零。模型/工具资源累计耗时与区间并集分别展示，不能把跨行累计值当作端到端等待时间。已有 /state/task-timings 继续提供 Task 状态耗时。

workflow.taskWaits 从持久状态历史和报告收发边界派生排队、运行、系统等待、人工等待、信息等待及审阅等待，按日对每类区间取并集。旧历史没有 waitingKind 时记为 unknownWait，不借当前状态猜测历史；报告等待可能与运行状态重叠，不能把这些列当作互斥阶段相加。状态历史没有精确请求/会话/报告关联时，相应筛选返回缺失说明。

workflow.responses 只匹配 replyToMessageId 精确指向入站消息、且已经保存送达消息 ID 和送达时间的回复；按入站日期归组。firstReplyMs 包含确认回执，firstLabeledSubstantiveReplyMs 只采用 replyKind=substantive 标签，标签不等于人工验证了实质回复内容。未匹配消息返回空值与缺失原因，不记为零耗时。

coordination.requests 按请求汇总会话数量、模型输入、未缓存输入及协调消息正文序列化后的字节数；不将字节数折算成 token 或费用。rows.coordinationQueueMs 使用 dingtalk/coordination-dispatched 中真实入队、分派时刻的差，包含等待轮到本请求及准备会话的时间；重复分派同一消息不重复记录。缺失、倒序时间或请求身份不符单列缺失；旧队列边界没有自动回填。

observedSince 和 coverage=observed-events-only 标明本投影的观测范围。缺失 usage、首流事件、step 起点或工具配对由缺失计数明确记录；fork seed 和重复投影不计作新模型调用。投影在现有 scheduler 表按会话分区保存，逻辑上更新某会话不改变其它会话的历史，但 single-json 后端仍会重写整个 Domain 文件；计量写入使用全局单写入器，将等待中的同会话事件合成一次持久写，避免多会话计量占满业务写队列，回执仍在持久化后完成；step 结束清理配对状态并压缩已完成步骤身份，缺失工具结果仍保留计数。精确分位频数、去重范围与每日区间并集随保留历史增长，retention 明示这一限制，不作任意条数截断。只持久保存计量元数据，不保存正文或工具参数。首流事件不等于首个可见字，更不等于首次实质回复；人工内容标注、全部外部阶段归因和账单计价仍未完成，不能据此承诺费用或真实业务响应收益。

请求会话通过 group_message_get 读取本请求消息及引用链，通过 group_resource_get 读取消息明确引用的附件或 URL。任意消息 ID、资源 ID 或 URL 被拒绝；分页须连续读取，身份、版本、格式或完整性不符会明确失败。公网文本读取仅允许无凭据的 HTTPS/443、公网 IPv4 DNS 结果；固定本次连接地址，不跟随重定向，不读取内网或环回地址。资源不支持、缺少读取器、图片不可用或正文未读完整时，不得猜测内容或当作证据齐全。

本轮源码实现及验证状态见性能优化目标与验收记录。本轮尚未部署；独立 DSH glob 责任包只产出本地补丁，未安装到运行 profile。22条带固定前缀的历史失败搜索已完成对照，8条无固定前缀及4条宽 worktrees 查询仍需准确目录输入。上下文、首次实质回复与费用等真实流量收益仍待部署后独立观测，不能由本地用例通过代替。

叶子任务

Task 可设置独立的简短标题用于看板展示；标题与 objective 分离，重命名不会改变任务授权范围、Goal 或验收标准。运行看板通过 DSH 官方 sidebar.footer.action 提供左侧菜单入口，并由 shell.overlay 承载右侧完整内容区域；点击运行看板时切换到看板并清除 Session 选中状态，点击任意 Session 时关闭看板、恢复该 Session 的选中状态与对话/轨迹。运行看板复用 Session 的实际选中背景色，不额外显示焦点边框。

执行控制账使用 schema 8，按事件类型与序号建立原生索引，避免详情查询与后台通知轮询反复全表扫描。已有 schema 7 必须先按受控部署说明执行零写预检、完整备份和封存迁移；启动不会自动升级数据库，缺失或错误索引会拒绝启动。

运行看板 Header 的高度和字体规格与 Session 页面一致。各页不再重复显示页面标题和子标题；任务列按 Header 与主内容实际占用计算剩余视口高度，卡片在列内独立滚动，页面本身不会因状态桶高度产生额外补白或纵向滚动。人工介入列表区分待处理、已处理和已失效请求；只有待发送或等待回复的请求提供处理操作，未知状态以异常标记展示且不会导致整个看板崩溃。

Runtime 使用 DSH 原生 subagent 和 Goal 创建叶子 Session。Task 保存标题、目标、验收标准、执行状态、结果，以及 topicRefs: [{topicId, revision}] 和 inputVersion；不保存 sourceMessageId、triggerHistory、messageHistory 或群消息正文副本。group_task_context_get 返回执行约定与 Topic 引用，原始上下文由 group_topic_context_get 按固定 revision 分页读取。只有确实影响任务的新增信息才推进 inputVersion，不向每个关联 Task 广播全部讨论。运行中和等待中的 Task 接纳上下文时继续原轮次；完成或归档 Task 只有被明确重开才开启新轮次。目标发生实质变化时，续接动作必须同时提交概括当前完整目标的新标题；Runtime 原子更新目标和标题，并由 objectiveHistory、titleHistory 与 runHistory 保留旧值。普通信息补充、等待恢复和异常唤醒不修改标题，归档不删除历史。叶子完成自身交付与必要自验证后即可提交 completed；原群参与者或其他机器人的后续检查属于 Topic 协作，不阻塞叶子 Task。若信息或人工介入确实阻塞本职交付，等待报告需列出 blockedItems（未完成要求、来源消息、必要依赖和原因），经 resident 内部审阅后才能进入 waiting。误把他人职责写入目标时，resident 按原消息修订 Task 目标、验收和阶段，保留已完成证据；外部反馈经正常 Topic 输入处理。历史 coordination 结果只读兼容，不再重发检查请求。

内部审阅预算等确定性系统故障会将原报告记为 failed，Task 进入 waitingKind=system 并释放运行名额；Host 通过可靠 Outbox 通知暂停，同一轮次、版本和错误码不重复通知，也不要求叶子反复改稿。恢复入口仍为 POST /tasks//reports//retry。恢复前在 Task 提交锁内只读重建审阅输入，复核报告版本、轮次、当前流程、待处理输入和人工授权；探测失败保持系统等待，不启动叶子或清除故障。通过后在并发容量允许时处理原 submissionId，不能靠创建新报告或会话绕过故障。

派发及重开时，Runtime 从已登记的本地 worktree、已有报告工件、检查点证据和交接记录提取原生绝对路径，检查当前是否存在，随任务输入提供可确认的工作位置。不会遍历工作区寻找这些位置；无法确认时明确标记 unknown。位置存在不代表旧验收仍有效，也不扩大任务授权。优先在已确认的目录检索，避免重新扫描整个工作区。

叶子新建受管理工作区 worktrees/ 下的 Git linked worktree 后，调用 task_worktree_register 登记路径、当前执行版本、