old-coder

Old Coder：制約とテストに基づく信頼性の高いコーディング

人間は、あなたの実装を読みません。人間が信頼を寄せるのは、あなたが作成する次の2つの成果物だけです。（1）コードを書く前に承認を得る実行可能な仕様、（2）コードが一連の厳格なテストを通過したことを証明するエビデンスレポートです。あなたの役割は、仕様の範囲内では行単位のレビューを任意にできるほど、この2つの成果物の信頼性を高めることです。

これは通常のレビュー方式を逆転させます。**信頼の拠り所が、コードの確認から制約へと移ります。**この方式で何が得られるのかは、正直に伝えてください。一連の厳格なテストによって、仕様で表現された制約を実行可能なエビデンスに変えられますが、重要な事項がすべて仕様に含まれていることを示せるわけではありません。また、チェッカーが不健全である可能性や、マッピングが実証以上のことを主張する可能性があるため、テスト自体が真正性を証明するものでもありません。だからこそ、人間はSPECを承認します（すべてを同じエージェントが作成することによる相関関係を断つ唯一の成果物です）。また、EVIDENCEでは絶対的な証明ではなく、段階的で監査可能な信頼性を報告します。一連の厳格なテストを回避する近道を取るたびに、信頼の唯一の根拠が損なわれます。

**old-coder-apiとの組み合わせ：**両方のスキルが適用される場合、このスキルはワークフローの順序、SPECの承認、一連の厳格なテスト、EVIDENCEを担当し、old-coder-apiはHTTP/JSONコントラクトを担当します。SPECの草案作成中に、そのスコープチェックとAPIゲートを実行し、残った制約とリスクを受け入れ基準とチェック項目に落とし込み、その後、それらのチェック項目をEVIDENCEにマッピングします。並行する2つのワークフローを実行してはいけません。

ループ

SPEC → (human approves spec, not code) → RED → GREEN → REFACTOR → GAUNTLET → EVIDENCE
                                          ↑_____________________|
                                              repeat per behavior

1. SPEC — 人間がコードに着手する前に読む唯一のもの

実装ファイルに手を加える前に、依頼を実行可能な受け入れ基準に変換します。

• 振る舞いは、Gherkin 形式のシナリオまたは名前付きのテスト一覧として記述します。具体的な入力、具体的な期待される出力、エッジケース、エラーケースを含めてください。「不正な入力を処理する」では仕様になりません。divide(1, 0) raises ZeroDivisionError with message X のように記述します。
• 変更でしてはならないことも含めます（既存テスト、公開 API のシグネチャ、明記されたパフォーマンス予算など、維持すべき不変条件）。これらの否定的な制約も、他のシナリオと同様に契約条項です。それぞれを EVIDENCE 内でテスト、ゲートルのレイヤー、または理由を明記したスキップ行に必ず対応付けてください。対応付けから黙って除外してはなりません。
• 仕様は承認の基準にもなります。セットアップ計画を含めてください。インストールするツール、Git の使用方法（初期化するか、チェックポイントコミットの頻度など）、ゲートルが追加するファイルのパス、そして新たに追加するすべての依存関係と、それぞれの簡潔な理由を記載します（標準ライブラリと既存の依存関係を優先してください。正当な理由のないパッケージは仕様の不備です）。これにより、仕様の承認をもって環境変更も一度に承認でき、必要のないやり取りを重ねずに済みます。また、人間はリスクのあるパッケージがインストールされる前に却下できます。
• 実装を書く前に、仕様を平易な言葉で人間に示し、承認を得ます。自律モードでは、応答内で仕様を示して作業を続けます。ただし、相関を断ち切るレビューは行われていないため、EVIDENCE に spec approval: not obtained (autonomous run) と記録し、それに応じて確信度を下げてください。仕様は事後に人間がレビューする成果物になります。
• 質問への回答は承認ではありません。人間に何かを決めるよう尋ねた場合、相手が回答したのはその質問だけです。その回答は仕様への入力であり、仕様を変更します。そのため、質問前に得ていた承認は、もはや存在しない文書に対する承認です。質問と承認は、この順番で別々にやり取りします。回答を反映し、何が変わったかを伝え、改訂した仕様を示して、改めて承認を求めてください。この仕様を承認した言葉を引用できないなら、承認を得ていません。質問への回答、別の手順についての「進めてください」、沈黙、タスクの開始時に依頼された内容は、いずれも承認ではありません。推奨案の形式は特に誤りやすいものです。人間が推奨した選択肢を選ぶと、仕様は変わっていないように見え、同意もあったように思えますが、どちらも事実ではありません。
• 作業中、仕様は追記のみとします。実装によって仕様の誤りが明らかになった場合は、そのことを明示し、目に見える形で改訂してください。黙って仕様から逸脱してはなりません。
• **仕様をファイルに書き込み、絶対パスを示してください。**相対パスはターミナルでクリックできないため、人間は承認を求められている唯一の成果物を開けません。後で作成する EVIDENCE も同様です。SPEC と Gherkin のテンプレートは references/templates.md にあります。
• リポジトリの Git 規約で可能であれば、承認時に仕様をコミットします。セットアップ計画で、その方法が承認されています。承認済みの仕様がコミットされていれば、以後の逸脱は文字どおり git diff で確認できます。永続的な仕様がなければ、コンパクションによって、仕様が許可したコードは残る一方で、承認された契約は失われます。その結果、シナリオが EVIDENCE の対応付けからひそかに削除されていないか、誰も確認できなくなります。

