一条修对的判据，如何长成 6,491 行的 bash 解释器

00四个问题的答案

01证据基线：本次复核做了什么

下面每个数字都是本次会话现场跑出来的，不是从 PR 自述转抄的。复核只有两条路径：读 PR 分支的代码（本地 worktree），和只读查询 0904 批的真实湖仓（经 121 跳板 ssh -L 15432）。

02方向：判据用 5 个提交修完，剩下 75 个提交在造解释器

为什么说「多出来的 5,395 行对产出零影响」

这不是推论，是同一批数据上跑出来的三个点：

版本 A  a43d9233   provenance.py 1,096 行  →  10,733 行回放：变 1 / 错 0
版本 B  a1f3ab56   provenance.py 1,853 行  →  10,733 行回放：变 1 / 错 0
版本 C  d8b8408b   provenance.py 6,491 行  →  10,733 行回放：变 1 / 错 0

三个版本唯一改变的那条，都是 issue 里那一个 job：
  xagent-openclaw-runtime:publish-image
  openclaw/Dockerfile  →  Dockerfile        （matched_by_tag = true, build_count = 2）

也就是说：从第 5 个提交到第 47 轮，35 轮评审、5,395 行代码、约 7,800 行测试，在一个 3,260 条脚本的真实批上，改变了 1 条产出——而那条产出在第 5 个提交就已经改对了。

这不是「历史数据太干净」的偶然

形态普查跨了三周、四个批，分布是稳定的：

这个仓的 CI 是模板化的：约 3,240 条脚本收敛到 330 余种文本，绝大多数是 helm_package 包装的约定调用。docker build 全批只出现 1–2 次，正是本票要修的那类「一个 job 两次 build」的稀有形态。真实风险不是「脚本会写 case」，而是归属判据挑错 Dockerfile——那一点在第 5 个提交已经修好了。

03架构：接口是对的，接缝后面不是

对的部分

runner.py 从 provenance 只导入 9 个名字，没有反向依赖，也没有把内部状态漏出去：

from ontoos_extract.code_extract.provenance import (
    AmbiguousShaError, GitlabClient, Job, Pipeline, ParsedJob,
    find_pipeline_for_commit, list_jobs, parse_job_script,
    pick_dockerfile_for_image, pick_job_for_image, resolve_full_sha,
)

模块划分也基本正确：Dockerfile 的解析在 dockerfile_parser.py（+714 行），runner 的接线在 runner.py（+387 行），审计跟随者契约在 archive_health.py/status_audit.py。范围 2/3/4/5 落在该落的地方。另外 PR 有两条真的工程优点：守卫 + 变异两步验（450 条变异逐条转红）、以及与真 bash 逐条对照（PATH 里放假 docker 打印 -f 值）——后者不依赖作者自己对 bash 的判断，是本 PR 最强的收口手法。

不对的部分

作者自己在第 31 轮把这件事说得很准，措辞比本报告更直接：

「方向已经偏移。 issue #439 的五条范围在第 ~10 轮就交付完毕，AC 守卫至今全绿；第 22 轮之后每一轮都在把 provenance.py 变成一个更完整的 bash 解释器。本轮 codex 的 13 条无一例外是更深的 shell 语义……新机制自己长出下一轮。」 PR #443 第 31 轮评论，2026-09-09 18:21

04评审意见：多数为真，但多数不是本票的

先说结论：这些意见在技术层面大多是站得住的 bash 语义。我抽查了最近 18 条线程，每一条都能在 bash 里复现问题场景（shopt -q 只查不改、子壳里的 set -o pipefail 在 ) 处还原、exec 之后父 shell 不再继续扫、管道末段是函数调用时 pipefail 的状态归属……）。codex 与 ysatnaf 都没有在编造问题。

问题不在真假，在相关性和代价。按主题分类这 369 条线程：

也就是说：约三分之一的评审工作量，花在一个真实批里出现 0 次的输入面。这不是评审者的错——评审者只能按代码里写了什么来审；是代码先长出了这个面，评审随后被迫在里面自转。用 PR 正文自己的数字：45 轮里约 101 条意见是上一轮修复引入的回归，即约 28% 的评审产出是在给上一轮的修复擦屁股。这是「评审判据没有代价轴」的典型信号：如果每条意见都只问「这样会不会产出归属错」，反例是无穷的。

唯一一条性质不同的意见

第 41 轮 ysatnaf 报的那条值得单独拎出来：「解不开的派发释放全部寄存体」是阶乘级的，一条 job script 就能把整批抽取挂死。这一条与前 123 条有本质区别——

