R 线交付记录（R0–R8.5）

⚠️ 这是归档材料，不作为设计参考。 原文从「内部路线图（未公开）」的 §11.x 整段搬出（2026-10-08）：路线图是规划文档，堆着已交付的每一步只会让它继续膨胀 （那份文件已经 1384 行）。路线图里只留「R 线现在在哪、下一步做什么」。 原文未做删改。R 线是什么、为什么做 → 「内部架构迁移评估（未公开）」。 R8.3–R8.5 的明细见文末「补记」（R8.3 起的原文仍在路线图 §11.5–§11.10）。

11.1 ✅ R0 已交付（2026-09-30）：一致性夹具

做了什么：把 Python 前端现在的行为逐字冻结成结构化基线 —— tokens / ast / bytecode / diagnostics 四个阶段，73 个语料。 工具 tools/conformance.py（freeze / check / list）、基线 tests/conformance/、守门测试 tests/test_m57_conformance.py（17 项）、 说明 docs/一致性夹具.md（内部）。

🔴 立规矩时立刻抓到两件事（都写进夹具文档）：

1. 差点把 bug 冻成标准：我把 serialize.dump_json 写成 dumps_json，

73 个语料的 bytecode 全变成「编译阶段：<内部错误：ImportError>」。 于是加了硬闸门：前端抛非基石错误一律拒绝冻结（那是实现 bug，不是语言行为）。 —— 自动化工具分不清「事实」与「事故」，所以「把当前状态升格为标准」的动作 必须有这道闸门。

1. 同一课在 M49 也上过：fetch_release_mirror.py 拿上一版的 SHA256SUMS

校验新包（文件名不随版本变 + 「大小一致就跳过」），四条校验全被静默跳过。 已改成硬错误：清单里没有这个资产名 → 拒绝发布。 （「跳过校验」与「校验通过」在 CI 里长得一模一样。）

📌 3.10 与 3.13 产物一致这条对 CI 排障有直接价值：它说明 CI 里 Python 3.10 的失败不是前端语义差异。

🔴 顺着这条线索查到了 CI 3.10 一直红的根因（2026-09-30 当天修掉）： tools/build_home.py 里有 12 处 {code('…\n…')} —— PEP 701 是 Python 3.12+ 才允许 f-string 表达式含反斜杠，3.10/3.11 直接 SyntaxError（import build_home 失败 → 连带 7 个用例全红）。 本地是 3.13，永远看不到。 修法：含反斜杠的字符串提到 f-string 外面； 并加了一条 AST 扫描测试（任何 Python 版本下都能发现）。 ⚠️ 顺带记一条口径：本地有 Rust 二进制、CI 不编译 Rust —— 本地结果不能 完全代表 CI。

11.2 ✅ R1 已交付（2026-10-01）：前端契约固化

做了什么：把「前端每个阶段要产出什么」写成带版本号的契约，并给出一把 能定位的尺子。R1 的定义就是「不改行为，只定义接口」。

验收演示（R1 的验收标准正是「改坏一处能定位」）：

❌ 外部产物 vs 基线：72/73 个语料一致；共 1 处问题
  · 产物不一致：tests/cases/01_算术.jsh 在 `tokens[2].col`
差异明细：
      「tokens[2].col」 —— OP「=」（第 2 行第 5 列）
        基线：5
        外部：6

📌 一条设计上的坚持：外部只提供部分阶段也行（R2 只做分词），但 没提供的阶段必须如实报「未提供」，默认（不带 --stage）时那就是没过 —— 「没测」与「测过了」必须能分开。同一个道理今天在 CI 上又验证了一遍。

11.3 ✅ R2 已交付（2026-10-01）：分词器换 Rust

做了什么：新建 core/（Rust crate，pyo3 编成 Python 扩展）， tokenize() 在 JISHI_FRONTEND=rust 时走 Rust、默认仍是 Python（有开关可回退）。

🔴 最重要的一条：「≥5 倍」够不着，是接口决定的

端到端 = Rust 纯核心（69.6 ms） + 把 Token 交回 Python（62.4 ms）
                                  其中 46.4 ms 是「纯造 11.7 万个 Token」的地板
