f1-test-drive

F1 テストドライブ

適用可否（セットアップ前に必須）

これは F1 の正式な適用ポリシーです。F1 を開始したり、フィクスチャを選択したり、レポートを作成したりする前に、PR のベースとの差分を実際に確認し、検証が必要な動作を特定してください。タスクの規模、Issue のラベル、ファイル名、「確認してリリースしてほしい」といった一般的な依頼は、F1 を実行する十分な理由にはなりません。

• 必須： F1 で検証できる製品／ランタイムの変更（Issue の追跡、認証、ルーティング、ランナー／セッションのライフサイクル、アクティビティのレンダリング）と、F1 ハーネス自体の機能変更です。変更された動作を検証できるアサーションを含むシナリオを選択してください。一般的なヘルスチェックや無関係なフィクスチャでは、正しさを確認できません。
• 適用対象外： ドキュメント、エージェントへの指示、CI／リリースのツール、インストーラー／ビルド／パッケージングのメタデータ、その他関連する製品ワークフローの動作に影響しない変更です。代わりに、適切なドキュメント、スクリプト、単体、統合、ビルド、パッケージの検査、または隔離インストールのスモークテストを実施してください。F1 を実行したり、F1 テストドライブのレポートを作成、添付、コミットしたりしないでください。F1 が適用対象外である理由と、合格したチェックを簡潔に PR に記載すれば十分です。
• 混在する変更： 関連する機能部分のみを F1 で検証し、その他の部分は対象に応じたチェックで検証してください。実際のランタイム動作の変更（依存関係、生成されるプロンプト、インストール時のデフォルト値を含む）について、ドキュメント、インフラ、メタデータに関する変更があることを理由に適用除外にはできません。
• 実際のリリース： バージョン番号を変更する PR だけでなく、前回のリリースと比較して、リリースされるペイロード全体を評価してください。ランタイムを含むペイロードでは、関連する F1 検証を引き続き実施してください。F1 で検証できる動作に変更のないペイロードでは、apps/cli/RELEASING.md に記載された非 F1 のリリース検証を使用してください。リリースツールの編集は、それ自体では機能的なリリースの準備や公開には当たりません。

F1 が適用対象外の場合は、セットアップとレポート作成に進まず、この手順を終了してください。適用対象であってもブロックされている場合は、不足しているカバレッジと阻害要因を正直に報告してください。適用対象外として扱い直したり、無関係なテストドライブの合格結果で代用したりしないでください。過去のレポートは保持してください。

実際の変更	検証方法
別個のエージェント ID 機能を含まない、PR #1502 のアーティファクトワークフローと隔離インストーラーツール	ワークフロー／スクリプトのテスト、バンドルの整合性、隔離インストール、CLI のスモークテストを実施します。無関係な ID 用の F1 フィクスチャやレポートは使用しません。
README の表現や CYPACK-1537 のような指示のみのポリシー	整合性、リンク、ポリシーの例をレビューします。F1 レポートは作成しません。リリース検証ツールの編集では、影響に見合った検証を行い、重大な証拠受け入れ失敗に対するテストは維持します。
ドキュメントを伴うランタイムのルーティング修正	変更されたルーティングをアサートする F1 シナリオを実施し、残りはドキュメントのチェックで検証します。
EdgeWorker の認証、ルーティング、またはセッションのライフサイクル	変更内容に応じて、ID の分離、選択されたリポジトリ、またはセッションの継続／終了をアサートする関連 F1 シナリオを実施します。
F1 の RPC コマンド、フィクスチャの実行、またはアクティビティレンダラーの動作	変更されたハーネスの経路をエンドツーエンドで検証し、単体／統合テストも実施します。F1 のドキュメントのみを編集する場合は、ドキュメントのチェックを行います。
バージョン番号のみを変更し、未リリースのセッション修正を含むリリース PR	前回のリリース以降を評価し、関連するセッションの F1 検証を実施します。
関連するワークフロー動作の変更を含まず、インフラ／ドキュメントのみをリリース	ペイロードの評価と対象に応じたチェックを、非 F1 のリリース検証として記録します。形式的な F1 レポートは作成しません。

目的（適用対象の場合）

関連する Issue トラッカー、EdgeWorker、アクティビティ出力の各経路を通じて、変更されたワークフローを検証します。セットアップを始める前に、シナリオ、期待される動作、アサーションを明記してください。以下のフェーズは構成要素として使用し、そのシナリオに必要な経路のみを、セットアップとクリーンアップに加えて含めてください。

テストドライブの手順

フェーズ 1：セットアップ

1. 新しいテストリポジトリを作成します（必要な場合）：

   cd apps/f1
   ./f1 init-test-repo --path /tmp/f1-test-drive-<timestamp>
   

2. F1 サーバーを起動します：

   CYRUS_PORT=3600 CYRUS_REPO_PATH=/tmp/f1-test-drive-<timestamp> bun run apps/f1/server.ts &
   

3. サーバーのヘルスを確認します：

   CYRUS_PORT=3600 ./f1 ping
   CYRUS_PORT=3600 ./f1 status
   

フェーズ 2：課題トラッカーの検証

