When not to use Meguro

Scope and proof boundaries

You need proof of live performance. Receipts are rehearsal evidence from a simulated store — not forecasts, certifications, or evidence of market demand. Meguro says this in-band because it's true.

Your critical path lives outside the modeled subset. Meguro models a subset of the Shopify Admin API and refuses the rest with a teaching error rather than faking behavior. If the calls your app depends on aren't in the modeled subset — the refusal enumerates it, and the compatibility table lists it — Meguro cannot exercise them, and won't pretend to.

You're testing storefront pages, themes, or checkout UI. A practice store renders no pages. It serves two agent surfaces: the Admin-shaped API, and a shopper endpoint that models Storefront reads, cart, and a checkout that ends at the buyer handoff. Payment placement is out.

You're load-testing. Meguro models Shopify's request cost bucket, so throttling and backoff show up on the receipt. It measures no latency or capacity and benchmarks nothing.

Your agent only reads. If it reads a catalog once and writes nothing, a fixture file is cheaper. An agent that writes gets a full receipt without moving Store time. Time matters only for modeled consequences.

You want someone to run your agent for you. Meguro never executes your agent; it provides the store and the record. Bring your own agent — that's the design, not a gap.