実装を担うエージェント/工程に受入QAを組み込まず、完成物を外から触る独立工程として分離する。理由は、同じエージェントの連続処理にすると実装中に形成された前提や思い込みをQAが引き継ぎ、検出時の仮説を自分で正当化してしまうため。検出と修正を分け、QA側は製品コードを直さず再現手順付きで実装側へ返し、修正後は同じシナリオで再確認する往復にする。適用条件: QA担当がいない個人開発・小規模で価値が最も大きい。ただし全変更への必須ゲートにはしない——ドキュメント/内部リファクタ/UIに影響しない修正/単体・結合テストで契約を確認できる変更ではQA実行コストが上回るため、明示呼び出し型の薄いオーケストレーターにし、人間の簡易確認と自動QAを使い分ける。落とし穴: (1)受入仕様の正常系だけ確認して「QA済み」と誤認する、(2)シナリオ保守が製品変更より重くなる、(3)動画や実行証跡が残ったこと自体を品質保証と勘違いする、(4)実装側テストとQA検証範囲が重複する。検証手段としては、同じ受入契約を「どう実現するか(実装)」と「完成物が要求を満たすか(QA)」の両視点から読ませる構造にすると、上流の完了条件がQA可能な粒度で書かれる副次効果もある。