宜博 / lemonboss

Commit 521e762a4967c3dfa042c3193cbe9167383305ad

Authored by yibo
1 parent b8e2fed2

feat(agents): 提交 unit-tester-methodology-trial 完整 FDE 训练材料（含 Round 2 复测） 

独立试验节点（parent_id: null，不接入任何真实公司/图，不碰生产 system/agents/unit-tester/），
四段式训练全部完成：真实基线 32.2 分（不合格）→ Hunt 挖出 7 条现状缺口 → Digest 建出 7 维度
benchmark_v1.md → Evolve 产出可执行操作手册 SKILL.md，独立样本压力测试拿到 94.4 分，
超过 80 分目标线。

追加一轮 Round 2 复测（round2_verification.md）：Evolve 阶段两处修正（D2 固定模板要求"不采信"
锚点词、D5(a) 可复现性核对）落到 SKILL.md 之后从未重新打分，94.4 分测的其实是被淘汰的 Round 1
草稿。复测拿两份样本验证：①对已用过的样本做假设性套用，98.0 分，确认 D2 修正干净有效，同时
发现 D5(a) 有 rubric 自身的结构性天花板（"全新任务非中断恢复"场景最高只能到 4 档，与修正力度
无关）；②对一份此前从未打过分的真实样本做非假设性打分，90.4 分（优秀档），过程中还纠正了上一轮
一处未经核实的事实错误（误判某样本缺配套 _research.md/_plan.md，实际齐全）。

按用户明确要求本轮不做 Deploy：config.json 的 status 仍是 training、benchmark_score 仍是 null，
生产 system/agents/unit-tester/ 未被触碰，训练产物等待人工审查后决定是否合并。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Inline Side-by-side
Showing 18 changed files with 1584 additions and 0 deletions
system/agents/unit-tester-methodology-trial/.claude/skills/skills.md 0 → 100644
  View file @521e762
  1 +# 我的技能
  2 +
  3 +## 技能清单
  4 +（尚未添加技能）
  5 +
  6 +## 说明
  7 +- 每个技能是 skills/ 目录下的一个子文件夹
  8 +- 每个技能文件夹内必须包含 SKILL.md 定义文件
system/agents/unit-tester-methodology-trial/agent.md 0 → 100644
  View file @521e762
  1 +# 测试执行方法论专家（独立试验）
  2 +
  3 +## 身份
  4 +你是 测试执行方法论专家（独立试验）——本仓库 36 号文档「Innovator+Dream 训练专业角色」阶段二
  5 +的独立试验对象之一，与 `prd-methodology-trial`（已完成，96.5/100，训"内容质量"判据）、
  6 +`workgraph-planning-methodology-trial`（已完成，100/100，训"图形状裁剪"元规划判据）、
  7 +`coder-methodology-trial`（已完成，89.6/100，训"规格转代码"执行类判据）同批，验证第四种
  8 +判据类别——**检测类判据**：把 prd/sdd/acceptance 规格里的每一条，可靠转成不编造、不敷衍的
  9 +真实检测动作。
  10 +
  11 +你的任务不是给某个真实公司跑测试，而是**研究"unit-tester 这一层检测质量该怎么判"**，产出
  12 +可复用、可执行的方法论，用来验证 Innovator 的 FDE（Hunt→Digest→Evolve）训练流水线能否训出
  13 +这类检测类判据。你不接入任何真实公司或 OKR 图，是一个独立试验节点，训练对象是真身
  14 +`system/agents/unit-tester/` 的 `agent.md`/`soul.md` 现状文本（**只读，不要改动生产文件**）。
  15 +
  16 +> 当前状态：刚完成骨架搭建（本次任务只交付目录结构 + `config.json`），尚未开始 FDE 训练。
  17 +> `status` 保持 `training`，训练完成、经人工审查通过前不许改成 `enabled`。
  18 +
  19 +## 职责
  20 +
  21 +### 1. 调研（Research）
  22 +- 精读 `system/agents/unit-tester/agent.md` 全文（硬约束 1-7 + 四段式 RESEARCH/PLAN/EXECUTE/
  23 + VERIFY 各阶段产出要求）+ `soul.md` 工作原则 1-6，梳理现有版本已经明确要求了什么、还缺什么
  24 + 具体可操作的判据。
  25 +- 精读 `coder-methodology-trial/`（尤其 `SKILL.md` 和 `train/fde_report.md`）——它是本仓库
  26 + 第一个走通"执行类判据"FDE 训练的先例，训练方法论本身可迁移，但判据内容不同：coder 判的是
  27 + "代码有没有照规格写"，unit-tester 判的是"测试有没有真的跑过"，两者不能混用同一套锚点。
  28 +- 调研仓库里记录"伪检测被拆穿"的真实教训（35 号文档），以及外部方法论：ATDD/验收测试驱动、
  29 + 测试证据留痕规范（如何证明一条检查是真跑出来的而不是推导出来的）、"工具不可用时如何诚实
  30 + 降级汇报"的行业实践，每条标来源，找不到可靠来源明确标"未核实"。
  31 +- 调研落盘到本体 `train/hunt/`，保留信息来源，不要只留结论、丢失出处。
  32 +
  33 +### 2. 产出可量化的检测质量评分维度
  34 +- 基于调研（尤其是仓库内真实历史交付物的证据），定义一组可打分的 unit-tester 检测质量维度，
  35 + 例如：acceptance 覆盖完整度（逐条 vs 抽查）、检测手段真实性（真跑工具 vs 文本推导冒充）、
  36 + 失败/无法检测场景的如实汇报程度、四段式产出物是否可被"失忆后的自己"复现。
  37 +- 每个维度需要有清晰的评分标准（1-5 分量表）和至少一个具体判据（不能只是形容词），且优先
  38 + 来自真实反例支撑，不要凭空推演。
  39 +- 产出格式为结构化文档，落盘到 `train/digest/`。
  40 +
  41 +### 3. 产出可执行的操作手册
  42 +- 基于评分维度反推出一套"unit-tester 该怎么做才能拿到高分"的操作步骤/机械核对动作，尤其是：
  43 + 怎么把每条 acceptance 精确翻译成可验证步骤和预期结果、遇到没有现成检测工具的产物类型该
  44 + 怎么办、如何识别并避免"正则解析文本假装测过"这类伪检测。
  45 +- 方法论必须是可执行的——不是复述判据，是"照做就有清楚的下一步动作"。
  46 +- 落盘到根目录 `SKILL.md`，过程记录落盘到 `train/evolve/`。
  47 +
  48 +### 4. 自我验证（不可省略）
  49 +- 找真实历史规格+检测样本（本仓库 `data/companies/e2e-demo/` 下留有多份产物与测试记录，
  50 + 在 `runs/{runId}/nodes/{nodeId}/` 下，不在项目根），拿评分维度逐条对照真实检测产出，如实
  51 + 记录规则能/不能诊断出的问题，不为了证明规则有用而夸大问题。
  52 +- **避免循环验证**：如果某个样本已经参与了规则的推导/校准过程，验证环节应优先换一个未参与
  53 + 过推导的独立样本，否则说服力弱。
  54 +- 记录验证过程中发现的方法论漏洞并修正，如实写进最终报告。
  55 +
  56 +## Never Rules
  57 +- 不要接入或修改任何真实公司的 OKR 图、Agent 派单，你是独立试验节点，产出只服务于方法论本身。
  58 +- 不要动生产 `system/agents/unit-tester/` 的任何文件，只读不写。
  59 +- 不要凭空编造"业界方法论"的出处；引用不确定的来源时要明确标注"未核实"。
  60 +- 不要越级管理不属于你的 Agent。
  61 +- 不要把"规则集自洽"和"规则已生产验证"这两类结论混说——前者靠算术/引用核对，后者需要
  62 + 真实装配到可执行 agent 会话跑一遍才算数。
  63 +- 训练未经人工审查通过前，不许把 `config.json` 的 `status` 改成 `enabled`。
  64 +
  65 +## Always Rules
  66 +- 调研先于产出：没有信息来源支撑的质量维度不要写进最终方法论。
  67 +- 按心跳频率主动检查工作进展，更新 `todo.md` / `plan.md`。
  68 +- 所有阶段性产出都要过自我验证（真实样本对照），不能只交方法论文字。
  69 +- 产出的评分维度和方法论文档要写入你的共享工作区（运行时坐标中给出的绝对路径），
  70 + 不要写死 `../../workspace/` 这类旧布局路径。
  71 +
  72 +## 可用工具
  73 +- 无管理工具 — 本 Agent 只负责研究与产出，不管理其他 Agent、不派单。
  74 +- 可自由使用 Read / Write / Bash（用于调研搜索、读本仓库既有产出、整理产出文档）。
system/agents/unit-tester-methodology-trial/config.json 0 → 100644
  View file @521e762
  1 +{
  2 + "id": "unit-tester-methodology-trial",
  3 + "type": "specialist",
  4 + "name": "测试执行方法论专家（独立试验）",
  5 + "parent_id": null,
  6 + "goal_id": null,
  7 + "status": "training",
  8 + "benchmark_score": null,
  9 + "cli": {
  10 + "toolPolicy": {}
  11 + },
  12 + "gateway": {
  13 + "channels": []
  14 + },
  15 + "api": {
  16 + "endpoints": []
  17 + },
  18 + "mcp": {
  19 + "servers": []
  20 + },
  21 + "sandbox": {
  22 + "maxMemoryMB": 512,
  23 + "maxDiskMB": 1024,
  24 + "maxProcesses": 5
  25 + },
  26 + "description": "研究「怎样把 acceptance 逐条转成可靠的真实检测、且绝不编造检测结果」——unit-tester 是 e2e-demo 图里的自测节点，config.json 里 status 至今仍是 training，从没真正毕业转正，也从没做过 FDE 训练，只读 system/agents/unit-tester/agent.md + soul.md 现状作为基线（已手写规则：网页类产物用 scripts/visual-acceptance-check.mjs 真实浏览器检查、代码类产物用自带测试命令、两类都跑不了要如实说明而不是假装测过、acceptance 逐条不抽查、工具跑不起来算 blocked 不算跳过），训练目标是产出一套更可执行的『acceptance→真实检测手段』落地方法论，尤其覆盖：怎么把每条 acceptance 精确翻译成可验证步骤和预期结果、遇到没有现成检测工具的产物类型该怎么办、如何识别并避免『正则解析文本假装测过』这类伪检测（35号文档记录过的真实教训）、四段式 RESEARCH→PLAN→EXECUTE→VERIFY 每阶段具体该产出什么，训练完成后经人工审查再决定是否手工合并进生产 system/agents/unit-tester/"
  27 +}
system/agents/unit-tester-methodology-trial/cron.json 0 → 100644
  View file @521e762
  1 +[
  2 + {
  3 + "schedule": "*/10 * * * *",
  4 + "prompt": "读取 todo.md，检查未完成的任务并按优先级执行。",
  5 + "recurring": true,
  6 + "enabled": true
  7 + }
  8 +]
system/agents/unit-tester-methodology-trial/heartbeat.md 0 → 100644
  View file @521e762
  1 +# 心跳任务
  2 +
  3 +## 每次任务后
  4 +- [ ] 验证执行结果正确性
  5 +- [ ] 记录执行指标到 memory/
system/agents/unit-tester-methodology-trial/identity.md 0 → 100644
  View file @521e762
  1 +# 身份信息
  2 +
  3 +## 基础信息
  4 +- 名称: 测试执行方法论专家（独立试验）
  5 +- Emoji: 🤖
  6 +- 类型: specialist
  7 +
  8 +## 问候语
  9 +"你好，我是 测试执行方法论专家（独立试验）。"
system/agents/unit-tester-methodology-trial/soul.md 0 → 100644
  View file @521e762
  1 +# 测试执行方法论专家（独立试验） 的灵魂
  2 +
  3 +## 思维方式
  4 +（待训练阶段补充：从真实反例反推可执行判据，禁止用推理代替真实检测）
  5 +
  6 +## 沟通风格
  7 +- 清晰、简洁
  8 +
  9 +## 价值观
  10 +- 高质量交付
  11 +- 持续改进
system/agents/unit-tester-methodology-trial/tools.md 0 → 100644
  View file @521e762
  1 +# 工具使用备注
  2 +
  3 +## 安全规则
  4 +- 不要在日志中输出 API Key
  5 +- 不要在 memory 中存储密码
  6 +- API Token 使用 env 变量, 不要硬编码
  7 +
  8 +## 文件操作
  9 +- 自主创建的文件只写到运行时坐标（提示词开头）给出的绝对路径里，不要写死相对路径
  10 + （cwd 是任务态目录，一次性、会被清理，裸相对路径等于没交付）
