14 Commits
Author SHA1 Message Date
DogFatherGitandClaude Opus 5 2f3b8630c7 Messungen am Telefon: 37 bekommen ihren Finger
Gestern Mittag gemessen: 39 `newContext`-Aufrufe nehmen ihre Breite
aus einer Variablen und setzen kein `hasTouch`. Ohne das meldet der
Browser `pointer: fine`, und KEINE Regel aus `@media (pointer:
coarse)` greift — dort stehen im ganzen Haus die 44-Pixel-
Beruehrziele, die ausgeblendeten Tastenkuerzel und die
eingeklappte Reiterleiste.

Was das anrichtet, war an pruef-breiten zu sehen: drei Befunde auf
320, 390 und 430 Pixeln, die mit dem Finger allesamt verschwanden —
Messfehler, keine Fehler.

37 DAVON HABEN IHN JETZT. Nur `hasTouch`, nicht `isMobile`: Gefragt
ist genau die eine Sache, um die es geht. `isMobile` waere eine
zweite Aenderung in derselben Zeile, und wenn danach etwas anders
aussieht, wuesste niemand, welche von beiden es war.

ZWEI BLEIBEN STEHEN, beide in pruef-grosscheck.mjs. Die Aenderung
dort waere ein Zweizeiler; sie zu pruefen hiesse, 206 Seiten ueber
vier Rollen laufen zu lassen, und das braucht Filipes Zusage. Eine
Aenderung, die ich nicht pruefen darf, liefere ich nicht aus.
Grundlinie in pruef-fingermass steht deshalb auf 2.

JEDE EINZELN NACHGELAUFEN — 37 Laeufe:

  34 gruen, darunter pruef-handy 186, pruef-material 159,
  pruef-start-ansicht 160, pruef-kalender 141, pruef-erwaehnung 129,
  pruef-bewerbung-aufgaben 163, pruef-neue-seiten 109

  3 mit Befunden, ALLE DREI VORBESTEHEND (Gegenprobe: alter Stand
  derselben Datei, gleicher Lauf, gleiche Zahl):
    pruef-browser        3  (WebKit startet auf diesem Rechner nicht)
    pruef-chat-anhaenge  2
    pruef-crew-wand-bild 3

EINE ZEITBOMBE GEFUNDEN UND ENTSCHAERFT

pruef-dabei-optik meldete „Haekchen: 0 -> 0" — aber nur, wenn vier
andere Pruefungen gleichzeitig liefen. Allein: „0 -> 1", gruen.

Dort stand `waitForTimeout(250)` mit der Begruendung „250 ms sind
reichlich ueber den 160" (der Dauer der Blende). Auf einem Rechner,
auf dem nebenher vier Browser messen, sind sie es nicht. Die
Pruefung war damit gruen, solange nichts anderes lief, und rot im
Gesamtlauf — also genau dann, wenn niemand sie einzeln nachstellen
kann.

Eine Wartezeit ist eine Annahme ueber den Rechner. Gewartet wird
jetzt auf das, worauf es ankommt: dass das Haekchen da ist. Laeuft
die Frist ab, faellt die Pruefung mit dem ECHTEN Wert um und nicht
mit einem Messfehler. Gegenprobe: unter derselben vierfachen Last,
die sie vorher rot gemacht hat, jetzt gruen.

UND DIE GRUNDLINIE WIEDER STRENG. Ich hatte sie kurz auf
„hoechstens" gestellt — damit haette ein Rueckgang stillschweigend
Platz fuer die naechste Suende gedeckt. Genau davor warnt der Kopf
derselben Datei bei der anderen Grundlinie, und ich habe es eine
Stunde spaeter selbst falsch gemacht.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-10-01 13:37:05 +02:00
DogFatherGitandClaude Opus 5 1d41e29bf7 Drei weitere Prüfungen, die das Falsche prüften
Der Durchgang, zweiter Teil. Gesucht nach dem schaerfsten Filter, den
es dafuer gibt: dem VERSPRECHEN GEGEN DIE WIRKLICHKEIT -- Pruefsaetze,
die „jede Rolle" oder „jede Seite" sagen. Genau so ist pruef-glocke
heute frueh aufgefallen.

