While testing the CLI end-to-end, traceroot traces get <id> works fine, but the experience feels like it could be improved. Capturing two related observations here — not proposing a specific solution yet, just flagging that today's behavior leaves value on the table.
Priority: P2
1. traces get sits awkwardly between "too little" and "redundant with export".
The two commands have different jobs:
traces export is the full dump — complete trace + span information, meant for a coding agent (or tooling) to consume.traces get is supposed to be the lightweight overview — for a human, and more importantly for a coding agent.
Right now get leans too far toward "too little": it renders just the skeleton of the trace structure (span names + status), without enough span-level information to be genuinely useful. But the opposite extreme isn't right either — if we dump all span info into get, it just becomes export (and a worse version of it).
So there's a middle ground to find: more than the bare skeleton, less than the full export. Worth figuring out what that right level of detail is.
2. The "View in TraceRoot" link is great — maybe we can go further.
The printed UI link at the bottom of get is genuinely useful. A natural extension: let get open the expanded trace directly in the UI rather than just printing the URL.
These two are loosely related (both about making get more useful), so grouping them into one issue for now. No concrete proposal yet — this is a "let's revisit and figure out the right direction" item.
While testing the CLI end-to-end,
traceroot traces get <id>works fine, but the experience feels like it could be improved. Capturing two related observations here — not proposing a specific solution yet, just flagging that today's behavior leaves value on the table.Priority: P2
1.
traces getsits awkwardly between "too little" and "redundant with export".The two commands have different jobs:
traces exportis the full dump — complete trace + span information, meant for a coding agent (or tooling) to consume.traces getis supposed to be the lightweight overview — for a human, and more importantly for a coding agent.Right now
getleans too far toward "too little": it renders just the skeleton of the trace structure (span names + status), without enough span-level information to be genuinely useful. But the opposite extreme isn't right either — if we dump all span info intoget, it just becomesexport(and a worse version of it).So there's a middle ground to find: more than the bare skeleton, less than the full export. Worth figuring out what that right level of detail is.
2. The "View in TraceRoot" link is great — maybe we can go further.
The printed UI link at the bottom of
getis genuinely useful. A natural extension: letgetopen the expanded trace directly in the UI rather than just printing the URL.These two are loosely related (both about making
getmore useful), so grouping them into one issue for now. No concrete proposal yet — this is a "let's revisit and figure out the right direction" item.