天花板 = 490.8 ÷（69.6 + 46.4） = 4.23x   ← 与实现好坏无关

建议（待作者确认）：R2 的验收线改成「纯核心 ≥5x + 逐 token 一致」， 把「端到端 ≥5x」挪到 R5 —— 那时下游（parser/compiler）才不吃 Python 对象。 ✅ 2026-10-01 已拍板采纳：R2/R3 这一层认「纯核心 ≥5x + 产物逐项一致」， 「端到端 ≥5x」移到 R5 验收（那时下游不再要 Python 对象）。

🔴 顺手抓到的（都不是写错，是「本来就没测」）

1. R0 的 73 个语料里一个 emoji 都没有（＝没测位置），而列号口径是这次迁移的

头号风险。补 12 个语料：emoji 码点列号 / 多行注释三形态 / 全角归一化 44 项 / 三引号独占行 / 数字写法 / 插值分段表 / 5 个词法错误； 并新增语料类别 tests/frontend_cases/（超 i64 整数 ⇒ C VM 有意报 E2005， 放 tests/cases/ 会破坏「三执行器都能跑」那条约定）。 ⚠️ CRLF / 孤立 \r / BOM 进不了语料目录（read_text 会归一化）→ 字符串级测试。

1. tokenizer.TOKEN_TYPES 漏了 FSTRING（M7 没补）。R2 的 kind_name_index

用 unreachable! 兜底 → 当场 panic（宁可不跑也别给错值）。

1. emit 没清空输出目录 ⇒ 中途失败后 compare 拿旧产物比出一个绿

（「没跑成功」伪装成「通过」，第三次遇到同一个坑）。已改成「先删再写」。

11.4 ✅ R3 已交付（2026-10-01）：语法 → AST 换 Rust

做了什么：core/src/parser.rs（2600 行）—— 把 1968 行的 jishi/parser.py 逐行移植，含全部解析期脱糖（条件表达式 / 超() / 匹配 / 枚举 / 推导式 / f-string），脱糖发生在与 Python 同一位置。

🔴 最有价值的一条不是性能，是「接口原本就是错的」

原计划让 Rust 从 source_lines 反拼源码。做到一半发现：source_lines 是 有损载体 —— incremental.split_lines 会去掉末尾空行，反拼回去 报错行号整体少一行（实测 9 例错 4 例，全在「块首后跟空行」这种形状上）。 而 LSP 那条路拿到的正是 inc.lines。

改成：Rust parse 吃源码文本；新增 parse_source(源码) 作生产入口 （顺带省掉一次重复分词）；旧入口留给 LSP 增量分词，并加精确守卫 （拿 token 流末尾 EOF 的行号当标尺）—— 丢了内容当场报错，不猜。

📌 手法可复用：「反拼」这件事本身就是信号 —— 需要把 A 反拼成 B 才能让下游 干活时，多半是接口给错了；把原始输入直接递下去，比在两侧维持两条「口径」 的隐性约定可靠得多。

🔴 顺手抓到的两处：① 插值字符串的 value 是分段表，直接插进中文报错会把 Python 的 repr 泄给用户 → 两侧统一说「插值字符串」；② 类外 超() 那条错漏了 with_source 与 ^ 下划线（它是解析之后补的检查，不走 _err）→ 报错的补全要认「一个出口」，别按「谁抛的」分岔。

下一步：R4 前端报错 —— ⚠️ 范围已缩小：R3 顺手把语法阶段的 diagnostics 一起比过了，所以 R4 只剩「把比较面补全」这半边（执行期/编译期留给 R5/R6）。

11.5 ✅ R4 已交付（2026-10-01）：前端报错（契约升 v2）

做了什么

🔴 渲染 为什么进契约：它是「事实」的下游产物，看着冗余，其实是兜底 —— 哪天给错误加了一个事实字段却忘了列进契约，两个实现的渲染立刻不一样；而 「字段没进契约」本身是看不出来的（R3 就栽在「漏了一个字段、比对还是绿的」）。 挑那个能连坐整个类的不变量，是一次就够的检查。

🔴 错误码体检第一次跑就抓到两笔（以前从来没人查过）：

• E0205「括号没有闭合」是死码 —— 定义在、说明在、jishi 错误 E0205 查得到，

