modwright 0.1.0

package/knowledge/baldursgate3/stats.boosts.yaml

@@ -0,0 +1,293 @@
+game: baldursgate3
+topic: stats.boosts
+title: Boost mechanics, BoostContext, BoostConditions, and conditional evaluation
+facts:
+  - id: bg3.boosts.boostcontext-evaluation-events
+    claim: BoostContext is the list of events on which the engine EVALUATES a boost — it is not a
+      "re-check as well" hint. Omit the event that represents initial evaluation and the boost never
+      applies at all with no error. ~42 of ~46 vanilla usages include OnCreate (OnEquip;OnCreate
+      ×20, bare OnCreate ×18).
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - boost
+      - boostcontext
+      - oncreate
+      - silent-failure
+    detail: "A class mod's on-cast charge passive shipped completely inert (no icon glow, slot still
+      consumed, no on-cast damage) for a full relaunch cycle, while the toggle itself worked fine —
+      which is what made it confusing. The 5 vanilla entries using OnDamaged;OnHealed with no
+      OnCreate are bloodied-style buffs deliberately OFF until you are hurt; copying that pair onto
+      an at-will toggle makes it permanently dead. Pattern: if a boost should be live the moment its
+      source exists, either include OnCreate or omit BoostContext/BoostConditions entirely."
+  - id: bg3.boosts.context-source-invalid-hp-percent
+    claim: "context.Source is not an attested qualifier for HasHPPercentageLessThan in a Conditions
+      field: all 4 vanilla Conditions usages qualify with context.Observer, and BoostConditions
+      usages are bare or context.Target. The expectation is that context.Source makes the entire
+      condition string evaluate false, silently stopping every functor gated by it."
+    status: inferred
+    source: ModWright research
+    tags:
+      - boost
+      - conditions
+      - context
+      - hp-percent
+      - silent-failure
+    detail: "A class mod's diagnostic passive whose Conditions read \"... HasHPPercentageLessThan(15,
+      context.Source)\" was the prime suspect for a load-CTD (bisect-isolated: the previous version
+      loads, the next CTDs at module load), on the reasoning that an unresolvable qualifier in a
+      parsed condition is a candidate stats-load crash. The following version removed the entire
+      diagnostic harness rather than isolating the term, so the failure mode is reasoned, not seen.
+      Do the census before using any qualified context in a new field: grep -rho 'data \"<Field>\"
+      \"[^\"]*<Func>[^\"]*\"'."
+  - id: bg3.boosts.context-observer-invalid-oncast-self
+    claim: context.Observer ALSO fails in a plain OnCast-on-self passive Conditions field. The 4 vanilla
+      context.Observer uses are all reaction/interrupt passives with a genuine Observer entity. In
+      an OnCast passive that fires on the caster there is no Observer, so the term evaluates false
+      and the whole and-chain dies silently.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - boost
+      - conditions
+      - context.observer
+      - oncast
+      - silent-failure
+    detail: "Symptom: the free cast worked, the HP self-charge never fired. The charge condition was
+      \"and not HasHPPercentageLessThan(15, context.Observer)\" on the mod's passive. Fix: use the
+      BARE form HasHPPercentageLessThan(15) (defaults to the functor's own entity = the caster), or
+      don't gate the functor at all and gate via the source status's own RemoveConditions — the
+      mod's fix was a status that removes itself below 15% via RemoveConditions
+      \"HasHPPercentageLessThan(15)\" + RemoveEvents \"OnDamage\" (precedent MAG_LOWHP_IGNORE_AOO),
+      which then makes the passive's HasStatus() gate false, so one mechanism gates both the free
+      cast and the charge."
+  - id: bg3.boosts.context-qualifier-field-specific
+    claim: A context qualifier proven valid in one field+functor context is NOT automatically valid in
+      another; match it to the entities the functor context actually provides, and run a
+      field-by-field vanilla census before using any qualified context in a new field.
+    status: inferred
+    source: ModWright research
+    tags:
+      - boost
+      - conditions
+      - context
+      - field-specific
+    detail: "The worked case: context.Observer is vanilla-attested in reaction/interrupt passive
+      Conditions and fails in an OnCast-on-self passive (see
+      bg3.boosts.context-observer-invalid-oncast-self). Census command: grep -rho 'data \"<Field>\"
+      \"[^\"]*<Func>[^\"]*\"'."
+  - id: bg3.boosts.toggled-passive-oncast-dead-until-on
+    claim: IsToggled passives sit OFF by default, and a toggled-off passive's OnCast StatsFunctors NEVER
+      fire. Applying the linked status directly (bypassing the toggle) gives you the status's boosts
+      but not the passive's cast hooks — which looks exactly like "the functor silently doesn't
+      work".
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - boost
+      - toggles
+      - oncast
+      - forced-cast
+    detail: Test protocols must toggle the passive ON (in-game click or toggle functors) and keep status
+      presence coupled to toggle state via ToggleOnFunctors/ToggleOffFunctors. Separately, a forced
+      Osi.UseSpell cast resolves at spell power level 0 (not the selected level) — see
+      bg3.se.use-spell-forced-cast.
+  - id: bg3.boosts.arcane-battery-toggle-pattern
+    claim: "The safest shape for a toggled slot-free-cast is the vanilla Arcane Battery split: the
+      passive carries IsToggled + ToggleOn/OffFunctors + the OnCast functors, and a status carries
+      the UnlockSpellVariant boost. MAG_MagicItemPoweredCast_Passive + MAG_MAGIC_ITEM_POWERED_CAST
+      are the template."
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - boost
+      - toggle
+      - free-cast
+      - arcane-battery
+      - pattern
+    detail: TAD_Freecast proves a toggled passive CAN hold UnlockSpellVariant in its own Boosts — but
+      note it has no BoostConditions/BoostContext at all. BoostConditions/BoostContext have zero
+      vanilla precedent on any StatusData (they are Passive-only fields), which is why a class mod
+      gates its status with RemoveConditions instead.
+  - id: bg3.boosts.diagnosis-dead-condition
+    claim: To diagnose a dead condition string, put each candidate term in its own IsHidden passive with
+      StatsFunctorContext "OnCast" and StatsFunctors "ApplyStatus(SELF,<distinct marker>,100,2)".
+      One cast then shows, on the portrait, exactly which terms parse and evaluate true. Keep each
+      probe in a SEPARATE passive — a malformed condition kills its own entry's functors, which is
+      what makes the isolation useful.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - boost
+      - debugging
+      - conditions
+      - diagnostic
+    detail: "The marker form is what proved the character-level weapon gate dead in one cycle: a class
+      mod paired IF(CharacterLevelGreaterThan(3)):WeaponProperty(Magical) with a visible
+      IF(CharacterLevelGreaterThan(3)):WeaponDamage(1,Thunder) on the same condition, and the tester
+      reported no \"+1 Thunder\" at L4. Note the counter-case: that mod's six-probe harness was
+      itself suspected of a load-CTD and deleted before it produced any reading — a probe that
+      carries unproven syntax can cost a cycle instead of saving one."
+  - id: bg3.boosts.statusdata-boosts-apply-on-applystatus
+    claim: bg3.boosts.boostcontext-evaluation-events' "no OnCreate -> never applies" rule is confirmed
+      for PassiveData only. On StatusData, a Boosts field was observed to evaluate at ApplyStatus
+      (i.e. the moment the status is first applied) independent of BoostContext's
+      re-evaluation-event semantics — a class mod status's free-cast ModifyUseCosts boost applied
+      correctly with BoostContext "OnDamaged;OnHealed" and no OnCreate, deliberately run despite
+      ModWright's validator (bg3.history.boostcontext-initial-event) warning on it.
+    status: verified
+    verified_on: 2026-09-08
+    source: ModWright field verification
+    tags:
+      - boost
+      - boostcontext
+      - statusdata
+      - passivedata
+      - applystatus
+      - asymmetry
+    detail: 'An acceptance regression put BoostContext "OnDamaged;OnHealed" back on the status (not the
+      passive, where the free-cast mechanism now actually lives). SpellSlot resources were sampled
+      before and after a leveled non-cantrip cast with the toggle ON: L1 4/4, L2 3/3, L3 2/2 before
+      and after — completely unchanged, i.e. the free-cast boost fired anyway. This does not mean
+      BoostContext is meaningless on StatusData; it means the "missing OnCreate -> dead boost"
+      failure mode proven for PassiveData (see bg3.boosts.boostcontext-evaluation-events) does not
+      generalize to StatusData, and each entry type needs its own verification rather than assuming
+      the PassiveData rule everywhere.'
+  - id: bg3.boosts.weapon-level-gating-fails-passive
+    claim: CharacterLevelGreaterThan(N) (and character-level conditions generally) do NOT resolve the
+      wielder inside a passive weapon-item status Boosts IF(). A gate like
+      IF(CharacterLevelGreaterThan(3)):WeaponProperty(Magical) on a summoned weapon's status
+      silently never fires. No vanilla weapon status gates a boost by wielder level — that's the
+      tell.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - boost
+      - weapon
+      - level-gate
+      - passive
+      - silent-failure
+    detail: "Fix: gate weapon properties by SPELL SLOT instead — the summon's upcast child knows its
+      slot, so apply a different weapon status per slot tier (a class mod put
+      WeaponProperty(Magical) on the slot-3+ tiers). Slot ≈ level anyway. Cast-time IF() in
+      SpellProperties does see the caster's level and is the reliable place for character-level
+      logic — see bg3.spells.level-conditions-in-spellproperties."
+  - id: bg3.stats.dipped-weapon-status-check
+    claim: "To react to a dipped weapon from a character-context boost or condition, test the WEAPON for
+      the dip status: HasStatus('DIPPED_FIRE',GetActiveWeapon()) — the form vanilla's poison-dip
+      functors use. DIPPED_FIRE is a weapon status carrying WeaponDamage(1d4, Fire)."
+    status: unverified
+    source: ModWright research
+    tags:
+      - boost
+      - conditions
+      - dipped
+      - weapon
+      - hasstatus
+      - getactiveweapon
+    detail: "Example rider:
+      IF(HasStatus('DIPPED_FIRE',GetActiveWeapon())):CharacterWeaponDamage(max(0,DexterityModifier)\
+      ,Fire). A bare HasStatus('DIPPED_FIRE') in character context looks at the character, which
+      never carries the dip status, so the condition is silently always false."
+  - id: bg3.stats.downedstatus-drop-to-one
+    claim: "\"Drop to 1 HP instead of 0\" is Boosts \"DownedStatus(<DOWNED entry>,<n>)\", not an
+      interrupt. DEATH_WARD uses DownedStatus(DEATH_WARD_DOWNED,10); RELENTLESS_RAGE gates it with
+      IF(HasStatus('SG_Rage')). The DOWNED entry is using \"SURVIVAL_INSTINCT_DOWNED\" with
+      OnApplyFunctors \"RemoveStatus(<buff>);RegainHitPoints(1,Guaranteed)\"
+      (RELENTLESS_ENDURANCE_DOWNED)."
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: Vanilla Status_BOOST entries DEATH_WARD, RELENTLESS_RAGE, RELENTLESS_ENDURANCE_DOWNED and
+      SURVIVAL_INSTINCT_DOWNED (4.73.98.727)
+    tags:
+      - boost
+      - downedstatus
+      - death-ward
+      - relentless
+      - long-rest
+      - status
+    detail: A once-per-long-rest marker status survives short rests with StatusPropertyFlags
+      IgnoreResting and is cleared by a passive with StatsFunctorContext "OnLongRest" and
+      StatsFunctors "RemoveStatus(SELF,<marker>)". Verified against the vanilla data, not yet as a
+      custom entry in-game.
+  - id: bg3.boosts.conditional-damagebonus-in-item-boosts-renders-as-bare-dice
+    claim: A conditional damage boost written straight into an Armor/Weapon entry's Boosts
+      (IF(IsUnarmedAttack()):DamageBonus(1d4,Fire)) works mechanically but the item tooltip prints
+      it as a bare "1d4" line with no sentence. Vanilla keeps such bonuses in a PassiveData with a
+      DisplayName/Description (SCL_MastiffPoachers_Ring_Passive) granted through PassivesOnEquip, so
+      the tooltip shows a card instead.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - boosts
+      - damagebonus
+      - tooltip
+      - passives
+      - armor
+  - id: bg3.boosts.onattack-functors-target-the-struck-creature-swap-flips-to-the-attacker
+    claim: In a PassiveData with StatsFunctorContext "OnAttack", a plain ApplyStatus(X,100,n) lands on
+      the creature that was hit (vanilla UND_HARDWORK_TARGET, MAG_ELECTROCUTED do exactly this), and
+      ApplyStatus(SELF,...) on the attacker; ApplyStatus(SWAP,...) therefore sends the status to the
+      ATTACKER, which put Kindling on the wearer instead of the enemy.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - passives
+      - onattack
+      - functors
+      - swap
+      - self
+      - target
+  - id: bg3.boosts.weapondamage-boosts-do-not-reach-spells-that-roll-their-own-dice
+    claim: WeaponDamage(...) boosts on a weapon (DefaultBoosts or an equip status) are added only to
+      damage expressed as MainMeleeWeapon / MainRangedWeapon; a weapon action whose SpellSuccess
+      rolls its own formula (DealDamage(1d8+max(StrengthModifier,DexterityModifier), Slashing))
+      shows and deals none of the weapon's extra fire dice, and needs them restated in its own
+      DealDamage and TooltipDamageList.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - boosts
+      - weapondamage
+      - spells
+      - dealdamage
+      - tooltip
+  - id: bg3.boosts.vanilla-item-status-effects-use-statusonequip-beside-the-passive
+    claim: "When a vanilla item's effect is a status rather than a boost, the Armor entry carries
+      `StatusOnEquip \"<STATUS>\"` next to PassivesOnEquip: The Graceful Cloth
+      (MAG_BarbMonk_Defensive_Cloth) grants Cat's Grace as StatusOnEquip MAG_CATS_GRACE (using
+      CATS_GRACE: Advantage(Ability, Dexterity);FallDamageMultiplier(0.5); IgnoreResting) while its
+      +2 Dexterity to 20 is the passive MAG_BarbMonk_Armor_Defensive_Passive (Ability(Dexterity, 2,
+      20), DescriptionParams \"2;20\"). A mod item copies both halves to match it."
+    status: inferred
+    source: ModWright research
+    tags:
+      - armor
+      - statusonequip
+      - passivesonequip
+      - cats-grace
+      - ability
+  - id: bg3.boosts.ext-stats-hot-edits-do-not-reach-the-combine-index
+    claim: Setting a stat field from Script Extender at runtime (Ext.Stats.Get(name).ComboCategory =
+      ..., then Ext.Stats.Sync) reads back changed on server and client and survives a save+reload,
+      and editing a loaded Ext.Stats.ItemCombo entry's Ingredients in place also reads back changed;
+      neither produced a Combine option in the running session, so combine eligibility is fixed at
+      load and a pak change plus full restart is the only test loop for recipes.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - scriptextender
+      - ext-stats
+      - sync
+      - hot-edit
+      - itemcombos

package/knowledge/baldursgate3/stats.equipment-kits.yaml

@@ -0,0 +1,69 @@
+game: baldursgate3
+topic: stats.equipment-kits
+title: Character-creation equipment kits (Stats/Generated/Equipment.txt)
+facts:
+  - id: bg3.equipment.cc-kit-override-replaces-vanilla-entry
+    claim: "A mod's Public/<Mod>/Stats/Generated/Equipment.txt that declares new equipment
+      \"EQP_CC_Monk\" REPLACES vanilla Monk's character-creation kit wholesale: vanilla Monk's
+      ClassDescription ClassEquipment points at that entry (defined in SharedDev Equipment.txt), and
+      the mod's same-named block is the whole kit. Every vanilla line you want to keep must be
+      restated."
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - equipment
+      - character-creation
+      - kit
+      - override
+      - classdescription
+      - stats
+    detail: 'Vanilla Monk lines to restate for a like-for-like kit: the potions, OBJ_Scroll_Revivify,
+      ARM_Shoes_Monk, OBJ_Keychain, OBJ_Bag_AlchemyPouch, ARM_Camp_Body, ARM_Camp_Shoes,
+      OBJ_Backpack_CampSupplies. Format: new equipment "<id>", then add initialweaponset "Melee",
+      then repeated pairs of add equipmentgroup / add equipment entry "<stat>". Trade-off: this
+      conflicts with any other mod overriding the same kit — the same class of trade-off as
+      overriding a vanilla progression node. A custom class avoids it by naming its own
+      EQP_CC_<Class> from its own ClassDescription instead. Validator
+      bg3.stats.equipment-kit-entries-resolve checks the block shape and that every entry resolves.'
+  - id: bg3.equipment.cc-kit-one-body-item
+    claim: A CC kit must carry exactly one Breast-slot (body) armor. With two — a custom robe plus the
+      vanilla ARM_Monk — character creation drew the VANILLA outfit while the custom robe's
+      VertexColorMaskSlots still applied, so the character's arms vanished. Dropping the vanilla
+      body item fixed it.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - equipment
+      - character-creation
+      - kit
+      - armor
+      - slot
+      - vertexcolormask
+      - silent-failure
+    related:
+      - id: bg3.items.visualbank.vertexcolormaskslots-underwear-fix
+        detail: The body mask that hid the arms is the same VertexColorMaskSlots mechanism that fact copies
+          from the vanilla robe.
+      - id: bg3.equipment.cc-kit-override-replaces-vanilla-entry
+    detail: The symptom is silent — nothing logs; the CC preview simply shows the vanilla outfit with
+      body parts missing. Validator bg3.stats.equipment-kit-one-body-armor warns when two entries in
+      one kit resolve to Armor stats whose Slot (own or inherited via using) is Breast.
+  - id: bg3.equipment.kit-order-equips-first-then-pack
+    claim: Kit entries are equipped in list order into free slots; a later entry whose slot is already
+      occupied lands in the pack instead (the vanilla quarterstaff listed after a custom naginata
+      was carried, not wielded).
+    status: unverified
+    source: ModWright research
+    tags:
+      - equipment
+      - character-creation
+      - kit
+      - order
+      - inventory
+    related:
+      - bg3.equipment.cc-kit-override-replaces-vanilla-entry
+    detail: Consistent with what was seen (the custom weapon came first in the block and was the one
+      wielded), but the ordering rule itself was not tested by swapping the two lines. List the
+      intended wielded weapon first until it is.

package/knowledge/baldursgate3/stats.interrupts.yaml

@@ -0,0 +1,45 @@
+game: baldursgate3
+topic: stats.interrupts
+title: Reaction interrupts (Stats/Generated/Data/Interrupt.txt)
+facts:
+  - id: bg3.stats.interrupt-observer-context
+    claim: InterruptData Conditions carry context.Observer as the standard idiom (every reaction
+      interrupt opens with Self(context.Source,context.Observer) and
+      IsAbleToReact(context.Observer)), and interrupt functors address the reaction entities with
+      the target specifiers OBSERVER_OBSERVER, OBSERVER_SOURCE and OBSERVER_TARGET
+      (ApplyStatus(OBSERVER_OBSERVER,<status>,...), RemoveStatus(OBSERVER_OBSERVER,<status>)). The
+      passive-only "context.Observer is invalid" lesson does not apply to InterruptData.
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: Shared, SharedDev and Gustav Interrupt.txt read on 2026-09-17
+    tags:
+      - interrupt
+      - reaction
+      - conditions
+      - context.observer
+      - target-specifier
+      - stats
+    detail: "The ModWright rules bg3.history.context-qualifier-validity and
+      bg3.history.reference-integrity flagged a cloned Polearm Master interrupt on both counts
+      (block) until they learned the entry type: the known-invalid evidence is PassiveData
+      (OnCast-on-self), and OBSERVER_* is a target, not a status name."
+  - id: bg3.stats.interrupt-enter-reach-native
+    claim: 'An opportunity attack on a creature ENTERING reach is native: InterruptContext
+      "OnEnterAttackRange" with InterruptContextScope "Self" (vanilla Interrupt_PolearmMaster,
+      unlocked by the passive boost UnlockInterrupt(Interrupt_PolearmMaster)); its Conditions accept
+      a Reach weapon, a WPN_STAVE or a WPN_SPEAR. No Osiris hook is needed for enter-reach
+      reactions; a clone with extra Properties (an ApplyStatus(OBSERVER_OBSERVER,...) rider) keeps
+      the reaction cost and the AttackOfOpportunity stack.'
+    status: inferred
+    source: ModWright research
+    tags:
+      - interrupt
+      - reaction
+      - opportunity-attack
+      - reach
+      - polearm-master
+      - stats
+    detail: "A subclass mod's reaction replaced its Script Extender scaffold with a scoped clone of
+      Interrupt_PolearmMaster. The stack \"AttackOfOpportunity\" keeps it from doubling with the
+      ordinary leave-reach reaction. What an interrupt cannot do: charge a resource conditionally on
+      the attack HITTING (Properties run when the reaction is taken)."

package/knowledge/baldursgate3/stats.itemcombos.yaml

@@ -0,0 +1,65 @@
+game: baldursgate3
+topic: stats.itemcombos
+title: ItemCombos.txt � the inventory Combine recipes (forging one item from two)
+facts:
+  - id: bg3.itemcombos.file-lives-beside-data-not-inside-it
+    claim: Recipes go in Public/<Mod>/Stats/Generated/ItemCombos.txt � next to the Data/ folder, not
+      inside it � as `new ItemCombination "<name>"` blocks (Type N Object|Category, Object N,
+      Transform N Consume|Transform|None|Dye) followed by `new ItemCombinationResult "<name>_1"`
+      (ResultAmount 1, Result 1, PreviewStatsID). A mod's file loads alongside the vanilla ones and
+      Ext.Stats.ItemCombo.Get("<name>") returns it on server and client; // comment lines at the top
+      of the file did not stop it loading (vanilla files carry none).
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - itemcombos
+      - combine
+      - stats
+      - file-layout
+  - id: bg3.itemcombos.combine-menu-comes-from-the-template-peace-action-not-the-recipe
+    claim: 'An item gets the "Combine" context-menu entry only if its RootTemplate carries an
+      OnUsePeaceActions Action with ActionType 23 (Attributes: Animation "", CombineSlots 1 (int8),
+      IsBase True). A recipe alone never adds the option: recipes naming vanilla objects (Amethyst,
+      a plain Spear) gave those items no Combine entry either, while the vanilla Broken Spear halves
+      showed it even with their partner dropped from the bag.'
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - itemcombos
+      - combine
+      - roottemplate
+      - peace-action
+      - actiontype-23
+    detail: "Validator idea (design 05): flag an ItemCombination ingredient whose RootTemplate chain has
+      no ActionType 23 peace action � the recipe is unreachable from the UI."
+  - id: bg3.itemcombos.category-ingredient-reads-combocategory-and-custom-values-did-not-match
+    claim: 'A `Type N "Category"` ingredient is matched against the stat field ComboCategory (vanilla:
+      _Body armour "DyableArmor" for the dyes, _DRINK_* "Drink" for the trap combo,
+      "ConstructPart"), not ObjectCategory. A mod-defined value on a weapon (ComboCategory
+      "<ModCategory>", confirmed on server and client) still never matched in-game, so name the
+      partner directly with `Type N "Object"` and its stat name instead.'
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - itemcombos
+      - category
+      - combocategory
+      - objectcategory
+  - id: bg3.itemcombos.vanilla-shape-transform-first-consume-second
+    claim: 'Vanilla two-part forges list the part that becomes the result as Object 1 with Transform
+      "Transform" and the part that is used up as Object 2 with Transform "Consume"
+      (QUEST_FOR_CultistsRepairedSpear: Head transforms, Shaft consumed, Result FOR_TrueSoul_Spear;
+      the beer-barrel poisonings likewise). A Weapon stat can be the transformed Object 1 � the
+      Emberwatch Naginata (a Weapon) became the Naginata of Ashcrown this way.'
+    status: verified
+    verified_on: 4.73.98.727 (Patch 8)
+    source: ModWright field verification
+    tags:
+      - itemcombos
+      - transform
+      - consume
+      - ordering
+      - weapons