slimcore-website/CLAUDE.md

# SlimCore Marketing Site — Implementation Brief

> **Stand:** 2026-05-04 · **Autor:** Pascal Oelmann (mit Claude Chat) · **Adressat:** Claude Code
> **Aufgabe:** Implementierung der Marketing-/Landing-Webseite für SlimCore unter `slimcore.io`.
> Diese Datei ist die Steuerungsquelle für alle Entscheidungen. Bei Konflikten gewinnt diese Datei gegenüber Default-Annahmen oder Lovable-Vorlagen.

---

## 0. TL;DR für Claude Code

- **Stack:** Astro 6 (Static Site, SEO-first) + Tailwind v4 + selektive React-Islands für interaktive Komponenten + shadcn/ui-Primitives + TypeScript strict.
- **Domain:** `slimcore.io` = Marketing. `app.slimcore.io` = SaaS-App (separates Repo, nicht Teil dieses Briefs).
- **Positionierung:** Primärgruppe sind Solo-Selbstständige und kleine Teams (1–10). Sekundär wachsende KMU bis ~30. Tertiär eCommerce-Händler. Hero-Linie: **„Schlank starten. Grenzenlos wachsen."**
- **Familienzugehörigkeit:** SlimCore ist eine eigenständige Produktmarke unter dem digiFORMER-Dach (Adobe-Modell, nicht Atlassian-Modell). Familien-Anker sind Typografie + nummerierte Sektionen + Status-Glyphen — NICHT die Farbe. Jede Marke hat genau eine eigene Akzentfarbe.
- **Akzentfarbe SlimCore:** Electric Persimmon `#FF6B2C` (`oklch(0.71 0.22 38)`). Definiert im familienweiten Markensystem (siehe `digiformer-brand-system.md`). Text-on-Accent ist `#2A0F02` (dunkles Persimmon-Schwarz), nicht Weiß — Kontrast-Grund.
- **Nicht verhandelbar:** Eine Akzentfarbe (kein Theme-Switcher). Umlaute. Sentence case. Keine US-Marketing-Klischees. Vision-Features als Vision benennen, nicht als verfügbar verkaufen.
- **Inhaltlicher Master:** `produktbeschreibung.pdf` (im Repo unter `/docs/produktbeschreibung.pdf`). Diese CLAUDE.md übersetzt das in Code-Anweisungen — nicht alle Inhalte werden hier wiederholt.
- **Markensystem-Master:** `digiformer-brand-system.md` regelt Farben, Typografie, Status-Glyphen und Markenarchitektur. **§7 ist die verbindliche Vendor- und Stack-Politik** (DE/CH/AT/EU-Headquarter + EU-Rechenzentren, Whitelist/Greylist/Blacklist). Bei Konflikten zwischen CLAUDE.md und Brand-System gewinnt das Brand-System. Bei Default-Empfehlungen wie „nimm Vercel" oder „nimm Stripe" prüft Claude Code immer zuerst Brand-System §7.4 — diese Vendors sind ausgeschlossen.

---

## 1. Mission

SlimCore ist die schlanke, modulare Geschäftssoftware für Solo-Selbstständige und kleine Teams — souverän in Europa gehostet, ohne Abhängigkeit von US-Konzernen, ohne Vendor-Lock-in. Die Marketing-Site muss drei Aufgaben erfüllen:

1. **Tester gewinnen.** Primärer Conversion-Funnel ist die Tester-Anmeldung. Phase 1 läuft jetzt.
2. **Glaubwürdigkeit aufbauen.** Souveränitäts-Versprechen ist Differenzierung — muss visuell und sprachlich substantiell wirken, nicht wie Marketing-Geschwurbel.
3. **Produkt verständlich machen.** 16 Module in 4 Säulen, mit klaren Status-Markierungen. Solo-Selbstständige und kleine Teams sollen in unter 30 Sekunden erkennen, ob SlimCore zu ihrer Situation passt — und ob es mit ihnen wachsen kann.

**Zentrales Versprechen:** „Schlank starten. Grenzenlos wachsen." — der Wachstums-Aspekt ist neuer Kern-USP gegenüber bisheriger Positionierung.

**Sekundär:** SEO-Sichtbarkeit für Suchanfragen wie „CRM für Solo-Selbstständige", „Geschäftssoftware Solo", „ERP Alternative DSGVO", „Odoo zu komplex", „CRM Made in Germany", „SaaS Hetzner Hosting".

---

## 2. Architektur-Entscheidung

### 2.1 Warum Astro statt Next.js / Vite-SPA

Die SlimCore-Web-App selbst läuft auf Vite + React + TanStack. Für die **Marketing-Site** sind die Anforderungen aber andere:

| Anforderung | Gewinner |
|---|---|
| SEO (statisches HTML, schnelles First Paint) | Astro (SSG by default) |
| Geringe Bundle-Größe für Marketing | Astro (ships zero JS by default) |
| MDX für späteren Blog/Notizen | Astro (eingebaut) |
| React-Komponenten wo nötig (Forms, Roadmap-Toggle) | Astro Islands (`client:load`, `client:visible`) |
| Tailwind v4 Kompatibilität | Astro (offizieller Adapter) |
| Tooling-Vertrautheit | beide ok |

Astro ist die richtige Wahl, weil 90 % der Site statisch ausgeliefert werden können. Interaktive Inseln (Tester-Formular, Roadmap-Filter, Modul-Tabelle mit Filter) werden als React-Islands punktuell hydriert.

### 2.2 Domains

- `slimcore.io` — Marketing-Site (dieses Repo)
- `app.slimcore.io` — SaaS-App (anderes Repo, existiert)
- `slimcore.io/login` → 301 Redirect auf `app.slimcore.io/login`
- `slimcore.io/app` → 301 Redirect auf `app.slimcore.io`

### 2.3 Hosting

Statisches Build-Output wird auf einem **Hetzner-VPS** ausgeliefert, mit **Coolify** als Deployment-Layer. Build- und Deploy-Pipeline läuft über Forgejo Actions (oder GitHub Actions als Übergangs-Realität, siehe Brand-System §7.5).

Vercel, Netlify, Cloudflare Pages und alle anderen US-gehosteten Static-Site-Plattformen sind **nicht zulässig** — siehe Brand-System §7.4. Die Marketing-Site einer Marke, deren Kernversprechen Souveränität ist, kann nicht auf US-Infrastruktur stehen, ohne sich beim ersten DNS-Lookup einer technisch versierten Tester-Person selbst zu widerlegen.

Alternativ-Host: **OVHcloud** (FR) als zweite Option, falls Hetzner-Kapazitäten ausgeschöpft oder Pascal aus anderen Gründen wechseln möchte.

**Default-Annahme für SlimCore-Marketing:** Hetzner-VPS in Falkenstein (Konsistenz mit der App-Hosting-Region), Coolify als Deployment-Orchestrator, Caddy oder nginx als Reverse-Proxy mit Auto-TLS via Let's Encrypt. Statisches Astro-Build-Output direkt aus dem Build-Container deployt.

### 2.4 Form-Handling

Tester-Anmeldungen gehen **direkt an die SlimCore-App-API**, nicht an einen externen Form-Service:

- **Primär (festgelegt):** POST an `https://app.slimcore.io/api/public/leads` (siehe `slimcore-go-to-market.md` §3 für die Spezifikation). Lead landet sofort im digiFORMER-Mandanten als CRM-Eintrag, dem Operator-Tenant für SlimCore.
- **Brevo** wird nur als Transactional-Mail-Provider für die Double-Opt-In-Bestätigung verwendet — nicht als Lead-Speicher. Brevo bekommt keine Lead-Daten zur Verwaltung; die SlimCore-App rendert die DOI-Mail und versendet sie über Brevo SMTP.
- **Kein Supabase**, kein Formspree, kein HubSpot, kein Typeform — Souveränitäts-Konsistenz mit dem Rest des Stacks.

Bot-Schutz: **Altcha** (Open Source, self-hosted Proof-of-Work-Challenge, keine Drittpartei). Plus Honeypot-Feld. Cloudflare Turnstile, reCAPTCHA und hCaptcha sind ausgeschlossen — siehe Brand-System §7.4.

---

## 3. Repo-Struktur

