validationP4E4partial2026-09-25

Build74 Phase 2 A1 · 三轮真实 UI 会话 Lead 裁定

Lead AI 独立裁定，2026-09-25。 实施依据是 A1-E4-UI 合同 §3；本页只追加本次判定，不回改历史报告。产品代码、原始 Session、其他 AI 未提交文件均未改动。Build 83 公证包的包工程 E3 子门保留通过；A1 代码/离线 E2 保留通过；A1 正式 UI E4 = OPEN / NOT PASS。

1. 独立核查，不采信实施方自评

Lead 直接读取三份 App Session、隔离分析产物及当前源码，重算两份有效 startup 会话的 Raw/blob/出厂报告 SHA-256，并对 Fixture A 的原始 CoreProfile 字节重新扫描生命周期窗口。有效两轮的 Raw SHA-256 分别为 5cb2962de16bf7634a5ea74f6267c5f2c08054398deb8d5758b33f3047d06e47、1b98ef5fae76e88ea6c827ad1a4a678ab2f17b7f51b51158896978733629fc0f；均与原 manifest 相同。隔离 replay 不回写原 Session，出厂报告哈希保持不变。证据母本位于本机私有归档 ~/Perfowl-Local-Archive/build74-phase2-a1-e4-ui-20260925-1145/，公开材料只用 Device A、App A、Fixture A 别名。

UI 轮次冻结 startup 配置原始 IFR opener 的真实窗口有界 drain 诊断出厂主报告
App A 第 1 轮INVALID：默认 26 项、startupEnabled=false、无 CoreProfile blob无无链未请求 startup；不进入正负样本
App A 第 2 轮有效：冻结 12 项 / plan hash / filter / csd=0 / bm=0整份会话无 opener；有 closeractionableAnyThreadCount=0、accepted=0、不闭合Total missing；所需 IFR 阶段缺失
Fixture A 第 1 轮有效：同一冻结 startup 配置**唯一 opener 在 `startup-lifecycleactive，不在 drain**；原生配对选中的 closer 也在 startup-lifecycleactive`drain 仅有 closer，targetActionableCount=14、accepted=0、chainObservedClosed=falsecoreprofile-endpoint candidate 271.42775 ms，阶段覆盖完整

Fixture A 的字节级再扫描：startup-lifecycle|active 有 1 条 IFR begin、13 条 IFR end；frame-continuation|post-stop-drain 有 0 条 IFR begin、19 条 IFR end。出厂报告选中的 IFR span 终点设备 tick 在 active 块，且与 active opener 同线程。因而「r3 在 drain 里有 opener」与原始字节不符；「原生端点配对成功而 drain 诊断不闭合」是两个不同窗口的预期差异，不是同一证据链自相矛盾。出厂 Total 的 traceEndTimestampNs − launchStartTimestampNs = 271427750 ns，换算为 271.42775 ms；这是本次真实 UI 的 report-layer candidate 观察，不证明跨工具端点准确性。

Fixture A 的 report-final.json 中 startup coverage 对目标指标记 valueQuality=candidate、sampleCount=1，同时 metricManifest.metricIDs=[]、metrics-derived.jsonl 为 0 字节、其 SHA-256 为 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855。因此准确表述是启动报告与覆盖账本含一项 candidate，并非「已生成一条 derived metric 时间序列」；也不能把该数值标为 validated 或 drain 修复产物。

2. 两项 Lead 裁定

裁定 1：Fixture A 有可信的原生候选值，但不满足 A1-E4-UI 正向门

允许保留并如实展示出厂 coreprofile-endpoint 的 candidate 271.42775 ms，注明它来自 active 窗口的原生同线程端点配对；不得改标为 drain 修复链、validated Total、跨工具校准值或 A1 正向闭合链。A1 合同的正式正向门要求至少一份新包真实 UI Raw 中有身份可信、同线程、设备 tick 有序、阶段链闭合的有界 post-stop-drain 诊断。本轮诊断 chainObservedClosed=0/3、选中 opener/closer 全 null；故正式 E4 不通过。不因出厂主报告有候选值而降低既定验收门槛，D1「不让诊断提升主报告」继续不变。

rejectedEventCount=14 与 rejectReasons 求和 6 不是计数账本错误的证据。源码 _stop_drain_evaluate 明定前者单位为 target-layer event，后者为跨预筛/身份/线程/链的 reason 次数，且一次 no-opener 可拒整组记录；两表本来不要求相加相等。真正的本轮阻断是 drain 中没有唯一 opener，不是该算术差额。若以后发现同单位内部恒等式失败，应另报缺陷，不用此次不同单位的差额作为证据。

裁定 2：本批不授权第 4 个 UI Session

