issue #439 / PR #443：评审为什么不收敛，接下来怎么办

一眼看懂

事实底座

下面每个数字都是本次从 GitHub、PR 分支与湖仓（dev_ods，0904 批）现场取得的，取法见附录。先看体量与曲线，再看真实数据。

真实批次说了什么

把 PR 最终代码（3abf8d05）与 main 的 provenance.py 同时装载，对 0904 批 code_pipeline_jobs 全部 3,260 条 job 脚本做三件事：数形态、比 job 选择、比 Dockerfile 归属。

1 · 实现方向是否有偏差

结论：有偏差，从「归属判据」滑向了「bash 执行语义的完备性」，这是不收敛的唯一根因。

issue #439 的问题是一句话：一个 CI job 跑了两次 docker build，旧代码取 referenced_dockerfiles[0]，把中间基础镜像的 Dockerfile 套给了发布镜像。答案也是一句话：逐条 build 登记 (dockerfile, tags)，用目标镜像的 tag 挑；挑不中就取最后一条并告警。这在第 1 个提交 88bf2cdb（+220 行）里已经写对了，openclaw 那条脚本用它就能归对。

偏差是怎么发生的？看提交标题就能读出三段轨迹：

1. 第 1–10 轮（09-08 白天，1,096 → 1,853 行）：评审意见落在五条范围上——完整 tag 先于 bare name、最后 stage 继承的 COPY、制品镜像不产 source-dir、--target 传递、跟随者状态一致性。这些是真问题，修得也对。
2. 第 11–20 轮（09-08 夜里，→ 2,833 行）：为了回答「这条 docker build 的 build context 是哪个目录」，开始跟踪 cd、子壳、AND-list 后台化、包装器（sudo / timeout / flock / bash -c）、kaniko / buildah / podman 车道。每一条在逻辑上都成立，但已经离开了 issue：本仓 3,260 条脚本里 cd 只有 17 条、包装器 0 条。
3. 第 21–45 轮（09-09 至 09-10，→ 6,389 行）：为了回答「这条命令在 bash 里会不会真的执行」，引入函数体寄存与重放、列表状态与 ! 取反、heredoc 引号感知扫描、case 模式匹配（含 ;;&、POSIX 字符类、nocasematch）、trap 信号谱、exit/exec/return 三层终止、pipefail 三值、协程隔离、派发扇出上限。这是在写一个 bash 解释器。作者第 31 轮的原话：「第 22 轮之后每一轮都在把 provenance.py 变成一个更完整的 bash 解释器……这条清单没有可见的尽头。」

三个佐证说明这不是「多做了一点」而是方向性错误：

• 与 #440 的裁定相悖。两天前在兄弟票 #440（同一根因链的 F2）里，用户拍板不做「从 scripts 解析 shell 命令行」的第四条声明源，理由写得很清楚：那是一个全新的易错面，新语义面必须逐格实测。#443 在同一周把这个面做成了 5,500 行，且没有任何一格用真实脚本实测过。
• 解释器对真实批次的产出影响为零。job 选择 1,582/1,582 相同，归属只变 1 条，而这 1 条用第 1 个提交就能变。也就是说第 11–45 轮的 +4,500 行在生产数据上没有产生一个字节的差异。
• 它永远收敛不到零。bash 静态语义不可判定（变量、eval、外部命令退出码、运行时环境）。作者自己的差分自查在第 45 轮仍报告：1,200 条随机形态里 52 条丢 build、128 条假阳；第 44 轮刚把丢 build 从 90 降到 52，第 45 轮又新增 3 条 P1。这不是「再两轮就收口」的形态，是一个开放集合。

2 · 代码实现的架构是否合理

结论：范围 2–5 的实现合理、贴近既有结构，可以整块保留；范围 1（provenance）的架构不合理，应重写而不是继续修。

可保留的部分（约 1,300 行，来自 dockerfile_parser / runner / archive_health / status_audit / schema）

