Work

Work is a single destination in the NEXUS sidebar holding one dataset — your work items, the projects they belong to, and the boards they are carded onto. Four planning surfaces read it, and a project scope narrows all four. They are not separate products with separate copies of the data; they answer different questions about the same rows:

Surface	The question it answers
Projects	Which container am I working inside? Selecting one narrows every other surface.
Board	Where is this in my flow? Columns you name, in the order you work.
List	What is there? Filtered and sorted by the store, not by the view.
Matrix	What matters first? Quadrants read from each item's priority.
Calendar	When is it? Scheduled work on the days it falls on, in your timezone.

Every surface reads and writes one store, and so do the local work_* MCP tools. There is one durable home for all of it on the machine:

~/.chainabit/nexus/work-management.json

A work item an agent files through work_item_create appears on your board; a card you drag on the board is the row that agent reads back. There is no second table and no synchronisation between the two — they are the same rows.

Everything here is local

Work data stays on your device and does not sync between devices. See Sync for the current behavior.

In this guide

• Work Items — the item model: schedule ranges (not due dates), the four legal schedule states, priority, the status lifecycle, hierarchy and relations.
• Boards — stages are columns you define, not statuses; WIP limits, definitions of done, and how ordering works.
• Matrix — the Eisenhower reading, whose quadrant is derived from priority and completion and is never stored.
• Projects — a project is a scope the other surfaces narrow to; its status lifecycle, and read-only statuses that genuinely refuse writes.
• Calendar — interval semantics, all-day vs timed vs multi-day vs unscheduled, and why days are your local days.
• Sync — the local-first stance, the recorded decision, and what is honestly not built.
• Delegation — handing a work item to an agent or a team, and the evidence an agent owes before it may call the item done.

Where to go next

• Local-First — why NEXUS keeps work on the machine.
• Tool Namespaces — the families a connected client discovers, including work_*.
• Projects — the other meaning of "project": the identity of a working folder, which a work-management project record is bound to.