[Mucheen]

插件可以通过同一个可执行文件候选列表选择用户指定的工具，模型 Provider、构建和测试遵守相同的选择与失败规则。缺失或清空设置继续自动发现；指定非空路径后不能静默换用另一安装。PR 同时保留两个独立提交中的插件详情布局修复。

• 统一来源与顺序：invocation.executables 保留 projectFile/environment/command/runtime，增加引用全局 file 设置的 kind: "setting"（reload/nextRun）。默认从前到后；可选 priority（大值优先、同分原序）或 insertBefore/insertAfter（同集合稳定 id）。Core 先确定性拓扑排序，再过滤平台；拒绝重复 ID、未知锚点、自环/循环和冲突元数据，不允许跨插件或跨集合插入。
• 共享宿主机制：plugins::executables 持有源类型和排序；ExecutableCandidateResolver 注入文件系统、环境、Runtime 和工具发现，区分 skip/resolved/terminalFailure。Build Systems 与自定义 Runtime Dependencies 接入；Build Provider 通过已有 ServerProcess 和 tool.executable 提示复用。文档说明 Language Server、Execution Provider 后续适配入口与各自包内边界、信任、自动启动和生命周期约束，未提前开放未实现的语法。
• 显式选择不回退：Core 直接拒绝非空非法存储值，普通 settings 的默认值容错保持原状。丢失文件、目录、权限或版本失败均停止显式选择。Provider 回退前同时检查工具和 Runtime 的非空 setting，前置 Runtime 提前失败也保留该约束并报告原始错误；全空设置仍允许 Provider 自行发现。只在解析失败时检查，早先候选成功仍优先于后置设置。被动导入不执行 Wrapper、Runtime 或版本探测。
• 一致的 Runtime 环境：每个 Runtime 候选在探测前构造包含其目录的 PATH，探测和后续执行复用同一环境，同目录 helper 与带空格路径均正常工作；失败候选的环境不传给下一候选。
• 能力与已发布兼容性：新机制使用可选 executableResolution: 1，纯自动发现插件继续使用 buildSystems 1。已发布 Cargo 0.1.1 的 buildSystems 2 / executableSetting 只保留输入适配，转换为首位 setting 候选；不返回 configuredExecutable，禁止与新候选元数据混写，旧 ZIP 不覆盖。配套 Cargo PR #3 已合并，0.1.2 源码使用新语法但尚未发布。
• 布局与截图：原有独立 UI 提交 fc653d5c0、589906520 保留选择按钮自然宽度、可压缩输入框/标题、详情分栏边界、窄表单横向滚动与顶部对齐。本轮未修改布局实现；补充了相同原生视图在 PR 基线与当前布局下的深浅主题、480pt 路径控件、700pt 窄分栏前后对比图和复现说明。
• 契约与维护记录：同步 Core、schema、fixture、Swift 桥接、安装审查、中文架构记录及功能矩阵。参考 xiaoyumuxi 的 feat(plugins): 添加声明式的构建工具插件 #1318、feat(build): macOS 宿主启动构建 Provider 并发送 lithe/build/* 请求 (#1351) #1356、feat(build): Provider 请求携带 refresh 与宿主解析的构建工具 (#1351) #1382 和 feat(backend): Maven 模型和依赖改由常驻 Java 后端提供并持久快照（1lck/Lithe-IDEA#1351） Lithe-IDEA/lithe-plugin-maven#3；Maven/Gradle 自动发现不需要新增设置，也没有 Cargo ID 特判。

验证（macOS，Swift 6.3.3）：

• 最终 Swift 106 项回归通过（9 个 suite）：真实 Core + MacBuildToolResolver + BuildSystemService 组合覆盖前置 Runtime 缺失/版本不足、工具或后置 Runtime 显式设置、空设置回退，模型和依赖请求均验证；真实脚本验证 Runtime 探测与执行找到同目录 helper；同时覆盖桥接、Provider 生命周期、本地化与深浅主题布局。逐测试计时、HTML/JUnit 位于 .artifacts/test-stability/review-runtime-final.*；新增组合回归 6 例共 945ms，同目录 helper 回归 554ms，均低于计时警戒线。
• 测试稳定性静态检查、共享契约、服务边界、Agent Notes、bundle 只读与功能矩阵检查通过；提交前使用精确 PR base 与暂存树运行矩阵变更 gate，提交后再次以 base/head 校验。
• Rust 与插件独立验证沿用前一宿主提交 d06d5bf9f 的通过结果，本轮未改 Rust/插件代码：Core 1106 项、构建契约额外逐项计时 32 项，完整 verify-rust-core.sh（含宿主 crates、Node/Java SDK、Core 集成、C ABI/Swift 桥接）通过；Cargo 独立仓库 11 项、真实双包 workspace 的 metadata 与全部任务、带空格的显式工具路径及包字节不变验证通过，0.1.2 打包校验通过。

