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

package/assets/ops-direct-invoke/skills/ops-direct-invoke/tasks/cannbot-dsl//345/215/225/345/205/203/345/256/236/347/216/260.yaml

@@ -0,0 +1,27 @@
+title: Unit 实现｜TDD 驱动的纵向能力增量
+goal:
+- 实现当前 Unit 的纵向能力，并交付对应测试与回归证据。
+approach:
+- 核对当前 Unit 的 design_sources、depends_on、verification_obligations、允许修改路径，以及原生 Unit 和 testcase.csv 中的 TDD case 与白盒分支；不以其他 Unit 的文件代替。
+- 新增能力时运行绑定 TDD，确认 Red 来自该能力缺失；环境、用例或 Golden 错误应记录并终止。重试沿用有效的原始 Red；复用已有能力时记录来源与当前验证结果，不为制造 Red 破坏已通过代码。
+- 算子公开实现模块固定为 `$WORK_DIR/operators/<op>/<op>.py`，结构事件记录器固定为 `$WORK_DIR/operators/<op>/probe/<op>_probe.py`；实际包名取自 spec.op.name。仅在 Unit 允许的源码范围内实现能力；生成或修改代码时按 `cannbot-dsl-best-practice` 加载生产代码规范，完整算子与公共结构按其整体实现参考落实设计中的运行、导出及编译工厂；微模块资料按需读取，核对 DESIGN 与目标设备事实。
+- 可按需参考 `$WORK_DIR/cannbot-dsl/samples/` 下的算子官方实现：按各示例目录的 README 定位与当前 Unit 相关的示例，参考其 API 用法、代码组织与结构事件记录写法；数学语义、tile/分块、并行与同步方案仍以冻结 DESIGN 和 `$WORK_DIR/cannbot-dsl/docs` 中的 API 文档为准。实际参考的示例文件与参考点须写入本节点执行记录，未记录来源的示例片段不得进入实现。
+- 结构用例使用 `CANNBOTDSL_PROBE_MODULE=operators.<op>.probe.<op>_probe`，由算子记录实际事件，探针提供 `reset()/snapshot()`；运行前将 `$WORK_DIR` 加入 `PYTHONPATH`。
+- 再运行绑定用例直到 Green，并运行依赖闭包与源码改动实际影响的前序能力回归；记录实现版本、命令、退出码和逐例结果，保持后续 Unit 可复用的已通过能力。
+- 读取当前 Unit 的 supported_domain、design_constraints、feasibility_checks 及其义务/review_evidence；先完成首次使用能力所需补证。将每项约束、补证的通过判据、当前版本原始证据与结论写入本节点执行记录，再交付该能力。
+- 设计承诺无法实现或必须改变执行域、数据通路、同步、复杂度等强制要求时，记录失败证据、差异、候选影响及受阻后继，按原生执行协议结束受阻操作；不以数学等价或小输入通过宣告完整实现，不自行改写冻结方案。
+- 运行绑定用例及依赖闭包、源码改动实际影响的前序能力回归；连续调用、重复运行和结构关系沿用冻结测试契约，保留当前代码、测试与原始结果的版本对应关系。
+- 将本节点执行过程记录写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID；业务产物仍写入本任务约定的位置。
+procedure:
+- 新增能力核对同一用例的 Red→Green 原因可信；重试或复用核对原始证据、来源与当前结果。当前 Unit 验证义务、补证与受影响能力回归均有真实通过证据。
+- 核对代码改动不越过允许路径，没有从 flash_attn/flash_kda 样例复制数学、固定 tile、架构比例或 Channel 深度。
+- 核对执行记录中声明的示例参考真实存在于 `$WORK_DIR/cannbot-dsl/samples/` 且与当前 Unit 职责相关，参考点限于 API 用法、代码组织或事件记录写法；示例中的数学、固定 tile、架构比例未被带入实现。
+- 核对执行记录中的实现版本、命令、退出码与逐例结果完整、可复核。
+- 逐项核对设计强制承诺与补证证据对应当前实现，输入条件实际触发；源码/编译产物/设备记录符合 review_evidence 的通过判据。仅有关联 ID 或通过自述、缺少承诺证据时判失败。
+- 追溯探针采集代码及原始事件，核对执行域、数据交接、代次与实际顺序来源；静态配置、固定 snapshot 或 Host 按预期拼装的事件不能证明结构完成。数值通过与设计符合性分别判定。
+- 核对受影响前序能力及依赖闭包的回归，无未解释缺口；强制设计承诺改变或关键补证失败保持失败，由既有重试/退出流程处理。
+- 将验收结论与证据写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID。
+acceptance:
+- test -s "$WORK_DIR/operators/<op>/<op>.py"
+out_of_scope:
+- 不修改 spec、DESIGN、原生 Unit、Golden、白盒分支表、TDD 断言或阈值，不代替全量精度与性能测试。

package/assets/ops-direct-invoke/skills/ops-direct-invoke/tasks/cannbot-dsl//345/215/225/345/205/203/351/233/206/346/210/220/345/244/215/351/252/214.yaml

@@ -0,0 +1,19 @@
+title: 单元集成复验｜汇合全部 Unit 实现
+goal:
+- 在全部 Unit 实现及修复完成后，验证组合实现的构建、功能和单元级数值正确性。
+approach:
+- 运行结构用例时，将 `$WORK_DIR` 加入 `PYTHONPATH`，使用 `CANNBOTDSL_PROBE_MODULE=operators.<op>.probe.<op>_probe`，沿用冻结的探针事件断言。
+- 对照 operators/<op>/test/testcase.csv 和 <op>_golden.py 核对所有 Unit、当前代码与测试资产，禁止只选择已通过的子集。
+- 构建完整实现，运行全部 Unit TDD、Golden、白盒及必要黑盒回归；使用 Skill 生成的测试入口和原生 case CSV，保留执行命令、退出码、逐例结果和失败日志。
+- 按冻结设计验证公开运行与导出共用编译工厂、Native 收集及产物实际命中，覆盖声明的编译变体；将执行命令、产物位置和结果纳入集成报告，失败进入实现修复。
+- 将完整结果和可定位的失败清单写入 `$WORK_DIR/operators/<op>/implementation/unit-integration-report.yaml`；失败时交由工作流回滚到实现修复节点。
+- 将本节点执行过程记录写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID；业务产物仍写入本任务约定的位置。
+procedure:
+- 核对所有必测 Unit 和集成回归均实际执行且通过，报告覆盖每个 Unit 与绑定 case，版本和日志可复核。
+- 核对无跳过、空断言、未解释失败或通过修改测试判定换取的通过结论。
+- 核对全部 Unit 的输入条件、调用生命周期和联合数值/结构证据均对应当前版本；设计约束与补证清单无未闭合项，需要人工检查的源码/编译/设备证据已有明确结论。
+- 将验收结论与证据写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID。
+acceptance:
+- test -s "$WORK_DIR/operators/<op>/implementation/unit-integration-report.yaml"
+out_of_scope:
+- 不修改冻结设计、用例、Golden 或阈值，不执行全量设备精度与性能验证。