但全仓库没有触发点（括号没闭合其实报 E0201）。一份永远兑现不了的承诺。 → ✅ 已拍板接上：期望右括号而已到文件末尾 ⇒ E0205，位置指向 那个没闭合的开括号（EOF 的位置是「末行第 1 列」，指着它没用）。 ⚠️ 只认「走到末尾都没等到」：中途撞上别的 token 仍报 E0201 并说出「看到了什么」—— 别为了把码归拢而把信息丢掉。

• E0204 可达却一个语料都没有 —— 八个形状能触发它。

🔴 词法那条还原路径漏读「修正」：词法/语法各抄一份字段清单，词法那份少了 fix —— 而当时恰好没有一个词法错误带 fix，所以怎么测都是绿的。 → 收成一个出口 + 字段表往返测试把它们钉死。 「两份清单并存 + 恰好没用到」＝ 测不出来，但问题在。

下一步：R5 编译器 → 字节码 —— 见 §11.6。

11.6 ✅ R5 已交付（2026-10-02）：编译器 → 字节码换 Rust

做了什么：core/src/compiler.rs（1151 行 Python 编译器的逐行移植） + jishilib.rs（基石库层展开）+ serialize.rs（字节码 JSON + Python 的 repr(float)）+ opcodes.rs + sha256.rs。

✅ 前端整条链（源码 → 词法 → 语法 → 字节码）现在都能在 Rust 里原生跑完。

🔴 兑现「端到端 ≥5x」靠的是换产物形态：从「Python 对象」换成 「字节码 JSON 文本」。地板（造对象）在文本这条路上不存在 —— 不是实现更快了，是接口换了。⚠️ VM/CVM 那条路仍要对象，别拿它判 R5。

🔴 移植时抓到四个既有 bug（与 R5 无关） —— R5 逐字复刻，R5.1 已全修 （编译器漏 Try 分支 / Python VM 撞掉帧栈基址 / 树遍历「捕获 为」开子作用域 / 调用链时机不一）。见 docs/前端契约.md §12.4、docs/设计决策.md D59。

下一步：R6 VM + 标准库（Rust 原生） —— 验收 = 426 项对拍全绿； 实测后定 C VM 去向。

11.7 ✅ R6 已交付（2026-10-04）：VM + 标准库（Rust 原生）

一句话：树遍历参考执行器六步 + 四项主体性能全交付，C VM 去向按「先量再定」 实测后拍板保留。细节不在这里重复：数据与结论见 docs/设计决策.md D76 （长任务 C VM 净 489.0ms vs Rust VM 净 649.0ms，C 快 1.33x；维护面 2408 行 / 近 30 天 12/187 次提交），时间线见 PROGRESS.md。

📌 教训（R6 全期最值钱的一条）：Val 的「32 字节」在文档里躺了很久、 被反复引用，却从没量过 —— 一量是 128 字节（撑大它的是内联的 Class）。 没有量过的数，不许当事实写。

11.8 🔎 R7.0 侦察与度量（2026-10-05）：工具链迁移面台账（待拍板）

R7 的验收是「编辑器不再依赖 Python；增量指标不倒退」。开工前先把面摸清 ——「搬得动/搬不动」都要有依据，不能靠感觉。

一、好消息：边界已经是「进程 + 协议」，不是「import 我们的模块」

• 编辑器扩展一直是 spawn 子进程：server.command 默认 jishi、

server.args 默认 ["lsp"]（stdio JSON-RPC，自带最小传输层 lsp-transport.js）；调试走 VS Code 的 DebugAdapterExecutable spawn jishi dap。 → R7 换的是协议那头是谁，不是发明新接口。

• 工具链模块没有一个依赖第三方 Python 库（只有 json/sys/pathlib/

argparse/threading/zipfile/hashlib 这类标准库）。 → 「不再依赖 Python」的实际含义 = 把 R2–R5 的 Rust 前端 + R6 的 Rust 宿主 接到同样的协议上，再补 Rust 侧还缺的几块。

二、迁移面台账（逐项）

三、搬不动的（显式登记，与既有「有意边界」同一条口径）

1. 从 python 导入 / 本地包：单二进制里没有 Python —— 与跨语言宿主已有

