Merge pull request 'docs(website): demo hero editor previews but does not publish (DM21)' (#383) from fix/demo-hero-publish-lock into main

Reviewed-on: #383

website/BACKEND_DESIGN.md

@@ -1825,7 +1825,8 @@ it.
   - the target of `/admin/users/:id…` is a demo account;
   - the caller of `/auth/me/…` is signed in as one;
   - the `PUT /admin/settings` body names a protected key (`site_mode*`, `module_source_hosts`,
-    `teams_voice_*`, `demo_*`).
+    `teams_voice_*`, `demo_*`, `hero_layout`). `hero_layout_draft` stays open, so the hero
+    editor previews but cannot publish (DM21).
 
   A condition that cannot decide refuses.
 - **Event steps** (`MODULE_API` 1.19.0, DM18). `POST /admin/events`, `PUT /admin/events/:id` and

website/DEMO_MODE.md

@@ -106,7 +106,7 @@ wipe puts them back (§7).
 | Other people's sessions | `DELETE /auth/me/sessions/:id` **on a demo account**, whichever session it names (DM17) | Sign every other visitor out of the shared account |
 | Password reset | `POST /auth/password/forgot`, `POST /auth/password/reset/:token` | Reset a demo account's password |
 | Registration | `POST /auth/register` (DM16) | Settings are open, so a visitor could switch `player_registration` on. The route is what keeps registration closed (§4) |
-| Settings that reach a lock | `PUT /admin/settings` when the body names `site_mode*`, `module_source_hosts`, `teams_voice_*` or `demo_*` | That route writes arbitrary keys, so these would get around the site-mode, Modules and team-voice rows above, or rewrite the banner and the published logins. The answer names the keys (`keys: [...]`) |
+| Settings that reach a lock | `PUT /admin/settings` when the body names `site_mode*`, `module_source_hosts`, `teams_voice_*`, `demo_*` or `hero_layout` | That route writes arbitrary keys, so these would get around the site-mode, Modules and team-voice rows above, rewrite the banner and the published logins, or publish the homepage hero (DM21). The answer names the keys (`keys: [...]`) |
 
 **Why DM17 locks the whole route.** A mobile access token carries no id for its refresh-token row,
 so the server cannot tell which row in `GET /auth/me/sessions` is the caller's own. Signing out is
@@ -123,6 +123,12 @@ so the server cannot tell which row in `GET /auth/me/sessions` is the caller's o
 changed and come back at the wipe, except the keys in the "Settings that reach a lock" row above.
 Brand images are uploads, so they fall under the upload lock.
 
+**The hero editor previews but does not publish (DM21).** Admin → Hero autosaves to
+`hero_layout_draft`, and its Preview opens the homepage with that draft, so both keep working. Its
+Publish writes `hero_layout`, the hero every visitor sees, and is refused; the editor's status line
+and the toast give the demo sentence. Its image uploads fall under the upload lock. The demo admins
+share one login, so they share one draft, and the wipe resets it.
+
 **Which accounts are demo accounts.** The four usernames in §4 are fixed in core
 (`server/src/demo/mode.js`), not read from the seed fixture: the lock checks them on every request,
 and a fixture that dropped one would unlock the account everybody shares. The lock decides by the
@@ -428,6 +434,7 @@ down.
 | DM18 | (build, step 2) Saving an event is core's route, and core never asks a module about a step's params. How is a denied command refused at save? | **A new core hook:** an event action's optional `demoRefuses(params)`, asked at create, save and publish on the demo, refusing `403 DEMO_LOCKED` (§3.4). `MODULE_API` 1.19.0; Module-Rust then needs `^1.19.0` |
 | DM19 | (build, step 4) Each app screen writes its own failure line, and the admin screens turn every `403` into "You don't have permission for that action". How does the app show a refusal? | **One app-wide snackbar** with the server's sentence, like the web's toast, and the screens whose `403` line blames the role say the demo sentence instead. `ErrorKind.DEMO_LOCKED` for load screens (§3.1) |
 | DM20 | (build, step 4) Should the app's sign-in screen list the logins, as the web's does? | **No, the banner only.** The Home strip names the site's sign-in page for the passwords; Google's reviewer gets `play-review`'s from the Play Console (§6) |
+| DM21 | (amendment, 2026-10-26) Settings are open, so the hero editor's Publish changes the homepage every visitor sees. What may a visitor do in the hero editor? | **Edit and preview, never publish.** `hero_layout` joins the protected settings keys; the draft and Preview stay open; uploads were already locked. Server lock only: Publish stays clickable and answers the demo sentence (§3.3) |
 
 DNS and HTTPS for `demo.runicgateway.com` come from an external reverse proxy, which the org lead is
 setting up. The app sits behind it on plain HTTP; core already trusts one proxy hop for
@@ -483,6 +490,7 @@ through that proxy.
    browser and the app, plus one full wipe cycle that restores a changed permission, NPC and
    event; a denied console command refused at save and at run; and a plugin config changed and
    reloaded through the editor, with the bridge's config refused for reading and another plugin's
-   secret field redacted. One PR.
+   secret field redacted; and the hero editor's draft previewed while its Publish is refused
+   (DM21). One PR.
 6. **Play**: the sign-in details in the Play Console point at `play-review`;
    runicgateway.com `/beta` publishes the logins.