/direct-verify

description: DIRECTタスクで実行した設定作業の動作確認とテストを行います。設定が正しく適用され、システムが期待通りに動作することを確認します。
allowed-tools: Read, Glob, Grep, Task, Write, Edit, TodoWrite
argument-hint: "[要件名] [TASK-ID]"

direct-verify

目的

DIRECTタスクで実行した設定作業の動作確認とテストを行います。設定が正しく適用され、システムが期待通りに動作することを確認します。

前提条件

• `/tsumiki-legacy:direct-setup` が実行済み
• タスクIDが提供されている
• 設定作業の記録が存在する

実行内容

**【重要】**: direct-setupで作成されたファイルについて、コンパイルエラーや構文エラーが見つかった場合は自動的に解決を試行します。

1. 追加ルールの読み込み

• `docs/rule` ディレクトリが存在する場合は読み込み
• `docs/rule/direct` ディレクトリが存在する場合は読み込み
• `docs/rule/direct/verify` ディレクトリが存在する場合は読み込み
• 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用

2. 技術スタック定義の読み込み

• `docs/tech-stack.md` が存在する場合は読み込み
• 存在しない場合は `CLAUDE.md` から技術スタックセクションを読み込み
• どちらも存在しない場合は `.claude/commands/tech-stack.md` のデフォルト定義を使用

3. 設定の確認

• 読み込んだ技術スタック定義に基づいて検証項目を特定
• Task tool (subagent_type: Explore, thoroughness: quick) を使用して関連設定や検証パターンを探索
• `docs/implements/{要件名}/{TASK-ID}/setup-report.md` をReadツールで読み込み、設定作業の結果を確認
• 環境変数の確認
• 設定ファイルの内容確認
• 依存関係のインストール状況確認
• サービスの起動状況確認

4. コンパイル・構文確認

• TypeScript/JavaScript構文エラーチェック（該当する場合）
• 設定ファイルの構文確認（JSON, YAML等）
• SQL構文確認（該当する場合）
• 最低限のコンパイルエラー解消
• **エラーが見つかった場合は自動的に修正を試行**

5. 動作テストの実行

• Task tool (subagent_type: Explore, thoroughness: quick) を使用して既存のテストケースや検証スクリプトを探索
• 基本的な動作確認
• 接続テスト
• 権限の確認
• エラーケースの確認

6. 品質チェック

• セキュリティ設定の確認
• パフォーマンス基準の確認
• ログの確認

7. CLAUDE.mdへの記録

• サブプロジェクトの存在確認（`package.json`, `Cargo.toml`, `pyproject.toml`, `go.mod`等）
• 各サブプロジェクトまたはルートの `CLAUDE.md` の存在確認
• CLAUDE.mdに以下の情報が**最小限**記載されているか確認：
• テスト実行コマンド
• アプリケーション起動コマンド
• ビルドコマンド（該当する場合）
• データベース操作コマンド（該当する場合）
• 情報が不足している場合は「## 開発コマンド」セクションを追加/更新
• 既存の情報が古い場合は更新。ファイルがなければ必要に応じて新規作成

8. 検証レポートの作成

• `docs/implements/{要件名}/{TASK-ID}/verify-report.md` を作成
• 全ての確認結果を記録
• 発見された問題と解決内容を記載
• CLAUDE.mdへの記録内容を記載
• 推奨事項と次のステップを記載

9. タスクの完了マーキング

完了条件を全て満たす場合は、**自動的に**以下のファイルを更新：

完了条件

• 全ての設定確認項目がクリア
• コンパイル・構文チェックが成功（エラーがすべて解決済み）
• 全ての動作テストが成功
• 品質チェック項目が基準を満たしている
• 発見された問題が適切に対処されている
• セキュリティ設定が適切
• パフォーマンス基準を満たしている

更新対象ファイル

1. **Overview ファイル**: `docs/tasks/{要件名}/overview.md` または `docs/tasks/{要件名}-overview.md`

• 該当タスクの進捗状況を「完了」に更新
• 完了日を記録

2. **タスク詳細ファイル**: `docs/tasks/{要件名}/TASK-{task_id}.md` または `docs/tasks/{要件名}-tasks.md`

• ステータスを「✅ 完了」に更新
• 完了日を記録
• 完了条件のチェックボックスを全て `[x]` に変更

出力先

確認記録は `docs/implements/{要件名}/{TASK-ID}/` ディレクトリに以下のファイルとして作成されます：

• `verify-report.md`: 設定確認・動作テスト記録

CLAUDE.mdへの記録

動作確認で必要となった最小限の実行方法は、**必ずCLAUDE.mdに記録**してください：

記録すべき内容（最小限）

• **テストケースの実行方法**
• テストコマンド（例: `npm test`, `pytest`, `cargo test`）
• 特定のテストファイル/ディレクトリの実行方法
• テスト環境のセットアップ方法（必要な場合のみ）

• **アプリケーションの実行方法**
• 開発サーバーの起動コマンド（例: `npm run dev`, `python manage.py runserver`）
• ビルドコマンド（例: `npm run build`, `cargo build --release`）
• 本番環境での起動方法（該当する場合）

• **データベース関連**（該当する場合のみ）
• マイグレーション実行方法
• シードデータの投入方法

記録場所の判定ロジック

1. **サブプロジェクトの特定**

