dash: the per-request component row has no events column, so successes vanished from it

[amiddavid]

Found by live verification of #118.

Splitting Report.Gates into Gates and Events (#121) reached /stats and Prometheus but not the dashboard's per-request surface:

• dash/event.go:504 — row.Gates = r.Gates, with no events counterpart.
• dash/schema.go:585 — the component row has only a gates column.

So sweep_dropped, sweep_offered, sweep_candidate_at_depth, reapplied_same_session and the other seven migrated names are absent from the per-request component row — which is the surface docs/hosted.md points operators to for "what did this component do on this request".

The aggregate views are fine: /stats carries both maps and Prometheus exports cg_component_events_total{component,event}. It is the per-request drill-down that lost them, and that is the one used to explain a single turn.

Why this is worse for the components that work

The names that moved are the ones a component raises when it succeeds. So the drill-down is now blind in proportion to how well a component is doing: a turn that removed twelve outputs and saved 33,340 tokens shows an empty gates cell, while a turn that refused everything shows a full one. Verified live during #118's re-verification.

The sibling defect on the log line (apply.logDecisions rendering only rep.Gates) is fixed in #118 — same root cause, and that one was three lines. This one is not: it needs a column, a schema migration, the API shape, and the UI, so it was flagged rather than bundled into an unrelated PR.

Worth deciding while you are there

Whether the row keeps two columns or one with a type discriminator. Two columns matches /stats and Prometheus and keeps the two questions visibly separate, which is the whole reason for the split; one column plus a flag is a smaller migration but re-creates the ambiguity at the storage layer that #121 removed at the metrics layer.

[amiddavid]

Fixed in 35cbbd5 on #118, end to end rather than just the column.

• Schema: an additive events column on request_components, with a default so an existing database keeps serving. Pre-migration rows read as '' and render unknown, not "did nothing" — the distinction the gates column's own comment records getting wrong once.
• FromTrace: carries r.Events across.
• Store and per-request read: insert and scan the new column.
• Windowed aggregate: a second json_each query over c.events, so the components table totals them too. A separate query rather than a UNION with a discriminator, because merging them there would undo at the API what the column split did at the storage layer.
• UI: activitySummary renders both, events first — "what happened" is the question a reader opens that cell with, and declines answer "why did nothing happen", which only matters once the first is empty.

On your open question — two columns or one with a discriminator — I took two columns, for the reason above. In the UI it is one cell rather than a new column: that column is deliberately unsortable (null in COMPONENT_SORT) and a second would have to be threaded through that array and both header rows for nothing a reader can use. The two stay labelled and on separate lines, so a success is never read as a refusal. gateSummary is deleted rather than left unused.

Worth recording, because it is the lesson rather than the diff. My first store round-trip test passed with row.Events = r.Events removed — it builds CompRow values directly, so it never exercised the Report-to-row mapping where the drop happened. That is the sixth vacuous check this component family has produced, and the first I wrote myself. TestFromTraceCarriesComponentEvents starts from a components.Report instead and fails with map[] when that line goes; the storage half is verified separately by not persisting the column. Both quoted in the commit.

The generalisable bit: start the fixture upstream of the seam you are testing. A test that begins downstream of the defect verifies the plumbing it kept.