行動の前に計画する

ツールを実行する前に、仕事と完了条件を書きます。チェックリストは意図と進捗を記録し、ツール結果は実際に起きたことを示します。検査失敗後の修正や計画変更も、両者を対応させれば未完了の仕事として見えます。

計画は作業票に似ています。「クリーナーを修正する」と書いてもコードは変わらず、チェックを付けても直りません。要求、実作業、完了の根拠を結び付けるために使います。

計画と実行の関係

各項目は観察できる結果を持つべきです。「名前を処理する」より「現在のクリーナーで選んだ 2 例を実行し、出力を比較する」なら完了を判定できます。

状態は pending、in_progress、completed の 3 つです。選んだタスクを進行中にし、ツールが成果物を変更するか検査結果を返します。計画更新は別操作です。検査失敗は観測であり、自動で修正したり修正タスクを作ったりはしません。

証拠を確認 は完了条件を確かめてから完了にします。失敗時には教材の harness が既知の修正を追加し、実行後に再検査します。試行後に完了 はツールを試した時点で完了にし、失敗結果も残して状態と比較できるようにします。

これは明示的な harness のポリシーです。todo の状態フィールドだけで強制されるものではありません。ツール呼び出しと同じく、効果を生むのはツールを実行する部分で、進捗更新は仕事の記述です。

行動前の計画のステップ

初期設定は 証拠を確認 と 内部の空白も含む。目標は名前の前後の空白を除き、内部の空白を残し、使用例を追加することです。クリーナーと使用例はどちらもまだありません。

完了条件を書く

最初の計画は 3 件の pending です。

まだツールも成果物もありません。実装の保存と動作の検証は別項目なので、t1 完了は正しさの証明ではありません。

草稿を保存してから計画を更新

harness は t1 を有効にし、用意した草稿のリビジョン 1 を保存します。全 ASCII 空白を取り除く実装です。書き込みのステップでは成果物はありますが、t1 はまだ in_progress。次の結果が保存版を示し、その後の計画更新で完了になります。

続いて t2 を有効にし、リビジョン 1 を検査します。

最初は前後の空白除去、2 番目は内部空白の保持も確かめます。全空白を削除すると前者だけ通ります。プレーヤーは空白を点で描きますが、実際の文字列は通常の空白です。

失敗を受けて計画を変更

検証は未完了です。証拠を使うポリシーは t2 の前に t4 Preserve inner spaces を挿入し、t2 を pending へ戻します。順は t1、t4、t2、t3。既知の仕事が増えたため、完了数は 1/3 から 1/4 になります。完了済み t1 が消えたわけではありません。

この時点で修正は計画にありますが、クリーナーはまだリビジョン 1 で内部空白を消します。リストと作業台を同時に見せるのは、この差を確かめるためです。

t4 を有効にし、前後の ASCII 空白だけを除く修正版 2 を保存します。以前の検査は版 1 に対するものなので stale になります。履歴として有用でも、変更後の成果物を保証しません。保存結果の後で t4 を完了にします。

再検査して残りを閉じる

t2 を再開して版 2 を検査すると、出力は "Ada" と "Ada Lovelace" で、両方成功します。この版の根拠で検証を完了にできます。

最後に t3 が " Ada " -> "Ada" の使用例を保存し、別の更新で完了になります。監査は 4/4 タスクが完了、2/2 検査が成功。ツール呼び出しは草稿保存、初回検査、修正保存、再検査、使用例保存の 5 回です。

全項目の完了が示すこと

全項目完了でも不正解 は、同じ草稿と内部空白の入力を使い、検証前で止まります。失敗後も試行基準のポリシーは t2 を完了にして使用例へ進みます。修正も 2 回目の検査もありません。

最後は 3/3 完了、検査は 1/2 成功で、境界入力の出力は "AdaLovelace" のままです。監査は記録を読むだけで、この不一致を隠して直しません。

簡単な例では通る の入力は " Ada " と " Grace "。草稿が両方通るため、どちらのポリシーも 3 件完了、2 検査成功で終わります。しかし内部空白の要件を試していません。省いた名前についての根拠にはなりません。

この比較はモデルの成功率を測りません。決定的なポリシーが示すのは進捗記録の意味であり、計画の有無によるモデル成功確率ではありません。Claude Agent SDK todo ガイド は構造化された状態更新を説明し、書面 todo なしで多段階作業を追うモデルも扱います。

境界条件

• 失敗後に計画が増える。 分母が 3 から 4 になるのは仕事の発見かもしれません。安定した ID で完了履歴を保ちます。
• 検査後に成果物が変わる。 結果は検査した版に属します。修正名が正しそうでも再検査が必要です。
• 選んだ検査が全成功。 範囲を確認します。単純な名前だけでは内部空白を試せません。
• タスクが広すぎる。 保存と検証に別の証拠が必要なら分けます。そうしないと completed が何を終えたのかを隠します。

よくある間違い

• 計画した操作を実行済みと読む。 成果物や結果を確認します。新しい行はツール効果を持ちません。
• 検査コマンドが返れば検証完了にする。 終わった呼び出しも失敗を報告します。結果を読みます。
• 古い根拠を再利用する。 検査と対象リビジョンを対応させます。
• 書いた計画を成功保証にする。 約束と進捗を見せるだけで、価値は使い方と検査範囲に依存します。

再起動や依存関係をまたぐ仕事はタスクシステムへ進んでください。タスクグラフと永続化は、ローカルの一覧と結果を一致させることとは別の問題です。

試すこと

最初のツールの前 で、計画を書くとどの成果物が変わるか予測し、保存と完了更新へ進みます。失敗後に修正 と 全項目完了でも不正解 は内部空白の例を固定し、完了規則だけを変えて比較します。最後に 簡単な例では通る で、成功した検査が目標全体を覆うかを考えてください。

モデルの簡略化

タスク、草稿、修正は固定データで、モデルが生成・発見したものではありません。ブラウザーが文字列変換と検査をメモリ内で実行します。活動タスク 1 件、既知の修正 1 件、ASCII 空白の 2 例だけです。モデルの計画、ツール障害、並行作業、永続化、自由な入力は省きます。エージェント設計やソフトウェア検証の正式な訓練の代わりではなく、この成功も全名称の正しさの証明ではありません。