integrity-forensics

Integrity Forensics — Anti-Autoresearch の薄いランチャー

監査対象：$ARGUMENTS

これは何か。 ARIS は論文を生成します。Anti-Autoresearch はその外向きの双対であり、査読者側のインテグリティ・フォレンジックです（8 つのファミリーにわたる 46 パターン、決定論的な GRIM／GRIMMER／statcheck コア、スパンに紐付けられた主張、裁定ではなく要約を行うルールベースのレポーター）。このスキルは薄いランチャーです。上流のコミットを固定し、上流の評価ゲートで固定を検証して、実行を変更せずに委譲し、判定を ARIS のポリシー用語に変換して後処理します。ベンダーコードもフォークも含みません。

🔁 実行頻度の制約（shared-references/external-cadence.md）：このスキルは判定を伴う意思決定支援です。/loop／/schedule でラップしてはいけません。また、以下の「唯一禁止されているループ」にあるとおり、「問題が指摘されなくなるまで編集を繰り返す」ことは絶対にしないでください。

定数

• ANTI_AR_REPO = https://github.com/wanshuiyin/Anti-Autoresearch.git
• ANTI_AR_COMMIT = b47af6f983b38347b6d2110379e266400597cf66 — SHA ピンです。 ランチャーは上流の HEAD を追跡しません。この定数の更新にはレビューが必要です（「ピン更新チェックリスト」を参照）。
• CLONE_DIR = ~/.aris/anti-autoresearch — 固定された作業コピーです。意図的にホストに依存しないパスにしています。ARIS は DeepSeek Harness、Codex CLI、Cursor、Trae、Antigravity、Copilot CLI でも動作しますが、そこでは ~/.claude/ はユーザーがインストールしていない環境を指すためです。以前のクローンが ~/.claude/anti-autoresearch にある場合は使用されません。オフラインの決定論的のみの実行を継続する場合に限り、そのクローンと .aris_eval_ok_* レシートを移動してください。それ以外の場合は、都合のよいときに削除できます。
• 査読者向けの設定項目はありません。 このランチャーは査読者モデルや実行負荷のパラメーターを公開せず、ARIS の — effort: を上流設定に対応付けることもありません。固定された上流は、固定されている内容（gpt-6-astra + xhigh。これは上流独自の設計判断です）をそのまま実行します。ランチャーから上流の査読ポリシーを上書きすると、監査できない設定項目が新たに生じます。
• GATE_HELPER = forensics_gate.py — 正規の探索順序（shared-references/integration-contract.md §2）に従って解決します：.aris/tools/ → tools/ → $ARIS_REPO/tools/ → ~/.aris/repo 経由の $ARIS_REPO/tools/。 失敗時のポリシー A（必須）：assurance: submission で解決できない場合は停止してください。ゲートの代わりを即興で用意してはいけません。

Step 0 — ピンを準備する（冪等）

CLONE_DIR="$HOME/.aris/anti-autoresearch"
ANTI_AR_COMMIT="b47af6f983b38347b6d2110379e266400597cf66"

mkdir -p "$HOME/.aris"
if [ ! -d "$CLONE_DIR/.git" ]; then
    git clone --no-checkout https://github.com/wanshuiyin/Anti-Autoresearch.git "$CLONE_DIR"
fi
# fetch ONLY if the pin isn't already present — a cached, validated pin works offline
git -C "$CLONE_DIR" cat-file -e "$ANTI_AR_COMMIT^{commit}" 2>/dev/null \
    || git -C "$CLONE_DIR" fetch -q origin
git -C "$CLONE_DIR" checkout -qf "$ANTI_AR_COMMIT" || {
    echo "FATAL: cannot checkout pinned commit $ANTI_AR_COMMIT"; exit 1; }
