Product
Store engine
Generates and regenerates the storefront, with a stated reason for every section order.
What the surface does
The store engine generates a complete storefront for the product you claimed — home, product page, pricing, about, contact and the supporting pages — and can regenerate it or reorder its sections on request. It publishes a preview, records the store truths it asserted, and reports the result of a domain search.
Section order with a stated reason
A generated page is a sequence of sections, and the sequence is a claim about what your buyer needs first. The engine produces both the order and an order rationale: one entry per section saying why it sits where it does. A section that cannot cite the evidence row justifying its position does not ship — that is a build gate, not a guideline.
Evidence legs map to sections by a single named table, so the proposal and the applier cannot disagree about what a leg means. An urgency row leads to a “why now” section, a scarcity row to availability, price evidence to the comparison block, customer questions to the FAQ.
Intents, not pixels
Edits are stated as intent in your own words. The engine proposes an execution, cites the dated row that justifies it, names the alternative it rejected and why, and marks whether the change can be put back. Nothing is applied until you accept: the proposal carries an empty applied-at field by construction.
- An instruction containing a pixel value, a spacing unit or a hex colour is refused. A measurement cannot be justified by an evidence row, and that justification is the whole test. The refusal says: tell us what you want it to do, and we will choose the execution and show you why.
- An instruction no dated row supports is refused by name — “we would be guessing at your buyer” — rather than executed on the engine’s taste.
- Reversibility is a real property, not a constant. Section order, dashboard layout, support tone and ad creative can be reverted, because applying one records the previous state. Anything that spends money or reaches the outside world is not reversible and says so before it happens.
When you override the engine’s lead section, both orders are kept: yours is applied and the engine’s own order is retained beside it, along with the rationale row it disagreed with.
What an operator sees
The store truths — what the storefront currently asserts about the product and the price — a live preview, the section list with each section’s reason and a control to lead with a different one, and the domain search result. Counts are reported from the built manifest, so what the panel says was ordered is what the served store contains.
Honest limits
- Generated stores run against a payments sandbox. Checkout refuses with a stated reason and no card is charged. Live payments are held behind two independent switches and an unresolved pricing-baseline decision.
- A domain is recommended after checking real availability. Buying it is an outward, irreversible act and executes only with you present.
- A store never publishes an address it does not hold, and never renders an unpublished store as live.
- The customer-facing copy never states a shipping cost, customs charge, duty or delivery caveat. That constraint is enforced by scanning the generated output, not by intention.
Once the store exists, demand gets tested: see growth. The endpoints behind this surface are documented in the API reference.