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?
Context & Rationale
A merchant reading the README,
docs/protocols.md, the runtimeAdapterDescriptoranddoctorgets 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
doctoragree with the record.Non-goals / Invariants Preserved
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.mdthat CI parses, or a JSON file that generates the docs table?