一种能力只有一个家

8 月 30 日我写了一份文档，只回答一个问题。我想做一件矩阵里还没有的事，它该长在哪个仓库里？

那时候矩阵已经有十几个项目。每加一样东西，我都得重新想一遍放哪。麻烦的地方在于，同一个问题隔几天再想，会得到不同的答案，于是同一种能力在两个仓库里各长一半，哪边都不完整。

文档的第一句就是「一种能力，一个家」。不建放杂物的仓库，同一种能力不许拆在两处。找不到家的东西，要么是归属还没想清楚，要么是真的需要一个新仓库。「先放这儿，以后再说」是唯一不许给的答案。

判归属按四个问题，按顺序问，第一个回答「是」的就是答案。先问它算不算某个现有项目的本职，算的话放进那个项目。再问它管的是不是矩阵本身，比如监控、台账、分发，这类事都归 yPulse。第三问，所有项目是不是都该继承它，比如统计和 SEO 的默认值，该继承就种进模板仓库。三问都落空，它又有自己的产物和用户，才建新仓库。

新仓库的代价我也写进去了。它要有自己的功能台账和发版流程，要接上 webhook，要写一份给 AI 读的说明文件。矩阵的总表多出一行，每个项目的配色还得往后挪一位。放进现有的仓库要便宜得多。

这份文档拦下过一个项目。9 月 4 日我把 yGraphify 移出了矩阵。它有两块内容，一块是设计体系的展示，一块是落地页的复刻。前一块是组件库 yBlocks 的本职，后一块是设计实验站 yLookbook 的本职。它从一开始就是同一种能力的第二个半成品，只是当时没人拿它去对那张分工表。一共 14 个提交，README 还是 create-next-app 生成的原文。

它也放行过一个新仓库。9 月 18 日建的 yListen 是一个 macOS 上的实时听译工具，要抓系统声音，要一个不抢焦点的悬浮窗，要在本机跑模型。矩阵里唯一做桌面小工具的 yTools 用的是 Tauri，而这个应用八成的难处都在苹果的接口那一侧，所以它用 Swift 原生，单独建仓。运行时不同，这是矩阵承认的分仓理由。我同时写明了不为它抽一套 Swift 模板，矩阵的规矩是同样的东西出现第二个实例时再抽，现在只有它一个。

后来又多了一条毕业的规矩，最早来自 yLookbook 的做法。东西先在实验场里诞生，和别的方案放在一起比，成熟了毕业进产品仓库，实验场里只留一条去向。毕业以后，产品仓库是事实的来源，实验场里那一条只是指针。

这条规矩现在有好几个例子。9 月底，数学影像从 yLookbook 独立成 yAtlas，有了自己的站点。10 月 1 日，yLookbook 里一个测量磁盘的页面毕业成了桌面应用 yIsobath，开始扫描真实的磁盘，出了安装包。10 月 3 日，「作图纸」系列反复用到的作图代码拆成了 yPlotter。拆出去以后，yLookbook 改成引用它打好的包，不再自己改。

引擎的门槛定得更高一些。同类作品超过五件才考虑抽离，而且一个引擎一个家，引擎仓库里只放引擎本身，具体的作品留在原来的仓库。导出视频、写导出清单这些各个引擎都要用的工具，统一放在 yReel，不在每个引擎里各造一套。10 月 10 日我要给视频加一种新的版本类型，改的就是 yReel 里那一份，yLookbook 和 yAtlas 各自换一次包就都有了。

规矩也有破例的时候。10 月 9 日，yLookbook 里搭微缩城市模型的那套代码提前拆成了 yDiorama。按规矩它还不够格，用到它的作品只有模型柜一件，导览片才是第二件。我还是决定先拆，这个例外和理由一起写进了文档。

不管是加进来还是移出去，理由都要留下。yGraphify 那一行现在还在文档最后「已移出」的表里，理由写了一大段，为的是半年后同一个想法换个名字回来的时候，有地方可查。