Twenty-six tests across two viewports, covering what the spec asks for:
changing today's hours reaches the panel, a message survives the
translation service being unavailable, a closure period closes the days
it covers — plus the authorisation paths and the sign-out regression.
They run against the standalone build served the way the container
serves it, not `next start`, which refuses to work with standalone
output anyway. The suite therefore exercises the artifact that ships
rather than a second arrangement that could drift from it.
Sign-in mints the session cookie Auth.js would have issued rather than
driving Authentik. What is under test is the application's behaviour for
a given role; the handshake itself is verified against the live provider
separately, and standing up an identity provider per run would trade a
lot of machinery for coverage of somebody else's code. The secret lives
in one module imported by both the config and the fixtures — when it
differed, every signed-in test failed at once while looking like an
authorisation bug.
Database access goes through plain SQL rather than the Prisma client,
whose generated module format Playwright's loader and Next's bundler
disagree about. That traded one problem for a subtler one: node-postgres
parses a DATE column into a local-midnight Date, so reading it back
shifted the day at UTC+2. Dates are read as text now.
The mobile profile runs on Chromium: WebKit needs system packages only
root can install, and a suite nobody can run locally is a suite nobody
runs. The config says how to switch to the real engine.
Two real defects surfaced, both found by the tests rather than by
reading. The seven "Ouvert" checkboxes on the hours page were
indistinguishable to a screen reader; each now names its day. And on a
phone the signed-in address appeared nowhere at all — the header hides
it to save room — so nobody could tell which account was about to sign
an audit entry on a device the shop shares. It is on the dashboard now.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012cSY9pVhZmJUKNN7wf1Myd
One card per day pushed the week to roughly 1100px, so checking a change
meant scrolling back up past the day you had just edited. All seven days
now fit on one phone screen.
Each row carries the day, an open switch, its slots inline and its two
actions. The per-row "duplicate onto the other open days" button was
repeated five times in prose; it is now a short labelled control on the
row itself, with the full sentence kept as its accessible name.
Unsaved days are marked with a dot rather than a badge, and the footer
still names which days are about to change — the point of the preview is
that it is readable without leaving the week.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012cSY9pVhZmJUKNN7wf1Myd
The first administration page, built for the actual use case: a phone
held in one hand behind the counter. One card per day, native time
inputs so the platform keyboard does the work, and the consequences
shown before the save rather than after — the footer names which days
are about to change, and the button stays disabled until something
actually has.
"Duplicate onto the other open days" leaves closed days closed. Someone
copying Tuesday's hours means "the days I open, I open like this", not
"open seven days a week".
Validation runs in the browser for the feedback and again in the action
before the write: the client is a convenience, not a guarantee, and this
is the schedule the shop window shows. A day being closed drops its
leftover slots rather than failing on them.
A save that changes nothing writes nothing — no rows, no audit entry,
and so no needless panel redraw. Reordering slots does not count as a
change. The audit diff stores one readable line per day in French, so
the log can be read without cross-referencing the schema.
The editing helpers are pure and tested, and the write path is tested
against a real database including the read-only refusal.
Test files now run sequentially: the integration files share one
database and each truncates it, so parallel files raced. The suite takes
six seconds; giving every file its own database would buy nothing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012cSY9pVhZmJUKNN7wf1Myd
vliaudatandClaude Opus 5