#14 [Feature/Roadmap] Define the protocol profiles we actually support

[Anonymous]

Originally created by: SergeevDmitry

Context & Rationale

A merchant reading the README, docs/protocols.md, the runtime AdapterDescriptor and doctor gets four slightly different answers to "which versions of which protocol, with which payment combination, are supported". The MCP descriptor reports a negotiated spec revision while the docs name an SDK version. A2A, ACP and AP2 each implement a deliberate subset, and that subset is what we can stand behind, not the whole spec.

Proposed Changes

• Write one compatibility record per adapter and provider: spec revision, SDK/schema/fixture versions, supported features, known exclusions, tested combinations, and where the evidence lives.
• Classify explicitly: HTTP, MCP and A2A carry x402 (and later MPP); AP2 is authorization, not a rail; ACP checkout is a separate merchant-paid flow.
• Add a CI check that docs, descriptors, discovery output and doctor agree with the record.
• Write down the bar for promoting a profile from experimental to stable: conformance evidence, operational docs, crash and replay coverage.

Non-goals / Invariants Preserved

• "Stable" applies to the tested profile only. Full-spec A2A streaming, autonomous AP2 and additional ACP services are separate work.
• No public-network payment is needed to run the compatibility check.

Impact & Value

Done when "supports MCP / A2A / ACP / UCP / AP2" has one precise technical meaning: revision, implemented subset, tested payment and authorization combinations, and where the evidence lives. At that point README, descriptors, doctor, docs and tests cannot drift from it without CI noticing.

Open question

Where does the record live: a docs/support-matrix.md that CI parses, or a JSON file that generates the docs table?