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: がある場合は、そのファイルを凍結されたロックとして 全体まで読みます。チャットの要約で代用しないでください。

調査はすべてツールと内部推論を通じて行ってください。完成したレポート のみを返してください。1 行目は READY または NOT READY、その次の 空でない行は Basis: とします。タイトル、進捗の説明、ラッパー、 承認ステップ、後で出力する内容の概要を追加しないでください。ホストが 回答をアーティファクトとして保存する場合、そのアーティファクトには 同じ完成済みレポートを含めてください。

references/outcome-lock.md を読み、その境界に照らして仕様を採点 してください。参照文書をレポートに転載しないでください。必要な結果を すでに所有しているランディング済みのオーナー／パスがある場合は それを使ってください。このタスク内に並列の仕組みを所有させても、 解決にはなりません。

収束の法則 — 以降のすべての指示より優先

1. 現在の証拠により、実装で仕様が定めるべき拘束力のある構造上の契約を 選ばなければならず、選択肢によって宣言済みの作業パッケージ、 コンシューマー、または外部から観測可能な事項が変わると証明された 場合に限り、ブロッカーを立ててください。
2. 以前の根拠、レビュー履歴、レビュー形式、または同じ根拠の再発は、 ブロッカーの理由になりません。
3. 以下の範囲に限定した台帳、依存関係、受け入れ条件、逆方向経路の レビューを完了してください。現在のブロッカーがゼロと判明した場合は、 直ちに READY を返してください。
4. 数値によるレビュー回数や書き直し回数の上限は設けないでください。 現在の証拠によって少なくとも 1 つのブロッカーがあると証明される 間のみ、NOT READY としてください。
5. 拘束力のある根拠が欠落または矛盾していて、人の選択が必要な場合に 限って質問してください。以前のレビューが失敗したことや同じ根拠が 再発したことを理由に、決定を保留してはいけません。

構造上の基準

選択肢の違いによって、データ、制御、識別、所有権、権限、永続化状態、 ライフサイクル、互換性、復旧、副作用、または受け入れ動作を通じて、 宣言済みの作業パッケージ、コンシューマー、または観測可能な契約が 変わる場合に限り、未決定の選択をブロッカーとします。

代替案が単一のコンポーネント内にとどまり、すべての境界と観測可能な 義務を維持する場合、その選択は実装の自由です。非公開のアルゴリズム、 ヘルパー名、局所的なリファクタリング、仮想上のコンシューマーは、 拘束力のあるアーティファクトによって不可欠と定められていない限り、 ブロッカーではありません。

状態の有効化時期やロールアウト時期について述べるのは、拘束力のある アーティファクトがそれを定義している場合に限ります。コード変更が デプロイされるというだけで、即時に有効化されると推測しないでください。

固定された境界

カタログ、判断事項、準備概要、または人間による明示的なロックから、Outcome ロックを固定します。仕様書内の独自の Outcome ロック節は、逸脱の証拠であって、新たな権限ではありません。固定された境界内にとどまり、隣接するプロダクト要件を勝手に作り出さないでください。

実装済みコードから確認できるのは、固定された Outcome が決定済みか、現在どの実装済みの担当者または隣接要素がある動作を担っているか、そしてこの仕様書が何を変更するかです。近くに重大な不具合があるという理由だけで、タスクの範囲を広げることはできません。

各 Blocker について、原因と解消方法では、欠けている契約がなぜこのタスクに属するのかを説明してください。裏付けのない子要素側の仕組みを取り除けば問題もなくなる場合は、その仕組みの完成ではなく、削除または人間による判断を求めてください。固定された Outcome がなお動作の一部を要求する場合は、その部分だけを切り分けて解消してください。既存の担当者やパスがあれば、平易な文章で明記してください。タスクの権限が欠けている、または矛盾している場合は、レビュアーの解釈を強めるのではなく、人間への質問としてください。

解消方法が固定された担当範囲の Outcome または既存の担当者／パスの範囲内にとどまる場合に限り、Next: to-spec を返してください。隣接する Outcome、新たな永続的担当者、またはロックの拡大が必要な場合は、Question: を1つと Next: wait for answer を返してください。

レビューの根拠

1. 現在の正確な仕様書と、それを直接拘束する成果物を特定し、読み直してください。パスと内容／リビジョンの識別情報を記録してください。Git の成果物については、ステージ済みの内容とワークツリーの内容が異なる場合、それぞれを区別してください。Git の識別情報を確認できない場合は、1回試した後にその制限を記録してください。同等のコマンドを再試行しないでください。
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>

シードインベントリにないリポジトリパスを開いてよいのは、現在の台帳または受け入れ条件の主張を判断するために直接必要な、根拠を担う依存関係である場合に限ります。リポジトリを際限なく走査しないでください。そのようなパスごとに、リポジトリ相対パス、レビュー時点の完全な Git blob ハッシュ、および理由を Evidence addition: 行としてレポートに記録してください。

レビューの完全性

