website/DEMO_MODE.md

@@ -301,6 +301,14 @@ now owned by the fresh site. The rig has to be back at the demo default set **be
 first talks to it. Then that first import *is* the reset: the site adopts the default set, and the
 default set never has to be described twice.
 
+**Except for two parts of it (DM26, found on the first restored wipes, 2026-10-27).** Permissions,
+groups and members come back through the import as described. **NPC profiles and factions** do not:
+the restored rig's RunicNPC says it is already managed, by the site before this one, so the new site
+adopts nothing (D244), and its first push sends an empty profile set. **Group chat styles** are
+never adopted by the import. These two come from the fixture instead (§7.3): the seed writes them
+into the site before its first sync, the site pushes them, and the baseline's NPC placements spawn
+again. The baseline still holds the placements, routes and everything else on the rig.
+
 ### 7.2 The rig: restore a baseline through Pterodactyl (DM3)
 
 The demo rig is the existing `rust-oxide` Pterodactyl server (DM5). On it sits one archive,
@@ -361,13 +369,19 @@ current `rust-oxide`. **Done:** the org lead created the subuser and added the s
      this only on the first run against a database, so a re-run never duplicates it;
    - hands each installed module its `modules.<id>` section through the module's `onDemoSeed` hook
      (DM15, `MODULE_API` 1.18.0). The Rust module writes its own server row, with the rig's sidecar URL
-     and token, and `demo-player`'s stand-in Steam link (DM6). Core never writes a module's tables;
+     and token, and `demo-player`'s stand-in Steam link (DM6), and the default set's NPC faction
+     table, NPC profiles and group chat styles (DM26, §7.1). Core never writes a module's tables;
    - stamps `demo_state`: `resetsAt`, the next `DEMO_RESET_EVERY_HOURS` slot (default 2) on the hour
      UTC, and the published logins.
 
    The fixture is JSON: `{ accounts, settings?, content?: { posts, wiki, pages, events }, modules? }`.
    The Rust module's section is `{ servers: [{ id, name, sidecarBaseUrl, sidecarToken, protocol?,
-   enabled?, sortOrder? }], links: [{ username, steamId, name?, serverId? }] }`.
+   enabled?, sortOrder? }], links: [{ username, steamId, name?, serverId? }], npcs?: { factions?:
+   [{ a, b, relation }], profiles?: [{ name, servers?, allServers?, killsScope?, body }] }, chat?:
+   [{ serverId, group, style }] }`. A profile's `body` lists only what differs from RunicNPC's defaults,
+   and is checked as the admin page checks one. A `style` lists only the BetterChat fields that differ
+   from the defaults. Its group is created on the site for that server if the import has not brought
+   it in yet; the import then fills in the rig's title, rank and permissions.
    Any string `"$env:NAME"` in it is replaced with that variable from the host's `.env`, so the
    sidecar token is never in the repo. An unset variable fails the run instead of seeding an empty
    credential. The script checks the fixture before writing anything. It must name exactly the four
@@ -377,8 +391,9 @@ current `rust-oxide`. **Done:** the org lead created the subuser and added the s
 
    **There is no seeded team.** Core's Teams are synced from the game (a Rust clan becomes a Team), so
    the demo's team comes from a clan in the rig's baseline (§7.2), not from the fixture.
-5. The module's sync connects when the rig finishes booting, and its first import adopts the
-   baseline's permissions and NPCs (§7.1).
+5. The module's sync connects when the rig finishes booting. Its first import adopts the
+   baseline's permissions, and its first NPC push sends the seeded profiles, which the baseline's
+   placements spawn from (§7.1).
 6. Smoke check, after a bounded wait: `GET /api/v1/public/status` answers, and the Rust server
    reports a live connection. A rig that has not come back fails the run, and the site still
    serves with the server shown offline.
@@ -471,6 +486,7 @@ down.
 | DM23 | (build, step 5) Where does the demo live on its host? | **`/opt/demo.runicgateway.com`**, the `demo-site` runner in host mode, like `rgcom`'s `/opt/runicgateway.com`. The org lead writes `.env` from `deploy/demo/.env.example` |
 | DM24 | (build, step 5) The module's demo code was on `edge` only, so no release could be installed. Cut over? | **Yes, now:** `Module-Rust` `edge` → `main` releases v0.6.0, the first with `protocol` in its install manifest |
 | DM25 | (amendment, 2026-10-27) Uploads are locked, but an image pasted into rich text is saved as a `data:` URI inside the JSON body. Block it? | **Yes, on every write and for every `data:` URI.** Core refuses any write whose JSON body has a `data:` URI in any string, on any route, the same way the multipart rule needs no list (§3.3) |
+| DM26 | (build, step 5, 2026-10-27) The restored rig is marked managed, so a fresh site adopts none of its NPC profiles and empties them on its first push; chat styles are never adopted. How does the default set bring them back? | **Seed them.** Module-Rust's `onDemoSeed` also takes `npcs` (factions, profiles) and `chat` (a style per group), written before the site's first sync (§7.1, §7.3). Patch release v0.6.1 |
 
 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
@@ -536,6 +552,13 @@ through that proxy.
    half worked (bundle 2026.10.22 written, rig restarted), but the seed loaded no module: the
    runner is not root, so its `chown` of `modules/` and `logs/` failed silently. The wipe now does
    the chown in a root container. The same day, DM25 added the `data:` URI rule (§3.3) to the walk's
-   upload checks.
+   upload checks. Wipe 362 was the first green one. **The default set** was then built through the
+   site as `demo-admin`. It holds `vip` and a new `moderator` group with chat titles, `demo-player` in
+   `vip`, bandit and guard NPC profiles with an allied faction pair, and `guard-1` at the bandit camp.
+   It was captured as the baseline (run 366, 499 MB with the world save). The first three restored
+   wipes (367-369) brought back the groups, permissions and members, but not the NPC profiles or the
+   chat titles (DM26). **Public URL:** `demo.runicgateway.com` is served through Pangolin. Cloudflare's
+   proxy in front of it made the app log Cloudflare's addresses as the visitors' IPs, under the
+   default `TRUST_PROXY=1`. Cloudflare was set to DNS only, and the app now logs the real visitor.
 6. **Play**: the sign-in details in the Play Console point at `play-review`;
    runicgateway.com `/beta` publishes the logins.