fix(preview): reduce office auto preview overhead

[IceyLiu]

Summary

• replace recursive workspace Office file watching with debounced on-demand scans after tool activity
• add a system setting to enable or disable automatic preview for newly created Office files
• ignore Office temporary marker files and add regression coverage for the new scan-based flow

Test plan

• bun run i18n:types
• node scripts/check-i18n.js
• bunx tsc --noEmit
• bun run test

[sentry]

Codecov Report

❌ Patch coverage is 70.58824% with 35 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...c/renderer/hooks/file/useAutoPreviewOfficeFiles.ts	76.92%	6 Missing and 9 partials ⚠️
src/process/bridge/fileWatchBridge.ts	71.42%	5 Missing and 3 partials ⚠️
...ettingsModal/contents/SystemModalContent/index.tsx	50.00%	5 Missing ⚠️
src/process/bridge/systemSettingsBridge.ts	40.00%	3 Missing ⚠️
...r/hooks/system/useAutoPreviewOfficeFilesEnabled.ts	70.00%	3 Missing ⚠️
...nderer/pages/conversation/Messages/MessageList.tsx	0.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[IceyLiu]

Code Review：fix(preview): reduce office auto preview overhead (#2285)

变更概述

本 PR 将工作空间 Office 文件检测从持久化递归 fs.watch 监听器改为按需防抖扫描：仅在会话 tool 活动或 turn 完成后触发，避免持续监听大型目录树（如含 node_modules 的代码库）的性能开销。同时新增"自动预览新建 Office 文件"系统设置开关，覆盖 IPC bridge、settings 组件、i18n 及单元测试全链路。

---

方案评估

结论：✅ 方案合理

从 watch 模式改为 scan 模式解决了两个已知缺陷：Linux 下 { recursive: true } 不可用，以及对大型 workspace 持续持有 watcher 的性能问题。scan 触发时机（tool_group/tool_call/turnCompleted + 1500ms debounce）足够精确，既不遗漏新生成的文件，也不产生无效扫描。scanRequestIdRef 竞态保护正确，knownOfficeFilesRef 基线管理逻辑清晰。设置开关通过 SWR 缓存与 mutateSWR 桥接，与 commandQueueEnabled 现有模式一致。

---

问题清单

🔵 LOW — fileWatchBridge.ts:43：no-await-in-loop lint 警告

文件：src/process/bridge/fileWatchBridge.ts，第 43 行

问题代码：

while (pendingDirs.length > 0) {
  const currentDir = pendingDirs.pop();
  if (!currentDir) continue;

  let entries: fs.Dirent[];
  try {
    entries = await fs.promises.readdir(currentDir, { withFileTypes: true });
  } catch {
    continue;
  }
  // ...
}

问题说明：oxlint no-await-in-loop 规则在本 PR 新增代码上触发。顺序逐目录读取在 workspace 目录层级较深时存在性能问题；lint 推荐使用 Promise.all 并发读取当前层级下所有已知子目录。

修复建议：

export async function scanWorkspaceOfficeFiles(workspace: string): Promise<string[]> {
  const discovered = new Set<string>();
  let currentLevel = [workspace];

  while (currentLevel.length > 0) {
    const results = await Promise.all(
      currentLevel.map(async (dir) => {
        try {
          return await fs.promises.readdir(dir, { withFileTypes: true });
        } catch {
          return [] as fs.Dirent[];
        }
      })
    );

    const nextLevel: string[] = [];
    for (let i = 0; i < currentLevel.length; i++) {
      const dir = currentLevel[i];
      for (const entry of results[i]) {
        const entryPath = path.join(dir, entry.name);
        if (entry.isDirectory()) {
          if (!shouldSkipWorkspaceOfficeScanDir(entry.name)) nextLevel.push(entryPath);
          continue;
        }
        if (!entry.isFile()) continue;
        if (!WORKSPACE_OFFICE_RE.test(entry.name)) continue;
        if (isIgnoredOfficeTempFileName(entry.name)) continue;
        discovered.add(entryPath);
      }
    }
    currentLevel = nextLevel;
  }

  return [...discovered].toSorted();
}

---

🔵 LOW — fileWatchBridge.ts:65：no-array-sort lint 警告

文件：src/process/bridge/fileWatchBridge.ts，第 65 行

问题代码：

return [...discovered].sort();

问题说明：oxlint unicorn/no-array-sort 规则触发。虽然此处已展开为新数组（.sort() 不会改变 discovered 集合），但 lint 规则要求统一使用 Array#toSorted() 语义。

修复建议：

return [...discovered].toSorted();

---

汇总

#	严重级别	文件	问题
1	🔵 LOW	fileWatchBridge.ts:43	no-await-in-loop：顺序目录读取
2	🔵 LOW	fileWatchBridge.ts:65	no-array-sort：应使用 toSorted()

结论

⚠️ 有条件批准 — 仅存在 2 个 LOW lint 警告（均在本 PR 新增代码上），逻辑正确性、架构一致性及测试覆盖均无问题，修复 lint 后即可合并。

---

本报告由本地 pr-review skill 生成，包含完整项目上下文，无截断限制。