spike

spike — 解決策の実証

運用上の不変条件

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

ドメイン評価基準

入力と実証対象

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

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

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

結論の状態

• 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 経由）。

実行プロトコル

1. 問題、候補、方針、制約、接点を明確にします。元の主張と、それを証明するために必要な証拠を定義します。
2. 最小限のスクラッチ実験を作成し、可能であればベースラインを実行します。同じ基準と関連する境界条件で候補を検証します。
3. 失敗を調査し、証明、範囲を限定した調査の尽了、阻害要因、または方針変更の必要性に至るまで、方針に沿った根拠のある代替案を検討します。停止を正当化する所見を記録します。
4. 状態、条件、限界を示した解決策の証明レポートを提示します。本番ファイルが変更されていないことを確認し、役立つサニタイズ済みの証明アーティファクトを保持します。