docs(plan): sim mode does invoke bisheng, measured in vendored cmake

Closes the last open question in section 10. It was recorded as inference; it
is now source.

asc-devkit vendors the toolkit's own ASC_CMake under tools/ascc/cmake/, so the
device compile path is readable without pulling the image:

    CMakeDetermineASCCompiler.cmake:47
        find_program(CMAKE_ASC_COMPILER NAMES "bisheng" PATHS ".../ccec_compiler/bin/")
    CMakeASCInformation.cmake:49
        CMAKE_ASC_COMPILE_OBJECT = "<CMAKE_ASC_COMPILER> ... -c -x asc <SOURCE>"
    host_config.cmake:69
        CCEC_LINKER = <toolkit>/ccec_compiler/bin/ld.lld

The decisive one is negative evidence: every RUN_MODE test in the repository is
STREQUAL "cpu". There is no sim branch anywhere. Build-time therefore
distinguishes only cpu from not-cpu, so sim takes the same path as npu and
bisheng is invoked. The two differ at run time -- which runtime and simulator
libraries load -- not in the build graph. The one extra action on the non-cpu
branch is update_host_stub.py, which generates host-side launch stubs, and a
launch stub exists precisely because there is a real device binary to start.

Worth keeping the reason the question was asked: the opposite design is real
and has good reasons behind it, since instruction-level simulation is orders of
magnitude slower than host code and a host compiler gives gdb and ASAN. CANN
split those concerns instead -- cpu mode IS that design, so sim would duplicate
it unless it executed real device instructions. Three modes rather than two is
itself the answer.

Section 10 now has no open items.

Author: speak-agent

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

@@ -492,10 +492,27 @@ Ascend C 有**三种**运行模式,经 `-DCMAKE_ASC_RUN_MODE=` 选择:
 **不是岛的机制对** —— 它没走那条路径。这正是本仓库反复付学费的形态:判据施加在
 错误的对象上。
 
-`sim` 模式则保留岛。**这一条是推断而非实测**,依据有二:它被称为"NPU 仿真"且用于
-验证 NPU 上的正确性;msOpProf 的 Simulator 模式采集**指令流水**数据,而指令流水只有
-在真正执行设备指令时才存在。**实现时必须先确认这一条**,方法是检查 `sim` 模式下
-是否仍调用 `bisheng`。
+`sim` 模式保留岛。**这一条已由源码证实,不再是推断**(`asc-devkit/tools/ascc/cmake/`
+与 `cmake/asc/legacy_modules/`):
+
+| 证据 | 内容 |
+|---|---|
+| `CMakeDetermineASCCompiler.cmake:47` | `find_program(CMAKE_ASC_COMPILER NAMES "bisheng" PATHS ".../ccec_compiler/bin/")` |
+| `CMakeASCInformation.cmake:49` | `CMAKE_ASC_COMPILE_OBJECT = "<CMAKE_ASC_COMPILER> … -c -x asc <SOURCE>"` |
+| `host_config.cmake:69` | `CCEC_LINKER = <toolkit>/ccec_compiler/bin/ld.lld` —— 设备侧链接 |
+| **全仓 `RUN_MODE` 判断** | **每一处都是 `STREQUAL "cpu"`,不存在 `sim` 分支** |
+
+最后一行是决定性的:构建期只区分 `cpu` 与**非** `cpu`,因此 **`sim` 与 `npu` 走完全
+相同的编译路径**,bisheng 被调用,岛成立。两者的差别在**运行期**(加载哪套运行时 /
+仿真库),不在构建图。
+
+分支点上唯一的额外动作是:非 `cpu` 分支多跑一个 `update_host_stub.py` —— 生成宿主侧
+的启动桩,而那正是"存在一个真实设备二进制需要被拉起"的标志。
+
+**为什么这个疑问值得问。** 反过来的设计是存在的,而且有正当理由:指令级仿真比跑宿主
+代码慢几个数量级;宿主编译器能给 gdb / ASAN / printf。CANN 的选择是把这两种诉求拆开
+—— `cpu` 模式**就是**那个设计,所以 `sim` 若不执行真实设备指令便与 `cpu` 重复,没有
+存在的理由。三种模式而非两种,本身就是答案。
 
 #### 10.3.2 算子注册元数据:JSON,且按 SoC 分(证实)
 
@@ -603,16 +620,16 @@ Triton IR → Linalg IR → AscendNPU IR → 算子二进制,配套 `triton-asce
 
 **没有阻碍项。** 初稿列的三条前置里,两条证实、一条被推翻;剩下的都是工程量。
 
-实现前仍需确认的只剩一条技术问题:**`sim` 模式是否仍调用 `bisheng`**(§10.3.1),
-因为它决定设备执行判据落在哪个对象上。
+**没有待确认的技术问题。** 初稿留的最后一条(`sim` 是否仍调用 `bisheng`)已由源码
+证实为"是"(§10.3.1)。
 
 ### 10.5 裁决判据
 
 阶段一(`rules-ascendc` + 一个 hello kernel)两条,第二条是重点:
 
 1. 在 `sim` 模式下跑出正确结果,**断言设备名/执行路径而非结果数值**(数值在 `cpu`
    模式与静默回退时同样正确)。**不得用 `cpu` 模式充当这条** —— 理由见 §10.3.1。
-   前置:先确认 `sim` 下仍调用 `bisheng`,否则这条判据与 `cpu` 模式等价而无效。
+   `sim` 调用 `bisheng` 已证实(§10.3.1),因此这条判据落在正确的对象上。
 2. **`git diff src/` 为空。**
 
 第二条为否,即"这条架构主张在第一个陌生厂商面前就没成立"。这个结论比移植成功更有
@@ -683,3 +700,4 @@ C6 值得单独说明:它是这批里唯一无法在开发机上验证的判据
 | 修订一 | 两处判断被推翻并就地更正:**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) |
+| 修订四 | 最后一条待确认项闭合:`sim` **确实调用 bisheng**,由 `asc-devkit` 内 vendored 的 `ASC_CMake` 证实 —— ASC 是一门 CMake 语言,其编译器就是 `bisheng`,且**全仓 `RUN_MODE` 判断只区分 `cpu` 与非 `cpu`,不存在 `sim` 分支**。至此 §10 无待确认项 |