Listing and enumeration
Search answers "where is the thing I am thinking of?". Listing answers a different question — "what is there?" — and the two are not interchangeable. An auditor sampling a population, or anyone asking whether a set is complete, needs the second.
/list is that view.
Filters
Combine any of them:
| Filter | Selects |
|---|---|
| free text | Full-text match, as in search |
| class | Object, Action, Event, Document, Type |
tag | Everything carrying a tag — done, major, reference |
code | Items holding a given code |
under | Everything beneath a subtree |
since / until | Written in a date range |
sort, desc | Order, and its direction |
Always a total
Every listing reports how many there are, not just how many are shown: showing 21–40 of 317.
This matters more than it looks. A list of nine with no denominator is indistinguishable from the first nine of three hundred — and a reader who assumes the former when the latter is true has drawn a conclusion about a population from a page of it.
The total is counted after access filtering, so it is what you may see rather than what exists. Two different users can honestly see two different totals, and each number is correct for the person reading it. See access control.
Drift, since a date
since turns the listing into a change report. Set it to the date of an opening
meeting and you get everything written to the scope after that point — which is the
question "did the record move while I was reading it?", asked in the one form that
can be answered.
Getting it out
CSV exports the current filter set, up to 1000 rows, with a provenance header naming
the database, the filter and the time. Whatever the screen shows, the file shows —
including the total.
The same enumeration is available on the REST API as
GET /api/list, paginated with X-Total-Count, and to an AI assistant through the
MCP endpoint as the list tool.