Auto-delete task history on plugin load (retention + checkpoint cleanup)

[hannesrudolph]

Closes #10850

Summary

Adds an auto-delete task history feature that purges old tasks on extension reload, helping users manage disk space and keep their task history clean.

Changes

New Setting

• Auto-delete task history dropdown in Settings → About
• Options: Never (default), 90 days, 60 days, 30 days, 7 days, 3 days
• Stored in VS Code global configuration as roo-cline.taskHistoryRetention

Purge Logic (src/utils/task-history-retention.ts)

• Runs once on extension activation
• Deletes tasks older than the configured retention period based on task_metadata.json timestamp
• Falls back to directory mtime for legacy tasks without metadata
• Detects and removes orphan checkpoint-only folders (directories containing only a checkpoints/ subdirectory)
• Uses ClineProvider.deleteTaskWithId() to ensure consistent cleanup of checkpoints, shadow repositories, and task state
• Includes retry logic with backoff for stubborn filesystem operations

UI Updates

• Added retention dropdown to About.tsx settings panel
• Full i18n support across 17 languages
• Warning text about permanent deletion

Testing

• New test suite task-history-retention.spec.ts covering:
  • Retention periods (3, 7, 30 days)
  • Dry run mode
  • Invalid metadata handling
  • Never (disabled) setting

Technical Notes

• Purge executes sequentially (not in parallel) to avoid race conditions when updating task state
• Verbose logging available but disabled by default to reduce noise
• Schema allows string enum values for UI compatibility

---

Important

Introduces an auto-delete task history feature with configurable retention periods, UI updates, and comprehensive testing.

• Behavior:
  • Adds auto-delete task history feature configurable via a dropdown in Settings → About.
  • Options include Never, 90, 60, 30, 7, and 3 days.
  • Purge logic in task-history-retention.ts deletes tasks older than the configured period.
  • Handles orphan checkpoint-only folders and uses ClineProvider.deleteTaskWithId() for cleanup.
• UI Updates:
  • Adds retention dropdown to About.tsx with i18n support for 17 languages.
  • Displays warning about permanent deletion.
• Testing:
  • New test suite task-history-retention.spec.ts for retention periods, dry run mode, and invalid metadata.
• Misc:
  • Adds TASK_HISTORY_RETENTION_OPTIONS to global-settings.ts.
  • Updates ClineProvider and webviewMessageHandler.ts to handle new setting.
  • Adds verbose logging and retry logic for filesystem operations.

^{This description was created by for 69efab6. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Oroocle   See task on Roo Cloud

Re-reviewed latest commit(s) on this PR (69efab6). No new issues found since the last review.

• Race condition in concurrent task state updates during purge
• settings:taskHistoryStorage i18n added only in en (missing in other locales)
• task-storage-size test suite mocks fs/promises but not VS Code config access via getStorageBasePath (can make tests environment-dependent)
• settings.taskHistoryRetention.description copy says "runs on extension reload" but purge now runs on activation
• common:taskHistoryRetention.* i18n keys exist only in src/i18n/locales/en/common.json (purge toast/actions can show missing-key strings in non-English UIs)

Previous reviews

• f5f7272: Review #1
• 51e1ab1: Review #2
• 4729908: Review #3
• d50d6a7: Review #4
• f109eb7: Review #5
• db6b195: Review #6
• 2423706: Review #7
• 7d20cc0: Review #8
• 48666c4: Review #9
• 3a5d03e: Review #10
• 32a6639: Review #11
• 82df612: Review #12
• ab6d3ab: Review #13
• cc67f71: Review #14
• 84853c9: Review #15
• 4f822b5: Review #16
• d8e63d7: Review #17
• f24227c: Review #18
• 16e6835: Review #19
• 42d73fe: Review #20
• d9b68d5: Review #21
• cb175d6: Review #22
• edbe270: Review #23
• 67c7629: Review #24
• 784a70d: Review #25
• 454fd8c: Review #26
• 9ad332f: Review #27

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}

[heyseth]

Executive Summary

This PR introduces an auto-delete task history feature that purges old tasks on extension reload. The implementation is well-architected, type-safe, and thoroughly tested. The code demonstrates solid engineering practices with proper error handling, i18n support, and integration with existing deletion logic.

Strengths

• ✅Consistency: Excellent reuse of existing deleteTaskWithId() logic ensures checkpoints, shadow repos, and state are cleaned up alongside files.
• ✅Reliability: Sequential deletion prevents race conditions, and robust retry logic handles stubborn filesystem operations.
• ✅Quality: Full i18n support across 17 languages and type-safe schema validation with Zod.

Suggested Enhancements (Code Included)

I have included specific code snippets in the comments to address performance and user trust:

1. Performance: Non-blocking Activation (Critical)
The current implementation awaits the purge process during the activate phase. On machines with large histories or slow disks, this will block the extension startup.

• Fix: I provided a snippet to wrap the logic in a background "fire-and-forget" task (void (async ...)), ensuring the extension activates immediately.
• Optimization: Added an early return check for retention === "never" to skip the logic entirely for the majority of users.

2. UX: Visibility & Trust
Silent deletion of user data can be alarming if a user expects to find a task.

• Fix: I added a Toast Notification logic to the background task. It only triggers if files were actually deleted and provides a direct link to Settings.

3. Testing: Edge Case Coverage
Since we are permanently deleting files, I identified a gap in testing regarding "Orphan Checkpoints" and "Legacy Mtime Fallback."

• Fix: I drafted 4 specific test cases to verify we strictly target garbage data and do not accidentally delete recent, valid tasks that lack metadata.

---

Conclusion

This is a high-value maintenance feature. Once the activation blocking issue is resolved (using the background task pattern I suggested), this logic is solid and ready for production!