These contracts are proposals or architecture-level boundaries unless independently verified.
| Caller / producer | Owner / recipient | Interface intent |
|---|---|---|
| Mini App or Bot | Commerce | Customer browsing and purchase admission |
| Dashboard Web | Operator | Authenticated control-plane routes |
| Commerce | Purchase Executor | Durable versioned purchase command |
| Purchase Executor | Wallet | Exact-command atomic hold and ledger link |
| Purchase Executor | Provider API adapter | Scoped revalidation, order submission, status |
| Catalog Aggregator | Provider API adapter | Read-only products and metadata |
| Provider Reconciler | Provider Host Manager | Restricted node-local lifecycle operations |
| Provider Reconciler | Provider status source | Status evidence for existing orders |
| Payment Adapter | Inbound Payments | Signed, normalized provider event |
| Inbound Payments | Wallet | Verified, one-time financial credit |
| Migrate | YSQL | Additive schema changes |
| Catalog Aggregator | Redis | Rebuildable catalog cache |
| Service identities | Secrets Provisioner | Scoped secret delivery |
| Ingress callers | Proxy | Route and mTLS policy |
Contract invariants
- Validate caller identity, action, recipient and interface version at each owner.
- HTTP success is not proof of a distributed atomic transaction.
- Amounts use exact decimal representations; never floating-point payment arithmetic.
- Customer, operator, catalog and host-lifecycle identities do not inherit Executor purchase authority.
- Distinguish definitive rejection, safe pre-effect retry and unknown external outcomes.
See the service directory for owner-specific interfaces and limitations.