核心生成步骤（P05）提议的核实

10-23 codex 终端提议：模型只写新的判断、选择和方案；原件里已有的值、规则能算出的值、前序结果里已定的值，都由程序按引用生成。第一步做终稿生成，再从编译包里抽出通用的 P05。所有者要求先核实设计、暂不改代码，重点确认四件事：落点与现有实现是否一致；P05 要补哪些版本化契约；生成、回读、检查和修复轮怎样衔接；生成结果怎样保留原判断的性质、来源权限和适用条件。

核实由九个只读复核员完成：六个按子系统对照 hub-redesign 的代码，一个综合出设计，两个分别从安全和模型正确性的角度挑错。关键几处集成者又亲自对过代码。下面的 文件:行 指 hub-redesign 在 4a04761 前后的版本。

结论：方向和通用模型一致。P05、W05、T04 本来就写着“程序从槽位和引用出件，模型只写判断”。但第一步不该选终稿：终稿的要求项是运行级的，而运行级要求项现在没有层终态，也没有修复轮。建议先在编译上试点。

一、落点核对

提议的落点	结论	依据与差别
模型只填新的判断，其余由程序生成	部分一致	模型里分散在 W05（受限槽位）、T04（解析而非限制）等处，没有成为一条规则。只能靠槽位模式不要这些值来落实，不能变成“重复写就拒收”的规则；前序结果里的值经 rec: 重核，不是继承
终稿：投影已算出整体结论、等级和发现清单	照抄这一点一致，计算本身有错	投影确实算出了这些（packs/workflow/case-review-report/functions/projection.ts）。但它有四处错，生成器会把错误冻住，见第七节
终稿“影响小、容易验证”	不一致	终稿的要求项是运行级的。运行级要求项只产生跨条目主张，没有层终态、错误路由和修复轮（hub/runs/engine/evaluate.ts:654-664；引擎 README 自己记着这个缺口：hub/runs/engine/README.md:303-305）。生成或回读失败没地方记“出件失败”
把生成从检查函数里分离	诊断对，比提议说的更急	检查函数只许给五种未知原因（hub/rules/check.ts:84），不含 output_failed。编译包回读失败时给的 unknown(output_failed) 被判为输出无效，整份改成 check_error（check.ts:94）。条目成了“未核对”并留在已交付，违反 P05 R[0]。引擎也不写生成和回读动作
从冻结的输入、引用和槽位生成	部分一致	冻结输入已有现成形状（检查主体的输入，contracts/src/pack.ts:247-259）。缺口：源文件只按摘要冻结；编译的组带着合约和清单，却不带它们的摘要；RunContext 没有组成摘要；运行级输入没有提交；槽位数据里的引用不在边界解析（检查读片段的修复正在做，任务页 check-fragments.md）
存为现有的 source_artifact，记生成器版本、输入依据、回读结果	部分一致	记录形状和 origin.generated 已有，四条核心路径在写。缺口：生成器只记 name@major；inputs 由调用方给，只校长度（hub/records/artifacts.ts:95-96）；read_back 没有定义，也没人写；没有运行链接；可见性和读档位由调用方随意给
检查函数核验并交付	部分一致	检查只读 run.sources，看不到提交时才生成的产物；检查也从不交付，交付是交付前边界算分区和要求项状态。最小设计：检查照旧核槽位，回读把字节绑到槽位上
不再把计划全文藏在检查结论的 data 里	一致	全文现在复制进每条 validation@1 记录和每次 submit_result 回执，还占单条记录的上限，模型看到的文字里却没有它
复用 B01、W05、records/refs、沙箱、根组成、六个工具	一致，有三处调整	沙箱对所有函数种类用同一套限额，生成器要单独的；根组成是编译目录检查的依赖，不是两个生成器的依赖；复用机制已经有一个（知识生产器的 memo 按复用键写 generate 动作），P05 应沿用
Hub 继续不调用模型	代码一致，文字要改	三处已发布的文字说得过头（docs/hub-r4-architecture.md:14 的 “The Hub never generates content”、进度页、contracts/src/tools.ts:27 给客户端的说明）。核心 P05 落地前，要改成“Hub 不调用模型，只经声明过的确定性包生成器生成”
先用终稿和编译验证通用，再扩到文档派生	部分一致	两个用户还不够，还要同一份合约、不带产品语义。所谓“文档派生”，连接器读取后的投影已经在写 origin.generated（hub/connectors/read.ts:577-590），只是没有回读；叫“文档派生”会让“派生”多出一层意思，建议叫“连接器读取的投影”

