Webklar/docs/superpowers/specs/2026-10-01-relaunch-design.md

Relaunch webklar.com – Design-Spezifikation

• Stand: 2026-10-01
• Status: Entwurf, wartet auf Freigabe durch den Inhaber. Nach der Freigabe wird daraus ein Umsetzungsplan geschrieben (Skill superpowers:writing-plans, Ablage docs/superpowers/plans/).
• Grundlage: Prüfung der Live-Seite vom 2026-10-01 (Desktop, Handy, Texte, Code, Kundenportal, Design-Recherche) und die Wünsche des Inhabers. Die Prüfberichte selbst liegen intern; alles, was für die Umsetzung nötig ist, steht in diesem Dokument.
• Material: Deutschland-Karte und Kundenportal-Screenshots in docs/relaunch/assets/ (Übersicht: docs/relaunch/README.md).

---

1. Ziel

Wer eine Website oder eine digitale Dienstleistung sucht und auf webklar.com landet, versteht in den ersten Sekunden, wer WEBklar ist und was er bekommt. Das passiert über Bilder, Bewegung und kurze Sätze statt über Textblöcke. Die Seite wirkt modern und ruhig, mit Abständen und Typografie wie bei Apple-Produktseiten. Sie darf nicht nach KI-Vorlage aussehen, ist übersichtlich, sagt nichts doppelt und ist auf dem Handy kein Endlos-Scroll.

Erfolgskriterien

Nr.	Kriterium	Wer prüft, wie
E1	Fünf-Sekunden-Test: Eine Testperson kann danach sagen „Die bauen Websites, Shops und Apps für kleine Betriebe, und man sieht alles in einem Kundenportal.“	Inhaber, mit 2–3 Personen, die die Seite nicht kennen
E2	Startseite auf dem Handy (390 × 844) höchstens 8 Bildschirmhöhen lang (heute 14)	Umsetzung: document.documentElement.scrollHeight / innerHeight
E3	Jede Aussage steht genau einmal auf der Startseite (Regeln in 6.3)	Umsetzung: Textprüfung
E4	Heller und dunkler Modus sind beide gestaltet, alle Texte erreichen mindestens 4,5 : 1 (ab 24 px mindestens 3 : 1)	Umsetzung: Kontrastmessung im Browser und Token-Test
E5	Startseite lädt höchstens 130 KB JavaScript (gzip), kein WebGL; LCP auf dem Handy unter 2,5 s, CLS unter 0,1	Umsetzung: vite build, Lighthouse Mobile
E6	Alle Routen und Rechtsseiten funktionieren, die Texte der Rechtsseiten sind unverändert, die Rechtstext-Tests bleiben grün	Umsetzung: npm test
E7	Austausch-Test: Mit einem anderen Agenturlogo passt die Seite nicht mehr, weil Texte, Karte und Portal nur zu WEBklar passen	Inhaber, Sichtprüfung

---

2. Ausgangslage

• Technik: Vite, React 18, TypeScript, Tailwind, shadcn/ui, React Router. Reine Client-SPA. Das Kontaktformular schreibt per Appwrite-Client in eine Datenbank.
• Live-Betrieb: webklar.com wird aus einem internen Repository gebaut. Dieses Repository ist der Arbeitsort für den Relaunch; sein main ist nicht live. Was hier fertig ist, wird nach Freigabe des Inhabers übertragen (Abschnitt 12).
• Befunde der Prüfung (Kurzfassung):
  • Die Startseite erzählt dieselbe Botschaft viermal (Problem, Lösung, Nutzen-Karten, Leistungen). „Leistungen“ und „Ablauf“ sind dieselben vier Schritte, „Potenzialanalyse“ steht fünfmal da.
  • Positionierung passt nicht: Die Seite verkauft „Digitalisierung für KMU“ mit CRM, Pipeline und Kennzahlen. Tatsächlich baut WEBklar Websites, Online-Shops, Web-Apps und Automatisierungen für kleine Betriebe.
  • Vorlagen-Look: drei Schriftfamilien, vier WebGL-/Effekt-Komponenten auf fast jedem Abschnitt, cyan-blaue Akzentfarbe, Karten mit Kreis-Symbolen, hochzählende Kennzahlen, Technik-Laufband.
  • Handy: 14 Bildschirmhöhen bei rund 630 Wörtern, keine horizontale Interaktion, Hover-Effekte ohne Funktion auf Touch, Menü ohne Scrollsperre.
  • Der helle Modus war nie gestaltet (dunkle Kopfleiste auf Weiß, Pixelpunkte über Text, unsichtbare Leuchtschrift).
  • Die Startseite lädt 476 KB JavaScript (gzip), davon 232 KB nur für den 3D-Hintergrund im Hero. prefers-reduced-motion wird nirgends beachtet.
• Bereits live behoben (Sofort-Paket, 2026-10-01):
  • Kontrast im hellen Modus, Theme-Schalter klickbar, Leuchtschrift-Fehler, Anker unter der Kopfleiste.
  • Ehrliche Fakten statt „52+ Projekte“ und „99,9 %“; erfundene Referenzen und Unsplash-Bilder entfernt.
  • Eine Telefonnummer; „spätestens am nächsten Werktag“ statt „24 Stunden“; Erfolgsversprechen entschärft.
  • Footer und Rechtslinks auf allen Unterseiten (gemeinsames Layout in src/routes.tsx), Datenschutzhinweis am Kontaktformular, eigene Seitentitel, deutsche 404-Seite.
  • Tests dazu: src/test/sofort-paket.test.tsx.
• Übergangslösung: Bis zum Relaunch kann die Live-Seite fest auf „dunkel“ stehen (nicht Teil dieses Repos). Der Relaunch gestaltet beide Modi neu.

---

3. Wünsche des Inhabers

1. Die leuchtenden Überschriften („Leistungen“, „Ablauf“, „Projekte“) reagieren erst, wenn die Maus schon im Wort ist. Das muss besser werden.
2. Auf dem Handy gibt es viele Fehler, und die Seite ist nur ein langer Scroll. Beispiel: die Schritte als Karten, die man von links nach rechts wischt.
3. „So arbeiten wir“ soll raus. Stattdessen wird das Kundenportal vorgestellt, mit Screenshots aus dem Portal, durch die man scrollen bzw. wischen kann.
4. Nichts soll doppelt vorkommen.
5. Das Programmiersprachen-Laufband: Hat das heute noch Sinn?
6. „Standort Deutschland“ ist sehr wichtig, aber nicht als Etikett in der unteren Leiste. Wunsch: rechts eine Umriss-Karte von Deutschland (SVG) mit einem roten Punkt dort, wo die Server stehen.
7. Mehr mit den Texten spielen, statt sie nur hinzustellen. Modern, aber nicht nach KI aussehend. Übersichtlicher. Eine echte „Experience“. Abstände und Texte wie auf der Apple-Website.
8. Ein Interessent soll sofort und spielerisch verstehen, was WEBklar ist und macht, am besten bildlich.

