Clients and the work on them, in one table.

A client is an issue of its own type, so it comes with comments, files, history, watchers — and the same API and MCP as everything else. The work on a client is its children: open the row and it is underneath; on the board it gathers under the client’s card.

Mini, because it is a table of clients with the work under each one — not a sales system with a deal pipeline, follow-up reminders or an email history.

The project writes down the columns it needs, of six kinds: a list with colours, a country, a number, a date, a person, a line of text. A value that does not fit its column is refused on the spot, never quietly dropped.

The same columns are on the client’s card — in a line, or as a two-column table when there are a dozen of them — and an empty one still has its row, because an empty field is exactly what somebody opens the card to fill.

The name, the owner, the status and every column of your own change right in the table. It is the same write the card makes, so history, notifications and your agents all see it.

A client gathers work of several kinds at once — onboarding, legal, support. Tag it, and one tag narrows the list; with nothing chosen the list can be grouped by tag. In the table, choosing a tag opens every client that has such work and hides the rest.

One .xlsx with your columns in your order — the whole book, not the page on the screen. A number stays a number and a date stays a date, which a CSV opened in a spreadsheet never promises.

Over MCP an assistant can do everything a project lead can with the book: list and change its columns, and fill them in on a client by name. The rules are the same ones the table keeps, so a value the table refuses is refused to the assistant too.