functional-managing-state-immutablylisted

# Managing State Immutably ## Overview Assignment is the source of most of the hard problems in software: a value that changes cannot be reasoned about locally, cannot be shared safely between threads, and cannot be replayed. Functional programming's central move is to stop assigning: a transformation produces a new value and leaves the old one alone. State does not disappear. It becomes explicit: a value, transformed by pure functions, held in exactly one place, and replaced under a controlled swap. That is what makes concurrency safe by construction rather than by discipline. ## When to use - Data is mutated in place and read from several places - A race condition, or a lock protecting shared data - Deciding how an entity changes over time - History, undo, or audit is needed - A cache, counter, or connection pool needs a home Not for: deciding which effects the system performs, which is [functional-separating-pure-core-from-shell](../functional-separating-pure-core-from-shell/SKILL.md). ## Core rules 1. Rule. **Transform, do not mutate.** A function that changes a value returns a new one. The caller decides what to keep. 2. Rule. **State transitions are pure functions.** `State -> Event -> State`. No I/O inside, no clock, no randomness. 3. Default. **Keep mutable state in one place, at the edge.** One reference cell, one database row, one actor. Not a field on ten objects. 4. Default. **Swap, do not edit.** Replace the whole value atomically; never parti