dsh-multi-model-discussion

A DeepSeek Harness (dsh) plugin that runs one topic through a multi-model deliberation pipeline and returns a traceable deliverable.

requirements → 3–5 proposal seats research and propose independently
             → integrated draft with a per-point disposition table
             → 2–5 blind review seats on the same draft version
             → evidence verification (read-only tools executed by the program)
             → immutable revision (new version)
             → independent acceptance on a fresh context

Install

dsh plugin --profile desktop add github:<owner>/dsh-multi-model-discussion

Then pick a registered provider/model for each node and seat in the visual page (/mmd/visual); runs stay blocked until every required route is chosen. No API key is read from or written to the plugin config — routes resolve through the harness like any other node.

What the model does vs. what the program does. Seats decide what to investigate, and write the proposals, draft, review, evidence conclusions and revision. Stages, version immutability, point and issue numbering, bounded retries, format repair, budgets, cancellation, late-result handling and the acceptance gate are all enforced by the program — a run cannot be marked accepted by prose alone.

Filesystem access is opt-in. The read-only research tools (read_file / list_dir / stat / locate) are confined to research.roots, and research ships disabled with an empty allow-list. Enabling it requires naming the roots explicitly. There is no write, delete, execute or network capability, and every probe and refusal is logged with a sha256.

Guarantees and limits. Point numbering and disposition checks prove traceability, not judgement: review and acceptance still have to weigh the reasoning against the source material. Simulation runs use in-process model doubles and say so in their own deliverable — they are not evidence that real multi-model deliberation works. See Known limitations for the full list.

Output is Chinese-first; the sections below are the complete reference documentation.

---

模型配置已改为按节点和席位选择（modelConfigVersion: 2）。需求、初稿、证据、修订、验收直接使用各自的 nodes.<id>.model（provider__model）；提案和审查分别使用自己的席位列表。旧 participants、integrator、acceptanceParticipant 仅用于首次迁移和历史任务兼容，不再决定新任务的模型。

可视化页的“模型分工总览”自动显示当前选择和最近运行的实际调用，点击行可跳到对应节点。没有调用记录时显示“尚未调用”；“已响应”仅代表模型返回，不代表任务验收通过。最多 10 个备选模型继续按优先级切换，写稿与验收的实际路由在切换和续跑时也要保持独立。

首次读取当前配置会将已有选择和有效参数保存到 node-overrides.json，并备份旧文件为 node-overrides.pre-model-config-v2.json；迁移保留 revision，之后清空模型不会从旧配置补回。缺失或失效模型阻止新运行，历史 manifest 保持原样。

新任务在派发前核对所有已选模型的推理档位。max 表示该模型支持的最高档位，例如模型只提供 low/medium/xhigh 时实际发送 xhigh；请求值和生效值分别留档，输出 token 上限不变。其他不支持的明确档位会在首次模型调用前拒绝，不等到后续阶段才报错。

能力查询独立限制在 30 秒内；节点派发时还受剩余节点及运行时限约束，取消或超时会在生成请求派发前退出。节点或运行时间已用尽时报告对应时限，不再误报为零毫秒的能力查询失败。连通性检查使用相同的档位解析规则。

格式修复若因“完整原任务＋旧答案”超过输入上限，会先完整归档旧答案，再保留完整原任务重新生成；输入上限、修复次数、无进展停止和结果校验继续生效。失败续跑会校验并恢复原始资料快照，复用已经保存且重新通过合同校验的完整提案席位；章节片段不能替代整份提案。未完成席位仍可能重新计费，恢复计划会列出相应记录。

取证阶段中断时，还可按问题复用完整的证据检查点：节点结果、问题账本、程序修正后的证据结论、稿件版本及读取覆盖关联须全部匹配。复用不会再次调用模型或重复入账，也不会把原来的 insufficient 提升为 supported。缺失记录、跨稿、重复条目或部分写入继续拒绝续跑；读取范围存在缺口时会保留缺口供最终验收判断。

