15 modules that already know about each other. You stay in charge of every change.

Pick what your product needs. They already know about each other.

A starter kit hands you a fixed set to delete from, wired on day one and yours to maintain from day two. These install through the same validated operation an agent uses, resolve each other's prerequisites topologically, and carry versioned upgrade codemods — so a module can move forward under an app that is already live. That last part is the whole difference, and breadth is what makes it visible: nobody feels an upgrade path on a product with six moving parts.

And the combinations are tested, not assumed. 15 modules is 4,047 prerequisite-closed combinations; every one of them is installed in several valid orders and asserted byte-identical, so two people who added the same modules in a different sequence are running the same app. The catalog is capped at 16 for exactly that reason — breadth is bounded by what the gate can prove, not by ambition. The combination gate · the upgrade gate.

An agent proposes. You decide what becomes true.

Every entity, field, page and pricing tier carries its provenance — suggested, accepted, or manual — and generators ground only on accepted ones. So an agent can propose freely and nothing it proposed is in your app until you said so. That is a structural property, not a setting: there is no mode in which a proposal skips the queue.

localhost:3000/workbench

Three proposals waiting, one open decision, and every row in the spec panel tagged with where it came from. This is the whole surface — there is no second place a change can land from.

A single turborepo on the committed 2026 stack.

The stack is fixed on purpose. Swapping a piece takes a written decision record and a migration plan — never a fresh repo, which is the point: the whole product is a bet that settled decisions stay settled.

Add one entity. Grow a whole admin surface.

One spec-op is the seed — that is the whole authoring surface, and it is what an agent writes. Sprout builds the typed table from it at runtime and derives the entire CRUD surface from there: no per-entity code, no scaffolding to maintain, and no schema file to keep in sync.

{
  "op": "data.addEntity",
  "args": { "entity": {
    "id": "e-task", "name": "task",
    "fields": [
      { "name": "title", "type": "string", "required": true },
      { "name": "done", "type": "boolean", "required": true },
      { "name": "priority", "type": "enum", "required": true,
        "options": ["low", "medium", "high"] }
    ]
  } }
}
// validated, then appended to the op log with its author recorded

// constructed in memory by the runtime; the database is reconciled
// with CREATE TABLE / ADD COLUMN IF NOT EXISTS. Shown for shape only.

priorityEnum = pgEnum('priority', ['low', 'medium', 'high'])

task = pgTable('task', {
  id: uuid('id').primaryKey().defaultRandom(),

  title: withMeta(text('title'), {
    label: 'Title', required: true,
  }),

  done: withMeta(boolean('done'), { label: 'Done' })
    .default(false),

  priority: withMeta(priorityEnum('priority'), { label: 'Priority' }),
})

Always reach for the lowest rung that expresses the change.

Every change goes up an explicit ladder — cheaper rungs absorb more, and regeneration stays safe by construction. The weight is what the change cost you; the platform's job is to keep changes on the low rungs.

What that guarantee measures out to: across every benchmark and every one of the 56 changes on the long-lived project, 0 files the platform did not own were overwritten — and 6 files taken over by hand on that project (2 ejected, 4 filled slots) held their bytes exactly through every later change.

The invariants that make it safe: additive-only spec-ops + additive DDL · manual rows survive regeneration · generators ground only on accepted entities · a writer that checks the ownership manifest before every write, so it can never clobber — overwrite a file you had taken over. Every change ends with maxstack validate.

5 verbs you'll use. 24 in total when you want them.

You don't have to touch any of these — the agent drives the same vocabulary over MCP. They're here for when you'd rather type than talk. Every verb runs standalone from the npm install: dev serves the runtime that ships with the CLI, build vendors it into your project. The 5 marked everyday below are the ones worth knowing; the rest are situational, and the reference is generated from the command tree so it cannot drift from this count.

The north star is change-safety — and it's measured.

Time-to-Nth-safe-change: the effort and success rate of landing a change to an already-live app with the regeneration-safety suite still 100% green. This is the one number the whole platform exists to move.

The honest boundaries.

Every one of these is a real limit today, not a coming-soon. If one of them is your requirement, this is the wrong tool and you should know that from the page rather than from the install.

The alternatives you are actually weighing: the builders (v0, Lovable, Bolt) start in a browser tab and have no review model, so nothing stops a regeneration from landing on code you changed. The starter kits (Shipfast, Vercel’s SaaS Starter, T3) hand you a fixed set to delete from, wired on day one and yours to maintain from day two — no upgrade path. We published the module-by-module version of that comparison.

Read the framework, not just the pitch.

Everything you need — setup, the change ladder, the workbench, the metrics protocol, the deploy runbook. The reference pages are generated from the source they document, so they cannot drift.