用途：把 Java 服务升级到其技术栈支持的最新 Java LTS（目标为最新 LTS，例如 Java 25；仅当依赖阻塞时才回退到 21 或 17），同时完成必要的框架升级，并以容器形式运行在目标平台（ECS/EKS 或用户指定平台），若已容器化则只更新基础镜像。拆解属延伸目标，由 AI-DLC 工作流单独处理。区域、平台与工具在 AI-DLC 工作流的“环境、区域与工具”章节中发现和决定。
主要能力：第一阶段评估（棕地先行）——检测构建工具（Maven/Gradle）、当前 JDK 目标、模块布局、框架与库版本；确定框架当前支持的最高 LTS；盘点 Java 版本风险面；判断容器化状态与部署模型；度量代码规模（LOC、模块数、依赖形态，如 jdeps 扇入/扇出）以决定执行策略；采集行为基线；发现环境/区域/工具。
升级工具：先解决工具门禁——是否允许托管转换服务（如 AWS Transform）。若允许且用户选择则使用；若不可用/未批准，则按 references/prescriptive-language-native-upgrade.md 的分组、原子、顺序正确、每组构建通过的路径执行（构建系统就绪 → Jakarta 迁移 → 数据库/ORM → 核心依赖 → Spring 生态 → 最终集成）。默认使用语言原生工具：OpenRewrite 应用目标 LTS 的最新 UpgradeToJava 配方（如 UpgradeToJava25，或回退时的 21/17 配方，必要时以 11/17/21 作为中间基线），以及框架配方（如 Spring Boot 2→3、javax→jakarta）；jdeps 分析内部/已移除 JDK API 的依赖与模块边界；jdeprscan 扫描废弃/移除 API；升级 Maven/Gradle JDK 工具链与编译器 release，并清除已知 CVE。
规模策略：小型（约 5 万行以下、模块少）一次性执行并单个 PR；中型（约 5 万至 20 万行）按组构建、测试并提交，PR 按组/层拆分；大型（约 20 万行以上或模块众多）按依赖顺序分波，禁止一次性执行。每波重复完整组序列，通过构建与测试、回归比对、本地运行时检查后各自合并 PR；优先基础/共享模块（高扇入），叶子应用最后；独立模块可并行分支，涉及共享模块需串行；波次顺序依据 jdeps 依赖图，高风险模块单独成波。
容器化：若已容器化则跳过新 Dockerfile，仅更新基础镜像并重新验证。基础镜像为目标 LTS 的受支持 JDK 运行时镜像（如 Amazon Corretto 25 或 distroless Java 镜像），多阶段构建、非 root 用户；配置外置，密钥经托管密钥存储（如 SSM Parameter Store/Secrets Manager）运行时注入；计算目标决策门（ECS Fargate 或 EKS，经 AWS Knowledge MCP 验证区域可用性）；IaC 决策门（Terraform vs CloudFormation 等）；区域按用户目标/允许区域部署，如不可用则应用回退门。
回归安全网：合并前证明行为对等，使用 regression-testing 技能构建行为优先的套件，有 Web/UI 界面时使用 web-test-automation，并接入 CI/CD 流水线。
完成定义：服务在目标 LTS 上编译且全部测试通过；框架按要求升级且行为对等；在目标区域通过所选 IaC 以容器运行于所选平台（仅未容器化时才编排容器化）；变更以 PR/MR 提交并通过 CI/CD 验证并关联需求；所有决策记录于 aidlc-docs/audit.md。
限制：拆解不在主要目标内；涉及托管转换服务、区域可用性、平台与 IaC 工具均需按门禁确认；文档未提供具体命令、价格或效果数据。