#2674·a2ui

No tabular or quantitative display primitive in the basic catalog

Author: shellenCreated Sep 16, 2026Updated Sep 18, 2026
LabelsP2type: feature/enhancementstatus: first-line-handled

Summary

Nothing in the basic catalog expresses tabular or quantitative data. Agents summarizing anything numeric — spend by month, comparison matrices, search results sharing columns — have to emit prose or a hand-aligned Row/Column grid.

This overlaps with the "missing controls" observation in #871 (which raises grid/charts among others), but that issue is a broader strategy question about extensibility. This one is narrower: a concrete request for a tabular primitive, plus a request for an explicit decision on quantitative display before v1.0.

Current workaround

A two-column receipt can be approximated with one Row justify=spaceBetween per line, label on the left and value on the right. That works for label/value pairs and falls apart immediately at three or more columns: there's no column alignment, no shared widths, no header semantics, and no way for a renderer to make it responsive or scrollable.

Proposed shape

json
{
  "id": "spend",
  "component": "Table",
  "columns": [
    { "key": "month", "label": "Month" },
    { "key": "total", "label": "Total", "align": "end" }
  ],
  "rows": { "path": "/report/months" }
}

Binding rows to a data path (rather than inlining components per cell) keeps tables cheap on the wire and lets the data model update rows without re-sending structure — which seems aligned with how the rest of the catalog separates structure from data.

On charts

Charts are a bigger conversation and may well belong in an optional catalog rather than basic — rendering them portably is a genuinely hard problem, and I'm not arguing they must ship. But the absence of any quantitative primitive is worth raising explicitly before v1.0 freezes, if only to get an intentional "no, use a custom catalog" on the record rather than leaving it an open question each implementer rediscovers.