v0.16.0

Listings are board rows; the body is the detail pane's

A board view used to deliver every card's full description — 76–84% of a day-view payload, unused by row rendering — and agents reading a board over MCP paid the same tax at board scale. Listings now come as the board row: title, team, zone, assignees, progress, stage, dates, plus the link refs extracted from the description server-side (status.links, capped at 50), so the row's links indicator works without the body. The description always was, and remains, resolved by its own endpoints: GET /cards/{uid} / get_card for the body, /links for resolved link titles, /log for the feed.

fields=full (REST) / full=true (MCP) opts genuine bulk readers into complete cards. This is a breaking change for API/MCP consumers that read descriptions from listings — pass the flag. The new title= substring filter on list_cards resolves a card someone mentioned by name to its uid in one cheap call.

Day views measured on the production board: me 103→33 KB, team 426→80 KB, view=all 2543→1124 KB.

Hardened by independent review

The branch went through two adversarial reviews before merge; everything they found is fixed in this release, most notably: editing a description is now gated on its body having actually loaded (previously a fast Save on a just-opened card could write "" over the real text), a full Card resource always carries spec.description — present even when empty — so "not loaded" is unambiguous, the detail dialog keeps a dirty draft safe from background refreshes, a failed body fetch retries on re-select, and a description edit refreshes the row's links icon immediately.

SPA tabs from older releases show empty description panes until reloaded — the deploy restart logs everyone out, so the reload happens on next sign-in.