要件から受け入れへ
1. 再確認と確認
ユーザーの目標、非目標、観察可能な受け入れ条件、リスク、予算制約を再確認します。確認後、実装に進みます。既に明確な確認がある場合はそれを引き継ぎ、重ねて許可を求めません。実際の実装に影響を与えるギャップのみを補足的に質問します。このフローは、ツール、費用、プッシュ、マージ、デプロイの権限を拡大しません。
2. コーディネーターによる直接分割
- コーディネーターは、機能境界、依存関係、インターフェース、責任者、受け入れ項目を直接提示し、分割エージェントの層を追加しません。独立したタスクは並行して進められ、依存タスクはインターフェースと順序に従って進められます。
- 独立してテストおよびロールバック可能な機能ごとに、独立したワークツリー、ブランチ、実際のPRを作成します。固定のターゲットブランチとベース/ヘッドSHAを使用します。異なる実装者が作業ディレクトリを共有したり、他のタスクのブランチを借用したりすることはありません。
- 単一機能PRの最終的な追加+削除行数は、テスト、ドキュメント、生成ファイルを含めて、可能な限り1000行を超えないようにします。超える場合は適切に分割します。分割できない場合は、理由と規模を説明し、生成ファイルを隠したり、機能を中途半端に分割したりしてはいけません。
- 複数機能バッチでは、サブPRのURL、依存関係、独立した受け入れ項目を記録します。プロジェクトが既にサポートしているスタックPRまたは統合ブランチに従って編成し、実際の能力を確認します。ドキュメント内のタスク番号を実際のPRと偽ってはいけません。
3. 実装者による実際の実行と自己検証
- 実装者は、実装、自己チェック、主要なユーザーパスの実行を完了した後に独立したレビューに提出します。主要な実行検証とスクリーンショットの作業をレビュアーに転嫁してはいけません。
- 正確なSHA、コマンド、環境、実際の結果、未テスト項目、リスクを記録します。バグがある場合は、修正前の再現手順と修正後の結果を同じパスで提供します。ビルド、モック、実際のサービスの受け入れ結果は別々に報告します。
- UIの変更については、主要な手順と結果の実際の実行スクリーンショットを提供します。スクリーンショットはPRコメントまたは添付ファイルに配置し、コードブランチにはコミットしません。まずアップロードツールがサポートするパラメータを確認します。アップロードがブロックされた場合はブロックを報告し、添付ファイルURLを偽造してはいけません。
- バックエンドの権限、データ、または資金に関する動作については、対応するAPI/データの証拠を提供します。テストには分離された環境と合成データを使用し、認証情報や個人データを漏洩してはいけません。
- UIのないルールやドキュメントの変更については、スクリーンショットを偽造してはいけません。範囲、リンク、ルールの一貫性、差分を確認するだけで十分です。コンテナ検証には承認された分離環境を使用し、ユーザーの個人マシンに無断でフォールバックしてはいけません。
- PRは4セクションテンプレートを使用し、各証拠は実際のコミットに関連付けます。
4. コードとセキュリティの個別レビュー
- リポジトリに既に設定されている自動コードレビューおよびセキュリティレビューを優先的に再利用し、完了状態、カバーされたSHA、未解決の発見事項をそれぞれ確認します。重複したレビューを追加で割り当てたり、手動でトリガーを繰り返したりしてはいけません。
- 設定されていない、トリガーされていない、またはターゲットSHAをカバーしていない場合は、ギャップを報告します。承認された代替計画に従って処理し、代替計画に承認がない場合は決定を仰ぎます。コメントがないことはレビュー完了を意味しません。
- コード品質については、必要に応じてインストール済みの
yushen-code-quality-reviewを読み取ります。セキュリティについては、必要に応じてyushen-security-reviewを読み取ります。パスは実際のインストール場所に従います。欠落しているか読み取れなかった場合はその旨を説明します。 - レビューでは、証拠がある問題のみを提起します。外部実装と比較して提案することはできますが、ユーザーの承諾なしにスキームを変更、移行、または依存関係を追加してはいけません。
5. 最大3ラウンドの収束
1ラウンドは、レビューフィードバック、修正、または証拠に基づく対処、検証から構成されます。コードレビューとセキュリティレビューを合計してラウンドをカウントし、合計で最大3ラウンドとします。エージェント、モデル、再試行、リスタック、または同じ作業PRの再開はラウンドをリセットしません。
初回ラウンドでは、要件と照らし合わせて完全な差分をレビューします。2回目、3回目のラウンドでは、新たな差分、既存の問題のクローズ、影響を受ける回帰をチェックします。安定した問題IDを使用して同じ根本原因の発見を統合し、位置、証拠、初回ラウンド、ステータス、修正SHA、検証を記録します。誤検出は証拠をもって説明し、コメントを消すためだけに無意味な修正を行ってはいけません。再確認なしに「解決済み」とマークしてはいけません。
同じ問題に対して2ラウンドの有効な修正を行っても進展がない場合は、早期にエスカレートできます。3ラウンド目でも未解決の問題が残っている場合は、自動収束を停止し、コーディネーターが証拠をまとめ、スキームを再検討し、決定を求めます。基準を下げたり、自動的に通過させたり、マージしたりしてはいけません。
6. 結合バージョンチェック
コーディネーターは、最終的な必須CI、競合解決、共有状態、結合ユーザーパスを確認し、各サブPRのSHAと結合候補SHAを記録します。各層が合格しても、結合が合格したことにはなりません。リベース、競合処理、または実装の変更後は、SHAマッピングを更新し、影響を受ける回帰を補います。古い証拠を現在のバージョンの結果と偽ってはいけません。
7. 人間による受け入れ
候補SHA、実行可能な成果物、最短テスト手順、期待される結果、残存リスクを提供します。ユーザー自身がテストし、対応するバージョンを明確に確認した後にのみ、実際の承認に従ってマージします。コードが変更された場合は、影響を受ける部分を再確認します。自動テストやボットによる承認は、本人の受け入れに代わるものではありません。リリースとデプロイは、それぞれの承認に従って処理されます。
インストーラー、デスクトップアプリケーション、またはその他の実際のリリース成果物を提供する場合、必要に応じてインストール済みのyushen-release-acceptanceを読み取り、最終的なダウンロードファイルから使用可能な状態までの完全なパスを検証し、プラットフォームの結論とプレビューの制限を区別します。純粋なテキストや内部の小さな変更については、完全なリリース受け入れを強制しません。
モデルとコスト戦略
設定可能なタスクの難易度、リスク、予算、利用可能な能力に基づいてモデルを選択します。確実性が必要なチェックはスクリプトを優先します。明確で局所的な実装は低コストモデルを優先します。複雑な診断、設計、高リスクの判断には能力適合モデルを選択します。証拠の整理には低コストモデルを使用します。開始時に、選択した役割、コスト境界、エスカレーション条件を説明し、特定のモデルを公開環境でデフォルトで利用可能と見なしてはいけません。
まず環境の障害とコンテキストの欠如を除外してから、エスカレーションするかどうかを決定します。予算を超えたり、有料呼び出しを追加したり、承認された能力を超えたりする場合は、まず対応する決定を仰ぎます。無制限に再試行してはいけません。バッチ終了後、必要に応じてフィードバック要約を使用し、ルールの更新は通常の受け入れフローに従います。
プロジェクトルールの組み込み
プロジェクトのAGENTS.mdで、関連するスキルとREVIEW.mdをタスクごとに読み取ることを明確に要求します。リンクが自動的に展開されることを想定してはいけません。REVIEW.mdには、判断可能な長期的なプロジェクトルールのみを配置し、各ラウンドの発見と証拠はPRに残します。ファイルの欠落や制約の競合がある場合は報告し、仕組みをでっち上げてはいけません。
プロジェクトルールを作成する際は、必要に応じて汎用REVIEWの例を参照し、実際に適用可能で検証可能な条項のみを保持します。