docs(plan): the toolkit pulls anonymously, so the experiment has no blocker

Overturns the previous commit's one negative finding, and corrects the framing
error underneath it.

The framing error first: BiSheng and the simulator were treated as two
acquisition questions. They are one -- ccec_compiler/bin/bisheng and
simulator/<SoC>/lib are both inside the CANN toolkit.

The toolkit's official distribution is a Docker image, not a .run installer
(measured in ops-math/QUICKSTART.md):

    swr.cn-south-1.myhuaweicloud.com/ascendhub/cann:8.5.0-910b-ubuntu22.04-py3.10-ops

and it pulls anonymously. Measured:

    GET /v2/                                              401
    GET /swr/auth/v2/registry/auth?...:pull               token issued
    GET /v2/ascendhub/cann/manifests/<tag> with token     200, arm64 + amd64

That 401 is what produced the wrong answer the first time. A bare 401 reads
identically to "credentials required", but it is also the first step of an
anonymous token handshake -- Docker Hub behaves the same way. Stopping at step
one turns "anonymously available" into "unobtainable". The criterion has to
walk the whole handshake, which is this repository's recurring lesson about a
criterion whose "no" and whose "not measured" produce the same reading.

Compliance lands in the tier the invariant already allows: proprietary vendor
userspace is fetched from the vendor's own published URL and never copied into
an xlings-res release. Pulling the official image from Huawei's own registry is
exactly that, so no redistribution right is needed.

Also records that AscendNPU IR is now open with a Triton path
(Triton IR -> Linalg -> AscendNPU IR), which gives a rule package a second
possible entry height. Not selected -- Ascend C remains the direct one, because
it is the actual form of the 1451 .cpp files in ops-math.

The feasibility gate therefore has no blocking row. One technical question
remains before implementation: whether sim mode still invokes bisheng, since
that decides which object the device criterion is pointed at.

Author: speak-agent

.agents/docs/2026-09-07-general-build-infrastructure-gaps-design.md

@@ -464,7 +464,7 @@ Python 层(`pyasc`、`pypto`、框架适配)不在覆盖内;规模是数人年;*
 
 ### 10.3 调研结果(2026-09-07 实测)
 
-三处不确定已调研,**两处证实,一处未能证实**。仓库全部可匿名 clone
+三处不确定已调研,**全部证实,无阻碍项**(§10.3.3 的初次否定结论已被推翻)。仓库全部可匿名 clone
 (`gitcode.com/cann/*`,分支 `8.5.0`),许可为 CANN Open Software License Agreement 2.0。
 
 #### 10.3.1 无硬件执行:存在,且是厂商自己的测试路径(证实)
@@ -527,15 +527,58 @@ math/<op>/op_host/config/<soc>/<op>_simplified_key.ini
 另外两项确认:**源码布局本身已经是岛** —— 每个算子的 `op_kernel/` 与 `op_host/` 是分开
 的目录;设备架构标志是 `CMAKE_ASC_ARCHITECTURES=dav-2201`,与 `sm_89` 同类。
 
-#### 10.3.3 毕昇的可再分发性:未能证实(不利)
+#### 10.3.3 工具包的获取:官方镜像,可匿名拉取(实测,已推翻初次结论)
 
-毕昇不是独立发布物。实测路径是
-`${ASCEND_DIR}/compiler/ccec_compiler/bin/bisheng`(`ops-math/cmake/torch_extension.cmake`)
-—— 它在 **CANN 工具包内部**。而工具包的下载页要求接受 *CANN Software User License
-Agreement 2.0* 且看来需要登录;**没有找到稳定的匿名 URL,再分发条款也未确认**。
+**初次调研把这一条判成"未能证实、构成阻碍"。复查后推翻。**
 
-这与 dpcpp 的处境不同,dpcpp 有可直接取的发布物。**这一条是本实验唯一真实的阻碍**,
-且它不是技术问题。
+首先纠正一个框架错误:初次把"毕昇"与"模拟器"当成两个获取问题。**它们在同一个包里** ——
+
+| 组件 | 路径 |
+|---|---|
+| 设备编译器 | `${ASCEND_DIR}/compiler/ccec_compiler/bin/bisheng` |
+| 模拟器 | `${ASCEND_DIR}/*/simulator/<SoC>/lib` |
+
+两者都在 CANN 工具包内部,所以这是**一个**获取问题,不是两个。
+
+**官方获取方式是 Docker 镜像**,而不是 `.run` 安装包(实测于 `ops-math/QUICKSTART.md`):
+
+```
+swr.cn-south-1.myhuaweicloud.com/ascendhub/cann:8.5.0-910b-ubuntu22.04-py3.10-ops
+```
+
+**它可以匿名拉取。** 实测过程与结论:
+
+| 步骤 | 结果 |
+|---|---|
+| `GET /v2/` | `401` |
+| 匿名 token:`GET /swr/auth/v2/registry/auth?service=dockyard&scope=repository:ascendhub/cann:pull` | **签发**(2107 字节 JWT) |
+| 持 token 取 manifest | **200**,manifest list,含 `arm64` 与 `amd64` |
+
+**那个 401 差点让我下错结论。** 裸的 401 与"需要凭据"读数相同,但它同样是匿名 token
+握手的第一步(Docker Hub 就是这样)。只看第一步会把"可匿名获取"误判成"不可得" ——
+这正是本仓库记过的形态:判据的"否"与"没测成"同读数。**判据必须走完握手。**
+
+**合规性:正好落在不变量允许的那一档。** 本生态的规则是"专有厂商用户态要么在它已经
+在的地方链接,要么从**厂商自己发布的 URL** 取 —— 绝不拷进 xlings-res 的发布物"。
+从华为自己的 registry 拉官方镜像**就是**这一档,不需要再分发权。
+
+结论:**这一条不再是阻碍。** 剩下的是工程问题(镜像里取哪些目录、怎么做成载荷),
+不是许可问题。
+
+#### 10.3.3b AscendNPU IR 已开放,存在第二个切入点
+
+毕昇开放了 **AscendNPU IR**(昇腾自有的 MLIR dialect),并给出 Triton 的完整路径:
+Triton IR → Linalg IR → AscendNPU IR → 算子二进制,配套 `triton-ascend`。
+
+这不改变"毕昇二进制在工具包里"这个事实,但它意味着**规则包有两个可选的切入高度**:
+
+| 切入点 | 输入 | 代价 |
+|---|---|---|
+| Ascend C(§10.2 的切片) | `op_kernel/*.cpp` | 直接对应现有算子库 |
+| Triton / AscendNPU IR | Triton kernel | 与 CUDA 侧的 Triton 生态同构,但离现有 CANN 算子库更远 |
+
+**本文不选型**,只记录第二条存在。对"验证 mcpp 完备性"这个目的而言 Ascend C 更直接,
+因为它才是 `ops-math` 里那 1451 个 `.cpp` 的实际形态。
 
 #### 10.3.4 一个附带发现:CMake 把 Ascend C 当作一门"语言"
 