# Force a PRISTINE tree at the pin — local tampering with the clone (edited
# adjudicator, injected module, even one hidden inside a NESTED git repo,
# which single-f clean skips) must not survive bootstrap and run under the
# official pin's name. Every step is checked; then the tree is verified.
git -C "$CLONE_DIR" reset --hard -q "$ANTI_AR_COMMIT" || {
    echo "FATAL: reset to pin failed"; exit 1; }
git -C "$CLONE_DIR" clean -ffdxq || {
    echo "FATAL: clean failed"; exit 1; }
[ -z "$(git -C "$CLONE_DIR" status --porcelain)" ] || {
    echo "FATAL: clone is not pristine after reset+clean — refusing to run"; exit 1; }

# One-time-per-pin validation: the upstream eval gate (8 injected-defect
# classes, 100% recall + zero clean false positives) must PASS before this
# pin is allowed to produce a verdict. NEVER skip; NEVER proceed on failure.
# The marker lives OUTSIDE the clone: a marker inside a tamperable tree proves
# nothing (and `git clean` above would erase it, forcing re-eval every run).
MARKER="${CLONE_DIR}.aris_eval_ok_${ANTI_AR_COMMIT}"
if [ ! -f "$MARKER" ]; then
    ( cd "$CLONE_DIR" && python3 eval/run_eval.py ) || {
        echo "FATAL: upstream eval gate FAILED at pin $ANTI_AR_COMMIT — refusing to"
        echo "       use an unvalidated forensics pin for verdicts."; exit 1; }
    touch "$MARKER"
fi
echo "anti-autoresearch pinned at $ANTI_AR_COMMIT (eval gate: validated)"

Step 1 — 委譲：上流のスイープを変更せずに実行する

$CLONE_DIR/workflows/anti-autoresearch/SKILL.md を開き、対象について最初から最後までその手順に従ってください。ラッパー側のルールは 2 つだけで、このランチャーが追加する唯一の内容です。

1. cwd。 上流スキルは git rev-parse --show-toplevel で自身の場所を特定します。上流の bash ブロックはすべて、最初に cd "$CLONE_DIR" を実行してから実行してください。必ず cd を使い、ROOT のエクスポートだけで済ませてはいけません（上流ブロックは独自に ROOT を再導出し、上書きするためです）。また、論文は絶対パスで指定してください。そうしないと、上流が ROOT を ARIS リポジトリに解決し、誤った Python の基盤を検出します。
2. Codex の呼び出しには approval-policy: never と sandbox: read-only を指定してください （セッションの衛生管理のためです。上流ではすでにディメンションごとの新しいスレッド、逐次実行、独自のモデルピンが指定されています。これらは変更しないでください）。

それ以外のすべて、すなわちエビデンス台帳、coverage.json のステートマシン、9 つの監査者ディメンション、反証パス、決定論的な要約は、上流の契約に従います。出力（report.json + REPORT.md、判定 ∈ CLEAN_GIVEN_EVIDENCE / SOFT_FLAGS / HARD_FLAGS / REVIEW_UNAVAILABLE）を書き換えたり、弱めたり、別の形式に対応付けたりしてはいけません。 可観測性レベル（L0／L1／L2）は、存在する成果物に基づいて上流が導き出す値です。L2 を保証してはいけません。

ステップ 2 — 型付きゲートと義務（ARIS 側の後処理）

# Resolve $GATE_HELPER via the canonical chain (integration-contract §2), then
# ONE atomic call (update + gate in a single locked transaction — the gate only
# ever speaks for the report the ledger has folded, sha-bound):
python3 "$GATE_HELPER" evaluate --report "$PAPER_DIR/report.json" --paper-dir "$PAPER_DIR" \
    --anti-ar-commit "$ANTI_AR_COMMIT" --executor-model "<this pipeline's executor>"
# exit 0 = WARN / NO_NEW_BLOCKER · exit 1 = BLOCK

ゲートは判定を再ラベル付けせずに、ポリシーへ変換します。

