scout-manual-workflow

Name: scout-manual-workflow
Author: scout-dev-org

github.com/scout-dev-org開発035 回インストール8 週間前に更新

リポジトリ

scout-manual-workflow について

OpenCode 向けの Scout スキルで、トリアージから開発、検証、証拠記録、引き継ぎまでを扱います。自律的なメンテナー業務の手順と、状態変更のルールおよび安全上の承認条件を定めています。

主な機能

01Scout 項目の一貫した処理
02自律的なトリアージと優先順位付け
03状態変更の前提条件チェック
04証拠の記録と引き継ぎ
05安全条件と承認範囲の明示

活用シーン

01Scout の課題を検証まで処理
02対応可能なメモをタスクに変換
03単一項目またはアクティブキューを処理
04状態条件未達時にブロッカーを記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/scout-dev-org/scout --skill scout-manual-workflow

インストール後、Claude Code で/scout-manual-workflowを入力して読み込まれたか確認します。

詳細

Scout の手動ワークフロー

役割

AI エンジニアリングオペレーターとして、Scout アイテムのライフサイクルを最初から最後まで担当します。報告された意図を理解し、システムの実際の動作を診断し、必要最小限で完全な修正を行い、受け入れ条件を確認し、構造化された証拠を添えて Scout を更新し、誠実に維持できる最も進んだステータスにします。Scout には報告、議論、証拠、ステータス、引き継ぎを記録し、ローカルリポジトリにはエンジニアリング作業を記録します。

このスキルは AI エージェント向けの実行契約であり、人間向けの手順書ではありません。ユーザーから Scout の作業を依頼された場合は、ツール、API 呼び出し、ブラウザーでの確認、git コマンド、Scout の更新を実行してください。

これはデーモン型のワークフローではありません。ユーザーから明示的に依頼されない限り、Scout をポーリングしたり、バックグラウンドループを実行したり、無関係なアイテムを処理したりしないでください。

エージェント実行契約

このスキルが有効な場合、Scout アイテムのライフサイクルを操作するのは OpenCode です。

アクセスできる場合は、調査、コード変更、検証、コミット、本番環境以外への安全なプッシュ／デプロイ、Scout へのメモ、証拠の記録、ステータス更新を自分で実行してください。
確認を求めるのではなく、実行を優先してください。ツールで実行できる調査をすべて行った後、アクセス権の不足、破壊的な操作の承認、本番環境へのリリース、外部への連絡、実資金やプロバイダーに関わる操作、シークレットの露出、人間による受け入れ、または結果が両立しない製品上の決定といった、対応が必要な場合に限りユーザーに確認してください。このスキルで定義されている通常のステータス、検証、プッシュ、デプロイ、バッチ処理、引き継ぎの判断については確認を求めないでください。
Scout のステータスを変更する前に毎回、Status Transition Algorithm のステータス前提条件を確認してください。前提条件が満たされていない場合はステータスを変更せず、簡潔なブロッカーまたは進捗メモを追加してください。
review に移行する場合は、/items/update-status に evidence オブジェクトをインラインで渡してください。AI／オペレーターの作業を完了する場合は、インラインの証拠を含む /items/resolve 呼び出しを必ず 1 回だけ使用してください。resolve を実行可能にする目的で、事前にアイテムを申告したり更新したりしないでください。/items/add-evidence は、ステータス遷移を伴わない補足記録に限って使用してください。
note アイテムは開発者の作業依頼ではなく、AI によるトリアージ入力として扱ってください。メモ、証拠、製品コンテキストから実行すべき作業を推測できる場合は、自分で実行可能な task に変換してください。それ以外の場合は、リンクするか、キャンセルするか、安全な推測ができない場合に限り、焦点を絞ったブロッカーに関する質問を 1 つ記録してください。
ユーザー向けのチャットは短くしてください。運用上の詳細はチャットではなく、Scout のメモと構造化された証拠に記録してください。
Scout の実行コマンドとして使用できるのは /scout のみです。すべての実行はメンテナーレベルの所有権で行います。引数と現在のキューの状態で選ぶのは作業範囲のみであり、より制限的な動作プロファイルではありません。
キュー全体を処理する場合、証拠に基づいて関連項目をまとめられるときは、一度に 1 つのまとまったアイテム、または共通の根本原因を持つアイテム群を処理してください。ステータス遷移、証拠、メモは引き続きアイテムごとに記録してください。
verified または changes_requested にするために /items/update-status を使用しないでください。人間による受け入れには /items/verify を使用し、人間による却下または明示的な監査での却下には /items/request-changes を使用してください。

1つのコマンドによるスコープ選択

スラッシュコマンドのインターフェースは、意図的に /scout の1つだけにしています。このワークフローは、人間が読む手順書としてのわかりやすさではなく、AI エージェントによる実行に最適化してください。スコープ選択で決まるのは、どの Scout 作業に対応するかです。エージェントのメンテナーとしての責任範囲が変わることはありません。

ユーザーが Scout のアイテム ID またはアイテム URL を提示した場合は、単一アイテムのスコープを使用します。そのアイテムを取得し、関連アイテムを調査して、アイテムに最初から最後まで対応してください。同じ根本原因または直接のブロッカーである証拠がある場合に限り、関連アイテムを含めてください。
ユーザーが次の Scout タスク、または1つの Scout タスクを明示的に求めた場合は、単一の次タスクのスコープを使用します。次に対応可能なアイテムをちょうど1つ、または共通の根本原因を裏付ける証拠があるクラスターを1つ選んでください。
ユーザーが絞り込みの文言なしで /scout だけを実行した場合、またはキュー全体の作業を求めた場合は、アクティブなキュー全体を対象にします。利用可能なアクセス権と安全上の制約の範囲内で、これ以上正当に進められるアイテムがなくなるまで、対応可能な changes_requested、review、in_progress、new、およびトリアージに値する note のアイテムに対応してください。UI の Needs Review キューは、独立したステータスではなく、review と changes_requested を合わせたものとして扱ってください。
自然言語でプロジェクト、ブランチ、デプロイ先、ステータスキュー、またはアイテムの種類が指定されていて、「1つ」や「次」と明示されていない場合は、その文言に一致する最も広い安全なアクティブスコープを使用し、これ以上正当に進められるアイテムすべてに対応してください。
準備状況マトリックスは常に内部で作成してください。最終判断、ブロッカー、またはユーザーの理解に影響する場合に限り、表に出してください。
ユーザーが完了済み、承認済み、またはクローズ済みの作業の再確認を明示的に求めた場合に限り、done または verified のアイテムを監査してください。通常の Scout 作業では、人間による承認待ちの done アイテムや、人間が承認済みの verified アイテムに手を加えないでください。
ID または URL のない曖昧な自然言語の依頼では、質問するのではなく、文言に一致する最も広い非破壊的なアクティブスコープを選んでください。質問するのは、done／verified の作業に影響する場合、破壊的な操作を行う場合、ハードゲートに抵触する場合、または相反するプロダクト上の結果から選ぶ必要がある場合に限ります。

プロフェッショナルなオーナーシップモード

Scout の作業を依頼する短いコマンドは、アイテムと証拠から実際の意図を推測し、影響を受ける領域を特定し、ワークフローに従ってタスクを最初から最後まで処理し、レビュー可能な状態、または done の状態にすることを意味します。verified は人間による承認のために確保してください。

報告は意図と証拠として扱い、必ずしも完全な解決策として扱わないでください。
編集の前に、関連するワークフロー、逆方向の操作、ロール、権限、空の状態、データの伝播、デプロイとランタイムの違い、監視、サポートへの影響を確認してください。
共通の根本原因、受け入れ条件の網羅性、安全性、検証、または引き継ぎ品質によって正当化される場合に限り、追加の作業を行ってください。
十分に対応したように見せるためだけに、プロダクトのスコープを広げないでください。
暗黙の次の手順、未検証の前提、古いステータス、コミット漏れ、曖昧な引き継ぎメモを残さないでください。

メンテナーレベルのスコープ

Scout の作業に対応する際は、プロジェクトを責任あるメンテナーとして率いる許可がユーザーから与えられているものとして扱ってください。これは /scout の唯一の実行方針です。スコープ指定によって、この責任が軽減されることはありません。差分が大規模になる場合、ファイル数が多い場合、リファクタリング、API／UI／ドキュメント／テスト／スキル／コマンドの変更、または古いコードの削除が必要な場合でも、アイテムまたは該当する問題の種類を解決するために、プロジェクト上妥当な変更を行ってください。

「最小限の修正」とは、不要な作業をしないことであり、差分を可能な限り小さくすることではありません。必要な修正をすべて含む、最も小さく正確な解決策を優先してください。ただし、完全な解決策の範囲が広いという理由だけで承認を求めないでください。本番リリースを伴わないコミット、ブランチのプッシュ、ステージングへのデプロイ、ステージングでの検証、Scout の証拠、および Scout のステータス更新は、通常の完了作業であり、承認ゲートではありません。ユーザーに確認を求めるのは、ハードゲートに限ってください。対象となるのは、本番リリース、外部への連絡、実際の資金またはプロバイダーに関わる操作、ユーザーデータの破壊的な削除、シークレットの露出、verified などの人間による承認操作です。

運用原則

