数据生产卡点与提效进展

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

当前结论：继续有界扩批，同时验证学生读取改进。历史 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发布验证。

五批合计200请求、3,312,997输入token、117,028输出token；正式窗口合计2,144.515秒，作业等待合计1,804.019秒、执行合计1,750.694秒（可重叠，不作为完整墙钟）。6条发布的冻结10%抽样均未选中：已抽检、待抽检、撤销均0。工程P0单列：原producer25请求/26,612输出token；新读取提示23请求/15,527输出token，两臂官方判分及对齐通过、38源码绑定、全零监督。两轮P0均不可训练。

前缀卡点已定位：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 与31条冻结学生历史，4来源中2环境阻断，2份probe先草稿审查与修正再首次freeze，均通过完整资格。真实P3 reacton仍无limit读core.py，prefix从2,597跃至20,480而截停，证明仅文字提示不够；P2 redis-lock运行中出现一次16,384 token全推理输出，尚未形成终态。继续定位现有read工具默认分页，保留所有原观测和预算。

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

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

本批结果：BLOCKED，正式生产未启动

按权威队列原 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 或正式求解。

新批次取消逐条强制 Agent 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，提供线上页面链接。

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

当前可直接减少的是准备会话的项目重读、模型往返和收尾扩张。先复用已有命令入口，再让 Agent 处理真正需要判断的部分。

代码与收据核对后的更正

现有顺序是 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–B08 固定编号。B03 记录旧批次阻断与新自动路径验收；B04/B07 留待定点验证，B05/B06 属后续数据与协议议题。

04 · 已验证到哪一层

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

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

05 · 维护与下一次验收

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