SKILL.md 3.64 KB

Edit Raw Blame History Permalink



name: unit-tester-verify-loop
description: "自测节点操作手册：读上游 artifact → 真实工具跑检查 → 交付 test.log 的四段式细则，含网页/代码两类产物的检查手段选择。"
layer: 2
domain: verification
keywords:


unit-tester
test
acceptance-test

  - research-plan-execute-verify
Skill: 自测节点操作手册
何时用
每次收到一个「自测/验证上游实现」类任务时，无论被测产物是网页还是代码，四段式都不跳。
开工前先定位三类路径（每次任务都做，不要复用上次记忆）
任务描述里有几段绝对路径，本文件和 agent.md 都不写死，因为它们随任务变化：


[上游输入] —— 被测 artifact 与相关规格（prd/sdd/acceptance）在哪，逐个读。
标 ⚠️ 的表示还没产出，汇报 blocked。
[节点产物目录] —— _research.md / _plan.md / _lessons.md / test.log 落在这里。

先判断被测产物是哪一类，检查手段不一样


产物类型
用什么真的测


网页/静态站点（index.html/.css/.js）
node scripts/visual-acceptance-check.mjs overflow --file <path> --widths <...>（视口横向溢出）、style --selector <sel> --prop <css属性>（真实计算样式）、console --file <path>（Console 报错 + 失败请求）、contrast --fg <hex> --bg <hex>（WCAG 对比度）——四个子命令各自吐一行 JSON，脚本头部注释有完整用法


代码/接口
产物自带的测试命令（package.json 的 test 脚本）或上游 sdd/acceptance 里点名的命令，真的跑一遍


两者都不是
如实说明这类产物用什么方式验证，不要因为没有现成工具就编一份假检查


四段式细则
RESEARCH

读上游 artifact 与相关规格，判断产物类型、acceptance 逐条对应什么检查手段。
有 ⚠️ 缺失的输入立即判断能不能开工，不能就汇报 blocked。
写 _research.md：产物类型判断 + acceptance 与检查手段的对应关系 + 已知空缺。
流转：node ../../../../../bin/lemon.js task transition --agentId <你的ID> --phase plan --artifact <_research.md路径>

PLAN

只凭 _research.md。逐条列出：这条 acceptance 用哪个具体命令测、预期结果是什么。
写 _plan.md，流转：
node ../../../../../bin/lemon.js task transition --agentId <你的ID> --phase execute --artifact <_plan.md路径>

EXECUTE

只凭 _plan.md。这是唯一允许真的跑检查命令的阶段。
一条一条跑，每跑完一条就把真实输出（命令的原始 stdout/退出码，不是复述）追加进 test.log。
命令跑不起来（工具报错、被测文件缺失）本身就是 blocked，别跳过继续跑下一条再假装没事。

VERIFY

核对 test.log 每条 acceptance 是不是都有真实输出支撑，没有的话回 EXECUTE 补测。
全部有真实依据 → report_task({status:"PASS"})，附 test.log 路径 + 跑了几条、各自结果。
有 acceptance 不过 → report_task({status:"blocked"})，说明哪条、真实输出是什么——
不要为了让流程走下去而软化一个真实的 fail。

硬规矩（违反即事故）

用正则解析源码文本冒充浏览器检查（网页类产物必须用 visual-acceptance-check.mjs 或等价的
真实渲染手段，不是字符串匹配）。
未走完四段直接写 test.log 或汇报 PASS。
工具跑不起来时默认"大概率没问题"而不是如实汇报 blocked。
发现被测代码有 bug 时自己动手改——那是 org-coder-impl 的活，你只负责记录发现。