click-path-audit

Topics in the source

• /click-path-audit — Behavioural Flow Audit
• The Problem This Solves
• How It Works
• Execution Steps
• Step 1: Map State Stores
• Step 2: Audit Each Touchpoint
• Pattern 1: Sequential Undo
• Pattern 2: Async Race

Find bugs that static code reading misses: state interaction side effects, race conditions between sequential calls, and handlers that silently undo each other. Traditional debugging checks: Does the function exist? (missing wiring) Does it crash? (runtime errors) Does it return the right type? (data flow) But it does NOT check: Does the final UI state match what the button label promises? Does function B silently undo what function A just did? Does shared state (Zustand/Redux/context) have side effects that cancel the intended action? Real example: A "New Email" button called setComposeMode(true) then selectThread(null). Both worked individually. But selectThread had a side effect resetting composeMode: false. The button did nothing. 54 bugs were found by systematic debugging — this one was missed. -- For EVERY interactive touchpoint in the target area: -- Before auditing any touchpoint, build a side-effect map of every state store action: This is the critical reference. The "New Email" bug was invisible without knowing that selectThread resets composeMode. Output format: For each button/toggle/form submit in the target area: Check each of these bug patterns: For each bug found: -

This is an excerpt. Refer to the complete source and its current requirements.