Logic-Lens — Logic Review（逻辑审查）
用途
该技能用于在单个文件或单个函数的范围内查找逻辑缺陷，方法是进行半形式化执行追踪，即按“前提（Premises）→ 追踪（Trace）→ 偏差（Divergence）→ 触发（Trigger）→ 修复（Remedy）”的流程展开分析。当用户分享代码、怀疑其中存在问题但没有给出具体失败现象时（例如“review this”“does this look right”等表述），即触发该技能。根据其范围路由规则：如果用户指向的是一个目录，则切换到 logic-health；如果描述的是已确认的故障，则切换到 logic-locate；如果是两个版本，则切换到 logic-diff。
主要能力
分析过程从建立“声称行为”和审查入口点开始，随后构建前提（Premises），并建立风险路径台账，在撰写发现之前先枚举 L1–L9 的候选缺陷路径，将每条保留路径标记为 Class A（自明）或 Class B（依赖不变式）。随后对选定路径进行深度追踪，解析每个名称、声明类型、跨被调用方边界，并将每条追踪停在已确认的偏差或已确认的安全后置条件处。
流程还包含对抗性红队步骤（Step 5.5），对每条候选发现从三个反驳问题（前提反驳、路径反驳、后果反驳）进行反驳尝试：确认存在防御的发现予以撤回，部分防御的降级为 Suggestion。设计意图门控要求在报告 L3 边界盲点前先判断代码是否在该边界显式返回错误或拒绝，若是则撤回。
铁律（Iron Law）——五字段纪律要求每条发现都必须包含前提 → 追踪 → 偏差的完整链条，然后写明触发（Critical/Warning 必须提供可复现的具体输入）和修复（可直接粘贴）。若可用运行时，Step 8 执行验证门控会为每条 Critical/Warning 生成最小复现脚本，执行以确认缺陷存在，应用修复后再次执行以确认修复有效，撤回误报，并将已验证的发现标记为“✅ Execution-verified”。
字段标签契约
下游评分器（scripts/grade-iteration.py）和其他 Logic-Lens 技能通过子字符串匹配字面 token 来消费该报告。改写这些 token（即使对人类读者而言是通顺的同义词）都会破坏契约。每条发现块必须包含全部五个字面标签（Premises: / Trace: / Divergence: / Trigger: / Remedy: 或中文的 前提： / 追踪： / 偏差： / 触发： / 修复：），作为行首前缀。章节标题（如 ### Premises、## Execution Trace）不满足该要求。
基准中观察到的三类典型失败模式：
- 对字段标签做同义替换，导致替换后的形式不包含必需子串（例如将 Premises/前提 替换为 前置条件构建/前置条件，或将 Divergence/偏差 替换为 根因/核心缺陷/结论）。
- 将已确认的 L-code 发现降级为“附加观察（非 Finding）”。如果前提→追踪→偏差成立，该发现就属于 ## Findings，即使严重级别为 Suggestion 也要保留五个字面字段。
- 完全省略 Divergence: / 偏差： 字段——这是最常见的失败模式。Divergence 字段是“实际行为偏离前提之处”的专用标签，不可选，也没有可接受的同义词。对无缺陷的发现，使用 Divergence: None — [why the premise holds]（中文 偏差：无——[原因]）。
报告中需要的其他字面 token：
- Logic Score 必须输出为字面行 Logic Score: XX/100（中文 逻辑评分： XX/100），直接放在 Scope: 下方。不接受“Score: XX”“Quality: XX”等写法。
- 模式行在报告中为 Logic Review（中文：逻辑审查）。
分类与消歧
技能在分配 L-code 前要求阅读 logic-risks.md 的 Quick Disambiguation Table，其中收录了常见误分类。重要的消歧规则包括：
- L4 优先检查：函数是否既修改输入又返回同一对象？
- L7 优先检查：共享状态是否在 await/yield/线程边界被访问且无显式同步？
- L4 与 L7：任何涉及多个执行上下文（线程/goroutine/await/yield）的状态访问都是 L7，绝不归为 L4——包括单线程 asyncio 中协程在 await 处交错的情况。L4 仅用于单上下文别名（可变默认参数、原地修改陷阱、迭代期间修改）。L4 要求以对共享/别名状态的实际修改为根因；变量作用域问题（const/let 可见性、构造器作用域）是 L1，查询模式低效（N+1）是 L3。
- L1 与 L6：如果根因是名称/标识符解析到了与开发者预期不同的定义（导入遮蔽、模块常量查找、原型链、构造器作用域的 const/let 对方法不可见），则为 L1；L6 仅适用于名称解析正确但被调用方行为与调用方假设不同。
- L2 与 L6：如果根因是操作符层面的隐式类型强制转换（+/-/*/== 触发字符串与数字转换，或 as/cast 绕过运行时类型检查），则为 L2；操作符不是被调用方。
- L5 与 L7：如果错误码、退出状态或异常被单上下文构造抑制（|| true、空 catch、缺少 set -e、裸 except），则为 L5（控制流逃逸）；L7 需要多个执行上下文。单一顺序脚本/函数内的错误传播失败属于 L5。
- L9 检查：如果根因是时区/区域设置/编码信息在数据类型层面丢失（例如 TIMESTAMP 与 TIMESTAMPTZ、朴素与带时区 datetime、依赖区域设置的字符串排序），则为 L9——即使看起来像“被调用方行为与预期不同”，也不是 L6，不是 L2，不是 L8。
Java/C++ DCL 规则
对于双重检查锁定模式，必须追踪两个面：(a) 缺失 volatile/内存屏障（可见性风险）；(b) instance = new X(); instance.init(); 作为两个非原子语句——无锁读取者可能在 init() 完成之前看到非空的 instance（发布先于初始化风险）。两者都必须报告，遗漏任何一个都是不完整的分析。
无缺陷场景纪律
当零偏差剩留时，仍要输出完整模板骨架——模式行、Scope、Logic Score: 100/100、## Findings，以及一个使用 Divergence: None — [why the premise holds]（中文 偏差：无——[原因]）并包含全部五个字段标签的发现块。这样使推理可审计并满足格式契约。如果分析主动证伪了一个疑似缺陷，在 Trace: 字段中解释该防御。不要把结论压缩成自由散文或省略结构化字段。
多发现纪律
当存在多条发现时，## Findings 内的每个发现块都必须包含全部五个字面字段标签，且内容针对该条发现。共享背景可以放在前言部分，但不能替代每条发现的字段。缺少 Divergence:（或任何其他必需字段）的发现会破坏契约。
修复演练
Step 6.5 要求在思维中重新通过修复后的代码追踪 Trigger 输入，确认：偏差消除、未引入回归、快乐路径保持。
配套材料可用性
本次目录副本包含上述内联指引，但不包含以下支撑路径。它们是外部前置条件，而非捆绑文件：
<support-root>/scripts/grade-iteration.py
从声明的上游来源或用户提供的该来源安装中获取所需材料。针对该安装解析每个路径，检查其内容，并核实任何适用的许可证与执行前提。在所需文件存在之前，不要运行命令，也不要声称已遵循某个引用步骤。不要伪造缺失的脚本，也不要把同名的无关文件视为等价。此处完整记录的独立步骤可在用户授权范围内进行；将任何依赖步骤报告为不可用。
设置
按 ../_shared/common.md §13 使用惰性加载：
- 仅在语言、Iron Law、Logic Score、范围管理、修复纪律、配置字段和加载预算方面阅读 ../_shared/common.md。
- 到达相应步骤时，只阅读 logic-review-guide.md 中相关的步骤。
- 在当前步骤需要时，按需加载 ../_shared/logic-risks.md、../_shared/semiformal-guide.md、../_shared/semiformal-checklist.md 和 ../_shared/report-template.md。
限制
仅在任务明确匹配其上游来源与本地项目上下文时使用此技能。
在应用更改之前，验证命令、生成的代码、依赖、凭据和外部服务行为。
不要将示例视为环境特定测试、安全审查或对破坏性/高成本操作的'用户批准'的替代品。