Issues

An issue is Multica's basic unit for organizing work: a feature, a bug, an investigation — anything a member or an agent should own and drive forward. The discussion around it, its status changes, and every run stay in one place, so there is no need to reassemble context from chat logs or terminal output.

Parts of an issue

Create an issue

Create one from the Issues page or inside a project — a title is enough, and every other property can be filled in later.

Each issue has a number, such as MUL-123. The digits increment within the workspace; after an admin changes the workspace's issue prefix, numbers display with the new prefix. See Workspaces.

Choose an assignee

When assigned to an agent or a squad, the issue enqueues immediately unless it is in backlog; if the runtime is offline, the task waits in the queue. Archived agents and squads cannot be assigned.

Assignment does not bypass an agent's Access; when assigning to a squad, the leader's Access is what gets checked. See Assign issues to agents.

Status

Every workspace starts with seven built-in statuses. They are also the seven categories — the fixed set of behaviors Multica knows about — so each built-in status names its own category.

There is no fixed flow between statuses — members and agents can change them directly.

Agents write the status the issue is in as their work changes it: starting work on what the issue asks for — in whatever form, research, design, or a review the issue itself requests — moves it to in_progress right away, so the board shows the work while it runs; delivering moves it to in_review; work that continues beyond the turn keeps it in_progress; a turn that produces nothing of the issue's own deliverable — answering questions, consulting on work owned elsewhere — leaves the status untouched throughout. These updates are written explicitly by the agent through the Multica CLI during the run — the server does not flip issue status when a task starts or completes (apart from the two system exceptions below). done is usually a human confirmation, or an integration such as a PR with close intent that merges.

Custom statuses

A workspace owner or admin can add statuses of their own under Settings → Issue Statuses — Code Review, QA, Rework. Each new status picks one of the seven categories and inherits that category's behavior in full:

So a Code Review status in the in_review category ends an autopilot run exactly like in_review does, and moving an issue out of backlog into a Rework status in the todo category starts the assigned agent exactly like moving it to todo would.

The name is what your team reads; the category is what the platform acts on. Wherever the rest of this documentation says a status triggers something, that rule belongs to the category, so a custom status inside it is covered too. It does not work in reverse: when the platform sets a status itself — the rollback to todo or the done on a merged PR above — it writes the built-in status, never a custom one from that category.

Four things follow from that model:

• A status's category is fixed once the status exists. Changing it later would silently rewrite what the platform does with every issue already sitting on that status, so the editor keeps it read-only. Choose the behavior first, then name it.
• Board columns are categories, not statuses. Adding a status never adds a column — there is one column per category. A custom status sits in its category's column, and its cards carry a small chip with the status name, so Code Review and QA stay distinguishable inside In Review.
• Built-in statuses are locked. Their names, colors, and categories cannot be changed, and they cannot be archived — a workspace that never opens the page keeps exactly the board it had.
• Archiving retires a status, it does not delete it. Issues already on it keep it, keep its name and color, and keep behaving the same. It only stops being offered the next time someone sets a status.

Built-in statuses are translated into the interface language; a custom status always shows the name you typed. The API and the CLI address it by its key: multica issue status MUL-42 code_review. The settings page derives that key from the name; the API accepts an explicit one and only falls back to deriving it. Either way the key is fixed at creation — renaming the status later does not change it.

Issues and tasks

An issue is the persistent record of a piece of work; a task is one concrete run by an agent. One issue can produce several tasks over time — a first implementation, follow-up changes, another check. A completed task only means that run ended; whether the issue is finished is determined by the issue's status.

Projects and sub-issues

An issue belongs to at most one project; the project provides shared instructions and resources for runs inside it. Moving an issue to another project does not create a copy.

Larger work can be split into sub-issues: the parent issue keeps the overall goal while sub-issues progress independently. Parent and child statuses do not affect each other.

Sub-issues can be given a stage to advance in batches — 1, 2, 3. When every sub-issue in the earliest unfinished stage reaches done or cancelled, the parent issue receives a "sub-issues completed" notification; when the parent's assignee is an agent, it wakes up and decides whether to start the next stage. Sub-issues without a stage count as one batch and notify once when they all finish.

Switch views

The Issues page offers five views — list, board, table, Gantt, and swimlane — filterable and sortable by status, assignee, project, and other properties. They all show the same issues.

Delete an issue

Any workspace member can delete an issue.

Next steps

• Projects — organize work that takes multiple issues to finish.
• Comments — discuss, reply, and @mention around an issue.
• Assign issues to agents — hand work to an agent and start the first run.
• Tasks — learn about queuing, running, retries, and cancellation.