Skip to main content
Build mode is the path that takes a user prompt all the way to a live preview URL. There is one while loop, one agent, and one flat message history — Claude Code style. Everything else orbits this.
Build Mode Overview

Request lifecycle

The dev server is started by the orchestrator before the agent ever runs. The system prompt asserts to the model that the dev server is already up — that promise is load-bearing for HMR timing, which is why bash short-circuits any npm run dev the model tries to issue.

Two project types

Project type is locked at session creation — it picks the sandbox template image, the system prompt variant, and which tools are registered.

Hard rules (load-bearing — don’t “simplify”)

  1. One while loop, one agent. The build loop is a single agent, not a swarm — parallel tool calls go through Promise.all. The one delegation that exists is bounded and read-only: spawn_subagent hands an investigation to up to four research agents that cannot write. See Subagents.
  2. Stream everything — tool-call start, file write chunks, thinking, status.
  3. ask_user stores a resolve and fires when the frontend POSTs /vibe/answer.
  4. Route to a larger-context model at 75 %, compact at 90 %. Compacting earlier thrashes memory; later trips provider context-overflow rejections.
  5. .mana/memory.md survives compaction — it lives on disk in the sandbox.
  6. 3-attempt cap per error in self-heal. Past that, the error surfaces.
  7. No placeholder text. Real content only.
  8. Templates come from GitHub via git clone --depth 1.
  9. Dev server is started by the orchestrator, not the agent. bash short-circuits npm run dev.
  10. toolCalls.clear() fires on finish_reason of "tool_calls" OR "stop" — some providers send tool calls with stop.
  11. Failover only activates for the default provider. Explicitly chosen models are not silently swapped on failure.

Where to look first when something breaks