Individual calls, for the one question every xenia_report view raises and cannot answer: which call was that. A 'tools' row reporting a 33KB maximum does not say which call returned it, and one signature covering six journalctl runs is one row on purpose. Deliberately thin — action id, time, tool, status, duration, reply size and a short command, and nothing that repeats identically down the rows. Defaults to the heaviest replies first; pass the 'signature' or 'tool' from a report row to drill into it, and the 'action_id' it returns to xenia_trace. 'detail' is cut to 120 characters so a page of rows stays readable — xenia_trace on the same action id is where the whole command is, for any call and not only a failed one.

How coding agents have been getting on with their work on this machine. One record, six views of it — choose what a row should be with 'view':

tasks one unit of work an agent named for itself, and whether it got there: achieved, partial, failed, abandoned or no_action. The outcome is read off the calls made under the task, never off the agent's claim about it; where the two disagree 'overstated' is 1 and 'declared' is what the agent said. Start here. instructions the same question one level up: one thing the user asked for, and how it turned out. The only view that carries whole prompts, which is why the rest carry a 'goal_id' — pass one back as 'goal_id' for the full text of that instruction. failures one kind of work that keeps failing, worst first, grouped across sessions. 'repos' names the checkouts it failed in, because that is where a fix goes; 'previously' is the same count over the window before this one, so a row failing 8 times against 0 is new and one against 12 is already getting better. 'recovered' is how often a later call put it right; many failures and few recoveries is a gap in the environment or the instructions, and the most actionable row here. Refusals split by who did the refusing: 'refused_by_rule' is a hook or a permission rule, and the reason is in 'example_error' — a config or code fix; 'declined_by_user' is a person saying no at the prompt, which is not yours to change. Pass 'example_action_id' to xenia_trace. repeats one piece of work a session did again minutes after it had already succeeded. This is the waste 'failures' cannot show, since none of it failed. Cost it in 'repeated_bytes' rather than 'repeated_ms': redoing work is rarely slow, but every repeat puts its whole reply back into a context. tools one tool, broker, host, repo or signature, with calls, failure rate, latency and reply bytes. Ask this rather than totalling rows yourself; order by 'total_bytes' for what floods a context rather than what takes time. disk one file (or repo, tool, session) with what was written to it, how often it was rewritten, and how much of that hashed to what was already there — 'unchanged' is bytes that reached the drive and changed nothing.

Rows come back under 'rows'. The tasks view also returns 'instructions', the text of each instruction its rows sat under, keyed by 'goal_id' — one entry per instruction rather than the same sentence repeated down every row. 'since', 'repo' and 'limit' apply to every view; each other parameter names the views that read it, and passing one to a view that does not is an error rather than a filter that quietly does nothing. For the individual calls behind any row, take its 'signature' to xenia_calls.

One action, the task it was working towards, its outcome, and — when a later action fixed it — every action in between, from that one session. This is how a failure was actually recovered from. A fix in a later session gives the two endpoints only: the work between them belongs to two sessions and threading it into one list by clock time would not be a reading of anything. Takes ANY action id, not only a failed one: it is also the way to read one call's arguments in full, since xenia_calls shortens them to keep its rows scannable and a recovery series is simply absent when there was nothing to recover from.