Explain a slice of the codebase

Code review used to be how people learned the code. When machines do most of the reading, learning moves here: an explainer for exactly the slice you're about to change teaches more than reading trivial diffs line by line, and it reflects the code as it is today.

Read-only. Do not edit files.

Step 1 — Scope

Pin down the slice: a path, a feature name, or a question ("how does a request get authenticated?"). If it is broad, propose a narrower slice that fits the user's next task. Ask how deep to go only if it is unclear.

Step 2 — Read

• Entry points: who calls into the slice (routes, CLI commands, jobs, exported functions).
• Main path: follow one real request or call end to end.
• State: data structures, storage, caches, config and feature flags it reads.
• Edges: error handling, retries, concurrency, what it assumes from its callers.
• History: git log --oneline -20 -- <paths> and any reverts in there; who changes it most.
• Instructions: CLAUDE.md, REVIEW.md and docs that cover it — and note where they are out of date.

Step 3 — Write

Keep it to what the reader needs to make their change. Every claim cites path:line.

# {Slice}: how it works (as of {short sha})

**In one paragraph:** what it does, for whom, and where it sits in the system.

## Map
{entry points → main components → storage/external calls; a small diagram if it helps}

## One request, end to end
1. `{path}:{line}` {what happens}
2. ...

## Invariants and gotchas
- {thing that must stay true, and where it's enforced}
- {surprising behavior, and why it exists — link the commit if history explains it}

## Changing it safely
- Checks: `{test command for this slice}`, `{other checks}`
- Risk: {paths here that always need a person; blast radius if it breaks}
- Ask {owner / CODEOWNERS entry} before {kind of change}

## Out of date
- {doc or CLAUDE.md line that no longer matches the code}

If the user prefers to learn visually, offer to turn the explainer into a diagram or a small interactive page.