wtclaude
c8a293b8f6
Engagement Phase 12a. The site had pages for where a message goes (Notifications and
email) and what it says (Message templates), and nothing at all for what makes one get
sent -- the four Engagement screens the workstream built.
New page: Engagement rules. Rules, Audiences, the trigger catalog and the send log on
one page, sitting between the two it joins up. Templates already has its own page and
Suppressions is in Troubleshooting, so neither is repeated here.
Two things it exists to state plainly:
* Every rule ships disabled, including the ones a module brings. "Installed" is not
"on", and an upgrade whose Team mail went quiet is the same fact.
* The ceiling is a TREE, not a ladder. The tempting reading -- a staff-only event
could obviously also go to one person -- is wrong, and the example is the argument:
"one person" for cheat detection is the player it was detected on.
Troubleshooting gains the symptom that page answers ("nothing is sent for one
particular event"): the rule is off, the rule is dormant, its own cooldown held it, or
the audience is empty.
Privacy: two rows the engagement work makes necessary, and one sentence it made false.
* app-content claimed "Nothing is cached for offline use". Phase 8 shipped a DataStore
snapshot of the inbox, so it was untrue -- and that row feeds the generated Play Data
Safety answers, which is a store-review matter rather than a doc nit. The snapshot now
has its own row and its own Play mapping (Messages / Other in-app messages; not
collected by us, stored on the device), and app-content's claim is narrowed to
everything else.
* deploy-engagement, for the deployment scope: an address is now used for more than
getting into an account, there is a delivery log holding a one-way hash of it, and
there is a suppression list. Its retention line says what is true rather than what a
reader assumes -- none of these tables has a retention sweep.
PLAY_DATA_SAFETY.md regenerated from the inventory; legal.lastUpdated moved with the page
it dates.
Verified: the whole `verify` chain green -- checkSidebar (plannedSidebar moved with the
live tree), checkFacts 19/19, checkQuickstart 59, checkReference 22, checkLinks 2605,
checkA11y, checkCsp, playDataSafety --check, 42 + 7 tests. Read in a browser as well, in
the served build.
AI-assisted: written with Claude Code.
Co-Authored-By: Claude <noreply@anthropic.com>
152 lines
6.1 KiB
JavaScript
152 lines
6.1 KiB
JavaScript
/**
|
|
* The documentation sidebar — PLAN.md §10 "Documentation", five groups, ~37 pages.
|
|
*
|
|
* The pages themselves land in phases 7 and 8. This file exists in phase 1 because the
|
|
* shape of the journey is a design decision that is already made, and because a sidebar
|
|
* written up front is what stops the docs from being organised by repository. A reader
|
|
* should never need to know that `link`, `servuo-plugins` and `installer` are three
|
|
* repositories in order to connect a game server (§10).
|
|
*
|
|
* `autogenerate` is deliberately NOT used: the order of "Getting started" is the
|
|
* installation path from §10, and alphabetical order would scramble it.
|
|
*
|
|
* Entries are added as their pages are written — Starlight fails the build on a link to a
|
|
* page that does not exist, which is the behaviour we want.
|
|
*/
|
|
export const docsSidebar = [
|
|
{
|
|
label: 'Getting started',
|
|
items: [
|
|
{ label: 'What is Runic Gateway?', slug: 'docs' },
|
|
{ label: 'Requirements', slug: 'docs/getting-started/requirements' },
|
|
{ label: 'Install the site', slug: 'docs/getting-started/install-the-site' },
|
|
{ label: 'First run', slug: 'docs/getting-started/first-run' },
|
|
{ label: 'Install a game module', slug: 'docs/getting-started/install-a-game-module' },
|
|
{ label: 'Connect a game server', slug: 'docs/getting-started/connect-a-game-server' },
|
|
{ label: 'Verify the whole stack', slug: 'docs/getting-started/verify-the-whole-stack' },
|
|
],
|
|
},
|
|
{
|
|
label: 'Administration',
|
|
items: [
|
|
{ label: 'Configuration', slug: 'docs/administration/configuration' },
|
|
{ label: 'Branding and theming', slug: 'docs/administration/branding-and-theming' },
|
|
{ label: 'Navigation and pages', slug: 'docs/administration/navigation-and-pages' },
|
|
{ label: 'Content', slug: 'docs/administration/content' },
|
|
{ label: 'Users and roles', slug: 'docs/administration/users-and-roles' },
|
|
{ label: 'Authentication', slug: 'docs/administration/authentication' },
|
|
{ label: 'Teams', slug: 'docs/administration/teams' },
|
|
{ label: 'Moderation', slug: 'docs/administration/moderation' },
|
|
{ label: 'Notifications and email', slug: 'docs/administration/notifications-and-email' },
|
|
{ label: 'Engagement rules', slug: 'docs/administration/engagement-rules' },
|
|
{ label: 'Message templates', slug: 'docs/administration/message-templates' },
|
|
{ label: 'Managing modules', slug: 'docs/administration/managing-modules' },
|
|
{ label: 'The shard connection', slug: 'docs/administration/the-shard-connection' },
|
|
{ label: 'Maintenance and upgrades', slug: 'docs/administration/maintenance-and-upgrades' },
|
|
{ label: 'Troubleshooting', slug: 'docs/administration/troubleshooting' },
|
|
],
|
|
},
|
|
{
|
|
label: 'Modules',
|
|
items: [
|
|
{ label: 'The module system', slug: 'docs/modules/the-module-system' },
|
|
{ label: 'Installing modules', slug: 'docs/modules/installing-modules' },
|
|
{ label: 'Module lifecycle', slug: 'docs/modules/module-lifecycle' },
|
|
{ label: 'The module manifest', slug: 'docs/modules/the-module-manifest' },
|
|
{ label: 'The module API', slug: 'docs/modules/the-module-api' },
|
|
{ label: 'Building a module', slug: 'docs/modules/building-a-module' },
|
|
{ label: 'The Integration Kit', slug: 'docs/modules/the-integration-kit' },
|
|
{ label: 'Testing and release', slug: 'docs/modules/testing-and-release' },
|
|
],
|
|
},
|
|
{
|
|
label: 'Architecture',
|
|
items: [
|
|
{ label: 'System architecture', slug: 'docs/architecture/system-architecture' },
|
|
{ label: 'The bridge', slug: 'docs/architecture/the-bridge' },
|
|
{ label: 'Authentication architecture', slug: 'docs/architecture/authentication-architecture' },
|
|
{ label: 'Teams architecture', slug: 'docs/architecture/teams-architecture' },
|
|
{ label: 'Protocol versions', slug: 'docs/architecture/protocol-versions' },
|
|
],
|
|
},
|
|
{
|
|
label: 'Reference',
|
|
items: [
|
|
{ label: 'Environment variables', slug: 'docs/reference/environment-variables' },
|
|
{ label: 'Installer CLI', slug: 'docs/reference/installer-cli' },
|
|
{ label: 'sidecar.toml', slug: 'docs/reference/sidecar-toml' },
|
|
{ label: 'Bridge.cfg', slug: 'docs/reference/bridge-cfg' },
|
|
{ label: 'HTTP API', slug: 'docs/reference/http-api' },
|
|
{ label: 'Event catalog', slug: 'docs/reference/event-catalog' },
|
|
{ label: 'Canonical documents', slug: 'docs/reference/canonical-documents' },
|
|
],
|
|
},
|
|
];
|
|
|
|
/**
|
|
* The tree §10 planned, kept as the record of what was intended — every page it names now
|
|
* exists, as of phase 8.
|
|
*
|
|
* It was the phases 7/8 checklist, and a checklist with nothing left on it is no longer
|
|
* pulling its weight: it is a second copy of the tree above, maintained by hand, and it had
|
|
* already drifted once (phase 7 added `Content` under D37 and this list was not updated,
|
|
* which nothing caught because nothing reads it). `checkSidebar.mjs` now asserts the two
|
|
* agree, which is what makes keeping it safe.
|
|
*
|
|
* Not exported into the Starlight config.
|
|
*/
|
|
export const plannedSidebar = {
|
|
'Getting started': [
|
|
'What is Runic Gateway?',
|
|
'Requirements',
|
|
'Install the site',
|
|
'First run',
|
|
'Install a game module',
|
|
'Connect a game server',
|
|
'Verify the whole stack',
|
|
],
|
|
Administration: [
|
|
'Configuration',
|
|
'Branding and theming',
|
|
'Navigation and pages',
|
|
'Content',
|
|
'Users and roles',
|
|
'Authentication',
|
|
'Teams',
|
|
'Moderation',
|
|
'Notifications and email',
|
|
'Engagement rules',
|
|
'Message templates',
|
|
'Managing modules',
|
|
'The shard connection',
|
|
'Maintenance and upgrades',
|
|
'Troubleshooting',
|
|
],
|
|
Modules: [
|
|
'The module system',
|
|
'Installing modules',
|
|
'Module lifecycle',
|
|
'The module manifest',
|
|
'The module API',
|
|
'Building a module',
|
|
'The Integration Kit',
|
|
'Testing and release',
|
|
],
|
|
Architecture: [
|
|
'System architecture',
|
|
'The bridge',
|
|
'Authentication architecture',
|
|
'Teams architecture',
|
|
'Protocol versions',
|
|
],
|
|
Reference: [
|
|
'Environment variables',
|
|
'Installer CLI',
|
|
'sidecar.toml',
|
|
'Bridge.cfg',
|
|
'HTTP API',
|
|
'Event catalog',
|
|
'Canonical documents',
|
|
],
|
|
};
|