logic-review

Logic-Lens — ロジックレビュー

出力スケルトンの契約

後続の採点スクリプト（scripts/grade-iteration.py）やほかの Logic-Lens スキルは、このレポートを ../_shared/common.md §1（ヘッダーマップ）、§2（必須フィールドラベルと Logic Score）、および ../_shared/report-template.md（スケルトン）で定義されたリテラルトークンの部分文字列一致で読み取ります。言い換えた場合、人間には問題なく読める類義語であっても、分析の品質にかかわらず契約に違反します。

言語によってトークンセットは変わりますが、構造は変わりません。 以下の2つのテンプレートは、2つの言語で書かれた同一の契約です。中国語のレポートに英語のラベルを出力することも、ラベルを言い換えるのと同様に契約違反です。common.md §1（最優先）に違反し、採点結果も同じように失敗します。まずユーザーの言語を判定し、§1 のヘッダーマップにある該当言語の列に従ってスケルトンを埋めてください。

ベンチマークで確認された、一般的なルールに加えて特に注意すべき3つの失敗パターン：

• 置き換えた語に必須の部分文字列が含まれないフィールドラベルの類義語置換 — Premises / 前提 を 前置条件构建 / 前置条件 に置き換える（eval-201）、または Divergence / 偏差 を 根因 / 核心缺陷 / 结论 に置き換える（eval-252）ケースです。いずれも人間には問題なく読め、セクション見出しや表の列名として使える場合もありますが、置き換え後の語には必須の部分文字列が含まれないため、採点スクリプトやほかのスキルはそのフィールドを文書内に存在しないものとして扱います。common.md §1 のリテラルトークンを使用してください。説明的な副題を併記することはできます。
• 確認済みの L コードの指摘を ### 附加观察（非 Finding） / ### 追加の観察事項 に格下げする — Premises→Trace→Divergence が成立する場合、その指摘は Suggestion の重要度であっても、5つのリテラルフィールドを含めて ## Findings（中国語では ## 发现）の中に記載してください。これは、Sonnet の実行で eval-279（quicksort L4）が失敗する原因として繰り返し確認されたパターンです。
• Divergence: / 偏差： フィールドそのものを省略する — 最も頻繁に発生する失敗パターンです。バグを正しく分析していても、偏差を文章、表のセル、または 根因、故障点、核心问题、缺陷 などの見出しの下に記述する出力が多くあります。Divergence: フィールドは、「実際の動作が前提から逸脱する箇所」を示す専用のラベルです。省略可能ではなく、許容される類義語もありません。バグがない場合は、Divergence: None — [前提が成立する理由]（中国語では 偏差：无——[原因]）を使用してください。

正しく書式設定された指摘 — テンプレートとして使用してください：

### 🔴 Critical
**[L4] — Mutation during iteration skips elements**
Premises: `users` is `list[User]` passed by reference; `list.remove()` shifts subsequent elements left; the `for` iterator advances by index.
Trace: [1] index=0, user is inactive → `remove()` shifts list. [2] Iterator advances to index 1, which now holds the element originally at index 2 — the original index-1 element is skipped. Rebuttal check: PASSED — no defense found.
Divergence: `remove_inactive([inactive₁, inactive₂, active])` returns `[inactive₂, active]` (2 elements) instead of `[active]` (1 element) — the second inactive user is never visited.
Trigger: `remove_inactive([User(False), User(False), User(True)])` → expected 1, actual 2.
Remedy: Replace loop body with `return [u for u in users if u.is_active]`. Dry-run: ✅ divergence eliminated.

各指摘ブロックには、5つすべてのリテラルラベル（Premises: / Trace: / Divergence: / Trigger: / Remedy: または 前提： / 追踪： / 偏差： / 触发： / 修复：）を、行頭のプレフィックスとして含める必要があります。セクション見出し（### Premises、## Execution Trace）では要件を満たしません。ラベルは指摘ブロック内に記載してください。