Windows 宿主尚未接入构建插件的新解析机制，不声明 executableResolution；Language Server/Execution Provider 的新候选语法也留待后续集成。截图是受控原生视图回放，未作为完整发行程序的手工验收。远端 CI 以本次 head 的检查区为准。

2026-10-23 合并最新 preview bad347e2e，冲突处理提交 1443f2a05：路径选择按钮同时保留共享 LitheActionButtonStyle 和防压缩布局；合并双方同名详情布局测试，保留窄面板缩放/滚动与中英文长版本号操作按钮回归；补齐 preview 全屏测试会话替身的新 confirmRunServicesBeforeClose 协议方法。合并后 107 项 Swift 测试（12 个 suite）通过，逐测试计时、HTML/JUnit 为 .artifacts/test-stability/pr1420-conflict-resolution.*；共享契约、服务边界、Agent Notes、Rust 注释、Windows 边界、bundle 只读及精确 base/head 平台矩阵门禁通过。

[lithe-code-review]

Lithe Review

结论： ✅ 通过
范围： preview ← codex/plugin-build-tool-path · head: a972d420

未发现需要阻塞合并的问题。

Scope Check

• 关联 Issue 或需求是否完成：未找到可验证的关联 Issue；按 PR 描述和实际 diff 检查。
• 已完成范围：Core 校验与解析、macOS 显式工具路径解析、Provider 失败不回退、共享契约、测试与架构笔记均已覆盖。
• 未完成范围：Windows 尚未接入构建插件宿主，diff 中明确保持为不支持状态。
• 是否复用了已有上游能力，或对自研边界给出充分证据：该变更扩展现有插件契约和平台适配层，没有引入新的构建领域实现。
• 每个 Finding 是否由本次变更引入或加剧：未发现符合证据门槛的问题。
• 是否属于本次变更职责范围：是。

Suggestions

1. 该变更涉及 macOS 设置、构建模型和工具解析界面，但提供的 PR 上下文没有截图或前后对比。建议在 PR 描述或评论中补充受影响界面的截图；当前静态审查未验证视觉效果。

Summary

显式路径从插件设置经 Rust Core 传入 macOS resolver，并用于模型 Provider、构建和测试执行；指定路径不可用或版本不满足时不会静默回退，空值仍保留自动发现。共享契约、能力版本、平台矩阵和 Agent Note 同步更新，未见明确回归。

Verification

• 实际检查的文件、提交和调用链：指定 650e372dfa8b8c646bcb2064bf6b90be4976bc2a...a972d4204ce4c178d0314872119c11db8d435341 的 25 个文件；重点检查 rust/lithe-core/src/build/{invocation,manifest,commands}.rs、rust/lithe-core/src/plugins/settings.rs、macOS RustBuildSystemOperations、MacBuildToolResolver、BuildSystemService、相关契约与 fixture，以及受影响测试和 Agent Note。
• 已提供的测试或 CI 结果：仅记录 PR 上下文提供的结果；macOS/Windows CI gate 和 Agent Notes 检查为 success，具体 Rust/Swift 测试 check run 为 skipped。PR 描述声称的本地测试未独立验证。
• 本次未运行的测试：所有测试、构建、应用启动和验证脚本均未运行。
• 仍存在的非阻塞风险或平台验证缺口：视觉效果缺少截图；Windows 构建插件宿主仍未接入，真实 Cargo 独立仓库验证依赖外部仓库。

[xiaoyumuxi]

请求调整本 PR 的 API 设计：统一可执行文件候选入口，替代 executableSetting

这次先不要沿用当前的 invocation.executableSetting + configuredExecutable 独立旁路方案。原有 API 已经有 invocation.executables、settings、Runtime 和 Provider 工具提示等抽象；希望沿着统一入口、类型扩展、解析器注入、跨模块复用的方向完善，而不是在 Build invocation 顶层再加一个专用覆盖字段。请调整本 PR 后再合并。

目标 API