package/assets/ops-direct-invoke/skills/ops-direct-invoke/tasks/cannbot-dsl//345/256/236/347/216/260/344/277/256/345/244/215.yaml

@@ -0,0 +1,21 @@
+title: 实现修复｜处理集成与检视问题
+goal:
+- 首轮核对 Unit 实现与测试清单；回滚时根据最新集成或检视报告修复实现问题。
+approach:
+- 修改算子源码时，必须加载 `cannbot-dsl-best-practice` Skill，按其中的要求执行。
+- 运行结构用例时，将 `$WORK_DIR` 加入 `PYTHONPATH`，使用 `CANNBOTDSL_PROBE_MODULE=operators.<op>.probe.<op>_probe`，沿用冻结的探针事件断言。
+- 读取原生 design/units/U*.yaml、testcase.csv、Golden 及已有集成和检视报告；首轮无失败报告时仅完成一致性检查。
+- 有失败报告时逐项定位到 Unit、代码路径和可重现用例，在允许修改的实现代码范围内修复，并记录问题与改动的对应关系。
+- 发生修复时，运行受影响 Unit 的 TDD，并按代码影响覆盖其上游依赖及受影响的下游 Unit 回归；保留原始失败证据，供后续集成复验和检视使用。
+- 将核对或修复记录写入 `$WORK_DIR/operators/<op>/implementation/implementation-fix-修复记录.md`。
+- 修复前区分实现缺陷与设计路线不可行；后者记录具体设计承诺、失败证据与影响，保持失败交既有耗尽/退出流程，由调用方在新轮修订设计与受影响资产，不在本节点替换冻结方案。
+- 将本节点执行过程记录写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID；业务产物仍写入本任务约定的位置。
+procedure:
+- 核对首轮清单完整且实现版本可追溯；回滚时报告中的每个阻断问题都有代码修复或有证据的误报判定。
+- 首轮未修改实现时，核对清单与已有证据的版本对应关系；发生修复时，核对受影响 Unit 及相关回归证据通过、改动未越过允许范围且原始失败证据完整。
+- 核对修复仍满足 Unit 的设计约束与补证通过判据，结构与数值证据分别闭合；设计不可行的记录不能作为修复完成或 PASS。
+- 将验收结论与证据写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID。
+acceptance:
+- test -s "$WORK_DIR/operators/<op>/implementation/implementation-fix-修复记录.md"
+out_of_scope:
+- 不修改已冻结的 DESIGN.md、unit 设计、Golden、TDD 断言或精度阈值，不跳过失败用例。

package/assets/ops-direct-invoke/skills/ops-direct-invoke/tasks/cannbot-dsl//345/256/236/347/216/260/346/243/200/350/247/206.yaml

@@ -0,0 +1,20 @@
+title: 实现检视｜审核代码与集成证据
+goal:
+- 审核完整实现对设计、Unit 边界和测试证据的符合性，阻断尚未解决的问题。
+approach:
+- 核对 `$WORK_DIR/design/doc/DESIGN.md`、原生 design/units/U*.yaml、testcase.csv、实现子图、代码差异与最新 `$WORK_DIR/operators/<op>/implementation/unit-integration-report.yaml`。
+- 检查设计约束、允许修改路径、资源与同步处理、边界条件、错误处理，以及 TDD、Golden、白盒和必要黑盒证据是否完整。
+- 将每个阻断问题定位到代码、Unit 与复现用例，写入 `$WORK_DIR/operators/<op>/implementation/implementation-review-report.yaml`；失败时由工作流回滚到实现修复节点。
+- 逐项追溯原生 Unit 的 design_constraints、feasibility_checks、verification_obligations 到当前源码、编译或设备证据和真实测试输入，区分规格数值正确与设计承诺完成；将未满足项定位到具体承诺、证据缺口及受影响 Unit。
+- 将本节点执行过程记录写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID；业务产物仍写入本任务约定的位置。
+procedure:
+- 核对报告给出明确 PASS 结论，所有阻断问题均已关闭；集成报告对应当前实现版本且所有必测回归通过。
+- 核对必备导出入口、共享编译工厂及 Native 验证证据符合冻结设计，并对应当前实现版本。
+- 核对不存在以缺少证据、跳过测试或放宽阈值换取的通过结论。
+- 核对每项设计强制承诺有符合通过判据的当前版本证据；允许选项内的重构已回归受影响能力，改变强制承诺的替代路线未被数值通过掩盖。
+- 核对结构事件来源真实，实际触发条件与生命周期覆盖成立；设计不可行的问题保持失败，不能在只允许改实现的修复节点中静默降级。
+- 将验收结论与证据写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID。
+acceptance:
+- test -s "$WORK_DIR/operators/<op>/implementation/implementation-review-report.yaml"
+out_of_scope:
+- 不自行改写实现、冻结设计、Golden、测试用例或阈值；不代替全量设备精度验证。

package/assets/ops-direct-invoke/skills/ops-direct-invoke/tasks/cannbot-dsl//345/256/236/347/216/260/351/227/250/347/246/201.yaml

@@ -0,0 +1,17 @@
+title: 门禁｜检查环境状态并决定是否实现
+goal:
+- 根据环境结论决定是否放行实现及其后续验证流程。
+approach:
+- 使用已验收的 `$WORK_DIR/environment/environment.yaml` 和 `$WORK_DIR/design/doc/DESIGN.md`，只确认文件存在且可读取；根据环境结论执行本工作流的放行政策。使用中发现输入矛盾时终止并报告。
+- 将放行或拒绝的决定及所依据的环境状态、设计文件路径写入 `$WORK_DIR/.workflow/implementation-gate-decision.yaml`。
+- '`PASS/full` 时决定为放行；`WARNING/compile_only` 时按本工作流的更严格政策决定为拒绝；`FAIL/blocked` 或未知状态属于契约错误，按执行协议终止本节点并说明证据。'
+- 将本节点执行过程记录写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID；业务产物仍写入本任务约定的位置。
+procedure:
+- 核对门禁决定与 `environment.yaml` 的 `final_status` 原文一致，所引依据文件真实存在。
+- '仅当 `final_status.status: PASS`、`execution_mode: full`、已验收的 `DESIGN.md` 存在且可读取时，确认决定为放行并验收通过。'
+- '`WARNING/compile_only` 时确认决定为拒绝，并判定本节点验收失败，以保证实现、精度、性能、文档、检视和交付节点不被调度。'
+- 将验收结论与证据写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID。
+acceptance:
+- 'test -s "$WORK_DIR/.workflow/implementation-gate-decision.yaml"'
+out_of_scope:
+- 只写本节点的门禁决定和报告，不修改环境或设计产物，不重新执行环境探测或方案设计。

package/assets/ops-direct-invoke/skills/ops-direct-invoke/tasks/cannbot-dsl//346/200/247/350/203/275/344/274/230/345/214/226.yaml

