Implementation

Scope

Three NATO-aligned locales. All LTR Latin-script. No RTL, no CJK, no bidi handling.

English is the authoring language; French and German come from the i18n catalog (react-intl, i18next, FormatJS, per product choice). Tactical formatting stays locale-independent (24-hour Zulu, MGRS, metric); civilian formatting is locale-aware. See Accessibility → Internationalization for the full contract.

Layouts stay LTR - nothing mirrors. Adding Romance, Nordic, Slavic, or non-Latin scripts would trigger a V2 cycle.

Framework base

WebAwesome (wa-* web components) as the primitive library. Framework-agnostic - works in React, Vue, Svelte, or vanilla HTML without wrappers.

Documentation site

This design system is published as a static site at https://design.frontierdefensetech.com. Configuration, templates, and layout inherit from the existing FDT marketing-site infrastructure - not built fresh for the design system. Content lives as markdown under content/, one file per section, ordered by a weight field in frontmatter.

Token naming convention

Three prefixes, each with a clear scope:

• --wa-* - WebAwesome’s standard token namespace. Consumed by WebAwesome components. FDT’s theme file defines these.
• --fdt-* - FDT extensions that WebAwesome has no concept of: glows, tactical textures, classification semantics, breakpoints.
• --fdt-{component}-* - Component-scoped custom properties (following WebAwesome’s pattern of unprefixed component props but namespaced for clarity): --fdt-program-card-padding, --fdt-radar-sweep-duration.

Never introduce bare tokens (--navy-800, --color-primary) or use --color-* generic prefixes. The prefix is the namespace and the namespace is the contract.

Theme file structure

fdt-design/
├── theme/
│   ├── fdt-theme.css          ← Token definitions, scoped :root, .wa-dark
│   ├── fdt-theme-light.css    ← Light-mode overrides (future)
│   └── fdt-fonts.css          ← @font-face declarations
├── components/
│   ├── fdt-symbol.js          ← APP-6D tactical symbol web component
│   ├── fdt-radar-scope.js     ← Radar scope (not a WebAwesome primitive)
│   └── fdt-program-card.js    ← Optional: pre-composed program card
├── icons/
│   ├── fa-sharp-regular/      ← Self-hosted FA Pro Sharp Regular subset
│   ├── fdt-custom/            ← FDT-drawn Sharp Regular operator glyphs
│   └── fdt-icons.css          ← wa-icon family configuration
├── styles/
│   ├── fdt-glow.css           ← Glow utility classes (.fdt-glow-sm, etc.)
│   ├── fdt-texture.css        ← Grid overlay and radar ambient classes
│   └── fdt-wordmark.css       ← .fdt-wordmark class (Barlow Condensed)
└── go-fonts/                  ← Go package vending embedded fonts
    ├── inter.go
    ├── barlow-condensed.go
    └── jetbrains-mono.go

External dependencies - licenses

FA Pro and WebAwesome Pro are both organizational seats - one covers the whole design system.

Icon pipeline

• Self-host FA Sharp Regular via a Font Awesome Kit, subset to only the icons the system actually uses (tree-shaken at build time). No CDN loads - defense endpoints cannot assume external resolution.
• wa-icon configured globally to resolve from Sharp Regular: wa-icon { --family: 'sharp'; --variant: 'regular'; } in fdt-icons.css.
• FDT-custom icons follow the same SVG anatomy as FA Sharp Regular (512-unit viewBox, ~32-unit stroke) and register under the fdt- prefix.
• Maintain a canonical icon inventory (fdt-icons-inventory.md) listing every icon name used across all FDT surfaces. Additions go through review; deletions go through deprecation (marked, then removed one minor version later).

Theming posture

Dark-native is the default. All surface, text, and semantic tokens are defined against .wa-dark so WebAwesome’s dark mode is the FDT default. A future light variant would override --wa-color-surface-* and --wa-color-text-*; brand and semantic colors hold. Marketing surfaces are never light - the dark-first stance is a brand choice, not a technical limitation.

Localization scope is covered in Accessibility → Internationalization - text expansion, locale-aware number/date formatting, tactical conventions that stay locale-independent, typeface subsets for the extended Latin set, and the V2 triggers for scripts outside the supported scope.

Build pipeline

Tokens live as CSS custom properties directly - no preprocessor required. For platforms outside the web (Go PDF, Swift iOS), a Style Dictionary or similar transform consumes a single JSON source of truth (fdt-tokens.json - shipping with this site) and emits:

• fdt-theme.css (web)
• FDTTokens.swift (iOS - for QRF, GRIDWATCH iPad OPFOR AI UI)
• fdt-tokens.go (Go - for DEBRIEF PDF output, TUI tools)
• fdt-tokens.json (raw, for Figma / design tooling)

Versioning

Semver. Breaking changes to tokens are major bumps. Adding a new token is a minor bump. Value tweaks (e.g., adjusting a glow opacity) are patch bumps. Publish to internal npm as @fdt/design-system.

Framework integration

• Web (React, Vue, Svelte, HTML): Import fdt-theme.css at app root. Load WebAwesome via its autoloader or individual component imports. FDT-specific web components (fdt-symbol, fdt-radar-scope) register themselves on import.
• Swift / iOS: Consume FDTTokens.swift in SwiftUI. FDTColor.electric500, FDTSpacing.md, etc. No WebAwesome on native iOS - native components style themselves from the shared tokens.
• Go tooling (DEBRIEF, TUI): Consume fdt-tokens.go and go-fonts. folio (PDF) pulls colors and fonts directly; lipgloss (TUI) maps to the closest ANSI equivalent with the named palette as reference.

WebAwesome component overrides

FDT styling is applied via the three official WebAwesome customization mechanisms, in this order of preference:

1. Global design tokens (--wa-*) - first choice. Covers ~80% of what FDT needs.
2. Component-scoped custom properties (wa-button { --wa-button-height: ... }) - for per-component tweaks.
3. CSS parts (wa-button::part(base) { box-shadow: var(--fdt-glow-sm); }) - for FDT signatures like glow, since WebAwesome’s base components don’t ship with this.

Avoid reaching into Shadow DOM beyond documented parts. If a needed customization isn’t expressable through these three mechanisms, file an issue upstream rather than forking.