fc4616bb056ef7dee382704f3c6ed28faf8f7f1b
100
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
fc4616bb05 |
Immer nur eine Tafel offen -- und eine zugeklappte belegt nichts mehr
Filipe: "wenn ich eine aufklicke soll auch immer nur die aufgehen und nicht alle 3." DAS IST MEHR ALS GESCHMACK. Seit die drei Tafeln nebeneinander stehen und jede ihren eigenen Lauf hat, teilen sie sich die Bildschirmhoehe: Drei offene Tafeln heissen drei kurze Ausschnitte -- eine offene heisst eine, in der man wirklich arbeiten kann. Die anderen werden ZUGEKLAPPT, nicht versteckt: Ihre Koepfe bleiben mit Namen und Anzahl stehen. Man sieht weiterhin, was es sonst gibt, und kommt mit einem Klick hin. Der gemerkte Stand wird mitgeschrieben -- sonst waere die Seite beim naechsten Aufruf in einem Zustand, den niemand hergestellt hat. UND EIN FEHLER VON MIR, DEN SEIN BILD GEZEIGT HAT Die zugeklappten Tafeln standen als LEERE KAESTEN ueber die volle Hoehe da. `align-items: stretch` am Brett gilt eben auch fuer die, die nichts zeigt. Drei gleich hohe Tafeln sind richtig, solange sie etwas enthalten -- eine geschlossene enthaelt nichts und soll dann auch nichts belegen. Vier Pruefungen gelaufen, alle gruen. NOCH OFFEN, und bewusst nicht angefangen: Erinnerungswecker, Terminarten (BigMatch/Turniere/Special-Live) und der Umbau der Begruessungskachel nach VanVans Werktisch. Jede davon ist ein eigener Bau -- angefangen und liegengelassen waeren sie schlimmer als gar nicht begonnen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
c5cdf686e3 |
Der Husky jetzt auch auf der Zugangsseite -- und fuenf Zeichen in fuenf Farben
Filipe: "bei dogfather ist immer noch die krone und da soll ja ein husky sein. und die symbole sollen doch alle viel krasser, geiler und spezieller sein." Er hat recht, und der Grund ist eine Haelfte, die ich uebersehen habe: Die Rollenzeichen gibt es ZWEIMAL im Haus -- als <use>-Bausteine in personen.html (dort war der Husky schon) und noch einmal ausgeschrieben in index.html, der Anmeldeseite. Getauscht hatte ich nur die erste. DER HUSKY, zweite Ausfertigung. Bei 21 Pixeln entscheidet die Silhouette, nicht das Detail: spitze aufrechte Ohren, breiter Kopf, der nach unten schmal zulaeuft, Gesichtsmaske. Mehr passt nicht hinein -- und mehr braucht es nicht. UND ALLE FUENF ZEICHEN TRAGEN JETZT IHRE EIGENE FARBE Sie waren feine Konturen in einer Farbe, und zwar in DERSELBEN fuer alle fuenf. Jetzt: eine gefuellte Flaeche in der Farbe ihrer Rolle, die Zeichnung hell darauf, ein leichter Schatten darunter. Chili rot, Husky gold, Stern violett, Schild gruen, Person blau -- dieselben Farben wie auf der Personenseite; wer die eine Seite kennt, erkennt die andere wieder. Die Farbe steht am ROLLENKNOPF (`--rf`), nicht im Zeichen. Die Zeichen wissen damit nichts von Rollen, und eine Farbaenderung passiert an einer Stelle statt an fuenf. Gewaehlt heisst: mehr Licht auf demselben Gegenstand -- kein anderer Gegenstand. Zehn Pruefungen gelaufen, alle gruen, darunter Kontrast und Handy fuer die Anmeldeseite. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
af4a00dce2 |
Die Kopfleiste war nie klebend -- und das Call-Brett hatte eine leere Haelfte
DIE LEISTE BLEIBT JETZT OBEN (screen 3)
Filipe: "diese leiste soll immer da stehen bleiben, egal ob man die
seite runterscrollt oder nicht, auf allen seiten."
In start.css steht seit jeher `.kopfleiste { position: sticky; top: 0 }`.
Zwanzig Zeilen darueber steht aber
body.start > .kopfleiste { position: relative; z-index: 1; }
und das ist (0,2,1) gegen (0,1,0) -- die staerkere Regel gewinnt,
unabhaengig von der Reihenfolge. Gemessen im Browser: `position:
relative`, und bei 600 px Scrollen wanderte die Leiste 600 px aus dem
Bild. Sie hat also nie geklebt, obwohl es im Code so dasteht.
Das ist heute die VIERTE Spielart derselben Falle: `:where()` zu
schwach, `body.start .willkommen` zu stark, die Kachel-Verschachtelung
zu stark -- und hier eine Regel, die etwas ganz anderes wollte (den
Stapelwert ueber der Buehne) und dabei die Positionierung mitgenommen
hat. Merksatz: Wer `position` setzt, nur um `z-index` zu bekommen,
greift jedes Mal daneben.
Nachgemessen: 700 px gescrollt, Leiste steht bei 0.
DAS CALL-BRETT: DREI TAFELN STATT ZWEIER SPALTEN (screen 2)
Filipe: "das bewegt sich immer noch mit, das ist so scheissen."
DAS PROBLEM WAR DIE AUFTEILUNG, nicht die Gestaltung. Zwei Spalten, und
"Steht an" hatte siebenundzwanzig Karten: Die rechte Spalte lief ueber
mehrere Bildschirmhoehen, die linke war nach zwei Koepfen zu Ende. Wer
scrollt, sieht dann eine leere halbe Seite mit einer Ueberschrift, die
scheinbar mitwandert -- sie steht bloss still, waehrend daneben alles
laeuft.
Jetzt bekommt jede Tafel DIESELBE Hoehe und einen EIGENEN Lauf. Alle
drei Gruppen sind damit immer gleichzeitig zu sehen, egal wie viel in
einer steckt, und die Seite selbst scrollt kaum noch. Das ist die
Bauart jedes Aufgabenbretts, und sie ist es aus genau diesem Grund.
Die Hoehe haengt am Fenster (`min(62vh, 620px)`) statt an einer festen
Zahl. Unter 900 px stehen die Tafeln untereinander und laufen wieder
frei -- auf dem Handy ist ein Kaestchen mit eigenem Balken eine Falle,
keine Hilfe. Der Balken ist selbst gestaltet; der Systembalken reisst
ein weisses Band in eine dunkle Flaeche.
NOCH OFFEN aus derselben Nachricht: der Erinnerungswecker fuer Termine
(ein-/ausschaltbar je Eintrag, mehrere Zeitpunkte, von jedem selbst
einstellbar) -- dazu will Filipe ausdruecklich Recherche, und der baut
sich nicht nebenbei.
Zehn Pruefungen gelaufen, alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
28a260fab2 |
Ein Husky statt der Krone -- und Spicy sieht DogFather, aber nur ihn
DER HUSKY (screen 1) Filipe: "die krone bei dogfather durch einen husky ersetzen, wie mein logo." Bei 24 Pixeln entscheidet die SILHOUETTE, nicht das Detail. Ein Husky erkennt man an dreierlei, und mehr passt auch nicht hinein: den spitzen aufrechten Ohren, dem breiten Kopf, der nach unten schmal zulaeuft, und der Gesichtsmaske. Fell oder Zunge waeren bei dieser Groesse Matsch -- genau deshalb hat die Krone davor funktioniert. UND ALLE ROLLENSYMBOLE SIND JETZT KOERPER Sie waren reine Konturen in einer Farbe -- daneben auf derselben Seite die Kachelzeichen mit drei Lichtern. Jetzt tragen sie eine gefuellte Flaeche in ihrer Rollenfarbe, die Zeichnung hell darauf, und Augen und Nase eigens gesetzt. Beim gewaehlten Knopf leuchtet die Flaeche staerker -- der einzige Unterschied, den es braucht: mehr Licht auf demselben Gegenstand. SPICY SIEHT DOGFATHER, ABER NICHT DEN ZWEITEN ADMIN (screen 2) Filipe: "die rolle spicy soll auch die rolle dogfather sehen, aber nur dogfather und nicht vanvan." NACHGEMESSEN AM ECHTEN SYSTEM, nicht angenommen: In der Datenbank tragen BEIDE die Rolle `admin` -- id 1 "Dogfather", id 4 "VanVan". Es gibt kein Feld, das den einen vom anderen unterscheidet. Der Unterschied, den es wirklich gibt, ist das Alter: DogFather ist der erste Zugang des Hauses. Deshalb zaehlt die kleinste Nummer unter den Admins -- eine Eigenschaft, die feststeht und nicht am Namen haengt. Die Schwachstelle steht im Code, damit sie niemand sucht: Wuerde Zugang 1 je geloescht, rueckte der naechste nach; dann gehoert ein ausdrueckliches Merkmal in die Tabelle. Die Entscheidung faellt im SERVER, nicht in der Oberflaeche. Dort stand vorher ein Filter, der den ganzen Abschnitt wegnahm -- zwei Regeln fuer dieselbe Frage laufen auseinander, und eine ausgeblendete Zeile hat noch nie etwas geschuetzt. MEINE EIGENEN PRUEFUNGEN VON HEUTE MITTAG FIELEN DABEI Richtig so: Sie pruefen "DogFather steht NICHT darin", und das gilt nicht mehr. Umgeschrieben -- und dabei kam der eigentliche Prueffall dazu: ein ZWEITER Admin-Zugang im Testbestand. Ohne ihn waere die Regel gar nicht pruefbar, bei einem einzigen Admin ist jede Antwort richtig. pruef-spicy von 57 auf 60. NOCH OFFEN aus derselben Nachricht: die Terminarten (BigMatch, Turniere, Special-Live) und der Umbau der Begruessungskachel nach dem Vorbild von VanVans Werktisch. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
09a0c17237 |
Bearbeiten geht jetzt -- und zwei Bedienelemente, die keine Kacheln sind
DER SERVER LIESS DAS AENDERN DIE GANZE ZEIT ZU. IM TAGESFENSTER FEHLTE DER KNOPF. Filipe: "ich hab die gemacht und kann sie nicht bearbeiten." Dort standen nur "erledigt" und "loeschen". Ein Recht ohne Knopf ist kein Recht. Jetzt oeffnet "bearbeiten" dasselbe Formular, gefuellt -- ein Formular, zwei Wege (POST oder PATCH), statt eines zweiten, das genauso aussieht und beim naechsten Feld auseinanderlaeuft. Die Wiederholung bleibt beim Bearbeiten aussen vor: Sie ist eine REGEL und wird unter "Laeuft von allein" geaendert, nicht an einer ihrer Auspraegungen. Wer das zulaesst, bekommt einen Termin, der aus der Reihe faellt, ohne dass jemand weiss warum. UND DIE REGEL DAZU IM SERVER Filipe: "nur diese person selber." Bis hierher durfte JEDER aendern, der den Termin ueberhaupt sah -- bei einem Termin mit mehreren Beteiligten also alle. Jetzt: die Leitung und wer ihn eingetragen hat. Dieselbe Regel wie beim Loeschen, die dort schon richtig stand. AUSNAHME "erledigt": Ein Haken, dass ein Gespraech stattgefunden hat, ist keine Aenderung am Termin, sondern eine Rueckmeldung dazu -- sonst muesste jeder Beteiligte den Anleger bitten, den eigenen Call abzuhaken. Gemessen in pruef-teilnehmer, mit allen drei Faellen. Beim Bauen der Pruefung ist mir ein Aufbaufehler unterlaufen (Bea statt Pat als zweite Teilnehmerin -- Luna darf Bea gar nicht einladen), und die Pruefung hat ihn korrekt als 404 statt 403 gemeldet. Der Fehler lag im Aufbau, nicht im Code. DER ANSICHTS-UMSCHALTER WAR VIER KACHELN `.k-ansicht` stand in der Modulliste. Jeder der vier Knoepfe bekam damit die volle Behandlung einer Kachel: Fase, Kantenlicht, Eckwinkel, Raster. Auf 90 mal 32 Pixeln ist das kein Modul, sondern Gedraenge -- vier Fasen und sechzehn Eckwinkel nebeneinander. Die Modulform ist fuer FLAECHEN gedacht, die etwas enthalten. Ein Umschalter enthaelt nichts, er waehlt aus, und die richtige Form dafuer ist die SCHIENE: eine vertiefte Bahn, in der ein erhabenes Stueck aus gebuerstetem Metall sitzt. Man sieht auf einen Blick, dass die vier zusammengehoeren und genau eines gewaehlt ist. DIE GRUPPENKOEPFE AUF DER CALLS-SEITE Vorher eine Textzeile mit Pfeil, und die Karten darunter begannen ohne Uebergang -- aufgeklappt sah man nicht, wo eine Gruppe aufhoert. Jetzt ist der Kopf ein Schalter mit Zustand, die Zahl ein gefasstes Schild, und die Karten stehen aufgeklappt in einer eigenen vertieften Bahn mit Farbschiene links. 14 Pruefungen gelaufen, alle gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
dd1f561f3b |
Vier Meldungen -- und dahinter zweimal derselbe alte Fehler
DIE SYMBOLE IN DER TAGESKACHEL WAREN DIESELBEN -- OHNE IHRE GESTALTUNG
Sie kommen vom selben Bauer wie alle anderen, bekamen aber nie dessen
Aussehen: Alle Lagenregeln waren auf `.kachel__svg` eingegrenzt, und
dieses Zeichen heisst `.dran__svg`. Uebrig blieb eine flache Kontur --
daneben, auf derselben Seite, dieselben Zeichen mit drei Lichtern,
Tiefe und Randlicht. Die Regeln gelten jetzt fuer beide Traeger, und
das Feld darum ist dasselbe gefasste Schild wie auf den Kacheln.
"UNDEFINED" IM CHAT -- DERSELBE FEHLER WIE HEUTE FRUEH, NUR ALS OBJEKT
Ueber Cigdems Namen stand woertlich "UNDEFINED". Die Rollennamen
standen als Objekt in FUENF Skripten (chat.js zweimal, dateien.js,
kalender.js zweimal), in keinem davon 'spicy'.
Heute Frueh war es dieselbe Sache als Menge (`new Set([...])`), und
seitdem sucht `pruef-css-klassen.mjs` danach. Ein Muster, das nur eine
Schreibweise kennt, findet auch nur eine -- die Pruefung sucht jetzt
auch nach Rollen-OBJEKTEN, mit Gegenprobe. Die Namen stehen an EINER
Stelle in bereiche.js.
DOGFATHER UND SPICY MEDIA SIND IM CHAT FUER JEDEN ERREICHBAR
DogFather kam bisher als Nebeneffekt ueber die Betreuungskette mit
hinein, Spicy Media gar nicht -- die Rolle steht in keiner Kette, sie
steht daneben. Beide werden jetzt ausdruecklich hinzugefuegt: Eine
Zustaendigkeit, die nur zufaellig aus einer anderen Regel herausfaellt,
faellt beim naechsten Umbau genauso zufaellig wieder heraus.
Gemessen aus der Sicht eines Creators -- wer bei ihm ankommt, kommt
ueberall an.
DIE PERSONENLISTE: SPICY MEDIA SIEHT ALLES AUSSER DOGFATHER
Der Abschnitt "Spicy Media" fehlte in der Liste komplett -- die Rolle
gibt es seit heute Frueh, die Personenseite kannte sie nicht. Und Spicy
Media selbst sah dort bisher nur das Anlegen-Formular; sie bekommt
jetzt die Liste, ohne DogFathers Zeile, und weiterhin ohne Codes,
Sperren, Loeschen und Protokoll. Ueberblick ist nicht Verwaltung.
ZWEI FOLGEFEHLER, BEIDE VON DEN PRUEFUNGEN GEFUNDEN
* `next("route")` TUT DAS GEGENTEIL VON DEM, WONACH ES KLINGT. Mein
erster Versuch war eine Ausnahme-Route VOR der Schranke, die mit
`next("route")` weiterreicht -- das ueberspringt aber die restlichen
Handler DIESER Route und geht zur naechsten Schicht, also genau zur
Schranke. Spicy bekam weiter 404, die Oberflaeche verstand das als
"nicht erlaubt" und sprang zur Startseite. Gemessen: Auf
personen.html standen die Kategorien der STARTSEITE.
* DAS PROTOKOLL WARF SIE VON DER SEITE. Es bleibt bei DogFather und
antwortet ihr mit 404 -- und `hole()` versteht ein 404 unter
`/verwaltung/` als "nicht erlaubt". Die Seite baute sich auf und
sprang im naechsten Atemzug weg. Eine Abfrage, von der man weiss,
dass sie 404 gibt, stellt man nicht.
UND EINE MEINER EIGENEN NEUEN PRUEFUNGEN WAR WERTLOS
"bei ihr fehlt der Abschnitt DogFather" -- gruen, mit dem Zusatz
"(keine Abschnitte)". Sie war gruen, weil die Liste bei ihr GAR NICHT
DA war. Genau der Haken, der nichts beweist. Er steht jetzt neben einem
Ergebnis, das etwas enthaelt: "Spicy Media | Manager | ...".
18 Pruefungen gelaufen, alle gruen. pruef-spicy von 49 auf 57.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
0ea8b27aca |
Aus drei Strichen werden drei Ringe aus Material
Filipe: "ich will dass der rand mit den sekunden minuten und stunden
viel krasser und geiler ist ... ultra modern, ultra speziell, ultra
profissionell, ultra phaenomenal."
EIN STRICH IST EINE LINIE. EIN RING IST EIN KOERPER.
Und ein Koerper hat drei Merkmale, die man zeichnen MUSS, sonst bleibt
es ein Strich. Jeder der drei Ringe besteht deshalb jetzt aus drei
Lagen:
SCHATTEN Er liegt ueber dem Zifferblatt, also wirft er einen.
Dieselbe Bahn, schwarz, ein halbes Rastermass nach UNTEN.
KOERPER Der Bogen selbst in seiner Farbe.
OBERKANTE Duenner, hell, ein Drittel nach OBEN. Weil er versetzt
ist, schaut er oben hervor und verschwindet unten -- genau
das tut eine gewoelbte Kante bei Licht von oben.
Kein Weichzeichner, nirgends: Die Tiefe kommt aus dem Versatz, nicht
aus Unschaerfe.
DIE BAHNEN SIND GEFRAESTE RILLEN
Ein Zeiger laeuft bei einem guten Instrument IN einer Vertiefung. Eine
Rille erkennt man an zweierlei: dunkler als ihre Umgebung, und an ihrer
unteren Wand steht eine helle Kante. Beides steht jetzt da, und die
Breite folgt dem Ring, der darin laeuft -- eine Rille, die schmaler ist
als ihr Zeiger, ist keine.
DREI KOEPFE STATT EINEM
Minute und Stunde bekommen dieselbe polierte Kappe wie die Sekunde, auf
ihren eigenen Bahnen und in ihrer eigenen Farbe. Erst dadurch liest man
die drei Ringe als drei ZEIGER und nicht als drei Fortschrittsbalken.
Sie laufen mit ihrem Ring: die Minute nimmt die Sekunden anteilig mit,
die Stunde die Minuten -- sonst staende der Kopf neben dem Ende seines
Bogens.
ALLE LAGEN WERDEN GEMEINSAM GESETZT. Sie tragen `data-ring`; einzeln
gepflegte Verweise waeren drei Stellen, an denen man eine vergessen
kann, und ein Schatten, der stehen bleibt, sieht sofort kaputt aus.
UND EIN FUND, DEN DIE PRUEFUNG SOFORT GEMELDET HAT
Die neue helle Oberkante des Stundenrings laeuft hinter den Ziffern
durch: schlechtester Kontrast 2,98:1 -- knapp unter der Grenze, und
ausgerechnet bei der Uhrzeit selbst. Die Antwort war nicht "Kante
weg", sondern der fehlende Untergrund: Auf einer echten Uhr steht eine
Anzeige, die ueber Zeigern liegt, auf einer eigenen vertieften INSEL im
Zifferblatt. Jetzt 5,42:1, und dabei 29 statt 14 gemessene Stellen.
Merksatz: Wenn eine neue Schicht einen Text unlesbar macht, ist die
Antwort selten "Schicht weg" -- meistens fehlt dem Text sein Grund.
Zehn Pruefungen gelaufen, alle gruen. Rechner und Handy angesehen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
9c7952b5a3 |
Drei Lichter statt einem: die Symbole bekommen Koerper
Filipe: "die symbole und der text dadrin sollen groesser und noch
spezieller sein, und die symbole sollen auch 2-3 farben haben ... sollen
mehr leben haben, auch viel realistischere effekte."
NICHT DREI AUSGEDACHTE FARBEN, SONDERN DIE DREI EINES ECHTEN AUFBAUS
So wird jedes Produktfoto ausgeleuchtet, und aus demselben Grund sieht
es plastisch aus:
1 FUEHRUNGSLICHT, kalt, von oben links. Ein Spitzlicht ist nie
reinweiss -- es traegt die Farbe der Lampe, und die ist kuehl.
2 EIGENFARBE des Gegenstands: der Ton seiner Kachel.
3 STREULICHT, warm, von unten. Licht, das vom Untergrund
zurueckkommt, ist waermer als das Hauptlicht. Genau dieser warme
Saum ist der Grund, warum ein Gegenstand im Bild STEHT statt zu
schweben.
Dazu die aelteste Regel der Malerei: warmes Licht, KUEHLE Schatten. Die
Seitenwaende der Zeichen kippen jetzt ins Blaue statt nur dunkler zu
werden. Und ein RANDLICHT auf der Lichtseite -- der schmale Streifen,
in dem das Fuehrungslicht die Kante streift. Ein Gegenstand ohne diese
Kante sieht immer ein wenig flach aus, und man kann meist nicht sagen,
warum.
ZWEI FEHLER DABEI, BEIDE ERST BEI FUENFFACHER VERGROESSERUNG SICHTBAR
* DAS WARME LICHT LAG UNTER DER FORM. Die Verlaeufe spannten ueber das
ganze 24er-Raster (y 2 bis 22); die Sprechblase des Chats reicht
aber nur von 5,5 bis 20,5. Der warme Stopp bei y 22 war damit
ausserhalb -- von den drei Lichtern kam genau eines an.
`objectBoundingBox` spannt den Verlauf jetzt ueber JEDES Teil
einzeln: Der Kalenderkorpus bekommt sein volles Licht, seine Fuesse
ebenfalls. So verhaelt sich ein echter Aufbau -- jedes Teil liegt im
selben Licht, nicht im selben Ausschnitt.
* DAS RANDLICHT WAR SCHMALER ALS DIE KONTUR DARUEBER und lag deshalb
vollstaendig darunter: gebaut, gezeichnet, unsichtbar. Jetzt 2,7
gegen 1,9 -- so schaut es oben links hervor.
GROESSER, WIE GEWUENSCHT
Plakette 58 -> 64 px (grosse Kachel 62 -> 70), Zeichen 29 -> 35 px
(gross 32 -> 39), Wasserzeichen 132 -> 156 px (gross 168 -> 196),
Name 1,06 -> 1,15 rem (gross 1,24 -> 1,38), Unterzeile 0,78 -> 0,845.
Auf dem Dashboard entsprechend.
UND DAS SCHILD WIRFT LICHT AUF SEINE KACHEL
Ein beleuchteter Gegenstand faerbt seine Umgebung. Ohne diesen Abfall
sieht selbst ein gut gebautes Schild aufgeklebt aus. Weit gestreut und
weit unter der Blendschwelle: Man soll ihn nicht sehen, man soll ihn
vermissen, wenn er fehlt.
Zehn Pruefungen gelaufen, alle gruen -- darunter Handy und Breiten,
weil groesserer Text der schnellste Weg zu einem Ueberlauf ist.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
5b6f9cef98 |
Rot, Schwarz, Babyblau -- und ein Glas, das entspiegelt ist
Filipe: "der rand soll auch eine mischung von rot schwarz und babyblau
haben und die kachel selbst soll einen uebertrieben krank geilen
hintergrund haben ... die einzige kachel, die komplett aus dem rudel
faellt. die uhr soll auch VIEL VIEL VIEL KRASSER sein. informier dich,
hol die besten skills von den besten skills."
NACHGELESEN STATT GERATEN -- UND DAS HAT DIE UHR VERAENDERT
Zur Frage, woran man ein hochwertiges Uhrenglas erkennt: Eine
Entspiegelung wird im Vakuum aufgedampft und senkt die Spiegelung auf
unter ein Prozent -- das Zifferblatt wirkt dadurch SCHAERFER, nicht
milchiger. Und ihr Erkennungszeichen ist kein weisser Schleier, sondern
ein TOPASBLAUER SCHIMMER, der je nach Lichteinfall ueber das Glas
laeuft.
Hier lag genau das Gegenteil: ein breiter weisser Verlauf ueber ein
Fuenftel der Scheibe -- also die Spiegelung eines UNBESCHICHTETEN
Glases, das Merkmal des billigeren Materials. Jetzt: ein schmaler,
harter Reflexbogen an der Woelbung, der topasblaue Schimmer diagonal
darueber, und die haarfeine Schnittkante oben.
DAZU ZWEI WEITERE MITTEL AUS DEM UHRENBAU
* AUFGESETZTE INDIZES bei 3, 6 und 9. Auf einer guten Luenette sind
die Viertelstunden keine Striche wie die anderen: Sie sind eigene
Marken, breiter und HELL statt graviert -- weil sie aufgesetzt sind
und deshalb Licht fangen statt Schatten zu halten. Die 12 bleibt
die rote.
* DAS SEKUNDENFELD IST EIN EINGELASSENES FENSTER. Eine Zusatzanzeige
sitzt in einer Aussparung des Blatts; man erkennt das daran, dass
der Schatten oben hineinfaellt und unten eine helle Kante steht.
Genau diese beiden Schatten stehen jetzt darin.
DIE FASSUNG: DREI FARBEN STATT STAHL MIT TUPFERN
Links die rote Haelfte, rechts die babyblaue, dazwischen und an den
Raendern Schwarz -- und ueberall dort, wo Metall das Licht bricht, die
hellen Spitzlichter. Es sind dieselben zwei Farben wie im Motiv und auf
der Anmeldekarte.
DER HINTERGRUND: SECHS SCHICHTEN
Lichtkante, KOHLEFASERGEWEBE (zwei gegenlaeufige Schraegen, die sich
kreuzen -- bei drei Prozent sieht man kein Muster, man sieht ein
MATERIAL), das Messraster, ein HORIZONT im unteren Drittel mit Schein
darueber, die beiden Farbbecken kraeftiger als bisher, und ein fast
schwarzer Grund mit Blauschimmer oben.
Alles weit unter der Blendschwelle -- die Hausregel gilt auch fuer
"krank geil": Es darf beeindrucken, es darf nicht blenden.
Sieben Pruefungen gelaufen, alle gruen. Rechner und Handy angesehen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6e09c55002 |
Die Symbole hatten nie ihre Farbe -- ein Jahr lang, auf jeder Seite
Filipe: "ich will dass die symbole viel krasser, realistischer, farbiger und spezieller sind ... ich meine wirklich alle alle alle symbole auf der ganzen website." DER GRUND WAR KEIN GESCHMACK, SONDERN EIN BAUFEHLER Die Verlaeufe der Zeichen arbeiten mit `currentColor`, damit jedes Zeichen die Farbe SEINER Kachel annimmt. Sie lagen aber alle zusammen in EINEM versteckten SVG am Ende der Seite, und jedes Zeichen verwies nur darauf. `currentColor` in einem Verlaufsstopp wird an dem Element aufgeloest, das den STOPP enthaelt -- also dort, im versteckten SVG, wo die Textfarbe das helle Grau der Seite ist. Jedes Zeichen im ganzen Haus war deshalb grau. Der Farbton kam sauber an der Kachel an (gemessen: rgb(62,149,231) auf der Dashboard-Kachel) und wurde nie benutzt. GEMESSEN, NICHT VERMUTET: Faerbt man das versteckte SVG rot, werden die Zeichen rot (hellster Bildpunkt 43/49/61 -> 46/29/40). Faerbt man das ZEICHEN rot, passiert nichts. Damit war die Frage entschieden. Das Tueckische daran: Es sah nie kaputt aus. Graue Zeichen auf dunklem Grund wirken sauber und zurueckhaltend -- man haelt es fuer eine Entscheidung. Ein Fehler, der wie Gestaltung aussieht, ueberlebt jede Pruefung, die auf Fehlermeldungen achtet. DIE REPARATUR Jedes Zeichen traegt seine Verlaeufe jetzt SELBST, in seinem eigenen SVG und mit eigener Kennung. Damit steht `currentColor` dort, wo es hingehoert. Die Verweise setzt das Skript als Inline-Stil, weil eine Klassenregel die je Zeichen andere Kennung nicht kennen kann -- das Wasserzeichen bekommt keinen, dort setzt das CSS die Farbe ausdruecklich. UND DAS LICHT WURDE UMGEDREHT Weiss stand vorher ueberall: die Deckflaeche begann mit 92 % Weiss, die Kontur war bis 38 % weiss und bei 100 % wieder. Selbst mit richtiger Farbe waere davon wenig uebrig geblieben. Jetzt ist Weiss nur noch da, wo bei einem echten Gegenstand das SPITZLICHT sitzt -- ein schmaler Streifen ganz oben. Darunter traegt die Eigenfarbe, unten kommt Streulicht in einer helleren Tonung statt in Weiss: Licht, das vom Untergrund zurueckkommt, nimmt die Farbe des Gegenstands mit, es bleicht ihn nicht aus. Das Spitzlicht selbst wurde schmal und hart -- ein Schleier ueber zwei Drittel der Flaeche ist kein Spitzlicht, sondern der sicherste Weg, jede Farbe blass zu machen. DAS WASSERZEICHEN Seine Deckkraft von sieben Prozent war ein Wert aus der Zeit, als das Zeichen grau war -- mehr ging nicht, ohne dass es schmutzig aussah. Eine Farbe darf lauter sein als ein Grau, weil sie zur Kachel GEHOERT. Auf 14 Prozent verdoppelt, kraeftigere Linie, und ein leichter Schein darunter fuer Tiefe. 15 Pruefungen gelaufen, alle gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
532daa3edf |
Alles fertig: Konsole montiert, Tageskachel als Instrument, zwei Seiten repariert
DIE KONSOLE -- DREI STUFEN DRAUF
1. VIER NIETEN in den vier Fasen. Das Einzige, was eine Flaeche
endgueltig zu einem GEGENSTAND macht, ist die Frage, wie sie
befestigt ist. Ein Gehaeuse haengt nicht in der Luft.
2. EINE GEFRAESTE NUT trennt Text von Instrumenten -- dunkel auf der
Lichtseite, hell auf der Schattenseite. Genau umgekehrt zu einer
aufgemalten Linie, und deshalb sieht sie nach Material aus.
3. DIE UHR SITZT IN EINER MULDE statt auf der Platte.
Drei Fehler dabei, alle im Bildschirmfoto gesehen: Die Nieten waren
QUADRATE (eine Hintergrundebene laesst sich nicht runden -- jetzt aus
Radialverlaeufen, die selbst rund sind). Die Mulde lag UEBER der Uhr
und hat die polierte Luenette zu mattem Grau gedaempft (`::after` wird
nach allen Kindern gezeichnet). Und das Raster musste von der
Nieten-Ebene herunter: Eine Ebene hat nur EINE Deckkraft.
DIE TAGESKACHEL "WAS IST DRAN"
Die drei Zeilen sind jetzt MODULE -- Fase, Kantenlicht in der Farbe
ihres Bereichs, Eckwinkel. Sie sind damit kleine Ausgaben derselben
Bauteile, zu denen sie fuehren, was sie ja auch sind. Die ZAHL wurde
zum gefassten Schild wie das Zeichen auf den Kacheln, und zwischen den
Haelften laeuft dieselbe gefraeste Nut wie auf der Konsole.
Ein Rueckschritt dabei, von der Pruefung sofort gemeldet: Ich hatte
die Ziffer weiss gemacht, weil das auf Metall gut aussieht -- damit
war ihre Aussage weg. Die Zahl traegt die Farbe ihres Bereichs und bei
etwas Ueberfaelligem die Warnfarbe; das ist die schnellste Auskunft der
ganzen Kachel. Die Farbe gehoert in die Ziffer, nicht ins Schild.
SPICY MEDIA SIEHT DIE ZAHLEN JETZT NIRGENDS
Vorher nur Kachel und Seite -- die Creator-Zahlen standen weiterhin im
Dashboard, weil das sie ueber eine eigene Schnittstelle holt. Die ist
jetzt zu (404 am Server, nicht in der Oberflaeche). Das Dashboard
bleibt fuer sie stehen: Es faengt den Fehlschlag ausdruecklich ab.
Mit Pruefung und Gegenprobe.
UND ZWEI SEITEN, DIE BEIM ANSEHEN AUFFIELEN
Das ist der Ertrag der Durchsicht jener zwoelf Seiten, die bisher nur
GEPRUEFT und nie ANGESEHEN worden waren:
* chat.html und uebersicht.html luden kopf.js OHNE wahl.js. Der
Umschalter "Meine Sicht" fiel dort auf das nackte Systemfeld
zurueck: 92 x 19 px, grauer Kasten, Systemschrift -- auf allen
anderen Seiten ist es ein selbst gebautes Bedienelement, hinter dem
dasselbe Feld unsichtbar bei 2 x 2 px liegt. Kaputt war nichts. Es
sah nur aus wie aus einem anderen Programm, und genau das findet
keine Pruefung, die auf Fehlermeldungen achtet.
Neue Pruefung: Wer kopf.js laedt, muss wahl.js laden -- und vorher.
* Der Chat-Rahmen gehoerte als einzige grosse Flaeche noch nicht zum
Modulsystem. Jetzt schon.
18 Pruefungen gelaufen, alle gruen. Rechner und Handy angesehen,
dazu Kalender, Chat, Automationen, Uebersicht, Start-Check,
Steckbrief, Bereiche, Profil, Content, Scouting und Report.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
90d5898640 |
Drei Stufen auf die Kacheln -- Fase, Rahmung, gefasstes Schild
Filipe: "perfektionier alle kacheln die du vorhin gewechselt hast auf
der ganzen website, mach sie alle noch geiler und geiler und noch
spezieller. sie gehen aber in eine gute richtung schon."
Alle drei Stufen sind FORM, keine neue Farbe -- das war die Lehre der
letzten Runden. Sie gelten fuer alle 35 Bauteile auf allen 18 Seiten,
weil sie in module.css stehen.
STUFE 1 -- DIE SCHRAEGE WIRD EINE ECHTE FASE
Bisher war die abgeschnittene Ecke ein Loch: Material, das fehlt. Eine
gefraeste Fase hat eine FLAECHE, und auf der liegt Schatten, weil sie
schraeg zum Licht steht. Ein Innenschatten aus der Richtung der
Schraege macht daraus ein bearbeitetes Werkstueck.
STUFE 2 -- ECKWINKEL AN DREI ECKEN STATT AN EINER
Eine einzelne Ecke liest sich als Verzierung, drei lesen sich als
RAHMUNG: Das Auge schliesst sie zu einem Ausschnitt. Die vierte bleibt
frei, dort sitzt die Fase -- ein Winkel auf einer abgeschnittenen Ecke
zeigte ins Leere.
STUFE 3 -- DAS ZEICHEN BEKOMMT EINE METALLFASSUNG
Die Plakette war ein abgerundetes Quadrat mit Farbschleier, also
dieselbe Form wie ueberall sonst im Netz. Jetzt ist sie ein gefasstes
Schild: dieselbe abgeschnittene Ecke wie ihre Karte, ein 2 px breiter
Ring aus gebuerstetem Metall, und die Kategoriefarbe INNEN. Damit
spricht die Anwendung EINE Materialsprache -- Konsole, Luenette der
Uhr und Schild sind dasselbe Metall.
ZWEI FEHLER DABEI, BEIDE GEMESSEN STATT VERMUTET
* DIE RUNDUNG BLIEB. `.kachel[data-gross="ja"] .kachel__zeichen`
setzt in start.css zweimal einen Radius (21 px, 18 px) und ist
staerker als eine einzelne Klasse. Gemessen: 18 px, obwohl
module.css 0 setzt und zuletzt geladen wird. Heraus kam ein Schild
mit abgeschnittener Ecke UND runden Ecken. Das ist heute die
dritte Spielart derselben Falle -- `:where()` war zu schwach,
`body.start .willkommen` zu stark, hier ist es die
Verschachtelung.
* DIE FASSUNG WAR ZU GRELL. Fast weiss auf 2 px Breite las sich als
Rahmen, der lauter ist als das Zeichen darin. Eine Fassung soll
das Schild halten, nicht mit ihm konkurrieren -- dieselben Stopps,
eine Blende dunkler.
18 Pruefungen gelaufen, alle gruen, keine mit gesunkener Anzahl.
Rechner und Handy (412 px) angesehen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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]>
|
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
4eab64bd20 |
Eine neue Form fuer jedes Modul -- und der Kalender zeigt nur noch, was einen angeht
Filipe: "DU HAST WIEDER EINE KLEINE AENDERUNG UEBERALL GEMACHT ANSTATT
EINE RIESEN AENDERUNG." Er hatte recht, und der Grund war jedes Mal
derselbe: Ich habe das MATERIAL getauscht (Mattglas, Leuchtschiene,
Verlauf) und die FORM gelassen. Ein abgerundetes Rechteck bleibt ein
abgerundetes Rechteck -- und die Silhouette ist das Einzige, was man aus
fuenf Metern erkennt.
Jetzt ist die Form eine andere: abgeschnittene Ecke oben links
(clip-path, echte Silhouette), ein Kantenlicht in der Kategoriefarbe
darauf, Eckwinkel unten rechts, ein feines Raster statt Koernung.
35 Bauteile auf allen 18 Seiten, in einer eigenen Datei (module.css).
DREI DINGE, DIE DABEI SCHIEFGINGEN UND JETZT ABGESICHERT SIND
1. Die Regeln standen in :where() -- Spezifitaet null, also gewann jede
aeltere .kachel::before-Regel. Jetzt :is().
2. module.css stand an DRITTER Stelle im Ladeweg. Auf Calls,
Automationen, Bereich und Dateien hat sie damit gar nichts bewirkt:
Die Seitendateien setzen dort selbst border-radius und box-shadow und
kommen spaeter. Genau das ergab wieder "ueberall ein bisschen". Sie
wird jetzt als LETZTE geladen, geprueft auf allen 18 Seiten.
3. Die Klassenliste steht siebenmal in der Datei (CSS kennt keine
Variable fuer Selektoren). Eine vergessene Kopie faellt niemandem
auf -- pruef-css-klassen vergleicht sie deshalb alle, mit Gegenprobe.
DER KALENDER: NUR NOCH, WAS EINEN ANGEHT
Filipe: "calls oder termine soll jeder nur sehen die er selber macht
oder jeden betrifft." Das gilt auch fuer DogFather, und das ist die
eigentliche Aenderung -- er bekam bisher 1=1. "Jeden betrifft" heisst:
ohne Gegenueber und ohne Teilnehmerliste. Wer niemanden eintraegt, meint
alle. Die Rollenfrage entfaellt im Kalender damit vollstaendig.
SECHS PRUEFUNGEN, DIE EINE WELT GEMESSEN HABEN, DIE ES NICHT MEHR GIBT
Alle sechs wurden auf die neue Regel umgeschrieben, keine geloescht --
loeschen haette die Zahl gesenkt und den neuen Weg ungeprueft gelassen:
ics, serien, sicht, spicy, teilnehmer, tagesblick, team.
UND VIER ECHTE FUNDE, DIE DABEI HERAUSFIELEN
* pruef-workspace-seiten war seit dem Bildumbau von heute Frueh auf
ALLEN 32 Seiten rot: Sie verlangte noch das eine Motiv. Die neue
Bedingung ist schaerfer als beide alten -- das geladene Bild muss zu
dem Merkmal passen, das die Seite selbst traegt. Und die Meldung sagt
jetzt, WELCHE Bedingung gefallen ist.
* pruef-leistung-optik hat sich selbst ausgesperrt (meldete sich als
Manager an, der die Zahlen seit Filipes Anweisung nicht mehr sehen
darf) und stuerzte danach ab: 2 Pruefungen statt 56. Der Absturz hat
verdeckt, dass sie sieben Fingerziele als "zu klein" meldete -- es
waren die unsichtbaren Knoepfe der zugeklappten Woche, 0x0.
* personen.html beim Manager: Der Erklaersatz ("Codes, Sperren und das
Protokoll bleiben bei DogFather") kam nie an -- das Element gab es
nicht, und das && davor hat den Fehlgriff verschluckt. Die Liste stand
ausserdem dauerhaft auf aria-busy="true": fuer einen Screenreader lud
die Seite fuer immer.
* pruef-schranke hielt personen.html noch fuer DogFather-only. Die Seite
wechselt jetzt die Erwartung, statt aus der Pruefung zu verschwinden:
Seite auf fuer die Leitung, Verwaltungsdaten dahinter weiterhin zu.
Die Anmeldeseite wurde nicht angefasst (nur ihr Versionsstempel).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e8478c9cae |
Spicy sieht DogFathers Sachen nicht mehr -- und sechs Fehler dazu
VIER DINGE AUS DEN BILDSCHIRMFOTOS, jedes ein echter Fehler:
1. SPICY MEDIA SAH DOGFATHERS DATEN. Beim ersten Anlauf bekam die Rolle
dieselbe Regel wie DogFather (`1=1`) -- damit stimmte der Ueberblick
ueber Manager, Scouts und Creator, und nebenbei standen seine eigenen
Termine, Aufgaben, Dateien und Eintraege mit drin. Jetzt gibt es
ohneDogFather() als EINE Stelle dafuer: Zwei Spalten werden geprueft,
`creator_id` (um wen geht es) und `erstellt_von` (wer hat es
geschrieben) -- ein Termin, den er sich selbst anlegt, haengt nur an
der zweiten. `IS NULL OR NOT IN` und nicht bloss `NOT IN`: In SQL ist
`NULL NOT IN (...)` weder wahr noch falsch, die Zeile fiele
stillschweigend heraus.
2. "PERSOENLICHER ZUGANGSCODE · undefined" auf der Anmeldeseite. Eine
zweite Namensliste im Browser, die beim Hinzufuegen der Rolle
niemand gepflegt hat. Ein unbekannter Schluessel faellt jetzt auf
sich selbst zurueck statt auf `undefined` -- haesslich, aber
sichtbar.
3. SPICY KAM NICHT IN DIE PERSONENVERWALTUNG. Der Server liess sie
herein, das Skript warf sie wieder hinaus: zwei Listen fuer dieselbe
Frage, gepflegt wurde nur die erste.
4. DIE ANMELDEKARTE WAR ZU KLEIN FUER FUENF ROLLEN. Der Kommentar an
genau dieser Stelle warnt woertlich davor -- und ich habe getan,
wovor er warnt: eine Rolle eingefuegt und die Zahl daneben nicht
angefasst. Gemessen: Inhalt 573 px in einer 526 px hohen Tafel, die
Fusszeile stand unter dem Rahmen. Schrift kleiner half nicht (sie lag
schon auf dem Anschlag), also sind die Abstaende an neun Stellen
enger. Nachgemessen auf fuenf Groessen: passt ueberall.
DIE ZEIT WAR WIRKLICH FALSCH. Nicht nur in meinem Satz: `datum()` in
personen.js schnitt die ISO-Zeichenkette ab -- und die ist UTC. Im
Protokoll stand 03:00, wo 05:00 war. Das Tueckische daran ist, dass es
nie kaputt aussieht: Eine Uhrzeit ist immer plausibel.
PROFILBILDER WERDEN JETZT GEZEICHNET. Der Server lieferte sie seit
gestern mit, gezeichnet wurden sie nirgends -- deshalb aenderte sich
nichts. Jetzt in der Personenauswahl (Aufgaben, Termine, Dateien,
Bereiche), in der Gespraechsliste und an jeder Nachricht. Der
Anfangsbuchstabe bleibt als Unterlage LIEGEN: Faellt das Bild aus, steht
dort weiter etwas Sinnvolles.
DER CHAT: Gesichter mit Rollenfarbe, Blasen mit Richtung (die erste
einer Folge eckig, die naechsten rund -- so sieht man, wo ein Gedanke
anfaengt), das offene Gespraech mit Schiene, Ungelesenes hervorgehoben,
und das Eingabefeld in einer eigenen Leiste, die sich beim Schreiben
hebt.
ZWEI EIGENE PATZER, beide von Pruefungen gefunden:
- `o is not defined`: Mein Suchmuster hat die zwei Zeilen fuer das
Bild ans DATEIENDE gesetzt statt in die Schleife -- und in
kalender.js an einen <span> statt ans <option>. Gemeldet von
pruef-sicht, das die Browserkonsole mitliest.
- Ein Kommentar mit `bild` in schraegen Anfuehrungszeichen stand INNEN
in einer Vorlagenzeichenkette und hat sie geschlossen. Die halbe SQL
wurde zu Programmtext.
Dazu: `.chat-neu` gibt es nicht (heisst `.chat__eingabe`), und der
Rollenknopf hatte fuer den Manager keinen sichtbaren Fokus -- ein
box-shadow wird von `overflow: hidden` abgeschnitten, ein outline nicht.
Gruen: spicy (43), creator-anlegen (29), personen-liste (33), sicht (48),
chat (48), chat-optik (24), buehne (38), struktur (32), css-klassen (15),
handy (59), breiten (23), formulare (19), start-ansicht (136),
lesbarkeit (14), barrierefrei (18), tempo (8), kopf-messen (3),
glocke (26), haerte (20), manager-sicht (43), alle-wege (19),
aufgabenbrett (44), kalender (84).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
3b356d6eef |
Ein Material fuer die ganze Website -- und die Uhr wird zum Chronographen
DIE UHR: Sekunde nach AUSSEN, Minute in die Mitte, Stunde nach innen (Wunsch Filipe). Das ist die Anordnung eines Chronographen und nicht die eines Fortschrittsbalkens: Der schnellste Zeiger laeuft auf der laengsten Bahn, weil man Bewegung dort am besten sieht -- der langsamste innen, wo eine kleine Drehung viel bedeutet. Die drei Umfaenge sind mitgewandert; ein vertauschter Ring ohne vertauschte Zahlen endet nie dort, wo er soll. EIN MATERIAL FUER ALLE SEITEN. Die Startseite hatte seit heute beleuchtete Platten, die anderen sechzehn Seiten flache Rechtecke -- man wechselte die Seite und fiel aus einer Oberflaeche in eine andere. Ich habe das bisher Seite fuer Seite nachgezogen, und genau deshalb war es nie fertig: Es sind FUENFUNDVIERZIG Stellen. Jetzt EINE Regel. Die Klassenliste ist nicht erfunden, sondern gemessen -- es sind genau die, die `var(--flaeche)` als Kartenflaeche benutzen. `:where()` ist der Kniff dabei: Spezifitaet null, also ueberschreibt die Regel nichts, was eine Seite selbst festlegt. Eine Warnkarte bleibt rot, eine Spalte behaelt ihre Statusfarbe. Ohne das haette ich an dreissig Stellen `!important` gebraucht. DREI FUNDE DER PRUEFUNGEN, alle berechtigt: 1. `.profil-gruppe` gibt es nicht -- ich hatte den Namen aus dem Kopf geschrieben statt aus der Datei. pruef-struktur meldete totes CSS. Die Karten auf profil.html heissen `.gruppe`, und genau der Name darf NICHT in die Liste: Auf der Startseite heissen die Kachelgruppen ebenso und haetten ploetzlich eine Kartenflaeche. 2. Der erste Verlauf war HELLER als das, was er ersetzt. Ein Material, das die ganze Website aufhellt, hellt auch jeden Text darauf auf -- und das faellt an der leisesten Schrift zuerst auf. 3. `.gruppe__unter` stand auf 4,21:1. Und das ist der interessante Fall: Die Farbe war nicht schuld, eine VERSCHIEBUNG war es. Mit der fuenften Rolle rutschte auf personen.html alles eine Zeile nach unten, und die Zeile landete auf einer helleren Stelle des Buehnenbilds. Sie ist die einzige Beschriftung ohne Karte -- ein Text, dessen Untergrund ein FOTO ist, bekommt nicht den leisesten Ton. Jetzt 5,51:1. Der zweite Fund fiel nur auf, weil die Zahl sich nach meiner ersten Korrektur KEIN Stueck bewegte (zweimal exakt 4,21) -- dasselbe Zeichen wie schon zweimal heute: falsche Stelle, nicht zu wenig. Gruen: buehne (38), css-klassen (15), struktur (32), handy (59), breiten (23), start-ansicht (136), lesbarkeit (14), tempo (8), personen-liste (33). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
68bc116c36 |
Die Rolle "Spicy Media" -- und drei Fehler, die nur ihre Pruefung fand
DIE PERSONENTABELLE WURDE NEU GEBAUT. Eine Rolle ist ein erlaubter Wert in einer Spalte, und der steckt in einem CHECK -- den kann SQLite nicht aendern. Auf `personen` zeigen ZWEIUNDFUENFZIG Fremdschluessel. Deshalb wird der Bauplan NICHT abgeschrieben, sondern gelesen: Der CREATE-Text kommt aus sqlite_master, darin wird ausschliesslich die Rollenliste ersetzt, und die Kopierliste kommt aus PRAGMA table_info. Die beiden aelteren Umstellungen schreiben ihre Spalten von Hand ab -- `personen` hat seit damals SIEBEN dazubekommen (bild, ueber_mich, tiktok ...). Wer hier abschreibt, verliert alle Profilbilder. ZWEI FRAGEN, DIE MAN AUSEINANDERHALTEN MUSS: siehtAlles() = DogFather ODER Spicy Media -> Listen, Uebersichten istDogFather() = nur DogFather -> loeschen, Rollen, Codes Es waere weniger Arbeit gewesen, istDogFather() um "spicy" zu erweitern -- und genau das waere der Fehler: Spicy Media koennte dann DogFather loeschen. DER CHAT BRAUCHTE NICHTS. Er haengt allein an der Teilnehmerliste und kennt kein "das Management sieht alles". Spicy Media sieht fremde Gespraeche nicht, weil es dafuer keinen Weg gibt -- nicht, weil eine Abfrage es verbietet. DREI ECHTE FEHLER, alle von pruef-spicy gefunden, keiner vorher sichtbar: 1. MEIN EIGENER KOMMENTAR STAND IM BAUPLAN. SQLite hebt den CREATE-Text woertlich auf, samt Kommentaren. Ich hatte "'spicy' steht HIER mit drin" hineingeschrieben -- und die Erkennung suchte genau dieses Wort im ganzen Text. Ergebnis: Die Umstellung hielt die Tabelle fuer erledigt, obwohl die CHECK-Regel noch die alte war. Jetzt wird die Regel herausgeschnitten und NUR darin gesucht; der Kommentar steht ausserhalb des SQL. 2. DER SICHERUNGSNAME HATTE NUR MINUTEN. `VACUUM INTO` weigert sich, eine vorhandene Datei zu ueberschreiben -- zu Recht. Zwei Umstellungen in derselben Minute wollten in dieselbe Datei, die zweite scheiterte, und weil ohne Sicherung nicht umgestellt wird, blieb sie aus. Es sah nach "lief" aus (die Datei lag ja da) und war keine. Jetzt mit Sekunden. 3. EINE FRISCHE DATENBANK LEGTE DIE ALTE ROLLENLISTE AN und stellte beim allerersten Start sofort um -- Tabelle neu bauen, Sicherung schreiben, fuer nichts. Ein Bauplan, der sofort umgebaut werden muss, ist der falsche. Und ein vierter in der Pruefung selbst: Der Chat-Aufbau benutzte einen falschen Weg, das Gespraech entstand gar nicht -- "Spicy Media sieht 0 Gespraeche" war trotzdem gruen, weil es keine gab. Jetzt ist das Anlegen selbst eine Pruefung, und eine Gegenprobe zeigt, dass Max es sehr wohl sieht. DAZU: Manager sehen die Kachel "Personen & Zugaenge" -- die SEITE geht auf, die Schnittstellen nicht. Alles unter /verwaltung haengt weiter an `nurAdmin` und antwortet 404; sie sehen genau den Teil, fuer den es einen Weg gibt. Spicy Media legt Creator UND Manager an (zweite enge Tuer, Rolle steht auch dort nicht im Aufruf; ein Manager kommt durch sie nicht). Der Rollentext des Managers stimmte nicht mehr -- er legt jetzt Creator an. pruef-spicy: 36 Pruefungen, alle gruen. Ausserdem gruen: personen-liste (33), creator-anlegen (29), sicht (48), css-klassen (15), alle-wege (19), haerte (20), manager-sicht (43). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4bb5afc942 |
Drei Ringe, klappbare Gruppen -- und die Calls-Seite endlich wirklich umgebaut
DU HATTEST RECHT (Bildschirmfoto 3). Beim letzten Mal habe ich an der Calls-Seite nur das MATERIAL der Karten getauscht und die Aufstellung gelassen. Drei Gruppen untereinander, und weil "Steht an" 27 Eintraege hat, lagen die beiden anderen ausserhalb des Bildes -- man SAH die Aenderung gar nicht, weil man nie so weit kam. Das war Lackieren, kein Umbauen. JETZT EIN BRETT AUS ZWEI SPALTEN. Die Gruppen sind eigenstaendige Tafeln in einem Raster; "Protokoll fehlt" (kurz, dringend) und "Festgehalten" (Archiv) liegen NEBEN der langen Liste statt darunter. `align-items: start` ist dabei der Punkt: Ohne ihn waeren alle Tafeln so hoch wie die hoechste, und neben der langen Liste stuenden zwei fast leere Kaesten. Welche Tafel wo landet, entscheidet die Breite und nicht das Skript -- eine festgeschriebene Spalte waere eine Zahl, die beim naechsten Fenster falsch ist. Jede Tafel klappt zu, und der Zustand wird gemerkt. Vorgabe: "Festgehalten" ist zu -- es ist das Archiv; wer die Seite oeffnet, will wissen, was ansteht. DIE GRUPPEN AUF DER STARTSEITE genauso. Der Kopf IST der Schalter, nicht ein Dreieck daneben: Die ganze Zeile ist ein Ziel von 40 Pixeln statt eines von vierzehn. <button> statt <div>, damit Tastaturbedienung und Ansage nicht mit tabindex und role nachgebaut werden muessen. Gemerkt wird je Gruppe UND je angesehener Rolle -- DogFather, der sich einen Creator ansieht, hat dort eine andere Aufteilung im Kopf. DIE UHR: drei Ringe statt zwei. Aussen die Stunde in Schwarzsilber, in der Mitte die Minute in Blau, innen die Sekunde in Rot -- von aussen nach innen immer schneller, so liest man eine Uhr ohne nachzudenken. UND SIE IST SCHARF. Kein blur(), kein drop-shadow mehr auf den Boegen -- an der alten lag beides drauf, und der Vorwurf stimmte. Der Glanz kommt jetzt aus dem VERLAUF: Echtes Metall glaenzt nicht, weil es leuchtet, sondern weil es das Licht abwechselnd hell und dunkel zurueckwirft. Fuenf Stopps statt zwei -- ein zweifarbiger Verlauf waere ein Farbverlauf, erst der Wechsel ist Metall. Dazu `shape-rendering="geometricPrecision"` (sonst rastert der Browser duenne Boegen grober) und Kappen auf `butt` statt `round`: Eine runde Kappe steht ueber das Ende hinaus, bei null Sekunden saehe man trotzdem einen Punkt. Minute und Stunde laufen WEICH mit: die Minute bekommt die Sekunden anteilig, die Stunde die Minuten. Ein Minutenring, der einmal pro Minute springt, sieht aus wie eine haengende Anzeige. Gruen: css-klassen (15), call-kategorien (17), start-ansicht (136), handy (59), breiten (23), buehne (38), struktur (32). NOCH OFFEN: der neue Kachelstil fuer die ganze Website und die Rolle "Spicy Media". Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
49bd4a7cec |
Manager legen Creator an -- eine neue Tuer statt eines Schluessels fuer die alte
Filipe: "wieso greift das in die rechte rein? ist doch ok, die sollen einfach paar leute selber hinzufuegen koennen." Er hat recht, und ich hatte zwei Dinge in einen Topf geworfen: Das hier braucht KEINE Datenbankaenderung -- nur die Rolle "Spicy Media" braucht eine. WARUM EIN EIGENER WEG UND NICHT DIE ALTE TUER Alles unter /workspace/api/verwaltung haengt an EINER Schranke (nurAdmin). Dahinter liegen acht Wege: Rollen aendern, Codes neu setzen, sperren, loeschen, Protokoll lesen. Einen Manager dort hineinzulassen und danach in jedem der acht einzeln zu pruefen, was er darf, ist genau die Bauweise, durch die am 31.08.2026 ein Loch entstanden ist -- zwei von drei Stellen abgesichert, die dritte vergessen. Deshalb bleibt die Tuer zu, und daneben steht eine neue mit genau einem Zweck: POST /workspace/api/creator-anlegen. Sie kann nichts anderes, als einen Creator anzulegen -- nicht weil eine Abfrage es verbietet, sondern weil es hier keinen anderen Weg gibt. Unterschied zwischen "darf nicht" und "kann nicht". DIE ROLLE STEHT NICHT IM AUFRUF, sie wird im Server gesetzt. Ein Feld `rolle` im Koerper waere die naheliegende Loesung und die falsche: Dann muesste eine Abfrage sie pruefen, und eine vergessene Abfrage ist ein zweiter Zugang mit vollen Rechten. Geprueft wird deshalb nicht, dass ein mitgeschicktes `rolle: "admin"` abgelehnt wird, sondern dass es WIRKUNGSLOS ist. DIE ZUTEILUNG PASSIERT SOFORT. Ein Creator ohne Betreuung ist fuer alle ausser DogFather unsichtbar -- der Manager haette ihn angelegt und danach nicht mehr gesehen. Wer anlegt, betreut; ein eigener Scout kann mitgegeben werden. Eine FREMDE Scout-Nummer wird abgelehnt (403) und nicht stillschweigend auf den Anleger zurueckgesetzt: Sonst glaubte der Manager, er haette zugeteilt. Der Knopf sitzt auf dem Dashboard, nicht in der Personenverwaltung -- dort kommt ein Manager gar nicht hinein, und hier sieht er seine Creator ohnehin. Der Zugangscode steht einmal im Dialog und wird nie nachgeladen; deshalb schliesst sich das Fenster NICHT von selbst. pruef-creator-anlegen.mjs, 29 Pruefungen, alle gruen -- und die Haelfte davon prueft, was NICHT geht: Personenverwaltung 404 fuer Manager, Scout und Creator kommen gar nicht erst durch, fremder Scout 403 (und der Creator wird dabei gar nicht erst angelegt), erfundene Nummer 403. Zwei Manager mit je einem eigenen Scout, weil sich "nur die eigenen" mit nur einem Manager gar nicht pruefen laesst. Nebenbei: .feld-hinweis ist von bereich.css nach aufgaben.css gewandert (zu den uebrigen Formularstilen) -- ein Formularbaustein in der Bereichsdatei ist nur so lange richtig, wie ihn keine zweite Seite braucht. Gruen: creator-anlegen (29), personen-liste (33), css-klassen (15), struktur (32), formulare (19). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4447a653e7 |
Die Uhr wird ein Gegenstand -- Rot x Babyblau, und start.css wird geteilt
DIE UHR. Filipe: "viel viel viel viel viel viel viel spezieller ... eine
mischung von rot und babyblau". Was eine Uhr teuer aussehen laesst, ist
nicht die Farbe, sondern das GEHAEUSE -- bei einer echten sieht man drei
Schichten uebereinander: einen Metallrand, der das Licht von oben faengt,
eine VERTIEFTE Scheibe darin, und ein Glas darueber, das spiegelt. Genau
die drei sind jetzt gebaut.
Die beiden Farben sind nicht aus dem Farbkasten: Rot ist Spicy Media,
Babyblau ist DogFather -- dieselben zwei, die im Kopf der Anmeldekarte
nebeneinanderstehen und im Motiv den Neonrahmen bilden. Zwei Verlaeufe,
absichtlich GEGENLAEUFIG (Stundenring rot->blau, Sekundenring blau->rot):
Wo der eine warm ist, ist der andere kuehl, so bleiben sie
auseinanderzuhalten, wo sie sich ueberlagern.
Dazu: eine Skala aus sechzig Strichen, jeder fuenfte kraeftiger (aus
einem Kegelverlauf, nicht aus sechzig Elementen); ein leuchtender Kopf,
der am Ende des Sekundenbogens mitlaeuft -- die einzige Stelle, an der
sich sichtbar etwas bewegt; und die Mischung IM Text als zwei Schatten
statt als Verlaufsschrift (background-clip: text waere im Windows-
Kontrastmodus unsichtbar). Die Glocke bekommt dasselbe Gehaeuse, nur
kleiner -- zwei runde Dinge aus verschiedenem Material sehen
zusammengesucht aus.
PROFILBILDER: /api/personen lieferte nur id, name, rolle. Deshalb konnte
KEINE Oberflaeche ein Gesicht zeigen, auch wenn eines hochgeladen war --
der Fehler lag nicht in der Anzeige, sondern in der Schnittstelle.
Jetzt kommt die fertige Bildadresse mit (nicht der Dateiname: sonst
setzt jede Stelle im Browser denselben Pfad zusammen). Und DogFather ist
fuer alle sichtbar -- Name, Rolle, Bild, sonst nichts; seine Eintraege,
Chats und Zahlen haengen weiter an den eigenen Regeln der Module.
start.css GETEILT statt gekuerzt. Sie lief mit 202 KB wieder in die
200-KB-Grenze, und diesmal war Kuerzen die falsche Antwort: Dreizehn
Seiten laden diese Datei, Uhr und Begruessungskachel braucht genau EINE.
Also heim.css -- 184 KB statt 202, und zwoelf Seiten laden 14 KB
weniger. Vorher mit grep nachgesehen, dass `uhr`, `willkommen` und
`glocke-platz` in keiner anderen HTML-Datei vorkommen.
ZWEI FUNDE DER PRUEFUNGEN, beide berechtigt:
- `.glocke--kachel` musste zurueck nach start.css. glocke.js laeuft auf
ALLEN siebzehn Seiten und kann die Klasse ueberall setzen; die Regel
gehoert dorthin, wo das Skript sie brauchen KANN, nicht dorthin, wo
es sie heute zufaellig braucht.
- Die Sekundenanzeige stand auf 10,88 px (Grenze 11,5). Gesperrte
Ziffern in Versalhoehe wirken kleiner als die Zahl sagt -- auf
11,84 px.
Gruen: css-klassen (15), struktur (32), sicht (48), buehne (38),
start-ansicht (136), handy (59), aufgabenbrett (44).
NOCH OFFEN aus derselben Nachricht: die Calls-Seite komplett umbauen mit
Auf-/Zuklappen ueberall, die Profilbilder auch WIRKLICH ueberall
zeichnen (die Daten sind jetzt da), die Rolle "Spicy Media" und
Manager-legt-Creator-an.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8f8c283a1a |
Kacheln werden ein Raster -- dritter Anlauf, diesmal die FORM
Filipe zweimal davor: "das ist genau das gleiche" und "sorry aber ich glaub du verstehst nicht was ich meine". Er hatte beide Male recht, und ich weiss jetzt warum: Ich habe zweimal die OBERFLAECHE geaendert (Mattglas, dann Leuchtschiene) und beide Male die FORM gelassen -- eine breite Zeile, Zeichen links, Text daneben. Wer eine Zeile umlackiert, bekommt eine lackierte Zeile. AUS DREI BREITEN ZEILEN WIRD EIN RASTER AUS SECHS KARTEN. Hochformat, Zeichen oben, Name unten, Schiene von links nach OBEN gewandert (an einer hochkanten Karte wuerde ein Lichtbalken links sie optisch halbieren). Die Zahl steht als Marke oben rechts statt in der Namenszeile, der Pfeil unten rechts. `data-gross="ja"` behaelt das Querformat -- so hebt sich die Kachel WIRKLICH ab, statt nur breiter zu sein. Bei 1380 px passen jetzt sechs Karten nebeneinander statt drei. BILDER: Kontrast 1,08 -> 1,14, Saettigung 1,10 -> 1,26, Glanz 0,34 -> 0,46, dazu ein neuer Durchgang "Tiefe" -- eine S-Kurve auf der Helligkeit. Das ist NICHT mehr Kontrast: Kontrast dehnt alles gleich und frisst Zeichnung in den Lichtern; die S-Kurve laesst die Mitte in Ruhe (dort sitzt das Motiv) und arbeitet nur an den Enden. Gerechnet auf dem Maximum der drei Kanaele, nicht je Kanal -- sonst wandert der Farbton (ein dunkles Rot wuerde braun). ANMELDESEITE: "Dogfather Universe" -> "SpicyMedia x DogFather" (das Kreuz kleiner und leiser, sonst liest man drei Namen statt zwei), und der Satz darunter nennt jetzt Manager, Scouts und Creator von Spicy Media -- ohne DogFather. ZAHLEN nur noch fuer DogFather. Beides zusammen, nicht nur die Kachel: Eine Kachel ist ein Weg, keine Schranke -- wer die Adresse kennt, waere weiterhin hineingekommen. Also auch in der Rechteliste auf ["admin"]. AUFGERAEUMT, weil pruef-struktur zu Recht rot wurde: start.css lief mit 202 KB in die 200-KB-Grenze. Der Grund war echter Ballast -- die Datei trug DREI Generationen Kacheldesign uebereinander. Die ueberholten Regeln sind weg (nur was der neue Entwurf nicht selbst setzt, bleibt), der Entwurfstext dazu auf seine Lehre gekuerzt. 198,7 KB, und wichtiger: nur noch EINE Stelle, an der eine Kachel beschrieben wird. Gruen: buehne (38), css-klassen (15), leistung (50), start-ansicht (136), handy (59), breiten (23), struktur (32). NOCH OFFEN aus derselben Nachricht: die neue Rolle "Spicy Media" und die Aenderung, dass Manager Creator anlegen duerfen. Beides greift in die Rechte und in die CHECK-Regel der Personentabelle ein -- das kommt als eigener Schritt mit Sicherung und eigener Pruefung, nicht nebenbei. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
8efdb39ce9 |
Kein Weichzeichner mehr -- die Bilder werden scharf, die Kacheln Lampen
Filipe: "gerade sehen die sogar leicht verschwommen aus ... die sollen
nicht durch die kacheln gehen ... ich wollte eine krasse aenderung."
Drei Ursachen, alle drei von mir eingebaut, alle drei gemessen:
1. ICH HABE 1647-PIXEL-BILDER ALS "uhd" MIT 2400 PIXELN AUSGELIEFERT.
Am Morgen stand in derselben Datei, sein Schirm sei 2550 px breit und
das groesste Bild 1600 -- meine "Loesung" war, die Ausgabe
hochzurechnen. Es gab nie mehr Bildpunkte. Dazu fehlte der Schritt,
den der Kommentar daneben selbst verlangt ("Verkleinern MITTELT
Bildpunkte ... deshalb schaerft man danach nach"): Es wurde nie
nachgeschaerft. Jetzt Unscharfmaske auf der ENDgroesse
(Ausgabeschaerfung) und ein Glanz-Durchgang: die hellsten Stellen
weich gezeichnet und additiv dazu -- Licht, das ueber seine Kante
strahlt. Guete 0,80 -> 0,88, am Gate 0,93.
2. backdrop-filter: blur() UNTER JEDER FLAECHE. 16 px unter siebzehn
Kacheln, 13 px unter sieben weiteren Flaechen, 26 px unter der
Anmeldekarte. Ein Weichzeichner mittelt nicht nur, was hinter dem
Element liegt -- er zieht seinen Radius weit darueber hinaus. Hinter
der Anmeldetafel ist Schwarz, direkt daneben aber die hellste Stelle
des Motivs: Die Karte wurde deshalb GRAU, gemessen rgb(46,57,64)
statt rgb(15,22,34). Je schoener der Rahmen, desto grauer die Karte.
Alle Weichzeichner raus, --flaeche 0,78 -> 0,89: Durchsicht bleibt,
aber scharf.
3. DIE TAFELMESSUNG WAR FALSCH, UND ICH HABE SIE VON HAND "KORRIGIERT".
Sie lief vom Inneren nach aussen und hielt beim ersten farbigen Punkt
an -- links glueht der Rahmen breiter als rechts, also hielt sie dort
frueher an (58,59 statt 55,37). Statt den Messfehler zu beheben, habe
ich in der CSS "um 1,1 % nach links" geschaetzt. Ergebnis: 32 px
schwarze Tafel blieben links offen. Jetzt wird die einzige
Eigenschaft gesucht, die nur der Rahmen hat -- kraeftig UND farbig --,
mit Gegenprobe auf der linken Bildhaelfte (dort muessen es 0 sein).
KACHELN: keine Politur mehr, ein anderes Ding. Jede steckt in einer
LEUCHTSCHIENE ihrer Kategoriefarbe, die Licht in die Platte wirft --
links scharfe Kante, rechts rund. Steiler Abfall (52 % statt 68 %):
beleuchtet, nicht eingefaerbt. Der Glanz wandert beim Ueberfahren
einmal durch. Dieselbe Sprache auf der Anmeldeseite: die vier Rollen
sind Tasten in Schienen (Gold/Bernstein/Gruen/Blau).
Zwei eigene Fehler nebenbei, beide durch das Unveraenderlichkeits-
Zeichen gefunden -- eine Zahl, die sich nach einer Aenderung KEIN Stueck
bewegt, sagt "falsche Stelle", nicht "zu wenig":
- Dreimal exakt 4,16:1 an "Ueberfaellig". Der Pruefpunkt lag nicht auf
dem Knopf, sondern in der Luecke daneben auf dem Bild. Ursache war
das hellere Hochkant-Bild, nicht das Bedienelement -> mehr Schleier
und weniger Glanz NUR fuer die Handy-Fassung. 4,16 -> 5,10.
- Die Koernung der Anmeldekarte lag mit 90 % Deckkraft ohne Mischmodus
ueber allem und hob jeden Bildpunkt um 30 Stufen. Jetzt 4 % mit
overlay, auf eigener Ebene.
- --flaeche anzuheben machte die WICHTIGE Anleitung duenner als eine
gewoehnliche (88 gegen 89) -- feste Zahl neben beweglicher Groesse.
Gefunden von pruef-lesbarkeit, jetzt an --flaeche gebunden.
Gruen: buehne (38), start-ansicht (136), handy (59), breiten (23),
lesbarkeit (14), css-klassen (15), barrierefrei (18), tempo (8).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
947c9d8a26 |
Agentur: Eintraege gehoeren allen -- und Events bekommen ein eigenes Formular
Gemessen am 07.09.2026, bevor irgendetwas geaendert wurde: Von drei Agentur-Eintraegen sah eine Creatorin genau EINEN -- den, der ihr zugeordnet war. Ein Event fuer alle traf weder `creator_id = ich` noch `erstellt_von = ich`; die Agentur-Seite war fuer jeden Creator leer. Nicht kaputt, nicht fehlerhaft: leer, so wie eine Seite aussieht, auf der noch nichts steht. Die Pruefung dazu war gruen. Sie legte ihre Testeintraege mit `creator_id: idLuna` an und pruefte damit einen Fall, den es im Alltag nicht gibt. - Bereichseinstellung `fuerAlle` + `ohneCreatorBezug`, daraus abgeleitet sichtbarEintrag(). BEWUSST neben sichtbar() statt darin: an derselben Funktion haengen Aufgaben, Dateien, Termine und Calls -- wer dort "1=1" einschleust, gibt nebenbei fremde Akten frei. Eine Gegenprobe mit einer zweiten Creatorin haelt das fest. - Die Zuordnung bietet nur noch "Agentur" an. Der Server verwirft eine Zuordnung ausserdem selbst -- inklusive des frei getippten Namens, und zwar NACH externPruefen: davor haette der Name den Riegel wieder aufgemacht. - "Event & Kampagne" heisst jetzt "Agentur-Events" und hat ein eigenes Formular: Von/Bis, Titel, Beschreibung, Aufgaben (Punkte und Preise), Regeln. Die Karte zeigt den Zustand als WORT (laeuft bis / startet / vorbei seit), nicht nur als Farbe. - Drei neue Spalten -- und sie stehen auch im Tabellenneubau vom 06.09. Der laeuft NACH dem Spaltennachtrag und haette sie samt Inhalt weggeworfen, ohne Fehler und mit stimmender Zeilenzahl. - Creator sehen weiterhin alles und tragen weiterhin nichts ein (403). Die Unterzeile sagt jetzt "alles, was hier steht" statt "alles, was zu dir gehoert" -- eine vollstaendige Liste soll sich nicht wie ein Ausschnitt lesen. pruef-agentur: 61 Pruefungen (vorher 40), alle gruen. Zwei eigene Fehler nebenbei gefunden und behoben: eine Beschriftung mit 11,2 px (Grenze 11,5) und ein Testdatum aus UTC statt Ortszeit. Zusaetzlich gruen: css-klassen, struktur, formulare, barrierefrei-workspace, handy. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
3914adf46c |
Material statt Farbe -- Kacheln werden Gegenstaende, die Karte ein Bildschirm
Filipe: "ich will dass alle kacheln viel geiler und spezieller aussehen,
viel realistischer" und "so dass der komplette von der kachel vom
hintergrund bild komplett bedeckt ist. ueberrasch mich."
DIE BILDER: BEARBEITET STATT ABGEDUNKELT.
Bis hierher tat der Bildbauer zwei Dinge -- kleiner rechnen und einen
schwarzen Schleier darueberlegen. Abdunkeln macht ein Bild aber nicht
ruhiger, sondern TOT: Es zieht jede Farbe zur Mitte, und uebrig bleibt
ein grauer Schleier mit einer Ahnung von Motiv.
Drei Dinge, die ein Fotograf zuerst anfasst, und keines davon ist
"dunkler":
* KONTRAST -- Verkleinern MITTELT Bildpunkte; deshalb wirkt jedes
verkleinerte Bild flauer als das Original, und deshalb schaerft man
danach nach.
* SAETTIGUNG -- holt das Rot der Chili und das Gruen der Blaetter
zurueck, die der Schleier herausgewaschen hatte.
* VIGNETTE -- der eigentliche Unterschied zwischen "Screenshot" und
"Aufnahme". Ein Objektiv verliert zu den Ecken hin Licht; das Auge
liest das als Tiefe. Sie ersetzt ausserdem einen Teil des flachen
Schleiers: Dunkel wird, wo ohnehin nichts steht.
Der flache Schleier sinkt dadurch von 0,42 auf 0,26 -- heller UND
lesbar, weil die Vignette genau dort arbeitet, wo die Kacheln liegen.
DIE KACHELN: VIER DINGE, DIE EIN DING VON EINEM RECHTECK TRENNEN.
Sie hatten Farbverlauf, Lichtkante und ein Licht, das dem Zeiger folgt --
und blieben Rechtecke mit Farbe darin. Es fehlten:
1. GEWICHT. Ein Ding, das auf etwas liegt, wirft einen Schatten, auch
wenn es niemand anfasst. Den gab es nur beim Ueberfahren.
2. MATERIALSTAERKE. Ein Blech hat oben eine Licht- UND unten eine
Schattenkante. Nur die obere ergibt einen aufgeklebten Strich.
3. KOERNUNG. Perfekt glatte Verlaeufe kommen in der Natur nicht vor,
und das Auge merkt das, ohne es benennen zu koennen. Drei Prozent
Rauschen genuegen -- aus einem SVG-Filter als Adresse, also ohne
Datei und ohne zusaetzliche Anfrage.
4. DURCHSICHT. Hinter den Kacheln liegt jetzt ein aufwendiges Bild.
Eine deckende Flaeche verdeckt es, eine mattierte nimmt seine Farbe
auf -- erst dadurch gehoeren beide zusammen.
Beim Ueberfahren wird die Kachel nicht heller, sondern kommt NAEHER:
Sie steigt, ihr Schatten wird groesser und weicher (der Abstand zum
Untergrund waechst). So verhaelt sich ein angehobener Gegenstand.
DIE ANMELDEKARTE: EIN GERAET STATT EINES BILDES AN DER WAND.
Sie sass mit Abstand in der gemalten Tafel -- zwei Rahmen ineinander,
dazwischen schwarze Leere. Jetzt geht sie bis unter das Gluehen des
Neonrahmens: Der Rahmen ist das Gehaeuse, die Karte der eingeschaltete
Bildschirm. Sie leuchtet von den Kanten herein in den Farben des Rahmens
(rot oben links, blau unten rechts), traegt eine Glasscheibe als sehr
schwache Spiegelung und dieselbe Koernung. Die Rollen sind Tasten
geworden: Materialstaerke oben hell, unten dunkel, beim Druecken sinken
sie ein, und die gewaehlte ist beleuchtet statt eingefaerbt.
Alle Angaben bleiben -- vier Rollen mit Beschreibung, Codefeld, Auge,
Rollenhinweis, Fusszeile. "Hochwertiger" heisst nicht "weniger drin".
EIN ECHTER FUND DABEI: --text-still lag ploetzlich bei genau 4,50:1
statt der noetigen 4,5. Der Ton war am 01.09. gegen die DAMALIGE,
dunklere Buehne gemessen. Wer den Hintergrund heller macht, muss die
leiseste Schrift nachziehen -- sonst haette man den Aufwand auch lassen
koennen. Erkannt daran, dass die Zahl sich bei zwei Schleier-Aenderungen
NICHT bewegte: Die Pruefung rechnet mit der CSS-Farbe.
Gemessen statt angesehen: Kontrast an echten Bildpunkten (pruef-buehne),
neun Bildschirmbreiten, drei Handygroessen, Ladezeit und Datenvolumen,
Klassen, Struktur, Startseite -- alles gruen. Die Seiten ueber dem
CLS-Zielwert sind nebenbei von sieben auf vier gesunken.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8107b97379 |
Die Kopfleiste wuchs beim Laden um vier Pixel -- und schob die Seite
Beim Messen des Datenvolumens nach dem Bildumbau fiel etwas anderes auf: Der Layout-Sprung auf der Startseite lag bei 0,99. Die Bilder waren es nicht -- ein Hintergrundbild liegt `position: fixed` und bewegt gar nichts. Die Meldung sagte es selbst, man musste nur hinsehen: ALLES sprang um denselben Betrag (295->301, 144->150, 685->692, 605->611). Wenn die ganze Seite gleichmaessig nach unten rutscht, waechst etwas ueber ihr. Gemessen: Leiste vor dem Skript 67 px, danach 71. Der Sicht-Umschalter kommt erst, wenn die Personenliste geladen ist, und ist mit 42 px das hoechste Teil in der Reihe. Vier Pixel -- man sieht sie kaum und merkt sie doch: Wer beim Laden schon zielt, klickt daneben. Die Loesung ist keine reservierte Hoehe auf Verdacht, sondern die Hoehe, die die Zeile ohnehin haben muss: `min-height: 44px`. Das ist das Mindestmass fuer ein Fingerziel (WCAG 2.5.8) und gilt hier sowieso fuer jedes Teil. Damit ist die Zeile immer so hoch wie ihr groesstes zulaessiges Element -- unabhaengig davon, ob dieses gerade schon da ist oder erst kommt. Ergebnis: 0,99 auf 0,60, und die Zahl der Seiten ueber dem Zielwert von zwoelf auf sechs. Datenvolumen unveraendert in Ordnung trotz der groesseren Bilder -- der Browser holt je Seite nur eine Stufe. Und der offene Punkt von vorhin ist geklaert: pruef-browser laeuft gruen durch, alle vier Maschinen (Chromium, Firefox, WebKit, WebKit auf dem iPhone), 64 Seitenaufrufe, 15898 Elemente. Der eine rote Punkt im Gesamtlauf war eine Zeitueberschreitung unter Dauerlast -- erkennbar daran, dass ZWEI Pruefungen gar nicht gelaufen waren und die Datei die doppelte Zeit brauchte. Eine gesunkene Anzahl ist ein eigener Befund. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
accf01b5d6 |
Sieben Motive statt einem -- und Bilder, die nicht mehr hochgerechnet werden
Filipe: "die grafik soll viieeeel besser aussehen bitte. die hintergrund
bilder sollen viel hochwertiger und spezieller aussehen."
DIE URSACHE WAR NICHT DIE BILDGUETE, SONDERN DIE GROESSE.
Sein Bildschirm ist 2550 px breit, das groesste ausgelieferte Bild war
1600 -- der Browser rechnet es also um das 1,6-fache hoch. Jede Kante
wird dabei weich, gleichmaessig ueber das ganze Bild. Genau das sieht
man als "billig", ohne benennen zu koennen, warum. Eine hoehere
WebP-Guete haette daran nichts geaendert: Man kann keine Bildpunkte
zurueckholen, die nie ausgeliefert wurden.
Anmeldeseite: jetzt 960 / 1280 / 1600 / 1920 / 2560, Guete 0,88.
Buehnen: jetzt 2400 (uhd) / 1600 (breit) / 900 (schmal).
Ueber srcset bzw. eine Fenstergroesse laedt trotzdem jeder nur die
Stufe, die er braucht -- ein Handy weiterhin 32 KB.
UND NEUN BUEHNEN ZEIGTEN DASSELBE BILD.
In start.css standen neun Regeln, eine je Szene -- alle zeigten auf
dieselbe Datei. Die Zuordnung war seit dem 01.09. richtig gedacht und
seit dem 03.09. wirkungslos. Aufgefallen ist es niemandem, weil jede
Seite fuer sich stimmig aussah; man merkt es erst, wenn man zwei
nebeneinander haelt. Jetzt hat jede Gruppe ihr eigenes Motiv, und die
Zuordnung folgt dem, was auf der Seite passiert:
studio Startseite Chili-Wasserfall, "More Than Media"
showbuehne Dashboard, Reports Spiegelkabinett -- viele auf einmal
portal LIVE, Content Splash mit IDEAS / BRAND / CONTENT
garage Aufgaben, Technik Kohle und Glut, Werkstatt
arena Dateien, Wissen Medaillon-Sammlung, ein Archiv
halle Profile, Schutz dieselbe Sammlung -- Personen, nicht
Betrieb
wald Start-Check, Scout roter Ahorn, etwas das waechst
skyline Kalender Podest unter dem Mond
lounge Calls, Chat dieselbe Nachtbuehne, ruhig
Sieben Motive auf neun Plaetze; die zwei Paare sind inhaltlich
benachbart und liegen nie nebeneinander auf einer Seite.
ABDUNKLUNG 0,42 -- gemessen, nicht uebernommen. Beim Tresorbild hatte
ich 0,62 aus den alten Szenen uebernommen, und uebrig blieb ein Schemen.
pruef-buehne rechnet den Kontrast an echten Bildpunkten nach: 4,69 bis
7,14 gegen die noetigen 4,5, an bis zu 28 Stellen je Seite.
Die Groessenpruefung in pruef-struktur bekommt eine begruendete Ausnahme
fuer GESTUFTE Bilder: Bei einer Datei, von der der Browser immer nur
eine von drei Stufen holt, misst eine feste 200-KB-Grenze das Falsche.
Sie gilt unveraendert fuer alles andere -- und die Ausnahme prueft
zusaetzlich, dass die kleineren Stufen wirklich existieren, damit sie
niemand als Schlupfloch benutzt.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
44b3290bc5 |
Die Kopfleiste: nicht die dritte Zahl, sondern gar keine
BEFUND. Der Gesamtlauf war nach dem Bildumbau bei SIEBZEHN Dateien rot,
pruef-handy allein mit 37 Fehlern. Alle mit derselben Meldung:
"ueber=126px". Eine Ursache, siebzehnfach gezaehlt.
Sie war meine. Um den Layout-Sprung bei 1280 px zu beheben, hatte ich
den Umbruch der aeusseren Leiste wieder auf "nur unter 380 px" gestellt
-- und damit bei 390 und 412 px genau das Loch aufgerissen, das ich
Stunden vorher geschlossen hatte. Dieselbe feste Schwelle von 380, ueber
die zwei Commits vorher eine Regel in CLAUDE.md gewandert ist.
DREI ANLAEUFE, und die ersten beiden waren Symptomkur:
1. `flex: 0 0 auto` fuer die Bedienelemente -> 126 px Ueberstand bei
412 px (sie koennen weder schrumpfen noch umbrechen).
2. Hoher Schrumpf-Faktor am Schriftzug (220 gegen 1) -> besser, aber
von 19 fehlenden Pixeln nahmen die Knoepfe 0,19, und die runden auf
1 auf. Ein Pixel, und die Gruppe brach um. Ich habe daraufhin die
Abstaende verkleinert; danach war es wieder genau ein Pixel. Wer an
einem Rundungsfehler schraubt, hat die falsche Stellschraube.
3. RICHTIG: dem Schriftzug gar keine Wunschbreite geben.
`flex: 1 1 0` heisst "ich beanspruche nichts und nehme, was uebrig
bleibt". Damit entsteht ueberhaupt kein Fehlbetrag, der verteilt
werden muesste. Kein Schrumpf-Faktor, keine Schwelle, nichts zu
runden. Dazu `max-width: max-content`, sonst zieht `flex-grow` die
Marken-Pille ueber die ganze Leiste (990 statt 375 px) -- wovor der
Kommentar zwei Zeilen darueber ausdruecklich warnt und was ich beim
Umbau uebergangen habe.
Gemessen ueber neun Breiten: 1920 bis 768 einzeilig (71 px), 412 und 390
zweizeilig (127), 320 dreizeilig (167). Ueberstand ueberall null. Und der
Layout-Sprung von 0,94 ist damit auch weg -- er kam aus derselben Ecke.
Dabei drei weitere echte Fehler gefunden, alle in Neuem von heute:
* Der Namenslink in der Fruehwarnung war 22x25 px -- unter dem
Mindestmass von 24x24 (WCAG 2.5.8). Bei kurzen Namen trifft man
daneben. Jetzt ein echtes Fingerziel mit negativem Aussenabstand, der
die Polsterung optisch wieder aufhebt.
* Die Warnkarten standen bei 320 px 9 px aus dem Bild:
`minmax(320px, 1fr)` begrenzt die Spalte, nicht ihren Inhalt. Erst
`min(320px, 100%)` PLUS `min-width: 0` PLUS umbrechender Kopf loesen
es -- einzeln keines davon. Die Schreibweise stand zwei Abschnitte
weiter oben laengst richtig da.
* Der Zurueck-Link im Schriftzug ragte aus seinem Kasten:
`overflow: hidden` schneidet nur die ANZEIGE ab, der Link behaelt
seine Layoutbreite. Bei 768 px lag sein Mittelpunkt unter den
Bedienelementen -- ein Klick dorthin traf das Falsche, auf 17 von 18
Seiten, und zu sehen war davon nichts.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
aa1d05a5c0 |
Neues Anmeldebild -- die Karte sitzt IN der gemalten Tafel
Filipe: "integriere die zugangskachel links nach rechts und passe sie
perfekt an damit sie in dem neuen bild rechts perfekt und die
vorgemachte kachel passt."
Das neue Motiv (Spicy Media x DogFather) hat rechts eine leere Tafel mit
Neonrahmen. Die Anmeldekarte sitzt jetzt DARIN -- und zwar wirklich
darin, nicht ungefaehr in der Gegend.
DAS PROBLEM, DAS MAN LEICHT UEBERSIEHT: Das Bild liegt mit
`object-fit: cover` unter der Seite; je nach Fensterform schneidet der
Browser oben/unten oder links/rechts etwas ab. Ein `left: 58%` bezieht
sich aber auf das FENSTER. Auf genau einer Bildschirmgroesse saehe es
richtig aus und ueberall sonst falsch. Deshalb rechnet `.tafel-anker`
dieselbe Cover-Formel noch einmal nach und ist damit deckungsgleich mit
dem Bild -- Prozentwerte darin sind Prozent DES BILDES.
Die vier Zahlen sind GEMESSEN (tools/gate-bauen.mjs), nicht geschaetzt.
Zwei Anlaeufe standen daneben und haben sich selbst verraten:
1. "Suche den leuchtenden Rahmen" fand den Mond, die roten Blueten und
jede Spiegelung -- Ergebnis: die ganze rechte Bildhaelfte. Eine
Messung, die das Offensichtliche zurueckgibt, hat nichts gemessen.
2. "Suche die groesste dunkle Flaeche" fand die Breite richtig, aber
94 % Hoehe: Ueber und unter der Tafel ist die Szene genauso
schwarz.
Richtig ist der dritte Weg: vom Mittelpunkt der Tafel nach aussen
laufen, bis es hell ODER farbig wird -- auf diesem Weg liegt nichts
anderes, denn die Tafel ist leer. Danach eine Plausibilitaetspruefung,
die abbricht statt vier geratene Zahlen auszugeben.
DREI FEHLER IM EIGENEN ENTWURF, alle gemessen statt angesehen:
* Die Karte hing 300 px unter dem Bildschirmrand. Auf `.tafel` liegt
die Einblend-Animation, deren Endbild `transform: none` ist -- mein
`translateY(-50%)` war damit wirkungslos. Zwei Wege, dasselbe
Element zu verschieben, vertragen sich nicht.
* Der Anker lag 3 % neben dem Bild: Das Bild traegt `scale(1.03)` als
Reserve fuer die Parallaxe. Jetzt tragen beide dieselbe Verwandlung,
und die Parallaxe laeuft ueber zwei CSS-Groessen am <body> -- so
wandert die Karte mit, statt dass der Rahmen unter ihr wegrutscht.
* Der Hochkant-Ausschnitt zeigte die LEERE Tafel: ein schwarzes
Rechteck mit ein paar Saeulen. Auf dem Handy liegt die Karte ohnehin
davor; dort gehoert das Logo hin. Jetzt faellt der Schriftzug
SPICY MEDIA in den sichtbaren Streifen -- nachgerechnet, nicht
probiert.
STARTSEITE: das Tresorbild als neuer Hintergrund. Die uebernommene
Abdunklung von 0,62 war zu viel (der Tresor ist von Haus aus dunkel) --
uebrig blieb ein Schemen. Und der "Leseweg" verdunkelte ausgerechnet die
MITTE: Bei den alten Szenen stand dort nichts, beim Tresor steht dort
die Tuer. Beides korrigiert und mit pruef-buehne an echten Bildpunkten
nachgemessen.
DABEI GEFUNDEN, ohne Zusammenhang mit dem Bild: Der abgeschaltete
"Ueberfaellig"-Filter kam auf 4,05:1 statt 4,5:1. Die Deckkraft zu
erhoehen half nichts -- die Pruefung rechnet mit der CSS-FARBE und dem
gemessenen Bildpunkt dahinter, und ein `opacity` am Elternknopf aendert
die Farbe nicht. Die Zahl blieb dreimal exakt gleich; genau das war der
Hinweis. Jetzt ein eigener, hellerer Ton. Der Kommentar daneben sagte
ohnehin, was gewollt ist: Man SOLL sehen, dass es null sind.
Und die vier Regeln von heute stehen in CLAUDE.md.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
70039714c5 |
Die Sicherung war zwei Loecher gross -- gefunden, weil sie zum ersten Mal wirklich zurueckgespielt wurde
"Wir haben eine Sicherung" war bis heute ein Satz, kein Nachweis. Die
taegliche Kopie ausserhalb des Servers prueft `PRAGMA integrity_check`
und meldet seit dem 31.08. jeden Tag "in Ordnung". Das heisst: die Datei
ist nicht zerschossen. Es heisst NICHT, dass man damit weiterarbeiten
kann.
tools/wiederherstellung-proben.mjs geht den Weg jetzt wirklich: juengste
Sicherung in ein Wegwerf-Verzeichnis kopieren, die echte Anwendung
dagegen starten (damit laufen alle Schemawanderungen durch), vorher und
nachher zaehlen, anmelden, jede Seite aufrufen. Drei Ausgaenge, nicht
zwei -- "konnte nicht nachsehen" ist weder Erfolg noch Fehler.
BEIM ERSTEN LAUF BLIEB GENAU EINE VON ACHTZEHN SEITEN ROT: der
Steckbrief, mit einem 404 fuer ein Bild. Daran hingen zwei echte Luecken:
1. PROFILBILDER WAREN NIE GESICHERT. sicherung-holen.sh holte
dateien/ und wissen/ -- die Bilder liegen aber in einem dritten
Ordner (profilbilder/, siehe workspace-steckbrief.js). Nach einem
Plattenausfall waeren alle Profilbilder weg gewesen, waehrend die
taegliche Meldung weiter "in Ordnung" sagte. Sie hat ja nie
behauptet, vollstaendig zu sein.
2. DIE RUECKMELDUNG AN DEN SERVER LIEF INS LEERE. Das Skript meldete
sich bei dogfather-universe.com/workspace/... -- seit dem Umzug am
06.09. antwortet diese Adresse mit 410 "Gone". Der Server erfuhr
also seit dem Umzug nicht mehr, dass die Kopie laeuft; auf der
Automationen-Seite waere sie mit jedem Tag aelter erschienen,
obwohl sie taeglich lief. Ein 410 wird jetzt eigens gemeldet -- es
heisst etwas anderes als "Netz kaputt", naemlich "die Adresse
stimmt nicht mehr".
Beides behoben. Und damit es kein drittes Mal passiert, vergleicht die
Probe die Ordnerliste des Sicherungsskripts gegen die Ordner, die der
Server im Quelltext wirklich benutzt (`join(DATEN_ORDNER, "...")`). Wer
morgen einen vierten Datenordner anlegt und ihn nicht sichert, bekommt
hier einen Fehler statt eines stillen Lochs -- mit Gegenprobe, dass der
Vergleich einen fehlenden Ordner auch wirklich erkennt.
Ergebnis nach den Reparaturen: 18 Pruefungen, alle gruen,
"DIE SICHERUNG LAESST SICH ZURUECKSPIELEN." Der Lauf traegt sich mit
Datum in die Sicherungsablage ein -- sonst weiss beim naechsten Mal
niemand, wann zuletzt wirklich zurueckgespielt wurde.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
bede91921d |
Der sechste Bereich, und zwei Pruefungen, die den Lauf lahmgelegt haben
DER AGENTUR-BEREICH (Stufe 4 des Plans)
Kernprinzip 04 des Konzepts lautet woertlich "Die Agentur bleibt
angebunden" -- und dafuer gab es bis heute nichts. Fuenf Bereiche
standen, der sechste fehlte vollstaendig. Damit stand nirgends, welche
Kampagne laeuft, welche Schulung ansteht und wie ein Anliegen an die
Agentur ausgegangen ist. Das lief ueber private Nachrichten: nicht
auffindbar, nicht nachvollziehbar, beim naechsten Mal von vorn.
Vier Arten, und die vierte ist der Punkt: kampagne, schulung, anliegen
und ZUSTAENDIGKEIT. Die letzte ist keine Verlegenheit, sondern das, was
das Konzept ausdruecklich fordert -- Betreuung und Umsetzung sind unsere
Seite, offizielle Wege sind Agenturseite. Solange das nur im Kopf steht,
wird es bei jedem Streitfall neu verhandelt.
Der Umbau war das eigentliche Risiko, nicht der Bereich: Ein CHECK
laesst sich in SQLite nicht aendern, die Tabelle muss neu gebaut werden
-- und dabei werden ALLE vorhandenen Eintraege umgeschrieben. Deshalb
geht pruef-agentur.mjs (31 Pruefungen) den Weg wirklich: Sie baut eine
Datenbank im ALTEN Stand nach, fuellt sie mit allen fuenf Bereichen,
laesst die echte Anwendung darueberlaufen und zaehlt danach jede Zeile
UND jedes Feld nach -- auch die seltenen Spalten (hook, creator_extern),
die man beim Abschreiben des Bauplans vergisst. Wichtigste Gegenprobe:
Der CHECK muss danach noch BEISSEN. Eine Umstellung, die nebenbei die
Schranke entfernt, sieht aus wie ein Erfolg und ist der schlimmere
Ausgang.
Nebenbei drei abgeschriebene Bereichslisten beseitigt (Wochenbericht,
Suche, Report-Ziele). Im Wochenbericht waere der neue Bereich sonst
schlicht nicht vorgekommen -- ohne Fehler, ohne Luecke, einfach nicht da.
ZWEI PRUEFUNGEN, DIE DEN GESAMTLAUF ZUM STILLSTAND BRACHTEN
pruef-call-kategorien.mjs hing DREI STUNDEN. Ursache war ein Zeitzuender
in ihr selbst: Sie legte Calls auf "heute 18:00" und erwartete zwei
davon unter "Heute". Ab 18 Uhr sind die vorbei, der Server schiebt sie
nach "Protokoll fehlt", und die Oberflaeche unterteilt erst ab FUENF
anstehenden. Uebrig blieben vier, die Bloecke verschwanden, und die
Pruefung wartete auf einen Klick auf einen Block, den es nicht gab.
Genau die Sorte Fehler, vor der die Projektnotiz vom 06.09. warnt: Sie
war um 17:59 gruen und um 18:01 rot, ohne dass sich am Code etwas
geaendert hatte. Jetzt liegen alle Zeiten RELATIV zu jetzt, und die
Erwartung wird mit derselben Vorschrift gerechnet, die calls.js benutzt
-- statt Zahlen, die nur zu einer bestimmten Tageszeit stimmen.
Und der Grund, warum daraus ein Stillstand statt eines Fehlers wurde:
index.js setzt bewusst zwei Auffangnetze (uncaughtException,
unhandledRejection). Fuer den Betrieb richtig -- ein Fehler darf die
Website nicht offline nehmen. Fuer eine Pruefung fatal: Sie importiert
index.js in denselben Prozess und erbt die Netze. Ihr eigener Absturz
wird dann nur protokolliert, und der Express-Server haelt den Prozess
danach ewig am Leben. Kein Fehler, kein Ergebnis, kein Ende.
Deshalb zwei Abhilfen, die zusammengehoeren:
* server/helfer-notbremse.mjs -- haengt eigene Zuhoerer DANEBEN
(process.on ergaenzt, es ersetzt nicht) und beendet den Lauf mit
Fehler; dazu ein Wecker. In alle 42 Browserpruefungen eingebaut.
Der Betrieb bleibt unveraendert.
* tools/alles-pruefen.mjs gibt jeder Datei eine Frist von 600 s. Wer
sie reisst, wird abgebrochen und ZAEHLT ALS FEHLGESCHLAGEN, mit der
letzten Ausgabe davor als Beleg. Einzelne Dateien nachzuruesten hilft
nur bis zur naechsten ohne Notbremse -- deshalb sitzt sie dort, wo
sie fuer alle gilt, auch fuer die, die es noch nicht gibt.
AUSSERDEM: pruef-breiten.mjs pruefte 16 Seiten aus einer Liste von Hand,
chat.html und leistung.html fehlten darin. Der Chat war bei keiner
einzigen der neun Breiten je gemessen worden. Wie bei pruef-handy kommt
die Liste jetzt aus dem Verzeichnis.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
80a8aac774 |
Der ganze Prueflauf blieb am Chat-Strom stehen -- behoben
BEFUND. Seit der Chat am 06.09. dazukam, LIEF DER GESAMTE
REGRESSIONSLAUF NICHT MEHR DURCH. Nicht "er wurde rot" -- er blieb
einfach stehen, bei Datei 3 von 62, ohne Fehlermeldung, ohne FEHL, ohne
Absturz. Nach zwoelf Minuten stand er immer noch dort. Von aussen sieht
"noch nicht fertig" genauso aus wie "haengt fuer immer"; deshalb ist
mir das gestern nicht aufgefallen, sondern erst, als ich den Lauf
gezielt beobachtet habe.
DIE URSACHE. pruef-alle-wege.mjs geht stumpf ueber ALLE 134
Schnittstellen und liest jede Antwort mit `await a.text()` aus. Der
Chat haelt seine Verbindung aber absichtlich offen und schickt neue
Nachrichten hinein, solange jemand zusieht (SSE). `text()` wartet, bis
der Server fertig ist -- und der wird nie fertig. Angemeldet als
DogFather trat der Lauf dort ein und kam nicht wieder heraus.
DIE ABHILFE, zwei Teile, die zusammengehoeren:
* Jeder Ruf hat jetzt eine Frist von 8 s. Laeuft sie ab, ist das ein
ERGEBNIS ("hing") und kein Absturz. Ein neuer Abschnitt meldet am
Ende, WELCHER Weg nicht geantwortet hat -- statt dass der Lauf
wortlos stehenbleibt.
* Bekannte Stroeme stehen in einer Liste MIT BEGRUENDUNG und werden
nicht uebersprungen, sondern anders geprueft: verbinden, Status
ablesen, abbrechen. Die Schranke wird damit genauso gemessen wie
ueberall. Zusaetzlich wird nachgemessen, dass ein eingetragener
Strom auch wirklich offen bleibt -- sonst verdeckte die Ausnahme
nur seine Inhaltspruefung.
Der "hing"-Zustand musste eigens gesammelt werden: In Abschnitt 1 haette
er ausgesehen wie "ohne Anmeldung erreichbar", in Abschnitt 2 waere er
ganz durchgefallen (`"hing" >= 500` ist false, Zeichenkette gegen Zahl).
Genau so verschwinden Befunde.
Ergebnis: 134 Schnittstellen, 532 Aufrufe, alles gruen, kein Haenger.
AUSSERDEM, gefunden beim Nachsehen:
* pruef-handy.mjs pruefte 15 Seiten -- aus einer Liste von Hand, die
veraltet war. chat.html, leistung.html und steckbrief.html standen
nicht darin: DREI von neunzehn Seiten waren nie auf einem Handy
gemessen worden, ausgerechnet der Chat. Die Liste kommt jetzt aus
dem Verzeichnis, die naechste neue Seite ist von selbst dabei.
* chat.html und leistung.html fehlte <link rel="manifest">. Auf dem
Handy heisst das: Wer die App installiert hat und ueber eine
Benachrichtigung dort landet, verlaesst den App-Rahmen -- die Seite
oeffnet im Browser, mit falscher Leistenfarbe. Ihre theme-color war
ausserdem eine andere als auf allen uebrigen Seiten. Beides behoben
UND als Pruefung in pruef-struktur nachgetragen, damit es beim
naechsten Mal nicht am Gedaechtnis haengt.
NEU: tools/wiederherstellung-proben.mjs — die Probe aufs Exempel.
Die Sicherung ausserhalb des Servers laeuft taeglich und prueft
`integrity_check`. Das sagt: die Datei ist nicht zerschossen. Es sagt
NICHT, ob die Anwendung damit startet, ob man sich anmelden kann und ob
die Daten vollstaendig sind. Eine Sicherung, die man nie zurueckgespielt
hat, ist eine Hoffnung. Das Werkzeug kopiert die juengste Sicherung in
ein Wegwerf-Verzeichnis, startet die echte Anwendung dagegen (damit
laufen alle Schemawanderungen wirklich durch), zaehlt vorher und
nachher, meldet sich an und ruft jede Seite auf. Drei Ausgaenge, nicht
zwei -- "konnte nicht nachsehen" ist weder Erfolg noch Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
953c3f5721 |
Zahlen bekommen eine Oberflaeche, das Dashboard bekommt Zahlen
Der Server konnte seit gestern rechnen -- und niemand konnte etwas
eintragen. Ein Rechenwerk ohne Oberflaeche ist kein Modul, sondern ein
Versprechen. Das ist jetzt eingeloest:
* leistung.html: Wochenkarten (Wert, Vergleich zur Vorwoche,
Verlaufslinie), Ziele als Fortschrittsbalken, die letzten 14 Tage
zum Eintragen -- auch die LEEREN, denn eine Luecke ist selbst die
Auskunft. Import aus dem TikTok-Export mit Vorschau VOR dem
Schreiben.
* Kachel "Zahlen" als erste der Gruppe "Rund um den Creator", eigenes
Zeichen (steigende Linie, kein zweites Balkendiagramm).
* Dashboard: jede Creator-Karte traegt jetzt Diamanten, LIVE-Tage und
Verweildauer. Bis heute zeigte sie ausschliesslich ARBEIT -- ein
Creator konnte null ueberfaellige Aufgaben haben und gleichzeitig
seit drei Wochen einbrechen, und die Karte sah tadellos aus.
* Die Fruehwarnung steht oben im Dashboard. Sechs benannte Signale im
Klartext mit Beleg, bewusst OHNE Punktzahl -- ein Wert wie
"Abwanderungsrisiko 73" klingt nach Wissenschaft und ist eine
Behauptung, der man nicht widersprechen kann.
* chat.html?mit=<person>: der Weg von der Warnung ins Gespraech. Gab
es vorher nicht; ein Hinweis ohne Weg dahin ist nur ein schlechtes
Gewissen.
GEFUNDEN VON DEN PRUEFUNGEN, nicht von der Theorie:
1. Die Verlaufslinie zeichnete fuer vier der sieben Groessen NICHTS.
Der Server liefert im Verlauf nur drei Reihen; fuer den Rest kam
undefined an. `=== null` faengt das nicht, Number(undefined) ist
NaN, und ein <polyline points="NaN,NaN"> ist im DOM vorhanden und
auf dem Bildschirm unsichtbar -- ohne Fehlermeldung. Die Pruefung
misst deshalb die PUNKTE, nicht die Anwesenheit des Elements.
2. Fuenf Schriftgroessen im CHAT lagen unter 11,5 px (.68/.7 rem) und
waren seit vorgestern drin. Die Grundlinie der Groessenpruefung
stand auf 43, gemessen wurden 48. Nicht die Grundlinie angehoben,
sondern die fuenf Stellen behoben: Eine Grundlinie, die mitwaechst,
ist keine mehr.
pruef-leistung-optik.mjs: 57 Pruefungen, zwei echte Browser, Gegenprobe
zu jeder Aussage -- auch dazu, dass die Vorschau vor dem Bestaetigen
wirklich noch nichts geschrieben hat und dass ein Creator seine Zahlen
zwar SIEHT, sie aber weder eintragen noch die Fruehwarnung ueber sich
lesen kann (auch nicht ueber eine von Hand gebaute Anfrage).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
c8a4e7628c |
Stufe 1+2: Zahlen ueber das Geschaeft, und eine Fruehwarnung
Der grosse Befund aus dem Plan vom 31.08.2026: Der Workspace organisiert ARBEIT hervorragend, wusste ueber das GESCHAEFT aber nichts. Keine Diamanten, keine LIVE-Tage, keine Verweildauer. Damit hing die ganze Betreuung in der Luft -- der Start-Check bewertete ohne zu messen, der Report fragte "was hat funktioniert" ohne Beleg, das 90-Tage-Ziel war ein Satz statt eines Fortschritts. STUFE 1 -- LEISTUNG Eine Zeile je Creator und TAG (nicht Woche: Feineres laesst sich immer zusammenfassen, Groeberes nie aufteilen). Diamanten, LIVE-Dauer, gueltiger Tag, Zuschauer im Schnitt und in der Spitze, Verweildauer, Schenker, neue Follower -- und eine NOTIZ. Ohne sie sieht man in drei Monaten einen Einbruch und weiss nicht mehr, dass die Person Grippe hatte. DIE VERWEILDAUER IST DIE LEITZAHL (Recherche 06.09.2026): 2026 haengt der Algorithmus alles an der Completion Rate, und sie gehoert als BETRIEBSkennzahl behandelt -- sie soll die naechste Runde steuern, nicht die letzte erklaeren. Jede Zahl kommt mit Vergleich, Verlauf und Einordnung. Eine Zahl ohne diese drei ist eine Eitelkeitszahl: Sie sieht nach Auskunft aus und ist keine, weil man nichts entscheiden kann. Zwei Wege hinein: Schnelleingabe und CSV-Import aus dem offiziellen Export, mit Vorschau vor dem Uebernehmen. STUFE 2 -- FRUEHWARNUNG Sechs benannte Signale (Zahlen fallen, LIVE-Tage brechen weg, lange nicht angemeldet, kein Gespraech, Aufgabenstau, Start-Check haengt) und daraus EIN ruhiger Satz: "Bei Nora wuerde ich diese Woche nachfassen." BEWUSST KEIN SCORE. Eine Note von 1 bis 100 wirkt objektiv und ist es nicht; sie verfuehrt dazu, Menschen nach einer Zahl zu behandeln. Am Score kann man nichts tun, am Signal schon. Deshalb Saetze statt Punkte, und jedes Signal einzeln nachvollziehbar. Ein CREATOR sieht die Fruehwarnung nicht: Das ist eine Arbeitsgrundlage fuer die Betreuung, keine Mitteilung an die betroffene Person. ZWEI ECHTE FEHLER, VON DER PRUEFUNG GEFUNDEN 1. ZAHLENFORMAT, Faktor tausend daneben. "1.250" wurde als 1,25 gelesen und "1,234" als 1,234. Die Regel "das letzte Trennzeichen ist das Dezimalzeichen" liefert bei nur EINEM Trennzeichen fuer beide Faelle das Falsche -- und die Zahl sieht danach trotzdem plausibel aus. Jetzt entscheidet, wie viele Ziffern dahinter stehen: genau drei heisst Tausendertrenner. 2. DIE ZIELE-ROUTE WURDE VERSCHLUCKT. Express nimmt die erste passende Route, und `:tag` passt auch auf "ziele" -- ein PUT auf .../ziele landete in der Tages-Route und scheiterte am Datumsmuster. Die Meldung sagte "ungueltig", was auf die Zahlen deutet, nicht auf den Weg. Reihenfolge getauscht. Beides waere still gewesen: falsche Zahlen sehen richtig aus, und ein Ziel, das sich nicht setzen laesst, probiert man zweimal und laesst es dann. pruef-leistung.mjs: 47 Punkte, darunter jede Rechnung einzeln nachgerechnet (Durchschnitte ohne Tage ohne Wert, Prozent von null, Wochengrenzen), Import zweimal eingelesen, deutsche und englische Zahlenformate, Rechte, und die Gegenprobe, dass die Fruehwarnung bei Unauffaelligkeit SCHWEIGT. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
9dc35f5da6 |
Chat wieder einhaengen -- die Datei ist jetzt da
Nachtrag zu |
||
|
DogFatherGitandClaude Opus 5
|
686249e36c |
Und die restlichen 40 Pruefbilder
Der erste Durchgang hat nur 62 von 102 erwischt. Grund: Die Liste kam
aus `path: "..."` -- Bilder, deren Name aus einem Template-Literal oder
einer Variablen entsteht, standen nicht darin:
path: breite === 1440 ? "pruef-kalender-computer.png" : "…-handy.png"
path: `pruef-rollen-${r.rolle}.png`
Danach war die Kontrolle entscheidend, nicht die Erfolgsmeldung: "0
Pruefbilder versioniert" -- es waren noch 40. Wer nach einem
Aufraeumen nicht nachzaehlt, glaubt der Absicht statt dem Ergebnis.
Vor dem Entfernen noch einmal im GANZEN Repo geprueft (nicht nur in
server/ und tools/, wie beim ersten Mal): Kein readFileSync, kein
existsSync, kein readFile auf eine .png-Datei. Sie werden ueberall nur
geschrieben.
Kontrolliert danach: 0 Pruefbilder versioniert, QR-Codes weiterhin 3.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
1f4717d683 |
Bilder der Pruefungen aus der Versionierung nehmen
62 Bildschirmfotos, 54 MB, die bei JEDEM Prueflauf neu geschrieben
werden. Sie standen im Repo und tauchten dadurch bei jedem Commit als
Aenderung auf -- man haette sie mitcommittet oder jedes Mal von Hand
aussortiert. Beides ist Ballast, und beides passiert irgendwann falsch.
Sie bleiben auf der Platte und werden weiter erzeugt. Nur versioniert
sind sie nicht mehr.
GEPRUEFT VOR DEM ENTFERNEN: Keine einzige Pruefung LIEST je ein Bild --
kein readFileSync, kein existsSync auf .png; sie werden ausschliesslich
geschrieben. Es sind also Ansichtsbilder, keine Vergleichsvorlagen,
deren Verlust eine Pruefung blind machen wuerde. Waeren es welche,
duerften sie nicht weg.
UND EIN BEINAHE-FEHLER, der hier festgehalten gehoert: Der erste Anlauf
nahm "alle .png ausser workspace/assets und assets/img". In dieser
Liste standen assets/qr/qr-instagram.png und zwei weitere QR-Codes der
Website -- echte Dateien, die niemand neu erzeugt. Ein zu grobes Muster
haette sie mitgeloescht.
Die Liste kommt deshalb jetzt aus der Quelle statt aus einem Muster:
Was in einem `screenshot({ path: ... })` einer Pruefdatei steht, kann
weg. Alles andere nicht. Kontrolliert danach: QR-Codes (3) und
Website-Bilder (105) sind unveraendert versioniert.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
3bab6d9fbf |
Der Knopf auf der Umzugsseite ist jetzt ein echter Verweis
Hinweis von Filipe: Wenn etwas wie ein Knopf aussieht, muss man auch
draufdruecken koennen. Er hatte recht.
Meine urspruengliche Begruendung - die Adresse solle nur zum Lesen
dastehen, damit niemand versehentlich ein Lesezeichen auf den alten Weg
setzt - traegt nicht: Wer klickt, landet auf der NEUEN Adresse und setzt
sein Lesezeichen genau dort. Ein Element, das wie ein Knopf aussieht und
sich nicht wie einer verhaelt, ist eine Falle.
Der Knopf hat jetzt einen Hover- und einen Tastatur-Fokuszustand, und
beide Bewegungen entfallen bei prefers-reduced-motion.
Die Pruefung geht dabei einen Schritt weiter als vorher: Sie prueft nicht
mehr nur, WELCHE Anfragen zugeordnet werden, sondern ruft die Middleware
wirklich auf und sieht sich die ANTWORT an. Denn die Zuordnung kann
stimmen und die Seite trotzdem kaputt sein:
- ein Platzhalter, der woertlich in der Seite steht statt eingesetzt zu
werden
- ein Knopf ohne Verweis (genau der Fall, den Filipe gemeldet hat)
- HTML statt JSON fuer /workspace/api/ - ein noch offener Tab wuerde
sonst die Hinweisseite als Daten zu lesen versuchen
- und die wichtigste: dass die NEUE Adresse durchgelassen wird
31 Pruefungen, alle gruen. Gegenprobe gemacht: Dreht man den Knopf zurueck
zu einem div ohne Verweis, meldet die Pruefung 2 Fehler - sie haette den
gemeldeten Mangel also selbst gefunden.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8e3eccc7a8 |
Alte Workspace-Adresse abgeschaltet statt weitergeleitet
Auf Filipes Wunsch: dogfather-universe.com/workspace/ soll nicht mehr existieren, er gibt den neuen Link selbst an Creator und Scouts weiter. Vorher stand dort eine Weiterleitung - die haette die alte Adresse auf unbestimmte Zeit am Leben gehalten. Der Server antwortet dort jetzt mit 410 Gone. Beides - 404 und 410 - heisst "gibt es hier nicht"; 410 sagt zusaetzlich "gab es, ist absichtlich weg, kommt nicht wieder". Genau der Sachverhalt. Suchmaschinen nehmen die Adresse dadurch schneller heraus, und in einem Protokoll ist ein 410 sofort als gewollt erkennbar, waehrend ein 404 immer nach Versehen aussieht. Statt einer nackten Fehlermeldung kommt eine kurze Hinweisseite mit der neuen Adresse. Wer hier landet, hat einen alten Link oder eine alte Verknuepfung und soll erfahren, wohin der Workspace gezogen ist, statt vor einem leeren Fenster zu sitzen. Bewusst OHNE Verweis zum Anklicken, damit niemand aus Versehen ein neues Lesezeichen auf den alten Weg setzt. Schnittstellen-Aufrufe unter /workspace/api/ bekommen JSON statt HTML - ein alter, noch offener Browser-Tab wuerde sonst die Hinweisseite als Daten zu lesen versuchen und einen unverstaendlichen Fehler zeigen. Die Pruefung deckt weiterhin 21 Faelle ab und ist mitgezogen: Der gefaehrlichste Fall heisst jetzt nicht mehr "Endlosschleife", sondern "die neue Adresse mit abschalten" - wer nicht auf den Hostnamen prueft, sperrt den Workspace fuer alle aus. Alle gruen, Gegenprobe schlaegt an. Diesmal vor dem Commit den Diff Datei fuer Datei kontrolliert - beim letzten Mal hatte ich hier eine fremde uncommittete Zeile mitgenommen und damit die Website fuer zwei Minuten abgeschossen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
09a4cfdeab |
AUSFALL BEHOBEN: versehentlich mitcommitteten Import zurueckgenommen
Die Website war ab 16:27 unerreichbar (HTTP 502, 29 Neustartversuche).
Ursache war mein Commit
|
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
58b8ef233a |
Creator Workspace zieht auf eine eigene Adresse um
Der Workspace laeuft ab sofort auf workspace.dogfather-universe.com. Die
alte Adresse dogfather-universe.com/workspace/ leitet dorthin weiter.
Grund: Chrome laesst neben der Hauptseite, deren Bereich "/" die ganze
Domain umfasst, keine zweite App auf derselben Adresse zu. Unter dem alten
Pfad liess sich der Workspace nur als Verknuepfung ablegen, nie als
richtige App installieren - im Menue stand "Oeffnen in DOGFATHER
UNIVERSE" statt "Seite als App installieren". Das ist kein Fehler,
sondern Absicht (w3c/manifest Nr. 1180: verschachtelte Bereiche auf einem
Ursprung sind "strongly not recommended"). Auf der neuen Adresse hat
Filipe die App erfolgreich installiert.
Der PFAD /workspace/ bleibt erhalten. An ihm haengen 150 Server-Routen,
107 API-Aufrufe und 26 Server-Dateien - ihn wegzuschneiden waere ein
grosser Umbau ohne Gewinn, denn der Konflikt entsteht durch die
gemeinsame ADRESSE, nicht durch den Pfad. Dadurch musste am Code nichts
weiter geaendert werden.
Die Entscheidung steht in einer eigenen Datei (workspace-umzug.js), weil
sie zwei Stellen hat, an denen ein Denkfehler teuer waere und die man
einer Bedingung nicht ansieht:
1. ENDLOSSCHLEIFE - derselbe Dienst bedient beide Adressen. Ohne
Hostpruefung leitet die neue Adresse auf sich selbst, und der
Workspace waere sofort nach dem Neustart fuer alle unerreichbar.
2. PRAEFIX-IRRTUM - "faengt an mit /workspace" trifft auch
/workspaceXYZ und /workspace-alt.
Als eigene Funktion ist beides pruefbar, ohne den Server zu starten:
pruef-workspace-umzug.mjs deckt 21 Faelle ab (alte/neue Adresse, mit und
ohne www, Gross-/Kleinschreibung, Portangabe, lokale Testadressen, beide
Praefix-Fallen). Alle gruen. Gegenprobe gemacht: Baut man die
Endlosschleife absichtlich ein, meldet die Pruefung 3 Fehler; baut man den
Praefix-Irrtum ein, meldet sie 2. Sie kann also auch "nein" sagen.
Bewusst 302 und nicht 301: Ein 301 wird vom Browser dauerhaft gemerkt und
laesst sich praktisch nicht zurueckholen - waere an der Umleitung etwas
falsch, waere die alte Adresse fuer jeden, der sie einmal aufgerufen hat,
dauerhaft unbrauchbar.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e0d8e6d55d |
Tagesblick: Termine als Karten, und vier Fehler, die dabei auffielen
Filipe zu der Liste mit einem einzigen Termin darin: "das soll viel
geiler und krasser aussehen bitte."
Er hatte recht, und der Grund war der Einzelfall. Ein Zeitstrahl lebt
davon, dass er etwas VERBINDET -- bei einem Eintrag verbindet er nichts.
Uebrig blieben eine magere Zeile, ein Strich ins Leere und Weissraum bis
zur Plakette am rechten Rand.
Jetzt traegt jede Karte fuer sich: eigene Flaeche mit farbiger Kante,
die Uhrzeit gross und in der Farbe der Terminart (vorher war sie
kleiner als der Titel -- dabei ist sie das, was man sucht), ein Balken
fuer die Dauer, und "JETZT" am naechsten Termin statt eines etwas
helleren Hintergrunds. Erledigtes bekommt einen Haken und verliert die
Farbe, bleibt aber voll lesbar; vorher wurde alles blasser, was auch
den Text traf.
Kein Neon dazu. Die Wirkung kommt aus Kontrast und Hierarchie.
VIER FEHLER, DIE DIE PRUEFUNGEN GEFUNDEN HABEN
1. ZEITZONE, in NEUN Pruefungen. Um 00:10 meldete pruef-teilnehmer
ploetzlich 13 Fehlschlaege an einer Datei, die seit Stunden niemand
angefasst hatte:
Ortszeit: 06.09.2026, 00:10
UTC: 05.09.2026, 22:10
Sie bildeten ihr Tagesdatum mit toISOString() -- also UTC -- legten
ihre Termine auf gestern und suchten heute. ZWEI STUNDEN AM TAG waren
sie damit rot, im Winter eine. Wer nur tagsueber laeuft, sieht das
nie. Jetzt gibt es helfer-zeit.mjs mit derselben Rechenweise wie die
Anwendung, und pruef-struktur sucht das Muster kuenftig automatisch.
2. MEIN UMSTELL-SKRIPT VERSAGTE STILL. Es pruefte
`if "helfer-zeit.mjs" not in s` -- und mein eigener Kommentar
enthielt den Dateinamen. Ergebnis: keine einzige der neun Dateien
bekam den Import, alle waeren zur Laufzeit abgestuerzt. `node --check`
findet das nicht. Aufgefallen, weil danach nachgezaehlt wurde statt
der Erfolgsmeldung zu glauben.
3. DIE KACHEL LIESS DIE SEITE SPRINGEN. Der Layout-Sprung auf
start.html stieg von 0 auf 0,96 -- zweimal bestaetigt. Sie erschien
erst nach dem Laden und schob alles darunter weg. Das ist kein
Schoenheitsfehler, sondern der Grund, warum man auf den falschen
Knopf drueckt.
Gemessen wurden die echten Hoehen (1 Termin 169 px, 3 → 327, 5 →
486). Daraus zwei Konsequenzen: Platz vorher reservieren, und
hoechstens DREI Termine zeigen -- das halbiert die Spanne und ist
die klarere Aussage. Der Rest steht als "1 weiterer Termin heute"
darunter, nicht stillschweigend abgeschnitten. Von 0,96 auf 0,163.
4. SCHRIFTGROESSE, zweimal am selben Tag: erst die Art-Plaketten mit
10,56 px, dann -- nach der Korrektur -- die neue Jetzt-Marke mit
10,88. Beide Male gemeldet von pruef-handy und pruef-grosscheck,
beide Male erst nach einem mehrminuetigen Browserlauf.
ZWEI PRUEFUNGEN, DIE SICH SELBST IM WEG STANDEN
pruef-tempo-workspace meldete "NEUE Doppelabfrage: start.html 2x
/workspace/api/termine". Nachgemessen an einem einzelnen Seitenaufruf:
genau eine Anfrage. Die Pruefung startete ihren Zaehler, bevor die
Anmeldung zur Ruhe gekommen war, und schrieb der Seite an, was die
vorherige noch offen hatte.
pruef-tagesblick fiel zum zweiten Mal auf dieselbe Falle herein: Sie
mass die Artfarbe an einem vorbeigezogenen Termin, der absichtlich grau
ist. Diesmal an der Wurzel geloest -- die Daempfung wird fuer die
Messung kurz abgeschaltet und sofort zurueckgesetzt. Damit ist die
Zuordnung fuer JEDEN Termin geprueft, unabhaengig von der Uhrzeit des
Laufs, und zusaetzlich beweist die Pruefung, dass die Daempfung greift.
NEU: Schriftgroessen werden jetzt AN DER QUELLE geprueft, in Sekunden
statt Minuten. Im Bestand stehen 43 solche Stellen; sie alle rot zu
melden haette die Pruefung ab Tag eins wertlos gemacht. Deshalb eine
Grundlinie wie beim Layout-Sprung: Sie haelt den Stand fest und
schlaegt an, sobald es MEHR werden. Heute haette das zweimal gegriffen.
Die Browserpruefung bleibt daneben -- sie sieht, was am Ende auf dem
Schirm steht, die CSS-Pruefung nur, was gemeint war.
Gesamtlauf: 56 von 56 Dateien, 2002 von 2002 Punkten.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6541ecbfa7 |
Alte Symboldateien tragen jetzt auch das neue Bild
Filipe hat die Verknuepfungen dreimal neu angelegt und sah trotzdem das alte Symbol. Die Ursache lag nicht an den neuen Dateien - die werden nachweislich korrekt ausgeliefert (36 von 36 live byteweise geprueft), sondern an vier Altlasten: /assets/img/favicon.png 256x256 /assets/img/apple-touch-icon.png 180x180 /assets/img/icon-192.png 192x192 /assets/img/icon-512.png 512x512 Die stammen aus der Zeit vor dem Umbau auf app-symbole/ und werden von KEINER Seite mehr verlinkt - geprueft mit einer Suche ueber alle html, js, json und webmanifest: nur noch sw.js und main.js nennen sie. Aber Chrome hat sich das Favicon dieser Domain gemerkt, als favicon.png noch verlinkt war, und gibt es nicht mehr her: Beim Anlegen einer Verknuepfung nimmt Windows dieses alte Bild, egal was im HTML steht. Auf Filipes Bildschirm trugen deshalb ZWEI verschiedene Verknuepfungen dasselbe Symbol - das war der entscheidende Hinweis, denn zwei Apps mit verschiedenen Manifesten koennen unmoeglich dasselbe Symbol haben. Statt zu hoffen, dass ein Zwischenspeicher irgendwann aufgibt, tragen die alten Adressen jetzt einfach dasselbe Bild wie die neuen. Damit ist es egal, welche ein Programm nimmt. Dazu im Service Worker: CACHE_NAME auf v2 hochgezaehlt - activate() loescht dadurch den alten Zwischenspeicher samt altem Symbol. Und SHELL_ASSETS zeigt nicht mehr auf die verwaisten icon-192/-512, sondern auf die Adressen aus dem Manifest. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ed12d75404 |
App-Symbole: Kennzeichen-Plakette, damit man sie klein unterscheiden kann
Die Symbole waren farblich schon verschieden, zeigten aber alle dasselbe Motiv. Gemessen in echter Groesse: Bei 24px (Startmenue) und 32px (Taskleiste) ist der Husky nur noch ein Fleck - es unterscheidet sie einzig die Farbe, und Webdesign, Kundenportal und WD-Verwaltung liegen im Lila-Rosa-Bereich dicht beieinander. Jedes Symbol traegt jetzt unten rechts eine Plakette mit einem Kennzeichen in der Farbe der App: Hauptseite * DogiCrew-Verwaltung C Webdesign W Kundenportal K WD-Verwaltung V Creator Workspace A Der Husky bleibt gross und dominant - die Marke wird nicht angetastet, die Plakette traegt nur die Unterscheidung. Die maskable-Fassungen haben eine EIGENE Plakettenlage, und die ist gerechnet, nicht geschaetzt: Android behaelt nur den Kreis mit 80% Durchmesser (Radius 0.40 ab Mitte). Der aeusserste Punkt der Plakette liegt bei sqrt(2)*(0.5-rand-groesse/2)+groesse/2. Der erste Entwurf kam damit auf 0.417 - die Plakette waere auf dem Handy angeschnitten worden. Mit rand 0.190 und groesse 0.280 sind es 0.380, also mit Reserve drin. Erzeugt aus den vorhandenen Symbolen (nicht neu gezeichnet), 36 Dateien: je App 32, 180, 192, 512 und die beiden maskable. Jede Datei danach einzeln aus dem PNG-Kopf vermessen - 36 von 36 haben die richtige Groesse und Inhalt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
de60df5637 |
Creator Workspace ist jetzt wirklich installierbar
Der Workspace liess sich nicht als App installieren: Windows und Android legten nur eine Browser-Verknuepfung an, mit dem globalen Favicon der Domain statt dem eigenen Symbol. Grund: workspace/app.webmanifest lag fertig da und wurde sogar ausgeliefert (HTTP 200), war aber in KEINER der 17 Seiten verlinkt. Ohne rel=manifest gibt es fuer den Browser nichts zu installieren. Jede der 17 Seiten bekommt deshalb den Manifest-Verweis und die eigene Fensterfarbe #0674b9 (Blau, passend zum nachtblauen Symbol). Zur Entstehung: Diese 17 Dateien tragen auch Versionsnummern einer parallel laufenden zweiten Sitzung (?v=202609052252), deren zugehoerige start.css und start.js noch nicht committet sind. Die gehoeren nicht in diesen Commit. Sie wurden fuer das Bereitstellen kurz auf den committeten Stand zurueckgesetzt und in der Arbeitskopie sofort wiederhergestellt - im Index liegt dadurch nur die eigene Aenderung, ihre Arbeit bleibt unangetastet uncommittet. Vorher gesichert, hinterher Datei fuer Datei verglichen: kein Unterschied. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5ef3a13615 |
Jede App der Domain bekommt eine eigene Fensterfarbe
Beim Installieren als App sahen alle Dienste gleich aus. Nicht wegen der Symbole - die sind seit heute Mittag gut unterscheidbar - sondern wegen der Farbe: zwoelf von vierzehn trugen dasselbe Fast-Schwarz (#05070b, #05070d, #0a0910, #0b0d10, #0d0817, #0e0a16). Das ist die theme_color, also am PC die Titelleiste des App-Fensters und am Handy die Statusleiste. Neu, je App eine Farbe, abgeleitet vom eigenen Symbol: Hauptseite #065f76 Petrol (Symbol stahlblau) DogiCrew-Verwaltung #8d4125 Kupfer (Symbol orange) Webdesign #564e95 Violett (Symbol lila) Kundenportal #924985 Magenta (Symbol pink) WD-Verwaltung #b44f5e Rose (Symbol rot) Creator Workspace #0674b9 Blau (Symbol nachtblau) Nextcloud (#17a5a6) bleibt unveraendert - als einzige hob sie sich schon ab. WICHTIG war, beide Stellen zu aendern: Die meta-Angabe im HTML ueberschreibt die theme_color aus dem Manifest. Nur das Manifest zu aendern haette gar nichts bewirkt. Der background_color (Startbildschirm beim Oeffnen) bleibt bewusst sehr dunkel, nur leicht in Richtung der App-Farbe getoent - kraeftig ist nur die schmale Leiste, damit nichts grossflaechig aufblitzt (Vorgabe augenschonend). Wie die Farben entstanden sind: Zwei Entwuerfe fielen bei der eigenen Pruefung durch. In HSL gerechnet lagen Workspace und Webdesign bei einem Farbabstand von 12.6 statt der noetigen 25 - auf dem Papier 30 Grad auseinander, fuers Auge dasselbe Blauviolett. Auch der zweite Versuch scheiterte (Hauptseite zu nah an Nextclouds Tuerkis, 19.1). Neun Farben bei gleicher Helligkeit passen schlicht nicht mit genug Abstand auf den Farbkreis. Erst mit der Helligkeit als dritter Dimension und einem Optimierer, der den KLEINSTEN Abstand im Satz maximiert, kam ein Satz heraus, der haelt: kleinster Abstand 25.5. Geprueft: 68 Farbpruefungen (weisse Schrift ueberall lesbar 5.0-7.2:1, keine blendet, jede hebt sich vom bisherigen Schwarz ab, alle Paare >= 25 Delta E) und 101 Browserpruefungen ueber 16 Seiten (Manifest und meta stimmen ueberein, genau eine theme-color je Seite, Symbole vorhanden) - alle gruen, Gegenprobe schlaegt an. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
c3b156dbad |
Tagesblick: eine Kachel fuer offene Punkte und die Termine des Tages
Wunsch Filipe, 05.09.2026, mit Bildschirmfoto der Hinweisliste: "eine
ganze kachel wo links die sachen sind die du da schon siehst und rechts
in der kachel die termine vom tag. in der mitte gesplittet. mach das
richtig geil und hochwertig."
WARUM DIE BEIDEN ZUSAMMENGEHOEREN
Links steht, was zu TUN ist, rechts, was schon FESTSTEHT. Zusammen
ergeben sie die einzige Frage, die man morgens hat -- wie sieht mein Tag
aus. Untereinander musste man scrollen, um sie zu beantworten.
Eine Kachel und nicht zwei nebeneinander: Zwei Rahmen lesen sich als
zwei Themen. Der Trenner laeuft oben und unten aus, statt von Kante zu
Kante durchzuschneiden -- eine harte Linie macht aus einer Kachel wieder
zwei.
Die rechte Haelfte ist ein Zeitstrahl, kein Kalenderauszug:
* Was als NAECHSTES dran ist, wird hervorgehoben. Beim Ueberfliegen
ist das die Auskunft, die man sucht -- nicht "der erste des Tages".
* Vorbei heisst nicht weg. Erledigtes tritt zurueck, bleibt aber
sichtbar; man will sehen, was man schon hinter sich hat.
* Dieselben vier Farben wie im Kalender. Eine Farbe, die hier etwas
anderes bedeutete, muesste man zweimal lernen.
Die Daten kommen aus der Kalender-Schnittstelle mit tage=1 -- keine
zweite Abfrage, keine zweite Sichtbarkeitsregel. Was jemand im Kalender
nicht sehen darf, kommt hier gar nicht erst an.
DREI FEHLER, DIE DABEI AUFFIELEN
1. Die rechte Haelfte war 38 statt 579 Pixel breit. Die versteckte
Ueberschrift fuer Vorleseprogramme zaehlt als Kind im Raster und hat
alles um eine Spalte verschoben, sodass "Heute" in der Ein-Pixel-
Spalte des Trenners landete. Die Spalten sind jetzt ausdruecklich
zugewiesen -- damit verschiebt auch ein spaeteres viertes Element
nichts mehr.
2. Die Plaketten (CALL, TERMIN, REVIEW) hatten 10,56 px. Die Hausgrenze
liegt bei 11,5 -- darunter liest auf einem Handy niemand mehr.
Gemeldet von pruef-handy auf allen drei Geraeteklassen UND von
pruef-grosscheck bei allen vier Rollen. Ein Fix, zwei Pruefungen.
3. Am Handy stand die Uhrzeit mittig zur Zeile, waehrend der Titel oben
begann -- sie fluchteten nicht, sobald die Plakette unter den Text
rutschte.
Die Kachel bleibt ganz weg, wenn BEIDE Haelften leer sind, und zeigt
sonst auf der leeren Seite einen Satz. Vorher haette jemand ohne offene
Punkte, aber mit drei Calls seinen Tagesplan nicht gesehen: Das
Verstecken hing an der linken Haelfte allein.
ZWEI PRUEFUNGEN, DIE SICH SELBST IM WEG STANDEN
pruef-tempo-workspace meldete "Layout springt: bereich.html 0,703".
Nachgemessen: derselbe Wert schwankt zwischen den Laeufen um den Faktor
zwei (aufgaben.html 0,478 / 0,262 / 0,262; bereich.html 0,703 dann
0,347). Er haengt davon ab, ob die Daten ankommen, waehrend das Geruest
noch aufgebaut wird. Eine Pruefung, die zufaellig rot wird, ist so
wertlos wie eine, die nie anschlaegt -- man klickt sie weg, und mit ihr
die echte Warnung. Statt die Grenze anzuheben (das haette sie stumpf
gemacht) wird ein Ausschlag jetzt durch WIEDERHOLUNG bestaetigt, und
gemeldet wird der zweite Wert, nicht der kleinere. Ein echter Sprung
kommt bei jedem Lauf und uebersteht das muehelos. Die neue Kachel selbst
springt uebrigens gar nicht: start.html steht bei 0.
pruef-push-weg meldete "ALLES IN ORDNUNG" und stuerzte danach ab
(libuv: UV_HANDLE_CLOSING, Rueckgabewert 3221226505). Ursache war
process.exit() mitten im Schliessen der fetch-Verbindungen. Jetzt
process.exitCode -- Node raeumt zu Ende. Fuenf Laeufe hintereinander
sauber. Eine Pruefung, die inhaltlich besteht und trotzdem rot ist, ist
das Schlimmste von beidem.
Gesamtlauf: 1994 von 1994 Punkten (1973 vorher + 21 der neuen Pruefung).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
5119e0139d |
vanvan.html: Coming-soon-Knopf wird Link zu VAN'S DIY
Der silberne Knopf trug 'Coming soon...' und war gesperrt (aria-disabled, kein href). Er heisst jetzt 'VAN`S DIY' und fuehrt zu https://vans-diy-bastelbedarf.com/ - in neuem Tab, mit rel=noopener, wie der TikTok-Knopf darueber und die uebrigen Shop-Verweise im Projekt. aria-disabled musste weg: sonst meldet ein Bildschirmleser 'nicht bedienbar', obwohl der Knopf jetzt bedienbar ist. Dabei aufgefallen und mitbehoben: Die Beschriftung brach auf schmalen Geraeten mitten im Wort um ('VAN / `S / DIY' bei 390px, Knopf 117px statt 89px hoch), weil die Sektion auf vanvan.html auch auf dem Handy zweispaltig bleibt - ein Inline-Style ueberschreibt dort die Regel aus @media(max-width:620px). .btn-silver bekommt deshalb white-space:nowrap. Das behebt zugleich den gleichen Umbruch von 'Coming soon...' auf abonnieren.html bei 320px. Geprueft im echten Browser: 52 Pruefungen (5 Sprachen x Text, href, kein aria-disabled, target, rel, sichtbar, bedienbar) plus echter Klick, der auf vans-diy-bastelbedarf.com landet - alle gruen, Gegenprobe schlaegt an. Zusaetzlich 180 Messungen ueber 4 Seiten x 9 Breiten x 5 Sprachen (270 Knoepfe angesehen): kein Umbruch, kein Ueberlauf. Ohne den nowrap-Fix meldet dieselbe Messung 30 Befunde. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
627f710d71 |
Aufgaben abbrechen, Teilnehmerwahl fuer alle, Benachrichtigungen
Zwei Wuensche vom 05.09.2026, dazu drei Fehler, die dabei ans Licht kamen.
ABBRECHEN (Wunsch: "in jedem status die aufgaben auch abbrechen koennen,
nur ich die manager und scouts")
Neuer Status mit Pflicht-Grund, aus jedem der vier Status heraus.
Festgehalten wird auch, WO die Aufgabe stand -- "im Review abgebrochen"
ist eine andere Aussage als "nie angefangen", und das Wiederaufnehmen
geht dorthin zurueck statt nach "offen".
Eigener Weg statt "abgebrochen" in der Statusliste: Dort entscheidet
darfAendern(), und das laesst auch den zustaendigen Creator aendern.
Der gewoehnliche PATCH kann diesen Zustand deshalb gar nicht erreichen
-- auch nicht fuer DogFather, sonst waere die Grund-Pflicht umgehbar.
Abgebrochenes steht in einem zugeklappten Bereich unter dem Brett, nicht
als fuenfte Spalte: Am Handy waeren dann alle fuenf unlesbar schmal.
Verschwinden darf es nicht, sonst waere der Abbruch ein Loeschen mit
Zwischenschritt.
Die Tabelle musste dafuer getauscht werden (SQLite kann CHECK nicht
aendern). Vorher auf einer Kopie durchgespielt: 40 von 40 Aufgaben,
Inhalte, Verweise und Indizes geprueft, Gegenprobe zeigt, dass der CHECK
noch lebt.
TEILNEHMERWAHL (Wunsch: "das soll viel besser aussehen und fuer jeden
verfuegbar sein")
Auf dem Bildschirm klebten die Namen aneinander: "DogfatherDogFather".
Ursache war, dass kalender.html das Stylesheet mit diesen Klassen nie
eingebunden hat -- sie standen in dateien.css. Vierzig gruene Pruefungen
zur Teilnehmerwahl hatten das nicht gemerkt, weil keine je gefragt hat,
ob es AUSSIEHT wie gedacht.
Jetzt eigene Klassen im eigenen Stylesheet, nach Rollen gruppiert: Die
Rolle steht einmal als Ueberschrift statt neunmal am Namen. Damit ist
das Kleben an der Wurzel weg, nicht zugepflastert.
"Fuer jeden" war mehr als ein hidden zu entfernen: darfEintragen() haette
einem Creator nur sich selbst erlaubt. Er haette seinen Scout gesehen,
angeklickt, und der Server haette ihn still weggelassen -- ein Knopf, der
nichts tut. einladbareIds() schaut jetzt in beide Richtungen, bewusst
getrennt von /api/personen: Wer die erweitert, gibt einem Creator
nebenbei die Moeglichkeit, seinem Scout Aufgaben zuzuweisen.
BENACHRICHTIGUNGEN (Wunsch: "sowas, und dass es perfekt funktioniert
fuer jeden")
Web Push nach RFC 8291/8292, ohne fremde Abhaengigkeit. Der Knopf sagt
in jeder Lage die Wahrheit, auch die unbequemen: abgelehnt (mit dem
Hinweis, wo man es zuruecknimmt), iPhone im Reiter (mit Anleitung),
Browser ohne Push. Ein Knopf, der bei abgelehnter Berechtigung nur
nichts tut, ist der sichere Weg zu "das funktioniert nicht".
DREI FEHLER, DIE DABEI AUFFIELEN
1. Ein defekter Zugangsdatensatz sperrte ALLE einer Rolle aus. Wirft
hashe() bei einer Person, flog die ganze Anmeldung in den catch: 503
"nicht verfuegbar" fuer jeden mit dieser Rolle. Aufgefallen durch
einen eigenen Testfehler. Jetzt wird die defekte Person uebersprungen
und laut protokolliert; die Gegenprobe zeigt, dass ein falscher Code
weiterhin abgelehnt wird.
2. Die Glocke sprengte die Kopfleiste -- zweimal. Bei 320 px lag die
Lupe des Suchknopfes auf dem Sicht-Umschalter (ein Knopf, der auf 12
Seiten ins Leere tippt), bei 768 px wurde der Abmelden-Knopf bis zu
15 px aus dem Bild geschoben, weil die Textgrenze auf 760 stand und
ein Tablet 768 hat. Nachgewiesen durch Messen mit und ohne Glocke,
nicht durch Vermuten.
3. .block__frage war viermal gestaltet und stand auf einer Seite, die
keine dieser Dateien laedt -- derselbe Fehler wie bei der
Teilnehmerwahl. Gefunden von der neuen Klassenpruefung beim ersten
Lauf.
NEUE PRUEFUNGEN
pruef-css-klassen jede gestaltete Klasse muss auf ihrer Seite ankommen
(unterscheidet Struktur-Anker von echtem Verlust)
pruef-dabei-optik die Wahl im Browser, an den echten Pixeln
pruef-abbrechen Umstellung auf einer Kopie, Rechte, Rueckweg
pruef-abbrechen-optik Knopf, Dialog, Bereich, Handy
pruef-glocke Zustaende, An/Abmelden, jede Rolle
pruef-push(-weg) Rechnung gegen die RFC-Vektoren, Zustellung
pruef-struktur prueft jetzt zusaetzlich, ob sich jedes Server-Modul als
ESM laden laesst. node --check auf einer .js-Datei prueft als CommonJS
und meldete "ok", waehrend der Import scheiterte.
Gesamtlauf: 55 von 55 Dateien, 1973 von 1973 Punkten.
Was NICHT geprueft werden konnte und deshalb dasteht: Der Schritt
"Browser holt eine Adresse beim Push-Dienst" braucht eine Verbindung zu
Googles FCM, die ein Pruef-Browser nicht hat. Die Pruefung misst das
zuerst und meldet es als dritten Ausgang, statt gruen zu sein.
Verschluesselung und Zustellung sind getrennt geprueft; diese eine
Strecke beweist sich erst auf dem Server.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
529c814389 |
Kalender: mehrere Teilnehmer je Termin und Serie
Wunsch Filipe: "wenn ich im kalender was eintrage will ich dass ich
auch 2 leute markieren kann mit denen der call ist." -- und auf
Rueckfrage: beliebig viele, und auch fuer wiederkehrende Termine.
Bis hierher hatte ein Termin GENAU EIN Gegenueber. Fuer ein Gespraech
zu dritt musste man zwei Termine anlegen und hatte zwei Wahrheiten
ueber dieselbe halbe Stunde.
DAS IST KEINE ANZEIGE, SONDERN EINE RECHTEREGEL. An der
Teilnehmerliste haengt die Sichtbarkeit: Wer eingetragen ist, sieht den
Termin. Deshalb zwei Grenzen, beide serverseitig:
* Eintragen darf man nur, wen man ohnehin sehen darf (Leitung jeden,
ein Scout seine betreuten Creator, ein Creator sich selbst).
* Zuordnungen verschiebt nur die Leitung -- sonst koennte sich jemand
selbst in fremde Termine eintragen und sie sich damit sichtbar
machen.
Gebaut nach dem Muster von datei_personen: eigene Tabellen
termin_teilnehmer und serie_teilnehmer statt weiterer Spalten.
teilnehmer_id bleibt das Haupt-Gegenueber und wird beim Speichern immer
in die Liste mit aufgenommen.
Vorhandene Termine werden beim Start uebernommen. Zusaetzlich liest die
Abfrage das Haupt-Gegenueber IMMER mit dazu -- die Liste stimmt damit
auch dann, wenn die Uebernahme nicht gelaufen ist (Sicherung
zurueckgespielt, Neustart ausgeblieben). Genau das ist beim Bauen
aufgefallen: Ein alter Termin zeigte "niemand dabei", obwohl ein
Gegenueber eingetragen war.
Serien vererben ihre Teilnehmer an jede erzeugte Auspraegung -- sonst
saehe der zweite Mensch den woechentlichen Call einmal und danach nie
wieder.
Neue Pruefung pruef-teilnehmer.mjs mit 40 Punkten: beide sehen ihn,
Fremde nicht, kein Selbsteintragen, Hinzufuegen und Entfernen, Serien,
Unsinn in der Liste. Mit Gegenprobe, die nachweist, dass die Messung
"nicht sichtbar" ueberhaupt erkennt. Im echten Browser gegengeprueft:
Schalter da, zwei angehakt, gespeichert, beide zurueck, keine
Konsolenfehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8759a46e5b |
iPhone-Symbole: quadratisch und deckend statt abgerundet
Gemeldet: "auf dem pc und auf dem handy soll alles funktionieren, auf
dem einen klappt es und auf dem anderen nicht."
Der Grund ist, dass PC und Handy ihr Symbol an drei verschiedenen
Stellen holen -- und jede stellt andere Anforderungen:
Browser-Reiter das normale Symbol, runde Ecken erlaubt
Android die maskable-Fassung, aussen wird beschnitten
iPhone <link rel=apple-touch-icon> -- und iOS rundet SELBST
ab und fuellt alles Durchsichtige mit SCHWARZ
Unser 180er brachte seine eigene Rundung mit, also durchsichtige Ecken.
Auf dem iPhone wurden daraus schwarze Zipfel, die dann ein zweites Mal
beschnitten wurden. Auf dem PC sieht dieselbe Datei tadellos aus --
genau daher der Unterschied zwischen den Geraeten.
Jetzt wird die 180er-Fassung randvoll und deckend gebaut. Nachgemessen
an allen zehn: 0,00 Prozent durchsichtig, Ecken voll deckend. Die
normale Fassung bleibt abgerundet (4,75 Prozent) -- auch das gemessen,
damit der Fix nicht die andere Seite kaputtmacht.
Dazu eine Pruefung in pruef-struktur.mjs: alle sechs Groessen je App
vorhanden, und jede Seite nennt beide Symbolarten. Fehlt das
iPhone-Symbol, nimmt iOS einen Bildschirmausschnitt der Seite.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e9709a5aa8 |
Maskable-Symbole: das ganze Symbol verkleinern, nicht nur das Logo
Gemeldet von Filipe: "die symbole sehen aber auf meinem pc nicht aus wie auf dem browser mit diesen geilen farben." Er hatte recht -- die maskable-Fassungen sahen aus wie eine schlechte Kopie: blass, das Medaillon riesig, der Doppelring ueber den Rand hinaus. Und genau die nimmt das Betriebssystem fuer installierte Apps. Der erste Entwurf verkleinerte nur das LOGO (52 statt 68 Prozent) und liess den Hintergrund unveraendert. Das geht bei einer glatten Flaeche gut und bei allem anderen schief: Medaillon, Doppelring, Raster und Eckband rechnen ihre Kreise in Prozent der FLAECHE. Wird aussen ein Fuenftel weggeschnitten, sitzt der Ring nicht mehr, wo er hingehoert. Jetzt wird das fertige Symbol als Ganzes auf 78 Prozent verkleinert und in eine Huelle aus dem dunkelsten Ton der App gesetzt. Damit bleibt jedes Verhaeltnis erhalten -- Ring zu Flaeche, Logo zu Ring, Verlauf zu Kante. Weggeschnitten wird nur ruhige Randfarbe. Nachgeprueft mit einer Vorschau, die den Zuschnitt nachstellt: rund (Android) und abgerundetes Quadrat (Windows/iOS). Beide sehen jetzt praktisch aus wie die Fassung im Browser. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
37c2930af0 |
Kundenportal war nicht installierbar: Manifest hinter der Zugangswand
Live gemessen nach dem Deploy: Symbole 200, portal.webmanifest 302 auf zugang.html. Der Browser bekam HTML statt JSON und bot "App installieren" gar nicht erst an -- die ganze Arbeit am Symbol waere fuer das Portal wirkungslos geblieben, ohne dass irgendwo etwas rot geworden waere. Das ist zum DRITTEN Mal derselbe Fehler an derselben Stelle (app.webmanifest, verwaltung.webmanifest, jetzt portal.webmanifest). Zweimal stand die Begruendung danach im Code -- beim dritten Mal wurde sie trotzdem uebersehen. Ein Kommentar verhindert nichts. Deshalb zusaetzlich eine Pruefung in pruef-struktur.mjs: Jedes Manifest unter /webdesign/ MUSS in der Ausnahmeliste von webdesign-gate.js stehen. Gegengeprobt -- Eintrag entfernt, Pruefung schlaegt an. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
7fe6a51233 |
ZockerAnstalt und Analyse: Symbole unter den richtigen Namen
Der erste Entwurf legte sie unter eigenen Namen daneben (dogfather-zocker-192.png). Die Dateien lagen da, die Manifeste zeigten weiter auf icon-192.png -- das neue Symbol waere nie angekommen. Der Kopiervorgang meldete trotzdem 6 Symbole kopiert. Jetzt werden die vorhandenen Namen ueberschrieben. Damit greifen Manifest und HTML ohne weitere Aenderung, und es gibt keine zweite Stelle, an der ein Verweis uebersehen werden kann. Fehlt ein erwarteter Name, wird das gemeldet statt still uebergangen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
3decdab2f2 |
Laufprotokoll der Browserpruefung gehoert nicht ins Repo
Es entsteht bei jedem Lauf neu und ist ein Ergebnis, kein Quelltext. Beim vorigen Commit versehentlich mitgenommen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
51c3d4402b |
Audit des Creator Workspace, App-Symbole fuer alle Apps der Domain
AUDIT (Auftrag: vollstaendiger Durchgang, Fehler direkt beheben)
Ausgangslage waren 40 Pruefungen mit 1616 Einzelpunkten, alle gruen.
Acht neue Pruefungen kamen dazu; sie haben gefunden, was die alten nicht
sehen konnten.
Der schwerste Fund: Die Zugangsschranke verglich req.path EXAKT gegen
eine Liste. Express raeumt Punkt-Segmente selbst weg, mehrfache
Schraegstriche aber nicht. Damit kam //workspace/start.html OHNE
Anmeldung mit HTTP 200, und ein Creator bekam ueber
/workspace//personen.html die Verwaltungsseite. Die DATEN waren nie
betroffen (nachgemessen: 404 bzw. 401). Behoben durch Normalisierung
UND eine Umkehr der Logik -- jetzt ist jede .html geschuetzt ausser der
Anmeldeseite, statt nur die in der Liste. Eine vergessene neue Seite
steht damit nicht mehr versehentlich offen.
Weiter behoben:
* Kaputter/abgebrochener Rumpf ergab 500 in HTML statt 400 in JSON --
die Oberflaeche ruft ueberall a.json() und lief in einen zweiten
Fehler; der Knopf hing ohne Meldung.
* POST /zustand/sichern war der einzige von 60 schreibenden Wegen
ohne Herkunftspruefung.
* workspace-sicherung.js gab interne Pfade in Fehlermeldungen nach
aussen; alle 23 anderen Module antworten neutral.
* admin_notiz war als einziges von 14 Feldern ohne <label>.
* Der aktive Filter hatte keinen sichtbaren Fokus (CSS-Spezifitaet
0,3,0 schlug 0,2,0) -- genau der Knopf, auf dem man steht.
* h1 -> h3 ohne Zwischenstufe auf zwei Seiten.
* HSTS ging auch ueber http mit (RFC 6797, 7.2 verbietet das).
* upgrade-insecure-requests galt auch auf 127.0.0.1 -- dadurch war
WebKit/Safari ueberhaupt nicht pruefbar, also der Browser, den
jedes iPhone benutzt.
* pruef-grosscheck las readdirSync(".") und pruefte aus server/
gestartet NULL oeffentliche Seiten -- meldete aber "ok".
Neue Pruefungen: struktur, schranke, haerte, alle-wege,
barrierefrei-workspace, breiten, tempo-workspace, browser.
Jede mit Gegenprobe und mit der geprueften Anzahl in der Bedingung.
Vier davon sind beim Bauen durch die eigene Gegenprobe aufgeflogen und
haetten sonst dauerhaft gruen gemeldet, ohne etwas zu messen.
APP-SYMBOLE (Wunsch: alle Apps der Domain, jede anders, ausser
safeaddress)
Zehn Apps, zehn Stile, zehn in OKLCH gerechnete Farben. Zusammen haelt
sie dasselbe Logo, dieselbe Eckenrundung und eine gemeinsame gedeckte
Farbreihe. Beim Bauen wird gemessen, ob sich das Logo vom Grund abhebt
(19 bis 58 Helligkeitsstufen).
Dabei aufgefallen: Das Kundenportal hatte kein eigenes Manifest und
trug Namen und Symbol der Webdesign-Seite. Der Workspace hatte gar
keins und war als App nicht installierbar. Beide haben jetzt eins.
Geaendert wurde AUSSCHLIESSLICH das Symbol. Ein Zwischenstand hatte
auch die Themenfarben gesetzt; das war mehr als bestellt und wurde
zurueckgenommen.
Werkzeuge: tools/logo-freistellen.mjs, tools/app-symbole.mjs,
tools/app-symbole-einbinden.mjs -- alles im Browser gerechnet, kein
Bildprogramm, keine neue Abhaengigkeit.
Gitea und Nextcloud sind bereits live und nachgeprueft.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
15fe9bb197 |
Zwei Pruefungen an die getroffenen Entscheidungen angepasst
Der komplette Pruefstand vor der Vorstellung (38 Laeufe im Workspace) lief bis auf zwei durch. Beide Fehlschlaege waren KEINE Fehler in der Anwendung, sondern Pruefungen mit veraltetem Weltbild -- Folgen von Entscheidungen, die Filipe selbst getroffen hat: 1. pruef-workspace-seiten (32 von 32 rot) pruefte, dass JEDE Seite ihre EIGENE Buehne hat (Aufgaben = Werkstatt, Kalender = Nachtstadt, ...). Am 03.09.2026 hat Filipe die neun Szenen durch EIN Bild ersetzt. Jetzt wird geprueft, was weiterhin wichtig ist: dass ueberhaupt ein Hintergrundbild ANKOMMT (ein data-buehne ohne CSS-Regel waere still wirkungslos) -- und dass es auf JEDER Seite dasselbe ist. Ohne die zweite Bedingung waere sie auch gruen, wenn irgendwo eine alte Szene zurueckkaeme. 2. pruef-zustand-ansicht erwartete, dass ein Manager den Systemzustand sieht. Seit dem 02.09.2026 gilt "die manager sollen diese kategorien garnicht sehen"; der Zustand gehoert zur Automationen-Seite. Beide UMGEDREHT statt geloescht. Eine geloeschte Pruefung hinterlaesst keine Spur davon, dass hier einmal etwas anderes galt -- und niemand merkt, wenn eine Sperre spaeter versehentlich wieder faellt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
80639d0bab |
Abnahme vor der Vorstellung: eine tote Kachel gefunden und geschlossen
Morgen wird die Seite als Produkt vorgestellt. Deshalb eine Pruefung,
die es bisher nicht gab: server/pruef-live-abnahme.mjs geht gegen die
ECHTE Domain statt gegen einen Server auf diesem Rechner.
Der Unterschied ist nicht theoretisch. Zwischen "laeuft bei mir" und
"laeuft im Netz" liegen Caddy, Cloudflare, der Cache-Stempel, das
Zertifikat und der Dienst-Neustart -- genau dort ist am 18.08. und am
22.08.2026 schon zweimal etwas haengengeblieben, das lokal tadellos war.
Sie geht 26 Seiten in DREI Gestalten durch:
RECHNER 1440 px
HANDY 390 px, mit Fingerbedienung
INSTALLIERT als App vom Startbildschirm -- ohne Adresszeile und ohne
Zurueck-Knopf des Browsers. Dort faellt auf, was man mit
Browserleiste nie merkt.
Gemessen je Seite: Konsolenfehler, fehlgeschlagene Anfragen, seitlicher
Ueberlauf, tote Verweise, fehlende Bilder, ueberhaupt Inhalt, Titel.
Dazu die App selbst: Manifest, Name, Start ohne Browserleiste, alle vier
Startbildschirm-Symbole einzeln abgefragt, Hintergrunddienst angemeldet
und aktiv.
DER EINE ECHTE FUND: Auf links.html war die Kachel "Merchandise / Shop"
ein <a href="#"> -- sie sah aus wie ein Verweis, liess sich anklicken
und tat nichts. Auf der Kachel steht "Folgt in Kuerze"; genau dann darf
sie nicht klickbar sein. Ein Knopf, der nichts tut, ist schlimmer als
gar keiner: Man drueckt ihn zweimal und haelt die Seite fuer kaputt.
Jetzt ein <div> mit denselben Klassen -- gleiches Aussehen, kein
Versprechen mehr, das die Seite nicht halten kann.
ZWEI FEHLALARME, beide in MEINER Pruefung, beide aufgeschrieben:
* Sie meldete "fehlende Bilder" auf zwei Seiten. Es waren versteckte
Platzhalter (<img hidden> ohne src), die JavaScript erst fuellt --
der Normalzustand. Jetzt zaehlen nur sichtbare Bilder mit Quelle.
* Sie meldete "manifest.json nicht ladbar", waehrend curl gleichzeitig
200 lieferte. Die Probe stand noch auf about:blank und holte von
dort -- fremde Herkunft, der Browser lehnt ab. Sie hat also nicht
die Seite geprueft, sondern sich selbst. Erst navigieren, dann
messen.
Die beiden anderen href="#" auf der Seite (index.html, streamplan.html)
bleiben: Sie sind versteckt und werden von JavaScript gefuellt, sobald
es etwas zu verlinken gibt. Geprueft wird nur, was man auch sieht.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
95f54fd211 |
Die ganze Oberflaeche spricht jetzt dieselbe Sprache wie die Zeichen
"bring alles auf dieses niveau -- texte, kacheln, hinweise, titel,
buttons, einfach alles."
Berechtigt, und der Fehler war meiner: Die Kachelzeichen sind Koerper
geworden, alles andere blieb flach. Ein plastisches Zeichen neben einem
gemalten Knopf sieht nicht nach "teilweise gut" aus, sondern nach
Versehen.
Ab jetzt gelten fuer JEDES Bauteil dieselben drei Regeln -- dieselben,
nach denen auch die Zeichen gebaut sind:
1. LICHT VON OBEN. Eine helle Kante an der Oberkante, in der Mitte am
staerksten, nach aussen auslaufend. Echtes Licht auf einer Kante
sieht so aus; eine durchgehend gleich helle Linie ist ein Strich.
2. TIEFE NACH UNTEN. Ein versetzter Schatten -- wie bei jedem
Gegenstand, der auf etwas liegt. Ohne ihn klebt ein Element auf der
Seite, statt darauf zu liegen.
3. VERLAUF STATT FLAECHE. Oben eine Spur heller als unten. Kaum zu
sehen, aber ohne ihn bleibt jede Flaeche tot.
Und eine vierte, nur fuer Bedienbares:
4. WAS MAN DRUECKT, GEHT HINEIN. Beim Klick kehrt sich die Woelbung um:
Licht nach unten, Schatten nach oben. Das ist der Unterschied
zwischen "es passiert etwas" und "ich habe etwas gedrueckt".
ANGEFASST -- beide Seiten, nicht nur eine:
Workspace (gate.css, gilt auf jeder Seite)
Knoepfe, Schritte, Abmelden, Stufenknoepfe, Suchknopf
Eingabefelder, Auswahlfelder, Suchfeld -- die bekommen die Woelbung
ABSICHTLICH ANDERSHERUM: Ein Feld, in das man schreibt, ist eine
Mulde, kein Knopf. Licht unten, Schatten oben.
Marken, Rollenabzeichen, Zaehler, Filterchips
Hinweisflaechen, Notizen, Call-Raum, Codekasten
Ueberschriften und Schilder
Oeffentliche Seite (main.css)
Knoepfe (btn, btn-primary, btn-outline) samt geschliffener Kante
Marken und Abzeichen
Ueberschriften
Der Textschatten aendert die FARBE nicht -- die Kontrastpruefung misst
weiter denselben Wert --, legt den Text aber auf die Seite, statt ihn in
den Hintergrund zu mischen.
Alles gedeckt. Diese Bauteile stehen zu Dutzenden auf einer Seite, und
was einzeln beeindruckt, blendet im Dutzend.
GEPRUEFT, zehn Laeufe, alle gruen: Buehne 38 (Textkontrast an echten
Bildpunkten), Rollen 97, Handy 50, Formulare 19, Grosscheck 15,
Lesbarkeit 14 -- dazu die vier Laeufe der oeffentlichen Seite
(Startseite, Design, Barrierefreiheit, Tastaturbedienung).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
788a5fbd81 |
Die Zeichen sind jetzt KOERPER, keine Zeichnungen mehr
"wir kommen nicht voran, ich will das viel realistischer."
Berechtigt: Ich habe viermal dieselbe flache Zeichnung anders
BELEUCHTET -- Verlauf, Fuellung, Glanz, Schlagschatten. Das Verfahren
war das Problem, nicht die Einstellungen. Also gewechselt.
JEDES ZEICHEN HAT JETZT EINE HOEHE. Aufbau von hinten nach vorn:
tiefe 3/2/1 dieselbe Silhouette, dreimal, je einen halben
Rasterpunkt nach rechts unten versetzt und heller
werdend. Das Auge liest die drei versetzten Kanten als
EINE schraege Seitenwand -- genau so zeichnet man einen
Quader von Hand. Drei Lagen sind gemessen: bei zwei
sieht es aus wie ein Druckfehler, ab fuenf wie ein
Schlagschatten.
deck die Oberseite: oben fast weiss, unten im Farbton. Die
Flaeche, auf die das Licht faellt.
glanz die Spiegelung darauf.
saum + linie die Details.
Dafuer bekam jedes Zeichen eine SILHOUETTE (KOERPER in bereiche.js) --
den geschlossenen Umriss des Gegenstands, getrennt von den Details.
Die Details bekommen bewusst KEINE Tiefe: Ein aufgedruckter Strich
steht nicht hervor.
DER SAUM ist die Loesung eines Problems, das erst durch die Tiefe
entstand: Dieselbe Linie liegt ueber ZWEI Untergruenden. Der Querstrich
im Kalender liegt auf der hellen Deckflaeche, die Wellen der
LIVE-Analyse frei auf der dunklen Plakette. Eine dunkle Linie
verschwindet dort, eine helle auf dem Deck -- was immer man waehlt, die
Haelfte ist weg. Dunkler Saum plus helle Linie loest beides: auf dem
Deck liest man eine eingravierte Rille, auf der Plakette traegt die
helle Linie. Ein Zeichen, zwei Untergruende, eine Loesung.
GEPRUEFT: Buehne 38 (Textkontrast an echten Bildpunkten), Startansicht
133, Rollen 97, Handy 50, Grosscheck 15, Lesbarkeit 14. Alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
44716fa54b |
Aus Zeichnungen werden Gegenstaende -- Kacheln der GANZEN Seite
"ich will dass die krank realistisch sind, und alle kacheln durch die
ganze website perfektionieren."
DIE ZEICHEN bekommen die Beleuchtung, die man aus der Wirklichkeit
kennt -- vier Lagen statt einer:
KOERPER gefuellte Grundform, oben satt, unten auslaufend
EIGENSCHATTEN eine dunkle Lage, die von unten hereinkriecht. Ein
Koerper ist unten dunkler als oben; ohne das bleibt
jede Flaeche eine Farbflaeche
GLANZ die Spiegelung, schmal ueber die obere Haelfte
KONTUR mit ZWEI Lichtquellen: oben das Hauptlicht (fast weiss),
in der Mitte der Eigenton, unten STREULICHT vom
Untergrund. Der letzte Stopp ist der Unterschied
zwischen "Zeichnung" und "Ding" -- ohne ihn laeuft jede
Form nach unten ins Dunkle aus.
Dazu ein SCHLAGSCHATTEN auf die Plakette, versetzt nach unten statt
mittig. Er ist der Grund, warum das Zeichen ueber der Flaeche schwebt
statt darauf zu liegen.
DIE PLAKETTE bekommt eine KOERNUNG -- eine sehr feine, unregelmaessige
Struktur. Das ist der Unterschied zwischen "am Rechner gemacht" und
"Gegenstand": Eine makellos glatte Farbflaeche gibt es in der
Wirklichkeit nicht, und das Auge erkennt das sofort, auch wenn niemand
sagen koennte woran. Eingebettetes Rauschen, keine Bilddatei -- kostet
nichts zu laden und kann nicht fehlen.
DIE KACHELN, und zwar BEIDE Systeme:
workspace .kachel -- bekam Tiefe nach unten (fehlte ganz: die Kachel
klebte auf dem Hintergrund statt darauf zu liegen) und eine
Lichtkante, die in der Mitte am hellsten ist und nach
aussen auslaeuft. Echtes Licht auf einer Kante sieht so
aus; eine durchgehend gleich helle Linie ist ein Strich.
oeffentlich .card (133 Vorkommen auf der Website) -- war eine Flaeche
mit einem Rand. Jetzt: Verlauf statt Flaeche, Lichtkante
oben, Schatten nach unten. Beim Ueberfahren hebt sie sich,
der Schatten wird laenger, die Kante heller.
Alles bleibt gedeckt. Diese Kacheln stehen zu Dutzenden auf einer Seite
-- was einzeln beeindruckt, blendet im Dutzend.
GEPRUEFT: Buehne 38 (Textkontrast an echten Bildpunkten), Startansicht
133, Rollen 97, Handy 50, Grosscheck 15, Lesbarkeit 14, dazu die drei
Laeufe der oeffentlichen Seite (Startseite, Design, Barrierefreiheit).
Alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
46e62fbaf7 |
Die Kachelzeichen komplett neu -- Plaketten statt getoenter Quadrate
Rueckmeldung: "ich will dass die viel krasser aussehen, du veraenderst
immer nur minimal." Berechtigt. Drei Durchgaenge lang habe ich an
Details gedreht (Verlauf, dann Fuellung) -- jeder fuer sich richtig, in
der Summe kaum sichtbar. Das hier ist der Umbau.
DIE PLAKETTE war ein leicht getoentes Quadrat mit duennem Rand. Sie ist
jetzt ein KOERPER:
* 58 statt 52 px (gross: 70 statt 62)
* Verlauf ueber die Diagonale statt flacher Toenung
* Lichtkante oben INNEN, Schattenkante unten innen -- zusammen eine
Woelbung, das Feld wirkt gepraegt statt gemalt
* ein Hof in der eigenen Farbe darunter
* ein Glanzbogen darueber, der von links oben einfaellt
DAS ZEICHEN war eine duenne Kontur. Es besteht jetzt aus DREI Lagen mit
je eigenem Verlauf:
KOERPER gefuellte Grundform, oben satt, unten fast weg -- eine
gleichmaessig gefuellte Form ist ein Aufkleber, eine
auslaufende ist ein Koerper
GLANZ schmaler heller Streifen quer ueber die obere Haelfte,
genau auf dem Koerper. Die Spiegelung.
KONTUR oben fast WEISS, unten im Farbton. So sieht Metall aus, auf
das Licht von oben faellt -- das ist der Grund, warum die
Zeichen jetzt plastisch wirken statt gezeichnet.
Dazu 29 statt 25 px und Strichstaerke 2,05 statt 1,65: Die Zeichen
sollen TRAGEN, nicht andeuten. Zaghaft war genau das Problem.
Alle drei Verlaeufe stehen EINMAL im Dokument und arbeiten mit
currentColor -- sie nehmen den Ton jeder der siebzehn Kacheln an. Drei
Verlaeufe statt einundfuenfzig.
Alles bleibt gedeckt: Ein leuchtender Kasten waere in einer dunklen
Oberflaeche eine Lampe, und Lampen schaut man nicht stundenlang an.
Im Wasserzeichen hinter dem Kacheltext und im Kontrastmodus bleiben
Koerper und Glanz aus.
GEPRUEFT: Buehne 38 (Textkontrast an echten Bildpunkten -- die
kraeftigeren Plaketten duerfen die Lesbarkeit nicht antasten),
Startansicht 133, Rollen 97, Handy 50, Grosscheck 15, Lesbarkeit 14.
Alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
7d77f3ea6b |
Die Zeichen bekommen eine Flaeche -- aus Konturen werden Piktogramme
"ich will die symbole in den kacheln noch viel krasser und geiler."
Bis eben war jedes Zeichen eine reine Kontur. Sauber, aber neutral --
siebzehn gleich starke Umrisse nebeneinander, wie aus jedem
Symbolbaukasten.
Jetzt besteht jedes aus ZWEI Teilen:
FUELLUNG eine gefuellte Grundform, gedeckt hinterlegt
LINIE die scharfe Zeichnung darueber, mit dem Verlauf von gestern
Das ist der Unterschied zwischen einem Symbol und einem Piktogramm.
Sobald ein Teil FLAECHE hat, bekommt das Zeichen ein Vorn und ein
Hinten, und das Auge erkennt es, ohne es zu lesen.
Gefuellt wird immer das, WORUM ES GEHT -- nie alles:
Kalender der Kopf des Blattes (daran erkennt man ihn aus drei Metern)
Aufgaben die mittlere Spalte -- "in Arbeit", dort passiert etwas
Dashboard zwei der vier Felder ueber Eck, das gibt Rhythmus
Ordner der Korpus ohne die Lasche, damit die Stufe sichtbar bleibt
Berichte aus drei Strichen werden drei SAEULEN (ein Balkendiagramm
hat Balken)
Start-Check nur der Haken -- ein gefuelltes Klemmbrett waere ein Kasten
Personen der Kopf; bei zwei Personen nur der VORDERE, daraus
entsteht die Tiefe
Buch die linke Seite -- eine im Licht, eine im Schatten
Technik die drei Griffe
LIVE der Sender in der Mitte; gefuellte Wellen saehen aus wie
ein Auge
Trichter nur der obere Teil, sonst kippt das Zeichen nach unten
20 % Deckkraft sind gemessen, nicht geraten: darueber wird das Zeichen
zum Fleck und die Linie darin unsichtbar, darunter sieht man die Flaeche
gar nicht. Beim Ueberfahren geht sie auf 30 %, als kaeme Licht dazu.
WARUM NICHT EINFACH DICKER -- der Unterschied zum gescheiterten Versuch
von gestern: Der legte eine dicke, WEICHGEZEICHNETE KOPIE DER LINIE
darunter und hat damit jede Luecke zugeschmiert (aus dem Kalender wurde
ein leerer Kasten). Eine Flaeche ist etwas anderes als ein aufgeblasener
Strich: Sie liegt INNERHALB der Kontur und laesst die Zwischenraeume
unberuehrt. Genau deshalb funktioniert es jetzt.
Im Wasserzeichen und im Kontrastmodus bleibt die Flaeche aus -- dort
wuerde sie den Text hinterlegen bzw. zu einem massiven Block werden.
GEPRUEFT: Buehne 38 (Textkontrast an echten Bildpunkten -- die Flaeche
darf die Lesbarkeit nicht antasten), Startansicht 133, Rollen 97,
Handy 50, Team 30, Grosscheck 15, Lesbarkeit 14. Alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
a9815e291a |
Ein Hintergrund fuer alles -- und Zeichen, die endlich vollstaendig sind
ZWEI AUFTRAEGE.
1. DER NEUE HINTERGRUND
Das Dogfather/Spicy-Media-Bild loest die neun Buehnen ab. Der Login
behaelt ausdruecklich sein eigenes Bild (body.gate, unangetastet) --
dort wird der Zugangscode eingegeben, und genau das sollte bleiben.
Nicht einfach hingelegt: Das Bild ist sehr kraeftig, vor allem die
rote Haelfte. Ohne Behandlung fiel der Textkontrast auf 3,03:1
(noetig sind 4,5:1) -- ausgerechnet in der Personenverwaltung und auf
dem Aufgabenbrett. Gemessen hat das server/pruef-buehne.mjs, das den
Kontrast an bis zu 36 echten Bildpunkten je Seite nachrechnet.
In vier Schritten angepasst und jedes Mal nachgemessen:
-0,14 Helligkeit -> 4,12:1 (immer noch zu wenig)
-0,20 Helligkeit -> 4,48:1 (zwei Hundertstel zu wenig)
-0,23 Helligkeit -> 4,63:1 bestanden, alle Seiten
Dazu Saettigung 0,72 und Gamma 0,91 -- dieselbe Behandlung, die auch
die alten Buehnen bekommen haben (tools/buehne-bauen.mjs arbeitet mit
Helligkeit 0,66 bis 0,88). Das Bild bleibt ein Bild und wird nicht
zur Tapete, aber Text steht darauf lesbar.
2. DIE ZEICHEN
Sie bekommen einen VERLAUF: oben hell, nach unten gedaempft -- eine
Lichtquelle ueber dem Zeichen, wie in der echten Welt. Dazu ein
weicher Schlagschatten in der eigenen Farbe. Der Verlauf ist EINMAL
definiert und arbeitet mit currentColor: ein Verlauf fuer siebzehn
Kachelfarben.
ZWEI SACKGASSEN AUF DEM WEG, beide aufgeschrieben statt weggeraeumt:
a) Erst lag unter jeder Linie eine dicke, weichgezeichnete Kopie --
"Licht, das die Linie wirft". Bei einem grossen Symbol traegt das.
Hier nicht: Ein Zeichen ist 24 Einheiten breit und 25 px gross,
eine Einheit ist also ein Pixel. Linie 1,65 plus Schein 2,5 fuellt
jede Luecke, die enger als vier Einheiten ist -- aus dem Kalender
wurde ein leerer Kasten. Gesehen habe ich das erst bei dreifacher
Vergroesserung; auf dem normalen Schirm sah es nur "satter" aus.
Die Lage ist wieder weg.
b) Der Verlauf lief zunaechst in OBJEKTKOORDINATEN. Damit wird er auf
den Umriss jedes einzelnen Pfades gerechnet -- und eine waagerechte
Linie hat die Hoehe null. Der Verlauf ist dann entartet, und der
Browser zeichnet den Pfad GAR NICHT. Verschwunden waren dadurch:
die Querlinie im Kalender, alle drei Regler-Striche in Technik,
die Grundlinie der Berichte. Jetzt laeuft er in Benutzer-
koordinaten ueber die festen 24 Einheiten -- was ohnehin richtiger
ist, denn das Licht kommt von oben und nicht von jedem Strich
einzeln.
AUSSERDEM ECHT REPARIERT: Das Technik-Zeichen hatte drei Griffe aus
Boegen der Laenge null ("a1.4 1.4 0 1 0 0-.02z") -- sie wurden nie
gezeichnet. Uebrig blieben drei nackte Striche, die aussahen wie ein
Menue-Symbol. Jetzt sind es echte Kreise. Kalender und Dashboard haben
mehr Luft zwischen ihren Linien bekommen, damit sie bei 25 px nicht
zu einer Flaeche verschmelzen.
GEPRUEFT: Buehne 38 (Kontrast an echten Bildpunkten), Startansicht 133,
Rollen 97, Handy 50, Grosscheck 15, Lesbarkeit 14 -- alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
0404f8c0c1 |
Dreizehn Lecks: eine Managerin sah die Creator aller anderen
Wunsch: "jeder manager soll auch immer nur seine und die seiner scouts
zugeteilten creator und creator daten sehen. und nicht die der anderen."
DIE KETTE WAR GEBAUT -- SIE WURDE NUR NICHT BENUTZT
Manager -> seine Scouts -> deren Creator steht seit dem 01.09.2026 an
genau einer Stelle (betreuteIds). Die Frage war eine andere: Benutzt sie
auch JEDER Weg, der Creator-Daten herausgibt? Ueber zwanzig Stellen
prueften die ROLLE statt der ZUTEILUNG -- "ist Leitung? dann alles".
NICHT GELESEN, SONDERN GEMESSEN
server/pruef-manager-sicht.mjs baut zwei Managerinnen mit vollstaendig
getrennten Creators. Bei der fremden heisst ALLES "GEHEIM..." -- Aufgabe,
Termin, Bereichseintrag, Datei, Steckbrief, Content-Saeule. Danach wird
jede der 31 Leseschnittstellen abgefragt und die ganze Antwort danach
durchsucht. Ein Leck faellt damit auf, egal wo es sitzt und egal, ob ich
es beim Lesen uebersehen haette.
GEFUNDEN: DREIZEHN. Alle geschlossen:
Kalender fremde Fristen -- besonders unangenehm, weil es
nicht wie ein Leck aussieht: eine kleine orange
Marke mit einem Titel, in dem fremde Vorhaben stehen
Personenauswahl alle Namen im Zuweisungsfeld
Dateien alle Namen in der Freigabe-Auswahl
Uebersicht Gesamtuebersicht ueber ALLE Creator
Report Auswahl UND Auswertung ueber den ganzen Bestand
Start-Check alle Creator zur Auswahl
Steckbriefe Bild, Kanaele, "ueber mich" von allen
Profile alle Profile, samt interner Notiz
Schulung Schulungsstand aller Creator
Suche Creator-Profile aller -- die unauffaelligste Stelle:
Man sucht etwas anderes und bekommt fremde Namen
Content-Balance Themensaeulen fremder Kanaele (die Abfrage daneben
war korrekt eingeschraenkt, DIESE hatte eine eigene
Bedingung)
darfCreator eine einzige Zeile -- sie hing an Profil,
Start-Check und Uebersicht gleichzeitig. Es reichte,
eine Nummer in die Adresse zu schreiben.
Die Antwort steht jetzt an EINER Stelle: sichtbareCreatorIds und
sichtbarePersonenIds in workspace.js. Rueckgabe null heisst "alle" und
gilt allein DogFather -- bewusst kein leeres Feld: Eine leere Liste
bedeutet "niemand", und die Verwechslung der beiden macht aus einer
Sperre eine Freigabe.
ZWEI DINGE, DIE ICH MIR SELBST NACHTRAGEN MUSS
1. Beim Stopfen fehlte einmal ein Import. Der Weg warf einen Fehler,
antwortete 503 -- und weil in einer Fehlermeldung kein "GEHEIM" steht,
meldete die Pruefung "kein Leck". Sie war gruen, weil der Weg KAPUTT
war. Die Pruefung zaehlt jetzt beides: nichts durchsickern UND
antworten.
2. Ein Fehlalarm: Die Suche gibt den SUCHBEGRIFF in ihrer Antwort
zurueck. Wer nach "GEHEIM" sucht, findet das Wort zwangslaeufig --
auch bei null Treffern. Ich haette um ein Haar ein Leck "repariert",
das es nie gab. Das Echo wird jetzt entfernt, bevor gemessen wird.
FOLGEN, bewusst in Kauf genommen:
* Ein Manager ohne Zuteilung sieht keinen Creator. Die Uebersicht sagt
ihm das jetzt in einem Satz, statt leer zu bleiben.
* Er kann nur noch IN SEINEN Creator-Bereichen schreiben (darfCreator).
ZWEI PRUEFUNGEN UMGEDREHT statt geloescht -- eine geloeschte Pruefung
hinterlaesst keine Spur davon, dass hier einmal etwas anderes galt:
pruef-uebersicht ("Manager sieht dasselbe" -> "nur seine zugeteilten",
mit beiden Faellen) und pruef-scout-zuteilung ("sieht die ganze
Personenliste" -> "landet auf der Startseite").
GEPRUEFT: 43 neue Pruefungen, dazu 23 bestehende Laeufe gruen --
Startansicht 133, Rollen 97, Kalender 84, Serien 67, Steckbrief 65,
Handy 50, Sicht 48, Ampel 47, Content 45, Aufgabenbrett 44, Schulung 41,
Bereiche 37, Scout-Zuteilung 36, Uebersicht 35, Personenliste 33,
Freie Namen 32, Team 30, Protokoll-Loeschen 20, Personenformular 20,
Formulare 19, Betreuung 18, Code 17, Grosscheck 15.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d8720debc1 |
Personen & Automationen gehoeren DogFather allein -- und das Formular laeuft nicht mehr ueber
ZWEI MELDUNGEN.
1. "DAS SIEHT JA MAL RICHTIG SCHEISSE AUS"
Die Rollenauswahl im Formular "Neue Person" lief unten aus dem
Formular heraus und legte sich ueber die Personenliste darunter.
Die Ursache war keine schlampige Gestaltung, sondern eine Regel, die
fuer etwas anderes gemacht ist: `.neu__raster > *` (aufgaben.css) gibt
JEDEM direkten Kind ein Raster mit fester Zeilenhoehe von 44 px, damit
Beschriftung und Eingabefeld in allen Spalten auf einer Linie sitzen.
Fuer ein einzeiliges Feld ist das genau richtig. Die Rollenauswahl ist
aber kein Feld, sondern ein Block aus vier hohen Karten -- die passten
nicht in 44 px, und was nicht hineinpasst, steht eben daneben.
Das Formular ist jetzt aus dem Spaltenraster geloest und liest sich
von oben nach unten: NAME (schmal, ein Name braucht keine 1200 px),
ROLLE (volle Breite, vier gleich breite Karten), Knoepfe. Das ist
nicht nur reparierter Ueberlauf, sondern auch die Reihenfolge, in der
man die Sache tatsaechlich entscheidet.
Dazu zwei Kleinigkeiten, die den Unterschied machen: Das Namensfeld
war ohne Rasterzeile 60 px hoch geworden (`height: 100%` einer Zeile,
die es nicht mehr gibt) -- hoeher als die Knoepfe daneben, was nach
Versehen aussieht, weil es eins war. Und die gewaehlte Rolle traegt
jetzt ein HAEKCHEN, nicht nur einen etwas helleren Rahmen: Genau die
Art Unterschied, die im Kontrastmodus verschwindet und fuer
farbunsichere Augen nie existiert hat.
2. "DIE MANAGER SOLLEN DIESE KATEGORIEN GARNICHT SEHEN"
"Personen & Zugaenge" und "Automationen" gehoeren ab sofort allein
DogFather.
Bei den Personen war es ohnehin ein Widerspruch im eigenen Haus: In
der Rollenauswahl steht seit jeher "Manager -- dieselben Rechte wie
DogFather, AUSSER der Personenverwaltung". Die Kachel stand trotzdem
bei ihm, und die Schranke liess ihn hinein: Codes erneuern, sperren,
Zuteilungen aendern. Eine Beschreibung, die etwas anderes sagt als die
Software, ist schlimmer als beides einzeln -- man weiss danach nicht
mehr, welcher von beiden man glauben soll.
Umgesetzt auf DREI Ebenen, weil Wegnehmen was man SIEHT kein
Rechteentzug ist:
1. die Kachel erscheint nicht mehr
2. die Seite leitet zur Startseite zurueck (GESCHUETZT)
3. die Schnittstellen antworten mit 404 -- Personenverwaltung,
Systemzustand, KI-Schalter
FOLGE, die bewusst in Kauf genommen wird: Die Betreuungs-Zuteilung
liegt auf der Personenseite. Ab jetzt kann also NUR DogFather
festlegen, wer welchen Creator betreut.
GEPRUEFT: server/pruef-personen-formular.mjs, 20 Pruefungen. Das Aussehen
wird gemessen, nicht angesehen: Endet die Rollenauswahl innerhalb des
Formulars? Ragt eine Karte seitlich hinaus? Liegt etwas ueber der Liste?
Sind alle vier Karten gleich breit (272-272 px)? Traegt die gewaehlte ein
Haekchen? Dazu zwei Gegenproben: DogFather kommt weiterhin an beide
Bereiche (sonst waere jede Sperr-Zeile auch bei einem fuer ALLE kaputten
Bereich gruen), und die Managerin arbeitet ansonsten unveraendert weiter.
Bestehende Laeufe gruen: Rollen 97, Handy 50, Sicherung 41, Personenliste
33, Team 30, Formulare 19, Code 17, Grosscheck 15.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
fc26597083 |
Wer sich einen neuen Code gibt, sperrt sich nicht mehr selbst aus
Gemeldet: "ich hab einen neuen code fuer mich gemacht aber ich wurde raus
gekickt bevor ich den neuen code kopieren konnte jetzt komm ich nicht mehr
rein."
DER FEHLER
Ein neuer Code beendete ALLE Sitzungen der Person -- auch die, in der der
Code gerade auf dem Bildschirm stand. Der naechste Aufruf der Seite lief in
ein "nicht angemeldet", die Umleitung zur Anmeldung nahm den Kasten samt
Code mit, und der Code ist nirgends noch einmal abrufbar (in der Datenbank
steht nur seine Pruefsumme). Ergebnis: ausgesperrt, Rueckweg nur ueber
einen Eingriff auf dem Server.
Bitter daran: Die Rueckfrage sagte das sogar an ("Deine aktuelle Sitzung
wird sofort beendet") -- als Warnung formuliert, nicht als Fehler erkannt.
Ein Ablauf, den man nur mit gutem Timing ueberlebt, ist keiner.
DREI RIEGEL, NICHT EINER
1. DIE EIGENE SITZUNG BLEIBT. codeNeu() beendet weiterhin alle Sitzungen
der Person -- ausser der einen, aus der heraus der Code gerade erneuert
wird. Sicherheitlich kostet das nichts: Wer den Code tauscht, hat sich
mit genau dieser Sitzung soeben ausgewiesen und haelt sie in Haenden.
Alle ANDEREN Geraete fliegen weiterhin hinaus -- das ist der Sinn der
Uebung und wird eigens geprueft.
2. DER KASTEN BLEIBT STEHEN. Solange ein frischer Code angezeigt wird,
springt die Personenseite nicht mehr von selbst zur Anmeldung. Selbst
wenn eine Sitzung aus einem anderen Grund endet (Zeitablauf, Neustart),
bleibt der Code lesbar, bis er weggeklickt ist -- mit einem Hinweis,
ihn jetzt abzuschreiben. Ein Code, den man nicht mehr lesen kann, ist
schlimmer als gar keiner.
3. EINE TUER VON AUSSEN: tools/notfall-code.sh. Setzt auf dem Server einen
neuen Code, zeigt ihn an und loescht die Sperre nach acht Fehlversuchen
gleich mit. Weigert sich, als root zu laufen (sonst gehoerten die
Hilfsdateien der Datenbank danach root und der Dienst koennte nicht
mehr schreiben). Dokumentiert als "Fall 0" in WIEDERHERSTELLUNG.md --
dem ersten Fall, den man aufschlaegt, wenn nichts kaputt ist ausser
dem Zugang.
KEIN fest hinterlegter Notfall-Code in der Anwendung: Der waere eine
Hintertuer, die dauerhaft offensteht, fuer jeden der sie findet, ohne
dass es auffiele. Dieser Weg verlangt Zugang zum Server, hinterlaesst
einen Protokolleintrag, und es gibt nichts zu erraten.
Die Rueckfrage sagt jetzt, was wirklich passiert, statt vor etwas zu
warnen, das nicht mehr eintritt.
GEPRUEFT: server/pruef-code.mjs, 17 Pruefungen -- darunter die Gegenprobe,
dass das ZWEITE Geraet derselben Person sehr wohl abgemeldet wird (ohne sie
waere die Reparatur auf dem Weg, einen neuen Code zur Formalie zu machen),
dass der alte Code nicht mehr gilt, dass beim Erneuern eines FREMDEN Codes
weiterhin alles hinausfliegt, und dass die Seite nach dem Erzeugen nicht
zur Anmeldung springt. Das Notfall-Skript ist mit beiden Wegen getestet
(Treffer und unbekannter Name). Bestehende Laeufe gruen: Rollen 97,
Personen-Liste 33, Sicht 48.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
540b5d8838 |
Freie Namen, ein Call-Knopf, und drei Seiten, die fuer Scouts kaputt waren
DREI SACHEN AUF EINMAL, alle aus derselben Sitzung.
1. AUSSUCHEN ODER SELBST EINTRAGEN
Wunsch: "ich will da auch sachen selber noch eintragen koennen, also
aussuchen und selbst eintragen."
Jede Personenauswahl (Kalender, Aufgaben, Bereiche, Content, Dateien)
nimmt jetzt auch einen getippten Namen an -- eine Agentur, eine Marke,
einen Gast ohne Konto. Dazu bekommt JEDE Auswahl ab acht Eintraegen
ein Suchfeld: tippen statt scrollen.
Gebaut IM vorhandenen Auswahl-Bauteil (wahl.js), nicht daneben. Der
erste Anlauf war ein zweites Bauteil -- es hat sich prompt mit dem
ersten gebissen, beide haben denselben <select> eingepackt. Ein
zweites haette ausserdem anders ausgesehen und waere beim naechsten
Umbau nur an einer von zwei Stellen nachgezogen worden.
Der freie Name steht in einer EIGENEN Spalte je Feld; die Verknuepfung
bleibt leer. Entweder eine Person ODER ein Name, nie beides.
Filipe hat ausdruecklich auch bei den Creator-Feldern freie Namen
gewollt, nachdem der Nachteil benannt war: Der Eintrag gehoert dann zu
keinem Konto. Damit daraus kein STILLER Ausfall wird, faellt jede
Abfrage, die bisher den Namen der verknuepften Person las, jetzt auf
den freien Text zurueck (externSql) -- gekennzeichnet als "(extern)".
Der Eintrag verschwindet dadurch aus keiner Liste, keiner Suche und
keiner Uebersicht.
2. WO FUEHRE ICH DEN CALL?
Den Knopf gab es, aber nur wenn jemand von Hand einen Link ins
Ortsfeld getippt hatte UND das Gespraech noch bevorstand. Stand dort
"Hier", war nichts zum Anklicken da.
Jetzt hat das Team einen festen Call-Raum (Discord-Sprachkanal), den
das Management einmal hinterlegt. Danach hat JEDER Call den Knopf --
und er bleibt, solange das Gespraech laufen kann, nicht nur bis zur
Startzeit. Ein eigener Link am Termin schlaegt den festen Raum.
3. WAS EINE ROLLE SIEHT, MUSS AUCH FUNKTIONIEREN
Gemeldet: "cigdem kriegt als manager gewisse sachen nicht auf die sie
sieht, check jede rolle ab."
Neue Pruefung server/pruef-rollen.mjs schickt SECHS Rollen-Zustaende
ueber alle 16 Seiten und misst Konsolenfehler, fehlgeschlagene
Serveraufrufe, tote Verweise, haengende Ladeanzeigen und wortlos leere
Seiten. 96 Durchgaenge.
Der sechste Zustand ist der wichtige: eine Rolle OHNE zugeteilte
Creator -- der Normalfall am ersten Tag und Cigdems echte Lage.
Genau dort fielen die Seiten durch, waehrend dieselben Seiten MIT
Zuteilung tadellos waren.
VIER ECHTE FEHLER GEFUNDEN UND BEHOBEN:
a) Eine Aufgabe, die eine Managerin ohne Creator anlegte, war fuer sie
im selben Moment unsichtbar -- creator_id und verantwortlich_id
leer, und "von mir selbst angelegt" stand in keiner
Sichtbarkeitsregel. Nur DogFather sah sie noch. Kein Fehler, keine
Meldung, die Aufgabe war einfach weg. Dasselbe bei den
Bereichseintraegen. Beide Regeln kennen jetzt erstellt_von.
Niemand sieht dadurch etwas Fremdes -- nur das Eigene.
b) Ein Scout ohne zugeteilten Creator bekam auf die GESAMTE
Report-Seite 404, obwohl sie fuer ihn verlinkt ist. Die Seite
antwortet jetzt sauber und leer, statt sich zu verweigern.
c) Start-Check und Report blieben fuer immer auf "wird geladen"
stehen, wenn es nichts zu laden gab.
d) Das Creator-Profil war fuer Scouts ohne Zuteilung wortlos leer --
der erklaerende Satz stand nur in der grauen Unterzeile.
Ausserdem meldete die bestehende Lesbarkeitspruefung zwei neue
Beschriftungen von mir als zu klein fuers Handy (10,88 statt 11,5 px).
Behoben, und dieselbe Groesse an der Serien-Karte gleich mit -- dort
waere es erst aufgefallen, sobald jemand eine Wiederholung anlegt.
GEPRUEFT: pruef-rollen 97, pruef-freie-namen 32 (mit Gegenproben:
Ben sieht Cigdems Aufgabe NICHT; die Saeulen-Zuordnung nimmt
ausdruecklich KEINEN freien Namen). Alle bestehenden Laeufe gruen:
Startansicht 133, Kalender 84, Serien 67, Protokoll 52, Handy 50, Sicht
48, Ampel 47, Content 45, Aufgabenbrett 44, Sprung 43,
Personen-Loeschen 40, Bereiche 37, Uebersicht 33, Workspace-Seiten 32,
Formulare 19, Betreuung 18, Grosscheck 15, Lesbarkeit 14.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
23429627ef |
Termine, die von allein weiterlaufen -- bis man sie abstellt
Wunsch: "ich will dass ich da im kalender auch sachen machen die jede
woche jeden monat automatisiert immer weiter laufen so wie ich es
auswaehle bis ich es selber deaktiviere. aktiviere diese option fuer
jeden."
Acht Rhythmen (taeglich, werktags, woechentlich, alle zwei Wochen,
monatlich am Datum, am Monatsletzten, am n-ten Wochentag, jaehrlich),
wahlweise mit Enddatum oder ohne Ende. Fuer JEDE Rolle -- Creator und
Scouts legen sie fuer sich selbst an, mit denselben Grenzen wie beim
einzelnen Termin.
WARUM ECHTE TERMINE UND KEINE GERECHNETEN AUSPRAEGUNGEN
Der naheliegende Weg waere gewesen, die Wiederholung nur beim Anzeigen
auszurechnen. Das waere ein stiller Ausfall geworden: ACHT andere Stellen
lesen die Tabelle termine direkt -- Calls, Protokolle, Berichte,
Hinweise/Ampel, Suche, Aufgaben ("naechster Termin"), Uebersicht und die
Startseite. In all diesen Ansichten haette schlicht nichts gestanden, und
aufgefallen waere es erst Monate spaeter. Stattdessen macht ein
Nachfueller aus der Regel echte Zeilen (Horizont 180 Tage) -- jedes andere
Modul sieht sie mit, ohne dass dort eine Zeile geaendert werden musste.
Beim geplanten ICS-Abo gilt dasselbe.
KEIN ZEITGEBER. Der Nachfueller laeuft beim Serverstart, beim Anlegen und
Aendern und beim Oeffnen des Kalenders (dort hoechstens alle fuenf
Minuten). Er ist idempotent. Ein Cron waere eine weitere Sache gewesen,
die stillschweigend ausfallen kann.
WAS BEIM ABSTELLEN PASSIERT: Vergangene Termine und alles, was jemand von
Hand angefasst hat (verschoben, umbenannt, abgehakt), bleibt stehen. Nur
die unberuehrte Zukunft wird aus dem Kalender genommen. Wer einen
einzelnen Tag loescht, streicht nur diesen einen -- der Tag wird als
Ausnahme vermerkt, sonst legte der Nachfueller ihn wieder an.
ZEITUMSTELLUNG: Gerechnet wird auf reinen Datumstexten in UTC-Mittag, die
Uhrzeit wird als Text angehaengt. 18:00 bleibt dadurch 18:00 und wandert
im Oktober nicht auf 17:00.
DIE SICHTBARKEITSREGEL STEHT JETZT NUR NOCH EINMAL (workspace.js,
termineSichtbar) statt zweimal fast gleich. Zwei Fassungen waeren
auseinandergelaufen -- und dann haette eine Wiederholung jemandem etwas
gezeigt, was der einzelne Termin ihm verbirgt.
IN DER OBERFLAECHE beschriften sich die Rhythmen nach dem gewaehlten
Datum ("jeden Dienstag", "jeden Monat am letzten Dienstag") statt
abstrakt ("woechentlich"), inklusive des ehrlichen Hinweises, dass "jeden
31." den Februar auslaesst. Darunter steht der ganze Satz in Worten. Eine
neue Leiste "Laeuft von allein" zeigt alle laufenden Wiederholungen mit
Abstell-Schalter -- was von selbst weiterlaeuft, muss man sehen koennen.
GEPRUEFT: 67 Pruefungen (server/pruef-serien.mjs), darunter von Hand
nachgeschlagene Datumsangaben fuer jeden Takt (der letzte Dienstag im
Dezember 2026 ist der 29., nicht der 22.; der 29. Februar nur in
Schaltjahren) und vier GEGENPROBEN, die beweisen, dass die Pruefungen
auch "nicht in Ordnung" sagen koennen. Die Anzahl der Pruefungen steht in
der Bedingung, nicht nur im Meldetext. Bestehende Pruefungen unveraendert
gruen: Kalender 84, Sicht 48, Startansicht 133, Protokoll 52, Ampel 47,
Handy 50, Aufgabenbrett 44, Sprung 43, Personen-Loeschen 40, Uebersicht
33, Workspace-Seiten 32, Formulare 19, Betreuung 18, Grosscheck 15,
Lesbarkeit 14.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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]> |
||
|
DogFatherGitandClaude Opus 5
|
60c3edb10d |
Verirrte Datei aus dem Worker-Ordner entfernt -- Wert vorher geprueft
Im Ordner cloudflare-worker/ lag seit dem 12.08.2026 eine Datei, deren
Name ein verunglueckter Windows-Pfad ist
("UsersqcigaDocumentsObelixDogFather.tmp-new-code.txt"). Darin: eine 14
Zeichen lange Zufallszeichenfolge. Sie kam mit dem Commit "Alle
ausstehenden Aenderungen fuer den Server-Umzug uebernommen" herein --
offensichtlich versehentlich.
WARUM SIE AUFFIEL: Von aussen sah sie aus wie ein offen liegender
Zugangscode. Ueber die Website war sie zwar nicht erreichbar (sie liegt
ausserhalb der ausgelieferten Ordner, 404) -- aber aus Gitea konnte sie
JEDER ohne Anmeldung abrufen: 200, 14 Bytes.
WAS DIE PRUEFUNG ERGAB, und deshalb steht sie hier fuer immer
nachlesbar, damit niemand sie ein zweites Mal machen muss:
* Der Wert ist KEIN gueltiger Zugangscode. Geprueft mit genau der
Rechnung, die auch die Anmeldung benutzt (scrypt mit dem Salz jeder
Person, timingSafeEqual gegen den gespeicherten Hash):
6 Personen geprueft, 0 Treffer.
* Die Website-Schranke von vor dem Go-Live ist nicht mehr in Betrieb --
der Dienst dogiweb setzt ueberhaupt keine Zugangscodes.
* Der Wert steht an keiner anderen Stelle im Code.
Er war also wertlos. Geloescht wird die Datei trotzdem: Sie SIEHT aus
wie ein Geheimnis, und der Naechste, der sie findet, macht dieselbe
Untersuchung noch einmal.
Zur Klarheit, falls das je wieder aufkommt: Ein Loeschen im Verzeichnis
entfernt nichts aus der Historie. Waere der Wert gueltig gewesen, waere
das Loeschen die falsche Antwort gewesen -- dann haette der Code
GEAENDERT werden muessen. Hier ist beides unnoetig, weil er nie gegolten
hat.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
bd42a0462e |
Cache-Stempel nachgezogen -- sonst waere die Aenderung nicht angekommen
Der vorige Commit aenderte personen.js, aber die HTML-Dateien trugen weiterhin den alten Stempel (?v=202609020145). Cloudflare liefert Dateien vier Stunden lang aus dem Zwischenspeicher: Die neue Auswahl "Gehoert zu" waere bis in den Vormittag hinein bei niemandem angekommen -- und der Deploy haette dabei fehlerfrei ausgesehen. Aufgefallen ist es nur, weil in `git status` keine einzige HTML-Datei stand. Genau das ist das Merkmal: Wer JS oder CSS aendert und danach keine geaenderten HTML-Dateien sieht, hat den Stempel vergessen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
9134b30d06 |
Scouts gehoeren zu einem Manager ODER zu DogFather -- wie bei den Creatorn
Wunsch vom 02.09.2026: "ich will die Rollen, welcher Scout welchem
Manager oder DogFather gehoert, wie es bei den Creator ist, drunter."
Die Auswahl stand bisher nur dann unter einem Scout, wenn es ueberhaupt
einen Manager gab -- und es gibt zurzeit keinen. In der Personenliste war
davon also nichts zu sehen. Jetzt steht sie immer da, mit Managern UND
DogFather zur Wahl, genau wie "Betreut von" bei den Creatorn.
DIE BEIDEN FAELLE BEWIRKEN VERSCHIEDENES, und das ist Absicht:
MANAGER Der Eintrag entscheidet ueber SICHTBARKEIT -- er sieht
danach die Leads dieses Scouts und dessen Creator.
DOGFATHER Der Eintrag haelt nur die ZUSTAENDIGKEIT fest. An den
Rechten aendert er nichts; DogFather sieht ohnehin alles.
Genau diese Unterscheidung gilt bei den Creatorn seit dem 31.08. auch.
Vorher hatte ich einen Scout unter DogFather abgewiesen mit der
Begruendung, der Eintrag bewirke nichts. Das war zu eng gedacht: Er
beantwortet die Frage "wen frage ich?", und das ist der Zweck dieser
ganzen Liste.
Ein Scout unter einem Scout bleibt ausgeschlossen -- eine Ordnung, die
es nicht gibt.
ZWEI DINGE MITGEZOGEN, damit die Liste nicht zwei Sprachen spricht:
* Der Leerwert heisst wieder "— niemand —" wie bei den Creatorn.
"— direkt bei DogFather —" sah aus wie eine Zuordnung und war
keine -- derselbe Fehler war bei den Creatorn schon einmal behoben
worden, weil dieselben Leute dadurch gleichzeitig als "ohne
zustaendige Person" gezaehlt wurden.
* Die Rolle steht nur dann in Klammern, wenn sie etwas hinzufuegt.
"Dogfather (DogFather)" waere zweimal dasselbe Wort.
Die Pruefung haelt jetzt BEIDES fest: dass die Zuteilung an DogFather
geht -- und dass sie niemandem mehr Sicht gibt. Verschwimmt dieser
Unterschied je, faellt es dort auf.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
9e523d3ea2 |
Manager sehen nur noch ihre zugeteilten Scouts -- und deren Creator
Wunsch vom 01.09.2026: "er soll nur die Scouts sehen, die ihm zugeteilt sind." Dazu entschieden: Ein Manager sieht dann AUCH die Creator dieser Scouts, und zuteilen darf NUR DogFather. WAS VORHER WAR. Ein Manager sah die gesamte Scout-Pipeline -- alle Leads aller Scouts, dazu dieselben in der Suche und in "Was ist dran". Das war die letzte Stelle, an der "nur DogFather sieht alles" noch nicht galt. EINE EIGENE TABELLE, KEIN ZWEITER EINTRAG IN `betreuung`. Dort heisst die Spalte creator_id, und der ganze uebrige Code liest sie als "das ist ein Creator". Ein Scout darin waere technisch moeglich und fachlich eine Luege gewesen: betreuteIds() gaebe Scout-Nummern zurueck, die anderswo als Creator behandelt wuerden. Solche Abkuerzungen raechen sich genau dann, wenn niemand mehr weiss, dass sie getroffen wurden. DIE KETTE steht an EINER Stelle (betreuteIds in workspace.js): Manager -> seine Scouts -> deren Creator. Ohne sie muesste jeder Creator einem Manager einzeln zugewiesen werden, und beim ersten vergessenen faende er ein Loch in seiner Uebersicht, ohne zu merken, dass es eines ist. Dieselbe Regel gilt fuer Leads in Pipeline, Suche und Hinweisen -- aus einer Quelle (pipelineIds), nicht dreimal abgeschrieben. ZUTEILEN DARF NUR DOGFATHER, und das ist keine Foermlichkeit: Diese Zuteilung ERWEITERT die Sicht eines Managers. Duerfte er sie selbst setzen, koennte er sich seine eigene Sichtbarkeit vergeben -- eine Grenze, die der Begrenzte selbst verschieben kann, ist keine. Deshalb istDogFather und ausdruecklich NICHT istLeitung. In der Personenliste steht bei jedem Scout "Gehoert zu", sichtbar nur fuer DogFather. Der Leerwert heisst "— direkt bei DogFather —" und nicht "— niemand —": Ein Scout ohne Manager ist nicht unbetreut, er haengt an DogFather. Das ist ein Zustand, kein Mangel. NEBENBEI KORRIGIERT: In der Zustaendigkeits-Route stand als Kommentar noch "ein Eintrag auf DogFather oder Manager aendert an den Rechten nichts, die Leitung sieht ohnehin jeden Creator". Das gilt seit heute nicht mehr -- fuer einen Manager entscheidet dieser Eintrag jetzt sehr wohl ueber die Sichtbarkeit. Ein falscher Kommentar ist schlimmer als keiner: Er wird geglaubt. DIE PRUEFUNG STELLT DEN MISSBRAUCH AN DEN ANFANG. Diese Aenderung erweitert Sichtbarkeit -- alles andere heute hat sie eingeschraenkt. Ein Fehler dort zeigt jemandem zu wenig und faellt auf; ein Fehler hier zeigt zu viel und faellt niemandem auf. Geprueft wird deshalb: Manager und Scout duerfen nicht zuteilen (404, und es wird auch wirklich nichts geschrieben), Scout an Scout und Scout an DogFather werden abgewiesen, ein Creator laesst sich nicht zuteilen. Danach die Kette in beide Richtungen, das Zuruecknehmen, und dass ein Scout zu genau einem Manager gehoert. Ein lehrreicher Fehlschlag in der Pruefung selbst: Sie meldete, die Auswahl fehle in der Oberflaeche. Sie fehlte nicht -- die Personenliste ist nach Rollen ZUGEKLAPPT, und die Pruefung hatte nicht aufgeklappt. Sah aus wie ein Produktfehler, war einer der Pruefung. Sie klappt jetzt auf und stellt vorher fest, dass wirklich alle sieben Zeilen dastehen. Gesamtlauf: 30 von 30 Dateien, 1210 von 1210 Einzelpunkten. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
15cfee1078 |
Gesamtlauf aller Pruefungen -- und eine Pruefung, die nichts geprueft hat
Auf "CHECK MAL AB, DASS ALLES PERFEKT LAEUFT. ALLES."
Ergebnis: 29 von 29 Pruefdateien in Ordnung, 1178 von 1178 Einzelpunkten
bestanden. Der Server laeuft ohne Neustart, alle 33 oeffentlichen Seiten
antworten, keine Schnittstelle gibt ohne Anmeldung etwas heraus.
DER EIGENTLICHE FUND WAR EINE PRUEFUNG, DIE NICHTS GEPRUEFT HAT.
tools/alles-pruefen.mjs zaehlt nicht nur gruen/rot, sondern die ANZAHL
der Einzelpruefungen je Datei -- und pruef-kopf-messen.mjs kam auf NULL.
Sie war nie eine Pruefung, sondern ein reines Messwerkzeug: Sie druckte
Zahlen und endete IMMER mit Exitcode 0. Weil sie "pruef-..." heisst, lief
sie bei jedem Gesamtlauf mit und meldete brav "bestanden". Sie konnte
gar nicht fehlschlagen.
Mit blossem Auge war das nicht zu sehen: Der Lauf war gruen, die Datei
stand unauffaellig zwischen den anderen. Aufgefallen ist es nur, weil
die Zahl mitgezaehlt wurde -- ein gruener Lauf ist eben kein Beweis,
solange nicht auch die Anzahl stimmt.
ZWEI KONSEQUENZEN:
1. Die Datei prueft jetzt wirklich. Die beiden Zahlen, um die es geht,
wurden laengst gemessen und werden nun auch beurteilt:
UEBERSTAND muss 0 sein
ABMELDEN ERREICHBAR muss wahr sein -- es ist der einzige Weg wieder
heraus; liegt er ausserhalb des Bildes, sitzt
man fest.
Die Messwerte bleiben in der Ausgabe: Sie sagen bei einem Fehlschlag
sofort, WELCHES Teil zu breit ist.
Gegenprobe gemacht: Mit einer unerfuellbaren Bedingung meldet sie
"3 Breiten gemessen, 3 beanstandet" und endet mit 1. Sie kann also
anschlagen -- vorher nicht.
2. Der Laeufer wertet "0 Pruefungen" ab jetzt als FEHLER, nicht als
Erfolg. Sonst haette dieselbe Falle beim naechsten Mal wieder
jemanden getaeuscht.
Der Laeufer selbst bleibt im Ordner tools/: Er faengt einen Fehlschlag
je Datei ab (statt beim ersten abzubrechen), zeigt die Dauer mit -- eine
Pruefung, die ploetzlich dreimal so lange braucht, wartet meist auf
etwas, das es nicht mehr gibt -- und druckt am Ende die Gesamtzahl.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
da49a227f1 |
Aufgabenbrett fuer alle Rollen -- und nur DogFather sieht alles
Wunsch vom 01.09.2026: "verbessere die Aufgabenseite auch bei Manager,
Scout und Creator. Die Scouts und Manager sollen vielleicht ein bisschen
mehr Optionen haben, wie ihre zugeteilten Creator. Aber auch die Creator
sollen es besser und detaillierter sehen. ABER NUR DIE ROLLE DOGFATHER
SOLL WIRKLICH WEITERHIN ALLEINE ALLES SEHEN KOENNEN."
(Nachgereicht: "die Seite Aufgabe auch bei DogFather machen bitte.")
ZWEI FEHLER IN DEN RECHTEN, die beim Nachsehen herausfielen:
1. Ein MANAGER sah auf dem Aufgabenbrett GAR NICHTS. Die Regel kannte
nur admin, creator und scout; er fiel in den Zweig "unbekannte
Rolle sieht nichts". Ein leeres Brett sieht aus wie "nichts zu
tun", nicht wie ein Fehler -- deshalb ist das lange niemandem
aufgefallen.
2. In Kalender, Dateien, Bereichen und Content sah derselbe Manager
dagegen ALLES (istLeitung). Zwei entgegengesetzte Antworten auf
dieselbe Frage, in einem Programm.
Jetzt gilt ueberall dasselbe: NUR DogFather sieht alles. Manager und
Scout sehen ihre eigenen Sachen plus die Creator, die ihnen zugeteilt
sind. Dafuer arbeitet betreuteIds() jetzt auch fuer Manager -- die
Datenbank konnte das laengst (in `betreuung` steht eine beliebige
Person), nur diese eine Funktion hat alle ausser Scouts abgewiesen.
GEAENDERT WURDE NUR, WER WAS SIEHT. Was ein Manager DARF -- freigeben,
aendern, Personen verwalten -- haengt weiterhin an istLeitung und ist
unberuehrt. Ohne diese Trennung haette ein Wunsch nach weniger Sicht
stillschweigend die halben Rechte mitgenommen; die Pruefung haelt beides
ausdruecklich fest.
DIE SEITE SELBST bekommt drei Zeilen ueber dem Brett, und die
Reihenfolge ist die Aussage:
1. WAS BRENNT -- ein Satz beim Reinkommen. Ein Brett aus vier Spalten
beantwortet das nicht; man muesste alle vier durchsehen, um zu
wissen, dass nichts brennt.
2. AUSSCHNITTE -- "Nur meine", "Heute faellig", "Ueberfaellig", jeder
mit seiner Zahl am Knopf. Ein Filter, der sich erst nach dem Klick
als leer herausstellt, kostet zweimal Aufmerksamkeit. Sie filtern
das Brett, statt eine zweite Liste aufzumachen: Vier Spalten
nebeneinander sind der Wert dieser Seite.
3. DIE CREATOR -- fuer Betreuer und DogFather, je mit offener Anzahl
und einer Warnzahl fuer Ueberfaelliges. Bei DogFather heisst die
Reihe "Alle Creator", sonst "Deine Creator": "deine" waere bei ihm
eine falsche Auskunft.
Ein Creator bekommt weder "Nur meine" noch die Creator-Reihe -- bei ihm
ist ohnehin alles seins, und ein Filter mit einem einzigen Eintrag ist
ein Knopf, der nichts tut. Die Liste der Creator stammt aus den
Aufgaben selbst und nicht aus einer Personenabfrage: Dann stehen dort
genau die, die man ohnehin sehen darf, und niemals einer mehr.
NEBENBEI (Screen 1): In der Betreuer-Auswahl stand "Dogfather
(DogFather)" -- zweimal dasselbe Wort, nur anders geschrieben. Die
Klammer entfaellt jetzt, wenn sie dasselbe sagt wie der Name.
pruef-aufgabenbrett.mjs prueft die ABGRENZUNG zuerst und an konkreten
Aufgaben, deren Titel verraten, wem sie gehoeren -- eine huebschere
Filterleiste ist eine Annehmlichkeit, eine Rechteregel, die zu viel
zeigt, ist ein Schaden. Dazu eine Gegenprobe zur alten Regel (der
Manager sieht ueberhaupt etwas) und die ausdrueckliche Bestaetigung,
dass er weiterhin anlegen darf.
Ein Fehler steckte in der Pruefung selbst: Sie erwartete beim Creator
eine feste Zahl und haing damit von ihrer eigenen Reihenfolge ab -- der
Abschnitt davor legt eine weitere Aufgabe an. Sie vergleicht jetzt gegen
die Schnittstelle. Das ist ohnehin die bessere Frage: nicht "sind es
drei", sondern "verschluckt die Seite etwas".
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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]> |
||
|
DogFatherGitandClaude Opus 5
|
24c66a022e |
Kennzahlen-Reihe auf der Content-Seite entfaellt
Wunsch: "diese Kisten sind jetzt ueberall zu viel, die sollen weg." Nur die Content-Seite (nachgefragt): Vorrat, Veroeffentlicht, Ideen, ohne Hook, ueberfaellig. Die Reihe auf der Startseite und die Kisten im Report bleiben -- letztere sind der Report. Sie hatte auch inhaltlich kein Recht mehr: Die Strecke direkt darunter zeigt Ideen, Produktion und Veroeffentlichtes ohnehin mit Zahl an jeder Spalte. Zwei Zaehler fuer dieselbe Sache auf einem Bildschirm sind einer zu viel -- und laufen frueher oder spaeter auseinander. WAS BLEIBT UND WARUM: Die Abfrage /workspace/api/content/kennzahlen wird NICHT entfernt. Aus derselben Antwort speist sich der Saeulen-Balken darunter (70/20/10). Die Funktion heisst jetzt zahlenLaden() statt kennzahlenLaden() -- der alte Name zeigte auf etwas, das es nicht mehr gibt. Entfernt sind neben der Reihe auch .kachel, .kachel__wert, .kachel__name und .kachel__zusatz aus content.css. Achtung fuer spaeter: "kachel" gibt es auch in start.css und report.css, mit ganz anderen Regeln. Diese drei Kopien haben nichts miteinander zu tun; ein Kommentar an der Fundstelle sagt das jetzt. DIE PRUEFUNG WURDE UMGEDREHT, NICHT GELOESCHT. pruef-content-ansicht.mjs sicherte bisher "fuenf Kennzahlen" -- jetzt sichert sie, dass keine da ist. Eine geloeschte Pruefung merkt niemand, wenn jemand die Reihe spaeter versehentlich wieder einbaut. Die Zahlen selbst bleiben geprueft: pruef-content.mjs prueft Vorrat, ohne Hook und ueberfaellig weiterhin an der Schnittstelle (Abschnitt 5 und 6). Entfallen ist ihre Anzeige, nicht ihre Richtigkeit. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
d4cd8952b7 |
Checklisten-Gruppen klappen zu, Markierungen tragen ein Zeichen
Zwei Wuensche vom 01.09.2026:
"neben den Titel soll immer ein Knopf sein, wo man die Liste aufmacht
oder wieder zumacht -- die sollen auch zu, damit die Seiten nicht so
lang sind."
"und wenn die Ansprechpartner was markieren, sollen die da so ein
Zeichen haben, so dass die sehen, da ist was -- und es soll auch oben
in der Kachel angezeigt werden."
ZUKLAPPEN. Der Gruppenkopf ist jetzt ein Knopf ueber die volle Breite
(49 px hoch, mit dem Daumen treffbar), nicht ein Pfeilchen daneben. Zu
ist der Standard. Gemessen: Die LIVE-Analyse ist damit 1100 statt 2081
Pixel lang -- 47 Prozent gespart. Welche Gruppen offen waren, merkt sich
der Browser; sonst waere jede Bewertung ein Ruecksprung an den Anfang.
DAS ZEICHEN. Eine Raute mit Ausrufestrich, in Bernstein. Drei
Entscheidungen, keine davon Geschmack:
* FORM -- alles andere auf dem Bildschirm ist rund oder eckig. Eine
Spitze nach oben gibt es sonst nirgends, und deshalb findet das Auge
sie zwischen zwanzig Kacheln ohne Suchen.
* FARBE -- immer dieselbe, nie die der Kachel. Ein Zeichen, das die
Farbe wechselt, muss gelesen werden; eines, das immer gleich
aussieht, wird erkannt. Rot waere falsch: "verbessern" ist ein
Auftrag, kein Fehler.
* BEWEGUNG -- ein Atmen ueber 3,2 s, kein Blinken; bei "weniger
Bewegung" bleibt der Schein stehen statt zu verschwinden.
Es steht an drei Stellen, immer aus derselben Quelle (bereiche.js): am
Gruppenkopf, am Punkt selbst und oben auf der Kachel der Startseite.
WARUM DAS ZEICHEN AM GRUPPENKOPF PFLICHT IST. Ohne es waere Zuklappen
ein Rueckschritt gewesen: Der Betreuer markiert etwas, die Gruppe ist zu,
und der Creator erfaehrt es nie. Die Zahl "zu verbessern" in der Bilanz
klappt die betroffenen Gruppen jetzt auf und springt hin.
Auf der Kachel nur fuer Creator. Fuer einen Betreuer waere es die Liste
dessen, was er selbst angehakt hat -- sie waechst mit seiner Arbeit, und
nur der Creator kann sie abbauen. Ein Zaehler, den man nicht auf null
bringen kann, wird ignoriert, und dann sind auch die daneben nichts wert.
ZWEI FEHLER, DIE DIE PRUEFUNG GEFUNDEN HAT:
1. Das Zeichen stiess auf der Kachel mit der Zahl zusammen (zwei
Pixel). Behoben an der Ursache: Besteht die Zahl NUR aus
Markierungen, ist sie dieselbe Auskunft ein zweites Mal und
entfaellt; sonst ruecken Zahl und Pfeil nach unten.
2. Danach war die Pruefung wertlos -- sie verglich mit einem Element,
das es nun nicht mehr gab, und war ohne einen einzigen Vergleich
gruen. Sie zaehlt jetzt die geprueften Nachbarn mit; null Nachbarn
ist ein Fehler, kein Erfolg.
Geprueft wird SICHTBARKEIT, nicht Vorhandensein: Ein zugeklappter Punkt
steht weiterhin im Dokument, alle bisherigen Pruefungen waeren gruen
geblieben, auch wenn der Creator seine Markierung nie zu Gesicht
bekaeme. Dazu Gegenproben: keine Markierung ohne Grund, und wer nichts
markiert bekommen hat, sieht auch kein Zeichen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
f9bf7d5674 |
"Hilfe anfordern" entfaellt - es bleibt die Rueckmeldung
Wunsch: "die sollen nirgendwo Hilfe anfordern koennen, sondern nur Rueckmeldungen." Es ist auch die klarere Loesung. Es gab zwei Wege, dasselbe zu sagen: einen Knopf, der eine Aufgabe erzeugte, und ein Textfeld, das eine Nachricht schrieb. Zwei Wege fuer eine Sache heisst, dass niemand weiss, welcher der richtige ist -- und dass Antworten mal als Aufgabe und mal als Nachricht landen. Wer dann nachsieht, findet die Haelfte nicht. Geblieben ist die Rueckmeldung an jedem Punkt: ein Verlauf, in dem beide Seiten schreiben koennen, sichtbar dort, wo es hingehoert -- am Punkt selbst und nicht in einer zweiten Liste. VOLLSTAENDIG entfernt, nicht nur ausgeblendet: * der Knopf in der Checkliste * der Knopf und die Marke "Hilfe moeglich" im Vorlagenblock * die Route /workspace/api/vorlagen/hilfe * 47 Datenfelder hilfe: true/false in den Vorlagen * die zugehoerigen Stile * der Abschnitt in pruef-vorlagen.mjs Datenfelder, die nichts mehr bewirken, und Routen, die niemand mehr aufruft, werden beim naechsten Mal fuer lebenden Code gehalten und mitgepflegt. Das ist teurer als das Entfernen heute. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
9267797d1d |
Feste Checklisten statt Vorschlaege - in allen vier Bereichen
"Die neuen Sachen in der LIVE-Analyse soll der Creator FEST sehen, auch
schoen kategorisiert, und der Ansprechpartner soll anklicken koennen,
wenn er findet, dass der Creator was verbessern sollte."
DER UMBAU. Vorher waren die Punkte Vorschlaege zum Uebernehmen: Man
holte sie sich und bekam einen eigenen Eintrag. Das war falsch gedacht.
Eine Checkliste, die man erst anfordern muss, ist keine Checkliste --
und schlimmer: Zwei Creator haetten unterschiedliche Listen gehabt, je
nachdem wer sich was geholt hat. Genau das macht einen Vergleich
unmoeglich, und um Vergleich geht es bei einer Betreuung.
Jetzt stehen dieselben Punkte fuer JEDEN fest da, gruppiert:
LIVE 21 Punkte -- vor, waehrend, nach der Sendung
Community 14 Punkte -- Moderation vorbereiten, aufbauen, wenn es kippt
Technik 12 Punkte -- Einrichtung, Ausfall, was geholfen hat
Content 13 Ideen -- nach Saeule (70/20/10) statt nach Ablauf
Jede Gruppe hat einen Satz, der erklaert, wofuer sie da ist. Eine
Ueberschrift allein sagt das nicht.
Was sich je Creator unterscheidet, ist nur der STAND -- und den setzt
die Betreuung: "Passt so" oder "Verbessern". Ein Creator kann sich nicht
selbst bewerten; koennte er es, stuende alles auf gruen. "Verbessern"
verlangt einen Satz, WAS zu verbessern ist -- eine Bewertung, mit der er
nichts anfangen kann, ist nicht streng, sondern nur entmutigend.
Der Creator sieht alles: die Stufe, den Grund, den Namen und den
Zeitpunkt. Und er kann an JEDEM Punkt antworten -- das ist der Kanal,
ueber den er ueberhaupt etwas sagen kann.
Oben steht eine Bilanz in einer Zeile: wie viele passen, wie viele sind
zu verbessern, wie viele hat noch niemand angesehen. Das ist die Frage,
die beide Seiten zuerst haben.
STABILE SCHLUESSEL statt Positionen. Ein Stand haengt am Schluessel des
Punktes ("ton-geprueft"), nicht an seiner Nummer. Haenge er an der
Position, waere beim Einfuegen eines Punktes in der Mitte jede Bewertung
dahinter am falschen Punkt -- und niemand wuerde es merken, weil beides
plausibel aussieht. 64 Punkte haben jetzt einen.
"Offen" loescht den Stand, statt ihn auf "offen" zu setzen: Ein
Datensatz, der nichts aussagt, ist Ballast.
ZWEI EIGENE FEHLER, VON DEN PRUEFUNGEN GEFUNDEN:
1. DAS CSS LAG IN DER FALSCHEN DATEI. Ich hatte es in content.css
geschrieben -- bereich.html laedt die gar nicht. Die Punkte standen
auf drei von vier Seiten nackt und ohne Flaeche da. Es ist derselbe
Fehler wie im August bei .knopf-still, .schalter und .kopf-zeile, und
es gibt seitdem eine Warnung dazu in start.css. Sie hat nichts
genutzt, solange keine Pruefung sie nachhielt.
Jetzt gibt es eine: Sie misst, ob eine Karte wirklich eine Kante und
Polsterung hat -- nicht nur, ob das Element existiert. Gegenprobe
gemacht: Klasse umbenannt, Pruefung meldet "STIL FEHLT".
2. Ein Betreuer sah beim Oeffnen keine Bewertungsknoepfe, weil noch kein
Creator gewaehlt war -- und musste erst raten, dass er oben jemanden
auswaehlen soll. Jetzt nimmt der Server den ersten betreuten Creator,
wenn keiner angegeben ist.
Die alte Oberflaechenpruefung fuer den Vorschlaege-Block wurde entfernt
statt angepasst: Sie verlangte etwas, das es nicht mehr gibt. Eine
dauerhaft rote Pruefung ist schlimmer als keine -- man gewoehnt sich
daran, und beim naechsten echten Fehler sieht niemand hin.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
372a0eb95a |
Ampel und Rueckmeldungen - bewerten darf nur die Betreuung
Der Wunsch: "der Creator sieht, ob es gut ist oder schlecht. Und wenn nicht gut, dann muss es verbessert werden -- und nur der Ansprechpartner kann das aendern. Die Creator koennen nur Nachrichten hinterlassen zum Kommunizieren." ZWEI GETRENNTE DINGE, und sie getrennt zu halten ist der ganze Punkt: DIE AMPEL ist eine Beurteilung. Sie gehoert dem Betreuer, und nur er setzt sie. Koennte ein Creator sich selbst auf gruen stellen, waere sie wertlos -- dann stuende ueberall gruen. Der Server lehnt es mit 403 ab und sagt dabei, wer es kann. DIE NACHRICHT ist ein Gespraech. Sie gehoert beiden. Ein Creator, der auf eine Bewertung nicht antworten kann, bekommt ein Urteil statt einer Betreuung. DREI STUFEN, NICHT FUENF. Eine Zahl von 1 bis 5 klingt genauer und ist es nicht: Niemand kann den Unterschied zwischen 3 und 4 erklaeren, und am Ende steht ueberall die 3. Die Frage lautet "reicht das schon?", und darauf gibt es drei ehrliche Antworten -- passt so, noch verbessern, noch nicht angesehen. "NOCH VERBESSERN" VERLANGT EINE BEGRUENDUNG. Eine Bewertung, mit der der Creator nichts anfangen kann, ist nicht streng, sondern nur entmutigend. Der Server lehnt sie ohne Grund ab; die Oberflaeche fragt deshalb gleich danach, statt hinterher eine Fehlermeldung zu zeigen. "Passt so" braucht keinen -- da gibt es nichts zu erklaeren. Die Stufe steht IMMER an der Karte, auch fuer den Creator, auch wenn sie "noch nicht angesehen" lautet. Er soll sehen, wo er steht, ohne fragen zu muessen. Der Grund steht daneben in voller Breite, nicht in einer Ecke. FREMDE NACHRICHTEN BLEIBEN STEHEN -- auch fuer DogFather. Ein Gespraech nachtraeglich umzuschreiben waere schlimmer, als eine unbedachte Aeusserung stehen zu lassen. Wer etwas richtigstellen will, schreibt eine neue. VORLAGEN AUCH FUER COMMUNITY UND TECHNIK (Screens 11 und 12): 14 Moderations-, Aktions- und Konfliktpunkte, 12 Technikpunkte. Ton steht vorn, weil schlechter Ton der Grund Nummer eins ist, warum Leute einen Stream verlassen. Die drei Bereiche laufen jetzt ueber EINE Zuordnung statt drei fast gleicher Bloecke -- sonst weicht der dritte irgendwann ab. Die beiden alten Zweige wurden entfernt: Toter Code, den man stehen laesst, wird beim naechsten Mal fuer lebenden gehalten. Die Ampeln einer ganzen Liste kommen in EINER Abfrage. Zwanzig Eintraege einzeln zu fragen waeren zwanzig Anfragen, und die Seite ruckelte sichtbar beim Aufbau. Die Sichtbarkeitspruefung laeuft dabei je Eintrag, nicht einmal pauschal -- ein fremder Eintrag taucht auch in der Sammelabfrage nicht auf. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5960f6e3c4 |
Unterweisungen mit beidseitiger Bestaetigung - und einer echten Sperre
Der Wunsch: "jeder Scout, Manager oder DogFather muss mit seinen
Creatorn die PDFs durchgehen, und beide druecken dann auf verifiziert,
so dass wir den Beweis haben -- und das ist danach auch nicht mehr zu
aendern."
Das ist kein Haekchen, das ist ein NACHWEIS. Wer so etwas baut, muss
drei Fragen beantworten, sonst ist er wertlos:
WER hat bestaetigt? Beide Seiten getrennt, mit Name, Zeitpunkt und IP.
Eine einzelne Bestaetigung reicht nicht -- "ich habe es ihm gezeigt" und
"er hat es mir gezeigt" sind zwei verschiedene Aussagen, und erst
zusammen ergeben sie einen Beweis. Bestaetigt nur einer, steht die
Unterweisung sichtbar als HALB da, in einer eigenen warnenden Farbe.
Diese Zwischenstufe sichtbar zu machen ist der Punkt: Ein Nachweis, bei
dem nur einer unterschrieben hat, sieht sonst aus wie fertig -- und man
merkt es erst, wenn jemand danach fragt.
WORAUF genau? Nicht auf "die Regeln", sondern auf eine bestimmte Datei.
Beim Bestaetigen wird der SHA-256 der PDF-Datei mitgespeichert. Tauscht
spaeter jemand die Datei aus, passt der Fingerabdruck nicht mehr, und
die Seite sagt das auch ("Das Dokument wurde seit der Bestaetigung
ausgetauscht"). Ohne diesen Wert waere die Bestaetigung ein Zettel ohne
Bezug.
IST ES UNVERAENDERT? Eine abgeschlossene Bestaetigung laesst sich nicht
mehr aendern und nicht loeschen -- und zwar nicht, weil der Code es
nicht anbietet, sondern weil die DATENBANK es ablehnt. Zwei Trigger mit
RAISE(ABORT). Ein Schutz, der nur im Code steht, ist beim naechsten
neuen Weg zur Datenbank wieder weg.
DER VOLLZUG WURDE DURCHGESPIELT. Aus RunOne stammt die Lehre, dass ein
Weg, den man nicht rueckgaengig machen kann, tagelang live sein und NIE
gelaufen sein kann. Die Pruefung bestaetigt deshalb wirklich, schliesst
ab, und versucht dann eine Aenderung -- ueber die Schnittstelle UND
direkt auf der Datenbank. Beide werden abgelehnt.
Und die GEGENPROBE dazu: Der Trigger wird entfernt, dieselbe Aenderung
versucht -- sie geht durch -- und der Trigger wieder gesetzt. Eine
Sperre, die man nicht hat scheitern sehen, ist keine Sperre.
Der Server entscheidet anhand der ROLLE, welche Seite gesetzt wird --
nicht der Absender. Sonst koennte ein Creator die Bestaetigung seines
Betreuers eintragen, und der ganze Nachweis waere wertlos. Eine bereits
gesetzte Seite wird nie ueberschrieben; ein Datum laesst sich also auch
nicht nachtraeglich verschieben.
Die Dokumente kommen aus der Wissens-Bibliothek, es gibt keinen zweiten
Upload-Weg. Sonst gaebe es Dateien, die nur hier existieren -- und
niemand wuesste, welche Fassung die richtige ist. Eine Unterweisung wird
nie geloescht, nur abgeschaltet: Die Nachweise haengen daran.
EIN EIGENER FEHLER, VON DER BROWSERPRUEFUNG GEFUNDEN: Der Aufruf der
Zusatzbloecke stand NACH einem return. laden() steigt frueh aus, wenn
die Liste leer ist -- und dann wurden Vorlagen und Unterweisungen nie
gebaut. Also ausgerechnet auf der leeren Seite, fuer die sie gedacht
sind. Jetzt stehen sie in einem finally.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
ca10479909 |
Fertige Vorlagen zum Uebernehmen - Content-Ideen und LIVE-Punkte
Der Wunsch stand an fuenf Stellen gleichlautend: "ich will dass da schon fertige Sachen stehen". Eine leere Seite mit einem Knopf "Neuer Eintrag" verlangt vom Creator genau das, was er noch nicht kann -- zu wissen, was ueberhaupt hineingehoert. WARUM VORLAGEN UND KEINE VORAUSGEFUELLTEN DATEN. Man koennte beim Anlegen eines Creators dreissig Eintraege in seine Datenbank schreiben. Das waere falsch: Sie waeren ab dem ersten Tag "seine" Eintraege und damit Altlast; aendert Filipe spaeter eine Formulierung, gilt sie nur fuer neue Creator; und die Liste saehe voll aus, obwohl noch nichts geschehen ist -- das Gegenteil einer ehrlichen Uebersicht. Vorlagen bleiben deshalb VORSCHLAEGE, bis jemand sie uebernimmt. Sie stehen im Code, gelten fuer alle sofort, und werden erst dann zu Daten, wenn sie gebraucht werden. Was uebernommen ist, ist ein ganz normaler Eintrag -- aenderbar, loeschbar, und von spaeteren Aenderungen an der Vorlage unberuehrt. INHALTE, fachlich begruendet: 13 Content-Ideen, jede mit AUSFORMULIERTEM Aufhaenger und Format. Die ersten ein bis drei Sekunden entscheiden ueber die Verbreitung -- "mach was Persoenliches" hilft niemandem, "Das haette ich am Anfang gern gewusst" kann man sagen. Verteilt nach 70/20/10 (Wert, Community, Eigenwerbung). 21 LIVE-Punkte in drei Abschnitten. Der mittlere ist der wichtigste und gibt es sonst nirgends: Was WAEHREND der Sendung auffaellt, ist am naechsten Tag weg. Diese Punkte sind so formuliert, dass man sie in einem Moment anklicken kann, in dem man eigentlich keine Zeit hat. Die Vorbereitung ist die laengste Liste, weil ein LIVE dort steht und faellt. Ton zuerst -- der Grund Nummer eins, warum Leute wieder gehen. "ICH BRAUCHE HILFE" wird eine AUFGABE, keine Nachricht. Eine Nachricht ist gelesen und dann weg; eine Aufgabe bleibt stehen, bis sie jemand erledigt, geht an den zustaendigen Betreuer (ohne Betreuer an die Leitung -- eine Bitte um Hilfe darf nicht ins Leere laufen), traegt hohe Prioritaet und eine Frist von drei Tagen. Ohne Frist bleibt sie liegen; das ist der Unterschied zwischen einer Aufgabe und einem Zettel. "CONTENT-PLANUNG" HEISST JETZT "CONTENT-IDEEN". "Planung" klang nach Terminen und Tabellen; was dort wirklich passiert, ist das Sammeln und Weiterentwickeln von Ideen. Der Kalender daneben plant. EIN CREATOR DARF SEINE EIGENEN EINTRAEGE AENDERN -- aber nur im Bereich Content. Wenn er sich eine Idee uebernimmt, ist das SEINE Idee; sie danach nicht umbenennen zu duerfen waere absurd. LIVE, Technik, Community und Schutz bleiben die Betreuungsakte, dort aendert er nichts. Ein erster Anlauf hatte die Ausnahme fuer alle Bereiche erlaubt -- die Pruefung pruef-bereiche-lesend hat das sofort gemeldet. DREI EIGENE FEHLER, VON DEN PRUEFUNGEN GEFUNDEN: - Der Vorlagenblock vergass nach dem Uebernehmen, was schon geholt war: Die Liste wird neu geladen, der Block neu gebaut, und die Markierung am Element war jedes Mal weg. Jetzt merkt sich das Modul die Auswahl. - Die Regel fuer eigene Eintraege war zu breit (siehe oben). - Die Marken im Vorlagenblock waren auf dem Handy 10,2 px klein. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
6996c5957d |
Formularzeilen gerade geruckt, Pipeline erklaert sich selbst
DIE VERZOGENE FORMULARZEILE hatte drei Ursachen, nicht eine -- und jede einzelne haette gereicht, damit es schief aussieht: 1. Die Rasterregel galt nur fuer Kinder mit der Klasse .feld. Der Kalender benutzt schlichte <div> ohne Klasse; die fielen hindurch, bekamen von zwoelf Spalten je EINE und wurden nur so breit, wie ihr Inhalt sie zwang. Daher "Art" schmal und "Beginn" breit. 2. "Dauer (Minuten)" brach in der schmalen Spalte auf zwei Zeilen um -- und schob das Feld darunter tiefer als seine Nachbarn. Die Klammer ist jetzt ein leiser Zusatz, die Beschriftung hat feste Hoehe. 3. Die letzten drei Pixel: Mit grid-template-rows: 1fr auto bestimmte jedes Element die Zeilenhoehe selbst. Ein <select> mass sich 3 px kleiner als ein <input> und sass dadurch hoeher. Gemessen: Container beider Felder identisch (652+71), Eingabe aber 676..720 gegen 679..723. Drei Pixel klingen nach nichts und sind genau das, was man als "verzogen" sieht. Jetzt hat die Zeile feste Hoehe und das Feld fuellt sie ganz. Ergebnis, gemessen statt betrachtet: alle Felder 44 px hoch, alle 362 px breit, alle Unterkanten auf einer Linie. Auf dem Handy untereinander -- zwei Felder auf 300 px sind zwei Streifen, in die nichts hineinpasst. NEUE PRUEFUNG pruef-formulare.mjs. Sie prueft nicht "sieht gut aus", sondern misst: gleiche Hoehe, Unterkanten auf einer Linie, kein Feld absurd schmal, keine Beschriftung mehrzeilig -- auf fuenf Seiten und zwei Geraetegroessen. Zwei Messfehler darin selbst gefunden und behoben (Teilpixel-Rundung, und eine Ausgabe ueber mehrere Zeilen, die die Datei zerschossen hat). DIE SCOUT-PIPELINE ERKLAERT SICH JETZT SELBST. Vorher stand im leeren Zustand ein Satz, der nur wiederholte, was man ohnehin sieht: dass nichts da ist. Wer die Seite zum ersten Mal oeffnet, wusste danach weiterhin nicht, wofuer es sie gibt. Der leere Zustand ist der EINZIGE Moment, in dem jemand garantiert liest, was dort steht -- spaeter ist die Flaeche von Daten belegt. Deshalb steht die Erklaerung genau dort und nicht in einer Hilfe, die niemand aufmacht. Erklaert wird der NUTZEN, nicht die Bedienung: nicht "hier klicken", sondern warum ein Scout ohne diese Liste Leute verliert -- naemlich die Interessierten, bei denen drei Wochen nichts passiert ist, und nicht die, die Nein sagen. Dazu die fuenf Stufen mit je einem Satz, was sie bedeuten. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
568909ba87 |
Bibliothek: nur je einer oben, "wichtig" laeuft ab, Knopf steht fest
NEU & WICHTIG zeigte bis zu sechs Karten mit je vier Knoepfen -- eine
halbe Bildschirmseite, bevor ueberhaupt eine Kategorie zu sehen war.
Jetzt stehen genau ZWEI da: der wichtigste und der neueste. Bewusst je
einer und nicht die ersten zwei -- das sind zwei verschiedene Antworten
("was soll ich unbedingt lesen" und "was ist dazugekommen"). Alles
Weitere ist einen Klick entfernt, der Knopf nennt die Zahl.
"WICHTIG" LAEUFT JETZT EBENFALLS NACH 48 STUNDEN AB. Vorher blieb es
stehen, bis es jemand von Hand abschaltete -- mit dem absehbaren
Ergebnis, dass oben nach ein paar Wochen eine Liste von Dingen steht,
die laengst niemanden mehr angehen. Niemand raeumt so etwas auf.
Der Schalter bleibt trotzdem sinnvoll: Er hebt einen Eintrag fuer zwei
Tage nach oben, auch wenn dieser aelter ist. Er ist damit ein
Scheinwerfer, kein Regal.
DER AKTIONSKNOPF SPRANG -- "einmal rechts, einmal links". Die Ursache
war nicht die Seite, sondern die TEXTLAENGE: Die Kopfzeile ist eine
umbrechende Flex-Zeile, und der Textblock daneben durfte wachsen. Bei
kurzer Unterzeile blieb der Knopf rechts, bei langer ("Community-
Richtlinien, erlaubte und verbotene Inhalte, Altersprüfung, Sperren,
Verwarnungen, Datenschutz, Jugendschutz und sicheres Verhalten")
rutschte er darunter. Es sah aus wie zwei verschiedene Seiten und war
dieselbe Regel.
Jetzt schrumpft der Textblock und der Knopf nicht -- er steht auf jeder
Seite an derselben Stelle. Auf dem Handy rutscht er bewusst darunter und
nimmt die volle Breite, dort ist nebeneinander kein Platz.
NEUE PRUEFUNG pruef-wissen-neu.mjs. Sie legt ausdruecklich Eintraege mit
einem Zeitstempel von VOR DREI TAGEN an. Mit frischen Daten waere alles
neu, ein abgelaufener Eintrag kaeme nie vor, und die Pruefung waere
gruen, ohne den Fall je gesehen zu haben. Geprueft wird ausserdem, dass
das Aufklappen WIRKLICH mehr zeigt -- ein Knopf, der nur seine
Beschriftung aendert, ist keiner.
Zwei Fehler in der Pruefung selbst gefunden: Sie schrieb in Spalten, die
so nicht heissen (datei statt name_datei), und suchte die Karten unter
".karte" -- sie heissen .pdf, und der Ausdruck zaehlte stattdessen die
umschliessenden Container.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2bebab156b |
Profilbild gebaendigt, Steckbrief von der Creator-Akte getrennt
ZWEI FEHLER, DIE FILIPE GESEHEN HAT.
1. DAS PROFILBILD LAG UEBER DER HALBEN SEITE. Als Patrick sein Bild
hochlud, zog sich ein roter Balken quer ueber die Startseite.
Ursache: Die CSS-Regel .wer__bild hat GEFEHLT. Das Element wurde in
kopf.js erzeugt, die Regel dazu nie geschrieben -- und ein <img> ohne
Groessenangabe nimmt seine natuerliche Groesse an, bei einem Handyfoto
also mehrere tausend Pixel. Dazu fehlte overflow: hidden am Traeger.
WARUM KEINE PRUEFUNG DAS GEFUNDEN HAT: Sie lud ein 1x1-Pixel-PNG hoch.
Klein, schnell, von Hand gebaut -- und voellig unfaehig, irgendetwas
zu ueberdecken. Die Pruefung war gruen, der Fehler war da, und gesehen
hat ihn der Nutzer. Sie arbeitet jetzt mit einem 1200x1200-Bild, also
in der Groesse, die wirklich hochgeladen wird, und misst danach: Bleibt
das Bild in seinem 28-px-Feld, ragt es irgendwo heraus, laeuft die
Seite ueber. Gegenprobe gemacht -- ohne die Regel meldet sie
1200x1200 in 28x28 und 918 px Ueberlauf.
2. ZWEI PERSONEN AUF EINEM BILDSCHIRM. Auf der Profilseite stand oben
"Profil: SpongBobSchwammKopf" und mittendrin "MEIN PROFIL: Dogfather".
Niemand konnte sagen, welche Angabe zu wem gehoert.
Es sind auch wirklich zwei verschiedene Dinge:
MEIN STECKBRIEF gehoert MIR -- Bild, ein Satz ueber mich, meine
Kanaele. Fuehre ich selbst.
CREATOR-PROFILE die BETREUUNGSAKTE eines anderen Menschen --
Ziele, 90-Tage-Plan, interne Notizen. Fuehren die
Betreuer.
Scouts, Manager und DogFather haben jetzt zwei getrennte Kacheln und
eine eigene Seite (steckbrief.html, serverseitig geschuetzt). Ein
Creator behaelt beides zusammen -- er hat nur eine Seite und sieht
dort ausschliesslich sich selbst. Die Logik liegt in einer eigenen
Datei statt hinten an profil.js: Sie gehoert der angemeldeten Person,
nicht der Akte.
ACHTZEHN KACHELN, ACHTZEHN FARBEN. Die neue Kachel haette sich ihren
Farbton mit den Creator-Profilen geteilt -- zwei Nachbarn in derselben
Farbe. Statt eine Farbe dazuzuerfinden, wurde tools/kachel-farben.mjs
fuer 18 Winkel neu gerechnet, samt der neuen Nachbarschaft im Raster.
Der kleinste Abstand zweier Nachbarn liegt weiterhin bei 100 Grad.
Gefunden hat das die Startseitenpruefung ("17 Farben auf 18 Kacheln").
Die Trennung wird jetzt fuer JEDE Rolle geprueft: welche Kacheln sie
sieht, dass auf der Akte kein fremder Steckbrief steht, und dass die
eigene Seite die richtige Person zeigt. Eine alte Pruefung, die das
Gegenteil verlangte, wurde ersetzt statt stehen gelassen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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]>
|
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
766c75b51d |
Die Buehnen richtig: nicht mehr beschnitten, hell, mit Lesespur
Drei handfeste Fehler, alle im Screenshot zu sehen gewesen. 1. ABGESCHNITTEN. background-size stand auf "138% auto". Auf einem 2540 px breiten Schirm wurde das Bild damit 3500 px breit und knapp 2000 px hoch -- in einem 1300 px hohen Fenster fehlten 700 px, und zwar oben. Genau deshalb waren die Figuren riesig und ihre Koepfe weg. Jetzt cover mit Verankerung auf 50% 42%: Die Flaeche wird immer gefuellt, so wenig wie noetig skaliert, und wenn etwas beschnitten werden muss, dann Fussboden und Decke -- nicht die Gesichter. 2. DIE VIGNETTE LAG FALSCH HERUM. Abgedunkelt wurde die MITTE, also genau der Teil, in dem die Szene steht. Man sah die Raender des Bildes und in der Mitte einen grauen Fleck. Jetzt laufen die RAENDER ins Dunkle und die Mitte bleibt klar -- so wie in der Fotografie. 3. ZWEI SCHICHTEN DUNKELHEIT. Zusaetzlich zur Vignette legte der Schleier .86/.58/.44 Schwarz ueber dasselbe Bild. Jetzt nur noch oben (Kopfleiste) und unten (Seitenende) ein Streifen. Dazu die Bilder selbst: Helligkeit 0.66 -> 0.88, mehr Kontrast und Farbe. Sie sind ein BILD, kein Nebel. DIE LESESPUR ist der eigentliche Kniff. In allen neun Szenen stehen HasiDog und DogFather AUSSEN, die Mitte ist frei -- danach wurden sie ausgesucht. Diese Aufteilung wird jetzt benutzt statt bekaempft: aussen bleibt das Bild hell und scharf, in der Mitte (wo der Text steht) wird gedaempft. Der klare Rand ist in jedem Fenster mindestens 400 px breit. Auf dem Handy gibt es daneben keinen Platz, dort deckt die Spur alles. Was frei stand und keine Karte hatte, bekommt eine Lesezone mit backdrop-filter: Der Hintergrund bleibt in Farbe und Form sichtbar, wird an dieser Stelle aber weichgezeichnet. Die billige Loesung waere gewesen, das Bild wieder abzudunkeln -- damit waere man dort, wo man angefangen hat. ZWEITER FUND AN DER EIGENEN KONTRASTMESSUNG. Sie tastete ausschliesslich NEBEN dem Element ab. Traegt ein Text seine Flaeche aber selbst (eine Beschriftung mit Hintergrund und Polsterung), liegt jeder Punkt daneben schon auf dem Bild -- gemeldet wurden 1,89:1, obwohl der Text auf deckender Flaeche steht und tadellos lesbar ist. Jetzt wird zuerst in der eigenen Polsterung gemessen, also auf dem, worauf der Text WIRKLICH liegt. (Der erste Fund an derselben Stelle war gestern: Sie mass Text gegen Nachbartext.) Nach dem Aufhellen einmal komplett durchgemessen: von sieben roten Stellen auf null. Schlechtester Wert jetzt 4,70:1 bei 4,5:1 Norm. Die Bilder sind groesser geworden (580 KB -> 1,8 MB fuer alle achtzehn), weil weniger Dunkelheit weniger komprimierbar ist. Geladen wird pro Seite genau eine: 42 bis 132 KB. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]> |
||
|
DogFatherGitandClaude Opus 5
|
fc4fde0f02 |
Buehnen hell, Flaechen dicht - und die Kopfleiste wieder kurz
DIE BUEHNEN WAREN ZU DUNKEL. Bei 0.42 Helligkeit sah man Schemen, nicht die Szene -- "zu dunkel und sieht ganz komisch aus" traf es genau. Jetzt 0.66 mit etwas mehr Farbe (1.08), die Vignette schwaecher (0.52 statt 0.72). Die Bilder kommen durch. MOEGLICH IST DAS NUR MIT DEM GEGENZUG: Alle Kacheln, Karten und Spalten lagen bei 2 bis 3 Prozent WEISS -- also praktisch durchsichtig. Solange der Hintergrund fast schwarz war, fiel das nicht auf; sobald er hell wurde, lief das Bild mitten durch den Text. Jetzt gibt es --flaeche (rgba(9,13,22,.78)), eine deckende dunkle Flaeche, und 44 Stellen in 16 Dateien holen sich ihre Farbe von dort. Der Unterschied ist genau der, den Filipe beschrieben hat: Der Hintergrund bleibt sichtbar, aber ZWISCHEN den Kacheln -- nicht hinter der Schrift. Wer die Flaechen kuenftig dichter oder durchlaessiger will, aendert eine einzige Zeile statt 44. Die Kacheln selbst tragen ihren Farbton jetzt AUF der Flaeche (color-mix mit --flaeche statt mit transparent) -- dadurch bleibt die Farbe erkennbar, ohne dass die Kachel durchsichtig wird. DIE KOPFLEISTE war so breit wie das ganze Fenster, obwohl der Text kurz ist: .marke__text stand auf flex: 1 1 auto. Das war unsichtbar, solange der Schriftzug nur Text war -- seit er einen Rahmen traegt, lief die Pille quer durchs Bild. Jetzt flex: 0 1 auto (schrumpfen ja, wachsen nein). Gemessen: 375 px statt 1280. Kontrast an echten Bildpunkten auf allen sechs Seiten nachgemessen -- haelt trotz des viel helleren Bildes (schlechtester Wert 4,69:1). Co-Authored-By: Claude Opus 5 <[email protected]> |