Neuer Abschnitt

Was macht Neuer Abschnitt?

Eine kurze Routine für einen Abschnitt einer Website, deren Regeln bereits festgelegt sind. Es ist der Abschnittsschritt des Skills futuristic-web-design, der so verpackt ist, dass er allein laufen kann.

Wenn ../futuristic-web-design/ neben diesem Skill liegt, enthalten seine Referenzdateien die Details. Lese diejenige, die die Aufgabe benötigt: references/design-system.md für das Layout-Vokabular und das Audit der generischen Website, references/ship.md für das Kontaktformular und den Telefonpass.

Wenn das Projekt noch keine Regeln-Datei oder kein Designsystem hat, stoppe und verwende futuristic-web-design ab seiner ersten Phase. Ein Abschnitt, der ohne ein Designsystem erstellt wird, ist die Quelle des generischen Aussehens.

Die Routine

1. Lies die Regeln. Öffne die Projektregeln-Datei (AGENTS.md, CLAUDE.md oder GEMINI.md) und die Theme-Tokens. Verwende nur die dort definierten Schriftarten und Paletten sowie den Stack, den das Projekt bereits verwendet.
2. Bestätige den Inhalt. Wo Fakten wichtig sind (Preise, Behauptungen, Namen, Zitate), frage nach. Erfinde niemals Kunden, Bewertungen oder Statistiken für ein reales Unternehmen. Schreibe ansonsten echten Text und markiere die Zeilen, die du erfunden hast. Keine Platzhaltertexte.
3. Wähle ein Layout mit Absicht. Geteilt, zentriert, randlos, Raster, Bento oder asymmetrisch. Sage in einem Satz, welches und warum. Vermeide die Standardlösung einer zentrierten Überschrift über drei identischen Karten: hebe ein Element hervor und versetze die anderen.
4. Baue eine Komponente in einer eigenen Datei unter components/ oder dem Äquivalent des Projekts.
5. Überprüfe sie bei 390px, 768px und 1440px in einem Browser und repariere, was du siehst. Ein Layout kann allen Regeln entsprechen und trotzdem falsch aussehen.
6. Passe den Abstand ober- und unterhalb an die benachbarten Abschnitte an.
7. Melde in drei Zeilen: was gebaut wurde, den Dateipfad und was die Augen des Nutzers benötigen (erfundener Text, nicht verdrahtete Buttons, alles, was du nicht überprüfen konntest).

Ändere nur den Abschnitt, der angefordert wurde. Ein Diff, der breiter ist als die Anfrage, verbirgt, welche Bearbeitung geholfen hat.

Layout-Optionen

Wenn der Nutzer nach Optionen fragt oder nicht beschreiben kann, was er möchte, erstelle zwei oder drei Varianten aus demselben Inhalt. Setze jede auf eine eigene Vorschauseite (/preview-1, /preview-2 oder /before und /after für eine Neugestaltung) mit einer einzeiligen Beschreibung. Menschen entscheiden leichter, als sie etwas spezifizieren.

Lasse die echte Seite unberührt, bis der Nutzer sich entscheidet. Lösche dann die anderen Varianten und ihre Routen, da übrig gebliebene Vorschauseiten mit der Website ausgeliefert werden.

Was einen Abschnitt designed aussehen lässt

• Schrift. Die Überschrift-Schriftart groß mit enger Laufweite, die Leseschriftart für alles andere. Nur zwei Schriftarten; Framework-Standardwerte wie font-mono auf einem Label zählen als dritte. Eine Hero-Überschrift besteht aus höchstens etwa acht Wörtern.
• Ein Hauptbutton. Ausgefüllt in der Button-Farbe der Palette, verknüpft mit der Aktion aus dem Briefing. Eine zweite Aktion ist ein Textlink mit einem Pfeil oder eine dezente Umrandung. Zwei Buttons mit gleichem Gewicht signalisieren, dass keine Entscheidung getroffen wurde.
• Jeder Button führt irgendwo hin. Ist das Ziel unbekannt, verwende das nächstgelegene ehrliche Ziel und liste den Button im Bericht als nicht verdrahtet auf.
• Oberfläche und Raum. Großzügiger Weißraum, flache Füllungen, haardünne Ränder, optional Korn oder Glas. Keine Farbverläufe, die eine Palette ersetzen. Schatten nur bei Hover.
• Bilder. In Anzeigegröße ausgeliefert, lazy-geladen unterhalb des ersten Bildschirms, mit Alt-Text, der das Bild beschreibt ("Bernsteinserumflasche auf hellem Stein", niemals "Bild 1").
• Bewegung. Ein kurzer Fade und ein paar Pixel nach oben, unter 500ms, einmalig. Unter prefers-reduced-motion bewegt sich nichts, einschließlich Smooth Scrolling und Hover-Transitionen.

Die 390px-Überprüfung

Mobilgeräte machen die meisten Besuche aus, daher ist dies die Breite, die entscheidet, ob der Abschnitt fertig ist.

• Der Fließtext ist lesbar, und keine Überschrift erstreckt sich über fünf oder mehr Zeilen.
• Nichts drückt gegen den Bildschirmrand.
• Touch-Ziele haben etwa 44px oder mehr.
• Es gibt kein horizontales Scrollen.
• Die Navigation klappt hinter einem Menü-Button zusammen, der sich öffnen und schließen lässt.
• Karten in einer Reihe behalten Preise und Buttons auf derselben Zeile, unabhängig von der Länge des darüber liegenden Textes. Überprüfe dies bei allen drei Breiten.

Kontaktabschnitt

Ein Formular ohne Ziel richtet Schaden an, da die Leute annehmen, ihre Nachricht sei angekommen. Das Modell ist ein Briefkasten: offen zum Einwerfen für alle, verschlossen zum Lesen für niemanden außer dem Eigentümer.

• Felder name, email, message, gespeichert in einer leads-Tabelle in Supabase oder dem Backend, das das Projekt bereits verwendet.
• Row-Level-Security aktiv: anonymes Einfügen erlaubt, kein öffentliches Lesen. Verkette nicht .select() mit dem Einfügen; ohne Leseberechtigung führt dies zu einem Fehler.
• Der Seiten-Code verwendet nur den öffentlichen Schlüssel, geladen aus .env.local, der in .gitignore bleibt.
• Validiere vor dem Senden (plausibles E-Mail-Format, nicht leere Nachricht) und erkläre jede Ablehnung. Gib unterschiedliche Meldungen für Erfolg und Fehler.
• Spam-Abwehr: ein verstecktes Honeypot-Feld, das leer bleiben muss, plus Ablehnung von Einsendungen, die schneller eintreffen, als ein Mensch tippen könnte.
• Teste wie ein Besucher: eine leere Nachricht, eine fehlerhafte E-Mail, eine gültige Einsendung. Nur eine neue Zeile in der Tabelle beweist, dass es funktioniert; eine Bestätigung auf dem Bildschirm nicht.
• Wenn ein Speichern fehlschlägt, lies den Fehler und korrigiere die Richtlinie. Schalte Row-Level-Security niemals aus, da diese Tabelle die Namen und Adressen der Leute enthält.