# YAGNI Analysis Report
## Overview
This report identifies "You Aren't Gonna Need It" (YAGNI) violations in the obsidian-mcp-resources codebase - features and abstractions that were implemented but are not actually used.
## Major YAGNI Violations
### 1. Subscription System (High Impact)
**Location**: `src/subscriptions/`
**Issue**: Complete subscription infrastructure with no actual usage
- **Components**:
- `SubscriptionManager`: Manages client subscriptions
- `SubscriptionHandlers`: Handles subscribe/unsubscribe requests
- `NotificationTrigger`: Triggers resource update notifications
- `CacheNotificationHooks`: Hooks for cache invalidation notifications
- **Evidence**:
- No tools actually call `NotificationTrigger` or notification methods
- Only exists in examples and tests
- Infrastructure is fully built but dormant
- **Recommendation**: Remove entire subscription system until actually needed
### 2. OptimizedBatchProcessor (Medium Impact)
**Location**: `src/utils/OptimizedBatchProcessor.ts`
**Issue**: Advanced batch processor with streaming, retry logic, and progress tracking - never used
- **Features**:
- Streaming results with `processStream()`
- Dynamic concurrency control
- Exponential backoff retry logic
- Progress callbacks
- **Evidence**:
- No imports found in production code
- Only used in tests and documentation
- Regular `BatchProcessor` is used instead (and only in ObsidianClient)
- **Recommendation**: Remove until complex batch processing is actually needed
### 3. RequestDeduplicator (Medium Impact)
**Location**: `src/utils/RequestDeduplicator.ts`
**Issue**: Utility to prevent duplicate concurrent requests - never used
- **Evidence**:
- No imports in production code
- Only exists with tests
- **Recommendation**: Remove until concurrent request deduplication is needed
### 4. Config File Loading (Low Impact)
**Location**: `src/utils/configLoader.ts`
**Issue**: Complex config file loading from ~/.config/mcp/obsidian.json
- **Features**:
- Custom config file paths via OBSIDIAN_CONFIG_FILE
- JSON config file parsing
- Config precedence system
- **Evidence**:
- Most users just use environment variables
- Adds complexity for edge case usage
- **Recommendation**: Consider simplifying to env-only config
### 5. Multiple Batch Processing Utilities (Low Impact)
**Location**: `src/utils/`
**Issue**: Two batch processors when one would suffice
- **Current state**:
- `BatchProcessor`: Simple, used only once in ObsidianClient
- `OptimizedBatchProcessor`: Complex, never used
- **Recommendation**: Keep only the simple one that's actually used
## Complexity Analysis
### Over-Engineered Features
1. **Streaming in OptimizedBatchProcessor**
- Async generator pattern for "streaming results"
- No evidence of datasets large enough to need streaming
- Adds significant complexity
2. **Subscription System Architecture**
- Full pub/sub pattern implementation
- Server notification infrastructure
- No actual use case implemented
3. **Config Loading Hierarchy**
- Environment variables → Custom config file → Default config file
- Most users just need env vars
## Impact Assessment
### Code Removal Potential
- **Subscription system**: ~500+ lines of code
- **OptimizedBatchProcessor**: ~300 lines
- **RequestDeduplicator**: ~100 lines
- **Config file features**: ~50 lines
### Total removable: ~950+ lines of unused code
## Recommendations
### Immediate Actions
1. Remove subscription system entirely
2. Remove OptimizedBatchProcessor
3. Remove RequestDeduplicator
4. Simplify config to env-only
### Future Guidelines
1. Don't build infrastructure before use cases
2. Start simple, evolve based on actual needs
3. Question every abstraction layer
4. Remove unused code promptly
## Pattern Recognition
These YAGNI violations follow common patterns:
- **Anticipatory Infrastructure**: Building for imagined future needs
- **Over-Abstraction**: Creating layers that aren't utilized
- **Feature Creep**: Adding "nice to have" features without demand
- **Example-Driven Development**: Building features just for examples
## Conclusion
The codebase would benefit from significant simplification by removing these unused features. This would:
- Reduce maintenance burden
- Improve code clarity
- Make the project easier to understand
- Follow the YAGNI principle properly
The subscription system in particular represents significant over-engineering for a tool that primarily serves as a simple MCP interface to Obsidian.
