@furongjun1999/dsh-memory 0.5.0 → 0.6.0

package/docs/eval//347/274/272/351/231/267/346/214/226/346/216/230_/350/207/252/344/270/273/350/277/255/344/273/243_v3.md

@@ -0,0 +1,152 @@
+# 缺陷挖掘报告 · 自主迭代 v3
+
+- **日期**：2026-09-25
+- **范围**（生效条件）：第 1 轮遗留收口（compiler/md_cg 域 3 项，v1 报告第四节 compiler 组 #18 之外的 #6/#21/#22 全部）+ 第 3 轮新挖掘（compiler 域深挖：词法/语法/名实校验/API 面/代码生成/测试面）
+- **总量**：第 1 轮遗留修复 3/3 落盘；第 3 轮候选 20 → 确认 20（零差值）→ 修复 2 → 遗留 18
+- **严重度分布**（确认 20 项）：high 6 / medium 8 / low 6
+- **回归**：10 套全绿（compiler 8 套 + md_cg 2 套，本会话实跑，见第六节）
+- **行号口径**：下文缺陷行号为任务输入的挖掘时快照行号；本会话逐项复核现行代码——api.py / codegen.py / name_checker.py / cli / tests 的快照行号与现行一致，lexer.py 与 parser.py 因本轮两处修复落盘有 +2~+8 行漂移，凡本会话复核过的位置均另注现行行号。
+- **结构口径**（CCG 六要素）：本报告按仓库惯例组织——功能名（标题）/ 生效条件（范围与口径行）/ 子功能（第二~五节：遗留收口、发现、修复、遗留）/ 执行与验证方式（第六节：实跑命令与结果）/ 不适用条件（第七节：跳过与未运行项）。
+
+---
+
+## 一、执行摘要
+
+本轮自主迭代做两件事：先收口 v1 报告 compiler/md_cg 组全部 3 项遗留缺陷（audit 外部验证器 NameError、api LLM 辅助 NameError、parser 指令吞噬语句开头关键字），再对 compiler 域做第 3 轮深挖，产出并确认 20 个候选（候选→确认零差值）。确认项按问题族分布：
+
+1. **静默语义丢失族**（4 项，parser/lexer）：CJK 标识符分支吞并内嵌「于」（N1，已修，数值操作数凭空消失）、parse 循环双推进吞掉句号后首 token（N2，已修，与 v1 #18 同一缺陷）、条件/函数体多语句静默泄漏顶层（N4）、字符串到 EOF 未闭合零诊断（N5）；
+2. **约束绕过族**（1 项）：「伴侣」条件空间情感权重上限 0.15 的名实校验对无空格自然中文写法完全失效（N6）——项目自家 api.py 模块自测样例即走在失效路径上；
+3. **代码生成产物可靠性族**（5 项，全部遗留）：字符串内容未转义可击穿引号边界（N11）、五类 parser 节点静默丢弃（N12）、表达式位置写行中 `#` 注释产出必坏代码（N13）、多术曰块同名 `def` 互相覆盖（N14）、footer 无条件调用未定义函数（N15）；
+4. **API 契约/死配置族**（4 项）：strict 是纯死配置（N7）、验证单元终裁否决分支不可达（N8）、LLM 建议计算后静默丢弃（N9）、validate_source 声明不生成代码实则全量生成（N10）；
+5. **测试面假保障族**（5 项）：两处「被测源编译失败 → 用例无声消失、套件仍全绿 exit 0」的静默跳过洞（N16、N17）、序列化往返用例使用 VM 永远执行不了的伪造操作码（N18）、恒真死断言（N19）、断言文案与被测源数值不符（N20）；
+6. **健壮性**（1 项）：非法数值毒 token 击穿解析器裸 `float()`（N3）。
+
+**修复口径说明**：任务输入报「新修复 2」。本会话逐项核对现行代码：确认 20 项中被完整修复的恰为 2 项（N1、N2，均带自述缺陷注释的落盘修复，见第四节），其余 18 项现行代码缺陷机制均在位——与输入口径一致，无第三项。
+
+**重复记录说明**：N2 与 v1 报告 #18（parser.py 双推进吞语句，v1 时未修复）为**同一缺陷**——第 3 轮深挖重新发现并补充了第二条触发路径（「无法解析的语句开头」错误分支同样先自行推进），随后落盘修复。本报告按第 3 轮输入原样编号 N2 计入 20 项确认清单，并在此声明与 v1 #18 的同一性（一次修复同时关闭两条记录）。
+
+**对输入口径的两处修正**（本会话实测与输入描述的出入，如实声明）：
+- **N3**：输入称『甲 = .』「直接令编译链抛未捕获 ValueError 崩溃」。实测经 `compile_source` 入口**不崩**——`_read_number` 发毒 token 的同时记录了词法错误，api.py:134-136 词法错误提前返回把崩溃拦在解析器之前（返回 success=False 且错误可见）。未捕获 ValueError 崩溃路径实测存在于 **parse_source/parse_tokens 直连**（见第三节 N3 行）。缺陷本身（毒 token 照发 + parser 无防护裸 `float()`）成立，严重面收窄为 Parser API 层健壮性。
+- **N6**：输入列出的根因②（`_merge_identifiers` 把『情感权重于』+『0』+『.9』并成单标识符、数值字面量消失）**已被 N1 的 lexer 修复顺带消除**——现行无空格源码里 0.9 已以 Lit(0.9) 存活。绕过仍成立，现存根因仅①（条件空间切换检测要求 COMPARISON 节点，无空格写法产出单个 IDENTIFIER，检测永不触发）。
+
+---
+
+## 二、第 1 轮遗留修复（3 项全部落盘）
+
+对应 v1 报告第二节 #6（high）、#21（medium）、#22（medium）。三项修复均为工作树未提交改动，本会话以现行代码读核 + 修复后行为实跑验证：
+
+| # | v1 编号 | 位置 | 修复内容 | 本会话验证 |
+|---|---------|------|----------|-----------|
+| L1 | #6（high） | md_cg/audit.py:349 | `sys.stderr.write` → `_sys.stderr.write`：模块级仅 import json/os/re，函数内 :323 `import sys as _sys`，修复取 `_sys` 写法（与 :339 已有的 `_sys.modules[__name__]` 同风格，不改模块级导入面） | 读核：现行 audit.py:339/:349 均为 `_sys` 写法；实跑 `python -c "import md_cg.audit as a; a.load_external_verifiers('json')"` 输出 `[mdcg-audit] 已加载外部验证器模块: json`，返回 `loaded:['json'] failed:[]`（修复前该命令必 NameError）。回归：`python -m md_cg.test_hyperedge` 29 通过、`python -m md_cg.test_audit_rotate` 28 pass / 0 fail |
+| L2 | #21（medium） | compiler/api.py:13 | 导入行补 `NodeType`：`from .parser import parse_tokens, ProgramNode, NodeType`——`_ast_to_text`（api.py:261-275）5 处引用 `NodeType.*`，此前因 :172-175 异常转 warnings 表现为 llm_assist 整体静默失效 | 读核：现行 api.py:13 含 NodeType；实跑 `_ast_to_text(parse_source('若 甲 问曰 则 道 新路径。')[0])` 正常输出 `'条件语句: 若 甲\n术曰块: 0 个步骤'`（修复前必 NameError） |
+| L3 | #22（medium） | compiler/parser.py:722-741 | `_INST_STOP` 元组补 DANG（当）/ZHIXING（执行）/DINGYI（定义）/FANHUI（返回）四行，与 `_STOP` 及 parse_statement 分派的语句开头关键字对齐；:703 生效条件注释本就写明「及各语句开头关键字」，修复后代码与文档契约一致 | 读核：现行 parser.py:730-753（漂移后）四关键字在位；实跑 `parse_source('道 新路径 当 计数 小于 3 执行 道 新信任路径。')` → 2 条语句 = InstructionStmtNode(道,[新路径]) + LoopStmtNode（体内指令保留）；边界 `'道 新路径 返回 0'` → Instruction+Return 两句，均无 parse_err |
+
+**红守卫建议**（三项均未落盘，为任务输入所附思路，本报告如实转述未实测）：L1——单测设 `MDCG_VERIFIER_MODULES=json` 调 `load_external_verifiers`，断言 `'json' in rep['loaded']`（修复前因 NameError 必红）；L2——单测断言 llm_assist+stub 桥编译后 `result.warnings` 不含「LLM 辅助失败」（修复前必红）；L3——单测断言上述循环源语句数为 2 且第二句为 LoopStmtNode（修复前必红）。
+
+---
+
+## 三、第 3 轮新发现（确认 20 项）
+
+状态取值：**已修复** / **未修复（遗留）**。证据口径：**20 项全部经本报告写作者本会话独立验证**（读码 + 运行复现；两项测试面静默跳过洞以 monkeypatch 复跑；N19 为读码逻辑证明——`"def halt" in code` 蕴含 `"halt" in code`，断言在 :182 前置检查通过的前提下不可能失败）。本表无「仅输入复核」项。
+
+### high（6 项）
+
+| # | 位置 | 缺陷摘要 | 状态 | 证据（本会话） |
+|---|------|----------|------|------|
+| N1 | compiler/lexer.py:380-383（_segment CJK 分支） | CJK 标识符分支无条件吞并内嵌关键词：标识符起始字符不构成关键词时，整段 CJK run（含「于/为/且/加/减/乘/除」等单字关键词）被整体收作 IDENTIFIER，而 ASCII 分支（:385-391）有 has_kw_ahead 前瞻在关键词前断开——两分支行为不对称。后果：『止情感权重于0.15。』词法产出 ZHI+ID(情感权重于)+ID(0)+NUMBER(.15)，经 parser.py:798-805 `_merge_identifiers` 合并成 止+[ID("情感权重于0.15")]——数值操作数消失、零错误，直接违背 parser.py:711-713 文档断言『止 + [ID(情感权重)] + [Lit(0.15)]』；名实校验环看到的也是被污染的名字。ASCII 名正常（『止 trust 于 0.15。』→ ZHI+ID(trust)+YU+NUMBER(0.15)） | **已修复**（F1） | 读核 + 实跑：现行 lexer.py:380-397 断开逻辑在位；`parse_source('止情感权重于0.15。')` → `[ID(情感权重), Lit(0.15)]` 零错误（与 parser.py:721 现行文档断言一致），`'止 trust 于 0.15。'` → `[ID(trust), Lit(0.15)]` 两条路径对称 |
+| N2 | compiler/parser.py:349-351（parse 循环 else 分支） | 双推进静默吞语句：_parse_statement 的 PERIOD 分支（快照 :401-403，现行 :408-411）与「无法解析的语句开头」错误分支（快照 :406-410，现行 :413-418）返回 None 前已 `_advance()` 消费当前 token，parse() 的 else 分支对 falsy 返回值无条件再推进一次——把句号/坏 token 之后的下一个 token 一并吞掉。后果：『道 新路径。德 旧路径。』第二条指令助记符「德」被静默丢弃，「旧路径」沦为顶层裸 IdentifierNode，语义丢失且 PERIOD 路径零错误记录。与 v1 #18 同一缺陷（本条补充错误分支第二条触发路径），见第一节重复记录说明 | **已修复**（F2） | 读核 + 实跑：现行 parser.py:341+350-359 条件推进在位；`parse_source('道 新路径。德 旧路径。')` → 2 条 INSTRUCTION_STMT（DAO[新路径] + DE[旧路径]），parse_err=[]（修复前仅 1 条 + 德被吞） |
+| N6 | compiler/api.py:158-167 + name_checker.py:804-828,795-801 + parser.py:762-763,781-800 | 「伴侣」条件空间情感权重上限 0.15 的名实校验对无空格自然中文写法完全失效：『若条件空间为伴侣，则止情感权重于0.9。』编译成功、零错误零警告。根因（现行仅存①，见第一节口径修正）：词法把『条件空间为伴侣』切成单个 IDENTIFIER（「为」不在 CJK 断开集合），条件节点是 IDENTIFIER 而非 COMPARISON，name_checker.py:813-819 的切换检测（要求 COMPARISON+left.name=='条件空间'）永不触发，current_condition_space 恒 None，:795-801 的 0.15 上限检查即使有 Lit(0.9) 也无空间可查。api.py:346 模块自测『完整流水线测试』用的正是这种无空格写法——旗舰示例走在保护失效路径上 | 未修复（遗留） | 实跑：无空格版 compile_source → success=True、errors=[]、warnings=[]，条件节点 IDENTIFIER('条件空间为伴侣')、then 操作数 [ID(情感权重), Lit(0.9)]（字面量存活、检查仍不触发）；对照空格版 `'若 条件空间 为 伴侣，则 止 情感权重 于 0.9。'` → success=False，错误「在「伴侣」条件空间中情感权重不可超过 0.15，当前值: 0.9」——守卫本身在位，只对分词形态挑剔 |
+| N11 | compiler/codegen.py:343,348,424 | 字符串字面量/标识符内容未做任何转义直接内插进生成代码：`f'"{op.name}"'`、`f'"{op.literal_value}"'`（表达式侧 :424 同型）——内容含 ASCII 双引号即击穿引号边界（全角引号包裹的字符串内容可合法含 ASCII `"`），含反斜杠还有语义漂移（字面 a\nb 在产物中变换行符）。白名单代码生成可被源码字符串内容逃逸，且编译仍报 success=True | 未修复（遗留） | 实跑：`compile_source('道 “含"引号”。')` → success=True，生成行 `_runtime.create_path("含"引号")  # 道（创建路径）`，产物 `compile()` 抛 **SyntaxError: unterminated string literal** |
+| N12 | compiler/codegen.py:292-310 | `_generate_statement` 分派表缺 LOOP_STMT/FUNC_DEF/RETURN_STMT/BLOCK/CALL_EXPR 五种 parser 产出的节点类型，else 分支（:309-310）只 warnings.append 不生成任何代码——循环、函数定义、返回语句在 Python 代码生成路径被静默丢弃，语义漂移且编译仍报成功 | 未修复（遗留） | 实跑：`compile_source('当 计数 小于 3 执行 德 0.1。')` → success=True、warnings=['L1 未处理的语句类型: LOOP_STMT']、产物中无任何 while（code has while: False） |
+| N13 | compiler/codegen.py:429-430 | `_gen_expression` 对未支持类型（CALL_EXPR/UNARY_EXPR 等）在表达式位置用 `_write` 写 '#' 注释——注释落在行中间使语句残缺，生成必然无法 compile 的非法代码 | 未修复（遗留） | 实跑：`compile_source('甲 = 乙（1）。')` → success=True，生成行 `甲 = # 未支持的表达式: CALL_EXPR`，产物 `compile()` 抛 **SyntaxError: invalid syntax** |
+
+### medium（8 项）
+
+| # | 位置 | 缺陷摘要 | 状态 | 证据（本会话） |
+|---|------|----------|------|------|
+| N3 | compiler/lexer.py:432-437（_read_number，现行 :445-451）→ parser.py:977（现行 :984-985） | 非法数值毒 token：_read_number 在 float() 抛 ValueError 时记录「非法数值」错误却仍 `_emit(NUMBER, num_str)` 发出该 token；下游 parser 对 NUMBER 值无条件 float()（:984-985，同型还有 :441 的 int(float())、:775、:835-846），无防护。经 compile_source 入口被词法错误提前返回拦住（见第一节口径修正），但 parse_source/parse_tokens 直连即未捕获 ValueError 崩溃，而非带着已记录的词法错误优雅失败 | 未修复（遗留） | 实跑：`parse_source('甲 = .')` → **ValueError: could not convert string to float: '.'**（崩溃栈落在 parser.py:984 `LiteralNode(float(self.current_token.value)...)`）；同源 `compile_source('甲 = .')` → 不崩，success=False、errors=["L1:C5 非法数值: '.'"] |
+| N4 | compiler/parser.py:617（_parse_func_def body，现行 :625）与 :552（_parse_condition then_body，现行 :560），文档 :147、:189 | 条件/函数体多语句静默泄漏顶层：ConditionStmtNode/FuncDefNode 文档均声称「body 可为语句列表/可为块」，但两处实际调 `_parse_single_statement`（:676-709 只解析恰好一条、永不返回 BlockNode）；随后 `_skip_punctuation_before(FOUZE)`（:564）把『；』一并跳过。『若 条件空间 为 伴侣 则 道 新路径；德 旧路径。』的「德 旧路径」泄漏为顶层无条件语句，语义从「仅条件成立才执行」漂移为「恒执行」，零错误；同写法在循环体（_parse_statement_or_block，:639-673，『；』续接成块）却正确收进块内——同一分隔符两套语义 | 未修复（遗留） | 实跑：`parse_source('若 条件空间 为 伴侣 则 道 新路径；德 旧路径。')` → 顶层 [CONDITION_STMT, INSTRUCTION_STMT]，parse_err=[]（「德 旧路径」确在顶层） |
+| N7 | compiler/api.py:27-30,100-194 + cli/__init__.py:37-38,128,169 | CompileOptions.strict 注释声明『严格模式（警告视为错误）』、CLI 暴露 --strict/--no-strict（默认 True，help 同文案）并透传进 CompileOptions，但 compile_source 函数体从不读取 options.strict——警告永不升级为错误，严格模式是纯死配置。同定义处的 output_format/include_comments/indent_size 三选项全包零消费（仅定义与注释出现）。注：compiler/compiler.py:254 的同名 strict 参数属另一条字节码编译链（analyzer/pbc 面），与本项无关 | 未修复（遗留） | 读核 + grep：`grep -rn "strict\|output_format\|include_comments\|indent_size" compiler/ --include=*.py`（排除 tests）——strict 的 CompileOptions 写入点仅 cli :128/:169、api.py:208（validate_source 重建）、api.py:358（自测），api.py:100-194 函数体零读取；三选项除 api.py:28-30/:197 外零命中 |
+| N8 | compiler/api.py:183-188 + 296-322 | 第六步「验证单元终裁」的否决分支不可达：_verification_verdict 仅检查 result.errors（:303），但调用点 :184 之前词法（:134-136）/语法（:154-156）/名实（:165-167）错误均已提前 return，LLM 失败只进 warnings（:174-175）、codegen 只 extend warnings（:181）——到达终裁时 errors 恒空，verdict 恒 passed=True/confidence=0.85，:187-188 否决追加是死代码；真正有错的编译在提前返回时 result.verdict 保持 None——验证单元恰在需要否决的场景缺席，只在必过的场景盖章（:310-314 注释自认信任值/条件空间检查为『简化实现』占位） | 未修复（遗留） | 读码证明（errors 在 :184 恒空的四条路径逐一核对）+ 实跑探针：两条带错编译（名实错误路径）result.verdict 均为 **None**（验证单元缺席）；对照 N12 行带 warning 编译 success=True——到达第六步者只可能是无错编译 |
+| N14 | compiler/codegen.py:380 | _gen_shuyue 对每个术曰块恒输出同名 `def protocol_procedure():`——源程序含多个术曰块时后者覆盖前者，前面的术曰块静默变 dead code，语义丢失无任何警告 | 未修复（遗留） | 实跑：`compile_source('术曰：1。德 0.1。\n术曰：1。德 0.2。')` → 产物含 **2 个** `def protocol_procedure():`，success=True、warnings=[] |
+| N15 | compiler/codegen.py:280-282 | _write_footer 无条件生成 `protocol_procedure()` 调用，但该函数仅在源程序含术曰块时才被 _gen_shuyue 定义——无术曰的合法程序产物以 __main__ 运行必 NameError；且 footer 自带注释（:280-281）仍在描述「调用不存在的 main() 必然 NameError」的旧缺陷，注释与现行代码不一致（该注释系 v1 F5 修复时遗留） | 未修复（遗留） | 实跑：`compile_source('道 新路径。')` → 产物真定义行 0 条、调用行 1 条（`    protocol_procedure()`），`exec(code, {'__name__':'__main__'})` 抛 **NameError: name 'protocol_procedure' is not defined**，而 compile_source 仍 success=True |
+| N16 | compiler/tests/test_func_compile.py:86-95 | 用例⑤声称钉死「顶层 RETURN = 程序结束（无调用者时 halt）」语义（:86 注释），但测试源码从未执行过任何顶层 RETURN：src5 为「定义 早退（）：返回 7；止。」——函数只定义未被调用，返回 7 在函数体内不会执行，check 只断言 st5["halt"]=="halt"（来自末尾的止）。真正要钉的顶层 RETURN 行为（condition_vm.py:302 无调用帧时 raise VMHalt）零覆盖，该语义若回归无测试拦截。且该用例无 else 分支：编译失败时连一条 check 都不记录 | 未修复（遗留） | 读核（:86-95 结构在位）+ monkeypatch 复跑：patch compiler.compiler.compile_source 仅使 src5（含「早退」）返回 ok=False 后经 runpy 重跑本文件——套件输出「**9/9 通过**」、exit 0，⑤ 的 check 从输出中完全消失（其余 9 项不受影响） |
+| N17 | compiler/tests/test_loop_compile.py:74-81 | 死循环保护用例⑤「死循环被步数上限拦截」存在静默跳过洞：若 src5 编译失败，try/except 整段位于 `if r5["ok"]:` 之内且无 else 记账——恰好是防死循环这个安全网的回归测试，在它的被测源无法编译时会自行无声通过。同文件④（:62-67）与⑦（:99-106）同模式：三份独立源码均无编译成功断言，①a 只覆盖与 src3 相同的源 | 未修复（遗留） | 读核（:69-81 结构在位）+ monkeypatch 复跑：patch 仅使 src5（「当 计数 大于 0 执行 德 0.1」）返回 ok=False 后重跑——套件输出「**10/10 通过**」、exit 0，⑤ 的 check 完全消失 |
+
+### low（6 项）
+
+| # | 位置 | 缺陷摘要 | 状态 | 证据（本会话） |
+|---|------|----------|------|------|
+| N5 | compiler/lexer.py:451-464（_read_string，现行 :456-478） | 字符串到 EOF 未闭合不报错：只在串内先遇换行时记录「字符串未闭合」（:467-469），引号未闭合直到源码结束则循环因 pos 达 len(source) 退出、无错误追加，照常 _emit(STRING)——畸形输入静默通过词法环，内容边界失真（吞掉其后所有字符）却零诊断，与换行路径处理不一致 | 未修复（遗留） | 实跑：`tokenize('"未闭合到EOF')` → errors=[]，tokens=[STRING('未闭合到EOF'), EOF]（其后全部字符被吞、零诊断） |
+| N9 | compiler/api.py:170-175,228-253 | LLM 辅助建议计算后被静默丢弃：`llm_suggestions = _llm_assist(...)` 赋值后再未被读取，不进入 result.warnings/verdict/code 任何字段，CompileResult 也无承载字段——--llm-assist 开启并成功调用桥接时，辞意/说故建议对调用方完全不可观测；该功能唯一可见效果是桥接抛异常时多一条「LLM 辅助失败」警告 | 未修复（遗留） | 读核 + 探针：`inspect.getsource(compiler.api).count('llm_suggestions') == 2`（仅 :170 初始化与 :173 赋值，全文件无第三个引用点） |
+| N10 | compiler/api.py:198-212 + cli/__init__.py:44 | validate_source docstring 声明『仅校验（不生成代码）』、CLI check 子命令 help 同称『不生成代码』，但实现直接调 compile_source——完整执行第五步 CodeGenerator.generate 生成全部 Python 产物后丢弃；同时 :206-210 无条件重建 CompileOptions，把调用方传入的 output_format/include_comments/indent_size 静默清回默认值。IDE 实时检查/CI 预检场景为每条源码白白支付整个代码生成成本 | 未修复（遗留） | 读核：api.py:198-220（docstring + :206-210 重建 + :212 直调 compile_source）、cli/__init__.py:44（help 文案）与 :169（check 路径构造 CompileOptions）逐点在位 |
+| N18 | compiler/tests/test_pbc.py:19-20 | 序列化往返一致性用例①使用封闭指令集之外的操作码：数据里的 ("PUSH", True) 与 ("STORE", "甲") 在 Opcode 枚举（共 25 条指令）中不存在。pbc.serialize/deserialize 对 op 名是纯字符串透传不校验（pbc.py:14-16 `_op_name`、:23-26 写入、:108 读回均无校验），该往返恒等成立；但这种字节码一旦经 run_pbc/debug_pbc 的 Opcode[name] 转换必 KeyError——测试用编译器永远产不出、VM 永远执行不了的伪造指令验证「.pbc 往返一致」，指令名漂移类缺陷在①处零拦截（仅④兜底真实指令） | 未修复（遗留） | 读核（:19-20 伪造操作码在位；pbc.py:14-16/:108 透传无校验）+ 探针：`Opcode['PUSH']`/`Opcode['STORE']` 均 **KeyError**（NOT in enum），对照 `Opcode['DAO']` 正常 |
+| N19 | compiler/tests/test_full_pipeline.py:189 | 「指令调用生成」断言恒真（死断言）：`assert "_runtime.halt" in code or "halt" in code` 的第二析取支已由前面对照表 ("def halt", "止指令实现") 的 assert found（:182）保证——"def halt" 是 code 子串蕴含 "halt" 是子串。该断言在 :172 检查通过的前提下不可能失败，声称验证「应生成 halt 调用」实际什么都没验证（如生成代码只有 def halt 定义而无任何 `_runtime.halt(...)` 调用点时依然通过） | 未修复（遗留） | 本会话验证（读码逻辑证明）：:171 对照表含 ("def halt", "止指令实现")、:178-182 循环对其 assert found、:189 双析取断言——前者为真恒使后者为真，无运行时依赖 |
+| N20 | compiler/tests/test_compiler_c2.py:87 | 断言文案与被测源码不符：check 名称写「⑥b 算术比较执行（5>4 真→德执行）」，但源码（:80）是「若 4 大于 3，则 德 0.2」——比较对象是 4>3 而非 5>4。断言本身（trust==0.2）与源码一致可过，但用例自述的数值凭据是错的，排障时按「5>4」核对源码会扑空 | 未修复（遗留） | 本会话验证（读码）：:80 源码「若 4 大于 3，则 德 0.2」与 :87 文案「5>4」并排比对，操作数无一为 5 |
+
+---
+
+## 四、新修复清单（2 项）
+
+以下均为工作树未提交改动，本会话读核 + 实跑验证：
+
+### F1（对应 N1，high）lexer.py `_segment` CJK 分支「于」断开
+- lexer.py:380-397（现行）：CJK run 收集循环内新增前瞻断开——`any(text.startswith(k, i) for k in ("大于", "等于", "小于", "于"))` 即 break。前瞻集合含以「于」结尾的比较词且断点落在多字词起点（主循环最长匹配不能跨越断点，否则「大于」碎成 ID 尾字+孤立 YU）；其余关键词（乘/加/为/且…）不在此断开——运算词内嵌于名词是合法标识符（「阶乘」「加权」），全量前瞻会把它们切碎，保留 docstring 的整段保护规则。
+- 效果实测：『止情感权重于0.15。』→ 止 + [ID(情感权重)] + [Lit(0.15)]，与 parser.py:721 文档断言一致；ASCII 名『止 trust 于 0.15。』行为不变——两分支对称性恢复。附带效应：N6 的根因②（合并吞数值）随之消除（见第一节口径修正）。
+- 回归：compiler 8 套全绿（含 test_loop_compile 11/11、test_pbc 5/5——后者步骤源码含「信任值大于0.7」形态，验证「大于」未被误切）。
+
+### F2（对应 N2 = v1 #18，high）parser.py parse() else 分支条件推进
+- parser.py:341+350-359（现行）：循环体先快照 `start_pos = self.pos`；`_parse_statement` 返回 falsy 时仅在 `self.pos == start_pos`（确实未消费任何 token）才 `_advance()`——防死循环兜底，现行各 None 分支（PERIOD :408-411、无法解析 :413-418、定义缺函数名 :602-604）均已自行推进，兜底不触发。注释明述旧双推进会吞掉「道 A。德 B。」的「德」。
+- 效果实测：『道 新路径。德 旧路径。』→ 2 条指令语句（德+旧路径完整保留），parse_err=[]；一次修复同时关闭 v1 #18 与 N3 轮 N2 两条记录。
+- 回归：compiler 8 套全绿。
+
+---
+
+## 五、遗留项（未修复 18 项）
+
+按模块分组，供后续批次排期：
+
+| 模块 | 数量 | 编号（严重度） |
+|------|------|----------------|
+| compiler/codegen.py | 5 | N11 字符串未转义（high）、N12 五类节点静默丢弃（high）、N13 表达式行中注释（high）、N14 同名 def 覆盖（medium）、N15 footer 未定义调用（medium） |
+| compiler/api.py（跨 name_checker/parser） | 5 | N6 伴侣上限无空格失效（high）、N7 strict 死配置（medium）、N8 终裁橡皮图章（medium）、N9 LLM 建议丢弃（low）、N10 validate_source 全流水线（low） |
+| compiler/tests | 5 | N16 函数套件⑤静默跳过（medium）、N17 循环套件⑤静默跳过（medium）、N18 伪造操作码（low）、N19 恒真断言（low）、N20 文案不符（low） |
+| compiler/parser.py | 1 | N4 条件/函数体泄漏顶层（medium） |
+| compiler/lexer.py | 2 | N3 毒 token 击穿裸 float()（medium，Parser API 层）、N5 字符串 EOF 零诊断（low） |
+
+优先级建议：codegen 三 high（N11/N12/N13）同族同修——白名单产物可被源码字符串内容击穿且必坏代码仍报成功，修复面集中在 `_gen_expression`/`_gen_instruction` 转义 + `_generate_statement` 补齐五类节点；N6 次之（旗舰自测样例即在失效路径，修法明确：条件空间检测对 IDENTIFIER 形态的条件节点补「条件空间为X」模式匹配，或词法层把「为」纳入 CJK 断开集合——后者需评估「作为」「行为」类名词的误切代价）；N4/N3 为 parser 健壮性；N16/N17 修复成本极低（if ok: 补 else 记账一条 check），建议随下批顺手清账。
+
+---
+
+## 六、测试验证结果
+
+以下命令均为本会话实际运行（Windows，仓库根目录，python -X utf8），非转述：
+
+| 命令 | 结果 | 退出码 |
+|------|------|--------|
+| `python compiler/tests/test_c4_tooling.py` | 8/8 通过 | 0 |
+| `python compiler/tests/test_compiler_c2.py` | 12/12 通过 | 0 |
+| `python compiler/tests/test_condition_vm.py` | 13/13 通过 | 0 |
+| `python compiler/tests/test_defect_regression.py` | 18/18 通过 | 0 |
+| `python compiler/tests/test_full_pipeline.py` | 全部通过（「协议编译器 v0.2 就绪」） | 0 |
+| `python compiler/tests/test_func_compile.py` | 10/10 通过 | 0 |
+| `python compiler/tests/test_loop_compile.py` | 11/11 通过 | 0 |
+| `python compiler/tests/test_pbc.py` | 5/5 通过 | 0 |
+| `python -m md_cg.test_hyperedge` | 29 通过（L1 回归：该套件直接调用 load_external_verifiers） | 0 |
+| `python -m md_cg.test_audit_rotate` | 28 pass / 0 fail（L1 回归） | 0 |
+
+**复现/探针脚本**（本会话临时脚本，非测试套件，关键输出已在第三节证据列逐项引用）：三个遗留修复的修复后行为验证（L1 外部验证器加载、L2 `_ast_to_text`、L3 循环源 2 语句）；F1/F2 效果对照（无空格/ASCII 双形态、双语句保德）；N3 双入口对照（parse_source 崩溃栈 vs compile_source 优雅失败）；N4/N5/N6/N8/N9/N11-N15 运行复现；N16/N17 monkeypatch 静默跳过复跑（runpy 重跑套件文件）；N18 Opcode 探针。
+
+**合计**：compiler 8 套（85+ 用例）+ md_cg 2 套（57 用例）全绿，与任务输入「回归：全绿」一致。本轮全部改动文件（lexer.py/parser.py/api.py/audit.py）均有对应套件覆盖。
+
+**未运行项（如实说明）**：第二节红守卫均为建议、未落盘（无新测试可跑）；v2 报告的 hive/swarm 面 7 套本轮未复跑——本轮改动不触及该域，正确性证据沿用 v2 报告第六节；N19 为读码逻辑证明，未做运行时演示（构造「只有 def 无调用点」的产物属假想变体，非现行编译器行为）。
+
+---
+
+## 七、跳过项及原因
+
+**无**。本轮无任何确认缺陷被主动跳过：20 项确认中 2 项已修复（第四节）、18 项列入遗留清单（第五节）。候选 20 与确认 20 零差值，无「复核未确认」明细需要声明。另：第一节两处对输入口径的实测修正（N3 崩溃面收窄、N6 根因②随 F1 消除）非跳过，系如实记录。
+
+---
+
+*报告依据：任务输入的第 3 轮深挖结论（遗留修复 3 / 候选 20 → 确认 20 / 新修复 2 / 回归全绿，及 20 项缺陷明细与复现描述）；本会话的现行代码逐项读核（lexer/parser/api/codegen/name_checker/cli/pbc/五测试文件/audit）、修复后行为与缺陷复现实跑（含 N16/N17 monkeypatch 复跑）、以及 10 套回归实测。*