1. 可执行文件来源统一在 executables 中声明。 现有 projectFile / environment / command / runtime 继续保留，增加第五种 kind: "setting"，通过 settingID 引用插件声明的全局 file 设置（允许 reload / nextRun；沿用已有校验和能力协商）。例如：

   {
     "invocation": {
       "executables": [
         { "id": "selected", "kind": "setting", "settingID": "toolPath" },
         { "id": "wrapper", "kind": "projectFile", "path": "mvnw" },
         { "id": "system", "kind": "command", "command": "mvn" }
       ]
     }
   }

   setting 未配置/主动清空时跳过并尝试后续候选；一旦显式指定非空路径，路径不存在、不可执行、版本不满足或配置非法时应明确失败，不能静默回退。 特别注意现有通用 settings 解析会将不合法的存储值退回默认值，不能让这条规则吞掉显式配置错误；请在该用途上保留“未设置”和“已设置但无效”的区别，同时避免改变其他 settings 的既有容错语义。

2. 顺序和插入能力。 默认以数组从前到后为优先级，API 文档明确建议优先采用该写法；有需要时增加可选 priority，以及基于稳定候选 id 的 insertBefore / insertAfter 来插入相对位置。请定义确定性的规范化/排序规则，避免 priority 与插入约束冲突（建议单个候选不可同时声明二者）；重复 ID、未知锚点、循环/矛盾约束在 Core 校验时报错。插入范围先限制在同一个候选集合，不允许任意插件跨插件改写可执行程序选择。

3. 解析器以宿主注入的能力扩展，而非每个模块写专用分支。 抽象共享的 ExecutableResolution / ExecutableCandidateResolver，按 kind 使用宿主提供的 Setting、Environment、Runtime、文件系统与平台工具发现服务；结果要区分 skip、resolved、terminal failure。第三方插件只做声明，不能借此注入任意宿主原生代码。候选合并/排序应先完成，再生成一次操作内确定的解析计划，确保 Provider、模型加载和实际执行使用一致的选择。

4. 这应该是插件平台可复用的底层能力，而非 Cargo/Build 专属 API。 目标使用方包括 Build Systems、Language Servers、Build Providers、Execution Providers、Runtime Dependencies。共享的是候选解析、优先级和失败语义的机制；各模块仍保留自己的启动协议与约束（如 packaged 文件边界、项目 Wrapper 的信任/执行时机、语言服务器自动启动限制）。已有 ServerProcess、Runtime 等机制优先经适配层复用，不要为了统一强制一次性重写全部 manifest 结构。

本 PR 的落地边界 / 验收

• 这次至少完成通用契约与底层解析设计，并将 Build 路径场景改用第五种候选；其余使用方可以分后续 PR 逐步接入，但必须在契约和架构文档中讲清复用入口、迁移计划及各模块的安全边界，不要留下 Build 专属的新旁路。
• 更新 Rust Core/schema/共享 fixture、Swift resolver、Provider 调用链、能力版本和文档；根据既有版本是否已发布处理兼容性与能力协商，老版本插件行为不变。
• 回归覆盖：空值自动发现；非空显式成功；指定文件丢失/权限不足/版本不满足/非法存储值不回退；带空格路径；候选顺序、priority、前后插入及无效约束；Provider/执行一致性；项目代码不被被动探测执行；macOS 与独立 Cargo 仓库相关测试。
• 此 PR 的 UI 布局修复若仍保留，请与底层契约更改区分提交和验证，不要让界面问题主导 API 设计。

核心诉求：单一 executables 入口，允许有序候选、类型化解析和相对插入；长期复用于全平台的工具/进程解析。请不要继续采用当前单独的 executableSetting API 方案。

[Mucheen]

@lithe review

[lithe-code-review]

Lithe Review

结论： ⚠️ 有建议
范围： preview ← codex/plugin-build-tool-path · head: d06d5bf9

未发现需要阻塞合并的问题。以下两项为 P2 非阻塞问题。

Findings

1. [P2] Runtime 提前失败时仍需保留显式工具选择约束
   macos/Sources/LitheExecutionModule/Services/BuildSystemService.swift:1291

   • 实际影响：显式配置的工具路径可能被 Provider 自行发现的安装替代，模型加载与实际构建使用不同的选择规则。
   • 触发条件：首个工具候选为非空 setting，同时某个 Runtime 依赖无法解析或版本不满足。
   • 复现步骤：为 Provider 模型声明首位 setting 候选，配置 /missing/tool，再声明一个无法发现的自定义 Runtime。MacBuildToolResolver.resolve 先解析全部 Runtime，因此在检查 setting 前抛出 terminal: false 的错误；此处吞掉错误并返回 nil，outputPlan 随后发送不带 tool.executable 的原始 Provider 请求，允许 Provider 自行查找。
   • 来源：本次引入。新增的禁止回退规则只识别候选解析产生的 terminal 错误，没有覆盖显式选择生效前的 Runtime 失败。

