Glossary

Some of these words are used elsewhere in software to mean something broader. Where that is true, the entry says so explicitly. Each definition links to the page that explains it properly.

Applicator#

A small piece of code that makes one specific kind of edit to source, without an AI model, for example "change this prop's value" or "move this element". Each one rewrites the exact characters in the file rather than describing a change to a model. Most edit kinds have a separate applicator per framework (a Vue one and a React one), but the two sets are not identical, and a few kinds exist only for Vue. See deterministic editing.

Attribution#

Working out what you actually clicked. When you select something in the preview, attribution decides which component owns it and which prop or slot produced it, so the edit lands in the right place in source. It uses the component's manifest and rendering hints to do this. See design-system grounding.

Backup journal#

A copy of a file's previous contents, written to .desde/backups/ before any Editor write touches the original. It is a manual recovery trail, not the Undo button and not git. See branch mode.

Branch mode#

The Editor's saving model: edits write your real source files in the currently checked-out branch's working tree, immediately, with no Save step. It is the only mode. An earlier per-session worktree model was removed, and the old EDITOR_WORKTREE_MODE and EDITOR_BRANCH_MODE variables no longer change anything. See branch mode.

Bridge#

The script that runs inside the prototype's iframe: it handles selection, highlighting, comment pins, and the inspector overlay, and talks to the surrounding app by message passing. The word covers two things: the source, which is the modules in src/bridge/, and the built file those compile into (dist/bridge-bundle.js), which is what both the Editor and the Viewer actually serve. See how it works.

data-desde-src#

An attribute of the form file:line:column that the Editor stamps onto elements as your dev server serves them, recording where in your source each element came from. It is what lets a click in the preview become an edit to a specific line. It is added in memory at serve time and never written into your files. See how it works.

Deployment#

One Viewer build of a project's repo at a particular commit, with its own status and build log. A project's current deployment is what visitors see at its URL, and until a project has one, its review page returns not-found. Viewer-only: the Editor has no deployments. See projects.

Dormant lane#

An edit kind the Editor still implements but no longer offers. Its controls are absent from the workspace and the edit API refuses it, until the project opts back in with a lanes entry in desde.config.json. Narrower than "removed": lanes.detach and lanes.swap name two lanes whose applicators, and whose tests, are intact and unchanged. A lane whose tests were allowed to rot could never be un-dormanted. See editor configuration.

Drift#

The Editor noticing that what it knows about your components disagrees with what actually rendered: a hint that no longer matches, a component missing from the catalog, or a prop nobody declared. Drift signals are advisory: they mean attribution may get worse, not that an edit was wrong. See design-system grounding.

Editor#

The local authoring tool. It runs on your machine as a command-line program (desde <repo-path>), supervises your own dev server (plain Vite, Nuxt, React Router or Next.js) and edits your source repo. It is not published to npm today, so it runs from a checkout of the Desde repo, and it edits Vue 3 and React source only. See the Editor guide and the CLI reference.

Grounding#

Everything the Editor knows about your design system (component manifests, design tokens, and project conventions), made available to both the inspector and the chat agent. The point is that a change lands as your button component with your tokens, not as generic markup. See design-system grounding.

Manifest#

A machine-readable description of one component: its name, its props and their allowed values, its slots and events, and optionally its rendering hints. Manifests are mostly extracted automatically from the type declarations shipped in an installed component library. See design-system grounding.

dsv_ token#

A Viewer personal access token, of the form dsv_<id>_<secret>. It authenticates as the person who created it and grants exactly what that person can already do. It is never an admin key. Only a hash is stored, so the full token is shown once when you mint it and cannot be recovered afterwards. See projects for the calls that need one.

Rendering hint#

The part of a manifest that says where an input shows up in the rendered output, for example "the title prop becomes the text of the .card-title element". This is what makes clicking a piece of text resolve to the prop that produced it. Hints record who wrote them and whether they have been checked against the real component. See design-system grounding.

Session#

Always a chat session, one conversation thread with the agent, shown as a tab in the chat panel and stored at .desde/chat-sessions/<id>.json. It is never an editing session: there is no per-session copy of your code, and every chat session edits the same working tree. Two sessions changing the same file will be told about each other. See the workspace.

Slug#

A Viewer project's URL-safe identifier, the {slug} in /p/{slug}/. It is how a prototype is addressed and how the Editor knows which Viewer project it is linked to. See projects.

Viewer#

The review surface: a self-hosted server that clones a GitHub repo, builds the prototype, serves it, and wraps it with comments and an inspector for people giving feedback. It adds the bridge to the served HTML as the page is requested rather than changing anything in your repo. It is a separate program from the Editor. See the Viewer guide.