ds-unstick

ds-unstick

当两个修复都以相同方式失败时，问题通常出在错误的认知，而不是错误的修改。找出这种认知并进行验证。

步骤

1. 停止修改。不要再尝试第三种相同修复的变体。
2. 用一行记录每次失败的尝试：你改了什么，以及发生了什么。包含确切的错误文本。
3. 写下所有尝试共同依赖的假设。常见示例：“这个文件才是实际运行的文件”“配置已加载”“函数接收的是字符串”“缓存已清除”“错误来自我的代码”。用一句话指出一个假设。
4. 用最简单、能得到是或否答案的探针直接验证这个假设：打印语句、日志行、which 或 --version、搜索实际调用位置的 grep、最小脚本，或查阅所安装确切版本的文档。粘贴结果。
5. 如果假设不成立，就找到了真正的问题。根据新事实规划修复。
6. 如果假设成立，列出 3 种不同的方法。“不同”是指采用另一种机制、库、层或数据路径，而不是微调同一处修改。每种方法用一行说明成本和风险。
7. 用一句话说明选择某种方法的原因。
8. 如果失败的尝试留下了残留，先恢复到干净状态：使用 git 撤销它们（git stash 或 git checkout -- <files>），然后只应用选定的方法。
9. 在 PROGRESS.md 中记录错误的假设或选定的方法（参见 ds-context-reset），以免后续会话重复这些尝试。
10. 使用新方法返回 ds-verify-loop。

停止条件

• 第 4 步中的探针解释了失败原因，或新方法通过了检查。
• 连续两轮使用此技能都失败。停止并向用户报告：已进行的尝试、已验证的假设以及证据。请用户指示下一步。

规则

• 不要重复已经失败的修复，即使只做了小幅修改也不行。
• 证据胜过推理。如果探针只需一分钟，就运行它。
• 保留失败尝试的列表，因为它是报告中最有用的部分。
• 使用新方法前先恢复到干净状态，以免旧修改掩盖结果。