@kernaut/kernaut-resources 0.1.17-beta.1 → 0.1.18

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/memory/contiguous-sentinel-initialization/techniques.md

@@ -1,50 +0,0 @@
----
-id: technique-ascendc-contiguous-sentinel-initialization
-knowledge_id: knowledge-bulk-contiguous-gate-initialization
-knowledge_id_source: agent-semantic-link
-knowledge_scope: conditional-general
-verified_operators: [na3d_varlen_forward]
-condition_ids: [condition-e0d488667ed48490]
-title: "AscendC：连续布局的 sentinel 矩阵优先整块初始化"
-type: technique
-vendor: ascend
-architectures: [ascend910b]
-soc: [ascend910b2c]
-languages: [ascendc]
-confidence: source-reported
-evidence_level: measured
-cann_version: "9.0.0"
-reproducibility: snippet
-prerequisites: []
-sources: []
-scope: "sentinel、gate、score 或 accumulator 矩阵在全局内存中连续布局，且消费者依赖整块完成事件"
-tags: [ascendc, ai-core]
-related:
-  - exp-ascend-na3d-bulk-gemm-gate-stamp
-  - technique-ascendc-datacopypad-burst-cost
----
-
-# AscendC：连续布局的 sentinel 矩阵优先整块初始化
-
-## 核心做法
-
-如果 sentinel、gate、score 或 accumulator 矩阵在全局内存中连续布局，可将逐行分配、填充和 DMA 合并为一次连续区域初始化，再保留原有覆盖范围和完成事件。
-
-## 作用机制
-
-整块写入可以减少逐行队列往返、DMA 描述和循环控制开销。它只改变初始化的组织方式，不应改变消费者看到的有效范围、默认值或同步时序。
-
-## 适用边界
-
-该做法要求布局确实连续，且整块写入不会覆盖尚未生产或仍被其他消费者使用的数据。非连续布局、不同步协议或按行独立生命周期的缓冲区不能直接套用。
-
-## 证据边界
-
-当前性能证据来自 `na3d_varlen_forward` 的 AscendC 实现，收益较小但方向明确。它是可迁移的条件性主题知识，不是已经跨算子验证的普遍性能结论。
-
-```cpp
-uint32_t elements = rows * width;
-Duplicate(ubSentinel, initValue, elements);
-DataCopyPad(gmSentinel, ubSentinel, elements * sizeof(T));
-SetFlag(doneEvent);
-```

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/memory/datacopypad-burst/techniques.md