```
slimcore-marketing/
├── CLAUDE.md                          ← diese Datei (Implementierungs-Brief)
├── README.md
├── docs/
│   ├── digiformer-brand-system.md     ← Marken-System (Mirror — Master später als npm-Paket)
│   ├── produktbeschreibung.md         ← Inhalt-Master in Markdown (für Re-Builds)
│   ├── produktbeschreibung.pdf        ← Inhalt-Master als PDF (für Lesefluss)
│   └── design-tokens-rationale.md     ← optionale Notizen zu Designentscheidungen
├── astro.config.mjs
├── tailwind.config.ts                 ← falls Tailwind-Config-Datei nötig (v4 nutzt @theme, Datei evtl. minimal)
├── tsconfig.json
├── package.json
├── public/
│   ├── favicon.svg
│   ├── og-default.png                 ← 1200×630 OG-Bild, generiert
│   └── fonts/                         ← self-hosted (DSGVO!)
│       ├── outfit-variable.woff2
│       ├── outfit-variable-latin-ext.woff2
│       ├── jetbrains-mono-variable.woff2
│       └── jetbrains-mono-variable-latin-ext.woff2
├── src/
│   ├── styles/
│   │   └── global.css                 ← Tailwind v4 @theme + Reset
│   ├── content/
│   │   ├── module.ts                  ← Modul-Liste als typed data
│   │   └── notizen/                   ← MDX für späteren Blog
│   ├── components/
│   │   ├── primitives/                ← shadcn/ui (Button, Input, Dialog)
│   │   ├── marketing/
│   │   │   ├── NavBar.astro
│   │   │   ├── Footer.astro
│   │   │   ├── Eyebrow.astro
│   │   │   ├── SectionHeading.astro
│   │   │   ├── NumberedItem.astro
│   │   │   ├── ModuleCard.astro
│   │   │   ├── ModuleGrid.astro
│   │   │   ├── StatusDot.astro
│   │   │   ├── TechStrip.astro
│   │   │   ├── SovereigntyBlock.astro
│   │   │   ├── RoadmapTimeline.astro
│   │   │   ├── ObjectionAnswer.astro
│   │   │   └── CTABlock.astro
│   │   └── islands/                    ← React, hydriert
│   │       ├── TesterForm.tsx
│   │       ├── ModuleFilter.tsx       ← optional
│   │       └── ContactForm.tsx
│   ├── layouts/
│   │   └── BaseLayout.astro           ← <head>, NavBar, Footer
│   └── pages/
│       ├── index.astro                ← Home
│       ├── module.astro
│       ├── souveraenitaet.astro
│       ├── tester.astro
│       ├── roadmap.astro
│       ├── kontakt.astro
│       ├── impressum.astro
│       ├── datenschutz.astro
│       └── danke.astro                ← Tester-Formular Submit-Ziel
└── e2e/
    └── nav.spec.ts                    ← Playwright smoke tests
```

---

## 4. Tech-Stack-Details

### 4.1 Astro

- Astro 6.x, Output-Mode `static`.
- `@astrojs/react` für React-Islands.
- `@astrojs/sitemap` für `sitemap-index.xml`.
- `@astrojs/mdx` für `/content/notizen` (Phase 2).

### 4.2 Tailwind v4

Pascal nutzt Tailwind v4 in der App. Hier auch. Das bedeutet:

- Konfiguration über `@theme` in `global.css`, nicht via `tailwind.config.ts` (falls möglich; minimaler Config nur wenn Plugins gebraucht werden).
- Custom-Properties als Single Source of Truth — diese werden später vom App-Repo geteilt (Phase 2: design-tokens als monorepo package).

### 4.3 React-Islands

Nur dort React laden, wo Interaktivität nötig ist:

- `TesterForm` — `client:load` (oberhalb der Falte)
- `ContactForm` — `client:visible`
- `ModuleFilter` — `client:visible`, optional

Die Roadmap-Timeline ist statisches Astro-Markup, keine Hydration nötig.

### 4.4 shadcn/ui

shadcn/ui ist komponentenweise — wir installieren NUR was wir brauchen:

- `button`
- `input`
- `textarea`
- `label`
- `dialog` (für Tester-Modal von der NavBar aus)

Kein Card-Component, kein Accordion, kein Carousel. Marketing-Cards bauen wir selbst minimal mit Tailwind.

### 4.5 TypeScript

`strict: true`, `noUncheckedIndexedAccess: true`. Module-Daten in `src/content/module.ts` als `as const`-Tupel mit explizitem Type-Export.

### 4.6 Schriftarten — self-hosted (DSGVO!)

Keine Google Fonts CDN. Alle Fonts liegen in `public/fonts/` und werden über `@font-face` mit `font-display: swap` geladen. Latin + Latin-Ext jeweils per `unicode-range` getrennt, damit Latin-Ext nur bei Bedarf geladen wird.

- **Headlines + Body:** Outfit Variable (SIL OFL, kostenlos) — geometrisch-modern, single-font für die ganze Marke
- **Mono:** JetBrains Mono Variable (SIL OFL, kostenlos) — Eyebrows, Stack-Strip, Wortmarke, Sektions-Nummern, Status-Labels

**Total:** 102 KB (32 KB Outfit Latin + 15 KB Outfit Latin-Ext + 40 KB JBM Latin + 15 KB JBM Latin-Ext). Brand-System §4.1 Mai-2026-Update: Outfit ersetzt Source Serif 4 + Inter familienweit.

---

## 5. Design System

### 5.1 Markenhaltung — Familienzugehörigkeit zu digiFORMER

`digiformer.eu` ist Beratungsmarke, ruhig-editorial. SlimCore ist Produktmarke — gleiche Haltung, mehr „Werkzeugkasten-Anmutung":

| Aspekt | digiFORMER | SlimCore | Gemeinsam |
|---|---|---|---|
| Tonalität | „Erst verstehen. Dann umsetzen." | „Schlank. Souverän." | Knapp, sachlich, kein Hype |
| Hauptvisual | Lange Editorial-Fließtexte | Modul-Raster (4×16) | Nummerierte Sektionen 01–04 |
| Akzentfarbe | dezent | EINE definierte | Beide nutzen genau eine |
| Mono-Font-Einsatz | wenig | viel (Stack, Status, Eyebrows) | Mono ist Familien-Marker |
| Sprache | Deutsch primär | Deutsch primär, EN Phase 2 | DE-first |

### 5.2 Farben

> **Quelle der Wahrheit:** Alle Marken-Farbtoken stehen in `digiformer-brand-system.md`. Diese Sektion zeigt nur die SlimCore-relevanten Werte als Code-Snippet. Bei Konflikt: Brand-System gewinnt.

**SlimCore-Akzent:** Electric Persimmon `#FF6B2C` — festgelegt im Markensystem (`digiformer-brand-system.md` §3.2). Lightness 0.71 / Chroma 0.22 / Hue 38° in OKLCH. Perceptiv auf gleicher Helligkeitsstufe wie digiFORMER-Cyan und SlimSafe-Lime.

**Familien-Logik:** Mutterbrand digiFORMER trägt Electric Cyan (`#06D8FF`), SlimCore als Produktmarke trägt Electric Persimmon. Die Familien-Anker sind nicht die Farbe, sondern Typografie + Status-Glyphen + nummerierte Sektionen. Adobe-Modell, nicht Atlassian-Modell.

```css
/* SlimCore Akzent — siehe digiformer-brand-system.md §3.2 */
--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 */

/* Konvenienz-Aliasse innerhalb dieses Repos */
--color-accent:       var(--brand-slimcore);
--color-accent-hover: var(--brand-slimcore-hover);
--color-accent-soft:  var(--brand-slimcore-soft);

/* Text-on-Accent (siehe Brand-System §3.7) */
/* WICHTIG: NICHT #FFFFFF — Kontrast unter WCAG-AA bei diesem Orange */
--color-text-on-accent: #2A0F02;
```

**Restliche Tokens — Light Mode (Default), familienweit identisch:**