Wo jeder Wunsch umgesetzt wird: 1 → D10 und 8.4 · 2 → 7.2, 7.3, 9.4, 9.6 · 3 → 7.2 · 4 → 6.3 · 5 → D8 · 6 → 7.1 · 7 → 7.1, 7.3, Abschnitt 8 · 8 → 7.1 (wechselnde Überschrift), 7.2 direkt danach (Portal-Bilder als zweiter Abschnitt).

---

4. Bereits getroffene Entscheidungen

Nr.	Entscheidung
D1	Positionierung: „Websites, Shops und Apps für kleine Betriebe“. Das Kundenportal ist der sichtbare Unterschied zu anderen Agenturen.
D2	Anrede: durchgehend „Sie“ (wie Verträge und Rechtstexte).
D3	Telefon: nur 0176 23726355 (tel:+4917623726355). E-Mail: support@webklar.com.
D4	Keine erfundenen Zahlen oder Referenzen: keine Verfügbarkeitsprozente, keine Projektzähler, keine Stockfotos und keine KI-Bilder von Personen. Referenzen nur mit Zustimmung des Kunden (AGB § 13); bis dahin gibt es keinen Projekte-Abschnitt.
D5	Antwortzeit: nur „spätestens am nächsten Werktag“ (entspricht den Abo-Bedingungen).
D6	Keine Erfolgsversprechen (AGB § 2: kein Erfolg geschuldet). SEO nur als gesondert beauftragte Leistung. Betreuung nach dem Start gibt es nur im Abo.
D7	Serverstandort: Rechenzentrum von Hetzner in Falkenstein/Vogtland, Sachsen (50,477 N, 12,371 O). Die Aussage gilt nur für Website und Kundenportal. E-Mail-Postfächer und Zahlungsabwicklung laufen anders (siehe Datenschutzerklärung). Deshalb nie „alle Daten in Deutschland“ und nie „Ihre Daten aus Sachsen“ schreiben.
D8	Das Programmiersprachen-Laufband entfällt. Es beantwortet keine Kundenfrage, und die Inhalte sind nicht belegt.
D9	„So arbeiten wir“ entfällt. Der Ablauf wird eine kompakte Schrittzeile im Kundenportal-Abschnitt.
D10	Der Leuchtschrift-Effekt entfällt. Abschnitte bekommen echte h2-Überschriften, die beim Scrollen sanft erscheinen. Das funktioniert auch auf dem Handy und für Screenreader.
D11	Heller und dunkler Modus werden beide gestaltet. Standard folgt dem System, der Umschalter sitzt in der Kopfleiste (Handy: im Menü).
D12	Vorgehen: Zuerst entsteht ein anklickbarer Entwurf der neuen Startseite (echte Seite auf einem Zweig), der Inhaber gibt Rückmeldung, danach folgt die Fertigstellung (Abschnitt 5).
D13	Die Texte der Rechtsseiten bleiben unverändert (AGB, Impressum, Wartungs-Abo, Hosting-Abo, Datenschutz-Weiterleitung). Markup und CSS-Klassen dieser Seiten dürfen für das neue Layout angepasst werden: Der eigene Kopfbereich (glass-nav-Header) entfällt, weil das gemeinsame Layout ihn liefert; Versalien, alte Schriftklassen und alte Button-Klassen werden ersetzt. Wortlaut, Reihenfolge und Gliederung der Texte bleiben gleich. Die Rechtstext-Tests müssen ohne Änderung grün bleiben.

---

5. Vorgehen in Phasen

Phase 1 – Entwurf der Startseite

• Die neue Startseite wird als echte Seite im Code gebaut (kein Wegwerf-Mockup), auf dem Zweig relaunch. Sie ersetzt src/pages/Index.tsx.
• Dazu gehören die neue Kopfleiste (6.1), alle Abschnitte aus 6.2 außer „Projekte“, der neue Footer (7.8), beide Modi, Desktop und Handy, echte Texte, echte Portal-Screenshots und die Deutschland-Karte.
• Zum Vergleich gibt es zwei Schriftvarianten (8.1), umschaltbar über ?schrift=a bzw. ?schrift=b. Der Umschalter ist nur im Entwurf vorhanden.
• Unterseiten bekommen in Phase 1 nur so viel Anpassung, dass sie mit der neuen Kopfleiste und dem neuen Footer nicht kaputt aussehen.
• Die alten Startseiten-Abschnitte bleiben noch als Dateien liegen; Phase 2 räumt sie auf.
• Tests, die alte Texte oder alte Navigationspunkte festschreiben, werden in Phase 1 angepasst (9.8). Die Prüfungen gegen verbotene Aussagen bleiben.
• Für den Inhaber gibt es eine Vorschau (O10) und Screenshots jedes Abschnitts in 1440 × 900 und 390 × 844, hell und dunkel, je Schriftvariante, im Pull Request.

Phase 2 – Fertigstellung

• Rückmeldungen des Inhabers einarbeiten und die gewählte Schrift fest einbauen; der Umschalter ?schrift wird entfernt.
• /kontakt, /ueber-uns und die 404-Seite bekommen den neuen Stil. Die Rechtsseiten bekommen nur das neue Layout (D13).
• Aufräumen (9.2), Barrierefreiheit (9.6), Leistungsbudget (E5), Browserprüfung (9.8).

Phase 3 – Livegang

• Nur mit ausdrücklichem OK des Inhabers. Übertragung ins Live-Repository (Abschnitt 12), danach Prüfung der Live-Seite.

---

6. Informationsarchitektur

6.1 Kopfleiste und Navigation

Eintrag	Ziel	Hinweis
Logo „WEBklar“	/
Kundenportal	/#kundenportal
Was wir bauen	/#leistungen
Preise	/#preise
Über uns	/#ueber-uns	Abschnitt auf der Startseite. Die ausführliche Seite /ueber-uns ist von dort und vom Footer verlinkt.
Projekte	/#projekte	erscheint nur, wenn es freigegebene Referenzen gibt
Button „Projekt besprechen“	/kontakt
Hell/Dunkel-Schalter	–

• Desktop: Alles in einer Leiste.
• Handy (unter 900 px): In der Leiste stehen nur Logo und Menü-Knopf. Der Menü-Knopf ist ein echter button mit aria-expanded und mindestens 44 × 44 px groß.
• Menü-Panel auf dem Handy:
  • enthält die Navigation, den Button „Projekt besprechen“ und den Hell/Dunkel-Schalter;
  • dunkelt den Hintergrund ab und sperrt das Scrollen der Seite;
  • schließt per Escape, per Tipp daneben und bei Auswahl eines Links.
• Alle Anker-Ziele sind <section id="…">, damit scroll-margin-top greift (bereits global gesetzt für section[id]). Von Unterseiten aus springt ScrollToTop nach dem Laden der Schriften zum Anker (vorhanden in src/App.tsx).

6.2 Startseite (Reihenfolge)

