FlexGodX/自律エージェント開発サイクル

自律エージェント開発サイクル（品質ゲートパイプライン）

このスキルは、Quest Nova（Flutter + Go + PostgreSQL 16 + Drift/SQLite）の自律的な開発中に検証された5フェーズのエンジニアリングワークフローとマルチエージェント仲裁パイプラインを形式化します。

フェーズ間の人間の介入なしに、高いアーキテクチャ忠実度、ゼロデータ損失、厳格なセキュリティ（ゼロトラスト/IDOR）、および数学的に検証された分散同期を保証します。

[!NOTE] リバースエンジニアリングは除外: リバースエンジニアリングフェーズは省略/無効化されています。パイプラインは目標定義と機能仕様の作成から直接開始するか（または既存のプロダクトブリーフを入力として受け取ります）。

---

1. コアアーキテクチャ原則

1. ゼロ割り込み自律性: オーケストレーターはすべてのフェーズを自律的に進行します。確認はユーザーに尋ねるのではなく、厳格な品質ゲート監査からのみ導出されます。
2. クリーンコンテキスト独立検証: レビュアーと審査員は、クリーンコンテキスト（検証可能なターゲット成果物、参照仕様、明示的な評価基準のみを受け取り、以前のチャット推論は含まれない）を持つ専用のサブエージェントとして生成されます。
3. 全会一致の承認障壁: すべての監査人/審査員が明示的なAPPROVED判定を下すまで、次のフェーズへの移行はブロックされます。欠陥リスト（CHANGES_REQUESTED）は即時の修正-再監査ループをトリガーします。
4. フォールバックモデルルーティング: プライマリ推論モデルがレート制限（例：HTTP 429クォータ枯渇）を経験した場合、パイプラインはエージェントの役割とクリーンコンテキストの境界を厳密に維持しながら、利用可能な高スループットモデル（例：Gemini 3.8 Flash）にタスクをシームレスにルーティングします。

---

2. 5フェーズパイプライン

flowchart TD
    P1["フェーズ1: 目標策定と機能仕様"] --> QG1{"品質ゲート1: 仕様監査"}
    QG1 -->|"CHANGES_REQUESTED"| P1Fix["仕様欠陥修正"]
    P1Fix --> QG1
    QG1 -->|"APPROVED（全会一致）"| P2["フェーズ2: システム設計とアーキテクチャ"]
    P2 --> QG2{"品質ゲート2: 3エージェント法廷"}
    QG2 -->|"CHANGES_REQUESTED"| P2Fix["アーキテクチャ改善"]
    P2Fix --> QG2
    QG2 -->|"APPROVED（全会一致）"| P3["フェーズ3: QA成果物と実装計画"]
    P3 --> QG3{"品質ゲート3: トレーサビリティ相互レビュー"}
    QG3 -->|"CHANGES_REQUESTED"| P3Fix["計画とQAの整合"]
    P3Fix --> QG3
    QG3 -->|"APPROVED（全会一致）"| P4["フェーズ4: 実装（バックエンド + クライアント）"]
    P4 --> P5["フェーズ5: 完全検証、ストレステスト、リリース"]

---

3. 成果物命名規則

パイプラインで生成されるすべての成果物はバージョン管理されたファイルです。成果物をその場で上書きせず、代わりに次のバージョンを作成します。

<ARTIFACT-NAME>-<date>-<NN>.md

• <ARTIFACT-NAME> — 成果物のUPPER_SNAKE名：GOAL、SPECIFICATION、DESIGN、QA_ARTIFACT、IMPLEMENTATION_PLAN、RELEASE_NOTES。
• <date> — ISO形式YYYY-MM-DDの作成日。
• <NN> — 同じ日に作成された同じ名前の成果物を区別する2桁のシーケンス番号（01、02、...）。特定の日の最初の成果物は01から始まり、その日のその成果物のその後の改訂ごとにインクリメントされます。カウンターは成果物名ごとであるため、同じ日に異なる成果物が同じ番号を共有する場合があります（例：GOAL-2026-11-10-01.mdとDESIGN-2026-11-10-01.md）。新しい日になると、カウンターは01から再開します。

例：

成果物	その日の最初の成果物	その日の2番目の成果物
Goal	docs/GOAL-2026-11-10-01.md	docs/GOAL-2026-11-10-02.md
Specification	docs/SPECIFICATION-2026-11-10-01.md	docs/SPECIFICATION-2026-11-10-02.md
Design	docs/DESIGN-2026-11-10-01.md	docs/DESIGN-2026-11-10-02.md

ルール：

1. フェーズの成果物とすべての相互参照（品質ゲートプロンプト、計画、リリースノート）は、バージョン管理されていない名前（docs/GOAL.mdなど）ではなく、正確なバージョン管理されたファイル名を引用する必要があります。
2. 成果物名の最大の<NN>が現在の正規バージョンです。以前のバージョンは監査証跡としてそのまま残されます。
3. 品質ゲートは、渡された特定のバージョンを監査し、そのファイル名を判定に記録します。

このスキル全体を通して、<date>と<NN>は上記の日付とシーケンス番号を表します。

---