```css
@theme inline {
  /* Surfaces */
  --color-bg-base:        oklch(0.99 0.005 90);    /* ~#FBFAF7 — warm offwhite */
  --color-bg-surface:     oklch(1.00 0 0);          /* pure white für Karten */
  --color-bg-inverse:     oklch(0.18 0.01 270);     /* ~#1A1B22 — fast schwarz, leicht kühl */

  /* Text */
  --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 */

  /* Borders */
  --color-border:         oklch(0.90 0.005 90);     /* ~#E2E0DA */
  --color-border-strong:  oklch(0.80 0.005 90);

  /* Status-Glyphen — monochrom, NICHT in Akzentfarbe (siehe Brand-System §5) */
  --color-status-available:  var(--color-text-primary);  /* ● = filled */
  --color-status-developing: oklch(0.20 0.01 270 / 0.45);/* ◐ = halftone */
  --color-status-planned:    transparent;                /* ○ = outlined */
  --color-status-vision:     transparent;                /* ◌ = dashed */
}
```

**Dark Mode (`:root[data-theme="dark"]`)** — invertierte Surface-/Text-Tokens, Marken-Token bleiben unverändert (sie funktionieren in beiden Modi). Detail-Werte beim Implementieren ableiten.

**Wichtig — Akzent-Verwendungs-Regeln (siehe Brand-System §3.5):**

- Akzent NUR für: primären CTA, Hover-States, Focus-Rings, 1–2 hervorgehobene Worte in der Hero-Headline, aktive Nav-Indikatoren, „aktuelle Phase"-Pille auf der Roadmap
- Akzent NICHT für: Modul-Karten-Hintergründe, Status-Dots (die sind monochrom), Hero-Backgrounds, Border auf Karten, Body-Text-Farbe
- Die Akzentfarbe lebt von Knappheit. Wenn auf einer Sektion zwei Worte in Persimmon stehen, ist das viel. Drei sind zu viel.

### 5.3 Typografie

```css
/* Font-Stacks — Outfit für Headlines + Body, JetBrains Mono für technische Marker */
--font-sans:  "Outfit", system-ui, sans-serif;
--font-mono:  "JetBrains Mono", ui-monospace, monospace;
--font-serif: var(--font-sans); /* Legacy-Alias, zeigt auf Outfit */

/* Type-Scale */
--text-eyebrow:   0.6875rem; /* 11px, mono, uppercase, letter-spacing 0.08em */
--text-body-sm:   0.8125rem; /* 13px */
--text-body:      1rem;      /* 16px, line-height 1.65 */
--text-body-lg:   1.0625rem; /* 17px Hero-Lead */
--text-h3:        1.25rem;   /* 20px */
--text-h2:        1.5rem;    /* 24px (mobile) → 1.875rem 30px (desktop) */
--text-h1:        2rem;      /* 32px (mobile) → 3rem 48px (desktop) → 3.5rem 56px (xl) */
--text-display:   3rem;      /* 48px Eyecatcher (Souveränität-Block) */
```

**Regeln:**

- Headlines (`h1`, `h2`): Sans (Outfit), weight 500 (NICHT 600 oder 700), `letter-spacing: -0.01em` bei H1+, `line-height: 1.10–1.20`. Bei Hero-Highlight (Background-Stempel) darf `font-weight: 550` genutzt werden, um optische Verdünnung dunkler Schrift auf Persimmon auszugleichen.
- Body: Sans (Outfit), weight 400, `line-height: 1.65`.
- Eyebrows: Mono (JetBrains Mono), 11px, uppercase, `letter-spacing: 0.08em`, Tertiärfarbe.
- Status-Dots, Section-Numbern (`01`–`04`), Tech-Stack-Marker, Wortmarke: Mono.
- Sentence case überall. Niemals Title Case. Niemals ALL CAPS außer Mono-Eyebrows.
- Maximale Textbreite für Fließtext: 60–70 Zeichen (`max-w-[65ch]`).

### 5.4 Spacing & Grid

- Container: `max-w-[1100px] mx-auto px-6 md:px-10 xl:px-12`.
- Section-Padding vertikal: `py-20 md:py-28 xl:py-32`.
- Zwischen Hero und erster Sektion: `pt-12 md:pt-20`.
- Modul-Grid: 1 Spalte mobil, 2 Spalten tablet, 4 Spalten desktop. `gap-3 md:gap-4`.
- Numbered-Items (4er-Reihen): 1/2/4-Spalten responsive.

### 5.5 Status-Glyphen (zentrales visuelles Vokabular)

Diese 4 Glyphen ziehen sich durch die ganze Site und sind das wichtigste sekundäre Marken-Asset:

| Status | Glyph (CSS) | Bedeutung |
|---|---|---|
| Verfügbar | ● — gefüllter Kreis, primary-text | heute produktiv |
| In Entwicklung | ◐ — halbgefüllt (`opacity: 0.45` filled) | aktiv im Bau |
| Geplant | ○ — solider Outline-Kreis | feste Roadmap, noch nicht gestartet |
| Vision | ◌ — gestrichelter Outline-Kreis | Richtung, nicht Versprechen |

Implementiert als `<StatusDot status="...">`-Astro-Komponente. NICHT mit Emoji oder SVG-Icons aus Bibliotheken — eigene CSS-Lösung mit `border` und `background`.

### 5.6 Komponenten-Inventar

Custom-Komponenten (alle in `src/components/marketing/`):

