Watchtower DAP Windows Debugging

<!-- Sync Impact Report --> <!-- Version change: none → 1.0.0 --> <!-- Modified principles: None (new constitution) --> <!-- Added sections: Performance Targets, Compatibility Constraints --> <!-- Removed sections: None --> <!-- Templates requiring updates: plan-template.md (constitution check), spec-template.md (requirements alignment) --> <!-- Follow-up TODOs: None --> # Watchtower Constitution <!-- Example: Spec Constitution, TaskFlow Constitution, etc. --> ## Core Principles ### I. Windows-Native Focus <!-- Windows-native only (no Linux/WSL in v1). --> The Watchtower MCP debugging tool MUST be Windows-native only in v1. No Linux/WSL support will be implemented in the initial release. This approach ensures faster time-to-market and leverages the Windows debugging ecosystem advantages. ### II. DAP as Single Source of Truth <!-- DAP is the single source of truth for debugging. --> DAP (Debug Adapter Protocol) MUST be the single source of truth for all debugging operations. All debugging state, breakpoints, and execution control MUST flow through DAP adapters, ensuring consistency and reliability across different language runtimes. ### III. Minimal MCP Tool Surface <!-- MCP tool surface is minimal and language-agnostic. --> The MCP tool surface MUST be minimal and language-agnostic. Tools SHOULD expose only essential debugging operations that work across all supported languages without exposing language-specific implementation details. ### IV. Stdio-First Transport <!-- Stdio transport by default; TCP only for explicit attach. --> Stdio transport MUST be the default for all debugging sessions. TCP transport MUST only be used when explicitly requested by the user for remote debugging scenarios. ### V. Deterministic Debug Loop <!-- Deterministic debug loop suitable for agents. --> The debug loop MUST be deterministic and suitable for automated agents. All operations MUST follow predictable state transitions and provide reliable event sequencing for agent-based workflows. ### VI. Security-By-Default <!-- Security-by-default: redact env/args, least FS access. --> All operations MUST follow security-by-default principles. Environment variables and arguments MUST be redacted in logs and outputs. File system access MUST be limited to the minimum necessary for debugging operations. ### VII. Observability Foundation <!-- Observability from day one: logs + metrics + traces. --> Comprehensive observability MUST be implemented from day one. All operations MUST include structured logging, performance metrics, and execution traces to enable effective debugging and monitoring. ## Performance & Compatibility Constraints <!-- Example: Additional Constraints, Security Requirements, Performance Standards, etc. --> ### Performance Targets - **Time to First Break**: Debugging sessions MUST achieve first breakpoint hit within 1000ms (P95) - **Step Performance**: Individual stepping operations MUST complete within 200ms (P95) - **Event Processing**: Event buffers MUST handle high-frequency events without drops or significant latency ### Compatibility Requirements The tool MUST support the following platforms and runtimes: - **Operating Systems**: Windows 10, Windows 11 - **Node.js**: Version 22.x, Runtime versions 20.x and 22.x - **.NET**: Version 8.x - **Python**: Version 3.11+ - **Dart/Flutter**: Version 3.x ### Operational Constraints - **Headless Operation**: NO IDE UI; headless MCP tools only - **No Remote Linux**: NO remote Linux/container targets in v1 - **Bounded Buffers**: Event buffers MUST be bounded with pagination support ## Development Governance <!-- Example: Constitution supersedes all other practices; Amendments require documentation, approval, migration plan --> ### Amendment Procedure - All principle changes MUST be documented with clear rationale - Amendments require approval from the project maintainers - Migration plans MUST be provided for any breaking changes - Changes MUST be backward compatible unless explicitly approved otherwise ### Quality Gates - All PRs MUST verify compliance with these principles - Performance targets MUST be met before merging - Security constraints MUST be enforced in all code paths - Compatibility MUST be tested against all supported platforms ### Compliance Review - Monthly compliance reviews MUST be conducted - Performance benchmarks MUST be run regularly - Security audits MUST be performed before major releases - User feedback MUST be incorporated into principle evolution **Version**: 1.0.0 | **Ratified**: 2025-10-17 | **Last Amended**: 2025-10-17