的那条登记同源（tests/error_cases/13_从python导入.jsh 等）。

1. jishi 医生 里的「Python 环境」检查项（venv / 编码 / C VM DLL 路径）：

单二进制里没有意义，换成 Rust 版自己的检查项（二进制位置 / 标准库自检 / 包索引可达性）。这是改动，不是缺失 —— 要在 R7.4 明说。

1. 元数据的「反射」做法：ai.py 用 Python 的 ast 读自己的源码抓

docstring 与结构；Rust 里没有等价物。必须换做法（见 §五-1 拍板项）。

四、建议的迁移顺序（依赖少的先来）与每项验收判据

⚠️ 「增量指标不倒退」要在 R7.3 验：基线是同机同时段测的 「编辑一次 → 诊断出来」的耗时（按文件行数分档）。incremental.py 有历史数据 （见 §六），但历史数据只能当量级参考，不能当判据 —— 按本项目纪律， R7.3 开工首日要在同一台机器上重测一份基线再比。

五、搬第一件之前要拍板的事

1. 🔴 语言元数据的唯一来源放哪？现在它长在 Python 里（而且是用反射自己源码

的方式长出来的）。三条候选：(a) Rust 侧显式表（可读、可测，但要防与 Python 侧漂移）；(b) 一份共享数据文件（.json/.toml），两侧都读它 ——漂移在结构上不可能；(c) 生成（从一个来源生成两侧）。 📌 这条决定 R7.2 的形态；本项目为「两个地方各自解释同一份元数据」付过代价 （AGENTS §2 有记录）。倾向 (b)，但需要你点头。

1. 🔴 Rust 二进制的入口名与分发形态：编辑器 spawn 的是 jishi

（现在是 Python 控制台脚本）。R7 之后是 ① 叫 jishi-rs、扩展里配置切换； 还是 ② 直接叫 jishi（Rust 版顶上），Python 版退成一个别名？ 这直接决定「编辑器不再依赖 Python」怎么验（① 是「可切换」，② 才是 「默认不依赖」）。

1. 🔴 DAP 放不放 R7：它要新做「可调试执行器」（单步 / 断点 / 语句钩子 +

变量快照）。要选落在哪个执行器上：树遍历参考执行器（已经是「规范」， 加单步可能最省）还是 Rust VM（快，但要动指令循环）。 若 R7 只想收「编辑器不再依赖 Python」，DAP 可以挪到 R8 之后。

1. 包管理放不放 R7：它和「自主分发」是同一件事的两半。若 R7 目标是

「编辑器不再依赖 Python」，包管理可以不动。

1. 旧 Python 工具链的处置：R7 完成后留不留？（D76 的教训：C VM 那次是

先量维护面再拍板）——建议同样处理：先量「留着的维护代价」与 「退掉的风险」，再定，不预设。

六、R7.0 已经拿到的基线（增量）

jishi/incremental.py 里记着一份历史实测（编辑一次的代价，Python 侧）：

📌 现状：只有分词是增量的，parse 仍是全量（1000 行以上有可感卡顿）。 ⚠️ 这份表是历史数据（当时机器 / 当时版本）—— R7.3 开工首日同机重测 一份，才是「不倒退」的判据。

11.9 🚧 R7 已拍板（2026-10-05）：四条决定 + R7.1 进度

§11.8 那份台账把「搬第一件之前要拍板的事」列了 5 条，用户当场拍了 4 条：

🔴 开工时核实出的前置条件（§11.8 台账没写清，值得单记）

前端本体本来住在 core/src/，而 core 是编成 Python 扩展（pyo3）的 crate —— 于是「能解析源码的东西只有 Python 拿得到」，独立宿主 jishi-rs 只能吃 已经编译好的字节码 / AST JSON（R6 的 --walk 也是吃 AST JSON）。 而 LSP / 格式化 / 静态检查都必须自己拿到 AST ⇒ 前端必须先解耦。

📌 核实的结果是好消息：这个搬家是干净的 —— 前端那五个文件代码级零 pyo3 用法 （翻遍 tokenizer / parser / serialize / jishilib / opcodes，命中的 "pyo3/Python" 全是注释里的「与 Python 侧对应关系」说明），而且跨模块引用本来就写 crate::tokenizer::… —— 整体搬到新 crate 根目录后一行引用都不用改。

