diff --git a/course/00-rewrite-trap/lesson.md b/course/00-rewrite-trap/lesson.md
new file mode 100644
index 0000000..13f4a30
--- /dev/null
+++ b/course/00-rewrite-trap/lesson.md
@@ -0,0 +1,267 @@
+# Module 0: The Rewrite Trap
+
+This module is an orientation. You get a small engine that is written the obvious way, you add one famous card to it, and you keep a record of what that cost you. Then you throw the engine away. Your real engine starts in [Module 1](../01-handles/lesson.md).
+
+Module 0 has no Spec, Build or Expansion Drop beats and no reference solution. Nothing here "fixes" the naive engine. The point is to feel the problem before the course names it.
+
+You will need:
+
+- the course repository, checked out;
+- Rust (`cargo`) or Node 24 with npm, whichever track you plan to take. You can try both.
+
+## Observe
+
+Baron Rivendare is a 4-mana 1/7 Legendary minion from Curse of Naxxramas. His card text ([Baron Rivendare, hearthstone.wiki.gg](https://hearthstone.wiki.gg/wiki/Baron_Rivendare)):
+
+> Your minions trigger their Deathrattles twice.
+
+Loot Hoarder is a 2-mana 2/1 with this text ([Loot Hoarder, hearthstone.wiki.gg](https://hearthstone.wiki.gg/wiki/Loot_Hoarder)):
+
+> Deathrattle: Draw a card.
+
+With Baron on your board, a dying Loot Hoarder draws two cards. The wiki says the Deathrattle is queued once and that "the second activation of the Deathrattle is immediately after the first activation resolves" ([Baron Rivendare](https://hearthstone.wiki.gg/wiki/Baron_Rivendare)).
+
+Baron does not change Loot Hoarder, and Loot Hoarder knows nothing about Baron. One card changes how a whole mechanic behaves. Players think of this as a single sentence of card text. In code, that sentence has to land somewhere.
+
+## Predict
+
+Write your answers down before you open the discussion. A file such as `notes/00.md` in your own workspace is fine.
+
+1. Before you read the engine: how many functions do you expect to change to add Baron Rivendare?
+2. You have Acolyte of Pain (played first) and Loot Hoarder on the board. You cast Whirlwind. Write the order of events you expect: each damage, each trigger, each draw, each death.
+
+The three cards involved ([Whirlwind](https://hearthstone.wiki.gg/wiki/Whirlwind), [Acolyte of Pain](https://hearthstone.wiki.gg/wiki/Acolyte_of_Pain), [Loot Hoarder](https://hearthstone.wiki.gg/wiki/Loot_Hoarder)):
+
+- Whirlwind, 1-mana spell: "Deal 1 damage to ALL minions."
+- Acolyte of Pain, 3-mana 1/4: "Whenever this minion takes damage, draw a card."
+- Loot Hoarder, 2-mana 2/1: "Deathrattle: Draw a card."
+
+Discussion: the Whirlwind order
+
+The real game deals all of the damage first, then resolves the damage triggers, and only then processes deaths:
+
+1. Damage to Acolyte of Pain, then damage to Loot Hoarder. For area damage, "all of the Damage/Healing Events are created in play order" and then resolved in play order ([Advanced rulebook](https://hearthstone.wiki.gg/wiki/Advanced_rulebook)). The rulebook's Frothing Berserker example puts it plainly: "all the damage occurs, then each 'On Damage' Event is resolved based on the order of play."
+2. Acolyte of Pain's trigger: draw a card.
+3. Loot Hoarder dies. A minion at 0 Health is only *mortally wounded* until the outermost Phase ends: "mortally wounded and pending destroy are ONLY converted into dead once the outermost Phase ends!" ([Advanced rulebook](https://hearthstone.wiki.gg/wiki/Advanced_rulebook)).
+4. Loot Hoarder's Deathrattle: draw a card. Deathrattles resolve in a Death Phase after the Death Creation Step ([Advanced rulebook](https://hearthstone.wiki.gg/wiki/Advanced_rulebook)).
+
+The naive engine's test suite states exactly this order in `test_00_real_rules_whirlwind_order`:
+
+```rust
+game.summon("Acolyte of Pain"); // played first
+game.summon("Loot Hoarder");
+game.cast("Whirlwind");
+assert_eq!(
+ game.log,
+ vec![
+ "damaged Acolyte of Pain 1",
+ "damaged Loot Hoarder 1",
+ "triggered Acolyte of Pain",
+ "drew a card",
+ "died Loot Hoarder",
+ "deathrattle Loot Hoarder",
+ "drew a card",
+ ]
+);
+```
+
+```ts
+game.summon("Acolyte of Pain"); // played first
+game.summon("Loot Hoarder");
+game.cast("Whirlwind");
+expect(game.log).toEqual([
+ "damaged Acolyte of Pain 1",
+ "damaged Loot Hoarder 1",
+ "triggered Acolyte of Pain",
+ "drew a card",
+ "died Loot Hoarder",
+ "deathrattle Loot Hoarder",
+ "drew a card",
+]);
+```
+
+The naive engine cannot pass it, so the test is marked expected-to-fail (`#[should_panic]` in Rust, `test.fails` in TypeScript). Remove the marker and run the tests to see the order the engine really produces: Acolyte is damaged and draws before Loot Hoarder is even hit. If your prediction matched the engine rather than the game, that is the point of this module. The obvious code gives an order that looks reasonable and is wrong.
+
+Discussion
+
+Most learners end up with a check inside the death code: "if a Baron is on the board, run the Deathrattle again". It works, and the test passes. But the engine now knows about one specific card, and the function that runs Deathrattles is the place every future Deathrattle rule has to be squeezed into.
+
+From Module 1 on, the course enforces the **Zero-Coupling Law**: engine code never names a specific card. A coupling audit checks it. The fix you just wrote would fail that audit.
+
+Discussion
+
+Each of them is another branch in the code that runs triggers. They all share a shape ("when a trigger of kind X fires, fire it N times") but the naive engine has nowhere to put a shape. It only has places to put special cases. Module 4 turns "trigger twice" into data that one generic piece of the engine consults.
+
+Discussion
+
+In the real game, "Rivendare's ability is not duplicated or multiplied by having more than one Baron Rivendare in play." ([Baron Rivendare](https://hearthstone.wiki.gg/wiki/Baron_Rivendare)). If your fix loops over the board and fires the Deathrattle once per Baron, you draw three cards instead of two. If you check "is any Baron on the board", you got this one right, perhaps by luck.
+
+Discussion
+
+In the real game you draw one card: "if he dies at the same time as a minion with a Deathrattle, the Deathrattle is not doubled." ([Baron Rivendare](https://hearthstone.wiki.gg/wiki/Baron_Rivendare)). The rules behind this: deaths are processed together when the outermost Phase ends, and Baron's doubling is an aura that is updated after the Death Creation Step, so it is already gone when the Deathrattle resolves ([Advanced rulebook](https://hearthstone.wiki.gg/wiki/Advanced_rulebook)).
+
+In the naive engine there is no "at the same time". Each minion dies alone, the instant its Health hits 0. If Baron dies first you draw one card; if Loot Hoarder dies first you draw two. The result depends on board position, which the real game never consults here.
+
+Discussion
+
+Because one function call does three jobs. In the naive engine, dealing damage *is* running the trigger *is* killing the minion:
+
+```rust
+pub fn deal_damage(&mut self, target: &MinionRef, amount: i32) {
+ // ...lower health, log "damaged"...
+ if let Some(effect) = on_damaged {
+ effect(self, target); // trigger runs now
+ }
+ if target.borrow().health <= 0 {
+ self.kill(target); // death and Deathrattle run now
+ }
+}
+```
+
+```ts
+dealDamage(target: Minion, amount: number): void {
+ // ...lower health, log "damaged"...
+ if (target.onDamaged) {
+ target.onDamaged(this, target); // trigger runs now
+ }
+ if (target.health <= 0) {
+ this.kill(target); // death and Deathrattle run now
+ }
+}
+```
+
+To get the real order you have to separate asking for something from doing it (Module 2) and decide death at defined checkpoints instead of the moment Health reaches 0 (Module 3). Neither fits inside the existing function. Both need a different engine shape.
+
+One more thing to notice: Whirlwind loops over a copy of the board holding direct references. A minion that has already died is still in that copy. If a later effect in the loop hit it again, the engine would happily kill it a second time. Module 1 replaces references with IDs for this reason.
+
+