@@ -0,0 +1,22 @@
+title: M6｜性能摸底
+goal:
+- 在精度验证通过的最终算子实现上，用 msprof 采集一个核心 case 的设备性能数据并保存原始证据；本节点只做摸底，不做优化。
+approach:
+- 从 `$WORK_DIR/design/doc/REQUIREMENTS.md` 已确认的性能目标场景选定核心 case：取 `$WORK_DIR/operators/<op>/test/testcase.csv` 中与该场景对应的一条 active blackbox `case_id`；没有完全对应的 case 时记录缺口与来源并终止本节点，不自造输入。
+- 在 `$WORK_DIR/performance/` 编写单进程采集脚本：以 `$WORK_DIR` 为 `PYTHONPATH`，按 `CANNBOTDSL_OP_MODULE=operators.<op>.<op>` 导入算子公开入口（入口非 `run` 时按 `CANNBOTDSL_OP_ENTRY`）；复用该 case 的 `inputs_json` 配方与 `<op>_golden.py` 的 `make_inputs` 构造与精度验证完全相同的输入。
+- 采集脚本先预热调用 10 次再正式采样 10 次：首次预热完成该静态 case 的唯一一次编译，采样循环全部命中编译缓存、零重新编译；将 `CANNBOTDSL_CACHE_DIR` 固定到 `$WORK_DIR/performance/` 下的目录；采集环境不得设置 `CANNBOTDSL_DUMP_*`、`CANNBOTDSL_PRINT_*`、`CANNBOTDSL_REUSE_ASCENDC`、`CANNBOTDSL_PIPE_STAGE`，被测代码不得残留 `cbd.print` 或 `dump_*`。
+- 用 msprof 包裹采集脚本：`msprof --aic-metrics=PipeUtilization --task-time=on --ai-core=on --application=<采集脚本及参数> --output=$WORK_DIR/performance/msprof_<case_id>`；固定设备型号与 `ASCEND_RT_VISIBLE_DEVICES`，不与其他进程共用设备。
+- 从 msprof 输出中提取算子目标 kernel 的 10 次 `Task Duration`，取最小值作为该 case 的性能结论，全部原始样本一并保留；报告注明所统计 kernel 的名称并与算子实现对应，对照已确认的性能目标仅作事实性记录，不作达标放行判定。
+- 将采集脚本、msprof 输出目录、运行命令、退出码、设备与驱动环境及实现版本保存到 `$WORK_DIR/performance/`，汇总报告固定为 `$WORK_DIR/performance/performance-report.md`。
+- 将本节点执行过程记录写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID；业务产物仍写入本任务约定的位置。
+procedure:
+- 核对核心 case 的 `case_id` 可追溯到 `REQUIREMENTS.md` 的性能目标场景，且输入配方与 `testcase.csv` 中该 `case_id` 一致，未自造输入。
+- 核对预热 10 次完成后才进入正式采样，采样期间未发生新的编译（编译日志或缓存证据）；采集环境未设置旁路编译缓存或触发回读的调试类变量，被测代码无残留 `cbd.print` 或 `dump_*`。
+- 核对 `Task Duration` 来自 msprof 原始输出、样本数为 10、取最小值口径一致，所统计 kernel 与算子实现对应，设备与环境固定；报告结论与原始样本一一对应。
+- 将验收结论与证据写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID。
+acceptance:
+- 'test -s "$WORK_DIR/performance/performance-report.md"'
+- 'find "$WORK_DIR/performance" -maxdepth 1 -type d -name "msprof_*" | grep -q .'
+out_of_scope:
+- 不做性能优化，不修改算子实现、测试用例或性能测量数据。
+- 不修改已冻结的规格、Golden、测试阈值或设计事实；不采集核心 case 以外的用例。

package/assets/ops-direct-invoke/skills/ops-direct-invoke/tasks/cannbot-dsl//346/226/207/346/241/243/347/224/237/346/210/220.yaml

@@ -0,0 +1,15 @@
+title: M7｜文档生成与补充
+goal:
+- 为最终算子实现补齐接口、构建、运行、约束和验证文档。
+approach:
+- 基于已通过验收的规格、设计、实现和测试证据编写文档，并标明环境与目标 SoC。
+- 将文档及其来源索引保存到 `$WORK_DIR/documentation/`；文档中的命令和路径须与交付代码一致。
+- 将本节点执行过程记录写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID；业务产物仍写入本任务约定的位置。
+procedure:
+- 核对文档覆盖适用范围、参数、边界、构建运行步骤和验证结果，且与当前实现一致。
+- 抽查文档中的命令和路径与交付代码真实对应。
+- 将验收结论与证据写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID。
+acceptance:
+- 'find "$WORK_DIR/documentation" -name "*.md" -size +0 | grep -q .'
+out_of_scope:
+- 不修改算子实现、测试用例或性能测量结果。

package/assets/ops-direct-invoke/skills/ops-direct-invoke/tasks/cannbot-dsl//346/226/271/346/241/210/350/256/276/350/256/241.yaml

