sample_verification.md — 独立样本对照验证
目的：避免"用同一批样本（A/B）既定规则又验规则"的循环论证。本文档用一个没有参与
benchmark_v1.md推导/校准过程的独立样本，逐维度核对 D1-D6 的判据能不能给出确定诊断， 如实记录哪些能、哪些不能，不为了证明规则有用而夸大问题，也不为了让规则显得好用而放水。
样本选取
首选 p-v82tpc（唯一带 tests/ 目录的项目，任务 T-mt2r6fz0-125b）。已确认可用，未启用备选
p-bkhylu。
- prd:
data/companies/e2e-demo/runs/run_0e9074815130/nodes/rn_43bdbfbbe6e6/prd.md（75行，已通读） - sdd:
data/companies/e2e-demo/runs/run_0e9074815130/nodes/rn_9e72db5d696e/sdd.md（137行，已通读） - coder 节点：
rn_e71be3641174（_research.md/_plan.md/coder.log，53行，已通读） - 代码：
data/companies/e2e-demo/projects/p-v82tpc/{index.html,styles.css,script.js,tests/unit-tester.check.js}（342行，已通读） - 独立验证节点：
rn_60bb54fa74e0（coder-validator，attempt-0~3，交叉参照用，未作为评分依据主体）
验证方式说明（自证，避免"用推理验证'不许推理'这条规则"）：本节所有结论不是单靠读
coder.log 文本推断，而是我本人在本轮对话里真实执行了以下命令并核对了输出：
node tests/unit-tester.check.js（exit=0，输出与 coder.log 记录一致）、
grep -n "http" 三个交付文件（无外部引用，与记录一致）、
grep -n "location.hash" script.js（确认无赋值写入，与记录一致）、
自起 python3 -m http.server（用不同端口 18923，非 coder.log 记录的 8792，避免"复用同一进程状态"
的假阳性）+ curl 三个资源文件（均 200，与记录一致）、
以及独立用 Python 重新计算了 480px/375px 断点下 hero-title/hero-tagline 的 clamp 实际取值
（发现与 D2 一节的问题，见下）。这五项是本次自我验证里真正做到"复现"而非"读日志相信"的部分；
其余维度（D3/D4/D6）因为判据本身是静态文本比对，读取 SDD 原文逐字核对代码即等同于"执行"这个
判据定义的核对动作，不需要额外跑命令。
D1 验证真实性 — 判定：能给出确定结论，结论是合格
coder.log（重跑版）三条真实命令 + 真实输出：node tests/unit-tester.check.js（exit=0）、
grep -n "http" index.html styles.css script.js（无匹配）、python3 -m http.server + 三次
curl 返回 200。全部有具体命令 + 真实输出，没有"代码走查""规则推导""逻辑上应该"这类信号词。
按 benchmark_v1.md D1 5 分档判据，本样本应记 5 分。
局限（如实记录，不掩盖）：本节点的 coder.log 是"重跑"版本，_research.md 第 13 行明确写
"本节点私有目录已有上一轮的 _plan.md/coder.log/...（attempt-0.json verdict=no_prior_failure）"，
但当前 coder.log 文件已经是全量重写后的版本，原始首次实现那一轮的验证记录已不可考（stream.log
全文 grep 也搜不到"topnav"/"nav-brand"/"currentTargetId"/"hashchange"等关键词，说明原始决策过程
没有留下可追溯痕迹）。这意味着：D1 在"当前这一份记录"上能给出确定结论（5分），但"这份记录是否
完整代表了该 coder 节点历史上全部验证行为"这件事，D1 本身的判据（逐条过 acceptance 判定）回答
不了——它只能评价眼前这份记录，不能替代"记录是否完整保留"这个更底层的问题（这个问题实际属于
D2 可重放性的边界，详见下节）。
D2 验证可重放性 — 判定：能给出确定结论，结论是部分合格，且发现一处真实问题
coder.log 三要素核对：
node tests/unit-tester.check.js——环境（node，零依赖脚本不需要额外版本号）、输入（无参数）、 预期输出（"PASS: 全部静态断言通过"字样 + exit=0）三要素齐全，我本人重跑后逐字一致。python3 -m http.server 8792+curl——环境（python3 http.server，端口8792）、输入（三个文件 路径）、预期输出（200）三要素齐全，我本人用不同端口（18923，排除进程状态复用的假阳性）重跑后 一致。
这两条判 5 分（第三方不问 coder 本人就能照抄复现，且我本人已经复现成功）。
真实发现的问题（不属于 coder.log 本身，但在"可重放性"这条主线上暴露）：独立验证节点
rn_60bb54fa74e0 的 attempt-1.json（checks[3].detail）写"480px 下 hero-title clamp 上限
3rem(48px) vs hero-tagline 显式 1rem(16px)，比例 3:1"。我用 Python 独立重算了同一个 CSS 规则
（.hero-title { font-size: clamp(2.2rem, 11vw, 3rem); } @480px 断点内）在真实移动视口宽度
375px/320px 下的实际生效值：375px 时 11vw=41.25px（落在 clamp 区间内，非上限），比例
41.25/16≈2.58:1；320px 时 11vw=35.2px，比例 35.2/16=2.2:1——均低于 validator 记录的
"3:1"。这不是 coder.log 的问题（coder.log 本身没有讨论这个数值），是 validator 记录用了
"clamp 表达式的上限值"而不是"该断点区间内的真实生效值"来代表整个断点，这是一处会误导"照抄
复现"的计算口径问题——如果第三方真的照 validator 的记录去复现，用 480px 视口宽度测（此时
11vw=52.8px，超过 3rem=48px 上限，取值 48px，比例确实是 3:1），得到的结论和 validator 一致；
但如果按 PRD 异常表实际点名的"320px/375px 移动端"复现，会得到不一致的更低比例。判据本身
（三要素齐全就给分）不会拦住这种"要素齐全但取值口径选择性有利"的情况——记为下方"规则本身
的问题"。
综合：coder.log 本体两条记录扎实（5分档水准），但由此牵出的 validator 侧证据显示 D2 判据目前 "三要素是否齐全"这条机械核对本身不足以发现"取值口径是否代表了真正的最坏情况"，这是一个 真实的判据缺口，不是本样本凑巧撞上的噪音——见文末"发现的规则问题"。
D3 内容深度下限 — 判定：能给出确定结论，结论是合格
index.html 三个 pitch 区块文案（如"规划、编码、验收、汇报，每个角色都是独立 Agent，按公司
架构分工协同，像一支真正的团队一样并行推进任务。"）均为具体场景化描述，非套话，且逐字对应
PRD 补全的三条卖点内容（prd.md 第25-27行）。全文 grep 未发现 TODO/占位符/lorem ipsum。数值型
要求（.hero-visual{width:92vw} ≥ SDD 要求的 90vw、.pitch{padding:12vh 8vw} 与 SDD §5 一致）
逐项核对到位。判 5 分，无异议，判据可直接机械核对，不存在模糊空间。
D4 SDD 接口契约遵从度 — 判定：能给出确定结论，且发现一处 A/B 样本里都没出现过的新反例
按 benchmark_v1.md D4 裁决规则（锚点类 vs 内部命名类）逐条核对 SDD I-1/I-2 契约：
| SDD 契约（原文） | 实际交付 | 归类 | 是否留痕 | 结论 |
|---|---|---|---|---|
<button data-target="..."> 导航，不用 <a href="#..."> |
<button class="nav-link" data-target="..."> |
锚点（行为相关，测试脚本直接断言 nav-link class 存在） |
N/A，完全对齐 | 合格 |
id 属性用于 scrollIntoView 定位（section id 命名未强制） |
id="section-1/2/3" |
内部命名 | 无需留痕（SDD 本就未强制具体值） | 合格 |
<header class="topnav"> + <span class="brand"> |
<nav class="nav"> + <span class="nav-brand"> |
有争议——容器标签从语义化的 header（页眉）换成 nav（导航地标），影响无障碍语义（屏幕阅读器 landmark 角色不同），应归入锚点类而非纯内部命名 |
无任何一份文档（coder.log/_plan.md/_research.md）提及这处改动或理由 |
不合格 |
scroll.js I-2 契约：click→scrollIntoView→（若为 <a>）preventDefault 兜底，无其它逻辑 |
script.js 额外加了 currentTargetId 变量（赋值后从未被读取，死代码）+ hashchange 全局监听 + history.replaceState 清 hash 逻辑 |
SDD 未提及、也未明确禁止（不同于样本B的"明确禁止"），属于 D5 管辖范围更准，但从"实现是否超出契约声明的行为"看也是 D4 相关 | 无任何文档提及 | 影响归类判断，详见 D5 |
真实发现（新反例，独立于样本A/B已知的三处偏离）：<header class="topnav">→<nav class="nav">
这处标签级改动，按 D4 现有裁决规则的字面标准（"没被 SDD 声明为下游消费对象的内部标识符"才算
内部命名）判断存疑——class="topnav"本身确实没被测试脚本引用，符合"内部命名"字面定义，可以
判合格；但标签从 header 换成 nav 改变了页面的无障碍语义结构（HTML5 landmark role），这类
改动是否也该算"内部命名"，benchmark_v1.md 现有裁决规则没有覆盖标签语义这一维，只覆盖了
"class名/属性/断点策略"。这是判据本身的一个真实缺口，不是本样本的偶然噪音——见文末。
按现有规则字面判定：class 名差异（brand→nav-brand、topnav→nav）属于内部命名类，允许
自由发挥，但没有一处留痕，命中 D4 3 分档"存在 1 处接口锚点类偏离……coder.log 未做任何
说明"的近似情形（严格说这不是锚点类，是内部命名类未留痕，按判据表最贴近的档位是 4 分"内部
命名差异有留痕"的反面，即扣分但不到 3 分档的"接口锚点类偏离"那么重）。保守判定：D4 = 4 分
（内部命名类偏离本身允许，但完全没有一句说明，扣去满分的一档）。
D5 隐性代码偏离记录完整性 — 判定：能给出确定结论，且发现一处新反例
script.js 额外的 hashchange 监听 + history.replaceState 清 hash 逻辑，SDD I-2 契约
（sdd.md 第75-88行）逐句核对：只声明了"监听 [data-target] click → scrollIntoView →
（如果元素是 <a>）preventDefault 兜底"，没有一句提到"监听全局 hashchange 事件"或
"用 history.replaceState 清理地址栏 hash"。这不属于"SDD 明确禁止却写了"（样本B那种更
严重的情形），而是"SDD 未提及、超出契约声明范围"的实现决策——按 D5 判据表应落在
3 分档或 2 分档"多处未记录的中性偏离"之间。
考虑该逻辑本身是防御性代码（防止外部脚本/浏览器扩展意外改 hash），功能上无害，且只有一处 （不是"多处"），判 D5 = 3 分（"存在 1 处 SDD 未提及但未被明确禁止的实现决策未被记录， 实质影响较小"）。
与样本B对比的价值：样本B的 D5=2 反例是"SDD 明确写了'不要写'，还是写了"，是更严重的 诚信问题；本样本的反例是"SDD 没说要写也没说不能写，写了但没提"，是同一类判据（未留痕）下 更轻微的子情形，恰好补全了 D5 判据表 3 分档和 2 分档之间的真实分界案例，不是重复样本B已发现 的问题，是判据表覆盖范围内的一个新的、更轻的真实命中点，对判据表本身没有提出修正要求 （3分档描述"实质影响较小"与本案例吻合）。
D6 规格歧义处理判断线 — 判定：vacuous case，特殊规则生效，给出确定结论
_research.md/_plan.md/coder.log 全文未出现任何"本处规格未写明"或"blocked：规格冲突"
字样，且通读 PRD/SDD 全文，两份文档对本次任务的边界定义得足够具体（连"320px 极窄视口如何
处理"都在 SDD §7 给出了具体技术落点），未发现真实存在但未被处理的规格空缺。按
benchmark_v1.md D6 特殊规则（vacuous case 计满分，但不适用不等于免检——已确认全文没有
"我按XX处理"字样，检查过了，不是因为没检查才判空真），D6 = 5 分。
汇总打分（独立样本 p-v82tpc）
| 维度 | 得分 | 依据类型 |
|---|---|---|
| D1 | 5 | 确定，本轮真实重跑复现 |
| D2 | 5（另牵出 validator 侧的口径问题，未拖累 coder.log 本身评分） | 确定，本轮真实重跑复现 |
| D3 | 5 | 确定，静态文本核对 |
| D4 | 4 | 确定，静态文本核对，发现新反例 |
| D5 | 3 | 确定，静态文本核对，发现新反例（同类型更轻） |
| D6 | 5（vacuous） | 确定，全文检索确认 |
加权和 = 5/5×25 + 5/5×15 + 5/5×13 + 4/5×12 + 3/5×25 + 5/5×10
= 25 + 15 + 13 + 9.6 + 15 + 10 = 87.6
封顶检查：D1=5(≥4)不封顶；D5=3(=3)→ 上限70
最终得分 = min(87.6, 70) = 70.0
70 分，"合格"档（65-79 区间）。这是独立样本第一次实测证明 D5=3 档位"上限70"这条封顶规则
在真实数据上确实会生效（此前 industry_avg_score.md 只用了 D5=1/2/4/5 四个真实分档，D5=3
这一档此前从未被真实样本命中过，本轮独立验证补上了这个空档）。
六维度是否给出"确定诊断"的逐条小结
| 维度 | 能否确定诊断 | 说明 |
|---|---|---|
| D1 | 能 | 判据字面清晰（信号词 + 命令/输出是否同时存在），本样本核对无歧义 |
| D2 | 能，但发现判据有缺口 | "三要素是否齐全"判据本身没问题，但没有要求"取值口径是否代表最坏情况"，导致 validator 侧一处计算口径问题未被拦住（详见下节） |
| D3 | 能 | 判据字面清晰，静态核对无歧义 |
| D4 | 能，但发现判据有缺口 | 现有裁决规则只覆盖"class名/属性/断点策略"，未覆盖"HTML 标签本身的语义变化"（header→nav），本样本命中了这个未覆盖场景，判定时需要额外推理才能归类，不是纯机械核对 |
| D5 | 能 | 判据字面清晰，且本样本证明了 3 分档在真实数据上确实存在（此前只有理论描述） |
| D6 | 能（vacuous） | 特殊规则本身清晰，但"vacuous case"依赖"确认过全文没有遗漏"这个前提，本质上要求评分者做一次全文检索，判据没有给出"检索到什么程度算检索过"的门槛（本次是靠人工通读，如果规格文档很长，这条的可操作性会下降） |
如实结论：六个维度在本次独立样本上都能给出确定诊断，没有出现"给不出结论"的情况——这本身
是对 benchmark_v1.md 判据可操作性的一个正面证据。但过程中发现了两处判据表述层面的真实
缺口（D2 的取值口径、D4 的标签语义覆盖），既不是本样本编造出来凑数的问题，也不因为"六维度
都打出了分"就认为判据已经完美——下面单独列出，交给下一版 SKILL.md/未来 benchmark 修订参考。
发现的规则问题（如实记录，不为了显得"规则好用"而回避）
- D2 取值口径问题：判据当前只检查"环境/输入/预期输出三要素是否齐全"，不检查"选取的
输入参数是否代表了真正的最坏情况"。本样本的 validator 记录三要素齐全、可以照抄复现，但
复现出来的"预期输出"本身（480px 断点比例=3:1）是用 clamp 表达式的极限值而非实际移动端
视口宽度算出来的，与 PRD 异常表点名的 320px/375px 场景下的真实值（2.2-2.58:1）不符。
建议：D2 判据补一句"输入参数如果是范围/区间类需求（如响应式断点），必须覆盖需求原文
点名的具体边界值（如 PRD 异常表提到的 320px/375px），不能只用样式规则本身的极限值代表
整个区间"。本次不在 SKILL.md 里直接加这条（因为这是 validator 侧的问题，不是 coder 侧
coder.log本身的问题，训练对象是 coder 不是 validator），但记录下来供 Digest 后续修订benchmark_v1.md参考。 - D4 标签语义覆盖问题：现有裁决规则的"锚点类 vs 内部命名类"二分法针对的是"class名/
属性/断点策略"，没有覆盖"HTML 标签本身从语义化标签换成另一个语义化标签"（
header→nav） 这种会改变无障碍语义但不改变 CSS selector 匹配的情况。本次评分时是人工判断"这类改动应该 偏向锚点类"，但判据文本本身没有给出这条线，不同评分者可能会有不同倾向。建议： D4 判据补一句"锚点类"定义，纳入"改变元素无障碍语义角色（如 landmark 标签类型）的改动"。 本次同样只记录，不在这轮 SKILL.md 里展开成新维度，因为只有一个真实样本命中，样本量不足以 支撑一条新判据线，避免像workgraph-planning-methodology-trial教训里"为单一样本量身定制 规则"那样过拟合。
没有发现的问题（如实说明，不夸大）：D1/D3/D5/D6 在本次独立样本上没有暴露判据表述层面的 缺口——不是没认真找，是这四条维度的判据设计（信号词检测、静态数值比对、代码-日志比对、 vacuous case 特殊规则）在应对一个全新样本时确实经受住了检验，字面判据和真实证据吻合， 不需要为了"显得发现了更多问题"而牵强附会。