Bug: 导航真相源注入 stale artifact 污染 — 已删除文件持续占据 [导航] 块

[kaverjody]

现象

猫的每轮对话顶部 [导航] 块持续注入 真相源: deploy-irb.py / 下一步: 先看 deploy-irb.py，即使该文件已被删除且与当前 thread 无关。

导致猫被误导去读取不存在的文件，产出串台/幻觉回复。

根因分析

代码路径：packages/api/src/domains/cats/services/agents/routing/route-helpers.ts:729-755

const mem = await threadStore.getThreadMemory(threadId);  // ← thread-scoped ✓
const storedLedgerArtifacts = mem.recentArtifacts;
const mergedLedger = mergeLedger(storedLedgerArtifacts, recentArtifacts);
const rankedSources = rankArtifactSources(mergedLedger, ...);
const topSource = rankedSources[0];

问题在 buildThreadMemory.ts 的 artifact ledger 策略：

G1: Artifact ledger — append+dedup+cap (cumulative, not overwrite)

一旦文件路径进入 recentArtifacts ledger，永远不会被移除，即使：

• 文件已删除
• 文件与当前对话完全无关
• 文件来自很久以前的 session

mergeLedger() 只做 append + dedup by ref + cap by count，无文件存在性检查、无 TTL、无过期淘汰。

复现步骤

1. 在某 thread 创建临时文件（如 /tmp/deploy-irb.py）
2. Session seal 后，文件路径进入 threadMemory.recentArtifacts
3. 删除该文件
4. 后续所有该 thread 的对话，导航都指向这个已删除的文件

影响

• 猫被误导读取不存在的文件
• 导航失去"指向当前工作上下文"的本来意义
• 用户体验：猫"串台"行为，实际是导航注入层指错路

建议修复

方案 A（推荐）：在 rankArtifactSources 前加文件存在性过滤

在 route-helpers.ts:748 后，对 mergedLedger 做文件存在性检查（PR 类型除外）。

方案 B：ledger 加 TTL 过期

在 mergeArtifactLedger() 里加时间窗口——超过 7 天的 artifact 自动淘汰。

方案 C：SessionSealer 写入时过滤已删除文件

在 SessionSealer.ts:412-416 调用 extractRecentArtifacts 前，过滤掉不存在的文件。

相关代码

• packages/api/src/domains/cats/services/agents/routing/route-helpers.ts:729-755
• packages/api/src/domains/cats/services/agents/routing/artifact-tracking.ts:38-67
• packages/api/src/domains/cats/services/agents/routing/source-ranking.ts:40-87
• packages/api/src/domains/cats/services/session/buildThreadMemory.ts:68-86
• packages/api/src/domains/cats/services/session/SessionSealer.ts:412-425

[zts212653]

👋 @kaverjody — 又一条高质量 bug report，感谢！代码路径 + 根因方向清晰。

Triage verdict: ✅ Accepted bug

标签 bug + triaged + accepted。

这条命中一个 architectural pattern：thread memory 里 stale artifact 缺 sweep/expiry 机制。你指的 route-helpers.ts:729-755 + buildThreadMemory.ts 是正确入口。

Direction 需要 maintainer 拍板的地方

recentArtifacts 的 lifecycle policy 有几个 open question:

1. Sweep 触发时机：每轮对话都 revalidate？还是 lazy on-read？还是 background cron？
2. File existence check 的 cost：如果每轮 top-N artifact 都 stat 一下，长 thread 会慢
3. "stale" 定义：文件不存在 = stale 明确；但如果文件 rename / move 呢？
4. 是否要保留 tombstone：删掉的 artifact 是否留一条 "这个 artifact 已删" 的记录，方便审计？

这些不是 blocker，是让实现方向收敛前要先想清楚。

Path

先标 accepted。要不要自提 PR？如果不修，我们家会开 architectural follow-up thread 承接。

[宪宪/claude-opus-4-7🐾] — inbound maintainer triage

[kaverjody]

感谢 triage！

PR 已提交

PR #1068 已提交，覆盖了基本场景：

• filterStaleArtifacts() 新函数（async file existence check）
• 两处 call site：navigation [真相源] 前 + briefingContext 里
• PR-type artifacts 保留
• Fail-open on throw

已验证生效（详见 PR #1068 comment）。

关于 open questions

你列的 4 个问题都很有价值，当前 PR 是 defensive layer，没有完全解决 architectural pattern：

Question	当前实现	后续可改进
Sweep 触发时机	Lazy on-read（每轮 filter）	可加 background sweep 或 TTL expiry
Stat cost	N 个 artifact 并行 stat，N 通常 ≤5	长 thread 可加 short-lived cache
Stale 定义	文件不存在 = stale	rename/move 场景后续可加 inode/mtime 检测
Tombstone	无（直接 filter 掉）	可考虑留审计记录

作为 follow-up，可以开新 issue 追踪更完整的 sweep/expiry 机制。当前 PR 先解决"已删除文件污染导航"这个最痛的场景。

🐾