Context

The Ruby SDK already has parser, client, server, Rack middleware, and Tempo/Stripe example coverage. As the MPP ecosystem moves toward cross-language conformance, it would be useful to track a small Ruby adapter path that can participate in the same kind of interop matrix being built across TypeScript, Rust, Python, Go, and other SDKs.

Proposed scope

Keep this incremental and reviewable:

1. Document the minimal process-adapter contract expected from a Ruby client/server adapter.
2. Add a Ruby client adapter that can pay an existing reference server.
3. Add a Ruby server adapter once the client path is stable.
4. Keep any CI matrix opt-in until the adapter is stable enough not to make unrelated PRs noisy.

Why this helps

Ruby is likely to appear in merchant/backend integrations, especially Rack, Rails, and Sinatra-style payment endpoints. A small adapter track would help catch drift in:

• WWW-Authenticate challenge parsing
• Authorization: Payment construction
• Payment-Receipt metadata shape
• cache/authorization behavior around paid responses
• Stripe/Tempo method-specific receipt semantics

Small first step

I can help with a first docs-only PR that describes the adapter contract and maps the current Ruby client/server primitives to that contract. If maintainers are aligned, follow-up PRs can add the client and server adapters separately.