{"name":"ZVV Atlas Showcase","description":"Living Documentation der ZVV Atlas Foundation — jedes Pattern als lauffähige Referenz.","atlasVersion":"0.2","repo":"https://github.com/zvvch/zvv-atlas","docs":"https://zvvch.github.io/zvv-atlas","live":"https://atlas.zvv.dev","contact":"ict@zvv.zh.ch","version":"0.0.0","commit":"8a0d6695c7f5aa13d4f2df4e79c3ba5f26c75959","buildTime":null,"environment":"production","atlas":{"latestVersion":"0.3.0","releases":{"count":6,"items":[{"version":"0.3.0","date":"2026-08-11","body":"### Changed — die offenen Spec-Entscheidungen sind gefallen und umgesetzt\n\n- **Alle 19 Fragen von `/entscheidungen` sind beantwortet** (MRA, 6. August 2026; Entscheidungsblock am Ende von `docs/proposals/ungedeckte-luecken.md`): zwölf Empfehlungen der Papiere bestätigt, vier eigene Entscheide (CSP-Nonces aus der Middleware, neutrale Rate-Limit-Antwort, Durchsetzung in der Server-Action, Kundenradar-Deck bleibt unter `/info`), drei ehrlich offen gehalten — die zwei Rate-Limit-Zahlen liegen beim Betrieb, die CTA-Zieladresse bei der Betriebsstelle.\n- **Geschlossen und aus `LUECKEN` entfernt:** L02 (E2E ist App-Entscheid; Rückweg über `patterns/e2e.md`), L03 (Datumszusage gestrichen, Guide entsteht aus dem ersten realen Migrations-PR), L08 (Referenz-Zeile + Legende in der Drift-Tabelle), L09 (Toolchain von `packages/atlas` deklariert, Atlas-CI installiert per `npm ci` reproduzierbar).\n- **Spec-Erweiterungen mit Conformance-Wirkung (Minor):** `02` §3.6 Rate-Limit-Mechanik (neutral, Server-Action) · `06` §5 Magic-Link-TTL 60 Minuten samt Supabase-Einstellort · `10` §5.1 `zvv_`-Namenskonvention für Rollen · `10` §7.1 Baseline-CSP mit Nonces (Stufe 1: Report-Only, Referenz `example/proxy.ts`) · `13` §9 Meta-Routen (`/info` Pflicht, `/changelog` ab Versionierung, `/docs` optional) und Versionierungs-Doktrin `version + commit + buildTime + environment`.\n- **Reduziert statt geschlossen, bewusst:** L04 (Report-Only bis zum Release-Zyklus ohne Verstösse), L05 (Sichtprüfung, einzige Lücke ohne Wächter). L06a und L07 sind noch am selben Tag per Delegation entschieden — 5 Anfragen/h pro Adresse und 20/h pro Quell-IP samt kopierbarem Fixed-Window-Muster (`02` §3.6), der CTA «Konto beantragen» zeigt auf `mailto:ict@zvv.zh.ch`. Alle Wächter sind umgedreht und halten den entschiedenen Zustand fest.\n\n### Changed — `/info` lässt sich durchscrollen\n\n- **Das Deck war eine Umschalt-Präsentation; das Mausrad tat nichts.** Wer ein Deck geschickt bekommt, probiert aber zuerst zu scrollen — eine Seite, die darauf nicht reagiert, wirkt kaputt. Jetzt eine echte Scroll-Bahn mit `scroll-snap-type: y mandatory`, jede Slide ein Rastpunkt.\n- **Bewusst kein Scroll-Hijacking.** Das Mausrad wird nicht abgefangen: Rad, Trackpad, Wischen, Scrollbalken und Tastatur nehmen denselben nativen Weg. Die Slides liegen dafür in Leserichtung im DOM statt absolut übereinander — der `aria-hidden`-Riegel auf den inaktiven Slides fällt weg, was scrollbar erreichbar ist, gehört auch in den Accessibility-Baum.\n- **Zähler und Punkte werden gerechnet, nicht beobachtet.** Ein `IntersectionObserver` liefert in einem nicht gezeichneten Dokument gar keine Einträge — in genau der Lage gemessen und verworfen; dieselbe Falle stellt `requestAnimationFrame`. Der Einblend-Effekt ist Zutat statt Voraussetzung: Bis die Messung übernimmt, ist jede Slide sichtbar, sonst wäre die Seite ohne JavaScript leer.\n- **Fussangel behoben:** Die Pfeiltaste rechts navigierte auf der letzten Slide still aus dem Deck. Beim Scrollen erreicht man das Ende viel häufiger — der Absprung gehört jetzt allein dem beschrifteten Knopf, wie die Deck-Spec ihn auch beschreibt.\n\n### Fixed — Geist Mono war dokumentiert, aber nie geladen\n\n- **`/typography` zeigte den Import aus `geist/font/mono`, der Showcase lud ihn nie:** `--font-geist-mono` war ein reiner System-Fallback, Code rendert bisher in Consolas beziehungsweise Menlo. Jetzt ist das Paket installiert und `GeistMono.variable` am ``; die Fallback-Kette steht als `var()`-Default in der kanonischen `assets/color-tokens.css`.\n\n### Fixed — die Mindestbreite galt überall und war nirgends erfüllbar\n\n- **`docs/01` §1 forderte 80 px (mobil) / 120 px (Desktop) Logobreite — und keine einzige Logo-Platzierung in Atlas hielt sie ein.** Topbar 40 px, Sidebar-Kopf 44 px, eingeklappte Rail 36 px, OG-Karte 74 px. Erfüllt war die Regel nur auf der Login-Seite und in der `/brand`-Seite, die sie erklärt. Die Spec war in der eigenen Referenz-Shell geometrisch nicht erfüllbar: 120 px Breite ergeben 55 px Höhe, mit Schutzraum 83 px — ein Band dieser Höhe ist keine Topbar mehr.\n- **Die Ursache war eine Zahl, die zwei Dinge meinte.** «Mindestbreite» stand für ein **Präsenz-Minimum** (wie gross muss die Marke auftreten, wo sie allein für den Absender steht), begründet wurde sie aber mit **Lesbarkeit** («darunter wird das Logo unleserlich»). Deshalb las jeder sie als universell, und deshalb brach sie überall dort, wo das Logo als Herkunftsmarker in der Chrome sitzt statt als Absender auf einer Markenfläche.\n- **Die Regel hat jetzt einen Geltungsbereich** — drei Flächenarten statt einer Zahl: **Markenfläche** (Login, Deckblatt, Mail-Kopf, Print, Hero) behält 80/120 px Breite · **Anwendungs-Chrome** (Topbar, Sidebar-Kopf, Footer) misst in der **Höhe**, ≥ 20 px, Standardmass `43 × 20` · **ohne CSS gerendert** (OG-Karte, PDF) misst als Anteil der Fläche, ≥ 5 % der Canvas-Höhe. Die Chrome misst in der Höhe, weil die Höhe das ist, was ein Band tatsächlich beschränkt. Und «px» ohne Bezugsrahmen ist bedeutungslos: Die OG-Karte rendert 74 px auf 1200 px Canvas — in einer Teams-Vorschau sind das effektiv rund 31 px.\n- **Neue Konstanten `LOGO_MIN_HOEHE_CHROME` und `LOGO_CHROME`** in `@zvvch/atlas/brand`. Die bestehende `LOGO_MIN_BREITE` bleibt, trägt aber jetzt im Doc-Kommentar, wofür sie gilt.\n- **`LOGO_MIN_BREITE` war seit v0.1 exportiert und wurde von keinem Layout je gelesen** — ausgerechnet mit der Begründung, «damit ein Layout sie rechnen kann statt sie zu schätzen». Genau deshalb fiel der Widerspruch drei Versionen lang niemandem auf. Eine Zahl, die niemand prüft, ist eine Notiz. Neuer Wächter-Block in `example/tests/brand.test.ts`: Standardmass hält die Untergrenze · Breite ist aus der Höhe gerechnet · Topbar und Sidebar setzen kein eigenes Mass · die eingeklappte Rail trägt Logo plus Schutzraum. **Gegengeprüft, dass alle vier rot werden:** Rail auf `w-14` zurückgesetzt und `width={40}` am Logo hartkodiert — beide Male rot, nach dem Zurücknehmen wieder grün.\n- **Der Wächter fand sofort eine Drift, die niemand gesucht hatte:** Das Standardmass `44 × 20` aus der App-Shell war selbst off-ratio — `round(20 × 2,173895) = 43`, nicht 44. Zwei von Hand getippte Zahlen, 2,20 statt 2,174. Korrigiert auf **`43 × 20`**; gesetzt wird ab jetzt die Höhe, die Breite ist gerechnet.\n- **Die eingeklappte Rail wächst von `w-14` auf `w-16`.** 43 px Logo + 2 × 5 px Schutzraum + 2 × 4 px Padding = 61 px; in 56 px blieben dem Schutzraum 2 px statt 5, und die Rail-Kante stünde im Schutzraum. Die Rail-Breite folgt jetzt aus dem Logo, nicht umgekehrt. Das eingeklappte Sonder-Mass `36 × 17` entfällt — die Identität schrumpft nicht, nur weil die Rail schmal wird.\n- **`docs/03` §2.1 forderte `text-zvv-primary` für den App-Namen, die Referenz-Topbar rendert ihn ohne Farbe.** Hier war die Doku die falsche Seite, aus drei unabhängigen Gründen: `patterns/logo-anwendung.md` §4 (Spec) verbietet eine Zweitfarbe neben dem Logo, `--color-zvv-primary` ist ein festes Hex **ohne Dark-Variante** (es existiert für Satori und Mail, wo HSL-Tokens nicht greifen), und auf dem Dark-Card landet es gemessen bei 4,09:1 — unter WCAG AA für 14-px-Text. Die Forderung ist gestrichen, der Grund steht daneben, damit sie nicht zurückkommt.\n- **Nebenbei:** `example/app/(showcase)/brand/page.tsx` rechnete mit hartkodiertem `/ 2.17` statt `ZVV_LOGO_VERHAELTNIS` — eine zweite Wahrheit für das Seitenverhältnis, ausgerechnet in der Demo, die das Rechnen aus einer Grösse vorführt.\n\n**Conformance-Wirkung:** keine App wird rückwirkend nicht-konform — die Spec wird präzisiert und in genau einer Richtung gelockert. Beim nächsten Release ist das ein **Minor**.\n\n### Added — die Topbar-only-Variante hat endlich eine Implementierung\n\n- **`docs/03` §2.1 spezifizierte die Topbar-only-Ausprägung vollständig — acht Pflicht-Elemente, `h-16`, eine Textfarbe für den App-Namen — und nichts im Showcase baute sie.** Genau deshalb konnten dort eine Bandhöhe und ein `text-zvv-primary` stehen, denen die reale Referenz-Topbar widersprach, ohne dass es je auffiel. **Eine Spec, der kein Code widersprechen kann, driftet unbemerkt** — dieselbe Fehlerklasse wie die nie gelesene `LOGO_MIN_BREITE`.\n- **Neu `example/components/layout/topbar-brand.tsx`** — die echte Komponente, nicht ein für den Showcase nachgezeichnetes Band: Logo im Chrome-Standardmass, App-Name als Text ohne Zweitfarbe, Breadcrumb, Pills-Nav mit Pre-Login-Zustand, Divider, User-Menü, Theme-Toggle. Vorgeführt in `/navigation` im Rahmen, nach dem Muster, das die Login-Vorschau gesetzt hat: **kein kopiertes Markup**, sondern dieselben Bausteine, die eine echte App verwendet.\n- **Drei Wächter darauf** — Bandhöhe aus §2.1, Band trägt Logo plus Schutzraum, App-Name ohne Zweitfarbe. Gegengeprüft: `h-16`→`h-12` und ein eingefärbter App-Name machen sie rot, zurückgenommen wieder grün.\n\n### Added — die App-Shell lernt vom besten Schüler\n\n- **Der Showcase hatte die schwächere Navigation als FZDB** — eine entkoppelte Topbar mit zentriertem Logo, eine Sidebar ohne Identitäts-Anker, kein Breadcrumb. Nach dem Drift-Grundsatz (CLAUDE.md §6) ist das ein Atlas-Bug: das FZDB-Muster ist jetzt als Pattern geschärft, nicht der Showcase als Einzelfall geflickt.\n- **Neu [`patterns/app-shell.md`](./patterns/app-shell.md)** (Guideline): Drei-Zonen-Shell — full-height Sidebar als **Identitäts-Anker** (ZVV-Logo + App-Name + Mandanten-Chip oben, ⌘K-Suche direkt darunter, Gruppen-Nav mit Uppercase-Labels in der Mitte, Einklappen-Toggle + Konto-Zeile mit User-Karte und Notification-Bell unten), Topbar als **Arbeitszeile** in drei Zonen (Breadcrumb nur mit Eltern-Ebenen links, Seitentitel zentriert, seitenbezogene Aktion + Theme rechts). Grundregel „keine Doppel-Identität\": jede Ecke beantwortet genau eine Frage — Chip „wessen Daten\", User-Karte „wer bin ich\", Titel „wo bin ich\".\n- **Zwei Linien über die ganze App:** Die Bänder sind in beiden Spalten gleich hoch — oben `h-12` (Identitäts-Header · Arbeitszeile), unten `h-14` (Konto-Zeile · Footer). Ihre Kanten ergeben zwei durchgehende horizontale Linien. Die erste Fassung hatte einen ~90 px hohen Kopf gegen eine 48-px-Zeile und einen 112-px-Fuss gegen einen 66-px-Footer; an der Sidebar-Kante entstanden zwei Stufen, die die Spalten wie getrennte Seiten wirken liessen.\n- **In einer flachen App ist die Nav-Gruppe die Eltern-Ebene des Breadcrumbs.** Der zentrierte Titel verlangt, dass der Breadcrumb die aktuelle Seite weglässt — auf einstufigen Routen wie `/tokens` bleibt danach aber nichts übrig, weil der Weg dort nur aus der Seite selbst besteht. Die Gruppe aus `NAV_GROUPS` füllt die Lücke (`⌂ › Foundation` + Titel „Color-Tokens\") und ist bewusst kein Link: eine Gruppe ist eine Ordnung, keine Route. Vorbild ist Vercels „All Projects\" links neben dem Seitentitel.\n- **Aus der Regel folgt die Platzierung, nicht umgekehrt.** Mandanten-Chip und Suche stehen **unter** der oberen Linie statt im Kopf. Der **Einklappen-Toggle wanderte in die Arbeitszeile** — sonst bräuchte das untere Band zwei Zeilen. Das ist zugleich shadcns kanonische `SidebarTrigger`-Position und hat den Nebeneffekt, dass der Toggle in beiden Rail-Zuständen an derselben Stelle liegt. Im Icon-Modus zieht die Notification-Bell mit in die Arbeitszeile, weil im 56-Pixel-Rail neben dem Avatar kein Platz ist.\n- **Muster verifiziert statt nur kopiert:** Die Verteilung deckt sich mit shadcn/ui's Sidebar-Anatomie (`SidebarHeader` = „branding/workspace switchers\", `SidebarFooter` = „user menus\"), den gängigen SaaS-Navigations-Analysen (Konto als Utility ans Sidebar-Ende, Topbar nur für global Gültiges) und dem Vercel-Dashboard als Reinform (Team-Switcher oben links, Suche in der Sidebar, User + Bell unten links, Topbar fast leer). Die erste Fassung hatte Name/Rolle dreifach (Chip, Begrüssung, User-Karte) — die Begrüssung flog raus, die Rolle steht nur noch unten.\n- **`docs/03-navigation.md` nachgezogen:** §1 Drei-Zonen-Layout, §2 in zwei Ausprägungen geteilt (Topbar-only als Brand-Träger vs. Arbeitszeile), §3.0 die Sidebar-Etagen inkl. Suche und Konto-Zeile, §4 Home-Icon statt App-Name als erstes Breadcrumb-Element und Eltern-only-Breadcrumb bei zentriertem Titel.\n- **Eine Korrektur gegen die Referenz selbst:** FZDB zeigt im Sidebar-Header kein Original-ZVV-Logo, nur einen Text-Platzhalter. Atlas übernimmt die FZDB-Struktur, macht das Original-Logo aber zur Pflicht (01 · Identity) — die Lücke steht als Drift-Notiz im Kapitel und gehört ins FZDB-Backlog.\n- **Showcase umgebaut** (`example/components/layout/`): Sidebar full-height mit Identitäts-Header, Suche und Konto-Zeile (Persona-Karte + Mock-Bell), Topbar als Drei-Zonen-Arbeitszeile mit zentriertem Seitentitel, `AppShell` als echte Drei-Zonen-Komponente statt totem Code. Sidebar, Topbar und Footer teilen eine Fläche (`bg-card` / `dark:bg-muted/30`) und bilden einen Chrome-Rahmen um den Content-Canvas.\n\n### Added — ein Grössen-Budget, das das Erreichte hält\n\n- **Ohne Wächter ist eine Aufräumaktion eine Aufräumaktion mit Verfallsdatum.** Auf drei Routen fielen rund 1 MB weg, nur weil zwei statische Importe auf `next/dynamic` umgestellt wurden. Der nächste statische Import einer schweren Bibliothek stellt den alten Zustand wieder her — und niemand merkt es, weil die Seite ja funktioniert.\n- **`npm run groessen`** startet den gebauten Server, misst je Route das **eager** geladene JavaScript und vergleicht es mit `example/bundle-baseline.json`. Neuer CI-Schritt **nach** dem Build.\n- **Gemessen statt geschätzt.** Der Wert kommt aus den `