Worldant turns a directory into a running world.

agent edits files
  -> worldant build
  -> validate migrations, artifacts, contracts, tests, and policies
  -> write .dist/run/<run_snapshot_id>
  -> record snapshot metadata in PgPaw
  -> worldant run serves latest valid snapshots

Execution never runs directly from the working tree. New calls use the newest valid snapshot. In-flight workflow runs stay pinned to the snapshot they started with.

Runtime loop

agent edits files
  -> build validates the world
  -> daemon activates latest valid snapshot
  -> clients call generated package / MCP / HTTP
  -> commands compute, mutations commit, workflows resume
  -> PgPaw emits authorized live updates
  -> UI, agents, and services react

Database truth

if it did not commit to PgPaw, it did not happen
if it committed to PgPaw, subscribers can observe it

Postgres row-level policy is the authorization boundary. Worldant can validate capability declarations, but database policy remains the final guard.

Execution

Worldant plans bounded JavaScript isolate slots using deno_core::JsRuntime. Commands, mutations, workflow replays, and steps load from .dist on demand. Idle entries and isolate slots are dropped to keep per-user infrastructure small.

Durable workflow replay uses a deterministic node:vm-style context inside an isolate slot. Steps execute outside that deterministic context and persist their results before workflow replay continues.

Build safety

The working tree may be broken while an agent edits. Runtime traffic does not use it. A build writes a new .dist/run/<run_snapshot_id> only after validation passes. The daemon chooses the latest valid snapshot per entry.

That gives Worldant the same operational property as deploys without requiring a separate external deployment platform: edit, build, activate, and keep the old snapshot serving until the new one is valid.