click-path-audit

原文涵盖的主题

• /click-path-audit — 行为流审计
• 解决的问题
• 工作原理
• 执行步骤
• 步骤 1：映射状态存储
• 步骤 2：审计每个触点
• 模式 1：顺序撤销
• 模式 2：异步竞态

发现静态代码审查遗漏的缺陷：状态交互副作用、顺序调用间的竞态条件，以及相互静默撤销的处理程序。 传统调试检查： 函数是否存在？（缺少连接） 是否崩溃？（运行时错误） 是否返回正确类型？（数据流） 但未检查： 最终 UI 状态是否与按钮标签承诺一致？ 函数 B 是否静默撤销了函数 A 刚刚执行的操作？ 共享状态（Zustand/Redux/context）是否存在抵消预期操作的副作用？ 真实案例：一个"新邮件"按钮依次调用了 setComposeMode(true) 和 selectThread(null)。两者单独工作正常。但 selectThread 有一个副作用重置了 composeMode: false。按钮毫无反应。系统化调试发现了 54 个缺陷——这个被遗漏了。 针对目标区域内的每个交互触点： 在审计任何触点之前，构建每个状态存储操作的副作用映射： 这是关键参考。"新邮件"缺陷在不知道 selectThread 重置了 composeMode 的情况下是不可见的。 输出格式： 针对目标区域内的每个按钮/开关/表单提交： 检查以下每种缺陷模式： 针对发现的每个缺陷： 此审计成本较高。请适当限定范围： 全应用审计： 在发布或重大重构后使用。按页面启动并行代理。 单页面审计： 在构建新页面或用户报告按钮失效后使用。 存储聚焦审计： 在修改 Zustand 存储后使用——审计所有使用已更改操作的消费者。 代理 1 必须首先完成。其输出是所有其他代理的输入。 系统化调试发现"无缺陷"但用户报告 UI 失效后 修改任何 Zustand 存储操作后（检查所有调用者） 任何涉及共享状态的重构后 发布前，针对关键用户流程 当按钮"无反应"时——这是解决该问题的工具 针对 API 级别缺陷（错误的响应结构、缺失端点）——使用系统化调试 针对样式/布局问题——视觉检查 针对性能问题——性能分析工具 在 /superpowers:systematic-debugging（发现其他 54 种缺陷类型）之后运行 在 /superpowers:verification-before-completion（验证修复是否有效）之前运行 反馈至 /superpowers:test-driven-development——此处发现的每个缺陷都应添加测试 ThreadList.tsx "新邮件"按钮： 存储定义： 系统化调试遗漏了它，因为： 按钮有 onClick 处理程序（未失效） 两个函数都存在（无缺失连接） 两个函数均未崩溃（无运行时错误） 数据类型正确（无类型不匹配） 点击路径审计捕获了它，因为： 步骤 1 映射出 selectThread 重置了 composeMode 步骤 2 追踪处理程序：调用 1 设置为 true，调用 2 重置为 false 判定：顺序撤销——最终状态

这里只展示节选，请以完整原文和当前要求为准。