@@ -1,110 +0,0 @@
----
-id: technique-ascendc-datacopypad-burst-cost
-title: "Ascend C DataCopyPad — Pricing the Per-Burst Fixed Cost"
-type: technique
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910c
-languages:
-- ascendc
-cann_version: '9.1.0'
-scope: >-
-  Historical AAP3D observations across 30-508 B and a KB-scale counterexample.
-  Per-burst figures are contextual back-solves, not isolated API latency.
-  The reported 1.8 ns normalization lacks a recovered loop/CSV in CB-04.
-tags:
-- ascendc
-- ai-core
-- ub
-- discrete-memory-access
-- double-buffering
-hardware_features:
-- ai-core
-- ub
-techniques:
-- discrete-memory-access
-- double-buffering
-confidence: experimental
-evidence_level: measured
-reproducibility: snippet
-prerequisites:
-- hw-ascend910b2c
-related:
-- pitfall-ascendc-gm-scalar-store-granularity
-- technique-ascendc-vector-repeat-granularity
-sources:
-- exp-ascend910c-datacopypad-burst-cost
-source:
-- path: sources/experience/ascend-campaign/ascend910c-datacopypad-burst-cost.md
-  anchor: Readings
-aliases:
-- "DataCopyPad 小 burst 固定代价"
-- "少 burst 不是无条件方向"
----
-
-> [CB-04 后置限定](../../../experience/cb04-aap3d-packing.md)：下文 55–102cycles、37–53ns 均是原 tiny 工作点的反推，不是 API 固定单价。KB对照8.40→8.70µs保留；1.8ns是未恢复完整循环的报告归一化，不能用.30µs/31替代。将device time除burst数只能给复合平均，不能仅凭恒定就唯一识别issue成本；调用数、缓存、同步和工作量另核。
-
-## The cost model
-
-A `DataCopyPad` burst carries a fixed issue cost of **55–102 cycle that does not
-depend on how much it moves**. Two independent back-solves on different shape sets
-(30–124 B and 30–508 B) saw no length dependence inside that window.
-
-The consequence is structural rather than incremental. If one burst carries one
-input row, the burst count is **identically `nc·D·H`** — it does not move when you
-retile, when you remove barriers, or when you save UB round-trips. Nothing that
-leaves the row-per-burst structure alone can reach it.
-
-## The restructuring
-
-Carry a **contiguous run of rows in one burst**, dropping the per-row alignment,
-and buy the alignment back with a single `Gather`:
-
-```cpp
-// BEFORE — one burst per row: bursts = nc * D * H, each 30-124 B
-for (uint32_t h = 0; h < H; ++h) {
-    DataCopyPad(ubIn[h * alignedW], gmIn[(base + h) * W],
-                {1, static_cast<uint16_t>(W * sizeof(T)), 0, 0}, padParams);
-}
-
-// AFTER — one burst per contiguous run of rows, then one Gather to
-// re-impose the 32 B row alignment inside UB.
-DataCopyPad(ubPacked, gmIn[base * W],
-            {1, static_cast<uint16_t>(H * W * sizeof(T)), 0, 0}, padParams);
-Gather(ubIn, ubPacked, rowOffsets, 0, H * W);
-```
-
-Measured effect on the operator this was found on: burst count down **31–71×**, the
-single largest improvement of that round.
-
-## The ceiling — read this before generalizing
-
-A control experiment held bytes and UB constant and changed only burst structure:
-
-| Regime | Cost per burst |
-|---|---:|
-| small burst (30–508 B) | 37–53 ns |
-| **1 × 64 KB → 32 × 2 KB** | **≈1.8 ns** (+0.30 µs total) |
-
-A variant that cut burst count 32× at KB scale measured **−0.09** — a loss.
-
-> "Fewer bursts" is not an unconditional optimization. It is a statement about a
-> regime, and the regime boundary is roughly one DMA transaction.
-
-## Two negatives that locate the cost
-
-- Removing a whole-block UB copy: **+0.01**, inside noise. In the small-burst
-  regime the cost is in burst *issue*, not in UB traffic.
-- Four independent instruction-count reductions: +0.03 / +0.02 / +0.01 / −0.02,
-  all noise — while the same change **plus double buffering** was **+0.21**.
-  Barriers are cheap; stalling DMA behind compute is not.
-
-## How the number was obtained
-
-Not from documentation and not from a microbenchmark: divide each case's measured
-device time by its burst count (`units/core × bursts/unit`). If the quotient is
-constant across shapes, that constant is the per-burst cost. This works on any
-operator whose per-case device times are already being collected, costs nothing
-extra to run, and yields the number in the same units the evaluation measures.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/memory/gather-dma/hardware.md

@@ -1,74 +0,0 @@
----
-id: hw-ascend-gather-dma-issue-bound
-title: "Gather Is DMA-Issue Bound, Not Bandwidth Bound — ~26 cycle per Row"
-type: hardware
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-evidence_level: measured
-cann_version: '9.1.0'
-confidence: experimental
-aliases:
-- gather issue rate
-- discrete DMA
-- "gather 发射条数受限"
-- "不是带宽受限"
-- "地址仿射化"
-tags:
-- ascendc
-- ai-core
-- ub
-- attention
-scope: >-
-  Measured at 48 AIV on rows small enough that the transfer is not the cost. At large
-  row sizes the transfer term takes over and the issue rate stops being the limit -
-  the same regime boundary as the per-burst cost of DataCopyPad.
-hardware_features:
-- ai-core
-- ub
-kernel_types:
-- attention
-related:
-- technique-ascendc-datacopypad-burst-cost
-- pitfall-ascendc-matmul-c-to-ub-direct-launch
-sources: []
----
-
-## The rate
-
-**≈3.3e9 rows/s at 48 AIV**, i.e. about **26 cycle per row**, and **nearly
-independent of the bytes per row**.
-
-## Two consequences that follow directly
-
-**Swapping `DataCopy` for `DataCopyPad` does not help.** Measured, it is *slower* —
-one case's gather went 6043 → 6887 cycle. The intuition that "the Pad variant carries
-extra overhead" is wrong here; both are issue-bound and the difference is elsewhere.
-
-**What can be saved is issue count, not bytes.** The two changes that worked:
-
-1. **Whole-block DMA at the edges** — merge several rows into one transfer.
-2. **Affine addressing** — `key_base + s2 * key_step`, hoisting two multiplies out of
-   the row loop.
-
-```cpp
-// BEFORE — one issue per row, address recomputed each time
-for (uint32_t s = 0; s < n; ++s)
-    DataCopy(ub[s * Dk], keyGm[(base + idx[s]) * Dk], Dk);
-
-// AFTER — affine address, and contiguous runs merged into one issue
-const uint64_t keyBase = base * Dk, keyStep = Dk;
-for (uint32_t r = 0; r < runs; ++r)
-    DataCopy(ub[runOff[r]], keyGm[keyBase + runStart[r] * keyStep], runLen[r] * Dk);
-```
-
-Together these took one case's gather from **9127 to 5034 µs**.
-
-This is the same regime argument as
-[`technique-ascendc-datacopypad-burst-cost`](../datacopypad-burst/techniques.md):
-below one transaction the issue path is the cost, so the lever is the number of
-issues, and above it the lever is bytes.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/memory/gm-scalar-store/pitfalls.md

