Big Boards

A Big Board is a kanban view over your notes. It is not a second place to file work: a board is a saved tag query plus an ordered list of Phase columns, so a note appears on a board because of the tags it already carries, and moves between columns because its phase changed.

That is the whole point. The board cannot drift from reality, because there is no separate board state to drift.

The four boards

Board	Membership tags	Phases
Tasks	task + blackops	Todo, In Progress, Blocked, Done
Bugs	bug + blackops	Needs Triage, Open, In Review, In PR, Closed
Features	feature + blackops	Open, In PR, Blocked, Shipped, Won't Build
Content Seeds	content-seed + blackops	Seed, Drafting, Drafted, Launched, Published

Membership matches on all tags, not any. A note tagged feature alone is not on the Features board; it needs feature and blackops together. A note can legitimately sit on more than one board.

The phase vocabularies are not invented for the boards. They are the values the existing agent skills already write into their bold **Status:** fields, which is why the boards rendered against existing notes with no backfill.

Bugs and Features use the same words, in the same order, for the states they genuinely share — Open and In PR. That is deliberate as of 2026-09-12: the two had drifted into different names for identical states (Idea against Needs Triage, Triaged against Open), and the cost showed up as notes sitting in Unsorted because a status from one board's vocabulary had been written onto the other.

Shared words, not a shared list. The differences are each doing work:

• Features have no triage or review column. Both exist on Bugs because a bug arrives as a report that may not be real, may not reproduce, or may already be fixed — something has to decide before work starts, and something has to check the diagnosis. A feature carries neither doubt: it is a proposal that is either worth building or it isn't, and one being built goes straight to a PR. A feature note stays Open for its whole build.
• Features have two terminal states, Shipped and Won't Build, because a single Closed cannot tell a delivered feature from an abandoned one. One Closed is enough for a bug.
• Features have Blocked, which the feature builder's resume sweep queries by that literal word to find work it can pick back up.

Managing boards

Boards are managed from Big Boards in the admin. New board opens the editor; each board card carries Edit and Delete.

The editor takes:

• Name, and a slug that follows it until you type your own. The slug is the board's URL at /admin/boards/<slug>.
• Description — what the board is for, shown on the card.
• Membership tags — comma separated. A note needs all of them to appear. One tag matches far more than you expect, which is why the built-in boards pair a subject tag with blackops.
• Phase columns — comma separated, left to right. These have to match what your agents write into a note's phase, or the cards pile up in Unsorted.
• Position — where the board sits in the list.
• Enabled — turn a board off without deleting it.

Tags and phases preview as chips as you type, with phases numbered so the column order is visible before you save.

Deleting a board removes the view, never the work. The notes it showed keep their tags and their phases, and they reappear the moment an equivalent board exists.

Global boards

A board with no workspace is global: it appears for every workspace on the platform. The four built-in boards are global, and they are marked as such on their cards.

Only a platform admin can edit or delete a global board. A site admin sees them, and creates boards scoped to their own site.

Boards are rows, not code

Board definitions live in the note_boards table. Adding a board, renaming a column, or reordering phases is a data change. It does not need a deploy.

Each row carries:

• slug, name, description
• tags — the membership query
• phases — the ordered columns, left to right
• position — the order boards themselves render in
• is_enabled — hide a board without deleting it
• workspace_id — NULL means the board is global; set it to scope a board to one site

The four boards above are seeded as global, which is how they have always behaved: the admin board list renders them in "All Sites" mode without scoping to a workspace.

If the table cannot be read, the boards fall back to a built-in seed list rather than rendering an empty page. An admin looking at a board screen with nothing on it would reasonably conclude their queues were gone.

The Unsorted column

A note whose phase matches no column on its board, including a note whose phase was never set, renders in an Unsorted column rather than being filtered out.

Unsorted comes first, not last. Those notes need a phase picking, and a column parked past six others on a horizontal scroll is one nobody reads. It disappears entirely when empty, so a fully classified board does not carry a permanent empty slot advertising the fact.

This is deliberate: the failure a board must never introduce is a note silently vanishing from its queue.

Sorting a board

Every column renders in the order you dragged it into. That is the right default and a poor only option: a Bugs board with forty notes in Open is unreadable unless you can ask it what is High, and "what came in this week" has no answer at all.

The Sort control in the board header offers:

Sort	Order
Manual (drag order)	The order you dragged the cards into. The default.
Priority (high first)	High, then Medium, then Low, then notes with no priority.
Date added (newest)	Most recently created first.
Date added (oldest)	Oldest first — the queue in arrival order.
Last modified (newest)	Most recently touched first.

The choice is saved per board in your browser, so Bugs sorted by priority and Content Seeds sorted by date each come back the way you left them. It is a local preference, not a property of the board: another browser or another device starts every board on Manual again, a private window forgets your choice when you close it, and nobody else sees it at any point. Under a date sort, each card shows the date it is being sorted by, so the order is legible rather than arbitrary-looking.

A note with no priority sorts below Low, not above it. Nobody having triaged it is not a claim that it matters more than something explicitly marked Low. Every sort falls back to the manual order to break a tie, so a column of equal priorities still renders in a deliberate order rather than whatever order the query returned.

Sorting is a view, not a rewrite

A sort never touches the manual order underneath. Switch back to Manual and the order you built by hand is exactly as you left it — the sort was only ever a lens over it.

That has one consequence worth knowing. While a non-manual sort is active, dragging a card still moves it between columns, and that still changes the note's phase. What it cannot do is set the card's place within a column: the sort decides that, so the card goes to the end of the manual order and then renders wherever the sort puts it. Dropping a card back into its own column under a sort does nothing at all, rather than quietly rewriting its position and bumping its timestamp for a drag that changed nothing on screen.

To reorder a column by hand, switch to Manual first.

Phase matching is tolerant, not fuzzy

Phase comparison ignores case and surrounding whitespace, so a note whose field reads **Status:** in progress still lands in the In Progress column.

It goes no further than that. In Progres is a typo you should see flagged, not one the system quietly absorbs.

A wrong phase warns, it never rejects

Writing a phase that is not a column on any board the note belongs to still succeeds. The response carries a PHASE_NOT_IN_BOARD warning naming the phase, the expected vocabulary, and the fact that the note was saved and will render under Unsorted.

Rejecting the write would mean losing the note's update over a spelling difference. Warning keeps the work and surfaces the problem.

No warning fires when the phase fits, when no phase was written, or when the note is on no board at all. A plain note carrying a phase is not a mistake.

Agents move the cards

The phase lives on the note, so the agent doing the work is the agent that updates the board. The bug fixer writes In PR when it opens a pull request. The feature builder advances a note through its own vocabulary as it goes.

Nobody grooms the board afterwards. Opening it shows the state the last run wrote.

Related

• Note Taxonomy — the tag vocabulary that decides board membership
• Sorties — how agent runs get fired in the first place