All work

Repository intelligence platform

Hecate

Star counts are a bad proxy for whether a project is alive. Hecate collects repository and package data from four sources, collects discussion from two more, and keeps a daily snapshot so growth can be measured rather than guessed. A forecasting stage predicts where a repository is headed next, and a question-answering service on top answers plain-English questions about the whole warehouse.

v2.0.0, running unattended on a daily schedule, RAG-backed Q&A verified live

dbt models, 54 tests, 63 nodes total
9
panels on the Grafana dashboard
21
mean faithfulness on the RAG evaluation harness
0.92

The problem

A repository with 60,000 stars and no commits in three years is a different thing from one with 8,000 stars and weekly releases, but most tooling treats them as comparable. Download counts say more about real use than either, and discussion says something different again, usually earlier.

The harder problem is discovery. If you seed a tracker from cumulative popularity, which is what GitHub's most-starred and npm's most-installed give you, then anything trending before it is famous is excluded by the seeding itself. The tracker can only ever confirm what you already knew.

How it works

Four extractors pull projects from GitHub, npm, PyPI and GitLab. Two more pull conversation from Hacker News and Lobsters. Each one is rate-limit aware and retries on failure.

A transformer normalises everything to a single schema, then loads into PostgreSQL idempotently. A run that dies halfway through can just be run again, which matters more than it sounds when the whole thing is unattended.

Posts about projects Hecate does not yet track are the interesting case. They are not discarded. They are kept, ranked, and the projects behind them get fetched and added, so discussion decides what gets tracked rather than the other way round.

Every tracked project is snapshotted daily. That table is the only history in the system, and it is the only reason growth can be measured at all, because everything else describes the present and upserts in place.

dbt turns the raw tables into staging views, then facts, dimensions, growth and momentum models: nine models backed by fifty-four tests. Grafana reads the result across 21 panels, Prometheus watches the jobs, and alerts fire when a run does not land.

A forecasting stage predicts each repository's star count a week out, gated by a confidence check so a forecast that has not cleared the bar is written as NULL rather than shown as if it were real, with its own backtest tool that checks predictions against what actually happened.

A question-answering service sits on top, provider-selectable across Gemini, Anthropic and OpenAI. Answers are built from SQL against the analytics models rather than a similarity search, since the questions people ask are aggregates and the whole corpus is small enough that picking the right rows beats finding similar ones. Every citation is checked against what the model was actually shown before it reaches the caller, and an evaluation harness scores whether the answer is grounded at all.

SOURCESPopularity-seededGitHub · npm · PyPI · GitLabDiscussionHacker News · Lobstersextractorslink resolutionINTAKEraw_repositoriesnormalised to one schema · upserted idempotentlysocial_mentionsevery post resolved back to a projectdiscovers untracked projectsdiscussion volumedaily snapshotSTORAGErepository_snapshotsdaily, the only history in the systemhistoryTRANSFORMdbtstaging → facts, dimensions, growth, momentumreadsSERVEGrafana · Prometheusdashboards and metrics, with alerts when a run does not land
A project mentioned in discussion that Hecate does not yet track gets fetched and added automatically, so discussion decides what gets tracked, not just popularity.

Where it landed

The platform reached v2.0.0. All six sources collect, dbt rebuilds the models daily, and the whole thing runs unattended with alerting and nightly backups. The Grafana dashboard now exposes 21 panels on anonymous read, up from the 15 it shipped with, including a forecast panel for the newest stage.

The question-answering service is deployed with all three providers verified end to end, env vars, auth, request routing, and the Anthropic path has cleared a full evaluation run against real production data: 0.92 mean faithfulness and zero hallucinations across a fixed question set, graded by a second model call rather than self-reported.

What it taught me

A green panel can still be measuring the wrong thing

Three dashboard panels were rendering correctly, refreshing on time, and reporting a number that did not mean what the panel title claimed. Nothing in the monitoring could catch that, because the failure was in the definition rather than the pipeline. I now write down what a metric is supposed to mean before building the panel, and check the query against that sentence.

Idempotency is a scheduling feature, not a database one

Making every load idempotent looked like extra work during the build. It is the single reason the daily schedule is safe to leave alone, because recovery from a partial run is just running it again rather than working out what landed.

Scheduled jobs fail quietly in ways live services do not

A job that never starts produces no error, no log line, and no alert unless you are specifically watching for absence. Catching a container image mismatch took far longer than it should have because the run simply was not there to fail.

Built with

  • Python
  • PostgreSQL
  • dbt
  • Kubernetes
  • Docker
  • Prometheus
  • Grafana
  • Redis
  • FastAPI
  • LangChain