evomath-tao

EvoMath（Tao スタイル）

EvoMath は、コンテスト数学形式の推論のための軽量な証明ワークフローです。その目的は、厳密な証明、検証済みの反例、有用な部分結果、または明確な引き継ぎを提示することです。プロセスは小規模に保ち、デフォルトで重い監査パイプラインを実行しないでください。

方法論の基盤 — Terence Tao の研究数学の実践

このスキルは、Terence Tao の研究数学への取り組み方を実践できる形にします。

1. まず小さなケースを計算する（Newton より先に Kepler）— 理論に手を伸ばす前に、データから直感を養います。
2. 深く掘り下げる前に、標準的な道具を幅広く試す — ほとんどの難問は標準的な手法で解けます。そうでない少数の問題も、いくつかの手法が失敗して初めて、そのことが明らかになります。
3. 厳密さと直感を両立させる（ポスト厳密数学）— 直感を信頼しつつ、すべての段階を検証します。「正しそうだ」は仮説であって、証明ではありません。
4. 行き詰まったら細分化する — 独立して検証できる主張に分解します。証明済み／予想／未解決を明確に整理した見取り図は、洗練されていても不確かな説明より優れています。
5. 証明できていないことについて誠実でいる — PROVED / VERIFIED_NUMERICALLY / CONJECTURED / HANDED_OFF を区別します。行き詰まったときは、具体的な不足箇所を明示します。
6. それぞれの結果から再利用可能な知見を抽出する — 問題を解くたびに、うまくいった方法を戦略として、失敗した方法を名前の付いたパターンとしてまとめます。数学的成熟とは、こうしたメタ的な知見の積み重ねです。

以下の各フェーズは、これらの原則の1つ以上を具体的に実践できる形にしたものです。

運用ルール

• ステップ間の引き継ぎには Markdown のメモを使います。スクリプトが明示的に要求しない限り、JSON/YAML は必要ありません。
• 状態は簡潔に保ちます。計画、検証済みの主張、失敗した試み、最終監査のみを残します。長い失敗の導出を後続のプロンプトに渡さないでください。
• 1つの長い導出より、互いに独立した少数の証明の試みを優先します。
• 数値検証は証明の段階ではありません（数学オリンピックのルール）。n=1..100 で主張を確認して反例が見つからなくても、それを PROVED とすることはできません。このような証拠に付けられる最も強いラベルは VERIFIED_NUMERICALLY です。
• 厳密な算術は反証に使えますが、近似数値は示唆を与えるにすぎません。
• 証明を最終版とするのは、整えた証明に対する敵対的な検証を終えた後だけです。
• ごまかすより、確信度を適切に調整して棄権する — 検証を繰り返し失敗したら、それを認めます。部分結果を返し、解決していない不足箇所を明示します（数学オリンピックのルール）。不足箇所を曖昧にしたまま PROVED とするより、構造化された行き詰まりの報告を添えて最終ステータスを HANDED_OFF とするほうが常に望ましいです。
• すべての最終回答に、final-status: ... という行を明示的に含めます。
• ワークフローの進行には TodoWrite を使います。各ステップを1つの todo とし、対応する .md ファイルがバリデーターに合格するまで、その todo を完了にできません。

ファイルシステムを利用できる場合は、Markdown ワークスペースを作成します（スクリプトのパスはこのスキルのディレクトリからの相対パスです）。

python scripts/evomath_workspace.py init --dir .evomath/current

ファイルシステムを利用できない場合は、同じ Markdown セクションを会話内に記述します。その場合、スクリプトがチェックする必須フィールドを同じように確認して、バリデーターを頭の中で実行します。守るべき規律は同じです。

早期終了

単一の計算、定義の確認、記号操作、または証明が不要な答えのみの依頼には EvoMath を使わないでください。代わりに直接答えます。早期終了では TodoWrite のリストは必要ありません。

文の真偽を左右する重大な曖昧さがある場合は、解く前に具体的な確認質問を1つしてください。

