Taku Debug — Taku 调试

taku-debug — 4阶段根因调查 随意的修复会产生新的bug。系统性的调查可以找到根因。这项技能将Superpowers的系统性调试和gstack的调查工作流合并成一个统一的4阶段过程。 规则标签：[IRON LAW]表示不可商量的正确性约束。[GUIDANCE]表示强烈的默认值，可以在上下文合理时进行调整。 何时使用此技能 使用taku-debug时： VERIFY阶段失败且失败路径尚不清楚 用户报告破损行为、回归或间歇性问题 需要解释为什么某事失败，然后再提出修复方案 不要仅仅为了运行常规验证而使用taku-debug。先运行仓库的正常检查。如果这些检查失败或生产行为已经破损，则进入此技能。 铁律 [IRON LAW] 在提出修复之前必须进行根因调查。每个不解决根因的修复都会使下一个bug更难找到。如果您尚未完成第1阶段（INVESTIGATE），则无法提出修复。违反此过程的字母就是违反调试的精神。 强制序列执行： 在编写任何代码更改之前，您必须： 完成第1阶段（INVESTIGATE）- 收集证据、重现、跟踪数据流 完成第2阶段（PATTERN）- 匹配已知模式 完成第3阶段（HYPOTHESIS）- 排序和测试假设 只有在完成所有三个阶段后，才能继续到第4阶段（IMPLEMENT）。如果您发现自己在产生DEBUG REPORT之前编写修复，请停止并返回到第1阶段。 4个阶段 第1阶段：INVESTIGATE 在形成任何假设之前收集背景信息。这是证据收集，而不是问题解决。为什么先收集证据：跳过理解问题直接跳到解决方案是调试中最常见的失败。您修复您认为错误的东西，而不是真正错误的东西。先收集证据可以防止这种偏见。 阅读错误。堆栈跟踪、错误消息、日志输出。阅读所有内容。行号、文件路径、错误代码- 所有这些。错误消息通常包含答案。 一致地重现。确切的步骤是什么？每次都会发生吗？如果无法重现，请收集更多数据。不要对间歇性bug进行猜测。 检查最近的更改。git log --oneline -20 -- git diff HEAD~1 -- 之前是否正常工作？什么变化了？回归意味着根因在diff中。 向后跟踪数据流。坏值从哪里来？哪个函数调用了带有坏值的函数？继续跟踪直到找到源头。在源头修复，而不是在症状上修复。 在多组件系统中收集证据。当系统有层次（API → 服务 → 数据库）时，在每个边界添加诊断日志。运行一次。查看哪里破损。然后调查该层。 预算检查：如果INVESTIGATE超过10分钟或产生> 20个证据项而没有收敛到根因假设，请暂停并展示到目前为止的发现。这不是失败-这是范围感知调查。复杂的分布式系统有时需要在继续之前缩小范围。 输出：根因假设-一个关于什么是错误的以及为什么错误的具体可测试的说法。 第2阶段：PATTERN 在提出解决方案之前将bug与已知模式进行匹配。为什么先匹配模式：大多数bug都是已知故障模式的实例。识别模式可以告诉您哪里可以查找和检查什么，从而将调查时间从几个小时缩短到几分钟。新bug很少见；您的bug几乎可以肯定以前发生过。 模式签名 哪里可以查找 竞争条件 间歇性、时间依赖 共享状态、并发访问 空值传播 类型错误、NoMethodError 缺少可选值的保护 状态损坏 不一致的数据、部分更新 事务、回调、钩子 集成失败 超时、意外响应 API边界、服务调用 配置漂移 本地工作，远程失败 环境变量、功能标志、秘密 过时的缓存 显示旧数据 Redis、CDN、浏览器缓存 还要检查： 同一代码库中的工作示例-什么做得对？ TODOS.md中相关的已知问题 Git日志中同一区域的以前修复 同一文件中的反复出现的bug是架构上的臭味，而不是巧合。 .taku/learnings/{project-slug}.jsonl - 来自以前调试会话的类似bug模式、以前的根因、已知的陷阱 如果模式不明显，请在网上搜索"{框架} {错误类型}"（先清理：删除主机名、IP、文件路径、客户数据）。 值得早期检查的常见故障模式： 配置漂移：文档、默认值、环境名称或运行时查找不一致。 边界不匹配：调用者和被调用者关于可空性、身份验证或所有权的意见不一致。 状态竞争：异步排序、缓存或生命周期清理更改了后续代码看到的内容。 平台路径/权限漂移：Windows、符号链接、可执行位或临时路径的行为不同。 第3阶段：HYPOTHESIS 形成排名假设