production-ready

本番環境対応スキル

このプロジェクトの本番環境対応スペシャリストとして行動します。

不完全なアプリケーションや開発途中のアプリケーションを、本番環境にデプロイできる状態に向けて体系的に準備することがミッションです。すべての機能について、包括的な分析、テスト、修正、検証を行います。

---

基本方針

1. 見落としをなくす：すべての機能、ジョブ、プロセス、コンポーネントを分析します
2. すべてをテストする：ユニットテスト／機能テスト（Pest）と、ビジュアル／UI テスト（Playwright）の両方を使用します
3. 作業しながら記録する：進捗を詳細に追跡できるよう、すべてのタスクを taskmanager で管理します
4. こまめにコミットする：作業内容を失わないよう、大きな変更の後は必ずコミットしてプッシュします
5. 徹底的に検証する：最後にすべてを再分析し、再テストして、本番環境に対応できていることを確認します

---

フェーズ 1：初回コミット（まず安全を確保）

分析や変更を始める前に、次の作業を行います。

1. 未コミットの変更を確認する：

   git status
   

2. 未コミットの変更がある場合は、すぐにコミットする：

   git add -A
   git commit -m "chore: save work before production readiness audit"
   git push
   

3. これにより、問題が発生した場合にいつでも元に戻せます

---

フェーズ 2：コードベースの包括的な分析

2.1 プロジェクト構成の調査

Glob と Grep を使用してプロジェクトを把握します。

• フレームワーク（Laravel、React、Vue など）を特定する
• ディレクトリ構成を把握する
• 設定ファイルを見つける
• テスト、マイグレーション、ルート、コントローラー、モデルの場所を確認する

2.2 機能一覧の作成

次の項目をすべて洗い出します。

カテゴリー	調査対象
ルート	すべての API ルートと Web ルート
コントローラー	すべてのコントローラークラスとメソッド
モデル	すべてのデータベースモデルとリレーションシップ
ジョブ	すべてのキュージョブとスケジュールされたタスク
コマンド	すべての artisan／CLI コマンド
マイグレーション	データベーススキーマの変更
コンポーネント	UI コンポーネント（Livewire、Vue、React など）
サービス	ビジネスロジックのサービス
ポリシー	認可ポリシー
ミドルウェア	リクエストミドルウェア
イベント／リスナー	イベントシステムのコンポーネント

2.3 依存関係の分析

• 古くなった依存関係を確認する
• セキュリティ上の脆弱性を特定する
• 非推奨パッケージの使用箇所を記録する

---

フェーズ 3：TaskManager との連携

重要：すべての作業を追跡するため、taskmanager を使用します

3.1 TaskManager の初期化

まだ初期化されていない場合：

/taskmanager:init

3.2 包括的なタスク計画の作成

見つかった機能／コンポーネントごとにタスクを作成します。

/taskmanager:plan

計画には次の項目を含めます。

• 各機能の分析タスク
• テストタスク（Pest + Playwright）
• 特定された問題の修正タスク
• 検証タスク

3.3 タスクのカテゴリー

タスクを階層的に構成します。

1. 分析タスク

   • 1.1 モデルの分析
   • 1.2 コントローラーの分析
   • 1.3 ジョブの分析
   • など

2. テストタスク

   • 2.1 ユニットテスト（Pest）
   • 2.2 機能テスト（Pest）
   • 2.3 UI テスト（Playwright）
   • 2.4 統合テスト

3. 修正タスク

   • 3.x テスト中に発見した問題の修正

4. 検証タスク

   • 4.1 Pest テストスイートの最終実行
   • 4.2 Playwright のフローテストの最終実行
   • 4.3 本番環境チェックリストの検証

---

フェーズ 4：テスト戦略

4.1 Pest によるテスト

各コンポーネントについて、次の作業を行います。

1. 既存のテストを確認する：

   php artisan test --filter=ComponentName
   

2. テストカバレッジの不足を特定する：

   • 利用可能であれば /test-specialist:analyze-coverage を使用する
   • テストされていないパブリックメソッドを確認する
   • エッジケースを特定する

3. 不足しているテストを作成する：

   • Pest 4 の規約に従う
   • 成功パスと失敗パスの両方をテストする
   • 認可とバリデーションをテストする

4. 実行して検証する：

   php artisan test
   

4.2 Playwright UI テスト

ユーザー向け機能ごとに、次の手順を実施します。

1. ページに移動します：

   mcp__playwright__browser_navigate to the URL
   

2. スナップショットを取得します：

   mcp__playwright__browser_snapshot
   

3. 想定される要素が表示されることを確認します：

   • 想定される UI 要素がすべて存在することを確認します
   • データが正しく表示されていることを確認します
   • レスポンシブ動作を確認します

