Commit Graph
24 Commits
Author SHA1 Message Date
DogFatherGitandClaude Opus 5 963ea492b1 Die fuenf Rollen bekommen eigene Farben und echte Zeichen
Auftrag von Filipe (Nachtliste, screen3): "die farben sollen jeden rollen
angepasst werden ueber die ganze website ... diese farben sollen auch
immer danach bei den rollen benutzt werden", dazu die Zeichen "viel viel
viel realistischer und geiler".

DIE FARBEN STEHEN JETZT AN EINER STELLE. Vorher lagen dieselben Hex-Werte
ueber chat.css, personen.css, kalender.css, start.css und gate.css
verstreut -- 47 Fundstellen, allein in chat.css sechzehn. Wer eine Farbe
aendern wollte, musste sie ueberall finden; wer eine uebersah, hatte zwei
Wahrheiten auf einem Bildschirm. Sie stehen jetzt in gate.css, der
einzigen Datei, die auf allen 19 Seiten liegt, mit je drei Toenen
(haupt/zweit/tief) fuer Flaeche, Verlauf und Schatten.

  spicy    rot        #ef5f57  warmes Chili-Rot, kein Signalrot
  admin    babyblau   #7ec8f2  + Lila #a78bfa als zweiter Ton
  manager  lila       #8a76ff  bleibt
  scout    gruen      #5fc99a  bleibt
  creator  bronze     #c79a6d  + Silber #d8dee9 -- neu

Zwei davon waren inhaltlich falsch: `admin` stand auf Gold und `creator`
auf demselben Blau wie der allgemeine Akzent -- die Rolle war dadurch
nicht von "irgendein Bedienelement" zu unterscheiden. In der
Personenliste fehlten Spicy und Manager ganz, und Creator trug das Lila
des Managers: zwei Rollen sahen in derselben Liste gleich aus.

Umgeschaltet wird am <html> (kopf.js), nicht an einzelnen Bausteinen:
Wer die Farbe an jedem Element einzeln setzt, vergisst das naechste, das
dazukommt.

DIE ZEICHEN TRAGEN IHRE FARBEN SELBST. Vorher hatte jedes genau eine
Farbe (currentColor). "Peperoni rot UND gruen" oder "gruenes Schild mit
einer roten Peperoni drin" ist damit nicht darstellbar, egal wie man
mischt. Jedes Zeichen bringt jetzt eigene Verlaeufe mit: Chili rot mit
gruenem Stiel, Husky in Silber mit blauen Augen (Radialverlauf plus
Lichtpunkt -- ein flacher blauer Punkt sieht aus wie ein Loch), Stern in
Gold mit wanderndem Glanz, Schild gruen mit Chili darin, Creator als
geschliffener Kristall in Lila und Silber statt der alten
Person-Silhouette, die aussah wie ein leeres Benutzerbild.

Das Funkeln des Sterns laeuft ueber eine wandernde Maske, nicht ueber die
Deckkraft: Auf- und Abblenden waere ein Pulsieren, kein Glitzern. 4,5 s
und schwach, damit es in einer Liste aus fuenf Rollen nicht dauerhaft den
Blick zieht -- und bei `prefers-reduced-motion` steht es still.

ZWEI FEHLER, DIE NUR DAS HINSEHEN GEFUNDEN HAT:

1. `.rollenwahl__symbol` setzte `fill: none; stroke: var(--r)`. Beides
   wird an die Pfade VERERBT -- jedes neue Zeichen waere von einem
   1,55 px dicken Rand in der Rollenfarbe ueberzogen worden.

2. Das Sprite stand in einem <svg style="display:none">. Solange die
   Zeichen einfarbig waren, war das harmlos. Ein <linearGradient> in
   einem `display:none`-Teilbaum wird aber NICHT ausgewertet, und ein
   <use> darauf bekommt gar keine Fuellung: Im Bildschirmfoto standen
   fuenf Bruchstuecke -- nur Striche, keine Flaechen. Die Zahlen sagten
   dazu nichts, das Sprite war ja vorhanden. Jetzt ein Kasten ohne
   Groesse: wird gerendert, nimmt keinen Platz.

Gemessen: pruef-rollen 97 Pruefungen EXIT=0, pruef-personen-formular 23
EXIT=0, pruef-start-ansicht EXIT=0, pruef-css-klassen EXIT=0. Farb-
umschaltung am lebenden System nachgesehen: html[data-rolle]=admin ->
--r-haupt = #7ec8f2.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-08 04:30:12 +02:00
DogFatherGitandClaude Opus 5 dbb19f69e9 Uhrmacherei statt Lack: guillochiertes Blatt, laufende Perle, Spiegelung auf Metall
Filipe: "ich will dass diese kachel komplett speziell ist, das
hochwertigste und geilste auf der ganzen website ... auch das gleiche
prinzip fuer die uhr, noch vieeeel spezieller. hol die besten skills
von den besten skills dafuer."

Also keine weitere Schicht Lack, sondern die Mittel, an denen man ein
teures Instrument WIRKLICH erkennt.

DIE UHR -- VIER MITTEL AUS DER UHRMACHEREI

  1. GUILLOCHIERTES ZIFFERBLATT. Guillochieren ist das Verfahren, mit
     dem seit zweihundert Jahren hochwertige Blaetter gemacht werden:
     Eine Maschine schneidet ein feines regelmaessiges Muster ins
     Metall, und weil jede Rille das Licht anders zurueckwirft, LEBT
     die Flaeche. Hier aus Strahlen vom Mittelpunkt und Ringen darum,
     beide bei vier Prozent Deckkraft -- wer das Muster einzeln
     erkennt, hat es zu laut gemacht.
  2. EIN AUFGESETZTER ZWOELF-INDEX. Auf einem echten Blatt ist die
     Zwoelf nie nur ein Strich wie die anderen: Sie ist das, woran das
     Auge sich ausrichtet. Ein Keil in Hausrot mit heller Kante.
  3. DIE PERLE AM KOPF DES SEKUNDENBOGENS. Sie laeuft einmal je Minute
     herum und ist das Einzige an der Uhr, das sich BEWEGT statt zu
     wachsen. Ein Bogen zeigt einen Stand, eine laufende Perle zeigt
     Leben. Sie springt im Sekundentakt statt zu gleiten -- ehrlicher
     (die Anzeige ist digital) und eine Bildberechnung je Sekunde statt
     sechzig.
  4. GRAVIERTE ZIFFERN. Ein dunkler Saum oben, ein heller unten -- das
     Lichtverhalten einer Vertiefung. Die Ziffern stehen damit IM Blatt
     statt darauf.

DIE KONSOLE -- DAS METALL FAENGT DAS LICHT

Auf den Kacheln leuchtet das Licht in der Farbe der Kategorie; dort ist
es ein Hinweis. Auf der Konsole waere das falsch -- ein farbiger
Schleier auf gebuerstetem Metall sieht aus wie eine Folie darauf.
Metall zeigt seine Form ueber die SPIEGELUNG: weiss, schmal, hart an
der Kante, und sie wandert mit dem Zeiger ueber die Fassung wie ein
Fenster, an dem man vorbeigeht. Erst dadurch sieht man, dass die
Fassung gewoelbt ist. Ein Standbild kann das nicht.

Dieselbe Falle wie heute Frueh dabei vermieden, diesmal vorher
bedacht: `.willkommen > *` haette dem Lichtelement wieder sein
`position: absolute` genommen -- jetzt `:not(.licht)`.

UND EIN FEHLER, DEN NUR DAS HANDY GEZEIGT HAT

Die Mulde der Uhr hing am Kasten daneben und war an dessen rechtem Rand
ausgerichtet. Am Rechner passte das; bei 412 px steht die Uhr mittig,
und die Mulde lag als dunkle Scheibe neben ihr. Sie entsteht jetzt aus
zwei Schattenringen der Uhr SELBST und ist damit konzentrisch bei jeder
Groesse -- die bessere Bauart, nicht nur die reparierte: Eine Fassung,
die man ausrichten muss, richtet irgendwann jemand falsch aus.

Zehn Pruefungen gelaufen, alle gruen. Rechner und Handy angesehen.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-07 15:00:59 +02:00
DogFatherGitandClaude Opus 5 2acb6bc020 Das Maus-Licht ist zurueck, und die Begruessung ist keine Kachel mehr
DAS LICHT, DAS DEM ZEIGER FOLGT -- MEIN EIGENER FEHLER VON HEUTE FRUEH

Es war nicht geloescht. In module.css stand seit heute

    .kachel > * { position: relative; z-index: 1; }

damit der Inhalt ueber Raster und Kantenlicht liegt. Das Lichtelement
ist aber ein direktes KIND jeder Karte -- ihm wurde damit sein
`position: absolute` genommen. Aus einer Flaeche ueber der ganzen Karte
wurde ein leerer Inline-Span ohne Ausdehnung. Im Browser gemessen:
`display: inline`, obwohl in start.css `absolute` steht.

Merksatz dazu im Code: Eine Regel auf `> *` trifft auch das, was gar
kein Inhalt ist.

Zweiter, aelterer Fehler beim selben Thema, den erst die Pruefung
gefunden hat: Beim Wechsel von einer Kachel direkt auf die naechste
ging das Licht GANZ aus. `pointermove` der neuen Karte meldet einen
Bildaufbau an, `pointerout` der alten kommt danach und hat ihn
geloescht -- obwohl er gar nicht ihr gehoerte. Jetzt wird nur noch der
EIGENE Bildaufbau entwertet.

DIE BEGRUESSUNG FLIEGT AUS DER REIHE

Filipe: "diese hauptkachel muss komplett aus der rolle fliegen im
gegenzug zu den anderen ... AUCH MIT DER UHR RECHTS; WIE IN DER
BUISNESS HUB SEITE VON VANVAN."

Nachgesehen statt geraten: Auf VanVans Business-Hub gibt es keine Uhr.
Gemeint ist das `gate-medaillon` der Anmeldeseite -- ein runder
Kegelverlauf, der wie gebuerstetes Metall aussieht, gefasst in zwei
eingelassenen Ringen. Diese Bauart steht jetzt hier, weitergetrieben.

Die Begruessung ist keine Kachel mehr, sondern eine KONSOLE, und sie
unterscheidet sich in der FORM, nicht im Lack:

  * Sie ist BREITER ALS DIE SEITE -- sie tritt links und rechts ueber
    die Spalte hinaus, in der alle Kacheln stehen.
  * Sie ist ein ACHTECK. Die Module haben EINE abgeschnittene Ecke,
    sie hat VIER.
  * Sie hat eine METALLFASSUNG, laengs gebuerstet, mit je einer warmen
    und einer kuehlen Spiegelung.

Die Uhr ist von 124 auf 164 px gewachsen und hat eine echte Luenette:
10 px deckendes Metall, zwoelf eingravierte Stundenmarken, sechzig
feine Minutenstriche, Glaskuppe.

