It works whether I open it or not
On 6 July I wrote the first plan for yPulse, which was still called Pulse then. Its first sentence says it is a data pipeline. A few principles follow. Pushing comes before a dashboard, because a dashboard you have to go and look at ends up unvisited. Raw data is kept in full from day one: the analysis will be rewritten again and again, and as long as the raw data is there it can be recomputed. And the investment is capped: the first version gets two or three days, and every later addition has to justify itself first.
The first version was done on 10 July, four days in. Pieces kept being added after that, and yPulse now has 944 commits. The plan's first sentence has held throughout, though: most of the time nobody opens it, and it runs anyway. The diagram below is one of its own pages, drawing the six workflows behind it.
How yPulse runs itself
Every pipeline behind the board: what starts it, what it writes, and where that lands.
Observation data reaches the board through commit → deploy; hub pages read the database live
Read it from top to bottom; the five rows are trigger, job, write, ship and surface. The small dots at the bottom of each box show which workflows pass through it. collect.yml carries four: a release, the daily cron and a change to the matrix list all converge on that one collect job, and the ledger sync rides along behind it. Pick a workflow and only the path it walks stays lit.
The two oldest were in the first version on 9 July: the daily collect and the weekly digest. Every morning at 7 (Japan time), GitHub Actions takes a snapshot of every repository in the matrix, recording stars, commits and traffic even on a day when nothing ships. The matrix has 25 repositories now, and the snapshots come in 11 series with 7,576 rows between them; the latest was taken on the morning of 13 October. The data lives in the repository's data folder, and only CI writes to it. My local checkout never commits it, and the local dev server reads the copy on the main branch, not the one in front of me.
The digest is written every Monday at 8 in the morning. It reads the week's changes out of the snapshots, has an LLM write them up, archives the result and pushes it to Discord. The push was wired up on 10 July; the plan had set that step as the finish line for the first version. Counting from the week of 6 July, fifteen digests had been archived by 12 October.
Release refresh came on 29 July. Before that, a project's release didn't show up on the board until the next morning. Now GitHub notifies yPulse the moment something ships. yPulse checks the signature, then checks that the repository is on the matrix list, and if both hold it starts the same collect job. The notification itself writes no data, so a release and the daily cron take the same path, and the board updates a few minutes later.
The matrix list is a yaml file with one line per project. Adding a project means adding that line; once it's pushed, the collect job runs and the new repository has a snapshot on the spot. A repository that leaves the matrix has its old snapshots removed. Release notifications for every repository have been set from this list since 29 July. DNS for the subdomains followed on 30 August, favicons and repository descriptions in September, and analytics in October. Scripts converge all of these outward settings from the list; I don't edit them by hand in each platform's dashboard.
Only one of the six workflows is started by me: capture. On 21 July yPulse got its own database, and MCP was connected the same day. When something occurs to me, I can type a slash command in Discord or tell any Claude session to log it, and either way it lands in the same inbox.
Ledger sync was added on 28 July; every collect run also pulls the feature ledgers of every repository. It broke once. One repository's ledger used an area that wasn't in the agreed vocabulary, so the sync step failed. GitHub Actions skips every step after a failed one by default, which took down the later step that updates my GitHub profile page. The profile went four days without an update while every token involved was fine. On 25 August I changed that step's condition so it runs even when an earlier step fails. A bad ledger still turns the run red, but the damage stays with the ledger.
One line isn't on this diagram. Since 9 October publishing works has been handed to yPulse too. It builds a job sheet from the works ledger, fills in each platform's form in the browser, leaves the final publish button for me to click, and records the links in the ledger afterwards. It only distributes; the content is made in other repositories. That line has its own tab on the same page.
Back to the diagram: I appear in two places, the terminals box at the top right and the release at the top left. Every other box waits for a clock or an event, and while I'm asleep the 7 a.m. collect runs all the same.