spec-readiness

规格就绪度

从实现者的角度审查当前规格：

如果明天就开始实现，实现者必须自行决定哪些契约，而这些契约本应由规格预先确定？

当调用包含 Adapter: codex-task-to-spec 时，验证指定的数据包清单和哈希，完整阅读冻结锁定文件和种子清单，并阅读 Authority resolutions: 清单中所有非 none 项对应的 JSON。仅审查提供的脱离分支提交。父级文档和对话记忆不具权威性。使用完整模式，并保持脱离分支的工作树只读。

如果该适配器调用包含 Stage: resolution-check，则暂停使用常规判定格式。阅读指定的问题解决产物，并且仅返回：

Resolved: yes | no
Lock: changed | unchanged
Resume: task-groundwork | to-spec | commit | review-stage
Basis: <absolute question-resolution artifact path> | sha256:<hash>

验证解决方案 JSON 的来源角色、阶段、变更情况和 calling_phase。 锁定文件有变更时返回 task-groundwork。锁定文件未变更时，仅当现有规格字节在该答案下仍然有效时返回 review-stage；锁定范围内的规格变更则返回 to-spec。

在此解决结果后停止；其余所有判定和报告规则均不适用于该次调用。

审查产物，而非作者。不要编辑规格或代码。仅当调用包含 Write report under: 时才写入报告文件；此时在该目录下写入 YYYY-MM-DD-HHMM-spec-readiness.md（使用本地时钟）。如果该确切名称已存在，则依次追加可用的 -2、-3 等后缀。完成报告后，写入相同内容，并在聊天中输出相同内容。不要在报告中附加粘贴卡片。若没有 Write report under: 字段，则仅在聊天中回复——不要创建或修改文件。不要根据规格文件夹猜测写入路径。如果调用包含 Lock:，则完整阅读该文件，将其视为冻结锁定文件；不要用聊天摘要代替。

所有调查均通过工具和私下推理完成。仅返回完整报告：第一行是 READY 或 NOT READY，下一条非空行是 Basis:。不要添加标题、进度叙述、包装内容、审批步骤或稍后输出的提纲。如果宿主将答案存储在产物中，该产物必须包含相同的完整报告。

阅读 references/outcome-lock.md，并根据其中的边界对规格进行评分。不要将参考文档复制到报告中。如果已有交付成果的负责人／路径已拥有所需结果，则使用该成果；在此任务中另行构建一套并行机制不算闭环。

收敛规则——覆盖之后的所有指令

1. 仅当当前证据证明实现必须自行选择一项有约束力的结构契约，而该契约本应由规格规定，并且不同选择会改变已声明的工作包、使用方或可观察结果时，才确立阻塞项。
2. 既往根因、审查历史、审查模式或重复出现的根因，都不会造成阻塞项。
3. 完成下文规定的有限范围内的账本、依赖、验收和反向路径审查。如果确认当前阻塞项为零，立即返回 READY。
4. 不设数字化的审查轮次或重写次数限制。只有当前证据证明至少存在一个阻塞项时，才保持 NOT READY。
5. 仅当缺失或相互矛盾的约束性依据需要人类作出选择时，才提问。绝不要因为先前审查失败或根因重复而暂停。

结构性门槛

只有当不同答案会通过数据、控制、身份、所有权、权限、持久化状态、生命周期、兼容性、恢复、附带影响或验收行为，改变已声明的工作包、使用方或可观察契约时，缺失的选择才构成阻塞项。

如果不同方案仅在单个组件内部有所差异，并且保留所有边界和可观察义务，则该选择属于实现自由。私有算法、辅助项名称、局部重构以及假设中的使用方均不构成阻塞项，除非约束性产物表明它们是关键依赖。

只有在约束性产物明确定义状态激活或推出时间时，才说明相关时间。不要仅仅因为代码变更将会部署，就推断状态会立即激活。

冻结边界

从目录、决策、基础工作简报或明确的人类锁定中冻结 Outcome 锁定。规范自身的 Outcome 锁定部分是偏移证据，不是新的权威依据。严格遵守冻结边界；不要臆造相邻的产品需求。

