数据生产卡点与提效进展

累计已入库：83条来源 · 1044行训练样本

有效监督token合计429,190。仅计独立官方通过、自动硬门准入并独立重建通过的发布。

b19：6个固定来源，2个环境准备阻断，4个正式求解且全部完成，3个官方通过并自动准入；1个官方拒绝。本批待处理、抽样、已抽检、待抽检、撤销均为0。b17的1条基础设施待处理仍留旧账，不计入库存；未抽中不表示做过语义审查。

P1当前320,330有效token，距规划4,960,000尚差4,639,670。b19完整选题至独立收尾1464.802秒，新增12,323，约30,286token/小时；完整墙钟包含镜像、环境、探针与父级等待，不以548.812秒正式窗口代替。

低产原因与当前动作：先完成 P1

此前把补充学生类20%供给当成了P1继续生产的前置条件，与既有配方“学生供给不足不阻塞教师采集”冲突。工程修复有必要，但连续串行修复、探针返工和主调度接线错误压低了真实产出。此处明确纠正执行顺序，训练混合目标仍保留80/20，不能提前把P1收集完成当作E2全部完成。

P1现有320,330有效token，规划约4,960,000，剩余约4,639,670。这是有效监督token目标，不能用1,600条或请求数替代。b15已封存：4个公开资格通过并正式求解，2个准备阻断。官方通过与自动准入数量按下表实录。

新campaign：e2-p1-b15-20261103。六来源从选题起合计最多4小时，每来源一次正常求解；每题60请求 / 65,536输出token / 1,800秒，独立官方判分、token对齐、loss mask与自动硬门不变，10%异步抽检继续保留。Mac审查不阻塞本批。准备失败不补题、不重采旧失败。当前结论不宣称提速倍数。

b16：公开局部API回归优先

6个环境和公开资格全部通过，沿用相同模型、profile、预算、独立判分和loss边界。本批不重采已失败来源；正常失败仍计入分母。

正式74请求、28,230输出token；工程P0调用0。工程探针Agent另计，不计入正式监督产出。

已核实并发缺口：controller原_solver_available按lane要求busy=0/reserved=0，全部A路时只允许一个求解；全局预算写2不代表两路已经生效。独立修复增加显式A路额度，保留总数2和B路单学生槽；当前冻结批次不热改，后续新批次验证。镜像页缓存曾使宿主可用内存降至444MiB，暂时阻塞准入；已保留缓存回收与资源收据，未删镜像或改WSL配置。

b17：公开局部API回归优先

6个环境和公开资格全部通过，沿用相同模型、profile、预算、独立判分和loss边界。本批5题实际求解、1题尚未求解时因基础设施故障终止。原窗口postprocess:failed和原始收据不变；仅为已发出的Elementpath/CORS续接尚未执行的独立判分与准入，没有新solve。Scikit判分前setup改变源码树，fresh_before=false，保留needs_infra_review且不可训练；HTTPX零调用封存不补题。

正式102请求、65,541输出token；工程P0调用0。工程探针Agent另计，不计入正式监督产出。

已核实并发缺口：controller原_solver_available按lane要求busy=0/reserved=0，全部A路时只允许一个求解；全局预算写2不代表两路已经生效。修复6e237c0已通过45项父级测试并用于新b17；A路额度2、全局2、B路1。实际求解命令最大同时运行2个，双求解重叠312.245秒。阶段汇总仅含coordinator作业，窗口后两来源收尾另有独立收据，完整墙钟包含这些耗时。第三执行槽供准备、后处理及准入使用，不额外增加求解数。前批镜像页缓存曾使宿主可用内存降至444MiB，暂时阻塞准入；已保留缓存回收与资源收据，未删镜像或改WSL配置。

b18：两份P1发布，新增7,343有效token

固定六来源：五个环境准备通过，四题正式资格通过并求解。TinyTag与Dyntastic官方通过、自动准入及独立重建通过，新增22行；Dask与Premailer官方拒绝并隔离。Iden镜像拉取失败；PyRLP父级改写探针时将正则边界转为退格字符，导致正确控制被误拒，两题均零模型调用阻断、不补题。PyRLP错误归因主调度，不计为模型能力失败，原草稿、失败与清理收据完整保留。

正式61请求、34,425输出token；新增P0调用0。两个探针执行会话单列246,334报告token、174工具调用；逐轮模型路由均antigravity/gemini-3.8-flash/max。这些工程调用不计入有效监督产出。

实际求解命令最大同时运行2个，双求解重叠179.450秒；四份求解累计执行496.578秒，作业耗时可重叠。完整2157.867秒、约12,250有效token/小时，低于前批，不能把并发生效表述为产能提升。生产已暂停且无在途作业，下一批需新来源、新窗口与新收据。

b19：三份P1发布，新增12,323有效token

六个镜像均可用；s3path与freezegun存在工作区外源码副本，环境门拒绝并零调用清理，未放宽隔离或补题。其余四题资格通过并完成求解：pyprof2calltree 8,034、bibtexparser 1,977、comm 2,312有效token，新增45行；邮件解析题官方拒绝。所有正式发布均完成mask/phase/token与来源的独立重建。

正式57请求、18,326输出token；新增P0调用0。两名探针执行者报告228,271token、162工具调用，逐轮模型路由均antigravity/gemini-3.8-flash/max；工程调用单列，不计有效监督产出。父级移除了comm探针对私有_closed字段的额外要求，正式冻结验证实际close行为。

实际求解最大同时运行2个，双求解重叠51.999秒。完整产率约30,286token/小时，不能根据不同来源的小批结果宣称稳定提速倍数。结算执行前检查发现复制脚本仍引用b17库存，已更正为b18并保留原脚本和更正收据，未写出错误库存。b20继承三份真实发布与全部已尝试来源，另开有界窗口。

就绪优先验收：24来源已收尾

