The weekly job publishes whatever the crawl produced, with nothing checking it first

[MLuc24]

.github/workflows/refresh.yml runs npm run data, then:

git add data
if git diff --cached --quiet; then … exit 0; fi
git commit -m "chore(data): weekly refresh from Garena and Fandom"
git push

Nothing between the crawl and the push looks at what came back. Whatever the crawl produced becomes the published dataset, and jsDelivr serves it to everyone reading @main within minutes.

What the existing guards do and do not cover

The crawlers do stop on a collapse:

• crawl-garena-heroes.mjs throws below MIN_EXPECTED_HEROES = 100
• crawl-garena-systems.mjs throws when a count drifts past TOLERANCE = 0.2 from its expected value

Both are gross-failure checks on counts of records. Neither notices a partial degradation, and merge-heroes.mjs prints per-field coverage at the end of a run but nothing acts on it — its only process.exit(1) is the catch handler.

So these all pass today and would be published:

• 129 heroes, every one of them with an empty lore, because a wiki section heading was renamed
• sources.fandomVi dropping from 59 back to 49, because a batch request silently returned fewer pages
• every stats array empty, because an infobox template got renamed — this is exactly the shape of the Tulen bug in Published data carries four wrong records because the crawlers are three weeks behind #1, but affecting all of them instead of one

The 24 August refresh is the concrete case: it published Tulen with no stats and no price, Kaine with no skill effects, Dolia with wiki markup in its biography. Green run, no signal.

Why this repo specifically

A dataset that updates itself weekly is only worth what its worst automatic commit is. Nineteen people are pinned to @main through a CDN; the failure mode here is not a broken build somebody notices, it is quietly wrong values that people build on.

Suggested fix

A scripts/check-data.mjs that runs after the merge and before the commit, comparing the freshly written data/ against the copy already in git:

• record counts per file
• coverage per field that matters (stats, lore, build, skills[].effects, sources.fandomVi, prices)
• exit non-zero when any of them falls by more than a small margin

A drop is not always wrong — Garena does remove heroes and skins — so the useful behaviour is to fail the job and let a human look, not to auto-correct. The workflow already knows how to stop: put the check between npm run data and git add.

Two smaller things in the same file while it is open: the actions are pinned at actions/checkout@v4 and actions/setup-node@v4, which GitHub now forces onto Node 24 with a deprecation annotation on every run, and a failed weekly job currently notifies nobody.