One new open-source project per post: what it does, why it surfaced now, how it works, where it is weak. Static Astro site, published from a queue.
npm install && npm run devnpm run discover— queries GitHub, scores candidates, writesdata/queue.json. It never writes tosrc/content; nothing publishes itself.- Pick a brief from the queue and write
src/content/news/<repo-name>.md. The front matter schema lives in src/content.config.ts — repository figures are a snapshot taken from the brief, never re-fetched at build time. - Set
publishDateto the day it should appear. A future date queues the post: it gets no page, no listing, no feed entry and no search row until a build runs on or after that date. Two posts a day is the cadence. - Push.
.github/workflows/deploy.ymlbuilds and deploys on every push tomain, and again each morning on a cron — the morning run is what moves the queue.
Reject a repository permanently by adding owner/name to data/rejected.json.
data/seen.json is the star baseline the momentum score is computed against — commit it,
or every run looks like a first run.
| Path | What |
|---|---|
src/content/news/ |
the posts |
src/data/site.ts |
name, URL, the ten categories and their colours |
src/lib/posts.ts |
publishedNews() — the one place the queue is enforced |
src/components/RepoFacts.astro |
the facts strip under each headline |
scripts/discover.mjs |
discovery; --selftest runs the filter and score checks offline |
plan.md |
why the thing is built this way |
GitHub Pages, from the repository HighlightsX/highlightsx.github.io, served at the domain
root — which is why every link in the source is an absolute path with no base prefix.
npm run build → dist → actions/deploy-pages. Set Pages source to GitHub Actions
in the repository settings once; no secrets, no build hook.
Moving to a custom domain later: add public/CNAME containing the domain, set it in Pages
settings, update site in astro.config.mjs and url in
src/data/site.ts. No other code changes — the site is already
root-relative.