Projects
A project in the Work destination is a container the other surfaces narrow to. It is deliberately not a page of its own.
Why there is no project detail page
A project's content is its work items, and there are already three complete readings of those. A project detail page would be a fourth rendering of the same rows, with its own filters, its own sort, its own empty state, and its own opportunity to disagree with the other three. So selecting a project opens a scope instead:
- the Board opens that project's board;
- the List filters to it;
- the Matrix and Calendar show only its items;
- and every one of them reads and writes through the scoped store, so the project's status governs all of them at once.
While a scope is open, a band above the surfaces names the project, states any read-only notice, and offers the way back out. It sits above every surface rather than inside one, so a person who scoped a paused project and then switched tabs is never left with a surface that silently refuses writes.
An item belongs to a project through a card on that project's board, not through a field on the item. "The items in this project" is resolved project → board → stage → card, by the store, so no surface can compute a different answer.
This project record is the same record the rest of NEXUS uses for a working folder — see Projects for that side of it.
Status lifecycle
| Status | Writable? | What it means for the work |
|---|---|---|
| Active | Yes | Its work items can be changed. |
| Paused | No | Work on it is deliberately stopped. Set it back to Active to work on it again. |
| Completed | No | Its items are kept as the record of what was done. |
| Abandoned | No | Its items are kept for reference only. |
| Archived | No | Restore it to change its items. |
Two transition rules the surfaces apply for you:
- Moving to Archived leaves the scope. An archived project's surfaces are read-only, so staying on them would show a board you can no longer touch.
- Moving out of Archived restores first. Archiving is a filing state rather than a point on the lifecycle, so going from Archived straight to Completed restores the project and then completes it — writing the new status over the archive would un-archive as a side effect of a different instruction.
Read-only means read-only
Active is the only writable status. Everything else is refused, and the refusal happens at the store, not at a button.
That distinction is the whole point. A status that only greys out a toolbar is not read-only: a keyboard shortcut, a drag, a context menu, or an agent driving the work_* tools would still write, while the person is told the project is stopped. Because the refusal lives under every surface, all of those paths refuse alike — and the refusal is stated in words, naming the project, its status, and the one move that lifts it.
A status this build does not recognise fails closed: it is treated as read-only and says so, rather than being assumed editable.
Working with projects
- Creating and assigning. A project's board is created on first use. Work items can be dragged onto a project, or added from the scope band's Add existing item menu, which offers items that are not already on that project's board (up to 25 — past that, dragging from the item surfaces is the right gesture, and the menu says so).
- Deleting. Deleting a project requires typing its name exactly. That is not ceremony: it deletes every work item carded onto the project and every sub-item beneath them, and the confirmation states the count before you commit. The project, its board and its columns remain; the items do not come back.
- Numbers on a project card. What is shown is computed from rows the store actually holds — how many items are linked, how many are complete, and the progress that follows from those. Figures that would need data this build has no local record of are reported as gaps, in words and with the reason, instead of being rendered as a plausible number.
Collaborators are cloud-only
A project here is a record on your machine, and a collaborator is a person on a Chainabit workspace — so a local project has none by definition. The scope band says exactly that, rather than offering an empty roster and an invite field that could never be filled in.