上流の判定	ポリシー
HARD_FLAGS	BLOCK — 監査者が重大な問題を提案しており、あなたが確認できるよう提示されています。「機械が不正を発見した」という意味では決してありません
REVIEW_UNAVAILABLE	BLOCK — 不完全な確認では、書類をそのまま通せません
SOFT_FLAGS	WARN — 人間による判断が必要です。未実行の項目も確認してください。上流の判定では、本来なら問題なしとなる場合に限り、不完全さが織り込まれます。そのため WARN でも、判定に影響する項目が未実行の確認に基づいている可能性があります。evaluate と fresh はどちらも、そうした項目を表示します
CLEAN_GIVEN_EVIDENCE	NO_NEW_BLOCKER — *PASS や承認と呼ばれることは決してありません。「手元の証拠からはフラグが見つからなかった」という意味であり、無罪を示すものではありません
その他すべて	BLOCK（フェイルクローズ）

さらに、未解決の重大な義務があれば BLOCK、未解決の義務があれば少なくとも WARN となります。受領証なしでクローズされた台帳エントリ、またはステータスが不明なエントリがあれば BLOCK となります（"status": "RESOLVED" を手動で編集してもゲートは開きません）。

gate.json には paper_fingerprint（論文のコンパイル入力と成果物（.tex／.bib／.sty／.cls／図／PDF）の SHA）も記録されます。下流の事前チェックは、次の 1 つのコマンドで行います。 python3 "$GATE_HELPER" fresh --paper-dir "$PAPER_DIR" --anti-ar-commit "$ANTI_AR_COMMIT" — 終了コード 0 ⟺ ゲートが現在のピンで生成されている ∧ ゲートが存在する ∧ 生成後に論文が変更されていない ∧ ゲートが現在の義務台帳と一致する ∧ 判定が通過可能（WARN／NO_NEW_BLOCKER）である。判定は、ゲートに保存されたトークンからではなく、SHA 検証済みのアーカイブ済みレポート（last_report.json）とライブ台帳から再計算されます。それ以外の場合（ゲートがない、ゲート生成後の編集または再コンパイル、台帳やアーカイブとの紐付けがない、再計算結果の不一致、BLOCK、トークンが不明）は終了コード 1 となります。再度確認を実行し、evaluate を実行してください。台帳を変更する操作（update／resolve／waive）を行うと、既存の gate.json は必ず削除されるため、中断した実行によって古い PASS 判定が残ることはありません。また、evaluate は論文内のいずれかのファイルより古いレポートを拒否します（古いレポートを、そのレポートで監査していない本文に適用することはできません）。確認の直後、論文ファイルに手を加える前に evaluate を実行してください。

ゲート成果物には、正確な来歴も記録されます。上流の監査者は GPT 系であるため、Claude の実行者の場合、指摘には cross-family の提案来歴が付与され、Codex の実行者の場合は same-family となります。いずれの場合も、このゲートが行うのはフラグを立てることだけであり、承認を与える機能はありません。そのため、この違いは情報提供を目的とするものであり、抜け道ではありません。

ステップ 3 — 検出された問題を修正する（磨き上げのループではなく、義務への対応）

すべての OPEN の義務に DISPOSITIONED を記録します。修正するか、明示的に免除します。上流では、監査担当者が行ったすべての提案が報告されるようになり、どれを対象外とするかは判断されなくなりました。そのため、2026-08 より前の調査で発生していた数より多くの義務が見込まれます。また、同意できない提案も含まれるでしょう。waive は正式に認められた、想定される結果です。「モデルが提案したが、人間である私が誤りだと判断した」は、ここでは通常の対応であり、最後の手段ではありません。報告書の各列（Anchored、Observability、FP-risk、Surface、Ext-check）を考慮して、各項目を判断してください。

実際に対応が必要な項目は、適切な手順で修正します。

