tanshu
32eeed144f
Three things that needed a rebuild and a redeploy, or had no way in at all, now have a Site identity panel in the admin: the restaurant's name and tagline, an SVG icon upload, and a switch for whether a menu says when it was published. They live in data/site.json and data/brand/icon.svg, extending ADR 0007: what the owner changes is content, and the config is the seed plus the theme, which still needs a rebuild. An uploaded SVG is a document that would run with this origin's authority, so it is reduced to shapes on the way in and served with default-src 'none'. The archive list keeps its dates even when the switch is off, because those dates are how one old menu is told from another. Also fixes the live check's own trap: the app caches identity in memory, so the tests drive it through the app rather than a second store instance, which would be a second writer.
926 B
The restaurant's name, tagline and icon are content
Changing the name of the restaurant used to mean editing config/<site>.site.json, rebuilding the image and redeploying. The name, tagline, icon and the switch for showing published dates now live in data/site.json and are edited in the admin, extending ADR 0007's split: what the owner changes is content, and the config is only the seed plus the things that need a rebuild (the theme).
Consequences: an uploaded SVG is served from this origin, so it is reduced to shapes on the way in (no script, no event handlers, no remote references) and served with default-src 'none'; the icon's URL is fixed at /brand/icon.svg so replacing it does not invalidate anything cached elsewhere. Because the app holds the identity in memory, a hand-edit of data/site.json on the server is not picked up until the container restarts — the admin is the supported way in.