现有代码可以表明冻结的 Outcome 是否已确定、当前由哪个已落地的负责人或相邻部分负责某项行为，以及本规范会更改什么。不能仅仅因为附近存在严重故障就扩大任务范围。

对于每个 Blocker，根因与关闭方式必须说明缺失的契约为何属于此任务。如果移除由子项负责且缺乏依据的机制就能消除问题，则应要求移除该机制或由人类作出决定，而不是要求补全该机制。如果冻结的 Outcome 仍要求实现部分行为，则应拆分并仅关闭该部分。用普通文本指出任何现有负责人／路径。任务授权缺失或相互矛盾时，应向人类提出问题，绝不能据此作出更强硬的审查解释。

只有当关闭方式仍处于冻结的自有 Outcome 或现有负责人／路径范围内时，才返回 Next: to-spec。相邻 Outcome、新的持久负责人或扩大锁定范围，都需要提出一个 Question:，并返回 Next: wait for answer。

审查依据

1. 定位并重新阅读确切的当前规范及直接具有约束力的工件。记录路径以及内容／修订标识。对于 Git 工件，当暂存区与工作区内容不同时，应区分两者。如果无法检查 Git 标识，则在尝试一次后记录此限制；不要重试等效命令。
2. 使用冻结的 Outcome 锁定、验收／停止条件、有序工作包，以及相关的迁移、回滚、恢复或激活状态。如果调用中包含 Lock:，则将该文件全文作为冻结锁定读取。不要将其作为单独的报告字段进行说明。
3. 默认使用 full 模式。有关复审的模式选择、收敛和增量流程，请遵循 references/incremental-review.md。

如果不存在可识别的当前规范，则返回 NOT READY，说明缺失的依据并停止。不要根据猜测重建规范。

对于常规的 codex-task-to-spec 审查，请在现有的 Basis 行中使用以下确切的机器标识：

Basis: full; commit-sha=<detached full Git SHA>; packet-sha256=<manifest SHA-256>; <paths and reviewer-owned basis detail>

只有当种子清单中未列出的仓库路径是判断当前台账或验收主张所必需的直接关键依赖时，才打开该路径。不要进行开放式仓库扫描。对于每个此类路径，在报告中添加一行 Evidence addition:，记录其相对于仓库的路径、审查提交中的完整 Git blob 哈希，以及理由。

审查完整性

每次审查都必须在报告前完成所有适用节点、边、台账行、验收路径和触发的反向路径。不能因发现第一个 Blocker 就停止：应在一次批次中返回所有当前可检测到的不同 Blocker 类别。

合约账本

为每个独立所有的工作包创建一个私有节点，并为每次生产者与消费者之间或权威方之间的交接创建一条有向边。检查每个适用节点和边的以下各行：

行	必需的合约
所有者与结果	入口、所有者、依赖项、构造、事务／生命周期所有者、承诺的结果
输入与权威性	形状、前置条件、上下文、输入或事实不一致时的规范来源
公共合约与身份	跨任务类型、创建权、状态、载荷、相等性与身份含义
结果	成功、无操作、重放、拒绝、冲突、数据缺失／格式错误、失败、回滚、重试与重试耗尽
状态与效果	前／后状态、精确记录、持久化、副作用、顺序、兼容性、激活与恢复
证明	验收标准、观察点、可区分的反例与测试判定依据

针对每个适用行，私下判断产物是否选定了连贯的合约、剩余选择是否属于行为等效的本地自由、未知项是否已明确指定负责人并限定范围，或实现是否必须自行选择缺失的边界合约。只有最后一种情况才是阻塞项。不要将这些内容作为状态标签输出。

不要因为列出了端点或正常路径，就认定整个节点已完成。只要已列明现有所有者／路径的所有者、入口和可观察的失败路径，就已足够；本任务无需指定该所有者内部的状态机。

条件式深度

