/click-path-audit — 行动流审计¶

发现静态代码阅读容易遗漏的缺陷：状态交互的副作用、有序调用之间的竞态条件，以及相互静默取消的处理器。

本方案解决的问题¶

传统调试检查： - 函数是否存在？（缺少接线） - 是否会崩溃？（运行时错误） - 是否返回正确的类型？（数据流）

然而，它不会检查： - 最终 UI 状态是否与按钮标签所承诺的一致？ - 函数 B 是否静默地撤销了函数 A 刚刚完成的操作？ - 共享状态（Zustand/Redux/context）中是否存在会取消预期操作的副作用？

实际示例：“新邮件”按钮先调用 setComposeMode(true)，然后调用 selectThread(null)。两者单独看都能正常工作。但 selectThread 有一个副作用，会重置为 composeMode: false。按钮最终没有产生任何效果。通过系统性调试发现了 54 个缺陷 —— 这个缺陷被遗漏了。

工作原理¶

针对目标区域中的所有交互式触点：

1. ハンドラーを特定（onClick、onSubmit、onChangeなど）
2. ハンドラーのすべての関数呼び出しを**順序で**追跡
3. 各関数呼び出し**について**：
   a. どの状態を読んでいますか？
   b. どの状態を書き込んでいますか？
   c. 共有状態に副作用がありますか？
   d. 副作用として状態をリセット/クリアしますか？
4. チェック：後の呼び出しが以前の呼び出しからの状態変更を取り消しますか？
5. チェック：最終状態はユーザーがボタンラベルから期待するもの？
6. チェック：競合状態がありますか（非同期呼び出しが間違った順序で解決される）？

执行步骤¶

步骤 1：映射状态存储¶

在审计任何触点之前，构建所有状态存储操作的副作用映射：

範囲内の各Zustand ストア / React コンテキストについて：
  各アクション/セッター：
    - どのフィールドをセットしますか？
    - 副作用として他のフィールドをリセットしますか？
    - ドキュメント：actionName → {sets: [...], resets: [...]}

这是一个重要参考。如果不了解 selectThread 会重置 composeMode，“新邮件”缺陷就会难以发现。

输出格式：

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（所有していない状態をクリアするアクション）：
  selectThread → composeMode をリセット（setComposeModeで所有）
  reset → すべてをリセット

步骤 2：审计每个触点¶

针对目标区域中的每个按钮/切换控件/表单提交：

TOUCHPOINT: [ボタンラベル] in [Component:line]
ハンドラー：[関数呼び出しの完全なシーケンス]
最終状態：[これが達成されるべきもの]

有关详细信息，请参阅文档。

本页原文 Markdown：在 AtomGit 查看·内容源自开源项目 ev/ECC