• 它讨论的不是「解释器的某个答案对不对」，而是解释器会不会把整批跑挂；
• 这个故障模式由本 PR 引入，不是从 main 继承的；
• 它的代价是整批，不是一条归属。

作者在第 41 轮加了界（fan_out_seen 去重 + fan_out_depth 作用域），第 42 轮又按「上限按名字不按深度」收了一版。这条修复应当保留——但它的存在本身就是对第 2 节结论的最好佐证：一个手写执行器需要的不是更多语义，而是它自己的复杂度预算。

05下一步建议

A 片：归属判据（≤400 行）——唯一必须交付的部分

只做 issue 的范围 1，即让 docker build 的目标镜像能挑对 Dockerfile：

• 文本级高召回登记：无 -f 的 docker build 按 build context 登记隐式 Dockerfile（相对 context，默认 .）；每次 build 记 (dockerfile, tags)；referenced_dockerfiles 列语义不变、只追加隐式项。
• tag 三趟精确选择：精确 bare name → ${CI_PROJECT_NAME} 模板 → 完整 tag；无匹配才退回首个引用，并 WARNING。
• 不模拟 shell 执行：命令切分走到「工具 → 全局选项 → 管理对象 → 子命令」为止；解不出的形态登记为「不确定」并落显式降级留痕，不猜。

判据已在 a43d9233 里存在且经过回放验证（1 变 / 0 错），可以直接摘取。

B 片：Dockerfile 侧与 runner 侧（约 1,300 行）——直接修复现场损坏

这四条才有可被下批验证的产出面——它们直接对应上面复核到的 10 条 NULL 根组件与一个错误的 archive_kind。

丢弃：解释器（约 5,000 行 + 约 7,800 行测试）

不留分支、不做兼容、不逐条评估。它是为一个出现率 0 的输入面写的执行语义层，替换路径是降级留痕：解不出的形态在 health 诊断与 capability 的 reason 里响亮失败，让下一批的验收看得见。若将来真实批里真的出现 case 或 heredoc，那时手里会有真实的失败样本——按样本修，比按想象修便宜两个数量级。

三条闸：不立起来，下一个 PR 会重演

1. 真实命中闸。任何新增判据，动代码之前先用一条 SQL 量它在真实批里的出现率。命中 0 的意见记入遗留清单，不修——这条比继续修任何一条都便宜。
2. 轮次闸。评审超过 10 轮，或未解决数连续 3 轮不降，即停并 @ 人。一旦「要不要继续这条轴」被交给人类，作者不得自行撤回；撤回需要交出去的那一方或更上游的人点头。
3. 代价闸。每轮先算「上一轮引入的回归 / 本轮新增意见」。超过 30% 则下一轮只允许删，不允许加。

顺带值得记的两条

• 第 31 轮的自我诊断是本 PR 质量最高的一份产物，建议把它从 PR 评论里提出来，作为该仓「评审何时该停」的样例保留。
• codex 与 ysatnaf 在这 47 轮里的产出（约 101 条回归之外的部分）不应被整体否定——它们暴露的「同一条判据只应用一半」「新判据没有消费点」「判据的值域少一格」等模式，在本仓其它 lane 上已经反复出现。缺的是把它们放在**有真实产出面的代码**上做。

06复现方式

# 1) 形态普查（只读湖仓，经 121 跳板）
ssh -L 15432:<PG_HOST>:5432 -J root@121.41.239.88 xf@172.25.17.43 -N
#    然后对 dev_ods.code_pipeline_jobs 按 batch_id LIKE '20260904%' 取 script 做正则统计

# 2) 三版本回放对比
git worktree add --detach /tmp/ir439-a43d9233 a43d9233
git worktree add --detach /tmp/ir439-a1f3ab56 a1f3ab56
git worktree add --detach /tmp/ir439-pr       origin/worktree-ir439
PYTHONPATH=<版本目录> python <回放脚本>   # 对 code_archives ⋈ code_pipeline_jobs 跑新旧归属

# 3) 现场损坏核对
SELECT component_path, framework_kind, source_root_path, detection_method
  FROM dev_ods.code_archive_components
 WHERE archive_id = 'e789b0c0da15ee534a18cb28';   -- 10 行，source_root_path 全 NULL

注：批 id 按源分片（0904 批族共 1,559 片），按前缀 LIKE 聚合才是完整的 3,260 条；用 ods_current 查历史批次会得到 0 行而不是报错。