Changelog

[v1.4.0] (2026-07-18) - Enchant catalog: item-applied enchants (arcanums, ZG, kits)

New Features

• New enchant catalog covering the permanent gear enchants no profession crafts — Dire Maul arcanums (Lesser Arcanum of Voracity/Rumination/…, Arcanum of Rapidity/Focus/Protection), the Zul'Gurub / Zandalar head, shoulder and leg enchants (Presence of Might, Syncretist's Sigil, Death's Embrace, Falcon's Call, Hoodoo Hex, Animist's Caress, …), armor kits, shield spikes, Wolfshead Trophy, Mithril Spurs. These are applied by a consumable item, so they never appear in any profession's recipe list — but a gear planner needs them as slot options. Three new methods expose a unified, slot-indexed view over both the craftable enchants (from recipe data) and these item-applied ones:
  • DB:EnchantsForSlot(slot) — every enchant applicable to a slot ("HEAD", "SHOULDER", "WRIST", "WEAPON2H", …), craftable and item-applied together.
  • DB:GetEnchant(enchantId) — a normalized catalog entry by SpellItemEnchantment id: { id, name, effect, slots (array), stats?, source ("craft"/"item"), itemId?, profId?, recipeId? }.
  • DB:IterateEnchants() — iterate the whole catalog.
• Authoritative, curated sourcing. The item-applied set is extracted from DBC — every ENCHANT_ITEM effect whose apply spell is not in a profession skill line, targets an armor/shield slot (SpellEquippedItems), and is granted by a real obtainable item — so [PH] placeholders and QA/dev test enchants drop out. Slot + structured stats reuse the v1.3.0 enchant-enrichment extraction.
• Structured stats now capture crit/hit and the tank/avoidance stats. The stat extraction gained the melee/spell crit and hit auras plus defense, dodge, block chance, block value, and ranged haste, emitted under the exact stat-weight keys a scorer reads — CRIT_PCT / HIT_PCT / SPELL_CRIT_PCT / SPELL_HIT_PCT / DEFENSE / DODGE_PCT / BLOCK_PCT / BLOCK_VALUE / RANGED_HASTE_PCT. So an enchant's every stat contributes to a stat-weighted (EP) total the same way an item's does. Covers the ZG/AQ head/shoulder/leg enchants (Presence of Might → Defense +7 / Stamina +10 / Block Value +15, etc.) and the craftable enchant recipes alike. Coverage: 80 (Vanilla), 128 (TBC), 140 (Wrath), 169 (Cata), 176 (Mists), in every locale. Delivered inside the existing Enchanting data files (no new load order).
• Kept out of the recipe space on purpose. Item-applied enchants live in a separate catalog keyed by enchant id, so GetProfessions() / GetRecipes() and every recipe-oriented consumer are completely unaffected. LibStub MINOR → 7.

Bug Fixes

• Enchant stat amounts were off by one for some enchants. The structured-stat extraction (v1.3.0) computed an aura's value as EffectBasePoints + 1, which is only right when the effect stores its value with a 1-sided die. Enchants that store the value directly (die 0) came out one too high — e.g. a "Stamina +20 / Defense +7 / Block Chance +2%" enchant shipped 21 / 8 / 3. Now computed as EffectBasePoints + EffectDieSides, which is correct for both encodings; the common die-1 enchants are unchanged.
• Stale localized name files re-synced. The v1.2.1/v1.2.2 _core corrections (Basic Campfire dropped from Cooking, Crystal Infused Bandage from Vanilla First Aid) were emitted with --core-only, so the per-locale name files still listed those spells. This full regeneration removes them (they were runtime-inert — a name with no _core entry is skipped — but the files are now correct).

[v1.3.0] (2026-07-12) - Enchant enrichment: id, target slot & structured stats

New Features

