dsh-jvm-doctor

生产 JVM 故障排查时，证据往往已经躺在剪贴板里：一段 jstack、一坨 GC 日志、Maven 或 Gradle 的 dependency:tree、一条 Caused by 链、两份 application.yml。模型要么想再去 attach 采集——生产里常常不允许——要么只能对着几百行文本「心算」死锁环和依赖冲突，还容易把「没看懂」当成「一切正常」。dsh-jvm-doctor 只做一件事：把到手文本变成结构化事实，并且每次调用都带上解析覆盖率与诚实回执，让「没有异常」和「解析失败」永远不会混在一起。

插件向模型注册五个纯函数工具：java_thread_dump 做线程普查与 Java 级死锁环（waiting_for / holding 链）；java_gc_log 汇总停顿与 p50/p90/p99，并兼容统一日志与旧式 GC 行；java_dependency_conflicts 理清多版本与 omitted for conflict；java_stack_trace 解析异常链并尽量还原 ... N more；spring_config_diff 对比展平后的配置，敏感键值在进载荷前就掩码。它不采集、不读盘、不联网、不碰运行中的 JVM——同样的粘贴永远得到同样的输出，超预算会明确拒绝或逐条报出省略条数，不认识的行计入 unknown_lines 并下调 confidence。

适合在事故复盘、值班协助和代码审查场景里，已经有人从日志或构建输出里复制了材料，希望模型帮忙归纳线程状态、GC 停顿、依赖冲突、根因帧或配置差异，但又不能或不愿在生产环境执行 jcmd、attach 或任意脚本的团队。工具只陈述可核对的事实，不做因果推断；覆盖率低于 1 时，应把 confidence 与 unknown_samples 当作答案的一部分。

若你需要的是现场采数、JMX 或跨会话的调用统计，这不是本插件的职责；若你手里已有文本、想要可复现、可审计的结构化解读，它正好补模型「只会读长文」的那一块短板。