Release v0.12.0 — Review Threads on Diffs, Share-Link Fix, Stale-Asset Hardening

2026-08-10

August 10, 2026

A change you can't discuss is a change you can't act on. v0.12.0 turns the Diff History page into a collaborative review surface: comment threads on any change event, replies, @mentions, and resolution — GitHub-PR style, but aimed at website content changes. It also fixes a bug where shared diff links pointed at an unmapped page and hardens the deployment pipeline against stale-asset errors once and for all.

Review Threads on Diffs

Every change in the Diff History timeline — usually sitting next to an AI summary and a side-by-side content snapshot — can now carry a review thread.

Comment on any change event from the diff modal. This is the natural place: the snapshot is right there, so you're anchored to the actual content that changed.
Reply in threads, with the full thread visible inline, oldest to newest.
@mention teammates to pull them in. Mentions resolve against your organization's member list (name + role in a quick-pick dropdown), are stored explicitly on the comment, and render as highlighted chips in the thread — the foundation for future in-app notification.
Resolve and reopen threads. Resolve a thread once the change is reviewed and dealt with; the thread collapses into a quiet "Resolved" state so the open discussion is always the signal.

Shared diffs get the same threads read-only: anyone with a public diff link can follow the discussion, and sees it with a "Sign in to join the discussion" prompt. Review context now travels with the link instead of living in a private tab somewhere.

The backend features an org-scoped commenting system with tenant isolation and token-scoped public read endpoints, fully integrating with existing authentication machinery.

Share-Link Fix

The previous release shipped single-diff share links, but the generated URL pointed at an unmapped route. Every link resulted in an error. The share endpoint now returns the public diff route that actually renders the shared diff, so the feature works end to end.

Stale-Asset Hardening

Even after recent cache work, browser error logs occasionally showed 404 errors for assets from a previous build served to tabs that were open across a deployment. The stale asset issue is a race: an open tab requests an asset that only existed in the previous bundle after that bundle's cache was purged.

This release attacks every link in that chain:

Best-effort service-worker install. One missing asset no longer aborts the whole install and strands users on the previous build worker.
Always purge, always notify. Every versioned cache is removed on activation and open tabs are instructed to reload.
Graceful asset fallback. If a hashed asset fails to load, cached copies are used before falling back to the application entry.
Controller-change backstop. The layout reloads when a freshly activated worker takes over, preventing outdated tabs from requesting deprecated bundles.
Correct caching headers. Service worker scripts are served with appropriate no-cache headers, and static manifests are configured with proper expiration directives.

Changelog & Blog Housekeeping

The in-app changelog and blog documentation have been synchronized with the latest release, registering all posts in a unified index registry.

Get Started

Open the Diff History page, pick any change, and start the first review thread on a competitor's new pricing page with a @mention for the person who should look at it. As always: sign up free, no credit card.