• 同 dst 合并（map_copy_to_components 的 _add 折叠 + merged_copies / merged_source_roots 信号）：落实了 docstring 早已写明的契约，落盘信号可查，判据清楚。
• bare COPY 源目录组件（kind='source-dir'，只认最后 stage 及其 FROM 链，ships_build_artifact 豁免制品镜像）：把影响面收在「本来就没有组件」的镜像上，两道闸各有守卫。
• 同根去重与跟随者契约（runner 以 comp_abs 为键只跑一次 FE；shared-source-root:<leader> 在写时门与湖仓审计两侧同口径校验领跑者存在、同 lane、同状态、双方 requested）：这是本 PR 里最像「架构」的一段，两侧共用 archive_health 的常量与判据函数，符合仓里「写库收口」的传统。
• backend-node 值域与浏览器侧信号三源（框架词表 / browserslist / web 根 COPY），通用打包器单独出现不算前端：判据方向正确，COLUMN_COMMENTS 同步。
• 解析失败的降级留痕（_safe_parse_job_script / _safe_pick_job_for_image 写 job-script-parse-failed / job-selection-failed 诊断，archive_status='partial'）：符合「已知为空 ≠ 不知道」的仓内铁律。

需要注意的膨胀点：Dockerfile 解析器里加入了 ENV / ARG / WORKDIR 展开与「ARG 默认值决定 FROM 祖先」的推断。Dockerfile 语义同样是开放的（--build-arg 覆盖、多阶段变量作用域），这一段应写进 ADR 并明确「只做字面量可解的那一格，其余保守」，否则会成为下一个 provenance。

不合理的部分（provenance.py，+5,513 行）

