Library: import subclasses (and other content) from 5etools to fill Open5e SRD gaps

Start with the pnpm db:import entry point and seedLibrary.ts, then inspect the character_classes and character_class_features tables and the 5etools data/class/.json files. Before implementation, establish the included content, source namespace, licensing and attribution rules; done means the reviewed multi-source scope and provenance requirements are explicit rather than bundled together.

Summary

Open5e's CharacterClass data (data/v2/wizards-of-the-coast/srd-2024) has exactly one subclass per class — 12 base classes + 12 subclasses, 24 rows total. Verified this is the actual content of the SRD, not an Open5e gap: the srd-2014 fixtures give the identical 12+12 shape under different slugs. WotC's SRD (both the 2014 OGL and 2024 CC-BY-4.0 releases) was deliberately published minimal; the ~50+ other official subclasses (Battle Master, Eldritch Knight, Circle of the Moon, Assassin, Psi Warrior, …) were never released as open content, so no git ref or endpoint on Open5e will ever surface them.

For the library to be reasonably complete, pnpm db:import needs to become multi-source: keep Open5e as the SRD source of record, and pull the non-SRD gaps from elsewhere, rather than treating "not in the SRD" as permanently out of scope.

What's available

Investigated 5etools-mirror-3/5etools-src (the canonical 5etools data mirror) as a candidate second source:

• data/class/class-<name>.json per class: a subclass[] array (every official subclass, tagged by source book — PHB, XGE, TCE, SCAG, EGW, the 2024 XPHB, …) and a subclassFeature[] array with the feature text.
• Feature text is prose, not structured mechanics — entries is 5etools' own recursive markup ({@dice 1d8}, {@condition prone}, nested lists/tables, cross-references), not numeric fields like Open5e's creature_action_attacks.to_hit/damage_dice. Importing this gets us display/reference text for a statblock or character sheet; it does not give the simulator engine executable combat logic — maneuvers, invocations, and fighting styles would still need hand-coded rules per feature, the same way monster Multiattack does today.
• Also present, beyond subclasses, since PC-building data already stopped being fully out of scope once the simulator needed class templates: optionalfeatures.json (Fighting Styles, Metamagic, Eldritch Invocations, Battle Master maneuvers — arguably more load-bearing for the simulator than the subclass fluff text, since these are the actual choices a PC makes), feats.json, races.json/species, items.json/magicvariants.json, and a bestiary/ far larger than the 331 SRD creatures.
• Open5e's own fixture repo also has other OGL-licensed publisher directories under data/v2/ (kobold-press, green-ronin, en-publishing, somanyrobots) worth a look if we want more content without leaving Open5e's rights posture at all — though these are third-party content, not additional official WotC subclasses.

The catch: licensing is not uniform across sources

5etools-src's repo-level MIT license covers the site's code, not data/ — that folder is a transcription of copyrighted WotC rulebook text with no rights grant from WotC, unlike Open5e's SRD mirror (WotC's own CC-BY-4.0/OGL release) or the GPL-3.0 spell-effect clips already imported. This is a materially different rights posture from everything currently in the pipeline, so it can't be folded in silently:

• Needs its own slug namespace (e.g. a 5e_ prefix) so re-imports never collide with or overwrite SRD-sourced rows, and so import_runs provenance stays answerable per source, not just per git ref.
• Needs its own attribution treatment alongside the existing SRD/CC-BY-4.0 and spell-effects/GPL-3.0 credits.
• Should be treated as a deliberate, reviewed inclusion rather than an automatic on-every-boot fetch the way seedLibrary.ts fetches Open5e today — worth a explicit call on how "live" this source should be before building it.

Suggested follow-up

• Extend pnpm db:import to support multiple sources feeding the same tables (character_classes, character_class_features, and whichever of the optional-feature/feat/species tables we decide are in scope), each tagged with its own provenance/license, rather than a single Open5e-only pipeline.
• Write a small parser for 5etools' {@tag …} markup into clean display text (prior art: 5etools-utils, various community converters) as part of that importer.
• Scope which non-subclass content (optional features, feats, species, expanded bestiary) actually gets imported — each is its own decision, not bundled into one PR.
• Relates to #16, which fills in classProgression numbers for the 12 subclasses already in the library — that work can't surface the other ~50 official subclasses because they don't exist in character_classes at all today. This issue is what would actually get them in.

Picking this up after the current encounter-simulator feature branch lands.