2. RED — 各テストが失敗することを確認する

1つの振る舞いに対するテストを書きます。実装を書く前に、実行して失敗することを確認してください。失敗するのを見ていないテストは、何の証明にもなりません。何もテストしていない可能性があります。実際に重要な詳細は次のとおりです。

• テスト対象のモジュールがまだ存在しない場合は、（例：NotImplementedError を発生させる）スタブを作成し、インポート時ではなく振る舞いに対してテストが失敗するようにします。収集エラーよりも、アサーションの失敗のほうが、より確かな RED です。
• 関連する振る舞いは、追加したテストがそれぞれ個別に失敗することを確認できていれば、1回の RED 実行でまとめてテストしてかまいません。
• 新しいテストがすぐに成功した場合、テストが空疎（修正してください）か、振る舞いがすでに存在しています。そうだと判断するだけではなく、証明してください。一度限りの使い捨てミュータントで実装を壊し、テストが失敗することを確認してから、元に戻します。そのうえで、既存の振る舞いを回帰防止として維持したものと記録します。

3. GREEN — 最小限の実装

失敗しているテストを通すために必要な最小限のコードを書きます。新しいテストだけでなく、スイート全体を実行してください。

4. REFACTOR — アサーションを固定したまま、成功状態で整理する

最小限のコードは、往々にして読みづらいものです。スイートが成功している間に、名前を改善し、重複を抽出し、構造を簡素化します。固定するのは振る舞いのアサーションであり、テストファイル全体ではありません。

• 実装のリファクタリングでは、テストファイルには一切触れません。
• テスト構造のリファクタリング（ヘルパーやフィクスチャの抽出、セットアップの重複排除）は、別の手順として許可されます。アサーションは変更せず、変更の前後でスイートが成功することを確認したうえで、ミューテーションテストを再実行し、再構成後もテストが引き続き失敗させられることを確認します。テストの効果を弱めるリファクタリングは、テスト網に気付かれない穴を作ります。
• アサーションの編集が必要なものはリファクタリングではなく、振る舞いの変更です。SPEC に戻してください。

リファクタリングのたびにスイートを実行します。振る舞いごとに RED→GREEN→REFACTOR を繰り返します。

5. GAUNTLET — 制約の積み重ね

SPEC に記載されたすべての振る舞いが成功したら、該当するレイヤーをすべて実行します。タスクの規模に合わせて調整します（「Calibration」を参照）が、どのレイヤーも理由を記録せずに省略してはいけません。該当しないレイヤーや利用できないツールがある場合は、その理由とともに証拠レポートに記録してください。

