[Question] should <read-files> and <modified-files> in compaction summary reflect current filesystem state?

[D7x7z49]

I noticed that <read-files> and <modified-files> tags in compaction summaries can include files that no longer exist on disk. Here is the flow:

1. During a session, the agent reads or edits a file. The path is collected by extractFileOpsFromMessage in packages/coding-agent/src/core/compaction/utils.ts.
2. On compaction, computeFileLists and formatFileOperations turn these paths into XML tags.
3. On re-compaction, extractFileOperations in compaction.ts inherits all old paths from the previous CompactionDetails. New tool calls add more paths.
4. Paths are never removed — even if the file was deleted later.

Concrete effect:

• A file deleted between two compactions still appears in <read-files> or <modified-files>.
• The LLM receives the summary, sees the file listed, tries to read it — and gets "file not found".

My question: is this by-design?

The comment on CompactionDetails says "Files read in the compacted history," which suggests historical tracking. But the summary is used for continuation, so listing deleted files seems to hurt more than help.

Would a filesystem check (fs.existsSync in computeFileLists) be a reasonable approach? Or do you see a different direction for this?