result-to-claim

结果到主张关卡

在每个评审者席位开始前，请遵循可选评审者： 通过规范的辅助解析器解析调用 → .aris/reviewer.json → Claude Code 默认项（Codex MCP）， 并使用 reviewer_route.py，同时保留此席位的层级、新上下文、源文件/图像输入和确定性关卡。 以下 Codex 示例/固定配置仅适用于 backend=codex；其他路由使用各自的首次调用/回复约定。保存路由和实际返回的身份； 不可用的选项记为 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）：预期主张和实验设计

汇总关键信息：

• 运行了哪些实验（方法、数据集、配置）
• 主要指标和基线对比（差值）
• 这些实验旨在检验的预期主张
• 已知的混杂因素或注意事项

步骤 1.5：确定性证据预检（在调用 Codex 之前）

对于每项引用了具体数字和源文件的声明，先以机械方式验证证据是否存在——不调用模型——以便在陪审团开始审查前发现虚构证据（参见 shared-references/evidence-precheck.md）。

1. 构建声明列表。 根据引用的数字及其结果文件，将 [{"id", "value", "source"}, ...] 写入 .aris/claims.json（source 是相对于项目根目录的结果文件/通配符；value 是引用的数字或字符串）。

2. 运行预检——这是必做步骤，而非建议。 执行下面的代码块 （依据 integration-contract §2 为解析器，采用策略 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. 将每项声明的状态带入步骤 2。 将一张简短的 evidence pre-check: <id> → verified | value_not_found | path_missing | unparseable 表格（来自 .aris/evidence_precheck.json）加入步骤 2 的 Codex 提示词，让陪审团知道哪些声明有真实证据可供查阅。如果跳过了预检（辅助工具无法解析），则在该位置说明这一情况，而不要省略。

这里的 verified 仅表示引用的证据存在——它是否支持声明，仍由步骤 2 的 Codex 陪审团判定（确定性关卡负责推动审查，不负责判定无罪）。

步骤 2：Codex 判定

将收集到的结果发送给 Codex 进行客观评估。只包含通过步骤 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.

步骤 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

步骤 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。

步骤 4：根据判定结果采取后续行动

no — 声明不受支持

1. 在 findings.md 中记录事后分析（Research Findings 部分）：
   • 测试了什么、失败了什么，以及对失败原因的假设
   • 对未来尝试的限制（哪些方法不要再次尝试）
2. 更新 CLAUDE.md 中的 Pipeline Status
3. 决定是转向 IDEA_CANDIDATES.md 中的下一个想法，还是尝试其他方法

partial — 声明部分受支持

1. 更新当前声明，准确反映已有支持的内容
2. 在 findings.md 中记录差距
3. 设计并运行补充实验，以填补证据缺口
4. 补充实验完成后，重新运行结果到声明的转换
5. 同一声明多轮得到 partial → 在 findings.md 中记录分析，并考虑缩小声明范围或更换想法

yes — 声明受支持

1. 在项目笔记中记录已确认的声明
2. 如果消融研究尚未完成 → 触发 /ablation-planner
3. 如果所有证据均已到位 → 可以开始撰写论文

步骤 5：更新研究 Wiki（如果已启用）

如果 research-wiki/ 不存在，请完全跳过此步骤。

如果 research-wiki/ 存在，请按照 shared-references/wiki-helper-resolution.md 中记录的规范链解析 $WIKI_SCRIPT（变体 B — 对调用方技能发出警告并跳过）。以下 verdict / idea-outcome 页面编辑直接处理原始 Markdown，不需要 helper；但边、query-pack 重建和日志行需要 helper。此技能绝不会编辑 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 判定为“部分支持”，不要将其上调为“支持”。
• 单个数据集上的一个正面结果不足以支持一般性 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，其中仅包含首行 verdict: REVIEW_UNAVAILABLE（供流水线调用方使用的机器可检查门控标记），在 findings.md 中记录相同内容，然后停止——CC 绝不能代替 Codex 判断 claim（循环可以推动流程，但不能免除审查；参见 acceptance-gate.md）。下游步骤（wiki add_experiment 边、ablation-planner、论文 claim）不得使用没有 Codex verdict 的运行结果。例外：确定性证据预检（步骤 1.5）仍可将证据造假的 claim 终结性地标记为 claim_supported: no——确定性驳回不需要审查者；只有支持性或含糊不清的结果才需要审查者。
• 无论结果如何，都要在 findings.md 中记录 verdict 和推理过程。

审查追踪

每次调用 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）。