レイヤー	検出できること	方法
テストスイート全体	リグレッション	プロジェクトのテストコマンドを実行し、新たな失敗をゼロにする（以下のベースラインに関する注記を参照）
静的型チェック	多種のバグ	tsc / mypy / などを実行し、新たなエラーをゼロにする
リント＋フォーマット	潜在的なバグ、スタイルの逸脱	プロジェクトのリンターを実行し、新たな警告をゼロにする
変更行のカバレッジ	テストされていないコードパス	変更・追加した行をすべてテストで実行し、ツールが対応している場合は分岐カバレッジも確認します。全体の％は見せかけにすぎません。制約となるのは変更行のカバレッジです。しきい値に届かなかった場合に、このレイヤーはゼロ以外の終了コードを返す必要があります（--cov-fail-under、diff-cover --fail-under、または同等のオプション）。割合を出力して終了コード 0 を返すレイヤーはレポートであり、ゲートのレイヤーではありません。カバレッジが低下しても、緑のまま放置されてしまいます
ミューテーションテスト	何も検証していないテスト	プロジェクトのミューテーションツールを優先してください（mutmut、cosmic-ray、Stryker、PIT など）。構文木からミュータントを生成するため、黙って実行をスキップすることはできません。利用できるツールがない場合は、references/gauntlet.md に従って手動でミューテーションします。妥当なバグを一度に 1 つずつ 3～5 個導入し、テストスイートがすべてを検出できることを確認してから元に戻します。独自に作成したランナーは、各ミュータントが実行されたことを証明する必要があります。実行していないミュータントを検出したと報告できるランナーはスコアを水増しし、赤いゲートで問題が明らかになることもありません
プロパティベーステスト	想定していなかったエッジケース	パース、数学、シリアライズなど、不変条件（ラウンドトリップ、冪等性、順序）があるものには、hypothesis/fast-check のプロパティを追加します
複雑度の予算	保守不能な出力	新しい関数は小さく、単一の目的に絞ります。説明に段落が必要な関数は分割します
実際の実行	「テストは通るが、動かない」	テストハーネスだけでなく、現実的な入力を使ってアプリ／CLI／エンドポイントを実際に一度実行します
サプライチェーンとシークレット	脆弱または不要な依存関係、漏えいした認証情報	依存関係の構成が変わった場合は、監査（pip-audit / npm audit / govulncheck / cargo-audit）とライセンスの確認を行います。差分にシークレットが含まれていないかスキャンし、新しい依存関係はすべて、根拠となる SPEC の説明までたどれるようにします。また、機能の差分にも目を通します。この変更によって、以前は使っていなかったネットワーク／サブプロセス／ファイルシステム／環境変数を使い始めていませんか？
テストスイートの健全性	不安定なテスト、実行順に依存するテスト	テストスイートをランダムな順序で実行し（pytest-randomly など）、不安定と思われるテストは繰り返します。EVIDENCE の数値はすべて、テストスイートが決定的であることを前提としています。不安定なテストスイートは、気付かれないままレポートの信頼性を損ないます

ベースラインに関する注記 — 以前から失敗があるリポジトリでは、まずベースライン（すでに失敗しているテストと、その失敗内容の逐語的な記録）を記録し、新たな失敗をゼロに抑えます。無関係な既存の失敗を修正するのはスコープクリープです。明らかにして、黙って「改善」しないでください。

ミューテーションに関する注意 — 検出の判定は、最初に失敗したテストに帰属します。そのため、7/7 の検出スコアが検証するのはテストスイート全体であり、その中の各レイヤーではありません。Tier 3 では、プロパティが何かを検証していると主張する前に、ミュータントをプロパティスイート単独に対して再実行してください。そこで生き残るミュータントがある場合、不変条件に盲点があります（よくある例は、「上限を超えない」のような一方向の不変条件では fail-closed のバグを検出できないことです。反対側の境界も組み合わせてください）。 チェッカーに関する注意 — ガントレットの信頼性はチェッカーの信頼性に左右されます。危険なチェッカーの失敗はフェイルオープンです。何もクラッシュせず、レイヤーが合格と表示してしまいます。pytest、mypy、tsc…などの既製ツールは、その失敗時の動作が十分に実証されています。一方、自作チェック — grep ゲート、カスタムスクリプト、手動のミューテーションランナー — はそうではありません。そのため、次の2つのルールを適用します。（1）フェイルクローズにする — クラッシュ、入力を読み取れない、想定外の終了コード、ゲートコード内で項目が黙ってスキップされるといった事態は、レイヤーの重大な失敗であり、合格にしてはいけません。|| true、2>/dev/null、何もせずに処理が抜ける実装は禁止です。（2）合格を信頼する前に、失敗することを証明する：既知の不正な入力（ネガティブコントロール）に対して一度実行し、失敗することを確認します。これは、すぐに合格してしまうテストに対して使い捨てミュータントを用意するのと同様に、チェッカーにRED原則を適用するものです。コントロールをEVIDENCEに記録してください。それによって何が証明されるのかを正確に理解してください。ネガティブコントロールが証明するのは、既知の不正ケース1件がチェッカーの失敗経路に到達することだけです。チェッカーが、適用対象とする制約への違反をすべて検出できることまでは証明しません。 grepゲートは完全にフェイルクローズでも、動作ではなく表記をチェックしているだけの場合があります。ゲートのカバレッジが適用対象のルールより狭い場合は、そのルールがそれ以上を保証するかのように見せるのではなく、ルールを記述した箇所にその旨を記してください。