• Enchant recipes now ship a target slot, a structured stat table, and their enchant id — all extracted authoritatively from DBC. Every recipe whose craft applies a permanent enchant (all Enchanting recipes, plus Engineering scopes / belt tinkers) now carries three new _core fields, and the library exposes them via DB:GetEnchantSlot, DB:GetStats, and DB:GetEnchantId:

  • enchantSlot — the target slot category ("HANDS", "WRIST", "CHEST", "BACK", "SHIELD", "FEET", "WEAPON1H", "WEAPON2H", "WAIST", "RANGED", …). Sourced from the recipe spell's SpellEquippedItems equipped-item restriction, so it's language-independent — no recipe-name grepping. (Weapon 1H/2H, which the mask doesn't encode, is the only piece read off the stable enchant name.)
  • stats — a structured { [key] = amount } table keyed by the game's own GetItemStats keys (ITEM_MOD_AGILITY_SHORT, RESISTANCE0_NAME = armor, RESISTANCE2_NAME = fire resistance, …), so a consumer sums enchant stats straight into item-stat totals instead of re-parsing the effect string. Extracted from the enchant's DBC effects — chasing the hidden apply-spell's SpellEffect auras (MOD_STAT, MOD_RESISTANCE school bitmask, spell power, healing, mp5, …) for the common case, direct SpellItemEnchantment effects for armor/resistance. Absent for procs / on-use effects (Crusader, Fiery Weapon) that carry no static stat.
  • enchantId — the SpellItemEnchantment id, i.e. the enchant number in an item link's enchant slot. Lets a consumer map an enchant already applied to a worn item back to the recipe that produces it — no tooltip scanning.

  Purely additive: the fields live in _core only (they're locale-independent), no existing field changed, and older consumers ignore them. New DBC pull: SpellEquippedItems, wired into the existing pipeline. Coverage on Vanilla: 140 slots, 121 stat tables, 153 enchant ids. LibStub MINOR → 6.

[v1.2.2] (2026-07-04) - Complete the spec map for TBC/Wrath (crafted-item gates)

Bug Fixes

• requiredSpec now covers TBC/Wrath crafted-item-gated recipes. v1.2.1 derived the spec gate solely from the recipe scroll (ItemSparse.RequiredAbility on the Plans:/Pattern: item), which is how Vanilla encodes it. But TBC and Wrath moved the gate onto the crafted item itself (e.g. Lionheart Blade → item 28428 → 17039 Master Swordsmith) and leave the scroll ungated — so every post-Vanilla spec recipe shipped without a requiredSpec, and consumers attributing a crafter to a spec fell back to "Unspecialized" for the entire TBC/Wrath weapon and armor lines. The generator now also matches the produced item against the specialization map. Newly tagged: 65 TBC (Blacksmithing 37, Leatherworking 18, Engineering 10), 72 Wrath (Blacksmithing 42, Leatherworking 18, Engineering 12), and 2 Vanilla (Gnomish/Goblin Engineering). Purely additive — no existing tag or other _core field changed. LibStub MINOR → 5. API unchanged.
• Mooncloth Tailoring recipes now tagged. The specialization map had 26802 ("Detect Amore", a holiday spell) where Mooncloth Tailoring's real spell id 26798 should have been, so every Mooncloth-gated recipe shipped with no requiredSpec. Corrected — Mooncloth now tags 3 recipes per build (TBC/Wrath), matching Spellfire and Shadoweave. Spellfire (26797) and Shadoweave (26801) were already correct.

[v1.2.1] (2026-07-02) - Specialization requirements + data corrections

New Features

• Recipes now carry their required specialization (requiredSpec). Spec-gated recipes — Leatherworking (Dragonscale / Elemental / Tribal), Blacksmithing (Armorsmith / Weaponsmith → Swordsmith / Hammersmith / Axesmith), Tailoring (Mooncloth / Shadoweave / Spellfire), and Engineering (Gnomish / Goblin) — now ship a requiredSpec field holding the specialization spell required to learn them, sourced from ItemSparse.RequiredAbility. It's the same spell id IsSpellKnown returns for that specialization, so consumers can compare it directly (e.g. hide recipes a character's spec can never learn, or attribute a crafter to a spec). Covers Vanilla / TBC / Wrath — specializations were removed in Cata. The field rides every recipe entry via LoadCore; LibStub MINOR → 4 signals its availability. The public query API is otherwise unchanged.

Bug Fixes

• Basic Campfire removed from Cooking. Recipe 818 is the learned campfire ability (it produces no item), not a craftable, so it never belonged in the recipe set. Dropped from the Cooking data.
• Crystal Infused Bandage removed from Vanilla First Aid. Recipe 30021 is a TBC First Aid bandage (Netherweave-based, skill 300→360) that the Anniversary Classic client ships in its data even though it isn't learnable in Vanilla. It's excluded from the Vanilla set only — TBC and later still ship it.

Tooling

• Dev-sync watcher hardened (wow-version-replication.ps1) — added a per-repo single-instance mutex so a second launch (e.g. a VS Code reload re-firing the folder-open task) exits cleanly instead of racing the running watcher; wrapped Copy-Item, the initial sync, and the poll loop in try/catch so a locked target (WoW open, AV scan, editor write-replace) or a file that vanishes mid-scan now logs a RETRY/WARN and self-heals on the next poll instead of silently killing the watcher; the mutex is released on exit. Mirrors the hardening already in the sibling addons' copies of this script.
• .pkgmeta — normalized the docs ignore entry (was docs/).
• .vscode/tasks.json — now tracked in the repo so the folder-open dev-sync task follows the project to a new machine.

[v1.2.0] (2026-05-30) - Core/names data split

Improvements

• De-duplicated locale-independent data (core + names split). v1.1.0 shipped a fully self-contained file per language, so the structural fields (difficulty / reagents / requiredSkill / teaches / craftedItemId / itemId / phase) were byte-identical across all 12 locale folders — and a client parsed all 12 copies of the full table on login (the GetLocale() guard skips execution, not parsing). Now that data lives once per game in Data/<game>/_core/<Prof>.lua (loaded via lib:LoadCore, guarded by IsGameVersion only), and each Data/<game>/<locale>/<Prof>.lua carries only the localized name + effect (via lib:LoadNames). The bulky structural table is parsed/loaded once instead of 12× — cutting both the download size and the once-per-login parse cost. Mirrors how LibItemDB-1.0 is built.

API

• New lib:LoadCore(profId, core) and lib:LoadNames(profId, names) (LibStub MINOR → 3). Both merge into the same self.recipes view, so the public query API (GetRecipe, GetReagents, GetDifficulty, GetEffect, Search, Iterate, …) returns the same stitched entry shape as before — no consumer change. LoadRecipes is retained as a back-compat shim that splits a self-contained table into a LoadCore + LoadNames pair.
• Per-flavour TOCs now list the _core files first, then all locale name files (each still self-guarded on GetLocale() + IsGameVersion).

[v1.1.0] (2026-05-30) - Full localization

New Features

• All official WoW locales — recipe names and enchant effect text now ship in deDE, esES, esMX, frFR, itIT, koKR, ptBR, ruRU, zhCN, and zhTW (plus enGB mirroring enUS), alongside enUS. 12 locales total, ~202,140 recipe entries across the five game versions, 672 data files. Each data file guards on GetLocale() so a client loads only its own language, and each per-flavour .toc lists every locale's files.

Improvements

• Locale-stable recipe sets — only name and effect are translated; the recipe set, difficulty tiers, reagents, required skill, and item IDs are byte-identical across every locale. Strings come from localized SpellName + SpellItemEnchantment pulls, re-resolved with the same enchant placeholder handling (cross-spell refs, etc.), with English fallback for any string a locale is missing. The English-only structural heuristics (scroll-prefix detection, obsolete-item filtering) never run on translated data, so the recipe set can't drift between languages.
• LibStub MINOR bumped to 2 — signals the expanded multi-locale data set to consumers. The public API is unchanged.
• Clean lint — added a scoped ---@diagnostic disable: undefined-global to LibProfessionDB-1.0.lua; the shared TOG multi-root workspace disables the Lua 5.1 builtin library, which otherwise false-flags pairs/table/etc.

[v1.0.0] (2026-05-30) - Initial release

New Features

• LibProfessionDB-1.0 — Standalone offline profession/recipe database exposed as a LibStub library. Resolves a crafting recipe to its name, reagents, skill-up difficulty tiers (orange/yellow/green/grey), required skill, produced item, and enriched effect text — with no trade-skill window open and no scan. API: IsReady, Count, GetMeta, GetProfessions, HasProfession, ProfessionCount, GetRecipes, GetRecipe, HasRecipe, GetName, GetReagents, GetEffect, GetDifficulty, GetRequiredSkill, GetItemID, GetCraftedItemID, Search, Iterate. Data is loaded via LoadRecipes(profId, recipes) from shipped, pre-built data files.
• Point-in-time data per game version — recipe difficulty, required skill, reagents, names, and effect text are NOT merged across expansions; each flavour ships exactly its own wago build's recipes. Vanilla/enUS through Mists/enUS captured (16,845 recipes across the five flavours).
• Enriched, searchable effect text — enchant recipes carry their effect name (+5 Weapon Damage, +1 All Stats, …) resolved from SpellItemEnchantment, including cross-spell placeholder resolution. Search matches both recipe name and effect text. Crafted gear ships no synthetic stat line (the client's real item tooltip is authoritative).
• Ships for every flavour except Retail — per-flavour TOCs for Vanilla/Era (11508), TBC (20505), Wrath (30405), Cataclysm (40402), and Mists (50503). Each TOC lists only its own game's profession data files.
• Guild version-check — ProfessionDB.lua registers a { GetName = "LibProfessionDB", Version } host with VersionCheck-1.0 at PLAYER_LOGIN. Hard dependencies on Ace3 and VersionCheck-1.0 are declared in every .toc and in .pkgmeta (required-dependencies).