What broke
The front page said "across 4 apps" because only four app pages had a number
The front page added up its commit total from a Commits fact on each app page. Only four of the ten published app pages had that fact, so the total covered four apps. The count now comes straight from git, and the page fact is only a fallback.
The short version
What went wrongThe front page commit total was summed from an optional Commits fact on app pages. Only four of ten pages had it, so the total covered four apps while looking correct.
How we found itThe green line said "across 4 apps" when ten app pages were published. Nothing crashed, and the arithmetic was right for those four apps.
The rule nowCount totals from the source, here git, with method and date stored beside them. Hand-written page facts are only a fallback, and items with no number must show as missing, not drop out of the sum.
This post documents something Claude got wrong. The claim rests on a commit or a file, not on memory. All of Claude's mistakes
The top of the vibeapp.win front page shows a short diff. Each red line is a piece of hype (“An app is something you build in an afternoon.”). Each green line is what our own record says instead. One green line gives the total number of commits behind the apps on the site.
By late evening on 3 October 2026, ten app pages were published. The green line said the commits were spread “across 4 apps”.
What the line was built from
The code behind the diff counts every number on the green side at build time, from published content. Claude wrote that code. For commits, it read a “Commits” fact on each app page. That fact cites git log, so the source itself was fine.
The problem was that the fact was optional. Only four of the ten app pages had it. The code mapped each app to its Commits fact and then dropped every app that had no number. It added up what was left and reported how many apps went into the total. That number was four.
The arithmetic was right. It was just right about four apps out of ten.
This behaviour came from a rule we wanted. The ledger code says a line “whose number would be zero or unknown is left out rather than padded”. That is a good rule for a whole line. Applied app by app inside one sum, it did something else. An app with no number vanished from the total. The line didn’t say the total was partial. It only said “4”, and you had to know there were ten apps to notice.
Why the page fact was the wrong source
A fact on an app page is written once, when the page is written. Whether it exists depends on whoever wrote that page. Its value is frozen at that moment. So a total built from those facts depends on how complete the pages are, not on how many commits there are. The front page was reporting something about our writing habits and calling it a commit count.
The site is built on Cloudflare Pages, and that build cannot read the private app repositories. So the build can’t just run git itself. That means the count has to be taken somewhere else and stored.
The fix
On 4 October 2026, Claude added a script that counts the commits outside the Pages build and writes the result to a file in the repository. The front page cites that file.
The method is written into the file next to the numbers:
git rev-list –count –no-merges HEAD in each app’s main repository; a repository shared by two app pages is counted once
Three choices in that method:
- Main repository only. An app page can list more than one repository. The script counts the first one, its main repo.
- No merges. Merge commits are not counted.
- Shared repositories once. If two app pages share a main repository, its commits go to the first page that has it and are not counted a second time.
The script only reads repositories that are approved as sources for this site. Only counts and dates come out of it, keyed by the app’s slug on the site. It also records the date of each repository’s first commit. The front page now uses that date for “since when”, instead of a start date written on the app page.
The page fact wasn’t removed. It is now a fallback. If an app is published after the last count, the front page uses that app’s Commits fact until the script runs again.
What the count says now
The measurement dated 2026-10-04 covers all ten published apps. Added up, it is 1,388 commits, with no merges and each repository counted once. The stock app is the largest at 683, about half of the total. The oldest first commit is in the stock app, on 2026-04-23. The newest repository is this site’s own, which had 142 commits by the day of the count and a first commit dated 2026-10-03.
That first date needs a caveat we can’t resolve from the material: 142 commits in about two days is a lot, and we haven’t checked how the repository’s history begins.
What this fix does not do
The count is a snapshot. It is accurate on the date in the file. Any later commits are left out until someone runs the script again. The date is stored with the count, but the number will still fall behind.
The fallback has the same weakness the old code had. An app published after the count, with no Commits fact on its page, still drops out of the total. The difference is that this now affects one new app between counts, not six of ten apps permanently.
Counting only the main repository also undercounts any app whose work is split across several repositories.
A second line changed in the same commit
The same commit changed another green line. It used to say that anything in doubt waits for Henning. From 4 October the engine that writes these posts runs on autopilot. It assesses and fixes the doubts it finds itself, and only what it cannot clear goes to Henning’s inbox. So the line now says “what the engine cannot clear waits for Henning”.
The rule
A total on the front page is counted from the source that produced it (here, git), with its method and date stored next to it. A fact written by hand on a page is only a fallback. Where an item has no number, it must show up as missing, not quietly drop out of the sum.