sdlc-verify

sdlc-verify

すべてのインテントにおいて、sdlc-apply の後に実行するのがデフォルトです。自分の作業を確認する実装担当者は評価が甘くなり、新しい読者なら気づく点を見落とします。ユーザーはインテント単位または実行単位で省略できます。それ以外の場合、apply から直接 close に進んではいけません。

レビュー担当者は、実装の会話を見ていてはいけません。新しいサブエージェント（同じモデルでもかまいません）か、独立した新しいセッションを使用してください。役割名やデフォルトのディスパッチだけでは独立性の証明にならないため、必ず確認してください。実装担当者が自分の作業を承認することはできません。レビュー担当者は report.md 以外を編集してはいけません。独立したレビュー経路がない場合、tier critical では blocked レポートを作成し、tier change では ## Result に「独立したレビューを実施していません」と記載して、受け入れるかどうかをユーザーに判断してもらいます。

tier change は簡易レビューです。受け入れ項目、diff、および影響を受けるチェックのみを確認します。tier critical では、以下の Spec、マイグレーション、障害経路のチェックも追加します。

引き継ぎ

レビュー担当者に渡すのは、リポジトリのパス、slug、コミット済みの候補（reviewed_head）、intent.md に記載された base、intent.md のパス、およびユーザーが判断を示した依頼文のみです。実施した内容やその理由の要約は渡さないでください。

レビュー担当者が行うこと

1. スナップショットを確認します。HEAD が reviewed_head と一致していること、未コミットの変更がdiff内のファイルに影響していないこと（他の人による無関係な未コミットファイルは無視します）、手順にチェックが付いていること、## Result が記入されていることを確認します。そうでない場合は blocked とします。
2. ユーザーの依頼文、インテント、diffを双方向で比較します。依頼された結果がすべて実際に提供されていること（手動での代替手段やテストダブルではないこと）、またユーザーが依頼していないものが追加されていないことを確認します。
3. base..reviewed_head のdiff全体を読みます。ロジック、信頼境界、エラー処理、変更された共有契約を使用する呼び出し元へのリグレッション、既存パターンとの整合性を確認します。
4. 影響を受けるチェックを自分で実行します。以前の結果を再利用できるのは、出力の生データとコードを確認し、コード、設定、コマンドが一致する場合のみです。主張をうのみにしてはいけません。
5. すべての Acceptance 項目を実際に確認します。UIでは、実行中のローカルアプリでメイン経路とエラー経路を操作します。パイプラインでは、保存値だけでなく、利用側または送信リクエストを確認します。状態を持つフローでは、障害とリトライ後の永続化された状態を確認します。マイグレーションでは、破棄可能なデータベース上で適用済みの履歴からアップグレードし、データが保持されることを確認します。
6. 本番環境や共有のデフォルトデータベースには絶対に触れないでください。tier critical の場合、または無関係なファイルに未コミットの変更がある場合は、reviewed_head の切り離されたチェックアウトでチェックを実行します（git worktree add --detach <tmp> <reviewed_head>）。終了後に削除します。
7. 最初の CRITICAL が見つかった時点で停止します。保存された生の出力で既に証明されている内容を再実行してはいけません。

検証の範囲は、この変更と実際に影響する範囲に限定してください。無関係な機能の操作を再現したり、製品全体を再認定したりしてはいけません。

レポート

intent/<slug>/report.md を作成します。40行以内にしてください。

---
slug: example-slug
reviewed_head: <full commit hash>
verdict: pass   # pass | fail | blocked
---

# Report: short name

## Checked
- PASS | <acceptance item or requirement> | <command or action> | <what was observed, evidence path>

## Findings
None. Or: - CRITICAL | WARNING | SUGGESTION: <file:line> what, and what evidence would settle it.

## Not checked
None. Or what and why. For `blocked`: Reason and Recovery lines instead.

pass とするには、すべての Acceptance 項目について証拠があり、候補がコミット済みで、CRITICAL の指摘がないことが必要です。レポートはコミットせずに残してください。close のコミットでレポートは不要です（フォルダーが削除されるため）。その前にレポートを読んでください。reviewed_head 以降にレビュー対象のファイルが変更された場合、レポートは古くなるため、新たにレビューする必要があります。fail の後の修正は sdlc-apply で行います。新しいレビュー担当者は指摘事項と修正のコミットを確認し、変更全体を再レビューする必要はありません。2回目の fail でループを停止し、対象を絞った再現手順とともにユーザーへ報告してください。