Changelog releases are published without reaching readers

Releases are being published, but readers are not being told about them.

What we found. Eleven changelog entries have been published since 2026-08-20. In that same window the portal created zero in-app notifications of any kind. The only changelog notifications it has ever created are two, both dated 2026-08-20.

Why it went unnoticed. Each entry records a timestamp saying it was notified, and that timestamp is being set correctly and promptly — on the release published tonight it appeared within a second of publishing. So every check that asks was this entry notified? answers yes. Nothing checks whether a notification was actually delivered to anyone, and that is the gap.

Part of the cause is on our side: while back-filling the changelog's history we deliberately suppressed notifications, which is correct for a back-fill — nobody wants eleven months of history arriving as eleven announcements. What we did not do is confirm that a genuine release afterwards still notified. Tonight's release was re-armed and re-published deliberately to test exactly that, and the delivery count stayed at zero.

Not yet known: whether email delivery is affected too, or only the in-app notification. The two are separate paths and only the in-app one can be counted from here.

Why it matters. A changelog nobody is told about is a page people have to remember to visit. The releases most worth announcing — single sign-on, off-site backups, the hardware work — have all shipped inside this window.

This is the first concrete instance of the problem Phase 8.6 exists to solve: notifications are spread across several mechanisms, each configured separately, with no single place that shows whether a message actually reached anyone.