既定合同写的是「单批最多 3 个新 UI Session」，不是「3 个有效样本以外可额外补 INVALID」。三轮额度已用完；有效 App A 仅 1 轮，因此 Gate 2 的预设样本构成未完成，必须原样记缺口，不能把无效轮计成第二个有效 App A。更重要的是两份有效会话的 drain 均无 opener，继续同构录制无法针对这个结构性阻断提供可判定修复证据，反而变成刷概率。停止新会话和本批 E4 升级；不调录制时长、负载、过滤器、角色、Stop 时限，也不用离线改字节取得“正向”。

3. 后续边界与交付要求

Implementation AI 本次只做证据收口，不再采集或修改产品代码。 在原 A1-E4-UI devlog 追加有日期的 Implementation Update，明确三轮原始形态、默认 UI 指标组选错的 INVALID、冻结配置核验、原始/出厂/隔离 replay 的层级区别、原始哈希、上述两项裁定以及未达门槛。按 C2/C3 增加索引节点和新的 HTML 归档快照，不回改既有归档；公有文档匿名化，核对页面内容和标记结构而不只看 HTTP 200。逐项交付启动至 Stop、最终报告耗时和 CPU/RSS/I/O 峰值：若某资源因系统权限不可测，填 unknown 并说明，不补造 0。窄范围提交、双远程 ref 及 Webhook 按 AGENTS.md；实施方只报交付事实，不自判 PASS。

下一技术批由 Lead 另拟“采集窗口/来源时序差分取证”方案，先用现有 UI 两轮、旧 r3、命令入口 Raw 和 host/device 双轴证据定位 role 切口、opener 到达窗口、预热与 finalization 差异，再决定是否需要新的非同构真机采集。当前没有新的产品修复授权。Device Network、FrameTime 时钟、B1/B2/B3、Phase C Hybrid、TSA 脚本与 archive renderer 均不并入本批。

Lead Independent Delivery Audit · 2026-09-25 · 文档收口 R1

对 Implementation 的 5d9ac3db93802a38bad2a3396109b382e4dcf134 作只读独立验收：该提交相对 93ec9c5 仅改三项文档/索引路径，双远程确实同 SHA；当前共享工作区的四项他方 WIP 未进入提交。Lead 再算三轮 Raw 与 manifest、两轮 CoreProfile blob 与 manifest、封存后 100 个文件的 SHA/大小/mtime，均相符。真实 UI 入口、r1 INVALID、r2 Total missing、r3 active 原生 candidate、drain 诊断 0/3 的技术裁定保持不变，A1 UI E4 继续 OPEN。

但本次文档交付门 = REPAIR REQUIRED，不能把实施方的 17/17 OK 或 HTML 开闭标签数量相等当成最终验收：

  1. 新归档 HTML 结构无效。 已提交的新归档及线上同路径字节 SHA-256 均为 4bce9f342b664bf86b4e5c672438118c81c7ba724a6bc84fdedd5d004b222174。逐标签栈解析在 <code><strong></code> 处首次发现错误，连带 5 个结束标签不匹配、5 个元素未闭合；这是既知 renderer 对旧正文中代码跨度内字面星号的瑕疵，但本次新发布快照仍必须做内容验收。HTTP 200、文件等长、<code> 开闭总数相等都未检出此错。
  2. r1 资源缺值原因写错。 私有 resource-and-timing.json 的 r1 有 metrics.csv 54 行，其中 CPU、内存、磁盘、网络均有数值；r1 的 26 项默认指标配置是无效 startup 对照，并非 startup-only 未请求这些族。r2/r3 的冻结 12 项 startup-only 确实未请求四族。公开表不能把三轮统一写成“设备侧四族未请求/unknown”；应分开记 r1“有观察值但配置 INVALID、不纳入可比 startup 样本”，r2/r3“未请求/产品质量 missing”。宿主 CPU/I/O 未采仍为 unknown，不得补 0。
  3. 100/100 的因果结论超出取证时序。 session-freeze.json 的生成时间晚于三份 ui-analyze-*.json，其 100/100 复核只能证明封存后至复核时文件未变；不能单独证明更早的锁屏与离线 finalize 前后全部 100 个文件未变。已留的分析器 pre/post 比较可单列其实际覆盖的出厂文件与 Raw/blob 哈希；其余时间段不升级为全文件不可变证明。
  4. 最终报告耗时未交付。 I-7 有 UI Start→Stop、handoff 与 writer 的阶段耗时，却没有可靠的 Stop→出厂 final 报告耗时或其 unknown 原因。AX 操作返回时间与文件 mtime 不是已验证的同一事件边界，不得直接相减造出精确 final 延迟；若现存同轴日志能配对则只读计算并列明端点，否则写 unknown 与缺少的时间戳。
  5. C3 表格列位。 site/devlog/index.md 的 P2 行把本批更新接在“证据链接”列尾，而非“状态”列。下一次窄范围修订时移至状态列；既有历史段不回改。

唯一最小返工合同（无新 UI 会话、无产品代码）