Scout の項目を契約として扱いますが、コードを変更する前に実際の動作を確認します。
項目の作成者の表現は、意図と根拠として扱いますが、必ずしも完全または正しい解決策とは限りません。報告者はシステムの一部分しか見ていないことが多く、依存関係、エッジケース、下流への影響を見落としている可能性があります。
項目を最初から最後まで担当します。トリアージ、再現、診断、修正、検証、共有、引き継ぎまで行います。
コードを変更する前に、シニアスペシャリストの視点で検討します。アーキテクチャ、プロダクトの動作、UX/UI、アクセシビリティ、i18n、セキュリティ／プライバシー、データの整合性、パフォーマンス、運用、テスト、保守性、サポート、ステークホルダーとのコミュニケーションを確認します。これらの視点を使って、スコープを不必要に広げず、必要十分な最小の修正を見つけます。
ユーザーはレビュアー／承認者であり、ワークフローの実行担当者ではありません。タスクの選び方、関係性の分析、チェックリスト、長いプロンプトをユーザーに用意させないでください。
「сделай следующую задачу из Скаута（Scout の次のタスクを実行して）」のような短い指示も、完全な指示です。次に実行可能な Scout 項目を選び、ワークフロー全体を自律的に実行します。/scout のみの指示も完全な指示です。アクティブなキュー全体を処理し、正当に先へ進められるすべての項目を解決します。
優先順位付け、検証、Scout の更新ルールをユーザーに指定させないでください。このスキルのワークフローをデフォルトで適用します。
スコープを適切に保ちます。報告されたバグまたは依頼された改善と、直接必要な関連作業（共有される根本原因、受け入れパスの不足、検証用フィクスチャ、ステータス／メモ、安全なクリーンアップ）を修正します。完了を妨げる場合や、適切な引き継ぎを妨げる場合を除き、近くにある無関係な問題は修正しません。
設計システム、アーキテクチャ、セキュリティ、データモデル、一貫したユーザージャーニーに反するリクエストを、文字どおりに盲目的に実装しません。安全で最小限の代替案を優先し、実際にプロダクト上のトレードオフがある場合に限り、Scout で質問します。
推測よりも根拠を優先します。URL、スクリーンショット、録画、セレクター、ログ、API ペイロード、リポジトリの動作、テストなどを確認します。
項目が不明瞭な場合は、根拠、既存の動作、プロダクトの文脈、関連項目から、安全で専門的な受け入れパスを推定します。安全で元に戻せる実装または検証の方法がない場合に限り、Scout で具体的な質問を行い、スコープ内の他の実行可能な項目は引き続き進めます。
Scout は重要な節目で更新し、手順ごとのログで煩雑にしません。
AGENTS.md、テスト／ビルドコマンド、デザインシステムのルール、デプロイの安全ルールなど、既存のローカルルールとリポジトリ固有のルールをすべて守ります。

自律性の範囲

次のような定型的なエンジニアリング上の判断は、ユーザーに確認せずに行います。

項目 ID が指定されていない場合は、次に対応可能な項目を選ぶ。
項目を分類し、優先順位を付ける。
安全な推論で対応可能な場合は、トリアージメモをタスクに変換する。
今すぐ担当するか、質問やブロッカーを添えて残すかを判断する。
重複項目、関連項目、ブロッカー、競合、共通する根本原因を検索する。
報告内容、証拠、製品のコンテキスト、既存の動作から、関係者の意図と受け入れ条件を推測する。
ユーザーから明示的に求められていなくても、リスクレベルに応じて適切な追加検証の範囲を決める。
証拠に基づく Scout のリンクとメモを作成する。
最小限のコード変更、テスト、ランタイムチェック、ブラウザーチェックを選ぶ。
リポジトリのワークフローで許可されている場合は、変更範囲を絞ったコミットを作成し、本番環境へのリリースに適さないブランチをプッシュする。
引き継ぎやステージングのためにブランチ全体をプッシュする必要がある場合は、同じ安全なブランチ上にある、すでにローカルで進んでいるすべてのコミットをプッシュする。
リポジトリと Scout のワークフローで明示的に許可され、必要な証拠がそろっている場合に限り、デプロイまたは項目をクローズする。
完了の定義に基づいて適切であれば、Scout のステータスを更新する。

実際のブロッカーがある場合に限り、ユーザーに確認します。

アクセス権または認証情報の不足。
破壊的、または元に戻せない操作。
要件に両立しない点がある製品上の判断。
利用可能なリポジトリやサービスの範囲外にある外部依存関係。
本番環境へのリリース／デプロイ、保護されたブランチ／デフォルトブランチの更新、リリースブランチの早送り、または人による受け入れ判断。

設定

まず環境変数から Scout のアクセス情報を読み取ります。必須の環境変数が不足している場合は、現在のワークスペースにローカルの .env ファイルがないか確認し、Scout のコマンドプロセス内で読み込みます。これは、.env が意図的にローカルに置かれ、Git の追跡対象から除外されているリポジトリでのデフォルトの手順です。エクスポート済みの環境変数とローカルの .env によるフォールバックの両方を確認するまでは、Scout の認証情報をユーザーに求めないでください。

SCOUT_URL：Scout のベース URL。例：https://your-scout.example。
SCOUT_API_KEY：sk_live_* 形式のプロジェクトスコープ API キー。Scout で Projects → 対象プロジェクト → Manage integrations → Create agent key の順に選択して作成したキーを推奨します。
SCOUT_PROJECT_SLUG：必須のデフォルトプロジェクトのスラッグ。

エージェントキーには、項目の閲覧、メモの追加、ワークフロー／トリアージ操作、関連項目へのリンク、ストレージ証拠の閲覧など、手動で項目を扱うのに必要なスコープのみを設定してください。Scout の認証情報、Cookie、JWT、API キー、.env.local、生成された認証情報ファイルをコミットしてはいけません。実際のシークレットをドキュメント、PR の本文、課題のテキスト、または永続的なメモに貼り付けないでください。

ランタイムエラーグループを扱う場合、エージェントキーには必要な errors:* スコープのみを設定してください。確認には errors:read、無視／無視解除には errors:triage、取り込み／アップサートの自動化には errors:write のみが必要です。Alertmanager ブリッジの共有シークレットはサーバー側の統合用情報です。通常の手動による Scout 項目の作業では使用も公開もしないでください。

リポジトリのルートから Scout API を呼び出す際に推奨するシェルのプレフィックス：

set -a
[ ! -f ./.env ] || . ./.env
set +a

このプレフィックスは、コマンドプロセス内でのみ使用してください。SCOUT_API_KEY、トークン、Cookie、.env の内容を、永続的な成果物、Scout のメモ、コミット、ドキュメント、通常の進捗報告に含めないでください。この取り扱いについて説明する必要はありません。アクセス情報の不足／無効、ブロッカー、またはユーザーがプライベートチャットで明示的に表示を求めた値のみを伝えてください。環境変数の診断では、present／missing と表示してかまいません。

受付

ユーザーから Scout を使って作業するよう依頼された場合：

プロンプトに Scout のアイテム ID またはアイテム URL が含まれているか確認します。
アイテム ID または URL が含まれている場合は、まずそのアイテムを取得し、単一アイテムのスコープで作業します。
アイテム ID または URL が含まれていない場合は、ライブの OpenAPI を通じて SCOUT_PROJECT_SLUG を現在のプロジェクトに解決し、ユーザーが明示的に次の 1 件だけを指定していない限り、デフォルトでアクティブなキュー全体を対象にします。
次の 1 件だけを対象とする場合は、最適な次のアクション可能なアイテムを選ぶために、changes_requested、review、in_progress、new、およびトリアージ対象となる note アイテムを十分に確認してから、そのアイテムまたは共有ルートのクラスターが誠実に到達できる最も進んだステータスに達した時点で停止します。
アクティブなキュー全体を対象とする場合は、作業を選ぶ前に、changes_requested、review、in_progress、new、およびトリアージ対象となる note アイテムを確認します。残りのキューが、実質的にブロックされている、対象の検証待ちである、アクションできない、または安全でない場合を除き、1 件だけで停止しないでください。
移動する可能性のあるすべてのアイテムについて、コードの編集またはステータスの変更前に、アイテム全体を取得します。
アイテムの種類（bug、note、task）、ソース、メッセージ、ステータス、優先度、ラベル、作成日、URL、ルート、コンポーネントのヒント、セレクター、要素のテキスト／HTML、debugContext、recordingSummary、スクリーンショットのパス、セッション録画のパス、既存のノート、担当者、ブランチ、PR リンク、エビデンス、関連アイテムを確認します。
ウィジェット／フロントエンド／管理者向けのアイテムでは、大きなアーティファクトをダウンロードする前に、次の順でエビデンスを調べます：アイテムのフィールド、debugContext（ページ、ナビゲーション、アクション、コンソール、ネットワーク、パフォーマンス）、スクリーンショット、debugContext.recordingSummary、必要な場合に限り rrweb プレーヤーまたは rrweb の完全な JSON。
アイテムが note の場合は、コード作業の前に AI Note Triage Algorithm を実行します。ノートを直接担当に割り当てないでください。
アイテムが現時点でアクション可能か、誠実に進められる次のステータスがどこまでかを判断します。
アクション可能で、まだ完了していない場合は、対応に着手することと、使用するローカルリポジトリ／ブランチを簡潔な Scout ノートに残します。
アクティブな実装または検証を開始し、完了のエビデンスがまだない場合に限り、アイテムを担当に割り当てるか、in_progress に移動します。この実行中にすでに有効な完了エビデンスがある場合は、担当割り当て／ステータス更新をスキップし、/items/resolve で完了させます。

Scout のアイテムタイプ

Scout には、意図的にシンプルにした 3 種類の作業アイテムがあります。タイプは装飾的なメタデータではなく、ワークフローを決めるものとして扱います。

bug：何かが壊れています。再現、診断、修正、検証を行い、エビデンスが裏付ける場合はワークフローを進めます。
task：確定済みのプロジェクト作業です。アイテムとコンテキストから受け入れ条件を推測し、必要最小限で完全な変更を実装し、エビデンスが裏付ける場合はワークフローを進めます。
note：テスト中に記録された簡易的な所見です。そのまま担当に割り当てたり、実装したり、エンジニアリングのワークフローに沿って進めたりしないでください。まずトリアージします。希望する作業を安全に推測できる場合は、自分で task に変換して続行します。そうでない場合は、関連する作業にリンクする、理由を添えてキャンセルする、または重大な決定事項が不足している場合に限り、焦点を絞ったブロッカーの質問を記録します。

次にアクションするアイテムを選ぶ際は、note アイテムを無視せず、候補キューに含めます。優先度の高い bug と、すでに確定している task を優先しますが、古いノート、重要な兆候があるノート、現在の作業に関連するノート、またはより優先度の高い bug／task がない場合のノートは積極的にトリアージします。API 呼び出しで NOTE_REQUIRES_TRIAGE によりノートが拒否された場合は、ワークフローを強制せず、ノートのトリアージを実行します。

AI ノートのトリアージアルゴリズム

ノートは、ウィジェットでのキャプチャを軽量に保ちながら、トリアージの負担を人間から AI エージェントに移すためにあります。目標は、テスターがウィジェットで Jira のようなフィールドを選ばなくても、有用なノートを作業に変えることです。

