`findings get` buries the RCA in raw text, hides the detector's classification, and dead-ends the workflow

[dark-sorceror]

Summary

findings get is the payoff command of the detector feature, and its human output falls short three ways:

1. The RCA body renders as one raw, unwrapped blob. The CLI prints rca.result verbatim (src/commands/findings/get.ts:102-112): no width wrapping, markdown (## Findings, **Root cause:**, backticks) printed literally, and — on real data — the first several hundred characters are analysis narration with sentences fused together (e.g. …this trace.git_repo is null. Let me examine the error spans.The failing_tool span…). The fused text is partly an upstream data problem, but the CLI displays it as-is and adds nothing.
2. The human view drops the detector's actual classification. --json carries results[0].data = {"category": "Tool call error"} and results[0].identified = true, but the human output shows only Category: Failure — the detector template label (categoryLabel(result.template) at src/commands/findings/get.ts:95), not what the detector concluded. Human and JSON views disagree on what "Category" means.
3. The command is a workflow dead end. traces get ends with View in TraceRoot: <url>; findings get ends at the RCA blob — no UI link, no next-step hint (traceroot traces get <trace-id> / traces export), in exactly the command where "what next" matters most.

How to replicate

1. traceroot findings get <finding-id> on a finding with a completed RCA.
2. The RCA: section opens with narration, prints markdown markers literally, and emits paragraph lines hundreds of columns wide.
3. The detector block shows only the template label; compare --json | jq '.results[0]' → {"data": {...}, "identified": true, ...}, none of which appears in the human output.
4. The output ends after the RCA — no URL, no suggested follow-up command.

Root cause (confirmed)

All in renderFinding (src/commands/findings/get.ts:72-115):

• Lines 105-109 split finding.rca.result on \n and push each line as-is — no wrapping or markdown handling.
• Line 95 prints the hardcoded template→label map; result.data and result.identified (DetectorResultItem, src/api/generated/schema.ts:264-277) are never rendered (a comment at lines 84-86 says they deliberately stay JSON-only).
• renderFinding returns after the RCA block. FindingDetail carries trace_id but no trace_url, so a UI link needs either the backend to provide one or a printed traceroot traces get <trace-id> hint as the bridge.

Impact

• The most valuable artifact the product produces — the root-cause analysis — is the least readable thing the CLI prints.
• Category: Failure looks like the detector's verdict but is the template name; the real classification is invisible outside --json.
• The cross-linking loop that traces get starts (its finding block points to findings get) never closes — there is no path onward.

Acceptance criteria

• The RCA body is wrapped to terminal width (non-TTY/--json unaffected) with minimal markdown treatment: headings/bold styled or stripped, never printed as literal ##/**.
• The human output surfaces each result's identified flag and data payload (e.g. Category: Tool call error (template: failure)).
• The output ends with a trace UI link (backend-provided) and next-step hints (traceroot traces get <trace-id>, traceroot traces export <trace-id>).
• --json output is unchanged.
• Rendering tests cover: long unwrapped paragraphs, markdown headings, a result with a data payload, and the link/hint footer.