| Production Defaults |
In any case ThreatSea relies on external sources like configuration variables etc. to determine its behaviour, it should either check if the external input is complete and correct and file an error if not, or default to production values. Defaults shall never be development values. In either case, precautions have to be taken that a safe state is reached. Counterexamples are connecting to the production backend or database from a test system or having the system endlessly trying to connect to an unconfigured database. |
Following the architectural principle of fail-safe defaults |
Decided |
17 Dec 2024 |
| Development or Debug Code |
The production build of ThreatSea shall never contain code only meant to run in development environments but not in production. On the same note, ThreatSea code should behave the same way in all environments. This is at least mandatory for preproduction and production. Deviating behaviour shall never be controlled by side effects (e.g. reading NODE_ENV) but explicitely (e.g. by dedicated environment variables like LOG_LEVEL). |
To guarantee tests cover production code, reduce complexity and attack surface, avoid intransparent dependencies and have fail-safe defaults. |
Decided |
17 Dec 2024 |
| Translations |
Each translation has to be maintained at one unique location. Translations must be structured in the following file structure: de common methodology_terms.de.js → includes 4x6 specific terminology like attack point names general.de.js → includes general terminology like "OK", "Abbrechen", "Speichern" additional required files, e.g. is_classification.de.js for information classification scheme pages apply-measure-dialog-page.de.json → specific terminology required for the "Apply Measure" dialog en common ... pages ... |
Avoiding duplicate translations |
Decided |
17 Feb 2025 |
| Color Design Tokens |
Colors are defined in /src/view/wrappers/color-tokens.ts as a two-layer token model. Primitives (colorPrimitives) are raw rgba values named by hue and scale (e.g. brand.blue900, neutral.gray100); they are the single source of truth and are never imported by components. Semantic aliases (colors) are intent-based names (e.g. text.default, surface.paper, border.focus) that map onto primitives and are wired into the MUI palette in theme.wrapper.tsx. Components consume color exclusively through the theme via theme.vars.palette. with CSS variables enabled, so values resolve to CSS custom properties; hardcoded color literals and direct token imports are disallowed and enforced by a no-restricted-imports lint rule. A small, documented set of exceptions covers runtimes that cannot read CSS variables — the Konva editor canvas, which uses literal theme.palette. values, and the @react-pdf/renderer report subtree — plus theme.wrapper.tsx itself. Full reference: apps/frontend/src/view/wrappers/THEME.md. |
Single source of truth for color; separates raw values from design intent so the palette can evolve without a wide refactor; keeps theming consistent through MUI; and lint enforcement prevents drift back to hardcoded literals. Enables future color-scheme and theming work, since CSS variables and colorSchemes are already enabled. |
Decided |
12 Jun 2026 |