Summary
Add a new configuration option protectedFilePatterns that prevents tool outputs involving certain files from being pruned. This would complement the existing protectedTools option by allowing protection based on file content rather than tool type.
Motivation
Currently, DCP protects certain tools from pruning (e.g., task, todowrite, todoread), but there's no way to protect file-based operations based on the file being accessed.
Files like plan.md, PLAN.md, ARCHITECTURE.md, TODO.md, DESIGN.md, and similar planning/context documents often contain critical project information that should remain in context throughout a session. When these files are read, the output provides important context that shouldn't be pruned even if it appears "stale" to the LLM analysis.
Proposed Solution
Add a new config option protectedFilePatterns that accepts an array of glob patterns or regex patterns:
Implementation Notes
-
Where to apply protection: In deduplicator.ts and janitor.ts, check if a tool's parameters.filePath matches any protected pattern before allowing it to be pruned.
-
Affected tools: This would primarily affect read, write, edit, and potentially glob/grep when they return results for matching files.
-
Pattern matching: Could use minimatch or a similar glob library that's already common in the Node ecosystem, or simple regex matching.
-
Default patterns: Consider including sensible defaults like:
const defaultProtectedFilePatterns = [
'**/plan.md',
'**/PLAN.md',
'**/TODO.md',
'**/ARCHITECTURE.md'
]
Example Use Case
A user reads plan.md at the start of a session to understand the project roadmap. Later, after several other file reads and edits, DCP's LLM analysis might incorrectly classify the plan.md read as "exploratory and no longer relevant" and prune it. With protectedFilePatterns, this important context would be preserved.
Alternatives Considered
- Protect all file reads - Too aggressive, would prevent legitimate pruning of actually obsolete file reads
- Manual protection via comments - User could add "keep this in context" but this is cumbersome
- Rely on LLM judgment - Current approach, but LLMs may not always recognize project-specific important files
Summary
Add a new configuration option
protectedFilePatternsthat prevents tool outputs involving certain files from being pruned. This would complement the existingprotectedToolsoption by allowing protection based on file content rather than tool type.Motivation
Currently, DCP protects certain tools from pruning (e.g.,
task,todowrite,todoread), but there's no way to protect file-based operations based on the file being accessed.Files like
plan.md,PLAN.md,ARCHITECTURE.md,TODO.md,DESIGN.md, and similar planning/context documents often contain critical project information that should remain in context throughout a session. When these files are read, the output provides important context that shouldn't be pruned even if it appears "stale" to the LLM analysis.Proposed Solution
Add a new config option
protectedFilePatternsthat accepts an array of glob patterns or regex patterns:{ "protectedTools": ["task", "todowrite", "todoread", "context_pruning"], "protectedFilePatterns": [ "**/plan.md", "**/PLAN.md", "**/ARCHITECTURE.md", "**/TODO.md", "**/DESIGN.md", "**/*.plan", "**/AGENTS.md" ] }Implementation Notes
Where to apply protection: In
deduplicator.tsandjanitor.ts, check if a tool'sparameters.filePathmatches any protected pattern before allowing it to be pruned.Affected tools: This would primarily affect
read,write,edit, and potentiallyglob/grepwhen they return results for matching files.Pattern matching: Could use minimatch or a similar glob library that's already common in the Node ecosystem, or simple regex matching.
Default patterns: Consider including sensible defaults like:
Example Use Case
A user reads
plan.mdat the start of a session to understand the project roadmap. Later, after several other file reads and edits, DCP's LLM analysis might incorrectly classify theplan.mdread as "exploratory and no longer relevant" and prune it. WithprotectedFilePatterns, this important context would be preserved.Alternatives Considered