result-to-claim

結果から主張への判定ゲート

各レビュー担当者の枠を開始する前に、選択可能なレビュー担当者に従ってください： 呼び出しを解決 → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP） を、正規のヘルパーリゾルバー経由で reviewer_route.py を使って実行し、この 枠のティア、新しいコンテキスト、ソース／画像入力、決定論的なゲートを維持します。 以下の Codex の例／固定指定は backend=codex の場合にのみ適用されます。それ以外のルートでは、 各ルート固有の初回呼び出し／返信の契約を使用します。ルートと実際に返された ID を保存してください。 選択したものを利用できない場合は REVIEW_UNAVAILABLE とします。実際の ファミリー／完了状況／スコープに基づいて受け入れ可否を分類してください。 呼び出し時に指定されたレビュー担当者／モデル／effort の上書き設定は、 レビュー担当者を含む子プロセスに引き継いでください。生成ワーカーは変更しません。

🔒 このスキルを /loop、/schedule、CronCreate でラップしないでください。 このスキルは 判定を伴い、結果が主張を裏付けているかどうかを判断します。この判定を 時刻ベースのタイマーで繰り返しても、新たな情報は得られません（判定が変わるのは 結果が変わったときだけで、時計が進んでも変わりません）。スケジュールすべきなのは、 判定の前にある外部の待機です。つまり、実験が完了したら、このゲートを 一度だけ実行します。詳しくは shared-references/external-cadence.mdを参照してください。

実験によって数値が得られます。このゲートは、その数値が何を意味するかを判断します。利用可能なソースから結果を収集し、Codex に判断を求めたうえで、判定に基づいて自動的に次の処理へ振り分けます。

コンテキスト：$ARGUMENTS

使用するタイミング

• 一連の実験が完了した後（サニティチェックだけでなく、主要な結果が出た後）
• 論文や査読への回答で主張を確定する前
• 結果が曖昧で、客観的なセカンドオピニオンが必要なとき

ワークフロー

ステップ 1：結果を収集する

プロジェクト内で利用可能なあらゆるソースから、実験データを収集します。

1. W&B（推奨）：wandb.Api().run("<entity>/<project>/<run_id>").history() — メトリクス、学習曲線、比較結果
2. EXPERIMENT_LOG.md：ベースラインと判定を含む結果の完全な表
3. EXPERIMENT_TRACKER.md：実験が完了（DONE）したか、まだ実行中かを確認
4. ログファイル：ほかに情報源がない場合は ssh server "tail -100 /path/to/training.log"
5. idea-stage/docs/research_contract.md（レガシー時のフォールバック：docs/research_contract.md）：意図した主張と実験設計

以下の主要情報をまとめます。

• 実施した実験（手法、データセット、設定）
• 主なメトリクスとベースラインとの比較（差分）
• これらの実験で検証することを意図した主張
• 既知の交絡要因や注意点

Step 1.5: 決定論的なエビデンスの事前チェック（Codex の呼び出しを行う前）

特定の数値とソースファイルを引用する各主張について、証拠が存在することを機械的に（モデル呼び出しなしで）検証し、陪審の実行前に捏造された証拠を検出します（shared-references/evidence-precheck.mdを参照）。

1. 主張のリストを作成します。 引用された数値とその結果ファイルから、[{"id", "value", "source"}, ...]を.aris/claims.jsonに書き込みます（sourceはプロジェクトルートからの相対パスで指定する結果ファイル／glob、valueは引用された数値または文字列です）。

2. 事前チェックを実行します。これは提案ではなく、実際の手順です。 以下のブロックを実行します（integration-contract §2のリゾルバー、Policy B：ヘルパーを解決できない場合は警告してスキップし、監査を決してブロックしません）。

# Policy B = warn-and-skip: nothing here may abort the audit. cd is non-fatal, the
# helper run is explicitly non-blocking, no pipefail-fragile pipe.
cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" 2>/dev/null || true
if [ -z "${ARIS_REPO:-}" ] && [ -f .aris/installed-skills.txt ]; then
    ARIS_REPO=$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills.txt 2>/dev/null) || true
fi
if [ -z "${ARIS_REPO:-}" ] && [ -f "$HOME/.aris/repo" ]; then
    ARIS_REPO=$(cat "$HOME/.aris/repo" 2>/dev/null) || true
fi
EVIDENCE_CHECK=".aris/tools/evidence_check.py"
[ -f "$EVIDENCE_CHECK" ] || EVIDENCE_CHECK="tools/evidence_check.py"
[ -f "$EVIDENCE_CHECK" ] || { [ -n "${ARIS_REPO:-}" ] && EVIDENCE_CHECK="$ARIS_REPO/tools/evidence_check.py"; }
[ -f "$EVIDENCE_CHECK" ] || EVIDENCE_CHECK=""