@@ -1,86 +0,0 @@
----
-id: pitfall-ascendc-gm-scalar-store-granularity
-title: "Scalar __gm__ Stores Write Back 64 Bytes — Cores Clobber Each Other"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910c
-languages:
-- ascendc
-cann_version: '9.1.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  AIV cores writing through a __gm__ pointer with plain scalar stores. DataCopyPad
-  writes were the control and were unaffected. A single-block kernel cannot show
-  the effect at all, which is why it survives most local test sets.
-tags:
-- ascendc
-- ai-core
-- vector-unit
-hardware_features:
-- ai-core
-- vector-unit
-related:
-- technique-ascendc-datacopypad-burst-cost
-source:
-- path: sources/experience/ascend-campaign/ascend910c-gm-scalar-store-granularity.md
-  anchor: What was run
-aliases:
-- "标量写 GM 64 字节回写粒度"
-- "两核写同一条 line 互抹"
----
-
-## P1. Two cores writing different words of the same cache line erase each other
-
-**Symptom.** Intermittent lost writes. Same binary, same input, a different set of
-slots wrong on each run. Downstream this shows up as garbage aggregates
-(`count out of range: 4.5e18`), as a crashed card, or — worst — as a test set that
-passes 24 times out of 26.
-
-**Cause.** On AIV, a plain scalar store through a `__gm__` pointer has a **64-byte
-write-back granularity**. Two cores writing different words of one line write back
-the whole line, each erasing the other's word.
-
-**Dose response** (48 blocks, one `int64` each, everything else held fixed):
-
-| Only the stride changes | visible writes | | Only the write method changes | visible writes |
-|---|---:|---|---|---:|
-| 8 B | **20/48** | | scalar store | 24/48 |
-| **64 B** | **48/48** | | **`DataCopyPad`** | **48/48** |
-| 512 B | 48/48 | | | |
-
-**Fix — either one works:**
-
-```cpp
-// (a) Pad any per-block array to one cache line per entry.
-constexpr uint32_t kLine = 64 / sizeof(int64_t);   // 8 slots
-countsGm.SetValue(GetBlockIdx() * kLine, localCount);
-
-// (b) Or write it with DataCopyPad, which is byte-granular and is visible
-//     to both scalar and DMA readers.
-DataCopyPad(countsGm[GetBlockIdx()], ubCount, {1, sizeof(int64_t), 0, 0});
-```
-
-Option (b) is often also the faster one: a random scatter can be bucketed locally
-in UB and then issued as contiguous runs, which is simultaneously the correctness
-fix and the performance fix.
-
-## P2. `DataCacheCleanAndInvalid` is not the remedy, and makes it worse
-
-Visible writes went **26 → 15** (dcci on the reader only) **→ 10** (dcci on both
-sides). A dcci-everywhere tree was still wrong *and* crashed the card (`507035`).
-Reaching for a cache maintenance intrinsic here treats the symptom as coherence
-when it is granularity.
-
-## P3. Why a passing run proves nothing
-
-`int32[blocks]` packs **16 blocks into one line**; `int64[blocks]` packs 8. Public
-case sets usually contain only one or two cases with `blocks != 1`, so the observed
-failure rate is low — one operator failed 2 runs in 26.
-
-> Whenever you see **multiple cores + a small array indexed by block + intermittent
-> wrongness**, check this first. A single green run is not evidence; sweep
-> `blocks = 1 / 7 / 20 / 48` and compare.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/memory/l2-cache-hint/techniques.md

