Every "Already known" check read `spellbook.slots`, and
`SpellDisplay::in_spellbook` filters out `SPELL_ATTR_IS_TRADESKILL` — correctly,
since recipes live in the trade-skill window, not the spellbook. So the question
"do I know this spell?" answered **no for every crafting recipe in the game**: a
recipe item never showed its `ITEM_SPELL_KNOWN` red line, and nothing stood
between the player and consuming it a second time.
grom learned Plans: Copper Chain Vest (item 3609) twice.
`PlayerReqState` gains `known_spells`, filled from `PlayerActions::spells` —
`SMSG_INITIAL_SPELLS` plus every learn, which is the set the reference's own
check reads (`0xb700b0`). It belongs there: that struct is already "the player
state the tooltip's red lines and the usable gate compare against", already
change-gated on the action/spell inputs, and already pushed by the same feed.
Both readers move over: the taught-spell line and `item_usable_by_id`'s spell
requirement, which had the same hole.
The existing `verified_families_signable_locked_resists_known` only passed
because it made the recipe known by putting it in the spellbook, which no real
session does — it now sets the known set instead, and that is the change's own
regression story. The new test leaves the spellbook deliberately empty, which is
the real shape and what fails if the check ever reads it again; it asserts the
not-yet-learned case too, so it cannot pass by always reading red.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
gromandClaude Opus 5
b4a5d3b38f