feat: add prelaunch site controls and refresh branding

docs/DEPLOYMENT.md

@@ -121,6 +121,46 @@ existing embedded-database connection instead of opening the locked database
 from a second process. The endpoint runs automated system messages, Oversight
 consolidation, and email digest checks and is not published through a host port.
 
+## Prelaunch operation
+
+The launch-control migration creates `site_launch_settings` with these defaults
+for a database that does not contain the row:
+
+- Coming Soon: enabled
+- Account creation: enabled
+- News, Database, Builds, Guides, and Builder: enabled
+
+The migration uses an insert-if-missing seed. Later deployments preserve the
+operator's settings, and configuration changes take effect without a restart.
+A full environment bootstrap copies the source row. Canonical ISAC game-data
+imports leave the target environment's launch settings unchanged.
+
+Use this operator flow after the first deployment:
+
+1. Open `/sign-in`; the launch gate keeps that route available.
+2. Sign in with an existing Administrator account.
+3. Open ISAC → System Configuration → Site Controls.
+4. Set account creation and public-section availability.
+5. Review the complete change set, then confirm it.
+6. Use `PREVIEW PAGE` to inspect `/coming-soon` with the authenticated
+   `ENTER FULL SITE` return action. The preview lists each section's current
+   availability.
+7. Verify `/coming-soon` and the affected public routes in a signed-out browser
+   session before public release. Sign in and verify the same disabled routes
+   remain unavailable.
+
+Keep Coming Soon enabled while preparing production. Section controls can be
+set in advance because the launch gate takes precedence for signed-out traffic.
+Set Account Creation to Disabled if prelaunch access must remain limited to
+existing identities. Switch the Launch Gate to Public Launch after verification.
+Disabled sections remain absent from navigation and unavailable by direct URL
+for every user, including authenticated agents. Authentication bypasses only
+the Coming Soon gate.
+
+Turn Coming Soon on to restore the promotional gate. Site-control changes append
+`system_configuration / site_access.updated` audit events, including the
+operator and complete before/after settings.
+
 ## Initial development-data bootstrap
 
 Initialize the first staging release from the development database, including

docs/DESIGN_SYSTEM.md

@@ -1,9 +1,10 @@
 # SHD.build Design System
 
-This document defines the visual language for SHD.build, the independent
-Division Resurgence community for builds, guides, game data, news, and
-discussion. New pages use the same tactical intelligence network as the admin
-dashboard. Public pages may use more space and larger editorial typography.
+This document defines the visual language for SHD.build, an independent
+Division Resurgence data-and-tools site for builds, guides, game data, news,
+and discussion. New pages use the same tactical intelligence network as the
+admin dashboard. Public pages may use more space and larger editorial
+typography.
 
 ## Design principles
 
@@ -16,6 +17,43 @@ dashboard. Public pages may use more space and larger editorial typography.
    underlines. Communicate hover and focus through SHD accent color, borders,
    brightness, and the required focus-visible outline.
 
+## Brand identity
+
+SHD.build uses the two-color Core Segments identity. The emblem combines the
+orange Division signal with ISAC's analytic role in the product:
+
+- Three unequal Signal Orange arc segments form the outer circle. Each segment
+  has square ends.
+- The widest break sits in the upper-right quadrant and contains one detached
+  Signal Orange square, which represents a data packet.
+- A Field Manual White open square forms the ISAC core at the center.
+
+Keep the emblem in Signal Orange and Field Manual White on Operations Black,
+Terminal Black, or another approved dark surface. SHD.build has no one-color
+emblem. Do not close the arc gaps, equalize the segments, remove the data
+packet, fill the ISAC core, add letters to the emblem, or recolor either part.
+Use a dark holding surface or omit the emblem when a placement cannot reproduce
+both colors.
+
+The standard lockup pairs the emblem with the heavy angular `SHD.build`
+wordmark. Set `SHD` in Field Manual White and `.build` in Signal Orange. Place
+the uppercase descriptor `RESURGENCE DATA & TOOLS` below the wordmark in
+restrained telemetry type. Do not substitute another descriptor.
+
+Use the complete lockup in the 76px global header and shared footer. The header
+uses a 38px emblem; keep the wordmark and descriptor compact enough to preserve
+the navigation grid. Mobile headers may use the emblem alone when the complete
+lockup would crowd navigation. Favicons and app icons use the emblem without
+text. Small-size artwork must retain both colors, widen the arc gaps where the
+pixel grid requires it, and keep the packet and open core distinct.
+
+Treat the emblem as decorative when visible `SHD.build` text names the product.
+Give an emblem-only home link the accessible name `SHD.build home`. Preserve
+the approved colors and full opacity in focus, disabled, and compact contexts;
+use text or control styling to communicate state instead of fading the mark.
+The Field Manual White core and Signal Orange arcs must remain distinct from
+their background at every delivered size.
+
 ### Routed error console
 
 Expected HTTP errors and unexpected server faults use one shared SHD exception
