Commit Graph
6 Commits
Author SHA1 Message Date
DogFatherGit 677bcb5653 Workspace: neues Knopf-System "Geschliffen" -- ueberall, eine Stelle
Von Filipe aus drei gerenderten Entwuerfen gewaehlt (A Kante & Glut,
B Geschliffen, C Praegung). Raten hilft hier nicht -- beim Zurueck-Knopf
hat erst der direkte Vergleich zum Ziel gefuehrt.

Aufbau: farbiger Verlaufsrand (padding-box/border-box) und ein feiner
heller Streifen obenauf -- wie eine angeschliffene Kante. Die Farbe sitzt
im Rand und in der Schrift, die Flaeche bleibt dunkel. Beim Zeigen hebt
sich der Knopf einen Pixel an und bekommt einen weichen farbigen Schein
darunter. Die Hauptaktion einer Seite ist zusaetzlich gefuellt.

JEDE AKTION HAT IHRE EIGENE FARBE:
  gruen  passt, erledigt, freigegeben
  amber  ausbaufaehig, wartet
  rot    Handlungsbedarf, loeschen
  blau   speichern
  violett anlegen
  gold   Onboarding -- der einzige Schritt, der eine Person anlegt
  grau   abbrechen, schliessen
  Stufenfarbe fuer den Weiter-Knopf der Scout-Pipeline

DAS IST JETZT DIE EINZIGE STELLE, AN DER KNOEPFE GESTALTET WERDEN.
Vorher standen sie in NEUN Dateien verstreut, und prompt sahen dieselben
Knoepfe auf verschiedenen Seiten verschieden aus. Alle alten
Definitionen sind entfernt; wer einen neuen Knopf braucht, nimmt eine
Farbklasse und schreibt kein CSS. Gilt ab jetzt auch fuer alles, was
noch dazukommt.

Geprueft ueber alle elf Seiten: 172 sichtbare Knoepfe, kein einziger
ungestylt, kein Kontrast unter 4,5:1.

Drei Sachen, die dabei aufgefallen sind:

1. Der neutrale "Abbrechen"-Knopf hatte halbdurchsichtiges Weiss als
   Farbwert -- gemessen 1,1:1 Kontrast, praktisch unlesbar. Neutral hat
   jetzt einen echten Farbwert (#8e9cb0).

2. Die Filter-Knoepfe (Kalender, Dateien, Bereiche) hatten eine eigene
   "gedrueckt"-Regel mit flaechiger Farbe, die den geschliffenen Rand
   ueberschrieb. Sie benutzen jetzt den gefuellten Auftritt des Systems.

3. Der Bearbeiten-Stift auf den Aufgabenkarten war nie ein richtiger
   Knopf, sondern nackter Text ohne Rand -- man sah nicht, dass man
   draufdruecken kann. Jetzt im System, in der kleinsten Groesse.

Der Zurueck-Knopf ("Neon-Kante") bleibt wie er ist -- den hat Filipe
selbst ausgesucht, und er ist ein Navigationselement, keine Aktion.

Messhinweis fuer spaeter: color-mix liefert computed color(srgb ...),
das laesst sich NICHT als Text auslesen. Die erste Messung meldete
faelschlich 1,13:1 fuer 49 Knoepfe. Richtig geht es ueber eine Leinwand
(fillStyle + getImageData).

Alle Toene bewusst gedeckt statt neon, alles respektiert
prefers-reduced-motion.
2026-08-28 12:13:11 +02:00
DogFatherGit 3a1ab64c26 Workspace: Suche ueber alle Bereiche (Phase 4)
Auf JEDER Seite, nicht auf einer eigenen. kopf.js baut sie selbst in die
Kopfleiste ein -- eine Suche, die man nur auf einer Extraseite findet,
benutzt niemand. Mit "/" oeffnen, mit Esc schliessen.

Durchsucht: Aufgaben, Termine, Calls, Gespraechsprotokolle, Dateien, die
fuenf Betreuungsbereiche, die Scout-Pipeline und die offenen Felder der
Creator-Profile.

Zwei Dinge machen den Unterschied zwischen einer Suche und einer
brauchbaren Suche:

1. SIE DARF NICHTS FINDEN, WAS DIE SEITE VERBERGEN WUERDE.

Eine Suche ist die verlockendste Stelle fuer ein Datenleck: Man tippt
einen Namen und bekommt Treffer aus Bereichen, die man nie oeffnen
duerfte. Jede Quelle wird deshalb mit der Sichtbarkeitsregel ihres
eigenen Moduls abgefragt -- importiert, nicht abgeschrieben.

Die management-internen Profilfelder (admin_notiz, plan_start,
naechster_review) werden GAR NICHT durchsucht, auch nicht fuer das
Management: Ein Treffer daraus taucht sonst spaeter in einer Ansicht
auf, die diese Felder nicht zeigen darf. Wer die Notiz lesen will,
oeffnet das Profil.

Geprueft mit einem eigenen Leck-Test: "GEHEIM" (Inhalt einer internen
Notiz) findet niemand, auch der Chef nicht. Die Lead-Notiz eines Scouts
findet nur er selbst und das Management, nicht der andere Scout.

2. SIE MUSS SAGEN, WO ETWAS STEHT.

Jeder Treffer traegt einen Ausschnitt RUND UM die Fundstelle, nicht die
ersten Zeichen des Feldes -- man sieht sofort, warum etwas gefunden
wurde. Bei Profiltreffern steht dabei, welches Feld getroffen hat, bei
Protokollen ob es unter "Besprochen" oder "Entscheidung" stand. Und
jeder Treffer fuehrt an die Stelle, an der man weiterarbeiten kann.

LIKE-Sonderzeichen werden maskiert. Ohne das waere die Suche nach "100%"
eine Suche nach "100 gefolgt von irgendwas" und "a_b" faende auch "axb"
-- beides falsch und beides faellt erst spaet auf. Geprueft: "100%" und
"a_b" finden genau ihren Eintrag, "axb" findet nichts.

Bewusst kein Volltextindex (FTS5): Die Datenmengen sind klein, und LIKE
braucht keinen zweiten Datenstand, der irgendwann auseinanderlaeuft.

Kleinigkeiten aus dem Test:
- Das Overlay stand auf voller Hoehe, auch bei zwei Treffern -- der
  Schleier ist flex und stand auf dem voreingestellten stretch. Jetzt
  flex-start, das Fenster waechst mit dem Inhalt (417 statt 780 px bei
  drei Treffern).
- Das eingebaute Kreuz von type="search" sass direkt neben dem
  Esc-Knopf: zwei Wege fuer dasselbe, dicht nebeneinander. Entfernt.
- Das CSS liegt in gate.css, nicht in einer Seiten-Datei -- genau der
  Fehler, der bei .knopf-still schon einmal passiert ist.
2026-08-28 11:39:46 +02:00
DogFatherGit 516a003dc8 Dateien: Hochladen nur fuer Management und Scouts
Wunsch vom 28.08.2026: "die dateien sollen nur die manager oder scout
hochladen koennen aber nicht die creator."

Serverseitig ueber DARF_HOCHLADEN. Die Pruefung steht bewusst VOR
express.raw -- wer nicht darf, wird abgewiesen, bevor auch nur ein Byte
entgegengenommen wird. Sonst wanderten bis zu 25 MB durch die Leitung,
nur um danach verworfen zu werden.

Ein Creator sieht und oeffnet weiterhin die Dateien seines Bereichs.
Statt des Ablegefeldes steht dort jetzt, warum es fehlt -- ein einfach
verschwundenes Feld wirkt wie ein Fehler.

Geprueft: Management 201, Scout 201, Creator 403 mit klarer Meldung;
Creator sieht und laedt weiterhin.

--------------------------------------------------------------------
Dabei ein Fehler aufgefallen, der mehrere Seiten betraf:

Das hidden-Attribut blendet nur ueber eine sehr schwache Browserregel
aus -- JEDE eigene display-Angabe schlaegt sie. Betroffen waren:
  * das Ablegefeld fuer Dateien (display: grid) -> ein Creator sah es
    trotz hidden weiterhin
  * die Verwaltungsfelder "Plan-Start" und "Naechster Review" im
    Creator-Profil (ebenfalls grid) -> ein Creator sah sie ebenfalls
  * der Zurueck-Knopf (inline-flex) -> waere vor dem Laden des Skripts
    kurz sichtbar gewesen

Behoben mit einer Regel in gate.css: [hidden] { display: none !important }

Beim Profil waren nie Daten betroffen -- der Server schickt die Felder
an einen Creator gar nicht erst mit, sie waren leer. Sichtbar sein
sollten sie trotzdem nicht.

Aufgefallen ist es erst im Screenshot. Der vorige Test hatte auf das
hidden-ATTRIBUT geprueft, und das war ja gesetzt. Die Pruefung schaut
jetzt auf die tatsaechliche Sichtbarkeit (isVisible).

Ausserdem: In der Regex zum Saeubern von Dateinamen standen die
Steuerzeichen als rohe Bytes statt als Escape-Sequenz. Die Funktion
arbeitete korrekt, aber die Datei galt dadurch als binaer -- grep
verweigerte sie, und Editoren haetten sie zerstoeren koennen. Jetzt
steht dort \x00-\x1f als Text.
2026-08-28 01:25:53 +02:00
DogFatherGit a378b126fe Workspace: Auswahllisten und Kalender in dunkler Darstellung
Die aufgeklappte Liste eines <select> zeichnet der Browser selbst, CSS
erreicht sie nicht. Ohne Hinweis geht er von einer hellen Seite aus und
malt sie weiss -- die helle Schrift darauf war praktisch unlesbar
(gemeldet mit Screenshot).

Behebung ueber color-scheme: dark auf <html>. Das ist der Schalter fuer
alles, was der Browser selbst zeichnet: Auswahllisten, Datumskalender,
Bildlaufleisten, Textmarkierung. Zusaetzlich sind Hintergrund und
Schriftfarbe an <option> gesetzt, weil aeltere Browser und manche
Linux-Oberflaechen color-scheme nur teilweise beachten.

Damit entfallen die beiden filter: invert(.75) am Kalendersymbol der
Datumsfelder -- der Browser zeichnet es jetzt schon hell, invert haette
es wieder verdunkelt.

Nur statische Dateien, kein Neustart noetig.
2026-08-28 00:20:10 +02:00
DogFatherGit 1f769c9de7 Workspace-Anmeldung: kompaktere Tafel auf niedrigen Bildschirmen
Auf dem iPhone 13 (nur 664 px nutzbare Hoehe) verdeckte die Tafel das
Motiv fast vollstaendig -- sichtbar waren nur die Ohrenspitzen. Neue
Regel fuer max-height 760px: kleinere Abstaende und Schriftgroessen,
und die Bildflaeche wird flacher.

Der zweite Teil ist der eigentliche Kniff: Bei flacherer Bildflaeche
skaliert der Ausschnitt nach BREITE statt nach Hoehe, dadurch zeigt er
den oberen Teil mit den Gesichtern statt seitlich zu beschneiden.

Geprueft auf iPhone 13, iPhone SE und Pixel 5.
2026-08-27 18:15:08 +02:00
DogFatherGit 19f969f36f Creator Workspace: Anmeldeseite unter /workspace
Erstes sichtbares Stueck des Creator-Workspace-Konzepts. Reine statische
Dateien in einem neuen Ordner workspace/ -- express.static liefert den
Repo-Ordner aus, die Seite ist damit ohne Servercode-Aenderung und ohne
Neustart unter /workspace/ erreichbar. Rein additiv: an bestehenden
Dateien wurde nichts geaendert.

Motiv: Dogfather und Hasi Dog stehen rechts im Bild, deshalb liegt die
Code-Tafel links ueber der ruhigen Flaeche (bei VanVans Buchhaltung ist es
gespiegelt, weil dort das Emblem links steht). Drei Layoutfaelle, damit die
Figuren in keiner Fenstergroesse von der Tafel ueberdeckt werden.

Bewusst nur WebP, kein AVIF: send 0.19.2 (Express 4) kennt AVIF nicht und
liefert es als application/octet-stream aus -- wegen des nosniff-Headers
verweigert der Browser das Bild dann komplett. Lokal gegen den echten
Express-Server geprueft: 0 Konsolenfehler, 0 CSP-Verstoesse.

Anmelden funktioniert noch nicht (kein Endpunkt); das Formular sagt das
jetzt ehrlich statt "Code stimmt nicht".
2026-08-27 18:13:05 +02:00