Progress Log for Daemon Architecture Migration
==============================================
Created: 2025-12-06
Repository: /home/beagle/work/devtool-mcp
Feature: Daemon Architecture with Persistent State
Risk Level: High (architectural change)
Scope: Production-ready with Windows support
## Planning Phase
[2025-12-06] Planning started
[2025-12-06] Architecture document created: docs/daemon-architecture.md
[2025-12-06] Protocol specification designed (memcache-style text protocol)
[2025-12-06] Tasks defined in tasks.json (14 tasks across 6 phases)
[2025-12-06] Planning artifacts created
## User Requirements Captured
- Scope: Production-ready (not just prototype)
- Streaming: Chunked responses (single request returns chunks until done)
- Persistence: Memory only (state lost on daemon restart)
- Constraints: Backwards compatible (existing MCP tools work unchanged)
## Architecture Decisions
1. Single binary with subcommand: `devtool-mcp daemon` vs default MCP mode
2. Text protocol over IPC (debuggable with netcat)
3. Auto-start daemon on first tool call if not running
4. Unix sockets (Linux/macOS) + named pipes (Windows)
5. Lock-free design preserved within daemon (sync.Map, atomics)
## Phase Breakdown
- Phase 1: Core daemon infrastructure (socket, protocol, main loop)
- Phase 2: Command handlers (migrate existing tool logic)
- Phase 3: MCP client shim (auto-start, delegation)
- Phase 4: Daemon management tool + main.go update
- Phase 5: Windows named pipe support
- Phase 6: Testing & documentation
## Key Files to Create
- internal/protocol/ - Command/response types and parser
- internal/daemon/ - Daemon core, handlers, socket management
- internal/client/ - Protocol client, auto-start logic
- internal/tools/daemon.go - New daemon management tool
## Key Files to Modify
- cmd/devtool-mcp/main.go - Add daemon subcommand
- internal/tools/process.go - Use client instead of direct manager
- internal/tools/proxy_tools.go - Use client instead of direct manager
- internal/tools/project.go - Use client instead of direct manager
## Risk Mitigation
- High risk: Auto-start race conditions → Use file locking
- High risk: State migration → Preserve existing interfaces
- Medium risk: Platform differences → Build tags, comprehensive testing
## Next Steps
1. Run session-init protocol to begin execution
2. Start with task-001 (protocol package)
3. Verify each task with its verification command
## Notes
- Existing ProcessManager/ProxyManager code unchanged
- MCP interface remains identical (backwards compatible)
- Daemon management exposed via new 'daemon' tool
- Debug with: echo "PING" | nc -U /tmp/devtool-mcp-$UID.sock
