crucible-emergent-resurrection

創発的復活 — ネガティブナレッジアーカイブ

自己進化型スキル：失敗の分類にモードが含まれていない場合、または復活トリガーの種類が再発した場合は、該当するセクションを更新し、references/evolution-log.md に追記してください。先送りしないでください。

失敗した仮説は無駄ではありません。以下のようなネガティブナレッジです。

1. 調査の境界を記録します
2. 既知の行き止まりを再調査するのを防ぎます
3. 条件が変われば再び有効になる可能性があります

このスキルは、「反復プロセスを通じて創発する可能性がある限り、試したことを何も排除しない」という遺伝的進化の仕組みです。

---

失敗したアイデアを単に削除してはいけない理由

このセッションでは、成果が得られなかったキャンペーンが17件蓄積されました。ネガティブナレッジとして記録しなければ、次のようなことが起こります。

• 今後のセッションで同じ行き止まりを再調査する（計算リソースの浪費）
• 失敗のたびに得られたメタレッスンを失う（帰無仮説の誤り、スケーリングの誤り、スコープの誤り）
• 再試行するのに十分なほど条件が変化したことを検出できない

失敗した試行は、再実行するより保存するほうが低コストです。

---

失敗モードの分類

失敗したキャンペーンは、それぞれ1つ以上のモードに当てはまります。分類によって復活の条件が決まります。

失敗モード	説明	復活トリガー
null-insignificant	シグナルは存在するが、ノイズフロアを下回っている	ノイズフロアが低下する（バックテストの延長、データの改善、コストの削減）
overfit-in-sample	ISでは強いが、OOSでは成績が悪い	別のデータレジームでクロスバリデーションに成功する、またはアーキテクチャを再設計する
wrong-null-applied	シグナルは正しいが、誤った帰無仮説の種類によって失敗した	正しい帰無仮説の手法が見つかる（Skill B §5 の直交カスケードを参照）
cross-asset-failed	ある資産では機能するが、ほかの資産では機能しない	別の資産で同じ構成の試行に合格する、またはレジーム検出器によって資産ごとの選択が可能になる
regime-conditional	全期間では失敗するが、特定のレジームにエッジが集中している	因果的なウォークフォワードによるレジーム分類が行われ、レジーム内で学習・テストの両方がプラスとなり、帰無仮説の z>3 を満たす
label-leaked	特徴量またはラベルが因果性に違反している	因果性を再検証し（bars[:i] を排他的に使用）、再テストに合格する
agent-overestimation	エージェントの推定が実際より大きい	外部オラクルまたはバー単位のリプレイにより、縮小版の妥当性が確認される
grid-degenerate	パラメーターグリッドが狭すぎる	グリッドを広げる、または感度分析によって未使用の次元が明らかになる
dormant-low-precedence	有効だが優先度が低い	優先度の高いフロンティアが解消されたら、再検討する
falsified-comprehensive	徹底的にテスト済み。提示された前提のもとでは実現不可能	前提が変わる（新しい資産クラス、新しい市場微細構造、レジームシフト）

各アーカイブファイルには、これらのうち1つ以上のタグを付けます。

---

アーカイブの構造

plugins/crucible/skills/d-emergent-resurrection/references/
├── archive/
│   ├── <YYYY-MM-DD>-<slug>.md          Dormant/failed campaign record
│   └── ...
├── falsified/
│   └── <YYYY-MM-DD>-<slug>.md          Permanently falsified (highest bar for resurrection)
└── exhumation-log.jsonl                 Append-only: when ideas moved, why

違いは次のとおりです。

• archive/ = 休眠中であり、終了したわけではありません。適切な条件が整うのを待っています。
• falsified/ = 明確な前提のもとで徹底的にテスト済みです。復活には前提の変更が必要です。

---

アーカイブファイルのテンプレート

失敗したアイデアをアーカイブに移す際は、次のフロントマター構造を使用してください。

---
id: "UNIQUE-ID"
title: "Short descriptive title"
status: "dormant"                       # or "falsified"
failure_mode: ["null-insignificant"]    # list; can be multiple
confidence: 0.95                         # how sure we are it's dead NOW
date_dormant: YYYY-MM-DD

verdict: |
  One-paragraph summary of what was tested and why it failed.

linked_ledger_entries:
  - "FINDING-ID-IN-EVOLUTION-JSONL"

linked_audits:
  - "findings/evolution/audits/YYYY-MM-DD-slug/verdict.md"

resurrect_if:
  - condition: "noise_floor_drops"
    trigger_metric: "trade_level_volatility"
    threshold: "< 1.2 bps (was 2.1 bps at dormancy)"
    requires: "6+ month new backtest reducing noise > 30%"

  - condition: "new_asset_regime"
    trigger_metric: "asset_correlation_cluster"
    threshold: "Jaccard(newasset_patterns, eur_patterns) > 0.65"
    requires: "Trial on new asset with fold-shuffle p < 0.05"

whats_blocked:
  - "List of specific reasons it was shelved"

next_agent_checklist:
  - [ ] If noise_floor drops > 30%: re-run config on latest data
  - [ ] Do NOT assume dead — it's 'not now, but perhaps next regime'
---

# Title

<detailed description of why it failed, what was tested, what would be needed to resurrect>

---

3 層の掘り起こしプロセス

