用跟踪文档作为任务唯一事实来源：适用于功能开发…

在开始一个功能、缺陷修复或多步骤任务时，把一份跟踪文档设为该任务的唯一事实来源，并随工作进展持续更新。

适用场景

解决思路

1. 激活后，把跟踪文档（`$path`）当作活的记录，在以下情形后更新它：任何决策（架构、设计、范围、命名等）做出后。
2. 发现新问题、bug 或边界情况后。
3. 出现新的子功能或需求后。
4. 问题被提出或解决后。
5. 完成任何重要实现工作后。
6. 与用户对话中出现日后值得回忆的关键内容后。
7. 每次提交文件时——提交是强烈信号，提示也应检查并更新跟踪文档。
8. 形成任何计划时——把计划写入文档，而不是只在聊天中展示；文档才是持久记录。
9. 若有疑问就更新文档；宁可记录过多，也不要丢失上下文。
10. Git 处理：除非跟踪文档已出现在仓库的 git 历史中，否则不要提交它；如果文件未被 git 跟踪，就把它排除在任何提交之外。
11. 保持更新简洁——优先使用项目符号和短段落，而不是长篇散文。
12. 当文档跨多个会话时，使用时间戳或日期标题。
13. 记录决策背后的 *为什么*，而不只是 *是什么*。
14. 当某部分过时或无关时，把它移到 "Archive" 或 "Resolved" 部分，而不是删除。
15. 如果文档尚不存在，根据当前任务创建它并给出合理的结构。

适用边界 · 注意事项

• 不要把跟踪文档提交到 git，除非它已经被仓库跟踪。
• 不要只把计划放在聊天中而不写入文档。
• 不要把过时内容直接删除，而应归档。