ns-judge

Delivery Judge

リリースされた差分が入力 ACに一致していることを証明します。SOLID の評価ではありません。セキュリティの評価でもありません。コード品質の審査はすでに ns-reviewer で合格しています。

形式（ベンダーのコピーではありません）：the-judge SKILL.md v1.4.0。ここで再実装してください。このファイルを貼り付けてはいけません。GitHub の APPROVE、絵文字、禁止ワードのチェックゲート、6 回の LLM パス、post_review.py は使いません。

使用タイミング

親はすでに ns-reviewer / reviewer-agent から Code Review: Approved を受けています。同じ親がその後、この SKILL.md をセッション内で読み込みます。v1 では judge-agent はありません。人間の /ns-judge はセッションの窓口にすぎません。

親	モード	AC のソース
run-implementation Step 5	closure	sdd/requirements.md
ns-autonomous の単独クローズ	closure	同じ
ns-coder のアドホック / C2	adhoc	--requirements / --ac-file があればそれを使用。なければ AC の証明をスキップ
ns-execution-gitlab-issue Phase 4	issue	synthesis からの --ac-file（Python は GitLab を呼び出しません）

ns-reviewer はこのスキルをディスパッチしてはいけません。

Code Review: Approved がない場合 → 停止します。審査してはいけません。先に reviewer を実行するよう親に伝えてください。

セッションの起動

../../ns-harness/references/session-boot.md を参照してください。この judge の実行でコールドスタートする場合は、プローブ前に Session boot 1–6 を実行してください。AGENTS.md をツールで Read してはいけません。

プローブ（Python は任意）

command -v python3 を実行します。Python がない場合、またはスクリプトが終了コード 1 を返した場合 → 事前チェックをスキップします。残りの LLM 審査は引き続き実行します。Python がないことを理由に Blocked にしてはいけません。

詳細と CLI：references/workflow.md。トークンの正規表現は scripts/prove_ac.py のみに記述されています。この本文には記述しません。

ワークフロー

1. 直近のコード判定が Code Review: Approved であることを確認します。そうでなければ停止します。
2. Python をプローブします。使用可能な場合：
   • アクティブなモードに対して prove_ac.py を実行
   • git diff \| python3 scripts/scan_bypasses.py を実行（常に終了コード 0）
3. prove_ac.py の終了コードが 2 → 書式は修正マップ（../ns-reviewer/references/review-fix-map.template.md）に従い、最終行を Delivery Review: Rejected にします。残りの LLM 審査は行いません。
4. 残りの LLM 審査（スクリプトをスキップした場合または prove の終了コードが 0 の場合）：テストですでに検出されていない残存事項を確認します。phpunit/lint を繰り返し指摘してはいけません。scan_bypasses.py が検出したむき出しの抑制は、残りの審査で評価します。主張には証拠が必要です（Pass E より厳格：AC トークン）。
5. findings.json を作成します。review_gate.py を実行します。ゲートに失敗した場合 → JSON を編集し、再実行します。プロダクトの Blocked ではありません。
6. 最終行：Delivery Review: {Approved|Rejected|Blocked}。スコアは Executive Summary に記載します。

スコアゲート（ns-reviewer と同じ表）

コピーして使用してください。別の評価基準を作ってはいけません。Approved は Critical がゼロかつスコアが 10 の場合です。スコア 9 は Rejected（Lift）です。

スコア	意味	判定への影響
10	そのままリリース可能	Approved（対象となる唯一のスコア）
9	AC / ledger / ui-contract 項目に基準未満の残存事項あり	Rejected — Lift
≤8	基準未達 / AC トークン不足 / ledger 未達	Rejected

Approved にできるのは、以下をすべて満たす場合のみです：

1. Critical の指摘がゼロ
2. 全体スコアが 10/10
3. スコア対象のすべての AC トークンがリポジトリ内で見つかる（AC ソースがある場合）

AC トークンの不足 / ledger 未達 / testid の不足は、Critical とするかスコアを ≤8 に制限する必要があります。10 にはできません。

Python をスキップした場合の残りの審査にも、同じ 10 のみのルールが適用されます。LLM は引き続きスコアと判定を出力します。

review_gate.py は、スコアが 10 以外の場合、または P0 の指摘がある場合に Approved とする JSON を拒否します。

モード

closure

prove_ac.py --mode closure [--repo .] [--version VERSION_SAN] [--requirements PATH]

規則：#### Acceptance criteria: のチェックボックス行。トークン：バッククォート、引用符で囲まれた文字列、data-testid、HTTP \b[1-5][0-9]{2}\b（スクリプト内）。トークンが 1 つ以上あり、リポジトリ内で 0 件の場合は P0 Rejected。行にトークンが 0 個の場合はスコア対象外（残りの審査で確認）。このスクリプトは機能が動作するとは主張しません。

さらに、ledger の不足 / マッピング漏れ、ui-contract の testid / コピー、ビジュアルチェックリストのリテラルも対象です。同じ Rejected の基準が適用されます。

issue

--mode issue --ac-file PATH。synthesis ファイルを使用します。Python から GitLab は呼び出しません。

アドホック

--requirements または --ac-file が指定されていない場合、AC の証明を省略します。残余チェックは引き続き実行します。親レポートでは、AC の証明が n/a と記載されることがあります。

必須の出力

承認

エグゼクティブサマリー

• スコア 10
• 評価基準に照らした一文
• 2 行の評価
• AC の証明：pass | n/a（アドホック、ソースなし）

次に記載します：Delivery Review: Approved

却下／ブロック

エグゼクティブサマリー

• スコア 1～10
• 一文
• 2 行の評価

修正マップ（エージェント）

../ns-reviewer/references/review-fix-map.template.md

次に記載します：Delivery Review: Rejected または Delivery Review: Blocked

制約

• 製品ファイルは読み取り専用です
• ns-reviewer からディスパッチしません
• GitHub レビュー API は使用しません
• P0／P1 の指摘には evidence: [{type:internal,ref:path:line}] が必要です
• 残余チェックでは、テストで既に検出される内容を繰り返しません

参考資料

ファイル	使用時
references/workflow.md	プローブ、スキップ、CLI、findings.json
../ns-reviewer/references/review-gate-workflow.md	親シーケンス（コード、次に判定）
../ns-reviewer/references/review-fix-map.template.md	却下時の本文
scripts/prove_ac.py	AC／台帳／ui-contract／ビジュアル規約
scripts/scan_bypasses.py	差分の stdin 候補
scripts/review_gate.py	findings.json ゲート