d6df590224550add767cbdd9ee609f6e396676c8
847
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
d6df590224 |
Telefonieren ging nur ueber UDP -- und die Seite sprang immer hoch
=== 1. WARUM TELEFONIEREN NICHT GING ===
Filipe: "es klingelt erscheint auch alles bei jedem aber telefonieren
klappt immer noch nicht."
GEMESSEN, BEVOR ETWAS GEAENDERT WURDE -- und alles war gruen:
coturn laeuft aktiv
STUN von aussen antwortet, nennt meine oeffentliche Adresse
echte Zuteilung von aussen 7/7, Testpaket kam an (Port 49183)
Dreier-Anruf im Prueflauf verbindet, alle hoeren alle
Vier Messungen, vier Mal in Ordnung -- und das Telefon ging trotzdem
nicht. Der Grund: Der Prueflauf faehrt BEIDE Seiten auf demselben
Rechner. Dort finden sie sich ueber die direkte Adresse, und die
Vermittlung wird nie gebraucht. Draussen sitzen sie in verschiedenen
Netzen.
DER FUND: Eingetragen war eine einzige Adresse --
turn:159.195.212.167:3478
Ein `turn:` OHNE `?transport=` heisst UDP, und nur UDP. Nachgemessen
hoert coturn aber auf beidem: 3478/UDP offen, 3478/TCP offen (5349/TLS
ist zu). Angeboten wurde nur der halbe Server.
Wer in einem Netz sitzt, das UDP nach draussen sperrt -- Mobilfunk mit
strengem Profil, Gast-WLAN, Firmennetz --, bekam damit KEINEN
Vermittlungsweg. Es klingelt (das laeuft ueber die Website, also ueber
443), und danach passiert nichts. Genau das gemeldete Bild.
Aus einem Eintrag werden jetzt drei Wege:
stun:host:port die eigene Adresse finden, ohne Vermittlung
turn:host:port?transport=udp der schnelle Weg
turn:host:port?transport=tcp der Weg durch fast jede Sperre
ABGELEITET, NICHT EINGETRAGEN: Drei Zeilen von Hand waeren drei
Stellen, an die beim naechsten Serverumzug jemand denken muesste --
die abgeschriebene Liste, die hier schon zweimal teuer war. Ein
Eintrag MIT `?transport=` bleibt unangetastet, ein fremder Dienst mit
eigenem Passwort sowieso.
pruef-turn-wege (neu, 15/0) sichert beides: dass jeder Weg herauskommt
UND dass jeder turn:-Weg Zugangsdaten traegt. Das Zweite ist das
wichtigere -- auffaechern ohne anmelden haette den Fehler nur
verschoben.
=== 2. DIE SEITE SPRANG BEIM ZURUECKGEHEN IMMER HOCH ===
Filipe: "das nervt man muss dan immer wieder runter scrollen bis man
da ist wo man vorher war."
Der Browser versucht es sogar -- scrollRestoration steht ab Werk auf
"auto". Nur: Jede Seite hier kommt fast leer an und holt ihren Inhalt
danach per Abruf. In dem Moment, in dem der Browser die alte Position
wiederherstellen will, ist das Dokument ein paar hundert Pixel hoch.
Er kann nicht auf Zeile 900 springen, die es noch nicht gibt -- und er
versucht es kein zweites Mal.
Jetzt macht es kopf.js selbst (gilt damit auf allen 21 Seiten): Stelle
merken beim Verlassen, beim Oeffnen zurueckholen und jeden Bildaufbau
lang versuchen, bis das Dokument hoch genug ist. Nach drei Sekunden
wird aufgegeben.
Drei Dinge sind Absicht:
- NUR beim Zurueckgehen, nicht bei jedem Oeffnen. Wer eine Kachel
anklickt, will oben anfangen.
- WER SELBST SCROLLT, GEWINNT. Rad, Wisch oder Taste beenden das
Nachspringen sofort.
- Nach einer Stunde vergessen -- auf Zeile 900 zu landen, weil man
gestern dort war, ist keine Hilfe.
=== 3. DIE LISTE IST NACH ROLLE GETRENNT ===
Filipe: "die rechte hand rolle immer zuerst und dan die modis. die
sollen auch schoen getrennt sein und verschieden aussehen also die
rechte hand viel spezieller."
Die Reihenfolge macht der Server ueber ROLLEN_SORTIERUNG -- dieselbe
Konstante wie ueberall sonst im Haus, nicht eine zweite. Eine
Sortierung nach ROLLE ist ausdruecklich keine Rangliste: Sie sagt
nichts darueber, wie gut jemand ist, nur welche Aufgabe er hat.
Deshalb steht ueber jeder Gruppe ein Satz und keine Zahl.
"Spezieller" heisst hier Material, nicht Groesse: eigener Farbton als
Kante und Schimmer, hellere Flaeche, kraeftigerer Name. Beide Karten
sind GLEICH GROSS und tragen dieselben Zeilen -- zwei Sorten Aufgabe,
keine Rangfolge. Im Kontrastmodus traegt eine doppelte Kante die
Unterscheidung, weil dort keine Farbe mehr wirkt.
=== 4. DER ANRUFKASTEN ===
Vorher: vier gleich aussehende Pillen nebeneinander, darunter eine
Geraeteauswahl, die das breiteste Element war. Kein Name, keine
Ordnung, und der einzige Knopf mit Folgen sah aus wie die anderen.
- MAN SAH NICHT, MIT WEM. Der wichtigste Satz eines Telefonats fehlte.
Der Chat kennt den Namen und gibt ihn jetzt mit; wer rangeht, sieht
den Anrufer.
- "MIKRO AN" WAR ZWEIDEUTIG -- "ist an" oder "schalt an"? Wer falsch
raet, sitzt stumm da. Jetzt traegt ein durchgestrichenes Zeichen
den Zustand, das Wort nur die Sache. aria-pressed bleibt die
Wahrheit, auch fuer Vorleseprogramme.
- DIE GERAETEAUSWAHL liegt hinter einem kleinen Knopf, der nur
erscheint, wenn es ueberhaupt etwas zu waehlen gibt.
- AUFLEGEN ist als einziger Knopf farbig und steht immer rechts.
- Ein ruhiger Puls atmet, solange die Verbindung aufbaut, und haelt
an, sobald sie steht. Bei prefers-reduced-motion steht er still.
=== NEBENBEFUND, DEN DIE PRUEFUNG GEFUNDEN HAT ===
pruef-anruf wurde durch die Auffaecherung an vier Stellen rot: Sie
griff `adressen[0]` und erwartete dort Zugangsdaten. Das ist jetzt der
STUN-Weg, und der hat richtigerweise keine. Gesucht wird nicht mehr
nach PLATZ, sondern nach ART -- ein Index ist eine Annahme darueber,
wie die Liste aussieht, und die hat sich gerade geaendert.
Dazu angepasst: Die Pruefung "die Uhr laeuft" verlangte, dass die Uhr
schon beim Klingeln zaehlt. Seit heute frueh beginnt sie beim
Rangehen (sonst standen im Kasten und im Chat zwei verschiedene
Zahlen). Sie prueft jetzt das Gegenteil -- statt sie zu streichen,
denn eine Zeile weniger haette den Fehler beim naechsten Umbau wieder
durchgelassen.
GEMESSEN: pruef-anruf 114/0 (vorher 111 -- drei MEHR, weil die
Auffaecherung mitgeprueft wird), pruef-turn-wege 15/0,
pruef-meldungen 8/0, pruef-css-klassen ALLES IN ORDNUNG,
pruef-rechtetafel 19/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
18a5231b70 |
Die Tuer ohne Klingel, der Anruf ohne Ende, die Glocke ohne Liste
Siebter Durchgang durch die Team-Dogi-Seiten aus Benutzersicht. Alles am
Code belegt, die Groessenangaben nachgerechnet.
=== DIE ANMELDUNG ===
WOHER BEKOMMT MAN EINEN CODE? Stand nirgends. Vier Kacheln, ein Feld,
ein Knopf -- wer keinen Code hatte, fand keinen einzigen Satz dazu. Fuer
die Community besonders teuer: Sie ist die einzige Rolle, die von
aussen kommt und niemanden im Haus kennt.
"BITTE KURZ WARTEN" SIND BIS ZU ZEHN MINUTEN (VERSUCHE_FENSTER_MIN).
Wer nach zwanzig Sekunden nachsieht und dieselbe Meldung liest, haelt
die Seite fuer kaputt. Jetzt steht die Zahl da.
EIN RICHTIGER CODE AN DER FALSCHEN KACHEL fiel in dieselbe Absage wie
ein erfundener -- der Server sucht nur unter der gewaehlten Rolle. Wer
aus der Community kommt und auf "Modi" tippt (das klingt ja danach),
tippt seinen richtigen Code dreimal Buchstabe fuer Buchstabe. Ab dem
zweiten Fehlversuch kommt jetzt ein Hinweis auf die Auswahl -- ohne zu
sagen, welche die richtige waere.
=== DER ANRUF: VIER FEHLER, EINE ERFAHRUNG ===
DAS FREIZEICHEN LIEF UNENDLICH. Es gab keinen Zeitgeber, der aufhoert.
Wer niemanden erreichte, sass vor einem piependen Kasten mit "02:47"
darauf, als telefoniere er laengst. Der Server schickt den Verfallszeit-
punkt sogar mit (`laeuft_bis`) -- benutzt hat ihn nie jemand.
DER KLINGELKASTEN VERSCHWAND NACH 46 SEKUNDEN, waehrend der Server 120
gibt. Wer beim Klingeln das Handy aus der Tasche holt und in Sekunde 50
hinsieht, fand nichts mehr -- kein Kasten, keine Knoepfe -- waehrend der
Anrufer noch siebzig Sekunden Freizeichen hoerte. Die 120 Sekunden sind
im Server ausdruecklich damit begruendet, dass man Zeit zum Entsperren
braucht; eine Zeile im Browser hat diese Entscheidung aufgehoben.
DAS FREIZEICHEN PIEPTE WEITER, waehrend daneben "Keine Verbindung."
stand. Ton sagte "es klingelt noch", Text sagte "vorbei".
DIE UHR ZAEHLTE AB DEM WAEHLEN. Wer 30 Sekunden klingeln liess und 12
Sekunden sprach, las im Kasten "00:42" und danach im Chat "Anruf . 12
Sekunden". Der Server rechnet es richtig; der Kasten hat es wieder
kaputtgemacht.
Dazu: Die Mikrofon-Absage verwies auf "das Schloss-Symbol neben der
Adresse" -- in der installierten App gibt es weder Adresszeile noch
Schloss. Das Haus kennt diesen Fehler und hat ihn beim Weg zur
Anruf-Probe schon behoben; hier stand er noch.
Und die Anruf-Probe: Ihr einziger Punkt ohne Handlungsanweisung war
"Antwort 503." -- auf einer Seite, die ausdruecklich fuer jemanden
gebaut ist, der nicht technisch ist. Ihr Rueckweg fuehrte ausserdem
immer in den Chat, auch wenn man von der Startseite kam.
=== DER TREFF ===
EIN EINZEILER MACHTE SECHS ERKLAERTEXTE UNSICHTBAR. bewerben.js las
`g.unter`, der Server schickt `g.text` -- also immer undefined. Damit
fehlten ALLE SECHS Gruppeneinleitungen des Fragebogens ("Kein Test mit
richtigen Antworten"), und die CSS-Regel dafuer lief ins Leere. Uebrig
blieben sechs nackte Ueberschriften ueber fuenfzehn Fragen.
DIE EINZIGE "SO LAEUFT DAS HIER"-SEITE WAR FAST UNERREICHBAR. Die
Kachel "Regeln & Hilfe" zeigte auf ein Brett, das am ersten Tag leer
ist. Die Regeln, die es wirklich gibt (Begruessung, fuenf Regeln, drei
Stufen, Mindestalter), stehen auf treff-regeln.html -- erreichbar ueber
genau einen kleinen Textlink auf einer Brettseite. Die Kachel zeigt
jetzt dorthin.
FIEL /api/treff/lage AUS, versprach die Seite einem Zuschauer
Schreibrechte, die der Server ablehnt: Die Pruefung fiel bei `lage ===
null` auf `true` durch -- von "darf auf keinem Brett" auf "darf
ueberall". Formular auf, getippt, 403.
Dazu: hilfe.js hatte eine eigene kleine Fehlertabelle fuer zwei
Kennungen und endete sonst bei "Ging nicht." -- ausgerechnet die Seite,
auf der jemand mit einem Problem sitzt, hatte die inhaltsleerste Absage
im Haus. Und der gesperrte "Neue Meldung"-Knopf erklaerte sich nur im
Maus-Tooltip; die Community kommt von TikTok, also vom Handy.
=== DIE STARTSEITE ===
DIE COMMUNITY BEKAM EIN WORT. Unter dem Titel steht bei jeder Rolle ein
Satz -- beim Community-Mitglied stand "Community". Woertlich derselbe
Mangel, den der Kommentar bei MODI_ROLLENTEXT beschreibt und fuer den
Modi behebt.
DER RING MELDETE 100 %, bevor man irgendetwas getan hat. Am ersten Tag,
ohne eine einzige Aufgabe, stand das groesste Element der Seite auf
"100 % -- HEUTE NICHTS OFFEN". Gelesen wird zuerst die Zahl, und 100 %
heisst fuer jeden "fertig", nicht "leer".
UND BEI EINER STOERUNG BLIEB "wird geladen" FUER IMMER STEHEN -- der
fruehe `return` liess den Platzhalter unberuehrt.
=== DIE ZUGANGSVERWALTUNG ===
Der Code-Kasten sagte "jetzt weitergeben" und gab die Haelfte nicht
mit, die man weitergeben muss: WO sich die Person anmeldet. DogFather
ruft den Code durchs Zimmer, der andere fragt "und wo?". Die Adresse
kommt jetzt vom Server (anmeldeAdresseFuer, abgeleitet aus derselben
Weiche), dazu ein Knopf "Code und Adresse kopieren".
Er verschwieg ausserdem den Rettungsweg: "danach nicht mehr abrufbar"
stimmt fuer DIESEN Code -- man kann jederzeit einen neuen vergeben. Wer
das nicht weiss, glaubt, er habe einen Menschen angelegt, der nie
hereinkommt. Und das Fenster liess sich wortlos schliessen, waehrend
der Code offen stand.
=== OPTIK: NACHGERECHNET, NICHT VERMUTET ===
DIE GLOCKE STAND NICHT IN DER LISTE. Sie ist ein echtes <button> und
wurde von der 44-px-Regel erfasst, waehrend ihre vier Nachbarn durch
einen staerkeren Selektor auf 36 px gehen. Zwischen 401 und 560 px --
also bei 412 px (haeufigste Android-Breite) und 430 px (iPhone Pro Max)
-- stand eine 44 px hohe runde Pille zwischen fuenf 36-px-Quadraten.
Der 400er-Block listet sie korrekt; genau dieses Band fiel durch beide
Rechnungen. Dasselbe Muster wie am 06.09.
DIE 9,6-px-REPARATUR IM KALENDER WAR SEIT WOCHEN WIRKUNGSLOS.
kalender.css wird NACH start.css geladen, beide Selektoren sind gleich
stark -- also gewann `.6rem` auf jeder Breite unter 760 px. Genau der
Wert, den start.css als behobenen Fehler protokolliert.
Und die Hebung selbst unterschritt ihre eigene Grenze: Die Regel, die
zu kleine Schrift hochziehen soll, zog `.k-pille` auf 11,2 px -- 0,3 px
unter die 11,5, die 33 Zeilen darueber aufgestellt werden.
Weitere nachgerechnete Groessen: Spaltenkopf und KW-Spalte im Kalender
(10,56 px), Kalenderwoche am Balken (9,92 px), Wecker-Knopf (30 px --
der kleinste im Haus, 14 unter der Vorgabe), Chat-Zurueck auf dem
Tablet (34x34, 40 % weniger Flaeche als noetig, und der einzige Weg
zurueck in die Liste), Emoji-Knoepfe (34 px bei 2 px Abstand -- wer
danebentippt, verschickt ein anderes Zeichen, und das ist sofort
abgeschickt).
IM WINDOWS-KONTRASTMODUS HATTE DIE STARTSEITE KEINE UEBERSCHRIFT.
`.ztitel` und der Team-Dogi-Schriftzug sind mit `background-clip: text`
gesetzt; faellt der Verlauf weg, bleibt durchsichtiger Text. Beide
haben jetzt den Rueckfall, den gate.css schon lange hat.
UND MEIN EIGENES STREIFENRASTER rechnete die Spaltenzahl aus der Breite
statt aus den Daten (`auto-fit`): Bei 390 px passten sechs, alles
darueber fiel in eine zweite, unbeschriftete Zeile. Das `overflow-x`
daneben konnte nie greifen -- ein auto-fit-Raster wird nie breiter als
sein Kasten. Der Kommentar beschrieb ein Verhalten, das es nicht gab.
GEMESSEN: pruef-meldungen 8/0, pruef-css-klassen ALLES IN ORDNUNG,
pruef-rechtetafel 19/0, alle Module laden, keine doppelten
Kachelnamen/-ziele/-farben in allen vier Rollen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
273318dd9c |
Vier Sackgassen, zwei Kacheln namens "Chat" -- und eine Seite ohne Kopf
Durchgang durch die Team-Dogi-Seiten aus der Sicht von jemandem, der
sie zum ersten Mal sieht. Alles hier ist am Code belegt und nachgemessen.
1. "KLINGELT NICHTS?" WARF ALLE DREI TEAM-ROLLEN AUF DIE STARTSEITE.
anruf-probe.html erklaert, WARUM das Telefon stumm bleibt. Sie steht in
der Rechtetafel offen, und aus dem Chat zeigen zwei Knoepfe darauf. Nur
hatte sie nie eine Kachel -- absichtlich, sie ist kein Bereich. Seit die
Adressregel vom 15.09. eine Kachel VERLANGT, landete jeder Klick wortlos
auf start.html.
Das ist die schlimmste Sorte Sackgasse: Man ruft sie auf, WEIL schon
etwas nicht geht, und sie wirft einen hinaus.
Mit derselben Zeile geheilt: Die Hinweisleiste wirft jeden Hinweis weg,
dessen Ziel es auf dieser Adresse nicht gibt -- "Bei dir klingelt nichts"
wurde auf crew deshalb NIE angezeigt. Ausgerechnet der Hinweis, der acht
von elf Leuten betrifft.
2. UND DIESE SEITE HATTE GAR KEINE GESTALTETE KOPFLEISTE.
.kopfleiste, __zurueck, __mitte, __titel stehen in KEINER Stilvorlage --
sie leben in start.css, die diese Seite absichtlich nicht laedt. Die
Leiste war nackter Text. Auf einer Seite, die man im Stoerfall aufruft,
sieht unfertig aus wie kaputt. Jetzt im <style>-Block der Seite, aus
demselben Grund wie ihr uebriges CSS.
3. EIN MODI KAM NICHT AN SEINE EIGENE AUSWERTUNG.
entwicklung.html und werdegang.html haben BEIDE eine ausgearbeitete
Eigensicht, und die Rechtetafel laesst ihn hinein. In seiner Kachelliste
stand keine von beiden -- der Weg existierte fuer ihn nicht. Die ganze
Eigensicht war toter Code, ausgerechnet fuer den, fuer den sie ist.
Mein eigener Fehler vom Vortag.
Zwei eigene Kacheln in "Fuer dich", aus den Leitungskacheln abgeleitet.
Sie loesen zugleich eine Namenskollision: Bis heute setzten BEIDE Seiten
fuer ihn die Ueberschrift "Deine Entwicklung".
4. DER KALENDER-LINK WAR FUER DIE COMMUNITY EINE SACKGASSE.
Auf jeder Brettkarte mit Termin stand "Im Kalender am 24.09." als Link.
kalender.html steht auf ALLE -- und ALLE ist ausdruecklich ohne "gast".
Jetzt fragt der SERVER die beiden Schranken (kalender_offen) und die
Karte zeigt den Termin als Text statt als Link. Die Auskunft bleibt, nur
der Weg ins Leere faellt weg. Die Regel im Browser nachzubauen waere die
vierte Stelle fuer dieselbe Frage gewesen.
5. EIN MODI KAM AN DIE TALENTE-NOTIZEN, DIE IHM VERWEHRT SIND.
BRETTER_UEBER_SEITEN war eine feste Liste ("wer die Seite darf, muss
auch dorthin kommen") und fragte nie, WER fragt. Ueber
bereich.html?b=talente kam er an Notizen zu Zuschauern, obwohl
talente.html fuer ihn gesperrt ist -- Begruendung dort: "Hier stehen
Namen von Menschen, die nichts davon wissen."
Aus der Liste wurde eine Zuordnung Brett -> Seite, gefragt wird
darfSeite(). Nachgemessen: modi/talente 404, modi/entwicklung darf,
hand+admin unveraendert.
Dazu stand in workspace-bereiche.js ein Kommentar, der das GEGENTEIL des
Codes behauptete ("entwicklung, talente bleiben 404"). Ein falscher
Kommentar an einer Rechtestelle ist schlimmer als keiner.
6. ZWEI KACHELN "CHAT", BEIDE AUF DIESELBE SEITE.
Seit dem Treff-Chat von gestern sahen Modi und rechte Hand zweimal
"Chat" mit demselben Ziel. Jetzt "Treff-Chat" mit ?raum=treff, das den
Raum direkt oeffnet -- gesucht an denselben zwei Merkmalen, an denen ihn
der Rest der Datei erkennt.
7. VERTRAUEN: "WIE GEHT'S DIR?" VERSPRACH MEHR, ALS ES HALTEN KANN.
Dort stand: "Niemand aus dem Team sieht deine Antworten -- auch
DogFather nicht." Punkt. Fast wahr und deshalb gefaehrlich: Aus
denselben Antworten entsteht eine namenlose Ampel fuer die Leitung.
Der ehrliche Satz war laengst geschrieben und wurde vom Server sogar
mitgeliefert (block.text) -- nur hat ihn nie jemand angezeigt. Er steht
jetzt im HTML, nicht im Skript: Wer die Seite oeffnet, soll ihn lesen,
BEVOR er tippt.
8. DIE NEUE AUSWERTUNG, AUS BENUTZERSICHT NACHGEBESSERT.
- Der Streifen hatte keine Zeichenerklaerung. Im Dateikopf stand "wer
Farben schlecht unterscheidet, liest dasselbe Zeichen" -- das stimmt
nur, wenn irgendwo steht, was die Zeichen heissen. Jetzt eine Legende,
aus `stufen` gebaut statt abgeschrieben.
- "nie gesetzt" war ein Mittelpunkt, "Kann ich nicht sagen" ein
Halbgeviertstrich. Zwei kurze Striche nebeneinander fuer den
Unterschied zwischen "niemand hat hingesehen" und "jemand hat
hingesehen und konnte es nicht sagen". Leer ist jetzt wirklich leer,
mit gestricheltem Rahmen.
- Die Aufschluesselung der Balken stand nur im Mausueberfahren -- am
Handy also nie, und dort steht jemand damit im Stream. Jetzt als Text.
- Die Modi-Sicht bekam Balken ohne Erklaerung, ein "Frag danach" ohne
Adressaten und bei fehlender Bewegung ein LEERES Element. Jetzt
Lesehilfe, ein Leerkasten mit Satz und zwei Wege weiter.
9. NEBENBEFUNDE, DIE DIE PRUEFUNG GEFUNDEN HAT.
pruef-css-klassen war schon VOR dieser Arbeit rot (nachgemessen mit
git stash). Alle drei Befunde behoben:
- hilfe.html und unsere-seiten.html luden ihre Seitendatei NACH
module.css und haus.css und ueberschrieben damit das Haus.
- Zwei Schriftgroessen unter 11,5 px aus dem gestrigen Bau
(.71rem Monatsbeschriftung, .68rem Marke) auf .75 und .72 gehoben.
- Die Pruefung selbst war blind fuer <style>-Bloecke in der Seite und
meldete deshalb dauerhaft drei Fehler an einer Seite, die ihre
Stile mit Absicht selbst traegt. Eine Warnung, die immer kommt, ist
keine Warnung mehr -- jetzt sieht sie hin, statt die Seite
auszunehmen.
Kleinkram nebenbei: "die Antworten sieht nur du" -> "siehst nur du" auf
der Kachel zur empfindlichsten Seite des Hauses. "Bewertet wird dort" ->
"Eingeschaetzt wird dort" in teamlage.html, zwei Zeilen unter "keine
Bewertung von Menschen". "1 Aufgabe(n) angelegt" ausgeschrieben.
GEMESSEN: pruef-css-klassen ALLES IN ORDNUNG (vorher 3 Fehler),
pruef-meldungen 8/0, pruef-rechtetafel 19/0, alle Module laden,
keine doppelten Kachelnamen/-ziele/-farben mehr in allen vier Rollen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
461d41943a |
Keine Maschinensprache mehr auf dem Bildschirm
Filipe: "keine kryptischen oder technischen fehlermeldungen, sondern
klare aussagen darueber, was passiert ist und wie man das problem
loesen kann."
DAS PROBLEM, NACHGEMESSEN.
Der Server antwortet im Fehlerfall mit { fehler: "..." }. Darin stehen
ZWEI verschiedene Dinge, und von aussen sehen sie gleich aus:
Maschinenkennungen (nicht_verfuegbar, nicht_gefunden, ungueltig -- 43
verschiedene) und fertige deutsche Saetze.
An 84 Stellen stand `textContent = d.fehler` -- ungefiltert. Wer beim
Hochladen einer Datei Pech hatte, las woertlich "nicht_verfuegbar" auf
dem Bildschirm und wusste nicht einmal, ob er selbst schuld war.
Gezaehlt: 474 Antworten mit "nicht_verfuegbar", 392 mit
"nicht_gefunden", 125 mit "ungueltig".
DREI AUSGAENGE, NICHT ZWEI.
`sagWas()` in workspace/assets/js/meldung.js:
bekannte Kennung -> ihr Satz
unbekannte Kennung -> der Ersatzsatz der Stelle, NIE die Kennung
(sie geht in die Konsole, wo sie jemandem
auffaellt, der sie beheben kann)
fertiger Satz -> unveraendert durch
Erkannt wird eine Kennung daran, dass sie nur aus Kleinbuchstaben,
Ziffern und Unterstrichen besteht. Ein deutscher Satz hat immer
Leerzeichen; eine Kennung nie. Die Unterscheidung ist entschieden,
nicht geraten.
UND WARUM DIE TABELLE NICHT ALTERN KANN.
Eine von Hand gepflegte Liste ist hier schon zweimal teuer geworden
(die abgeschriebene Spaltenliste, die feste Umbruchschwelle). Deshalb
rechnet pruef-meldungen.mjs die Kennungen AUS DEM SERVER aus statt sie
zu kennen -- eine neue ohne Satz macht sie rot. Man kann es nicht mehr
vergessen.
Sie prueft drei Dinge und beweist zu jedem, dass sie auch "nicht in
Ordnung" sagen kann:
1. vollstaendig -- jede Kennung hat einen Satz
2. angeschlossen -- keine Rohanzeige, und jede Seite, deren Skript
sagWas benutzt, laedt auch meldung.js
3. lesbar -- kein Satz enthaelt Kennung, Zahl oder englisches Wort
GEFUNDEN HAT SIE SOFORT EINEN ECHTEN FEHLER: leistung.html laedt seine
Skripte ohne `defer` und fiel damit durch meinen Einbau. Dort waere
sagWas nicht definiert gewesen -- aus einer Fehlermeldung waere ein
Absturz geworden, also schlimmer als vorher.
NEBENBEFUND, DER MICH FAST EINE FALSCHE MELDUNG GEKOSTET HAETTE:
"alter_offen" heisst NICHT "etwas Aelteres ist offen", sondern
"Altersbestaetigung steht noch aus" (workspace.js:4864). Geraten
haette ich es falsch uebersetzt.
GEMESSEN: pruef-meldungen 8/0, alle 46 Skripte syntaktisch in Ordnung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
7be85c265b |
Der Treff bekommt einen Chat -- mit Nachtruhe, ohne Telefon
Filipe, auf die Frage ob die Community einen Chat bekommen soll:
"eine geile mischung von punkt 2 und drei. mach es perfekt so das quasi
nach mitternacht bis morgens 6 uhr keiner schreiben kann damit auch die
privatsphaere beruecksichtig wird ueber nacht ... und die sollen nicht
anrufen koennen. nur schreiben."
Zur Auswahl standen "gar kein Chat", "nur mit Oeffnungszeiten" und
"offen wie im Team". Seine Antwort ist eine vierte, die nicht auf dem
Zettel stand, und sie ist die bessere.
1. WARUM DIE NACHTRUHE MEHR IST ALS EINE EINSTELLUNG
Sein Grund war Privatsphaere -- und zwar die der Leute, die moderieren.
Die Forschung zu ehrenamtlichen Moderatoren sagt genau das: Die beiden
meistgenannten Gruende fuers Aufhoeren sind ZU WENIG ZEIT und STREIT IM
TEAM. Ein Chat, der nachts um drei weiterlaeuft, erzeugt beides.
SIE GILT FUER ALLE, AUCH FUER DIE LEITUNG. Das ist die unbequeme
Entscheidung: Der bequeme Weg waere, DogFather auszunehmen. Aber wenn er
um halb vier schreibt, liest es jemand -- und wer liest, fuehlt sich
zustaendig. Eine Nachtruhe, von der die Leitung ausgenommen ist, ist
keine, sondern eine Bitte.
MODERIEREN GEHT WEITER. Verbergen, loeschen, herausnehmen sind keine
Nachrichten. Wer nachts etwas Schlimmes sieht, kann es wegnehmen -- er
kann nur nicht darueber diskutieren. Und der vertrauliche Meldeweg
bleibt offen: Er ist ein Fall mit einer Zustaendigkeit, kein Raum mit
dreissig Leuten.
GERECHNET IN ORTSZEIT, nicht in UTC. `getHours()` auf einem UTC-Server
haette den Chat im Sommer von 2 bis 8 geschlossen -- zwei Stunden
daneben, und nur denen sichtbar, die um diese Zeit wach sind. Dieses
Haus ist mit der Rechnung schon zweimal hereingefallen.
DER RIEGEL SITZT IM SERVER, nicht im Browser. Ein ausgegrautes Feld ist
eine Hoeflichkeit; wer die Adresse kennt, spricht die Schnittstelle
direkt an. Nachrichten UND Anhaenge werden abgelehnt -- ein offener
Anhangweg waere der Umweg, den jeder findet, der es einmal versucht.
2. KEIN TELEFON -- UND WARUM DAS EINEN EIGENEN RIEGEL BRAUCHT
Ein Anruf haengt in diesem Haus an der RAUMMITGLIEDSCHAFT, nicht an der
Rolle. Solange die Community keinen Raum hatte, war die Frage muessig.
Seit sie einen hat, waere Telefonieren erlaubt -- nicht, weil es jemand
entschieden haette, sondern weil es niemand verboten hat.
Der Riegel steht ganz vorne am Anruf-Router, nicht in den neun Routen
dahinter. Alle sieben Wege sind geprueft, einzeln.
3. DER FUND, DER DIE GANZE NACHTRUHE UMGANGEN HAETTE
Ein Gast konnte ein PRIVATES ZWEIER-GESPRAECH mit DogFather aufmachen.
Die Route antwortete mit 200 und legte den Raum an.
`ohneAussen` nimmt die Community aus den Listen ANDERER heraus -- damit
kein Creator einen Zuschauer anschreibt. Die Gegenrichtung kam nie vor,
weil die Chatseite fuer 'gast' gar nicht offen war. Seit heute ist sie
offen, und damit war die Erlaubnis da.
Ein Zweier-Gespraech ist kein Kanal: keine Nachtruhe, kein Modi liest
mit, niemand koennte moderieren. Aus "die Community bekommt einen Chat"
waere ungewollt "jeder Zuschauer bekommt eine Standleitung zu
DogFather" geworden.
GEFUNDEN HAT ES DIE PRUEFUNG, NICHT DAS LESEN -- und zwar in dem Moment,
in dem ich zwei Dateien weiter selbst vor genau dieser Sorte Erlaubnis
gewarnt hatte.
4. ZWEI TOTE WEGE, EINER DAVON MEINER
pruef-community-sicht sucht nach sichtbaren Wegen, die ins Leere
fuehren. Sie fand zwei:
a) "Bei dir klingelt nichts" -> anruf-probe.html. Der Hinweis von
heute Vormittag, und die Seite steht einem Gast ausdruecklich NICHT
offen. Mein Fehler, und einer, der jedem naechsten Hinweis genauso
passiert waere.
AN DER WURZEL BEHOBEN: Die Hinweise pruefen jetzt auch die ROLLE
(`darfSeite`), nicht nur die Adresse. Das ist der 15.09. noch
einmal, eine Ebene tiefer -- damals die Adresse, diesmal die Rolle,
und dieselbe Lehre: Die Hinweise sind eine DRITTE Stelle neben
Seiten und Schnittstellen.
b) Der Verweis "Kalender" im Tagesblick. Steht fest im HTML, fuehrt
fuer die Community ins Leere -- und zwar SCHON VOR den Aenderungen
dieses Tages. Aufgefallen nur, weil (a) daneben stand. Der Weg
wird jetzt abgeleitet: Wer die Kachel hat, hat den Weg.
5. DIE PRUEFUNG LAEUFT ZWEIMAL
Die Nachtruhe laesst sich nicht in EINEM Lauf in beiden Zustaenden
pruefen -- die Zeiten werden beim Laden gelesen, und ein zweiter Server
braeuchte denselben Port. pruef-treffchat ruft sich deshalb selbst noch
einmal auf, mit einem Fenster, das jetzt gilt. Dieselben Pruefungen,
andere Lage.
DIE UHR WIRD NICHT GEFAELSCHT. Verschoben wird die GRENZE, nicht die
Zeit -- eine Pruefung, die an der Systemzeit dreht, faelscht danach auch
anderes mit und ist nur nachts gruen.
6. WAS SICH NEBENBEI GEAENDERT HAT
- pruef-treff war SCHON VORHER ROT (8 Fehler): Sie erwartete sieben
Kacheln fuer die Community, es waren gestern Nacht schon zehn. Feste
Zahlen, Rechnung von gestern. Jetzt abgeleitet -- 72 Pruefungen statt
66, alle gruen.
- Ein 404 bei jedem Seitenaufruf der Community: `anruf.js` holte die
Verbindungsadressen, bevor es wusste, wer fragt. Der Browser
protokolliert das, BEVOR JavaScript abfangen kann -- also darf die
Anfrage gar nicht erst gestellt werden. `/api/ich` sagt es jetzt
vorher. Ein Fehler, der immer kommt, macht den naechsten echten
unsichtbar.
- Reaktionen (Daumen) bleiben nachts erlaubt. Ausdruecklich, mit
Begruendung im Code: Ein Daumen ist keine Nachricht, er loest keine
Meldung aus und kann keinen Streit anfangen. Eine Luecke ohne
Begruendung wird beim naechsten Durchsehen entweder geschlossen oder
uebersehen -- beides falsch.
GEMESSEN: pruef-treffchat 108/0 (neu, laeuft zweimal), pruef-treff 72/0
(vorher 66 mit 8 Fehlern), pruef-chat gruen, pruef-rechtetafel 19/0,
pruef-community-sicht gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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 (
|
||
|
DogFatherGitandClaude Opus 5
|
6c10ef0600 |
Wie geht's dir?: fester Kern, wechselnde Fragen -- und die leere Runde
Dein Auftrag von vorher, zusammen mit zwei Saetzen, die sich zu
widersprechen schienen: "viel mehr Fragen" und "kurz und knapp".
1. DER FEHLER, DEN ICH DABEI GEFUNDEN HABE, WAR GROESSER.
Eine Runde galt als vollstaendig, sobald zu jeder Frage IRGENDEIN Stand
vorlag. Nach der ersten Runde ist das immer der Fall -- die Antworten
bleiben ja stehen. Ab da liess sich jede weitere Runde abschliessen,
OHNE eine einzige Frage anzufassen: Die alten Antworten wanderten mit
neuem Datum ein zweites Mal in den Verlauf.
Der Verlauf zeigte dann eine gerade Linie, und die bedeutete nicht "es
ist gleich geblieben", sondern "niemand hat gefragt". Genau die Sorte
Zahl, die hier verboten ist: eine, die etwas Falsches behauptet, und
der man glaubt. Bei DIESEM Gegenstand -- dem Befinden eines Menschen --
waere das der schlechteste denkbare Ort dafuer.
DIE VORHANDENE PRUEFUNG HAT DEN FEHLER NICHT GEFUNDEN, SIE HAT IHN
FESTGESCHRIEBEN. Dort stand woertlich `ok(zweite.code === 201, "eine
zweite Runde geht auch sofort")` -- gruen, und ein Beleg fuer genau das
Gegenteil dessen, was sie pruefen sollte. Sie aenderte eine Antwort von
zwoelf und war zufrieden.
Ab jetzt zaehlt nur, was NACH der letzten Runde gesetzt wurde. Die alte
Antwort bleibt sichtbar -- sie ist nicht falsch, nur alt -- und traegt,
solange eine Runde faellig ist, den Hinweis "Das war deine Antwort beim
letzten Mal". Der Knopf zum Abschliessen ist weg, bis bestaetigt wurde.
2. FUENF FESTE FRAGEN, DREI WECHSELNDE.
Kern sind die, bei denen ein Ausfall teuer waere: die beiden
meistgenannten Gruende fuers Aufhoeren (zu wenig Zeit, Streit im Team),
die Erholung, die Sicherheit vor Anfeindung und der beste
Fruehindikator ("kann ich mir vorstellen, in ein paar Monaten noch
dabei zu sein"). Eine davon nur jede dritte Runde zu fragen hiesse, die
Antwort im Schnitt sechs Wochen spaeter zu bekommen.
Alle anderen rotieren, drei je Runde. Damit bleibt eine Runde bei acht
Fragen -- die Quellen sagen fuenf bis fuenfzehn, unter zwei Minuten --
und der Katalog kann WACHSEN, ohne dass eine Runde laenger wird. Das
ist der eigentliche Gewinn und die Aufloesung deines Widerspruchs.
Gerechnet, nicht gewuerfelt: aus der Zahl der bisherigen Runden. Zufall
hiesse, dass bei jedem Neuladen etwas anderes dasteht. Und weil sieben
Zusatzfragen und drei Plaetze nicht glatt aufgehen, wird der Versatz
erhoeht, falls er je einen gemeinsamen Teiler mit der Laenge haette --
sonst kaemen nur zwei feste Haelften dran, und der Rest nie.
3. WAS DARAUS FOLGTE, OHNE DASS ES IM PLAN STAND.
- `rhythmus()` zaehlte gegen ALLE Fragen. Mit der Rotation waere das nie
wieder erfuellt gewesen: Jede Runde haette sich selbst fuer
unvollstaendig erklaert und die Seite haette taeglich gefragt.
Jetzt gegen den Kern, der in jeder Runde enthalten ist.
- Die Auswertung sieht ALLE zwoelf Fragen, nicht die acht dieser Runde.
Der Verlauf hoert nicht auf, wenn eine Frage pausiert.
- Der Verlauf zeigt jede Frage MIT Geschichte (nach zwei Runden elf von
zwoelf), nicht die der aktuellen Runde. Leere Felder heissen jetzt
ausdruecklich "war nicht dran", nicht "keine Antwort".
- "seit 2 Runden" heisst jetzt "die letzten 2 Male". Mit der Rotation
war die alte Formulierung eine Behauptung ueber eine Runde, in der
gar nicht gefragt wurde.
4. ZWEI DINGE, DIE KEIN ZAHLENVERGLEICH GEFUNDEN HAT -- nur das
Ansehen des Bildschirmfotos, und beide waren wahr und trotzdem
irrefuehrend:
- Der Satz "diese Runde sind 8 von 12 dran" stand nur, solange etwas
offen oder faellig war. Im Ruhezustand -- dem, den man am haeufigsten
sieht -- fehlte er. Wer acht Fragen zaehlt, wo zwoelf im Katalog
stehen, haelt vier fuer verschwunden.
- "Das war deine Antwort beim letzten Mal" stand an JEDER Frage,
unmittelbar nachdem man sie beantwortet hatte.
Beide haben jetzt eine Pruefung, inklusive Gegenprobe ueber eine
zurueckdatierte Runde.
GEMESSEN: pruef-befinden 100/0 (vorher 75 -- die Zahl ist gestiegen,
nicht gefallen), pruef-entwicklung 43/0, pruef-push-ziel 10/0,
pruef-werdegang 95/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
19e9f471d3 |
Entwicklung: die Auswertung je Person -- und elf Seiten ohne Farbe
Filipe: "dan perfektionierst du eine neue wo diagramme texte und so zu
jedem modi gemacht wird und diese kategorie kannst du entwicklung nenen."
1. DAS EIGENTLICHE PROBLEM WAR, DASS ES KEINE VERGANGENHEIT GAB.
`entwicklung_stand` hat den Schluessel (person, punkt, beurteiler) und
wird bei jeder Aenderung UEBERSCHRIEBEN -- dort richtig, eine Beobachtung
ueber einen Menschen soll aktuell sein. Nur: Damit existierte nichts,
woraus sich ein Verlauf zeichnen liesse. Nachgemessen: 43 Zeilen Stand,
NULL Zeilen Geschichte. Ein Diagramm ueber einen einzigen Zeitpunkt ist
kein Diagramm, sondern ein Balken.
Neu: `entwicklung_lauf` haengt jede Aenderung an, statt zu ueberschreiben.
Sie steht in workspace-entwicklung.js, bei der Tabelle, zu der sie
gehoert -- die Auswertung liest nur. Andersherum gaebe es einen Ring
zwischen zwei Modulen, und Ringe halten in JavaScript genau so lange,
bis jemand eine Konstante auf oberster Ebene benutzt.
KEIN ANLASS, NIE. Neben jedem "da hakt es" steht ein Satz, woran man es
gemerkt hat -- fuer ein Gespraech aufgeschrieben. Eine Chronik dieser
Saetze waere das Belastendste, was dieses Haus speichern kann. Die Spur
hat gar keine Spalte dafuer, und die Pruefung liest die TABELLE, nicht
die Ausgabe: Eine Spalte, die es gibt, wird eines Tages gefuellt.
Die Startaufnahme uebernimmt den heutigen Stand mit seinen ECHTEN Daten,
damit die Seite am ersten Tag nicht leer ist -- und zaehlt ausdruecklich
NICHT als Bewegung. Der Tag, an dem die Spur entstand, war kein Tag, an
dem 43 Dinge gleichzeitig passiert sind.
2. WAS GEZEIGT WIRD: BEWEGUNG, KEINE NOTE.
Keine Punktzahl, kein Prozentwert, kein Durchschnitt, keine Rangliste,
kein Vergleich zwischen zwei Menschen. Das ist die Recherche, nicht
Vorsicht: Ueberrechtfertigung (Deci), sozialer Vergleich senkt die
Leistung derer, die schlechter dastehen, Schwaechenfokus ebenso.
Stattdessen das progress principle (Amabile/Kramer, ~12 000
Tagebucheintraege): Sichtbarer Fortschritt ist der staerkste einzelne
Treiber. Deshalb Diagramm 1 "Was sich bewegt hat" -- zwei Richtungen um
eine Nulllinie, ein Massstab fuer beide. Diagramm 2 der Streifen (Punkt
x Monat), fortgeschrieben, aber nach 90 Tagen sichtbar verblasst.
Und die Texte in dieser Reihenfolge: was sich bewegt hat, was traegt,
erst danach was liegt.
Selbst gezeichnet, kein Diagrammpaket: 60 kB ueber die Leitung von
jemandem, der mit dem Handy im Stream steht -- und es braechte eigene
Farben neben die Hausfarben. Jede Zelle traegt ihr Zeichen als Text,
jeder Balken seine Zahl, darunter eine Legende: Die Farbe ist nie die
Auskunft.
Zwei Gesichter: Die Leitung sieht die Karten, ein Modi ausschliesslich
die Bewegung in der eigenen -- ohne Namen, ohne Anlass, ohne Streifen.
3. NEBENBEFUND, GROESSER ALS ERWARTET: ELF SEITEN OHNE FARBE.
Der Umbau von heute frueh heisst "Jede Seite traegt die Farbe ihrer
Kachel". Nachgemessen traf das auf 18 von 34 Seiten zu. Elf Seiten mit
echter Kachel gingen leer aus -- ausgerechnet die von Team Dogi:
befinden, bewerben, bewerbungen, entwicklung, hilfe, rechte, talente,
teamlage, teilen, treff-moderation, treff-regeln, unsere-seiten.
Der Grund: `zuSeite()` sucht nur in `Bereiche.GRUPPEN`, und dort stehen
ausschliesslich die Kacheln der Agentur. Die von Team Dogi liefert der
Server (`ich.bereiche`, `ich.bereiche_zusatz`). Auffallen konnte das
nicht -- eine Seite ohne Farbe sieht aus wie eine, die eben keine hat.
kopf.js faerbt jetzt zweimal: sofort aus GRUPPEN (Agenturseiten ohne
Flackern wie bisher), und noch einmal aus den Serverkacheln, sobald
`werZeigen` sie bringt. Nur, wenn beim ersten Mal nichts gefunden wurde.
pruef-buehne misst den Kontrast an echten Bildpunkten und kannte diese
zwoelf Seiten nicht. Jetzt stehen sie in der Liste; ihre Frist waechst
mit der Laenge, statt als feste Zahl irgendwann zu reissen. Gemessen
fuer werdegang.html: 4,83:1 am Computer, 6,22:1 am Handy.
4. TON 38 SAH FREI AUS UND WAR ES NICHT.
Erster Anlauf war Ton 38, weil 37 die hoechste Nummer in workspace.js
ist. Gezaehlt in start.css sind es 39, alle vergeben. Genau davor warnt
das Farbwerkzeug im eigenen Kopf ("Ton 22, weil er frei AUSSAH").
Dabei aufgefallen: Die zwei Kacheln von heute Nacht wurden ohne das
Werkzeug gesetzt. Ton 39 lag 0,0362 von Ton 15 entfernt -- der engste
Abstand im ganzen Haus, zwei praktisch gleiche Cyan-Toene. Filipe dazu
mehrfach: "keine die sich irgendwie aehnlich sind".
Neues Werkzeug `tools/kachel-farbe-einzeln.mjs`: zieht EINE Farbe nach,
ohne die anderen anzufassen. Das grosse Werkzeug haette alle 40 neu
gefaerbt -- jede Kachel im Haus, ungefragt. Es bricht ab, wenn es nicht
alle Toene lesen kann: Der erste Anlauf las 31 von 40, weil einstellige
Nummern mit ZWEI Leerzeichen dastehen, und rechnete froehlich weiter.
Ergebnis: kleinster Abstand 0,0362 -> 0,0840, durch Aendern von zwei
Kacheln, die es erst seit gestern Nacht gibt.
5. anruf-probe.html lud `basis.css` und `kopf.css` -- beide gibt es
nicht. Ausgerechnet dort faellt es nicht auf, weil die Seite ihre eigene
Stilangabe im Kopf hat. pruef-struktur war deshalb rot (5 Befunde) und
ist jetzt gruen.
GEMESSEN: pruef-werdegang 95/0 (neu), pruef-entwicklung 43/0,
pruef-befinden 75/0, pruef-rechtetafel 19/0, pruef-zwischenspeicher 21/0,
pruef-start-ansicht 0 Fehler, pruef-struktur 0 Fehler (vorher 5),
pruef-buehne fuer werdegang.html 0 Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
0b73fbb501 |
Jede Seite traegt die Farbe ihrer Kachel -- und der alte Name ist weg
1. DIE FARBE DER KATEGORIE GILT JETZT AUF DER GANZEN SEITE. Filipe: "die kacheln sollen auch in jeder seite die farben der kategorie haben. ich will dass alles perfekt angepasst ist." Vorher war jede Bereichsseite gleich blau, egal aus welcher Kachel man kam -- beim Klick verlor man die einzige Farbe, an der man sich orientieren konnte. KEINE DRITTE LISTE: Der Ton steht bereits in den Kacheln, und der Browser hat beide Quellen vorliegen (`ich.bereiche` vom Server, `Bereiche.GRUPPEN` fuer die Agentur). `tonSetzen` sucht dort und setzt `data-ton` am <body>; die Zuordnung Nummer->Farbe gilt ueber start.css ohnehin schon. Gefunden wird ueber das ZIEL, nicht ueber den Namen -- der aendert sich (heute zweimal), das Ziel nicht. Der Akzent der Seite wird daraus gemischt, nicht rein uebernommen: Einige Toene sind sehr hell (Ton 30 fast Weissgruen, Ton 36 Zitronengelb) und wuerden als duenne Linie auf dunklem Grund blenden. 12 % ruhiges Blaugrau nehmen die Spitze, ohne die Kategorie unkenntlich zu machen. 2. DER UMBENANNTE NAME WAR NOCH AN VIER STELLEN. Die Kachel heisst seit heute "Eure Aufgaben" -- Titel und Kopfleiste der Seite sagten aber weiter "Entwicklung", und zwei Pruefungen suchten die Kachel ueber ihren alten Namen. Sie waeren beim naechsten Lauf rot geworden, ohne dass etwas kaputt ist. pruef-befinden sucht die Kachel jetzt ueber ihr ZIEL statt ueber den Namen: Das ist die Angabe, die sich nicht aendert, wenn jemand den Namen nachschaerft. GEMESSEN: pruef-entwicklung 43/0, pruef-befinden 75/0, pruef-community-sicht 10/0, pruef-wege-nach-draussen 64/0, pruef-bereiche-lesend gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b40089ff79 |
Testfoto aus dem Commit nehmen
server/_foto-logos.png war ein Bildschirmfoto zum Nachsehen, wie die schwebenden Logos aussehen -- kein Bestandteil der Anwendung. Es ist beim 'git add -A' mitgekommen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
f62ade3573 |
Vertraulicher Meldeweg, klappbare Abschnitte, lila Stunden, Logos
Eine Nacht voller Auftraege von Filipe. Der Reihe nach: 1. VERTRAULICH MELDEN -- der groesste neue Teil. "es soll auch eine kategorie also eine hauptkachel geben wo die community leute sich anonym melden koennen wenn sie probleme haben ... rechte hand und dogfather sollen zugriff auf diese anonyme nachrichten haben. also anonym fuer die anderen." WICHTIG, UND ES STEHT SO AUF DER SEITE: "anonym" heisst hier VERTRAULICH. DogFather und die rechte Hand sehen den Namen -- so bestellt und auch richtig, ohne Namen kann man niemandem helfen. Anonym ist es gegenueber allen anderen: kein Modi, kein anderes Mitglied. Wer glaubt, er schreibe unerkannt, schreibt anders und fuehlt sich hinterher getaeuscht -- deshalb steht der Satz im Formular, bevor jemand tippt. Der strikte Wechsel (melden -> warten -> antworten -> warten) ist im SERVER erzwungen, nicht nur im Knopf. Ein ausgegrauter Knopf ist keine Regel. Geschlossen wird nur von der Leitung; abgeschlossene Faelle werden nach 90 Tagen samt Nachrichten geloescht -- hier stehen die empfindlichsten Texte des Hauses. Modis sind ausdruecklich AUSSEN VOR: Sehr oft geht es in diesen Meldungen um eine Moderationsentscheidung. 2. JEDE KATEGORIE LAESST SICH ZUKLAPPEN. "man soll auf dieser seite jede kategorie auf und zu klappen koennen mit einem button ... ueberall wo so eine liste entstehen kann." Das Muster gab es auf der Startseite schon; es steht jetzt als `abschnittKlappbar` in kopf.js und wird von den Brettern und dem Zeitstrahl benutzt. Die Koepfe sind echte <button> (fuer die Tastatur), der Zustand haelt in localStorage, und er haengt je Brett UND Art -- sonst waere "Regel zugeklappt" ueberall gleichzeitig zu. 3. DIE SPRUNGLEISTE SIEHT AUS WIE ETWAS ZUM ANFASSEN. Vorher unterstrichene Woerter, die aussahen wie eine Fusszeile. Jetzt Marken mit Rahmen in einem eigenen Block. 4. DIE STUNDEN SIND LILA. UMGERECHNET, NICHT NEU GEWAEHLT: Jeder der fuenf Verlaufsstopps wurde nach OKLCH zerlegt, der Farbton auf 303 Grad gedreht, zurueckgerechnet. Helligkeit und Buntheit blieben gleich -- eine frei gegriffene Palette waere heller oder bunter geworden, und die Uhr damit unruhiger. 5. DIE KARTEN "UNSERE SEITEN": babyblau und lila, mit schwebenden Logos. Beide Logos wurden zu MASKEN gerechnet (tools/logo-maske.mjs): Die PNG tragen nur Alpha, die Farbe kommt aus dem CSS. Dadurch passt dasselbe Logo in jede Kachel, egal welchen Ton sie hat -- und VanVans 378-KB- Logo wurde dabei zu 109 KB. Vier Stueck je Karte, verschieden gross, zwei Bahnen, 26 bis 41 Sekunden Umlauf. Der erste Versuch war mit 5-9 % Deckkraft praktisch unsichtbar; jetzt 10-16 %. 6. "ENTWICKLUNG" HEISST JETZT "EURE AUFGABEN". Filipe hat recht: Die Kachel fuehrt seit dem 11.09. auf den Katalog -- eine Aufgabenliste. Der Name blieb stehen, weil beim Umhaengen des Ziels niemand ihn angefasst hat. Der Name "Entwicklung" ist damit frei fuer das, was er darunter versteht (Auswertung je Person mit Verlauf und Text) -- das ist noch NICHT gebaut. DREI PRUEFUNGEN, DIE ZUFAELLIG GRUEN WAREN, sind nebenbei aufgefallen: - pruef-kachelraster wartete feste 500 ms auf eine gestaffelte Einblendung und mass vier Reihen, wo drei sind. Jetzt reducedMotion. - pruef-start-ansicht scrollte 600 px und nahm an, danach liege keine Kachel mehr unter dem Zeiger. - pruef-wege-nach-draussen zaehlte das Kachelraster ueber ALLE Gruppen statt je Gruppe. GEMESSEN: pruef-hilfe (neu) 55/0, pruef-wege-nach-draussen 64/0, pruef-jeder-hat-eine-seite 65/0, pruef-community-sicht 10/0, pruef-bereiche-lesend, pruef-steckbrief, pruef-start-ansicht, pruef-kachelraster alle gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
63f2b2bc55 |
Jeder hat einen Steckbrief -- und die Kacheln stehen in der richtigen Reihenfolge
Filipe: "jeder soll ein steckbrief haben, jeder der ein account hat, rechte hand, modis und community, jeder soll genau wie ich foto und so hinzufuegen koennen." Und: "ich will das oben die sachen fuer dogfather sind, dan die sachen fuer modis und dan community bereich." 1. JEDER HAT EINEN STECKBRIEF. In rechte.js fehlte "gast" -- und damit ausgerechnet die groesste Gruppe. Die Seite selbst konnte es die ganze Zeit: `/mein` fragt nach der eigenen Nummer und kennt gar keine Rolle. Es fehlte nur die Tuer und die Kachel. DABEI EIN ZWEITER FUND, der schon laenger da war: In assets/js/steckbrief.js stand eine Liste aus drei Gruppen (Management, Scouting, Creator). Wer in keine passte, verschwand LAUTLOS aus der Uebersicht -- betroffen waren die rechte Hand und die Modis. Ein Modi, der die Seite oeffnete, sah seine eigenen Leute nicht. Kein Fehler, keine leere Liste, sie waren einfach nicht da. Die Zuordnung kommt jetzt vom Server (`abschnittFuer`). Damit kann sie nicht mehr veralten, und in der ausgelieferten Datei steht keine Liste von Rollennamen mehr -- was ohnehin Hausregel ist. Wer kuenftig vergessen wird, landet sichtbar unter "Weitere" statt zu verschwinden; die Gegenprobe dafuer steht in der Pruefung. "Wer hier mitarbeitet" heisst jetzt "Wer hier dabei ist" -- ein Mitglied arbeitet nicht mit, es schaut zu. 2. DIE REIHENFOLGE. Die Moderationskachel trug dieselbe Gruppe wie die sieben Bretter und landete deshalb HINTER ihnen: Wer moderiert, musste an der ganzen Community vorbeiscrollen. Sie hat jetzt eine eigene Gruppe und steht davor. ERST ZU VIEL GEMACHT, DANN KORRIGIERT: Mein erster Entwurf schrieb auch die Reihenfolge der Arbeitsgruppen fest. Die ist an mehreren Stellen bewusst gewaehlt und begruendet -- pruef-start-ansicht hat es sofort gemeldet, zu Recht. Jetzt wandern nur noch Moderation, Community und "Fuer dich" ans Ende; alles andere bleibt, wo es war. 3. ZWEI PRUEFUNGEN, DIE ZUFAELLIG GRUEN WAREN. pruef-kachelraster zaehlte Reihen ueber die Y-Koordinate und wartete feste 500 ms. Die Kacheln laufen aber gestaffelt ein -- mit einer Gruppe mehr war die Messung zu frueh und meldete vier Reihen, wo drei sind. Das Bildschirmfoto derselben Seite zeigte ein makelloses Raster. Jetzt misst sie mit `reducedMotion: reduce`, also den Endzustand. pruef-start-ansicht scrollte 600 px und nahm an, danach liege keine Kachel mehr unter dem Zeiger. Dieselbe Falle wie eine feste Umbruchschwelle: eine Rechnung von gestern. Sie fragt jetzt, was gemeint ist -- leuchtet die ALTE Kachel noch? GEMESSEN: pruef-jeder-hat-eine-seite (neu) 65 Pruefungen 0 Fehler, pruef-steckbrief, pruef-start-ansicht, pruef-kachelraster, pruef-community-sicht alle gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
f30227c873 |
Unsere Seiten, klickbare Video-Karten -- und coturn, das nie vermittelt hat
Drei Sachen von Filipe, und eine davon war ein Fehler von mir.
1. DER VERMITTLUNGSSERVER HAT NIE EINEN ANRUF GETRAGEN.
Am 18.09. habe ich gemeldet, coturn laufe und sei "von aussen
nachgewiesen". Das war falsch. Im Protokoll: null Zuteilungen, jemals.
Beim ersten echten Versuch "check_stun_auth: Cannot find credentials"
-- in /etc/turnserver.conf fehlte `static-auth-secret`, also suchte
coturn die Zugangsdaten in seiner eigenen Datenbank und wies jeden ab.
Und mein eigenes Werkzeug meldete die ganze Zeit gruen:
"Eingetragen, Geheimnis lesbar, Server antwortet." Jedes Wort wahr --
und keins beantwortete die Frage, um die es geht. Eine STUN-Bindung
fragt "bist du da?", eine Zuteilung fragt "traegst du meinen Anruf?".
`tools/turn-sprache.mjs` (neu) versucht jetzt eine ECHTE Zuteilung und
schickt ein Paket darueber. `turn-einrichten.mjs` benutzt sie und hat
drei Ausgaenge statt zwei: traegt / traegt nicht / konnte nicht
nachsehen. Nach Filipes Reparatur auf dem Server gemessen: Zuteilung
auf Port 49199, Paket angekommen -- von Luxemburg durch Deutschland.
2. UNSERE SEITEN -- die erste Kachel, die HINAUSFUEHRT.
Website und VanVans Shop, mit dem Rabattcode DOGI10. Der Code wurde
nachgesehen, nicht abgeschrieben: partnercodes.json, 10 Prozent,
aktiv, "zum weitergeben an Community" -- und giltAufSale: false,
weshalb der Satz zu reduzierten Artikeln danebensteht. Der zweite Code
dort ist als "nur fuer Filipe persoenlich" vermerkt und steht nirgends.
Auch Name und Beschreibung des Shops stammen von der Seite selbst.
Meine erste Fassung hiess "Van's DIY Bastelbedarf" und nannte "Perlen,
Anhaenger, Werkzeug" -- ausgedacht und falsch. Er heisst mit "&" und
verkauft Haekelwerke, Plushies, Schmuck.
Der Ton der Kachel wurde GESUCHT, nicht gewaehlt: sieben geratene
Blautoene schafften den noetigen Abstand nicht, also 372 600
Kombinationen abgesucht. #087ce7, Abstand 0.310, Kontrast 4.51:1.
3. DIE GANZE VIDEO-KARTE KLICKT -- "egal wo man drauf drückt".
Und hier steckte der lehrreiche Fehler: Zuerst stand der Klick-Block
unten vor `return k`. Diese Funktion hat DREI Rueckgabepunkte, und der
erste lautet `if (!darfEintragen()) { ...; return k; }` -- also genau
fuer die Mitglieder, fuer die Filipe es wollte. Beim Team ging es, bei
der Community nicht. Jetzt haengt er dort, wo `videoWeg` entsteht.
Nicht klickbar bleiben Karten ohne Video und solche, deren Video bei
TikTok geloescht wurde -- sonst fuehrt der Klick auf eine Fehlerseite,
und wir sehen kaputt aus.
GEMESSEN: pruef-wege-nach-draussen (neu) 63 Pruefungen, 0 Fehler, auf
1400 und 412 px. Mit Gegenproben: der Kopierknopf oeffnet nichts, der
eigene Knopf wirkt genau einmal, auf einer Karte ohne Video passiert
nichts. pruef-community-sicht 10/0 auf jetzt 11 Seiten, 0 tote Wege.
Nebenbei: Der Pfeil klebte bei langen Untertiteln am Text (auf dem
Bildschirmfoto gesehen). 0.45rem Abstand.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d766be57b6 |
Anruf: wer auflegt, hinterlaesst jetzt auch eine Spur
Filipe, 00:30 Uhr: „hab angerufen aufgelegt und da steht immer noch nichts im chat vom anruf...." Im Protokoll: vier Anrufe, je drei bis zehn Sekunden, kein einziger Eintrag im Gespraech. Und mein Denkfehler dahinter war einfach: „Verpasster Anruf" stand NUR in `aufraeumen()` -- also erst, wenn ein Anruf nach zwei Minuten von selbst verfaellt. Wer vorher auflegt, loeschte ihn spurlos. Abschnitt 5e hat damit genau den Weg geprueft, den niemand geht: warten, bis es von allein aufhoert. Im Alltag legt man auf. Fuer die andere Seite ist ein Anrufer, der aufgibt, ERST RECHT ein verpasster Anruf. UND EINE ZWEITE FALLE, die die erste verdeckt hat: `verpasstVermerken` nahm den Anrufer aus der Runde der Anwesenden (`a.wer`). Beim Verfallen steht er noch darin -- beim AUFLEGEN ist sie leer. Die Zeile waere also auch dann ausgefallen, wenn der Aufruf an der richtigen Stelle gestanden haette. Jetzt kommt er aus `a.anrufer`, wie beim gefuehrten Anruf auch. Zwei Fehler, die einander gedeckt haben, und beide hat dieselbe Pruefluecke durchgelassen: Ich hatte den Ablauf geprueft, den ich gebaut hatte, nicht den, den ein Mensch geht. Geprueft: pruef-anruf 106 -> 111. Der neue Abschnitt ruft an, wartet kurz, legt auf -- und misst, dass genau EINE Zeile entsteht, dass sie „verpasst" sagt, dass der Anrufer daran steht und dass spaeteres Aufraeumen keine zweite schreibt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ff09a67578 |
Anruf-Probe: erreichbar auch in der App
Filipe: „geht es nicht auf der app?"
Nein -- und das war mein Fehler. Ich hatte eine Seite gebaut, die
sagt, WARUM es nicht klingelt, und sie war nur ueber die Adresszeile
erreichbar. In der installierten App gibt es keine. Eine Hilfe, die
man nicht aufrufen kann, ist keine.
Zwei Wege dorthin, beide genau da, wo man hinschaut, wenn etwas nicht
stimmt:
* Ein „?" neben den Anrufknoepfen im Chat -- dauerhaft da, auch
ohne laufenden Anruf. Wichtig fuer die andere Seite: Wer angerufen
wird und nichts hoert, sieht gar keinen Anrufkasten.
* Und „Klingelt nichts?" im Anrufkasten selbst, fuer den, der gerade
vergeblich anruft.
Beide klein und ohne Farbe: Wer telefoniert, soll sie uebersehen; wer
ratlos dasitzt, findet sie.
pruef-anruf weiterhin 106, 0 Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
4fdf08d003 |
Anruf-Probe: eine Seite, die sagt, WARUM es nicht klingelt
Filipe: „funktioniert nichts davon was machst du?"
Zu Recht. Ich habe an einem Abend fuenf Dinge repariert, jedes einzeln
nachgewiesen -- und bei ihm klingelte trotzdem nichts. Der Grund ist
jedes Mal derselbe gewesen: Ich kann von hier aus messen, was der
SERVER tut, aber nicht, was in SEINEM Browser ankommt. Und genau dort
lag es.
Gemessen habe ich gerade wieder: Der Server liefert die richtige Datei
aus (32616 Bytes, Klingelton enthalten), sobald sie mit Stempel
angefordert wird. Ohne Stempel kommt eine sieben Stunden alte Fassung
aus dem Zwischenspeicher. WELCHE von beiden sein Browser anfordert,
sehe ich nicht -- und das ist die Frage, an der alles haengt.
/workspace/anruf-probe.html dreht das um. Sie laeuft in SEINEM Browser
und beantwortet der Reihe nach:
1. Ist die neue Fassung ueberhaupt geladen? Sie holt anruf.js und
sieht nach, ob Klingelton und Nachklingeln darin stehen. Fehlen
sie, kommt die Seite aus dem Zwischenspeicher -- und JEDE
Reparatur ist unsichtbar, egal wie oft man neu laedt.
2. Darf der Browser Ton abspielen? (Er erlaubt ihn erst nach der
ersten Beruehrung -- wer ueber eine Benachrichtigung hereinkommt,
hoert sonst nichts und haelt das Telefon fuer kaputt.)
3. Sind Benachrichtigungen erlaubt UND ist ein Geraet beim Server
angemeldet? Das sind zwei verschiedene Dinge, und die Luecke
dazwischen sieht man sonst nirgends.
4. Steht die Verbindung, ueber die das Klingeln kommt?
Dazu ein Knopf, der genau den Klingelton abspielt, den ein Anruf
macht. Wer ihn hoert, weiss, dass es an der Seite nicht liegt.
Am Ende steht EIN Satz: das Wichtigste zuerst, mit dem, was zu tun
ist. Keine Liste zum Selbstdeuten.
Sie ruft niemanden an und zeigt nichts ueber andere.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
00459f47c6 |
Anruf: "Anruf · 3:42" steht jetzt im Chat, nicht nur der verpasste
Filipe: „im chat soll auch stehen verpasster anruf oder anruf gehabt
und wie lange."
Die zweite Haelfte. Ein verpasster Anruf steht seit heute drin -- ein
GEFUEHRTER stand nirgends. Nach dem Auflegen war das Gespraech spurlos
weg.
Tage spaeter ist die Frage aber nicht „hat er angerufen", sondern
„haben wir das besprochen oder nur kurz telefoniert?". Drei Minuten
sind ein Gespraech, zwoelf Sekunden sind ein Verwaehlen. Eine Zeile
ohne Zahl beantwortet das nicht.
GEZAEHLT AB DEM RANGEHEN, nicht ab dem Klingeln. Sonst staende bei
jedem Anruf eine halbe Minute zu viel darin -- die Zeit, in der das
Telefon nur laeutete. Dafuer merkt sich der laufende Anruf jetzt zwei
Dinge zusaetzlich:
* `gespraechSeit` -- gesetzt, wenn der Zweite dazukommt.
* `anrufer` -- wer begonnen hat. `wer` ist die Runde der
gerade Anwesenden; sie leert sich, und am Ende
laesst sich daraus nicht mehr ablesen, von wem
der Anruf ausging. Die Zeile steht bei ihm, wie
bei jedem Telefon.
Unter einer Minute steht die Sekundenzahl („7 Sekunden"), darueber
Minuten („3:42 Minuten") -- „0:07" liest sich umstaendlicher, als es
ist.
Geprueft: pruef-anruf 101 -> 106. Der neue Abschnitt fuehrt einen
echten Anruf: anrufen, rangehen, kurz warten, beide auflegen -- und
misst dann, dass genau EINE Zeile entsteht, dass sie „Anruf" sagt und
nicht „verpasst", und dass die Dauer in SEKUNDEN steht. Stuende dort
die Zeit seit dem Klingeln, waeren es Minuten.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
c87c396ef5 |
Anruf: es klingelt jetzt wirklich -- vorher gab es gar keinen Ton
Filipe: „ist das normal dass es nicht mal klingelt wenn man anruft?"
Nein. Und der Grund war so einfach wie peinlich: Es gab ueberhaupt
keinen Ton. Weder beim Anrufer noch beim Angerufenen. Der Anruf zeigte
einen Kasten auf dem Bildschirm, sonst nichts -- wer nicht zufaellig
hinsah, merkte nichts, und wer anrief, wusste nie, ob ueberhaupt etwas
passiert.
Damit erklaert sich auch, warum heute Abend alles „kaputt" wirkte,
obwohl Verbindung, Raum, Anmeldung und Code stimmten: Ein stummes
Telefon ist von einem defekten nicht zu unterscheiden.
ZWEI TOENE, JE NACH SEITE:
Angerufener zwei weiche Toene (880/660 Hz), dann Pause -- alle
2,4 Sekunden, dazu Vibration, wo das Geraet sie kann.
Anrufer ein leiseres, langsameres Freizeichen (440 Hz). Ein
stiller Kasten mit laufender Uhr sagt nur, DASS etwas
passiert; ein Freizeichen sagt, was.
OHNE TONDATEI. Ein .mp3 waere eine Datei mehr im Netz, eine
Lizenzfrage und ein Ladefehler, der genau dann auffaellt, wenn man ihn
braucht. Zwei Sinustoene aus dem Browser reichen. Sanft ein- und
ausgeblendet, weil ein hart geschalteter Sinus knackt -- und das
Knacken ist das Unangenehme daran.
Der Ton hoert auf, sobald jemand rangeht (`dabei`), sobald die
Verbindung steht und beim Auflegen. Drei Stellen, weil ein
Freizeichen, das waehrend des Gespraechs weiterlaeuft, das ist, was
man an Telefonanlagen hasst.
EHRLICH DAZU: Browser lassen Ton erst zu, wenn jemand auf der Seite
etwas angeklickt hat. Wer die Seite gerade erst geoeffnet hat, hoert
unter Umstaenden nichts -- dann bleibt die Benachrichtigung des
Geraets der Weg. Das ist eine Regel des Browsers, keine Entscheidung
von uns.
Geprueft: pruef-anruf 100 -> 101. Gemessen wird am Oszillator, nicht
am Lautsprecher: Ob wirklich etwas zu hoeren ist, haengt an Geraet und
Lautstaerke -- dass die Seite Toene ERZEUGT, laesst sich messen.
Gegenprobe (Freizeichen ausgebaut): „0 Toene erzeugt", rot.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
0137ced9c2 |
Anruf: die Ruhezeit hat ihn verschluckt
Filipe um 23:44 Uhr: „sie bekommt nur eine benarichtigung das eine
neue nachricht ist aber sonst nichts irgendwas laeuft da gewaltig
schief."
Serverseitig war ALLES in Ordnung, und das war das Verwirrende: Der
Anruf kam an, der Raum stimmte (Dogfather + VanVan), sie war
angemeldet, sie hatte ein Geraet, der neue Code lief. Trotzdem klang
nichts.
Die Ursache war eine einzige Zeile in workspace-push.js, die ich beim
Bauen des Anrufs nie gesehen hatte:
if (art !== "test" && istRuhezeit()) return { grund: "ruhezeit" };
RUHE_AB = 22. Es war 23:44. Die Benachrichtigung wurde gar nicht erst
verschickt -- ihr Geraet konnte nicht klingeln, weil es nichts zu
klingeln gab.
Fuer eine Aufgabenerinnerung ist die Regel genau richtig: Die schickt
der Server von sich aus, weil eine Frist naeher rueckt. Ein Anruf ist
das Gegenteil -- ein Mensch drueckt gerade auf den Hoerer und wartet.
Ein Telefon, das nachts stumm bleibt, ist kein Telefon.
ANRUFE SIND JETZT EINE EIGENE ART. Zwei Dinge auf einmal:
* Sie umgehen die Ruhezeit.
* Und sie lassen sich getrennt abschalten. Vorher gingen sie als
„chat_nachricht" hinaus -- wer die Benachrichtigungen fuer den
Chat abstellt, haette damit auch Anrufe abgestellt, ohne es zu
wissen. Das sind zwei verschiedene Entscheidungen.
Wer nachts seine Ruhe will, schaltet „Jemand ruft an" ab. Eine
Entscheidung, die man selbst trifft, statt einer Regel, die man nicht
kennt.
Geprueft: server/pruef-anruf-ruhezeit.mjs, 6 Pruefungen. Sie stellt
die Ruhezeit auf „rund um die Uhr", damit sie nicht tagsueber gruen
und nachts rot ist, und unterscheidet am RUECKGABEGRUND: "ruhezeit"
heisst haengengeblieben, "keine_geraete" heisst durchgekommen. Dazu
die Gegenprobe, dass eine erfundene Art durchfaellt -- sonst waere
„nicht ruhezeit" auch fuer etwas wahr, das nie verschickt wird.
pruef-anruf weiterhin 100, 0 Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
31906e9216 |
Pruefung berichtigt: die kurze Klingeldauer galt fuer den ganzen Lauf
Der Commit davor ging mit EINEM roten Test hinaus -- ich habe das Ergebnis nicht angesehen, weil Pruefung und Commit in derselben Kette liefen. Das war der Fehler, nicht der rote Test selbst. Die Ursache war die Pruefung, nicht der Code: ANRUF_KLINGELT_SEKUNDEN stand auf 2, und das gilt fuer den GANZEN Lauf. Im Browser-Teil vergehen zwischen "anrufen" und "der Server kennt den Anruf" mehrere Sekunden -- dort war er damit schon verfallen. Jetzt zehn Sekunden: lang genug fuer den Browser, kurz genug, dass Abschnitt 5e nicht zur Geduldsprobe wird. 100 Pruefungen, 0 Fehler. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
e43fe97550 |
Anruf: zwei Minuten Zeit -- und ein verpasster Anruf bleibt sichtbar
Filipe: „das mit dem anruf klappt nicht … es geeeeeht einfach nicht." NACHGEMESSEN WAR SERVERSEITIG ALLES IN ORDNUNG: Der Anruf kam an (Protokoll), der Raum stimmte (Dogfather + VanVan), sie war angemeldet (Sitzung bis morgen frueh), sie hat ein Geraet fuer Benachrichtigungen, und der neue Code lief. Trotzdem ging es nicht -- und zwar aus zwei Gruenden, die beide nichts mit Technik zu tun haben, sondern mit Zeit und Sichtbarkeit. 1. 45 SEKUNDEN SIND KEIN KLINGELN. Bei einem Telefon hebt man ab. Hier muss in dieselben Sekunden: Benachrichtigung zustellen, bemerken, Handy entsperren, antippen, App laden, Anmeldung pruefen. Das reicht, wenn man das Geraet in der Hand haelt -- und sonst nie. Jetzt zwei Minuten: lang genug, um aus der Tasche zu kommen, kurz genug, dass niemand vor einem Anruf sitzt, den es nicht mehr gibt. 2. UND DANACH WAR ES, ALS WAERE NIE ETWAS GEWESEN. Ein verpasster Anruf verschwand lautlos: keine Zeile, kein Hinweis, nicht einmal, DASS jemand angerufen hat. Genau das fuehlt sich an wie „geht nicht", auch wenn alles funktioniert hat. Jedes Telefon der Welt zeigt einen verpassten Anruf; jetzt steht er als Zeile im Gespraech, beim Anrufer, mit Uhrzeit. Geprueft: pruef-anruf 95 -> 100. Der neue Abschnitt misst den echten Ablauf (anrufen, niemand geht ran, Zeile erscheint) und dass sie NUR EINMAL erscheint -- `aufraeumen()` laeuft bei jeder Anfrage mit. Dafuer ist die Klingeldauer ueber die Umgebung einstellbar: Eine Pruefung, die zwei Minuten wartet, wird abgeschaltet, und dann waere der verpasste Anruf wieder ungeprueft. Im Betrieb steht die Variable nirgends. Und noch ein eigener Messfehler: Die Pruefung las zuerst /api/chat/raum/:id -- die Route heisst /api/chat/raeume/:id/nachrichten. Sie meldete „0 Nachrichten, vorher wie nachher" und sah damit aus wie ein Befund ueber den Code. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4ea7b37333 |
Anruf: "sie kriegt nur eine Benachrichtigung aber keinen Anruf"
Filipe, gerade gemeldet. Es waren ZWEI Fehler, und beide erklaeren
genau das, was er gesehen hat.
--- 1. Die Benachrichtigung sagte nicht, dass es ein Anruf ist ------
Gemessen kam bei ihr an:
Nachricht von [object Object]
(kein Text)
`nachricht.von` ist beim Klingeln ein OBJEKT (`{id, name}`) und keine
Zeichenkette; einen `text` gibt es bei einem Anruf gar nicht. Moeglich
wurde beides, weil die ART des Ereignisses die Benachrichtigung nie
erreichte: `chatEreignis` nimmt sie als vierten Parameter entgegen,
reichte sie aber nur in den Ereignisstrom weiter. Fuer den Push galt
jedes Ereignis als Chatnachricht -- auch das Klingeln.
Jetzt steht dort "Filipe ruft an" / "Tippen zum Rangehen", und beim
Tippen landet man im richtigen Gespraech.
--- 2. Und dort klingelte es dann trotzdem nicht --------------------
Das Klingeln lief ausschliesslich ueber den offenen Ereignisstrom. Wer
zusieht, hoert es. Wer die Seite NICHT offen hat, bekommt die
Benachrichtigung, tippt darauf, die Seite laedt -- und bleibt still.
Das Ereignis war vorbei, bevor sie da war.
Der Anruf funktionierte damit ausgerechnet fuer die nicht, fuer die
die Benachrichtigung ueberhaupt gebaut wurde.
Neu: `GET /workspace/api/anruf/offen` -- beim Laden fragt die Seite
einmal nach, ob in einem ihrer Raeume jemand wartet. Nur was noch
klingelt (45 s), nur Raeume, in denen die Person drin ist, und nicht
beim Anrufer selbst.
--- Gepruefte Wege -------------------------------------------------
pruef-anruf 80 -> 95. Zwei neue Abschnitte, beide mit Gegenprobe:
Route stillgelegt -> 3 rot; der Text ist jetzt einzeln pruefbar
(`pushTextFuer`), weil er vorher tief in einer Funktion entstand, die
nur der Push-Weg aufruft -- von aussen nicht messbar.
Nebenbei gefunden: `istDrinFuerAnruf` braucht die PERSON, nicht ihre
Nummer, und sagt das mit einem eigenen TypeError. Meine erste Fassung
uebergab die Nummer.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2b74e40007 |
Startseite: der Ring zaehlte Aufgaben -- ein Zuschauer hat keine
Nach dem Aufgabenblock und der dritten Zahl war noch ein Rest da, und
zwar der auffaelligste: In der Mitte der Seite stand gross
100 %
HEUTE NICHTS OFFEN
Der Ring zaehlt AUFGABEN -- was heute faellig war und was davon fertig
ist. Ein Mitglied hat keine, also stand dort dauerhaft 100 %. Dieselbe
tote Zahl wie "0 betreut" daneben, nur groesser.
Was ein Mitglied an dieser Stelle wissen will, ist etwas anderes:
Laeuft heute noch etwas? Der Ring zaehlt bei ihm jetzt die TERMINE des
Tages und faerbt, was davon vorbei ist. Bei null Terminen sagt er das
in Worten ("Heute steht nichts an") statt eine Null als Prozentzahl
auszugeben -- jede Prozentangabe waere da eine Behauptung ueber
nichts.
Dafuer kann der Server jetzt `mitte` schicken: einen Text fuer die
Ringmitte. Fehlt das Feld, bleibt alles wie bisher -- fuer alle
anderen aendert sich nichts.
UND DER FUSSTEXT ERKLAERTE EINEN KASTEN, DEN ES NICHT GAB. Unten stand
"„Was ist dran" fuehrt keine eigene Liste, sondern zeigt ..." -- der
Kasten selbst erscheint aber nur, wenn er etwas zu zeigen hat, und bei
einem Mitglied nie. Eine Erklaerung fuer etwas, das nicht da ist, ist
schlimmer als keine: Man sucht danach. Sie verschwindet jetzt mit ihm.
Gemessen (Handy): Startseite 1781 -> 1634 px.
pruef-community-sicht 10, pruef-zentrale-ring 14, pruef-vorlagen 24 --
alle ohne Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
fa34017809 |
Community-Pruefung: auch auf dem Handy, und ohne feste Schwelle
Die Community ist ueberwiegend mit dem Telefon unterwegs -- eine Messung auf 1400 px beantwortet fuer sie die falsche Frage. Und genau auf dem Handy waren heute die haesslichsten Sachen: drei verschiedene Kartenanordnungen, ein Hinweis quer ueber der naechsten Beschriftung. Dabei fiel gleich eine feste Zahl auf: Die Pruefung verlangte mindestens 20 sichtbare Wege. Auf dem Rechner sind es 27, auf dem Handy 18 -- dort klappt die Kopfleiste um. Die Pruefung wurde also auf der zweiten Breite rot, ohne dass etwas falsch war. Sie auf 15 zu senken waere derselbe Fehler mit einer anderen Zahl. Verlangt wird jetzt, was die Sache selbst hergibt: mindestens ein sichtbarer Weg je Seite. Findet sich weniger, hat etwas nicht geladen -- und dann ist "0 tote Wege" kein Ergebnis, sondern ein Messfehler. 10 Pruefungen, 0 Fehler, auf beiden Breiten. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ed8c83af09 |
Community: zwei Namen fuer zwei Sachen -- und ein praeziserer Satz
DIE LETZTEN BEIDEN SEITEN ANGESEHEN, die einem Mitglied offenstehen.
Sie standen bisher nur in der Messung ("keine toten Wege, keine fremde
Sprache") -- angesehen hatte ich sie nie.
1. ZWEIMAL "REGELN & HILFE". Die Seite mit den fuenf Regeln hiess
genauso wie das BRETT, auf das sie verweist. Auf dem Brett stand
damit ein Link "Regeln & Hilfe", der auf eine Seite namens "Regeln
& Hilfe" fuehrte -- wer ihn drueckte, glaubte im Kreis gelaufen zu
sein. Und dieser Link steht auf JEDEM Brett des Treffs.
Es sind zwei verschiedene Dinge: Hier die fuenf Regeln, kurz und
fest. Dort ein Brett, das daneben haeufige Fragen, Hilfe und die
Folgen sammelt. Die Seite heisst jetzt "Die Regeln".
2. "GESPEICHERT WIRD ERST, WENN DU ABSCHICKST" -- daneben stand "du
kannst zwischendurch aufhoeren und spaeter weitermachen". Beides
zusammen kann nicht stimmen, und nachgemessen stimmt der zweite
Satz: bewerben.js legt einen Entwurf im Browser ab (localStorage).
Der alte Satz war also nicht falsch, aber missverstaendlich -- er
meinte "an uns uebermittelt wird erst beim Abschicken" und klang
nach "nichts wird gespeichert". Bei einem Formular mit sechzehn
Feldern ist das der Unterschied zwischen "ich mache spaeter weiter"
und "ich fange lieber gar nicht erst an". Und es ist eine
Datenschutzauskunft: Wer an einem fremden Geraet sitzt, sollte
wissen, dass die Antworten dort liegen bleiben.
Die Bewerbungsseite selbst ist im Uebrigen vorbildlich: jedes Feld mit
"noetig"/"freiwillig" markiert, Hilfetexte, die ehrlich sind ("Ehrlich
ist besser als beeindruckend"), und am Ende steht, wer es liest.
pruef-community-sicht: 7 Pruefungen, 0 Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
542070e864 |
Community: der Chat-Knopf fuehrte auf JEDER Seite ins Leere
ERST DIE METHODE, DANN DER FUND. An einem Tag habe ich in der Community elf Dinge gefunden, die dort nicht hingehoerten -- jedes einzelne, weil ich zufaellig hingesehen habe. Das ist keine Methode. Der Workspace ist fuer die Agentur gebaut worden, und die Community hat ihn geerbt; solche Reste findet man nicht durch Nachdenken, sondern indem man ALLE Seiten durchgeht, die ein Mitglied erreichen kann. server/pruef-community-sicht.mjs tut genau das. Sie leitet aus rechte.js ab, welche Seiten offenstehen (4) und welche nicht (27) -- von Hand aufgezaehlt waere das eine Liste, die bei der naechsten Seite niemand nachzieht --, oeffnet jede davon als Mitglied und fragt zweierlei: Fuehrt ein sichtbarer Weg auf eine verbotene Seite? Steht dort die Sprache eines Arbeitsplatzes? BEIM ERSTEN LAUF: 27 sichtbare Wege, davon ZEHN ins Leere -- und alle zehn derselbe Knopf. Der Chat steht oben rechts in der Kopfleiste, auf jeder einzelnen Seite, mit Zaehler. `chat.html` steht einem Mitglied aber nicht offen: Der Klick landet wieder auf der Startseite. Keine Meldung, kein Grund, nichts passiert -- an der Stelle, die man am ehesten drueckt. Der Knopf haengt jetzt an `darf_chat` aus /api/ich, und das kommt aus derselben Rechtetabelle wie die Schranke dahinter. Die Oberflaeche vergleicht keine Rollennamen -- das waere eine zweite Wahrheit, die bei der naechsten Rechteaenderung auseinanderlaeuft. Dieselbe Ueberlegung steht zwei Zeilen weiter oben schon einmal. UND DIE PRUEFUNG HAT GLEICH MEINEN EIGENEN FEHLER GEFUNDEN: Die erste Fassung stand in `aufbauChat`, wo es die Person gar nicht gibt -- ReferenceError auf allen zehn Seiten. Ohne den Skriptfehler-Abschnitt waere der Knopf verschwunden UND die Seite kaputt gewesen, und das haette wie ein Erfolg ausgesehen. Jetzt haengt es dort, wo die Person ankommt (`werZeigen`) -- ein vorhandener Knopf laesst sich immer entfernen, auf die Reihenfolge des Ladens zu bauen waere eine Annahme. GEGENPROBE: DogFather hat seinen Chat-Knopf weiterhin und 24 Wege auf andere Seiten. Ohne diesen Abschnitt saehe eine abgeschaffte Funktion genauso aus wie eine, die richtig entscheidet. 7 Pruefungen, 0 Fehler. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
c2a8c5f15f |
Zentrale: "0 betreut" war fuer die Community dieselbe tote Zahl
Im Code stand die Loesung schon -- fuer jemand anderen. Am 10.09.2026 wurde dort vermerkt: "BETREUT" IST FUER EINEN MODI IMMER NULL. Er betreut keine Creator. Auf seiner Startseite stand deshalb dauerhaft "0 betreut": eine Zahl, die nie etwas anderes sagen kann, und damit schlimmer als keine. Wer sie sieht, sucht nach dem Fehler. Fuer ein Mitglied der Community gilt das erst recht -- und dort blieb es stehen. Dieselbe Zahl, derselbe Grund, dieselbe Wirkung. Jetzt steht dort, was die Community wirklich betrifft: WUENSCHE OFFEN. Der Ort, an dem sie mitentscheidet, was als Naechstes passiert -- eine Zahl, die zum Hingehen einlaedt, statt eine, die nichts sagt. WORAN DIE ENTSCHEIDUNG HAENGT: `freigabeBedingung` gibt nur fuer Leute von aussen eine SQL-Bedingung zurueck, sonst null. Damit ist die Frage "ist das jemand aus der Community" schon beantwortet, ohne dass hier ein Rollenname steht -- und dieselbe Bedingung sorgt dafuer, dass nur gezaehlt wird, was diese Person auch sehen darf. GEMESSEN, beide Seiten: Community : "4 Wuensche offen" DogFather : "2 im Team" (unveraendert) pruef-zentrale-ring: 14 Pruefungen, 0 Fehler. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4f5ac04bc9 |
Startseite: ein Zuschauer hat keine Aufgaben -- und keine toten Knoepfe
ZUM ERSTEN MAL MIT GAST-AUGEN ANGESEHEN. Gemessen wurden bisher immer nur die sieben Bretter, nie die Seite davor -- dabei ist sie das Erste, was ein Mitglied sieht. Sie zeigte: "DEINE AUFGABEN" mit sieben Zaehlern (Ueberfaellig, Heute faellig, Offen, In Arbeit, Review, Erledigt, Abgebrochen), darunter "Nichts offen. Alles abgearbeitet - goenn dir was." und im Kopf "Nichts liegt an - guter Tag zum Vorarbeiten." Das ist die Sprache eines Arbeitsplatzes. Eine Zuschauerin hat hier keinen: Sie arbeitet nicht vor, ihr wird nichts zugewiesen, und "Review" sagt ihr nichts. UND JEDE DER SIEBEN ZAHLEN WAR EIN LINK auf aufgaben.html. Die Rechtetabelle nennt dort "ALLE" -- was die Rolle der Community ausdruecklich NICHT einschliesst. Nachgemessen: Ein Klick landet wieder auf start.html. Sieben tote Knoepfe, und der Kommentar direkt daneben sagt selbst: "Ein toter Knopf ist keine Antwort." WORAN DIE ENTSCHEIDUNG HAENGT -- nicht an der Rolle. Rollennamen der Community gehoeren nicht in eine Datei, die jeder herunterladen kann (pruef-modi-wortleck wacht darueber, und ROLLENTEXT laesst sie aus demselben Grund aus). Gefragt wird stattdessen nach etwas, das der Server ohnehin beantwortet hat: Hat diese Person die Aufgaben-Kachel? Er schickt nur, was jemand sehen darf. Keine zweite Wahrheit, kein Rollenname -- und es bleibt richtig, wenn sich die Rechte aendern. GEGENPROBE IM MESSWERKZEUG: ein zweiter Durchgang als DogFather auf derselben Seite. DogFather : Block DA, 7 Links, "Vorarbeiten" ja Community : Block weg, 0 Links, keine Arbeitswoerter Ohne diesen Durchgang saehe eine abgeschaffte Funktion genauso aus wie eine, die richtig entscheidet. Nebenbei: Die Startseite ist fuer die Community von 1436 auf 1231 px geschrumpft. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
e128c169b9 |
Community: das Handy aufgeraeumt, und leere Bretter zeigen keine Filter
BISHER HABE ICH AM RECHNER GEMESSEN. Die Community ist ueberwiegend mit dem Telefon unterwegs -- also 412 px, alle sieben Bretter. 1. FUENF KARTEN, DREI VERSCHIEDENE ANORDNUNGEN. Am Rechner stehen Etikett, Titel und Zustand nebeneinander, und das ist richtig. Auf 412 px hing es an der LAENGE des Etiketts: Bei "SONSTIGES" passte der Titel noch daneben und "Offen" rutschte darunter; bei "FUER DEN STREAM" stand das Etikett allein oben und "Offen" ploetzlich RECHTS vom Titel. Inhaltlich unterschied sich nichts -- man liest es als Unordnung. Unter 560 px jetzt feste Reihenfolge: die Marken oben nebeneinander, der Titel darunter ueber die volle Breite. Immer gleich. 2. "ERLEDIGT" STAND ZWISCHEN NAME UND ROLLE: "von Filipe · erledigt · DogFather". Der Rollenname gehoert zum Namen davor, und "erledigt" ist eine Aussage ueber den Eintrag, nicht ueber die Person -- dazwischen gelesen wirkt es, als sei jemand erledigt. 3. FILTER FUER NICHTS. Am ersten Tag steht auf jedem Brett ein Satz wie "Noch hat niemand Hallo gesagt. Sei der Erste - ein Satz reicht." Darueber standen fuenf Filterknoepfe. Das ist die schlechteste Stelle fuer Bedienelemente, die ins Leere fuehren: Wer zum ersten Mal hier ist, soll den Satz lesen und schreiben. Wie bei "Nur offene" ist `!filter` der wichtige Teil: Ist die Liste leer, WEIL gefiltert wird, bleibt die Reihe stehen -- sonst kaeme man nie wieder zu "Alle" zurueck. Gemessen: leer 0 Filter, mit Inhalt 5 bzw. 6. UND DAS MESSWERKZEUG KANN JETZT LEERE BRETTER ZEIGEN (LEER=ja). Die Texte dafuer gibt es seit Langem -- gesehen hatte sie noch niemand, weil jede Messung vorher erst den Startkatalog uebernimmt. Genau deshalb war der Filter dort nie aufgefallen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
447a4157a5 |
Community: die Koepfe sagen jetzt, wofuer das Brett da ist
DIE SIEBEN BRETTER HATTEN KEINE UNTERZEILE. Ein Mitglied sah nur:
— TERMINE
Was ansteht
Hier schreibt das Team.
Die Oberzeile ist eine Kategorie, kein Satz; darunter stand
ausschliesslich, OB man schreiben darf -- auf drei Brettern sogar
wortgleich dasselbe. Was das Brett IST und was man hier tut, stand
nirgends.
Jetzt sagt jeder Satz zwei Dinge: wofuer das Brett da ist und was man
konkret tut. Zum Beispiel: "Was ihr euch wuenscht. Drueck ,Will ich
auch' - danach wird sortiert, was am meisten gewollt ist." Der Hinweis
aufs Schreibrecht haengt sich dahinter, in dieser Reihenfolge: "was
ist das hier" kommt vor "darf ich mitmachen".
--- Zwei Funde aus der Highlights-Galerie ---------------------------
1. DREI KARTEN, DREI HOEHEN. `align-items: start` liess jede Karte
dort enden, wo ihr Text aufhoerte. Eine Galerie ist ein Raster --
ungleiche Kanten liest man als Fehler, nicht als Absicht. Jetzt
gleich hoch (gemessen: aus 3 verschiedenen Hoehen wurde 1).
2. "NUR OFFENE" AUF BRETTERN OHNE ZUSTAENDE. Fuenf der sieben kennen
gar kein "offen/erledigt" -- ein Clip ist nicht erledigt. Der Knopf
stand trotzdem ueberall und tat dort nichts. Ein Knopf, der nichts
tut, kostet das Vertrauen in den naechsten.
Er erscheint jetzt nur, wenn die Liste ueberhaupt etwas Erledigtes
enthaelt -- dieselbe Regel wie bei der Kanalzeile. Das `||
filter === 'offen'` daneben ist kein Beiwerk: Ist der Filter aktiv,
sieht man gerade keine erledigten mehr, und der Knopf wuerde unter
der eigenen Hand verschwinden.
GEGENPROBE IM MESSWERKZEUG: Ein Wunsch wird auf erledigt gesetzt.
Wunschliste 6 Filter (mit "Nur offene"), Highlights 5 (ohne).
Ohne diesen Eintrag saehe eine abgeschaffte Funktion genauso aus
wie eine, die richtig entscheidet.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6e062b2439 |
Community: ein Ton je Art -- gesucht, nicht geraten
Alle Etiketten trugen denselben blauen Ton. Auf "Regeln & Hilfe"
stehen siebzehn Karten untereinander, auf dem Treff acht -- das Auge
hatte nichts, woran es sich festhalten konnte. Man liest dann jede
Ueberschrift, statt zu ueberfliegen.
NACH BEDEUTUNG, NICHT NACH REIHENFOLGE. Lob gruen, "etwas stimmt
nicht" warmrot, Fragen blau, Regeln golden. Deshalb traegt die Art
"frage" auf drei Brettern denselben Ton: Wer das Muster einmal
gelernt hat, soll es wiedererkennen.
WARUM EIN WERKZEUG UND KEINE FARBLISTE. Der erste Versuch war von
Hand: feste Helligkeit, Buntheit nach Gefuehl. Vier Toene lagen
ausserhalb des darstellbaren Bereichs, drei Paare zu nah. Nach dem
Nachbessern waren es fuenf zu nahe Paare -- wer die Buntheit eines
Violetts senkt, schiebt es naeher an alles andere Gedaempfte. Zwei
Zahlen von Hand zu stimmen, waehrend eine dritte Bedingung mitlaeuft,
geht nicht auf. Das ist eine Suche, keine Wahl.
tools/art-farben.mjs sucht deshalb selbst: Der Farbwinkel steht fest
(das ist die Entscheidung), Helligkeit und Buntheit werden gesucht --
unter drei Bedingungen gleichzeitig: in sRGB, Kontrast mindestens
4,5:1 auf dunklem Grund, und mindestens 0,10 OKLab-Abstand zu jeder
Art, die auf DEMSELBEN Brett vorkommt. Ueber Bretter hinweg darf sich
ein Ton wiederholen -- man sieht nie zwei gleichzeitig.
UND ES SUCHT DIE LEISESTE FASSUNG, nicht die kraeftigste. Der erste
Durchlauf maximierte die Buntheit; heraus kamen #35f695 und #f584fd --
Neongruen und Neonviolett. Das widerspricht der Hausregel ("gedeckte
statt reisserisch-grelle Neon-Optik"), und bei siebzehn Karten waere
es eine Leuchtreklame. Jetzt: gerade bunt genug, um sie zu
unterscheiden. Buntheit ist eine Kostenstelle, kein Ziel.
Ergebnis: 23 Toene, 39 Paare geprueft, engstes Paar je Brett 0,100.
DAS WERKZEUG PRUEFT AUCH DAS CSS gegen seine eigene Rechnung. Ohne
das misst es nur sich selbst: Wer einen Ton von Hand aendert, bliebe
unbemerkt -- genau die Art Pruefung, die immer bestaetigt. Gegenprobe:
ein Ton von Hand verstellt -> rot mit Angabe von Soll und Ist.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
11c4a795e2 |
Community: Starthilfe beim Schreiben -- und vier Funde aus den Bildern
Filipe: "perfektioniere jede einzelne kategorie der community ... ich will auch dass du fertige und beispiele machst fuer die community damit die auch start hilfe haben ueberall." STARTHILFE: Wer zum ersten Mal schreibt, steht vor einem leeren Feld -- der haeufigste Grund, warum ein Brett still bleibt, obwohl viele mitlesen. Im Formular stehen jetzt Beispiele: ein Klick fuellt Art, Ueberschrift und Text. Auf treff, wunsch, highlight und mitmachen -- nicht auf anschlag, ansteht, regeln, denn dort schreibt die Community nicht, und ein Angebot fuer eine verschlossene Tuer ist keins. JEDE VORLAGE HAT LUECKEN. Eine, die man absenden KANN, wird abgesendet; dann steht dort zehnmal derselbe Satz, und der elfte Mensch merkt, dass hier niemand wirklich schreibt. Die Pruefung misst das: keine Vorlage ohne "…". NICHT ZU VERWECHSELN MIT DEM STARTKATALOG. Der ist fuers Team (fertige Beitraege zum Uebernehmen), das hier fuer die Mitglieder. --- Vier Funde, drei davon nur aus dem Bild ------------------------- 1. ZWEI KNOPFREIHEN MIT DENSELBEN WOERTERN. Auf "Regeln & Hilfe" standen "Regel · Haeufige Frage · Hilfe · Was passiert, wenn" zweimal untereinander -- die eine filterte, die andere sprang zur Ueberschrift, und beide sahen gleich aus. Wo nach Art gegliedert wird, entfaellt jetzt der Filter; die Sprungmarken sind Links geworden, mit "Springe zu" davor und der Anzahl dahinter. 2. "MELDEN" UNTER JEDER REGEL. Siebzehn Melden-Knoepfe unter Texten des Teams -- man meldet keine Regel. Steht jetzt nur noch an Beitraegen von Mitgliedern. Die Gegenprobe im Messwerkzeug legt dafuer eigens einen Beitrag eines zweiten Mitglieds an: Ohne ihn saehe ein abgeschaffter Meldeweg genauso aus wie ein funktionierender. 3. DER HINWEIS LAG AUF DER NAECHSTEN BESCHRIFTUNG. Auf 412 px stand "Gehoert allen hier - wer Der Treff sieht ..." quer ueber "UEBERSCHRIFT". Der Hinweis haengt absolut unter dem Feld, und darunter sind 30 px Luft -- genug fuer EINE Zeile. Unter 560 px steht ohnehin nur ein Feld je Zeile; dort gibt es nichts auszurichten, und er darf einfach im Fluss stehen. 4. UND MEIN EIGENER FEHLER, der alles unsichtbar machte: `vorlagen` gab es hier schon -- als Checkliste fuer Creator, mit demselben Behaelter `#vorlagen`. Die spaetere Funktionsdeklaration gewinnt, zwei Elemente trugen dieselbe Kennung, und die Starthilfe erschien NIE. Keine Fehlermeldung, keine rote Pruefung, nichts in der Konsole. Gefunden nur durch einen Blick auf das Bild. Deshalb prueft pruef-vorlagen jetzt im Browser mit, dass keine Kennung doppelt vorkommt -- derselbe Fehler wie am 17.09. mit `.teilen`, und beim naechsten Mal soll ihn nicht der Zufall finden. Nebenbei messbar: "Regeln & Hilfe" ist von 4569 auf 3623 px geschrumpft, die Karten sind 54 px niedriger. Geprueft: pruef-vorlagen (neu, 24), pruef-video unveraendert 67. Gegenproben: unbekannte Art -> rot; Vorlage ohne Luecke -> rot. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d4e05e460a |
Community: die echte Sicht messbar machen -- und die Sternchen weg
Filipe: "perfektioniere jede einzelne kategorie der community."
ERST MESSEN. tools/community-blick.mjs meldet sich als GAST an und
fotografiert alle sieben Bretter. Das war noetig, weil als DogFather
auf jedem Brett Knoepfe und Felder stehen, die ein Mitglied nie sieht
-- wer so beurteilt, beurteilt eine Seite, die es fuer die Community
nicht gibt.
Der Weg dorthin war laenger als gedacht, und jeder Umweg steht als
Kommentar im Werkzeug:
- Die Community hat eine EIGENE Anmeldeseite (crew-index.html); auf
der anderen gibt es die Rolle "gast" gar nicht.
- Wer sich zum ersten Mal anmeldet, muss sein Alter bestaetigen
(400 "alter_offen"), sonst kommt er nicht hinein.
- Ueber die echte Adresse schickt der Server HSTS, woraufhin
Chromium alle Unterdateien auf https umbiegt -- der Testserver
spricht nur http. Ergebnis: eine nackte Seite ohne Stil und ohne
Skripte, auf der kein Knopf etwas tat. Die Kopfzeile ist richtig
so und bleibt; stattdessen wird jetzt ueber die Kopfzeile
angemeldet und das Sitzungsplaetzchen in den Browser gelegt.
Ohne diese drei Punkte fotografiert man die Anmeldeseite und haelt
"0 Karten, kein Schreibfeld" fuer einen Befund ueber die Bretter.
ERSTER BEFUND, BEHOBEN: An zehn Stellen stand **Fettschrift** als
Sternchen im Text. Auf "Regeln & Hilfe" hiess es woertlich "Drei
Stufen: **Hinweis** ..., **Pause** ..., **Ausschluss**" -- ausgerechnet
die drei Stufen, um die es geht, sahen aus wie ein Tippfehler.
KEIN innerHTML: Gebaut wird aus einzelnen Knoten. Was nicht zwischen
zwei Sternchenpaaren steht, wird Text und kann nichts anderes werden.
Ein einzelnes Sternchen bleibt ein Sternchen -- "3 * 4" ist keine
Hervorhebung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e933de3248 |
Anruf: der Lautsprecher -- und warum es kein Freisprech-Knopf ist
Filipe: "die funktion lautsprecher fehlt." Er ist das Gegenstueck zum Mikrofon: "Mikro aus" heisst, die anderen hoeren MICH nicht -- "Lautsprecher aus" heisst, ICH hoere sie nicht. Beides braucht man, aus verschiedenen Gruenden: das Mikro, wenn es bei einem selbst laut ist; den Lautsprecher, wenn nebenher etwas laeuft oder jemand ins Zimmer kommt. WAS BEWUSST NICHT GEBAUT WURDE: der Umschalter zwischen Hoermuschel und Freisprechen, den ein Telefon hat. Recherchiert statt geraten -- den gibt es im Browser nicht: Auf dem iPhone entscheidet Safari selbst, wohin der Ton geht, und Android laesst einzelne Toene gar nicht auf ein anderes Geraet legen (setSinkId ist dort nicht verfuegbar, weil die Plattform es nicht hergibt). Ein Knopf, der dort nichts tut, waere schlimmer als keiner -- man drueckt ihn und sucht den Fehler dann bei sich. Wo es GEHT (Rechner mit Chrome, Edge, Safari), steht dafuer eine echte Geraeteauswahl daneben. Sie erscheint nur, wenn es mehr als ein Geraet gibt UND die Namen bekannt sind; eine Auswahl mit einem Eintrag ist keine Auswahl, sondern eine Behauptung. DIE PRUEFUNG, AUF DIE ES ANKOMMT: Kommt jemand dazu oder geht jemand, werden die Toenelemente NEU GEBAUT -- und neue Elemente wissen nichts von einem Schalter, der vorher umgelegt wurde. Genau daran scheitern solche Knoepfe sonst: Sie wirken, bis sich die Runde aendert, und dann hoert man ploetzlich wieder mit. Gegenprobe (Anwenden nach dem Neuzeichnen ausgebaut) macht genau diese eine Pruefung rot, waehrend alle anderen gruen bleiben. Geprueft: pruef-anruf 73 -> 80, im echten Dreiergespraech im Browser. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
59c84bd248 |
Videos: Stufe 7 -- aus einem Wunsch wird ein Video, mit Namen
"Ein Video aus einem Wunsch zeigt den Namen." Wer sich etwas gewuenscht hat, soll sehen, dass daraus etwas geworden ist -- das ist der Sinn eines Wunschbretts. Ohne die Verbindung ist die Galerie eine Sammlung, und der Wunsch von letzter Woche bleibt unbeantwortet im Raum stehen. DER KNOPF STEHT AM WUNSCH, nicht im Formular oben. Das ist dieselbe Entscheidung wie bei den Kettenknoepfen daneben, aus demselben Grund (dort woertlich): "Wer ein Formular ausfuellt, denkt nicht an den Wunsch von letzter Woche." Hier denkt er an nichts anderes. DAS LECK, das es nicht geben darf: Der Titel der Quelle wird auf der Kachel ANGEZEIGT. Eine Kette in die Content-Planung waere deshalb kein Schoenheitsfehler, sondern ein Weg, interne Arbeit in die Community zu tragen. Die Quelle muss ein Community-Brett sein -- dieselbe Regel wie beim "Daraus"-Knopf. ZWEI WEGE, EIN ZIEL: "Daraus ein Highlight machen" gibt es laenger. Wer ihn geht und DANACH das Video einfuegt, bekaeme sonst ein zweites Highlight aus demselben Wunsch -- zwei Wege zum selben Ziel, die nichts voneinander wissen. Das Video haengt sich jetzt an den vorhandenen Eintrag. Der Titel bleibt dabei der des Wunsches: Er stammt von einem Menschen, der von TikTok ist eine Bildunterschrift mit Schlagwoertern. Geprueft: pruef-video 51 -> 67. Gegenprobe (Brett-Pruefung und Anhaengen ausgebaut) macht 6 rot, darunter "ein Eintrag aus der Content-Planung kommt NICHT als Quelle durch (201)". UND DAS BILDSCHIRMFOTO HAT ETWAS GEFUNDEN, das keine Zahl gemeldet haette: Das Eingabefeld erschien am ENDE der Karte, unter der Fusszeile -- getrennt von dem Knopf, den man gerade gedrueckt hatte. Alle Pruefungen waren gruen, das Feld war da und reagierte. Jetzt haengt es an der Knopfreihe. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
fb55377e19 |
Videos: Stufe 5 -- fuehrt der Knopf noch irgendwohin?
Ein Video kann bei TikTok geloescht oder auf privat gestellt werden.
Bei uns blieb der Eintrag stehen -- mit Cover, Text und einem Knopf
auf eine Fehlerseite. Das faellt beim Bauen nicht auf und beim Testen
nicht; es faellt dem auf, der klickt, und das ist die Community.
DREI ANTWORTEN, NICHT ZWEI. Die naheliegende Fassung fragt TikTok und
setzt bei einem Fehlschlag "weg". Die waere an einem einzigen
schlechten Nachmittag von TikTok in der Lage, die halbe Galerie als
geloescht zu markieren -- und wer das hinterher sucht, sucht lange,
denn im Protokoll stuende sauber, dass gefragt wurde. Also:
Daten kommen an -> da. Zaehler zurueck, eine frueher gesetzte
Markierung faellt weg (privat gestellte
Videos kommen wieder).
"gibt es nicht" (404) -> ein Fehlversuch. Erst der DRITTE an drei
verschiedenen Tagen markiert.
niemand antwortet -> weiss nicht. Aendert gar nichts, nicht
einmal den Zeitstempel: Wer ihn setzte,
verschoebe die naechste Nachfrage um sieben
Tage, obwohl nichts gemessen wurde.
Drei Geschwindigkeiten beim Nachsehen: unauffaellig woechentlich,
verdaechtig taeglich (sonst dauerte eine Loeschung drei Wochen bis zur
Anzeige), schon markiert wieder woechentlich -- taeglich nachzufragen
waere Hammern fuer eine Auskunft, die wir schon haben. Gefunden hat
das eine rote Pruefung, nicht das Nachdenken davor.
Der Knopf verschwindet nicht, er sagt "Bei TikTok nicht mehr da".
Bewusst kein Rot: Es ist kein Fehler, sondern eine Auskunft -- Titel,
Text und Cover stimmen weiter, die liegen bei uns.
Geprueft: pruef-video 37 -> 51. Gegenprobe (Stoerung als "weg" werten
plus Markieren ab dem ersten Versuch) macht 8 rot, darunter woertlich
"eine Stoerung erhoeht den Zaehler NICHT (0 -> 1)".
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
88a8712638 |
Messung von aussen: traegt die Vermittlung wirklich?
Dass der Server auf 3478 antwortet, beweist nur, dass der Dienst laeuft und dieser eine Port offen ist. Ein vermittelter Anruf laeuft ueber einen ZWEITEN Port, den coturn erst bei der Zuteilung vergibt. Ist der Bereich 49160-49260 in der Firewall zu, antwortet STUN weiterhin brav, die Zuteilung gelingt sogar -- und es kommt trotzdem kein Ton an. Das faellt erst im echten Anruf auf, und auch dann nur bei denen, die die Vermittlung ueberhaupt brauchen. Deshalb wird bis zum Schluss gemessen: zuteilen lassen, sich selbst als Gegenstelle eintragen, ein Paket ueber die zugeteilte Adresse schicken, nachsehen ob es ankommt. Live von aussen gelaufen: 7 Pruefungen, 0 Fehler, Relay-Port 49190. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
00f0271ea6 |
Probelauf prueft auch die Abfrage des Einrichtungswerkzeugs
Die STUN-Abfrage in turn-einrichten.mjs hatte noch nie einen antwortenden Server gesehen. Eine Abfrage, die immer "keine Antwort" sagt, laesst uns an der Firewall suchen, waehrend dort nichts falsch ist. Jetzt gemessen: mit laufendem Server erkennt sie ihn, ohne meldet sie ihn als nicht erreichbar. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
12b0438dc2 |
Auch .conf-Dateien mit Unix-Zeilenenden
deploy/turnserver.conf hatte keine Regel. Heute steht LF darin, weil sie so angelegt wurde -- wer sie unter Windows bearbeitet und speichert, haengt aber an jede Zeile ein unsichtbares Zeichen. Aus static-auth-secret=abc wuerde dann ein Geheimnis, das auf CR endet, und coturn wiese jeden Anruf ab, ohne dass die Datei falsch aussieht. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
775c4b4207 |
Vermittlungsserver: coturn mit Zugangsdaten, die verfallen
Damit Anrufe auch in Netzen zustande kommen, die keine direkte Verbindung zulassen (15-25 % der Faelle). coturn ist installiert, steht aber still, bis die Konfiguration liegt -- ein coturn mit Werkseinstellung ist ein offenes Relais. KEIN FESTES PASSWORT. Es laege dauerhaft im Browser jedes Team-Mitglieds und liesse sich nie entziehen. Der Server rechnet stattdessen bei jeder Abfrage Zugangsdaten, die nach zwoelf Stunden verfallen (server/workspace-turn.js, coturns `use-auth-secret`). Das Geheimnis liegt in einer Datei, nicht in der Datenbank: einstellung- Setzen() schreibt Werte ins Protokoll, und coturn braucht denselben Wert ohnehin in /etc. Die Oberflaeche frischt die Daten vor jedem Anruf auf. Der Chat ist eine App, die tagelang offen bleibt -- wer nur beim Laden holt, telefoniert am zweiten Tag ohne Vermittlung, und es faellt nicht auf: Es scheitern nur die, die sie gebraucht haetten. DIE WICHTIGSTE ZEILE DER KONFIGURATION ist die Sperrliste. Gemessen: dreizehn Dienste lauschen auf diesem Server nur oertlich, darunter Caddys Verwaltung auf 127.0.0.1:2019 -- wer sie erreicht, kann jede Website umleiten. Ohne Sperrliste waere der Vermittlungsserver die Tuer dorthin, und die Anfrage saehe fuer Caddy aus wie von localhost. Geprueft: pruef-anruf.mjs 51 -> 73 Pruefungen. Gegenprobe (Geheimnis als Passwort ausliefern + fremde Zugangsdaten ueberschreiben) macht genau 5 rot, darunter "das Geheimnis steht NIRGENDS in der Antwort". tools/turn-probelauf.sh beweist am echten coturn, was ein fester Vergleichswert nicht kann: dass coturn unsere Rechnung akzeptiert. Beide Seiten koennten sonst konsequent falsch rechnen und jede Pruefung waere gruen. Seine eigene Gegenprobe war zweimal zu Recht rot -- der erste Aufbau mass wegen `-y` gar nicht das Ziel, das er zu messen behauptete, sondern coturns eingebauten Loopback-Schutz. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5bbf1f2019 |
Der Anruf funktioniert wirklich -- gefunden im Dreier-Test
GEBAUT WAR NICHT BEWIESEN. Der Anruf ist fuer bis zu vier Leute
geschrieben, geprueft war er zu zweit -- und der Zweier-Test pruefte
nur, dass der Kasten erscheint und die Uhr laeuft. Ob jemals TON
ankommt, hat er nie gefragt.
Der Dreier-Test hat es gefragt. Ergebnis beim ersten Lauf:
DogFather 0 Stroeme, "Verbunden"
rechte Hand 0 Stroeme, "Verbunden"
der Modi 0 Stroeme, "Verbindung ..."
DREI FEHLER, gefunden durch Messen statt Raten:
1. SIGNALE, DIE ZU FRUEH KOMMEN, WURDEN WEGGEWORFEN -- und das haette
JEDEN Anruf getroffen, auch zu zweit.
Wer rangeht, meldet "dabei". Der Anrufer bekommt das sofort und
schickt sein Angebot. Der Angerufene braucht danach aber noch ein
bis zwei Sekunden fuer das Mikrofon, und in dieser Zeit war `anruf`
noch null. Das Angebot wurde still verworfen; danach kommt keins
mehr. Beide Seiten zeigten "Verbindung ...", und es passierte nie
wieder etwas.
In der Spur war es unuebersehbar, sobald man hinsah:
ereignis:signal inhalt=angebot <- kommt an
ereignis:signal inhalt=weg
verbindung angelegt <- erst JETZT
Ein Signal ist keine Nachricht, die man wiederholen kann. Wer es
wegwirft, hat den Anruf verloren -- es wird jetzt aufgehoben und
abgearbeitet, sobald das Mikrofon steht.
2. DIE WARTESCHLANGE LAG ZUERST AN DER FALSCHEN STELLE. Eingebaut in
`signalVerarbeiten`, verworfen wurde aber schon eine Ebene hoeher.
Gefunden erst, als die Diagnose zeigte, dass `signalVerarbeiten` NIE
aufgerufen wird: keine einzige Konsolenzeile, obwohl beide Zweige
dort etwas melden. Eine Reparatur an der falschen Stelle sieht aus
wie eine Reparatur.
3. "VERBUNDEN" STAND DA, BEVOR ETWAS VERBUNDEN WAR. Die Meldung wurde
gesetzt, wenn jemand RANGEHT -- die Verbindung braucht danach noch
Sekunden. Den richtigen Zeitpunkt kennt nur die Verbindung selbst
(`onconnectionstatechange`). Eine Anzeige, die etwas Falsches sagt,
ist schlimmer als keine.
Dazu zwei Kleinigkeiten, die dabei auffielen: Das Abarbeiten laeuft
jetzt NACHEINANDER (ein Verbindungsweg, der vor der Beschreibung
ankommt, wird abgewiesen -- parallel gewinnt oft der Weg), und die
Warteschlange wird beim Auflegen geleert, damit kein altes Signal in
den naechsten Anruf wandert.
Und die Pruefung selbst hatte einen Fehler: Abschnitt 6 setzt erfundene
STUN-Adressen und liess sie stehen. Der Browser haette im naechsten
Abschnitt gegen deren Zeitlimit gekaempft statt gegen den Code. Sie
werden jetzt wieder geleert -- eine Pruefung, die der naechsten den
Boden verstellt, macht deren Ergebnis unlesbar.
pruef-anruf 40 -> 51. Der neue Abschnitt prueft das, worauf es
ankommt: Bei drei Teilnehmern muss JEDER zwei Stroeme haben. Haette
`verbindungen` eine einzelne Variable statt einer Karte, ginge es zu
zweit gut und der Dritte ueberschriebe stillschweigend den Ersten --
man sieht sich zu dritt und hoert einen.
Gegenprobe (Warteschlange wieder ausgebaut): 4 rot, genau die
Tonpruefungen.
Gruen: anruf, chat, css-klassen, namen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
93c9788782 |
Telefonieren im Chat -- und die Farben nach Nachbarschaft verteilt
ZWEI SACHEN IN EINEM COMMIT, weil beide aus derselben Nacht stammen. === 1. DIE FARBEN: DER RICHTIGE ABSTAND === Filipe: "es gibt noch mehr die aehnlich aussehen von den farben also leg los alle die sich aehnlich sind von den farben wechseln." Er hatte recht, und mein Denkfehler laesst sich benennen: Ich hatte den kleinsten Abstand ueber ALLE 37 Paare maximiert -- und der liegt bei 37 Farben zwangslaeufig bei 0,10. Das ist die Packungsgrenze, kein Versaeumnis. NUR SIEHT NIEMAND ALLE 37 NEBENEINANDER. Man sieht NACHBARN. Im Browser gemessen, an der tatsaechlichen Lage auf dem Schirm -- 125 Paare, die wirklich nebeneinander stehen, 15 davon unter 0,15: Creator-Profile / Zahlen 0,1019 beide rosa-rot LIVE-Analyse / Technik 0,1030 beide orange Wunschliste / Meldungen 0,1032 beide gelbgruen Wer sieht was / Entwicklung 0,1039 beide cyan Regeln & Hilfe / Mitmachen 0,1047 beide gruen Der Treff / Anschlagbrett 0,1070 beide rosa Die Farben bleiben, ihre ZUTEILUNG aendert sich: Nachbarabstand 0,1047 -> 0,2133 (mehr als verdoppelt) Nachbarn unter 0,15 6 -> 0 Die Nachbarschaft steht in server/kachel-nachbarn.json, gemessen im Browser -- nicht aus der Struktur im Quelltext abgeleitet. Die sagt, was zusammengehoert, nicht was zusammen zu sehen ist. === 2. TELEFONIEREN IM CHAT === Filipe: "kann man machen dass die modis, rechte hand und ich auch telefonieren koennen im chat?" ... "was man selbst in die app reinsetzten kann, nicht meinen pc belastet und trotzdem vielleicht in gruppe, mit video oder einzelnd." DER TON GEHT NICHT UEBER DEN SERVER. Direkt von Browser zu Browser (WebRTC); der Server reicht nur die Verbindungsdaten weiter, ein paar Kilobyte je Anruf. Zu zweit kodiert jedes Geraet einen Strom und dekodiert einen -- die Last eines gewoehnlichen Videoanrufs. KEIN NEUER DIENST. Der Chat hatte bereits alles: `chatEreignis()` fuer den Hinweg (SSE), Push fuers Klingeln, Raeume mit mehreren Teilnehmern. Ein eigener WebSocket daneben waere eine zweite Verbindung fuer dieselbe Frage -- und die zweite wird beim naechsten Umbau vergessen. Gebaut: Ton und Video, einzeln und in Gruppe bis GRUPPE_MAX (4), Klingeln mit Annehmen/Ablehnen, Mikro und Kamera schaltbar, Gespraechsdauer, Auflegen. Der Chat bleibt daneben benutzbar -- man schreibt oft, waehrend man spricht. EIN FUND, DER OHNE PRUEFLAUF LIVE GEGANGEN WAERE: Der Server sperrt Mikrofon und Kamera per Permissions-Policy auf ALLEN Seiten. Der erste Lauf meldete "microphone is not allowed in this document" -- der Anruf haette bei JEDEM versagt, mit einer Meldung, die auf die falsche Faehrte fuehrt (man sucht an den Browsereinstellungen). Die Sperre bleibt ueberall und ist an genau EINER Stelle geoeffnet: der Chat-Seite, und nur fuer sie selbst (`self`, nicht `*`). NOCH NICHT GEBAUT -- und ausdruecklich nicht heimlich: coturn. Ohne Vermittlungsserver klappen Anrufe nur im selben Netz. Die Adressen stehen in den Einstellungen statt im Quelltext; sie lassen sich nachtragen, ohne eine Zeile zu aendern. Ein oeffentlicher STUN-Dienst als Standard kam nicht in Frage: Er saehe bei jedem Anruf die IP-Adressen beider Teilnehmer, und fuer ein Team, das ueber Moderation und Vorfaelle spricht, ist das keine Kleinigkeit. server/pruef-anruf.mjs, 40 Pruefungen. Der wichtigste Abschnitt: Wer nicht in den Raum gehoert, kommt an KEINE Route. Ein Anruf hinterlaesst keine Spur -- wer mithoert, faellt nicht auf. Gegenproben, jede zielgenau: Empfaengerpruefung der Signalisierung weg -> 1 rot Raumpruefung weg -> 5 rot (jede Route offen) Kopfzeilen-Ausnahme weg -> 4 rot Gruen: anruf, chat, chat-optik, chat-kanaele, css-klassen, namen, struktur. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
438493c7dc |
Kacheln: 37 Farben neu gerechnet, und in jeder ein eigenes Universum
Filipe, zwei Wuensche: "ich will das jede kachel eine andere farbe hat
... keine die sich irgendwie aehnlich sind ... richtig geil und
speziell" und "der hintergrund ... soll noch mehr viel mehr nach
universum sein. nicht einfach so paar weisse punkte sondern richtig
geil hochwertiger geiler universum ... in den kacheln ueberall".
BEIDES WAR BERECHTIGT, und beides liess sich messen:
kleinster Farbabstand 0,0529 (Rueckmeldung / Steckbrief)
Paare unter 0,10 26 von 666
schlechtester Kontrast 1,64:1 (Ton 35 -- praktisch unlesbar)
sieben Toene unter 4,5:1
Universum auf GENAU EINER Kachel
WIE DAS PASSIEREN KONNTE, obwohl es ein Farbwerkzeug gab: Es kannte 21
Farben. Seit dem 08.09. waren SECHZEHN von Hand dazugekommen (Ton 22
bis 37) -- jede einzeln plausibel, keine gegen die anderen gerechnet.
Das Werkzeug meldete weiter "0,0973, alle Bedingungen erfuellt" und
meinte einen Stand, den es nicht mehr gab. Dieselbe Krankheit wie eine
abgeschriebene Spaltenliste: Die Zahl wird nicht falsch, sie wird
UNZUSTAENDIG. Es liest die Anzahl jetzt aus den Dateien.
NEU GERECHNET, alle 37 auf einmal:
kleinster Abstand 0,0529 -> 0,1010 (fast doppelt)
Paare unter 0,10 26 -> 0
schlechtester Kontrast 1,64 -> 4,50:1
Buntheit bis 0,300 statt 0,170, Helligkeit 0,58 bis 0,92
Drei Stellschrauben: Buntheitsgrenze hoch (augenschonend heisst dunkles
Schema und kein Flackern, NICHT blass), Raster von 2 Grad auf 1 Grad
und von fuenf auf zwanzig Helligkeitsstufen, und sechzehn Startpunkte
statt einem. Der Kontrast 4,5:1 bleibt hart -- eine Kachelfarbe traegt
Text.
DAS UNIVERSUM STEHT JETZT IM HINTERGRUND JEDER KACHEL, nicht in einem
Element: Beide Pseudo-Elemente sind vergeben (Leuchtschiene, Glanz),
und ein neues Element muesste an jeder Stelle nachgetragen werden, die
Kacheln baut. Eine Ebene, die man vergessen kann, wird vergessen.
Siebzehn Ebenen: drei nahe Sterne mit Hof, vier mittlere (zwei im
Kachelton), fuenf Staubkoerner, eine Milchstrasse als Schraege, drei
Nebel im Kachelton, ein kuehler Gegenpol, eine Vignette. Die Nebel
tragen `var(--ton)` -- 37 Kacheln sind damit 37 verschiedene Nebel.
Keine Bewegung: 28 driftende Felder waeren 28 Dauerlaeufer auf der
Grafikkarte.
Nach dem ersten Bildschirmfoto nachgeschaerft -- die Sterne lagen bei
6 bis 14 Prozent und waren aus der Naehe nicht zu sehen, genau die
"paar weissen punkte". Der Grund steht in der Kachel selbst: Sie ist
halbdurchsichtig, darunter liegt das Buehnenbild. Ein Sternenfeld muss
sich hier gegen ein FOTO durchsetzen, nicht gegen Schwarz.
NEU: server/helfer-png.mjs -- ein PNG-Leser (zlib, 90 Zeilen). Er
beantwortet die Frage, die aus dem CSS nicht mehr zu beantworten war:
Zwischen Textfarbe und Flaeche liegen jetzt sieben Ebenen plus das
durchscheinende Buehnenbild. Gemessen am Bildschirmfoto: schlechtester
Textkontrast 8,02:1 (Grenze 4,5).
NEU: server/pruef-kachel-universum.mjs, 12 Pruefungen.
DREI ANLAEUFE FUER DIE STERNPRUEFUNG, und die ersten zwei waren gruen
und wertlos:
1. Ebenen im CSS zaehlen -- `0px` ist auch eine Zahl. Alle Sterne
auf null: blieb gruen.
2. Helle Punkte im Bildschirmfoto zaehlen -- die Kachel ist
halbdurchsichtig, das Foto darunter hat selbst Punktstruktur.
Gemessen: 459 Punkte mit Sternen, 441 ohne. Vier Prozent sind
kein Nachweis, sondern Rauschen.
3. Jetzt die GROESSEN aus dem CSS (>= 0,7 px). Schwaecher, aber
ehrlich -- und die Gegenprobe greift: 12 -> 0.
Dabei fiel ein eigener Messfehler auf: Der Bereich wurde aus der
Textposition geschaetzt und lag OBERHALB der Kachel. Verraten hat es
die Gegenprobe, die zweimal exakt 153 lieferte -- eine Messung, deren
Ergebnis sich nicht aendert, wenn man das Gemessene entfernt, misst
etwas anderes.
Gegenproben, alle zielgenau:
zwei gleiche Farben -> 3 rot Sterne auf 0px -> 1 rot
Nebel ohne Kachelton -> 1 rot (nach dem Schaerfen: vorher blieb es
gruen, weil `--ton` auch im Grundverlauf steht)
Gruen: kachel-universum, css-klassen, start-ansicht, namen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
3d9de349ad |
Wer sich kuemmert -- an jeder Anfrage und an jedem Kandidaten
Ein Versprechen von frueher, nie gebaut: die Arbeit mit der rechten
Hand teilen. Gemessen: Es gab dafuer NICHTS. Weder an `bewerbungen`
noch an `talent_stufe` stand eine Zustaendigkeit -- beide sehen alles,
niemand ist benannt.
Das ist nicht "geteilt", das ist "jeder dachte, der andere macht es".
Bei einer Anfrage wartet ein Mensch darauf. Bei einem Kandidaten
bleibt er auf seiner Stufe liegen -- die Standzeit an der Karte sagt
zwar, DASS etwas liegt, aber nicht, wer es aufheben sollte.
MAN NIMMT SELBST, MAN BEKOMMT NICHT ZUGETEILT. Ein "DogFather weist
zu" waere eine Rangordnung, und die gehoert hier nicht hin (18.08.2026:
"mich bitte nie wie da hoeher stellen wie andere"). Wer Zeit hat,
uebernimmt; wer keine mehr hat, gibt ab -- mit DEMSELBEN Knopf, wie bei
den Merkmalen und den Probeschritten.
DER FALL, AUF DEN ES ANKOMMT: Eine FREMDE Uebernahme wird mit 409
abgewiesen, nicht stillschweigend ueberschrieben. Sonst nimmt einer dem
anderen die Anfrage aus der Hand, ohne dass es jemand merkt -- und
beide glauben, sie sei erledigt. Wer trotzdem will, laesst erst
abgeben.
DER UNBESETZTE ZUSTAND IST DER AUFFAELLIGE. "Ich kuemmere mich" steht
als Knopf da, "Du kuemmerst dich" als ruhige Zeile, fremdes als
gestrichelter Rahmen ohne Zeigefinger (ein Knopf, der aussieht wie
einer und nichts tut, ist eine Falle). Andersherum waere die Liste ein
Feld aus Namen, in dem die Luecke nicht auffaellt -- und genau die
Luecke ist die Auskunft.
Verglichen wird ueber die NUMMER, nicht ueber den Namen: Zwei Leute
duerfen gleich heissen.
DREI EIGENE FEHLER, alle beim Nachsehen gefunden statt beim Schreiben:
1. `nurLeitung` HAT AN MEINER ROUTE GEFEHLT. Der Router setzt
`angemeldet` fuer den ganzen Pfad, `nurLeitung` aber je Route --
ich hatte nur die Nachbarzeilen ueberflogen. Ohne den Riegel haette
sich jeder Angemeldete fuer eine fremde Anfrage zustaendig erklaert:
kein Datenabfluss, aber ein Name an einer Anfrage, der dort nichts
zu suchen hat -- und sie gilt als betreut, waehrend sich niemand
kuemmert. Gegenprobe bestaetigt: ohne die Zeile 200 statt 404.
2. `nummer()` aufgerufen, das es in dieser Datei gar nicht gibt --
ein Absturz zur Laufzeit, den `node --check` nicht sieht.
3. Die Pruefung benutzte `json()` und rohe Cookie-Objekte statt der
Hausmittel `alsJson`/`holen`/`schicken` dieser Datei. Abgeschrieben
aus der Nachbardatei, in der sie anders heissen.
Und wieder eine Zeile, die ohne Daten gruen war: "um die sich niemand
kuemmert" bestaetigte auch bei LEERER Liste -- `undefined` ist nun
einmal kein Zustaendiger. Die Anzahl gehoert in die Bedingung.
pruef-nachwuchs 244 -> 258, pruef-bewerbung 77 -> 91.
Gegenproben:
Riegel gegen fremde Uebernahme weg -> 5 rot
nurLeitung weg -> 2 rot (der eigene Fehler)
pruef-nachruesten fuehrt beide neuen Spalten mit.
Gruen: nachwuchs, bewerbung, nachruesten, namen, css-klassen, struktur.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
1a2dfa07f3 |
Trichter und Entwicklungskarte kennen einander
An der Stufe "Im Team" steht seit jeher zweimal: "ab hier zaehlt die
Entwicklungskarte, nicht mehr diese". Gemessen: Es gab keinen Weg
dorthin. Wer den Satz las, musste die Seite selbst finden und die
Person dort aus einer Liste heraussuchen.
Das ist heute das DRITTE Mal dasselbe Muster -- ein Text verspricht
einen Weg, den es nicht gibt:
"uebernehmen oder sauber beenden" -> der Ausgang fehlte
Kalender zeigt Brettzettel -> zurueck fuehrte nichts
"ab hier die Entwicklungskarte" -> kein Link
HIN: Von der Talentkarte fuehrt ein Weg auf die Entwicklungskarte
GENAU DIESER Person -- ueber `?zeigen=person-<id>`, den Weg, den das
Haus dafuer schon hat (kopf.js), nicht ueber eine zweite Mechanik. Die
Karte ist beim Ankommen offen; ein Link, der auf einer Liste endet, auf
der man die Person wieder sucht, hat nichts erspart.
Der Sprung passiert ERST, wenn alle Kacheln stehen. Waehrend der
Schleife haengt die gesuchte noch nicht im Dokument und hat keine
Position -- ein Sprung dorthin waere einer an den Seitenanfang,
lautlos, und man haelt den Link fuer kaputt.
ZURUECK: Die Entwicklungskarte sagt jetzt, wie dieser Mensch gekommen
ist -- mit dem Namen der Talentkarte und wer ihn eingearbeitet hat.
Beim ersten Beurteilen ist genau das die Frage ("woher kommt der
eigentlich?"), und wer sie nicht beantwortet bekommt, faengt bei null
an, obwohl vier Wochen Beobachtung vorliegen.
NUR DER WEG, NICHT DIE DATEN. Die Merkmale aus dem Trichter hierher zu
kopieren waere bequem und falsch: zwei Kataloge, zwei Fragen (taugt er?
/ wie entwickelt er sich?). Eine Zahl aus dem einen sieht im anderen
aus wie eine Beurteilung und ist keine.
Moeglich wurde beides erst durch `talent_stufe.person_id` von vorhin --
ohne die Verknuepfung gibt es keine Richtung, in die man zeigen
koennte.
pruef-nachwuchs 236 -> 244. Geprueft wird nicht, ob ein Link DASTEHT,
sondern ob man am Ziel ankommt: Karte offen, richtige Person, Kachel
hervorgehoben, Herkunft da, Rueckweg da. Mit Gegenprobe an einer
zweiten Karte, die NICHT aus dem Trichter kam (sonst hiesse "kam ueber
den Trichter" nur, dass ueberall etwas steht).
Gegenproben:
Sprung ausgebaut -> 5 rot
Herkunft ausgebaut -> 2 rot, genau die beiden richtigen
Und wieder eine Schriftgroesse unter der Hausgrenze (.7rem = 11,2 px),
gefunden von pruef-css-klassen. Zurueckhaltend wird ueber FARBE
gedaempft, nicht ueber Groesse -- das ist der Unterschied zwischen
"leise" und "zusammengekniffen".
Gruen: nachwuchs, entwicklung, sprung, modi-wortleck, namen,
css-klassen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
a435e734c9 |
Aus dem Talent wird ein Mensch mit Aufgaben
Filipe: "wie talente bewertet werden, aufgaben bekommen, analysiert
werden von vanvan und mir, alles moegliche."
GEMESSEN VOR DEM BAU, und der Befund war groesser als erwartet: Der
letzte Schritt des Trichters legt einen Zugang an -- und die
Verknuepfung wurde NIRGENDS gespeichert. `zugangAnlegen()` gab die
Person zurueck, der Code wurde einmal gezeigt, und danach wusste die
Karte nicht mehr, wer aus ihr geworden ist.
Was dadurch nicht ging:
- von der Karte zur Person springen
- dem Neuen aus der Karte heraus seine ersten Aufgaben geben
- in einem halben Jahr nachsehen, aus welchem Kandidaten eigentlich
welches Teammitglied wurde
DREI SPALTEN WAEREN ZU VIEL GEWESEN, eine reicht: `talent_stufe.person_id`.
Kein Fremdschluessel auf `personen` -- wird ein Zugang geloescht, soll
die Karte stehen bleiben. Sie erzaehlt, wie jemand gekommen ist, und
das bleibt wahr, auch wenn er wieder geht. Ein CASCADE haette genau
diesen Verlauf mitgeloescht.
NUR SETZEN, NIE LOESCHEN (COALESCE): Sonst verloere die Karte ihren
Menschen, sobald jemand sie auf eine fruehere Stufe zuruecksetzt.
WOMIT ER ANFAENGT. Der Katalog mit 101 Aufgaben in 14 Bereichen gab es
laengst -- nur fuehrte der Weg dorthin ueber eine andere Seite, wo man
die Person heraussuchen und Bereich plus Stufe waehlen musste. Vier
Schritte, die niemand macht, waehrend er gerade jemanden aufnimmt;
dasselbe Muster hat heute schon zu einer Karte auf "Im Team" ohne
Menschen darin gefuehrt. Jetzt steht der Kasten an der Karte, ein Klick
legt einen Bereich an.
ES BLEIBT EIN ANGEBOT, KEINE AUTOMATIK -- Filipes Entscheidung bei der
Live-Checkliste gilt hier genauso: "was ungefragt Dinge anlegt, ist
schwer wieder loszuwerden". Und der Kasten ist ZU, wenn schon Aufgaben
da sind; offen wuerde er zum Nachlegen einladen, und das ist selten
gemeint. Daneben steht, wie viele schon offen sind -- ohne diese Zahl
legt man beim zweiten Hinsehen dasselbe noch einmal an.
pruef-nachwuchs 200 -> 236, davon 14 im Browser (Abschnitt 17 mit
eigenem Browser: der aus Abschnitt 15 lief, bevor es den Kandidaten
ueberhaupt gab -- ein Stand von zwei Abschnitten vorher ist keine
Messung, sondern eine Annahme).
VIER EIGENE FEHLER DABEI GEFUNDEN, drei davon durch die Gegenproben:
1. `d.angelegt?.length` -- die Antwort ist eine ZAHL, kein Feld. Der
Knopf haette "6 Aufgaben stehen bereit" gemeldet, auch wenn null
entstanden sind.
2. Der "Schritt zurueck" ging auf `probe` -- und der verlangt Buddy
und Datum. Die Route antwortete 400, die Stufe blieb stehen, und
die Zeile darunter bestaetigte, dass sich nichts geaendert hat:
eine Pruefung, die immer gruen ist. Aufgefallen erst an der
Gegenprobe (COALESCE ausgebaut -> blieb gruen). Eine Gegenprobe
ist keine Kuer, sie prueft die Pruefung.
3. Feldnamen `buddy`/`datum` statt `buddy_id`/`erste_schicht` --
Fehler in der Pruefung, nicht im Code.
4. Die Rollennamen-Zeile war ZU SCHARF und meldete prompt einen
Treffer: "Die Modis, die mit ihm gearbeitet haben" aus dem
Probeplan -- ein Satz, der ueber eine Schnittstelle kommt, die nur
die Leitung erreicht, und genau dorthin gehoert. Geprueft wird
jetzt, was hier neu ist; ueber die ausgelieferten DATEIEN wacht
pruef-modi-wortleck (101 Dateien, mit eigener Gegenprobe).
Gegenproben, jede zielgenau:
Nummer ungeprueft -> "erfundene Zugangsnummer wird abgewiesen"
COALESCE weg -> "Schritt zurueck nimmt ihr den Menschen weg"
Person nicht geliefert-> 4 rot
pruef-nachruesten fuehrt die neue Spalte mit -- jede neue Spalte gehoert
in diese Liste, sonst prueft die Datei den Weg von gestern.
Gruen: nachwuchs, nachruesten, modi-wortleck, namen, css-klassen,
struktur.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
5e628e0078 |
Brett und Kalender kennen einander jetzt in beide Richtungen
Der Kalender zeigt seit heute, was auf den Brettern steht und einen
Termin hat. Die Verbindung war aber EINSEITIG, und beide Halften
fehlten:
Beim SCHREIBEN konnte niemand wissen, dass ein Tag in der Zukunft den
Zettel in den Kalender bringt. Das Feld heisst "Datum" und ist mit
HEUTE vorbelegt -- die Funktion war vorhanden und unauffindbar. Eine
Funktion, die niemand findet, ist keine.
Beim LESEN sagte die Karte nichts. Am Fuss stand bloss ein Datum, und
"24.09.2026" sieht aus wie "17.09.2026" -- obwohl das eine ein Termin
ist und das andere der Tag, an dem jemand getippt hat.
EINE REGEL, ZWEI VERWENDER -> server/workspace-termin-regel.js.
Der Kalender fragt "welche gehoeren hinein?" (SQL, ganze Tabelle), die
Brettkarte fragt "stehe ICH drin?" (JavaScript, je Zeile). Beide Fassungen
stehen jetzt nebeneinander in EINER Datei, importfrei wie
treff-tabellen.js.
Das ist kein Vorsichtsprinzip, sondern Erfahrung: Zwei Fassungen
derselben Regel sind im Haus dreimal auseinandergelaufen -- die
abgeschriebene Spaltenliste (11.09., drei Spalten samt Inhalt weg), die
zweite Artenliste neben ARTNAME (ein BigMatch liess sich anlegen und
war unsichtbar) und `.teilen` heute frueh.
server/pruef-terminregel.mjs, 35 Pruefungen. Der Kern ist Abschnitt 2:
Er prueft die beiden Fassungen GEGENEINANDER, nicht jede fuer sich --
zwei Pruefungen, die je eine Seite bestaetigen, finden genau diesen
Fehler nicht. Verglichen wird beides: WELCHE Zettel und WELCHER Tag.
Neun Faelle, davon vier, die zu Recht wegbleiben.
Vier Gegenproben, jede in ihre eigene Richtung:
JS laesst mehr durch -> "die Karte behauptet einen Termin, den der
Kalender nicht kennt"
JS nennt anderen Tag -> "verschiedene Tage: Kalender 22., Karte 17."
SQL laesst mehr durch-> "steht im Kalender, aber die Karte sagt nichts"
Marke ausgebaut -> 0 statt 1
EIN ECHTER FEHLER DABEI BEHOBEN, und er war aelter als diese Arbeit:
Das Formularraster gibt jedem Feld GENAU ZWEI Zeilen (Schild dehnbar,
Eingabe fest 44 px) -- deshalb sitzen die Eingaben auf einer Linie. Ein
Hinweisabsatz erzeugt eine dritte Zeile, und weil das Raster alle
Felder auf gleiche Hoehe dehnt, rutscht ausgerechnet diese Eingabe nach
oben. Gemessen: 328..372 gegen 351..395. 23 px -- genau das, was man
als "verzogen" sieht.
Mit `git stash` getrennt: aufgaben.html war dadurch SCHON VORHER rot
(ein anderes Feld hat dort ebenfalls einen Hinweis), bereich.html hatte
ich neu verursacht. Der Hinweis haengt jetzt absolut unter dem Feld --
beide sind gruen, und zwar an der Wurzel, nicht symptomatisch.
`pointer-events: none`, sonst faengt der Satz Klicks ab, die dem
Element darunter galten.
Am Handy gemessen statt geschaetzt: 0 Ueberschneidungen mit anderen
Feldern. Gegenprobe (row-gap auf 2 px): 1 Ueberschneidung.
Und noch zwei eigene Pruefungsfehler behoben, beide von derselben Sorte:
ein falscher Selektor samt `.catch(() => {})`, der den Fehlgriff
lautlos verschluckte (danach war das Hinweisfeld leer und die Zeile
darunter trotzdem gruen, weil "" nun einmal nicht "ja" ist) -- und die
Marke wurde ueber `textContent` gezaehlt statt ueber ihre Sichtbarkeit.
Aufgefallen ist das am Bildschirmfoto, auf dem ich sie fuer fehlend
hielt; deshalb macht die Pruefung jetzt zusaetzlich einen AUSSCHNITT
der Karte -- auf einem Vollbild von 2000 px ist eine Pille von 28 px
nicht zu beurteilen.
Gruen: terminregel, kalender, formulare, ueberlappung, countdown,
namen, css-klassen, struktur.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
528ee1ecc7 |
Pruefung fuer den Weg, den es live allein gibt: alte Datenbank, neue Spalten
Entstanden aus einem Fehlalarm, den ich selbst verursacht habe.
Mein Deploy-Block liess vier Sekunden nach dem Neustart zaehlen, ob
`talent_stufe` die drei neuen Spalten hat. Antwort: 0. Das sah aus wie
eine fehlgeschlagene Umstellung an lebenden Daten -- und war keine.
Die Spalten entstehen beim ERSTEN angemeldeten Aufruf des Bereichs
(`tabellen()`, gesteuert ueber `bereit`), und vier Sekunden nach einem
Neustart hat sich noch niemand angemeldet. Die Pruefung verlangte eine
Aussage, die zu diesem Zeitpunkt gar nicht wahr sein KONNTE. Ein
Fehlalarm ist nicht harmlos: Er kostet Vertrauen in jede kuenftige
Zahl, die im selben Block steht.
Nachgestellt auf einer Kopie des exakten Live-Zustands (die sieben
Spalten vom Server abgelesen): erster Aufruf -> Spalten entstehen,
Seite antwortet 200. Nichts war kaputt.
DER EIGENTLICHE FUND: Der Weg „alte Datenbank bekommt neue Spalten" war
NIE GEPRUEFT. Jede Pruefung im Haus startet auf einer frischen Datei,
in der die Tabellen mit allen Spalten neu entstehen -- der
Nachruest-Pfad wurde dabei nie betreten. Gemessen: 27 Stellen in drei
Dateien ruesten Spalten so nach. Live ist das der einzige Weg, der
ueberhaupt vorkommt.
Dieselbe Sorte Luecke wie die Sicherung, die nie zurueckgespielt wurde:
Sie meldet jahrelang „in Ordnung" und sagt nichts darueber, ob sie im
Ernstfall traegt.
server/pruef-nachruesten.mjs, 11 Pruefungen:
1. Der Ausgangszustand stimmt -- MIT Gegenprobe, dass die neuen
Spalten wirklich fehlen (sonst bewiese der Rest nichts).
2. Ein echter Aufruf ruestet nach, und keine alte Spalte geht dabei
verloren (11.09.: eine abgeschriebene Liste hat genau so drei
Spalten samt Inhalt weggeworfen, ohne Fehlermeldung).
3. Die Karte traegt das neue Feld -- dass die Spalte existiert, heisst
noch nicht, dass die Anwendung sie ausliefert.
4. Und es laesst sich hineinschreiben. Eine nachgeruestete Spalte, in
die nichts geht, waere ein halber Umbau.
Eine Zeile mit Daten ist Pflicht: Ueber eine leere Tabelle laeuft
`talentKarte` gar nicht, und ein „200" bewiese dann nur, dass der Weg
ohne Daten funktioniert.
Gegenprobe (ALTER TABLE ausgebaut): 5 rot, darunter „die Talente-Seite
antwortet mit 503" -- genau der Schaden, den das Nachruesten verhindert.
Dabei stuerzte Abschnitt 4 ab statt rot zu melden; ein Absturz
verschluckt die Zeilen danach und sieht aus wie ein Problem der
Pruefung. Jetzt hat er den dritten Ausgang.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
fabb1f94a8 |
Kalender: was auf den Brettern steht und einen Termin hat
Filipe, zu einer Clip-Karte: "ich will dass die auch in einer kalender
drin sind, aber ich will dass es richtig geil ist und perfektionier das
bitte."
Gemessen vor dem Bau: /workspace/api/termine lieferte `termine` und
`fristen`. Die Zettel von den achtzehn Brettern kamen nirgends vor --
obwohl `eintraege` seit langem VIER Zeitfelder hat: datum, uhrzeit,
geplant, event_ende.
WELCHE HINEINGEHOEREN, IST DIE GANZE FRAGE -- und sie laesst sich
messen statt raten. `datum` ist ein Pflichtfeld und faellt auf HEUTE
zurueck, wenn niemand eins waehlt. Alle Eintraege hineinzukippen hiesse
also: jeder je getippte Zettel steht an dem Tag, an dem ihn jemand
getippt hat. Nach einem Monat waere der Kalender ein Protokoll und kein
Plan -- und ein Kalender, in dem alles steht, sagt nichts mehr.
GEZEIGT WIRD NUR, WOFUER JEMAND EINE ZEIT BESTIMMT HAT:
geplant eine Zusage ("Wird gemacht -- am 24.09.")
event_ende ein Zeitraum
uhrzeit niemand tippt aus Versehen 20:00
datum > heute der Rueckfall ist IMMER heute oder frueher
Erledigtes bleibt draussen. Der vierte Fall ist der wichtigste und der
unauffaelligste: kein neues Feld, keine Umgewoehnung.
RECHTE: dieselbe Funktion wie die Bretter selbst (`sichtbarEintrag`),
nicht eine zweite Meinung. Im Kalender steht nur eine kleine Pille mit
einem Titel -- dass darin ein vertrauliches Vorhaben steckt, faellt
niemandem auf, der nicht danach sucht. Genau so kam am 03.09. eine
Managerin an fremde Aufgabenfristen.
DREI FEHLER AM BILDSCHIRMFOTO GEFUNDEN, nicht an einer Zahl:
1. Der Brettname stand VOR dem Titel -- aus "Clip am Wochenende"
wurde "Cli...". Das Etikett verdraengte, was es einordnen sollte.
Jetzt zweite Zeile: Hoehe ist im Monatsraster der billigere Platz.
2. Am Handy (45px Zellbreite) wurde daraus ein "Co..." -- Hoehe ohne
Information. Jetzt eine CONTAINER-Abfrage: entschieden wird nach
der Breite der ZELLE, nicht des Fensters. Eine Fensterschwelle
waere wieder die Rechnung von gestern (September, Kopfleiste,
zweimal).
3. .64rem = 10,24px -- unter der Hausgrenze 11,5px, gefunden von
pruef-css-klassen. Gedaempft wird jetzt ueber Farbe und Gewicht,
nicht ueber Groesse.
EIN ECHTER FEHLER VERHINDERT: In der Listenansicht waeren die Zettel im
Termin-Zweig gelandet -- mit Wecker, "erledigt" und "loeschen". Der
Knopf haette PATCH /api/termine/b12 geschickt: eine Nummer, die es dort
nicht gibt, an eine Schnittstelle, die davon nichts weiss. Still, ohne
Wirkung, ohne Meldung.
DER WEG FUEHRT AUF DEN ZETTEL, nicht nur auf das Brett -- ueber
`?zeigen=` (kopf.js), den Weg, den das Haus dafuer schon hat. Zwischen
zwanzig Eintraegen waere der gesuchte sonst von Hand zu suchen.
pruef-kalender: +25 Pruefungen. Sieben Gegenproben, jede zielgenau:
Schnitt weg -> 6 rot Erledigtes rein -> 6 rot
Rechteregel ausgehebelt-> 1 rot COALESCE weg -> 1 rot
Termin-Knoepfe an -> 2 rot Container-Regel weg -> 1 rot
Sprung-Zweig weg -> 3 rot
UND SIEBEN FESTE ZAHLEN ABGELEITET. Die alten Pruefungen zaehlten
"alle fünf Einträge", "vier Arten", "vier Filter" -- mit den neuen
Testdaten wurden daraus zehn, und sieben Pruefungen je Bildschirmgroesse
wurden rot, ohne dass am Kalender etwas kaputt war. Mit `git stash`
nachgemessen (ohne meine Aenderung: 0 Fehler), also nicht angepasst,
sondern gerechnet: jede Zahl kommt jetzt aus den Testdaten darueber.
Zwei eigene Pruefungsfehler dabei behoben: ein falscher Umschalter-
Selektor liess `every()` auf einem leeren Feld laufen (gruen ohne
Daten), und die Sichtbarkeit der zweiten Zeile wurde ueber
`textContent` gemessen -- das liefert auch, was `display: none`
ausblendet.
Gruen: kalender, sprung, namen, css-klassen, struktur.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e3e015bca4 |
Kopfleiste: ein Name, der zweimal vergeben war
Filipe zu einem Bildschirmfoto: "was soll das jetzt, wieso sieht das in
gewissen seiten so scheisse aus?!"
Der Teilen-Knopf stand doppelt so hoch wie seine Nachbarn, mit dem
Zeichen UEBER dem Wort statt daneben. Es war kein Gestaltungsfehler,
sondern ein Name: `.teilen` gab es ZWEIMAL --
gate.css Knopf der Kopfleiste inline-flex, waagerecht
bereich.css Layout der Teilen-Seite flex column, 22px, 44rem
Auf den drei Seiten, die beide Dateien laden (bereich, bewerben,
teilen), gewann die spaeter geladene. Der Knopf bekam das Layout einer
ganzen Seite. "Gewisse Seiten" war exakt richtig beobachtet.
DERSELBE NAME KOSTETE AUSSERDEM DEN KNOPF: kopf.js baut ihn nur ein,
wenn `getElementById('teilen')` nichts findet -- ein Schutz gegen
doppelten Einbau. Auf teilen.html steht `<section id="teilen">` aber
schon im HTML. Dort fehlte der Knopf ganz, ohne Spur, ohne Meldung.
REPARIERT ALS REGEL, NICHT ALS EINZELFALL:
- Was kopf.js in die Leiste haengt, traegt jetzt `kopf-` davor
(kopf-teilen, kopf-sicht-wahl, kopf-sicht-feld, kopf-fremd-band).
Eine Seite darf dann heissen wie sie will -- auch "teilen", "chat"
oder "suchen", und genau diese Woerter braucht als naechstes eine
Seite.
- Die Teilen-Seite bekommt eigene Klassennamen (tl-*).
NEU: server/pruef-namen.mjs (12 Pruefungen, ohne Server, <1 s).
Es ist der ZWEITE Namenskonflikt an einem Tag -- der erste war
`.t-schritt` auf der Talente-Seite, gefunden nur durch Zaehlen im
Browser. Beide waren gruen in jeder bestehenden Prueflinie.
Gemessen, um den Schnitt zu finden, der etwas taugt:
2872 Klasse in zwei geladenen Dateien erwaehnt -> Rauschen
1887 davon mit eigener Blockdefinition -> Rauschen
12 davon mit widersprechendem `display`
6 davon ohne `display: none` -> geprueft
Mit Gegenprobe, die aus den Dateien ABGELEITET wird (die erste, fest
abgeschriebene Fassung fand nichts, weil die gewaehlte Klasse dort gar
kein `display` setzt -- eine Gegenprobe, die selbst danebenliegt,
beweist nichts).
pruef-kopf-messen: 3 -> 16 Messungen, und drei eigene Fehler behoben,
die alle dieselbe Form hatten -- zu frueh hingesehen:
1. Sie mass NUR uebersicht.html. Die laedt bereich.css nicht und war
fuer diesen Fehler blind.
2. Sie mass nur 320/390/430px. Unter 720px versteckt gate.css das
Wort "Teilen"; der Knopf bleibt klein, auch falsch angeordnet.
Filipes Bild war 1366px breit.
3. Sie wartete 300ms. kopf.js haengt Teile erst nach `/api/ich` ein
und hat ein Netz bei 1200ms. Zweiter Versuch: warten, bis `#wer`
Text hat -- SOFORT wahr, dort steht `…` als Platzhalter. Dritter:
auf Stabilitaet warten -- nach 0ms und 500ms gleich gross, also
"fertig". Erst die Mindestwartezeit (1200 aus kopf.js plus Luft)
davor machte die Messung echt.
Bewiesen an der Gegenprobe: mit dem alten Fehler meldet sie jetzt
"kopf-teilen ist 77px -- die anderen im Schnitt 43px", vorher blieb sie
gruen.
Statt einer festen Hoehe wird gefragt, ob EIN Teil aus der Reihe faellt
(> 1,6x der Schnitt seiner Nachbarn). Das waechst mit, wenn die Leiste
groesser wird, und muss bei keinem neuen Knopf nachgezogen werden.
Gruen: namen, kopf-messen, sicht, css-klassen, struktur.
Co-Authored-By: Claude Opus 5 <[email protected]>
|