docs: plan report/block/hide, decide M8's open items, plan demo content
- website/USER_SAFETY.md (new): report, block and hide on the website and in the app, S1-S5 decided by the org lead, five questions open. - android/PLAN.md: M8's three open items decided (keep the rating and add report/block/hide; conservative data safety; UnifiedPush on specialUse with restart on boot), the order to the cutover, and M21 (Teams and the team forum in the app, planned, not scheduled). - website/DEMO_MODE.md: DM32 and section 11, the demo content plan (two seed passes; moderation, Teams/forum/reports, event history, Rust stats). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
This commit is contained in:
@@ -498,6 +498,7 @@ down.
|
||||
| DM29 | (step-5 walk, W2, 2026-10-28) `SECRET_WORDS` also hides harmless fields such as "Allow Master Key" and "TC Auth Only". Narrow it? | **No, leave it as is** |
|
||||
| DM30 | (step 6, 2026-10-28) How does runicgateway.com `/beta` publish the logins? | **Live from the demo.** `/beta` reads this site's `GET /public/settings` `demo.logins` on its server, caches it for a minute, and links to `/account/login` when the demo does not answer (runicgateway.com D82) |
|
||||
| DM31 | (step 6) runicgateway.com's "See it running" links were UO routes, which 404 here. What do they do? | **Per game.** A deep link names its game, and that site's mounted `demoGames` (`["rust"]` for this demo) says which games' links show. Rust's point at `/rust` and `/rust/servers/demo?tab=…`, so that site now quotes the fixture's server id `demo` (runicgateway.com D83) |
|
||||
| DM32 | (2026-10-29) The moderator tour shows empty queues, and other surfaces are empty too (§11). Which get seeded? | **All four of §11's groups:** moderation history, Teams with their forum and reports, event history with the calendar, and Rust player stats |
|
||||
|
||||
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
|
||||
@@ -647,3 +648,71 @@ through that proxy.
|
||||
locks). The org lead types the password, ticks the full-access attestation and saves. The closed
|
||||
track does not exist yet (Test and release shows *Get started* for closed and internal testing), so
|
||||
there is no opt-in URL for `betaOptInUrl`, and `/beta`'s first gate stays shut.
|
||||
7. **Demo content** (DM32, §11): the seed's two passes and the rig's clans. Planned 2026-10-29.
|
||||
One PR in `website` (core seed, the wipe's second pass), one in `Module-Rust` (`onDemoSeed`
|
||||
stats and feed lines, into `edge`), a new baseline, and a walk of every surface §11 names after
|
||||
the next wipe.
|
||||
|
||||
## 11. Demo content (DM32)
|
||||
|
||||
**Why.** A read-only count of the live demo on 2026-10-29 found these surfaces empty after a wipe:
|
||||
every moderation queue (recent actions, filter hits, spam hits, member events, appeals, reports),
|
||||
Teams (public, the player's own, staff's review queue), event runs and history, the public calendar
|
||||
(the three seeded events are never scheduled), `demo-player`'s inbox, and on the Rust side the
|
||||
leaderboard, wipes, clans and the events feed. Only the four demo accounts exist. A reviewer touring
|
||||
as `demo-moderator` finds nothing to moderate.
|
||||
|
||||
### 11.1 Two seed passes
|
||||
|
||||
Some of it can be written the moment the site is up. The rest depends on the rig: Teams are
|
||||
**module-authoritative** and re-synced every 15 minutes (`TEAMS.md`), so a Team written straight
|
||||
into core would be archived by the next sync, and the Rust stats need the wipe the rig is on. So:
|
||||
|
||||
- **Pass 1, `seed:demo`, as today**: accounts, settings, content, events, and the new core rows
|
||||
below that need nothing from the rig.
|
||||
- **Pass 2, `seed:demo --after-rig`**, a new step in `demo-wipe.yml` after the rig reports in and
|
||||
the first Teams sync has run: Team forum content, reports, Rust stats and feed lines. It waits for
|
||||
the Teams it names, with a time limit, and fails the wipe if they never appear, as the rig smoke
|
||||
check does.
|
||||
|
||||
The rig's wipe id comes from the restored world save, so it is the same on every wipe
|
||||
(`w-20261005T165054Z` today). Pass 2 reads it from the server state rather than the fixture, so a
|
||||
new baseline with a new map still works.
|
||||
|
||||
### 11.2 What each group seeds
|
||||
|
||||
- **Moderation history** (pass 1, core). Discord-shaped rows for six invented members: a few
|
||||
`mod_actions` (warn, timeout, ban), `warnings`, `filter_hits` and `spam_hits`, join and leave
|
||||
`member_events`, staff `mod_notes` (one admin-only), and three `appeals`: one pending to claim,
|
||||
one under review, one resolved. Times are relative to the seed, so the 24 h / 7 d / 30 d counts
|
||||
are never zero. There is no bot on the demo, so approving an appeal records the reversal as
|
||||
failed. That is the shipped behaviour when the bot is down, and the appeal still closes.
|
||||
- **Teams, forum and reports.** Two or three clans **in the rig's baseline** (the Clans plugin's
|
||||
data, which already reports an empty board), with stand-in members and `demo-player`'s stand-in
|
||||
Steam ID in one, so sync brings them in as Teams. One clan's name contains a reserved term, so it
|
||||
lands in staff's review queue. Pass 2 then writes forum threads and posts in them, and two open
|
||||
reports. Once report, block and hide exist (`USER_SAFETY.md`), it also writes reports on chat
|
||||
lines.
|
||||
- **Event history and the calendar** (pass 1, core). Two finished runs of the seeded events, with
|
||||
their steps, log, participants (stand-ins, and `demo-player` through its link) and published
|
||||
results, so the history and results pages fill and `demo-player`'s inbox has the results
|
||||
notification. The three seeded events are scheduled in the coming days, so the public calendar
|
||||
shows them.
|
||||
- **Rust player stats** (pass 2, Module-Rust `onDemoSeed`). About ten stand-in players with wipe
|
||||
stats (kills, deaths, NPC kills, playtime, gather totals, weapon kills) on the rig's current
|
||||
wipe, an earlier wipe for the Wipes tab, and a day of feed lines (kills, joins, chat), so the
|
||||
leaderboard, profiles and feed are populated. The online list stays honest at zero.
|
||||
|
||||
### 11.3 Open questions
|
||||
|
||||
1. **Stand-in Steam IDs.** Every 17-digit `7656119…` number can belong to a real person, and these
|
||||
would appear on public leaderboards. *Recommended:* check each candidate against Steam's public
|
||||
profile page before using it, keep only IDs with no profile, and list them in the fixture with
|
||||
that check recorded. `demo-player`'s existing stand-in gets the same check.
|
||||
2. **Invented Discord IDs.** The moderation pages show Discord user ids. *Recommended:* synthetic
|
||||
ids from a block well below any issued since 2016, named in the fixture as demo data. Nothing on
|
||||
the demo links them to Discord.
|
||||
3. **Names.** *Recommended:* invented gamer tags ("Rusty_Pete", "Scrap Baron", …), never a real
|
||||
person's name, and nothing offensive even in the seeded filter hits, which show a placeholder
|
||||
word.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user