用 git refs 做 Issue 追踪

两个 AI Coding Agent 同时改同一个 repo，最先崩的通常不是代码，而是协作。Agent A 在重构鉴权，Agent B 此时毫无察觉地开始了同样的工作，而且因为上下文窗口是空的，它们根本不记得上次做了什么。如果用状态文件记录，会污染 diff 且频繁冲突；用外部追踪器又得处理 Token 和网络依赖。

我研究了一下 grite 的实现逻辑，它把 Issue 追踪直接塞进了 git 引用（git refs）里，通过一个只增（append-only）的事件日志和 CRDT 确定性合并，彻底解决了多写冲突。

核心逻辑：将 Issue 视为事件流

它不把 Issue 存为工作区的文件，而是存放在 refs/grite/wal 这个 git ref 中。无论是创建、评论还是改标签，都被编码成 CBOR 格式的不可变事件追加到日志里。

这种设计的精妙之处在于：状态随代码走。分支时同步分支，合并时同步合并，git push 即同步。不需要额外部署数据库，也不需要注册账号。

技术实现拆解

• git WAL (写前日志)： 绝对真理来源。每个事件通过 BLAKE2b 哈希生成 EventId，内容寻址保证了日志不可篡改。
• 物化视图 (Materialized View)： 使用 sled 嵌入式 KV 存储。它在启动时回放 WAL 日志，将事件投影为当前的 Issue 状态。这里引入了 CRDT 语义（标量字段用 LWW 最后写入胜出，标签用交换集），确保两个 Agent 在不同机器上修改同一个 Issue 后，合并结果在任何顺序下都完全一致。
• CLI 与 Daemon： 接口层。Daemon 负责维持 sled 视图的热加载，而 CLI 保证了独立运行的能力。

实操指南

虽然这是一个底层工具，但操作逻辑非常符合 git 习惯。以下是基本的实战流程：

# 初始化，会创建 AGENTS.md 方便 AI Agent 自动发现工具
grite init 

# 创建一个 Issue
grite issue create --title "Fix race in WAL append" \
 --body "Intermittent failure under high concurrency."

# 查看列表与更新标签
grite issue list
grite issue update --label bug --label concurrency

# 同步状态（本质是 git fetch + CRDT merge + push）
grite sync

这种方案最硬核的地方在于它把分布式系统的最终一致性问题，通过 git 的版本管理能力给解决了。对于构建复杂 AI Agent 工作流的人来说，这种本地化、无状态依赖的协作机制非常值得借鉴。