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.

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 `<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.