音声原稿 03-c：継続的インテグレーション
このパートでは、人がいないパイプラインで、入力待ちを起こさず、機械が読める指摘を、前回と重複させずに出すことを扱います。ノートの、パイプライン、一回の実行で渡すもの、書いた会話でレビューしない、と同じ中身です。
対話のクロードコードは、確認の質問で止まります。ジョブに人はいません。ピー、またはプリント、は、プロンプトを処理し、結果を標準出力へ書き、入力を待たずに終了します。環境変数でヘッドレスにする、という名前の仕組みや、バッチというフラグは、この起動の代わりになりません。標準入力を捨てるだけでも、プログラムが質問を出して待つのを止められません。止めるのは、ピーです。
指摘を、プルリクエストの行へ機械で付けるなら、文章ではなく構造です。出力形式をジェーソンにし、ジェーソンスキーマで、ファイル、行、重大度、本文の欄を固定します。自由文は、投稿スクリプトが行番号を読み違えます。
パイプラインから見た基準は、クロードエムディーに置きます。価値のあるテストとは何か、どのフィクスチャが使えるか、どのスタイルは指摘しないか。ここが空だと、体裁だけのテストと、スタイルの指摘が増えます。既存のテストファイルも文脈に渡し、すでに覆っているケースを再提案させません。
プロンプトに渡すのは、差分、基準のファイルの場所、前回の指摘、既存テストのパスです。リポジトリ全体を無関係に読ませると、指摘がスタイルへ逃げます。スキーマには、既出の指摘と同じなら重複である、という欄を入れます。投稿スクリプトは、その欄が真の行を落とします。前回の指摘をプロンプトに入れ忘れると、この欄は常に偽になり、同じ行に同じコメントが二度付きます。新しいコミットのあとに再レビューするときは、前回の指摘を含め、新規か未対応だけを報告させます。
コードを書いた会話に、その差分のレビューを頼むと、生成のときの理由が履歴に残っています。モデルはその理由を疑いにくいです。思考を長くさせる指示を同じ会話に足しても、自分の前提は残ります。レビューは、差分と基準だけを渡した別の実行にします。別の実行のほうが、細かい矛盾に気づきます。
パイプラインでこれを実現するには、生成のジョブとレビューのジョブを、別プロセスにします。生成のログをレビューのプロンプトへ貼ると、別プロセスでも、自己レビューと同じ履歴を再構成してしまいます。レビューへ渡すのは、差分と基準だけです。
共有したい最小の並びを、確認します。ルートのクロードエムディーには、言語、テストの実行コマンド、指摘しないスタイル、だけを書きます。ルール配下のテストのファイルは、テストの拡張子にだけ読み、APIのファイルは、APIの木にだけ読みます。コマンド配下のレビューは、全員のレビューです。スキル配下の移行手順は、フォークと、読み取り中心のツール制限を持ちます。秘密はどこにも書きません。外部サーバーの設定には、環境変数の参照だけを書きます。
このパートの判断は、こうです。パイプラインの停止はピーです。機械が読む指摘は、ジェーソンとスキーマです。再レビューは、新規と未対応だけです。書いた会話ではレビューせず、生成のログをレビューへ貼り戻しません。基準は、共有の指示ファイルに置きます。
ジョブが止まるパターンを、三つ潰します。一つ目は、人が確認に答える前提の起動です。ピーを付けると、結果を出して終了します。二つ目は、ヘッドレスという名前の環境変数や、バッチというフラグで同じことができる、と思い込むことです。この停止の代わりにはなりません。三つ目は、標準入力を捨てることです。プログラムは質問を出して、捨てられた入力を待ち続けます。止めるのは起動のフラグであって、入力の捨て方ではありません。
投稿までのデータの形です。プロンプトには、差分、基準のファイル、前回の指摘の構造、既存テストのパスを書きます。リポジトリ全体を無関係に読ませると、指摘は一行の長さへ逃げます。基準そのもの、つまり価値のあるテスト、使えるフィクスチャ、指摘しないスタイルは、共有の指示ファイルに置きます。ここが空だと、体裁だけのテストが増えます。既存テストを渡さないと、すでに覆っているケースを再提案します。
スキーマの欄は、ファイル、行、重大度、本文、そして既出なら重複、です。投稿スクリプトは、重複が真の行をスキップします。前回の指摘を入れ忘れると、重複は常に偽になり、同じ行に同じコメントが二度付きます。再レビューは、新規か未対応だけを報告させます。
書いた会話でレビューしない、をジョブで実現します。生成とレビューは別プロセスです。生成のログをレビューのプロンプトへ貼ると、別プロセスでも、この境界でよい、という生成時の理由が履歴として戻ります。モデルはその理由を擁護します。思考を長くする指定も、同じ履歴の上では前提を消しません。レビューへ渡すのは、差分と基準だけです。この分離は、ファイル単位と横断を分けるのと同じ理由で、一度に持つ前提を減らします。
再レビューで同じコメントが二度付くときの切り分けです。スキーマに重複の欄が無いなら、投稿スクリプトはスキップできません。欄はあるのに常に偽なら、前回の指摘をプロンプトへ入れ忘っています。欄が真なのに投稿されるなら、スクリプトが欄を見ていません。三つは別の場所です。プロンプトを厚くしても、欄が無ければ機械は重複を判断できません。
生成ジョブの標準出力を、レビュージョブの入力にそのまま渡すのも、自己レビューの再構成です。渡してよいのは差分そのもの、つまり変更されたファイルと行です。生成時の説明、なぜこうしたか、は渡しません。基準のファイルは、レビュー側が共有の指示から読みます。既存テストのパスを省くと、すでに覆っているケースが新しい指摘として付きます。
短いエコーで、起動の違いを確認します。同じプロンプトを対話で実行すると、確認で止まります。ピーを付けると、結果を一行出してプロセスが終わります。標準入力を捨てただけの起動は、対話と同じように待ちます。この差が見えれば、パイプラインの停止はフラグだと確認できます。環境変数の名前を変えても、この差は出ません。
機械が読む指摘の欄が自由文だと、投稿スクリプトは行番号を、本文の中の数字と取り違えます。ファイル、行、重大度、本文をスキーマで固定し、自由文の前置きを許しません。ジェーソンだけ、と文章で頼むのは、前の章と同じで、前置きと末尾の読点でパーサが死にます。パイプラインでは、出力形式とスキーマを起動時に指定します。基準の文章は指示ファイルに置き、プロンプトには差分と前回の指摘だけを足します。
書いたのと同じ会話に、思考を長くする指定だけを足しても、レビューは分離されません。生成のとき、この境界でよい、と書いた文が履歴に残っているからです。見直せ、と言われると、その文を擁護します。別プロセスにして、渡すものを差分と基準だけに限って、初めて前提が消えます。前回の指摘をその別プロセスへ含めるのは、重複を避けるためであって、生成の理由を渡すためではありません。新規か未対応だけを報告させ、既出は重複の欄で落とします。
価値のあるテストとは何かが指示ファイルに無いと、パイプラインは体裁だけのテストを提案します。どのスタイルは指摘しないか、どのフィクスチャが使えるか、も同じファイルに置きます。プロンプトの中だけで基準を毎回書くと、ジョブごとに基準がずれ、同じ行が日によって指摘されたりされなかったりします。
再レビューの入力から、生成時の説明を抜く理由を、もう一度置きます。なぜこの境界でよいか、がプロンプトに残っていると、別プロセスでもその理由を擁護します。渡すのは差分、基準、前回の指摘、既存テストのパスです。重複の欄が真の行は投稿しません。ピーが無い起動は、人がいないジョブで確認を待ち続けます。標準入力を捨てても、その待ちは止まりません。