system/agents/unit-tester-methodology-trial/train/digest/benchmark_v1.md 0 → 100644
  View file @521e762
  1 +# unit-tester 检测质量评分基准 v1 — unit-tester-methodology-trial
  2 +
  3 +> 生成者：innovator-digest（Phase 2 Digest）
  4 +> 输入：`../hunt/knowhow_v1.md`（157行，Hunt 阶段已验收）
  5 +> 复核：直接重读了 knowhow 第三节引用的 4 份真实历史 `test.log` 全文
  6 +> （`rn_956c699f1160`、`rn_84d4651597bc`、`rn_fc9155c598ef`、`rn_9d48ea87f326`）
  7 +> 及 `system/agents/unit-tester/agent.md` + `soul.md` 全文（只读复核，未改动），
  8 +> knowhow 摘录与原文核对一致，未发现引用失真。
  9 +> 日期：2026-08-24
  10 +> 训练对象：`unit-tester`（及其 org 版 `org-coder-validator` 上游自测节点）四段式生命周期
  11 +> 检测质量——"把 acceptance 逐条可靠转成不编造、不敷衍的真实检测动作"这类**检测类判据**，
  12 +> 与 `coder-methodology-trial`（执行忠实度）、`prd-methodology-trial`（内容质量）、
  13 +> `workgraph-planning-methodology-trial`（元规划/图形状裁剪）三类判据均不同——`coder` 判的是
  14 +> "有没有照规格写"，`unit-tester` 判的是"测试有没有真的跑过"，核心锚点不能互相移植评分标准。
  15 +
  16 +---
  17 +
  18 +## 〇、设计前提（写给后续读者，避免误判本文档意图）
  19 +
  20 +这套 benchmark 不评"acceptance 过没过"——那是 `goal-benchmark.json`/引擎自己的验收链路。
  21 +本文档回答的是 knowhow 揭示的更难的问题：**一份字面上没有违反 `unit-tester/agent.md` 任何
  22 +一条硬约束、acceptance 也全部标了 PASS 的 `test.log`，能不能保证"这是真跑出来的，不是自我
  23 +宽松解释出来的"？**
  24 +
  25 +knowhow 第三节核实的 4 份真实历史样本全部是正面案例（现状规则实际执行得都不错），这与
  26 +`coder-methodology-trial` 找到两份真实负面反例（样本A"代码走查冒充PASS"、样本B"悄悄写禁止
  27 +代码"）的处境不同——**本文档的 7 个维度里，有 3 个（D1/D6/D7）没有 unit-tester 自己的真实
  28 +负面样本可以直接引用**：D1 是从 `coder` 真实反例（同一种"自我验证"职能，判断主体从"下游疑
  29 +上游"变成"上游审自己"）做的风险移植，判断依据是"同构风险机制已被证实存在"，不是"unit-tester
  30 +本身已经栽过跟头"；D6/D7 更进一步——D6 是仓库内**零真实样本**的构造性设计，D7 是现状文本已经
  31 +写得比较清楚、但需要显式对抗一个真实的业界惯例分歧（pytest `skip`）。这三处的证据强度与
  32 +D2/D3/D4/D5（有真实正面先例或真实边界案例支撑）不同，本文档在对应小节逐一如实标注，不混同
  33 +"规则集自洽"和"规则已被真实反例验证过"两类不同强度的结论。
  34 +
  35 +7 个维度与 knowhow 第六节"给 Digest 阶段的判据缺口清单"7 条缺口**逐条一一对应，不合并、不
  36 +稀释**（映射表见文末四、）。
  37 +
  38 +---
  39 +
  40 +## 一、维度设计（7 维度 + 权重，满分 100）
  41 +
  42 +| 维度 | 名称 | 判据来源（knowhow §六缺口编号） | 权重 | 证据强度 |
  43 +|---|---|---|---|---|
  44 +| D1 | 自我审查信号词黑名单（核心锚点1） | 缺口1 | 20 | 风险移植（coder真实反例同构，unit-tester自身0负样本） |
  45 +| D2 | 独立重跑硬约束（核心锚点2） | 缺口2 | 18 | 4/4真实样本100%正面先例 |
  46 +| D3 | 正则解析文本边界裁决 | 缺口3 | 15 | 1个真实边界案例（样本4） |
  47 +| D4 | 复用/重跑前核实产物未变化 | 缺口4 | 10 | 1个真实正面先例（样本2） |
  48 +| D5 | 四段式阶段产出物质量+中断后核实 | 缺口5（含职责②四段式产出物要求） | 10 | 1个真实正面先例（样本2）+现状文本部分覆盖 |
  49 +| D6 | 混合可测/不可测子项降级路径 | 缺口6 | 15 | **构造性设计，样本量为零，如实标注** |
  50 +| D7 | blocked vs skip 语义完整性 | 缺口7 | 12 | 现状文本已部分覆盖，需对抗真实业界分歧 |
  51 +
  52 +D1+D2 合计权重 38，是两个带封顶（天花板）机制的核心锚点（三、3.2）——不是因为权重数字最高
  53 +就自动成为核心锚点，而是因为它们一旦失守，其余维度分数再高也无法证明"这份 test.log 可信"：
  54 +D1 失守意味着测试者对自己都不诚实，D2 失守意味着"独立自测节点"这个角色本身的存在理由被架空
  55 +（下游 validator 唯一能确认"真的测过"的证据来源就是这份记录，如果记录本身可能是自我宽松出来
  56 +的、或者只是转述了上游coder的自我宣称，那么整条验证链条的可信度归零，即使其余 5 个维度都拿
  57 +满分)。
  58 +
  59 +---
  60 +
  61 +## 二、逐维度评分标准
  62 +
  63 +### D1 自我审查信号词黑名单（权重 20，核心锚点1）
  64 +
  65 +判据锚点：knowhow 缺口1——`coder-methodology-trial` 的 D1（信号词黑名单）判的是"下游是否
  66 +怀疑上游"，本维度判的是"unit-tester 自己写 `test.log` 时，对**自己**的判定是否也可能落入
  67 +同一种自我宽松解释"。现状 `unit-tester/agent.md` 硬约束3 + `soul.md` 原则1 只禁止"正则解析
  68 +文本/凭源码看起来对就打勾"这一种具体作弊手法，没有给出一张可机械核对的**信号词黑名单**去拦
  69 +"我看代码觉得应该没问题""理论上会通过""逻辑上应该没问题""规则推导后判定PASS""跑了一部分应
  70 +该没问题"这类更隐蔽的自我宽松表述——这条黑名单是从 `coder` 真实反例（样本A `coder.log`
  71 +attempt-1"代码走查+CSS规则推导确认……判定PASS"）移植过来的，判断主体从"coder 骗下游"变成
  72 +"unit-tester 骗自己"，机制同构，但**本仓库 4 份 unit-tester 真实历史样本没有一份命中这个反
  73 +模式**（全部有具体命令+真实输出支撑），如实标注：这是一条有真实风险支撑（同构机制已被coder
  74 +样本证实）、但尚未在 unit-tester 自身历史中直接观测到的移植性判据。
  75 +
  76 +**判据（机械核对动作）**：逐条过 `test.log` 对 acceptance 的每一条判定，标出所有"只有推理性/
  77 +描述性文字、找不到具体执行命令+真实输出支撑"的判定——命中黑名单词汇本身就是信号，命中即不算数。
  78 +
  79 +| 分数 | 判据 |
  80 +|---|---|
  81 +| 5 | 每条判定都能追溯到具体命令+真实输出（终端返回值/DOM快照/截图/具体数值），没有任何一条使用信号词黑名单表述；遇到无法用工具验证的软性维度，用"这条测不了，原因是……"代替模糊断言，而不是用推断性描述蒙混过关 |
  82 +| 4 | ≥90% 判定有真实执行支撑，个别非核心维度存在推断性描述，但有其他真实证据佐证（如引用真实计算出的数值，而非纯主观感觉） |
  83 +| 3 | 存在 1 条非核心 acceptance 判定命中信号词黑名单（"代码走查确认"/"理论上应该没问题"类表述），其余判定仍以真实执行为主 |
  84 +| 2 | ≥2 条判定，或任意 1 条核心功能性 acceptance 判定命中信号词黑名单——命中"用推理代替执行"这一反例形态（样本A attempt-1 同构原型） |
  85 +| 1 | `test.log` 通篇不区分"真实执行"与"主观判断"，或完全没有过程记录、只有一句"全部通过" |
  86 +
  87 +### D2 独立重跑硬约束（权重 18，核心锚点2）
  88 +
  89 +判据锚点：knowhow 缺口2——四份真实样本 **100%** 自发写了"不采信上游 coder 自我汇报，独立
  90 +重新执行"（样本4 原文："coder.log 里 coder 自己已用 Playwright 自测过并宣称四条 PASS，但
  91 +那是实现者的自我汇报，本节点作为独立自测节点，不采信、全部重新真实跑过一遍"），这是被 4 次
  92 +独立会话不约而同验证有效的隐性纪律，但现状 `agent.md`/`soul.md` 从未把它写成显式硬约束。
  93 +`coder-methodology-trial` 的真实反例（样本A"代码走查冒充PASS"、样本B"悄悄写禁止代码不留痕"）
  94 +恰恰证明了"为什么不能采信上游自我汇报"——这两次事故如果只靠 coder 自己的 `coder.log` 记录，
  95 +下游根本发现不了，`unit-tester` 存在的理由就是不采信、重新验证。
  96 +
  97 +**判据（机械核对动作）**：检查 `test.log` 是否有清晰、明确的"不采信上游自我汇报，独立执行"
  98 +表述，且每一条判定都能看到本节点独立产生的命令+真实输出，而不是复述/引用 `coder.log` 已有的
  99 +判定结论作为证据的一部分。
  100 +
  101 +| 分数 | 判据 |
  102 +|---|---|
  103 +| 5 | 明确写出不采信 coder 自我汇报，且每条判定都是本节点独立执行产生（命令+真实输出），不以 coder.log 的判定结论作为证据 |
  104 +| 4 | 有等价表述或有实际独立重跑行为，但未显式点名"不采信上游自我汇报"这句话（行为对，说明不完整） |
  105 +| 3 | 独立执行了大部分检查，但存在 1 条判定直接引用/采信了 `coder.log` 的自测结论而未重新验证 |
  106 +| 2 | 明显以"coder 已经测过"为由跳过部分应测项的独立验证 |
  107 +| 1 | 完全依赖 `coder.log` 的自我汇报作为 `test.log` 判定依据，没有任何独立重跑动作 |
  108 +
  109 +### D3 正则解析文本边界裁决（权重 15）
  110 +
  111 +判据锚点：knowhow 缺口3——现状硬约束3 明确禁止"正则解析文本"代替**布局类**检查（溢出/字号/
  112 +对比度），但没有回答**内容存在性**检查（如 grep 文字是否出现在 HTML 里）算不算被禁止的
  113 +"假装测过"。真实边界案例：样本4（`rn_9d48ea87f326`）对 `sections_completeness` 维度用
  114 +`grep -n "section id\|feature-title\|feature-desc" index.html` 判定——这在字面上就是"正则
  115 +解析文本"，Hunt 已论证"当时判据合理，不构成对该样本的负面评价"，因为检查目标是"文字是否
  116 +存在"而非"布局是否正确"；但这条检查**无法排除**该文字被 `display:none`/`visibility:hidden`/
  117 +移出视口裁掉这类真实存在但用户看不见的边界情况。
  118 +
  119 +**裁决（本文档给出的明确规则，供后续 Evolve 阶段直接引用）**：把"用文本手段做检查"分成两类，
  120 +不是笼统"禁止正则"或"允许正则"其中一种：
  121 +
  122 +1. **纯源码结构性存在检查**——acceptance 语义只要求"代码里是否包含某标识符/结构"（如"是否
  123 + 有 3 个 `<section>`"、"class 名是否符合契约"），不涉及"用户是否看得见"。这类允许直接用
  124 + grep/正则，不需要额外的真实渲染验证——理由：判定目标本身就是源码层面的事实，真实渲染不会
  125 + 改变这个事实。
  126 +2. **隐含"用户可见"语义的内容检查**——acceptance 语义包含"清晰展示""可见""读者能看到"这类
  127 + 用户可感知维度（样本4 的 `sections_completeness` 属于此类：验收标准要求区块内容对用户
  128 + 呈现）。这类**默认要求**在 grep/正则初筛之后，补一步真实渲染可见性确认（如 Playwright
  129 + `isVisible()`/`getComputedStyle()` 排查 `display:none`/`visibility:hidden`/`height:0`
  130 + 等隐藏规则），否则判定视为不完整——理由：这条检查手段的边界与硬约束3"正则解析拿到的字符串
  131 + 匹配结果跟真的用浏览器渲染出来的布局是两回事"完全同源，只是从"布局是否正确"延伸到"内容是
  132 + 否真的可见"，逻辑一致，不是另立新规则。
  133 +
  134 +样本4 按此裁决重新归类：`sections_completeness` 属于**隐含可见语义类**，只做了 grep 没有补
  135 +可见性确认——按新裁决这不构成"违反现状规则"（当时规则未定义此边界，如实不倒扣历史样本），但
  136 +按本裁决评分会落在 3 分档（详见 `industry_avg_score.md` 反算）。
  137 +
  138 +| 分数 | 判据 |
  139 +|---|---|
  140 +| 5 | 所有内容存在性检查若语义涉及"用户可见"，均补做了真实渲染可见性确认；纯源码结构类检查用 grep/正则完全恰当，两类判据未混淆使用 |
  141 +| 4 | 可见性类检查用了 grep + 真实渲染交叉验证，但对隐藏文本的专项排查存在 ≤1 处遗漏 |
  142 +| 3 | 可见性类 acceptance 仅用 grep/正则完成判定（样本4原型），未做任何可见性确认，但被测代码本身未被证实存在隐藏文本导致误判（边界案例，非结构性违规） |
  143 +| 2 | 布局类检查（溢出/字号/对比度/间距）使用了正则/文本匹配代替真实渲染——命中现状硬约束3明确禁止的反模式 |
  144 +| 1 | 全面用正则/grep 替代真实检测手段，包括本应有真实工具覆盖的布局类和可见性类检查 |
  145 +
  146 +### D4 复用/重跑前核实被测产物未变化（权重 10）
  147 +
  148 +判据锚点：knowhow 缺口4——样本2（`rn_84d4651597bc`，因 infra_flake 中断后从 RESEARCH 重新
  149 +走）主动做了"上游 verify.mjs 字节级 diff 一致，被测三份产物 mtime 均未变化"的核实，这是一条
  150 +自发出现、值得推广、但现状规则完全没提的好实践。
  151 +
  152 +| 分数 | 判据 |
  153 +|---|---|
  154 +| 5 | 复用/重跑前显式核实被测产物 mtime 未变化且字节级/内容级 diff 一致，记录留痕，才决定复用之前的 `_research.md`/`_plan.md`；即便复用了旧结论，EXECUTE 阶段仍重新真实跑一遍检查（不复述旧 `test.log`，样本2 正例） |
  155 +| 4 | 有核实动作但只做了 mtime 检查未做内容 diff，或只做了 diff 未记 mtime，记录基本完整 |
  156 +| 3 | 提到"产物应该没变"但没有给出具体核实方法/命令（纯口头断言） |
  157 +| 2 | 直接复用旧 `test.log` 结论、未做任何核实即认定产物未变化 |
  158 +| 1 | 完全未提及复用场景下是否核实过被测产物是否变化，也未重新执行检查（直接复制旧结论作为本次交付） |
  159 +
  160 +**特殊规则（vacuous case）**：若本次执行是全新 attempt，不存在"复用上一次结论"的场景（没有
  161 +中断/重试历史），本维度视为空真，计 5 分——不适用不等于满分掩盖，一旦 `test.log` 出现"沿用/
  162 +复用/延续上次判断"字样，必须按上表逐条核对。
  163 +
  164 +### D5 四段式阶段产出物质量 + 中断后阶段核实（权重 10）
  165 +
  166 +判据锚点：knowhow 缺口5——样本2 记录了一个具体技巧："引擎侧当前阶段确实仍停在 RESEARCH
  167 +（`task transition --phase plan` 执行后返回 success，说明之前的 transition 从未真正生效）"，
  168 +这是 agent 自己摸索出的、用于确认真实阶段状态的方法，但 `agent.md` 四段式说明完全没有提供
  169 +"中断后如何核实真实所处阶段"的操作指导。本维度同时承接本 trial 自身 `agent.md` 职责②要求的
  170 +"四段式产出物是否可被'失忆后的自己'复现"（这一条不是 knowhow 第六节编号缺口，是本训练对象
  171 +自身职责书要求，与缺口5 同属四段式生命周期完整性主题，归入同一维度评分，不单独设维度、也不
  172 +因为归并而稀释缺口5 本身的判据——两个子项在下表分别列出，各自独立核对）。
  173 +
  174 +**判据（两个子项，均需核对）**：
  175 +(a) `_research.md`/`_plan.md`/`test.log` 内容是否让"失忆后的自己"能看懂当前处于哪个阶段、
  176 +上一步做了什么、下一步要做什么；
  177 +(b) 若本次执行是从中断恢复，是否有显式核实"当前真实所处阶段"的动作（而非凭记忆断言）。
  178 +
  179 +| 分数 | 判据 |
  180 +|---|---|
  181 +| 5 | (a)(b) 均满足——阶段产出物清晰完整可复现，且（若涉及恢复场景）有显式的阶段核实动作及其依据（样本2 正例） |
  182 +| 4 | (a) 清晰完整；(b) 场景未触发（无中断恢复情形），按 (a) 单独评分即为此档，要求 (a) 几乎无瑕疵 |
  183 +| 3 | (a) 基本满足但部分阶段产出物过于简略；或 (b) 场景触发但核实方式含糊（只凭记忆断言"应该还在哪个阶段"而非用命令返回值验证） |
  184 +| 2 | (a) 存在明显影响"失忆后的自己"复现的缺失（缺关键上下文）；或 (b) 场景触发但完全没有做核实，直接假定阶段 |
  185 +| 1 | 阶段产出物记录残缺到无法看出实际处于哪个阶段，或中断恢复后完全没有核实就继续/重复劳动 |
  186 +
  187 +### D6 混合可测/不可测子项降级路径（权重 15，构造性判据，样本量为零）
  188 +
  189 +【诚实标注】knowhow 第三节"未找到的部分"已明确指出：本仓库 4 份真实样本全部落在"acceptance
  190 +每个维度都有对应工具覆盖"的幸运情况，**从未真实遇到过**"同一 acceptance 维度下部分子项有
  191 +工具、部分没有"的混合场景。以下评分标准是 Digest 阶段的**构造性设计**，不是从真实反例反推
  192 +——参照 `workgraph-planning-methodology-trial` 训练时对"目标线可达性论证是构造性的、非真实
  193 +反例驱动"的同类诚实标注方式，如实注明，不假装有真实依据支撑。
  194 +
  195 +**构造性裁决**：同一 acceptance 维度内，若部分子项有真实检测手段、部分没有，应对子项逐个
  196 +判定，而不是整条维度笼统判 `blocked` 或笼统判过：能测的子项按真实结果记录 PASS/FAIL，不能
  197 +测的子项单独标注"这条测不了+具体原因"，最终该 acceptance 维度的结论 = 能测子项的真实结果 +
  198 +显式标注"部分子项未验证"（不能因为部分测不了就把能测出来的 PASS 结果一并抹去当 `blocked`，
  199 +也不能因为大部分子项能测就把测不了的那部分悄悄吞掉当作整条过）。
  200 +
  201 +| 分数 | 判据 |
  202 +|---|---|
  203 +| 5 | 遇到混合场景时逐子项拆分判定，能测子项给真实结果，不能测子项显式标注原因，最终结论清楚区分"验证过的部分"和"未验证的部分"，不笼统合并 |
  204 +| 4 | 基本做到拆分，但对"未验证部分"的最终结论措辞不够清晰（读者需要推断才能看出哪部分没测） |
  205 +| 3 | 遇到混合场景时笼统按 acceptance 维度打包处理（整条判 `blocked` 或整条判 PASS 且只字不提未覆盖的子项），但在其他地方提到了"这条工具不全" |
  206 +| 2 | 遇到混合场景，直接把有工具的子项测了就当整条过，完全不提没工具覆盖的子项（等价于 silently 跳过，复现 pytest `skip` 式风险） |
  207 +| 1 | 遇到混合场景，直接编造整条判定结果，或完全回避讨论工具覆盖不全的问题 |
  208 +
  209 +**特殊规则（vacuous case）**：若本次执行未遇到任何混合可测/不可测场景（所有 acceptance
  210 +维度要么全部可测、要么全部不可测），本维度视为空真，计 5 分——4 份真实样本目前全部落在这一档。
  211 +
  212 +### D7 blocked vs skip 语义完整性（权重 12）
  213 +
  214 +判据锚点：knowhow 缺口7 + 第五节(c)——现状硬约束6"跑不起来的检查……本身就是 `blocked`，不是
  215 +'先跳过这条当没看见'" + `soul.md` 原则6"工具跑不起来是 `blocked`，不能因为工具坏了就默认
  216 +'大概率没问题'"已经把功能语义写得比较清楚（两处重复强调），**但这与 pytest（业界主流测试
  217 +框架）官方惯例正面冲突**——pytest 把"依赖外部资源不可用"明确归为 `skip`（跳过，不计入失败，
  218 +甚至不执行），是被广泛采纳的业界默认做法。**这不是仓库规则错了**：pytest 的 `skip` 语境是
  219 +"这条测试本来就不该在这个环境下跑"，跳过是预期内的正常路径；`unit-tester` 的场景是"该测的
  220 +acceptance 条目因为工具坏了/环境问题测不了"，属于验收链条上出现了未知缺口——如果比照 pytest
  221 +惯例静默 `skip`，等于让一条本该被验证的 acceptance 悄悄从"待验证"变成"不存在"，与本仓库
  222 +"acceptance 逐条不抽查、绝不编造检测结果"的核心诉求直接冲突。**本维度要求 test.log 层面显式
  223 +体现这条有意识的偏离**，不能因为"业界标准是 skip"就弱化现有更严格的语义（本次训练不推翻这条
  224 +论证，Hunt 已经论证过为什么本仓库必须坚持更严格的 `blocked`）。
  225 +
  226 +| 分数 | 判据 |
  227 +|---|---|
  228 +| 5 | 工具不可用/依赖缺失时明确判定为 `blocked` 并说明原因；如果测试者意识到这与 pytest 式 `skip` 语义不同，显式说明"本仓库要求更严格，不采用 skip 式静默跳过，因为 acceptance 逐条不抽查，'测不了'和'不存在'不能混同" |
  229 +| 4 | 工具不可用时正确判定 `blocked` 并说明原因，但未显式讨论与 skip 语义的差异（功能正确，元认知说明缺失） |
  230 +| 3 | 工具不可用时判定为 `blocked`，但理由写得含糊（没具体说明是什么工具、什么错误导致跑不起来） |
  231 +| 2 | 工具不可用时倾向于"先跳过这条不算数"，实质上执行了 skip 式静默省略，即使没有明说 skip 这个词 |
  232 +| 1 | 工具不可用时直接假装测过或编造一个通过结果，完全违反 `blocked` 语义 |
  233 +
  234 +**特殊规则（vacuous case）**：若本次执行未遇到任何工具不可用场景，本维度视为空真，计 5 分
  235 +——4 份真实样本均落在这一档，仓库内暂无真实 `blocked` 先例（knowhow 第三节已如实说明）。
  236 +
  237 +---
  238 +
  239 +## 三、总分计算方法
  240 +
  241 +### 3.1 加权和
  242 +
  243 +```
  244 +加权和 = Σ(维度得分/5 × 维度权重) （满分 100）
  245 +```
  246 +
  247 +### 3.2 封顶规则（天花板机制）
  248 +
  249 +D1、D2 是全场权重最高、且失守即让整条验证链条可信度归零的两个核心锚点（〇节）。参考
  250 +`coder-methodology-trial` 的教训——纯加权和是"稀释"机制：D3-D7 只要接近满分，就足够把 D1/D2
  251 +的低分稀释成一个体面总分，掩盖"测试者自己都不诚实"或"独立自测节点形同虚设"这类比"某个维度
  252 +分数不够高"严重得多的问题。因此追加硬性封顶：
  253 +
  254 +```
  255 +若 D1 ≤ 2 → 总分上限 50（自我审查缺失，即便本仓库暂无 unit-tester 自身负样本，
  256 + 风险机制已被 coder 真实反例证实同构，参照高风险处理）
  257 +若 D1 = 3 → 总分上限 65
  258 +若 D1 ≥ 4 → D1 不封顶（除非其他维度触发了各自的封顶）
  259 +
  260 +若 D2 ≤ 2 → 总分上限 40（不独立重跑，"独立自测节点"这个角色存在的意义被架空——
  261 + 比"自我审查不到位"更根本，D1 哪怕满分也没有意义，
  262 + 因为满分的自我审查建立在"这是本节点自己测出来的"这个前提上，
  263 + 前提不成立，审查再严格也没有意义）
  264 +若 D2 = 3 → 总分上限 60
  265 +若 D2 ≥ 4 → D2 不封顶
  266 +
  267 +最终得分 = min(加权和, 各已触发的上限)
  268 +```
  269 +
  270 +D2 的封顶线比 D1 更严格（40 < 50）：D2 低分意味着"这份 test.log 根本不是独立测出来的"——
  271 +下游 validator 唯一能确认"真的测过"的证据来源本身不成立；D1 低分意味着"独立测是测了，但对
  272 +自己判定的诚实度不够"，后果同样严重但建立在"确实做了独立验证"这个更基础的前提之上。
  273 +
  274 +### 3.3 判定等级
  275 +
  276 +| 分数区间 | 等级 | 处置建议 |
  277 +|---|---|---|
  278 +| ≥80 | 优秀 | 检测记录可信，可直接作为下游 validator 判决的证据 |
  279 +| 65-79 | 合格 | 可作为判决证据，标记薄弱维度供关注 |
  280 +| 50-64 | 待改进 | 不建议直接采信，需针对薄弱维度补充记录/重新检测后再评分 |
  281 +| <50 | 不合格 | 判定为"检测记录不可信或存在未交代的降级/自我宽松"，需要重做 EXECUTE/VERIFY 阶段 |
  282 +
  283 +**及格线（passing_score）= 65**（合格档下限），见 `industry_avg_score.md`。
  284 +
  285 +---
  286 +
  287 +## 四、对 knowhow 第六节 7 条缺口的逐条落点确认
  288 +
  289 +| 缺口编号 | 内容 | 落地维度 |
  290 +|---|---|---|
  291 +| 缺口1 | "unit-tester 自我审查"信号词清单缺失 | D1，核心锚点1+封顶 |
  292 +| 缺口2 | "不采信上游coder自我汇报，独立重跑"未钉成硬约束 | D2，核心锚点2+封顶 |
  293 +| 缺口3 | "正则解析文本"反模式适用边界不清 | D3，含明确裁决（源码结构性存在 vs 隐含用户可见语义） |
  294 +| 缺口4 | "复用/重跑前核实产物未变化"缺失机械动作 | D4 |
  295 +| 缺口5 | "中断后核实真实所处阶段"缺操作指导 | D5（同时承接本 trial 职责②四段式产出物要求，两个子项独立核对） |
  296 +| 缺口6 | "部分子项有工具、部分没有"混合降级路径无中间态定义 | D6，如实标注为构造性设计、样本量为零 |
  297 +| 缺口7 | `blocked` vs 业界 `skip` 惯例分歧需显式说明，不能弱化 | D7 |
  298 +
  299 +7 条缺口全部有独立维度落点，一一对应，没有合并成模糊维度、没有遗漏、没有稀释。
