用途：评估 OpenTelemetry 生态中的依赖包与 Collector 升级，在可用仓库证据支持下找到最高稳定目标版本，并给出针对具体项目的升级建议。除非用户要求实施，否则只评估、不修改项目文件。
主要能力与流程：先检查仓库与运行时证据，再选择工作流。依赖升级关注包清单、锁文件、API、SDK、插桩库、导出器、插件与依赖约束；Collector 升级关注二进制、镜像、Chart、Operator、配置、feature gate、组件、OCB manifest、构建与运行时行为。涉及独立版本或第三方模块的自定义 Collector 时，先走 Collector 流程，再看依赖流程中的模块约束。跨两个面时两者都读。
版本判断：明确当前与候选版本，分别记录包装器、发行版、制品与内嵌依赖；查询权威注册表与带标签的上游主源获取当前稳定版本并记录查询日期；预发布标记（RC、beta/alpha、nightly、无标签源码）除非该包线刻意如此，否则视为预发布，不得把项目的实验包线悄悄换成其他线的稳定包；无稳定版满足需求时单独评估预发布并明确标注。区分“最新稳定版”与“已验证兼容的最高版本”。
验证与限制：在临时副本、worktree 或隔离环境中验证，保护用户工作树；从最新稳定候选开始，失败时诊断并测试较低版本，不假设兼容性单调。把上游变更与仓库实际用法及下游契约关联，不可用的消费者、环境和精确版本覆盖视为未验证。优先使用可用的专用技能，否则用上游主源与仓库证据并报告验证缺口。依赖解析、编译、配置接受、测试通过各自证明力有限，需说明其结果能证明什么。
报告结构：Recommendation（升级建议及证据、工作量、风险）、Relevant Findings、Proposed Upgrade Path（最小协调的依赖、制品、代码、配置与上线变更序列）、Validation（候选、制品、配置、平台、检查及结果）、Remaining Risk（无法验证的重要项，无则省略）。上游结论需链接权威发行说明、文档或源码；最新版与已验证最高兼容版不同时两者都列出并说明阻塞原因。
适用场景：多生态项目的 OpenTelemetry 升级评估、Collector 与依赖协调升级、兼容性风险判断。限制：默认不执行改动；未提供具体版本、包线或生态则无法给出确定建议；验证结果受临时环境与可运行检查范围约束。