指摘の分類	修正方法
A — 数値の自己整合性	RESULT FILES から再計算します（/paper-claim-audit のエビデンスチェーン）。文ではなく数値を修正します
D — 実験の完全性	/experiment-audit に戻るか、再実行します
E — 引用	/citation-audit の KEEP/FIX/REPLACE の仕組みを使います
G — 証明と導出	/proof-checker の修正ループを使います
B / C / H — スコープ、ベースライン、評価設計	科学的な判断が必要です。指摘をレビュー担当者の INPUT として /auto-review-loop に渡すか、人間に判断を委ねます
AIS / advisory（重みゼロ）	/auto-paper-improvement-loop で任意の参考情報として使用します。ゲートの条件にはなりません

各義務を明示的に完了してください。レシートは型付けされ、ハッシュ化されます。

python3 "$GATE_HELPER" resolve --paper-dir "$PAPER_DIR" --obligation-id <id> \
    --fix-type corrected-from-results|claim-narrowed|claim-withdrawn|citation-replaced \
    --evidence <path-to-the-ground-truth-that-backs-the-fix> \
    --verified-by "human:<name>" | "checker:<tool>" | "cross-family-review:<thread-id>"
# or, with HUMAN sign-off only:
python3 "$GATE_HELPER" waive --paper-dir "$PAPER_DIR" --obligation-id <id> \
    --approver "human:<name>" --reason "<why this stands as-is>"

台帳が機械的に適用するルール（tests/test_forensics_gate.py）：

• 追記専用 — 調査を再実行すると義務が追加されることはありますが、完了することはありません。
• 後の報告書で指摘が消えた場合も、OPEN のまま UNRESOLVED_DISAPPEARANCE が付与されます。該当箇所の言い換えは修正ではありません。
• claim-withdrawn は誠実な修正です（裏付けのない主張を削除することは正当な解決であり、削除差分をエビデンスとして示します）。
• 免除は解決ではありません。人間の承認を経て恒久的に記録され、元の指摘のスナップショットは変更されません。
• 実行者が付ける fix_type ラベルはレシートであり、判定ではありません。重大な指摘を完了するには、分類別チェッカー、新たなクロス分類レビュー、または人間による確認が必要です（--verified-by には TYPED な来歴が必要で、記録されます。承認していない人間の名前を挙げると、恒久的な記録が残る虚偽記録になります）。
• レシートは記憶に頼らず、再検証されます。後続のゲート実行時には、エビデンスファイルが引き続き存在し、完了時に記録されたハッシュと一致する必要があります。完了後にエビデンスを編集すると、BLOCK が再び発生します。
• resolve/waive（update と同様）は、現在有効な gate.json を無効化します。ステップ 3 を終えるには、調査を再実行してから evaluate を実行し、下流の事前チェックが参照するゲートに修正後の状態を反映させます。

禁止されている唯一のループ

「編集 → 調査の再実行 → CLEAN になるまで繰り返す」は絶対に行わないでください。 その目的関数は、編集者に検出器をすり抜ける方法を学習させます。アンカーされた箇所を削除すれば数値を修正するよりも簡単にフラグを消せてしまい、監査自体をすり抜けるように加工された論文ができあがります。修正後の再実行は、DISCREPANCY が解消されたことの確認（および新たな不一致の検出）のために行います。ゲートを通過させるかどうかを決めるのは判定結果ではなく、義務台帳です。

信頼境界（計算されるものとプロトコルの区別）

