[Mucheen]

阶段 D 把 Maven 的任务、配置、测试与运行事实交给 Provider，宿主保留编排、存储及进程生命周期。本 PR 仍为 Draft，不关闭 #1495。针对 review 5715250513 已修正下列边界；工具链消费及 Core Maven 运行配置所有权仍未收尾，尚不适合标记 Ready。

本轮 review 修正

• v7 原生配置由提供者解释及编辑。 删除 XML root/path 绑定和 Core XML 编辑器。宿主分配私有空暂存文件，提供者校验原始版本并写入替换内容，只返回来源、SHA-256 和 changed 回执。宿主校验文件身份、大小、哈希、权限及版本，保留元数据原子替换，再向同一提供者回读；失败、取消和迟到结果清理暂存，不把原始文档或秘密放进 RPC。macOS 与 Windows native/前端接口同步。JSON SDK 示例与 Maven XML 编辑分别验证格式所有权。
• v8 直接消费通用报告。 macOS 使用 BuildTestResults，删除 Maven 报告类型、转换及通用 UI 中的 Surefire 文本解析。保留规范摘要、调用次数、耗时、来源位置和不透明重跑引用；源码发现只通过显式关联匹配，未关联用例仍显示，同名测试按提供者分别留存。Windows 旧 Java 行标记消费者保留字段别名。
• 准备任务由插件声明。 buildSystems 4 用 preparation.purpose/sourceRoles 描述用途与源码角色，宿主按当前模型中唯一的最深工程和任务选择，拒绝工程或角色歧义；不再硬编码 java-prepare-run-main/test。声明变化进入安装权限审查。
• 自动运行配置使用通用选择器。 macOS 按当前插件声明和模型目标生成 build.provider + extensions.build，独立于 Java 导入；Core 删除 mavenRunProvider 字段、Maven 服务投影和默认项的框架名单。选择器决定稳定 ID，模型顺序不改变结果；名称/执行类型变化保留参数、环境和目录覆盖，目标撤回不从旧缓存复活。单独记录完整快照指纹并刷新过期提示；准备仍重查当前目标。宿主提前限制声明/目标组合，避免展开超限清单。旧 application 保存引用保持协议 4 兼容。
• v11 改走 DebugAdapter Registry。 删除本入口的 runtime:jvm 和内置 Java attach。服务运行声明公开 configurationType；宿主选定当前注册适配器，发送 adapterID/configurationType 与 loopback connection 目标，并在模型准备、进程启动、监听等待和 attach 前验证包与注册代次。保存的通用 Provider 服务引用可使用此流程，无语言导入需求时不强制启动 JDT。
• 语言服务器仍归同包。 Java Support 自己声明 attach 适配器，由自己的 JDT 托管；Maven 仅引用公开配置类型。复用现有 startArguments、适配器传输及进程清理。官方插件元数据检查补齐 API 4 和 requires 的保留，Java 自动发布仍暂停。
• 迁移删除窗口明确。 D-MIGRATION-REMOVAL 只保留首个含迁移器的稳定版 N 与 N+1，在 N+2 发布前删除迁移器、唯一调用入口、测试及回执；尚未发行，不编造实际版本号。
• Node/Java SDK 仅重写未发布的 7、11，保留 8–10 及原有 handler。契约镜像只在宿主合入后按最终 preview commit 同步，正式 SDK lock、下载 URL 与校验值未改。

已接入的生产范围

• 原生 Build 与 Agent 共用实例、任务、输出、状态及停止；删除 macOS MavenService/MavenFeatureModel、旧任务进程、旧配置副本、文本依赖树及路径 fallback。
• Build 模型提供 Run 标签、模块搜索、源码根、依赖导航与语言导入。团队/本机实例选项、重置、冲突、回读和一次性迁移保持所有权；同步当前配置、失败和取消不保留影子值。
• 精确测试使用 JDT 原样标识及不透明选择器，Maven 负责执行与 Surefire/Failsafe 报告。覆盖参数化、Unicode、同名包/模块、失败/缺失/损坏报告、清理过时项和精确重跑。
• typed Run 选项保持 runtime/application argv、环境、入口和 cwd 的独立边界；service/task 的保存引用保留类型与身份。Provider 调用、原生主 Run、独立服务和 Start All 复用既有操作身份、输出、停止及撤销机制。
• Maven 后端使用真实 reactor、workspace reader、执行计划及 Mojo 描述符准备框架运行，保留 Profile、工具与参数。资源准备复用公开任务；JDT 拥有 Java 构建、classpath 和入口，不在宿主重建上游模型。

本轮验证

