Build Command

Build Command drafts blueprint configuration from a plain-language request: you say what you want, Build Command drafts the plan, a person approves it, and the existing blueprint apply path executes it.

Flow, with every step on the existing blueprint boundary:

1. Request. A person types what they want. Build Command reads a names-only catalog of what the org already has (tags, forms and their field keys, pipelines and stages, lifecycles, templates with their approval state, sequences, routines). No ids, records, messages, members or secrets.
2. Plan. The model returns a goodqa.blueprint/1 file built only from registered kinds, plus a list of asks it cannot build yet with the reason. The file goes through the normal blueprint plan: field-level diff, conflicts, ID remap, reference checks.
3. Approve. A signed-in person approves. The approval is bound to the plan hash. An edit creates a new revision with a new hash and clears approval; cancel closes the draft.
4. Apply. The existing per-item atomic, audited blueprint apply runs with the conflict policy forced to skip. No deletes. A second apply replays the receipts and creates nothing.

What it can build

Every kind is configuration. Each one stops short of acting:

Kind	Written as
CRM tags, flags, fields, segments, pipelines	Configuration
CRM lifecycles and eligibility rules	Configuration (rules only mark eligibility; nothing auto-enrols)
Chat channels, meeting types	Channel; meeting type inactive
Forms	Draft, never published
Form-to-CRM mappings (form.crm_mapping@1)	Switched off. Names a form, tags, flags, pipeline stage, lifecycle; resolved to ids in the org
Outreach templates	Draft. A person approves them; channels start in dry run
Outreach sequences (outreach.sequence@1)	Inert. Steps name templates a person has already approved; enrols nobody, creates no permit
Routines	Switched off, no project or people bound. Check-in, proof and discussion steps with native overdue escalation

Routines are the one way a plan can remind a person ("call within 2 days"), repeat work weekly, or escalate a missed check-in. They import disabled; a person binds a project and people, then switches them on. The follow-up graph adopts the run ticket once a routine runs.

A sequence that uses templates created in the same plan is shown as needs attention and is skipped on apply: a model can never approve a template. After a person approves the templates, ask Build Command for the sequence again.

What it cannot build yet, and why

These are listed under Can't build yet with the reason. They are never faked.

• Starting a sequence automatically when a form is submitted. Enrolling a contact needs a recorded basis and a send permit approved by a person.
• Sending anything. Send permits stay mandatory; channels start in dry run.
• Webhooks. A webhook delivers org data to an outside address and has a signing secret that is shown once; a person registers it in settings.
• Recurring test missions, tickets and standalone follow-up items. These are work records tied to a project and a person, not configuration. A routine is the supported recurring block.
• Permissions, members, secrets, connections, deletes.

Safety properties (each pinned by a test)

• Approval is a signed-in person; an MCP agent has no approval tool. To let an org key apply, a person names apiKeyId on approve; the blueprint approval expires after 15 minutes and re-checks the live key and the person.
• The generic blueprint_apply route and MCP tool refuse to apply a Build Command plan unless the draft is approved for that exact hash and caller.
• A non-admin cannot draft, approve, apply, edit or cancel.
• Draft cost is the provider-reported cost saved with the draft. A missing cost is null, never zero.

Open /o/<orgSlug>/org-builder (sidebar label Build Command). REST paths are under /v1/orgs/<orgId>/org-builder: draft, edit, approve, cancel, apply, capability, drafts/<draftId>. MCP tools: org_builder_draft, org_builder_get, org_builder_edit, org_builder_apply, dispatching through the same guards.