1bdeccc054505c0bd23f209787114a8709f4668a
100
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
1bdeccc054 |
Highlights: drei Accounts nebeneinander, nach Zeit geteilt
DogFather, HasiDog und DogFather Clips haben eigene Zuschauer und einen eigenen Ton -- das steht so schon an KANAELE im Server. Eine gemeinsame Galerie behauptete, sie waeren ein Topf; wer fuer Clips schneidet, suchte in jeder Reihe nach den Kacheln, die ihn angehen. Jetzt drei Spalten nebeneinander, jede zuklappbar, jede mit ihrem Handle und ihrer Zahl. Eine vierte Spalte gibt es nur, wenn sie gebraucht wird: Bilder ohne TikTok-Link gehoeren zu keinem Account, und sie verschwinden zu lassen waere der schlimmere Fehler. Die Reihenfolge kommt vom SERVER. Der Browser hatte dafuer eine eigene kleine Liste (KANAL_WORT) -- dieselben drei Namen in anderer Reihenfolge, ohne Handles. Beim vierten Account waere genau diese Kopie die vergessene. Dazu eine Zeitleiste: Aktuell (heute), Diese Woche, Dieser Monat, Dieses Jahr, Alles. Kalenderzeitraeume, keine Rueckblicke -- wer am Dienstag "diese Woche" fragt, meint Montag und Dienstag. Jeder Knopf traegt seine Zahl; ohne sie klickt man ins Leere und weiss nicht, ob es am Filter lag. Und beim Anlegen laesst sich der Account waehlen -- fuer Bilder und Momente ohne Link. Bei einem TikTok-Link leitet der Server ihn weiterhin aus dem Handle ab; das ist genauer, weil niemand sich vertippen kann. Beim Bauen gemessen statt vermutet: Der Spaltenkasten lag IM Galerie-Raster von #liste und bekam eine Zelle von 376 px -- Elternbreite 1160. Die drei standen untereinander. Die Galerie gehoert jetzt in die Spalte, nicht um sie herum. pruef-highlights.mjs: 26 Pruefungen, mit Gegenproben (Gast bekommt die Liste nicht, erfundener Account wird abgelehnt, zweiter Klick hebt den Filter auf). pruef-video.mjs weiterhin 67/0. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d77dd216c5 |
Ein Termin von-bis belegt jeden Tag dazwischen
Zwei Fehler, nicht einer. Der sichtbare: Die Kachel stand nur am Anfangstag. Wer im Monatsraster auf den Mittwoch sah, sah nichts -- obwohl die Aktion von Montag bis Freitag lief. Der unsichtbare, und der ist der schlimmere: Der SERVER suchte Eintraege, deren ANFANG im sichtbaren Fenster liegt. Eine Aktion vom 28.09. bis zum 05.10. kam im Oktober deshalb ueberhaupt nicht an -- nicht "nur am ersten Tag markiert", sondern gar nicht da. Wer im Oktober plante, sah eine freie Woche, die belegt war. Jetzt entscheidet die UEBERSCHNEIDUNG, nicht der Anfang. Gebaut wurde es in nachTag() -- der einzigen Stelle, an der Eintraege auf Tage verteilt werden. Monat, Woche, Liste und Zeitstrahl holen sich alle dort; vier Ansichten einzeln nachzuruesten waeren vier Stellen, an denen die fuenfte vergessen wird. Das Ende wird abgeleitet, nicht gepflegt: aus event_ende ODER aus Uhrzeit plus Dauer. Ein Live von 22:00 ueber vier Stunden endet um 02:00 am naechsten Tag -- das stand bisher nirgends, obwohl die Zahlen da waren. Der Tagesdialog filterte selbst auf den Anfangstag. Im Raster war der Mittwoch markiert, tippte man ihn an, stand da "An diesem Tag steht nichts." Jetzt fragt er dieselbe Stelle wie das Raster. pruef-zeitraum.mjs: 16 Pruefungen, beide Fehler einzeln, mit drei Gegenproben (vor dem Anfang, nach dem Ende, Punkttermin). pruef-terminregel.mjs weiterhin 35/0. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
947ea7ff49 |
Fertige Vorschlaege lassen sich wechseln
Bisher kamen ALLE auf einmal -- damit gab es nichts zu wechseln, die Liste war entweder ganz da oder ganz weg. Bei 17 Vorschlaegen (Brett "regeln") ist eine Wand aus Karten ausserdem das Gegenteil von "uebernehmen, was passt". Jetzt vier auf einmal, und ein Knopf holt die naechsten vier. Der Server rechnet die Stelle mit Rest -- nach dem letzten kommt wieder der erste. Es gibt also keinen Zustand "durchgeklickt, jetzt leer". Bei hoechstens vier offenen Vorschlaegen erscheint der Knopf gar nicht: Ein Knopf, der dieselben Karten noch einmal malt, ist ein Knopf, der nichts tut. Was es NICHT ist: Die Vorschlaege werden nicht erzeugt. Sie sind ein geschriebener Vorrat von 113 Stueck auf 16 Brettern. pruef-vorschlaege.mjs: 21 Pruefungen. Die entscheidende vergleicht die Titel vorher und nachher -- ein Knopf, der nur gedrueckt werden kann, besteht jede Pruefung, die nur nach dem Knopf sucht. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
c4e26409b9 |
Die Seite laesst sich als App installieren
Das Manifest war lange vollstaendig -- die App LIESS sich installieren. Nur bot das ausschliesslich der Browser an, versteckt in seinem Dreipunktemenue. Wer es nicht sucht, findet es nie. Und ohne installierte App gibt es auf dem Handy keine verlaesslichen Benachrichtigungen; genau daran hing im September das Telefonieren. Jetzt steht der Knopf in der Kopfleiste, auf allen Seiten, mit drei Antworten statt einer: schon installiert -> gar kein Knopf Browser bietet an -> der Knopf fragt ihn Safari am iPhone -> der Knopf erklaert den Weg Der dritte Fall ist der gefaehrliche: Dort gibt es beforeinstallprompt nicht und wird es nicht geben. Ein Knopf, der am iPhone nichts tut, waere schlimmer als keiner -- man drueckt ihn und sucht den Fehler bei sich. pruef-installieren.mjs: 14 Pruefungen, alle drei Zustaende, mit Gegenprobe in der installierten App. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
586eb51504 |
Profilfotos im Chat, rechte Hand zuerst, Karten lesbar
---- SCREEN 9: DIE FOTOS ------------------------------------------- Filipe: "da soll man im chat auch die profilfotos von den leuten sehen wenn die schon eins drin haben." ZWEI Luecken, beide an Stellen, wo ein Feld weggeworfen wurde: 1. Die GESPRAECHSLISTE bekam kein Bild. `teilnehmerVon` liest es aus der Datenbank, die Detailansicht nimmt es mit -- die Zeile fuer die Liste warf es weg. Folge: im offenen Gespraech ein Gesicht, in der Liste daneben ein Buchstabe. Vom selben Menschen. 2. Eine FRISCH GESENDETE Nachricht trug kein Bild. Der Verlauf beim Laden schon. Folge: Wer gerade zusieht, bekommt einen Buchstaben; wer neu laedt, ein Gesicht -- der Unterschied haengt nur daran, wann man geschaut hat. Der Buchstabe bleibt als Unterlage LIEGEN und wird nicht ersetzt: Laedt das Bild nicht, steht dort weiterhin etwas Sinnvolles statt eines kaputten Bildsymbols. Vier Stellen, ein Verhalten. ---- SCREEN 3: REIHENFOLGE UND AUSSEHEN ---------------------------- Filipe: "ich will dass hier wie ueberall die reihenfolge immer rechte hand und dan erst die modis." Die Abfrage sortierte nach `aktiv DESC, name` -- die ROLLE wurde nicht einmal mitgelesen. Die Seite konnte gar nicht wissen, wer rechte Hand ist; sie sortierte alphabetisch, und damit stand Diene vor Funny, weil D vor F kommt. Jetzt mit ROLLEN_SORTIERUNG -- derselben Regel, die auch Personenliste, Chat und Rechtetafel benutzen. "die kiste von rechte hand soll auch noch vieeeeeel krasser und spezieller aussehen ... der hintergrund von den kacheln soll auch viel krasser und geiler sein und so dass man texte und so besser erkennt. weil gerade ist es schwer lesbar." ZUERST DAS LESEN: Der Grund fuer die schlechte Lesbarkeit war der durchscheinende Untergrund -- die Karten lagen auf dem Buehnenbild, und ein Foto wird stellenweise hell. Sie bekommen jetzt eine DECKENDE Unterlage und erst darueber die Verlaeufe. Die Verlaeufe sieht man weiterhin, nur nicht mehr das Bild dahinter. DANN DAS BESONDERE: Die rechte Hand bekommt einen goldenen Ton, eine deutlich hellere Kante und eine schmale Leiste an der linken Seite -- man sieht den Rang aus zwei Metern, ohne ein Wort zu lesen. KEIN zweiter Bauplan: dieselbe Karte, dieselben Felder, nur ein Merkmal am Element. Zwei Karten zu bauen hiesse, jede kuenftige Aenderung zweimal zu machen. ---- EINE PRUEFUNG, DIE EINE POSITION FESTNAGELTE ------------------ `ok(leute[0]?.id === idMarina, "die Aktiven stehen oben")` wurde rot, sobald die rechte Hand nach vorn sortierte. Richtig wurde sie dadurch nicht: Die Aussage "die Aktiven stehen oben" hat mit Marinas Platz nichts zu tun. Jetzt prueft sie die EIGENSCHAFT (keine Pause vor einer Aktiven) -- eine Pruefung, die eine Position festnagelt, verbietet jede Umsortierung, auch die gewollte. GEPRUEFT: pruef-team-stufen 28/0 (zwei Aussagen mehr), pruef-erwaehnung 69/0 (zwei mehr: das Bild kommt in der Liste an, und wer keines hat, bekommt auch keines vorgegaukelt), pruef-css-klassen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
c59517cb23 |
Ein Anruf faengt leise an
Filipe: "uebrigens soll man auswaehlen koennen ob man lautsprecher will oder nicht bitte. es soll ohne lautsprecher anfangen das gespraech und nur wenn man drauf klickt soll es laut werden ... es soll nicht raushaengen oder so, das ist nicht cool." DER GRUND IST DER STREAM. Ein Anruf, der beim Annehmen sofort aus den Lautsprechern kommt, ist im schlimmsten Fall fuer alle Zuschauer zu hoeren, bevor irgendjemand reagieren kann. Das laesst sich nicht zurueckholen. HIER STAND `hoeren = true` mit der Begruendung: "Wer den Ton abgestellt hat, will ihn nicht beim naechsten Gespraech wieder an." Das war richtig gedacht und ist jetzt umgedreht -- aus demselben Grund, nur in die andere Richtung: Der Zustand soll NICHT ueberdauern. Eine Entscheidung von vorhin darf nicht fuer ein Gespraech gelten, von dem man noch nichts wusste. Zurueckgesetzt wird an BEIDEN Wegen, beim Anrufen und beim Rangehen -- einer allein waere die Haelfte, und die andere Haelfte faellt niemandem auf, bis es einmal zu laut war. UND MAN SIEHT ES. Leise anfangen ohne Hinweis waere die naechste Sackgasse: "ich hoere nichts" ohne Grund und ohne Weg. Ein Balken sagt es, solange es gilt, und verschwindet in dem Moment, in dem man den Ton anmacht. Er ist SELBST der Knopf -- wer liest "tippen, um den Ton anzumachen", will genau das tun. Gedaempftes Bernstein statt Alarmrot: Es ist kein Fehler, sondern ein Zustand. DABEI EINEN EIGENEN FEHLER GEFANGEN: Der Balken fragte `!anruf` -- und diese Variable wird erst gesetzt, NACHDEM der Kasten aufgeht. Beim Aufbauen blieb er deshalb versteckt, und man sass in einem stummen Gespraech ohne einen Satz dazu. Genau der Zustand, den er verhindern soll. Jetzt haengt er am sichtbaren Kasten. DIE PRUEFUNG WURDE ROT und hat damit ihre Arbeit getan -- sie hielt das alte Verhalten fest. Umgedreht, nicht gestrichen: Die wichtigste Falle (ueberlebt der Schalter das Neuzeichnen, wenn jemand auflegt?) bleibt, nur der erwartete Zustand hat sich gedreht. GEPRUEFT: pruef-anruf 117/0 (war 114) -- drei Aussagen mehr, darunter dass der Hinweis da ist, 44 px hoch und im richtigen Moment verschwindet. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
01151574ae |
Die rechte Hand verteilt Aufgaben und wechselt Rollen
Filipe: "jeder soll sich selber aufgabe vergeben koennen aber nur die
rechte hand und dogfather aufgaben an andere verteilen." Und: "ich will
dass ich da auch die rollen der leute wechseln kann ohne dass ich denen
einen neuen account machen muss ... perfektionier das fuer die rolle
dogfather und rechte hand."
---- AUFGABEN VERTEILEN ---------------------------------------------
Die Regel gab es schon -- sie fragte `istLeitung`, und darin steht die
rechte Hand NICHT. Sie konnte also keine Aufgabe weitergeben.
`hand` DORT EINZUTRAGEN WAERE FAHRLAESSIG GEWESEN: `istLeitung` wird an
57 Stellen in 19 Dateien gefragt -- unter anderem im vertraulichen
Meldeweg, in der Personenverwaltung und in den Auswertungen ueber
Menschen. Das haette in einem Zug ueber Einsicht in fremde Meldungen
entschieden, und das hat niemand gewollt.
Stattdessen `darfAufgabenVerteilen` -- eine eigene Regel mit eigenem
Namen. Man sieht an der Aufrufstelle, worum es geht, und wer sie
spaeter aendert, aendert genau diese eine Sache.
Wer nicht verteilen darf, bekommt KEINE Absage: Die Aufgabe landet bei
ihm selbst. Das ist genau, was Filipe wollte ("jeder soll sich selber
aufgabe vergeben koennen") und freundlicher als ein Fehler.
---- ROLLEN WECHSELN ------------------------------------------------
Auch das gab es schon, samt dem wichtigen Satz in der Rueckfrage: "Der
Zugangscode bleibt derselbe." Es konnte nur DogFather (und Spicy
Media).
DREI GRENZEN, JEDE MIT GRUND:
* Niemand wird zu "admin" -- unveraendert seit dem 11.09.2026.
* Die rechte Hand ernennt keine zweite rechte Hand. Wer jemanden auf
die eigene Ebene hebt, vergibt Vertrauen, das ihm nicht gehoert.
Und wer eine Rolle UEBER sich aendern koennte, koennte sich selbst
befoerdern, indem er zuerst den anderen herabstuft.
* Niemand aendert die eigene Rolle -- sonst waere jede Grenze nur ein
Umweg.
SPICY MEDIA BEHAELT, WAS SIE HATTE. Beim ersten Anlauf waere sie durch
die neue Regel ausgesperrt gewesen -- ein Rueckschritt, den ich selbst
verursacht haette. Sie steht jetzt ausdruecklich in der Tabelle.
---- UND DIE OBERFLAECHE RECHNET NICHT MEHR SELBST ------------------
Die Rollenwahl nahm die Knoepfe des ANLEGE-Formulars. Fuer die rechte
Hand ist das leer -- sie legt niemanden an. Die Wahl waere leer
geblieben, das Recht unbenutzbar.
Der Server schickt jetzt zwei Listen mit: wozu ich machen darf
(`rollen_zum_aendern`) und wessen Rolle ich anfassen darf
(`rollen_anfassbar`). Beide aus denselben Funktionen wie die Schranke.
Damit kann die Seite weder zu streng sein (ein Recht, das niemand
findet) noch zu grosszuegig (ein Knopf, der eine Absage bringt) -- der
Fehler vom 10.09.2026, als zwei Listen drei Zeilen auseinander
einander widersprachen.
Dabei fast hineingelaufen: `ROLLEN_REIHE` ist die SORTIERUNG, und
darin fehlt "gast" mit Absicht. Wer sie fuer eine Aufzaehlung nimmt,
verliert die Community still -- genau diese Verwechslung hat am
17.09.2026 schon einmal verhindert, dass sich jemand zu "Community"
machen liess.
---- AUSSERDEM ------------------------------------------------------
Screen 2: "Unsere Seiten" und "Regeln & Hilfe" haben die Plaetze
getauscht -- nur diese zwei.
GEPRUEFT: pruef-verteilen 11/0 (neu, inkl. der Abgrenzung "darf
verteilen, ist aber NICHT Leitung"), pruef-rollen-anlegen 11/0,
pruef-personen-formular 36/0, pruef-personen-liste 33/0,
pruef-personen-loeschen 40/0, pruef-rechtetafel 19/0, pruef-treff 72/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e378514bb4 |
Einmal anmelden reicht -- und beim Zurueckgehen bleibt die Seite stehen
Filipe: "kannst du bitte machen dass die leute sich nur einmal anmelden
muessen und dan nur noch abgemeldet werden wenn sie sich selbst
abmelden. damit sie auch die benarichtigungen sofort kriegen ... und
auch sofort die anrufe annehmen koennen."
---- 1. DIE ANMELDUNG BLEIBT ----------------------------------------
VORHER: zwoelf Stunden, feste Frist ab dem Anmelden. Wer morgens um
acht anfing, flog abends um acht raus -- mitten im Betrieb. Und wer
abgemeldet ist, hat die Seite nicht offen; ein Anruf erreicht ihn dann
nur noch ueber die Benachrichtigung, und bis er sich wieder angemeldet
hat, ist das Klingeln vorbei. Genau das beschreibt Filipe.
JETZT: ein gleitendes Fenster von 180 Tagen, das sich bei jeder Nutzung
verlaengert. Wer die Seite benutzt, bleibt angemeldet -- ohne Ende.
NICHT UNENDLICH, und das ist Absicht: In diesem Haus liegen
vertrauliche Meldungen ueber Menschen. Ein Zugang, der nie ablaeuft,
ist auf einem verlorenen Handy fuer immer offen. Ein halbes Jahr ohne
Besuch schliesst das Geraet und ist niemandem zu viel zugemutet.
An EINER Stelle gebaut: `sitzungLesen` -- durch die gehen alle 26
Fachmodule. Ein Parameter mehr haette 26 Aufrufe geaendert und beim 27.
Modul vergessen werden koennen; `req.res` haengt ohnehin an der
Anfrage. Verlaengert wird erst, wenn weniger als die Haelfte des
Fensters uebrig ist -- sonst waere das ein Schreibzugriff bei jedem
Bild und jedem Herzschlag des Ereignisstroms.
Drei Texte, die noch "zwoelf Stunden" behaupteten, sagen es jetzt
richtig -- inklusive der Abmelde-Nachfrage, die jetzt dazusagt, dass
man angemeldet bleiben SOLLTE, um Anrufe zu bekommen.
---- 2. BEIM ZURUECKGEHEN BLEIBT DIE STELLE -------------------------
Filipe, zum dritten Mal und in Grossbuchstaben. Also erst gemessen:
gescrollt auf: 900
gemerkt: 900
gelandet: 1054 <- 154 px daneben, zuverlaessig
Die Wiederherstellung LIEF also -- sie traf nur nicht. Ursache ist
Chromes Scroll-Verankerung: Waechst Inhalt OBERHALB der Stelle,
verschiebt der Browser den Bildlauf mit, damit das Sichtbare stehen
bleibt. Im Alltag genau richtig; beim Wiederherstellen das Gegenteil.
Sie wird jetzt fuer die Dauer des Wiederherstellens abgeschaltet und
danach wieder eingeschaltet -- nicht dauerhaft, sonst spraenge einem im
Chat der Text unter dem Finger weg. Dazu wird die Stelle nachgesetzt,
solange die Seite noch waechst, und aufgehoert, sobald sie 400 ms lang
ruhig ist. Ergebnis: 900 -> 900, und es bleibt dort.
DAZU, und das ist der groessere Teil: Der Ereignisstrom in kopf.js
laeuft auf 32 Seiten und wird jetzt beim Weggehen geschlossen. Eine
offene EventSource sperrt den Vor-/Zurueck-Speicher des Browsers aus --
deshalb wurde bisher JEDE Rueckkehr ein vollstaendiger Neuaufbau.
Filipe hat genau das beschrieben ("OHNE DASS DIE SEITE ... NEU LAEDT").
EHRLICH DAZU: Playwright schaltet diesen Speicher fuer Tests ab, und er
liess sich hier nicht einschalten. Ich kann also NICHT messen, dass er
jetzt greift -- die Aenderung ist trotzdem richtig (eine offene
Verbindung ist die dokumentierte Sperre, und ein Strom, der beim
Weggehen offen bleibt, ist ohnehin ein Zuhoerer, den niemand mehr
liest). Gemessen und abgesichert ist der Weg OHNE diesen Speicher --
also der schlechteste Fall.
---- 3. DABEI GEFUNDEN: pruef-schranke mass seit neun Tagen nichts --
Sie suchte `const GESCHUETZT = {` per Textmuster in workspace.js. Diese
Tabelle ist am 11.09.2026 nach rechte.js umgezogen -- seitdem fand das
Muster nichts, und die Pruefung meldete "0 geschuetzte Seiten", "alle 0
Seiten leiten um", "0 Schreibweisen ausprobiert". Drei rote Zeilen, die
nach einem Zaehlfehler aussahen und in Wahrheit hiessen: hier wird
nichts mehr geprueft.
Jetzt wird die Tabelle IMPORTIERT. Ein Textmuster auf fremden
Quelltext reisst beim naechsten Umzug still; ein import reisst laut.
Ergebnis: 33 geschuetzte Seiten, 363 Schreibweisen -- alles gruen.
GEPRUEFT: pruef-rollstelle 8/0 (neu, mit Spur ueber die Zeit und zwei
Gegenproben), pruef-schranke (war rot), pruef-code 17/0,
pruef-haerte 20/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
75019ec8c3 |
Am Handy stand nicht da, mit wem man schreibt
Gemessen in der Kopfzeile eines Gespraechs, Name "Team-Runde":
360 px -> 0 px sichtbar (98 noetig)
390 px -> 12 px
412 px -> 33 px
1280 px -> passt
Auf JEDEM Telefon stand also kein Name da -- man oeffnet ein Gespraech
und sieht nicht, mit wem. Und weil die Zeile nicht leer aussieht
(Zurueck-Pfeil, fuenf Knoepfe), wirkt sie nicht kaputt, sondern eng.
URSACHE: `flex: 1` heisst ausgeschrieben `1 1 0%` -- Grundbreite NULL.
Damit "passt" der Name rechnerisch immer, egal wie eng es ist, und es
bricht nie etwas um. Die Knopfreihe daneben hat `flex: none` und
schrumpft nie; seit die Knoepfe am Finger 44 px breit sind, bleibt bei
sechs Knoepfen nichts uebrig.
Zwei Stellen setzten dieselbe Eigenschaft, die spezifischere gewann --
die erste Reparatur wirkte deshalb nur bei 360 px und sonst nicht.
Beide nennen jetzt dieselbe Grundbreite.
KEINE NEUE SCHWELLE: `flex-wrap` bricht genau dann um, wenn der Platz
wirklich nicht reicht. Dieses Haus ist an festen Breiten schon zweimal
gescheitert (Kopfleiste, 06.09.2026); kommt morgen ein siebter Knopf
dazu, stimmt es weiter. Ergebnis: 244 / 268 / 289 px statt 0 / 12 / 33.
---- WARUM DER HANDY-RUNDGANG DAS NICHT GEFUNDEN HAT ----------------
Zwei eigene Entscheidungen, jede fuer sich vernuenftig, zusammen ein
Loch:
1. `sichtbar()` verlangt `width > 0`. Ein auf null gequetschtes
Element ist unsichtbar -- und "unsichtbar" hiess "nichts zu
pruefen". Genau falsch herum: Nichts zu sehen IST der Befund.
2. `text-overflow: ellipsis` gilt als Absicht. Das stimmt auch --
ein langer Name soll gekuerzt werden. Es stimmt nur nicht mehr,
wenn nichts uebrig bleibt.
Die neue Regel ist bewusst schmal: gemeldet wird nur, was unter 40 px
sichtbar ist und mindestens das Doppelte braeuchte. "Jede Kuerzung
melden" waeren die ~350 Fehlalarme, die diese Pruefung schon einmal
zugedeckt haben.
NACHGEMESSEN: 206 Seitenaufrufe, 91 638 Elemente. Die Regel schlaegt
an genau EINER Stelle an (kalender.html, sechsmal) und sonst nirgends
-- 64 -> 70 Befunde. Die Pruefung ist genauer geworden, nicht die App
schlechter.
DER KALENDER-FUND BLEIBT OFFEN: Im Monatsraster ist ein Tag am Handy
36 px breit, ein Eintrag braucht 186 bis 317. Das ist kein Versehen im
Code, sondern die Frage, ob die Monatsansicht am Telefon ueberhaupt
die richtige Vorgabe ist -- eine Entscheidung, keine Reparatur.
GEPRUEFT: pruef-chat-optik 39/0 (drei neu, mit einer Gegenprobe, die
den gemessenen Fall HERSTELLT -- fuenf Knoepfe wie in einer Gruppe;
der erste Anlauf blieb gruen, weil in einem Zweiergespraech nur drei
stehen und der Platz auch ohne Reparatur reicht: 12 px mit der alten
Angabe, 268 mit der neuen, im selben Aufbau).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2a26a49f91 |
Mit "@" jemanden im Chat ansprechen
Filipe: "ich will das man die leute mit @ markieren kann im chat."
MARKIEREN IST KEINE FARBE, SONDERN EINE ANSPRACHE. Sie funktioniert
nur, wenn drei Dinge zusammen stimmen: Der Richtige ist gemeint, er
MERKT es, und man sieht es im Satz. Fehlt eines davon, ist es eine
Attrappe -- und zwar eine, die gut aussieht.
WER GEMEINT IST, ENTSCHEIDET DER SERVER. Der Browser schickt nur Text.
Damit wirkt ein von Hand getipptes "@VanVan" genauso wie eines aus der
Auswahlliste, und niemand kann jemanden ansprechen, der gar nicht im
Raum sitzt -- auch nicht ueber die Schnittstelle.
Die Regeln stehen in server/chat-erwaehnung.js, jede mit Begruendung.
Zwei davon sind keine Feinheit, sondern der Unterschied zwischen
brauchbar und laestig:
* Das Zeichen VOR dem "@" darf kein Buchstabe sein. Sonst piepst
jede E-Mail-Adresse im Chat jemanden an
("[email protected]").
* Das Zeichen DANACH auch nicht, und der laengste Name gewinnt.
Sonst spricht "@Tilikum" Tili an.
MAN MERKT ES AUCH OHNE OFFENEN RAUM. Eine Zahl in der Gespraechsliste
sagt "hier ist etwas" -- nicht, ob es an dich war. Wer morgens vier
Raeume mit Zahlen sieht, macht den lautesten zuerst auf, und dort
steht selten das, was auf ihn wartet. Jetzt steht ein "@" daneben.
UND DIE MELDUNG AUFS HANDY SAGT ES: "VanVan hat dich erwaehnt" statt
"Nachricht von VanVan". Als EIGENE Art, die sich getrennt abschalten
laesst -- wer den lauten Chat stumm stellt, will trotzdem wissen, wenn
ihn jemand direkt anspricht. Ohne Ausnahme von der Ruhezeit: Ein Anruf
wartet auf eine Antwort, ein "@Anna" nicht.
DIE AUSWAHL BEIM TIPPEN loest drei Dinge, die man sonst selbst wissen
muesste: wie die Person genau heisst, wer ueberhaupt im Raum ist, und
ob man sich vertippt hat. Tastatur zuerst (Pfeile, Enter, Tab, Escape).
Sie erzwingt nichts -- wer weitertippt, schreibt einfach weiter.
ZWEI RECHNUNGEN, EINE ANTWORT: Der Browser braucht dieselbe Aufloesung,
um sofort hervorzuheben. Genau dort laufen Dinge auseinander, und dann
haette die Seite jemanden hervorgehoben, den niemand benachrichtigt
hat. pruef-erwaehnung LIEST die Browserfassung aus der Datei und fuehrt
sie aus -- ein Nachbau wuerde pruefen, ob ich zweimal dasselbe
schreiben kann.
---- DABEI GEFUNDEN: "gelesen bis 999999" ----------------------------
Der Server nahm fuer den Lesestand JEDE ganze Zahl an. Wer einmal eine
Zahl hinter allem Vorhandenen schickte, sah in diesem Gespraech nie
wieder einen Zaehler und nie wieder ein @-Zeichen: Alles Kuenftige galt
als gelesen, bevor es geschrieben war. Das faellt niemandem als
Zusammenhang auf -- man merkt nur, dass "die Benachrichtigungen nicht
gehen".
Der Browser schickt heute immer die letzte gesehene Nummer, ist also
nicht der Grund. Aber eine Grenze, die nur davon lebt, dass der
Aufrufer sich benimmt, ist keine. Jetzt wird auf die juengste
Nachricht des Raums begrenzt -- abgeleitet, nicht geraten.
Gefunden hat es meine eigene Pruefung: Sie setzte zum Aufraeumen 99999
und wunderte sich danach, warum das frische "@" nicht leuchtete.
WOHER MAN ERFAEHRT, DASS ES DAS GIBT: Im Chat gibt es keinen
Hilfeknopf. Der Hinweis steht deshalb im Leersatz einer neuen Gruppe --
dort, wo man beim ersten Oeffnen ohnehin hinsieht, und nur ab drei
Leuten. In einem Zweiergespraech waere er Ballast.
GEPRUEFT: pruef-erwaehnung 67/0 (neu) -- 13 Regelfaelle ohne Server,
der Weg durch die Schnittstelle, das Zeichen in der Liste samt
Gegenprobe bei jemandem, der dabei aber nicht gemeint war, beide
Aufloesungen nebeneinander, und der ganze Ablauf am echten Bildschirm
bis "Enter waehlt und schickt NICHT ab".
Dazu pruef-chat 48/0, pruef-chat-optik 36/0, pruef-treffchat 110/0,
pruef-chat-kanaele 79/0, pruef-glocke 31/0, pruef-push 24/0,
pruef-anruf-klingelt, pruef-css-klassen, pruef-meldungen,
pruef-nachfrage, pruef-tippziele.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
409ed551f3 |
"Review" heisst jetzt "Zur Freigabe" -- und Datumsfelder sind so hoch wie alle anderen
Im Code stand die Begruendung selbst: "«Review» allein sagt einem Neuen nichts." Das Wort ist englisch, ein Hauptwort ohne Handlung, und es verraet nicht, WER jetzt dran ist. "Zur Freigabe" sagt beides: fertig von mir, wartet auf jemanden. Geaendert wurde nur, was ein Mensch LIEST -- der Zustandsschluessel bleibt `review`, der gehoert der Datenbank. Betroffen: Spalte und Weiterknopf im Aufgabenbrett, Dateien-Filter, Startseiten-Zaehler, Kachel-Unterzeile, Hinweis "Datei wartet auf Freigabe", Report. NICHT geaendert: der Kalender. Dort ist `review` eine TERMINART (ein Gespraech, in dem man zurueckschaut), kein Zustand. Ich hatte das beim Umbenennen selbst verwechselt und wieder zurueckgenommen -- ein Kommentar an der Stelle haelt die zwei Bedeutungen jetzt auseinander. pruef-sprung hing an der Wortwahl (`/review/i` auf der Beschriftung) und wurde rot, obwohl der Filter richtig stand. Sie prueft jetzt `data-status` -- den Schluessel, der sich nicht mit der Sprache aendert. DAZU, unabhaengig gefunden: Datumsfelder waren 48 px hoch, alle anderen Felder 44. Gemessen auf drei Seiten bei 390 px. Alle liegen auf dem 44-px-Beruehrziel -- nur das Datumsfeld drueckte sich darueber, weil Chromium in `::-webkit-datetime-edit` eine eigene Innenpolsterung setzt, die sogar ein gesetztes `height: 44px` ueberstimmt. Zwei Anteile, einzeln nachgemessen (jeder allein 48->46, erst beide zusammen 48->44): 1 px Polsterung oben und unten im Feldkasten, und eine Zeilenhoehe von 24 statt 22. Keine feste Hoehe gesetzt -- die Zeilenhoehe wird aus Beruehrziel und Polsterung gerechnet, damit sie mitwandert, wenn sich eines davon aendert. Geprueft: pruef-formulare 19/0 (war 16 mit 3 Fehlern), pruef-sprung 43/0, pruef-start-ansicht 151/0, pruef-aufgabenbrett 49/0, pruef-uebersicht 35/0, pruef-uebersicht-browser 20/0, pruef-deutsche-texte, pruef-css-klassen. Ausserdem: vorlagen.js geloescht (8,2 KB). `vorlagenBlock(` wurde in |
||
|
DogFatherGit
|
0f5faf7ee6 |
Eine Seite, die nicht laedt, sagt es -- und bietet einen Weg zurueck
Fuenf Suchlaeufe parallel, ihre Funde selbst nachgemessen und behoben.
DER GROESSTE: 13 VON 21 SEITEN SCHLUCKTEN JEDEN NETZFEHLER.
Jede Seite beginnt mit `try { await hole('/api/ich') } catch { return; }`.
Faellt das Netz aus -- Aufzug, U-Bahn, Funkloch --, bricht der Block ab,
und die Seite bleibt fuer immer auf "wird geladen …" stehen. Gemessen:
0 von 32 Stellen setzten `aria-busy` im Fehlerfall zurueck, und es gab
KEINEN EINZIGEN "Nochmal versuchen" auf allen 21 Seiten.
Im Code stand der richtige Satz dazu -- an genau einer Stelle:
"Ein Platzhalter, der nie ersetzt wird, ist eine Luege mit
Fortschrittsanzeige." Er galt ueberall ausser dort.
Neu: window.ladefehler() in meldung.js. Sie ersetzt alles, was gerade
"laedt", durch drei Dinge: was los ist, was das bedeutet, und einen
Knopf, der es noch einmal versucht -- ohne die Seite neu zu laden.
21 Dateien angeschlossen. Neu: server/pruef-ladefehler.mjs, 26/0, mit
abgeklemmtem Netz im echten Browser.
UND DIE STARTSEITE WARF BEI EINEM FUNKLOCH AUF DIE ANMELDUNG.
`catch { location.assign('/workspace/') }` -- der Mensch glaubt, er sei
rausgeworfen, und tippt seinen Code neu. Dabei haelt seine Sitzung 12
Stunden; nur die Anfrage kam nicht durch. Umgeleitet wird jetzt nur
noch bei einer ANTWORT, die das sagt (401).
DER ANMELDEHINWEIS FUEHRTE MODIS IN DIE SPERRE.
Nach zwei Fehlversuchen stand: "Stimmt die Auswahl oben? Ein Code
gehoert immer zu genau einer davon." Auf der Crew-Wand ist das FALSCH
-- `stillerZugang()` sucht ueber die Codekennung, die angetippte
Kachel spielt fuer hand/modi keine Rolle. Sie probieren alle vier
durch, sammeln vier Fehlversuche, und nach acht in zehn Minuten ist
ihre Adresse gesperrt. Ein Hinweis, der die Sperre herbeifuehrt, gegen
die er helfen soll. Auf der Agenturwand stimmt der Satz weiter --
deshalb wird gefragt, auf welcher Wand man steht.
Dazu: Die Crew-Wand nannte nur der Community einen Weg ("Frag im Live
nach"). Wer zum Team gehoert und dessen Code nicht geht, fand dort
niemanden.
SACKGASSE AUF DER KERNSEITE EINES MODI.
treff-moderation sagte: "Zugaenge legst du in 'Personen & Zugaenge'
an" -- eine Seite, die ein Modi nicht oeffnen darf. Am ersten Tag, bei
leerer Community, war das der einzige Satz im Abschnitt. Jetzt fragt
die Seite ueber `window.__ich.seiten`, ob es den Weg fuer DIESEN
Menschen gibt. Und ein 404 wirft ihn nicht mehr wortlos auf die
Startseite.
TOTE KNOEPFE AN FREMDEN KARTEN.
"◀ zurueck" und "▶ In Arbeit" standen an JEDER Aufgabenkarte, auch an
fremden. Ein Modi sieht das Brett des ganzen Teams; er tippt, der
Server lehnt mit 403 ab, und die Meldung erscheint GANZ OBEN. Bei
einer Karte weiter unten sieht er nichts. Zwei Zeilen tiefer stand die
Regel im Klartext: "niemandem etwas anzubieten, das dann abgelehnt
wird." Der Server schickt jetzt `darf_aendern` mit.
13 STELLEN ROLLTEN GEGEN DEN WILLEN DES NUTZERS.
`scrollIntoView({ behavior: 'smooth' })` beachtet "Animationen
reduzieren" NICHT. Wer das eingestellt hat, hat es meist wegen
Schwindel getan. Zwei Stellen fragten vorher, dreizehn nicht.
Jetzt `window.sanft()`, einmal statt dreizehnmal.
DAS WORT UEBER DEN BRETTERN EINES MODI HIESS "BETREUUNG".
Fest im HTML, ueberschrieben nur bei Brettern mit eigenem `ober` --
sechs haben keines. Jetzt faellt es auf die GRUPPE der Kachel zurueck,
ueber die er hergekommen ist. Je Rolle richtig, ohne zweite Liste.
DER HINWEIS-ZU-KACHEL-WEG WAR DOPPELT KAPUTT.
`bereichZu` suchte nur in GRUPPEN -- der Liste der AGENTUR. Die
Kacheln von Team Dogi schickt der Server; fuer einen Modi fand die
Zeile entweder nichts oder eine fremde Kachel und uebernahm deren
Farbe. Und sie suchte ueber den NAMEN: "LIVE-Analyse" heisst auf der
Crew-Adresse "Live-Ablauf". Beim Beheben erst den Namen umgedreht --
und damit die Agenturseite kaputt gemacht (pruef-start-ansicht sofort
rot). Jetzt ueber das ZIEL, das in beiden Haeusern dasselbe ist.
UND EIN BRETT WAR SEIT GESTERN GESPERRT.
`TREFF_BRETTER` wird aus Kachelzielen abgeleitet. Als die Kachel
"Regeln & Hilfe" am 19.09. auf `treff-regeln.html` umgelenkt wurde,
fiel `regeln` heraus -- und `treff-regeln.html` verweist weiterhin
darauf ("Haeufige Fragen stehen auf dem Brett Regeln & Hilfe").
Gefunden hat es pruef-treff, die seit gestern rot war. 72/0.
NEBENBEI 7 SEITEN LEICHTER: meldung.js wird jetzt abgeleitet
eingebunden -- nur dort, wo sagWas/ladefehler/sanft wirklich
gebraucht werden. Die Anmeldewand traegt es nicht mehr.
Gruen: pruef-ladefehler 26/0, pruef-sackgassen 11/0 (582 Wege, 0 ins
Leere), pruef-start-ansicht, pruef-treff 72/0, pruef-treffchat,
pruef-community-sicht 10/0, pruef-aufgabenbrett, pruef-code 17/0,
pruef-chat-optik, pruef-nachfrage 49/0, pruef-meldungen 8/0,
pruef-css-klassen, pruef-tippziele 11/0, pruef-leerzustand 13/0,
pruef-rechtetafel.
|
||
|
DogFatherGit
|
cc39552b4f |
Eine Eingabe geht nicht mehr wortlos verloren
Filipe: "Was passiert, wenn jemand eine Funktion abbricht?" GEMESSEN: Acht Dialoge im Workspace enthalten Eingabefelder -- "Aufgabe bearbeiten" (10 Felder), der Tageseintrag in der Leistung (8), Ziele, Netzwerk, Import, ein neuer Chat-Raum, ein Creator. Bei allen galt: Esc, Klick daneben oder "Abbrechen" wirft ALLES weg, wortlos. Wer zehn Felder ausgefuellt hat und mit dem Daumen den Rand trifft, faengt von vorn an. Neu: window.verwurfWache() in nachfrage.js. BEIDE SCHLIESSWEGE, denn sie laufen verschieden: Esc / Klick daneben loest `cancel` aus, close() wird NICHT gerufen "Abbrechen"-Knopf ruft close(), loest kein `cancel` aus Wer nur einen abfaengt, hat eine halbe Sicherung -- und die ist schlimmer als keine, weil man ihr vertraut. NICHT VON HAND VERTEILT: Jeder Dialog mit Feldern bekommt sie automatisch (ausser dem Nachfrage-Dialog selbst -- er wuerde beim Schliessen nach sich selbst fragen, in sich selbst, und haenge fuer immer). Wer morgen einen neunten baut, hat sie, ohne daran zu denken. UND SIE FRAGT NUR BEI WIRKLICHER AENDERUNG. Beim Oeffnen wird ein Abbild der Felder genommen, beim Schliessen verglichen. Wer einen Dialog aufmacht und gleich wieder zu, merkt nichts. ZWEI SACHEN BEIM BAUEN GEMESSEN STATT VERMUTET: MEINE EIGENE "ROBUSTHEIT" HAT DIE WACHE STILL AUSGESCHALTET. Gegen den Fall "Felder werden erst nach dem Oeffnen gefuellt" hatte ich einen zweiten Schnappschuss beim Hineinklicken (`focusin`) eingebaut. Gemessen: Der entstand NACH dem Tippen -- Fokus und Werteingabe passieren im selben Atemzug. `beimOeffnen` war danach gleich dem getippten Text, und der Dialog ging wortlos zu. Die Sicherung sah eingebaut aus und tat nichts. Jetzt wird im naechsten BILD nachgetragen: Was das Skript beim Oeffnen nachtraegt, ist drin; getippt haben kann in derselben Sechzehntelsekunde niemand. (Nachgemessen: Alle acht Dialoge fuellen heute VOR showModal.) ZWEIMAL ESC HINTEREINANDER SCHLIESST TROTZDEM. Das ist Chromiums "close watcher": Eine Seite darf den Nutzer nicht mit Esc einsperren. Die Regel ist richtig; dagegen anzubauen waere falsch. Sie steht deshalb im Code und in der Pruefung -- festgehalten, nicht umgangen. Der Knopf unterliegt ihr nicht, und am Handy gibt es ohnehin kein Esc. Elf Speicherwege rufen `vergessen()`, damit nach erfolgreichem Speichern nicht gefragt wird. Eine Warnung nach dem Speichern waere genau die, die man wegklickt -- und danach auch die echte. pruef-nachfrage 49/0 (war 33), davon zehn am Bildschirm: unberuehrt geht er ohne Nachfrage zu nach einer Aenderung fragt Esc nach, der Dialog bleibt offen "Weiter bearbeiten" laesst ihn offen UND der Text steht noch da auch der Abbrechen-Knopf fragt -- jedes Mal "Verwerfen" schliesst wirklich, und der Text steht nirgends pruef-aufgabenbrett, -leistung, -uebersicht-browser, -chat-optik, -css-klassen gruen, pruef-tippziele 11/0. |
||
|
DogFatherGit
|
285038f400 |
Der vertrauliche Meldeweg vergisst jetzt -- und sagt, bis wann
Zwei Entscheidungen, die offenstanden. Beide getroffen, nachdem
gemessen war, was wirklich da ist.
1. WIE LANGE BLEIBEN ABGESCHLOSSENE FAELLE? 90 Tage.
Die Entscheidung war bereits getroffen: `AUFBEWAHRUNG_TAGE = 90` steht
seit dem 19.09. in hilfe-tabellen.js, mit Begruendung ("ein Fall kommt
manchmal wieder auf"). Nur hat sie NIEMAND durchgesetzt --
`hilfeAufraeumen()` gab es, und der einzige Aufrufer war ihre eigene
Pruefung. Der Kommentar darueber behauptete "Wird beim Start
aufgerufen (siehe index.js)"; das war nie wahr.
Jetzt steht die Regel in workspace-aufbewahrung.js, dem Loeschkonzept,
das sich selbst durchsetzt -- beim Start und danach taeglich. Die
zweite Fassung in workspace-hilfe.js ist WEG, nicht doppelt: Zwei
DELETEs auf dieselben Daten waeren morgen verschieden, und der
Unterschied fiele erst auf, wenn er zaehlt.
GEMESSEN VOR DEM EINSCHALTEN:
In der echten Datenbank steht heute KEIN einziger Fall. Der erste
Lauf loescht nichts, und der erste Fall kann fruehestens in drei
Monaten 90 Tage alt werden. Jetzt einschalten ist frei -- spaeter
waere es der riskante Moment gewesen.
PRAGMA foreign_keys steht im Dienst auf 1, und hilfe_nachrichten
traegt ON DELETE CASCADE. An einem echten Fall mit Nachricht
nachgemessen: vorher 1/1, nachher 0/0. Ohne diese Messung waere
der Fall verschwunden und der eigentliche Text liegengeblieben.
2. SOLL EIN GESCHLOSSENER FALL WIEDER ZU OEFFNEN SEIN? Nein.
Im Kopf von workspace-hilfe.js steht: "EIN GESCHLOSSENER FALL IST
GESCHLOSSEN. Auch fuer die Leitung -- sonst ist 'zugemacht' eine
Meinung und keine Tatsache." Das ist eine gute Regel, und sie bleibt.
Nachgemessen, dass sie auch traegt: Ein Melder kann seinen
geschlossenen Fall weiter LESEN, und ein geschlossener Fall zaehlt
nicht gegen das Limit von drei offenen. Wer eine Wiederholung melden
will, kann das also jederzeit -- die Bauweise ist stimmig.
NUR WUSSTE DAS NIEMAND. Dort stand ein Satz: "Dieser Fall ist
abgeschlossen (Datum)." Jetzt stehen drei -- und sie beantworten die
drei Fragen, die man in dem Moment hat:
Kann ich noch schreiben? Nein, und er laesst sich nicht oeffnen.
Bleibt das hier stehen? Bis zum TT.MM.JJJJ, dann geloescht.
Und wenn es wieder passiert? Neu melden, der alte zaehlt nicht mit.
Das Datum kommt vom Server (`lesbar_bis`), die Frist ebenso -- sie
steht nur an EINER Stelle. Und sie steht jetzt auch im Dialog BEIM
Schliessen: Wer eine Uhr startet, soll das vorher wissen, nicht
danach.
OHNE UHRZEIT, und das ist kein Schoenheitsgrund: Ein Fall, der am
20.09. um 14:04 (Sommerzeit) geschlossen wird, verfaellt 90 Tage
spaeter um 13:04 -- die Uhr wird dazwischen zurueckgestellt. Richtig
gerechnet, sieht aus wie ein Fehler. Wer eine Stunde sucht, die es
nicht gibt, hat Zeit verloren.
UND DIE URSACHE, DAMIT ES NICHT WIEDER PASSIERT:
hilfe_faelle kam am 19.09. dazu, das Loeschkonzept ist vom 15.09., und
nichts hat die beiden je verglichen. Neue Pruefung in
pruef-aufbewahrung: Jede Tabelle mit einer Spalte, die "hier ist etwas
zu Ende" sagt, MUSS im Konzept stehen.
Kein "jede Tabelle muss drinstehen": 46 Tabellen, 41 mit
Personenbezug -- das gaebe 38 Meldungen, von denen fast alle falsch
waeren (sie sind ueber personen_geloescht gedeckt). Eine Pruefung,
die 38-mal meldet, wo einmal richtig waere, wird abgeschaltet.
Gesucht wird das schmale Merkmal: GENAU ZWEI Tabellen im Haus tragen
so eine Spalte. Beide jetzt im Konzept -- hilfe_faelle mit Frist,
aufgaben ausdruecklich OHNE (erledigte Aufgaben sind
Arbeitsdokumentation, keine Meldung ueber einen Menschen).
pruef-hilfe 84/0 (war 59) -- darunter zehn neue am Bildschirm:
"drei Saetze statt einem", "sie stehen untereinander, nicht
nebeneinander" (ein <p> in einem <p> waere ungueltig, der Container
ist jetzt ein <div>), "und WANN, mit Datum".
pruef-aufbewahrung 45/0 (war 41), mit Gegenprobe.
|
||
|
DogFatherGit
|
9e9ed67c4a |
Keine Sackgassen -- fuer JEDE Rolle, nicht nur fuer den Gast
Filipe: "Es darf keine Sackgassen geben."
pruef-community-sicht prueft genau das -- aber nur fuer den GAST.
Ein Modi hat 25 Kacheln, eine rechte Hand 30, DogFather 39. Keine
dieser drei Rollen war je darauf geprueft worden, ob ihre Seiten auf
etwas verweisen, das sie nicht oeffnen darf.
Und genau dort ist es zweimal passiert: Am 19.09. warf "Klingelt
nichts?" ALLE DREI Team-Rollen auf die Startseite zurueck, und der
Kalender-Verweis fuehrte die Community seit jeher ins Leere. Beides
hat jemand zufaellig gefunden, nicht eine Pruefung.
Neu: server/pruef-sackgassen.mjs -- 11/0.
4 Rollen, 126 Seitenansichten, 582 sichtbare Wege, 0 ins Leere.
DREIMAL ABGELEITET STATT AUFGEZAEHLT:
Die ROLLEN kommen aus der Anmeldewand (data-rolle), nicht aus einer
Liste. Kaeme eine fuenfte dazu, stuende sie sonst nicht drin und
niemand wuerde es merken.
Die SEITEN kommen aus der Rechtetafel -- derselben, nach der der
Server entscheidet. Keine zweite Liste, die auseinanderlaufen kann.
Die BRETTER hinter bereich.html kommen aus den Kacheln dieser Rolle.
Die Altersbestaetigung des Gastes wird an der ANTWORT erkannt
(400 + alter_offen), nicht an der Rolle: Eine Liste "wer bestaetigen
muss" waere morgen falsch, wenn die Schranke noch woanders gilt.
Und sie braucht weder HTTPS-Front noch umgebogenen Namensdienst: Das
Haus einer Person kommt aus ihrer ROLLE, nicht aus der Adresse. Ein
Modi ist auch auf 127.0.0.1 im Crew-Haus.
GEGENPROBE: Ein erfundener Weg auf eine gesperrte Seite wird gefunden.
Ohne sie waere "0 ins Leere" auch dann wahr, wenn nichts geladen haette
-- deshalb steht die Zahl der Wege zusaetzlich in der Bedingung.
|
||
|
DogFatherGit
|
0a2363374c |
Eine Nachricht, die nicht ankommt, sieht man jetzt -- und schickt sie neu
DER KOMMENTAR STAND DA, DIE SACHE NICHT. Im Chat stand woertlich: "NICHT STILL VERSCHWINDEN LASSEN. Wer etwas schreibt und es sieht, glaubt, es sei angekommen." Gemessen: `markiereAlsGescheitert` setzte `n.gescheitert = true` -- und gelesen hat das Merkmal NIEMAND, weder das Skript noch das CSS. Eine gescheiterte Nachricht sah exakt aus wie eine zugestellte. Im CSS stand an der Stelle eine leere Regel mit dem Kommentar "Platzhalter, damit :has unterstuetzt bleibt". Ein Kommentar, der eine Absicht beschreibt, erfuellt sie nicht. Jetzt: sichtbare Kante an der Blase, blasse Darstellung solange sie unterwegs ist, und ein Knopf "Nochmal senden" daneben. Der Satz in der Meldezeile bat vorher ums Kopieren -- fuenf Handgriffe fuer etwas, das die Seite in einem tun kann; den Text hat sie ja noch. KEIN ZWEITER SENDEWEG: Der Knopf legt den Text zurueck ins Feld, stellt das Antwortziel wieder her und ruft `abschicken`. Ein eigener Weg waere morgen anders als dieser, und der Unterschied fiele erst auf, wenn er zaehlt. "ZUM NEUESTEN" STAND AUF EINER RECHNUNG VON GESTERN: `bottom: 96px` -- die Hoehe der Schreibleiste an dem Tag, an dem der Knopf gebaut wurde. Das Textfeld waechst aber bis 160. Wer lange tippt und gleichzeitig oben liest, hatte den Knopf HINTER der Leiste. Und darueber koennen noch das Nachtruhe-Band und der Hochlade-Balken stehen. Jetzt misst die Seite den ganzen Unterbau selbst -- ueber einen Beobachter statt einer Liste von Ausloesern, denn das Band erscheint um Mitternacht von selbst. Kommt morgen ein viertes Bauteil dazu, rechnet es von allein mit. NEUE PRUEFUNG FUER EINEN WEG, DEN NIE ETWAS GEPRUEFT HAT: pruef-chat-optik faengt die Sendeanfrage jetzt einmal ab und geht den ganzen Fehlerweg durch -- 10 Aussagen, darunter: der Unterschied ist auch zu SEHEN, nicht nur im Merkmal (Rand 1px) die Nachricht steht danach GENAU EINMAL da, nicht doppelt und sie ist beim Gegenueber angekommen Der letzte ist der eigentliche: Alles davor koennte gut aussehen und trotzdem nichts zugestellt haben. pruef-treffchat war seit gestern rot -- 8 Fehler ueber "undefined". Sie suchte die Kachel mit `ziel === "chat.html"`, seit dem 19.09. heisst es `chat.html?raum=treff` (sie fuehrt direkt in den Raum). Kein Befund ueber das Haus, sondern einer ueber sich selbst. Sie sucht jetzt nach der SEITE und prueft statt des Wortlauts das, worauf es ankommt: Man erkennt den Chat, und der Name kommt genau einmal vor. 110/0 statt 108 mit 8 Fehlern. pruef-chat, -anhaenge, -kanaele, -optik, -ausbau gruen, pruef-start-ansicht 151/0, pruef-tippziele 11/0, pruef-nachfrage 33/0, pruef-leerzustand 13/0, pruef-meldungen 8/0, pruef-css-klassen gruen. |
||
|
DogFatherGit
|
18148675a9 |
Die gepflegte Liste der Tippziele wird jetzt bewacht
In module.css steht ein Block, der ein Dutzend Klassen auf 44 Pixel
hebt. Diese Liste wurde von Hand gepflegt -- genau die Falle, vor der
die Hausregeln warnen: Wer einen Knopf mit `width: 34px` baut, traegt
ihn dort nicht nach und merkt es nicht.
GEMESSEN: FUENF Bedienelemente standen nicht drin.
.nachricht__weg 24 breit (das x an einer Nachricht)
.antwort-leiste__weg 28 breit
.chat__weg 34 breit <- der unangenehmste
.todo__weg 36 breit
.sicht__weg 28 breit
`.chat__weg` ist der Knopf, der ein Gespraech wegraeumt -- und direkt
daneben sitzt der, der es FUER ALLE aufloest. Zwei 34-Pixel-Ziele
nebeneinander, eines davon unwiderruflich.
Neu: server/pruef-tippziele.mjs -- 11/0, ohne Browser, unter einer
Sekunde. Sie leitet die Bedienelemente aus dem CSS ab und verlangt
fuer jedes eine Abdeckung. Die Liste bleibt (CSS kann nicht rechnen),
aber sie kann nicht mehr still veralten.
DER ERSTE ANLAUF WAR ZU GROB und meldete 21 Treffer, davon 15 falsch:
`.chat__weg svg` ist 17 Pixel gross und soll das auch sein --
getroffen wird der Knopf darum herum. Eine Pruefung, die zu viel
meldet, wird abgeschaltet; das ist kein besseres Ergebnis als eine,
die zu wenig meldet. Jetzt unterscheidet sie Bedienelement und
Innenteil (svg, ::after, __punkt, __lupe, __pfeil).
UND DIE REPARATUR WAR ERST ZU KLUG. Fuer das 24-Pixel-x in einer
Chat-Nachricht hatte ich eine unsichtbare Trefferflaeche gebaut
(`::after { inset: -10px }`), um die Zeile nicht hoeher zu machen.
Dann gemessen: Die Zeile IST schon 44 hoch -- `start.css` hebt unter
760 px bereits JEDEN button. Es fehlte nur die BREITE. Die Flaeche
haette ein Problem geloest, das es nicht gibt, und dafuer einen Trick
eingefuehrt, den man beim naechsten Lesen erst verstehen muss.
Jetzt schlicht `min-width: 44px`.
Gemessen am Bildschirm, mit und ohne Finger:
Maus .nachricht__weg 24x24 .chat__weg 34x34 (unveraendert)
Finger .nachricht__weg 44x44 .chat__weg 44x44
`pointer: coarse` und nicht `max-width`: Ein Tablet ist 1024 breit und
wird trotzdem mit dem Finger bedient.
NACHTRAG ZUR PRUEFUNG SELBST: Sie verlangte kurz, dass es die
Trefferflaeche GIBT -- und fiel um, als sie wieder verschwand. Eine
Pruefung, die eine Bauweise erzwingt statt eines Ergebnisses, steht
dem Aufraeumen im Weg. Sie erkennt sie jetzt an, verlangt sie aber
nicht.
pruef-tippziele 11/0, pruef-chat-optik gruen, pruef-css-klassen gruen,
pruef-nachfrage 33/0, pruef-leerzustand 13/0.
|
||
|
DogFatherGit
|
2f3fb03ffe |
Eine Pruefung, die nach der ersten Aussage stirbt, prueft nichts
pruef-start-ansicht kam seit gestern Nachmittag ueber die ERSTE
Aussage nicht hinaus: 1 statt 151. Sie starb mit "Failed to execute
getComputedStyle: parameter 1 is not of type Element" -- und sagte
damit gar nichts mehr ueber die Startseite.
URSACHE WAR MEIN EIGENER HINWEIS VON GESTERN. "Bei dir klingelt
nichts" gehoert absichtlich zu keinem Bereich (die Anruf-Probe ist
ein Werkzeug, keine Kachel). Dadurch bekam die Zeile kein Zeichen --
und die Pruefung rief getComputedStyle auf null.
ZWEI FEHLER, ZWEI REPARATUREN:
Die ZEILE sah kaputt aus. Sie stand als einzige ohne Zeichen
zwischen allen anderen, der Text begann weiter links. Genau der
stille Fehler, der wie Absicht aussieht. Sie bekommt jetzt immer
ein Zeichen -- aber KEINE Farbe, denn sie soll keinen Bereich
behaupten, zu dem sie nicht gehoert.
Die PRUEFUNG durfte daran nicht sterben. Ein fehlendes Teil ist ein
BEFUND, kein Absturz. Und sie nahm an, jeder Hinweis zaehle etwas.
Seit gestern gibt es zwei Sorten: zaehlende ("2 Aufgaben sind
ueberfaellig") und Zustaende ("Bei dir klingelt nichts"). Sie
unterscheidet das jetzt und nennt beide Anzahlen -- faellt eine
Sorte ganz weg, sieht man es. Das ist die GENAUERE Pruefung, nicht
die schwaechere.
GEBAUT, GEMESSEN, WIEDER ENTFERNT: Auf dem Weg dahin hatte ich die
Kachelgruppen beim ersten Besuch einklappen lassen -- 25 Kacheln in
5 Gruppen sind fuer den ersten Tag eine Wand. Drei Messungen haben
es widerlegt:
Die erste Gruppe ist nicht die wichtigste. Bei DogFather heisst
sie "Rund um das Team" und hat GENAU EINE Kachel. Er haette eine
Kachel gesehen und sieben zugeklappte Ueberschriften.
Die Regel "nur wenn es nicht auf den Schirm passt" haette auch auf
1280x900 gegriffen -- bei 30 Kacheln passt es nie.
Es gibt keinen "ersten Besuch": Der Merker entsteht erst beim
Klappen. Wer die Seite seit Wochen benutzt und nie geklappt hat,
faende am Morgen seine Startseite umgebaut.
Die Begruendung steht jetzt im Code, damit es niemand ein zweites
Mal baut.
pruef-start-ansicht 151/0, pruef-nachfrage 33/0,
pruef-leerzustand 13/0, pruef-meldungen 8/0, pruef-css-klassen gruen.
|
||
|
DogFatherGit
|
e5eed8506c |
Der gefaehrlichste Handgriff im Haus wird jetzt am Bildschirm geprueft
pruef-personen-loeschen gibt es seit Langem -- sie kennt aber nur die
Schnittstelle: kein Browser, kein Knopf, kein Dialog. Der Weg, den ein
Mensch geht, um eine Person zu loeschen, war nie geprueft. Und das ist
der eine Handgriff, den man nicht zuruecknehmen kann.
pruef-nachfrage hat jetzt einen Browserteil (33/0 statt 17/0):
der Dialog geht auf und nennt den Namen im Titel
er sagt, dass es endgueltig ist, was passiert und was bleibt
ein FALSCH abgetippter Name schliesst ihn NICHT und sagt, warum
der Abbruchknopf loescht nichts
richtig abgetippt wird geloescht (Liste 2 -> 1)
Abmelden fragt nach und nennt den Grund (Zugangscode)
Esc bricht ab -- man bleibt angemeldet
BEIM BAUEN ZWEIMAL DANEBENGEGRIFFEN, beide Male gemessen statt
vermutet:
Die Liste zeigte nur eine Person, obwohl vier in der Datenbank
standen. Das sah nach einem Befund aus. Die Rollen-Abschnitte sind
standardmaessig ZU -- nur der eigene ist offen, und das ist richtig
so. Die Pruefung klappt ihn jetzt auf.
Vorher wurde mit einer festen Wartezeit gearbeitet. Jetzt wird auf
den Zustand gewartet, nicht auf die Uhr.
Neu: server/helfer-nachfrage.mjs (bestaetige/verwerfe/nachfrageText)
kennt beide Wege -- den <dialog> und den confirm()-Notnagel fuer
Safari vor 15.4. Ohne den zweiten liesse sich der Notnagel nie pruefen.
|
||
|
DogFatherGit
|
1207b79a33 |
Hochladen sieht man jetzt, Leerzustaende sagen was hingehoert
DREI BLOECKE AUS DEM PERFEKTIONSLAUF.
1. HOCHLADEN MIT FORTSCHRITT UND ABBRUCH
Alle fuenf Wege (Dateien, Chat-Anhang, Wissen-PDF, Aufgaben-Anhang,
Profilbild) benutzten `fetch`. Das kann beim SENDEN nicht sagen, wie
weit es ist -- sichtbar war "wird hochgeladen …", von der ersten bis
zur letzten Sekunde gleich. Bei 40 MB im Mobilfunknetz zwei Minuten.
Wer das sieht, drueckt noch einmal und laedt dieselbe Datei doppelt.
Neu: workspace/assets/js/hochladen.js (XMLHttpRequest, das Einzige,
was `upload.onprogress` kann) samt gemeinsamer Anzeige.
Drei Ausgaenge: fertig / abgebrochen / schiefgegangen -- und ein
Abbruch ist KEIN Fehler und bekommt keine rote Meldung.
DABEI AUFGEFALLEN: KEINE EINZIGE PRUEFUNG im Haus laedt eine Datei
ueber die Oberflaeche hoch. Der ganze Umbau waere gruen gewesen,
ohne dass ein Byte je den Weg der Nutzer gegangen waere.
Neu: server/pruef-hochladen.mjs -- 18/0, mit echter Datei.
Zwei Irrtuemer beim Bauen, beide gemessen statt vermutet:
Ohne Drosselung gibt es auf localhost EINEN Fortschritt-Stand.
Das sah nach Befund aus und war keiner. Jetzt 2 MBit/s ueber
CDP -- derselbe Verlauf wie bei den Modis im Mobilfunk, 57
gemessene Zwischenstaende.
Gewartet wurde auf den Dateinamen "irgendwo im Dokument" -- der
stand auch im Fortschrittsbalken. Die Bedingung war erfuellt,
bevor etwas angekommen war.
2. LEERZUSTAENDE
Elf von 18 Brettern fielen auf "Noch kein Eintrag in diesem
Bereich" zurueck. Am ersten Tag ist ALLES leer -- wer da achtzehn
Bretter oeffnet und achtzehnmal denselben Satz liest, lernt nichts
ueber die Bretter, sondern dass das System kaputt ist. Jeder Satz
sagt jetzt, was hier hingehoert UND was der naechste Schritt ist.
Neu: server/pruef-leerzustand.mjs -- 13/0, leitet die Bretter aus
BEREICHE ab; ein neunzehntes ohne Satz macht sie rot.
3. ABMELDEN UND KONTRASTMODUS
Abmelden war am Handy ein 44-Pixel-Zeichen neben Glocke und Suche,
sofort wirksam. Teurer als es aussieht: Zum Wiederanmelden braucht
man den Zugangscode, und den gibt es EINMAL. Jetzt mit Rueckfrage,
die genau das sagt -- und dazu, dass Zumachen reicht (12 Stunden).
Kontrastmodus: 68 Regeln zeigen einen Zustand NUR ueber Farbe
(35x aria-pressed, 33x data-an). Der Modus ersetzt alle Farben und
entfernt box-shadow -- gedrueckt sah aus wie nicht gedrueckt.
14 CSS-Dateien hatten gar keinen Block. Statt 14 Bloecke zu pflegen
eine Regel in gate.css, die den ZUSTAND trifft statt die Datei.
Gemessen mit forcedColors: active -- vorher ununterscheidbar,
jetzt `solid 2px Highlight`.
Was seinen Zustand als WORT traegt (.marke-status, .t-stufe,
.spalte), braucht nichts -- nachgesehen, nicht vermutet.
PRUEFUNGEN, DIE AUF confirm() WARTETEN: Fuenf Dateien benutzten
`seite.once("dialog", d => d.accept())`. Playwright faengt confirm()
selbst ab, einen <dialog> nicht -- pruef-chat-anhaenge meldete acht
Fehler, keiner davon im Code. Neu: server/helfer-nachfrage.mjs, der
beide Wege kennt (auch den Notnagel fuer Safari vor 15.4).
pruef-chat-anhaenge, -ausbau, -optik und pruef-code wieder gruen.
hilfeAufraeumen bleibt ausgeschaltet -- das loescht echte Daten und
ist Filipes Entscheidung.
|
||
|
DogFatherGit
|
c516aad4ed |
Nichts verschwindet mehr ohne eine Nachfrage, die sagt was passiert
Filipe: "Es darf vor allem keine Stellen geben, an denen ein Benutzer
etwas falsch machen kann, nur weil die Seite es nicht verstaendlich
genug erklaert."
Gemessen: 30 Stellen in 16 Dateien benutzten confirm() oder prompt().
Das Haus hatte die richtige Bauweise laengst -- einen <dialog>, in
aufgaben.html sogar ausfuehrlich begruendet -- aber sie stand IN EINER
SEITE. Wer anderswo etwas loeschen liess, hatte sie nicht.
confirm('Wirklich loeschen?') stellt die falsche Frage: Es fragt, ob
man sicher ist, und nennt nicht, WAS passiert, was BLEIBT und ob es
ZURUECK geht. Jetzt beantwortet jeder der 41 Dialoge alle drei.
Neu: workspace/assets/js/nachfrage.js -- window.frageNach() mit
Pflichtgrund, Zahlenfeld, einzeiliger Eingabe und Abtippsicherung.
Drei Ausgaenge: <dialog> / confirm()-Notnagel fuer Safari vor 15.4 /
Abbruch (Esc, Klick daneben, "Doch nicht" -- immer false).
DREIMAL DERSELBE FALLSTRICK, dreimal nachgemessen statt vermutet:
.dialog stand in aufgaben.css und leistung.css -> auf dateien.html
waere der Dialog ein weisser Systemkasten gewesen. 14 Regeln
klammergenau nach module.css verschoben (Klammern gezaehlt, nicht
per Muster geschnitten -- heute frueh hat ein nicht-gieriges
Muster schon einmal CSS zerrissen).
Das Formular trug .neu neu--blank -- und .neu gibt seine Abstaende
nur in aufgaben.css. Gemessen: padding 0px, und die Felder
verloren ihre height:44px. Jetzt steht alles unter
.nachfrage__form in module.css; der Dialog borgt nichts mehr.
Die erste Fassung der Pruefung zaehlte nachfrage.js SELBST als
Nutzer -- damit war jede Seite trivialerweise "Nutzer" und die
Pruefung gruen ohne Inhalt. Jetzt ausdruecklich ausgenommen.
ZWEI FUNDE NEBENBEI:
hilfeAufraeumen() wird im Betrieb NIE aufgerufen. Der Kommentar
behauptete "wird beim Start aufgerufen (siehe index.js)" -- das
war nie wahr; einziger Aufrufer ist die eigene Pruefung. Folge:
geschlossene vertrauliche Faelle bleiben unbegrenzt stehen. NICHT
eingeschaltet (das loescht echte Daten und ist Filipes
Entscheidung), sondern der Kommentar richtiggestellt.
Einen Hilfe-Fall zu schliessen ist endgueltig -- es gibt keine
Route, die ihn wieder oeffnet. Vorher stand darueber nur die
Frage nach einem Schlusswort. Jetzt sagt der Dialog es.
pruef-struktur hat meine eigene Pruefung von heute Nachmittag
erwischt: Sie bildete ihr Datum aus UTC. Beim Beheben erst
heuteLokal(datum) genommen -- die Funktion nimmt gar kein Argument
und haette still "heute" statt "+3 Tage" geliefert. Jetzt tagLokal(3),
nachgerechnet: Abstand 3 Tage.
Am Bildschirm angesehen (Rechner 1280, Handy 390): passt rein, Esc
ergibt false, Fokus liegt auf dem harmlosen Knopf, Knoepfe 44px auf
Touch. Der Platzhalter im Abtippfeld zeigte den erwarteten Namen --
das sah aus wie ein schon ausgefuelltes Feld, entfernt.
Neu: server/pruef-nachfrage.mjs -- 17/0, mit sechs Gegenproben und
beiden Richtungen (wer fragt, laedt die Datei; wer nie fragt, laedt
sie nicht -- sonst truege die Anmeldewand 4,8 KB fuer nichts).
pruef-meldungen 8/0, pruef-css-klassen gruen, pruef-struktur gruen,
pruef-leistung gruen.
|
||
|
DogFatherGitandClaude Opus 5
|
26937dda16 |
Ein klingelndes Telefon haengt nicht mehr an einem einzigen Kanal
Filipe: "wenn vanvan rangeht und redet klingelt es immer noch bei mir
weiter, der anruf verbindet nicht richtig."
=== WAS DAS PROTOKOLL SAGT ===
17:04:52 anruf_start Person 1 (Filipe)
17:05:25 anruf_ende Person 4 (VanVan) 24 s
17:05:31 anruf_ende Person 1 (Filipe) 39 s
Sie WAR im Gespraech -- der Server hat sie 24 Sekunden als
Teilnehmerin gefuehrt. Das Ereignis "dabei" ist also verschickt
worden. Bei Filipe kam es nicht an: `tonAus()` ist das Erste im
`dabei`-Zweig, noch vor jeder Pruefung, und das Tuten lief weiter.
=== GEPRUEFT UND AUSGESCHLOSSEN ===
Raumzugehoerigkeit beide in Raum 1, bei keinem `raus_am` gesetzt
Verkabelung Server sendet mit `art: "anruf"`, chat.js reicht
an window.anrufEreignis weiter, anruf.js nimmt
entgegen -- alle drei Stellen stimmen
Tonsteuerung ein einziger Taktgeber, `tonAus` raeumt ihn;
kein zweiter Weg, der ihn neu startet
Ereignisstrom Keep-alive vorhanden, Kopfzeilen richtig
(no-transform, X-Accel-Buffering: no)
Service Worker hat gar keinen fetch-Handler, kann also kein
altes Skript ausliefern
teilnehmerVon vs.
teilnehmerFuerAnruf reicht nur durch, dieselbe Abfrage
Es geht unterwegs verloren, auf einem Weg, der von hier aus nicht
messbar ist: Ereignisstrom ueber Cloudflare, ein schlafender Reiter,
ein Neustart im falschen Moment.
=== ALSO NICHT WEITERSUCHEN, SONDERN DIE ABHAENGIGKEIT BESEITIGEN ===
Ein klingelndes Telefon darf nicht an einem einzigen, zerbrechlichen
Kanal haengen. Solange es klingelt, fragt der Anrufer jetzt SELBST
nach: "ist schon jemand dran?" -- alle zwei Sekunden an
`/workspace/api/anruf/:raum`, das es laengst gibt.
Der Ereignisstrom bleibt der erste Weg, er ist schneller. Das hier ist
das Netz darunter. Kommt das Ereignis an, hat die Nachfrage nichts
mehr zu tun und haelt von selbst an (sie prueft `anruf.beginn` und die
bekannten Teilnehmer).
Sie hoert an JEDEM Ende auf: beim Auflegen, wenn die Verbindung steht,
wenn das Ereignis doch ankommt, wenn der Anruf vorbei ist. Eine
Schleife, die weiterlaeuft, fragt sonst auf jedem Geraet, das je
telefoniert hat, alle zwei Sekunden nach einem Anruf, den es nicht
mehr gibt.
Alle zwei Sekunden und nicht jede halbe: Es klingelt hoechstens zwei
Minuten, das sind sechzig Abrufe.
=== ZWEI DINGE, DIE DIESE SUCHE ERST SO MUEHSAM GEMACHT HABEN ===
DAS PROTOKOLL KANNTE ANFANG UND ENDE, ABER NICHT DEN MOMENT DAZWISCHEN.
Die wichtigste Frage -- "ist sie ueberhaupt rangegangen?" -- war nur
ueber einen Umweg zu beantworten (ein `anruf_ende` mit ihrer Nummer).
Das ist eine Schlussfolgerung, keine Auskunft. `anruf_dabei` steht
jetzt drin, mit der Zahl der Beteiligten.
UND EINE PRUEFUNG WAR GRUEN, OHNE ETWAS ZU PRUEFEN. In chatEreignis
stand `(zuschauer.get(personId) || []).length` -- `zuschauer` haelt
aber Mengen, und eine Menge hat kein `length`. Der Ausdruck war IMMER
undefined, also immer falsch, also wurde nie uebersprungen: Wer die
Seite offen hatte, bekam zusaetzlich zur Nachricht auf dem Bildschirm
noch eine Meldung aufs Handy.
Der Kommentar drei Zeilen darueber warnt woertlich davor ("der
schnellste Weg, dass er Benachrichtigungen abschaltet"), und
`siehtZu()` weiter unten macht es mit `.size` richtig. Die Absicht
stand da, die Zeile tat das Gegenteil.
Meine eigene Pruefung hat das mitgetragen: Sie bestaetigte den alten
WORTLAUT statt sein VERHALTEN und war deshalb gruen. Genau die
Hausregel vom 01.09. -- ein gruener Haken sagt nur, dass die Bedingung
erfuellt war, nicht dass sie das Richtige geprueft hat. Jetzt prueft
sie auf `.size`.
GEMESSEN: pruef-anruf-klingelt 24/0 (vorher 17), pruef-anruf 114/0,
pruef-turn-wege 15/0, pruef-meldungen 8/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
9a1287aa0e |
Es hat nie geklingelt -- und die Vermittlung war nie das Problem
Filipe: "irgendwas klappt mit dem telefonieren nicht."
=== WIE DER FEHLER GEFUNDEN WURDE ===
Ich habe zuerst wieder die Vermittlung verdaechtigt. Stattdessen das
Protokoll des Servers gelesen -- und dort stand es die ganze Zeit:
24x anruf_start, jeder nach 7 bis 39 Sekunden beendet
im Chat danach jedes Mal: "Verpasster Anruf"
die Gegenseite schrieb: "Hab keinen Anrufeingang gehabt und
keine Benachrichtigung"
Es ging nie um Ton oder Verbindung. Es hat bei der anderen Person
schlicht nicht geklingelt.
Dieselbe Lehre wie am 06.09. ("kommt keine Mail an" -- erst fragen, OB
gesendet wurde) und am 14.09. (zwei Tage Audiowege verfolgt, waehrend
die CPU bei 98 % stand). Eine halbe Minute in der richtigen Tabelle
haette Stunden gespart.
Nebenbefund zur Messbarkeit: Das coturn-Protokoll kann die Frage gar
nicht beantworten -- es schreibt Zuteilungen bei dieser Stufe nicht
mit. Meine eigene Zuteilung von 16:35 taucht dort ebenfalls nicht auf.
Wer daraus "null Zuteilungen, also kaputt" liest, sucht am falschen
Ende. Das ist der dritte Ausgang: nicht "in Ordnung" und nicht
"kaputt", sondern "kann ich hier nicht sehen".
=== WAS WIRKLICH DEFEKT WAR ===
Die Benachrichtigung WURDE zugestellt -- `zuletzt_ok` am Geraet stand
auf genau die Anrufminute. Sie hat nur nicht geklingelt:
1. `Urgency: "normal"` STAND FEST IM TRANSPORT, fuer jede Meldung.
Auf Android entscheidet dieser Kopf, ob sofort zugestellt wird oder
bis zum naechsten Aufwachen gewartet. Im Stromsparmodus werden
daraus Minuten -- bei einem Anruf, der 120 Sekunden klingelt, ist
das ein verpasster Anruf mit Zeitstempel.
2. `renotify: false` UND `tag: d.art`. Eine zweite Meldung mit
derselben Kennung ersetzt die erste LAUTLOS. Wer ein zweites Mal
anruft, WEIL nicht abgehoben wurde, loest damit gar keinen Ton mehr
aus -- genau im wichtigsten Moment.
3. KEIN vibrate, KEIN requireInteraction. Ein stiller Kasten, der von
selbst verschwindet. In einer Hosentasche unsichtbar.
Fuer "Aufgabe ueberfaellig" ist all das genau richtig, und der
Kommentar daneben stimmte auch ("eine Meldung, die stehen bleibt, ist
eine Zumutung"). Fuer ein klingelndes Telefon ist es das Gegenteil.
Jetzt unterscheidet das Haus beides:
- eigene Kennung je Anruf, damit der zweite den ersten nicht
stillschweigend ersetzt
- renotify, vibrate (zweimal lang, wie ein Telefon),
requireInteraction
- Urgency: high und eine TTL von 150 Sekunden -- ist der Anruf
vorbei, verfaellt auch die Meldung, statt eine Stunde spaeter
nachtraeglich aufzuploppen
- alle ANDEREN Meldungen bleiben unveraendert ruhig. Das ist kein
Nebensatz: Wuerde alles vibrieren und stehenbleiben, schaltet es
nach drei Tagen jemand ab -- und dann klingelt auch der Anruf nie
wieder.
Die Dringlichkeit haengt an derselben Bedingung wie die Nachtruhe
(`art === "test" || art === "anruf"`). "Darf das nachts stoeren?" und
"darf das warten?" haben dieselbe Antwort; zwei Bedingungen waeren die,
die beim naechsten Nachschaerfen auseinanderlaufen.
=== ERREICHT ES AUCH JEMANDEN? ===
Der Service Worker ruft skipWaiting() und clients.claim() -- die neue
Fassung greift beim naechsten Oeffnen der App, ohne dass jemand etwas
tun muss.
ABER: Nachgemessen haben NEUN von fuenfzehn aktiven Zugaengen KEIN
Geraet angemeldet -- darunter eine rechte Hand und zwei Modis. Bei
ihnen kann keine Benachrichtigung ankommen, so laut sie auch waere.
Das ist kein Codefehler; das muessen die Leute einmal selbst tun.
=== GEMESSEN ===
pruef-anruf-klingelt 17/0 (neu, mit drei Gegenproben), pruef-anruf
114/0, pruef-turn-wege 15/0, pruef-meldungen 8/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
5c3bfcb47d |
Der Handy-Rundgang, den es fuer die Modis nie gab
Filipe: "mach einen kompletten check dass die app auf dem handy perfekt
funktioniert ... weil die modis haben schon probleme." Auf die
Rueckfrage: "einfach ALLES ABCHECKEN ALLES MOEGLICHE."
=== DER BEFUND, DER ALLES ERKLAERT ===
Es gibt seit dem 02.09. einen grossen Rundgang (pruef-grosscheck). Er
geht ueber jede Seite, zwei Bildschirmgroessen und VIER Rollen:
admin . manager . scout . creator
Vier von acht. Es fehlen modi, hand und gast -- also genau die drei
Rollen, die auf crew.dogfather-universe.com leben, und genau die, von
denen die Beschwerden kommen. Ihre Seiten waren nie im Ganzen auf einem
Handy durchgemessen worden.
Kein Vorwurf an den Rundgang: Er wurde fuers Agenturhaus gebaut, und
Team Dogi kam spaeter dazu. Aber es erklaert, warum Fehler dort
ueberleben konnten.
pruef-handy-teamdogi.mjs schliesst die Luecke: 4 Rollen x 2 Breiten x
bis zu 32 Seiten = 206 Seitenaufrufe, 91 052 Elemente, 3 880
Bedienelemente. Gemessen wird: kommt die Seite an, stuerzt etwas ab,
laeuft etwas ueber den Rand, ist Text abgeschnitten, kann man es
treffen, liegt etwas uebereinander, weiss man was es tut.
=== WAS ES GEFUNDEN HAT ===
DIE KOPFLEISTE WAR AUF JEDER SEITE ZU KLEIN. Bei Breiten bis 400 px
schrumpften alle Knoepfe auf 34x34, bis 560 px auf 36x36. Das sind zehn
Pixel unter dem, was ein Daumen sicher trifft -- und es betraf jede
Seite, jede Rolle, jeden Aufruf. Genau das erlebt man als "der Knopf
geht nicht".
Die Verkleinerung war nie noetig. Am echten Aufbau nachgemessen:
Breite belegt bei 44px noetig verfuegbar
360 px 237 284 328
390 px 237 284 358
412 px 245 284 380
Es passt ueberall, mit Luft. Jetzt 44x44 -- und dazu `flex-wrap: wrap`
als Regel statt einer dritten festen Zahl: Die Reihe bricht genau dann
um, wenn der Platz wirklich nicht reicht.
DER ZURUECK-KNOPF war 38x44 -- die Hoehe stimmte, die Breite nicht. Der
Rundgang hat ihn 192-mal gemeldet. Er ist der Knopf, den man auf jeder
Unterseite am haeufigsten trifft.
DIE KLEINEN UMSCHALTER (38 px) waren eine begruendete Ausnahme --
begruendet fuer die Maus. Auf Geraeten, die mit dem Finger bedient
werden, gilt jetzt 44. Gefragt wird `pointer: coarse` und nicht die
Breite: Ein schmales Browserfenster am Rechner braucht keine 44 px, ein
1200 px breites Tablet sehr wohl.
DIE KALENDERPILLEN waren 26 px hoch, das Rechtefeld 34 px breit, die
Kalenderpfeile 38 px. Alle auf 44.
EINE BESCHRIFTUNG HING NICHT AM FELD. In checkliste.js stand ein
<label> ohne `for` neben einem <select> ohne `id`. Optisch richtig --
fuer ein Vorleseprogramm ein namenloses Feld. Und weil wahl.js das
Systemmenue durch einen eigenen Knopf ersetzt und dessen Namen AUS DEM
LABEL holt, blieb auch der Knopf namenlos.
=== DREI FEHLER IN MEINER EIGENEN PRUEFUNG ===
Und sie sind der lehrreichere Teil.
(1) DER ERSTE LAUF MELDETE EIN 1647 px BREITES BILD auf einem 390 px
breiten Schirm. Das sah nach dem Fund des Tages aus. Es war einer
in MEINER Pruefung: `dogfather-universe.com` steht in der fest
eingebauten HSTS-Liste von Chromium, der Browser schaltet
unabaenderlich auf https um, und mein Testserver sprach http.
Ergebnis: JEDE Stilvorlage schlug fehl. Gemessen wurde eine Seite
ganz ohne CSS.
Haette ich den Befund gemeldet statt nachzusehen, waere ein halber
Tag in eine Reparatur geflossen, die nichts repariert. Die Pruefung
spricht jetzt selbst https, mit eigenem Zertifikat und einem
winzigen Vorbau.
(2) 350 FEHLALARME. `span.zurueck-knopf__text` wurde 192-mal als
abgeschnitten gemeldet, `span.teilen__text` 154-mal -- beide sind
ABSICHTLICH 1 px gross und weggeschnitten, damit ein
Vorleseprogramm sie liest und das Auge nicht. Dazu 24-mal
`-webkit-line-clamp` (gewolltes Kuerzen auf zwei Zeilen), 14-mal
Textfelder MIT Beschriftung (ich fragte `labels` nur bei input und
select, nicht bei textarea) und 26-mal Zierrat mit
`aria-hidden="true"`.
Eine Warnung, die immer kommt, ist keine Warnung mehr -- und diese
haetten jeden echten Fund zugedeckt.
(3) DIE UEBERLAUF-MESSUNG WAR BLIND. Sie rechnete
`scrollWidth - clientWidth`; `body { overflow-x: hidden }` macht
beide Werte immer gleich. Die Pruefung fand nichts und meldete
trotzdem gruen. Gefunden hat das die GEGENPROBE -- sie ist genau
dafuer da. Jetzt zaehlt, ob ein sichtbares Element ueber den
rechten Rand ragt.
=== UND EIN FEHLER BEIM AUFRAEUMEN ===
Beim Verschieben der Touch-Regeln von start.css nach module.css hat ein
NICHT-GIERIGES Suchmuster am ersten `}` am Zeilenanfang aufgehoert und
dabei mehr mitgenommen als gemeint: die Schriftgroessen-Regeln fuer
schmale Fenster. Die haetten danach nur noch auf Geraeten mit Finger
gegolten.
Gefunden hat es wieder der Rundgang, nicht das Lesen: `.k-pille` blieb
26 px hoch, obwohl die neue Regel 44 sagte -- die alte stand weiter
unten und gewann. Zurueckgeholt aus HEAD, an ihren Platz gesetzt.
Nebenbei kam dabei heraus, WARUM eine Regel nicht ankam: Jede Seite
laedt gate -> start -> seite -> module -> haus. `aufgaben.css` setzt
`.schnitt { min-height: 38px }` mit derselben Staerke, kommt aber
spaeter. Eine Regel, die man geschrieben hat und die nicht wirkt, sieht
im Editor genauso aus wie eine, die wirkt.
=== STAND ===
Befunde: 120 -> 64.
Weg sind: alle abgeschnittenen Texte (0), alle namenlosen
Bedienelemente (0), alle zu kleinen Knoepfe in Kopfleiste, Zurueck-Weg,
Filterreihen, Kalender.
Es bleiben 64, und sie sind alle von derselben Sorte: 48-mal der
Ersatzknopf eines Auswahlfeldes (34-42 px breit, aber 44 hoch), 8-mal
Kalenderpillen (36-39 breit, 44 hoch), 8 Ueberstaende. Alle sind in der
HOEHE gross genug und nur in der Breite knapp -- die komfortable
Empfehlung, nicht die Mindestanforderung. Sie stehen namentlich im
Prueflauf und sind der naechste Schritt.
GEMESSEN: pruef-css-klassen ALLES IN ORDNUNG, pruef-meldungen 8/0,
pruef-rechtetafel 19/0, pruef-turn-wege 15/0, und beide Gegenproben des
neuen Rundgangs schlagen an.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
e54c6829f1 |
Talente: der Trichter bekommt einen Ausgang
Gemessen vor dem Bau: talentNaechste kettet aufgefallen -> beobachtet -> angesprochen -> probe -> imteam, und danach kommt nichts. Eine Suche nach "beenden|abgesagt|verworfen|archiv" in workspace-entwicklung.js fand nichts. Der Trichter hatte genau einen Ausgang -- obwohl der Text der Probe-Stufe woertlich verspricht: "Nach 30 Tagen: uebernehmen -- der Zugang entsteht dabei -- oder sauber beenden." Wer nicht passte, blieb also auf seiner Stufe stehen, mit wachsender Standzeit und rotem "liegt"-Zeichen. Nach einem Jahr hat die Liste mehr Karteileichen als Kandidaten, und dann schaut niemand mehr hin. DREI SPALTEN, KEINE NEUE STUFE. Eine neue Stufe haette einen CHECK-Umbau auf laufenden Daten verlangt -- und eine Auskunft zerstoert: Die Stufe haelt fest, WO es geendet hat. "Beendet in der Probe" und "beendet nach dem ersten Hinsehen" sind zwei verschiedene Saetze, und genau der Unterschied ist die Frage, wenn dieselbe Person in einem halben Jahr wieder auffaellt. DER SATZ IST PFLICHT (10 Zeichen, wie beim Ablehnen einer Anfrage) -- aus zwei Richtungen: Nach vorn, weil beim zweiten Anlauf niemand mehr weiss, was damals war. Nach innen, weil wer schreiben muss, anders entscheidet als wer klickt. "Passt nicht" hat neun Zeichen. WIEDER AUFNEHMEN setzt auf "aufgefallen" zurueck -- Menschen aendern sich, ein Urteil von damals gilt nicht weiter -- und rettet den alten Satz in die Notiz, statt ihn zu loeschen. AM BILDSCHIRMFOTO GEFUNDEN, nicht an einer Zahl: Auf einer Karte auf "Im Team" stand "Nichts mehr zu tun -- der Zugang steht" und direkt darunter "Passt doch nicht?". Ein Beenden dort haette die Karte stillgelegt und den ZUGANG offengelassen -- eine halbe Handlung, die sich wie eine ganze anfuehlt. Jetzt steht dort der Weg zu "Personen & Zugaenge", und der Server weist es mit 409 ab. pruef-nachwuchs 152 -> 200, davon 21 im echten Browser (der erste Browserblick auf diese Seite ueberhaupt -- mit einer Messung, ob Name und Datum bei 390 px uebereinanderliegen, statt einer Zahl im CSS). Sechs Gegenproben, jede genau auf ihr Ziel: Grenze auf 0 -> 3 rot Beendete bleiben drin -> 2 rot beendete: [] -> 5 rot alter Grund verworfen -> 1 rot Serverriegel imteam -> 5 rot Browserzweig imteam -> 3 rot Dazu gruen: css-klassen, struktur, entwicklung, uebergang. Nebenbefund behoben: absage() im Browser warf einen erklaerenden Satz des Servers lautlos weg und zeigte "Ging nicht." -- die Auskunft war da. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGit
|
3a49e30aa4 |
Die Probezeit hat einen Inhalt -- und man sieht, wer was gesehen hat
Filipe: "wie talente bewertet werden, aufgaben bekommen, analysiert werden von vanvan und mir, alles moegliche, wie gesagt ich will hoch profissionel arbeiten." WAS GEMESSEN FEHLTE Die Stufe "Probe" hatte eine Frist von 30 Tagen, einen Buddy, ein Datum -- und einen Satz: "Nach 30 Tagen: uebernehmen oder sauber beenden." Worauf diese Entscheidung sich gruenden soll, stand nirgends. Eine Probezeit ohne Inhalt ist keine Probe, sondern eine Wartezeit; am dreissigsten Tag entscheidet dann das Bauchgefuehl dessen, der zuletzt etwas gesehen hat. Und: `von_id` stand seit dem Bau in talent_merkmal und wurde nie ausgeliefert. Man sah, DASS ein Merkmal gesetzt ist -- nicht, von wem. Bei zwei Leuten, die unabhaengig beobachten, ist genau das die Auskunft. DER PROBEPLAN Zwoelf Schritte in drei Phasen: mitlaufen -> selbst machen -> allein. Die Reihenfolge ist der Punkt (Discord empfiehlt sie so, in der Ausbildung heisst sie "see one, do one"). Wer die mittlere Stufe ueberspringt, hat am Tag 30 zwei Sorten Kandidaten, die man nicht unterscheiden kann. JEDER SCHRITT HAT EINEN ZUSTAENDIGEN -- sechs das Talent, drei der Buddy, drei die Leitung. Ohne diese Angabe wandern in jeder Probezeit dieselben drei an niemanden: Der Buddy denkt, die Leitung macht es. KEINE PUNKTZAHL. Am Ende stehen drei Fragen, die ein Mensch beantwortet; die Haken sagen nur, ob er genug gesehen hat. Und "entscheidbar" haengt an DREI Schritten, nicht an einer Anzahl: Wer nie allein gearbeitet hat und wen das Team nie beurteilt hat, ueber den weiss man nichts, egal wie viele andere Haken stehen. Neun von zwoelf reichen nicht, drei genuegen -- wenn es die richtigen sind. WAS DAS HINSEHEN GEFUNDEN HAT `.t-schritt` gibt es auf dieser Seite schon -- es ist die Zeile mit dem naechsten Schritt der Trichterstufe. Meine Regeln standen SPAETER in derselben Datei und haetten sie ueberschrieben. Gefunden hat das keine Ueberlegung, sondern das Nachzaehlen im Browser: 13 Elemente mit `.t-schritt`, obwohl der Plan zwoelf hat. ZWEI PRUEFUNGEN WAREN SCHON VORHER ROT (gemessen mit git stash) pruef-schritt (6 rot) und pruef-befinden (4 rot) -- seit den Erweiterungen von heute frueh: aus sechs Befinden-Fragen wurden zwoelf, aus vier Kategorien sechs, und die Personenkachel zaehlt seit heute in Kaesten statt in einem Satz. Die Zahlen standen als feste Werte in den Pruefdateien. Nicht die Zahlen angepasst, sondern ABGELEITET: aus ENTWICKLUNG_BLOECKE und ENTWICKLUNG_PUNKTE.befinden. Eine feste Zahl ist eine Rechnung von gestern; wer sie nachtraegt, traegt sie beim naechsten Mal wieder nach. GEPRUEFT pruef-nachwuchs 123 -> 152. Vier Gegenproben, jede trifft ihr Ziel: Liste auch vor der Probe -> 1 rot, Abhaken ohne Stufenpruefung -> 7 rot, "entscheidbar" nach Anzahl statt nach den drei -> 3 rot, Name nicht mitgeliefert -> 1 rot. Dazu gruen: schritt 65, befinden 75, entwicklung 43, uebergang, neue-seiten, rechtetafel, css-klassen, struktur, deutsche-texte, modi-wortleck. |
||
|
DogFatherGit
|
470c65a46b |
Anfragen fuer Modi: ein Fragebogen, vier Wege, eine Bruecke
Filipe, mit dem Bildschirmfoto des Bretts "Mitmachen": "ich will dass die leute sich da anonym bei mir melden koennen ... wie ein fragebogen wieso die person modi werden will warum sie sollte, positiv negative sachen ... und dan soll ich annehmen ablehnen, in warteschlange stellen oder sofort kommunizieren koennen. und wenn ich annehme dan soll diese person automatisch zu talente kategorie weiter geleitet werden." Seine zwei Entscheidungen auf Rueckfrage: "Vertraulich, aber nicht namenlos" und "Du und die rechte Hand". WAS ES GIBT 15 Fragen in 6 Gruppen, 9 davon Pflicht. Vier davon standen nicht auf seinem Zettel und kommen aus der Recherche zu Moderator-Bewerbungen: Alter, frühere Sperren, "ein Freund bricht die Regeln - was machst du?" und "was kannst du nicht so gut?". Die letzte ist die aussagekraeftigste: Wer darauf "nichts" schreibt, hat sich gerade selbst beantwortet. Vier Wege: Reden - Warteschlange - Annehmen - Ablehnen. "Reden" steht vorne, weil die haeufigste richtige Antwort auf eine Bewerbung eine Rueckfrage ist und keine Entscheidung; stuende "Annehmen" oben, wuerde es geklickt. "Sofort kommunizieren" ist ein Satz, den sie liest. Kein Chat: Ein Zugang aus der Community steht ausdruecklich in keiner Chatliste (AUSSEN_ROLLEN). Der Satz ist damit der einzige Weg, dieser Person etwas zu sagen -- deshalb ist er bei "Reden" und "Ablehnen" Pflicht, und WELCHE Wege ihn verlangen, steht im Katalog und nicht zweimal. Nach "Annehmen" entsteht ein Talent auf der Stufe "Angesprochen". Die ersten beiden Stufen fragen, ob ueberhaupt Interesse besteht; wer sich selbst meldet, hat das beantwortet. WAS DABEI HERAUSKAM, DAS NICHT GESUCHT WAR aufgaben.js entschied mit `p.rolle === 'modi' || p.rolle === 'hand'`, wer eine Katalogaufgabe bekommen kann. Diese Datei ist ohne Anmeldung aus dem offenen Netz lesbar -- damit stand der verborgene Zugang darin nachzulesen. Jetzt entscheidet es der Server und schickt ein Ja/Nein. Gefunden von der Wortleck-Pruefung, nicht vom Auge. pruef-struktur meldete teilen.html seit heute frueh als "von nirgendwo verlinkt" -- und lag falsch: Auf sie zeigt `share_target.action` im Manifest. Die Manifeste sind jetzt Verweisquelle, nicht die eine Seite eine Ausnahme. Und im Bildschirmfoto stand der Schriftzug der Buehne mitten im Text einer Anfrage: `color-mix(..., transparent)` mischt mit DURCHSICHTIG. Deckend ist `#ffffff 6%`, so wie es .t-karte macht. Dieselbe Stelle hat mich heute schon einmal erwischt. GEPRUEFT pruef-bewerbung 77, davon 14 im Browser. Vier Gegenproben, jede trifft genau ihr Ziel: Bruecke ohne "genau einmal" -> 2 rot, Vertraulichkeit weg -> 5 rot, Nachricht-Pflicht weg -> 2 rot, Knopf ohne Rollenfrage -> 1 rot. Dazu unveraendert gruen: rollen 315, modi-verborgen 80, modi-katalog 49, entwicklung 43, treff, bereiche-lesend, haus-seiten, alle-wege, rechtetafel, css-klassen, struktur, deutsche-texte, start-ansicht, sicht, aufgabenbrett, womit, kanaele. |
||
|
DogFatherGitandClaude Opus 5
|
a0d9dc38e4 |
Teilen -> Workspace: aus fuenf Schritten wird ein Tipp
SCHRITT 4 AUS DEM VIDEO-PLAN Filipe postet ein Video auf dem Handy. Bisher: Link kopieren, App oeffnen, Bereich suchen, Feld finden, einfuegen. Fuenf Schritte, von denen jeder einzelne der Grund sein kann, es "spaeter" zu machen -- und spaeter heisst nie. Jetzt: in TikTok auf "Teilen", DogFather waehlen, uebernehmen. Die neue Seite workspace/teilen.html ist das Ziel dieses Tipps, eingetragen als share_target in beiden Manifesten. DER STOLPERSTEIN, DEN JEDE ANLEITUNG VERSCHWEIGT Das Teilen-Ziel kennt drei Felder: title, text, url. Man baut es, testet mit "?url=https://…" und ist fertig. IM ECHTEN LEBEN KOMMT DER LINK IN `text`. Android-Apps -- TikTok eingeschlossen -- teilen als reinen Text: "Sieh dir das an! https://vm.tiktok.com/xyz/" steht dann in `text`, und `url` ist leer. Wer nur `url` liest, hat eine Seite gebaut, die im Test funktioniert und auf dem Handy eine leere Maske zeigt. Gesucht wird deshalb in allen drei Feldern nach einem MUSTER, nicht nach einem Feldnamen -- und ein Satzzeichen am Ende gehoert nicht zur Adresse. SIE TRAEGT NICHT VON SELBST EIN. Die Seite kann nicht wissen, ob der Griff in die Tasche gemeint war. Ein Video, das ungefragt in den Highlights landet, muss jemand wieder loeschen -- das ist mehr Arbeit als ein Tipp auf "Uebernehmen". Und wohin ist eine Frage, keine Annahme: Highlights sind vorausgewaehlt, Treff und Anschlagbrett stehen daneben. GET UND NICHT POST. POST braeuchte einen Service Worker, der die Anfrage abfaengt -- eine Stelle mehr, die kaputtgehen kann, und zwar genau die unsichtbare: Man tippt auf Teilen und landet auf einer leeren Seite. Hier wird nur ein Link geteilt, keine Datei. GESEHEN, NICHT NUR GEZAEHLT Das Bildschirmfoto auf 390 px zeigte einen Mangel, den keine Zahl gemeldet haette: Das gewaehlte Ziel hob sich nur ueber Helligkeit ab. Bei einer echten Wahl ist das zu wenig, und wer Farben schlecht unterscheidet, sieht gar nichts. Jetzt: farbiger Streifen links, deutlicherer Grund -- und ein HAKEN, der ohne jede Farbwahrnehmung funktioniert. EIN SICHERHEITSFUND NEBENBEI -- UND ER IST DER WICHTIGERE pruef-alle-wege meldete: Von 126 schreibenden Wegen hatte genau EINER keine Herkunftspruefung. POST /workspace/api/aufbewahrung/jetzt -> 200 Eine beliebige fremde Seite kann im Browser eines angemeldeten DogFather ein Formular dorthin abschicken; der Browser gibt das Sitzungsplaetzchen mit, der Server fuehrt aus. Und ausgerechnet dieser Weg: aufbewahrungLauf() LOESCHT abgelaufene Daten. Ein Aufruf zur falschen Zeit loescht wirklich etwas, und im Protokoll sieht es aus, als haette DogFather es selbst angestossen. Die anderen 125 Wege hatten den Riegel -- dieser eine wurde beim Hinzufuegen uebersehen. Genau dafuer geht die Pruefung ALLE Wege durch, statt einer Liste zu glauben. Behoben, danach: "kein schreibender Weg nimmt eine fremde Herkunft an". DIE PRUEFUNG (server/pruef-teilen.mjs, 27 Pruefungen) Auf 390 px gemessen -- diese Seite wird fast nur dort geoeffnet, eine Messung auf 1400 px misst etwas, das niemand sieht. Geprueft wird der Satz mit Link darin, das Satzzeichen am Ende, der Fall ohne Link (Feld zum Einfuegen statt Fehlermeldung), das Eintragen, die Dublette, das zweite Brett -- und dass share_target in BEIDEN Manifesten steht. Ohne den Eintrag erscheint der Workspace gar nicht erst im Teilen-Menue, und die ganze Seite waere unerreichbar, ohne dass eine der anderen 26 Pruefungen es merkt. GEGENPROBE: nur `url` lesen statt aller drei Felder -- also genau die naheliegende Fassung, die im Test funktioniert und auf dem Handy versagt -> 8 Pruefungen rot. Stempel 202609171416. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d69eb34448 |
Die Kanalzeile -- und der Kasten, der auf dem Chili-Motiv stand
SCHRITT 3 AUS DEM VIDEO-PLAN: DIE KANALZEILE
Filipe: "fuer meinen Account, dogfather, dann dogfather clips und
hasidog." Sobald Videos aus drei Kanaelen nebeneinander liegen, ist die
erste Frage nicht "welche Art", sondern "von welchem Kanal".
ALS ZWEITE DIMENSION, nicht als weiterer Wert in derselben Leiste. Der
vorhandene Filter ist EIN Wert (Alle / Nur offene / die Arten); wer den
Kanal dort hineinpresst, kann "nur offene Clips von HasiDog" nicht mehr
fragen. Zwei getrennte Reihen zeigen ausserdem, dass es zwei Fragen
sind -- in einer Zeile klickt man das zweite und wundert sich, warum
das erste wieder aus ist.
SIE ERSCHEINT NUR AB ZWEI KANAELEN, und die Kanaele werden aus den
vorhandenen Eintraegen abgeleitet statt aufgezaehlt. Auf einem Brett
ohne Videos steht keine leere Leiste; bei einem Kanal steht kein
Filter, der nichts tut. Ein Knopf, bei dem nichts passiert, kostet das
Vertrauen in den naechsten.
Die drei Toene sind dieselben wie am Zeichen auf der Karte -- wer
"DogFather Clips" in Tuerkis filtert, findet darunter Karten mit
tuerkisem Zeichen. Ungewaehlt bleiben sie gedeckt: drei bunte Knoepfe
nebeneinander waeren eine Ampel, und eine Ampel sagt "gut/schlecht",
wo nur "welcher Kanal" gemeint ist.
DER KASTEN, DER AUF DEM CHILI-MOTIV STAND
Der leere Zustand der Talente-Seite von heute Vormittag hatte nur einen
gestrichelten Rand. Solange dort EIN Satz stand, ging das; jetzt stehen
dort drei Absaetze, fuenf Merkmale und zwei Knoepfe -- und das
Spicy-Media-Motiv mit Chilischoten und Neonlicht schien voll durch den
Text. Lesbar war das nicht, augenschonend erst recht nicht.
DIE WARNUNG STAND 70 ZEILEN WEITER UNTEN in derselben Datei, bei
.t-fuss, und beschreibt exakt diesen Fehler ("Sie stand als einziger
Text der Seite direkt auf der Buehne"). Ich habe sie gelesen und bin
trotzdem hineingelaufen. Ein Kommentar, der vor einem Fehler warnt,
verhindert ihn nicht -- gefunden hat es erst das Bildschirmfoto.
GESEHEN STATT GEZAEHLT (server/bild-stufen.mjs)
Stufenleiter und Talente-Seite waren heute Vormittag nur an Zahlen
geprueft. Das Bild zeigte: die Leiste sitzt sauber in einer Zeile
(1400 px) und in vier auf 412 px, nichts laeuft ueber den Rand, keine
Konsolenfehler -- und den Kasten ohne Grund.
DIE PRUEFUNG (server/pruef-kanalzeile.mjs, 14 Pruefungen)
Sie prueft nicht nur, DASS gefiltert wird, sondern dass das Richtige
uebrig bleibt: "weniger" allein waere auch erfuellt, wenn der Filter
irgendetwas wegwirft. Dazu der zweite Klick (hebt auf) und Abschnitt 4:
Kanal UND Art zusammen -- der eigentliche Grund fuer zwei Reihen.
ZWEI GEGENPROBEN:
a) Kanalfilter ausgebaut -> 3 Pruefungen rot
b) Zeile immer anzeigen -> 1 rot, genau der Ein-Kanal-Fall
UND ZWEI FEHLER IN DER PRUEFUNG SELBST, beide von mir:
* Der Kartenselektor traf nichts, und die Messung meldete "0 -> 0".
Das sah aus wie ein Ergebnis und war keins.
* Beim Berichtigen machte String.replace aus "$$" ein "$" --
seite.$$() wurde zu seite.$(). Der Fehler steht woertlich in den
Hausregeln und hat trotzdem zugeschlagen. Aufgefallen ist er nur,
weil "undefined" in der Ausgabe stand; "0" waere durchgegangen.
* Und eine verlorene Escaping-Ebene machte aus /\s+/ ein /s+/ --
die Pruefung ersetzte jedes "s" durch ein Leerzeichen und las
"Ca per chläft im Wä chekorb". Sie wurde rot, und das war richtig.
Stempel 202609171407.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8f0a184b9f |
Was DogFather eintraegt, sehen jetzt auch die anderen -- und 113 fertige Inhalte
Vier Bildschirmfotos, vier Auftraege. Vor dem Bauen gemessen
(server/mess-sichtbarkeit.mjs): alle Bereiche, alle vier Rollen.
ZWEI FEHLER, DIE NIEMAND GEMELDET HAETTE
Beide sahen auf DogFathers eigenem Bildschirm vollkommen richtig aus --
und das ist das Tueckische: Ein leeres Brett sieht nicht nach Fehler
aus, sondern nach "da ist eben noch nichts".
1. DIE FREIGABE. "Was ansteht" und "Highlights" zeigen der Community
nur, was freigegeben ist. Ein aus dem Vorschlagskasten uebernommener
Eintrag hatte keine Freigabe. Gemessen:
Brett DogFather rechte Hand Modi Community
ansteht 4 4 4 0
highlight 3 3 3 0
Filipe konnte fuellen, so viel er wollte -- fuer die Community
blieben genau die zwei Bretter leer, auf die es ankommt. Wer aus dem
Team uebernimmt, gibt jetzt zugleich frei: Die Freigabe fragt "hat
das Team diesen Text gesehen?", und die Antwort ist beim Uebernehmen
ja. Eine zweite Entscheidung daneben waere keine Sicherheit, sondern
ein Klick.
2. TEAM_DOGI_ROLLEN IST {hand, modi} -- OHNE "admin". Die
Sichtbarkeitsregel fuer Team Dogi lautete damit woertlich "Eintraege
von hand oder modi". Folge: ALLES, was DogFather in Live, Technik,
Community, Ideen, Angebote oder Rueckmeldung schreibt, war fuer sein
eigenes Team unsichtbar. Das ist nicht erst seit dem Startkatalog so
-- der hat es nur sichtbar gemacht, weil vorher ueberall Null stand
und Null gleich Null aussieht, egal aus welchem Grund.
Die Liste wird genau dort erweitert, wo es um Sichtbarkeit geht --
NICHT in TEAM_DOGI_ROLLEN selbst: Diese Menge entscheidet auch,
welches Haus jemand bewohnt. Ein Eintrag dort haette DogFather
stillschweigend zur Crew umgezogen.
113 FERTIGE INHALTE IN DEN LEEREN KATEGORIEN
Gemessen waren elf Bereiche ausserhalb des Treffs komplett leer -- fuer
JEDE Rolle. Der Startkatalog kannte nur die sieben Treff-Bretter; die
Oberflaeche war die ganze Zeit bereit, es fehlten nur die Texte.
workspace-arbeit-start.js fuellt neun davon: Live, Content, Technik,
Community, Schutz, Ideen, Rueckmeldung, Angebote, Agentur.
"talente" und "entwicklung" bekommen ABSICHTLICH nichts: Dort waere ein
"fertiger Inhalt" ein erfundener Mensch -- ein Testdatensatz in einem
System, das echte Menschen bewertet. Die Talente-Seite bekommt ihre
Hilfe anders (siehe unten).
DER ENTWICKLUNGSKATALOG: 28 -> 68 PUNKTE, VIERTE STUFE
Filipe: "wieso ist da immer noch nicht perfektionniert wie bei den
anderen mit fortgeschritten und so, und VIIIIIEEEELLLLLL mehr aufgaben."
* Neue Stufe "Fortgeschritten" zwischen "nach ein paar Monaten" und
"wofuer man jemanden fragt" -- genau die Mitte fehlte.
* Stufenleiter als FILTER ueber den Kategorien, wie die Checkliste es
seit dem 10.09. vormacht. Aus r.erwartung gebaut, nicht aufgezaehlt.
* Zwei neue Bloecke, die Filipe ausdruecklich wollte: "Clips, Schnitt
und Kommentare" und "Waehrend der Stream laeuft" -- seine
Wunschkategorien vom 17.09. ("videos schneide, kommentieren,
markierungen").
* Keine Note, keine Punktzahl, keine Rangliste. Unveraendert.
DAS BEFINDEN: 6 -> 12 FRAGEN, UND SIE MELDET SICH VON SELBST
Den 14-Tage-Rhythmus gab es schon -- er wirkte aber nur, WENN jemand die
Seite aufmachte. Wer sie vergisst, wurde nie wieder gefragt: Das war
eine Anzeige, keine Anfrage. Jetzt kommt sie ueber dasselbe Push-System
wie faellige Aufgaben, hoechstens einmal je sieben Tage, und sie fragt
rhythmus() aus workspace-befinden.js -- dieselbe Funktion wie die Seite,
keine zweite Formel daneben.
Sechs neue Fragen zu Erholung, Sinn, Klarheit, Anfeindung, Entwicklung
und dem Blick nach vorn, jede mit ihrer Einordnung.
Und an acht Stellen stand "sechs Fragen" ueber zwoelf Fragen -- wo ein
Skript den Text baut, wird jetzt gezaehlt; in den festen Seiten steht
gar keine Zahl mehr.
DIE TALENTE-SEITE, WENN NIEMAND DARAUF STEHT
Statt "Noch niemand auf der Liste" stehen dort jetzt die fuenf Gruppen
mit ihren 21 Anzeichen -- die gab es laengst, sie waren auf der leeren
Seite nur nie zu sehen. Dazu der Weg in beide Richtungen: woher ein
Talent kommt (der Treff) und wo es endet (die Entwicklung).
DIE PRUEFUNG (server/pruef-alle-sehen-es.mjs, 42 Pruefungen)
Sie prueft BEIDE Haelften von Filipes Satz. Nur zu zaehlen, ob alle
alles sehen, waere gruen, wenn man saemtliche Schranken entfernte --
Abschnitt 4 belegt, dass 19 Bereich-Rollen-Paare zu bleiben und die
Community an keinen der elf Arbeitsbereiche kommt.
ZWEI GEGENPROBEN, weil 42 von 42 im ersten Lauf kein Beweis ist:
a) "admin" aus der Team-Sicht entfernen -> 13 Pruefungen rot
b) Freigabe beim Uebernehmen abschalten -> 2 rot, genau ansteht
und highlight
Jede trifft ihr Ziel und nicht alles.
UND EINE LUECKE IN EINER ALTEN PRUEFUNG
pruef-deutsche-texte war gruen -- und hatte die 113 neuen Texte, die 40
neuen Entwicklungspunkte und die 6 neuen Fragen nie gesehen: Sie stehen
in Dateien, die sie nicht kannte. Jetzt 391 statt 174 geprueften
Texten. (Meine erste Untergrenze stand auf 400 und war sofort rot --
geraten statt gemessen.)
Stempel 202609171318.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
f05783ebc8 |
Link einfuegen, Video steht in der App -- Stufe A des Video-Plans
Filipe: "damit meine videos auch da auf der app rein kommen ... sobald
ich ein video poste erscheint es sofort in der app fuer die ganze
community ... dass man das Coverbild und den Text sieht ... fuer meinen
Account, dann DogFather Clips und HasiDog."
Der Weg, der HEUTE funktioniert -- ohne Freigabe, ohne Geheimnis, ohne
Wartezeit: Adresse einfuegen, alles andere geht von allein.
Link -> oEmbed (Titel, Cover-Adresse, Account)
-> Cover HERUNTERLADEN und bei uns ablegen
-> Eintrag mit Bild, Text und Knopf zum Video
DAS COVER WIRD KOPIERT, NICHT VERLINKT -- der wichtigste Satz.
TikToks Bildadresse ist signiert und laeuft ab. Heute an einem echten
Video nachgemessen: x-expires = 1789812000, also in 48 Stunden. Wer sie
nur speichert, hat uebermorgen schwarze Kacheln. Beim Bauen merkt man
das nicht und beim Testen auch nicht -- es faellt erst am uebernaechsten
Tag auf, und dann sieht die ganze App kaputt aus.
Deshalb wandert das Bild in dieselbe Ablage wie jeder Anhang und geht
durch dieselbe Bytepruefung. Ein heruntergeladenes Cover ist eine
FREMDE Datei; dass der Typ hier von einem fremden Server behauptet wird
statt vom eigenen Browser, macht ihn nicht glaubwuerdiger.
NUR SEINE EIGENEN KANAELE. Der Account aus der Antwort wird gegen
KANAELE geprueft (kanalVonHandle). Genommen wird author_url (.../@name),
nicht author_name -- der Anzeigename aendert sich, wenn jemand ihn
umstellt. Ein fremdes Video in Filipes Highlights waere nicht bloss
falsch einsortiert, es waere fremder Inhalt unter seinem Namen: 403.
DIE PRUEFUNG SCHALTET TIKTOK AB (server/pruef-video.mjs, 37 Pruefungen)
Ein nachgebauter Dienst auf 127.0.0.1 antwortet wie TikTok, mitsamt
Ablaufstempel. Im letzten Abschnitt wird er ABGESCHALTET. Danach muss
die alte Cover-Adresse ins Leere laufen und unsere weiterhin ein Bild
liefern -- beides wird gemessen, nebeneinander. Waere das Bild nur
verlinkt, waeren beide tot, genau wie uebermorgen im Betrieb.
Die Adresse des Dienstes kommt aus TIKTOK_OEMBED_BASIS. Steht sie nicht
da, gilt TikTok -- kein Verhalten, das sich still aendert. Eine
Pruefung, die das echte TikTok braucht, misst fremde Verfuegbarkeit
statt unseren Code und wird irgendwann rot, ohne dass etwas kaputt ist.
VIER GEGENPROBEN, weil 37 von 37 im ersten Lauf kein Beweis ist:
a) Cover nicht mehr kopieren -> 9 Pruefungen rot
b) author_name statt author_url -> 22 rot
c) Bytepruefung entfernen -> 2 rot (genau Abschnitt 5)
d) Dublettenpruefung entfernen -> 4 rot (genau Abschnitt 4)
Jede schlaegt dort an, wo sie soll. Und eine fuenfte Gegenprobe ist ins
Leere gelaufen: Der Patch lief ueber python3, das es hier nicht gibt --
die Datei blieb unveraendert und der Lauf war gruen. Haette ich die
Ausgabe nicht gelesen, haette ich behauptet, die Pruefung koenne rot
werden, ohne sie je rot gesehen zu haben. Der dritte Ausgang, an mir
selbst.
DAZU:
- eintraege.quelle_url / quelle_kanal / quelle_geholt_am (Umstellung)
- KANAELE bekommt handle, dazu kanalVonHandle()
- videoRouter steht VOR bereicheRouter, sonst schluckt /:bereich ihn
- Eingabefeld und Kanal-Knopf in bereich.html/.js, Farben wie bei den
Aufgaben-Kanaelen
- Stempel 202609171249
Nicht darin: die Kanal-Filterzeile in der Galerie, die Handy-Verknuepfung
(Teilen -> Workspace) und der Zustand "nicht mehr da" fuer geloeschte
Videos. Stufe B (Display API) braucht Filipes Entwickler-Freigabe.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
4a440e42d8 |
Die Community-Texte sind auf DogFather bezogen
Filipe, mit einem Bildschirmfoto der fertigen Vorschlaege im Treff:
"die sachen sollen immer auf mich bezogen sein bitte. ich, dogfather
bin der mittelpunkt immer."
Er hatte recht, und es war MESSBAR: 47 Eintraege, "DogFather" kam
FUENFMAL vor, ein namenloses "wir" sechzehnmal. Das las sich wie der
Community-Bereich von irgendwem.
Jetzt 39 von 52 (75 %) -- und die vier Bretter, die die Community
wirklich sieht, zu 100 %: Treff, Anschlagbrett, Wunschliste,
Highlights. Dazu fuenf neue Eintraege, die es vorher gar nicht gab
("Wer ist DogFather ueberhaupt?", "Was soll Casper mal machen?",
"Mehr mit Casper", "Die drei Kanaele", "Ein Ausschnitt fuer die
Clips").
Aus "Was sollen wir im naechsten Stream machen?" wird "Was soll
DogFather im naechsten Stream unbedingt machen?". Aus "Sag Hallo -- wie
bist du hier gelandet?" wird "ueber welchen Kanal bist du gekommen?"
-- und nennt die drei beim Namen.
UND ES WIDERSPRICHT DER ANDEREN REGEL NICHT.
Filipe am 18.08.2026: "mich bitte nie wie da hoeher stellen wie andere,
ich bin genau so viel wert wie die andere." Das galt dem TEAM --
Manager, Scouts, Modis. Hier geht es um die Community, und die ist
wegen seiner Streams da. Wo das Team in diesen Texten vorkommt, steht
es weiter auf Augenhoehe: Es moderiert, es entscheidet im Alltag
selbst, es wird nicht als Gefolge beschrieben. In "Wer entscheidet
das" steht beides nebeneinander.
WARUM EINE QUOTE UND NICHT "JEDER TEXT":
Bei der Telefonseelsorge oder "Melden ist kein Petzen" waere ein
eingebautes "DogFather" aufgesetzt. Ein Text, der den Namen trotz
allem traegt, ist schlechter als einer ohne. Deshalb 60 % als Grenze
und 100 % dort, wo es um seine Streams geht.
pruef-treff-start jetzt 41 Pruefungen, mit Gegenprobe in beide
Richtungen: Ein anonymer Satz MUSS erkannt werden, ein bezogener darf
nicht faelschlich anschlagen.
pruef-deutsche-texte 12 gruen -- die neuen Texte tragen echte Umlaute.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
4bd19a4096 |
Die Community-Rolle laesst sich endlich anlegen
Filipe: "und wieso kann ich immer noch keine community rolle
erstellen?"
Nachgemessen statt geraten: Die Auskunft schickte "gast/Community" als
waehlbare Rolle mit, die Oberflaeche baute den Knopf daraus -- und das
Anlegen antwortete 400 "Unbekannte Rolle." Genau so reproduziert.
DIE URSACHE: EINE LISTE, ZWEI FRAGEN
Die Pruefung las `ROLLEN`, und `ROLLEN` ist `ROLLEN_REIHE` -- die
SORTIERREIHENFOLGE. Dort fehlt "gast" mit Absicht; der Kommentar in
workspace.js sagt es woertlich ("steht mit Absicht NICHT in der Liste,
sie faellt ans Ende").
`ROLLEN_REIHE` beantwortet "in welcher Reihenfolge", nicht "welche gibt
es". Genau davor wird in diesem Haus an zehn Stellen gewarnt -- und
hier stand es vier Zeilen ueber der Stelle, an der es passiert ist.
Gefragt wird jetzt `darfAnlegen` -- dieselbe Auskunft, aus der die
Oberflaeche ihre Knoepfe baut. Damit koennen die beiden nicht mehr
auseinanderlaufen.
ZWEI NEBENBEFUNDE, beide groesser als der gemeldete Fehler:
1. DIE ALTE PRUEFUNG LIESS "admin" DURCH. `ROLLEN_REIHE` enthaelt sie.
Filipes Regel vom 11.09. ("dogfather soll man nicht auswaehlen
koennen, das ist die einzige die man nicht auswaehlen kann") stand
nur in ANLEGBAR -- und die wurde hier nicht gefragt. Es liess sich
also ein zweiter DogFather-Zugang anlegen.
2. DIESELBE ZEILE STAND EIN ZWEITES MAL, beim Rollenwechsel. Auch eine
bestehende Person liess sich nicht zu "Community" machen. Dort stand
die richtige Pruefung (`darfAnlegen`) schon direkt darunter -- die
falsche davor kam ihr nur zuvor. Und sie antwortete gespraechiger
(403 "Diese Rolle vergibst du nicht." gegen 400 "Unbekannte
Rolle."); wer durchprobiert, haette daran ablesen koennen, welche
Rollen es gibt. Jetzt beide Faelle wortgleich.
Gefunden hat das nicht das Lesen, sondern die neue Pruefung: Ihre
Suche nach der alten Zeile reichte in die Nachbarroute hinein.
NEU: pruef-rollen-anlegen (11 Pruefungen)
Sie schreibt keine Liste ab, sondern holt sich die Rollen aus
`darfAnlegen` -- derselben Quelle wie Route und Oberflaeche -- und legt
JEDE davon wirklich an. Eine eigene Liste waere eine dritte gewesen und
damit dieselbe Falle noch einmal.
Dazu die Gegenproben: eine erfundene Rolle, eine leere, und ein zweiter
DogFather -- alle drei abgelehnt.
pruef-rollen 315, pruef-personen-formular 36, pruef-personen-liste,
pruef-rechtetafel 19: gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
79e675b846 |
Stufe 6 und 7: Der Treff wird ein Gespraech, jedes Brett bekommt seine Form
Damit sind alle acht Stufen des Plans gebaut. STUFE 6 -- DAS GESPRAECH "Der Treff -- Hallo sagen, fragen, loben" war eine Liste aus Karten. Der einzige Bereich, in dem Menschen MITEINANDER reden sollen, zwang sie, nebeneinander zu reden: Jeder schrieb eine eigene Karte, niemand antwortete jemandem. Jetzt: Antworten eingerueckt unter ihrem Beitrag, aelteste zuerst (so liest man ein Gespraech), mit Namen und Rolle. Das Feld steht immer da statt hinter einem "Antworten"-Knopf -- ein leeres Feld ist die deutlichste Einladung, die es gibt. Nur EINE Stufe eingerueckt: Auf 390 px ist bei der zweiten Schluss. Eine EIGENE Tabelle, kein Eintrag mit "antwort_auf": Eine Antwort hat keine Art, keinen Zustand, keine Frist und gehoert in keinen Filter. Als Eintrag gefuehrt haette sie zwanzig immer leere Spalten -- und tauchte in jeder Zaehlung auf, die Beitraege zaehlt. Und nicht ueberall: nur Treff und Wunschliste. Aus dem Plan, §9 -- ein Antwortfeld unter jedem Aushang hiesse, jeder Aushang muss betreut werden. ZWEI FEHLER, BEIDE VON DER PRUEFUNG GEFUNDEN 1. EIN PFAD, DER AUSSAH WIE EIN BEREICH. `/api/bereich/antwort/:id` lief in die Middleware auf `/api/bereich/:bereich` -- "antwort" ist kein Bereich. Fuer DogFather ging es (ein frueherer Zweig liess ihn durch), fuer einen Modi kam 404. Ein Weg, der je nach ROLLE an voellig anderer Stelle scheitert, sucht man lange. Liegt jetzt unter `/api/antwort/:id`. 2. UND EIN ECHTES LOCH. Die Loeschregel hiess `!darfSchreiben(req.person, "treff")` -- also "wer schreiben darf", und das duerfen Gaeste ab der Stufe "dabei". JEDER GAST HAETTE JEDE FREMDE ANTWORT LOESCHEN KOENNEN. Gefunden hat es eine Pruefung mit einer FALSCHEN Erwartung: Sie verlangte, dass ein Modi keine fremde Antwort loeschen kann. Das war falsch -- er moderiert ja --, aber der Weg dorthin hat das echte Problem freigelegt. Jetzt entscheidet TREFF_TEAM_ROLLEN. Der Gast-Fall ist ueber HTTP nicht messbar (er kommt nur ueber die crew-Adresse herein, und den Host-Kopf kann fetch nicht setzen). Statt stillschweigend zu ueberspringen prueft die Pruefung die REGEL selbst -- und dass die Route wirklich diese Menge benutzt. STUFE 7 -- JEDES BRETT BEKOMMT SEINE FORM - "Regeln & Hilfe" ist ein DOKUMENT: Sprungmarken oben, vier Abschnitte (Regel, Was passiert wenn, Hilfe, Haeufige Frage). Man schlaegt es im Streitfall auf und will FINDEN, nicht scrollen. scroll-margin-top, sonst verschwindet die angesprungene Ueberschrift unter der Kopfleiste und der Sprung sieht aus wie ins Leere. - "Anschlagbrett" zeigt grosse AUSHAENGE statt Zeilen -- gemessen 21 px Titel statt 17. Ein Aushang zwischen dreissig anderen ist kein Aushang. - "Mitmachen" gruppiert nach Art, die drei Schritte zuerst. UND EINE SCHRIFT, DIE ZU KLEIN WAR: Die Rollen-Marke an einer Antwort stand auf 11,2 px, die Hausgrenze liegt bei 11,5. Die Grenze anzuheben waere der bequeme Weg gewesen -- und ab da haette pruef-css-klassen nichts mehr gehalten. NEU: pruef-gespraech (27 Pruefungen) pruef-treff-start jetzt 34 (Stufe 7 mitgeprueft) Alle Community-Pruefungen gruen: gespraech 27, treff-start 34, kreislauf 23, countdown 22, wunschliste 30, galerie 26, bremse 16, treff 66, bereiche-lesend, css-klassen, deutsche-texte 12. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b396e548ab |
Stufe 8: Der Kreislauf -- ein Wunsch kommt als Clip zurueck
Bisher waren die acht Bretter acht Silos. Ein Wunsch wurde angenommen,
irgendwann passierte etwas im Stream, irgendwann lag ein Clip bei den
Highlights -- und nichts davon wusste voneinander. Wer den Wunsch
geschrieben hatte, erfuhr NIE, dass er erfuellt wurde.
Wunsch -> Termin bei "Was ansteht" -> Clip bei "Highlights"
Das ist der Unterschied zwischen einem Briefkasten und einer Community.
Jemand schreibt einen Wunsch und sieht ihn vier Wochen spaeter als Clip
wieder -- mit seinem Namen daneben.
ZUM DRITTEN MAL LAG DER PLAN DANEBEN. Dort stand "`aus_eintrag_id`
gibt es in der Tabelle bereits". Gibt es -- an den AUFGABEN. Die
Eintraege hatten nichts dergleichen. Dreimal an einem Tag, und jedes
Mal hat es das Messen gefunden, nicht das Nachdenken.
EINE HANDLUNG, KEIN AUSWAHLFELD. Der Zusammenhang entsteht durch
"daraus wird ein Termin" -- als Knopf an dem Wunsch, um den es geht.
Wer ein Formular ausfuellt, denkt nicht an den Wunsch von letzter
Woche, und ein Auswahlfeld mit vierzig Eintraegen benutzt niemand.
Die Kette steht auf beiden Karten: "Aus Wunschliste: ... von Lena"
(ruhig, es ist Herkunft) und "Daraus wurde: Highlights ..." (gruen, das
ist die Nachricht, auf die jemand gewartet hat).
ON DELETE SET NULL, nicht CASCADE: Wird der Wunsch geloescht, bleibt
der Clip. Er ist ja trotzdem passiert.
UND DIE PRUEFUNG VON STUFE 2 HAT STUFE 5 ERWISCHT.
Der Startkatalog stand ueber dem Countdown und schob die Antwort auf
"wann ist der naechste Stream" von 458 px auf 1488 px -- aus dem
ersten Handybildschirm heraus. Gefunden hat das nicht das Auge,
sondern das Abnahmekriterium aus §7 des Plans, das seit heute Vormittag
in pruef-countdown steht.
DIE REGEL DARAUS: Ein WERKZEUG (fuer das Team) draengt nie eine
ANTWORT (fuer alle) nach unten.
Der Countdown steht jetzt ganz oben, noch vor den Filtern -- gemessen
342 px statt 458.
NEU: pruef-kreislauf (23 Pruefungen)
Lena schreibt einen Wunsch, daraus wird ein Termin, daraus ein
Highlight. Geprueft: Der Titel wandert mit, der NAME wandert mit, beide
Enden sehen die Kette, Lena sieht sie auch (ein Kreislauf, den nur das
Team sieht, ist keiner), zweimal derselbe Weg verdoppelt nichts -- und
die Gegenprobe, dass ein ANDERER Weg vom selben Wunsch sehr wohl geht.
Und wohin sie NICHT fuehrt: nicht in die Content-Planung eines
Creators. Dort steht Arbeit, die die Community nichts angeht.
pruef-countdown 22, pruef-treff-start 27, pruef-wunschliste 30,
pruef-galerie 26, pruef-treff 66, pruef-bremse 16, pruef-css-klassen:
alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
7701f5e5e5 |
47 fertige Inhalte statt acht leerer Bretter
Filipe, mit drei Bildschirmfotos nebeneinander -- Der Treff, das
Anschlagbrett, Was ansteht, alle drei mit demselben grauen Kasten:
"ich meine alle kategorien sehen einfach so scheisse und leer aus,
ich will fertige sachen schon drin wo auch die community und alle
anderen benutzen koennen"
Er hat recht, und das ist mein Fehler: Es stand in MEINEM Plan, §5.1
-- "Acht leere Seiten sind schlimmer als keine." Ich habe es
aufgeschrieben und danach fuenf Stufen lang Technik gebaut.
Dreimal derselbe Satz auf drei Bildschirmen sieht nicht nach "neu" aus,
sondern nach defekt.
WAS JETZT BEREITLIEGT (47 Eintraege)
Regeln & Hilfe 15 das Nachschlagewerk: sechs Regeln, drei
Folgen-Erklaerungen, drei Hilfen, drei Fragen
Mitmachen 11 der Weg in drei Schritten, vier Aufgabengebiete,
vier ehrliche Fragen ("Was habe ich davon?")
Der Treff 6 Gespraechsanfaenge, auf die man in einem Satz
antworten kann
Anschlagbrett 5 Willkommen, Ablauf, wo was hingehoert, Danke
Wunschliste 4 Beispiele, die zeigen, wie ein guter Wunsch
aussieht
Was ansteht 4 Terminvorlagen
Highlights 2 was hier hingehoert
NICHT AUTOMATISCH BEIM START. Ein Text, den niemand gelesen hat,
stuende sonst als Ansage des Teams auf einer oeffentlichen Seite.
"Bleibt fair" klingt harmlos, bis jemand fragt, was das im Streitfall
heisst -- und dann muss dahinterstehen, WER es gemeint hat. Uebernehmen
ist eine Entscheidung; automatisch fuellen waere eine Behauptung. Und
jeder Text laesst sich vorher aendern.
ZWEI BEREICHE SIND KEIN KATALOG, SONDERN FERTIGE SEITEN: "Regeln &
Hilfe" und "Mitmachen" sind Nachschlagewerke, keine Feeds. Ein leeres
Regelwerk ist schlimmer als gar keins -- im Streitfall hat dann niemand
etwas in der Hand. Die Regeln sagen ausserdem jeweils, was PASSIERT,
nicht nur was verboten ist, und die Hilfe nennt die Telefonseelsorge.
UND JEDER BEREICH SAGT JETZT SEINEN EIGENEN SATZ, wenn er leer ist:
"Gerade gilt nichts Besonderes. Das ist eine gute Nachricht." /
"Noch hat niemand Hallo gesagt. Sei der Erste -- ein Satz reicht."
DIE FALLE, DIE ICH MIR SELBST GEBAUT HATTE: Die Bremse aus Stufe 4
zaehlt zehn Beitraege je Stunde. Wer fuenfzehn Regeln uebernimmt,
haette nach der zehnten eine halb gefuellte Seite und die Meldung, er
habe zu viel geschrieben -- genau die Sorte Sicherung, die das richtige
Verhalten bestraft und deshalb abgeschaltet wird. Das Uebernehmen ist
eine einzelne Handlung des Teams und geht nicht durch die Bremse; die
Pruefung weist beides nach.
NEU: pruef-treff-start (27 Pruefungen)
Der Katalog selbst (jede Art gibt es im Bereich, jeder Text sagt mehr
als sein Titel, kein Titel doppelt, echte Umlaute), das Uebernehmen
(einzeln, alle, zweimal verdoppelt nichts), die Verborgenheit, die
sieben verschiedenen Leertexte -- und im Browser: elf Vorschlaege,
ein Klick, elf Eintraege, Katalog verschwindet.
pruef-treff 66, pruef-bremse 16, pruef-deutsche-texte 12,
pruef-bereiche-lesend, pruef-css-klassen: gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
4b14906371 |
Stufe 5: Highlights als Galerie -- und ein enger Weg fuer Bilder
Aus dem Plan im Vault. "Eure Clips und Bilder" zeigte Textkarten mit
einem Anhang darunter. Ein Bild als Anhang unter einer Ueberschrift ist
kein Highlight -- dieser Bereich lebt vom Sehen. Jetzt steht das Bild
OBEN, der Text ist Bildunterschrift.
ZWEI DINGE WAREN ANDERS ALS IM PLAN
1. "Anhaenge sind schon da" stimmte nicht. Sie hingen an AUFGABEN
(`dateien.aufgabe_id`); ein Eintrag konnte gar kein Bild tragen.
Neue Spalte `eintrag_id`.
2. UND DER WICHTIGE, ein Sicherheitsthema: Alles in dieser Ablage geht
bewusst als DOWNLOAD hinaus (`application/octet-stream`,
`Content-Disposition: attachment`). Eine hochgeladene HTML- oder
SVG-Datei wuerde sonst im Browser als Seite DIESER Domain laufen --
mit Zugriff auf die Sitzung. Eine Galerie braucht also einen
eigenen, engen Weg, keine Lockerung der alten Regel.
DIE FRAGE "IST DAS EIN BILD?" DARF NICHT `dateien.typ` BEANTWORTEN.
Diese Spalte traegt den vom Browser BEHAUPTETEN Typ
(`req.get("content-type")`) -- wer hochlaedt, bestimmt ihn selbst. Eine
Galerie, die ihm glaubt, liefert auf Zuruf alles inline aus. Erkannt
wird deshalb an den ERSTEN BYTES: PNG, JPEG, GIF, WEBP.
SVG IST AUSDRUECKLICH NICHT DABEI. Es ist ein Bildformat UND kann
Skript enthalten -- genau die Luecke, gegen die die Regel gebaut wurde.
Ein Format, das beides ist, gehoert nicht in die Ausnahme.
Kein Bild heisst 404, nicht 415: Eine eigene Antwort waere die Auskunft
"diese Nummer gibt es, sie ist nur kein Bild", und die laesst sich
durchzaehlen.
WESSEN REGEL GILT: Ein Bild am Community-Beitrag folgt dem BEITRAG,
nicht der Dateiablage. Deren Regel haengt an Creator-Zuordnungen, und
ein Gast hat keine -- er saehe sonst nie ein Highlight, obwohl es fuer
ihn gemacht ist.
NEU: pruef-galerie (26 Pruefungen)
Der Beweis steht in zwei Zeilen: Am Beitrag haengen VIER Dateien --
zwei echte PNGs, ein SVG und eine HTML-Datei, die sich als
"image/png" ausgibt. Im Raster stehen ZWEI. Die anderen beiden holt
der Browser, bekommt 404, und der error-Handler raeumt sie weg: kein
leerer Rahmen, kein kaputtes Symbol.
Dazu die Gegenprobe in die andere Richtung -- ein echtes PNG, das sich
als "text/plain" ausgibt, geht durch. Ohne sie hiesse "404" nur, dass
der Weg immer ablehnt. Und die Konsolenpruefung laesst genau die zwei
gewollten 404 zu und nichts sonst; ein pauschales "Konsole egal" haette
jeden echten Fehler mitversteckt.
EIN EIGENER FEHLER: Mein Test-PNG war kein dekodierbares Bild, nur ein
Dateikopf. Der Browser konnte es nicht zeichnen, der error-Handler
raeumte es weg, und die Pruefung fand im Raster nichts. Fehler in der
Pruefung, nicht im Haus -- aber ein nuetzlicher: Er hat nebenbei
gezeigt, dass ein kaputtes Bild keinen leeren Rahmen hinterlaesst.
pruef-anhaenge 37, pruef-treff 66, pruef-bereiche-lesend,
pruef-css-klassen: gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
670940bd3a |
Stufe 4: eine Bremse -- und eine stille Sperre, die es nicht gibt
Aus dem Plan im Vault. Diese Stufe steht dort bewusst VOR Galerie und
Gespraech: Mehr Sichtbarkeit heisst mehr Angriffsflaeche, und ein
Bereich, der waechst und keine Bremse hat, waechst genau einmal.
DER TREFF HATTE SCHON MEHR, ALS MEIN PLAN ANNAHM
Stufen (WER schreiben darf: neu, dabei, stamm) und Massnahmen (wer
NICHT MEHR darf: Hinweis, Pause, Ausschluss). Gefehlt hat die Frage
dazwischen: WIE SCHNELL. Ein Stammgast konnte in einer Minute vierzig
Beitraege absetzen -- aus Aerger, aus Versehen oder per Skript.
DIE STILLE SPERRE IST VERWORFEN -- nach einer Messung, nicht nach
einem Gefuehl. `gast` ist eine Rolle mit Zugangscode, es gibt KEINE
Selbstanmeldung. Wer ausgeschlossen wird, kann sich nicht neu
anmelden. Damit loest ein Shadowban ein Problem, das dieses System
nicht hat; er bliebe ein Werkzeug, das Menschen taeuscht, ohne etwas
zu verhindern. Steht jetzt in §9 des Plans: was wir NICHT bauen.
DIE BREMSE: 10 Beitraege je Stunde und Person, nur auf den
Community-Brettern. Keine neue Tabelle -- die Antwort steht schon in
`eintraege`, eine Zaehlung ueber die letzte Stunde genuegt. Eine eigene
Tabelle waere ein zweiter Ort fuer dieselbe Wahrheit und muesste
zusaetzlich aufgeraeumt werden.
Die Absage sagt, WANN es weitergeht ("In 37 Minuten"). Ohne Zeitangabe
probiert jemand im Minutentakt weiter -- genau die Last, die man
verhindern wollte.
MEIN ERSTER ENTWURF BREMSTE DIE FALSCHE ARBEIT: Er zaehlte ALLE
Eintraege. Eine Creatorin mit zehn Content-Ideen haette danach im Treff
nichts mehr schreiben koennen. Eine Bremse, die das richtige Verhalten
bestraft, wird abgeschaltet -- und ist ab da wirkungslos.
DIE TEAM-SICHT: "Was hereinkommt", ganz oben auf der Moderationsseite,
vor den offenen Meldungen. Eine Meldung setzt voraus, dass jemand etwas
GESEHEN hat -- und wer acht Bretter durchklicken muss, tut das nicht
achtmal am Tag. Eine Zeile je Beitrag statt einer Karte: Hier
ueberfliegt man, man liest nicht. Der Inhalt steht auf dem Brett; eine
Vorschau waere eine zweite Stelle, an der derselbe Beitrag steht.
NEU: pruef-bremse (16 Pruefungen)
Die Grenze wird aus dem Code GELESEN, nicht abgeschrieben -- sonst
misst die Pruefung beim naechsten Anpassen etwas anderes als der
Server tut. Dazu die drei Fragen: Greift sie? Trifft sie die richtige
Arbeit (Content bleibt offen, das zweite Treff-Brett nicht)? Und laesst
sie den normalen Fall in Ruhe? Gegenprobe: Beitraege auf vorgestern
zurueckdatiert -- danach muss es sofort wieder gehen.
pruef-treff 66, pruef-wunschliste 30, pruef-countdown 22,
pruef-bereiche-lesend, pruef-css-klassen: gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
7eec2edf3f |
Stufe 3: Die Wunschliste bekommt einen Rang und einen Weg
Aus dem Plan im Vault. Eine Wunschliste ohne sichtbare Erfuellung ist
ein Briefkasten ohne Postbote -- nach dem dritten unbeantworteten
Wunsch schreibt niemand mehr.
ZWEIMAL LAG MEIN PLAN DANEBEN, beide Male zu pessimistisch:
- Die Sortierung nach Stimmen GAB es schon, seit dem 11.09.
- Die Datenbank erlaubte 'angenommen' und 'abgelehnt' laengst in ihrer
CHECK-Regel; nur die Pruefung im Server liess sie nicht durch. Die
Tabelle war der Logik voraus.
Auch ein Plan von gestern Nacht ist eine Bestandsliste und altert.
WAS DAZUGEKOMMEN IST
- Vier Zustaende JE BEREICH statt zwei global: Offen -> Wird gemacht
-> Gemacht, dazu "Diesmal nicht". Eine gemeinsame Liste haette
"Diesmal nicht" auch an einem Schutzvorfall erlaubt, und dort
bedeutet es nichts.
- Ein geplanter Tag dazu: "Wird gemacht" allein ist ein Versprechen,
"Wird gemacht -- am 24.09." ist ein Termin.
- Der Rangbalken. Eine Rangfolge sieht man erst, wenn der ABSTAND
sichtbar ist: 12 Stimmen neben 14 sehen sonst aus wie 1 neben 40.
Fuer ein Vorleseprogramm spricht er in Worten.
- Entschiedenes rutscht nach unten, wird aber NICHT geloescht. Gerade
der erfuellte Wunsch ist der Beweis, dass sich Schreiben lohnt.
"DIESMAL NICHT" IST DER WICHTIGSTE DER VIER, und es ist bewusst nicht
rot. Ein Nein ist eine Antwort, Schweigen ist keine -- aber wer ein
rotes Schild an seinem Wunsch sieht, schreibt keinen zweiten.
UND AUF DEM BILDSCHIRMFOTO STAND "WAS IHR EUCH WUENSCHT".
Die Umlaut-Pruefung von gestern Nacht sah es nicht: Sie kannte die
Kataloge und die festen Seitentexte, aber nicht die
Bereichseinstellungen, aus denen JEDE Ueberschrift und jede
Art-Beschriftung kommt. Sechs Stellen ("Fuer den Stream", "Wie es hier
laeuft", "Haeufige Frage", "Ich haette Lust" ...).
Gefunden hat sie kein Gedankengang, sondern ein Blick auf das fertige
Bild. Die Wortliste hatte ausserdem Loecher -- "wuensch" fehlte
schlicht; 23 Stuecke nachgetragen. pruef-deutsche-texte deckt jetzt
auch die 120 Beschriftungen der Bereiche ab (9 -> 12 Pruefungen), mit
einer Gegenprobe auf genau den Satz, der heute Morgen durchrutschte.
NEU: pruef-wunschliste (30 Pruefungen)
Der aelteste Wunsch bekommt die meisten Stimmen -- genau der Fall, der
eine Sortierung nach Datum entlarvt. Dazu: alle vier Zustaende setzen,
ein erfundener nicht, "abgelehnt" am Anschlagbrett ABGELEHNT, der
geplante Tag, die Balkenbreiten (100/33/0 %), und dass der gemachte
Wunsch weiter in der Liste steht -- nur nicht mehr oben.
pruef-countdown 22, pruef-treff 66, pruef-bereiche-lesend,
pruef-deutsche-texte 12: gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
77db1bcc2e |
Stufe 2: "Wann ist der naechste Stream?" steht jetzt oben
Aus dem Plan im Vault. Bei "Was ansteht" gibt es genau EINE Frage, die
ein Zuschauer hat -- und sie stand in Zeile vier einer Liste wie jede
andere Angabe auch.
Jetzt ganz oben, gross:
ALS NAECHSTES
in 12 Std 15 Min
Abendstream
17.09.2026 um 23:30 Uhr
2 weitere Termine danach
Darunter wird die Liste zum ZEITSTRAHL: Heute und morgen · Diese Woche
· Spaeter · Ohne Datum · Vorbei. Vergangenes steht unten, nicht
dazwischen -- ein abgelaufener Termin zwischen kommenden liest sich wie
ein Fehler.
DER PLAN VERSPRACH ETWAS, DAS DIE DATEN NICHT HERGABEN.
"in 3 Std 12 Min" -- aber `eintraege.datum` ist ein TAG, und die
Pruefung im Server lehnte eine Uhrzeit ausdruecklich ab
(`^\d{4}-\d{2}-\d{2}$`). Ein Stundencountdown war unmoeglich.
Das ist die uebliche Sorte Planungsluecke: Sie steht nicht im Plan, sie
steht in der Datenbank. Neue Spalte `uhrzeit`, OPTIONAL -- viele
Termine haben keine ("diese Woche", "im Oktober"), und ein Pflichtfeld
haette dafuer eine erfundene erzwungen. Ohne Uhrzeit zaehlt der
Countdown in Tagen, und "morgen" ist eine ehrliche Antwort.
Der Ton folgt der NAEHE, nicht der Wichtigkeit: Was gleich anfaengt,
ist waermer. Das ist die einzige Information, die eine Farbe hier
tragen kann, ohne zu behaupten, ein Termin sei "besser" als ein
anderer. Kein Blinken, keine Animation -- auf dieser Seite steht
niemand unter Zeitdruck, er will es nur wissen.
NEU: pruef-countdown (22 Pruefungen)
Das Abnahmekriterium aus dem Plan, in Pixeln gemessen: Die Antwort MUSS
im ersten Bildschirm stehen (gemessen 458 px von 844) und groesser sein
als jede Fliesstextzeile (27 px). Dazu: Uhrzeit setzen, wiederfinden
und wieder ENTFERNEN; vier unmoegliche Zeiten; der Zeitstrahl mit
"Vorbei" ganz unten; und der leere Fall, in dem ein SATZ dasteht statt
einer leeren Flaeche.
UND EIN EIGENER FEHLER, gefunden von der eigenen Gegenprobe: Der
Testtitel war "X" -- ein Zeichen, der Server verlangt zwei. Vier
"wird abgelehnt"-Haken waren damit halb aus dem falschen Grund gruen.
Aufgefallen ist es nur, weil die Gegenprobe ("der gueltige Fall muss
durchgehen") danebenlag. Ohne sie haette die Pruefung vier Haken
gesetzt und nichts geprueft.
pruef-treff 66, pruef-bereiche-lesend, pruef-css-klassen gruen -- die
anderen sieben Bretter teilen sich diese Datei.
Der Plan im Vault fuehrt jetzt einen Abschnitt 12: "Was beim Bauen
herauskam, das im Plan nicht stand". Plaene altern, Befunde nicht.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e4d11caeb0 |
Community-Kacheln: das Loch, die Zwillinge, die unsichtbaren Farben
Filipe, mit einem Bildschirmfoto: "das wie es jetzt ist ist es einfach total scheisse ... gerade einfach nur dahin geknallt und drauf geschissen". Er hatte in allen drei Punkten recht, und alle drei sind messbar. 1. DAS LOCH IM RASTER -- eine Zeile Reihenfolge Drei Spalten, "Der Treff" doppelt breit -- aber an DRITTER Stelle. Nach zwei normalen Kacheln war noch EINE Spalte frei, er passte nicht und rutschte eine Reihe tiefer. Genau das ist die Luecke auf dem Foto. DIE REGEL, und sie gilt fuer jedes Raster im Haus: Eine breite Kachel gehoert an den ANFANG. Steht sie hinten, faellt die Luecke in die MITTE -- und eine Luecke in der Mitte sieht kaputt aus, eine am Ende sieht grosszuegig aus. Jetzt: Treff (2 Spalten) + Anschlagbrett fuellen Reihe 1, drei weitere Reihe 2, der Rest Reihe 3. Fuer DogFather und die Modis geht es genau auf, 3 x 3. Und es stimmt auch inhaltlich: Der Treff IST das Herz dieses Bereichs. 2. ZWEI KACHELN, EIN SYMBOL "Regeln & Hilfe" und "Meldungen & Massnahmen" trugen beide `schutz` -- im Quelltext zweimal, nebeneinander, auf dem Schirm nicht zu unterscheiden. Meldungen bekommt `startcheck`, die abgehakte Liste: Bei Regeln steht, was GILT. Hier steht, was daraus WURDE. 3. DIE FARBEN WAREN DA UND KAMEN NICHT AN Die sieben Toene sind laengst klar verschieden (#cc9451, #668e6e, #cc92c6, #656a9e ...). Der Grund stand direkt daneben: `.kachel:hover::before` und ein ausfuehrlicher Kommentar sprechen von einer Schiene, die "heller wird und weiter in die Platte strahlt" -- nur hatte `.kachel::before` ausser einem Uebergang KEINEN Inhalt. Das Element wurde beim Umbau am 07.09. entfernt, seine Hover-Regeln blieben stehen. Seither trug den Ton nur ein Verlauf, der bei 58 % verschwunden ist; unter dem Buehnenbild reicht das nicht. Das hier ist deshalb kein neuer Einfall, sondern das Wiedereinsetzen dessen, womit der Rest der Datei ohnehin rechnet. Drei Pixel, oben, nach rechts auslaufend -- Farbe an der Kante unterscheidet, Farbe auf der Flaeche blendet. NEU: pruef-kachelraster (15 Pruefungen) Ein Loch wird nicht angesehen, sondern gerechnet: belegte Zellen = Kacheln + 1 je doppelt breiter kleinstmoegliche Reihen = aufgerundet (Zellen / Spalten) Mehr Reihen als das heisst: irgendwo liegt eine Zelle leer, die es nicht muesste. Eine Luecke am ENDE faellt bewusst heraus. Dazu: jedes Zeichen genau einmal (erkannt am SVG-Pfad, nicht an einem Namen -- den gibt es im DOM nicht), jede Kachel mit Schiene, acht verschiedene Toene. Und die Gegenprobe in beide Richtungen: die ALTE Reihenfolge MUSS ein Loch melden, die neue nicht. ZWEI EIGENE FEHLER DABEI, beide durch Messen gefunden: - Ich hielt ein Vollbild-Foto fuer den Beweis, dass keine Kacheln da sind -- sie blenden sich beim Hereinscrollen ein. Die Pruefung scrollt jetzt erst hin. - Ich erwartete sieben Kacheln fuer einen Modi. Er moderiert, also sieht er acht. Der Code hatte recht, meine Annahme nicht. pruef-treff hat die Reihenfolge festgehalten und ist rot geworden -- genau ihre Aufgabe. Erwartung nachgezogen, mit dem Grund daneben. pruef-kachel-universum 37, pruef-haus-seiten 34, pruef-treff 66, pruef-css-klassen und pruef-start-ansicht: gruen. Der ausfuehrliche Plan fuer den ganzen Bereich liegt im Vault: "02 Projekte/Community-Bereich - Plan zur Perfektion" (fuenf Durchgaenge). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
3ebe87611e |
Dreizehn fortgeschrittene Aufgaben -- und die ersten, die es ohne den Kanal nicht geben konnte
Filipe: "ich will auch dass es fortgeschrittene aufgaben gibt." 88 -> 101 Aufgaben, Stufe "Erfahren" von 29 auf 42. Kein doppelter Schluessel, kein Text unter der Laenge, die `pruef-modi-katalog` verlangt (der Text muss BEGRUENDEN, nicht den Titel wiederholen). DER PUNKT IST NICHT DIE ZAHL, sondern dass mehrere davon vorher gar nicht formulierbar waren. Erst seit es Kanaele gibt, kann eine Aufgabe lauten: "Denselben Moment fuer zwei Kanaele verschieden schneiden -- was auf dem Hauptkanal als Rueckblick funktioniert, braucht bei Clips einen haerteren Einstieg." "Einen Monat lang nichts vom Hauptkanal spiegeln -- erst wenn der Nebenkanal sich allein traegt, weiss man, ob er ein Kanal ist oder ein Echo." "Die Kanaele in einer Tabelle nebeneinanderstellen -- einzeln angesehen waechst jeder irgendwie." Dazu Sachen, die eine erfahrene Person von einer eingearbeiteten unterscheiden: messen, was ein Ausschnitt an ZEIT kostet; denselben Ausschnitt zweimal mit anderem Anfang veroeffentlichen; eine Woche planen, in der DogFather nicht da ist; jedem Kanal einen festen Kopf geben. Die feste Zahl in pruef-modi-katalog ist mitgezogen (88 -> 101). Sie bleibt bewusst fest: Eine Zahl, die sich selbst nachzaehlt, merkt nicht, wenn etwas herausfaellt. pruef-modi-katalog 49 und pruef-deutsche-texte 9 gruen -- die neuen Texte tragen echte Umlaute, nicht ae/oe/ue. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b66fc379c8 |
Drei Accounts, eine Aufgabenliste: der Kanal
Filipe: "ich hab ja auch 2 neben account, hasidog und dogfather clips." Der Arbeitsplatz wusste davon nichts -- es gab genau eine Welt, und die hiess nirgends. DAS WAR KEIN FEHLENDES FELD, SONDERN EINE MEHRDEUTIGKEIT. "Schneide drei Ausschnitte" ist bei drei Accounts keine Aufgabe, sondern eine Frage. Wer sie bekommt, muss nachfragen -- oder raet. Raet er falsch, ist die Arbeit nicht halb getan, sondern am falschen Ort, und das faellt erst auf, wenn jemand hinsieht. WAS DAZUGEKOMMEN IST - KANAELE in workspace.js (DogFather, HasiDog, DogFather Clips), jeder mit einem Satz, der ihn erklaert. Ein Auswahlfeld mit drei Namen und ohne ein Wort dazu ist eine Ratefrage fuer jemanden, der neu ist. - Spalte `kanal` an den Aufgaben, per ADD COLUMN: kein Tabellenneubau, keine CHECK-Regel, alte Zeilen bleiben leer. - Auswahl in beiden Formularen, ein farbiges Zeichen auf der Karte (gedeckte Toene -- auf dem Brett stehen bis zu vierzig Karten). LEER IST EIN GUELTIGER ZUSTAND, kein fehlender. Vieles gilt fuer alles: eine Absprache im Team, ein Zugang, eine Auswertung. Ein Pflichtfeld haette dafuer einen falschen Kanal erzwungen, und ein falscher Eintrag ist schlechter als ein leerer. Deshalb steht dort "Für alle" und kein Strich. WARUM EINE LISTE IM QUELLTEXT UND KEINE TABELLE Sonst gilt hier: Eine abgeschriebene Liste altert. Diese ist keine Abschrift -- sie laesst sich aus nichts ableiten, weil sie eine Tatsache ueber Filipes Betrieb ist. Einen Kanal dazuzunehmen ist eine Zeile. Sobald sich das oefter aendert als ein paarmal im Jahr, gehoert sie in die Verwaltung; vorher waere das eine Oberflaeche fuer drei Zeilen. NEU: pruef-kanaele (21 Pruefungen) Vier Fragen, und die dritte wird gern vergessen: Kann man ihn setzen? Faellt ein erfundener auf? Erfaehrt jemand, der ihn nicht benutzen darf, dass es ihn gibt? Und laesst er sich wieder ENTFERNEN -- ein Feld, das `""` als "unveraendert" behandelt, macht aus einem Loeschversuch ein Nichts-Tun, ohne Fehlermeldung. Abschnitt 6 fragt die Datenbank selbst. Ohne ihn koennte alles gruen sein, obwohl der Wert nur durch die Auskunft zurueckgereicht wird. pruef-aufgabenbrett, pruef-modi-katalog 49, pruef-modi-kategorien 25 und pruef-css-klassen unveraendert gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
fa8e86ad81 |
Die Personenkacheln der Entwicklung im Hausstil
Filipe, mit zwei Bildschirmfotos nebeneinander: "wieso ist diese seite noch nicht im stil und perfektioniert wie die auf screen2 ... aber so dass ich die leute in einer kachel aussuchen kann alle einzel." Der Unterschied lag NICHT im Aufbau -- der stimmte -- und auch nicht am Inhalt: Die 28 Punkte sind laengst ganz auf Modi-Arbeit gebaut (Im Chat 8, Wenn es eng wird 7, Im Team 7, Wie viel von selbst 6, dazu sechs Fragen an einen selbst). Es waren zwei andere Dinge: 1. DIE ZAHLEN WAREN GRAUE TEXTZEILEN Drueben stehen sie als abgesetzte Kaesten mit grosser Ziffer und eigenem Ton. `bilanz-zahl` liegt in start.css und gehoert dem ganzen Haus -- es wird jetzt benutzt statt nachgebaut. Ein Nachbau laeuft auseinander, sobald jemand eins von beiden anfasst. Aus "0 von 28 angesehen" werden drei Kaesten wie auf der Checkliste: angesehen / noch offen / verschieden gesehen. Die ersten beiden teilen dasselbe Ganze, die dritte ist das Ergebnis dieser Seite -- wo zwei Leute dasselbe sehen, gibt es nichts zu besprechen. 2. EINE ANGEKLICKTE PERSON SAH AUS WIE EINE NICHT ANGEKLICKTE Die Kachel war ein Knopf ohne Zustand. Man klickte jemanden an, die Karte ging auf -- und oben blieb alles gleich. Wer scrollte, wusste nicht mehr, wen er offen hat. Jetzt `aria-pressed`, damit es auch ein Vorleseprogramm sagen kann, und eine gedaempfte Umrandung. Die Reihe heisst "Person waehlen" wie auf dem Aufgabenbrett. Nebenbei: Der Ton des ersten Kastens springt auf gruen, sobald nichts mehr offen ist -- sonst saehe eine fertig angesehene Person aus wie eine halbe. NEU: pruef-entwicklung-kacheln (15 Pruefungen) Nicht "sieht gleich aus" -- das laesst sich nicht messen -- sondern was das Aussehen traegt: Benutzt die Kachel den Hausbaustein oder einen Nachbau (und steht nichts Selbstgebautes daneben)? Ergibt angesehen + noch offen die Gesamtzahl, die die Auskunft selbst nennt? Und die Gegenprobe zur Auswahl: VOR dem ersten Klick darf keine Kachel gewaehlt sein, danach genau eine, und beim naechsten Klick wandert sie, statt sich zu sammeln. pruef-entwicklung 43 und pruef-css-klassen unveraendert gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
3a86b13de1 |
Drei Zahlen, die etwas anderes zaehlten, als sie sagten
Weiter an derselben Stelle wie der Ring: Nicht umbauen, was gut ist --
suchen, wo eine Beschriftung etwas anderes behauptet, als darunter
gerechnet wird. Drei Funde, alle auf der Startseite.
1. "HEUTE" WAR ZWEIDEUTIG
Die erste Zahl unter dem Ring heisst "heute" und zaehlt TERMINE.
Solange der Ring die Uhrzeit zeigte, fiel das nicht auf. Seit er
"Heute geschafft" heisst und AUFGABEN zaehlt, standen zwei
verschiedene "heute" uebereinander -- ein Widerspruch, den der
vorherige Commit erst erzeugt hat. Heisst jetzt "Termine heute".
2. "KOMMT NOCH" ZAEHLTE STUNDEN, NICHT TERMINE
`mitTermin` ist eine Menge von STUNDEN -- fuer den Ring richtig, er
faerbt Stundensegmente. Als Zahl daneben war es falsch: Drei Termine
um 20 Uhr ergaben "1 kommt noch". Eine zu kleine Zahl meldet niemand;
man verlaesst sich darauf und wundert sich spaeter.
3. DIE KACHELZAHL SAGTE VORLESEND "OFFENE PUNKTE"
Sie summiert HINWEISE: bei Aufgaben "2 ueberfaellig" + "2 heute
faellig" = 4. Im Block darunter steht "6 Offen". Beides richtig -- nur
das Wort "offen" machte daraus einen Widerspruch, und wer die Seite
vorgelesen bekam, hoerte eine Zahl offener Aufgaben, die es nicht
gibt. Jetzt: "Aufgaben: 4 Sachen liegen an".
NICHT GEAENDERT, OBWOHL ICH ES VORGESCHLAGEN HATTE:
Die sieben Zaehler bleiben, auch wenn mehrere Null sind. Im Code steht
Filipes Anweisung vom 08.09. daneben ("diese beiden kategorien sollen
bei jedem in jeder rolle gleich sein"), samt der Erfahrung, dass das
Ausblenden schon einmal dazu fuehrte, dass Spicy Media als Einzige
etwas anderes sah. Der leere Zustand wird bereits gedaempft statt
entfernt -- das ist die bessere Loesung und sie war schon da.
pruef-zentrale-ring jetzt 14 Pruefungen (vorher 10), darunter drei
Termine in DERSELBEN Stunde -- der Fall, der 1 statt 3 ergab. Dazu die
Gegenprobe, dass jemand ohne Termine dort auch null sieht.
pruef-start-ansicht und pruef-tagesblick unveraendert gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
b57b9cebb5 |
Der Ring oben zeigt Arbeit statt der Uhrzeit
Auf der Startseite von Creator, rechter Hand und Modis ist der Ring das
groesste Element, ganz oben. Er rechnete:
prozent = (aktuelle Stunde - 6) / 18
...und nannte das "Tag geschafft". Um 9 Uhr also 17 %, um 23 Uhr 94 %
-- unabhaengig davon, ob jemand etwas getan hatte.
Aufgefallen auf einem Bildschirmfoto: Bei einer Modi stand "0 % TAG
GESCHAFFT", waehrend sie ueberhaupt nichts offen hatte. Beide Angaben
waren fuer sich richtig und zusammen Unsinn -- und es war das Erste,
was sie sah.
JETZT ZAEHLT ER ARBEIT. Nenner ist, was heute auf dem Tisch liegt:
heute faellig ODER laenger offen. Die naheliegende Rechnung ueber "nur
heute faellig" waere derselbe Fehler noch einmal gewesen -- bei drei
ueberfaelligen Sachen haette der Ring "nichts faellig" gemeldet.
Zaehler ist, was HEUTE fertig wurde (erledigt_am), nicht was irgendwann
abgehakt wurde. Liegt nichts an: voller Ring, und der Titel sagt es in
Worten statt nur eine 100 zu zeigen.
Gemessen danach, dieselbe Seite: "33 % Heute geschafft", darunter
"2 Sachen sind ueberfaellig -- das zuerst". Die Seite erzaehlt jetzt
eine Geschichte statt zweier.
NEU: pruef-zentrale-ring (10 Pruefungen)
Drei Lagen, drei Menschen: etwas anliegend und teils fertig / nichts
anliegend / drei ueberfaellige und nichts fertig. Dazu zwei
Abgrenzungen (morgen faellig und vorgestern erledigt duerfen nicht
mitzaehlen) und die Gegenprobe: zwischen zwei Abfragen wird eine
Aufgabe fertig gemacht, der Ring MUSS springen -- er tut es, 0 % -> 33 %.
Der letzte Abschnitt rechnet die alte Uhrzeit-Formel mit und meldet,
falls der Ring je wieder auf ihren Wert faellt.
NEU: mess-startseite -- ein Messwerkzeug, kein Pruefwerkzeug
Es sagt nicht richtig/falsch, sondern wie viel da ist: Seitenlaenge in
Handy-Bildschirmen, Bedienelemente, Woerter, Ring, je Rolle, mit
echten Aufgaben statt im leeren Zustand. Gemessener Stand:
admin 7,0 Schirme / 58 Bedienelemente hand 5,7 / 43
modi 5,0 / 37 manager 4,9 / 38
scout 4,5 / 34 creator 4,3 / 32
pruef-sicht, pruef-verborgen, pruef-modi-verborgen und
pruef-haus-trennung laufen unveraendert durch -- die neue Abfrage
folgt der fremden Sicht ueber dieselbe Variable wie der Rest.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
78b64f6eca |
Auf dem Brett steht jetzt Deutsch, nicht ASCII
Unter jeder Kategorie stand eine Erklaerung ohne Umlaute: "Was im Livechat passiert, waehrend gesendet wird. Loeschen, stummschalten, begruessen, deeskalieren." Elf der vierzehn Kategorien und alle drei Stufen waren betroffen, dazu vier Stellen mit zwei Bindestrichen statt eines Gedankenstrichs. Entstanden ist es beim Schreiben ueber Hilfsskripte, die an Umlauten scheitern -- fuer einen Kommentar gleichgueltig, fuer einen Satz, den ein Mensch liest, ein Fehler. Gesehen hat es keine Pruefung: Der Text war inhaltlich richtig, der Katalog vollstaendig, alles gruen. Aufgefallen ist es auf einem Bildschirmfoto. NEU: pruef-deutsche-texte (9 Pruefungen) Sieht 174 Katalogtexte und 28 ausgelieferte Seiten durch. Bewusst eine Liste von Wortstuecken statt eines Musters aus Buchstabenfolgen: "ue" ist in "Feuer" und "neue" richtig, "ss" in jedem zweiten Wort. Die Liste ist ein Netz, kein Beweis, und der Kopf der Datei sagt das. Die Skripte bleiben absichtlich aussen vor. Ausprobiert: Dieselbe Liste schlaegt dort 71 Mal an und kein einziges Mal zu Recht -- es sind Feldnamen, Stilklassen und Adressen, die ASCII sein MUESSEN. Eine Warnung, die immer kommt, ist keine Warnung mehr. Ihr sichtbarer Text wird deshalb am fertigen Bildschirm geprueft, ueber innerText. AUSSERDEM, auf demselben Bildschirmfoto gefunden: Die Fusszeile der Vorlagenkarten war eine starre Flex-Zeile. Bei einer schon uebernommenen Aufgabe stehen dort drei Dinge statt zwei, und "Frist: in 2 Tagen" brach mitten im Wort auf drei Zeilen um. Keine neue feste Breite dagegen, sondern flex-wrap plus nowrap -- eine Regel, die misst, statt einer Zahl, die beim naechsten Element wieder faellig waere. UND EINE LEHRE ZUM MESSEN: Die erste Fassung dieser Pruefung zaehlte element.getClientRects(). Sie blieb gruen, auch mit dem Fehler wieder eingebaut -- ein Flex-Kind wird zum Block und liefert immer genau ein Rechteck. Gefunden hat das nur die Gegenprobe. Gemessen wird jetzt ueber einen Bereich um den Textknoten. Das Bildschirmfoto landet ausserdem dort, wo die Zeile darunter es ansagt (server/), nicht im Arbeitsverzeichnis. pruef-modi-katalog 49 (vorher 45), pruef-deutsche-texte 9, pruef-css-klassen, pruef-struktur, pruef-vorlagen, pruef-aufgaben-vorlagen: alle ohne Fehler. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
76fa8b95fc |
Beim Verteilen sehen, wer schon wie viel hat
Weiter an derselben Sache: die Kategorien, aus denen Aufgaben an das Team gehen. ZWEI DINGE WAREN UNBEQUEM: Die Person kam aus dem Formular GANZ OBEN auf der Seite. Man waehlt sie dort, scrollt herunter zum Vorlagenbrett und drueckt "Uebernehmen" -- und wer das nicht weiss, bekommt "Bitte zuerst eine Person waehlen" und sucht, wo. Und beim Vergeben sah man nicht, wer schon wie viel offen hat. Das ist die wichtigere Haelfte: Zu wenig Zeit ist in den Untersuchungen zu Moderatoren der meistgenannte Grund fuers Aufhoeren, und die Person, die verteilt, ist die einzige, die das verhindern kann. Dafuer muss die Zahl dort stehen, wo entschieden wird -- nicht auf einer Auswertung, die man hinterher aufruft. Jetzt steht ueber den Aufgaben eine Reihe mit den Namen des Teams und der Zahl daneben. Ein Klick, und die uebernommenen Aufgaben gehen dorthin; das Formular oben bleibt als Rueckfall, damit der bisherige Weg weiter funktioniert. KEINE SCHWELLE, KEINE WARNFARBE AUF DER ZAHL. Was "zu viel" ist, haengt vom Menschen ab -- eine feste Grenze waere geraten, und geraten ist bei dieser Frage schlimmer als nichts. Was NICHT geraten ist: dass etwas ueberfaellig liegt. Nur das wird markiert, und zwar gedeckt. Ein Warnton an einem Namen liest sich sonst wie ein Vorwurf gegen die Person, dabei ist es eine Auskunft ueber die Verteilung. Ohne eine einzige neue Abfrage: Die Personen und ihre Aufgaben liegen im Browser ohnehin schon. Ein zweiter Abruf waere ein zweiter Weg, auf dem eine andere Liste herauskommen kann. server/pruef-modi-katalog.mjs 45 Pruefungen (vorher 36), 0 Fehler Der neue Abschnitt meldet sich als DogFather an -- der bisherige Browserteil ist ein Modi, und der sieht diese Auswahl gar nicht. Er drueckt wirklich: Marina waehlen (9 offen), eine Aufgabe uebernehmen, nachsehen ob sie bei ihr liegt (9 -> 10). Ein Knopf, den niemand betaetigt hat, ist kein geprueter Knopf. Und er prueft die Gegenrichtung mit: Ein Creator und eine Managerin stehen NICHT zur Auswahl -- sie arbeiten im anderen Haus. pruef-aufgabenbrett, pruef-sicht, pruef-womit 41, pruef-css-klassen -- alle 0 Fehler Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4802954263 |
Der Aufgabenkatalog fuers Team: Kategorie mal Stufe, 88 Aufgaben
Filipe: "perfektionniere die kategorien wo ich aufgaben an die modis verteile und so, ich will dass du alles was es gibt auf der welt durch gehst und wie bei den aufgaben wo sie fuer mich haben auch mit kategorien und vielen aufgaben." ERST GEZAEHLT, WAS DA WAR. Es gab einen Katalog: 60 Eintraege in neun Phasen. Wem sie gehoerten: DogFather 13 DogFather & rechte Hand 12 rechte Hand 14 -------------------------------- zusammen 39 von 60 Zwei Drittel des "Modi-Katalogs" waren Aufbauarbeiten fuer Filipe selbst. Nur 20 Eintraege waren wirklich Arbeit fuer jemanden im Team. Und die Verteilung ueber die vierzehn Kategorien war schief: Planung 10, Events 1, Wachstum 1, Branding 1, Sonstiges 0. Der Aufbauplan ist nicht falsch, nur etwas anderes -- er bleibt unter `aufbauplan` erhalten. Ihn zu loeschen hiesse, 60 durchdachte Schritte wegzuwerfen, weil sie am falschen Platz standen. NEU: 88 Aufgaben in KATEGORIE mal STUFE, dieselbe Form wie bei den Creator-Vorlagen. Wer eine Aufgabe vergibt, denkt "Frida macht Chat" und nicht "wir sind in Phase 3". Chat 11, Team 8, Community/Events/Clipping/Technik je 7, Social/Planung/Organisation je 6, Kommunikation/Analyse/Wachstum/ Branding je 5, Sonstiges 3 -- keine Kategorie mehr leer. Drei Stufen: neu dabei (24), eingearbeitet (35), erfahren (29). Eine Aufgabe der Stufe "erfahren" an einen Neuen zu geben ist kein Kompliment, sondern ein Ueberfallen. UND DIE VIERZEHN KATEGORIEN HABEN JETZT EINEN SATZ. Vorher standen da vierzehn nackte Namen -- "Organisation" und "Planung" nebeneinander, ohne dass jemand sagt, was worin gehoert. Dann landet dieselbe Aufgabe beim einen unter Planung, beim anderen unter Organisation, und jede Auswertung darueber ist wertlos. Jetzt: Planung ist, was NOCH NICHT ist; Organisation, was bereits ist, in Ordnung zu halten. RECHERCHIERT, NICHT AUSGEDACHT (Quellen im Kopf des Katalogs): Twitch und Discord zu dem, was ein Moderator tatsaechlich tut; TikTok LIVE im Besonderen (gefilterte Kommentare, Gaesteverwaltung, Regeln zu Beginn, Matches, Geschenke ohne Betteln); Community-Arbeit zu Rhythmus, Vertretung und Monatsrueckblick. Dazu die Burnout-Forschung, die schon in "Wie geht's dir?" steht -- deshalb stehen unter "Team" Aufgaben, die zu wenig Zeit und Streit frueh sichtbar machen. WAS DABEI BEINAHE SCHIEFGEGANGEN WAERE, und was es gefunden hat: Das Uebernehmen griff noch auf MODI_KATALOG zu -- die alten Phasen. Der Browser schickt die Nummer aus der AUSGELIEFERTEN Liste zurueck. Ein Klick auf "Uebernehmen" haette damit eine voellig andere Aufgabe angelegt, und zwar eine, die es gibt: keine Fehlermeldung, nichts Rotes, nur die falsche Aufgabe auf dem Brett. Gefunden hat das pruef-modi-katalog, die an der verschwundenen Phase abgestuerzt ist. Der Knopf "Alle N uebernehmen" schickte die Stufe nicht mit. Er sagte "Alle 4 uebernehmen" und haette elf angelegt -- das merkt man erst auf dem Brett. Und der Satz ueber dem Brett sagte weiterhin "Nach Etappen sortiert". Gesehen im Bildschirmfoto der Pruefung, nicht im Code. server/pruef-modi-katalog.mjs 36 Pruefungen, 0 Fehler Neu darin: jede Kategorie muss belegt sein (mindestens drei), jede Stufe auch, keine Kennung doppelt -- und JEDER TEXT MUSS BEGRUENDEN. Die letzte Zeile hat zwei meiner eigenen Texte als zu duenn erwischt. pruef-modi-kategorien 25, pruef-aufgabenbrett, pruef-vorlagen, pruef-css-klassen, pruef-struktur -- alle 0 Fehler Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
99f96553c5 |
Eine Benachrichtigung muss irgendwohin fuehren
Der letzte offene Punkt aus dem Umbau vom 15.09.: Seitdem entscheidet
die Adresse, welche Seiten es gibt -- fuer Seiten, Hinweise und
Suchtreffer ist das umgesetzt, fuer Push war es das nicht. Und der
Grund stimmte: Eine Benachrichtigung entsteht, wenn NIEMAND auf einer
Adresse steht. Sie geht an ein Geraet, und das oeffnet die Adresse, als
die es installiert wurde.
DIE FRAGE LAESST SICH TROTZDEM BEANTWORTEN -- nur nicht ueber die
Adresse, sondern ueber den MENSCHEN. Wer im Team ist (rechte Hand,
Modi), kommt NUR auf crew. herein; das steht in
sitzungPasstZurAdresse und gilt in beide Richtungen. Fuer ihn gibt es
die Agenturseiten nirgends -- auf keinem Geraet, in keiner
installierten App.
Erst gemessen, welche Ziele es ueberhaupt gibt und wer sie bekommt:
aufgaben.html an den Verantwortlichen -- kann ein Modi sein, und
die Seite gibt es auf crew. in Ordnung
calls.html an die TERMIN-TEILNEHMER <- der Fall
kalender.html dieselben Empfaenger, Seite gibt es in Ordnung
scouting.html nur an Scouts in Ordnung
start.html ueberall in Ordnung
Ein Modi, der als Teilnehmer in einem Call steht, bekam also einen
Hinweis auf eine Seite, die es fuer ihn nicht gibt.
UND DIE BENACHRICHTIGUNG WIRD NICHT UNTERDRUECKT. Das ist die
eigentliche Entscheidung: Er SOLL erfahren, dass der Call gleich
anfaengt -- er soll nur nicht auf einer Seite landen, die ihn
weiterleitet. Statt der Seite kommt die Startseite; dort steht, was
ansteht. Eine Weiterleitung ins Leere sieht aus wie ein Fehler, eine
Startseite nicht.
An EINER Stelle, durch die jede Benachrichtigung geht. DogFather und
Spicy Media arbeiten in beiden Haeusern -- fuer sie bleibt jedes Ziel,
das es in einem der beiden gibt; welches Geraet sie in der Hand
halten, weiss hier niemand, und die Seitenschranke faengt den Rest ab.
`benachrichtige` gibt jetzt zurueck, WOHIN wirklich geschickt wurde.
Sonst muesste eine Pruefung die verschluesselte Nachricht aufmachen,
um es zu erfahren -- das beweist pruef-push-weg mit einem nachgebauten
Browser bereits, und zweimal dieselbe Maschinerie waere die zweite,
die veraltet.
server/pruef-push-ziel.mjs 10 Pruefungen, 0 Fehler (Port 4423/4424)
Mit Gegenprobe in beide Richtungen: aufgaben.html und befinden.html
bleiben stehen (sonst hiesse "wird zur Startseite" nur, dass jedes
Ziel dorthin faellt), eine Managerin wird weiterhin zu den Calls
geschickt, und ein echter Push-Dienst zaehlt mit, dass die acht
Nachrichten auch wirklich rausgegangen sind.
pruef-push, pruef-push-weg, pruef-glocke -- alle 0 Fehler
Co-Authored-By: Claude Opus 5 <[email protected]>
|