@@ -1,80 +0,0 @@
----
-id: technique-ascendc-l2-cache-hint
-title: "SetL2CacheHint Bypass — Biggest Single Memory Win, and the Threshold Must Be Measured"
-type: technique
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.0.0'
-evidence_level: measured
-confidence: experimental
-reproducibility: snippet
-scope: >-
-  Streaming inputs read exactly once, on a part with a 192 MB L2. The thresholds are
-  on host-computed TOTAL traffic, not per tensor, and are far above L2 capacity - they
-  do not transfer to a part with a different L2 and must be re-measured. Bypassing the
-  output write is a regression in every case measured.
-tags:
-- ascendc
-- ai-core
-- ub
-- cache-policy
-hardware_features:
-- ai-core
-- ub
-techniques:
-- cache-policy
-prerequisites:
-- hw-ascend910b2c
-related:
-- technique-ascendc-datacopypad-burst-cost
-sources:
-- exp-ascend910b2c-memory-and-arith-techniques
-source:
-- path: sources/experience/ascend-campaign/ascend910b2c-memory-and-arith-techniques.md
-  anchor: 'L2 bypass: the threshold is far above L2 capacity'
-aliases:
-- "SetL2CacheHint 分档"
-- "阈值必须实测"
-- "L2 bypass"
----
-
-## What it does
-
-A purely streaming input — every element read once — has no reuse to gain from L2,
-and occupying L2 displaces the output write-back. Telling the read path to bypass:
-
-```cpp
-template <typename G> __aicore__ inline void HintStreamRead(G &g) {
-    g.template SetL2CacheHint<AscendC::CacheRwMode::READ>(
-        AscendC::CacheMode::CACHE_MODE_DISABLE);
-}
-```
-
-Measured: 224→197 µs and 292→261 µs, effective bandwidth **1.5 → 1.9 TB/s**.
-
-## The threshold is far above L2, and below it the hint is harmful
-
-Gate it on host-computed **total** traffic:
-
-| Total traffic | Bypass |
-|---|---|
-| ≥ 280 MB | ✅ consistently helps |
-| 210–220 MB | ❌ slower |
-| ≤ 42 MB | ❌ **40% slower** — 15.4 vs 11.0 µs |
-
-L2 is 192 MB, so the useful threshold sits at roughly 1.5× capacity, not at it. Below
-42 MB the line fill is functioning as a prefetcher and disabling it removes that.
-
-> The shape of this is the general point: a cache hint is not a monotone knob. It has
-> a regime where it helps and a regime where it hurts, and the boundary is not the
-> cache size.
-
-## Two settings that were measured and rejected
-
-- **Bypassing the output write** — 197→252 µs. Writes must stay in L2.
-- **`CACHE_MODE_LAST`** — a wash, within noise on every case.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/memory/ub-buffer-hazards/pitfalls.md

