Build 74 Phase 2 · Lead 裁定与 Stop-drain 诊断实施方案

> Lead AI 编写；等待 Project Owner 明确批准。 本文是本批唯一实施依据，取代旧方案的准入、结果、测试与任务 B 实施条款；旧方案及其归档保留为历史提交，不回改历史读数。本文完成的是方案与静态/原始字节复核（E1，引用历史真机原始 Session），不是新包 E4 验收。实施记录须在本文按日期增量追加，不能由 Implementation AI 自判 PASS。

0. 基线、证据与不变量

已证、未证与纠错

1. 已证（源码＋原始字节）：四轮冻结 UI 配置相同，Total 均 missing；S2/r1/r2 交付 CoreProfile 原始字节没有目标 IFR opener；r3 有目标线程的 1 条 code=12 opener、2 条 IFR closer，处于 frame-continuation / post-stop-drain，被冻结保留谓词排除。仅在离线副本翻转 role，可令 r3 配对、S2 仍 missing；其数值是反事实，不得作为真实 Total。
2. 已证（清点脚本的准确分母）：私有归档 scripts/analyze_drain_admission_delta.py 先过滤生命周期命名空间、_lifecycle_actions() 非空，随后以 _thread_pids[tid] == targetPID 过滤。其 newlyAdmissibleInFrameContinuationChunks 的 S2/r1/r2/r3 为 0/0/0/3，实际是“目标归因 actionable 清点”，不是仅按 role/phase/namespace 的预筛，更不是最终准入。任意线程 actionable 对照 S2=9、r3=31。候选数、身份通过数、闭合链记录数必须分列，不得再共用“准入增量”。
3. 已证（源码）：现有 consume() 在 target_generation=None 时不拒绝；_records 无界、_reset_semantics() 被 _rebuild_semantics() 调用；report(source_raw_sha256=…) 本身不读取 Raw，真正的重放由 derive_launch_trace_session() 创建解码器并逐事件 consume()。现有两遍 _thread_pids 是全局归因，不证明 TID 从未被别的 PID 复用。

只读容量 census：按 raw-events.jsonl 中 binary chunk 的偏移顺序重组成 RAW v2 流，四轮 trace header thread 数依次为 2828/2731/2248/2288，三类映射记录去重 tid 数依次为 563/505/573/721；把两集合简单相加作保守上估为 3391/3236/2821/3009，均低于拟设保护阈值 8192。r3 诊断候选 tid 的归因见证只有一个 PID 值且等于目标 PID。该上估只证明这四个历史样本可容纳，不是未来上界；不得直接把含非 binary 块的存储文件当作连续 kd_buf 流扫描。

1. 未证：设备丢失 marker 的 arg1 含义、TID 重用在四轮之外的分布、drain 第二条 closer 的真实语义、设备 tick 与主机 stop 时刻同轴关系、T2 双时间轴 4.38 倍跨度的原因、与 Apple Instruments 同事件端点的一致性。sourceQuality.lossFree 只覆盖主机活线队列丢失；设备丢失 marker 是丢失片段/标记，不是被丢事件条数。
2. 纠错：coreProfileRestartCount=0 不等于 reconnectGeneration=0；sourceEpoch 可合法不为 1，必须与本 Session 的 launch/source 基线比较；“drain 收到”不等于“设备事件发生在 tap 停止之后”；dataCompleteness=complete 是产物封闭，不代表请求指标均有样本。

四轮原始事件外层的 (targetGeneration, sourceEpoch, reconnectGeneration, sourceID) 均只有一个组合，且与各自 launch.requested.raw 一致；这是历史样本的一致性事实，不是写死其具体数值的依据。

1. 架构决定（ADR-P2-01）

决定状态：方案已定，实施待 Owner 批准。

D1：主报告与 UI 的硬边界

本批 totalDurationMs 不发布；totalQuality、totalSource、totalRepairReason、status、reason、phaseResults、requiredMissingPhases、phaseCoverageComplete、spanCount、unmatchedBeginCount、_open、_spans、_completed、_initial_frame_end_* 与冻结版逐字段相同。活线 UI 仍显示 partial/missing；最终报告可比活线多一个诊断块，但不能据此出现启动总时长或“阶段已覆盖”的展示。诊断块不得含 *Total*、*Repair*、diagnosticEndpointMs、launch→closer 毫秒值或任一可直接被 UI 当作 Total 的标量。未来开放 Total 是独立决策批次，至少需要同会话同事件端点身份、设备/主机桥与外部参照的可比证据、来源与质量标签、Swift 展示来源位、新包 E4 正负形态。

D2：时间与容量

不使用 launch_start+15s、max(startup chunk tick)、主机 stop 时间或 4 秒 drain 等待预算作设备域准入上/下界。唯一时间判定是同一时基下 closer.machTicks > opener.machTicks >= openSceneBegin.machTicks；其中严格 > 是本诊断新保守门，不是冻结 _pair_markers 的 < 比较的逐字复用。缺 timebase、非正差、tick 乱序无法重建或跨 epoch，均不给闭合诊断。

容量先按第 3 节定义的精确候选层清点四轮与合成高压，512 仅作为显式安全上限，不声称覆盖所有真实会话。超限选 A：整批诊断失效；保留 overflow/计数/原因，不保留前缀形成的 opener、closer 或数值。主机时间窗限制采集耗时，不证明条数上界。

D3：显示指标拆批与依赖

本批只做 B0 只读取证，不接线指标。B0 先以 T2 原始 1716 条帧复算主机接收轴与设备 presentation 轴、stale/host gap/refreshMultiple 分布，并核对 graphics.raw 中已有的 ios.foreground.fps 路径；仅能得到双轴差异，不能擅称时钟成因。B1（DisplayPerformanceProjector 是否为四项的唯一所有者）待 B0 与重复出数检查后另批裁定并实施；B2（显示指标具名 missing reason）须与 Device Network 的独立全局缺值语义批次对齐后另批；B3（请求指标覆盖摘要）在 B1/B2 契约稳定后另批。dataCompleteness 不改义；FrameTime 时钟取证可独立延伸，但未解决前不得提升四项质量等级。

2. A1 诊断实现契约（Owner 批准后由 Implementation AI 执行）

2.1 入口与写面

1. 仅最终 derive_launch_trace_session() 为解码器显式启用 stop_drain_diagnostic=True，实时构造保持默认关闭。最终重放将 RawEvent 外层 target_generation/source_epoch/reconnect_generation/source_id/sequence 作为独立可选参数传给 consume()；不能仅从 payload 默认值推断或硬编码 epoch 1。校验后的 manifest rawSHA256 绑定诊断来源。
2. 在现有 kd_buf 单次扫描中，独立于 retain_record 抽取 binary ∧ role=frame-continuation ∧ phase=post-stop-drain ∧ _lifecycle_actions(record)≠[] 的记录；先记 actionableAnyThreadCount，后经身份门得到 targetActionableCount，最后链门得 acceptedEventCount。候选只存固定宽度 tuple：tick、arrival sequence、tid、debugID、必要的 args、Raw sequence、chunk/record offset；不得复制 chunk 字节或向 _records、_markers 注入。最小扫描和全量扫描的 action code 覆盖必须等价；尤其 code=12 要按 _lifecycle_actions 可接受的 func 形态检查，不能只在真机分类中写死 0x2B870030。如需补扫描 ID，只在诊断 opt-in 的局部集合补齐，不改默认活线 LIVE_LIFECYCLE_DEBUG_IDS。
3. 主报告语义重建与诊断账本分离：_reset_semantics() 只清派生语义/可重算诊断结果，不清会话原始候选账本；target rebind、原始来源不一致或溢出使诊断账本失效。_semantic_dirty 仍只由原有 _records 改变；诊断计算在最终 report() 的 _ensure_semantics() 之后从只读快照进行。多次 report 幂等；活线 _emitted_report 早退路径不新增诊断。
4. 不触碰 realtime.py 的 role 决策、CoreProfile 采集与 stop/drain 时序，不改变 _pair_markers()、_recover_total_endpoint()、_lifecycle_anchor_ticks()。若最终重放现有路径无法取得某项外层身份，不猜值，输出 identity-unknown 诊断拒绝原因。不得为补诊断改变主报告的 target 归因。

2.2 四道准入门与拒绝优先级

拒绝优先级：Raw/来源完整性 → 会话身份 → 容量 → 线程归属 → 链闭合。统计每层原始数与拒绝原因，避免“0”掩盖缺值。r3 的预期是目标 actionable 3、链接受事件 2、多余 closer 1；S2/r1/r2 的目标 actionable 为 0，不是承诺未来所有负向都为 0。第二条 closer 与第一条的正差为 rejectedTick − selectedTick = 296418，仅作为离线测试断言，不输出 selectedMinusRejected 反号字段。

2.3 有界内存、超限和完成性

• 诊断候选上限 512；线程归属账本唯一 tid 上限 8192。这是保护阈值而非真实数据上界证明。超任一上限立即标记 truncated=true、diagnosticUsable=false，之后只保留 O(1) 饱和/精确计数，不保留前缀链作闭合结论；不影响既有主报告。对真实四轮先做只读分层 census；若 8192 不覆盖基线，须回 Lead 重新裁定上限，Implementation AI 不得自行调大。
• 内存复杂度 O(min(C,512)+min(M,8192))，C 为 actionable drain 记录、M 为映射 tid 数；单次既有 Raw 扫描、每条 O(1) 分类，诊断末尾最多排序 512 条，O(512 log 512)；无额外全 Raw 扫描、无新进程/主机轮询、无额外网络调用。原始 chunk 字节不复制。
• handoffDrainStatus=timeout、设备丢失 marker 均作为完整性警示，不得推断未见记录一定不存在。若观察到完整两事件链，可标 chainObservedClosed=true 同时 captureComplete=false；若只见 opener 或 closer，则 chainObservedClosed=false。两者无论如何都不提升 Total/phase 主字段。

2.4 诊断块精确合同

最终 launch-trace-report.json 可仅增 stopDrainLifecycleDiagnostics，示意字段：algorithmVersion="stop-drain-lifecycle-diagnostic.v1"、sourceRawSHA256、actionableAnyThreadCount、targetActionableCount、acceptedEventCount、rejectedEventCount、rejectReasons、diagnosticUsable、chainObservedClosed、truncated、captureComplete、drainStatus、selectedOpenerMachTicks、selectedCloserMachTicks、对应的 selected*RawSequence/RecordOffset、sourceEpoch、reconnectGeneration、targetGeneration、deviceLostEventMarkerCount、deviceLostArgSemanticsVerified=false。缺值为 null 而非 0；拒绝或超限时所有 selected 字段必须为 null。仅保留可复核的原始 tick 与归因/来源字段，不派生任何 launch→closer ms 或 IFR duration 数值。公开站点/归档不得写真实 PID、tid、sourceID 或 Session UUID；本地诊断可保留原始标识供审计。

四轮预期主报告逐字段等于冻结版（剔除本批新增诊断块和不可比的生成时间字段），r3 诊断链可闭合、S2/r1/r2 仍无闭合链；如果实际回放不符，应记录 FAIL 与原始差异，不能改预期凑数。

3. B0 只读取证合同（可与方案收口同轮执行，非产品开发）