実行プロトコル（TodoWrite + 検証）

早期終了ゲートを通過した問題では、このプロトコルに従います。

1. 5 項目の ToDo リストを作成する

解答に取りかかる前に、次の 5 項目をこの順番で TodoWrite に登録してください。各項目には、主な参照ファイルを記載します。

1. 簡潔に計画する — references/intake-checklist.md を読み、問題の種類の分類、曖昧さへの対処、目標の種類を確認します。
2. 候補を試す — この問題の種類に対する着想が足りない場合は、references/angles-by-type.md を読み、解法のアイデアを確認します。
3. 組み立てる — 書式の規則や LaTeX のテンプレートが必要な場合は、references/output-formats.md を読みます。
4. 監査する — 問題の分類と重大度の規則を確認するため、references/grading-taxonomy.md を読みます。ユーザーが厳密な複数レビュアーによる監査を求めた場合に限り、references/phase-4-audit.md を読みます。
5. 振り返る — 深い振り返りが必要になった場合に限り（下記の「深い振り返りのトリガー」を参照）、references/claim-memory.md を読みます。

2. 各ステップの進め方

各ステップを順番に進めます。

1. 参照ファイルを読むか、出力を作成する前に、ToDo を in_progress にします。

2. そのステップで必要な場合に限り、参照ファイルを読みます。

3. 対応する .md 出力（plan.md、candidates.md、audit.md、final.md の各セクションなど）を作成します。

4. ToDo を完了にする前に、バリデーターを実行します。

   python scripts/evomath_workspace.py validate-phase <N> --dir .evomath/current
   

5. 検証に失敗した場合、ToDo は in_progress のままにします。表示された失敗メッセージをもとに .md ファイルを修正し、バリデーターを再実行します。バリデーターが終了コード 0 で終了するまで、完了にしてはいけません。

3. PROVED ゲート

最終ステータスが PROVED の場合は、さらに次を必ず実行します。

python scripts/evomath_workspace.py validate-proved --dir .evomath/current

これにより、10 項目からなる PROVED 自己チェックリスト（references/output-formats.md を参照）が final.md にあり、すべての項目にチェックが入っていることを確認します。 これに失敗した場合は、最終ステータスを CONJECTURED または HANDED_OFF に引き下げ、解答を修正します。

4. 深い振り返りのトリガー

ステップ 5（振り返り）には、2 つのモードがあります。

• 簡易振り返り（デフォルト）：成功したパターン、避けるべき失敗パターン、メモリに記録したかどうかの 3 行。

• 深い振り返り（次のいずれかに該当する場合に実施）：

  • ステップ 2 で、いずれかの候補に 3 回以上の修正が必要だった
  • 最終修正の前に、ステップ 4 で致命的な欠陥が見つかった
  • どの L2 戦略エントリにもまだない、新たな有力な手法が現れた
  • ユーザーが自己進化または問題をまたいだ学習を明示的に求めた
  • 最終ステータスが HANDED_OFF で、失敗モードが繰り返し発生している

  深い振り返りモードでは、references/claim-memory.md に記載された ESE/IVE プロトコルをすべて実行し、.evomath/session-memory.md の L2/L3 メモリを更新します。

5. ファイルシステムを利用できない場合のフォールバック

スクリプトを実行できない場合も、同じ TodoWrite の手順に従います。

• 5 項目のリストを作成し、順番に進めます。
• 同じ .md セクションを会話内に記載します。
• スクリプトの実行の代わりに、同じ必須フィールドを確認して手動で検証します。

ワークフロー

1. 簡潔に計画する

短い Markdown の計画を作成します。

• 問題の種類：代数、幾何、整数論、組合せ論、解析、その他。
• 目標：証明、反証、例の提示、証明の監査のいずれか。
• 方針：1 文で記述します。
• 小目標：箇条書きで 5 項目以内にします。

「すべてを求めよ」という問題では、次の両方を含めます。

• 存在性・構成
• 不可能性・除外

