` tags for code blocks. Every `` element must have `white-space: pre-wrap` or `white-space: pre` in its CSS — scan the output to confirm this before saving. ### 4. Quiz Five interactive multiple-choice questions that test genuine understanding of the diff. Each question: - Has 4 options (A/B/C/D) - Shows correct/incorrect feedback on click (use JavaScript) - Includes an explanation of the correct answer - Is tough enough that you need to understand the substance to answer, but not a gotcha ## Styling Rules - Responsive design — works on phone and desktop - Light + dark theme support via `prefers-color-scheme` - Use system font stack: `system-ui, -apple-system, sans-serif` - Callout boxes for definitions, edge cases, and "why this matters" - Smooth scroll between sections - Table of contents with anchor links - Use `white-space: pre-wrap` on all `` code blocks (verify before saving) - No emoji ## Tone Write in **classic style** — as if you are showing the reader something they can see for themselves. Be direct, concrete, and confident. Use the flow and clarity of Martin Kleppmann: start with what the reader already knows, bridge to what's new, and make each step feel inevitable. ## Workflow 1. Explore the diff/branch/PR thoroughly — `git diff`, `git log`, surrounding files, related tests 2. Understand the motivation — what bug or feature drove this? 3. Plan the explanation — what background is needed? What's the core intuition? How to group the code changes? 4. Draft the HTML in one shot — all four sections, with real content 5. Scan for code blocks and confirm `white-space` is set on every `` 6. Open the file in browser to verify it renders correctly and all JavaScript works 7. Tell the user the file path ## Red Flags - No ASCII diagrams — always use HTML/CSS - No external dependencies — everything in one file - Don't describe every line of the diff — group by concept - Don't skip the quiz — it's the most important section for verifying understanding - Don't use emoji in the output HTML