git:20260912.c1de365 to git:20260913.3c614b8

17 added, 23 removed. Audit A to A.

---

name: equipment-progression

- description: Engine-neutral equipment economy. Pick one growth model per slot — replace, upgrade in place, affix-craft, or fuse. Use for loot, crafting, loadout caps, set bonuses.

+ description: Use when weapons, armor, tools, loadouts, upgrades, affixes, fusion, set effects, or replacement gear need a clear ownership and progression model without mixing incompatible item identities.

---

# Equipment Progression

- Ask which column each *slot* uses. Mixing columns on the same instance is the usual failure.

+ This skill owns **equipment instance identity, slot compatibility and progression transforms**. `inventory-economy` owns storage, `crafting-loop` owns recipe transactions, and `durability-economy` owns wear.

- | Column | What the player keeps | What "upgrade" means |

+ ## Modes

+ | Mode | Persistent identity | Progression |

|---|---|---|

- | A Replace | Nothing; next drop is the upgrade | Find a better instance |

- | B Tree | The same instance | Spend mats, pick a branch |

- | C Affix | The same base | Reroll / add / masterwork stats |

- | D Fuse | The same instance + a spent mat | Function changes; may add wear |

- | E Eternal | A named unique | Cooldown or bond, not a town repair |

+ | replace | instance is normally superseded by another | acquire another instance |

+ | tree | same instance | authored upgrade branch |

+ | affix | same base identity | add/reroll/masterwork attributes |

+ | fuse | output identity is authored from inputs | consume/combine instances |

+ | eternal | named/persistent identity | authored unlock/bond/cooldown progression |

- Legal split: weapons A + armor B. Illegal: one sword that both shatters *and* trees to endgame.

+ A project may combine systems when identity and transition semantics are explicit. Do not declare a combination illegal merely because another genre usually avoids it.

- ## Rules that do not belong to any franchise

+ ## Stable item contract

- 1. Attack lives on the item. Defense lives on the body. Buff food is a third, timed layer.

- 2. Set bonuses open at mid-tier or full set, never at +0.

- 3. Slot caps are difficulty. Expanding a page is a reward, not a vendor dump on minute one.

- 4. An upgrade recipe must name the missing mat *and* the region class it comes from. That is map gravity.

- 5. Failed upgrades are readable. Do not swallow materials into a silent RNG without a tell.

+ Each equipable instance has a stable instance ID plus item definition ID, slot/type, progression mode/state and authored modifiers. Save/migration must not key an item by localized display name or transient list index.

- ## Data

+ Upgrade/fuse/reroll operations are transactions coordinated with `crafting-loop` and `inventory-economy`: inputs are validated, consumed once, output is created/updated once, and duplicate callbacks do not duplicate gear or lose materials.

- ```

- Item { id, slot, column: A|B|C|D|E, tier,

- attack?, defense?, set_id?,

- wear?, upgrade[]{ mats[], unlocks? } }

- ```

+ Set bonuses, starter viability, tier pacing, slot caps and acquisition geography are project design choices. Publish them in data and validate them against the intended game instead of imposing universal tier or endgame laws.

- ## Accept

+ ## Acceptance

- The starter item in a Replace slot cannot finish the game unless it is tagged Eternal. The player can look at a mountain and know why they would go there for a mat. Inventory is tight enough that discard is a real choice.

+ Replay acquire/equip/replace/upgrade/fuse/save/load paths including duplicate callbacks and a failed transaction. Stable item identities, consumed inputs and resulting slot state remain consistent. Test at least one project-specific progression edge case; rarity color or “bigger number” alone is not progression evidence.