1. 从 T2 的已验证 Raw 读取 display.frame-lifetime.raw，记录 Session 别名、Raw SHA-256、事件数、sourceID/epoch/reconnect、算法版本与首末 sequence。原始 Session 和报告只读；输出在私有分析目录，公开文档只放匿名汇总。
2. 在各自时间域独立计算 hostSpanMs=(max(hostReceiveMonotonicNs)−min(...))/10^6、presentationSpanMs=(max(presentationTimestampNs)−min(...))/10^6；比值仅是观察到的跨度比，不作为时钟换算系数。逐事件/相邻帧统计 host gap、presentation gap、负/零/缺 timestamp、stale host gap（按冻结 FRESHNESS_STALE_HOST_GAP_NS）、refreshMultiple。不得拿主机 Stop 时刻为设备 tick 定上下界。
3. 分别追踪 DisplayPerformanceProjector 的五项输入、活线 camelCase 输出、_consume_metric_frame() 的 metric-ID 样本入口，以及 metric_engine.py 中 graphics.raw → ios.foreground.fps 现有路径；输出所有者冲突矩阵与五项 coverage 对账。metrics-derived.jsonl=0 不等于“所有 metric_engine 路径不存在”；T2 的 1686 个 FrameTime 样本不证明其余四项已具备发布质量。
4. B0 结论只允许写“观察到的两轴差异、哪些路径未接线、哪些需要同事件时钟见证”。若缺时钟桥或同事件 ID，原因标 unknown；不得把 4.38 倍归因于固定设备时钟比例，也不得扩 _apply_frame_coverage.metric_map 直接出数。

4. Implementation AI 文件边界与执行顺序

须先得到 Owner 对本文的明确批准。 执行时按以下顺序，不跨批：

1. 先对私有副本做四轮分层 census 和 B0；固定原始 SHA、候选定义、三扫描模式；若 r3 不能维持 G1–G4 或 8192 上限已不足，停止产品实现并回 Lead。
2. A1 仅可改 MacApp/Sidecar/perfowl_collector_core/launch_trace.py 的最终重放参数、诊断账本、末尾只读投影，以及与之匹配的 Python 测试/fixture；需要新增独立小模块时先在 Implementation Update 说明最小原因，不可顺手改 realtime.py、online_report.py、metric_engine.py、Swift/UI 或站点指标口径。拒绝把候选注入主 _records。
3. 公式/字段先按本文冻结，随后写 site/devlog/ 同文档日期化 Implementation Update，记实际文件、与本文偏差、验证命令、性能对比、E2/E4 边界与遗留项。未通过门禁写 partial/blocked，不得自宣阶段 PASS。
4. B1/B2/B3、Device Network、Phase C 和正式 Total 发布均不在本次可实施范围。任何“为测试方便”改变 CLI 默认 kdf2/csd、UI 录制配置、drain 时限、role 或源过滤都需另获 Lead/Owner 批准。

5. 必须交付的验证矩阵（不允许预设真机事件形态）

真机 E4：只使用冻结 Build74 同形态 App UI 入口作为对照，核对 effectiveCoreProfileConfig 的四个生命周期过滤类别、csd=0、bm=0；CLI 默认 kdf2=[0xFFFFFFFF]/csd=128 形态一律 INVALID。新包每轮先按原始字节分类（完整链、只有 opener、只有 closer、无 lifecycle、身份缺值/冲突、溢出/timeout），再套相应判据；不得要求每轮都重现 r3 三条事件，也不得把没有正向链的轮次宣称功能已获 E4。至少一个新包真实正向闭合链、真实负向形态、原始哈希/报告一致性和活线/最终主字段对照齐备，Lead 才可考虑 A1 E4 PASS。所有会话的 Total 仍按原生契约，不因诊断提升。

6. 效率与交付门禁

• 基准采用同一批已校验 Raw，冻结版与修改版交错各至少 3 轮，报告 finalizer wall、CPU、峰值 RSS、读 I/O、首个 live snapshot 延迟、长会话最坏值；诊断开关默认关闭的 live 链路不得新增扫描/等待。A1 finalizer 相对基线目标：wall 与 CPU 增量各 ≤5% 或 ≤100 ms（取较宽者），增量 RSS ≤8 MiB；超过即回 Lead，不自行放宽。最坏合成容量边界必须稳定完成且不造成无界分配。
• 跑匹配 Python 专项、全量 Sidecar、Swift 现有报告/工作台回归、知识契约门禁与 site/npm run build（0 错误/0 死链），并独立审计 git diff 只含本批文件。对共享工作区只窄范围暂存；受保护未跟踪文件保持不变。
• 若 Owner 批准 A1 开发，完成后按 AGENTS.md 的签名、公证/staple、独立安装、SHA-256、双远程、Webhook 门禁交付；任一缺口如实记 partial，不得把 E2、旧 Build74 包或 HTTP 200 当新包 E4。

7. 尚未解开的事实与下一决定

当前不能证明普通帧不会在更晚设备窗口复用相同 terminal、不能证明 T2 双轴差异的物理原因、不能从另一场 Apple trace 推定 Perfowl 同场端点一致，也不能以 deviceLostEventMarkerCount 推出具体丢失条数。A1 是诚实诊断而非启动成功率修复；若 Owner 的目标是立即发布更多 Total，必须另起证据批次，不得把本方案静默扩权。B0 完成后由 Lead 再定 B1 的所有者；Network 与 Phase C 均保持独立门禁。

当前状态：方案完成，Owner 批准 PENDING；产品实现未开始；Build74 正式 E4 验收未完成。

8. Lead Execution Gate Update（2026-09-24，Project Owner 工作流程调整）

Project Owner 已明确取消逐批审批：Lead AI 完成方案 → 给 Owner 可转发的执行指令 → Implementation AI 执行并交付 → Owner 将交付内容转给 Lead AI → Lead AI 独立验收。因此本文此前所有“等待 Owner 批准”“须先得到 Owner 明确批准”“若 Owner 批准 A1 开发”的表述，自本增量段起均仅作为已被取代的历史门禁保留，不再阻止执行；技术范围、D1/D2/D3、安全及证据门禁不变。

当前实施门禁：Lead 已完成本文并发出配套执行指令；Owner 将该指令转交 Implementation AI 即可开始。先执行 §3 B0 与 §4 第 1 项的只读取证/分层 census；若 G1–G4 对 r3 不成立、8192 保护阈值已不足、主报告不变量无法保持或性能预算预判不可达，实施方停在取证阶段并交付阻塞证据，不得自行扩大范围。若前置门通过，再实施 §2 A1、§5 全矩阵、§6 性能和交付门禁。Implementation AI 只报告实现、自测与证据，不自判阶段 PASS；Owner 转交完整交付后，由 Lead 决定是否通过及下一批方向。

实施交付必须至少包含：exact commit/parent/受控文件清单和共享工作区残留状态；四轮与 T2 的匿名化 Session/Raw SHA/输入输出清单；B0 双轴与所有者冲突矩阵；A1 主报告零差异证明、分层计数、512/513 与 8192/8193、身份/线程复用/timeout 对抗测试；专项及全量测试命令与原始输出；前后性能对比；日期化 Implementation Update、站点/新增归档与构建结果；签名/公证/stapling/安装/包 SHA 的真实状态；双远程与 Webhook 结果；仍缺的 E4 真机证据及下一阶段。任一门禁缺口如实标 partial/blocked，不以旧 Build74 包或历史 r3 回放冒充新包 E4。

Implementation Update（2026-09-24 · Implementation AI · E2）

> 关联方案：本文件（Build 74 Phase 2 唯一实施依据）。前置门（§8 / §4 第 1 项）判定 通过，已按 §2 实施 A1、按 §3 完成 B0 只读取证、按 §5/§6 执行验证矩阵与效率门禁。证据等级 E2：本段记录本地构建、测试与原始字节回放的真实结果。A1 真机 E4 未执行、新包未构建未签名未公证，阶段状态不由实施方自判 PASS；Total、质量、阶段覆盖与活线 UI 语义保持冻结。

IU-1 受控文件与基线

IU-2 前置门（§4 第 1 项 / §8）

结论：不停在取证阶段，进入 A1 实施。

IU-3 四轮分层 census（out/rounds-census.json）

• Raw SHA-256（匿名化清单）：S2 2d9932ff…037f1f；T1-r1 073eb427…6c50865；T1-r2 bc98c9fd…8ffb718；T1-r3 0589cca3120288108886633942e8d045fe918b683b8227d43e1d6f9e20ad7637。
• minimalWhitelistGapCount = 0 四轮成立 ⇒ 最小扫描与全量扫描的 action code 覆盖等价（方案 §2.1 第 2 条）。
• 四轮外层身份各只有一个组合 (targetGeneration=1, sourceEpoch=1, reconnectGeneration=0, sourceID=同一值)，与各自 launch.requested.raw 一致；targetPIDResolved=true。该身份是本批四个历史样本的事实，实现里没有写死任何一代际数值。
• handoffDrainStatus：S2 / T1-r1 / T1-r2 为 quiescent，T1-r3 为 timeout。
• 分母差异（如实保留，待 Lead 复核口径）：本批按重组 RAW v2 流上 record_offset % 64 == 0 的记录对齐计数，得 mappingTidCount 471/417/486/616、union 3299/3148/2734/2904；方案 §0.3 记录的是 563/505/573/721 与 3391/3236/2821/3009。两者都远低于 8192，结论不变。

IU-4 A1 诊断块（真机原始字节，逐字段）

T1-r3 其余可复核 locator：opener recordIndex=4118589、recordOffset=537664、rawSequence=52；closer recordIndex=4168471、recordOffset=2694848、rawSequence=53；recordIndexUnit="decoded-record-index-1-based"、recordOffsetUnit="chunk-relative-byte-offset"；rejectReasons 非零仅 terminal-already-closed: 1 与 thread-binding-unknown: 28；deviceLostEventMarkerCount=10、deviceLostArgSemanticsVerified=false；sourceEpoch / targetGeneration / reconnectGeneration = 1 / 1 / 0。

• selected closer 是 tick 更早的那条（正差 296418 ticks = 12.35075 ms，仅离线断言用，不输出）⇒ 冻结契约「较早可闭合 closer 胜出、其余记 terminal-already-closed」在真实字节上成立，未生成第二条 span。
• 诊断块不含 *Total*、*Repair*、diagnosticEndpointMs，也不含任何 launch→closer 毫秒值；缺值一律 null 而非 0；拒绝或超限时所有 selected* 字段为 null。
• S2 的 9 条任意线程记录未被目标化（thread-binding-unknown: 9）；r1 缺 launch start 未以 0 代替；r1/r2 目标 actionable 为 0。

IU-5 B0 只读取证（T2 轮）

• Session 别名 T2；rawSHA256 = 8b20cdec05869ca3741cc9bab90d3f20f89cdc64d64a7e038b774fd79d3a95b7；display.frame-lifetime.raw 1716 条 + launch.requested.raw 1 条。
• 双轴（各自时间域独立计算）：hostSpanMs = 134486.592、presentationSpanMs = 30721.029、observedSpanRatio = 0.2284；主机轴 p50 = 70.311284 ms 对设备轴 p50 = 16.642166 ms。该比值只是观察到的跨度比，不是时钟换算系数。
• staleHostGapCount = 0（阈值 FRESHNESS_STALE_HOST_GAP_NS = 1_000_000_000）⇒ 产品注释记载的「陈旧／突发投递」族在本 Session 上不成立。
• 所有者冲突矩阵：ios.display.refresh_rate、ios.foreground.fps、ios.frame.pacing_jitter、ios.frame.time.p95 四项 sampleCount=0、valueQuality="missing"；唯一 ios.frame.time = 1686 / "candidate"。applyFrameCoverageMissing 恰为上述四项。
• metrics-derived.jsonl：空串哈希、frameCount=0、metricIDs=[]、consumedRawEventCount=1717；DisplayPerformanceProjector 自述拥有全部五项，但产出只落活线样本字典 ⇒ 这是接线缺口，不是采集缺口。
• 时钟成因保持 unknown；未扩 _apply_frame_coverage.metric_map，未提升任何质量等级，未出数。

