/ratel-langfuse-analyze — read live traces, propose fixes

Pull aggregates and outlier traces from the Langfuse MCP server, pattern-match against the catalog of known agent failure modes, and write a findings report the customer can act on this week. Two grouped outputs: Ratel-flavored opportunities (where we'd integrate or deepen Ratel) and general low-hanging fruit (anyone could fix it).

The general findings are not filler — they're how we earn trust. A consultant who only ever recommends their own product looks like a salesperson. We're not that.

What good output looks like

A finding is good if:

1. It cites at least one trace id or a saved filter URL so the customer can verify it themselves.
2. It says what to do, not just what's wrong. Vague findings ("error rate is high") waste partner time.
3. It says why the fix matters — in one sentence the customer's PM can read.
4. It's tagged Ratel or generic. Mixing them hides the value story.
5. If it's a Ratel-flavored finding, it cites the Ratel version that solves it (today: v0.1.6 line; future: pull from ratel-observability-assessment/references/ratel-value-map.md).

A finding is bad if:

• It's a restatement of a dashboard ("p95 latency is 4.2s"). Dashboards already show that.
• It uses qualifiers like "could potentially be improved" or "may be worth investigating". Either it's a finding or it isn't.
• It's invented to fill space.