mingdao-harness 0.6.2 → 0.6.4

package/src/atomic-write.js

@@ -4,12 +4,26 @@
 // 存在丢更新与"rename 到对方半截文件"的成体系隐患；config/credentials 等关键文件更是直写。
 // 本模块提供两个原语：
 //   1. atomicWriteFileSync —— tmp 名含 pid+随机后缀（跨进程绝不共名），写完 rename 原子替换；
-//   2. withFileLockSync —— O_EXCL lockfile 互斥（带超时与陈旧锁回收），包裹读-改-写序列。
-// 零依赖：仅 node:fs / node:path / node:crypto / Atomics.wait。
+//   2. withFileLockSync —— O_EXCL lockfile 互斥（带超时与陈旧锁回收），包裹读-改-写序列；
+//   3. withFileLock —— **同一套语义的异步版**：等待期间 `await` 让出事件循环，不阻塞 WebUI。
+//
+// v0.6.2（自评 P2-7 的阻塞面）：同步版用 `Atomics.wait` 睡眠，**等待期间整个事件循环停摆**
+// ——实测持锁方存活 2.6 秒时，一个 100ms 的定时器在锁返回前根本没触发。对常驻服务而言，
+// 这意味着一次文件锁争用就会冻结所有并发会话/权限确认/SSE 流。因此新增异步版并把
+// 「正好在请求路径上」的调用点迁过去（workspace 的 7 处）；同步版保留给纯同步调用链。
+//
+// 另有一处**必须先修**的隐患：原可重入判据是**进程级 Set**。同步临界区不会 yield，
+// 所以一直没出事；但异步临界区**会** yield——此时另一个任务拿同一把锁会被误判成"可重入"
+// 而**并发**进入临界区，读-改-写互相覆盖。现在用 AsyncLocalStorage 把可重入限定在
+// **同一条调用链**内：并发任务各持各的集合，嵌套调用复用同一份。
+// 零依赖：仅 node:fs / node:path / node:crypto / node:async_hooks / Atomics.wait / timers/promises。
 
 import fs from 'node:fs';
+import { pidOwnedBy } from './proc.js';
 import path from 'node:path';
 import crypto from 'node:crypto';