1. pruef-workspace-seiten meldete aufgaben.html als „Breite 1560px".
   KEIN FEHLER: Die Seite traegt zusaetzlich `.inhalt--brett`, und die
   setzt ausdruecklich 1560 px -- mit Begruendung in aufgaben.css („ein
   Brett darf breiter sein als Text, der Kopfbereich bleibt lesbar
   schmal"). Die Pruefung verglich starr mit 1240 und kannte die
   Klasse nicht; sie meldete damit eine Absicht als Fehler, seit dem
   Tag, an dem die Klasse entstand. Mit Gegenprobe belegt: schon vor
   allen Aenderungen von heute rot.
   Jetzt kommt die erwartete Breite aus den KLASSEN des Elements.
   Beide Zahlen bleiben stehen, weil sie etwas aussagen -- kommt
   weder 1240 noch 1560 an, ist die Regel verloren.

2. pruef-meldungen meldete „ohne Satz: ungueltiger_stand". Zuerst ein
   ECHTER Fehler, und zwar meiner vom selben Tag: In
   workspace-support.js stand eine nackte Kennung statt eines Satzes.
   Behoben -- und danach meldete die Pruefung sie WEITER, weil sie das
   Zitat im Kommentar las, der die Behebung begruendet.
   Dieselbe Falle wie ein Grep ueber eine Datei, die ihre eigene
   Geschichte enthaelt; mir ist sie heute schon einmal passiert. Eine
   Pruefung, die verbietet, ueber einen behobenen Fehler zu SCHREIBEN,
   erzieht dazu, die Begruendung wegzulassen. Kommentare zaehlen jetzt
   nicht mehr; Adressen mit // in Zeichenketten bleiben unberuehrt.

3. pruef-auskunft meldete „NICHT EINGEORDNET:
   vorlagen_bewerbungen.aufgabe_id". ECHT: Die Spalte zeigt auf eine
   Aufgabe, nicht auf einen Menschen, und stand in keiner der beiden
   Listen. Das ist mehr als Ordnungsliebe -- bei einer
   Auskunftsanfrage muss das Haus sagen koennen, welche Spalten auf
   eine Person zeigen. Eine unbekannte Spalte ist eine, bei der
   niemand weiss, ob sie mitgehoert.

ZWISCHENSTAND: ACHT Pruefungen an einem Tag, die rot waren oder das
Falsche prueften. Das Muster ist immer dasselbe -- eine Liste oder
Zahl, die zum Zeitpunkt des Schreibens stimmte. Sie wird nicht falsch,
sie wird unzustaendig.

Gruen: pruef-meldungen (8), pruef-auskunft (46),
pruef-workspace-seiten, pruef-support (45), pruef-vorlagen.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-24 13:01:25 +02:00
DogFatherGitandClaude Opus 5 6e46a08543 Portnummern werden abgeleitet, nicht mehr vergeben
Gemessen: 165 Pruefdateien, 129 verschiedene Nummern -- NEUNZEHN
doppelt, vier davon dreifach. Niemand hatte das gewollt; jede neue
Pruefung wurde von einer vorhandenen abgeschrieben, und die Nummer kam
mit. Meine eigene Notiz sagte "sieben" -- auch eine Bestandsliste
altert.

Der Waechter faengt den Schaden ab, aber er kann nur melden, was schon
passiert ist: Zwei Pruefungen mit derselben Nummer koennen nie
gleichzeitig laufen, und ein liegengebliebener Prozess der einen laesst
die andere abbrechen mit einer Meldung, die wie ein Befund aussieht.
Genau das ist mir am 20.09. zweimal passiert.

Jetzt leitet jede Datei ihre Nummer aus ihrer STELLE IM ALPHABET ab
(eigenerPort in helfer-port.mjs), zwei je Datei. Nicht ueber eine
Pruefsumme: Bei 165 Namen in 4900 Nummern waeren nach dem
Geburtstagsproblem rund DREI Zusammenstoesse zu erwarten -- ein Hash
tauscht eine sichtbare Doppelung gegen eine unsichtbare. Die Stelle im
Alphabet ist eindeutig von der Bauart her.

--- ZWEI FEHLER AUF DEM WEG, BEIDE LEHRREICH -------------------------

1. DER ERSTE VERSUCH WAR GRUEN UND KAPUTT. Ersetzt wurde mit einem
   Muster: "([^"]*4231[^"]*)". Das hielt

     { host: "127.0.0.1", port: 4231, path: "/404.html" }

   fuer eine Zeichenkette -- ein Muster kann eine oeffnende nicht von
   einer schliessenden Anfuehrung unterscheiden. Heraus kam

     { host: "127.0.0.1`, port: ${PORT}, path: `/404.html" }

   also GUELTIGER Code ohne port-Feld. `node --check` sagte gruen fuer
   alle 164 Dateien. Aufgefallen ist es erst, weil ich vier Vertreter
   gegen eine vorher gemessene Grundlinie laufen liess: pruef-schranke
   39/0 vorher, 38/1 nachher.

   Alles zurueckgenommen und mit einem Zerleger neu gemacht, der weiss,
   ob eine Stelle Code, Zeichenkette, Vorlage, Kommentar oder
   regulaerer Ausdruck ist. In pruef-ics stand die Nummer in einem
   regulaeren Ausdruck -- der wird jetzt gebaut statt hingeschrieben.

2. EIN MODUL, DAS BEIM IMPORTIEREN ARBEITET, IST EINE FALLE. Der
   zweite Durchgang importierte den ersten, um seine Mechanik zu
   benutzen -- und fuehrte dessen Hauptlauf gleich mit aus. Die
   zweiten Nummern wurden dadurch als erste behandelt, zwei Aufrufe
   bekamen dieselbe Nummer, und in pruef-content stand `const PORT`
   zweimal.

--- WAS DAS DAUERHAFT HAELT -----------------------------------------

pruef-portnummern.mjs (neu, 8 Pruefungen) fragt nicht "welche Nummern
sind doppelt", sondern "wer traegt ueberhaupt noch eine von Hand ein"
und "wer startet einen Server, ohne seine Nummer abzuleiten". Die
zweite Frage hat sofort etwas gefunden, das in KEINER Doppelungsliste
stand: pruef-push-weg belegte 4341 und 4342, rief den Waechter aber
gar nicht auf -- dieselbe Nummer wie pruef-agentur. Eine Liste zeigt
nur, was auf ihr steht.

Mit Gegenprobe: Eine unbekannte Datei bekommt keine geratene Nummer,
sondern einen Abbruch, und eine dritte Nummer je Datei gibt es nicht.

--- NACHGEMESSEN ----------------------------------------------------

Sechzehn Pruefungen gegen ihre vorher gemessene Grundlinie, je eine
Vertreterin jeder umgestellten Bauweise (eine Nummer, zwei Nummern,
Nummer in einer Zeichenkette, in einer Vorlage, in einem regulaeren
Ausdruck, dynamische Einfuhr, Nachtlauf mit zwei Laeufen):

  crew-adresse 132/0 · schranke 39/0 · content 45/0 · entwicklung 46/0
  anruf 127/0 · ics 37/0 · push-weg 20/0 · arten 28/0 · video 67/0
  kanalzeile 14/0 · agentur 62/0 · spicy 83/0 · creator-anlegen 50/0
  push-ziel 10/0 · portnummern 8/0

Alle exakt wie vorher. Zwei waren schon vorher rot und sind es
unveraendert geblieben (crew-wand-bild 41/4, teilen 14/3) -- per
`git stash` belegt, nicht angenommen.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-20 22:51:21 +02:00
DogFatherGitandClaude Opus 5 790b77a73d Bei dir klingelt nichts -- und 49 Pruefungen, die blind waren
1. SIEBEN VON ELF HATTEN KEIN GERAET ANGEMELDET.

Gemessen am echten Server, nicht geschaetzt (die Notiz von heute Nacht
sagte acht -- Tamy hat inzwischen eins). Bei ihnen kommt nichts an,
solange die Seite zu ist: keine Aufgabe, kein Termin, kein Anruf.

Die Glocke sagt das seit jeher korrekt und kennt sogar den
iPhone-Sonderfall ("erst zum Home-Bildschirm"). Nur tippt sie niemand
an -- sie ist ein stiller Schalter in einer Leiste.

Jetzt steht es dort, wo man hinsieht: als Hinweis in "Was ist dran?",
mit Weg auf anruf-probe.html. Als OFFENER PUNKT, nicht als Warnung --
eine Warnung, die bei sieben von elf Leuten dauerhaft oben steht, ist
nach einer Woche unsichtbar, und mit ihr die echten daneben. Er
verschwindet von selbst, sobald ein Geraet da ist (Gegenprobe in
pruef-glocke).

Und ohne die "1" davor: Er zaehlt nichts, er beschreibt einen Zustand.

FUENF DER SIEBEN DURFTEN DIE SEITE GAR NICHT OEFFNEN. anruf-probe.html
stand nur Leitung und Modis offen. Das war die falsche Einschraenkung:
Die Seite prueft die ganze Kette bis zur Geraete-Kennung, und die
traegt auch jede Aufgaben- und Terminerinnerung. Jetzt alle Team-Rollen,
ohne "gast" (die Community bekommt keine Erinnerungen).

2. 49 PRUEFUNGEN KONNTEN "BELEGT" NICHT VON "KAPUTT" UNTERSCHEIDEN.

Aufgefallen beim Nachsehen, warum ein Lauf rot war: Es war mein eigener,
haengengebliebener Lauf, der den Port hielt. Kein Befund.

Dabei gemessen: Von 130 Pruefungen hatten 49 keinen Portwaechter, und
SIEBEN Portnummern sind doppelt vergeben (4186, 4188, 4189, 4193, 4198,
4321, 4345). Bei belegtem Port startet der eigene Server STILL nicht --
und alles Weitere misst gegen einen fremden Stand. Das hat in diesem
Haus schon zweimal Stunden gekostet (27.08. und 05.09.).

Der Waechter existierte seit dem 05.09., er war nur nie ausgerollt.
Jetzt haben ihn alle 130. Gegenprobe gemacht: Port belegt ->
Rueckgabewert 3 mit Begruendung statt stillem Messen.

pruef-content bekommt BEIDE Ports -- sie startet zwei Server, und der
zweite gehoert zur Gegenprobe. Nur den ersten zu schuetzen hiesse,
ausgerechnet den Teil ungeschuetzt zu lassen, dem man glaubt.

Die sieben doppelten Nummern bleiben vorerst. Mit dem Waechter ist eine
Kollision jetzt laut statt still; Umnummerieren ist ein eigener Schritt.

3. pruef-rollen IST ABGESTUERZT, SEIT WANN WEISS NIEMAND.

"Target crashed" bei der fuenften Rolle, nach 234 gruenen Pruefungen.
Kein Fehlschlag -- ein toter Browser.

NACHGEMESSEN GEGEN DEN STAND VOR HEUTE (0b73fbb): dort genauso, an
derselben Stelle. Es lag also nicht an den Aenderungen dieses Tages.
Aufgefallen ist es nie, weil ein abgestuerzter Browser von aussen wie
ein Programmfehler aussieht und die 234 gruenen Zeilen davor sich wie
ein fast bestandener Lauf lesen.

Ursache ist die Menge: fuenf Rollen mal sechzehn Seiten in EINEM
Browserprozess. Die Kontexte wurden je Rolle geschlossen, der Prozess
darunter lief durch. Jetzt bekommt jede Rolle ihren eigenen Browser,
und ein Absturz meldet sich selbst statt als Zeitueberschreitung
irgendwo weiter unten aufzuschlagen.

Ergebnis: 321 Pruefungen, alles in Ordnung -- statt Absturz bei 234.

4. DAS SYMBOL FUER TIKTOK.

assets/img/app-symbole/workspace-1024.png, frisch gerendert statt
hochskaliert (das Huskygesicht lebt von harten Kanten) und als VOLLES
Quadrat ohne Rundung: Die Aufnahme hat keinen Alphakanal, die Ecken
waeren sonst weiss. App-Portale wollen ohnehin das volle Quadrat, die
Rundung macht das Betriebssystem.

Die sechs vorhandenen Groessen sind dabei bitgleich geblieben --
gepruefte Nebenwirkung, nicht gehofft.

GEMESSEN: pruef-glocke 31/0 (neu: 5 zum Hinweis), pruef-rollen 321/0
(vorher Absturz), pruef-rechtetafel 19/0, pruef-struktur 0 Fehler,
pruef-betreuung und pruef-werdegang gruen.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-19 11:14:18 +02:00
DogFatherGitandClaude Opus 5 4e35c6f8e5 screen11: Der Chat hatte gar keinen Hintergrund -- seit jeher
Wunsch Filipe: "die hintergrund bilder sollen alle so strahlen und
schoen sein wie dieses. dieses ist wirklich mega und perfekt."
(Massstab ist die Scouting-Seite, Szene "wald".)

DER FUND: `chat.html` hat weder `.kopf-zeile` noch `.k-kopf` -- sie
traegt ihren Titel im eigenen `.chat__kopf`. In kopf.js stand ganz
oben:

    const kopf = document.querySelector('.kopf-zeile, .k-kopf');
    if (!B || !kopf) return;

Damit hing ALLES an der Frage, ob es eine Kopfzeile gibt, an die man
eine Plakette haengen kann -- auch der Farbton der Seite und ihr
Hintergrundbild, die damit nichts zu tun haben. Der Chat ist an dieser
Zeile ausgestiegen und hat WEDER Ton NOCH Buehne bekommen, obwohl in
bereiche.js seit jeher `szene: 'lounge'` fuer ihn steht. Eine
Zuordnung, die es gibt und die nie ankam.

Jetzt stehen Ton und Buehne VOR der Plakette: Sie brauchen nur den
Bereich. Die Plakette braucht zusaetzlich einen Kopf -- gibt es den
nicht, faellt eben nur sie aus.

WARUM DAS KEINE PRUEFUNG GEFUNDEN HAT, gleich zweimal:

  1. `chat.html` stand nicht in der Seitenliste von
     pruef-workspace-seiten. Eine Pruefung, die eine Seite nicht kennt,
     kann auf ihr nichts finden. Jetzt drin, zusammen mit
     leistung.html -- 18 Seiten statt 16.

  2. Die Buehnenregel lautete `r.buehne ? r.buehneBild === r.buehne :
     !!r.buehneBild` -- fehlt das Merkmal, reichte IRGENDEIN Bild.
     Gedacht war die Ausnahme fuer die Startseite, geschrieben war sie
     fuer jede Seite. Der Chat verlor sein `data-buehne`, fiel auf die
     Grundszene zurueck, und die Pruefung sagte "ein Motiv ist da,
     alles gut". Eine Bedingung, die bei fehlender Angabe MILDER wird
     statt strenger, kann den Verlust dieser Angabe nicht melden --
     sie belohnt ihn. Die Ausnahme haengt jetzt an der Startseite, nicht
     am Fehlen des Merkmals.

Die Regel ist dafuer aus der Schleife herausgeloest (`buehneRichtig`)
und hat sieben Gegenproben bekommen -- darunter genau den Chat-Fall.
Ohne sie waere "alles in Ordnung" nur die Aussage, dass die Regel
nichts gemeldet hat, nicht dass sie etwas melden koennte.

DIE AUSNAHME DES CHATS STEHT JETZT MIT NAMEN in der Pruefung, statt
dass die Seite aus der Liste faellt: Plakette und Wasserzeichen
entfallen dort, weil es den Ort dafuer nicht gibt -- Ton und Buehne
gelten. Ob der Chat eine Plakette bekommen soll, ist eine
Gestaltungsfrage fuer Filipe, keine Fehlerfrage.

ZWEI FALSCHE AUSSAGEN in tools/gate-bauen.mjs richtiggestellt:
"halle: dieselbe Sammlung, GESPIEGELT" -- nachgemessen haben beide
Dateien dieselbe Pruefsumme, es gibt in diesem Werkzeug keine
Spiegelung. Und "0,42 ist gemessen" ueber `const DUNKEL = 0.26`; der
Wert wurde gesenkt, die Zeile ist nicht mitgegangen. Ein Kommentar, der
mehr behauptet als der Code tut, ist schlimmer als keiner.

ZUM EIGENTLICHEN WUNSCH, ehrlich: Ich habe die Hintergrundhelligkeit
aller 18 Seiten nachgemessen. Die Scouting-Seite ist tatsaechlich die
hellste (0,0263), alle anderen liegen 19 bis 65 Prozent darunter --
aber der Grund ist NICHT die Bildbehandlung. Schleier und Abdunklung
sind fuer alle Seiten gleich und mehrfach nachgemessen. Der Unterschied
ist, WIE VIEL vom Bild noch zu sehen ist: Die Scouting-Seite traegt
eine schmale Karte, die anderen dichte Tabellen und Kachelraster. Das
liesse sich aendern, aber es ist eine Entscheidung ueber die
Inhaltsdichte von 17 Seiten -- die gehoert Filipe, nicht mir um zwei
Uhr nachts.

(Meine erste Messung sagte das Gegenteil. Sie nahm einen Streifen bei
x 0..150 -- ausgerechnet die dunkelste Spalte jedes Motivs. Danach
schien die Scouting-Seite fast schwarz, waehrend das Bildschirmfoto
derselben Seite hell und farbig ist. Ein Messfeld, das nicht
repraesentativ ist, misst zuverlaessig das Falsche.)

Geprueft: pruef-workspace-seiten (18 Seiten, alles in Ordnung),
pruef-buehne, pruef-css-klassen -- alle in Ordnung.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-09 00:14:48 +02:00
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]>
2026-09-07 07:12:48 +02:00
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]>
2026-09-06 22:06:49 +02:00
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]>
2026-09-03 10:02:09 +02:00
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]>
2026-09-01 15:04:23 +02:00
DogFatherGitandClaude Opus 5 0391a91d14 Neun Buehnen statt einer - jede Seite hat ihre eigene Szene
Filipe hat neun Bilder geschickt, damit es VERSCHIEDENE Hintergruende
gibt. Benutzt wurde davon genau eines (das Studio), die uebrigen acht
lagen unbenutzt im Ordner -- lounge.png und skyline.png sogar schon
fertig kopiert. Zu Recht beanstandet.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DREI FUNDE DURCH DIE PRUEFUNGEN:

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

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-01 09:55:25 +02:00
DogFatherGitandClaude Opus 5 43ce6551e2 Bereiche nur lesend fuer Creator + Content-Planung als echte Strecke
ZWEI SACHEN, beide auf Wunsch vom 31.08.2026.

