diff --git a/course/02-action-queue/lesson.md b/course/02-action-queue/lesson.md
index 8be4adb..1ec578a 100644
--- a/course/02-action-queue/lesson.md
+++ b/course/02-action-queue/lesson.md
@@ -329,9 +329,75 @@ If the check fails, fix your engine (a normal commit, outside the drop), then re
+## Stress it
+
+Optional. Each question pushes the design past what this module's tests check. Predict first, then open the discussion.
+
+1. Add a fictional card to your content: Test Bomb, 1/50, "Whenever a minion takes damage, deal 1 damage to all minions." Summon one and deal it 1 damage. Before you run it: what does your engine do, and what is in the log when it stops?
+
+Discussion
+
+It never stops on its own. The Bomb's trigger damages the Bomb, which queues the Bomb's trigger, inside itself. The reference engine at this module recurses until the language runtime gives up: in the TypeScript track that is a `RangeError` after about two thousand log events, with the Bomb at −936 Health. A stack overflow in the middle of a Sequence also leaves the world half-changed, which is worse than the crash.
+
+Depth-first resolution by plain recursion is the right model and it has this cost: nothing bounds the depth. Two real games answer in two different ways.
+
+- **Forbid it by rule.** The Advanced rulebook: "A trigger cannot be nested inside itself" ([Advanced rulebook](https://hearthstone.wiki.gg/wiki/Advanced_rulebook)). In engine terms: keep the set of (source, trigger) pairs that are resolving right now, and don't queue an entry that is already in it. Try it. With the guard, the Bomb damages everything once and the Sequence ends: its trigger is on the stack when its own damage lands, so it isn't queued again.
+- **Allow it and name the outcome.** Magic: The Gathering has no such guard. Rule 104.4b: "If a game ... somehow enters a 'loop' of mandatory actions, repeating a sequence of events with no way to stop, the game is a draw." ([Comprehensive Rules](https://magic.wizards.com/en/rules)). An engine for that game has to *detect* the loop, which is harder than preventing it.
+
+Either way the decision belongs in the engine's one resolution loop, and it is a rule of the game, not an implementation detail: two Bombs under the guard still hit each other once each, and a player can see that.
+
+The guard is not part of the course's tests, and the reference doesn't have it; [Module 3](../03-death-step/lesson.md) says why it can wait. If you add it, add a test with it.
+
+Discussion
+
+Only `test_02_depth_first_nesting`: the triggers come out Echo, Armorsmith, Reactor, and `ArmorGained` precedes Reactor's `StatsChanged`. The other three pass, which is worth noticing. Area damage first, mortally wounded minions that still react, and fatigue are all independent of the depth-first rule. One test in the module pins it.
+
+What you gained is that the breadth-first engine can't overflow the stack: question 1's Bomb fills a list instead (forever, but politely). That is why queues are the pattern people reach for first, and why Nystrom's advice in Name it is to avoid raising events from handlers. If you want depth-first order *and* no recursion, keep an explicit stack and push a trigger's consequences on top of it, to be resolved before what was already waiting. That is Slay the Spire's "add to top" from Further reading, and it is the same order your recursion produces.
+
+Discussion
+
+One number: the nesting depth at which each event was recorded (or, equivalently, a "block opens" and a "block closes" marker around each trigger's resolution). Your `react` already knows it; it is the depth of the recursion.
+
+```text
+Damaged(Armorsmith, 1)
+ Triggered(Echo)
+ Damaged(enemy hero, 1)
+ Triggered(Reactor)
+ StatsChanged(Reactor, 2, 5)
+ Triggered(Armorsmith)
+ ArmorGained(0, 1)
+```
+
+Printed this way the depth-first rule is visible at a glance: Reactor's line is *inside* Echo's block, and Armorsmith's block starts only after Echo's has closed. A breadth-first engine can't print this tree at all, because its events have no single parent block that is still open. The nested blocks in the game's own log are consistent with the rulebook's "similar to a depth-first search"; that is the course's reading of the log format, not a statement from Blizzard.
+
+Keep the tree printer. It is the most useful debugging tool you will have in Modules 3 and 4.
+
+Discussion
+
+In `perform`, between "an effect asked for 3 damage" and "the world changed": lower Armor by 2, lower Health by 1, and record one `Damaged` event, so Reactor triggers once. Not in the card, because every source of damage would have to remember to do it. Not in a trigger, because triggers react to events that have already happened, and this changes what happens.
+
+That makes Armor the course's first example of a rule that **rewrites an action before it is performed**, rather than reacting after. Module 4 builds a different rule of that family (how many times a trigger runs), and names the general one: a replacement effect. The questions you just had to answer are the ones every such rule raises. Does the event report the amount asked for or the amount that got through? (The wiki's second quote suggests "it still counts", so the event exists even if Health didn't change.) And if two rewriting rules apply to the same action, which goes first?
+
+The course doesn't build this: no test damages a hero that has Armor. If you build it, decide what `Damaged.amount` means and write that down next to the event type.
+
+Discussion
@@ -43,6 +47,10 @@ Write your answers down before you open the discussion, for example in `notes/03
4. In the Sequence's entry point, after the action and all its reactions have resolved. `damage` runs inside nested Phases: if it removed the minion, the minion would miss the reactions it is still owed (Module 2's mortally wounded Acolyte), and a removal there would happen mid-Phase, in the middle of somebody else's Queue. One checkpoint at the end of the outermost Phase means one place where minions leave play.
+5. Left of the Reactor: that is where the Golem stood. An engine that remembered "index 1" gets it wrong. When the step began the board was `[Hoarder, Golem, Reactor]` and the Golem was at index 1. The step then removes the Hoarder *and* the Golem, so the board is `[Reactor]`, and index 1 is now the right end: the token lands to the right of the Reactor.
+
+ This is Module 1's Predict question 2 again. "A board index goes stale as soon as anything moves", and a Death Creation Step moves several things at once. The first version of this course's own reference engine had exactly this bug, and the original four tests passed, because none of them had a minion die to the left of a summoning Deathrattle in the same step. The cure is the same as in Module 1: remember a handle. See Build.
+
Hint 2 — concept
- **Marks, not removals.** Damage lowers Health. A destroy action sets a `pendingDestroy` flag. Neither moves anything.
-- **Death Creation Step:** one function. Collect every minion in play, in order of play, that has Health ≤ 0 or `pendingDestroy`. Read each one's board index *first*, then move them all to the graveyard and record `Destroyed` for each. Return their Death Events, each holding the id and the remembered position.
+- **Death Creation Step:** one function. Collect every minion in play, in order of play, that has Health ≤ 0 or `pendingDestroy`. For each one, *first* note where it stands, then move them all to the graveyard and record `Destroyed` for each. Return their Death Events, each holding the id and the remembered place.
+- **Remember a neighbour, not an index.** An index into the board is wrong as soon as another minion further left leaves in the same step (Predict question 5). Remember instead the nearest minion to the right that is *not* dying in this step, by id, or "none". Nothing leaves play during the Death Phase that follows, so that minion is still on the board when the Deathrattle resolves, and "immediately left of it" (or the right end, for "none") is where the dead minion stood.
- **Death Phase:** if the step returned anything, record `DeathPhase{round}` and hand the Death Events to the same `react` you wrote in Module 2. A Deathrattle is a trigger whose condition is "the Death Event is mine". The dead minion is no longer in play, so `react` must also consider the dead minion itself as a listener for its own Death Event.
- **Loop:** after the Death Phase, run the step again. Stop when it returns nothing.
-- **Position:** an effect needs to know where to summon. Pass the remembered position along with the trigger (in the reference it's a field of the effect's context), and give the summon action an optional board index.
+- **Position:** an effect needs to know where to summon. When a Deathrattle starts to resolve, turn the remembered neighbour into a board index *then*, not earlier, and pass it along with the trigger (in the reference it's a field of the effect's context). Give the summon action an optional board index.
Discussion
+
+Every pass needs at least one death, and a death removes a minion. The only way minions come back is a summon, and the only card that summons is Harvest Golem, whose token has no Deathrattle. So count the pair (Harvest Golems in play, minions in play) and compare pairs left to right. A pass in which a Golem dies lowers the first number. A pass in which no Golem dies summons nothing, so it lowers the second. The pair can't fall forever, so the loop ends.
+
+That argument is about the *card set*, not the engine. Break it with one card: Test Ember, a 1/0 with "Deathrattle: Summon a Test Ember." It arrives mortally wounded, dies in the next Death Creation Step, and summons its replacement, every round, with nothing else on the board. Your engine will loop until something external stops it.
+
+So termination is a property the designers of a card set have to maintain, or the engine has to enforce. Magic: The Gathering does the second, as a rule of the game: 104.4b, "If a game ... somehow enters a 'loop' of mandatory actions, repeating a sequence of events with no way to stop, the game is a draw." ([Comprehensive Rules](https://magic.wizards.com/en/rules)). The course's sources don't say what Hearthstone does. The cheapest engine-side guard is a cap on `round` that fails loudly; a failure with a message is better than a hang, and far better than a silent cut-off that makes one game in a million resolve differently.
+
+Discussion
+
+It depends on how you remember positions, and the experiment is worth running for that reason.
+
+If you remember a board index, `test_03_summon_position_after_simultaneous_deaths` fails in the *other* direction from Predict question 5, or passes by accident, depending on the order of the two dead minions. Indexes read during a removal loop are indexes into a list that is changing under you.
+
+If you remember the surviving right-hand neighbour, the result depends on what "surviving" means halfway through the loop. The reference asks "is that minion doomed?", a question about marks, which has the same answer before and after any removal. So the one-at-a-time version gives the same result. That is not luck. The step is simultaneous *because every decision in it reads only the marks*, and the marks don't change during the step. "Decide from a snapshot, then apply" is the pattern; "do everything first, then everything else" is one way to get it, and reading only data that the loop doesn't change is another. Module 8 and Module 9 lean on the same idea.
+
+Discussion
+
+Twisting Nether would kill the Acolyte too, so use damage: bring each Ghoul to 1 Health first (three earlier Sequences), then cast Whirlwind. One Death Creation Step removes all three; Death Phase 1 resolves three Deathrattles, each dealing 1 to all minions. The Acolyte takes 1 from Whirlwind and 3 from the Ghouls and draws four cards in all.
+
+With 4 Health (the course's card, and today's) it is at 0 after the third Ghoul and leaves in the next step: one more Death Creation Step, an empty Death Phase 2 (no Deathrattle), and the loop ends. Counting Whirlwind's damage, a 3-Health Acolyte was already at 0 after the *second* Ghoul, and still drew for the third: mortally wounded minions keep triggering. The rulebook's "draws three cards" counts only the Ghouls' damage. Writing an example out as a test, with every number in it, is how you find out which of its numbers the example was actually about.
+
+Discussion
+
+Two in case A, one in case B. Both minions leave in the same Death Creation Step and both Deathrattles sit in one locked Queue, in order of play. In A the Herald's resolves first and summons Baron; a summon runs an Aura Update, so when the Hoarder's entry *starts*, Baron is in the snapshot and it activates twice. In B the Hoarder's entry starts before any Baron exists.
+
+This is the rulebook passage quoted under Build: a multiplier summoned by one Deathrattle doesn't help that Deathrattle, "But Deathrattles/End of turn effects that follow can benefit, for Aura (Other) is updated when you summon them." The reference has behaved this way since this module and no Module 4 test checks it, because no Module 4 card summons a multiplier. Module 5 adds the test (`test_05_summoned_multiplier_counts_for_later_entries`) once a card can be written as data inside a test.
+
+Note what decides the answer: order of play, again. The same six words of card text, the same spell, and the draw count depends on which minion was played first.
+
+Discussion
+
+They all pass. In the reference, the same change breaks no test in Modules 1 to 9.
+
+The snapshot differs from a live scan only when a multiplier's presence on the board changes *between* Aura Updates. In this engine minions leave play only in the Death Creation Step, which is followed at once by an update, and a summon runs an update too. That leaves one gap: a minion that is **played**. Its aura isn't in the snapshot until the outermost Phase ends, and a live scan would see it at once. So the two engines differ only if something asks "how many times?" between the play and the end of the Phase, about a trigger the new minion multiplies. That something is the played minion's own Battlecry.
+
+Module 4 has no card with both a Battlecry and a Battlecry multiplier, so the difference is invisible here. Module 5 can write one as data, and its `test_05_own_aura_misses_own_battlecry` does: "Battlecry: Draw a card. Your Battlecries trigger twice." draws one card under the snapshot and two under a live scan. The real game sides with the snapshot: "The double Battlecry effect will only take place if Brann was already present on the board." ([Brann Bronzebeard](https://hearthstone.wiki.gg/wiki/Brann_Bronzebeard)).
+
+The method matters more than the card. You changed a design decision, the tests stayed green, and that told you the tests didn't pin the decision. Then you worked out the smallest scenario that tells the two designs apart. That is **mutation testing** done by hand, and [Module 11](../11-break-your-engine/lesson.md) does it to the whole course.
+
+Discussion
+
+There are three, and any one would be enough:
+
+- **Deferred death** (Module 3). "Destroy" only marks Brann. He is on the board until the Death Creation Step, after the whole Battlecry entry has finished.
+- **The snapshot.** Even if Brann left the board at once, the list of auras in force isn't recomputed until an Aura Update.
+- **The count is read once.** `activations` is asked when the queue entry starts, and the loop runs that many times whatever happens to the snapshot meanwhile.
+
+Three mechanisms guarding one behaviour means none of them is tested by it. Question 2 found the same thing from the other side. When you want a test to pin *one* decision, build the scenario in which the other safeguards don't apply.
+
+Discussion
+
+`max + extra` is order-independent because it never applies one aura *to the result of* another. It folds all the `max` values with `max` and all the extras with `+`, each of which gives the same answer in any order, and combines the two totals once at the end.
+
+`multiply` breaks that unless you decide where it sits. With one additive +1 and one ×3 you can get (1 + 1) × 3 = 6 or 1 × 3 + 1 = 4. The fix is the same move again: don't let the order of the *auras* matter; fix the order of the *kinds*. "All max, then all additive, then all multiply" is a three-entry list, written once. That list is a tiny version of Magic's rule 613, quoted in Name it: continuous effects are "applied in a series of layers", and only inside a layer does a timestamp break ties.
+
+The reference's choice (`max + extra`) is itself only one of the defensible ones. "Additive extras, then at least the base" (`max(base, 1 + extra)`) is another, and it gives 3 for Baron plus two Chorus. No source decides between them, since Test Chorus is the course's card. What a design must not do is leave the choice to the order of a loop.
+
+Discussion
+
+- **Top:** `[] + [effect: draw]`. A minion whose whole text is "Draw a card." with no trigger in front of it. In the reference the clause compiles into the "effects before any trigger" list, which only a spell ever runs. The card does nothing, ever, and nothing reports that.
+- **Bottom:** `[trigger: deathrattle] + [aura: Deathrattles ×2]`. It reads "Deathrattle: Your minions trigger their Deathrattles twice." In the reference the trigger gets no effects, so on death the log shows a `Triggered(deathrattle)` followed by nothing; and the aura is in force the whole time the minion is in play, exactly like Baron's, because an aura clause isn't attached to the trigger before it.
+
+Neither result is what the text says to a player, and `assemble` accepted both. The function is closed over *lists of clauses*, but a card's text has a grammar (an effect belongs to a trigger; a trigger needs an effect; an aura stands alone), and cutting two well-formed texts in half and swapping can leave that grammar. `text == base.text` is the only check, and it is about a different question.
+
+A design has three honest ways out:
+
+- **Curate the pool**, so that every pair of halves fits. This is what the real game does: the base comes from minions "whose effects can be split in half" ([Assemble](https://hearthstone.wiki.gg/wiki/Assemble), paraphrased in Observe). Curation is data, and it costs designer time per card.
+- **Check the result.** Write `wellFormed(text)` and have the `assemble` effect offer only donors and halves whose result passes. The rule lives in one function, next to the must-change rule. Alexis King's [*Parse, don't validate*](https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) argues for going one step further: make the compiled form unable to represent a trigger without effects, so the check can't be skipped.
+- **Give every list a meaning.** Decide that an aura after a trigger is granted when the trigger fires, and that a bare effect on a minion is a Battlecry. Now nothing is ill-formed, and you have designed several new mechanics by accident.
+
+The course takes none of them: its pool is small and its tests only assemble pairs that fit. Write `wellFormed` for the course's four clause kinds; it is about ten lines. Then count how many of the base × donor × half combinations in `cards/` it rejects.
+
+Discussion
+
+A dozen cases cover the course: one phrase per trigger ("Deathrattle:", "Whenever this minion takes damage,"), one per effect, one per target, and the joining punctuation. The test is a loop over the catalog.
+
+It is worth doing for what it proves. The card file is now the single source of both what the card *does* and what it *says*, so the two can't drift apart. And Assemble gets its rules text for free: render the assembled clause list. In the real game the assembled minion's "text changes"; with behaviour as data, that is the same operation as changing what it does. Try `render` on the two cards from question 1. A renderer that can't produce a sensible sentence is a second detector for ill-formed text.
+
+You will find cards where the catalog's sentence and your rendering can't match word for word (Harvest Golem's "Summon a 2/1 Damaged Golem." needs the token's stats). Decide whether `render` looks the token up or the test allows a difference, and note which. That is the gap Argentum's "inspectable AST nodes" in Further reading are there to close.
+
+Discussion
+
+The same log, provided you also recorded the *inputs*: every harness call that started a Sequence, in order, with its arguments. Inputs plus choices is everything that enters the engine from outside. Everything else is computed. That makes a game **replayable** from a short list, and it is why the chooser was worth the trouble: one port for nondeterminism instead of a `random()` call wherever a card needed one.
+
+Two things break replay, and both are worth trying. Iterating over an unordered map somewhere in the engine (TypeScript objects keep insertion order; a Rust `HashMap` does not, so on the Rust track this can bite) and ids that depend on something outside the game. If your replayed log differs, the first differing event points at the place.
+
+Replay is the foundation for three things the course doesn't build: saving a game as its inputs, undo by replaying all but the last input, and reproducing a bug report exactly. Robert Nystrom's [*Command*](https://gameprogrammingpatterns.com/command.html) chapter makes the same observation about recorded input: "We can take the player's input, push it over the network to another machine, and then replay it." [Module 11](../11-break-your-engine/lesson.md) uses replay to build a solver.
+
+