feat: implement hierarchical memory management system

[roomote]

This PR implements a hierarchical memory management system as requested in issue #6602. The feature allows Roo Code to automatically load memory files (like CLAUDE.md or Roorules.md) recursively from parent directories when reading files.

Summary of Changes

Core Implementation

• HierarchicalMemoryManager: New class that handles recursive directory walking and memory file loading
• Duplicate Prevention: Uses a Set to track already-loaded memory files to prevent duplicates
• ApiMessage Extension: Added isHierarchicalMemory flag to distinguish memory messages from regular messages

Integration Points

• readFileTool: Integrated memory loading after file approval
• Task: Added memory injection and state management
• Context Compression: Hierarchical memories are automatically included in the compression process

UI Components

• ContextManagementSettings: Added toggle and file name configuration
• HierarchicalMemoryModal: New modal for viewing loaded memory files
• TaskActions: Added memory view button that appears when memories are loaded

Configuration

• Global Settings: Added enableHierarchicalMemory and hierarchicalMemoryFileNames settings
• Default: Feature is disabled by default, with "Roorules.md" as the default memory file name

Testing

• Comprehensive test suite for HierarchicalMemoryManager
• Tests cover duplicate prevention, error handling, and edge cases
• All existing tests continue to pass

How It Works

1. When a file is read via readFileTool, the system checks if hierarchical memory is enabled
2. If enabled, it walks up the directory tree from the file's location to the workspace root
3. At each directory level, it looks for configured memory files (e.g., Roorules.md)
4. Found memory files are loaded and marked with isHierarchicalMemory: true
5. These memories are injected into the conversation context before the file content
6. Users can view loaded memories via the memory view button in the UI

Benefits

• Reduces token waste by automatically loading relevant context
• Improves context management for large projects
• Maintains backward compatibility (disabled by default)
• Provides transparency through the memory viewer UI

Fixes #6602

---

Important

Implements a hierarchical memory management system with new classes, UI components, and settings, enhancing context management by loading memory files recursively from parent directories.

• Core Implementation:
  • Introduces HierarchicalMemoryManager class for recursive directory walking and memory file loading.
  • Prevents duplicate memory file loading using a Set.
  • Extends ApiMessage with isHierarchicalMemory flag.
• Integration Points:
  • Integrates memory loading in readFileTool() after file approval.
  • Adds memory injection and state management in Task class.
  • Includes hierarchical memories in context compression.
• UI Components:
  • Adds ContextManagementSettings for toggle and file name configuration.
  • Introduces HierarchicalMemoryModal for viewing loaded memory files.
  • Updates TaskActions with a memory view button.
• Configuration:
  • Adds enableHierarchicalMemory and hierarchicalMemoryFileNames to global settings.
  • Feature is disabled by default, with "Roorules.md" as default memory file name.
• Testing:
  • Comprehensive tests for HierarchicalMemoryManager covering duplicates, errors, and edge cases.
  • Existing tests remain unaffected.

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

[roomote]

I reviewed my own code and found bugs I didn't know I was capable of writing.

[roomote]

Is this intentional? The hierarchical memory messages are created with role "user" but the issue specification shows "system" role in the examples. This could affect how the AI interprets these memory instructions.

[roomote]

Potential memory leak: The read Set never gets cleared except when explicitly calling clearCache(). For long-running tasks, this could accumulate many file paths. Consider:

Suggested change

	if (e.code !== "ENOENT") console.error(e)
	} catch (e: any) {
	if (e.code !== "ENOENT") {
	console.error(`Failed to read memory file ${full}:`, e)
	}
	}

Also, should we implement a size limit or clear the cache when the task ends?

[roomote]

Race condition risk: Multiple approved files trigger memory loading sequentially. If files are in the same directory, the timing could cause issues. Consider collecting unique directories first:

Suggested change

	if (cline.memoryManager) {
	// Load hierarchical memory for approved files
	if (cline.memoryManager) {
	const approvedFiles = fileResults.filter((result) => result.status === "approved")
	const uniqueDirs = new Set<string>()
	for (const fileResult of approvedFiles) {
	const fullPath = path.resolve(cline.cwd, fileResult.path)
	uniqueeDirs.add(path.dirname(fullPath))
	}
	for (const dir of uniqueDirs) {
	const memoryMessages = await cline.memoryManager.loadFor(dir, cline.cwd)
	if (memoryMessages.length > 0) {
	await cline.injectHierarchicalMemory(memoryMessages)
	}
	}
	}

[roomote]

The Windows path test is skipped. Could we add proper cross-platform path handling tests? This is important for Windows users.

[roomote]

UI enhancement opportunity: When many memory files are loaded, users might benefit from a search/filter feature. Consider adding a simple text filter above the file list?

[daniel-lxs]

Closing, not on the roadmap