thrifty-check 是 thrifty 运行中的检查者（checker）子技能，职责是验证一个单元是否真正满足其验收标准，就地修复小的局部缺陷，并诊断剩余失败，以便编排器决定后续处理。它自身不升级、不重做整个单元、不重写计划，这些决策与循环计数由编排器负责。
用途：在 thrifty 运行中，当需要判断时被派发，对单个已完成单元进行核查。编排器已运行可运行门禁，因此检查者不应浪费 token 重新验证已通过的内容。
主要能力：
- 验证——只针对被调用的原因。读取工作目录下的 briefs/<UNIT-ID>.md 及 CONTRACT.md 的相关片段。若原因是失败门禁，则读取失败测试输出及其涉及的代码路径进行诊断，沿失败追踪，无需读整个模块，并自行重跑失败命令确认。若原因是断言性标准，则阅读产出物并判断这些标准（文字质量、引用、规范、设计），引用具体证据，跳过已通过门禁的代码。不信任执行器在受判维度上的自述，但也不重新推导已通过的门禁。相关时确认单元遵守了契约的跨单元形状/名称，不审计不在问题范围内的单元内部。
- 诊断——将单元归为恰好一类：pass（所有标准满足且遵守契约）、local（小的局部缺陷，简报合理，少量编辑即可修复）、execution（单元实质错误，但简报本身合理）、brief（标准按原文无法达成，或简报/契约错误、含糊、矛盾）。
- 外科手术式修复——仅当诊断为 local 时，自行尝试一次修复：记录当前通过的标准作为回归基线；做最小就地编辑修复失败标准，修复而非重新生成单元；重跑该单元全部标准；回归保护：若步骤 1 中通过的任何标准现在失败，说明修复引入回归，回退编辑并报告 diagnosis: execution（编排器将路由到新的执行器重做），绝不接受以一个新失败换另一个失败的修复；若所有标准现在通过，报告 diagnosis: pass。对于 execution 或 brief，不编辑，只报告，这些层级由编排器派发。
- 报告结构化裁决（最终消息）：包含 unit、criteria（每项 id、pass 布尔值、evidence 证据）、overall（pass|fail）、diagnosis（pass|local|execution|brief）、recommended_tier（0 无、1 外科手术由你完成、2 重做、3 重新规划）、surgical_attempted（true|false）、notes。notes 字段在升级时至关重要：对 execution 成为交给新执行器的纠正指导；对 brief 告诉架构师具体哪个跨单元决策需要修复。需具体并引用证据。
使用方式：作为 thrifty 工作流中的子技能被编排器派发，接收工作目录、单元 id 和检查原因（失败门禁或断言性标准）。
适用场景：需要判断单个单元是否满足验收标准、诊断失败类型、并对小局部缺陷进行就地修复的 thrifty 运行环节。
限制：不自行升级、不重做整个单元、不重写计划；不重复验证已通过的门禁；仅对 local 诊断尝试一次修复；修复引入回归时必须回退并报告 execution；对 execution 或 brief 不编辑只报告。