各レビューで、報告前に該当するすべてのノード、エッジ、台帳行、受け入れパス、および発生条件を満たした逆方向のパスを確認してください。最初の Blocker が見つかっても、そこで終了してはなりません。現時点で検出可能な、互いに異なるすべての Blocker の種類を1回にまとめて返してください。

契約台帳

独立して所有される各作業パッケージに非公開ノードを作成し、プロデューサーとコンシューマー間、または権限の引き継ぎごとに有向エッジを作成します。該当するすべてのノードとエッジについて、次の項目を確認します。

項目	必須の契約
担当者と成果	エントリーポイント、担当者、依存関係、構築、トランザクション／ライフサイクルの担当者、約束する成果
入力と権限	形式、事前条件、コンテキスト、入力または事実が食い違う場合の正規ソース
公開契約とアイデンティティ	タスク間で共有する型、作成権限、状態、ペイロード、等価性とアイデンティティの意味
結果	成功、何もしない場合、再実行、拒否、競合、データの欠落／不正形式、失敗、ロールバック、再試行と上限到達
状態と効果	実行前／実行後の状態、正確なレコード、永続化、副作用、順序、互換性、有効化と復旧
検証	受け入れ基準、観測ポイント、選択肢を区別する反例、テストオラクル

該当する各項目について、成果物が一貫した契約を選んでいるか、残る選択肢が動作上同等なローカルの裁量か、未知の事項が明示的に担当され範囲が定められているか、あるいは実装時に欠落した境界契約を選ばなければならないかを内部で判断します。最後の場合のみが Blocker です。これらをステータスラベルとして出力しないでください。

エンドポイントやハッピーパスが示されているだけで、ノード全体が完了したと見なさないでください。担当者、エントリー、観測可能な失敗経路が明記されていれば、既存の担当者／経路として十分です。このタスクでは、その担当者の内部状態機械まで指定する必要はありません。

条件付きの深さ

台帳によって該当するゲートのみを適用します。仕様が公開型／アイデンティティ、複数コンポーネントの構築／所有権、または永続／同時実行の境界をまたぐ場合は、 references/structural-gates.mdを読み、該当するセクションを適用してください。単一ノードのローカルな変更で、データベース、ロールアウト、同時実行、公開 API に関する問いに答える必要はありません。

依存関係の順に作業パッケージをたどります。欠落した判断ごとに、依存するすべてのプロデューサー、コンシューマー、状態、エラー、テスト、下流タスクをたどります。現れ方が複数ある場合は、最も早い正規契約の欠落の下にまとめます。選択肢が互いに独立して変わり得る場合のみ、指摘事項を分けます。同じ正規契約の欠落に起因する競合結果、受け入れの不足、下流コンシューマーへの影響は、その Blocker の判断範囲にとどめ、別の Blocker として出力しないでください。

各受け入れ基準と最終的な変更を、次の順に逆方向へたどります。

結果 -> 変更 -> 検証／スナップショット -> 観測 -> ソース／アイデンティティ

必要なすべての段階が存在し、結び付けられたアイデンティティと権限が維持され、観測可能な反例があることを確認します。各受け入れアサーションでは、競合する契約を区別できる反例を観測する必要があります。テストスイートが成功しても、ハッピーパスのサンプルでも、アサーションされた内容しか証明されません。すべてのノード、エッジ、該当する項目、受け入れ経路、適用される逆方向の経路を確認するまで終了しないでください。レビューの範囲は適切に保ってください。

判定と出力

表示する成果物の先頭文字から出力を開始し、最初の行には READY または NOT READY のみを記載してください。READY とするには、Blocker がゼロであり、 明示的な担当者がいて範囲が限定された既知の未知事項のみが残っている必要があります。 「注意事項付きで準備完了」とは決して記載しないでください。 レポートをタイトル、承認カード、外側のコードフェンスで囲まないでください。

次に Basis の行を1行記載します（形式の例です。事実に即して READY を使用してください）。

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

以下に定義するフィールドのみを報告してください。タスク、レビュー方法、 対象範囲の確認プロセス、過去の説明を繰り返さないでください。

READY は判定だけでは不十分です。Basis の後に、対象となる契約／コンシューマーの 範囲、該当する場合は実装上の重要な自由度、既存の担当者／パス、未発動の構造的 ゲートが追加の義務を生じさせない理由を示す、簡潔な Ready evidence: 行を1行記載してください。

再レビューでは、現在の指摘事項の前に、判断に関係する過去の行のみを簡潔に記載してください。

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

Codex アダプターモードでは、シードインベントリを超えて開いた直接パスごとに 1行追加してください。

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: を1つ記載し、Next: wait for answer で締めくくってください。 根拠に裏付けられた選択肢とその結果を説明してください。固定の選択肢一覧にしてはいけません。 原因の再発、不完全な修正、過去の NOT READY を、決定権限に関する質問にすり替えないでください。

複数の契約が要件を満たす場合は、アーキテクチャを指定しないでください。 計画の正しさは adversarial-spec-review に、ランタイム／PR の正しさは対応する レビュースキルに回してください。