📌 教训：「谁拿得到这个能力」要在侦察时就查清，不能只看「这个能力在不在 Rust 里」。台账当时写「tokenizer ✅ / parser ✅」是对的，但没说「它们住在 pyo3 扩展里、二进制用不上」—— 差一点就按「已经齐了」排期。

进度

① CLI 主入口：jishi-rs <文件.jsh> / --stdin / --ast / --json-errors / --sandbox / --json-result / --timeout / --load-bytecode / --dump-bytecode。tools/check_cli.py（新闸门）跑 93 个语料 × 3 种模式 × 两个引擎，不一致 0；--json-errors 连 fix（print→打印）都对上。 ② MCP：jishi-rs mcp 与 python -m jishi.mcp_server 同一串 40 条报文逐字节一致（7 个工具全过；只有 duration_ms 会因为它是墙上时间而归一）。 ③ run_script 到点真 kill：子进程隔离 + 到点 kill()；宿主自己那条沙箱超时（线程 + 有超时的收结果）1 秒内带着协议 JSON 退出。 🔴 位置参数的语义改了：<文件> 从「字节码 JSON」变成源码（与 jishi <文件> 对齐），字节码走 --load-bytecode —— tests/ + tools/ 里 25 个文件、35 处调用点跟着补了开关。 🔴 顺带修掉三个真 bug（旧判据没覆盖到，R7.4 的对拍照出来的）：① 宿主把 值错误("x") 当立刻抛而不是构造异常（三个 Python 执行器都不是这样，令 e = 值错误("x") 在宿主上直接崩）；② TraceFrame 少带 col，调用链里那一项恒为 null；③ 树遍历的「找不到名字」hint 给 "" 而另两个执行器给 null。 🔴 本机环境坑：Windows 上给子进程 stdin 方向 CreatePipe 稳定失败（ERROR_PIPE_BUSY / os error 231，兄弟症状是 test_m31 那条已登记的 spawnSync node.exe EBUSY）。jishi-rs --mcp-spawn-probe 是复现入口；解法是用临时文件当 stdin（--stdin 语义不变，只是不走管道）。 ⚠️ Python 侧两处如实登记（不是宿主的问题）：① CLI 的沙箱超时会丢输出（跑死循环时 stdout 全空、0.5 秒的超时要跑十几秒 —— 泄漏的守护线程抢 GIL）；② MCP 的 stdout 以前没像 CLI 那样 reconfigure(newline="\n")，Windows 上吐 CRLF（已修，两侧统一 LF）。 判据 test_m92（CLI：对拍 + 独立 + 计时 超时护栏）/ test_m93（MCP：报文逐字节 + 独立 + 计时 真 kill 护栏）。⏳ 下一步 R7.5 DAP | | R7.5 | DAP 搬进 Rust（可调试执行器 + jishi-rs dap） | ✅ 已交付： ① 给树遍历参考执行器 (rust/src/walk.rs) 加调试钩子（DebugHooks：before_stmt / push_frame / pop_frame）—— 只读、不改语义；为了让「带调试器跑」与「不带」逐字节相同，钩子只读语句与作用域。 ② 会话（rust/src/debugger.rs，对应 debugger.py 的 _Session）：断点表 / 单步模式判定 / 变量与调用栈 / 就地求值 / 出错现场快照。 ③ DAP 适配器（rust/src/dap.rs，20 个请求 + 事件 + 60 余条报文）。 🔑 Rust 版与 Python 版的线程模型不一样、报文一样：Python 用「主线程跑协议 + 脚本线程跑程序」，Rust 的 Walker 不是 Send，所以改成「读线程只做分帧 + 主线程既跑协议又跑程序」—— 暂停时由 PauseDriver 串行地泵消息，顺手把 stackTrace / variables / evaluate 答掉。对客户端而言报文序列逐条对应。 ⚠️ 一处如实说明的时序差异：程序自由跑时收到的读请求，Python 当场就答、Rust 在下一个语句边界才答（对 pause / disconnect 无影响 —— 本来就是「下一条语句生效」）。判据用同步客户端（等应答再发下一条）把两边卡在同一点。 🔴 判据：三种场景（普通单步 / 就地求值 / 出错现场）与 jishi dap 报文逐字节一致（13327 / 13930 / 10655 字节）+ 不依赖 Python 的独立判据（能力声明必须在 body.capabilities 里、停不住的行要标 verified:false、只支持树遍历要明确拒绝、写死的变量与栈期望、清空 PATH 也能跑）。 ⚠️ 没搬的部分（如实登记）：字节码执行器的调试（--执行器 vm/cvm 明确拒绝）。 ✅ R7.5 收尾已交付：jishi-rs 调试（交互式命令行）—— 补上命令表 （断点/取消断点/清空断点/变量/查看/栈/源码/帮助 + gdb 风格别名）与「读一行」的驱动 LineDriver（PauseDriver 当初就是为它留的口子）。判据 tests/test_m95_debug_cli_rust.py （20 场景逐字节对拍 + stdin 路径 + 独立判据）。🔴 顺带修掉一个宿主真 bug： 内建渲染成 <内建函数 打印>、异常类型渲染成裸的 值错误（Python/Node 是 <内建 打印> / <异常类型 值错误>）—— 旧测试只比 Python VM 与 Node、没算上 Rust， 是 变量 全部 的对拍照出来的；已补进 test_m32_boundaries.py。 | | R7.6 | 包管理搬进 Rust（packages.py 597 行 + cli.py 的 _run_package_cmd） | ✅ 已交付： rust/src/packages.rs + jishi-rs 安装/卸载/列表/发布/索引/检查。判据 tests/test_m96_packages_rust.py （六子命令逐字节对拍 + 独立判据 + file:// 本地镜像走完整条安装链）。 🔴 检查 换回了包管理的语义：Python 的 检查 是包依赖冲突、源码检查叫 源码静态检查（别名 静态检查）；R7.1-c 当初把源码 lint 挂在 检查 上是错的， R7.6 让回包管理（否则 Rust 顶上 jishi 时脚本会静默走错），调用点改了 test_m86/test_m87。 🔴 一处刻意保留的差异：打包 zip 的字节不同（Python ZIP_DEFLATED、宿主 stored 写出器）→ 发布 / 索引 --checksum 的体积与 sha256 对不上（测试归一化后比）； 内容一样、stored 合规（拿 Python zipfile 当裁判验过），不影响安装。 ⚠️ 另两处已登记文案差异：缺参数走 argparse（宿主给中文用法，只对齐退码 2）； 网络错误的具体文案（外层结构逐字一致）。📌 复用了 zip.rs/crypto.rs/http.rs （http::client::request 返回类型从 String 改成原始字节，新增 fetch_bytes）。 ✅ R7 六件（R7.1–R7.6）全部完成。 |

