#17 [Feature/Roadmap] UCP checkout adapter

[Anonymous]

Originally created by: SergeevDmitry

Depends on: the protocol-profiles issue and the ACP ambiguous-retry bug.

Context & Rationale

UCP is listed as planned in the README and docs/protocols.md, and there is nothing under src/protocols for it. Checkout mappings, discovery routes and a shared backend executor already exist from the ACP work, so a UCP adapter should be mostly translation, plus the parts of the spec ACP does not have: version negotiation and payment handlers.

Proposed Changes

• Implement one pinned merchant-checkout profile from the UCP spec, REST/HTTP first if the chosen revision supports it.
• Map the profile's required operations to merchant resources; keep UCP wire types inside the adapter.
• Route side-effecting operations through the shared pipeline using the merchant idempotency contract from the ACP ambiguous-retry bug.
• Add config, mount-conflict checks, readiness, doctor, capability advertisement, and explicit rejection of unsupported versions.
• Validate with a runnable merchant fixture and the UCP conformance tooling or an official client; document which conformance categories we skip.

Non-goals / Invariants Preserved

• Disabled by default; the merchant owns checkout state and payment.
• Identity linking, order webhooks and arbitrary extensions are later work.
• Passing ACP or AP2 tests says nothing about UCP; x402 payment-handler and AP2 mappings need their own design.

Impact & Value

Done when the same merchant backend serves UCP buyers with no UCP-specific business logic: a UCP request becomes a canonical merchant operation, passes through the shared transaction, authorization, payment, idempotency and receipt machinery, and returns in UCP form.

Open questions

• Which UCP revision is stable enough to pin? I have not checked whether the spec has cut a versioned release.
• Is the payment-handler model close enough to ACP's merchant-paid flow to share adapter internals, or is it structurally different?