@@ -1,70 +0,0 @@
----
-id: pitfall-ascendc-ub-buffer-hazards
-title: "Three Silent UB Hazards — Brcb Width, Queue Direction, Duplicate Offset"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910b2c
-languages:
-- ascendc
-cann_version: '9.0.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  DAV_2201 UB. All three are silent in the sense that nothing reports them at the
-  point of the mistake; two show up as wrong data and one as a runtime error far from
-  its cause.
-tags:
-- ascendc
-- ai-core
-- ub
-- vector-unit
-hardware_features:
-- ai-core
-- ub
-- vector-unit
-related:
-- pitfall-ascendc-alignment
-- pitfall-ascendc-gm-scalar-store-granularity
-aliases:
-- "Brcb 每拍写八个 block"
-- "VECIN 队列"
-- "Duplicate 偏移 32B 对齐"
----
-
-> [CB-03 路径限定](../../../experience/cb03-roi-gqa-layout-boundaries.md)：P3 的 GQA 旧因果实例在未实例化的 BatchedSoftmax 路径；强制走该路并对齐后通过，但三个测量点分别慢 97%/71%/40%。这不能证明当前 hidden 失败根因；当前 pack 的 rowBytes 与 Nd2Nz 字段宽度另查。队列也要按真正消费者选事件，纯 GM→UB→GM 拷贝不能照搬 MTE2→V 的依赖。
-
-## P1. `Brcb` writes 8 blocks per beat regardless of `n`
-
-Allocate `ceil(n/8)*8` blocks at the destination. Sizing it by `n` — at `n = 1` that
-is a single 32 B block — lets it **write 224 B past the end**, into whatever buffer
-comes next.
-
-## P2. A GM→UB load must go through a `VECIN` queue
-
-Use a `VECOUT` queue and `EnQue`/`DeQue` carry a `V→MTE3` event instead of `MTE2→V`.
-The `Cast` then reads stale data **before the DMA lands**.
-
-The symptom is "occasionally a bit off", not a stable wrong answer, which makes it the
-hardest of the three to find. The queue direction is the only thing that distinguishes
-the two cases in the source.
-
-## P3. A `LocalTensor` offset for `Duplicate` must also be 32 B aligned
-
-`Duplicate(t[2045], …)` raises `507035`. The correct way to clear a tail is to start
-from `valid & ~7`, zero from there, and let the subsequent computation overwrite the
-still-valid part.
-
-```cpp
-// WRONG — 2045 is not a multiple of 8 elements, so the byte offset is unaligned
-Duplicate(t[valid], 0.0f, n - valid);
-
-// RIGHT — round the start down to the alignment, then recompute over the overlap
-const uint32_t clearFrom = valid & ~7u;
-Duplicate(t[clearFrom], 0.0f, n - clearFrom);
-```
-
-See also [`pitfall-ascendc-alignment`](../alignment/pitfalls.md), which is the same
-constraint arriving through a different API.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/memory/uninitialized-ub-and-padvalue/pitfalls.md

@@ -1,77 +0,0 @@
----
-id: pitfall-ascendc-uninitialized-ub-and-padvalue
-title: "Unwritten UB Bytes and Unset padValue Read as Whatever the Last Kernel Left"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910c
-languages:
-- ascendc
-cann_version: '9.0.1'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  Any tile whose written extent is smaller than its allocated extent - tail
-  blocks, masked lanes, early-exit paths. It does NOT apply where every element
-  of the buffer is written on every pass, which is why aligned shapes hide it.
-tags:
-- ascendc
-- vector-unit
-related:
-- pitfall-ascend-torch-npu-toolchain-surface
-sources:
-- exp-ascend910c-target-env-divergence
-aliases:
-- "UB 没清零 换环境就错"
-- "DataCopyPad 没设 padValue"
-- "尾块残留值"
-- "本地恰好是 0"
----
-
-> [CB-03 证据限定](../../../experience/cb03-reference-and-special-values.md)：未初始化读取是排查假设，不能仅凭换环境后失败就认定此因。D4 实际只做正逆序位串，未做 UB 投毒；GS3D 的投毒失败还可能来自错误写入。下文初始化方法须按实际 API 重载、填充和有效读取范围验证，不把默认内存为零或每次遗留相同值视为平台保证。
-
-# Residual UB Is Not Zero, It Is Whatever Ran Before
-
-## Symptom
-
-Correct at your desk, wrong on another machine, with the same binary and the
-same input. The wrong elements sit at the tail of a tile, or in lanes a mask
-excluded.
-
-## Mechanism
-
-Two sources, same shape:
-
-1. **A UB buffer that is allocated but not fully written.** The bytes you did
-   not write hold what the previous kernel left there. On a quiet development
-   machine that is very often zero, and zero is usually the value that makes the
-   arithmetic come out right — so the bug is *masked by the environment*, not
-   absent.
-
-2. **`DataCopyPad` without an explicit `padValue`.** The padded lanes of a
-   non-aligned tail come from the same place.
-
-Neither has a local trigger. The initial memory contents are constant at your
-desk and different on the target, which puts this in the same family as the
-core-count and toolchain-release divergences: **a defect whose triggering
-condition is held constant by the environment you test in.**
-
-## Fix
-
-```cpp
-constexpr float kPoison = -3.0e38f;
-AscendC::Duplicate(local, static_cast<T>(0), tileElements);   // whole tile
-AscendC::DataCopyPadExtParams<T> pad{true, 0, 0, static_cast<T>(0)};
-```
-
-Initialise the full allocated extent, not the written extent, and always give
-`DataCopyPad` a pad value — the default is not a promise.
-
-## How to find it without the other machine
-
-Fill the buffer with a poison value instead of zero before the kernel writes it
-(`kPoison` above). Anything that reads an unwritten byte then produces an
-obviously wrong number locally, on the first run. Zero-initialising hides the
-same bug; poison exposes it.

