kadence

我每天都在和编程代理打交道，昂贵的从来不是写代码本身 — 而是反复解释。每个新会话，代理都会重新读一遍同样的文件，然后提出我们上周已经否决过的方案。队友的代理对此同样一无所知：那份记忆是按用户、按机器隔离的。

所以 kadence 把缺失的这一层放在了代码仓库本身 — 一个仅追加的日志，每个事件一个 JSON 文件，与代码一起提交。内容既不会被修改也不会被删除，因此 `kadence task show KAD-1` 能回答「我们是怎么走到这一步的」，而 `--json` 无论项目里有十个还是一千个任务，都能把同样的答案以大约 1KB 的体积交给代理。

有两件事我宁愿提前说清楚，而不是让你们自己去发现：

• 由于是仅追加的，两个人在不同分支上编辑同一个任务，不会产生合并冲突。我们在动手之前统计了 130 个使用基于文件的追踪器的公开仓库中的 8,396 次合并提交 — 其中 15% 在任务文件上发生了冲突，而这其中 89% 正是日志结构可以消除的那一类。

• 我们尚未证明的是：团队在会话之间丢失的上下文真的多到值得为此引入一个日志。这个赌注押在推理上，而不是押在用户身上 — 用户访谈还没开始做。如果最后发现代理靠 `git log` 就能应付自如，那这个立论就站不住脚。

MIT 许可，免费，零网络请求。要离开只需要 `rm -rf .kadence` — 你的事件就是普通的 JSON，不依赖我们也能读取。

我最希望从你这里得到的：如果你们团队在使用代理，请告诉我上一次会话不得不重新学习的那些东西。这正是我想消灭的东西。

npm install -g kadence && kadence init