mkdir -p .aris
if [ -n "$EVIDENCE_CHECK" ]; then
    # NB: evidence_check exits 1 when it FINDS hallucinated evidence (value_not_found /
    # path_missing) — that is the useful signal, NOT a failure. So judge success by
    # whether valid JSON was produced, never by exit code. `|| true` keeps set -e calm.
    python3 "$EVIDENCE_CHECK" . --batch .aris/claims.json > .aris/evidence_precheck.json 2>.aris/evidence_precheck.err || true
    if [ -s .aris/evidence_precheck.json ] && python3 -c "import json,sys;json.load(open('.aris/evidence_precheck.json'))" 2>/dev/null; then
        cat .aris/evidence_precheck.json
    else
        echo "WARN: evidence_check produced no valid output (see .aris/evidence_precheck.err);" >&2
        echo "      pre-check skipped (Policy B); the Codex jury still runs." >&2
    fi
else
    echo "WARN: evidence_check.py not resolved at .aris/tools/, tools/, \$ARIS_REPO/tools/, or via ~/.aris/repo." >&2
    echo "      Pre-check skipped (Policy B); the Codex jury still runs. Fix: rerun" >&2
    echo "      bash tools/install_aris.sh, export ARIS_REPO, or copy the helper to tools/." >&2
fi

出力は{"results": [{id, value, source, status, ...}], "summary": {status: n}}で、status ∈ {verified, value_not_found, path_missing, unparseable}となります。

3. ステータスに応じて対応します。 value_not_foundまたはpath_missingが返された主張は、いずれも捏造された証拠です。直ちにclaim_supported: noおよびintegrity_status: evidence_not_foundと記録してください。データに存在しない数値を擁護するためにCodexを呼び出してはいけません。unparseableの主張（使用可能な値／ソースがないもの）は、通常どおり陪審に回します。

4. 主張ごとのステータスをStep 2に引き継ぎます。 .aris/evidence_precheck.jsonから、evidence pre-check: <id> → verified | value_not_found | path_missing | unparseableの表を作成し、Step 2のCodexプロンプトに渡します。これにより、陪審はどの主張に実際に読み取れる証拠があるかを把握できます。事前チェックをスキップした場合（ヘルパーを解決できなかった場合）は、省略せず、その欄にスキップした旨を記載します。

ここでのverifiedが意味するのは、引用された証拠が存在することだけです。その証拠が主張を裏付けるかどうかは、Step 2でCodexの陪審が判断します（決定論的なゲートは結果を左右しますが、無罪を言い渡すものではありません）。

Step 2: Codexによる判定

収集した結果をCodexに送信し、客観的に評価します。Step 1.5の事前チェックを通過した主張のみを含めてください。すでに終端的に却下された（evidence_not_found）主張には決定論的な判定が適用されているため、ここで再審理してはいけません。

まずこのレビュー担当スロットを解決してください。以下はbackend=codexの例です。

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "ultra"}
  prompt: |
    RESULT-TO-CLAIM EVALUATION

    I need you to judge whether experimental results support the intended claim.

    Intended claim: [the claim these experiments test]

    Experiments run:
    [list experiments with method, dataset, metrics]

    Results:
    [paste key numbers, comparison deltas, significance]

    Evidence pre-check (deterministic, from Step 1.5):
    [per-claim: <id> → verified | value_not_found | path_missing.
     A value_not_found/path_missing means the cited number is NOT in its result
     file — treat that claim as having no evidence; do not defend it. `verified`
     means the number exists in the file — YOU still judge whether it supports
     the claim.]

    Baselines:
    [baseline numbers and sources — reproduced or from paper]

    Known caveats:
    [any confounding factors, limited datasets, missing comparisons]

    Please evaluate:
    1. claim_supported: yes | partial | no
    2. what_results_support: what the data actually shows
    3. what_results_dont_support: where the data falls short of the claim
    4. missing_evidence: specific evidence gaps
    5. suggested_claim_revision: if the claim should be strengthened, weakened, or reframed
    6. next_experiments_needed: specific experiments to fill gaps (if any)
    7. confidence: high | medium | low

    Be honest. Do not inflate claims beyond what the data supports.
    A single positive result on one dataset does not support a general claim.

Step 3: 解析と正規化

Codexの応答から構造化フィールドを抽出します。

- claim_supported: yes | partial | no
- what_results_support: "..."
- what_results_dont_support: "..."
- missing_evidence: "..."
- suggested_claim_revision: "..."
- next_experiments_needed: "..."
- confidence: high | medium | low

Step 3.5: 実験の完全性をチェックする（監査が存在する場合）

EXPERIMENT_AUDIT.jsonが存在しない場合は、この手順をスキップしてください。

