Developers

The registry holds 213 atom packages, each a directory with a single atom.json describing what it is, what it takes and what it returns. Seventy-six draw interface, sixty-two are tools, twenty-seven are compute steps, sixteen are runtime profiles, twelve are skills, eleven are providers, eight are workflows. The Sim searches that registry to work out what it is able to do at all.

flow.json declares the graph and the rules around it: where intent may come from, which tools and skills are allowed, which paths may be read or written, how many tool calls a single run may make, which engine executes it, and how it appears in the catalog: display name, category, launch surface, slash command. Change the manifest and you change the flow's powers. There is nowhere else to hide them.

Every flow is addressable as a generated tool, so the Sim can call it in the middle of another job exactly the way it calls a primitive. That is what makes this compound rather than a folder of scripts: today's flow is tomorrow's single step.

Seventy-six interface components ship as atoms: tables, charts, forms, dropzones, media timelines, code editors, comparison sliders. A flow can render a surface instead of returning a wall of text. A flow can take the chat, an inline slot inside it, a sidecar panel beside it, or a window of its own.

A provider is a folder declaring an endpoint, its authentication, the shape of the request and the shape of the response. Adding one is a manifest plus the smallest adapter the difference genuinely requires. No new client class per vendor, and no vendor names leaking into what the user reads.

Observe, atomize, plan, close, run, commit, project, learn. Many surfaces enter at the top and many views project from the bottom, but everything narrows through typed runtime work over durable state. Close is the admission gate in the middle. That is the point where a plan either becomes a run or does not.