1) "die creator sollen da nur die sehen die wir ihnen eintragen, also
   dogfather manager und scout."

Vorher durfte ein Creator in LIVE, Content, Technik, Community und Schutz
selbst anlegen, aendern und eigene Eintraege loeschen. Das hebelt den
Zweck dieser Bereiche aus: Sie sind die Betreuungsakte. Wer eine
LIVE-Auswertung umschreiben oder eine unbequeme Notiz verschwinden lassen
kann, macht die Akte wertlos.

Der Creator SIEHT weiterhin alles, was zu ihm gehoert -- vollstaendig.
Er kann es nur nicht veraendern. Umgesetzt als EINE Schranke vor allen
schreibenden Wegen, nicht als Pruefung an drei Stellen: Genau so ist hier
schon einmal ein Loch entstanden (zwei von drei Stellen abgesichert, die
dritte vergessen). 403 mit klarem Text statt 404 -- der Bereich existiert
fuer ihn ja, er steht davor.

Vorsicht Express 4: Der Platzhalter heisst dort `*`, nicht `*name` wie in
Fassung 5. Mit der falschen Schreibweise haette die Sperre stumm nichts
getan -- kein Fehler, keine Warnung.

37 Pruefungen, Schwerpunkt auf den verneinenden Faellen: alle fuenf
Bereiche, alle drei Wege, dazu der eigene Alteintrag (der frueher
ausdruecklich erlaubt war) und der Nachweis, dass hinterher wirklich
nichts veraendert wurde.