审查与取证的 limitations 仍要求非空字符串；若模型返回每项均非空的字符串数组，程序按原顺序用换行连接并记录归一化，原始响应完整保存。空数组、空白项或混合类型不会被填补或接受。其他字符串字段的诊断会区分缺失、空值和实际类型，避免格式修复反复猜错。

DSH 多模型协作研讨插件（M1）。一个运行实例把一个课题跑完整条流水线：

需求整理 → 3–5 个提案席位各自调查并独立提案 → 初稿整合与观点逐项处置 → 2–5 个审查席位（默认 3 个，同版本、互相不可见）
        → 证据核验（程序执行只读工具）→ 完整稿修订（不可变新版本）
        → 新上下文独立验收                     ↑___________ maxReviewCycles 决定循环次数

模型负责提出调查请求、分析与写作；受限只读工具由程序执行。阶段、版本、观点与问题编号、有限重试、格式修复、预算、取消、晚到结果处理与验收门槛全部由程序负责。

审查和验收可按需申请本地只读核查；needs_revision 且必需验收项没有证据缺口时最多定向修订一次并重新验收，blocked_evidence 保持终态。

第 2、4 步各提供五个独立席位，分别保存模型和追加提示词。审查默认提供需求、技术、挑战三个视角，可手动启用 2～5 个；所有席位均可选择 DSH 模型目录中的路由。共享节点提示词之后追加本席位提示词，每席位最多 20,000 字，超长拒绝保存，不截断。未启用席位可以保留已失效的模型配置。

新运行必须先保存 3～5 个提案席位；历史记录仍可读取。审查默认配置取现有参与者、已启用提案席位和模型目录中的路由，用户可调整并保存；同路由不同席位具有独立身份，但不保证观点多样性。两阶段分别保存草稿，阶段通用提示词和席位提示词分开保存。

第 2 步中，每个席位先只看用户原始输入和已登记资料，自行形成调查问题；如进入第二轮，才拿到共同需求基线检查遗漏与冲突。最多进行两轮自主调查请求，每轮最多请求 4 项受限本地只读操作。程序按 research.roots 白名单执行，并只向发起请求的席位回填实际结果及拒绝原因。席位随后写完整提案，单列 keyPoints 关键观点与 baselineChallenges 基线异议；未读到或被拒绝的资料必须保持未知，不得写成已核实事实。席位之间在提案完成前看不到彼此的调查和答案。

程序为每条关键观点生成稳定 pointRef，初稿整合者须逐项选择采纳、合并、拒绝或待证，写明理由和初稿位置。修订时若改变原处置，须显式提交 proposalPointUpdates，程序保存新版处置表。第 4 步审查原提案、观点清单、处置表与同版本稿件；最终验收再次对照观点和最新处置。程序核对清单与处置编号是否完整，但这只能证明可追溯，不能证明观点、引用或整合判断正确。最新处置中核心观点仍待证时不能宣告验收通过。

仅刷新网页不能加载后端源码更新，需重启 DSH 后端。当前后端版本标识为 mmd-orchestrator-0.5.11-deadline-diagnostics。

