> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.cessy.ai/development-process/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.cessy.ai/_mcp/server.

# Builder Path

> Follow the recommended development process for scoped Cessy app changes from discovery to published runtime verification.

Use this path for any non-trivial Cessy change. It works for human builders and for AI-assisted builders connected through Design MCP.

## 1. Inspect before editing

Start with the current app, not an assumption:

* open the app in the Builder UI
* or ask the connected Design MCP agent to call `get_app`, `get_domain_model`, `list_errors`, and relevant `get_reference` topics

Write down the exact commands, events, projections, policies, permissions, adapters, or pages that are in scope.

## 2. Model the business change

Name the business decision first. Then identify:

* the command that requests the decision
* the events that record the facts
* the decider state required to validate the command
* the projections required by users, agents, or integrations
* the policies or webhooks that should react after events
* the actors who may execute or read each part

If that map is unclear, do not start with frontend or API work.

## 3. Use a workspace

For design edits, create or use a workspace. Keep one coherent change per workspace. Validate the workspace before creating or promoting a changeset.

See [Workspaces And Changesets](/development-process/workspaces-and-changesets).

## 4. Publish intentionally

Before publishing, check:

* validation result
* permission impact
* generated OpenAPI impact
* runtime agent impact
* webhook, subscription, and adapter impact
* projection rebuild need

After publishing, run one command/projection smoke test against the target environment.

## 5. Capture the handoff

Every completed builder change should leave a short trail:

* app id and target environment
* workspace and changeset ids
* artifacts changed
* validation result
* smoke tests run
* known follow-up work

This is especially important when an AI builder made or reviewed the change.

> Follow the recommended development process for scoped Cessy app changes from discovery to published runtime verification.

## Docs

- [Workspaces And Changesets](https://docs.cessy.ai/development-process/workspaces-and-changesets.md): Use Cessy workspaces and changesets to isolate, validate, review, and promote app design changes.
- [Workspace Seeding](https://docs.cessy.ai/development-process/workspace-seeding.md): Prepare Design Workspaces with repeatable runtime data for previews, validation, and agent-driven testing.
- [Publish And Operate](https://docs.cessy.ai/development-process/publish-and-operate.md): Promote a validated Cessy model, verify generated contracts, and operate the published runtime safely.