A profile is not a badge
Universal Commerce Protocol discovery starts from a business profile. The profile declares supported protocol versions, services, capabilities and endpoints so a platform can negotiate what it can actually do. A client is expected to follow those declarations, not interpret them as marketing.
That makes the profile part of the runtime contract. Advertising catalog.search and catalog.lookup over a REST endpoint means a compatible client should be able to invoke those UCP operations there. If it cannot, the profile is not partially useful. It is a broken route map.
What the WordPress plugin used to declare
Before 1.0.137, KaliCart Bridge published /.well-known/ucp, a JSON mirror and a REST route. The profile named a dev.ucp.shopping service and pointed at the plugin’s catalog API. That API is a bounded, read-only ARC catalog surface. It was never the UCP REST binding described by the profile.
We reproduced the failure directly: a UCP-shaped request to the advertised catalog path returned WordPress’s rest_no_route. Discovery succeeded, negotiation appeared possible, and the first real operation failed. The declaration was the defect.
Hosting made the local profile unreliable too
There was a second, independent problem. Several shared-hosting configurations do not route an extensionless path under /.well-known/ to WordPress. Seven of eleven active stores measured on 23 September returned a hosting-level 404 for the canonical profile path. Static fallbacks were not a general answer: on the measured hosting group they inherited no-store cache headers, which the profile contract forbids.
Even where the profile could be fetched, it still pointed to the wrong protocol binding. Fixing only the path would have made a false promise easier to discover.
What changed in 1.0.137
- The plugin no longer publishes
/.well-known/ucp,ucp.jsonor the old UCP REST route. - Its native discovery document continues to describe the ARC catalog endpoints it really implements.
- Stores that explicitly join the Federated Catalog are exposed by KaliCart Global through a single UCP Catalog implementation.
- Product results retain seller identity and lead back to the merchant’s WooCommerce checkout.
The production release fixture now says exactly that: its merchant-domain profile returns 404, its Bridge discovery endpoint returns the native JSON contract, and KaliCart Global serves the UCP transport.
Why the Global is the right UCP layer
A cross-store catalog and a per-store plugin have different jobs. The Bridge translates one WooCommerce store into stable product facts. KaliCart Global indexes stores that opted in, performs cross-merchant discovery and speaks the shared protocol at one maintained endpoint.
Keeping UCP in one place avoids eleven slightly different protocol implementations on eleven hosting stacks. It also preserves the authority boundary: the index helps an agent find candidates, while the merchant remains the seller and owns the checkout.
Removing UCP made the system more interoperable
Interoperability is not the number of standards named in a discovery file. It is the number of declared operations another implementation can successfully execute. Removing an unimplemented profile reduced the surface area and made every remaining declaration more trustworthy.
The practical rule is simple: publish a capability only at the layer that implements and tests it. A profile that says less and works is more useful than a profile that says more and fails.