Troubleshooting

Resource won't start / errors immediately

Load order. legacy-lib, ox_lib, and oxmysql must start before legacy-crafting. In particular, client/benches.lua calls exports['legacy-lib']:Target() at file load time — if legacy-lib isn't started first, this fails immediately.
legacy-skills not started. legacy-skills is not a hard dependency, but if Config.UseSkillsResource = true and it isn't running, XP calls will fail or behave unexpectedly. GetCraftingProgress silently falls back to the local tier/XP system if legacy-skills's resource state isn't 'started' — this fails silently, so double-check Config.UseSkillsResource matches what's actually running.

fetchAndSpawn() only runs once, 2000ms after resource start, and again on legacy-crafting:syncBenches. There's no retry/backoff — if oxmysql is still connecting when that timer fires, benches simply won't show until the next sync event.
For use_existing_prop benches, OpenCrafting resolves camera position from the live spawned entity first, falling back to stored bench.coords. Existing-prop benches never have a spawned entity, so bench.coords must be populated correctly in the DB or the camera will be positioned wrong.
If you insert bench rows directly into legacy_crafting_benches instead of using the in-game placement UI (StartBenchPlacement/StartExistingPropSelection), you must manually populate camera_angle, camera_height, camera_distance, prop_offset_x/y/z, and player_coords — otherwise the camera/prop preview silently falls back to defaults (0,0,0.85 offset, Config.CameraOffset height/distance, 'front' angle) and the player will play the crafting animation wherever they're standing instead of at the bench.
RegisterBenchStashes() only runs once, 1 second after resource start. If legacy-crafting itself restarts, every storage-enabled bench must still exist in legacy_crafting_benches for its stash to re-register on boot.

Config.AdminCommand and every admin export check IsAdmin(), which combines the framework's own admin flag with ACE group membership (group.<name>) for each entry in Config.AdminGroups. Players need the ACE group actually granted, not just an in-game admin job/permission level — this is the most common reason admins get rejected.
The admin command rejects console execution (source == 0) entirely.

Storage-mode benches never see player inventory items. If bench.storage_enabled is true, ingredient checks look only at the bench's stash, never the player's inventory. A player carrying the item but with an empty stash will always see "Missing".
ox_inventory is hard-required for crafting, even outside storage mode — the craft callback calls exports.ox_inventory:Search / RemoveItem directly rather than going through the Inventory wrapper. Swapping inventory frameworks via legacy-lib does not change this.
required_jobs format differs between benches and recipes. bench.required_jobs is a raw comma-separated string compared against the player's job/gang name. recipe.required_jobs on legacy_crafting_recipes is stored/decoded as JSON. Writing the wrong format directly to the DB will silently break access checks for one or the other.

When Config.UseSkillsResource = true, legacy_crafting_xp.xp stays at 0 for every player (only total_crafts is tracked locally) — XP actually lives in legacy-skills. Reading legacy_crafting_xp directly in this mode will misleadingly show 0 XP / Novice even for high-level players.
cachedTiers is a module-level cache populated on first getTiers() call, only invalidated by saveTier/deleteTier. Editing legacy_crafting_tiers directly in the database will not be reflected until a resource restart.
If legacy_crafting_tiers is empty, LoadTiers() silently falls back to Config.Tiers from config.lua instead of erroring — seed the table or configure Config.Tiers before relying on tiers.
Toggling Config.UseSkillsResource changes what required_level means (1–5 vs 1–75) — recipes configured for one system will be misconfigured after switching without revisiting required_level values on every recipe.

sql/schema.sql starts with DROP TABLE IF EXISTS on all legacy_crafting_* tables — never run it against a live database unless you intend a full wipe.
Cascading deletes are in effect: deleting a category deletes all its recipes; deleting a recipe or bench deletes its ingredients/assignments. Using deleteCategory/deleteRecipe/deleteBench has effects beyond the single row.
sql/seed_gun_recipes.sql and sql/seed_heists_and_weapons.sql are idempotent via upfront DELETE ... WHERE output_item IN (...) blocks — re-running them discards any manual edits you made to those same recipes in the admin panel.
sql/seed_heists_and_weapons.sql uses raw weapon hash strings (e.g. WEAPON_MINIGUN) as output_item — your inventory system must recognize these as valid items or crafting will succeed server-side while producing an item your inventory can't handle. It also seeds some recipes with required_level up to 72; if your tier/XP curve doesn't reach that high, those recipes are permanently uncraftable until adjusted.
saveBench looks up prop_model from a legacy_crafting_bench_types table when bench_type_id is given and prop_model is blank. This table is not part of the documented schema — if it doesn't exist or isn't populated, the lookup silently returns nothing and falls back to prop_tool_bench02.

The NUI (web/) must be built with npm install && npm run build inside web/ to produce web/dist — the Lua side loads the built output, not the raw src. Running commands from the resource root won't trigger this build.
Adding a new language requires a locales/<locale>.json with the exact same keys as locales/en.json — there is no fallback for missing keys.
web/vite.config.js must keep base: './'; changing it to an absolute path breaks asset loading inside the FiveM CEF browser.
tailwind.config.js references CSS variables (--accent, --accent-dim, --accent-gradient) that must be defined in a root CSS file elsewhere, or accent color/gradient utility classes won't render correctly.