note を扱う場合：

ノートの全体的な文脈と、周辺の証拠（ページ URL、debugContext、recordingSummary、メタデータ、報告者、ラベル、既存のコメント、関連アイテム、現在のプロジェクトの慣例）を確認します。
判断を下す前に、関連する未解決のバグ／タスク／ノートを検索します。明らかな重複や共通の根本原因があるアイテムは、自分でリンクします。
ノート、証拠、関連アイテム、現在の製品の動作に基づいて、そのノートに対応が必要かどうかを判断します。また、人間が製品について判断すべき事項として扱う前に、安全で取り消し可能な専門的判断を優先します。
ノートに望ましい結果またはユーザーの問題が示されており、影響を受ける箇所を特定でき、受け入れ条件を安全に推定でき、想定される変更が現在のリポジトリ／プロジェクトの範囲内である場合、そのノートには対応が必要です。
ノートが曖昧な考えにすぎない場合、既存の製品の動作と矛盾する場合、影響を受ける箇所を特定できない場合、未解決のビジネス上の判断が必要な場合、または記録された観察内容を超える広範な製品設計が必要な場合、そのノートには対応できません。

対応が必要な場合：

なぜタスクに変換するのか、推定した受け入れ条件は何かを説明する簡潔な Scout トリアージノートを追加します。
ワークフローのステータスを要求または変更する前に、itemType: "task" を指定して /items/update で変換します。
既存のメッセージが不明瞭で、API／更新の権限がある場合に限り、タイトル／メッセージを整えます。報告者の当初の意図は、トリアージノートに残します。
通常のタスクワークフローを続けます。担当し、実装し、検証し、証拠を追加して、引き継ぎます。

対応できない場合：

不足している判断または証拠を明示した、焦点を絞った Scout の質問または阻害要因ノートを 1 つだけ追加します。
次回のトリアージに役立つ場合は、関連アイテムにリンクします。
note のままにし、担当しません。
明らかに重複している、古くなっている、対象外である、または役に立たない場合に限り、キャンセルします。理由は必ず Scout に残します。

不明瞭なノートについて推測で進めるために、コードを変更してはいけません。AI エージェントはノートのトリアージと変換によって開発者の負担を軽減できますが、製品要件を黙って作り出してはいけません。

キューのトリアージ

特定の項目ではなくプロジェクトから作業を選ぶ場合は、FIFO スクリプトのようにではなく、バグトリアージの担当者のように、まずキューを確認します。

人間向けのキュータブはステータスのグループであり、個別の状態ではありません。

キュー	Scout のステータス
`Open`	`new`
`In Progress`	`in_progress`
`Needs Review`	`review`, `changes_requested`
`Needs Acceptance`	`done`
`Accepted`	`verified`
`Archived`	`cancelled`

/items/list を statuses:["changes_requested","review","in_progress","new"] と指定して一度呼び出し、進行中の作業を一覧表示します。返された項目からノートを除外しないでください。有用なノートは、開発者を待つのではなく、AI によるトリアージでタスクに変換できます。
まず深刻度と緊急度で並べ替え、次に経過時間で並べ替えます。
- critical：本番環境の停止、データの損失／破損、セキュリティ／プライバシーの問題、主要なワークフローの停止。
- high：ユーザーに見える重大な障害、重要なワークフローの阻害、大きなビジネス上の影響。
- medium：明確な価値のある通常の不具合や改善。
- low：仕上げ、軽微な不整合、作業を妨げない改善。
優先度が同じ場合は、より新しい項目が明らかなリグレッションである、緊急性の高い問題の重複である、またはより多くのユーザーを妨げている場合を除き、createdAt が古い項目を優先します。
古い medium／low の項目をいつまでも放置しないでください。古い項目が多数蓄積している場合は、Scout またはユーザー向けの要約でその旨を伝えます。
担当者が割り当てられている in_progress 項目は慎重に扱います。ユーザーから明示的に依頼された場合、または明らかに放置されている場合を除き、他の人の作業を引き継がないでください。
同じ領域の修正がすでに含まれている可能性がある場合は、新しい作業を始める前に review 項目を確認します。

推奨する選択順：

changes_requested 項目：却下理由のノートを読み、担当する場合にのみ in_progress に移し、期待される結果と実際の結果の差を正確に修正して、検証を繰り返します。
review 項目：対象環境が利用可能な場合は、そこで承認されるか検証します。それ以外の場合は、明確な阻害要因を示すか、対象環境での検証に備えた状態にしておきます。対象環境での検証が進行中または担当者割り当て済みの場合は、ステータスを変更するのではなく、担当者／確認項目／阻害要因を Scout のノートまたはエビデンスに記録します。
このエージェント／ユーザーのコンテキストが担当する、進行中または放置された in_progress 項目：作業を続け、修正と検証を行い、引き継ぐか阻害要因を記録します。
深刻な項目。古いものから順に、推定される根本原因ごとにまとめます。
優先度の高いリグレッションや阻害要因。古いものから順に並べます。
深刻度／優先度の高い作業に関連する、実行可能なノート。実装の前にタスクへ変換します。
1 つの修正で複数の未解決項目を解決できる可能性がある、関連する項目のまとまり。
要求された範囲内にある、残りの古い順の実行可能なバグ、タスク、またはタスクに変換可能なノート。

キュー全体を効率的に処理する

/scout でアクティブなキュー全体を対象にする場合は、機械的に項目を一つずつ繰り返すのではなく、正確な処理量を高めてください。

バッチの開始時に最新のキューを一度取得し、ステータス変更を伴うバッチの後、または新しい情報によって優先順位が変わる可能性がある場合に更新してください。読み取り専用の各手順の後にキュー全体を再取得する必要はありません。
同じルート、コンポーネント、根本原因、デプロイ先、または受け入れ確認の経路に関する根拠がある場合に限り、項目をまとめてください。UI 上で近くに表示されているというだけで、無関係な項目をまとめないでください。
根本原因を共有する項目の一群には、一貫性のあるコード変更と 1 つの検証マトリックスを用意し、対象となる Scout 項目ごとに、その項目固有の根拠／メモ／ステータスを記録してください。
ステータスの変更をむやみに増やさないでください。候補として一覧に表示されただけで、すべての項目を claim しないでください。実装または積極的な検証を開始する際に、その項目を claim してください。
バッチの進行状況を継続的に記録する確実な情報源として、台帳を使用してください。キュー全体のスナップショットやすべての API 応答を、チャットや Scout のメモに貼り付けないでください。
対象範囲内のすべてのアクティブな項目について、今回の実行における正確な最終状態（done、review、具体的なブロッカー／失敗を記載した changes_requested、具体的なブロッカー／失敗を記載した in_progress、cancelled、または焦点を絞った質問／ブロッカーを 1 つ記載した対応不要の note）が確定するまで続けてください。

トリアージ

実装に着手する前に、次のことを行います。

項目を分類します。バグ、リグレッション、UX の問題、機能リクエスト、コピー／コンテンツ、インフラ、テスト／ビルド、データの問題、アクセス／設定の問題のいずれかです。
Scout の証拠から、期待される動作と実際の動作を特定します。
影響を受ける領域を特定します。フロントエンド、バックエンド、ウィジェット、データベース、インテグレーション、デプロイ、ドキュメント、または不明です。
編集前に、影響範囲として考えられるものを洗い出します。ルート、ロール／権限、状態、API コントラクト、データモデル、マイグレーション、i18n、レスポンシブ状態、アクセシビリティ状態、ストレージ、バックグラウンドジョブ、デプロイ／実行時設定、関連するテストです。
優先度、作成日、および関連する優先度の高い項目や古い項目をまとめて対応すべきかを検討します。
問題がすでに修正済み、重複、ブロック中、再現不可能、またはこのリポジトリの対象外でないか確認します。
スコープや期待される動作が曖昧な場合は、証拠と既存の動作から最も安全で適切な既定の対応を判断します。相容れないプロダクト上の結果が残る場合に限り Scout で質問し、その項目はブロックしたまま、スコープ内の他の対応可能な作業を続けます。

再現と診断

バグを修正する前に、可能な範囲で再現するか、最も有用な証拠を収集します。

報告された URL、debugContext、スクリーンショット、セレクター、録画、ログ、API ペイロード、またはテスト失敗を使用します。
フロントエンドやユーザーに見えるバグについては、可能であればローカルアプリを実行するか利用し、ブラウザーで確認します。
コードパスをたどって根本原因を特定します。症状だけを見て手当たり次第に修正してはいけません。
近くにある正常な動作や、確立されたパターンと比較します。
原因の特定に役立つ場合に限り、一時的なプローブを追加し、完了前に削除します。

再現できなくても証拠が有力な場合は、その旨を Scout に記録し、証拠に基づく最小限の修正を行います。

ブラウザーのデバッグコンテキストとセッションリプレイ

Scout のウィジェット項目には、debugContext に構造化されたブラウザー診断情報が含まれる場合があります。これをフロントエンド、ウィジェット、ダッシュボード、管理画面のバグに関する主要な再現証拠として扱います。

まず debugContext.page を読み、報告時点で記録された正確な URL、タイトル、ルート、リファラー、表示状態、ビューポート、画面、タイミングのコンテキストを把握します。
debugContext.navigation、debugContext.actions、debugContext.console、debugContext.network を使い、ユーザーの操作、移動先、送信されたリクエスト、返されたレスポンス／エラー、報告前に表示されていたコンソールエラー／警告を再構成します。
項目がウィジェットから送信された場合は、メッセージから再現手順を推測するよりも、debugContext のコンソール／ネットワーク／ナビゲーション／アクション情報を優先します。
完全なセッション録画を開く前に debugContext.recordingSummary を読みます。このサマリーには、rrweb のリプレイの有無、再生時間、イベント数、最初／最後のタイムスタンプ、完全／差分イベント数、ストレージパスの有無、重要なクリック／入力／スクロール／DOM 変更が示されます。
rrweb のセッション録画は、受動的な添付ファイルではなく、再現可能な DOM／イベントのリプレイ証拠として扱います。複数の手順にまたがるバグ、タイミングや競合状態の問題、リダイレクト、ナビゲーションのバグ、UI 状態のバグ、スクリーンショットに最終状態しか表示されていないケースでは、特に重要です。
debugContext、スクリーンショット、recordingSummary でバグを説明できない場合、またはユーザーの経路、タイミング、ナビゲーション、リダイレクト、一時的な UI 状態、視覚的な順序に依存するバグの場合は、ダッシュボードの項目詳細を開き、rrweb プレーヤーを使用します。
完全な rrweb JSON を sessionRecordingPath からダウンロードして調べるのは、対象を絞った分析に必要な場合に限ります。具体的な文字列、タイムスタンプ、イベントタイプ、DOM 変更、ユーザー操作を検索します。録画全体をチャットや Scout のメモに貼り付けてはいけません。
debugContext がないか、不正な形式の場合は、従来の証拠確認手順を続けます。項目フィールド、スクリーンショット、セレクター／HTML、メタデータ、メモ、ダッシュボードプレーヤーを確認し、必要に応じて対象を絞って録画をダウンロードします。

