On 2026-08-07, Hecate had exactly one day of snapshot history for every repository it
tracks, so every 7- and 30-day growth window was correctly NULL, and the momentum
ranking meant to blend growth, usage and attention into one score had nothing to blend.
It scored on attention alone, growth_component was NULL across all 2,011 rows, and
signals_measured was 1 everywhere. The plan was to check again once a week of real
history existed and see whether that resolved on its own.
A week later, the data problem is genuinely fixed, though not without a gap. Snapshots landed on thirteen of the fourteen days between 2026-08-07 and 2026-08-20; 2026-08-18 has no snapshot at all, because Docker Desktop failed to start that morning and the day's collection never ran. A missed day like that can't be backfilled after the fact, it describes a moment that's already passed. It didn't corrupt anything downstream, though: every 7-day comparison here lands on an exact snapshot match seven days out, so a repository's growth figure either exists from a real pair of snapshots or doesn't exist at all, it never quietly falls back to a stale day.
2,010 of the roughly 2,079 tracked repositories now have thirteen days of observed
history and a populated stars_gained_7d. Net star growth across the whole catalog for
the week was +611,090 (46,590,814 → 47,201,904), and the absolute leaders look exactly
like leaders should: public-apis up 11,138 stars, skills up 9,794, MoneyPrinterTurbo
up 9,733.
Not every one of those 2,010 rows is a meaningful comparison, though. Only 1,026 repositories have a real star-based growth figure at all: GitHub and GitLab are the only sources that report stars, so npm and PyPI repositories carry a structural zero, not a measured one. Filtered down to the sources where growth can actually mean something, the shape is unremarkable, most of the catalog barely moved.
The raw momentum table didn't get the same care. Query fct_momentum directly, ORDER BY momentum DESC, and the top of the ranking is a tie: systemd, h3.c, a scanned repo
named skitter-creek-bath-salts, cua, and the npm package skills all sit at exactly
100.00, each pegged there by a single signal hitting the score's normalisation cap, not
by three signals agreeing a repository is interesting. Across the whole table, only 32
rows out of roughly 2,068 have signals_measured = 2. Not one has all three.
This dashboard already knows that, and works around it: repositories are ranked by how
many signals corroborate the score first, raw score second, and anything resting on a
single signal gets demoted into its own section below a divider rather than competing
with real multi-signal movement. pi leads at 54.7 on two signals, growth and attention.
The next five, rosenbridge, asm-hall-of-shame, msword, wyzer,
linkedin-feed-blocker, are single-signal attention movers, real Hacker News and Lobsters
posts, ranked below pi even though their raw scores sit close to it. skills and
standardwebhooks score higher than all of them in isolation, 100.0 and 82.3, and rank
last anyway: single-signal usage numbers that would otherwise have swamped the top of the
list exactly the way systemd and cua swamp it in the raw table.
That's a real fix, but it lives in this dashboard's own query, not in fct_momentum
itself. Anything else that reads that table directly, an API response, a different
report, this same panel rebuilt from scratch next month, inherits the tie all over again.
The underlying score still caps at 100 and still can't tell a real three-signal mover
from a repo that happens to have one metric pegged at its ceiling.
A routine sanity check catches a version of the same problem from another angle. Sorting
fct_repository_growth by stars_growth_pct_7d instead of absolute growth is supposed
to surface small repos accelerating fast. It doesn't: the top ten by percentage were ten
packages with zero stars, click, PyYAML, numpy, eslint, rimraf among them, all
showing 0 / 0 growth with nothing to divide by. It's the same root cause the
1,026-repository filter above already worked around for the distribution chart, just
unfixed in this particular column.
Discovery is still doing its job: 49 of the 2,079 tracked repositories arrived because
Hecate found them itself. And the forecast job, which couldn't even create its CronJob as
of this morning's run, cronjobs.batch "hecate-forecast" not found, got redeployed later
today and produced its first usable predictions; every batch before this one came back
100% insufficient_history. There's nothing to compare against yet, the target date is
2026-08-28, but it's running.
One honest caveat on all of this: today's dbt job didn't complete, 0 of 1, so the marts I queried directly reflect the last successful build, not necessarily this morning's fresh snapshot.
The lesson isn't really about Hecate specifically. A fix that lives in a dashboard's query is a real fix for anyone looking at that dashboard, and it is not a fix for the data underneath it. Both were true here at once: the growth window filled right on schedule, a smarter ranking already exists and already gets it right for this one view, and the raw table one layer down still ties five unrelated repositories at a normalisation cap, waiting for the next thing that queries it directly to rediscover the same problem from scratch.