2026-06-26 08:00:06 +00:00
2 changed files with 704 additions and 0 deletions
@@ -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.
@@ -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.