VIER FEHLER AUF DEM WEG DAHIN, ALLE IM BILDSCHIRMFOTO GESEHEN

  1. HALBDURCHSICHTIGES METALL ist kein Metall, sondern graues Glas.
     Stand gleichzeitig an Konsole und Uhr.
  2. KEGELVERLAUF AUF EINEM BREITEN BALKEN bewirkt nichts: Die ganze
     Oberkante liegt in wenigen Grad. Rund -> conic, lang -> linear.
     Die Verlaufsart muss zur FORM passen, nicht zum Material.
  3. DIE SKALA DER UHR WAR NIE SICHTBAR, seit es sie gibt. Ihre Maske
     rechnete Prozente auf die weiteste ECKE (116 px) statt auf den
     Radius (82 px) -- der Ring lag komplett ausserhalb der Uhr.
     `closest-side` behebt es. Eine unsichtbare Verzierung sieht aus
     wie gar keine, nicht wie ein Fehler.
  4. `body.start .willkommen` in start.css hat die neue Konsole
     ueberschrieben -- nicht ueber die Ladereihenfolge, sondern ueber
     die SPEZIFITAET (0,2,1 gegen 0,1,0). Derselbe Fehler wie mit
     `:where()` heute Frueh, nur andersherum: damals zu schwach
     geschrieben, hier zu stark stehen gelassen.

Der Ueberstand haengt an der Polsterung der Inhaltsspalte
(`min(34px, 3.6vw)`) statt an einer festen Zahl -- eine feste haette
auf dem Handy 17 px aus dem Bildschirm geragt.

UND EINE PRUEFUNG, DIE UNTER DEN BILDRAND GEZIELT HAT

pruef-start-ansicht meldete zwei Fehler am Licht. Das Licht war in
Ordnung: Die hoehere Konsole hatte Kachel 3 auf y = 1134 geschoben,
bei einem 1200 px hohen Fenster lag ihre Mitte unter dem Rand. Sie
rollt jetzt hin, misst danach neu -- und die Zahl der wirklich
gemessenen Kacheln steht in der Bedingung. 140 statt 137 Pruefungen.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-07 13:03:16 +02:00
DogFatherGitandClaude Opus 5 ac432d85e1 Spicy Media: sieben stille Luecken -- und der Kalender zeigt wirklich nur noch Eigenes
Filipe hat drei Sachen gemeldet. Zwei davon waren nicht das, wonach sie
aussahen.

1. "BEI DER SPICY ROLLE IST DA EIN PROBLEM" (Creator-Profil laedt nicht)

Nicht diese Seite war kaputt. In NEUN Skripten stand dieselbe Zeile

    const LEITUNG = new Set(['admin', 'manager']);

und in keinem davon 'spicy'. profil.js nahm deshalb den Creator-Zweig
und lud das EIGENE Profil -- ein Spicy-Zugang ist kein Creator, also
404. Acht der neun sind nicht kaputtgegangen; sie haben sich still
falsch verhalten.

Die Liste steht jetzt EINMAL in bereiche.js. Beim Aufraeumen kamen mit
derselben Suche sechs weitere Luecken heraus, alle vom selben Typ:

  * Aufgaben abbrechen -- Server UND Knopf ohne 'spicy'
  * Teilen-Knopf in der Kopfleiste -- ohne 'spicy'
  * Chat: die Gespraechsliste laeuft ueber eine feste Rollenfolge.
    Wer nicht darin steht, taucht gar nicht auf -- eine Person, die es
    fuer die anderen nicht gibt.
  * Kalender: dieselbe Rollenfolge, dort landete Spicy Media durch
    indexOf() === -1 ganz oben statt an ihrem Platz.
  * Dashboard: "Creator anlegen" nur fuer admin/manager -- der Server
    haette sie gelassen, den Knopf hat sie nie gesehen.
  * Personenliste: ROLLENNAME ohne 'spicy'. Der Auffangwert
    `|| p.rolle` schrieb "spicy" statt "Spicy Media" -- plausibel
    genug, um jahrelang zu bleiben.

`pruef-css-klassen.mjs` verlangt jetzt, dass kein Workspace-Skript sich
wieder eine eigene Rollenliste baut. Mit Gegenprobe, dass der Sucher so
eine Liste auch wirklich findet.

2. "DIE ZAHLEN DIESE KATEGORIE NICHT SEHEN"

Kachel und Seite waren beim Anlegen der Rolle auf ["spicy","admin"]
gesetzt worden -- "dieselben Rechte ausser Automationen". Beides jetzt
auf DogFather allein.

3. "IN CIGDEMS KALENDER STEHT IMMER NOCH MEIN MANAGER MEETING"

Das war MEIN Denkfehler von heute Frueh, nicht ein vergessener Fall.
Ich hatte "geht alle an" als "kein Teilnehmer eingetragen" definiert --
also entschied der Server, was alle angeht, und nicht der, der den
Termin anlegt. Wer niemanden eintraegt, meint aber meistens nicht
"alle", sondern "mich".

Der Fall ist entfallen. Sichtbar ist ein Termin jetzt nur noch fuer
den, der ihn angelegt hat, dem er zugeordnet ist, der das Gegenueber
ist -- oder der in der Teilnehmerliste steht. Damit ist das Markieren
im Termin die einzige Antwort auf "wen geht das an": eine sichtbare
Entscheidung im Formular statt einer unsichtbaren Regel im Server.

Calls & Protokolle rufen dieselbe Funktion auf und koennen deshalb gar
nicht auseinanderlaufen -- das war Filipes vierter Wunsch, und er ist
mit derselben Zeile erledigt.

