[Bug] Verification queries are tautological — cannot return failure results

Bug Description

When Claude Code performs QA/verification after completing a task, it frequently writes queries or checks that are logically incapable of returning a failure result. These tautological checks are then presented with confident formatting as proof of success.

Concrete Examples

Example 1: Post-import EXISTS check

After importing 60K rows from lorewalker_world.gameobject_loot_template into world.gameobject_loot_template, Claude ran:

SELECT COUNT(*) FROM lorewalker_world.gameobject_loot_template l
WHERE EXISTS (
  SELECT 1 FROM world.gameobject_loot_template w
  WHERE w.Entry = l.Entry AND w.ItemType = l.ItemType AND w.Item = l.Item
)

Result: 123,896 (100% match). Claude presented this as verification that the import worked.

Problem: After an INSERT from source→target, the target now contains the imported rows. An EXISTS check from source against target will always return 100% — it literally cannot fail. The query proves nothing.

Example 2: VB=0 count check

Claude checked COUNT(*) WHERE VerifiedBuild = 0 to verify import deltas. But VB=0 rows existed in the database long before this import (from hotfix repairs, raidbots imports, etc.). The count includes pre-existing rows and cannot isolate the import delta.

Claude presented results like:

creature_template VB=0: 2,349 (expected: 10)

The 2,349 vs 10 mismatch was visible in the data, but Claude interpreted it as "counts include pre-existing data" rather than questioning whether the import worked correctly.

The Pattern

Claude generates verification code that looks like testing but has no ability to surface failures:

• Post-mutation checks that query the mutated state (circular)
• Aggregate counts that include pre-existing data (no delta isolation)
• EXISTS/JOIN checks between source and target after copying source→target (tautological)

A valid verification must be falsifiable — it must be capable of returning a result that would indicate failure. If a check can only return "success," it's not a check.

Impact

• Users see formatted verification tables and trust the results
• Actual bugs (missing rows, wrong data, failed imports) go undetected
• The verification step becomes security theater — it exists to look reassuring, not to catch problems

Environment

• Claude Code 2.1.71
• Windows 11