1. テスト課題を作成します：

   CYRUS_PORT=3600 ./f1 create-issue \
     --title "<issue title>" \
     --description "<issue description>"
   

2. 課題 ID と課題作成時の応答を確認します。

フェーズ 3：EdgeWorker の検証

1. エージェントのセッションを開始します：

   CYRUS_PORT=3600 ./f1 start-session --issue-id <issue-id>
   

2. アクティビティを監視します：

   CYRUS_PORT=3600 ./f1 view-session --session-id <session-id>
   

3. 次の点を確認します：

   • セッションが開始されている
   • アクティビティが表示される
   • エージェントが課題を処理している

フェーズ 3.5：Slack チャットセッションの検証（任意）

Slack → ChatSessionHandler → ClaudeRunner の経路を検証する場合に使用します。F1 では、Slack の署名検証を経由せずに合成 app_mention イベントを注入するテスト専用エンドポイント /cli/dispatch-chat を公開します（slackBotToken が未定義の場合、SlackChatAdapter は Slack API 呼び出しを何もしません）。

1. 合成チャットイベントを送信します：

   CYRUS_PORT=3600 ./f1 start-chat-session \
     --channel C_TEST_CHAN \
     --user U_TEST_USER \
     --text "hello"
   

   応答には <channel>:<ts> 形式の threadKey が含まれます。後続の送信で同じチャットスレッドを指定するには、同じ --thread-ts を再利用します。

2. 共有自動メモリの接続を確認します：

   • チャットのワークスペースが <cyrusHome>/slack-workspaces/<sanitized-threadKey>/ に存在します。
   • 共有自動メモリディレクトリが <cyrusHome>/slack-memory/ に存在するか、遅延作成できる状態です。
   • ClaudeRunner が発行する claude_query_options イベントに、cqo.settingsAutoMemoryDirectory=<cyrusHome>/slack-memory が含まれています。

3. 共有メモリと併せてスレッドごとのワークスペース分離を確認します：

   • 別のチャンネル／スレッドで 2 つ目のイベントを送信します。
   • 別個の slack-workspaces/<other-thread-key>/ ディレクトリが存在することを確認します（ワークスペースは分離されたままです）。
   • 両方の送信のテレメトリが同じ slack-memory パスを解決することを確認します（メモリは共有されます）。

フェーズ 4：レンダラーの検証

1. アクティビティペイロードの品質を検証します：

   • 想定される種類（例：thought、action、response）
   • タイムスタンプが存在する
   • 内容が適切な形式で、読みやすい

2. ページネーションの動作を検証します：

   CYRUS_PORT=3600 ./f1 view-session --session-id <session-id> --limit 10 --offset 0
   

フェーズ 5：クリーンアップ

1. アクティブなセッションを停止します：

   CYRUS_PORT=3600 ./f1 stop-session --session-id <session-id>
   

2. バックグラウンドのサーバープロセスを停止します。

レポート形式

該当する F1 ドライブを実施した場合に限り、apps/f1/test-drives/ の下にレポートを作成します。 テストしたコミット、変更された動作、コマンド、アサーション、結果、 制約事項を記録します。該当するシナリオに合わせてこのテンプレートを調整し、関係のない チェックリストは省略します。プレースホルダーや「該当なし」の F1 レポートは決して作成しないでください：

# Test Drive #NNN: [Goal Description]

**Date**: YYYY-MM-DD
**Goal**: [One sentence]
**Test Repo**: [Path]

## Verification Results

### Issue-Tracker
- [ ] Issue created
- [ ] Issue ID returned
- [ ] Issue metadata accessible

### EdgeWorker
- [ ] Session started
- [ ] Worktree created (if applicable)
- [ ] Activities tracked
- [ ] Agent processed issue

### Renderer
- [ ] Activity format correct
- [ ] Pagination works
- [ ] Search works

## Session Log
[commands + key outputs + pass/fail]

## Final Retrospective
[what worked, issues, recommendations]

合格／不合格の基準

変更された動作に関するアサーションと、該当する以下のワークフローチェックに合格した場合にのみ合格とします：

1. サーバーが起動する
2. 課題が正常に作成される
3. セッションが開始され、アクティビティが表示される
4. アクティビティペイロードに一貫性がある
5. セッションが正常に停止する
6. 未処理のエラーがない

次の場合は不合格です：

• サーバーの起動に失敗する
• 課題の作成に失敗する
• セッションが開始されない
• 妥当な時間待ってもアクティビティがない
• アクティビティデータの形式が不正である
• 未処理の例外が発生する

重要な注意事項

• 使用中でない限り、固定ポート 3600 を優先します。
• ドライブごとに新しいテストリポジトリを使用します。
• デバッグ時は失敗した状態を保持します。
• 機能ランナー／ハーネスに変更を加えた場合は、上記の適用性ポリシーで求められているとおり、マージ前に影響を受ける経路をエンドツーエンドで検証します。

複数ハーネスに関する注意

このスキルは、意図的に特定のハーネスに依存しないようにしています：

• Claude のサブエージェントはこのスキルを呼び出せます。
• Codex／OpenCode のワークフローは、同じスキルの内容を参照できます。
• ハーネス固有のアダプターは、この標準スキルを薄くラップするものにしてください。