Workstation
The Workstation page (/workstation) is the single sidebar entry for what the company builds and who builds it. It's tabbed — Products first, Projects second (the active tab is in the URL as ?tab=) — rather than two separate sidebar entries. Projects are the git repositories RoboCo is allowed to touch. Products group several repositories into one shipping unit and route each delivery cell to the repo it owns. You only need Products when a single thing you ship spans more than one cell.
Both URLs redirect straight into the matching Workstation tab, so a bookmark or an old link never breaks. Nothing else about either feature changed — same fields, same tables, same behavior, just presented as tabs on one page.
Both tabs default to a card-grid view — one box per row, with the same status/badge visual language as the Agents page's roster — with a Cards / Table toggle in the header to switch to the classic table. The choice is remembered independently per tab, per browser. Card view adds a sort control (plus an ascending/descending toggle) that reorders the cards client-side; the table view is untouched and keeps its own row order regardless of the sort picked in card view.
Products
A product maps each delivery cell to the project (repository) it builds for that product. Use it when one deliverable spans multiple cells — a Backend repo and a Frontend repo, say, that ship together.
The page is a straightforward table plus a New button. A product carries a name and a set of cell-to-project assignments: Backend → repo A, Frontend → repo B, UX/UI → repo C. A cell with no assignment simply doesn't participate in that product — the table's Cells column reads "Unmapped" when none are set. Alongside it, a Progress column rolls up done / active / blocked task counts across every one of the product's mapped projects, with the same at-risk status dot the Projects table uses.
In card view, each product's card carries the same Cells mapping and Progress rollup as its table row, plus a pencil shortcut straight into the edit dialog. Sort by Name or by Cell count (how many cells the product maps).
Why the mapping matters
When the Main PM decomposes a product into work and fans it out to the cells, the branch and PR structure follows the mapping. The Main PM cuts one integration branch per distinct repository in the product. A cell's work lands on its repo's integration branch; the cell PM opens the cell→root PR within that repo, and the Main PM opens the root→master PR per repo. Two cells assigned the same repo share one integration branch; two cells on different repos get one each.
If everything you're shipping lives in one repo, you don't need a product at all — register the project and hand the Task Assistant or the Create Task dialog that project directly. Products exist purely to coordinate a multi-repo, multi-cell deliverable.
For how branches assemble and merge once the cells are building, see the merge model. For the lifecycle a single task moves through, see the task lifecycle.
Projects
A project is one git repository plus the configuration that tells the company how to build and check it. The Projects page is where you register, search, and edit them.
- New opens the create dialog — name, slug, git URL, forge (GitHub, Gitea, or GitLab), git token, assigned cell, default branch, and optional per-project gate commands (including the codegen command, alongside test/lint/format/typecheck/build/quality).
- The list supports search, a cell filter, and a show-inactive toggle so retired repos stay out of the way without being deleted.
- Edit now opens a slim quick-edit dialog — just name, assigned cell, and active — with a Full settings → link out to the project's own settings page for everything else.
The project settings page (/projects/[id]/settings)
Every other project field lives on its own full page now, one card per concern instead of one long scrolling dialog:
| Card | What it holds |
|---|---|
| Identity | name, git URL, forge selection, and the GitHub App binding — the same Select repo picker the New Project dialog offers, once a GitHub App is configured on the Settings page (see Registering a project). The slug shows here too but is immutable — set once at creation, since it composes every agent's workspace path and every branch name. |
| Git Auth | the encrypted git token — write-only, never re-displayed once saved; clear it or replace it. |
| Placement | assigned cell, default branch, the Protected Branches chips editor (extra branches, beyond the always-protected master/main, the fleet won't rebase onto or force-push over), and the active toggle. |
| Environments | the environment-ladder editor — add, reorder, or remove named rungs mapping to branches (see Environment branches). |
| CI/CD Commands | test / lint / format / typecheck / build / quality-gate / codegen commands. |
| Budget & Ops | the Monthly Budget (USD) field (see Task & project cost budgets), CI-watch opt-in plus its workflow file, the video engine per-project opt-in, the dependency-update bot's command and lockfile paths (see Autonomous maintenance), and two Board Programs checkbox lists — participates in (Pest Control, Spackle, Mirror, Dogfood: opts this project into that program's cycles) and excluded from (org-scoped programs; today only Roadmap's exclusion is actually enforced). |
| Sandbox | the sandbox services opt-in (Postgres / Redis / Mongo) and, per service, which extensions or modules it should carry. |
Each card saves independently — editing one doesn't require touching or re-submitting the others. Conventions (see Architectural conventions) sits alongside these as its own page-level tab, at its natural full width rather than squeezed into a card.
The table itself carries a Tasks column (a status dot plus done / active / blocked counts across the project's tasks, so an at-risk repo is visible without opening it) and, inline under a project's name, a CI-Watch badge whenever that project has opted into multi-repo CI-watch.
A project's card mirrors its table row exactly — the same cell badge, active/inactive status badge, git-token badge, and CI-Watch badge, plus the Tasks done/active/blocked counts — so nothing is card-only or table-only. Sort by Name or by Cell.
The field-by-field detail — what each field means, the token scopes you need, the encryption guarantee, and the default-branch gotcha — lives in Register your first project. Read that page before you create a repo; this page doesn't repeat it.
The single biggest lever on output quality is pointing a project's quality_command and per-step commands at the real checks you'd run locally. The company then gates itself the way you would. Details in Gate commands.
Next
→ Tasks & Kanban to author and track the work · Git to watch the branches and PRs land · Board Programs for what the participation checkboxes on the Budget & Ops card actually opt a project into.