Run the regression pack on every release, and compare it to the last one

Upload a sheet and the same journey runs once per row, each with its own full evidence. Accepting and rejecting rows are generated together, so a limit is exercised on both sides of its edge rather than only where it works.

=today-25y is stored as an expression rather than a date, so a row that sits on a boundary today still sits on it next month. A literal date would quietly stop testing the boundary.

A real regression pack is not a list of independent cases: it signs in once, then walks through a policy, a quote, a document. Later cases keep the same browser session, so the pack reads the way a tester works. Step 1 below is that, in a real run.

Steps 3 and 4 read values out of the page into variables, and step 5 asserts one against what was recorded earlier — which is how a suite checks continuity rather than just absence of errors. Both are runs against our own test fixtures, so the URLs are local and the titles say “Fixture”. The statuses, strategies and wording are exactly as the engine wrote them.

A count of passes tells you almost nothing on a regression pack — it was passing last time too. These are the verdicts the screen renders, in its own words.

The last one is why this page exists. A rule that has stopped being enforced does not fail a test — the flow completes, and a pass/fail count calls it green. It is only visible if something knew the row was supposed to be stopped.

What makes two runs comparable at all

• —The suite carries a content hash, so a change in the tests is distinguishable from a change in the verdict.
• —Each step compiles the same way every time, so a difference between runs is a difference in the application.
• —Every resolved element records the strategy that found it, so a step that started resolving differently is visible.