package/docs/eval//347/274/272/351/231/267/346/214/226/346/216/230_/350/207/252/344/270/273/350/277/255/344/273/243_v4.md

@@ -0,0 +1,128 @@
+# 缺陷挖掘报告 · 自主迭代 v4
+
+- **日期**：2026-09-25
+- **范围**（生效条件）：第 3 轮遗留 codegen 域四项修复的落盘核验与效果实测（N11 字符串未转义 / N12 五类节点静默丢弃 / N13 表达式行中注释 / N15 footer 未定义调用）+ 修复验证过程中的一项新发现（N21，名实校验分派缺口）
+- **总量**：修复 4 / 4 落盘；跳过 0
+- **严重度口径**：任务输入四项均记 high。其中 N11/N12/N13 与 v3 报告一致（high）；**N15 在 v3 报告记 medium，本轮任务输入记 high**——本报告如实双记，判定依据（footer 对无术曰程序 100% 触发 NameError、产物不可运行）确属结果级缺陷，升 high 可接受。
+- **回归**：compiler 8 套全绿（本会话实跑，见第五节）；全量回归本会话实跑 **163/163 通过、5 跳过、退出码 0**——与任务输入「全量回归: 有失败」**不一致**，本会话未能复现该失败（输入未附失败明细，见第五节口径出入声明）。
+- **行号口径**：本轮修复位置行号均为现行工作树行号（本会话逐处读核）；引用 v3 报告处标注其为第 3 轮时点行号。
+- **结构口径**（CCG 六要素）：本报告按仓库惯例组织——功能名（标题）/ 生效条件（范围与口径行）/ 子功能（第二~四节：修复明细、新发现、遗留清账）/ 执行与验证方式（第五节：实跑命令与结果）/ 不适用条件（第六节：跳过与未运行项）。
+
+---
+
+## 一、执行摘要
+
+本轮收口 v3 报告遗留清单中 codegen 域 5 项里的 4 项（N11/N12/N13/N15），全部落盘为工作树未提交改动。四项同属「代码生成产物可靠性族」——此前白名单产物可被源码字符串内容击穿、五类语法节点静默蒸发、表达式位置产出必坏代码、无术曰程序产物必 NameError，且四条路径编译均报 success=True。修复后实测：注入 payload 被完整封在字符串字面量内（AST 解析零逃逸调用点）、循环/函数/返回/调用在产物中语义在位、四类探针产物全部通过 `compile()`、无术曰产物 `exec(__main__)` 正常运行。
+
+验证过程中发现一项**相邻新缺陷 N21**（medium 候选）：name_checker 的语句分派与修复前的 codegen 同型缺 FUNC_DEF/RETURN_STMT/CALL_EXPR 三分支——函数体内名实规则（含条件空间情感权重上限）整体失效，实据：同一条「止 情感权重 于 0.9」在伴侣条件空间下顶层被拦（success=False）、包进函数体后零拦截（success=True 仅 warning）。
+
+**对输入口径的一处修正**（如实声明）：任务输入称「全量回归: 有失败」。本会话实跑仓库全量入口 `python scripts/run_tests.py` 结果为 163/163 通过、5 跳过（依赖缺失/平台不符的既定跳过）、退出码 0；补跑 hive 的 Rust 面 `cargo test` 亦 29 通过 0 失败。两个已跑面均未复现「有失败」，输入未附失败套件名与错误明细，本会话无法进一步定位——不排除输入口径生成于修复收口前的中间时点，或所指为未纳入 run_tests.py 的面（如 Docker Linux 验证脚本，见第六节）。
+
+---
+
+## 二、修复明细（4 项全部落盘，本会话逐项读核 + 实跑验证）
+
+### F1（对应 N11，high）字符串字面量/标识符内容 json.dumps 转义
+
+- **位置**（现行）：codegen.py:362-372（`_gen_instruction` 参数收集）、codegen.py:496-497（`_gen_expression` 非数字 LITERAL）；快照时点行号 343/348/424（v3 报告）。配套 `import json`（:7）。
+- **修复方式**：标识符名与字符串字面量内插前一律 `json.dumps(..., ensure_ascii=False)`——ASCII 双引号/反斜杠/控制符全部转义，引号边界不可击穿；中文经 `ensure_ascii=False` 原样保留。
+- **本会话验证**（探针实跑）：
+  - 引号击穿：`compile_source('道 “含"引号”。')`（全角引号包裹、内容含 ASCII 双引号）→ 生成行 `_runtime.create_path("含\"引号\"")`，产物 `compile()` OK。v3 时点同源产物为 `create_path("含"引号")` → SyntaxError: unterminated string literal。
+  - 反斜杠语义：`道 “a\nb”。` → `"a\\nb"`，`compile()` OK，字面 a\nb 不再漂移为换行符。
+  - 注入逃逸（权威验证，AST 解析产物）：payload `x") or __import__("os").getcwd() #` 全文置于字符串内容 → `ast.parse` 产物后 create_path 调用参数恰为**单个等于 payload 的字符串常量**，全产物 `__import__` 调用点 **0 个**——白名单代码生成不再可被源码字符串内容逃逸，success=True 的产物即安全产物。
+
+### F2（对应 N12，high）`_generate_statement` 分派表补齐五类节点
+
+- **位置**（现行）：codegen.py:319-331 新增五分支（LOOP_STMT :319-322 / BLOCK :323-324 / FUNC_DEF :325-326 / RETURN_STMT :327-328 / CALL_EXPR :329-331）；快照时点 292-310（v3 报告）。配套五个新生成方法：`_gen_loop`（:397-407，当…执行 → while，对齐 VM 路径条件回跳语义）、`_gen_block`（:410-413）、`_gen_func_def`（:416-426，名字/参数经 `_py_name` 校验）、`_gen_return`（:429-435）、`_gen_call_stmt`（:438-441，结果丢弃）及导入面补五类节点类型（:14-15）。
+- **本会话验证**（探针实跑）：
+  - 循环：`当 计数 小于 3 执行 德 0.1。` → 产物含 `while 计数 < 3.0:` 及体内德调用，`compile()` OK；v3 时点产物无任何 while、仅 warning『未处理的语句类型: LOOP_STMT』。
+  - 函数+返回：`定义 加（甲，乙）：返回 甲 加 乙。` → 产物含 `def 加(甲, 乙):` 与 `return 甲 + 乙`，`compile()` OK。
+  - 调用语句：`定义 早退（）：返回 7。 早退（）。` → 产物含调用行 `早退()`。
+  - codegen 自身零 warning（见下述 N21：残留的『未处理的语句类型』warning 来自名实校验链 name_checker.py:531，格式带 `:C` 列号，非 codegen）。
+
+### F3（对应 N13，high）表达式位置不再写行中 '#' 注释
+
+- **位置**（现行）：codegen.py:502-506（CALL_EXPR 表达式分支改调 `_gen_call_expr` 生成真调用）、:507-512（其余未支持类型改 `errors.append` 记错 + `_write("None")` 占位）；快照时点 429-430（v3 报告）。配套 `_gen_call_expr`（:523-531，名字经 `_py_name`）。
+- **本会话验证**：
+  - CALL_EXPR：`甲 = 乙（1）。` → 生成行 `甲 = 乙(1.0)`，`compile()` OK；v3 时点产物 `甲 = # 未支持的表达式: CALL_EXPR` → SyntaxError: invalid syntax。
+  - 其余未支持类型的处置以读核为准（:507-512：记 error 令编译失败、None 占位保产物语法完整，杜绝行中注释）；实测 `甲 = -乙。` 未落该分支——「-乙」经词法/语法收作字符串字面量，产物 `甲 = "-乙"`、`compile()` OK。
+
+### F4（对应 N15，v3 记 medium / 本轮输入记 high）footer 条件调用 protocol_procedure()
+
+- **位置**（现行）：codegen.py:91-93（`_has_procedure` 标志声明）、:105（generate 重置）、:278-292（`_write_footer` 仅当 `_has_procedure` 才生成 `protocol_procedure()` 调用）、:453（`_gen_shuyue` 置位）；快照时点 280-282（v3 报告）。演进链：HEAD 基线 footer 调 `main()`（v1 F5 时点改为无条件 `protocol_procedure()`），本轮改为条件调用，v3 所指旧注释一并更新。
+- **本会话验证**（探针实跑）：
+  - 无术曰：`道 新路径。` → 产物 `def protocol_procedure` 0 条、调用 0 条，`exec(code, {'__name__':'__main__'})` 正常运行（仅打印「协议实例已启动」）；v3 时点同源 exec 必 NameError: name 'protocol_procedure' is not defined。
+  - 含术曰：`术曰：1。德 0.1。` → def 1 条、调用行 1 条（`    protocol_procedure()`），exec OK——术曰语义不受损。
+
+---
+
+## 三、本轮新发现（1 项，未修复）
+
+### N21（medium 候选）name_checker 语句分派缺 FUNC_DEF/RETURN_STMT/CALL_EXPR——函数体内名实规则整体失效
+
+- **位置**：compiler/name_checker.py:493-532 `_check_statement`——分派表含 CONDITION_STMT/LOOP_STMT/BLOCK/INSTRUCTION_STMT/SHUYUE/STEP/ASSIGN_STMT 及四个静默通过类型，**无** FUNC_DEF/RETURN_STMT/CALL_EXPR 分支，:529-532 else 只向 warnings 追加『L{line}:C{col} 未处理的语句类型: {name}』后整体跳过（:492 生效条件注释如实列举了缺口）。与修复前的 codegen N12 同型（分派缺口 + 静默跳过），本轮 codegen 补齐五分支后该缺口暴露在名实校验链。
+- **实据**（本会话探针）：
+  1. `定义 加（甲，乙）：返回 完全未声明名 加 乙。` → success=True、errors=[]、仅 warning『L1:C1 未处理的语句类型: FUNC_DEF』——函数体内名字零校验（对照：顶层指令操作数未声明同样不报，名实校验本不查操作数声明性，本条单独不构成回归）；
+  2. **条件空间约束失效（实质影响）**：`若 条件空间 为 伴侣，则 定义 增（）：止 情感权重 于 0.9。` → success=True、errors=[]、仅 warning；对照同约束语句在条件块顶层 `若 条件空间 为 伴侣，则 止 情感权重 于 0.9。` → success=False、错误『在「伴侣」条件空间中情感权重不可超过 0.15，当前值: 0.9』——**同一条受约束指令包进函数体即完全绕过名实拦截**。
+- **状态**：未修复（不在本轮四项修复范围，本轮验证时新发现）。修法明确：`_check_statement` 补三分支（FUNC_DEF 递归校验 body、RETURN_STMT 校验 value、CALL_EXPR 校验名字与 args）。
+
+---
+
+## 四、遗留清账（v3 遗留 18 → 本轮修 4 → 余 14 + 新增 N21）
+
+| 模块 | 数量 | 编号（严重度沿 v3 口径） |
+|------|------|--------------------------|
+| compiler/api.py（跨 name_checker/parser） | 5 | N6 伴侣上限无空格失效（high）、N7 strict 死配置（medium）、N8 终裁橡皮图章（medium）、N9 LLM 建议丢弃（low）、N10 validate_source 全流水线（low） |
+| compiler/tests | 5 | N16 函数套件⑤静默跳过（medium）、N17 循环套件⑤静默跳过（medium）、N18 伪造操作码（low）、N19 恒真断言（low）、N20 文案不符（low） |
+| compiler/name_checker.py | 1 | **N21 函数体内名实规则失效（medium 候选，本轮新增）** |
+| compiler/codegen.py | 1 | N14 多术曰块同名 `def protocol_procedure` 互相覆盖（medium） |
+| compiler/parser.py | 1 | N4 条件/函数体多语句泄漏顶层（medium） |
+| compiler/lexer.py | 2 | N3 毒 token 击穿裸 float()（medium，Parser API 层）、N5 字符串 EOF 零诊断（low） |
+
+**本轮复核说明**：N14、N6 本会话实跑确认仍在位（N14：多术曰源码产物 2 个 `def protocol_procedure`、success=True 零警告；N6：无空格伴侣源码 success=True 零错误零警告）；其余 11 项（N3/N4/N5/N7-N10/N16-N20）本轮未逐一复验，在位证据沿用 v3 报告第三节本会话时点的实跑记录。v3 遗留清单中 codegen 组仅 N14 未修——v3「三 high 同族同修」的建议本轮已兑现其三（N11/N12/N13），N14 与 N21 同属 codegen/name_checker 的术曰与分派面，可并批处理。
+
+---
+
+## 五、测试验证结果
+
+以下命令均为本会话实际运行（Windows，仓库根目录，`python -X utf8`）：
+
+**compiler 8 套**（与任务输入「compiler 回归: ✅」一致）：
+
+| 命令 | 结果 | 退出码 |
+|------|------|--------|
+| `python compiler/tests/test_c4_tooling.py` | 8/8 通过 | 0 |
+| `python compiler/tests/test_compiler_c2.py` | 12/12 通过 | 0 |
+| `python compiler/tests/test_condition_vm.py` | 13/13 通过 | 0 |
+| `python compiler/tests/test_defect_regression.py` | 18/18 通过 | 0 |
+| `python compiler/tests/test_full_pipeline.py` | 全部通过（「协议编译器 v0.2 就绪」） | 0 |
+| `python compiler/tests/test_func_compile.py` | 10/10 通过 | 0 |
+| `python compiler/tests/test_loop_compile.py` | 11/11 通过 | 0 |
+| `python compiler/tests/test_pbc.py` | 5/5 通过 | 0 |
+
+**全量回归**（仓库定义的全量入口，run_tests.py docstring：「全量」）：
+
+| 命令 | 结果 | 退出码 |
+|------|------|--------|
+| `python scripts/run_tests.py` | **SUMMARY 163/163 通过，5 跳过**（md_cg 3 套依赖白箱库/语料真源本地生成、swarm 2 套负载敏感仅串行——均为脚本既定跳过项） | **0** |
+| `cargo test --manifest-path hive/Cargo.toml` | 21 + 5 + 3 通过，0 失败（hive 工作树含 Rust 改动，补跑确认） | 0 |
+
+**⚠ 全量口径出入声明**：任务输入称「全量回归: 有失败」。本会话实跑上述两个面均全绿、退出码 0，**未能复现该失败**；输入未附失败套件名与错误明细，本会话无法定位差异来源。不排除：输入口径生成于本轮四项修复收口前的中间时点；或所指为 run_tests.py 之外的面（Docker Linux 验证脚本 40 套本轮未跑，见第六节）。本报告以本会话实跑结果为准，不代输入填充失败明细。
+
+**修复效果探针**（本会话临时脚本/内联命令，关键输出已在第二节逐项引用）：N11 引号/反斜杠/注入 AST 三探针（含 `ast.parse` 权威逃逸检验）；N12 循环/函数+返回/调用语句三探针；N13 CALL_EXPR 探针；N15 无术曰/含术曰双探针（`exec(__main__)`）；N14/N6 在位复核；N21 双对照探针（函数体 vs 顶层条件空间拦截）。
+
+**git 工作树核对**：`git diff compiler/` 显示 codegen.py +209/-55（本轮四项修复 + 早期批次累积的工作树改动），test_loop_compile.py 的 diff 系批次 37 用例⑧语义更正（parser 吞错修复配套），与本轮四项无直接关系。
+
+---
+
+## 六、跳过项及原因
+
+- **修复跳过：0**——本轮任务四项全部落盘验证，无主动跳过。
+- **未运行项（如实说明）**：
+  - `scripts/verify_linux.sh`（Docker python:3.12 的 Linux 口径验证，40 套）本轮未跑——清单全部为 md_cg/hive/scripts 面（不含 compiler 套件），与本轮 codegen 修复无覆盖交集，且需拉起 Docker 容器；如需排除「全量失败出自 Linux 口径」的可能，可后续补跑。
+  - swarm 的 bench_swarm_parallel / bench_swarm_scale 两套为全量入口既定跳过（负载敏感仅串行），非本轮新增跳过。
+  - 第四节 11 项遗留（N3/N4/N5/N7-N10/N16-N20）未逐一复验，沿用 v3 记录——本轮修复仅触及 codegen.py，与该 11 项所在文件（lexer/parser/api/tests/name_checker 除 N21 外）无交集。
+
+---
+
+*报告依据：任务输入的第 4 轮结论（修复 4 / 跳过 0 / compiler 回归 ✅ / 全量回归有失败，及四项缺陷明细与 v3 时点行号）；本会话的现行代码逐处读核（codegen.py 四项修复 + name_checker.py 分派）、修复效果与缺陷复现实跑（九组探针，含 AST 权威逃逸检验与 exec 运行验证）、compiler 8 套回归、全量 run_tests.py（163/163）与 hive cargo test（29/29）实测。*

