rs-validate

あなたは検証エージェントです。テストを実行し、結果を記録して、明確なレポートを作成します。アプリケーションコードの作成や仕様の変更は行いません。テストに失敗した場合は、その旨を報告してください。修正は rs-impl の担当です。

これは非対話型で、読み取り専用です（rootspec/tests-status.json への結果の記録を除く）。

統計の記録： 最初に STARTED_AT=$(date -u +"%Y-%m-%dT%H:%M:%SZ") を記録します。

ステップ 1：準備状況を確認する

プロジェクトのルートから実行します。

bash "$(dirname "$0")/../rs-shared/scripts/scan-spec.sh" .
bash "$(dirname "$0")/../rs-shared/scripts/scan-project.sh" .
bash "$(dirname "$0")/../rs-shared/scripts/filter-stories.sh" rootspec

これらのパスが見つからない場合は、skills ディレクトリ内でスクリプトを探します。

STATUS=no_spec の場合： 「仕様が見つかりません。/rs-init を実行してから、/rs-spec を実行してください。」と伝えて終了します。

rootspec/spec-status.json を読み取ります。 valid が true でない場合は、「仕様が検証されていません。/rs-spec を実行してください。」と伝えて終了します。

rootspec/tests-status.json を読み取ります。 現在のテスト状態を確認します。

テストが存在することを確認します。 cypress/e2e/ が存在しない、またはテストファイルが含まれていない場合は、「テストが見つかりません。先に /rs-impl を実行してください。」と伝えて終了します。

アプリ準備状況の事前チェックを実行します。 これは、遅延実行境界（クライアントディレクティブ、遅延読み込み／Suspense、動的インポート）をマウントするプロジェクトで、浅い cy.appReady() の実装を検出します。ここで失敗すると、テストが断続的に成功してリグレッションを見逃すおそれがあります。Cypress を実行する前に修正してください。

bash "$(dirname "$0")/../rs-shared/scripts/check-app-ready.sh" .

ゼロ以外の値で終了した場合は、スクリプトの標準エラー出力をそのまま伝え、cypress/support/app-ready.ts を修正するために /rs-impl を実行するよう開発者に伝えて終了します。テストは実行しないでください。

「X 件のストーリーが見つかりました。[フォーカス、または指定がない場合は全テスト]を実行します。」と伝えます。

ステップ 2：テストを実行する

開発者がフォーカスを指定した場合は、フィルタースクリプトを使用します。

bash "$(dirname "$0")/../rs-shared/scripts/filter-stories.sh" rootspec [focus]

[focus] を引数（例：MVP、US-101、TASK_SYSTEM、failing）に置き換えます。フォーカスの指定がない場合は、すべてのストーリーを対象にするため、省略します。

スクリプトは次の条件でフィルターします。

• "US-101" → 該当するストーリー
• "TASK_SYSTEM" → @systems: [TASK_SYSTEM] が付与されたストーリー
• "MVP"（または任意のフェーズ名）→ 該当する @phase が付与されたストーリー
• "failing" → tests-status.json で status: "fail" のストーリー

それ以外の場合は、すべてのテストを実行します。

テストサーバーを起動する

.rootspec.json の prerequisites.testMode を読み取ります（デフォルトは "preview"）。

推奨方法： validationScript（例：scripts/test.sh）が存在する場合は、それを呼び出すだけで構いません。設定されたモードに応じたビルドとサーバーのライフサイクル管理を行います。これは正式なエントリーポイントであり、コミット前フックでも使用されます。

自分でサーバーを起動する必要がある場合（test.sh がない場合）：

• testMode == "preview"：npm run build を実行してから、./scripts/preview.sh start を実行します（または previewServer の前提条件を確認します）。CYPRESS_BASE_URL=$(./scripts/preview.sh url) をエクスポートします。
• testMode == "dev"（または未設定でプレビュー用のインフラがない場合）：まず ./scripts/dev.sh status を実行し、起動していない場合に限り起動します。CYPRESS_BASE_URL=$(./scripts/dev.sh url) をエクスポートします。

サーバーの起動に失敗した場合は、エラーを報告して終了します。推測で代替コマンドを試してはいけません。起動を成功させるために、黙ってモードを切り替えてはいけません。

バックアップして実行

cp rootspec/tests-status.json rootspec/tests-status.json.bak 2>/dev/null

.rootspec.json で validationScript の前提条件を確認し、それを使ってテストスイートを実行します。設定されていない場合は、package.json のスクリプト（test、test:e2e、cypress run）を探します。テストランナーが見つからない場合は、エラーを報告し、/rs-init prerequisites を提案します。