• v7/通用报告/准备任务：Core 1436 项、macOS 246 项通过；Maven XML 编辑与配置工作流 12 步、Node/Java SDK E2E 6 项通过。
• v11：macOS 192 项、Windows 前端 62 项及类型检查/生产构建、Node 构建协议 26 项、Java SDK 49 项通过。
• 最新 Core 全量 1437 项通过；补齐 Java Support 项目模板的宿主能力夹具。末尾生成排序与显式目录覆盖另有 3 项定向计时通过；macOS 280 项回归通过，其中真实 Maven 模型经生产桥接生成通用配置、Profile 变更/恢复及包清单/会话清理为 11.215 秒。生产 Core 输出及非空通用覆盖通过 Run v2 JSON Schema，缓存命令/工具绑定仍被拒绝。
• 最新开发包：真实 Core→Maven 20 步通过；Quarkus 3.15.5、Micronaut Maven Plugin 4.7.2 的暂停/JDI/恢复/HTTP/清理 4 步通过；macOS 生产存储写回、回读及外部冲突通过（7.354 秒）。包文件清单不变。
• 共享契约、Core 注释、服务/Windows 边界、运行时 bundle 只读、Agent Notes、222 项功能矩阵、i18n 与官方插件元数据检查通过。计数有重叠，不合计为新增覆盖数。
• Windows native 配置 crate 的 55 项通过、4 个既有 watcher 失败；macOS 上 Tauri 检查仍受既有 Windows API 引用限制。未运行 Windows 产品或完整断点 UI，不以跨平台前端测试代替。

仍待完成及合并顺序

1. 等 #1581 合并后，接入其重写后的 toolDefinitions/toolchainProviders 与四层选择契约；旧 toolchainSources 方案已撤回。删除本 PR 新增的 project-maven/project-maven-jdk 注册及按名字选择。2026-11-01 核实 feat(plugins): 插件注入的工具链框架与 macOS 只读环境设置页 #1581 已 Ready、尚未合并。
2. 自动生成已改为通用 provider:build.provider + extensions.build，删除 mavenRunProvider 与框架投影；继续删除 Core Maven profile/reactor 的稳定解析字段及 project_ownership 中 reactor/Wrapper/版本元数据。旧保存配置的 ID、领域选项和工具覆盖仍需一次性迁移，不能将旧框架配置直接视为新引用；v11 完整生产切换仍依赖此项。
3. Windows 生产消费者、Agent/Java 准备、旧数据迁移、目标树 Debug 与实际 Windows/安装包验收；未完成时保持 Provider 产品准入关闭。普通 Java/JDT 完整后端迁移属于阶段 E。
4. 宿主修正合并后同步公开契约，依次处理 SDK Draft #5、Maven Draft #8，再验证最低运行时与真实发行组合。当前本地验证不代替正式 SDK 发布或插件包验收。

详细删除账本与依赖见 docs/development/issue-1495-plugin-migration-remaining-plan.md；本 PR 不自动合并、标记 Ready 或发布。

[xiaoyumuxi]

构建工具的 API 都 7 版本了么，记得同步 docs 仓库里面的开发文档呀

[xiaoyumuxi]

需要修改：Maven 迁移必须只用已有的通用 API，宿主/Core 不能内置 Maven 或 JVM 逻辑

#1495 的目标是把 Maven 从宿主迁成插件。现在的实现一边迁出去，一边又在宿主和 Core 里加了新的 Maven/Java 专属路径，和插件化的方向相反。原则是：插件只能使用已有的通用 API；通用 API 不够时，按通用方式扩展契约（不出现针对某个运行时或工具的枚举）；宿主和 Core 里不得有按工具名写的实现或特判。

各协议版本的结论

版本 / 新增项	结论	理由
v7 原生配置（build.configurationPlan、lithe/build/configuration、litheBuildConfiguration、Core 的 build.editConfigurationDocument）	驳回	字段绑定写死了 XML，Core 内置了 XML 编辑器，实际上只适用于 Maven 的 settings.xml。见第 4 点
v8 内联测试报告（results.decoder: "provider"、litheTestResults、coverage）	通过	格式统一，去掉了宿主解析 Surefire 报告的依赖。条件是宿主直接使用 litheTestResults，不转成 MavenTestResults（见第 3 点）
v9 不透明测试选择器（selectorKinds、selectors）	通过	宿主只转发、不解析，适用于任何工具
v10 类型化运行选项（execution: application/service/task、launchOptions）	通过	参数、环境变量、入口、工作目录都是通用的，entrypoint 是不透明字符串
v11 JVM 服务调试（launchOptions.debug: { runtime: "jvm", port }）	驳回	针对某个运行时的枚举，并且接到宿主内置的 Java attach 上。见第 1 点
executableResolution 2（{ kind: "toolchain", toolchainID } 候选）	部分驳回	候选指向宿主内置注册的 project-maven/project-maven-jdk。可执行文件和它用的 JDK 要由插件在清单里声明，宿主按声明解析。环境版本管理要等 #1581 合入后再适配。见第 2 点
Java 构建准备任务约定（java-prepare-run-main/java-prepare-run-test）	驳回或改写	宿主约定固定任务 ID，等于宿主里的 Java 工作流按名字调用插件。改成由提供者在清单里声明任务为哪类准备服务，宿主按声明查找。见第 5 点

v7 和 v11 重新设计后，请确认 v8～v10 的版本号是否需要重排，并同步说明对 Lithe-IDEA/lithe-plugin-docs#5 里 SDK 代码的影响。