#	Abschnitt	Anker	Typ	Kernaussage
1	Hero mit Deutschland-Karte	–	Bühne	Wir bauen Ihre Website, Ihren Shop, Ihre Web-App oder Ihre Automatisierung. Website und Kundenportal laufen auf dem Server in Falkenstein.
2	Kundenportal	#kundenportal	Bühne	Sie sehen Ihr Projekt live: Vorschau, Fortschritt, Chat, Rechnungen. Darunter die Schrittzeile.
3	Was wir bauen	#leistungen	Beleg	Vier Produkte, dazu der Umzug bestehender Websites
4	Projekte	#projekte	Beleg	nur mit freigegebenen Referenzen, sonst entfällt der Abschnitt komplett
5	Preise	#preise	Beleg	Angebot vorher, Hosting-Abo 20 €, Wartungs-Abo 50 €, weitere Arbeit nur nach Freigabe
6	Über uns	#ueber-uns	Beleg	Wer dahinter steckt, wo
7	Kontakt	#kontakt	Bühne	Ein Satz, ein Button, E-Mail und Telefon
–	Footer	–	–	Navigation, Rechtliches, Anschrift

• Bühne = etwa eine Bildschirmhöhe auf dem Desktop (min-height: 100svh), ein Satz plus ein Bild oder Objekt.
• Beleg = Höhe nach Inhalt, Text in einer Spalte von höchstens 46 rem.
• Das Kundenportal steht an zweiter Stelle, damit gleich nach dem Hero ein Bild zeigt, was WEBklar anders macht (Wunsch 8).

6.3 Jede Aussage hat genau einen Ort

Aussage	Einziger Ort auf der Startseite
Positionierung „Websites, Shops und Apps für kleine Betriebe“	kleine Zeile im Hero
Serverstandort Falkenstein	Kartenpunkt im Hero
Kundenportal und Live-Vorschau	Abschnitt Kundenportal (im Hero nur ein Satz im Untertext, ohne Funktionsliste)
Ablauf	Schrittzeile im Kundenportal-Abschnitt
Kennenlernen (15 Minuten, kostenlos)	Kontakt-Abschnitt; die Schrittzeile sagt nur „Kennenlernen“
Preise	Abschnitt Preise
Winnweiler / Pfalz	Abschnitt Über uns (die Anschrift im Footer ist Pflichtangabe und zählt nicht)
E-Mail und Telefon	Kontakt-Abschnitt (Footer ohne eigene Kontaktspalte)

• Den Erstkontakt nennt der Button überall „Projekt besprechen“. Das Wort „Potenzialanalyse“ entfällt.
• Die heutige Faktenzeile im Hero („Falkenstein / Live-Vorschau / ab 20 €“) entfällt.

6.4 Unterseiten

Route	Inhalt im Relaunch
/kontakt	Formular mit der bestehenden Logik (Appwrite), neue Gestaltung, der Datenschutzhinweis bleibt
/ueber-uns	ausführlichere Fassung des Team-Abschnitts; der Block „Der Unterschied“ entfällt
/wartungs-abo, /hosting-abo, /agb, /impressum	Texte unverändert, neues Layout (D13)
/datenschutz	bleibt Weiterleitung auf die Datenschutzerklärung im Kundenportal
*	404 im neuen Layout

6.5 Seitentitel, Beschreibung, Vorschaubild

• Startseite:
  • Titel: „WEBklar – Websites, Shops und Apps für kleine Betriebe“
  • Beschreibung: „WEBklar baut Websites, Online-Shops und Web-Apps. Im Kundenportal sehen Sie jeden Schritt, mit Live-Vorschau Ihrer Website.“
• Wo ändern: index.html (title, description, og:*, twitter:*), DEFAULT_TITLE und DEFAULT_DESCRIPTION in src/hooks/use-page-meta.ts und src/pages/Index.tsx.
• /kontakt:
  • Titel: „Projekt besprechen“
  • Beschreibung: „Beschreiben Sie Ihr Vorhaben in zwei Sätzen. WEBklar meldet sich spätestens am nächsten Werktag.“
• public/og-image.png zeigt noch die alte Positionierung. Ein neues Bild (1200 × 630, höchstens 150 KB) im neuen Stil entsteht in Phase 2: Logo, Positionierungssatz und Karte, ohne Personen.

---

7. Abschnitte im Detail

Texte in [eckigen Klammern] brauchen die Freigabe des Inhabers (Abschnitt 11). Bis dahin gilt der jeweils genannte Ersatztext. Alle anderen Texte sind Entwürfe, die so eingebaut werden.

7.1 Hero mit Deutschland-Karte

Text (links):

• Kleine Zeile darüber: „Websites, Shops und Apps für kleine Betriebe“
• Überschrift h1 mit wechselndem Teil: „Wir bauen Ihre Website.“ → „Wir bauen Ihren Online-Shop.“ → „Wir bauen Ihre Web-App.“ → „Wir bauen Ihre Automatisierung.“ → zurück zu „Wir bauen Ihre Website.“
  • Es wechselt der ganze Teil nach „Wir bauen“ (wegen Ihre/Ihren).
  • Ablauf: Wechsel alle 2,4 s mit 400 ms Überblendung. Nach einem Durchlauf bleibt „Ihre Website.“ stehen.
  • Anhalten: Während des Durchlaufs gibt es einen unauffälligen Pause-Knopf (aria-label „Wechselnde Überschrift anhalten“, Tippfläche mindestens 44 × 44 px; WCAG 2.2.2). Hover oder Fokus auf der Überschrift halten den Wechsel ebenfalls an.
  • Ohne Bewegung: Bei prefers-reduced-motion: reduce steht fest „Wir bauen Ihre Website.“, ohne Knopf. Ist der Tab nicht sichtbar, pausiert der Wechsel.
  • Screenreader: Im h1 steht ein fester, visuell versteckter Satz: „Wir bauen Websites, Online-Shops, Web-Apps und Automatisierungen.“ Der wechselnde Teil ist aria-hidden.
  • Layout: Der Wechsel darf nichts springen lassen. Die Varianten liegen übereinander, die Breite richtet sich nach der längsten.
