clock-read-while-rendering

This fails the run. Where it is wrong about your code, // ramonda-check-ignore <reason> on the line says so, and the reason is printed on every run.

Reported when Date.now(), new Date() or Math.random() is reached from a render, by any path.

The framework reports the same fault while running, as RMD021 — but only once the line actually runs. This is the same fault proved from the source instead.

A render has to be a function of state and props, and neither of these is. The same inputs then produce a different answer every pass: the diff sees a change that is not one, a @compute recomputes forever, and a server-rendered page cannot be hydrated — the server's answer and the client's were taken a few hundred milliseconds apart.

That last one is the reason to catch it here. What a reader actually meets is a hydration mismatch, whose advice is to go and find the non-determinism; this names it instead.

Decide the value once and keep it: read the clock in @created and hold it in @state, and mark it @persist so the client restores the server's value rather than taking a new one.

new Date(value) is not reported — parsing a timestamp is deterministic. It is the argument-less new Date() that asks what time it is.

The runtime answers only part of this. RMD021 watches the RANDOM half and deliberately leaves the clock alone — the platform reads the clock behind your back, so a guard on it reports calls the app never made. new Date() is caught by RMD020 as a fresh identity, and Date.now() only when a hydration disagrees (RMD007); in a client-only app nothing catches it at all. That gap is what this rule is for.

Next

• All rules — the other checks this one runs beside.
• Checking your app — how to run it, and what it proves.