📌 R7.1-b 顺带打通了一条流水线（后面两件照抄）：**Rust 侧显式表 + 「自报家底」 --dump-* + Python 侧逐字段比 —— 这是拍板第 1 条说的那条漂移检测，先从「纯数据」 的错误码表上跑通。首次的表由 tools/gen_errcodes_rs.py 一次性搬运**（跑完看 diff）， 之后两侧由测试钉住。

11.10 🚧 R8 侦察与度量（2026-10-07）—— 单二进制 + wasm + 退役 Python/JS

R7 六件收口（jishi-rs 已覆盖 编辑器 / agent / 脚本 / 包管理 四条路）之后进 R8。 R8 的定义（docs/架构迁移路径.md §三）：单二进制 + wasm，退役 Python 与 JS → 架构变革 收尾；验收 = 三平台包可用 + playground 跑通 + 安装/升级链路不受影响， 体积 ≤ 5 MB、启动 ≤ 100 ms（达不到就如实公布）。

一、开工实测（本机，2026-10-07）

📌 两条验收线都擦着过，所以 R8 的「体积/启动」不是「顺手就过」，而是 要看着别退：后续任何一件（wasm 胶水、沙箱步数预算、改名）都可能把它推过线。

二、🔴 本次已完成的高风险单点验证：wasm 真能跑

