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.
1.1 KiB
Categories are content, not configuration
Sections moved out of config/<site>.site.json and into the data directory as data/sections.json, managed from the admin: add, rename, reorder and remove. The config's Section list is now only the seed for a Site that has never been opened, which keeps a fresh deployment useful without making a redeploy the price of adding a category. This supersedes ADR 0005.
Two rules make the change safe to live with. A Section's slug is fixed once created — the label can change at any time, but the web address cannot, because it is what a table card or a printed QR code points at. And a Section cannot be removed while it still holds menus, so a category cannot silently orphan or delete content; the admin says how many sets are in the way.
Considered Options: keeping Sections in the config and adding an admin that edits the file (rejected: the config is mounted read-only into the container, and every change would still need a redeploy); storing them in the manifests (rejected: a Section exists before it has any Menu Set, so it needs a home of its own).