Projects & Workspaces

What it is

Two related surfaces. Projects register a codebase (with its repos, file tree, and boundary policy) as the home for missions. Workspaces are ephemeral scratch folders agents use to stage files.

Operator surface

  • Projects — project_list, project_get, project_register, project_sync, project_delete, project_tree_get / project_tree_update, project_check_boundary.
  • Workspaces — workspace_create (returns the workspaceId handle every other tool needs), workspace_write_file, workspace_read_file, workspace_list_files, workspace_delete.

REST is ProjectsController, WorkspaceDownloadController, and the connections / onboarding controllers; the dashboard exposes project registration and file-tree views.

How it works

A ProjectRecord links to its Git repositories (ProjectConnection, ProjectMirrorMetadata, ProjectSubmodule) and stores a registered file / module tree plus a boundary policy that project_check_boundary enforces so agents stay inside approved paths; ProjectSession and PendingSync track sync state. Workspaces are provisioned in a per-tenant genesis-workspace service and addressed purely by their returned id — they are deliberately separate from the permanent project repos so agents can scribble freely before producing reviewable changes.

Design canvases

A design task (coding_task_dispatch with taskType: "design", or a workflow Coder node whose task type is design) has the coder author a design canvas — multi-artboard mockups as .dc.html files plus a canvas.json layout, committed under design/<slug>/ in the project repo. Genesis assembles those sources into a single pan/zoom canvas and renders it on the project page (/projects/{id}) and the Preview screen; each canvas opens at /projects/{id}/design/{taskId}/{slug}.

This is Genesis's own skill (genesis-design-canvas), not the Claude Code /design feature: the bundled skill and its Artifact tool require a claude.ai login the broker-mediated coder does not have, so Genesis authors the same .dc.html format and does the assembly itself — nothing is published to claude.ai. The canvas is rendered in a sandboxed srcdoc iframe (opaque origin, allow-scripts only), the same origin-isolation posture the conversation view uses for inline UI mockups; it is view-and-export only in the dashboard (no save-back), and it is a different, weaker-blast-radius path than the run-artifact render lane (see artifacts).

When a visual direction is genuinely open, the coder drafts 2–4 low-fi direction artboards, raises one attention request (decision_create, a Clarification), and waits for the operator to answer in the Genesis decision queue after viewing the directions on the dashboard — only a human resolves it (separation of duties). The coder then builds the chosen direction into Main.dc.html. Design tasks are dispatched explicitly or authored into a workflow; the mission decomposer does not emit them on its own.