2) Content-Planung: aus der Liste wird eine Strecke.

Recherchiert statt geraten. Die Quellen sind an drei Punkten eindeutig:

  * "A content calendar for creators is a pipeline, not a datebook" --
    eine Wand aus Terminen verbirgt genau die Stellen, an denen es hakt.
  * Die ersten ein bis drei Sekunden entscheiden ueber die Verbreitung.
    Der Hook ist deshalb ein eigenes Feld auf jeder Karte, kein Fliesstext.
  * Regelmaessigkeit schlaegt Menge. Wer regelmaessig senden will, braucht
    VORRAT -- und Vorrat ist die eine Zahl, die eine Ideenliste
    verschweigt.

Daraus:
  * Fuenf Stufen statt drei (Idee, Hook & Skript, Gedreht, Fertig &
    geplant, Veroeffentlicht). Alte 'produktion'-Eintraege werden beim
    naechsten Start auf 'gedreht' umgestellt -- ohne das fielen sie aus
    jeder Spalte heraus.
  * Neue Felder hook, format, saeule_id, geplant (ALTER TABLE, gefahrlos).
  * Content-Saeulen je Creator, drei bis fuenf, nach der 70/20/10-Regel.
    Mit Balance-Balken ueber 90 Tage, nur Veroeffentlichtes -- was auf dem
    Kanal steht, ist die Wahrheit ueber seine Ausrichtung.
  * Die Kachel VORRAT rechnet in TAGE um ("reicht noch etwa 7 Tage").
    "4 Videos uebrig" sagt nichts; die Tage sagen, ob man am Wochenende
    drehen muss. Gezaehlt wird nur Gedrehtes und Fertiges -- eine Idee ist
    kein Video, und wer Ideen mitzaehlt, steht am Donnerstag ohne Material.
  * "Ideen lassen sich direkt in Aufgabe/Termin/LIVE-Thema ueberfuehren"
    -- woertlich aus dem Konzept, das letzte unumgesetzte Stueck. Die Idee
    bleibt bestehen und bekommt einen Vermerk, damit niemand dieselbe
    Aufgabe zweimal anlegt.

