hillclimbing

ヒルクライミング

1. 最初の変更の前にチェックを修正する

• 基準を合否が判定できるチェックにし、作業の進捗に応じて変化するスコアを設定します。
• 次の内容をそのまま記録します。提示された目標と基準、チェックとそのしきい値、ガードレール（現在合格しており、引き続き合格する必要があるチェック）、予算（ユーザーが提示した場合のみ）。

チェック可能な基準にできない場合は、今、一度だけ質問し、チェック案を提案します。 これが予定されている唯一の質問です。

ベースラインとして、チェックとガードレールを実行します。チェックがすでに合格している場合は、その旨を報告して停止します。記録と反復ログは作業ツリーの外にある進捗ファイルに保存し、コンテキストがリセットされた後に読み直します。

2. 改善する

各反復で、次のことを行います。

• 直前の実行結果に基づいて、スコアの変化を追跡できる程度に小さな変更を一つ加えます。
• チェックとガードレールを再実行します。
• スコアが改善し、すべてのガードレールに合格した場合に限り、その変更を維持します。それ以外の場合は、正確に元に戻します。
• 変更、スコア、維持または取り消しを一行で記録します。
• 最良の状態を復元できるようにしておきます。
• 反復の合間に、続けるかどうかを尋ねてはいけません。

スコアにノイズがある場合は、測定ごとに複数回実行し、中央値を比較します。

3回の反復で改善がなければ、失敗した試みに共通する前提を明示し、それを捨てるために、より大きな変更を行います。取り消した変更を再試行してはいけません。停滞しているからといって停止してはいけません。

3. 目標をすり替えない

基準を満たすために、次のことをしてはいけません。

• テスト、アサーション、しきい値、チェックを編集、スキップ、削除、または緩和する
• 期待される出力をハードコードするなど、チェックの入力に特別な処理を加える
• エラーを握りつぶしたり、フックを迂回したりするなど、チェックの報告内容を抑制する
• チェックの対象を一部や小さなサンプルに絞る

誤ったチェック（古いバグをアサートするテスト）はユーザーにとってのブロッカーであり、変更してはいけません。

4. 次のいずれかに該当する場合のみ停止する

1. 達成。 最終状態から、すべてのチェックとガードレールを改めて完全に実行します。すべて合格します。以前の合格、一部のみの実行、部分的な実行は達成と見なしません。
2. 予算を使い切った。 ここで勝手に設定した予算ではなく、ユーザーが提示した予算です。
3. ユーザーの対応が必要。 次のステップに、許可、認証情報、確認が必要な破壊的または外部に影響する操作、相反する基準間の選択、または誤ったチェックの修正が必要な場合です。または、基準に到達できないことが証明できる場合です。その制約と、それを証明する測定結果または情報源を明示します。「難しい」ことや「何度も失敗した」ことは証明になりません。ブロッカーに依存しないステップは、すべて先に完了させます。

最終報告は、必要に応じて調整します。

Status: met | budget spent | blocked: <what is needed from the user>
Score: <baseline> -> <final> (threshold <threshold>)
Check: <command>
<its output from the final run>
Iterations: <n> (<kept> kept, <reverted> reverted)