IU-6 验证矩阵与命令（原始结果）

1. 专项合成矩阵（§5 A-P / A-N / A-I / A-C / A-B / A-S / A-Q）：cd MacApp/Sidecar && PYTHONPATH=. python3 -m unittest tests.test_build74_a1_stop_drain_diagnostic → Ran 45 tests … OK。
2. 四轮主报告逐字段冻结对照：python3 scripts/a1_frozen_vs_new.py → 四轮 frozenDiffs=0、added=['stopDrainLifecycleDiagnostics']、removed=[]；冻结树 hasDiagnosticKey=false、修改树 =true；结论字符串 ALL FOUR ROUNDS: frozen fields identical。
3. 三扫描模式等价：python3 scripts/a1_three_modes.py → 四轮 minimal == exhaustive == offline 全 True。
4. 分层 census 与 B0：python3 scripts/census_rounds.py、python3 scripts/b0_frametime.py → out/rounds-census.json、out/b0-frametime-dual-axis.json。
5. 全量 Sidecar：cd MacApp/Sidecar && PYTHONPATH=. python3 -m unittest discover -s tests -p 'test_*.py' → Ran 1022 tests in 124.343s / OK。
6. Swift 现有报告／工作台回归：cd MacApp && swift test --disable-sandbox → Executed 204 tests, with 3 tests skipped。首轮与全量 Python 套件并行运行时出现 1 项未命名失败；随后 4 轮互不竞争的运行均为 0 failures（含一次单独复跑）。本批 git diff --name-only 只含 1 个 Python 文件、未改任何 Swift 源 ⇒ 不归因本批，但该次未复现失败按诚实原则记录在此。
7. 知识契约门禁：cd site && python3 scripts/metric-knowledge-gate.py → PASS: 66 Registry contracts, Canonical ownership, versionless governance, ten-element markers, sidebar, overview, knowledgeRole governance, and rendered visual coverage。

（以上命令使用的解释器为受管 Python 3.12：/private/tmp/perfowl-core-py312/bin/python3；脚本位于私有归档 scripts/。）

IU-7 效率门禁（§6）与一次真实超支

第一次实测（交错 3 配对、min-of-N）：7 项超预算 —— S2／CPU +119.9 ms；T1-r1／wall +218.0、CPU +221.9 ms；T1-r2／wall +163.4、CPU +161.6 ms；T1-r3／wall +652.3、CPU +651.5 ms（各轮预算 100 / 100 / 100 / 100 / 100 / 189.8 / 186.5 ms）。按 §6「超过即回 Lead，不自行放宽」的精神，阈值未动，改为分解成本并修正实现：

修正后（交错 5 配对、min-of-N） —— 结论：PERF: every metric within the plan §6 budget。

峰值 RSS 四轮均为负增量（修改版更低），读 I/O 全 0，均在 §6 预算内。

活线路径（§6「首个 live snapshot 延迟、长会话最坏值」）——同一 Session、活线构造（emit_completed_trace=true、诊断开关保持默认关闭），交错 5 配对：

增量有正有负、量级与主机噪声同阶 ⇒ 活线链路未新增扫描或等待；两棵树的活线报告都不含 stopDrainLifecycleDiagnostics。

IU-8 相对方案的偏差

1. drain 记录的发现方式：方案 §2.1 第 2 条允许「只在诊断 opt-in 的局部集合补齐 ID」。实现改为记录跨步字节平面预筛 + _lifecycle_actions 复核，按命名空间而非 debugID 白名单选择（_lifecycle_actions 对 0x1F/0x07 code-13 与 0x2B/0x87 code-90 等形态忽略低位 func，白名单会静默漏掉等价记录）。覆盖等价性由 minimalWhitelistGapCount=0 与三模式逐轮等价证明；不扩大冻结正则 alternation。
2. 账本的承接路径：映射记录优先在冻结映射分支内折叠；整块被冻结分支跳过的分块（frame-continuation、post-publish、retain_all_records）改由流式包装器折叠。四轮三模式与 45 项测试钉住语义等价。
3. captureComplete 口径：取 handoffDrainStatus ∈ {end-of-stream, quiescent} 为 true，timeout 为 false，且允许与 chainObservedClosed=true 并存（方案 §2.3 第 3 条）。产品从不发出字面量 "complete"，早期按 =="complete" 判定会把 r3 误标，已在实现中修正。
4. retain_all_records（审计模式）差异：该模式会把 drain continuation 记录也保留成冻结记录，从而让 code=12 opener 关闭掉 G4 要求仍然打开的 UIKit Scene Creation ⇒ 该模式报 open-start-phase-missing: 1、thread-binding-unknown: 28、accepted=0。等价性主张仅限两种产品选择模式（minimal / exhaustive / offline）；该差异已在测试与代码注释中显式文档化。
5. 账本内部表示：tid→单一 PID/冲突 由「绑定 dict + 冲突集合」改为「同一 dict 内负哨兵 + 命名镜像集合」。可观测契约（rejectReasons 与诊断块字段）逐字段不变。
6. 测试 fixture 的 sourceID：复用产品源码中本批之前已存在的 CoreProfile sourceID 常量（3 个产品模块 + 1 个既有测试），未新增任何设备标识。按 §2.4，站点与 docs 归档不写出该值，也不写真实 tid / PID / Session UUID；原始标识只留在私有归档供审计。

IU-9 门禁状态（不自判 PASS）

IU-10 站点与归档

• 本段写入后，按 AGENTS.md C2 在 site/devlog/index.md 时间线顶部追加节点，并把本文件渲染出的 HTML 快照新增到 docs/architecture/（既有归档不回改）；按 C3 同步「八阶段总计划」与「未关门门禁」两张表。
• 站点构建与交付门禁的真实结果记录于下一段。

IU-11 站点构建与归档（本段记录于构建之后）

• cd site && npm run build（prebuild 自动执行知识门禁与归档同步）→ 门禁 [metric-knowledge-gate] PASS: 66 Registry contracts, Canonical ownership, versionless governance, ten-element markers, sidebar, overview, knowledgeRole governance, and rendered visual coverage；归档 [sync-archive] docs/ -> public/archive/ (263 files)；vitepress build → build complete in 93.23s，0 错误、0 死链（除既有 chunk 体积提示外无告警）。
• 新增归档快照：docs/architecture/perfowl-p4-build74-phase2-lead-decision-and-diagnostic-plan-2026-09-24-implementation-update.html（由本文件渲染）。既有 …-2026-09-24.html 与 …-2026-09-24-workflow-update.html 不回改。
• 交付门禁汇总见 IU-9：双远程推送与交付 Webhook 的真实结果随交付汇报给出；签名／公证／stapling／独立安装／包 SHA 记 partial（本机无 Developer ID Application 身份、无公证凭据）；A1 真机 E4 未执行，不以历史回放或旧包冒充。

Lead Independent Validation & A1-R1 Repair Decision（2026-09-24 · E2）

裁定：A1 的现有提交 475c541 为 REPAIR REQUIRED，不进入新包 E4；B0 的双轴观察和四轮原始字节清点可作为只读取证保留。 本段是 Lead 独立复核，不回改 IU-1～IU-11 的执行方原始读数和自测结果。Lead 复跑 Python 专项 45/45、全量 1022/1022；这些通过只证明已覆盖路径，不覆盖下列反例。Git HEAD 与两个远程 main 均核至 475c541；共享工作区其他 AI 的未提交路径和原始 Session 未触碰。

L-1 独立确认与口径更正

• 源码 diff 确认：最终 Raw replay opt-in，默认 live 不启用；主报告的 Total/质量/阶段字段未被诊断分支赋值。已有四轮回放记录 r3 目标 actionable 3、接受 2、额外 closer 1；S2/r1/r2 无目标闭合链；r3 handoffDrainStatus=timeout，不能宣称采集完整或新包 E4。
• Lead 从四轮 binary chunk 按存储偏移重组 RAW v2，再逐个 64-byte kd_buf 复算映射 TID：所有正 TID 为 563/505/573/721；其中具有正 PID 见证的是 471/417/486/616；差额 92/88/87/105 全部仅见 PID=0。故方案 §0.3 与 IU-3 不是字节矛盾，而是分母不同。8192 是保护上限，不是未来会话容量证明。
• B0 中 observedSpanRatio=0.2284 定义为 presentationSpan/hostSpan，逆比约 4.38；这两者都不是时钟换算系数。T2 的 1716 帧、四项 missing、FrameTime 1686 candidate 保持观察结论；staleHostGapCount=0 仅排除“大于冻结 1s 阈值的相邻 host gap”，不能排除其他时钟/节流成因。B1/B2/B3、Network、Phase C 均未放行。

L-2 阻断性反例（Lead 以已提交测试 fixture 的 kd_buf 构造作只读复跑）

1. G1/G2 整批身份不一致未失效。 在同一回放中先输入另一个 sourceID 的 drain lifecycle 记录，再输入基线 sourceID 的 opener+closer，当前诊断出现 source-mismatch=1 且仍 chainObservedClosed=true、acceptedEventCount=2。实现只给单条候选设 gate bit，未落实 §2.1 第 3 条“原始来源不一致使诊断账本失效”及 §2.2 G2“整批不给闭合诊断”。generation/epoch/reconnect 缺失或不一致也不得以后续正常候选洗白。
2. D2/G4 缺锚点设备 tick 顺序门。 冻结 UIKit Scene Creation begin tick=150，drain opener tick=140、closer tick=200，当前仍 chainObservedClosed=true，直接违反本方案 §1 closer > opener >= openSceneBegin。只检查 _open 非空不够；须读取同线程该 open begin 的原始 machTicks 并检验同域次序，缺 tick fail-closed。
3. G4 忽略同线程中间冲突 transition。 drain 的 opener tick=1000、再次 scene begin tick=1100、closer tick=1200，当前仍闭合；_STOP_DRAIN_ACTION_OTHER 被记录却从未参与闭合判决。现有 test_opener_must_be_the_code12_shape_not_any_begin 甚至断言额外 scene begin 后仍闭合，属于需修正的正例。相同线程从冻结 anchor 到选中 closer 之间再出现 phase-3/phase-8 竞争 transition 时，必须明确拒绝或证明它不冲突，不能静默跳过。
4. 字段语义需收紧。 当前 captureComplete=true 仅由 drainStatus ∈ {end-of-stream,quiescent} 推出，即使有设备丢失 marker 也可能为 true。该字段名会被误解为生命周期数据完整；在本批尚未有新包消费者时，将其改为准确的 drain 终止状态字段（建议 drainEndedWithoutTimeout），或给出等价而不宣称数据完整性的命名；保持 deviceLostEventMarkerCount 独立。rejectReasons 覆盖预筛/身份/线程/链多层，而 rejectedEventCount 只计目标层，文档与测试必须明确两者不可相加。

L-3 A1-R1 唯一可执行修复边界与验收门禁

