feat(review): review the captures in ozalid rather than a local report

[haribo]

Summary

The journeys' captures now go to ozalid, where the user reviews them. The local HTML report and its reviews.json are removed — 392 lines that generated a page nobody could act on, and whose verdict file was still empty.

just e2e            → runs the journeys
just ozalid-dry     → says what would be sent, writes nothing
just ozalid-push    → sends it
   (review in the browser)
then                → commit, pull request, merge

Local, and before the pull request. A capture that reaches CI is a capture nobody looked at while there was still time to change what it shows. CI keeps running the journeys — it checks that they pass, not what they look like.

What changed is not computed here

Every capture is hashed; ozalid is asked which addresses it does not hold; what it does not hold is what changed. Content addressing answers the question, so nothing here compares images. A capture ozalid already holds is never sent twice.

A first push sent 49 distinct captures for 59 cells: the same screen rendered identically in two variants is stored once and judged twice.

The case map is committed

tools/ozalid/cases.json holds which ozalid case each journey is. ozalid generates a case's id and says the client stores it and never invents one; matching on the title instead would open a second case the day somebody rewords a test — silently, leaving the history on the old one. The map makes a rename visible in review, where it is fixed by editing one line.

The push warns when the map holds a case the run did not produce, which is what a rename looks like from here.

Structure on the server

Categories follow the design documents rather than the test files, so the path from a screen to the rule that governs it is the same in both directions:

Installation / First run          2 cases
Back office  / Access             1
             / Frame              1
             / Catalogue          1

No empty category. A branch with no case promises a journey that does not exist — the opposite fault to the catch-all it replaces. The twenty other branches the v1 scope implies are written down in the issue, and each will be created with its first case.

Axes are viewport then theme, ordered so a variant reads desktop·light — the name it already has here. ozalid creates axes by first use and ships no list of its own.

Not done, on purpose

• The push is not wired into just e2e. A failed experiment would land in the book alongside the real thing.
• CI pushes nothing. That would need a service token in GitHub secrets, and it would arrive too late anyway.

Test plan

• just frontend-check — typecheck, lint, theme tokens, type scale
• just frontend-test — 190 tests
• just e2e — desktop-light 4, desktop-dark 4, mobile-light 5, and it now ends without building a report
• just ozalid-dry after the push — 0 cases to open, 0 captures to send, which is the change detection working
• No orphaned reference to the removed report — grep over docs and the justfile
• The token appears nowhere in the branch history nor in any tracked file; .env.example carries an empty placeholder

Backend untouched, so backend-check, backend-test and api-check do not apply.

One commit rather than the three I first proposed: the justfile carries both the addition and the removal, and the documentation describes exactly this change. Splitting them would have produced states where the code and the docs disagree.