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, themes, or checkout UX. A practice store is commerce state behind an Admin-shaped API, not a rendered storefront.

You're load-testing. The throttle model exists to exercise your agent's backoff discipline, not to benchmark a platform.

Your agent never touches commerce state. If it reads a static catalog once, a fixture file is cheaper.

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.