@@ -0,0 +1,32 @@
+title: M3A｜CANNBotDSL 方案设计
+goal:
+- 基于冻结的算子规格与环境事实形成分文件方案，明确数学语义、任务时序、资源与成本依据，并提供一份汇总文档供后续工作流使用。
+approach:
+- 读取 `$WORK_DIR/design/doc/spec.yaml`、`$WORK_DIR/environment/environment.yaml` 和 `$WORK_DIR/environment/env_selected_soc.yaml`。环境为 `FAIL/blocked` 时按工作流政策停止。
+- '`PASS/full` 时，读取选定 SoC 并结合 `npu-arch` 与运行时证据形成 `$WORK_DIR/environment/soc-info.yaml`；SKU 相关的核数、容量和带宽以实际证据为准。'
+- '`WARNING/compile_only` 时，在设计中说明可设计和编译、不可执行 NPU 验证；按本工作流政策在设计后停止，不编造 SoC 或实测数据。'
+- 消费冻结的 `spec.yaml` 分类和语义，将环境、`$WORK_DIR/cannbot-dsl/docs` 文档目录、SoC 信息作为设计输入提供给 `cannbot-dsl-op-design`；不要求 Skill 接收固定路径、证据 schema 或调用其他 Skill。
+- 加载 `cannbot-dsl-best-practice` 的整体实现参考，提取公开调用与导出契约、共享构建依赖、资源存续范围及产物识别的验收条件，纳入 HostLaunch、API、Validation 和 DevView；具体接口示例注明版本与适用前提，支持的导出变体、Native 收集与产物命中转为后续实现和验证的明确义务。影响正确性、接口或实现可行性的依赖必须在本节点确认；无法确认时记录证据并终止。
+- 加载 `ops-design-paradigms` Skill，提供冻结的 `op.paradigms` 与路由所需的 `dsl`，按 Skill 当前的组合优先、语言适配和按需展开规则获取设计知识；语言声明与匹配记录写入节点报告，资料的算法、能力与约束用于核对方案及其适用前提，沿用规格中的范式。
+- 设计正文以数学表达式、任务坐标、数据流、资源模型及算法伪代码描述方案；目标语言与 API 资料用于确认执行能力、接口与产物契约，参考代码保留适用范围、来源和抽象占位说明。
+- 指定 `$WORK_DIR/design/doc/` 为设计输出目录，生成 `INDEX.md`、索引列出的主题文件及 `branches/DESIGN-BRANCH-*.md`。设计内容覆盖算法、接口、执行路径、资源、并行与同步、API、精度和边界验证。
+- 在 Kernel 定义阶段调用次数、计算量、各层搬运量及重复次数，推导共用资源负载、串行依赖和预计瓶颈；在 TemplatePartition 代入代表规模比较可行候选，在 LaunchData 核对物理资源，在 Validation 给确认或推翻成本假设的观测。耗时估算与实测分别注明依据。
+- 按实际执行机制说明阶段次序、协作及资源复用。多个工作项交错推进时，按设计 Skill 的流水模板实例化带索引的时序表、warmup/steady/drain 伪代码及生命周期；阶段数和资源类型依据当前算法确定，具体排布按已匹配的范式资料选择，实际存在的缓冲与状态分别推导份数。
+- 工作流运行 `scripts/assemble_cannbotdsl_design.py --design-dir "$WORK_DIR/design/doc" --output "$WORK_DIR/design/doc/DESIGN.md"`，形成供单文件消费者使用的汇总文档；汇总文件由工作流维护，不要求设计 Skill 自行输出。
+- 将节点执行过程写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID；记录须包含 `ops-design-paradigms` 的语言声明与范式匹配结果（命中清单或兜底说明）。
+procedure:
+- 核对分文件与 `INDEX.md` 一致，分支文件存在；`DESIGN.md` 按索引设计章节和链接顺序汇总，标题层级统一，INDEX 与参考资料正文未嵌入。
+- 核对关键决策可追溯到 spec、环境/API 证据或 `ops-design-paradigms` 命中文档出处，不存在影响正确性、接口或实现可行性的阻断未决项；非阻断事项说明影响和适用边界。
+- 核对正文的公式、坐标、数据流与资源推导完整，引用资料及代码示例的版本、适用条件和验证范围明确。
+- 核对阶段成本、候选选择、资源预算与性能观测一致；阶段耗时缺少依据时保留工作量推导及采集计划，按实际存在的共享资源、状态依赖和流水开销分析。
+- 流水方案核对时序表与伪代码使用相同工作项及阶段偏移，覆盖短任务、实际槽复用和排空；首次/末次来自所属任务的有效范围，每个等待有对应发布，复用发生在最后读完成之后。
+- 核对范式消费记录已声明 `dsl`，遵循 Skill 当前路由规则，命中或兜底理由与冻结规格相符，资料来源可追溯。
+- '`PASS/full` 时，核对 `soc-info.yaml` 与选定 SoC 一致；`WARNING/compile_only` 时核对设计未写入虚构的 NPU 实测事实。'
+- 将验收结论与证据写入 `$WORK_DIR/.workflow/reports/`。
+acceptance:
+- 'test -s "$WORK_DIR/design/doc/INDEX.md"'
+- 'test -s "$WORK_DIR/design/doc/DESIGN.md"'
+- '`environment.yaml.final_status.status: PASS` 时：test -s "$WORK_DIR/environment/soc-info.yaml"'
+out_of_scope:
+- 不编写算子实现，不执行编译、NPU 精度测试或性能测试。
+- 不重新选择 spec 中已冻结的范式分类；范式资料按 `ops-design-paradigms` 的语言边界读取通用层与 DSL 适配资料。

package/assets/ops-direct-invoke/skills/ops-direct-invoke/tasks/cannbot-dsl//346/265/213/350/257/225/347/224/237/346/210/220.yaml

@@ -0,0 +1,29 @@
+title: 测试生成｜Golden、白盒与 Unit TDD
+goal:
+- 生成独立 Golden、白盒与 Unit TDD 用例，以及可供调度的实现子图。
+approach:
+- 先运行 `scripts/validate_unit_contracts.py --units-dir "$WORK_DIR/design/units"` 确认规划产物仍满足交接契约；加载 `cannbot-dsl-test-generator` Skill，将 `$WORK_DIR/design/doc/spec.yaml`、汇总的 `$WORK_DIR/design/doc/DESIGN.md`、`$WORK_DIR/design/units/` 和 `$WORK_DIR/operators/<op>/test/` 分别作为规格、设计、检验义务与测试目录传入。黑盒模块先于本节点写入同一 CSV。
+- 按该 Skill 的 Golden 与测试入口模块生成独立 CPU Golden 和固定入口，完成静态校验及 CPU 样例、边界数值复核，保存原始证据。
+- 按该 Skill 的白盒模块，将设计中的执行路径与验证矩阵转换为 whitebox 用例及有依据的排除项，完成校验并保留证据。
+- 按该 Skill 的 TDD 模块为原生 Unit 的每项验证义务生成并校验用例，结构义务提供可执行事件断言；保留义务、用例及白盒分支的关联证据。
+- 结构用例的探针由对应实现 Unit 写入 `operators/<op>/probe/<op>_probe.py`，模块名为 `operators.<op>.probe.<op>_probe`；本节点定义事件断言与接口契约，不提前伪造探针事件。
+- 对每项 Unit 验证义务建立到 TDD case 和相关白盒分支的可追溯关系；缺少可区分测试时记录对应验证义务与缺项并终止本节点，由框架处理结果。
+- 使用 `scripts/build_implementation_subgraph.py --output-dir $WORK_DIR --harness-script <workflow-orchestrator/scripts/get_task.py>` 从 Unit 和 testcase.csv 生成 `.workflow/implementation-tasks.yaml`；生成器独立复查 Unit 契约，按能力拓扑排序后为重叠或未知写集添加串行依赖，不依赖文件编号顺序。
+- 全部 Unit 叶子汇入 `implementation-fix`，再进入 `unit-integration` 与 `implementation-review`；回滚目标和重试预算沿用本工作流设置。生成节点展开任务 YAML 内容，并通过 harness 校验子图。
+- 编排层负责将 Unit 的 verification_obligations 交给测试生成，将 design_constraints、feasibility_checks 的 obligation_ids 对应到已覆盖义务，将 review_evidence 的产物、检查方法和通过判据交给实现与检视节点。测试 Skill 只负责检验义务到用例的转换与校验，输入物化与结构事件采集契约须可复核；序列与重复要求使用固定 runner 支持的契约，无法表达时记录具体缺口并终止。
+- 将节点执行过程写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID。
+procedure:
+- 核对 Golden 独立于待测实现、设计引用有效，静态校验与 CPU 样例及边界数值复核证据齐备；静态通过不能代替数值正确性。
+- 核对白盒分支使用公开输入并覆盖设计中的真实路径、尾块、同步、dtype、shape、layout 与边界。
+- 核对每项 Unit 验证义务对应至少一个可区分的 TDD 用例；黑盒分组在本节点写白盒和 TDD 后逐行不变；三个分组非空、Case ID 唯一，校验记录对应当前 CSV。
+- 用 harness `get_task.py` 核对实现子图无未知依赖、无环、无孤立 Unit，回滚目标为同子图的传递上游。
+- 核对 Unit 能力依赖、证据关联与实际输入条件校验通过；逐项审查 must_distinguish、coverage_axes 与真实取值和判定的对应关系，脚本通过不代替设计符合性。结构事件来源能被后续 verifier 追溯，不能将静态配置视为设备时序证据。
+- 将验收结论与证据写入 `$WORK_DIR/.workflow/reports/`。
+acceptance:
+- Unit 契约校验退出码为 0，记录对应本轮 Unit 文件；设计约束与补证关联无缺项。
+- test -s "$WORK_DIR/operators/<op>/test/<op>_golden.py"
+- test -s "$WORK_DIR/operators/<op>/test/test_<op>.py"
+- test -s "$WORK_DIR/operators/<op>/test/testcase.csv"
+- test -s "$WORK_DIR/.workflow/implementation-tasks.yaml"
+out_of_scope:
+- 本节点负责生成和验证 Golden；不修改冻结的 spec、设计、Unit、数学及异常语义或精度阈值，不实现算子，不运行 NPU 精度与性能验证。

