/* ========================================================================= DER ARBEITSBEREICH VON BELEGHERO Gilt nur fuer body.bp-app. Die Website laedt diese Datei nicht. Grundlage: docs/DESIGN-SOFTWARE.md ------------------------------------------------------------------------- WOHER DIE VORBILDZAHLEN STAMMEN (SideChat, 08.08.2026) KONVENTION: Ein Kommentar mit einer ZAHL nennt eines der Kuerzel unten. Kommentare ohne Kuerzel sind BESCHREIBEND (etwa "die Vorbilder machen das nie") und ausdruecklich NICHT gemessen - sie taugen als Begruendung, nicht als Beleg. Wer aus einem solchen Satz eine Zahl ableitet, misst sie vorher. Jede Zahl in dieser Datei, die sich auf ein Vorbild beruft, ist an einer dieser Dateien GEMESSEN - nicht abgelesen, nicht erinnert: S-BELEGE docs/vorbilder/665983e3a3c4c73837183773_sevdesk-belege- verwalten-desktop.webp 1528x1112, Massstab 1x S-DASH docs/vorbilder/sevdesk-dashboard-desktop@3x-scaled.webp 2560x1863, Massstab 1,69 (NICHT 3, trotz Dateiname) S-RECHNUNG docs/vorbilder/68b80cfc..._rechnung-gestalten-sevdesk- desktop-und-mobile@2x.webp 3312x2224, Massstab 2,00 Q-LISTE docs/vorbilder/Fr Purple Opengraph Product Tour.jpg 4800x2596, Massstab unbekannt - nur Verhaeltnisse verwendbar Q-ALT docs/vorbilder/qonto-fr-composition-analytics.png von 2018, widerspricht dem heutigen Qonto. NICHT als Massstab. DIE MASSSTAEBE SIND HERGELEITET, nicht aus den Dateinamen genommen: S-DASH 1,69 ueber zwei unabhaengige Anker (Leistenbreite 397/236 und Zeilenabstand 68/40, beide aus S-BELEGE) S-RECHNUNG 2,00 ueber den Vorschau-Knopf (722px bei 393 CSS Geraet und 16 CSS Rand); Gegenprobe: Knopfhoehe ergibt exakt 48 CSS DREI REGELN, die sich in dieser Nacht als noetig erwiesen haben: 1. VOR JEDER MESSUNG DIE ECHTE APP-KANTE BESTIMMEN. Diese Bilder tragen einen dekorativen Rahmen samt Schlagschatten. In S-BELEGE liegt die Produktkante bei x=46, nicht bei x=12; in S-DASH bei x=77, nicht 9. Wer den Rahmen mitnimmt, verschiebt ALLES um 34 bzw. 68 Bildpunkte. So sind einmal vier Leistenwerte auf einen Schlag falsch geworden. 2. ABSOLUTE HELLIGKEITEN NICHT UEBER ZWEI BILDER VERGLEICHEN. Dieselbe Haarlinie misst 233 in S-BELEGE (1x) und 213 in S-RECHNUNG (2x) - verschiedene Kompression, verschiedene Skalierung. Verbindlich ist der Wert aus dem 1x-Bild. Verhaeltnisse dagegen gelten ueberall. 3. "DAS GIBT ES NICHT" IST DIE RISKANTESTE AUSSAGE. Ein falsches "ist da" faellt beim Bauen auf, ein falsches "ist nicht da" nie. Beispiel: die Zahlenplaettchen der Filterreihe galten kurz als nicht vorhanden, weil der Messstrahl zwei Pixel ueber ihnen lag. Vor jeder Abwesenheits- aussage das Bild vergroessert ansehen. ------------------------------------------------------------------------- WARUM DIESE DATEI NEU GESCHRIEBEN IST (06.08.2026) Die Vorgaengerin hatte 3.308 Zeilen, 1.661 Deklarationen und davon 941 mit !important - siebenundfuenfzig Prozent. Das ist keine Datei mehr, das ist ein Stellungskrieg: jede Runde Gestaltung musste die vorige ueberbieten, und jede neue Regel brauchte einen laengeren Selektor als die alte. Henry sagte, die Oberflaeche "catcht" nicht. Emil sagte, es soll wirklich ein neues Design sein und nicht ein paar geaenderte Zahlen. Beides ist mit einer weiteren Schicht auf diesem Stapel nicht zu haben. Zwei Dinge sind deshalb anders als vorher: 1. Gestaltet wird gegen die ECHTEN Klassennamen im Markup (.panel, .card, .nav-item, .choice-card), nicht gegen die Namen, die app-shell.js zur Laufzeit zusaetzlich anhaengt (.sheet, .row-card, .side-item, .pick). Die Aliase bleiben bestehen und stoeren nicht - aber die Gestaltung haengt nicht mehr davon ab, ob ein Skript schon gelaufen ist. Das spart das Aufblitzen beim Laden und den halben Spezifitaetskrieg. 2. !important nur dort, wo eine fremde Regel wirklich ueberboten werden muss - im Wesentlichen gegen bp2.css und theme.css, die beide vorher geladen werden und fuer die Website gedacht sind. ------------------------------------------------------------------------- DER STRUKTURELLE UNTERSCHIED ZU VORHER Vorher lag EIN grosses weisses Blatt auf gruen getoentem Grund, und alles stand darauf. Dadurch gruppierte nichts: Einrichtung, Projekte und offene Aufgaben sahen aus wie ein einziger Textblock, und wo doch gruppiert wurde, entstanden Karten in Karten. Jetzt: neutraler Grund, darauf mehrere weisse Karten mit Haarlinie, und INNERHALB einer Karte trennen Haarlinien statt weiterer Karten. Genau so sind Qonto, sevdesk und belegFuchs aufgebaut, und genau das meint Henry mit "klinisch". ========================================================================= */ /* ========================================================================= 1 GRUNDWERTE ========================================================================= */ body.bp-app { /* --- Flaechen --------------------------------------------------------- Fast neutral. Der Hauch Buntheit (0.001-0.004) haelt die Flaechen mit der Hausfarbe verwandt, ohne dass man Gruen sieht. Reines Grau neben einem gruenen Akzent wirkt schmutzig, deshalb nicht chroma 0. EMIL, 07.08.2026: "weißer statt grünlicher Hintergrund". Nachgemessen war der Grund NICHT gruenlich - Chroma 0.0028 sind zwei Prozent der Buntheit des Akzents, das sieht kein Auge. Er war aber ein helles GRAU: 97% Helligkeit gegen 99.6% der Karte, und dieser Abstand von 2,6 Prozentpunkten war es, der die Flaeche als "nicht weiss" lesen liess. Der Grund geht deshalb auf 98.6% hoch und die Buntheit auf ein Drittel herunter. Damit bleiben zwischen Grund und Karte nur noch 1,2 Prozentpunkte - zu wenig, um eine Karte zu tragen. Genau deshalb hat Emil im selben Satz Schatten verlangt: die Karte hebt sich ab jetzt durch Hebung, nicht durch einen dunkleren Nachbarn. Siehe --hebung. */ /* DIE KACHEL HAT DENSELBEN GRUND WIE DIE SEITE. Gemessen in derselben Datei: Kachelflaeche 255, Seitengrund 255. sevdesk setzt hier weiss auf weiss und trennt AUSSCHLIESSLICH ueber die Kontur. Das ist selbst ein Befund und passt zu "die Linie traegt die Ordnung". Ich hatte 250 gegen 254 - einen kleinen Helligkeitsunterschied, der die Karte mittragen sollte. Er tut es nicht wirklich (vier Stufen sieht kaum jemand) und macht die Flaeche zugleich unruhig. Beide jetzt gleich; die Trennung leistet die Linie, so wie im Vorbild. */ /* REINES WEISS, und die Gleichheit von Grund und Kachel bleibt. GEMESSEN an S-BELEGE, Schnitt bei y=400 und y=600 quer durch die Leistenkante bis in die Kachel: Leistengrund 251 Inhaltsgrund 255 ab x=284 Kachel innen 255 Kachelkontur 233 (waagerechte Linie), 242 (senkrecht, weichgezeichnet) Grund und Kachel sind im Vorbild BEIDE reines Weiss; getrennt werden sie allein durch die Haarlinie. Genau so steht es hier auch - nur lagen wir mit 99,4 % bei 253 statt 255. WARUM DIE ZWEI STUFEN ZAEHLEN: Der Abstand Linie-zu-Grund war bei uns 253-234 = 19, im Vorbild 255-233 = 22. Die Linie las sich blasser, obwohl `--linie` mit 233 exakt richtig gesetzt war. Beide Werte fuer sich stimmten, erst ihr VERHAELTNIS war daneben - dieselbe Sorte Fehler wie der Gruenstich, den keine Einzelmessung gefunden hat. Gemeldet von SideChat aus einer Gegenueberstellung; ihre Zahl war 17, nachgemessen sind es 19, die Richtung stimmt. Und es ist woertlich das, womit dieser ganze Umbau angefangen hat: Emil, "weisser statt gruenlicher Hintergrund". */ --flur: oklch(100% 0 155); /* Kachel-/Innengrund — bleibt weiss */ /* SEITENGRUND: ein ZARTER Verlauf von Weiss nach Gruen (12.08.2026, zweiter Anlauf). Der erste Anlauf war ein dunkelgruener Verlauf. Emil im Bild: „das grün geht garnicht … viel viel zu stark und zu dunkel". Er will den Ton der Marketingseite - und der ist nachgesehen, nicht geschaetzt: `bp2.css --paper: oklch(99.4% 0.003 150)`, also fast Weiss mit einem Hauch Gruen (Buntheit 0,003). Deshalb hier dieselbe Groessenordnung: oben der Marketington, unten eine Spur mehr Gruen. Der Abstand betraegt 3,4 Helligkeitspunkte und 0,0154 Buntheit - sichtbar als Hauch, nicht als Farbe. Zum Vergleich die beiden bestehenden Gruentoene des Hauses: `--wasch` oklch(96.4% 0.010 152) und `--green-wash` der Website oklch(95.5% 0.018 152). Henrys Wunsch nach 10 bis 20 Prozent mehr Gruen setzt der untere Wert als rund 15 Prozent mehr Buntheit gegenueber dem bisherigen Stand um. Die Schrift bleibt damit dunkel wie zuvor - alle Regeln fuer helle Titel, die der dunkle Grund gebraucht hatte, sind wieder weg. */ --grund-oben: oklch(99.4% 0.003 150); --grund-unten: oklch(96.0% 0.0184 152); --karte: oklch(100% 0 155); /* Kachel - GLEICH wie der Grund */ /* DIE GRAUTOENE SIND NEUTRAL. KEIN GRUENSTICH MEHR. Das ist die Erklaerung fuer Emils "grünlicher Hintergrund", die uns zwei Tage gefehlt hat. SideChat hat am 08.08.2026 alle acht Arbeitsseiten durchgemessen: acht verschiedene Flaechentoene, davon vier mit einem Gruenstich von 3 bis 7 Stufen (Gruen ueber Rot und Blau). sevdesk hat DREI Flaechenwerte, und alle drei sind neutral oder minimal blau. Einzeln ist so ein Stich unsichtbar. Er liegt aber auf JEDER Karte, jedem Schildchen, jedem Streifen - und Gruenstich auf grosser Flaeche ist genau das, was man als "gruenlich" empfindet, ohne es benennen zu koennen. Deshalb war er mit Messungen an Einzelwerten nicht zu finden: jeder Wert fuer sich war vertretbar. BEIM UMSTELLEN AUF CHROMA 0 IST ETWAS PASSIERT, DAS ICH NICHT ERWARTET HATTE: vier Tokens landen damit EXAKT auf sevdesks gemessenen Werten. --still 246,248,246 -> 247,247,247 (sevdesk 247,247,247) --linie 233,234,233 -> 233,233,233 (sevdesk 233) --flaeche-aktiv 227,230,228 -> 229,229,229 (sevdesk 229,229,229) --linie-leiste 250,250,250 -> 250,250,250 (sevdesk 250) Die Helligkeiten waren also die ganze Zeit richtig. Der Gruenstich WAR die ganze Abweichung. GRUEN BLEIBT, WO ES ETWAS BEDEUTET: --wasch, --gut-wasch und die Hausfarbe selbst behalten ihre Buntheit. Sie markieren eine Handlung oder einen Zustand. Eine Flaeche markiert nichts. */ --still: oklch(97.6% 0 155); /* ruhige Zone: Kartenkopf, Tabellenkopf */ /* DIE DRITTE FLAECHE, und sie widerspricht einer frueheren Zusammenfassung. SideChat hatte notiert, sevdesk komme mit ZWEI Flaechenwerten aus - weiss und ein Grau um 246. DIESE ZUSAMMENFASSUNG WAR ZU KNAPP, und Main hat recht damit, sie zu berichtigen: gemessen sind in S-BELEGE und S-DASH 255 (Kachel), 246-248 (Schildchen, Tabellenkopf, Kennzahlflaeche), 249 (Leistengrund) und 229 (aktiver Filtereintrag). Das sind vier Familien, nicht zwei. Die Verkuerzung auf zwei stammte aus den ersten fuenf Messungen - die Filterreihe kam spaeter dazu. Der aktive Filtereintrag misst 229, deutlich dunkler als alles andere. Gemessen rgb(229,229,229) -> oklch(92.2%). Wir nehmen die Helligkeit und unseren Hausfarbton. Genutzt NUR fuer "hier stehst du gerade" - eine Auswahl, die man druecken kann und die gedrueckt IST. */ --flaeche-aktiv: oklch(92.2% 0 155); /* GEMESSEN, nicht geschaetzt. Quelle: docs/vorbilder/665983e3a3c4c73837183773_sevdesk-belege-verwalten-desktop.webp Schnitt quer zur Kachelkante: [255,255,255,255,233,255,255,254,255] - GENAU EIN Bildpunkt weicht ab. Ein Schatten zeigt eine Rampe ueber fuenf bis fuenfzehn Punkte. Das ist eine Haarlinie, 1px, Helligkeit 233. Meine Schaetzung lag bei 226/229/227 - eine Spur zu dunkel. Vorbehalt von SideChat: an der linken Kante misst er 242. Eine 1px-Linie auf nicht-ganzzahliger Position wird weichgezeichnet und liest sich heller; 233 ist der dunkelste gemessene Wert und damit die beste Schaetzung fuer die wahre Farbe. */ --linie: oklch(93.5% 0 155); /* Haarlinie - gemessen 233/255 */ /* DIE LEISTE TRENNT ANDERS ALS EINE KACHEL RAHMT. Gemessen an S-DASH (obere Leiste, 250) und S-BELEGE (Kachelkontur, 233) - SideChat, Punkt 7. Jeder Wert aus dem Bild, in dem der Baustein vorkommt; ueber zwei Bilder hinweg waeren sie nicht vergleichbar (siehe Regel 2 im Kopf). Das ist kein Zufall und kein Messfehler - eine Leiste soll oben abschliessen, ohne einen Kasten zu zeichnen. Bei 250 auf Weiss sind das fuenf Stufen Unterschied; man sieht sie kaum und vermisst sie sofort, wenn sie fehlt. Umgerechnet mit echter sRGB->OKLCH-Rechnung: rgb(250,250,250). */ --linie-leiste: oklch(98.5% 0 155); --linie-zart: oklch(95% 0 155); /* Trennung zwischen Zeilen */ /* --- Erhebung --------------------------------------------------------- Die Karte hebt sich durch SCHATTEN vom Grund ab, nicht durch eine Linie. Das ist der groesste einzelne Unterschied zu den Vorbildern. Eine 1px-Linie um jede Karte laesst eine Oberflaeche wie einen Drahtgitter-Entwurf aussehen - Emil, 06.08.2026: "Das sieht aus wie ein erster Entwurf von einem Software-Development-Praktikanten." BERICHTIGT UND BELEGT, 07.08.2026. Hier stand: "Qonto, sevdesk und belegFuchs setzen alle drei auf weiche Schatten und verzichten auf den Rahmen." Ich hatte aus vier QONTO-Aufnahmen abgeleitet und sevdesk sowie belegFuchs mitbehauptet, ohne je eine Aufnahme davon gesehen zu haben. Die Behauptung ist nicht bloss unbelegt, sondern WIDERLEGT. Die Bilder liegen jetzt im Repo und sind nachschlagbar: docs/vorbilder/sevdesk-dashboard-desktop@3x-scaled.webp docs/vorbilder/665983e3a3c4c73837183773_sevdesk-belege-verwalten-desktop.webp docs/vorbilder/68b80cfcaa79526693f89b43_rechnung-gestalten-sevdesk-desktop-und-mobile@2x.webp In S-BELEGE, S-DASH und S-RECHNUNG: Kachel mit FEINER LINIE, KEIN Schatten. Genau diese Linie traegt dort die Ordnung. Auswertung in docs/VORBILDER-BEFUND.md. DIE VORBILDER WIDERSPRECHEN SICH, das gehoert dazugesagt: Qonto 2018 macht es umgekehrt (Schatten, kein Rahmen), Qonto heute laesst die Karte ganz weg und nimmt nur Haarlinien. belegFuchs liegt nicht vor. SEVDESK GEWINNT - eine Entscheidung, keine Messung: gleicher Markt, gleiche Sprache, gleiche Belege, gleiche Nutzer. Qonto ist eine Bank. Und Emil hat ausdruecklich die sevdesk-Bilder gelobt, nicht die von Qonto. WAS DARAN ZU LERNEN IST: Eine erfundene Quellenangabe ist schlimmer als eine fehlende. Wer keine Begruendung findet, prueft nach. Wer eine findet, hoert auf zu pruefen. Dieser Satz hat einen Tag lang die Richtung mitbestimmt, und niemand konnte ihn pruefen, weil die Bilder nirgends lagen. Deshalb steht jetzt ein DATEINAME dort, wo vorher "die Vorbilder" stand. Der Schatten bleibt nur, wo wirklich eine Ebene darueber liegt - beim Kontofenster. 07.08.2026 DEUTLICH STAERKER. Der Schatten war auf einen Grund gerechnet, der 2,6 Prozentpunkte dunkler war als die Karte - die Karte stand schon durch den Helligkeitsunterschied. Seit der Grund fast weiss ist, traegt der Schatten die Karte ALLEIN. Bliebe er bei 0.05/0.06, schwaemmen die Karten unsichtbar auf der Flaeche. Zwei Lagen: eine harte, kurze fuer die Kante (1px) und eine weite, weiche fuer die Hebung (10px). Eine einzelne Lage sieht entweder nach Klebefolie oder nach Nebel aus. HIER STAND "wie in den Vorbildern", UND DAS WAR DER LETZTE REST DERSELBEN ERFINDUNG, gegen die der halbe Absatz darueber anschreibt. Es kann nicht stimmen: zwanzig Zeilen weiter oben steht belegt, dass sevdesk GAR KEINEN Schatten hat. Ein Vorbild ohne Schatten kann keine Schattenlagen zeigen. Gemeint sein koennte nur Qonto 2018 - und das ist ein Stand, den wir ausdruecklich nicht als Massstab nehmen. Die zwei Lagen bleiben trotzdem, als ENTSCHEIDUNG: sie stehen an Knoepfen und am Kontofenster, nicht an den Kacheln. Die Kacheln tragen die feine Linie, so wie gemessen. Berichtigt am 07.08.2026, nachdem die pruefende Sitzung diesen Absatz nochmals angemahnt hat - sie las eine aeltere Fassung, aber sie hatte trotzdem recht, nur an anderer Stelle. */ --hebung: 0 1px 2px oklch(24% 0.014 155 / 0.07), 0 4px 10px oklch(24% 0.014 155 / 0.07); --hebung-hoch: 0 2px 4px oklch(24% 0.014 155 / 0.07), 0 12px 28px oklch(24% 0.014 155 / 0.11); /* --- Schrift ---------------------------------------------------------- */ --tinte: oklch(24% 0.014 155); /* Haupttext */ --tinte-2: oklch(46% 0.011 155); /* Nebentext */ /* 60 % WAREN ZU BLASS - GEMESSEN, NICHT GEAHNT. Emils Punkt 12: "'Bald verfügbar', Status-/Hilfstexte und einige Placeholder sind teils zu blass." Gemessen ergab 60 % genau 3,92:1 gegen Weiss - unter den 4,5:1, ab denen normaler Text als lesbar gilt, und zufaellig derselbe Ton, den die Oberflaeche fuer Ausgegrautes nimmt. Deshalb sah auch der Kuendigungsknopf deaktiviert aus. 55 % ergeben 4,86:1 auf Weiss und 4,62:1 auf `--still` (249) - beide Untergruende, auf denen dieser Ton vorkommt, liegen darueber. Emil wollte ausdruecklich NICHT alles abdunkeln: fuenf Punkte auf einem Ton sind kein neuer Kontrastentwurf, sie sind die Schwelle. */ /* 52 %, NICHT 55 %. Derselbe Grund, aus dem --ink-3 in bp2.css schon von 60 % auf 52 % gesenkt wurde - die App-Seite hat den Schritt nie mitgemacht. Gemessen am 14.08.2026 (scripts/barrierefreiheit.py): "Offen" auf /uebersicht 4,00 "Dieser Monat" auf /uebersicht 4,36 "Nur damit kann BelegHero ..." 4,36 (auf /uebersicht UND /account) Verlangt sind 4,5 fuer Fliesstext. Betroffen ist wieder genau das Erklaerende - Rubriken und der Satz, der sagt, WARUM ein Anschluss noetig ist. */ --tinte-3: oklch(52% 0.009 155); /* Meta, Rubriken */ /* --- Akzent ----------------------------------------------------------- Die Hausfarbe bleibt. Geaendert sind nur die hellen Verwandten, die in der Anwendung die Flaechen fuellten und den Eindruck "zu hell" machten. Gruen bedeutet ab hier ZUSTAND - aktiver Punkt, getroffene Auswahl, Erfolg - und nicht mehr Beruehrung. */ --gruen: #2e4f35; --gruen-tief: #223c28; --gruen-hell: oklch(42% 0.045 152); /* DIE KONTUR DES RUHIGEN KNOPFES - Henry, 11.08.2026: "Die Software ist insgesamt zu kahl. Zu wenig Farbe. Kleine Komponenten wie Buttons sollten auch gruen werden." Gemessen vor dem Durchgang: von 132 farbigen Elementen der Software tragen 118 die Farbe in der SCHRIFT und nur 10 in einer Kontur - auf sieben Seiten zusammen. Nicht der Anteil war zu niedrig (18.8 % gegen 17.8 % auf der Verkaufsseite), sondern Farbe erschien fast nur als Wort. 65 % Helligkeit ist nicht Geschmack, sondern die Schwelle: bei 0.65 haelt der Ton 3.16:1 gegen Weiss und erfuellt damit WCAG 1.4.11 fuer Bedienelemente. Die bisherige graue Kontur (`--linie`) haelt 1.21:1 - sie erfuellt die Norm nicht, und das war vor Henrys Wunsch schon so. Heller waere also nicht zurueckhaltender, sondern weiter daneben. */ --gruen-kontur: oklch(65% 0.05 152); --wasch: oklch(96.4% 0.010 152); --wasch-rand: oklch(88% 0.028 152); /* --- Nebenfarben fuer Zustand ----------------------------------------- Deutlich farbiger als zuvor. In den Vorbildern traegt die Marke die Bedeutung. NICHT PRUEFBAR (SideChat, 08.08.2026): der folgende Satz nennt Zustaende, die in KEINER unserer Aufnahmen vorkommen - S-BELEGE zeigt Faellig, Offen, Teilbezahlt, Bezahlt, Entwurf. Die Aussage stammt aus einem Bildschirm, den wir nicht haben. Das PRINZIP dahinter ist dagegen gemessen und gilt: Farbe nur bei Offenem, Grau bei Erledigtem (Bezahlt misst rgb(246,245,248), identisch mit dem Kategorieschildchen). sevdesk zeigt "Beleg fehlt" bernsteinfarben und "Vollstaendig" grau, und man liest den Zustand, ohne den Text zu lesen. Meine erste Fassung hatte fast alles grau - dann ist die Marke nur noch Dekoration. Die harte Buntheitsgrenze aus test_kein_gruen_auf_gruen gilt weiterhin fuer --wasch, also die Hausfarbe. Fuer Warnung, Fehler und Hinweis entscheidet dort der gemessene Kontrast, und der bleibt ueber 4,5:1. */ --warn: oklch(46% 0.125 62); --warn-wasch: oklch(94% 0.065 80); --stop: oklch(48% 0.165 27); --stop-wasch: oklch(94% 0.055 27); --info: oklch(45% 0.115 250); --info-wasch: oklch(94.5% 0.045 250); --gut-wasch: oklch(94.5% 0.055 152); /* --- Form ------------------------------------------------------------- Drei Radien, mehr nicht. KORREKTUR 06.08.2026: die Karte lag bei 8px und wirkte dadurch hart und billig. Henrys "die auswahlmoeglichkeiten sind zu rund" galt den Auswahlkacheln mit 26 bis 34px - nicht den Karten. BERICHTIGT 08.08.2026 (SideChat, gemessen): Hier stand "die Vorbilder liegen bei Karten durchgehend zwischen 12 und 14px". Das ist falsch, und zwar in beiden Teilen. Gemessen an den Aufnahmen: Tabellenkachel docs/vorbilder/665983e3...sevdesk-belege-...webp 8px Dashboard-Kachel docs/vorbilder/sevdesk-dashboard-desktop@3x...webp 11px Weder "durchgehend" noch "12 bis 14" - sevdesk benutzt ZWEI verschiedene Radien je nach Kachelart, und beide liegen unter 12. Ich hatte seine Kritik auf alles angewendet und damit ueberkorrigiert. */ /* 07.08.2026, Emil: "weichere Ecken". Eine Stufe hoeher, nicht zwei - Henrys "die auswahlmoeglichkeiten sind zu rund" gilt weiterhin, und der Weg zurueck in die Ueberkorrektur ist kurz. 14px bei Karten liegt UEBER dem, was die Vorbilder zeigen (gemessen 8 und 11, siehe oben). Das ist eine ENTSCHEIDUNG nach Emils Wunsch "weichere Ecken", keine Ableitung - hier stand vorher, es liege "am oberen Ende dessen, was die Vorbilder zeigen", und das stimmte nicht. */ --e-klein: 8px; --e: 10px; /* GEMESSEN AN S-BELEGE (SideChat, 07.08.2026): 5px Eckversatz, an BEIDEN Knopfarten gleich, hohe Sicherheit. Damit ist der Satz zwei Absaetze weiter oben - "10px bei Bedienelementen knapp darueber (8 bis 10)" - WIDERLEGT. Er war geschaetzt, nicht gemessen; ich hatte ihn aus dem Gesamteindruck der Aufnahmen abgeleitet und wie eine Ablesung hingeschrieben. Dasselbe Muster wie bei `--hebung`. ES WIDERSPRACH EMILS FRUEHEREM "weichere Ecken". Anders als bei --e-karte liesz die Messung hier keinen Spielraum, in dem sich beides erfuellen liesse: 5 und 10 sind kein Unsicherheitsband, sondern zwei Werte. Ich habe es ihm deshalb ausdruecklich vorgelegt statt es still umzudrehen. ENTSCHIEDEN. Emil, 07.08.2026, woertlich: "so wie in sevdesk ist gut." Damit ist die Messung die Vorgabe und "weichere Ecken" gilt nur noch dort, wo keine Messung dagegensteht - naemlich bei --e-karte. */ --e-knopf: 5px; --knopf-innen: 14px; /* aus derselben Messung: Innenraum 12 bis 14px */ /* GEMESSEN 7-8px an der Kachel in S-BELEGE, MIT VORBEHALT: der waagerechte Versatz an der Oberkante betraegt 7px, senkrecht laeuft die Rundung aber ueber 12 Zeilen aus. Bei einem reinen Kreisbogen muessten beide gleich sein - es ist also entweder kein Kreisbogen oder die Kantenglaettung zieht ihn in die Laenge. SideChat: "10-12 ist durch diese Messung nicht ausgeschlossen." ICH NEHME 12 - das obere Ende des Unsicherheitsbandes, und das ist eine ENTSCHEIDUNG, keine Messung: Emil hat ausdruecklich "weichere Ecken" verlangt. Innerhalb dessen, was die Messung zulaesst, waehle ich das, was er gesagt hat. Waere 12 durch die Messung ausgeschlossen, staende hier 8. */ --e-karte: 12px; --e-pille: 999px; /* NUR Zustandsmarken und Zaehler */ /* `--line` IST KEINE ZWEITE HAUSFARBE, SONDERN EIN ALTLASTNAME. Main meldete am 10.08.2026 zwei fremde Konturtoene: /invoice-profile mit 218,224,218 und /bank mit 238,238,238, die einzigen zwei im Bestand. Beides sind Symptome derselben Ursache - `--line` ist FUENFMAL verschieden definiert: bp2.css:54 oklch(90% 0.010 150) = 218,224,218 account.html:8 #d8d5cc (beige) bank.html:8 #d8d5cc bank_test.html:8 #d8d5cc invoices.html:8 #d8d5cc Geprueft, bevor umgelenkt: `var(--line)` hat elf Fundstellen in bank.html und invoice_profile.html, und ALLE elf sind Konturen (border / border-top / border dashed). Keine Schrift, kein Grund. Damit ist der Name eindeutig belegt und darf auf den Hauston zeigen. app-neu.css wird nach den