核心实现e9b4e7e，99项针对性测试通过。新窗口e2-ready-b21-20261103冻结24个未使用A路来源，从选题起最多90分钟；b20封存六ID继续排除，不恢复旧窗口、不补失败题。最终准备阻断15题，启动求解9题，正常完成8题，官方通过5题，自动准入5题。

本批新增57,062有效监督token，完整选题至独立收尾3167.482秒，约64,854token/小时。包含镜像、环境、探针制作、主调度返工与收尾；工程模型调用和正式生产分列。不同来源与镜像缓存条件不能据此证明稳定提速倍数。

机制验证：Coordinator等待型prepare作业0个，求解实际最大并发2，公开资格通过9/24。外部准备采用逐题独立子进程，UTF-8探针原样交付；精确原子claim、完整资格、源码哈希、一次正常尝试、独立判分、角色/loss mask及自动硬门保持。

目标就绪缓冲4题，观测峰值2题；缺题空闲观测为772.2槽秒，仅覆盖5秒采样区间，不外推未采样阶段，也不能排除内存门影响。镜像结果{'pulled': 15, 'pull_failed': 1, 'blocked_deadline': 8}，供给和探针制作仍需继续改进。准备通过率与判分通过率分别按原分母报告。

完整证据：storage/audits/e2-ready-speedup-20261103/acceptance-corrected.json、throughput-corrected.json、real-release-verification.json。核心就绪派发机制已验证。本批单次完整墙钟产率超过60k/h，但未先做6来源阶段A，外部Docker操作也未统一纳入3执行槽，不能作为新两阶段协议的阶段B通过；稳定产能收益尚未证明。未训练、未push或合入main。

历史b20收尾：停止派发，保留78条真实来源

用户要求先收尾进度并合并推送main，原生产截止和两小时循环已取消。b20六个镜像均可用，五题环境检查通过，一题因Django settings未初始化而导入失败；两个探针执行者停止，未形成完整正式资格。run-bounded从未启动，正式模型、独立判官、自动准入和有效监督token新增均为0。

六个准备容器与临时工作区均确认清理，镜像与原始收据保留。账本保持halted，六个未派发来源保持pending原状态并由独立停止收据封存，不伪造生产结束记录、不自动重选。停止终端包装任务后仍发现原生Python启动子进程，已按完整命令身份定点终止并核验无残留。

最终库存78来源/923行/372,128有效token，P1 320,330，距规划4,960,000尚差4,639,670；本次为进度收尾，未完成原数据量目标。b17的Scikit基础设施待处理留在旧账、不可训练。主检出有他人未提交改动，合并验证使用独立integration工作区；不覆盖主检出AGENTS/HANDOFF，也不夹带任务目录的未提交profile和临时日志。

生成瓶颈：已挽回成果，仍需提高实际转化率

b10正式生成59请求、33,779输出token，新增27,274有效token。正式失败窗口286.875秒，完整选题至恢复收尾6,548.628秒（含实现、探针返工、P0和对齐修复），完整墙钟产率约14,993有效token/小时。恢复发生在窗口结束后，不将全部产出除以286秒来夸大速度。

工程调用单列：可见合同P0为24请求/8,138输出token；紧凑预算与修正学生后端P0为29请求/12,487输出token，均不可训练。没有同口径前后对照，不宣称提速倍数。b12固定4来源默认环境及公开资格全部通过，107次请求/56,616输出token只产出2,030有效token；正式窗口494.703秒，完整墙钟1,970.021秒，约3,710有效token/小时，不扩量。

前八批7条P1均准入，145请求得到74,102有效token；13条学生相关尝试仅2准入，329请求得到11,335有效token。这是小样本描述，不能归因于单一模型能力；真实损耗同时来自准备、上下文开销、收敛与后处理。

b14：最后一次bash读取越过学生前缀上限

新producer 23f4dbf只扩展真实行内assert验证失败识别。Atlan第1–14请求均为read、grep、find或cat，工作区无改动；第14请求执行cat tests/unit/test_search_model.py，下一次测量从11,179增至19,240，15K门正常截停。没有修改后的失败验证，也未达到20步无修改的S条件，因此本次没有走到新W路径，不能宣称修复改善了产率。

两个固定来源耗尽：dparse存在pipenv/vendor/dparse外部副本，0调用准备阻断；Atlan14学生请求、0教师、0完成、0judge、0准入。完整选题至封存2,023.098秒，正式窗口127.406秒，有效产率0。工程P0另计20请求、196,735输入、13,847输出，全部loss=0。

准备至启动1,850.604秒：镜像拉取117.734秒，实际环境准备83.969秒；一名公开探针Worker151个assistant事件、107次工具调用、962.146秒、122,291报告token；父级去掉超范围别名/空列表要求并完成正式冻结7.156秒。主调度误复用准备入口、旧预检漏传教师策略的零调用失败与等待也计入完整墙钟。准备成本仍过高，不能把Worker产物当作零成本。

现有read限制100行/4096字节；bash完整文件输出仍导致实际前缀跳增8,061 token。已派只读诊断检查现有输出上限和pruner时序，结果尚未完成。停止扩批、不修改旧轨迹、不提高预算。证据：b14/production-command-observation.json、b14/preparation-cost.json、b14/final.json。

b13：提示已送达，验证漏判仍造成零产出

bbde69a把真实最近一次学生前缀用量及“上次已判定阶段”写入单个动态system提示，避免声称尚未决定的路由。19项Python测试、65插件检查、6请求真实DSH自然接管与25请求新P0通过；工程输出8,200 token全部loss=0。新提示每请求增加约55–78个学生token，接管后约35个，不重新计算或丢弃历史。

Snowflake首次编辑发生在第9请求，比上一条失败来源更早，但两题不同，不能据此宣称修复提升。第18和20请求源码修改后运行含assert的python -c验证，均有真实traceback和非零退出；原固定测试runner正则未识别，下一请求前缀分别12,714和14,374，仍低于15K却没有W接管。第22请求前缀15,566最终截停。这是可复现的检测缺口，不能证明接管后必然成功。