• 計算されるもの（ゲートが機械的に適用します）：判定→ポリシーのマッピング、 追記専用台帳のライフサイクル、sha のバインディング（レポート ↔ 台帳 ↔ アーカイブ）、 レシートの再ハッシュ、論文のフィンガープリント、ピン／バージョンの一致、再計算された 判定（fresh は保存済みトークンを決して信頼しません）。
• プロトコル（意図的に指示に基づいて評価するもの）：スイープが実際に、この論文に対して ピン留めされたクローン上で実行されたかどうかです。ゲートは基準を引き上げます — 構造上の最低条件（レポートには判定者を明記し、カバレッジマップを含める必要があります）、 古いレポートを検出する mtime ガード — そして、そこで止まります。レポートと論文の間に 暗号学的なバインディングは意図的にありません。これは研究ワークフローのゲートであり、 来歴管理システムではないためです。正直に言えば、意図的に不正を行う実行者なら古いレポートを 提出できます。同様に、human: / checker: / cross-family-review: のラベルは 説明責任を示すものであり、認証ではありません。虚偽のラベルは、明示的かつ 永続的な虚偽の記録になります。
• 対象外：シェルアクセスを持ち、.aris/ の成果物を一貫性を保って書き換える当事者は、 所有者としての権限を持っています（ディレクトリを丸ごと削除することもできます）。 このゲートが防ぐのは、不注意な実行者や手順を省く実行者、そして正常なクラッシュ／競合／ 再開に対してであり、マシンの所有者に対してではありません。

ピン更新チェックリスト（メンテナー向け）

1. 新しい ANTI_AR_COMMIT を設定します。マーカーは削除しないでください（eval ゲートは 新しい SHA に対して自動的に再実行されます）。
2. 上流の schemas/report.schema.json と判定語彙を、ゲートのポリシーテーブルと比較します。 変更があった場合は、更新前に tools/forensics_gate.py を拡張してください。
3. 古い検出事項／義務は引き続き有効です（フィンガープリントは ID ではなく、範囲／ハッシュに 基づいています）。ただし、古い判定者が生成した検出事項は、再判定ではなく再監査 する必要があります（上流独自の移行ルールです）。
4. 更新によって、ユーザーが処置しなければならない項目数が変わる場合は、ユーザーに伝えてください。 fresh は古いピンの保存済み gate.json をすべて PIN_MISMATCH で拒否するため、更新するだけで 全員に再スイープが強制されます。再スイープのコストが二度発生しないよう、上流の変更は 2 回ではなく 1 回の更新にまとめてください。

2026-08 の更新（98a75fc）— 未解決の義務が増える見込みです。 上流では提案の判定から、 提案の報告へと移行しました。以前は FP リスク、可観測性、対象範囲、外部確認の必要性に関する ゲートによって info に格下げされていた検出事項が、今後は info より上の判定で届くため、 義務が発生します。論文の内容が悪化したわけではありません。監査者が指摘した内容が、より多く 表に出るようになったのです。誤りだと判断した提案を免除するのが想定された処置であり、 判断材料となるのはレポートの検出事項ごとの列（Anchored、Observability、FP-risk、 Surface、Ext-check）です。同じ時期に、上流はレポート自体をバインドするハッシュも削除しました が、こちらではそれらを使用したことはありません。

Codex ネイティブに関する注記（ミラー）

上流は Codex ネイティブのパックを提供していません。監査者スキルは Claude-Code の契約です。 Codex ネイティブのセッションでは、上流の決定論的処理のみのモード（数値処理の中核と、 すべてのカバレッジマップが review_unavailable の判定者 — 範囲を正直に限定し、問題を指摘することは できますが、CLEAN と判定することは決してできません）を実行できます。9 つの次元すべてを網羅する スイープには、上流の Claude-Code 契約を変更せずに実行できるホストが必要です。既知のものは Claude Code と DeepSeek Harness 上の dsh-aris バンドルです。上流のレビュー担当者の呼び出しを その場で spawn_agent に変換するのは、上流の契約を書き換えることにあたり、禁止されています。

レビューの追跡

上流は、論文の .aris/traces/ に次元ごとのトレースを保存します。ランチャーが追加するのは .aris/forensics/ の成果物のみです。gate.json（anti_ar_commit と、レポート／台帳のハッシュ、 論文テキストのフィンガープリントをピン留めします）、obligations.json（追記専用台帳）、 last_report.json（fresh が再計算の元にする、sha 検証済みの折りたたみ済みレポートのアーカイブ）です。