• Untertext: „In unserem Kundenportal sehen Sie jederzeit, wie weit Ihr Projekt ist – mit Live-Vorschau Ihrer Website.“
• Buttons: „Projekt besprechen“ (→ /kontakt, Hauptbutton) und „Kundenportal ansehen“ (→ #kundenportal, zweitrangig gestaltet).

Karte (rechts):

• Datei: docs/relaunch/assets/deutschland-umriss.svg (ein Pfad, nur Linie, stroke="currentColor", viewBox 0 0 663 892). Als Inline-SVG-Komponente einbauen.
• Roter Punkt Falkenstein: cx = 469.6, cy = 520.5. Ist schon in der Datei und geprüft: liegt im Südwesten Sachsens, 14 km von der tschechischen Grenze.
• Beschriftung am Punkt: „Falkenstein, Sachsen“, darunter klein „Hier laufen Ihre Website und das Kundenportal.“ Mindestgröße 14 px.
• [Optional, O8] zweiter, hohler Punkt für das Büro in Winnweiler (ca. 49,567 N, 7,850 O → cx ≈ 146.7, cy ≈ 622.2, Formel in der README). Falls ja, steht „Hier sitzen wir“ dort, und der Ort wird im Abschnitt Über uns nicht noch einmal genannt.
• Farben: Linie var(--line-strong), Punkt var(--accent).
• Bewegung beim ersten Erscheinen:
  • Der Umriss zeichnet sich in 1,6 s (stroke-dashoffset; dafür pathLength="1" setzen und vector-effect="non-scaling-stroke" entfernen, die Strichstärke dann in der viewBox angeben).
  • Danach erscheint der Punkt, dann pulsiert ein Ring um ihn dreimal (Skalierung 1 → 2,6, je 2,4 s, Deckkraft abnehmend) und bleibt dann stehen.
  • Bei reduzierter Bewegung ist alles sofort sichtbar, ohne Ring.
• Barrierefreiheit: Die Karte ist Dekoration (aria-hidden="true"). Die Aussage steht als Text daneben.

Layout:

• Desktop: Zweispaltig, Text links (etwa 55 %), Karte rechts mit etwa 80 svh Höhe. Bei 1280 × 800 ist der ganze Hero ohne Scrollen sichtbar.
• Handy: Text oben, Karte darunter (40–46 svh hoch, mittig). Die Beschriftung am Punkt bleibt lesbar.
• Hintergrund: ruhige Fläche (--bg), kein WebGL-, Video- oder Effekthintergrund.

7.2 Kundenportal (#kundenportal)

Text:

• Überschrift: „Ihr Projekt. Live im Kundenportal.“
• Einleitung: „Sie sehen, was wir zuletzt erledigt haben, öffnen die Live-Vorschau Ihrer Website und schreiben uns im Chat – mit Fotos, Dateien oder Sprachnachricht. Ihre Rechnungen liegen ebenfalls dort, und aufs Handy installieren Sie das Portal wie eine App.“
  • Die Installierbarkeit ist geprüft: Das Portal hat ein Web-App-Manifest und einen Service Worker und ist auf dem Handy als App installierbar.

Funktionen in dieser Reihenfolge (Bilder in docs/relaunch/assets/portal/, Dateiendung .webp):

#	Titel	Bildunterschrift	Desktop-Bild	Handy-Bild
1	Live-Vorschau	„Ihre Website, noch während wir daran bauen.“	desktop-1-projekte	phone-1-projekte
2	Fortschritt	„Was wir zuletzt erledigt haben – in einfachen Sätzen.“	desktop-2-fortschritt	phone-3-projektdetails
3	Chat	„Frage, Foto oder Sprachnachricht direkt ans Team.“	desktop-3b-chat-foto	phone-4b-chat-foto
4	Rechnungen	„Ansehen, bezahlen, herunterladen.“	desktop-4-rechnungen	phone-5-rechnungen
5	Funktionen	„Bausteine zum Dazubuchen, zum Beispiel eine News-Pinnwand für Ihre Website.“	desktop-7-news-pinnwand	phone-8-news-vorschau
6	Als App	„Aufs Handy installieren, fertig.“	– (siehe unten)	phone-2-projekte-lang

• [Nur wenn O9 = ja]: Zeile 4 heißt dann „Rechnungen und Verträge“ und bekommt zusätzlich phone-6-vertraege. Eine weitere Zeile „Stundenkonto“ mit desktop-5-stundenkonto kommt hinzu, weil diese Ansichten im Portal noch nicht für alle Kunden freigeschaltet sind.
• Nicht bewerben: „Terminplaner“ und „Analyse“. Sie sind im Portal nur Platzhalter („kommt bald“).

Desktop (ab 900 px):

• Eine festgepinnte Bühne (position: sticky, Scrollstrecke etwa 3–4 Bildschirmhöhen).
• Links steht die Liste der Funktionen. Die aktive Funktion ist hervorgehoben, ein roter Punkt dient als Marker.
• Rechts:
  • Ein Desktop-Fenster: 1 px Linie, 12–14 px Rundung, oben eine schlichte Leiste mit der Adresse project.webklar.com, keine Ampelpunkte.
  • Unten rechts überlappt ein Handy-Rahmen das Fenster, etwa 30 % der Breite.
• Die Bilder wechseln per Überblendung, sobald die nächste Funktion zur Hälfte im Blick ist (IntersectionObserver).
• Bei Schritt 6 blendet das Desktop-Fenster aus. Der Handy-Rahmen rückt in die Mitte und wird größer. Darin schiebt sich der lange Screenshot phone-2-projekte-lang mit dem Seiten-Scroll nach oben. Das ist transform: translateY, gekoppelt an den Scrollfortschritt, kein eigener Scrollbereich.

Handy (unter 900 px):

• Keine festgepinnte Bühne.
• Stattdessen eine Wisch-Reihe (9.4) mit je einem Handy-Screenshot im Rahmen und der Bildunterschrift darunter.
• Die letzte Karte „Als App“ zeigt phone-2-projekte-lang. Es schiebt sich langsam nach oben, solange die Karte sichtbar ist.
• Bei O9 = ja höchstens 7 Karten.

Schrittzeile unter dem Portal (ersetzt „So arbeiten wir“):

• Text: „1 Kennenlernen · 2 Angebot mit Preis · 3 Bauen mit Vorschau und Ihrer Freigabe · 4 Online – Hosting und Pflege auf Wunsch im Abo“
• Desktop: eine Zeile mit vier Punkten.
• Handy: vier kleine Karten in einer Wisch-Reihe (Wunsch 2).

Rahmen und Bildinhalt:

• Es gibt einen Rahmenstil für alle Bilder. Er muss auf hellem und dunklem Grund funktionieren. Das Portal selbst ist dunkel und violett; das ist Bildinhalt, nicht Seitenfarbe.
• Die Screenshots zeigen nur die erfundene „Bäckerei Sonnenschein“. Nie echte Kundendaten verwenden, auch nicht verpixelt.

7.3 Was wir bauen (#leistungen)

Text:

• Überschrift: „Was wir für Sie bauen.“
• Einleitung:
  • Standard: „Die meisten Betriebe starten mit einer Website. Wenn mehr nötig ist, bauen wir mehr.“
  • [Bei O2 = ja]: „Die meisten Betriebe starten mit einer Website: Startseite und bis zu drei Unterseiten, mit Texten, Design und Anpassung für Handy und Computer. Wenn mehr nötig ist, bauen wir mehr.“

Vier nummerierte Einträge, als Textzeilen statt Karten mit Symbolen:

1. Website: „Startseite, Unterseiten, Impressum und Datenschutz – gestaltet, getextet und online.“
2. Online-Shop: „Warenkorb, Kasse, Zahlung und Versand. Auf Wunsch angebunden an Ihre Warenwirtschaft.“
3. Web-App: „Eigene Software für Ihren Betrieb mit Login, Verwaltung und Auswertungen, im Browser und auf dem Handy.“
4. Automatisierung: „Was sich ständig wiederholt, erledigt der Rechner: Bestätigungen, Rechnungen, Dokumente auslesen, ein KI-Assistent mit Ihrem Firmenwissen.“

Schlusszeile: „Sie haben schon eine Website? Wir ziehen sie um – mit Domain, Inhalten und Postfächern.“

Mit Texten spielen:

• Die Einleitung hellt sich beim Scrollen Wort für Wort auf (gedimmt 0,18 → voll), höchstens 30 Wörter.
• Nur wenn animation-timeline unterstützt wird und keine reduzierte Bewegung gewünscht ist. Sonst steht der Text normal da.

Layout:

• Desktop: große Überschrift links, nummerierte Liste rechts, viel Weißraum.
• Handy: die vier Einträge als Wisch-Reihe (9.4). Jede Karte ist 80 vw breit, die nächste ist angeschnitten sichtbar, dazu ein Zähler „1 / 4“.

7.4 Projekte (#projekte)

• Solange keine Referenz freigegeben ist, entfällt der Abschnitt komplett. Ist das Daten-Array leer, werden Abschnitt und Menüpunkt nicht gerendert.
• Sobald Freigaben vorliegen:
  • Überschrift: „Echte Websites. Echte Betriebe.“
  • Untertext: „Nur Projekte, die online sind und die wir zeigen dürfen.“
  • Je Projekt ein eigener Screenshot (kein Stockfoto), ein echter Link und eine Zeile Beschreibung.
  • Desktop mit großen Bildern, Handy als Wisch-Reihe, höchstens 5 Projekte.

7.5 Preise (#preise)

Text:

• Überschrift: „Was es kostet. Vorher.“
• Einleitung:
  • Standard: „Für Ihr Projekt bekommen Sie vorher ein Angebot mit Preis. Für den Betrieb danach gibt es zwei Abos. Alle Preise sind Endpreise; als Kleinunternehmer (§ 19 UStG) berechnen wir keine Umsatzsteuer.“
  • [Bei O1 = ja]: Der erste Satz wird ersetzt durch den freigegebenen Preisanker, z. B. „Eine Website gibt es ab … €.“

Zwei Blöcke (Desktop nebeneinander, Handy untereinander). Wortlaut aus den Abo-Seiten:

• Hosting-Abo, 20 € im Monat: „Für statische Websites: Hosting mit SSL-Zertifikat, täglicher Datensicherung und Überwachung der Erreichbarkeit, eine Domain und ein E-Mail-Postfach mit 5 GB. 12 Monate Mindestlaufzeit.“ → Link „Details zum Hosting-Abo“ (/hosting-abo)
• Wartungs-Abo, 50 € im Monat: „Für alle Websites und Web-Anwendungen, auch mit Login, Shop oder Datenbank: zusätzlich Sicherheitsupdates für die Software Ihrer Website, beliebig viele Postfächer mit zusammen 5 GB und eine Stunde Arbeitszeit pro Monat. 12 Monate Mindestlaufzeit.“ → Link „Details zum Wartungs-Abo“ (/wartungs-abo)

Zeile darunter: „Weitere Arbeit nur mit Ihrer Freigabe: 100 € pro Stunde, abgerechnet in 15-Minuten-Schritten.“ Das gilt für beide Abos, so steht es auf beiden Abo-Seiten.

Eine Quelle für alle Angaben:

• Preise, Laufzeiten und Leistungen müssen mit den Seiten /hosting-abo und /wartungs-abo übereinstimmen.
• Die Werte liegen in einem Datenmodul src/data/abos.ts, das die Startseite nutzt.
• Die Abo-Seiten selbst werden nicht auf das Modul umgebaut (D13). Stattdessen prüft ein Test, dass Preis, Laufzeit und Speicherangaben auf Startseite und Abo-Seiten gleich sind.

Darstellung: Preise zählen nicht hoch. Zahlen mit tabular-nums.

7.6 Über uns (#ueber-uns)

Text:

• Überschrift: „Wer hinter WEBklar steckt.“
• Text:
  • Standard: „Wir sind ein kleines Team aus Winnweiler in der Pfalz. Sie sprechen bei uns direkt mit den Leuten, die Ihre Website bauen.“
  • [Bei O4 = ja]: Namen und Rollen kommen dazu, z. B. „Justin kümmert sich um Websites, Angebote und Betreuung, Kenso um Shops, Software und Automatisierung.“
  • [Bei Freigabe]: „Erreichbar Montag bis Freitag von 9 bis 17 Uhr.“

Fotos:

• Nur echte Fotos des Teams, die der Inhaber liefert.
• Bis dahin keine Fotos: keine Platzhalter-Gesichter, keine KI-Bilder, keine Initialen-Kreise.

Link: „Mehr über uns“ → /ueber-uns.

7.7 Kontakt (#kontakt)

• Überschrift: „Erzählen Sie uns, was Sie vorhaben.“
• Text: „Zwei Sätze genügen. Wir melden uns spätestens am nächsten Werktag. Im ersten Gespräch klären wir in 15 Minuten, ob und wie wir helfen können – kostenlos und unverbindlich.“
• Button: „Projekt besprechen“ (→ /kontakt), darunter E-Mail und Telefon.
• Gestaltung: Bühne mit viel Ruhe, kein Effektrahmen.

7.8 Footer

• Links im Footer: Logo, „WEBklar GbR“ und die Anschrift (Pflichtangabe, aus dem Impressum).
• Spalte Seiten:
  • Startseite → /
  • Kundenportal → /#kundenportal
  • Was wir bauen → /#leistungen
  • Preise → /#preise
  • Über uns → /ueber-uns
  • Kontakt → /kontakt
  • Wartungs-Abo → /wartungs-abo
  • Hosting-Abo → /hosting-abo
• Spalte Rechtliches:
  • AGB, Impressum, Datenschutz
  • „Verträge hier kündigen“ und „Vertrag widerrufen“: Beide bleiben hervorgehoben wie heute, weil sie rechtlich vorgeschrieben sind. Die Ziele bleiben wie im heutigen Footer.tsx.
• Gestaltung: Passt sich hellem und dunklem Modus an, also kein harter schwarzer Block im hellen Modus. Kein animiertes Raster.

---

8. Gestaltung

8.1 Schrift

• Eine Schriftfamilie, zwei Gewichte (400 und 600). Inter, Space Grotesk und Poppins entfallen.
• Im Entwurf gibt es zwei Varianten zum Vergleich:
  • A – Systemschrift: -apple-system, BlinkMacSystemFont, "SF Pro Display", "Segoe UI", Roboto, sans-serif. Auf Apple-Geräten ist das echtes SF Pro, ohne Lizenz- oder Ladefrage.
  • B – selbst gehostete Variable-Schrift unter SIL Open Font License, z. B. „Instrument Sans“, als woff2 in public/fonts/. Nichts von Google Fonts oder anderen fremden Servern laden (Datenschutz).
• Vor der Entscheidung an echten deutschen Überschriften mit Umlauten und ß prüfen.
• Keine Versalien-Überschriften mehr, sondern normale Satzschreibung. Überschriften mit text-wrap: balance, Absätze mit text-wrap: pretty, dazu hyphens: auto mit lang="de".

Größen (Token):

:root {
  --fs-hero:  clamp(2.5rem, 1.569rem + 3.81vw, 5rem);       /* 40 → 80 px */
  --fs-h2:    clamp(2rem, 1.444rem + 2.29vw, 3.5rem);        /* 32 → 56 px */
  --fs-lead:  clamp(1.1875rem, 1.05rem + 0.6vw, 1.625rem);   /* 19 → 26 px */
  --fs-body:  1.0625rem;                                     /* 17 px, Zeilenhöhe 1.47 */
  --fs-small: 0.875rem;                                      /* 14 px, kleinste Textgröße überhaupt */
  --measure-text: 46rem;
  --container: 1100px;
}
h1, h2 { font-weight: 600; line-height: 1.05; letter-spacing: -0.015em; }

• Abstand von der Überschrift zum ersten Absatz: 1,2 em.
• Fließtext und Formularfelder mindestens 16 px, sonst zoomt iOS.

8.2 Farben

Grundsatz:

• Neutral, also nahezu Schwarz und Weiß mit wenigen Grautönen, plus eine Akzentfarbe: Rot wie der Kartenpunkt.
• Das cyan-blaue Primär und das Türkis im dunklen Modus entfallen.
• Rot nur für den Kartenpunkt, aktive Zustände und Marker. Der Hauptbutton ist neutral: dunkel auf hell, hell auf dunkel.

Startwerte (geprüfte Kontraste, Feinabstimmung im Entwurf, O7):

Token	Hell	Dunkel	Zweck
--bg	#ffffff	#0b0b0c	Seitenfläche
--bg-alt	#f5f5f7	#161618	jeder zweite Abschnitt
--fg	#1d1d1f	#f5f5f7	Text (≥ 15 : 1)
--fg-muted	#6e6e73	#a1a1a6	Nebentext (hell ≥ 4,66 : 1 auch auf --bg-alt, dunkel ≥ 7 : 1)
--line	#d2d2d7	#2c2c2e	Trennlinien, Rahmen
--line-strong	#86868b	#636366	Kartenumriss
--accent	#e5251c	#e5251c	Punkt und Marker (Nicht-Text, ≥ 3 : 1 auf allen Flächen)
--accent-text	#c81e16	#ff5a4f	Rot als Text oder Link (hell ≥ 5,28 : 1, dunkel ≥ 5,88 : 1, auch auf --bg-alt)
--focus	#c81e16	#ff5a4f	Fokusrahmen

• Alle Kombinationen prüft ein Test auf Kontrast. Heute geschieht das schon so in src/test/sofort-paket.test.tsx, über die Token in index.css.
• Das Logo bleibt (src/components/Logo.tsx), Schreibweise „WEBklar“.

8.3 Abstände und Flächen

• Abstände: zwischen Abschnitten 120–160 px auf dem Desktop und 72–96 px auf dem Handy. Container 1100 px breit, Textspalte 46 rem.
• Flächen: Flächenwechsel statt Rahmen. Abschnitte stehen abwechselnd auf --bg und --bg-alt, der Text steht frei auf der Fläche.
• Formen: Rundungen und Rahmen nur um Bilder und Bildschirme.

8.4 Bewegung

Grundregeln:

• Eine Kurve: cubic-bezier(.2, .8, .2, 1). Zwei Dauern: 200 ms für Zustände, 600 ms für das Erscheinen. Versatz höchstens 60 ms. Kein Federn.
• Erscheinen beim Scrollen per CSS animation-timeline: view() innerhalb von @supports. Der Grundzustand ist sichtbar: Ohne Unterstützung steht alles einfach da.
• Reduzierte Bewegung: Alles läuft hinter @media (prefers-reduced-motion: no-preference). Bei reduce gibt es keine Bewegung außer Farbwechseln.
• Animiert werden nur transform und opacity.
• Nicht erlaubt: Scroll-Hijacking und scroll-snap auf der ganzen Seite.
• Sticky: Vorfahren von position: sticky nutzen overflow: clip statt hidden.
• Hover: Hover-Effekte nur in @media (hover: hover) and (pointer: fine).

Ausdrücklich erlaubte Ausnahmen, auch nur ohne reduzierte Bewegung:

Element	Abweichung
Kartenumriss (7.1)	stroke-dashoffset über 1,6 s
Ring um den Punkt (7.1)	3 × 2,4 s, dann Stillstand
Wechselnde Überschrift (7.1)	400 ms Überblendung alle 2,4 s, ein Durchlauf
Wort-für-Wort-Aufhellen (7.3)	an den Scrollfortschritt gekoppelt

8.5 Regeln gegen den Vorlagen-Look

1. Schrift: eine Familie, zwei Gewichte.
2. Farbe: eine Akzentfarbe (Rot), und zwar mit Bedeutung.
3. Hintergründe: keine Effekte, also kein WebGL, keine Glüh-Ränder, kein Pixelraster, kein Glas.
4. Layout: kein Raster aus drei Karten mit Kreis-Symbolen. Stattdessen nummerierte Textzeilen, eine große Aussage plus Liste oder asymmetrische Layouts.
5. Texte, die nur WEBklar sagen kann: Falkenstein, Kundenportal, Winnweiler. Verboten sind „maßgeschneidert“, „ganzheitlich“, „innovativ“, „nahtlos“, „auf das nächste Level“, „Hebel“, „Tool-Inseln“, „Pipeline“ und „Potenzialanalyse“.
6. Zahlen: keine Kennzahlen ohne Beleg, keine hochzählenden Zahlen.
7. Bewegung: nur mit Aufgabe (8.4).
8. Flächen: wenige Kästen, viel Fläche.
9. Bilder: nur echtes Bildmaterial, also Portal-Screenshots mit Demodaten, echte Teamfotos und echte Projekte.
10. Austausch-Test: siehe E7.

---

9. Technik

9.1 Bleibt

• Grundgerüst: Vite, React, TypeScript, Tailwind und React Router mit allen bestehenden Routen.
• Layout: src/routes.tsx mit dem gemeinsamen Unterseiten-Layout SubpageLayout. Es wird zum neuen Layout mit Kopfleiste und Footer.
• Seiten-Helfer: usePageMeta setzt Titel und Beschreibung je Route. ScrollToTop springt zu Ankern.
• Kontaktformular: Die Logik in src/pages/Contact.tsx und src/lib/appwrite.ts bleibt, mit dem Datenschutzhinweis.
• Rechtsseiten: Ihre Texte und Tests bleiben: src/test/abos.test.tsx, agb-haftung.test.tsx, agb-verguetung.test.tsx.
• Hell/Dunkel: next-themes mit der Klassen-Strategie und dem Standard „system“, dazu das Skript in index.html gegen Aufblitzen.

9.2 Fällt weg (Phase 2)

Vor jedem Löschen prüfen, dass nichts mehr die Datei importiert.

• Effekt-Komponenten und ihre Pakete:
  • Komponenten: Silk, PixelBlast, LightRays, BorderGlow, FlickeringGrid, TextHoverEffect, CountUp.
  • Pakete: three, @react-three/fiber, postprocessing, ogl.
• Alte Startseiten-Abschnitte:
  • Partners (das Laufband) mit public/svg/*.
  • ProblemSection, SolutionSection, Values, Services, Process.
  • Die Hintergrundbilder problem*.jpg, loesung.jpg, backgroud_effect*.
• Alte Schriften: src/fonts.css und public/fonts/inter-*, space-grotesk-*. Sie werden durch die gewählte Schrift ersetzt.
• Alte Buttons: das CSS für die Buchstaben-Animation.
• Analytics: AnalyticsProvider, src/lib/analytics.ts, die data-analytics-*-Attribute und gtag. Heute ist das inaktiv; es würde aber Google laden, und der Relaunch nutzt kein Tracking (Abschnitt 13).
• Ungenutzte shadcn-Komponenten und Pakete: laut Prüfung rund 45 tote Dateien und 29 Pakete, die nur von toten Dateien genutzt werden.
• Tests:
  • Tests, die nur gelöschte Komponenten prüfen, werden entfernt oder auf die neuen Abschnitte umgeschrieben.
  • Die Quelltext-Prüfungen gegen verbotene Aussagen bleiben in jedem Fall: alte Telefonnummer, Unsplash, „24 Stunden“, „99,9“, Erfolgsversprechen.

9.3 Neu

• Startseite: src/pages/Index.tsx mit den Abschnitten aus 7, je Abschnitt eine Komponente in src/components/home/:
  • HeroKarte.tsx
  • Kundenportal.tsx
  • Leistungen.tsx
  • Preise.tsx
  • UeberUns.tsx
  • KontaktBuehne.tsx
• src/components/DeutschlandKarte.tsx: Inline-SVG aus dem Asset. Die Punkte kommen als Props, dazu die Formel aus der README.
• src/components/WischReihe.tsx: die wiederverwendbare horizontale Reihe (9.4).
• src/components/GeraeteRahmen.tsx: Desktop-Fenster mit Adressleiste und Handy-Rahmen.
• src/data/abos.ts: Preise und Leistungen für die Startseite (7.5).
• Design-Token: neu in src/index.css und tailwind.config.ts (8.1, 8.2).

9.4 Wisch-Reihe (unter 900 px)

• Technik: natives CSS ohne Bibliothek.
  • Reihe: display: flex; overflow-x: auto; scroll-snap-type: x mandatory; scroll-padding-inline: 16px; overscroll-behavior-x: contain;
  • Karten: flex: 0 0 80vw; max-width: 380px; scroll-snap-align: start.
• Wischen erkennbar machen:
  • Die nächste Karte ist angeschnitten sichtbar. Das ist der wichtigste Hinweis.
  • Dazu ein Zähler „2 / 4“. Die aktive Karte bestimmt ein IntersectionObserver (mindestens 60 % sichtbar).
• Barrierefreiheit:
  • Liste mit role="list".
  • Bereich mit tabindex="0" und aria-label, z. B. „Vier Leistungen, seitlich wischen“.
  • Die Fokusreihenfolge entspricht der Anzeige.
  • Kein aria-live, keine automatische Bewegung.
• Ab 900 px zeigt jeder Abschnitt seine Desktop-Darstellung (Liste, Raster oder Bühne). Auf dem Desktop bleibt keine Wisch-Reihe übrig.
• Grenze: Höchstens 7 Karten je Reihe.

9.5 Bilder

• Format und Auslieferung:
  • WebP mit Qualität 80–85.
  • Über srcset ausliefern: Desktop 800, 1200 und 1600 w, Handy 390 und 780 w.
  • loading="lazy" (außer Bildern im ersten Bildschirm), decoding="async", feste width/height.
• Budgets:
  • Ein einzelnes Desktop-Bild höchstens 120 KB, ein einzelnes Handy-Bild höchstens 60 KB.
  • Was beim ersten Erreichen des Portal-Abschnitts sichtbar wird, höchstens 300 KB.
  • Alle Bilder des Abschnitts für eine Gerätegröße zusammen höchstens 900 KB.
• Rohdateien: Die Dateien in docs/relaunch/assets/portal/ sind Rohexporte in doppelter Auflösung und müssen verkleinert werden. Das geht einmalig vorab oder per Build-Skript mit sharp. In public/ landen nur die verkleinerten Fassungen.
• Alt-Texte: jedes Bild bekommt einen, z. B. „Kundenportal: Projektübersicht mit Live-Vorschau der Website“.

9.6 Barrierefreiheit und Handy

• Struktur: genau ein h1 je Seite, jeder Abschnitt ein h2, dazu die Landmarken header, nav, main, footer.
• Bedienung: sichtbarer Fokus (--focus), die Tastatur erreicht alles, Tippflächen mindestens 44 × 44 px.
• Formulare: mit autocomplete (name, email, organization) und aria-live für Fehler und Erfolg.
• Handy-Checkliste (aus der Prüfung):
  • kein seitlicher Überlauf bei 360 und 390 px;
  • svh/dvh statt vh;
  • Safe-Area-Ränder (env(safe-area-inset-*)) bei festen Elementen;
  • Menü mit Scrollsperre (6.1);
  • Anker landen unter der Kopfleiste;
  • Text mindestens 14 px, Fließtext 16–17 px;
  • nichts ist nur per Hover erreichbar;
  • Querformat 844 × 390 hat Inhalt und Buttons ohne erzwungene Höhe.

9.7 Leistung

• Budgets: E5, dazu CSS höchstens 15 KB gzip.
• Routen per React.lazy: Die Rechtsseiten müssen nicht im Startpaket sein. Die Render-Tests in src/test/ fragen dann asynchron ab (await screen.findBy…).
• Appwrite-SDK: erst beim Absenden des Formulars laden (import()).
• Keine fremden Server: Schriften, Bilder und Skripte selbst hosten.

9.8 Tests und Prüfung

• npm test (Vitest und Testing Library) prüft:
  • Abschnitte rendern mit h2, und die Anker passen zur Navigation.
  • Wisch-Reihen haben tabindex und aria-label.
  • Preise auf der Startseite stimmen mit den Abo-Seiten überein.
  • Verbotene Aussagen und Wörter kommen nicht vor (8.5 Punkt 5).
  • Die Rechtsseiten-Tests laufen unverändert grün.
  • Die Kontrast-Token beider Modi erreichen mindestens 4,5 : 1.
• Anpassung bestehender Tests in Phase 1:
  • In src/test/sofort-paket.test.tsx dürfen die Stellen geändert werden, die alte Texte oder Strukturen festschreiben: Meta-Beschreibung mit „Potenzialanalyse“, Navigationspunkte „Leistungen“ und „Ablauf“, Texte auf /kontakt und /ueber-uns sowie Tests gelöschter Komponenten.
  • Nicht entfernt werden die Quelltext-Prüfungen gegen verbotene Aussagen.
  • Die drei Rechtstext-Testdateien bleiben unverändert.
• Browserprüfung (Playwright) bei 390 × 844 und 1440 × 900, hell und dunkel:
  • kein seitlicher Überlauf, keine Konsolenfehler;
  • Seitenlänge auf dem Handy höchstens 8 Bildschirme;
  • Karte und Punkt sind sichtbar, Wisch-Reihen lassen sich wischen;
  • bei prefers-reduced-motion: reduce gibt es keine Bewegung;
  • Screenshots für den Inhaber.
• Vor jedem Push: npm test, npm run build und npm run lint (keine neuen Fehler gegenüber main).

---

10. Rechtliche Leitplanken

• Rechtstexte: Die Texte von AGB, Impressum, Abo-Seiten und Datenschutzerklärung nicht ohne ausdrückliche Freigabe des Inhabers ändern (D13). Die Tests sichern das ab.
• Inhalte:
  • keine Erfolgsversprechen und keine unbelegten Zahlen;
  • keine Referenzen ohne Zustimmung;
  • keine Stockfotos und keine KI-Bilder von Personen.
• Preise: als Endpreise, mit Hinweis auf § 19 UStG.
• Server: Die Aussage zum Serverstandort gilt nur für Website und Kundenportal (D7).
• Kontaktformular: Der Datenschutzhinweis mit Link bleibt direkt am Formular.
• Keine Drittanbieter-Anfragen, damit die Datenschutzerklärung stimmt.
• Portal-Screenshots: nur mit Demodaten.
• Footer: „Verträge hier kündigen“ und „Vertrag widerrufen“ bleiben auf jeder Seite erreichbar.

---

11. Offene Entscheidungen (Inhaber)

Nr.	Frage	Bis zur Entscheidung gilt
O1	Preisanker für Websites veröffentlichen? Welcher Betrag?	Standardtext in 7.5 (Angebot mit Preis, ohne Betrag)
O2	Leistungsumfang „Startseite und bis zu drei Unterseiten“ als Einstieg nennen?	Standardtext in 7.3
O3	Zeitrahmen veröffentlichen (z. B. erste Vorschau nach wenigen Tagen)?	nicht nennen
O4	Team: Wer wird mit Namen, Rolle und Foto gezeigt?	Standardtext in 7.6, keine Fotos
O5	Welche Kunden stimmen einer Referenz zu?	kein Projekte-Abschnitt
O6	Werden Eingänge über das Kontaktformular zuverlässig gemeldet? Nur dann ist „spätestens am nächsten Werktag“ haltbar	Formulierung bleibt; vor dem Livegang klären
O7	Schrift A oder B, genauer Rotton	im Entwurf beide Schriften zeigen, Startwerte aus 8.2
O8	Zweiter Kartenpunkt für Winnweiler („Hier sitzen wir“)?	nur Falkenstein
O9	Stundenkonto und Verträge im Portal-Abschnitt zeigen? Hängt an der Freischaltung im Portal	nicht zeigen
O10	Wie sieht der Inhaber den Entwurf?	GitHub Pages über einen Actions-Workflow für den Zweig relaunch (siehe unten). Geht das nicht (z. B. privates Repo ohne Pages), Screenshots im Pull Request
O11	Repository öffentlich oder privat?	nichts Internes einchecken: keine Preiskalkulation, keine Kundennamen, keine Serverdetails
O12	Erreichbarkeit „Montag bis Freitag 9 bis 17 Uhr“ auf der Startseite nennen?	nicht nennen

Vorschau über GitHub Pages (O10):

• Der Build bekommt den Unterpfad über VITE_BASE (vite.config.ts: base) und BrowserRouter basename={import.meta.env.BASE_URL}.
• Damit Unterseiten direkt aufrufbar sind, wird dist/index.html im Workflow nach dist/404.html kopiert.
• Das Kontaktformular sendet in der Vorschau nichts (ohne Appwrite-Variablen zeigt es eine Fehlermeldung, das ist in Ordnung).
• Schriftvarianten sind über ?schrift=a bzw. ?schrift=b erreichbar.

---

12. Arbeitsweise und Livegang

• Zweige: Gearbeitet wird auf Zweigen in diesem Repository, zusammengeführt per Pull Request nach main dieses Repos. main hier ist nicht live.
• Pull Requests enthalten Screenshots der geänderten Abschnitte: Desktop und Handy, hell und dunkel.
• Geheimnisse: Keine einchecken. .env bleibt lokal; .env.example enthält nur öffentliche Client-IDs.
• Livegang:
  • Nach Freigabe des Inhabers wird der Stand ins interne Live-Repository übertragen, danach werden alle Routen live geprüft.
  • Die Übertragung macht eine Sitzung auf dem Server oder der Inhaber; sie gehört nicht zur Cloud-Arbeit.
  • Bei der Übertragung dürfen Dateien, die es nur im Live-Repository gibt (Server-Doku, Vorschau-Konfiguration), nicht gelöscht werden.

---

13. Nicht im Umfang

• Blog, CMS, Mehrsprachigkeit.
• Analytics, Tracking und Cookie-Banner.
• Vorab-Rendering (SSR/SSG), sitemap.xml, strukturierte Daten und echte 404-Statuscodes. Das ist ein eigenes Folgeprojekt; der Code soll dafür aber nichts verbauen.
• Änderungen am Kundenportal selbst, z. B. eine einheitliche Anrede oder der Mehrwertsteuer-Hinweis bei Funktionen.
• Änderungen an Server, Deploy und Kontakt-Backend.

---

14. Abnahme

Phase 1 (Entwurf) ist fertig, wenn:

• auf dem Zweig relaunch laufen:
  • die neue Kopfleiste,
  • alle Abschnitte aus 6.2 außer „Projekte“,
  • der neue Footer;
• der Hero mit wechselnder Überschrift, gezeichneter Karte und Pause-Knopf funktioniert, ebenso die Wisch-Reihen auf dem Handy und die Portal-Bühne auf dem Desktop;
• beide Schriftvarianten umschaltbar sind;
• die Vorschau (O10) erreichbar ist und Screenshots vorliegen: 1440 × 900 und 390 × 844, hell und dunkel, je Schriftvariante;
• npm test und npm run build grün sind.

Phase 2 ist fertig, wenn:

• die Erfolgskriterien E2–E6 gemessen erfüllt sind;
• der Inhaber E1 und E7 bestätigt hat;
• alle Unterseiten das neue Layout haben und die Texte der Rechtsseiten unverändert sind;
• der Schriftumschalter entfernt ist und die gewählte Schrift fest eingebaut ist;
• Effekt-Komponenten, Analytics und tote Abhängigkeiten gelöscht sind;
• die Rückmeldungen des Inhabers eingearbeitet sind und er den Stand freigibt.