核心资产重构裁定（独立裁定 v1，2026-09-12）

现状注记（2026-10-04）：本文的裁定使命已被后续演进实质承接——裁定①（核心不重写）被 MoonBit 迁移的绞杀者模式实践超越（同仓重写已推进至 S8 收官，Rust 区冻结为 oracle 待退役）；D5 工具链 Go 化已于 2026-09-18 收官；D6（JIT 存废重裁）已由总计划 F-3 裁定承接（JIT 倾向不搬，模板 JIT 可搬 MoonBit、S9 复核）；§14 JIT trace P0 静默错值为 Rust oracle 冻结区存量缺陷（baseline/jit_nested_counting_loop*.c 红锚在库），随 Rust 区退役自然消失。本文保留为裁定过程与判据体系（J1~J10）的第一手档案，scripts/core_asset_verdict/ 证据与 native/tests/CORE_ASSET_VERDICT_FAILURES.md 台账仍被防线引用〔——已失效：两者均随 2026-10-05 删区退役（探针对象为 Rust 冻结区），git 历史可回溯；2026-10-07 回灌〕。

本文是什么：对 统一整备路线图.md（U0~U7，排期权威）之上"核心资产要不要重构、 重构什么、按什么边界与顺序"的重新裁定。它是决策文档，不是施工计划——施工仍以路线图为准， 本文只增补/修订边界、判据与证据。

本文不是表态：每条结论都给验证方式与反证条件；文中所有数字都是本次会话在 master@8236bc5（工作区含未提交的文档改动）上实测得到的，脚本与原始 JSON 落在 scripts/core_asset_verdict/（已随 2026-10-05 删区退役——证据 JSON 见 git 历史 / tag rust-oracle-freeze）。

验证方式标注（强制）： [动态实测] = 本次会话实际运行并记录；[静态亲读] = 本次会话直接读码/读文档确认； [agent 报告，未独立复核] = 引用既有模块审查结论；[未验证] = 未取得证据。 禁止把 [agent 报告] 当 [动态实测]。

与既有裁定的关系：本文不推翻 三语化整备审计计划.md §5.0 的三层裁定与 路线图 §0 的合并裁定（裁定①②③④），而是在新证据下：① 修正裁定①的证据基础与适用范围 （原表述"662 影子用例的逐字节行为锚是最硬资产"经实测只对"批处理 stdout"面成立）； ② 把裁定②的边界从目录改划为设计域；③ 新增第⑤层（防线口径自身）； ④ 给"整体重写"（候选 D/E）写下可测量的触发门槛（当前未触发）。

0. 一句话裁定

核心（编译管线五段 + VM opcode 语义）不重写——但这条裁定过去是拿"662 全绿"当证据的，那个 证据经本次独立通道实测不合格；真正支持它的是本次新增的独立证据（1000 例随机三路差分零分歧 + 按切面突变 margin 32~559）。同时，"不动核心、只跑 U0~U7"（候选 A）也被实测否决：交互出口 （serve）上存在越过程序末尾 seek 即 panic** 的新 P0，且它不在 U0~U7 任何批次里；教学内容、 可视化、步级 payload 三个切面的突变 margin = 0~1（M2/M6 零检出），即产品价值所在的面 当前没有防线。**

因此本次裁定的落点是：B（防线换代）+ C（资源与参数域接口级补设计→域内局部重写）并行先行； D（整体重写）与 E（换载体）不触发，且各自的门槛写成可测量的数字（§Q4/Q6）。 顺序上 B 必须先于任何交互切面重写——因为在 B 建成之前，没有任何人能判断交互切面的重写 是变好还是变坏（现状是"没有 oracle"，不是"oracle 说是好的"）。

1. 证据清单（本文全部论断的原始来源）

1.1 母文档（结论以其为准，本文只做增补/修订）

1.2 本次新增的实测（脚本可复现；原始 JSON 同目录）

测量工具说明（诚实标注）：路线图 U0 要求"psutil 独立测量"，本机 pip install psutil 失败 （离线）[动态实测]，改以 ctypes 直接调用同一 API（psapi.GetProcessMemoryInfo，见 winmem.py）——仍是驱动侧独立测量，且与既有 scripts/replay/debug_p3_leak.py 口径一致。 不信被测代码自报这一条未被削弱。

2. 核心张力 T1~T5 的正面处理

T1 换语言没有换来生命周期设计 —— 成立，且证据链完整

推论：正确切面不是语言层、也不是整体 yes/no，而是哪些域缺少设计。本次把"缺设计"从 unified/ 扩展到四处（见 §Q1 的表与 §Q5 的边界重划）。

T2 防线与被测对象同源 —— 部分成立，且本次实测给出了同源性的量

工作记录20260912_突变测试.md 已证"判定逻辑可信"（3/3 检出）。本次把测量推到切面维度：

[动态实测：mutation_facet_test.py，每个突变 cargo build --release → 影子 → cargo test → git checkout 还原；all_files_reverted: true，还原后影子复跑 643/3/16 绿]

读法：防线不是纸糊的（M3=32、M5=559 说明批处理正确性面被密集锚住），但防线强度与 "产品价值所在的面"完全错位——教学标注 margin 1、诊断文案 margin 1、可视化四状态 0、 步级兜底标注 0。这正是 T3 的定量版本。同时它也给出 T2 的答案：同源性没有让防线失效， 让防线失效的是切面选择。

T3 防线切面与产品价值切面错位 —— 成立，且已量化

