What ran, how it went, what it returned
A run is mostly a list of these. So the collapsed header carries everything needed to skim it (the tool, the target, the outcome, the time), and the body carries everything needed to audit it.
Statuses
The container stays neutral, so a long run reads as a list rather than a wall of tinted cards. The status word and its icon carry the state; the border never changes.
Arguments and result
Pass the call's detail as children and the header becomes a disclosure. With nothing to disclose it renders as a plain row instead: a row that cannot open should not look pressable.
{
"path": "src/tokens/tokens-light.css",
"pattern": "--color-status-"
}Waiting on a person
Approval controls render outside the collapsible panel. Someone deciding whether to allow a write should not have to expand the call to find the button, and someone who wants to check the arguments first can still open it.
{
"path": "src/components/Button/Button.tsx",
"bytes": 4182
}A live run
The log surface is a composition, not a component: tool call is the line, and an ordinary list is the container. Play the run and the calls appear in order, each running briefly before it settles.