用途：在任务派发前检测拟议 T4 任务与 pending-confirm 同级任务之间的冲突，避免覆盖或矛盾。
主要能力：按规范 §21.1 定义五类冲突——C1 文件级重叠（L1，免费）、C2 函数/区域重叠（L2，约 10ms 正则）、C3 schema/契约冲突（L2）、C4 语义意图冲突（L3，beta.2 占位）、C5 架构冲突（L4，beta.2 占位）。派发流程：先跑 check-l1-files.sh；若重叠且置信度≥0.95 直接返回冲突，低置信度则用 check-l2-syntactic.sh 深入重叠文件；tier≤2 或创建新模式时检查 L4，存在 pending-confirm 同级时检查 L3。发现冲突写入 .claude/plans/conflicts.jsonl，记录 conflict_id、layer、type、participants、overlap、confidence 等字段，由 conflict-arbiter 后续填充仲裁与解决。
使用方式：由 hooks/pre-dispatch-conflict-check.cjs 在 PreToolUse 自动触发，post-execute-conflict-rescan.cjs 在阻塞完成后重扫冻结任务；也可用 /aura-frog:plan-conflicts 手动列出/查看/解决。设置 AF_CONFLICT_LLM_DISABLED=true 可短路 L3+L4 派发，L1+L2 始终运行。
限制：beta.2 不执行 L3/L4（返回占位）；不修改计划树状态，仅写 conflicts.jsonl；不决定解决方式；不直接阻塞工具调用；不跨项目边界。延迟目标 L1 p95<100ms、L2<300ms、L3/L4 缓存<50ms，冷启动 L3<3s、L4<8s（rc.1）；超硬上限则记录警告并按存在冲突处理。