docs/架构迁移路径.md 的风险表写着「wasm 上跑不通（playground）→ R8 前先做单点验证 （一个 hello 走通 wasm），不把它拖到最后」。本次当场做了（一次性探针， 源码留在 build/_wasm_probe/，不进仓库）：

1. rustup target add wasm32-unknown-unknown（本机原先只有 x86_64-pc-windows-gnu）；
2. 零改动下 jishi-frontend 与 jishi-ffi 都能编到 wasm（0 error）——

比预想的好得多（原以为要按 cfg 拆 crate）；

1. 探针（cdylib + 3 个 extern "C" 导出 + 手写 30 行 JS shim）真跑起来了：

wasm 模块 1,518,284 B = 1.45 MB（release，未做 opt-level="z"/LTO 调优）。

📌 结论：R8 最大的一处未知已排除 —— 整条链（前端 + 编译器 + 字节码 VM + 原生 标准库）在 wasm 上零依赖跑得通，不需要 wasm-bindgen 那类框架。 ⚠️ 「编得过」≠「跑得对」：探针同时证明了必须避开的两处 —— std::thread（sandbox.rs 的超时靠它，wasm 上会 panic）与 std::fs/net/process。

三、现状台账：还差什么

四、建议的推进顺序（依赖少的先来）

五、待拍板（4 条）→ ✅ 2026-10-07 已拍板

⇒ 于是 R8 的步序定为：R8.1 wasm 正式化 → R8.2 playground 切 wasm → R8.3 三平台发行包 → R8.4 退役 Python/Node + 改名 jishi → R8.5 收尾（进 0.3.x）。

11.11 ✅ R8.1 已交付（2026-10-07）：wasm 引擎 + 裸 ABI + 手写 shim

按 §11.10 的拍板（裸 ABI、步数预算、单二进制→wasm→退役、改名与退役同批）开工。

交付物

实测

• wasm 模块 1,544,334 B = 1.47 MB（未做 opt-level="z"/LTO 瘦身）。
• 12 个语料（含 error_cases）在 wasm 里的结果 JSON 与

jishi-rs --sandbox --json-result 逐字节一致（只归一 duration_ms）。

🔴 三条要记住的

1. std::time::Instant::now() 在 wasm 上 panic（`time not implemented on this

platform）。panic="abort" 下它表现成 RuntimeError: unreachable —— 看着完全 不像时钟问题，我在这上面绕了一圈（先怀疑 profile、又怀疑 LTO）。 ⇒ sandbox.rs 加了 Clock（wasm 上恒 0），真实耗时由 shim 用 performance.now()` 量。

1. 步数预算关进 cargo 特征 budget，只有 wasm/ 开。这是量出来的：

• 判断放指令循环顶（每条指令过一遍）→ 1.068x；
• 只在回跳处判 → 1.058x；
• 同轮「同一份二进制的两份拷贝」→ 1.005x（所以 5~6% 不是噪声）；
• 特征关掉 → 1.000x（与加这个功能之前逐位同效）。

⇒ 原生宿主一个字节的钱都不用付；wasm 付 6% 换「页面不冻住」。

1. [profile.release]（opt-level="z" + LTO + strip）暂时没写：当时配上它

wasm 只剩 16KB 且一跑就 trap —— 后来查明根因是第 1 条（时钟），不是 profile。 但它现在没被验证过，所以先不写（1.47MB 能上网页）；要瘦身得单独量过再开。

⚠️ 一处如实说明：wasm 上判「跑飞了」的单位是循环圈数 ⇒ 兜不住没有回跳的失控（无限递归）—— 那种撞 wasm 栈上限，由 shim 接住并翻成 「程序跑飞了」。引擎给的错只有「执行步数超过上限」那一条。

⏳ 下一步 R8.2：site/playground.html 从 Pyodide 换成就是这份 wasm （现在跑的是 Python 实现，页面 432KB、还要从 CDN 拉 Pyodide）。

11.12 ✅ R8.2 已交付（2026-10-08）：在线试玩页换成 wasm

按 §11.10 的顺序（单二进制 → wasm → 退役）做的第二件：把 playground 页面本身 从 Pyodide 换掉。

交付物

换掉了什么

判据怎么写的（值得复用的一条）

