explaining-code-changeslisted

# Explaining Code Changes ## Workflow 1. Identify the change target: diff, commit range, branch, or PR. If the target is ambiguous, ask one clarifying question before generating the file. 2. Inspect the diff and read enough surrounding code to understand the relevant system behavior. Prefer source files, tests, schemas, routes, and UI entry points over generated or vendored files. 3. Build the explanation spine: - what existed before - what changed - why the change matters - how data or control flows through the system - which assumptions, invariants, edge cases, or tests are affected 4. Create one self-contained HTML file at `/tmp/YYYY-MM-DD-explanation-<slug>.html` unless the user specifies another path. 5. Validate the saved file before responding. If validation fails, fix the file and rerun the relevant checks. 6. Respond with only the file path and a brief summary of what it explains. ## HTML structure Use one long responsive page with inline CSS and JavaScript. Include: 1. **Title and table of contents**: Link to each major section. 2. **Background**: Explain the relevant existing system. Start broad enough for newcomers, then narrow to the pieces needed for this change. 3. **Intuition**: Explain the core idea with concrete toy data, examples, and diagrams before detailed code. 4. **Code walkthrough**: Group changes by concept or execution path, not by raw file order. Connect each code detail to the behavior or design idea it supports. 5. **Self-chec