完整选题至收尾992.804秒，正式窗口101.843秒。环境含镜像等待102.109秒，探针Agent约581秒，正式探针冻结2.625秒；实际求解69.172秒，自动准入排队1.477秒、执行0.234秒。本批0入库的直接原因不是Mac Review或准入等待。

23f4dbf已修正单条python -c断言验证识别：使用AST确认真实assert、完整Python traceback头和非零退出；保留原修改条件与15K上限，拒绝普通脚本、外部换行命令、管道与成功退出。16项测试、原历史两个边界只读对照和6请求真实DSH自然W均通过；20请求双臂P0的官方判分、token对齐及38项源码绑定通过，13,847输出token全部loss=0。修复已集成2204ff6，原b13失败结果不重采；实际生产收益另看b14终态。

b12留下的三个主要损耗

nox-uv的公开探针通过，但生成器实际尝试的仓库集成测试因离线依赖未完成，随后官方判分拒绝。这里只证明公开验证覆盖不足，未读取私有判分材料，不断言它就是官方拒绝的唯一原因。

合并审查与代码清理 · 首轮

未采纳两类过度结论：通用发布格式支持P1/P2配对，不代表E2活动种子允许同Issue多版本；两条预算耗尽轨迹，也不能证明纯模型能力是唯一根因或断言合同修复不会改变结果。审查必须核对本层合同与具体反例，不为修复误报而放宽去重。

证据：pipeline-repair/pr-hygiene-first-pass.json、tool-contract-parent-verification.json。首轮扫描仅有一个开放PR；后续按新提交与验收结果增量检查，不重复全量审查，也不自动执行远程关闭、push或main合并。

先补齐有效产出链路，再判断扩批

历史b08结论：完整墙钟产率约2,603有效token/小时，尚不接受直接大规模扩量；先改善准备通过率与预算内完成率。历史 16.8249 小时新增 36 条准入、109,340 个有效监督 token，即 2.14 条 / 小时、6,499 token / 小时。按旧速率补足本次试产前剩余 token 的算术时长为 38.6 天；这不是预测，未计当前停机、来源变化和学生配额约束。历史两槽同时空闲 8.384 小时，账本槽占用率 26.98%，不能归因 GPU 算力不足。

用户已明确允许拉镜像并按空间维护。Docker 的 docker_data.vhdx 已在 E:/Deeplearning/DockerDesktop/Docker/wsl/disk/，无需迁移；拉取前三份时 E 盘余量约 311 GiB。固定选择原 ordinal 211、213、215 的三个新来源，排除旧 20 条，镜像合计压缩体积 1.68 GiB；串行拉取实测 43.70、82.22、43.28 秒，总墙钟 169.203 秒，未重试。

镜像预取器已加入只读可用性检查、总截止时间、80 GiB 宿主盘余量门和绑定 manifest 的独立收据。不会将 Docker 错误或不可解析的身份当成成功；日志不覆盖，超时后不再启动新拉取。真实三镜像复用检查通过，10 项定向测试通过。

新 producer 已独立冻结，新 P0 两臂均 completed、官方 judge 通过、fresh_before / cleanup / token 对齐通过，38 个源码绑定验证一致。共 25 请求、26,612 输出 token，全部决策零监督、不可训练，不计生产产出。已有工程控制合同按原证据复用，真实两臂调用全部为本轮新执行。

首个 number-parser 默认环境准备 13.703 秒通过，metar-taf-parser 默认导入及隔离也通过；pysiaf 22.578 秒后因未跟踪嵌套 relic/ 仓库未清除而阻断，tracked diff 为 0，容器与 testbed 均已清理。该失败占三来源中的一个名额，不补题或掩盖 clean-base 失败。

另一处实际修复：已由原 queue 登记的零调用准备阻断可正常完成 command stage，不再强行索取 ready 而拖停全批；携带执行或用量的异常仍拒绝。23 项阶段测试与 39 项控制器测试通过。新独立状态复用现有 orchestration/worker 代码，Windows worker 已绑定修复；旧协调器、旧批次、main 均未改。

独立资格验收仅接纳 metar-taf-parser：number-parser 的探针额外要求公开需求未规定的 lang API，且control直接注入探针结果，已拒收并保留证据。因此本批2条准备阻断、1条完整资格，未追加来源。metar已完成唯一正常求解，21请求、22,270输出token、204.689秒；独立官方judge、真实public probe、token对齐全部通过，自动发布21条决策、21,003有效监督token。冻结抽样未选中该source，未伪造语义审查。正式窗口489.953秒，等待合计233.059秒、执行合计246.767秒；其中后处理等待210.705秒。清理可重建WSL页缓存后，宿主余量从约3GiB回升到7GiB，原内存门随后放行，门限未改。窗口token产率约154,323/h，但不含25.36分钟探针制作和工程P0，且只有一个正样本，不可外推大规模速度。若仍零准入，针对具体失败继续改进，不以完成请求数代替有效产出。

第二组已终态暂停：smbprotocol通过官方judge并自动准入4,217有效token；pscript在默认导入Python2遗留模块时失败，零调用阻断；ar以P3运行27请求、41,615输出token，学生上下文达到15,447 tokens触发原15K门限，正常隔离、未判成通过。冻结抽检未抽中SMB，当前无待抽检、无活动生产作业。

服务恢复等待曾误请求 /v1/health 返回404；原容器实际健康，改查根路径 /health 后HTTP 200，模型身份仍为Qwen/Qwen3.5-4B。没有新建模型或修改生成参数。学生历史25次观察中，P2 12次产出2,408有效token，P3 13次零产出；下一新合同将绑定既有收益分配器与冻结历史，避免每批遗忘历史后先选P3。80/20目标、自然接管和原预算保持。