1. 用模拟执行回答证据选择。目标是「给这个镜像找到它的 Dockerfile」。正确的架构是：文本级高召回登记所有 build 候选 → 用镜像 tag 做精确选择 → 用镜像侧证据对账 → 不确定时显式降级并留痕。PR 把第一步做成了「先判定哪些命令在 bash 里真的会跑」，于是每一种 shell 控制流都成了归属判据的一部分。
2. 不可判定的问题放进了热路径。parse_job_script 对每个 archive 的每个 job 都跑。第 41 轮发现过派发扇出是阶乘级（8 个 helper 各以 $RUN_HOOK 收尾 = 13,700 条 build，15 个永不返回），靠加深度上限止血；60,000 条形态 fuzz 才把「不抛异常」钉住。一个 6,000 行的解释器本身就是新的稳定性面，而它保护的是本批 0 次出现的形态。
3. 两条车道共用一台解释器却各自消费。精确车道（builds）与粗车道（_script_invokes_build 的 own-script 闸、_executed_script_text）共用 _ListState / _Nesting，但消费点分散——作者的第 4 条、第 25 条教训（「同一条口径要一次找齐它的全部消费者 / 出口」）在本 PR 里复发了至少七次（跳过保留字三轮各补一处、target_known 有产出无消费、pipe_failed 三个出口只改一个、adopt_options 缺 ( 帧那一半…）。这不是纪律问题，是结构问题：状态被拆在参数列表与闭包里跨行携带（_parse_docker_builds 有 8 个可变参数），没有一个执行上下文对象。
4. 测试钉形态不钉性质。316 个 provenance 用例绝大多数是「某种 shell 写法 → 期望 builds」，随实现精确化而失效（作者第 21 条教训：「按字面量写的守卫会随着建模变精确而失效」，三次）；「变异不转红先怀疑守卫」踩了十次。真正有判别力的两条等价关系守卫（直写 vs 函数体一致、( ) vs { } 一致）是第 43 轮才立的。
5. 现成的确定性证据一次没用。runner 早已通过 crane blob 取镜像层文件清单（_layer_file_listing），并按候选 Dockerfile 的 COPY dst 挑层（pick_layers_for_copy_targets）。这意味着「候选 Dockerfile 最后 stage 的 COPY dst 是否真的出现在镜像层里」是一个已经付过成本的、与 shell 无关的对账信号：openclaw 那台镜像，openclaw/Dockerfile 的 dst 命中 app/node_modules，根 Dockerfile 的 dst 命中 opt/xagent，真相在层清单里一目了然。PR 全程没有触碰这条证据。
6. 模块边界。GitLab HTTP client、SHA 磁盘缓存、脚本解析、归属判据、job 选择同居一个 6,389 行文件；文件头 docstring 仍写着「provenance for one (project, commit) pair」。如果 shell 证据层非做不可，也应是独立模块（shell_evidence.py）加独立 ADR。

3 · 评审提出的是实质性问题吗

结论：分层看。第 1–10 轮多数实质；第 11–20 轮逻辑成立、实质稀薄；第 21–45 轮形式成立、实质为零，并且相当比例是评审在给自己制造工作。

几个结构性的观察，比逐条评价更重要：

• 采纳率 95% 是失控信号。Codex 233 条里 222 条被接受并修复，明确拒绝的只有 5 条。一个健康的评审循环里应当有一批「成立但范围外，记遗留」的意见；这里没有过滤器，于是评审者的产能直接决定了 PR 的体量。
• 评审在消费自己的产出。作者自报 359 条意见里约 101 条是「上一轮修复引入的回归」；本次按线程标题保守统计，明确写着「本轮引入」的就有 17 条，第 11–20 轮最密（9 条）。第 24 轮自查 6 条修复里 4 条被下一轮证明是回归，作者自己写下了「边际收益已转负」，然后继续。
• 循环里没有人，也没有真实数据。Copilot 42 次全部报「unexpected error」从未评审；CI 三个 job 因组织计费在 2–3 秒内失败，整个 PR 生命周期没跑过一次；ysatnaf 既是作者又是行内评审者（135 条）；Codex 每轮约 12 分钟出 5–13 条。所有判据都来自构造脚本，没有一条来自 code_pipeline_jobs。第 31 轮的选项 B 正是要一份「真实脚本样本」当边界判据——那份样本在湖仓里，五分钟可得。
• 仍 open 的 5 条（set -o pipefail 逃出 ( ) / 子壳内被整条丢弃 / ! 被 finish 二次折叠冲掉 / deferred 未进快照 / ! { … } 落进内层列表）全部是第四层意见，本批 0 次出现，不应阻塞任何决策。它们的存在本身说明这条轴不会自己停下来。

4 · 下一步的行动建议

推荐路线：停止在 #443 上继续轮次；把它转为 draft 保留作素材；在已建的 worktree-ir439-rework（目前停在 main 0404d477）上按三个小 PR 重做。这对应作者第 31 轮的选项 C，但拆分口径比他估的简单：#443 里 dockerfile_parser / runner / archive_health / status_audit / schema 的改动彼此独立、与 provenance 只通过 DockerfileAttribution 一个数据类接口耦合，可以整块摘取；只有 provenance.py 需要重写。

给评审循环装闸（写进 PR 正文的「评审约定」段，agent 与人都遵守）

1. 真实命中闸。每条 P1/P2 意见必须附「0904 批 3,260 条脚本中的命中数」或一份真实 .gitlab-ci.yml 片段；命中为 0 的意见记入「发现与遗留」，不修、不 resolve、不阻塞。这就是作者第 31 轮要的边界判据，本报告附录给出了一条 SQL 就能算的方法。
2. 轮次与趋势闸。超过 10 轮，或未解决数连续 3 轮不降，自动停轮并 @ 人拍板；作者不得自行「撤回需要决策」。
3. 回归率闸。一轮意见中「上一轮引入」占比超过 30%，下一轮只许删代码、不许加形态。
4. 作者与评审分离。ysatnaf 不再对自己的 PR 出行内评审；改用只读评审子 agent（仓内已有「评审子 agent 必须只读」铁律），且评审结论须自建探针复现。
5. Copilot / CI 状态显性化。Copilot 连续报错与 CI 计费拦截都要在每轮总结里写明「本轮没有第三方评审、没有 CI」，避免 42 条错误评论被当作评审记录。

票务与文档

• #439 保持 open，改挂 PR-A / B / C 三个 sub-issue；AC6「归属变化清单」以本报告附录的回放结果先行勾掉，下批复核。
• #443：转 draft，正文顶部加一段「本 PR 作为素材库保留，不再接受评审；后续见 #439 三个子票」，5 条 open 线程不再处理。不删分支——第 1–10 轮的评审记录与 26 条教训有保存价值。
• 新立 backlog 票「CI 脚本 shell 语义建模」：不设优先级，附本批 0 命中的证据，等真实形态出现再评估；把 #443 的差分自查方法（假 docker + 真 bash 逐条对照）记进票里作为将来的验收手段。
• ADR：「Dockerfile 归属采用文本级高召回登记 + tag 精确选择 + 镜像层对账，不模拟 shell 执行」。同时把 #440 的裁定（不解析 scripts 里的 shell 命令行）引用进来，两票同一原则。

附录 · 方法、数据来源与局限

数据来源

• GitHub：gh issue view 439；gh pr view 443（正文 46 KB、77 提交、501 条 review 事件、105 条顶层评论）；GraphQL reviewThreads 分页 4 次取全 368 条线程。
• 代码：git fetch origin refs/pull/443/head 后与 origin/main 逐提交比对行数；在独立 worktree 上用仓内 venv 跑 test_code_extract_provenance.py 等五套：450 passed / 45 s。
• 湖仓：经 121 跳板 ssh -L 15432 连 dev_ods，batch_id LIKE '20260904_112726_%'（batch_id 按 archive 带后缀，须用前缀）；code_pipeline_jobs 3,260 行、code_archives 1,716 行。

三条可复现的检查

# 1) 真实脚本形态分布（任何一条意见都先跑这个）
SELECT count(*) FILTER (WHERE script ~* 'pipefail')      AS pipefail,
       count(*) FILTER (WHERE script ~* '(^|\n)\s*case\b') AS case_stmt,
       count(*) FILTER (WHERE script ~ '(?<!<)<<(?!<)')    AS heredoc,
       count(*) FILTER (WHERE script ~* '\bdocker\s+(buildx\s+)?build\b') AS docker_build
FROM dev_ods.code_pipeline_jobs WHERE batch_id LIKE '20260904_112726_%';

# 2) PR 自带回放（AC6），本次实测 1 变 / 1,052 不变 / 0 错
python scripts/replay_dockerfile_attribution.py --config <pg-config.yaml> --batch 20260904_112726_%   # 注意：脚本按 = 过滤，需改 LIKE 或逐 archive 传

# 3) main 与 PR 的 job 选择对拍：两份 provenance.py 同时装载，对 1,582 条流水线跑 pick_job_for_image
#    结果：1,582 相同 / 0 不同 / 两侧 0 异常（脚本见本次会话 scratchpad/lake_analysis2.py）

局限

• 只扫了 0904 一批（当前最新全量）。历史批次的脚本文本高度模板化（去重后 339 种），结论大概率成立，但没有逐批验证。
• 「解释器对产出影响为零」是对本仓当前 CI 写法的结论，不是对解释器正确性的结论；未来若有仓库改用裸 docker build + 复杂 shell，需要重新评估——这正是建议用真实命中数当闸的原因。
• PR 的 316 个 provenance 用例本次全绿，本报告没有复核它们各自的变异是否仍转红（作者自报 436 条变异逐条转红）。
• 评审线程的分层按创建时间切成四段，与作者的轮次编号有 ±1 轮的偏差。