Click Path Audit

作者 affaan-mef648e01899ba3e8dc6371642deaaf64b4477775無授權條款275K 個星標收錄於 2026年10月9日更新於 2026年10月9日儲存庫4 天前更新

Trace every user-facing button/touchpoint through its full state change sequence to find bugs where functions individually work but cancel each other out, produce wrong final state, or leave the UI in an inconsistent state. Use when: systematic debugging found no bugs but users report broken buttons, or after any major refactor touching shared state stores.

僅含說明Software Development

AI 產生的概覽

透過追蹤狀態變化來稽核介面點擊處理程序，找出最終狀態與按鈕標籤不符的問題。

功能: 提供一套結構化流程來稽核互動式介面接觸點：先梳理每個狀態儲存操作及其設定或重設的欄位，再依序追蹤每個處理程序中的呼叫。它會檢查六類缺陷模式，包括順序撤銷、非同步競態、過期閉包、缺少狀態轉換、死路徑以及 useEffect 干擾。最後產出包含嚴重程度、接觸點位置、呼叫追蹤、預期與實際行為以及修正建議的報告。
適用情境: 適用於系統化除錯未發現缺陷但使用者回報按鈕無反應或行為異常的情況，也適用於重構共用狀態儲存之後。它還用於發佈前對關鍵使用者流程的檢查。
執行需求: 僅為說明文件，不含指令碼。需要存取目標應用程式的原始碼，包括元件處理程序與狀態儲存定義。

/click-path-audit — Behavioural Flow Audit

Find bugs that static code reading misses: state interaction side effects, race conditions between sequential calls, and handlers that silently undo each other.

The Problem This Solves

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.

How It Works

For EVERY interactive touchpoint in the target area:

1. IDENTIFY the handler (onClick, onSubmit, onChange, etc.)2. TRACE every function call in the handler, IN ORDER3. For EACH function call:   a. What state does it READ?   b. What state does it WRITE?   c. Does it have SIDE EFFECTS on shared state?   d. Does it reset/clear any state as a side effect?4. CHECK: Does any later call UNDO a state change from an earlier call?5. CHECK: Is the FINAL state what the user expects from the button label?6. CHECK: Are there race conditions (async calls that resolve in wrong order)?

1. IDENTIFY the handler (onClick, onSubmit, onChange, etc.)2. TRACE every function call in the handler, IN ORDER3. For EACH function call:   a. What state does it READ?   b. What state does it WRITE?   c. Does it have SIDE EFFECTS on shared state?   d. Does it reset/clear any state as a side effect?4. CHECK: Does any later call UNDO a state change from an earlier call?5. CHECK: Is the FINAL state what the user expects from the button label?6. CHECK: Are there race conditions (async calls that resolve in wrong order)?

Execution Steps

Step 1: Map State Stores

Before auditing any touchpoint, build a side-effect map of every state store action:

For each Zustand store / React context in scope:  For each action/setter:    - What fields does it set?    - Does it RESET other fields as a side effect?    - Document: actionName → {sets: [...], resets: [...]}

For each Zustand store / React context in scope:  For each action/setter:    - What fields does it set?    - Does it RESET other fields as a side effect?    - Document: actionName → {sets: [...], resets: [...]}

This is the critical reference. The "New Email" bug was invisible without knowing that selectThread resets composeMode.

Output format:

STORE: emailStore  setComposeMode(bool) → sets: {composeMode}  selectThread(thread|null) → sets: {selectedThread, selectedThreadId, messages, drafts, selectedDraft, summary} RESETS: {composeMode: false, composeData: null, redraftOpen: false}  setDraftGenerating(bool) → sets: {draftGenerating}  ...
DANGEROUS RESETS (actions that clear state they don't own):  selectThread → resets composeMode (owned by setComposeMode)  reset → resets everything

STORE: emailStore  setComposeMode(bool) → sets: {composeMode}  selectThread(thread|null) → sets: {selectedThread, selectedThreadId, messages, drafts, selectedDraft, summary} RESETS: {composeMode: false, composeData: null, redraftOpen: false}  setDraftGenerating(bool) → sets: {draftGenerating}  ...
DANGEROUS RESETS (actions that clear state they don't own):  selectThread → resets composeMode (owned by setComposeMode)  reset → resets everything

Step 2: Audit Each Touchpoint

For each button/toggle/form submit in the target area:

TOUCHPOINT: [Button label] in [Component:line]  HANDLER: onClick → {    call 1: functionA() → sets {X: true}    call 2: functionB() → sets {Y: null} RESETS {X: false}  ← CONFLICT  }  EXPECTED: User sees [description of what button label promises]  ACTUAL: X is false because functionB reset it  VERDICT: BUG — [description]

TOUCHPOINT: [Button label] in [Component:line]  HANDLER: onClick → {    call 1: functionA() → sets {X: true}    call 2: functionB() → sets {Y: null} RESETS {X: false}  ← CONFLICT  }  EXPECTED: User sees [description of what button label promises]  ACTUAL: X is false because functionB reset it  VERDICT: BUG — [description]

Check each of these bug patterns:

Pattern 1: Sequential Undo

handler() {  setState_A(true)     // sets X = true  setState_B(null)     // side effect: resets X = false}// Result: X is false. First call was pointless.

handler() {  setState_A(true)     // sets X = true  setState_B(null)     // side effect: resets X = false}// Result: X is false. First call was pointless.

Pattern 2: Async Race

handler() {  fetchA().then(() => setState({ loading: false }))  fetchB().then(() => setState({ loading: true }))}// Result: final loading state depends on which resolves first

handler() {  fetchA().then(() => setState({ loading: false }))  fetchB().then(() => setState({ loading: true }))}// Result: final loading state depends on which resolves first

Pattern 3: Stale Closure

const [count, setCount] = useState(0)const handler = useCallback(() => {  setCount(count + 1)  // captures stale count  setCount(count + 1)  // same stale count — increments by 1, not 2}, [count])

const [count, setCount] = useState(0)const handler = useCallback(() => {  setCount(count + 1)  // captures stale count  setCount(count + 1)  // same stale count — increments by 1, not 2}, [count])

Pattern 4: Missing State Transition

// Button says "Save" but handler only validates, never actually saves// Button says "Delete" but handler sets a flag without calling the API// Button says "Send" but the API endpoint is removed/broken

// Button says "Save" but handler only validates, never actually saves// Button says "Delete" but handler sets a flag without calling the API// Button says "Send" but the API endpoint is removed/broken

Pattern 5: Conditional Dead Path

handler() {  if (someState) {        // someState is ALWAYS false at this point    doTheActualThing()    // never reached  }}

handler() {  if (someState) {        // someState is ALWAYS false at this point    doTheActualThing()    // never reached  }}

Pattern 6: useEffect Interference

// Button sets stateX = true// A useEffect watches stateX and resets it to false// User sees nothing happen

// Button sets stateX = true// A useEffect watches stateX and resets it to false// User sees nothing happen

Step 3: Report

For each bug found:

CLICK-PATH-NNN: [severity: CRITICAL/HIGH/MEDIUM/LOW]  Touchpoint: [Button label] in [file:line]  Pattern: [Sequential Undo / Async Race / Stale Closure / Missing Transition / Dead Path / useEffect Interference]  Handler: [function name or inline]  Trace:    1. [call] → sets {field: value}    2. [call] → RESETS {field: value}  ← CONFLICT  Expected: [what user expects]  Actual: [what actually happens]  Fix: [specific fix]

CLICK-PATH-NNN: [severity: CRITICAL/HIGH/MEDIUM/LOW]  Touchpoint: [Button label] in [file:line]  Pattern: [Sequential Undo / Async Race / Stale Closure / Missing Transition / Dead Path / useEffect Interference]  Handler: [function name or inline]  Trace:    1. [call] → sets {field: value}    2. [call] → RESETS {field: value}  ← CONFLICT  Expected: [what user expects]  Actual: [what actually happens]  Fix: [specific fix]

Scope Control

This audit is expensive. Scope it appropriately:

Full app audit: Use when launching or after major refactor. Launch parallel agents per page.
Single page audit: Use after building a new page or after a user reports a broken button.
Store-focused audit: Use after modifying a Zustand store — audit all consumers of the changed actions.

Recommended agent split for full app:

Agent 1: Map ALL state stores (Step 1) — this is shared context for all other agentsAgent 2: Dashboard (Tasks, Notes, Journal, Ideas)Agent 3: Chat (DanteChatColumn, JustChatPage)Agent 4: Emails (ThreadList, DraftArea, EmailsPage)Agent 5: Projects (ProjectsPage, ProjectOverviewTab, NewProjectWizard)Agent 6: CRM (all sub-tabs)Agent 7: Profile, Settings, Vault, NotificationsAgent 8: Management Suite (all pages)

Agent 1: Map ALL state stores (Step 1) — this is shared context for all other agentsAgent 2: Dashboard (Tasks, Notes, Journal, Ideas)Agent 3: Chat (DanteChatColumn, JustChatPage)Agent 4: Emails (ThreadList, DraftArea, EmailsPage)Agent 5: Projects (ProjectsPage, ProjectOverviewTab, NewProjectWizard)Agent 6: CRM (all sub-tabs)Agent 7: Profile, Settings, Vault, NotificationsAgent 8: Management Suite (all pages)

Agent 1 MUST complete first. Its output is input for all other agents.

When to Use

After systematic debugging finds "no bugs" but users report broken UI
After modifying any Zustand store action (check all callers)
After any refactor that touches shared state
Before release, on critical user flows
When a button "does nothing" — this is THE tool for that

When NOT to Use

For API-level bugs (wrong response shape, missing endpoint) — use systematic-debugging
For styling/layout issues — visual inspection
For performance issues — profiling tools

Integration with Other Skills

Run AFTER /superpowers:systematic-debugging (which finds the other 54 bug types)
Run BEFORE /superpowers:verification-before-completion (which verifies fixes work)
Feeds into /superpowers:test-driven-development — every bug found here should get a test

Example: The Bug That Inspired This Skill

ThreadList.tsx "New Email" button:

onClick={() => {  useEmailStore.getState().setComposeMode(true)   // ✓ sets composeMode = true  useEmailStore.getState().selectThread(null)      // ✗ RESETS composeMode = false}}

onClick={() => {  useEmailStore.getState().setComposeMode(true)   // ✓ sets composeMode = true  useEmailStore.getState().selectThread(null)      // ✗ RESETS composeMode = false}}

Store definition:

selectThread: (thread) => set({  selectedThread: thread,  selectedThreadId: thread?.id ?? null,  messages: [],  drafts: [],  selectedDraft: null,  summary: null,  composeMode: false,     // ← THIS silent reset killed the button  composeData: null,  redraftOpen: false,})

selectThread: (thread) => set({  selectedThread: thread,  selectedThreadId: thread?.id ?? null,  messages: [],  drafts: [],  selectedDraft: null,  summary: null,  composeMode: false,     // ← THIS silent reset killed the button  composeData: null,  redraftOpen: false,})

Systematic debugging missed it because:

The button has an onClick handler (not dead)
Both functions exist (no missing wiring)
Neither function crashes (no runtime error)
The data types are correct (no type mismatch)

Click-path audit catches it because:

Step 1 maps selectThread resets composeMode
Step 2 traces the handler: call 1 sets true, call 2 resets false
Verdict: Sequential Undo — final state contradicts button intent

來源與署名

來源：affaan-m/ECC位於skills/click-path-audit提交ef648e0

授權條款：無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架

Click Path Audit

/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

Pattern 3: Stale Closure

Pattern 4: Missing State Transition

Pattern 5: Conditional Dead Path

Pattern 6: useEffect Interference

Step 3: Report

Scope Control

Recommended agent split for full app:

When to Use

When NOT to Use

Integration with Other Skills

Example: The Bug That Inspired This Skill

來源與署名

更多來自 affaan-m/ECC 的技能

Unified Notifications Ops

Verification Loop

Ui To Vue

Unified Memory

Visa Doc Translate

Team Builder

更多Software Development技能

Playground

M5 Onboard

Cardputer Buddy

Web Design Guidelines

Vercel React Native Skills

Vercel React Best Practices