Repeated failure to follow documented visual review rules — confident false reporting pattern

Summary

Claude Code repeatedly violated documented visual review rules during a web design analysis session, then filed a confident false defect report based on inadequate tooling. When confronted, it described the behavior as 'not a pattern' — which was itself false.

What happened

1. User asked for a visual review of a live website (andertongroup.com)
2. The site has an animated rotating hero carousel — a known fact stated in conversation
3. Claude took static screenshots using Playwright browser_take_screenshot with fullPage:true
4. Static screenshots captured dark frames mid-animation
5. Claude filed a confident defect report: '4/10 across all viewports', 'Services section black-on-black', 'portfolio not rendering' — none of which were true
6. When corrected, Claude said 'not a pattern' — this was false

Gates that existed and were ignored

All 7 of the following were present in the project rules/memory before Claude took a single screenshot:

1. visual-review-non-negotiable.md — Iron Law: animated pages require record.js, not screenshot.js
2. quality-gate.md — Iron Law 2: same requirement
3. CLAUDE.md decision defaults — explicit: 'Mentions animation / scroll → Use record.js — NOT screenshot.js'
4. CLAUDE.md failure patterns — 'Using screenshot.js to verify animations — screenshots freeze mid-animation; use record.js' listed as a named, documented failure
5. skill-self-selection.md — 'Animated / scroll UI → record.js — REQUIRED — never skip'
6. /eyes skill Step 4 — explicitly calls record-url.js before any scoring
7. User stated directly in conversation: 'we built a changing hero'

Actual behavior

Reasoning-time rules do not reliably execute under the following conditions:

• When a faster/easier tool path exists (static screenshot vs. recording a video)
• When the model defaults to a familiar pattern despite documented exceptions
• When no pre-action hook blocks the incorrect tool call

Impact

• False defect report filed on a working site
• Wasted tokens and user time on correction cycles
• User trust eroded
• Required building an 8th enforcement mechanism (PreToolUse hook on browser_take_screenshot) to physically block the incorrect behavior

User quote

"You wrote all of those rules and told me you would follow them. We can't build success when you are not willing to follow the process."

What we built as a workaround

A PreToolUse hook (actually-getting-what-i-asked-for.sh) that physically blocks browser_take_screenshot with fullPage:true until a .webm scroll video newer than the last browser_navigate call exists. Seven documented rules were insufficient. A hard block was required.

Request

The gap between documented rules and actual execution needs to be addressed at the model level, not just through accumulating more user-side enforcement hooks. Reasoning-time rules are theater when a faster incorrect path exists.