復活は意図的に行います。自動で復活させてはいけません。

レイヤー 1 — 自律的なフラグ付け：定期的に（cron ジョブやセッション開始時のチェックなどで）、archive/* をスキャンし、resurrect_if の条件が現在満たされている可能性があるファイルを探します。CANDIDATE_FOR_RESURRECTION_<date> のタグを付けます。これはフラグ付けのみで、復活させることはありません。

レイヤー 2 — エージェントによるレビュー：次回の調査セッションまたは自律型エージェントが、タグ付けされた候補をレビューします。試験対象を 1 つ選びます（過剰な試行錯誤を防ぐため）。シグナルが本当に再出現したか確認するため、1～2 回のフォールドを実行します。次のいずれかを行います。

• アクティブなキャンペーンに昇格させます（status: "active"、新しい監査フォルダー）
• アーカイブファイルのフロントマターを更新します：「 時点では誤検知。条件は満たされたように見えたが、再試行は失敗」

レイヤー 3 — 人間による承認：復活させたものを本番環境にデプロイする前（または初回の再試行を超えるリソースを割り当てる前）に、人間が掘り起こしレポートをレビューします。条件の変化がデータのアーティファクトではなく、実際のものであることを確認します。

---

アーカイブするタイミング（トリガー）

調査セッション中に、次の場合は archive/ に移動します。

• シリアルゲートの失敗によってシグナルが消滅した場合（Skill B §2、Gate C — 回復不能なゲート）
• シャッフル帰無検定で明確に棄却された場合（z < 1、p > 0.9）
• 20 以上のパラメーターの組み合わせがすべて失敗した場合 → 各組み合わせではなく、アプローチ全体をアーカイブします
• クロスアセットの Gate D が失敗した場合 → 「普遍的」な解釈をアーカイブし、アセット固有のものは適用範囲を絞ったライブ版として残します（Skill C §3 を参照）

アーカイブ ≠ 沈黙です。ファイルを書き込み、exhumation-log.jsonl に追記します。

{
  "date": "YYYY-MM-DD",
  "action": "archive",
  "id": "...",
  "reason": "...",
  "from_audit": "..."
}

---

アーカイブしない場合

• 発見がすべてのゲートを通過したものの、経済性が控えめな場合 — これは live-limited-economics であり、休止状態ではありません。アクティブな状態を維持し、アンサンブルの組み合わせを探します
• 発見が 1 つのゲートで部分的に失敗した場合 — Skill C §3 を参照してください（適用範囲を狭めるのであり、打ち切るのではありません）
• キャンペーンで使用した手法が無効な結果を出した場合 — アーカイブするのは特定の仮説のみで、手法自体はアーカイブしません
• キャンペーンの途中でユーザーの関心が薄れた場合 — これは失敗モードではありません。別の場所で paused としてマークします

---

集団レベルの復活シグナル

個々のファイルの resurrect_if に加えて、集団レベルの条件にも注意します。

• 複数の失敗したキャンペーンが同じ失敗モードを共有している → 共通の原因は対処可能な可能性があります（例：5 件すべてで誤った帰無タイプを使用した → 新しい帰無仮説を考案 → 5 件すべてを復活させる）
• 新しい手法やテクノロジーが登場した → 古い手法での過去の失敗が覆る可能性があります
• アセットのマイクロストラクチャが変化した → アセット固有の失敗が覆る可能性があります

---

台帳との連携

findings/evolution/evolution.jsonl のエントリーに dormant_refs フィールドを追加します。

{
  "id": "FINDING-ID",
  "status": "null",
  "dormant_refs": [
    {
      "archive_file": "plugins/crucible/skills/d-emergent-resurrection/references/archive/<slug>.md",
      "failure_mode": ["null-insignificant"],
      "resurrect_conditions": ["noise_floor_drops", "new_asset_regime"]
    }
  ]
}

双方向に連携します。台帳 → アーカイブファイル、アーカイブファイル → 台帳。

---

現在のアーカイブ（シード状態）

セッション ca9d7ffa-ef5a-41d0-94c8-56f113a132f2 では、次の結果が得られました。

• 17 件の帰無キャンペーン → それぞれにアーカイブファイルが必要です（シード作成状態：アーカイブファイルはまだバックフィルされていません。個々のキャンペーンの判定を扱う際に作成してください）
• 1 件の肯定的な発見（NGRAM3FU-STRADDLE-001-FULL-STACK） → アクティブな状態を維持し、アーカイブしません

17 件のアーカイブエントリーのバックフィルは今後のタスクです。初期状態では、各キャンペーンの判定がレビューされ、アーカイブに書き込まれるまで、references/archive/ は意図的に空のままです。

---

実行後の振り返り

このスキルを実行した後：

1. 失敗したアイデアのアーカイブは問題なく行われましたか？ファイルの情報が少なすぎたり、詳しすぎたりした場合は、上記のテンプレートを更新してください。
2. resurrect_if: の条件は発火しましたか（レイヤー 1）？適切に具体的でしたか、それとも曖昧すぎましたか？調整してください。
3. 分類にない新しい失敗モードがありましたか？項目を追加し、references/evolution-log.md に記録してください。
4. 以前にアーカイブしたアイデアが正常に復活しましたか？掘り起こしの内容を exhumation-log.jsonl に記録し、機能した条件パターンも記してください — これはメタ知識です。