• 范围：只修 launch_trace.py 的诊断 opt-in 分支、匹配的专项测试、本文件日期化增量记录和站点/新增归档；不得动默认 live、主 _records/_spans/Total、role、采集配置、FrameTime 公式、Network、Swift UI 或 Phase C。不得回改既有历史报告与归档。
• 会话级失败优先：每个消费的 CoreProfile Raw 外层 sourceID/targetGeneration/sourceEpoch/reconnectGeneration 与 launch baseline 比较，包括被主解码器提前丢弃的 chunk、无 actionable 的 chunk；任一缺失/不一致置诊断批次无效，保留分层计数和精确原因，但 diagnosticUsable=false、chainObservedClosed=false、acceptedEventCount=0、全部 selected locator/tick=null。正常的非 1 epoch、非 0 reconnect 与自身 baseline 相等时必须通过。主报告仍按冻结解码器自身规则运行，不因诊断失败改变。
• 闭合严格顺序：同一目标 TID 的冻结 phase-3 open begin 必须有可比较 tick，且 closerTick > openerTick >= openSceneBeginTick；anchor tick 缺值或逆序明确拒绝。对该线程从 anchor 到 selected closer 的 drain lifecycle 记录排序后，仅允许唯一 code-12 opener 与首个可闭合 IFR closer；额外 closer 保留 terminal-already-closed；重开 scene、其他 phase-3/phase-8 竞争 transition 保守拒绝并计 interleaved-conflict。不得用 15s、host stop 或 chunk 最大 tick 代替设备域门。
• 专项负例：新增“错 source 在前、正常链在后”“缺 source/epoch/generation/reconnect + 正常链”“错代际 chunk 被早退 + 正常链”“无 actionable 的错源 chunk + 正常链”“opener 早于 anchor”“anchor tick 缺值”“scene reopen 位于 anchor→opener、opener→closer”“两 closer 到达序与 tick 序相反”等；逐项断言诊断和主报告。旧的额外 scene begin 正向断言必须改为保守拒绝。正常 r3 仍需 3/2/1，S2/r1/r2 仍无目标链。
• 回归与效率：重跑 45 项原测试＋新增负例、全量 Sidecar、Swift/知识门禁、站点构建；四轮原始 Raw SHA 与主报告字段零差异、minimal/exhaustive/offline 等价、512/513 和 8192/8193 option A 继续成立；基线/修订版交错性能比较仍按 §6 原阈值，不放宽。打包/Developer ID/notary/staple/独立安装及新包 E4 缺口保持真实状态，不用历史回放代替 E4。
• 交付：Implementation AI 在本文件追加 A1-R1 Implementation Update，提交仅本批路径并尝试双远程推送、验证站点实际内容、按 AGENTS.md 发送一次交付 Webhook；交回 exact commit/parent、差异、所有命令原始结果、四轮/对抗 fixture 逐字段矩阵、性能与包/E4 状态。Implementation AI 不自判 PASS；Owner 直接转交 Lead 独立复验，无需另行逐批审批。

当前 Gate：A1 E2 = REPAIR REQUIRED；A1 新包 E4 = NOT RUN；Total/质量/阶段覆盖仍冻结；B0 E1 观察已接收但不授权 B1。

A1-R1 Implementation Update（2026-09-24 · Implementation AI · E2）

实施依据：本文件末尾的 “Lead Independent Validation & A1-R1 Repair Decision”（L-1 口径更正、L-2 四项阻断性反例、L-3 唯一可执行修复边界）。基线 main = 1c7570a130958987e11919c468eedc28b50ac845。本段为纯追加，不回改 IU-1～IU-11 与 L-1～L-3 的任何数字。

范围纪律：只改 launch_trace.py 的诊断 opt-in 分支、匹配的专项测试、本文件与站点/新增归档。默认 live 构造、主 _records/_spans/Total、质量、阶段覆盖、role、采集配置、FrameTime 公式、Swift UI、Network、Phase C 全部未触碰；未回改既有历史报告与归档。

R-1 实际修改（MacApp/Sidecar/perfowl_collector_core/launch_trace.py +178 / −73）

新增拒绝原因 anchor-tick-missing、opener-before-anchor 已写入 STOP_DRAIN_REJECT_REASONS（词表保持封闭，rejectReasons 仍逐键自该元组生成）。

R-2 对抗 fixture 与专项测试（45 → 60 项）

MacApp/Sidecar/tests/test_build74_a1_stop_drain_diagnostic.py +285 / −13。新增 15 项，其中 L-3 点名的负例逐条落地：

被修正的旧正例：test_opener_must_be_the_code12_shape_not_any_begin 原先断言「额外 scene begin 后仍闭合」，按 L-2 item 3 改为保守拒绝（interleaved-conflict=1、acceptedEventCount=0）；同批把 captureComplete 的三处断言改名为 drainEndedWithoutTimeout，并给 replay() 增加 identity_per_chunk 以构造混合身份回放。

R-3 四轮原始字节正负回放与主报告冻结对照

r3 其余 locator 与 A1 完全一致：opener recordIndex=4118589、recordOffset=537664、rawSequence=52；closer recordIndex=4168471、recordOffset=2694848、rawSequence=53；rejectReasons 非零仅 terminal-already-closed: 1 与 thread-binding-unknown: 28；deviceLostEventMarkerCount=10、deviceLostArgSemanticsVerified=false；sourceEpoch / targetGeneration / reconnectGeneration = 1 / 1 / 0。

对照结论（三树同机、同一不可变 Session 副本）：

• base（A1, 1c7570a）→ ship（A1-R1）：四轮 baseVsShipFrozenDiffs=0，且报告键集合既未增也未减（added=[] / removed=[]）⇒ 修复严格落在诊断块内部，主报告逐字段零差异。
• frozen（b45d15e7）→ ship：四轮 frozenVsShipFrozenDiffs=0、added=["stopDrainLifecycleDiagnostics"]、removed=[]；冻结树四轮 hasDiagnosticKey=false。
• 诊断块 base→ship 的唯一差异就是字段改名（captureComplete 无此名 ⇒ 呈现为 (null, true/false)），其余 18 个可对照字段的值逐轮相同。
• r3 逐字段复现 A1：31 / 3 / 2 / 1、链闭合、truncated=false、selected tick 与 locator 全同 ⇒ 修复未改变任何真实正向结果。
• 负向回归保持：S2 仍 targetActionableCount=0（9 条任意线程记录 thread-binding-unknown: 9）、r1/r2 仍 0 ⇒ 未被本次修复误伤为闭合。
• 新 chunk 级身份门在真实数据上未误伤：四轮均 batchInvalid=false；若任一真实 chunk 身份不一致，r3 会立刻退化为 diagnosticUsable=false，实测没有。

R-4 三模式等价、容量边界与 option A

• 四轮 minimal == exhaustive == offline 全 True（扫描覆盖等价未被本次修复破坏）。
• 容量余量未变：候选行 9 / 0 / 0 / 31 ≪ 512；唯一绑定 tid 2977 / 2888 / 2330 / 2440 ≪ 8192；conflictTidCount=0、bindingOverflow=false。8192 仍只是保护上限，不是未来会话容量证明。
• 512/513 与 8192/8193 的 option A 继续成立：test_candidate_capacity_boundary_is_inclusive_at_512、test_candidate_overflow_at_513_invalidates_the_whole_diagnosis、test_thread_binding_capacity_boundary_is_inclusive_at_8192、test_thread_binding_overflow_at_8193_invalidates_the_whole_diagnosis、test_worst_case_capacity_completes_without_unbounded_allocation 五项在 60 项专项中全部通过。本批未改任何容量常量或阈值。

R-5 效率门禁（§6，阈值未放宽）与活线路径

解释器受管 Python 3.12，交错 5 配对、min-of-N，同一不可变副本。§6 预算逐字沿用：wall / CPU 各 ≤ max(5%, 100 ms)，ΔRSS ≤ 8 MiB。两种对照都报，因为二者回答不同问题。

对照一 · frozen（无诊断）→ ship（A1-R1） = 诊断总成本，与 IU-7 同口径：

对照二 · base（A1）→ ship（A1-R1） = 本次返工自身的增量：

结论：PERF: every metric within the plan section 6 budget at 5 interleaved pairs —— 8 组对照 × (wall, CPU, RSS) 共 24/24 在预算内。相对 frozen 的最大增量是 r3 wall +159.270 ms（+4.08%，预算 195.3 ms）；相对 A1 基线的最大增量是 S2 wall +52.970 ms（+3.84%，预算 100 ms）；ΔRSS 全部在 −0.574 ～ +2.105 MiB。未放宽任何阈值。 readBlocks 全 0。

活线路径（base ↔ ship，交错 5 配对）：

• 首快照、全会话 consume、最差单分块的最大差值分别 8.288 / 19.143 / 7.040 ms，与主机噪声同阶；两树活线报告都不含 stopDrainLifecycleDiagnostics ⇒ 本批新增的 chunk 级身份检查只存在于 _stop_drain_enabled 为真的离线分支，活线逐指令未变。
• 口径更正（诚实记录）：上一轮 out/a1-perf-interleaved.json 把 ru_maxrss 的字段名写作 maxRssKb，但 macOS 上该值单位是字节（Linux 才是 KiB）。IU-7 报告中的 “ΔRSS −8.86 ～ −10.83 MiB” 实为 bytes/1048576 的结果，数值本身可用、字段名有误导。本轮探针改用 maxRssBytes / deltaMinMiB 并显式注释单位；未回改上一轮归档（D2）。

R-6 验证命令与原始结果

1. 专项矩阵：cd MacApp/Sidecar && PYTHONPATH=. python3 -m unittest tests.test_build74_a1_stop_drain_diagnostic → Ran 60 tests … OK（A1 为 45，本批 +15）。
2. 四轮三树回放对照：python3 scripts/a1r1_four_round_replay.py → 四轮 baseVsShipFrozenDiffs=0 / frozenVsShipFrozenDiffs=0 / added=["stopDrainLifecycleDiagnostics"] / removed=[]；结论字符串 FOUR ROUNDS: base==ship and frozen==ship on every frozen field。
3. 三模式与容量：python3 scripts/a1r1_three_modes_and_capacity.py → 四轮 minimal == exhaustive == offline 全 True；THREE MODES: minimal == exhaustive == offline on all four rounds; capacity headroom unchanged。
4. §6 效率：python3 scripts/a1r1_perf_interleaved.py 5 → PERF: every metric within the plan section 6 budget at 5 interleaved pairs (frozen->ship and base->ship)。
5. 活线延迟：python3 scripts/a1r1_live_latency.py pair 5 → 上表；两树活线均无诊断块。
6. 全量 Sidecar：cd MacApp/Sidecar && PYTHONPATH=. python3 -m unittest discover -s tests -p 'test_*.py' → Ran 1037 tests in 123.316s / OK（A1 为 1022，本批 +15）。
7. Swift：cd MacApp && swift test --disable-sandbox → Executed 204 tests, with 3 tests skipped and 0 failures（本批未改任何 Swift 源）。
8. 知识契约门禁：cd site && python3 scripts/metric-knowledge-gate.py → PASS: 66 Registry contracts …。
9. 站点构建：见 R-6b。

R-6b 站点构建与新增归档

• 新增归档快照（C2，既有 docs/ 归档不回改）：docs/architecture/perfowl-p4-build74-phase2-lead-decision-and-diagnostic-plan-2026-09-24-a1r1-update.html，由本文件渲染。
• cd site && npm run build → 知识门禁与归档同步随构建同批执行，退出码 0、0 死链，原始输出（关键行；全日志 67 行）：

> python3 scripts/metric-knowledge-gate.py && bash scripts/sync-archive.sh
[metric-knowledge-gate] PASS: 66 Registry contracts, Canonical ownership, versionless governance, ten-element markers, sidebar, overview, knowledgeRole governance, and rendered visual coverage
public/archive/.DS_Store
[sync-archive] docs/ -> public/archive/ (265 files)
✓ building client + server bundles...
✓ rendering pages...
build complete in 98.68s.