2. [P2] 在自定义 Runtime 版本探测前加入所选目录到 PATH
   macos/Sources/Lithe/Platform/MacOS/Build/MacBuildToolResolver.swift:143

   • 实际影响：有效的自定义 Runtime 可能被误判为版本不满足，并以 terminal 错误终止操作。
   • 触发条件：Runtime 通过 setting 选择，声明了最低版本，其启动脚本需要通过 PATH 调用同目录辅助程序。
   • 复现步骤：在不属于宿主 PATH 的目录放置可执行脚本 runtime，内容为调用同目录的 fixture-helper；辅助程序输出符合要求的版本。将 Runtime setting 指向该脚本并调用解析。版本探测仍使用旧 environment，找不到辅助程序；所选目录直到第 156 行才加入 PATH，而失败分支已经返回。
   • 来源：本次引入。本次新增的 Runtime setting 来源没有获得主工具 setting 在探测前构造 PATH 的行为。

Scope Check

• 关联 Issue 或需求是否完成：未找到可验证的关联 Issue；按 API 调整评论及实际 diff 检查。
• 已完成范围：统一候选入口、确定性排序、严格设置值校验、能力协商、旧清单适配、macOS 接入和布局修复均已落地；上述组合边界仍有遗漏。
• 未完成范围：Windows 宿主及 Language Server、Execution Provider 的新候选语法接入明确留待后续。
• 上游复用：沿用现有工具发现、Runtime、ServerProcess 和 Provider，没有新增构建领域的并行实现。
• Finding 来源与职责：两项均由新增 setting 候选路径引入，属于本次解析与失败语义的职责范围。

Suggestions

1. 将显式选择约束贯穿 Runtime 解析和 Provider 错误处理，确保前置依赖失败也不会允许 Provider 忽略所选工具；补充真实 resolver 与服务串联的组合回归。
2. 在 Runtime 探测前构造候选专用环境，先加入所选目录，再将同一环境用于探测和后续执行；补充调用同目录辅助程序的回归。
3. 补充插件详情页、窄路径控件的修改前后截图，覆盖深浅主题与窄面板。当前上下文没有截图，视觉效果尚未验证。

Summary

共享机制和平台适配边界清晰，契约、fixture、测试及架构记录同步较完整。现有新增测试主要分别覆盖工具 setting、Runtime setting 和模拟 terminal 错误，尚未覆盖上述依赖顺序与探测环境组合。

Verification

• 实际检查：固定 fe0b31c…d06d5bf9 的完整 39 文件 diff，重点追踪 Core 候选校验与计划、原始设置存储、Swift 桥接、Runtime 解析、Provider 模型请求、任务执行及 UI 布局测试。
• 已提供结果：head 的 Rust Core、Windows frontend、插件测试与包校验为 success；Swift、Windows Rust、arm64 发布包及 Plugin CI gate 尚在进行。作者另报告本地 Rust、Swift、桥接及完整门禁通过，本次未独立验证。
• 本次未运行：所有测试、构建、应用和验证脚本；未访问网络或修改文件。
• 验证缺口：缺少 UI 前后截图；独立 Cargo 仓库结果仅依据作者报告；Windows 新机制尚未接入。

[xiaoyumuxi]

跨 PR 复审（head d06d5bf9）

结论：新版本已回应此前的 API 架构调整要求；仍建议修复 2 项 P2 后合并。

当前 diff 已将配置候选纳入 invocation.executables，加入 kind: "setting"、排序/插入规则与宿主解析抽象。此前要求移除独立 executableSetting 旁路的意见，不再当作未处理问题。

请继续处理本 head 现有自动审查 指出的两个组合边界：

1. [P2] Runtime 前置解析失败时，不应丢掉显式工具路径约束。 BuildSystemService.swift:1291 在 Runtime 报非 terminal 错误时返回 nil，后续 Provider 可能用自己的工具发现路径，违背指定非空 setting 不回退的语义。建议把“显式候选约束”传到 Provider/Runtime 失败处理，增加实际 resolver + Provider 组合测试。
2. [P2] 自定义 Runtime 探测前应构造与运行一致的 PATH。 MacBuildToolResolver.swift:143 对 setting 指定的脚本先运行版本探测、后追加脚本目录；依赖同目录 helper 的合法 Runtime 会被误判。请将所选目录提前加入探测环境，并复用相同环境到执行阶段。

本轮未独立运行 Swift/Rust 测试；Windows 下复用新机制仍属后续集成范围。

[Mucheen]

@xiaoyumuxi 看看可以合并了没