validate-api

受け入れテスト — API

実際のクライアントと同じ方法で、起動中のサーバーをテストします。ユニットテストが通っても、それはコード独自の前提に対して通ったにすぎません。ここで確認するのは、ステータスコード、JSON の形式、再読み込み後も残る副作用など、実際の通信上の動作です。

validate-feature により受け入れテスト台帳の一部が渡されて実行されるか、API の変更に対して直接実行されます。直接実行する場合は、まず変更の受け入れ基準（仕様、または変更対象のエンドポイント）からチェックリストを作成してください。どちらの場合も、項目を順に進めます。

1. サーバーを起動する — 起動方法も記録する

docs/agents/project.md を読み、Run locally (dev) の項目を確認します。項目がある場合は、そのコマンドでバックエンドを起動します。ない場合は、リポジトリを調べてコマンドを特定します（Cargo のバイナリ／tauri／package.json のスクリプト／Makefile）。サーバーを起動し、応答することを確認します（ヘルスチェック用ルート、または最初のチェックリスト項目のリクエストに何らかの応答が返ること）。その後、起動コマンドと起動完了を示す応答を project.md の ## Run locally (dev) の下に記録します。完了条件：サーバーがリクエストに応答し、起動コマンドが project.md に記録されていること。

前提条件 — 認証、データ、環境。 エンドポイントで認証（トークン、シード済みテストアカウント）、フィクスチャ／シードデータ、または環境設定（環境変数、テスト用データベース）が必要な場合は、リポジトリでの提供方法を調べ、起動コマンドとともに project.md に記録します。401 や空のデータベースで止まる受け入れテストは、機能ではなくテスト環境を検証しているだけです。前提条件を解決して記録し、検証不能として扱わないでください。

API 標準ドキュメント（任意）

適用対象： チェックリストの項目が HTTP／RPC API である場合。読み込み： skills/project/define-system-doc/consult-recipe.md。パス： docs/standards/api.md。 承認済みの場合は参照します。存在しない場合は何もしません。不足が重要な場合は /define-system-doc standards/api を一度だけ提案します。自動では呼び出さないでください。

2. 各チェックリスト項目を実際のリクエストにする

台帳の API 項目ごとに、クライアントが送信する具体的なリクエスト（メソッド、パス、ヘッダー、本文）と、期待するレスポンス（ステータス、本文のフィールド名と大文字・小文字の区別、ID の型）、および副作用を記述します。エッジ条件も明示的に網羅します。空欄／空白のみのフィールドではドキュメントに記載されたエラー、存在しない ID ではドキュメントに記載されたステータス、不正な形式の本文、繰り返し呼び出しなどを確認します。

3. 起動中のサーバーに対して実行する

各リクエストを送信し（curl／http／スクリプト）、2xx かどうかだけでなく期待事項をすべて検証します。ステータス、本文の形式に加え、基準に「永続化」とある場合は新しい GET で読み戻し、「再起動後も」とある場合はサーバーを再起動してから再度読み戻します。各項目について、実際の結果と期待値を台帳に記録します。 完了条件：すべての API 項目で結果が確認されていること。

4. 失敗した箇所を修正する

必須のサブスキル：root-cause を使用します。失敗したリクエストによって、すでに修正と再実行を繰り返すためのループができています。根本原因を修正し、回帰テストを追加して、該当項目を再実行します。

5. 長期的に使えるテストにする

実行したリクエストを、サーバー（または実際の接続点にあるハンドラー）に対して実行するコミット済みテストにします。docs/agents/project.md の規約に従って要件 ID をタグ付けし、検証スイートに加えて、この実行後も動作を保証できるようにします。完了条件：永続的なテストがコミットされ、タグ付けされ、成功していること。