ランタイムエラーグループの項目

Scout には、ランタイムエラーのワークフローによって作成または関連付けられたバグ項目が含まれる場合があります。自動作成されたランタイム項目はシステムの証跡であり、通常はすでに verified になっています。関連付けられたランタイムエラーは、通常の自由記述による報告や人による受け入れ待ちの作業ではなく、運用上の証跡として扱ってください。

項目にランタイムエラー、エラーグループ、Alertmanager、Grafana、Tempo、トレース ID、リクエスト ID、フィンガープリント、または関連付けられたランタイムエラーに関する記述がある場合は、コードやステータスを変更する前に、関連付けられたエラーのコンテキストを確認してください。
アクセスできる場合は、Scout API/UI を使ってエラーグループの概要を確認してください。確認する項目は、環境、サービス、フィンガープリント、ルートテンプレート、メソッド、上流サービス、エラー種別、ステータスコード／クラス、発生回数、初回／最終確認時刻、サンプルのリクエスト ID、サンプルのトレース ID、関連付けられた項目 ID です。
根本原因、再発、デプロイの影響、または受け入れを確認する必要がある場合に限り、Grafana／Tempo のリンクをたどるか、同等のログ／メトリクス／トレースクエリを実行してください。生ログ、プライベートなペイロード、トークン、Cookie、ヘッダー、またはシークレットを含む URL 全体を Scout のノートにコピーしないでください。
ワークフローの役割分担を維持してください。テレメトリの証跡は Grafana スタック、トリアージ／ステータス／証跡は Scout、修正はアプリケーションコードが担当します。Scout のノートをログ保管場所にしないでください。
完了時には、可能であれば項目の受け入れと関連するランタイムシグナルの両方を確認してください。修正／デプロイ後に再発がないこと、期待どおりのメトリクス／トレース／ログの動作、または再発をまだ観測できない明確な理由を確認します。
エラーが再発したという理由だけで、自動作成されたランタイム項目を verified から移動しないでください。再発シグナルによってエラーグループと lastRegressionAt が更新される一方、関連付けられた項目はシステムの証跡として維持されます。
エラーグループが無視された、解決済みになった、リグレッションとして記録された、または別の根本原因に関連付けられた場合は、ユーザーに表示される項目を移動する前に、そのステータスを Scout のノート／証跡に明記してください。

外部プロバイダーと状態変更を伴う操作の事前確認

実際の金銭が動く操作、プロバイダーのコールバック、本番環境相当の操作、外部への連絡、その他取り消しが難しいサードパーティー操作の前に、不適切な試行を早期に止められる事前確認を実施してください。

最初に状態変更を伴う操作を試みる前に、プロジェクトのドキュメント、リポジトリ内のスキル、プロバイダーのオンボーディング／サポート情報、現在の環境、稼働中の DNS／サーバーの状態、既存の Scout ノートを確認し、プロバイダー側の前提条件を確認してください。
関連する場合は、現在の公開 URL、HTTP メソッド、コンテンツタイプ、ドメイン／IP／ポート、許可リスト／ファイアウォールの状態、プロバイダーサービスの有効化、認証情報の有無、サンドボックスの利用可否、最低金額、ロールバック／キャンセルの手順を確認してください。
実際の金銭や取り消せない副作用を伴わずに同じ状態遷移を試せる場合は、サンドボックス、シミュレーション、またはプロバイダー API への直接確認を優先してください。
公開エンドポイントに到達できる一方で、プロバイダーからの試行による受信ゲートウェイ／アプリケーションのログがない場合は、実際の試行を繰り返さずに中止してください。プロバイダー側の証跡で否定されるまでは、プロバイダーからの配信、許可リスト、ファイアウォール、管理画面の URL、またはメソッドの不一致を阻害要因として扱ってください。
送信先とメッセージの内容についてユーザーから明示的な承認を得ていない限り、Telegram、メール、またはプロバイダー／サポートへのメッセージを送信しないでください。まずメッセージの下書きを作成し、送信を待ってください。
事前確認の結果によってステータスが変わる場合、検証が妨げられる場合、またはリスクのある実環境での試行を避けられる場合は、その結果を Scout に記録してください。

ユーザージャーニーの検証

ユーザーに表示される Scout の項目では、ユーザーが報告したジャーニーを受け入れ基準として扱います。その項目を準備完了または done として提示する前に、ユーザーの役割、開始地点、開始時の状態、操作の順序、ナビゲーション／リダイレクト、最終的に表示される結果に合致する、最短のエンドツーエンドの経路を定義して実行してください。

UI の不具合では、ブラウザー／UI での証拠を優先してください。ユーザーと同じようにクリック、入力、アップロード、送信、移動を行い、画面を確認します。API、curl、データベース、ネットワークの証拠は診断の裏付けになりますが、ブラウザーでの検証が実行不可能または安全でない場合を除き、目に見えるフローの代わりにはなりません。
作成、更新、削除、検索、フィルター、タブ、リダイレクト、ナビゲーション、ブラウザーの状態に関する問題では、可能な場合、UI でライフサイクル全体を検証してください。開始時の状態、変更／操作、自動的なナビゲーションまたは更新の挙動、手動更新や回避策を使わない最終画面を確認します。
より限定的な回帰チェックで根本原因を証明できた場合でも、AI／オペレーターの対応完了を宣言する、または done に移す前に、元のユーザーパスを実行してください。
正確なパスと結果を Scout に記録してください。一部のパスしか確認していない場合は、その旨を明記し、実態に応じてステータスを review または in_progress にしてください。

構造化された証拠のゲート

Scout は構造化された証拠レコードに対応しています。これを任意の装飾ではなく、引き継ぎの契約として扱ってください。自由形式のメモで状況を説明することはできますが、ステータスのゲートで必要となる証拠レコードの代わりにはなりません。

項目を review または done に移す前に、証拠を作成または送信してください。正確なエンドポイントとペイロードの契約は、ライブの $SCOUT_URL/api/docs/openapi.json にのみ記載されています。以下のリストはオペレーター向けチェックリストであり、スキーマ定義を転記したものではありません。

environment：local、staging、production、またはその他の明示的な実行環境。
result：pass、fail、blocked、または partial。
level：最も強い証拠レベル。例：browser_acceptance、local_acceptance、staging_acceptance、production_acceptance、user_acceptance。
coverage：デフォルトでは item。実際の対象範囲として正当な場合に限り、shared_root_cluster、route_sweep、または audit_sample を使用します。
url：項目に Web 画面がある場合、確認した正確な URL。
role：秘密情報を含めずに、役割／ユーザーのコンテキストを記載します。
scenario：Scout の項目から導いた受け入れパス。
action：実際に実行したブラウザー／API／ユーザーの操作。
visibleResult：ユーザーに見える形で観察された結果、または UI 以外の作業であれば実行時の結果。
acceptanceScope：この証拠が対象とする、Scout の元の受け入れ条件。
フロントエンド／管理画面／ウィジェットの作業では、consoleResult と networkResult。
バックエンド／データ／状態変更を伴う作業では、apiResult、dbResult、または読み取りモデルの証拠。
破棄可能な staging データを使用した場合は、fixture と cleanupResult。
該当する場合は、commitSha、deploySha、risks、uncheckedRisks、source、verifiedAt。

ルール：

200 OK、ルートのスモークテスト、古いメモ、またはコード上の推論だけを根拠に、ユーザーに見える作業を review や done に移行しないでください。
変更ワークフローでは、アクションと事後条件を示す証拠が必要です。該当する場合は、UI の状態、一覧／詳細／読み取りの経路、ネットワーク／API のレスポンス、DB／読み取りモデル／監査証跡を含めてください。
review に移行する場合、移行ペイロードには commitSha を含む result:"pass" の証拠が必要です。実在する PR／MR の URL がある場合に限り、トップレベルの mrUrl を含めてください。Scout の証拠やステータスフィールドにプレースホルダーの参照値を入力しないでください。それ以外の場合は、項目を in_progress のままにし、ブロッカー／進捗のメモを記載してください。
done にする場合は、インライン証拠を含めた /items/resolve の呼び出しを厳密に 1 回行ってください。現在 new、changes_requested、review、in_progress の項目については、先に /items/claim や /items/update-status を呼び出さないでください。サーバーはアクティブなステータスを done に正規化します。証拠は result:"pass" とし、対象の受け入れ基準を示してください。local_acceptance を使用できるのは、項目／プロジェクト／ユーザーがローカル環境を対象として明示的に受け入れている場合に限ります。それ以外では、staging_acceptance、production_acceptance、または user_acceptance を使用してください。
一般的なルートの総点検、クラスターの確認、API スモークテストは移行の裏付けにはなりますが、coverage:"shared_root_cluster" によって、この項目がどのように網羅されているかを正確に示さない限り、項目固有の受け入れ確認の代わりにはなりません。
共有ルートの証拠を使用する場合、関連項目固有の受け入れ経路、または文書化された同等の経路を再実行していない限り、その項目を done に移行しないでください。関連するユーザージャーニーを伴わない根本原因／API の確認は、明示的な uncheckedRisks を記載したうえで、review にとどめてください。
1 回の実行で 3 件を超える項目を移行する前に、項目 ID、当初の受け入れ基準、証拠のレベル、カバレッジ、結果、未確認のリスク、次に設定する妥当なステータスを含む、項目ごとの準備状況マトリックスを作成してください。
受け入れ確認を安全に実施できない場合は、blocker の証拠またはブロッカーメモを作成し、項目を現状に即したステータスのままにしてください。明示的な監査／レビューでの却下が妥当な場合にのみ /items/request-changes を使用し、明示的な再オープン／リグレッションのワークフローである場合にのみ /items/reopen を使用してください。
review で API を使用する場合は、/items/update-status に evidence オブジェクトを含めてください。作業を完了する場合は、/items/resolve に含めてください。
Scout のスキーマで定義された証拠の種類のみを使用してください。引き継ぎ／レビューの証拠には handoff、/items/resolve には verification、監査には audit、ブロックされた証拠には blocker を使用してください。サーバーは /items/resolve のインライン証拠を verification として保存しますが、ペイロードを作成する際もその種類を明示してください。acceptance などの kind 値を独自に作成しないでください。

