Start a Build

Build is the boundary between definition and implementation. Chat, the Spec, and the Graph define what should be built. Build is the moment Castaly starts turning that definition into working code.

Pressing Build does not immediately change code. Castaly checks the Spec first, prepares a Build Plan, and waits for you to accept that plan before implementation begins.

Before you press Build

Use Build when the Project definition is ready to become implementation.

📄The Spec reflects your intent

The requirements, rules, and flows are clear enough for Castaly to build from.

🧭The Graph structure looks right

The pages, feature groups, and features match what you expect.

🔎Recent changes make sense

The latest changes Castaly made are the ones you intended.

✅Open questions are resolved

Castaly has the product decisions it needs to plan the Build.

If something looks wrong, continue in Chat before pressing Build. It is cheaper to fix the definition than to rebuild the implementation.

What happens when you press Build

1. 1

   Castaly checks the Spec for conflicts

   Castaly checks the current Spec for contradictions before writing code. If conflicts exist, the Project enters Build blocked and Castaly shows them in Chat. See Resolve Spec Conflicts for the full flow.

2. 2

   Castaly generates a Build Plan

   With a clean Spec, Castaly freezes a Spec snapshot and proposes a Build Plan in Chat: what it will implement, grouped and ordered.

3. 3

   You accept or keep editing

   Choose Accept to start execution, or Keep editing to return to the Spec and Graph before code changes.

4. 4

   Castaly implements, tests, and deploys

   After you accept, Castaly writes code, runs checks, and deploys a Preview. The Graph nodes move through build states while Chat reports light progress.

5. 5

   Preview becomes ready

   When deployment succeeds, the Project reaches Preview ready and you can test the running result in the Preview tab.

Build starts only after you accept

The Build button starts planning, not execution. Code changes only begin after you accept the Build Plan.

• Accept starts implementation, testing, and Preview deployment.
• Keep editing drops the current plan and returns you to refinement.
• No code changes before acceptance. You can still decide that the Spec needs more work.

This gives you one last review point between the Project definition and generated code.

Status you may see

The workspace header and Graph summary use the same product wording, so you always know where a Build stands:

• Build ready — the Spec and Graph are ready to build.
• Plan ready — a Build Plan is waiting for your Accept.
• Build blocked — Spec conflicts need to be resolved before planning can continue.
• Building / Testing / Deploying preview — the build is running.
• Preview ready — the preview is live.
• Build failed — the build, tests, or deploy failed.

If Build is blocked

Build blocked means the Spec contradicts itself. Castaly lists the conflicts in Chat with suggested options and source references. Resolve them in conversation, then press Build again.

Blocking happens before code runs whenever possible, so nothing half-built is left behind. See Resolve Spec Conflicts.

If Build fails

If implementation, tests, or deployment fail, the status becomes Build failed. You do not restart the whole Project.

• Retry runs the failed work again from where it broke.
• Continue Build picks up from the last completed point when available.

For the full recovery map, see Resolve Blockers.

A missing required runtime secret or API key does not block Build or Preview. It may affect feature behavior in Preview, and it can block Publish until you add the secret in Project Settings.

Review the Graph and recent changes before pressing Build. The more accurate the definition is, the more likely the right work lands in one Build.

Next: Preview Your Project explains how to test the running result after deployment.