Plan and delegate work

NEXUS keeps a work-management store of its own: projects, boards, and the work items on them. It is one Work destination in the left rail, and everything in it lives on this machine.

1. Four readings of the same items

Work is not four separate tools. There is one set of work items, and four ways to read them — switching surfaces never moves an item, and never hides one that a filter did not hide.

Surface	What it is for
Board	A kanban board: columns you define, cards you drag between them.
List	A flat, filterable, sortable table — the surface for finding things and changing several at once.
Matrix	An Eisenhower matrix: urgency against importance, in four quadrants.
Calendar	Scheduled items across days, plus everything still unscheduled.

A fifth entry, Projects, is not a fifth reading — it is the container the other four can be narrowed to.

2. Set up a board

Columns on the board are stages you define, not a fixed lifecycle. Add one, name it, and optionally give it two things:

• A work-in-progress limit. When a card would push the column over its limit, NEXUS asks before letting it in — it names the limit and the current count. It is a question, not a veto: a WIP limit is a commitment you make to yourself, and you are allowed to break it knowingly. A limit of 0 is respected as "this column is set up to hold nothing" rather than treated as no limit at all.
• A definition of done. Whatever you write is shown to you as the card enters the column. Moving a card within a column asks nothing — neither the count nor the meaning of done changed, and prompting for it would only train you to dismiss prompts.

3. Filter a list without losing the filter

The List surface filters and sorts through the store, not by trimming a page of rows it already had. That matters for sorting: "highest priority first" over rows already in hand only sorts the rows already in hand.

Your filter set is restored rather than remembered by luck. Navigate into an item and back, or let the window rebuild, and you return to the list you set up — not to an unfiltered one you never asked for. The list also distinguishes "the store is empty" from "your filters matched nothing", and the filter menus are built from the unfiltered data, so a filter can never delete the option you need in order to undo it.

4. Scope everything to a project

Select a project and the Work destination narrows to it. The scope header stays above whichever surface you are on, so the project's identity and its status control are reachable from all four rather than only from the one you opened.

A project's status is load-bearing. When a project is not active — paused, completed, abandoned, or archived — it becomes read-only, and that is enforced in the store rather than by disabling buttons. Every write from every surface, whichever menu, shortcut, or drag produced it, is refused with the same message. Changing the project's status back is deliberately the one write that still goes through, because it is the way out.

Collaborators are absent from a local project, and that absence is real. A collaborator is a person on a shared account; a project record on your Mac has no account behind it.

5. Delegate an item to an agent or a team

Right-click a card on the board, a card in the matrix, or a row in the list, and choose Delegate to…. All three offer the same recipients and word a refusal the same way, because they are the same control mounted in three places.

Three things to know about what happens next:

• The delegated task IS the work item. Nothing is copied into a second task list. The item keeps its own acceptance check, its owned files, and its recorded evidence; the delegation records who is carrying it.
• A team delegation fans out by file ownership. One item is split across teammates by which files each member owns — which is the point of handing it to a team rather than to one agent, and what stops two agents editing the same file over each other. One item therefore has several delegations, one per member.
• Completion is evidence-gated. An agent reporting "done" is not enough. A delegated item counts as complete when its acceptance check ran and the recorded evidence says it passed. Absent evidence has proved nothing, and a run that failed twice before passing says so rather than presenting only its last state.

The loop is visible on the item itself: who took which slice, on which thread, what came back, and what the evidence said.

6. Where it is stored, and what does not happen

Everything above is a single file on this machine — ~/.chainabit/nexus/work-management.json. See Paths & Credentials.

There is no sync. Nothing here replicates to a Chainabit account or to another machine, and there is no setting that turns that on. Two machines means two independent stores. That is a stated limit, not something to configure around — see Local-first for the reasoning and what it is waiting on.

Agents can reach the same store over MCP through the work_* tools, which are local end to end and are not the Chainabit cloud's similarly named tools — see MCP Tools § work-management tools.

Next

Continue to Pinned memory.

Where to go next

• Work — the full guide to every surface this page only introduces.
• Project Model — workspace, project, repository, and chainy, and why a project is not a chainy.
• MCP Tools — the work_* tools and their full parameter schemas.
• Agent Mesh guide — the delivery semantics a delegation rides on.