• `package.json`, `Cargo.toml`, `pyproject.toml`, `go.mod` などの存在で判定
• サブプロジェクトごとに独立したCLAUDE.mdを作成

2. **CLAUDE.mdの配置ルール**

• **サブプロジェクトが存在する場合**: 各サブプロジェクトのルートに `CLAUDE.md` を作成
• 例: `frontend/CLAUDE.md`, `backend/CLAUDE.md`
• **モノリポ構造の場合**: ルートの `CLAUDE.md` に全体像を記載し、各サブプロジェクトに詳細を記載
• **単一プロジェクトの場合**: ルートの `CLAUDE.md` にのみ記載

3. **既存のCLAUDE.mdが存在する場合**

• 既に必要な情報が記載されているかチェック
• 不足している情報のみ追記
• 情報が古い場合は更新

記録方法

各CLAUDE.mdに以下のセクションを追加または更新：

## 開発コマンド

### テスト実行
\`\`\`bash
# すべてのテストを実行
{テストコマンド}

# 特定のテストを実行
{特定テスト実行コマンド}
\`\`\`

### アプリケーション実行
\`\`\`bash
# 開発サーバー起動
{開発サーバー起動コマンド}

# ビルド
{ビルドコマンド}
\`\`\`

### データベース操作（該当する場合）
\`\`\`bash
# マイグレーション実行
{マイグレーションコマンド}

# シードデータ投入
{シードコマンド}
\`\`\`

記録の優先順位

1. **必須**: テスト実行方法、アプリケーション起動方法 2. **推奨**: ビルド方法、データベース操作（該当する場合） 3. **任意**: 詳細なトラブルシューティング（README.mdに記載）

README.mdへの記録

動作確認結果や運用に関する重要な情報は、**必ずREADME.mdにも記録**してください：

記録すべき内容

• 動作確認の手順とコマンド
• 各コンポーネントの正常動作の確認方法
• パフォーマンス基準値（起動時間、メモリ使用量等）
• 発見された問題と解決方法（トラブルシューティング）
• 推奨される運用設定
• セキュリティ関連の注意事項

記録方法

1. **動作確認セクション**に確認手順を追記

• 既存の「動作確認」セクションがあれば、そこに追記
• なければ新規作成

2. **トラブルシューティングセクション**に問題と解決方法を追記

• 発見された問題は必ず記録
• 解決コマンドは実行可能な形で記載

3. **プロジェクトステータスセクション**にタスク完了情報を更新

• タスク完了時は自動的に更新される

記録例

動作確認セクションへの追加

### {サービス名}の検証

\`\`\`bash
# {確認項目の説明}
{確認コマンド}
\`\`\`

**期待される結果**: {期待される出力や状態}

パフォーマンス基準の記録

### パフォーマンス基準

- 起動時間: {時間}秒以内
- メモリ使用量: {サイズ}MB以内
- レスポンスタイム: {時間}ms以内

トラブルシューティングセクションへの追加

### {問題の概要}

**症状**: {問題の詳細な説明}

\`\`\`bash
# 問題の確認
{確認コマンド}

# 解決方法
{解決コマンド}
\`\`\`

**原因**: {問題の原因}
**解決**: {解決の説明}

出力フォーマット例

<verify_report_format>

# {TASK-ID} 設定確認・動作テスト

## 確認概要

- **タスクID**: {TASK-ID}
- **確認内容**: {設定確認の概要}
- **実行日時**: {実行日時}
- **実行者**: {実行者}

## 設定確認結果

### 1. 環境変数の確認

```bash
# 実行したコマンド
echo $NODE_ENV
echo $DATABASE_URL

**確認結果**:

- [x] NODE_ENV: development (期待値: development)
- [x] DATABASE_URL: postgresql://localhost:5432/mydb (期待値: 正しいDB URL)

### 2. 設定ファイルの確認

**確認ファイル**: `config/database.json`

```bash
# 実行したコマンド
cat config/database.json | jq .

**確認結果**:

• [x] ファイルが存在する
• [x] JSON形式が正しい
• [x] 必要な設定項目が含まれている

コンパイル・構文チェック結果

1. TypeScript/JavaScript構文チェック

# TypeScriptファイルがある場合
npx tsc --noEmit --skipLibCheck

# JavaScript構文チェック
node --check *.js

**チェック結果**:

• [x] TypeScript構文エラー: なし
• [x] JavaScript構文エラー: なし
• [x] import/require文: 正常

2. 設定ファイル構文チェック

# JSON設定ファイルの構文チェック
cat config/*.json | jq empty

# YAML設定ファイルの構文チェック（該当する場合）
yamllint config/*.yml

**チェック結果**:

• [x] JSON構文: 正常
• [x] YAML構文: 正常（該当する場合）
• [x] 設定項目の妥当性: 確認済み

3. SQL構文チェック（該当する場合）

# SQL構文の基本チェック
psql -d mydb --single-transaction --set ON_ERROR_STOP=on -f schema.sql --dry-run

**チェック結果**:

• [x] SQL構文: 正常
• [x] テーブル定義: 正常
• [x] 制約定義: 正常

3. 依存関係の確認

# 実行したコマンド
npm list express pg

**確認結果**:

• [x] express: インストール済み
• [x] pg: インストール済み

4. データベース接続テスト

# 実行したコマンド
psql -d mydb -c "SELECT 1;"

**確認結果**:

-