0.17.0: the general library for build programs, the resolved toolset in deps-vcpkg and deps-cmake, and a test kit for plugins (mcpp#734)

.agents/docs/2026-09-26-deps-vcpkg-rules-qt-plan.md

@@ -7,12 +7,12 @@
 | # | 决定 | 对设计的影响 |
 |---|---|---|
 | D6 | 附加模块合为一个包 | 确认 `xim:qt-addons`；按 xim 的载荷私有规则，它有**自己的前缀**，不写入 `xim:qt` 的目录 |
-| D8 | 先做 mcpp / xlings 生态的通用能力；GalTranslPP 的 D 阶段只在 fork 上做初步验证 | 引擎需求 2 在 mcpp 中实现：构建程序声明运行时库目录 |
+| D8 | 先做 mcpp / xlings 生态的通用能力；验证工程的 D 阶段只在 fork 上做初步验证 | 引擎需求 2 在 mcpp 中实现：构建程序声明运行时库目录 |
 | D9 | 免装 VS 不是目标 | 删除 `toolchain::msvc_xim`；`xim:msvc` 由 mcpp 自动匹配，插件不声明 |
 
 另有一项由实测带来的简化：vcpkg-tool 每个发布附带 `vcpkg-standalone-bundle.tar.gz`（3.4 MB，脚本与该工具
 版本严格对应，`vcpkg-bundle.json` 含 `"usegitregistry": true`）。以它为 `VCPKG_ROOT` 时，`builtin-baseline`
-清单经 git registry 解析，registry 落在 vcpkg 的每用户 registries 缓存。已在本机实测：对 GalTranslPP 的
+清单经 git registry 解析，registry 落在 vcpkg 的每用户 registries 缓存。已在本机实测：对验证工程的
 baseline `ea1a7396` 执行 `vcpkg install --dry-run` 解析出 `fmt 12.2.0`，缓存 137 MB。因此设计第 3 版 §3.6 的托管克隆、
 按工具检出与文件锁全部取消。
 
@@ -24,14 +24,14 @@ baseline `ea1a7396` 执行 `vcpkg install --dry-run` 解析出 `fmt 12.2.0`，
 | openxlings/xim-pkgindex | `xim:vcpkg` 2026.7.27（工具 + standalone bundle）、`xim:qt` 6.11.1、`xim:qt-addons` 6.11.1；`xim:7zip` 说明 `7z.dll` 位置；测试 | 合入即发布索引；`xlings-res/vcpkg` 资源用 `gh` 与 `gtc` 双端上传 |
 | mcpp-community/mcpp-plugins | `0.13.0`：`deps-vcpkg` + `mcpp-vcpkg`、`rules-qt` + `rules-qt-xim` + `rules-qt-xim-addons`、`deps-cmake` + `mcpp-cmake`；fixtures；CI 引擎版本；README | tag `v0.13.0`，GitHub release，`gtc` 上传 `mcpp-res/mcpp-plugins` |
 | mcpp-community/mcpp-index | 登记 `mcpp:plugins 0.13.0` | 合入即发布 |
-| Sunrisepeak/GalTranslPP（fork） | 临时 PR 2：迁移 A–C，D 阶段初步验证 | 不合入 |
+| 验证工程（fork） | 临时 PR 2：迁移 A–C，D 阶段初步验证 | 不合入 |
 
 ## 3. 依赖关系
 
 ```
 T2 xim 包（vcpkg/qt/qt-addons）──► T2r 索引合入（xim-pkgindex#878，已合入）
 T3 插件按 SPEC-007 实现（PR 已开，等待）──┐
-T1 mcpp#702 实现并发布（mcpp 侧）─────────┴──► T3c 插件 CI 全绿 ──► T3r 插件发布 0.13.0 ──► T4 mcpp-index ──► T5 GalTranslPP PR 2
+T1 mcpp#702 实现并发布（mcpp 侧）─────────┴──► T3c 插件 CI 全绿 ──► T3r 插件发布 0.13.0 ──► T4 mcpp-index ──► T5验证工程PR 2
 ```
 
 - T1、T2、T3 并行：T3 在本机用 T1 的源码构建验证 Linux 路径；Windows 与 macOS 路径只能由 CI 验证。
@@ -70,9 +70,9 @@ T1 mcpp#702 实现并发布（mcpp 侧）─────────┴──►
   位于插件仓库之内，因此其安装位于 `target/` 之下，检查脚本的日志写入 `target/ci/`，第二次构建以
   `--profile dev` 绕过快路径，使 Linux 与 Windows、macOS 走同一条规划路径。从索引取得插件的项目不受影响。
 
-## 6. 0.14.0：运行时数据与精简 Qt（GalTranslPP 验证后的第二轮）
+## 6. 0.14.0：运行时数据与精简 Qt（验证工程验证后的第二轮）
 
-GalTranslPP 在 0.13.1 上构建成功后仍有两个手动步骤（解压嵌入式 Python、运行 `Release.py`），Qt 下载量为
+验证工程在 0.13.1 上构建成功后仍有两个手动步骤（解压嵌入式 Python、运行 `Release.py`），Qt 下载量为
 完整基础包。第二轮把固定步骤程序化，并补齐 windeployqt 的 Qt 翻译：
 
 | 交付 | 仓库 | 机制 |
@@ -100,5 +100,5 @@ libstdc++，mcpp 的 clang 使用 libc++，两者的 `std::` 符号互不链接
 判据（Linux CI `vcpkg-libcxx`）：llvm 下 `libfmt.a` 含 `std::__1::` 符号且程序运行；默认工具链构建后 libc++
 前缀仍在；切回 llvm 不重跑安装；deps-cmake 子项目的 `CMAKE_CXX_COMPILER` 为 mcpp 的 clang。
 
-GalTranslPP 上游仅支持 Windows（README 所述，代码直接调用 WinAPI），Linux 的判据由本仓库的 fixture 承担；
-GalTranslPP PR2 作为 Windows 回归验证。
+验证工程上游仅支持 Windows（README 所述，代码直接调用 WinAPI），Linux 的判据由本仓库的 fixture 承担；
+验证工程PR2 作为 Windows 回归验证。

.agents/docs/2026-09-26-plugins-0.15-architecture-plan.md

@@ -17,7 +17,7 @@
 6. 缺少插件开发规范；README 过长。
 
 约束：
-- GalTranslPP 上游仅支持 Windows。Linux 与 macOS 的判据由插件仓库的 fixture 承担，GalTranslPP PR2 作为 Windows 回归。
+-验证工程上游仅支持 Windows。Linux 与 macOS 的判据由插件仓库的 fixture 承担，验证工程PR2 作为 Windows 回归。
 - mcpp 最新版本为 2026.9.26.2。
 - 0.14.1 与 0.15.0 合并为一个版本 0.15.0。每个仓库一个 PR，仅在无法同时验证时拆分（§8）。
 
@@ -145,7 +145,7 @@ rules-qt 的 SDK 查找顺序为 `options::root` → `QT_ROOT_DIR`（不采用 `
 |---|---|
 | 删除 `rules-qt-xim*` | 改为 `features = ["rules-qt"]`，并在 `[xlings]` 中声明 `xim:qt-base` 或 `xim:qt` 及版本 |
 | 删除 `mcpp-deps` | 从依赖边删除 `tools = ["mcpp-deps"]` |
-| vcpkg 前缀多一层 triplet | 改用返回的 `prefix`，不硬编码 `vcpkg_installed/<triplet>`（GalTranslPP `gpp.build` 第 182 行） |
+| vcpkg 前缀多一层 triplet | 改用返回的 `prefix`，不硬编码 `vcpkg_installed/<triplet>`（验证工程`build` 第 182 行） |
 | 插件不再提供 glib 目录 | 使用外部 Qt 的 Linux 项目自行处理闭包 |
 
 载荷的更新方式：xlings 以磁盘上的载荷与安装记录判定"已安装"，不会对已存在的载荷调用配方的 `installed()`。因此含运行时闭包的载荷以新版本号
@@ -164,7 +164,7 @@ mcpp-plugins#32 → 0.15.0（Linux Widgets 与 Windows CRT 判据依赖上一步
         │ 三平台 CI 全绿 → tag、GitHub release、gtc 上传 GitCode
 mcpp-index：登记 0.15.0
         │
-GalTranslPP PR2：按 §7 迁移；Windows 回归（含 VC++ 运行时）
+验证工程PR2：按 §7 迁移；Windows 回归（含 VC++ 运行时）
 并行：mcpp issue E1、E2
 ```
 

.agents/docs/2026-09-27-mcpp-2026.9.27.1-ecosystem-plan.md

@@ -44,7 +44,7 @@ bba733a 在云端从未构建。本地以 mcpp 2026.9.26.2、GCC 16.1 构建。
 | e2e 802（#704） | 在默认工具链为 llvm@22.1.8 的机器上失败：测试断言 `NEEDED libstdc++`，而清单未固定工具链。在测试清单中写入 `[toolchain] default = "gcc@16.1.0"` 后三项断言全部通过，说明 #704 的修复正确，缺陷在测试本身 |
 
 逐 issue 审查的结论：12 个 issue 的修复均对应 issue 的原始描述，未发现错误（#706 是已合入上游的文档提交，不在本 PR 中）。需要处理的是以下三点：
-- **#714 是行为变更：** 未解析的 `workspace = true` 由静默变为空版本，改为加载时报错。在 mcpp-plugins、mcpp-index、GalTranslPP、mcpp-language-server 中均未发现依赖旧行为的清单。
+- **#714 是行为变更：** 未解析的 `workspace = true` 由静默变为空版本，改为加载时报错。在 mcpp-plugins、mcpp-index、验证工程、mcpp-language-server 中均未发现依赖旧行为的清单。
 - **#710 覆盖不足：** 非成员宿主工具包的工具链路径只有单元测试，没有 e2e。
 - **note 代码改名：** `MCPP_BUILD_DATABASE_HOST_TOOL_UNBUILT` 改为 `..._DEFERRED`，没有兼容别名；mcpp-language-server 不读取这两个代码。
 
@@ -175,7 +175,7 @@ A1 至 A4 可以并行。B3 不依赖 B2：旧版 xlings 忽略 revision 字段
 | xlings #620 | 先用 xlings 2026.9.26.3 安装 glibc（revision 0），再升级到 2026.9.27.1 并执行 `xlings install glibc` | 输出重装提示，载荷为 revision 1 |
 | xlings #621 | 执行 `setlocale(LC_ALL, "C.UTF-8")` 与 `iconv -f UTF-8 -t GBK`；qt-demo 执行 `mcpp run` | 两项调用成功；Qt 不再输出 UTF-8 locale 提示 |
 
-**消费方验证：** GalTranslPP fork 以 mcpp 2026.9.27.1 与 plugins 0.16.0 运行 Windows CI，测量首次 emit、构建后再次 emit，并确认未安装 llvm@20.1.7。预期结果见 `2026-09-27-galtranslpp-upstream-vs-pr2-outlook.md` §4 的 S4 一栏。该验证只更新 fork 分支，不向上游提 PR；是否基于上游最新重做，另行决定。
+**消费方验证：**验证工程fork 以 mcpp 2026.9.27.1 与 plugins 0.16.0 运行 Windows CI，测量首次 emit、构建后再次 emit，并确认未安装 llvm@20.1.7。预期结果见 `2026-09-27-validation-project-upstream-vs-pr2-outlook.md` §4 的 S4 一栏。该验证只更新 fork 分支，不向上游提 PR；是否基于上游最新重做，另行决定。
 
 ### 3.6 阶段 E：收尾
 

.agents/docs/2026-09-27-plugins-0.15.2-plan.md

@@ -1,12 +1,12 @@
 # plugins 0.15.2 与生态收敛方案
 
-日期：2026-09-27。依据：`2026-09-27-versioning-assets-locale-and-galtranslpp-review.md` 及其后的讨论结论。
+日期：2026-09-27。依据：`2026-09-27-versioning-assets-locale-and-validation-project-review.md` 及其后的讨论结论。
 
 ## 0. 目标
 
 1. Qt 以上游版本 `6.11.1` 作为唯一版本键，消费方书写上游版本。
 2. brotli 资源恢复规范文件名，GitHub 与 GitCode 逐字节一致。
-3. GalTranslPP PR2 达到当前生态能力下的最佳形态：版本单点声明、可配置项有文档、emit 开销可解释且可测。
+3.验证工程PR2 达到当前生态能力下的最佳形态：版本单点声明、可配置项有文档、emit 开销可解释且可测。
 4. 需要 mcpp、xlings、xim glibc 改动的事项，以 issue 形式交给各自仓库。
 
 非目标：修改 mcpp、xlings 或 glibc 配方本身。
@@ -46,7 +46,7 @@ D1 的索引改动只是删除冗余键；消费方的切换不依赖它先合
 - 验收：三平台 CI 全绿。其中 Linux 的 widgets 打包检查要确认新缓存下装出的 `6.11.1` 带有运行时闭包（libdbus、xkbcommon、fontconfig），这正是 D1 的实证。
 - 发布：tag v0.15.2、GitCode 镜像（sha256 比对）、mcpp-index 登记。
 
-### 2.4 GalTranslPP PR2
+### 2.4 the validation project PR2
 
 | 项 | 内容 | 验收 |
 |---|---|---|
@@ -70,7 +70,7 @@ E6 若查明警告来自插件（例如 rules-qt 在不需要 Qt 的构建程序
 
 ```
 2.1 brotli 资源 ──► 2.2 xim PR ──► 索引发布 ──► 2.5-1 删除 -r1
-2.3 plugins 0.15.2 ──► 发布 + index 登记 ──► 2.4 GalTranslPP PR2
+2.3 plugins 0.15.2 ──► 发布 + index 登记 ──► 2.4验证工程PR2
 ```
 
 两条链互不阻塞：2.3 与 2.4 使用 `6.11.1` 键，该键今天已存在且内容已修正（见 §1 关键事实）。
@@ -83,7 +83,7 @@ E6 若查明警告来自插件（例如 rules-qt 在不需要 Qt 的构建程序
 | mcpp-community/mcpp#711 | 发布物无法依赖另一个包按目标平台构建的可执行文件，只能借宿主工具边 | 否：本机构建结果正确；交叉编译时才会出错 |
 | mcpp-community/mcpp#712 | `xpkg_dir` 把裸版本当字面 pin，xlings 则会匹配到四段版本键；已复现（libglvnd `1.7` → 装了 1.7.0.1，`xpkg_dir` 返回空） | 否：写精确版本键即可避开 |
 | openxlings/xlings#620 | 配方修订号独立于版本号 | 否：没有外部用户时就地修正（D4） |
-| openxlings/xlings#621 | glibc 载荷没有 locale 数据，编译进去的 locale 路径不在载荷内 | 否：只是一条提示；GalTranslPP 仅构建 Windows，不受影响 |
+| openxlings/xlings#621 | glibc 载荷没有 locale 数据，编译进去的 locale 路径不在载荷内 | 否：只是一条提示；验证工程仅构建 Windows，不受影响 |
 
 不再提交：设置 `QT_ROOT_DIR` 时仍下载声明的 Qt。这是预期行为，按 E4 写进文档。
 视 E2、E3 的结果，可能再提交"xlings 条目支持从工作区继承"。
@@ -92,7 +92,7 @@ E6 若查明警告来自插件（例如 rules-qt 在不需要 Qt 的构建程序
 
 | 风险 | 缓解 |
 |---|---|
-| 删除 `6.11.1.1` 后，仍书写 `6.11.1.1` 的消费方解析失败 | 已知消费方只有 plugins fixture 与 GalTranslPP，二者均在本方案中改为 `6.11.1` |
+| 删除 `6.11.1.1` 后，仍书写 `6.11.1.1` 的消费方解析失败 | 已知消费方只有 plugins fixture 与验证工程，二者均在本方案中改为 `6.11.1` |
 | 某处缓存仍恢复出修正前的 `6.11.1` 载荷 | 两处 CI 缓存 key 均升级；Linux widgets 打包检查会在闭包缺失时失败 |
 | E2 或 E3 不被 mcpp 支持 | 回退为逐成员声明，不阻塞发布 |
 
@@ -103,14 +103,14 @@ E6 若查明警告来自插件（例如 rules-qt 在不需要 Qt 的构建程序
 | 2.1 brotli | GitCode 已上传规范名资源与 `SHA256SUMS`，两端逐字节一致；GitHub 的 `-r1` 已删除；GitCode 的 `-r1` 待用户删除 |
 | 2.2 xim | openxlings/xim-pkgindex#891 已合入（4c1dc850）；发布后的索引中 qt、qt-base、qt-addons 只列出 `6.11.1`；brotli 按规范名安装，带头文件 |
 | 2.3 plugins | mcpp-community/mcpp-plugins#34 已合入（53c57d5），三平台 CI 全绿；tag v0.15.2；GitCode mcpp-res/mcpp-plugins 0.15.2 与 GitHub 逐字节一致（sha256 `a66e349d…76ad`）；mcpplibs/mcpp-index#478 已合入，`latest` 为 0.15.2 |
-| E2 | 成员的 `.workspace = true` 可以与 `features`、`host-module` 同用。非成员的 `gpp.build` 不能继承（mcpp#714），改为自带版本；若把它设为成员，根目录的 `mcpp build` 会把它当作目标构建并失败 |
+| E2 | 成员的 `.workspace = true` 可以与 `features`、`host-module` 同用。非成员的 `build` 不能继承（mcpp#714），改为自带版本；若把它设为成员，根目录的 `mcpp build` 会把它当作目标构建并失败 |
 | E3 | 不成立：三种写法（带 cfg 的 target 表、`[target.linux]`、`[xlings.workspace]`）写在根清单时，成员的构建程序都看不到载荷（mcpp#713）。回退为逐成员声明 |
-| E6 警告来源 | 21 条 "no Qt SDK" 全部来自 `gpp.build`：它启用 `rules-qt` 只为导入模块，自己没有 build.mcpp，mcpp 仍为它合成规则程序（mcpp#715）。0.15.2 让这种情况不再输出提示；新增 fixture `qt-import-only` |
-| Qt 路径单点 | GalTranslPP 的 `gpp::qt_root` 与 `gpp::qt_options()` 汇集到一处：规则、发布布局、ElaWidgetTools 的 `QT_SDK_DIR` 都取同一个 SDK |
+| E6 警告来源 | 21 条 "no Qt SDK" 全部来自 `build`：它启用 `rules-qt` 只为导入模块，自己没有 build.mcpp，mcpp 仍为它合成规则程序（mcpp#715）。0.15.2 让这种情况不再输出提示；新增 fixture `qt-import-only` |
+| Qt 路径单点 |验证工程的 `gpp::qt_root` 与 `gpp::qt_options()` 汇集到一处：规则、发布布局、ElaWidgetTools 的 `QT_SDK_DIR` 都取同一个 SDK |
 
 新发现并已提交的 mcpp issue：#713（根清单的 xlings 声明对成员不可见）、#714（非成员的 `.workspace = true` 变成空版本）、
 #715（没有设备源也合成规则程序）、#716（provisioning 印记在载荷删除后仍然有效）。
-| 2.4 GalTranslPP | Sunrisepeak/GalTranslPP 提交 43ee88f，run 36272623612 全绿。首次 emit 258 s；GPPCLI 6.2 min；GPPGUI 18.2 min；pack 0.9 min；无改动的第二次构建 0.8 min，未触发安装；构建后再次 emit 62 s。所有日志中 "no Qt SDK" 为 0 条；成员记录的 SDK 事实为 `xlings: …/xim-x-qt-base/6.11.1` |
+| 2.4验证工程| 验证工程 提交 43ee88f，run 36272623612 全绿。首次 emit 258 s；cli 6.2 min；gui 18.2 min；pack 0.9 min；无改动的第二次构建 0.8 min，未触发安装；构建后再次 emit 62 s。所有日志中 "no Qt SDK" 为 0 条；成员记录的 SDK 事实为 `xlings: …/xim-x-qt-base/6.11.1` |
 
 构建后再次 emit 需要 62 s，原因有二：