if EXPERIMENT_AUDIT.json exists:
    read integrity_status from file
    attach to verdict output:
        integrity_status: pass | warn | fail

    if integrity_status == "fail":
        append to verdict: "[INTEGRITY CONCERN] — audit found issues, see EXPERIMENT_AUDIT.md"
        downgrade confidence to "low" regardless of Codex judgment

    if integrity_status == "warn":
        append to verdict: "[INTEGRITY: WARN] — audit flagged potential issues"
else:
    integrity_status = "unavailable"
    verdict is labeled "provisional — no integrity audit run"
    (this does NOT block anything — pipeline continues normally)

完全性プロトコルの詳細はshared-references/experiment-integrity.mdを参照してください。

Step 4: 判定に基づいて振り分ける

no — 主張は裏付けられていません

1. findings.mdの調査結果セクションに事後分析を記録します。
   • 何を検証し、何が失敗したか、その理由に関する仮説
   • 今後の試行に向けた制約（再試行しないこと）
2. CLAUDE.mdのパイプラインステータスを更新します。
3. IDEA_CANDIDATES.mdの次のアイデアに切り替えるか、別のアプローチを試すかを決定します。

partial — 主張は部分的に裏付けられています

1. 裏付けられている内容を反映するように、作業中の主張を更新します。
2. findings.mdに不足している点を記録します。
3. エビデンスの不足を埋めるため、補足実験を計画して実施します。
4. 補足実験の完了後、結果から主張への対応付けを再実行します。
5. 同じ主張でpartialが複数回続く場合 → findings.mdに分析を記録し、主張の範囲を絞るか、別のアイデアに切り替えることを検討します。

yes — 主張は裏付けられています

1. 確認済みの主張をプロジェクトのメモに記録します。
2. アブレーション研究が未完了の場合 → /ablation-plannerを実行します。
3. すべてのエビデンスが揃っている場合 → 論文執筆の準備が整っています。

Step 5: 研究 Wiki を更新する（有効な場合）

research-wiki/ が存在しない場合は、このステップ全体をスキップしてください。

research-wiki/ が存在する場合は、 shared-references/wiki-helper-resolution.md に記載されている標準チェーンに従って $WIKI_SCRIPT を解決してください （バリアント B — 呼び出し元スキル向けの警告してスキップする方式）。以下の判定結果／アイデアの結果ページの編集は生の Markdown を対象とするため、ヘルパーは不要ですが、エッジ、クエリパックの再構築、ログ行の記録にはヘルパーが必要です。このスキルは claim の status フィールドを編集せず、claim ノードも作成しません — claim は /proof-checker が作成し（その証拠の status も設定します）。ここでは実験エッジを追加するだけです。

cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" || exit 1
ARIS_REPO="${ARIS_REPO:-$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills.txt 2>/dev/null)}"
if [ -z "${ARIS_REPO:-}" ] && [ -f "$HOME/.aris/repo" ]; then
  ARIS_REPO=$(cat "$HOME/.aris/repo" 2>/dev/null) || true
fi
WIKI_SCRIPT=".aris/tools/research_wiki.py"
[ -f "$WIKI_SCRIPT" ] || WIKI_SCRIPT="tools/research_wiki.py"
[ -f "$WIKI_SCRIPT" ] || { [ -n "${ARIS_REPO:-}" ] && WIKI_SCRIPT="$ARIS_REPO/tools/research_wiki.py"; }
[ -f "$WIKI_SCRIPT" ] || {
  echo "WARN: research_wiki.py not found; verdict will be reported but wiki edges/query-pack/log will be skipped. Fix: bash tools/install_aris.sh or smart_update.sh (refreshes ~/.aris/repo), export ARIS_REPO, or cp <ARIS-repo>/tools/research_wiki.py tools/." >&2
  WIKI_SCRIPT=""
}

