Builder Path

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.

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.