4. フェーズ別実行ガイド

フェーズ1: 目標策定と機能仕様（品質ゲート1）

• 目的: 要件/ブリーフに基づいて、明示的なシステム境界、ユーザーループ、ドメインモデル、技術仕様を策定します。
• 成果物:
  • docs/GOAL-<date>-<NN>.md: グローバルシステムスコープ、コア不変条件、完了の定義（DoD）。
  • docs/SPECIFICATION-<date>-<NN>.md: エンティティスキーマ、時間的メカニズム、同期プロトコル、OCCバージョニング、3-wayマージルール、IDOR保護、DDLスキーマ。
• 品質ゲート1（クリーンコンテキスト監査人）:
  • サブエージェント（typeName: "research"）を生成します。
  • docs/SPECIFICATION-<date>-<NN>.mdと評価基準（完全性、セキュリティ、データ整合性、一貫性）のみを提供します。
  • APPROVEDになるまでループします。

フェーズ2: システム設計と「3エージェント法廷」（品質ゲート2）

• 目的: スケーラブルでフォールトトレラントなバックエンドとリアクティブクライアントをアーキテクチャします。
• 成果物: docs/DESIGN-<date>-<NN>.md（システム設計ドキュメント：バックエンド、クライアント、セキュリティ）。
• 品質ゲート2（3エージェント法廷）: クリーンコンテキストで3つの独立したサブエージェントを生成します。
  1. 審査員1（バックエンド＆システムアーキテクト）: DBスキーマ、トランザクション境界、行レベルロック、トポロジカルDAGソート、パーティションスキーム、OCCを評価します。
  2. 審査員2（クライアント＆UIアーキテクト）: オフラインファーストDB（Drift/SQLite）、バックグラウンドアイソレート、フレームバジェット（< 16.6 ms）、ミューテーションキュー結合、BLoCステートマシンを評価します。
  3. 審査員3（セキュリティ＆エッジケース批評家）: 競合状態、コールドスタートデッドロック、エコーループ、トークンリプレイ（RTR）、セッション盗難、IDOR脆弱性を特定します。
  • 先に進むには、3人の審査員全員がAPPROVEDを返す必要があります。

フェーズ3: QA成果物、トレーサビリティ計画、品質ゲート3

• 目的: コードを書く前に、仕様、アーキテクチャ、テスト間の100%双方向トレーサビリティを確保します。
• 成果物:
  • docs/QA_ARTIFACT-<date>-<NN>.md: 完全な受け入れ基準（AC-XX）、ユニットテスト、統合テスト、分散同期テスト（TC-SYNC-XX）、ストレステストシナリオ（STRESS-XX）。
  • docs/IMPLEMENTATION_PLAN-<date>-<NN>.md: QAケースに直接マッピングされた段階的なタスク分割。
• 品質ゲート3（相互監査人）:
  • docs/QA_ARTIFACT-<date>-<NN>.md内のすべての受け入れ基準とエッジケースがdocs/IMPLEMENTATION_PLAN-<date>-<NN>.md内の実装ステップに直接マッピングされていることを確認します。
  • APPROVEDになるまでループします。

フェーズ4: 実装とテスト検証

1. データベースマイグレーション: 複合インデックスとパーティショニングを含むすべてのDDLマイグレーションを適用します。
2. バックエンドエンジン:
   • クリーンアーキテクチャ: domain/、repository/、usecase/、delivery/http/。
   • ユニットテストと統合テストの実行: cd backend && go test -v ./...。
3. クライアントエンジン:
   • コア時間ユーティリティ（PlainDate、FloatingTime、SparseSortOrder）。
   • 3-Way差分マージエンジン（5つのチェックリストシナリオ、ゼロデータ損失ノート）。
   • インプレースミューテーション結合とインフライトレース処理（MutationQueueManager）。
   • BLoCアーキテクチャとアダプティブUI（デスクトップ3ペイン + モバイルナビゲーション）。
   • クライアントテスト実行: cd client && flutter test。
   • リンターチェック: cd client && flutter analyze（0 issues）。

フェーズ5: ストレステスト、リリース、引き継ぎ

1. 分散同期検証: マルチデバイス並行処理、OCC競合、エコー抑制、HTTP 410ブートストラップ調整を実行します。
2. ストレステスト:
   • データベースコネクションプール飽和（STRESS-01）: プールリーク0の並行ワーカー。
   • UIフレームバジェットベンチマーク（STRESS-02）: 1000タスクを16.6 ms未満で処理（安定した60/120 FPS）。
3. 成果物コンパイル:
   • ネイティブバックエンドバイナリのビルド: go build -o bin/<service> cmd/<service>/main.go。
   • クライアントバンドルのビルド: flutter build bundle / flutter build macos / flutter build web。
4. リリースノート: docs/RELEASE_NOTES-<date>-<NN>.mdを生成し、検証されたメトリクス、DoDチェックリスト、実行手順を文書化します。

---

5. 監査人＆審査員プロンプトテンプレート

品質ゲート1、2、3でクリーンコンテキストサブエージェントを呼び出すためのプロンプトテンプレートについては、references/auditor_prompts.mdを参照してください。