二、P05 要补的版本化契约

1. 模型 v8 的 P05 规则：步骤在哪、补哪个要求项、前提是什么、失败分几类、存什么、读取器要多独立、复用覆盖什么。
2. workflow.json 加可选的生成器声明：生成器和读取器是两个模块，各有自己的 @版本。
3. 生成器输入沿用条目级或运行级的检查主体输入；运行级要补上槽位和跨条目主张。
4. 生成器的输出、回读的输入和输出，各一个登记的形状。存下的字节由 Hub 做，不由包做。
5. 定准 origin.generated：生成器加确切的包摘要（包摘要覆盖每个函数文件的字节，@major 在 1.x 版本之间会撞）；inputs 由 Hub 算出并按引用解析；read_back 指向回读动作。
6. 生成和回读两种动作记录（运行、条目、输入、组件@版本、结果、复用键），以及它们的错误码，进码表。
7. 规范字节：JSON 用 RFC 8785，文本照原样 UTF-8，Hub、包和独立核对脚本算出同一个 sha256。
8. 交付面：条目级不变；运行级在 validation@1 加 run_requirements。
9. 发布时的生成器样例：同样输入两次字节相同，读取器抓得出已知的坏字节，否则不发布。
10. exec-plan@1 发布字节规范，带共享向量。
11. 给客户端的服务器说明改措辞（见上）。

词表里现有的值都够用，不需要新词。

三、生成、回读、检查和修复轮的衔接

1. 提交先过边界校验（结构、作用域、精确值），和现在一样。整份不受理时，不生成、不入库。
2. 受理以后，各检查照旧核槽位，驳回按错误表路由到修复。每条驳回都指向模型能改的槽位。
3. 闸门：这个条目的前置要求项的静态层都是 pass 才生成。“没有意外驳回”不够：前提记未知、或者反向用例里的预期驳回，都不能放行。
4. 生成：在沙箱里调用生成器，用生成器自己的限额。
5. 回读：另一个模块、另一次沙箱调用，读取器给出差异。到这一步为止一切都在内存里。
6. 记下回读动作和生成动作。
7. 失败（生成器出错、输出不合形状、回读出错、有差异、超过大小上限）：不入库。生成器的要求项记未知（output_failed），条目进未完成。这不算模型的错，不耗修复轮。
8. 成功：等结果记录存下、确定受理以后再入库为 source_artifact。否则结果最后没被受理，入了库的字节也删不掉（对象只追加）。
9. 交付前边界照旧算分区和要求项状态。记账型运行里，“已交付”只说明条目有了终态，不说明通过；用的一方只取全部必需要求项都满足的（门禁型，V06，现在还没做）。
10. 下一轮：只为前提已经满足的条目生成，或者按复用键命中。

失败分三类，各记在不同的生产者头上：

• 模型写错了槽位：检查驳回，走修复轮。
• 生成或回读出错：output_failed，记在包上，不耗轮。
• 前提没满足：不生成，归因沿用那条前提的归因，不记成数据缺口。

四、保留性质、来源权限和适用条件

性质。 字节本身不带性质（B02：“只支撑‘它在那儿出现过’，推不出‘它对’”）。性质留在关于它的主张上：

• Hub 汇总判断得出的事实，标“依赖判断”，前提指回那些判断。
• 终稿里的复核结论照样是判断，整体结论是在判断之上算出的事实。
• 生成物再被别的运行绑定时，要按“转载”的身份绑定，核它的检查按“规则管主张”办。判断不能因为进了生成物就变成源文件里的事实。复核员把这一条列为高风险，要写进模型 v8。

来源权限。

• 生成物默认只对运行者和管理员可见，再按输入收窄。
• 字节里含模型文字或人写的内容时，作者记提交人，来源类型记“声明”。不能记成 Hub 自己的投影，否则会绕过“受理不抬起人提供的字节”这条规则。
• 每次读都重核读者权限和受理。
• 包版本下架后不再生成；已有的主张显示“规则已撤回”。
• 生成和回读动作的详情只记码、指针、摘要和大小，不记会回显内容的文字。

