Demo type · 03

Code review of a pull request

Use this when you want to walk someone through a real change — what moved and why it matters — using colored diff lines, risk badges, and reviewer notes pinned to the exact line they're about.

This is a copyable exemplar. Lift the review widget below (the .pr block + its script) into a lesson built from assets/lesson-template.html — keep the design tokens and the Simple → Technical pattern.

1

What you're looking at

A pull request is a proposal: "here's a change I'd like to merge into the shared code." Reviewing it means reading the change line by line and deciding whether it's safe to accept.

The change below adds a rate limit to the login page — a cap of 5 tries per minute per address — so an attacker can't guess thousands of passwords. Green lines are added, red lines are removed. The pills along the top are risk badges — a quick read of which way each property moved. The clay dots are reviewer notes pinned to a line; click a dotted line to read one.

Think of it like… marking up a colleague's draft. You strike through a sentence (red), write a better one in the margin (green), and leave sticky notes — "this could break for repeat visitors" — stuck to the exact line you mean.

How a reviewer reads this diff

The hunk header @@ -14,6 +14,11 @@ means: starting at line 14, the old file had 6 lines, the new file has 11. A unified diff shows context lines (unchanged), - deletions, and + additions interleaved so you can see intent, not just the result.

Risk badges are the reviewer's one-glance summary of direction of change: security posture improves (a brute-force vector closes), tail latency is roughly flat (one in-memory counter lookup), and a new failure mode appears (legitimate users behind a shared NAT can be throttled together). None of that is in the diff text — it's the judgment a review adds on top.

Notes carry a severity: blocking must be resolved before merge, nit is optional polish, praise reinforces a good pattern. Anchoring a note to a line number keeps the conversation precise as the branch evolves.

2

The review

The real change, annotated. Click any line with a clay dot to open the reviewer's note.

OPEN  #482 · opened by p.mendes · branch fix/login-rate-limit → main
Add rate limiting to the login endpoint

Caps password attempts at 5 / minute per IP on POST /auth/login to blunt credential-stuffing. 1 file changed · +9 −2

Securitybrute-force vector closed Latency~ flat (in-memory) Failure modesshared-NAT lockout risk Attack surfaceguess rate throttled 99%
src/routes/auth.ts+9−2
@@ -11,9 +11,16 @@ router.post('/auth/login', async (req, res) => {
1111 const { email, password } = req.body;
13+ const hits = await limiter.incr(key, { windowSec: 60 });
15+ return res.status(429).json({ error: 'too_many_attempts' });
16+ }
1217 const user = await db.users.findByEmail(email);
18+ const ok = user && await verify(password, user.hash);
19+ if (!ok) return res.status(401).json({ error: 'bad_credentials' });
1520 return res.json({ token: sign(user.id) });
0 / 4 notes open Approve with changes

Each clay-dotted line carries a note. 1 is blocking and must be fixed before merge — see if you can find it.

3

How a note becomes a badge

Each badge along the top isn't decoration — it's the sum of what the reviewer found in the lines. Read this left to right: a line raises a concern, the reviewer judges its direction, and that judgment rolls up into one badge.

DIFF LINE + if (hits > 5) return 429 caps guesses per IP + limiter.incr(key, 60s) one in-memory lookup key = login:${req.ip} shared NAT → group lockout JUDGMENT helps? ROLLS UP TO ▲ Security ≈ Latency ▲ Failure modes
Read left → right: a diff line raises a concern, the reviewer judges its direction, and the judgment rolls up into one badge.
4

Make it your own

To teach a different change, keep the structure and swap the content: