タスクがpull requestに変わる仕組み

このページは他のドキュメントから参照される主要なページです。各実行段階の名称が記載されており、他の記事で処理が行われる場所を正確に特定できます。

パス#

your description
   │
   ▼
   specification   what will be built, and how you will know it worked
   │
   ▼
   plan            the ordered steps, reviewed before any code is written
   │
   ▼
   build           code and tests written in an isolated workspace
   │
   ▼
   verify          your test suite, plus checks and quality gates
   │
   ▼
   review          an automated review pass over the diff
   │
   ▼
   pull request    on a branch, in your repository, waiting for you

仕様書#

Coroidはユーザーの文章から直接開始されるわけではありません。まずはユーザーの記述を仕様書：何を構築するか、明確に範囲外とされる項目、そして作業が成功したかを判断するための 受入基準。

受入基準が重要な理由は、後続の検証段階でそれに基づいてテストが行われるからです。曖昧な仕様書では成果物を評価しにくくなります。

タスクの「仕様書」タブで仕様書を閲覧・編集できます仕様書タブにて、実行開始前に確認してください。

「仕様書駆動開発ガイド」仕様書駆動開発ガイドテスト可能な基準の記述方法、スコープの境界設定方法、そして計画・実装・レビューを通じて同じ成功定義を維持する方法について解説します。

計画#

小規模な変更以外の場合、仕様書は「計画」となります計画：順序付けられた一連の手順をフェーズごとにまとめたものです。コードを記述する前に計画を承認します。

計画を却下するコストは低く、アプローチが誤っている場合には適切な判断です。コード記述後に却下するとコストがかかります。この段階での判断が最も効果的です。

構築#

エージェントはリポジトリを分離されたワークスペースにクローンし、そこで作業します。コードを読み取り、変更を記述し、テストを作成または更新します。

ワークスペースはタスクごとに一時的かつ個別に用意されます。エージェントの操作がデフォルトブランチに影響を与えることはなく、同時に実行される2つのタスクが互いの作業内容を参照することもありません。

検証#

まずは自社のテストスイートが実行されます。これが最も信頼性の高いシグナルであり、チームが重要と判断した事項がすでに反映されているからです。

さらに、品質ゲート組織で設定された内容が実行されます：カバレッジの閾値、リンティング、セキュリティスキャン、プレビュー環境でのブラウザテストなどです。ブロッキングゲートはタスクの実行を停止し、アドバイザリーゲートは検出結果を記録してタスクを継続させます。

レビュー#

レビューアーエージェントが同僚と同じように差分を確認し、検出結果を生成します。修正可能な検出結果は再作業のために送り返され、その他の結果はpull requestに添付されて確認できます。

Coroid pull requestがすでにレビュー済みの状態で届くのは、あなたのレビューを代替するためではなく、あなたのレビューが最初のチェックとなるのを防ぐためです。

プルリクエスト#

ブランチがプッシュされ、ベースブランチに対してpull requestが開かれます。変更内容、テスト結果、検証結果、レビュー結果が含まれます。

Coroidでの処理はここで終了します。マージはユーザーが行います。

タスクのステータス#

タスクのステータスにより、上記の流れのどの段階にあるかがわかります：

スループットを決定する要因#

1つのエージェントスロットが一度に1つのタスクを処理します。スロット数により並列で実行される作業量が決まりますが、単一のタスクの完了時間を短縮するわけではありません。タスクの所要時間は変更の規模とテストスイートの実行時間によって決まります。

次へ#

エージェントの役割——どのエージェントが各段階を担当し、各エージェントに許可される操作内容。