Lootr Tools refuses a drop rate that arrives without a provenance status

Zod's `parse` either returns the object or throws, so the helper hands the whole job over: `defineClass` is `return gameClassSchema.parse(input)` ^[1]. The check runs when the data module is first imported ^[1]. Whatever imports it first owns the failure. Editors keep normal TypeScript completion, and the schema enforces the rules TypeScript alone cannot protect at runtime ^[2]. With the data sitting directly in React components, the developer wrote, nobody noticed a wrong unlock requirement or an expired code until a reader pointed it out ^[19].

The range rule is narrower than it looks. Drop rates must be decimals from 0 to 1 ^[3]. Five percent entered as 5 fails, because 5 is outside the range ^[2]. Half a percent entered as 0.5 passes, and the page quotes it as fifty percent ^[2].

An object can satisfy its own schema and still point at an aspect that does not exist ^[9]. So the data index calls `assertValidDataset` over sources, classes, aspects, items, builds and codes before the app uses the dataset ^[10]. Seven checks run there: duplicate entity ids and slugs, builds referencing missing classes, classes recommending missing aspects, aspects recommending missing classes, entities citing missing sources, item rates outside 0 to 1, and item rates without a rate status ^[11]. Two of the seven restate rules the per-object parse already enforces. The other five only come into view once the whole dataset is in hand: the duplicate test and four kinds of dangling reference ^[3]. The post does not say why the rate rules are checked in both places. A build pointing at a nonexistent class, it says, "never becomes a production page" ^[12].

Codes are the case where the model leaves the conflict unresolved. Two dated sources can disagree about the same code on the same day, so the schema allows a status of `unknown` instead of forcing an active or expired choice ^[16]. On stored dates, the post says: "The content may still be wrong, but it no longer pretends to be fresh." ^[15]

The decision pages are held to the same rule as the data. The Build Finder scores candidate builds on class, goal, source confidence, current-update compatibility and aspect match. With no exact match it falls back to another goal at lower confidence, and with no build at all it derives a conservative plan from class basics ^[17]. The probability helpers are pure functions outside React. That makes edge cases easier to test, the developer wrote: zero percent drops, hundred percent drops, tiny rates across huge run counts, and unreachable confidence targets ^[18]. What the current patch actually does is a separate problem. The developer wrote that the approach constrains the damage when research is incomplete, and that the production site still needs regular rechecks ^[21].