Design — Concepts

Design is a thin orchestrator over the rest of the Destesi suite. Understanding the five moving parts makes the whole product predictable.

Project

A project ties together a Git repository, a database branch, and a sandbox. There are three ways the repository comes about:

• Imported — you point Design at a repo you already have.
• Created — Design creates a fresh repo in your GitHub to grow into.
• Internal — you haven’t connected GitHub, so Design creates the repo for you and manages it with its own credential.

In all three cases the repo is the source of truth from that moment on: your app is real code in real version control from the first commit, not an export you have to trust later. A project is workspace-scoped — it is never visible outside the workspace it was created in.

The workspace: three tabs

Working on a project means moving between three views of the same thing:

• Preview — your app running live, hot-reloading as the agent edits it.
• Code — the real file tree and file contents, read straight from the running sandbox. What you read here is what is running.
• History — every turn the agent committed, and the ability to restore the project to any of them.

History is the safety net that makes ambitious requests reasonable. Each successful turn is a commit, so the history is a list of states your app has genuinely been in; if a turn takes it somewhere you don’t want, you restore the previous point instead of trying to talk the agent back out of it.

Your build feed — the conversation with the agent — is stored on the server rather than in one browser, so it follows you between devices. Opening a project loads the most recent turns and scrolling up loads older ones.

The sandbox

Each project runs in a warm sandbox — an isolated pod that clones your repo, installs dependencies, and starts your dev server with hot-reload. It is the same runtime engine that powers Preview. The live-preview pane in the IDE is an authenticated reverse proxy to the dev server inside that sandbox.

Sandboxes are bounded by a time-to-live and reaped when idle. Reopening a project simply re-boots from the last commit (head_sha) plus the database branch, so nothing is lost — a stopped sandbox is cheap to resume.

Note

A sandbox boots whatever your repo’s dev script starts. An empty, freshly-created repo has nothing to serve until the agent writes an app into it — import a repo with a working dev server to see the preview immediately.

The database branch

Every project gets its own Postgres database — a copy-on-write Snap branch. Design injects its connection string into the sandbox as DATABASE_URL, so your app finds it the way any app finds a database, with no Design-specific code. The agent and the running app read and write it freely; the source is never touched and branches are isolated from each other. This is why you can let an agent run migrations against “the database” without fear.

Note

There is no data browser inside Design — the workspace is preview, code, and history. Inspect the data with your own app, or with any Postgres client using the same connection.

The agent

When you send a chat message, a headless coding agent runs inside the sandbox and edits the files on the same filesystem the dev server is watching — so the preview hot-reloads as the agent works. The agent only edits files; it has no credentials and no network access to your GitHub. That isolation is deliberate: the sandbox runs your repo’s code, so it must never hold a workspace secret.

How your code is committed

Because the agent can’t push, Design does the git work host-side: after a turn it pulls the edited tree out of the sandbox, applies it to a working clone, and commits + pushes to a destesi-design branch in your repo using your Connect GitHub token. The commit SHA becomes the project’s new head_sha. Your code is genuinely yours at every step — open a pull request to your default branch whenever you want to merge the agent’s work.

Shipping it

Design has no deploy button, and that is the point rather than a gap. The code is already in your repository on every turn, so shipping is whatever shipping already means for you: merge the working branch and let your existing pipeline run, or hand the repo to Deploy or any other host. Nothing has to be extracted from Design first, because nothing was ever locked inside it.

Where it fits

Design composes Connect (credentials), Snap (database), the sandbox engine (runtime), and your GitHub (code). It owns none of those substrates — it orchestrates them, which is why a Design project is just a normal repo you can clone, run, and keep with or without Destesi.