diff --git a/.agents/docs/2026-09-26-deps-vcpkg-rules-qt-plan.md b/.agents/docs/2026-09-26-deps-vcpkg-rules-qt-plan.md
index c05b740..4dd1ca1 100644
--- a/.agents/docs/2026-09-26-deps-vcpkg-rules-qt-plan.md
+++ b/.agents/docs/2026-09-26-deps-vcpkg-rules-qt-plan.md
@@ -85,3 +85,20 @@ GalTranslPP 在 0.13.1 上构建成功后仍有两个手动步骤（解压嵌入
 
 实测：库包中的 `artifact` 输出经 `mcpp::deploy` 传播到依赖它的程序的 `bin/` 与 `mcpp pack` 目录；依赖包中无下游
 消费者的 `artifact` action 随下游构建执行。
+
+## 7. 0.14.1：Linux 上依赖的 C++ 标准库与程序一致
+
+Windows 上 MSVC ABI 的编译器共用 Microsoft 的标准库，macOS 上共用 libc++；Linux 上主机编译器使用
+libstdc++，mcpp 的 clang 使用 libc++，两者的 `std::` 符号互不链接。0.14.1 在 Linux 的 libc++ 工具链下：
+
+| 交付 | 机制 |
+|---|---|
+| `deps-vcpkg` 生成的 triplet | 默认 triplet 为 `<arch>-linux-libcxx`，经 `VCPKG_CHAINLOAD_TOOLCHAIN_FILE` 以 mcpp 的 clang 编译端口，再接 vcpkg 自身的 Linux 工具链；clang 的配置文件给出 libc++ 与 mcpp 链接的 C 库 |
+| 每个 triplet 一个 vcpkg 安装 | vcpkg 的清单模式从安装中移除其余 triplet 的包；前缀改为 `<install root>/<triplet>/<triplet>`，两个工具链的前缀并存，切换不重装 |
+| `deps-cmake` | 未经 `cache_args` 指定编译器或工具链文件时，传入 mcpp 的 clang |
+
+判据（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 回归验证。
diff --git a/.agents/docs/2026-09-26-plugins-0.15-architecture-plan.md b/.agents/docs/2026-09-26-plugins-0.15-architecture-plan.md
new file mode 100644
index 0000000..1a2338d
--- /dev/null
+++ b/.agents/docs/2026-09-26-plugins-0.15-architecture-plan.md
@@ -0,0 +1,186 @@
+# mcpp-plugins 0.15.0：职责分层、以 build.mcpp 为中心的配置与多平台运行时闭包
+
+> 2026-09-26 · 第 3 版（吸收第 1、2 版评审）· 承接 `2026-09-26-deps-vcpkg-rules-qt-{design,plan}.md`
+
+## 0. 总纲
+
+核心体系由两部分组成：mcpp 通用引擎及其构建插件框架；官方、第三方或项目内的构建插件。`build.mcpp` 是这一机制的
+核心使用点：项目在其中导入插件模块、配置插件并调用它。
+
+评审提出的问题：
+
+1. Linux 上 vcpkg 端口与程序的 C++ 标准库不一致。
+2. Linux 上 QtGui 不可用。
+3. 插件与依赖库绑定：Qt 版本固定，运行时库写在插件的 feature 中。
+4. feature 应是通用机制；依赖的选择由插件与 build.mcpp 组合配置实现。
+5. 内部实现（`mcpp-deps`）不得成为消费方契约。
+6. 缺少插件开发规范；README 过长。
+
+约束：
+- GalTranslPP 上游仅支持 Windows。Linux 与 macOS 的判据由插件仓库的 fixture 承担，GalTranslPP PR2 作为 Windows 回归。
+- mcpp 最新版本为 2026.9.26.2。
+- 0.14.1 与 0.15.0 合并为一个版本 0.15.0。每个仓库一个 PR，仅在无法同时验证时拆分（§8）。
+
+## 1. 职责分层与决定
+
+| 层 | 负责 | 不负责 |
+|---|---|---|
+| mcpp | 构建图、动作与戳、运行时闭包检查、部署、打包、工具链信息 | 任何具体库、SDK 或工具 |
+| 插件 | 机制：输入变为声明了输入输出的动作；前缀或 SDK 映射进构建 | 版本；运行时闭包；绕过引擎缺口 |
+| xlings 包 | 载荷及其在每个平台上的运行时闭包 | 构建逻辑 |
+| 项目 | 策略：库、SDK、版本、路径、选项 | — |
+
+- **D1 feature 只表达机制。** feature 只能声明机制自身执行的工具（`xim:vcpkg`、`xim:cmake`），不得声明链接进程序的库或
+  SDK。`rules-qt-xim`、`rules-qt-xim-base`、`rules-qt-xim-addons` 在 0.15.0 **直接删除**（评审决定，不保留别名）。
+- **D2 运行时闭包归提供它的包，逐平台成立**（§4）。
+- **D3 内部实现不进入契约。** 契约面只有 feature 名、`options` 字段、返回类型和文档所列的环境变量。
+
+## 2. 配置：以 build.mcpp 为中心
+
+每项配置取第一个给出值的层级：
+
+| 级 | 位置 | 说明 |
+|---|---|---|
+| 1 | `build.mcpp` 中的 `options` | 项目配置的主要位置，值可以计算；插件的返回值（前缀、SDK 根、部署的文件）是编程扩展点 |
+| 2 | 约定的环境变量 | 只采用生态中已有的名字（`QT_ROOT_DIR`），变化时重新规划 |
+| 3 | 项目在 `[xlings]` 中声明的载荷 | 版本由项目声明 |
+
+生效层级以 `mcpp::fact` 记录。第 2 版中的 `[package.metadata.<成员>]` 一级按评审意见删除：vcpkg 的库列表属于
+build.mcpp，而不是 mcpp.toml。
+
+```toml
+[build-dependencies.mcpp]
+plugins = { version = "0.15.0", features = ["rules-qt", "deps-vcpkg"], host-module = true }
+
+[target.'cfg(any(windows, linux, macos))'.xlings.workspace]
+"xim:qt-base" = "6.11.1.1"
+```
+
+```cpp
+// build.mcpp
+import mcpp.rules.qt;
+import mcpp.deps.vcpkg;
+int main() {
+    mcpp::deps::vcpkg::options v;
+    v.libraries = { "fmt", "spdlog" };
+    mcpp::rules::qt::options q;
+    q.modules = { "Core", "Widgets" };
+    return mcpp::deps::vcpkg::use(v) && mcpp::rules::qt::compile(q) ? 0 : 1;
+}
+```
+
+rules-qt 的 SDK 查找顺序为 `options::root` → `QT_ROOT_DIR`（不采用 `QTDIR`）→ 项目声明的 `xim:qt` 或 `xim:qt-base`（附带
+`xim:qt-addons`）。找不到时的警告给出可直接复制的两行声明。
+
+## 3. C++ 标准库对齐
+
+- **deps-vcpkg**：在 Linux 的 libc++ 工具链下，默认 triplet 为生成的 `<arch>-linux-libcxx`，端口以 mcpp 的 clang 编译。
+- **每个 triplet 独立安装**：前缀为 `<install root>/<triplet>/<triplet>`。
+- **deps-cmake**：同样条件下传入 mcpp 的 clang。
+- **rules-qt**：在 libc++ 工具链下使用 Qt 官方 Linux 构建时给出警告。
+
+以上已完成：PR #32 的这部分三平台 CI 通过，本机 `vcpkg-libcxx` 判据通过。
+
+## 4. 多平台运行时闭包
+
+判据：只装有操作系统的机器上，`mcpp pack` 的产物能够启动。
+
+| 平台 | Qt 加载的外部库 | 0.15.0 |
+|---|---|---|
+| Linux | glib、zstd、zlib、libdbus、fontconfig、freetype、X11、xkbcommon、EGL/GL、xcb 系列 | `xim:qt` 与 `xim:qt-base` 声明这些包和 `xim:glibc`。libxpkg 的加载器谓词在安装后改写载荷中的每个 ELF：可执行文件使用 xlings 加载器，RUNPATH 为这些包与载荷自身 `lib/` 的闭包。工具与程序共用一个加载器和 libc |
+| Windows | 系统 DLL；VC++ 运行时（MSVCP140、VCRUNTIME140、VCRUNTIME140_1） | windows-x86_64 载荷从微软可再分发包（xlings-res/msvc 镜像，与 `xim:msvc` 14.44.35207 同一 vsix）取出 `Microsoft.VC143.CRT` 放入 `bin/`。windows-aarch64 暂缺镜像，列为后续项 |
+| macOS | 系统 framework 与 libc++ | 无新增 |
+
+- **新增 `xim:dbus` 1.16.2**：由 conda-forge 重新打包到 xlings-res/dbus（双端逐字节一致），依赖只有 libc 与 libpthread；构建
+  前缀已重定位到 `/`。
+- **后续项**：QtNetwork 所需的 krb5、brotli；windows-aarch64 的 CRT；xlings glibc 的 UTF-8 locale。
+
+本机验证（手工模拟改写 RUNPATH）：Linux 上 console、Widgets offscreen 两个程序均运行。Windows 的 CRT 放置由 CI 验证（V1）。
+
+## 5. mcpp-deps：删除
+
+它原是 deps 系列动作的命令，负责四件事：
+- vcpkg 的环境变量；
+- 安装根的锁；
+- 短路径的临时目录；
+- CMake 三步串联，以及解压前清空目录。
+
+它经 `tools = ["mcpp-deps"]` 进入了消费方契约，也是 mcpp#705、#707 性能问题的来源。0.15.0 以不依赖新引擎能力的方式替代：
+
+| 职责 | 替代 |
+|---|---|
+| `VCPKG_ROOT`、`VCPKG_DISABLE_METRICS` | vcpkg 参数 `--vcpkg-root`、`--disable-metrics` |
+| 锁 | vcpkg 自身的 `<root>/vcpkg/vcpkg-running.lock`；workspace fixture 两成员共用一个根，本机通过（V2） |
+| 短路径临时目录 | `--x-buildtrees-root`、`--x-packages-root`、`--downloads-root`，路径在规划时计算 |
+| CMake 三步、清空并解压 | 构建程序写出的脚本，由 `cmake -P` 执行；参数以方括号参数书写，保留空格与分号 |
+
+- `tools/deps_main.cpp` 与 `[targets.mcpp-deps]` 直接删除，与 D1 的处理一致，不保留弃用目标。
+- 依赖边写有 `tools = ["mcpp-deps"]` 的消费方须删除该项，这记入 §7。
+- 本机 vcpkg-consumer、cmake-consumer、archive-consumer、vcpkg-workspace、vcpkg-libcxx 五个判据全部通过。
+
+交给 mcpp 的只有通用能力，都不阻塞本版：
+- E1：动作支持环境变量与工作目录；
+- E2：feature 自带其所需的包内工具。`tools-embed` 的 `mcpp-embed` 仍经 `tools` 暴露，待 E2 支持后收回。
+
+## 6. 规范与文档
+
+- **README**：精简为约 100 行（原 1113 行），开篇陈述 §0 的总纲；各成员细节移至 `docs/<成员>.md`。
+- **`docs/plugin-development.md`（新增）**：包含职责分层表和十条规则：
+  1. 机制而非策略；
+  2. feature 只表达机制；
+  3. build.mcpp 为先的三级配置；
+  4. 运行时闭包归载荷；
+  5. 内部实现不进入契约；
+  6. 工作即动作；
+  7. 缺失即警告；
+  8. 引擎缺口提交 issue；
+  9. 每条行为对应判据；
+  10. 文档简洁。
+
+  第三方插件与项目内插件同样适用。
+
+## 7. 兼容性（0.15.0 的破坏性变更）
+
+| 变化 | 消费方需做的修改 |
+|---|---|
+| 删除 `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 行） |
+| 插件不再提供 glib 目录 | 使用外部 Qt 的 Linux 项目自行处理闭包 |
+
+载荷的更新方式：xlings 以磁盘上的载荷与安装记录判定"已安装"，不会对已存在的载荷调用配方的 `installed()`。因此含运行时闭包的载荷以新版本号
+`6.11.1.1` 发布（xim-pkgindex#888，沿用 fontconfig 2.15.0.1、libglvnd 1.7.0.1 的做法），项目声明 `"xim:qt-base" = "6.11.1.1"`。
+这一点由插件 CI 实测发现：缓存恢复了旧的 6.11.1 载荷，Linux 程序缺少 `libzstd.so.1`。
+
+## 8. 任务依赖与 PR
+
+```
+xlings-res/dbus（已发布）
+xim-pkgindex#885：dbus（单独拆出：CI 从已发布索引解析依赖，新包与其首个依赖方无法同时验证）
+        │ 合入 → 索引发布
+xim-pkgindex#884：qt、qt-base 的 Linux 闭包与 Windows CRT
+        │ 合入 → 索引发布
+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++ 运行时）
+并行：mcpp issue E1、E2
+```
+
+## 9. 总体评审
+
+| 维度 | 结论 |
+|---|---|
+| 架构 | 四层职责不重叠；插件中的平台逻辑均由引擎提供的工具链信息推导，没有写死的值 |
+| 稳定性 | 动作的输入输出完整；运行时闭包在规划、链接、运行、打包阶段分别由引擎与载荷保证 |
+| 简洁 | 删除三个 feature、一个包内工具和 metadata 一级；新增的机制只有 `cmake -P` 脚本 |
+| 易用性 | 配置集中在 build.mcpp；依赖边不再有 `tools`；Qt 选择是两行显式声明 |
+| 兼容性 | 破坏性变更集中在 §7，每项修改为一到两行；载荷修订经新版本号到达已安装旧载荷的机器 |
+| 跨平台 | 三个平台的闭包逐一论证；windows-aarch64 的 CRT 为已知缺口 |
+| 一致性 | 三级配置、fact 记录、警告优先，对所有成员相同 |
+| 测试 | 新增 `qt-sdk-consumer`（三个层级）、Linux Widgets 与打包、Windows CRT、`vcpkg-libcxx` |
+
+遗留：
+- V1：Windows 的 CRT 是否被引擎放置到程序旁；
+- 后续项：krb5、brotli、windows-aarch64 的 CRT、UTF-8 locale。
diff --git a/.github/scripts/check-deps-and-qt.sh b/.github/scripts/check-deps-and-qt.sh
index 3b087be..c73eb98 100644
--- a/.github/scripts/check-deps-and-qt.sh
+++ b/.github/scripts/check-deps-and-qt.sh
@@ -72,7 +72,7 @@ vcpkg_consumer() {
 
     if is_windows; then
         # The pack collects it from the runtime search directory.
-        ls target/vcpkg_installed/x64-windows/bin/fmt.dll > /dev/null || fail "x64-windows built no fmt.dll"
+        ls target/vcpkg_installed/x64-windows/x64-windows/bin/fmt.dll > /dev/null || fail "x64-windows built no fmt.dll"
         run_directly vcpkg-consumer | tee target/ci/direct.log
         grep -qE '^vcpkg-consumer: fmt [0-9]+ says 42$' target/ci/direct.log ||
             fail "started from the build directory, the program did not find fmt.dll"
@@ -83,6 +83,51 @@ vcpkg_consumer() {
     fi
 }
 
+# LINUX UNDER A libc++ TOOLCHAIN. The host compiler vcpkg and CMake find uses
+# libstdc++, whose `std::` symbols a libc++ program cannot link. The default
+# triplet is then the generated `x64-linux-libcxx`, whose ports build with
+# mcpp's clang; fmt's interface returns `std::string`, so the link itself is the
+# criterion. The prefix is then shown to survive the default toolchain's own
+# installation, which vcpkg would remove if the two triplets shared one.
+vcpkg_libcxx() {
+    local llvm="${MCPP_LLVM:-llvm@22.1.8}" gen=x64-linux-libcxx
+    [ "$(uname -m)" = aarch64 ] && gen=arm64-linux-libcxx
+    cd "$ROOT/tests/vcpkg-consumer"
+    rm -rf target vcpkg_installed
+    mkdir -p target/ci
+    "$MCPP" build --toolchain "$llvm" 2>&1 | tee target/ci/libcxx-build.log
+    "$MCPP" run --toolchain "$llvm" | tee target/ci/libcxx-run.log
+    grep -qE '^vcpkg-consumer: fmt [0-9]+ says 42$' target/ci/libcxx-run.log || fail "the libc++ program did not print through fmt"
+    local lib; lib=$(find target/vcpkg_installed -path "*/$gen/$gen/lib/libfmt.a" | head -1)
+    [ -n "$lib" ] || fail "no $gen prefix with libfmt.a"
+    grep -q 'std::__1::' <(nm -C "$lib") || fail "$lib is not built against libc++"
+    echo "ok: under $llvm the ports build with mcpp's clang and the program links them"
+
+    "$MCPP" build 2>&1 | tee target/ci/default-build.log
+    "$MCPP" run | tee target/ci/default-run.log
+    grep -qE '^vcpkg-consumer: fmt [0-9]+ says 42$' target/ci/default-run.log || fail "the default toolchain's program did not print through fmt"
+    [ -f "$lib" ] || fail "the default toolchain's installation removed the $gen prefix"
+    local stamp; stamp=$(find target -path '*deps-vcpkg*' -name "$gen.stamp" | head -1)
+    [ -n "$stamp" ] || fail "no $gen installation stamp"
+    touch -r "$stamp" target/ci/before-switch-back
+    sleep 1
+    "$MCPP" build --toolchain "$llvm" --profile dev > target/ci/switch-back.log 2>&1 ||
+        { cat target/ci/switch-back.log; fail "the build switched back to $llvm failed"; }
+    [ -z "$(find "$stamp" -newer target/ci/before-switch-back)" ] ||
+        fail "switching back to $llvm re-ran its installation"
+    echo "ok: the two toolchains' prefixes coexist, and switching back installs nothing"
+
+    # deps-cmake takes the same compilers.
+    cd "$ROOT/tests/cmake-consumer"
+    rm -rf target
+    mkdir -p target/ci
+    "$MCPP" build --toolchain "$llvm" 2>&1 | tee target/ci/libcxx-build.log
+    "$MCPP" run --toolchain "$llvm" | grep -q '^cmake-consumer: greet says 42$' || fail "the libc++ cmake-consumer did not run"
+    grep -rqs 'CMAKE_CXX_COMPILER:[A-Z]*=.*xim-x-llvm.*/clang++' target --include=CMakeCache.txt ||
+        fail "deps-cmake configured the subproject without mcpp's clang"
+    echo "ok: deps-cmake configures the subproject with mcpp's clang under $llvm"
+}
+
 vcpkg_workspace() {
     cd "$ROOT/tests/vcpkg-workspace"
     rm -rf target app-a/target app-b/target vcpkg_installed
@@ -106,10 +151,7 @@ cmake_consumer() {
     "$MCPP" run | tee target/ci/run.log
     grep -q '^cmake-consumer: greet says 42$' target/ci/run.log || fail "the program did not call the subproject's library"
     assert_not_rerun "$(stamp_of deps-cmake)"
-    # The builds after an edit are planned as well. The subproject lies inside
-    # this repository, the tree mcpp stamps for the plugins' host tool
-    # (mcpp#705), so an edit also rebuilds `mcpp-deps`; the build that is
-    # expected to re-run the installation absorbs that rebuild.
+    # The builds after an edit are planned as well.
     touch greet/greet.c
     "$MCPP" build --profile dev > target/ci/third-build.log 2>&1 || { cat target/ci/third-build.log; fail "the rebuild failed"; }
     # The installed library is the product of the rebuild, whatever the engine
@@ -234,15 +276,60 @@ qt_widgets_consumer() {
         find target/dist -ipath '*platforms/qoffscreen.dll' | grep -q . ||
             fail "the packed tree carries no platforms/qoffscreen.dll"
         echo "ok: the packed tree carries the Qt modules and the platform plugins"
+        # The VC++ runtime Qt's DLLs import travels with them, so the program
+        # does not depend on the target machine's VC++ Redistributable.
+        for dll in msvcp140.dll vcruntime140.dll vcruntime140_1.dll; do
+            find target -path '*/bin/*' -iname "$dll" | grep -q . || fail "$dll was not placed beside the program"
+            find target/dist -iname "$dll" | grep -q . || fail "the packed tree carries no $dll"
+        done
+        echo "ok: the VC++ runtime is beside the program and in the packed tree"
+    fi
+    if ! is_windows && ! is_macos; then
+        # QtGui's runtime closure comes from the payload: the program runs
+        # under the ecosystem's loader, which reads no host library directory.
+        "$MCPP" pack --format dir | tee target/ci/pack.log
+        for so in libQt6Widgets.so.6 libdbus-1.so.3 libxkbcommon.so.0 libfontconfig.so.1; do
+            find target/dist -name "$so*" | grep -q . || fail "the packed tree carries no $so"
+        done
+        echo "ok: the packed tree carries Qt and QtGui's runtime closure"
     fi
 }
 
+# The SDK at each level `rules-qt` consults, read back from the fact the rule
+# records (`rules-qt.sdk=<level>: <root>`, in the build program's cache).
+qt_sdk_consumer() {
+    cd "$ROOT/tests/qt-sdk-consumer"
+    rm -rf target
+    mkdir -p target/ci
+    sdk_fact() { grep -h -o 'rules-qt\.sdk=[^"]*' target/.build-mcpp/build.mcpp.cache | tail -1; }
+    "$MCPP" build 2>&1 | tee target/ci/build.log
+    "$MCPP" run | tee target/ci/run.log
+    grep -qE '^qt-sdk-consumer: Qt 6\.' target/ci/run.log || fail "the program did not load QtCore"
+    local fact root; fact=$(sdk_fact)
+    case "$fact" in "rules-qt.sdk=xlings: "*) ;; *) fail "the project's payload was not the SDK: $fact" ;; esac
+    root=${fact#rules-qt.sdk=xlings: }
+    echo "ok: the SDK is the payload the project declares ($root)"
+
+    # The payload's root, named for one machine, then by the build program.
+    QT_ROOT_DIR="$root" "$MCPP" build > target/ci/env-build.log 2>&1 || { cat target/ci/env-build.log; fail "the build under QT_ROOT_DIR failed"; }
+    fact=$(sdk_fact)
+    [ "$fact" = "rules-qt.sdk=QT_ROOT_DIR: $root" ] || fail "QT_ROOT_DIR was not the SDK: $fact"
+    echo "ok: QT_ROOT_DIR names the SDK, and a change re-plans the build"
+    QT_SDK_CONSUMER_ROOT="$root" QT_ROOT_DIR=/nonexistent "$MCPP" build > target/ci/options-build.log 2>&1 ||
+        { cat target/ci/options-build.log; fail "the build under options::root failed"; }
+    fact=$(sdk_fact)
+    [ "$fact" = "rules-qt.sdk=options: $root" ] || fail "options::root was not the SDK: $fact"
+    echo "ok: options::root names the SDK ahead of QT_ROOT_DIR"
+}
+
 case "${1:-}" in
     vcpkg-consumer)      vcpkg_consumer ;;
+    vcpkg-libcxx)        vcpkg_libcxx ;;
     archive-consumer)    archive_consumer ;;
     vcpkg-workspace)     vcpkg_workspace ;;
     cmake-consumer)      cmake_consumer ;;
     qt-consumer)         qt_consumer ;;
     qt-widgets-consumer) qt_widgets_consumer ;;
-    *) echo "usage: $0 vcpkg-consumer|archive-consumer|vcpkg-workspace|cmake-consumer|qt-consumer|qt-widgets-consumer"; exit 2 ;;
+    qt-sdk-consumer)     qt_sdk_consumer ;;
+    *) echo "usage: $0 vcpkg-consumer|vcpkg-libcxx|archive-consumer|vcpkg-workspace|cmake-consumer|qt-consumer|qt-widgets-consumer|qt-sdk-consumer"; exit 2 ;;
 esac
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index bda882c..9a6bace 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -1453,7 +1453,7 @@ jobs:
           # catch, so it must not introduce one.
           # THE MEMBERS THAT CARRY SOURCES, READ OUT OF THE MANIFEST. From 0.13.0 a
           # member family may hold features that add a payload and no source
-          # (`rules-qt-xim`, `dist-apk-kotlin`): they compile nothing this fixture
+          # (`dist-apk-kotlin`): they compile nothing this fixture
           # could miss, and naming them here would download an SDK on every host.
           # So the requirement is one-sided -- every source-carrying member of the
           # four families is named -- and the other side only checks spelling:
@@ -1638,7 +1638,7 @@ jobs:
       #
       # vcpkg keeps everything it reuses in one per-user directory -- its
       # binary cache (`archives/`), its registry cache (`registries/`) and,
-      # through `mcpp-deps`, its downloads -- so caching that directory is what
+      # through the member's `--downloads-root`, its downloads -- so caching that directory is what
       # makes the second run of a manifest a restore rather than a compile.
       - name: Cache vcpkg's per-user directory
         uses: actions/cache@v4
@@ -1650,6 +1650,13 @@ jobs:
       - name: deps-vcpkg installs a manifest as an action, and planning installs nothing
         run: bash .github/scripts/check-deps-and-qt.sh vcpkg-consumer
 
+      # Linux has two C++ standard libraries. Under a libc++ toolchain the
+      # ports build with mcpp's clang, and the two toolchains' prefixes coexist.
+      - name: deps-vcpkg and deps-cmake build with mcpp's clang under a libc++ toolchain
+        run: |
+          "$MCPP" toolchain install llvm 22.1.8
+          bash .github/scripts/check-deps-and-qt.sh vcpkg-libcxx
+
       - name: deps-archive extracts a zip the project keeps and deploys its tree beside the program
         run: bash .github/scripts/check-deps-and-qt.sh archive-consumer
 
@@ -1659,12 +1666,17 @@ jobs:
       - name: deps-cmake builds a CMake subproject as an action and links it
         run: bash .github/scripts/check-deps-and-qt.sh cmake-consumer
 
-      # A console program: QtCore, which is what Linux is served for. QtGui
-      # loads libdbus, which the ecosystem does not publish, so the Widgets
-      # fixture runs on Windows only.
-      - name: rules-qt runs moc, rcc, lupdate and lrelease, with the SDK from xim:qt-base
+      - name: rules-qt runs moc, rcc, lupdate and lrelease, with the SDK the project declares
         run: bash .github/scripts/check-deps-and-qt.sh qt-consumer
 
+      # The payload carries QtGui's runtime closure (libdbus, fontconfig, xcb,
+      # ...), so a Widgets program links, runs offscreen and packs on Linux.
+      - name: rules-qt builds a Widgets program with a .ui form, runs it offscreen and packs it
+        run: bash .github/scripts/check-deps-and-qt.sh qt-widgets-consumer
+
+      - name: rules-qt takes the SDK from the project's payload, QT_ROOT_DIR or options::root
+        run: bash .github/scripts/check-deps-and-qt.sh qt-sdk-consumer
+
   # ── THE SAME RULE ON THE OTHER TWO PLATFORMS ────────────────────────────────
   #
   # `rules-spirv` is the only member whose payload this ecosystem publishes for
@@ -1837,7 +1849,7 @@ jobs:
           # three hosts is the class of difference this job exists to catch.
           # THE MEMBERS THAT CARRY SOURCES, READ OUT OF THE MANIFEST. From 0.13.0 a
           # member family may hold features that add a payload and no source
-          # (`rules-qt-xim`, `dist-apk-kotlin`): they compile nothing this fixture
+          # (`dist-apk-kotlin`): they compile nothing this fixture
           # could miss, and naming them here would download an SDK on every host.
           # So the requirement is one-sided -- every source-carrying member of the
           # four families is named -- and the other side only checks spelling:
@@ -2337,11 +2349,14 @@ jobs:
       - name: deps-cmake builds a CMake subproject as an action and links it
         run: bash .github/scripts/check-deps-and-qt.sh cmake-consumer
 
-      - name: rules-qt runs moc, rcc, lupdate and lrelease, with the SDK from xim:qt-base
+      - name: rules-qt runs moc, rcc, lupdate and lrelease, with the SDK the project declares
         run: bash .github/scripts/check-deps-and-qt.sh qt-consumer
 
-      # Windows and macOS: QtGui's dependencies are the system's there. On Linux
-      # QtGui loads libdbus, which the ecosystem does not publish, so the Linux
-      # job runs the console fixture only.
-      - name: rules-qt builds a Widgets program with a .ui form, and it runs offscreen
+      # Windows: the payload carries the VC++ runtime Qt's DLLs import, so the
+      # program starts on a machine without the VC++ Redistributable. macOS:
+      # Qt loads system frameworks only.
+      - name: rules-qt builds a Widgets program with a .ui form, runs it offscreen and packs it
         run: bash .github/scripts/check-deps-and-qt.sh qt-widgets-consumer
+
+      - name: rules-qt takes the SDK from the project's payload, QT_ROOT_DIR or options::root
+        run: bash .github/scripts/check-deps-and-qt.sh qt-sdk-consumer
diff --git a/README.md b/README.md
index 2d282cc..7f041ff 100644
--- a/README.md
+++ b/README.md
@@ -1,22 +1,17 @@
 # mcpp-plugins
 
 The build plugins the mcpp project maintains, published as one package,
-`mcpp:plugins`. A consumer selects the members it needs through features and
-imports each one from `build.mcpp` under the module name the member declares.
+`mcpp:plugins`. mcpp is a general engine with a framework for build plugins;
+plugins come from this package, from third parties, or from the project
+itself, and `build.mcpp` is where a project uses them. A consumer selects the
+members it needs through features, imports each one from `build.mcpp` under the
+module name the member declares, and configures it there.
 
 ```toml
 [build-dependencies.mcpp]
-plugins = { version = "0.8.0", features = ["rules-spirv"], host-module = true }
+plugins = { version = "0.15.0", features = ["rules-spirv"], host-module = true }
 ```
 
-`[build-dependencies]`, not `[dependencies]`. The two keys answer separate
-questions: `host-module = true` says which build-time product is wanted, and
-the section says whether the package reaches the target. A rule package answers
-"no" to the second -- its library must never be linked into the artifact while
-its rule is still needed -- which is the case docs/05 section 2.6.1 exists for.
-Writing it under `[dependencies]` also works, which is precisely why the
-distinction has to be stated rather than left to a failure to teach.
-
 ```cpp
 // build.mcpp
 import std;