バグがない場合：## Findings（中国語では ## 发现）を出力し、5つすべてのフィールドラベルを使った指摘ブロックを記載してください。Divergence: None — [前提が成立する理由] とします。この形式は必須です。採点と監査の両方に対応します。

以下の例を中国語で示しているのは、ローカライズされたトークンセットを具体的に示すためです。英語のテンプレートと完全に同じスケルトンです。英語のレビューでは英語のラベルを使用してください。構造は変わりません。

### ✅ 无 Bug
**[无 Bug] — defer 保证所有退出路径都会解锁**
前提：`mu.Lock()` 在第 12 行获取；`defer mu.Unlock()` 位于第 13 行（在任何条件分支或提前返回之前）。
追踪：[1] `defer` 在 `Lock()` 之后立即注册。[2] Go 规范保证 deferred 调用在所有函数退出路径上执行（return、panic、提前返回）。[3] Lock 与 defer 注册之间无条件分支。
偏差：无——`defer mu.Unlock()` 无条件置于加锁之后，保证每条退出路径都会释放，不存在锁泄漏。
触发：N/A（无 bug 可复现）。
修复：N/A（代码本身正确）。

セットアップ

../_shared/common.md §13 に従って遅延読み込みを使用してください。

1. ../_shared/common.md は、言語、Iron Law、Logic Score、スコープ管理、修正の規律、設定フィールド、読み込み予算に関する箇所のみを読みます。
2. 該当するステップに進んだ時点で、logic-review-guide.md の関連ステップのみを読みます。
3. 現在のステップで必要になった時点で、../_shared/logic-risks.md、../_shared/semiformal-guide.md、../_shared/semiformal-checklist.md、../_shared/report-template.md を読み込みます。

プロセス

ステップ 0．言語とスコープの振り分け。 common.md §1 に従ってユーザーの言語を判定します。以下のラベルと見出しはすべて、その言語にしてください。対象範囲が単一のファイルまたは単一の関数であることを確認します。ユーザーがディレクトリを指定している場合は logic-health に切り替え、確定した障害について説明している場合は logic-locate に切り替え、2 つのバージョンについて述べている場合は logic-diff に切り替えます。

ステップ 1．想定される動作とレビューの開始点を確認する（ガイドのステップ 1）— コードが本来どのように動作するべきかを1文で説明し、トレースする具体的なエントリー関数を選択します。ファイルが common.md §9 の上限を超える場合は、選択した範囲とその理由を明記します。

ステップ 2．前提条件を構築する（ガイドのステップ 2）— semiformal-checklist.md の「前提条件構築チェックリスト」に従います。レビュー対象の関数が別のローカル関数に依存している場合は、呼び出し元と呼び出し先の契約も含めます。

ステップ 3．リスク経路台帳を作成する（ガイドのステップ 3）— 指摘事項を書く前に、L1～L9 にわたるバグ候補の経路を列挙します。残す経路にはそれぞれ、クラス A（自明）またはクラス B（不変条件に依存）のタグを付けます。正常系だけで終わらせないでください。L コードを割り当てる前に、logic-risks.md の「クイック判別表」を確認します。よくある誤分類はそこで一覧にされています。L4 優先チェック： 入力を変更し、同じオブジェクトを返す関数はありますか？ L7 優先チェック： 明示的な同期なしに、await／yield／スレッドの境界をまたいで共有状態にアクセスしていますか？ L4 と L7 の判別： 複数の実行コンテキスト（スレッド／goroutine／await／yield）が関わる状態アクセスはすべて L7 であり、L4 ではありません。これは、await でコルーチンが交互に実行される単一スレッドの asyncio も含みます。L4 は単一コンテキストにおけるエイリアスの問題に限られます（可変デフォルト、インプレース変更の落とし穴、反復中の変更）。L4 では、根本原因として共有／エイリアスされた状態の実際の変更が必要です。変数スコープの問題（const/let の可視性、コンストラクターのスコープ）は L1、クエリパターンの非効率性（N+1）は L3 です。