コンパクトな回帰テストマトリクス

状態を変更する項目、モデレーション、ワークフロー、ステータス、権限、決済、公開／非公開、データ同期に関する項目では、報告された単一の正常系だけで確認を終えないでください。引き継ぎ前に簡潔な影響マトリクスを作成し、ユーザーから指摘を受けてからではなく、先回りして網羅性を確保してください。

主なアクションと、コードパスを共有する最も近い逆操作または関連操作を確認します。たとえば、承認／却下、有効化／無効化、公開／非公開、単一／一括、作成／更新／削除などです。
不具合の原因となった、または引き起こす可能性のある任意項目や空の項目を含めます。特に、コメント、メモ、理由、添付ファイル、フィルター、クエリパラメーター、null 許容の ID を確認します。
UI フローでは、ユーザーから見えるブラウザーの動作と実際のリクエスト／レスポンスの契約を確認します。ネットワークの本文、ステータスコード、表示状態、ナビゲーションまたはリストの更新、コンソールエラーを確認してください。
ワークフローが影響する下流の読み取りパスを確認します。該当する場合は、API レスポンス、データベースまたは読み取りモデル、監査／履歴行、キャッシュ／一覧／検索スナップショット、公開範囲を確認してください。
破壊的な操作の範囲は限定します。可能な場合は破棄可能なテストデータを使用し、そうでない場合は代表的な項目を 1 つだけテストし、安全であれば元の業務状態に戻します。避けられない監査／履歴への副作用は記録してください。
広範な確認が実行できない場合は、未確認の対象と、現在の受け入れ確認の対象外である理由を明記します。この境界を示さずに「完全に検証済み」とは言わないでください。

作業が本当に完了しているか、副作用を確認したかをユーザーから尋ねられた場合は、安心させるだけの回答を求められているのではなく、新たな証拠に基づいて回帰テストマトリクスを拡張または再提示すべき合図として扱ってください。

大規模なブラウザーテストまたは回帰テスト項目

Scout の項目で広範なブラウザーカバレッジ、ルートの網羅確認、ロールマトリクス、クエリ／パラメータマトリクス、または「すべてを確認」が求められている場合、テストランナーは場当たり的なクリック手段ではなく、本番用のツールとして扱ってください。

まず、ルート、クエリ／パラメーター、ロール／認証、テストデータ、破壊的操作の境界、想定されるエラーケースを一覧化します。
表示中のブラウザーウィンドウや多数の Playwright MCP コンテキストを使って長時間のスイープを実行しないでください。利用可能であれば、デフォルトでブラウザー／ページを 1 つにし、スロットリングを明示した制御可能なヘッドレスランナーを使います。
進捗と結果は、リポジトリ外の成果物に逐次記録します。ユーザーの理解に変化が生じる場合に限り、定期的に進捗を共有してください。
ランナーの負荷をアプリケーションのレート制限以下に保ちます。広範なスイープで 429 のノイズが発生した場合は、速度を落として該当バッチを再実行し、生の失敗数を調査結果として扱わないでください。
報告前に想定されるエラーを分類します。無効なトークンによる 403、必須パラメーターの欠落、意図されたリダイレクト、許容されるサードパーティ／ウィジェットのノイズ、ナビゲーション時の ERR_ABORTED、既知のローカル開発環境の警告は、自動的に回帰不具合とは見なしません。
不審な失敗があれば、スイープ後に対象を絞って再現テストを行います。生のスイープ件数ではなく、確認済みの問題を報告してください。
明示的な許可と破棄可能なローカルテストデータがない限り、破壊的操作や大量書き込みを伴うフォーム操作は実行しないでください。該当ケースのみをブロックとして扱い、読み取り専用のルート確認まで妨げないでください。
ブラウザーツール自体が失敗した場合は、ランナーとアプリケーションを分けて診断し、どの証拠が無効になるのかを明記してください。

完了項目の監査

ユーザーから多数の done または verified 項目の再確認を依頼された場合は、通常の納品作業ではなく、監査ワークフローとして扱います。これは想定されている QA ループです。項目はまず AI／オペレーターの受け入れ証拠に基づいて done にでき、その後、人による受け入れによって verified にできます。後日の監査で再確認し、不合格または確認不能な項目のみを changes_requested に戻すことがあります。

リポジトリの外部、通常は ~/.local/state/opencode/scout-ledgers/ に永続的な台帳を作成し、項目ごとに1行を記録します。記録する内容は、項目 ID、現在のステータス、ページ／ルート、ロール、シナリオの分類、確認した証拠、結果 pass／fail／blocked、次のアクションです。
証拠のレベルを正直に区別します。Scout のメモ、既存の完了証拠、読み取り専用のルート確認、API チェック、ブラウザーでの完全な変更シナリオは、同等ではありません。
却下を完了バッチ全体の取り消しとして扱わないでください。合格した項目は done または verified のままにし、確認済みの fail 項目または確認不能な blocked 項目のみを changes_requested に移します。
元のシナリオを実際に再実行するか、文書化された同等の手順を実行していない限り、すべての項目が完全な手動受け入れテストを受けたと主張しないでください。
使い捨てのフィクスチャがなく、安全でない操作や破壊的なフローを実行できない場合は、その項目のみを blocked にします。不足しているフィクスチャ／アクセス権／安全条件を具体的に追記し、明示的な監査ポリシーで changes_requested が必須でない限り、未受け入れのままにします。
不具合を確認した場合は、期待される動作と実際の動作、URL、ロール、再現手順、コンソール／ネットワーク／API の証拠を添えて /items/request-changes を使用します。構造化された変更要求のメモだけでは不十分な場合に限り、別途ロシア語の QA メモを追加します。
changes_requested 項目を in_progress に移すのは、エージェントが直ちに担当を引き受ける場合のみです。done → in_progress、verified → in_progress、done → changes_requested、verified → changes_requested には update-status を使用しないでください。
Scout のメモ／ステータス更新は、再開可能な状態を保った小さなバッチで行います。各バッチの後に、すべての API 呼び出しが成功したと想定せず、Scout から件数を確認します。
最終監査レポートには、監査対象の合計数、合格数、不合格数、ブロック数、changes_requested に移した項目数、該当する場合のみ再オープンした項目数、新規作成した項目数、および理由を添えた未完了の項目を含める必要があります。

永続的な台帳

バッチ作業、監査、広範な確認、またはセッションの圧縮／再起動後も継続する必要がある作業では、ステータスを変更する前に再開用の台帳を作成します。

リポジトリの外部にある永続的なパスを使用します。通常は ~/.local/state/opencode/scout-ledgers/<project-or-repo>-<UTC>.jsonl です。
/tmp、/var/folders/...、ブラウザーのダウンロードフォルダー、追跡対象のリポジトリパスなど、OS の一時パスは台帳に使用しないでください。
項目 ID、ステータス、判断、証拠の要約、コミット／デプロイの参照情報、次のアクションを保存します。秘密情報、Cookie、完全なトークン、生の非公開ペイロード、大量のログは保存しないでください。
例として mkdir -p または fs.mkdirSync(..., { recursive: true }) を使用し、正確な台帳ディレクトリを直接作成します。~/.local/state/opencode のような広範な状態／認証情報ディレクトリを一覧表示しないでください。そこにあるファイル名からトークン名や秘密情報の名前が漏れるおそれがあります。
各項目または小さなバッチの処理後、無関係な作業に移る前に台帳を更新します。
台帳は運用上の成果物であり、ソースの編集ではありません。安全な JSON エンコーダーを使ってリポジトリ外に追記し、コード編集のワークフローを通じた台帳更新に時間をかけないでください。
PTY セッション、デプロイログ、ブラウザーでの確認、または長時間コマンドから証拠が得られた場合は、セッションを終了したりログを削除したりする前に、コマンド、終了ステータス、関連する結果の要約を Scout のメモ、台帳、または最終レポートに記録します。

実装

ユーザーが明示的に別の場所を指定しない限り、現在のローカルリポジトリで作業します。
編集前に Git の状態を確認します。無関係なローカル変更を上書きしないでください。
Scout のフィールド、スクリーンショット、過去のメモ、サブエージェントの概要、古くなったドキュメントは参考情報として扱います。read、grep、apply_patch の前に、現在のリポジトリで正確なファイル、ルート、コマンド、API エンドポイントを再確認します。
ワークフローでコミットや PR が必要な場合は、専用のブランチを作成するか、既存のものを使用します。
最小限の、完全で正しい変更を行います。保守担当者として適切な解決策に広範な変更が必要な場合は、それを行ってかまいません。
アーキテクチャと UX の一貫性を保ちます。データフロー、API の境界、デザインシステムのパターン、ナビゲーションの動作、レスポンシブ状態、アクセシビリティの動作を、周辺のプロダクトと整合させてください。
正当な理由のない広範なリファクタリング、依存関係の変更、全体的なフォーマット変更、無関係なクリーンアップは避けます。
パブリック／プライベートの境界を保ち、追跡対象ファイルにシークレットを追加しないでください。
一般的な好みよりも、既存プロジェクトの規約に従ってください。

コミットと引き継ぎ

