@cannbot-plugin/cannbot-harness 0.0.0-stage → 0.1.5

package/assets/ops-direct-invoke/skills/ascendc-blaze-best-practice/references/workflow/step2-blaze-investigation.md

@@ -0,0 +1,192 @@
+# Step 2: Blaze Investigation
+
+> **定位**：从最高层 `project_root` 发现并只读验证 `<project-root>/ops-tensor/`，围绕需求语义建立可核验的源码事实报告。设计请求可以跳过 Step 1；Step 2 不依赖 Step 1 文件产物，不推荐项目方案、不匹配场景、不选择路线、不编译或运行设备。
+
+## 1. 输入、输出与边界
+
+```text
+输入：project_root、operator_name、用户需求、target_chip、npu_arch；可选 cann_version、Step 1 抽象版本记录、Step 3 语义化补充调查问题
+blaze_source_root：<project-root>/ops-tensor/
+operator_root：<project-root>/operators/<operator_name>/
+输出：operators/<operator_name>/docs/blaze/blaze-investigation-report.md
+模板：/ascendc-blaze-best-practice/references/blaze-investigation/investigation-report-template.md
+```
+
+- 从 `project_root` 和 `operator_name` 派生全部路径。没有 Step 1 handoff 时，自行只读建立相同的抽象源码一致性记录；有 handoff 时核对当前 checkout 与记录一致。
+- 写报告前只创建 `<project-root>/operators/<operator_name>/docs/blaze/` 及缺失的父目录；这不建立 Step 1 的工程骨架，也不创建任何实现文件。
+- 确认 `ops-tensor/` 和 `operators/` 同级，remote 指向授权仓库，当前 worktree/branch 可核验，必要递归 submodule 已初始化且与父仓 gitlink 一致。
+- 源码或 submodule 缺失、不一致时停止，给出由 Step 1 或 direct init 恢复的条件；不得在 Step 2 clone、pull、checkout、切换版本或执行 submodule update。
+- 只读核对项目内 `op_kernel/include/blaze/`、`tensor_api/` 是否存在且与当前根源码同源。设计请求跳过 Step 1 时，副本缺失不阻塞 Investigation，也不由 Step 2 复制；在报告中记录 `missing_for_exact_materialization`，由 Step 3 为实施阶段编译一次性原样物化 action。已存在但来源或内容不一致则记录 `blocking`。
+- 不回退搜索 `operators/<operator_name>/`、其他项目或历史工程中的 ops-tensor。
+- 调查范围来自数学语义、dtype、format、layout、topology、shape、额外输入输出和明确约束，而不是预设场景名称。
+- Blaze 源码事实只来自当前 `<project-root>/ops-tensor/` 的源码、官方文档、example 和 UT。Asset、项目实现、其他 Skill 和历史验证工程都不是 Blaze 源码能力证据。
+- 不读取 `references/scenarios/index.md`、任何场景设计/开发指导或依赖 Skill；Step 2 不知道项目是否将采用定制场景。
+- 不读取 `environment.md`、外部 workflow manifest、DESIGN/PLAN 模板或其他 direct invoke 产物。芯片事实必须由输入直接提供，不追溯外部工作流文件。
+- 根 `ops-tensor` 始终只读；项目内官方副本存在时只读核对，缺失时只记录物化状态。候选扩展必须有边界；同一 Investigation 报告最多接受一次来自 Step 3 的补充调查。
+- 报告版本字段使用当前自检或 Step 1 handoff 的抽象版本记录；不得写实际提交 ID、manifest/hash、文件哈希、构建时间戳或具体提交节点。源码变化会使已有 Investigation 失效。
+
+## 2. 五阶段 Runbook
+
+| 阶段 | 必读文档 | 动作 | 报告写入 | 停止条件 |
+|---|---|---|---|---|
+| 0. 建立调查 Brief | [报告模板](../blaze-investigation/investigation-report-template.md) | 派生路径并只读自检 Blaze 源码；将需求投影为分区、约束、问题和读取边界 | 路径/版本状态、需求投影、调查范围、补充范围 | 源码缺失/不一致或需求语义不足时停止 |
+| 1. 候选组装方案发现 | [Blaze 源码调查方法](../blaze-investigation/source-investigation-method.md) | 先从 example/UT/真实 Kernel 入口找种子，再回到定义与 specialization | 候选目录、发现证据、读取边界 | 每个已调查语义有 found/not_found/unknown 记录 |
+| 2. Blaze 组装方案闭合 | [Blaze 组装方案恢复方法](../blaze-investigation/assembly-recovery-method.md) | 依真实调用恢复 Kernel、Policy、BlockMmad、BlockScheduler、可选 Epilogue、Tiling/Params | 具体证据、成员链、结构状态 | 每条候选标为 complete/partial；禁止名称拼接 |
+| 3. 依赖与物理合同闭合 | [依赖追溯方法](../blaze-investigation/dependency-trace-method.md) | 只追踪候选实际消费的 Params、Tensor API、物理数据和 host/device ABI | 字段语义、API、物理数据、ABI、已观察限制和未闭合事实 | 调用点/定义点/字段语义闭合或明确 unknown |
+| 4. 证据审计与报告冻结 | [调查合同审计方法](../blaze-investigation/design-contract-method.md)、报告模板 | 审计证据、冲突、读取边界和未闭合事实 | 唯一事实报告、证据账本、补充记录 | 不产生支持、路线或场景结论 |
+
+只在进入对应阶段时读取该阶段文档。Step 2 不提前加载 DESIGN 模板、PLAN 模板、场景指导或依赖 Skill。
+
+## 3. 阶段 0：建立调查 Brief
+
+先只读核对根级源码：
+
+```bash
+git -C <project-root>/ops-tensor remote -v
+git -C <project-root>/ops-tensor status --short --ignore-submodules=none
+git -C <project-root>/ops-tensor submodule status --recursive
+git -C <project-root>/ops-tensor ls-tree HEAD include/tensor_api
+```
+
+不得在 Step 2 执行会改变 checkout 的命令。缺仓、remote 不匹配、未初始化 submodule、gitlink 不一致或布局不是 `ops-tensor/` 与 `operators/` 同级时停止，并将恢复目标指向 Step 1/direct init。
+
+从需求提取：
+
+```text
+request_summary
+math_contract
+tensor_roles_and_extra_io
+dtype_format_layout_constraints
+topology_and_shape_predicates
+runtime_compile_time_axes
+demand_partitions
+hard_constraint_manifest
+required_source_questions
+out_of_scope
+candidate_expansion_budget: 1
+supplement_scope: absent | one semantic request
+```
+
+Basic、Batch、Grouped、Quantized、MX、layout、transpose 和 shape 是可组合的需求画像。只有会改变真实入口、specialization、ABI 或物理数据合同的轴才拆分 demand partition；shape 用谓词域描述，不枚举用户未要求的数值。发现新的 compile-time 轴时，记录 `brief_amendment`，使受影响事实重新核验，不能借拆分缩小用户范围。
+
+“额外输出后处理”“额外 operand”“广播关系”等只是需求语义探针：它们要求调查相关数据流、物理映射或 AIC/AIV 协作事实，但不对应注册场景，也不预测路线。
+
+### 补充调查
+
+Step 3 仅在缺少决定性 Blaze 源码事实时，向下一轮同一报告写入一次 `supplement_scope`。它必须包含：
+
+```text
+requested_by: Step 3
+attempt: 1
+affected_requirement_ids
+semantic_questions
+required_blaze_source_frontier
+why_decision_is_blocked
+```
+
+问题只描述待确认的需求语义、接口、物理数据或调用关系；不得出现场景 ID、场景文档路径、custom 路线或实现建议。补充完成后仍缺关键事实时，报告照实记录 `unresolved_source_facts`，由 Step 3 停止等待用户澄清。
+
+## 4. 阶段 1：候选组装方案发现
+
+按 [Blaze 源码调查方法](../blaze-investigation/source-investigation-method.md)：
+
+1. 从与需求语义相近的 example、UT 和真实 Kernel 入口寻找 using、alias、实例化及调用点。
+2. 回到公开定义解析 specialization、模板参数、Params 和架构守卫。
+3. 未找到执行种子时，才从目标公开 Kernel/Policy/Block 反向寻找实际 caller。
+4. 仅为解释真实调用而读取绑定官方 API 文档和构建文件。
+5. 不按相似文件名无边界扫描，也不把未引用组件拼成候选。
+
+每个候选记录：
+
+```text
+candidate_id
+investigated_partition_ids
+candidate_result: found | not_found | unknown
+concrete_entry_seed
+coverage: indexed | deep | out_of_scope
+applicability_observations
+source_refs
+```
+
+`not_found` 表示在已声明读取边界没有发现对应种子，不等于 Blaze 官方库不支持；`unsupported` 只能记录源码或官方约束明确拒绝的准确形态。
+
+## 5. 阶段 2：Blaze 组装方案闭合
+
+沿同一真实入口恢复实际调用链：
+
+```text
+Kernel entry
+  -> Policy / specialization / dispatch
+  -> BlockMmad
+  -> BlockScheduler
+  -> optional Epilogue
+  -> TilingData / Params / Tiling entry
+```
+
+每条候选绑定具体 witness、成员、适用 partition、结构状态和 source relationships。Grouped Plain、Grouped Quantized、Grouped MX 必须分别取得与激活分区一致的 witness，不能用 Grouped MX 代替其他模式。
+
+候选不能闭合时，只允许一次有边界的扩展：先检查同一真实入口的另一 specialization，再检查该入口实际引用的同族组件。扩展后仍不能确认时保留 `partial` 或 `unknown`，不猜测模板参数或组件组合。
+
+## 6. 阶段 3：依赖、物理数据与 ABI
+
+只追踪已闭合候选实际消费的依赖。每个 Scheduler/Block/Policy/Kernel/Epilogue 字段记录：
+
+```text
+field_path
+field_type_and_unit
+consumer_and_semantics
+legal_domain_or_predicate
+cross_field_constraints
+tilingdata_mapping
+observed_value_scope
+evidence_refs
+evidence_status: source_observed | documented | example_assembled | conflict | unknown | unsupported
+```
+
+同时记录实际 Tensor API 调用点与定义、Routing、location/layout/dtype、shape/offset/stride/extent/alignment 单位、逻辑/物理转换、buffer/workspace 生命周期、Kernel entry、GM 参数、TilingData、grid 和 host ownership。不要建立 API 百科。
+
+没有现成 Blaze 源码 host Tiling 不阻塞调查。要闭合的是 Scheduler Params 的语义、合法域、约束和 ABI；`observed_value_scope` 只能说明源码观察到的值，不能替项目选择固定值。
+
+若需求要求 MatMul 输出后逐元素或 broadcast 数据处理，调查与已发现候选实际相关的输出位置、物理 mapping、完成时机、C+V/adapter/同步事实。不能从需求名称推断这些实现存在，也不能将其组织为场景 bundle。
+
+## 7. 阶段 4：证据审计与报告冻结
+
+按 [调查合同审计方法](../blaze-investigation/design-contract-method.md) 审计：
+
+- 每个调查问题都有事实、来源明确的限制、或 `unknown`；
+- 每个 concrete candidate 有真实入口、组件链、依赖与适用边界；
+- 已观察限制与未闭合事实分开记录；
+- `coverage` 只表示调查深度，`evidence_status` 只表示原子证据状态，`object_readiness` 只表示候选或证据对象的局部事实闭合度；三者均不构成官方支持、项目可执行性或项目路线结论；
+- 报告清楚列出实际读取根、未读取范围、候选扩展和补充调查历史。
+
+报告不得聚合为官方支持结论、可执行性、候选组合、场景 ID、场景 bundle 或项目路线。Step 3 依据精确需求重新评估这些事实；未调查不等于不支持，源码证据充分也不等于设备精度通过。
+
+## 8. 完成
+
+关闭报告前确认至少绑定：
+
+```text
+project_root
+operator_name
+operator_root
+report_path
+blaze_source_root
+target_chip
+npu_arch
+cann_version: <optional>
+investigation_id
+source_version_status
+checkout_consistency
+read_only_source_regions
+read_only_source_region_status
+read_only_source_region_evidence_refs
+source_refs
+candidate_evaluation_id
+assembly_witness
+assembly_members
+dependency_and_physical_data_facts
+abi_and_signature_facts
+unresolved_source_facts
+```
+
+报告只记录事实和缺失事实，不写 native/custom/unsupported 结论。核对模板、链接、读取边界、证据账本、未闭合事实和补充次数后进入 [Step 3: Kernel Design](step3-kernel-design.md)。