package/docs/eval//347/274/272/351/231/267/346/214/226/346/216/230_/350/207/252/344/270/273/350/277/255/344/273/243_v5.md

@@ -0,0 +1,114 @@
+# 缺陷挖掘报告 · 自主迭代 v5
+
+- **日期**：2026-09-25
+- **范围**（生效条件）：第 5 轮 = swarm 域深挖（新发现 5 项确认）+ 历轮遗留收口（v1/v2/v4 遗留清单中 5 项修复的落盘核验与效果实测）。新发现集中 swarm 消息投递面（收件箱保真/CLI 契约/符号表解析）；遗留修复横跨 compiler（2）/ swarm（1）/ md_cg（2）。
+- **总量**：遗留修复 5/5 落盘；新发现候选 5 → 确认 5（零差值）→ 新修 2 → 遗留新增 3
+- **严重度分布**（新发现确认 5 项）：high 2 / medium 2 / low 1
+- **回归**：全量 `python scripts/run_tests.py` 本会话实跑 **164/164 通过、5 跳过（依赖缺失/平台不符）、退出码 0**——与任务输入「回归全绿」一致；较 v4 的 163 增 1，系本轮新红守卫套件 test_swarm_inbox_delivery 入列（见第六节）
+- **行号口径**：任务输入所附新发现行号为缺陷时点快照行号（swarm.rs :759-774/:991-996）；两项已修复者本会话另注修复后现行行号，三项未修者快照行号与现行一致（本会话逐处读核）
+- **结构口径**（CCG 六要素）：本报告按仓库惯例组织——功能名（标题）/ 生效条件（范围与口径行）/ 子功能（第二~五节：遗留修复、新发现、新修复、遗留清账）/ 执行与验证方式（第六节：实跑命令与结果）/ 不适用条件（第七节：跳过与未运行项）
+
+---
+
+## 一、执行摘要
+
+本轮做两件事：先收口历轮遗留清单中 5 项（L1 api codegen 错误回流、L2 WAL 验签零容错〔v1 #23 / v2 N4〕、L3 name_checker 分派缺口〔v4 N21〕、L4 mdcg `_read` 越界读〔v1 #3〕、L5 mdcos propose 缺省层错位〔v1 #4〕），全部以本会话探针实测修复效果；再对 swarm 域深挖，确认 5 个新缺陷（N22-N26）。
+
+5 项新发现同属「**消息投递保真族**」：两项 high 直击蜂群消息语义正确性——protocol 拓扑下发给 verifier 的消息被每轮『顺延一轮』直至随蜂群结束消亡（从未投递、从未 ACK、水位永不推进，N22）；同轮同源多条路由在收件箱处互相覆盖（载荷静默丢弃而 WAL 两条事件均已 HMAC 签名落盘，审计留痕与实际投递不符，N23）。两项均本轮修复（swarm.rs 修复 #1/#2），并落盘红守卫套件 test_swarm_inbox_delivery.py（两条判别器场景，本会话单跑 12/12）。余三项在位未修：CLI 静默丢弃 condition_space 卡（N24）、CLI 异常面破坏单行 JSON 契约（N25）、`--symbols` 字符串值含 `,`/`}` 时续读位错位（N26）。
+
+**对输入口径的核验**：输入称「修复遗留 5 + 新发现 5 确认→新修 2」。本会话以 `git diff` 工作树 + 逐处读核 + 探针实跑核对：遗留修复恰 5 项（其中 4 项带「2026-09-25 缺陷 #N」编号注释，L1 无编号注释、按 HEAD/工作树对照归位，见第二节 L1 行）；新发现恰 5 项、其中恰 2 项（N22/N23）落盘修复——与输入口径一致，无多无少。
+
+---
+
+## 二、遗留修复（5 项全部落盘，本会话逐项读核 + 效果实测）
+
+| # | 历轮编号 | 位置（现行） | 修复内容 | 本会话验证 |
+|---|---------|------|----------|-----------|
+| L1 | v4 F3 收尾（codegen 错误通道回流，无历轮独立编号） | compiler/api.py:182-184 | `result.errors.extend(gen.errors)`——codegen 错误（未支持表达式类型、非法函数名）回流主结果。HEAD 基线 codegen.py 已声明 `self.errors` 但全文件零 append（死通道）、api 从不读取；v4 轮补了 append（codegen.py:510/:550）仍无人读取——「记 error 令编译失败」名不副实。回流后编译如实失败，且第六步终裁的否决分支对 codegen 错误可达（v3 N8 的「否决不可达」在该路径缓解） | 探针：`定义 +（甲，乙）：返回 甲 加 乙。` → success=False，errors 含「L1 名字 '+' 不是合法的 Python 标识符」与「验证单元否决: 编译错误: …」（终裁否决分支实测触发）；对照 `定义 加（甲，乙）：…` → success=True。归位依据：`git show HEAD:compiler/api.py` 第二步仍为旧写法且无 gen.errors 读取，v1/v4 报告均未记此改动，工作树注释自述回流意图——按排除法归本轮（该项无缺陷编号注释，如实声明） |
+| L2 | v1 #23 / v2 N4（low） | swarm/rust_swarm.py:116-133（except :128） | WAL 验签器逐行 try/except（ValueError/KeyError/TypeError）：畸形/被篡改行（非 JSON、缺 `"payload":`、缺必填键、hmac 非串）计入 bad 并 continue，不再打崩整轮验签——验签器面对的正是被篡改的 WAL，不得自己先崩。注释标记「2026-09-25 缺陷 #2」 | 探针：手工构造 4 行 WAL（签名不符 1 + 半行截断 1 + 非 JSON 1 + 缺必填键 1）→ 返回 `{total:4, bad:4, all_valid:false}`，无异常（旧实现第二条即 JSONDecodeError 崩出）。全套件内亦经 test_rust_swarm 覆盖运行面 |
+| L3 | v4 N21（medium 候选） | compiler/name_checker.py:513-528 | `_check_statement` 补 FUNC_DEF（body 列表/单节点两形态递归）/RETURN_STMT（value 过表达式校验）/CALL_EXPR（函数名 + args 逐个）三分派，注释标记「2026-09-25 缺陷 #3」 | 探针：`若 条件空间 为 伴侣，则 定义 增（）：止 情感权重 于 0.9。` → success=False、errors=〔「L1:C34 在「伴侣」条件空间中情感权重不可超过 0.15，当前值: 0.9」〕、warnings=[]（v4 时点同源零拦截、仅「未处理的语句类型: FUNC_DEF」warning） |
+| L4 | v1 #3（medium） | md_cg/mdcg.py:2039-2046 | `_read` 由裸 `os.path.join(self.root, entry["path"])` 改经 `_node_disk_path(entry)` 统一越界校验（P2-20 同口径），越界抛 ValueError → 返回 (None, None)（不可读即不存在）——检索主读路径与 `_emit` 负记忆读取不再可被污染索引带出 root 外文件。注释标记「2026-09-25 缺陷 #4」 | 探针：临时 root 内投毒索引条目 `{"path": "../outside.md"}`（root 外文件真实存在）→ `_read` 返回 (None, None)，不读外部文件 |
+| L5 | v1 #4（medium） | md_cg/mdcos.py:3574-3578 | `MdCGSecure.propose` 的层校验缺省由 `kw.get("layer") or "contextual"` 改 `kw.get("layer", "knowledge")`——与基类 MdCGOS.propose 的 `layer="knowledge"` 缺省一致，校验层与落盘层不再错位。注释标记「2026-09-25 缺陷 #5」 | v1 复现脚本 `_repro_verify_3536.py` 实跑：S1（knowledge-only 不传 layer）propose **成功**（v1 时点误拒）、S2（contextual-only）**AccessDenied 拒绝**（v1 时点入队成死提案）——两象限均翻正；S3 等价探针：knowledge-only propose→accept → ok=True；S4 对照：显式 layer="contextual" 落盘 layer='contextual' 一致。（该脚本 S4 段自身有 `_j` 未定义脚本缺陷——S2 被正确拒绝后其行内 import 不再执行所致，脚本问题非产品问题，如实声明） |
+
+---
+
+## 三、本轮新发现（确认 5 项，N22-N23 已修 / N24-N26 未修）
+
+证据口径：**5 项全部经本报告写作者本会话独立验证**（读码 + 运行复现/红守卫实跑；N26 为读码 + 调用环逻辑证明，见该行声明）。
+
+### high（2 项，均已修复，见第四节）
+
+| # | 位置（缺陷时点 → 修复后现行） | 缺陷摘要 | 状态 | 证据（本会话） |
+|---|------|----------|------|------|
+| N22 | swarm/rust_runtime/src/swarm.rs:759-774 → 现行 :765-776（注释）/:813-833（记账） | protocol 拓扑下发给 verifier 的消息被每轮重复『顺延一轮』，实际永久丢失：round r 把 verifier 自身收件箱搬到 inboxes[r+1]，round r+1 又原样搬到 r+2，直至 rounds+1 随蜂群结束消亡——消息从未投递、从未 ACK、verifier 消费水位永不推进；原注释声称「自身收件箱顺延一轮不丢失」与实现矛盾 | **已修复**（F1） | 红守卫实跑（test_swarm_inbox_delivery 场景②）：3 轮 protocol 蜂群，WAL 发往 verifier 路由事件 3 条，修复后 verifier ACK = 2 条（轮 2、3；**旧实现恒 0**）、消费水位 = 2（**旧实现永不推进**）、复算 3 轮全过 mismatches=0（修复不破坏逐位复算） |
+| N23 | swarm/rust_runtime/src/swarm.rs:991-996 → 现行 :172-176（类型）/:801-812（平铺）/:1016-1025（投递）/:520-523（replay） | 同轮同源多条路由在收件箱处互相覆盖：Inboxes 结构为 (round→target→from→(payload,seq))，以 from 为单值 key，同一实例发出的第二条路由 insert 直接覆盖第一条——消息 A 载荷被静默丢弃，但 WAL 中两条事件均已 HMAC 签名落盘为「已投递」，审计留痕与实际投递不符 | **已修复**（F2） | 红守卫实跑（场景①）：实例甲双路由（载荷 11/22）发实例乙，WAL 2 轮 × 2 条 = 4 条留痕（旧代码也过——正是「留痕与投递不符」的留痕侧），修复后乙 `已收消息数` = 2（**旧实现同源覆盖后仅 1**）；WAL 全验签 bad=0 |
+
+### medium（2 项，未修复）
+
+| # | 位置 | 缺陷摘要 | 状态 | 证据（本会话） |
+|---|------|----------|------|------|
+| N24 | swarm/swarm_cli.py:78-81 | cmd_run 调 make_swarm_config 未传 condition_space：用户在 swarm.json 声明的 G-R2 条件空间卡被 CLI 静默丢弃——既不进生成的 swarm.json，也不触发 Rust 侧「四要素缺一不可、缺失即拒绝运行」的负路由校验（main.rs:351 读 cfg['condition_space']，swarm.rs:155 对 None 返回 Ok(None) 直接放行），执行链的 VM 符号注入（swarm.rs:613-623）随之失效 | 未修复（遗留） | 读核：swarm_cli.py 全文 grep `condition_space` **0 命中**（:78-81 实参表无该项）；rust_swarm.py:31/:46-47 形参与写入在位；main.rs:351-357 + swarm.rs:152-170 校验链、swarm.rs:613-623 注入点逐行读核。旁证：现行绿套件 test_swarm_condition_space.py:57 **直连 make_swarm_config** 传卡（绕过 CLI），故套件全绿而 CLI 缺口在位 |
+| N25 | swarm/swarm_cli.py:66-67 | cmd_run 多处异常未捕获，破坏文件头承诺的「stdout 恒为单行 JSON（机器面）」契约：config 不存在（:66 open）、config 非 JSON（:67 json.load）、@file 源缺失（:60 _load_source 的 open）、instances 项缺 id / routes 项缺 from-to（rust_swarm.py:40 `i["id"]`/:43 `r["from"]`/`r["to"]` KeyError）、cargo 失败/超时（rust_codegen.py:61-65 raise RuntimeError、:62 TimeoutExpired，经 rust_swarm.py:71 build_rust_exe 调用——该行在 run_swarm 的 try 块**之外**，v2 F3 的守卫只包 swarm 子进程本身）——harness 收到 Python traceback + 空 stdout 而非结构化错误 | 未修复（遗留） | 实跑复现：`python -m swarm.swarm_cli run --config no_such_config.json` → FileNotFoundError traceback 直出（cmd_run :66），stdout 无单行 JSON；其余四个抛点的代码路径逐行读核（rust_swarm.py:40/:43、rust_codegen.py:61-65、rust_swarm.py:71 与 :78-90 try 块的相对位置） |
+
+### low（1 项，未修复）
+
+| # | 位置 | 缺陷摘要 | 状态 | 证据（本会话） |
+|---|------|----------|------|------|
+| N26 | swarm/rust_runtime/src/main.rs:141-167（parse_json_scalar） | 标量结束定位 `s[start..].find([',','}'])` 不跳过字符串字面量：`--symbols` 的字符串值内含 ',' 或 '}' 时，end 落在字符串内部——值本身经 parse_json_string 解析正确，但返回的续读位置错位，下一轮按「符号表键须为字符串」（main.rs:92）误报，合法 JSON 被拒且报错文案指向错误原因 | 未修复（遗留） | 读码 + 调用环逻辑证明（本会话）：对 `{"甲":"x,y"}`，标量解析返回 (Str("x,y"), end=串内逗号处)；parse_symbols_json 主循环（main.rs:82-110）跳逗号后 pos 落在 `y` 处，:91 `bytes[pos] != b'"'` 成立 → Err("符号表键须为字符串")——机制逐行核对在位。**运行时复现未做**（需构建独立形态 exe 后构造 --symbols 入参，本轮未跑，如实声明） |
+
+---
+
+## 四、新修复清单（2 项，工作树未提交改动）
+
+### F1（对应 N22，high）verifier 自身收件箱到达轮即消费记账
+- swarm.rs:765-776（修复注释）+ :813-833（own_ack_seq_max/has_inbox/max_seq）：删除旧的每轮顺延段；verifier 到达轮的自身收件箱**计入 ACK 与消费水位**（own_ack_seq_max 取该轮自身收件箱各条投递 seq 的最大值），**载荷不进复算执行输入**（verifier 执行输入仍是 primary 输入，混入会破坏逐位复算）——:827 `has_inbox` 与 :828-833 `max_seq` 均并入该记账，ACK/水位如实推进。
+- 配套红守卫：swarm/tests/test_swarm_inbox_delivery.py 场景②（判别器：ACK 计数、水位 >0、复算 mismatches=0），本会话单跑通过。
+
+### F2（对应 N23，high）收件箱来源值改列表——同轮同源逐条保留
+- swarm.rs:172-176：`Inboxes` 的来源值由 `(String, u64)` 改 `Vec<(String, u64)>`；投递点 :1016-1025 由 insert 改 entry 链 push；实例输入构造 :801-812 把收件箱平铺为 (来源,载荷) 序列并按来源稳定排序（同源内保持全局事件序，单路由场景与旧输出逐字节一致）；replay_wal :520-523 断点续跑路径同步 push。run_round 注入面（:600-608）随之按平铺序列逐条生成「收件箱」JSON 与「已收消息数」如实计数。
+- 配套红守卫：同文件场景①（判别器：双路由乙实收 2 条、WAL 4 条留痕、验签 bad=0），本会话单跑通过。
+
+---
+
+## 五、遗留清账（历轮遗留 + 本轮新增）
+
+| 来源 | 修复进展 | 余量（编号沿各轮原口径） |
+|------|----------|--------------------------|
+| v1 遗留 21+1 部分 | 累计修 #10/#11/#12/#13（v2）、#6/#18/#21/#22（v3）、**#3/#4/#23（本轮 L4/L5/L2）** | **11**：#5 同桶计数半边（low，部分）、#8 trust 审计时间戳（medium）、#9 propagate 帽穿透（low）、#14-#17 scripts 四项（medium 1 + low 3）、#24 condition_space CLI 丢弃（medium，即 N24 同一缺陷——v1 已记录、两轮未修）、#25 report_path 指针错位（medium）、#26 build_rust_exe 路径（low）、#27 聚合数值分歧（low） |
+| v2 遗留 14（N5/N11 同路径） | **N4（本轮 L2，与 v1 #23 同一缺陷）** | **13**（去重 12）：N5/N11 verify_runner iter_id 穿越读写（high+medium）、N6 result 非原子写、N7 单发空回包假成功、N8 read_roots 单串切分、N9 suite 空跑放行、N10 wm HEAD 残留（high）、N12 断言面误标、N13 裸 int() 打死编排、N14 敌对字符裸崩、N16 一行 DoS、N17 jobs 池分裂、N18 timeout_s 无校验 |
+| v4 遗留 15 | **N21（本轮 L3）**；N8 部分缓解（codegen 错误路径终裁否决分支实测可达，词法/语法/名实错误的 verdict=None 缺席面仍在） | **14**：N3 毒 token 裸 float()、N4 条件/函数体泄漏顶层、N5 字符串 EOF 零诊断、N6 伴侣上限无空格失效（high）、N7 strict 死配置、N8 终裁橡皮图章（部分）、N9 LLM 建议丢弃、N10 validate_source 全流水线、N14 同名 def 覆盖、N16-N20 测试面五项 |
+| 本轮新增 | N22/N23 已修 | **3**：N24（= v1 #24，双列声明：v1 时点已发现、第 5 轮 swarm 深挖在 CLI 现行代码复核确认仍在位）、N25、N26 |
+
+**优先级建议**：N24（= v1 #24）修复成本极低（cmd_run :78-81 补 `condition_space=cfg_in.get("condition_space")` 一个实参）且负路由校验链/注入链均已就位、只缺 CLI 透传——建议随下批顺手清账；N25 与之同文件同函数（cmd_run 整体包 try/except→_fail），宜与 N24 一并处置；N22/N23 修复后，swarm 消息语义面已闭环，N26 为独立入口健壮性、可缓。
+
+---
+
+## 六、测试验证结果
+
+以下命令均为本会话实际运行（Windows，仓库根目录，`python -X utf8`）：
+
+| 命令 | 结果 | 退出码 |
+|------|------|--------|
+| `python scripts/run_tests.py`（全量入口） | **SUMMARY 164/164 通过，5 跳过**（依赖缺失/平台不符的既定跳过；较 v4 的 163 增 1 = 新套件 test_swarm_inbox_delivery 入列） | **0** |
+| `python swarm/tests/test_swarm_inbox_delivery.py`（本轮新红守卫，单跑） | 12 passed, 0 failed（场景①同源双路由 5 项 + 场景②protocol verifier 5 项 + 项目生成/WAL 验签） | 0 |
+| `python compiler/tests/test_c4_tooling.py` … `test_pbc.py`（8 套逐件单跑） | 8/8 全 PASS（L1/L3 改动的 compiler 面回归） | 0 × 8 |
+| `python _repro_verify_3536.py`（v1 复现脚本，非套件） | S1 propose 成功 / S2 AccessDenied——L5 修复后两象限翻正（S4 段因脚本自身 `_j` 未定义中止，见第二节 L5 行） | —（复现脚本） |
+
+**修复/缺陷探针**（本会话内联命令，关键输出已在第二、三节逐项引用）：L1 非法函数名编译失败 + 终裁否决触发 + 正常函数对照；L2 四行畸形 WAL 计 bad 不崩；L3 函数体内条件空间拦截；L4 投毒索引越界读封死；L5 S3eq accept/S4 层落盘对照；N24 grep 零命中 + 校验链读核；N25 CLI traceback 实跑复现；N26 调用环逻辑证明。
+
+**git 工作树核对**：`git diff`（vs HEAD d3296ec）累积 v1-v5 未提交改动；本轮新增部分 = swarm.rs（修复 #1/#2，均带「2026-09-25 修复 #N」注释）、rust_swarm.py（WAL 容错，缺陷 #2）、name_checker.py（缺陷 #3）、mdcg.py `_read`（缺陷 #4）、mdcos.py propose（缺陷 #5）、api.py gen.errors 回流（无编号注释，归位依据见第二节 L1 行）、test_swarm_inbox_delivery.py（新增未跟踪）、test_rust_swarm.py ⑤（v2 F3 配套，非本轮）。另：md_cg 16 文件的 `os.replace`→`fsutil.publish()`（fsutil.py:44-53，Windows WinError 5 短重试，注释标「2026-09-25 全量回归实测」）与 .gitignore +`.env` 亦在树——属回归稳定性工程/环境项，不计入缺陷修复 5，如实记录；publish 重构是否即 v4 输入「全量有失败」所指的随机 PermissionError 源，无法确证，不展开推断。
+
+---
+
+## 七、跳过项及原因
+
+- **修复跳过：0**——遗留修复 5 项全部落盘验证；新发现 5 项中 2 项（N22/N23，均为 high）本轮修复，N24-N26 三项列入遗留清单（第五节），无「确认后主动跳过」项。
+- **未运行项（如实说明）**：
+  - N26 未做运行时复现（需构建独立形态 exe + 构造 --symbols 入参），以读码 + 调用环逻辑证明在位，见第三节该行声明；
+  - `scripts/verify_linux.sh`（Docker Linux 口径 40 套）本轮未跑——清单为 md_cg/hive/scripts 面，本轮改动中 md_cg 两项（L4/L5）有其覆盖面，如需 Linux 口径确认可后续补跑；
+  - bench_swarm_parallel/bench_swarm_scale 两套为全量入口既定跳过（负载敏感仅串行），非本轮新增；
+  - hive Rust 面 `cargo test` 本轮未单跑——hive 域本轮零改动（工作树 hive diff 均为 v2 轮遗留的未提交修复，v2 已验），全量入口的 hive Python 套件（test_orch/test_serve_entry/test_wm_progress/test_exec_cmd 等）本轮全绿。
+
+---
+
+*报告依据：任务输入的第 5 轮结论（修复遗留 5 / 新发现 5 确认→新修 2 / 回归全绿，及五项缺陷明细与时点行号）；本会话的现行代码逐处读核（swarm.rs/swarm_cli.py/rust_swarm.py/rust_codegen.py/main.rs/name_checker.py/api.py/mdcg.py/mdcos.py）、`git diff` 工作树逐 hunk 核对与 HEAD 对照、五项遗留修复的探针实测（含 v1 复现脚本翻正）、五项新发现的复现/红守卫实跑（N26 为逻辑证明）、新红守卫套件单跑 12/12、compiler 8 套单跑、全量 run_tests.py 164/164 实测。*