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 run 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, grouped into four lifecycle categories:

Categories keep lifecycle reasoning simple. Boards, lists, filters, and sorting all work from the individual status, and the concrete statuses preserve the more specific workflow behavior agents and automations rely on.

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 run 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 under Settings → Issue Statuses — Code Review, QA, Rework. Every status belongs to one of four lifecycle categories:

Custom statuses inherit lifecycle semantics only. They do not inherit built-in Backlog parking, In Review autopilot completion, Blocked failure, or In Progress recovery. Use the fixed built-in status when that behavior is required. Historical custom statuses follow the same rules: Awaiting Response is ongoing work, not automatic review completion. Assignment and creation still follow the general agent trigger rules.

For installed clients, existing API category fields retain the seven-value wire enum. New clients normalize that representation into four categories; wire values never grant behavior inheritance. The database stores only the four lifecycle values.

Four things follow from that model:

• A status's category is fixed once the status exists. Changing it later would change the lifecycle behavior of every issue already sitting on that status, so the editor keeps it read-only. Choose the lifecycle stage first, then name it.
• Status grouping uses individual statuses. Board columns, List sections, and Swimlane status columns each distinguish built-in and custom statuses. Code Review and QA have separate columns even though both belong to Started. Categories are internal lifecycle classifications, not replacement column names.
• 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 runs

An issue is the persistent record of a piece of work; a run is one concrete run by an agent. One issue can produce several runs over time — a first implementation, follow-up changes, another check. A completed run 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.
• Runs — learn about queuing, running, retries, and cancellation.