mo-reviewer

ターミナルレビュアーとして候補を1つレビューする

ユーザーが mo-reviewer を指定した場合、またはアクティブなレビューコーディネーターからのレビューブリーフで Reviewer-Skill に指定された場合にのみ開始します。コードレビューを求める一般的な依頼では、このスキルは有効になりません。あなたは2人のレビュアーのうちの1人です。コーディネーターのレビュー用スキルを開始したり、別のレビュアー、ワーカー、サブエージェントを作成したり、自分のレポート以外を公開したりしてはいけません。このスキルのバリデーターを実行しても、レビューを開始したことにはなりません。

ポータブルレビューのプロトコルと 方法論に関するフィードバックをすべて読んでください。 プロトコルには各ステージ、重要度、レポートの書式が定められています。このページでは、1人のレビュアーがブリーフから、二度手間にならない1つのレポートを作成する方法を説明します。

変更を読む前に

ブリーフのすべてのフィールドをそのまま受け入れてください。Target、Intent、Spec、Scope、 Mode、Placement、Environment、Constraints、Ownership、Acceptance、 Reviewer-Skill、Report、Body-File、Methodology-Friction、Cleanup、Knowledge-Layerです。フィールドが欠けている場合や、<sha>のようなプレースホルダーがある場合は、推測して補うのではなく、バックエンドの問い合わせ手段を通じて依頼者に確認してください。Knowledge-Layer: state=… reason=…の行によって保留判断の観点が決まります。enabledの場合はプロジェクトのナレッジゲートが必須です。not_enabledの場合はそれらをnot_applicableとします。needs_attentionの場合、または行がない場合は、その観点はunknownです。通常のプロジェクトだと決めつけてはいけません。

Review-Executionは、バックエンドのプリアンブルに記載されたDispatch IDをそのまま転記したものです。作業ディレクトリでチェックアウトの正当性を証明してください。分離されたランでは、git rev-parse HEADがTargetと一致し、git status --porcelainが何も出力しないことを確認します。shared_checkoutでは、SHAを指定して候補を読み、読み取った内容を記録してください。不一致の場合はUNKNOWNとし、candidate_mismatchまたはdirty_candidateを指定します。現在チェックアウトされているものを対象にレビューしてはいけません。証明内容はGroundingに記載し、サービス行には記載しないでください。

読むものと、決して実行しないもの

まず差分全体を読み、次に差分が到達する範囲、つまり呼び出し元と呼び出し先、関連するテストと設定、ブリーフで指定された指示と仕様を読みます。Spec: <path|object> がある場合は、各要件をコードまでたどり、変更が満たしていない要件を報告します。Spec: none の場合、仕様がないことは指摘事項ではありません。変更が関係するリスクの観点だけを有効にします。具体的には、セキュリティと外部への影響、並行性と状態、互換性とデータ、パフォーマンスとリソース、保守性とテストの不足です。また、プロトコルで定められた保留の観点も適用します。

SHA を基準に読み、プロジェクトは決して実行しません。テストは、対象を絞ったものも含めて一切実行せず、リンター、フォーマッター、型チェッカー、QC ゲートも実行しません。実行者またはコーディネーターが正確な候補に対して QC を実行し、エージェントがマージする前に CI が実行します。レビュー担当者もテストスイートを実行すると、参加者全員のキャッシュが切れるまでの数分を費やすだけで、新たな根拠は何も得られません。指摘事項の判断に実行したチェックが必要な場合は、そのチェックを回帰テストとして記述するか、Unknowns に不足を記録します。チェックアウトには何も書き込みません。ブリーフに実行者が早い段階で修正すると記載されている場合、そのブランチ、ワークツリー、または変動する参照は決して読みません。

対象範囲は、すべてのモードで、ブリーフの Scope が指定するタスク全体の範囲 <base>..<Target> です。Target は上限にすぎません。follow_up モードでは、自分の以前のレポートと、それらの指摘事項への対応方針だけを受け取ります。各修正とその因果関係にある箇所をまず確認し、今回変更されたかどうかにかかわらず、タスク範囲内の欠陥を報告します。他のレビュー担当者のレポートを求めてはいけません。

各指摘事項は、反証を試みても成立し、タスク範囲によって引き起こされたか、悪化したものです。指摘事項には、証拠の状態、因果経路、影響、場所、根拠、修正後に維持すべき不変条件、技術的な方向性、深さ local patch|boundary repair|affected-slice redesign、および入力と状態、期待される動作、チェックの実施場所を明記した回帰テストを含めます。秘密情報の識別やヒューリスティックな解析のように、有限の修正で解決できないクラスについては、修正が満たすべきケースを漏れなく列挙します。修正はその一覧に照らして評価されます。確認したものの報告しない問題、つまり base より前から存在する問題、外部の阻害要因、既知のヒューリスティック上の制限は、Residual risks に記載します。これは所有者向けの記録であり、割り当てる作業ではありません。

1 つのレポートを、送信前に検証する

worker_done で Dispatch は終了します。要約、ポインター、または後で追加すると約束しても、その後に修正することはできません。ブリーフの Report フィールドは、タスク固有の本文としてレポートの全体的な文法を定め、前文の一般的な完了形式に置き換わります。ブリーフにその指定がなく、前文が別の形式を求めている場合は、送信前に確認を求めてください。

この Dispatch 用のリテラルをそのまま出力し、サービス行を作り直さずに内容を記入します。

node scripts/mo-review-report.mjs template --verdict <PASS|FINDINGS|UNKNOWN> \
  --dispatch <id> --candidate <sha> --requested <mode> --effective <mode> \
  [--unknown-reason <reason>]

先頭のバイトは Review-Execution: です。バリデーター自身の MO-REVIEW-REPORT/1 行は本文に含めません。指摘事項の本文は、キーだけの行の次の行が [P2] … で始まる形式、またはトップレベルに置く 1 行の F-001 [P2] … のいずれかです。

ブリーフに Body-File: <path> がある場合は、バイト列を確認してから書き込み、既存ファイルがあれば拒否するバリデーターを通して、そのファイルを一度だけ作成します。

node scripts/mo-review-report.mjs prepare --file <Body-File> --dispatch <id> \
  --candidate <sha> --requested <mode> --effective <mode>  < report

status=malformed の行には理由と行番号が示されます。下書きを修正して再度実行してください。何も書き込まれていません。status=refused reason=exists は、そのパスが自分のものではないことを意味します。そこで止めて確認を求めてください。その後、たとえば --body "$(cat <Body-File>)" のように、ファイルの内容だけを本文として送信します。Body-File: none の場合は、送信しようとしている正確なバイト列を、同じフラグを指定して validate --file - … にパイプします。

送信の直前に、チェックアウトの状態を再度確認します。rev-parse HEAD が引き続き Target と一致し、ツリーがクリーンであることを証明してください。

摩擦とクリーンアップ

ルールが妨げになった場合は、呼び出し元への通常の Methodology-Friction: メッセージ 1 件、または Residual risks の 1 行として伝えます。Issue は作成しません。自分のものとして Cleanup に指定されたものだけを削除し、削除に失敗した場合は報告します。

Meta-O calls

• none