Full Go port of suitbuilder.py's ConstraintSatisfactionSolver (the LIVE solver
behind the suitbuilder UI; main.py's /optimize/suits is legacy/unused):
- suit_model.go: CoverageMask + reductions, SuitItem/ItemBucket/SuitState,
SpellBitmapIndex, ScoringWeights, SearchConstraints, CompletedSuit.to_dict,
ItemPreFilter, set name<->id maps. Every sort carries (character_name, name)
tiebreakers for deterministic results.
- suit_solver.go: the 5-phase pipeline — load_items (fed in-process by the Go
/search/items), create_buckets (+multi-slot/generic-jewelry expansion),
apply_reduction_options, sort_buckets, and the depth-first recursive_search
with both Mag-SuitBuilder pruning rules, can_add_item constraints (set limits,
jewelry spell contribution, strict spell mode), scoring, and finalize.
- suit_http.go: POST /suitbuilder/search (SSE: phase/log/suit/progress/complete),
GET /suitbuilder/characters, GET /suitbuilder/sets.
- search.go: refactor handleSearchItems -> shared runSearch (the solver reuses
it so both see identical rows); emit slot_name (get_sophisticated_slot_options
+ translate_equipment_slot); fix the trinket slot_names clause to exclude
%bracelet% (matches Python).
- slotname.go: the EquipMask-based slot translation, loaded from the enum DB.
Validation: 9/9 scenarios stream byte-identical suits vs the Python service on
production data (no-spell, multi-character, locked slots with/without spells,
spell constraints, alternate set pairs, primary-only). ~45x faster than Python.
Three subtle bugs found and fixed during validation:
- slot_name is load-bearing, not display: jewelry's computed_slot_name is empty,
so load_items falls back to slot_name to bucket rings/neck/wrists/trinket.
- Python scoring uses floor division (total_armor // 100); total_armor goes
negative (non-armor items carry armor_level -1) so Go's truncation was +1 off.
- the trinket fetch must exclude bracelets or they duplicate the Wrist buckets.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds the remaining search-result enrichment that the suitbuilder solver (and the
item-detail UI) depend on, validated byte-exact against the Python service on
production data:
- Load the SpellTable (spells.values, 6266 entries) from the enum DB and port
translate_spell (id -> {id,name,description,school,difficulty,duration,mana,
family}, Unknown_Spell_<id> fallback, "" defaults).
- Emit `spells` (full dicts) and `spell_names` from the ordered passive Spells
array (original_json->'Spells', array order + duplicates preserved), exactly
as enrich_db_item/extract_item_properties do — NOT from item_spells. Only set
when the item has spells. A jsonb_typeof guard keeps non-array Spells safe.
- Add the shirt_only / pants_only / underwear_only filters as CTE-body WHERE
injections (coverage-bit logic on key 218103821), mirroring main.py.
Validation (char Plant Enjoyer, all chars): spell_names 0 mismatches (8 spell
items), spells[].name 0 mismatches, shirt_only/pants_only item sets identical
(0 only-py / 0 only-go). Normal-search total_count still matches Python.
Note: for shirt/pants/slot filters Python's total_count is inconsistent with its
own items (separate count CTE lacks the injection); Go uses one CTE so the count
is self-consistent. Deliberately not replicating that Python bug.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Loads the ObjectClass enum map and adds object_class_name via translate_object_class,
including the context-aware Gem(11) classification (crystal/mana stone/gem/aetheria
by item name, using the original name before the material prefix). The rare
aetheria-by-IntValues path is documented as not reproduced (needs original_json).
Validated vs Python: 0 mismatches over 600 rows (3 queries incl. a 'crystal' text
search that exercises the gem context) for object_class_name, name, material_name,
item_set_name, value.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
enrichRows now applies the material-name prefix to name (material is already a
translated string in the DB), sets material_name + original_name, and resolves
item_set_name via the AttributeSetInfo enum (fallback "Set {id}").
Validated vs Python position-by-position: 0 mismatches across 60 armor + 60
jewelry rows for name, material_name, item_set_name, original_name, value,
object_class. Sample names match exactly (e.g. "Gold Alduressa Coat").
Remaining enrichment slices: object_class_name (gem context), spells/spell_names
(needs the spells enum map), slot_name (sophisticated), weapon damage/speed/mana,
rating gear-total fallbacks.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds the full computed_slot_name CASE (EquippableSlots decode, jewelry by
wielded-location, weapons, cloak) and the remaining SQL filters: weapon_type
(skill-id EXISTS), slot_names (per-slot OR clauses), item_set/item_sets
(translate_equipment_set_id, bug-for-bug).
Validated vs Python (total_count EXACT): weapon_type heavy/bow/caster (473/138/
474), slot_names ring/neck/cloak (1286/1428/220), item_set 13 (526). The
computed_slot_name VALUES match exactly (slot distribution identical: Head 721,
Hands 458, Feet 403, Chest 376, ...).
Two documented edge-case discrepancies, both Python main-vs-count CTE
inconsistencies (Python's count query uses a SIMPLIFIED slot CASE where armor ->
'Armor', so its own total_count disagrees with its item list): slot_names with
armor slot names, and sort_by=slot_name empty-string ordering. Our consistent
single-CASE implementation is arguably more correct; reconcile to Python's count
CTE later if strict parity on those is required.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Ports the search CTE (items_with_slots: combat/req/enh joins + the rating
extractions from item_raw_data.int_values JSONB via GREATEST/COALESCE, coverage
mask, computed_spell_names), the SQL filters, sort mapping, pagination, and the
DISTINCT count query. Returns each row's direct DB columns + computed booleans
(is_equipped/bonded/attuned/rare, condition_percent).
Validated vs the Python service on the production DB: total_count EXACT across
13 filter combinations (armor/jewelry/min_armor/min_damage/text/material/
min_value/is_rare/rating/equipped/character/workmanship), and 50-row alignment
with 0 direct-column mismatches (same SQL sort order, same rows).
Deferred to later slices: deep per-row enrichment (extract_item_properties:
material_name/spells/slot_name/object_class_name/...), and the enum-dependent
filters (has_spell/spell_contains/legendary_cantrips, slot_names, item_set,
weapon_type, underwear).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