L1 と L6 の判別： 根本原因が、開発者の想定とは異なる定義に名前／識別子が解決されること（インポートのシャドーイング、モジュール定数の検索、プロトタイプチェーン、メソッドから参照できないコンストラクター内スコープの const／let）である場合、症状がメソッド不在エラーや誤った戻り値であっても L1 です。L6 が適用されるのは、名前が正しく解決されているものの、呼び出し先の動作が呼び出し元の想定と異なる場合に限ります。

L2 と L6 の判別： 根本原因が、演算子レベルでの暗黙の型変換（+／-／*／== による文字列↔数値の変換、または as／キャストによる実行時の型チェックの回避）である場合、L2 です。L6 には、呼び出し元の想定と動作が異なる特定の呼び出し先を呼び出していることが必要です。演算子は呼び出し先ではありません。

L5 と L7 の判別： エラーコード、終了ステータス、例外が単一コンテキストの構文（|| true、空の catch、set -e の欠落、except のみ）によって抑制されている場合、L5（制御フローの逸脱）です。L7 には複数の実行コンテキストが必要です。単一の逐次実行スクリプト／関数内でのエラー伝播の失敗は L5 です。

L9 チェック： バグの根本原因が、データ型レベルでのタイムゾーン／ロケール／エンコーディング情報の喪失（例：TIMESTAMP と TIMESTAMPTZ、naive と aware の日時、ロケール依存の文字列ソート）である場合、L9 です。「呼び出し先の動作が想定と異なる」ように見えても L6 ではありません。また、L2 でも L8 でもありません。 ステップ 4. 選択したパスを詳細に追跡する（ガイドのステップ 4）— 通常のパスと最もリスクの高いエッジパスを追跡します。すべての名前を解決し、すべての型を明示し、呼び出し先の境界を越えて追跡し、確認済みの乖離または確認済みの安全な事後条件に達した時点で各トレースを終了します。**Java/C++ の DCL ルール：**ダブルチェックロックのパターンでは、両面を必ず追跡します：(a) volatile / メモリバリアの欠如（可視性の危険）と、(b) instance = new X(); instance.init(); が 2 つの非アトミックな文であること。ロックを使わない読み取り側は、init() が完了する前に、null 以外の instance を参照する可能性があります（初期化前公開の危険）。両方を報告してください。どちらか一方でも省略すると、分析は不完全です。

ステップ 5. 乖離を特定する（ガイドのステップ 5）— それぞれを L1～L9 に分類し、深刻度を割り当て、到達可能性ゲートを適用します（クラス A は直接報告、クラス B はプローブが必要です。強制処理が見つかった場合は候補から除外し、見つからなかった場合は割り当てた深刻度を適用し、一部だけ確認できた場合は Warning を上限とし、manual verification recommended を付記します）。バグがないシナリオには正確性パリティの原則を適用します。**バグがない場合の出力規律：**乖離が 0 件の場合も、テンプレートの骨格全体を出力してください。Mode 行、Scope、**Logic Score:** 100/100、## Findings（中国語では ## 发现）に続けて、5 つのフィールドラベルをすべて含む調査結果ブロックを記載し、Divergence: None — [why the premise holds]（中国語では 偏差：无——[原因]）を使用します。これにより推論を監査可能にし、フォーマット要件を満たします。分析によって疑われたバグがないと積極的に立証した場合は、その防御策を Trace: フィールドで説明してください（例：「Go の defer mu.Unlock() は、早期リターンを含むすべての終了パスでロック解除を保証します」）。判定を自由形式の文章にまとめたり、構造化フィールドを省略したりしないでください。後続の評価では、バグがないとの結論でも 5 フィールド形式が必要です。

