Referenz

Orange ist die einzige Marken-/Aktionsfarbe im UI. Schwarz/Weiß trägt alles andere. Einzige Ausnahme: Status-/Feedbackfarben (unten) für Pills und Formular-Rückmeldungen. Sunset-Gradient nur im Hero, siehe unten.

Status-/Feedbackfarben

Nur für Pills, Formular-Erfolgs-/Fehlermeldungen und vergleichbare Zustandsanzeigen. Nie als Marken-/Aktionsfarbe verwenden.

Cormorant Garamond (Display) + EB Garamond (Fließtext) + IBM Plex Mono (Daten/UI). Headings, Nav, Labels und Buttons stehen immer in Großbuchstaben mit weiter Laufweite, Fließtext bleibt normal gesetzt.

• Genau ein H1 pro Seite — über .page-head h1 (56px), die spezifische Headline der Seite (nicht zwangsläufig der Grav-Seitentitel, siehe Eyebrow-Regel unten). Auf Home ist das der Hero-Claim.
• H2 — Section-Überschriften innerhalb der Seite (40px, .section-head h2). H3 — Karten-/Tabellentitel innerhalb einer Section (30px).
• H2-Breite (.section-head h2 { max-width: 30ch }) — Großbuchstaben + letter-spacing:0.06em machen jedes Zeichen spürbar breiter als der ch-Referenzwert des Browsers; ein zu knapper max-width-Wert lässt selbst kurze Überschriften (z. B. „Deine Pace-Zonen", 17 Zeichen) unnötig umbrechen. Bei neuen kurzen H2-Überschriften nach dem ersten lokalen Test immer visuell prüfen, ob sie einzeilig bleiben — nicht nur die Zeichenzahl gegen den ch-Wert rechnen.
• Seitenkopf-Muster (verbindlich, außer Home) — jede Seite startet mit .page-head: ein kurzer .eyebrow-Kicker direkt über dem H1, danach immer exakt 68px Abstand bis zum ersten Inhaltsblock — egal ob das ein Zitat, eine Lede, eine normale Section, eine Sticky-Leiste oder ein Bild ist. Diese 68px sind die einzige, durchgehend verbindliche Konstante für „H1 zu erstem Inhalt" auf dieser Seite, unabhängig vom Seitentyp. Home ist die einzige Ausnahme (eigenes Hero-Muster statt .page-head). H1/H2 haben selbst margin:0 (globale Heading-Regel), direkt folgende Elemente brauchen deshalb ein bewusst gesetztes margin-top statt sich auf den Browser-Standardrand zu verlassen — sonst kleben Überschrift und Text ohne Luftraum aneinander (.lede/.section-note lösen das über margin-top:68px, siehe unten).
• Eyebrow = Seitentitel, H1 = spezifisch — der Eyebrow trägt immer den schlichten Seitentitel (page.title, z. B. „Kontakt", „Über mich", „Styleguide"), das H1 wird darunter konkreter/eigenständig formuliert, nie eine Wiederholung desselben Worts. Beispiele: /projekt-777 — Eyebrow „Projekt 777", H1 „Wie aus Plänen neue Wege wurden"; /ueber-mich — Eyebrow „Über mich", H1 „Der Läufer"; /styleguide — Eyebrow „Styleguide", H1 „Referenz". Ausnahme: Unterseiten, die zu einem übergeordneten Bereich gehören (Blogpost, Modul-Bibliothek, Tools-Extended-Unterseiten, rechtliche Unterseiten), zeigen stattdessen den übergeordneten Bereich als Eyebrow (z. B. „Blog · Wettkampf", „Trainings-Hub", „Tools · Extended Version", „Rechtliches") und die eigene, spezifische Seite als H1 — das ist keine Dopplung, sondern ein Breadcrumb. Darunter außerdem: keine zweite Eyebrow- oder Heading-Zeile direkt nach dem Seitenkopf. Ein einleitender Absatz/„Story"-Text schließt als reiner Fließtext an, notfalls mit einem hervorgehobenen Auftakt-Satz (<strong> in Akzentfarbe) statt einer eigenen Zwischenüberschrift.
• Zitat direkt nach der Headline, vor der Lede (verbindlich auf jeder Hauptnav-Seite) — Projekt 777, Lauf-Blog, Trainings-Hub, Tools, Über mich und Kontakt starten alle mit derselben Reihenfolge: Eyebrow → H1 → .quote → Lede/Mengentext (falls vorhanden). Ein kurzes, passendes Motivations-/Laufzitat mit Namen und Rolle der zitierten Person (<cite>Name <span>Rolle</span></cite>). Hat die Seite keine Lede (Projekt 777, Tools, Blog, Über mich), sitzt das Zitat als direktes Geschwister-Element von .page-head — dafür sorgt .page-head + .quote { margin-top: 68px }. Hat die Seite eine Lede (Kontakt, Trainings-Hub), sitzt das Zitat INNERHALB von .page-head zwischen H1 und Lede — dafür gelten die spezifischeren Regeln .page-head h1 + .quote und .page-head .quote + .lede. Alle drei Werte (68px) sind identisch — Headline→Zitat, Zitat→Lede und (auf Seiten ohne Zitat) Headline→Lede laufen sitewide mit demselben Abstand, damit der Seitenkopf-Rhythmus nie unterschiedlich groß wirkt, egal welche Kombination aus Zitat/Lede eine Seite hat. Inhalt liegt als quote: { text, author, role } im Frontmatter der jeweiligen Seite, nicht hartcodiert im Template. Home ist auch hier die Ausnahme (kein Zitat im Hero). Lehre (Stand 2026-10-01): Bis hierhin hatte „Headline→Lede" ohne Zitat abweichend nur 16px, weil die Lede fälschlich als Teil der Kopfzeile statt als eigenständiges Element gedacht war — sichtbar inkonsistent im direkten Seitenvergleich, auf Nutzerhinweis auf einheitlich 68px korrigiert.
• Einleitende Absätze (.lede, .section-note) — beide immer --size-body-lg (20px) mit max-width:72ch. Wichtig: ch ist schriftgrößen-relativ — dieselbe ch-Zahl ergibt bei unterschiedlicher font-size unterschiedliche Pixelbreiten. Wenn mehrere Absätze auf einer Seite optisch gleich breit laufen sollen (z. B. Seitenkopf-Lede + Abschnitts-Erklärtext), müssen sie deshalb dieselbe font-size tragen, nicht nur denselben ch-Wert.
• Wann Body-lg (20px) vs. Body (18px) vs. Mono/Daten (14px)? — Body-lg für alles, was der Besucher als Erstes/Wichtigstes lesen soll: Seitenkopf-Lede, Section-Notes, die Fließtext-„Story" auf einer Seite (z. B. /projekt-777, dort über .story p). Body für zweitrangigen/unterstützenden Text, der neben anderen UI-Elementen steht statt selbst die Hauptlektüre zu sein: Card-Beschreibungen (.card p, auch die Home-Kacheln), Listenpunkte, Formular-Hinweistexte, Modul-Fakten. Mono/Daten ausschließlich für IBM Plex Mono in tatsächlichen Daten-/UI-Kontexten (Zeiten, Labels, Tabellenkopf) — keine allgemeine „kleine Schrift"-Option für Fließtext. Ein Wert außerhalb dieser drei (z. B. ein hartcodiertes 14px in Garamond) ist immer ein Fehler, kein viertes Level.
• Ziffern in Überschriften – Cormorant hat standardmäßig Mediävalziffern, die zu tief sitzen. Überschriften auf der Website (font-variant-numeric: lining-nums) und in den Mails (zusätzlich font-feature-settings: 'lnum' 1, inline) nutzen Versalziffern.

• 0px — Buttons, Karten, Tabellen. Aktionsflächen sind eckig.
• 3px — Pills/Status-Badges. Leicht gerundet, nie ein Kreis.
• 50% — nur Icon-Buttons (Social, Scroll-Top). Die einzige runde Form im UI.
• Spacing — 4px-Basis (siehe --space-1 bis --space-24 in theme.css), Sektionen durch Weißraum getrennt, nicht durch Linien.
• Navigation — sticky, bleibt beim Scrollen fixiert oben (position: sticky), feste Höhe --nav-h.
• Mobile-Breakpoint — ab 960px Breite klappen die 7 Nav-Punkte zu einem Burger-Menü zusammen (reiner CSS-Checkbox-Trick, kein JavaScript). Menü öffnet als volle Breite unterhalb der Navbar.
• Footer — vierspaltig (Kategorien, Information, Rechtshinweise, Social Links als Icons), darunter eine schmale Copyright-Zeile mit Styleguide-Link. Bricht unter 700px auf zwei Spalten.
• Hero-Video — Home-Hero zeigt das Original-Video (777_jogger.mp4, stumm, Endlosschleife, keine Bedienelemente) statt einer reinen Farbverlauf-Näherung. Ausschnitt object-position: center 35%, orientiert am Original-Standbild. Fällt auf den Sunset-Gradient zurück, falls das Video nicht lädt.

Seit September 2026 tritt die Marke ohne Wortmarke oder Zusatzzeile auf: nur die drei Schrägstriche, in drei Farbvarianten für unterschiedliche Grundflächen.

Freigegebene Farbkombinationen (Zeichen auf Vollfläche):

Jeder kann ein Läufer sein. Wir sind dazu bestimmt, uns zu bewegen.

Bill Rodgers Boston und New York Marathon Gewinner

• .quote — Zitatblock (<blockquote>): 3px Akzentlinie links, Zitattext in Cormorant Garamond kursiv (22–30px, fluid), Quellenangabe darunter in IBM Plex Mono Großbuchstaben (Name) mit optionaler zweiter Zeile für Rolle/Kontext (<cite><span>). Keine Anführungszeichen-Glyphe — die Akzentlinie markiert das Zitat.
• Einsatz: redaktionelle Einschübe in Blog-Artikeln oder Seiteneinstiege (aktuell testweise auf /blog direkt unter dem Seitenkopf).

Alle Buttons teilen die Basisklasse .btn (eckig, IBM Plex Mono, Großbuchstaben) und heben beim Hover leicht ab (Verschiebung nach oben + Schatten). Primary und Outline laufen mit entgegengesetzter Hover-Richtung; der Modifier .btn-reverse dreht die Reihenfolge jeweils um — Start- und Hover-Zustand tauschen die Plätze.

• .btn.btn-primary — gefüllter Haupt-CTA in Akzentfarbe, weiße Schrift. Hover: entleert sich zu Outline in Akzentfarbe (Rahmen + Schrift orange). Einsatz: max. 1× pro Section, z. B. Hero-CTA.
• .btn.btn-primary.btn-reverse — startet als Outline in Akzentfarbe, füllt sich beim Hover orange mit weißer Schrift — die Umkehrung von .btn-primary.
• .btn.btn-outline.on-light — sekundärer CTA auf hellem Grund, umrandet, füllt sich beim Hover in Ink ein. Einsatz: Karten-/Kachel-Links.
• .btn.btn-outline.on-light.btn-reverse — startet gefüllt in Ink mit weißer Schrift, entleert sich beim Hover zu Outline in Ink — die Umkehrung von .btn-outline.on-light.
• .btn.btn-outline (ohne .on-light) — dieselbe Outline-Variante auf dunklem Grund, Akzentfarbe statt Ink.
• .btn-sm — Größen-Modifier für Buttons innerhalb von Karten/Kacheln (kompakteres Padding & kleinere Schrift). Funktioniert mit jeder Farb-/Richtungsvariante, immer zusätzlich, nie allein.
• .icon-btn — runde Icon-Buttons (Social-Links in Footer/Kontakt, Share-Leiste, To-Top), einzige Kreisform im UI. Hover dimmt auf 70% Deckkraft und vergrößert sich leicht (scale 1.08), statt Farbwechsel.
• Kachel-Regel — CTA-Buttons in einer Karten-Reihe (.teaser-row .card) sitzen per Flexbox immer am unteren Kartenrand, unabhängig von der Textlänge.

Tabs

• Live für gleichwertige Bereiche einer Seite (Dashboard: Stand / Wochenziele / Laufpausen und Aktiver Zyklus / Neuer Plan / Plan-Historie). Markup: Leiste .tabnav mit .tabnav-item je Tab, die Bereiche tragen .tab-panel und data-tab-panel; das Skript js/tabs.js schaltet um. Design: alle Tabs gleich breit (Text zentriert), der aktive Tab nur mit Schrift in der Akzentfarbe (.is-active, keine gefüllte Fläche), inaktive Tabs in gedämpftem Grau und beim Hover ebenfalls Akzentfarbe. Linien: zwischen den Tabs eine 1px graue Trennlinie (--line), unter der gesamten Leiste eine horizontale 1px-Linie in --line, sonst keine Umrandung. Bereiche stehen immer auf weißem Grund (kein .alt-Hintergrund). Der aktive Tab steht im URL-Hash (#id), damit Formular-Aktionen und Neuladen auf demselben Tab landen; ohne JavaScript bleiben alle Bereiche sichtbar. Abgrenzung: Die Filter-Leiste filtert gleichartige Einträge, Tabs wechseln unterschiedliche Inhaltsbereiche.
• Live Text mittig in jeder Zelle (Flex-Zentrierung), Zellbreite mindestens 150px und mindestens so breit wie der Text, damit er auch im Tablet-View nicht aus der Zelle läuft; die Leiste scrollt dann seitlich.

Filter-Leiste

• Live für "viele gleichartige Einträge, davon nur eine Teilmenge zeigen" (Blog-Kategorien, Modul-Bibliothek-Themen, Wochenplan-Phasen im Trainingsplan-Generator Extended) gilt .btn-filter/.is-active (Akzentfarbe gefüllt) als verbindliches Muster – alle Einträge bleiben dabei immer als vollständige Karten sichtbar, nichts klappt auf/zu. Ein rohes HTML-<details>-Akkordion wurde bewusst wieder verworfen, weil es nicht zur restlichen Linie passte.

Profil-Menü

• Live .navuser am rechten Ende der Navigation, das Profil-Icon ist immer sichtbar: Gäste sehen nur das Icon als Link zum Login (mobil mit dem Text „Anmelden“), Angemeldete sehen Icon plus Namen mit Menü, ohne Umrandung, in derselben Schrift und auf einer Höhe mit den Navigationspunkten (alle Einträge der Leiste sind vertikal zentriert; Hover in der Akzentfarbe). Darunter ein dunkles Panel (wie die Navigation) mit „Angemeldet als …“, genau zwei Einträgen: „Mein Profil“ (Admins landen im Dashboard, alle anderen in „Mein Bereich“) und „Abmelden“. Das Panel klappt weich auf (Einblenden plus 8px Gleiten, 0,22 s, bei „Bewegung reduzieren“ ohne Animation). Schließt per Klick daneben oder Esc. Unter 1180px nur das Icon. Mobil (unter 960px) bleibt das Profil-Icon in der Navigationsleiste links neben dem Burger (nicht im Burger-Menü) und klappt dasselbe Panel direkt unter der Leiste auf (.nav-right bündelt Burger, Links und Profil, die Reihenfolge steuert order).

Inhaltsverzeichnis

• Live Für lange Referenz- und Doku-Seiten (Styleguide, Dokumentation): zweispaltig mit klebendem Inhaltsverzeichnis links (.doc-layout, .doc-toc, 260px) und Inhalt rechts. Der Styleguide ist in Kapitel (section.sg-chapter mit id und data-toc für den Kurztitel) und Unterkapitel (h3.sg-sub mit id) gegliedert; das Verzeichnis wird daraus per Skript erzeugt (Kapitel nummeriert, Unterkapitel eingerückt) und markiert beim Scrollen das aktuelle Unterkapitel in der Akzentfarbe, das übergeordnete Kapitel in Ink. Unter 960px steht das Verzeichnis als aufklappbarer Kasten „Inhalt“ (details, eingeklappt) über dem Inhalt und schließt nach einem Klick. Neue Einträge gehören in das passende Kapitel; wächst ein Kapitel, bekommt es ein weiteres h3.sg-sub, kein neues Kapitel ohne Not.

Overlay

• Live wenn eine Karte/Zeile mehr Tiefe hat, als kompakt Platz findet (z. B. Modul-Details im Trainingsplan-Generator Extended): ein Klick auf den Auslöser öffnet .pg-modal-backdrop (abgedunkelter Hintergrund, schließt per Klick daneben) mit .pg-modal (weiße Box, eckig, ×-Schließen-Button oben rechts). Kein neues Farb-/Formvokabular, nur bestehende Bausteine (.pill, .module-facts, .module-variants) in einer Overlay-Hülle.

Auswahlfeld

• Live jedes select in einem .form-field nutzt nicht den nativen Pfeil, der direkt am Rand klebt, sondern einen eigenen Chevron (12px, in --ink-700) mit 16px Abstand zum rechten Rand; rechts 44px Innenabstand, damit langer Text nie unter den Pfeil läuft. Sonst wie die Textfelder: eckig, 1px Rahmen in --line, Hover und Fokus in der Akzentfarbe. Gilt für alle bestehenden und neuen Formulare, auch die öffentlichen Generatoren. Websiteweit: auch jedes select außerhalb eines .form-field (Tabellen, Modals, per Skript erzeugte Felder) übernimmt über die Basisregel select die Schrift EB Garamond, Pfeil, Rahmen und Fokus; Browser-Standardschrift ist nicht erlaubt. Kompakte Varianten ändern nur Schriftgröße (--size-body-sm) und Innenabstand.

Formularfehler

• Live Fehler stehen direkt unter dem betroffenen Feld, nicht gesammelt oben: der Rahmen des Feldes wechselt auf --bad-ink, darunter steht die Meldung (.field-error, 14px, --bad-ink). Formulierung: konkret, sagt was zu tun ist und nennt wenn möglich ein Beispiel („Bitte die Zielzeit als hh:mm:ss angeben, z. B. 03:45:00.“), ohne Schuldzuweisung und ohne Fachjargon. Verhalten: Beim Absenden scrollt die Seite zum ersten fehlerhaften Feld (Reihenfolge wie im Formular) und setzt dort den Fokus; ein Hinweis am Absende-Button nennt die Anzahl der markierten Felder. Die Meldung eines Feldes verschwindet, sobald man es ändert. Auch Fehler aus der Berechnung werden dem passenden Feld zugeordnet. Technisch: aria-invalid="true" am Feld, aria-describedby auf die Meldung, role="alert". Die grüne bzw. rote Box (.form-success/.form-error) bleibt dem Ergebnis des ganzen Formulars vorbehalten.

Checkbox

• Live websiteweit eckig, ohne Border-Radius: 18px Quadrat, 1px Rahmen in --ink-500, weißer Grund; angehakt in der Akzentfarbe gefüllt mit weißem Haken. Hover und Fokus in der Akzentfarbe. Gilt für jedes input[type=checkbox] (nur der Burger-Schalter der Navigation ist ausgenommen), neue Formulare brauchen keine eigene Klasse.

Rückweg

• Live jede Dashboard-Unterseite endet mit dem Button „Zum Dashboard“ (partials/dash-back.html.twig, Outline-Button am Seitenende, außerhalb der Tabs). Der Eyebrow einer Dashboard-Unterseite nennt nur den Bereich, ohne „Dashboard ·“. Neue Dashboard-Seiten binden das Partial am Ende ein.

Fakten-Liste

• Live zweispaltig: links die Bezeichnung (Mono, Großbuchstaben, 130px), rechts der Wert in eigener Spalte, damit umbrechender Text unter dem Wert und nicht unter der Bezeichnung steht. Aufbau <li><span>Label</span><div>Wert</div></li>.

Aktionen in Karten und Zeilen

• Live Buttons unter Fließtext in einer Karte haben 24px Abstand zum Text (Selektor .card .card-action, damit er die Absatz-Regel der Karte schlägt). Mehrere Buttons nebeneinander stehen in .btn-row (12px Abstand, brechen um). Verweise wie „Aktiven Plan ansehen“, „Zum Plan-Generator“ und „Abmelden“ sind Outline-Buttons (btn btn-outline on-light, in Karten btn-sm), keine Textlinks.
• Live Bearbeiten und Löschen stehen rechtsbündig nebeneinander als btn-sm-Outline-Buttons. „Bearbeiten“ klappt darunter das Formular im .pe-panel-Stil auf (Akzentstreifen, vorbefüllt), der Knopf wechselt zu „Schließen“; „Änderung speichern“ ist primär, „Abbrechen“ Outline.

To-do-Liste (Themenplan)

• Live Dashboard-Seite /dashboard/themenplan (Template dashboard-themenplan): oben Kennzahlen (.plan-stats) und je Welle ein Fortschrittsbalken (.tp-bar: voll in Akzent = live, halb transparent = in Arbeit, grau = offen). Darunter Filter (Welle als .btn-filter, Status, Themenfeld, Suche) und die Liste .tp-list. Jeder Eintrag (.tp-item) zeigt die ID in Mono und Akzent, den Titel in Cormorant (normale Schreibung), Pills für Welle, Kategorie, Typ und Aufwand, rechts Status-Auswahl und Termin, dazu „Details“. Die Details (.tp-detail, Akzentstreifen, --surface-alt) listen Frage, Mehrwert, eigene Daten, Verlinkung, Quellenansatz, Länge und Inspiration als dl.tp-facts und bieten Notiz und Link zum Bearbeiten. Änderungen speichern sofort (Status, Termin, Notiz, Link), eine kleine Meldung unter dem Eintrag zeigt „Gespeichert“ oder den Fehler. Die Grundliste liegt im Plugin (data/themenplan.json), die Eingaben getrennt im Datenordner (themenplan-status.json).

Roadmap

• Live Dashboard-Seite /dashboard/roadmap: aufklappbare Phasenkarten (.rm-phase, offene Phase mit Akzentrahmen) mit Titel in Cormorant, Pills für erledigte Aufgaben und erfüllte Kriterien, Prognosezeile in Mono und Akzentfarbe (.rm-forecast), Abschlusskriterien als Checkbox-Liste (.rm-gate, --surface-alt) und darunter die Aufgabenliste im Stil der To-do-Liste (.tp-item). Aufgaben tragen Pills für Stufe (Muss in Warnfarbe, Soll und Kann neutral) und Stundenrichtwert, Status, Termin, Notiz, Phase zum Verschieben und Stufe. Eigene Aufgaben (.rm-add) lassen sich je Phase ergänzen und wieder löschen. Die Wochenzeit oben bestimmt die Prognose (Rest-Stunden geteilt durch Stunden pro Woche). Phasen sind flexibel: Es zählen Reihenfolge und Kriterien, keine Termine.

Dokumentationsseite

• Live Aufbau für lange Erklärtexte im Dashboard (dashboard-dokumentation-seite.html.twig): zweispaltig mit klebendem Inhaltsverzeichnis links (.doc-toc, wird aus den h2 mit id erzeugt, markiert den aktuellen Abschnitt) und Inhalt rechts (.doc-content, max. 820px). Bausteine: Einstiegsabsatz .doc-lead, nummerierte Schritte .doc-steps, Prozesskette .doc-chain, Zeitleiste .doc-timeline, Hinweisbox .doc-note (orange) und .doc-note.is-info (grau), Abbildung mit Inline-SVG .doc-figure (Klassen .dg-*, nur Theme-Farben), Glossar .doc-glossary. Texte für Einsteiger stehen im normalen Fließtext, technische Details in aufklappbaren Abschnitten (details.doc-tech), die der Knopf im Inhaltsverzeichnis gesammelt öffnet. Mobil steht das Verzeichnis über dem Inhalt.

Bearbeiten-Panel & Protokoll

• Live klappt unter einer Zeile auf (Tabellenzeile mit [hidden]), hellgrauer Grund (--surface-alt), 3px Akzentstreifen links, Felder als .form-field (Beschriftung Mono, Auswahlfeld mit eigenem Pfeil). Eine Aktion pro Gruppe (.pe-group): Feld plus btn-sm-Button (primär für die Hauptaktion, Outline für Nebenaktionen). Ergebnisse und Fehler erscheinen darunter als .form-error bzw. .pg-notice.warn. Der Knopf der Zeile wechselt zwischen „Ändern“ und „Schließen“. Änderungsprotokoll (.plan-rev): Karte pro Änderung mit Zeitpunkt in Mono, Pill für die Quelle (Manuell neutral, Agent grün) und „rückgängig gemacht“ in Warnfarbe; zurückgenommene Einträge sind auf 60 % abgeblendet.

Aufklappbare Wochen

• Live details mit Titel in Cormorant, Meta in Mono, eigener Pfeil (dreht beim Öffnen), aktuelle Woche mit Akzentrahmen und offen.

Offene Vorschläge

• Live Karte mit Akzentrahmen (1px, --accent) für Entscheidungen, die auf dich warten: Zeitpunkt in Mono, Pills für Quelle („Agent“) und „Probemodus“ (Warnfarbe), Titel in Cormorant, Begründung gedämpft, darunter die einzelnen Änderungen als Checkbox-Liste (alle vorgewählt, Zeilen mit Trennlinie) und die Aktionen „Ausgewählte anwenden“ (primär) und „Verwerfen“ (Outline). Mit mehreren Möglichkeiten stehen statt der Checkboxen Radiobuttons (empfohlene Option vorgewählt, Pill „empfohlen“), darüber die Einschätzung des Agenten (.plan-prop-ki: Mono-Beschriftung, 3px Akzentstreifen links, --surface-alt). Fragen des Agenten tragen die Pill „Frage“ und die Aktionen „Ja, einplanen“ / „Nein, danke“.

Vorschlagsverlauf

• Live Zähler (Mono-Beschriftung, Zahl in Cormorant) nebeneinander mit Umbruch, darunter eine data-table mit Datum, Art (Pills „automatisch“, „Probemodus“), Vorschlag und Ausgang als Pill (übernommen grün, abgelehnt neutral, verfallen Warnfarbe). Die Quelle „Automatisch“ im Änderungsprotokoll nutzt dieselbe grüne Pill wie „Agent“.

Befinden

• Live Reihe aus Datum (Mono, klein) und Pill mit dem Wert 1 bis 5 (1 rot, 2 Warnfarbe, 3 neutral, 4 und 5 grün), umbrechend. Befinden-Skala in der Tagesmail: fünf quadratische Knöpfe mit Mono-Ziffer, Outline in Schwarz; die schon gegebene Antwort ist Akzent gefüllt. Darunter eine kleine Legende (1 = sehr schlecht, 5 = sehr gut).

Aufbau

• Live Alle versendeten Mails folgen dem Styleguide: schwarzer Kopf mit Logo, weiße Inhaltsfläche (max. 640px, 1px Rahmen in --line), schwarzer Fuß mit Links in der Akzentfarbe, Hintergrund --ink-050. Schriften wie auf der Website (Überschrift Cormorant Garamond in Großbuchstaben mit weiter Laufweite, Text EB Garamond, Beschriftungen IBM Plex Mono), mit Rückfall auf Garamond/Georgia bzw. Courier, falls das Mailprogramm Webfonts nicht lädt. Mindestgrößen: Text 17px, Details und Tabellen 15px, Beschriftungen und Kleingedrucktes 13px, Buttons 14px. Bausteine: Eyebrow in Mono und Akzentfarbe, Hinweisbox warn/info wie .pg-notice, Pill wie .pill, Button primary (orange) und outline, eckig. Webfonts (Google Fonts) werden nur in Mails an dich selbst nachgeladen, nicht in Mails an Dritte. Quellen: Renderer.php (Agent-Mails, Antwortseiten) und templates/email/base.html.twig mit den Vorlagen email/rtc-*.html.twig (Formular- und Login-Mails).

Fuß

• Live zentriert auf Schwarz: „777 | Run The Continents“ (Mono, Versalien, weiß), Name, Kontakt-Adresse, dann „Impressum · Datenschutz · Kontakt“, „Folgt mir:“ und Instagram, Facebook, X, YouTube (Akzentfarbe, alle absolut verlinkt). Gilt für Agent-Mails (Renderer::footer()) und alle Site-Mails (email/base.html.twig). Das Twitter-Logo ist überall durch das X-Logo ersetzt.

• Warmes, ungefiltertes Licht, echte Rennsituationen — kein Beschnitt zu Kreisen, keine Duotone-Filter.
• Schutz von Text über Fotos immer über einen vollflächigen dunklen Verlauf (--gradient-scrim), nie über eine Box hinter dem Text.
• Erfolge-Timeline: neueste zuerst — Die Einträge stehen in ueber-mich.md chronologisch (ältester zuerst), das Template dreht die Reihenfolge um (h.timeline|reverse), damit der neueste Erfolg oben steht. Neue Einträge werden also unten an die Liste angehängt.
• Erfolge-Timeline: verbindlich Hochformat 2:3 — Renn-/Zieleinlauf-Fotos für die Timeline (/ueber-mich, .timeline-item img) werden als Hochformat mit Seitenverhältnis 2:3 bereitgestellt (z. B. 1000×1500px oder 1333×2000px wie das Tokio-Foto). CSS nutzt aspect-ratio:2/3; object-fit:cover; — leichte Abweichungen vom exakten Verhältnis werden mittig beschnitten, das Hauptmotiv sollte deshalb zentriert im Bild stehen, nicht am Rand. Querformat-Fotos wirken in der schmalen Timeline-Spalte zu klein/gequetscht, deshalb bewusst nur ein Format statt zwei.

Artikel-Baukasten

• Live Optionale Felder im Frontmatter eines Blog-Artikels: description (Meta-Beschreibung, sonst Textanfang), faq (Liste aus q und a; erscheint als Abschnitt „Häufige Fragen“ und als strukturierte Daten FAQPage), sources (Liste aus title, optional url und note; Abschnitt „Quellen“), toc: true (Inhaltsverzeichnis aus den Zwischenüberschriften bei mindestens drei) und medical: true (Hinweisbox; erscheint automatisch bei den Kategorien Medizin und Ernährung). Die Box .post-note nutzt die Warnfarbe mit Akzentstreifen, das Inhaltsverzeichnis .post-toc den grauen Grund mit Akzentstreifen. Artikel ohne diese Felder bleiben unverändert.
• Live Tabellen im Artikel: Tabellen, die im Markdown geschrieben werden (| Spalte | Spalte |), übernehmen automatisch das Design von .data-table: weiße Fläche, 1px Rahmen, Kopfzeile in Mono und Großbuchstaben auf --surface-alt, erste Spalte halbfett, Versalziffern in gleicher Breite. Ein Skript legt sie in .table-scroll, damit sie mobil seitlich scrollen statt zu überlaufen. Keine eigenen Tabellenstile pro Artikel.
• Live Hervorhebungskästen im Artikel: drei Varianten als HTML im Markdown, <div class="post-callout is-merke"> (grauer Grund, Akzentstreifen, Beschriftung „Merke“, für die Kernaussage), is-check (weiße Fläche mit Rahmen und Kästchen-Liste, „Schnell-Check“) und is-fazit (schwarzer Grund mit weißer Schrift, „Fazit“ am Ende). Aufbau: <span class="label"> plus <p> oder <ul>; innerhalb des Kastens wird kein Markdown ausgewertet. Meist ein Kasten je Variante, bei langen Artikeln zwei Merke-Kästen (die Beschriftung ist frei, zum Beispiel „Faustregel“). Die Schreibregeln stehen im Kapitel „Ton & Sprache“ unter „Artikel schreiben“.
• Live Bilder mit Bildunterschrift: <figure class="post-figure"><img src="…" alt="…" loading="lazy"><figcaption>…</figcaption></figure>, volle Textbreite, Bildunterschrift klein und gedämpft. Screenshots als WebP in 1200 px Breite ablegen, ohne Browser-Tabs und private Angaben; nach einem </figure> immer eine Leerzeile lassen.
• Live KI-Titelbild: Frontmatter hero_ai: true setzt am Artikelende den Hinweis „Hero-Bild: KI-generiert“ (wie auf digmarketing.de, siehe Redaktionelle Grundsätze). Bilder im Text, die überwiegend KI-erzeugt sind, tragen „Bild: KI-generiert“ in der Bildunterschrift.
• Live Kommentare: erscheinen unter jedem Blog-Artikel (Abschnitt .bc): Liste mit Name, Datum, Text, Herz-Zähler und „Antworten“, darunter das Formular mit Rechenaufgabe und Zustimmung zur Datenschutzerklärung. Antworten des Autors tragen das Badge „Autor“ (pill-good). Neue Kommentare sind erst nach der Freigabe im Dashboard (/dashboard/kommentare) sichtbar. Abschalten pro Artikel mit comments: false.
• Live Titelbild für Handys: Frontmatter hero_image_mobile (Hochformat 4:5, 800 × 1000 px, Ausschnitt aus dem Querformat). Bis 640 px Breite lädt der Browser dieses Bild und zeigt es im Format 4:5, sonst gilt das Querformat in 16:9. Ohne das Feld bleibt es beim Querformat. Erzeugen mit dev/themenplan/hochformat.py.

• Erste Person Singular, direkt. Kein „wir", keine Marketing-Adjektive, keine Ausrufezeichen außer bei echten News.
• Keine Emoji. Rückschläge werden nüchtern benannt, nicht schöngeredet.
• Zahlen tragen die Aussage — nicht runden, deutsches Zahlenformat (Komma/Punkt).
• „Mehr erfahren"-Links als literales >>, kein Pfeil-Icon.
• Kein Gedankenstrich in Fließtexten. Statt „Text – weiterer Gedanke" lieber ein eigener Satz, ein Komma mit „weil"/„da"/„sonst" oder ein Doppelpunkt für Aufzählungen. Ausnahme: Zahlenbereiche wie Pace-Angaben (5:15–5:25/km) oder Wochen-Spannen (Woche 1–4) bleiben mit Bis-Strich, das ist keine Satzzeichen-Pause. Betrifft Lede, Section-Notes, Card-Texte, Warnhinweise und alle anderen Inhalte für Besucher:innen.

Artikel schreiben (Leitfaden)

• Haltung. Zuerst die Situation, dann die Erklärung: Jeder Artikel beginnt in den ersten 300 Wörtern mit einer echten Läufersituation. Ich schreibe als Läufer, der ein Problem hatte, und belege Aussagen mit Quellen, Zahlen und ehrlichen Grenzen. Es wird nichts erfunden: Szenen, Zweifel und Beobachtungen stammen aus eigenen Daten oder Angaben. Die Szene wird wahrnehmbar (was ich gesehen, gedacht, getan habe), Zweifel nur, wo er echt war. Mindestens eine Perspektive je Artikel: eigene Erfahrung, Beobachtung im Verein oder Wettkampferfahrung. Sicherheit wird abgestuft: belegt, Faustregel oder eigene Erfahrung, Unsicheres bleibt unsicher.
• Aufbau. Der Untertitel hat drei bis vier Sätze, fasst den Inhalt zusammen und macht Lust aufs Lesen. Die Kernaussage steht früh. Die Reihenfolge lautet: was passiert ist, warum, dann die Forschung; Studien und Formeln stützen die Geschichte, sie tragen sie nicht. Jeder Abschnitt gibt dem Leser einen Nutzen, jede Kernaussage steht einmal ausführlich, die FAQ beantwortet nur echte Zusatzfragen. Jeder Artikel hat einen Merksatz zum Mitnehmen (Merke- oder Faustregel-Kasten). Zwischenüberschriften nennen den Nutzen oder die Frage des Lesers, ohne Clickbait. Zahlen werden erklärt, Studien eingeordnet.
• Stil. Maßstab ist brand eins: journalistisch, anschaulich, verständlich, mit leichter Ironie statt Akademikerton. Absätze bestehen aus drei bis fünf verbundenen Sätzen (im Schnitt 40 bis 70 Wörter, nie über 100), kurze und lange Sätze wechseln sich ab, eine Reihe von Kurzsätzen wirkt abgehackt. Listen nur für Abläufe und Checks, Erzählendes bleibt Fließtext. Prüffrage: Würde ich das so in einem Magazin lesen wollen? Die Vorprüfung misst den Anteil sehr kurzer Sätze (höchstens 25 %).
• Sprache. Floskeln wie „darüber hinaus“, „nicht zuletzt“, „wichtig ist“, „besonders wichtig“, „außerdem zeigt sich“, „zusammenfassend“, „grundsätzlich“, „im Rahmen von“, „eine Vielzahl“, „wertvolle Erkenntnisse“, „essenziell“, „entscheidend“ und „von Bedeutung“ werden gestrichen, nicht durch Füllwörter wie „tatsächlich“ oder „konkret“ ersetzt. Weitere Muster: „nicht nur … sondern auch“, Dreierlisten als Reflex, rhetorische Fragen als Überleitung, Superlative.
• Schluss. Das Fazit ist eine Erkenntnis, keine Zusammenfassung, und besteht nur aus Belegtem oder Erlebtem.
• Artikeltypen. Erfahrungsbericht: Szene, Erkenntnis, Erklärung, Folgen, Fazit. Ratgeber: Situation, Problem, Erklärung, Lösung, Kasten, Fazit. How-To: Ergebnis und Voraussetzungen, nummerierte Schritte, typische Fehler, Prüfung. Pillar: Orientierung mit Inhaltsverzeichnis, Kapitel mit eigenen Situationen, Verweise auf Einzelartikel.
• Prüfung vor der Veröffentlichung. Läufersituation in den ersten 300 Wörtern? Eigene Erfahrung, Vereinsbeobachtung oder Wettkampferfahrung? Löst jeder Abschnitt ein konkretes Problem? Floskeln entfernt, Wiederholungen gestrichen? Würde ich es einem Laufkollegen so erzählen? Ein überraschender Gedanke? Jede Statistik erklärt? Absätze smartphonefreundlich und flüssig statt abgehackt? Fazit als Erkenntnis? Jede Behauptung belegt, nichts erfunden? Unsicheres gekennzeichnet? Hinweis und fachliches Gegenlesen bei Medizin und Ernährung? Klarer nächster Schritt (Tool, Folgeartikel)? Untertitel, Meta-Beschreibung, FAQ und Quellen vollständig?