第三组固定六来源终态：3准备阻断、1条P1自动准入14,211有效token、P2和P3各1条前缀截停；正式窗口340.422秒。完整建批墙钟1,945.178秒，约26,301有效token/小时。requirements-parser因扩展URL空白要求拒收，RFC5794因baseline错误信息的绝对路径与freeze不一致阻断，两者均未求解。

第四组固定五来源终态：1准备阻断、4条P2求解、2条完成且官方通过并自动准入，新增11,335有效token；另两条前缀截停。pykube自然接管发生在第21请求，favicon在第11请求；发布仅保留教师续写，学生前缀和工具上下文mask均为0。正式窗口603.219秒，完整建批墙钟1,408.075秒，约28,980有效token/小时。第4批启用哈希绑定的student-yield-v2与历史快照，39项定向测试通过，已在真实派发和P2发布验证。

八批合计474请求、9,340,479输入token、385,179输出token；正式窗口合计4,679.046秒，作业等待合计4,663.075秒、执行合计4,162.646秒（可重叠，不作为完整墙钟）。9条发布的冻结10%抽样均未选中：已抽检、待抽检、撤销均0。原producer、文字提示和原生分页三轮工程P0合计79请求、1,013,664输入token、59,391输出token，均全零监督、不可训练，单列不计正式产出。

前缀卡点已定位：15K计算完整渲染后的可见请求，不是仅assistant输出。pydlm两次整文件读取及编辑后重读贡献约59%的上下文增量；wakeonlan大段读源码/测试贡献约60%。自然W与超限同边界时按冻结协议截停。独立producer dbebc2d 仅增加五行“定位符号、显式offset/limit、检查改动区域、简洁目标测试”提示，不丢历史、不截工具结果、不增加预算；新P0验证后才能用于未来新来源。

第五组固定六个原A车道来源终态：JWT通过并准入8,709有效token，其余5条准备阻断；正式窗口209.781秒、完整墙钟1,175.552秒。两份probe重复包含路径诊断导致freeze不一致，另两份过度限制退出/异步实现，父级拒收；未重跑旧失败。

第六组新读取producer dbebc2d 已终态暂停，4来源中2环境阻断、2真实学生执行、0准入。reacton P3仍无limit读core.py，prefix从2,597跃至20,480截停；redis-lock P2产生3次每次16,384-token的纯推理输出，最终16请求/56,564输出token，以max_tokens结束且无handoff。准入遗漏该未完成终态导致阶段失败，已通过原reviewed入口证据绑定隔离，35项队列测试通过；原失败作业与run-bounded收据保留，无重跑solve/judge。

现成DSH read工具默认2,000行/50KiB；tool-result-pruner只在约102K上下文压力时工作，无法保护15K学生前缀。新独立producer 4cfcc05 仅配置 tool-fs.readLimit=100、readMaxBytes=4096，工具原生显示offset续读提示。直接执行runtime工具已验证默认/续页/UTF-8字节门，未改runtime源码、未裁剪历史。新P0两臂均通过，共31请求、381,257输入/17,252输出token，38源码绑定一致、全零监督。两臂各4次成功read页面，最大3,930字符；各1次显式limit超100被原工具拒绝，真实错误保留。第七批两条P1发布已通过独立候选重建与loss-mask核验，新增22,758 token；文字提示版无真实收益，不作为有效提速结论。

来源余量也约束目标：当前约2,097个未尝试候选，若不增加来源，要补齐2,000条轨迹需余下约92.6%准入。该比例明显高于现有观测，仅提升token速度不能保证达到来源目标；不重采质量失败来凑数。

证据：storage/audits/e2-scale-readiness-20261103/ 中的 throughput-assessment、image-prefetch-summary、p0-execution、engineering-verification；原始轨迹与 private judge 留在本地。以下保留旧批次原口径。

第八批：恢复已付费成果，修复生产控制故障

PEM的13请求、4,740输出token已通过官方判分。错误的seed去重字段导致发布失败，原清单、失败作业和窗口收据完整保留；修复输入后复用原判分发布，未重跑模型或judge。独立恢复控制器只处理原6来源中从未求解的OpenAPI与PSD，继承原绝对截止时间；已完成来源不重置，未追加来源。

正式调用148请求、3,452,729输入、140,583输出token；新增P0调用0。原窗口641.329秒加恢复窗口672.109秒，合计1,313.438秒；等待合计1,164.811秒、执行合计1,263.407秒。完整选题至终态墙钟4,431.426秒，包含准备、故障修复与等待，有效产率2,602.86 token/小时。草稿Agent和工程修复Agent调用单独留证，不混入生产模型用量，也不视为零成本。

另一次新来源准备验收（b09 dissect.cstruct）发现editable虚拟__path__被误当/testbed内目录。主调度拒绝资格，0求解、0新增模型调用，清理并单独封存；不计入八批正式生产分母，也不重试补题。修复封堵假通过，未将拒绝不明路径冒充该项目已可生产。

收据：eight-batch-summary.json、b08/final.json、b08/throughput.json、pipeline-repair/final-acceptance.json。当前campaign已halted、框架已paused、活动作业和关闭错误均0。E2目标尚未完成，剩余瓶颈是公开资格制作、模块发现兼容和求解预算内收敛。

第七批：分页已落地，学生有效收益仍未改善

八个固定来源中，五条准备阻断、三条求解、两条P1官方通过并自动准入。BigQuery 7,204 token、TD Connector 15,554 token；beautysh P2在第19请求以11,045前缀自然L接管，学生18请求/4,856输出，教师42请求/42,526输出，最终触及60请求上限，仍余18,154输出额度，0监督。

真实分页：beautysh七次成功read、最大4,654渲染字符，一次显式limit超100被拒；BigQuery七页、最大4,754字符；TD两页、最大4,275字符。4096-byte门限制选中源文本，行号与封装增加渲染长度。分页不限制bash输出，也不保证整段上下文永远低于15K。