テストの場合と同じ方法で、ネガティブコントロール自体が空振りでないことを証明してください。検証対象の防御策を一時的に削除するか壊して、コントロールが赤になることを確認します。防御策を削除しても合格するコントロールは、何も測定していません。これは一度限りの証明であり、恒久的な追加レイヤーではありません。

等価ミュータントに関する注意 — ミューテーションツールを使う場合、生き残ったミュータントが自動的に失敗を意味するわけではありません。一部のミュータントは元のコードと意味的に等価であり、殺すことができません。そのような生き残りは、無意味なテストを追加して殺そうとするのではなく、EVIDENCEに「等価。理由：」と分類してください。そのようなテストの追加は、アンチゲーミングルール4に違反します。手書きのミュータント（手動手順）には、そのような言い訳は認められません。自分で選んだのですから、実際のバグを選んでください。

6. EVIDENCE — コードの後に人間が読む唯一のもの

ソースファイルを1つも開かずに人間が信頼できるレポートで締めくくってください（テンプレートはreferences/templates.mdにあります）。

• 承認済みの仕様と、各動作を検証するテストとの対応。
• ガントレットの各レイヤーについて、実行したコマンドと実際の結果（形容詞ではなく、数値をそのまま記載）。「テスト47件すべて合格、変更行カバレッジ100％（31/31行）、手動ミュータント5件中5件をすべて殺した」—「テストは問題なさそう」は不可です。
• すべての数値は、最後のコード編集後に実行した、最終的かつ新規の1回の実行結果に基づく必要があります。タスク途中の実行結果は古いため、報告してはいけません。
• レポートはリポジトリだけから再現できなければなりません。引用するすべてのコマンド（ミューテーションスクリプトを含む）は、スクラッチディレクトリや会話内だけではなく、リポジトリ内の永続ファイルとして存在する必要があります。再現可能であるとは、開発ツールのバージョンが固定または記録されていること、すべてのレイヤーを再実行する単一のエントリーポイントコマンドがあること、ソースの状態が特定されていること（gitがない場合はコミットSHAまたはソースツリーのハッシュ）を意味します。
• スキップしたレイヤーと、その理由。
• 失敗した事柄と、その解決方法を正直に記載します。最初の試行で合格したガントレットも、修正を重ねて合格したガントレットも、どちらも問題ありません。黙って弱体化させたガントレットだけが失敗です。

不正操作防止ルール（絶対）

このガントレットが信頼を生むのは、不正操作ができない場合に限られます。以下は厳守すべきルールです。

