Note where identity lives in the plan and README

This commit is contained in:
tanshu committed 2026-09-22 23:11:48 +05:30
1 parent 32eeed144f
commit ce8079355b
2 files changed
+2 -1

No files matched your search

+1
View File
@@ -34,6 +34,7 @@ npm run check-site -- https://menu-new.hopsngrains.com
``` ```
src/config.ts Site config: brand, theme, seed Sections, limits src/config.ts Site config: brand, theme, seed Sections, limits
src/storage/sections.ts Categories: the Site's own list, edited in the admin src/storage/sections.ts Categories: the Site's own list, edited in the admin
src/storage/identity.ts Name, tagline, icon and display switches, edited in the admin
src/storage/manifest.ts Manifest type, validation, atomic JSON writes src/storage/manifest.ts Manifest type, validation, atomic JSON writes
src/storage/sets.ts The Menu Set store: create, add Pages, publish, restore, delete src/storage/sets.ts The Menu Set store: create, add Pages, publish, restore, delete
src/storage/validate.ts Boot validation: fatal problems and warnings src/storage/validate.ts Boot validation: fatal problems and warnings
+1 -1
View File
@@ -114,7 +114,7 @@ The look is the Atelier Dining & Hospitality system from Stitch (`docs/design/st
- New repo `menu-admin` on `git.tanshu.com`: app source, `Dockerfile`, `compose.yaml` for local dev, `docs/` (this plan, `CONTEXT.md`, the ADRs), `node --test` tests, and `deploy.sh` (tests, build, push). - New repo `menu-admin` on `git.tanshu.com`: app source, `Dockerfile`, `compose.yaml` for local dev, `docs/` (this plan, `CONTEXT.md`, the ADRs), `node --test` tests, and `deploy.sh` (tests, build, push).
- The container is `node:24-alpine` running TypeScript directly, so there is no build step; sharp's musl binaries come from `npm ci` on the image's own platform. It writes only under `MENU_ROOT` and healthchecks its own `/healthz`. - The container is `node:24-alpine` running TypeScript directly, so there is no build step; sharp's musl binaries come from `npm ci` on the image's own platform. It writes only under `MENU_ROOT` and healthchecks its own `/healthz`.
- The design system is documented in `docs/design/stitch/atelier-dining-hospitality.md`, with the four screens Stitch produced beside it. The Site's brand and theme live in `config/<site>.site.json`, baked into the image and selected with `MENU_SITE_CONFIG`; its Section list only seeds `data/sections.json` the first time. Categories are edited in the admin from then on (ADR 0007), so adding one does not need a redeploy. - The design system is documented in `docs/design/stitch/atelier-dining-hospitality.md`, with the four screens Stitch produced beside it. `config/<site>.site.json` holds the theme and the seed for everything the owner can change: it seeds `data/sections.json` (ADR 0007) and `data/site.json`, which holds the name, tagline, icon and date switch (ADR 0008). Colours stay in the config, so changing them is a rebuild; nothing else does.
- Build locally and push `registry.tanshu.com/menu-admin:<tag>`, matching the sibling `deploy.sh` / `make build-production TAG=` convention. - Build locally and push `registry.tanshu.com/menu-admin:<tag>`, matching the sibling `deploy.sh` / `make build-production TAG=` convention.
- New `menu-admin` playbook in `ansible-playbooks` with per-Site vars (`vars/hopsngrains.yml` first, the other two stubbed): roles `network`, `menu-app` (pull image, create `/var/lib/menu-app.<site>`, start container, health check, then `verify` the data directory) and `caddy` (snippet upsert). - New `menu-admin` playbook in `ansible-playbooks` with per-Site vars (`vars/hopsngrains.yml` first, the other two stubbed): roles `network`, `menu-app` (pull image, create `/var/lib/menu-app.<site>`, start container, health check, then `verify` the data directory) and `caddy` (snippet upsert).
- The existing `roles/caddy` only *adds* a snippet when its exact text is missing, which cannot change a proxy target; the new playbook's role uses a stable marker so `blockinfile` updates in place, and removes the old role's per-hostname marker at cutover so Caddy never holds two blocks for one hostname. - The existing `roles/caddy` only *adds* a snippet when its exact text is missing, which cannot change a proxy target; the new playbook's role uses a stable marker so `blockinfile` updates in place, and removes the old role's per-hostname marker at cutover so Caddy never holds two blocks for one hostname.