log-triagelisted

# OmniLLM Log Triage & Improvement Goal: turn correlated runtime evidence from OmniLLM and Claude Code into actionable findings and, when requested, verified code improvements, while separating OmniLLM defects from client, plugin, configuration, and environment issues. ## 1. Gather evidence Unless the user gives another window, inspect the **past 2 days**. Apply the time filter before counting or sampling so older incidents do not distort the result. Report the requested window and the actual timestamp range present in each log. ### OmniLLM logs Primary sources: - `~/.omnillm/omnillm.log` and rotated `omnillm.log.*` - `.omni-dev.log` in the repository root The OmniLLM log is JSON-lines (zerolog). Key fields: `level`, `request_id`, `api_shape`, `model_requested`, `model_used`, `provider`, `stop_reason`, `stream`, `input_tokens`, `output_tokens`, `latency_ms`, `status`, `path`, `message`, and the timestamp field (`time` or `timestamp`). Filter JSON entries to the window first, then run these passes over the filtered data: 1. Non-info levels (`warn`, `error`, `fatal`, `panic`). 2. HTTP failures grouped by status and path. 3. Failures grouped by provider, requested model, and message. 4. Latency and time-to-first-token outliers. 5. Request IDs with an initial request but no terminal response; exclude completed retries and expected stream cancellations. 6. Token/context anomalies such as near-limit input or zero output. 7. Repeated retry, timeout, serialization, upstream-