新增阻断证据：codeowners残留外部源码；pyansys默认发现为空；dissect namespace无__file__使helper报错；LTA资格未能完成；datatree公开合同冲突。保留八来源分母，不补题、不重采。namespace导入检查先做最小修复；未经证明的模块发现变化不覆盖原hardener。

收据：storage/audits/e2-scale-readiness-20261103/b07/final.json · real-release-verification.json · read-observation-check.json · throughput.json

历史批次：最早20来源因缺镜像封存

这是镜像下载授权前的历史结果，新增准入为0；不代表当前生产总量。后续八批已新增9条自动准入，累计供给61条来源、268,881有效监督token。

按权威队列原 ordinal 固定前 20 个未尝试来源。对本机 323 条镜像记录与 2,144 个 untouched pending 来源做精确 tag / digest / ID 比对，可用交集为 0；选定的 20 条另经 docker image inspect 逐条确认 No such image。通过原 queue claim / block 入口登记零调用准备阻断，每条消耗一个名额，不替换来源。

正式启动 0；进入准备 20；准备阻断 20；求解完成、judge 通过、自动准入、待处理、抽中、已抽检、待抽检、撤销均为 0。本次没有派发生产作业，run-bounded 未执行，4 小时生产窗口未开启。终态写入独立 prelaunch-end.json，没有伪造窗口结束或 completed 审查收据。

campaign、stage、pipeline 的 automatic_policy 均为 c4c2f73f0ca9a6d80767b7ae3f5d1a6ec74f7c46e36abf11712b2be43c67c76a，冻结抽样 10%。每来源预算保持 60 请求、65,536 输出 token、1,800 秒和 15,000 学生前缀上限。main_root 指向本任务的已验收代码；新 ledger、controller SQLite、spotcheck SQLite 和收据独立建立。

renderer、student 健康检查均为 HTTP 200，协调器两节点心跳在线、活动作业 0。原 Windows handler 配置仍指向旧 main 路径，尚未绑定本次验收代码；完整来源资格、新 producer P0 和阶段脚本接线仍需就绪后才能启动。由于镜像条件已经失败，本次没有改动共享 worker 或服务，也没有执行 P0。

e2_spotcheck.py list 实测为空；没有 release 或抽中样本，bundle / record 不适用。Mac 未收到审查任务。旧两来源待审数据保持原状，权威旧账本状态和事件上限 1472 未变。若未来获得可用镜像，应另开新批次并重新确认启动条件，不重置本批 20 个名额。

配置：storage/config/e2-auto-20-20261103-d779-{pipeline,stage}.json；run：eval/work/e2-auto-20-20261103-d779/；证据：final.json（本地）、readiness.json（本地）、20 条来源与逐条阻断（本地）。原始收据不随页面发布。

已封存的两来源批次

旧批次首要卡点：B03 · Mac 审查未完成。B08 已在两来源定点验证；准入回写仍缺审查产物，审查内部卡住原因未知。

固定来源：pyca_pyopenssl_pr1327、buildkite_test-collector-python_pr61。用户明确允许恢复旧批次仅环境阻断、模型调用为 0 的来源；旧记录不变，本轮是首次真实求解。两来源之外不补题，也不重采已判负来源。

两条来源各 13 项准备检查和 13 个哈希引用通过：clean base、默认导入、network none、无外部源码副本、baseline 失败、correct control 通过、wrong control 拒绝、自动 cleanup 均有实际收据。新 P0 使用修复后的 driver 与精确响应模型身份；原 policy 与拒绝封存的旧运行保留。

两次工程 P0 合计 44 次请求、35,389 输出 token、4 次独立 judge；新合同两臂的 judge / token 对齐 / 原封存门通过。工程轨迹全量 mask、不可训练，单独计量，不计入生产来源、准入或监督产出。

Windows 使用既有 stage handler，Mac 只在审查包生成后调用当前已保存的 Review 角色。协调器、controller 和 ledger 均使用独立本轮状态；脚本限制最多两来源并在异常时恢复暂停。启动前服务与两机 worker 已就绪；封存时 primary Mac worker 已自行退出。

最终结果：BLOCKED。启动 2、准备阻断 0、求解完成 2、judge 通过 1、准入 0。pyopenssl 判负后隔离；buildkite 保留 reviewing，不能当作已准入或已判负。两来源各只求解一次，共 80 次请求、39,678 输出 token；未追加来源。

首次 Review 因节点 role_ids 缺指定角色，在 started=null 时失败。仅修复该白名单后，同一审查包恢复一次；worker 约 600 秒后报 agent_job_timeout，未取得可验证的完成回合或审查产物。底层会话当时仍运行，已由主调度取消；2026-11-03 01:29:12（北京时间）的 fresh 状态确认 Mac 在线、会话空闲、无排队回合。原作业仍记 needs_reconciliation，资源已释放；节点已通过原生 acknowledge 关闭本地回执，原 completion/result 不变、新执行数 0。primary worker 已自行退出，本次未重启。协调器 paused、campaign halted、active_jobs=0。finalize-review 未执行。

审查会话请求数与 token 用量缺收据，不能填 0；本页 80 次请求仅指两条生产求解。工程 P0 另计，未启动训练或拉新镜像。

最终生产收据 · 审查停止与资源对账 · 主调度启动验收 · 完整资格与新 P0 · 实际有界配置

自动准入与异步抽检

工程验收通过：受影响范围 136 项通过，另 1 项测试夹具修正后通过、1 项 P0 绑定检查改用现有工厂 Python 后通过，共 138 项有效检查。并非一次无失败全量运行；HTML 脚本、链接、桌面/窄屏渲染及 CLI 入口通过。20 来源新批次已因缺本地镜像在启动前封存；未执行新 P0 或正式求解。