package/resources/kop-2026-10-23-0.1.17-beta.1/product_capabilities/kernel_optflow/skills/KernelWiki-private/wiki/ascend/foundations/meta/host-api-lowering/pitfalls.md

@@ -1,83 +0,0 @@
----
-id: pitfall-ascendc-host-op-aclnn-lowering
-title: "Host Tensor Factories Lower to aclnn — Passes Locally, Fails on the Runner"
-type: pitfall
-vendor: ascend
-architectures:
-- ascend910b
-soc:
-- ascend910c
-languages:
-- ascendc
-cann_version: '9.1.0'
-evidence_level: measured
-confidence: experimental
-scope: >-
-  Applies where the target runtime forbids aclnn single-operator dispatch. On a
-  runtime that permits aclnn the same code is slower, not wrong. What transfers is
-  the class of defect - a host API that silently lowers to a forbidden kernel - not
-  the error code.
-tags:
-- ascendc
-related:
-- pitfall-ascendc-gm-scalar-store-granularity
-source:
-- path: sources/experience/ascend-campaign/ascend910c-host-api-aclnn-lowering.md
-  anchor: What happened
-aliases:
-- "torch zeros 下降成 aclnn"
-- "本地过 线上挂 561103"
----
-
-## P1. `torch::zeros` in a launch plugin is an `aclnn` call
-
-**Symptom.** 20/20 locally, **0/20** on the target runtime,
-`compile_runtime_error ... 561103`. Grepping the source for `aclnn` returns
-nothing.
-
-**Cause.** `torch::zeros` lowers to `aclnnInplaceZero`. The forbidden thing is a
-behaviour — an aclnn single-operator executing — and the source text never names it.
-
-**Fix.** Only `torch::empty` is safe: it allocates and dispatches no kernel. Zero
-the buffer with an Ascend C kernel instead.
-
-```cpp
-// WRONG — dispatches aclnnInplaceZero:
-auto y = torch::zeros({n}, opts);
-
-// RIGHT — allocate only, then zero it inside your own kernel
-// (Duplicate + DataCopyPad over a tile).
-auto y = torch::empty({n}, opts);
-```
-
-Same mechanism, same ban: `torch::{zeros, ones, full, rand, randn, arange,
-linspace, eye}` and their `*_like` forms; `.zero_() / .fill_() / .copy_() /
-.clamp_() / .masked_fill_()`; `torch::{cat, stack, clone, matmul, mm, bmm, softmax,
-transpose, permute, reshape, view}`; `.cpu() / .item()`. `.contiguous()` is a
-warning, not a fatal — it dispatches only on a transposed or non-contiguous view.
-
-## P2. Switching to `torch::empty` can expose a masked defect
-
-`torch::empty` leaves the buffer uninitialized, so any path that reads before
-writing becomes visible. In the observed case the fp16 path did not run the shift
-kernel while softmax unconditionally read that block; local memory residue happened
-to be zero, so it surfaced as a puzzling local **19/20** rather than as a clear
-failure.
-
-Audit every output for an unconditional writer on every path before making this
-substitution.
-
-## P3. `torch::empty` cannot be called inside the launch callback
-
-Calling it from within the `RunOpApi` callback makes every kernel after the first
-in-gate case fail `507057`. Allocate outside the callback.
-
-## P4. The check has to match the rule's shape
-
-The rule is behavioural ("no aclnn single-operator may execute"); a `grep aclnn` is
-textual. The distance between the two is exactly where this escaped, and finding it
-cost two full remote validation cycles.
-
-> When writing a static check for a behavioural ban, ask how many spellings evade
-> your pattern, enumerate them, and give the scanner a **positive control** — an
-> input it must flag — so that a silent scanner cannot be mistaken for a clean tree.