# 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 ← , 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; /* 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 ``-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. `` 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 `` 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 `` (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** (`` 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 = ``. 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 ``, 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} — SlimCore ``` ### 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 `` 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: `` 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.