package/assets/ops-direct-invoke/skills/ops-direct-invoke/tasks/cannbot-dsl//347/216/257/345/242/203/345/260/261/347/273/252.yaml

@@ -0,0 +1,25 @@
+title: M0｜环境检查（并行分支 A）
+goal:
+- 确认本轮 CANNBotDSL 开发环境，并提供对应的 API 参考。
+approach:
+- 必须加载 `cannbot-dsl-env-check` Skill，按其中的要求执行环境探测和证据记录。
+- 以 `$WORK_DIR` 作为 Skill 的 `--output-dir`；不得重命名或改写 Skill 固定生成的文件及 schema。
+- 以 `$WORK_DIR/cannbot-dsl/docs`（创建工作区节点克隆的示例仓文档目录，含 `docs/api/` 接口文档）作为本轮 DSL 文档与 API 参考的唯一来源；核对目录可用，记录其所属 commit SHA 并与创建工作区节点的记录一致；不再提取或生成其他 API 文档产物。
+- 本工作流对 `WARNING/compile_only` 采取更严格的业务政策：仅继续完成方案设计，设计后不进入实现；不得把这一工作流政策写回或伪装成环境 Skill 的原始能力结论。
+- 将本节点执行过程记录写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID；业务产物仍写入本任务约定的位置。
+procedure:
+- 验证 `environment.yaml` 与 `env_selected_soc.yaml` 均可被 YAML 解析，且结论与探测证据一致。
+- 核对 `final_status.status` 为 `PASS`、`WARNING` 或 `FAIL` 之一，并与 `compile_gate`、`execution_mode`、允许/禁止动作及各阶段证据一致。
+- '`final_status.status: PASS` 时，确认 `env_selected_soc.yaml` 的 `selection.selection_status` 为 `SELECTED`，且包含唯一、非空的逻辑设备与芯片标识。'
+- '`final_status.status: WARNING` 时，确认 `final_status.execution_mode` 为 `compile_only`、编译门禁通过且 NPU 运行环境失败。'
+- 确认 `PASS` 与 `WARNING` 的原生语义及本工作流的额外限制均被准确记录、未被混写；`FAIL` 不得被验收为通过。
+- 核对 `$WORK_DIR/cannbot-dsl/docs` 存在且 `docs/api/` 下接口文档内容非空，文档所属 commit SHA 与创建工作区节点的记录一致。
+- 核对节点记录已声明 `$WORK_DIR/cannbot-dsl/docs` 为本轮文档与 API 参考的唯一来源，未生成或引用其他 API 提取产物。
+- 将验收结论与证据写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID。
+acceptance:
+- 'test -s "$WORK_DIR/environment/environment.yaml"'
+- 'test -s "$WORK_DIR/environment/env_selected_soc.yaml"'
+- 'test -d "$WORK_DIR/cannbot-dsl/docs/api"'
+- 'find "$WORK_DIR/cannbot-dsl/docs" -name "*.md" -size +0 | grep -q .'
+out_of_scope:
+- 不安装或修改系统环境，不生成算子规格、测试用例或设计方案。

package/assets/ops-direct-invoke/skills/ops-direct-invoke/tasks/cannbot-dsl//347/262/276/345/272/246/351/252/214/350/257/201.yaml

@@ -0,0 +1,25 @@
+title: 全量精度验证｜冻结用例与阈值的设备实测
+goal:
+- 在实现与检视 Agent Loop 完全通过后，用最终算子源码运行已接入的黑盒、白盒和 TDD 用例，依据已校验的独立 <op>_golden.py 完成全量精度验证。
+- 保存逐例原始结果和可复核的精度结论；全部必测用例通过后才放行性能与文档节点。
+approach:
+- 核对 `$WORK_DIR/design/doc/spec.yaml`、`$WORK_DIR/design/doc/DESIGN.md`、`$WORK_DIR/operators/<op>/test/<op>_golden.py`、`$WORK_DIR/operators/<op>/test/test_<op>.py`、`$WORK_DIR/operators/<op>/test/testcase.csv`、最终算子源码以及实现集成和检视报告；缺失或前序工作未通过时停止。
+- 将 `$WORK_DIR` 加入 `PYTHONPATH`，将 `CANNBOTDSL_OP_MODULE` 设为 `operators.<op>.<op>`；结构用例将 `CANNBOTDSL_PROBE_MODULE` 设为 `operators.<op>.probe.<op>_probe`（`<op>` 取 `spec.op.name`）。公开入口不是 run 时设置 CANNBOTDSL_OP_ENTRY；目标异常未直接暴露 spec 错误代码时，提供并验证 CANNBOTDSL_ERROR_MATCHER。分别以 `--sheet blackbox|whitebox|tdd --device npu --require-accelerator` 运行固定 test_<op>.py；实际设备名可按环境替换，但禁止 CPU 冒充目标设备。结构 TDD 需核验探针的 `reset()/snapshot()` 接口与算子记录的事件一致。三个逻辑分组都必须非空且逐例通过。Golden 的公开接口与当前 spec 一致，精度容差以 spec.yaml 的 numerical_tolerance.per_dtype 为准。
+- 黑盒 case 必须与 CSV 黑盒行及按需重算的覆盖报告对齐；`match_golden_nan` 只在 spec 明示的 NaN 场景采用，`raises_error:<code>` 必须由目标入口实际抛出匹配的错误语义，环境、输入构造或任意异常都不得算作成功。
+- 固定算子实现版本、设备型号、驱动与运行环境、测试框架版本和输入集合；在目标设备上执行全部黑盒、白盒和 TDD 用例，分别保留 test_<op>.py 写入 testcase_output/{blackbox,whitebox,tdd}/ 的逐例结果 CSV、运行命令、退出码、逐例结果和原始日志；如逐例调用则保留带 case_id 的独立结果文件。
+- 对 NaN/Inf、尾块、dtype、shape、layout、边界值与多输出逐项检查；任何失败都保留可重现输入和失败诊断，不删除用例、不修改 Golden、规格或阈值以换取通过。
+- 将命令、退出码、环境及实现/用例版本记录写入 `$WORK_DIR/precision/execution.yaml`，原始运行日志写入 `$WORK_DIR/precision/execution.log`，汇总结论写入 `$WORK_DIR/precision/precision-report.md`；报告引用三个分组原生结果 CSV 的路径、用例清单及覆盖关系；如果设备不可用、用例未接入或实际运行被跳过，结论必须为未验证，不得标记 PASS。
+- 将本节点执行过程记录写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID；业务产物仍写入本任务约定的位置。
+procedure:
+- 核对 `$WORK_DIR/precision/` 中的执行记录、日志及汇总报告，并读取报告引用的原生逐例结果 CSV；确认全部证据可追溯到冻结用例清单。
+- 核对 blackbox、whitebox、tdd 三组全部必测用例均在目标设备真实执行且通过当前生效的判定规则；不存在跳过、伪造结果、缺失输出或未经解释的覆盖缺口。
+- 核对数值例报告包含实际生效的误差指标与阈值、实测值和 pass/fail；结构例报告包含每项可执行断言及探针事件实测值。
+- 核对精度容差以 `spec.yaml` 的 `numerical_tolerance.per_dtype` 为准；`match_golden_nan` 只在 spec 明示的 NaN 场景采用；`raises_error:<code>` 由目标入口实际抛出匹配的错误语义，环境、输入构造或任意异常均未算作成功。
+- 核对失败、超时或环境问题均未被汇总为通过。
+- 将验收结论与证据写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID。
+acceptance:
+- 'test -s "$WORK_DIR/precision/execution.yaml"'
+- 'test -s "$WORK_DIR/precision/execution.log"'
+- 'test -s "$WORK_DIR/precision/precision-report.md"'
+out_of_scope:
+- 不修改已冻结的规格、设计、用例、Golden 或精度阈值，不做性能优化，不以精度节点内的隐式修复代替重新执行实现与检视闭环。

