Making the weekly digest worth opening

01The week at a glance

A digest explains why each release matters, but it's a lot to read when you just want the highlights. When you open the Coding Agents digest, you want to know two things first:

• Who shipped the most this week?
• Which releases should I read about?

The card answers both before the first paragraph. On top is a treemap with one tile per product. The size of a tile shows how much that product shipped. Colored columns in each tile split its work into features, enhancements and fixes. A flame on a tile marks each release we score as major or landmark.

Under the treemap is a list of the five biggest releases. Each row links to the part of the digest that talks about it. Click a tile, and the list shows only that product's releases.

The first real choice was which releases the card should count. A collection can have releases that the digest doesn't mention, usually small patches. We could count every release from the week, or only the ones the digest covers.

We chose the covered ones. The card is a summary of the digest you are reading. Every tile and every row links into the digest text, and a release the digest skips would have nowhere to link to.

This has a cost. In a week where the digest leaves out a lot of small activity, the card counts less than really shipped. If that becomes a problem, the fix belongs where the digest is written, so the digest covers more. The card should never disagree with the text under it.

The card also knows when to stay out of the way. With fewer than three releases in a week, the text is enough, so the card doesn't appear. If only one product shipped, a single tile says nothing, so the card shows only the list.

02What counts as impact

The first idea for tile size is the number of releases, and it gives the wrong answer. In the week shown above, Claude Code had six releases and Codex had four. But about two-thirds of Claude Code's work was fixes, and Codex launched a new default model. A tile sized by count would tell you that Claude Code had the bigger week.

So a tile's size is its impact, which we build from two signals we already store for every release. The first is importance, a score from 1 to 5 given to each release when we index it. A release scored 3, 4 or 5 counts as 2, 3 or 4 points. The second is composition, the count of features, enhancements and fixes inside the release. A feature counts in full, an enhancement counts three quarters, and a fix counts half. A release's points are scaled by that mix. When we don't know the mix, we use a flat 0.6.

Small releases needed one more rule. Some teams tag a release for every patch. If each patch added points on its own, a busy week of small fixes could outweigh one large launch. So a product's minor releases (importance 1 or 2, or not scored) share one pool. The pool grows quickly at first and then levels off. It can never pass 4 points, the value of one landmark release made of features.

The colors carry a choice too. Fixes use a pale red, mixed at 30% strength into the tile's background. At full strength, a tile that is mostly fixes looks like an error. Its red band also draws the eye away from the green features band, which is the work the tile size is meant to reward. At 30% it still matches the red used for fixes elsewhere on the site, so the two read as one system.

All of this lives in one small function with no side effects. It takes the week's releases and returns the tiles and the ranked list. The card only draws what that function returns. That choice paid off in the next part.

03Playing the week back

A finished week has a shape that a static card hides. Some products ship on Monday and go quiet. Others save a large launch for Thursday. The replay shows that shape. It plays the week back day by day, with one lane per product and one mark per release. Beside the lanes, the impact map grows as releases land. A caption names the biggest release of the day so far.

Tuesday

End of the week

The replay ends on the card. Its last frame has the same tiles in the same places and the same five releases. So the replay ends where the digest begins. To get that, the replay doesn't use a second copy of the impact math. At each moment, it runs the same function as the card on the releases shipped so far. At the end, "shipped so far" is the whole week, so the final frame is the card. A test checks that the two are equal. Tiles also keep their final order through the whole replay, so they grow in place and don't swap positions.

A few more decisions set how it feels:

• Days, not hours. Each release belongs to a day, and a day's releases are spaced evenly in the order they were published. Every day takes five seconds, so every week takes 35 seconds. A 1× / 2× switch is the only speed control.The email links to this replay as "the 35-second replay".
• Every frame comes from the clock. Fades, glows and captions are computed from the current time in the replay and each release's slot. Nothing depends on when an animation started. This makes the scrubber exact and the frames easy to test. A video export could step through the frames later.
• Dates without times. Some changelogs publish a date and no time. We store those at midnight UTC. Converted to Eastern time, midnight would move the release to the evening before. So the replay treats an exact midnight as "date only" and keeps the date.
• Reduced motion. If your system asks for less motion, the replay doesn't play by itself. Previous-day and next-day buttons let you step through the week.

You reach the replay from a "Replay the week" link on the card. The link appears only when the card does, so it never points at a week too small to replay.

04One email per reader per week

The card and the replay make the page better, but a reader still has to visit it. The email brings the digest to them. The collection page and each digest page now have an "Email me this digest weekly" toggle. You need an account to use it. On Monday, when the digest for the week that just closed is written, each subscriber gets a short email. It has:

• the digest's intro;
• the five biggest releases;
• a button to read the digest;
• a quiet text link to the 35-second replay.

We first had to decide what subscribing means. Release Notes Index already lets you follow organizations and products, and a follow shapes your feed. We could have let people follow a collection and send email to its followers. We chose a separate subscription instead. A follow keeps one meaning, "show me this in my feed", and email stays something you turn on for each collection. Unsubscribing from one collection's email, with one click, leaves the rest of your settings alone.

Then we had to send each email exactly once. Two things make that harder than it sounds:

• The job that writes digests can also rewrite old weeks or fill in weeks it missed.
• The queue that delivers emails can deliver the same message twice, and a failed step can run again.

The first check is about which weeks send. Only the week that just closed sends email. A catch-up run for a missed week, a forced rewrite of an old digest, or a backfill never emails anyone. Nobody wants a "this week" email about last month.

The second check is the claim. Each subscription row stores the last week it was sent. Before sending, the delivery step moves that week forward, but only if it is still behind:

  const updated = await db
    .update(userCollectionDigestSubs)
    .set({ lastSentWeek: weekStart })
    .where(
      and(
        eq(userCollectionDigestSubs.userId, userId),
        eq(userCollectionDigestSubs.collectionId, collectionId),
        or(
          isNull(userCollectionDigestSubs.lastSentWeek),
          lt(userCollectionDigestSubs.lastSentWeek, weekStart),
        ),
      ),
    )
    .returning({ id: userCollectionDigestSubs.id });
  return updated.length > 0;

The update and the check are one statement, so only one delivery can win. A message delivered twice finds the week already claimed and stops without sending. If the send itself fails, the claim is undone, so the queue's retry can try again.

One trade-off is still open. The email ranks its five releases by importance alone, and keeps ties in the order the digest cites them. It doesn't use the card's impact math, which lives in the web app. For the top five the two orders mostly agree, but they can differ when releases tie on importance. Our plan is to move the impact math into shared code only when another part of the system needs the same numbers.

05On for every new collection

Weekly digests were opt-in for each collection, turned on with a manual database change. They are now on by default for every new collection. A collection can still be turned off through the API.

The default lives in the application, not in the database table. Our database is SQLite, and SQLite can't change a column's default without rebuilding the table. That rebuild would also touch every table that points at collections, including the new subscriptions table. The only code that creates collections goes through the same layer that now supplies the default, so we set it there. Existing collections didn't need a change, because all of them already had digests on.

Your subscriptions also appear on your account's notifications page, where you can turn any of them off. Email goes only to verified addresses. If yours isn't verified, the toggle tells you so and offers to resend the link, so a subscription never fails without a word.

To try it, open any collection's latest digest. Look at the week at a glance, press "Replay the week", and turn on the email if you want next Monday's digest in your inbox.