結果をレビューしてマージする

Coroidは、独自のブランチ上でベースブランチに対するpull requestを作成して作業を完了します。自動的にマージを行うことはありません。マージは常に人の判断により行われ、それはプロバイダー側または承認してマージでCoroid内に表示されます。詳細はマージ処理。

含まれる内容#

• コード変更
• それに合わせて記述または更新されたテスト
• 既存のテストスイートを実行した結果
• 組織が設定した品質チェックの結果
• 差分に対するレビュー結果で、修正済みの項目または指摘事項が記載されています

目的はレビューを置き換えることではありません。レビューが最初のチェックとなるべきではないという点です。

実際に確認すべき点#

機械的な検証はすでに完了しています。人だけが判断できる点に注目してください：

1. 正しい問題を解決しているか？仕様に定められた受け入れ基準と比較してください。自分が依頼した内容の記憶と比較するのではなく。
2. コードベースに適合しているか？コーディング規約、命名、抽象化の構造などです。Coroidはコードを読み取ってこれらを推測し、ほとんどの場合正しく判断しますが、常に正しいとは限りません。
3. 予期しなかった箇所に変更が及んでいないか？差分を確認する前にファイル一覧をご覧ください。
4. 新しいテストは有意義か？何も保証しない合格テストは、テストがない場合よりも悪い結果となります。

作業を差し戻す#

コストが増す順に3つの選択肢があります：

• コメントを付けて再作業を依頼— タスクが開発エージェントに戻され、指摘事項とともにコンテキストが保持されます。「内容は正しいが不完全」な場合に最適です。
• 計画を拒否して再実行— 実行方法は正しいがアプローチが誤っていた場合に使用します。
• タスクをキャンセル— その作業が不要な場合に使用します。キャンセルすると実行が停止し、エージェントのスロットが解放されます。

同僚に伝えるのと同じように、修正コメントを具体的に記述してください。「これは空のケースに対応していません」parseRange「」と記述すれば修正が生成され、「要改善」と記述すると推測に基づく結果が得られます。

マージ#

Coroidは決して自動でマージを行いません。タスク完了時に自動マージを有効化する設定も存在しません。マージは常に人間が判断し、実行します。

これは「」下で開始された作業にも適用されます。指示Coroidは各マージについて自身がどう判断したかを記録し、自己評価の指標として利用しますが、その記録に基づいて行動することはありません。詳細はこちら。Coroidの判断内容と、最終的に人間が決定する事項。

GitHubまたはGitLab内で#

プロバイダー内でpull requestをマージし、通常のブランチ保護機能や必須チェック、承認ルールを適用します。pull requestは通常のプルリクエストと同様なので、既存のレビューやCIプロセスが適用されます。

Coroidから「Approve & merge」で#

Coroidのレビュー画面にはApprove & mergeボタンがあります。確認を求められた後、CoroidがGitHubまたはGitLabを通じてpull requestをマージします。これはプロバイダーのマージボタンを押すのと同等で、ブランチ保護機能や必須チェック、承認ルールが適用されます。これらの条件でマージが阻止される場合、プロバイダーからの理由が表示され、マージは行われません。

マージ前に行われる処理は、承認対象によって異なります。

• タスクこのタスクにはまずpull requestが必要です。まだ存在しない場合、レビュー画面で「作成」が提供されます。Create PRの前にApprove & merge承認すると、Coroidがタスクブランチをプッシュしてpull requestに最新のレビュー済みコミットを反映させ、その後pull requestをマージします。タスクを承認するには、該当プロジェクトへの書き込み権限が必要です。
• 計画計画に属するタスクは個別にマージできません。計画の単一のpull requestは、プロモーションレビューで承認されます。Coroidはまず、計画開始以降にベースブランチが変更されていないかを確認します（詳細は ベースブランチが変更された場合）、必須の品質チェックが通過し、pull requestにマージ競合がなく、レーンゲートによるブロックもない場合に、pull requestをマージします。計画を承認するには、該当プロジェクトへの書き込み権限が必要です。
• 強制マージ計画のプロモーションレビューでは「強制マージ」も選択可能です。Force mergeこの操作ではCoroidのベースブランチチェック、マージ競合チェック、レーンゲートチェックはスキップされますが、必須の品質チェックやプロバイダーのルールは適用されます。理由を文書で記載する必要があり、それはプロモーション情報と共に記録されます。また、プロジェクトへの管理者権限も必要です。

TheチャットアシスタントおよびMCPクライアントこれらのクライアントもプランのpull requestを承認または強制マージできます。これらはあなたの代わりに動作するため、同じチェックやプロジェクトへのアクセス権が適用されます。アシスタントは常に事前に確認を求めます。MCPクライアントによる強制マージは常に「待機中」状態になります。承認これは人間向けの処理です。MCPクライアントからの承認がそこで待機するかどうかは、自動化ポリシーによって決まります。どちらも単一のタスクをマージすることはできません。

リリース予定の内容を準備する#

マージ後、プロジェクトの「リリース」タブを開いて 「新規リリースを選択します。リリースする対象のマージコミットを指定すると、Coroidが含まれるプルリクエストを一覧表示します。その後、リリースページで各環境に対してチェック、承認、デプロイ、正常性確認の4ステップが順に実行されます。デプロイ処理は引き続きリポジトリとCI/CDが担当します。Coroidがリリースのデプロイ完了を判定するのは、パイプラインが確認を返した場合、またはオーナーや管理者が検証済みの外部デプロイを記録した場合のみです。

次へ#

リリース— マージコミットを準備し、各環境での処理を追跡します。次に進むべき場所他のワークフローが一覧表示されます。

関連項目#

• 来歴