ai-test-process-mcp: Instructions file for Codex

ai-test-process-mcp

AIによるテストプロセス支援MCPサーバー。Phase 1 はテスト計画書のドラフト生成・レビュー・修正と、Test Design 技法エンジン。TypeScript + @modelcontextprotocol/sdk。

必須ルール

• 自明な修正（typo・1〜2行・設定値変更）はmainが直接対応する。不具合修正は原因が自明な場合（例：直前のコミットで壊したことが明らか）のみ自明扱い。原因調査が必要な場合は非自明として即 planner を起動する。
• 非自明なタスク（新しいresource/toolの追加、既存ロジックの変更など）はmainが調査せず、planner に調査・仕様策定・引き渡し票生成を依頼する。
• mainはplanner票を編集・要約せず実装担当へ渡す。デフォルトは feature-dev、ユーザーが明示した場合だけcodex exec --sandbox workspace-write を使う。
• planner・feature-devはエージェント定義上model: inheritのため、Agent起動時にmodelパラメータを明示しない限りmain自身のモデルをそのまま継承する。mainはタスクの複雑さ・調査範囲の広さに応じて、単純な調査や小規模な実装にはSonnet、複雑な設計判断や広い調査が必要なタスクにはOpusというように、起動のたびにmodelを明示指定し、トークン効率が良くなるよう調整する。acceptance-testは機械的なテスト実行のみのためmodel: haiku固定のまま変更しない。
• codexを使う場合、planner→実装担当（feature-dev相当）の引き継ぎはcodex内部の自動委譲に任せず、mainが必ず仲介する。plannerのcodex exec実行が完了したら一度プロセスを終了させ、その出力（票）を使ってmainが改めてトップレベルのcodex execを起動する。理由: サンドボックス内部からの自己再帰呼び出し（自分自身をサブプロセスとして再起動）はPATHが制限されnpmのグローバルbinを含まないため、内部委譲に任せるとcodexコマンド未検出で失敗することがある。
• codexを使う場合、codex execが失敗したら原因により対応を分ける。
  • タイムアウトによる失敗: リトライ前にgit status -sbとgit diff --statで変更が既に反映されていないか確認する。反映済みなら再実行しない。未反映なら、より長いタイムアウトで再実行してよい。
  • タイムアウト以外の失敗（コマンド未検出・権限エラー等）: 停止してユーザーに報告する。自動でfeature-dev実装へ切り替えない。
• Codexは並列起動しない。
• 受け入れテストは明示指示時のみ acceptance-test を使い、planner票をそのまま渡す。
• テストFAILが実装バグなら報告を添えて実装担当（feature-dev、または明示指定時はCodex）へ戻し、設計・仕様の問題だけplannerへ戻す。
• 新しいresource/toolを追加する際は、src/resources/<name>.ts + src/tools/<name>.ts を新設し、それぞれの index.ts に1行登録を足すパターンに従う（server.ts 本体は変更しない）。プラグインローダーやレジストリのような抽象化は追加しない。
• 新しい決定的検査を追加するときは、「宣言」と「実体」の照合を必ずセットで実装する。宣言されたIDやラベルの一致だけを見る検査は追加しない。網羅率・カバレッジ率のように「達成度」を数値で提示する検査は、その数値の根拠が成果物本文から裏付けられることまで検査する。
• JSTQB/実務ベースのテスト知識は src/resources/ 配下に構造化データとして保持し、原典の逐語転載はしない（著作権上、パラフレーズのみ）。
• ツールのレンダリングロジック（例: renderTestPlan()）はMCP登録から独立した純関数として実装し、test/ でvitestにより単体テストする。
• サブエージェント定義（.claude/agents/*.md, .codex/agents/*.toml）は同期成果物。直接編集せず、正本 C:\Claude Code\_agent-templates\*.md を編集して sync-agents.ps1 を実行する。