First product: a reviewed supplier update
ARCHIVE
Archived research / exploratory draft. Not the current implementation contract. Read REST 1.0 and the current concept.
Recommended MVP; not implemented. This refines the earlier “read stock, then change one price” engineering sequence into a commercial workflow. It does not claim founder approval of the new scope.
The first paid product should help an owner apply a supplier price update to existing OpenCart products and account for every row. A true stock answer is the connection proof; a recurring completed job is the value proof.
A deliberately small first scope
Support one explicitly selected OpenCart release family, one store, one base currency and existing products with stable identifiers. Propose a default job limit of 50 changed products during the pilot; this is a safety/scoping hypothesis, adjustable after measurement.
The file must identify products and proposed selling prices, or provide supplier costs plus an owner-approved pricing formula. Do not treat a cost column as a retail price. Require currency, tax basis, rounding and the treatment of promotions to be explicit. If reliable cost data is absent, do not claim to enforce a margin floor.
The first release should read product/stock data and limited order status, prepare a price job, collect approval, apply supported changes and verify them. No product creation, quantity writes, refunds, order-status changes, campaign launch or new supplier purchasing in this scope.
Illustrative owner journey
This is an example, not a live store or successful run.
The owner uploads a file for 40 products and asks to prepare next week's prices. The agent identifies 34 exact matches, two missing identifiers, one duplicate and three ambiguous rows. It explains the matching basis and asks the owner to resolve or exclude the six exceptions. No fuzzy match is silently written.
The owner sees a table with product links, current and proposed amounts, currency/tax interpretation, affected customer group, and any existing promotion. Unchanged rows are not presented as savings or completed writes. The owner approves the exact remaining list; editing the list creates a new approval version.
A receipt might show 31 applied, two skipped after concurrent changes, and one pending verification. The job is partially complete, not successful. The owner can inspect the evidence and resolve the remaining work without repeating completed writes.
The four surfaces
| Surface | What the merchant needs |
|---|---|
| Today | Work awaiting review, blocked jobs, meaningful findings, and connection freshness |
| Conversation | Intent, clarification and explanations tied to actual store data |
| Review | Before/after table, exclusions, estimated scope, approval and rejection |
| History | Who authorized what, applied values, verification and possible compensation |
The owner should not need to configure an MCP server or select a model. An agency may handle connector installation, but the merchant still owns the permission decision.
Definition of a complete MVP job
The job must be tied to one shop and actor; every input row must have a disposition. Validation and durable audit recording must exist before the first write. Apply only the approved version, detect intervening changes, and read back authoritative values. A network timeout is an uncertain outcome to reconcile, not permission to repeat the write blindly.
Show an honest recovery route. If an extension changes pricing semantics, the connector should refuse that operation until supported. If the connection is revoked, queued work must stop. If a refund or shipped order is requested, explain that the current product cannot perform it.
See authority and recovery, implementation, and release gates.