@shgroup/dsh-serenity-hooks 1.91.0 → 1.93.0

package/dsh.plugin.json

@@ -1,6 +1,6 @@
 {
   "id": "dsh-serenity-hooks",
-  "version": "1.91.0",
+  "version": "1.93.0",
   "main": "lib/index.js",
   "description": "宁静号 ACC harness（Native Cordis 插件）：给 DSH 装一个「AI 工作区」——14 个工具（container_fs/cognitive_trajectory/dashboard/container_git/msm/praxis/ontology/serenity-skill-creator/cheap-worker/localstore/container_admin；另三个 im-bridge/acc-diag/diagram 按配置条件出现）+ 机械约束（安全模式/工作区围墙/密钥守卫）+ 认知轨迹日志与原地重建 + 网页登录入口/IM 桥/认知轨迹唤醒注册表。轨迹声明 = 轨迹目录下的 trajectory.json（约束面 + 旧标识 uid + CRO 机器绑定 cro.host；旧名 trajectory-constraint.json / skiff.json 仍在读取族里）；轨迹提示词 = 轨迹目录下的 PROMPT.md（一条轨迹「是谁、按什么章程工作」，所有轨迹通用，追加在容器层与质量层之后，不替换它们）。适配 DSH 0.1.7-rc.1 / 0.2.0-rc.1 / 0.2.1-rc.1（三档，deepseek-ai/deepseek-harness）。",
   "engines": {

package/lib/index.js

@@ -8957,10 +8957,14 @@ function appendCroWakeLog(root, dirName, input, nowMs = Date.now()) {
 *
 * ## 判据（三条同时成立，缺一不可）
 *
-* 1. 日志里**最后一条 `turn/end`** 的 `reason.kind === 'interrupted'`；
+* 1. 日志里**最后一条 `turn/end`** 的 `reason.kind` ∈ {@link UNFINISHED_KINDS}
+*    （= `interrupted` 崩溃补收尾 ／ `aborted` 正常终止，两者都是"这一轮没收完"）；
 * 2. 该 `turn/end` **之后没有新的 `turn/start`**（否则已被后续轮次接续）；
 * 3. ⛔ **不要求**末条是 `session/end-seed`（2026-10-23 放宽，原因见 {@link detectInterruptedEnd}）。
 *
+* 🔴 **2026-10-24 补入 `aborted`**：修前只认 `interrupted` ⇒「被正常终止」整类漏扫
+* （发布重启／换宿主最常见的形态）。判据问的是「这一轮收完了吗」，**不是"进程死得惨不惨"**。
+*
 * ⚠️ **为什么不能只看"存在过 interrupted"**：一个长会话历史上可能中断几十次
 * （本容器实测单会话 33 次）。只看"曾经中断"会把早已恢复的会话全部当成待续 ⇒ 灾难。
 *
@@ -9006,10 +9010,33 @@ const ZSTD_MAGIC = Buffer.from([
 ]);
 /** 默认回看窗口：8 小时（owner 2026-10-22 定） */
 const DEFAULT_LOOKBACK_MS = 288e5;
-/** 每次从文件尾部读取的字节数（够覆盖数百个末尾事件） */
-const TAIL_WINDOW_BYTES = 1 << 20;
-/** 需要凑够的末尾事件数（够跨过 turn/end + step/end + end-seed 即可，留余量） */
-const TAIL_EVENT_TARGET = 60;
+/**
+* 每次从文件尾部读取的字节数。
+*
+* 🔴 **2026-10-24 从 1 MiB 提到 8 MiB**：与 `TAIL_EVENT_TARGET` 提到 400 配套。
+* 1 MiB 常常装不下 400 个事件（大 step 的 `tool/result` 单条就可几十 KB）——
+* 那样"要 400 个"只是愿望，实际被字节数截断（**两种上限里小的那个说了算**）。
+*/
+const TAIL_WINDOW_BYTES = 8 << 20;
+/**
+* 需要凑够的末尾事件数。
+*
+* 🔴🔴 **2026-10-24 从 60 提到 400 —— 这是"啥都扫不到"的直接成因（实测，不是估算）**。
+*
+* 原值 60 的前提是「`turn/end` + `step/end` + `end-seed` 三个事件就在尾部附近」——
+* 那个前提**在"轮内被打断"时完全不成立**：
+*   · 一轮跑到一半死掉 ⇒ 尾部全是 `tool/call` / `tool/result` / `assistant/message` / `step/start`，
+*     **一条 `turn/start`／`turn/end` 都凑不齐**；
+*   · 实测本机 10 个窗口内会话，**4 个**在 60 事件窗口里凑不到 `turn/start`
+*     （被误判成"没开轮"）⇒ 换成 400 事件**全部命中**（turn=56/105/192/24）。
+*   · 最坏一条：57 MB 的日志里，一个 step 就可能塞进几十个 `tool/call`。
+*
+* ⚠️ **这不是"调参"，是判据前提变了**：一旦允许"轮内任意位置中断"这个形态，
+*    尾部窗口就**必须**宽到能跨过一整轮的碎片。
+* 💰 成本：解压帧数上升（实测 6 会话 × 400 事件仍是**几十毫秒**量级）——
+*    用几十毫秒换"不再漏掉一整类"，划算。
+*/
+const TAIL_EVENT_TARGET = 400;
 /**
 * 从文件尾部倒序解压，凑够 `want` 个事件。
 *
@@ -9053,34 +9080,59 @@ function readTailEvents(logPath, want) {
 	return events.slice(-want);
 }
 /**
-* 判定一组尾部事件是否「以 interrupted 结尾」。
+* 判定一组尾部事件是否「以未完成的轮次结尾」。
 * 不命中 → null。
 *
-* ## 🔴 2026-10-23 判据放宽（owner 实测：「不是挂在工具调用上的，也要能被 interrupted 筛选到并唤醒」）
+* ## 🔴🔴 2026-10-24 判据放宽（owner 报障：「有的会话在重启时不是崩溃的就扫不到，还是没修好」）
+*
+* ### 漏的是什么（宿主源码实读，非推测）
+*
+* 宿主只有**两条**会写出「轮次没收完」的 `turn/end`，而它们的 `kind` **不是同一个词**：
+*
+* | 形态 | 写谁 | `reason.kind` | 修前是否命中 |
+* |---|---|---|---|
+* | 进程**崩溃**／被强杀，下一轮 resume 时补收尾 | `interruptedTurnClosers()` → `openTurnClosers(events,{kind:'interrupted'})` | **`interrupted`** | ✅ |
+* | 进程**正常退出**（`restart-web` 的 SIGTERM、`agent/disposed`、用户中断） | 驱动 catch 里 `abortedCancelCause(signal)` | **`aborted`** ＋ 内层 `reason:{kind:'user'\|'parent'\|'disposed'\|'hook'}` | ❌ **漏** |
+*
+* ⇒ 修前只认 `interrupted` ⇒ **「被正常终止」这一大类全部漏掉**，而它恰恰是
+* **发布重启／换宿主** 最常见的形态（比崩溃常见得多）。
 *
-* ### 原判据（v1.87.4 起）为什么漏
-* 原来只认 **末条事件 = `session/end-seed`**。实测（本机 3337 条会话全扫）：
-*   · 末轮 `turn/end[interrupted]` 的会话 **26** 条；
-*   · 其中满足原判据的只有 **24** 条 ⇒ **漏 2 条**，形态逐字为：
-*     `… turn/end[interrupted] -> session/end-seed -> agent/inbox/spliced -> agent/inbox/spliced`
-*   ⇒ 重启后宿主把这**两条**追加在 end-seed 之后（它们是"恢复时把待办消息重新塞进收件箱"），
-*     于是"末条必须 end-seed"这条**在恢复动作发生之后就恒不成立**。
-*   ⚠️ 讽刺的是：**正是那些被恢复过、又再次被打断的会话**最容易长成这样
-*     ⇒ 原判据恰好对"反复中断"的会话失明，而它们才是最需要守护的。
+* 🔴 **这两条是同一个状态的两种成因，不是"一个对一个不对"**：
+* 判据问的是「**这一轮有没有收完**」，不是「进程死得惨不惨」。
+* 拿死法当判据 ⇒ 换一种死法就漏一批（这正是 owner 反复看到的"还是没修好"）。
 *
-* ### 新判据（三条，缺一不可）
-* 1. 日志里**最后一条 `turn/end`** 的 `reason.kind === 'interrupted'`；
-* 2. 该 `turn/end` **之后没有新的 `turn/start`**（否则说明它已被后续轮次接续）；
-* 3. ⛔ **不再要求末条是 `end-seed`**。
+* ### 为什么不能只加 `aborted` 就完事
+* `aborted.reason.kind` 里还可能有 `hook`（宿主主动 hook 取消）——它同属"没跑完"。
+* ⇒ 本判据**只看外层 `kind`**，理由：外层已经回答了"这一轮收完了吗"，
+*   内层回答的是"谁让它停的"，**那是另一个问题**，混进来会让判据随"谁取消的"漂移。
 *
-* ### 为什么不改成"末条必须是某个白名单"
-* 那就是原缺陷换个白名单再犯一次（`agent/inbox/spliced` 之外还会有别的）。
-* **判据要问的是"最后一轮的结束原因是什么、之后有没有新轮开始"**，
-* 而不是"日志最后一个 token 长什么样"——后者是**载体形态**，前者是**状态**。
+* ### ⛔ 刻意**不**纳入的形态（保守边界，写明理由）
+* - `error`：本轮**收完了**（宿主记了错误收尾），它不是"停在这里等人续"；
+* - 完全没有 `turn/end` 的开轮（例如日志末尾是 `turn/start` 后再无事件）：
+*   那**也可能是"进程正活着、这一轮正在跑"**，与真中断在读数上不可分
+*   ⇒ 纳入会误唤醒在跑的会话。⚠️ 这是**已知边界**，不是遗漏。
 *
 * ### 为什么不会误报"曾经中断但已恢复"
 * 恢复一定伴随 `turn/start`（新一轮）或新的 `turn/end`（`completed` 等）⇒ 判据 1／2 各自挡住。
-* 实测该放宽**不新增误报**：原 24 条全含于新判据（`curOnly = 0`），新增 2 条全是真漏。
+*/
+/**
+* 「这一轮没跑完」的 `turn/end.reason.kind` 取值域。
+*
+* 🔴🔴 **2026-10-24（owner 报障）**：原判据只认 `'interrupted'` 一个词 ⇒
+* **「被正常终止」整类漏扫**。两个值对应的形态见 {@link detectInterruptedEnd} 的头注。
+*
+* ⚠️ **这是判据的唯一取值点** —— 别在别处再写一份字面量（两份会漂）。
+*/
+const UNFINISHED_KINDS = /* @__PURE__ */ new Set(["interrupted", "aborted"]);
+/**
+* 命中判定（**形态 A：靠 `turn/end.reason.kind`**）。
+*
+* ⚠️ **本函数刻意不判「开了没收」** —— 那种形态与「此刻正在跑」在日志读数上**不可分**，
+* 只有扫描层手里有 `liveIds`（正在跑的会话 id）才判得准。
+* ⇒ 分工：**本函数判"收尾原因"，`scanInterruptedSessions` 判"开了没收"**（见 `detectUnclosedTurn`）。
+* ⛔ 不要把这些情形塞进本函数 —— 会让它同时依赖"日志形态"与"进程状态"，那种判据无法单独证伪。
+*
+* @returns 命中时给出被中断的轮次与"可能有副作用"的工具名；不命中 null
 */
 function detectInterruptedEnd(events) {
 	if (events.length === 0) return null;
@@ -9091,9 +9143,65 @@ function detectInterruptedEnd(events) {
 	}
 	if (idx < 0) return null;
 	const turnEnd = events[idx];
-	if (turnEnd?.data?.reason?.kind !== "interrupted") return null;
+	const kind = turnEnd?.data?.reason?.kind;
+	if (typeof kind !== "string" || !UNFINISHED_KINDS.has(kind)) return null;
 	for (let i = idx + 1; i < events.length; i++) if (events[i]?.type === "turn/start") return null;
-	const turn = typeof turnEnd.data?.turn === "number" ? turnEnd.data.turn : null;
+	const turn = typeof turnEnd?.data?.turn === "number" ? turnEnd.data.turn : null;
+	return {
+		turn,
+		pendingTools: findPendingTools(events, turn)
+	};
+}
+/**
+* 命中判定（**形态 B：一轮开了却没收**）—— 🔴🔴 **2026-10-24 owner 报障的正解**。
+*
+* ## 为什么这一格以前整类漏掉
+*
+* 进程在**轮内任意位置**死掉时，宿主**永远没机会写 `turn/end`**
+* ⇒ 日志就停在 `tool/call` ／ `step/start` ／ `assistant/message` 上。
+* 修前 `detectInterruptedEnd` 首行是 `if (idx < 0) return null`（找不到 turn/end 就放弃）
+* ⇒ **这一整类被判成"没中断"**。
+*
+* ## 判据
+* **最后一条 `turn/start` 之后没有 `turn/end`** ⇒ 那一轮开了没收。
+*
+* ## 为什么必须由**扫描层**调用（而不是并进 `detectInterruptedEnd`）
+* 「开了没收」与「此刻正在跑」在**日志读数上完全一样**。
+* 唯一能分开它们的东西是 `liveIds`（宿主报的"此刻在跑的会话"）——
+* 而那是**扫描层**的参数，不是日志的属性。
+* ⇒ 本函数只回答"日志形态是不是开了没收"，**由调用方保证已排除在跑的会话**。
+* ⚠️ 判据纪律：两个不同的问题（日志形态 ／ 进程状态）**不许塞进同一个函数**，
+*    否则那个函数无法被单独证伪（改任一侧都可能让测试红，而说不清是哪侧错了）。
+*
+* @param events 尾部事件
+* @returns 命中时给出未收尾的轮次与"可能有副作用"的工具名；没有未收尾的轮次 ⇒ null
+*/
+function detectUnclosedTurn(events) {
+	if (events.length === 0) return null;
+	let lastEnd = -1;
+	for (let i = events.length - 1; i >= 0; i--) if (events[i]?.type === "turn/end") {
+		lastEnd = i;
+		break;
+	}
+	let startIdx = -1;
+	for (let i = events.length - 1; i >= 0; i--) if (events[i]?.type === "turn/start") {
+		startIdx = i;
+		break;
+	}
+	if (startIdx < 0 || startIdx < lastEnd) return null;
+	/**
+	* ⚠️ **不要拿 `session/end-seed` 当"已封口"判据**（我第一版这样写，当场被真机用例打红）。
+	*
+	* 真实日志里最常见的恢复形态就是
+	*   `turn/end[interrupted] → session/end-seed → turn/start(新轮)`
+	* —— `end-seed` 是**上一轮**的收尾标记，**不是新一轮的**。
+	* 拿它判"新一轮已封口" ⇒ 会把「新一轮开了就死」误判成"已接续" ⇒ **又回到"啥都扫不到"**。
+	*
+	* ⇒ 判据保持最简：**最后一条 `turn/start` 是否晚于最后一条 `turn/end`**。
+	*   "会不会重复拉起正在跑的会话"由 `liveIds` 负责（扫描层），不是本函数的事。
+	*/
+	const t = events[startIdx]?.data?.turn;
+	const turn = typeof t === "number" ? t : null;
 	return {
 		turn,
 		pendingTools: findPendingTools(events, turn)
@@ -9171,7 +9279,22 @@ function scanInterruptedSessions(projectDir, options = {}) {
 		result.scanned++;
 		try {
 			const events = readTailEvents(logPath, TAIL_EVENT_TARGET);
-			const hit = detectInterruptedEnd(events);
+			/**
+			* 🔴🔴 **两种形态都要接**（2026-10-24 owner 报障：「我要求你抓到非工具调用的中断，
+			* 现在什么都抓不到了」）。
+			*
+			* - 形态 A `detectInterruptedEnd`：日志里有 `turn/end`，且它的 `reason.kind` 是
+			*   `interrupted`（崩溃后被 resume 补收尾）／`aborted`（被正常终止）。
+			* - 形态 B `detectUnclosedTurn`：**日志里压根没有 `turn/end`** —— 进程在轮内任意位置死掉，
+			*   宿主没机会写收尾 ⇒ 日志停在 `tool/call` / `step/start` / `assistant/message`。
+			*   ⚠️ **这一格必须靠"已排除在跑的会话"才成立**，而 `liveIds` 恰好在本函数手里
+			*   （循环开头 `if (liveIds.has(sessionId)) continue`）⇒ 这就是它该待在这里、而不是
+			*   并进 `detectInterruptedEnd` 的原因。
+			*
+			* 实测（本机 10 个窗口内会话）：**4 条**只能由形态 B 抓到（末条 `tool/call` / `step/start`），
+			* 修前全落到 `skipped`。
+			*/
+			const hit = detectInterruptedEnd(events) ?? detectUnclosedTurn(events);
 			if (!hit) {
 				result.skipped++;
 				continue;
@@ -10935,12 +11058,12 @@ function collectRunningSessionIds(nowMs) {
 function renderInterruptedScan(input) {
 	const { projectDir, lookbackHours, scan } = input;
 	const lines = [];
-	lines.push(`═══ 以 interrupted 结尾的 dsh 会话（回看 ${lookbackHours}h）═══`);
+	lines.push(`═══ 末轮未跑完的 dsh 会话（回看 ${lookbackHours}h）═══`);
 	lines.push(`  扫描域: ${projectDir}`);
 	lines.push(`  检查 ${scan.scanned} 个 · 命中 ${scan.sessions.length} · 跳过 ${scan.skipped} · 耗时 ${scan.elapsedMs}ms${scan.errors.length > 0 ? ` · 读取失败 ${scan.errors.length}` : ""}`);
 	if (scan.sessions.length === 0) {
 		lines.push("");
-		lines.push("✓ 没有会话以 interrupted 结尾 —— 无需处理。");
+		lines.push("✓ 没有末轮未跑完的会话 —— 无需处理。");
 		return lines.join("\n");
 	}
 	lines.push("");
@@ -10951,7 +11074,9 @@ function renderInterruptedScan(input) {
 		if (s.pendingTools.length > 0) lines.push(`      ⚠️ 有调用无结果的工具（副作用未知）: ${s.pendingTools.join(", ")}`);
 	}
 	lines.push("");
-	lines.push("判据: 日志末条 = session/end-seed，且其前最近的 turn/end 的 reason.kind = interrupted。");
+	lines.push("判据: 日志末条 `turn/end` 的 `reason.kind` ∈ {interrupted, aborted}，且其后没有新的 turn/start。");
+	lines.push("      interrupted = 进程崩溃后被 resume 补收尾 ／ aborted = 被正常终止（重启、销毁、用户中断）。");
+	lines.push("      两者都表示「这一轮没跑完」，都会被收进来。");
 	lines.push("🔴 本动作**只读** —— 是否续跑、续哪条、几点续，由调用方（你的认知轨迹）决定。");
 	lines.push("⚠️ 未完成的工具调用「副作用未知」≠「没执行」：它们可能已写文件 / 已发消息。");
 	lines.push("   续跑前应先核对副作用，而不是把那一轮整段重放。");
@@ -10977,7 +11102,7 @@ function renderContinueResult(input) {
 	lines.push(`  检查 ${scan.scanned} 个 · 命中 ${scan.sessions.length} · 跳过 ${scan.skipped} · 耗时 ${scan.elapsedMs}ms`);
 	if (scan.sessions.length === 0) {
 		lines.push("");
-		lines.push("✓ 没有会话以 interrupted 结尾 —— 无需续跑。");
+		lines.push("✓ 没有末轮未跑完的会话 —— 无需续跑。");
 		return lines.join("\n");
 	}
 	lines.push("");
@@ -11126,7 +11251,7 @@ function createCognitiveTrajectoryTool(ctx) {
 			"list (inventory + stats) / show (read one SESSION.md) / create (make a NEW trajectory) / use (bind THIS conversation) / rebuild (clear-and-rebuild THIS conversation in place) / archive (move a trajectory out of the active list; one-way, never overwrites).",
 			"(B) DELIVERY — sends ONE message to ANOTHER trajectory; your own binding is unchanged: send-now (right now) / send-later (one future instant).",
 			"(C) REFERENCE — cro-guide: how to give a trajectory its own program that decides when it should be woken.",
-			"(D) INSPECTION — interrupted: list dsh sessions whose LAST turn ended with reason \"interrupted\" (the process died before that turn completed). PURE READ: no periodic scheduling, no auto-continue, no log mutation — deciding IF/WHEN/WHICH to resume belongs to the calling trajectory (this is the \"entry point only\" contract). The criterion is EXACTLY \"ends with interrupted\", NOT \"was ever interrupted\": one long session may have been interrupted dozens of times historically, and treating those as pending would resurrect sessions that already recovered. Each hit reports the turn number and the tool names that had a call but no result (best-effort — those side effects are UNKNOWN, so re-running them blindly is dangerous).",
+			"(D) INSPECTION — interrupted: list dsh sessions whose LAST turn did not finish — reason.kind is \"interrupted\" (process died; the host synthesised the closer on resume) OR \"aborted\" (terminated normally: restart, dispose, user cancel). Both mean \"this turn did not complete\"; picking only one misses an entire class. PURE READ: no periodic scheduling, no auto-continue, no log mutation — deciding IF/WHEN/WHICH to resume belongs to the calling trajectory (this is the \"entry point only\" contract). The criterion is EXACTLY \"the last turn did not finish\", NOT \"was ever interrupted\": one long session may have been interrupted dozens of times historically, and treating those as pending would resurrect sessions that already recovered. Each hit reports the turn number and the tool names that had a call but no result (best-effort — those side effects are UNKNOWN, so re-running them blindly is dangerous).",
 			"HOW TO CHOOSE (a rule, not a guess):",
 			"not yet bound + starting new work ⇒ create (with no prior binding it activates immediately, so the new trajectory has a carrier at once).",
 			"already bound + recording a SEPARATE future line ⇒ create (it does NOT steal your binding; activate the new one later by send-now).",
@@ -11422,16 +11547,16 @@ function createCognitiveTrajectoryTool(ctx) {
 				return listResident(root);
 				case "interrupted": {
 					/**
-					* 以 `interrupted` 结尾的 dsh 会话（owner 2026-10-22 令：**只出入口**）。
+					* 以未完成轮次结尾的 dsh 会话（owner 2026-10-22 令：**只出入口**）。
 					*
 					* 🔴 **边界（owner 原话：「我们 ACC 不关心周期」）**：本动作**只回答**"此刻哪些会话
-					* 的最后一轮以 interrupted 结束"，**不判周期、不自动续跑、不改日志**。
+					* 的最后一轮没跑完"，**不判周期、不自动续跑、不改日志**。
 					* 何时扫、续谁、怎么续 = 调用方（CCC 的认知轨迹）的事。
 					*
 					* 🔴 **为什么不是"曾经中断过"**：长会话历史上可中断几十次（实测单会话 33 次）；
-					* 按"曾经"判会把早已恢复的会话全部当成待续 ⇒ 灾难。判据在
-					* `trajectory/interrupted.ts` 的 `detectInterruptedEnd`：**末条 = end-seed
-					* 且其前最近的 turn/end 是 interrupted**。
+					* 按"曾经"判会把早已恢复的会话全部当成待续 ⇒ 灾难。
+					* 🔴 **判据只在一处**：`trajectory/interrupted.ts` 的 `detectInterruptedEnd`
+					* （⛔ 别在此处复述取值域 —— 2026-10-24 就是这份复述漏掉了 `aborted`）。
 					*
 					* 🔴 **正在跑的会话要排除**：live 会话不该被判成"待续"（它正在跑，不是中断）。
 					*/

package/lib/trajectory/core.d.ts

@@ -63,12 +63,15 @@
  *   判据：它管的是**被找到**，不是**不被销毁** ⇒ 纯读、不碰生命周期、不进系统提示词。
  *   ⚠️ 这也修正了 v1.77.1 的一处说明面失真（手册曾描述一个**不存在**的动作，D179(a)）。
  * 2026-10-22（owner 令「在 trajectory 加上触发入口即可，剩下的 CCC 搞定」）：新增
- *   **`interrupted`** —— 列出**以 `interrupted` 结尾**的 dsh 会话（进程在轮次完成前退出）。
+ *   **`interrupted`** —— 列出**末轮未跑完**的 dsh 会话（进程在轮次完成前退出）。
  *   判据（R↓，为何 ACC 只出**入口**不管周期）：**周期性归属调用方的认知轨迹**，
- *   ACC 只回答"此刻哪些会话以 interrupted 结尾"这一个问题。⇒ 本动作**纯读**、
+ *   ACC 只回答"此刻哪些会话的最后一轮没跑完"这一个问题。⇒ 本动作**纯读**、
  *   **不判周期、不自动续跑、不改任何会话日志**（是否续、续谁、几点续 = CCC 的事）。
- *   ⚠️ 判据的锋利处：**只认"以 interrupted 结尾"**，不认"曾经中断过"—— 长会话历史上
+ *   ⚠️ 判据的锋利处：**只认"末轮未跑完"**，不认"曾经中断过"—— 长会话历史上
  *   可中断几十次（实测单会话 33 次），按"曾经"判会把早已恢复的会话全部当成待续。
+ *   🔴 **2026-10-24（owner 报障「不是崩溃的就扫不到」）**："未跑完"有两种宿主写法 ——
+ *   `interrupted`（崩溃后 resume 补收尾）与 `aborted`（被正常终止：重启／销毁／用户中断）。
+ *   修前只认前者 ⇒ **发布重启这一类整批漏扫**。取值域只在 `trajectory/interrupted.ts` 一处定义。
  * 2026-10-22（owner 追加令「我希望实现的是 continue-all-interrupted 方法，调用后自动找到
  *   8h 内所有 dsh 会话注入简单的 continue 进行唤醒，这样 CCC 就不用动脑子了」）：
  *   新增 **`continue-all-interrupted`** = `interrupted` 的**动作版**（扫 → 逐条注入续跑消息）。

package/lib/trajectory/interrupted.d.ts

@@ -17,10 +17,14 @@
  *
  * ## 判据（三条同时成立，缺一不可）
  *
- * 1. 日志里**最后一条 `turn/end`** 的 `reason.kind === 'interrupted'`；
+ * 1. 日志里**最后一条 `turn/end`** 的 `reason.kind` ∈ {@link UNFINISHED_KINDS}
+ *    （= `interrupted` 崩溃补收尾 ／ `aborted` 正常终止，两者都是"这一轮没收完"）；
  * 2. 该 `turn/end` **之后没有新的 `turn/start`**（否则已被后续轮次接续）；
  * 3. ⛔ **不要求**末条是 `session/end-seed`（2026-10-23 放宽，原因见 {@link detectInterruptedEnd}）。
  *
+ * 🔴 **2026-10-24 补入 `aborted`**：修前只认 `interrupted` ⇒「被正常终止」整类漏扫
+ * （发布重启／换宿主最常见的形态）。判据问的是「这一轮收完了吗」，**不是"进程死得惨不惨"**。
+ *
  * ⚠️ **为什么不能只看"存在过 interrupted"**：一个长会话历史上可能中断几十次
  * （本容器实测单会话 33 次）。只看"曾经中断"会把早已恢复的会话全部当成待续 ⇒ 灾难。
  *
@@ -96,39 +100,47 @@ export interface ScanResult {
     elapsedMs: number;
 }
 /**
- * 判定一组尾部事件是否「以 interrupted 结尾」。
- * 不命中 → null。
- *
- * ## 🔴 2026-10-23 判据放宽（owner 实测：「不是挂在工具调用上的，也要能被 interrupted 筛选到并唤醒」）
- *
- * ### 原判据（v1.87.4 起）为什么漏
- * 原来只认 **末条事件 = `session/end-seed`**。实测（本机 3337 条会话全扫）：
- *   · 末轮 `turn/end[interrupted]` 的会话 **26** 条；
- *   · 其中满足原判据的只有 **24** 条 ⇒ **漏 2 条**，形态逐字为：
- *     `… turn/end[interrupted] -> session/end-seed -> agent/inbox/spliced -> agent/inbox/spliced`
- *   ⇒ 重启后宿主把这**两条**追加在 end-seed 之后（它们是"恢复时把待办消息重新塞进收件箱"），
- *     于是"末条必须 end-seed"这条**在恢复动作发生之后就恒不成立**。
- *   ⚠️ 讽刺的是：**正是那些被恢复过、又再次被打断的会话**最容易长成这样
- *     ⇒ 原判据恰好对"反复中断"的会话失明，而它们才是最需要守护的。
- *
- * ### 新判据（三条，缺一不可）
- * 1. 日志里**最后一条 `turn/end`** 的 `reason.kind === 'interrupted'`；
- * 2. 该 `turn/end` **之后没有新的 `turn/start`**（否则说明它已被后续轮次接续）；
- * 3. ⛔ **不再要求末条是 `end-seed`**。
- *
- * ### 为什么不改成"末条必须是某个白名单"
- * 那就是原缺陷换个白名单再犯一次（`agent/inbox/spliced` 之外还会有别的）。
- * **判据要问的是"最后一轮的结束原因是什么、之后有没有新轮开始"**，
- * 而不是"日志最后一个 token 长什么样"——后者是**载体形态**，前者是**状态**。
- *
- * ### 为什么不会误报"曾经中断但已恢复"
- * 恢复一定伴随 `turn/start`（新一轮）或新的 `turn/end`（`completed` 等）⇒ 判据 1／2 各自挡住。
- * 实测该放宽**不新增误报**：原 24 条全含于新判据（`curOnly = 0`），新增 2 条全是真漏。
+ * 命中判定（**形态 A：靠 `turn/end.reason.kind`**）。
+ *
+ * ⚠️ **本函数刻意不判「开了没收」** —— 那种形态与「此刻正在跑」在日志读数上**不可分**，
+ * 只有扫描层手里有 `liveIds`（正在跑的会话 id）才判得准。
+ * ⇒ 分工：**本函数判"收尾原因"，`scanInterruptedSessions` 判"开了没收"**（见 `detectUnclosedTurn`）。
+ * ⛔ 不要把这些情形塞进本函数 —— 会让它同时依赖"日志形态"与"进程状态"，那种判据无法单独证伪。
+ *
+ * @returns 命中时给出被中断的轮次与"可能有副作用"的工具名；不命中 null
  */
 export declare function detectInterruptedEnd(events: SessionEvent[]): {
     turn: number | null;
     pendingTools: string[];
 } | null;
+/**
+ * 命中判定（**形态 B：一轮开了却没收**）—— 🔴🔴 **2026-10-24 owner 报障的正解**。
+ *
+ * ## 为什么这一格以前整类漏掉
+ *
+ * 进程在**轮内任意位置**死掉时，宿主**永远没机会写 `turn/end`**
+ * ⇒ 日志就停在 `tool/call` ／ `step/start` ／ `assistant/message` 上。
+ * 修前 `detectInterruptedEnd` 首行是 `if (idx < 0) return null`（找不到 turn/end 就放弃）
+ * ⇒ **这一整类被判成"没中断"**。
+ *
+ * ## 判据
+ * **最后一条 `turn/start` 之后没有 `turn/end`** ⇒ 那一轮开了没收。
+ *
+ * ## 为什么必须由**扫描层**调用（而不是并进 `detectInterruptedEnd`）
+ * 「开了没收」与「此刻正在跑」在**日志读数上完全一样**。
+ * 唯一能分开它们的东西是 `liveIds`（宿主报的"此刻在跑的会话"）——
+ * 而那是**扫描层**的参数，不是日志的属性。
+ * ⇒ 本函数只回答"日志形态是不是开了没收"，**由调用方保证已排除在跑的会话**。
+ * ⚠️ 判据纪律：两个不同的问题（日志形态 ／ 进程状态）**不许塞进同一个函数**，
+ *    否则那个函数无法被单独证伪（改任一侧都可能让测试红，而说不清是哪侧错了）。
+ *
+ * @param events 尾部事件
+ * @returns 命中时给出未收尾的轮次与"可能有副作用"的工具名；没有未收尾的轮次 ⇒ null
+ */
+export declare function detectUnclosedTurn(events: SessionEvent[]): {
+    turn: number | null;
+    pendingTools: string[];
+} | null;
 /**
  * 扫描一个 **project 目录**（形如 `<sessions-root>/--home-yh-home-home-serenity--/`）。
  *

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shgroup/dsh-serenity-hooks",
-  "version": "1.91.0",
+  "version": "1.93.0",
   "description": "宁静号 ACC harness（Native Cordis 插件）——给 DeepSeek Harness 装一个「AI 工作区」：14 个工具（container_fs/cognitive_trajectory/dashboard/container_git/msm/praxis/ontology/serenity-skill-creator/cheap-worker/localstore/container_admin；另三个 im-bridge/acc-diag/diagram 按配置条件出现）+ 机械约束（安全模式/工作区围墙/密钥守卫/对外输出守卫）+ 认知轨迹日志与原地重建 + 网页登录入口/IM 桥/认知轨迹唤醒注册表。轨迹声明 = 轨迹目录下的 trajectory.json（约束面 + 旧标识 uid + CRO 机器绑定 cro.host；旧名 trajectory-constraint.json / skiff.json 仍在读取族里）；轨迹提示词 = 轨迹目录下的 PROMPT.md（一条轨迹「是谁、按什么章程工作」，所有轨迹通用，追加在容器层与质量层之后，不替换它们）。适配 DSH 0.1.7-rc.1 / 0.2.0-rc.1 / 0.2.1-rc.1（三档）。",
   "license": "MIT",
   "repository": {