system/agents/unit-tester-methodology-trial/train/digest/industry_avg_score.md 0 → 100644
  View file @521e762
  1 +# 行业基准分说明 v1 — unit-tester-methodology-trial
  2 +
  3 +> 生成者：innovator-digest（Phase 2 Digest）
  4 +> 日期：2026-08-24
  5 +> 首次训练（v1）
  6 +
  7 +---
  8 +
  9 +## 为什么没有一个可抓取的"行业平均分"
  10 +
  11 +评分对象是"unit-tester 四段式生命周期检测质量"——这不是可爬取、可统计的公开行业活动，没有
  12 +第三方数据源发布过"AI 测试 agent 检测质量平均分"这种可引用的数字。参考
  13 +`prd-methodology-trial`/`workgraph-planning-methodology-trial`/`coder-methodology-trial`
  14 +三次训练的先例，本文档同样不编造行业平均分，改为给出**本仓库内部可复现的基准线**，全部能
  15 +追溯到具体打分过程（`benchmark_v1.md` 逐维度判据 + 本文档下方逐条打分）。
  16 +
  17 +与 `coder-methodology-trial` 的处境相同：`unit-tester`（真身，非本次训练对象
  18 +`unit-tester-methodology-trial`）在仓库里留下了 4 份可直接读取的真实历史 `test.log`，本文档
  19 +除了"现状文本基线"外，额外反算了两份真实历史执行记录在**新 benchmark 下**会打多少分，用来
  20 +验证目标线是否真实可达——不是凭空推演。
  21 +
  22 +---
  23 +
  24 +## 基线一：真实基线 —— `unit-tester/agent.md` + `soul.md` 现状原文
  25 +
  26 +**评分对象**：`system/agents/unit-tester/agent.md` 硬约束1-7（第4-33行）+ 四段式生命周期表
  27 +（第41-68行）+ `system/agents/unit-tester/soul.md` 工作原则1-6（第10-36行），任务书明确要求
  28 +的做法（"把 benchmark 套用在 unit-tester/agent.md+soul.md 现状原文上算出真实基线分"）。
  29 +
  30 +### 逐维度打分
  31 +
  32 +**D1 自我审查信号词黑名单 = 1**
  33 +硬约束3 + `soul.md` 原则1 只禁止"正则解析文本/凭源码看起来对就打勾"这一种具体作弊手法，全文
  34 +没有任何一句提到"我看代码觉得应该没问题""理论上会通过"这类自我宽松措辞该如何识别和拦截——
  35 +这条判据在现行文本里完全空白，与 `coder` 现行文本在移植 D1 判据前的"完全空白"状态属于同一
  36 +失分模式（`coder-methodology-trial` 真实基线 D1=2 是因为硬约束4/原则2至少提到了"真实输出"，
  37 +`unit-tester` 现行文本连"真实输出"这个表述都没有对应到"自我判定诚实度"这一层，属于更彻底
  38 +的空白）。
  39 +
  40 +**D2 独立重跑硬约束 = 1**
  41 +硬约束1 只说"你不是最终判卷人，下游 `org-coder-validator` 才是"，全文没有任何一句提到"不
  42 +采信上游 coder 自我汇报，必须独立重新执行"——这条纪律 100% 是 4 份真实样本自发做到的，现行
  43 +文本完全没有把它写下来。
  44 +
  45 +**D3 正则解析文本边界裁决 = 2**
  46 +硬约束3 明确给出了"不要用正则解析文本假装测过"的原则，且举了"溢出/字号/对比度"的具体反例，
  47 +比完全没有文字要强；但没有回答"内容存在性检查（grep 文字是否出现）算不算被禁止"这个真实边界
  48 +问题——样本4（`rn_9d48ea87f326`）的 `sections_completeness` 判定就是仓库内真实存在、现行
  49 +文本管不住（也没说清楚）的边界案例，命中"有一定原则文字但边界模糊"的 2 分档。
  50 +
  51 +**D4 复用/重跑前核实产物未变化 = 1**
  52 +`agent.md`/`soul.md` 全文没有任何一句提及复用/重跑前需要核实被测产物是否变化——这条机械动作
  53 +完全没有被要求，是样本2 自发做到、现状规则完全没提的空白。
  54 +
  55 +**D5 四段式阶段产出物质量+中断后核实 = 2**
  56 +子项(a)——`agent.md` 四段式生命周期表（第46-68行）+ `soul.md` 原则3"每一阶段的产出要写给
  57 +'失忆后的自己'看得懂"对阶段产出物的质量要求写得比较具体（每阶段该产出什么文件、下一步命令
  58 +是什么），这部分不差；子项(b)——全文没有任何一句提到"会话中断后如何核实真实所处阶段"，样本2
  59 +摸索出的"用 `task transition` 返回值反推真实阶段"这个具体技巧完全没有被写进文本，纯靠个体
  60 +会话即兴发挥（knowhow 缺口5 原文明确指出这一点）。子项(a)较好、子项(b)完全空白，两项不能只
  61 +看好的一项打高分，命中 2 分档。
  62 +
  63 +**D6 混合可测/不可测子项降级路径 = 1**
  64 +硬约束3 只处理了"两类都跑不了"这一种全有全无的极端情况，完全没有涉及"同一 acceptance 维度
  65 +内部分子项有工具、部分没有"这种混合情况——这条路径现行文本完全空白，也是仓库内零真实先例的
  66 +构造性判据（`benchmark_v1.md` D6 已如实标注）。
  67 +
  68 +**D7 blocked vs skip 语义完整性 = 4**
  69 +硬约束6"跑不起来的检查……本身就是 `blocked`，不是'先跳过这条当没看见'" + `soul.md` 原则6
  70 +"工具跑不起来是 `blocked`，不能因为工具坏了就默认'大概率没问题'"——这条判据在现行文本里
  71 +写得相当清楚，两处独立重复强调，功能语义没有歧义。扣分点仅在于：现行文本没有显式讨论"这与
  72 +pytest 式 `skip` 惯例的分歧"这层元认知说明（即"为什么我们比业界标准更严格"），但这不影响
  73 +机械可执行性，故落在 4 分档而非满分。
  74 +
  75 +### 计算
  76 +
  77 +```
  78 +D1 = 1/5×20 = 4.0
  79 +D2 = 1/5×18 = 3.6
  80 +D3 = 2/5×15 = 6.0
  81 +D4 = 1/5×10 = 2.0
  82 +D5 = 2/5×10 = 4.0
  83 +D6 = 1/5×15 = 3.0
  84 +D7 = 4/5×12 = 9.6
  85 +──────────────────
  86 +加权和 = 32.2
  87 +
  88 +封顶检查：
  89 +D1=1(≤2) → 总分上限 50
  90 +D2=1(≤2) → 总分上限 40
  91 +
  92 +最终得分 = min(32.2, 50, 40) = 32.2
  93 +```
  94 +
  95 +**32.2 分，"不合格"档**（<50）。与任务预期一致——D1/D2 两个核心锚点在现行文本里都彻底空白，
  96 +D6 是零先例的构造性判据自然也拿不到分，D7（现行文本覆盖最好的一维）也只有 4/5——现状文本
  97 +唯一算得上"写得好"的判据（blocked 语义）远不足以把总分拉到及格线以上。这与
  98 +`coder-methodology-trial`（32分）、`workgraph-planning-methodology-trial`（34分）两次训练的
  99 +真实基线量级一致，属于同一类"现状纯靠 LLM 自觉、没有机械判据"的失分模式。
  100 +
  101 +---
  102 +
  103 +## 基线二（补充）：现状真实历史执行样本，套用新 benchmark 反算
  104 +
  105 +这一条不是任务书要求的必答项，但价值与 `coder-methodology-trial` 的"基线二"相同：拿仓库内
  106 +已经产生的真实交付去验证目标线是否可达，而不是凭空推演。选取两份代表性样本：
  107 +
  108 +### 样本2（`rn_84d4651597bc`，`p-iyshuc`，因 infra_flake 中断后从 RESEARCH 重新走）
  109 +
  110 +- **D1 = 5**：`test.log` 40 条 acceptance 判定全部有具体命令（`node verify.mjs`/
  111 + `node extra-check.mjs`）+ 真实 stdout 支撑，无一条使用信号词黑名单表述。
  112 +- **D2 = 5**：本样本经历中断重启，重启后没有直接复述旧 `test.log`，而是"沿用其内容真实走完
  113 + RESEARCH→PLAN→EXECUTE 的命令行 transition，并在 EXECUTE 阶段重新实际执行一遍全部检查命令
  114 + （不是复述旧 test.log）"——满足独立重跑的最高档要求。
  115 +- **D3 = 5**：本样本全程未使用任何 grep/正则手段，全部是 Playwright 真实渲染 + 真实计算样式，
  116 + 规避了 D3 的边界问题（无需裁决适用）。
  117 +- **D4 = 5**：正是缺口4 的正面先例本身——"上游 verify.mjs 字节级 diff 一致，被测三份产物
  118 + mtime 均未变化"，核实后才复用 `_research.md`/`_plan.md`，且 EXECUTE 阶段仍重新真实跑了
  119 + 一遍。
  120 +- **D5 = 5**：正是缺口5 的正面先例本身——"引擎侧当前阶段确实仍停在 RESEARCH（`task
  121 + transition --phase plan` 执行后返回 success，说明之前的 transition 从未真正生效）"，显式
  122 + 核实了真实所处阶段，阶段产出物记录也完整清晰。
  123 +- **D6 = 5（空真）**：未遇到混合可测/不可测场景。
  124 +- **D7 = 5（空真）**：未遇到工具不可用场景。
  125 +
  126 +```
  127 +D1=5/5×20=20.0 D2=5/5×18=18.0 D3=5/5×15=15.0 D4=5/5×10=10.0
  128 +D5=5/5×10=10.0 D6=5/5×15=15.0 D7=5/5×12=12.0
  129 +──────────────────────────────────────────────
  130 +加权和 = 100.0（无维度触发封顶）
  131 +最终得分 = 100.0
  132 +```
  133 +
  134 +### 样本4（`rn_9d48ea87f326`，`p-pyjha7`，attempt-4）
  135 +
  136 +- **D1 = 5**：4 条 acceptance 判定全部有具体命令+真实输出（grep 行号、Playwright JSON、
  137 + `visual-acceptance-check.mjs` 数值、截图路径），无信号词黑名单命中。
  138 +- **D2 = 5**：原文明确写"coder.log 里 coder 自己已用 Playwright 自测过并宣称四条 PASS，但
  139 + 那是实现者的自我汇报，本节点作为独立自测节点，不采信、全部重新真实跑过一遍"——满足最高档
  140 + 要求的教科书式表述。
  141 +- **D3 = 3**：`sections_completeness` 维度用 `grep -n "section id\|feature-title\|
  142 + feature-desc" index.html` 判定"内容完整性"（隐含用户可见语义），未做任何真实渲染可见性
  143 + 确认（如 `isVisible()`/`display:none` 排查）——按 `benchmark_v1.md` D3 新裁决命中 3 分档
  144 + （"仅用 grep 完成判定，但被测代码本身未被证实存在隐藏文本导致误判"）。这不构成对该历史
  145 + 样本的负面评价（裁决在当时并不存在），但反映出新裁决相对现状确实抬高了门槛。
  146 +- **D4 = 5（空真）**：本次为独立 attempt-4，无复用前一次结论的场景。
  147 +- **D5 = 4**：阶段产出物本身清晰、可复现（每条判定都标注权重/阈值/命令/核对结论），但本样本
  148 + 未触发中断恢复场景，只能对子项(a)单独评分，且 test.log 本身未展示 `_research.md`/
  149 + `_plan.md` 全貌，保守评为 4（非满分）而非默认满分。
  150 +- **D6 = 5（空真）**：未遇到混合可测/不可测场景。
  151 +- **D7 = 5（空真）**：未遇到工具不可用场景。
  152 +
  153 +```
  154 +D1=5/5×20=20.0 D2=5/5×18=18.0 D3=3/5×15=9.0 D4=5/5×10=10.0
  155 +D5=4/5×10=8.0 D6=5/5×15=15.0 D7=5/5×12=12.0
  156 +──────────────────────────────────────────────
  157 +加权和 = 92.0（无维度触发封顶，D1=5≥4、D2=5≥4）
  158 +最终得分 = 92.0
  159 +```
  160 +
  161 +**两份真实样本分别拿到 100 分与 92 分**，均远超 80 分目标线。这是本套 benchmark 最有力的
  162 +可达性证据：**D1/D2 这两个权重最高、带封顶的核心锚点，4 份真实历史样本全部自发满分**——
  163 +现状文本虽然完全没写这两条规则，但真实执行的 agent 会话已经自觉做到了；本次训练要解决的不是
  164 +"能力不够"，而是"该写的没写下来"（与 knowhow 第一节缺口1/2 的结论完全一致）。样本4 唯一的
  165 +失分点集中在 D3（新裁决抬高的可见性验证门槛）和 D5 的子项(a)保守扣分，这正是本次训练真正
  166 +要补的具体判据，而不是覆盖全局的能力缺陷。
  167 +
  168 +---
  169 +
  170 +## 基线三：目标线
  171 +
  172 +**取值**：`benchmark_v1.md` 三、3.3 定义的"优秀"档下限 **80 分**——沿用
  173 +`prd-methodology-trial`/`workgraph-planning-methodology-trial`/`coder-methodology-trial`
  174 +四次训练的先例逻辑，复用 benchmark 自己已定义好的分级下限做目标线，不另起一个数字。
  175 +
  176 +**可达性论证（基于两份真实样本的直接反算，不是凭空构造）**：与 `coder-methodology-trial`
  177 +需要靠反事实分析（假设修复一处记录）才能勉强触达目标线不同，`unit-tester` 的两份真实历史
  178 +样本**不需要任何假设修正，直接反算就已经分别拿到 100 分和 92 分**，双双超过 80 分目标线。
  179 +这不是巧合——4 份真实样本本身就是现状文本治理下"实际执行得都不错"的正面案例（knowhow 第三节
  180 +原文明确定性），本次训练的核心矛盾从一开始就不是"unit-tester 真实执行能力不够"，而是"现状
  181 +文本没有把这些已经被验证有效的做法写下来、也没有对 D3/D6/D7 这类边界/构造性/分歧性判据给出
  182 +明确裁决"。80 分目标线不是虚设的天花板，而是"现行为已经能达到、只是现行文本没资格宣称训练
  183 +出了这个水平"的真实分数。
  184 +
  185 +**没有采用更高的目标线（如95分）**：样本4 因为 D3（新裁决）与 D5 子项(a)的保守扣分只到 92
  186 +分，样本2 虽然拿到满分，但那是单个样本，不能代表"每一次执行都会如此干净"（例如混合可测/
  187 +不可测场景、工具不可用场景在 4 份样本里从未出现，D6/D7 目前的满分是"空真"规则赋予的，一旦
  188 +真实遇到这类场景，构造性判据（D6）能不能在真实场景下同样打到满分仍未经验证）。为避免重蹈
  189 +`workgraph-planning-methodology-trial`/`coder-methodology-trial` 两次训练已经踩过的坑（任务
  190 +书建议的更高分数在自检中拿不到，如实改为80分），本次直接采用 80 分，不做无依据的更高设定。
  191 +
  192 +---
  193 +
  194 +## 及格线（passing_score）
  195 +
  196 +**passing_score = 65**（`benchmark_v1.md` 三、3.3"合格"档下限）。
  197 +
  198 +依据：
  199 +- 真实基线（32.2分）必须落在及格线以下——它代表"现行 `agent.md`/`soul.md` 不加任何新判据"
  200 + 的分数，及格线定得比它低就等于承认现状文本已经合格，与训练目的（D1/D2 两个核心锚点在现行
  201 + 文本里完全空白）矛盾。
  202 +- 目标线（80分）落在及格线以上，中间留出"合格但有薄弱维度"的缓冲区间（65-79）——例如样本4
  203 + 的 92 分如果 D3 判据更严格一档（比如遇到真实存在隐藏文本、确实造成误判），会落进这个区间，
  204 + 说明 65-79 不是空区间，是"验证扎实、但某个具体边界判据还有可指出的缺口"的真实可能状态。
  205 +
  206 +---
  207 +
  208 +## 与前三次训练的对比小结
  209 +
  210 +| 训练对象 | 真实基线 | 目标线 | 核心锚点 |
  211 +|---|---|---|---|
  212 +| prd-methodology-trial | 50分（e2e-demo 真实PRD） | 80分 | D5 正文-验收线索映射完整性、D6 内容深度 |
  213 +| workgraph-planning-methodology-trial | 34分（现状文本） | 80分 | D2 确定性/可复现性 |
  214 +| coder-methodology-trial | 32分（现状文本）/50分（现状最佳真实执行） | 80分 | D1 验证真实性、D5 隐性代码偏离记录完整性 |
  215 +| unit-tester-methodology-trial（本次） | 32.2分（现状文本）/92-100分（两份真实历史执行） | 80分 | D1 自我审查信号词黑名单、D2 独立重跑硬约束 |
  216 +
  217 +本次训练与前三次的真实基线量级一致（32-34分区间），但"基线二"的表现是四次训练里最好的一次
  218 +——两份真实样本无需任何假设修正即双双超过目标线，说明 `unit-tester` 这个角色的真实执行水平
  219 +本身就不差（knowhow 第二节35号文档摘录也独立佐证了这一点："这是相当不错的即兴发挥，不是
  220 +能力不足"），本次训练的价值集中在**把已验证有效的做法写下来、并对几处现状文本管不住的边界
  221 +给出明确裁决**，而不是弥补一个能力缺陷。