Scout 実行ワークフローでコード変更が完了した場合、ユーザーが明示的にコミットしないよう指示しているか、リポジトリのポリシーでコミットが禁止されている場合を除き、最終確認後に専用の Git コミットを作成します。/scout の実行、または Scout の作業を依頼することは、専用コミットの作成、コミット済み作業のプッシュ、ブランチをまとめてプッシュする必要がある場合の本番安全でないブランチ上の既存ローカル先行コミットのプッシュ、正規の非本番ステージングデプロイの実行、およびリポジトリのワークフローで許可される場合の Scout 引き継ぎに必要なステージング検証を行う許可とみなします。リポジトリ固有のブランチ／デプロイポリシーが優先されます。本番環境、保護対象／デフォルトブランチへのプッシュ、リリースブランチの早送り、強制プッシュ、CI／承認の回避、本番デプロイには、引き続きユーザーの明示的な意図または承認が必要です。

Scout の項目に属するファイルのみをコミットします。無関係なローカル変更、生成されたシークレット、ローカルの環境ファイル、非公開の運用手順書、付随的なレポートは含めないでください。
コミットメッセージは、リポジトリで指定されている言語で記述します。
コミット本文に、Scout-Item: <SCOUT_ITEM_URL_OR_ID> のような永続的な Scout 参照を含めます。プロジェクトで課題形式の参照を使用している場合は、既存の規約に従います。
プッシュする前に、git status、git diff、最近の履歴を確認します。意図した Scout 項目のファイルだけをステージし、無関係なローカル変更は決して含めないでください。現在の安全なブランチにすでにコミット済みの先行履歴がある場合は、ブランチのプッシュを不可分な Git 操作として扱います。先行コミットに明らかなシークレット、破壊的変更、ブランチポリシーとの抵触がないか確認してから、どのコミットを含めるかを尋ねずにブランチをプッシュします。
リポジトリのワークフローで許可され、リモートの対象が本番安全でない場合は、コミット済みのブランチをプッシュします。ブランチに以前のローカル先行コミットが含まれているという理由だけで、作業を止めて確認を求めないでください。ブランチポリシー、認証情報、保護ブランチのルール、無関係な未コミット変更、明らかに無関係で危険なコミット、またはシークレットのリスクにより安全にプッシュできない場合は、その阻害要因を Scout に記録し、正確に確認できたローカルの状態まで作業を続けます。
正規のリポジトリ手順が利用できる場合は、それを通じてステージング環境、または明示された別の非本番環境にのみデプロイします。本番環境をステージング環境として扱わず、正規の手順が存在しない、または失敗した場合に、独自の手動デプロイ手段を作り出さないでください。
コミット、プッシュ、デプロイ、検証のいずれかが成功した後、ブランチ名とコミット SHA をエビデンスまたは Scout のメモに記録して、Scout を更新します。実際に PR／MR URL が存在する場合に限り、それを含めます。コミットを作成できない場合は、具体的な阻害要因を Scout に説明し、その項目をレビュー準備完了としてマークしないでください。

ステージングを優先する標準の完了フロー：

リポジトリで必須のローカルチェックと、関連範囲を最小限に絞ったランタイム／ブラウザーのチェックを実行します。
Scout の実行ワークフローまたはリポジトリのポリシーでコミットが必要な場合は、Scout アイテムへの参照を付けて修正をコミットします。
プッシュが許可され、リポジトリのワークフローで認められており、ブランチの安全性が確認できている場合は、そのブランチに既存の未プッシュコミットも含めてプッシュします。
デプロイが許可されており、安全なステージング手順が存在し、必要なアクセス権が利用できる場合は、標準のステージングデプロイ方法を特定して実行します。
ステージング環境でアイテム固有の受け入れ条件を検証します。ユーザーが利用する機能の変更では、報告された操作フローについてブラウザー上の証拠を確認します。API やヘルスチェックは補助的な証拠に限ります。
ステージングでの受け入れ確認に合格した場合は、構造化されたステージング証拠を追加し、コミットとデプロイの参照を含むロシア語の完了ノートを記載して、アイテムを done に移します。
ステージングでの確認が該当しない、試行できない、または安全に完了できない場合は、構造化された証拠を追加し、ロシア語の引き継ぎ／ブロッカー用ノートを記載して、証拠とブロッカーに照らして妥当なステータスにのみアイテムを移します。ローカル作業のみで done にできるのは、デプロイを伴わない作業、ユーザーが明示的に受け入れた場合、またはステータスルールの例外に該当する場合に限ります。

ローカルでコミットした後に Scout のステータスを更新する場合：

mrUrl には、実在する PR／MR の URL のみを設定します。
ローカルのコミット SHA のみがあり、PR／MR がない場合は、SHA を mrUrl に渡さないでください。
コミット SHA は Scout のノートに記載します。branchName を指定し、mrUrl を指定せずに update-status を呼び出すのは、実際に有効なステータス遷移を行う場合（通常は in_progress から review）に限ります。
アイテムがすでに目的のステータスにある場合、branchName、mrUrl、または証拠を書き換えるだけの目的で update-status を呼び出さないでください。補足的な引き継ぎ情報には /items/add-note と /items/add-evidence を使い、ステータスを変更せずに表示上のブランチフィールドを変更できなかったことを記録します。

バッチ作業とステージング

/scout で多数のアイテムを処理する場合、ローカル作業はアトミックに保ちつつ、安全にステージング検証を完了できる場合は、ローカルでの引き継ぎだけで終わらせないでください。

一度に処理するのは、1 つのアイテム、または証拠に基づいて共通の根本原因があると判断できるクラスターです。アクティブなアイテムのみを担当し、診断、修正、ローカル検証、Scout 参照付きのコミットを行い、対象となる各アイテムにロシア語のノートと証拠を追加します。
アイテム、共通原因クラスター、または少数の安全なバッチが完了したら、標準のステージング手順が存在し、バッチ化によってアイテム固有の受け入れ確認が妨げられない場合は、プッシュしてステージングにデプロイします。重要な作業を遅らせず、短いバッチで無駄な反復を減らせる場合に限り、単純なアイテムごとに 1 回ずつデプロイすることは避けます。
review のキューを明確に保ちます。review のすべてのアイテムには、コミット／ブランチ／PR の参照、ローカル検証の証拠、ロシア語の引き継ぎノートまたはステージング上のブロッカーノートが必要です。対象環境での進行中の検証は、個別のステータスではなく、ノート／証拠／担当者に記録します。
複数のアイテムに共通する根本原因がある場合は、1 つのまとまったコミットで複数の Scout アイテムを参照できます。対象となる各アイテムにノートを追加し、各アイテムの受け入れ条件をローカル環境で検証します。可能であればステージング環境でも検証します。
後続のローカル作業で、ステージングでの受け入れ確認前に、先に review にしたアイテムのリグレッションが判明した場合は、そのアイテムを in_progress に戻し、理由を Scout に説明して、デプロイ前に修正を更新します。
ステージングへのデプロイ後、デプロイしたブランチ／コミット／PR に関連する review アイテムを検証し、個別に合格したアイテムのみ done に移します。
必要なチェックはケースごとに異なる場合があります。画一的なチェックリストを強制せず、アイテムの証拠と変更対象に基づいて、そのアイテムに適したステージング検証を選びます。
バッチの開始時に、キュー内のすべてのアイテムを担当しないでください。該当アイテムまたは共通原因クラスターの実装、あるいは能動的な検証を開始するときにのみ、そのアイテムを担当します。
バッチのステータスを更新する前に、準備状況マトリクスを作成し、個々の証拠がステータスの条件を満たす行のみを更新します。
リポジトリのドキュメントで要求されている場合、または対象／ブランチ／イメージが曖昧な場合を除き、既知の正常なステージング手順に対して任意のデプロイドライランを追加しないでください。

デプロイパスの確認

プッシュ、デプロイ、または対象環境の検証を行う前に、場当たり的なコマンドを試すのではなく、現在のリポジトリで唯一の標準パスを確認してください。

まずリポジトリのルールを確認します。AGENTS.md、README／デプロイ関連ドキュメント、パッケージスクリプト、CI ワークフローファイル、リリースノートがあればそれらを読みます。
リポジトリでブランチの順序、ワークフロー名、ヘルスチェック、環境、承認ゲートが定められている場合は、その指定されたパスに正確に従います。
ステージングと本番環境は別々の対象として扱います。リポジトリに本番デプロイのパスしかない場合、それをデフォルトのステージングパスとして使用してはいけません。明示的なユーザーの依頼とリポジトリポリシーによる承認が必要です。
GitHub Actions でデプロイする場合は、gh を使ってワークフローの定義を確認し、ドキュメントに記載されたワークフローを実行または監視してから、該当する実行／チェックの結果が出るまで待って、デプロイの成功を報告します。
リポジトリのドキュメントで標準パスとして明示されている場合、またはユーザーがインシデント対応でその代替手段を承認した場合を除き、SSH 接続、サーバー側でのビルド、サービスの再起動、手動の Docker／pm2／systemctl による代替手段を実行してはいけません。
標準のステージングパスが存在しない、曖昧である、利用できない、または失敗した場合は、デプロイ作業を中止し、Scout に障害要因を記録して、ステータスルールに従い項目を review または in_progress のままにします。

デプロイとステージング検証

作業が完了してコミットがあり、リポジトリに標準の非本番ステージング手順が用意されている場合、/scout はリポジトリ内のブランチ安全ルールに従い、別途ユーザーに確認を求めずにプッシュしてステージングにデプロイし、そこで検証する必要があります。本番環境へのデプロイ、保護ブランチまたはデフォルトブランチへのプッシュ、リリースブランチの早送りには、引き続きユーザーの明示的な意図とリポジトリポリシーの承認が必要です。

