Initial: extract brand system as standalone repo
This commit is contained in:
Pascal Oelmann
commit
d15c05ee13
3 changed files with 396 additions and 0 deletions
1
.gitignore
vendored
Normal file
1
.gitignore
vendored
Normal file
|
|
@ -0,0 +1 @@
|
|||
.DS_Store
|
||||
21
README.md
Normal file
21
README.md
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
# digiFORMER Brand System
|
||||
|
||||
Verbindliche Marken-, Stack- und Vendor-Politik der digiFORMER GmbH.
|
||||
Single Source of Truth für alle digiFORMER-Sites und -Produkte.
|
||||
|
||||
## Verwendung als Submodule
|
||||
|
||||
Dieses Repo wird in andere digiFORMER-Repos als Git-Submodule unter
|
||||
`docs/brand-system/` eingebunden. Site-Repos lesen `brand-system.md`
|
||||
ausschließlich — Änderungen passieren nur in diesem Repo.
|
||||
|
||||
## Sites, die dieses Brand System nutzen
|
||||
|
||||
- `digiformer/digiformer-website` (digiformer.de)
|
||||
- `digiformer/slimcore-website` (slimcore.io)
|
||||
|
||||
## Update-Workflow
|
||||
|
||||
1. Änderung hier committen und pushen
|
||||
2. In den Site-Repos: `git submodule update --remote docs/brand-system`
|
||||
3. Im Site-Repo den neuen Submodule-Commit als Bump committen
|
||||
374
brand-system.md
Normal file
374
brand-system.md
Normal file
|
|
@ -0,0 +1,374 @@
|
|||
# digiFORMER Brand System
|
||||
|
||||
> **Stand:** 2026-05-04 · **Inhaber:** digiFORMER GmbH · **Pflege:** Pascal Oelmann
|
||||
> **Geltungsbereich:** Mutterbrand digiFORMER und alle Produktmarken (SlimCore, trendscout, SlimSafe, künftige).
|
||||
> **Zweck:** Diese Datei ist die Single Source of Truth für Farben, Typografie, visuelles Vokabular und Markenarchitektur. Jedes Repo, das eine Markenoberfläche produziert, importiert die Tokens aus dem (geplanten) Paket `@digiformer/design-tokens` — bis das existiert, kopiert man die Werte aus diesem Dokument.
|
||||
|
||||
---
|
||||
|
||||
## 1. Markenarchitektur
|
||||
|
||||
### 1.1 Beziehung zwischen Mutterbrand und Produkten
|
||||
|
||||
digiFORMER ist eine **Beratungs- und Umsetzungs-Marke**. SlimCore, trendscout, SlimSafe und alle weiteren Produkte sind **eigenständige Produktmarken unter dem digiFORMER-Dach**. Das Verhältnis folgt dem **Adobe-Modell**: der Mutterbrand sorgt für Stabilität und Vertrauen in formellen Kontexten (Pitch-Decks, Verträge, Vorstandsgespräche), die Produktmarken dürfen jeweils eigene laute Persönlichkeiten haben und werden nicht visuell mit dem Mutterbrand verschmolzen.
|
||||
|
||||
Konsequenz: Wenn auf einer SlimCore-Site „ein Produkt der digiFORMER GmbH" steht, ist das eine *Quellenangabe*, kein visuelles Hauptmotiv. SlimCore trägt seine eigene Akzentfarbe, nicht die von digiFORMER.
|
||||
|
||||
### 1.2 Was die Familie verbindet
|
||||
|
||||
Die Familienzugehörigkeit wird **nicht über Farbe** hergestellt, sondern über drei andere Ebenen, die auf jeder Site identisch sind:
|
||||
|
||||
1. **Typografisches System** — Source Serif 4 für Headlines, Inter für Body, JetBrains Mono für technische Marker. Skalen, Gewichte und Sentence-case-Regeln gleich.
|
||||
2. **Strukturelles Vokabular** — nummerierte Sektionen (`01`–`04`), Mono-Eyebrows in Tertiärfarbe, Editorial-Layout mit viel Weißraum, eine Akzentfarbe statt Farbflächen-Show.
|
||||
3. **Status-Glyphen** — `●` `◐` `○` `◌` werden überall identisch genutzt (siehe §5).
|
||||
|
||||
Was die Familie unterscheidet: jede Marke hat genau eine eigene Akzentfarbe (siehe §3).
|
||||
|
||||
---
|
||||
|
||||
## 2. Markenarchitektur-Regeln
|
||||
|
||||
### 2.1 Naming
|
||||
|
||||
- Mutterbrand: **digiFORMER** (Camel-Case, das `digi` immer klein, `FORMER` immer groß). Die GmbH-Form heißt **digiFORMER GmbH**.
|
||||
- Produktmarken: **SlimCore**, **trendscout**, **SlimSafe** — jeweils Camel-Case ohne Leerzeichen. `slimcore.io` (Domain) wird kleingeschrieben, im Fließtext aber `SlimCore`.
|
||||
- Niemals: „Cockpit", „digiFORMER Cockpit", „Slim Core" (mit Leerzeichen), „Trend Scout", „Slim Safe".
|
||||
|
||||
### 2.2 Sub-Branding-Verbote
|
||||
|
||||
- Kein Produktlogo darf das digiFORMER-Logo als Element enthalten
|
||||
- Keine Site nutzt zwei Akzentfarben gleichzeitig
|
||||
- Kein Theme-Switcher zwischen Marken-Akzentfarben innerhalb einer Site
|
||||
- Wenn ein Produkt einen Footer-Hinweis auf den Mutterbrand braucht, dann als kleiner Text-Link: `ein Produkt der digiFORMER GmbH`, nicht als farbiges Banner
|
||||
|
||||
### 2.3 Mutterbrand-zu-Produkt-Verlinkung
|
||||
|
||||
- digiFORMER-Site verlinkt auf alle Produkt-Sites unter `/digitools` (so bereits umgesetzt)
|
||||
- Produkt-Sites verlinken im Footer auf `digiformer.eu`, nicht auf andere Produkte (Cross-Linking zwischen Produkten ist Phase 2, wenn mehrere live sind)
|
||||
|
||||
---
|
||||
|
||||
## 3. Farbsystem
|
||||
|
||||
### 3.1 System-Logik
|
||||
|
||||
Alle Markenfarben des Systems liegen auf einem **gleichmäßig verteilten Farbkreis** mit **gleicher Sättigungs-Energie** („elektrisch-mutig"). Damit:
|
||||
|
||||
- ist jede Farbe von jeder anderen klar unterscheidbar
|
||||
- entsteht keine versehentliche Hierarchie zwischen Marken
|
||||
- harmonieren alle Farben, wenn sie nebeneinander auftreten
|
||||
- bleibt Raum für künftige Produkte ohne Restrukturierung
|
||||
|
||||
Es gibt **8 Slots** auf 360°. Vier sind aktiv besetzt, vier sind Reserve.
|
||||
|
||||
### 3.2 Aktive Markenfarben
|
||||
|
||||
| Marke | Rolle | OKLCH | Hex (≈) | Hue |
|
||||
|---|---|---|---|---|
|
||||
| **digiFORMER** | Beratung & Umsetzung | `oklch(0.78 0.16 215)` | `#06D8FF` | 215° (Electric Cyan) |
|
||||
| **SlimCore** | Geschäftssoftware | `oklch(0.71 0.22 38)` | `#FF6B2C` | 38° (Electric Persimmon) |
|
||||
| **trendscout** | Trend-Radar für E-Commerce | `oklch(0.62 0.25 350)` | `#E91E63` | 350° (Magenta) |
|
||||
| **SlimSafe** | Sicherheit & Compliance* | `oklch(0.86 0.22 130)` | `#A3E635` | 130° (Lime) |
|
||||
|
||||
*SlimSafe-Rolle ist Arbeitsannahme, bis das Produkt sich weiter konkretisiert.
|
||||
|
||||
### 3.3 Reserve-Slots für künftige Produkte
|
||||
|
||||
Vier weitere Slots auf dem Farbkreis sind reserviert. Bei einem neuen Produkt wird einer davon belegt — geleitet vom inhaltlichen Charakter, nicht von Reihenfolge.
|
||||
|
||||
| Slot | OKLCH | Hex (≈) | Hue | Charakter / passend für |
|
||||
|---|---|---|---|---|
|
||||
| **R1 — Acid Yellow** | `oklch(0.86 0.20 85)` | `#FACC15` | 85° | Schnell, sichtbar, kreativ — Marketing-/Content-/UGC-Werkzeuge, Kampagnen-Tools |
|
||||
| **R2 — Mint** | `oklch(0.74 0.15 165)` | `#14B8A6` | 165° | Ruhig, klar, sauber — Wartungs-, Admin-, Monitoring-, Wellness-Tools |
|
||||
| **R3 — Cobalt** | `oklch(0.50 0.22 265)` | `#2D52FF` | 265° | Vertrauen, Autorität — Finanz-, Recht-, Compliance-fokussierte Tools |
|
||||
| **R4 — Electric Violet** | `oklch(0.55 0.25 295)` | `#7C3AED` | 295° | AI, Intelligenz — Analytik-, ML-, Knowledge-Tools |
|
||||
|
||||
**Regel zur Belegung:** Slots werden in der Reihenfolge des Charakters zugewiesen, nicht in der Reihenfolge der Produkt-Launches. Wenn das nächste Produkt z. B. ein Audit-Tool ist, bekommt es Cobalt — nicht Acid Yellow nur weil das die niedrigste Slot-Nummer ist.
|
||||
|
||||
### 3.4 Hover- und Soft-Varianten
|
||||
|
||||
Für jede Markenfarbe gibt es zwei zwingende Begleit-Werte:
|
||||
|
||||
```
|
||||
Base — Vollton, für CTAs, Status-Highlights, primäre Marken-Anwendungen
|
||||
Hover — etwa 15–20% dunkler als Base, für Button-Hover und :active
|
||||
Soft — Base mit Alpha-Wert 0.10–0.12, für seltene Surface-Tints
|
||||
(z. B. „aktive Filter-Pille" oder Notification-Hintergrund)
|
||||
```
|
||||
|
||||
Beispiel SlimCore (Electric Persimmon):
|
||||
|
||||
```css
|
||||
--brand-slimcore: oklch(0.71 0.22 38); /* #FF6B2C */
|
||||
--brand-slimcore-hover: oklch(0.62 0.23 38); /* #E04F0F */
|
||||
--brand-slimcore-soft: oklch(0.71 0.22 38 / 0.12); /* tint */
|
||||
```
|
||||
|
||||
**Hue-Justage-Hinweis:** Electric Persimmon wurde 2026-05-04 von einem ursprünglichen `#EC5C29` (L 0.66 / C 0.19) auf den heutigen Wert kalibriert, um die perceptive Helligkeit an Cyan (L 0.78) und Lime (L 0.86) anzunähern. Dadurch entsteht ein in sich konsistentes Familienfoto, in dem keine Marke „dunkler" wirkt als die anderen.
|
||||
|
||||
### 3.5 Farb-Anwendungs-Regeln (gelten für jede Marken-Site)
|
||||
|
||||
- **Eine Akzentfarbe pro Site.** Niemals zwei Markenfarben in einer Oberfläche. Wenn eine SlimCore-Site auf ein digiFORMER-Cluster verlinkt, bleibt der Link in SlimCore-Persimmon — nicht in digiFORMER-Cyan.
|
||||
- **Akzent ist knapp.** Akzentfarbe wird ausschließlich verwendet für:
|
||||
- primäre CTA-Buttons (Background)
|
||||
- Hover-States auf Links
|
||||
- Focus-Rings bei Form-Elementen
|
||||
- 1–2 hervorgehobene Wörter in der Hero-Headline (optional, sparsam)
|
||||
- aktive Nav-Indikatoren (z. B. unterstrichene aktive Sektion)
|
||||
- Status-Pille „aktuelle Phase" auf der Roadmap
|
||||
- **Akzent wird NICHT verwendet für:**
|
||||
- Karten-Hintergründe (außer in seltenen Fällen mit `-soft`-Variante)
|
||||
- Body-Text-Farbe
|
||||
- Border auf Karten (außer fokussierten/aktiven)
|
||||
- Status-Dots der Modul-Liste (siehe §5 — Status-Glyphen sind monochrom)
|
||||
- Diagramme/Charts — diese nutzen die Tailwind-`c-`-Ramp-Klassen, nicht Akzentfarben
|
||||
- **Auf hellem Hintergrund:** Base-Variante. Auf fast-schwarzem Hintergrund (invertierter Hero): gleiche Base-Variante — unsere Markenfarben sind so gewählt, dass sie auf beiden Untergründen funktionieren.
|
||||
|
||||
### 3.6 Konstrast-Mindestwerte
|
||||
|
||||
Jede Akzentfarbe muss mit ihrem definierten Kontrastpartner (siehe §3.7) WCAG AA erreichen:
|
||||
|
||||
- Body-Text auf Akzent-Background: ≥ 4.5:1
|
||||
- Large Text (≥18px bold oder ≥24px regular) auf Akzent-Background: ≥ 3:1
|
||||
- UI-Komponenten und Border: ≥ 3:1
|
||||
|
||||
Wenn eine Akzentfarbe diese Werte mit Standard-Schwarz/-Weiß nicht erreicht, ist die definierte Text-on-Accent-Farbe aus §3.7 verbindlich.
|
||||
|
||||
### 3.7 Text-on-Accent (Vordergrund auf farbigem Hintergrund)
|
||||
|
||||
| Marke | Text-on-Accent (Hex) | Begründung |
|
||||
|---|---|---|
|
||||
| digiFORMER (`#06D8FF`) | `#003845` | Cyan ist hell — schwarzer Text wirkt zu hart, dunkles Petrol harmoniert |
|
||||
| SlimCore (`#FF6B2C`) | `#2A0F02` | Electric Persimmon ist heller als der ursprüngliche Wert — weißer Text fällt unter WCAG-AA. Dunkles Persimmon-Schwarz erreicht 9:1 (AAA) und macht den Button visuell entschiedener |
|
||||
| trendscout (`#E91E63`) | `#FFFFFF` | Magenta ist dunkel genug für weißen Text |
|
||||
| SlimSafe (`#A3E635`) | `#2A3D08` | Lime ist sehr hell — schwarzer Text zu hart, dunkles Olivgrün harmoniert |
|
||||
| R1 Acid Yellow (`#FACC15`) | `#3D2E00` | Yellow extrem hell — dunkles Braun |
|
||||
| R2 Mint (`#14B8A6`) | `#FFFFFF` | dunkel genug für Weiß |
|
||||
| R3 Cobalt (`#2D52FF`) | `#FFFFFF` | dunkel genug für Weiß |
|
||||
| R4 Violet (`#7C3AED`) | `#FFFFFF` | dunkel genug für Weiß |
|
||||
|
||||
---
|
||||
|
||||
## 4. Typografie (familienweit)
|
||||
|
||||
Identisch über alle Marken-Oberflächen.
|
||||
|
||||
### 4.1 Font-Stacks
|
||||
|
||||
```css
|
||||
--font-serif: "Source Serif 4", Georgia, serif;
|
||||
--font-sans: "Inter", system-ui, sans-serif;
|
||||
--font-mono: "JetBrains Mono", ui-monospace, monospace;
|
||||
```
|
||||
|
||||
Alle drei Schriften sind unter SIL OFL lizenziert und werden **self-hosted** ausgeliefert (keine Google-Fonts-CDN — DSGVO).
|
||||
|
||||
### 4.2 Hierarchie
|
||||
|
||||
| Rolle | Familie | Größe | Gewicht | Letter-Spacing | Line-Height |
|
||||
|---|---|---|---|---|---|
|
||||
| Display (Hero) | Serif | 48–56px | 500 | -0.015em | 1.05 |
|
||||
| H1 | Serif | 32–40px | 500 | -0.015em | 1.10 |
|
||||
| H2 | Serif | 24–32px | 500 | -0.005em | 1.20 |
|
||||
| H3 | Serif | 20px | 500 | 0 | 1.30 |
|
||||
| Body Lead | Sans | 17px | 400 | 0 | 1.55 |
|
||||
| Body | Sans | 16px | 400 | 0 | 1.65 |
|
||||
| Body small | Sans | 13px | 400 | 0 | 1.55 |
|
||||
| Eyebrow | Mono | 11px | 500 | 0.08em | 1.20 (uppercase) |
|
||||
| Caption | Mono | 11px | 400 | 0.04em | 1.35 |
|
||||
|
||||
### 4.3 Regeln
|
||||
|
||||
- **Sentence case** überall. Niemals Title Case. ALL CAPS nur für Mono-Eyebrows.
|
||||
- **Maximal zwei Gewichte:** 400 regular + 500 medium. Niemals 600 oder 700.
|
||||
- **Niemals mid-sentence bolding.** Hervorhebungen sind Sache der Akzentfarbe oder kursiver Schrift.
|
||||
- **Maximale Zeilenbreite:** 60–70 Zeichen (`max-w-[65ch]`) für Fließtext.
|
||||
- **Mono für „technisch":** Stack-Bezeichnungen, Status-Labels, Sektions-Nummern (`01`/`02`), Versions-Marker, Timestamps.
|
||||
- **Serif für „inhaltlich":** Headlines, eventuell Pull-Quotes, Editorial-Pull-Outs.
|
||||
|
||||
---
|
||||
|
||||
## 5. Status-Glyphen (familienweites visuelles Vokabular)
|
||||
|
||||
Diese vier Glyphen sind das wichtigste sekundäre Marken-Asset — sie ziehen sich durch jede Marken-Site und schaffen Wiedererkennbarkeit auch dann, wenn die Akzentfarbe wechselt.
|
||||
|
||||
| Glyph | CSS | Bedeutung | Farbe |
|
||||
|---|---|---|---|
|
||||
| ● | gefüllter Kreis | Verfügbar / live / produktiv | `--color-text-primary` |
|
||||
| ◐ | halbgefüllt (Opacity 0.45) | In Entwicklung / aktiv im Bau | `--color-text-primary` mit α 0.45 |
|
||||
| ○ | solider Outline-Kreis | Geplant / feste Roadmap | `--color-text-tertiary` |
|
||||
| ◌ | gestrichelter Outline-Kreis | Vision / Richtung | `--color-text-tertiary`, dashed |
|
||||
|
||||
**Wichtig:** Status-Dots sind **monochrom**, nicht in der jeweiligen Markenfarbe. Sie sind Teil des familienweiten Vokabulars und sollen über alle Marken hinweg identisch lesbar sein. Die Markenfarbe lebt anderswo (CTAs, Hover, Hervorhebungen).
|
||||
|
||||
Implementierung als CSS — niemals Emoji oder Bibliotheks-Icons.
|
||||
|
||||
---
|
||||
|
||||
## 6. Surface-Token (familienweit)
|
||||
|
||||
Auf allen Marken-Oberflächen identisch:
|
||||
|
||||
```css
|
||||
--color-bg-base: oklch(0.99 0.005 90); /* ~#FBFAF7 — warm off-white */
|
||||
--color-bg-surface: oklch(1.00 0 0); /* white für Karten */
|
||||
--color-bg-inverse: oklch(0.18 0.01 270); /* ~#1A1B22 — fast schwarz, leicht kühl */
|
||||
|
||||
--color-text-primary: oklch(0.20 0.01 270); /* ~#1F2128 */
|
||||
--color-text-secondary: oklch(0.45 0.01 270); /* ~#5C5F6B */
|
||||
--color-text-tertiary: oklch(0.60 0.01 270); /* ~#8B8E97 */
|
||||
|
||||
--color-border: oklch(0.90 0.005 90); /* ~#E2E0DA */
|
||||
--color-border-strong: oklch(0.80 0.005 90);
|
||||
```
|
||||
|
||||
Dark Mode invertiert die Surface- und Text-Token, behält aber die Markenfarben unverändert (sie sind in OKLCH so gewählt, dass sie in beiden Modi funktionieren).
|
||||
|
||||
---
|
||||
|
||||
## 7. Vendor- und Stack-Politik
|
||||
|
||||
Diese Sektion ist verbindlich für alle Repos, Marken-Oberflächen und produktiven Systeme unter dem digiFORMER-Dach. Sie hat die gleiche Verbindlichkeit wie die Farbsystem- und Typografie-Regeln — ein Verstoß ist kein Stil-Lapsus, sondern ein Bruch der Markenbotschaft.
|
||||
|
||||
### 7.1 Harte Regel
|
||||
|
||||
> **Jeder Vendor im kritischen Daten- oder Anwendungspfad muss eine Hauptniederlassung in DE, CH, AT oder EU haben UND in EU-Rechenzentren operieren. Keine Ausnahmen.**
|
||||
|
||||
Konsequenzen, die jedes Projekt-Briefing reflektieren muss:
|
||||
|
||||
- Personenbezogene Daten — auch IP-Adressen, User-Agents, Browser-Fingerprints — dürfen nicht an US-Anbieter übermittelt werden, auch nicht über deren EU-Töchter. Die CLOUD-Act-Exposition wird durch Tochter-Strukturen nicht aufgehoben.
|
||||
- Build-Pipelines, Deployment-Infrastruktur, CDN, DNS und Bot-Schutz folgen derselben Regel — was die Site ausliefert, den Build orchestriert oder Traffic terminiert, ist Teil des Pfades.
|
||||
- Schriftarten, Icons, JS-Libraries werden self-hosted ausgeliefert, niemals von US-CDNs eingebunden.
|
||||
- Wenn eine Funktion nur über einen US-Anbieter verfügbar wäre, fällt die Funktion weg oder wird selbst gebaut.
|
||||
- Open-Source-Komponenten von US-Entwicklern oder US-Firmen (z. B. React, Next.js, Tailwind, Source Serif 4) sind erlaubt, solange sie self-hosted ausgeliefert werden und keine Telemetrie an die Mutter-Org senden.
|
||||
|
||||
### 7.2 Whitelist — bestätigte aktive Vendors
|
||||
|
||||
| Vendor | Sitz | Rechenzentren | Funktion |
|
||||
|---|---|---|---|
|
||||
| Hetzner Online GmbH | DE (Gunzenhausen) | DE, FI | Hosting, VPS, DBs, Object Storage |
|
||||
| OVHcloud SA | FR (Roubaix) | EU-weit | Hosting-Alternative |
|
||||
| Brevo (Sendinblue SA) | FR (Paris) | FR | Transactional Mail |
|
||||
| Vivid Money S.A. | LU (Luxemburg) | LU, DE | Geschäftskonto, Payments |
|
||||
| Adyen N.V. (via Vivid) | NL (Amsterdam) | EU | Karten-Acquiring (indirekt über Vivid) |
|
||||
| Zitadel | CH (Zürich) | EU | Auth |
|
||||
| Coolify / Dokploy | OSS (selbst gehostet) | — | Deployment-Layer auf Hetzner/OVH |
|
||||
| Garage | OSS (selbst gehostet) | — | Object Storage (Multi-DC-Cluster) |
|
||||
| PostgreSQL | OSS | — | Datenbank |
|
||||
| PostgREST | OSS | — | API-Schicht |
|
||||
|
||||
### 7.3 Greylist — geprüft EU-konform, aber Rolle noch nicht final entschieden
|
||||
|
||||
Diese Vendors erfüllen die harte Regel und kommen für eine konkrete Anforderung in Frage. Bei jeder neuen Anforderung wird hier geprüft, bevor eine externe Suche gestartet wird.
|
||||
|
||||
| Vendor | Sitz | Mögliche Rolle |
|
||||
|---|---|---|
|
||||
| Friendly Captcha GmbH | DE (München) | Bot-Schutz (kommerziell) |
|
||||
| Altcha | OSS (kein Drittanbieter) | Bot-Schutz (self-hosted) |
|
||||
| mCaptcha | OSS (kein Drittanbieter) | Bot-Schutz (self-hosted) |
|
||||
| Pirsch Analytics GmbH | DE | Web-Analytics |
|
||||
| Plausible Insights OÜ | EE (Estland) | Web-Analytics |
|
||||
| Mollie B.V. | NL (Amsterdam) | Subscription-Billing für Phase 3 |
|
||||
| Bunny.net (BunnyWay d.o.o.) | SI (Slowenien) | CDN |
|
||||
| Mailgun EU / Postmark EU | EU-Region | Mail-Alternative falls Brevo nicht reicht |
|
||||
| INWX GmbH / united-domains | DE | Domain-Registrar |
|
||||
|
||||
**Aktuell offene Greylist-Entscheidungen:**
|
||||
- Bot-Schutz: Friendly Captcha (kommerziell, einfach zu integrieren) vs. Altcha (self-hosted, keine Drittpartei) vs. nur Honeypot + Rate-Limit (kein Captcha)
|
||||
- Analytics: Pirsch vs. Plausible vs. keiner (Privacy-Premium)
|
||||
- CDN: Bunny vs. Hetzner-direkt-Auslieferung (für statische Sites oft ausreichend)
|
||||
|
||||
### 7.4 Blacklist — ausdrücklich ausgeschlossen
|
||||
|
||||
Diese Anbieter sind nicht in den Stack aufzunehmen. Auch ihre EU-Töchter sind ausgeschlossen, weil die Mutter-Konzern-Struktur die CLOUD-Act-Exposition nicht aufhebt.
|
||||
|
||||
| Anbieter | Grund |
|
||||
|---|---|
|
||||
| Vercel Inc. | US-Headquarter |
|
||||
| Netlify Inc. | US-Headquarter |
|
||||
| Cloudflare Inc. | US-Headquarter — DNS, CDN, Pages, R2, Turnstile, alle Produkte |
|
||||
| Amazon Web Services | US-Headquarter |
|
||||
| Google Cloud Platform | US-Headquarter |
|
||||
| Microsoft Azure | US-Headquarter (außer Übergangs-Realität GitHub, siehe §7.5) |
|
||||
| Stripe Inc. | US-Headquarter |
|
||||
| Supabase Inc. | US-Headquarter |
|
||||
| Firebase / Firestore | Google-Mutter, US |
|
||||
| HubSpot Inc. | US-Headquarter |
|
||||
| Pipedrive | mehrheitlich US-übernommen |
|
||||
| Twilio / SendGrid | US-Headquarter |
|
||||
| Mailchimp / Intuit | US-Headquarter |
|
||||
| Google reCAPTCHA | US-Headquarter |
|
||||
| hCaptcha (Intuition Machines) | US-Mutterkonzern |
|
||||
| Google Analytics | US-Headquarter |
|
||||
| Google Fonts (als CDN) | US-Headquarter — Schriften self-hosten erlaubt |
|
||||
| Calendly | US-Headquarter (siehe §7.5 Übergang) |
|
||||
| Typeform | ursprünglich ES, mehrheitlich US-Investoren — Fall-by-Fall-Prüfung; Default ausgeschlossen |
|
||||
| Notion / Airtable | US-Headquarter |
|
||||
| Slack | Salesforce-Mutter, US |
|
||||
|
||||
### 7.5 Übergangs-Realitäten
|
||||
|
||||
Manche Vendors sind heute im Einsatz, weil sie historisch gewachsen sind oder noch keine geeignete EU-Alternative für die exakte Funktion existiert. Diese Übergänge sind explizit dokumentiert und mit einem Auflösungs-Pfad versehen. Sie tauchen nicht in der Whitelist auf und sind kein Präzedenzfall für neue Entscheidungen.
|
||||
|
||||
| Übergang | Heute | Ziel | Auflösung bis |
|
||||
|---|---|---|---|
|
||||
| Calendly | Termin-Buchung über externen Link (kein Embed) | SlimCore-eigenes Termin-Modul | Phase 2 SlimCore-Roadmap |
|
||||
| GitHub | Code-Hosting für öffentliche / leichtgewichtige Repos | Forgejo / Gitea selbst gehostet auf Hetzner | offen, vor erstem Production-Secret-Rollout |
|
||||
| GitHub Actions | CI für die Marketing-Site und SlimCore-App | Forgejo Actions + Self-hosted-Runner auf Hetzner | parallel zur GitHub-Migration |
|
||||
|
||||
Wenn weitere Übergänge entdeckt werden, gehören sie hierher — nicht stillschweigend in den Stack.
|
||||
|
||||
### 7.6 Anwendung in Briefs
|
||||
|
||||
Jedes Repo-CLAUDE.md, jede neue Marken-Site, jedes neue Produkt-Briefing referenziert §7.1–7.4 als verbindlich. Bei jeder Default-Empfehlung („nimm Vercel", „nimm Stripe") muss der Brief diese gegen die Listen prüfen, bevor sie übernommen wird. Bei Konflikt zwischen einer einzelnen Empfehlung und dieser Politik gewinnt diese Politik.
|
||||
|
||||
---
|
||||
|
||||
## 8. Implementierung
|
||||
|
||||
### 8.1 Heutige Lösung (Phase 1)
|
||||
|
||||
Jedes Repo definiert die benötigten Marken-Token in seinem eigenen `global.css` als Tailwind-v4-`@theme`-Block. Werte werden aus diesem Dokument kopiert.
|
||||
|
||||
### 8.2 Mittelfristig (Phase 2)
|
||||
|
||||
Geplant: ein npm-Paket `@digiformer/design-tokens`, das alle Marken-Token, Surface-Token, Typografie-Variablen und Status-Glyph-CSS exportiert. Jede Marken-Site importiert nur die für sie relevanten Marken-Token, plus alle familienweiten Token.
|
||||
|
||||
Repo-Struktur (Vorschlag):
|
||||
|
||||
```
|
||||
@digiformer/design-tokens/
|
||||
├── package.json
|
||||
├── README.md
|
||||
├── src/
|
||||
│ ├── colors.css ← alle Marken + Surfaces als CSS-Variables
|
||||
│ ├── typography.css ← Font-Stacks + Skalen
|
||||
│ ├── glyphs.css ← Status-Dot-Klassen
|
||||
│ └── tokens.json ← maschinenlesbar für Tooling
|
||||
└── dist/ ← gebaut
|
||||
```
|
||||
|
||||
### 8.3 Langfristig (Phase 3, Vision)
|
||||
|
||||
Token-Studio-Anbindung an Figma, automatische Sync zwischen Design-Files und Code.
|
||||
|
||||
---
|
||||
|
||||
## 9. Wann diese Datei aktualisiert wird
|
||||
|
||||
- Bei jeder Belegung eines Reserve-Slots durch ein neues Produkt — Eintrag von §3.3 nach §3.2 verschieben, Rolle dokumentieren
|
||||
- Bei jeder Re-Tonung einer aktiven Markenfarbe — alte Werte als Kommentar erhalten, Migration-Datum notieren
|
||||
- Bei jeder Erweiterung der Reserve (z. B. zweite Acht-Slot-Schicht für einen zweiten Saturationslevel) — ist heute nicht geplant, kommt nur falls die ersten 8 Slots belegt sind
|
||||
|
||||
---
|
||||
|
||||
## 10. Referenzen
|
||||
|
||||
- digiFORMER-Site (Mutterbrand-Tonalität): https://digiformer.lovable.app
|
||||
- SlimCore-Marketing-Site: in Entwicklung, Repo `slimcore-marketing`
|
||||
- trendscout-Marketing-Site: noch nicht begonnen
|
||||
- SlimSafe-Marketing-Site: noch nicht begonnen
|
||||
|
||||
---
|
||||
|
||||
**Ende des Brand-System-Dokuments.** Bei Konflikten zwischen diesem Dokument und einer einzelnen Repo-Konfiguration gewinnt dieses Dokument.
|
||||
Loading…
Reference in a new issue