簡単な問題では、ルートの小目標が 1 つあれば十分です。

2. 候補を試す

モードの振り分け（生成前に決定）：

• Phase 0 で goal = find-numeric-answer の場合（AIME 形式：答えは単一の数値で、証明は不要）→ AIME モード：異なるアプローチ（小規模なケースの列挙、合同式の不変量、代数的な変形、母関数、総当たりコード）を用いて、短い答えの候補を5～7個生成します。候補全体の多数決を取ります。上位2つの候補を元の問題に代入して検証します。残りの証明ワークフローはスキップします。上位2つの候補が一致し、かつ代入による検証に合格した場合に限り、数値の答えを final-status: PROVED とともに出力します。
• それ以外の場合 → 証明モード：以下に進みます。

証明モード — 候補ごとの5ラウンド内部ループ：

各アクティブな下位目標について、真に異なるアプローチを最大4つ試します。 各候補は5ラウンドの内部ミニプロセスを経て生み出されます。一度の生成ではありません。

1. 解く — 推論のみを使って証明を試みます。このラウンドではツールを使用しません （計算機、sympy、Lean、ウェブは禁止）。紙と鉛筆だけで考えます。
2. 自己改善 — 明確になるよう証明の試みを洗練し、明らかな不足を修正します。
3. 自己検証 — 行ごとに確認し、次の点を探します。断定を隠す語（「明らかに」など）、根拠のない入れ替え、仮定の欠落、端点のケースの誤り、隠れた仮定。
4. 修正 — ステップ3で見つかった問題を修正します。
5. 候補が is_sound と自己報告するまで、または候補ごとに最大5回まで、1～4を繰り返します。

各候補の内部ラウンド数を記録し、Phase 4 で自己修正にどれだけ手間がかかったかを確認できるようにします。5ラウンドを要した候補は、1ラウンドで妥当と判断された候補より、確実性が低い可能性が高くなります。

候補を次の Markdown テーブルに記録します。

候補	アイデア	内部ラウンド数	判定	問題点または理由
C1		1–5	妥当 / 要修正 / 不成立

候補の判定基準：

• 妥当：検証済みの主張として使うのに十分です。
• 要修正：有望ですが局所的な手順が不足しています。5ラウンドの内部ループ外で最大2回まで修正します（修正の合計上限は内部5回＋外部2回です）。
• 不成立：誤り、循環論法、弱すぎる、または既知の行き詰まりを繰り返しています。

計算に関する規律（数学オリンピックの VERBATIM ルール）：解くラウンドではツールを呼び出しません。Phase 1（実証）および Phase 5（ディープモード）では計算が許可されますが、Phase 2（解く）では決して許可されません。これにより、「sympy を呼び出したから正しいはず」という儀式的な推論を防ぎます。

候補が妥当な場合は、1段落の証明要約を添えて Proof Artifact / Verified Claims に追加します。アプローチが不成立の場合は、繰り返さないよう Negative Attempts に1行追加します。

問題の種類に対するアイデアが尽きた場合に限り、references/angles-by-type.md を使用します。デフォルトでは読み込みません。

3. 組み立てる

採用した主張を、明快な証明または反証にまとめます。

ルール：

• 元の主張を述べます。
• 最終的な議論のみを提示し、不成立だった試みは省略します。
• 自明でない各手順を、検証済みの主張、定理、構成、または厳密な計算によって正当化します。
• 必要な下位目標が未解決のままなら、証明が完了したふりをせず、部分的な結果または引き継ぎを出力します。

4. 監査

探索メモではなく、整理された証明のみを監査してください。

以下を確認してください。

• 証明が、元の命題を証明しており、より弱い言い換えを証明しているのではないこと。
• すべての場合、境界値、退化ケース、量化子が扱われていること。
• 証明または Proof Artifact での明示的な受容なしに、主張が引用されていないこと。
• 反証で、正確に検証済みの反例が使われていること。

監査では、math-olympiad の 3 つのセーフガードパターンに従います（references/phase-4-audit.md を参照）。

