wtclaude
66187dde5d
Some checks failed
PR checks / checks (pull_request) Failing after 4m19s
Astro 7 with the Node adapter, Starlight mounted at /docs, the token file, both self-hosted typefaces, the layout shell, and the two build-time checks from §12. The palette's gold and cyan are sampled from runic-emblem.png rather than guessed, per §11: 494,059 opaque pixels binned by hue, each value annotated with its measured contrast against the ground, and restricted rather than brightened where a ratio fails. - checkTokens.mjs fails the build on any colour literal outside tokens.css, which is what keeps §7's "recolouring is a file copy" promise true. - checkFacts.mjs re-reads all 14 externally-sourced facts from their authorities over the Gitea API and fails on disagreement. It also enforces D13: no email address in the source outside brand-default/brand.json. - Both were negative-tested; neither has ever been allowed to pass by default. §6 asks for output:'server' with per-page prerender=true. Astro 7 expresses the same runtime shape as output:'static' with an adapter, opting individual routes out — so the default is static rather than accidentally server-rendered. Co-Authored-By: Claude <noreply@anthropic.com>
79 lines
2.2 KiB
JavaScript
79 lines
2.2 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' }],
|
|
},
|
|
];
|
|
|
|
/**
|
|
* The full planned tree, kept next to the live sidebar so phases 7 and 8 have their
|
|
* checklist in the place they will be working. Not exported into the Starlight config —
|
|
* it names pages that do not exist yet.
|
|
*/
|
|
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',
|
|
'Users and roles',
|
|
'Authentication',
|
|
'Teams',
|
|
'Moderation',
|
|
'Notifications and email',
|
|
'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',
|
|
],
|
|
};
|