我不打开它，它也在干活
7 月 6 日我写了 yPulse 的第一份规划，那时它还叫 Pulse。规划的第一句话说，它是一条数据管道。下面列了几条原则。推送要排在仪表盘前面，因为要主动去看的仪表盘，最后都会没人看。原始数据从第一天起全量保存，分析的写法以后会反复改，只要原始数据在，就能回头重算。还有一条是控制投入，第一版限定在两三天里，之后每加一块都要先问一句值不值。
第一版 7 月 10 日做完，前后四天。之后一块一块加上去，yPulse 现在有 944 个提交。规划的第一句倒是一直成立，它大部分时候没人打开，自己在跑。下面这张图是它自己的一个页面，画的是它背后的六条工作流。
yPulse 如何驱动自己
看板背后的每一条管线，什么启动它，它写下什么，最后落到哪里。
观测数据经「提交 → 部署」落到看板，中枢页面直连数据库实时读取
图从上往下读，五行分别是触发、作业、写入、发布和界面。每个盒子底下的小圆点，表示有哪几条工作流经过它。可以看到 collect.yml 底下有四个点，发版、每天的定时任务、矩阵名单的改动，最后都汇到这一个采集作业上，台账同步也搭在它后面跑。点一条工作流，图上只亮它走过的那条路。
最早的两条是 7 月 9 日第一版里就有的，每日采集和每周周报。每天早上 7 点（日本时间），GitHub Actions 给矩阵里每个仓库打一次快照，星标、提交、流量都记下来，这一天什么都没发也照记。现在矩阵里有 25 个仓库，快照分 11 类，一共 7,576 行，最近一次是 10 月 13 日早上。这些数据存在仓库的 data 目录里，只有 CI 能往里写，我本地的代码从来不提交它。本地开发服务器读的也是主分支上那一份，不读我手边的。
周报每周一早上 8 点生成，从这一周的快照里读出变化，交给 LLM 写成一段文字，存一份再推到 Discord。推送是 7 月 10 日接上的，那份规划把这一步定为第一版的完成线。从 7 月 6 日那一周算起，到 10 月 12 日已经存了 15 份。
7 月 29 日加了发版刷新。以前一个项目发了版，要等到第二天早上才会出现在看板上。现在 GitHub 一发版就通知 yPulse，它先校验签名，再查这个仓库在不在矩阵名单里，两样都对，就去启动同一个采集作业。通知本身不写任何数据，所以发版和每天的定时任务走的是同一条路，几分钟后看板就更新了。
矩阵名单是一个 yaml 文件，每个项目占一行。加一个项目，改的就是这一行，推上去以后采集作业自动跑一次，新仓库当场有了快照。离开矩阵的仓库，旧的快照会被清掉。各个仓库的发版通知，7 月 29 日起就按这份名单统一设置。8 月 30 日加上了子域名的 DNS，9 月是网站图标和仓库简介，10 月是访问统计。这些对外的设置都由脚本按名单收敛过去，我不去各个平台的后台手改。
六条里只有一条是我亲手启动的，就是速记。7 月 21 日 yPulse 有了自己的数据库，同一天接上了 MCP。想到一件事，可以在 Discord 里打一个斜杠命令，也可以在任何一个 Claude 会话里让它直接记一条，最后都落进同一个收件箱。
台账同步是 7 月 28 日加的，每次采集都顺带把所有仓库的功能台账拉一遍。它出过一次事。有个仓库的台账里出现了词表之外的领域，同步那一步失败了，而 GitHub Actions 默认会跳过失败之后的所有步骤，排在后面、负责更新我 GitHub 个人主页的那一步也就跟着停了。主页就这样四天没有更新，其实每个令牌都好好的。8 月 25 日改了那一步的执行条件，前面失败了它也照样执行。现在台账出了问题，这次运行照样标红，影响只到台账自己。
还有一条线不在这张图上。10 月 9 日起，作品的发布也交给了 yPulse，它从稿件台账生成发布单，在浏览器里把各个平台的表单填好，最后那个发布按钮留给我点，发完再把链接记回台账。它只负责分发，内容由别的仓库生产。这条线在同一个页面的另一个标签里。
回到这张图，我出现的地方只有两处，最右上角那个终端盒子，和最左上角的发版。其余的盒子都等着时钟或者事件，我睡觉的时候，早上 7 点的那次采集照样会跑。