@@ -30,1074 +25,78 @@ int main() {
 }
 ```
 
+The edge is a `[build-dependencies]` entry, not a `[dependencies]` entry:
+`host-module = true` states which build-time product is wanted, and the section
+states that the package does not reach the target. A rule's library is never
+linked into the artifact (mcpp docs/05 §2.6.1).
+
 ## Naming
 
-| family | module name | purpose |
+| family | module | answers |
 |---|---|---|
-| rules | `mcpp.rules.<x>` | how one kind of translation unit is compiled by a compiler mcpp does not drive: the spelling of its flags, the probe of its toolkit, the actions it submits |
-| tools | `mcpp.tools.<x>` | a build-time utility independent of any compiler; see `tools/README.md` |
-| dist | `mcpp.dist.<x>` | what comes out of the link, and in what form a user installs it: an `.msi`, an AppImage, a signed `.app` |
-| deps | `mcpp.deps.<x>` | where a library comes from: a prefix a program mcpp does not drive installs (vcpkg, CMake), mapped into the build |
+| rules | `mcpp.rules.<x>` | how one kind of translation unit is compiled by a compiler mcpp does not drive |
+| tools | `mcpp.tools.<x>` | what the build program does itself (see [`tools/README.md`](tools/README.md)) |
+| dist | `mcpp.dist.<x>` | what comes out of the link, and in what form a user installs it |
+| deps | `mcpp.deps.<x>` | where a library comes from |
 | identity | `mcpp.plugins` | the lib root, compiled before every member; it states the collection's version |
 
-The four families answer four different questions, and the prefix is which
-one a member answers:
-
-```
-rules-*   how is this translation unit compiled
-tools-*   what does the build program need to do itself
-dist-*    what comes out of the link, and in what form a user installs it
-deps-*    where does a library come from
-```
-
-A `dist-*` member fits neither of the first two definitions: it does not
-compile a translation unit and it does not do its work while the build program
-runs. It consumes **link outputs** through a `role = "artifact"` action, reached
-with `mcpp pack --format <name>` (mcpp 2026.9.11.1+). The prefix matters because
-the taxonomy is load-bearing -- a consumer reading `rules-wix` would expect a
-compiler it does not drive and a translation unit, and there is neither.
-
-A `deps-*` member compiles none of the project's translation units and does not
-do its work while the build program runs: the installation is a `prepare`
-action (mcpp's SPEC-007, docs/specs/build-plugins.md), which fills a declared
-output directory and which the package's compile and link edges wait for, and
-whose command is `mcpp-deps`, a program built from this package. The build
-program refers to the prefix by name -- include directory, libraries by full
-path, runtime search directory -- and never by what is in it, so a plan made
-before the installation is the plan made after it.
-
-The `mcpp.` prefix is reserved for this package: mcpp warns when a module under
-it is declared by a package outside the `mcpp` namespace. `mcpp.build.*` is the
-engine's own module family and is not used here.
+The `mcpp.` prefix is reserved for this package. The full account of the
+families, and of how the engine routes a file to a rule, is in
+[docs/engine-and-rules.md](docs/engine-and-rules.md).
 
 ## Members
 
-| feature | module | since mcpp | what it needs |
-|---|---|---|---|
-| `rules-ascendc` | `mcpp.rules.ascendc` | 2026.9.6.6 | `[build] accel = "ascend8.5+{dav-c220}"`, a constrained glob for `*.asc`. Compiles with BiSheng in MIXED mode, so the object carries the device binary and a host-callable launcher and joins the ordinary link -- no registration file and no device-link step. Its own engine needs are `.asc` in the device-source table and `mcpp::link_flag` for the `-rpath-link` the toolkit's shared libraries require, both 2026.9.6.5 |
-| `rules-cuda` | `mcpp.rules.cuda` | 2026.9.6.6 | `[build] accel = "cuda…"`, a constrained glob for `*.cu`; the clang route with an LLVM toolchain, the nvcc route with a GCC one |
-| `rules-hip` | `mcpp.rules.hip` | 2026.9.6.6 | `[build] accel = "hip, cuda12.9+{sm_89}"`, a constrained glob for `*.hip`. On the NVIDIA platform HIP is a header layer over the CUDA runtime, so the compiler is the project's own clang and there is no ROCm on the machine |
-| `rules-metal` | `mcpp.rules.metal` | 2026.9.8.1 | the Metal toolchain of the macOS host's Xcode, located rather than installed: Xcode is not redistributable, so no payload is declared. `.metal` sources the project names on a macOS or iOS row become one `xcrun --sdk <sdk> metal` action per shader (`-MMD`, so an edited `#include` recompiles the shaders that include it) and one `xcrun --sdk <sdk> metallib` action per library, placed beside the program with `mcpp::deploy` under `metallib/`, which `dist-apple` maps into the bundle's resources. `compile(shaders)` compiles one source several times with definitions of its own, one library per `shader`; `options::library` links every shader into one library (`default` is the one `newDefaultLibrary` finds). Before planning anything the rule asks `xcrun --sdk <sdk> --show-sdk-path` and `--find metal` / `--find metallib`, and refuses naming the command that answered nothing, because a missing SDK and a missing compiler have different remedies (Xcode 26 installs the Metal toolchain as a separate component). A shader on any other row is refused naming the row. CI compiles the fixture on `macos-15` and checks each library's magic, and that a header edit recompiles only the shaders that include it |
-| `rules-qt` | `mcpp.rules.qt` | 2026.9.26.2 (mcpp#702) | a Qt 6 SDK: `rules-qt-xim` declares `xim:qt` 6.11.1 on the target axis, `rules-qt-xim-base` declares `xim:qt-base` instead (qtbase and qttools with the QtQml library lupdate loads, about a third of the download; 0.14.0), `rules-qt-xim-addons` adds `xim:qt-addons` (the additional libraries) as a second prefix, and `options::root` names an SDK from elsewhere. From 0.13.0. `moc` for every header under the package root that declares `Q_OBJECT`, `Q_GADGET` or `Q_NAMESPACE` and for a source that includes its own `<stem>.moc`; `uic` for `.ui`, `rcc` for `.qrc`, `lrelease` for `.ts` (named in `[build] sources` or in the options), each a `role = "source"` action with declared inputs. The modules are linked by full path, and the SDK's `bin/` (Windows) or `lib/` is a runtime search directory: the program's run path, `mcpp run`'s load path, `mcpp pack`'s closure, and on Windows the Qt DLLs the program imports placed beside it by the engine. The plugin directories `deploy_plugins` names are deployed beside the program. See [`deps-vcpkg`, `deps-cmake`, `deps-archive` and `rules-qt`](#deps-vcpkg-deps-cmake-deps-archive-and-rules-qt) |
-| `rules-slang` | `mcpp.rules.slang` | 2026.9.7.1 | `[build] accel = "vulkan1.2"`, a constrained glob for `*.slang`. Slang is a different language from GLSL rather than a second driver for it -- its own module system, generics, and targets beyond SPIR-V -- so it is a rule of its own. `.slang` is **not** in the engine's device-source table: this feature declares `device_extensions = [".slang"]` and `rule_module = "mcpp.rules.slang"`, and the engine routes it from there. That is the criterion for the whole arrangement -- a new device language costs no engine release. Since 0.7.0 it has the same `options::storage` axis as `rules-spirv` (header / object / sidecar), `options::extra_args` for the arguments the rule has no field for, and `options::per_file` for what one shader gets that the others do not -- a project with a `-fvk-use-gl-layout` and one shader needing `-emit-spirv-via-glsl` writes both without leaving one `compile()` call |
-| `rules-spirv` | `mcpp.rules.spirv` | 2026.9.6.6 | `[build] accel = "vulkan1.2"`, a constrained glob for the shader stages; compiles each shader through a `role = "source"` action and states which of the two compilers produced it |
-| `rules-swift` | `mcpp.rules.swift` | 2026.9.8.1 | the Swift compiler of the macOS host's Xcode or Command Line Tools, located rather than installed, as `rules-metal` locates its toolchain. From 0.12.0. The `.swift` sources a project names on a macOS or iOS row compile as one module named after the package: one whole-module `xcrun --sdk <sdk> swiftc -wmo -emit-object -target <triple>` action whose role is `object`, so the object joins every image of the package, and one `swiftc -typecheck -emit-objc-header-path` action whose role is `source`, whose directory `mcpp::include_dir` adds, so the package's C and C++ sources include `<module>-Swift.h`. `options::bridging_header` names a C header Swift sees without an import. The link receives the toolchain's `usr/lib/swift/<platform>` and the SDK's `usr/lib/swift` as search directories and `/usr/lib/swift` as a run path through `mcpp::link_flag`. Before planning anything the rule asks `xcrun --sdk <sdk> --show-sdk-path` and `--find swiftc`, and refuses naming the command that answered nothing; a Swift source on any other row is refused naming the row. Not supported: a Swift `import` of another package's module, and another package's C++ including this package's generated header, which both need an engine channel that publishes a package's interface directory to its dependents; and SwiftPM dependencies. CI builds `tests/swift-consumer` on `macos-15` -- a C++ program calling a `@_cdecl` Swift function that calls back into C -- and runs it |
-| `rules-sycl` | `mcpp.rules.sycl` | 2026.9.6.6 | `[build] accel = "sycl"` or `"sycl, cuda12.9+{sm_89}"`, a constrained glob for `*.sycl`, and `compat:sycl-runtime` so the artifact can reach `libsycl.so.9` at run time. Its own engine need is `.sycl` in the device-source table, 2026.9.6.1 |
-| `tools-embed` | `mcpp.tools.embed` | 2026.9.5.4 | nothing beyond mcpp: it reads a file and writes a header while the build program runs. The floor is the release whose fast path compares a declared file input, without which an edit to the data does not reach the binary |
-| `tools-island` | `mcpp.tools.island` | 2026.9.7.1 | nothing beyond mcpp: it reads marked entry points out of an island's own source and writes the `extern "C"` boundary header its compiler reads and the module the C++ side imports. Not a device rule -- it claims no extension, and a project calls it from its own `build.mcpp` |
-| `dist-appimage` | `mcpp.dist.appimage` | 2026.9.11.1 | `xim:appimagetool`, which this feature declares on the `cfg(linux)` axis. Linux only. Turns the tree `mcpp pack` staged into one AppImage: the staged bundle is already an AppDir bar three files, so the member writes an `AppRun`, a `.desktop` entry and an icon into it and invokes one tool -- it never copies or re-lays-out a tree that can be hundreds of megabytes. From 0.11.1 `options::icon` may be an SVG as well as a PNG: the image carries `<name>.svg`, because the desktop entry names the icon without an extension and a reader finds it by the file's, and any other format is refused by name |
-| `dist-wix` | `mcpp.dist.wix` | 2026.9.11.1 | `xim:wix` 5.0.2-1, which this feature declares on the Windows target axis; the .NET 6 runtime the tool needs is a Windows component the payload does not carry, and `wix --version` names it when it is missing. Windows only. `--format msi` renders a `.wxs` and passes the program in as a preprocessor variable, because a bind path that resolves to nothing is silent. From 0.10.0 `--format setup` is a Burn bundle chaining that MSI, with WiX's stock bootstrapper application (`bal:WixStandardBootstrapperApplication`, theme `hyperlinkLicense`, `options::license_url` its link) loaded through the `WixToolset.BootstrapperApplications.wixext` extension the 5.0.2-1 payload carries (`options::extension` names another). The bundle is written as `<product_name>-<arch>.exe` beside the MSI, with an UpgradeCode of its own, and `options::bundle_output` naming `setup.exe` is refused before `wix` runs, because `wix` refuses that name (WIX0388). A project with its own bootstrapper application supplies `options::bundle_wxs`, which receives the MSI as `$(Msi)`. From 0.10.1 the MSI installs the staged tree, not the program alone: every file `mcpp pack` stages beside the program (a deployed file, a resolved DLL) is named file by file in a `StagedFiles` component group written beside the definition -- enumerated while the tree exists, never harvested from a directory -- placed at its staged path under `INSTALLFOLDER`, and declared an input of the action; the generated definition references the group, and a project's own `options::wxs` installs it with `<ComponentGroupRef Id="StagedFiles" />`. `options::inputs` and `options::bundle_inputs` declare the files a project's own definitions name beyond that (an icon, a bootstrapper application and its payloads). CI builds the bundle on `windows-2022` and compares the MSI `wix burn extract` takes out of it with the one the first action wrote, and installs the MSI administratively and compares both the program and a deployed file |
-| `dist-apple` | `mcpp.dist.apple` | 2026.9.14.2 (0.10.0); 2026.9.11.2 (macOS) and 2026.9.12.3 (iOS) before it | the base macOS install (`ditto`, `codesign`, `hdiutil`), and `xim:macapp-run` for `mcpp run` on macOS, which this feature declares with `when = "run"`. macOS: `Contents/`-shaped, as always. iOS (`aarch64-ios-sim`, `aarch64-ios`): a flat bundle at the same call site -- no separate feature, no separate module -- with `MinimumOSVersion` from `mcpp::min_platform_version()` (#622 A11), `CFBundleSupportedPlatforms` read from `env == "sim"`, `UIDeviceFamily`, `LSRequiresIPhoneOS`, and a directory of flat PNGs listed under `CFBundleIcons` in place of macOS's single `.icns` file. Signing is skipped on the simulator row (`options::identity` is ignored, with a `mcpp::warning` naming why), and the device row signs only with an identity. The iOS row is measured end to end on `macos-15`: a real `mcpp build`, `mcpp pack --format app` and `mcpp run` against `aarch64-ios-sim`, through `xim:apple-simulator-tools`' `simctl-run`. **The macOS floor is one release higher than its siblings** and the reason is not this member: under 2026.9.11.1 `mcpp pack` staged before dispatching and let a staging failure fail the command, so on a Mach-O program -- which the built-in closure walk refuses, because it uses `LD_TRACE_LOADED_OBJECTS` and dyld answers that by running the program -- every dispatched format was unreachable, including one that reads no staged tree. 2026.9.11.2 makes staging a service to the provider. From 0.9.2 the staged tree's deployed files (`bin/<to>/...`, which the engine stages for a Mach-O program before the closure walk since the release for mcpp#630) land at the bundle's resource destination -- `Contents/Resources/<to>/...` on macOS, the bundle root on iOS -- and the launcher alone goes to the executable directory, so `CFBundleExecutable` names a file that is where it says. The iOS fixture declares `llvm.libcxx` and `llvm.compiler-rt-builtins` under `cfg(os = "ios")`, which is what an application that imports `std` on those rows declares. From 0.10.0, with mcpp 2026.9.14.2: the dylibs the engine stages beside a Mach-O program, which the stage manifest's `needs` lines name, go to `Contents/Frameworks/` (`Frameworks/` on iOS) and not to the resources; the program is linked with the rpath that finds them there (`@executable_path/../Frameworks`, `@executable_path/Frameworks` on iOS) through `mcpp::link_flag`, so no file is edited after the link; a macOS bundle without `options::identity` is signed ad hoc, frameworks first and the bundle second, which `codesign --verify --deep --strict` requires of a bundle that carries a framework; an incomplete closure is a `mcpp::warning` naming the unresolved libraries; every refusal is a `mcpp::warning` as well, because the engine discards a build program's output when it exits 0. On macOS the member supplies the runner named `app` (`macapp-run`), so `mcpp run --format app` runs the bundle's executable in the foreground and returns its status with no runner in the manifest; a manifest runner of that name wins. `--format dmg` stages the bundle beside an `Applications` link and writes a UDZO image with `hdiutil create` (`options::volume_name`, `options::dmg`); it is refused on iOS. An engine below 2026.9.14.2 stages no `needs` lines, so the bundle carries no framework, anchors the rpath to the package directory, and hands the bundle directory to the kernel under `mcpp run --format app` unless `--runner app` is typed. CI measures the bundle on `macos-15`: the load command, the signature, the program with and without its framework (exit 7, then "Library not loaded"), `mcpp run --format app` with and without `--runner app`, and `hdiutil verify` and an attached image. From 0.11.0: a project's own Info.plist entries (`options::info_plist`), an iOS device bundle's provisioning profile (`options::provisioning_profile`), and `devicectl-run` (`xim:apple-device-tools`) as the device row's runner named `app` -- see [`dist-apple`: a project's Info.plist, and an iOS device](#dist-apple-a-projects-infoplist-and-an-ios-device). From 0.12.0 `options::omit_keys` leaves out a key the member only defaults -- see [`dist-apple`: a project's Info.plist, and an iOS device](#dist-apple-a-projects-infoplist-and-an-ios-device). From 0.12.0 a package in the resolved graph contributes Info.plist entries through `[package.metadata.dist-apple]`, applied before the application's own |
-| `dist-web` | `mcpp.dist.web` | 2026.9.13.1, the release that carries `${mcpp.self}` and `mcpp stage`'s argument shape as an engine contract (`stage --verify content --output <dst> <src>`) -- what lets this member's copy run on every host mcpp does, Windows included, in place of the `cp` this member used through 0.8.0 | nothing beyond mcpp: `wasm32-emscripten` only. Copies `${mcpp.stage_dir}/bin/` -- the `.js` launcher, the implicit `.wasm`, the `.data` when present, and every `mcpp::deploy`'d file, all of which #622 A5 and A4 already stage there -- to `<out_dir>/web/`, dropping the `bin/` prefix a browser has no use for, and writes an `index.html` rendered from a project template or a built-in default that loads the script with a plain `<script src>`. Each staged file and the rendered page are copied with `${mcpp.self} stage --verify content --output <dst> <src>`, the same copier every `stage_file` edge in `build.ninja` already runs -- no host-specific copy tool, no plan-time `create_directories` (`stage` creates the destination's parent), and a second `mcpp pack --format web` with nothing changed copies nothing. From 0.12.0 `options::page` names the page (`index.html` by default), for a project whose other build names it after the target; a name that is not a bare `*.html` file name is refused at plan time |
-| `dist-apk` | `mcpp.dist.apk` | 2026.9.14.2 from 0.10.0, which stages the closure this member reads; before it 2026.9.13.1, raised alongside `dist-web` in the same 0.9.0 release: this member's own manifest-template and Java-array changes ask nothing new of the engine, but this collection publishes one package at one version, and this is the release CI verifies it under from here on | `xim:android-build-tools`, `xim:android-platform` (versioned by API level, read back for `targetSdkVersion`), `xim:jdk-temurin` (`javac`/`jar`/`jarsigner`; `android-build-tools`' own runtime dependency provisions a JDK for its OWN wrappers only), `xim:android-debug-keystore`, `xim:bundletool` (0.10.0, for `--format aab`), all on the `cfg(env = "android")` axis. Generates `AndroidManifest.xml` and signs with the published Android debug key by default. Level 0 needs no Java (`hasCode="false"`, `android.app.NativeActivity`); `options::java_sources` adds `javac` + `d8` and a real `<activity>`. `options::manifest_template` renders a project manifest with six tokens substituted verbatim; `{{application_id}}` and `{{activity}}` are required always and `{{lib_name}}` at level 0, each refused by name at plan time when missing (naming `assets/mcpp-run.json`, which `adb-run` reads them from too) or when the template names an unknown token; empty renders 0.8.0's manifest byte-identically. From 0.9.3 the manifest template gains `{{version_name}}` / `{{version_code}}` (the package version, and `major * 1000000 + minor * 1000 + patch`). `options::resources` is a project's own `res/`, linked as the application's base resources from 0.9.1 (0.9.0 linked it as an aapt2 overlay, which refuses every resource the base does not already define -- a launcher icon could not be supplied). `options::java_sources` is an array: one `javac` over every root's `.java` files and one `d8` over the result, so a project's own sources and a path dependency's join without being merged into one directory first, and `rerun_if_changed_glob` is declared only for a root under `mcpp::manifest_dir()` -- a dependency root's files are already inputs of the `javac` action and its version is already in the build's fingerprint. Android only -- an `app` target is a shared object on this row (#622 A3). From 0.10.0, with mcpp 2026.9.14.2, the member reads the native closure the engine stages -- the application object, the graph's shared libraries and `libc++_shared.so` under `lib/` for one `--target`, `lib/<abi>/` for several -- and packs every ABI the tree carries into one APK; its own `NEEDED` walk and the stamp that lost a dependency's library on a second pack are gone. A stage manifest without `needs` lines comes from an engine below 2026.9.14.2 and is refused naming that floor, as is an incomplete closure, naming the unresolved libraries; every refusal is also a `mcpp::warning`, because the engine discards a build program's output when it exits 0. `--format aab` shares every step but the last three: `aapt2 link --proto-format` (with `--version-code` / `--version-name`, which bundletool requires), a base module in the layout bundletool reads, `bundletool build-bundle` from `xim:bundletool` (declared on the same axis), and `jarsigner` with the same keystore. CI packages both level 0 and level 1 and checks the archive (`mcpp::deploy`'d files under `assets/`), and on `tests/apk-consumer-shared` two packs in a row, a two-ABI APK (`aapt2` reports both, `apksigner` verifies it), an App Bundle (`bundletool validate`, `jarsigner -verify`, a universal APK from `bundletool build-apks`), a refusal's reason in `mcpp pack`'s output, and the floor refusal; the runner has no emulator or device, so the two rows that actually run were measured locally on 2026-09-12, through `adb-run`, against a KVM-accelerated x86_64 emulator and a physical arm64-v8a phone, both printing `1-2-3` and exiting 0. From 0.11.0: Kotlin sources (`dist-apk-kotlin`, which declares `xim:kotlin`), R classes, Android libraries from source, local AARs and JARs, a Maven graph through a lock file (`dist-apk-maven`, which declares `xim:coursier`), a manifest merge, and an unsigned package -- see [`dist-apk`: Kotlin, libraries and a Maven graph](#dist-apk-kotlin-libraries-and-a-maven-graph). From 0.11.1 the native libraries are packed as the Android Gradle plugin packs them: each is stripped with the build's own `llvm-strip --strip-unneeded` (the NDK's, beside the compiler `mcpp::toolchain_dir()` reports; `options::keep_debug_symbols` packs them as staged), and a manifest stating `android:extractNativeLibs="false"` gets them stored uncompressed on a 16 KB page, which loading them from the APK in place requires; CI checks both, and the symbol table `keep_debug_symbols` keeps. From 0.12.0 the engine's strip decision governs these libraries as well: under mcpp 2026.9.16.1, which publishes it to build programs as `MCPP_PACK_STRIP` and `MCPP_PACK_DEBUG_SYMBOLS_DIR`, that engine strips and separates the libraries it stages itself and the member packs them as staged, while the libraries the engine did not stage -- an archive's `jni/` libraries -- follow the same decision inside the member: `--no-strip` packs them as they are, and `--debug-symbols <dir>` separates each one's debug information into `<dir>/<abi>/<library>.debug` with `llvm-objcopy` before stripping it and linking the packed copy to that file (`.gnu_debuglink`). A library is stripped unless either `keep_debug_symbols` or the engine says to keep it, and under an older engine, which publishes neither variable, the member strips every library as before. Because that engine strips before the member reads the tree, `keep_debug_symbols` keeps only the member's own strip off and `--no-strip` is what ships the symbols of the libraries the graph built; the member warns when the option is set and the engine stripped. From 0.12.0 a library in the resolved graph contributes libraries and archives through `[package.metadata.dist-apk]`, ranked below the application's own -- see [A library states its contribution](#a-library-states-its-contribution-packagemetadatadist-apk) |
-| `deps-vcpkg` | `mcpp.deps.vcpkg` | 2026.9.26.2 (mcpp#702) | `xim:vcpkg` (the tool and the scripts released with it), which this feature declares on the host axis, and `tools = ["mcpp-deps"]` on the edge. From 0.13.0. Installs a `vcpkg.json` manifest as a `prepare` action and maps `<install root>/<triplet>` into the build by name, its shared-library directory a runtime search directory; `mcpp emit build-database` installs nothing. See [`deps-vcpkg`, `deps-cmake`, `deps-archive` and `rules-qt`](#deps-vcpkg-deps-cmake-deps-archive-and-rules-qt) |
-| `deps-cmake` | `mcpp.deps.cmake` | 2026.9.26.2 (mcpp#702) | `xim:cmake`, which this feature declares on the host axis, and `tools = ["mcpp-deps"]` on the edge. From 0.13.0. Configures, builds and installs a CMake subproject as one `prepare` action whose inputs are the subproject's files, and maps the prefix as `deps-vcpkg` does |
-| `deps-archive` | `mcpp.deps.archive` | 2026.9.26.2 | `xim:cmake`, which this feature declares on the host axis, and `tools = ["mcpp-deps"]` on the edge. From 0.14.0. Extracts a zip archive the project keeps and places its tree beside the program: one action names every member as an output, read from the archive's central directory while the build program runs, and each is deployed, so `mcpp run` finds the files and `mcpp pack` carries them. See [`deps-vcpkg`, `deps-cmake`, `deps-archive` and `rules-qt`](#deps-vcpkg-deps-cmake-deps-archive-and-rules-qt) |
-
-### Each rule brings its own environment
-
-A project names the rule and nothing else:
-
-```toml
-[build-dependencies.mcpp]
-plugins = { version = "0.8.0", features = ["rules-cuda"], host-module = true }
-```
-
-The payloads each rule drives are declared **here**, under the feature that
-selects the rule and the accelerator it serves:
-
-```toml
-[target.'cfg(accelerator = "cuda")'.feature-xlings.rules-cuda]
-"xim:cuda-nvcc"   = "12.9.86"
-"xim:cuda-cudart" = "12.9.79"
-```
-
-Two gates, and both must open before a byte is downloaded. The feature says
-whether the rule is wanted; the selector says whether this build compiles for
-the device. A CPU-only build opens neither.
-
-**The shape of each default is a judgement about coupling.** An exact version
-where the payload is coupled to something the rule cannot see -- a CUDA runtime
-must not be newer than the driver it will meet, so the 12.9 line is offered and
-a project with newer machines names 13.x itself. A floor (`>=`) where no such
-coupling exists: a shader compiler, a SYCL compiler, a CANN toolkit.
-
-mcpp reads the difference. A bare version is a **choice**, so a project pinning
-a different one wins and the override is reported; a `>=` is a **requirement**,
-so a project pinning below it is refused naming both sides. Either way one
-version is installed. To override:
-
-```toml
-[target.'cfg(accelerator = "cuda")'.xlings.workspace]
-"xim:cuda-nvcc" = "13.3.33"
-```
-
-**What is not here:** anything the produced program chooses to run *on*. A
-Vulkan ICD (`xim:mesa-lavapipe`) is a device, and a rule that declared one would
-force a software renderer onto consumers that have a GPU. The runtime adapters
-(`compat:cuda-runtime`, `compat:sycl-runtime`, `compat:vulkan-runtime`) stay in
-the project for that reason and for a second one: this package is reached
-through a `[build-dependencies]` edge, so its own `[dependencies]` deliberately
-do not reach the consumer's target.
-
-### Each rule takes the extensions it claims
-
-`mcpp::device_sources()` is the package's WHOLE device set, not one rule's
-share of it, and every rule in a build program reads the same variable. A
-project with two backends puts a `.cu` and a `.comp` in that one list.
-
-Each rule therefore selects the extensions it claims and leaves the rest:
-
-| feature | claims |
-|---|---|
-| `rules-ascendc` | `.asc`, `.cce` |
-| `rules-cuda` | `.cu` |
-| `rules-hip` | `.hip` |
-| `rules-metal` | `.metal` |
-| `rules-qt` | `.ui`, `.qrc`, `.ts`; a header is found by what it declares, since `.h` is already C++ |
-| `rules-slang` | `.slang` |
-| `rules-swift` | `.swift` |
-| `rules-sycl` | `.sycl` |
-| `rules-spirv` | `.comp .vert .frag .geom .tesc .tese .mesh .task .rgen .rint .rahit .rchit .rmiss .rcall`, and `.glsl` / `.hlsl` so that a stage-less name is refused by name rather than by absence |
-
-A rule whose backend this build does not name returns immediately, so a build
-program may call every rule it imports unconditionally and `--no-accel`
-compiles nothing.
-
-A device source that NO rule claims is not silently dropped: mcpp refuses a
-device source that reached no action, naming the file. That is the engine's
-half of this rule and it needs 2026.9.6.5.
-
-The floor is the mcpp release whose engine carries what the member relies on.
-From 0.4.0 every rule shares one: **2026.9.8.1**, the release in which a
-package's host modules are ordered by their IMPORT GRAPH rather than by their
-paths. This package needs that: `src/declare.cppm` is imported by every member,
-and `rules/` sorts before `src/`, so before that release the members were
-compiled first and failed with "failed to read compiled module".
-
-**The floor could have been avoided, and was not.** `src/declare.cppm` sorts
-after `rules/`, which is exactly why it needs the ordering fix -- and naming it
-`aa_declare.cppm` at the package root would make the old PATH order happen to be
-correct, so 0.4.0 would run on 2026.9.7.1 with no floor move at all. That is
-declined on purpose: it encodes a load-bearing constraint in a filename with
-nothing enforcing it, which is the fragility the engine fix removes. A file
-renamed for a reason nobody can see is a defect waiting for the rename that
-looks harmless.
-
-0.5.0, 0.5.1 and 0.5.2 do not move it. Naming an island's entry points is a
-change to what this package generates, not to what it asks the engine for.
-
-0.7.1 does not move it either, and records a compiler rather than an engine:
-under MSVC 14.52 (36629 and 36725, measured on xrgui's CI) a module that has
-instantiated `std::filesystem::path`'s iterator poisons every importer that
-touches `path` again -- `filesystem(1572): error C2801: '_Path_iterator<...>::operator =='
-must be a non-static member`. Nothing in this package instantiates that
-iterator now: the lib root reads paths apart as strings
-(`mcpp::plugins::names::components`), and the members' relative-path
-arithmetic is `mcpp::plugins::names::relative_to`.
-
-The previous shared floor was 2026.9.7.1, the release that reads
-`device_extensions` and `rule_module`, reports `[language] modules` and the
-package's own name to a build program, writes the build program a declared rule
-set describes, and gives `mcpp::action` its `depfile` field. A client below it
-does not get a degraded surface; it gets a build in which the rules never route
--- the file falls through to the ordinary source scan and mcpp says it has no
-role for the extension.
-
-The previous shared floor was 2026.9.6.6, the release in which a payload a
-DEPENDENCY declared is both installed and answerable. Before it a rule could
-declare `>=8.5.0`, have it installed, and still be told by `xpkg_dir` that
-nothing was there -- which is why each rule's list used to be repeated in every
-project that used it. The earlier per-member floors are still the floors of the
-rules themselves (`rules-spirv` needs the shader extensions in the device-source
-table, 2026.9.5.3; `tools-embed` needs the fast path to compare a declared file
-input, 2026.9.5.4; `rules-sycl` needs `.sycl` in that table, 2026.9.6.1), and
-they are all below the shared one.
-
-`rules-slang` is the member that does NOT appear in that list, and its absence
-is the point: `.slang` is in no engine table at any version. The feature
-declares the extension and the module that compiles it, so the release it needs
-is the one that reads those two keys rather than the one that would have carried
-its extension.
-
-0.10.0 moves the collection's floor to **2026.9.14.2**, and the reason is two
-members rather than the rules: `dist-apk` and `dist-apple` read the native
-closure the engine stages and names in the stage manifest's `needs` lines,
-`dist-apple`'s framework rpath needs the engine to leave an `@executable_path`
-rpath as written, and `mcpp run --format app` reaches the runner named after the
-format only from that release. `rules-metal` itself needs nothing past
-2026.9.8.1. An older engine is not left to fail silently: `dist-apk` refuses a
-stage without `needs` lines, naming the release.
-
-The index descriptor states the highest floor among the members, so it is the
-floor of the collection rather than of any one feature; a project on an older
-mcpp is refused at resolution rather than at the first shader.
-
-## What a consumer names
-
-A member that embeds a payload -- `rules-spirv`, `rules-slang`, `tools-embed` --
-does not leave the consumer to include a generated header. All three hand their
-payloads to one generator, `mcpp::plugins::surface`, so what a consumer writes
-is the same whichever produced them:
-
-```cpp
-import myapp.shaders;
-
-const auto s = myapp::shaders::blur_comp();
-VkShaderModuleCreateInfo ci{ .codeSize = s.size_bytes, .pCode = s.code };
-```
-
-### From a file name to a call
-
-Every name a consumer writes is derived, and derived one way, so nothing has to
-be looked up:
-
-```
-base directory   shaders/                  derived: the shallowest directory
-                                           every payload shares
-file             shaders/post/tone.frag
-                         └── the path below the base
-module           myapp.shaders             package name + group
-namespace        myapp::shaders::post      the module name segment by segment,
-                                           then the directory's segments
-identifier       tone_frag                 stem + stage, non-identifier
-                                           characters replaced by `_`
-call             myapp::shaders::post::tone_frag()
-```
-
-`myapp` comes from the package unless the project sets `options::module_name`;
-the base directory is derived unless it sets `options::base_dir`.
-
-Three invariants, and each exists because its absence was a defect:
-
-- **The module name and the namespace are the same identifier path**, `.` for
-  `::`. A reader never has to learn which namespace a module opens.
-- **The directory reaches the generated file's path and the linker symbol, not
-  only the namespace.** Two shaders sharing a stem in different directories
-  produced byte-identical generated headers, and GCC's `#pragma once` treats two
-  files with the same size and content as the same file -- so the second include
-  did nothing and both accessors returned the first array, while the program
-  printed the right magic number twice.
-- **The stage is always part of the identifier**, so `blur.comp` and `blur.frag`
-  do not collide. Uniformly rather than only when needed: conditional naming is
-  worse than verbose naming.
-
-
-
-**The interface is a function, and it names no standard-library type.** A
-variable cannot keep one shape across the ways bytes can be stored, because
-`constexpr` and `extern` are mutually exclusive. A std type in the interface is
-worse than it looks: measured with GCC 16.1 on a 1 MB payload, an interface
-returning `std::span` produced a 1 313 968-byte BMI against 1 808 bytes for the
-std-free equivalent, and that cost is fixed rather than proportional to the
-payload -- it is `<span>`'s templates, present whether the payload is 16 KB or
-16 MB. A consumer that wants a `std::span` constructs one from the two members.
-
-**Where the bytes live is a second, independent choice.** The surface decides how
-a consumer names a payload; `storage` decides where it sits. The declarations are
-identical under all three, so a project changes this and no consumer changes.
-
-| storage | the payload is | reach for it when |
-|---|---|---|
-| `header` (default) | a C array in generated source, compiled in | almost always |
-| `object` | a section, through `.incbin` in a generated `.S` | total payload is large |
-| `sidecar` | a file beside the artifact, read at run time | hot reload, or a payload too large to link |
-
-**Every payload a compile reads is in the build graph.** Two mechanisms carry
-that, and which one applies is decided by WHEN the thing is known.
-
-A shader's `#include` is discovered by the compiler while it runs, so it arrives
-afterwards, in a depfile. `mcpp::action::depfile` carries it and all six rules
-pass one -- each spelling measured against the tool rather than read from its
-help text.
-
-An `.incbin` is discovered by nobody. The assembler opens the file at assembly
-time; the generated `.S`'s own text does not change when the payload does; the
-object is assembled once. Measured on 0.3.0, in a sandbox against the published
-packages: editing a shader left the program printing the previous payload's byte
-count, with a green build.
-
-Asking the assembler does not fix it, and that was measured rather than assumed.
-The compiler driver's `-MD` is a preprocessor channel that never sees `.incbin`;
-GNU as names it in its own `--MD`; clang's integrated assembler has no
-dependency output of any kind. Tracking it that way would work under GCC and
-fail silently under Clang -- worse than failing under both.
-
-**So under `object` storage the generation is an ACTION and the payloads are its
-declared inputs.** That is the one graph primitive the engine has, used for what
-it is: a payload changes, the action reruns, its outputs count as new, and the
-edge that assembles them reruns. The command is `mcpp-embed`, built from this
-package through `tools = ["mcpp-embed"]` -- not published separately, because
-docs/05 section 2.14 states what that costs: "the tool's version IS the
-dependency's version, so a `protoc` that does not match its runtime is not
-expressible."
-
-`header` and `sidecar` need none of it, and that was checked rather than
-assumed. Under `header` the bytes reach the artifact through generated data
-headers the payload's own compiler already writes as action outputs; under
-`sidecar` they are never compiled at all. So the default path builds no tool,
-and a consumer that never opts into object storage writes nothing extra.
-
-**Which one is a measurement, not a preference.** With GCC 16.1 on 100 payloads
-of 16 KB each -- the size of an ordinary compute shader:
-
-```
-header route   compile 0.64s + link 0.44s                = 1.10s
-object route   convert 1.28s + compile 0.44s + link 0.46s = 2.17s
-```
-
-The header route is faster, because at that size neither route has a measurable
-marginal cost and the total is decided by how many processes start; one compiler
-invocation absorbs many headers. The crossover is the TOTAL embedded byte count
-rather than the payload count: below about 1 MB the header route wins, and above
-about 4 MB the compiler's slightly superlinear curve loses by an order of
-magnitude (2.31s against 0.116s). Source expansion is a constant 2.75x.
-
-**`object` needs a GAS assembler.** Every gcc and clang toolchain has one on all
-three platforms; MSVC does not, and mcpp refuses `.S` under it, so the emitter
-falls back to `header` there and says so once. The surface does not change, so a
-consumer compiled either way is the same source.
-
-**`sidecar` states its cost rather than hiding it.** The accessor opens a path
-relative to the working directory, so the program finds its payloads when run
-from the package root and does not when run from elsewhere -- which is why it is
-not the default, and why `mcpp pack` of such a program has something further to
-collect. `tests/spirv-sidecar` and `tests/slang-sidecar` assert both halves: found
-from the root, and reported missing from `/tmp`.
-
-**The default follows the project.** `[language] modules = true` gives the
-module surface, `false` gives a header with the same declarations. mcpp reports
-the setting as `MCPP_LANGUAGE_MODULES`; an engine that does not report it leaves
-the header surface in place, so an older engine keeps the behaviour every
-consumer of this package had before the surface existed.
-
-**The generator is not shader-specific, and three members already share it.**
-`mcpp::plugins::surface` knows about a run of bytes, a name, where it lives and
-how it is reached; it does not know what SPIR-V is. `rules-spirv`, `rules-slang`
-and `tools-embed` all call it, which is what keeps their generated declarations
-from drifting.
-
-It lives in this package's lib root, so a rule package outside this collection
-reaches it by depending on `mcpp:plugins` and activating no feature -- the lib
-root alone, which is one small module. That works and is the intended path;
-whether the generator should become a package of its own is an open question and
-not one this version answers.
-
-
-**One copy of the bytes.** A generated data header declares a `static` array, so
-before this every translation unit that included one carried its own copy.
-Exactly one translation unit -- the generated implementation -- includes them
-now, and every consumer reaches the same array through the accessor.
-
-## `tools-embed`'s four entry points
-
-| entry point | inputs | outputs | shape |
-|---|---|---|---|
-| `file()` | one | one header | one array, one `_size`, included by name |
-| `files()` | N | N headers | one `file()` call per input; `options::identifier` is refused, because it names one symbol and there are several |
-| `group()` | N | N headers + one generated interface | the same N headers, handed to `mcpp::plugins::surface` so a consumer writes one `import` and names no generated file -- see "What a consumer names" above |
-| `table()` | N | one header | one array of rows, each carrying its input's key beside its bytes; the consumer iterates or looks a row up by key |
-
-`table()` is for a set the consumer wants to walk rather than name member by
-member, where `files()`'s one accessor per input and `group()`'s one function
-per input are both the wrong shape. The motivating case is a shader set:
-
-```cpp
-mcpp::tools::embed::table_options opt;
-opt.name_space = "myapp";
-opt.identifier = "shaders";
-opt.row_type   = "shader_entry";
-mcpp::tools::embed::table({ "shaders/Standard.vert", "shaders/Standard.frag" }, opt);
-```
-
-which produces, in one header, a struct and an array of it:
-
-```cpp
-struct shader_entry { const char* key; const unsigned char* data; std::size_t size; };
-inline constexpr shader_entry shaders[] = {
-    { "Standard.vert", /* ... */, /* ... */ },
-    { "Standard.frag", /* ... */, /* ... */ },
-};
-```
-
-**The row struct is generated beside the array it describes, for the reason
-0.2.6 fixed for `mcpp.rules.spirv`'s header:** a generated header has to be
-includable on its own with nothing else. A consumer never declares the row
-type by hand, so it cannot declare one that has drifted from what the array
-actually holds.
-
-**Each row's bytes are a numeric array, never a raw string literal.** A raw
-string literal delimits on a fixed marker (`)"` closes `R"(...)"`), and no byte
-sequence in an arbitrary payload is excluded strongly enough to promise it
-never contains that marker: shader source can carry it by accident, and a
-binary payload can carry it by construction. The motivating case for this
-entry point built its shader table by concatenating file contents into one
-string in a build script -- exactly this bug: a shader containing that
-four-character sequence truncates the string at that point, and every shader
-concatenated after it goes missing, with nothing but an unrelated compiler
-error to show for it.
-
-**A row's key is a choice, not a convention.** `table_options::key` selects
-between the file name with its extension (`Standard.vert`, the default,
-because a bare stem would collide with `Standard.frag`), the bare stem, and the
-path relative to the manifest directory -- for a nested input set where two
-directories hold a file of the same name, which the file name alone cannot
-tell apart. Two inputs that derive one key are refused, naming both: the same
-shape `mcpp.rules.spirv` refuses two shaders sharing one output name, because
-the alternative is a table that silently keeps the last row sharing a key and
-drops the rest, and a build that did that would still link and run.
-
-**`table_options` is its own type rather than a second meaning for `options`'s
-fields.** `options::identifier` names one symbol, so `files()` refuses a caller
-who sets it for several inputs rather than silently applying it to the first.
-A table writes exactly one array regardless of how many inputs feed it, so
-there is always exactly one name to give: `table_options::identifier` (default
-`embedded_table`) and `table_options::row_type` (default `embedded_file`) name
-the array and the struct. `out_dir`, `name_space`, `elem` and `width` mean what
-they mean in `options`, `element::word32`'s "not a multiple of 4" refusal
-included -- checked per input, since a table has several.
-
-## `tools-island`: an island's boundary
-
-`mcpp::plugins::surface` generates the whole interface for a **data** payload,
-because an address and a size are all there is to decide.
-`mcpp.tools.island` generates what is mechanical about a **code** island -- and
-only that. It is a member like `tools-embed` rather than part of the lib root:
-nothing in this collection uses it, a project does.
-
-The entry points are marked where they are defined, and the signature exists
-once:
-
-```c
-// src/kernels/saxpy.cu -- no include: the generated header arrives through the
-// compiler's forced-include flag, which is what defines the marker as nothing.
-
-MCPP_EXPORT_C
-int saxpy_device(float a, const float* x, const float* y, float* out, unsigned n) { ... }
-```
-
-```cpp
-// build.mcpp
-mcpp::tools::island::options opt;
-opt.module_name  = "myapp.kernels";
-opt.out_dir      = std::string(mcpp::out_dir()) + "/island";
-opt.roots        = { root + "/src/backends/cuda", root + "/src/backends/cpu" };
-opt.layout_root  = root + "/src/backends/cuda";   // default: roots.front()
-opt.strip_prefix = "myapp_";                       // optional short spelling
-
-const auto entries = mcpp::tools::island::scan(opt);
-const auto out     = mcpp::tools::island::emit(*entries, opt);
-mcpp::include_dir(out->include_dir.c_str());
-mcpp::generated(out->interface_file.c_str());
-```
-
-Two files come out of that one marked declaration: the `extern "C"` header the
-device translation unit includes, guards and `__cplusplus` dance included, and
-the module the C++ side imports.
-
-**The names arrive in the module's own namespace (0.5.0).** `docs/42` states one
-rule for both lanes -- the module name and the namespace are one identifier path
--- and this generator did not follow it: every entry point was at global scope,
-so `import myapp.kernels` bought a file name and nothing else. It follows it
-now, and a directory below the layout root extends the path exactly as a payload
-tree's does:
-
-```
-src/backends/cuda/image/blur.cu   myapp_blur   ->  myapp::kernels::image::myapp_blur
-src/backends/cuda/saxpy.cu        myapp_saxpy  ->  myapp::kernels::myapp_saxpy
-```
-
-**A root is a tree, and one of them supplies the shape.** Overlapping roots are
-refused: a file reachable from two of them has two namespace paths, and which
-one it got would depend on the order of the list. `options::roots` names
-the directories implementations live under; `options::layout_root` names the one
-whose directory structure decides where entry points live, and defaults to the
-first. Every other root only has to define the names, so a fallback tree may be
-one flat file or six directories and may be reorganised without renaming
-anything a consumer wrote. This is a naming role and not a rank: every root
-compiles, links, and is equally a backend.
-
-A file list would not do: its common ancestor moves when a file is added, and a
-consumer's qualified name would move with it. Roots also must not come from
-`mcpp::device_sources()`, which `accel` narrows to nothing under `--no-accel` --
-the device tree would vanish and the namespace would come from the fallback.
-
-`scan` registers every file it reads as a declared input and each root as a
-glob, so **adding** a file re-runs the program. Declared inputs are hashed
-contents, and a new file changes none of them.
-
-**A short spelling, when the prefix repeats the namespace.** An island's symbol
-is global to the whole program, so an entry point carries a package prefix
-whether or not it sits in a namespace. `options::strip_prefix` emits a second
-spelling beside the first:
-
-```cpp
-export namespace myapp::kernels::image {
-using ::myapp_blur;                          // the authored name; this is the symbol
-inline constexpr auto blur = myapp_blur;     // the short name, for the call site
-}
-```
-
-Both are exported and the authored one stays canonical -- it is what `nm`, a
-link error, a profiler and `dlsym` show. A `constexpr` function pointer costs
-the artifact nothing: the pair is one symbol. A short name that collides with
-another entry point's name in the same namespace is refused, naming both.
-
-The C++ side is usually a **seam module** of the project rather than a consumer
-directly: `app.cppm` imports the generated module and turns pointers and a count
-back into spans, and it is the one place a backend can be exchanged. That means
-one module interface of the project imports a module interface written into the
-build directory during the same build; the ordering comes from the scan seeing
-the import, and nothing has to be declared for it.
-
-**Three layers, and each overrides the one above.** `scan` reads the marked
-declarations out of the roots, which puts the signature beside the definition;
-`island::declared` builds an entry from a declaration the scan cannot see, for
-`emit` to take directly; and a project that wants neither writes its own header
-and its own module wrapper. The default is the one that keeps the signature in
-one place.
-
-**The marker selects.** An island has internal functions, and a generator that
-exported whatever the file contained would make the boundary an accident of the
-file's contents. `MCPP_EXPORT_C` names the mechanism rather than the domain --
-what is marked is exported across a generated boundary with C linkage -- and
-deliberately does not end in `_API`, a suffix that conventionally expands to a
-visibility attribute where this expands to nothing. It is configurable through
-`options::marker`.
-
-**The scan is not a C parser.** From the marker it copies verbatim to the
-parenthesis closing the parameter list, matching nesting, so a signature that
-wraps across lines or carries a macro travels through unexamined.
-
-**The island writes no `#include` either.** `force_include_flags` returns the
-flags that make the compiler read the generated header before the island's first
-line -- `-include <path>` for gcc and clang, `/FI<path>` for MSVC -- so a project
-using this generator has no header in its source tree and no line naming one.
-
-**Those flags go to the RULE, not to the project.** The island is compiled by a
-driver mcpp did not invoke, which inherits nothing from `mcpp::cflag` or
-`mcpp::cxxflag`, so each device rule takes them on its own command line:
-
-```cpp
-mcpp::rules::cuda::options opt;
-opt.flags = mcpp::tools::island::force_include_flags(out->header_file,
-                                                     mcpp::compiler());
-```
-
-`cuda`, `hip`, `sycl` and `ascendc` all carry `options::flags`, appended last and
-passed through unexamined. The project-wide channels are not merely too wide for
-this, they are wrong for it: `cxxflag` forces the header into every C++
-translation unit, including the seam `.cppm`, and a module interface unit must
-begin with `export module` -- declarations ahead of that line are ill-formed.
-
-A HOST fallback compiled by mcpp itself has no such command line, so it writes
-one ordinary `#include` of the generated header. The asymmetry is between "a
-compiler this project can flag on its own" and "every C++ translation unit",
-not between the two halves' importance.
-
-An `#include` of the generated header would name a file its author never opens,
-and it buys no self-containment: that translation unit could not be compiled
-outside mcpp with or without the line, because the file it names does not exist
-until mcpp writes it.
-
-**The check that include used to do is still there.** The compiler sees the
-declarations, so a definition whose signature drifted from its declaration fails
-where it was written rather than at the link:
-
-```
-src/kernels/saxpy.c:22:5: error: conflicting types for 'scale_device'
-```
-
-**Two checks, and they answer different questions.**
-
-One name declared twice in ONE root is a collision. C language linkage does not
-mangle, so those are one symbol, and a namespace that appeared to separate them
-would promise an isolation the linker does not provide -- measured: two modules
-re-exporting one `extern "C"` name into two namespaces give `&a::f == &b::f`.
-It is refused, naming both files and saying that two implementations of one
-entry point belong in two roots. That refusal is what makes the namespaces
-honest: a name exists in exactly one of them.
-
-One name in SEVERAL roots is one entry point implemented several times, which is
-the ordinary shape of a seam -- a device island and a host fallback, exactly one
-of them in any link. Every root is read unconditionally, because all of them
-exist on disk in either build and which one is compiled is the manifest's
-decision rather than a condition the build program repeats. The declarations
-must then agree verbatim, and two that declare it **differently** are refused,
-naming both files and both signatures:
-
-```
-mcpp.tools.island: two definitions of `island_scale` declare it differently.
-  src/kernels/image/scale.c
-    int island_scale(float a, float* out, unsigned n)
-  src/cpu/ops.c
-    int island_scale(float a, float* out, double n)
-  C language linkage does not mangle, so these never meet at the link:
-  whichever one is in the artifact reads its arguments by its own signature.
-```
-
-Nothing else in the toolchain catches that. The two halves are never in one
-translation unit and never in one link, and C linkage does not mangle, so a
-build with disagreeing halves is clean and the artifact reads its arguments by
-whichever signature it was compiled with. `scan` is the only point at which both
-texts exist at once.
-
-**A root that yields nothing is an error.** A misspelled path or a marker that
-never arrived would otherwise produce a module exporting nothing, and the
-failure would surface as an unresolved name in a consumer three files away.
-
-**The declaration still exists once.** Without this, a project writes it twice --
-in a header, and again wherever the C++ side reaches it. C language linkage does
-not mangle, so two copies that disagree are one symbol: the link is clean and
-each side reads the arguments by its own ABI, with no compile error and no link
-error. That is the copy this removes.
-
-**The module re-exports names, not signatures.** `using ::saxpy_device;` inside
-the module's namespace needs the identifier and nothing else, so the generator
-has no C parser in it and the header stays the only place a signature is
-written. Measured on both
-implementations this package supports: a consumer that imports the module and
-never includes the header calls the entry point and links against an
-implementation built by a different driver, under GCC 16.1 and clang 22.1.8.
-
-**The C++ interface is still yours.** A seam that turns raw pointers into
-`std::optional<std::vector<float>>` is a design decision, and no generator makes
-it well. This removes the boilerplate around the boundary, not the boundary's
-design. `emit_module = false` emits the header alone for a project that keeps a
-hand-written seam that includes rather than imports.
-
-### Why the generators live here and not in mcpp
-
-The engine's `mcpp` module is compiled into the mcpp binary and carries the
-**protocol** -- what a build program can tell mcpp: `action`, `generated`,
-`include_dir`, `fact`, `floor`. A generator is a **library on top of** that
-protocol: it reads declarations, writes files, and hands them back through
-`mcpp::generated`. It extends nothing.
-
-So the line is: the engine's module carries the protocol, and generators are
-libraries. Both of these are opinionated and will change -- what a `payload`
-looks like, how a namespace is derived, which storages exist -- and code inside
-the engine changes only with an engine release, which is the coupling this
-version's `device_extensions` work exists to remove.
-
-A rule package outside this collection reaches them by depending on
-`mcpp:plugins` and activating no feature: the lib root alone, one small module.
-That is a package dependency it chooses, not a coupling the engine imposes. If
-they stabilise, moving them into the engine later is a low-risk step; the reverse
-is not.
-
-## `dist-apk`: Kotlin, libraries and a Maven graph
-
-From 0.11.0 a level-1 package takes what a Gradle application module takes.
-Every path option is relative to the manifest or absolute.
-
-| option | what it adds | payload |
-|---|---|---|
-| `kotlin_sources` | Directories of `.kt` sources. `kotlinc` compiles them first (`-jvm-target 17`), with every Java root as reference sources; `javac` then compiles the Java against the Kotlin classes, and `d8` dexes both with `kotlin-stdlib.jar`. This option or `java_sources` makes a level-1 package, and both may be set | `xim:kotlin`, declared by the `dist-apk-kotlin` feature |
-| (none) | R classes. A package with code links with `aapt2 link --java`, and the `R` classes of the application, of each library and of each archive are compiled with the sources (`--extra-packages`) | |
-| `libraries` | Android libraries from source, each with `package` (its R package), `resources`, `manifest`, `assets`, `java_sources` and `kotlin_sources`. A library listed earlier wins a resource both define, and the application's own `resources` win over every library | |
-| `aars`, `jars` | Local archives. A JAR joins the classpath and the dex. An AAR contributes `classes.jar`, `res/` (under the package its manifest names), its manifest, `jni/<abi>/*.so` and `assets/`. Archives rank after `libraries` | |
-| `maven`, `maven_repositories`, `maven_lock`, `maven_cache` | `group:artifact:version` coordinates, resolved with their transitive dependencies into a lock file. The resolved AARs and JARs are then handled like `aars` and `jars`, and rank after them. The defaults are Google's Maven repository then Maven Central, `maven.lock` beside the manifest, and `COURSIER_CACHE` then coursier's own cache directory for the host | `xim:coursier`, declared by the `dist-apk-maven` feature |
-| `graph_libraries` | From 0.12.0, `true` by default: the libraries and archives the resolved graph's packages state in `[package.metadata.dist-apk]` (see below). `false` reads none, for an application that lists every library itself | |
-| `sign` | `false` writes the aligned package unsigned, with no `apksigner` for an APK and no `jarsigner` for an App Bundle, for a pipeline that signs elsewhere. It is refused together with `keystore` | |
-
-Both features imply `dist-apk`, so a project names them in its place:
-
-```toml
-[build-dependencies.mcpp]
-plugins = { version = "0.11.0", features = ["dist-apk-kotlin", "dist-apk-maven"], host-module = true }
-```
-
-They are features and not payloads of `dist-apk` because provisioning runs
-before the build program says what it compiles. A payload of `dist-apk` would be
-installed for every Android consumer, and the Kotlin compiler is 90 MB. Kotlin
-sources without the feature are refused, naming it.
-
-**An ordinary build does not reach the network.** A Maven graph is resolved and
-downloaded only when the developer asks:
-
-| `MCPP_DIST_APK_MAVEN` | what `mcpp pack` does |
-|---|---|
-| unset | Reads each locked artifact from the cache and checks its sha256 against the lock. A missing lock is refused, and so is a lock resolved for other coordinates, or an artifact absent from the cache. Each refusal names the mode that fixes it. The lock records the repositories it was resolved from without requiring them: a mirror that serves the same bytes passes the digest check |
-| `update` | `cs fetch` resolves the coordinates, downloads the graph and writes the lock, one line per file: `artifact <coordinate> <aar\|jar> <path in the cache> <sha256>` |
-| `fetch` | Downloads exactly the locked artifacts into the cache (`--intransitive`, one per module), for a machine that has the lock and an empty cache |
-
-Commit the lock. Nothing is shrunk or obfuscated, and an archive's ProGuard
-rules are ignored.
-
-**The manifest merge is a stated subset of the Android Gradle plugin's
-merger** (`merge_manifests` in `dist/apk.cppm`):
-
-- An element is added when the application has none of the same kind and
-  `android:name`. This covers the children of `<manifest>`
-  (`<uses-permission>`, `<uses-feature>`, `<permission>`, ...) and of
-  `<application>` (activities, services, receivers, providers, `<meta-data>`,
-  ...). `<queries>` children are unioned, and an identical element is added
-  once.
-- A different element under the same name is refused, naming the element and
-  the library. The exceptions are an application element that says
-  `tools:node="replace"`, which keeps the application's, and one that says
-  `tools:node="remove"`, which keeps neither. A differing `<application>`
-  attribute is refused unless the application lists it in `tools:replace`.
-- A library whose `minSdkVersion` is above the application's is refused.
-- `${applicationId}` is substituted. Any other `${...}` placeholder is refused.
-- `tools:` attributes and the `xmlns:tools` declaration are removed from the
-  result.
-
-Anything beyond that belongs in the project's `manifest_template`.
-
-`tests/apk-consumer-libraries` measures the options together on Linux:
-
-- one signed APK from a Kotlin and Java application, a library from source, an
-  AAR and a JAR, with every class dexed, three R packages, the application's
-  value for a resource the library also defines, and the merged manifest;
-- `sign = false`;
-- an App Bundle from the same inputs;
-- a manifest conflict refused by name;
-- the Maven modes, each refusal included.
-
-**The build host is Linux.** Every payload publishes a macOS table, and the
-member's plan runs on macOS, but mcpp 2026.9.14.2 does not link an Android row
-on a macOS host: the application's own link fails with `ld64.lld: error: unknown
-argument '-soname'` before this member runs, because the engine states the
-target triple on that host's link line only for an Apple row
-(mcpp-community/mcpp#647, E3). The Windows host has no Android row, because the
-Windows NDK carries no libc++ module surface (`xim-pkgindex`,
-`pkgs/a/android-ndk.lua`).
-
-### A library states its contribution: `[package.metadata.dist-apk]`
-
-From 0.12.0, with mcpp 2026.9.16.1, a library states in its own manifest what it
-contributes to an Android package, and every application that depends on it
-carries that without naming the library in its build program:
-
-```toml
-# the library's mcpp.toml
-[package.metadata.dist-apk]
-package        = "org.example.widgets"   # its R package
-resources      = "android/res"
-manifest       = "android/AndroidManifest.xml"
-assets         = "android/assets"
-java_sources   = ["android/java"]
-kotlin_sources = ["android/kotlin"]
-jars           = ["android/libs/support.jar"]
-aars           = ["android/libs/player.aar"]
-```
-
-Every key is optional, and each has the meaning of the `library` field or the
-option of the same name; paths are relative to the library's directory. The
-engine hands the application's build program the resolved graph
-(`MCPP_GRAPH_FILE`), and `dist-apk` reads the table of every package in it other
-than the application. The contributions rank below the application's own
-`libraries`, `jars` and `aars`, and a package ranks above the packages it depends
-on, so an application's resource overrides a library's and a library's overrides
-the framework beneath it. A key of the wrong shape is refused naming the package
-and the key; a key this version does not read is reported with a warning and
-ignored, so a library may state a key a newer collection reads. Under an older
-engine there is no graph, and nothing is contributed. CI checks both engines on
-`tests/apk-consumer-graph`.
-
-## `dist-apple`: a project's Info.plist, and an iOS device
-
-| option | what it does |
-|---|---|
-| `info_plist` | A plist whose top-level `<dict>` entries join the bundle's Info.plist: usage descriptions, URL types, background modes. A key the member derives is refused by name: `CFBundleExecutable`, `CFBundleIdentifier`, `CFBundleName`, `CFBundleShortVersionString`, `CFBundleVersion`, `CFBundlePackageType`, `LSMinimumSystemVersion`, `MinimumOSVersion`, `CFBundleSupportedPlatforms`, `CFBundleIconFile`, `CFBundleIcons`. A key it only defaults takes the project's value: `UIDeviceFamily`, `LSRequiresIPhoneOS`, `NSHighResolutionCapable`. Without `info_plist` the plist is byte-identical to 0.10.1's |
-| `omit_keys` | From 0.12.0. Defaulted keys to leave out of the Info.plist, for a project whose other build states neither: `UIDeviceFamily`, `LSRequiresIPhoneOS`, `NSHighResolutionCapable`. A property list has no null, so `info_plist` can replace a default's value but cannot remove its key. A key the member derives, a key it never writes, a key named twice, and a key `info_plist` also sets are each refused by name. A key that does not apply to the row (`UIDeviceFamily` on macOS) changes nothing |
-| `graph_info_plist` | From 0.12.0, `true` by default: the Info.plist entries the resolved graph's packages state (see below). `false` reads none |
-| `provisioning_profile` | The device row (`aarch64-ios`) only, and only with `identity`. The profile is embedded as `embedded.mobileprovision`. Its `Entitlements` dictionary signs the bundle unless `entitlements` names a file, with a wildcard `application-identifier` stated as the bundle's own. That identifier must cover the bundle identifier: exactly, `<team>.*`, or `<team>.<prefix>.*`. The plist is read from the profile's bytes, so a plan made on any host checks it; verifying the profile's CMS signature is left to `codesign` and the device |
-
-A library states its Info.plist entries in its own manifest (0.12.0, mcpp
-2026.9.16.1), as a plist of the shape `info_plist` takes, its path relative to
-the library's directory:
-
-```toml
-# the library's mcpp.toml
-[package.metadata.dist-apple]
-info_plist = "apple/Info-fragment.plist"
-```
-
-The entries of every package in the resolved graph other than the application
-are applied in the graph's order, dependencies first, so a package overrides the
-packages it depends on; the application's own `info_plist` is applied last and
-wins every key, and a key the application names in `omit_keys` is left out
-whoever contributes it. A key the member derives is refused in a contribution as
-in `info_plist`, naming the package. Under an older engine there is no graph, and
-nothing is contributed.
-
-On the device row the member supplies the runner named `app`: `devicectl-run`,
-from `xim:apple-device-tools`, which the feature declares with `when = "run"` on
-that row alone. `mcpp run --target aarch64-ios --format app` installs the signed
-bundle on a connected device with `xcrun devicectl device install app`, then
-launches it with the console attached. `DEVICECTL_RUN_DEVICE` names a device;
-unset, the first connected iOS device is used. The simulator row keeps
-`simctl-run`.
-
-**Not yet measured:** no runner this repository uses has a device, and the
-device bundle, its signature and whether `devicectl` returns the program's exit
-status have not been measured on one; `devicectl-run` prints that when it runs.
-CI measures the rest:
-
-- On Linux, the plan: the entries, a refused key, an omitted default on iOS
-  and on macOS and the three refusals of `omit_keys`, the graph's entries in
-  the graph's order with the application's winning and `graph_info_plist =
-  false`, a contributed derived key refused naming its package, an unreadable
-  graph document refused, the embedded profile, the
-  entitlements, a wildcard profile, and the refusals of a profile for another
-  identifier, on the simulator row, or without an identity.
-- On `macos-15`: the entries in a real macOS bundle that `plutil` accepts and
-  that launches, and in a simulator bundle that the simulator runs.
-
-## `deps-vcpkg`, `deps-cmake`, `deps-archive` and `rules-qt`
-
-### `deps-vcpkg`: the libraries a vcpkg manifest names
-
-```toml
-[build-dependencies.mcpp]
-plugins = { version = "0.14.0", features = ["deps-vcpkg"], host-module = true, tools = ["mcpp-deps"] }
-```
-
-```cpp
-// build.mcpp
-import std;
-import mcpp;
-import mcpp.deps.vcpkg;
-
-int main() {
-    mcpp::deps::vcpkg::options o;
-    o.libraries = { "fmt", "spdlog" };
-    return mcpp::deps::vcpkg::use(o) ? 0 : 1;
-}
-```
-
-`use()` finds `vcpkg.json` at or above the package root, so every member of a
-workspace finds a manifest kept at the workspace root. It then:
-
-- declares `mcpp-deps vcpkg …` as a `mcpp::roles::prepare` action whose output
-  directory is `<install root>/<triplet>` and whose inputs are `vcpkg.json`,
-  `vcpkg-configuration.json` and every file of the manifest's overlay ports and
-  triplets. The package's compile and link edges wait for it; it runs under
-  `mcpp build` when an input changed, and never under `mcpp emit
-  build-database`;
-- adds `<install root>/<triplet>/include` as an include directory;
-- links each name in `options::libraries` by its full path under
-  `<install root>/<triplet>/lib` (`fmt` is `fmt.lib` on Windows, `libfmt.a` or
-  `libfmt.so` elsewhere; a name with an extension is a file name);
-- for a triplet that links dynamically, declares `bin/` (Windows) or `lib/`
-  (elsewhere) with `mcpp::runtime_search_dir`: the program's run path on ELF and
-  Mach-O, `mcpp run`'s load path, `mcpp pack`'s closure, and on Windows the
-  DLLs the program imports placed beside it after the link;
-- copies each file `options::deploy` names out of the prefix, by an action
-  that names the copy as its output, and deploys the copy beside the program;
-- returns the prefix (`root`, `include`, `lib`, `bin`, `share`, `triplet`, and
-  `deployed`, the copies, for a project that lays out a directory of its own).
-
-A vcpkg tool that is not installed is a warning and not a failure: the plan
-states every path it can, and the build is where the absence fails.
-
-| option | meaning |
-|---|---|
-| `triplet` | empty derives it from the target: `x64-windows`, `arm64-windows`, `x64-mingw-dynamic`, `x64-linux`, `arm64-linux`, `x64-osx`, `arm64-osx`; a custom triplet is found through the manifest's `overlay-triplets` |
-| `libraries` | the link, in order; a name that matches no installed file fails the link, naming its path |
-| `manifest_root` | the directory holding `vcpkg.json` |
-| `install_root` | empty is vcpkg's default, `<manifest root>/vcpkg_installed` |
-| `overlay_triplets` | further overlay-triplet directories |
-| `install_args` | arguments appended to `vcpkg install` |
-| `vcpkg_root` | a vcpkg root other than the `xim:vcpkg` payload |
-| `deploy` | files of the prefix the program reads at run time, each `{file, to}`: `file` relative to the prefix root, `to` the directory beside the program (`{"share/opencc/t2s.json", "BaseConfig/opencc"}`) |
-
-The payload `xim:vcpkg` is vcpkg-tool's release binary with the standalone
-bundle published beside it, so the scripts a port calls are the ones that tool
-was released with. A `builtin-baseline` manifest resolves through vcpkg's git
-registry, into vcpkg's per-user registry cache; no clone of microsoft/vcpkg is
-made per project, and an inherited `VCPKG_ROOT` is not used. `mcpp-deps`
-places vcpkg's downloads and each installation's build trees in vcpkg's
-per-user directory (`%LOCALAPPDATA%\vcpkg` on Windows, `$XDG_CACHE_HOME/vcpkg`
-or `~/.cache/vcpkg` elsewhere), beside vcpkg's default binary cache, and takes
-an exclusive lock on the installation root while vcpkg runs. vcpkg fetches its
-own CMake, Ninja and 7-Zip, and on Windows a portable git; on Linux and macOS
-its documented host prerequisites (git, curl, zip, unzip, tar, a C compiler)
-are the host's. Ports are compiled with vcpkg's default toolchain for the
-triplet: the Visual Studio toolset on Windows, the host compiler elsewhere. The
-program links them, so its C++ runtime must be theirs: mcpp's clang on the MSVC
-ABI links a Windows port as it stands, while on Linux a toolchain whose C++
-library is libc++ does not link a port built against the host's libstdc++, and
-such a project builds with a gcc toolchain.
-
-Not supported: vcpkg's classic mode; the debug libraries under `debug/lib`.
-
-### `deps-cmake`: a CMake subproject
-
-```cpp
-import mcpp.deps.cmake;
-
-int main() {
-    mcpp::deps::cmake::options o;
-    o.source     = "3rdParty/widgets";
-    o.cache_args = { "-DWIDGETS_BUILD_EXAMPLES=OFF" };
-    o.libraries  = { "widgets" };
-    o.shared     = true;
-    return mcpp::deps::cmake::use(o) ? 0 : 1;
-}
-```
-
-One `prepare` action configures, builds and installs the subproject into
-`<out dir>/deps-cmake/<name>/install`, its declared output directory; its inputs
-are the subproject's files, so an edit to the subproject rebuilds it. The prefix is mapped as `deps-vcpkg`
-maps its own. `layout` names install directories other than `include/`, `lib/`
-and `bin/`; `prefix_path` becomes `CMAKE_PREFIX_PATH` (`mcpp::rules::qt::root()`
-for a subproject that finds Qt); `cache_args` carries `-D…`, `-G …` and a
-toolchain file. The subproject is compiled with the toolchain CMake selects by
-default unless `cache_args` names another. `deploy` places files of the prefix
-beside the program, as `deps-vcpkg` takes it.
-
-### `deps-archive`: files a program reads at run time, from an archive
-
-```cpp
-import mcpp.deps.archive;
-
-int main() {
-    mcpp::deps::archive::options o;
-    o.archive = "assets/python-embed.zip";
-    o.to      = "runtime";
-    return mcpp::deps::archive::unpack(o) ? 0 : 1;
-}
-```
-
-`unpack()` reads the archive's central directory while the build program runs,
-so every file it holds is named before anything is extracted. One `artifact`
-action, `mcpp-deps unpack`, extracts it into `<out dir>/deps-archive/<name>` with
-`cmake -E tar xf --touch`, naming each file as an output; each file is then
-deployed under `to`, so `mcpp run` finds it beside the program and `mcpp pack`
-carries it. The action's inputs are the archive and the tool, so an edited
-archive is extracted again and an unchanged one is not; `mcpp emit
-build-database` extracts nothing. `result::files` lists the extracted copies
-with their paths beside the program, for a project that lays out a directory of
-its own. A C++ file inside the archive is data: the action's outputs never join
-the package's compile set.
-
-Only zip is read, because a compressed tar has no index to list without
-decompressing it while planning; a ZIP64 archive is refused by name, as is a
-member whose path would leave the extraction directory. A missing `cmake` is a
-warning, and the plan then extracts and deploys nothing.
-
-### `rules-qt`: Qt's code generators and Linguist tools
-
-```toml
-[build-dependencies.mcpp]
-plugins = { version = "0.14.0", features = ["rules-qt-xim"], host-module = true }
-
-[build]
-sources = ["src/*.cpp", "res/*.qrc", "i18n/*.ts", "ui/*.ui"]
-```
-
-```cpp
-import mcpp.rules.qt;
-
-int main() {
-    mcpp::rules::qt::options o;
-    o.modules        = { "Core", "Gui", "Widgets", "Network" };
-    o.deploy_plugins = { "platforms", "styles", "imageformats" };
-    o.i18n.tr_function_alias = { "translate+=appTr" };
-    return mcpp::rules::qt::compile(o) ? 0 : 1;
-}
-```
-
-| feature | SDK |
-|---|---|
-| `rules-qt` | `options::root`; nothing is downloaded |
-| `rules-qt-xim` | `xim:qt` 6.11.1: the official base package without documentation (qtbase, qtsvg, qtdeclarative, qttools, qttranslations) |
-| `rules-qt-xim-base` | `xim:qt-base` 6.11.1 in place of `xim:qt`: qtbase and qttools with the QtQml library `lupdate` loads, about a third of the download (56–73 MB); every module a widgets or console program links, without Qt Quick, qtsvg or Qt's own translations |
-| `rules-qt-xim-addons` | adds `xim:qt-addons` 6.11.1, every additional library, as a second prefix |
-
-| option | meaning |
-|---|---|
-| `modules` | `Core`, `QtCore` and `Qt6Core` name one module; each is linked by full path and defines `QT_<MODULE>_LIB` |
-| `private_modules` | modules whose private headers are included |
-| `moc`, `moc_headers` | `moc_scan::project_headers` (default) scans the package's headers by content; `moc_scan::listed` takes `moc_headers` only |
-| `forms`, `resources` | `.ui` and `.qrc` files beside those in `[build] sources` |
-| `i18n` | `.ts` files beside those in `[build] sources`; `update_sources` runs `lupdate` before `lrelease`, as an action whose output is the `.ts` file it rewrites; `tr_function_alias`; `deploy_to` (default `translations`); `out_dir`, where `lrelease` writes (default `<out dir>/qt/translations`); `qt_languages`, Qt's own strings for each language: the catalogs of the linked modules combined by `lconvert` into `qt_<language>.qm` under `deploy_to`, the file windeployqt writes |
-| `deploy_plugins` | plugin directories placed beside the program; default `platforms` |
-| `deploy_software_gl` | Windows: `opengl32sw.dll` and `d3dcompiler_47.dll` beside the program |
-| `root`, `extra_roots` | an SDK, and further prefixes |
-
-Generated files are written under `<out dir>/qt/`: `moc_<stem>.cpp` and
-`qrc_<stem>.cpp` are compiled, `ui_<stem>.h` and `<stem>.moc` are included
-(the directory is an include directory), and `translations/<stem>.qm` is
-deployed. Under an MSVC compiler the rule adds `/Zc:__cplusplus` and
-`/permissive-`; on Linux, `-fPIC`, which Qt's headers require. A resource
-compiled into a static library is registered with `Q_INIT_RESOURCE(<stem>)`, as
-Qt documents; in a program it registers itself.
-
-A missing SDK, module or tool is a warning: the rule states what it can, and
-the build is where the absence fails.
-
-On Linux, Qt's official QtCore links glib, zstd and zlib and the shared
-`libstdc++`. `rules-qt-xim` and `rules-qt-xim-base` declare the first three on Linux, and the rule
-declares their `lib/` directories as runtime search directories; the program
-states `[build] cxx_runtime = "toolchain-coupled"` (mcpp's docs/20), so the
-process has one C++ runtime. The statement is project-wide because mcpp reads a
-`[target.<triple>]` table only when a target is named (mcpp#704). On macOS and
-under clang on the MSVC ABI mcpp reports the contract it delivers instead. Modules that load QtGui are not
-served on Linux: QtGui loads `libdbus-1.so.3`, which the ecosystem does not
-publish, and mcpp's runtime closure check refuses the program. On macOS the
-modules are frameworks under `lib/`: the rule compiles with `-F<root>/lib` and
-links each framework's binary by its full path.
-
-## How the engine sees this package
-
-mcpp compiles every module interface unit among a host-module package's
-resolved sources as a host module of its own, the lib root first (2026.9.5.3+).
-`[features.<f>] sources` is what puts a member into that set, so the module set
-a consumer can import is exactly its feature set. A member is compiled alone,
-in the same command as the consumer's `build.mcpp`, and may import `std`,
-`mcpp` and `mcpp.plugins`.
+| feature | module | mcpp floor | what it does | doc |
+|---|---|---|---|---|
+| `rules-ascendc` | `mcpp.rules.ascendc` | 2026.9.6.6 | Compiles Ascend C (`*.asc`) with BiSheng in mixed mode, so the object joins the ordinary link. | [rules](docs/rules.md#rules-ascendc) |
+| `rules-cuda` | `mcpp.rules.cuda` | 2026.9.6.6 | Compiles CUDA (`*.cu`) through clang with an LLVM toolchain or nvcc with a GCC one. | [rules](docs/rules.md#rules-cuda) |
+| `rules-hip` | `mcpp.rules.hip` | 2026.9.6.6 | Compiles HIP (`*.hip`) with the project's clang on the NVIDIA platform. | [rules](docs/rules.md#rules-hip) |
+| `rules-metal` | `mcpp.rules.metal` | 2026.9.8.1 | Compiles `.metal` shaders into Metal libraries with the host's Xcode and deploys them beside the program. | [rules](docs/rules.md#rules-metal) |
+| `rules-qt` | `mcpp.rules.qt` | 2026.9.26.2 | Runs `moc`, `uic`, `rcc` and Qt's Linguist tools as actions, links the Qt modules and places their runtime. | [rules-qt](docs/rules-qt.md) |
+| `rules-slang` | `mcpp.rules.slang` | 2026.9.7.1 | Compiles Slang (`*.slang`) and embeds or places the result. | [rules](docs/rules.md#rules-slang) |
+| `rules-spirv` | `mcpp.rules.spirv` | 2026.9.6.6 | Compiles GLSL and HLSL shader stages to SPIR-V and embeds or places the result. | [rules](docs/rules.md#rules-spirv) |
+| `rules-swift` | `mcpp.rules.swift` | 2026.9.8.1 | Compiles a package's `.swift` sources into one module the C and C++ sources call. | [rules](docs/rules.md#rules-swift) |
+| `rules-sycl` | `mcpp.rules.sycl` | 2026.9.6.6 | Compiles SYCL (`*.sycl`) with DPC++. | [rules](docs/rules.md#rules-sycl) |
+| `tools-embed` | `mcpp.tools.embed` | 2026.9.5.4 | Writes a data file into a header the program compiles in. | [tools-embed](docs/tools-embed.md) |
+| `tools-island` | `mcpp.tools.island` | 2026.9.7.1 | Generates the `extern "C"` boundary and the C++ module of a code island. | [tools-island](docs/tools-island.md) |
+| `dist-appimage` | `mcpp.dist.appimage` | 2026.9.11.1 | Turns the tree `mcpp pack` stages into an AppImage (Linux). | [dist](docs/dist.md#dist-appimage) |
+| `dist-wix` | `mcpp.dist.wix` | 2026.9.11.1 | Builds an MSI of the staged tree, and a Burn bundle chaining it (Windows). | [dist](docs/dist.md#dist-wix) |
+| `dist-apple` | `mcpp.dist.apple` | 2026.9.14.2 | Lays out a macOS or iOS application bundle, signs it and writes a disk image. | [dist-apple](docs/dist-apple.md) |
+| `dist-web` | `mcpp.dist.web` | 2026.9.13.1 | Copies a `wasm32-emscripten` program and its files into a web directory with an `index.html`. | [dist](docs/dist.md#dist-web) |
+| `dist-apk` | `mcpp.dist.apk` | 2026.9.14.2 | Packs the native closure into a signed APK or App Bundle, with Java, Kotlin and Maven libraries. | [dist-apk](docs/dist-apk.md) |
+| `deps-vcpkg` | `mcpp.deps.vcpkg` | 2026.9.26.2 | Installs a `vcpkg.json` manifest as an action and maps the prefix into the build. | [deps](docs/deps.md#deps-vcpkg) |
+| `deps-cmake` | `mcpp.deps.cmake` | 2026.9.26.2 | Builds and installs a CMake subproject as an action and maps the prefix into the build. | [deps](docs/deps.md#deps-cmake) |
+| `deps-archive` | `mcpp.deps.archive` | 2026.9.26.2 | Extracts a zip archive the project keeps and places its tree beside the program. | [deps](docs/deps.md#deps-archive) |
+
+Some features add a sub-capability to a member: `dist-apk-kotlin` and
+`dist-apk-maven` (Kotlin sources, a Maven graph), and `surface` and `deps`,
+which the members imply. A feature states a mechanism and the tools that
+mechanism runs; the libraries and SDKs a program links are the project's
+declaration (0.15.0 removed `rules-qt-xim*`; see [rules-qt](docs/rules-qt.md)).
 
 ## Layout
 
 ```
-mcpp.toml          the package: one feature per member
-src/plugins.cppm   export module mcpp.plugins;  the lib root: the version,
-                   mcpp::plugins::surface, which every member that embeds a
-                   payload uses to write the declarations a consumer names,
-                   and mcpp::plugins::xml, the XML reader and writer
-                   dist-apk's manifest merge and dist-apple's plists share
-rules/<x>.cppm     export module mcpp.rules.<x>;
-tools/<x>.cppm     export module mcpp.tools.<x>;
-dist/<x>.cppm      export module mcpp.dist.<x>;
-deps/<x>.cppm      export module mcpp.deps.<x>;  deps/deps.cppm is what the
-                   deps members share
-tools/deps_main.cpp  mcpp-deps, the command of every deps installation
-tests/<consumer>/  one project per member, built by CI with the pinned mcpp
+mcpp.toml            the package: one feature per member
+src/plugins.cppm     export module mcpp.plugins;  the version, mcpp::plugins::surface
+                     (the declarations a consumer names) and mcpp::plugins::xml
+rules/<x>.cppm       export module mcpp.rules.<x>;
+tools/<x>.cppm       export module mcpp.tools.<x>;
+dist/<x>.cppm        export module mcpp.dist.<x>;
+deps/<x>.cppm        export module mcpp.deps.<x>;  deps/deps.cppm is shared
+tests/<consumer>/    one project per member, built by CI with the pinned mcpp
+docs/                one page per member or group of members
 ```
 
-## What a rule may drive, and what it may not
-
-A member drives a compiler the ecosystem resolved and no other. `xim:dpcpp` is
-`mcpp.rules.sycl`'s compiler; `xim:gcc` is the C++ standard library it compiles
-against; `xim:cuda-nvcc` is the back end it emits for. None of the three is a
-default: each is read from `mcpp::xpkg_dir`, and a member that cannot find one
-refuses and prints the `[xlings.workspace]` line that would add it.
-
-Two of those three were added because a build that already worked was found to
-be reading the host. Without `--gcc-install-dir` the SYCL unit compiled against
-`/usr/include/c++`; without `--cuda-path` clang found the host's CUDA
-installation. Neither said anything: both are visible only in the compiler's
-own include search list, and only on a machine that has those directories.
-
 ## Adding a member
 
-1. One file, `rules/<x>.cppm`, `tools/<x>.cppm`, `dist/<x>.cppm` or `deps/<x>.cppm`, declaring
-   its module name.
-   The engine owns the graph — the accelerator axis, the constrained globs,
-   the action edges, the fingerprint — and the member owns the spelling: which
-   tool, which flags, what is generated. A member does not read `/usr`; a tool
-   comes from `mcpp::toolchain_dir()`, `mcpp::xpkg_dir()` or an explicit option,
-   and a missing one is refused naming the `[xlings.workspace]` entry to add.
-2. A feature in `mcpp.toml` adding that one source.
-3. A consumer under `tests/` that builds through it and asserts on the
-   artefact, and a row in the table above with the mcpp floor.
-4. A version bump: mcpp identifies an installed package by `(name, version)`,
-   so a changed payload under an unchanged version is not reinstalled.
+A member is one module file, one feature in `mcpp.toml`, a consumer under
+`tests/` that CI builds and asserts on, a row in the table above with its mcpp
+floor, and a version bump. The conventions a member follows -- the same for a
+third-party or a project's own plugin -- are in
+[docs/plugin-development.md](docs/plugin-development.md); the division between
+what the engine owns and what the member owns is in
+[docs/engine-and-rules.md](docs/engine-and-rules.md#adding-a-member-what-the-engine-owns-and-what-the-member-owns).
 
 ## Releases
 
diff --git a/deps/archive.cppm b/deps/archive.cppm
index 352831c..29faab7 100644
--- a/deps/archive.cppm
+++ b/deps/archive.cppm
@@ -179,23 +179,30 @@ inline result unpack(const options& opt) {
         r.files.clear();
         return r;
     }
-    const std::string tool = mcpp::deps::launcher(who, "deps-archive");
-    if (tool.empty()) return {};
-
     // ── the extraction, as an edge ──
-    const std::string id   = "deps-archive:" + name;
-    const std::string desc = "UNPACK " + archive.filename().string();
-    const std::string arc  = mcpp::deps::generic(archive);
-    const std::string dst  = mcpp::deps::generic(into);
+    // `cmake -P` over a script this program writes: the directory is emptied
+    // first -- the action names every member of the archive as an output, and
+    // a file left from a previous archive would be one it did not name -- and
+    // `ARCHIVE_EXTRACT ... TOUCH` (CMake 3.24+) gives each file the time of
+    // extraction, so the outputs are newer than the archive.
+    using mcpp::deps::bracket;
+    const std::string id     = "deps-archive:" + name;
+    const std::string desc   = "UNPACK " + archive.filename().string();
+    const std::string arc    = mcpp::deps::generic(archive);
+    const std::string dst    = mcpp::deps::generic(into);
+    const fs::path    script = fs::path(mcpp::out_dir()) / "deps-archive" / (name + ".cmake");
+    mcpp::deps::write_if_changed(script,
+        "# Written by mcpp.deps.archive: extract " + archive.filename().string() + ".\n"
+        "file(REMOVE_RECURSE " + bracket(dst) + ")\n"
+        "file(MAKE_DIRECTORY " + bracket(dst) + ")\n"
+        "file(ARCHIVE_EXTRACT INPUT " + bracket(arc) + " DESTINATION " + bracket(dst) + " TOUCH)\n");
+    const std::string scriptS = mcpp::deps::generic(script);
     mcpp::action a;
     a.id          = id.c_str();
     a.role        = mcpp::roles::artifact;
     a.description = desc.c_str();
-    a.arg(tool.c_str()).arg("unpack")
-     .arg("--cmake").arg(cmake.c_str())
-     .arg("--archive").arg(arc.c_str())
-     .arg("--into").arg(dst.c_str())
-     .input(tool.c_str()).input(cmake.c_str()).input(arc.c_str());
+    a.arg(cmake.c_str()).arg("-P").arg(scriptS.c_str())
+     .input(cmake.c_str()).input(scriptS.c_str()).input(arc.c_str());
     for (auto const& f : r.files) a.output(f.path.c_str());
     a.submit();
 
diff --git a/deps/cmake.cppm b/deps/cmake.cppm
index a15b92a..b996c35 100644
--- a/deps/cmake.cppm
+++ b/deps/cmake.cppm
@@ -13,17 +13,19 @@
 //
 // and the subproject is configured, built and installed into a prefix under
 // this package's output directory by ONE `prepare` action (mcpp's SPEC-007
-// R3.3) whose `output_dir` is that prefix and whose inputs are the
+// R3.3), `cmake -P` over a script this program writes, whose `output_dir` is
+// that prefix and whose inputs are the
 // subproject's files, so an edit to it rebuilds it and nothing else does. The prefix is then mapped exactly as `mcpp.deps.vcpkg` maps its own:
 // include directory, libraries by full path, the shared libraries deployed
 // beside the program.
 //
-// THE COMPILER IS CMAKE'S OWN CHOICE. A subproject is configured the way its
-// authors build it -- on Windows, CMake's default generator and the Visual
-// Studio toolset it finds -- unless the project passes `-G`, `-DCMAKE_CXX_COMPILER`
-// or a toolchain file through `cache_args`. Keeping the C runtime and the C++
-// standard library consistent with the program is the project's decision, as it
-// is with any prebuilt library.
+// THE COMPILER IS CMAKE'S OWN CHOICE, EXCEPT WHERE ITS C++ LIBRARY DIFFERS. A
+// subproject is configured the way its authors build it -- on Windows, CMake's
+// default generator and the Visual Studio toolset it finds. On Linux under a
+// libc++ toolchain the compilers are mcpp's own clang (`-DCMAKE_C_COMPILER`,
+// `-DCMAKE_CXX_COMPILER`), because the host compiler CMake finds uses libstdc++
+// and the two do not link (`mcpp::deps::program_compilers`). A project that
+// passes either compiler or a toolchain file through `cache_args` decides.
 //
 // `xim:cmake` is declared by this feature; `options::cmake` names another.
 
@@ -123,34 +125,53 @@ inline prefix use(const options& opt) {
             "{}: no cmake (xpkg_dir(\"xim\", \"cmake\") answered \"{}\"), so this plan builds "
             "nothing. The `deps-cmake` feature declares `xim:cmake`; `mcpp build` provisions it "
             "before this program runs.", who, std::string(mcpp::xpkg_dir("xim", "cmake"))));
-    } else if (const std::string tool = mcpp::deps::launcher(who, "deps-cmake"); tool.empty()) {
-        return {};
     } else {
-        const std::string stamp = mcpp::deps::generic(base / (name + ".stamp"));
-        const std::string id    = "deps-cmake:" + name;
-        const std::string desc  = "CMAKE " + name;
-        mcpp::action a;
-        a.id          = id.c_str();
-        a.role        = mcpp::roles::prepare;
-        a.description = desc.c_str();
-        a.arg(tool.c_str()).arg("cmake")
-         .arg("--cmake").arg(cmake.c_str())
-         .arg("--source").arg(mcpp::deps::generic(source).c_str())
-         .arg("--build").arg(mcpp::deps::generic(build).c_str())
-         .arg("--prefix").arg(p.root.c_str())
-         .arg("--config").arg(opt.config.c_str())
-         .arg("--");
+        // ONE ACTION, THREE STEPS. `cmake -P` runs a script this program
+        // writes: configure (every time -- over an existing cache CMake re-runs
+        // only what changed, and the arguments may have changed, which is why
+        // the action ran at all), then build and install.
+        const std::string stamp  = mcpp::deps::generic(base / (name + ".stamp"));
+        const std::string id     = "deps-cmake:" + name;
+        const std::string desc   = "CMAKE " + name;
+        const fs::path    script = base / (name + ".cmake");
+        using mcpp::deps::bracket;
+        std::vector<std::string> configure{
+            "-S", mcpp::deps::generic(source), "-B", mcpp::deps::generic(build),
+            "-DCMAKE_INSTALL_PREFIX=" + p.root, "-DCMAKE_BUILD_TYPE=" + opt.config };
         if (!opt.prefix_path.empty()) {
             std::string joined;
             for (auto const& d : opt.prefix_path) {
                 if (!joined.empty()) joined += ';';
                 joined += mcpp::deps::generic(mcpp::deps::absolute_from_root(d));
             }
-            a.arg(("-DCMAKE_PREFIX_PATH=" + joined).c_str());
+            configure.push_back("-DCMAKE_PREFIX_PATH=" + joined);
         }
-        for (auto const& x : opt.cache_args) a.arg(x.c_str());
-        a.input(tool.c_str());
+        const bool chosen = std::ranges::any_of(opt.cache_args, [](const std::string& x) {
+            return x.contains("CMAKE_C_COMPILER") || x.contains("CMAKE_CXX_COMPILER")
+                || x.contains("CMAKE_TOOLCHAIN_FILE");
+        });
+        if (const auto cc = mcpp::deps::program_compilers(); cc && !chosen) {
+            configure.push_back("-DCMAKE_C_COMPILER=" + cc.c);
+            configure.push_back("-DCMAKE_CXX_COMPILER=" + cc.cxx);
+        }
+        for (auto const& x : opt.cache_args) configure.push_back(x);
+        std::string text = "# Written by mcpp.deps.cmake: configure, build and install " + name + ".\n"
+                           "execute_process(COMMAND ${CMAKE_COMMAND}";
+        for (auto const& x : configure) text += "\n    " + bracket(x);
+        text += "\n    RESULT_VARIABLE rc)\n"
+                "if(NOT rc EQUAL 0)\n  message(FATAL_ERROR \"configure exited ${rc}\")\nendif()\n"
+                "execute_process(COMMAND ${CMAKE_COMMAND} --build " + bracket(mcpp::deps::generic(build)) +
+                " --config " + bracket(opt.config) + " --target install --parallel\n    RESULT_VARIABLE rc)\n"
+                "if(NOT rc EQUAL 0)\n  message(FATAL_ERROR \"build and install exited ${rc}\")\nendif()\n";
+        mcpp::deps::write_if_changed(script, text);
+        const std::string scriptS = mcpp::deps::generic(script);
+        mcpp::action a;
+        a.id          = id.c_str();
+        a.role        = mcpp::roles::prepare;
+        a.description = desc.c_str();
+        a.arg(cmake.c_str()).arg("-P").arg(scriptS.c_str());
         a.input(cmake.c_str());
+        a.input(scriptS.c_str());
         for (auto const& f : mcpp::deps::files_under(source)) a.input(f.c_str());
         mcpp::deps::watch_tree(source);
         a.output(stamp.c_str());
diff --git a/deps/deps.cppm b/deps/deps.cppm
index 499f0c7..6621f82 100644
--- a/deps/deps.cppm
+++ b/deps/deps.cppm
@@ -24,9 +24,10 @@
 //      paths it WILL use lets the editor resolve every include the moment the
 //      first build finishes.
 //
-// This unit imports `mcpp`, so it exists only inside a build program. The
-// program that performs the installation is `mcpp-deps` (tools/deps_main.cpp),
-// an ordinary executable built from this package.
+// This unit imports `mcpp`, so it exists only inside a build program. Each
+// action's command is the installer itself -- `vcpkg`, or `cmake -P` over a
+// script the member writes -- so the package brings no program of its own and
+// a consumer's edge names none (0.15.0; 0.13.0-0.14.0 ran `mcpp-deps`).
 
 export module mcpp.deps;
 
@@ -56,19 +57,14 @@ inline void warn(const std::string& message) {
     mcpp::warning(folded.c_str());
 }
 
-// The installer program, or empty after saying which line brings it.
-inline std::string launcher(std::string_view member, std::string_view feature) {
-    const std::string tool = mcpp::dep_bin("plugins", "mcpp-deps");
-    if (!tool.empty()) return tool;
-    std::cerr << std::format(
-        "{0}: the installation runs as a build action, and an action's command is\n"
-        "  a program: `mcpp-deps`, built from this package. Ask for it on the edge\n"
-        "  that brings the member in:\n\n"
-        "      [build-dependencies.mcpp]\n"
-        "      plugins = {{ version = \"{1}\", features = [\"{2}\"], host-module = true,\n"
-        "                  tools = [\"mcpp-deps\"] }}\n",
-        member, mcpp::plugins::version, feature);
-    return {};
+// A CMake script this build program writes, for an action whose work is more
+// than one command: `cmake -P <script>` is one argument vector, and the script
+// runs the steps in order and fails on the first that fails. Every value is a
+// bracket argument, so a path or a `-D` value keeps its spaces and semicolons.
+// The script is written only when its text changes, so its time stamp -- an
+// input of the action -- moves only when the work does.
+inline std::string bracket(std::string_view text) {
+    return "[==[" + std::string(text) + "]==]";
 }
 
 inline bool is_windows() { return std::string_view(mcpp::target_os()) == "windows"; }
@@ -180,6 +176,77 @@ inline void runtime_directory(const std::string& bin, const std::string& lib) {
     mcpp::runtime_search_dir(dir.c_str());
 }
 
+// vcpkg's own per-user directory: where its default binary cache
+// (`archives/`) and registry cache (`registries/`) already live (vcpkg's
+// "Default binary cache" documentation). Scratch and downloads go beside them.
+inline std::filesystem::path vcpkg_user_dir() {
+    namespace fs = std::filesystem;
+    auto env = [](const char* n) { const char* v = std::getenv(n); return std::string(v ? v : ""); };
+    if (std::string_view(mcpp::host()).find("windows") != std::string_view::npos) {
+        if (auto v = env("LOCALAPPDATA"); !v.empty()) return fs::path(v) / "vcpkg";
+        if (auto v = env("APPDATA"); !v.empty()) return fs::path(v) / "vcpkg";
+    } else {
+        if (auto v = env("XDG_CACHE_HOME"); !v.empty()) return fs::path(v) / "vcpkg";
+        if (auto v = env("HOME"); !v.empty()) return fs::path(v) / ".cache" / "vcpkg";
+    }
+    return fs::temp_directory_path() / "vcpkg";
+}
+
+// FNV-1a over `text`: a short directory name, stable across runs and
+// compilers, which `std::hash` does not promise. Index loop: GCC 16 does not
+// inline a string's iterators across a module boundary.
+inline std::string short_name(std::string_view text) {
+    std::uint64_t h = 1469598103934665603ull;
+    for (std::size_t i = 0; i < text.size(); ++i) {
+        h ^= static_cast<unsigned char>(text[i]);
+        h *= 1099511628211ull;
+    }
+    return std::format("{:08x}", std::uint32_t(h ^ (h >> 32)));
+}
+
+// ── The compiler a subproject builds with ──────────────────────────────────
+//
+// A prefix's C++ libraries are linked into the program, so their C++ standard
+// library must be the program's. On Windows every compiler of the MSVC ABI
+// uses Microsoft's, and on macOS every compiler uses libc++; on Linux two
+// incompatible libraries exist, the host compiler that vcpkg and CMake choose
+// uses libstdc++, and mcpp's clang uses libc++ (`std::__1::`). So when the
+// program's library is libc++ on Linux, a subproject builds with mcpp's own
+// clang, whose configuration file names libc++ and the C library mcpp links
+// against; otherwise the installer's own choice already agrees and nothing is
+// stated.
+struct compilers {
+    std::string c, cxx;
+    explicit operator bool() const { return !cxx.empty(); }
+};
+
+inline compilers program_compilers() {
+    namespace fs = std::filesystem;
+    if (std::string_view(mcpp::target_os()) != "linux"
+        || std::string_view(mcpp::cxx_stdlib()) != "libc++"
+        || std::string_view(mcpp::compiler()) != "clang"
+        || std::string_view(mcpp::host()) != std::string_view(mcpp::target())) return {};
+    const fs::path bin = fs::path(mcpp::toolchain_dir()) / "bin";
+    std::error_code ec;
+    if (!fs::is_regular_file(bin / "clang++", ec) || !fs::is_regular_file(bin / "clang", ec)) return {};
+    return { generic(bin / "clang"), generic(bin / "clang++") };
+}
+
+// Writes `content` to `file` unless the file already holds it, so a file the
+// build program generates keeps its time stamp from one plan to the next and
+// the action that reads it does not run again.
+inline void write_if_changed(const std::filesystem::path& file, const std::string& content) {
+    namespace fs = std::filesystem;
+    std::error_code ec;
+    if (fs::is_regular_file(file, ec)) {
+        std::ifstream in(file, std::ios::binary);
+        const std::string old{ std::istreambuf_iterator<char>(in), std::istreambuf_iterator<char>() };
+        if (old == content) return;
+    }
+    fs::create_directories(file.parent_path(), ec);
+    std::ofstream(file, std::ios::binary | std::ios::trunc) << content;
+}
+
 // ── Files beside the program ───────────────────────────────────────────────
 //
 // Data a program reads at run time from beside itself -- a dictionary, a
diff --git a/deps/vcpkg.cppm b/deps/vcpkg.cppm
index c02b508..a9d3f3e 100644
--- a/deps/vcpkg.cppm
+++ b/deps/vcpkg.cppm
@@ -11,16 +11,17 @@
 // and three things follow, none of which the project states again:
 //
 //   1. INSTALLATION IS AN EDGE. One `prepare` action (mcpp's SPEC-007 R3.3)
-//      runs `vcpkg install` for the manifest and fills `<install root>/<triplet>`,
-//      its declared `output_dir`; this package's compile and link edges wait
+//      runs `vcpkg install` for the manifest and fills the prefix
+//      `<install root>/<triplet>/<triplet>`, its declared `output_dir`; this package's compile and link edges wait
 //      for it. It re-runs when `vcpkg.json`, `vcpkg-configuration.json` or an
 //      overlay changes, and never under `mcpp emit build-database`.
-//   2. THE PREFIX REACHES THE BUILD BY NAME. `<install root>/<triplet>/include`
-//      is an include directory; each listed library is linked by its full path;
+//   2. THE PREFIX REACHES THE BUILD BY NAME. `<prefix>/include` is an include
+//      directory; each listed library is linked by its full path;
 //      `bin/` (Windows) or `lib/` is a runtime search directory, so the
 //      program's run path, `mcpp run`, `mcpp pack` and -- on Windows -- the
 //      DLLs placed beside the program all come from the engine (R4.1, R4.3).
-//   3. THE TOOL IS A PAYLOAD. `xim:vcpkg` is the tool together with the
+//   3. THE TOOL IS A PAYLOAD, AND THE ACTION IS THE TOOL. `xim:vcpkg` is the
+//      tool together with the
 //      scripts released with it (vcpkg-tool's standalone bundle), declared by
 //      this feature. A `builtin-baseline` manifest resolves through vcpkg's
 //      git registry into vcpkg's per-user registry cache, so no clone of
@@ -47,8 +48,10 @@ export namespace mcpp::deps::vcpkg {
 struct options {
     // The vcpkg triplet. Empty derives it from the target: `x64-windows`,
     // `arm64-windows`, `x64-mingw-dynamic`, `x64-linux`, `arm64-linux`,
-    // `x64-osx`, `arm64-osx`. A custom triplet is named here and found through
-    // the manifest's `overlay-triplets` like any other.
+    // `x64-osx`, `arm64-osx`; on Linux under a libc++ toolchain, the generated
+    // `x64-linux-libcxx` or `arm64-linux-libcxx`, whose ports build with mcpp's
+    // clang. A custom triplet is named here and found through the manifest's
+    // `overlay-triplets` like any other.
     std::string triplet;
     // Library names in link order: `fmt` denotes `lib/fmt.lib` on Windows and
     // `lib/libfmt.a` or `lib/libfmt.so` elsewhere; a name with an extension
@@ -59,7 +62,12 @@ struct options {
     // root.
     std::string manifest_root;
     // Where vcpkg installs. Empty is vcpkg's own default,
-    // `<manifest root>/vcpkg_installed`.
+    // `<manifest root>/vcpkg_installed`. Each triplet is its own vcpkg
+    // installation, `<install root>/<triplet>`, whose prefix is
+    // `<install root>/<triplet>/<triplet>`: vcpkg's manifest mode removes from
+    // an installation the packages of every triplet but the one it installs,
+    // so two triplets sharing one -- a target switched, a toolchain whose C++
+    // library differs -- would each remove the other's prefix.
     std::string install_root;
     // Further overlay-triplet directories, beside the manifest's own.
     std::vector<std::string> overlay_triplets;
@@ -76,7 +84,7 @@ struct options {
 // The prefix, by name: the installation fills it during the build, and the
 // build program refers to it without looking inside (SPEC-007 R1.3).
 struct prefix {
-    std::string root;       // <install root>/<triplet>
+    std::string root;       // <install root>/<triplet>/<triplet>
     std::string include;    // root/include
     std::string lib;        // root/lib
     std::string bin;        // root/bin
@@ -182,8 +190,16 @@ inline prefix use(const options& opt = {}) {
         return {};
     }
 
-    const std::string triplet = opt.triplet.empty() ? default_triplet() : opt.triplet;
-    if (triplet.empty()) {
+    // THE C++ LIBRARY. Where the host compiler's C++ library is not the
+    // program's -- libc++ on Linux -- the default triplet is a generated one,
+    // `<triplet>-libcxx`, whose ports build with mcpp's own clang
+    // (`mcpp::deps::program_compilers`). A triplet the project names is used
+    // as it stands.
+    const mcpp::deps::compilers cc = opt.triplet.empty() ? mcpp::deps::program_compilers()
+                                                         : mcpp::deps::compilers{};
+    const std::string triplet = !opt.triplet.empty() ? opt.triplet
+                              : cc ? default_triplet() + "-libcxx" : default_triplet();
+    if (triplet.empty() || triplet == "-libcxx") {
         std::cerr << std::format("{}: no default vcpkg triplet for the target '{}'; name one with "
                                  "options::triplet.\n", who, std::string(mcpp::target()));
         return {};
@@ -191,7 +207,8 @@ inline prefix use(const options& opt = {}) {
 
     const fs::path installRoot = opt.install_root.empty()
         ? manifestRoot / "vcpkg_installed" : mcpp::deps::absolute_from_root(opt.install_root);
-    const fs::path root = installRoot / triplet;
+    const fs::path tripletRoot = installRoot / triplet;
+    const fs::path root = tripletRoot / triplet;
 
     prefix p;
     p.root      = mcpp::deps::generic(root);
@@ -213,7 +230,31 @@ inline prefix use(const options& opt = {}) {
     for (auto const& d : opt.overlay_triplets) overlayTriplets.push_back(mcpp::deps::absolute_from_root(d));
     const std::vector<fs::path> overlayPorts = manifest_overlays(manifestRoot, "overlay-ports");
 
+    // The generated triplet and the toolchain file it chains: vcpkg's own
+    // Linux toolchain, with the compilers set first.
+    fs::path generated;
+    if (cc && !vcpkgRoot.empty()) {
+        generated = fs::path(mcpp::out_dir()) / "deps-vcpkg" / "triplets";
+        const std::string arch = triplet.substr(0, triplet.find('-'));
+        const fs::path chain = generated / (triplet + ".toolchain.cmake");
+        mcpp::deps::write_if_changed(generated / (triplet + ".cmake"), std::format(
+            "# Written by mcpp.deps.vcpkg: the ports build with the program's compiler,\n"
+            "# so their C++ standard library is the program's.\n"
+            "set(VCPKG_TARGET_ARCHITECTURE {})\n"
+            "set(VCPKG_CRT_LINKAGE dynamic)\n"
+            "set(VCPKG_LIBRARY_LINKAGE static)\n"
+            "set(VCPKG_CMAKE_SYSTEM_NAME Linux)\n"
+            "set(VCPKG_CHAINLOAD_TOOLCHAIN_FILE \"{}\")\n",
+            arch, mcpp::deps::generic(chain)));
+        mcpp::deps::write_if_changed(chain, std::format(
+            "set(CMAKE_C_COMPILER \"{}\")\n"
+            "set(CMAKE_CXX_COMPILER \"{}\")\n"
+            "include(\"{}\")\n",
+            cc.c, cc.cxx, mcpp::deps::generic(fs::path(vcpkgRoot) / "scripts" / "toolchains" / "linux.cmake")));
+    }
+
     std::vector<fs::path> tripletSearch = overlayTriplets;
+    if (!generated.empty()) tripletSearch.insert(tripletSearch.begin(), generated);
     if (!vcpkgRoot.empty()) {
         tripletSearch.push_back(fs::path(vcpkgRoot) / "triplets");
         tripletSearch.push_back(fs::path(vcpkgRoot) / "triplets" / "community");
@@ -229,35 +270,52 @@ inline prefix use(const options& opt = {}) {
             "{}: the vcpkg tool is not installed (xpkg_dir(\"xim\", \"vcpkg\") answered \"{}\"), "
             "so this plan installs nothing. The `deps-vcpkg` feature declares `xim:vcpkg`; "
             "`mcpp build` provisions it before this program runs.", who, vcpkgRoot));
-    } else if (const std::string tool = mcpp::deps::launcher(who, "deps-vcpkg"); tool.empty()) {
-        return {};
     } else {
+        // THE ACTION IS vcpkg ITSELF. Everything an installation needs is an
+        // argument: `--vcpkg-root` pairs the tool with the scripts it was
+        // released with, whatever `VCPKG_ROOT` the shell has; vcpkg locks the
+        // installation root itself (`<root>/vcpkg/vcpkg-running.lock`), so two
+        // workspace members installing one root wait for each other; its build
+        // and package trees go to a short directory under vcpkg's per-user
+        // directory, because a port's build nests deep and Windows tools still
+        // enforce MAX_PATH.
         const std::string stamp = mcpp::deps::generic(
             fs::path(mcpp::out_dir()) / "deps-vcpkg" / (triplet + ".stamp"));
         const std::string id    = "deps-vcpkg:install:" + triplet;
         const std::string desc  = "VCPKG install " + triplet;
         const std::string exeS  = mcpp::deps::generic(exe);
-        const std::string mRoot = mcpp::deps::generic(manifestRoot);
-        const std::string iRoot = mcpp::deps::generic(installRoot);
+        const fs::path user     = mcpp::deps::vcpkg_user_dir();
+        const fs::path work     = user / "mcpp" / mcpp::deps::short_name(mcpp::deps::generic(tripletRoot));
+        mcpp::rerun_if_env_changed("VCPKG_DOWNLOADS");
+        const char* downloads = std::getenv("VCPKG_DOWNLOADS");
         mcpp::action a;
         a.id          = id.c_str();
         a.role        = mcpp::roles::prepare;
         a.description = desc.c_str();
-        a.arg(tool.c_str()).arg("vcpkg")
-         .arg("--vcpkg").arg(exeS.c_str())
-         .arg("--root").arg(vcpkgRoot.c_str())
-         .arg("--manifest-root").arg(mRoot.c_str())
-         .arg("--install-root").arg(iRoot.c_str())
-         .arg("--triplet").arg(triplet.c_str());
+        a.arg(exeS.c_str()).arg("install")
+         .arg(("--vcpkg-root=" + vcpkgRoot).c_str())
+         .arg("--disable-metrics")
+         .arg("--triplet").arg(triplet.c_str())
+         .arg(("--x-manifest-root=" + mcpp::deps::generic(manifestRoot)).c_str())
+         .arg(("--x-install-root=" + mcpp::deps::generic(tripletRoot)).c_str())
+         .arg(("--x-buildtrees-root=" + mcpp::deps::generic(work / "bt")).c_str())
+         .arg(("--x-packages-root=" + mcpp::deps::generic(work / "pk")).c_str())
+         .arg("--clean-buildtrees-after-build")
+         .arg("--clean-packages-after-build");
+        // Downloads are shared by every project on the machine; a user who has
+        // moved them already (`VCPKG_DOWNLOADS`) keeps that.
+        if (!downloads || !*downloads)
+            a.arg(("--downloads-root=" + mcpp::deps::generic(user / "downloads")).c_str());
         // `arg()` and `input()` copy what they are given, so the temporaries
         // below need not outlive the call.
         for (auto const& d : opt.overlay_triplets)
-            a.arg("--overlay-triplets").arg(mcpp::deps::generic(mcpp::deps::absolute_from_root(d)).c_str());
-        if (!opt.install_args.empty()) {
-            a.arg("--");
-            for (auto const& x : opt.install_args) a.arg(x.c_str());
+            a.arg(("--overlay-triplets=" + mcpp::deps::generic(mcpp::deps::absolute_from_root(d))).c_str());
+        if (!generated.empty()) {
+            a.arg(("--overlay-triplets=" + mcpp::deps::generic(generated)).c_str());
+            for (auto const& f : mcpp::deps::files_under(generated)) a.input(f.c_str());
         }
-        a.input(tool.c_str());
+        for (auto const& x : opt.install_args) a.arg(x.c_str());
+        a.input(exeS.c_str());
         a.input(mcpp::deps::generic(manifestFile).c_str());
         if (fs::is_regular_file(configFile, ec)) a.input(mcpp::deps::generic(configFile).c_str());
         // An overlay's files are inputs: a changed patch or triplet is a
diff --git a/docs/deps.md b/docs/deps.md
new file mode 100644
index 0000000..4690ffe
--- /dev/null
+++ b/docs/deps.md
@@ -0,0 +1,166 @@
+# `deps-vcpkg`, `deps-cmake` and `deps-archive`
+
+The `deps-*` members answer where a library comes from: a vcpkg manifest, a CMake subproject, or an archive the project keeps. Each installation is an action with declared inputs and outputs, and the prefix reaches the build by name (include directory, libraries by full path, runtime search directory), so planning installs nothing.
+
+## `deps-vcpkg`
+
+Module `mcpp.deps.vcpkg`; engine floor: 2026.9.26.2 (mcpp#702).
+
+**Needs and behaviour.** `xim:vcpkg` (the tool and the scripts released with it), which this feature declares on the host axis. From 0.13.0. Installs a `vcpkg.json` manifest as a `prepare` action and maps `<install root>/<triplet>/<triplet>` into the build by name, its shared-library directory a runtime search directory; `mcpp emit build-database` installs nothing. See [the section below](#deps-vcpkg-the-libraries-a-vcpkg-manifest-names)
+
+## `deps-cmake`
+
+Module `mcpp.deps.cmake`; engine floor: 2026.9.26.2 (mcpp#702).
+
+**Needs and behaviour.** `xim:cmake`, which this feature declares on the host axis. From 0.13.0. Configures, builds and installs a CMake subproject as one `prepare` action whose inputs are the subproject's files, and maps the prefix as `deps-vcpkg` does
+
+## `deps-archive`
+
+Module `mcpp.deps.archive`; engine floor: 2026.9.26.2.
+
+**Needs and behaviour.** `xim:cmake`, which this feature declares on the host axis. From 0.14.0. Extracts a zip archive the project keeps and places its tree beside the program: one action names every member as an output, read from the archive's central directory while the build program runs, and each is deployed, so `mcpp run` finds the files and `mcpp pack` carries them. See [the section below](#deps-vcpkg-the-libraries-a-vcpkg-manifest-names)
+
+## `deps-vcpkg`: the libraries a vcpkg manifest names
+
+```toml
+[build-dependencies.mcpp]
+plugins = { version = "0.15.0", features = ["deps-vcpkg"], host-module = true }
+```
+
+```cpp
+// build.mcpp
+import std;
+import mcpp;
+import mcpp.deps.vcpkg;
+
+int main() {
+    mcpp::deps::vcpkg::options o;
+    o.libraries = { "fmt", "spdlog" };
+    return mcpp::deps::vcpkg::use(o) ? 0 : 1;
+}
+```
+
+`use()` finds `vcpkg.json` at or above the package root, so every member of a
+workspace finds a manifest kept at the workspace root. It then:
+
+- declares `vcpkg install …` as a `mcpp::roles::prepare` action whose output
+  directory is the prefix `<install root>/<triplet>/<triplet>` and whose inputs are `vcpkg.json`,
+  `vcpkg-configuration.json` and every file of the manifest's overlay ports and
+  triplets. The package's compile and link edges wait for it; it runs under
+  `mcpp build` when an input changed, and never under `mcpp emit
+  build-database`;
+- adds `<prefix>/include` as an include directory;
+- links each name in `options::libraries` by its full path under
+  `<prefix>/lib` (`fmt` is `fmt.lib` on Windows, `libfmt.a` or
+  `libfmt.so` elsewhere; a name with an extension is a file name);
+- for a triplet that links dynamically, declares `bin/` (Windows) or `lib/`
+  (elsewhere) with `mcpp::runtime_search_dir`: the program's run path on ELF and
+  Mach-O, `mcpp run`'s load path, `mcpp pack`'s closure, and on Windows the
+  DLLs the program imports placed beside it after the link;
+- copies each file `options::deploy` names out of the prefix, by an action
+  that names the copy as its output, and deploys the copy beside the program;
+- returns the prefix (`root`, `include`, `lib`, `bin`, `share`, `triplet`, and
+  `deployed`, the copies, for a project that lays out a directory of its own).
+
+A vcpkg tool that is not installed is a warning and not a failure: the plan
+states every path it can, and the build is where the absence fails.
+
+| option | meaning |
+|---|---|
+| `triplet` | empty derives it from the target: `x64-windows`, `arm64-windows`, `x64-mingw-dynamic`, `x64-linux`, `arm64-linux`, `x64-osx`, `arm64-osx`; on Linux under a libc++ toolchain the generated `x64-linux-libcxx` or `arm64-linux-libcxx` (0.15.0); a custom triplet is found through the manifest's `overlay-triplets` |
+| `libraries` | the link, in order; a name that matches no installed file fails the link, naming its path |
+| `manifest_root` | the directory holding `vcpkg.json` |
+| `install_root` | empty is vcpkg's default, `<manifest root>/vcpkg_installed`. Each triplet is its own vcpkg installation, `<install root>/<triplet>`, because vcpkg's manifest mode removes from an installation the packages of every other triplet (0.15.0; 0.14.0's prefix `<install root>/<triplet>` is no longer read) |
+| `overlay_triplets` | further overlay-triplet directories |
+| `install_args` | arguments appended to `vcpkg install` |
+| `vcpkg_root` | a vcpkg root other than the `xim:vcpkg` payload |
+| `deploy` | files of the prefix the program reads at run time, each `{file, to}`: `file` relative to the prefix root, `to` the directory beside the program (`{"share/opencc/t2s.json", "BaseConfig/opencc"}`) |
+
+The payload `xim:vcpkg` is vcpkg-tool's release binary with the standalone
+bundle published beside it, so the scripts a port calls are the ones that tool
+was released with. A `builtin-baseline` manifest resolves through vcpkg's git
+registry, into vcpkg's per-user registry cache; no clone of microsoft/vcpkg is
+made per project. The action is vcpkg itself, configured by arguments
+alone (0.15.0; 0.13.0-0.14.0 ran it through a program of this package):
+`--vcpkg-root` names the payload, whatever `VCPKG_ROOT` the shell has;
+`--disable-metrics`; the downloads and each installation's build trees go to
+vcpkg's per-user directory (`%LOCALAPPDATA%\vcpkg` on Windows,
+`$XDG_CACHE_HOME/vcpkg` or `~/.cache/vcpkg` elsewhere), beside vcpkg's default
+binary cache, under a short name, because Windows tools still enforce MAX_PATH;
+an existing `VCPKG_DOWNLOADS` is kept. vcpkg locks the installation root itself
+(`<root>/vcpkg/vcpkg-running.lock`), so two workspace members installing one
+root run one after the other. vcpkg fetches its
+own CMake, Ninja and 7-Zip, and on Windows a portable git; on Linux and macOS
+its documented host prerequisites (git, curl, zip, unzip, tar, a C compiler)
+are the host's. Ports are compiled with vcpkg's default toolchain for the
+triplet: the Visual Studio toolset on Windows, the host compiler elsewhere. The
+program links them, so its C++ standard library must be theirs. On Windows every
+compiler of the MSVC ABI, mcpp's clang included, uses Microsoft's, and on macOS
+every compiler uses libc++, so a port links as it stands. Linux has two
+libraries that do not link with each other: the host compiler uses libstdc++,
+and mcpp's clang uses libc++ (`std::__1::`). Under a libc++ toolchain the
+default triplet is therefore a generated one, `<arch>-linux-libcxx`, whose
+ports build with mcpp's clang through vcpkg's chain-loaded toolchain file; the
+clang's own configuration names libc++ and the C library mcpp links against.
+Under a gcc toolchain the default triplet is vcpkg's own (0.15.0).
+
+Not supported: vcpkg's classic mode; the debug libraries under `debug/lib`.
+
+## `deps-cmake`: a CMake subproject
+
+```cpp
+import mcpp.deps.cmake;
+
+int main() {
+    mcpp::deps::cmake::options o;
+    o.source     = "3rdParty/widgets";
+    o.cache_args = { "-DWIDGETS_BUILD_EXAMPLES=OFF" };
+    o.libraries  = { "widgets" };
+    o.shared     = true;
+    return mcpp::deps::cmake::use(o) ? 0 : 1;
+}
+```
+
+One `prepare` action, `cmake -P` over a script the member writes
+(`<out dir>/deps-cmake/<name>.cmake`), configures, builds and installs the
+subproject into `<out dir>/deps-cmake/<name>/install`, its declared output
+directory; its inputs are the script and the subproject's files, so an edit to the subproject rebuilds it. The prefix is mapped as `deps-vcpkg`
+maps its own. `layout` names install directories other than `include/`, `lib/`
+and `bin/`; `prefix_path` becomes `CMAKE_PREFIX_PATH` (`mcpp::rules::qt::root()`
+for a subproject that finds Qt); `cache_args` carries `-D…`, `-G …` and a
+toolchain file. The subproject is compiled with the toolchain CMake selects by
+default unless `cache_args` names a compiler or a toolchain file; on Linux under
+a libc++ toolchain the compilers are mcpp's clang, as `deps-vcpkg` builds its
+ports (0.15.0). `deploy` places files of the prefix
+beside the program, as `deps-vcpkg` takes it.
+
+## `deps-archive`: files a program reads at run time, from an archive
+
+```cpp
+import mcpp.deps.archive;
+
+int main() {
+    mcpp::deps::archive::options o;
+    o.archive = "assets/python-embed.zip";
+    o.to      = "runtime";
+    return mcpp::deps::archive::unpack(o) ? 0 : 1;
+}
+```
+
+`unpack()` reads the archive's central directory while the build program runs,
+so every file it holds is named before anything is extracted. One `artifact`
+action, `cmake -P` over a script the member writes, empties
+`<out dir>/deps-archive/<name>` and extracts the archive there with
+`file(ARCHIVE_EXTRACT ... TOUCH)`, naming each file as an output; each file is then
+deployed under `to`, so `mcpp run` finds it beside the program and `mcpp pack`
+carries it. The action's inputs are the archive and the tool, so an edited
+archive is extracted again and an unchanged one is not; `mcpp emit
+build-database` extracts nothing. `result::files` lists the extracted copies
+with their paths beside the program, for a project that lays out a directory of
+its own. A C++ file inside the archive is data: the action's outputs never join
+the package's compile set.
+
+Only zip is read, because a compressed tar has no index to list without
+decompressing it while planning; a ZIP64 archive is refused by name, as is a
+member whose path would leave the extraction directory. A missing `cmake` is a
+warning, and the plan then extracts and deploys nothing.
diff --git a/docs/dist-apk.md b/docs/dist-apk.md
new file mode 100644
index 0000000..e738663
--- /dev/null
+++ b/docs/dist-apk.md
@@ -0,0 +1,120 @@
+# `dist-apk`
+
+`mcpp.dist.apk` packs the native closure `mcpp pack` stages into a signed APK or an App Bundle for Android, with an optional Java or Kotlin layer, Android libraries and a Maven graph.
+
+## `dist-apk`
+
+Module `mcpp.dist.apk`; engine floor: 2026.9.14.2 from 0.10.0, which stages the closure this member reads; before it 2026.9.13.1, raised alongside `dist-web` in the same 0.9.0 release: this member's own manifest-template and Java-array changes ask nothing new of the engine, but this collection publishes one package at one version, and this is the release CI verifies it under from here on.
+
+**Needs and behaviour.** `xim:android-build-tools`, `xim:android-platform` (versioned by API level, read back for `targetSdkVersion`), `xim:jdk-temurin` (`javac`/`jar`/`jarsigner`; `android-build-tools`' own runtime dependency provisions a JDK for its OWN wrappers only), `xim:android-debug-keystore`, `xim:bundletool` (0.10.0, for `--format aab`), all on the `cfg(env = "android")` axis. Generates `AndroidManifest.xml` and signs with the published Android debug key by default. Level 0 needs no Java (`hasCode="false"`, `android.app.NativeActivity`); `options::java_sources` adds `javac` + `d8` and a real `<activity>`. `options::manifest_template` renders a project manifest with six tokens substituted verbatim; `{{application_id}}` and `{{activity}}` are required always and `{{lib_name}}` at level 0, each refused by name at plan time when missing (naming `assets/mcpp-run.json`, which `adb-run` reads them from too) or when the template names an unknown token; empty renders 0.8.0's manifest byte-identically. From 0.9.3 the manifest template gains `{{version_name}}` / `{{version_code}}` (the package version, and `major * 1000000 + minor * 1000 + patch`). `options::resources` is a project's own `res/`, linked as the application's base resources from 0.9.1 (0.9.0 linked it as an aapt2 overlay, which refuses every resource the base does not already define -- a launcher icon could not be supplied). `options::java_sources` is an array: one `javac` over every root's `.java` files and one `d8` over the result, so a project's own sources and a path dependency's join without being merged into one directory first, and `rerun_if_changed_glob` is declared only for a root under `mcpp::manifest_dir()` -- a dependency root's files are already inputs of the `javac` action and its version is already in the build's fingerprint. Android only -- an `app` target is a shared object on this row (#622 A3). From 0.10.0, with mcpp 2026.9.14.2, the member reads the native closure the engine stages -- the application object, the graph's shared libraries and `libc++_shared.so` under `lib/` for one `--target`, `lib/<abi>/` for several -- and packs every ABI the tree carries into one APK; its own `NEEDED` walk and the stamp that lost a dependency's library on a second pack are gone. A stage manifest without `needs` lines comes from an engine below 2026.9.14.2 and is refused naming that floor, as is an incomplete closure, naming the unresolved libraries; every refusal is also a `mcpp::warning`, because the engine discards a build program's output when it exits 0. `--format aab` shares every step but the last three: `aapt2 link --proto-format` (with `--version-code` / `--version-name`, which bundletool requires), a base module in the layout bundletool reads, `bundletool build-bundle` from `xim:bundletool` (declared on the same axis), and `jarsigner` with the same keystore. CI packages both level 0 and level 1 and checks the archive (`mcpp::deploy`'d files under `assets/`), and on `tests/apk-consumer-shared` two packs in a row, a two-ABI APK (`aapt2` reports both, `apksigner` verifies it), an App Bundle (`bundletool validate`, `jarsigner -verify`, a universal APK from `bundletool build-apks`), a refusal's reason in `mcpp pack`'s output, and the floor refusal; the runner has no emulator or device, so the two rows that actually run were measured locally on 2026-09-12, through `adb-run`, against a KVM-accelerated x86_64 emulator and a physical arm64-v8a phone, both printing `1-2-3` and exiting 0. From 0.11.0: Kotlin sources (`dist-apk-kotlin`, which declares `xim:kotlin`), R classes, Android libraries from source, local AARs and JARs, a Maven graph through a lock file (`dist-apk-maven`, which declares `xim:coursier`), a manifest merge, and an unsigned package -- see [`dist-apk`: Kotlin, libraries and a Maven graph](#dist-apk-kotlin-libraries-and-a-maven-graph). From 0.11.1 the native libraries are packed as the Android Gradle plugin packs them: each is stripped with the build's own `llvm-strip --strip-unneeded` (the NDK's, beside the compiler `mcpp::toolchain_dir()` reports; `options::keep_debug_symbols` packs them as staged), and a manifest stating `android:extractNativeLibs="false"` gets them stored uncompressed on a 16 KB page, which loading them from the APK in place requires; CI checks both, and the symbol table `keep_debug_symbols` keeps. From 0.12.0 the engine's strip decision governs these libraries as well: under mcpp 2026.9.16.1, which publishes it to build programs as `MCPP_PACK_STRIP` and `MCPP_PACK_DEBUG_SYMBOLS_DIR`, that engine strips and separates the libraries it stages itself and the member packs them as staged, while the libraries the engine did not stage -- an archive's `jni/` libraries -- follow the same decision inside the member: `--no-strip` packs them as they are, and `--debug-symbols <dir>` separates each one's debug information into `<dir>/<abi>/<library>.debug` with `llvm-objcopy` before stripping it and linking the packed copy to that file (`.gnu_debuglink`). A library is stripped unless either `keep_debug_symbols` or the engine says to keep it, and under an older engine, which publishes neither variable, the member strips every library as before. Because that engine strips before the member reads the tree, `keep_debug_symbols` keeps only the member's own strip off and `--no-strip` is what ships the symbols of the libraries the graph built; the member warns when the option is set and the engine stripped. From 0.12.0 a library in the resolved graph contributes libraries and archives through `[package.metadata.dist-apk]`, ranked below the application's own -- see [A library states its contribution](#a-library-states-its-contribution-packagemetadatadist-apk)
+
+## `dist-apk`: Kotlin, libraries and a Maven graph
+
+From 0.11.0 a level-1 package takes what a Gradle application module takes.
+Every path option is relative to the manifest or absolute.
+
+| option | what it adds | payload |
+|---|---|---|
+| `kotlin_sources` | Directories of `.kt` sources. `kotlinc` compiles them first (`-jvm-target 17`), with every Java root as reference sources; `javac` then compiles the Java against the Kotlin classes, and `d8` dexes both with `kotlin-stdlib.jar`. This option or `java_sources` makes a level-1 package, and both may be set | `xim:kotlin`, declared by the `dist-apk-kotlin` feature |
+| (none) | R classes. A package with code links with `aapt2 link --java`, and the `R` classes of the application, of each library and of each archive are compiled with the sources (`--extra-packages`) | |
+| `libraries` | Android libraries from source, each with `package` (its R package), `resources`, `manifest`, `assets`, `java_sources` and `kotlin_sources`. A library listed earlier wins a resource both define, and the application's own `resources` win over every library | |
+| `aars`, `jars` | Local archives. A JAR joins the classpath and the dex. An AAR contributes `classes.jar`, `res/` (under the package its manifest names), its manifest, `jni/<abi>/*.so` and `assets/`. Archives rank after `libraries` | |
+| `maven`, `maven_repositories`, `maven_lock`, `maven_cache` | `group:artifact:version` coordinates, resolved with their transitive dependencies into a lock file. The resolved AARs and JARs are then handled like `aars` and `jars`, and rank after them. The defaults are Google's Maven repository then Maven Central, `maven.lock` beside the manifest, and `COURSIER_CACHE` then coursier's own cache directory for the host | `xim:coursier`, declared by the `dist-apk-maven` feature |
+| `graph_libraries` | From 0.12.0, `true` by default: the libraries and archives the resolved graph's packages state in `[package.metadata.dist-apk]` (see below). `false` reads none, for an application that lists every library itself | |
+| `sign` | `false` writes the aligned package unsigned, with no `apksigner` for an APK and no `jarsigner` for an App Bundle, for a pipeline that signs elsewhere. It is refused together with `keystore` | |
+
+Both features imply `dist-apk`, so a project names them in its place:
+
+```toml
+[build-dependencies.mcpp]
+plugins = { version = "0.11.0", features = ["dist-apk-kotlin", "dist-apk-maven"], host-module = true }
+```
+
+They are features and not payloads of `dist-apk` because provisioning runs
+before the build program says what it compiles. A payload of `dist-apk` would be
+installed for every Android consumer, and the Kotlin compiler is 90 MB. Kotlin
+sources without the feature are refused, naming it.
+
+**An ordinary build does not reach the network.** A Maven graph is resolved and
+downloaded only when the developer asks:
+
+| `MCPP_DIST_APK_MAVEN` | what `mcpp pack` does |
+|---|---|
+| unset | Reads each locked artifact from the cache and checks its sha256 against the lock. A missing lock is refused, and so is a lock resolved for other coordinates, or an artifact absent from the cache. Each refusal names the mode that fixes it. The lock records the repositories it was resolved from without requiring them: a mirror that serves the same bytes passes the digest check |
+| `update` | `cs fetch` resolves the coordinates, downloads the graph and writes the lock, one line per file: `artifact <coordinate> <aar\|jar> <path in the cache> <sha256>` |
+| `fetch` | Downloads exactly the locked artifacts into the cache (`--intransitive`, one per module), for a machine that has the lock and an empty cache |
+
+Commit the lock. Nothing is shrunk or obfuscated, and an archive's ProGuard
+rules are ignored.
+
+**The manifest merge is a stated subset of the Android Gradle plugin's
+merger** (`merge_manifests` in `dist/apk.cppm`):
+
+- An element is added when the application has none of the same kind and
+  `android:name`. This covers the children of `<manifest>`
+  (`<uses-permission>`, `<uses-feature>`, `<permission>`, ...) and of
+  `<application>` (activities, services, receivers, providers, `<meta-data>`,
+  ...). `<queries>` children are unioned, and an identical element is added
+  once.
+- A different element under the same name is refused, naming the element and
+  the library. The exceptions are an application element that says
+  `tools:node="replace"`, which keeps the application's, and one that says
+  `tools:node="remove"`, which keeps neither. A differing `<application>`
+  attribute is refused unless the application lists it in `tools:replace`.
+- A library whose `minSdkVersion` is above the application's is refused.
+- `${applicationId}` is substituted. Any other `${...}` placeholder is refused.
+- `tools:` attributes and the `xmlns:tools` declaration are removed from the
+  result.
+
+Anything beyond that belongs in the project's `manifest_template`.
+
+`tests/apk-consumer-libraries` measures the options together on Linux:
+
+- one signed APK from a Kotlin and Java application, a library from source, an
+  AAR and a JAR, with every class dexed, three R packages, the application's
+  value for a resource the library also defines, and the merged manifest;
+- `sign = false`;
+- an App Bundle from the same inputs;
+- a manifest conflict refused by name;
+- the Maven modes, each refusal included.
+
+**The build host is Linux.** Every payload publishes a macOS table, and the
+member's plan runs on macOS, but mcpp 2026.9.14.2 does not link an Android row
+on a macOS host: the application's own link fails with `ld64.lld: error: unknown
+argument '-soname'` before this member runs, because the engine states the
+target triple on that host's link line only for an Apple row
+(mcpp-community/mcpp#647, E3). The Windows host has no Android row, because the
+Windows NDK carries no libc++ module surface (`xim-pkgindex`,
+`pkgs/a/android-ndk.lua`).
+
+### A library states its contribution: `[package.metadata.dist-apk]`
+
+From 0.12.0, with mcpp 2026.9.16.1, a library states in its own manifest what it
+contributes to an Android package, and every application that depends on it
+carries that without naming the library in its build program:
+
+```toml
+# the library's mcpp.toml
+[package.metadata.dist-apk]
+package        = "org.example.widgets"   # its R package
+resources      = "android/res"
+manifest       = "android/AndroidManifest.xml"
+assets         = "android/assets"
+java_sources   = ["android/java"]
+kotlin_sources = ["android/kotlin"]
+jars           = ["android/libs/support.jar"]
+aars           = ["android/libs/player.aar"]
+```
+
+Every key is optional, and each has the meaning of the `library` field or the
+option of the same name; paths are relative to the library's directory. The
+engine hands the application's build program the resolved graph
+(`MCPP_GRAPH_FILE`), and `dist-apk` reads the table of every package in it other
+than the application. The contributions rank below the application's own
+`libraries`, `jars` and `aars`, and a package ranks above the packages it depends
+on, so an application's resource overrides a library's and a library's overrides
+the framework beneath it. A key of the wrong shape is refused naming the package
+and the key; a key this version does not read is reported with a warning and
+ignored, so a library may state a key a newer collection reads. Under an older
+engine there is no graph, and nothing is contributed. CI checks both engines on
+`tests/apk-consumer-graph`.
diff --git a/docs/dist-apple.md b/docs/dist-apple.md
new file mode 100644
index 0000000..81b1127
--- /dev/null
+++ b/docs/dist-apple.md
@@ -0,0 +1,59 @@
+# `dist-apple`
+
+`mcpp.dist.apple` lays out the staged tree as a macOS or iOS application bundle, signs it, writes a disk image, and runs the bundle under `mcpp run --format app`.
+
+## `dist-apple`
+
+Module `mcpp.dist.apple`; engine floor: 2026.9.14.2 (0.10.0); 2026.9.11.2 (macOS) and 2026.9.12.3 (iOS) before it.
+
+**Needs and behaviour.** the base macOS install (`ditto`, `codesign`, `hdiutil`), and `xim:macapp-run` for `mcpp run` on macOS, which this feature declares with `when = "run"`. macOS: `Contents/`-shaped, as always. iOS (`aarch64-ios-sim`, `aarch64-ios`): a flat bundle at the same call site -- no separate feature, no separate module -- with `MinimumOSVersion` from `mcpp::min_platform_version()` (#622 A11), `CFBundleSupportedPlatforms` read from `env == "sim"`, `UIDeviceFamily`, `LSRequiresIPhoneOS`, and a directory of flat PNGs listed under `CFBundleIcons` in place of macOS's single `.icns` file. Signing is skipped on the simulator row (`options::identity` is ignored, with a `mcpp::warning` naming why), and the device row signs only with an identity. The iOS row is measured end to end on `macos-15`: a real `mcpp build`, `mcpp pack --format app` and `mcpp run` against `aarch64-ios-sim`, through `xim:apple-simulator-tools`' `simctl-run`. **The macOS floor is one release higher than its siblings** and the reason is not this member: under 2026.9.11.1 `mcpp pack` staged before dispatching and let a staging failure fail the command, so on a Mach-O program -- which the built-in closure walk refuses, because it uses `LD_TRACE_LOADED_OBJECTS` and dyld answers that by running the program -- every dispatched format was unreachable, including one that reads no staged tree. 2026.9.11.2 makes staging a service to the provider. From 0.9.2 the staged tree's deployed files (`bin/<to>/...`, which the engine stages for a Mach-O program before the closure walk since the release for mcpp#630) land at the bundle's resource destination -- `Contents/Resources/<to>/...` on macOS, the bundle root on iOS -- and the launcher alone goes to the executable directory, so `CFBundleExecutable` names a file that is where it says. The iOS fixture declares `llvm.libcxx` and `llvm.compiler-rt-builtins` under `cfg(os = "ios")`, which is what an application that imports `std` on those rows declares. From 0.10.0, with mcpp 2026.9.14.2: the dylibs the engine stages beside a Mach-O program, which the stage manifest's `needs` lines name, go to `Contents/Frameworks/` (`Frameworks/` on iOS) and not to the resources; the program is linked with the rpath that finds them there (`@executable_path/../Frameworks`, `@executable_path/Frameworks` on iOS) through `mcpp::link_flag`, so no file is edited after the link; a macOS bundle without `options::identity` is signed ad hoc, frameworks first and the bundle second, which `codesign --verify --deep --strict` requires of a bundle that carries a framework; an incomplete closure is a `mcpp::warning` naming the unresolved libraries; every refusal is a `mcpp::warning` as well, because the engine discards a build program's output when it exits 0. On macOS the member supplies the runner named `app` (`macapp-run`), so `mcpp run --format app` runs the bundle's executable in the foreground and returns its status with no runner in the manifest; a manifest runner of that name wins. `--format dmg` stages the bundle beside an `Applications` link and writes a UDZO image with `hdiutil create` (`options::volume_name`, `options::dmg`); it is refused on iOS. An engine below 2026.9.14.2 stages no `needs` lines, so the bundle carries no framework, anchors the rpath to the package directory, and hands the bundle directory to the kernel under `mcpp run --format app` unless `--runner app` is typed. CI measures the bundle on `macos-15`: the load command, the signature, the program with and without its framework (exit 7, then "Library not loaded"), `mcpp run --format app` with and without `--runner app`, and `hdiutil verify` and an attached image. From 0.11.0: a project's own Info.plist entries (`options::info_plist`), an iOS device bundle's provisioning profile (`options::provisioning_profile`), and `devicectl-run` (`xim:apple-device-tools`) as the device row's runner named `app` -- see [`dist-apple`: a project's Info.plist, and an iOS device](#dist-apple-a-projects-infoplist-and-an-ios-device). From 0.12.0 `options::omit_keys` leaves out a key the member only defaults -- see [`dist-apple`: a project's Info.plist, and an iOS device](#dist-apple-a-projects-infoplist-and-an-ios-device). From 0.12.0 a package in the resolved graph contributes Info.plist entries through `[package.metadata.dist-apple]`, applied before the application's own
+
+## `dist-apple`: a project's Info.plist, and an iOS device
+
+| option | what it does |
+|---|---|
+| `info_plist` | A plist whose top-level `<dict>` entries join the bundle's Info.plist: usage descriptions, URL types, background modes. A key the member derives is refused by name: `CFBundleExecutable`, `CFBundleIdentifier`, `CFBundleName`, `CFBundleShortVersionString`, `CFBundleVersion`, `CFBundlePackageType`, `LSMinimumSystemVersion`, `MinimumOSVersion`, `CFBundleSupportedPlatforms`, `CFBundleIconFile`, `CFBundleIcons`. A key it only defaults takes the project's value: `UIDeviceFamily`, `LSRequiresIPhoneOS`, `NSHighResolutionCapable`. Without `info_plist` the plist is byte-identical to 0.10.1's |
+| `omit_keys` | From 0.12.0. Defaulted keys to leave out of the Info.plist, for a project whose other build states neither: `UIDeviceFamily`, `LSRequiresIPhoneOS`, `NSHighResolutionCapable`. A property list has no null, so `info_plist` can replace a default's value but cannot remove its key. A key the member derives, a key it never writes, a key named twice, and a key `info_plist` also sets are each refused by name. A key that does not apply to the row (`UIDeviceFamily` on macOS) changes nothing |
+| `graph_info_plist` | From 0.12.0, `true` by default: the Info.plist entries the resolved graph's packages state (see below). `false` reads none |
+| `provisioning_profile` | The device row (`aarch64-ios`) only, and only with `identity`. The profile is embedded as `embedded.mobileprovision`. Its `Entitlements` dictionary signs the bundle unless `entitlements` names a file, with a wildcard `application-identifier` stated as the bundle's own. That identifier must cover the bundle identifier: exactly, `<team>.*`, or `<team>.<prefix>.*`. The plist is read from the profile's bytes, so a plan made on any host checks it; verifying the profile's CMS signature is left to `codesign` and the device |
+
+A library states its Info.plist entries in its own manifest (0.12.0, mcpp
+2026.9.16.1), as a plist of the shape `info_plist` takes, its path relative to
+the library's directory:
+
+```toml
+# the library's mcpp.toml
+[package.metadata.dist-apple]
+info_plist = "apple/Info-fragment.plist"
+```
+
+The entries of every package in the resolved graph other than the application
+are applied in the graph's order, dependencies first, so a package overrides the
+packages it depends on; the application's own `info_plist` is applied last and
+wins every key, and a key the application names in `omit_keys` is left out
+whoever contributes it. A key the member derives is refused in a contribution as
+in `info_plist`, naming the package. Under an older engine there is no graph, and
+nothing is contributed.
+
+On the device row the member supplies the runner named `app`: `devicectl-run`,
+from `xim:apple-device-tools`, which the feature declares with `when = "run"` on
+that row alone. `mcpp run --target aarch64-ios --format app` installs the signed
+bundle on a connected device with `xcrun devicectl device install app`, then
+launches it with the console attached. `DEVICECTL_RUN_DEVICE` names a device;
+unset, the first connected iOS device is used. The simulator row keeps
+`simctl-run`.
+
+**Not yet measured:** no runner this repository uses has a device, and the
+device bundle, its signature and whether `devicectl` returns the program's exit
+status have not been measured on one; `devicectl-run` prints that when it runs.
+CI measures the rest:
+
+- On Linux, the plan: the entries, a refused key, an omitted default on iOS
+  and on macOS and the three refusals of `omit_keys`, the graph's entries in
+  the graph's order with the application's winning and `graph_info_plist =
+  false`, a contributed derived key refused naming its package, an unreadable
+  graph document refused, the embedded profile, the
+  entitlements, a wildcard profile, and the refusals of a profile for another
+  identifier, on the simulator row, or without an identity.
+- On `macos-15`: the entries in a real macOS bundle that `plutil` accepts and
+  that launches, and in a simulator bundle that the simulator runs.
diff --git a/docs/dist.md b/docs/dist.md
new file mode 100644
index 0000000..893fa4f
--- /dev/null
+++ b/docs/dist.md
@@ -0,0 +1,21 @@
+# `dist-appimage`, `dist-wix` and `dist-web`
+
+Three `dist-*` members that turn the tree `mcpp pack` stages into an installable form: an AppImage on Linux, an MSI or a Burn bundle on Windows, and a web directory for `wasm32-emscripten`. `dist-apple` and `dist-apk` have pages of their own ([dist-apple.md](dist-apple.md), [dist-apk.md](dist-apk.md)).
+
+## `dist-appimage`
+
+Module `mcpp.dist.appimage`; engine floor: 2026.9.11.1.
+
+**Needs and behaviour.** `xim:appimagetool`, which this feature declares on the `cfg(linux)` axis. Linux only. Turns the tree `mcpp pack` staged into one AppImage: the staged bundle is already an AppDir bar three files, so the member writes an `AppRun`, a `.desktop` entry and an icon into it and invokes one tool -- it never copies or re-lays-out a tree that can be hundreds of megabytes. From 0.11.1 `options::icon` may be an SVG as well as a PNG: the image carries `<name>.svg`, because the desktop entry names the icon without an extension and a reader finds it by the file's, and any other format is refused by name
+
+## `dist-wix`
+
+Module `mcpp.dist.wix`; engine floor: 2026.9.11.1.
+
+**Needs and behaviour.** `xim:wix` 5.0.2-1, which this feature declares on the Windows target axis; the .NET 6 runtime the tool needs is a Windows component the payload does not carry, and `wix --version` names it when it is missing. Windows only. `--format msi` renders a `.wxs` and passes the program in as a preprocessor variable, because a bind path that resolves to nothing is silent. From 0.10.0 `--format setup` is a Burn bundle chaining that MSI, with WiX's stock bootstrapper application (`bal:WixStandardBootstrapperApplication`, theme `hyperlinkLicense`, `options::license_url` its link) loaded through the `WixToolset.BootstrapperApplications.wixext` extension the 5.0.2-1 payload carries (`options::extension` names another). The bundle is written as `<product_name>-<arch>.exe` beside the MSI, with an UpgradeCode of its own, and `options::bundle_output` naming `setup.exe` is refused before `wix` runs, because `wix` refuses that name (WIX0388). A project with its own bootstrapper application supplies `options::bundle_wxs`, which receives the MSI as `$(Msi)`. From 0.10.1 the MSI installs the staged tree, not the program alone: every file `mcpp pack` stages beside the program (a deployed file, a resolved DLL) is named file by file in a `StagedFiles` component group written beside the definition -- enumerated while the tree exists, never harvested from a directory -- placed at its staged path under `INSTALLFOLDER`, and declared an input of the action; the generated definition references the group, and a project's own `options::wxs` installs it with `<ComponentGroupRef Id="StagedFiles" />`. `options::inputs` and `options::bundle_inputs` declare the files a project's own definitions name beyond that (an icon, a bootstrapper application and its payloads). CI builds the bundle on `windows-2022` and compares the MSI `wix burn extract` takes out of it with the one the first action wrote, and installs the MSI administratively and compares both the program and a deployed file
+
+## `dist-web`
+
+Module `mcpp.dist.web`; engine floor: 2026.9.13.1, the release that carries `${mcpp.self}` and `mcpp stage`'s argument shape as an engine contract (`stage --verify content --output <dst> <src>`) -- what lets this member's copy run on every host mcpp does, Windows included, in place of the `cp` this member used through 0.8.0.
+
+**Needs and behaviour.** nothing beyond mcpp: `wasm32-emscripten` only. Copies `${mcpp.stage_dir}/bin/` -- the `.js` launcher, the implicit `.wasm`, the `.data` when present, and every `mcpp::deploy`'d file, all of which #622 A5 and A4 already stage there -- to `<out_dir>/web/`, dropping the `bin/` prefix a browser has no use for, and writes an `index.html` rendered from a project template or a built-in default that loads the script with a plain `<script src>`. Each staged file and the rendered page are copied with `${mcpp.self} stage --verify content --output <dst> <src>`, the same copier every `stage_file` edge in `build.ninja` already runs -- no host-specific copy tool, no plan-time `create_directories` (`stage` creates the destination's parent), and a second `mcpp pack --format web` with nothing changed copies nothing. From 0.12.0 `options::page` names the page (`index.html` by default), for a project whose other build names it after the target; a name that is not a bare `*.html` file name is refused at plan time
diff --git a/docs/engine-and-rules.md b/docs/engine-and-rules.md
new file mode 100644
index 0000000..d442c43
--- /dev/null
+++ b/docs/engine-and-rules.md
@@ -0,0 +1,369 @@
+# How the members meet the engine
+
+How a rule reaches the engine: each rule declares its own environment and the file extensions it claims, a consumer names a member through features and the declarations a payload generates, and the engine compiles each member as a host module. The section on what a rule may drive states the one constraint every member shares: it drives only a compiler the ecosystem resolved.
+
+## Naming, in full
+
+The four families answer four different questions, and the prefix is which
+one a member answers:
+
+```
+rules-*   how is this translation unit compiled
+tools-*   what does the build program need to do itself
+dist-*    what comes out of the link, and in what form a user installs it
+deps-*    where does a library come from
+```
+
+A `dist-*` member fits neither of the first two definitions: it does not
+compile a translation unit and it does not do its work while the build program
+runs. It consumes **link outputs** through a `role = "artifact"` action, reached
+with `mcpp pack --format <name>` (mcpp 2026.9.11.1+). The prefix matters because
+the taxonomy is load-bearing -- a consumer reading `rules-wix` would expect a
+compiler it does not drive and a translation unit, and there is neither.
+
+A `deps-*` member compiles none of the project's translation units and does not
+do its work while the build program runs: the installation is a `prepare`
+action (mcpp's SPEC-007, docs/specs/build-plugins.md), which fills a declared
+output directory and which the package's compile and link edges wait for, and
+whose command is the installer itself -- `vcpkg`, or `cmake -P` over a script
+the member writes -- so the package builds no program for it. The build
+program refers to the prefix by name -- include directory, libraries by full
+path, runtime search directory -- and never by what is in it, so a plan made
+before the installation is the plan made after it.
+
+The `mcpp.` prefix is reserved for this package: mcpp warns when a module under
+it is declared by a package outside the `mcpp` namespace. `mcpp.build.*` is the
+engine's own module family and is not used here.
+
+## Each rule brings its own environment
+
+A project names the rule and nothing else:
+
+```toml
+[build-dependencies.mcpp]
+plugins = { version = "0.8.0", features = ["rules-cuda"], host-module = true }
+```
+
+The payloads each rule drives are declared **here**, under the feature that
+selects the rule and the accelerator it serves:
+
+```toml
+[target.'cfg(accelerator = "cuda")'.feature-xlings.rules-cuda]
+"xim:cuda-nvcc"   = "12.9.86"
+"xim:cuda-cudart" = "12.9.79"
+```
+
+Two gates, and both must open before a byte is downloaded. The feature says
+whether the rule is wanted; the selector says whether this build compiles for
+the device. A CPU-only build opens neither.
+
+**The shape of each default is a judgement about coupling.** An exact version
+where the payload is coupled to something the rule cannot see -- a CUDA runtime
+must not be newer than the driver it will meet, so the 12.9 line is offered and
+a project with newer machines names 13.x itself. A floor (`>=`) where no such
+coupling exists: a shader compiler, a SYCL compiler, a CANN toolkit.
+
+mcpp reads the difference. A bare version is a **choice**, so a project pinning
+a different one wins and the override is reported; a `>=` is a **requirement**,
+so a project pinning below it is refused naming both sides. Either way one
+version is installed. To override:
+
+```toml
+[target.'cfg(accelerator = "cuda")'.xlings.workspace]
+"xim:cuda-nvcc" = "13.3.33"
+```
+
+**What is not here:** anything the produced program chooses to run *on*. A
+Vulkan ICD (`xim:mesa-lavapipe`) is a device, and a rule that declared one would
+force a software renderer onto consumers that have a GPU. The runtime adapters
+(`compat:cuda-runtime`, `compat:sycl-runtime`, `compat:vulkan-runtime`) stay in
+the project for that reason and for a second one: this package is reached
+through a `[build-dependencies]` edge, so its own `[dependencies]` deliberately
+do not reach the consumer's target.
+
+## Each rule takes the extensions it claims
+
+`mcpp::device_sources()` is the package's WHOLE device set, not one rule's
+share of it, and every rule in a build program reads the same variable. A
+project with two backends puts a `.cu` and a `.comp` in that one list.
+
+Each rule therefore selects the extensions it claims and leaves the rest:
+
+| feature | claims |
+|---|---|
+| `rules-ascendc` | `.asc`, `.cce` |
+| `rules-cuda` | `.cu` |
+| `rules-hip` | `.hip` |
+| `rules-metal` | `.metal` |
+| `rules-qt` | `.ui`, `.qrc`, `.ts`; a header is found by what it declares, since `.h` is already C++ |
+| `rules-slang` | `.slang` |
+| `rules-swift` | `.swift` |
+| `rules-sycl` | `.sycl` |
+| `rules-spirv` | `.comp .vert .frag .geom .tesc .tese .mesh .task .rgen .rint .rahit .rchit .rmiss .rcall`, and `.glsl` / `.hlsl` so that a stage-less name is refused by name rather than by absence |
+
+A rule whose backend this build does not name returns immediately, so a build
+program may call every rule it imports unconditionally and `--no-accel`
+compiles nothing.
+
+A device source that NO rule claims is not silently dropped: mcpp refuses a
+device source that reached no action, naming the file. That is the engine's
+half of this rule and it needs 2026.9.6.5.
+
+The floor is the mcpp release whose engine carries what the member relies on.
+From 0.4.0 every rule shares one: **2026.9.8.1**, the release in which a
+package's host modules are ordered by their IMPORT GRAPH rather than by their
+paths. This package needs that: `src/declare.cppm` is imported by every member,
+and `rules/` sorts before `src/`, so before that release the members were
+compiled first and failed with "failed to read compiled module".
+
+**The floor could have been avoided, and was not.** `src/declare.cppm` sorts
+after `rules/`, which is exactly why it needs the ordering fix -- and naming it
+`aa_declare.cppm` at the package root would make the old PATH order happen to be
+correct, so 0.4.0 would run on 2026.9.7.1 with no floor move at all. That is
+declined on purpose: it encodes a load-bearing constraint in a filename with
+nothing enforcing it, which is the fragility the engine fix removes. A file
+renamed for a reason nobody can see is a defect waiting for the rename that
+looks harmless.
+
+0.5.0, 0.5.1 and 0.5.2 do not move it. Naming an island's entry points is a
+change to what this package generates, not to what it asks the engine for.
+
+0.7.1 does not move it either, and records a compiler rather than an engine:
+under MSVC 14.52 (36629 and 36725, measured on xrgui's CI) a module that has
+instantiated `std::filesystem::path`'s iterator poisons every importer that
+touches `path` again -- `filesystem(1572): error C2801: '_Path_iterator<...>::operator =='
+must be a non-static member`. Nothing in this package instantiates that
+iterator now: the lib root reads paths apart as strings
+(`mcpp::plugins::names::components`), and the members' relative-path
+arithmetic is `mcpp::plugins::names::relative_to`.
+
+The previous shared floor was 2026.9.7.1, the release that reads
+`device_extensions` and `rule_module`, reports `[language] modules` and the
+package's own name to a build program, writes the build program a declared rule
+set describes, and gives `mcpp::action` its `depfile` field. A client below it
+does not get a degraded surface; it gets a build in which the rules never route
+-- the file falls through to the ordinary source scan and mcpp says it has no
+role for the extension.
+
+The previous shared floor was 2026.9.6.6, the release in which a payload a
+DEPENDENCY declared is both installed and answerable. Before it a rule could
+declare `>=8.5.0`, have it installed, and still be told by `xpkg_dir` that
+nothing was there -- which is why each rule's list used to be repeated in every
+project that used it. The earlier per-member floors are still the floors of the
+rules themselves (`rules-spirv` needs the shader extensions in the device-source
+table, 2026.9.5.3; `tools-embed` needs the fast path to compare a declared file
+input, 2026.9.5.4; `rules-sycl` needs `.sycl` in that table, 2026.9.6.1), and
+they are all below the shared one.
+
+`rules-slang` is the member that does NOT appear in that list, and its absence
+is the point: `.slang` is in no engine table at any version. The feature
+declares the extension and the module that compiles it, so the release it needs
+is the one that reads those two keys rather than the one that would have carried
+its extension.
+
+0.10.0 moves the collection's floor to **2026.9.14.2**, and the reason is two
+members rather than the rules: `dist-apk` and `dist-apple` read the native
+closure the engine stages and names in the stage manifest's `needs` lines,
+`dist-apple`'s framework rpath needs the engine to leave an `@executable_path`
+rpath as written, and `mcpp run --format app` reaches the runner named after the
+format only from that release. `rules-metal` itself needs nothing past
+2026.9.8.1. An older engine is not left to fail silently: `dist-apk` refuses a
+stage without `needs` lines, naming the release.
+
+The index descriptor states the highest floor among the members, so it is the
+floor of the collection rather than of any one feature; a project on an older
+mcpp is refused at resolution rather than at the first shader.
+
+## What a consumer names
+
+A member that embeds a payload -- `rules-spirv`, `rules-slang`, `tools-embed` --
+does not leave the consumer to include a generated header. All three hand their
+payloads to one generator, `mcpp::plugins::surface`, so what a consumer writes
+is the same whichever produced them:
+
+```cpp
+import myapp.shaders;
+
+const auto s = myapp::shaders::blur_comp();
+VkShaderModuleCreateInfo ci{ .codeSize = s.size_bytes, .pCode = s.code };
+```
+
+### From a file name to a call
+
+Every name a consumer writes is derived, and derived one way, so nothing has to
+be looked up:
+
+```
+base directory   shaders/                  derived: the shallowest directory
+                                           every payload shares
+file             shaders/post/tone.frag
+                         └── the path below the base
+module           myapp.shaders             package name + group
+namespace        myapp::shaders::post      the module name segment by segment,
+                                           then the directory's segments
+identifier       tone_frag                 stem + stage, non-identifier
+                                           characters replaced by `_`
+call             myapp::shaders::post::tone_frag()
+```
+
+`myapp` comes from the package unless the project sets `options::module_name`;
+the base directory is derived unless it sets `options::base_dir`.
+
+Three invariants, and each exists because its absence was a defect:
+
+- **The module name and the namespace are the same identifier path**, `.` for
+  `::`. A reader never has to learn which namespace a module opens.
+- **The directory reaches the generated file's path and the linker symbol, not
+  only the namespace.** Two shaders sharing a stem in different directories
+  produced byte-identical generated headers, and GCC's `#pragma once` treats two
+  files with the same size and content as the same file -- so the second include
+  did nothing and both accessors returned the first array, while the program
+  printed the right magic number twice.
+- **The stage is always part of the identifier**, so `blur.comp` and `blur.frag`
+  do not collide. Uniformly rather than only when needed: conditional naming is
+  worse than verbose naming.
+
+
+
+**The interface is a function, and it names no standard-library type.** A
+variable cannot keep one shape across the ways bytes can be stored, because
+`constexpr` and `extern` are mutually exclusive. A std type in the interface is
+worse than it looks: measured with GCC 16.1 on a 1 MB payload, an interface
+returning `std::span` produced a 1 313 968-byte BMI against 1 808 bytes for the
+std-free equivalent, and that cost is fixed rather than proportional to the
+payload -- it is `<span>`'s templates, present whether the payload is 16 KB or
+16 MB. A consumer that wants a `std::span` constructs one from the two members.
+
+**Where the bytes live is a second, independent choice.** The surface decides how
+a consumer names a payload; `storage` decides where it sits. The declarations are
+identical under all three, so a project changes this and no consumer changes.
+
+| storage | the payload is | reach for it when |
+|---|---|---|
+| `header` (default) | a C array in generated source, compiled in | almost always |
+| `object` | a section, through `.incbin` in a generated `.S` | total payload is large |
+| `sidecar` | a file beside the artifact, read at run time | hot reload, or a payload too large to link |
+
+**Every payload a compile reads is in the build graph.** Two mechanisms carry
+that, and which one applies is decided by WHEN the thing is known.
+
+A shader's `#include` is discovered by the compiler while it runs, so it arrives
+afterwards, in a depfile. `mcpp::action::depfile` carries it and all six rules
+pass one -- each spelling measured against the tool rather than read from its
+help text.
+
+An `.incbin` is discovered by nobody. The assembler opens the file at assembly
+time; the generated `.S`'s own text does not change when the payload does; the
+object is assembled once. Measured on 0.3.0, in a sandbox against the published
+packages: editing a shader left the program printing the previous payload's byte
+count, with a green build.
+
+Asking the assembler does not fix it, and that was measured rather than assumed.
+The compiler driver's `-MD` is a preprocessor channel that never sees `.incbin`;
+GNU as names it in its own `--MD`; clang's integrated assembler has no
+dependency output of any kind. Tracking it that way would work under GCC and
+fail silently under Clang -- worse than failing under both.
+
+**So under `object` storage the generation is an ACTION and the payloads are its
+declared inputs.** That is the one graph primitive the engine has, used for what
+it is: a payload changes, the action reruns, its outputs count as new, and the
+edge that assembles them reruns. The command is `mcpp-embed`, built from this
+package through `tools = ["mcpp-embed"]` -- not published separately, because
+docs/05 section 2.14 states what that costs: "the tool's version IS the
+dependency's version, so a `protoc` that does not match its runtime is not
+expressible."
+
+`header` and `sidecar` need none of it, and that was checked rather than
+assumed. Under `header` the bytes reach the artifact through generated data
+headers the payload's own compiler already writes as action outputs; under
+`sidecar` they are never compiled at all. So the default path builds no tool,
+and a consumer that never opts into object storage writes nothing extra.
+
+**Which one is a measurement, not a preference.** With GCC 16.1 on 100 payloads
+of 16 KB each -- the size of an ordinary compute shader:
+
+```
+header route   compile 0.64s + link 0.44s                = 1.10s
+object route   convert 1.28s + compile 0.44s + link 0.46s = 2.17s
+```
+
+The header route is faster, because at that size neither route has a measurable
+marginal cost and the total is decided by how many processes start; one compiler
+invocation absorbs many headers. The crossover is the TOTAL embedded byte count
+rather than the payload count: below about 1 MB the header route wins, and above
+about 4 MB the compiler's slightly superlinear curve loses by an order of
+magnitude (2.31s against 0.116s). Source expansion is a constant 2.75x.
+
+**`object` needs a GAS assembler.** Every gcc and clang toolchain has one on all
+three platforms; MSVC does not, and mcpp refuses `.S` under it, so the emitter
+falls back to `header` there and says so once. The surface does not change, so a
+consumer compiled either way is the same source.
+
+**`sidecar` states its cost rather than hiding it.** The accessor opens a path
+relative to the working directory, so the program finds its payloads when run
+from the package root and does not when run from elsewhere -- which is why it is
+not the default, and why `mcpp pack` of such a program has something further to
+collect. `tests/spirv-sidecar` and `tests/slang-sidecar` assert both halves: found
+from the root, and reported missing from `/tmp`.
+
+**The default follows the project.** `[language] modules = true` gives the
+module surface, `false` gives a header with the same declarations. mcpp reports
+the setting as `MCPP_LANGUAGE_MODULES`; an engine that does not report it leaves
+the header surface in place, so an older engine keeps the behaviour every
+consumer of this package had before the surface existed.
+
+**The generator is not shader-specific, and three members already share it.**
+`mcpp::plugins::surface` knows about a run of bytes, a name, where it lives and
+how it is reached; it does not know what SPIR-V is. `rules-spirv`, `rules-slang`
+and `tools-embed` all call it, which is what keeps their generated declarations
+from drifting.
+
+It lives in this package's lib root, so a rule package outside this collection
+reaches it by depending on `mcpp:plugins` and activating no feature -- the lib
+root alone, which is one small module. That works and is the intended path;
+whether the generator should become a package of its own is an open question and
+not one this version answers.
+
+
+**One copy of the bytes.** A generated data header declares a `static` array, so
+before this every translation unit that included one carried its own copy.
+Exactly one translation unit -- the generated implementation -- includes them
+now, and every consumer reaches the same array through the accessor.
+
+## How the engine sees this package
+
+mcpp compiles every module interface unit among a host-module package's
+resolved sources as a host module of its own, the lib root first (2026.9.5.3+).
+`[features.<f>] sources` is what puts a member into that set, so the module set
+a consumer can import is exactly its feature set. A member is compiled alone,
+in the same command as the consumer's `build.mcpp`, and may import `std`,
+`mcpp` and `mcpp.plugins`.
+
+## What a rule may drive, and what it may not
+
+A member drives a compiler the ecosystem resolved and no other. `xim:dpcpp` is
+`mcpp.rules.sycl`'s compiler; `xim:gcc` is the C++ standard library it compiles
+against; `xim:cuda-nvcc` is the back end it emits for. None of the three is a
+default: each is read from `mcpp::xpkg_dir`, and a member that cannot find one
+refuses and prints the `[xlings.workspace]` line that would add it.
+
+Two of those three were added because a build that already worked was found to
+be reading the host. Without `--gcc-install-dir` the SYCL unit compiled against
+`/usr/include/c++`; without `--cuda-path` clang found the host's CUDA
+installation. Neither said anything: both are visible only in the compiler's
+own include search list, and only on a machine that has those directories.
+
+## Adding a member: what the engine owns and what the member owns
+
+1. One file, `rules/<x>.cppm`, `tools/<x>.cppm`, `dist/<x>.cppm` or `deps/<x>.cppm`, declaring
+   its module name.
+   The engine owns the graph — the accelerator axis, the constrained globs,
+   the action edges, the fingerprint — and the member owns the spelling: which
+   tool, which flags, what is generated. A member does not read `/usr`; a tool
+   comes from `mcpp::toolchain_dir()`, `mcpp::xpkg_dir()` or an explicit option,
+   and a missing one is refused naming the `[xlings.workspace]` entry to add.
+2. A feature in `mcpp.toml` adding that one source.
+3. A consumer under `tests/` that builds through it and asserts on the
+   artefact, and a row in the README's members table with the mcpp floor.
+4. A version bump: mcpp identifies an installed package by `(name, version)`,
+   so a changed payload under an unchanged version is not reinstalled.
diff --git a/docs/plugin-development.md b/docs/plugin-development.md
new file mode 100644
index 0000000..5fce06f
--- /dev/null
+++ b/docs/plugin-development.md
@@ -0,0 +1,42 @@
+# Plugin development
+
+mcpp is a general build engine with a framework for build plugins. Plugins come from this package, from third parties, or from the project itself, and `build.mcpp` is where a project uses them: it imports a plugin's module, configures it, and calls it. This page states the conventions every plugin in this package follows. A third-party plugin or a project's own plugin is held to the same conventions, and mcpp's SPEC-007 (docs/specs/build-plugins.md) is the engine contract they rest on.
+
+## 1. Division of responsibility
+
+| layer | owns | does not own |
+|---|---|---|
+| mcpp | the build graph, actions and their stamps, the runtime closure check, deployment, packing, and the toolchain facts (`mcpp::compiler()`, `mcpp::cxx_stdlib()`, ...) | any particular library, SDK or tool |
+| plugin | a mechanism: one kind of input turned into actions with declared inputs and outputs, and a prefix or SDK mapped into the build | versions; the runtime closure of what it maps; workarounds for engine gaps |
+| xlings package | a binary payload and its runtime closure on every platform it serves | build logic |
+| project | policy: which libraries and SDKs, at which versions, where, with which options | — |
+
+## 2. Rules
+
+1. **A plugin provides a mechanism, not a policy.** A plugin contains no fixed version, path or library list that a project could reasonably want to choose.
+2. **A feature states a mechanism and the tools it runs.** `[feature-xlings.<feature>]` may declare a tool the plugin's actions execute (`xim:vcpkg`, `xim:cmake`), with a floor when the tool is a floor. It never declares a library or an SDK that is linked into the program. The project declares those in its own `[xlings]` table.
+3. **Configuration is `build.mcpp` first.** Each setting is taken from the first of three levels that gives it:
+   1. the plugin's `options`, set in `build.mcpp`, where the value may be computed;
+   2. an environment variable, only under a name the ecosystem already uses (`QT_ROOT_DIR`), and read with `rerun_if_env_changed`;
+   3. a payload the project declares.
+
+   The level that decided is recorded with `mcpp::fact`. What a plugin returns (a prefix, an SDK root, the deployed files) is its extension point: `build.mcpp` may declare its own actions over it.
+4. **The runtime closure belongs to the package that ships the binaries.** A payload whose libraries load others carries or declares them on every platform, so a packed program starts on a machine with only its operating system. A plugin names the payload's library directories as runtime search directories and nothing beyond them.
+5. **Internals are not part of the contract.** The contract is the set of feature names, `options` fields, returned types and documented environment variables. A consumer's manifest names no program the plugin uses internally. An action's command is the tool itself (`vcpkg`, or `cmake -P` over a script the plugin writes), never a helper program built from the plugin's package.
+6. **Work is an action.** Installation, extraction and generation are actions with declared inputs and outputs (SPEC-007 R1.1, R3). A build program plans, and `mcpp emit build-database` never installs.
+7. **Absence is a warning.** A missing tool or SDK is a `mcpp::warning`, and the plan states every path it can (R1.2). A plan never depends on what an action produced (R1.3).
+8. **Engine gaps are reported, not patched.** A capability the engine lacks is filed as an mcpp issue. A workaround that already exists is recorded in the plugin's documentation with the issue number and is removed when the engine provides the capability.
+9. **Every behaviour has a criterion.** Each documented behaviour has a CI check, run on every platform the plugin claims.
+10. **Documentation is concise.** A plugin's page opens with one summary paragraph, followed by use, options and behaviour, in plain declarative sentences. The README is an index.
+
+## 3. A new plugin
+
+A plugin in this package consists of:
+- a module file under `rules/`, `tools/`, `dist/` or `deps/`;
+- a feature in `mcpp.toml`;
+- a fixture under `tests/` that CI builds and asserts on;
+- a row in the README's member table with its mcpp floor;
+- a page under `docs/`;
+- a version bump.
+
+A project's own plugin is a module in the project (a path dependency with `host-module = true`) and follows §2 in the same way.
diff --git a/docs/rules-qt.md b/docs/rules-qt.md
new file mode 100644
index 0000000..2e1e487
--- /dev/null
+++ b/docs/rules-qt.md
@@ -0,0 +1,84 @@
+# `rules-qt`
+
+`mcpp.rules.qt` runs Qt's code generators (`moc`, `uic`, `rcc`) and Linguist tools (`lupdate`, `lrelease`, `lconvert`) as build actions, links the Qt modules and places their runtime beside the program. The rule declares no SDK and pins no version: the project names the Qt it builds with, in `build.mcpp` or in its own `[xlings]` table. Module `mcpp.rules.qt`; engine floor 2026.9.26.2 (mcpp#702); from 0.13.0.
+
+## Use
+
+```toml
+[build-dependencies.mcpp]
+plugins = { version = "0.15.0", features = ["rules-qt"], host-module = true }
+
+# The SDK and its version are the project's declaration.
+[target.'cfg(any(windows, linux, macos))'.xlings.workspace]
+"xim:qt-base" = "6.11.1.1"
+
+[build]
+sources = ["src/*.cpp", "res/*.qrc", "i18n/*.ts", "ui/*.ui"]
+```
+
+```cpp
+// build.mcpp
+import mcpp.rules.qt;
+
+int main() {
+    mcpp::rules::qt::options o;
+    o.modules        = { "Core", "Gui", "Widgets", "Network" };
+    o.deploy_plugins = { "platforms", "styles", "imageformats" };
+    o.i18n.tr_function_alias = { "translate+=appTr" };
+    return mcpp::rules::qt::compile(o) ? 0 : 1;
+}
+```
+
+## The SDK
+
+The first of three levels that names an SDK decides, and the rule records which as the fact `rules-qt.sdk` (0.15.0):
+
+| level | how | scope |
+|---|---|---|
+| 1. build program | `options::root`, `options::extra_roots` | any value `build.mcpp` computes |
+| 2. environment | `QT_ROOT_DIR`, the variable install-qt-action and aqtinstall set; a change re-plans the build | one machine |
+| 3. declared payload | `xim:qt`, else `xim:qt-base`, with `xim:qt-addons` as a second prefix, at the version the project's `[xlings]` table states | one project, provisioned by `mcpp build` |
+
+| payload | contents |
+|---|---|
+| `xim:qt-base` | qtbase, qttools with the QtQml library `lupdate` loads, and qttranslations; about a third of `xim:qt`'s download |
+| `xim:qt` | qtbase, qtsvg, qtdeclarative, qttools, qttranslations |
+| `xim:qt-addons` | the additional libraries, beside `xim:qt` |
+
+The payloads that carry their runtime closure are version `6.11.1.1` (the Qt 6.11.1 archives, laid out anew); a machine that holds `6.11.1` keeps the earlier layout. 0.15.0 removed the features `rules-qt-xim`, `rules-qt-xim-base` and `rules-qt-xim-addons`, which declared a payload at a fixed version: a feature states a mechanism, and the SDK a program links is the project's choice. A project that named one declares the payload instead, as above.
+
+## Options
+
+| option | meaning |
+|---|---|
+| `modules` | `Core`, `QtCore` and `Qt6Core` name one module; each is linked by full path and defines `QT_<MODULE>_LIB` |
+| `private_modules` | modules whose private headers are included |
+| `moc`, `moc_headers` | `moc_scan::project_headers` (default) scans the package's headers by content; `moc_scan::listed` takes `moc_headers` only |
+| `forms`, `resources` | `.ui` and `.qrc` files beside those in `[build] sources` |
+| `i18n` | `.ts` files beside those in `[build] sources`; `update_sources` runs `lupdate` as an action whose output is the `.ts` it rewrites; `tr_function_alias`; `deploy_to` (default `translations`); `out_dir` (default `<out dir>/qt/translations`); `qt_languages`: the linked modules' catalogs combined by `lconvert` into `qt_<language>.qm`, the file windeployqt writes |
+| `deploy_plugins` | plugin directories placed beside the program; default `platforms` |
+| `deploy_software_gl` | Windows: `opengl32sw.dll` and `d3dcompiler_47.dll` beside the program |
+| `root`, `extra_roots` | level 1 of the SDK lookup |
+
+`roots()` and `root()` return the SDK the lookup chose, for a program that hands it on (a CMake subproject's `CMAKE_PREFIX_PATH`).
+
+## Behaviour
+
+- `moc` runs for every header under the package root that declares `Q_OBJECT`, `Q_GADGET` or `Q_NAMESPACE`, and for a source that includes its own `<stem>.moc`; `uic` for `.ui`, `rcc` for `.qrc`, `lrelease` for `.ts`. Each is a `role = "source"` action with declared inputs; the outputs are under `<out dir>/qt/`.
+- The SDK's `bin/` (Windows) or `lib/` is a runtime search directory: the program's run path, `mcpp run`'s load path, `mcpp pack`'s closure, and on Windows the Qt DLLs placed beside the program. The plugin directories `deploy_plugins` names are deployed beside the program.
+- Under an MSVC compiler the rule adds `/Zc:__cplusplus` and `/permissive-`; on Linux, `-fPIC`. On macOS the modules are frameworks under `lib/`, compiled with `-F<root>/lib` and linked by their binaries' full paths. A resource compiled into a static library is registered with `Q_INIT_RESOURCE(<stem>)`.
+- A missing SDK, module or tool is a warning: the plan states what it can, and the build is where the absence fails.
+
+## Runtime closure
+
+A program packed by `mcpp pack` starts on a machine that has only its operating system:
+
+| platform | Qt loads | provided by |
+|---|---|---|
+| Linux | glib, zstd, zlib, libdbus, fontconfig, freetype, X11, xkbcommon, EGL/GL, the xcb libraries | the `xim:qt` and `xim:qt-base` payloads: they declare these packages with `xim:glibc`, so xlings patches every file of the payload to the ecosystem's loader and a RUNPATH over them (openxlings/xim-pkgindex#884); Widgets programs pass mcpp's runtime closure check and run under that loader |
+| Windows | system DLLs, and the VC++ runtime (`MSVCP140`, `VCRUNTIME140`, `VCRUNTIME140_1`) | the payloads place the redistributable VC++ runtime in `bin/` (windows-x86_64), so it reaches the program's directory with Qt's DLLs |
+| macOS | system frameworks and libc++ | the system |
+
+The rule names none of these libraries (0.15.0; 0.13.0 and 0.14.0 declared glib, zstd and zlib on Linux and served QtCore only). A Qt from elsewhere carries what its installer arranged. On Linux, QtNetwork additionally loads `libgssapi_krb5` and `libbrotlidec`, which the ecosystem does not publish yet.
+
+Qt's official Linux build uses the shared libstdc++, so a Linux program states `[build] cxx_runtime = "toolchain-coupled"` (mcpp's docs/20) and builds with a gcc toolchain; under a libc++ toolchain the rule warns. The statement is project-wide because mcpp reads a `[target.<triple>]` table only when a target is named (mcpp#704).
diff --git a/docs/rules.md b/docs/rules.md
new file mode 100644
index 0000000..de5d6b8
--- /dev/null
+++ b/docs/rules.md
@@ -0,0 +1,51 @@
+# Device and language rules
+
+The rules that compile one kind of translation unit with a compiler mcpp does not drive: GPU and accelerator languages (`rules-ascendc`, `rules-cuda`, `rules-hip`, `rules-sycl`), shader languages (`rules-spirv`, `rules-slang`, `rules-metal`) and Swift (`rules-swift`). Each section states the module, the engine floor, what the rule needs and how it compiles. The environment each rule brings and the extensions it claims are in [engine-and-rules.md](engine-and-rules.md).
+
+## `rules-ascendc`
+
+Module `mcpp.rules.ascendc`; engine floor: 2026.9.6.6.
+
+**Needs and behaviour.** `[build] accel = "ascend8.5+{dav-c220}"`, a constrained glob for `*.asc`. Compiles with BiSheng in MIXED mode, so the object carries the device binary and a host-callable launcher and joins the ordinary link -- no registration file and no device-link step. Its own engine needs are `.asc` in the device-source table and `mcpp::link_flag` for the `-rpath-link` the toolkit's shared libraries require, both 2026.9.6.5
+
+## `rules-cuda`
+
+Module `mcpp.rules.cuda`; engine floor: 2026.9.6.6.
+
+**Needs and behaviour.** `[build] accel = "cuda…"`, a constrained glob for `*.cu`; the clang route with an LLVM toolchain, the nvcc route with a GCC one
+
+## `rules-hip`
+
+Module `mcpp.rules.hip`; engine floor: 2026.9.6.6.
+
+**Needs and behaviour.** `[build] accel = "hip, cuda12.9+{sm_89}"`, a constrained glob for `*.hip`. On the NVIDIA platform HIP is a header layer over the CUDA runtime, so the compiler is the project's own clang and there is no ROCm on the machine
+
+## `rules-metal`
+
+Module `mcpp.rules.metal`; engine floor: 2026.9.8.1.
+
+**Needs and behaviour.** the Metal toolchain of the macOS host's Xcode, located rather than installed: Xcode is not redistributable, so no payload is declared. `.metal` sources the project names on a macOS or iOS row become one `xcrun --sdk <sdk> metal` action per shader (`-MMD`, so an edited `#include` recompiles the shaders that include it) and one `xcrun --sdk <sdk> metallib` action per library, placed beside the program with `mcpp::deploy` under `metallib/`, which `dist-apple` maps into the bundle's resources. `compile(shaders)` compiles one source several times with definitions of its own, one library per `shader`; `options::library` links every shader into one library (`default` is the one `newDefaultLibrary` finds). Before planning anything the rule asks `xcrun --sdk <sdk> --show-sdk-path` and `--find metal` / `--find metallib`, and refuses naming the command that answered nothing, because a missing SDK and a missing compiler have different remedies (Xcode 26 installs the Metal toolchain as a separate component). A shader on any other row is refused naming the row. CI compiles the fixture on `macos-15` and checks each library's magic, and that a header edit recompiles only the shaders that include it
+
+## `rules-slang`
+
+Module `mcpp.rules.slang`; engine floor: 2026.9.7.1.
+
+**Needs and behaviour.** `[build] accel = "vulkan1.2"`, a constrained glob for `*.slang`. Slang is a different language from GLSL rather than a second driver for it -- its own module system, generics, and targets beyond SPIR-V -- so it is a rule of its own. `.slang` is **not** in the engine's device-source table: this feature declares `device_extensions = [".slang"]` and `rule_module = "mcpp.rules.slang"`, and the engine routes it from there. That is the criterion for the whole arrangement -- a new device language costs no engine release. Since 0.7.0 it has the same `options::storage` axis as `rules-spirv` (header / object / sidecar), `options::extra_args` for the arguments the rule has no field for, and `options::per_file` for what one shader gets that the others do not -- a project with a `-fvk-use-gl-layout` and one shader needing `-emit-spirv-via-glsl` writes both without leaving one `compile()` call
+
+## `rules-spirv`
+
+Module `mcpp.rules.spirv`; engine floor: 2026.9.6.6.
+
+**Needs and behaviour.** `[build] accel = "vulkan1.2"`, a constrained glob for the shader stages; compiles each shader through a `role = "source"` action and states which of the two compilers produced it
+
+## `rules-swift`
+
+Module `mcpp.rules.swift`; engine floor: 2026.9.8.1.
+
+**Needs and behaviour.** the Swift compiler of the macOS host's Xcode or Command Line Tools, located rather than installed, as `rules-metal` locates its toolchain. From 0.12.0. The `.swift` sources a project names on a macOS or iOS row compile as one module named after the package: one whole-module `xcrun --sdk <sdk> swiftc -wmo -emit-object -target <triple>` action whose role is `object`, so the object joins every image of the package, and one `swiftc -typecheck -emit-objc-header-path` action whose role is `source`, whose directory `mcpp::include_dir` adds, so the package's C and C++ sources include `<module>-Swift.h`. `options::bridging_header` names a C header Swift sees without an import. The link receives the toolchain's `usr/lib/swift/<platform>` and the SDK's `usr/lib/swift` as search directories and `/usr/lib/swift` as a run path through `mcpp::link_flag`. Before planning anything the rule asks `xcrun --sdk <sdk> --show-sdk-path` and `--find swiftc`, and refuses naming the command that answered nothing; a Swift source on any other row is refused naming the row. Not supported: a Swift `import` of another package's module, and another package's C++ including this package's generated header, which both need an engine channel that publishes a package's interface directory to its dependents; and SwiftPM dependencies. CI builds `tests/swift-consumer` on `macos-15` -- a C++ program calling a `@_cdecl` Swift function that calls back into C -- and runs it
+
+## `rules-sycl`
+
+Module `mcpp.rules.sycl`; engine floor: 2026.9.6.6.
+
+**Needs and behaviour.** `[build] accel = "sycl"` or `"sycl, cuda12.9+{sm_89}"`, a constrained glob for `*.sycl`, and `compat:sycl-runtime` so the artifact can reach `libsycl.so.9` at run time. Its own engine need is `.sycl` in the device-source table, 2026.9.6.1
diff --git a/docs/tools-embed.md b/docs/tools-embed.md
new file mode 100644
index 0000000..cb08b3b
--- /dev/null
+++ b/docs/tools-embed.md
@@ -0,0 +1,77 @@
+# `tools-embed`
+
+`mcpp.tools.embed` reads a file while the build program runs and writes a header that carries it as an array, through four entry points; the declarations a consumer names are generated by `mcpp::plugins::surface`.
+
+## `tools-embed`
+
+Module `mcpp.tools.embed`; engine floor: 2026.9.5.4.
+
+**Needs and behaviour.** nothing beyond mcpp: it reads a file and writes a header while the build program runs. The floor is the release whose fast path compares a declared file input, without which an edit to the data does not reach the binary
+
+## `tools-embed`'s four entry points
+
+| entry point | inputs | outputs | shape |
+|---|---|---|---|
+| `file()` | one | one header | one array, one `_size`, included by name |
+| `files()` | N | N headers | one `file()` call per input; `options::identifier` is refused, because it names one symbol and there are several |
+| `group()` | N | N headers + one generated interface | the same N headers, handed to `mcpp::plugins::surface` so a consumer writes one `import` and names no generated file -- see [What a consumer names](engine-and-rules.md#what-a-consumer-names) |
+| `table()` | N | one header | one array of rows, each carrying its input's key beside its bytes; the consumer iterates or looks a row up by key |
+
+`table()` is for a set the consumer wants to walk rather than name member by
+member, where `files()`'s one accessor per input and `group()`'s one function
+per input are both the wrong shape. The motivating case is a shader set:
+
+```cpp
+mcpp::tools::embed::table_options opt;
+opt.name_space = "myapp";
+opt.identifier = "shaders";
+opt.row_type   = "shader_entry";
+mcpp::tools::embed::table({ "shaders/Standard.vert", "shaders/Standard.frag" }, opt);
+```
+
+which produces, in one header, a struct and an array of it:
+
+```cpp
+struct shader_entry { const char* key; const unsigned char* data; std::size_t size; };
+inline constexpr shader_entry shaders[] = {
+    { "Standard.vert", /* ... */, /* ... */ },
+    { "Standard.frag", /* ... */, /* ... */ },
+};
+```
+
+**The row struct is generated beside the array it describes, for the reason
+0.2.6 fixed for `mcpp.rules.spirv`'s header:** a generated header has to be
+includable on its own with nothing else. A consumer never declares the row
+type by hand, so it cannot declare one that has drifted from what the array
+actually holds.
+
+**Each row's bytes are a numeric array, never a raw string literal.** A raw
+string literal delimits on a fixed marker (`)"` closes `R"(...)"`), and no byte
+sequence in an arbitrary payload is excluded strongly enough to promise it
+never contains that marker: shader source can carry it by accident, and a
+binary payload can carry it by construction. The motivating case for this
+entry point built its shader table by concatenating file contents into one
+string in a build script -- exactly this bug: a shader containing that
+four-character sequence truncates the string at that point, and every shader
+concatenated after it goes missing, with nothing but an unrelated compiler
+error to show for it.
+
+**A row's key is a choice, not a convention.** `table_options::key` selects
+between the file name with its extension (`Standard.vert`, the default,
+because a bare stem would collide with `Standard.frag`), the bare stem, and the
+path relative to the manifest directory -- for a nested input set where two
+directories hold a file of the same name, which the file name alone cannot
+tell apart. Two inputs that derive one key are refused, naming both: the same
+shape `mcpp.rules.spirv` refuses two shaders sharing one output name, because
+the alternative is a table that silently keeps the last row sharing a key and
+drops the rest, and a build that did that would still link and run.
+
+**`table_options` is its own type rather than a second meaning for `options`'s
+fields.** `options::identifier` names one symbol, so `files()` refuses a caller
+who sets it for several inputs rather than silently applying it to the first.
+A table writes exactly one array regardless of how many inputs feed it, so
+there is always exactly one name to give: `table_options::identifier` (default
+`embedded_table`) and `table_options::row_type` (default `embedded_file`) name
+the array and the struct. `out_dir`, `name_space`, `elem` and `width` mean what
+they mean in `options`, `element::word32`'s "not a multiple of 4" refusal
+included -- checked per input, since a table has several.
diff --git a/docs/tools-island.md b/docs/tools-island.md
new file mode 100644
index 0000000..41ee485
--- /dev/null
+++ b/docs/tools-island.md
@@ -0,0 +1,238 @@
+# `tools-island`
+
+`mcpp.tools.island` reads the marked entry points of a code island's own source and writes the `extern "C"` boundary header the island's compiler reads and the module the C++ side imports.
+
+## `tools-island`
+
+Module `mcpp.tools.island`; engine floor: 2026.9.7.1.
+
+**Needs and behaviour.** nothing beyond mcpp: it reads marked entry points out of an island's own source and writes the `extern "C"` boundary header its compiler reads and the module the C++ side imports. Not a device rule -- it claims no extension, and a project calls it from its own `build.mcpp`
+
+## `tools-island`: an island's boundary
+
+`mcpp::plugins::surface` generates the whole interface for a **data** payload,
+because an address and a size are all there is to decide.
+`mcpp.tools.island` generates what is mechanical about a **code** island -- and
+only that. It is a member like `tools-embed` rather than part of the lib root:
+nothing in this collection uses it, a project does.
+
+The entry points are marked where they are defined, and the signature exists
+once:
+
+```c
+// src/kernels/saxpy.cu -- no include: the generated header arrives through the
+// compiler's forced-include flag, which is what defines the marker as nothing.
+
+MCPP_EXPORT_C
+int saxpy_device(float a, const float* x, const float* y, float* out, unsigned n) { ... }
+```
+
+```cpp
+// build.mcpp
+mcpp::tools::island::options opt;
+opt.module_name  = "myapp.kernels";
+opt.out_dir      = std::string(mcpp::out_dir()) + "/island";
+opt.roots        = { root + "/src/backends/cuda", root + "/src/backends/cpu" };
+opt.layout_root  = root + "/src/backends/cuda";   // default: roots.front()
+opt.strip_prefix = "myapp_";                       // optional short spelling
+
+const auto entries = mcpp::tools::island::scan(opt);
+const auto out     = mcpp::tools::island::emit(*entries, opt);
+mcpp::include_dir(out->include_dir.c_str());
+mcpp::generated(out->interface_file.c_str());
+```
+
+Two files come out of that one marked declaration: the `extern "C"` header the
+device translation unit includes, guards and `__cplusplus` dance included, and
+the module the C++ side imports.
+
+**The names arrive in the module's own namespace (0.5.0).** `docs/42` states one
+rule for both lanes -- the module name and the namespace are one identifier path
+-- and this generator did not follow it: every entry point was at global scope,
+so `import myapp.kernels` bought a file name and nothing else. It follows it
+now, and a directory below the layout root extends the path exactly as a payload
+tree's does:
+
+```
+src/backends/cuda/image/blur.cu   myapp_blur   ->  myapp::kernels::image::myapp_blur
+src/backends/cuda/saxpy.cu        myapp_saxpy  ->  myapp::kernels::myapp_saxpy
+```
+
+**A root is a tree, and one of them supplies the shape.** Overlapping roots are
+refused: a file reachable from two of them has two namespace paths, and which
+one it got would depend on the order of the list. `options::roots` names
+the directories implementations live under; `options::layout_root` names the one
+whose directory structure decides where entry points live, and defaults to the
+first. Every other root only has to define the names, so a fallback tree may be
+one flat file or six directories and may be reorganised without renaming
+anything a consumer wrote. This is a naming role and not a rank: every root
+compiles, links, and is equally a backend.
+
+A file list would not do: its common ancestor moves when a file is added, and a
+consumer's qualified name would move with it. Roots also must not come from
+`mcpp::device_sources()`, which `accel` narrows to nothing under `--no-accel` --
+the device tree would vanish and the namespace would come from the fallback.
+
+`scan` registers every file it reads as a declared input and each root as a
+glob, so **adding** a file re-runs the program. Declared inputs are hashed
+contents, and a new file changes none of them.
+
+**A short spelling, when the prefix repeats the namespace.** An island's symbol
+is global to the whole program, so an entry point carries a package prefix
+whether or not it sits in a namespace. `options::strip_prefix` emits a second
+spelling beside the first:
+
+```cpp
+export namespace myapp::kernels::image {
+using ::myapp_blur;                          // the authored name; this is the symbol
+inline constexpr auto blur = myapp_blur;     // the short name, for the call site
+}
+```
+
+Both are exported and the authored one stays canonical -- it is what `nm`, a
+link error, a profiler and `dlsym` show. A `constexpr` function pointer costs
+the artifact nothing: the pair is one symbol. A short name that collides with
+another entry point's name in the same namespace is refused, naming both.
+
+The C++ side is usually a **seam module** of the project rather than a consumer
+directly: `app.cppm` imports the generated module and turns pointers and a count
+back into spans, and it is the one place a backend can be exchanged. That means
+one module interface of the project imports a module interface written into the
+build directory during the same build; the ordering comes from the scan seeing
+the import, and nothing has to be declared for it.
+
+**Three layers, and each overrides the one above.** `scan` reads the marked
+declarations out of the roots, which puts the signature beside the definition;
+`island::declared` builds an entry from a declaration the scan cannot see, for
+`emit` to take directly; and a project that wants neither writes its own header
+and its own module wrapper. The default is the one that keeps the signature in
+one place.
+
+**The marker selects.** An island has internal functions, and a generator that
+exported whatever the file contained would make the boundary an accident of the
+file's contents. `MCPP_EXPORT_C` names the mechanism rather than the domain --
+what is marked is exported across a generated boundary with C linkage -- and
+deliberately does not end in `_API`, a suffix that conventionally expands to a
+visibility attribute where this expands to nothing. It is configurable through
+`options::marker`.
+
+**The scan is not a C parser.** From the marker it copies verbatim to the
+parenthesis closing the parameter list, matching nesting, so a signature that
+wraps across lines or carries a macro travels through unexamined.
+
+**The island writes no `#include` either.** `force_include_flags` returns the
+flags that make the compiler read the generated header before the island's first
+line -- `-include <path>` for gcc and clang, `/FI<path>` for MSVC -- so a project
+using this generator has no header in its source tree and no line naming one.
+
+**Those flags go to the RULE, not to the project.** The island is compiled by a
+driver mcpp did not invoke, which inherits nothing from `mcpp::cflag` or
+`mcpp::cxxflag`, so each device rule takes them on its own command line:
+
+```cpp
+mcpp::rules::cuda::options opt;
+opt.flags = mcpp::tools::island::force_include_flags(out->header_file,
+                                                     mcpp::compiler());
+```
+
+`cuda`, `hip`, `sycl` and `ascendc` all carry `options::flags`, appended last and
+passed through unexamined. The project-wide channels are not merely too wide for
+this, they are wrong for it: `cxxflag` forces the header into every C++
+translation unit, including the seam `.cppm`, and a module interface unit must
+begin with `export module` -- declarations ahead of that line are ill-formed.
+
+A HOST fallback compiled by mcpp itself has no such command line, so it writes
+one ordinary `#include` of the generated header. The asymmetry is between "a
+compiler this project can flag on its own" and "every C++ translation unit",
+not between the two halves' importance.
+
+An `#include` of the generated header would name a file its author never opens,
+and it buys no self-containment: that translation unit could not be compiled
+outside mcpp with or without the line, because the file it names does not exist
+until mcpp writes it.
+
+**The check that include used to do is still there.** The compiler sees the
+declarations, so a definition whose signature drifted from its declaration fails
+where it was written rather than at the link:
+
+```
+src/kernels/saxpy.c:22:5: error: conflicting types for 'scale_device'
+```
+
+**Two checks, and they answer different questions.**
+
+One name declared twice in ONE root is a collision. C language linkage does not
+mangle, so those are one symbol, and a namespace that appeared to separate them
+would promise an isolation the linker does not provide -- measured: two modules
+re-exporting one `extern "C"` name into two namespaces give `&a::f == &b::f`.
+It is refused, naming both files and saying that two implementations of one
+entry point belong in two roots. That refusal is what makes the namespaces
+honest: a name exists in exactly one of them.
+
+One name in SEVERAL roots is one entry point implemented several times, which is
+the ordinary shape of a seam -- a device island and a host fallback, exactly one
+of them in any link. Every root is read unconditionally, because all of them
+exist on disk in either build and which one is compiled is the manifest's
+decision rather than a condition the build program repeats. The declarations
+must then agree verbatim, and two that declare it **differently** are refused,
+naming both files and both signatures:
+
+```
+mcpp.tools.island: two definitions of `island_scale` declare it differently.
+  src/kernels/image/scale.c
+    int island_scale(float a, float* out, unsigned n)
+  src/cpu/ops.c
+    int island_scale(float a, float* out, double n)
+  C language linkage does not mangle, so these never meet at the link:
+  whichever one is in the artifact reads its arguments by its own signature.
+```
+
+Nothing else in the toolchain catches that. The two halves are never in one
+translation unit and never in one link, and C linkage does not mangle, so a
+build with disagreeing halves is clean and the artifact reads its arguments by
+whichever signature it was compiled with. `scan` is the only point at which both
+texts exist at once.
+
+**A root that yields nothing is an error.** A misspelled path or a marker that
+never arrived would otherwise produce a module exporting nothing, and the
+failure would surface as an unresolved name in a consumer three files away.
+
+**The declaration still exists once.** Without this, a project writes it twice --
+in a header, and again wherever the C++ side reaches it. C language linkage does
+not mangle, so two copies that disagree are one symbol: the link is clean and
+each side reads the arguments by its own ABI, with no compile error and no link
+error. That is the copy this removes.
+
+**The module re-exports names, not signatures.** `using ::saxpy_device;` inside
+the module's namespace needs the identifier and nothing else, so the generator
+has no C parser in it and the header stays the only place a signature is
+written. Measured on both
+implementations this package supports: a consumer that imports the module and
+never includes the header calls the entry point and links against an
+implementation built by a different driver, under GCC 16.1 and clang 22.1.8.
+
+**The C++ interface is still yours.** A seam that turns raw pointers into
+`std::optional<std::vector<float>>` is a design decision, and no generator makes
+it well. This removes the boilerplate around the boundary, not the boundary's
+design. `emit_module = false` emits the header alone for a project that keeps a
+hand-written seam that includes rather than imports.
+
+### Why the generators live here and not in mcpp
+
+The engine's `mcpp` module is compiled into the mcpp binary and carries the
+**protocol** -- what a build program can tell mcpp: `action`, `generated`,
+`include_dir`, `fact`, `floor`. A generator is a **library on top of** that
+protocol: it reads declarations, writes files, and hands them back through
+`mcpp::generated`. It extends nothing.
+
+So the line is: the engine's module carries the protocol, and generators are
+libraries. Both of these are opinionated and will change -- what a `payload`
+looks like, how a namespace is derived, which storages exist -- and code inside
+the engine changes only with an engine release, which is the coupling this
+version's `device_extensions` work exists to remove.
+
+A rule package outside this collection reaches them by depending on
+`mcpp:plugins` and activating no feature: the lib root alone, one small module.
+That is a package dependency it chooses, not a coupling the engine imposes. If
+they stabilise, moving them into the engine later is a low-risk step; the reverse
+is not.
diff --git a/mcpp.toml b/mcpp.toml
index 9cc2db3..ebec8de 100644
--- a/mcpp.toml
+++ b/mcpp.toml
@@ -1,7 +1,7 @@
 [package]
 name        = "plugins"
 namespace   = "mcpp"
-version     = "0.14.0"
+version     = "0.15.0"
 description = "Official mcpp build plugins: rule packages under mcpp.rules.*, build-time utilities under mcpp.tools.*, each member selected by a feature"
 license     = "Apache-2.0"
 authors     = ["mcpp-community"]
@@ -145,23 +145,12 @@ implies           = ["surface"]
 rule_module       = "mcpp.rules.qt"
 device_extensions = [".ui", ".qrc", ".ts"]
 
-# WHERE QT COMES FROM IS A FEATURE OF ITS OWN, for the reason `dist-apk-kotlin`
-# gives: provisioning runs before the build program learns what it compiles, so
-# a payload `rules-qt` declared would download an SDK into every project that
-# already has one -- a Qt from vcpkg, from a distribution, from an installer.
-# `rules-qt-xim` is the one that downloads; `rules-qt-xim-addons` adds the
-# additional libraries (Multimedia, Charts, WebSockets, ...) as a second prefix.
-[features.rules-qt-xim]
-implies = ["rules-qt"]
-
-[features.rules-qt-xim-addons]
-implies = ["rules-qt-xim"]
-
-# `xim:qt-base`: qtbase and qttools with the QtQml library qttools' Linguist
-# tools load, without Qt Quick -- about a third of `xim:qt`'s download. For a
-# widgets or console program. 0.14.0.
-[features.rules-qt-xim-base]
-implies = ["rules-qt"]
+# WHERE QT COMES FROM IS THE PROJECT'S CHOICE, not a feature: `rules-qt` finds
+# the SDK from `options::root`, `QT_ROOT_DIR`, or a Qt payload the project
+# declares in its own `[xlings]` table at the version it chooses
+# (docs/rules-qt.md). A feature states a mechanism and the tools that mechanism
+# runs, never a library the program links (docs/plugin-development.md). 0.15.0
+# removed `rules-qt-xim`, `rules-qt-xim-base` and `rules-qt-xim-addons`.
 
 # NOT device rules: these embed or declare things a project already has, so they
 # claim no extension and name no rule module. A consumer calls them from its own
@@ -246,8 +235,9 @@ implies = ["dist-apk"]
 # and it produces inputs of the link rather than something made from it, so it
 # is not a dist member. The installation is a `prepare` ACTION (mcpp's SPEC-007
 # R3.3: it fills a declared output directory, and the package's compile and link
-# edges wait for it) whose command is `mcpp-deps` (below); the consumer asks for
-# that tool on the same edge: `tools = ["mcpp-deps"]`. The prefix reaches the
+# edges wait for it) whose command is the installer itself -- `vcpkg`, or
+# `cmake -P` over a script the member writes -- so a consumer's edge names no
+# tool (0.15.0). The prefix reaches the
 # build by name, and its shared-library directory through
 # `mcpp::runtime_search_dir` -- both from the release that lands mcpp#702.
 #
@@ -446,12 +436,12 @@ implies           = ["surface"]
 [target.'cfg(accelerator = "ascend")'.feature-xlings.rules-ascendc]
 "xim:cann-toolkit" = ">=8.5.0"
 
-# ── The environment `deps-vcpkg`, `deps-cmake` and `rules-qt-xim` need ─────
+# ── The environment `deps-vcpkg`, `deps-cmake` and `deps-archive` need ───────
 #
-# THE INSTALLERS ARE THE HOST'S; THE SDK IS THE TARGET'S. vcpkg and CMake run
-# on the machine that builds, so their payloads are declared on the host axis,
-# `[feature-xlings.<feature>]`. Qt's libraries are linked into the program, so
-# its payload is declared on the target axis, as the device toolkits above are.
+# THE INSTALLERS ARE THE HOST'S. vcpkg and CMake run on the machine that
+# builds, so their payloads are declared on the host axis,
+# `[feature-xlings.<feature>]`. They are the tools these members' actions run;
+# the libraries those tools install are the project's choice.
 #
 # `xim:vcpkg` IS THE TOOL AND ITS SCRIPTS, NOT A CLONE OF THE REGISTRY. The
 # payload is vcpkg-tool's release binary with the standalone bundle published
@@ -479,36 +469,6 @@ implies           = ["surface"]
 [feature-xlings.deps-archive]
 "xim:cmake" = ">=3.31"
 
-# AN EXACT VERSION: `moc`'s output is tied to the Qt libraries it is linked
-# against, so the SDK is a choice a project may change, not a floor. The
-# additional libraries share the base's version, and `xim:qt-addons` depends on
-# `xim:qt` at exactly that version.
-[target.'cfg(any(windows, linux, macos))'.feature-xlings.rules-qt-xim]
-"xim:qt" = "6.11.1"
-
-# THE LIBRARIES QT'S LINUX QtCore LINKS AND DOES NOT CARRY: glib, zstd and
-# zlib, which it expects the distribution to provide. A program mcpp links runs
-# under the ecosystem's glibc loader, which does not search the host's library
-# directories, so the rule declares each package's `lib/` as a runtime search
-# directory. Unversioned: they are ABI-stable C
-# libraries, and the SDK names them by SONAME. QtGui needs `libdbus-1.so.3` besides, which the ecosystem does not
-# publish; GUI modules on Linux are therefore not served yet.
-[target.'cfg(linux)'.feature-xlings.rules-qt-xim]
-"xim:glib" = ""
-"xim:zstd" = ""
-"xim:zlib" = ""
-
-[target.'cfg(any(windows, linux, macos))'.feature-xlings.rules-qt-xim-addons]
-"xim:qt-addons" = "6.11.1"
-
-[target.'cfg(any(windows, linux, macos))'.feature-xlings.rules-qt-xim-base]
-"xim:qt-base" = "6.11.1"
-
-[target.'cfg(linux)'.feature-xlings.rules-qt-xim-base]
-"xim:glib" = ""
-"xim:zstd" = ""
-"xim:zlib" = ""
-
 # ── The environment `dist-appimage` needs ──────────────────────────────────
 #
 # ONE PAYLOAD, AND IT CARRIES TWO FILES. `appimagetool` builds the image, and
@@ -668,19 +628,3 @@ kind = "lib"
 kind = "bin"
 main = "tools/embed_main.cpp"
 
-# mcpp-deps -- the command of every installation a `deps-*` member declares.
-#
-# An action carries an argument vector and no environment; vcpkg is configured
-# through its environment, and two workspace members installing one prefix at
-# once must not write it concurrently. This program sets the environment, takes
-# a lock on the installation root, and runs the installer as its child. Built
-# from this package for the reason `mcpp-embed` is: the member and the program
-# it plans are one decision, and a separately published binary could drift from
-# it by a release.
-#
-#   [build-dependencies.mcpp]
-#   plugins = { version = "0.14.0", features = ["deps-vcpkg"],
-#               host-module = true, tools = ["mcpp-deps"] }
-[targets.mcpp-deps]
-kind = "bin"
-main = "tools/deps_main.cpp"
diff --git a/rules/qt.cppm b/rules/qt.cppm
index 6652e34..6a8528f 100644
--- a/rules/qt.cppm
+++ b/rules/qt.cppm
@@ -15,11 +15,20 @@
 // import table names: its plugins (`platforms/qwindows.dll`, `styles/`,
 // `imageformats/`), which is the job `windeployqt` exists for.
 //
-// WHERE QT COMES FROM IS NOT THIS RULE'S QUESTION. `options::root` names an SDK;
-// empty takes the `xim:qt` payload, which `rules-qt-xim` declares, and
-// `xim:qt-addons` beside it when `rules-qt-xim-addons` declares that. A project
-// using a Qt from elsewhere names `rules-qt` alone and downloads nothing.
+// WHERE QT COMES FROM IS THE PROJECT'S CHOICE, stated at one of three levels;
+// the first that names an SDK decides, and `mcpp::fact("rules-qt.sdk", ...)`
+// records which:
 //
+//   1. `options::root` (and `extra_roots`), in the build program -- any value
+//      the program computes;
+//   2. the environment variable `QT_ROOT_DIR`, the name Qt's installers for CI
+//      (install-qt-action, aqtinstall) set, for one machine;
+//   3. a Qt payload the project declares in its own `[xlings]` table, at the
+//      version it chooses: `xim:qt`, else `xim:qt-base`, with `xim:qt-addons`
+//      as a second prefix.
+//
+// The rule declares no SDK and pins no version.
+
 // WHAT THE PROGRAM LOADS, THE ENGINE FINDS. The SDK's shared-library directory
 // is a runtime search directory (mcpp's SPEC-007 R4.1): the program's run path
 // on ELF and Mach-O, `mcpp run`'s load path, `mcpp pack`'s closure, and on
@@ -93,7 +102,9 @@ struct options {
     // Windows: `opengl32sw.dll` (Mesa's software OpenGL) and `d3dcompiler_47.dll`
     // beside the program, as `windeployqt` places them by default.
     bool deploy_software_gl = false;
-    // The SDK. Empty takes `xim:qt`, then `xim:qt-addons` as a second prefix.
+    // The SDK. Empty consults `QT_ROOT_DIR`, then the `xim:qt` or
+    // `xim:qt-base` payload the project declares, with `xim:qt-addons` as a
+    // second prefix (see the header).
     std::string root;
     std::vector<std::string> extra_roots;
     std::string out_dir = std::string(mcpp::out_dir());
@@ -267,27 +278,55 @@ inline std::filesystem::path private_dir(const std::filesystem::path& root, cons
 
 // The SDKs this build uses: `options::root` and `extra_roots`, or the xim
 // payloads. Empty when none is present.
-inline std::vector<std::filesystem::path> roots(const options& opt = {}) {
-    std::vector<std::filesystem::path> out;
+// Where the SDK came from: the level that named it, and its prefixes.
+struct sdk_source {
+    std::string level;   // "options", "QT_ROOT_DIR", "xlings", or empty
+    std::vector<std::filesystem::path> roots;
+};
+
+inline sdk_source locate(const options& opt = {}) {
+    namespace fs = std::filesystem;
+    sdk_source out;
     std::error_code ec;
-    auto add = [&](const std::string& r) {
-        if (r.empty()) return;
-        const auto p = detail::absolute_from_root(r);
-        if (std::filesystem::is_directory(p, ec)) out.push_back(p);
+    auto add = [&](const fs::path& p) {
+        if (!p.empty() && fs::is_directory(p, ec)) out.roots.push_back(p);
+    };
+    auto extras = [&] {
+        for (auto const& r : opt.extra_roots) add(detail::absolute_from_root(r));
     };
-    if (!opt.root.empty()) add(opt.root);
-    else {
-        // `xim:qt` is the full base; `xim:qt-base` is its qtbase + qttools
-        // subset (`rules-qt-xim-base`). A project that declares both uses the
-        // full one.
-        const std::string full = mcpp::xpkg_dir("xim", "qt");
-        add(full.empty() ? std::string(mcpp::xpkg_dir("xim", "qt-base")) : full);
-        add(mcpp::xpkg_dir("xim", "qt-addons"));
+    // 1. The build program.
+    if (!opt.root.empty()) {
+        out.level = "options";
+        add(detail::absolute_from_root(opt.root));
+        extras();
+        return out;
+    }
+    // 2. The machine.
+    mcpp::rerun_if_env_changed("QT_ROOT_DIR");
+    if (const char* env = std::getenv("QT_ROOT_DIR"); env && *env) {
+        out.level = "QT_ROOT_DIR";
+        add(fs::path(env));
+        extras();
+        return out;
+    }
+    // 3. A declared payload. `xim:qt` is the full base and `xim:qt-base` its
+    // qtbase + qttools subset; a project that declares both uses the full one.
+    const std::string full = mcpp::xpkg_dir("xim", "qt");
+    const std::string base = full.empty() ? std::string(mcpp::xpkg_dir("xim", "qt-base")) : full;
+    if (!base.empty()) {
+        out.level = "xlings";
+        add(fs::path(base));
+        if (const std::string addons = mcpp::xpkg_dir("xim", "qt-addons"); !addons.empty())
+            add(fs::path(addons));
     }
-    for (auto const& r : opt.extra_roots) add(r);
+    extras();
     return out;
 }
 
+inline std::vector<std::filesystem::path> roots(const options& opt = {}) {
+    return locate(opt).roots;
+}
+
 // The first SDK, for a project that hands it to something else (a CMake
 // subproject's `CMAKE_PREFIX_PATH`). Empty when none is present.
 inline std::string root(const options& opt = {}) {
@@ -297,32 +336,19 @@ inline std::string root(const options& opt = {}) {
 
 // ─── What the program loads ────────────────────────────────────────────────
 
-// The SDK's shared-library directories, and on Linux those of the libraries
-// Qt's official QtCore expects the distribution to provide (glib, zstd, zlib,
-// declared from xim by `rules-qt-xim` and `rules-qt-xim-base`), as runtime search directories
+// The SDK's shared-library directories, as runtime search directories
 // (SPEC-007 R4.1). The engine renders them as the program's run path, puts
-// them on `mcpp run`'s load path -- which reaches a library's dependencies
-// where the program's run path does not, because QtCore carries a RUNPATH of
-// its own -- searches them for `mcpp pack`'s closure, and on Windows places
-// the Qt DLLs the program imports beside it (R4.3).
+// them on `mcpp run`'s load path, searches them for `mcpp pack`'s closure, and
+// on Windows places the Qt DLLs the program imports beside it (R4.3). What Qt's
+// own libraries load in turn is the SDK's to resolve: the `xim:qt` and
+// `xim:qt-base` payloads stamp their Linux dependencies (glib, libdbus,
+// fontconfig, xcb, ...) onto Qt's RUNPATH, and a Qt from elsewhere carries
+// what its installer arranged.
 inline void runtime_directories(std::span<const std::filesystem::path> roots) {
-    namespace fs = std::filesystem;
-    std::error_code ec;
     for (auto const& r : roots) {
         const std::string dir = detail::generic(r / (detail::is_windows() ? "bin" : "lib"));
         mcpp::runtime_search_dir(dir.c_str());
     }
-    if (detail::is_windows() || detail::is_macos()) return;
-    for (auto const* pkg : { "glib", "zstd", "zlib" }) {
-        const std::string dir = mcpp::xpkg_dir("xim", pkg);
-        if (dir.empty()) {
-            detail::warn(std::format("mcpp.rules.qt: xim:{} is not installed, and QtCore on Linux "
-                                     "loads it; `rules-qt-xim` declares it.", pkg));
-            continue;
-        }
-        if (fs::is_directory(fs::path(dir) / "lib", ec))
-            mcpp::runtime_search_dir(detail::generic(fs::path(dir) / "lib").c_str());
-    }
 }
 
 // ─── The rule ──────────────────────────────────────────────────────────────
@@ -333,17 +359,27 @@ inline bool compile(options opt = {}) {
     constexpr std::string_view who = "mcpp.rules.qt";
     mcpp::fact("mcpp.plugins", std::string(mcpp::plugins::version).c_str());
 
-    const auto sdks = roots(opt);
+    const sdk_source source = locate(opt);
+    const auto& sdks = source.roots;
     if (sdks.empty()) {
         detail::warn(std::format(
-            "{}: no Qt SDK: options::root is {} and xpkg_dir(\"xim\", \"qt\") answered \"{}\". "
-            "Nothing Qt-specific is planned. The `rules-qt-xim` feature declares `xim:qt` and "
-            "`rules-qt-xim-base` declares `xim:qt-base`, which `mcpp build` provisions; a Qt "
-            "from elsewhere is named with options::root.",
-            who, opt.root.empty() ? "empty" : "'" + opt.root + "' (no such directory)",
-            std::string(mcpp::xpkg_dir("xim", "qt"))));
+            "{}: no Qt SDK{}. Nothing Qt-specific is planned. Name one with options::root or "
+            "QT_ROOT_DIR, or declare a payload, which `mcpp build` provisions:\n"
+            "    [target.'cfg(any(windows, linux, macos))'.xlings.workspace]\n"
+            "    \"xim:qt-base\" = \"6.11.1.1\"",
+            who, source.level.empty() ? std::string()
+                                      : " at the directory " + source.level + " names"));
         return true;
     }
+    mcpp::fact("rules-qt.sdk", std::format("{}: {}", source.level, generic(sdks.front())).c_str());
+    // Qt's official Linux binaries are built with GCC against libstdc++, and
+    // their interface carries `std::` types; a libc++ program does not link them.
+    if (!detail::is_windows() && !detail::is_macos()
+        && std::string_view(mcpp::cxx_stdlib()) == "libc++" && source.level == "xlings")
+        detail::warn(std::format(
+            "{}: the Qt SDK is Qt's official Linux build, whose C++ standard library is "
+            "libstdc++, and this toolchain's is libc++; build with a gcc toolchain "
+            "(`--toolchain gcc@<version>`), or name a Qt built with libc++.", who));
     const fs::path main = sdks.front();
     const fs::path gen  = fs::path(opt.out_dir) / "qt";
     std::error_code ec;
@@ -407,7 +443,7 @@ inline bool compile(options opt = {}) {
             "{}: module(s){} not found in {}. The base package carries Core, Gui, Widgets, "
             "Network, Svg, Qml, Quick and the other qtbase/qtdeclarative modules; the "
             "additional libraries (Multimedia, Charts, WebSockets, ...) are `xim:qt-addons`, "
-            "which the `rules-qt-xim-addons` feature declares.",
+            "which the project declares beside `xim:qt`.",
             who, list, generic(main)));
     }
 
diff --git a/src/plugins.cppm b/src/plugins.cppm
index 29cff09..f06f9d6 100644
--- a/src/plugins.cppm
+++ b/src/plugins.cppm
@@ -49,7 +49,7 @@ export namespace mcpp::plugins {
 //
 // One package, one version: the number lives in mcpp.toml, and the CI step
 // `the collection states its own version` compares the two.
-inline constexpr std::string_view version = "0.14.0";
+inline constexpr std::string_view version = "0.15.0";
 
 } // namespace mcpp::plugins
 
diff --git a/tests/all-rules-compile/build.mcpp b/tests/all-rules-compile/build.mcpp
index ba86a6f..ff571b5 100644
--- a/tests/all-rules-compile/build.mcpp
+++ b/tests/all-rules-compile/build.mcpp
@@ -81,8 +81,8 @@ int main() {
     auto apkPlan = mcpp::dist::apk::plan_for();
     ok = ok && !apkPlan.applies;
 
-    // `rules-qt` without `rules-qt-xim` has no SDK here, so the question that
-    // plans nothing is where the SDK would be: nowhere.
+    // `rules-qt` declares no SDK and this fixture declares none, so the
+    // question that plans nothing is where the SDK would be: nowhere.
     ok = ok && mcpp::rules::qt::roots({ .root = "no-such-qt-sdk" }).empty();
     // The `deps-*` members install through an action; asked only what they
     // derive without one -- the triplet this target defaults to, and the file
diff --git a/tests/all-rules-compile/mcpp.toml b/tests/all-rules-compile/mcpp.toml
index 7826616..2c2a6a4 100644
--- a/tests/all-rules-compile/mcpp.toml
+++ b/tests/all-rules-compile/mcpp.toml
@@ -64,10 +64,10 @@ plugins = { path = "../..", features = [
 # member whose macOS and Windows compile is never attempted -- which is exactly
 # the failure the two platform-specific members are here to catch.
 #
-# `rules-qt` is named without `rules-qt-xim`: the rule compiles either way, and
-# the SDK -- hundreds of megabytes on every host -- is what the `-xim` feature
-# adds and nothing else. The CI step that reads this list requires every member
-# that carries SOURCES; a member that only declares a payload is optional here.
+# `rules-qt` declares no SDK: the rule compiles without one, and the SDK --
+# hundreds of megabytes on every host -- is a project's own declaration. The CI
+# step that reads this list requires every member that carries SOURCES; a
+# member that only declares a payload is optional here.
 #
 # `deps-vcpkg` and `deps-cmake` declare their installers on the host axis, so
 # this fixture installs `xim:vcpkg` (3 MB) and `xim:cmake` on every host. Their
diff --git a/tests/archive-consumer/mcpp.toml b/tests/archive-consumer/mcpp.toml
index f97c6ae..18d3947 100644
--- a/tests/archive-consumer/mcpp.toml
+++ b/tests/archive-consumer/mcpp.toml
@@ -20,7 +20,7 @@ modules    = true
 import_std = false
 
 [build-dependencies.mcpp]
-plugins = { path = "../..", features = ["deps-archive"], host-module = true, tools = ["mcpp-deps"] }
+plugins = { path = "../..", features = ["deps-archive"], host-module = true }
 
 [targets.archive-consumer]
 kind = "bin"
diff --git a/tests/cmake-consumer/mcpp.toml b/tests/cmake-consumer/mcpp.toml
index ee9f762..1570ae5 100644
--- a/tests/cmake-consumer/mcpp.toml
+++ b/tests/cmake-consumer/mcpp.toml
@@ -13,7 +13,7 @@ modules    = true
 import_std = true
 
 [build-dependencies.mcpp]
-plugins = { path = "../..", features = ["deps-cmake"], host-module = true, tools = ["mcpp-deps"] }
+plugins = { path = "../..", features = ["deps-cmake"], host-module = true }
 
 [targets.cmake-consumer]
 kind = "bin"
diff --git a/tests/qt-consumer/mcpp.toml b/tests/qt-consumer/mcpp.toml
index de3f2f3..96cfba9 100644
--- a/tests/qt-consumer/mcpp.toml
+++ b/tests/qt-consumer/mcpp.toml
@@ -33,7 +33,11 @@ modules    = true
 import_std = false
 
 [build-dependencies.mcpp]
-plugins = { path = "../..", features = ["rules-qt-xim-base"], host-module = true }
+plugins = { path = "../..", features = ["rules-qt"], host-module = true }
+
+# The SDK is the project's declaration, at the version it chooses.
+[target.'cfg(any(windows, linux, macos))'.xlings.workspace]
+"xim:qt-base" = "6.11.1.1"
 
 [build]
 # Qt's Linux libraries load the shared libstdc++ (`libstdc++.so.6`), so the
diff --git a/tests/qt-sdk-consumer/build.mcpp b/tests/qt-sdk-consumer/build.mcpp
new file mode 100644
index 0000000..5bb7ed2
--- /dev/null
+++ b/tests/qt-sdk-consumer/build.mcpp
@@ -0,0 +1,14 @@
+// The SDK is whatever the project names. The program names one only when it is
+// given one, which stands for any value a build program computes.
+import std;
+import mcpp;
+import mcpp.rules.qt;
+
+int main() {
+    mcpp::rules::qt::options o;
+    o.modules        = { "Core" };
+    o.deploy_plugins = {};
+    mcpp::rerun_if_env_changed("QT_SDK_CONSUMER_ROOT");
+    if (const char* r = std::getenv("QT_SDK_CONSUMER_ROOT"); r && *r) o.root = r;
+    return mcpp::rules::qt::compile(o) ? 0 : 1;
+}
diff --git a/tests/qt-sdk-consumer/mcpp.toml b/tests/qt-sdk-consumer/mcpp.toml
new file mode 100644
index 0000000..aaf01d9
--- /dev/null
+++ b/tests/qt-sdk-consumer/mcpp.toml
@@ -0,0 +1,33 @@
+# Fixture: the Qt SDK named by the project, at the levels `rules-qt` consults
+# (docs/rules-qt.md, "The SDK"). The edge asks for `rules-qt` alone, which
+# declares no SDK; the project declares `xim:qt-base` at a version of its own
+# choosing. CI builds it so, then names a Qt through `QT_ROOT_DIR`, then
+# through `options::root` (the build program reads `QT_SDK_CONSUMER_ROOT`, a
+# value it computes), and reads the level the rule recorded as the fact
+# `rules-qt.sdk` each time.
+[package]
+name        = "qt-sdk-consumer"
+version     = "0.1.0"
+description = "Fixture: a Qt SDK named by the project through rules-qt"
+license     = "Apache-2.0"
+authors     = ["mcpp-community"]
+
+[language]
+standard   = "c++23"
+modules    = true
+import_std = false
+
+[build-dependencies.mcpp]
+plugins = { path = "../..", features = ["rules-qt"], host-module = true }
+
+[target.'cfg(any(windows, linux, macos))'.xlings.workspace]
+"xim:qt-base" = "6.11.1.1"
+
+[build]
+# Qt's Linux libraries load the shared libstdc++; see tests/qt-consumer.
+cxx_runtime = "toolchain-coupled"
+sources = ["src/*.cpp"]
+
+[targets.qt-sdk-consumer]
+kind = "bin"
+main = "src/main.cpp"
diff --git a/tests/qt-sdk-consumer/src/main.cpp b/tests/qt-sdk-consumer/src/main.cpp
new file mode 100644
index 0000000..3b1f792
--- /dev/null
+++ b/tests/qt-sdk-consumer/src/main.cpp
@@ -0,0 +1,9 @@
+// Prints the version of the QtCore it loaded.
+#include <QtCore/QtGlobal>
+
+#include <cstdio>
+
+int main() {
+    std::printf("qt-sdk-consumer: Qt %s\n", qVersion());
+    return 0;
+}
diff --git a/tests/qt-widgets-consumer/mcpp.toml b/tests/qt-widgets-consumer/mcpp.toml
index cf2f590..fabda0e 100644
--- a/tests/qt-widgets-consumer/mcpp.toml
+++ b/tests/qt-widgets-consumer/mcpp.toml
@@ -20,10 +20,16 @@ modules    = true
 import_std = false
 
 [build-dependencies.mcpp]
-plugins = { path = "../..", features = ["rules-qt-xim"], host-module = true }
+plugins = { path = "../..", features = ["rules-qt"], host-module = true }
 
-# Built and run on Windows and macOS by CI; on Linux QtGui needs libdbus, which
-# the ecosystem does not publish.
+# The SDK is the project's declaration: the full base package here, and
+# `xim:qt-base` in tests/qt-consumer.
+[target.'cfg(any(windows, linux, macos))'.xlings.workspace]
+"xim:qt" = "6.11.1.1"
+
+# Built, run and packed on every host by CI. On Linux the payload carries
+# QtGui's runtime closure (libdbus, fontconfig, xcb, ...); on Windows, the VC++
+# runtime its DLLs import.
 [build]
 # Qt's Linux libraries load the shared libstdc++ (`libstdc++.so.6`), so the
 # program uses the toolchain's shared C++ runtime rather than embedding a second
diff --git a/tests/vcpkg-consumer/build.mcpp b/tests/vcpkg-consumer/build.mcpp
index b5f7ea2..99f441e 100644
--- a/tests/vcpkg-consumer/build.mcpp
+++ b/tests/vcpkg-consumer/build.mcpp
@@ -7,11 +7,10 @@ import mcpp.deps.vcpkg;
 int main() {
     mcpp::deps::vcpkg::options o;
     o.libraries = { "fmt" };
-    // This fixture lives inside the package it depends on by path, and mcpp keys
-    // that package's host tool by a stamp of its tree, `target/` excepted
-    // (mcpp#705). An installation beside the manifest would change the stamp,
-    // rebuild `mcpp-deps` and run again, so it goes under `target/`. A project
-    // that takes `mcpp:plugins` from the index keeps vcpkg's default.
+    // This fixture lives inside the package it depends on by path, so its
+    // installation goes under `target/`, which `git clean` and the CI's
+    // `rm -rf target` reset with the rest of the fixture. A project keeps
+    // vcpkg's default.
     o.install_root = "target/vcpkg_installed";
     // A file the program would read at run time, placed beside it.
     o.deploy = {{"share/fmt/copyright", "licenses/fmt"}};
diff --git a/tests/vcpkg-consumer/mcpp.toml b/tests/vcpkg-consumer/mcpp.toml
index e687885..07ef3c6 100644
--- a/tests/vcpkg-consumer/mcpp.toml
+++ b/tests/vcpkg-consumer/mcpp.toml
@@ -18,7 +18,7 @@ modules    = true
 import_std = true
 
 [build-dependencies.mcpp]
-plugins = { path = "../..", features = ["deps-vcpkg"], host-module = true, tools = ["mcpp-deps"] }
+plugins = { path = "../..", features = ["deps-vcpkg"], host-module = true }
 
 [targets.vcpkg-consumer]
 kind = "bin"
diff --git a/tests/vcpkg-workspace/app-a/mcpp.toml b/tests/vcpkg-workspace/app-a/mcpp.toml
index a1eb757..565b5db 100644
--- a/tests/vcpkg-workspace/app-a/mcpp.toml
+++ b/tests/vcpkg-workspace/app-a/mcpp.toml
@@ -8,7 +8,7 @@ modules    = true
 import_std = true
 
 [build-dependencies.mcpp]
-plugins = { path = "../../..", features = ["deps-vcpkg"], host-module = true, tools = ["mcpp-deps"] }
+plugins = { path = "../../..", features = ["deps-vcpkg"], host-module = true }
 
 [targets.app-a]
 kind = "bin"
diff --git a/tests/vcpkg-workspace/app-b/mcpp.toml b/tests/vcpkg-workspace/app-b/mcpp.toml
index 84fdae7..6a17bad 100644
--- a/tests/vcpkg-workspace/app-b/mcpp.toml
+++ b/tests/vcpkg-workspace/app-b/mcpp.toml
@@ -8,7 +8,7 @@ modules    = true
 import_std = true
 
 [build-dependencies.mcpp]
-plugins = { path = "../../..", features = ["deps-vcpkg"], host-module = true, tools = ["mcpp-deps"] }
+plugins = { path = "../../..", features = ["deps-vcpkg"], host-module = true }
 
 [targets.app-b]
 kind = "bin"
diff --git a/tests/vcpkg-workspace/mcpp.toml b/tests/vcpkg-workspace/mcpp.toml
index cd7e645..13ccc09 100644
--- a/tests/vcpkg-workspace/mcpp.toml
+++ b/tests/vcpkg-workspace/mcpp.toml
@@ -4,9 +4,9 @@
 # The compile edges of the package that declares a `prepare` action wait for
 # it, and those of no other package do, so each member declares the
 # installation itself. The two actions run the same `vcpkg install` against the
-# root's one manifest into one installation root; `mcpp-deps` holds a lock on
-# that root, so they run one after the other and the second finds everything
-# installed.
+# root's one manifest into one installation root; vcpkg locks that root itself
+# (`vcpkg/vcpkg-running.lock`), so they run one after the other and the second
+# finds everything installed.
 [workspace]
 members = ["app-a", "app-b"]
 
diff --git a/tools/deps_main.cpp b/tools/deps_main.cpp
deleted file mode 100644
index de58af8..0000000
--- a/tools/deps_main.cpp
+++ /dev/null
@@ -1,372 +0,0 @@
-// mcpp-deps -- the command of every installation a `deps-*` member declares.
-//
-// WHY A PROGRAM AND NOT THE INSTALLER ITSELF AS THE ACTION'S COMMAND.
-//
-// An `mcpp::action` is an argument vector and nothing else: it carries no
-// environment and no working directory (mcpp's docs/30, "Declaring work instead
-// of doing it"). vcpkg is configured through its environment -- `VCPKG_ROOT`
-// names the tool's scripts, `VCPKG_DISABLE_METRICS` keeps a build from
-// reporting home -- and an installation has three more needs no argument
-// vector can state:
-//
-//   - a LOCK on the installation root, because two workspace members that
-//     both use one prefix each declare the installation (the engine orders
-//     construction actions per package), and two installers writing one tree
-//     at once is a corrupt tree;
-//   - SHORT scratch directories for vcpkg's build trees, outside the project,
-//     because a port's build nests deep and Windows still enforces MAX_PATH on
-//     many of the tools a port runs.
-//
-// This program sets those up and runs the installer as a child, waiting for it
-// and returning its status; the action is a `prepare` (mcpp's SPEC-007 R3.3),
-// whose stamp mcpp writes when the status is 0 and whose declared output
-// directory the installation fills. It holds no knowledge of any project: every value
-// arrives on its command line from the member that planned the action.
-//
-// Usage:
-//   mcpp-deps vcpkg --vcpkg <exe> --root <VCPKG_ROOT> --manifest-root <dir>
-//             --install-root <dir> --triplet <t>
-//             [--overlay-triplets <dir>]... [-- <extra vcpkg install args>...]
-//   mcpp-deps cmake --cmake <exe> --source <dir> --build <dir> --prefix <dir>
-//             [--config <Release>] [--generator <g>]
-//             [-- <extra configure args>...]
-//   mcpp-deps unpack --cmake <exe> --archive <file> --into <dir>
-#if defined(_WIN32)
-#  define WIN32_LEAN_AND_MEAN
-#  define NOMINMAX
-#  include <windows.h>
-#else
-#  include <fcntl.h>
-#  include <sys/file.h>
-#  include <sys/wait.h>
-#  include <unistd.h>
-#  include <spawn.h>
-extern char** environ;
-#endif
-#include <cstdlib>
-
-import std;
-
-namespace {
-
-namespace fs = std::filesystem;
-
-[[noreturn]] void usage(std::string_view why) {
-    std::cerr << "mcpp-deps: " << why << "\n"
-              << "usage: mcpp-deps vcpkg --vcpkg <exe> --root <dir> --manifest-root <dir> "
-                 "--install-root <dir> --triplet <t> [--overlay-triplets <dir>]... "
-                 "[-- <args>...]\n"
-              << "       mcpp-deps cmake --cmake <exe> --source <dir> --build <dir> --prefix <dir> "
-                 "[--config <c>] [--generator <g>] [-- <args>...]\n"
-              << "       mcpp-deps unpack --cmake <exe> --archive <file> --into <dir>\n";
-    std::exit(2);
-}
-
-struct args {
-    std::map<std::string, std::vector<std::string>> named;
-    std::vector<std::string> rest;   // after `--`
-
-    const std::string& one(const std::string& key) const {
-        auto it = named.find(key);
-        if (it == named.end() || it->second.empty()) usage("missing --" + key);
-        return it->second.back();
-    }
-    std::string opt(const std::string& key, std::string fallback = {}) const {
-        auto it = named.find(key);
-        return it == named.end() || it->second.empty() ? fallback : it->second.back();
-    }
-    std::vector<std::string> all(const std::string& key) const {
-        auto it = named.find(key);
-        return it == named.end() ? std::vector<std::string>{} : it->second;
-    }
-};
-
-args parse(int argc, char** argv, int from) {
-    args a;
-    for (int i = from; i < argc; ++i) {
-        std::string_view s = argv[i];
-        if (s == "--") {
-            for (++i; i < argc; ++i) a.rest.emplace_back(argv[i]);
-            break;
-        }
-        if (!s.starts_with("--") || i + 1 >= argc) usage(std::format("unexpected `{}`", s));
-        a.named[std::string(s.substr(2))].emplace_back(argv[++i]);
-    }
-    return a;
-}
-
-std::string env(const char* name) {
-    const char* v = std::getenv(name);
-    return v ? std::string(v) : std::string();
-}
-
-// ── The platform: environment, a child process, a lock ─────────────────────
-
-#if defined(_WIN32)
-std::wstring wide(std::string_view s) {
-    if (s.empty()) return {};
-    const int n = ::MultiByteToWideChar(CP_UTF8, 0, s.data(), int(s.size()), nullptr, 0);
-    std::wstring w(std::size_t(n), L'\0');
-    ::MultiByteToWideChar(CP_UTF8, 0, s.data(), int(s.size()), w.data(), n);
-    return w;
-}
-
-void set_env(const std::string& name, const std::string& value) {
-    ::SetEnvironmentVariableW(wide(name).c_str(), value.empty() ? nullptr : wide(value).c_str());
-}
-
-// The quoting `CommandLineToArgvW` and the C runtime both undo: backslashes
-// are literal unless they precede a quote, and then they are doubled.
-std::wstring quote(const std::wstring& arg) {
-    if (!arg.empty() && arg.find_first_of(L" \t\n\v\"") == std::wstring::npos) return arg;
-    std::wstring out = L"\"";
-    for (std::size_t i = 0;; ++i) {
-        std::size_t backslashes = 0;
-        while (i < arg.size() && arg[i] == L'\\') { ++i; ++backslashes; }
-        if (i == arg.size()) { out.append(backslashes * 2, L'\\'); break; }
-        if (arg[i] == L'"') { out.append(backslashes * 2 + 1, L'\\'); out += L'"'; }
-        else { out.append(backslashes, L'\\'); out += arg[i]; }
-    }
-    return out + L"\"";
-}
-
-int run(const std::vector<std::string>& argv) {
-    std::wstring line;
-    for (auto const& a : argv) {
-        if (!line.empty()) line += L' ';
-        line += quote(wide(a));
-    }
-    STARTUPINFOW si{};
-    si.cb = sizeof si;
-    PROCESS_INFORMATION pi{};
-    if (!::CreateProcessW(nullptr, line.data(), nullptr, nullptr, TRUE, 0, nullptr, nullptr,
-                          &si, &pi)) {
-        std::cerr << std::format("mcpp-deps: cannot start {} (error {})\n", argv.front(),
-                                 ::GetLastError());
-        return 127;
-    }
-    ::WaitForSingleObject(pi.hProcess, INFINITE);
-    DWORD code = 1;
-    ::GetExitCodeProcess(pi.hProcess, &code);
-    ::CloseHandle(pi.hThread);
-    ::CloseHandle(pi.hProcess);
-    return int(code);
-}
-
-struct file_lock {
-    HANDLE h = INVALID_HANDLE_VALUE;
-    explicit file_lock(const fs::path& p) {
-        h = ::CreateFileW(p.wstring().c_str(), GENERIC_READ | GENERIC_WRITE,
-                          FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, nullptr,
-                          OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, nullptr);
-        if (h == INVALID_HANDLE_VALUE) return;
-        OVERLAPPED o{};
-        ::LockFileEx(h, LOCKFILE_EXCLUSIVE_LOCK, 0, MAXDWORD, MAXDWORD, &o);
-    }
-    ~file_lock() {
-        if (h == INVALID_HANDLE_VALUE) return;
-        OVERLAPPED o{};
-        ::UnlockFileEx(h, 0, MAXDWORD, MAXDWORD, &o);
-        ::CloseHandle(h);
-    }
-    bool held() const { return h != INVALID_HANDLE_VALUE; }
-};
-#else
-void set_env(const std::string& name, const std::string& value) {
-    if (value.empty()) ::unsetenv(name.c_str());
-    else ::setenv(name.c_str(), value.c_str(), 1);
-}
-
-int run(const std::vector<std::string>& argv) {
-    std::vector<char*> cargv;
-    for (auto const& a : argv) cargv.push_back(const_cast<char*>(a.c_str()));
-    cargv.push_back(nullptr);
-    pid_t pid = 0;
-    if (::posix_spawnp(&pid, cargv[0], nullptr, nullptr, cargv.data(), environ) != 0) {
-        std::cerr << std::format("mcpp-deps: cannot start {}\n", argv.front());
-        return 127;
-    }
-    int status = 0;
-    while (::waitpid(pid, &status, 0) < 0) {}
-    if (WIFEXITED(status)) return WEXITSTATUS(status);
-    return 128 + (WIFSIGNALED(status) ? WTERMSIG(status) : 0);
-}
-
-struct file_lock {
-    int fd = -1;
-    explicit file_lock(const fs::path& p) {
-        fd = ::open(p.c_str(), O_RDWR | O_CREAT, 0644);
-        if (fd >= 0) ::flock(fd, LOCK_EX);
-    }
-    ~file_lock() {
-        if (fd < 0) return;
-        ::flock(fd, LOCK_UN);
-        ::close(fd);
-    }
-    bool held() const { return fd >= 0; }
-};
-#endif
-
-// FNV-1a: a stable name for a directory derived from a path. Stable across
-// runs and compilers, which `std::hash` does not promise.
-std::string short_name(std::string_view text) {
-    std::uint64_t h = 1469598103934665603ull;
-    for (unsigned char c : text) { h ^= c; h *= 1099511628211ull; }
-    return std::format("{:08x}", std::uint32_t(h ^ (h >> 32)));
-}
-
-// vcpkg's own per-user directory: where its default binary cache
-// (`archives/`) and registry cache (`registries/`) already live (vcpkg's
-// "Default binary cache" documentation). Scratch and downloads go beside them,
-// so everything vcpkg keeps for a user is in the place vcpkg's own
-// documentation sends them to look.
-fs::path vcpkg_user_dir() {
-#if defined(_WIN32)
-    if (auto v = env("LOCALAPPDATA"); !v.empty()) return fs::path(v) / "vcpkg";
-    if (auto v = env("APPDATA"); !v.empty()) return fs::path(v) / "vcpkg";
-#else
-    if (auto v = env("XDG_CACHE_HOME"); !v.empty()) return fs::path(v) / "vcpkg";
-    if (auto v = env("HOME"); !v.empty()) return fs::path(v) / ".cache" / "vcpkg";
-#endif
-    return fs::temp_directory_path() / "vcpkg";
-}
-
-// ── vcpkg ──────────────────────────────────────────────────────────────────
-
-int vcpkg_install(const args& a) {
-    const fs::path exe          = a.one("vcpkg");
-    const fs::path root         = a.one("root");
-    const fs::path manifestRoot = a.one("manifest-root");
-    const fs::path installRoot  = a.one("install-root");
-    const std::string triplet   = a.one("triplet");
-
-    std::error_code ec;
-    fs::create_directories(installRoot, ec);
-    file_lock lock(installRoot / ".mcpp-deps.lock");
-    if (!lock.held())
-        std::cerr << "mcpp-deps: could not lock " << installRoot.string()
-                  << "; continuing without the lock\n";
-
-    // THE TOOL'S OWN SCRIPTS, NOT WHATEVER `VCPKG_ROOT` THE SHELL HAS. The
-    // root this program is given is the standalone bundle published with the
-    // tool, so the scripts a port calls are the ones this tool was released
-    // with. An inherited `VCPKG_ROOT` naming a clone at another commit would
-    // pair this tool with scripts it was not tested against.
-    set_env("VCPKG_ROOT", root.string());
-    set_env("VCPKG_DISABLE_METRICS", "1");
-
-    const fs::path user = vcpkg_user_dir();
-    const fs::path work = user / "mcpp" / short_name(fs::absolute(installRoot).generic_string());
-
-    std::vector<std::string> cmd{
-        exe.string(), "install",
-        "--triplet", triplet,
-        "--x-manifest-root=" + manifestRoot.string(),
-        "--x-install-root=" + installRoot.string(),
-        "--x-buildtrees-root=" + (work / "bt").string(),
-        "--x-packages-root=" + (work / "pk").string(),
-        "--clean-buildtrees-after-build",
-        "--clean-packages-after-build",
-    };
-    // Downloads are shared by every project on the machine; a user who has
-    // moved them already (`VCPKG_DOWNLOADS`) keeps that.
-    if (env("VCPKG_DOWNLOADS").empty())
-        cmd.push_back("--downloads-root=" + (user / "downloads").string());
-    for (auto const& d : a.all("overlay-triplets")) cmd.push_back("--overlay-triplets=" + d);
-    for (auto const& r : a.rest) cmd.push_back(r);
-
-    std::cerr << "mcpp-deps: vcpkg install --triplet " << triplet << " ("
-              << manifestRoot.string() << " -> " << installRoot.string() << ")\n";
-    const int code = run(cmd);
-    if (code != 0) {
-        std::cerr << std::format("mcpp-deps: vcpkg install exited {}\n", code);
-        return code;
-    }
-    return 0;
-}
-
-// ── CMake ──────────────────────────────────────────────────────────────────
-
-int cmake_install(const args& a) {
-    const fs::path cmake  = a.one("cmake");
-    const fs::path source = a.one("source");
-    const fs::path build  = a.one("build");
-    const fs::path prefix = a.one("prefix");
-    const std::string config = a.opt("config", "Release");
-
-    std::error_code ec;
-    fs::create_directories(build, ec);
-    file_lock lock(build / ".mcpp-deps.lock");
-
-    // CONFIGURE EVERY TIME, AND LET CMAKE DECIDE WHAT THAT COSTS. A configure
-    // over an existing cache re-runs only what changed, and the arguments may
-    // have changed -- which is why this action ran at all.
-    std::vector<std::string> configure{
-        cmake.string(), "-S", source.string(), "-B", build.string(),
-        "-DCMAKE_INSTALL_PREFIX=" + prefix.string(),
-        "-DCMAKE_BUILD_TYPE=" + config,
-    };
-    if (auto g = a.opt("generator"); !g.empty()) { configure.push_back("-G"); configure.push_back(g); }
-    for (auto const& r : a.rest) configure.push_back(r);
-    std::cerr << "mcpp-deps: cmake configure " << source.string() << "\n";
-    if (int code = run(configure); code != 0) {
-        std::cerr << std::format("mcpp-deps: cmake configure exited {}\n", code);
-        return code;
-    }
-    std::vector<std::string> install{
-        cmake.string(), "--build", build.string(), "--config", config,
-        "--target", "install", "--parallel",
-    };
-    std::cerr << "mcpp-deps: cmake build and install -> " << prefix.string() << "\n";
-    if (int code = run(install); code != 0) {
-        std::cerr << std::format("mcpp-deps: cmake --build exited {}\n", code);
-        return code;
-    }
-    return 0;
-}
-
-// ── An archive ─────────────────────────────────────────────────────────────
-
-// Extracts `--archive` into `--into`, which it empties first: the member that
-// planned this action named every file the archive holds as an output, and a
-// file left over from a previous archive would be one it did not name. CMake's
-// `-E tar` reads zip as well as tar on every host; `--touch` gives each file
-// the time of extraction, so the outputs are newer than the archive and the
-// next build finds them up to date. `-E tar` extracts into its working
-// directory, which an action cannot set, so this program sets it.
-int unpack(const args& a) {
-    const fs::path cmake   = a.one("cmake");
-    const fs::path archive = fs::absolute(a.one("archive"));
-    const fs::path into    = fs::absolute(a.one("into"));
-
-    std::error_code ec;
-    fs::remove_all(into, ec);
-    fs::create_directories(into, ec);
-    if (ec) {
-        std::cerr << std::format("mcpp-deps: cannot create {}: {}\n", into.string(), ec.message());
-        return 1;
-    }
-    fs::current_path(into, ec);
-    if (ec) {
-        std::cerr << std::format("mcpp-deps: cannot enter {}: {}\n", into.string(), ec.message());
-        return 1;
-    }
-    std::cerr << "mcpp-deps: unpack " << archive.string() << " -> " << into.string() << "\n";
-    if (int code = run({cmake.string(), "-E", "tar", "xf", archive.string(), "--touch"}); code != 0) {
-        std::cerr << std::format("mcpp-deps: cmake -E tar exited {}\n", code);
-        return code;
-    }
-    return 0;
-}
-
-} // namespace
-
-int main(int argc, char** argv) {
-    if (argc < 2) usage("no subcommand");
-    const std::string_view sub = argv[1];
-    const args a = parse(argc, argv, 2);
-    if (sub == "vcpkg") return vcpkg_install(a);
-    if (sub == "cmake") return cmake_install(a);
-    if (sub == "unpack") return unpack(a);
-    usage(std::format("unknown subcommand `{}`", sub));
-}