acceptance-api

受け入れテスト — API

実際のクライアントと同じ方法で、起動中のサーバーをテストします。ユニットテストはコード自体の前提に基づいて成功しますが、こちらではステータスコード、JSON の形式、再読み込み後も維持される副作用といった、通信上の動作を検証します。

acceptance-check から受け入れ項目の一部を受け取って実行します。または、API の変更に対して直接実行する場合は、まず変更の受け入れ条件（仕様、または変更対象のエンドポイント）からチェックリストを作成します。いずれの場合も、項目を順番に進めてください。

1. サーバーを起動し、起動方法を記録する

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

前提条件 — 認証、データ、環境。 エンドポイントに認証（トークン、シード済みテストアカウント）、フィクスチャ／シードデータ、または環境設定（環境変数、テスト用データベース）が必要な場合は、リポジトリでの提供方法を確認し、起動コマンドと併せて project.md に記録します。401 や空のデータベースで行き詰まる受け入れテストは、機能ではなくテストハーネスを検証していることになります。項目を検証不能とせず、前提条件を整えて記録してください。

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

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

3. 起動中のサーバーに対してテストする

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

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

必須のサブスキル：debug を使用します。失敗したリクエストは、すでにレッド状態にできるループになっています。根本原因を修正し、回帰テストを追加して、該当項目を再実行します。

5. 永続的なテストにする

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