• 全日志 grep -E 'Dead link|dead link|error|Error' 零命中；vitepress build 若遇死链会非零退出，本批 EXIT=0。
• site/devlog/index.md 按 C2/C3 更新（时间线顶部节点、阶段进度行、未关门门禁行），不删除任何历史节点。

R-7 相对方案的偏差（逐条，均为实现细节，不改语义）

R-8 遗留项与门禁状态

• A1 E2 返工完成，但Implementation AI 不自判 PASS；由 Owner 转交 Lead 独立复验。
• A1 新包 E4 = NOT RUN：需要新包上的正向闭合链 + 真实负向形态 + 原始哈希/报告一致性 + 活线对最终主字段对照。本批未构建新包、未执行真机，不以历史回放冒充 E4。
• 签名 / 公证 / stapling / 独立安装 / 包 SHA-256 = partial：本机无 Developer ID Application 身份、无 notarytool 凭据。冻结 Build74 测试包 SHA-256 仍为 3a557cc0c0c666f90736c34fa9b633adb646a92a55ecfdae095c41f349a5dbc1。
• 未并批：B1/B2/B3、Device Network、Phase C、role 标记、采集配置。
• Total / 质量 / 阶段覆盖仍冻结；totalDurationMs 继续不发布；B0 的 E1 观察已接收但不授权 B1。

Lead Independent Validation & A1-R2 Repair Decision（2026-09-24 · E2）

裁定：f54afee 的 A1-R1 修复解决了 L-2 原三项反例，但 A1 E2 仍为 REPAIR REQUIRED，不进入新包 E4。 本段只追加 Lead 新验证结论，不回改 R-1～R-8 的执行方数据。Lead 核对 exact parent=1c7570a、提交范围恰为 5 个本批路径、GitLab/GitHub main 同为 f54afee、共享工作区其他 AI 的 4 个路径未动；独立复跑专项 60/60 与 Sidecar 全量 1037/1037。四轮已验证 Raw 副本独立回放仍为 r3 31/3/2/1、链闭合，S2/r1/r2 无目标闭合链，四轮 Total 均 missing/partial；这证明历史样本不误伤，不能证明 G4 对其他线程形态安全。

V-1 独立对抗结果与根因

1. 跨目标线程误配（阻断）：同一个 launch/epoch/source 中，冻结 scene begin 和 drain code-12 opener 在目标线程 A，另一个有独立目标 PID 映射见证的线程 B 仅有 IFR closer。当前诊断 targetActionableCount=2、acceptedEventCount=2、chainObservedClosed=true、无拒绝原因。源码 closers=[row for row in target_rows if row[4]==CLOSE_IFR] 未约束 row[2]==opener[2]，违反 §2.2 G4 的“同 tid closer”。不能把两个目标线程拼成一条生命周期链。
2. 其他目标线程误阻断（同一根因的负向）：线程 A 有完整 opener/closer，线程 B 在两者之间出现 scene begin；当前报告 interleaved-conflict=1 且链不闭合。G4 冲突只可检查 opener 所属线程，其他目标线程的 action 不应成为该链的冲突证据。目标进程身份相同不等于线程相同。
3. 同 tick 的中间竞争事件漏判（阻断）：线程 A 的 scene reopen 与 opener 均 tick=1000，reopen 的到达序先于 opener，closer tick=1200；当前仍 chainObservedClosed=true。R1 的前窗 < openerTick 与后窗 (openerTick,arrival) 均跳过了“同 tick 且先到达”的 reopen。设备 tick 不能给这两条事件证明安全先后，应保守拒绝；同 tick 于 closer 的竞争 transition 同理需要明确 fail-closed 规则。

V-2 A1-R2 最小修改合同

• 范围：仅 launch_trace.py 的 opt-in 诊断 G4 投影、匹配 Python fixture、本文件日期化 Implementation Update、C2/C3 站点与新增归档。不得改 chunk 身份门、Raw 扫描/保留、线程映射账本、默认 live、主报告、role/采集配置、Swift/UI、Network、FrameTime 或 Phase C。既有两个容量常量及 §6 性能门槛不变。
• 同线程准入：先确定唯一 opener 的 threadID=A 及冻结 scene anchor；仅同一 threadID=A 的纯 IFR closers 可作 terminal，按 (machTicks,arrivalSequence) 选最早可闭合者。线程 B 的 closer 绝不可配 A 的 opener，也不可记为 A 的 terminal-already-closed；线程 B 的其他 action 绝不可阻断 A 的闭合。targetActionableCount 仍为身份/目标 PID 层的全部候选；需在诊断原因或字段契约中清晰解释其他目标线程的未入链记录，不得伪装成已接受。
• 同 tick 冲突：在 opener 线程 A 上，自冻结 anchor 起至候选 closer 含端点 的任何非纯 IFR closer、非唯一 code-12 opener 的生命周期 action 都是竞争 transition；若与 opener 或 closer 同 tick，设备域无法证明严格的安全先后，故保守拒绝并计 interleaved-conflict。closerTick 仍必须严格大于 openerTick，openerTick 不得早于 anchorTick。选中首个可闭合 closer 之后且 tick 严格更晚的 transition 不影响既成链；两个纯 closer 按冻结“较早可闭合者胜出”规则处理。
• 必须新增正负 fixture：A opener+B closer（两线程均有目标 PID 见证）→ 无闭合；B closer 更早、A closer 更晚 → 必须选 A；A 完整链+B 中间 scene transition → A 可闭合；A 内 scene reopen 与 opener 同 tick、分别置于到达序前/后 → 均拒绝；A 内竞争 transition 与 closer 同 tick、到达序前/后 → 均拒绝；A 内 opener/closer 之后 tick 严格更晚的 transition → 不误伤；原 L-2 三项负例与 r3/S2/r1/r2 原始回放全部保持。新增测试要同时断言 selected locator、accepted/rejected 和原因，不只断言布尔闭合。
• 验收：专项 + 全量 Sidecar、Swift/知识门禁、站点构建；四轮原始 SHA/主报告冻结字段零差异、minimal/exhaustive/offline 等价、512/513 与 8192/8193 option A；基线/修订版交错 wall/CPU/RSS/I/O 与活线延迟按 §6 原预算复核。保留签名/公证/包与新包 E4 的真实缺口，Lead 复验 E2 前不启动 E4，不发布 Total。
• 交付：Implementation AI 追加本文件 A1-R2 Implementation Update，新增不可回改的 HTML 快照，窄范围提交/双远程/内容校验/Webhook；交回 exact commit/parent、完整 diff、对抗矩阵、原始测试及性能结果、四轮 Raw SHA/locator、包/E4 状态。Implementation AI 不自判 PASS；Owner 直接转交 Lead，无需逐批审批。

当前 Gate：A1-R1 原反例修复已验证；A1 E2 = REPAIR REQUIRED（新增 G4 同线程/同 tick 反例）；新包 E4 = NOT RUN；D1/D2/D3、Network 单批与 Phase C FROZEN 均不变。

A1-R2 Implementation Update（2026-09-25 · Implementation AI · E2）

按本文件末尾 Lead Independent Validation & A1-R2 Repair Decision（V-1/V-2） 执行的最小返工。范围仅 Stop-drain 诊断的 G4 投影与匹配 Python fixture：默认活线、Raw 扫描/保留、chunk 身份门、线程映射账本、role、采集配置、Total、Swift/UI、Network、FrameTime B1/B2/B3、Phase C 一律未动；两个容量常量与 §6 性能预算未放宽。共享工作区其他 AI 的 4 个未提交路径与 MacApp/Tests/1.trace/ 全程保全。

R-1 实际修改（launch_trace.py +55/−34，3106 → 3232 行中的诊断投影段）

未改动（逐字节）：STOP_DRAIN_CANDIDATE_CAPACITY=512、STOP_DRAIN_THREAD_BINDING_CAPACITY=8192、_stop_drain_check_chunk_identity、_stop_drain_lifecycle_offsets、_stop_drain_fold_mapping_stream、_matching_record_offsets、_stop_drain_note_binding*、_stop_drain_fold_binding、_stop_drain_anchor_ticks、derive_launch_trace_session。

R-2 对抗 fixture（测试 +198/−0，60 → 67 tests）

新增 second_thread_witness() helper（同 PID 异 tid 的 G3 映射见证）与 7 项测试，每项同时断言 selected locator、accepted/rejected 与原因：

旧 60 项全部原样通过（含 L-2 三项负例、r3 形状、容量边界 512/513、8192/8193 option A、三模式等价与 hash-bound 回放）。

R-3 四轮三树原始字节回放（a1r2-four-round-replay.json，failures: []）

frozen=b45d15e7（无诊断）／base=f54afee（A1-R1，产品码与 A1-R2 基线 3c94f19 逐字节相同，sha256 935b362d… 已由脚本断言）／ship=A1-R2。每轮 baseVsShipFrozenDiffs=0、frozenVsShipFrozenDiffs=0、新增键仅 stopDrainLifecycleDiagnostics、removed=[]；冻结树四轮均无诊断键；四轮 rawSHA256 与 census 期望逐轮相等。

r3 逐字段复现 A1-R1：opener/closer tick 16767974101340/16767975398389、recordIndex 4118589/4168471、rawSequence 52/53、非零原因 {'terminal-already-closed': 1, 'thread-binding-unknown': 28}；S2 仍 any=9/target=0（thread-binding-unknown: 9），r1/r2 仍 any=0。四轮 offThreadTargetRecordCount=0——真实四轮采集没有第二个目标线程的 actionable 记录，新门未误伤任何历史样本。

R-4 三模式等价与容量（a1r2-three-modes-and-capacity.json，failures: []）

batchInvalid=false、ledgerInvalid=false、bindingOverflow=false 全四轮成立；容量边界 512/513 与 8192/8193 option A 由专项测试钉住，常量未动。

R-5 效率与活线（交错 5 配对，failures: []，24/24 在预算内）

预算规则不变（|Δ| ≤ max(基线 min 的 5%, 100 ms)，RSS ≤ +8 MiB）。frozen→ship 最差 r3 wall +186.624 ms（+4.86%，预算 192.0）；base→ship 四轮全部在 −19.717 ～ +23.234 ms。RSS 字段名在本批探针中更正为 maxRssBytes（macOS ru_maxrss 单位是字节；值一直正确，A1-R1 归档不回改）。

活线（base↔ship，5 配对；诊断默认关闭，按活线构造驱动）：

最大差值（首快照 +6.996 / 全会话 +49.594 / 最差单分块 +4.505 ms）与主机噪声同阶；两树活线报告均不含 stopDrainLifecycleDiagnostics。

R-6 验证命令与原始结果

1. 专项矩阵：cd MacApp/Sidecar && PYTHONPATH=. python3 -m unittest tests.test_build74_a1_stop_drain_diagnostic → Ran 67 tests … OK（A1-R1 为 60，本批 +7）。
2. 四轮三树回放对照：python3 scripts/a1r2_four_round_replay.py → 结论字符串 FOUR ROUNDS: base==ship and frozen==ship on every frozen field; only stopDrainLifecycleDiagnostics added.
3. 三模式与容量：python3 scripts/a1r2_three_modes_and_capacity.py → THREE MODES: minimal == exhaustive == offline on all four rounds; capacity headroom unchanged.
4. §6 效率：python3 scripts/a1r2_perf_interleaved.py 5 → PERF: every metric within the plan section 6 budget at 5 interleaved pairs (frozen->ship and base->ship).
5. 活线延迟：python3 scripts/a1r2_live_latency.py pair 5 → 上表；两树活线均无诊断块。
6. 全量 Sidecar：cd MacApp/Sidecar && PYTHONPATH=. python3 -m unittest discover -s tests -p 'test_*.py' → Ran 1044 tests in 119.817s / OK（A1-R1 为 1037，本批 +7）。
7. Swift：cd MacApp && swift test --disable-sandbox → Executed 204 tests, with 3 tests skipped and 0 failures（本批未改任何 Swift 源）。
8. 知识契约门禁与站点构建：见 R-6b。