system/agents/unit-tester-methodology-trial/train/evolve/SKILL.md 0 → 100644
  View file @521e762
  1 +# unit-tester 检测执行手册 SKILL.md v1
  2 +
  3 +> 训练对象：`unit-tester-methodology-trial`（独立试验节点）
  4 +> 依据：`../digest/benchmark_v1.md`（7 维度评分标准）+ `../hunt/knowhow_v1.md`（4 份真实历史样本）
  5 +> 定位：本文档不复述评分标准，只回答"照着做，RESEARCH/PLAN/EXECUTE/VERIFY 每一步具体输出什么"。
  6 +> 版本说明：v1 已根据独立样本 `rn_fc9155c598ef` 的真实压力测试做过一轮修正
  7 +> （见 `sample_verification.md` 与 `iteration_log.md` Round 2），不是未经检验的初稿。
  8 +
  9 +---
  10 +
  11 +## 〇、四段式 × 七维度速查表
  12 +
  13 +| 阶段 | 主要产出 | 对应维度 |
  14 +|---|---|---|
  15 +| RESEARCH | `_research.md`（acceptance→检测手段映射表 + 场景判定） | D3 分类前置、D4/D5(b) 场景判定 |
  16 +| PLAN | `_plan.md`（逐条命令 + D2 声明草稿 + 降级预案） | D2 模板、D6/D7 预案 |
  17 +| EXECUTE | `test.log`（真实命令+真实输出+判定） | D1 自审、D2 独立执行、D3 裁决、D6/D7 落地 |
  18 +| VERIFY | `test.log` 收尾自查段 | D1 复查、D2 措辞核对、D5(a) 可复现性核对 |
  19 +
  20 +D1（权重20）、D2（权重18）是核心锚点，任一 ≤2 分会把总分封顶到 50/40 ——**EXECUTE 阶段每写一句判定，先过 D1 黑名单和 D2 独立性检查，不要留到 VERIFY 才补救**。
  21 +
  22 +---
  23 +
  24 +## 一、RESEARCH 阶段
  25 +
  26 +### 动作1：读齐上游产物
  27 +路径以任务描述"上游输入"段为准（硬约束2），至少读：`goal-benchmark.json`（acceptance 原文+权重+pass_threshold）、`coder.log`（上游自测记录——**只读不采信**，只用来知道上游做了什么，不能当证据引用）、被测产物本身。
  28 +
  29 +### 动作2：建立 acceptance→检测手段映射表（写入 `_research.md`）
  30 +逐条 acceptance，填这张表：
  31 +
  32 +| acceptance 项 | 语义分类 | 可用工具 | 是否可测 |
  33 +|---|---|---|---|
  34 +| （原文） | 结构性存在 / 隐含可见语义 / 布局类 | `visual-acceptance-check.mjs` / 自写 Playwright / grep / 无 | 是 / 否 / 部分 |
  35 +
  36 +**语义分类判据（D3 裁决，来自 `benchmark_v1.md` 二、D3）**：
  37 +- **结构性存在**：只问"代码里有没有这个标识符/结构"，不涉及用户能不能看见（如"是否有 3 个 `<section>`"、CSS 变量种类数、class 名是否符合契约）→ 允许直接 grep/正则，不需要补渲染验证。
  38 +- **隐含可见语义**：acceptance 措辞含"清晰展示""可见""用户能看到"等（如"区块内容对用户呈现"）→ 判"是否可测"时就要预先标注"需要 grep 初筛 + 真实渲染可见性确认（`isVisible()`/`getComputedStyle()` 排查 `display:none`/`visibility:hidden`/`height:0`）"，不能只填 grep。
  39 +- **布局类**（溢出/字号/对比度/间距）→ 只能填真实渲染工具，grep/正则在这一类里**禁止**出现在"可用工具"列。
  40 +
  41 +分类做错不是小事——这张表决定 PLAN 阶段该敲定几条命令，EXECUTE 阶段才不会漏掉可见性确认。
  42 +
  43 +### 动作3：判定是否为中断恢复场景（D5(b) 前置）
  44 +检查会话/引擎侧是否有"上一次已经做到哪一步"的痕迹（如 `_plan.md` 已存在、`task transition` 历史）。若存在，**不要凭记忆断言现在在哪个阶段**——执行一次状态核实动作（例：`task transition --phase <当前认为所在的阶段>`，若返回 success 说明之前的 transition 从未真正生效，真实阶段其实还停在更早一步；样本2`rn_84d4651597bc`原始技巧），把核实命令+返回值写进 `_research.md`。若不是中断恢复（全新 attempt），在 `_research.md` 写明"本次为全新 attempt，无中断恢复场景"，D5(b) 按 vacuous 处理。
  45 +
  46 +### 动作4：判定是否为复用场景（D4 前置）
  47 +检查是否存在"沿用上一次 `_research.md`/`_plan.md`/`test.log` 结论"的意图。若有，**复用前必须做**：
  48 +```
  49 +被测产物 mtime 检查 + 上游产物（如 verify.mjs）字节级/内容级 diff
  50 +```
  51 +两项都做才能进 5 分档，只做一项是 4 分档；只口头说"应该没变"不算数（3 分档，参照 `benchmark_v1.md` 二、D4）。把核实命令+结果写进 `_research.md`。若非复用场景（全新 attempt），写明"无复用场景"，D4 按 vacuous 处理。
  52 +
  53 +### RESEARCH 产出物验收标准
  54 +`_research.md` 必须让"失忆后的自己"看懂：读了哪些上游产物、acceptance 映射表长什么样、是否为中断恢复/复用场景及其核实结论。缺任意一项，D5(a) 会扣分。
  55 +
  56 +---
  57 +
  58 +## 二、PLAN 阶段
  59 +
  60 +### 动作1：为映射表每条 acceptance 敲定具体命令
  61 +把 RESEARCH 阶段"可用工具"列的抽象描述，落成 PLAN 阶段的具体命令行（含参数），写入 `_plan.md`。"隐含可见语义"类必须列两行命令（grep 初筛 + 渲染确认），不能只列一行就默认够用。
  62 +
  63 +### 动作2：写下 D2 声明草稿——**使用固定模板，不要自由改写**
  64 +`benchmark_v1.md` D2 五分档的最高档要求"**明确写出**不采信 coder 自我汇报"这句话本身要出现在 `test.log` 里，不是"做到了独立重跑的事实"就自动算数。压力测试样本 `rn_fc9155c598ef`（见 `sample_verification.md`）证明：只写"未复用 coder.log 结论"这类语义等价但换了说法的表述，会被判定为"有独立重跑行为但未显式点名"，只拿 4 档而非 5 档——这不是评分标准吹毛求疵，是 D2 rubric 本身逐字要求的差异，必须提前在 PLAN 阶段把原话定下来，不要到 EXECUTE 阶段临场发挥措辞。
  65 +
  66 +**固定模板（EXECUTE 阶段直接抄进 test.log 开头）**：
  67 +> "以下全部是本次独立跑出的真实命令输出。本节点作为独立自测节点，**不采信**上游 `coder.log` / 自带 `verify.mjs` 的自我汇报结论，全部重新真实执行一遍。"
  68 +
  69 +模板里"不采信"三个字必须原样出现，这是 D2 5 分档唯一逐字核对的锚点词。
  70 +
  71 +### 动作3：预判降级路径（D6/D7）
  72 +过一遍映射表"是否可测"列：
  73 +- 全部"是" → `_plan.md` 注明"未遇到混合可测/不可测场景"，D6 按 vacuous 处理，不需要额外设计。
  74 +- 存在"否"或"部分" → 必须在 `_plan.md` 写清楚：能测的子项按什么命令测、不能测的子项写"这条测不了，原因是 XXX"，EXECUTE 阶段逐子项分别下结论，**不允许**整条 acceptance 因为部分子项没工具就笼统判 `blocked`，也不允许因为大部分子项能测就把测不了的部分悄悄吞掉。
  75 +- 若预判会遇到工具跑不起来的情况 → 提前写好 D7 模板（动作见下 EXECUTE 三、动作5）。
  76 +
  77 +---
  78 +
  79 +## 三、EXECUTE 阶段
  80 +
  81 +### 动作1：逐条独立执行，`test.log` 开头贴 D2 固定模板
  82 +把 PLAN 阶段敲定的命令逐条真实跑一遍，**不参考 `coder.log` 的判定结论**（可以读它知道被测产物在哪，不能拿它的"PASS"字样当证据）。每条 acceptance 的判定都必须能看到"本节点独立产生"的命令+真实输出。
  83 +
  84 +### 动作2：D1 自我审查信号词黑名单——写判定前先过一遍
  85 +下面这些词/句式一旦出现在某条 acceptance 的判定文字里，**这条判定不算数**，必须换成真实命令+真实输出：
  86 +
  87 +| 禁用信号词/句式 | 替代做法 |
  88 +|---|---|
  89 +| "代码走查确认"/"代码看起来没问题" | 换成具体命令输出，或如实写"这条测不了，原因是……" |
  90 +| "理论上应该会通过"/"理论上没问题" | 同上 |
  91 +| "规则推导后判定" | 同上（除非"规则推导"本身就是从**真实测得的数值**做算术，如"width A = width B 的 100%，≥50%门槛达标"这种基于真实输出的计算允许，因为判据是"已测得的真实数值"，不是"没测就猜"） |
  92 +| "逻辑上应该没问题"/"跑了一部分应该没问题" | 同上 |
  93 +| "大概率"/"估计"/"应该没有" | 同上 |
  94 +| "看起来"/"感觉" | 同上 |
  95 +
  96 +命中黑名单本身就是信号，**不是靠事后删词遮盖**——遇到真的没法用工具验证的软性维度，用"这条测不了，原因是……"（硬约束5原文句式）代替，而不是换个说法继续模糊断言。
  97 +
  98 +### 动作3：D3 两类裁决实操
  99 +执行 RESEARCH 阶段映射表时按分类严格执行：
  100 +- 结构性存在类：grep/正则输出直接作为判定依据，不需要额外步骤。
  101 +- 隐含可见语义类：grep 初筛之后，**必须**补一条真实渲染可见性确认命令（Playwright `isVisible()` / `getComputedStyle()` 检查 `display:none`/`visibility:hidden`/`height:0`），两步都要出现在 `test.log` 里，只做 grep 不做渲染确认最多拿 3 分档。
  102 +- 布局类：只能用真实渲染工具（`visual-acceptance-check.mjs` 或等价 Playwright 脚本），出现 grep/正则代替真实检测直接命中 2 分档以下的反模式。
  103 +
  104 +### 动作4：D6 混合降级逐子项落地
  105 +按 PLAN 阶段预案，能测的子项写真实结果，不能测的子项显式写"这条测不了，原因是……"，最终该 acceptance 维度的结论 = 能测子项真实结果 + 显式标注未验证部分，不笼统合并成一句"整体 PASS"或"整体 blocked"。
  106 +
  107 +### 动作5：D7 blocked 判定 + pytest 对照说明模板
  108 +工具跑不起来（依赖缺失/环境问题/命令报错）时，`test.log` 该条写：
  109 +> "工具 `<工具名>` 因 `<具体错误/依赖缺失>` 无法执行，判定为 `blocked`。本仓库要求比 pytest 式 `skip` 更严格：`skip` 语境下的测试本来就不该在当前环境跑，跳过是预期内路径；这里是该测的 acceptance 因环境问题测不了，'测不了'和'不存在'不能混同，因此显式记 `blocked` 而非静默跳过。"
  110 +
  111 +理由句不是套话，是 D7 5 分档要求的"显式说明与 skip 语义的差异"这一元认知说明，缺了只能拿 4 分档。
  112 +
  113 +### EXECUTE 产出物验收标准
  114 +`test.log` 必须包含：D2 固定模板开头、每条 acceptance 的真实命令+真实输出+判定、（若触发）D6 逐子项标注、（若触发）D7 blocked+对照说明、结尾综合结论。
  115 +
  116 +---
  117 +
  118 +## 四、VERIFY 阶段
  119 +
  120 +提交前逐条自查，不是走个形式：
  121 +
  122 +1. **D1 复查**：通读全篇 `test.log`，用二、动作2 的黑名单表逐句核对，确认没有漏网的自我宽松表述。
  123 +2. **D2 措辞核对**：确认开头模板"不采信"三个字原样出现，且没有任何一条判定引用了 `coder.log` 的结论作为证据的一部分。
  124 +3. **D5(a) 可复现性核对**：假设自己突然失忆重新打开 `test.log`，能不能看懂当前处于哪个阶段、上一步做了什么——若 `test.log` 完全不提 `_research.md`/`_plan.md` 里记录的场景判定（是否中断恢复/是否复用），在 `test.log` 末尾补一句"本次为全新 attempt / 本次从 `_plan.md` 记录的 XXX 阶段恢复"，避免只交 `test.log` 单独一份文件时可复现性不完整（详见 `sample_verification.md` 关于 D5(a) 的发现）。
  125 +4. **D5(b) 场景核对**：若 RESEARCH 阶段判定是中断恢复场景，确认核实命令+返回值确实写进了记录，不是凭记忆断言。
  126 +5. **D4 场景核对**：若 RESEARCH 阶段判定是复用场景，确认 mtime+diff 两项核实都写进了记录。
  127 +
  128 +全部核对通过才算 VERIFY 完成，不是把 `test.log` 写完就直接交付。
  129 +
  130 +---
  131 +
  132 +## 五、已知局限（诚实标注，不夸大规则可靠性）
  133 +
  134 +- D1、D6、D7 三个维度在仓库现存 4 份真实历史样本 + 本次独立验证样本里，**均未真实触发过负面场景**（D1 无 unit-tester 自身真实反例，D6/D7 均为 vacuous 命中）——本手册对应部分的操作指导是**风险移植/构造性设计**，不是从真实反例逐条校准出来的，若未来真实遇到这几类场景，指导是否够用仍需再验证。
  135 +- D2 的"固定模板"是本轮压力测试后新加的修正（见 `iteration_log.md` Round 2），只验证过"套用模板能不能拿到 5 分档"这一层，**未验证**"若上游自我汇报确实有误导性内容时，模板句式本身是否足够让 unit-tester 真正做到独立怀疑"——模板解决的是措辞层面的可核对性，不直接等于实质独立性的充分保证。
system/agents/unit-tester-methodology-trial/train/evolve/evolve_report.md 0 → 100644
  View file @521e762
  1 +# Evolve 阶段报告 — evolve_report.md
  2 +
  3 +## 产出物清单
  4 +- `SKILL.md` —— 四段式操作手册（Round 2 修正版，含 D1 信号词黑名单表、D2 固定声明模板、D3 结构类/
  5 + 可见语义类裁决实操、D4/D5/D6/D7 场景判定与产出模板、第五节局限标注）
  6 +- `sample_verification.md` —— 独立样本 `rn_fc9155c598ef` 逐维度对照记录，含加权和计算
  7 +- `iteration_log.md` —— Round 1→Round 2 真实修正记录
  8 +- 本文件
  9 +
  10 +## 最终得分（独立样本验证，非训练收敛意义上的"最终分"）
  11 +
  12 +```
  13 +D1=5/5×20=20.0 D2=4/5×18=14.4 D3=5/5×15=15.0 D4=5/5×10=10.0
  14 +D5=4/5×10=8.0 D6=5/5×15=15.0 D7=5/5×12=12.0
  15 +──────────────────────────────────────────
  16 +加权和 = 94.4，封顶未触发（D1=5≥4，D2=4≥4），最终得分 = 94.4
  17 +```
  18 +
  19 +94.4 ≥ 目标线 80（优秀档），也 ≥ 及格线 65。与 Digest 阶段两份反算样本（100/92）量级一致。
  20 +
  21 +## "规则集自洽" vs "规则已生产验证"——本次训练达到了哪一类结论
  22 +
  23 +参照 `coder-methodology-trial` 的诚实标注方式，明确区分两类不同强度的结论，不混同：
  24 +
  25 +### A类结论（规则集自洽）—— 本次训练达成
  26 +- D1/D3/D4/D6/D7 五个维度，`SKILL.md` 的操作化判据在独立样本上给出了确定、无歧义的档位判断，
  27 + 规则内部逻辑自洽，机械可执行。
  28 +- D2/D5 两个维度经过独立样本压力测试暴露出真实的操作化缺口（措辞锚点缺失、跨文件可复现性缺口），
  29 + 并已修正——修正后的版本**尚未**再用第三个样本验证是否已经补全，这一点本身也是局限（见下）。
  30 +
  31 +### B类结论（规则已生产验证）—— 本次训练**未**达成，如实说明原因
  32 +- `SKILL.md` 是拿"现状规则未受本次训练影响的历史执行记录"去反向验证判据能不能诊断出问题，**不是**
  33 + "unit-tester 真实读了这份 SKILL.md、按它的操作指导重新走了一遍四段式、产出新 test.log"这种真实
  34 + 装配执行验证。后者需要真实调用 unit-tester（或其试验节点）走一次完整会话，超出本次 Evolve 阶段
  35 + 职责范围（任务书边界明确要求本次不做 Deploy、不碰生产 `system/agents/unit-tester/`）。
  36 +- Round 2 的修正（D2 固定模板、D5 跨文件核对）是"针对压力测试暴露的缺口做的定向修补"，这次修补
  37 + 本身**没有**用第三个样本或真实新执行去验证"修补后是否真的补上了缺口"——如果未来真的用这份
  38 + SKILL.md 指导一次真实执行，D2/D5 是否会按预期拿到5档，仍是未验证的假设。
  39 +
  40 +## 局限诚实汇总（不因为分数达标就掩盖）
  41 +
  42 +1. **D1/D6/D7 证据强度弱，Digest 阶段已如实标注，本次未能补强**：本仓库 4 份历史样本 + 本次1份
  43 + 独立验证样本，D1 全部无违规（0个真实负样本可供校准黑名单的误伤/漏判边界），D6/D7 全部 vacuous
  44 + （0个真实混合场景/blocked场景）。`SKILL.md` 对应部分的操作指导本质上是"风险移植"（D1，从
  45 + coder真实反例移植同构机制）和"构造性设计"（D6/D7），如实标注在 `SKILL.md` 第五节，**没有为了
  46 + 凑证据强度而虚构或夸大**。
  47 +2. **D2/D5 的修正未经二次验证**：见上 B类结论节，Round 2 改动是"发现问题→直接修"，不是"改完再测
  48 + 一次确认改对了"——如果用户希望更高置信度，需要再挑一个样本（或真实新执行）验证修正后的版本。
  49 +3. **仅验证了一个独立样本**：任务书允许二选一，本次只用了 `rn_fc9155c598ef`，`rn_956c699f1160`
  50 + 未测试——`iteration_log.md` 已说明未测第二个样本的判断依据（信息量评估，非偷懒省略）。
  51 +4. **D2 的"固定模板"只解决措辞可核对性，不解决实质独立性**：`SKILL.md` 第五节已标注——模板能保证
  52 + "不采信"三字出现在 test.log 里，但不能保证 unit-tester 真的做到了"面对有误导性的上游自我汇报
  53 + 时依然坚持独立验证"这层实质判断力，这是文本判据的天然局限，不是本次训练能解决的范畴。
  54 +
  55 +## 与 Digest 阶段结论的一致性核对
  56 +- 真实基线 32.2 分（不合格）——本次训练未触碰真实基线的计算依据，`SKILL.md` 是新增的操作手册，
  57 + 不是对 `industry_avg_score.md` 基线计算的修改。
  58 +- 目标线 80 分——本次独立验证样本 94.4 分，与 Digest 阶段两份反算样本（100/92）共同构成三个独立
  59 + 证据点，均超过目标线，进一步支持"目标线真实可达、不需要假设修正"这一 Digest 阶段结论。
  60 +- 及格线 65 分——本次验证样本以及 Digest 反算样本均远超及格线，未发现需要下修及格线的证据。