if research-wiki/ exists:
    # 1. Create/refresh the experiment node FIRST (verdict OWNER → --update-on-exist so
    #    a re-judge overwrites the stale verdict). The supports/invalidates edges in #2
    #    point FROM exp:<id>, and add_edge does NOT verify node existence — so GATE those
    #    edges on the experiment node having been born (EXP_NODE_OK), else they'd dangle
    #    (the exact bug this closes). On failure: warn, skip the wiki edges, still report.
    EXP_NODE_OK=0
    if [ -n "$WIKI_SCRIPT" ]; then
      if python3 "$WIKI_SCRIPT" add_experiment research-wiki/ \
           --slug "<exp_id>" --idea "idea:<active_idea>" \
           --verdict "<yes|partial|no>" --confidence "<high|medium|low>" \
           --date "<date>" --hardware "<hw>" --duration "<dur>" \
           --metrics "<key metrics>" --reasoning "<one-line why this verdict>" \
           --provenance "<EXPERIMENT_AUDIT.md / run dir>" --update-on-exist; then
        EXP_NODE_OK=1   # page written + idea--tested_by-->exp edge + index/query_pack rebuilt
      else
        echo "WARN: add_experiment failed for <exp_id>; skipping wiki edges (verdict still reported)." >&2
      fi
    fi

    # 2. Record empirical support as EDGES ONLY — and ONLY when the exp node was born
    #    ([ "$EXP_NODE_OK" = 1 ]), so no edge dangles off a missing node. Never edit the
    #    claim page's `status`: that is the PROOF axis (verified / refuted / unproven /
    #    sound-modulo-imports / drafted / retracted), owned by /proof-checker (the claim
    #    birth point) — "supported"/"invalidated" are NOT valid claim statuses. The claim
    #    target should ALREADY be born by /proof-checker; add_edge does not verify it.
    for each claim resolved by this verdict (only if [ "$EXP_NODE_OK" = 1 ]):
        if verdict == "yes":
            python3 "$WIKI_SCRIPT" add_edge research-wiki/ --from "exp:<id>" --to "claim:<cid>" --type supports --evidence "<metric>"
        elif verdict == "partial":
            python3 "$WIKI_SCRIPT" add_edge research-wiki/ --from "exp:<id>" --to "claim:<cid>" --type supports --evidence "partial: <metric>"
        else:
            python3 "$WIKI_SCRIPT" add_edge research-wiki/ --from "exp:<id>" --to "claim:<cid>" --type invalidates --evidence "<why>"

    # 3. Update idea outcome (raw markdown, helper-free)
    Update research-wiki/ideas/<idea_id>.md:
      - outcome: positive | mixed | negative
      - If negative: fill "Failure / Risk Notes" and "Lessons Learned"
      - If positive: fill "Actual Outcome" and "Reusable Components"

    # 4. Rebuild + log (only if $WIKI_SCRIPT resolved)
    [ -n "$WIKI_SCRIPT" ] && python3 "$WIKI_SCRIPT" rebuild_query_pack research-wiki/
    [ -n "$WIKI_SCRIPT" ] && python3 "$WIKI_SCRIPT" log research-wiki/ "result-to-claim: exp:<id> verdict=<verdict> for idea:<idea_id>"

    # 5. Re-ideation suggestion
    Count failed/partial ideas since last /idea-creator run.
    If >= 3: print "💡 3+ ideas tested since last ideation. Consider re-running /idea-creator — the wiki now knows what doesn't work."

ルール

• 判定者は Codex であり、CC ではありません。 CC は証拠を収集して振り分けを行い、Codex が評価します。これにより、事後的な正当化を防ぎます。
• データが裏付ける範囲を超えて claim を誇張しないでください。Codex が「部分的」と判断した場合、「はい」に格上げしないでください。
• 1 つのデータセットでの肯定的な結果だけでは、一般的な claim は裏付けられません。適用範囲について正直に記述してください。
• confidence が低い場合は、判定を確定できないものとして扱い、claim を確定するのではなく実験を追加してください。
• レビュー担当者が利用できない場合は、安全側に倒して処理を停止してください。 Codex の呼び出しに失敗した場合は、まず shared-references/reviewer-routing.md にある機能フォールバックチェーン（gpt-6-astra+ultra → gpt-6-astra+xhigh、続いてモデル機能フォールバックでは gpt-6.1-sol+xhigh を最初に試し、機能エラーのみを対象とする）を順に確認してください。許可された組み合わせで成功しない場合は、CLAIMS_FROM_RESULTS.md に 1 行目の verdict: REVIEW_UNAVAILABLE のみを記述し（パイプラインの呼び出し元が機械的に確認できるゲートです）、findings.md にも同じ内容を記録して、停止してください — CC が独自に claim を判定することはありません（ループは進行を促すことはできますが、潔白を証明することはできません。acceptance-gate.md を参照）。後続のステップ（Wiki の add_experiment エッジ、ablation-planner、論文の claim）は、Codex の判定がない実行結果を使用してはなりません。例外：決定論的な証拠事前チェック（Step 1.5）では、捏造された証拠について claim を claim_supported: no として最終判定できます — 決定論的な却下にレビュー担当者は不要であり、SUPPORTIVE または曖昧な結果にのみレビュー担当者が必要です。
• 結果にかかわらず、判定とその理由を必ず findings.md に記録してください。

レビューの追跡

mcp__codex__codex または mcp__codex__codex-reply によるレビュー担当者の呼び出しごとに、shared-references/review-tracing.md（ポリシー C — フォレンジック。黙ってスキップしない）に従ってトレースを保存してください。save_trace.sh（shared-references/integration-contract.md §2 のチェーンに従って解決）を使用するか、ファイルを .aris/traces/<skill>/<date>_run<NN>/ に直接書き込んでください。--- trace: パラメーター（既定値：full）に従ってください。