Variant B of the prototype (/prototype/menu-design branch): each category is a
card whose face is the first page of that menu, so the landing is built from the
restaurant's own paper instead of labels on a dark page. The row scrolls and
snaps on a phone and wraps into a grid on a desktop; the cards are drawn from
the existing tokens, not the prototype's hexes. The bar's links become filled
segments, the current one the only teal thing on screen.
Fixes the scroller's first card being clipped: a negative-margin full bleed was
fighting scroll-snap, so the row now insets its first card and snaps to the same
inset.
Categories were baked into config/<site>.site.json, so adding one meant a
rebuild and a redeploy. They are now data: data/sections.json, seeded from the
config the first time, and managed in the admin (add, rename, reorder, remove).
A category's web address is fixed when it is created because that is what a QR
code points at, and a category cannot be removed while it still holds menus.
The landing and the top bar were the ugliest parts. The landing was a column of
hairlines with tiny meta — a broadsheet, and the paper that makes this app worth
looking at was nowhere on it. It is now a shelf: each category is a row whose
right edge is a sliver of that menu's first page, bleeding off the screen, with
the shelf edge in brass and the name in heavy tight Archivo. The bar was a row
of teal pills that would not survive more categories: it now names the menu you
are reading and opens a sheet listing the rest, each with its own paper sliver,
and the current one is the only teal thing on screen. The sheet is a link to the
landing page, so navigating still works without the script.
Also fixes the category manager's own layout, which I shipped unstyled, and the
markup contract the route tests described.
Two defects, both found by driving the real editor in Firefox:
1. The editor drew grab handles with a grab cursor on sets it refuses to
reorder, so the live Food menu looked draggable and did nothing. Handles and
the move buttons are now rendered only when reordering is possible, and the
notice says what can still be done.
2. Reordering was saved only from dragend. Browsers suppress mouse events during
a drag and dragend is not guaranteed to arrive, which left the rows visibly
reordered while the server kept the old order — the drag looked like it
worked and then reverted on reload. The order now commits from dragover after
a pause in the drag, with drop/dragend/mouse events as faster paths, deduped
against the last confirmed order and reported in the page.
To make (1) coherent the Current set may now be reordered while its Pages stay
fixed: order is presentation, media URLs are content-hashed and pages are
rendered per request, so nothing stale can be served (ADR 0006). Archives stay
frozen. Admin pages are no-store and assets cache for 5 minutes, so a fix like
this one is not masked by a stale admin.js.
scripts/check-dnd.mjs drives the real editor and asserts the drag persists; it
is the only automated check that reaches this path.
The playbook pulls the tag from the registry, creates the data root owned by the
app user, runs the container with its config baked into the image, waits for
health, then verifies the data directory as the app user so a permissions
mistake surfaces at deploy time. Caddy is pointed at the app with a stable
marker, so a temporary hostname can be checked beside the live site and the
cutover is one invocation with the retire flags set.
The store keeps a Menu Set's state in the directory layout (drafts/ versus
published/) and its metadata in a manifest, with publishing as a single
directory rename. Editing is allowed on Drafts only, so a published menu can
never change under a customer. Stages 2 and 3 of docs/plan.md, with tests.
tanshu