[FEATURE] Ruby adapter

[censoredp]

🚀 Feature Request

Is your feature request related to a problem?

mcp-debugger supports Python, JavaScript, Go, Java, .NET, and Rust, but not Ruby. Ruby developers debugging with AI agents (Claude Code, Cursor, etc.) currently have no way to drive rdbg through MCP.

Describe the solution you'd like

A first-class adapter-ruby package using Ruby's stdlib debug gem (rdbg), wired into the existing adapter registry and policy pattern — matching the shape of adapter-go / adapter-python.

Describe alternatives you've considered

• byebug / pry-byebug: no DAP support.
• ruby-debug-ide: works, but unmaintained and DAP coverage is worse than debug gem's.
• External bridges (e.g. VS Code's Ruby extension): tied to the VS Code IPC protocol, not reusable in MCP.

💡 Use Case

Debugging a Ruby/Rails test or service under an AI agent, e.g.:

rdbg --open --host=127.0.0.1 --port=12345 bin/rspec_debug spec/some_spec.rb

Then from the agent:

create_debug_session(language: "ruby")
attach_to_process(sessionId, host: "127.0.0.1", port: 12345)
set_breakpoint(...)
continue_execution(...)
evaluate_expression(...)

🔧 Implementation Ideas

• New package packages/adapter-ruby mirroring the adapter-go layout (src/, package.json, tsconfig.json).
• New packages/shared/src/interfaces/adapter-policy-ruby.ts with Ruby-specific policy (command resolution for rdbg, attach vs launch semantics, DAP quirks).
• Minor additions in shared interfaces + adapters/adapter-loader.ts / container/dependencies.ts to register the new adapter. Ideally split into a separate "hooks for Ruby adapter" PR if the core changes are non-trivial.
• One Ruby-specific gotcha to document: pry-byebug loaded in a project hijacks TracePoint and silently breaks rdbg's line-based breakpoints. Recommended workaround is binding.break if defined?(DEBUGGER__) in source, and a thin bundler+rspec runner for script mode. Worth a paragraph in the adapter README.
• CI: add a Ruby toolchain (ruby/setup-ruby@v1) to the workflow matrix; rdbg ships with Ruby ≥ 3.1 stdlib debug gem.

📊 Impact

• Who would benefit: Ruby / Rails developers using AI coding agents.
• Priority: Medium
• Complexity: Moderate — adapter itself is straightforward; the cross-cutting shared-interface changes and CI work are the bulk.

🤝 Are you willing to contribute?

• Yes, I'd like to implement this feature (have a working prototype locally against rdbg)
• Yes, I'd like to help test it
• No, but I'm available for questions

📝 Additional Context

Happy to open a draft PR once there's interest. Would appreciate guidance on whether the shared-interface changes should land as a prep PR first, or bundled with the adapter.

[debugmcpdev]

Thanks @censoredp — please open the PR. Bundled, one PR is the right shape; that's how Go (#11), Java (#12), .NET (#24), and Rust all shipped. Don't worry about polish — open it when something works and we'll iterate.

Three guardrails worth flagging up front so they don't bite you in review:

1. DAP-native only. Adapter has to speak Debug Adapter Protocol directly (or via a thin bridge we control). rdbg's native DAP qualifies.
2. Respect upstream licensing. Shelling out to a permissively-licensed debugger from the user's environment is the model (debugpy, Delve, CodeLLDB). What we can't take is a debugger bundled/redistributed in violation of its upstream license — we've turned a PR away over this before.
3. Ruby-specific logic stays in the adapter and policy. You'll touch a handful of src/ files for unavoidable registration — adapters/adapter-loader.ts, container/dependencies.ts, the selectAdapterPolicy chain in proxy/dap-proxy-worker.ts, and the language-to-policy switches in session/session-manager-data.ts and session/session-store.ts. That's expected; every adapter touches those. What we'd push back on is new language-specific branches in core beyond those registration points — every Ruby quirk should land in packages/adapter-ruby or adapter-policy-ruby.ts. There are a few such branches in core today (Java, js-debug, Rust); we're trying not to grow that list. If you find yourself wanting to add if (policy.name === 'ruby') somewhere in src/, flag it in the PR description for discussion.

The end-to-end checklist (vitest aliases, hardcoded adapter counts in tests, root package.json optionalDependencies, etc.) is in CLAUDE.md → "Adding New Language Adapters".

Looking forward to it.