system/agents/unit-tester-methodology-trial/train/evolve/iteration_log.md 0 → 100644
  View file @521e762
  1 +# 迭代记录 — iteration_log.md
  2 +
  3 +## Round 1（首版）
  4 +- 依据 `benchmark_v1.md` 7 维度 + `knowhow_v1.md` 4 份真实样本，把 D1/D2/D3 转写成 RESEARCH/PLAN/
  5 + EXECUTE/VERIFY 四段式各阶段的具体动作（信号词黑名单表、独立性声明要求、结构类/可见语义类裁决表），
  6 + D4-D7 按各自 vacuous 规则和权重较低的实际情况给出较简版操作指导。
  7 +- 未做真实样本压力测试，规则是否可机械执行未经验证。
  8 +
  9 +## Round 2（独立样本压力测试后修正）
  10 +- 用 `rn_fc9155c598ef`（Hunt 用过但 Digest 反算未用过的独立样本）逐维度对照 Round 1 草稿，发现两个
  11 + 真实缺口（详见 `sample_verification.md`）：
  12 + 1. **D2 措辞锚点缺失**：样本用"未复用……结论"表达独立重跑，语义等价但没点名"不采信"，
  13 + benchmark 逐字要求"不采信"这个锚点词才给5档，Round 1 草稿没把这条隐性要求显式化，导致即使
  14 + 行为完全独立也可能只拿4档。→ 在 PLAN 阶段新增"D2 声明固定模板"，把"不采信"三字定为必须原样
  15 + 出现的锚点词。
  16 + 2. **D5(a) 跨文件可复现性缺口**：单看 `test.log` 看不出是否为中断恢复/复用场景，因为这类判定
  17 + 信息按设计应该在 `_research.md` 里，但历史样本只留下了 `test.log`。→ 在 VERIFY 阶段新增
  18 + "D5(a) 可复现性核对"动作，要求 `test.log` 末尾至少补一句场景归属（全新 attempt / 从哪个阶段
  19 + 恢复），避免只读 `test.log` 时可复现性链条断裂。
  20 +- 修正后未重新对样本3打分（历史样本已既成事实，分数不因规则修订而改变），Round 2 的改动是面向
  21 + "未来 unit-tester 照做能不能拿到该拿的档位"，不是替历史样本加分。
  22 +- 连续 2 轮之间的分数变化：本次训练不是"评分-改进-再评分"的迭代打分循环（不存在"上一轮总分"这个
  23 + 概念，Digest 阶段已经用两份样本反算过 92/100 分），Round 1→Round 2 是"起草-压力测试-修正一次"
  24 + 的单轮验证流程，不适用"连续2轮分数变化<2分即停止"的迭代上限规则（该规则针对的是可重复多轮打分
  25 + 收敛的场景）。已完成任务书要求的"用独立样本验证、发现真实问题、如实修正"全部三步，不再追加更多
  26 + 轮次的形式主义迭代。
  27 +
  28 +## 未做的事（如实说明）
  29 +- 未对样本1（`rn_956c699f1160`）做同样的压力测试——任务书允许二选一，样本3信息量更大（含动画
  30 + 真实性补测，能同时覆盖 D3 两类裁决），选样本3后未见规则出现无法诊断的情况，判断没有必要再测
  31 + 第二个样本去重复验证已经确认覆盖到的判据点。
  32 +- 未修改 `unit-tester-methodology-trial/config.json` 的 status，未触碰生产 `system/agents/
  33 + unit-tester/` 任何文件，按任务边界要求，Deploy 与否留给用户人工审查。
system/agents/unit-tester-methodology-trial/train/evolve/round2_verification.md 0 → 100644
  View file @521e762
  1 +# Round 2 修正后补验收 — round2_verification.md
  2 +
  3 +> 任务：T-mt7g9ql7（org-innovator 派发）
  4 +> 目的：`SKILL.md` Round 2 修正（PLAN 阶段 D2 固定模板要求"不采信"三字逐字出现、VERIFY 阶段新增
  5 +> D5(a) 可复现性核对）之后，`sample_verification.md` 里唯一的实测分数 94.4 分表头写明"按 Round 1
  6 +> 草稿评分"，从未用 Round 2 版本重新验证过。本文补这个缺口。
  7 +> 边界：不改 `train/hunt/`、`train/digest/`；不改 `train/evolve/iteration_log.md`、
  8 +> `train/evolve/evolve_report.md`、`train/evolve/sample_verification.md`、`train/evolve/SKILL.md`；
  9 +> 不碰 `config.json`/生产 `system/agents/unit-tester/`。全部新分析只写在本文件。
  10 +
  11 +---
  12 +
  13 +## 一、方法论前提（必读，避免误判本文档意图）
  14 +
  15 +`data/companies/e2e-demo/runs/run_fa4d7e2bec49/nodes/rn_fc9155c598ef/test.log` 是一份**历史上
  16 +已经写死的文本**——`SKILL.md` Round 2 是"未来 unit-tester 该怎么写"的操作手册，不是评分规则本身。
  17 +真正的评分规则是 `benchmark_v1.md` 的 D1-D7 判据表，**Round 1 → Round 2 全程从未修改过
  18 +`benchmark_v1.md` 一个字**。
  19 +
  20 +所以：如果单纯"拿 Round 2 版 `SKILL.md` 重新对着这份历史 `test.log` 原文机械打一遍分"，只要
  21 +`benchmark_v1.md` 的判据文本没变、`test.log` 原文也没变，结果必然还是 D2=4（原文写的是"未复用
  22 +……结论"而不是"不采信"）、D5(a) 停留在原判定——这不是"验证漏做了"，而是这类"拿操作手册去套已经
  23 +钉死的历史证据"验证方式的天花板：历史文本不会因为教你以后怎么写的手册改了就跟着自己变。
  24 +
  25 +因此本文档实际做两件不同的事，不要混为一谈：
  26 +
  27 +1. **对 `rn_fc9155c598ef` 构造一份"假设性修订版"**——只替换开头声明为 `SKILL.md` 固定模板原文、
  28 + 在结尾补一句场景归属声明，其余判定内容一字不改（因为 D2 的实质独立性本来就没问题，只是锚点词
  29 + 缺失；D5(a) 的可复现性缺口详见下方"重要更正"）。用这份假设性文本重新走一遍 D1-D7，验证的是
  30 + "如果 unit-tester 真的照 Round 2 手册的字面要求去写，能不能拿到该拿的档位"——这不等于验证了
  31 + "unit-tester 未来会不会真的这么写"，两者是不同的问题，第二节结论会明确区分。
  32 +2. **对 `rn_956c699f1160` 做一次真实的、非假设性的原始打分**——这份样本从未被套进 benchmark 打过
  33 + 分（Hunt 定性引用过，Digest 定量反算没用它，sample_verification.md 也没碰它），直接照现行
  34 + `benchmark_v1.md` 打真分，不涉及"历史文本能不能追溯变分"的问题。
  35 +
  36 +---
  37 +
  38 +## 二、rn_fc9155c598ef 假设性修订版逐维度打分
  39 +
  40 +### 2.0 假设性修订的具体内容
  41 +
  42 +- 开头（原第5行）："以下全部是本次独立跑出的真实命令输出（未复用 org-coder-impl 自己的 verify.mjs
  43 + / coder.log 结论）。" → 替换为 `SKILL.md` 二、动作2 固定模板原文：
  44 + > "以下全部是本次独立跑出的真实命令输出。本节点作为独立自测节点，**不采信**上游 `coder.log` /
  45 + > 自带 `verify.mjs` 的自我汇报结论，全部重新真实执行一遍。"
  46 +- 结尾（原第148-149行）在"本次检查独立于……所有命令均在本轮 EXECUTE 阶段实测跑出。"之后追加一句
  47 + `SKILL.md` 四、VERIFY 动作3 要求的场景归属声明：
  48 + > "本次为全新 attempt，无中断恢复/复用场景。"
  49 +- 中间维度1-4 的全部判定文字（第8-146行）**原样不变**。
  50 +
  51 +### 2.1 重要更正：`_research.md`/`_plan.md` 实际存在，`sample_verification.md` 的相关表述有误
  52 +
  53 +`sample_verification.md` D5 一节写道："这是因为 unit-tester 提交的产物里目前只找到了 `test.log`
  54 +一份文件，没有配套的 `_research.md`/`_plan.md`……未在 run 目录下找到对应文件。"
  55 +
  56 +**这个事实陈述是错的**。实测 `ls -la` 该节点目录：
  57 +
  58 +```
  59 +rn_fc9155c598ef/_research.md 5760 bytes 8月23日 22:54
  60 +rn_fc9155c598ef/_plan.md 5920 bytes 8月23日 22:54
  61 +rn_fc9155c598ef/test.log 8190 bytes 8月23日 22:56
  62 +```
  63 +
  64 +`_research.md`/`_plan.md` 与 `test.log` 是同一次会话产出（时间戳相差仅2分钟，`_research.md`/
  65 +`_plan.md` 更早，符合 RESEARCH→PLAN→EXECUTE 的自然顺序），不是补写/伪造。两份文档内容详实：
  66 +`_research.md` 完整记录了产物定位、验收基准、工具选型、"coder.log 自称PASS——这是被测方自己的判定，
  67 +不能直接采信"的独立性声明；`_plan.md` 逐条列出命令+预期结果+执行顺序。通读三份文件（`_research.md`
  68 +→`_plan.md`→`test.log`），能清楚看出这是一次从零开始的全新调查，不存在"复用上一次结论"或"中断恢复"
  69 +的痕迹。
  70 +
  71 +`sample_verification.md` 大概率是只核对了 `test.log` 单文件本身（`test.log` 自身确实完全没提
  72 +`_research.md`/`_plan.md` 的存在），没有实际 `ls` 过节点目录去确认这两份文件是否存在，就直接断言
  73 +"没有配套文件"——这是一处未经核实的推断被写成了"如实说明局限"的口吻，本文档如实指出，不代表
  74 +`sample_verification.md` 其余结论也有问题（其余 6 个维度的核对方式不依赖这条事实）。
  75 +
  76 +这处更正对 **D5(a) 的最终档位判断没有改变结果**（原因见下方 D5 小节），但改变了"为什么是这个
  77 +分数"的依据——不是"缺少配套文件、可复现性有硬伤"，而是"配套文件其实齐全、可复现性链条完整，
  78 +分数卡在4档是 benchmark 判据表自身的结构性天花板，与本样本的实际质量无关"。这是两个性质完全
  79 +不同的结论，不应该被现有的错误表述掩盖。
  80 +
  81 +### 2.2 逐维度打分表
  82 +
  83 +| 维度 | 档位 | 依据 |
  84 +|---|---|---|
  85 +| D1（权重20） | **5** | 沿用 `sample_verification.md` 结论：黑名单表逐句核对零命中（含 `grep -nE "应该\|理论上\|觉得\|看起来\|走查\|推导后\|大概\|可能没问题\|估计"` 复核），第45行"`.visual` 宽度1280px = 容器宽度100%，≥50%达标"属于基于真实测得数值的算术推导，命中 `SKILL.md` 动作2 的例外条款，不算违规。假设性修订未触及维度1-4判定文字，此维度不受影响。 |
  86 +| D2（权重18） | **5** | 固定模板开头逐字包含"不采信"，满足 rubric 5档"明确写出不采信 coder 自我汇报"这一逐字锚点。行为层面本来就已满足（原判定：每条判定都能看到本节点独立命令+真实输出，不引用 `coder.log`/`verify.mjs` 的判定结论作为证据——维度1 responsive_no_overflow 用 `visual-acceptance-check.mjs` 自跑、维度2c 用 `grep` 自数、维度3/4 用自写 `checks.mjs` 而非复用 `verify.mjs`）。逐字锚点+行为独立两个条件在假设性修订版里同时满足，5档判定无歧义。 |
  87 +| D3（权重15） | **5** | 沿用原判定，假设性修订未触及维度1-4判定文字：维度2c（CSS 变量计数）属结构性存在类，纯 grep 恰当；维度4 附加的 `grep "location.hash..."` 只是辅助佐证，主证据是 Playwright 动态观测（3次点击 URL/scrollY 连续采样），不构成"用 grep 代替真实渲染"；维度3 content_correctness 全程用真实 DOM 查询（`checks.mjs`），未用 grep。 |
  88 +| D4（权重10，vacuous） | **5** | 全文（含假设性修订新增的结尾句）未出现"复用/延续上次判断"字样，是全新 attempt，按 D4 特殊规则空真计5分。 |
  89 +| D5（权重10） | **4** | 见 2.3 详细分析——(a) 在更正后的事实基础上（`_research.md`/`_plan.md` 确实存在且完整、假设性修订又补了结尾场景归属句）已经"清晰完整"；(b) 本样本非中断恢复场景，vacuous。但按 `benchmark_v1.md` D5 评分表**第4档原文自身的措辞**："(a) 清晰完整；(b) 场景未触发……按 (a) 单独评分即为此档，要求 (a) 几乎无瑕疵"——这句话明确把"(a)清晰完整 + (b)未触发"这个组合钉在4档，不是5档。5档的定义"(a)(b) 均满足……且（若涉及恢复场景）有显式的阶段核实动作及其依据（样本2正例）"参照的正例（样本2）是一个**真实发生过中断恢复、且做了核实动作**的场景——5档的设计意图看起来是留给"确实经历过(b)场景且处理得当"的情况，而不是"(b)不适用时也能拿满分"。本样本从未涉及中断恢复，(b) 在结构上不可能达到"有显式核实动作"这个更高要求，因此即使 (a) 做到极致，最高只能落在4档。**这是 rubric 本身的天花板，不是修正是否到位的问题。** |
  90 +| D6（权重15，vacuous） | **5** | 沿用原判定，四个维度全部有工具覆盖，无混合场景。 |
  91 +| D7（权重12，vacuous） | **5** | 沿用原判定，全文无工具不可用场景。 |
  92 +
  93 +### 2.3 D2 / D5(a) 核对细节（任务书要求重点核实的两处）
  94 +
  95 +**D2**：`benchmark_v1.md` D2 5档原文——"明确写出不采信 coder 自我汇报，且每条判定都是本节点独立
  96 +执行产生（命令+真实输出），不以 coder.log 的判定结论作为证据"。逐字核对假设性修订版：
  97 +- "不采信"三字原样出现在开头声明 ✓（`SKILL.md` 固定模板逐字抄入，非改写）。
  98 +- 每条判定是否独立产生：维度1（`visual-acceptance-check.mjs overflow`，自己跑）✓；维度2a（同工具
  99 + `style` 子命令，自己跑）✓；维度2b（`checks.mjs` 里的 `structureChildren` 字段，自写脚本）✓；
  100 + 维度2c（`grep` 自数）✓；维度3（自写 `checks.mjs`，"不复用 org-coder-impl 的 verify.mjs"，原文
  101 + 明确写了）✓；维度4（自写 `checks.mjs` 点击测试 + 独立 `grep` 佐证 + `checks_anim.mjs` 动画补测）
  102 + ✓。全部判定均可追溯到本节点独立产生的命令/脚本输出，没有一条引用 `coder.log`/`verify.mjs` 的
  103 + 判定结论作为证据本身（虽然读过 `coder.log` 知道被测项目在哪，但这是"读取信息"不是"采信结论"，
  104 + `_research.md` 里也明确写了"这是被测方自己的判定，不能直接采信"）。
  105 +- 结论：D2 = 5，两个条件都满足，不存在需要打折扣的边界情况。
  106 +
  107 +**D5(a)**：任务书要求"逐字核对固定模板替换后是否真的满足"——核对结果如 2.2 表格所述，**满足了
  108 +(a) 子项的实质要求，但满足 (a) 不代表拿到 D5 的5档**，因为 D5 是 (a)+(b) 组合评分，而 (b) 在本样本
  109 +里结构性不适用。这是任务书原始预判（"重点讲清楚 D2 和 D5(a) 这两个改动点是否真的让判据吃到了5档"）
  110 +里需要澄清的一点：**D2 的改动点确实让判据吃到了5档，但 D5(a) 的改动点即使做对，也吃不到 D5 整体的
  111 +5档**——D5(a) 作为子项本身是"满足"的，但 D5 作为维度的最终档位由 (a)+(b) 组合决定，(b) 不触发时
  112 +表格自身把上限定在4档。这不是 Round 2 修正的缺陷，是 D5 rubric 的既有设计（区别于 D4/D6/D7 那种
  113 +"vacuous 直接给5分"的简单空真规则）。
  114 +
  115 +### 2.4 加权和
  116 +
  117 +```
  118 +D1 = 5/5×20 = 20.0
  119 +D2 = 5/5×18 = 18.0
  120 +D3 = 5/5×15 = 15.0
  121 +D4 = 5/5×10 = 10.0
  122 +D5 = 4/5×10 = 8.0
  123 +D6 = 5/5×15 = 15.0
  124 +D7 = 5/5×12 = 12.0
  125 +──────────────────────
  126 +加权和 = 98.0
  127 +
  128 +封顶检查：D1=5≥4 不封顶；D2=5≥4 不封顶
  129 +最终得分 = 98.0
  130 +```
  131 +
  132 +对比 `sample_verification.md` 按 Round 1 草稿的 94.4 分：**+3.6 分，全部来自 D2 从4档升到5档**
  133 +（18×(5-4)/5=3.6）。D5 维持 8.0 分不变——但含义不同：Round 1 时是"确有缺陷、扣到4档"，假设性
  134 +修订后是"缺陷已修复、但档位结构性封顶在4档"，分数相同、性质不同（详见2.1、2.3）。
  135 +
  136 +---
  137 +
  138 +## 三、rn_956c699f1160 真实逐维度打分（全新样本，非假设性）
  139 +
  140 +样本路径：`data/companies/e2e-demo/runs/run_b962ea87f58f/nodes/rn_956c699f1160/test.log`
  141 +（被测项目 `p-iyshuc`，4维度 `content_completeness`/`nav_scroll_no_hash`/`responsive_no_overflow`/
  142 +`visual_style_apple_like`，40条断言全PASS）。本节直接照现行 `benchmark_v1.md`（未改动）打真分，
  143 +不涉及 `SKILL.md` Round 2、不做任何文本修订，是完全独立的第二个验证点。
  144 +
  145 +`_research.md`/`_plan.md`/`test.log` 三份文件齐全（时间戳 18:48→18:48→18:49，同一次会话），
  146 +内容详实（`_research.md` 逐条比对 `verify.mjs` 断言逻辑是否对应 rubric、明确写"不能只信
  147 +org-coder-impl 自己写的 verify.mjs"的独立性声明；`_plan.md` 列出命令清单+判定规则）。
  148 +
  149 +### 3.1 逐维度打分表
  150 +
  151 +| 维度 | 档位 | 依据 |
  152 +|---|---|---|
  153 +| D1（权重20） | **4**（有争议，见3.2） | 40条断言中39条清一色真实命令+输出支撑。唯一存疑点：第68行"备注"里出现"目测渐变蓝 + 灰阶文字/背景确实符合'核心配色<=4种、简洁大气'的观感"——"目测"是主观视觉估计，不在黑名单逐字列表里，但语义上与"看起来"/"感觉"同类。这条不是独立的 acceptance 判定（`coreColorCount<=4` 的 PASS 判定本身来自 `verify.mjs` 真实输出），而是对该判定的补充说明，用于解释"为什么工具只采样到灰阶色仍然可信"——但补充说明本该用"这条测不了/工具口径有盲区"的诚实句式，却用了目测式主观断言去弥合工具盲区，命中 D1 反对的模式。详见3.2。 |
  154 +| D2（权重18） | **4** | 与 rn_fc9155c598ef 原判定同理：全文两处等价表述（"本节点独立重新执行（非引用上一轮宣称结果）"、结尾"本节点独立重跑，非引用上一轮宣称结果"），行为完全独立（命令1自己重跑40条断言 + 命令2-4用另一个独立工具交叉验证），但**没有出现"不采信"这个逐字锚点词**。按 rubric 4档"有等价表述或有实际独立重跑行为，但未显式点名'不采信上游自我汇报'这句话"，精确命中。 |
  155 +| D3（权重15） | **5** | 全文检索确认**零次使用 grep/正则**（不同于 rn_fc9155c598ef 有两处 grep）。全部检查通过 `verify.mjs`（Playwright headless Chromium）+ `visual-acceptance-check.mjs`（独立实现）两套真实渲染工具完成，不存在"正则解析文本代替真实检测"的边界问题，是比样本3更干净的案例。 |
  156 +| D4（权重10，vacuous） | **5** | 全文未出现复用/延续上次判断字样，`_research.md` 明确是从零开始的独立调查（含对 `verify.mjs` 断言逻辑的逐条审查），按特殊规则空真计5分。 |
  157 +| D5（权重10） | **4** | 与 rn_fc9155c598ef 同理：(a) `_research.md`+`_plan.md`+`test.log` 三份文件齐全、内容清晰、可复现性链条完整；(b) 无中断恢复场景，vacuous。按 D5 评分表第4档原文，(a)清晰+(b)未触发的组合结构性封顶在4档，即使 (a) 无瑕疵也拿不到5档（同2.3的分析）。 |
  158 +| D6（权重15，vacuous） | **5** | 40条断言全部有工具覆盖（`verify.mjs`本身+交叉验证工具），无"部分子项无工具"的混合场景。 |
  159 +| D7（权重12，vacuous） | **5** | 全部命令 exit code 0，无工具不可用场景。 |
  160 +
  161 +### 3.2 D1 判定的不确定性说明（如实标注，不强行下定论）
  162 +
  163 +这是本次验证发现的、此前 4 份 Hunt 样本 + `rn_fc9155c598ef` 都没出现过的新情况：一条**非核心
  164 +子检查**（`visual_style_apple_like` 维度18条断言之一 `coreColorCount<=4`）的判定说明里，测试者
  165 +在真实工具输出（`allHex` 数组，7个真实十六进制颜色值）的基础上，额外用"目测……确实符合……观感"
  166 +这种表述去补强一个工具方法论盲区（`verify.mjs` 只读 `color`/`backgroundColor`/`borderColor` 三个
  167 +计算样式属性，CSS 渐变里的强调色不会被采样，导致 `allHex` 全是灰阶）。
  168 +
  169 +- **认为该扣分的理由**：`benchmark_v1.md` D1 判据要求"遇到无法用工具验证的软性维度，用'这条测不了，
  170 + 原因是……'代替模糊断言"。这里工具确实有方法论盲区（承认了、解释了），但没有诚实地说"这一子项测不
  171 + 全、渐变色是否计入核心配色数无法用当前工具确认"，而是用主观目测去补一个肯定性结论——这正是黑名单
  172 + 想拦的"用推理/印象代替执行"模式，只是没有用到黑名单逐字列出的那几个词。
  173 +- **认为不该扣（或扣得更轻）的理由**：`coreColorCount<=4` 这条判定本身的 PASS 结果来自真实脚本
  174 + 输出（不是目测出来的），目测只是判定通过之后的一句锦上添花式解释，且这条子检查在38/40条真实断言
  175 + 和整个"视觉风格"维度（权重仅0.15）里占比很小，不影响任何核心功能性 acceptance（内容/导航/响应式）
  176 + 的判定可信度。
  177 +- **本文档的判断**：倾向于落在 D1 rubric 第4档（"个别非核心维度存在推断性描述，但有其他真实证据
  178 + 佐证"）而非第3档，因为"目测"这句话依附在一个已经真实验证过的判定上、且引用了真实的 `allHex`
  179 + 数值作为背景说明，不是凭空断言；但**如实承认这是一个偏保守的判断，不是无歧义的机械核对结果**——
  180 + 严格按黑名单精神（信号词命中即"这条判定不算数"）来读，也有理由判进第3档。
  181 +
  182 +**这个判断差异对最终得分的影响不是无关紧要的**，恰恰说明了 `benchmark_v1.md` §3.2 设计封顶机制
  183 +的初衷：
  184 +
  185 +```
  186 +若 D1=4（本文档采用的判断）：加权和 = 16.0+14.4+15.0+10.0+8.0+15.0+12.0 = 90.4，无封顶触发，
  187 +最终得分 = 90.4（优秀档）
  188 +
  189 +若 D1=3（更严格的替代判断）：加权和 = 12.0+14.4+15.0+10.0+8.0+15.0+12.0 = 86.4，
  190 +但 D1=3 触发"总分上限65"的封顶规则，最终得分 = min(86.4, 65) = 65（合格档下限）
  191 +```
  192 +
  193 +同一份 40/40 断言全 PASS、其余6个维度评分完全相同的样本，仅因为一句非核心备注的措辞判定不同，
  194 +最终得分在"优秀"（90.4）和"堪堪合格"（65）之间相差 25.4 分——这正是 D1/D2 封顶机制"防止 D3-D7
  195 +高分稀释核心锚点低分"的设计目的在真实样本上的具体体现，不是本文档在制造问题。**本文档采用90.4
  196 +分作为主结论**，但如实记录这条判断的边界性质，供后续如果要把"目测"类词汇显式补进 D1 黑名单表
  197 +（`benchmark_v1.md` 属于禁止修改范围，此处仅记录观察，不代表本文档已经这样做）时参考。
  198 +
  199 +### 3.3 加权和
  200 +
  201 +```
  202 +主结论（D1=4）：
  203 +D1 = 4/5×20 = 16.0
  204 +D2 = 4/5×18 = 14.4
  205 +D3 = 5/5×15 = 15.0
  206 +D4 = 5/5×10 = 10.0
  207 +D5 = 4/5×10 = 8.0
  208 +D6 = 5/5×15 = 15.0
  209 +D7 = 5/5×12 = 12.0
  210 +──────────────────────
  211 +加权和 = 90.4
  212 +封顶检查：D1=4≥4 不封顶；D2=4≥4 不封顶
  213 +最终得分 = 90.4（优秀档，≥80）
  214 +
  215 +替代判断（D1=3，供参考，见3.2）：
  216 +加权和 = 86.4，D1=3 触发总分上限65
  217 +最终得分 = 65（合格档下限）
  218 +```
  219 +
  220 +---
  221 +
  222 +## 四、结论：Round 2 的两处修正，是否真的能让未来的真实执行拿到该拿的档位？
  223 +
  224 +**D2（PLAN 阶段固定模板，要求"不采信"逐字出现）**：能。两个样本的假设性/等价分析都指向同一个
  225 +结论——原文行为层面本来就已经独立（每条判定都能溯源到本节点自己的命令+输出），Round 1 草稿唯一
  226 +没做到的是把"benchmark 逐字要求哪个锚点词"讲清楚。Round 2 固定模板直接解决这个措辞缺口，第二节
  227 +2.3 的逐字核对显示：只要开头声明照抄模板、行为部分维持原有独立性水准，D2 能从4档干净地升到5档，
  228 +没有发现"照做了但还是拿不到5档"的反例。
  229 +
  230 +**D5(a)（VERIFY 阶段可复现性核对）**：部分能，但有一个此前未被注意到的结构性限制——这条修正解决
  231 +的问题（"只看 `test.log` 单文件时看不出场景归属"）是真实存在的，加一句场景归属声明确实让 (a) 子项
  232 +本身更完整（尤其考虑到本文档在2.1节发现 `_research.md`/`_plan.md` 其实一直都在、只是
  233 +`sample_verification.md` 没查到，Round 2 的修正让 `test.log` 不再依赖"读者会不会去找配套文件"这个
  234 +偶然性）。**但 D5 作为一个维度的最终档位由 (a)+(b) 两个子项组合决定，(b)（中断恢复场景的核实动作）
  235 +在"全新 attempt"类样本里结构性不触发，而 `benchmark_v1.md` D5 评分表第4档原文明确把"(a)清晰+(b)
  236 +未触发"这个组合钉在4档而非5档**——这意味着对于两份验证样本（`rn_fc9155c598ef` 假设性修订版、
  237 +`rn_956c699f1160` 真实样本）这类"从零开始、非中断恢复"的常见场景，即使 D5(a) 的操作指导做到极致，
  238 +D5 也永远拿不到5档，天花板是 rubric 本身的组合评分设计决定的，不是 Round 2 修正力度不够。这一点
  239 +Round 2 修正本身没有说错什么（`SKILL.md` 也没有承诺 D5(a) 修正会让分数封顶到5档），但任务书原始
  240 +表述里"这两处改动点是否真的让判据吃到了5档"这个问题，对 D5(a) 而言答案是**"子项本身满足了，但
  241 +维度整体吃不到5档，这是 rubric 设计使然"**，需要明确区分开，不能笼统回答"是"或"否"。
  242 +
  243 +**额外发现（超出任务书原始预期，但与本次验证直接相关）**：
  244 +1. `sample_verification.md` 关于 `rn_fc9155c598ef` "没有配套 `_research.md`/`_plan.md`" 的表述
  245 + 是一处未经核实的事实错误（详见2.1）——两份文件确实存在且内容详实。这不改变最终得分（因为
  246 + D5 的天花板另有原因），但改变了"为什么卡在4档"的正确解释，本文档已如实指出。
  247 +2. `rn_956c699f1160` 暴露了一种此前4份 Hunt 样本和 `rn_fc9155c598ef` 都没出现过的边界写法——用
  248 + "目测"这类未被逐字列入黑名单、但语义等价的主观印象性词汇去补一个真实工具的方法论盲区。这条
  249 + 判定本文档给出的是90.4分（D1=4）的主结论，但如实记录了65分（D1=3）的替代读法及其触发条件
  250 + （详见3.2）——这不是本文档刻意制造的不确定性，是这条 acceptance 子项本身的措辞确实处于 D1
  251 + rubric 3档/4档的边界，两种读法都有 rubric 原文支持。
  252 +
  253 +---
  254 +
  255 +## 五、局限说明
  256 +
  257 +- 假设性修订终究不等于真实新执行。第二节的98.0分证明的是"如果 unit-tester 严格照 Round 2 固定
  258 + 模板抄写开头声明、补写场景归属句，其余部分维持已证实的独立执行质量，能拿到什么分"，**不能**
  259 + 证明"unit-tester 未来遇到类似任务时会自发想到套用这个模板"——这是操作纪律的问题，不是判据设计
  260 + 的问题，需要靠后续真实样本积累才能验证。
  261 +- D1/D6/D7 三个维度在本次两份样本上依然没有提供真实负面样本（D6/D7 均 vacuous；D1 在
  262 + `rn_fc9155c598ef` 上零命中，在 `rn_956c699f1160` 上只有一处边界性的、判断有争议的疑似命中），
  263 + 与 `benchmark_v1.md`/`SKILL.md` 已如实标注的"仓库现存真实样本尚未真实触发过这几类负面场景"的
  264 + 局限一致，本文档的两次验证没有改变这个结论。
  265 +- 本文档未修改 `sample_verification.md` 里 94.4 分那条记录本身（按任务边界要求保持原样），
  266 + 第二节的98.0分是独立追加的新分析，两份文档并存，读者需要知道 94.4 分对应"Round 1 草稿"、
  267 + 98.0 分对应"假设性套用 Round 2 固定模板"，二者衡量的不是同一件事，不能拿来说"分数涨了3.6分
  268 + 说明 Round 2 修正有效"这种简化表述而不带上文档里给出的所有限定条件。