@@ -64,19 +102,18 @@ from the orange links reserved for SHD navigation and legal resources. Support
 and legal links form a compact horizontal rail that may wrap at intermediate
 widths and becomes a two-column touch-friendly grid on narrow mobile screens.
 
-The footer repeats the complete SHD brand lockup used by the global header:
-double-ring SHD mark, white `SHD`, orange `.build`, and the restrained
-`RESURGENCE COMMUNITY` descriptor. Do not substitute a plain text wordmark or
-color the complete product name orange.
+The footer repeats the complete Core Segments lockup used by the global header:
+two-color emblem, Field Manual White `SHD`, Signal Orange `.build`, and the
+`RESURGENCE DATA & TOOLS` descriptor. Do not substitute a plain text wordmark,
+drop either emblem color, or color the complete product name orange.
 
-### Community platform positioning
+### Platform positioning
 
-SHD.build is a Division Resurgence community. Primary product language and
-global navigation represent five durable
-channels: News, Database, Builds, Guides, and Builder. Loadout-specific terms
-remain appropriate inside build routes, but the global brand descriptor,
-homepage metadata, hero, sign-in introduction, and footer describe the broader
-community platform.
+SHD.build provides Division Resurgence data and tools for players. Primary
+product language and global navigation represent five durable channels: News,
+Database, Builds, Guides, and Builder. Loadout-specific terms remain
+appropriate inside build routes. The global brand descriptor, homepage
+metadata, hero, sign-in introduction, and footer describe the broader toolset.
 
 The homepage uses a community-channel grid to establish this information
 architecture. Each channel has an operational code, plain-language purpose,
@@ -265,9 +302,10 @@ explains it.
 At viewports up to 900px, replace the hidden desktop link rail and account
 controls with a labeled square `MENU` control in the shared site
 header. Activating it opens a right-side SHD navigation panel over a dismissible
-backdrop. The panel includes Home, Discover, Builder, Guides, Sign In or My
-Profile, and ISAC when authorized; authenticated agents also receive identity
-state and Sign Out inside the panel.
+backdrop. The panel includes Home, each enabled public destination, Sign In or
+My Profile, and ISAC when authorized. Authenticated agents also receive identity
+state and Sign Out inside the panel. Section availability controls both desktop
+and mobile navigation.
 
 Use numbered full-width navigation rows, explicit active-route text styling,
 orange action indicators, and minimum 44px interaction targets. Opening moves
@@ -294,6 +332,53 @@ squeezed beside long module headings on mobile.
 - Community build cards retain the colored top rule, abstract loadout artwork,
   concise tags, agent attribution, and a full-width terminal action.
 
