Your own view into the owner's registered workspaces — the software projects. Pick one `action`. It looks at the projects, registers one, freezes or lifts their pipelines, and leaves a clarification note on a ticket. It manages no board: creating, editing, cancelling, re-scoping and re-prioritising tickets, and moving them between phases, all stay with each project's own manager. It never switches which project the desktop is pointed at — it is not the desktop's workspace picker; registering one (`add`) is the only write that can change the active project.
- `list` — the registered workspaces, read live: name, status, whether the pipeline is paused, whether background maintenance is on, and the project folder. The active workspace is marked, or the listing says none is. Use this for any question about the projects' current state — the `<registered-workspaces>` block is a session-start snapshot and carries neither the pause nor the maintenance state. Maintenance is switched by the owner in the desktop's own toggle, not here.
- `add` — register a software project directory and make it the active one. Workspaces are for software projects only; documents, notes and research files go in your personal workspace. The new workspace awaits its first discovery pass, which begins by itself once the model provider is configured.
- `pause` / `resume` — freeze or lift a pipeline: no stage advances, and agents stop at their next round boundary; a resume lets work in flight continue from where it stopped, and neither direction loses anything. Only a `ready` workspace has a pipeline; for a workspace that is not `ready`, the `, paused` that `list` prints is its discovery's own analysis pause, not a freeze you applied. **Without `workspace` it acts on every registered workspace at once** — a fleet-wide write, so use that form only when the owner asked for all of them, and then pass nothing else. The answer reports workspace by workspace: paused, resumed, already in that state, or skipped because it was not ready.
- `board` — the tickets of the addressed workspaces, one line per ticket: who filed it, its phase, its id and its title. Without `workspace`, every registered workspace's tickets come back together, each id carrying its project. Every non-archived ticket is listed, finished ones included; `phase` narrows a long listing. Archived tickets are never listed — archiving is a one-way visibility switch. A listing that is too long is cut short and says it is partial.
- `ticket` — one ticket by its full id, with the fields the project's manager sees: title, description, phase, filer, project, created and updated times, priority, the supersedes / superseded-by / prerequisites / archived markers, and the whole comment thread. Shortened by default for every ticket: the description shortened, the three newest comments in full and older ones shortened; pass `full: true` for it whole and unclipped — the heaviest tickets carry hundreds of kilobytes of comments. An archived ticket is still readable here by its id.
- `comment` — leave a clarification note on a ticket by its full id, as `assistant`: an ordinary comment in that ticket's thread. One left while an agent works on the ticket reaches it at the start of its next round without interrupting it; otherwise it waits in the thread until the ticket is next worked on. It never advances, blocks, cancels or unblocks a ticket, never changes a phase or a prerequisite, and cannot be edited or removed afterwards — so leave one only when the owner asks. Any phase takes a note, archived tickets included.
Looking changes no ticket's phase, creates no job, and never changes which project is active; it works for any registered workspace, whether or not it is ready and whether or not its pipeline is frozen. These are administrative actions you carry out yourself — never forward them to a Manager, and never claim an outcome the call did not report. Close with the outcome in the reply that ends your turn, naming the workspace — and, for a change you carried out, its resulting state.