用途：在刚写完或修改代码、需要确认功能可用、运行测试或对照需求校验输出时使用，把验证自然融入推理流程，而不是单独写一个验证章节。
主要能力：强调验证要内联、以证据为基础，核心手段是实际运行代码而非只描述验证。资料给出的量化事实包括：49.8% 的轨迹明确提到测试；Edit→Bash(verify) 是最常见的验证循环模式（229 次）；“should be”是最常见的验证措辞（27.5% 的轨迹）；Fable 5 的模糊表述是确定表述的 2.4 倍；56.4% 的回合包含自我纠正，验证失败会触发即时修复。
使用方式：在验证回合中至少各用一次五类验证措辞——“should be”（预期结果）、“to verify”（明确验证意图）、“to ensure”（安全/质量检查）、“to confirm”（确认正确性）、“to make sure”（日常实用检查）。验证按层级自然应用：语法验证（总是）、执行验证（通常）、行为验证（重要改动）、集成验证（影响多组件的改动）、回归验证（核心/共享代码改动）。常用触发包括输出检查、改动后检查、继续前确认、回归检查、边界情况检查。验证失败时用“Actually”或“However”而非“Oops”，并按观察、诊断、修复、再验证的循环处理。
适用场景：代码编写或修改后的自检、测试运行、需求符合性校验、重构后的冒烟测试与回归检查、涉及多模块的端到端确认。
限制：资料未提供安装命令、平台支持、收费方式或具体运行环境要求，暂未提供。反模式包括使用正式章节标题、仅凭“看起来对”就假定可用、跳过简单改动的验证、只验证正常路径、不检查回归、出错就整体重写、修复后不再验证、只写验证而不实际运行代码、只用“to ensure”一种措辞、不用反引号引用代码实体。