累计61条来源、685行训练决策样本、268,881有效监督token。第八批已收尾；并发阶段重叠已验证，但新审查发现单任务租约拒绝会连带停止健康任务，正在修复。Mac Review不阻塞生产，工具合同、准备通过率与预算内完成率仍需改善。

旧批次保留原协议与收据。新自动策略须与新 campaign、配置和源码哈希冻结；会影响旧 P0 的代码变更须重新验证。仅有 CPU 合成发布测试不能称为真实生产准入或训练收益。

本轮工程验收收据（本地）。未进行真实模型调用、独立 judge 重跑或训练，不据此宣称数据收益和加速倍数。

已实现入口

新配置使用 自动流水线模板、阶段模板和 冻结策略。模板明确为 BLOCKED，须替换路径、绑定实现源码、在新 campaign.json 中写入同一 automatic_policy，再取得匹配的新 P0。旧正式配置不自动切换。

python storage/e2_pipeline.py --config NEW_PIPELINE.json dry-run
python storage/e2_pipeline.py --config NEW_PIPELINE.json run-bounded --max-seconds 14400
python storage/e2_spotcheck.py --db CAMPAIGN/spotcheck.sqlite3 list --status pending
python storage/e2_spotcheck.py --db CAMPAIGN/spotcheck.sqlite3 bundle   --instance-id INSTANCE --view-dir ADMISSION_VIEW   --reviewer-machine-id MAC_ID --reviewer-role-id REVIEW_ROLE_ID
python storage/e2_spotcheck.py --db CAMPAIGN/spotcheck.sqlite3 record   --instance-id INSTANCE --disposition passed   --result-file spotcheck-result.json --agent-result-file agent-result.json

bundle 只打包公开允许文件，并绑定来源、release、策略及指定审查机器/角色。主调度将它交给当前 Review 角色独立执行；结果须包含 instance_id、source_id、release_sha256、bundle_sha256、policy_sha256、decision=keep 与具体 reason，回传后由 record 验证实际 completed 回合。keep_with_masks 不能让原 release 直接通过；问题数据用 withdrawn 加证据撤销，可无替代版本。超时或缺结果保持待抽检，不补造通过记录。

run-bounded 到达来源上限且全部终态、异常或时间上限后停止派发并双暂停，写 run-bounded-end.json。窗口到期时已经启动的作业会列为未结，主调度须核对并有界收尾；暂停本身不等于进程已取消。已有结束收据禁止同窗口重放。

正式生产调用 prompt

以下示例将来源上限设为 20、窗口设为 4 小时；需要其他规模时只修改这两个参数。模型、预算与抽样比例从新冻结配置核验。

使用当前仓库的 multiagent 生产系统执行一个有界新批次。

批次范围：最多 20 个新来源，source_limit=20；总窗口最多 4 小时。
采用本仓库已验收的 automatic-hard-gates-v1 自动准入配置；抽样比例按冻结策略（默认 10%），抽检异步执行，不阻塞其他正常来源的求解和自动发布。

你是唯一主调度。复用 Windows 现有阶段 command handler；确定性工作直接运行脚本。Mac Review 仅处理被抽中或需要语义复核的安全审查包，不再逐条强制审核。实现修复默认一名执行者，不递归派发，不新建编排框架。

先读 HANDOFF.MD，核对 HEAD/未提交修改；从 e2-auto-pipeline.example.json 与 e2-auto-stage.example.json 建立新配置，绑定当前验收代码作为 main_root。核验策略和脚本来源哈希、完整准备资格、当前冻结预算、生产 P0、服务和生产节点 worker。策略须在 campaign、stage、pipeline 中一致绑定。新源码使旧 P0 失效时，不放宽门禁；本次允许按原冻结预算为新身份执行最小必要工程 P0，工程调用单列、不可训练。其余缺项只做必要定点修复；仍无法满足则返回 BLOCKED，不循环重审。

使用新 run、新 campaign、新控制器状态和独立收据，不修改旧批次，不复用旧上限，不重采已判负来源。每来源最多一次正常求解；准备失败也占来源上限，不追加题目凑成功。

授权本批真实求解、独立官方判分、必要已有容器/服务操作，以及被选中样本的一次独立抽检。不授权训练、拉新镜像、无限重试、push或合入main。沿用已冻结模型路由和预算，不降低来源隔离、去重、真实执行、token对齐和loss mask门。未知监督边界进入待处理，不伪造审查或准入收据。

使用 python storage/e2_pipeline.py --config NEW_PIPELINE.json run-bounded --max-seconds 14400，以及独立 e2_spotcheck CLI；启动前核对 --help 和实际配置；不能用无终止条件的常驻 run 代替有界批次。使用既有事件与完成通知监督；禁止用模型回合轮询。Mac离线或抽检超时只记录抽检未完成，不拦住其他自动正常来源；确认有问题的release通过原撤销入口处理并保留更正链，不重做solve/judge。

达到来源上限并完成各自终态，或4小时窗口到期时停止新派发，核对本批仍在运行的作业并有界收尾，保持暂停。即使0准入也结束。

返回：启动数、准备阻断数、求解完成数、judge通过数、自动准入数、待处理数、抽中/已抽检/待抽检/撤销数、生产与工程P0分别的请求/token、等待/执行/墙钟时间，以及run/config/收据路径。区分代码验收、真实生产验收与训练收益。同步更新现有HTML台账并发布到https://local-train-docs.pages.dev，提供线上页面链接。

执行提速：减少重复启动与检查

累计61条来源、685行训练决策样本、268,881有效监督token。第八批已收尾；并发阶段重叠已验证，但新审查发现单任务租约拒绝会连带停止健康任务，正在修复。Mac Review不阻塞生产，工具合同、准备通过率与预算内完成率仍需改善。

代码与收据核对后的更正

现有顺序是 prepare → solve → postprocess → prepare-review → review → finalize-review；其中 prepare 与 review 用独立 Agent，其余四阶段用已有命令 handler。求解器本身仍会调用模型；这里减少的是外层编排会话。此前“每阶段都是新 Agent”“solve 还需脚本化”的判断不符合当前源码。

