Asked whether this could be made deterministic rather than timed. It can, and
should have been from the start.

Every previous attempt gated a CSS animation keyed to element creation, and each
was a timer trying to out-guess DOM churn. The board is built twice on every
load — prerender, then Board.razor's spinner, then the data — so the animation
fires on whichever sets happen to exist. Latching on cascade-end never armed
(the rebuild lands at 311ms, the cascade needs 562ms). Latching on cascade-start
flickered: a sliver of motion on the prerendered set before it was torn down.
A settle window was still a guess. Three releases went out that way.

Timers cannot win here, because what they are racing is the framework's own
render schedule. So ask the framework instead. There is no CSS animation on the
columns any more. Board.razor calls playBoard() from the render where its data
has actually arrived — the same signal it already trusts to decide when its
drag-and-drop interop can safely import — and JS animates exactly the elements
present at that moment, once, with the Web Animations API. Anything built
afterwards cannot animate, because there is no rule left to fire on it.

One subtlety worth the extra argument: Board.razor's "_columns is not null" is
component state, not the DOM. OnInitializedAsync's continuation can land between
the spinner render and its OnAfterRender, so the call sometimes arrives while the
spinner is still on screen and querying for columns finds none — which is why
the first cut of this animated nothing at all, intermittently. It now passes the
count it rendered and JS waits for that many columns. That is a wait on the thing
being animated rather than on a clock, and it is what makes the result identical
at every timing.

Keyframe values live in app.css as custom properties and are read back off :root,
so the stylesheet stays the source of truth rather than the timings being
duplicated into JS.

Verified at circuit delays of 0, 250 (the production gap), 700 and 1500ms: every
one starts exactly as many animations as there are columns and finishes all of
them — no doubles, and nothing cancelled mid-flight, which is the flicker. Past
the safety reveal (a guard for a board that never renders at all, not a timing
heuristic) the entrance is forfeited rather than played over content already on
screen. Three consecutive full runs, no flakes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

@@ -124,0 +172,4 @@
+        var look = function () {
+            if (!played) return;
+            var columns = document.querySelectorAll('.board > .column');
+            if (columns.length >= expected) { then(columns); return; }

@@ -105,2 +77,2 @@
-    // admin page. Routes.razor cannot help — those navigations reuse the
-    // circuit, so its first render happened long ago.
+    // Switching between Sign in and Create account is the one replay the design
+    // does want. Routes.razor cannot help here — that navigation reuses the

@@ -124,0 +184,4 @@
+
+    // Board.razor tells us how many columns it just rendered. That matters
+    // because its own guard ("_columns is not null") is component state, not the
+    // DOM: OnInitializedAsync's continuation can land between the spinner render

@@ -130,4 +283,3 @@
             return result;
         };
     });
-    window.addEventListener('popstate', routeChanged);