Farben: Die fuenf Saeulenfarben sind Daten, keine Dekoration. Geprueft
gegen genau diesen Hintergrund (#0a0d13) auf Helligkeitsband,
Farbstaerke, Farbfehlsichtigkeit (schlechtestes Paar dE 8.4),
Normalsicht-Abstand (19.3) und Kontrast -- alle Pruefungen bestanden.
Immer mit Legende UND Beschriftung; Farbe allein traegt nie die
Information.

Beim Ansehen des ersten Bildes fiel der klassische Brett-Fehler auf: Die
Spalte "Veroeffentlicht" waechst ewig und schiebt alles andere aus dem
Bild. Sie zeigt jetzt die juengsten sechs, der Rest ist einen Klick
entfernt. Die vorderen Spalten bleiben ungekuerzt -- was dort liegt, ist
Arbeit.

Nur EIN Schreiber fuer die Tabelle eintraege: workspace-content.js
enthaelt ausschliesslich, was es woanders nicht gibt (Saeulen,
Kennzahlen, Ueberfuehren). Zwei Module auf denselben Zeilen waeren der
sichere Weg zu zwei Wahrheiten.

45 + 40 Pruefungen, Computer und Handy, dazu die Gegenprobe: Ein Creator
sieht die ganze Strecke, die Kennzahlen und die Verteilung -- und keinen
einzigen Knopf, auch keinen versteckten. Ausgeblendet ist nicht dasselbe
wie nicht vorhanden.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-08-31 21:45:14 +02:00
DogFatherGitandClaude Opus 5 299d2a23b3 Workspace: Dashboard gebaut, Kopfleiste auf dem Handy repariert
Die Kachel "Dashboard" fuehrte nirgendwohin -- man stand ja schon auf der
Startseite. Statt sie zu streichen bekommt sie ein Ziel: die
Gesamtuebersicht je Creator, die das Konzept auf Seite 1 als "UEBERSICHT
-- alles zentral" verspricht und die es bisher nirgends gab. Die
Startseite bleibt der Einstieg (was ist dran, wohin gehe ich), das
Dashboard ist der Ueberblick (wie steht es um wen).

Eine Karte je Creator: ueberfaellig, dringend, offen, in Arbeit, im
Review, erledigt in 30 Tagen, dazu der naechste Termin, der Start-Check
als Balken und wie lange die Person nicht mehr da war. Jede Zahl ist ein
Verweis -- eine Zahl ohne Weg dorthin waere nur ein schlechtes Gewissen.
Sortiert nach dem, was Handlung verlangt, nicht alphabetisch.

Sichtbarkeit serverseitig wie ueberall: Creator sieht sich selbst
("Mein Stand"), Scout nur seine zugeteilten, DogFather und Manager alle.
Der naechste Review-Termin faellt fuer alle ausser der Leitung weg.

Nebenbei zwei alte Fehler gefunden und behoben:

1. Die Kopfleiste schob auf einem 390px-Handy 214 px aus dem Bild -- der
   Abmelden-Knopf war dort auf JEDER Seite unerreichbar. Ursache: In der
   Flex-Zeile fehlte min-width: 0, also konnte nichts schrumpfen. Auf
   kleinen Schirmen weicht jetzt die Marke (steht direkt darunter noch
   einmal als Ueberschrift) und der Zurueck-Knopf zeigt nur den Pfeil.
   Geprueft von 320 bis 1440 px auf 14 Seiten.

2. .inhalt--breit, .kopf-zeile, .zurueck und .leise standen in
   aufgaben.css -- einer Datei, die eine neue Seite gar nicht laden muss.
   Derselbe Fehler wie frueher bei .knopf-still und .schalter. Jetzt in
   start.css, die jede Seite laedt.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-08-31 13:17:04 +02:00