package/assets/ops-direct-invoke/skills/ops-direct-invoke/tasks/cannbot-dsl//350/247/204/346/240/274/347/224/237/346/210/220.yaml

@@ -0,0 +1,18 @@
+title: 规格｜生成结构化算子规格
+goal:
+- 将已确认的需求转换为结构化算子规格。
+approach:
+- 必须加载 `ops-spec-gen` Skill，使用其非交互入口，按其中的要求执行。
+- 生成前必须读取该 Skill 的 category、paradigm 和 category-paradigm 映射注册表；范式分类在本节点完成并冻结，后续设计节点不得重新选择。
+- 读取需求分析节点的有效产物，生成算子接口、输入输出、属性、数据类型、shape、格式、约束、异常语义、精度标准和性能目标，以 `$WORK_DIR/design/doc` 作为生成器 `--output-dir`。
+- 依据已确认需求补齐规格并执行 Skill 的完整校验，保存命令、退出码和 findings；缺少依据或存在未决项时记录并终止，不补造事实。
+- 将本节点执行过程记录写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID；业务产物仍写入本任务约定的位置。
+procedure:
+- 审查执行者的完整校验记录，确认对应当前 spec 且返回 0；证据不足时退回补齐，不重跑同一校验代替执行者提供证据。
+- 逐项核对 `spec.yaml` 覆盖接口、输入、输出、属性、dtype、shape/格式约束、精度口径和异常边界。
+- 核对每条规格可追溯到 `$WORK_DIR/design/doc/REQUIREMENTS.md` 的已确认需求；不存在 TODO、会阻断黑盒设计或方案设计的未决项及相互冲突的约束。
+- 将验收结论与证据写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID。
+acceptance:
+- 'test -s "$WORK_DIR/design/doc/spec.yaml"'
+out_of_scope:
+- 不生成测试代码、CANNBotDSL 实现或设计方案。

package/assets/ops-direct-invoke/skills/ops-direct-invoke/tasks/cannbot-dsl//351/234/200/346/261/202/345/210/206/346/236/220.yaml

@@ -0,0 +1,16 @@
+title: M1｜需求分析（并行分支 B）
+goal:
+- 将已确认的算子需求整理为可供规格生成消费的需求记录。
+approach:
+- 读取启动前已确认的 `$WORK_DIR/需求分析.md`、原始任务及输入约束，整理为下游规格所需的需求记录；本节点不重新调用交互式需求对齐 Skill。
+- 在 `$WORK_DIR/design/doc/REQUIREMENTS.md` 记录接口、输入输出、目标环境、精度与性能要求、边界条件和未决事项的来源。
+- 发现影响规格生成的缺项或冲突时记录来源与影响并终止本节点，不自行决定，也不在运行中等待用户答复。
+- 将本节点执行过程记录写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID；业务产物仍写入本任务约定的位置。
+procedure:
+- 核对 `REQUIREMENTS.md` 各项要求与用户确认记录可追溯。
+- 核对接口、约束和验收口径与确认记录一致；仍有影响规格的缺项或冲突时不通过，标注阻塞不等于需求已就绪。
+- 将验收结论与证据写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID。
+acceptance:
+- 'test -s "$WORK_DIR/design/doc/REQUIREMENTS.md"'
+out_of_scope:
+- 不生成 `spec.yaml`、设计方案、测试用例或算子实现。

package/assets/ops-direct-invoke/skills/ops-direct-invoke/tasks/cannbot-dsl//351/273/221/347/233/222/347/224/250/344/276/213/350/256/276/350/256/241.yaml

@@ -0,0 +1,19 @@
+title: M2｜CANNBotDSL 黑盒用例设计
+goal:
+- 依据冻结规格形成覆盖合法行为、边界及异常语义的可执行黑盒用例。
+approach:
+- 必须加载 `cannbot-dsl-test-generator` Skill，只运行其 DSL 黑盒用例设计模块；输入与输出均以本工作流的 CANNBotDSL 算子契约为准。
+- 将 `$WORK_DIR/design/doc/spec.yaml` 与 `$WORK_DIR/operators/<op>/test/` 分别作为规格和测试目录传给 Skill，按其当前黑盒设计与校验方法执行，保存覆盖报告及校验记录。
+- 直接编写 `$WORK_DIR/operators/<op>/test/testcase.csv` 的 blackbox 行，每例绑定真实 spec 路径、公开输入配方、预期 Golden 比较或 spec 错误代码；不能用固定输入配方表达的复杂布局/结构明确记录排除理由或设计经验证的扩展，不以口头声明代替可执行 case。
+- 本节点只编辑 `$WORK_DIR/operators/<op>/test/testcase.csv` 的 blackbox 分组。异常用例必须对应 spec.op.error_codes 和 raises_error 语义；生成阶段不调用被测算子，也不依赖 DESIGN.md、Golden 或 Unit。
+- 将本节点执行过程记录写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID；业务产物仍写入本任务约定的位置。
+procedure:
+- 核对 `spec.yaml` 的数学语义、dtype 组合、语义分支、边界和极值均有可追溯的 case ID 或明确排除理由。
+- 核对 testcase.csv 中的输入名称、dtype、rank 与预期错误代码通过脚本校验。
+- 核对 `operators/<op>/test/testcase.csv` 的 blackbox 逻辑分组非空、case_id 唯一，且生成阶段未调用被测算子。
+- 核对未将外部用例表或未执行场景写成已通过结果；黑盒设计只产用例，实际设备判定留给精度验证节点。
+- 将验收结论与证据写入 `$WORK_DIR/.workflow/reports/`，文件名包含节点 ID。
+acceptance:
+- 'test -s "$WORK_DIR/operators/<op>/test/testcase.csv"'
+out_of_scope:
+- 不实现算子，不生成 Golden、白盒或 TDD 用例，不执行设备精度和性能测试。