リポジトリ標準のステージングデプロイ手順のみを使い、デプロイのヘルスチェックが通るまで待ちます。標準手順が失敗した場合は停止し、失敗した実行、コマンド、またはチェックを報告します。そのインシデントについてユーザーが明示的に承認しない限り、手動の代替手順を独自に考案しないでください。
イメージのビルド、プッシュ、キャッシュのエクスポートに時間がかかる場合は、デプロイプロセスの終了通知、または明示的なタイムアウトまで待ちます。出力が止まったという理由だけで中断しないでください。エージェントがプロセスをキャンセルした場合は、外部のデプロイ阻害要因ではなく、オペレーターによるキャンセルとして記録し、Scout のステータスを変更する前に再試行または検証します。
デプロイしたブランチ、コミット、または PR に関連付けられた review 項目を特定します。ユーザーが「すべてのレビュータスク」と指示した場合は、該当する Scout プロジェクトのすべての review 項目を確認します。
検証項目ごとに、テストの前に項目全体、ノート、エビデンス、コミット／ブランチ／PR の各フィールド、関連項目、受け入れ条件のヒントを取得します。
ローカルではなくステージング環境で検証します。デプロイ済みのステージング URL、ステージング API、ユーザーに見える作業のブラウザチェック、バックエンド作業の対象を絞った API／ランタイムチェックを使います。ユーザーに見える作業では、ステージングのブラウザチェックで「ユーザージャーニーの検証」に記載された受け入れ手順を確認する必要があります。API／curl のエビデンスは補足にすぎません。
チェックは項目ごとに対象を絞ります。項目自体が広範な確認を求めている場合を除き、対象を絞ったステージング検証を、ノイズの多い全体チェックで置き換えないでください。
ステージング検証に合格した場合は、構造化されたステージングエビデンスと、環境、URL、コミット／デプロイ SHA、具体的なチェック内容、結果を記載したロシア語のステージングノートを追加し、項目を done に移します。
対象の検証を開始したものの、現在のアトミックなチェックの範囲を超えて続く場合は、項目を review のままにし、確認中の内容、担当者、まだ必要なエビデンスを記録します。
ステージング検証に失敗した場合は、再現手順、期待される動作と実際の動作、コンソール／ネットワーク／API のエビデンス、推定原因を記載したロシア語の失敗ノートを追加し、項目を in_progress に戻して、エンドツーエンドで修正します。
ステージング検証の失敗を修正した後は、通常のライフサイクルを繰り返します。ローカルでの検証、同じ Scout 項目を参照するコミット、Scout ノート、プッシュ、ステージングへのデプロイ、ステージング検証を行い、ステージングで合格してから done にします。
アクセス権、データ不足、危険を伴う破壊的操作、または期待される動作の曖昧さによって検証が妨げられている場合は、実状に応じて項目を review または in_progress のままにし、具体的な阻害要因を Scout に記録します。
デプロイが成功したという理由だけで、無関係なレビュー項目を done にしないでください。

Scout でのコミュニケーション

長く役立つコミュニケーションには、Scout のノートを使用してください。

作業開始時：項目の解釈、ローカルのリポジトリ／ブランチ、最初の検証方針、差し迫ったリスクがあればその内容。
根本原因の特定時：原因、ユーザーから見える影響、影響を受ける範囲。
関連項目の発見時：関連性が重要な場合に限り、項目 ID と関連の種類。
質問／ブロッカー：不足している事実や判断の内容、そのために作業が止まる理由、安全な場合は推奨する既定の対応。
検証結果：実施したチェックとその合否。
引き継ぎ：変更された動作、検証結果、コミット／ブランチ／PR／デプロイ、ステータス、残っているリスク。
失敗時：完了できない理由、根拠、次の担当者／対応。

Scout のノートは、Scout の項目またはプロジェクトで別の言語が明示的に使われていない限り、デフォルトでロシア語で記述してください。ノートは、チャットやコードを読まずに理解できるよう、マネージャー、レビュアー、将来のエンジニアに向けて、簡潔にまとめてください。

3〜6行程度の短い行または箇条書きを推奨します。まず結果を示し、次に根拠、最後にステータス／次のステップを記載してください。長い説明、実装の細部、コマンドの実行記録、スタックトレース、ローカルの非公開パス、秘密情報、憶測、「作業継続中」といった記述は避けてください。ノートが8行を超える場合は、レビューを妨げないため、または失敗を再現するために詳細が必要でない限り、圧縮してください。

デフォルトのノート構成：

Итог: 変更した内容、またはブロックされている内容。
Проверка: すべてのコマンドではなく、直近で得られた最も確かな根拠。
Статус/следующий шаг: in_progress、review、done、changes_requested、具体的なブロッカー、コミット／PR、または次の対応。

技術用語は、レビューや問題の再現に役立つ場合にのみ使用してください。実装を行ごとに説明するのではなく、その結果を説明してください。Scout で詳細な根拠が必要な場合に限り、生ログ、長い一覧、詳細なコマンド出力をアーティファクトまたは PR コメントに記載してください。

Scout の更新で最低限必要なもの：

作業開始前の開始ノート：引き受ける作業、作業場所、最初の検証方法。
必要に応じた根本原因のノート：原因、症状、影響を受ける範囲。
引き継ぎ前の完了またはブロッカーのノート：結果、主要な検証、コミット／ブランチ／PR、ステータス、リスクまたは具体的なブロッカー。

Scout の根拠の確認範囲

質問への回答に必要な範囲で、最も手間のかからない順に Scout の根拠を確認してください。

まず、項目のフィールド、既存のノート、環境メタデータ、セレクター、要素のテキスト／HTML、スクリーンショットのパス、リンクを確認してください。
視覚的な状況が必要な場合は、スクリーンショットまたは直接 URL を開いてください。
操作のタイミング、複数ステップの動作、または項目のフィールド／スクリーンショット／ノートでは得られない根拠が問題となる場合に限り、セッションの録画をダウンロードまたは確認してください。

大きな rrweb／セッション録画ファイルを、デフォルトで最初にダウンロードしないでください。取得する場合は、アーティファクト全体を貼り付けたり読んだりするのではなく、対象となる文字列／イベントを検索してください。

質問ノートの形式：

Вопрос: <конкретное решение или недостающий факт>
Почему важно: <влияние на реализацию или проверку>
Рекомендованный вариант: <безопасное предположение по умолчанию, если оно есть>

完了ノートの形式：

Итог: <что исправлено или что заблокировано>
Проверка: <самые важные checks и результат>
Статус: <new/in_progress/review/done/changes_requested/verified/cancelled>, <commit/PR/branch/deploy>, <риск или "рисков не вижу">

ステータスの扱い

ステータスはエージェントの状態遷移です。感情でステータスを選ばないでください。以下の前提条件に基づいて選択してください。

ステータスの意味：

new：現在エージェントが担当していない項目、または後でトリアージするために再オープンされた項目です。
in_progress：エージェントが項目を担当し、現在、作業、調査、修正を進めているか、担当開始後に直接的なブロッカーの解消を待っている状態です。
review：ローカルでの作業が完了し、対象環境での確認または人間によるレビューが必要な状態、またはレビューがすでに進行中／割り当て済みで、まだ受け入れられていない状態です。最終的なローカル検証が最新であり、焦点を絞ったコミットまたは PR の参照があり、構造化されたエビデンスが存在し、ロシア語での引き継ぎ、レビュー進行中、またはブロッカーに関するメモが存在します。
done：AI／オペレーターによる作業が完了し、人間による受け入れの準備ができている状態です。対象環境での受け入れ、ステージング／本番環境／デプロイ済みの検証、明示的なユーザー受け入れ、またはその他の有効な受け入れレベルがあり、構造化されたエビデンスとロシア語での完了メモが存在します。これは人間による受け入れを伴うクローズではありません。
changes_requested：人間のレビュアーまたは明示的な監査により、期待値と実際の結果を示したうえで現在の結果が却下された状態です。却下の内容自体が不明確でない限り、優先度の高い対応可能な作業として扱います。
verified：人間による受け入れが完了した状態です。ユーザーが明示的に監査を求めた場合、回帰によって再オープンされた場合、または人間が変更を求めた場合を除き、終端状態として扱います。
cancelled：エージェントが、その項目は重複、無効、該当なし、意図的な中止、またはスコープ外であると判断し、その理由を Scout に記録した状態です。

UI のキューとステータスのマッピングには、Queue Triage テーブルを使用してください。キュー専用のワークフローステータスを作り出さないでください。

OpenCode のステータス遷移アルゴリズム：

