[建议 / Feature] 任务自动归档仅扫描"最近打开过的工作区"：纯 CLI 工作区永不归档，开启 7 天策略后历史仍持续堆积（3.12.2 实测）

问题类别 · Category

UI / 界面体验 · UI / UX

涉及的 Agent 框架 · Agent framework

ZCode Agent（自研）

提交前确认 · Pre-submission checklist

• 已搜索现有 issue（关键词：归档 / archive / retention / 自动清理 / 堆积），未见重复；相关但不同：#596（存储保留与清理，面向磁盘占用与删除）、#625（7.5GB 会话库导致 database is locked）、#617（CLI 创建的会话在桌面端侧边栏不可见）、#471（rollout 日志膨胀）。本条不请求"新增自动归档"，而是报告已存在的自动归档功能覆盖不全且不可观测。
• 已阅读 CONTRIBUTING.md

使用场景 · Use case

ZCode Desktop 3.12.2 / Windows 11。设置中已经开启「自动归档旧任务」且保留时长设为 7 天（~/.zcode/v2/setting.json：taskAutoArchiveEnabled = true、taskAutoArchiveOlderThanDays = 7，从 2026-09-14 之前的日志写入记录看一直是该值）。按预期，7 天不活跃的历史应当被自动收走，但任务列表仍然只增不减。

实测本机 ~/.zcode/v2/tasks-index.sqlite（2026-09-16，tasks 表）：

指标	实测值
任务总数	40
已归档（archived = 1）	6
该 6 个的 updated_at	几乎都是当天/前一天（今天 09:23、11:31 等）→ 只可能是手动归档
完全符合归档候选条件却未归档	13
其中最旧一条的 updated_at	2026-09-02（14 天前）

候选条件用的是源码里的定义：archived = 0 AND pinned = 0 AND unread_at IS NULL AND task_status = 'completed' AND updated_at < 现在 - 7 天。

再看这 13 个的工作区分布，就能定位问题：

工作区	符合条件未归档数
%USERPROFILE%\.zcode\workspace\default（纯 CLI 使用）	12
另一个项目工作区（最近在桌面端打开过）	1

而 setting.json 的 recentProjects 只包含两个最近打开过的项目工作区，完全不包含 default 工作区。

同时，~/.zcode/v2/logs/ 最近三天的日志里搜不到任何归档执行痕迹（源码中一旦真正归档成功会打印一条「按设置自动归档…」info），archiveStaleTasks / 归档相关关键词零命中。

根因（已在 3.12.2 的 app.asar 中核实）：

1. 扫描范围只覆盖"最近打开过的工作区"。归档入口 Er(workspaces) 只是遍历调用方传入的工作区列表：

   async function Er(v){
     if (v.length === 0) return;
     let R = await Ro();                 // 读设置，未启用则返回 null
     if (!R) return;
     for (let se of v) {                 // 只遍历传入的工作区
       ...
       let dt = await C.archiveStaleTasks({
         workspacePath: se.workspacePath,
         workspaceIdentity: se.workspaceIdentity,
         olderThanDays: R.olderThanDays
       });
       ...
     }
     G > 0 && info(`按设置自动归档…`);
   }
   

   设置项自身的描述也印证了这一点：「定时扫描最近打开过的工作区，将已完成、无未读、未置顶且超过保留期的任务自动归档」。结果是：从未在桌面端打开过的工作区（尤其纯 CLI 工作流）里的任务，永远不会进入归档扫描范围，无论不活跃多久。这与 #617 反映的是同一道断层——CLI 侧的会话/任务在桌面端视图中缺位。

2. 候选条件硬编码 task_status = 'completed'：

   r = ["workspace_key = ?","deleted = 0","archived = 0","pinned = 0",
        "unread_at IS NULL","updated_at < ?","task_status = 'completed'"];
   

   error、中断、未正常收尾的任务永远不满足条件，本机有 1 个 error 状态任务已超过 7 天，按现有逻辑将永久留存。

3. 自动归档没有任何可观测性。归档只在 G > 0 时打一条 info，设置界面也不显示"上次归档时间 / 归档数量 / 扫描了多少工作区"。用户端看到的现象就是"开关打开了、天数设了，任务还是一个不少"，无从判断是没生效、扫漏了，还是候选条件不满足。

建议方案 · Proposal

1. 扫描范围从"最近打开过的工作区"扩展到任务索引全量：对 tasks-index.sqlite 中存在 archived = 0 任务的所有 workspace_key 执行候选判定。可以保留"最近打开过的工作区走高频道扫描"，其余工作区做低频（如每日一次）或开机后一次全量补齐，成本可控。
2. 放宽候选状态条件：把 task_status = 'completed' 从硬编码条件改为可配置项，例如设置里提供「仅归档已完成任务 / 归档所有不活跃任务」两档，默认把 completed 与 error / aborted 一并纳入。
3. 补齐可观测性与手动入口：设置项下方显示「上次自动归档：<时间>，归档 个任务」；任务列表提供「立即清理不活跃任务」按钮；归档动作写入日志时带上"扫描工作区数 / 候选数 / 实际归档数"，便于用户和你们排查。
4. 建议把默认值改为开启（当前 taskAutoArchiveEnabled 默认 false）。功能默认关闭、界面又无任何提示，绝大多数用户不会主动发现它——这与 #596 报告的"~/.zcode 只增不减"是同一条痛点链，自动归档本该是它的日常缓解手段。

预期价值 · Expected value

• 开启归档后历史列表真正有界：本机在修好后可立即消化 13 个陈旧任务（最早的已 14 天）。
• 覆盖纯 CLI 工作流用户：CLI 的会话同样写入任务索引，但这些工作区从不在桌面端打开，是目前完全无人管理的增量。
• 行为可验证之后，用户才敢把自动归档当作 #596 / #625 的日常缓解手段，而不是定期手动删文件自救。

你认为的优先级 · Your perceived priority

中 · Medium

你使用的 ZCode 版本 / 环境 · ZCode version / environment

ZCode Desktop 3.12.2（Windows 11 x64）/ GLM Coding Plan

补充材料 · Additional context

• 源码证据（resources/app.asar，3.12.2）：归档入口 Er(v) 与候选 SQL 见上；设置为 taskAutoArchiveEnabled（zod 默认 false）与 taskAutoArchiveOlderThanDays（int().positive().max(365).default(7)）。

• 设置项文案（i18n）：settings.taskAutoArchive =「自动归档旧任务」；settings.taskAutoArchiveDays =「归档保留时长」；settings.taskAutoArchiveDays.option.3/7/14/30。

• 数据可自行复现，对 ~/.zcode/v2/tasks-index.sqlite 直接查 tasks 表即可：

  select count(*) from tasks
  where archived = 0 and pinned = 0 and unread_at is null
    and task_status = 'completed' and updated_at < :now_minus_7d;
  

• 本机结果：40 个任务里 13 个满足上述条件却未归档，其中 12 个属于从未在桌面端打开过的 default 工作区；同期 6 个已归档任务的 updated_at 均为当天/前一日，只能来自手动操作。

Start by examining the archive entry point Er(v), C.archiveStaleTasks, and the settings keys taskAutoArchiveEnabled and taskAutoArchiveOlderThanDays in resources/app.asar. Use tasks-index.sqlite and the provided SQL query to reproduce the missed candidates. Done should cover the agreed workspace and task-status scope and provide verifiable archive results or logs.