docs: the ecosystem packages that make accelerator support usable

An engine capability with no packages behind it does not exist for a developer.
The design and the plan now name what has to land in xim and mcpp-index, in
dependency order, with what each package validates.

Two entries carry most of the weight. AdaptiveCpp comes first among the
payloads because its OpenMP backend runs SYCL kernels on the CPU, which makes
the whole of form B verifiable end to end on a machine with no GPU. llama.cpp-m
comes first among the libraries because one package exercises three of the
seven user roles at once, it has no Python packaging layer to confuse the
result, and it already exists in the ecosystem, so the step is adding a backend
rather than adopting a large project.

The two header-only libraries, CCCL and CUTLASS, are listed before anything
with a binary artifact: they carry no size or variant-matrix problem and are
therefore the first real libraries reachable by the source-distribution path.

Author: speak-agent

.agents/docs/2026-09-05-accelerator-support-design.md

@@ -627,6 +627,44 @@ artifact:
 ⇒ **首选 ggml。** 理由不是它最流行,是它**一个包同时压到 R1/R3/R5 三类**,
 而且它没有 Python 打包层,不会把 wheel 的问题混进来。
 
+### 8.1b 要补进生态的包(2026-09-05 追加)
+
+引擎能力落地之后,生态里必须有**真实流行的**运行时 / 库 / 框架 / SDK,
+否则这套能力对开发者等于不存在。下表按依赖顺序排,每一行注明它验证什么。
+
+#### xim 侧(工具链与 SDK 载荷)
+
+| 包 | 内容 | 验证什么 | 依赖 |
+|---|---|---|---|
+| ⭐ `adaptivecpp` | SYCL,SSCP + **omp 后端** | **形态 B 可在无卡 CI 端到端跑,含 kernel 真执行** | LLVM 载荷 |
+| `cuda-nvcc` | `nvcc`/`ptxas`/`nvlink`/`fatbinary`/`cicc` + CRT 头 | 设备工具链不再依赖 host(§5.0b) | —— |
+| `cuda-cudart` | CUDA 运行时库与头 | 程序能链、能跑 | `libcuda-host-link`(**已有**) |
+| `dpcpp` | intel/llvm 开源版,`configure.py --cuda/--hip` | 形态 B 的 NVIDIA/AMD 后端(无需 Codeplay) | —— |
+| `cudnn` | 深度学习原语 | 真实推理框架可用 | `cuda-cudart` |
+| `nccl`(后续) | 多卡通信 | 多卡场景 | `cuda-cudart` |
+
+⚠️ 体积按组件取,不打整个 toolkit(§9 RK-3)。`cuda-nvcc` + `cuda-cudart` 是百 MB 级。
+
+#### mcpp-index 侧(规则包、能力包、真实库)
+
+| 包 | 提供 | 验证什么 |
+|---|---|---|
+| `rules-cuda` | `mcpp:device-rule=cuda` | P5 规则包;`backend` 经 capability 解析 |
+| `compat.cudart` | `gpu-runtime` | capability 绑定 |
+| `compat.cublas` | `gpu-blas` | ⚠️ 与 `compat.rocblas` **同名符号** ⇒ 它们本身就是决定 4 的验证夹具 |
+| `compat.cccl` | header-only(Thrust/CUB/libcu++) | 最小可用的 GPU 算法库;无二进制分发问题 |
+| `compat.cutlass` | header-only,按 CUDA 版本门控架构白名单 | **逐 glob 架构收窄(R4)的压测对象** |
+| ⭐⭐ `llama.cpp-m` 加 CUDA 后端 | —— | **R1 + R3 + R5 三类;而且它已经在 `mcpplibs/` 里** |
+| `compat.onnxruntime`(后续) | 按 EP 分变体 | R1 的多变体选择,真实体量 |
+| `compat.opencv` + CUDA(后续) | —— | 真实的混合工程 |
+
+⭐⭐ **`llama.cpp-m` 是首选验证对象,理由不是它流行,是它一个包同时压到三类使用者**,
+而且它没有 Python 打包层,不会把 wheel 的问题混进来。它已经存在于生态中,
+所以这一步是「给它加一个后端」,不是「从零收录一个大工程」。
+
+⭐ `compat.cccl` 与 `compat.cutlass` 都是 header-only,**没有二进制分发与体积问题**,
+所以它们是 §11.1 说的「源码分发这条最短路径」上最先能落地的两个真实库。
+
 ### 8.2 ⚠️⚠️ 发布顺序是一个环,必须拆开
 
 memory 记过两条硬的:「消费者先发布,索引 `latest` 才能动」、

.agents/docs/2026-09-05-accelerator-support-implementation-plan.md

@@ -251,10 +251,27 @@ clang 必须 `< 15`),或内置一张按 CUDA 版本的表。
 
 ## 跨仓库
 
-**PR B(mcpp-index)**:`rules-cuda` 规则包;`compat.cublas` 能力包;
-一个最小多后端夹具库。**在 PR A 发布之后**。
+**PR B(mcpp-index)** —— 在 PR A 发布之后。按此顺序:
 
-**PR C(xlings)**:按需的载荷。若本机 CUDA 已够用则本轮可不动。
+| # | 包 | 类型 | 验证 |
+|---|---|---|---|
+| B1 | `rules-cuda` | 规则包 | P5;`backend` 经 capability 解析 |
+| B2 | `compat.cccl` | header-only | 源码分发最短路径上的第一个真实库 |
+| B3 | `compat.cudart` / `compat.cublas` | 能力包 | capability 绑定;**同名符号夹具(决定 4)** |
+| B4 | `compat.cutlass` | header-only | 逐 glob 架构收窄(R4)的压测 |
+| B5 | `llama.cpp-m` 加 CUDA 后端 | 真实框架 | ⭐⭐ R1+R3+R5;**它已在 `mcpplibs/` 里** |
+| B6 | `compat.onnxruntime` / `compat.opencv` | 后续 | 真实体量的多变体选择 |
+
+**PR C(xim-pkgindex)** —— 载荷。按此顺序:
+
+| # | 包 | 验证 |
+|---|---|---|
+| C1 | ⭐ `adaptivecpp` | 形态 B **在无卡机器上 kernel 真执行** |
+| C2 | `cuda-nvcc` | 设备工具链脱离 host(§5.0b 的原则) |
+| C3 | `cuda-cudart` | 依赖已有的 `libcuda-host-link` sentinel |
+| C4 | `dpcpp` / `cudnn` / `nccl` | 后续 |
+
+⚠️ 按组件取,不打整个 toolkit。`cuda-nvcc` + `cuda-cudart` 是百 MB 级不是 GB 级。
 
 **沙箱验证**:`xlings subos <name> --sandbox --cmd "..."`,先配 CN mirror。