本批次收据明确记录 mac_business_review_jobs=0：4 个来源因 src/Lib 导入路径与 editable 搬迁问题准备失败；另外 4 个均有独立 judge 执行收据且 accepted=false。原诊断中的“走完审查后仍未通过”不适用于这个冻结批次。环境修复已有独立候选 B08；并行增加机器内存不能修复路径或提高判分正确率。

可消除的下一项固定开销是 prepare 外层会话：当已有完整、绑定源码的准备脚本，直接运行脚本并验证原 ready.json。依然需要人工判断的公共任务审查或环境修复保留 Agent；不能把所有 prepare 都承诺变成秒级。归档接口的行为是归档会话，没有证据保证 app-server 退出，本轮不以此实施清理。

本轮调度本身也提供了反例：两个并行只读 Worker 用时 280 秒、38 次工具调用，仍把“未归档”误推成“已证实泄漏”，由主调度纠正。并行只适用于可独立交付的工作，不能用更多审查者替代明确任务边界。

已实现：prepare 可走命令，保留原资格校验

当前 route-v2 配置已启用 handler: e2-pipeline-stage，prepare 通过命令入口复用完整 ready，独立 review 保留 Agent。完整准备 helper 与来源哈希已绑定；旧批次配置保持原样。

已有合法 ready 收据直接复用；否则执行一次已绑定脚本，再由原 verify_ready 检查任务、完整检查项与文件哈希。坏收据、缺任务、脚本失败及未完成的旧尝试均报错；失败脚本遗留 ready 不能冒充成功。成功阶段按原收据幂等复用，独立 review 仍必须走 Agent。

工程验收：49 项通过。控制器 32 项（15.502 秒）、阶段执行 17 项（8.213 秒）。本地 HTTP worker 集成验证脚本模式仅 review 创建外层会话，旧模式仍为 prepare/review 两次；阶段测试执行真实 CPU helper 并校验失败、不重放、源码哈希与原资格门。首次组合测试被错误设置的 20 秒后台上限中止，之后按两个文件完整执行通过；没有把中止当作通过。HTML 锚点、内联脚本语法与 diff 检查通过，未进行浏览器视觉验收。

验收结论：准备脚本直通已在两来源生产中验证，0 准备阻断。完整资格在启动前取得，生产 prepare 阶段复用 ready，阶段耗时不能冒充从零准备成本。尚无同口径前后对照，不宣称吞吐提升；未改准入阈值、未训练。

本轮落实的执行规则

1. 固定交付物 → 复用已有脚本或一名执行者 → 一次定向验证 → 汇报并停止。
2. 只有互相独立的工作才并行，最多 3 名；子任务不递归派发。
3. 同一基线已通过的检查复用证据；修复只复验影响范围。
4. 完成通知驱动续接，避免模型回合轮询；不把 running 当进展。
5. 提交/推送不自动扩张成截图、同质审计或新方案；任务要求的报告与部署另按明确范围完成。

本轮维护同一份 HTML 并同步文档站点；代码是否合入主检出与文档发布分别记录。规则已写入本分支 AGENTS.md；这是工作方式约束，不是自动化运行时强制限额。来源：Code review 对话、缓慢原因分析对话、本轮进程/内存与会话状态查询。rate_limits=null 不能证明未限流；普通 HTTPS 延迟不能排除模型端排队。当前两来源已有真实执行收据，准入为 0；暂无同口径生产提速对照。

01 · 历史生产基线

窗口：2026-11-01 09:56:58Z 至 11-02 02:46:28Z；事件截止 1421。暂停后的时间不计入速度。以下为历史基线，未并入当前两来源批次。

02 · 原语义审查协议（保留兼容）

旧协议由持久 SQLite 控制器接续六阶段；新自动模式改用命令准入，Mac 仅处理独立抽检。Windows 保留发布权威，跨机材料继续使用公开允许列表和 hash 绑定。

机械层此前已通过双机探针。11-03 两来源已真实求解与独立判分，一条审查包送入 Mac；以本页当前批次的原始收据为准，不将 CPU 测试或资源配置外推为吞吐收益。

03 · 持续维护的卡点台账

按当前处理优先级排列，保留 B01–B12 固定编号。B09–B12 记录镜像供给、资格成本、环境自身副本与生成窗口损耗；B03 记录旧批次阻断与新自动路径验收，B04/B07 留待定点验证，B05/B06 属后续数据与协议议题。

2026-11-05 增补 B11/B12：镜像把项目自身装到 /testbed 外，副本来自镜像默认 HEAD 而非声明 base；GLM 9 准入、DeepSeek 10 准入，58 个 DeepSeek 来源里 25 个环境门零调用、5 个网关重置、2 个探针 hold，真正判分 26 个。修复必须先删副本、pip wheel 缓存与 hatch/pipx/pipenv 工具环境，再从 /testbed 做 editable 重装并过原门；不得放宽 source-copies 判定。

04 · 正式数据生成窗口工程复盘

2026-11-04 GLM 与 DeepSeek 两个正式生成窗口封存。这里只复盘工程损耗；正常判分拒绝、预算耗尽与基础设施失败分开记录，旧收据不改写。

口径：按真正判分的 25 个算，通过率 10/25（40%）；按 58 个入队算才是 17%。GLM 另有 9 准入、56,401 监督 token。低准入率的主因在求解之前，不是模型完全不会做。

损耗排序与当前判断