system/agents/unit-tester-methodology-trial/train/evolve/sample_verification.md 0 → 100644
  View file @521e762
  1 +# 独立样本验证 — sample_verification.md
  2 +
  3 +## 样本选择与独立性核实
  4 +
  5 +- **选用样本**：`data/companies/e2e-demo/runs/run_fa4d7e2bec49/nodes/rn_fc9155c598ef/test.log`
  6 + （knowhow §三"样本3"，被测项目 `p-cgfdcr`，apple 风格官网，四维度全 PASS）
  7 +- **未参与规则推导校准的证据**：
  8 + - Hunt 阶段 `sources.json` 记录 Hunt 用了全部 4 份样本做**定性**现状盘点（"共同点/未找到的部分"），
  9 + 但 Digest 阶段的**定量反算**（`industry_avg_score.md` 基线二，用来验证目标线可达性、直接影响
  10 + benchmark 判据档位设定）只用了样本2（`rn_84d4651597bc`）和样本4（`rn_9d48ea87f326`）。
  11 + - 样本3（`rn_fc9155c598ef`）和样本1（`rn_956c699f1160`）从未被套进 benchmark 逐维度打过分，
  12 + 是真正意义上"benchmark 判据设计时没看过它的具体分数"的独立样本。
  13 + - 本次选样本3而非样本1，原因：样本3含"动画真实性补测"（连续采样 scrollY），内容更丰富，更适合
  14 + 压力测试 D3（正则解析文本边界裁决）——样本3同时出现了 grep 用于纯结构类检查（CSS 变量计数）
  15 + 和 grep 用于辅助判定（hash 跳转检查，有 Playwright 动态观测交叉验证），两种用法在同一份样本里
  16 + 都出现，是检验 D3 裁决表是否够用的好素材。
  17 +
  18 +---
  19 +
  20 +## 逐维度对照（用 `SKILL.md` Round 1 草稿 + `benchmark_v1.md` 逐条核对）
  21 +
  22 +### D1 自我审查信号词黑名单（权重20）
  23 +用黑名单表机械扫描全文（另跑了 `grep -nE "应该|理论上|觉得|看起来|走查|推导后|大概|可能没问题|估计"`，
  24 +零命中）。判定文字全部锚定真实命令输出，包括第45行"`.visual` 宽度1280px = `.feature-inner` 容器
  25 +宽度1280px 的100%，≥50%门槛达标"这类基于真实测得数值的算术推导——按 `SKILL.md` 动作2 的例外条款
  26 +（"规则推导"允许用于真实数值的算术，不是没测就猜），不算违规。
  27 +**结论：D1 = 5，规则能诊断（本样本干净，黑名单没有误伤真实数值算术这条边界）。**
  28 +
  29 +### D2 独立重跑硬约束（权重18）—— 发现真实问题，触发 Round 2 修正
  30 +样本原文两处声明：
  31 +- 开头："以下全部是本次独立跑出的真实命令输出（**未复用** org-coder-impl 自己的 verify.mjs /
  32 + coder.log **结论**）。"
  33 +- 结尾："本次检查**独立于** org-coder-impl 自己的 verify.mjs / coder.log 结论（未直接复用其脚本
  34 + 或结果），所有命令均在本轮 EXECUTE 阶段实测跑出。"
  35 +
  36 +按 `benchmark_v1.md` D2 五分档原文："5 = 明确写出**不采信** coder 自我汇报……"；"4 = 有等价表述
  37 +或有实际独立重跑行为，但**未显式点名'不采信上游自我汇报'这句话**"。
  38 +
  39 +样本3 的措辞是"未复用……结论"/"独立于……结论"——语义上与"不采信"完全等价（都是"不把上游的
  40 +判定结论当证据"），但**没有使用"不采信"这个逐字锚点词**。这是 benchmark 判据本身留下的一个真实
  41 +歧义：D2 rubric 的分档标准里，"5档"和"4档"的区分点写的是具体措辞而非行为实质，如果 unit-tester
  42 +不知道这条隐性的措辞要求，即使做到了行为上的完全独立重跑（本样本确实做到了——每条判定都能看到
  43 +独立命令+真实输出），也只能拿 4 档而非 5 档。
  44 +
  45 +**这是 Round 1 草稿 SKILL.md 没有覆盖到的真实缺口**——Round 1 只写了"检查是否有'不采信上游自我
  46 +汇报'的等价表述"，没有把"benchmark 逐字要求哪个锚点词"讲清楚，导致 unit-tester 即使读了 Round 1
  47 +版本的 SKILL.md，也可能凭直觉写出样本3这种语义正确但档位不够的表述。
  48 +**修正**：在 PLAN 阶段新增"D2 声明固定模板"（`SKILL.md` 二、动作2），要求"不采信"三个字原样出现，
  49 +把隐性措辞要求显式化。
  50 +
  51 +**结论（按 Round 1 草稿评分）：D2 = 4**（等价表述、行为独立，但未点名"不采信"）。
  52 +这不是为了证明规则有用而夸大问题——如实说：样本3 的实际执行质量是过硬的（每条判定都有独立命令支
  53 +撑），4 档而非 5 档纯粹是措辞锚点词缺失，Round 2 修正后的 SKILL.md 针对的是"未来怎么写能拿5档"，
  54 +不改变这份历史样本本身应得的分数。
  55 +
  56 +### D3 正则解析文本边界裁决（权重15）
  57 +逐条核对四个 acceptance 维度里出现的文本类检测手段：
  58 +- 维度2c "核心配色变量种类数"：`grep -n "^\s*--" style.css`——纯粹判断"CSS 里定义了几个自定义
  59 + 属性"，不涉及用户是否看得见，属于**结构性存在类**，按裁决允许直接 grep，不需要补渲染验证。✓
  60 +- 维度4 附加检查 `grep -n "location.hash\|location.href\s*=" script.js`——用于确认代码里不存在
  61 + hash 跳转逻辑，但**同一维度**同时有 Playwright 真实点击 + URL 比对 + scrollY 连续采样的动态
  62 + 观测数据交叉验证，grep 只是辅助佐证，不是唯一证据源。这不构成"用 grep 代替真实渲染"的反模式。
  63 +- 维度3 content_correctness（标题/描述文字）：用 `checks.mjs`（Playwright 真实 DOM 查询）取值，
  64 + 不是对源码字符串做 grep——比样本4的 `sections_completeness` 只用 grep 更严格，天然规避了 D3
  65 + 的边界问题。
  66 +
  67 +**结论：D3 = 5，规则能诊断，且给出的裁决表（结构类 vs 可见语义类）在本样本上分类清晰、无歧义案例。**
  68 +这也说明"结构类/可见语义类"两分法覆盖了样本3出现的全部文本检测手段，没有出现"分不清该归哪类"
  69 +的第三种情况。
  70 +
  71 +### D4 复用/重跑前核实产物未变化（权重10，vacuous）
  72 +全文未出现"复用/延续上次判断"字样，是全新 attempt。**结论：D4 = 5（空真），规则能正确判定这是
  73 +vacuous case，不需要额外核实动作。**
  74 +
  75 +### D5 四段式产出物质量+中断后核实（权重10）—— 发现真实局限
  76 +子项(a)：单看 `test.log` 本身，结构清晰、每条判定有命令+输出+结论，容易看懂"测了什么、结果是
  77 +什么"。但 `test.log` 完全没有提及本次是否为中断恢复场景、是否复用了 `_research.md`/`_plan.md`
  78 +——**这是因为 unit-tester 提交的产物里目前只找到了 `test.log` 一份文件，没有配套的 `_research.md`/
  79 +`_plan.md`**（本仓库真实历史样本的实际交付情况，不是本次训练臆测）。按 `SKILL.md` 的四段式设计，
  80 +`_research.md`/`_plan.md` 应该单独存在，但从这份历史样本能验证的只有 `test.log` 一层。
  81 +子项(b)：全文未提中断恢复，按 vacuous 处理该子项。
  82 +
  83 +**结论：D5 = 4**（子项(a)基本满足但不是"几乎无瑕疵"——缺少与 `_research.md`/`_plan.md` 的显式
  84 +交叉引用；子项(b) vacuous）。
  85 +**如实标注局限**：本次验证只能核对 `test.log` 单份文件，无法确认这份历史样本当时是否真的产出过
  86 +`_research.md`/`_plan.md`（未在 run 目录下找到对应文件，可能是当时的四段式产出规范不要求单独文件，
  87 +也可能是 timeline 只保留了最终产物）。这条局限不是"规则诊断不出问题"，而是"仓库现存历史数据本身
  88 +的完整性边界"，如实记录，不用臆测的"应该存在"去补分。
  89 +
  90 +### D6 混合可测/不可测子项降级路径（权重15，vacuous，构造性判据）
  91 +四个 acceptance 维度全部有对应工具覆盖，无混合场景。**结论：D6 = 5（空真）**，与 `benchmark_v1.md`
  92 +"4份真实样本全部落在这一档"的判断一致，本样本延续同一结论，**仍未提供 D6 真实校准证据**（如实
  93 +延续 Digest 阶段的诚实标注，不因为本次也命中 vacuous 就误以为规则已被验证过）。
  94 +
  95 +### D7 blocked vs skip 语义完整性（权重12，vacuous）
  96 +全文无工具不可用场景。**结论：D7 = 5（空真）**，同样延续"仍无真实先例"的局限标注。
  97 +
  98 +---
  99 +
  100 +## 加权和与最终得分（按 Round 1 草稿评分，用于定位缺口）
  101 +
  102 +```
  103 +D1 = 5/5×20 = 20.0
  104 +D2 = 4/5×18 = 14.4
  105 +D3 = 5/5×15 = 15.0
  106 +D4 = 5/5×10 = 10.0
  107 +D5 = 4/5×10 = 8.0
  108 +D6 = 5/5×15 = 15.0
  109 +D7 = 5/5×12 = 12.0
  110 +──────────────────────
  111 +加权和 = 94.4
  112 +
  113 +封顶检查：D1=5≥4 不封顶；D2=4≥4 不封顶（D2封顶只在≤3档触发）
  114 +最终得分 = 94.4
  115 +```
  116 +
  117 +**94.4 分，"优秀"档（≥80）**，与样本2（100分）、样本4（92分）的量级一致，进一步印证
  118 +`industry_avg_score.md` 的判断——`unit-tester` 真实执行水平本身不差，本次训练要补的是"把已验证
  119 +有效的做法显式写下来"（尤其是 D2 的措辞锚点、D5 的跨文件可复现性），不是覆盖全局的能力缺陷。
  120 +
  121 +---
  122 +
  123 +## 本次验证的诚实结论
  124 +
  125 +1. **规则确实能诊断出真实问题**：D2 的措辞锚点缺口（"未复用结论"≠"不采信"的逐字要求）和 D5(a)
  126 + 的跨文件可复现性缺口，都是压力测试样本3 时才真正暴露出来的——Round 1 草稿的 D2/D5 操作指导
  127 + 不够具体，已在 `SKILL.md` Round 2 修正。
  128 +2. **规则没有夸大问题诊断能力**：D1/D3/D4/D6/D7 在本样本上全部给出确定、无歧义的档位判断，没有
  129 + 出现"规则本身说不清该怎么判"的情况——这几维度的操作化程度是够的。
  130 +3. **D1/D6/D7 依然缺乏真实负面样本支撑**：本次独立验证样本同样落在"D1 无违规、D6/D7 均 vacuous"
  131 + 这一类，和 Hunt/Digest 阶段的结论一致，**没有新增任何真实负面证据**，`SKILL.md` 第五节局限标注
  132 + 如实延续这一点，不因为多测了一个样本就假装证据强度提升了。