- **`Eyebrow`** — Mono-Caption über Headlines. Slot: text. Optional: status (Pill-Style: „IN ENTWICKLUNG").
- **`SectionHeading`** — `h2` mit optionalem Eyebrow. Slot: subtitle.
- **`NumberedItem`** — Nummeriertes Item für Methoden/Säulen-Listen. Props: `number` (`"01"`), `title`, slot für body. Mono-Nummer in Tertiärfarbe links oben oder über dem Title.
- **`ModuleCard`** — eine der 4 Säulen-Karten mit Status-Liste. Props: `pillarNumber`, `pillarTitle`, `modules: { name: string; status: ModuleStatus }[]`.
- **`ModuleGrid`** — Wrapper, der 4 ModuleCards in Grid layoutet.
- **`StatusDot`** — atomar.
- **`TechStrip`** — horizontale Mono-Leiste mit Stack-Komponenten, Trennzeichen `·`.
- **`SovereigntyBlock`** — 2-Spalten-Layout (links Headline, rechts 4 Argumente mit Border-Left-Akzent).
- **`RoadmapTimeline`** — vertikale Linie mit 4 Phasen (Heute / Q3-Q4 2026 / 2027 / Vision). Jede Phase = Card mit Liste der Items.
- **`ObjectionAnswer`** — Frage als Serif-Quote, Antwort als Body-Text. 4 davon im Grid.
- **`CTABlock`** — Schluss-Sektion mit Headline + zwei Buttons + E-Mail-Link.
- **`NavBar`** — sticky-on-scroll. Standardmäßig auf hellem Body-Hintergrund. **Auf der Home-Seite bei Scroll-Position 0 läuft die NavBar visuell IM dunklen Hero mit** (gleicher `#0E0F14`-Hintergrund, Logo und Links in Off-White). Sobald der Tech-Strip vorbei ist und der helle Body-Bereich beginnt, wechselt die NavBar in den hellen Modus zurück. Implementierung: NavBar als `position: sticky` mit `top: 0`, der Hero-Hintergrund läuft hinter der transparenten NavBar durch — beim Scrollen wird die NavBar dann von der hellen Body-Sektion „ausgewaschen". Alternative-Implementierung: NavBar wechselt Hintergrund-Farbe per IntersectionObserver, sobald der Hero den Viewport verlässt. Beide Wege sind ok, Hauptsache: kein Hard-Cut zwischen NavBar und Hero-Hintergrund.
- **`Footer`** — 4-Spalten, dezente Border-Top, Akzent nur bei Hover-Links.

### 5.7 Buttons

```
Primary:    bg-text-primary text-bg-base, hover: bg-accent
Secondary:  border-text-primary, transparent bg, hover: bg-text-primary/5
Ghost-Link: underline-offset-4, hover: text-accent
```

Keine `rounded-full`-Mega-Pills. `rounded-md` (6–8px) reicht. Padding: `px-5 py-2.5 text-sm` für CTAs, `px-3 py-1.5 text-xs` für Sekundär.

### 5.8 Was es im Design NICHT gibt

- Keine Drop-Shadows (außer 1px-Border auf Karten). Keine Glow-Effekte. Keine Glassmorphism.
- Keine Farbverläufe/Gradients — nirgends.
- Keine animierten Hintergründe, keine Particles, keine Floating-Blobs.
- Kein Theme-Switcher zwischen Akzentfarben.
- Keine 3D-Render von Software-Mockups (auch wenn AI das schnell macht).
- Keine Stock-Fotos von „glücklichen Geschäftsleuten am Laptop".
- Keine Emoji als Icons.
- Keine bunten Icon-Badges (Material/Heroicons-Buntheit). Wenn Icons: einfarbig, Lucide-Strichstärke 1.5px, Größe 16–20px, Farbe `--color-text-secondary`.

---

## 6. Information Architecture

### 6.1 Sitemap

```
/                       Home
/module                 Alle Module mit Status, filterbar
/souveraenitaet         Long-form über Hosting, Open Source, Egress
/tester                 Tester-Programm + Anmeldeformular
/roadmap                Detail-Roadmap (verlinkt von Home-Roadmap-Section)
/kontakt                Kontaktformular + Adresse + E-Mail
/notizen                (Phase 2) Blog/Notizen, MDX-basiert
/notizen/[slug]         (Phase 2) Einzelner Notiz-Beitrag
/impressum              Pflicht
/datenschutz            Pflicht
/danke                  Tester-Form-Submit-Ziel
```

### 6.2 Navigation

**Top-Nav (Desktop):**

```
[slimcore]   Module · Souveränität · Roadmap · Tester    DE | EN    [Tester werden →]
```

- Logo links: nur Wortmarke "slimcore" in Mono, weight 500. Kein Icon-Logo (Phase 2 evtl.).
- Sprache: Mono, klein. Phase 1 nur DE aktiv, EN ausgegraut. `<a hreflang="...">` korrekt.
- CTA rechts: Primary-Button.

**Mobile:** Hamburger → Drawer (Dialog von rechts). Link-Liste, gleiche Struktur.

**Sticky-Verhalten:** NavBar ist sticky on scroll. Auf der Home-Seite ist sie bei `scrollY=0` im dunklen Hero-Modus (siehe NavBar-Komponenten-Spec in §5.6); der Übergang zum hellen Modus passiert beim Verlassen des Hero-Bereichs. Der `border-b` erscheint nur im hellen Modus und nur bei `scrollY > 8px`.

### 6.3 Footer

4 Spalten:

1. Marken-Block: Logo + 1-Zeiler + Newsletter-Hinweis (führt zu `/kontakt#newsletter` — Phase 2).
2. Produkt: Module / Souveränität / Roadmap / Tester
3. Stack: PostgreSQL / PostgREST / Docker / Hetzner DE
4. Kontakt: hallo@slimcore.io / Termin → / digiFORMER GmbH-Adresse

Bottom-Bar: `© 2026 SlimCore — ein Produkt der digiFORMER GmbH · Impressum · Datenschutz · AGB`

---

## 7. Seiten-Spezifikation

### 7.1 `/` (Home) — der Reihe nach

**1. Hero — DUNKLER HERO MIT PERSIMMON-HIGHLIGHT (verbindlich)**

> **Diese Spezifikation ist verbindlich, nicht optional.** Frühere Brief-Versionen ließen die Hero-Variante offen, was zu einer hellen Standard-Implementierung geführt hat. Die finale Entscheidung ist die dunkle Variante mit Background-Highlight auf „Grenzenlos". Bitte nicht zur hellen Variante zurückrationalisieren — die dunkle Variante ist Teil der Marken-Persönlichkeit „seriös, aber Revoluzer", und der Bruch zwischen dunklem Hero und hellen Folge-Sektionen ist gewolltes Lese-Architektur-Element.

**Hintergrund und Farben:**
- Hero-Sektion: Vollflächiger dunkler Hintergrund `#0E0F14` (fast-schwarz, leicht kühler Stich — nicht reines Schwarz)
- Headline-Text: `#F5F5F0` (warmes Off-White, kein reines Weiß — passt zum cremefarbenen Body-Hintergrund der restlichen Site)
- NavBar in der Hero-Region läuft mit dunklem Hintergrund mit; Logo, Nav-Links und Sprachwahl in Off-White mit reduzierter Opacity (0.65–0.85). Übergang zum hellen Body unterhalb des Tech-Strips.
- Hero hat KEIN Border, KEIN Frame — nahtlos voll-bleed in die Container-Breite

**Eyebrow:**
- Text: `▸ GESCHÄFTSSOFTWARE FÜR SOLO-SELBSTSTÄNDIGE UND KLEINE TEAMS`
- Schrift: JetBrains Mono, 11px, weight 500, letter-spacing 0.10em
- Farbe: `#FF6B2C` (Electric Persimmon — auf dunklem Hintergrund signalstark, nicht „dezent")
- Das vorangestellte `▸` ist verbindlich (nicht ◆, nicht •) — kleines visuelles Wiedererkennungs-Element

**H1 (Headline):**
- Text auf zwei Zeilen: „Schlank starten." auf Zeile 1, „Grenzenlos wachsen." auf Zeile 2
- Schrift: Outfit, weight 500, line-height 1.18, letter-spacing -0.015em
- Größe: clamp(38px, 5vw, 56px) — responsive, aber nicht kleiner als 38px im Hero
- Farbe: `#F5F5F0` für „Schlank starten." und „wachsen."
- **Das Wort „Grenzenlos" ist verbindlich als Background-Highlight gesetzt:**
  - Background: `#FF6B2C` (Electric Persimmon)
  - Vordergrund-Text auf dem Highlight: `#2A0F02` (dunkles Persimmon-Schwarz, nicht reines Schwarz)
  - Padding: `0.04em 0.2em 0.08em` (em-relativ, skaliert mit der Schriftgröße)
  - `display: inline-block`, `line-height: 0.95`, `font-weight: 550`, `vertical-align: baseline` — der Block hugt die Buchstaben eng, kompensiert die optische Verdünnung dunkler Schrift auf hellem Persimmon
  - KEINE rounded corners (border-radius 0) — das Persimmon-Rechteck soll wie ein Marker-Stempel wirken, nicht wie ein Pill-Button

**Lead-Paragraph:**
- Text: „Die schlanke Geschäftssoftware für Solo-Selbstständige und kleine Teams. Sie aktivieren am Anfang nur, was Sie heute brauchen — meistens CRM, Belege und Aufgaben. Wenn aus Ihnen drei werden, dann fünfzehn, schalten Sie weitere Module zu, ohne zu wechseln."
- Schrift: Outfit, 16–17px, weight 400, line-height 1.6
- Farbe: `rgba(245, 245, 240, 0.75)` (75% Opacity des Off-Whites — sekundäre Lesbarkeit ohne Kontrast-Verlust)
- Maximale Breite: ~540px (verhindert dass der Lead über die volle Container-Breite läuft)

**CTAs:**
- Primary „Tester werden →": Background `#FF6B2C`, Text `#2A0F02` (NICHT weiß — Kontrast-Grund, siehe Brand-System §3.7), border-radius `var(--border-radius-md)`, padding `11px 20px`, font-size 13px, weight 500
- Secondary „Module ansehen →": Background transparent, border `0.5px solid rgba(245,245,240,0.5)`, Text `#F5F5F0`, sonst gleich

**Vertikales Padding:**
- Hero-Sektion: `60px` oben, `48px` unten (Desktop). Auf Mobile 40px/32px.

**Übergang zur nächsten Sektion (Tech-Strip):**
- Tech-Strip läuft VISUELL noch im dunklen Hintergrund weiter (gleiches `#0E0F14`), nicht im hellen
- Border-top und border-bottom des Tech-Strips: `0.5px solid rgba(245,245,240,0.08)` (sehr dezent)
- Mono-Text im Strip in `rgba(245,245,240,0.55)`, „STACK"-Label in `rgba(245,245,240,0.85)`
- Erst die Modul-Landschaft (Sektion 3) bricht in den hellen Hintergrund — dieser Bruch ist die gewollte Lese-Architektur

**Was NICHT passieren darf:**
- Kein heller Hintergrund im Hero
- Kein Persimmon-Wort ohne Background-Highlight (nur Wort-Farbe wäre die helle-Variante-Lösung — hier ist Background-Highlight verbindlich)
- Keine rounded corners auf dem Persimmon-Rechteck
- Kein weißer Text auf dem Persimmon-Highlight (Kontrast unter WCAG-AA)
- Keine Drop-Shadows, keine Glow-Effekte, keine Gradients

**2. Tech-Strip — dunkler Hintergrund, läuft visuell vom Hero weiter**
- Hintergrund: `#0E0F14` (gleicher dunkler Wert wie Hero, kein Bruch)
- Höhe: padding `12px 32px` (vertikal niedrig, optisch eine schmale Strip-Leiste)
- Border-top und border-bottom: `0.5px solid rgba(245,245,240,0.08)`
- Inhalt: Mono, 11px, letter-spacing 0.06em, uppercase
  - `STACK` als Label in `rgba(245,245,240,0.85)`
  - Folgende Stack-Komponenten in `rgba(245,245,240,0.55)`, getrennt durch ` · ` (mit Spaces):
    `STACK · POSTGRESQL · POSTGREST · HETZNER DE · DSGVO · ZUGFERD 2.0 · DATEV`
- Mobile: gleicher Inhalt, aber mit `flex-wrap: wrap` damit die Items in mehreren Zeilen umbrechen können

**3. Modul-Landschaft (Hero-Visual)**
- Eyebrow: `VIER SÄULEN · 16 MODULE`
- H2: „Aktivieren Sie nur, was Sie heute brauchen."
- Lead (1 Satz): „Jedes Modul ist einzeln aktivierbar. Heute starten Sie mit CRM, Belegen und Aufgaben — morgen schalten Sie Versand und Team-E-Mail dazu, ohne Migration, ohne Wechsel."
- Legende mit 4 Status-Glyphen
- 4-Spalten-Grid mit `<ModuleCard>` für jede Säule (siehe Quelltext der Modul-Liste in §11 / Appendix A)
- Footer-Link: `Alle Module & Status ansehen →` führt zu `/module`

**4. Was uns trennt — drei Differenzierungen**
- Eyebrow: `WAS UNS TRENNT`
- H2: „Best-Practices der großen Tools. Bedienbar wie ein modernes SaaS."
- 3 NumberedItems (01/02/03):
  - 01 · **Schlank von Tag 1** — „Sie aktivieren das, was Sie heute brauchen — meistens CRM, Belege und Aufgaben. Kein Onboarding-Marathon, keine 27-Module-Suite, die Sie nie ausschöpfen."
  - 02 · **Wächst mit** — „Wenn aus Ihnen drei werden, dann fünfzehn, bleiben Sie in derselben Software. Team-Postfach, Lager, Versand, Workflow schalten Sie zu, wenn Sie sie wirklich brauchen — ohne Migration."
  - 03 · **Souverän** — „In Deutschland gehostet, Open-Source-Stack, Datenexport jederzeit. Keine US-Cloud, kein Vendor-Lock-in, keine Lizenzbedingungen, die nächstes Jahr neu geschrieben werden."

**5. Souveränität (das große Versprechen)**
- Eyebrow: `DAS GROSSE VERSPRECHEN`
- H2 (Display, 2-spaltig): links „Ihre Daten.<br>Ihr Land.<br>Ihre Kontrolle." | rechts: Lead + 2×2-Grid mit Border-Left-Items für Hosting / Stack / Export / Egress
- Footer-Link: `Mehr zur Souveränität →` führt zu `/souveraenitaet`

**6. Roadmap-Snapshot**
- Eyebrow: `ROADMAP`
- H2: „Heute. Bald. Vision."
- Vertikale 4-Phasen-Timeline (Heute / Q3-Q4 2026 / 2027 / Vision) mit jeweils Modul-Liste
- Footer-Link: `Detail-Roadmap →` führt zu `/roadmap`

**7. Schnell-Argumentarium (5 Einwände)**
- Eyebrow: `FÜNF EINWÄNDE, FÜNF SÄTZE`
- H2: „Antworten, die Sie sonst erst im dritten Call bekommen."
- Grid mit `<ObjectionAnswer>` (auf Mobile gestapelt, auf Desktop 2-spaltig mit ungerader letzter Zeile):
  1. „Wir sind nur zwei. Lohnt sich das?" → Genau für Sie gebaut. Drei Module zum Start, Module wachsen mit
  2. „Was, wenn wir wachsen?" → Skaliert von 1 bis ~50, dieselbe Software, mehr aktivierte Module
  3. „Wir nutzen schon HubSpot." → Lücke zwischen Pipeline und Belegen schließen, ohne HubSpot abzulösen
  4. „Odoo war zu komplex." → 80 % von Odoo, ohne Implementierungs-Overhead
  5. „Was, wenn ihr verschwindet?" → Voller Export, offenes Schema, jeder PG-Hoster führt's weiter
  - (Wortlaute aus PDF §13 — leicht angepasst, NICHT 1:1 wenn das den Lesefluss bricht.)

**8. Tester-Programm-Teaser**
- Eyebrow: `TESTER-PROGRAMM · PHASE 1`
- H2: „Sie kennen die Lücken besser als jeder Berater."
- Body: „Helfen Sie uns, die Geschäftssoftware zu bauen, die Sie hoffentlich die nächsten zehn Jahre nutzen wollen. Im Gegenzug: früher Einfluss, vergünstigte oder kostenfreie Nutzung — und ein direkter Draht ins Team."
- CTAs: `[Tester werden →]` `[hallo@slimcore.io]`

**9. Final-CTA**
- Schlanker Closer: „30 Minuten, kostenlos, unverbindlich. Sie schildern, wo Sie stehen — wir sagen ehrlich, ob SlimCore zu Ihrer Situation passt."
- Buttons: `[Tester werden →]` `[Termin vereinbaren →]`

### 7.2 `/module`

- Hero-light: Eyebrow + H1 „Module" + Lead „Was Sie aktivieren können — und in welcher Reife."
- Filter-Bar (React-Island, `client:visible`): Status-Filter (Alle / Verfügbar / In Entw. / Geplant / Vision) + Säulen-Filter (Alle / 01 / 02 / 03 / 04). Reine Client-Filterung, kein State im URL für Phase 1.
- Tabelle/Liste: pro Modul → Name, Säule, Status, 1-Satz-Beschreibung, ggf. Voraussetzungen.
- Datenquelle: `src/content/module.ts` als Single Source of Truth (siehe Appendix A).

### 7.3 `/souveraenitaet`

Long-form, MDX-fähig. Sektionen:

1. **Warum das jetzt zählt** — CLOUD Act, Schrems II, geopolitische Unsicherheit (Pascal-Tonalität: nüchtern, nicht alarmistisch)
2. **Hosting** — Hetzner, deutsches Recht, DSGVO
3. **Open-Source-Stack** — PostgreSQL, PostgREST, Traefik, Docker, React. Tabellen: Komponente → Lizenz → Anbieter
4. **Keine US-Abhängigkeiten** — Auth-Layer auf PostgreSQL-Basis (Zitadel als perspektivisches Ziel), Brevo (FR), Adress-Adapter (austauschbar), Garage Object Storage (selbst gehostet)
5. **Kein Vendor-Lock-in** — Export-Formate, offenes Schema, BuHa-API-Kompatibilität
6. **Optionaler Compliance-Layer** — Egress-Audit, Egress-Proxy

Visuelle Sprache wie auf Home: nummerierte Sektionen 01–06, viel Mono in Caption, Border-Left-Items für Listen.

### 7.4 `/tester`

- Hero: H1 „Tester-Programm · Phase 1", Lead: „Wir suchen Solo-Selbstständige und kleine Teams aus diversen Branchen — und auch ein paar wachsende KMU. Ein bewusst breites Spektrum, weil wir verschiedene Nutzungsmuster sehen wollen, bevor wir verengen."
- Sektion „Wer wird gesucht" — Liste aus PDF §10.1 (Solos/Mikroteams primär, KMU sekundär, eCommerce „willkommen, kein Muss")
- Sektion „Was Tester bekommen" — Liste aus §10.2
- Sektion „Was Tester geben" — Liste aus §10.3
- Sektion „Worauf einstellen" — Liste aus §10.4 (kursiv, ehrlicher Disclaimer)
- **Anmeldeformular** (`<TesterForm>` React-Island):
  - Felder: Firma* (mit Hint „auch Einzelunternehmen — geben Sie einfach Ihren Namen an"), Name*, E-Mail*, Telefon (optional)
  - Branche: Free-Text statt Select (kein Genre-Korsett für die Primärgruppe)
  - Team-Größe: Range-Slider 1–50, Default 3
  - „Was nutzen Sie heute?" (Textarea, kurz) — wertvoller Diagnose-Input für Pascal
  - „Was wäre die größte Lücke?" (Textarea)*
  - Honeypot-Feld + Altcha (self-hosted Proof-of-Work-Challenge, kein Drittanbieter). Verifikation serverseitig.
  - Doppel-Opt-in via Brevo
  - Submit → `/danke`
- Footer-Block mit Pascal-Tonalitäts-Zitat aus PDF §10.5

### 7.5 `/roadmap`

Detail-Version der Home-Timeline. Pro Phase: alle Module mit aktuellem Status und 1-Satz-Erläuterung. Klare visuelle Trennung „heute funktioniert" vs. „kommt vs. „Vision".

### 7.6 `/kontakt`

- Adresse digiFORMER GmbH, hallo@slimcore.io
- **Termin-Buchung:** Calendly-Link `https://calendly.com/digiformer/quick-call` — als externer Link in einem neuen Tab, NICHT als Inline-Embed. Damit kein Calendly-JavaScript / keine Cookies in der SlimCore-Domain landen — vermeidet Cookie-Consent-Pflicht.
- Kein Kontaktformular auf dieser Seite (Tester-Form ist primärer Funnel).
- **Übergangs-Hinweis:** Calendly ist Übergangslösung. Ein SlimCore-natives Termin-Buchungs-Modul ist Pascal-Roadmap-Item; sobald verfügbar, wird der Link durch dieses Modul ersetzt. Bis dahin akzeptierter Souveränitäts-Trade-off, weil Calendly nur als externer Link verwendet wird (keine Daten-Verarbeitung auf slimcore.io selbst).
- **Datenschutzerklärung:** Calendly als Datenverarbeiter erwähnen (US-Anbieter, Cookies bei Klick auf den Link), Hetzner und Brevo ebenfalls — siehe §7.7. Kein Cloudflare-Turnstile / reCAPTCHA, weil nicht im Stack.

### 7.7 `/impressum` & `/datenschutz`

- Impressum nach §5 TMG, vorbefüllen mit digiFORMER-GmbH-Daten als Platzhalter — Pascal final freigeben.
- Datenschutzerklärung: Brevo (FR), Hetzner (DE) als Auftragsverarbeiter, Calendly (US, Übergangs-Realität bis SlimCore-natives Termin-Modul). Altcha ist self-hosted und damit nicht zu nennen. Keine Analytics in Phase 1.

---

## 8. Inhaltliche Regeln & Wording

Quelle: PDF §11 + Pascal-Memory.

### 8.1 Wording-Konventionen

- **„Mandant"** statt „Tenant" oder „Workspace"
- **„Belegfluss"** statt „Document Flow"
- Umlaute schreiben — IMMER `ä/ö/ü/ß`, niemals `ae/oe/ue`
- **„KMU"** für die Zielgruppe (nicht „SMB", nicht „Mittelständler" überall)
- **„Setup-Service"** statt „Onboarding-Paket"
- **„DSGVO-konform"** ist Mindestanforderung — nicht als Verkaufsargument für sich allein
- **„SlimCore"** — nicht „Cockpit", nicht „digiFORMER Cockpit"
- **„digiFORMER GmbH"** — bei Markenangaben mit Camel-Case
- **Kein Verweis auf Personen außerhalb von Pascal Oelmann** als Kontaktperson, solange das Team nicht explizit sichtbar ist

### 8.2 Tonalitäts-Verbote

- Keine US-Marketing-Klischees: kein „supercharge", „rocket", „game-changer", „revolutionize", „reimagine"
- Keine Versprechen für Vision-Features. Vision = `<StatusDot status="vision">`. Vision wird benannt, nicht verkauft.
- Keine echten Kundennamen ohne Freigabe (Phase 1: keine Kunden-Logos auf der Site)
- Keine Vergleiche per Markenname ohne juristische Vorprüfung — bei den Einwänden im Schnell-Argumentarium ist HubSpot/Odoo OK (sind Eigenzitate aus typischen Verkaufsgesprächen, kein Vergleichsclaim)
- Kein Superlativ ohne Beleg

### 8.3 Tonalitäts-Gebote

- Klar, nicht großspurig
- Selbstbewusst, nicht arrogant
- Pragmatisch, nicht idealistisch (Souveränität ist Nutzen, kein moralisches Argument)
- Deutsch zuerst — EN folgt in Phase 2

---

## 9. Implementierungs-Phasen

Claude Code arbeitet diese Phasen sequenziell ab. Jede Phase endet mit einer Pause für Pascal-Review.

### Phase 0 — Setup (1 Session)

1. Astro-Projekt initialisieren (`pnpm create astro@latest`, Template: minimal)
2. `@astrojs/react`, `@astrojs/sitemap`, `@astrojs/mdx` installieren
3. Tailwind v4 einrichten (via Vite-Plugin, nicht via PostCSS)
4. `global.css` mit `@theme` und allen Token-Variablen anlegen (siehe §5.2/5.3)
5. Self-hosted Fonts in `public/fonts/` ablegen, `@font-face` in `global.css`
6. shadcn/ui-Setup für Astro: Button, Input, Textarea, Label, Dialog
7. `BaseLayout.astro` mit `<head>`, OG-Tags, NavBar, Footer
8. NavBar + Footer minimal funktionsfähig
9. **Pause:** Pascal überprüft Look der Layout-Hülle.

### Phase 1 — Komponenten-Bibliothek (1 Session)

10. `Eyebrow`, `SectionHeading`, `NumberedItem` — primitive Layout-Bausteine
11. `StatusDot`, `ModuleCard`, `ModuleGrid`
12. `TechStrip`, `SovereigntyBlock`, `RoadmapTimeline`
13. `ObjectionAnswer`, `CTABlock`
14. Storybook-light: `/dev/components.astro` — eine interne Seite, die alle Bausteine in allen Varianten zeigt (für visuelle Regression)
15. **Pause:** Pascal überprüft Komponenten einzeln.

### Phase 2 — Home (1 Session)

16. `index.astro` mit allen 9 Sektionen
17. Modul-Daten aus `src/content/module.ts` (Appendix A)
18. SEO-Tags, OG-Image (statisches PNG zunächst)
19. **Pause:** Pascal Review.

### Phase 3 — Module + Tester (1–2 Sessions)

20. `/module` mit Filter-Island
21. `/tester` mit Form-Island
22. App-API-Anbindung an `app.slimcore.io/api/public/leads` (siehe `slimcore-go-to-market.md` §3 für die Spezifikation). Brevo nur als Transactional-Mail-Provider für die DOI-Bestätigung.
23. Altcha-Integration (self-hosted PoW-Challenge): NPM-Paket `altcha-lib` server-seitig, `altcha`-Web-Component clientseitig. Challenge-Endpoint im Astro-Server oder direkt in der App-API. Honeypot-Feld zusätzlich.
24. `/danke` Bestätigungsseite
25. **Pause:** End-to-End-Test der Tester-Anmeldung.

### Phase 4 — Restliche Seiten (1 Session)

26. `/souveraenitaet`, `/roadmap`, `/kontakt`
27. `/impressum`, `/datenschutz` (Templates)
28. **Pause:** Inhalts-Review mit Pascal.

### Phase 5 — Polish & Deploy (1 Session)

29. Lighthouse-Run, alle Scores ≥ 95 (Performance/SEO/A11y/Best-Practices)
30. Sitemap + robots.txt
31. Open-Graph-Bild dynamisch (Satori als self-hosted Render-Library, KEIN Vercel-OG-Library-Endpoint), optional. Phase 1 reicht statisches PNG.
32. Hetzner-VPS-Deployment via Coolify, Domain-Anbindung, Caddy/nginx mit Let's Encrypt
33. Playwright-Smoke-Tests für alle Seiten
34. **Launch.**

### Phase 6 — Phase-2-Backlog (später, NICHT Teil des Initial-Builds)

- `/notizen` Blog mit MDX
- EN-Variante mit `astro-i18n` oder Manual-Routing
- Newsletter-Doppel-Opt-in über Brevo
- Status-Page-Banner („System operational")
- Pascal-„Über uns"-Mini-Sektion auf Home

---

## 10. Was Claude Code NICHT tun soll

- ❌ Ein Theme-Switcher zwischen Akzentfarben einbauen (auch nicht als Easter-Egg)
- ❌ Komplexe Animationen mit Framer-Motion / GSAP / Lottie
- ❌ Card-Hover-Effekte mit `transform` und Schatten
- ❌ shadcn-Card-Komponente nutzen — wir bauen eigene minimale Cards
- ❌ Stock-Fotos einbauen — keine Bilder von Menschen außer (Phase 2) Pascal-Portrait
- ❌ Generierte 3D-Mockups der Software (auch wenn beeindruckend)
- ❌ Google Fonts via CDN
- ❌ Google Analytics, Hotjar, Meta Pixel — Tracking-Setup ist Phase-2-Diskussion mit Pascal
- ❌ HubSpot/Pipedrive/Salesforce-Integrationen — Souveränitäts-Widerspruch
- ❌ Cookie-Banner für nicht-existente Cookies. Altcha ist self-hosted (keine Drittpartei), Brevo läuft nur als Mail-Versender (keine Cookies auf slimcore.io), keine Analytics in Phase 1 — kein Banner nötig.
- ❌ Vision-Features als verfügbar darstellen
- ❌ Erfundene Kundenstimmen oder Logo-Walls

---

## 11. Module-Daten (Single Source of Truth)

Datei: `src/content/module.ts`

```typescript
export type ModuleStatus = 'available' | 'developing' | 'planned' | 'vision';
export type Pillar = '01' | '02' | '03' | '04';

export interface Module {
  id: string;
  name: string;
  pillar: Pillar;
  pillarTitle: string;
  status: ModuleStatus;
  description: string;
}

export const modules: readonly Module[] = [
  // Pillar 01 — Kunden & Kommunikation
  { id: 'crm',         name: 'CRM',          pillar: '01', pillarTitle: 'Kunden & Kommunikation', status: 'available',  description: 'Zentrale Kontaktverwaltung mit Firmen/Personen, Interaktions-Timeline, Vertriebs-Pipeline (Kanban), Tags, Custom Fields, Massenaktionen.' },
  { id: 'team-email',  name: 'Team-E-Mail',  pillar: '01', pillarTitle: 'Kunden & Kommunikation', status: 'developing', description: 'Geteilte Postfächer über MS365 angebunden. Drei-Spalten-UI, automatische CRM-Zuordnung, Inbox-Übersicht.' },
  { id: 'helpdesk',    name: 'Helpdesk',     pillar: '01', pillarTitle: 'Kunden & Kommunikation', status: 'planned',    description: 'Aus E-Mails werden Tickets. Zuweisung, Status-Workflow, SLA-Tracking. Kein Portal-Konto nötig.' },
  { id: 'phone',       name: 'Telefonie',    pillar: '01', pillarTitle: 'Kunden & Kommunikation', status: 'planned',    description: 'Yeastar P520-Anbindung. Echtzeit-Erfassung, CRM-Zuordnung, verpasste Anrufe als Widget.' },
  { id: 'whatsapp',    name: 'WhatsApp',     pillar: '01', pillarTitle: 'Kunden & Kommunikation', status: 'planned',    description: 'WhatsApp Business API als Eingangskanal. Automatisches CRM-Matching, Timeline-Eintrag.' },

  // Pillar 02 — Handel & Logistik
  { id: 'items',       name: 'Artikel',         pillar: '02', pillarTitle: 'Handel & Logistik', status: 'developing', description: 'Stammdaten mit Varianten, Stücklisten/Bundles, Chargen-/MHD-/Seriennummern, Preislisten, EU-LMIV-Felder.' },
  { id: 'inventory',   name: 'Lager',           pillar: '02', pillarTitle: 'Handel & Logistik', status: 'available',  description: 'Lagerorte, Bestandsführung, Wareneingänge, FIFO/FEFO, MHD-Tracking, Seriennummern, mehrere Lager.' },
  { id: 'orders',      name: 'Bestellungen',    pillar: '02', pillarTitle: 'Handel & Logistik', status: 'available',  description: 'Alle Kanäle konsolidiert. Positionsverwaltung, Status-Workflow, Bezahlstatus-Tracking.' },
  { id: 'channels',    name: 'Verkaufskanäle',  pillar: '02', pillarTitle: 'Handel & Logistik', status: 'developing', description: 'WooCommerce bidirektional, Amazon SP-API kurz davor, Shopify/Kaufland/Etsy später.' },
  { id: 'shipping',    name: 'Versand',         pillar: '02', pillarTitle: 'Handel & Logistik', status: 'developing', description: 'Multi-Carrier: DHL zuerst, DPD/GLS/Hermes folgen. Label, Tracking, Shiptastic-Integration.' },
  { id: 'purchasing',  name: 'Einkauf',         pillar: '02', pillarTitle: 'Handel & Logistik', status: 'planned',    description: 'Lieferanten als CRM-Kontakte, Einkaufsbestellungen, Wareneingang mit Bestandsbuchung.' },

  // Pillar 03 — Belege & Finanzen
  { id: 'documents',   name: 'Belege',          pillar: '03', pillarTitle: 'Belege & Finanzen', status: 'available',  description: 'Konfigurierbarer Belegfluss: Angebot → AB → Lieferschein → Rechnung → Gutschrift → Mahnung. PDF-Erzeugung, Vorlagen pro Mandant.' },
  { id: 'invoices',    name: 'Rechnungen',      pillar: '03', pillarTitle: 'Belege & Finanzen', status: 'developing', description: 'Aus Bestellungen, Zeiterfassung oder manuell. ZUGFeRD 2.0 und XRechnung.' },
  { id: 'payments',    name: 'Zahlungen',       pillar: '03', pillarTitle: 'Belege & Finanzen', status: 'available',  description: 'Offene-Posten, Zahlungseingänge, Teilzahlungen, vierstufiges Mahnwesen, Liquiditäts-Widget.' },
  { id: 'accounting',  name: 'BuHa-Export',     pillar: '03', pillarTitle: 'Belege & Finanzen', status: 'available',  description: 'DATEV-CSV produktiv, sevDesk-API und Lexware-API in Vorbereitung.' },

  // Pillar 04 — Team & Organisation
  { id: 'tasks',       name: 'Aufgaben',        pillar: '04', pillarTitle: 'Team & Organisation', status: 'developing', description: 'Kanban oder Liste. Zuweisung, Fälligkeiten, Kommentare, Verknüpfung mit Kontakten/Bestellungen/Belegen.' },
  { id: 'projects',    name: 'Projekte',        pillar: '04', pillarTitle: 'Team & Organisation', status: 'planned',    description: 'Klammer um Aufgaben mit Meilensteinen und Budget-Tracking.' },
  { id: 'time',        name: 'Zeiterfassung',   pillar: '04', pillarTitle: 'Team & Organisation', status: 'planned',    description: 'Stempeluhr + Projektzeiten. Erfasste Zeiten werden auf Wunsch zu Rechnungspositionen.' },
  { id: 'hr',          name: 'Personal',        pillar: '04', pillarTitle: 'Team & Organisation', status: 'planned',    description: 'Stammdaten, Arbeitsverträge, Urlaubsanträge mit Genehmigungs-Workflow, Abwesenheitskalender.' },
] as const;
```

---

## 12. SEO & Meta

### 12.1 Globale Meta-Tags (in `BaseLayout.astro`)

```html
<title>{title} — SlimCore</title>
<meta name="description" content="{description}" />
<meta property="og:title" content="{title}" />
<meta property="og:description" content="{description}" />
<meta property="og:image" content="{ogImage ?? '/og-default.png'}" />
<meta property="og:type" content="website" />
<meta property="og:locale" content="de_DE" />
<meta name="twitter:card" content="summary_large_image" />
<link rel="canonical" href="{canonicalUrl}" />
<link rel="alternate" hreflang="de" href="{deUrl}" />
<!-- hreflang en kommt in Phase 2 -->
```

### 12.2 Default-Texte

- Site-Title: `SlimCore — Schlanke Geschäftssoftware für Solo-Selbstständige und kleine Teams`
- Site-Description: `Modulare SaaS-Plattform für CRM, Belege, Aufgaben und Workflow. Schlank starten, grenzenlos wachsen — in Deutschland gehostet, Open-Source-Stack, kein Vendor-Lock-in.`

### 12.3 Pro-Seite-Meta (Beispiele)

```ts
export const meta = {
  '/':              { title: 'Schlank starten. Grenzenlos wachsen.',       description: 'Schlanke Geschäftssoftware für Solo-Selbstständige und kleine Teams. CRM, Belege, Aufgaben — modular, in Deutschland gehostet, Open Source, kein Vendor-Lock-in.' },
  '/module':        { title: 'Module — Was Sie aktivieren können',          description: '16 Module in 4 Säulen. Was heute produktiv ist, was im Aufbau ist, was in der Roadmap steht. Aktivieren Sie heute drei, schalten Sie morgen das vierte zu.' },
  '/souveraenitaet':{ title: 'Digitale Souveränität — wie SlimCore das löst', description: 'Hetzner-Rechenzentren, Open-Source-Stack, kein US-Anbieter im Datenfluss, voller Datenexport in offenen Formaten.' },
  '/tester':        { title: 'Tester-Programm — Phase 1',                    description: 'Wir suchen Solo-Selbstständige und kleine Teams für die Tester-Phase. Früher Einfluss, vergünstigte Nutzung, direkter Draht ins Team.' },
  '/roadmap':       { title: 'Roadmap — Heute, bald, Vision',                description: 'Was heute produktiv ist, was Q3/Q4 2026 kommt, was 2027 ansteht, und wohin wir wollen.' },
};
```

### 12.4 Strukturierte Daten

`schema.org/SoftwareApplication` auf der Home als JSON-LD:

```json
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "SlimCore",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "offers": { "@type": "Offer", "priceCurrency": "EUR" },
  "publisher": {
    "@type": "Organization",
    "name": "digiFORMER GmbH",
    "url": "https://digiformer.eu"
  }
}
```

---

## 13. Performance-Budget

| Metrik | Ziel |
|---|---|
| LCP | < 1.5 s |
| CLS | < 0.05 |
| Total JS Bundle (Home) | < 50 KB nach gzip |
| Total Page Weight (Home) | < 200 KB ohne Fonts |
| Fonts | self-hosted, woff2, `font-display: swap`, subset Latin-Ext |

Astro liefert das mit Bordmitteln, solange wir keine Bilder ohne Optimierung einbauen. Alle eingebundenen Bilder über Astro's `<Image>` mit AVIF-Output.

---

## 14. Accessibility

- Alle interaktiven Elemente keyboard-erreichbar
- Focus-Ring sichtbar (2px solid var(--color-accent), offset 2px)
- Color-Contrast ≥ 4.5:1 für Body-Text, ≥ 3:1 für Large Text
- `prefers-reduced-motion` respektieren — keine Auto-Scroll-Animationen
- Form-Labels immer sichtbar (kein Placeholder-as-Label)
- `aria-describedby` für Form-Hilfetexte
- Sprache-Switcher: `<a hreflang>` korrekt gesetzt
- Heading-Hierarchie strikt: ein H1 pro Seite, dann H2 → H3, keine Sprünge

---

## 15. Referenz-URLs

- **digiFORMER (Familien-Anker):** https://digiformer.lovable.app — Tonalität, nummerierte Sektionen, Editorial-Haltung
- **Lovable-Entwurf SlimCore (Counter-Example):** https://slimcore-sparkle-design.lovable.app — was zu vermeiden ist (Theme-Switcher, zu bunt, fehlendes Modul-Visual)
- **Produktbeschreibung (Master-Quelle):** `/docs/produktbeschreibung.pdf` und `/docs/produktbeschreibung.md`
- **Markensystem (familienweit):** `/docs/digiformer-brand-system.md` — Farben, Typografie, Status-Glyphen
- **Go-to-Market-Dokument:** lebt im SlimCore-App-Repo unter `/docs/slimcore-go-to-market.md` — dort sind API-Spezifikation für `/api/public/leads`, die drei Phasen, Workflow-Templates und Payment-Provider-Strategie dokumentiert. Marketing-Site referenziert dieses Dokument für die Form-Submission-Spec.

Claude Code soll die digiFORMER-Site EINMAL pro Session als visuelle Referenz fetchen, NICHT 1:1 nachbauen — sondern die typografische Haltung übernehmen und die Modul-zentrische Eigenständigkeit von SlimCore drauflegen.

---

## 16. Glossar

| Begriff | Bedeutung |
|---|---|
| Mandant | ein Kunde von SlimCore (= Tenant) |
| Säule | eine der 4 Modul-Gruppen |
| Modul | eine funktionale Einheit (CRM, Lager, ...) |
| Belegfluss | Angebot → AB → Lieferschein → Rechnung → Gutschrift → Mahnung |
| BuHa | Buchhaltung |
| KMU | Kleine und Mittlere Unternehmen |
| Setup-Service | Bezahlte Einrichtung/Datenmigration/Schulung |
| Tester-Phase 1 | Aktuelle Programm-Stufe für Early Adopters |

---

## 17. Offene Entscheidungen (für Pascal)

Diese Punkte sind nicht final — Claude Code soll bei dem genannten Default starten und Pascal explizit auf die Stelle hinweisen, an der die Entscheidung steht.

1. **Akzentfarbe SlimCore — ✓ ENTSCHIEDEN:** Persimmon `#EC5C29`, Teil des familienweiten Markensystems. Siehe `digiformer-brand-system.md`.
2. **Hosting — ✓ ENTSCHIEDEN:** Hetzner-VPS (DE) mit Coolify als Deployment-Layer. OVHcloud (FR) als zweite Option. Vercel/Netlify/Cloudflare-Pages ausgeschlossen — siehe Brand-System §7.4.
3. **Form-Backend — ✓ ENTSCHIEDEN:** App-API (`app.slimcore.io/api/public/leads`) als primärer Endpoint. Brevo nur für Transactional-Mail. Spezifikation siehe `slimcore-go-to-market.md` §3.
4. **Termin-Buchung — ✓ ENTSCHIEDEN:** Calendly `https://calendly.com/digiformer/quick-call`, als externer Link (kein Embed). Übergangslösung bis zum SlimCore-eigenen Buchungs-Modul. Datenschutzerklärung muss Calendly nennen.
5. **OG-Image** — Phase 1: statisches PNG. Phase 2: dynamische Generierung via Satori.
6. **Cookie-Consent** — abhängig von finalem Tracking-Setup. Default Phase 1: kein Banner, weil keine Cookies, die Consent benötigen.
7. **Tokens-Paket** — Heute: Werte aus `digiformer-brand-system.md` kopieren. Später: `@digiformer/design-tokens` npm-Paket aufsetzen, wenn der dritte Marken-Build ansteht (Phase 2).
8. **Bot-Schutz — ✓ ENTSCHIEDEN:** Altcha (Open Source, self-hosted). Keine Drittpartei zwischen Tester und SlimCore — das ist die souveränitäts-konsistenteste Option. Implementiert als kleiner Server-Endpoint (Proof-of-Work-Challenge), der lokal vom Astro-Backend oder direkt von der App-API ausgeliefert wird. Plus Honeypot-Feld. Friendly Captcha bleibt Backup, falls Altcha-PoW gegen Bot-Volumen nicht reicht.
9. **Analytics — ✓ ENTSCHIEDEN:** Keine in Phase 1. Datenschutz-Premium und ein zusätzlicher konsistenter Souveränitäts-Punkt („Wir tracken Sie nicht" als Marken-Argument). Pirsch (DE) oder Plausible (EE) bleiben als Option für Phase 2, wenn Conversion-Optimierung relevant wird.
10. **Code-Hosting — ✓ ENTSCHIEDEN:** GitHub für den Start (Übergangs-Realität, siehe Brand-System §7.5). Forgejo selbst gehostet auf Hetzner als mittel-fristiges Ziel. Migration vor erstem Production-Secret-Rollout. Bis dahin: keine sensiblen Secrets in GitHub-Issues, keine privaten Kunden-Daten in Repo-Files.

---

**Ende des Briefs.** Claude Code soll diese Datei in jeder Session zuerst lesen und bei Implementierungs-Entscheidungen explizit auf Sektionen verweisen.