The 13 checks

Frozen v1 labels and critical flags — the contract between live DE data and the community parsers.

How a check works

fetch → parse → validate → verdict

One HTTP request pulls the profile; @wfcd/profile-parser parses it; the 13 checks run through a safe wrapper (an exception becomes a failed check); the verdict is derived from critical flags only. Details in the guide.

Each run is persisted in data/app.sqlite — summary, individual checks, request metadata.

The checks

6 critical / 7 advisory
#Check (exact label)Critical
1profile.displayName is a non-empty stringyes
2profile.accountId matches the requested idno
3profile.accountId is a 24-char hex ObjectIdyes
4profile.masteryRank is an integer >= 0yes
5profile.created is a valid Dateyes
6profile.loadout is built (suits/xpInfo arrays)yes
7profile.missions is an arrayno
8profile.challengeProgress is an array (Nightwave)no
9profile.intrinsics is an objectno
10stats.timePlayedSec is a finite numberyes
11stats.missionsCompleted is a numberno
12stats.weapons and stats.enemies are arraysno
13xpCacheExpiryDate / ceremonyResetDate are parsed Datesno

The verdict

derived from critical flags only
broken warnings ok
  • broken — at least one critical check failed: the parser pipeline is unusable for its purpose.
  • warnings — only non-critical checks failed: the profile still parses, but a field drifted.
  • ok — all 13 checks passed.

Keeping the labels honest

frozen by tests
  • The exact labels and critical flags above are asserted by the test suite — they cannot drift silently.
  • An offline parity test replays a real captured DE response (packages/core/test/fixtures/profile.raw.json) through the same pipeline on every npm test — no network.
  • Refresh the fixture with npm run check:live (exactly one request), or run the whole pipeline offline with npm run check:offline.