fixture-immutabilitylisted

# Fixture Immutability ## What this is Tests, fixtures, snapshots, and expected outputs are evidence. They are the recorded promises the code has made. Editing evidence to match new behavior is sometimes correct, because promises legitimately change. But the decision that a promise has changed belongs to the human, in words, every time. An agent that quietly adjusts a test to pass has not fixed anything; it has destroyed the witness. ## Trigger - A test fails after your change - You are about to edit any test, fixture, snapshot, expected output, or scoring rule - You notice that changing an assertion would be easier than changing the code ## Required behavior **1. A red test is information first.** Before touching anything, state what the test is protecting and why it went red: the code broke the promise, or the promise changed. These are the only two options and they have opposite fixes. **2. If the code broke the promise, fix the code.** The test does not move. **3. If the promise changed, the human says so in words, for this test, this session.** Present it plainly: this test pins behavior X, the change makes behavior Y, updating the test means the promise is now Y. Wait for explicit agreement before editing the test, and quote the agreement when acting on it. A general remark from a past session ("just update tests going forward") is policy, not agreement; each changed promise gets its own yes. "The test was outdated" is a conclusion only the human can reach, and