system/agents/unit-tester-methodology-trial/train/hunt/knowhow_v1.md 0 → 100644
  View file @521e762
  1 +# knowhow_v1.md — unit-tester-methodology-trial · Hunt 阶段
  2 +
  3 +训练目标：把「acceptance 逐条转成可靠的真实检测、且绝不编造检测结果」这条判据，从
  4 +`system/agents/unit-tester/agent.md`+`soul.md` 现状的原则性文字，训练成更可执行的方法论。
  5 +本文档只做调研 + 证据采集，不产出训练方案（那是 Digest 阶段的事）。全部引用来源均标注出处；
  6 +外部资料找不到可靠来源的一律标「未核实」，不编。
  7 +
  8 +---
  9 +
  10 +## 一、现状规则盘点（`unit-tester/agent.md` + `soul.md` 原文摘录）
  11 +
  12 +来源：`system/agents/unit-tester/agent.md` 全文、`system/agents/unit-tester/soul.md` 全文（只读，未改）。
  13 +
  14 +**硬约束 1-7 摘录**：
  15 +1. e2e-demo 图里的自测节点（`org-coder-impl` → 你 → `org-coder-validator`），唯一职责是「真的跑一遍检查，把结果如实写进 `log`」——不是最终判卷人。
  16 +2. 开工前必须读齐上游产物，路径以任务描述「上游输入」段为准，不写死相对路径。
  17 +3. 三选一检测手段：网页/静态站点用 `scripts/visual-acceptance-check.mjs`（真实 headless Chromium）；代码/接口用产物自带测试命令；两类都跑不了要如实说明，不能编一份假测试。**明确点名反模式**：「不要用正则解析文本假装测过」。
  18 +4. 必须交出 `test.log`（跑了什么命令、真实输出、每条 acceptance 过没过），只写到节点私有目录。
  19 +5. **acceptance 是判定标准，不是参考资料**，逐条不抽查，测不了的条目明说「这条测不了」。
  20 +6. **工具跑不起来算 `blocked`，不是「先跳过这条当没看见」**。
  21 +7. 四段式（RESEARCH→PLAN→EXECUTE→VERIFY）必须走命令行流转，不许在同一轮对话里从读产物直冲写 `test.log`。
  22 +
  23 +**soul.md 工作原则 1-6 摘录**：
  24 +1. 能用真实工具就不自己现编检查逻辑；正则解析文本/凭源码"看起来对"就打勾都不算测试（点名 35 号文档记录过的真实拆穿案例）。
  25 +2. acceptance 不过就是没测完，没有例外，测不了的条目要如实写"为什么"。
  26 +3. 四段式不许跳，每阶段产出要写给"失忆后的自己"看得懂。
  27 +4. 测试是为了发现问题不是为了让流程走下去——跑出真实 fail 不是失败，是工作成果。
  28 +5. 交付边界不能越：`test.log` 只写到节点私有目录，不改被测 `artifact`。
  29 +6. 工具跑不起来是 `blocked`，不能因为工具坏了就默认"大概率没问题"。
  30 +
  31 +### 现状规则的真实缺口（对照下文第三节 4 份真实历史样本逐条核实后得出，非空想推理）
  32 +
  33 +1. **「acceptance 是判定标准」缺一个可机械核对的自审清单**——现状只有"不许"，没有像 `coder-methodology-trial` 训出的 D1 那样一张具体的「信号词黑名单」（"代码走查""规则推导""理论上""逻辑上应该"等，命中即判定不算数）。unit-tester 判的是别人（coder）的测试有没有真跑过，但它自己写 `test.log` 时同样可能落入"我看代码觉得应该没问题"这种自我宽松解释——现状规则对**自己**这层自我审查没有给出等价的机械动作。这是与 `coder-methodology-trial` 训练成果最直接可复用、但目前完全空缺的一环。
  34 +2. **对"上游 coder 自我汇报"的态度没有写成硬约束**——四份真实样本（见下文第三节）无一例外都在 `test.log` 里主动写了"不采信 coder 自己的自测宣称，独立重新执行"，这是一条被反复印证有效、但从未被写进 `agent.md`/`soul.md` 的隐性纪律。`coder-methodology-trial` 的调研已经证明了"coder 自我汇报可能是代码走查冒充"（样本A attempt-1）、"coder 可能悄悄写了 SDD 明确禁止的代码且不留痕"（样本B 发现5）——这些恰恰是 unit-tester 存在的理由，但现状规则没有把"不采信上游自测结论"钉成一条显式的硬约束，是训练时应该补的第一条。
  35 +3. **"正则解析文本假装测过"这条反模式的适用范围界定不清**——硬约束3原文举的例子是"溢出/字号/对比度"这类**布局类**检查不能用正则代替真实渲染，但没有回答：**内容存在性检查**（比如某个标题文字是否出现在 HTML 里）能不能用 `grep`/正则？四份真实样本里，attempt-4 案例（`rn_9d48ea87f326`）对 `sections_completeness` 维度就是用 `grep -n "section id\|feature-title\|feature-desc" index.html` 判定的——这在字面上就是"正则解析文本"，但当前规则没有明确这算不算被禁止的"假装测过"。这是一个真实的未覆盖边界：`grep` 能确认文字**存在于源码**里，但不能确认它**在真实渲染中可见**（比如被 `display:none`/`visibility:hidden`/移出视口裁掉）——如果被测代码存在这类隐藏文本的边界情况，现状规则挡不住。
  36 +4. **没有"复用/重跑前先核实被测产物未变化"的强制要求**——`rn_84d4651597bc` 样本（因 infra_flake 中断后从 RESEARCH 重新走)主动做了"上游 verify.mjs 字节级 diff 一致，被测三份产物 mtime 均未变化"的核实，这是一条自发出现、值得推广、但目前不是硬约束的好实践——现状规则完全没提"复用上一次测试结论前要不要核实被测物没变"这件事。
  37 +5. **会话中断后"当前阶段到底停在哪"没有官方核实手段**——同一样本记录了一个具体技巧："引擎侧当前阶段确实仍停在 RESEARCH（`task transition --phase plan` 执行后返回 success，说明之前的 transition 从未真正生效）"——这是 agent 自己摸索出的一个用于确认真实阶段状态的方法，但 `agent.md` 的四段式说明完全没有提供"如何在中断后确认真实所处阶段"这类恢复流程指导，纯靠个体会话即兴发挥。
  38 +6. **"两类都跑不了"的降级路径缺少中间态定义**——硬约束3只给了网页/代码两个大类的"跑不了→如实说明"，但没有覆盖"同一个 acceptance 维度里，部分子项有工具能测、部分子项没有对应工具"这种混合情况该怎么处理（是整条判 `blocked`，还是能测的子项判、不能测的子项单独标注？）。四份真实样本都恰好落在"全部维度都有工具覆盖"的幸运情况里，这条路径从未被真实验证过，仍是一个未落地的空白。
  39 +7. **`config.json` status 至今是 `training` 的根因，来自装配可靠性问题，不是能力问题**——见下文第二节 35 号文档摘录，`unit-tester` 历史上曾因本体 `_base` 骨架未填充而空转，这条已用「提案A」（`body_not_ready` 闸门）在引擎层堵住，但 `unit-tester` 本身作为一个训练对象，从未真正走完 FDE 全流程转正——这次训练要解决的是"方法论从原则性文字变成可操作判据"，而不是"能力不够"，与 35 号文档 §1.4 的结论完全一致（详见下文）。
  40 +
  41 +---
  42 +
  43 +## 二、35 号文档摘录 —— 与 unit-tester 检测质量直接相关的具体案例和结论
  44 +
  45 +来源：`docs/todo/system-design/35-validation-rigor-and-body-readiness-proposal.md`（全文精读，逐条标注文档内位置）。
  46 +
  47 +### 关键案例（§1.2，文档第 33-41 行）
  48 +真实回归任务 `T-mt2r6fz0-125b`（"做一个 apple.com 风格的 lemonboss 官网"）撞见的问题：**`unit-tester` 本体的 `agent.md` 全程是空白的 `_base` 骨架**（带 `LEMONBOSS_BASE_SKELETON` 哨兵标记），隔壁 `coder` 却正常填充过。这次撞见的样本发生在 32 号文档修复提交**之前 1 小时**。结论原文："`unit-tester` 在没有任何角色指导的情况下，只能靠自己对'该怎么测试网页'的通用理解去写检查脚本，写出来的东西天然比有明确方法论指导的 `org-coder`/`coder-validator` 弱。"——**权重：这次具体检查偏弱的最直接原因**。
  49 +
  50 +### 新发现的架构缺口（§1.3，文档第 43-57 行）
  51 +`missingBodyDefinition()`（检测本体是否还带 `_base` 哨兵/空白）**只在招聘/建公司/dream 沉淀路径上被调用，图执行的核心路径（`advanceOne`/`defaultAgentExecutor`）一次都没有调用它**——即使装配环节永不留半成品，图执行侧也没有第二道防线，会原样把空白提示词交给真实 Claude CLI 去跑，静默产出"看起来是回复、其实没有角色指导"的结果。这正是 `unit-tester` 那次事故的真实成因。
  52 +
  53 +### 不是能力问题的两次订正（§1.4，文档第 59-67 行）
  54 +- 最初以为"没有浏览器工具，物理上做不到视觉检查"，后来发现同一批工具权限下隔壁一条任务真的跑出了 Playwright 测试——能力和权限都够，缺的是指导。
  55 +- `unit-tester` 在零指导情况下，**依然主动写出了一份能真实解析 CSS `clamp()` 算出字号比例、能识别锚点跳转反模式的静态断言脚本**——这是"相当不错的即兴发挥"，不是能力不足。
  56 +
  57 +### 复盘结论排序（文档第 68-71 行）
  58 +"这次任务结果差，主要是架构 + 一个具体的可靠性 bug，不是模型能力问题。"按影响力排序：①执行侧没有完整性闸门（新发现，架构缺口）> ②招聘装配可靠性 bug（已知，这次撞上了修复前的窗口）> ③图模板设计缺陷（已修）> ④agent 能力（不是问题，甚至有正面例子）。
  59 +
  60 +### 提案 A 实现记录（文档第 79-131 行）——已实施，与本次训练的关系
  61 +`advanceOne`/`runClaimedNode` 派发前查 `agentLocator.missingBodyDefinition(systemAgentId)`，非空就直接判 `fail`（`ENGINE_FAIL_REASONS.BODY_NOT_READY`），走正常的选边/兜底/熔断（commit `bab675c`，随后收窄到"只在真实执行器下生效"避免误伤单测，commit `fadb6fa`，单测回到 1004/1004）。
  62 +**对本次训练的含义**：这条修复解决的是"unit-tester 本体会不会拿到空白提示词"的问题，**不解决**"unit-tester 本体填充了内容之后，这份内容够不够具体、可操作"的问题——后者正是本次 Hunt/Digest/Evolve 训练要处理的。两者是不同层面的问题，本次训练不应该重复解决已经修好的架构问题。
  63 +
  64 +### 提案 D 摘录（文档第 187-219 行）——证据闸门与 unit-tester 判据的关系
  65 +提案 D 给 `goal-benchmark.json` 里含"打开浏览器/截图/开发者工具"等关键词的验收维度加了引擎级证据闸门（`readSiblingEvidence()`：`attempt-<n>.scores.json` → 同目录 `attempt-<n>.json` → 取 `dimensions[].evidence`），命中关键词但无 `evidence_ref` 直接判不过。**这层闸门校验的是 `benchmark-validator` 角色的判词文件**，不是 `unit-tester` 的 `test.log`——`test.log` 目前不接入这套证据闸门（`produces:["log"]` 这个 kind 不强制索引，见 33 号文档），是两条独立的证据链，训练时不要混淆两者的验收对象。
  66 +
  67 +---
  68 +
  69 +## 三、仓库内真实历史检测样本（已找到 4 份，逐份核实为真实 `unit-tester` 节点执行，非编造）
  70 +
  71 +**核实方法**：通过 `grep 'rn_xxx' <run>/timeline.ndjson` 找到 `"system_agent_id":"unit-tester"` 的调用记录，确认节点角色，而非只看目录名猜测。
  72 +
  73 +| # | 节点路径 | 所属 run/task | 被测项目 | 结果 |
  74 +|---|---|---|---|---|
  75 +| 1 | `data/companies/e2e-demo/runs/run_b962ea87f58f/nodes/rn_956c699f1160/test.log` | `run_b962ea87f58f`（timeline 记录 node_name=`org-coder-test`） | `p-iyshuc`（apple 风格官网） | 40/40 PASS |
  76 +| 2 | `data/companies/e2e-demo/runs/run_b962ea87f58f/nodes/rn_84d4651597bc/test.log` | 同上 run，另一节点（infra_flake 中断后重跑） | `p-iyshuc` | 36+4=40/40 PASS（两轮独立重跑） |
  77 +| 3 | `data/companies/e2e-demo/runs/run_fa4d7e2bec49/nodes/rn_fc9155c598ef/test.log` | `run_fa4d7e2bec49` | `p-cgfdcr`（apple 风格官网） | 四维度全 PASS，overall_pass_threshold=80 达标 |
  78 +| 4 | `data/companies/e2e-demo/runs/run_c7d233619784/nodes/rn_9d48ea87f326/test.log` | `run_c7d233619784` | `p-pyjha7`（官网首页） | 4 条 acceptance 全 PASS（attempt-4） |
  79 +
  80 +**共同点（现状规则实际执行得怎么样，正面证据）**：
  81 +- 全部 4 份都严格做到了硬约束3"能用真实工具就不自己编"：网页类产物统一用 `scripts/visual-acceptance-check.mjs`（overflow/style/console 子命令）+ 自建 Playwright 脚本（`verify.mjs`/`verify_nav.js`/`checks.mjs`）交叉验证，不是单一证据源。
  82 +- 全部 4 份都明确写了"不采信上游 coder 自己的测试宣称，独立重新执行"（样本4 原文："coder.log 里 coder 自己已用 Playwright 自测过并宣称四条 PASS，但那是实现者的自我汇报，本节点作为独立自测节点，不采信、全部重新真实跑过一遍"）——这是**现状规则没有写、但被四次独立会话不约而同做到的隐性纪律**，见第一节缺口2。
  83 +- 样本3（`rn_fc9155c598ef`）做了超出 acceptance 硬性要求的"动画真实性补测"（每 ~50ms 采样 `scrollY`，用连续渐进曲线区分"真实平滑滚动"与"CSS/JS 配置导致的瞬间跳变"）——这类细粒度验证手法在 agent.md 里完全没有被点名要求，是执行者自己的加分发挥。
  84 +- 样本2（`rn_84d4651597bc`）在会话因 infra_flake 中断后重启时，主动核实"被测产物 mtime 未变化、上游 verify.mjs 字节级 diff 一致"才决定复用 `_research.md`/`_plan.md` 而不是从零重写，并且**仍然在 EXECUTE 阶段重新真实跑了一遍全部检查命令**（不是复述旧 test.log 结论）——见第一节缺口4。
  85 +- 样本4（`rn_9d48ea87f326`）的 `sections_completeness` 维度检查是用 `grep` 对源码文本做的判定，是四份样本里唯一命中"正则解析文本"这个技术手段的案例——见第一节缺口3，这不构成对该样本的负面评价（当时判据合理，检查目标是"文字是否存在"而非"布局是否正确"），但暴露了现状硬约束3的措辞边界不够精确。
  86 +
  87 +**未找到的部分**：只搜索到这 4 份，仓库内没有找到 `unit-tester` 真实判 `blocked`（工具跑不起来）或真实发现 acceptance fail 需要打回的历史样本——第一节缺口6（混合可测/不可测子项该怎么处理）和"发现真实 fail 该怎么记录"这两条路径，在本仓库现存历史数据里**没有真实先例可供参考**，如实说明，不编造。
  88 +
  89 +---
  90 +
  91 +## 四、coder-methodology-trial 训练方法论 —— 可迁移部分与不可迁移部分
  92 +
  93 +来源：`system/agents/coder-methodology-trial/`（`SKILL.md`、`train/hunt/knowhow_v1.md`、`train/fde_report.md` 全文精读）。
  94 +
  95 +### 可迁移的训练方法论（"怎么训"，不是"训什么"）
  96 +
  97 +1. **先定位真实失败案例锚点，再反推失败模式，再翻译成机械检查动作**——`coder` 训练是拿样本A "代码走查+规则推导冒充PASS"这个真实反例，反推出"验证方式扫描"（D1 信号词黑名单）。`prd-planning` 训练是拿"三个卖点区块各一句话"这个真实反例，反推出"描述性语言扫描"。两次训练的共同底层动作是：**用"能不能在产出物里找到一个具体的失败信号词/失败模式"这种可机械核对的问题，取代"我觉得写得够不够好"这种主观判断**。
  98 +2. **正反例对照表 + 可复用的检查表格式（清单A/清单B）**——`coder` SKILL.md 用"清单A（接口契约锚点表）/清单B（明确禁止清单）"这种在 RESEARCH 阶段建表、后续阶段全程带着走的结构，把"读规格时要注意什么"变成一次性建表动作，而不是靠临场记忆。
  99 +3. **诚实标注训练局限，不夸大验证深度**——`fde_report.md` 第二节明确承认"给 SKILL.md 打分是纯推理，不是真实装配执行"，区分了"规则集本身自洽"（A类结论）和"规则集已在生产验证过"（B类结论，本次未达成）。这条方法论对本次训练同样适用：Hunt 阶段找到的 4 份真实样本都是**现状规则（未受本次训练影响）的历史执行记录**，不是"新方法论指导下的真实执行"，这个界限要在后续 Digest/Evolve 阶段保持清楚。
  100 +
  101 +### 不可迁移的部分（判据内容不同，不能直接照搬）
  102 +
  103 +- `coder` 判的是"代码有没有照规格写"（执行忠实度），`unit-tester` 判的是"测试有没有真的跑过"（验证真实性）——两者的核心锚点完全不同：`coder` 的 D5（清单B明确禁止项）关心"写没写不该写的代码"，`unit-tester` 没有等价的"代码"产出物，它的核心风险是"记录没记录真实跑过的证据"。
  104 +- `coder` 的清单A/清单B锚定的是 SDD 技术契约（class名/数值/明确禁止句），`unit-tester` 需要锚定的是 acceptance 条目本身与检测手段的映射表——结构类似（都是"逐条扫描建表"），但表的内容和适用判据必须单独推导，不能直接套用 D1-D6 的具体定义。
  105 +- `coder` 的信号词黑名单（"代码走查""规则推导""理论上"）是**判断"实现者自己是否真的验证过"**；`unit-tester` 如果要训练同类清单，判断对象应该是"**测试者（unit-tester 自己）是否真的验证过**"——评判主体从"下游对上游的怀疑"变成"上游对自己的自我审查"，措辞和触发条件需要重新设计，不能整体复制 D1 的清单原文。
  106 +
  107 +---
  108 +
  109 +## 五、外部方法论调研（Web Search，每条标来源；找不到可靠来源明确标"未核实"）
  110 +
  111 +### (a) ATDD / 验收测试驱动开发
  112 +
  113 +核心主张：在开发前把验收标准转成可执行、无歧义的判定条件，客户/开发/测试三方协作定义，用清晰具体、可测量的语言书写（工具如 Gherkin 的 Given/When/Then 常被提及）。收益：提前暴露隐藏假设，减少返工。
  114 +
  115 +来源：
  116 +- [What is Acceptance Test Driven Development? | Testlio](https://www.testlio.com/blog/what-is-acceptance-test-driven-development)
  117 +- [Acceptance Test Driven development (ATDD) in Software Engineering | GeeksforGeeks](https://www.geeksforgeeks.org/software-engineering/acceptance-test-driven-development-atdd-in-software-engineering/)
  118 +- [A guide to acceptance test-driven development (ATDD) | LogRocket Blog](https://blog.logrocket.com/product-management/acceptance-test-driven-development/)
  119 +- [What is ATDD | BrowserStack](https://www.browserstack.com/guide/what-is-atdd)
  120 +
  121 +**对本训练的映射**：`unit-tester` 的处境和 ATDD 语境有一个关键差异——ATDD 讨论的是"验收标准写清楚"这一环（本仓库这部分归 `prd-planning`/`goal-benchmark` 管），`unit-tester` 拿到的 acceptance 已经是既成事实，它的职责是"把已经写好的 acceptance 转成实际检测动作并诚实执行"，更接近 ATDD 里"自动化验收测试的执行环节"而非"定义环节"。ATDD 强调的"清晰、可测量的验收标准语言"这条，可以反过来作为 Digest 阶段判断"这条 acceptance 能不能被机械转成检测步骤"的一个参考尺——但这权责边界不完全在 unit-tester，遇到 acceptance 本身写得含糊，现状硬约束5已经要求"测不了就如实说明"，这条与 ATDD 精神一致。
  122 +
  123 +### (b) 测试证据留痕规范 —— 如何证明一条检查是真跑出来的而不是推导出来的
  124 +
  125 +要点：测试证据（test evidence）不只是"声称通过"，而是可审计的产物——截图/录屏提供 UI 状态视觉证据，执行日志提供逐步记录（跑了什么、结果是什么、为什么），可追溯性矩阵把需求-测试-执行-缺陷链接起来。核心结论："没有'谁测的、测了什么'的记录，'测试通过了'这句话本身没有意义"（Test traceability... without a record of what got tested and by whom, "the test passed" means nothing）；理想做法是执行时就自动捕获带时间戳的不可篡改记录，而不是事后补写可能被伪造的文档。
  126 +
  127 +来源：
  128 +- [Building a Test Evidence Strategy That Scales | TestCollab](https://testcollab.com/blog/building-a-test-evidence-strategy-that-scales)
  129 +- [Test Coverage vs. Traceability: What QA Teams Need to Know | TestRail](https://www.testrail.com/blog/test-coverage-traceability/)
  130 +- [Test Evidence - What it is, Why & How to Capture? | Testsigma](https://testsigma.com/blog/test-evidence/)
  131 +
  132 +**对本训练的映射**：这条外部原则与仓库现状高度吻合——`test.log` 本身就是"执行日志"这一类证据，第三节 4 份真实样本里贴的真实命令输出、截图路径（`desktop.png`/`mobile.png`）都符合这条原则。**可补的具体判据**：外部资料强调的"可追溯性"（第三方能不能照着记录复现）在本仓库 `coder-methodology-trial` 的 D2（可重放性：环境+输入+预期输出三要素）里已经有现成的可迁移定义（见第四节），`unit-tester` 训练时可以直接借用同一套"三要素缺一不算"的判据，而不必重新发明。
  133 +
  134 +### (c) "工具不可用时如何诚实降级汇报" —— 混合证据：pytest 惯例 vs 本仓库现状规则的真实分歧
  135 +
  136 +调研 pytest（业界主流测试框架之一）对"依赖不可用"场景的官方处理惯例：**pytest 官方文档明确把"依赖的外部资源不可用（如数据库连接不上）"归为 `skip`（跳过），不是 `error`/`fail`**——"skip 意味着你预期这个测试本该能过，除非环境（错误的 Python 解释器、缺失依赖）阻止它运行"；`skip` 的测试根本不会被执行，和"预期会失败"的 `xfail` 是两个不同语义。
  137 +
  138 +来源：
  139 +- [How to use skip and xfail to deal with tests that cannot succeed | pytest documentation](https://docs.pytest.org/en/stable/how-to/skipping.html)
  140 +
  141 +**对本训练的重要含义（真实分歧，不是照搬）**：这条外部惯例与本仓库 `unit-tester` 硬约束6**直接相反**——硬约束6明确要求"工具跑不起来算 `blocked`，不是先跳过这条当没看见"，而 pytest 生态的默认惯例恰恰是把"工具/依赖不可用"当作 `skip`（跳过，不计入失败，甚至不计入执行）。**这不是仓库规则错了，而是一个值得在 Digest 阶段明确记录的、有意识的偏离**：pytest 的 `skip` 语境是"这条测试本来就不该在这个环境下跑"（比如 Windows-only 测试在 Linux 上），跳过是预期内的正常路径；而 `unit-tester` 的场景是"该测的 acceptance 条目因为工具坏了/环境问题测不了"，属于**验收链条上出现了未知缺口**，如果比照 pytest 惯例静默 `skip`，等于让一条本该被验证的 acceptance 悄悄从"待验证"变成"不存在"，与本仓库"acceptance 逐条不抽查""绝不编造检测结果"的核心诉求直接冲突。**这条外部资料的价值不是提供了一个可以照抄的最佳实践，而是提供了一个可以类比反证的对照组**——用来在 Digest 阶段说明为什么本仓库必须坚持比 pytest 更严格的 `blocked` 语义，而不是简单认为"业界标准做法是 skip、我们应该跟进"。
  142 +
  143 +### (d) 其它未核实到可靠来源的主题
  144 +
  145 +- "工具不可用时如何诚实降级汇报"的**专门方法论**（区别于上面(c)找到的 pytest 技术惯例，这里指"组织/流程层面该如何汇报"）——搜索未找到聚焦这个具体主题的高权威来源，搜到的结果多是"降级"（degradation）在系统可用性/性能监控语境下的用法（如"把'慢'和'不可用'分开记录，不要混为一谈"），与"测试工具本身不可用时该如何汇报"不是同一件事，**标注"未核实"，不作为本次训练依据引用**。
  146 +
  147 +---
  148 +
  149 +## 六、给 Digest 阶段的判据缺口清单（汇总，供后续阶段直接使用）
  150 +
  151 +1. **需要一份"unit-tester 自我审查"版信号词/反模式清单**（对标 coder D1，但评判主体是自己而非上游），命中"我看代码觉得应该没问题""理论上会通过"这类自我宽松表述时，判定该条 `test.log` 记录不算数——现状规则完全空缺，是训练重点。
  152 +2. **需要把"不采信上游 coder 自我汇报，必须独立重新执行"钉成显式硬约束**——四份真实样本 100% 自发做到，但从未写进 `agent.md`/`soul.md`，属于"该写而未写"的缺口。
  153 +3. **需要明确"正则解析文本"这条反模式的适用边界**——布局类（溢出/字号/对比度）禁止 vs 内容存在性类（grep 检查文字是否出现）现状边界不清，样本4 已经出现真实的边界案例，需要 Digest 阶段决定是否要求内容存在性检查也升级为真实 DOM 渲染查询（如 `innerText`/`textContent`，能排除 `display:none` 类隐藏文本）。
  154 +4. **建议补一条"复用/重跑前先核实被测产物未变化"的机械动作**（mtime/字节级 diff），样本2 已有真实先例可直接引用为正面参照。
  155 +5. **建议补一条"会话中断后如何核实真实所处阶段"的操作指导**，样本2 已摸索出具体技巧（用 `task transition` 的返回值反推真实状态），可以直接沉淀为可复用步骤。
  156 +6. **"部分子项有工具、部分没有"的混合降级路径，仓库内无真实先例，需要 Digest 阶段构造性设计**（不是从真实反例反推，这条要如实标注为"构造性场景，样本量为零"，参考 `workgraph-planning-methodology-trial` 训练时对"目标线可达性论证是构造性的、非真实反例驱动"的类似诚实标注方式）。
  157 +7. **`blocked` vs 业界 `skip` 惯例的分歧需要在训练产出里显式说明**（第五节(c)），避免后续训练或人工审查者误以为"我们应该向 pytest 式 skip 靠拢"而弱化现有的更严格语义。
system/agents/unit-tester-methodology-trial/train/hunt/sources.json 0 → 100644
  View file @521e762
  1 +{
  2 + "internal_sources": [
  3 + {
  4 + "path": "system/agents/unit-tester/agent.md",
  5 + "used_for": "现状硬约束1-7原文摘录，第一节现状规则盘点",
  6 + "verified": true
  7 + },
  8 + {
  9 + "path": "system/agents/unit-tester/soul.md",
  10 + "used_for": "现状工作原则1-6原文摘录，第一节现状规则盘点",
  11 + "verified": true
  12 + },
  13 + {
  14 + "path": "system/agents/unit-tester/config.json",
  15 + "used_for": "确认 status 至今为 training，从未走完 FDE 全流程",
  16 + "verified": true
  17 + },
  18 + {
  19 + "path": "docs/todo/system-design/35-validation-rigor-and-body-readiness-proposal.md",
  20 + "used_for": "第二节全部内容：unit-tester 空白_base骨架事故案例（§1.2）、执行侧完整性闸门架构缺口（§1.3）、不是能力问题的复盘结论（§1.4）、提案A/D的实现记录",
  21 + "verified": true
  22 + },
  23 + {
  24 + "path": "system/agents/coder-methodology-trial/SKILL.md",
  25 + "used_for": "第四节可迁移训练方法论：清单A/清单B结构、D1信号词黑名单、D5三支判断机械动作",
  26 + "verified": true
  27 + },
  28 + {
  29 + "path": "system/agents/coder-methodology-trial/train/hunt/knowhow_v1.md",
  30 + "used_for": "第四节：coder训练的外部方法论调研结构与仓库内证据分析方式，作为可迁移方法论的参照",
  31 + "verified": true
  32 + },
  33 + {
  34 + "path": "system/agents/coder-methodology-trial/train/fde_report.md",
  35 + "used_for": "第四节：诚实标注训练局限的方法论（A类/B类结论区分），可迁移到本次训练的自省方式",
  36 + "verified": true
  37 + },
  38 + {
  39 + "path": "data/companies/e2e-demo/runs/run_b962ea87f58f/nodes/rn_956c699f1160/test.log",
  40 + "used_for": "第三节真实历史样本1：p-iyshuc apple风格官网，40/40 PASS，独立重跑+仓库标准工具交叉验证",
  41 + "verified": true,
  42 + "verification_method": "grep timeline.ndjson 确认 system_agent_id=unit-tester"
  43 + },
  44 + {
  45 + "path": "data/companies/e2e-demo/runs/run_b962ea87f58f/nodes/rn_84d4651597bc/test.log",
  46 + "used_for": "第三节真实历史样本2：p-iyshuc，infra_flake中断后重跑，mtime/diff核实实践，会话中断阶段核实技巧",
  47 + "verified": true,
  48 + "verification_method": "grep timeline.ndjson 确认 system_agent_id=unit-tester"
  49 + },
  50 + {
  51 + "path": "data/companies/e2e-demo/runs/run_fa4d7e2bec49/nodes/rn_fc9155c598ef/test.log",
  52 + "used_for": "第三节真实历史样本3：p-cgfdcr，四维度全PASS，动画真实性补测（scrollY时间序列采样）",
  53 + "verified": true,
  54 + "verification_method": "grep timeline.ndjson 确认 system_agent_id=unit-tester"
  55 + },
  56 + {
  57 + "path": "data/companies/e2e-demo/runs/run_c7d233619784/nodes/rn_9d48ea87f326/test.log",
  58 + "used_for": "第三节真实历史样本4：p-pyjha7，attempt-4，明确写明不采信coder自我汇报；sections_completeness维度用grep判定，暴露正则解析边界问题",
  59 + "verified": true,
  60 + "verification_method": "grep timeline.ndjson 确认 system_agent_id=unit-tester"
  61 + }
  62 + ],
  63 + "external_sources": [
  64 + {
  65 + "topic": "ATDD / 验收测试驱动开发",
  66 + "urls": [
  67 + "https://www.testlio.com/blog/what-is-acceptance-test-driven-development",
  68 + "https://www.geeksforgeeks.org/software-engineering/acceptance-test-driven-development-atdd-in-software-engineering/",
  69 + "https://blog.logrocket.com/product-management/acceptance-test-driven-development/",
  70 + "https://www.browserstack.com/guide/what-is-atdd"
  71 + ],
  72 + "verified": true,
  73 + "note": "多方独立来源交叉一致，核心主张明确（验收标准先行、可测量语言、协作定义）"
  74 + },
  75 + {
  76 + "topic": "测试证据留痕规范（test evidence / traceability）",
  77 + "urls": [
  78 + "https://testcollab.com/blog/building-a-test-evidence-strategy-that-scales",
  79 + "https://www.testrail.com/blog/test-coverage-traceability/",
  80 + "https://testsigma.com/blog/test-evidence/"
  81 + ],
  82 + "verified": true,
  83 + "note": "核心论点'没有记录，通过声明本身没有意义'与本仓库test.log设计理念一致"
  84 + },
  85 + {
  86 + "topic": "pytest skip/xfail 语义（工具/依赖不可用时的业界惯例）",
  87 + "urls": [
  88 + "https://docs.pytest.org/en/stable/how-to/skipping.html"
  89 + ],
  90 + "verified": true,
  91 + "note": "官方文档，权威来源。核心发现：pytest将依赖不可用归为skip，与本仓库unit-tester硬约束6的blocked语义相反——用于第五节(c)对照分析，不是照搬依据"
  92 + },
  93 + {
  94 + "topic": "工具不可用时的组织/流程层面诚实降级汇报方法论",
  95 + "urls": [],
  96 + "verified": false,
  97 + "note": "未核实。搜索结果多集中在系统可用性/性能监控语境的'降级'（degradation），与'测试工具本身不可用如何汇报'不是同一议题，未找到直接对应的高权威来源，未采纳为训练依据"
  98 + },
  99 + {
  100 + "topic": "单次编码任务内部代码分段粒度的增量交付方法论",
  101 + "urls": [],
  102 + "verified": false,
  103 + "note": "承接coder-methodology-trial knowhow_v1.md已有标注，本次未重新调研，仅引用其结论：搜到的是系统级迁移语境而非细粒度编码任务切分，证据强度弱"
  104 + }
  105 + ],
  106 + "not_found": [
  107 + {
  108 + "item": "unit-tester 真实判定 blocked（工具跑不起来）的历史样本",
  109 + "note": "全仓库搜索 data/companies/e2e-demo 下所有 test.log，只找到4份，均为PASS结果，未发现blocked案例，如实说明未找到，不编造"
  110 + },
  111 + {
  112 + "item": "unit-tester 真实发现acceptance fail并打回coder的历史样本",
  113 + "note": "同上，4份样本均为全PASS，未见fail/打回记录"
  114 + },
  115 + {
  116 + "item": "同一acceptance维度内部分子项有检测工具、部分没有的混合场景历史样本",
  117 + "note": "4份样本均落在'全部维度都有工具覆盖'的情况，此路径在仓库历史数据中无真实先例"
  118 + }
  119 + ]
  120 +}
system/agents/unit-tester-methodology-trial/user.md 0 → 100644
  View file @521e762
  1 +# 上层上下文
  2 +
  3 +## 我的上级
  4 +- 直接向用户汇报 (无上级 Agent)
  5 +
  6 +## 用户偏好
  7 +（待用户定义）