+import { AsyncLocalStorage } from 'node:async_hooks';
+import { setTimeout as sleepAsync } from 'node:timers/promises';
 import { procAlive } from './proc.js';
 
 export function atomicWriteFileSync(/** @type {string} */ target, /** @type {string|Buffer} */ data, /** @type {any} */ options = {}) {
@@ -26,90 +40,252 @@ export function atomicWriteFileSync(/** @type {string} */ target, /** @type {str
   }
 }
 
+// ---------------------------------------------------------------------------
+// 「私有文件」写入（v0.6.3，审计 H-1）
+//
+// 背景：会话/记忆/任务/调度/工作空间/索引这些文件此前直接 appendFileSync / 原子写**不带 mode**，
+// 默认 umask 下是 0644——而会话原文会原样记录用户粘贴的 sk-*、PEM、JWT，同机其它用户可读。
+// 同仓的账本/审计/凭据早已 0600，属于「同模块两套口径」。
+//
+// 两条纪律：
+//   ① 创建时带 mode: 0o600；
+//   ② **每次写都补一次 chmod 自愈**——mode 只在创建时生效，对旧版本留下的 0644 文件不起作用
+//      （凭据/审计早已这么做，这里收敛成共享助手，避免八处各写一遍再漂移）。
+// ---------------------------------------------------------------------------
+
+/**
+ * 追加写入并保证 0600（对已存在文件收权自愈）。
+ * @param {string} file @param {string|Buffer} data
+ */
+export function appendFilePrivateSync(file, data) {
+  fs.appendFileSync(file, data, { mode: 0o600 });
+  try {
+    fs.chmodSync(file, 0o600);
+  } catch {}
+}
+
+/**
+ * 原子写入并保证 0600（对已存在文件收权自愈）。
+ * @param {string} file @param {string|Buffer} data
+ */
+export function atomicWritePrivateSync(file, data) {
+  atomicWriteFileSync(file, data, { mode: 0o600 });
+  try {
+    fs.chmodSync(file, 0o600);
+  } catch {}
+}
+
 export function atomicWriteJsonSync(/** @type {string} */ target, /** @type {any} */ value, { mode = 0o600 } = {}) {
   atomicWriteFileSync(target, JSON.stringify(value, null, 2) + '\n', { mode });
 }
 
-// 极简互斥锁：O_EXCL 创建 lockfile；持锁期间执行 fn（同步）；异常/完成释放。
-// 进程崩溃遗留的陈旧锁（> staleMs 未更新）自动回收，避免永久卡死。
-// 可重入（P0-1 修复，v0.4.5）：本进程已持该锁时直接执行 fn——O_EXCL 锁不可重入，此前
-// killTask 持锁内调 patchTask 二次抢同一把锁自死锁 5s（tasks kill/pause/remove 全失效）。
+// 极简互斥锁：O_EXCL 创建 lockfile；持锁期间执行 fn（同步/异步）；异常/完成释放。
+// 进程崩溃遗留的陈旧锁自动回收，避免永久卡死。
 const sleepBuf = new Int32Array(new SharedArrayBuffer(4));
 const sleepMs = (/** @type {number} */ ms) => Atomics.wait(sleepBuf, 0, 0, ms);
-const heldLocks = new Set(); // 本进程当前持有的锁路径（可重入判定）
-
-// v0.6.2（自评报告 P2-7）：默认值必须 **timeoutMs > staleMs**。
-// 原为 5000 / 15000——等待方 5 秒就抛「获取文件锁超时」，而陈旧锁要 15 秒才允许回收，
-// 中间 10 秒是纯粹的**死区**：持锁方一旦崩溃，这段时间内所有写方必然全部失败
-// （cachestats 静默跳过轮转丢计费明细；tasks/workspace/schedule/sync 未捕获时直接报错）。
-export function withFileLockSync(/** @type {string} */ lockPath, /** @type {() => any} */ fn, { timeoutMs = 20000, staleMs = 15000 } = {}) {
-  // 可重入：同一调用栈内已持该锁 → 直接执行，不再二次抢锁
-  if (heldLocks.has(lockPath)) {
-    return fn();
+
+// 可重入集合按**调用链**隔离（见文件头注释：异步临界区会 yield，进程级 Set 会让并发任务互相穿透）
+const lockScope = new AsyncLocalStorage();
+/** @param {(held: Set<string>) => any} fn */
+function runWithHeld(fn) {
+  const held = lockScope.getStore();
+  if (held) return fn(held); // 已在同一条调用链里：复用同一份，嵌套即"可重入"
+  const fresh = new Set();
+  return lockScope.run(fresh, () => fn(fresh));
+}
+
+/**
+ * 尝试独占创建锁文件。EEXIST 表示别人持有（返回 false，由调用方决定等待或重试）；
+ * 其它错误（权限/路径非法）**直接抛出**——那不是"有人在用"，装成争用只会掩盖真问题。
+ * @param {string} lockPath
+ */
+function tryAcquire(lockPath) {
+  let fd;
+  try {
+    fd = fs.openSync(lockPath, 'wx');
+  } catch (err) {
+    if (/** @type {any} */ (err)?.code === 'EEXIST') return false;
+    throw err;
+  }
+  try {
+    // v0.6.3（M-11）：锁内容额外记下本进程的**入口脚本**，作为 pid 的身份凭据。
+    // 起因：陈旧回收只看「持有者 pid 是否存活」，而 pid 会被复用——复用给一个活进程后
+    // `procAlive` 恒真，这把锁**永不回收**，所有写方等到超时失败（死锁）。
+    // 有了 cmd（argv[1]），回收方可以用既有的 pidOwnedBy() 校验"活着的这个 pid 还是不是原来那个进程"。
+    // v0.6.3（M-11）：锁内容额外记下入口脚本的**文件名**作为 pid 的身份凭据。
+    // 起因：陈旧回收只看「持有者 pid 是否存活」，而 pid 会被复用——复用给一个活进程后
+    // `procAlive` 恒真，这把锁**永不回收**，所有写方等到超时失败（死锁）。
+    //
+    // 为什么是 basename 而不是 argv[1]：`ps` 显示的是**输入时的形态**，而 Node 把 argv[1]
+    // 解析成绝对路径——`node test/smoke.js` 在 ps 里就是 `node test/smoke.js`。
+    // 第一版存 argv[1]，于是"同进程内的并发任务"也被判成 pid 复用 → **把活锁抢走**，
+    // 既有的并发串行断言当场抓到（3 次自增只剩 1）。basename 在两种形态下都出现，是稳妥的交集。
+    fs.writeSync(fd, JSON.stringify({ pid: process.pid, at: Date.now(), cmd: path.basename(process.argv[1] || process.execPath) }));
+  } finally {
+    fs.closeSync(fd);
+  }
+  return true;
+}
+
+/** @param {string} lockPath */
+function releaseLock(lockPath) {
+  try {
+    fs.unlinkSync(lockPath);
+  } catch {}
+}
+
+/**
+ * 判断能否回收一把陈旧锁（返回 true = 调用方应立刻重试）。
+ *
+ * v0.6.2（P2-7）：陈旧判据是「**持有者 pid 已死**」优先，而不是只看 mtime：
+ *   · 只看 mtime 会带来两个反向问题：① 崩溃后要白等满 staleMs 才允许回收（配小 timeout 就是死区）；
+ *     ② 某个 fn 本身耗时超过 staleMs（大文件重写、慢盘）时，别人会把**仍然活着**的锁判成陈旧并回收
+ *     ——互斥直接失效，且没有任何补救。
+ *   · 锁内容本来就写着 {pid, at}，现成的判据要用上：持有者还活着（哪怕 fn 跑了很久）**绝不回收**。
+ * 读不到持有者信息（老格式/内容损坏）时才退回「mtime 超过 staleMs」。
+ * @param {string} lockPath @param {number} staleMs
+ */
+function reclaimIfStale(lockPath, staleMs) {
+  let st;
+  try {
+    st = fs.statSync(lockPath);
+  } catch {
+    return true; // 锁文件刚被释放：立刻重试
   }
-  fs.mkdirSync(path.dirname(lockPath), { recursive: true });
-  const t0 = Date.now();
-  for (;;) {
-    // v0.4.7：区分「抢锁阶段」与「执行 fn 阶段」。此前 fn 自身抛出的 EEXIST 也会落进下方的
-    // 锁重试分支，而 finally 已释放锁 → 重抢成功后再次执行 fn → 再次抛出 → **同步死循环**
-    // （100% CPU，连超时分支都不可达）。acquiring 在 fn 开始执行前置 false。
-    let acquiring = true;
+  let holderPid = 0;
+  let holderCmd = '';
+  try {
+    const meta = JSON.parse(fs.readFileSync(lockPath, 'utf8'));
+    holderPid = Number(meta?.pid) || 0;
+    holderCmd = String(meta?.cmd || '');
+  } catch {}
+  let holderAlive = holderPid > 0 ? procAlive(holderPid) : null;
+  // M-11：pid 存活 ≠ 原持有者还活着。用命令行归属校验识破 pid 复用：
+  //   · pidOwnedBy 返回 false → 这个 pid 现在跑的是**别的**程序 → 原持有者已死，可以回收；
+  //   · 返回 true（同一入口脚本，可能是也可能不是原进程）或 null（Windows/取不到命令行）→ 保持"活着"。
+  // 这一层是**严格改进**：原先这种情况一律不回收，现在只有"能确证不是原进程"时才回收。
+  if (holderAlive === true && holderCmd) {
     try {
-      const fd = fs.openSync(lockPath, 'wx'); // 独占创建
-      try {
-        fs.writeSync(fd, JSON.stringify({ pid: process.pid, at: Date.now() }));
-      } finally {
-        fs.closeSync(fd);
-      }
-      heldLocks.add(lockPath);
-      acquiring = false; // 锁已持有：此后 fn 的任何异常都不得进入锁重试分支
+      if (pidOwnedBy(holderPid, holderCmd) === false) holderAlive = false;
+    } catch {}
+  }
+  const reclaimable = holderAlive === false || (holderAlive === null && Date.now() - st.mtimeMs > staleMs);
+  if (!reclaimable) return false;
+  // TOCTOU 防护（OfficeACE 报告）：unlink 前读锁内容并二次 stat 比对，
+  // 防两个进程同时判定陈旧、后者误删前者刚创建的新锁（互斥失效）
+  try {
+    const before = fs.readFileSync(lockPath, 'utf8');
+    const st2 = fs.statSync(lockPath);
+    if (st2.mtimeMs === st.mtimeMs && before === fs.readFileSync(lockPath, 'utf8')) {
+      fs.unlinkSync(lockPath);
+    }
+  } catch {}
+  return true; // 无论是否回收成功都重试一次（若锁刚被他人更新则继续等待）
+}
+
+// 锁的两个时间参数（v0.6.2 依实测重新定过）：
+//
+// ① **必须 timeoutMs > staleMs**。曾是 5000/15000——等待方 5 秒就抛超时，而陈旧锁要 15 秒才
+//    允许回收，中间 10 秒是纯**死区**：持锁方一旦崩溃，这段内所有写方必然全部失败。
+// ② 现在取 **5000 / 4000**：死区没了，且**等锁的最坏冻结从 20 秒降到 5 秒**。
+//    依据是实测（本机）：纯状态的临界区极短——小文件读-改-写 **0.13ms**，
+//    连最重的 cache-stats 轮转（1.43MB / 2 万行解析 + 重写 1 万行）也只有 **6ms**。
+//    5 秒是实测最坏值的约 800 倍，正常争用绝不会误判超时；**只有**「持有者活着但卡死」
+//    或「锁内容读不出 pid 且超过 staleMs」才会等这么久。
+// ③ 两个值都可用环境变量覆盖，便于诊断与测试（例如调小 staleMs 以便立刻回收陈旧锁）。
+const ENV_TIMEOUT = Number(process.env.MINGDAO_LOCK_TIMEOUT_MS);
+const ENV_STALE = Number(process.env.MINGDAO_LOCK_STALE_MS);
+const DEFAULT_TIMEOUT_MS = Number.isFinite(ENV_TIMEOUT) && ENV_TIMEOUT > 0 ? ENV_TIMEOUT : 5000;
+const DEFAULT_STALE_MS = Number.isFinite(ENV_STALE) && ENV_STALE > 0 ? ENV_STALE : 4000;
+
+/**
+ * 锁超时的统一文案：**说清锁文件在哪、怎么看持有者、什么时候可以删**。
+ * 只报一句"获取文件锁超时"的话，用户除了重试什么也做不了。
+ * @param {string} lockPath @param {number} timeoutMs
+ */
+function lockTimeoutError(lockPath, timeoutMs) {
+  return new Error(
+    `获取文件锁超时（${(timeoutMs / 1000).toFixed(1)} 秒，${lockPath}）：可能有其他进程长时间占用或已卡死。\n` +
+      `  排查：查看该 .lock 文件内容（形如 {"pid":123,"at":…}），确认那个 pid 是否还活着；` +
+      `若不是活着的 mingdao 进程，删除该文件后重试即可（陈旧锁也会在 ${DEFAULT_STALE_MS / 1000} 秒后自动回收）。`
+  );
+}
+
+export function withFileLockSync(/** @type {string} */ lockPath, /** @type {() => any} */ fn, { timeoutMs = DEFAULT_TIMEOUT_MS, staleMs = DEFAULT_STALE_MS } = {}) {
+  return runWithHeld((held) => {
+    // 可重入：同一条调用链内已持该锁 → 直接执行，不再二次抢锁
+    if (held.has(lockPath)) return fn();
+    fs.mkdirSync(path.dirname(lockPath), { recursive: true });
+    const t0 = Date.now();
+    for (;;) {
+      // v0.4.7：区分「抢锁阶段」与「执行 fn 阶段」。此前 fn 自身抛出的 EEXIST 也会落进下方的
+      // 锁重试分支，而 finally 已释放锁 → 重抢成功后再次执行 fn → 再次抛出 → **同步死循环**
+      // （100% CPU，连超时分支都不可达）。acquiring 在 fn 开始执行前置 false。
+      let acquiring = true;
       try {
-        return fn();
-      } finally {
-        heldLocks.delete(lockPath);
+        if (!tryAcquire(lockPath)) {
+          const e = /** @type {any} */ (new Error('EEXIST'));
+          e.code = 'EEXIST';
+          throw e;
+        }
+        held.add(lockPath);
+        acquiring = false; // 锁已持有：此后 fn 的任何异常都不得进入锁重试分支
         try {
-          fs.unlinkSync(lockPath);
-        } catch {}
+          return fn();
+        } finally {
+          held.delete(lockPath);
+          releaseLock(lockPath);
+        }
+      } catch (err) {
+        if (!acquiring) throw err; // fn 自身的异常绝不进入锁重试
+        if (/** @type {any} */ (err).code !== 'EEXIST') throw err;
+        if (reclaimIfStale(lockPath, staleMs)) continue;
+        if (Date.now() - t0 > timeoutMs) {
+          throw lockTimeoutError(lockPath, timeoutMs);
+        }
+        sleepMs(25);
       }
-    } catch (err) {
-      if (!acquiring) throw err; // fn 自身的异常绝不进入锁重试
-      if (/** @type {any} */ (err).code !== 'EEXIST') throw err;
-      try {
-        const st = fs.statSync(lockPath);
-        // v0.6.2（P2-7）：陈旧判据改为「**持有者 pid 已死**」优先。
-        //
-        // 原判据只看 mtime 超过 staleMs，带来两个反向问题：
-        //   ① 崩溃后要白等满 15 秒才允许回收（配上面 5 秒的 timeout 就是死区）；
-        //   ② 若某个 fn 本身耗时超过 15 秒（大文件重写、慢盘），别人会把**仍然活着**的锁
-        //      判成陈旧并回收——互斥直接失效，而且没有任何补救。
-        // 锁内容本来就写着 {pid, at}（此前只用于 TOCTOU 比对），现成的判据没用上。
-        let holderPid = 0;
+    }
+  });
+}
+
+/**
+ * 异步版互斥：语义与 withFileLockSync **完全一致**（同一套 tryAcquire / reclaimIfStale /
+ * 可重入规则、同样的超时与错误文案），唯一区别是等待时 `await sleepAsync()` —— 让出事件循环，
+ * 因此**不会冻结 WebUI**。事件循环敏感的调用点（请求路径）应当用它。
+ *
+ * 为什么值得单独一个函数而不是把同步版改成异步：调用链里不少地方本身就是同步的
+ * （CLI 一次性命令、调度守护进程内部的读-改-写），强行异步化会把 async 传染到 24 个调用点，
+ * 回归风险大于收益。做法是**逐个判断**：请求路径上的迁移，纯同步链保留同步版。
+ * @param {string} lockPath @param {() => any} fn
+ */
+export async function withFileLock(/** @type {string} */ lockPath, /** @type {() => any} */ fn, { timeoutMs = DEFAULT_TIMEOUT_MS, staleMs = DEFAULT_STALE_MS, pollMs = 25 } = {}) {
+  return runWithHeld(async (held) => {
+    if (held.has(lockPath)) return fn();
+    fs.mkdirSync(path.dirname(lockPath), { recursive: true });
+    const t0 = Date.now();
+    for (;;) {
+      if (tryAcquire(lockPath)) {
+        held.add(lockPath);
         try {
-          holderPid = Number(JSON.parse(fs.readFileSync(lockPath, 'utf8'))?.pid) || 0;
-        } catch {}
-        const holderAlive = holderPid > 0 ? procAlive(holderPid) : null;
-        // 回收条件：持有者已死（立刻回收，不留死区）；或读不到持有者信息且确实超过 staleMs。
-        // 持有者仍活着（哪怕 fn 跑了很久）**绝不回收**——那会破坏互斥。
-        const reclaimable = holderAlive === false || (holderAlive === null && Date.now() - st.mtimeMs > staleMs);
-        if (reclaimable) {
-          // TOCTOU 防护（OfficeACE 报告）：unlink 前读锁内容并二次 stat 比对，
-          // 防两个进程同时判定陈旧、后者误删前者刚创建的新锁（互斥失效）
-          try {
-            const before = fs.readFileSync(lockPath, 'utf8');
-            const st2 = fs.statSync(lockPath);
-            if (st2.mtimeMs === st.mtimeMs && before === fs.readFileSync(lockPath, 'utf8')) {
-              fs.unlinkSync(lockPath);
-            }
-          } catch {}
-          continue; // 无论是否回收成功都重试一次（若锁刚被他人更新则继续等待）
+          return await fn();
+        } finally {
+          // 注意：这里必须放在 try/finally 里而不是靠外层 catch——
+          // fn 的异常要原样抛出，绝不能被误当成"抢锁失败"而重跑临界区
+          held.delete(lockPath);
+          releaseLock(lockPath);
         }
-      } catch {
-        continue; // 锁文件刚被释放
       }
+      if (reclaimIfStale(lockPath, staleMs)) continue;
       if (Date.now() - t0 > timeoutMs) {
-        throw new Error(`获取文件锁超时（${lockPath}），可能存在其他进程长时间占用`);
+        throw lockTimeoutError(lockPath, timeoutMs);
       }
-      sleepMs(25);
+      await sleepAsync(pollMs);
     }
-  }
+  });
+}
+
+/** 同步/异步锁的默认超时与陈旧阈值（导出供诊断与测试断言「上限有界」）。 */
+export function lockDefaults() {
+  return { timeoutMs: DEFAULT_TIMEOUT_MS, staleMs: DEFAULT_STALE_MS };
 }

package/src/audit.js

@@ -8,7 +8,7 @@ import fs from 'node:fs';
 import path from 'node:path';
 import { mingdaoHome, ensureHome } from './config.js';
 import { redactSecrets } from './redact.js';
-import { atomicWriteFileSync } from './atomic-write.js';
+import { atomicWriteFileSync, withFileLockSync } from './atomic-write.js';
 
 // v0.6.2（第三方代码审计 P2-2）：截断触发改为看**文件大小**。
 // 原判据 `auditCount > 20000` 是**进程内**计数：CLI 每次会话只 append 几次、进程结束即归零，
@@ -40,10 +40,28 @@ export function writeAudit(/** @type {any} */ entry) {
   try {
     ensureHome();
     const file = auditFile();
-    fs.appendFileSync(file, JSON.stringify(entry) + '\n');
-    try {
-      fs.chmodSync(file, 0o600);
-    } catch {}
+    // v0.6.3（M-20）：**追加与轮转必须在同一把锁里**。原实现是「锁外追加 + 锁外读改写轮转」，
+    // 丢失窗口很实在：A 追加 → B 追加 → A 读到含 A 的快照 → A 原子写回 → B 那一行消失。
+    // 审计是合规证据，"少一行"等于证据链有洞，而且不报错。锁的范围含 append：代价是每次
+    // 工具调用多一次毫秒级文件锁（审计本就每工具调用一条，不在热路径上）。
+    let appended = false;
+    withFileLockSync(file + '.lock', () => {
+      fs.appendFileSync(file, JSON.stringify(entry) + '\n');
+      appended = true;
+      try {
+        fs.chmodSync(file, 0o600);
+      } catch {}
+      // 低频截断：statSync 廉价，只有真的超过阈值才整文件读一次并重写
+      if (fs.statSync(file).size > MAX_BYTES) {
+        const lines = fs.readFileSync(file, 'utf8').split('\n').filter(Boolean);
+        if (lines.length > KEEP_LINES) {
+          // v0.6.2（P2-3）：**原子写**——原先直接 writeFileSync，截断过程中崩溃会留下半截
+          // audit.jsonl（审计证据丢事件）。atomicWriteFileSync 的 tmp 名含 pid+随机后缀，
+          // 写完 rename 原子替换，读者永远看到完整文件；mode 保持 0600。
+          atomicWriteFileSync(file, lines.slice(-KEEP_LINES).join('\n') + '\n', { mode: 0o600 });
+        }
+      }
+    });
 
   } catch (err) {
     // v0.6.2（B-WS-1/2 第八处）：仍然「不影响会话」（审计不能反过来打断用户干活），
@@ -60,19 +78,6 @@ export function writeAudit(/** @type {any} */ entry) {
     }
     return;
   }
-  // 低频截断：statSync 廉价，只有真的超过阈值才整文件读一次并重写
-  try {
-    const f = auditFile(); // 上面 try 里的 file 是块内作用域，这里单独取一次
-    if (fs.statSync(f).size > MAX_BYTES) {
-      const lines = fs.readFileSync(f, 'utf8').split('\n').filter(Boolean);
-      if (lines.length > KEEP_LINES) {
-        // v0.6.2（P2-3）：**原子写**——原先直接 writeFileSync，截断过程中崩溃会留下半截
-        // audit.jsonl（审计证据丢事件）。atomicWriteFileSync 的 tmp 名含 pid+随机后缀，
-        // 写完 rename 原子替换，读者永远看到完整文件；mode 保持 0600。
-        atomicWriteFileSync(f, lines.slice(-KEEP_LINES).join('\n') + '\n', { mode: 0o600 });
-      }
-    }
-  } catch {}
 }
 
 export function listAudit(limit = 20) {

package/src/cachestats.js

@@ -5,7 +5,7 @@ import fs from 'node:fs';
 import path from 'node:path';
 import { mingdaoHome, ensureHome } from './config.js';
 import { estimateCost, cacheSplit, beijingDayStart, beijingParts } from './pricing.js';
-import { withFileLockSync, atomicWriteFileSync } from './atomic-write.js';
+import { withFileLockSync, atomicWriteFileSync, appendFilePrivateSync } from './atomic-write.js';
 
 export function cacheStatsFile() {
   return path.join(mingdaoHome(), 'cache-stats.jsonl');
@@ -69,63 +69,73 @@ export function recordCacheStats(/** @type {any} */ entry) {
       aux: entry.aux === true ? true : undefined,
       auxReason: entry.auxReason ? String(entry.auxReason) : undefined,
     });
-    fs.appendFileSync(cacheStatsFile(), line + '\n');
-  } catch (err) {
-    const msg = String(/** @type {any} */ (err)?.message ?? err);
-    lastWriteError = msg;
-    // 只提示一次：写不进去通常是持续性问题（磁盘满/权限），每回合刷屏反而让人忽略它
-    if (!writeWarned) {
-      writeWarned = true;
-      console.warn(
-        `[MingDao] ⚠ 费用明细写入失败：${msg}\n` +
-          `  今日费用护栏会**少计**这部分消费（可能超支而不知）；请检查 ${cacheStatsFile()} 的磁盘空间与权限。`
-      );
-    }
-    // 追加都失败了，后面的轮转毫无意义（statSync 也大概率抛错），直接返回真实原因，
-    // 不要让轮转分支的异常把 append 的原因覆盖掉
-    return { ok: false, error: msg, phase: 'append' };
-  }
-  try {
-    if (fs.statSync(cacheStatsFile()).size > MAX_BYTES) {
-      // 审计 P2-3（v0.4.2）：轮转 read-modify-write 加跨进程锁——web/CLI/worker 多进程并发轮转时，
-      // 读与写之间他人追加的行会被覆写丢失；锁内重读再瘦身，写用原子替换。
+    // v0.6.3（BUG-009）：**追加与轮转共用同一把锁**。
+    // 原实现是「锁外追加 + 锁内轮转」，仍留有丢失窗口：A 追加 → B 追加 → A 进锁读整文件、
+    // 算出瘦身结果、原子替换 —— B 那一行若落在 A 的「读」与「写」之间，就被整文件替换覆盖掉。
+    // 丢的是费用明细，而费用明细正是日费用护栏的依据（少计 → 超支而不自知）。
+    let appended = false;
+    try {
       withFileLockSync(cacheStatsFile() + '.lock', () => {
-        const raw = fs.readFileSync(cacheStatsFile(), 'utf8');
-        const lines = raw.split('\n').filter(Boolean);
-        if (lines.length > MAX_LINES) {
-          // v0.4.6 P2 修复：轮转必须保留**当天全部**记录。此前只保留最后 KEEP_LINES 行——
+        appendFilePrivateSync(cacheStatsFile(), line + '\n');
+        appended = true;
+        if (fs.statSync(cacheStatsFile()).size > MAX_BYTES) {
+          // 审计 P2-3（v0.4.2）：轮转的 read-modify-write 同样有并发窗口，现在它与追加在同一锁内。
+          // v0.4.6 P2：轮转必须保留**当天全部**记录。此前只保留最后 KEEP_LINES 行——
           // 单进程写满 2 万条后，当天早先的费用会被裁掉，todayCost() 随之变小，
           // 日费用护栏被静默重置（用户可再次超支而不自知）。当天行（最多 MAX_LINES 条）
           // 与最近 KEEP_LINES 行取并集，去重且保持原顺序。
-          const dayStart = beijingDayStart().getTime();
-          const todayLines = lines.filter((/** @type {string} */ l) => {
-            try {
-              return (JSON.parse(l).at || 0) >= dayStart;
-            } catch {
-              return false;
-            }
-          });
-          const tail = lines.slice(-KEEP_LINES);
-          const tailSet = new Set(tail);
-          const todayCapped = todayLines.length > MAX_LINES ? todayLines.slice(-MAX_LINES) : todayLines;
-          const todaySet = new Set(todayCapped);
-          const merged = [...todayCapped, ...tail.filter((l) => !todaySet.has(l))];
-          // 顺序按原文件恢复（避免打乱 byDay 折线的时间序）
-          const order = new Map(lines.map((l, i) => [l, i]));
-          merged.sort((a, b) => (order.get(a) ?? 0) - (order.get(b) ?? 0));
-          atomicWriteFileSync(cacheStatsFile(), merged.join('\n') + '\n');
+          const raw = fs.readFileSync(cacheStatsFile(), 'utf8');
+          const rows = raw.split('\n').filter(Boolean);
+          if (rows.length > MAX_LINES) {
+            const dayStart = beijingDayStart().getTime();
+            const todayLines = rows.filter((/** @type {string} */ l) => {
+              try {
+                return (JSON.parse(l).at || 0) >= dayStart;
+              } catch {
+                return false;
+              }
+            });
+            const tail = rows.slice(-KEEP_LINES);
+            const tailSet = new Set(tail);
+            const todayCapped = todayLines.length > MAX_LINES ? todayLines.slice(-MAX_LINES) : todayLines;
+            const todaySet = new Set(todayCapped);
+            const merged = [...todayCapped, ...tail.filter((l) => !todaySet.has(l))];
+            // 顺序按原文件恢复（避免打乱 byDay 折线的时间序）
+            const order = new Map(rows.map((l, k) => [l, k]));
+            merged.sort((a, b) => (order.get(a) ?? 0) - (order.get(b) ?? 0));
+            atomicWriteFileSync(cacheStatsFile(), merged.join('\n') + '\n');
+          }
         }
       });
+    } catch (err) {
+      const msg = String(/** @type {any} */ (err)?.message ?? err);
+      lastWriteError = msg;
+      if (!appended) {
+        // 只提示一次：写不进去通常是持续性问题（磁盘满/权限），每回合刷屏反而让人忽略它
+        if (!writeWarned) {
+          writeWarned = true;
+          console.warn(
+            `[MingDao] ⚠ 费用明细写入失败：${msg}\n` +
+              `  今日费用护栏会**少计**这部分消费（可能超支而不知）；请检查 ${cacheStatsFile()} 的磁盘空间与权限。`
+          );
+        }
+        return { ok: false, error: msg, phase: 'append' };
+      }
+      // 追加已成功、只有轮转失败：丢的不是账，而是文件会持续增长
+      if (!rotateWarned) {
+        rotateWarned = true;
+        console.warn(`[MingDao] ⚠ 费用明细轮转失败：${msg}\n  ${cacheStatsFile()} 会持续增长（不影响计费，但请检查磁盘空间/权限）。`);
+      }
+      return { ok: false, error: msg, phase: 'rotate' };
     }
   } catch (err) {
-    // 轮转失败与追加失败是两件事：这里丢的不是账，而是文件会持续增长
     const msg = String(/** @type {any} */ (err)?.message ?? err);
     lastWriteError = msg;
-    if (!rotateWarned) {
-      rotateWarned = true;
-      console.warn(`[MingDao] ⚠ 费用明细轮转失败：${msg}\n  ${cacheStatsFile()} 会持续增长（不影响计费，但请检查磁盘空间/权限）。`);
+    if (!writeWarned) {
+      writeWarned = true;
+      console.warn(`[MingDao] ⚠ 费用明细写入失败：${msg}\n  今日费用护栏会**少计**这部分消费（可能超支而不知）；请检查 ${cacheStatsFile()} 的磁盘空间与权限。`);
     }
-    return { ok: false, error: msg, phase: 'rotate' };
+    return { ok: false, error: msg, phase: 'append' };
   }
   return { ok: true, error: null, phase: null };
 }

package/src/cli.js

@@ -7,7 +7,7 @@ import fs from 'node:fs';
 import { DEFAULT_MODEL } from './models.js';
 import path from 'node:path';
 import readline from 'node:readline';
-import { loadConfig, saveConfig, runWizard, ensureHome, mingdaoHome } from './config.js';
+import { loadConfig, saveConfig, runWizard, ensureHome, mingdaoHome, readConfigStrict, quarantineCorruptConfig } from './config.js';
 import { helpLines } from './help.js';
 import { modelPreset, PROVIDERS } from './models.js';
 import { maskKey, getStoredKey } from './credentials.js';
@@ -231,7 +231,7 @@ async function main() {
   if (opts.prompt[0] === 'schedule-daemon') {
     const home0 = ensureHome();
     const { listSchedules, runSleeper, sleeperAlive, procAlive, daemonPidFile, writeSchedule } = await import('./schedule.js');
-    const { readTask } = await import('./tasks.js');
+    const { readTask, taskWorkerAlive } = await import('./tasks.js');
     const handled = new Set();
     const supervising = new Set(); // 本 daemon 正在监督的任务（防崩溃恢复误判正在执行的任务）
     const nonce = String(opts.prompt[1] || '');
@@ -261,7 +261,16 @@ async function main() {
             // v0.4.7（P2 T15）：先看「跑这个任务的宿主进程」是否仍存活。存活说明它正在跑
             // （可能还没写 lastTaskId），**等它**——否则「本 daemon 刚接管 + 旧 daemon 在途」
             // 会被当成崩溃残留 → 重置 pending → 并发重跑同一任务。
-            if (procAlive(j.runnerPid)) continue;
+            //
+            // v0.6.3（P1-5）：但「宿主就是自己」时必须例外——markRunning 写的 runnerPid 就是
+            // 本 daemon 的 pid，于是 `procAlive(自己)` 恒真 → `continue` → 这条 job **永久跳过**：
+            // 面板一直转圈、既不重跑也不收尾，用户只能 daemon stop + 删 pidfile 自愈。
+            // 同理：宿主只是"标记"，真正在跑的是 detached worker，绝不能凭宿主死活就重排。
+            const runnerIsSelf = Number(j.runnerPid) === process.pid;
+            if (!runnerIsSelf && procAlive(j.runnerPid)) continue;
+            // worker 仍活着（宿主被 SIGKILL 但 detached worker 还在跑）→ **绝不重排**，
+            // 否则同一个任务会跑第二遍；等它收尾，下一轮恢复会走「t.status !== running」的定案分支。
+            if (t && t.status === 'running' && taskWorkerAlive(t)) continue;
             if (!t) {
               await writeSchedule(home0, { ...j, status: 'pending' });
               continue;
@@ -292,7 +301,14 @@ async function main() {
           handled.add(j.id);
           supervising.add(j.id);
           runSleeper(home0, j.id, { shouldStop: () => leaseLost })
-            .catch(() => {})
+            // v0.6.3（P1-5）：不能静默吞。协程一次异常（锁超时/写盘失败）此前**无痕**消失，
+            // 于是 job 停在 running、下一轮恢复又因 runnerPid 指向自己而跳过 → 永久卡住。
+            // 现在至少留一条可诊断的日志（用户能在 daemon 日志里看到"为什么没跑"）。
+            .catch((/** @type {any} */ e) => {
+              try {
+                console.error(`[MingDao] ⚠ 调度协程异常（任务 ${j.id}）：${e?.message || e}`);
+              } catch {}
+            })
             .finally(() => {
               handled.delete(j.id);
               supervising.delete(j.id);
@@ -341,6 +357,11 @@ async function main() {
     return;
   }
   const home = ensureHome();
+  // v0.6.3（H-7）：进向导**之前**先分清「没有配置」与「配置读不出来」。
+  // 后者若被当成首次运行，向导会用全新对象整文件覆盖掉用户配置（customModels/mcpServers/
+  // sync/net/costGuard 全丢）且不备份。这里先把损坏文件改名备份并告警，再继续走首次向导。
+  const cfgStrict = readConfigStrict();
+  if (cfgStrict.exists && !cfgStrict.ok) quarantineCorruptConfig(cfgStrict.error || '未知原因');
   let cfg = loadConfig();
   if (!cfg || opts.init) {
     const wio = createIO();

package/src/commands/diagnose.js

@@ -112,6 +112,9 @@ export async function handleDiagnose(/** @type {any} */ _cmd, /** @type {any} */
     io.print(style('请把该文件内容贴到反馈渠道排查；密钥/token/私网路径已脱敏。', C.dim));
   } catch (/** @type {any} */ err) {
     io.print(style('[错误] ' + (err?.message || err), C.red));
+    // v0.6.3（M-21）：诊断包生成失败必须体现在退出码上——脚本化收集诊断信息时
+    // 「打印了错误但退 0」会让调用方以为拿到了报告。
+    process.exitCode = 1;
   } finally {
     io.close();
   }