The canonical models every Fayz product and the integration service agree on: a delivery order, its status machine, its commands, and the sink port a product fills. No React, no Supabase, no provider shapes.
The canonical models that every Fayz product and the integration service
agree on. Seam 2 of ADR 0003 (control-sdk-backend/docs/0003-where-logic-lives.md):
these are the contract, versioned here, consumed by the service, by a plugin's
sink, and later by the screens as the bodies of the data API.
What is here, and what is deliberately not:
CanonicalOrder v1: one delivery order, whatever marketplace it came from.
Money is in minor units (centavos) as integers. No provider's shape leaks in:
a normaliser in the service turns an iFood or OpenDelivery payload into this.
OrderStatus and nextStatus: the status machine, monotonic, cancellation
final.
OrderCommand, availableCommands, commandObserved: what a kitchen may do
to an order in a given status, and how to tell a command landed.
OrderSink and Binding: the port a product fills to receive orders. The
service calls it; @fayz-ai/plugin-orders/server and V1's adapter implement
it with one SQL function each.
No React, no Supabase, no runtime dependency beyond zod.
The canonical models every Fayz product and the integration service agree on: a delivery order, its status machine, its commands, and the sink port a product fills. No React, no Supabase, no provider shapes.