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 流扫描。
4. 未证：设备丢失 marker 的 arg1 含义、TID 重用在四轮之外的分布、drain 第二条 closer 的真实语义、设备 tick 与主机 stop 时刻同轴关系、T2 双时间轴 4.38 倍跨度的原因、与 Apple Instruments 同事件端点的一致性。sourceQuality.lossFree 只覆盖主机活线队列丢失；设备丢失 marker 是丢失片段/标记，不是被丢事件条数。
5. 纠错：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 均不变。