Reverts the explicit subnets: the pools were freed by deleting five networks, so
the network role is back to its single idempotent task - ensure the network
exists and Caddy is on it - and the Sites no longer declare a subnet. The
deployment readme keeps the note that a new Site needs a config, and therefore a
new tag, but no longer asks for a free /24.
If the pools fill up again the failure is recognisable: 'all predefined address
pools have been fully subnetted', and the choices are deleting stale networks or
declaring a subnet per Site.
The deploy failed on hngmohali with 'all predefined address pools have been
fully subnetted': every 172.17-172.30/16 is in use, 172.31/16 is the host's own
VPC so Docker will not allocate from it, and all sixteen 192.168.0-240/20 blocks
are taken. Docker therefore refuses a network created without a subnet.
Each Site now names a free network_subnet (10.210.0.0/16, one /24 each), the role
looks the network up first and only creates it when it is absent and with that
subnet, and it fails with an explanation when a Site declares none. Existing
networks are left alone, because Docker cannot change a subnet in place and the
Sites already running have theirs. The test checks every Site declares one, and
the deployment readme says a new Site needs a free subnet.
deploy.sh now deploys every Site by default, with SITE=<name> to narrow it, which
is what the local edit was reaching for.
One image serves every Site, so a new Site is three small files: an inventory
entry, a vars file naming its web address and data root, and a config that seeds
its theme and first category list (baked into the image, which is why a new Site
needs a new tag).
Both reuse the directory their old static menus were served from, and the caddy
role drops the snippet the retired nginx-menu playbook wrote for each hostname,
so a deploy repoints each address at its own container with nothing else to do.
The seeded category lists are a starting point, not a decision: categories, names
and icons are all editable in each Site's own admin. A test now checks the
inventory, config and vars agree for every Site and that no config is orphaned,
because a half-added Site was the obvious way to get this wrong.
The script refused anything under ten characters. That is a policy the owner
should hold, not one the tooling invents; the only rule left is that the password
cannot be empty, since an empty one would let anyone in. Resetting is the same
script with --force, which overwrites the hash and generates a fresh session
secret, signing out anyone who was signed in - now written down in the operating
notes and the deployment readme, including the form that prompts on your own
machine instead of the server.
ssh host bash script gives no terminal, so read -s could neither show the prompt
nor read it, and the script sat there looking frozen. It reads from /dev/tty now
and, when there is no terminal, says so and prints the command that works:
ssh -t <host> bash bash <data-root>. The deployment readme shows the -t form and
uses the real paths.
The script defaulted to menu-admin:latest and refused to run on monoco, where the
image is registry.tanshu.com/menu-admin:<tag>. It now reads the image off the
container the app is already running, deriving the container name the way the
playbook does, and only asks for an explicit image when there is no container to
borrow one from. The failure message names the exact command either way.
podman builds an OCI image by default and drops Docker's HEALTHCHECK instruction,
so the container had no health at all and the play failed waiting for one. The
check is now declared on the docker_container task - node is in the image and the
exec form needs no shell quoting - which is both what operators see in docker ps
and what an orchestrator would use.
The wait still asks the app directly rather than reading State.Health, because a
container that already exists is only rebuilt when the image tag changes or when
-e recreate_container=true is passed, and a wait must not depend on a container
attribute an existing one may not have.
The first real deploy left the site on 502 and this is why. podman builds an OCI
image by default and drops the Docker HEALTHCHECK instruction, so the app
container has no State.Health at all; the role waited on that field, exhausted
its retries and failed the play, so the caddy role never ran and Caddy kept
proxying menu.hopsngrains.com to the old nginx container that is now gone.
The wait now asks the app itself: docker exec node -e fetch /healthz, which needs
no healthcheck and no DNS. And because the address may still be claimed by the
snippet the retired nginx-menu playbook wrote, the caddy role drops that marker
before writing its own - two blocks for one address make Caddy refuse the config,
and a refused reload quietly leaves the old proxy in place.
check-site also asked for the font the old design used, so it would have failed a
healthy site; it checks one we ship.
That was the intent of the uncommitted edit, and it is a better location than a
second directory: the app inherits the place the menus were already served from
and only ever reads and writes its own data/ and site.env inside it.
app_root is written as /var/lib/{{ host }}, quoted, because the unquoted form is
what failed to parse. Every documented path follows, and the deployment readme
now says that emptying the old menu files means deleting those files rather than
the directory, which holds the live content.
The deploy failed on 'YAML parsing failed: missing quotes around a template
block'. vars/hopsngrains.yml had been edited to derive its names from the web
address, but the two derived values were unquoted and YAML reads a leading brace
as a flow mapping, so the file did not parse at all.
The names now derive from a title (the domain) with every interpolation quoted,
which is what nginx-menu did and what makes the file copyable for another Site:
host menu.<title>, container menu-app.<title>, network <container>_net, data
/var/lib/menu-app.<title>. Resolving the vars offline gives exactly the values
the docs promise, including /app/config/hopsngrains.site.json inside the image.
The old edit derived from host, so app_root would have been
/var/lib/menu.hopsngrains.com — the directory the old static menus were served
from.
There is no previous system kept serving, so the playbook no longer knows about
one: the retire flags, the temporary web address, the task that removed the old
nginx snippet and the task that stopped the old container are gone. One run
starts the container and points the Site's web address at it, and deploying an
earlier tag is the rollback. The vars lose vhost, retire_nginx_snippet,
retire_nginx_container and legacy_container; the Caddy role keeps only the
snippet upsert.
The deployment readme drops its staged-rollout sections and the glossary of words
that no longer exist, and the plan's sequence and the operating notes describe
the single run instead.
The deployment readme used three pieces of jargon without defining any of them,
which reads as a locked door to anyone doing their first deploy. It now opens
with what each word means, the table of which address serves what at each stage,
and the note that skipping the parallel run is a legitimate choice.
Domain terms stay in CONTEXT.md; these are operational words for this directory,
so they are defined here.
ESLint cannot parse this project's TypeScript: typescript@7 is the native port
with no JavaScript compiler API, which every ESLint TypeScript parser needs, and
typescript-eslint refuses to install with a >=4.8.4 <6.1.0 peer. oxlint parses
TypeScript without the compiler API, so it lints the .ts and the .js together in
about 20ms over the whole repo, and it runs the correctness category as errors.
It found one real thing on the first run: the drag harness built its fetch
options with a body key even for GET. The four opinionated rules it also flagged
are off with their reasoning in the README, since oxlint's config takes no
comments. lint is back in deploy.sh's checks, and the editor has lint tasks and
the oxc extension recommendation. Prettier is unchanged.
The playbook, its roles, its vars and a new inventory now live in ansible/,
beside the app they deploy, the way the other apps on this machine are laid out.
The inventory follows the same shape: one entry per Site, all on the same box,
each naming its own vars file through var_file, so adding a Site is one line and
a file rather than a command-line flag. ansible_host is written as the
resolvable name rather than an ssh alias so the inventory works on any machine.
The image is now built with podman as a multi-arch manifest and pushed to
registry.tanshu.com/menu-admin, mirroring the Makefile used elsewhere on this
machine: build-production, plus build-check and build-check-local for a build
that does not push. deploy.sh runs the checks, builds, pushes, then runs the
playbook for the Site named by SITE, with SKIP_DEPLOY for a push without a
deploy.
ESLint comes out again: this project's typescript@7 has no JavaScript compiler
API, so typescript-eslint cannot install, and linting only the JavaScript was
not worth keeping. Prettier stays, and the README records why ESLint is absent
and what would bring it back.
Prettier owns formatting: .prettierrc.json, format and format:check scripts, and
a one-off pass over the repo so the check is green from the start. Embedded
language formatting is off deliberately - the renderers build HTML in html
tagged templates and letting Prettier reflow those would change the markup
customers receive. docs/ is excluded because it is hand-wrapped prose, and shell
scripts have no Prettier parser.
ESLint covers the JavaScript: the two browser scripts, the build and check
scripts, and its own config. no-var is scoped out for the browser scripts on
purpose; they are plain ES5-shaped IIFEs and a hoisting difference would only
show up in a browser.
ESLint cannot lint the TypeScript here: typescript@7 is the native port with no
JavaScript compiler API, and typescript-eslint requires a 4.8-6.1 peer, so it
refuses to install and forcing it through would leave a parser that cannot read
the compiler. tsc --noEmit stays the TypeScript gate; README records the two
ways to change that.
lint and format:check now run in deploy.sh, and VS Code formats on save with
Prettier and surfaces ESLint findings.
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.
The document still preloaded the Archivo file the old design used, which is now
gone: a 404 on every page load. It preloads Playfair Display and Plus Jakarta
Sans instead, and the asset test names a font that exists.
Google Stitch produced an Atelier Dining & Hospitality system for this app: warm
ivory linen and espresso for the guest surfaces, burnished gold for the single
active thing, Playfair Display for the restaurant's voice and Plus Jakarta Sans
for everything transactional, editorial rows with dot leaders, pill controls,
hairline containment instead of drop shadows. The four screens and the system
document are kept in docs/design/stitch/ as the source.
Both fonts are now self-hosted with their licences, the guest stylesheet is
rebuilt on the system, and the admin is the same system in its dark mode
(espresso workspace, obsidian pods, gold actions) by overriding the same tokens
at a higher specificity, since the per-Site theme is injected inline after the
stylesheets. The Site theme in config/ moves to the system's palette, which is
where per-Site branding belongs; the old Archivo font is dropped.
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.
The bar hid them behind a switcher and a sheet. It now names every menu that
exists, which is what was asked for; it scrolls sideways when the categories
outgrow the width, and the current one is the only filled item. Without the
script it is simply a row of links, so nothing is lost when JavaScript is off.
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.
npm run dev now runs scripts/dev-env.ts first, which creates .dev/site.env with
a known dev password and a random session secret, so a fresh clone serves a
working admin without anyone hand-building a hash. Adds .vscode launch
configurations and tasks for the dev server, one test file, and check-site, and
brings scripts/ under typecheck, which it had been missing.
A file past the size limit makes the multipart stream itself throw, which
escaped the per-file catch and reached the error handler: the phone that just
sent a 35 MB photo got 'Something went wrong'. Catch the limit errors around the
part loop, say which limit was hit, and report it once rather than twice. Also
asserts that derivatives carry no EXIF while the Original keeps the uploaded
bytes.
The data root belongs to the app's uid, so the SSH user usually cannot write
into it, and a site.env they did write would be unreadable by the app — the
admin would stay disabled after provisioning. The script now writes the file
through a container running as the app user, so ownership is right the first
time and no playbook re-run is needed. Also checks the data root exists and
tells you to run the playbook if it does not.
Every mutating form now carries the CSRF token as a hidden field, and the
upload route accepts it as a multipart field as well as a header. Driving the
real UI in Firefox found what the header-only tests could not: Create Draft,
Save, Publish, Delete and the up/down buttons all posted without a token and
were rejected. Adds npm run check-site, which verifies a running Site from the
outside and exits non-zero so it can gate a cutover.
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.
verify reports integrity problems and repair rebuilds derivatives from the
Originals, which is what makes the file layout trustworthy without a database.
The image runs TypeScript on Node 24 with no build step, writes only under
MENU_ROOT, and the provision script writes the untracked site.env using the
image's own hasher so the server needs no Node.
The admin signs in with the shared password, creates a Menu Set, drops photos
into it (shrunk in the browser first), reorders Pages by dragging or with
up/down buttons, previews the Draft exactly as customers would see it, and
publishes it over the previous set. Restore and delete close the loop. Mutations
need a session, a same-origin request and a CSRF token derived from the session;
a Draft's media is served only to a session holder.
Landing page, Section pages and archived sets rendered per request from the
store, with the approved design: hand-written CSS, self-hosted Archivo, a
copper pour line in the Section rail, an admin-only Thumbnail and a text page
index. Media is keyed by Page id so URLs survive publishing, and a Draft's
media needs a session. Includes the scrypt admin auth and the login throttle
the media rule needs.
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