用途：在会话结束前对本次工作做对抗式压力测试，用不共享你盲点的审查者来检查成果，避免自我确认。调用方式通常为显式调用 /session-review，不要指望自动触发。
主要流程：一、组装简报，这是关键步骤。写一份自包含的 markdown 简报（例如 /tmp/<repo>-session-review.md），它是审查者唯一获得的上下文，需包含贴合工作的角色设定（如功能切片用 Principal Engineer、认证工作用 Security reviewer）、陌生人可理解的项目背景、会话目标、构建内容及具体 file:line 引用、最想被挑战的决策点，以及涉及当前最佳实践时明确要求联网核查并给出出处。同时要告知代码阅读者“不要信任这份摘要，去读实际文件”。
二、并行运行审查者（同一条消息中）。审查者 A 为隔离的代码阅读者，指向简报和实际文件，并附带时效性指令：联网核查所选库、运行时、模式今年是否仍是最佳选择并引用来源。审查者 B 为外部家族模型（如可用），仅依据简报审查，用于概念与技术时效性，而非文件级事实。只有 A 一个审查者时仍算轻量审查，需注明缺失并继续。
三、综合：独立得出相同发现属高置信信号，应提升；分歧处按事实裁决，代码事实以代码阅读者为准，不数票。
四、行动：低成本、安全、影响面小的修复本次立即应用，并用 typecheck、lint、测试等产物验证；较大项转为带度量指标的待办；对不认同的发现写明理由反驳。
五、度量结果：统计发现、应用、计划、反驳的数量，以及遗漏项和更新的技术时效性事实。
六、对系统做回顾：哪些基础元素（规则、MEMORY 行、交接、模式）确有价值，哪里产生摩擦或缺口，编排是否得当；输出最多 1-3 条有证据支撑的最小调整，偏向先减后加。
限制与护栏：绝不盲从接受，带理由拒绝发现是成功；按风险而非重要性区分“现在”与“计划”；按工作量缩放，小会话用轻量简报和单一审查者，架构变更才用完整多审查者流程。详细裁决程序见 reference/orchestrator-fact-check.md，并行开发默认与停止条件见 reference/parallel-development.md，审查循环见 reference/review-loop.md。