R-6b 站点构建与新增归档

• 新增归档快照（C2，既有 docs/ 归档不回改）：docs/architecture/perfowl-p4-build74-phase2-lead-decision-and-diagnostic-plan-2026-09-24-a1r2-update.html，由本文件渲染。
• cd site && npm run build → 退出码 0、0 死链，原始输出（关键行；全日志 67 行）：

> python3 scripts/metric-knowledge-gate.py && bash scripts/sync-archive.sh
[metric-knowledge-gate] WARN: 42 content-risk audit hit(s), manual confirmation required
[metric-knowledge-gate] PASS: 66 Registry contracts, Canonical ownership, versionless governance, ten-element markers, sidebar, overview, knowledgeRole governance, and rendered visual coverage
[sync-archive] docs/ -> public/archive/ (267 files)
✓ building client + server bundles...
✓ rendering pages...
build complete in 94.36s.

（WARN: 42 content-risk 为既有 site/knowledge/** 内容告警，A1-R1 批次已披露，本批未触碰该目录，门禁最终判 PASS。）

• site/devlog/index.md 按 C2/C3 更新（时间线顶部节点、未关门门禁行），不删除任何历史节点。

R-7 相对 V-2 的偏差（逐条）

R-8 遗留项与门禁状态

• A1-R2 E2 返工完成，但 Implementation AI 不自判 PASS；由 Owner 转交 Lead 独立复验。
• A1 新包 E4 = NOT RUN：需要新包上的正向闭合链 + 真实负向形态 + 原始哈希/报告一致性 + 活线对最终主字段对照。本批未构建新包、未执行真机，不以历史回放冒充 E4。
• 签名 / 公证 / stapling / 独立安装 / 包 SHA-256 = partial：本机无 Developer ID Application 身份、无 notarytool 凭据。冻结 Build74 测试包 SHA-256 仍为 3a557cc0c0c666f90736c34fa9b633adb646a92a55ecfdae095c41f349a5dbc1。
• 未并批：B1/B2/B3、Device Network、Phase C、role 标记、采集配置。
• Total / 质量 / 阶段覆盖仍冻结；totalDurationMs 继续不发布；B0 的 E1 观察已接收但不授权 B1。

Lead Independent Validation & A1-R3 Count-Semantics Repair Decision（2026-09-25 · E2）

裁定：0306233 的 G4 同线程/同 tick 核心修复已通过 Lead 对抗复测，但 A1 E2 整体暂为 REPAIR REQUIRED。 本段仅追加，不回改 A1-R2 执行方数字。Lead 核对 exact parent=3c94f19、提交恰 5 个本批路径、双远程 main 同为 0306233、受保护共享区路径未动；独立复跑专项 67/67。同源同代际、两条各有目标 PID 见证的线程对照：A opener+B closer → closed=false；B 较早 closer+A 较晚 closer → 选 A；B 中间 scene transition 不阻断 A；同线程竞争 transition 与 opener/closer 同 tick 均拒绝。四轮已验证 Raw 副本独立回放仍为 r3 31/3/2/1、链闭合，S2/r1/r2 不闭合，四轮 Total 均 missing/partial。故 V-1 的配对正确性问题已关闭，但下面的新字段语义问题未关闭。

W-1 新增计数字段的已复现反例

offThreadTargetRecordCount 的定义是“目标层中位于唯一 opener 以外线程的记录数”，但当前只在 G4 锚点存在且时间门通过后的 else 分支计算。Lead 用同一 fixture 造 线程 A opener + 线程 B closer，双方均有目标 PID 见证，但冻结 scene anchor 缺失：当前 targetActionableCount=2、open-start-phase-missing=1、offThreadTargetRecordCount=0；同样的两条 drain 记录只补上 scene anchor 后该值变为 1。opener 已唯一且线程已知，缺 anchor 不改变 B 属于 off-thread 的事实，因此前一个 0 是错误的事实陈述。在多个 opener、无 opener但有目标记录、batch-invalid/truncated 的情形，参照线程或完整账本不可判定，当前默认 0 也不得被展示为“已证实没有 off-thread 记录”。四轮历史 offThread=0 只证明其可观察的目标 drain actionable 均无跨 opener 线程记录，不证明整个真实 Session 中不存在第二目标线程；执行方文档相应句子应以增量纠正。

W-2 独立全量测试现状（不作错误归因）

Lead 独立运行 Sidecar 全量 1044：本次 2 failures，分别是既有 test_g_rejected_flood_keeps_message_bound_fairness（3107 未大于 3123）与 test_sample_cadence_remains_stable_and_does_not_multiply_with_concurrent_sources（只发 1 条，期望至少 2 条），总耗时 168.469s。两测试文件在 R1 基线副本和 R2 当前树 SHA-256 相同，R2 本批代码仅动 launch_trace.py 诊断投影；但不能仅凭“未改测试文件”断言完全无回归。两项定向连续运行：R2 先 2/2、2/2、再 1/2；R1 基线三轮 2/2、2/2、2/2。此样本支持负载敏感/偶发，尚不证明与本批无关。门禁不得把执行方一次 1044/1044 或 Lead 本次失败单独包装为确定结论；下一轮需非并行复跑并给同环境基线/修订对照。

W-3 A1-R3 唯一可执行边界与门禁

• 产品修改只限新增诊断字段的计算时点/缺值语义：offThreadTargetRecordCount 默认 null（无法确定时），目标候选空且批次可用时精确为 0；唯一 opener 一经确定，即先按其 TID 统计其他目标线程记录，再做 scene anchor/设备 tick/闭合判决，使有 opener 无 anchor 的反例得到 1。无唯一 opener且有目标记录、batch-invalid 或 truncated 维持 null，不能把未评估写成 0。不得改 G4 opener/closer/冲突选择、身份门、原始扫描、Raw 保留、主报告、活线、role、采集配置、容量阈值或任何显示指标。
• 专项 fixture：唯一 opener+跨线程 closer、锚点缺失 → offThread=1 且链仍不闭合；补 anchor 后 offThread=1；无目标候选的可用诊断 → 0；多个 opener/只有目标 closer/整批身份失效/候选或绑定容量超限 → null，并逐例核 diagnosticUsable、truncated、accepted/selected/reason。不因计数修正改变 r3 的 31/3/2/1 和四轮主报告字段。
• 回归与资源：专项、四轮原始 SHA/locator、minimal/exhaustive/offline、512/513 与 8192/8193 option A、基线/修订的 §6 交错性能预算及 live 无诊断块继续跑。Sidecar 全量在无并行大负载条件下至少一次完整 PASS；对上面两项波动测试分别在同一机器、同一解释器、相邻时段对 R1 基线与 R3 修订树交错各 ≥3 轮，交付每轮原始数值和 exit code。若出现稳定的 ship-only 失败，停止并报 Lead，不擅自改其超时阈值、测试逻辑或邻接模块。
• 交付：在本文件追加 A1-R3 Implementation Update 与历史用语更正；C2 新增 HTML 快照，C3 更新时间线/门禁；窄范围提交、双远程、站点内容核实和 Webhook，保护并行 WIP 与原始 Session。交 exact commit/parent、测试原始结果、Raw SHA 与主报告对照、性能、签名/公证/包/E4 的真实状态。Owner 转交 Lead 独立复验；无需逐批审批。

当前 Gate：G4 同线程/同 tick 子门 = E2 通过；A1 整体 E2 = REPAIR REQUIRED（诊断计数缺值语义 + 全量波动测试归因）；新包 E4 = NOT RUN；D1/D2/D3、Network 独立批次与 Phase C FROZEN 不变。

A1-R3 Implementation Update（2026-09-25 · Implementation AI · E2）

按本文件末尾 Lead Independent Validation & A1-R3 Count-Semantics Repair Decision（W-1/W-2/W-3） 执行的最小返工。范围仅 Stop-drain 诊断 offThreadTargetRecordCount 的计算时点与 null/0 语义 + 匹配 Python fixture + 同环境回归归因：默认活线、Raw 扫描/保留、chunk 身份门、线程映射账本、G4 配对规则与同 tick 窗口、role、采集配置、Total、显示指标、Swift/UI、Network、FrameTime B1/B2/B3、Phase C 一律未动；两个容量常量与 §6 性能预算未放宽。共享工作区其他 AI 的 4 个未提交路径与 MacApp/Tests/1.trace/ 全程保全，原始 Session 只读。

S-1 实际修改（launch_trace.py +36 / −11）

未改动（逐字节）：STOP_DRAIN_CANDIDATE_CAPACITY=512、STOP_DRAIN_THREAD_BINDING_CAPACITY=8192、G4 opener/closer 选择、interleaved-conflict 闭区间窗口、身份门、_stop_drain_anchor_ticks、原始扫描与 Raw 保留、derive_launch_trace_session；offThreadTargetRecordCountUnit 与其余 *Unit 契约不变。

S-2 反例与专项测试（测试 +160 / −0，67 → 72 项 OK）

新增 5 项测试（含 subTest 共 12 个用例），逐例同时断言计数、diagnosticUsable、truncated、accepted/selected 与拒绝原因：

旧 67 项全部原样通过（含 L-2/V-2 全部正负 fixture、r3 形状、512/513、8192/8193 option A、三模式等价与 hash-bound 回放）。

S-3 W-1 反例 A/B 语义探针（旧 0 → 新 1，w1-counterexample-a1r2.json vs w1-counterexample-a1r3.json）

对同一批合成 fixture 分别驱动 A1-R2 树（0306233 产品码）与 A1-R3 树，逐字段对照：

这正是 W-1 复现的"opener 已唯一、仅缺 anchor 时假 0"：修复后该例为 1，且缺 anchor 不改变 B 属于 off-thread 的事实。

S-4 四轮三树原始字节回放（a1r3-four-round-replay.json，failures: []）

frozen=b45d15e7（无诊断）／base=f54afee（R1 基线；脚本把其 launch_trace.py sha256 935b362d… 与 A1-R2 归档记录的 R1 基线哈希做机器等同断言，非采信提交信息）／ship=A1-R3（sha256 658dc5b4…）。四轮 rawSHA256 与 census 期望逐轮相等；baseVsShipFrozenDiffs=0、frozenVsShipFrozenDiffs=0、base↔ship 报告键无增删、frozen↔ship 新增键仅 stopDrainLifecycleDiagnostics、frozen 树四轮均无诊断键。

r3 逐字段复现 A1-R2：opener/closer tick 16767974101340/16767975398389、recordIndex 4118589/4168471、rawSequence 52/53、非零原因 {'terminal-already-closed': 1, 'thread-binding-unknown': 28}、drainStatus=timeout、drainEndedWithoutTimeout=false；S2 仍 any=9/target=0（thread-binding-unknown: 9），r1/r2 仍 any=0。四轮 offThread=0 现为唯一 opener 存在前提下的已证实 0（真实四轮无第二目标线程的 actionable 记录）；语义更正见 S-10。

S-5 三模式等价与容量（a1r3-three-modes-and-capacity.json，failures: []）

batchInvalid=false、ledgerInvalid=false、bindingOverflow=false 全四轮成立；三模式诊断块（含 offThreadTargetRecordCount）逐轮相同；容量常量未动，512/513 与 8192/8193 option A 由 S-2 专项钉住。

S-6 §6 效率门禁：先统一字节码状态，再判预算（a1r3-perf-interleaved.json）

门禁前置条件（本批新增，阈值未放宽）：ru_maxrss 是进程高水位、含 import 期编译开销，而本机 PYTHONDONTWRITEBYTECODE=1 使任何运行都不回写 .pyc。A1-R1 树残留了一份旧 .pyc，rsync 物化的 A1-R2/A1-R3 树没有——仅此一项就让 base→ship 的 RSS 出现 +15.7 MiB 的伪回归。因此门禁先对三棵树统一 compileall（记录每树 __pycache__ 数 = 3/3/3）再测量。

24/24 在预算内（|Δ| ≤ max(基线 min 的 5%, 100 ms)，RSS ≤ +8 MiB）；readBlocks 全树全轮为 0。

缓存态消融（a1r3-bytecode-cache-ablation.json，同机、同一解释器、每态 3 次）：as-found（R1 暖 / ship 冷）457.52 vs 472.69 MiB = +15.168 MiB；both-warm 457.57 vs 457.88 = +0.313 MiB；both-cold 470.90 vs 473.79 = +2.887 MiB；判定 cache artifact confirmed ⇒ 同态下 base↔ship RSS 差 ≤ 0.32 MiB，不存在本批自有 RSS 回归。首次（混合缓存态）记录的性能 JSON 按 D1/D2 原样保留为 a1r3-perf-interleaved-SUPERSEDED-mixed-bytecode-state.json，不回改。

S-7 活线（base↔ship，5 配对，a1r3-live-latency.json）

最大差值（首快照 +8.823 / 全会话 +19.945 / 最差单分块 +3.610 ms）与主机噪声同阶；两树活线报告均不含 stopDrainLifecycleDiagnostics（诊断默认关闭、未新增扫描/等待）。

S-8 同环境波动测试归因（a1r3-flaky-interleave-{quiescent,under-load}.json）

同一机器、同一解释器、相邻时段，对 R1 基线树与 A1-R3 树交错（每轮交替先后顺序）运行 W-2 点名的两项测试；两测试文件在本批与基线逐字节相同，未改测试逻辑、未改超时阈值。

无负载下 flood 直方图两树一致：yields=3125、maxBurst=64、reasons={'message-limit': 3125, 'active-time': 0}、maxGap 1.1–9.0 ms。加负载后 active-time 抢占升到 1–8、message-limit 落到 3120–3124，撞破 > total//64 − 2 = 3123 的断言：R1 基线三轮分别 3123/3122/3120（全失败），A1-R3 为 3124/3121/3124（1 轮失败）。失败形态与 W-2 记录的 3107 未大于 3123 同源，且基线比修订树更常失败 ⇒ 该 flake 由负载引起、不是 A1-R3 的 ship-only 回归；cadence 测试在本次负载档位未复现（两树 7/7 PASS），记为未复现项而非"已排除"。未出现稳定 ship-only 失败，故未触发"停止并报 Lead"分支。

S-9 验证命令与原始结果

1. 专项矩阵：cd MacApp/Sidecar && PYTHONPATH=. python3 -m unittest tests.test_build74_a1_stop_drain_diagnostic → Ran 72 tests … OK（A1-R2 为 67，本批 +5）。
2. W-1 反例 A/B：python3 scripts/probe_w1_counterexample.py <tree> 对 0306233 树与 A1-R3 树各跑一次 → 见 S-3（旧 0 → 新 1）。
3. 四轮三树回放：python3 scripts/a1r3_four_round_replay.py → FOUR ROUNDS: base==ship and frozen==ship on every frozen field; only stopDrainLifecycleDiagnostics added.（exit 0）。
4. 三模式与容量：python3 scripts/a1r3_three_modes_and_capacity.py → THREE MODES: minimal == exhaustive == offline on all four rounds; capacity headroom unchanged.（exit 0）。
5. §6 效率：python3 scripts/a1r3_perf_interleaved.py 5 → 先打印 bytecode state normalised (compileall): {'frozen': 3, 'base': 3, 'ship': 3}，再 PERF: every metric within the plan section 6 budget at 5 interleaved pairs (frozen->ship and base->ship).（exit 0）。
6. 缓存态消融：python3 scripts/diag_bytecode_cache_ablation.py → as-found gap +15.168 MiB; uniform-state gaps [0.313, 2.887] MiB + cache artifact confirmed（exit 0）。
7. 活线：python3 scripts/a1r3_live_latency.py pair 5 → 见 S-7。
8. 波动交错：python3 scripts/a1r3_flaky_interleave.py 4 quiescent → FLAKY INTERLEAVE: no stable ship-only failure across 4 interleaved rounds per test.（exit 0）；… 3 under-load 见 S-8。
9. 全量 Sidecar（无并行大负载）：cd MacApp/Sidecar && PYTHONPATH=. python3 -m unittest discover -s tests -p 'test_*.py' → Ran 1049 tests in 122.031s / OK（A1-R2 为 1044，本批 +5；两项波动测试本轮均 PASS）。
10. Swift：cd MacApp && swift test --disable-sandbox → Executed 204 tests, with 3 tests skipped and 0 failures（本批未改任何 Swift 源）。
11. 知识契约门禁与站点构建：见 S-11b。

S-10 历史用语增量更正（不回改 A1-R2 原文）

A1-R2 的 R-3 段写有：「四轮 offThreadTargetRecordCount=0——真实四轮采集没有第二个目标线程的 actionable 记录，新门未误伤任何历史样本。」该句只在"已观察到的目标 drain actionable 记录"范围内成立，按 W-1 更正为：四轮 offThread=0 仅证明这四份 Raw 的目标层 actionable 记录全部位于唯一 opener 线程，不证明整个真实 Session 中不存在第二目标线程；且在 A1-R3 之后，0 还要求"唯一 opener 存在"这一前提，否则字段为 null。原句按 D2 保留、不回改，本段仅指明其失效范围。

S-11 相对 W-3 的偏差（逐条）

S-11b 站点构建与新增归档

• 新增归档快照（C2，既有 docs/ 归档不回改）：docs/architecture/perfowl-p4-build74-phase2-lead-decision-and-diagnostic-plan-2026-09-24-a1r3-update.html，由本文件渲染。
• site/devlog/index.md 按 C2/C3 更新时间线顶部节点、八阶段总计划 P2 行与未关门门禁，不删除任何历史节点。
• 构建结果与原始输出见文件末尾的 ### A1-R3 站点构建与归档结果（本段成文于构建之前）。

S-12 遗留项与门禁状态

• A1-R3 E2 返工完成，但 Implementation AI 不自判 PASS；由 Owner 转交 Lead 独立复验。
• A1 新包 E4 = NOT RUN：本批未构建新包、未执行真机，不以历史回放冒充 E4。
• 签名 / 公证 / stapling / 独立安装 / 包 SHA-256 = partial：本机无 Developer ID Application 身份、无 notarytool 凭据。冻结 Build74 测试包 SHA-256 仍为 3a557cc0c0c666f90736c34fa9b633adb646a92a55ecfdae095c41f349a5dbc1。
• 未复现项：test_sample_cadence_remains_stable_and_does_not_multiply_with_concurrent_sources 在本次负载档位未复现（两树 7/7 PASS），其负载敏感性未被本批证据排除。
• 未并批：B1/B2/B3、Device Network、Phase C、role 标记、采集配置。
• Total / 质量 / 阶段覆盖仍冻结；totalDurationMs 继续不发布；B0 的 E1 观察仍不授权 B1。

A1-R3 站点构建与归档结果

• 归档快照入库后执行 cd site && npm run build → 退出码 0、0 死链，原始输出（关键行；全日志 67 行）：

> python3 scripts/metric-knowledge-gate.py && bash scripts/sync-archive.sh
[metric-knowledge-gate] WARN: 42 content-risk audit hit(s), manual confirmation required
[metric-knowledge-gate] PASS: 66 Registry contracts, Canonical ownership, versionless governance, ten-element markers, sidebar, overview, knowledgeRole governance, and rendered visual coverage
[sync-archive] docs/ -> public/archive/ (269 files)
✓ building client + server bundles...
✓ rendering pages...
build complete in 96.53s.

• WARN: 42 content-risk 为既有 site/knowledge/ 内容告警（A1-R1/A1-R2 批次已披露，本批未触碰该目录），门禁最终判 PASS**（66 contracts）。
• site/devlog/index.md 已按 C2/C3 更新时间线顶部节点、八阶段总计划 P2 行与未关门门禁，未删除任何历史节点。
• 生产环境内容核实（HTTP）在推送部署后执行，结果见交付汇报。

Lead Independent Acceptance · A1-R3（2026-09-25 · E2）

裁定：A1-R3 最小返工 E2 PASS；Phase 2 A1 的代码/离线证据门 E2 PASS；新包 E4 = NOT RUN，分发工程 = partial，整体产品验收仍 OPEN。 此裁定不发布 Total、不升级质量或阶段覆盖，不授权 B1/B2/B3、Device Network 或 Phase C。8d165a5c4cead9043988faed565a0b6924c00515 的 parent 为 f04ac31acb5f682319b927a87ef25647b0e15ab4，仅 5 个本批路径；未碰受保护的原始 trace 与并行 WIP。

Lead 独立核证

1. 源与反例：完整检查 launch_trace.py 的 offThreadTargetRecordCount 写入路径；诊断块默认 None，批次失效/截断早退保持 None；有效且目标层空时为 0；唯一 opener 存在时按其 TID 在锚点/设备 tick 判决前统计，故原 W-1「A opener + B closer，缺 anchor」不再错误报 0。G4 配对、身份门、容量阈值与冻结主报告路径在本次产品 diff 中未改。独立复跑专项 72/72 OK，涵盖 W-3 正负例和既有 G4 反例。
2. 当前 HEAD 的 Raw 重放：Lead 用当前工作树的 derive_launch_trace_session 直接读取四轮只读 Session 副本，逐轮与实施归档的诊断字段比较一致：S2、r1、r2 的目标层均空，offThread=0、链未闭合；r3 为 target=3/accepted=2/rejected=1/offThread=0 且诊断链闭合。四轮 totalDurationMs=None；该重放不产生新 E4，也不把诊断链提升为主报告 Total。
3. 回归与资源：Lead 在当前 HEAD 非并行跑 Sidecar 全量 1049/1049 OK（122.764s）。查验实施方保留的同环境交错原始 JSON：无负载两树各 4/4；负载下 flood fairness 基线 0/3、修订树 2/3，显示既有负载敏感性而非稳定 ship-only 回归；cadence 负载失败仍未复现，不声称其绝对不存在。§6 归档的统一字节码状态性能 24/24 在预算内；混合缓存态的失败结果保留，消融证据说明缓存状态是主要混杂因素，但 r3 frozen→ship wall +188.325ms / 预算 193.1ms，余量仅约 4.8ms，E4 与后续版本需持续关注，不以单次低于阈值声称性能大幅改善。
4. 文档口径更正：Implementation Update S-4/S-10 中「四轮 0 均以唯一 opener 存在为前提」「0 要求唯一 opener，否则 null」表述过窄，与其代码及测试的有效空目标层 → 0分支不符。准确契约是：有效且目标层空 → 0；目标层非空且唯一 opener 可识别 → 按 opener TID 精确计数（可为 0）；目标层非空但 opener 不唯一/不存在，或批次失效/截断 → null。 S2/r1/r2 的 0 属第一种，不证明存在 opener；r3 的 0 属第二种。本段只追加澄清，不回改历史表格与测试数字。此为记录措辞瑕疵，不影响已复测的代码行为，但后续知识/报告不得复用错误简写。

下一门禁

A1 E2 已关闭，E4 未关闭。 下一动作是独立新包构建/签名/公证/stapling/安装与 SHA 校验后，按已冻结的 §5 真实设备正向闭合链、真实负向形态、Raw 哈希/报告一致性、活线与最终主字段对照执行 E4。当前环境缺 Developer ID 身份及 notarytool 凭据，应维持 package=partial、E4=NOT RUN，不得用旧 Build74 包、离线 Raw 或站点部署代替新包验收。E4 若出现不同于历史的形态，按事实记录并回 Lead 复核，不为追求成功率构造 Total；Network 独立批、Phase C FROZEN。

Implementation Update · 新包与真机 E4 采集（2026-09-25 · Implementation AI · E4 形态采集）

> 关联方案：本文件 §5 真机 E4 合同、§6 交付门禁。基线 f3c9b73d20c39e70aa39243be0ba9a4ee2a19688（本轮产品代码零改动，只新增文档与本机私有采集工具）。本轮执行「新包构建/签名/公证/staple/独立安装」与「按冻结 Build74 UI 配置采集真实正/负向形态」。实施方不自判 E4 PASS；结论按事实记录，请 Lead 独立验收。

前置事实修正（推翻本文件此前的环境判断）

本节之前的历史结论「当前环境缺 Developer ID 身份及 notarytool 凭据」经本轮实测不成立，属事实修正（不改写历史段，只在此追加更正）：

S-1 新包构建与分发链（实测全链通过）

• 构建：PERFOWL_BUILD_NUMBER=83 + Developer ID 身份 + PERFOWL_DISABLE_SWIFTPM_SANDBOX=1 ./scripts/build-app.sh，exit 0（约 6m32s），CFBundleVersion=83，x86_64。
• 首次公证 Invalid：322 条 The signature does not include a secure timestamp. 根因是 MacApp/scripts/build-app.sh 对嵌套二进制使用 --timestamp=none。本轮未改该产品脚本（永久修复属 Lead 决策范围），改为对 Contents/Resources 下全部嵌套二进制逐一补 TSA 重签并对外层 --deep --timestamp：实测 signed_files_checked=323、missing_timestamp=0。
• 重新提交公证：Accepted（jobId 874d2772-528b-4872-8ce4-50bebab81030，issues: None）；stapler staple + stapler validate 通过；spctl 由 rejected / Unnotarized Developer ID 变为 accepted / source=Notarized Developer ID；codesign --verify --deep --strict 通过，签名链 Developer ID Application → Developer ID CA → Apple Root CA、flags=0x10000(runtime)。
• 交付容器：MacApp/dist/Perfowl-Build74-Phase2-f3c9b73-x86_64-notarized.zip，109,842,490 B，SHA-256 22ab40b54f1e9fddd381715851383262f11608c1ad4b00a24ef25d9cd12c750e（提交公证用包 109,837,729 B / 15b68ea52be9a6530e1bd79e20a99370c19a55720598a8bebde392523f79a15c）。
• 独立解包目录复验：版本 83、--verify --deep --strict 有效、spctl 为 accepted / Notarized Developer ID、stapler 通过、内置 Collector Core 存在（12,413,616 B）；并以该副本完成一次启动冒烟（自动拉起内置 pymobiledevice3 做设备发现，进程已清理）。App 自身既有会话库（72 个既有会话，最新 mtime 2026-09-24 14:21）未被触碰。

S-2 真机采集（新包会话 16 轮，冻结配置逐字段一致）

• 入口：使用新包内捆绑的核心按 App wire 序列 prepare_app → start → stop 驱动，冻结 CapturePlan（12 条 startup 指标 + capturePlanHash f9f54077…）在两条命令上回显一致；PERFOWL_FRAME_FILTER_EXPERIMENT=exact-debug-id 显式透传（代码默认 subclass 不是冻结形态）。每轮两阶段：stream（活线 closeout，只 seal + manifests、不重扫 Raw）→ CLI finalize（唯一产出带诊断块 final 报告的路径）。
• 会话规模：16 轮新包会话（早期 5 轮因分析工具曾就地覆盖 final 报告而移入私有归档 discarded/，不参与本段判据；追加批次 10 轮全部通过只读自证）。
• 机械断言（out/e4-rounds.json）：

• 形态分布（原始字节分类，official final 报告口径）：target-actionable-no-closure 13 轮、no-lifecycle-records 3 轮；非零拒因只有 no-opener（13 轮）与 thread-binding-unknown（13 轮）。drain 状态 8 轮 timeout / 8 轮 quiescent；一轮一 Session，时长 11.1–71.0 s。
• 窗口级原始字节扫描（out/lifecycle-scan-*.json，复用包自身 KD_BUF/_stop_drain_lifecycle_offsets/_lifecycle_actions）：
• 13 轮：begin:Initial Frame Rendering（opener）只出现在 startup-lifecycle|active 窗口，drain 窗口只有 closer 与普通记录 ⇒ 结构上必然 no-opener；
• 4 轮：整份 Session 内不存在 opener 记录（closer-only；其中 3 轮 drain 窗口仅 766 B）；
• r3 对照：opener 出现在 frame-continuation|post-stop-drain（唯一一例）⇒ 可闭合。
• 未取得的形态：§5 要求的「至少一个新包真实正向闭合链」未取得。其余量缺口见 S-3。

S-3 未取得正向链的可复现机制与量化缺口

诊断（launch_trace.py）只把落在 frame-continuation|post-stop-drain 块内的 opener 计入账本，因此正向闭合链的充要条件是：opener 记录在主机的到达时刻晚于 stop-drain 切口。切口 = 启动完成 handoff，其位置由核心自身记录的两项推出：completionWaitStartedAt = 首个 drain 块主机时刻 − startupCoreProfileCompletionWaitElapsedSeconds，而切口 = completionWaitStartedAt + elapsed：

• completed / completion-observed（12/16）：切口跟在 opener 自身到达之后 ⇒ opener 必落在 active 窗口，结构上不可能闭合；
• timed-out / startup-completion-grace-expired（4/16）：切口 = grace 截止（4.0 s）；但这 4 轮的 opener 在整份 Session 内都不存在 ⇒ 无端点可闭合。

逐轮量化（out/opener-deadline-table.json）：

设备时钟（machTicks）对照排除了「App/设备行为不同」这一解释：新包各轮 code12（0x2b870030）距 end:sceneWillEnterForeground（0x2b8704e4）为 ≈660–743 ms，r3 为 ≈743 ms，即设备侧发射时序基本一致；差异在主机侧交付滞后（writerQueueWaitMaxMs：新包 0.73–218.97 ms vs r3 284.80 ms）。故正向形态需要的是主机/传输滞后把 opener 的到达推过 grace 截止，而不是改 App、设备或采集配置。

本批未采用任何「制造」手段：未人为加压、未改 drain 时限、未改 kdf2/csd/frame filter/role/源过滤、未改 UI 录制配置、未重放离线 Raw 冒充真机轮次。追加 10 轮的唯一目的是在同一冻结配置下多取样，判据逐轮回填。

S-4 相对方案的偏差（逐项）

1. 采集入口等价性：§5 要求「只使用冻结 Build74 同形态 App UI 入口作为对照」。本轮用新包内捆绑核心 + 复现 App wire 序列（prepare_app/start/stop、同一冻结 CapturePlan 与实验档位）作为 GUI 等价入口；--connection-route usb 被接受，但 provider 仍报 route: tunneld / tunneld-native-rsd（与 r3 相同）。该等价性是否可接受由 Lead 裁定；本轮未使用 CLI 默认配置（其 kdf2=[0xFFFFFFFF]/csd=128 形态按 §5 属 INVALID）。
2. 会话时长：新包轮次 11.1–71.0 s，r3 为 25.29 s。时长不在 §5 冻结字段清单内，且 CoreProfile 段在 ~6–12 s 内已完成 drain，故未作为冻结配置偏差计算；此差异如实保留。
3. 私有归档新增 discarded/：derive_launch_trace_session 会把结果写回 launch-trace-report.json；早期分析工具曾直接在会话目录内调用它，导致 5 轮会话的 live 报告被 final 报告覆盖（受影响的 ca8596bc/1b9e0980/1b56b2a4/1849d892/9a2edfc1）。这些轮次已隔离、不纳入本段任何数字；工具改为隔离 staging 树（真实字节复制）后，追加轮次全部自证 replay_wrote_into_session=false。
4. build-app.sh 嵌套签名缺 TSA：未修（永久修复点留 Lead 决策），本轮以补签方式完成分发链；该缺口对下一轮构建仍然存在。

S-5 独立回放一致性门禁的修复（工具侧，非产品侧）

原分析工具在隔离 staging 树中对大文件使用符号链接，而产品自身的 Raw 回放校验会拒绝「manifest 的 coreProfileBlobFile 解析到 Session 目录之外」的路径，因此每一轮独立回放都以 ReplayValidationError 失败，replayMatchesShipped* 退化为恒 false（不是产品报告不一致）。改为真实字节复制（不用硬链接，避免共享 inode 被就地写坏）后：16/16 replay_vs_shipped_diag_equal=true、replay_vs_shipped_main_equal=true，且 pristine 哈希复算证明未写回会话。结论：新包 shipped final 报告可由当前工作树的独立回放逐字段复现。

live_vs_final_main_equal 仍为 false，差异集合逐轮仅为 decodedRecordCount（例：1855341 → 3668220、2100633 → 2785338）——live closeout 只统计其已解码量、final 重扫整份 Raw，属既有设计；两列原值均在 out/e4-evidence-table.md 中并列保留，未作裁剪。

S-6 遗留项与门禁状态（实施方不自判 PASS）

• A1 新包真机 E4 = 未取得正向闭合链 ⇒ 不满足 §5 的 PASS 前置条件，状态记 partial，判据交 Lead。 缺口是一个「opener 主机到达晚于 grace 截止」的真实会话；当前 16 轮均为早到 1.7–4.4 s 或无 opener。
• 其余 §5 前置项本轮已齐备：真实负向形态 16 轮、原始哈希/报告一致性 16/16、活线与最终主字段对照齐备（含 A-S 活线无块 / final 有块）、新包签名/公证/staple/独立安装与包 SHA 真实可查。
• §6 效率门禁：本轮产品代码零 diff，无新增扫描/等待、无性能变更，故不产生新的前后性能对比；上一批次的 §6 证据与结论继续有效。
• 未关闭的工程缺口：build-app.sh 嵌套签名缺 TSA（永久修复点）、--connection-route usb 下 provider 仍走 tunneld-native-rsd 的路由表述差异（与本方案冻结形态一致，供 Lead 裁定）。
• 交付物（本机私有归档 ~/Perfowl-Local-Archive/build74-phase2-a1-e4-20260925-0837/）：out/e4-rounds.json、out/e4-evidence-table.{json,md}、out/opener-deadline-table.json、out/boundary-<alias>.json、out/lifecycle-scan-<alias>.json、evidence/notarytool-*.{log,json}、install-verify/、discarded/、scripts/。共享工作区未跟踪文件与受保护 trace 全程未动。