[动态实测：test_facet_census.py（810 个 #[test]，按测试体引用 API 归类）；影子侧的 0 由驱动 源码决定——analyze_diff 只比较 stdout.strip()，[静态亲读]]

规模侧的证据（同样重要）：

• 662 用例行数：中位 9 行、均值 18.3、p90 50、最大 122；≤5 行 296 例。(case_census.py)
• 662 用例真实步数（逐个跑 vitro_cli unified）：测得 652 例，中位 115 步、p90 1938、 p99 13916、最大 135835；≥10k 步仅 11 例、≥100k 步仅 1 例。(measure_steps.py)
• 语言面覆盖形状：printf 660、字符串字面量 655、循环 306、指针 295、数组 292， 而 unsigned 仅 26、位运算 23、函数指针 9、union 7、file_io 10、变参 2、math.h 2。
• 带 .in 标准输入的用例 34/662。
• 引擎 max_steps 默认 1000 万——压力用例规模与泄漏量级差 2~4 个数量级。

→ "662 是最硬资产"只对批处理 stdout 面成立，且这一面的覆盖是"窄而密"（中位 9 行/115 步）。

T4 使用证据缺失被误读为"没问题" —— 成立

• 三出口的外部消费者只有一个：SharpTutor，锚定 10591ad（本仓库已推进 4 个提交） [静态亲读：下游需求处置回执.md 头部]。
• wasm32 出口：只有"零修改构建 3.75MB + C API 全链路冒烟"，无运行时行为实测 [静态亲读：AGENTS.md；本次 [未验证]]。
• 没有任何会话量/用户量/语料量记录。→ 按 T4 要求，无使用证据的资产默认高风险； 本次据此把"交互出口（serve）"的风险等级从"U2 附带项"提为"独立 P0"（§Q1）。

T5 真实使用者路径与防线路径不一致 —— 证据缺口，列第一优先

• 仓库内没有任何真实学生失败记录：docs/current/04-标准库与防线/学生错误用例集.md 是 假想清单（"预期诊断"由作者写定），且 grep 全 native/ 无任何测试引用它 [动态实测 + 静态亲读]。
• 真实用户试用计划过、从未产出结果：ROADMAP_2026_Q3.md C2.1"邀请 3~5 名真实用户 (学生/教师)"、C2.x 明写"需要真实用户，当前无法由 Agent 独立完成"； ARCHIVE_M7_BETA_READINESS.md §4 有"试用计划/反馈收集点/通过标准"，但仓库内 不存在 CPP_BETA_FEEDBACK.md 或任何等价产物（glob 实测：*BETA* 只命中该归档件）。
• ⇒ "复现真实学生失败路径 = 0 条"，原因不是我不会复现，而是输入不存在。 按任务要求，该证据缺口列 Q7-G1 第一优先，并在此明示：本文所有关于"教学生会怎么用" 的推断都是 [未验证]，不作为任何裁定的依据。
• 2026-09-12 更新（本裁定交付后获得新输入）：用户补交了前端期 2 条真实现场， "输入不存在"不再成立。复核结论（独立实测 + clang 对照，详见 native/tests/CORE_ASSET_VERDICT_FAILURES.md）： ① char *p 参数上 p += 2 被误拒（E3045）——已修，且被影子可靠接住（9 个用例全部有真 golden）； ② 单条声明内混合"不定长数组初始化 + 标量 + 指针"被误拒——已修（2026-06-07）， 但该形态在全防线语料中覆盖 = 0，修复只被特性级用例锚定 → 新登记 D-2026-09-07， 并已补用例 baseline/multidecl_array_pointer_mix.c（自带 <stdio.h>，有真 golden）； ③ 同批现场还暴露 E3053 误报（char 数组用字符常量初始化报 N 条"可能丢失精度"）—— 当前仍存在，新登记 R-2026-09-12；④ 覆盖率 >100% —— 属 code_line 跨文件全局行号的 协议缺口，已在 docs/spec/STEP_PAYLOAD_SCHEMA_V0_1.md §8 #9 补记"消费方可见后果"。 方法论点：这 4 个问题中只有 1 个被"事后补影子测试"这条链可靠接住（1 个形态零覆盖、 2 个结构上不可能接住），即该处置方式对本次现场的有效覆盖率约 1/4—— 这为 §T3"防线切面与产品价值切面错位"提供了样本级证据，也为 Q5-B（防线换代） 提供了"按现场形态而非特性清单建语料"的具体要求。G1 仍为 P0 第一优先 （2 条 ≪ 30 条，且两条均为回忆提交、无系统留痕入口）——2026-09-13 更新：该 "一次性凑样本"判据已废止，G1 拆分改判为 G1a（真实通道滚动等待，不阻塞 CS 系列）+ G1b（合成靶料，随 U1 交付），见 §9；缺口由开放台账承接，不再阻塞。

3. Q1 分区裁定表

判据栏一律给"本次证据"；反证栏给"什么证据会改变此裁定"。 "不写代码的域"与"写代码的域"同等对待——本表最后一行是防线自身。

边界重划（这是本次裁定对既有②/③最重要的一处修订）： 既有裁定用目录划界（"native/src/unified/ 进重构区"）。实测显示同一病理 （边界/参数域从未被设计）跨目录存在：

1. unified/engine.rs —— 窗口/重放边界（seek 距离无约束、split_off 无防御）；
2. unified/engine.rs + session_api/serve —— 参数域（end=-1、step 越界 → 一条 JSON 杀死会话）；
3. vitro_vm 累积状态 —— regions/trace/output_chunks/vis_event_queue 无预算；
4. unified/collector.rs 的 payload 生成路径 —— 四状态/标注的正确性无防线（margin 0）。

⇒ 重构区应按"哪个域缺设计"划，而不是按目录划：统一命名为 「生命周期与参数域（Lifecycle & Parameter Domain）」，含上述 4 处；unified/ 只是其中一处。

4. Q2 判据体系 v2（可机检）

既有四条升级判据（多真相再现 / 修 A 坏 B / known_issue 趋势 / 同子系统 ≥2 次 GB 级事故） 全部落在代码语义域与资源域，对"防线外切面"无效——这正是本次发现 seek panic 与 margin-0 切面的原因。新增判据全部给阈值 + 检测命令 + 当前实测值：

J3 的 margin 定义（与 U7 一致，本次给机器化口径）：margin = "能独立拦截该语义突变的 判定数" = 影子分类变化用例数 + 失败测试数。M2/M6 的 margin=0 意味着： 把指针四状态或默认标注整体改错，现有 662+891 条防线一条都不会红。

5. Q3 行为债量化（实测，非脑测）

5.1 "662 用例里有多少是外部可推导的"

clang_oracle_audit.py 不读报告、不读缓存，对 662 例逐个重跑 clang：

这 22 例在影子门禁口径下全部算"通过"（oracle_free_classification.py 直接按 analyze_diff 的真实分支复算）：

既有文档的口径是"豁免通道 ≈6/662"（KNOWN_FAILURE_CASES 2 + @category *bug* 4）。 实测的"零比对通道"是 21/662（3.2%），约为其 3.5 倍，且其中没有一例被文档登记。

可救性（oracle_gap_probe.py，只在临时副本补头文件、不改动用例文件）：

• 补 #include <stdio.h> 等头文件后，13/22 恢复"clang 可编译可运行且 stdout 与 Vitro 一致" ——即这 13 例本可以成为真 golden，只是因为驱动对文件用例不注入头文件 （run_with_clang 只在 path is None 时走 make_clang_header）[静态亲读 + 动态实测]。
• 9 例仍然失败：其中 e2_include_cycle/e3_static_assert_fail 是设计上双侧都失败 （用例注释已写明），complex_number/implicit_int/variadic_macro/file_* 属 Vitro 扩展或 clang 拒绝的构造，e1_func_identifier/keyword_compat 为真实差异（后者 Vitro 接受 auto int y 等写法）。

5.2 "若按交互切面重写引擎，662 用例中真正失效、无法复用的是多少"

逐类评估（可复核的判定，不是估计）：

结论（可证伪）： "重写 = 重新欠一遍行为债"这个论证的量化基础比它听起来弱得多—— 真正"失效、不可复用"的是 22 例（3.3%）；把 3 例 known_issue 计入需重裁定则是 25 例（3.8%）； 把自我豁免通道计入风险面是 29 例（4.4%）。 行为债的真实主体不是"用例失效"，而是两件事：

1. 语义体量：native/ 共 46,516 行 Rust（本次实测），其中管线五段 + VM 执行器 = typeck 8176 + vm 7837 + codegen 5917 + parser 4455 + lexer 3126 + runtime 1606 + ast 1329 = 32,446 行；按历史迁移实测速率（8,057 行 / 4~5 周）线性外推 ≈ 6~9 人月， 且 C++/模板/容器面比当年更大；
2. oracle 的窄带：640 条 golden 的中位规模是 9 行 / 115 步， unsigned 只覆盖 26 例、函数指针 9 例、union 7 例、file_io 10 例—— 重写即使 100% 复刻这 640 条，也只证明教学子集窄带内一致。

⇒ 这个反直觉的结论正是本次裁定把 B（防线换代）排在重写之前的量化依据： 反对重写的理由不应再说"债太重"（债只有 ~4% 的用例损失），而应说"现有的锚不足以验收任何 重写"。

5.3 资源域的量化（本次实测，含对既有结论的两处修正）

5a. Q7-G6 复核定论（2026-09-14，四点直接采样关闭）

方法：scripts/core_asset_verdict/regions_growth（serve 会话 config.set max_steps 提预算 → churn malloc(16)+free ×N → memory.regions 的 region_counts.heap 直接读条目数，不经 RSS 代理；通道失效 fail loud 拒判）。release 构建，单轮 （裁定验收线"×3 次"的四点增长曲线已由机制闭环 + 三源交叉印证替代，见下）。

定论：分段饱和模型，§5.3 与评估报告两侧既有证据均为真（观测区间不同）：

1. 推进期（条目 < 隔离预算 ÷ 块大小）：条目随 N 线性增长——评估报告的 "14B/次"（条目 MemoryRegionData 的字节成本）在此段成立；每次操作扫描条目数 随 N 涨，时间含 O(N²) 分量——P-1 的"×5 规模 ×10 时间"跨段观测成立；
2. 饱和期（DEFAULT_QUARANTINE_BUDGET = MEM_SIZE/4 = 256KB 填满后 FIFO 驱逐 + free_list 地址复用）：条目恒定 16387（= 256KB ÷ 16B + 少量活跃块， 100k 与 1M 两点逐位相同）；每次操作扫固定 ~16k 条 → 时间 O(N) 线性—— 裁定 §5.3 的"≈线性"（其三点 50k~200k 全在饱和段）与"峰值平坦 8.6MB"成立；
3. 饱和机制是设计内行为（隔离区决议 §3 的 FIFO + 预算驱逐），非静默丢条目 ——复用路径的 is_freed 复位 + freed_logs retain 清理保持 UAF 检测窗口 语义完好（memory.rs 复用分支亲读确认）；
4. U2#2 重构判据据此修正：原方案"已释放条目归并 freelist 摘要 + 上限"的 收益有限（稳态 ~16k 条 × 条目字节 = 数 MB 常驻，天然有界）；真正痛点是 每次操作的 ~16k 条线性扫描（free 的 iter().find / malloc 复用的 iter().find / realloc 的 retain）——重构方向收缩为 addr 索引化 （HashMap<addr, idx> 或有序索引，消 16k×N → O(1)/次），隔离区语义与 复用语义差分用例（U2 验收线既有）作为不破坏判据。U2#2 自本节起解锁开工。

6. Q4 候选方案对比（A~E）

E 的对照要点：E 节省的是最难但已被证明可用的那部分（§Q3-E4 三路差分 1000 例零分歧）， 砍掉的正是唯一没有被验证过的那部分（步级 payload/margin 0）。方向与 T3 的证据相反。

7. Q5 选定方案的分阶段计划（B + C）、回滚点与中止条件

2026-09-12 多轮收敛更新：本节是域内计划（B 防线换代 + C 资源与参数域）。 跨域执行顺序、门禁、**新增的第五域（防线自身）**与工具链语言迁移见 §13； 两者若有冲突，以 §13 为准。

7.1 边界与接口冻结策略

1. 先冻结"被消费的语义"，再动结构：spec/STEP_PAYLOAD_SCHEMA_V0_1.md 已冻结字段集； 本次补冻参数域契约（每个 serve/capi 方法的合法域与越界响应），作为 J1 的判定依据。
2. checkpoint/snapshot 的 wire 语义当前未进 schema —— C 阶段若需变更，必须先走 schema 版本化（v0.2 激活轨道已在 unified/contracts.rs + 冻结测试里，复用该机制）。
3. cap 与隔离区语义冻结：堆有界隔离决议.md 的三色堆语义是 C 阶段的 不可破坏项，重构前先写差分保护用例（U2#2 已有要求，本次给具体验收）。

7.2 分阶段（每阶段含红→绿、回滚与"过渡期不变瞎"保障）

7.3 中止条件（"何时必须放弃重构"）

1. P2 连续两轮迭代仍无法把 seek 斜率压到 64B/步，或压缩后核心语义出现 ≥1 条新分歧 → 停止该域重构，退回"显式限制远距 seek"的契约（把做不到的明说成限制，并写入 capabilities/error_catalog），同时重开候选 D 的评估。
2. P1 发现"步级 payload 无法定义正确性判据"（即业界/教学组都拿不出独立 oracle） → 停止"以 payload 为重心"的防线换代，退守 J1/J5/J8（参数域、资源、panic）三项可判定的门禁。
3. 任何阶段发现 P0 级新事故（GB 级资源事故 / 静默错值扩散到核心语义）→ 立即冻结该阶段， 按事故归档制度留痕后再决定继续或改判。

8. Q6 改判触发条件（对"核心不重写"这条裁定，全部可测量）

本文未采纳"整体重写"，因此本节是裁定①的可证伪条件清单。任一条件成立即须重新裁定。

R1 是最关键的一条：它把"要不要重写核心"从立场之争变成可执行的实验 （成本：一次夜间跑，样本量已写明）。本文据此建议把 R1 作为 U7#1 的验收线， 而不是"连续 7 晚零未知差异"这类无法反驳的软表述。

9. Q7 证据缺口清单（每条含实验、样本量、判据）

允许"证据不足"，不允许以"证据不足"结案。以下 8 条是当前无法判定的全部问题。

本次已自行关闭的缺口（留档，避免重复开单）：

• "exemption 通道有多大" → 22 例，21 例零比对（§5.1）；
• "seek 重放到底多大" → 1.2~2.3KB/步，10M 步外推 12~23GB（§5.3）；
• "662 的规模 realism 如何" → 中位 9 行 / 115 步（§T3）；
• "核心语义在随机输入下是否稳" → 1000 例三路一致（§1.2-E4）。

10. 红→绿用例清单（CI 必须先留痕 FAIL，再修）

纪律：以下每条在修复前必须先在 CI 产生一条 FAIL 记录（用例编号即本节编号），修复提交 必须引用编号。禁止把它们改成 skip/known_issue，禁止修改任何测试预期值。 本文所有条目在本次会话中均已实测为红（原始输出见对应 JSON）。

11. 交付前自检（逐条回答）

1. 每条结论标注验证方式了吗？其中多少依赖 AI 编写的用例？ 是，全文逐条标注。质量论据不依赖 AI 用例：判"核心稳"用 1000 例随机生成器 + clang + 自写 语义模型（§E4）；判"防线强/盲"用突变 margin（§E3）与驱动侧资源测量（§E6）。 AI 编写的 662 用例只在描述现状（覆盖率、oracle 缺失）时被统计，未被当作质量证据。
2. 除影子防线外有几个独立验证通道？各照到什么切面？ 5 个：① clang 子进程 golden（外部实现而非 AI 用例）→ 语言语义/批处理；② 自写随机程序生成器
   • Python 语义模型 → 三路语义差分；③ 突变注入 → 语义可测性与 margin（逐切面）； ④ 驱动侧 psapi 资源测量 → 宿主资源；⑤ 随机交互序列 + 畸形 JSON fuzz → 交互出口/参数域。
3. 实际测了哪些"想不到的场景"？怎么生成的？ 越过程序末尾的 seek（随机交互序列随机命中，非预想）； payload.get end=-1（畸形词表）；随机交互交错（step/seek/payload/breakpoint/reset）； 1000 例随机程序（生成器，含 unsigned/位运算/struct/malloc 链表）； 500k 步远距 seek；1M putchar；30 条畸形 JSON。生成方式：随机生成器 + 随机序列 + 突变。
4. 交互切面覆盖密度？有使用证据吗？ 影子 0/662；工作区 30/810 集成测试（3.7%，其中 8 条只查 schema 形态/词汇闭包）， 输入程序为十几个小程序（5 个交互测试文件内联原始字符串 21 处，含 JSON 片段）， 对比批处理面 662 个。使用证据：1 个下游消费者（SharpTutor，锚定 10591ad），0 条学生记录， wasm 出口无运行时实测。
5. 复现了几条真实学生失败路径？若为 0，为什么？ 0 条。原因不是不可复现，而是输入不存在：仓库内无学生实测记录， 学生错误用例集.md 是假想清单且无任何测试引用；真实用户试用计划过 （ROADMAP_2026_Q3.md C2.x 明写"需要真实用户，当前无法由 Agent 独立完成"）但从无产物。 → 列为 G1 第一优先，并声明本文不含基于"学生实际行为"的推断。
6. 说"债很重/成本很高"时的量化口径是什么？ 口径三件套：语义体量（46,516 行 Rust；管线+VM 32,446 行；按历史迁移 8,057 行/4~5 周 外推 ≈6~9 人月）、oracle 条数与规模（640 条 clang golden，中位 9 行/115 步）、 复用损失（22 例不可复用 = 3.3%，25 例需重裁定 = 3.8%）。并且明确："债"不是主论点—— 主论点是"现有 oracle 不足以验收任何重写"。
7. 如果裁定是错的，什么证据会推翻？写成可测量条件了吗？ 是，§Q6 R1~R5 全部可测量（R1 已给样本量 ≥5000 例 × ≥5 种子与判据）。特别地， R1 是关于"核心不重写"最关键的反证条件，已建议作为 U7#1 的验收线。
8. 重构方案在过渡期会不会让防线变瞎？如何防止？ 会——尤其 P2（资源域）：新引擎无外部 oracle（clang 不产生 payload/checkpoint 语义）。 防法三条：① P0 仪器先行（护栏与 RSS 门禁在动刀之前在线，并先证会红）； ② 旧引擎二进制留作参照实现，同输入双跑逐帧差分；③ 差异未归因不得放行（CI 黄牌）， 并明确"参照只保行为、不保正确"——正确性仍须由 P1 的独立 oracle 承担。

12. 状态记录

本节记录本文的历代修订历史。最新执行方案见文末 §13（多轮收敛）—— §13 与 §7 冲突时以 §13 为准；§13 内含其自身的状态记录（§13.7）。

• 2026-09-12：本文立项。基线 master@8236bc5（工作区含文档改动，未提交）。 本次新增 9 个探针脚本与 11 份证据 JSON，落在 scripts/core_asset_verdict/。 核心新发现：① seek 越过程序末尾 panic（新 P0，不在任何既有清单）； ② payload.get 负参 panic（既有 R9b，本次独立复现并给最小复现）； ③ 662 中 22 例零 oracle（21 例零比对），13 例可补头恢复真 golden； ④ 按切面突变：教学内容 1、诊断 1、可视化 0、兜底标注 0； ⑤ seek 重放斜率 1.2~2.3KB/步（10M 步外推 12~23GB），但为瞬时尖峰而非累积泄漏。 待办：① docs/README.md 索引同步（本次已做）；② native/tests/*_FAILURES.md 台账登记 （见 native/tests/CORE_ASSET_VERDICT_FAILURES.md）；③ CSharp前端引入计划.md §7 需补入本文 §7.3 的中止条件与 §Q6 的 R5 判据。

13. 重构执行方案（多轮收敛，2026-09-12）

本节位置：§6 是候选对比、§7 是 B+C 域内计划、§8 是改判条件。本节把多轮讨论 （独立复核 → 真实学生现场 → oracle 选型 → 工具链语言选型 → 性能实测 → 防线空转发现） 收敛为跨域执行顺序与门禁。与 §7 冲突时以本节为准。 不新增文档：本节就地扩充本文，避免文档数量膨胀带来的管理成本。

13.1 本节依据的新增实测（均可在本仓库复现）

13.2 新增第五域 D1：防线自身（优先于 D2/D3/D4）

理由（本节的中心判断）：§0 裁定①"核心不重写"的证据来自防线（随机三路差分、切面 margin）。 若防线自身空转，这组证据必须重新估价——一个不检查的门禁长期全绿，与"真的没问题"在观测上不可区分。

实测到的 7 个"表面正确"实例：

共同结构：全部"通过"，但通过的语义是"脚本自己没崩"，而不是"被检查的对象正确"。 根因：引擎侧有突变测试（mutation_facet_test.py，3/3 检出），脚本侧从未做过——防线自己没有防线。

对策（制度化，非一次性）：

1. 脚本埋雷验证义务（与 §4"保险丝可触发性义务"同构）：每个判定型脚本必须至少留有一条 "注入必然违反 → 必须变红"的实证记录，纳入批次验收。
2. 优先级：shadow_verify.py（唯一硬门禁）> ci_three_tier_check.py（失败台账对账核心）

   serve_smoke.py（已证实空转）。

3. 新增判据 J9 脚本可触发性：判定型脚本的埋雷记录 = 0 时，其"全绿"不得作为任何结论的依据。

13.3 五域与执行顺序

顺序的三个理由： ① D1 先于一切——门禁若空转，所有"全绿"依据失效，后续批次会在不可信地基上施工； ② W1-1 与重构解耦——性能批次不触碰引擎语义、收益最大（-20s 起）、风险最低，可与 D1/D2 并行； ③ D5 最后——Go 版脚本同样需要被埋雷验证，先跑通"验证脚本的方法"，迁移时才有等价性判据。

13.4 对 U0~U7 的修订（三处数字更正 + 一处新增）

13.5 D5 语言迁移的边界与纪律

• 核心保持 Rust 单栈：不换实现语言。依据是双重结论——上一次 C++→Rust 重写解决了内存安全 （编译器强制、无需人盯），但没有解决"缺设计"（Rust 版又泄漏两次，且都是 safe 代码的逻辑无界）。 再做一次整体重写会把 32,446 行语义债重欠一遍，而生命周期缺陷会以同样概率重新长出。
• Python → Go 的动因排序（性能排最后）： ① 消除编码类失败模式——全仓库 103 处 UTF-8 样板，且已发生三类实际事故（Windows GBK 炸中文、 \S+ 正则吞中文注释污染用例名、BOM 干扰 clang 对照）； ② 编译器成为跨上下文的纪律执行者——正是"纪律靠上下文维持就会失效"的对策； ③ 表达空间窄——Go 只有一种循环、无继承、错误显式，AI 写不出"反人类但能跑"的代码 （此条优于 C#：C# 表达空间更大，AI 可写出"聪明但难审"的代码）； ④ 性能：上界 8.2%（§13.1），不作为动因。
• oracle 用 Go：数据表（JSON，人可审）+ Go 薄解释器 + 启动自检 fail loud（事件类型清单 vs 规则表 key， diff 非空即拒绝启动）；规则表是语言无关资产。
• 迁移纪律（不可跳过）：主驱动 shadow_verify.py（105KB，承载 E-P1-5 输出通道 / Clang 缓存 key / known_issue 双向对账 / @category 豁免 / .strip() 比对语义 / sorted(glob) 确定性分片）必须新旧双轨同跑， 五项结论（663 / match 644 / known_issue 3 / vitro_better 16 / 0 非预期差异）逐项一致才允许切换。

13.6 中止条件（补充 §7.3）

1. 埋雷验证发现任一 P0 门禁空转 → 立即冻结所有以"全绿"为依据的结论，先修门禁，暂停其余批次。
2. shadow_verify 的判定逻辑被证明存在系统性空转 → §0 裁定① 与 §5.2 行为债量化均须重新裁定 （它们的证据基础来自该门禁）。
3. 语言迁移期新旧驱动任一项结论不一致 → 停止切换，差异归因后方可继续。
4. U2 验收线规模争议未决（§13.4 第一条）→ 不得开工 D4，因为无法验收。

13.7 状态记录（本节）

• 2026-09-12：本节立项（多轮讨论收敛）。新增第五域 **D1（防线自身）**并置于最前；新增判据 J9； 三处 U 批次数字更正；给出 W0~W3 五域顺序与 D5 迁移纪律。
• 已同步：docs/README.md 索引描述；native/tests/CORE_ASSET_VERDICT_FAILURES.md （R-2026-09-12 / D-2026-09-07 / G1 由"0 条"改为 2 条）；docs/spec/STEP_PAYLOAD_SCHEMA_V0_1.md §8 #9（补 code_line 的消费方可见后果：覆盖率 >100% 与热力图错位，并明确非前端独有）。
• 2026-09-12：D5 W3-1 前两站完成。① shadow_verify_cpp：Go 版双轨对账一致（94 用例集合 / 逐用例判定 / stdout 内容级）后接管 CI，Clang 并发 16 路 24.75s → 4~5.2s；② replay_s1_s5： Go 版双轨对账一致（61 条断言状态与编号逐行一致，exit 0 / 0.47s 含编译）。W1-1 的 "replay ≥3 分钟未完成"已失效——W0-2 止血（engine.rs panic 修复）后 Python 版实测 0.39s 全绿，性能观察作废；Go 版迁移价值回归 D5 本源（消除编码失败模式 + 编译器纪律）。 两站 Go 版均带 J9 启动自检（--selftest / 内置断言）与产物新鲜度门禁；Python 版保留为 双轨对照基准。剩余：探针集 → 主驱动 shadow_verify.py（须五项指标双轨一致才可切换）。
• 2026-09-12（晚）：D5 W3-1 第三站（探针集第一件）完成。random_diff：Go 版 （scripts/core_asset_verdict/random_diff.go）以 MT19937 + CPython seeding 逐比特复刻 实现"同 seed 同用例集合"，与 Python 3.14 双轨对账逐用例一致（1000 例 verdict + expected
  • clang 输出全同），Go 47.0s / Python 50.7s。三点实证/更正： ① 引擎 DLL 非线程安全实证——Vitro 调用与 clang 并发同池时进程以 0xc0000374 （STATUS_HEAP_CORRUPTION）崩死；此前 Python 版未崩只是 6 线程下 vitro 调用碰撞率低， 不是线程安全的证据。Go 版已恢复互斥串行；主驱动 shadow_verify.py --jobs 的并发 口径存在同源风险，待专项评估（风险记录，非回归）。 ② 基线刷新：库内旧产物（c3159ac）与当前脚本 + 当前 Python 3.14 的运行结果不一致 （历史环境不可复现：可能是旧版生成器或旧 Python），以本次双轨一致结果为新基线； "种子固定可复现"在同环境下由双实现两次运行证实。 ③ 门禁加牙：Python 版 main 恒 return 0（无牙）；Go 版非 agree 即 exit 1。 探针集处置口径：防线级/判定型（会再跑）继续迁移；一次性取证（repro_panics / case_census / clang_oracle_audit 等）按 AGENTS.md 判据不迁移，保留 Python 原样。
• 2026-09-12（晚，续）：D5 探针集 interaction_probe 迁移完成，并带来 W0-2 紧迫性的 定量实证。Go 版（整数 seeding 复刻 → 同 seed 同 op 序列）与 Python 版对账逐字段一致。 seed=20260912 实测：9 个随机交互会话中 8 个死于 engine.rs:400 seek panic（死亡点 分布 ops=2~102，即任意会话期望几十次交互内必死），恶意输入 payload.get end=-1 死于 engine.rs:416——W0-2 止血批次的两个 P0 在 master 上全部仍然活着。Go 版已按 J9 加牙（死亡/坏帧/不变量违反 → exit 1），当前红；W0-2 修复后转绿即是止血验收。 建议 W0-2 提前执行（小批次：clamp + 参数域防御 + serve catch_unwind）。
• 2026-09-13（续）：W0-1 完成 + D5 退役清理。① 三判定型脚本 J9 埋雷 全落地（台账 脚本埋雷验证记录.md）：ci_three_tier_check（假 KNOWN 条目 → hard 点名 / exit 1）、serve_smoke（新增边界批；撤 W0-2 钳位埋雷 → 3 FAIL / exit 1——catch_unwind 救活进程时由 id 关联断言层抓语义破坏， 双保险）、shadow_verify（登记 JIT 批次 tpl_add 突变实例）。 J9 顺带抓获脚本自身缺陷两处：serve_smoke resolve_exe debug 优先在 陈旧产物上假绿（已修 mtime 较新者）；判定型脚本须从仓库根运行（cwd 敏感）。 ② D5 退役清理：删除 7 个已被 Go 版替代的 Python 驱动 （shadow_verify_cpp / replay_s1_s5 / interaction_probe / random_diff / resource_longrun / seek_accumulation / winmem）——本节前文"Python 版保留 为双轨对照基准"的表述就此修订：D5 六站全部收官、各站双轨一致的 对账记录均已归档在案，基准用途终结，退役删除（git 历史可回取， git show 1d458eb^:scripts/<path>）。CI 活性四件（three_tier / smoke / precompile / engineering_health）与一次性取证/活性生成器保留，分类与 理由见 CHANGELOG Removed 段。删除前后 go vet 输出逐字节一致（存量 警告非本批引入）。
• 2026-09-13（续）：W0-2 / W0-3 / W0-4 全部落地（D6 修复批次之后）。 W0-2 止血收口：① engine.rs 两处 panic 此前"已修复"的判断不成立—— interaction_probe 复跑实证 A 段 8 个会话仍各 panic 一次（.serve_a_*.err.log 全部指向 engine.rs:400 split_off：seek 远超步数时理论 discard > 缓存长度； :416 get_payloads 的 ((-1).min(cache_end) as usize) 负数绕回 usize::MAX—— 旧 clamp 只 min 不封底）。本轮真修（discard.min(len) + 先钳区间再转 usize）+ serve 主循环 catch_unwind（panic → 错误帧 + 保守重建会话；埋雷 验证：注入 panic! 实测错误帧返回、后续请求正常、进程存活）；回归锚 serve_param_domain_regression.rs 五条；探针从红转绿（1800 请求 0 死亡 0 违反、fuzz 存活、stderr 零 panic）。 W0-3 契约止血：capabilities_json 所有权对齐书面契约（红→绿：契约测试 先证两次调用返回同一静态指针）；ABI 1.2.0 → 1.3.0；vitro_capi.h 补 齐缺失声明（实测 20 个，§13.4 原记 19 再更正；导出 41 = 声明 41 对账）
  • 三种所有权分区总说明 + clang include 编译验收；capi/mod.rs 22 入口 catch_unwind 全覆盖（22/22）；shared/ 三个孤儿文件删除。 W0-4（R-2026-09-12）：char 初始化器 W3053 误报修复——'A'/char 值域内 整常量豁免（is_char_safe_initializer + char_narrow_suppress）+ 同行同码 去重；9 条误报 → 0，真实截断（超域常量 / 变量赋值 / 赋值语句）仍报警 （typeck_e3053_regression_test 四条正反向锚定）+ baseline 用例。 全验收：cargo 66 套件全绿、shadow 667/647/4/16 门禁通过、探针 EXIT=0、 serve_smoke 通过、clippy 零警告。
• 2026-09-13：D6 / R-2026-09-13 修复批次落地（W1-4 收口）。① fast path 修复（!is_recording() 判断）红→绿闭环：修复前 665/644/output_gap 2/exit 1 → 修复后 666/match 646/门禁通过；② vm_bench.rs 方学校正 + jit_enabled 结构性 禁用开关（VitroVM 公共 API），加速比重测 9.16x（嵌套）/ 9.43~9.72x（单层）/ 0.97x（递归无效形状）——"不赚反亏"撤销，D6 裁定保留 JIT + 作用域收缩 （由修复内建）；③ J10 落地：jit_path_parity.rs 八条三锚差分 + baseline jit_single_hot_loop.c + 弱断言升级，突变实测（tpl_add 加→减） margin=20（cargo 11 红 + shadow 9 红），还原后全防线复绿（shadow 666/646 门禁通过 + cargo 63 套件全绿）。附带实证两条：修复前旧 bench 的 "JIT 时间"建立在穿透 bug 的错值执行上（只断言 ret==0 的"表面正确"实例， 已用 return sum 锚定修复）；bTree_default 存在 CLI/DLL 入口间 match/FAIL 漂移（模板程序 UB + 堆残留，既有条目已登记，非回归）。
• 2026-09-13：Q7-G1 拆分改判（G1 → G1a + G1b）。动因：真实用户短期不可得（下游仅 SharpTutor 且锚定旧二进制，历史试用计划过从未产出），"≥30 程序 + ≥300 会话"一次性判据 不可执行，而 G1 以 P0 挂起会让人误以为 CS 系列被阻塞。拆为： G1a 真实通道——归档入口直接落 native/tests/CORE_ASSET_VERDICT_FAILURES.md （不新增文件），时间盒滚动判据（CS2 交付前或 3 个月，先到者为准），"交互切面命中率 ≥30%" 改为待真实数据回填的开放指标（不得以合成数据代填），不阻塞 CS 系列； G1b 合成通道——防线 6 / U1#1 靶料，三源混合（教材/OJ 外部先验错误分布 / 真实现场 形态扩展 / MisconceptionPattern 六类兜底），禁止单源自证（循环论证红线：合成绿 ≠ 真实覆盖——2 条现场 4 问题仅 1 个被现有链路接住，已证明真实形态超出当前模式空间）， 判据 = 逐模式拦截 + margin 记录 + 先红后绿（套 J9），"合成覆盖率"与"真实命中率"分列。 R3 性质不变（被动监听，证据到达即触发）。统一整备路线图.md §4 防伪绿机制表与 U1#1 来源列已同步本纪律。

14. JIT trace 路径的 P0 静默错值（2026-09-13 独立复核）

来源：D5 迁移期间的性能/对照核对环节暴露核心资产缺陷 → 本节为独立复核结论 （复现 + 归因修正 + 根因定位 + 双向交叉验证）。 状态：已定位，未修复（本轮只更新文档，不动代码——按用户决定）。 验证方式：以下全部为 [动态实测]（本会话实跑，debug 与 release 双构建）。

14.1 现象与最小复现

#include <stdio.h>
int main(){int i,j,inner=0;
for(i=0;i<200;i++){for(j=0;j<200;j++){inner=inner+1;}}
printf("inner=%d i=%d j=%d\n",inner,i,j);return 0;}

字节码无罪、unified 执行循环无罪，缺陷在 executor 的 JIT trace 路径。 debug 与 release 构建输出完全相同 → 纯逻辑缺陷，与优化无关（非 ICF/UB）。

14.2 归因修正（重要）：与 long long 无关

原始归因为"循环体内写 long long 局部变量"，实测不成立：

按"long long 处理错误"去修会修错方向。

14.3 精确触发条件

三层条件同时满足才触发：

1. 外层循环回边计数达到 JIT_THRESHOLD = 100（第 101 轮开始录制）；
2. 内层循环已被 JIT 化（内层 trace 已建立——内层回边计数在第一轮外层内即远超阈值）；
3. 外层循环体不含条件分支（否则录制 Abort、退回解释、结果正确）。

触发点扫描（内层固定 200）：

14.4 根因

VitroVM::run 的 JIT fast path 在 trace 录制期间仍然生效 （native/crates/vitro_vm/src/core/executor/mod.rs:14-16，未检查 trace_recorder.is_recording()）。

事件链：

1. 内层循环先被 JIT 化（其 trace 本身正确，见 14.5）；
2. 外层第 101 轮，ip_hits[外层头] = 100 → recorder.start(外层头)；
3. 录制推进到内层循环头时，fast path 命中内层 trace → execute_trace_bulk 一次跑完整个内层循环，ip 直接落到内层出口；
4. 录制器从未见到内层循环的任何指令 → 外层 trace = [外层cond, outer++, j=0, i++, Jump 外层头]；
5. 外层回边 next_ip == start_ip → RecordResult::Finish（jit_trace.rs:102-104）→ 这条结构不完整的 trace 被编译注册（executor/mod.rs:331-335）；
6. 第 102 轮起每轮外层由 bulk 执行 → 内层被完全跳过。

一组机制解释全部观测：inner = 101×200 + 0（前 101 轮正常、之后内层 0 次）、j 终值 0（j=0 在 trace 内每轮执行，内层循环体不在其中）、触发点第 102 轮、带条件分支的循环体不受影响。

14.5 双向交叉验证（四组实验）

14.6 修复方向（2026-09-13 同日已执行推荐方案）

14.7 为什么门禁全绿却没抓住（防线形状盲区）

覆盖形状恰好互补地漏掉：

待落为用例（建议 native/tests/cases/baseline/jit_nested_counting_loop.c）：14.1 的 5 行程序 + 一个带 long long 的变体（固化"与 long long 无关"这一事实）。 纪律：先留 FAIL（红）记录，一行修复后转绿（红→绿 + J9）。

14.8 关联：vm_bench 方法学缺陷 —— Phase 25 的加速比从未可信

native/tests/vm_bench.rs 的对照存在两处缺陷：

let result = execute_run(&mut session);               // JIT 分支：session_ops 封装
...
vm.jit_traces_mut().clear();                          // ① 只清表，不禁用 JIT
let ret2 = vm.run(&mut session2.as_vm_context());     // ② 裸 VM.run，入口根本不同

• ①：clear() 只清空已编译 trace，hits 仍会累积并重新触发录制 → "纯解释"轮实际是 混合（前 100 次迭代解释 + 之后 JIT）；
• ②（更致命）：两分支入口不同（execute_run vs vm.run），同时变了两个变量 → 0.66x~0.86x 既不能证明 JIT 慢、也不能证明它快。

另：native/benches/vm_benchmark.rs 只测 compile_and_run（编译 + 初始化，checkpoints.save 后即返回），从未执行程序，不是 VM 性能基准。

⇒ "JIT 不赚反亏"的结论必须在校正方法学后重测才能成立（真禁用开关 + 统一入口）。

14.9 对 §13 的影响

14.10 状态记录（本节）

• 2026-09-13：本节立项。仅更新文档，未修复代码。
• 2026-09-13（同日，修复批次落地）：待办四项全部完成。 ① 用例落地（前条已记）；② fast path 修复：executor/mod.rs fast path 加 !trace_recorder.is_recording() 判断（推荐方案），红→绿闭环——修复前红留痕 665/644/output_gap 2，修复后 665→666 / match 646 / 门禁通过，两条 JIT 用例转绿； ③ vm_bench.rs 方学校正（真禁用开关 jit_enabled + 统一入口 execute_run + best-of-5 + fail-loud 自检 + 返回码锚定计算值），重测加速比 9.16x~9.7x （嵌套纯计数 9.16x / 单层热循环 9.43~9.72x / 递归无效形状 0.97x 噪声级）—— "0.66x~0.86x 不赚反亏"确认为方法学假象并撤销；④ Phase 25 状态同步 （AGENTS.md：降级记录更新为"已修复 + 加速比实测"）与 CHANGELOG.md（三条目）。 附带实证：修复后嵌套 1k×1k 撞默认 10M 步上限——修复前内层被穿透跳过、 步数虚低，旧 bench 的"JIT 时间"建立在错值执行上且只断言 ret==0（又一例 "通过 = 脚本自己没崩"，已在 bench 中以 return sum 锚定计算值修复）。

14.11 对重构范围的影响（2026-09-13 追加；同日 D6 裁定收口）

结论：需要扩大——但扩大的是「裁定的覆盖面」与「收敛的优先级」，不是「要重写的代码量」。

14.11.1 裁定①（核心不重写）维持，且被强化

⇒ 出问题的地方恰好不在核心——这是裁定① 的反向证据，核心因此更可信。

14.11.2 新增子域 D6：JIT 加速器（已并入 §13.3 五域表 W1-4）

关键推理：裁定① 的保护范围是"编译管线五段 + VM opcode 语义核心"。JIT 是加速器，不在该范围内 → 不受裁定①保护。而它当前状态：

处置 = 存废重新裁定，而非重写，顺序固定：

① 校正 vm_bench（真禁用开关 + 统一入口）→ 重测真实加速比
② 净收益不显著 → 删 JIT（执行路径 3 → 2，消除一整类静默错值风险）
   净收益显著   → 保留但收缩作用域（只 JIT 最内层单层循环）
③ 无论走哪条路 → J10 必须落地

裁定收口（2026-09-13 同日，①②③ 全部执行完毕）：

已知残留（登记，不阻塞）：录制期外层每轮重复"start→内层逐条→Abort"的微小开销 （嵌套形状 9.16x 数据证明不痛）；可选优化是录制入口预检"体内已有 trace 即不启动"， 属性能小项。bTree_default 在 CLI/DLL 两入口间 match/FAIL 漂移——模板程序自身 UB（读未初始化 children，堆残留决定 NULL 与否），E2E_FAILURES 既有条目已登记 "表现非确定性"，FAIL 态命中白名单，非回归。

与 §13 的 U5 同向：收敛的正确形式不是"让多条路径等价"，而是减少路径数与作用域。

14.11.3 D1（防线自身）扩一个维度：形状对抗生成

原 D1 = "脚本埋雷验证"（验证检查器是否会红）。本次暴露的是输入空间维度：

D1b 是 U7#1"随机差分"的加强版：随机数据不够，必须随机形状。

14.11.4 U5 提级：J10 前置到 W1

U5（三路径收敛）原排 Wave 3。现有 P0 实证：三路径确实分叉且为静默错值。 ⇒ J10（JIT vs 解释器等价性）前置到 W1，与 oracle 建设同期。理由：CS2/CS3 会大规模扩充 执行语义（ARC、异常展开），每扩一块就多一块分叉面，等 Wave 3 再收为时已晚。

14.11.5 明确不扩大：不重写核心

1. 修法是一行（fast path 加 !is_recording()）；
2. 解释器路径正确（unified 1085838 步与 clang 一致）——核心没坏；
3. 分叉的根源是"存在多条路径且无等价性合同"（设计问题）。重写核心不会消除它——只要仍留 ≥2 条路径，新代码同样会长出分叉；本次缺陷恰恰是在 Rust 重写之后长出来的 （与 §T1"换语言没有换来生命周期设计"同构的教训）。

14.11.6 一句话

范围扩大 3 处（+D6 子域 / D1b 形状对抗 / J10 前置到 W1）、缩小 0 处，但都不是"多写代码"， 而是"多裁定一个域 + 多两条防线判据"。裁定①（核心不重写）维持不变。