package/assets/ops-direct-invoke/skills/ascendc-blaze-best-practice/references/workflow/step3-kernel-design.md

@@ -0,0 +1,246 @@
+# Step 3: Kernel Design
+
+> **定位**：依据精确需求和 Step 2 的 Blaze 源码调查，完成唯一的项目路线决策，并生成冻结的项目设计与执行计划。本步骤不复制文件、不写实现、不构建项目或运行设备。
+
+## 1. Inputs and Outputs
+
+必须先读取：
+
+- 用户需求，以及调用上下文直接提供的 `project_root`、`operator_name`、`target_chip`、`npu_arch` 和可选 `cann_version`；
+- `operators/<operator_name>/docs/blaze/blaze-investigation-report.md`；
+- [Blaze DESIGN 模板](../kernel-design/blaze-design-template.md)；
+- [Blaze PLAN 模板](../kernel-design/blaze-plan-template.md)。
+
+Step 1 项目/版本 handoff 是完整四步流程的可选输入，不是设计请求的启动依赖。Step 3 不读取 `environment.md`、外部 workflow manifest 或其他 direct invoke 产物，也不重新大范围搜索 Blaze 源码；判断需要的源码事实缺失时，向 Step 2 提交一次精确的补充调查问题。
+
+正常完成后，输出固定写入当前项目：
+
+- `operators/<operator_name>/docs/DESIGN.md`：需求、接口、路线、最终组件/场景合同、资源数据同步、支持边界和验证合同；
+- `operators/<operator_name>/docs/PLAN.md`：仅可执行路线的精确资料、目标文件、有序动作、接线、checkpoint、交付、清理和回退。
+
+`unsupported` 只生成阻塞 `DESIGN.md`，不生成 `PLAN.md`。一次补充调查后仍缺关键事实时，不生成最终路线、DESIGN 或 PLAN，停止等待用户澄清。任何可写目标都不得位于 `<project-root>/operators/<operator_name>/` 之外。DESIGN/PLAN 的版本字段继承当前 Investigation 的抽象版本记录；不得写实际提交 ID、manifest/hash、文件哈希、构建时间戳或具体提交节点。
+
+## 2. Top-Down Design Workflow
+
+```text
+需求合同
+  -> 算子接口合同
+  -> 基于 Blaze 官方库的方案分析
+  -> 定制扩展场景匹配与设计（可选）
+  -> 最终合同装配
+  -> 验证合同
+  -> PLAN 编译与冻结
+```
+
+每个阶段记录输入、动作、输出和停止条件。前置合同未闭合时，不得跳到后续阶段。
+
+### 2.1 Requirements Contract
+
+从用户需求冻结可逐项核对的合同：
+
+- 数学公式、输入输出、dtype、累加和转换顺序；
+- topology、layout/transpose、shape/tail、运行时变化维度；
+- 额外输入输出、精度/资源目标、错误语义和排除范围；
+- demand partitions、硬约束和支持边界。
+
+Basic、Batch、Grouped、Quantized、MX 只是需求画像维度，不能从名称推导 Blaze 组件兼容性或项目路线。
+
+### 2.2 Operator Interface Contract
+
+先读取 Investigation 的物理/ABI事实、[MatMul Layout](../fundamentals/blaze-matmul-layout.md) 和 [Launcher 开发](../launcher/launcher-development.md)，再冻结外部逻辑接口及其接口到设备的映射草案。此阶段不从旧样例或未选 Kernel 签名反推用户接口。
+
+`operator_interface_contract` 必须记录：
+
+- 参数角色、顺序、逻辑 shape/dtype/layout；
+- 必选/可选/默认值、运行时/编译时归属；
+- host 调用、所有权、生命周期、错误和拒绝语义；
+- 每个输入、输出和辅助对象的物理数据前置条件。
+
+同时输出 `abi_mapping_draft`。每个逻辑参数或运行时辅助对象至少有一行：
+
+```text
+abi_mapping_draft_row_id
+logical_argument_id
+logical_role_and_requiredness
+logical_shape_dtype_layout
+physical_buffer_role_and_storage_rule
+byte_extent_offset_and_unit_rule
+host_owner_and_lifetime
+runtime_or_compile_time_owner
+intended_device_destination_role
+rejection_condition
+evidence_refs
+```
+
+这是一份从用户接口到设备数据流的草案：它必须明确每个逻辑对象将如何成为物理 buffer，并指出预期由 Kernel GM 参数、Tiling/Params、workspace 或其他设备消费者接收；但不得在没有真实证据时填写具体 GM 参数名、入口修饰符、Wrapper 形态、模板参数或 grid。精确设备 ABI 在 2.3 冻结。
+
+逻辑接口本身不清时请求用户澄清；物理格式、字节规则或 ABI 前置事实不清时返回 Step 2。两类问题未闭合时不得进入 2.3。Kernel entry、GM 参数、TilingData、grid、pipe、event 和 slot 不能反向定义用户接口。
+
+### 2.3 基于 Blaze 官方库的方案分析
+
+本阶段对每个可进入设计的需求始终执行。它使用 Step 2 中的候选 Blaze 组装方案事实，按 2.1 的每个 requirement/partition 精确判断能否形成完整的 Blaze 官方库方案；它是路线决策的第一部分，而不是 Step 2 的复述。
+
+按以下顺序执行：
+
+1. 读取候选真实入口、具体证据、组件链、specialization、Tiling/Params、Tensor API、物理数据、host/device ABI、资源、final/partial 和生命周期事实；同时读取已观察限制与未闭合源码事实、[Tiling 方法](../kernel-design/tiling-selection.md) 和 [Launcher 开发](../launcher/launcher-development.md)。
+2. 将每一项事实映射到精确需求，形成 `matmul_base_analysis` 和候选处置记录。不得按名称拼接类型、构造模板笛卡尔积，或以 Asset/旧工程证明 Blaze 官方库能力、固定 ABI 或支持范围。Asset 只能在兼容性证明且 DESIGN 明确选择后作为项目副本的结构起点。
+
+每个可行候选的选择状态只能是“首选”或“备选”，且每个 required partition 最多一个首选。淘汰、阻塞和不适用候选单独记录在候选处置中；PLAN 只消费首选合同，不自动激活备选。
+3. 对每个保留为设计 binding 的具体 Blaze 组装方案，以同一真实 witness 在 `matmul_base_analysis.abi_bindings[]` 中冻结独立 ABI 子合同。每条记录必须写入 `design_binding_ref`、覆盖的 `partition_ids` 和 `assembly_witness_ref`；其中的 `kernel_abi_contract` 必须包含入口修饰符和链接形式、入口符号、模板/具体 specialization、GM 参数的顺序/方向/可空语义/物理字节规则、TilingData/Params、workspace、grid/usedCore、Wrapper 绑定、dispatch，以及 final/partial 输出生命周期。每项都必须有对应 `source_ref`。
+4. 为每个选定 binding 在其 `matmul_base_analysis.abi_bindings[]` 记录中输出独立 `abi_crosswalk`：
+
+```text
+logical argument
+  -> physical buffer and storage rule
+  -> Launcher argument
+  -> Wrapper argument
+  -> ordered Kernel GM parameter
+  -> TilingData/Params field or not_applicable with reason
+  -> Block/Kernel/Epilogue device consumer
+```
+
+   每行还必须记录稳定 `crosswalk_row_id`、方向、可空条件、字节范围/offset 单位、所有权/生命周期和 `source_refs`。TilingData、workspace、grid/usedCore、stream/dispatch 等非逻辑参数也要作为辅助 ABI 对象记录其 host 产生者、入口/Wrapper 绑定和设备消费者。不得将不同 `design_binding_ref` 的参数顺序或 crosswalk 行混用。
+   若设计使用 Skill Asset 或项目副本作为结构起点，必须额外完成 Asset 能力边界核对：
+
+   - 记录 Asset 实际提供的 Kernel、Block、Scheduler、Epilogue 和同步层；
+   - 记录它明确不提供的 Host Tiling、Launcher、额外 operand、workspace、Golden 和验证层；
+   - 将目标项目的适配点和首个设备消费者接入现有 ABI crosswalk、场景 delta 和 source refs。
+   - 对会被项目 include 的 Host/ASC 资产执行同名全局 helper 探针；内部
+     `Align`、`CeilDiv`、`FloorAlign` 等 helper 必须显式限定所属命名空间，不能
+     依赖 include 顺序或调用方的 `using namespace` 消除歧义。
+
+   任何一层未闭合都必须标记为 `adaptation_required` 或 `extension_missing`，不能因为
+   Asset 文件存在或局部组件可编译就将端到端方案标记为 complete/native。
+5. 从每个真实 witness 在对应 `abi_bindings[]` 记录中生成 `source_backed_signature_skeleton`，保留入口声明形态、参数顺序、Wrapper 或 dispatch 调用关系及其 `source_refs`。它是设计合同，不是可复制 Kernel recipe；只有 witness 已明确的修饰符、`__cube__`/`__mix__`、GM 参数、模板参数和调用方式才能写入，其他位置保留待项目命名的占位，不得猜测。
+6. 若某一项决定性事实缺失且报告尚无已完成的补充，提出只描述需求语义和待查 Blaze 源码关系的补充问题，返回 Step 2。补充问题不得包含场景 ID、场景路径或路线建议。若同一报告已完成一次补充后仍缺关键事实，停止为“未完成设计，等待澄清”；不写最终路线，也不生成 DESIGN/PLAN。
+7. 若已有事实表明某个需求不能由选定官方方案覆盖，逐项记录 `native_gaps`，再进入 2.4。可接受的依据是来源明确的不兼容/拒绝，或对该精确需求已穷尽声明读取边界后的无匹配事实；孤立 `not_found`、`indexed`、未读目录或未知事实不得写为 `native_gaps`。
+
+   `native_gaps` 的判定对象是 §0.4 需求合同中的完整算子语义，不是其中的某个子步骤。官方方案覆盖性检查必须满足以下原则：
+   - 算子的全部计算步骤（包括 matmul 及其前/后的所有非 matmul 计算）必须由单一 Blaze 官方 Kernel 方案覆盖，才算 blaze_native。多个独立 Kernel 分别覆盖不同步骤不构成 blaze_native。
+   - 禁止将用户需求中的任何计算步骤排除到 Blaze 官方方案分析范围之外（如声明为"辅助预处理""host 侧步骤""非 Blaze 操作"等），从而缩小 `native_gaps` 的判定范围使剩余步骤单独满足 blaze_native 条件。
+   - 算子的所有计算必须在 device 侧完成。不得将需求中声明的计算步骤放到 host 侧执行后将其结果作为中间输入传入 device Kernel。
+
+8. 若一个完整官方方案以单一 Kernel 覆盖算子的全部计算步骤（包括 matmul 及其前/后的非 matmul 计算），且全部在 device 侧完成，写入：
+
+```text
+implementation_route: blaze_native
+selected_scenario: <omit>
+```
+
+此结果不读取 `references/scenarios/index.md`、场景设计指导或场景开发指导。
+
+Blaze 源码没有现成 host Tiling 实现本身不构成缺口。先逐字段核对可复用的项目 Tiling Engine；能证明 Params 语义、单位、合法域和 ABI 兼容时，PLAN 可复用或最小适配。不能复用但上述事实已闭合时，PLAN 可令项目 Tiling Engine 返回经过证明的固定合法控制值。需要新的 Params、specialization、合法域或 ABI 事实时，返回 Step 2。
+
+### 2.4 定制扩展场景匹配与设计（可选）
+
+本阶段仅在 2.3 已记录至少一个 `native_gaps` 后执行。它直接使用 2.1 的精确需求合同匹配 [场景索引](../scenarios/index.md)，不使用 Step 2 的场景预判，也不以“额外语义”之类 flag 作为前提。
+
+1. 读取每个索引行的支持范围和准入条件；当前只允许命中一个场景，不组合多个场景。
+2. 若需求合同不足以判定任一支持范围或准入条件，停止等待用户澄清；不将需求歧义写成 `unsupported`。
+3. 零命中或多命中：在 `DESIGN.md` 写入：
+
+```text
+implementation_route: unsupported
+unsupported_points:
+  - requirement_id
+    native_gap
+    scenario_match_result
+    evidence_refs
+    user_recovery
+```
+
+   停止设计，不生成 PLAN，也不进入 Step 4。
+4. 唯一命中：读取该行的设计指导。场景指导检查自己声明的 Blaze 源码前提，以及是否消费 `matmul_base_analysis`。
+5. 场景前提缺失：生成一次无场景名的补充调查问题并返回 Step 2。若同一报告已完成一次补充且关键事实仍缺失，停止为“未完成设计，等待澄清”；不写最终 `implementation_route`，不生成 DESIGN/PLAN。
+6. 场景前提充分：写入：
+
+```text
+implementation_route: blaze_custom
+selected_scenario: <唯一 scenario_id>
+```
+
+   并由场景设计指导生成定制扩展合同。
+
+场景是否消费 2.3 的 `matmul_base_analysis` 由该场景自身定义。当前 Elementwise/Broadcast Epilogue Fusion 明确消费该合同；后续场景不自动继承。
+
+### 路线结果表
+
+| 已知事实与匹配结果 | Step 3 行为 | 交付 |
+|---|---|---|
+| 判断需要的 Blaze 源码事实缺失，尚未补充 | 生成一次语义化补充问题，回 Step 2 | 无最终路线、无 DESIGN/PLAN |
+| 一次补充后仍缺关键事实，或需求合同本身不清 | 停止等待用户澄清 | 无最终路线、无 DESIGN/PLAN |
+| 官方 Blaze 方案以单一 device Kernel 覆盖算子全部计算步骤 | `implementation_route=blaze_native`，跳过注册表 | DESIGN + PLAN |
+| 官方方案有 `native_gaps`，场景唯一命中且前提充分 | `implementation_route=blaze_custom` | DESIGN + PLAN |
+| 官方方案有 `native_gaps`，场景零命中或多命中 | `implementation_route=unsupported` | 仅阻塞 DESIGN |
+
+### 2.5 最终合同装配
+
+按以下顺序装配最终合同：
+
+```text
+requirements
+  -> operator interface
+  -> abi_mapping_draft
+  -> matmul_base_analysis (per-binding ABI contract, crosswalk, signature skeleton)
+  -> selected scenario delta (only blaze_custom)
+  -> final operator/kernel/resource/data/sync/validation contracts
+```
+
+需求语义由需求合同持有，外部接口由接口合同持有，官方库分析由 `matmul_base_analysis` 持有，定制增量由唯一场景合同持有。场景必须明确 `consumed_contracts`、`preserved_contracts`、`replaced_contracts` 和 `added_contracts`，不得由通用流程猜测。
+
+若发现需要改变前置设计合同，返回对应 owner；需要新的 Blaze 源码事实时返回 Step 2。不得在 Step 3 现场实验或循环重选路线。
+
+### 2.6 Validation Contract
+
+冻结逻辑数据、物理转换、CPU Golden、阈值、非有限值、边界、诊断、重复运行、清理和回归要求。验证矩阵只来自需求、Investigation 和已选场景指导。
+
+Step 3 只能记录 `planned` 或 `unverified`，不得伪造设备结果。验证合同必须规定：任何设备结论均需绑定当前 Investigation、冻结首选组装方案的真实 witness，以及实际构建和验证记录；未满足时对应组合保持 `unverified`，不得泛化。`blaze_custom` 的专项验证由场景设计指导增加；`blaze_native` 使用通用 MatMul 验证合同。
+
+### 2.7 PLAN Compilation
+
+仅当 `implementation_route` 为 `blaze_native` 或 `blaze_custom`，且 DESIGN 合同已冻结时，用统一模板编译 `operators/<operator_name>/docs/PLAN.md`：
+
+1. 绑定 Investigation、DESIGN、唯一首选和验证合同；
+2. `blaze_native` 仅从官方库设计和通用方法生成 action；
+3. `blaze_custom` 才读取唯一索引行的开发指导，并将要求实例化为 reading manifest、actions、checkpoints、交付和回退；
+4. 核对 Investigation 的项目内官方副本状态。副本已由 Step 1 建立时登记 `read_only` 并将物化 action 记为 N/A；设计请求跳过 Step 1 且副本缺失时，为每个缺失目标生成首个 `action_type: create` action，只允许从当前 `blaze_source_root` 原样复制或绑定、核对同源内容并立即设为只读，不得适配或使用第二源码根；
+5. 只要 PLAN 含 CMake configure 或 build action，必须读取 [Blaze CMake 构建指导](../fundamentals/blaze-cmake-build-guide.md)，将项目构建入口、目标、预期产物、成功 checkpoint 和失败后的 Step 4 排障入口写入初始 PLAN；项目构建文件可作为初始 `target_file_manifest` 目标，但不是 Step 4 修复的封闭文件清单；
+6. 冻结 PLAN 第 9、10 章以及第 1、3 章设计基线；第 2、4--8 章留给实施阶段持续更新，第 11 章建立空的追加记录；
+7. 删除备选与未激活分支，执行 PLAN freeze gate。
+
+每个初始 action 必须有 DESIGN refs、source refs、读取前置、计划目标、产物、验证和回退。CMake action 不增加专用合同字段，也不要求 Step 3 预判实际编译中才会暴露的 include 顺序、编译选项、链接参数或 `-iquote`。PLAN 不得留下需要 Step 4 决定的路线、接口、ABI、支持范围或验证标准；实现层的文件、配置和修复细节可由 Step 4 根据证据闭合。`unsupported` 和“等待澄清”路径均不产生可执行 action。
+
+## 3. Reading Routes
+
+| 设计节点 | 必读资料 | 条件资料 | 禁止 |
+|---|---|---|---|
+| 需求合同 | 用户需求、Investigation 的需求投影 | 无 | recipe、实现样例 |
+| 接口合同 | Investigation 的物理/ABI事实、[MatMul Layout](../fundamentals/blaze-matmul-layout.md)、[Launcher 开发](../launcher/launcher-development.md) | 报告明确的公共 API | 未选 Kernel 签名、场景正文 |
+| Blaze 官方库方案分析 | 候选 Blaze 组装方案、实际 witness、限制、未闭合事实、[Tiling 方法](../kernel-design/tiling-selection.md)、[Launcher 开发](../launcher/launcher-development.md) | 框架方法 | 场景索引、场景正文、Asset 能力推断 |
+| 定制场景设计 | `native_gaps`、唯一索引行的设计指导 | 场景规定的依赖 Skill 根入口和叶子 | 其他场景、development guide |
+| 最终合同与验证 | 已生成合同、验证方法 | 场景验证增量 | 新候选、新设备事实 |
+| PLAN 编译 | 冻结 DESIGN、Step 4 约束 | 含 CMake action 时必读 [Blaze CMake 构建指导](../fundamentals/blaze-cmake-build-guide.md)；`blaze_custom` 的唯一 development guide | 新设计分支、路线切换 |
+
+## 4. DESIGN/PLAN Gates
+
+可执行交接必须满足：
+
+- `implementation_route` 是 `blaze_native` 或 `blaze_custom`；
+- Step 2 报告中影响选择的 Blaze 源码事实已闭合，或具有来源绑定的明确限制；
+- `blaze_native` 有完整官方库设计，且没有场景 action；
+- `blaze_custom` 有唯一 `selected_scenario`、完整场景合同和场景指导映射；
+- `abi_mapping_draft` 覆盖全部逻辑参数、输出和必要辅助对象，且物理数据、字节规则、所有权和拒绝条件闭合；
+- 每个首选 binding 的 `kernel_abi_contract`、`abi_crosswalk` 和 `source_backed_signature_skeleton` 均绑定同一真实 witness；每个必需对象都能追到 Launcher、Wrapper、Kernel 参数、Tiling/Params（或有依据的 `not_applicable`）和设备消费者，且不混用其他 binding 的参数顺序或入口；
+- DESIGN/PLAN 的 project/design/plan IDs、路线、场景、首选 binding 和一致性 marker 相同，且 `design_plan_consistency=confirmed`；
+- PLAN 初始文件范围是 DESIGN `allowed_change_scope` 的子集；Step 4 的实现修复可在项目根内扩展，但不得触碰 `forbidden_change_scope`；
+- 项目内官方副本已与当前根源码同源，或 PLAN 为缺失副本提供先于构建和实现的 create-only 原样物化 action；该 action 完成后副本只读，任何内容适配仍受 `forbidden_change_scope` 禁止；
+- 每个首选合同有 action，每个验证合同有 checkpoint；所有涉及 buffer、Tiling、Wrapper、Kernel entry 或 Launcher 的 action 均引用对应 ABI 合同项，其中 Wrapper、Kernel entry 或 Launcher 启动绑定还引用签名骨架；
+- 存在构建 action 时，PLAN 已提供初始构建入口、configure/build 目标、预期结果、构建 checkpoint 和失败处理基线；
+- 无 blocking、TBD，以及未决的路线、接口/ABI、支持范围或验证标准；
+- 官方源码区和 Asset 原文件只读。
+
+`unsupported` 只允许输出 `native_gaps`、`unsupported_points`、用户恢复路径和禁止执行范围。一次补充后仍缺事实的路径不输出最终合同。
+
+## 5. Handoff
+
+仅 `blaze_native` 或 `blaze_custom` 且联合门禁通过时，才能把 `operators/<operator_name>/docs/DESIGN.md` 和 `operators/<operator_name>/docs/PLAN.md` 交给实施阶段。完整四步 Blaze 流程进入 [Step 4: Implementation](step4-operator-development.md)；direct invoke Developer 直接消费相同文档，不调用 Blaze Step 4。实施阶段以第 1、3、9、10 章和 DESIGN 为设计边界，可在 `operator_root` 内调查实现问题、动态修复和记录额外文件，不重新设计路线、匹配场景或扩大支持域。