ステップ 5.5. 敵対的レッドチーム分析（ガイドのステップ 5.5）— 候補となる調査結果ごとに、反論に関する 3 つの質問（前提への反論、パスへの反論、結果への反論）に答え、その調査結果を否定できるか試みます。防御策が確認できた調査結果は撤回し、防御策が一部確認できた調査結果は Suggestion に格下げします。**設計意図ゲート：**L3 Boundary Blindspot を報告する前に、「この境界で処理を続行しようとするのではなく、コードが明示的にエラー／拒否を返していますか？」と確認します。はいの場合（例：maxSize での errors.New("cache full")、429 Too Many Requests、バッファー満杯時の拒否）は撤回してください。これは正しい境界の強制であり、ブラインドスポットではありません。L3 が適用されるのは、コードが境界を越えて処理しようとし、気付かれないまま失敗する場合（誤った結果、クラッシュ、無限ループ）に限られます。注：境界での panic はクラッシュであり、設計されたエラー返却ではないため、L3 に該当する可能性があります。

ステップ 6. 鉄則を適用する — 5 フィールド規律（ガイドのステップ 6）— すべての調査結果で Premises → Trace → Divergence が揃っていることを確認します。その後、Trigger（具体的な再現入力。Critical/Warning では必須）と Remedy（common.md §10 に従った、そのまま貼り付け可能な修正内容）を記述します。各調査結果では、次のリテラルなフィールドラベルを必ず使用してください — 英語では Premises: / Trace: / Divergence: / Trigger: / Remedy:、中国語では 前提： / 追踪： / 偏差： / 触发： / 修复：。言い換えはしないでください。Execution Path、Issue Found、Core Defect、执行路径、发现的逻辑隐患、核心缺陷 のような見出しを代用することは認められません。これらは後続の評価に失敗し、他の Logic-Lens スキルが利用するレポートの契約を破ります。**複数の調査結果に関する規律：**調査結果が複数ある場合、## Findings（中国語では ## 发现）内の各調査結果ブロックに、5 つのリテラルなフィールドラベル — Premises: / Trace: / Divergence: / Trigger: / Remedy:（またはそれぞれの中国語表記）— をすべて含め、各調査結果に固有の内容を記載してください。共通の背景情報は前置きセクションに記載してもかまいませんが、個々の調査結果に必要なフィールドの代わりにはなりません。Divergence:（またはその他の必須フィールド）を省略すると、Premises: や Trace: がレポート内の別の箇所にあっても、調査結果は契約違反となります。 Step 6.5. 修正案のドライラン（ガイド Step 6.5）— Trigger 入力を修正後のコードに通して頭の中で再トレースし、分岐が解消され、リグレッションが発生せず、正常系が維持されていることを確認します。

Step 7. スコアの算出と出力（ガイド Step 7）— 実行環境が利用できる場合は、必ず先に Step 8 を実行してください。誤検出を取り下げるため、スコアが変わります。検証を通過した検出結果について、common.md §6 に従って Logic Score を算出し、Scope 行（**Scope:** / 中国語 **范围：**）の直下に、文字どおり **Logic Score:** XX/100（中国語 **逻辑评分：** XX/100）の行として出力します。この正確なトークン（「Score: XX」や「Quality: XX」ではありません）は、採点ツールによる認識とスキル間での利用の両方に必須です。その後、Report Template の残りの部分を、見出しをローカライズして出力します。

Step 8. 実行検証ゲート（ガイド Step 8）— 対象言語の実行環境が利用できる場合、Critical と Warning のすべての検出結果について必須です。分析に反する結果が出る可能性がある唯一のステップなので、確信を持ってトレースできても省略してはいけません。Trigger フィールドから最小限の再現コードを作成し、元のコードに対して実行した後、修正案を適用して再実行します。元のコードで再現コードが成功する検出結果は、誤検出として取り下げます。残ったものには ✅ 実行検証済み を付けます。実行環境がない場合は ⚠️ 未検証——利用可能な実行環境なし（中国語 ⚠️ 未验证——无可用运行时）とします。

レポートの Mode 行： Logic Review（中国語：逻辑审查）。