1. JVM 服务调试（buildProviders 11）要改走 debugAdapters 和 connection attach

• 契约里的 launchOptions.debug: { "runtime": "jvm", "port" } 是针对某个运行时的枚举。协议 3 起只增不改，一旦发布就去不掉。
• 宿主准备好服务后调用 resolveJavaAttach(host:port:)，生成写死了 adapterProviderID: "java" 的配置（AppModel+BuildProviderDebugging.swift、DebugLaunchConfigurationResolver.swift），走的是宿主内置的 Java 调试路径，没有经过插件注册的适配器。
• 已有的通用能力完全能覆盖这个场景：API 4 的 debugAdapters 支持 attach，用 targetBindings.connection 绑定端点，java-debug 的 hostName/port 就是契约里的示例；JDT 的 Java Debug Server 可以用 tcpLanguageServer 声明。
• 期望的做法：调试选项声明 attach 用哪个适配器（适配器 ID 或 configurationType），不写运行时种类；宿主选好端口，让提供者以监听模式启动进程，然后用 { kind: "connection", host: "127.0.0.1", port } 目标交给 debugAdapters 注册表去 attach。这样 Node 的 --inspect、debugpy、dlv 以后可以直接复用。

2. 宿主/Core 不得写死 project-maven 和 project-maven-jdk

• RunService.swift（两处）、AppModel+JavaBuildPreparation.swift 调用 buildProviderHints(..., toolchain: "project-maven", ...)；RunToolchainProviders.swift 新增了 project-maven-jdk；契约里也写着 “Maven declares project-maven-jdk”。
• 构建工具和它用的 JDK 应该由插件在清单里声明（invocation、executableResolution 候选），宿主按声明解析，不按名字取值。
• 环境版本管理请等 #1581 合入后再适配。 #1581 新增通用的声明式 toolchainSources，统一处理版本管理器（mise 等）安装的运行时和项目版本文件，JDK 和 Maven 的选择链也会接入。本 PR 先不要新增 project-maven-jdk 这类宿主注册的 toolchain，也不要自己实现一套 Maven JDK 或 Maven 版本的选择逻辑；等 #1581 合入后，Maven 插件基于 toolchainSources 和清单声明的候选来选择 JDK 与 Maven，避免出现两套版本选择机制。

3. Core 不得解析 Maven 专属配置和框架

• execution/configuration.rs 新增了对 config["provider"] == "maven.module"、extensions.maven（module、profiles、skipTests、mainClass、reactorPath、jvmArguments）的解析，以及 "spring-boot.maven" | "quarkus.maven" | "micronaut.maven" 框架名单。
• project_ownership.rs、ProjectRuntimeModels、LanguageTestService.swift（MavenTestResults）等处新增了 maven_run_provider、maven_reactor_path、maven_wrapper、maven_minimum_version 等字段。
• 这些语义应该属于 Maven 插件：Core 只把运行选择器（provider: "build.provider" + extensions.build）原样交给提供者，提供者自己决定 profile、reactor 和框架目标。测试结果统一用 v8 的 litheTestResults，不再转换成 Maven 专用的结构。

4. v7 原生配置不能只支持 XML

• litheBuildConfiguration 的绑定方式（rootElement/namespace、XML 元素路径）和 Core 内置的 XML 编辑器 build.editConfigurationDocument 只适用于 Maven 的 settings.xml。
• 通用做法：定义与格式无关的字段绑定，由提供者负责读写自己的格式；或者把文档编辑也交给提供者，宿主只做冲突检查、确认和原子写回。否则 Gradle、npm、Cargo 以后都要再加版本。

5. Java 构建准备任务约定要改成声明式

• java-prepare-run-main/java-prepare-run-test 是宿主里的 Java 工作流按约定好的任务 ID 调用构建提供者，属于宿主按名字调用插件。
• 改成由提供者在清单里声明“某个任务为哪类准备服务”（例如在任务上加一个通用的用途字段），宿主按声明查找任务，不再在契约里约定固定 ID。

6. 临时迁移代码

• MacLegacyMavenConfigurationMigration 如果只用于把旧配置一次性迁到插件，请标明它是临时代码以及删除的时间点，并且不要在迁移以外的路径上复用。这个需要单独的进行记录跟追踪的哎

影响

Lithe-IDEA/lithe-plugin-docs#5 的 SDK 协议 7～11 和 Lithe-IDEA/lithe-plugin-maven#8 都依赖这里的契约，需要等上面几点改完、契约稳定后再同步和合入。其中 Lithe-IDEA/lithe-plugin-docs#5 里协议 8～10 的 SDK 代码可以保留；协议 7 和 11 的部分要跟着新设计重写。

建议的合入顺序：#1581（版本管理）→ 本 PR 按上述意见修改，并把 JDK/Maven 选择适配到 toolchainSources → 同步契约到 lithe-plugin-docs，再合入 Lithe-IDEA/lithe-plugin-docs#5 和 Lithe-IDEA/lithe-plugin-maven#8。