package/assets/ops-direct-invoke/skills/ops-direct-invoke/templates//344/273/243/347/240/201/346/243/200/350/247/206/346/212/245/345/221/212.md

@@ -0,0 +1,70 @@
+# {算子名称} 代码检视报告
+
+> 算子开发节点的 verifier 产出，与该节点的全量黑盒验收共同构成放行条件。对全部变更文件做多维度检视。本仓采用 direct launch 工程架构，须额外核对提交反作弊红线（当前任务指定的 A 类条款，违反 = 提交无效）。不通过时列出具体问题和证据，不自行回退上游任务。
+
+## 检视摘要
+
+- 产出节点 ID：{节点 ID}
+- 被检视代码版本：{提交号或变更快照标识}
+
+| 维度 | 结果 | 详情 |
+|------|------|------|
+| 提交反作弊（A 类） | {通过/有问题} | A1–A7 全部通过，附代码证据 |
+| 代码规范（B 类） | {通过/有问题} | B 类编码规则全部通过，附代码证据 |
+| 需求与实现 | {通过/有问题} | 满足已确认需求和硬件约束，schema 对齐；不要求照搬知识搜集草稿 |
+| 文档与实现同步 | {通过/有问题} | 见下方核对表 |
+| 潜在风险 | {通过/有问题} | 越界、精度、并发等 |
+| 冗余清理 | {通过/有问题} | |
+
+## 文档与实现同步核对
+
+> 算子开发阶段尚未生成白盒用例，不要求预先交付；尚未执行的文档准备不作为缺失产物。经历过回退迭代的交付件为重点核对对象——代码多轮更新而文档停留在早期快照。
+
+| 文档 | 声明内容 | 代码实际 | 是否一致 | 应刷新点 |
+|------|----------|----------|----------|----------|
+| {分支覆盖说明} | | | {一致 / 不一致} | |
+| {当前实现记录与调整依据} | | | | |
+| {交付说明 / 算子文档} | | | | |
+
+## 提交反作弊核对（A 类，零容忍）
+
+| 红线编号 | 条款 | 结果 |
+|----------|------|------|
+| A1 | 不调 PyTorch/torch_npu 计算代算 | {通过/违规} |
+| A2 | 不用 PyTorch/torch_npu 处理输入输出 tensor | {通过/违规} |
+| A3 | 不路由 CANN 内置同名算子 | {通过/违规} |
+| A4 | 不 CPU fallback | {通过/违规} |
+| A5 | 不缓存/固定/按地址命中输出 | {通过/违规} |
+| A6 | 不篡改 profiler/timing API | {通过/违规} |
+| A7 | 不返回 FakeTensor/懒求值包装器 | {通过/违规} |
+
+## 变更范围
+
+| 文件 | 变更类型 | 说明 |
+|------|----------|------|
+
+## 问题清单
+
+### {编号}. {问题标题}
+
+- **维度**：{规范/一致性/风险}
+- **严重程度**：{阻塞/高/中/低}
+- **位置**：{文件:行}
+- **描述**：{问题表现}
+- **建议**：{修改建议}
+
+## 总结
+
+{整体质量评价}
+
+## 检视结论
+
+**结论**：{通过 / 不通过}
+
+{不通过时汇总结构化修改意见，指明 算子实现中的具体修改点}
+
+## 附录：修订记录
+
+| 版本 | 日期 | 修改内容 |
+|------|------|----------|
+| v1.0 | {YYYY-MM-DD} | 初始检视 |

package/assets/ops-direct-invoke/skills/ops-direct-invoke/templates//345/212/237/350/203/275/351/252/214/346/224/266/346/212/245/345/221/212.md

@@ -0,0 +1,80 @@
+# {算子名称} 功能验收报告
+
+> verifier 核对 executor 提供的本阶段真实用例运行证据，不重复构建或执行测试。算子开发节点检查全量黑盒；白盒测试节点记录黑盒回归与白盒运行，用例正确但暴露的算子缺陷交给代码修复。测试任务通过不代表所有算子用例通过，必须分别记录。
+
+## 验证摘要
+
+- 产出节点 ID：{节点 ID}
+- 被验收代码与测试版本：{提交号或变更快照标识}
+- 验收范围：{本阶段已确认的完整用例集}
+
+| 验证项 | 结果 | 详情 |
+|--------|------|------|
+| 编译验证 | {通过/失败} | {构建命令、退出码和日志路径} |
+| schema 注册 | {通过/失败} | {与需求接口一致，`torch.ops.<pkg>.<op>` 可调用} |
+| 精度验证 | {通过/失败} | {通过数}/{总数} 用例通过 |
+| 白盒覆盖 | {通过/失败/本阶段未生成} | 源码路径与用例对应，实际命中、失败及受阻项分别列证据 |
+
+## 关键指标
+
+| 指标 | 值 |
+|------|----|
+| 评测/测试报告 | {测试入口输出和比对结果路径} |
+| 用例总数 | {全量用例表条目数，含补充用例} |
+| 通过率 | |
+| golden 实现 | {测试方案约定的 golden 文件路径与版本} |
+| 执行计数一致性 | {生成数 == 用例数 == 执行数} |
+
+## 测试明细
+
+| 用例编号 | 名称 | 结果 | 说明 |
+|----------|------|------|------|
+
+## 源码与白盒用例对应
+
+| 源码分支 ID | 白盒设计条目 | 源码位置与条件 | 用例 ID | 实际命中证据 | 结论 |
+|-------------|--------------------|----------------|---------|--------------|------|
+
+> 白盒用例覆盖以实际源码为准，不要求与知识搜集草稿一致。区分测试问题与被测算子缺陷，不能伪造覆盖；受算子缺陷影响的覆盖交给修复节点验证。
+
+## 失败用例
+
+{逐条列失败用例、现象、初步定位（附测试报告失败明细）；无则填"无"}
+
+## 精度说明
+
+> 按测试方案精度判定口径表逐**输出张量**填写。实测值从 executor 提供的原始结果核对，并核验其对应当前源码、测试与构建产物版本（不只采信自述结论），最差用例指该输出张量上指标最差的那条用例。
+
+| 输出张量 | dtype | 判定指标 | 阈值 | 最差用例 | 实测值 | 权威源出处 | 结论 |
+|----------|-------|----------|------|----------|--------|------------|------|
+| | | | | | | | {达标 / 不达标} |
+
+| 项目 | 内容 |
+|------|------|
+| 比对基准 | {测试方案约定的 golden 文件路径与版本} |
+| 权威口径实例化方式 | {口径断言的执行位置与本次执行方式} |
+| 交叉核对（自建容差） | {结论；与权威口径不一致时标注该分叉，并说明以权威口径为准} |
+| 口径一致性 | {口径表取值与权威源逐项一致 / 差异项及处理} |
+
+## 验收结论
+
+**用例运行结论**：{通过 / 不通过 / 本阶段未执行的范围}
+
+**当前任务结论**：{通过 / 不通过；白盒任务按用例质量与框架接入判定，算子缺陷列入修复交接}
+
+{不通过时给出结构化修改意见，标注问题语义归属并指明问题所在环节（算子实现 / 测试方案的精度判定口径）的具体修改点}
+
+## 测试环境
+
+| 项目 | 内容 |
+|------|------|
+| 目标芯片/架构 | {芯片} / {ascend910b / ascend910_93 / ascend950} |
+| CANN 版本 | {版本} |
+| 执行方式 | {测试入口命令及运行目录} |
+| 测试依赖 | {实际使用的依赖和版本} |
+
+## 附录：修订记录
+
+| 版本 | 日期 | 修改内容 |
+|------|------|----------|
+| v1.0 | {YYYY-MM-DD} | 初始版本 |