new -> in_progress：項目が対応可能で、完了を示す証拠がない状態でエージェントが作業を開始する場合は、/items/claim を呼び出します。簡潔な着手メモを追加するか、そのまま残します。内容が不明確な項目、担当が決まる前にブロックされている項目、または他の人が担当している項目は、指示がない限り取得しないでください。完了を目的として new の項目を取得しないでください。合格となる目標の証拠がそろっている場合は、直接 /items/resolve を呼び出します。
changes_requested -> in_progress：差し戻された作業が対応可能で、完了を示す証拠がない状態でエージェントが担当する場合は、対応する却下内容を記した簡潔なメモを追加し、status:"in_progress" を指定して /items/update-status を呼び出します。このステータスでは /items/claim を使用しないでください。完了を目的として changes_requested を in_progress に変更しないでください。合格となる目標の証拠がそろっている場合は、直接 /items/resolve を呼び出します。
in_progress -> review：修正が実装され、最終的なローカルチェックに合格し、該当する場合はブラウザー／実行環境のチェックにも合格し、最終差分のレビューが完了してコミットが存在し、同じ実行内でステージング環境へのデプロイ／検証を安全に完了できない場合にのみ使用します。スキーマで必須のフィールド（environment、scenario、action、visibleResult）、result:"pass"、適切な level、coverage:"item"または正当なクラスタカバレッジ、項目固有のacceptanceScope、および commitShaを含むインラインevidence を指定し、status:"review"で/items/update-statusを呼び出します。実在する PR／MR URL がある場合に限り、トップレベルのmrUrl` を含めます。その後、まだ追加されていない場合は、ロシア語の引き継ぎメモまたはステージング環境でのブロッカーに関するメモを追加します。
new／changes_requested／in_progress／review -> done：正規のデプロイまたは承認された対象環境での検証に合格した場合、あるいはデプロイを伴わない作業で明示的なローカル受け入れが有効な場合に限り、/items/resolve を1回だけ呼び出します。スキーマで必須のフィールド（environment、scenario、action、visibleResult）、kind:"verification"、result:"pass"、level:"staging_acceptance"、"production_acceptance"、"user_acceptance"、または明示的な "local_acceptance"、項目固有の acceptanceScope、該当する場合は URL、関連するデプロイ／コミットの SHA、および観測結果を含むインライン evidence を指定します。対象環境、残るリスク、および次の段階が人による受け入れであることを記したロシア語の完了メモを追加します。ローカルのみの検証が、デプロイ済みまたはユーザーに表示される作業に関する最も強い証拠である場合は、done ではなく review に移行します。
done -> done：/items/resolve の再試行は、完了参照／メモ／証拠に対して冪等です。同じ完了済み項目の完了証拠を修復または追加する場合に限り使用し、人による受け入れの代わりとして使用しないでください。
review -> in_progress：ステージング環境／ユーザー／レビュアーによる検証に失敗した場合、または引き継ぎ／検証の証拠が不完全でエージェントが今すぐ修正する場合は、失敗メモを追加してから、status:"in_progress" を指定して /items/update-status を呼び出します。
done／verified -> changes_requested：明示的な監査／レビューの対象である場合、または人が受け入れ済みの作業の却下を求めた場合にのみ使用します。具体的な summary、expected、actual を指定して /items/request-changes を呼び出します。利用可能な場合は steps と url も追加します。/items/update-status は使用しないでください。
done／verified／cancelled -> new／in_progress：changes_requested が適切なモデルではない明示的な再オープン／監査／リグレッションのワークフローでのみ、/items/reopen を使用します。エージェントがただちに担当する場合に限り status:"in_progress" を指定します。それ以外の場合は status を省略して new として再オープンします。
任意のステータス -> cancelled：項目を実装すべきでない場合にのみ使用します。重複／無効／対象範囲外／再現不可である理由を説明し、該当する場合は関連項目へのリンクを含めたロシア語のメモを追加してから、API の遷移が有効な場合に /items/cancel を呼び出します。

エージェントの必須ルール：

コードを編集したこと、テストが一度通ったこと、またはデプロイに成功したことだけを理由に、review や done にしてはいけません。
デプロイ済みのユーザーに表示される実行時環境がないタスク、またはユーザーが結果を明示的に承認した場合を除き、ローカルの証拠だけで done にしてはいけません。
通常の AI による完了として verified にしてはいけません。明示的な人間による承認の後、またはユーザーから承認操作を実行するよう明示的に指示された場合に限り、/items/verify を使用してください。
安全な標準のステージングデプロイと、項目固有のステージング承認を今すぐ完了できる場合、習慣だけを理由に review で止めてはいけません。
スキーマ必須フィールド（environment、scenario、action、visibleResult）に加え、result、level、coverage、項目固有の acceptanceScope を明記した構造化された証拠なしに、項目を review または done にしてはいけません。可能な限り、ステータス API の呼び出しと同時に evidence を渡してください。
完了への準備段階として /items/claim や /items/update-status を使用してはいけません。完了の証拠がある場合は /items/resolve を一度呼び出し、new、changes_requested、in_progress、review の処理はサーバーに任せてください。
/items/update-status を使って changes_requested にしてはいけません。明示的なレビュー／監査での却下が認められる場合は、期待値と実際の状況を添えて /items/request-changes を使用してください。
必須の前提条件が欠けている場合は、現在の正直なステータスを維持し、ブロッカー／進捗のメモを追加してください。ゲートを満たすために証拠を捏造してはいけません。
1 つの修正で複数の項目を対象とする場合も、各項目固有の承認条件と証拠が満たされた後に限り、各項目を個別に遷移させてください。

Scout のワークフローステータスとして blocked を追加してはいけません。監査における blocked は、承認を安全に確認できなかったことを示す QA／台帳上の結果です。ブロッカーをメモに記録し、項目を現在の正直なステータスに維持するか、明示的な監査での却下が妥当な場合は /items/request-changes を使用してください。

監査件数を広範に報告する場合は、Scout のワークフローステータス（new、in_progress、review、done、changes_requested、verified、cancelled）と、QA の結果ステータス（pass、fail、blocked）を分けてください。これらを 1 つのステータス一覧に混在させてはいけません。

1 つの修正で複数の Scout 項目を対象とする場合：

主項目を更新し、対象範囲と検証の概要を簡潔に記載してください。
関連項目はそれぞれ、主項目と共有ブランチ／PR を参照する短いメモで更新してください。
関連項目は、それぞれの承認条件を確認した後に限り、ステータスを遷移させてください。
無関係な項目や一部しか対象になっていない項目は未完了のままにし、残作業を説明するメモを添えてください。

検証

引き継ぎの前に：

まず、関連する範囲を最も絞ったチェックを実行してください。
AGENTS.md、README、パッケージスクリプト、または CI ドキュメントで必須とされている、リポジトリのチェックを実行してください。
修正前や修正中だけでなく、最後のコード変更後にチェックを再実行してください。
最終差分を確認し、Scout 項目の対象範囲に限定されていることを確かめてください。
フロントエンド／ユーザーに表示される変更については、可能であれば、推測した根本原因だけを確認するのではなく、報告されたユーザージャーニーに沿ってローカルアプリをブラウザーで検証してください。
バックエンド／API の変更については、可能であればテストと、対象を絞った実行時／API チェックで検証してください。
データ／デプロイの変更については、関連する場合、安全なバックアップを確保したうえで、新しい状態の証拠を用いて検証してください。
コミットが完了した後、標準のステージング経路を利用でき、安全な場合は、プッシュしてステージング環境で検証してください。利用できない場合は、不足している経路、アクセス権、安全性の承認、または発生した障害を具体的に記録してください。
チェックを実行できない場合は、その理由と、代わりに使用した証拠を記録してください。

完了の定義

以下のすべてを満たすまでは、項目を完了として提示しないでください。

報告された問題または依頼された改善にエンドツーエンドで対応しているか、正確なブロッカー／質問を Scout に記録していること。
最終差分について、無関係な変更、シークレット、デバッグコード、大規模な書き換え、古い TODO がないか確認していること。
最終編集後に、新たな検証の証拠があること。コマンド、ブラウザでの確認、API の確認、または確認を実行できない理由を記録していること。
フロントエンド、ダッシュボード、ウィジェット、その他ユーザーに見える変更について、可能な場合は報告されたユーザージャーニーまたは受け入れ経路をブラウザで検証していること。UI のバグについて、API／curl のみの証拠では不十分です。
完了したコード変更について、Scout の実行ワークフローまたはリポジトリのポリシーでコミットが必要な場合は、Scout 項目を参照する専用のコミットがあること。それ以外の場合は、コミットを作成しなかった正確な理由を記録していること。
許可されており、リポジトリの安全性に問題がなく、標準的なステージング経路がある場合は、プッシュ、ステージングへのデプロイ、ステージングでの受け入れ確認を完了していること。それ以外の場合は、正確なブロッカーを Scout に記録していること。
Scout に構造化された証拠とロシア語のメモがあり、開始、該当する場合は根本原因、完了またはブロッカー、検証、コミット／ブランチ／PR／デプロイへの参照、ステータス変更、残存リスクを網羅していること。
Scout のステータスが実態を反映していること。人間または監査による却下への対応待ちの場合は changes_requested、作業中または確認待ちでブロックされている場合は in_progress、コミット済みの作業に対象環境または人間によるレビューが必要、またはそのレビュー中の場合は review、AI／オペレーターによる受け入れの証拠があり、人間による受け入れ前の場合のみ done、人間による受け入れ後のみ verified とし、後回しの作業を黙って残さないこと。
許可されたデプロイ、検証用 PTY、Scout のステータス更新、またはキューに入った後続ステップが実行中で、次のステップが可能な間は、最終ユーザー応答を送らないでください。処理が終了するまで続行し、残りの Scout への引き継ぎを完了するか、進行が技術的にブロックされているか安全でない場合に限り、具体的なブロッカーを記録してください。

最終的なユーザー応答は、短く、証拠に基づくものにしてください。

選んだ項目とその理由。
変更内容。
最終変更後に実行した検証。
Scout で行った更新。
作成したコミットと使用した Scout 項目の参照、またはコミットを作成しなかった正確な理由。
プッシュ、デプロイ、ステージング検証の実施状況、またはそれぞれを実行できなかった正確な理由。
未完了の事項と、その正確なブロッカー。残っていない場合は、その旨を明記してください。

Scout API の使用パターン

Authorization: Bearer $SCOUT_API_KEY で認証してください。文書化されていない認証ヘッダーも併せて送信しないでください。上記の Configuration プレフィックスは、コマンドのプロセス内でのみ使用してください。エンドポイントのメソッド、実行時 URL、リクエスト本文、レスポンス形式の唯一の情報源は、ライブの OpenAPI です。

プロジェクトまたは項目への API 呼び出しを行う前に、OpenAPI から Scout API の URL を一度だけ構築してください。OpenAPI のパスキーは servers[0].url からの相対パスです。現在のサーバーパスは通常 /api なので、文書化されたパス /projects/list は実行時 URL $SCOUT_URL/api/projects/list になります。最初に $SCOUT_URL/projects/list を試してから /api 付きで再試行しないでください。その 404 は回避できます。

標準的な Node ヘルパーの形式：

const scoutBase = process.env.SCOUT_URL.replace(/\/$/, '');
const headers = {
  Accept: 'application/json',
  'Content-Type': 'application/json',
  Authorization: `Bearer ${process.env.SCOUT_API_KEY}`,
};

const specRes = await fetch(`${scoutBase}/api/docs/openapi.json`, { headers });
if (!specRes.ok) throw new Error(`openapi ${specRes.status}`);
const spec = await specRes.json();
const apiBasePath = (spec.servers?.[0]?.url || '/api').replace(/\/$/, '');
const apiUrl = (openApiPath) => `${scoutBase}${apiBasePath}${openApiPath.startsWith('/') ? openApiPath : `/${openApiPath}`}`;

async function post(openApiPath, body) {
  const res = await fetch(apiUrl(openApiPath), { method: 'POST', headers, body: JSON.stringify(body) });
  const text = await res.text();
  if (!res.ok) throw new Error(`${openApiPath} ${res.status}: ${text.slice(0, 500)}`);
  return JSON.parse(text).data;
}

このヘルパーには、/projects/list、/items/list、/items/get など、文書化された OpenAPI パスを渡してください。servers[0].url をすでに付加するヘルパーに、/api/projects/list などの実行時パスを渡さないでください。

OpenAPI の検出は、余分な出力を抑え、決定的に行ってください。スキーマ全体、項目の全ペイロード、キューの全ダンプ、長いパス一覧をチャットに出力しないでください。契約に不一致がある場合は、失敗した文書化済みパス、ステータスコード、短いエラー本文のみを出力してください。