# 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 契约（原文） | 实际交付 | 归类 | 是否留痕 | 结论 | |---|---|---|---|---| | `