# Code-to-Cart architecture

## Boundary

GovCodex treats ACP as a transport and seller-transaction boundary, not as a
replacement domain model:

```text
parcel + code evidence
  → selected canonical product
  → project_procurement_items / Buy list
  → ACP discovery + version negotiation
  → seller-scoped REST or MCP checkout
  → exact-total human approval
  → sandbox order
  → budget + construction tasks + project action graph
```

The canonical `commerce_offers` ingestion, allowlisting and commission-blind
ranking remain unchanged. ACP seller metadata and stable item identifiers live
in separate ACP tables and mapping modules. A database trigger prevents the
synthetic seller catalog from entering production offers.

## Buyer boundary

The buyer side owns seller discovery, version negotiation, idempotency,
checkout persistence, approval binding and mapping into project state. It does
not decide authoritative availability, fulfillment, tax or transaction totals.

## Seller boundary

The in-repo Aurora Sauna Works seller is a deterministic implementation of the
pinned checkout surface. Its HTTP route, in-process REST binding and MCP binding
all dispatch to the same engine. The public showcase creates a new store for
each request and performs no network call.

## Project boundary

Orders flow one way into existing durable systems: case events, procurement
items, budget lines, construction tasks and action-graph facts. There is no
second workflow engine for commerce.

The electrician appointment remains a separate, namespaced experiment. Stable
ACP `2026-04-17` cannot represent a service booking, availability window, slot
hold or deposit. Mixing that extension into the stable seller would invalidate
the conformance claim, so it has a separate engine and route.