DX finding. mount(app, ceremony?) accepts host seams ({ orderStore, catalog, completion, signingKey, … }), and the gate shares per-order verification state via app.locals.attestomcp. But getting-started only documents the storefront path — there's no recipe for "mount the gate on YOUR existing MCP server with YOUR own order / completion / store." A dev not using createStorefront() has to reverse-engineer the seam contract from client.ts / mount.ts.
Capability for discussion. A documented "bring your own host" recipe + a typed defineHost({ orderStore, catalog, completion, signingKey }) helper that publishes the seams correctly, so integrators aren't doing raw app.locals wiring. Pairs with the framework-adapter work (#dxA).
Why it matters: the storefront is one host; the product promise is "mount on any app." The seam contract should be a first-class, documented API, not an internal detail.
DX finding.
mount(app, ceremony?)accepts host seams ({ orderStore, catalog, completion, signingKey, … }), and the gate shares per-order verification state viaapp.locals.attestomcp. But getting-started only documents the storefront path — there's no recipe for "mount the gate on YOUR existing MCP server with YOUR own order / completion / store." A dev not usingcreateStorefront()has to reverse-engineer the seam contract fromclient.ts/mount.ts.Capability for discussion. A documented "bring your own host" recipe + a typed
defineHost({ orderStore, catalog, completion, signingKey })helper that publishes the seams correctly, so integrators aren't doing rawapp.localswiring. Pairs with the framework-adapter work (#dxA).Why it matters: the storefront is one host; the product promise is "mount on any app." The seam contract should be a first-class, documented API, not an internal detail.