MCP Debugger

## Errors (blocking) ### `docs\development\GITHUB_SECRETS_SETUP.md` **Category**: debris **Issue**: Documentation debris: This document is a one-time setup checklist for configuring GitHub Secrets for CI/CD workflows. It tracks the status of secret configuration (configured vs. not yet configured), includes a "Current Status" section with specific milestones (e.g., "Tag v0.9.0-beta pushed"), "Next Steps" for immediate follow-up actions, and a "Last Updated" date. Its purpose is to guide a one-time infrastructure setup task rather than serve as ongoing reference documentation. Once all secrets are configured and CI is verified, the document's actionable purpose is exhausted. **Remediation**: Delete this file ### `docs\sse-connection-debug.md` **Category**: doc_incorrect_content **Issue**: The document states that POST requests use the 'X-Session-ID' header for session identification, but the shadow doc for sse-command.ts clearly states that the POST /sse endpoint 'Validates sessionId from query parameters', not from a header. The manual test script test-sse-protocol.js also shows the session ID being sent as a query parameter (extracted via regex from the endpoint URL), though test-sse-connection.js and test-sse-working.js do use X-Session-ID header. [evidence: src/cli/sse-command.ts — "Validates sessionId from query parameters"] **Remediation**: Update the document to show that the session ID should be passed as a query parameter in the POST URL (e.g., POST /sse?sessionId=<uuid>), not as an X-Session-ID header. This mismatch between header vs query parameter could be the root cause of the 'Invalid session ID' error described in the document. ### `docs\architecture\js-debug-vendoring.md` **Category**: doc_stale_content **Issue**: The document lists required sidecars as bootloader.js and optionally watchdog.js, but the shadow docs indicate the actual required sidecars are bootloader.js AND hash.js. hash.js is not mentioned anywhere in the document. [evidence: packages\adapter-javascript\scripts\build-js-debug.js — "Requires `bootloader.js` and `hash.js` sidecars for js-debug runtime"] **Remediation**: Add hash.js to the list of required support files throughout the document. Update the search-and-copy pseudocode to include 'hash.js' in the supportTargets set, and add it to the post-vendoring verification checklist as a critical file alongside bootloader.js. ### `docs\testing\RUST_MCP_DEBUGGER_TEST_REPORT_NEW.md` **Category**: debris **Issue**: Documentation debris: This is a one-time test execution report from a specific date (November 13, 2025) documenting the results of a manual testing session. It captures specific session IDs, specific error outputs, and specific environmental conditions from that single test run. While it contains useful bug analysis, it is a snapshot of a testing activity rather than an ongoing reference document. The bugs it identifies may have already been fixed, making this a process artifact from a one-time testing action. **Remediation**: Delete this file ### `docs\testing\RUST_MCP_DEBUGGER_TEST_REPORT_NEW.md` **Category**: doc_incorrect_content **Issue**: The report claims there is a path resolution bug in codelldb-resolver.ts where the code only goes up ONE directory level ('..') from __dirname, suggesting it needs TWO levels. However, the shadow documentation for codelldb-resolver.ts describes a multi-path search strategy with multiple fallback paths, including '../../vendor/codelldb/...' (package root production install) as the FIRST search path, and '../vendor/codelldb/...' (legacy dist directory) as the SECOND fallback. The report mischaracterizes the single '../' path as a bug when it is actually one of several intentional fallback paths in the search strategy. [evidence: packages\adapter-rust\src\utils\codelldb-resolver.ts — "Search strategy with multiple fallback paths (L33-41): 1. Package root production install (`../../vendor/codelldb/...`) 2. Legacy dist directory (`../vendor/codelldb/...`) 3. Monorepo source tree paths 4. Process CWD relative paths"] **Remediation**: Update the report to acknowledge that codelldb-resolver.ts uses a multi-path fallback search strategy that includes both ../../vendor and ../vendor paths. The actual issue may be that none of the fallback paths resolved correctly in the test environment, not that the code only uses a single '../' path. ### `docs\testing\RUST_MCP_DEBUGGER_TEST_REPORT_NEW.md` **Category**: doc_incorrect_content **Issue**: The report's proposed 'Code Fix Required' section shows incorrect code that does not match the actual architecture of codelldb-resolver.ts. The actual code uses a multi-path search strategy with multiple fallback paths tried sequentially, not a single path.resolve call. The suggested fix of changing one '..' to two '..' misrepresents the actual code structure. [evidence: packages\adapter-rust\src\utils\codelldb-resolver.ts — "Search strategy with multiple fallback paths (L33-41): 1. Package root production install (`../../vendor/codelldb/...`) 2. Legacy dist directory (`../vendor/codelldb/...`) 3. Monorepo source tree paths 4. Process CWD relative paths"] **Remediation**: Remove or rewrite the 'Code Fix Required' section to accurately reflect the multi-path fallback architecture. Investigate why none of the fallback paths (including the ../../ path) resolved correctly in the test environment. ### `docs\error-handling-guide.md` **Category**: doc_stale_content **Issue**: The document's error table lists PortAllocationError with error code 'InternalError', but the shadow doc indicates its property is 'reason' with default 'No available ports'. More importantly, the table is missing UnsupportedLanguageError which is actively used in the server (server.ts confirms 'Custom error types: SessionNotFoundError, SessionTerminatedError, UnsupportedLanguageError' for error handling). [evidence: src\server.ts — "Custom error types: SessionNotFoundError, SessionTerminatedError, UnsupportedLanguageError"] **Remediation**: Add UnsupportedLanguageError to the Available Error Types table and include it in the implementation patterns section as it's actively used in the server. ### `docs\docker-support.md` **Category**: doc_incorrect_content **Issue**: The document states the Docker image tag is 'mcp-debugger:local' when using the build scripts (docker-build.sh), but the actual build script tags the image as 'debug-mcp-server'. [evidence: scripts/docker-build.sh — "Executes `docker build -t debug-mcp-server .` to create the image with tag "debug-mcp-server""] **Remediation**: Update the documentation to clarify that docker-build.sh builds the image as 'debug-mcp-server', not 'mcp-debugger:local'. The manual build command uses 'mcp-debugger:local' but the build scripts use a different tag. Either align the documentation or note the discrepancy. ### `packages\shared\README.md` **Category**: doc_incorrect_content **Issue**: The README lists 'AdapterFactory' as the abstract base class for adapter factories, but the actual codebase uses 'BaseAdapterFactory' as the name for the base adapter factory class. [evidence: packages/shared/src/index.ts — "BaseAdapterFactory: Base implementation for adapter factories"] **Remediation**: Rename 'AdapterFactory' to 'BaseAdapterFactory' in the Base Classes section and update the usage example to extend 'BaseAdapterFactory' instead of 'AdapterFactory'. ### `docs\patterns\dependency-injection.md` **Category**: doc_incorrect_content **Issue**: The IProxyManagerFactory.create() method signature is shown without the optional adapter parameter. The doc shows `create(): IProxyManager` but the actual interface accepts an optional IDebugAdapter parameter. [evidence: src\factories\proxy-manager-factory.ts — "IProxyManagerFactory Interface (L13-15) - Single method `create(adapter?: IDebugAdapter): IProxyManager`"] **Remediation**: Update the IProxyManagerFactory interface example to show `create(adapter?: IDebugAdapter): IProxyManager` and update the ProxyManagerFactory.create() implementation accordingly. ### `docs\patterns\dependency-injection.md` **Category**: doc_incorrect_content **Issue**: The ProxyManagerFactory.create() implementation shown does not pass the adapter parameter. The actual implementation passes `adapter || null` to the ProxyManager constructor. [evidence: src\factories\proxy-manager-factory.ts — "`create()` method (L27-34) instantiates ProxyManager with injected dependencies - Passes `adapter || null` to handle optional debug adapter parameter"] **Remediation**: Update the ProxyManagerFactory example to show `create(adapter?: IDebugAdapter): IProxyManager` and include the adapter parameter being passed to the ProxyManager constructor. ### `tests\e2e\README.md` **Category**: doc_incorrect_content **Issue**: The README states Python adapter has 'Breakpoints verify immediately (unlike JavaScript)' but the shadow docs for the Python smoke test show breakpoints have unverified status initially, same as JavaScript. The Python test explicitly handles 'unverified status' for breakpoints. [evidence: tests\e2e\mcp-server-smoke-python.test.ts — "Unverified Breakpoints: Initial breakpoint status is false but functionality works (L119-122)"] **Remediation**: Update the Python adapter description to state that breakpoints may initially report as unverified (similar to JavaScript), not that they 'verify immediately'. ### `docs\javascript\typescript-source-map-investigation.md` **Category**: doc_incorrect_content **Issue**: The document shows a simplified code snippet for transformLaunchConfig() that doesn't match the actual implementation. The doc shows direct property setting (result.sourceMaps, result.outFiles, result.resolveSourceMapLocations) inline in transformLaunchConfig when detecting .ts files, but the actual implementation in javascript-debug-adapter.ts uses a much more complex flow involving automatic TypeScript detection via file extensions (.ts, .tsx, .mts, .cts), runtime selection priority (user override → tsx → ts-node → node), ESM project detection, and delegates outFiles handling to determineOutFiles() from config-transformer.ts. [evidence: packages/adapter-javascript/src/javascript-debug-adapter.ts — "Automatic TypeScript detection via file extensions (.ts, .tsx, .mts, .cts) Runtime selection priority: user override → tsx → ts-node → node Synchronous execution with fallbacks (cannot use async in interface) ESM project detection and loader configuration Source map and outFiles handling"] **Remediation**: Update the 'Current Implementation' code snippet to reflect the actual transformLaunchConfig implementation which involves runtime detection priority, ESM detection, and delegation to utility functions like determineOutFiles(), isESMProject(), and hasTsConfigPaths(). ### `docs\development\setup-guide.md` **Category**: doc_incorrect_content **Issue**: The setup guide says the server supports two transport modes: STDIO and TCP (with --transport tcp --port flags). The shadow docs show the server actually supports STDIO and SSE (Server-Sent Events) transports, not TCP. The CLI sets up 'stdio' and 'sse' commands, and extensive E2E tests validate SSE transport. There is no 'tcp' transport mentioned anywhere in the codebase. [evidence: src\index.ts — "Sets up three main CLI commands: 1. **stdio**: Handles MCP protocol over stdio transport 2. **sse**: Handles MCP protocol over Server-Sent Events transport 3. **check-rust-binary**: Validates Rust binary availability"] **Remediation**: Replace all references to TCP transport with SSE transport. Change `--transport tcp --port 6111` to `sse -p 6111` or the appropriate SSE command syntax. Update the VS Code launch configuration args accordingly. ### `docs\development\setup-guide.md` **Category**: doc_incorrect_content **Issue**: The VS Code launch configuration for 'Debug Server (TCP)' uses args ['--transport', 'tcp', '--port', '6111'], but the actual CLI uses 'sse' as a subcommand with '-p' flag for port, not '--transport tcp --port'. [evidence: scripts\start-sse-server.sh — "Starts the compiled JavaScript server with specific configuration: Mode: SSE (Server-Sent Events), Port: 3001, Log level: debug"] **Remediation**: Update the VS Code launch configuration to use the correct SSE command syntax, e.g., args: ['sse', '-p', '6111', '--log-level', 'debug'] ## Warnings (non-blocking) - `docs\getting-started.md`: The document instructs users to set a breakpoint at line 21, claiming it is 'inside the recursive fibonacci function'. According to the shadow documentation, fibonacci_recursive spans lines 9-16 and fibonacci_iterative spans lines 19-28. Line 21 is inside the fibonacci_iterative function, not the recursive one. [evidence: examples\python\fibonacci.py — "fibonacci_recursive(n) (L9-16): Classic recursive Fibonacci implementation... fibonacci_iterative(n) (L19-28): Optimized iterative Fibonacci implementation"] - `docs\windows-launcher-guide.md`: The guide refers to the project as 'Debug MCP Server' and uses 'debug-mcp-server' in paths, but the shadow documentation consistently refers to the project as 'mcp-debugger'. The project appears to have been renamed. For example, Docker images use 'mcp-debugger:local' and 'mcp-debugger:test', the npm package is 'mcp-debugger', and Claude CLI integration uses 'mcp-debugger' as the server name. [evidence: scripts/docker-build-if-needed.js — "IMAGE_NAME: Docker image name from env or 'mcp-debugger:local' default"] - `docs\windows-launcher-guide.md`: The MCP settings configuration examples show 'command' as a direct node invocation or batch script path, but the project now supports stdio mode explicitly via CLI arguments (e.g., 'node dist/index.js stdio'). The simple-run.cmd launcher just calls 'node dist\index.js' without the 'stdio' subcommand. [evidence: scripts/install-claude-mcp.sh — "Command: node $PROJECT_DIR/dist/index.js stdio"] - `docs\sse-connection-debug.md`: The PowerShell test commands in Step 4 show sending the session ID via 'X-Session-ID' header in a POST request to /sse, but the server validates sessionId from query parameters, not headers. [evidence: src/cli/sse-command.ts — "Validates sessionId from query parameters"] - `docs\rust-adapter-performance.md`: The document states the default/tested CodeLLDB version is 1.11.0, but the vendor script defaults to version 1.11.8. The footnote says 'CodeLLDB 1.11.0' while the actual vendored version is newer. [evidence: packages/adapter-rust/scripts/vendor-codelldb.js — "CODELLDB_VERSION (L31): Target version, defaults to '1.11.8'"] - `mcp_debugger_launcher\README.md`: The README states 'Node.js 16+ installed' as a requirement. The shadow documentation for the main project's bundling targets Node 18 (main bundle) and Node 20 (proxy bundle), suggesting Node.js 18+ would be more accurate. [evidence: scripts\bundle.js — "Main bundle uses... targets Node 18... Proxy bundle... targets Node 20"] - `docs\architecture\js-debug-vendoring.md`: The document states the preferred/first server entry is 'vsDebugServer.cjs' at top-level, but the shadow docs for build-js-debug.js show the discovery function's first preference is 'dist/vsDebugServer.js', not a .cjs file at the root. The actual entry discovery chain is: dist/vsDebugServer.js → dist/src/dapDebugServer.js → extension/src/dapDebugServer.js → js-debug/src/dapDebugServer.js → BFS fallback. [evidence: packages\adapter-javascript\scripts\build-js-debug.js — "Prefers Node/CJS bundle: `dist/vsDebugServer.js` ... Built-from-source ESM: `dist/src/dapDebugServer.js` ... VSIX packaging: `extension/src/dapDebugServer.js` ... Source ESM: `js-debug/src/dapDebugServer.js` ... BFS search for `dapDebugServer.js` or `vsDebugServer.js`"] - `docs\architecture\js-debug-vendoring.md`: The document's pseudocode shows the vendored output files as VENDOR_FILE and VENDOR_FILE_CJS, but the shadow docs clarify the script always produces both vsDebugServer.js and vsDebugServer.cjs with a local package.json containing 'type: commonjs'. The document doesn't mention the package.json CommonJS boundary creation. [evidence: packages\adapter-javascript\scripts\build-js-debug.js — "Always produces `vsDebugServer.js` and `vsDebugServer.cjs` (CommonJS enforcement) ... Creates local `package.json` with `"type": "commonjs"` boundary"] - `docs\architecture\js-debug-vendoring.md`: The document mentions copying sidecars including '.wasm, .map, .json, .node' files but also lists 'hash.js' is missing from the critical sidecars. The shadow docs confirm the script 'Copies server entry and critical sidecars (bootloader.js, hash.js, *.wasm, *.map)' - note hash.js is listed as a critical sidecar. [evidence: packages\adapter-javascript\scripts\build-js-debug.js — "Copies server entry and critical sidecars (bootloader.js, hash.js, *.wasm, *.map)"] - `docs\python_debugging_notes.md`: The document references functions 'startDebugpyAdapterAndSequence' and 'setupDapEventHandlers' as being in 'src/proxy/dap-proxy.ts', but the shadow docs show that dap-proxy.ts is now a clean re-export module (facade) that re-exports from multiple specialized modules. The actual proxy logic has been refactored into separate modules: dap-proxy-core.ts (ProxyRunner), dap-proxy-worker.ts (DapProxyWorker with handleInitCommand, setupDapEventHandlers), and dap-proxy-connection-manager.ts (connection and session initialization). [evidence: src\proxy\dap-proxy.ts — "Clean export module for DAP (Debug Adapter Protocol) proxy functionality, designed for testing and programmatic use without auto-execution. Acts as a facade providing access to all proxy components."] - `docs\python_debugging_notes.md`: The document references 'client.on('initialized', ...)' handler pattern, but the current architecture uses a policy-based approach with adapter policies (PythonAdapterPolicy) rather than direct client event handlers. The setupDapEventHandlers in dap-proxy-worker.ts handles initialized events at L450-513 with deferred initialized event handling for different adapter patterns. [evidence: src\proxy\dap-proxy-worker.ts — "setupDapEventHandlers() (L450-513): Configures event forwarding (initialized, output, stopped, etc.) ... Complex event ordering with deferred 'initialized' event handling to support different adapter initialization patterns."] - `assets\screenshots\README.md`: The README states variable-inspection.png shows 'both a=20, b=20 after line 4'. However, the swap_variables function bug is at lines 10-11 (a=b overwrites a, then b=a assigns new a to b). The bug manifests after lines 10-11, not after line 4. Line 4 is just the function definition. The variables would show both equal to 20 (original value of b) after the swap logic executes, not 'after line 4'. [evidence: examples\python_simple_swap\swap_vars.py — "L10: `a = b` - overwrites original value of `a`; L11: `b = a` - assigns the new value of `a` (which is now `b`'s original value) to `b`; Result: both variables contain the original value of `b`"] - `docs\testing\RUST_MCP_DEBUGGER_TEST_REPORT_NEW.md`: The report does not mention the CODELLDB_PATH environment variable fallback that exists in the resolver, which could serve as a workaround for the path resolution issue encountered. [evidence: packages\adapter-rust\src\utils\codelldb-resolver.ts — "Environment variable fallback: `CODELLDB_PATH` (L53-60)"] - `tests\e2e\npx\README.md`: The README lists 'npx-test-utils.ts' as a test utility file but does not mention 'smoke-test-utils.js', which is imported by both npx-smoke-javascript.test.ts and npx-smoke-python.test.ts for the parseSdkToolResult function. [evidence: tests\e2e\npx\npx-smoke-javascript.test.ts — "Custom utilities: `buildAndPackNpmPackage`, `installPackageGlobally`, `createNpxMcpClient`, `cleanupGlobalInstall` from `npx-test-utils.js` (L11) / `parseSdkToolResult` from `smoke-test-utils.js` (L12)"] - `tests\e2e\npx\README.md`: The README claims 'Mock adapter works' is tested under Language Support, but the shadow docs for npx-smoke-python.test.ts and npx-smoke-javascript.test.ts only describe tests for Python and JavaScript languages. There is no mention of a Mock adapter test file in the npx E2E test directory. [evidence: tests\e2e\npx\npx-smoke-javascript.test.ts — "Main test suite (L19-273): `describe.sequential('NPX: JavaScript Debugging Smoke Tests')`"] - `tests\e2e\npx\README.md`: The README states bundle size should stay reasonable at '<10MB', but the check-bundle-size.js script uses 8MB as the warning threshold and 15MB as the error threshold. The '<10MB' figure doesn't correspond to either threshold. [evidence: scripts\check-bundle-size.js — "WARN_SIZE_MB = 8 (L16) - Warning threshold for bundle size monitoring / ERROR_SIZE_MB = 15 (L17) - Hard limit that causes build failure"] - `tests\e2e\npx\README.md`: The README states step 4 tests via 'npx @debugmcp/mcp-debugger', but the actual test infrastructure installs the package globally and then creates an MCP client by resolving the global CLI entry point via 'npm root -g', bypassing npx entirely. [evidence: tests\e2e\npx\npx-test-utils.ts — "createNpxMcpClient() (L276-385): Creates MCP client connected to globally-installed package: Resolves global CLI entry point via `npm root -g` / Uses direct Node.js execution (bypasses npx.cmd on Windows)"] - `tests\e2e\npx\README.md`: The 'What These Tests Do' section lists 5 steps including 'Verify all adapters work - Tests Python, JavaScript, and Mock adapters', but there is no mock adapter test file listed in the test files section nor described in any shadow documentation for the npx E2E tests. [evidence: tests\e2e\npx\npx-smoke-python.test.ts — "End-to-end smoke test suite for Python debugging functionality when using the MCP debugger via `npx`"] - `CONTRIBUTING.md`: The CONTRIBUTING.md states the project uses 'npm' for dependency installation and building (e.g., 'npm install', 'npm run build', 'npm test'), but the validate-push.js script (which simulates CI) uses 'pnpm install' and 'pnpm build', indicating the project uses pnpm as its package manager, not npm. [evidence: scripts/validate-push.js — "Runs `pnpm install` in clean environment ... Executes `pnpm build` to verify compilation"] - `CONTRIBUTING.md`: The project structure section lists 'src/cli/', 'src/container/', 'src/dap-core/', 'src/debugger/', 'src/proxy/', 'src/session/', 'src/tools/', 'src/utils/' but does not reflect the monorepo/packages structure evident from shadow docs. The prepare-pack.js script references workspace packages (shared, adapter-go, adapter-javascript, adapter-python, adapter-mock, adapter-rust) under a 'packages/' directory, and check-bundle-size.js references 'packages/mcp-debugger/dist/cli.mjs'. [evidence: scripts/prepare-pack.js — "Scans hardcoded workspace packages (`shared`, `adapter-go`, `adapter-javascript`, `adapter-python`, `adapter-mock`, `adapter-rust`) ... PACKAGE_DIR (L14): Hardcoded path to `../packages/mcp-debugger`"] - `CONTRIBUTING.md`: The 'Running the Demo' section says to run 'node dist/index.js' but the server has specific CLI subcommands (stdio, sse, check-rust-binary). The entry point requires a transport mode to be specified for actual operation. [evidence: src/index.ts — "Sets up three main CLI commands: 1. **stdio**: Handles MCP protocol over stdio transport 2. **sse**: Handles MCP protocol over Server-Sent Events transport 3. **check-rust-binary**: Validates Rust binary availability"] - `CONTRIBUTING.md`: The Testing section mentions using Vitest test runner infrastructure (based on shadow docs showing vitest.setup.ts and vitest.workspace.ts), but the CONTRIBUTING.md does not mention Vitest. It also references tests/runners/run-tests.cmd which may be outdated given the project uses Vitest as its test framework. [evidence: tests/vitest.setup.ts — "Global Vitest test configuration and setup file that initializes test environments, manages global state, and provides cross-platform compatibility for ESM-based tests."] - `CONTRIBUTING.md`: The document lists 'Python 3.7+' as a prerequisite, but the shadow docs indicate the project supports multiple debug adapter languages including JavaScript (js-debug), Rust (CodeLLDB), Go, Python, and Mock adapters. Python is not the only debugging target. [evidence: scripts/check-adapters.js — "JavaScript adapter: Uses js-debug with specific vendor files and sidecars - Rust adapter: Uses CodeLLDB with multi-platform binary support"] - `CONTRIBUTING.md`: The Key Components section lists only 'Session Manager', 'DAP Proxy', 'MCP Tools', and 'Debugger Providers' but omits the adapter registry system which is central to the architecture. The server uses dynamic language discovery via an adapter registry. [evidence: src/server.ts — "Dynamic language discovery: Runtime detection of available debug adapters via adapter registry"] - `docs\error-handling-guide.md`: The Available Error Types table is missing several error classes that exist in the source code: NodeNotFoundError, UnsupportedLanguageError, and ProxyInitializationError are all defined in debug-errors.ts but not listed in the table. [evidence: src\errors\debug-errors.ts — "NodeNotFoundError (L44-48): Node.js-specific runtime error (marked for future use) ... UnsupportedLanguageError (L87-100): Unsupported programming language ... ProxyInitializationError (L177-190): Debug proxy setup failures"] - `docs\error-handling-guide.md`: The document mentions utility functions isRecoverableError() and getErrorMessage() only in the Debugging Tips section but doesn't document them properly. The shadow doc confirms these are important utility functions with specific behavior: isRecoverableError classifies SessionTerminatedError and SessionNotFoundError as non-recoverable, and ProxyNotRunningError and LanguageRuntimeNotFoundError as recoverable. There's also isMcpError<T> type guard not mentioned at all. [evidence: src\errors\debug-errors.ts — "isMcpError<T> (L195-200): Generic type guard for MCP error instances ... getErrorMessage (L205-210): Safe error message extraction ... isRecoverableError (L215-234): Determines if errors can be recovered from"] - `AGENTS.md`: AGENTS.md describes safe-commit.sh as ensuring 'builds, lint, and smoke tests succeed locally', but the shadow documentation for safe-commit.sh shows it only performs a personal information check (mandatory) and then either does a normal git commit or a git commit --no-verify. It does not run builds, lint, or smoke tests itself. [evidence: scripts\safe-commit.sh — "Bash wrapper script that enforces mandatory personal information checks before Git commits while providing optional bypass for other verification steps."] - `AGENTS.md`: AGENTS.md lists workspace modules as '@debugmcp/shared, adapter-mock, adapter-python, adapter-javascript', but the shadow documentation for prepare-pack.js lists workspace packages as 'shared, adapter-go, adapter-javascript, adapter-python, adapter-mock, adapter-rust'. AGENTS.md is missing adapter-go and adapter-rust from the packages listing. [evidence: scripts\prepare-pack.js — "Scans hardcoded workspace packages (`shared`, `adapter-go`, `adapter-javascript`, `adapter-python`, `adapter-mock`, `adapter-rust`)"] - `docs\go\README.md`: The document mentions Go 1.18 as minimum requirement without mentioning the Delve version requirement. The shadow docs indicate Delve 0.17.0+ is also a version requirement mentioned in the adapter metadata. [evidence: packages/adapter-go/src/go-adapter-factory.ts — "Returns static metadata including language info, file extensions (.go), version requirements (Go 1.18+, Delve 0.17.0+)"] - `docs\migration-guide.md`: The document header says it covers changes through v0.12.0, but the body includes a section for v0.15.0. The header note is inconsistent with the actual content. [evidence: docs\migration-guide.md — "This migration guide covers changes through v0.12.0, including the major UX improvements."] - `docs\migration-guide.md`: The v0.15.0 section mentions only two adapter packages (@debugmcp/adapter-mock and @debugmcp/adapter-python), but the adapter-loader's listAvailableAdapters() supports mock, python, javascript, rust, and go adapters. The guide under-reports available adapters. [evidence: src\adapters\adapter-loader.ts — "Supports mock, python, javascript, rust, and go debuggers with corresponding NPM packages (L138-144)."] - `docs\migration-guide.md`: The DebugLanguage enum shown in the migration guide only lists PYTHON and MOCK, but the shadow docs indicate JavaScript, Rust, and Go are also supported languages with adapters, policies, and vitest configs. [evidence: src\session\session-manager-data.ts — "Supports: Python, JavaScript, Rust, Go, Mock, with DefaultAdapterPolicy fallback"] - `docs\migration-guide.md`: The mock adapter source path referenced in 'Examples' points to '../src/adapters/mock/mock-debug-adapter.ts', but the actual mock adapter is in a separate package at 'packages/adapter-mock/src/mock-debug-adapter.ts'. [evidence: packages\adapter-mock\src\mock-debug-adapter.ts — "Mock debug adapter implementation for testing debug protocols without external dependencies."] - `docs\migration-guide.md`: The Python adapter source path referenced in 'Examples' points to '../src/adapters/python/python-debug-adapter.ts', but the actual Python adapter is in a separate package at 'packages/adapter-python/src/python-debug-adapter.ts'. [evidence: packages\adapter-python\src\python-debug-adapter.ts — "Python-specific debug adapter implementation that provides Python debugging functionality using debugpy."] - `docs\migration-guide.md`: The migration guide mentions the tool 'get_supported_languages' in Common Migration Issues, but the server's actual tool is named 'list_supported_languages' as shown in the v0.15.0 section and the server shadow doc. [evidence: src\server.ts — "Discovery: list_supported_languages"] - `docs\migration-guide.md`: The 'Extension Developers' section instructs users to manually register adapters and update a language enum, but with v0.15.0's dynamic adapter loading, adapters are discovered at runtime via naming conventions and don't require manual enum updates or explicit registry.register() calls. [evidence: src\adapters\adapter-loader.ts — "Dynamic adapter loading system for debugMCP that discovers, loads, and manages debugger adapters for different programming languages at runtime."] - `docs\migration-guide.md`: The environment variable list mentions 'MCP_DEBUGGER_SESSION_DIR', 'MCP_DEBUGGER_LOG_LEVEL', and 'MCP_DEBUGGER_LOG_FILE', but the shadow docs reference different environment variable names: 'DEBUG_MCP_LOG_LEVEL' for log level and 'MCP_CONTAINER' for container mode. The documented variable names cannot be confirmed from the shadow docs. [evidence: src\utils\logger.ts — "DEBUG_MCP_LOG_LEVEL: Global log level override"] - `packages\adapter-javascript\docs\README.md`: The README describes this as a 'non-functional adapter stub for Task 1 only' with 'stub methods and safe defaults', but the shadow docs for javascript-debug-adapter.ts show a fully implemented adapter with comprehensive functionality including launch config transformation, DAP protocol handling, connection management, TypeScript auto-detection, and feature support across 810 lines of code. [evidence: packages/adapter-javascript/src/javascript-debug-adapter.ts — "Primary JavaScript/TypeScript debug adapter implementation that wraps the vendored VS Code js-debug adapter in a standardized interface for the DebugMCP framework."] - `packages\adapter-javascript\docs\README.md`: The README states 'DebugLanguage enum currently lacks a JAVASCRIPT member; a TODO is noted in the adapter', but the shadow docs show the adapter is fully operational with language set to 'javascript' (cast to DebugLanguage), indicating this limitation has been worked around or resolved. [evidence: packages/adapter-javascript/src/javascript-debug-adapter.ts — "Language: 'javascript' (cast to DebugLanguage due to type limitations)"] - `packages\adapter-javascript\docs\README.md`: The README states 'Environment validation and adapter command building are trivial placeholders', but the shadow docs show comprehensive validation logic (Node.js version check, vendor dependency check, TypeScript runner detection) and a full adapter command builder that searches multiple paths for vsDebugServer.cjs/js and validates TCP port requirements. [evidence: packages/adapter-javascript/src/javascript-adapter-factory.ts — "validate() (L47-131): Comprehensive environment validation for JS/TS debugging"] - `packages\adapter-javascript\docs\README.md`: The README describes 'src/utils/* and src/types/* contain placeholders for later tasks', but the shadow docs show the index.ts exports real utility functions: resolveNodeExecutable, detectTsRunners, transformConfig, and the JsDebugConfig type - all of which are used by the adapter implementation. [evidence: packages/adapter-javascript/src/index.ts — "resolveNodeExecutable (L12): Utility function for locating and resolving Node.js executable paths... detectTsRunners (L13): Function to detect available TypeScript runtime environments"] - `packages\adapter-javascript\docs\README.md`: The README states the entry point vendor file is 'vendor/js-debug/vsDebugServer.js', but the shadow docs for the build script show it always produces both vsDebugServer.js AND vsDebugServer.cjs, and the integration test asserts the adapter command path ends with vsDebugServer.cjs. The adapter's buildAdapterCommand searches for vsDebugServer.cjs/js. [evidence: tests/adapters/javascript/integration/javascript-session-smoke.test.ts — "Asserts adapter path ends with `/vendor/js-debug/vsDebugServer.cjs`"] - `packages\adapter-javascript\docs\README.md`: The README lists only 'JavascriptAdapterFactory' as the export, but the actual index.ts also exports JavascriptDebugAdapter, resolveNodeExecutable, detectTsRunners, transformConfig, and the JsDebugConfig type. [evidence: packages/adapter-javascript/src/index.ts — "JavascriptAdapterFactory (L6)... JavascriptDebugAdapter (L9)... resolveNodeExecutable (L12)... detectTsRunners (L13)... transformConfig (L14)... JsDebugConfig (L17)"] - `docs\docker-support.md`: The document states debugpy runs on port 5678 in the 'Exposing debugpy Port' section, but the docker-entrypoint.sh shows debugpy is launched on port 5679. [evidence: docker/docker-entrypoint.sh — "Launches Python debugpy server in background: Host: 0.0.0.0, Port: 5679 (standard debugpy port)"] - `docs\docker-support.md`: The autoApprove list in the recommended Claude configuration is missing several tools that exist in the server. The server implements 16+ MCP tools including 'attach_to_process', 'detach_from_process', 'pause_execution', 'evaluate_expression', 'get_local_variables', 'get_source_context', and 'list_supported_languages' which are not listed in autoApprove. [evidence: src/server.ts — "Tool Categories: Session Management: create_debug_session, list_debug_sessions, close_debug_session; Debugging Control: start_debugging, attach_to_process, detach_from_process; Execution Control: step_over, step_into, step_out, continue_execution, pause_execution; Inspection: get_variables, get_local_variables, get_stack_trace, get_scopes; Evaluation: evaluate_expression, get_source_context; Discovery: list_supported_languages"] - `tests\README.md`: The README states the .actrc file uses 'catthehacker/ubuntu:full-22.04' images, but the 'Running Tests with Act' section above it says Act will 'Use your local catthehacker/ubuntu:act-latest image'. These two statements within the same document contradict each other. The 'Common Container Test Issues' section also says to use 'catthehacker/ubuntu:full-*' images (not act-* variants), which aligns with the Act Configuration section but contradicts the earlier statement about act-latest. [evidence: scripts\act-test.sh — "Uses `-j build-and-test` job targeting across workflows"] - `tests\README.md`: The README says the testing framework is 'Jest/Vitest' but the shadow docs consistently show Vitest as the primary testing framework. The vitest.setup.ts shadow doc shows comprehensive Vitest-specific setup, unit tests use Vitest (vi.mock, describe/it/expect/vi pattern), and E2E tests use Vitest. Jest is only referenced in jest-register.js for legacy E2E TypeScript support. The README's suggestion to use '--debug flag with Jest/Vitest' in the debugging section is also imprecise. [evidence: tests\vitest.setup.ts — "Global Vitest test configuration and setup file that initializes test environments, manages global state"] - `tests\README.md`: The test directory structure shown in the README omits several directories and files that exist according to the shadow docs. Missing entries include: tests/test-utils/ (contains promise-tracker.ts, python-environment.ts, session-id-generator.ts, helpers/port-manager.js, helpers/session-helpers.js), tests/vitest.setup.ts, tests/jest-register.js. The 'utils/' directory listed may actually be 'test-utils/'. [evidence: tests\test-utils\promise-tracker.ts — "Test utility for debugging promise memory leaks by tracking promise lifecycle across test sessions"] - `examples\visualizer\README.md`: The README lists 'Automatic file creation if missing' as a Log Watcher feature, but the shadow doc for log_watcher.py does not mention this capability. However, the live_visualizer.py shadow doc mentions 'Creates log file if it doesn't exist with proper error handling' and 'Automatic log file creation with parent directory structure', so this feature exists in the live_visualizer layer, not in log_watcher itself. The README's attribution to 'Log Watcher Features' is slightly misleading. [evidence: examples\visualizer\log_watcher.py — "Main class that monitors log files using polling with position tracking and file rotation detection."] - `docs\development\llm-collaboration-journey.md`: The document mentions '657 passing tests' as the end result. This is a point-in-time snapshot that is likely outdated given ongoing development evident from the shadow docs (multiple files with 2026-02-19 generation dates showing continued development). [evidence: tests\core\unit\session\session-manager-operations-coverage.test.ts — "@generated: 2026-02-19T23:47:50Z"] - `docs\multiple-mcp-servers.md`: The document states Node.js 16.0.0 or higher is required for the Debug MCP Server. However, the shadow docs for bundle.js show the main bundle targets Node 18 and the proxy bundle targets Node 20, suggesting Node.js 18+ is the actual minimum requirement. [evidence: scripts/bundle.js — "Main bundle (L15-34): Minified, CJS format, targets Node 18, keeps `fsevents` external... Proxy bundle (L131-150): Unminified for debugging, includes all dependencies, targets Node 20"] - `docs\multiple-mcp-servers.md`: The document references the server configuration using 'simple-run.cmd' as the command, and uses 'debug-mcp-server' as the server name. The shadow docs consistently refer to the project as 'mcp-debugger' (e.g., in install-claude-mcp.sh, docker-build-if-needed.js, prepare-pack.js). The project appears to have been renamed from 'debug-mcp-server' to 'mcp-debugger'. [evidence: scripts/install-claude-mcp.sh — "Removes existing mcp-debugger configuration and adds new JSON-based MCP server configuration... Tool Prefix: `mcp__mcp-debugger__` for Claude Code integration"] - `docs\agent-debugging-guide.md`: The document mentions Python breakpoint status as simply working, but the shadow docs for Python E2E tests indicate that Python breakpoints initially report as 'unverified' (verified=false) even though they function correctly. This is a notable Python-specific behavior not mentioned in the guide. [evidence: tests\e2e\mcp-server-smoke-python.test.ts — "Unverified Breakpoints: Initial breakpoint status is false but functionality works"] - `docs\agent-debugging-guide.md`: The document doesn't mention that Python expression evaluation is expression-only and rejects statements (like assignments). The E2E tests explicitly validate this constraint. [evidence: tests\e2e\mcp-server-smoke-python.test.ts — "Expression-Only Eval: Statements like assignments should fail"] - `docs\architecture\adapter-api-reference.md`: The document states transformLaunchConfig has a synchronous signature `transformLaunchConfig(config: GenericLaunchConfig): LanguageSpecificLaunchConfig`, but the shadow docs for debug-adapter.ts indicate it is async since v2.1.0 to support build operations like Rust compilation. [evidence: packages/shared/src/interfaces/debug-adapter.ts — "transformLaunchConfig() (L121) - **Async since v2.1.0** - Transform generic to language-specific launch config (supports build operations like Rust compilation)"] - `packages\shared\README.md`: The README omits many significant exports from the shared package, including: AdapterPolicy and language-specific policies (JsDebugAdapterPolicy, PythonAdapterPolicy, RustAdapterPolicy, GoAdapterPolicy, MockAdapterPolicy, DefaultAdapterPolicy), DapClientBehavior, process interfaces (IProcess, IProcessLauncher, IDebugTarget, IDebugTargetLauncher, IProxyProcess), AdapterLaunchBarrier, FileSystem, IDependencies, AdapterError, ValidationResult, AdapterInfo, and re-exports of @vscode/debugprotocol. [evidence: packages/shared/src/index.ts — "Language-Specific Policies (L174-187): AdapterPolicy, JsDebugAdapterPolicy, PythonAdapterPolicy, RustAdapterPolicy, GoAdapterPolicy... Client Behavior Abstractions (L189-195): DapClientBehavior... Utility Services (L197-202): AdapterLaunchBarrier, FileSystem... External Integration (L204-205): Re-exports @vscode/debugprotocol types"] - `packages\shared\README.md`: The README lists 'DebugLanguage' supported languages as 'Python, Mock, etc.' but the actual DebugLanguage enum supports more languages including Go and Rust (as evidenced by GoAdapterPolicy, RustAdapterPolicy, and JsDebugAdapterPolicy exports). [evidence: packages/shared/src/models/index.ts — "DebugLanguage (L79-85): Supported programming languages including MOCK for testing scenarios"] - `packages\shared\README.md`: The README mentions 'SessionState.RUNNING' and 'SessionState.PAUSED' in the usage example, but according to the models, SessionState is a legacy deprecated enum, and the codebase has moved to a dual-state model with SessionLifecycleState and ExecutionState. [evidence: packages/shared/src/models/index.ts — "SessionState (L120-135): Legacy state enum marked deprecated, maintained for backward compatibility"] - `docs\development\build-pipeline.md`: The document says 'Uses tsup (replacing esbuild)' for package builds, but the shadow doc for scripts/bundle.js still describes the root-level bundle.js as using esbuild for bundling. The document may be conflating two different bundling stages — tsup for the mcp-debugger package and esbuild for the root bundle.js script. [evidence: scripts\bundle.js — "Node.js build script that bundles the MCP (Model Context Protocol) debugger server and its proxy component into standalone executable files using esbuild."] - `docs\development\build-pipeline.md`: The document describes the build process architecture with 'Bundling with tsup' section stating the project uses tsup and replaced esbuild, but scripts/bundle.js shadow doc confirms esbuild is still actively used for creating dist/bundle.cjs and dist/proxy/proxy-bundle.cjs at the root level. [evidence: scripts\bundle.js — "Main bundling orchestrator that: Creates main application bundle from `dist/index.js` to `dist/bundle.cjs`... `esbuild`: Primary bundling engine"] - `docs\development\build-pipeline.md`: The document says scripts/bundle.js creates 'dist/proxy/proxy-bundle.cjs' as part of the root build, but the document also attributes proxy-bundle.cjs creation to the tsup-based mcp-debugger package build. The shadow doc for bundle.js confirms it creates a proxy bundle at dist/proxy/proxy-bundle.cjs using esbuild, suggesting there may be two different proxy bundles or the doc conflates the two. [evidence: scripts\bundle.js — "Creates secondary proxy bundle from `dist/proxy/dap-proxy-entry.js`... Output Artifacts: `dist/proxy/proxy-bundle.cjs`: Proxy component bundle"] - `docs\development\build-pipeline.md`: The document says the check-bundle-size script checks against 'esbuild metafile format for bundle analysis' per its shadow doc, but the build-pipeline doc claims the project uses tsup replacing esbuild. The bundle size checker still assumes esbuild metafile format. [evidence: scripts\check-bundle-size.js — "Assumes esbuild metafile format for bundle analysis"] - `docs\patterns\event-management.md`: The document states ProxyManagerEvents interface is at lines 48-67, but the shadow doc for proxy-manager.ts indicates it's at lines 30-46. [evidence: src\proxy\proxy-manager.ts — "ProxyManagerEvents Interface (L30-46)"] - `docs\patterns\event-management.md`: The document states IProxyManager interface is at lines 48-67 (same section), but the shadow doc indicates IProxyManager is at lines 51-73. [evidence: src\proxy\proxy-manager.ts — "IProxyManager Interface (L51-73)"] - `docs\patterns\event-management.md`: The ProxyManagerEvents interface shown in the document does not include the 'dap-event' event, but the shadow doc lists it as one of the typed events emitted by ProxyManager. [evidence: src\proxy\proxy-manager.ts — "Status events: 'dry-run-complete', 'adapter-configured', 'dap-event'"] - `docs\patterns\event-management.md`: The document references session-manager.ts lines 121-122 and 184-310 for the WeakMap pattern, but session-manager.ts is actually a thin facade class that extends SessionManagerOperations. The WeakMap and event handler setup are in session-manager-core.ts (sessionEventHandlers at L84, setupProxyEventHandlers at L205-355). [evidence: src\session\session-manager-core.ts — "sessionEventHandlers: WeakMap (L84) - Event handler cleanup tracking... setupProxyEventHandlers(session, proxyManager, launchArgs) (L205-355) - Event binding for proxy lifecycle"] - `docs\patterns\event-management.md`: The document references cleanup pattern at session-manager.ts lines 313-344, but this code lives in session-manager-core.ts at lines 357-387. [evidence: src\session\session-manager-core.ts — "cleanupProxyEventHandlers(session, proxyManager) (L357-387) - Safe event handler removal"] - `docs\patterns\event-management.md`: The document attributes auto-continue logic, state transitions, promise-based event waiting, and event race conditions to 'src/session/session-manager.ts' with specific line numbers. However, SessionManager is a thin facade extending SessionManagerOperations. These implementations are in session-manager-core.ts and session-manager-operations.ts. [evidence: src\session\session-manager.ts — "Main class extending SessionManagerOperations to provide complete session management interface... currently minimal implementation"] - `docs\architecture\mock-adapter-design.md`: The document describes the mock adapter process as located at 'src/adapters/mock/mock-adapter-process.ts', but the shadow documentation shows the actual location is 'packages/adapter-mock/src/mock-adapter-process.ts'. The project uses a monorepo package structure, not a flat src/adapters/mock/ path. [evidence: packages\adapter-mock\src\mock-adapter-process.ts — "This file implements a mock Debug Adapter Protocol (DAP) server for testing purposes."] - `docs\architecture\mock-adapter-design.md`: The document's mock variable data shows sample variables 'localVar' (int, 42), 'complexObject', and 'largeArray', but the actual mock adapter process uses different sample variables: x=10, y=20, result=30 for locals and __name__, __file__ for globals. [evidence: packages\adapter-mock\src\mock-adapter-process.ts — "Locals: x=10, y=20, result=30 (sample integers) Globals: __name__, __file__ (sample strings)"] - `docs\architecture\mock-adapter-design.md`: The document shows mock-adapter-process.ts using a TCP server created with 'createServer' from 'net' module and listening on host/port. While TCP mode is supported, the shadow docs indicate the default communication mode is stdio (stdin/stdout), not TCP. The document only shows the TCP mode without mentioning stdio as the default. [evidence: packages\adapter-mock\src\mock-adapter-process.ts — "Stdio Mode: Default, uses process.stdin/stdout for DAP communication. TCP Mode: Creates server on specified host:port, allows reconnections (L144-171)"] - `docs\architecture\mock-adapter-design.md`: The document's MockDebugAdapter class example shows an event-based pattern with 'this.emit()' calls directly in the adapter class, but the shadow documentation indicates the actual implementation delegates DAP communication through a ProxyManager pattern with 'sendDapRequest()' as a stub for ProxyManager delegation. [evidence: packages\adapter-mock\src\mock-debug-adapter.ts — "sendDapRequest() (L358-369): Stub for ProxyManager delegation"] - `docs\architecture\mock-adapter-design.md`: The document describes the mock adapter process using command-line arguments but doesn't mention the --session argument. The shadow docs indicate the process supports --port, --host, AND --session command-line arguments. [evidence: packages\adapter-mock\src\mock-adapter-process.ts — "Command-line argument parsing for TCP mode (--port, --host, --session) (L107-128)"] - `docs\patterns\dependency-injection.md`: The document shows the SessionManager constructor taking `(config: SessionManagerConfig, dependencies: SessionManagerDependencies)` directly, but the actual SessionManager class extends SessionManagerOperations which extends SessionManagerData which extends SessionManagerCore. The constructor pattern shown may not reflect the actual class hierarchy. [evidence: src\session\session-manager.ts — "SessionManager (L28): Main class extending SessionManagerOperations to provide complete session management interface"] - `docs\patterns\dependency-injection.md`: The IProxyProcess interface shown includes a `sendCommand(command: any): void` method, but the actual IProxyProcess interface has different members including sessionId, sendCommand(), and waitForInitialization(). [evidence: src\interfaces\process-interfaces.ts — "IProxyProcess (L86-90): Enhanced IProcess for proxy operations - Session ID tracking (L87) - Command sending via sendCommand() (L88) - Initialization waiting with optional timeout (L89)"] - `docs\patterns\dependency-injection.md`: The production container configuration is shown at `src/container/dependencies.ts` with a simplified `createProductionDependencies()` that returns only 4 dependencies (fileSystem, processManager, networkManager, logger). The actual function is much more complex with process launchers, factories, adapter registry, and environment configuration. [evidence: src\container\dependencies.ts — "createProductionDependencies() (L71-170): Main factory function that creates production-ready dependency container with real implementations... Core Services, Process Launchers, Factories, Adapter System"] - `docs\patterns\dependency-injection.md`: The createProductionDependencies() function is shown taking no parameters, but the actual implementation takes a ContainerConfig parameter. [evidence: src\container\dependencies.ts — "Configuration: ContainerConfig input for logger and service configuration"] - `docs\patterns\dependency-injection.md`: The document shows createTestDependencies() at `tests/utils/test-utils.ts` but the actual location is `tests/test-utils/helpers/test-utils.ts`. Also, the function shown doesn't match - the shadow docs show individual mock creation functions like createMockFileSystem and createMockLogger rather than a unified createTestDependencies function. [evidence: tests\test-utils\helpers\test-utils.ts — "createMockLogger(L319-326) - Creates ILogger mock with all logging methods; createMockFileSystem(L332-351) - Creates IFileSystem mock with default successful responses"] - `CLAUDE.md`: The CLAUDE.md describes transport modes including TCP mode ('node dist/index.js --transport tcp --port 6111'), but the shadow docs for src/index.ts only mention 'stdio' and 'sse' CLI commands, with no mention of a TCP command. The CLI sets up three commands: stdio, sse, and check-rust-binary. [evidence: src\index.ts — "Sets up three main CLI commands: 1. **stdio**: Handles MCP protocol over stdio transport 2. **sse**: Handles MCP protocol over Server-Sent Events transport 3. **check-rust-binary**: Validates Rust binary availability"] - `CLAUDE.md`: The CLAUDE.md lists 16 MCP tools in the 'Available Tools After Integration' section but only enumerates 12 tools (create_debug_session, set_breakpoint, start_debugging, step_over, step_into, step_out, continue_execution, get_variables, get_stack_trace, evaluate_expression, close_debug_session, plus get_source_context is not listed). The shadow docs for server.ts confirm 16 tools are registered, including tools like list_debug_sessions, attach_to_process, detach_from_process, pause_execution, get_local_variables, get_scopes, get_source_context, and list_supported_languages that are missing from CLAUDE.md's tool list. [evidence: src\server.ts — "**Tool Categories:** 1. **Session Management**: create_debug_session, list_debug_sessions, close_debug_session 2. **Debugging Control**: start_debugging, attach_to_process, detach_from_process 3. **Execution Control**: step_over, step_into, step_out, continue_execution, pause_execution 4. **Inspection**: get_variables, get_local_variables, get_stack_trace, get_scopes 5. **Evaluation**: evaluate_expression, get_source_context 6. **Discovery**: list_supported_languages"] - `CLAUDE.md`: The CLAUDE.md states the adapter loader has '5 known adapters' for the file adapter-loader.ts, which is consistent with the shadow docs showing mock, python, javascript, rust, and go. However, the CLAUDE.md states the container mode path handling is 'Only /workspace/ prepend for existence checks', while the shadow docs for simple-file-checker.ts indicate it uses a centralized 'resolvePathForRuntime()' function from container-path-utils.js rather than a simple /workspace/ prepend. [evidence: src\utils\simple-file-checker.ts — "**Path Resolution Strategy**: Delegates all path transformation to container-path-utils for consistency across the codebase."] - `CLAUDE.md`: The CLAUDE.md mentions 'dap-proxy-worker.ts' as a key file but does not mention the AdapterManager in the DAP Proxy System section accurately. The shadow docs show the worker uses an adapter policy pattern (DefaultAdapterPolicy, JsDebugAdapterPolicy, PythonAdapterPolicy, etc.) rather than an 'AdapterManager' for managing language-specific adapters. The actual components are DapProxyWorker with adapterPolicy, GenericAdapterManager (for process spawning), and DapConnectionManager. [evidence: src\proxy\dap-proxy-worker.ts — "Main DAP (Debug Adapter Protocol) proxy worker that bridges debugging clients and debug adapters using the Adapter Policy pattern to eliminate language-specific hardcoding."] - `CLAUDE.md`: The DebugLanguage enum in models.test.ts shadow docs confirms 5 languages (python, javascript, rust, go, mock), which is consistent with CLAUDE.md. The session states described in CLAUDE.md as 'IDLE → INITIALIZING → READY → RUNNING → PAUSED → TERMINATED' don't match the shadow docs which show a dual-state model with SessionLifecycleState (created, active, terminated) and ExecutionState (initializing, running, paused, terminated, error), plus a legacy SessionState with 7 states. [evidence: tests\core\unit\session\models.test.ts — "SessionLifecycleState: 3 states (created, active, terminated) ExecutionState: 5 states (initializing, running, paused, terminated, error) SessionState (legacy): 7 states"] - `docs\architecture\adapter-development-guide.md`: The document describes `transformLaunchConfig` as a synchronous method in the minimal adapter example (`transformLaunchConfig(config: any): any { return config; }`), but the shadow doc for IDebugAdapter states that `transformLaunchConfig` is 'Async since v2.1.0' and supports build operations like Rust compilation, implying it should return a Promise. [evidence: packages/shared/src/interfaces/debug-adapter.ts — "transformLaunchConfig() (L121) - **Async since v2.1.0** - Transform generic to language-specific launch config (supports build operations like Rust compilation)"] - `docs\architecture\adapter-development-guide.md`: The document states the CLI has no mention of a 'check-rust-binary' command, but the shadow doc for src/index.ts shows there are three CLI commands: stdio, sse, and check-rust-binary. This is not a contradiction in the adapter guide itself, just context. However, the guide mentions `DEBUG=mcp:*` for debugging but the shadow docs indicate console output is permanently silenced in the server entry point, which could make this advice misleading. [evidence: src/index.ts — "Console output is permanently silenced to prevent protocol corruption"] - `docs\javascript\README.md`: The document states 'TypeScript debugging with source maps is currently under active development' and 'automatic source map resolution to TypeScript source files is not yet fully functional.' However, the shadow docs show a dedicated E2E testing fixture (tests/fixtures/javascript-e2e/app.ts) specifically for 'debugging TypeScript applications with source maps' and the adapter has comprehensive TypeScript support including automatic runtime detection, ESM project detection, loader configuration, and source map/outFiles handling. [evidence: packages/adapter-javascript/src/javascript-debug-adapter.ts — "Automatic TypeScript detection via file extensions (.ts, .tsx, .mts, .cts)... Runtime selection priority: user override → tsx → ts-node → node... ESM project detection and loader configuration... Source map and outFiles handling"] - `docs\javascript\README.md`: The document describes the adapter transport as 'Stdio communication with adapter' in the Implementation Details section. However, the shadow docs clearly state the adapter uses TCP-only transport mode. [evidence: packages/adapter-javascript/src/javascript-debug-adapter.ts — "Provides TCP-only transport mode for proxy infrastructure... TCP Transport Only: Adapter port validation required for proxy infrastructure"] - `tests\e2e\README.md`: The README does not mention several existing E2E test files: mcp-server-smoke-go.test.ts (Go debugging), mcp-server-smoke-rust.test.ts (Rust debugging), mcp-server-smoke-javascript-sse.test.ts (JavaScript SSE transport), comprehensive-mcp-tools.test.ts (comprehensive tool matrix), debugpy-connection.test.ts (debugpy integration), test-event-utils.ts, and rust-example-utils.ts. The README only lists 6 files but there are significantly more E2E test files. [evidence: tests\e2e\mcp-server-smoke-go.test.ts — "End-to-end smoke test for Go debugging functionality through MCP (Model Context Protocol) interface"] - `tests\e2e\README.md`: The 'Transport Methods' coverage section lists 'stdio, SSE, containerized stdio' but misses that tests also cover JavaScript debugging over SSE transport (mcp-server-smoke-javascript-sse.test.ts), which specifically tests an IPC corruption fix. [evidence: tests\e2e\mcp-server-smoke-javascript-sse.test.ts — "Critical test that validates a production issue where console output during SSE server operation corrupts IPC channels, causing JavaScript debugging to fail with empty stack traces"] - `tests\e2e\README.md`: The 'Language Adapters' coverage section only mentions 'JavaScript and Python debugging adapters' but the E2E tests also cover Go (mcp-server-smoke-go.test.ts), Rust (mcp-server-smoke-rust.test.ts), and Mock adapters (comprehensive-mcp-tools.test.ts). [evidence: tests\e2e\mcp-server-smoke-rust.test.ts — "E2E smoke test suite for Rust debugging functionality through MCP (Model Context Protocol) interface"] - `tests\e2e\README.md`: The README describes Python adapter as having 'Clean stack traces without internal frames' and 'Stable variable references (no refresh needed)' as contrasting with JavaScript, but the shadow docs show the Python test validates 'Clean Stack Traces: Expects fewer than 10 frames without internal runtime frames' and 'Stable References: Variable references don't require refresh after stepping'. While these claims are present in the shadow docs, the characterization of 'Breakpoints verify immediately' is contradicted. [evidence: tests\e2e\mcp-server-smoke-python.test.ts — "Breakpoint setting with unverified status handling (L108-123)"] - `tests\e2e\README.md`: The README's 'Running the Tests' section doesn't include commands for the Go, Rust, JavaScript-SSE, comprehensive tools, or debugpy connection tests. [evidence: tests\e2e\mcp-server-smoke-go.test.ts — "MCP Server Go Debugging Smoke Test @requires-go"] - `tests\e2e\README.md`: The Prerequisites section doesn't mention Go or Rust toolchain requirements needed for Go and Rust E2E tests. [evidence: tests\e2e\mcp-server-smoke-go.test.ts — "Requires Go compiler and Delve debugger for full flow test"] - `docs\architecture\javascript-adapter.md`: The document states DebugLanguage includes 'javascript' and that unit tests expect 'three languages'. The shadow doc for models.test.ts shows the DebugLanguage enum has 5 languages: python, javascript, rust, go, mock. The test suite validates 5 languages, not three. [evidence: tests\core\unit\session\models.test.ts — "DebugLanguage: 5 languages including python, javascript, rust, go, mock"] - `docs\architecture\javascript-adapter.md`: The document mentions the vendor dependency path as 'packages/adapter-javascript/vendor/js-debug/vsDebugServer.js', but the build script and adapter factory indicate the primary server entry is 'vsDebugServer.cjs' (CommonJS enforced), and the integration test asserts the path ends with '/vendor/js-debug/vsDebugServer.cjs'. [evidence: tests\adapters\javascript\integration\javascript-session-smoke.test.ts — "Asserts adapter path ends with `/vendor/js-debug/vsDebugServer.cjs`"] - `docs\architecture\javascript-adapter.md`: The document says the adapter loader lists JavaScript with 'installed: false' when unavailable but 'still lists the adapter as available'. The shadow docs for adapter-loader.ts confirm it has a hardcoded list of known adapters (mock, python, javascript, rust, go) with runtime availability detection. However, the document implies only three adapters exist (mock, python, javascript) by saying 'default build' includes mock and python. The known adapters list actually includes 5 languages. [evidence: src\adapters\adapter-loader.ts — "Supports mock, python, javascript, rust, and go debuggers with corresponding NPM packages (L138-144)."] - `docs\architecture\javascript-adapter.md`: The document states the export surface includes 'resolveNodeExecutable' described as resolving 'the Node runtime path in a cross-platform, deterministic manner'. While this is exported, the document omits two other public exports: 'detectTsRunners' and 'transformConfig', which are part of the package's public API surface. [evidence: packages\adapter-javascript\src\index.ts — "resolveNodeExecutable (L12)... detectTsRunners (L13): Function to detect available TypeScript runtime environments... transformConfig (L14): Configuration transformation utility"] - `docs\architecture\javascript-adapter.md`: The document mentions the adapter command builds vsDebugServer.js path, but the shadow doc for JavascriptDebugAdapter shows buildAdapterCommand searches for 'vsDebugServer.cjs/js' (multiple possible paths), and the build script produces both vsDebugServer.js and vsDebugServer.cjs with CommonJS enforcement. [evidence: packages\adapter-javascript\src\javascript-debug-adapter.ts — "Searches multiple possible paths for vsDebugServer.cjs/js"] - `docs\vitest-llm-config.md`: The document states the test-results-analyzer.js usage is 'node tests/utils/test-results-analyzer.js --level=summary', but the shadow documentation shows the file is located at 'tests/test-utils/helpers/test-results-analyzer.js', not 'tests/utils/test-results-analyzer.js'. [evidence: tests\test-utils\helpers\test-results-analyzer.js — "Test utility script that parses JSON test results and provides formatted analysis output with multiple detail levels."] - `docs\javascript\typescript-source-map-investigation.md`: The document's 'Proposed Solution 1: Smart Path Resolution' suggests implementing .ts → .js path resolution as a new feature, but the actual implementation already handles TypeScript files through runtime transpiler detection (tsx, ts-node) with automatic runtime selection. The document's proposed solution of checking for a corresponding .js file and swapping the program path is not how the adapter works - it uses runtimeExecutable substitution instead. [evidence: packages/adapter-javascript/src/javascript-debug-adapter.ts — "Runtime selection priority: user override → tsx → ts-node → node"] - `docs\javascript\typescript-source-map-investigation.md`: The document's Solution 2 code snippet shows a simplified version of tsx detection that doesn't reflect the actual implementation. The real implementation uses detectBinary() from typescript-detector.ts with local-first resolution strategy, platform-aware binary names, PATH fallback, and caching - not a simple which() call. [evidence: packages/adapter-javascript/src/utils/typescript-detector.ts — "detectBinary() (L43-70): Detects single TypeScript runner with platform-aware binary resolution... Local-First Resolution (L50-61): Checks <cwd>/node_modules/.bin/ first for project-local installations... PATH Fallback (L63-67): Uses whichInPath utility when local binaries not found"] - `docs\javascript\typescript-source-map-investigation.md`: The document states the adapter 'passes the .ts file directly to js-debug' as the problem, but the actual implementation in javascript-debug-adapter.ts already handles TypeScript files by detecting them via extensions and configuring appropriate runtime executables (tsx/ts-node). The adapter does not simply pass .ts files directly to js-debug without configuration. [evidence: packages/adapter-javascript/src/javascript-debug-adapter.ts — "Automatic TypeScript detection via file extensions (.ts, .tsx, .mts, .cts) Runtime selection priority: user override → tsx → ts-node → node"] - `docs\javascript\typescript-source-map-investigation.md`: The document references 'November 6, 2025' as previous test results and 'November 11, 2025 deployment tests' but these are future dates relative to the document's 'January 12, 2025' latest testing date. This is internally inconsistent - the 'previous' results have later dates than the 'latest' testing. [evidence: examples/javascript/typescript_test.ts — "TypeScript test file specifically designed for MCP debugger testing. Provides comprehensive scenarios for testing source map resolution, breakpoints, variable inspection, and TypeScript-specific debugging features."] - `docs\development\dap-sequence-reference.md`: The document describes 'node-debug2' as the Node.js debug adapter used in VS Code, but the shadow docs show the codebase uses 'js-debug' (pwa-node) as the JavaScript debug adapter, with multi-session child debugging support. node-debug2 is a predecessor that has been superseded. [evidence: packages/shared/src/interfaces/adapter-policy-js.ts — "JavaScript-specific adapter policy for VS Code's js-debug (pwa-node) debugger, implementing multi-session debugging behavior"] - `docs\development\dap-sequence-reference.md`: The document references 'vscode-node-debug2' throughout the Node.js section, but the codebase exclusively uses js-debug (pwa-node) with a complex multi-session architecture including child session management, command queueing, strict handshake protocols, and reverse request handling - none of which are mentioned. [evidence: src/proxy/child-session-manager.ts — "Manages child debug adapter sessions for multi-session debugging scenarios, particularly JavaScript debugging with js-debug/pwa-node which requires concurrent sessions"] - `docs\development\dap-sequence-reference.md`: The document mentions states like 'Initializing' and 'Disconnected' as optional states but doesn't reflect the actual state model used in the codebase which has a dual-state model separating SessionLifecycleState (CREATED, ACTIVE, TERMINATED) from ExecutionState (INITIALIZING, RUNNING, PAUSED, TERMINATED, ERROR). [evidence: packages/shared/src/models/index.ts — "SessionLifecycleState (L90-97): High-level session existence states (CREATED, ACTIVE, TERMINATED). ExecutionState (L103-114): Detailed execution states within active sessions (INITIALIZING, RUNNING, PAUSED, TERMINATED, ERROR)."] - `docs\development\debugging-guide.md`: The guide references CLI commands 'stdio' and 'sse' but also shows transport === 'tcp' for health checks. The actual CLI setup from index.ts shows three commands: stdio, sse, and check-rust-binary. There is no 'tcp' transport mentioned in the source. [evidence: src\index.ts — "Sets up three main CLI commands: 1. **stdio**: Handles MCP protocol over stdio transport 2. **sse**: Handles MCP protocol over Server-Sent Events transport 3. **check-rust-binary**: Validates Rust binary availability"] - `docs\development\setup-guide.md`: The guide states Node.js v16.0.0 or higher is required, but the bundle script targets Node 18 for the main bundle and Node 20 for the proxy bundle, suggesting Node 16 may not be sufficient. [evidence: scripts\bundle.js — "Main bundle (L15-34): Minified, CJS format, targets Node 18... Proxy bundle (L131-150): Unminified for debugging, includes all dependencies, targets Node 20"] - `docs\development\setup-guide.md`: The directory structure shows a flat src/ layout with session/, proxy/, dap-core/, interfaces/, implementations/, utils/ directories. The shadow docs reference a monorepo structure with packages/ directory (packages/shared, packages/adapter-go, packages/adapter-javascript, packages/adapter-python, packages/adapter-mock, packages/adapter-rust, packages/mcp-debugger) which is not reflected in the documented structure. [evidence: scripts\prepare-pack.js — "Scans hardcoded workspace packages (`shared`, `adapter-go`, `adapter-javascript`, `adapter-python`, `adapter-mock`, `adapter-rust`) and extracts their current versions from package.json files"] - `docs\development\setup-guide.md`: The guide mentions only Python debugging support and uses 'npm' commands throughout, but the project is a monorepo using pnpm (validate-push.js uses pnpm install/build) and supports multiple languages including Python, JavaScript, Rust, Go, and Mock adapters. [evidence: scripts\validate-push.js — "Runs `pnpm install` in clean environment... Executes `pnpm build` to verify compilation"] - `docs\development\setup-guide.md`: The guide lists only Python (v3.7+) as a language prerequisite for debugging, but the project supports JavaScript, Rust, Go, and Mock debugging adapters with corresponding E2E test suites. [evidence: tests\e2e\comprehensive-mcp-tools.test.ts — "validates all 19 MCP debugger tools across 5 supported languages (Python, JavaScript, Rust, Go, Mock)"] - `docs\development\setup-guide.md`: The 'Running the Server Locally' section shows 'DEBUG=* node dist/index.js' for debug logging, but the actual server silences all console output to prevent MCP protocol corruption. The server uses structured logging via a logger utility, not the DEBUG environment variable. [evidence: src\index.ts — "Console Silencing (L12-34): IIFE that must execute first to prevent stdout pollution that can corrupt MCP protocol in stdio mode and IPC channels in SSE mode. Silences all console methods and process warnings."] - `docs\stack-trace-filtering.md`: The document states Python has 'No filtering applied (shows all frames)' and lists only JavaScript as having stack frame filtering. However, the Go adapter policy also implements stack frame filtering, removing Go runtime (/runtime/) and testing (/testing/) frames unless includeInternals is true. The document's claim that only JavaScript sessions use filtering is incomplete/misleading. [evidence: packages\shared\src\interfaces\adapter-policy-go.ts — "Stack Frame Filtering (L275-296): Removes Go runtime (`/runtime/`) and testing (`/testing/`) frames unless `includeInternals` is true"] - `docs\stack-trace-filtering.md`: The document states 'Only JavaScript sessions use filtering currently' under the SessionManagerData section. The shadow docs show that the selectPolicy method in SessionManagerData supports Python, JavaScript, Rust, Go, Mock with DefaultAdapterPolicy fallback, and the Go adapter policy also implements stack frame filtering. [evidence: src\session\session-manager-data.ts — "selectPolicy() (L28-48): Maps debug language strings/enums to appropriate adapter policies. Supports: Python, JavaScript, Rust, Go, Mock, with DefaultAdapterPolicy fallback"] - `docs\stack-trace-filtering.md`: The document's supported languages list mentions only JavaScript and Python, omitting Rust and Go which are also supported debug languages with their own adapter policies. While the document focuses on stack trace filtering specifically, stating 'Python/Other languages: No filtering applied' under edge cases is misleading since Go does apply filtering. [evidence: packages\shared\src\interfaces\adapter-policy-go.ts — "Stack Frame Filtering (L275-296): Removes Go runtime (`/runtime/`) and testing (`/testing/`) frames unless `includeInternals` is true"] - `docs\architecture\dual-pattern-decision-guide.md`: The GoAdapterPolicy example shows filterStackFrames filtering only runtime/ frames, but the actual implementation also filters /testing/ frames. [evidence: packages/shared/src/interfaces/adapter-policy-go.ts — "Stack Frame Filtering (L275-296): Removes Go runtime (`/runtime/`) and testing (`/testing/`) frames unless `includeInternals` is true"] - `docs\architecture\dual-pattern-decision-guide.md`: The GoAdapterPolicy example shows resolveExecutablePath returning only providedPath or 'dlv', but the actual implementation also checks the DLV_PATH environment variable as a fallback. [evidence: packages/shared/src/interfaces/adapter-policy-go.ts — "resolveExecutablePath() (L92-106): Path resolution priority: provided path → `DLV_PATH` env var → default `dlv` command"] - `docs\architecture\dual-pattern-decision-guide.md`: The document describes AdapterPolicy methods as stateless, but the actual AdapterPolicy interface includes extensive state management methods (createInitialState, updateStateOnCommand, updateStateOnEvent, isInitialized, isConnected). [evidence: packages/shared/src/interfaces/adapter-policy.ts — "State management (L222-249): Methods for creating and updating adapter-specific state"] - `docs\architecture\dual-pattern-decision-guide.md`: The document's Summary section describes AdapterPolicy as 'Session management behaviors (lightweight, stateless)' but AdapterPolicy has significant responsibilities including command queueing, state management, handshake protocols, DAP client behavior configuration, and adapter spawn configuration - it is not merely lightweight. [evidence: packages/shared/src/interfaces/adapter-policy.ts — "AdapterPolicy (L45-322): Main interface with 20+ methods covering: Multi-session support, Stack frame filtering, Variable extraction, Adapter configuration, Handshake and initialization, Command queueing, State management, Connection status, Behavior configuration, Adapter spawning"] - `docs\architecture\dual-pattern-decision-guide.md`: The DON'T list for AdapterPolicy says 'Add complex state management' but AdapterPolicy implementations like JsDebugAdapterPolicy have complex command queueing systems with multiple state flags and strict initialization ordering. [evidence: packages/shared/src/interfaces/adapter-policy-js.ts — "requiresCommandQueueing(): Always returns true for JS adapter... shouldQueueCommand() (L446-492): Gates commands based on initialization state"] - `docs\logging-format-specification.md`: The document specifies the log file path as 'logs/debug-mcp-server.log', but in container mode the logger forces the path to '/app/logs/' instead. The specification doesn't mention this container-specific path override. [evidence: src\utils\logger.ts — "MCP_CONTAINER=true: Forces container-specific log path /app/logs/"] - `docs\logging-format-specification.md`: The document mentions file rotation under 'Performance Considerations' as something to 'implement' (future tense), but the logger already implements file rotation with specific parameters: 50MB per file, 3 rotated files maximum (150MB total). [evidence: src\utils\logger.ts — "File rotation: 50MB per file, 3 rotated files maximum (150MB total)"] - `docs\troubleshooting.md`: The document mentions container mode translating paths with '/workspace/' prefix, but the shadow docs show the container workspace root is configurable via MCP_WORKSPACE_ROOT environment variable and is not hardcoded to '/workspace/'. [evidence: src/utils/container-path-utils.ts — "Container mode requires `MCP_WORKSPACE_ROOT` environment variable (mount point)"] - `docs\troubleshooting.md`: The troubleshooting guide does not mention that in host mode, relative paths are explicitly rejected by SimpleFileChecker. The guide suggests using absolute paths as a 'best practice' but doesn't mention that relative paths will actually fail in host mode. [evidence: src/utils/simple-file-checker.ts — "Explicitly rejects relative paths in host mode (L45-57) to prevent downstream debug adapter failures"] - `examples\asciinema_demo\run_rich_demo.py`: L124-125: Commented-out code for stderr reading that could mislead AI agents about intended functionality - `examples\asciinema_demo\run_rich_demo.py`: L116-116: TODO comment about setting up stderr monitoring thread appears outdated given current simplified implementation - `examples\asciinema_demo\run_rich_demo.py`: L330-332: Commented-out code with type: ignore hints at complex non-blocking I/O logic that was abandoned - `packages\adapter-go\src\go-debug-adapter.ts`: L93-120: Multiple console.error statements wrapped in CI environment checks for debugging purposes - `packages\adapter-go\src\go-debug-adapter.ts`: L314-316: Comment about Delve returning 'unknown goroutine' when stopOnEntry is true may be outdated - `packages\adapter-javascript\src\javascript-debug-adapter.ts`: L36-36: Comment mentions casting 'until DebugLanguage includes JAVASCRIPT' but this appears to be a permanent workaround rather than temporary - `packages\adapter-javascript\src\javascript-debug-adapter.ts`: L542-548: Large block of commented-out attachSimplePort logic that could mislead agents about current behavior - `packages\adapter-javascript\src\javascript-debug-adapter.ts`: L438-446: Long comment about async limitations and deasync patterns that doesn't match the actual synchronous implementation approach - `packages\adapter-python\src\python-debug-adapter.ts`: L88-101: CI-specific console.error debug statements appear to be temporary debugging code that may no longer be needed in production - `packages\adapter-python\src\python-debug-adapter.ts`: L156-162: More CI-specific console.error debug statements that appear to be temporary debugging code - `packages\adapter-python\src\python-debug-adapter.ts`: L199-201: Additional CI-specific console.error debug statement that appears to be temporary debugging code - `packages\adapter-rust\src\utils\codelldb-resolver.ts`: L76-78: Comment about intentional code duplication may be misleading - the platform detection logic is duplicated between resolveCodeLLDBExecutable() and getCodeLLDBVersion(), but the justification about 'coupling without meaningful benefit' is questionable since a simple helper function would reduce maintenance burden - `packages\shared\src\interfaces\adapter-policy-js.ts`: L195-197: ESLint disable comment with type assertion workaround - indicates potential architectural issue - `packages\shared\src\interfaces\adapter-policy-js.ts`: L235-235: ESLint disable comment for 'any' type usage in event handler - `packages\shared\src\interfaces\adapter-policy-js.ts`: L629-629: ESLint disable comment for 'any' type in request arguments - `packages\shared\src\models\index.ts`: L12-12: Comment mentions adding 'console, cwd, env' but cwd and env are already present in GenericAttachConfig - `src\proxy\child-session-manager.ts`: L264-264: Parameter _parentConfig is declared but unused, with void statement to suppress warnings - `src\proxy\child-session-manager.ts`: L285-285: Parameter _parentConfig is declared but unused, with void statement to suppress warnings - `src\session\session-manager.ts`: L31-34: TODO comment describes implementation need for handleAutoContinue method to accept sessionId parameter, but the method currently just throws an error - `tests\core\unit\server\server-lifecycle.test.ts`: L56-62: Test description 'should handle server start errors' suggests error handling testing, but the implementation only tests successful start scenario - identical to the previous test - `tests\e2e\debugpy-connection.test.ts`: L257-264: Duplicate parseSdkToolResult function definition - identical to the one at lines 107-114 - `tests\integration\rust\rust-integration.test.ts`: L50-50: Comment suggests the test only verifies session creation, but the test also verifies session retrieval and language property - `tests\integration\rust\rust-integration.test.ts`: L73-74: Comment mentions test files 'aren't set up yet' but this appears to be a permanent condition rather than a temporary setup issue - `tests\manual\test_debugpy_launch.ts`: L9-9: Hardcoded Windows path comment suggests this needs manual updates for different environments, but provides no guidance on how to configure it properly - `tests\manual\test_python_debugger_instantiation.ts`: L2-2: SessionConfig and DebugLanguage imports are unused in this test file - `tests\test-utils\helpers\test-dependencies.ts`: L72-72: Comment refers to moving implementations to a different path but import is already using the referenced location - `tests\test-utils\mocks\child-process.ts`: L340-342: Comment claims to return a 'getter function' but actually returns an object with a 'get' method - `tests\validation\breakpoint-messages\test_syntax_error.py`: L5-8: Code after syntax error on line 4 is unreachable due to missing closing parenthesis in function definition