Skip to main content
This guide routes an agent to source-backed iCommerce contracts. It is documentation, not an installed skill or permission to enable writes. Release line 1.39.0 is the reviewed baseline; optional working-tree capabilities need separate feature and release checks.

​
Establish the working surface

  • Native embedding: application-owned accessors against SQLite or the configured backend.
  • Governed commands: operator-owned identity/policy with typed payload and durable receipt.
  • MCP: the actual discovered profile and its strict/read-only filters.
  • Rust HTTP: the deployed /api/v1 DTO, auth, tenant and retry-receipt contract.
  • Messaging gateway: channel/session endpoints, not an alias for commerce REST or MCP HTTP.
  • Sync/protocol/payment services: separate identity, credentials, state and settlement evidence.
Use CLI reference for entrypoints. Do not assume that a domain method, CLI action, REST operation and MCP tool share names or that model text can grant apply authority.

​
Operate with retained evidence

  1. Identify the intended store, principal, tenant, business record and actual installed features.
  2. Read current state; keep IDs and uncertainty. Do not interpret missing observations as success.
  3. Test the hypothesis through preview or native simulation.
  4. Load authority outside model arguments. Check required capabilities, approvals, versions, scope, budget and deadline through governed execution.
  5. Persist original key and exact request before dispatch. Read receipt status and retry rules.
  6. Verify resulting native records and external outcomes separately; retain original receipts.
A repeated run with a new key can be a new business action. HTTP pending receipts do not expire automatically and may represent committed effects; use operator reconciliation.

​
Important boundaries

Keep exact decimal strings, installed-version method signatures and original identity. Use bindings, recovery, and Sandbox execution as needed.
Last modified on October 20, 2026