Module stones

Trigger/Effect Stones — inventory handlers and the combat runtime.

The inventory half (insert, remove, upgrade, quick equip, upgrade all, the temporary drop grant) is a set of pure state transitions; the monolith persists whatever they produce.

The combat half is OverlordLogic::apply_stone_triggers, the single entry point of the whole mechanic. It hangs off apply_success_hooks, so it runs for every successfully handled event in both dispatch paths — the pure dispatch and the monolith’s merged arms — instead of being wired per event arm, where a new arm would silently miss it.

The rules the design rests on

• One cooldown for the whole build. A Core event checks every socketed trigger at once, every match fires and adds its tier weight to the gauge, then mech::GLOBAL_COOLDOWN is written once. Firing comes in bursts of up to five rather than five independent trickles.
• A condition met on cooldown is lost, and its counter restarts. No bank and no queue: mech::reset_sequence_counters takes the sequence back to zero, so “every 5th attack” starts counting from one again.
• Nothing an effect produces is Core. A trigger reacts to OverlordEvent::is_core_combat_event only, and every event this module emits carries CombatEventOrigin::Proc, which makes “effect grants a crit → crit trigger → effect grants a crit” inexpressible. A real Basic Attack stays Core even when an effect changed its magnitude, because effects add derived damage beside the real hit instead of rewriting it.
• No effect shortens the cooldown. It is written before the effect loop dispatches anything, which holds under re-entrancy too.

Its arithmetic and its per-fight bookkeeping keys live in crate::mechanics::stones.