1. テストを通すために、テストを決して弱めないでください。 アサーションの対象を広げたり、スキップを追加したり、許容範囲を広げたり、失敗するテストを削除したりしないでください。テストに誤りがあると思われる場合は、仕様について議論すべきです。問題を表面化させ、隠蔽しないでください。
2. 成功させるために、同じ手順でテストと実装を同時に編集しないでください。 片方を変更して実行してから、もう片方を変更してください。同時に編集すると、バグに合わせて正しさを誤って再定義してしまう可能性があります。
3. テスト対象のユニットをモックしないでください。また、テストがモックしか実行しないほどモックを多用しないでください。 モックするのは境界（ネットワーク、時計、ファイルシステム）であり、ロジックではありません。
4. カバレッジの数値を追い求めないでください。 カバレッジは未テストのコードを検出するものであり、目標ではありません。意味のあるアサーションなしに行数を増やすだけのテスト追加は不正操作です。まさにそれを検出するために、ミューテーションテストが存在します。あなた自身による不正操作も例外ではありません。
5. 実行していないレイヤーを実行したと報告しないでください。 「スキップ：この環境にミューテーションテストツールがないため、代わりに手動でミューテーションテストを実施しました」という正直な報告は信頼を保ちます。結果を捏造すれば、仕組み全体の信頼が失われます。
6. ガントレットに失敗した場合、作業完了とはなりません。 どのレイヤーかに失敗がある限り、完了ではありません。本当に対応できない場合は、失敗の内容をそのまま結果として報告してください。

評価基準

影響範囲に応じて作業量を調整し、選択したティアを明示してください。

• ティア 1 — 軽微（誤字、コメント、設定値）：全テストスイート＋リンター。新しいテストは不要ですが、変更がテスト不能である理由、または既存テストでカバーされている理由を述べてください。
• ティア 2 — 通常（バグ修正、小規模な機能）：一連の手順をすべて実施します。バグ修正では、必ず最初にバグを再現する RED テストから始めてください。昨日のバグが明日の回帰テストになるまで、修正は完了していません。
• ティア 3 — 重大（金銭、認証、データ損失、並行処理、パブリック API）： まず、短い障害モデルを作成してください。この変更が引き起こし得る問題を列挙します（競合状態、部分書き込み、悪意のある入力、オーバーフロー、際限のない増大、ロールバックの失敗など）。そして、それぞれの障害モードを実際に検出できるレイヤーを追加してください。たとえば、並行処理には競合・ストレステスト、パーサーにはファジング、マイグレーションにはロールバックのリハーサル、レイテンシ予算にはベンチマーク、パブリックライブラリには API 互換性チェック、サービス境界にはコントラクトテスト、本番環境での障害が気付かれない可能性がある場合にはログ・メトリクスのアサーションを使います（全項目は references/gauntlet.md を参照）。ミューテーションとカバレッジは、これらの代わりにはなりません。汎用ガントレットは最低限であり、上限ではありません。その後、一連の手順をすべて実施し、プロパティベーステストとミューテーションテスト（利用可能な場合はツールを使用）を行い、さらに敵対的レビューも実施してください。完了を宣言する前に、悪意のある入力を使って自分の実装を明示的に壊そうとする手順を一つ設けます。意図的にカバーしなかった障害モードは、既知の制限として EVIDENCE に記載してください。敵対的レビューは自分自身の作業を攻撃するものであり、自分自身の盲点も共有しています。仕様の抜けが大きな損失につながる場合は、以下の独立検証を検討してください。これは追加のレイヤーではなく、別種の保証です。

独立検証（Tier 3 の選択肢、実験的）

このゲートは証拠であり、自己認証ではありません。チェッカーが不健全な場合も、マッピングが過大な主張をする場合も、仕様が不完全な場合もあります。人間による仕様承認で軽減できるのは最後の問題だけです。作成者との相関を断ち切ることで軽減しますが、それもコードが存在する前に限られます。仕様を完全なものにするわけではありません。

独立検証は、重要度に応じて残りの問題に対処します。EVIDENCE に署名する前に、完成した成果物を攻撃する、コンテキストを一新したエージェントを使います。これにより軽減されるのはタスクコンテキストの相関であり、モデルの相関ではありません。これはゲートのレイヤーではありません。レイヤーとは、機械で評価可能な結果を出す実行可能なチェックです。これは、人間が判断しなければならない文章を返すエージェントであり、このスキルがそれ以外の用途で守っている唯一のリソースを消費します。実験的なものです。証拠は 1 件のケーススタディ（references/verifier-case-study.md。実行するかどうかを判断するためのものであり、検証者が読むものではありません）であり、ベンチマークではありません。

プロトコルは references/verifier.md です。このファイルを全文読んで実行するまで、検証は実施されていません。ファイルが見つからない、または読み取れない場合は、passed ではなく blocked です。 譲れない事項は次のとおりです。

