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.

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

@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

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

/* 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.
  Ihr Land.
  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

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)

<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)

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:

{
  "@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.