fix: final review findings

Co-Authored-By: Claude Opus 5.5 <[email protected]>

course/00-setup.md

@@ -189,6 +189,8 @@ cd fsharp
 ./test.sh                          # everything
 ```
 
+If `scala-cli` prints a hint that the munit dependency is outdated, ignore it: the course pins munit on purpose, for reproducibility.
+
 Try it now with Module 0, which has a few sanity tests that already pass. They check that your toolchain works and that the fixtures folder can be read. If you see three green tests (Scala and F#: a short summary with no failures), you are set up.
 
 ### What a red test means

course/06-rendering-as-data.md

@@ -195,7 +195,7 @@ Our `view : GameState → Scene` is exactly this, for a canvas instead of HTML.
 
 ## Exercises
 
-> **About test names.** The test titles quoted under "Proved by" are the JavaScript ones. The Scala and F# suites test the same things one-to-one, but their titles use each track's vocabulary: "events" instead of "inputs", `None` instead of `null`, `()` instead of `undefined`, `bind`/`choose` instead of `flatMap`/`filterMap`, `IO.map throwingF io` instead of `map(io, throwingF)`, and so on. Failing tests are reported by name when you run the module's tests; to read all titles, open `scala/test/M06View.test.scala` or `fsharp/tests/M06View.fs`. Fixture-based tests have the same case names in every track.
+> **About test names.** The test titles quoted under "Proved by" are the JavaScript ones, which carry an `m06` prefix (e.g. `m06 CELL is 20 pixels`). The Scala and F# suites test the same things one-to-one, without that prefix: `CELL is 20 pixels` is identical, and the fixture-driven cases appear as `view: <case name>` with the same case names in every track. Failing tests are reported by name when you run the module's tests; to read all titles, open `scala/test/M06View.test.scala` or `fsharp/tests/M06View.fs`.
 
 ### Exercise 6.1 — `view`
 

course/09-wiring-it-together.md

@@ -229,11 +229,11 @@ Remember section 12 of Module 7: the loop only helps if each continuation does a
 That's the whole runtime. Go back to the stateful code at the start of Module 8, with its `let state` and logic in callbacks, and compare. There, the mutable variable held the *game state*, and game logic lived in the callbacks. Here, the variable holds the *current stream* — the runtime doesn't even know there's a game. It has no idea what a snake, a tick or a score is. All the game logic is in pure values; the runtime is a few lines of plumbing. That is what "pushing effects to the edge" means in practice.
 
 ```
-                 ┌──────────────────────── runtime (impure, ~20 lines) ─────────────────────────┐
- browser ──key──▶│ feed(KeyDown key):  [ios, next] = stream.step(ev); stream = next; ios.forEach(runIO) │──▶ canvas
-         ──time─▶│ feed(Time t)                                                                  │
-                 └───────────────────────────────────────────────────────────────────────────────┘
-                                  ▲ the one `let` / `var` / ref cell: stream
+                 ┌────────────────────────────── runtime (impure, ~20 lines) ─────────────────────────────────┐
+ browser ──key──▶│ feed(KeyDown key):  [ios, next] = stream.step(ev); stream = next; ios.forEach(runIO)       │
+         ──time─▶│ feed(Time t)                                                                               │
+                 └────────────────────────────────────────────────────────────────────────────────────────────┘
+                 ▲ the one `let` / `var` / ref cell: stream
 ```
 
 The tests describe the behaviour precisely; read them before writing the code: