@miniapp-studio/renderer

The standalone runtime. It validates a canonical document at its boundary and renders it, loading neither Craft nor any builder code.

import { StudioRenderer } from "@miniapp-studio/renderer";

<StudioRenderer
  document={document}
  registry={registry}
  dataSources={dataSources}
  eventHandlers={eventHandlers}
  url={window.location.href}
/>;

Its only runtime dependencies are core and React. Validation, known-node styling, unknown-policy traversal, async scope ownership, the theme scope, token resolution, event dispatch, and the shimmer boundary are all isolated behind the small StudioRenderer composition boundary.

What the renderer guarantees

• It never partially renders a structurally invalid document. Validation runs again here, at the runtime boundary, even if a builder already ran it.
• Zod is part of the runtime cost by design (~85 kB). It is what makes the boundary check real; it is not a leak.
• No authoring code is reachable from it. Adding @craftjs/*, @miniapp-studio/builder, antd, @ant-design/*, or @rc-component/* to this package — directly or through a module it can reach — breaks the package's reason to exist.

That last guarantee is held by review rather than by a test: the suite that bundled the routes and weighed them against a committed baseline was removed for its cost, as described in documents/testing-rules.md. The reasoning behind keeping the editor out of a runtime route is in Authoring configuration versus runtime configuration.

The contracts it implements

The document format, component/data-source/event-handler definitions, theme tokens, and binding resolution are all core's, and are documented there:

• packages/core/README.md — the canonical document and the "define it once" APIs.
• packages/core/documents/dynamic-data-contract.md — loading, error, and loop status transitions, and error ordering.