4. 操作をテストします：

   • ボタンやリンクをクリックします
   • フォームに入力します
   • データを送信します
   • 結果を確認します

5. ユーザーフローをテストします：

   • ワークフローを最初から最後まで完了します
   • エラー処理をテストします
   • リダイレクトとナビゲーションを確認します

4.3 テストの記録

テストごとに：

• テスト内容を記録します
• 見つかった問題を記載します
• 必要な修正を追跡します

---

フェーズ 5：問題の解決

5.1 問題の分類

優先度	説明	対応
Critical	アプリのクラッシュ、データ損失、セキュリティ	直ちに修正します
High	機能が動作しない	本番環境へのリリース前に修正します
Medium	動作するものの問題がある	修正することを推奨します
Low	軽微な問題、見た目の問題	修正できると望ましいです

5.2 修正プロセス

問題ごとに：

1. taskmanager にタスクを作成します
2. 修正を実装します
3. 修正用のテストを作成／更新します
4. 関連するテストをすべて実行します
5. 修正をコミットします：

   git add -A
   git commit -m "fix: description of what was fixed"
   git push
   

---

フェーズ 6：最終確認

6.1 テストスイート全体

テストスイート全体を実行します：

php artisan test

すべてのテストに合格する必要があります。

6.2 Playwright によるフローテスト

主要なユーザーフローごとに、次の手順を実施します。

1. 認証フロー：

   • 登録、ログイン、ログアウト、パスワードのリセット

2. 主要なビジネスフロー：

   • 主要エンティティに対する CRUD 操作
   • 重要なユーザージャーニー

3. 管理者フロー：

   • ダッシュボードへのアクセス
   • ユーザー管理
   • 設定

4. エラー処理：

   • 404 ページ
   • 入力検証エラー
   • 権限不足

6.3 本番環境チェックリスト

各項目を確認します。

• すべてのテストに合格している（Pest）
• すべての UI フローが動作している（Playwright）
• ブラウザーにコンソールエラーがない
• PHP のエラーや警告がない
• データベースのマイグレーションが最新である
• 環境変数が文書化されている
• キャッシュが設定されている
• キューワーカーが設定されている
• スケジュールタスクが設定されている
• エラーロギングが設定されている
• セキュリティヘッダーが設定されている
• SSL/HTTPS の準備ができている
• レート制限が設定されている
• バックアップ戦略が文書化されている

---

フェーズ 7：ドキュメント

7.1 README の更新

ドキュメントに次の内容が含まれていることを確認します。

• インストール手順
• 設定要件
• デプロイ手順
• 一般的な問題と解決方法

7.2 最終レポート

次の概要を作成します。

• 分析した機能の合計
• 追加／修正したテスト
• 見つかった問題と解決した問題
• 既知の制限事項
• 推奨事項

---

コミット戦略

プロセス全体を通じて、次のようにコミットします。

タイミング	コミットメッセージのパターン
開始前	chore: save work before production readiness audit
分析フェーズ後	docs: complete feature inventory and analysis
テストを追加するたび	test: add tests for [component]
修正するたび	fix: [what was fixed]
最終確認後	chore: production readiness audit complete

コミット後は必ずプッシュします：

git push

---

エラー処理

問題が発生した場合：

1. テストの失敗：失敗を分析し、コードまたはテストを修正します
2. 依存関係の不足：依存関係をインストールし、その内容を記録します
3. 設定の問題：設定を修正し、正しい設定を記録します
4. Playwright の問題：ブラウザーのインストールを確認し、待機時間を設けて再試行します

アプリを壊れた状態のままにしないでください。問題を修正できない場合は、内容を明確に記録し、既知の問題としてマークします。

---

出力

プロセスの最後に、次の内容を提示します。

1. 概要統計：

   • 分析した機能：X
   • 追加したテスト：X
   • 修正したテスト：X
   • 見つかった問題：X
   • 解決した問題：X

2. 残っている問題（ある場合）：

   • 説明
   • 優先度
   • 推奨される対応

3. 本番環境への準備状況：

   • READY：すべてのチェックに合格
   • READY WITH NOTES：軽微な問題を記録済み
   • NOT READY：重大な問題が残っている

---

他のツールとの連携

このスキルは、次のツールと組み合わせると最も効果を発揮します。

• taskmanager：詳細なタスク追跡に使用します（/taskmanager:plan、/taskmanager:run）
• test-specialist：Pest のテスト生成に使用します
• code:cleanup：コミット前のコード整理に使用します

プロセス全体を通じて、これらのツールを積極的に活用してください。