package/assets/ops-direct-invoke/skills/ops-direct-invoke/templates//346/265/213/350/257/225/346/211/247/350/241/214/350/256/260/345/275/225.md

@@ -0,0 +1,73 @@
+# {节点 ID} {步骤名称} 测试执行记录
+
+> executor 产出，不代写验收结论。技术穿刺记录下发范围的代表用例；算子开发提供全量黑盒证据，白盒测试与代码修复提供全量黑盒和已接入白盒的证据；符合下述条件时可引用已有有效执行结果。原始输出、哈希清单和逐用例结果独立保存，本报告只给摘要与路径，不复制全文。
+
+## 验证范围
+
+- 本节点要验证的目标、关键疑点与采用路线：
+- 本次范围及未验证范围：
+- 下一轮可复用的代码、测试入口及证据绝对路径与版本：
+
+穿刺必须记录关键端到端组合在目标设备的运行结果；资料推导、CPU 自检或模拟执行不能代替。只对穿刺范围给结论，不宣称正式全量交付。
+
+## 证据清单与引用
+
+- 执行或复用：{本次新执行 / 复用；复用不计为新增设备执行}
+- 输入与版本清单绝对路径：{每次真实执行生成一次 `<节点ID>-证据-r<轮次>/<节点ID>-清单.json` 或清单文本}
+- 原始结果索引：{构建日志、测试命令及退出码、逐用例结果、加载记录的路径与哈希}
+- 本次变更及复用判断：{差异路径、受影响项、复用来源与适用范围}
+
+清单覆盖需求、源码、注册/打包/构建配置、测试及用例 ID、golden、checker/阈值配置、随机种子、实际工具链/设备环境、wheel 和加载库。大清单单独保存，下文引用路径与条目，不重复抄写哈希或用例明细。清单与日志保留原版本，变更生成新的清单，引用必须落到具体执行轮次，不能使用会被覆盖的 latest 路径。只记录决定本次结果的输入，不对所有阅读资料重复计算哈希。
+
+## 版本与构建
+
+- 需求及测试方案版本：
+- 源码、测试、golden 和构建入口的路径与哈希（包含未提交变更）：
+- 构建命令、工作目录、环境及退出码：
+- 原始构建日志绝对路径：
+- 构建产物绝对路径与哈希：
+- 运行时实际加载模块路径与哈希（应与本次构建一致）：
+
+## 本阶段运行
+
+- 测试入口、实际命令、运行目录及退出码：
+- 原始输出、机器可读结果与逐用例明细路径：
+- 本阶段用例清单及版本（正式交付全量；穿刺列代表用例）：
+- 实际设备型号与执行位置：
+
+| 范围 | 应执行数 | 实际执行数 | 通过 | 失败 | 跳过 | 未执行 |
+|------|----------|------------|------|------|------|--------|
+| 穿刺代表用例（正式开发不适用） | | | | | | |
+| 黑盒（正式开发） | | | | | | |
+| 白盒（未生成时不适用） | | | | | | |
+
+计数应与原始结果逐条一致，不能只给汇总通过率。逐输出记录精度指标、阈值、实测值及判定结果；源码分支覆盖区分设计覆盖、实际命中与受阻路径。复用与重跑按以下规则确定；不能使用旧版本日志掩盖当前失败。
+
+## 证据复用规则
+
+| 当前变化 | 必须完成的验证 |
+|----------|----------------|
+| 无待修复缺陷；决定结果的输入、版本、配置及设备环境一致；已有本阶段要求的全量成功记录 | 引用原始证据并核对当前交付与清单一致，不重复构建或测试 |
+| 仅报告文字或许可注释变化 | 核对完整差异确实不影响执行，保留新旧哈希及映射；符合条件时复用，不声称重新构建或重跑 |
+| Python logging 等可执行语句变化 | 不能按纯注释处理；验证受影响的输出、计数、退出码与异常行为。只有证实计算、参数、断言、控制流和执行环境未受影响时，才能复用原设备结果，否则重跑 |
+| 算子计算、注册/包装、打包、编译配置或工具链变化 | 重建并运行本阶段要求的全量回归，复核实际加载路径和二进制 |
+| 用例、golden、checker/阈值、数据生成、种子或测试逻辑变化 | 重新运行本阶段全量回归；候选构建输入未变时可复用 wheel。不得放宽标准消除失败 |
+| 设备或运行环境变化；原证据缺失、不完整、含失败或无法对应当前版本 | 补齐当前环境下的完整验证；不能证明构建仍适用时重建 |
+
+穿刺代表用例不能替代正式全量；上一阶段黑盒通过不能替代新增白盒的执行。后续节点仍核对全量用例 ID 与结果，不能只引用上一份报告的 pass。复用时在本阶段报告记录来源及差异判断，verifier 独立确认复用条件；有疑点即要求执行者补证据，不由验收者代跑。
+
+## 失败与归属
+
+| 用例 ID | 现象与复现命令 | 原始证据 | 算子 / 测试 / 框架问题 | 影响范围 |
+|---------|----------------|----------|-------------------------|----------|
+
+白盒阶段允许如实记录被正确用例暴露的算子缺陷，供下一节点修复；算子开发与修复交付要求本阶段全量通过。不能删测、放宽阈值或隐藏失败来取得通过。
+
+## 重试记录
+
+- 对应验收报告的问题编号及修复内容：
+- 本次证据目录：{使用节点 ID 前缀及不同轮次后缀，保留前次日志}
+- 修改后的文件与新哈希：
+- 复用证据路径及有效性依据，或阻塞条件未变的复核结果：
+
+重试只补差异；失败、未运行和未验证项如实记录，不以重复生成报告替代修复。