@@ -550,26 +593,26 @@ Agreement 2.0* 且看来需要登录;**没有找到稳定的匿名 URL,再分发
 2. 这是 §9 那条轴的第三方佐证:CMake 用 `enable_language(ASC)` 把它放进**引擎**,
    mcpp 用规则包把它放进**包**。**同一条轴,不同的归属** —— 而归属正是 §7 要裁决的事。
 
-### 10.4 修正后的可行性闸
-
-初稿把"有硬件或模拟器"列为开工硬闸。**这条太严,已更正。** 闸应拆成两个:
+### 10.4 可行性闸(两次修正后)
 
 | 目的 | 需要 | 结论 |
 |---|---|---|
-| **架构验证**(本实验) | 无 | **可开工** —— 裁决判据 `git diff src/` 为空完全在构建期 |
-| **对用户可用** | `sim` 模式或真机 | `sim` 存在(§10.3.1),但受 §10.3.3 阻碍 |
+| **架构验证**(本实验) | 无 | **可开工**。裁决判据 `git diff src/` 为空完全在构建期 |
+| **设备执行判据** | `sim` 模式 + 工具包 | **可得**。工具包镜像匿名可拉(§10.3.3),`sim` 无需硬件(§10.3.1) |
+| 真机验证 | 昇腾硬件 | 可选,不阻塞以上任何一项 |
+
+**没有阻碍项。** 初稿列的三条前置里,两条证实、一条被推翻;剩下的都是工程量。
 
-唯一的真实前置是 **§10.3.3:毕昇能否合规取得**。不解决它,连构建都跑不起来。
-可能的出路两条,均需人工确认:(a) 工具包是否允许在 CI 环境内自动下载安装;
-(b) 是否接受"用户自备工具包,mcpp 只按 `ASCEND_HOME_PATH` 定位"的形态 —— 后者与
-本生态"不用宿主"的不变量有张力,需要单独裁定。
+实现前仍需确认的只剩一条技术问题:**`sim` 模式是否仍调用 `bisheng`**(§10.3.1),
+因为它决定设备执行判据落在哪个对象上。
 
 ### 10.5 裁决判据
 
 阶段一(`rules-ascendc` + 一个 hello kernel)两条,第二条是重点:
 
 1. 在 `sim` 模式下跑出正确结果,**断言设备名/执行路径而非结果数值**(数值在 `cpu`
    模式与静默回退时同样正确)。**不得用 `cpu` 模式充当这条** —— 理由见 §10.3.1。
+   前置:先确认 `sim` 下仍调用 `bisheng`,否则这条判据与 `cpu` 模式等价而无效。
 2. **`git diff src/` 为空。**
 
 第二条为否,即"这条架构主张在第一个陌生厂商面前就没成立"。这个结论比移植成功更有
@@ -639,3 +682,4 @@ C6 值得单独说明:它是这批里唯一无法在开发机上验证的判据
 | 初稿 | 四处通用缺口:`exports`、`link-flag`、包内布局、探测库。配置头与包内布局在核实 main 后各自缩小 |
 | 修订一 | 两处判断被推翻并就地更正:**RDC 归插件侧,引擎零改动**(§0.2);**stdpar 可岛化,初稿的"互斥"说法过头**(§8.1)。新增三处缺口(§6)、归属规则(§7)、编程模型三分法(§8)、术语对齐建议(§9)、以及用陌生厂商证伪的实验(§10) |
 | 修订二 | §10 的三处不确定实地调研(§10.3),两处证实一处未证实。第三处更正:**"有硬件或模拟器"不是开工硬闸**,架构验证完全在构建期(§10.4);真实前置只有毕昇的合规取得。新增两条实测结论:`cpu` 模式**不走岛**因而不能充当设备判据(§10.3.1),以及 CMake 把 Ascend C 当作一门语言 —— 同一条轴、不同归属的第三方佐证(§10.3.4) |
+| 修订三 | §10.3.3 的结论被**推翻**:工具包官方镜像 `swr.cn-south-1.myhuaweicloud.com/ascendhub/cann` **可匿名拉取**(走完 token 握手实测),且从厂商自有 registry 取正落在不变量允许的一档。同时纠正一个框架错误:毕昇与模拟器**在同一个包里**,是一个获取问题不是两个。**至此该实验没有阻碍项。** 另记 AscendNPU IR 已开放,规则包存在第二个切入高度(§10.3.3b) |