package/assets/ops-direct-invoke/skills/ascendc-blaze-best-practice/references/workflow/step4-operator-development.md

@@ -0,0 +1,166 @@
+# Step 4: Implementation
+
+> **定位**：仅在明确完整“开发算子”的 Blaze 四步流程中，执行 Step 3 生成的 `operators/<operator_name>/docs/DESIGN.md` 和 `operators/<operator_name>/docs/PLAN.md`。direct invoke Developer 直接消费相同文档，不调用本 Step。Step 4 不重新设计、不重新匹配场景或扩大支持域；按冻结合同推进，并可为实现设计补充算子项目内修复步骤。
+
+## 1. 规范性输入和职责边界
+
+Step 4 的规范性输入只有当前项目：
+
+```text
+operators/<operator_name>/docs/DESIGN.md  # 设计合同：做什么、为什么、边界和验证合同
+operators/<operator_name>/docs/PLAN.md    # §1/§3/§9/§10 设计基线；§2/§4--8 状态；§11 追加记录
+```
+
+PLAN 的 `reading_manifest`、action `source_refs` 和 `read_before_action_ids` 是初始阅读基线，不是 Step 4 的封闭读取清单。Step 4 可以按实际实现和错误证据读取项目文件、生成日志、实际命令、构建缓存、相关工具链资料和排障文档；这些资料只用于实现冻结设计，不得成为第二套设计入口。
+
+### 1.1 问题触发的排障
+
+当前 action 或 checkpoint 失败、输出异常或结果偏离预期时，扫描 [`references/troubleshooting/`](../troubleshooting/)：
+
+1. 枚举目录下所有 Markdown 文档；
+2. 只读取每篇文档开头的“适用范围”和“触发信号”；
+3. 完整读取与当前问题匹配的文档；
+4. 定位并修复问题，重新执行原 action 或 checkpoint。
+
+没有匹配文档时，继续使用常规工程方法诊断；缺少排障文档本身不构成阻塞。问题定位期间可以检查错误直接涉及的工具链头文件、项目文件和构建产物；这些内容只作为诊断证据，不能改变冻结设计。
+
+为实现冻结设计，Step 4 可以在 `<project-root>/operators/<operator_name>/` 内新增、修改或删除实现所需文件，包括源码、构建文件、Tiling、Launcher、测试和诊断代码；可以调整 include 路径与顺序、target 级编译选项，以及当前项目和既有工具链/运行时依赖的链接配置。新增或调整实际文件时更新 PLAN 第 2 章；同步更新第 4--8 章状态/结果，并把问题、实际修改、验证结果和证据追加到第 11 章 `execution_record`。不回写 DESIGN 或 PLAN 第 1、3、9、10 章。
+
+修复一旦需要改变实现路线、Blaze 组装方案、算子接口或 Kernel ABI、数据语义、支持范围或验证标准，停止并回 Step 3；需要新的 Blaze 源码事实时先回 Step 2。Blaze 源码、submodule 或只读副本异常回 Step 1。项目内新增文件不单独触发回退，新的外部依赖仍需回 Step 3 评估。
+
+设计请求跳过 Step 1 且项目内官方副本缺失时，只能执行 PLAN 冻结的 `create_only_exact_read_only_materialization`：从当前 Investigation 绑定的 `blaze_source_root` 原样复制或绑定缺失目录，核对同源内容后立即设为只读，再进入其他 action。该初始化动作不是 custom 适配，不得改写、筛选或补丁官方文件；PLAN 未授权、来源不一致或核对失败时回 Step 1。
+
+禁止：
+
+- 重新选择 route、Blaze 组装方案、Kernel/接口/ABI 合同，或扩大支持域和验证标准；Tiling 合法值、资源使用和同步实现可在冻结语义内修复；
+- 重新匹配场景、读取 registry 做路由或把场景 development guide 当独立指令；
+- 从相似工程、旧 recipe、Asset 注释或资料推导新的设计、路线或支持范围；
+- 将 DESIGN 中的“备选”自动切换为执行方案；
+- 修改 DESIGN，或修改 PLAN 第 1、3、9、10 章；
+- 修改根 `ops-tensor`、Skill Asset 原文件、项目根之外的路径，或在已登记的缺失目录原样物化之外写入项目内官方副本和 DESIGN `forbidden_change_scope`；
+- 引入具体提交 ID、hash、构建时间戳或提交节点；
+- 修改或引用独立验证工程。
+- 在 host 侧执行算子需求中声明的任何计算步骤；算子的全部计算（包括但不限于反量化、scale/dequant、cast、activation、normalization 等）必须在 device Kernel 中完成，不得将 host 侧计算的中间结果作为 device Kernel 的输入。
+
+## 2. DESIGN/PLAN 联合门禁
+
+在创建、复制、修改或删除任何项目文件前，逐项核对：
+
+```text
+implementation_route: blaze_native | blaze_custom
+checkout_consistency: confirmed
+design_plan_consistency: confirmed
+frozen_plan_status: ready
+```
+
+同时确认：
+
+- DESIGN 和 PLAN 双向引用，project/design/plan IDs、一致性 marker、route、scenario（如有）和唯一首选一致；
+- 没有 unresolved blocking、TBD、未选分支或需要 Step 4 决定的设计事项；
+- PLAN `target_file_manifest` 是 DESIGN `allowed_change_scope` 的初始子集；Step 4 的实际项目文件可以在项目根内扩展，须避开 DESIGN `forbidden_change_scope`，并在 `execution_record` 记录；
+- 初始 `target_file_manifest.target_file`、action `target_files` 和可写交付件必须记录为以 `operators/<operator_name>/` 开头的项目相对路径；官方源码区和 Skill Asset 只能作为只读来源；
+- 项目内官方副本已同源核对，或 PLAN 具有最先执行的 create-only 原样物化 action；除该缺失目录初始化外，官方副本不允许任何写入；
+- 每个初始 action 都有 DESIGN refs、source refs、读取前置、计划目标、产物、验证和 rollback；修复不要求补 action；
+- 存在 CMake configure 或 build action 时，PLAN 写明构建目标、预期结果、构建 checkpoint 和失败处理基线；项目构建文件不是 Step 4 修复的封闭清单；
+- DESIGN 的 `abi_mapping_draft`、每个首选 `design_binding_ref` 的 source-backed `kernel_abi_contract`、`abi_crosswalk`、`source_backed_signature_skeleton` 和（适用时）场景 `abi_crosswalk_delta` 已闭合；每个必需逻辑参数和辅助 ABI 对象都能以稳定 `crosswalk_row_id` 在同一 binding 内追到物理 buffer、Launcher、Wrapper、Kernel 参数、Tiling/Params（或有依据的 `not_applicable`）和设备消费者；
+- 所有涉及 buffer、Tiling/Params、Wrapper、Kernel entry 或 Launcher 的 action 都引用相应 ABI 合同项；其中 Wrapper、Kernel entry 或 Launcher 启动绑定 action 还引用 source-backed 签名骨架，且静态 ABI checkpoint 覆盖物理字节/offset、TilingData、workspace、grid/usedCore、Wrapper/entry 绑定和输出生命周期；
+- 每个验证合同、交付件、清理要求都有 checkpoint/action；
+- 除已登记的 create-only 缺失目录原样物化外，只读源码区、Asset 原文件、DESIGN forbidden scope 和项目根之外的路径未被修改；物化后的官方副本内容零改动；
+- `implementation_route=blaze_native` 时，PLAN 不含场景 action 或 custom fallback；
+- `implementation_route=blaze_custom` 时，PLAN 的场景要求映射完整且只有一个 `selected_scenario`；
+- `implementation_route=unsupported`，或没有最终路线/DESIGN/PLAN 的“等待澄清”状态，均不能进入 Step 4。
+
+任一真正的设计或源码事实门禁失败，停止在文件修改前。缺少真实入口、GM 参数、TilingData/Params、workspace、grid/usedCore、Wrapper 或物理字节规则的 Blaze 源码事实时，回 Step 2；冻结设计合同不足以定义需求语义、接口/ABI 或验收标准时回 Step 3；若失败原因是 Blaze 源码版本不一致，回 Step 1。普通资料缺失、文件未列入初始 manifest 或 action 需要实现修复时，不单独阻塞 Step 4。
+
+## 3. 四阶段执行 Runbook
+
+### 3.1 阶段 0：联合交接
+
+读取 DESIGN 及 PLAN 第 1、3、9、10 章，确认当前项目 Blaze 源码版本、只读边界、初始目标文件和 execution record 空间。在第 4 章更新交接进度，并在第 11 章追加 handoff 结果；不修改设计基线。
+
+### 3.2 阶段 1：执行材料与文件核验
+
+以 PLAN `reading_manifest` 和 `target_file_manifest` 为起点：
+
+1. 加载当前 action 已登记的来源和位置，并按实现需要检查项目文件和工具链资料；
+2. 当前 action 为 CMake configure 或 build 时，确认 action 的构建目标、预期结果、checkpoint 和失败处理基线完整；
+3. 核对初始 `read_before_action_ids`、source refs、依赖入口和实际头文件；缺少资料时先在项目和工具链中查找，不因未登记自动回退；
+4. 对当前 buffer/Tiling/Params/Wrapper/Kernel/Launcher action 核对其 `abi_contract_refs`、`design_binding_ref`、`crosswalk_row_id`（场景增量为 `delta_crosswalk_row_id`）和签名骨架与同一当前源码 witness 一致；
+5. 核对每个目标文件的 action type、source、允许范围和预期产物；
+6. 不创建目录、不复制文件、不修改文件。
+
+只有发现只读文件被修改、项目根越界或冻结设计语义不足时才停止并回退；材料未登记或初始目标不完整时，优先在项目内补齐实现并记录实际变更。
+
+### 3.3 阶段 2：有序 action 执行
+
+严格按 `ordered_actions.sequence` 和 prerequisites：
+
+- 初始 `create`、`copy_and_adapt`、`modify`、`delete`、构建、运行、记录和清理都必须是显式 action；修复步骤可以直接记录在 `execution_record`，不要求补 action；
+- 官方副本的 create-only 物化 action 必须先执行并完成同源、内容和只读状态核对；它不能改为 `copy_and_adapt`，也不能在失败时切换来源；
+- 每个初始 action 按计划目标推进，完成后执行其 checkpoint；
+- action 或 checkpoint 失败、输出异常或结果偏离预期时，按 1.1 节加载匹配资料，在项目根内诊断、修复并重新验证；不要求先补 action 或重新登记文件；
+- 修复循环不预设固定重试次数；只要证据仍指向实现层且能取得新进展，就继续修复并重跑失败项及受影响的下游 checkpoint；
+- 不改路线、不换候选、不扩大参数/shape/dtype/场景支持域；实现修复可新增项目内文件和实现步骤；
+- 复制 Asset 后只能适配项目目标副本，Asset 原文件保持零 diff；复制或适配必须保持初始 PLAN 冻结的相对 include 拓扑，或同时落实已冻结的源到目标映射和 include 改写；完成后用目标实际 compiler/语言/架构执行 include-closure 探针；
+- 第 2 章更新实际文件状态，第 4--8 章更新进度和结果，第 11 章追加实际文件、输出、证据、结果和 deviation；不能改写第 9 章动作定义。
+
+### 3.4 阶段 3：验证、清理和交付
+
+按 PLAN `validation_checkpoints` 执行静态 ABI、构建、功能、边界、物理地址、资源/生命周期、精度、重复运行、诊断清理和最终回归。清理按 PLAN 基线执行，并覆盖执行期间产生的临时诊断文件和产物；交付只核对 `deliverable_manifest`。任何设备结论必须通过 `execution_record.evidence_refs` 关联当前 Investigation、冻结首选组装方案的真实 witness，以及实际构建和验证记录；任一关联缺失时，对应组合保持 `unverified`，不得泛化。
+
+任何 required checkpoint、交付件、只读审计或清理后回归失败，都不能标记完成。先保留证据并继续诊断、修复和重跑；只有确认需要改变冻结设计、补充 Blaze 源码事实或修复源码基线时，才按第 5 节回 Step 3/2/1。暂时无法解决的实现问题记录为 `failed`，工具链或设备不可用记录为 `blocked`，不把它们伪装成设计回退。
+
+## 4. PLAN 更新与 Execution Record 边界
+
+PLAN 的所有权固定为：第 1 章需求语义和第 3 章测试范围/追溯/验收标准是设计基线；第 2 章文件状态、第 4 章进度、第 5 章问题/决策、第 6--8 章结果由实施阶段持续更新；第 9、10 章冻结；第 11 章只能追加。设计基线变化必须在第 5、11 章记录 `design_issue` 并返回 Step 3。
+
+第 11 章每条记录至少包含：
+
+```text
+execution_id
+action_id_or_checkpoint_id
+start_and_end_marker
+actual_files_changed
+actual_output
+result: completed | failed | blocked
+evidence_refs
+deviation
+rollback_performed
+next_action_or_return_target
+```
+
+如果 deviation 改变需求语义、路线、Blaze 组装方案、接口/ABI、验证标准或支持域，必须停止当前实现，记录证据并把 `next_action_or_return_target` 指向 Step 3；不得把设计回退记成环境 `blocked`。项目内新增文件、实现步骤、Tiling 合法值、资源/同步实现或配置修复更新第 2、4--8 章并追加实际修改和验证证据，不改写第 1、3、9、10 章。
+
+## 5. 失败分类与回退
+
+| 失败类型 | 处理 |
+|---|---|
+| Blaze 源码版本不一致 | 停止修改，回 Step 1 |
+| Blaze 源码事实、类型链、Params、API 或物理 ABI 被当前源码推翻 | 保留证据，回 Step 2，再重做 Step 3 |
+| Blaze 源码、submodule 或项目只读副本不完整/不一致 | 只读采集完整性证据，停止修改并回 Step 1 |
+| 冻结设计、接口/ABI、支持范围或验证标准缺失/冲突 | 文件修改前回 Step 3 |
+| CMake configure、编译、链接、精度或普通实现失败 | 按 1.1 节持续排障、修复并重新执行受影响 checkpoint |
+| 修复需要改变需求语义、路线、Blaze 组装方案、接口/ABI、支持域、验证标准或引入新的外部依赖 | 保留证据，回 Step 3 |
+| 执行材料缺失但设计和源码事实完整 | 在项目内补齐实现并记录实际文件，不自动回退 |
+| canonical Skill/场景注册/指导自身缺失或冲突 | 源码事实不足时回 Step 2；否则记录 `failed` 并进入 Skill 维护，不伪装成设计或环境回退 |
+| 普通实现错误 | 在项目根内修复并重新验证；只有触及冻结设计才回 Step 3 |
+| 验证推翻设计前提 | 停止受影响 action，回 Step 3；需要新事实先回 Step 2 |
+| 用户需求改变 | 停止执行，回需求合同和 Step 3 |
+
+回退保留用户已有改动和失败证据，不做整体 Git 恢复，不覆盖只读区域，也不恢复旧 recipe 作为正式路由。
+
+## 6. 完成门禁
+
+Step 4 完成必须同时证明：
+
+- PLAN 所有 required action、checkpoint、deliverable、cleanup 和 final regression 已记录结果；
+- 项目文件均位于项目根内；除已登记的 create-only 缺失目录原样物化外，官方源码区、Asset 原文件和 DESIGN forbidden scope 未改写；
+- 目标 route、唯一首选、接口/Kernel/Tiling/资源/同步/验证合同与实现一致；
+- 已执行的 buffer、Tiling/Params、Wrapper、Kernel entry 和 Launcher 接线均符合冻结的 ABI crosswalk 和签名骨架；
+- 所有 required 精度/边界/非有限值门禁通过；
+- 每项已记录的设备结论均有绑定当前 Investigation、冻结首选组装方案真实 witness、构建和验证记录的 `execution_record.evidence_refs`；未验证组合保持 `unverified`，不作为交付支持范围；
+- 清理后正式回归通过；
+- 根 `ops-tensor`、全部 Skill Asset 原文件和独立验证工程零改动；项目内官方副本与当前根源码同源，且物化完成后内容零改动；
+- 最终 execution record 明确交付或阻塞原因。
+
+下一阶段不是新的 Step；最终交付审计属于本 Step 4。