mirror of
https://github.com/prosolis/gogobee.git
synced 2026-07-18 01:42:42 +00:00
b6d4e4ccec
The self-view listed a name, a tier and a price — everything except what a player decides on. The facts were all there, just not on the wire. Three things the contract spec got wrong, found by reading both sides: Equipping *moves* the row out of adventure_inventory into magic_item_equipped, so the two sets are disjoint. The spec's `attuned` on a backpack item can never be true — bond state isn't false there, it's undefined. The real gap was that worn items weren't sent at all: the panel showed the backpack and hid the sword. Hence Equipped, where Attuned means something and an inert item can be seen. Stat modifiers ARE modeled. The spec said they weren't, and that shipping them meant either an engine change or a display-only approximation that lies the first time it disagrees with the engine. But magicItemEffectSummary is the engine's own summary — the same function the game speaks with. Sending it can't drift, because there's nothing to drift from. SkillSource is two different things: "mining" on masterwork gear, and the internal "magic_item:<id>" registry pointer on magic-item rows. Sending it raw would put gogobee's IDs on a page, and Pete couldn't tell them apart to filter them. Only the skill name goes out. Desc and Effect resolve at the push site because an inventory row carries neither — descriptions live on MagicItem/EquipmentDef, and the combat delta is computed, never stored. Shop gear resolves by (slot, tier); Name is decorative there. All additive and omitempty on the private /api/ingest/detail push, so neither side has to deploy first.