dsh-workplan 1.5.1 → 1.6.0

package/src/host.ts

@@ -325,7 +325,7 @@ export function apply(ctx: any, config: WorkplanConfig = {}) {
 
 export const meta = {
   name,
-  version: '1.5.1',
+  version: '1.6.0',
   promptOrder: PROMPT_ORDER,
   routes: ['/dsh-workplan/plans', '/dsh-workplan/vendor/chart.umd.js'],
 }

package/src/plan.ts

@@ -1074,8 +1074,16 @@ export function applyStatus(statuses: any, subtaskId: any, patch: any) {
     if (patch.summary === undefined) next.summary = ''
     if (patch.error === undefined) next.error = null
   }
-  if (patch.status === 'in_progress' && next.startedAt === null) {
-    next.startedAt = Date.now()
+  if (patch.status === 'in_progress') {
+    if (next.startedAt === null) next.startedAt = Date.now()
+    /*
+     * [1.5.2] 「正在做」不允许自称 100%。
+     *
+     * 工具允许 `{status:'in_progress', progress:100}`，界面于是出现
+     * 「正在做 + 进度 100%」，计划层再叠一个环 0% / 加权 100%（T5 C8）。
+     * 完成只能由 status='done' 表达，progress 到 99 就是这一步的上限。
+     */
+    if (Number(next.progress) >= 100) next.progress = 99
   }
   if (patch.status === 'blocked' && next.finishedAt === null) {
     next.finishedAt = Date.now()
@@ -1272,6 +1280,16 @@ export function deriveAggregates(statuses: readonly StatusEntry[]): {
   }
 
   const total = statuses.length
+  const allDone = total > 0 && done === total
+  /*
+   * [1.5.2] 加权进度在「未全部完成」时不得四舍五入成 100。
+   *
+   * 旧算法直接 `round(progressSum / total)`：11 个 done + 1 个 blocked@95 得到
+   * 100，卡片上就出现「总体进度 100%」旁边还有「1 卡住了 / 11/12 做好了」——
+   * 与截图同类的自相矛盾（T4 实测 A.5）。这里的封顶只作用于展示口径，不影响
+   * 任何计数；全部完成时仍严格为 100，从而与 `done === total` 一一对应。
+   */
+  const raw = total === 0 ? 0 : Math.round(progressSum / total)
   return {
     stats: {
       total,
@@ -1279,7 +1297,7 @@ export function deriveAggregates(statuses: readonly StatusEntry[]): {
       blocked,
       inProgress,
       pending,
-      progress: total === 0 ? 0 : Math.round(progressSum / total),
+      progress: allDone ? 100 : Math.min(99, raw),
     },
     departments: [...departments.values()],
   }
@@ -1309,13 +1327,18 @@ export function computeStats(statuses: any): Stats {
 }
 
 /**
- * Invariant checker for tests and CI; production paths never call it because
- * pure derivation is already self-consistent.
+ * Invariant checker for tests and CI.
  *
  * Returns an empty array when every invariant holds. Each message names the
  * field and the observed value so it can be pasted straight into a report.
+ *
+ * [1.5.2] `phase` 是新增的可选入参：1.4.3 的 I1–I7 只校验计数内部自洽，
+ * 完全不看 `phase` 与 `stats` 的关系，因此「14/14 且 progress=100 却写着
+ * 正在收尾」这种**跨字段**矛盾一路畅通到界面。I8/I9 专门封住这一类：
+ * 只要调用方把本次真正要下发的 phase 传进来，任何「进度与状态文案打架」
+ * 的载荷都会在这里被判为违规，而不是等到用户看截图。
  */
-export function aggregateInvariantViolations(snapshot: PlanSnapshot): string[] {
+export function aggregateInvariantViolations(snapshot: PlanSnapshot, phase?: any): string[] {
   const violations: string[] = []
   const { statuses, stats, departments } = snapshot
 
@@ -1371,17 +1394,96 @@ export function aggregateInvariantViolations(snapshot: PlanSnapshot): string[] {
     violations.push(`I7 各部门 inProgress 之和=${sums.inProgress} 与 stats.inProgress=${stats.inProgress} 不一致`)
   }
 
+  /*
+   * [1.5.2] I8/I9 —— 完成语义跨字段不变量（用户截图那条「100% + 正在收尾」）。
+   *
+   * I8：工作项全部 done ⇔ phase 必须是 done。这是一条双向断言：
+   *     - 全 done 却是 pending/planning/executing/integrating/paused/blocked/degraded
+   *       ⇒ 卡片会同时出现 100% 与进行中文案（本次事故）；
+   *     - phase=done 却还有未完成项 ⇒ 反向矛盾（「已完成」下面挂着没做完的活）。
+   * I9：加权进度与计数同口径：全 done ⇒ 100；未全 done ⇒ 不得为 100。
+   *     旧算法 round(progressSum/total) 让 11 done + 1 blocked@95 算出 100。
+   */
+  if (stats.total > 0) {
+    const allDone = stats.done === stats.total
+    if (allDone && phase !== undefined && phase !== null && phase !== 'done') {
+      violations.push(`I8 stats.done=${stats.done}/${stats.total} 已全部完成，但 phase=${String(phase)} 仍表示未完成`)
+    }
+    if (!allDone && phase === 'done') {
+      violations.push(`I8 phase=done 但 stats.done=${stats.done}/${stats.total} 尚未全部完成`)
+    }
+    if (allDone && stats.progress !== 100) {
+      violations.push(`I9 全部完成但 stats.progress=${stats.progress}`)
+    }
+    if (!allDone && stats.progress >= 100) {
+      violations.push(`I9 未全部完成（${stats.done}/${stats.total}）却显示 stats.progress=${stats.progress}`)
+    }
+  }
+  /*
+   * I10：单个工作项也不能自相矛盾——`in_progress` 意味着「还没做完」，
+   * 它的进度必须 < 100（旧载荷里出现过「正在做 + 100%」，T5 C8）。
+   */
+  for (const item of statuses) {
+    if (item?.status === 'in_progress' && Number(item?.progress) >= 100) {
+      violations.push(`I10 子任务 ${String(item?.subtaskId)} 状态为 in_progress 但 progress=${item?.progress}`)
+    }
+  }
+
   return violations
 }
 
-export function planPhase(statuses: any, resultSeen = false) {
+/**
+ * 计划级阶段，由状态列表唯一决定。
+ *
+ * [1.5.2] 修复「一边 100%、一边正在收尾」的根因。
+ *
+ * 旧实现的最后一步是 `return resultSeen ? 'done' : 'integrating'`：工作项全部
+ * done 时仍要等「结果消息落盘」才晋升终态。问题在于 `resultSeen` 只是**持久化
+ * 回放**才知道的副作用，内存路径（`updateStatus` / `serialisePlan`）拿不到它：
+ *
+ *  - 主 Agent 用 `dsh_workplan_update` 补完最后几项时，phase 永远停在 integrating；
+ *  - 该路径不会再派发，也就永远不会写结果消息，于是 integrating 永久留存；
+ *  - 同期 `stats.done/total` 已是 14/14、百分比 100%，卡片就同时显示
+ *    「100% · 都做完了」和「正在收尾」，并留在「进行中」组（用户截图）。
+ *
+ * 结论：完成语义只能有一个事实源——状态列表。工作项全部完成即计划完成，
+ * 不需要也不允许等另一个副作用来「确认」。`resultSeen` 参数仅为兼容旧调用点保留，
+ * 不再参与判定（旧的 integrating 窗口已由 dispatch 内的 `executing` 覆盖）。
+ */
+export function planPhase(statuses: any, _resultSeen = false) {
   if (statuses.length === 0) return 'pending'
-  if (statuses.every((item: any) => item.status === 'done')) return resultSeen ? 'done' : 'integrating'
+  if (statuses.every((item: any) => item.status === 'done')) return 'done'
   if (statuses.some((item: any) => item.status === 'blocked')) return 'blocked'
   if (statuses.some((item: any) => item.status === 'in_progress' || item.status === 'done')) return 'executing'
   return 'pending'
 }
 
+/**
+ * 把「缓存的 phase」与「由状态列表派生的 phase」对账成唯一结果。
+ *
+ * phase 是缓存（dispatch/预算/取消会写它），statuses 是事实源。只要两者可能
+ * 分叉，就必须在出口处对账，否则同一个会话会因读取路径不同而翻转（实时
+ * integrating / 刷新后 done，T2 场景 B）。
+ *
+ * 规则只有四条，全部可由 `aggregateInvariantViolations` 断言：
+ *  1. 工作项全部 done ⇒ 一定是 done（缓存不得把它拖回任何进行中状态）；
+ *  2. 缓存是 done/integrating 但工作项没全 done ⇒ 缓存过期，回退到派生值；
+ *  3. pending/planning/executing 是「状态列表能直接回答」的轮次状态：一旦
+ *     有工作项开始（派生值不再是 pending），缓存里的旧 pending/planning 必须
+ *     让位；而派生值仍是 pending 时保留缓存（dispatch 刚开始、状态尚未落盘）。
+ *  4. 其余情况保留缓存的轮次状态（paused/cancelled/blocked/degraded）——
+ *     它们携带状态列表里没有的信息（预算暂停、用户取消）。
+ */
+export function reconcilePhase(phase: any, statuses: any) {
+  const derived = planPhase(statuses)
+  if (derived === 'done') return 'done'
+  if (phase === 'done' || phase === 'integrating') return derived
+  if (phase === 'pending' || phase === 'planning' || phase === 'executing') {
+    return derived === 'pending' ? phase : derived
+  }
+  return phase ?? derived
+}
+
 export function nextReadyInStage(plan: any, statuses: any[], stageId: string) {
   const byId = new Map(statuses.map((item: any) => [item.subtaskId, item]))
   const stage = plan.stages.find((item: any) => item.id === stageId)

package/src/runtime.ts

@@ -17,6 +17,7 @@ import { randomUUID } from 'node:crypto'
 import {
   MAX_CONCURRENT,
   PlanError,
+  aggregateInvariantViolations,
   applyStatus,
   attachPlanMeta,
   buildChildPrompt,
@@ -43,6 +44,7 @@ import {
   parseResultMessage,
   parseWorkplanMessage,
   planPhase,
+  reconcilePhase,
   truncate,
   validatePlan,
   applyResultStatuses,
@@ -800,21 +802,30 @@ export async function dispatchPlan(ctx: any, record: any, options: any) {
         })
       }
       record.statuses = reset
-      record.phase = 'paused'
       const total = record.statuses.length
       const done = record.statuses.filter((item: any) => item.status === 'done').length
+      /*
+       * [1.5.2] 预算到点 ≠ 一定是「暂停」。
+       *
+       * 旧代码在这里无条件 `record.phase = 'paused'`：如果最后一个子任务恰好在
+       * 截止时刻之后完成（done === total），计划会以 14/14、progress=100 的载荷
+       * 带着 paused 返回，界面就是「100% + 预算用完，可续跑」（T5 C4）。
+       * 全部完成时直接进终态，并且不再写「其余 0 项保留为未完成」这种自相矛盾的说明。
+       */
+      const allDoneNow = total > 0 && done === total
+      record.phase = allDoneNow ? 'done' : 'paused'
       const minutes = Math.max(1, Math.round((options.totalTimeoutMs ?? TOTAL_TIMEOUT_MS) / 60000))
-      record.error = `本轮执行预算（${minutes} 分钟）已到：已完成 ${done}/${total}，其余 ${total - done} 项保留为未完成，再次派发本计划即可续跑（已完成的不重跑）`
+      record.error = allDoneNow
+        ? null
+        : `本轮执行预算（${minutes} 分钟）已到：已完成 ${done}/${total}，其余 ${total - done} 项保留为未完成，再次派发本计划即可续跑（已完成的不重跑）`
       /*
        * Drop the failure lines the aborted children wrote on their way out.
        * They used to survive into the result payload as
        * `["T4: 总执行超时", "总执行超时", …]`, so the model read a failure
        * report for subtasks that were explicitly *not* failures.
        */
-      record.errors = [
-        ...(record.errors ?? []).filter((line: string) => !/总执行超时/.test(String(line))),
-        record.error,
-      ].slice(-20)
+      record.errors = (record.errors ?? []).filter((line: string) => !/总执行超时/.test(String(line)))
+      if (!allDoneNow) record.errors = [...record.errors, record.error].slice(-20)
     } else {
       /*
        * `blocked` is a terminal state, so it always reports progress 100 — the
@@ -845,6 +856,58 @@ export async function dispatchPlan(ctx: any, record: any, options: any) {
   return record
 }
 
+/*
+ * [1.6.0] 会话「这一轮到底还在不在跑」的唯一事实源。
+ *
+ * 事故（session-7129faea…）：会话早已结束，面板仍把计划列在「进行中」组，
+ * 卡片写着「预算用完，可续跑」——没有任何东西在跑，状态却表示正在跑。
+ *
+ * 根因：插件只订阅 `agent/pre-step`，`turn/end`、`session/disposed` 全都收不到；
+ * 计划状态因此只由「派发结果」驱动，而派发结束后不再有任何事件把它收敛。
+ *
+ * 修复不引入第二个事件订阅（跨 scope 的事件投递受 scope 过滤，不可靠；而且
+ * 订阅只覆盖实时路径，刷新/重启后全靠回放，两条链路一旦不同源就会来回翻转）。
+ * 这里直接读会话日志本身——它既是实时事实，也是回放事实：
+ *
+ *  - 从末尾向前找最近的一条「轮次边界」事件：先遇到 `turn/end` ⇒ 这一轮已结束；
+ *    先遇到 `turn/start` ⇒ 这一轮还开着；都没找到 ⇒ 未知，调用方保持原判定。
+ *  - 不存在「会话已结束」这种事件：宿主只有每轮 `turn/end`。因此**不能**把
+ *    `turn/end` 直接等同于「计划取消/完成」——一轮结束后可以随时续跑，这也是
+ *    卡片提供「可续跑」的原因。它只证明「此刻没有东西在跑」。
+ *  - 向后扫描设上限，避免越界；超过上限就返回 unknown，绝不猜测。
+ */
+const TURN_BOUNDARY_SCAN = 200
+
+export function sessionTurnState(session: any) {
+  const total = Number(session?.seq)
+  if (!Number.isFinite(total) || total <= 0 || typeof session?.eventAt !== 'function') {
+    return { state: 'unknown', reason: null, reasonDetail: null, at: null }
+  }
+  const floor = Math.max(0, Math.floor(total) - TURN_BOUNDARY_SCAN)
+  for (let seq = Math.floor(total) - 1; seq >= floor; seq -= 1) {
+    let event
+    try {
+      event = session.eventAt(seq)
+    } catch {
+      return { state: 'unknown', reason: null, reasonDetail: null, at: null }
+    }
+    if (!event) continue
+    if (event.type === 'turn/start') return { state: 'open', reason: null, reasonDetail: null, at: null }
+    if (event.type === 'turn/end') {
+      const reason = event.data?.reason ?? null
+      const detail = reason && reason.kind === 'aborted' ? (reason.reason?.kind ?? null) : null
+      const at = Number(event.time)
+      return {
+        state: 'ended',
+        reason: typeof reason?.kind === 'string' ? reason.kind : 'completed',
+        reasonDetail: typeof detail === 'string' ? detail : null,
+        at: Number.isFinite(at) ? at : null,
+      }
+    }
+  }
+  return { state: 'unknown', reason: null, reasonDetail: null, at: null }
+}
+
 function serialisePlan(record: any, session: any) {
   const plan = record.plan ?? null
   /*
@@ -865,15 +928,61 @@ function serialisePlan(record: any, session: any) {
   )
   const statuses = snapshot.statuses
   const stats = snapshot.stats
-  let phase = record.phase ?? (plan ? planPhase(statuses) : 'degraded')
+  /*
+   * [1.5.2] 出口对账，而不是无条件相信内存缓存。
+   *
+   * 旧写法 `record.phase ?? planPhase(statuses)` 让缓存一旦存在就完全绕过
+   * statuses：一次 `updateStatus` 把计划写成 integrating 之后，即使 14/14 全部
+   * 完成，下发的 phase 仍是 integrating，界面于是「100% + 正在收尾」。这里改成
+   * `reconcilePhase`：全部完成一律 done，缓存过期的 done/integrating 回退到派生值。
+   */
+  let phase = reconcilePhase(record.phase ?? (plan ? planPhase(statuses) : 'degraded'), statuses)
   if (phase === 'pending' && !record.dispatchedAt && plan?.createdAt && Date.now() - plan.createdAt > STALE_PENDING_MS) {
     phase = 'cancelled'
   }
+  /*
+   * [1.6.0] 终态收敛：这一轮已经结束，而计划没有完成 ⇒ 不许再显示「进行中」。
+   *
+   * `phase` 到这里为止只由「派发动作」写入（executing / paused / blocked …），
+   * 而派发结束后没有任何事件把它改回来，于是会话结束、进程空闲、面板却仍在
+   * 「进行中」组里（事故截图）。上面 `sessionTurnState` 用会话日志回答
+   * 「此刻还有没有东西在跑」，这里把答案落成独立阶段 `ended`：
+   *
+   *  - done / cancelled 已经是终态，不再改写（done 改写会直接违反不变量 I8）；
+   *  - 其余阶段一律收敛为 `ended`，并把原阶段留在 `suspendedPhase` 里，
+   *    卡片因此仍能显示「预算用完，可续跑」「卡住了」这类二级事实，不丢信息；
+   *  - 只改**下发出去的那一份**，不动 `record.phase`：用户说「继续」后同一轮
+   *    重新开始（日志里出现新的 turn/start），下一份 payload 自然回到原来的
+   *    派发状态，不需要任何反向迁移逻辑；
+   *  - 实时路径与回放路径都经过本函数，因此刷新前后结论必然一致（T4 硬约束）。
+   */
+  let suspendedPhase: any = null
+  let endReason: any = null
+  let endReasonDetail: any = null
+  let endedAt: any = null
+  if (phase !== 'done' && phase !== 'cancelled') {
+    const turn = sessionTurnState(session)
+    if (turn.state === 'ended') {
+      suspendedPhase = phase
+      endReason = turn.reason
+      endReasonDetail = turn.reasonDetail
+      endedAt = turn.at
+      phase = 'ended'
+    }
+  }
+  /*
+   * 每次真正下发前跑一遍跨字段不变量（I1–I10）。正常情况下恒为空；一旦某个
+   * 未来改动重新引入「进度与状态打架」，这里会把它连同具体字段值一起带出去，
+   * 而不是等用户截图发现。附在 payload 上而不是抛错：展示层不应因自检而白屏。
+   */
+  const violations = aggregateInvariantViolations(snapshot, phase)
   return {
     sessionId: session.id,
     planId: record.planId ?? plan?.planId ?? null,
     title: plan?.title ?? record.title ?? '任务进度',
     phase,
+    ...(phase === 'ended' ? { suspendedPhase, endReason, endReasonDetail, endedAt } : {}),
+    ...(violations.length ? { violations } : {}),
     degraded: record.degraded === true,
     error: record.error ? truncate(record.error, 2000) : null,
     errors: (record.errors ?? []).slice(-20),
@@ -940,6 +1049,8 @@ export function reconstructFromSession(session: any, targetPlanId?: string) {
    * plan and let the caller ask for a specific one.
    */
   const finished: any[] = []
+  /** [1.6.0] callId → 待确认的 update 写入；只有配对的 tool/result 才能定案。 */
+  const pendingToolCalls = new Map<string, any>()
   const snapshot = () => ({ plan, statuses, resultPhase, resultSeen, resumeCount, cancelled })
   for (let seq = start; seq < session.seq; seq += 1) {
     let event
@@ -987,19 +1098,42 @@ export function reconstructFromSession(session: any, targetPlanId?: string) {
         cancelled = true
       }
     } else if (event.type === 'tool/call' && plan) {
+      /*
+       * [1.6.0] 只登记，不下结论。
+       *
+       * 回放原来一见到 `dsh_workplan_update` 的调用就 applyStatus，但调用发起不等于
+       * 状态写入成功：宿主的 tool/result 带着 `message.isError`。会话
+       * session-7129faea 里就有一次失败的 update 被回放记成完成，于是刷新后面板显示
+       * 7/12，而真实只完成 6/12 —— 回放比实时“更乐观”，这是第二个数据源打架点。
+       * 现在一律等对应的 tool/result：成功才采纳，失败或没有结果都不采纳。
+       */
       const data = event.data
-      if (data?.name === 'dsh_workplan_update') {
+      if (data?.name === 'dsh_workplan_update' && typeof data.callId === 'string') {
         const args = readToolArguments(data.arguments)
         if (args && typeof args.subtaskId === 'string' && typeof args.status === 'string') {
-          try {
-            statuses = applyStatus(statuses, args.subtaskId, {
-              status: args.status,
-              progress: typeof args.progress === 'number' ? args.progress : undefined,
-              summary: typeof args.note === 'string' ? args.note : undefined,
-            })
-          } catch {
-            // An invalid historical call is ignored; the live cache remains authoritative.
-          }
+          pendingToolCalls.set(data.callId, { args, planId: plan.planId })
+        }
+      }
+    } else if (event.type === 'tool/result') {
+      const message = event.data?.message
+      const callId = message?.role === 'tool' ? message.toolCallId : null
+      if (typeof callId !== 'string') continue
+      const pending = pendingToolCalls.get(callId)
+      pendingToolCalls.delete(callId)
+      if (!pending || !plan || pending.planId !== plan.planId) {
+        // 结果晚于新计划到达：旧计划的写入不污染新计划的状态表。
+      } else if (message.isError === true) {
+        // 失败的更新不是完成：状态表保持原样。
+      } else {
+        const args = pending.args
+        try {
+          statuses = applyStatus(statuses, args.subtaskId, {
+            status: args.status,
+            progress: typeof args.progress === 'number' ? args.progress : undefined,
+            summary: typeof args.note === 'string' ? args.note : undefined,
+          })
+        } catch {
+          // An invalid historical call is ignored; the live cache remains authoritative.
         }
       }
     }
@@ -1028,6 +1162,15 @@ export function reconstructFromSession(session: any, targetPlanId?: string) {
   let phase = planPhase(statuses, resultSeen)
   if (resultPhase === 'paused' && statuses.some((item: any) => item.status !== 'done')) phase = 'paused'
   if (cancelled) phase = 'cancelled'
+  /*
+   * [1.5.2] 回放也必须走同一套对账。
+   *
+   * 回放曾经因为 `resultSeen=true`（结果消息在会话里）得到 done，而同一时刻的
+   * 实时缓存因为没有这个副作用得到 integrating —— 同一个会话刷新前后翻转。
+   * `reconcilePhase` 让两条链路都以 statuses 为准：全部完成即 done（包括历史上
+   * 「先完成、后收到取消消息」的会话，不再出现「100% + 已取消」）。
+   */
+  phase = reconcilePhase(phase, statuses)
   /*
    * An old plan that was never dispatched used to be relabelled `cancelled`,
    * which also made it permanently unresumable — the card said "已取消" and no
@@ -1206,7 +1349,16 @@ export function createWorkplanRuntime(ctx: any, options: WorkplanRuntimeOptions
     if (status === 'blocked') {
       record.statuses = markDependentsBlocked(record.plan, record.statuses, subtaskId)
     }
-    record.phase = planPhase(record.statuses)
+    /*
+     * [1.5.2] 这里曾是「100% + 正在收尾」的直接入口。
+     *
+     * 旧代码 `record.phase = planPhase(record.statuses)` 用不到 `resultSeen`，
+     * 所以主 Agent 用 update 工具补完最后一项时得到的 phase 永远是 integrating；
+     * 而这条路径之后不会再派发，也就永远不会写结果消息把它晋升为 done。
+     * 走 `reconcilePhase` 后，全部完成即 done，且已 done 的计划不会被一次
+     * 空更新打回 integrating（T4 实测 A.2 的回退路径）。
+     */
+    record.phase = reconcilePhase(record.phase, record.statuses)
     record.updatedAt = Date.now()
     const snapshot = derivePlanSnapshot(record.statuses)
     return {
@@ -1231,6 +1383,29 @@ export function createWorkplanRuntime(ctx: any, options: WorkplanRuntimeOptions
     const reason = typeof args?.reason === 'string' && args.reason.trim()
       ? args.reason.trim()
       : '用户取消'
+    /*
+     * [1.5.2] 已完成即终态：取消不再把 100% 的计划改写成「已取消」。
+     *
+     * T4 实测 A.4：2/2 全部 done 的计划被取消后会得到 `phase=cancelled` +
+     * `done=2/2` + `percent=100` —— 又一个「一边说全好了、一边说被取消」的
+     * 自相矛盾组合，且会让本可续跑/查看的完成记录永远退出「已完成」组。
+     * 这里直接把取消变成 no-op 并如实返回 done。
+     */
+    const before = derivePlanSnapshot(record.statuses)
+    if (before.stats.total > 0 && before.stats.done === before.stats.total) {
+      record.phase = 'done'
+      record.updatedAt = Date.now()
+      state.records.set(session.id, record)
+      return {
+        ok: true,
+        planId: record.plan.planId,
+        phase: 'done',
+        reason,
+        alreadyDone: true,
+        abortedRunning: false,
+        stats: before.stats,
+      }
+    }
     if (record.dispatchPromise) {
       /*
        * Cancel must always work.
@@ -1411,9 +1586,14 @@ export function createWorkplanRuntime(ctx: any, options: WorkplanRuntimeOptions
         ctx.logger?.warn?.(`dsh-workplan: 写入结果消息失败：${error instanceof Error ? error.message : String(error)}`)
       }
     }
-    if (record.resultWritten && record.statuses.length > 0 && record.statuses.every((item: any) => item.status === 'done')) {
-      record.phase = 'done'
-    }
+    /*
+     * [1.5.2] 终态不再依赖「结果消息写成功」这个副作用。
+     *
+     * 旧代码只有 `record.resultWritten === true` 时才把 phase 升成 done，
+     * 于是 session.append 抛错（或该轮根本没有派发）就会永久停在 integrating。
+     * 完成语义由 statuses 决定；结果消息只负责持久化，不负责定义完成。
+     */
+    record.phase = reconcilePhase(record.phase, record.statuses)
     /*
      * The model's dispatch result reports the same snapshot the dashboard will
      * show. It used to send `record.stats` while the status list below was read