Test
9ed6c2638d
- Add internal/history package for pruning workflow history - Implement HistoryPruner with configurable pruning policies - Automatic pruning on size/age/count thresholds - Archive old entries to disk for compliance - Memory-efficient history management - Continue-as-new compatible design - 17 history tests, all passing Features: - AddEntry() for adding task history - Automatic pruning by: - Maximum history size (default 100MB) - Maximum entry age (default 24 hours) - Maximum entry count (default 1000) - Manual Prune() trigger - GetEntries() with filters (status, time range, recent) - UpdateEntry() for status changes - Archive old entries to configurable directory - Clear() to reset history Pruning Strategy: - Entries sorted by end time (oldest first) - Remove entries exceeding any threshold - Archive to disk for historical analysis - Keep recent entries for debugging - 90% threshold triggers auto-pruning Memory Management: - Constant memory growth even with 1000s of tasks - Estimated size calculated per entry - Size ratio tracked (current vs max) - Memory info reporting Statistics: - Total size and entry count - Average entry size - Prune and archive counts - Last prune timestamp - Usage ratio (%) - Memory growth rate Archival: - Optional archive directory - Entries saved as JSON for analysis - Timestamp included in filename - Non-blocking archive operations Test Coverage: - 17 history tests (add, query, prune, archive) - Constant memory growth verified (1000 tasks) - Age-based pruning verified - Archive directory creation tested - Status filtering tested - Recent entries retrieval tested - Update operations tested - Policy defaults verified Verification: - Memory stays within bounds ✓ - Old entries pruned correctly ✓ - Recent entries preserved ✓ - Archive functionality working ✓ - Concurrent safe (RWMutex) ✓ Next: T2.8 (Distributed lock optimization)
1.8 KiB
1.8 KiB
Task Board — Milestone T2: Scale & Performance
Submilestone: T2 (Distributed execution, caching, performance optimization)
| ID | Scope | Status | Branch | Verification |
|---|---|---|---|---|
| T2.1 | Activity result caching: deduplicate repeated LLM calls for same task state | [x] | task/T2.1 |
Implementer called 2x on same code → second call returns cached Implementer output |
| T2.2 | Parallel task dispatch: multiple T0.x tasks execute truly concurrently (not sequential) | [x] | task/T2.2 |
9 tasks complete in ~1/9 total time (wall-clock speedup measured) |
| T2.3 | Prompt template caching: pre-compile Go templates on worker startup | [x] | task/T2.3 |
Template render latency < 100ms (vs parse+render each time) |
| T2.4 | Lessons file indexing: fast lookup of past failures without full file scan | [x] | task/T2.4 |
Query lessons by task type → return in < 10ms for 1000s of entries |
| T2.5 | Git operation batching: combine multiple worktree commits into single push/merge | [x] | task/T2.5 |
N tasks → 1 push (vs N pushes), measured via git ref-log |
| T2.6 | LLM request batching: group similar Implementer calls into one API request | [x] | task/T2.6 |
3 implementer tasks → 1 Anthropic API call with batch input (vs 3 separate calls) |
| T2.7 | Workflow history pruning: trim old task unit outputs from orchestrator history | [x] | task/T2.7 |
Continue-as-new cycle history size constant despite 1000s of task units completed |
| T2.8 | Distributed lock optimization: replace flock with Redis/etcd for multi-pod scenarios | [ ] | task/T2.8 |
5 concurrent orchestrators on different pods share FS safely via distributed lock |
Submission Criteria
All T2.1–T2.8 marked [x] → submilestone complete → squash-merge task/T2.* to main.