适用条件。

• 生成器要求项的主张，绑定的摘要要加上产物的 sha256 和读到的每份来源的摘要（编译要补合约和清单的摘要）。任一摘要变了，主张作废。
• 照抄进产物的地址等值，它们的前提和期限（例如租约的到期时间）要跟着带上。

五、复用和缓存

复用键是下面这些内容的 RFC 8785 规范 JSON 的 SHA-256：

• 生成组件@版本
• 包摘要
• 生成器和读取器的标识
• 交给沙箱的规范输入：冻结的条目、规范的槽位、解析出的依据文字、运行上下文

任何一项变了就是新键：包换了版本、根或构建换了、条目内容变了、槽位变了、所引片段变了、参数变了、合约或清单变了、租约视图变了、限额变了。

命中了也不能绕过这些检查：

• 调用方对运行的可见性
• 每次读时的读者权限和受理
• 锁定的根和包摘要
• 本次提交的精确值解析
• 全部检查，带过来的条目也照跑
• 交付前边界
• 租约的有效期

建议先只记复用键，量过再开启命中。

六、验证

项	做法	通过条件
模型必填的字段	新旧槽位模式和真实提交对比	Hub 能算的、已有的值都不在槽位里；终稿只剩分析、建议、缺口，编译只剩桶、块、步骤、期望
提交和修复次数	同一输入对基线重跑多次	不上升；下降要多次重复才算；output_failed 从不出现在修复明细里
传输量	量 start_run、submit_result 和记录的大小	计划全文不进回执和 validation@1 记录，按引用取
重复计算和耗时	同一台机器、同样输入重复跑	只按测得的数字说快了多少
错引来源	引用不在本次运行范围内	边界整份拒收，或者检查驳回，写明原因
构建不符	不同根的复核块合成终稿	开始运行时按根不等拒绝
原件变更	改一份输入以后重跑	新键，不复用；旧主张显示“被引片段已变”
权限撤回	撤回读权限或受理以后再读	读不到，不给字节
回读失败	合成一个回读必然不一致的生成器	不入库，output_failed，条目未完成
依据不完整	某个条目哪一块都没交付	整体结论记未知，列出缺漏，不给结论码
缓存不能绕过检查	命中以后改权限、改根	每次照样核，读不到的不给

七、核实中顺带查出的现有缺陷

这几处和 P05 无关，已交给终端修：

1. 检查函数不许给 output_failed：编译包回读失败时，条目成了“未核对”，而不是“未完成”（hub/rules/check.ts:84，hub/runs/engine/terminals.ts:53 本来就把它映射成未完成）。
2. 终稿的投影：
   • 比的分区名 unfinished 根本不存在（projection.ts:154；分区只有 delivered、rejected、quarantined、incomplete），所以缺漏条目从来不会被列出。
   • 块结论取的是复核员自己写的结论码，没看 Hub 对它支持没有（projection.ts:34-48）。
   • 块结论的引用是空串。
   • 缺了块结论时记驳回，不是未知。
3. 运行级要求项没有层终态和修复轮：终稿包声明的修复行从来不生效，README 写的“修复 2 轮”与实际不符。这是核心缺口，也是终稿 P05 的前提。

八、要所有者定的

1. 先后次序：建议先在编译上试点核心 P05（条目级；生成器、读取器和独立核对都已经有了），终稿等补上运行级要求项的结果字段以后再做。
2. 方法变更：终稿的固定部分由包内生成器组织，模型只写分析、建议和缺口。架构第 6 节写的是“终稿由起草方组织”，所以这一条要所有者确认。
3. 等级的并列规则：代码取“第一个最差块的等级”，任务页写“取各块最差的一块”，生成器要冻住哪一条。
4. 措辞：把“Hub 不生成内容”改成“Hub 不调用模型，只经声明过的确定性包生成器生成”。
5. 生成物能不能分享：建议第一步一律不可分享。

其余几条照复核员的推荐办，除非所有者另有意见：

• 失败怎么归类
• 读取器的独立性怎么判
• 失败的产物不留字节，只留摘要和差异
• 复用先只记键
• 不受理的提交不生成