• 零第三方依赖：只用 Node 内置模块，插件包不 import 任何 @deepseek-ai/*，因此在 profile 的 node_modules 里可直接解析。
• 真实调用走 ctx.llm.stream()，按 provider/model 精确指定路由。
• 模拟调用可走同一条真实链路（见下），也可走进程内替身。

目录

plugin/
  package.json                       bundle 清单（dsh.bundle.patch）
  cordis.patch.yml                   Host 行（配置在这里，可被 profile 层覆盖）
  presets/multi-model-discussion.patch.yml   自定义模式（agent preset）声明
                                            （tool-fs-search / tool-todo 的 config 为 required，
                                             缺失会让整个模式被标记「加载失败」而无法选择）
  prompts/                           节点提示词：common + 7 个节点
  lib/
    index.js                         插件入口（Host 能力 / 预设提示段）
    config.js                        配置校验（无 schemastery 依赖）
    service.js                       multiModelDiscussion 运行时：发起 / 查询 / 停止 / 报告
    core/
      contracts.js                   NodeResult 合同 + 逐节点 payload 校验 + 验收门槛
      proposal-seats.js              提案席位：5 个稳定席位、3–5 启用、路由与追加提示词
      orchestrator.js                流水线、版本、重试、预算、取消、晚到结果
      ledger.js                      问题与证据账本（去重、来源保留、applied≠resolved）
      store.js                       运行目录、不可变版本、原子写入、重启识别
      orchestration-context.js       上下文组装 + 输入清单 + 用量预算
      research.js                    只读研究工具（白名单，无写/删/执行/联网）
      proposal-research.js           提案席位自主调查请求的受限执行与结果回填
      quality-gate.js                提案观点编号、引用及逐项处置的结构校验
      model-client.js                ctx.llm.stream 封装 + 错误分类
      prompts.js                     提示词装载 + 输出合同生成
      report.js                      成果 / 处置表 / 证据索引 / 验收记录渲染
    testing/
      simulator.js                   确定性测试替身（按任务包生成合同合法结果 + 故障注入）
      mock-adapter.js                把替身注册成真实 provider 路由
  test/                              自动化测试（node --test）

安装

必读资料入口修复（2026-09-27）

后端版本 mmd-orchestrator-0.3.1-input-bridge 接通了本次任务的必读资料。 用户给出文件或源码检查范围后，发起助手负责整理 taskInputs.declare，不要求用户手填配置：

{
  "topic": "基于真实源码评审当前架构",
  "requiresFileEvidence": true,
  "taskInputs": {
    "declare": [
      { "path": "plugin/lib/core/orchestrator.js", "required": true, "strategy": "whole-file", "purpose": "核对流程实现" }
    ]
  }
}

path 可以相对已配置的只读根目录；多个根目录命中同一路径时报告歧义。 inputs 是服务/HTTP 的兼容别名，不可与 declare 同时传入。 扫描范围只能用于定位文件，不能扩大读取白名单；目录和通配符须由发起助手先展开为具体声明。 已读取的文件快照以完整原文进入节点输入。已取消自动分批阅读、笔记压缩、分节审查和分节验收；修订也接收完整稿件。完整请求（含提示词、材料、查询结果与额外要求）超过 maxInputTokensPerCall 时，在派发前报 INPUT_LIMIT，不截断、不生成有损笔记。maxDraftTokensForFullRead 仅兼容历史配置，不再影响读取。只有写作输出确实接近输出上限而被截断时，才允许在预算预检后分章生成；每章仍接收完整输入材料。 空必读清单（显式要求真实文件核验时）、必需文件缺失或快照失败会在调用模型前停止，状态为 needs_evidence；后续取证无成功读取也会停止依赖它的修订。 资料快照和读取额度按运行隔离，不复用上一任务的缓存。

源码更新后须重启 DSH 后端并在 describe.versions.orchestrator 核对版本。旧进程仍使用已加载模块；既有运行不能靠刷新页面或改默认探针自动补齐资料，需用新入口重新发起。

验证命令：node --test "test/*.test.mjs"。以当次摘要为准；自动化测试使用本地模拟模型，不产生真实 API 调用。

plugin_manager  action: install_bundle
                target: <本插件所在目录>

安装后提供 discussion_* 工具、/discussion 命令、/mmd/api HTTP 入口，以及花名册中的「多模型研讨」模式。

「多模型研讨模式」系统提示段仅在对应预设的 role: preset 作用域中注册；Host 只提供共享能力，普通模式保留自己的系统提示。promptSection.enabled: false 可关闭预设提示段；Host 中的 promptSection 配置不注入模式指令。

配置改 cordis.patch.yml，或在 <profile>/cordis.patch.yml 里按 id multi-model-discussion 覆盖（config 整体替换）。示例见 config.example.yml。

入口

入口	用法
工具	discussion_start { topic, constraints?, expectedDeliverable?, requiresFileEvidence?, taskInputs? } → { runId }；discussion_status；discussion_issues；discussion_report；discussion_stop；discussion_resume_plan；discussion_resume
命令	/discussion start <课题> / list / status [runId] / issues <runId> / report <runId> / stop <runId> [原因]
HTTP	GET /mmd/api?op=list|status|report|describe|smoke|flow|node|models[&runId=][&node=]；POST /mmd/api?op=start|stop|resume-plan|resume|save-node|save-limits|save-config|save-seats|save-review-seats
可视化	浏览器打开 /mmd/visual：7 步流程图（附实际分支说明），点节点看提示词与输出合同，可指定单执行者节点的参与者与该节点跑 DSH 里的哪个模型、勾选并行节点跑哪几家、追加提示词、调单节点 token 上限；“提案席位”块配置 5 个独立提案席位（启用开关 / 模型 / 席位追加提示词）；全局循环与预算同页改，并显示总预算与最近一次运行的用量/剩余时限。切换节点保留未保存草稿，刷新或离开前提示；窄窗口自动切为单栏

op=smoke 是真实联调前的路由自检：对每个参与方发一次极小调用（约 24 输出 token）， 报告是否可达、错误码、以及该路由是否上报 usage。它不写运行目录、不重试、失败时不替换参与者； 可视化页在调用前会先确认，因为这是真实用量。

op=flow 返回 7 节点流水线、每节点的有效路由与设置来源、limitSpecs（中文标签、单位、范围、 覆盖值）以及独立性检查结果；op=node&node=<id> 返回该节点的提示词原文与输出合同； op=models 返回可选的参与者路由。

覆盖保存的语义（op=save-node / save-limits / save-config）：

• save-node body {node, patch, expectedRevision?}；save-limits body {limits, expectedRevision?}； save-config body {nodes, limits, expectedRevision?}（原子提交多节点）。
• 字段给值 = 设置覆盖；给 null = 移除覆盖并回落到继承值（cordis 节点默认 → 参与者自带值 → 全局上限）；省略字段 = 保持已有覆盖。清空按钮与“留空=跟随”都会发送显式 null， 所以“跟随”能真正恢复继承值，而不是把旧覆盖留在文件里。
• 每次保存是一次事务：读 → 合并 → 整份独立性校验 → 写，同一 storageRoot 内串行执行， 并发保存不同字段不会互相覆盖；expectedRevision 与当前 revision 不一致时返回 409 CONFLICT（另一个标签页或其他工具已改过）；违反独立性的提交返回 400 + problems。op=describe 分三层：base（激活时的配置）、effective（下一次运行）、 runSnapshot（某次运行自己的 manifest 快照）。
• 并行节点（proposal / review）的旧参与者配置可用 participantIds: [...] 指定参与者； 留空或 null 表示清除覆盖、回到“全部参与者”。不允许空数组，也不允许用 participantId 指定单个执行者。新运行的第 2 步按提案席位配置，必须启用 3～5 个席位；第 4 步使用单独的审查席位配置。
• save-seats body {seats: [...], expectedRevision?}：一次性保存 5 个提案席位。每个席位 {seatId, name?, enabled, provider, model, promptExtra?}，seatId 恒为 seat-1…seat-5 （稳定身份，不以模型为唯一身份）。第 2 步启用数必须为 3–5，少于 3 会被拒绝保存并返回 problems；未启用的席位保留其模型与提示词，不调用模型、不产生提案。席位之间即使路由相同 也各自独立：拥有独立提示词、独立版本文件与独立调用记录。席位的 provider/model 会按 DSH 模型目录核对，目录里不存在的路由被拒绝保存，不会被静默替换。前端仅做快速提示，真正的 把关在 save-seats 与 start 两处（start 未通过时返回 PROPOSAL_SEATS_INVALID，不创建运行）。 未保存过席位时不能发起新运行；历史运行仍按各自的配置快照回看。
• 单执行者节点还可以用 model 指定该席位跑哪个模型：写 provider__model（例如 deepseek-official__deepseek-reasoner）换到任意 DSH 可用模型，或只写模型名表示留在该席位 自己的 provider 上换一个模型。模型目录由 Host 动态提供（ctx.llm 的 listProviders / listModels），页面下拉框与 DSH 选模型看到的是同一份目录；DSH 没有 暴露的模型会被拒绝保存，不会被静默写进配置。选中的模型就是该节点的执行身份：版本文件名 （draft-deepseek-official__deepseek-reasoner-v1）、节点记录、独立性校验都按它算。
• 独立性按模型路线（provider + model）比较，不再只看参与者 id——两个参与者绑在同一个模型上 并不算独立。同一模型被同时放到作者节点（需求/初稿/修订）和验收节点上会拒绝保存并说明冲突； 核验者与作者同模型仍只给提示。
• 合并后的配置必须满足“验收模型 ≠ 任何作者节点（需求/初稿/修订）的执行模型”。该规则在激活、 保存、启动三处校验；启动不通过时不会创建运行目录。单节点分步改动会出现非法中间态， 因此同时调整多个角色时要用 save-config 一次提交；可视化页保留逐节点编辑，单独保存仍会校验作者与验收者独立性。

覆盖存放在 <storageRoot>/node-overrides.json，下一次 start 生效，正在跑的不受影响。 想用新模型，先在 cordis.patch.yml 的 participants 里加一条路由，再在可视化页按节点选用。

plugin_manager list_plugins / set_plugin include:multi-model-discussion 可启停。

运行产物（storageRoot/<runId>/）

文件	内容
run.json	当前有效状态：阶段、需求版本、当前稿版本、验收、用量、未决、提交记录
manifest.json	环境与配置快照（脱敏）、编排器与提示词版本
events.jsonl	只追加的运行日志：阶段、调用、用量、工具执行、停止、晚到结果
commits.jsonl	每个阶段结果的提交标识（重启后据此判断是否已保存）
versions/	不可变版本：需求、各席位提案、程序汇总的观点清单、初稿观点处置表、完整稿与验收；同一标识写入不同内容会被拒绝（VERSION_CONFLICT）
nodes/	每次节点调用：任务包、输入清单、席位调查请求、原始输出、解析结果、用量、是否晚到
issues.jsonl / evidence.jsonl	问题与证据的只追加审计日志（读取时折叠为当前状态）
deliverable.md	可独立阅读的完整成果 + 提案观点处置表 + 问题处置表 + 证据索引 + 验收记录 + 运行记录

模拟测试

node --test "test/*.test.mjs"

测试套件覆盖编排全链路（提案席位、观点处置、互审、取证、修订、验收、续跑与预算）， 模型调用全部由 lib/testing/ 的进程内替身承担，不读凭据、不联网、不产生真实 API 调用。

跨仓库的端到端驱动脚本（run-simulated.mjs / run-in-dsh.mjs / 证据矩阵）属开发工作区， 依赖该工作区的私有夹具，不随本包发布。

lib/testing/mock-adapter.js 可把替身注册成真实 provider 路由（mmd-mock-alpha/mmd-mock-beta）， 编排器经 ctx.llm.stream 取结果——适配器注册表、chunk 协议、usage 上报、终止 finish 全部是真实代码路径，只有供应商网络被替换。

testDoubles.mode: 'dsh-adapter' 时配置校验器强制全部参与者为 mmd-mock-*，防止误打真实 API。

模拟结果不是真实多模型效果：模拟运行产出的 deliverable.md 顶部会写明这一点， 验收报告也单列。

只读研究工具

lib/core/research.js 实现 read_file / list_dir / stat / locate，全部限定在 research.roots 白名单内；没有写、删除、执行或联网操作。第 2 步的席位自行决定要查什么，proposal-research.js 校验路径、文件大小与请求数量后，由程序执行并将结果仅回填该席位。第 5 步也由程序执行取证。 工具执行与资料覆盖可审计：运行日志和节点记录保留实际调用、拒绝与 sha256。 模型声称 document/runtime 证据但没有工具调用记录时，账本会把结论降级为 insufficient 并写下降级原因。

已知限制

• 席位调查仅限配置的本地只读根目录，不能自行联网、执行测试或读取范围外资料；未取得资料时应保留待验证项。
• 观点编号和逐项处置校验只检查结构与可追溯性。审查与最终验收仍须判断理由、原始资料和最终稿是否吻合；原提案正文在输入预算不足时可能未进入单次审查，审查者必须说明覆盖局限。
• 第 4 步审查和第 7 步验收可各自申请一轮最多 4 项本地只读查询；每位审查者最多 4 项与 16,000 字符上限，验收也最多 4 项与 16,000 字符。查询合同与执行器共用字段校验：locate 必须提供 1–5 个 include 定位词，read_file 每次最多 200 行；格式错误会在执行前触发格式修复。仅允许白名单根目录内的读取、列目录、元数据和文本定位；没有联网、执行命令或写入。执行结果会以不可变证据快照保存，并在返修和重新验收中复用；旧稿的覆盖范围不会自动算作当前稿覆盖。验收项必须引用类型匹配的支持证据，最终报告记录引用的证据编号、原稿版本与来源哈希。
• 交付中的提案观点处置表记录的是初稿整合决定；后续修订是否仍保留该观点须对最终稿复核。
• 运行中的 Host 若在插件源码改动后未重启，仍执行旧模块代（Node ESM 缓存）。源码改完不等于线上生效：先用 describe 的版本号核对，再重启 Host。
• 金额预算未实现：仅在单价与计费规则可信时才应启用。
• M2 部分实现：断点续跑已可用（见下节），中途改约束、受影响版本失效、多轮问题路由仍未实现。
• 续跑默认允许普通节点重派，但模型调用可能重复计费，续跑计划会标出 mayRebill。显式列入 sideEffectingNodes 的节点须有可信的 preDispatch 证明才可自动重派；无法证明时仅能审计后 force。
• 验收为 needs_revision 且必需项没有 unverified 时，系统按未满足项与最小动作自动定向修订一次，再用新上下文独立验收一次；版本不可变，记录保留原判定与返修链。仍未通过即结束。blocked_evidence 不触发返修，须补齐证据后另行处理。额外模型调用仍计入原运行的总时限与 token 预算；额度不足会按现有预算规则停止。
• 版本命名自 0.1.0 起带参与者维度；此前生成的 runs/ 保留原名，不做迁移、不篡改历史记录。

断点续跑（M2）

失败的运行不必从需求重新跑。已提交的阶段产物（需求基线、提案、观点清单、初稿、处置表、 审查问题账本）都在磁盘上，续跑会复用它们，只从第一个未提交的阶段继续。

用法

# 先看能不能续、从哪续（只读查询；当前 HTTP 入口要求 POST）
curl -X POST http://127.0.0.1:3080/mmd/api \
  -H "Content-Type: application/json" \
  -d '{"op":"resume-plan","runId":"run_xxx"}'

# 续跑
curl -X POST http://127.0.0.1:3080/mmd/api \
  -H "Content-Type: application/json" \
  -d '{"op":"resume","runId":"run_xxx"}'

resume-plan 返回 resumable、resumeFrom、committedKinds、lastFailure（含 sideEffectFree 判定）、mayRebill / rebillRisks 与 totals。工具侧对应 discussion_resume 与 discussion_resume_plan。

允许续跑的条件

两半都要成立，缺一不可：

1. 位置：状态属于 call_failed / interrupted / stopped，且存在未提交的后续阶段。 accepted、needs_revision、needs_evidence 是有意的终态，不是重试对象。
2. 安全：重发只能重复“工作”，不能重复“外部副作用”。内置流水线没有任何会写外部状态的 节点（研究工具只读，其余节点都是单次模型调用，且节点内部本来就会对超时/传输做有限重试）， 因此普通节点上的失败可在阶段提交、版本和账本一致性检查通过后续跑；计划会列出可能重复计费的调用。 部署若新增带副作用的节点，把它列入 sideEffectingNodes； 这些节点上的失败继续按严格规则判定：只有适配器明确证明请求未派发（preDispatch=true） 且无用量，才能自动续跑；错误码和短耗时本身不是证明。

以下情况拒绝，绝不猜测：

情形	拒绝原因	为什么
副作用节点 + 超时、传输中断	SIDE_EFFECT_UNKNOWN	上游可能已执行、响应丢失，结果未知；非副作用节点不受此限
副作用节点 + 调用报了 usage	SIDE_EFFECT_UNKNOWN	已计费说明确实跑了；非副作用节点不受此限
副作用节点 + 参数错误但无可信派发前证明	SIDE_EFFECT_UNKNOWN	不能用错误码或耗时单独放行
无任何失败记录	FAILURE_NOT_RECORDED	未知即不安全
只能从 evidence 之后续	RESUME_PAST_EVIDENCE_UNSUPPORTED	见下
其他实例的执行者心跳未过期	EXECUTOR_LEASE_HELD	该运行正被别的实例执行，续跑会双跑

节点达到输出上限（node/output-truncated）时，普通节点可从未提交阶段重派；该次模型调用 可能已经计费，计划会提示 mayRebill。显式副作用节点仍须通过安全门槛。

仅当拒绝原因为 SIDE_EFFECT_UNKNOWN 时，人工确认后可用 force: true 覆盖副作用安全门槛。 强制会在事件流里留下 run/resume-forced 记录（含被覆盖的拒绝原因）；它不能覆盖阶段、 版本或账本完整性检查。

执行者租约（多实例与热重载）

进程内的活跃登记（liveRuns）看不到别的 DSH 进程，也看不到热重载前遗留的老实例。运行目录里 因此多了一份心跳文件 executor-lease.json：

• 每个执行者在开跑前获取租约，并按 executorHeartbeatMs（默认 30s）续期；
• 恢复扫描（reconcile）只把心跳过期的运行标记为 interrupted，别的实例正在心跳的运行 会被跳过（不再出现“标记中断、执行者照跑”的 split-brain）；
• discussion_status 的 live 现在表示“有实例在跑”（含其他进程），并返回 executorLease 详情；
• stop 对另一个进程的运行会把停止标志落盘，对方心跳读到后中止在途调用（最长一个心跳周期）；
• 续跑前会检查租约，心跳未过期一律拒绝（EXECUTOR_LEASE_HELD）；
• 状态文档写入带归属保护：interrupted / stopped 只能由显式 reopen（续跑）离开，过期快照 无法把已终结的运行写回 running。

相关配置：executorLeaseTtlMs（默认 600000，心跳超过该时长视为执行者已死）、 executorHeartbeatMs（默认 30000）、sideEffectingNodes（默认空数组）。

已知限制

• 不能从 evidence 之后续跑。 覆盖事实虽已按问题和稿件版本落盘，但修订后的重新取证与 验收恢复尚未完成；若跳过这一步，旧稿覆盖可能被误用。因此续跑在 evidence 处停止。
• 模型可能在响应已结算后、节点记录保存前中断；这种 call-settled-unrecorded 会在计划中提示 重复计费风险，显式副作用节点仍需人工审计后的强制续跑。
• 旧版运行若缺少提案清单等必需产物，返回 RESUME_MIGRATION_REQUIRED，不会猜测重建。
• 续跑复用运行原 id、课题、约束与已提交产物：是同一个运行被继续，不是新建运行。
• 复用已提交阶段、完整保存并通过校验的提案席位，以及同稿同轮且审计记录齐全的证据问题。其余未提交工作照常调用模型。