Workspaces & repositories

In the dashboard, the home of a codebase is a project: registering one tells ARDS where your code lives and makes it the place missions run against. Behind the scenes ARDS keeps its own clone of your repository — the working copy coders write to (you'll see it called the workspace in status messages) — and pushes approved work back to your real repository. You never manage the clone yourself; you manage projects.

There is no separate setup wizard any more. Registering a project does the whole job: it is cloned, indexed, and onboarded automatically, and the first mission — like every approval after it — arrives in the decisions queue.

The Projects page

Projects in the sidebar opens the registry — the page titles itself Project Management. All Projects lists every project as a card: its name (click through to the project's page), a status badge, its type, a link to its repository, and an Aspects progress figure from onboarding.

While the first clone is running, the card says Cloning workspace…. If it fails, the card says Workspace clone failed. with a hint about the likely cause and a Try Again button — a bad token or an unreachable host are the usual suspects.

Register a project

The Register New Project form sits on the same page:

• Project Name — required.
• Repository URL — where your code lives. The form adapts to what you paste:
  • HTTPS — for a private repo, add a Personal Access Token. The form states the scope it needs: "Required scope: read_repository (GitLab) / repo read (GitHub). Stored encrypted; used only to clone into the mirror." It also offers a direct link to your provider's token-creation page.
  • SSH — click Generate deploy key; ARDS generates an ed25519 keypair and shows you the public key to paste into your provider's deploy-keys list. Grant write access: a read-only key clones fine, but blocks the push back to your repository when work is approved later.
  • Empty — allowed. The form explains: "Repository URL is optional. Leave it empty to create a greenfield project: Genesis hosts the repository and creates the customer origin at delivery."
• Description — optional.
• Type — Managed, Consulted, or Observed.

Click Register Project and watch the new card appear in the list; the clone, indexing, and onboarding run on their own from there.

Pick the active project

The project selector lives in the top bar of the dashboard, showing All Projects by default. Picking a project scopes what you see — conversations, missions, and decisions filter to it — and per-project entries (Intelligence, Onboarding) appear in the sidebar for it.

A project's page

Click a project's name to open its page: the description, its id, current phase, repository link, and creation date, plus the project's vision when one is set. From here you reach the project's Intelligence and Onboarding views, see the branch state across its missions, review its design canvases, and set up app browsing targets.

Boundaries: what agents may touch

The Projects page also states the standing rules — Constitutional Boundaries — that apply to every project:

• Boundary (Protected) — .git/, main branch, *.env files: agents don't touch these.
• Requires Approval — merge to main, delete protected files: only with your explicit approval.
• Autonomous — feature branches, regular files: agents work freely here.

This is why day-to-day agent work happens on branches, and why anything that lands on your main branch passed through a human gate first.

How approved changes reach your repository

Approved work is pushed to your repository automatically, using the credential you provided at registration — the Personal Access Token for HTTPS, the deploy key for SSH. There is no separate "publish" step, which is also why a read-only deploy key eventually hurts: cloning worked, but the approval push fails.

When a mission runs workflows, the path has one more named layer: each run you accept lands as one changement on the mission's branch, and the mission's merge request is the composed stack of those changements. Each changement can be reverted individually — dependent changements cascade, and you see a preview of the cascade before anything is undone. See the changement stack.

Design canvases

A design canvas is a set of visual mockups — several artboards laid out on one surface — produced for your project by a design task. The project page has a Design canvases panel listing every canvas produced so far, with its artboard count (N artboards); before any exist it says: "No design canvases yet. Dispatch a design task to create one."

Click a canvas to open the full-screen viewer at /projects/{id}/design/{taskId}/{slug}. There you can pan and zoom across the artboards, export what you see as PNG or PDF, and download the canvas sources as a zip (Sources (zip)). The viewer is view-and-export only.

How one comes to exist: a design-type task produces it. When the visual direction is genuinely open, the coder drafts a few low-fi direction artboards first and asks you to choose between them — that question arrives in the Decisions queue. Look at the directions in the viewer, answer the decision, and the task continues by building out the direction you picked.

One honest limitation: canvases are produced by tasks, not hand-edited — there is no editing them in the dashboard. If you want a canvas changed, say so in the mission or task that owns it.