Am laufenden System als Cigdem nachgemessen: Profil laedt ("Profil:
Luna"), Zahlen-Kachel weg und Seite gesperrt, im Kalender NUR der
Termin, bei dem sie markiert ist, Calls zeigt genau denselben.

Fuenf Pruefungen auf die endgueltige Regel umgeschrieben statt
geloescht (sicht, spicy, teilnehmer, scout-zuteilung, css-klassen).
Die dritte Drehung bei scout-zuteilung steht mit allen drei Staenden
in der Akte -- eine geloeschte Pruefung hinterlaesst keine Spur davon,
dass hier einmal etwas anderes galt.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-07 07:36:59 +02:00
DogFatherGitandClaude Opus 5 1b2874299e Uhr und Glocke in die Begruessung, Teilen in die Leiste, ein echter Fehler weg
Neun Punkte aus Filipes Bildschirmfotos. Der wichtigste war kein
Aussehen, sondern ein Fehler:

UEBEREINANDERLIEGENDE TEXTE IN DER SICHERUNGSLISTE. Das Datum entstand
aus `name.split('-').slice(1).reverse().join('.')`. Bei
"woechentlich-2026-09-06.db" ging das gut; die Sicherungen vor einem
Umbau heissen aber "vorher-2026-09-02-160012438.db" -- mit Zeitstempel.
Heraus kam "160012438.02.09.2026", dreimal so lang wie die 96-px-Spalte,
und es lief ueber den Nachbartext. Ein Muster, das Bestandteile ZAEHLT
statt sie zu SUCHEN, bricht beim ersten Namen mit einem Teil mehr. Jetzt
ein Suchmuster nach vier-zwei-zwei Ziffern -- und in der CSS eine
Kuerzung, damit der NAECHSTE zu lange Text nur abgeschnitten wird. Eine
Spalte mit fester Breite ohne Kuerzung ist immer eine Zeitbombe.

DIE BEGRUESSUNGSKACHEL. Runde Digitaluhr rechts: zwei Ringe um dieselbe
Mitte -- innen die Sekunde, aussen der Stand der Stunde. Kein
setInterval(1000): Ein fester Takt laeuft mit der Zeit aus dem Tritt und
ueberspringt Sekunden; gewartet wird bis zur naechsten VOLLEN Sekunde.
Die Glocke ist aus der Kopfleiste hierhergezogen -- mit Rueckfall, denn
zwoelf andere Seiten haben diesen Platz nicht. Nebenbei ist die Leiste
damit um ein Element leichter; sie ist am 06.09. schon einmal an einem
sechsten zerbrochen.

TEILEN-KNOPF in der Leiste, nur fuer Scout, Manager und DogFather.
Geteilt wird der EINGANG, nicht die aktuelle Seite: Ein Link auf
bereich.html?b=schutz schickt jemanden auf eine Seite, die er nicht
sehen darf. Wo es navigator.share gibt, wird es benutzt; sonst
Zwischenablage; wo beides fehlt, erscheint der Knopf gar nicht -- ein
dritter Ausgang statt einer Schaltflaeche, die nichts tut.

WEITER: Kachelreihenfolge Steckbrief -> Profile -> Zahlen. Die
Tagesliste laesst sich zuklappen und zeigt dann SIEBEN Tage (die Woche,
nicht die vier von ueberall sonst). Dialoge, Automationen-Karten,
Sicherungsblock, KI-Kasten und Call-Karten bekommen dasselbe Material
wie die Kacheln -- Leuchtschiene, Materialstaerke, Glanz.

Profilbilder brauchten nichts: Der Weg gibt es fuer jede Rolle bereits
(steckbrief.html fuer die Betreuung, derselbe Block auf profil.html fuer
Creator, Hochladen schreibt immer auf req.person.id).

ZWEI EIGENE FEHLER, beide gemessen statt vermutet:
  - Die Koernung lag in vier neuen Bloecken auf DERSELBEN Ebene wie die
    Spiegelung und erbte deren 50 % Deckkraft. Gemessen rgb(56,44,58)
    statt rgb(20,26,38) -- die Karten sahen durchsichtig aus, obwohl sie
    zu 95 % decken. Derselbe Fehler wie heute Nachmittag an der
    Anmeldekarte. Koernung gehoert auf eine eigene Ebene mit overlay.
  - `.glocke-platz:empty { display: none }` liess die Kachel wachsen,
    sobald die Glocke geladen war. Layout-Sprung von start.html: 0,708.
    Platz wird jetzt reserviert -> 0,473.

pruef-struktur: `-breit` gehoert in die Stufen-Ausnahme. Schaerfe kostet
Bytes (hohe Frequenzen lassen sich nicht wegrechnen), die mittlere Stufe
wuchs auf 230-300 KB. Die Regel bleibt inhaltlich: gross nur, WENN eine
kleinere Stufe daneben steht. Die Verkettung der beiden replace() waere
ein stiller Fehler gewesen -- fuer uhd haette sie nach `-schmal` gesucht.

Gruen: kopf-messen (3), breiten (23), glocke (26), css-klassen (15),
struktur (32), buehne (38), start-ansicht (136), handy (59),
formulare (19), barrierefrei (18), lesbarkeit (14), tempo (8).

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-07 03:40:49 +02:00
DogFatherGitandClaude Opus 5 233cd76d78 Der Handy-Durchgang: drei echte Bedienfehler, alle vom selben Ursprung
Filipe: "ich will dass du die komplette seite auf dem handy abcheckst.
ich will dass alles perfekt aussieht und bedienbar ist."

DER SCHWERSTE FUND: Auf ZWOELF Seiten war der "Meine Sicht"-Umschalter
nicht bedienbar -- wer darauf tippte, landete im Chat.

Bei 412 px (der haeufigsten Android-Breite ueberhaupt) brach die
Kopfleiste nicht um, der Umschalter wurde auf 50 px zusammengedrueckt,
sein Knopf behielt aber seine 104 px Mindestbreite und lag damit quer
ueber dem Chat-Knopf. Sichtbar war davon nichts.

Und die Ursache steht seit dem 05.09. woertlich im Kommentar daneben:
"Die Rechnung ging genau auf, solange rechts VIER Dinge standen. Mit der
Glocke sind es FUENF, und bei 320 px passte es nicht mehr." Am 06.09.
habe ich den Chat-Knopf dazugesetzt -- SECHS -- und die Schwelle bei 380
gelassen. Derselbe Fehler, eine Position weiter.

Die Lehre ist nicht "380 auf 430 erhoehen"; das waere er ein drittes
Mal, nur mit einer anderen Zahl. Eine feste Schwelle ist eine Rechnung,
die jemand einmal aufgestellt hat und die beim naechsten Knopf still
falsch wird. `flex-wrap: wrap` OHNE Schwelle rechnet nicht, sondern
misst -- es bricht genau dann um, wenn der Platz nicht reicht.

DASSELBE NOCH EINMAL, am anderen Ende: Bei 1280 px brauchte die Leiste
1235 px (Marke 375 + Bedienelemente 844 + Abstand 16) und hatte 1200.
Auch hier war der Chat-Knopf der Tropfen. Sie brach um, sobald das
Skript die Bedienelemente eingehaengt hatte, und schob die ganze Seite
52 px nach unten -- CLS 0,94. Jetzt gibt die MARKE nach (sie darf
gekuerzt werden, ein Knopf nicht), und umgebrochen wird nur noch auf
sehr schmalen Geraeten.

WEITERE ECHTE FUNDE:
  * /workspace/api/chat/ungelesen wurde auf JEDER Seite ZWEIMAL geholt:
    einmal beim Laden, einmal Millisekunden spaeter beim Aufgehen des
    Ereignisstroms. Der 'open'-Zuhoerer war fuer Wiederverbindungen
    gedacht und feuerte auch beim ersten Mal.
  * Drei Kacheln teilten sich einen Farbton mit einer anderen (18 Farben
    auf 21 Kacheln). Filipe wollte ausdruecklich, dass jede ihre eigene
    hat. Nicht eine Farbe dazuerfunden -- der ganze Farbkreis ist mit
    tools/kachel-farben.mjs neu in 21 geteilt; kleinster Abstand zweier
    Nachbarn jetzt 120 Grad (vorher 106). Dabei fiel eine feste 16 in
    der Mischschleife auf: Bei 18 Kacheln wurden die letzten beiden nie
    mitgemischt.
  * Der Agentur-Untertitel wurde auf dem Handy abgeschnitten.
  * Ein zugeklappter <details>-Kasten (Kalender-Abo) verdeckte einen
    Filter-Chip: Chromium versteckt dessen Inhalt ueber
    `content-visibility`, nicht ueber `display` -- die Kaesten behalten
    eine Groesse. Dieselbe Falle wie bei den Zeitbloecken, dieselbe
    Loesung.

UND DREI PRUEFUNGEN, DIE SELBST FALSCH LAGEN:
  * "achtzehn Kacheln" stand als feste Zahl im Test. Eine Pruefung, die
    bei jeder neuen Kachel rot wird, erzieht dazu, ihr Rotwerden zu
    ignorieren. Sie zaehlt jetzt aus bereiche.js.
  * "das Licht der Kalender-Kachel (tuerkis) muss mehr Blau als Rot
    haben" -- Wissen von aussen, und nach dem Neurechnen war der
    Kalender rosa. Gemessen wird jetzt gegen den Ton der Kachel selbst.
  * pruef-workspace-umzug meldete sein Ergebnis in eigenen Worten. Der
    Gesamtlauf las daraus NULL Pruefungen und schrieb bei JEDEM Lauf ein
    FEHL, obwohl alle 31 Punkte bestanden. Ein Fehlalarm, der immer
    kommt, macht den einen echten unsichtbar.

Und weil "BUTTON 'Meine Sicht' verdeckt" mich eine Stunde gekostet hat,
sagen pruef-handy und pruef-tempo jetzt DAZU, was verdeckt und was
springt -- mit Elternkette und Koordinaten. Ein Befund, den man nicht
verorten kann, ist ein halber.

NEU: der Kalender zum Abonnieren (Stufe 3.2). Persoenlicher, jederzeit
widerrufbarer Link fuer Google, Apple und Outlook. 36 Pruefungen, die
das ICS ZURUECKLESEN statt es anzusehen -- entfaltet, entschluesselt,
verglichen. Wichtigster Punkt: Der Weg ohne Anmeldung darf nichts
zeigen, was der Weg mit Anmeldung nicht zeigt.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-06 23:15:37 +02:00
DogFatherGitandClaude Opus 5 17157b4f18 Sicht-Umschalter: ein Auge statt des Wortes "SICHT"
Filipe zu dem Feld in der Kopfleiste: "das soll viel besser aussehen
viel geiler aber nicht so eine scheisse."

Er hatte recht. Da stand ein Etikett mit dem Wort SICHT und daneben ein
Auswahlfeld -- ein Formular, das in die Kopfleiste gerutscht war. Drei
Aenderungen:

  * DAS AUGE ersetzt das Wort. Es sagt dasselbe in einem Zeichen und
    laesst dem NAMEN den Platz, um den es eigentlich geht. Fuer
    Vorleseprogramme bleibt die Beschriftung erhalten, nur unsichtbar --
    sie ersatzlos zu loeschen haette das Feld unbeschriftet gelassen.

  * "Meine Sicht" statt "Alles (meine Sicht)". Der Zusatz erklaerte
    nichts und machte den Knopf so breit, dass am Handy nichts anderes
    mehr danebenpasste.

  * EIN KREUZ statt "zurueck zu mir". Der Satz brauchte mehr Platz als
    der Name daneben, und was ein Kreuz an einer aktiven Auswahl tut,
    weiss jeder. Die Worte bleiben im aria-label und im Titel.

DIE EIGENTLICHE VERBESSERUNG ist aber die Hierarchie: Im Normalfall
ist der Umschalter still (graues Auge, ruhiger Rand). Sobald eine
FREMDE Sicht laeuft, traegt er ganz Farbe -- nicht nur ein
Zusatzknopf am Rand.

Das ist der gefaehrlichste Zustand dieser Funktion: Wer sie vergisst,
sieht am naechsten Tag drei Aufgaben statt dreissig und haelt das fuer
den Bestand. Ein Zustand, der Schaden anrichtet, muss lauter sein als
einer, der nichts tut.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-06 17:48:03 +02:00
DogFatherGitandClaude Opus 5 4637aa24e7 Chat zwischen Creator, Scouts und Managern
Wunsch Filipe, 06.09.2026: *"eine kategorie chat, wo die creator mit
ihren manager nachrichten austauschen koennen, wie erinnerungen, fragen
und noch vieles mehr."* Auf Nachfrage entschieden: Zweier-Gespraeche UND
Gruppen; Manager und Scouts duerfen sich auch ohne gemeinsamen Creator
schreiben.

WER MIT WEM steht an EINER Stelle: schreibbareIds() in workspace.js.
Bewusst getrennt von einladbareIds() (Terminwahl): Dort geht es darum,
wen man zu einem Kalendereintrag dazustellen darf -- harmlos. Ein Chat
legt ein dauerhaftes Gespraech an, schickt eine Benachrichtigung und
macht den eigenen Namen sichtbar. Zwei Fragen, zwei Funktionen.

Ein Creator erreicht seine Betreuer und DogFather, KEINEN fremden
Creator. Eine Gruppe ist kein Schlupfloch: Jede Nummer wird einzeln
gegen dieselbe Regel geprueft.

SOFORT STATT NACHFRAGEN IM TAKT (SSE). Ein Chat, der alle fuenf
Sekunden fragt, ist fuenf Sekunden langsam und stellt bei zehn
Angemeldeten 7200 Anfragen in der Stunde fuer Nachrichten, die es
meistens nicht gibt. Kein WebSocket: Hier fliesst alles in eine
Richtung, und SSE uebersteht einen Verbindungsabriss von selbst.

DIE ZAHL STEHT AUF JEDER SEITE, nicht nur im Chat. Eine Nachricht, die
man erst sieht, wenn man den Chat aufmacht, ist keine Nachricht --
sie ist ein Fundstueck.

Push aufs Handy nur an die, die NICHT gerade zusehen. Wer die Seite
offen hat, sieht es ohnehin; ihm zusaetzlich etwas aufs Handy zu
schicken ist der schnellste Weg, dass er Benachrichtigungen abschaltet.

WAS BEWUSST NICHT GEHT:
  * Niemand liest fremde Gespraeche mit -- auch DogFather nicht. Ein
    Chat, in dem der Chef stillschweigend mitliest, ist kein Chat.
    Er kann jederzeit jedem schreiben, aber sichtbar.
  * Eine abgeschickte Nachricht laesst sich nicht aendern, nur
    zuruecknehmen. Wer Absprachen nachtraeglich umschreiben kann, macht
    den Verlauf wertlos. Zurueckgenommenes hinterlaesst einen Hinweis
    statt eines Lochs.

DAZU: CALL-LISTE NACH ZEIT GEGLIEDERT

Wunsch mit Bild von "STEHT AN 27": *"die liste soll kategorisiert sein
und werden mit einem button zum auf und zu machen."* Jetzt Heute /
Diese Woche / Naechste Woche / Spaeter, offen nur der erste gefuellte
Block. Nach ZEIT und nicht nach Titel: Auf dem Bild waren fast alle
"Community-Talk" -- nach Titel gruppiert haette man zwei Ueberschriften
und darunter dieselbe lange Liste.

DER FUND, DER DIE FUNKTION GERETTET HAT: Ein zugeklappter Block zeigte
seinen Inhalt trotzdem -- 367 Pixel Hoehe bei open=false. <details>
versteckt seinen Inhalt naemlich nur, solange niemand dem Inhalt eine
eigene display-Angabe gibt, und .gruppe__karten traegt display:grid.
Der Knopf haette sich bewegt und sonst nichts getan. Im Bildschirmfoto
fiel es nicht auf, weil der Ausschnitt genau darueber endete.

Ausserdem gefunden und behoben:
  * Ein Wettlauf beim Abschicken: War der Ereignisstrom schneller als
    die Antwort auf das POST, stand die eigene Nachricht zweimal im
    Verlauf.
  * Die Chatseite war zu hoch -- die Kopfleistenhoehe stand als fester
    Wert (62 px) im CSS, am Handy ist sie doppelt so hoch. Das
    Eingabefeld stand halb unter dem Bildschirmrand. Jetzt gemessen.
  * Der Platzhalter "Enter schickt ..." brach am Handy um UND stimmte
    dort nicht: Ohne Tastatur schickt Enter absichtlich nicht.
  * Der Dialog benutzte Klassen aus aufgaben.css, das chat.html nicht
    lud -- gemeldet von pruef-css-klassen, bevor jemand einen
    ungestylten Dialog zu sehen bekam.

Pruefungen: pruef-chat (44 Punkte, Rechte und Sichtbarkeit),
pruef-chat-optik (24, zwei echte Browser schreiben sich),
pruef-call-kategorien (16).

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-06 16:28:58 +02:00
DogFatherGitandClaude Opus 5 e7b277b7fc Die Startseite log nicht -- sie war nur alt. Und Protokolle lassen sich loeschen
Drei Meldungen aus einer Nachricht.

1. "WIRD IMMER NOCH ANGEZEIGT"
   Ein Protokoll war geschrieben, die Startseite meldete trotzdem weiter
   "1 Gespraech hat noch kein Protokoll".

   NACHGESTELLT statt vermutet: Der Server lag die ganze Zeit richtig.
   Der Hinweis erscheint, sobald ein vergangenes Gespraech kein Protokoll
   hat, und verschwindet in dem Moment, in dem eines geschrieben ist --
   nachgemessen, beides.

   Falsch war der BILDSCHIRM. Browser legen eine verlassene Seite
   vollstaendig beiseite (bfcache) und holen sie beim Zurueckgehen
   unveraendert hervor, mitsamt allen Zahlen vom ersten Laden. Kein
   Skript laeuft dabei erneut. Wer ein Protokoll schreibt und dann auf
   "Zurueck" tippt, sieht zwangslaeufig den Stand von vorher.

   Das ist kein Schoenheitsfehler: Eine Zahl, die etwas Falsches
   behauptet, ist schlimmer als gar keine -- man glaubt ihr ja. Und sie
   kostet danach Vertrauen in ALLE Zahlen.

   kopf.js laedt eine zurueckgeholte Seite jetzt neu. Nur dann
   (`event.persisted`), nicht bei jedem Anzeigen -- sonst waere es eine
   Endlosschleife. Gilt fuer jede Workspace-Seite, nicht nur die
   Startseite.

2. PROTOKOLLE LOESCHEN -- NUR DOGFATHER
   Bewusst istDogFather und nicht istLeitung: Ein Manager hat sonst
   ueberall dieselben Rechte, hier ausdruecklich nicht. Wer ein Protokoll
   entfernen darf, kann nachtraeglich bestimmen, was besprochen wurde.

   Geloescht wird NUR das Protokoll. Das Gespraech bleibt im Kalender und
   rutscht wieder zu "Protokoll fehlt" -- die Handlung ist damit
   umkehrbar: neu schreiben, fertig. Die daraus entstandenen AUFGABEN
   bleiben ebenfalls stehen; sie sind echte Arbeit, die jemand uebernommen
   hat, und mit einem Klick auf ein Protokoll zu verschwinden waere ein
   stiller Datenverlust an ganz anderer Stelle.

   Der Knopf steht nur bei DogFather. Ein Knopf, der bei anderen
   erscheint und dann abgewiesen wird, ist eine Einladung zum Aergernis.

3. IMMER NUR EINS OFFEN
   Vorher liessen sich beliebig viele Protokolle gleichzeitig aufklappen
   -- die Seite wurde so lang, dass die Liste darunter aus dem Blick
   geriet. Ein neu geoeffnetes Gespraech schliesst jetzt das vorherige.
   Beim Laden ist alles zu.

GEPRUEFT: server/pruef-protokoll-loeschen.mjs, 20 Pruefungen. Die
Zurueck-Pruefung misst an EINZAHL gegen MEHRZAHL ("1 Gespraech HAT" gegen
"2 Gespraeche HABEN") -- die Zahl selbst steht in einem eigenen Feld und
taucht im Fliesstext nicht auf. Drei Gegenproben: dass der Hinweis nach
dem Reparieren ueberhaupt noch anschlaegt (sonst waere "verschwunden"
auch bei kaputtem Hinweis gruen), dass eine Managerin 403 bekommt und das
Protokoll danach unveraendert dasteht, und dass der Loeschknopf bei ihr
gar nicht erst gezeichnet wird. Bestehende Laeufe gruen: Startansicht 133,
Rollen 97, Kalender 84, Serien 67, Protokoll-Klappe 52, Handy 50, Ampel
47, Freie Namen 32, Code 17.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-02 23:45:45 +02:00
DogFatherGitandClaude Opus 5 1d54058760 Die Sicht wirkt jetzt auch auf die SEITE, nicht nur auf die Listen
Gemeldet: "ich hab oben die Ansicht von Tili ausgewaehlt und seh immer
noch die Seite genau wie meine." Das stimmte.

Der Umschalter war HALB gebaut. Die Daten dahinter folgten der Auswahl
(Aufgaben, Kalender, Dateien, Bereiche, Hinweise, Suche) -- die Seite
drumherum nicht: /workspace/api/ich lieferte immer den Angemeldeten, und
daraus baut die Startseite ihre Kacheln, die Rollenzeile und die
Begruessung. DogFather sah einen fremden Arbeitsplatz in seiner eigenen
Verkleidung.

ZWEI FEHLER STECKTEN DARIN.

1. /api/ich verschwieg die gewaehlte Sicht. Es liefert sie jetzt als
   eigenes Feld `sicht` -- NEBEN den eigenen Angaben, nicht an ihrer
   Stelle. Die Oberflaeche braucht beides: WER BIN ICH (Kopfleiste,
   "das bin ich" in Listen, alles was schreibt) und WESSEN ARBEITSPLATZ
   SEHE ICH (was gezeigt wird). Die beiden zu vermischen waere der
   sichere Weg dazu, dass irgendwann etwas unter fremdem Namen
   gespeichert wird.

2. EIN FEHLER DER REIHENFOLGE, und der war der eigentliche Grund.
   In kopf.js wurde `aktiv` (welche Sicht laeuft) erst in
   sichtAufbauen() gesetzt -- das laeuft ueber werZeigen(), also
   NACHDEM die Seite ihre erste Abfrage abgeschickt hat. Ausgerechnet
   /api/ich, aus dem Kacheln, Rolle und Begruessung entstehen, ging
   damit IMMER ohne die gewaehlte Sicht hinaus. Beide Zeilen waren fuer
   sich richtig; im Quelltext sieht man so etwas nicht.

WAS JETZT PASSIERT: In der Sicht auf einen Creator verschwinden die
Leitungs-Kacheln (18 -> 14, kein "Personen & Zugaenge", keine
"Automationen"), die Gruppe heisst "Wissen" statt "Team & System" --
genau wie bei ihm -- und unter dem Gruss steht "Arbeitsplatz von Tili ·
Creator". Plakette und Name oben bleiben die eigenen: Man ist weiterhin
man selbst, man sieht nur einen anderen Arbeitsplatz.

WARUM DIE PRUEFUNG DAS UEBERSEHEN HAT, und das ist die Lehre: Sie hat
geprueft, dass WENIGER AUFGABEN erscheinen -- und das stimmte ja. Sie
prueft genau die Haelfte, die fertig war. Jetzt prueft sie auch, dass
die Leitungs-Kacheln verschwinden, die Gruppentitel mitgehen und
dransteht, wessen Arbeitsplatz man ansieht.

Beim Schreiben dieser Pruefung dieselbe Falle noch einmal: Sie mass
"seine eigenen Kacheln", waehrend aus einem Abschnitt davor noch die
Scout-Sicht lief (die ueberlebt den Seitenwechsel, das ist gewollt), und
meldete einen Fehler, den es nicht gab. Eine Pruefung, die ihren eigenen
Ausgangszustand nicht herstellt, misst den Nachhall der vorigen.

31 von 31 Dateien, 1236 von 1236 Einzelpunkten.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-02 16:21:39 +02:00
DogFatherGitandClaude Opus 5 d7cf598b00 "Heute" war zwei Stunden lang gestern -- und vier Fehler auf Handy und PC
Auftrag: "einen grossen Check machen, ob alles klappt, auf dem Handy und
PC." Dafuer ein neuer Rundgang (pruef-grosscheck.mjs), der stumpf ueber
alles geht: 19 Workspace-Seiten mal 4 Rollen mal 2 Bildschirmgroessen
plus 33 oeffentliche Seiten, zweimal. 208 Seiten, 50 774 Elemente.

Solche Rundgaenge finden andere Fehler als gezielte Pruefungen: nicht
den falsch gerechneten Wert, sondern die Seite, die bei genau einer
Rolle ueberlaeuft.

=== DER WICHTIGSTE FUND: "heute" war in UTC gerechnet ===

Der Check lief um 01:10 Uhr. Ortszeit war der 2. September, in UTC noch
der 1. -- und in diesem Fenster rechnete die Anwendung an ZWOELF Stellen
"heute" als toISOString(), also in UTC. Server und Benutzer stehen beide
auf Europe/Berlin.

Was das im Alltag bedeutete, jede Nacht zwischen 0 und 2 Uhr:
  * eine heute faellige Aufgabe galt noch nicht als faellig
  * eine um Mitternacht ueberfaellig gewordene erschien erst um 2 Uhr
  * der Filter "Heute faellig" zeigte den Vortag
  * Datumsfelder schlugen gestern vor
  * der Kalender begann seine Vorgabe einen Tag zu frueh

Also genau dann, wenn nach einem Stream gearbeitet wird.

kalender.js machte es die ganze Zeit RICHTIG -- samt Begruendung, warum
die ARITHMETIK trotzdem in UTC laufen muss (UTC-Mittag ueberlebt die
Zeitumstellung; wer lokal rechnet, verliert am 27. Oktober einen Tag).
Diese Trennung gilt jetzt ueberall, aus je einer Quelle:
  RECHNEN mit Datumsangaben  -> UTC-Mittag, unveraendert
  WELCHER TAG IST HEUTE      -> Ortszeit (heuteLokal/tagLokal im Server,
                                window.heuteLokal in kopf.js)

WIE ES AUFFIEL, und das ist die eigentliche Lehre: Zuerst schlugen zwei
Pruefungen fehl -- und die Ursache lag in IHNEN, sie rechneten selbst in
UTC (36 Stellen in 17 Dateien). Nach deren Reparatur schlugen sie WIEDER
fehl, und erst da zeigten sie auf die Anwendung. Wer beim ersten Mal
aufgehoert haette ("ist ja nur die Pruefung"), haette den echten Fehler
nie gesehen.

Nachtrag desselben Musters: pruef-uebersicht legte den Termin weiterhin
in UTC an, waehrend die Erwartung schon auf Ortszeit stand. Wer eine
Datumsrechnung umstellt, muss BEIDE Seiten umstellen -- die, die
schreibt, und die, die prueft.

=== VIER FEHLER AUF HANDY UND PC ===

1. Ein langer Creator-Name ("SpongBobSchwammKopf") schob die Startseite
   auf dem Handy um 48 Pixel aus dem Bild -- ein Wort ohne Trennstelle,
   und die Seite liess sich seitlich wegschieben. Trifft echte Namen:
   Creator heissen selten "Tim".

2. Die klebende Speicherleiste verdeckte auf dem Handy ein Textfeld.
   Beim Tippen sieht man die eigene Zeile nicht. Behoben mit
   scroll-margin-bottom (WCAG 2.2, 2.4.11 "Focus Not Obscured").

3./4. Zwei Beschriftungen waren mit 9,6 px (Uebersicht: "ueberfaellig",
   "dringend", "offen") und 9,9 px (Kalender: "heute") zu klein. Fuers
   Handy gab es laengst eine Ausnahme -- nur der Rechner war vergessen
   worden. Ausgerechnet die Woerter, die den Zahlen ihre Bedeutung geben.

=== WAS KEINE FEHLER WAREN ===

Der erste Durchgang meldete 19 Maengel, die keine waren. Alle einzeln im
Quelltext nachgeprueft und dem Rundgang beigebracht:
  * Kacheln und Kopfzeilen "abgeschnitten" -- das Wasserzeichen ragt
    ABSICHTLICH ueber den Rand (steht so im Quelltext)
  * "verdeckt: wahl2__echt" -- das echte <select> liegt absichtlich
    unsichtbar unter seinem Knopf
  * "zurueck-knopf__text abgeschnitten" -- das uebliche Muster fuer
    "nur fuer Vorleseprogramme"
  * drei "zu kleine" Verweise -- WCAG 2.5.8 nimmt Verweise im Fliesstext
    AUSDRUECKLICH aus. Eine Pruefung, die ihre eigene Messlatte nicht
    kennt, misst nichts.

Beim vierten Punkt haette ich fast an der falschen Stelle repariert.

Und statt die Sticky-Meldung abzuschalten (dann faende sie auch echte
Ueberdeckungen nie mehr), wurde sie GENAUER: Ueberdeckt etwas Klebendes
ein Eingabefeld, ist das nur in Ordnung, wenn das Feld genug
scroll-margin-bottom hat, um darunter hervorzukommen. Aus einer vagen
Meldung wird eine pruefbare Zusage.

Vier Gegenproben belegen, dass der Rundgang ueberhaupt etwas finden
kann: ein zu breites Element, ein winziger Knopf, ein winziger Verweis
AUSSERHALB eines Satzes und ein wirklich abgeschnittenes Wort werden
alle gemeldet. Ohne diesen Nachweis waere "alles in Ordnung" wertlos.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-02 01:51:28 +02:00
DogFatherGitandClaude Opus 5 1c00770ec5 Lesbarere Kaesten, und DogFather kann durch fremde Augen sehen
SCREEN 1 -- "die Kachel ganz leicht dunkler, so dass man den Text besser
gelesen bekommt, aber nicht zu viel, so dass man den Hasen noch sieht."

Die Erklaerkaesten stehen jetzt auf 88 statt 78 Prozent Deckung. Zehn
Punkte sind gemessen der Unterschied zwischen muehsam und ruhig lesbar
und lassen zwoelf Prozent Bild durch -- das Motiv bleibt sichtbar.

"und die von wichtigen und neuen PDFs sollen auch staerker sein."
Das war kein Geschmack, sondern ein Fehler: `background` ist eine
Eigenschaft, keine Schicht. Die Zeile
`background: rgba(232,192,125,.045)` hat die Flaeche nicht getoent,
sondern ERSETZT -- uebrig blieben viereinhalb Prozent Deckung. Damit war
ausgerechnet die Anleitung, die jeder lesen soll, die am schwersten
lesbare der Seite. Die Toenung liegt jetzt als Schicht darueber.
Gemessen: 88 % gegen 78 % bei einer gewoehnlichen.

pruef-lesbarkeit.mjs misst das an ECHTEN PIXELN (Text kurz unsichtbar
machen, Flaeche fotografieren, WCAG-Formel) und kennt ZWEI Grenzen --
lesbar genug UND durchsichtig genug. Mit nur einer haette sie eine
schwarze Flaeche am besten gefunden, und das wollte niemand.

SCREEN 2 -- "ich will alles von den Scouts und Managern einsehen
koennen, auswaehlen, was und von wem. Ueberall, auf jeder Seite.
NUR WIR BEIDE SOLLEN DIESE OPTION HABEN."

Die naheliegende Loesung waere ein Filter je Seite gewesen -- also eine
zweite Rechteregel in zwoelf Modulen, und eine Rechteregel an zwoelf
Stellen stimmt irgendwann an elf. Stattdessen wird die PERSON getauscht,
nicht die Regel: Waehlt DogFather einen Scout, laufen alle vorhandenen
Sichtbarkeitsregeln unveraendert mit diesem Scout. Er sieht exakt dessen
Arbeitsplatz -- nicht mehr, nicht weniger. Keine neue Rechteregel.

Im Browser genauso: EIN Ort statt vierzehn. fetch wird einmal umgeleitet
und haengt den Wert an jede lesende Abfrage an. Neue Seiten sind damit
von selbst dabei; man kann es nicht vergessen.

Drei Sicherungen: nur admin (auf dem SERVER geprueft, nicht in der
Oberflaeche), nur lesend (geschrieben wird immer im eigenen Namen --
sonst staende im Protokoll der falsche Name), nur aktive Personen.

Und ein Rahmen um die Seite, solange eine fremde Sicht laeuft. Der
gefaehrlichste Fall ist nicht, dass man nicht umschalten kann, sondern
dass man vergisst, dass man umgeschaltet hat -- und drei Aufgaben statt
dreissig fuer den Bestand haelt.

FUENF FEHLER, DIE DIE PRUEFUNGEN GEFUNDEN HABEN:

1. steckbrief.html hat die Kopfleiste NIE gefuellt -- dort stand
   monatelang "…" statt des eigenen Namens. Aufgefallen, weil der
   Umschalter dort fehlte. Jetzt zusaetzlich ein Netz darunter: Meldet
   sich nach kurzer Zeit niemand, holt der Kopf sich selbst, wer
   angemeldet ist. Die naechste neue Seite kann es nicht mehr vergessen.

2. Der Umschalter sprengte die Kopfleiste (46 px am Rechner, 117 px am
   Handy) und drueckte den Abmelden-Knopf hinaus.

3. Ich habe das <select> gestaltet -- wahl.js ersetzt aber jedes
   Auswahlfeld durch einen eigenen Knopf und schrumpft das echte Feld
   auf einen Pixel. Meine Regeln haben es wieder auf 20 x 44 aufgeblasen,
   wo es als unsichtbares Hindernis ueber dem Knopf lag. Gestaltet wird
   jetzt der Knopf.

4. Ein Wettlauf: Auf profil.html rufen zwei Dateien werZeigen() auf.
   Beide kamen an "gibt es den Umschalter schon?" vorbei, bevor eine ihn
   angehaengt hatte -- zwei Umschalter uebereinander. Die Sperre gehoert
   vor das erste await.

5. Die Handy-Pruefung bemaengelte ein Schild, das dort per display:none
   gar nicht erscheint. Sie sieht jetzt nur noch sichtbaren Text an --
   eine Pruefung, die Unsichtbares anmahnt, gewoehnt man sich ab zu
   lesen.

Dazu zwei Messfehler in den Pruefungen selbst: getComputedStyle liefert
ein LEBENDES Objekt (die Farbe wurde gelesen, nachdem der Text
unsichtbar gemacht war -- gemeldet wurden 1,17:1 fuer tadellos lesbaren
Text), und ein Vergleich lief still ins Leere, weil die Vergleichsdaten
fehlten.

pruef-sicht.mjs stellt den MISSBRAUCH an den Anfang: Scout, Manager und
Creator haengen ?sicht= an und muessen ignoriert werden; erfundene
Nummern, Buchstaben und ein Einschleusversuch fallen auf die eigene
Sicht zurueck; eine abgeschaltete Person liefert keine Sicht mehr; und
was DogFather bei fremder Sicht anlegt, steht unter SEINEM Namen.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-01 21:20:23 +02:00
DogFatherGitandClaude Opus 5 a129525cb7 Kennzahlen werden Wege, Team wird sichtbar, Felder bekommen ein Aussehen
Vier Wuensche vom 01.09.2026, dazu ein gemeldeter Fehler.

SCREEN 1 -- "wenn man auf die Kisten drueckt, sofort zu der Seite,
diesem Punkt". Jede Kennzahl im Bericht fuehrt jetzt dorthin, wo die
gezaehlten Dinge stehen: nicht nur auf die richtige Seite, sondern auf
die richtige Stelle (?zeigen=...). Ein gemeinsamer Helfer in kopf.js,
damit nicht jede Seite ihr eigenes Sprungverhalten erfindet.

  Auf dem Aufgabenbrett wird HERVORGEHOBEN, nicht gefiltert -- das Brett
  lebt davon, dass man die vier Spalten nebeneinander sieht. Bei den
  Dateien wird gefiltert, denn die Seite hat ohnehin eine Filterleiste,
  und deren Knoepfe zeigen dann mit an, wo man steht. Der Kalender
  schaltet auf die Liste um: In der Monatsansicht liesse sich
  "vergangen" gar nicht sinnvoll markieren.

  Immer mit einem Weg zurueck ("Alles zeigen"), der auch den Parameter
  aus der Adresse nimmt. Eine Seite, die gefiltert bleibt, ist eine
  Falle: Man kommt spaeter wieder, sieht drei von zwanzig Aufgaben und
  haelt das fuer den Bestand.

  Drei Entscheidungen gegen den ersten Entwurf:
  * KEIN ?creator= im Verweis. Das sah hilfreich aus und waere eine
    Luege gewesen -- keine Zielseite liest den Wert.
  * Kisten mit Null fuehren NIRGENDWOHIN. Ein Weg zu null Dingen ist
    eine Enttaeuschung, kein Angebot.
  * "neu angelegt" fuehrt ohne Ausschnitt aufs Brett: Der Bericht zaehlt
    einen Zeitraum, das Brett kennt keinen. Eine Hervorhebung, die nicht
    dieselbe Menge trifft, ist schlimmer als keine.

SCREEN 2 -- "ich will, dass wir Manager, Scouts, DogFather auch die
Fotos, Namen und so alles sehen". Der Steckbrief war eine Einbahnstrasse:
Jeder pflegte seinen, niemand bekam ihn je zu Gesicht. Die
Schnittstelle dafuer lag fertig da und wurde von keiner Seite
aufgerufen. Jetzt steht "Das Team" auf steckbrief.html und (fuer
Creator) auf profil.html -- nach Rollen gruppiert, mit Bild, Rolle,
eigenem Satz und Kanaelen. Wer wen sieht, entscheidet weiterhin der
Server; ein Creator sieht seine Betreuung, nicht die anderen Creator.

SCREEN 4 -- "das soll richtig geil aussehen und nicht so einfach, auch
die Schrift". Die Ursache war kein Geschmack, sondern ein Loch im
Aufbau: Jede Seite gestaltete ihre Felder mit einem EIGENEN Selektor,
und wer ein Feld anderswo hinsetzt, faellt durch alle Netze. Genau so
stand "Ein Satz ueber dich" als grauer Kasten in MONOSPACE da --
<textarea> faellt ohne `font: inherit` auf Schreibmaschinenschrift
zurueck. Jetzt gibt es eine Grundlage fuer jedes Feld, und die drei
wortgleichen Kopien in aufgaben/profil/bereich sind weg.

  Der erste Anlauf setzte dort auch `width: 100%` -- die Pruefung
  meldete sofort Felder von 28 statt 362 Pixeln. Breite ist LAYOUT und
  gehoert der Seite; eine Grundlage mit Staerke null verliert jeden
  Breitenstreit, also darf sie ihn nicht anfangen.

SCREEN 5 -- "wieso seh ich mein Bild da nicht?" Ein lehrreicher Fehler:
Der Server liefert das Bild laengst mit, und im Quelltext dort steht
ausdruecklich "es steht in der Kopfleiste JEDER Seite UND IN DER
BEGRUESSUNG". Die Absicht war aufgeschrieben, die Haelfte nie gebaut --
und aufgefallen ist es nicht, weil ein Buchstabe im Kreis nicht falsch
aussieht, nur eben nicht wie man selbst.

PRUEFUNGEN. Zwei neue (pruef-sprung, pruef-team), eine erweiterte
(pruef-formulare). Sie haben vier echte Fehler gefunden, die mit blossem
Auge nicht zu sehen waren:
  * Der Sprung auf "dringend" hob auch ERLEDIGTE dringende Eintraege
    hervor -- man klickt auf "2" und bekommt drei markiert.
  * Auf einer leeren Zielseite erschien gar keine Erklaerung (frueher
    Ausstieg uebersprang sie). Das ist der wichtigere Fall: Wer auf eine
    Zahl klickt und im Leeren landet, glaubt, er sei falsch abgebogen.
  * Das Kachel-Merkzeichen stiess mit der Zahl zusammen.
  * Die Feldpruefung fand vier RICHTIGE Felder falsch (die Kanaele holen
    ihren Rahmen vom Umschlag mit dem "@"). Eine Pruefung, die
    Richtiges anmahnt, gewoehnt man sich ab zu lesen.
Und zwei Faelle, in denen die Pruefung sich selbst belogen haette: null
gefundene Felder galten als "in Ordnung", und der Ueberdeckungsvergleich
war nach einer Aenderung ohne ein einziges Vergleichselement gruen.
Beide zaehlen jetzt mit, wie viel sie tatsaechlich angesehen haben.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-01 20:18:39 +02:00
DogFatherGitandClaude Opus 5 1fe443e59c Handy durchgeprueft, Lichtfarbe je Kachel, haengendes Licht behoben
DAS LICHT BLIEB HAENGEN -- vier Ursachen, jede einzeln behoben:

1. EIN WETTLAUF. Zwischen dem Anmelden eines Bildaufbaus und seinem
   Ablauf konnte der Zeiger die Karte laengst verlassen haben. Dann hatte
   pointerout schon aufgeraeumt, und der Bildaufbau schaltete das Licht
   gleich wieder AN. Der haeufigste Fall und der unauffaelligste.
2. UEBER EINE LUECKE VERLASSEN. Wer eine Karte nicht ueber eine
   Nachbarkarte verliess, sondern ueber den Zwischenraum, loeste kein
   Ereignis aus, das die alte Karte kannte.
3. GESCROLLT, OHNE DIE MAUS ZU BEWEGEN. Die Karte wandert unter dem
   stehenden Zeiger weg -- es kommt gar kein Zeigerereignis. Jetzt wird
   beim Scrollen nachgesehen, ob die beleuchtete Karte noch unter dem
   Zeiger liegt.
4. FENSTER ODER TAB VERLASSEN. Auch dort kommt nichts mehr.

Es gibt jetzt genau EINE beleuchtete Karte -- mehr kann es nicht geben,
es gibt ja nur einen Zeiger. Beim Wechsel geht die alte aus, bevor die
neue angeht.

DIE FARBE GEHOERT ZUR KACHEL. Auf der Wissensseite leuchteten alle sechs
Welten violett, weil die Farbe dort --w heisst und der ganze uebrige
Workspace --ton benutzt. Das Licht griff auf --ton zu, fand nichts und
nahm den Farbton der SEITE. Dieselbe Luecke bei den Aufgaben-Spalten
(--sfarbe), den Kalenderkarten (--afarbe) und den Kalenderzeilen
(--zfarbe). Alle vier setzen jetzt --ton mit.

Nachgewiesen an echten Bildpunkten, nicht am Quelltext: Der Zeiger wird
auf die Aufgaben-Kachel gesetzt (dort muss Rot ueberwiegen: 85 zu 22)
und auf die Kalender-Kachel (dort Blau: 71 zu 13). Ein
Zeichenkettenvergleich haette das nicht gekonnt -- der Browser rechnet
color-mix() aus und schreibt je nach Fassung rgb(), color() oder oklab()
zurueck.

DAS HANDY, komplett durchgeprueft: neue pruef-handy.mjs faehrt alle
fuenfzehn Seiten auf DREI echten Geraetegroessen ab (320 px iPhone SE,
390 px iPhone, 412 px Android) und misst fuenf Dinge, die am Rechner
unsichtbar sind. Gefunden und behoben:

  * ZWEI ECHTE UEBERLAEUFE (startcheck +27 px, automation +33 px). Die
    Seite liess sich waagerecht schieben -- auf einem Telefon der
    schlimmste Fehler. Ursachen: zwoelf Raster mit festem Mindestmass
    (minmax(280px, 1fr) kann nicht schrumpfen -> min(280px, 100%)),
    zwoelf feste Mindestbreiten an Auswahlfeldern, und ein "flex: none"
    an den Stufen-Knoepfen, das jedes Schrumpfen verbot. "width: 100%"
    allein reichte dort nicht.
  * BERUEHRZIELE unter 24 px (WCAG 2.2, Kriterium 2.5.8). Auswahlfelder
    waren 18 bis 22 px hoch. Jetzt 44 px -- die Empfehlung von Apple und
    Google, und der Daumen ist nun einmal breiter als ein Mauszeiger.
    Nebenbei behebt die Schriftgroesse 16 px das Hineinzoomen von iOS.
  * SCHRIFT unter 11,7 px an 52 Stellen. Gesucht wurden sie nicht von
    Hand -- das waere ein Ratespiel gewesen und haette die Haelfte
    uebersehen -- sondern durch Durchsuchen der Stildateien nach
    font-size unter 0,73rem.

ZWEI FEHLER IN DEN EIGENEN PRUEFUNGEN gefunden und behoben: Die
Schriftregel griff zuerst gar nicht (start.css wird VOR den Seitenstilen
geladen, bei gleicher Staerke gewinnt die spaetere -- jetzt mit
body.start qualifiziert), und die Lichtpruefung scrollte 600 px und
stellte nicht zurueck, sodass die folgende Pruefung ins Leere zeigte.

GEGENPROBE gemacht: Mit absichtlich eingebauten Fehlern (8-px-Schrift,
500 px breiter Inhalt) meldet die Handypruefung sofort Rot. Eine
Pruefung, die immer bestaetigt, bestaetigt nichts.

Alle achtzehn Pruefungen laufen gruen.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-01 14:48:48 +02:00
DogFatherGitandClaude Opus 5 41ffb91688 Das Licht folgt dem Zeiger - auf jeder Karte, und der Rand mit
Auf der Startseite gab es einen Lichtfleck unter dem Zeiger. Jetzt auf
JEDER Karte im ganzen Workspace -- und mit zwei Schichten statt einer:

  der FLECK   ein weicher Schein unter dem Zeiger, in der Farbe des
              Bereichs (--ton). Eine Aufgabenkarte leuchtet orange, eine
              Kalenderkarte tuerkis.
  der RAND    eine helle Stelle, die auf der KANTE mitwandert.

Der Rand ist der Teil, der den Unterschied macht. Er entsteht aus einem
Farbverlauf, von dem eine Maske nur den ein Pixel breiten Saum stehen
laesst: zwei Ebenen, eine ueber die Innenflaeche, eine ueber den ganzen
Kasten, und mask-composite: exclude laesst genau die Differenz uebrig --
den Rahmen. Dadurch leuchtet wirklich die Kante an der Stelle, an der
der Zeiger steht, statt eines Rechtecks, das so tut als ob.

Beides steckt in einem eingefuegten <span class="licht">. Ein eigenes
Element statt ::before/::after am Kasten selbst, weil die bei fast
allen Karten schon belegt sind (Akzentstreifen, Wasserzeichen) -- ein
Pseudo-Element doppelt zu benutzen geht nicht, und der Fehler faellt
erst auf, wenn eines von beiden verschwindet.

Kosten: EIN Zuhoerer fuer das ganze Dokument, gedrosselt auf einen
Bildaufbau, passiv angemeldet. Das Licht-Element wird beim ersten
Ueberfahren eingesetzt, nicht beim Laden -- Karten entstehen laufend
neu, wenn Listen sich aktualisieren. Ohne feinen Zeiger (Handy) und bei
"weniger Bewegung" laeuft gar nichts und es wird auch nichts eingefuegt.

pointerout feuert auch beim Wechsel zwischen Kindern INNERHALB einer
Karte. Ohne die Pruefung auf relatedTarget haette das Licht bei jeder
Bewegung ueber ein Wort hinweg geflackert.

DIE ALTE FASSUNG IN start.js IST WEG. Sie stehen zu lassen haette zwei
Zuhoerer auf denselben Bewegungen bedeutet -- doppelte Arbeit bei jedem
Zeigerzucken, und der Fehler waere erst aufgefallen, wenn jemand die
eine geaendert haette und sich nichts tat.

GEPRUEFT AN ECHTEN BILDPUNKTEN, nicht am Quelltext: Der Zeiger wird in
die Mitte einer Kachel gesetzt, dann wird die Helligkeit der Kante
direkt darueber gegen dieselbe Kante an der fernen Ecke gemessen.
Ergebnis 50 gegen 17. Geht die Maske jemals verloren, waere die ganze
Karte eingefaerbt und der Text unlesbar -- das faellt damit sofort auf.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-01 11:51:47 +02:00
DogFatherGitandClaude Opus 5 299ef0d506 Eigenes Profil fuer jeden - mit Bild und Kanaelen
SCREEN 1: Jeder im Workspace hat jetzt seinen eigenen Steckbrief --
Creator, Scout, Manager und DogFather gleichermassen. Ein Bild, ein Satz
ueber sich, und die Kanaele, auf denen er unterwegs ist. Er steht ganz
oben auf profil.html, ueber der Creator-Akte; die ist etwas anderes
(die fuehren die Betreuer, den Steckbrief fuehrt man selbst).

Das Bild erscheint sofort ueberall: in der Kopfleiste jeder Seite und in
der Begruessung. /api/ich liefert es deshalb gleich mit -- das spart auf
jeder Seite eine zweite Abfrage und verhindert, dass die Plakette erst
als Buchstabe erscheint und dann umspringt. Faellt das Bild aus, steht
der Buchstabe da: Er wird nicht ersetzt, sondern liegt darunter.

WARUM KEINE ECHTE TIKTOK-ANMELDUNG. "Mit TikTok verbinden" klingt nach
OAuth. Das waere: ein Entwicklerkonto mit App-Freischaltung, eine
Pruefung durch TikTok (Wochen, widerrufbar), je Person ein Zugriffstoken,
das ablaeuft, erneuert werden muss und -- wenn es abhandenkommt --
fremden Zugriff auf ein fremdes Konto bedeutet. Dafuer bekaeme man
Follower-Zahlen.

Gebraucht wird hier aber "Wer ist das, und wo finde ich ihn?". Dafuer
genuegt der oeffentliche Name. Gespeichert wird deshalb NUR das Handle --
kein Token, kein Passwort, nichts, was abhandenkommen kann. Daraus wird
ein Verweis auf den Kanal. Vier Kanaele: TikTok, Instagram, YouTube,
Twitch. Sollen spaeter echte Zahlen dazukommen, ist das ein eigenes
Vorhaben -- der Name hier bleibt dann trotzdem richtig.

Eingefuegt werden darf, was Leute wirklich in der Zwischenablage haben:
"@name", "https://www.tiktok.com/@name" oder der Name allein. Alles wird
auf den Namen zurueckgefuehrt, statt eine Fehlermeldung zu zeigen.

SICHERHEIT beim Bild -- die drei Stellen, an denen Profilbilder
typischerweise scheitern:
  1. Der Typ wird an der SIGNATUR der Datei geprueft, nicht am
     Content-Type, den der Absender behauptet. Ein umbenanntes SVG mit
     Skript darin kaeme sonst durch und liefe im Namen der Domain --
     mit der Sitzung des Betrachters.
  2. Auf der Platte bekommt jede Datei einen Zufallsnamen. Kein Name
     kann Pfade verlassen oder etwas ueberschreiben.
  3. Ausgeliefert mit nosniff und einer eigenen, alles verbietenden
     Inhaltsregel.
Das Bild liegt als Datei neben der Datenbank, nicht darin: Bilder in
SQLite blaehen jede Sicherung auf, und die laeuft jede Nacht.

Niemand schreibt einem anderen ins Profil -- auch DogFather nicht. Ein
Satz ueber sich und der eigene Kanalname gehoeren der Person. Wer wen
SEHEN darf, folgt der bekannten Regel: Leitung alle, Scout seine
Creator, Creator sich und seine Betreuer. Fremde Profile sind 404, nicht
403.

ZWEI FUNDE DURCH DIE PRUEFUNG:
- Der TikTok-Link, den die App beim Teilen kopiert, endet auf
  "?lang=de&is_from_webapp=1". Der wurde abgelehnt: "sieht nicht richtig
  aus" -- obwohl es der offizielle Link ist. Jetzt werden Parameter und
  Anker mit abgeschnitten.
- Ein zu grosses Bild ergab "500 Serverfehler" statt einer Ansage. Der
  PayloadTooLargeError lief bis in die allgemeine Fehlerbehandlung
  durch. Jetzt 413 mit dem Satz, wie viel erlaubt ist. Von Hand haette
  das vermutlich nie jemand probiert.

Vor der Schemaaenderung wurde eine geprueft vollstaendige Sicherung
gezogen (VACUUM INTO, Integritaet ok, 6 Personen).

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-01 11:31:34 +02:00
DogFatherGitandClaude Opus 5 0391a91d14 Neun Buehnen statt einer - jede Seite hat ihre eigene Szene
Filipe hat neun Bilder geschickt, damit es VERSCHIEDENE Hintergruende
gibt. Benutzt wurde davon genau eines (das Studio), die uebrigen acht
lagen unbenutzt im Ordner -- lounge.png und skyline.png sogar schon
fertig kopiert. Zu Recht beanstandet.

Jetzt wird aus jeder Szene eine Buehne, breit und schmal, und jede Seite
bekommt die, die zu ihr passt:

  studio      Startseite            der neutrale Ort, alles beginnt hier
  showbuehne  Dashboard, Review     die grosse Buehne, alles im Blick
  garage      Aufgaben, Technik     Werkstatt, hier wird gearbeitet
  skyline     Kalender              Nacht ueber der Stadt, Zeit
  lounge      Calls, Community      Sitzecke, hier wird geredet
  arena       Dateien, Wissen       Archiv hinter dem Portal
  halle       Profil, Personen      die Halle, in der jemand steht
  wald        Start-Check, Scouting der Weg, den man erst sucht
  portal      Content, LIVE         Durchgang, hier entsteht etwas

Die Zuordnung steht in bereiche.js -- derselben Liste, aus der schon
Zeichen und Farbton kommen. Eine Seite traegt damit dreierlei aus einer
einzigen Quelle: Farbe, Zeichen und Buehne. Sie koennen nicht
auseinanderlaufen.

Alle neun bekommen dieselbe Behandlung (abgedunkelt auf 0.42, Vignette
in der Mitte, wo der Text steht, oben ausgeblendet, wo die Kopfleiste
sitzt). Sie sehen verschieden aus und verhalten sich gleich -- eine
Buehne, die je Seite anders hell waere, waere Unruhe statt Vielfalt.
Der schmale Ausschnitt ist je Szene ein anderer, weil ein auf 9:16
gequetschtes Breitbild nur noch Wand zeigt; genommen wird der Bereich,
in dem die Figuren stehen.

18 Dateien, zusammen 580 KB -- pro Seite werden davon zwei geladen
(breit ODER schmal), also 16 bis 48 KB. Die Rohbilder waren 2,4 MB je
Stueck.

Kontrast auf allen sechs geprueften Seiten an echten Bildpunkten
nachgemessen: haelt (schlechtester Wert 4,59:1).

FUND: Die Buehnenpruefung suchte nach "buehne-breit" und fand die neuen
Namen nicht mehr -- sie meldete "die Buehne liegt im Hintergrund: FEHL",
obwohl sie da war.

Die Seitenpruefung sieht jetzt nach, dass jede Seite ihre Szene hat UND
dass das Bild wirklich ankommt: Ein data-buehne ohne passende CSS-Regel
waere still wirkungslos.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-01 10:36:16 +02:00
DogFatherGitandClaude Opus 5 c46fb413ab Jede Seite traegt Zeichen und Farbe ihrer Kachel
Auf der Startseite hat jeder Bereich sein eigenes Zeichen und seinen
eigenen Farbton -- siebzehn unterscheidbare Bereiche statt siebzehn
Kaesten. Bisher endete das an der Kachel: Wer sie anklickte, landete auf
einer Seite, der man nicht mehr ansah, woher sie kam. Dreizehn Seiten,
alle in demselben Blau, alle ohne Zeichen, alle mit derselben duennen
Textzeile als Kopf.

Jetzt wird die Kachel weitergereicht. Der Kopf jeder Seite bekommt
dieselbe Behandlung wie die Kachel: Plakette mit dem Zeichen, der
Bereichsname mit leuchtendem Strich in der Kachelfarbe, ein groesserer
Titel und dasselbe Zeichen noch einmal riesig und fast unsichtbar als
Wasserzeichen dahinter. Aufgaben ist ueberall orange, Kalender ueberall
tuerkis, Personen ueberall rot-gold.

EINE QUELLE STATT ZWEIER LISTEN. Zeichen, Ton, Rolle und Ziel jedes
Bereichs standen nur in start.js. Sie einfach zu kopieren waere der
sichere Weg dazu, dass "Aufgaben" irgendwann auf der Startseite gelb und
auf der Aufgabenseite gruen ist. Beides liegt jetzt in
assets/js/bereiche.js und wird von start.js UND kopf.js benutzt -- wer
eine Kachel aendert, aendert damit automatisch auch den Kopf der Seite.
Sie koennen gar nicht auseinanderlaufen.

Eingesetzt wird die Plakette von kopf.js, nicht in dreizehn HTML-Dateien:
Das vorhandene Markup wird nur umschlossen, nicht ersetzt. Der Kalender
hat einen eigenen Kopf (dort ist der Zeitraum die Ueberschrift) und wird
ausdruecklich mitgenommen -- sonst waere ausgerechnet die aufwendigste
Seite die einzige ohne Zeichen.

Die Seitenpruefung sieht jetzt auf allen dreizehn Seiten nach, dass Ton
UND Zeichen UND Wasserzeichen da sind, und gibt beides aus (ton=9
zeichen=3/3). Eine Seite, die ihre Zuordnung verliert, faellt damit
sofort auf statt erst beim Hinsehen.

Kontrast danach an echten Bildpunkten nachgemessen: haelt auf allen
sechs geprueften Seiten (schlechtester Wert 4,80:1).

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-01 10:22:22 +02:00
DogFatherGitandClaude Opus 5 e65827a6db Begruessung, Schriftzug, hellerer Hintergrund - und "Wissen" fuer Creator
Vier Wuensche auf einmal, alle auf der Startseite und der Kopfleiste.

BEGRUESSUNG. Dort stand "Angemeldet" ueber dem Namen -- eine Zeile, die
nichts hinzufuegt, weil oben rechts ohnehin Name und Rolle stehen. Jetzt
beantwortet der Kopf die drei Fragen, die man beim Reinkommen hat:
WANN (Wochentag, Datum, Kalenderwoche nach ISO 8601, selbst gerechnet),
WER (Plakette mit dem Anfangsbuchstaben in der Farbe der Rolle -- der
einzige runde Koerper der Seite, dadurch sofort als Person lesbar) und
WIE es steht (ein Satz aus denselben Hinweisen, die darunter stehen --
keine zweite Zaehlung). An Tagen mit Charakter kommt ein Wort dazu:
Neue Woche, Endspurt, Wochenende. Der Gruss ist feiner gestuft und der
Name eigenstaendig ausgezeichnet: das Grusswort leise, der Name kraeftig.

SCHRIFTZUG oben links. Vorher alles gleich laut, der Trenner ein
Satzzeichen wie jedes andere. Jetzt hat er Rang: der Name vorn und
kraeftig, der Ort dahinter und leiser, dazwischen eine kleine Raute in
der Hausfarbe. Aufgeteilt zentral in kopf.js statt in sechzehn HTML-
Dateien, und nur die Textknoten -- Verweise bleiben unberuehrt.

HINTERGRUND heller, wie gewuenscht: Der Schleier liegt bei .86/.58/.44
statt .95/.72/.60, dazu zwei sehr weiche Farbschimmer, die dem Bild das
reine Schwarz nehmen. Der Kontrast wurde danach an echten Bildpunkten
nachgemessen und haelt ueberall (schlechtester Wert 4,78:1).

"WISSEN" statt "Team & System" -- aber nur fuer Creator. Von der Gruppe
bleibt fuer ihn genau eine Kachel uebrig; eine Ueberschrift, die Team
und System verspricht und nur die Bibliothek zeigt, verspricht etwas
Falsches.

DREI FUNDE DURCH DIE PRUEFUNGEN:

1. Die Kontrastmessung war kaputt, seit Text neben Text steht. Sie tastete
   stur 4 px rechts vom Text ab -- und traf dort den NACHBARTEXT statt den
   Untergrund (1,10:1 gemeldet, ohne dass etwas schlecht lesbar war). Jetzt
   werden sechs Stellen rings um den Text angeboten und jede zuerst
   gefragt, ob dort wirklich Untergrund liegt. Strenger, nicht lockerer.
   Texte ohne freie Stelle werden GEZAEHLT und ausgegeben, nicht still
   uebersprungen.
2. bereich.html hatte als einzige Seite kein span.marke__text. Damit
   griffen dort weder die Ueberlauf-Kuerzung noch der neue Rang. Stand seit
   Monaten so, aufgefallen erst, als die Seitenpruefung die Marke auf allen
   dreizehn Seiten nachgesehen hat.
3. Die Datumspruefung haette im Maerz stillschweigend versagt: \w kennt
   ohne Unicode-Schalter kein "ae". Ein Fehler, der sieben Monate wartet.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-01 09:55:25 +02:00
DogFatherGitandClaude Opus 5 e74254263f Buehne aus den echten Marken-Bildern, Kopfleiste und Begruessung neu
Filipe hatte recht, und zwar zweifach: Der Husky war der FALSCHE (ein
fremder Neon-Husky aus dem alten Bilderordner statt DogFather), und zwei
in die Ecken geklebte Bilder ergeben noch kein Bild.

DIE BUEHNE, zweiter Anlauf. Aus den zehn geschickten Bildern das Studio
gewaehlt, in dem HasiDog und DogFather stehen -- nicht aus Geschmack,
sondern wegen der ANORDNUNG: Die beiden stehen weit aussen, die Mitte ist
dunkel. Genau dort steht der Inhalt. Bei den Bildern mit den Figuren in
der Mitte waeren sie hinter dem Text gelandet.

Ueber die ganze Flaeche, fest an der Scheibe, 138 % breit: Bei 100 %
staenden die beiden bei 20 % und 78 % der Breite -- mitten unter der
Textspalte. Vergroessert man das Bild ueber die Scheibe hinaus, wandern
sie nach aussen (rund 9 % und 88 %) und der leere Hallenboden liegt dort,
wo gelesen wird. Ein Bild groesser zu machen, damit WENIGER davon im Weg
ist, klingt verkehrt und ist genau richtig.

Fuer schmale Schirme ein eigener Hochkant-Ausschnitt derselben Szene --
ein auf 9:16 gequetschtes Breitbild zeigt nur noch Wand.
1,9 MB PNG -> 28 KB WebP.

DIE VIER STELLEN aus den Bildschirmfotos:

* Kopfleiste: der DogFather-Kopf davor. Als MASKE aus dem Logo gerechnet
  (Dunkelheit wird Deckkraft), nicht als Bild -- so laesst er sich im
  Stil einfaerben; ein fertig eingefaerbtes Bild muesste man fuer jede
  Farbe neu bauen. 114 KB -> 3 KB.

* "Dogfather · DogFather" war der peinlichste Punkt: Name und Rolle lasen
  sich gleich, es sah nach einem Fehler aus. Jetzt drei unterscheidbare
  Dinge -- Zeichen mit dem Anfangsbuchstaben, Name, Rolle als Marke in
  ihrer Farbe. Gebaut in kopf.js, EINMAL statt vierzehnmal: Jede
  Seitendatei setzte diese Zeile bisher selbst zusammen.

* Begruessung: leuchtender Strich, groesserer Gruss, auslaufende
  Trennlinie. Dieselben Striche vor "WAS IST DRAN" und "DEINE AUFGABEN" --
  so gehoert sichtbar zusammen, was zusammengehoert.

ZWEI EIGENE FEHLER, die die Pruefungen gefunden haben:

1. Ich hatte Verlaeufe IM TEXT gebaut (background-clip mit durchsichtiger
   Schrift). Sah gut aus, und der Kontrasttest meldete 1,05:1 -- zu Recht.
   Durchsichtige Schrift haengt an einer einzigen Technik; faellt sie aus
   (Kontrastmodus, Druck, aeltere Browser), ist der Text UNSICHTBAR statt
   nur anders gefaerbt. Das ist kein Schoenheitsfehler, das ist ein
   Ausfall. Jetzt feste Farbe mit einem Hauch Leuchten.

2. Auf dem Handy stand der Abmelden-Knopf 9 px aus dem Bild. Die Suche
   nach der Ursache ging zuerst in die Irre -- der Test nannte das
   Wasserzeichen, das aber von seiner Kachel sauber abgeschnitten wird
   und nur seine Masse meldet. Gemessen war es die Marke: 209 px + 139 px
   rechte Gruppe passten nicht in 390 px. Auf dem Handy bleibt jetzt nur
   der Kopf stehen; der Markenzug steht zwei Zeilen tiefer ohnehin als
   Ueberschrift. Fuer Vorleseprogramme bleibt er im Dokument.

Und einmal habe ich mir beim Ersetzen eines CSS-Blocks das halbe
Stylesheet geloescht (die Kachel-Regeln lagen zwischen den beiden
Suchmarken). Aufgefallen sofort am Bildschirmfoto, zurueckgeholt aus Git,
danach zeilengenau ersetzt.

118 Pruefungen, alle gruen. Der Kontrast wird weiterhin an echten
Bildpunkten gemessen, jetzt an bis zu 35 Stellen je Seite.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-01 05:45:59 +02:00
DogFatherGitandClaude Opus 5 1894395d8f Workspace: lange Protokoll-Listen aufklappbar, zugeklappt vier Zeilen
Die "Letzten Ereignisse" im Personen-Bereich fuellten mit 25 Zeilen die
halbe Seite, obwohl sie Nachschlagewerk sind und kein Startbild. Jetzt
stehen nur die vier neuesten da, der Rest kommt auf Knopfdruck.

Der Knopf sagt, was er TUT ("Alle 25 zeigen" / "Nur die letzten 4") und
nennt die Zahl, damit man weiss, was dahintersteckt. Bei hoechstens vier
Eintraegen bleibt er ganz weg -- ein Knopf, der nichts verbirgt, verwirrt
nur. Der Pfeil dreht sich, aria-expanded stimmt.

Gemeinsamer Helfer in kopf.js statt zweimal derselbe Block: Dieselbe
Liste gab es auf der Automationen-Seite ("Zuletzt automatisch passiert"),
die verhaelt sich jetzt genauso. Zugeklappt wird per CSS
([data-klapp="zu"]) statt durch Entfernen von Zeilen -- das Aufklappen
braucht so weder Neuaufbau noch zweite Abfrage.

Der Zuhoerer wird nur einmal gesetzt (die Listen werden bei jeder
Aktualisierung neu aufgebaut), und die Anzahl wird bei jedem Umschalten
frisch gelesen statt in der Fassung des ersten Durchlaufs festzuhaengen.

Geprueft: beide Seiten, Computer und Handy, zweimaliges Hin- und
Herklappen, Gegenprobe mit drei Eintraegen -- server/pruef-protokoll-klappe.mjs

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-08-31 13:27:07 +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 d3212a3f60 Workspace: Zurueck-Knopf hochwertiger, auf der Startseite entfernt
Zwei Rueckmeldungen umgesetzt.

1. Auf der Startseite gibt es den Knopf jetzt gar nicht mehr im
   Dokument. Vorher erschien er dort, sobald man von einer anderen
   Workspace-Seite kam -- aber die Startseite IST die oberste Ebene, ein
   "davor" gibt es nicht.

2. Aussehen: statt des Textzeichens "<-" jetzt ein echtes SVG-Winkel-
   symbol, Pillenform, und ein Verlaufsrahmen.

   Wichtig dabei: Die Fuellung ist DECKEND. Beim ersten Versuch war sie
   halbtransparent, dadurch schien der Rahmenverlauf durch die ganze
   Flaeche und der Knopf sah aus wie eine Hauptaktion -- genau das soll
   er nicht. Jetzt bleibt vom Verlauf nur der 1px schmale Rand sichtbar.

   Ruhezustand: dunkle Pille, feine Stahlkante, gedaempfter Text.
   Ueberfahren: Cyan-Violett-Rand, heller Text, weicher Schein, und der
   Pfeil rueckt zwei Pixel nach links -- die Bewegung sagt die Richtung
   ohne zusaetzlichen Text. Bei prefers-reduced-motion faellt sie weg.

Geprueft: Start -> kein Knopf; Aufgaben -> "Zurueck", fuehrt zurueck;
Personen direkt aufgerufen -> "Uebersicht". Keine Konsolenfehler.

Nur statische Dateien, kein Neustart noetig.
2026-08-28 00:40:19 +02:00
DogFatherGit 75d05d05d2 Workspace: Zurueck-Knopf auf allen Seiten
Wunsch: "ich will auch immer bei jeder seite auch immer einen knopf
haben damit ich zurueck gehen kann auf die seite vorher."

Neues gemeinsames Modul assets/js/kopf.js. Blindes history.back() reicht
dafuer nicht: Wer die Adresse direkt eingibt oder gerade von der
Anmeldung kommt, landet damit ausserhalb des Workspace oder wieder im
Anmeldeformular. Deshalb wird zuerst geprueft, woher der Aufruf kam:

  * vorherige Seite im Workspace  -> "Zurueck", history.back()
    (fuehrt wirklich dorthin zurueck, samt Bildlaufposition)
  * kein Verlauf, aber Unterseite -> "Uebersicht", geht zur Startseite
  * kein Verlauf auf der Startseite -> Knopf bleibt verborgen
    Ein Knopf, der nichts tut, ist schlimmer als keiner.

Der Knopf sitzt links in der Kopfleiste, an derselben Stelle wie im
Browser.

Nebenbei aufgeraeumt: Das Abmelden stand bisher in jeder der fuenf
Seitendateien noch einmal -- fuenfmal derselbe Block, fuenfmal eine
Stelle zum Vergessen. Liegt jetzt ebenfalls in kopf.js.

Geprueft: Start nach Login -> verborgen; Aufgaben von Start ->
"Zurueck", fuehrt zurueck; Kalender direkt aufgerufen -> "Uebersicht".
Keine Konsolenfehler, Abmelden funktioniert weiterhin.

Nur statische Dateien, kein Neustart noetig.
2026-08-28 00:35:26 +02:00