Distribution and coverage
Use SDK installation. Do not suppress a native loader/version
failure by falling back to a different package or source build without checking compatibility.
Inspect runtime
isSupported() for domains that provide it, and kernelFeatures() before
relying on optional native safety fields. Type declarations alone cannot prove an older
binary honors a field.
Native contracts differ from REST and MCP
Node accessors use camelCase; kernel envelopes pass snake_case Serde wire shapes, exact amount/quantity strings, UUIDs and RFC3339 timestamps. HTTP uses its DTOs; MCP tools carry their own schemas. List pagination and nullable fields also vary by method. The Node binding exposesCommerce.open() for asynchronous opening/migrations and close()
for lifecycle control. The constructor remains synchronous. Call close() after in-flight
work completes; later operations fail instead of using a released engine.
Money precision
Use exact methods/fields in the installed binding:
Compatibility numeric fields remain. Do not add, round or convert settlement values through
binary floating point. Exact aliases are not a statement that every legacy field changed
type. Check finance-domain declarations for their own exact string fields.
Check the entire workflow
For returns, receipt, disposition and completion are distinct operations. Verify the actual item-disposition API before choosing a binding for completion; do not assume a status helper performs it. For inventory, 1.39’sfulfillOrderStock() is a distinct full-shipment posting.
For payments, a native record is separate from external settlement and provider retry identity.
The reviewed working tree adds invoice/order payment retry handling beyond the committed
release. Do not assume those in-progress signatures exist in the published 1.39.0 binary.
Use actual feature checks, declarations and release evidence before enabling them.
See governed commands,
stock fulfillment, and
returns.