1. 环境门把镜像安装副本/缓存当外部源码。25 个零调用来源中 19 个触发 source_copies：11 个是真副本（pdbpp、coverage、mudata、flake8-pie、singer、dbt-artifacts-parser、pyjq、pynvim、banks、dparse、multipart），5 个是 tests/doc/backports/google/testing 等发现名误杀，3 个模块列表为空，另 6 个是导入/发现/安装失败。真副本的镜像默认 HEAD 不是声明 base，不能放宽门；只能先删副本、清 wheel/hatch/pipx/pipenv 环境，再从 /testbed 做 editable 重装。
2. 公开探针比官方判分窄。进入判分的 26 个来源里，25 个公开探针第一次、也是唯一一次运行就 passed，feedback_issued=false；官方要求 f2p 全过且 p2p 无回退，15 个拒绝分别差 1–7 项。被拒绝来源中位请求数 24，准入来源 12.5：不是轮次不够，是探针没有把差距暴露给模型，模型在探针通过时停了。
3. 上游网关与备用路由。14:06 本地网关重置（WinError 10054），5 个在跑来源以 teacher_upstream_error 结束，77 请求无补丁；每源只尝试一次，所以没有重放。主路由 639/646 请求 HTTP 200，但 api.deepseek.com 两份 key 都返回 401，主路由一旦限流，请求可能落到坏路由并烧掉唯一机会。
4. 并发和资源门先限死，再放开。初期只有 1 个求解槽，CPU 接近 0、宿主约 11 GB 可用内存，来源却串行；之后依次提到 2、6、12，协调器作业上限 20。内存预留 2048 MB，而 solve 实测峰值约 414 MB，六槽放不下；后降到 768/512 MB。WSL 页缓存把 vmmemWSL 撑大时，available_mb 会跌到 3.6 GB 但无真实压力，drop_caches 后回到约 8 GB。重启协调器会杀掉在途求解：meeb 损失 39 请求/21,421 输出，容器保活曾被误判为“还活着”，并手改过 SQLite，后按 infra 排除、不重放。
5. 批次控制和冻结机制脆弱。run_bounded 退出会暂停协调器，而暂停又被当成终态，重启后立刻再停；needs_infra_review 也会停批。任何单来源作业失败会停全批：ml31415 判分通过但公开探针未过，_suspend 停了 84 个待跑来源；后改为只 hold 该来源。批次中不能在 producer 工作树 commit，verify_campaign 校验 HEAD 等于 campaign.producer.head，提交会让后续 finish 全失败；改 e2_campaign_prepare.py 后 stage 配置仍引用旧 hash，控制器直接退出。
6. Docker 磁盘与镜像供给。前一批 e2-formal6 启动时 Docker 数据盘 100%、可用 0；4 次 image-pull 失败、2 个来源未拉取，教师/solve/judge 全 0。删除 176 个不能复用的 scaleswe 标签后恢复到 71%、275.7 GB；1 个因 Created 容器占用而保留。更早的 20 来源批次因本地镜像全部缺失而零调用封存；manifest 可查不等于镜像可下载或可执行。
7. 去重、授权与数据治理。501 个历史已选/已尝试 ID 中，只有 131 个零调用基础设施失败可一次性放行；157 个已经真实求解过，不能按质量重采样；10 个选中但从未启动、8 个无执行记录、1 个准备失败、2 个明确阻断。授权必须逐 ID、绑 41 份旧账本 hash、带截止时间，用过一次回到排除名单；不能改代码开长期口子。

当前未闭环

• 5 个误杀来源的重跑尚未执行；对话最后只修了 stage 配置 hash，控制器退出问题刚处理。
• 11 个真副本来源尚未删装重装：pdbpp、coverage、mudata、flake8-pie、singer、dbt-artifacts-parser、pyjq、pynvim、banks、dparse、multipart。
• 25 个环境门零调用、5 个网关重置来源没有重放；2 个探针未过单独 hold；27 个作者 hold 未入队。
• DeepSeek 备用 key 仍是 401；共享宿主原子预留仍缺完整部署/验证，当前并发主要靠固定配额。
• B11/B12 仍为 open；已发布 HTML 台账不等于来源已修复或已重跑。

下一步顺序

1. 先修 project_modules 发现规则：排除通用名、区分“发现为空”和“真有副本”、处理单文件模块；重跑 5 个误杀来源。
2. 对 11 个真副本做“删副本/缓存/工具环境 → editable 重装 base → 原门复审”，不改判定。
3. 用公开可见测试扩大 probe 覆盖，减少“probe 通过但官方差 1–7 项”；hidden judge 仍不进入提示。
4. 修备用路由 key，并定义基础设施失败的安全一次性重放，不消耗正常质量失败来源。
5. 控制面：单源失败隔离、暂停/终态分离、有租约时禁止重启、批次中禁止 commit/hash 漂移；资源门按实测峰值和全局原子预留配置。

证据：HANDOFF.MD、storage/audits/e2-reuse131-20261104/authorization.json、storage/audits/e2-reuse131-20261104/meeb-whoisit-infra-stop.json、storage/audits/e2-reuse131-deepseek-20261104/gateway-reset-20261104.json、storage/audits/e2-scale-readiness-20261103/b14/dparse-environment.json、b05/environment-block.json。原始轨迹、判分材料和私有 judge 留在本地，不随页面发布。

05 · 已验证到哪一层

全批次 595 次监测日志采样中，Windows 可用内存低水位为 1,162 MiB，采集到的容器 OOM / OOM kill 计数为 0。求解阶段 25 次资源探测合计约 610 ms。RSS 可能重复计入共享页或漏过短进程；Windows 余量、WSL 工作集与容器 cgroup 有重叠，不相加。当前两来源已测到真实 Docker 阶段；Mac Review已启动但未完成，正向发布仍未验收。

证据入口：本轮工程验收与历史口径 · 原多机框架验收。原始生产账本、审查材料和私有 judge 留在本地，不随本页发布。

06 · 维护与下一次验收

python storage/e2_pipeline.py --config PIPELINE.json dry-run
python storage/e2_pipeline.py --config PIPELINE.json status
python storage/orchestration_manage.py start-pipeline \
  --config PIPELINE.json --runtime-dir RUNTIME