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?
Context & Rationale
UCP is listed as planned in the README and
docs/protocols.md, and there is nothing undersrc/protocolsfor 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
doctor, capability advertisement, and explicit rejection of unsupported versions.Non-goals / Invariants Preserved
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