+### Prelaunch network shell
+
+Use the standalone prelaunch shell for `/coming-soon`. It replaces the global
+application shell while the public launch gate is active, so visitors see one
+clear deployment message instead of navigation into gated sections. Keep the
+SHD.build mark, a visible network-state block, one primary access action, the
+Discord community action, the deployment manifest, and legal links. Signed-out
+visitors receive `AGENT SIGN IN`; an authenticated operator previewing the page
+receives `ENTER FULL SITE`.
+
+The desktop composition pairs the launch statement with a technical network
+visual. Use the shared grid background, square borders, restrained orange
+emphasis, and telemetry labels. Orange identifies the primary action and active
+signal paths. Green may reinforce a staged or available state; red may reinforce
+an unavailable channel. Every state also needs a text label.
+
+The deployment manifest lists News, Database, Builds, Guides, and Builder with
+plain-language descriptions. A visitor who follows a disabled-section URL sees
+the affected section name in a status notice. The page must state whether new
+agent registration is open without implying that sign-in for existing accounts
+has closed. The manifest uses the saved section controls as its source of truth
+and marks unavailable sections in text. An authenticated preview follows the
+same availability states.
+
+At widths below 900px, stack the launch statement above the network visual and
+collapse the manifest to one column as space requires. Preserve 44px action
+targets and keep status text within the viewport. Reduce the radar sweep and
+other ambient motion under `prefers-reduced-motion`; retain the static rings,
+nodes, and labels.
+
+ISAC Site Controls use three connected command panels: Launch Gate, Account
+Creation, and Public Sections. Use `SegmentedChoice` for each finite state.
+Display the pending-change count outside the panels and require a confirmation
+modal that lists every changed setting as previous state, arrow, and proposed
+state. A successful save closes the modal and refreshes the network-state
+summary. Keep a `PREVIEW PAGE` link in the command toolbar so authenticated
+operators can inspect the promotional page without ending their session.
+Operators need text for enabled, disabled, coming-soon, and public states; color
+supports those labels.
+
+The Launch Gate controls signed-out entry to the application. Public Section
+controls apply to everyone. When an operator disables News, Database, Builds,
+Guides, or Builder, remove that destination from global navigation for signed-in
+and signed-out users and block its route family on the server. The promotional
+page identifies a disabled destination when a user follows an old bookmark or
+direct URL. Do not present authentication as a way around a disabled section.
+
 ### Agent and authentication surfaces
 
 - Account pages should read as an agent dossier: identity and access at the top,
@@ -390,6 +475,11 @@ squeezed beside long module headings on mobile.
 - Authentication uses one unified access screen rather than separate sign-in and
   registration destinations. Verified email and first-time OAuth identities may
   create an account; returning identities sign into the matching account.
+- With account creation disabled, keep returning-agent methods available, hide
+  the password `CREATE ACCOUNT` mode, and show a concise registration-state
+  notice. Provider and email controls must explain that unknown identities
+  cannot create an account without suggesting that existing identities lost
+  access.
 - Password access uses an explicit `SIGN IN` / `CREATE ACCOUNT` mode switch
   inside the fallback panel. Account creation separates the public display name
   from the private ASCII login username.

docs/architecture.md

@@ -42,6 +42,47 @@ provide a persistent writable filesystem and can override the location with
 `TDR_DATABASE_PATH`. This rules out ephemeral serverless filesystems unless a
 persistent volume is attached.
 
+## Site launch controls
+
+The singleton `site_launch_settings` row stores the public launch gate, account
+creation state, and availability for News, Database, Builds, Guides, and
+Builder. Schema migration creates the row with Coming Soon enabled, account
+creation enabled, and all five sections enabled. The application caches the row
+for five seconds and clears the process cache after an operator saves changes.
+
+Agents with `site.settings.manage` edit the row from ISAC → System
+Configuration → Site Controls. The save action requires an explicit value for
+all seven controls and a confirmation token. A successful update records
+`system_configuration / site_access.updated` with the operator, target row, and
+complete before/after snapshots.
+
+The request hook applies the launch gate to anonymous traffic and section
+availability to every request:
+
+- With Coming Soon enabled, anonymous `GET` and `HEAD` requests redirect to
+  `/coming-soon`. Anonymous mutations outside exempt routes receive a JSON 404.
+- Authenticated agents bypass the Coming Soon gate and enter the application.
+- A disabled public section blocks its route family for every user, including
+  authenticated agents: `/news`, `/database`, `/builds`, `/guides`, or
+  `/builder`. `GET` and `HEAD` requests redirect to `/coming-soon` with the
+  unavailable section identified. Mutations receive a JSON 404.
+- Authentication callbacks, sign-in, contact, legal pages, health endpoints,
+  scheduler endpoints, application assets, and the prelaunch page remain
+  reachable without a session.
+
+The global navigation omits disabled sections for every user. Server checks
+remain authoritative for direct URLs and mutations. An authenticated operator
+may open `/coming-soon` to preview the promotional page, but the preview does
+not override section availability.
+
+Account creation uses a separate control. Closing registration blocks password
+registration, a magic-link request for an unknown email, and Discord OAuth for
+an unknown Discord identity. Existing password, email, and Discord identities
+can still sign in. The sign-in page hides the password registration form and
+explains registration closure. This guard runs on the server, so a crafted form
+submission or OAuth callback cannot create an account while registration is
+closed.
+
 ## Increment plan
 
 1. Product shell and anonymous local-draft builder.