1. 検証者のコンテキスト分離（レビュー前に思考の痕跡を取り除く）。
2. 非対称投票（成立の確認には 4 件の HOLDS、反証には 2 件の HOLE FOUND）。
3. 鳩の巣原理による終了（しきい値に達したらレビュー担当者の起動を停止する）。

PROVED を付与する前に、反例優先ルールと、名前付きパターンのスクリーニング（grading-taxonomy.md の P4 / P5 / P6 / P18 / P40 / P41）を適用してください。

通常の用途では、慎重なローカル監査を 1 回行えば十分です。より重い references/phase-4-audit.md のプロトコルは、ユーザーが厳密な複数レビュアーによる監査を求めた場合、または結果のリスクが高い場合にのみ使用してください。

5. 振り返り

最終回答の後に、短い振り返りメモを追加してください。簡潔にまとめてください。

• 成功したパターンがあれば、そのパターン
• 避けるべき失敗パターン
• メモリを書き込んだかどうか

問題ごとのメモリは、次の問題でリセットされます。問題をまたぐメモリは任意です。ファイルアクセスが可能な場合は、簡潔な戦略や失敗の要約のみを .evomath/session-memory.json に書き込んでください。書き込まなかった場合は、memory-persisted: false と記載してください。

ステータスラベル

次のうち 1 つだけを使用してください。

ステータス	意味
PROVED	元の命題の完全な証明が、セーフガード 1～3 の監査に合格しました。EvoMath が付与する最も強いラベルです。
REFUTED	正確な反例、または矛盾による証明が見つかりました
VERIFIED_NUMERICALLY	有限個の厳密な検査のみを実施しており、一般的な証明はありません。数値的な根拠は証明ではありません。このラベルは、経験的な裏付けを正直に記録するためのものです。
CONJECTURED	強い部分的根拠または部分的な証明はありますが、不完全です
HANDED_OFF	明確に残る課題またはユーザーへの質問を提示して中断しました

すべての最終回答に、この 5 つのラベルのうち、ちょうど 1 つを含めてください。付与条件と昇格ルールについては、references/confidence-rules.md を参照してください。

最終回答の形式

固定スキーマではなく、Markdown を使用してください。

final-status: PROVED

## Result
<answer>

## Proof / Report
<clean proof, refutation, audit report, partial result, or handoff>

## Audit
- audits-run:
- critical-issues:
- remaining-gaps:

## Proof Artifact
- verified claims:
- negative attempts:

## Reflection
- memory-persisted:
- storage-location:
- proposed-memory-updates:

証明監査の依頼では、重要度の高い順に指摘事項を示し、その後に判定と修正案を提示してください。

任意のヘルパー

• scripts/evomath_workspace.py：
  • init 5 つの Markdown 状態ファイルを作成します。
  • check final.md に有効な final-status: 行があることを確認します。
  • validate-phase N ステップ N（1～5）の .md 出力を検証します。対応する todo を完了にする前に使用してください。--strict を追加すると、それ以前のすべてのステップも再検証します。
  • validate-proved 最終ステータスが PROVED の場合、10 項目の Self-Check Checklist がすべてチェック済みであることを確認します。
• references/angles-by-type.md：問題の種類ごとの手法案。
• references/grading-taxonomy.md：監査向けの詳細な欠陥分類。
• references/phase-4-audit.md：より重い独立レビュー用プロトコル。
• references/output-formats.md：任意の Markdown / LaTeX 書式の詳細と PROVED Self-Check Checklist のテンプレート。
• references/claim-memory.md：3 層のメモリアーキテクチャと ESE / IVE の振り返りプロトコル。深い振り返りモードの場合のみ読み込んでください。
• references/model-tier.md：モデルのティアごとのパラメーター表（Haiku / Sonnet / Opus）。Phase 0 の開始時に一度読み込み、使用中のモデルに応じて K、internal-rounds、audit passes、abstain thresholds を設定してください。