ShadowsOverWestgate/sow-nodebb-theme
3
0
Fork 0
Code Issues 12 Pull Requests Actions Packages Projects Releases Activity

spec

Browse Source
This commit is contained in:
archvillainette
2026-06-26 09:35:18 +02:00
parent 594d2e17f1
commit ea55d1e146
2 changed files with 704 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/superpowers/specs/2026-06-26-global-topbar-design.md
+158
View File
@@ -0,0 +1,158 @@
# Global Topbar Design Spec
Date: 2026-06-26
Status: draft, goal definition
## Goal
Complete the Westgate global topbar as the theme-owned replacement for
Harmony's NodeBB sidebars.
The current `custom_pages/westgate-pages/top-bar.html` and
`custom_pages/westgate-pages/topbar-custom.js` files are reference material from
the design extraction. They show the intended visual language and rough
interaction shape, but they are not production behavior. The finished topbar
belongs in this theme as global chrome, not as ACP Custom Content pasted onto
individual pages.
The topbar must make website pages, wiki pages, and forum pages feel like one
Westgate application while preserving real NodeBB account, navigation, search,
notification, chat, draft, and status behavior.
## Evidence Checked
- `docs/superpowers/specs/2026-06-26-website-pages-design.md` already defines
the topbar as the owner of Harmony sidebar functions.
- `custom_pages/westgate-pages/THEME-INTEGRATION.md` recommends a
`templates/partials/header/topbar.tpl` theme partial and reuse of Harmony live
components.
- `custom_pages/westgate-pages/top-bar.html` is a visual/reference draft with
placeholder avatar, notification, chat, and draft data.
- `custom_pages/westgate-pages/topbar-custom.js` is a paste-ready preview
controller for ACP Custom JavaScript, with comments noting where live NodeBB
behavior still needs to replace preview behavior.
- `templates/header.tpl` currently imports `partials/sidebar-left.tpl` and lays
out `#panel` beside the sidebar.
- Harmony still supplies the inherited right sidebar through its footer unless
Westgate overrides that path.
- `theme.scss` is imports-only and already imports focused files from
`scss/westgate/`.
## Required Behavior
The Westgate topbar replaces the NodeBB sidebar experience. It must own every
user-facing button or action that currently lives in Harmony's desktop sidebars
or duplicate mobile bars:
- Brand/home entry.
- ACP Navigation links and active states.
- Forum/category entry points.
- Search, including NodeBB quick search behavior.
- Notifications, with real unread counts and notification list behavior.
- Chats when chat is available to the user.
- Drafts, with real draft count, open, and delete behavior.
- User avatar menu using the logged-in user's real avatar.
- User status controls that set the user's actual NodeBB status, including
online, away, and invisible when supported by the running NodeBB version.
- Profile, bookmarks, edit profile, settings, moderator/admin affordances, and
logout.
- Guest login and register actions.
- Mobile equivalents for the same primary actions.
The topbar is not allowed to pretend that live data exists. If the current user
has no notifications, chats, or drafts, the topbar must show the real empty or
hidden state. Counts must come from NodeBB data, not hard-coded badge text.
## Visual Direction
Use the draft topbar as a visual target, not as final source. The production
topbar should keep the black velvet, near-black plum, muted gold, restrained
contrast, and small red state detail direction already established by the
Westgate theme.
All substantive styling belongs in a focused SCSS partial such as
`scss/westgate/_topbar.scss`, imported from `theme.scss`. The partial should use
existing `--wg-*` tokens where possible and should not introduce a second visual
system.
Harmony sidebar buttons should be restyled as topbar controls. They should feel
native to the topbar, not like sidebar markup awkwardly placed in a horizontal
row.
## Implementation Direction
The production implementation should be theme-first:
- Add a focused topbar partial, likely
`templates/partials/header/topbar.tpl`.
- Mount the topbar from `templates/header.tpl`.
- Remove the global Harmony left sidebar from the main layout.
- Override the Harmony footer path if needed so the right sidebar no longer
renders as a separate global sidebar.
- Let `#panel` become the normal main content column under the topbar.
- Keep `theme.scss` imports-only.
- Put topbar CSS under `scss/westgate/`.
- Put topbar client behavior in the theme client bundle unless an ACP bridge is
explicitly chosen as a temporary deployment step.
Where possible, reuse Harmony or NodeBB partials and component hooks for live
behavior instead of rebuilding dynamic systems. Important hooks include search,
notifications, chat, drafts, user controls, and status controls. If preserving
Harmony selectors would produce brittle markup, update the theme JavaScript
intentionally and document the changed selector contract.
## Reference Files
The reference files may be copied from selectively, but they should not be
treated as production source:
- `custom_pages/westgate-pages/top-bar.html`: visual structure, states, and
scoped CSS ideas.
- `custom_pages/westgate-pages/topbar-custom.js`: preview interaction patterns
for menus, search expansion, mobile drawer, and escape/outside-click handling.
- `custom_pages/Westgate Top Bar.dc.html`: original visual design export.
Preview-only behavior to remove or replace includes hard-coded notifications,
hard-coded chats, hard-coded drafts, fake status persistence in `localStorage`,
demo member/guest switching, and placeholder avatar rendering.
## Risks
Harmony JavaScript currently assumes sidebar-oriented selectors for search,
drafts, notification/chat counts, sidebar toggles, tooltips, and layout offsets.
The topbar implementation must account for those assumptions directly. A
visually correct topbar is not complete if NodeBB's live sidebar behavior stops
working.
The mobile experience also needs an explicit decision during implementation:
once the Westgate topbar drawer owns the same actions, Harmony's inherited
mobile bars should not duplicate those controls.
## Acceptance Criteria
- No Harmony left or right global sidebar is visible on normal Westgate pages.
- All former sidebar actions remain reachable from the topbar or its mobile
drawer.
- Logged-out users see real login/register actions.
- Logged-in users see their real avatar and the correct account menu.
- Notifications, chats, and drafts use real NodeBB counts and lists.
- Empty notification, chat, and draft states are real states, not mock rows.
- User status buttons call the real NodeBB status behavior and reflect the
resulting state.
- Search uses NodeBB search behavior rather than a visual-only input.
- The topbar appears consistently on Custom Pages, wiki routes, and normal forum
routes.
- The topbar styling follows Westgate theme tokens and lives under
`scss/westgate/`.
- The implementation remains a child theme over `nodebb-theme-harmony`.
## Decisions For Implementation Planning
- Whether to temporarily ship any part of the topbar through ACP Custom Content
for visual validation before moving it fully into the theme.
- Whether the skin switcher remains exposed, and if so where it belongs in the
topbar or account menu.
- Whether legacy `sidebar-footer` widget content is deprecated, moved to a real
footer, or exposed through another intentional surface.
- Which Harmony selectors are preserved for compatibility and which are replaced
with Westgate topbar selectors.
docs/superpowers/specs/2026-06-26-website-pages-design.md
+546
View File
@@ -0,0 +1,546 @@
# Westgate Website Pages Design Spec
Date: 2026-06-26
Status: draft, investigation only
## Goal
Build the public website pages for Shadows Over Westgate inside NodeBB. The site
uses NodeBB as the application platform, the Custom Pages plugin for website
routes/pages, the Westgate theme for shared visual language and global chrome,
and local plugins where Custom Pages needs dynamic data or behavior.
The site should feel like one Westgate experience rather than a forum with
separate pasted pages. The visual target remains black velvet, near-black plum,
muted gold, restraint, decay, and rich contrast. Red is reserved for state or
danger details. Color changes should happen through existing `--wg-*` theme
tokens where possible.
The custom pages to design are:
- Home
- Gallery
- News
- Blog / Developer Blog
- Recruitment
Everything built for these pages belongs under a tracked `custom/` folder.
Everything currently in `custom_pages/` is reference material from the design
extraction and should be pulled from selectively, not treated as production
source.
The major structural goal is that Harmony's left and right sidebar functions are
owned by a global Westgate topbar. Website pages, wiki pages, and forum pages
should share the same navigation, account actions, search, notifications, chat,
drafts, and authentication entry points.
## Evidence Checked
- `theme.json` declares `baseTheme: "nodebb-theme-harmony"`.
- `theme.scss` imports Harmony first, then focused Westgate partials under
`scss/westgate/`.
- `templates/header.tpl` currently matches the Harmony layout pattern: a
`layout-container`, `partials/sidebar-left.tpl`, `#panel`, and
`partials/header/brand.tpl`.
- Harmony's `footer.tpl` imports `partials/sidebar-right.tpl`.
- Harmony's sidebar partials under
`/home/vicky/Repositories/nodebb-theme-harmony/templates/partials/sidebar/`
own the live controls for navigation, user menu, search, notifications, chat,
and drafts.
- Harmony's `public/harmony.js` binds behavior to sidebar-oriented selectors,
especially `[component="sidebar/search"]`, `[component="sidebar/drafts"]`,
`[component="sidebar/toggle"]`, `nav.sidebar [component="notifications/count"]`,
and `nav.sidebar [component="chat/count"]`.
- The wiki plugin at
`/home/vicky/Projects/westgate/repositories/migration/sow-nodebb-plugin-wiki`
is a NodeBB plugin that treats selected categories as wiki namespaces and
topics as wiki pages. Its README says the active theme supplies brand colors,
typography, and panel chrome through CSS custom properties.
- `custom_pages/` contains raw Claude Design exports, screenshots, preview
harnesses, and cleaned paste-ready modules.
- `custom_pages/westgate-pages/THEME-INTEGRATION.md` already sketches a theme
integration path for News, Dev Blog, Gallery, and Topbar.
## Artifact Inventory
### Raw Claude Design Exports
These are reference artifacts, not direct production inputs:
- `custom_pages/Westgate.dc.html`
- `custom_pages/Westgate v1 (approx palette).dc.html`
- `custom_pages/Westgate Top Bar.dc.html`
- `custom_pages/support.js`
- `custom_pages/image-slot.js`
The `.dc.html` files use Claude Design/Omelette style markup such as `<x-dc>`,
`<sc-if>`, inline preview handlers, and runtime helpers. They establish layout,
states, palette exploration, and interaction ideas. They should not be pasted
directly into NodeBB Custom Pages as production page content.
### Reference Custom Pages-Compatible Page Modules
These are cleaned design extraction files that may be used as references while
building tracked production files under `custom/`:
- `custom_pages/westgate-pages/home.html`
- `custom_pages/westgate-pages/join-the-team.html`
- `custom_pages/westgate-pages/top-bar.html`
- `custom_pages/westgate-pages/topbar-custom.js`
`home.html` and `join-the-team.html` are useful because they are already pure
HTML/CSS widgets scoped under `.wg-page`. The production versions should be
rebuilt as `custom/pages/home.html` and `custom/pages/recruitment.html`, with
content and links adjusted for the final routes.
`top-bar.html` is a faithful preview/reference for the global topbar, but it is
not the preferred long-term deployment form. The live topbar belongs in the
theme as a global partial and stylesheet, with client behavior in the theme
client bundle or ACP custom JavaScript only as a temporary bridge.
### Preview Harnesses And Screenshots
Preview harnesses:
- `custom_pages/westgate-pages/_preview-home.html`
- `custom_pages/westgate-pages/_preview-join.html`
- `custom_pages/westgate-pages/_preview-topbar.html`
Screenshots under `custom_pages/screenshots/` capture the visual target and
states. They are useful for QA and comparison, but should not be treated as
source assets for the live site unless explicitly selected.
## Repository Ownership Model
### `custom/` Is The Production Custom Pages Source
All custom-page artifacts we build should live under `custom/` in this
repository. The first layout should be:
```text
custom/
pages/
home.html
gallery.html
news.html
blog.html
recruitment.html
shared/
assets/
```
The `custom/pages/*.html` files are the source files intended to be installed
through NodeBB Custom Pages and Widgets. They may start as paste-ready HTML/CSS,
but they should be treated as source we own, not generated exports.
`custom/shared/` is reserved for shared snippets, notes, or small page fragments
that are intentionally reused across the five pages. It should stay small; if a
shared concern becomes real application behavior, move it into the theme or a
plugin instead.
`custom/assets/` is reserved for manifest notes and selected source assets for
custom-page use. It should not become a dumping ground for generated screenshots
or raw uploads. Actual public media should normally be uploaded through NodeBB or
served by the owning plugin/theme static directory.
### `custom_pages/` Is Reference Only
`custom_pages/` is an extraction/reference folder. It may contain Claude Design
exports, preview harnesses, uploads, screenshots, and exploratory files.
Rules:
- Do not install files directly from `custom_pages/` without first moving or
rewriting the relevant element into `custom/`.
- Do not treat `.dc.html` files as production source.
- Do not track generated previews/screenshots as production assets unless they
are explicitly chosen as QA references.
- When a useful element is pulled from `custom_pages/`, document that provenance
in the relevant `custom/pages/*.html` comment or in this spec.
### Theme Owns Shared Visual Language
The theme remains responsible for the design system and global chrome:
- `--wg-*` design tokens
- fonts
- panel, button, form, card, prose, and widget styling
- topbar
- forum page styling
- wiki parity hooks through `--wiki-*` variables and shared classes
Custom pages should consume the theme's tokens and classes. They should not fork
the palette or create a second visual system.
### Plugins Own Dynamic Behavior When Custom Pages Is Not Enough
NodeBB should do everything, but not every page can be static HTML.
If Custom Pages cannot server-render or safely fetch the data a page needs, a
small local NodeBB plugin should provide the data/API/view-model layer while the
page remains a Custom Pages route. This applies especially to:
- News from forum category `1`
- Blog from forum category `84`
- Gallery if it needs a special upload directory, moderation flow, or asset API
- Future recruitment applications, because no application plugin exists yet
The rule is: Custom Pages owns the website route and page composition; forum
topics/categories remain canonical content where appropriate; plugins may expose
normalized data so the page does not look or behave like a raw forum view.
## Page Ownership
### Static Custom Pages
Use Custom Pages and widgets directly for pages whose content is mostly
editorial and does not require live NodeBB data:
- Home
- Recruitment
Rules:
- Scope page styles under `.wg-page` or a more specific page root such as
`.wg-home` or `.wg-recruit`.
- Use existing `--wg-*` CSS variables for fonts, color, borders, shadows, and
panels.
- Keep inline JavaScript out of static page widgets unless there is a strong
reason. The current reference Home and Recruitment pages require no
JavaScript.
- Treat placeholder upload paths such as `/assets/uploads/westgate/...` as
install-time inputs.
- Leave per-page sidebar widget areas empty unless a page explicitly needs a
sidebar module.
### Dynamic Custom Pages
Use Custom Pages plus plugin-provided data for pages that need live forum or
asset data:
- News
- Blog / Developer Blog
- Gallery
Rules:
- Custom Pages owns the public route.
- The page should present as a website page, not a category or topic template.
- The underlying NodeBB source should remain available for permissions,
moderation, authorship, search, and discussion behavior.
- Data should be normalized before rendering: title, slug, category, author,
date, teaser, body, optional banner image, and canonical discussion link.
- Forum affordances should be hidden from the main website presentation unless
they are intentionally exposed as secondary actions.
### Forum And Wiki Parity
Forums and the wiki are not separate visual products. They must stay in parity
with custom pages:
- Same topbar and global navigation.
- Same `--wg-*` palette, typography, border, panel, and focus treatment.
- Same prose vocabulary for article-like content where practical.
- Same button and card language.
- Same mobile behavior expectations.
- Same accessibility bar: readable contrast, visible focus states, usable hover
and active states.
The wiki plugin already exposes theme hooks through `--wiki-*` CSS variables and
uses `.westgate-wiki` / `.wiki-article-prose` classes. The Westgate theme should
remain the place where those variables are mapped to the `--wg-*` design system.
## Page Specifications
### Home
Production source: `custom/pages/home.html`
Reference source: `custom_pages/westgate-pages/home.html`
Deployment: Custom Pages route `home` or `/`, with the full file pasted into
an HTML widget in the main content area.
Current sections:
- Hero with title, setting line, key-art placeholder, and two CTAs.
- Server status strip with static placeholder data.
- Setting pitch with long-form atmosphere copy.
- Four "Enter the City" step cards.
- Latest News strip with three static card placeholders.
Open data decisions:
- Final route: `/`, `/home`, or both via redirect.
- Final art upload paths.
- Whether server status and player counts remain static at launch or come from a
status widget/API.
- Whether the Latest News strip remains manually curated or is replaced by live
category data later.
### Recruitment
Production source: `custom/pages/recruitment.html`
Reference source: `custom_pages/westgate-pages/join-the-team.html`
Deployment: Custom Pages route `recruitment`, with the full file pasted into
an HTML widget in the main content area.
Current sections:
- Recruitment hero with screenshot placeholder.
- Three contributor pillars.
- Team culture panel.
- CTA linking to an applications page and Discord.
Intent:
- Explain the benefits of building with Westgate.
- Keep the pitch brief.
- Link to an applications page when that exists.
- Link to Discord immediately.
- Do not imply a full application capability exists yet.
Open data decisions:
- Final application route or placeholder route.
- Final Discord invite URL.
- Final art upload paths.
- Whether role categories stay broad or become specific to current recruiting
needs.
- Whether any old `join`, `join-the-team`, or recruitment-adjacent route should
redirect to `recruitment`.
### News And Dev Blog
Production source:
- `custom/pages/news.html`
- `custom/pages/blog.html`
Reference source: `custom_pages/westgate-pages/THEME-INTEGRATION.md`
Deployment: Custom Pages routes backed by NodeBB topic/category data.
Intent:
- News and Blog should be live NodeBB content, not duplicated static pages.
- The page index should render article cards.
- Individual topics in those categories should receive article-style treatment:
banner hero, metadata, title, author, and prose body.
- Users should not need to know the article came from a forum post.
- Discussion should remain available through a secondary link or article footer,
not as the primary presentation.
- Each article can optionally use a banner image pulled from the topic.
Canonical source categories:
- News: `cid 1`
- Blog / Developer Blog: `cid 84`
Known Blog route: `https://westgate.pw/category/84/developer-blog`
Rendering requirements:
- Index pages show cards with title, date, teaser, category label, optional
thumbnail/banner, and author.
- Article pages show an optional banner hero, title, metadata, author, and
article body.
- Article body should reuse the wiki/article prose vocabulary where possible so
News, Blog, Wiki, and forum article content stay visually aligned.
- Missing banners must degrade to a handsome text-led hero, not a broken or empty
media slot.
- The implementation should avoid exposing raw forum chrome in the main article
reading experience.
Open data decisions:
- Whether the route names are `/news` and `/blog`, or whether `/developer-blog`
also exists as a canonical or redirect route.
- How a topic declares its banner image: topic thumbnail, first image, upload
metadata, tag, or a small plugin-owned convention.
- Whether News and Blog share one rendering module with different category IDs.
### Gallery
Production source: `custom/pages/gallery.html`
Reference source: `custom_pages/westgate-pages/THEME-INTEGRATION.md`
Deployment: Custom Pages route backed by gallery asset/topic data.
Intent:
- Gallery showcases screenshots and/or art uploaded specifically for Gallery.
- The source may be forum topics, a special directory, NodeBB uploads, or a
plugin-managed asset list.
- Each item should render as a visual tile with enough metadata to feel curated.
- Category view renders as a responsive masonry-style grid.
- Topic pages remain normal unless later design work requires a custom viewer.
Open data decisions:
- Whether Gallery uses a forum category, a special upload directory, or a
plugin-owned asset registry.
- Upload and moderation workflow.
- Whether Gallery items link to topics, media lightboxes, or standalone custom
pages.
- Required metadata: title, author, date, caption, tags, source topic, or
approval state.
### Forums And Wiki
Forums should remain normal NodeBB/Harmony-derived forum pages styled by
Westgate theme overrides.
Wiki uses the custom Westgate wiki plugin, not Custom Pages. It still must stay
visually aligned with the custom pages and forums. The existing theme already
maps wiki styling through `scss/westgate/_wiki-prose.scss`, and the wiki plugin
ships layout defaults plus `--wiki-*` hooks.
Parity requirements:
- Custom page article prose and wiki article prose should converge where
possible.
- News/Blog article bodies should be close enough to wiki article bodies that a
reader sees one editorial system.
- Forum cards, wiki cards, and custom-page cards should share radius, border,
shadow, type scale, and focus behavior.
- Topbar behavior must be uniform across Custom Pages, wiki routes, and forum
routes.
## Topbar And Harmony Sidebar Migration
### Current Harmony Baseline
Harmony splits global chrome across:
- Left sidebar: ACP Navigation, dropdown navigation items, skin switcher, sidebar
toggle.
- Right sidebar: logged-in user menu, search, notifications, chats, drafts.
- Mobile bottom/top bar: mobile access to related sidebar controls.
Westgate currently inherits this model because `templates/header.tpl` imports
`partials/sidebar-left.tpl` and Harmony `footer.tpl` imports
`partials/sidebar-right.tpl`.
### Required End State
The global topbar owns the functions users previously reached through Harmony's
sidebars:
- Brand link.
- ACP Navigation items.
- Forums menu / category entry points.
- Search.
- Notifications.
- Chats, when `canChat` is true.
- Drafts.
- User avatar menu.
- User status controls.
- Profile, bookmarks, edit profile, settings.
- Moderator tools when available.
- Logout.
- Guest login and register actions.
- Mobile drawer equivalents for the same primary actions.
- Skin switcher if custom skins remain enabled.
The global layout should no longer render Harmony's left or right desktop
sidebars for normal pages. `#panel` should run as the main content column under
the topbar.
### Implementation Principles For Later
This is not implemented in this spec pass, but the later implementation should
follow these principles:
- Add a theme partial such as `templates/partials/header/topbar.tpl`.
- Mount that partial from `templates/header.tpl`.
- Stop importing `partials/sidebar-left.tpl` and `partials/sidebar-right.tpl` in
the global layout, either by overriding both header and footer or by another
clean theme-level layout change.
- Move topbar SCSS into a focused Westgate partial such as
`scss/westgate/_topbar.scss`; import it from `theme.scss`.
- Prefer topbar-specific local partials copied from Harmony sidebar partials only
where the markup must change. Preserve NodeBB component hooks such as
`component="notifications/list"`, `component="chat/list"`,
`component="drafts/list"`, `component="drafts/open"`,
`component="drafts/delete"`, `component="header/usercontrol"`, and
`component="search/form"`.
- Keep Bootstrap dropdown behavior if reusing Harmony's existing client logic.
- If markup cannot preserve Harmony's selectors, update the theme client script
intentionally instead of relying on accidental sidebar selectors.
- Do not duplicate live notification/chat/draft data with static mock rows in
production.
- Ensure the topbar is present on Custom Pages, wiki plugin routes, and standard
forum routes.
### Harmony JavaScript Compatibility Risks
`public/harmony.js` currently assumes sidebar selectors in several places:
- Composer sizing offsets from `.sidebar-left`.
- Sidebar toggle persistence via `[component="sidebar/toggle"]`.
- Search focus via `[component="sidebar/search"]`.
- Draft rendering via `[component="sidebar/drafts"]` and
`[component="drafts/list"]`.
- Notification/chat placeholder cloning via `nav.sidebar`.
- Sidebar tooltip setup via `.sidebar`, `.sidebar-left`, and `.sidebar-right`.
- `#main-nav` overflow adjustment for left sidebar dropdowns.
The implementation must either keep compatible hooks in the topbar or replace
these assumptions with topbar-aware behavior. This is the main technical risk in
the topbar migration.
## Acceptance Criteria
For this design to be ready for implementation planning:
- The repository has a clear source-of-truth distinction between raw Claude
Design exports, reference Custom Pages modules, and tracked `custom/`
production sources.
- The five required custom pages have named production files under `custom/`.
- Static Custom Pages can be installed without relying on Harmony sidebars.
- Dynamic Custom Pages have a documented data ownership path through NodeBB
forum content and/or local plugins.
- The global topbar spec accounts for every current Harmony sidebar user
function, including logged-out and logged-in states.
- News and Blog use forum categories `1` and `84` as canonical content while
presenting as website articles.
- Gallery is explicitly left open where its source model is not yet thoroughly
specced.
- Recruitment is renamed from Join the Team to `recruitment.html` and does not
pretend application functionality exists yet.
- Wiki and forums are covered by the same parity requirements as Custom Pages.
- Routes, asset paths, and live-data integrations are listed as decisions instead
of being silently assumed.
- No generated files are promoted to tracked production assets without an
explicit decision.
## Open Decisions
- Should `custom_pages/` remain untracked reference material, or should selected
QA screenshots be tracked separately?
- Should the global topbar first ship as a theme partial, or temporarily as
Custom Content HTML/JavaScript for faster visual validation?
- Should the skin switcher remain available? If yes, it needs a topbar/user-menu
home.
- Should `sidebar-footer` widget content be deprecated, moved to a real footer,
or exposed somewhere else?
- Should Harmony's mobile bottom/top bar remain enabled after the Westgate
topbar mobile drawer exists?
- What are the final route names and redirects for Home, Recruitment, News,
Gallery, Wiki, Forums, Blog, and Developer Blog?
- What is the canonical Gallery source model?
- What data convention marks a News/Blog topic banner image?
- Which plugin, if any, owns applications when recruitment needs an application
flow?
- Which page screenshots should become QA references, and which are obsolete?
## Non-Goals For This Pass
- No template overrides are implemented here.
- No SCSS is moved or added.
- No Custom Pages content is installed.
- No category IDs are changed.
- No `custom/` production files are created in this investigation-only pass.
- No generated image or screenshot assets are promoted.
- No commits or pushes are made by this draft.