用途：log-analysis 面向只读日志分诊，不负责改代码或设计监控。当用户提供应用、API、worker、代理、容器、pod、浏览器、CI 或 JSON 日志，并想知道“哪些行重要、真正的错误是什么、级联从哪里开始”时使用。
主要能力：先把请求归一化为一个主证据包，可选 app-runtime、container-runtime、browser-plus-api、ci-cascade、structured-json、security-signal；再按时间窗、请求/追踪 ID、任务/构建 ID、会话或租户缩小证据范围；随后按硬停止、依赖/环境阻塞、请求/运行时失败、余波的顺序隔离最早可操作故障；最后把重复下游行归为一个签名或影响范围，并给出分类桶，如 missing-config-or-secret、dependency-or-connection、auth-or-permission、request-or-runtime-error、data-shape-or-validation、resource-or-capacity、browser-network-mismatch、ci-build-test-failure、security-or-suspicious-pattern、unknown-needs-more-context。
使用方式：输出默认采用 Log Triage 简报结构，包含来源、首个可操作故障、模式/影响范围、分类、可能根因、下一步只读检查、路由建议。若证据太短或从级联中段开始，应标记低置信度，并请求最早错误簇或首个阻塞点前后 20-80 行，以及一个锚点（时间窗、请求 ID、任务/构建、pod/容器或浏览器路由）。
适用场景：容器依赖失败（如 connect ECONNREFUSED redis:6379 后大量重试）、浏览器与 API 不匹配（如 401 与 JWT audience invalid）、CI 级联（如 ModuleNotFoundError 导致测试中止）、JSON webhook 日志中的 429 重试等。
限制：不用于 Unity/Unreal 构建日志（应转 game-build-log-triage）、监控可观测性设计（monitoring-observability）、已知阻塞后的复现与修复（debugging）、跨日志族的重复异常搜寻（pattern-detection）。所有建议检查保持只读，一旦工作变成调试、可观测性设计或异常搜寻就应路由出去。具体安装命令、收费与平台信息暂未提供。