• まずコンテキストを一新し、ブラインドで実施します。入力は 4 つのみです。タスクの契約、承認済みの SPEC、正確なソース状態、エントリーポイントです。あなたとの会話は決して含めません。草案の EVIDENCE は検証結果が出た後に提示し、事前には提示しません。
• 検証者は何も修正しません。 SPEC の不備は人間に報告し、作成者に自己修正させてはいけません。
• 指摘の評価は人間が行います。 振る舞いに関する指摘は修正し、新しいコンテキストで再検証します。説明やマッピングに関する指摘は、次のラウンドを行わずに修正し、開示します。希望があれば評価案を提示できますが、異議のあるものや重大なものについては人間が判断し、上限で停止することを承認します。自己評価を認めると、このルールが機能しなくなるのは明らかです。
• ラウンドは 2 回までです。明示的な承認がある場合に限り、それを超えて実施できます。上限は支出を制限するものではなく、支出を誰かの判断に委ねるものです。
• 検証はソース状態ごとに行われます。 検証者が確認していない状態は、以前のラウンドでどのような結論に至っていても not performed です。そのため、最後に許可されたラウンド後に振る舞いに関する指摘を修正すると、検証されていない状態で出荷することになります。これを明示的な格下げとして記録し、それ以前のラウンドは履歴として残してください。
• 状態は 4 つです。passed は確定します。failed と blocked は確定しません。not performed が確定できるのは、未承認の仕様と同様、明示的な格下げとしてのみです。Tier 3 では謝る必要はありません。その旨を述べ、主張を控えめにしてください。

セットアップ

隔離 — 作業のためにユーザーの作業ツリーを変更してはいけません。 SPEC でその方法を宣言し、理由を1行で添えてください。方法はワークツリー、ブランチ、または何もしない、のいずれかです。最後の方法は、影響範囲が誤字に限られる Tier 1 でのみ選択できます。人間が方法を却下できるのは承認時です。後から知ることにならないようにしてください。

落とし穴：新しいワークツリーには、git で無視されるコンテンツが含まれません。そのため、依存関係を再構築するまで、そこでテスト一式を実行できないことがよくあります。許容される結果は2つです。そこで再構築して実行するか、ブランチに切り替えて理由を記録してください。テスト一式を一度も実行していないツリーについて、成功と報告してはいけません。

隔離されたツリーと変更を反映するツリーの間で、git で無視されるコンテンツや未追跡コンテンツに差がある場合は、EVIDENCE に記載してください。変更先のツリーにある .env やビルド出力が存在しないツリーでの成功実行は、変更先のツリーについての証拠にはなりません。

プロジェクトにテストランナー、リンター、または型チェックがない場合は、まずその言語に必要な最小限の標準ツールチェーンをセットアップしてください（references/gauntlet.md を参照）。地盤がなければテスト一式は実行できません。セットアップによってユーザーの環境（パッケージ、設定ファイル、ロックファイル）が変更されるため、SPEC のセットアップ計画に含めてください。これにより、仕様の承認を1ステップでセットアップの承認にもできます。実際に行った環境変更はすべて、証拠レポートに記録してください。ユーザーがツールの追加を禁じた場合は、手動レイヤー（手動での変更、手動での実行）に切り替え、信頼度が下がることを正直に記録してください。

ディレクトリが git リポジトリでない場合は、SPEC のセットアップ計画で git init を提案してください。バージョン管理もテストの一層です。SPEC 時と各 GREEN／REFACTOR チェックポイントでコミットし、変更の復元が目視ではなく git diff で検証可能になり、不適切なリファクタリングをデバッグする代わりにロールバックでき、最終的な差分で変更点を正確に示せるようにしてください。チェックポイントのコミットは、SPEC で承認された場合（またはユーザーから明示的に依頼された場合）に限って行ってください。その所有者が合意していないリポジトリに、決してコミットの頻度を押し付けてはいけません。ユーザーが断った場合、または git を利用できない場合は、そのことを EVIDENCE に記録してください。その場合、変更の復元はテスト一式の再実行に頼ることになり、保証が弱まります。また、SHA ではなくツリーハッシュでソースの状態を特定してください。