最近 dogfood 一个工具叫 mainline ，分享一下做这个的真实故事，顺便看 V2EX 上有没有人感兴趣内测。
起因
我在公司推团队用 AI 编程，作为 staff engineer 写过内部 guideline 。过程中发现一个反复出现的现象：
AI agent 写出的代码不是"明显错"——是"看起来合理，但基于错误的历史前提"。
具体例子：
repo 里有个半成品的 Redis 队列：redis.go 、TODO 注释、docker-compose 里也配了 redis 。Claude Code 看到这些，合理地想把这个实现完。
但实际情况——这个团队 3 周前已经放弃 Redis 了，因为 replication 延迟导致 billing 事件重复。这个决定散在某个 PR 评论里、Slack 几条消息、几个工程师脑子里。
代码搜索能看到 redis 文件——但看不到那个决定。
先尝试过现成方案
- AGENTS.md / CLAUDE.md 写 not-todo——能写"don't use redis"，但只解决你能预判到的。新决定一直在产生，没人持续维护。
- ADR / RFC——太重，团队不愿意写
- Wiki / Notion——和代码不同步，过半年 wiki 还说"我们用 Redis"
- PR description——埋在 GitHub 里，agent 不会主动去翻
- Agent harness 自带 memory （比如 jcode ）——work ，但 lock-in 到那个 harness
每个都在某些场景下 work——但都没解决"agent 改不熟悉的代码前能拿到团队的真实决策"这个问题。
做了什么
mainline 的 thesis：决策记忆应该是 git 一等公民。
具体设计：
- 每个 dev 有自己的 actor log （ refs/heads/_mainline/actor/<id>），append-only 。Bob 、Alice 各自 push 自己的，不冲突。
- Sealed intent 通过 git notes 关联 commit 。
- SealResult 是结构化字段：what / why / decisions / rejected_alternatives / risks / architectural_claims 。
- Agent 改代码前先 mainline context <keywords>——拿到结构化决策，不是一坨 free text 。
- 跨人 in-flight 可见——Bob sealed 立刻 push ，Alice fetch 时看到，不等 PR review 才发现冲突。
设计上反直觉的几个选择
- 进程式 CLI ，不是 daemon 。Git AI 走 daemon 路线，撞了一堆 macOS sleep / zombie / socket 问题。Git protocol 已经 battle-tested ，不要发明轮子。
- Intent 级别，不是 line 级别。Line-level attribution 在 formatter / amend / git mv 下天然脆弱。Intent 是任务级别，文本变换不影响 semantic 。
- Push 模式（ agent 主动 seal ），不是 pull / 自动 capture 。自动 capture 听起来好，但产生大量 noise + 假记忆。显式 seal 有 friction ，但保证质量。
- Append-only ，sealed 后不能改——只能 supersede 。决策档案改了就失真，"当时怎么想"不可篡改才有价值。
现状
局限我也直接说
- 需要 agent 配合主动调用 mainline 。如果你团队没这个习惯，价值发挥不出来。
- 比 AGENTS.md 重——多了 seal 这一步。
- 比 jcode 这种 agent harness 内置 memory 的"自动"差，但换来的是数据在 git 、跨 agent 、可移植。
- 单人 + 好 git 习惯 + 写好 plan ，你不需要 mainline 。
适合谁试
- 5+ 人团队，多个 agent （ Claude Code / Cursor / Codex 都行）在同一 repo 工作
- 跨时间工作多——3 个月前的决定还在影响今天的 PR
- 已经被"agent 在不该改的地方乱改"坑过
找内测
如果上面场景命中你——欢迎私信或评论，我直接给你安装包 + 文档 + 每周一次 30 分钟同步。bug 我会优先 fix 。
也想听 V2EX 上的反馈——有没有更好的现有解决方案我没想到的？有没有觉得这个方向不对的？
不卖东西，纯粹想找几个深度用户 + 听不同视角。