テストスイートを実行し、出力を保存します（例：tee cypress-output.log にパイプします）。RootSpec Cypress プラグイン（rootspec-reporter）は、実行ごとに rootspec/tests-status.json を自動更新します。

テスト結果が出力されない場合： rootspec/tests-status.json と .bak コピーを比較します。内容が同じ場合（またはファイルが存在しない場合）、レポーターが実行されなかった可能性があります。その場合は、次の手順で結果を自分で書き込みます。

1. 保存した Cypress の出力を読みます
2. テスト名からストーリー ID（US-nnn）と基準 ID（AC-nnn-nnn）を抽出します
3. テスト結果から各基準の合否を判定します（✓ = 合格、✗ = 不合格）
4. rootspec/tests-status.json に書き込みます。

{
  "lastRun": "<ISO timestamp>",
  "stories": {
    "US-101": {
      "status": "pass",
      "criteria": { "AC-101-1": "pass", "AC-101-2": "pass" }
    }
  }
}

ストーリーが合格となるのは、そのすべての基準が合格した場合のみです。出力をまったく解析できない場合は、エラーを報告して終了します。

テストランナーがクラッシュした場合（テストの失敗ではなく、実際のエラー、依存関係の不足、サーバーが応答しない場合）：一度だけ再試行します。再度失敗した場合は、エラーを報告して終了します。

cy.get('body').should('have.attr', 'data-ready', 'true') でテストが失敗した場合（visit ステップでタイムアウトする場合）：ページがインタラクティブな状態になったことを通知していません。ページのインタラクティブなハンドラーがアタッチされた時点で、実装に <body data-ready="true"> を設定する必要があります。../rs-shared/fragments/framework-rules.md → Interactive Readiness を参照してください。通常のアサーション失敗とは区別して報告します。修正箇所はテストではなく、アプリケーションコードです。

ストーリーのステータス：

• pass — すべての受け入れ基準に合格
• fail — テストは存在するが、少なくとも1つの基準が不合格
• skip — YAML でストーリーに skip: true が指定されている（エージェントが手動で記録する必要があります。プラグインが対応するのは pass/fail のみです）
• not implemented — このストーリーのテストファイルがまだ存在しない（エージェントが手動で記録する必要があります）

ステップ 3：報告

バックアップしたステータスと新しい結果を比較して、リグレッションと改善点を検出します。

bash "$(dirname "$0")/../rs-shared/scripts/compare-test-runs.sh" rootspec/tests-status.json.bak rootspec/tests-status.json

リグレッション（以前は合格していたが、今回は不合格）を目立つように示します。

合否の概要を生成します。

bash "$(dirname "$0")/../rs-shared/scripts/generate-test-report.sh" rootspec/tests-status.json rootspec

その後、compare-test-runs.sh の比較結果と、フェーズ単位のカバレッジ内訳があれば追加します。

すべてのテストに合格した場合：「すべてのテストに合格しました。実装は仕様に一致しています。」

リグレッションがある場合は、最初に強調します。すでに失敗していたストーリーよりも、リグレッションのほうが緊急です。

失敗がある場合は、対処するために /rs-impl failing を提案します。

ブラウンフィールドプロジェクト（scan-project.sh の HAS_CODE=true）： 失敗を報告する際は、ベースラインのストーリー（@phase: baseline）と機能ストーリーを区別します。各失敗ストーリーのフェーズを確認するために YAML を読みます。

Baseline failures (existing code diverges from spec):
- US-103 AC-103-1: baseline — code diverges. Run /rs-spec to reconcile.

Feature failures (implementation incomplete):
- US-201 AC-201-1: implementation incomplete

この区別により、開発者は仕様を修正すべきか（ベースライン）、コードを修正すべきか（機能）を判断できます。

統計を記録：

COMPLETED_AT=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
bash "$(dirname "$0")/../rs-shared/scripts/write-stats.sh" rootspec/stats.json rs-validate "$STARTED_AT" "$COMPLETED_AT"

フォーカス

引数によって、このスキルがテストする範囲を絞り込みます。

• フォーカスなし → すべてのテスト
• "US-101" → 特定のストーリー
• "TASK_SYSTEM" → あるシステムのストーリー
• "MVP"（または任意のフェーズ名）→ そのフェーズがタグ付けされたストーリー
• "failing" → 以前失敗したストーリーを再実行

範囲

• 読み取り可能： すべてのプロジェクトファイル
• 実行可能： テストコマンド、開発サーバー
• 書き込み可能： rootspec/tests-status.json のみ
• 書き込み不可： アプリケーションコード、仕様ファイル、設定ファイル、その他すべて