test_m10 只管「HTML 里有什么」（无 Pyodide 残留 / 引用 wasm 三件 / 体积量级）； 真正兜底的是 test_m97 新加的那条端到端：把生成出来的那个页面放进 Node + DOM 桩里跑起来（真 shim + 真 wasm），点「运行」，比输出文本 （示例程序写死期望、语法错比码与行列、运行期错比码与标题）。

📌 只断言「HTML 里含 JishiWasm.load 这个串」是糊不住错的 —— 渲染逻辑、 错误分支、事件绑定、textContent 写没写对，全都不在字符串里。这一条才是 「页面能用」的判据。

🔴 顺带修的：协议形状不统一

胶水与 wasm 自己兜的两种意外（wasm trap / 返回不是合法 JSON）以前给的是 errors 数组（元素带 type），而引擎给的失败是 error 对象 （{code,title,message,line,col,hint}）—— 页面得判两支。

⇒ 统一成引擎那一份。改了三处：wasm/jishi-wasm.js 的两条兜底、wasm/src/lib.rs jishi_eval 的「值没法表示成 JSON」那条。「页面只该认一个协议」。

📌 实机验证（不是只在 Node 里跑）

用无头 Edge 起本地站点（python -m http.server → 127.0.0.1:8791）：

• playground.html / jishi-wasm.js / jishi_wasm.wasm（1,544,414 B）都是 200；
• --dump-dom 里状态栏已从「正在加载引擎…」变成 「就绪」、运行按钮已启用

⇒ fetch 得到 + 实例化 + ABI 自检这条路通；

• 再截一张「自动点过运行」的图：输出区显示示例的正确结果。

⚠️ file:// 直接双击打不开（浏览器不许从本地磁盘读 wasm）—— 页面里已经写明 「改用本地服务器（例如 python -m http.server）」。这与以前不同：旧页面虽然是 自包含的，但它照样要联网拉 Pyodide。

⏳ 下一步 R8.3：三平台发行包从 PyInstaller 改走 cargo build --release。

补记：R8.3–R8.5（2026-10-08 ~ 10-09）

本节是摘要（R8.3 起的原文仍在内部路线图 §11.5–§11.10）。这一段把 0.2.x 「架构变革」收尾：单二进制发行 → 退役 Python/Node → 升 0.2.2。

• R8.3 发行包改走 cargo（单二进制）：三平台包从 PyInstaller 换成

cargo build --release 的产物 —— 包内文件数 249 → 13、Windows zip 约 20MB → 2.91MB、启动 83ms。顺带修掉一个真 bug：老包的 bin/ 是 嵌套的（bin/jishi/jishi.exe），而 install.sh / install.ps1 的自检写的是 平铺 —— Linux/macOS 用 tar.gz 装完自检必失败，且 jishi 不在 PATH 上 （Windows 走 Inno Setup 才没暴露）。判据 test_m98。

• R8.4a：医生 / 新项目 / 教程 搬进 Rust（rust/src/tools.rs）——

发行包换单二进制后这三个不能再缺。新项目/教程 与 Python 逐字节对拍； ⚠️ 医生 有意重写（Python 版报「Python 版本 / C VM / MCP」，单二进制里 那三样根本不存在）。判据 test_m99。

• R8.4b-1：交互式 REPL（-i）搬进 Rust（rust/src/repl.rs）——

10 个会话 stdout/stderr/退码逐字节一致；⚠️ 不改行编辑（那是独立一件事）。 判据 test_m100。

• R8.4b-2（改名 + 退役）：jishi 让给单二进制（Python 退 jishi-py，随后

随退役取消安装入口）；jishi/ → oracle/jishi/、node/ → oracle/node/， 只作判据基准。改动面约 640 处、233 个文件。判据 test_m101。 🔴 收敛 142→0 的四类根因见路线图 §11.9（盲替换打坏 .jishi/-jishi； core/ 里硬编码模块名；editable 要重装；语料 glob + 基线重冻）。

• R8.5 收尾：版本升 0.2.2；[profile.release] 量完再开（LTO + strip，

exe 4.63→2.91MB、算力 0.97x；opt-level="z" +24% 慢 ⇒ 不用）； check_engines 改每语料私有 cwd（判据 test_m102）。