diff --git a/docs/superpowers/specs/2026-06-26-global-topbar-design.md b/docs/superpowers/specs/2026-06-26-global-topbar-design.md new file mode 100644 index 0000000..893b557 --- /dev/null +++ b/docs/superpowers/specs/2026-06-26-global-topbar-design.md @@ -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. diff --git a/docs/superpowers/specs/2026-06-26-website-pages-design.md b/docs/superpowers/specs/2026-06-26-website-pages-design.md new file mode 100644 index 0000000..de317fa --- /dev/null +++ b/docs/superpowers/specs/2026-06-26-website-pages-design.md @@ -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 ``, +``, 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.