spike

spike — ソリューションの実証

運用上の不変条件

• スクラッチ領域の境界：候補ロジック、ハーネス、フィクスチャ、実証用成果物は .agents/scratch/ 内にのみ作成します。本番コードと恒久的なテストには手を加えません。
• 作業ツリーの保全：既存の変更と無関係なスクラッチ成果物を保持します。統合境界は読み取り専用で調査し、実行のために変更が必要な場合は分離したコピーを使用します。
• 問題への忠実性：アサーションは元の問題と受け入れ基準に基づいて設定します。ベースラインと候補の実行で同じアサーションを維持し、分離した機能の実証と本番修正の実証を区別します。
• 方向性の境界：提示されたソリューションの方向性と制約の範囲内で、証拠に基づく有限の代替案を検討します。方向性の変更が必要な場合は、別途判断が必要であることを報告します。探索範囲を黙って広げたり、無理に GREEN にしたりしてはいけません。
• 機密情報の証拠と環境：記録する前にシークレットをマスキングします。シークレットファイル（.env*、*.key、*.pem）は決して調査しません。ハーネスのランナーとスクラッチ用データストアは .agents/environment.md に基づいて設定し、実験は厳密に .agents/scratch/ 内に限定します。

ドメイン別評価基準

入力と実証対象

• 問題または RED のシグナル、候補ソリューション、そして入力または確認済みのコンテキストで定められた制約付きのソリューションの方向性を受け取ります。問題は推測が必要な場合や曖昧な場合があります。利用可能な証拠からテスト可能な基準を導き、前提を記録します。境界が明確であれば、候補が独自に方向性を定めてもかまいません。明示されていないアーキテクチャ上の選択肢は未確定のままにします。
• 関連する統合境界、期待される結果、判明している場合は元の障害メカニズム、実証が必要な主な不確実性を特定します。入力またはコンテキストからテスト基準や許容される方向性を定められない場合は、代替案の検討に進む前に、必要な入力を示して UNRESOLVED と報告します。
• 修正のアサーションは元の症状に基づいて定義します。新機能の場合は、必須の動作をアサーションにします。正確性、互換性、並行性、同等性、リソースの測定は、その要件に関係する場合にのみ選択します。

ベースラインと候補の実験

• 可能な場合はベースラインで RED を確認し、続いて同じアサーションを候補に対して実行して GREEN を目指します。元の障害を再現できない場合は、欠陥修正に関する主張にその不足を明記します。
• 実際の境界、または忠実に分離したコピーを使用して検証します。モックの境界と省略した統合動作を明示します。モックのみでの GREEN が実証するのはモデル化された範囲に限られ、未検証の本番修正を確認するものではありません。
• 重要な入力、環境、状態遷移、境界ケースを保ちながら、ハーネスを最小限にします。サニタイズ済みフィクスチャとコマンドを使って、セットアップと実行を再現可能にします。
• 間欠的または並行的な動作については、可能な限りシード、クロック、インターリーブを制御します。1 回の成功だけを受け入れず、失敗と反復回数を記録します。
• 各失敗を根拠として、方向性の範囲内にある代替案を選びます。完全な実証、許容される関連代替案の検討完了、ランタイムまたはアクセスのブロッカー、あるいは方向性の変更が必要だという証拠が得られた時点で終了します。

結論の状態

• CONFIRMED：実証的な証拠が、明示されたテスト範囲で元の基準を満たしています。欠陥修正を確認するには、忠実なベースラインでの失敗と、同じアサーションで候補が GREEN になることも必要です。
• INFERRED：推論または部分的な実行が候補を裏付けていますが、元の基準を実証的に完全には証明できていません。具体的に何が不足しているかを明記します。
• REJECTED：関連する許容済み代替案を検討し尽くした後、範囲を限定した実験で、候補または方向性が基準を満たさないことが示されています。結論はテストした代替案と条件に限定し、全般的に不可能だとは主張しません。
• UNRESOLVED：方向性、基準、ランタイム、アクセス、その他の前提条件が不足しているため、根拠のある実証または棄却ができません。

正式な出力仕様

証明を再現し、適用可能性を評価するのに十分な根拠を含む、簡潔なレポートを1つ作成します。有用な場合は、サニタイズしたスクリプトとログをスクラッチ領域に保持し、決定的な観察結果をレポートにまとめます。

# Solution-Proof Report: <problem / candidate>

State: <CONFIRMED | INFERRED | REJECTED | UNRESOLVED>
Conclusion: <what the candidate demonstrably solves, may solve, failed to solve, or leaves unknown>
Original criteria: <problem-grounded assertions>
Direction and constraints: <supplied boundary and assumptions>
Integration seam: <module/interface/runtime boundary>
Evidence: <scratch paths and commands; baseline and candidate results for the same assertion>
Conditions and proof limits: <tested environment, substitutions, missing proof, applicability limits>

## Alternatives *(omit if none were explored)*
<candidate -> decisive observation -> retained or eliminated within direction>

振り分け

• 証明済みの解決策が受け入れられ、ファイルへの影響を計画する必要がある → （/changeset 経由）。
• 要件が不足しているため、有意義な証明を行えない → （/clarify 経由）。
• 成功するには、提示された方針を変更する必要がある → （/architect-decision 経由）。
• ツールチェーンが不足している、またはテスト用データストアの準備ができていないため、実験を実行できない → （/env-doctor 経由）。

実行プロトコル

1. 問題、候補、方針、制約、接合点を明確にします。元の主張と、それを証明するために必要な根拠を定義します。
2. 最小限のスクラッチ実験を構築し、可能であればベースラインを実行します。同じ基準と関連する境界条件で候補を検証します。
3. 失敗を調査し、証明、範囲を定めた探索の終了、阻害要因、または方針の変更が必要となるまで、方針の範囲内で根拠に基づく代替案を検討します。検討を打ち切る判断の根拠となった観察結果を記録します。
4. 状態、条件、限界を含む解決策の証明レポートを提示します。本番ファイルが変更されていないことを確認し、有用なサニタイズ済みの証明用アーティファクトを保持します。