Blog

Every project has the same crew manifest: a designer shaping the pattern set, an engineer wiring data and blocks, and the site editors who will actually fly the thing after handover.

The editor role is the one we design for hardest. If a page cannot be built, rearranged, and rebranded from the editor alone, we treat that as a defect — the editor-equals-frontend rule exists for exactly this reason.

This demo site is the proof: everything on it was assembled from patterns an editor can reach.

A release starts as a version bump and a tag. From there it moves through a fixed sequence: build, publish, portal registration, and finally the native update flow on every install that qualifies.

Release candidates go to non-production installs only; a clean tag goes everywhere. That split is the whole safety model — the demo and lab environments you are reading this on are always first in line.

When the countdown reaches zero, nothing dramatic happens. That is the point.

Every install in the fleet phones home with a heartbeat: theme version, core compatibility, and a bundle of health signals. Individually those numbers are noise. Together they are the earliest warning system we have.

The trick is knowing which curves matter. A single failed check after an update is a blip; the same check failing across a fleet segment is a rollout problem. This post walks through the three panels we watch first.

The takeaway: telemetry is not about dashboards, it is about defaults. If the signal is good, nobody should have to look at it at all.