仅应用由账本触发的检查门槛。当规范跨越公共类型／身份、多组件构造／所有权或持久／并发状态边界时，阅读 references/structural-gates.md，并应用对应章节。单节点的本地编辑无需回答数据库、发布、并发或公共 API 相关问题。

按依赖顺序遍历工作包。对于每个缺失的决策，追踪所有依赖的生产者、消费者、状态、错误、测试和下游任务。将同一缺失规范合约的各种表现归并在最早出现的该合约之下。只有当各项选择可以独立变化时，才拆分发现项。由同一缺失规范合约导致的冲突结果、验收缺口或下游消费者影响，都属于该阻塞项的决策范围；不要将其另列为阻塞项。

对每条验收标准和终态变更，反向追踪：

结果 -> 变更 -> 证明／快照 -> 观察 -> 来源／身份

核实每个必要环节都存在、保留绑定身份和权威性，并且有可观察的反例。每项验收断言都必须能观察到可区分不同竞争合约的反例；测试套件通过或正常路径样本，只能证明其实际断言的内容。只有在检查完所有节点、边、适用行、验收路径和触发的反向路径后，才停止。审查范围应与任务相称。

结论与输出

可见交付内容必须从第 0 个字符开始，首行只能是 READY 或 NOT READY。READY 要求没有任何 Blocker，且仅存在有明确负责方、范围有限的已知未知项。绝不使用“有条件就绪”。 不要用标题、审批卡片或外层代码围栏包裹报告。

然后写一行 Basis（示例格式；符合实际时使用 READY）：

NOT READY
Basis: <full | incremental | reset-to-full>; <paths and exact content/revision identity or limitation>

仅报告下文定义的字段。不要复述任务、审查方法、覆盖流程或先前叙述。

READY 不能只是一个结论。在 Basis 后添加一行简洁的 Ready evidence:，指出具名契约/使用方覆盖情况、相关的实质性实现自由度、现有负责人/路径，以及为何未触发的结构性门槛不会产生额外义务。

重新审查时，在当前发现之前，仅输出简洁且与决策相关的 Prior 行：

Prior: <id> resolved | still present | superseded — <current-spec evidence that decides the status>

在 Codex 适配器模式下，为种子清单之外直接打开的每条路径各添加一行：

Evidence addition: <repository-relative path> | <full Git blob hash> | <reason>

路径和原因写在同一行，且两者的值中都不得包含字面分隔符 |。

仅报告当前 Blocker，并使用以下精简格式：

[Blocker] <title>
Evidence and impact: <current path:line/section or inline clause; activated harm / structural divergence and recoverability>
Root and closure: <stable descriptive root; why it belongs to this task; existing owner/path when applicable; other manifestations; producers, consumers, states, and proofs the next to-spec rewrite must close; falsifiable decision without prescribing excess mechanism>
Proof: <independent evidence / distinguishing counterexamples>

上述每个 Blocker 字段均为必填项。重新审查时，在 Root and closure 中简要说明其由来或重复原因：指出此前根因是否仍存在、此前审查是否遗漏了其依据中已有的证据，或重写是否使该根因变得可触发。非阻塞的局部歧义、薄弱证据和轻微的清晰度损失不属于此就绪报告的内容。

在锁定范围内判定为 NOT READY 时，以以下内容结尾：

Next: to-spec

判定为 READY 时，以以下内容结尾：

Next: review-stage gate

如果冻结锁定已决定移除或使用某个已落地的负责人/路径，则缺乏依据的子项架构属于锁定范围内的 Blocker；结尾使用 Next: to-spec。如果缺少绑定效力的依据或依据相互矛盾，导致实际架构、范围、持久化存储或创建/替换/取消的选择仍未确定，则不要发送 to-spec。列出当前 Blocker 后，以一句具体的通俗语言问题 Question: 结束，并使用 Next: wait for answer。说明有证据支持的选项及其后果，不要给出固定选项菜单。绝不要把重复的根因、不完整的修正或先前的 NOT READY 转化为权威性问题。

当多个契约都能满足结果时，不要规定架构。计划正确性应交由 adversarial-spec-review，运行时/PR 正确性应交由相应的审查技能处理。