main
89
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
b625d901a5 |
Jeder darf seine eigene Chat-Nachricht bearbeiten
Filipe: "die nachrichten die man in den chat reinschreibt. jeder soll
seine eigene nachricht bearbeiten koennen. diese option soll jeder
fuer seine eigene nachrichten haben die er selber verfasst hat."
NUR DIE EIGENE -- OHNE AUSNAHME, auch nicht fuer DogFather und die
rechte Hand. Beim LOESCHEN gibt es diese Ausnahme seit dem 22.09.
(fuer den Notfall), und es waere naheliegend gewesen, sie
mitzunehmen. Das waere falsch: Eine fremde Nachricht zu entfernen
heisst "das soll hier nicht stehen". Eine fremde zu AENDERN heisst,
jemandem Worte in den Mund zu legen, die unter seinem Namen und
seinem Bild stehen bleiben. Nicht dieselbe Befugnis in groesser,
sondern eine andere. Genau das ist die wichtigste Pruefzeile:
DogFather darf loeschen und bekommt beim Bearbeiten 403/404.
AN DER NACHRICHT STEHT "BEARBEITET". Ein Text, der sich still
aendert, nachdem andere darauf geantwortet haben, ist ein
Vertrauensproblem und kein Komfort. Der Vermerk traegt die Zeit im
Titel. Derselbe Text setzt ihn NICHT -- sonst stuende er irgendwann
ueberall und waere nichts mehr wert.
ERWAEHNUNGEN BLEIBEN, WIE SIE BEIM SENDEN WAREN. Wer beim Bearbeiten
"@Anna" ergaenzt, spricht Anna damit nicht an. Sonst gaebe es nur
schlechte Wege: nachtraeglich benachrichtigen laesst sich beliebig
oft wiederholen, und still eintragen setzt jemanden auf eine Liste,
von der er nie erfaehrt. Ansprechen tut man mit einer neuen
Nachricht. (Falls das anders gewuenscht ist, ist es eine eigene
Entscheidung -- nicht etwas, das hier nebenbei mitpassiert.)
DER RAUM RUECKT NICHT NACH OBEN und niemand bekommt die Nachricht
als ungelesen: Eine Tippfehlerkorrektur ist keine Wortmeldung.
`letzte_am` wird deshalb nicht angefasst.
Leer geht nicht -- dafuer steht "loeschen" daneben, mit Rueckfrage.
Grenzen (4000 Zeichen) sind dieselben wie beim Senden; eine zweite
Rechnung waere die, die auseinanderlaeuft.
Das Feld sitzt AN der Nachricht, nicht im Schreibfeld unten: Wer
seinen Text zum Bearbeiten unten wiederfindet, schickt ihn beim
naechsten Enter als NEUE Nachricht ab und hat ihn zweimal im Raum.
Enter speichert, Shift+Enter macht eine Zeile, Escape bricht ab --
dieselben Tasten wie beim Schreiben. 16 px Schrift, sonst zoomt iOS
beim Hineintippen die ganze Seite heran.
Der Stift traegt sich in die Familie der Handgriffe ein, wie es der
Hinweis in chat.css ausdruecklich verlangt ("wer einen sechsten
Handgriff baut, traegt ihn hier ein und bekommt sein Zeichen").
EIN FEHLER, DEN NUR DAS BILD GEZEIGT HAT. Ich hatte im Code
behauptet, die Gespraechsliste aendere sich beim Bearbeiten nicht,
und darum auf das Nachladen verzichtet. Auf dem Bildschirmfoto stand
rechts "Treffen um 15 Uhr" und links in der Liste weiter "Du:
Treffen um 15 Urh" -- derselbe Satz, zweimal verschieden, auf einem
Schirm. Richtig ist: Die REIHENFOLGE aendert sich nicht, die
VORSCHAU sehr wohl. Beide Haelften waren fuer sich gemessen und
gruen; keine Zahl hat es gemerkt.
pruef-chat 17 neue Pruefungen: eigene geht, fremde nicht, DogFather
nicht, Vermerk kommt mit nach draussen (auch im SELECT -- genau das
hat am 03.10. bei den Anhaengen einen halben Tag gekostet), Raum
rueckt nicht, Vorschau zieht nach, leer/zu lang abgelehnt,
unveraendert ohne Vermerk, geloeschte nicht bearbeitbar, wer nicht
im Raum ist bekommt 404 statt 403.
pruef-chat-optik 71 -> 84: im echten Browser, mit zwei Sitzungen.
Darunter die Zeile, auf die es ankommt -- der neue Text steht bei
Patrick, OHNE Neuladen. Ein Bearbeiten, das nur der Schreibende
sieht, waere schlimmer als keins.
Dabei zwei eigene Messfehler behoben: Die Sitzungen von oben waren
laengst geschlossen (Playwright meldet nur "Target page has been
closed"), und beide klickten "das oberste Gespraech" statt
denselben Raum -- wodurch die Pruefung "an ihr steht KEIN
bearbeiten" gruen war, weil die Nachricht gar nicht da war. Sie
haengt jetzt daran, dass er sie wirklich sieht.
Datenbank vorher gesichert und zurueckgelesen (integrity_check,
324 Nachrichten, 20 Personen).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
5d9c8cd377 |
Haustrennung: kein Eintrag mehr aus dem anderen Haus
Filipe, 24.09.2026: "wenn ich bei der einen was mache soll nichts bei
der anderen passieren." -- und heute: "ja los".
GEMESSEN, BEVOR ETWAS ANGEFASST WURDE (jedes Brett x beide Adressen x
vier Rollen):
AGENTUR-Adresse DogFather 18 Bretter
Manager 6 Bretter
Creator 6 Bretter
Modi kommt nicht rein (401)
CREW-Adresse DogFather 18 Bretter
Modi 13 Bretter
Manager kommt nicht rein (401)
Creator kommt nicht rein (401)
Die Anmeldung war also dicht. Durch griff genau EINE Rolle: DogFather.
Er wohnt in beiden Haeusern, und die Riegel in sichtbarEintrag()
fragten nach der ROLLE, nicht nach der Adresse. Auf der Crew-Adresse
stand damit das Brett der Agentur samt Inhalt.
Nachgemessen ist der Durchgriff AELTER als der gestrige Eventkarten-
Umbau -- zweimal gemessen, mit und ohne ihn, gleiches Ergebnis.
RIEGEL 0 in sichtbarEintrag(): Wer auf einer Adresse angemeldet ist,
sieht nur Eintraege dieses Hauses. Er haengt den uebrigen Riegeln
UM, statt in jeden Ausgang geschrieben zu werden -- die Funktion hat
drei Rueckgabepunkte, und der naechste waere sonst wieder offen.
Nachher, dieselbe Messung: DogFather sieht auf der Agenturadresse nur
Agentur-Eintraege, auf der Crew-Adresse nur die des Rudels. Manager,
Creator und Modi unveraendert.
WAS DABEI SCHIEFGING UND WIE ES AUFFIEL
1. Die erste Fassung liess bei `haus IS NULL` den BEREICH entscheiden.
pruef-haus-trennung.mjs wurde sofort rot: "Lunas Live vom Montag"
verschwand von der Agenturadresse. `live`, `technik` und
`community` tragen BEIDES -- die Kacheln von Team Dogi und die
Creator-Akten. Eine Regel, die jedem Brett genau ein Haus zuweist,
kann das nicht. Jetzt bleibt ein Eintrag ohne Haus sichtbar: ein
Eintrag zu viel faellt auf, ein fehlender nicht.
2. Damit NULL kein Dauerloch ist: FUENF von ACHT Stellen, die
Eintraege anlegen, setzten `haus` gar nicht (workspace-video.js,
-content.js, -bewerbung.js, -treff.js, -vorlagen.js). Nachgetragen.
3. Und `person.haus` war dafuer der falsche Massstab: Legt DogFather
ueber die Agenturadresse ein Highlight an, gehoert es trotzdem dem
Rudel -- sonst sieht die Community es nie. pruef-treff.mjs hat das
gefunden (2 Fehler). Neu: hausFuerNeuenEintrag() -- bei den sieben
Brettern des Rudels entscheidet das BRETT, sonst die Adresse.
NEU: pruef-haus-luecke.mjs (12 Pruefungen). Sie sucht die
Einfuege-Stellen im Quelltext und wird rot, sobald eine neunte
dazukommt, die `haus` vergisst -- mit Gegenprobe, dass das Suchmuster
eine solche Stelle auch wirklich erkennt. Ein Kommentar daneben haette
es nicht verhindert; das steht so schon im Projektgedaechtnis.
NEBENBEI: In bereich.js stand seit gestern `|| "Agentur-Events"` als
Rueckfall fuer das Etikett der Vorschau. pruef-treff.mjs verbietet
das zu Recht -- wie ein Brett heisst, haengt am Haus, und der Server
sagt es. Der Rueckfall ist weg; fehlt die Angabe, steht lieber kein
Etikett da als ein falsches.
pruef-treff.mjs nachgezogen (85 -> 86 Pruefungen, nicht weniger): Die
Zusage "DogFather sieht den Beitrag" wird jetzt auf der Crew-Adresse
geprueft, mit Gegenprobe fuer die Agenturadresse.
GEPRUEFT, alle gruen:
pruef-haus-luecke 12 pruef-haus-trennung 100
pruef-crew-adresse 169 pruef-treff 86
pruef-eventkarte 77 pruef-agentur 62
pruef-haus-seiten 38 pruef-eintrag-bild 24
pruef-vorlagen 24 pruef-video, -content, -bewerbung,
-bereiche-lesend: in Ordnung
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
3e1e0810ba |
Agentur-Events: die Karte als Aushang, Aufgaben zum Abhaken
Filipe, mit einem Bildschirmfoto des Oktober-Events: "ich will das viel geiler viel perfekter. und auch wenn man die eintraegt und so soll viel mehr perfektioniert und uebersichtlicher sein." VORHER GEMESSEN (1280 px, eine einzige Eventkarte): Kartenhoehe 1196 px -- das Fenster ist 900 px davon Banner 638 px -- 53 %, ohne einen Buchstaben Titel steht bei 1482 px -- zweimal scrollen bis zum Namen Titelgroesse 15,36 px -- 1,4 px mehr als der Fliesstext Etikett 10,88 px -- unter der eigenen Grenze (11,5) Datum 3 x -- in drei Zeilen untereinander Knoepfe 4 x gleich -- "loeschen" wie "zur Aufgabe" NACHHER, dieselbe Messung: Karte 618 px, Buehne 203 px, Titel 75 px unter der Kartenkante und 24,8 px gross, Etikett 12 px, das Datum einmal, "loeschen" abgesetzt. DIE KARTE Das Banner ist nicht mehr ein Anhang ueber dem Titel, sondern die Buehne dahinter -- Hoehe gedeckelt, Titel darauf. Dazu die Frage, die bei einem Wettbewerb wirklich zaehlt und bisher nirgends beantwortet wurde: "noch 12 Tage", mit Zeitbalken. Ein Knopf "Banner ganz" holt das vollstaendige Bild zurueck, das beim Umbau sonst verloren gegangen waere -- bei Filipes Banner steht die Ansage IM Bild. DIE AUFGABEN Aus Fliesstext wird eine Liste, und jeder hakt fuer sich ab (neue Tabelle event_punkte, Schluessel aus dem Zeilentext). Umsortieren laesst den Haken, wo er ist; wird die Bedingung selbst umgeschrieben, faellt er -- beides nachgemessen. Die Leitung sieht, wer wie weit ist, eine Creatorin sieht diese Liste gar nicht erst. DAS FORMULAR Ein Feld je Zeile statt eines leeren Textfeldes. Im echten Event stand ".Jeden Tag Live gehen" neben ". 33k Diamanten erreichen" -- einmal mit Leerzeichen, einmal ohne. Das ist die zwangslaeufige Folge davon, dass die Aufzaehlungszeichen von Hand getippt werden; jetzt setzt sie das Formular. Dazu "Laeuft 14 Tage.", eine Warnung bei verdrehtem Zeitraum und eine Vorschau, die dieselbe Funktion benutzt wie die echte Karte. NEBENBEI GEFUNDEN UND BEHOBEN * Das Banner kam bei Creatorn mit 404 zurueck -- also an genau der Karte, die fuer sie gemacht ist. Die Regel "wer das Brett sieht, sieht das Bild" galt nur fuer die sieben Community-Bretter. Jetzt fragt der Bildweg dieselbe Regel wie das Brett (darfEintragSehen); die Gegenprobe zeigt, dass ein fremder Eintrag weiterhin 404 gibt. * Zwei Stellen setzten das Formular zurueck, die kuerzere liess Vorschau und Zeilen-Editor stehen -- beim naechsten "Neuer Eintrag" standen die Aufgaben des vorigen Events noch da. * Der Schriftgrund ragte auf dem Handy 6 px ueber die Karte (feste -20 px gegen 14 px Polsterung); jetzt an die Polsterung gekoppelt. GEPRUEFT pruef-eventkarte.mjs (neu): 77 Pruefungen, 0 Fehler -- mit Gegenproben zu jeder Zusage und einer Kontrastmessung am Bildpunkt auf einem weissen Banner (14,7:1; ohne den Schriftgrund 1,05:1). pruef-agentur.mjs auf die neuen Bausteine nachgezogen, Zahl unveraendert bei 62. pruef-eintrag-bild.mjs 24/0. OFFEN, NICHT AUS DIESEM UMBAU: Das Brett `agentur` ist auf der Crew-Adresse erreichbar. Zweimal gemessen, mit und ohne diese Aenderung -- gleiches Ergebnis. Gehoert zur Trennungsregel vom 24.09.2026 und wird getrennt entschieden. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ae2f12c67d |
"Fuer wen"-Reihe weg -- aber nur bei Team Dogi
Filipe, mit Bildschirmfoto der Leiste "FUER WEN · Alle 3 2 ·
Marina 1 · Diene 0": "brauchen wir nicht auf der aufgaben seite."
GETRENNT GEFUEHRT, wie seit dem 24.09. fuer jeden Umbau. Es ist
DIESELBE Reihe in beiden Haeusern, aber nicht dieselbe Aufgabe:
Team Dogi -> "Fuer wen", darin drei, vier Modis, die ohnehin
alle auf einem Schirm stehen. Ein Filter fuer eine
Liste, die kuerzer ist als er. WEG.
Spicy Media -> "Alle Creator" / "Deine Creator". Scouts und
Manager filtern damit durch ihre Creator, und das
sind deutlich mehr. BLEIBT.
Die Trennung ist eine einzige Zeile an `ich.haus` -- das kommt vom
Server. Eine Rollenliste im Browser waere die zweite Wahrheit und fuer
DogFather, der in beiden Haeusern arbeitet, sogar falsch.
Der Zweig fuer die dritte Beschriftung ist mit entfernt, nicht
stehengelassen: "Fuer wen" ist von nirgends mehr erreichbar, und ein
Zweig, den niemand erreicht, sieht beim Lesen aus wie ein Fall, den
es gibt -- beim naechsten Umbau pflegt ihn jemand mit.
BEWIESEN IN BEIDE RICHTUNGEN, sonst waere die Trennung eine
Behauptung:
* pruef-handy-teamdogi (neu, 3 Pruefungen, 244 -> 247): auf crew.
im echten Browser ist die Reihe weg -- MIT der Gegenprobe, dass
die Seite ueberhaupt steht (4 Knoepfe in der Schwester-Reihe).
"Reihe nicht da" waere sonst auch auf einer kaputten Seite wahr.
* pruef-aufgabenbrett (49, unveraendert): bei Spicy Media steht sie
weiterhin da, mit "Alle, Tili, Luna" und der Beschriftung "Alle
Creator".
ZWEI DINGE AM PRUEFWERKZEUG, die mich heute Zeit gekostet haben:
1. `probleme` wurde seit jeher gefuellt und NIE ausgegeben. Am Ende
stand "1 Befund" und sonst nichts -- wer das liest, weiss DASS
etwas ist, nicht WAS, und muss den ganzen Lauf noch einmal
anstossen. Die Befunde stehen jetzt unter der Zahl.
2. Der Anmeldeweg stand in der Schleife, und fuer die neue Messung
habe ich ihn abgeschrieben -- dabei eine aeltere Fassung erwischt,
ohne `isVisible()` und mit `click()` statt `check()`. Ergebnis:
30 Sekunden Zeitablauf an der Altersfrage, die es fuer DogFather
gar nicht gibt. Jetzt ein Helfer, den beide Aufrufer benutzen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e00a905ce8 |
Dopplung weg: "Bei dir klingelt nichts" stand zweimal auf einem Schirm
Der neue Kasten von heute Mittag hat die alte Tagesblick-Zeile nicht
ersetzt, sondern sich darueber gesetzt. Beide sagten dasselbe,
untereinander, auf derselben Seite.
GEFUNDEN HAT DAS NUR EIN BILDSCHIRMFOTO. Beide Teile waren fuer sich
gruen: pruef-glocke verlangte die Zeile, pruef-push-hinweis den
Kasten, und keine der beiden konnte sehen, dass die andere existiert.
Zahlen zeigen so etwas nie. Deshalb macht pruef-push-hinweis jetzt
bei jedem Lauf ein Foto -- und scrollt vorher hin, weil der erste
Versuch brav die Begruessungskachel zeigte und den Kasten gar nicht
im Bild hatte. Ein Beweisbild ohne das, was es beweisen soll, ist
schlimmer als keins: Man glaubt ja, hingesehen zu haben.
Entfernt wurde die aeltere der beiden (19.09.2026). Sie war gut
gebaut, server-seitig und nicht wegklickbar -- aber sie hat das
Problem nicht geloest: Am 03.10. nachgemessen hatten immer noch
12 von 20 kein Geraet, darunter die linke Hand und ein Modi. Sie SAGT
es und man kann nichts tun; sie fuehrt nur auf eine andere Seite. Der
neue Kasten hat einen Knopf und erklaert den iPhone-Fall, in dem
Web-Push ohne Home-Bildschirm gar nicht geht.
Entscheidung von Filipe am 03.10. Offen gesagt, was damit aufgegeben
ist: Wer "Nicht jetzt" tippt, bekommt keine zweite Erinnerung mehr.
Gegensicherung ist die Personenliste -- dort steht seit heute bei
jeder Person, die nichts bekommt, genau das.
pruef-glocke 36 -> 33, und die Zahl ist erklaert: 5 Pruefungen zur
alten Zeile entfernt, 2 neue dafuer. Die neuen pruefen das
GEGENTEIL von vorher -- dass die Zeile nicht unbemerkt
zurueckkommt -- mit der Zahl der geprueften Hinweise in der
Bedingung, damit eine leere Antwort der Schnittstelle nicht als
"steht nicht drin" durchgeht.
Die alte Gegenprobe ("mit angemeldetem Geraet ist der Hinweis weg")
ist ersatzlos entfallen, nicht aus Bequemlichkeit: Sie waere ab jetzt
IMMER gruen, egal was das Haus tut. Eine Pruefung, die nichts mehr
widerlegen kann, taeuscht nur Deckung vor. Was sie geprueft hat,
prueft pruef-push-hinweis am neuen Kasten, mit einer echten
Anmeldung.
OHNE_ZAHL in start.js bleibt als leere Liste stehen -- der naechste
Zustandshinweis braucht sie wieder, und als Liste ist sie die eine
Stelle dafuer.
Gegengemessen: pruef-tagesblick 23, pruef-start-ansicht 160,
pruef-push-hinweis 16 -- alle 0 Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
cc716a9c1c |
Startseite sagt einmalig Bescheid, wenn jemand nichts bekommt
Am 03.10.2026 nachgemessen: 20 aktive Personen, 8 mit einer Anmeldung. Zwoelf bekamen keine einzige Benachrichtigung -- darunter die linke Hand und ein Modi. Die heute frueh behobene Dringlichkeit hilft diesen zwoelf nichts: Ohne Anmeldung geht gar nichts hinaus. Belegt im neuen Sendeprotokoll, seit dem Deploy heute Mittag: 10 Chat-Meldungen zugestellt, 26 Versuche an "keine_geraete" gescheitert. Genau diese 26 sind der Grund. Keiner der zwoelf wusste es. Die Glocke sagt es nur dem, der sie anschaut -- und genau das hatten sie nie getan. Jetzt steht auf der Startseite eine ruhige Zeile mit zwei Knoepfen: Anschalten oder nicht jetzt. ABGELEITET AUS `lage()`, der Stelle, die es ohnehin weiss. Eine zweite Ableitung daneben waere die, die beim naechsten Umbau etwas anderes behauptet als die Glocke zwei Zentimeter weiter oben. NUR DORT, WO ES ETWAS ZU AENDERN GIBT. Bei "verboten" hilft kein Knopf (das muss man im Browser zuruecknehmen), bei "geht-nicht" erst recht nicht. Auf dem iPhone erklaert er stattdessen den Weg ueber den Home-Bildschirm -- ohne den gibt es dort gar kein Web-Push, und das weiss sonst niemand. NUR AUF DER STARTSEITE, obwohl glocke.js auf 39 Seiten laeuft: Die Seite stellt den Platz, das Skript fuellt ihn -- dasselbe Muster wie `#glocke-platz`. Auf jeder Seite waere er nach dem zweiten Mal Tapete. Ruhig, nicht alarmierend: Es ist kein Fehler, sondern eine Einstellung, die noch niemand getroffen hat. Rot waere hier falsch. pruef-push-hinweis.mjs (neu, 16 Pruefungen). Sie misst VIER Abwesenheiten und nur eine Anwesenheit, weil die Gefahr auf der anderen Seite liegt: weg nach "Nicht jetzt", weg geblieben nach dem Neuladen, nicht da auf anderen Seiten (mit der Gegenprobe, dass die Glocke dort sehr wohl steht -- sonst waere nur gemessen, dass das Skript gar nicht laeuft), und nicht da, wenn die Benachrichtigungen AN sind. Die letzte mit echter Anmeldung, die nachweislich in der Datenbank landet. Dabei gelernt, und es stand nicht im Code: `browser.newContext()` gibt ein Inkognito-Fenster, und Chrome unterstuetzt dort die Push-API nicht -- "deliberately no way to feature-detect this". Die Pruefung meldete zuerst den dritten Ausgang statt gruen, und weil sie die Browsermeldungen mitschreibt, stand die Ursache sofort da. Jetzt laeuft sie mit einem echten Profil. Gegengemessen, dass die zusaetzliche Zeile nichts verschiebt: pruef-glocke 36, pruef-start-ansicht 160, pruef-tagesblick 23, pruef-kachelraster 24, pruef-handy 189, pruef-breiten 23, pruef-lesbarkeit 14, pruef-ueberlappung (20 Breitenpaare) -- alle 0 Fehler. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
628b99943e |
Personenliste zeigt, wen eine Benachrichtigung ueberhaupt erreicht
Am 03.10.2026 am laufenden System nachgemessen: 20 aktive Personen, aber nur 8 mit einer Push-Anmeldung. Zwoelf bekommen keine einzige Benachrichtigung -- darunter ein Modi und die linke Hand. Das war fuer niemanden sichtbar. Die Glocke sagt es nur dem, der sie anschaut, und wer etwas Wichtiges schreibt, konnte nicht wissen, wen es erreicht. Die Dringlichkeit, die heute frueh behoben wurde, hilft diesen zwoelf gar nichts: Ohne Anmeldung geht nichts hinaus. Der Hinweis steht jetzt auf der Personenseite, also dort, wo ohnehin ueber Personen entschieden wird -- nicht auf einer eigenen Seite, die niemand aufruft. Aus DERSELBEN Abfrage wie alles andere; eine zweite waere eine zweite Gelegenheit, dass die Liste etwas anderes sagt als die Wirklichkeit. NUR BEIM FEHLEN, UND DAS IST ABSICHT. Stuende bei jeder Person eine Zeile, stuenden bei zwanzig Personen zwanzig Zeilen da, und die, auf die es ankommt, gingen darin unter -- eine Angabe, die immer kommt, wird nicht mehr gelesen. Schweigen heisst hier: erreichbar. Die Zeilen verschwinden eine nach der anderen, sobald jemand die Glocke anschaltet. Nicht bei gesperrten Personen: Dort ist es keine Luecke, sondern richtig so. pruef-personen-liste 33 -> 37, mit der Gegenprobe in beide Richtungen: Eine Person bekommt im Testbestand ein angemeldetes Geraet, und bei genau ihr darf der Hinweis NICHT stehen. Stuende er ueberall, waere "er steht da" wertlos. Gegengemessen, dass die zusaetzliche Zeile nichts verschiebt: pruef-personen-kachel 45, pruef-hand-personen 49, pruef-modi-verborgen 94, pruef-betreuung 18, pruef-scout-zuteilung (liest dieselbe Klasse .person__bezug) -- alle ohne Fehler. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
db8dd2fbea |
147 Zeichen je Zeile -- am Kontrast lag es nicht
Filipe: „nur die kacheln noch viel geiler. so dass ich die texte auch
besser erkenne."
NAHELIEGEND WAERE GEWESEN, die Farben aufzuhellen. Erst gemessen,
dann gebaut -- und die Vermutung war falsch:
Kontrast .s-karte__text 15,7 : 1 (noetig 4,5)
Kontrast aller zehn Textarten 7,5 bis 15,7 : 1
ZEICHEN JE ZEILE 147 (angenehm 45-75)
Am Kontrast lag es nicht; der ist ueberall ueppig. Es lag an der
ZEILENLAENGE. Auf 1280 px lief der Meldungstext ueber die ganze
Kartenbreite: 1120 px, knapp 150 Zeichen. Beim Zeilenwechsel findet
das Auge die naechste Zeile nicht mehr sicher -- man liest dieselbe
zweimal oder ueberspringt eine. Das ist der groesste Hebel beim
Lesen, und er kostet nichts.
GEAENDERT
Meldungstext 15,2 -> 17 px, max-width 72ch, Zeilenhoehe 1.6
Verlaufstext 14,4 -> 15,2 px, max-width 70ch
Kartenrand 16/18/15/22 -> 18/20/16/24 px
Trennlinie zwischen Meldung und Verlauf
147 -> 78 Zeichen je Zeile (PC), 39 auf dem Handy
`ch` UND NICHT PIXEL: `ch` ist die Breite der Null und waechst mit
der Schrift mit. Eine Angabe in Pixeln waere bei der naechsten
Schriftgroesse wieder falsch -- dieselbe Falle wie jede feste Zahl.
MEHR RAND, WEIL DIE SCHRIFT GEWACHSEN IST. Bei unveraendertem Rand
haette sie die Kante beruehrt, und die Karte waere voller gewirkt
statt lesbarer. Links bleibt es breiter: dort laeuft die
Leuchtschiene in der Farbe des Stands.
DIE TRENNLINIE kostet einen Pixel und beantwortet „wo hoert die
Meldung auf und wo faengt die Vorgeschichte an?". Vorher lief beides
ohne Zaesur ineinander.
EIN FEHLER IN MEINER EIGENEN MESSUNG -- und er haette Schaden
angerichtet
Die erste Fassung der Kontrastrechnung meldete fuer drei gut lesbare
Texte einen Kontrast von 1,04. Ich war nah dran, Farben zu
„reparieren", die in Ordnung sind.
Der Grund: `rgb()` zaehlt 0..255, `color(srgb …)` zaehlt 0..1 -- und
genau das liefert Chrome fuer jedes `color-mix()`. 0,77 als 0,77/255
gelesen ist fast Schwarz. Aufgefallen ist es nur, weil die Zahl
nicht zum Bildschirmfoto passte: Dort waren die Texte deutlich
lesbar.
DESHALB STEHT IN DER PRUEFUNG EINE GEGENPROBE IM BROWSER: Ein
absichtlich zu blasser Absatz wird eingehaengt und MUSS auffallen
(gemessen 1,23 : 1). Ohne sie waere „alle ueber 4,5" auch dann
gruen, wenn die Rechnung kaputt ist -- und genau das war sie.
GEPRUEFT -- pruef-support-bilder 56 -> 64 ok
9 Textarten in der Karte gemessen
der Meldungstext ist 16.96 px gross (mindestens 16)
und bricht nach etwa 78 Zeichen um (hoechstens 85, vorher 147)
der Verlaufstext: 15.2 px, etwa 75 Zeichen
jeder Text haelt die Kontrastschwelle (0 darunter)
— schwaechster 7.55 : 1
Gegenprobe: ein absichtlich blasser Text faellt auf (1.23 : 1)
auf 390 px ragt mit der groesseren Schrift nichts heraus (0 px)
und die Zeile bleibt lesbar lang (etwa 39 Zeichen)
Dazu gruen: pruef-css-klassen · pruef-fingermass.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
a1c2d49260 |
Drei Bilder konnte man schon -- nur sagte es niemand
Filipes Frage: „koennen die leute auch schon mehrere fotos schicken wenn die im support was melden wollen?" Technisch seit dem 02.10. (VanVans Meldung #11), und heute mehrfach am laufenden Server nachgemessen. Beim Nachsehen auf der SEITE stand aber: Knopf: „Bild anhängen" -- Einzahl Unterzeile: „häng ein Bild dran" -- Einzahl daneben: (nichts) Wer nicht zufaellig ein zweites Mal auf den Knopf tippt, schickt eines. Aus seiner Sicht waere VanVans Meldung ungeloest -- und er haette recht. EINE MOEGLICHKEIT, VON DER MAN NICHTS WEISS, GIBT ES NICHT. Das ist dieselbe Sorte wie ein Knopf, der eine Absage holt, nur andersherum: Dort verspricht die Oberflaeche zu viel, hier zu wenig. Beides kostet denselben Menschen dieselbe Zeit. GEAENDERT Knopf: „Bilder anhängen" Unterzeile: „häng Bilder dran" daneben: „bis zu 3 Bilder" -- bevor man etwas waehlt nach einem: „eins.png · 24 KB · noch 2 möglich" Die letzte Zeile ist die wichtigere von beiden: „eins.png · 24 KB" allein sagt nicht, dass ein zweites geht -- und genau an dieser Stelle hoert jemand auf. DIE ZAHL KOMMT VOM SERVER (`bilder_max`) und wird neu geschrieben, sobald sie da ist. Ohne das stuende beim ersten Laden der Vorgabewert dort -- heute zufaellig derselbe, morgen vielleicht nicht. Eine Zahl, die zufaellig stimmt, ist keine Auskunft. GEPRUEFT -- pruef-support-bilder 52 -> 56 ok der Knopf steht in der Mehrzahl („Bilder anhängen") und daneben steht, wie viele gehen („bis zu 3 Bilder") auch die Unterzeile sagt nicht mehr „ein Bild" und daneben steht, dass noch Platz ist („eins.png · 0 KB · noch 2 möglich") Dazu gruen: pruef-zeichen 7 · pruef-css-klassen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ae5b467e9a |
Der Supportverlauf: eine Zeitachse, eine Farbe je Runde
Filipe: „ich will diese komplette seite vom support viel
uebersichtlicher, profissioneller, jede runde soll auch immer eine
spezielle farbe haben und anders aufgestellt aufgeteilt sein damit
man einen viel besseren und krasseren ueberblick hat."
WAS VORHER DASTAND -- an einem Bild mit zwei Runden nachgesehen,
bevor eine Zeile angefasst wurde: vier Textzeilen untereinander,
alle in derselben Farbe. „RUNDE 1", Antwort, „Ging noch nicht · …",
„RUNDE 2". Bei fuenf Runden muss man die Runden ZAEHLEN, statt sie
zu sehen -- und wer spricht, stand nur als kleiner Name daneben.
VIER TEILE SIND NEU
1. EINE LEISTE OBEN. Ein Punkt je Runde, in ihrer Farbe, mit ihrer
Nummer -- und der Rand sagt, wie sie ausgegangen ist. Damit ist
„wie oft ging es schon hin und her?" eine Frage des Hinsehens.
Erst ab zwei Runden: bei einer waere sie ein Punkt neben nichts.
2. EINE ZEITACHSE statt einer Liste. Jede Runde haengt mit einem
Punkt an einer Linie in IHRER Farbe. Die Linie ist ein Rand an
der Runde selbst, nicht am Behaelter -- so traegt jede ihr
eigenes Stueck Achse.
3. ZWEI SPRECHRICHTUNGEN je Runde, als getrennte Kaesten:
„GEANTWORTET" in der Rundenfarbe, darunter „GING NOCH NICHT"
(Bernstein) oder „GEHT WIEDER" (gruen) oder „WARTET AUF
ANTWORT". Vorher standen beide Saetze als Absaetze untereinander
und sahen gleich aus; man musste lesen, um zu wissen, von wem
sie sind. Jetzt sagt es die Form.
4. DIE LETZTEN ZWEI OFFEN, aeltere hinter „3 fruehere Runden
zeigen". Die Leiste sagt ohnehin, wie viele es gab; im Wortlaut
braucht es nicht alle. Zwei und nicht eine: Die letzte sagt, wo
es steht, die vorletzte, woran es davor lag.
DIE FARBE WIRD GERECHNET, NICHT GEPFLEGT
`rundenTon(nr)` gibt 200 + ((nr-1) mod 4) * 32 Grad. Eine Liste mit
fuenf Farben waere die naheliegende Loesung und die falsche: Runde
sechs bekaeme keine. Diese Sorte Liste hat im Haus schon dreimal
etwas gekostet.
DER BEREICH IST ENG UND ABSICHTLICH: 200 bis 296 Grad, Blau ueber
Indigo nach Violett -- die Palette der Seite (babyblau mit lila) und
der Bereich, in dem KEINE Farbe nach „gut" oder „schlecht" aussieht.
Gruen und Bernstein sind fuer den AUSGANG reserviert; waere eine
Rundenfarbe rot, stuenden zwei Aussagen in einer Farbe.
AUGENSCHONEND: 52 % Saettigung, 64 % Helligkeit -- fuer alle Toene
gleich, und nur im CSS. Sonst waere Runde drei blasser als Runde
eins, und augenschonend ist das Gegenteil von zufaellig. Kein Neon,
kein Gluehen. Die Farbe ordnet Zeilen zu; sie schreit nicht.
UND DIE FARBE ALLEIN TRAEGT NICHTS: Die Nummer steht daneben, der
Ausgang in Worten. Fuer Vorleseprogramme gibt es statt elf Punkten
einen Satz.
EIN FUND UNTERWEGS: DIE MESSUNG MASS SEIT ZWEI TAGEN NICHTS
`mess-support-runde.mjs` schickte die Rueckmeldung noch als JSON.
Am 02.10. ist die Route auf den Kopf-Weg umgestellt worden
(`x-geht`, `x-text`); seither antwortete sie mit 400. Gemerkt hat es
niemand, weil diese Datei Bilder macht und keine Rueckgabewerte
prueft: Auf dem Bild stand danach EINE Runde statt vier, und das
sieht aus wie ein Ergebnis. Aufgefallen ist es erst, als die Bilder
vier Rundenfarben zeigen sollten.
Eine Messung, die nach einem Umbau stillschweigend etwas anderes
misst, ist schlimmer als keine -- man glaubt ihr. Sie meldet den
Fehlschlag jetzt mit Code und Text.
GEPRUEFT -- pruef-support-bilder 39 -> 52 ok
die Leiste zeigt jede Runde (5 Punkte) · mit ihrer Nummer
die ersten vier Runden haben vier verschiedene Farben (4)
und die fuenfte faengt die Reihe wieder von vorn an
Gegenprobe: sie sind nicht alle gleich (4 Farben)
auch die Rundennummern tragen ihre Farbe (2 von 2)
offen stehen die letzten zwei Runden (2)
und die aelteren sind einen Griff entfernt
jede Runde zeigt beide Seiten
aufgeklappt stehen alle da (5) · und wieder zu
auf 390 px ragt nichts heraus (0 px)
bei einer einzigen Runde gibt es keine Leiste (0)
Die Gegenprobe „sie sind nicht alle gleich" ist die wichtigste:
Waere `--ton` nicht angekommen, waeren alle Punkte grau -- und „vier
Punkte" waere gruen gewesen, ohne dass eine Farbe zu sehen ist.
Gemessen wird die ANGEZEIGTE Farbe, nicht die Zahl im Attribut.
Dazu gruen: pruef-support 104 · pruef-css-klassen · pruef-zeichen 7 ·
pruef-fingermass 5.
Eine Schriftgroesse musste nachgebessert werden: .7rem sind 11,2 px,
und unter 11,5 px faengt im Haus die Grenze an, ab der man
zusammenkneift.
NUR DAS AGENTURHAUS: Die Supportseite liegt unter `/workspace`.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
ad5e758721 |
922 px auf einem 844-px-Bildschirm -- die halbe Antwort war zu wenig
VanVan im Support, Meldung #15: „Die Modis koennen die Antworten auf die Bewerbungen im Bereich eure Aufgaben noch nicht einklappen. Das wird mit der Zeit unuebersichtlich." Heute Nacht habe ich dazu „Verstanden" gebaut: Gelesenes rutscht hinter eine zugeklappte Zeile. Das ist richtig und war trotzdem nur die halbe Antwort -- denn UNGELESENE stehen absichtlich offen da, und davon hat ein Modi im Haus gerade neun. GEMESSEN STATT GESCHAETZT, an seinem echten Bestand nachgebaut, auf dem Handy (390 x 844 px): Band: 922 px -- hoeher als das ganze Fenster Anteil der Seite: 49 % Das IST ihr Satz. Mein Umbau loeste es erst NACH einem Griff auf „Alle verstanden"; bis dahin stand die Wand unveraendert da. GEAENDERT: Hoechstens drei stehen offen, der Rest ist einen Griff entfernt („und 6 weitere"). Danach: Band: 566 px -- passt in den Bildschirm nach einem Griff: 46 px (zugeklappte Zeile) WARUM NICHT NULL: Eine Absage, die man aufklappen muss, ist keine Nachricht mehr -- das war die Begruendung vom 30.09., und sie gilt. WARUM NICHT ALLE: siehe oben. Drei ist die Zahl, bei der Kopf, Zeilen und Sammelknopf unter einem Bildschirm bleiben. DIE NEUESTEN ZUERST -- der Server sortiert nach `entschieden_am DESC`. Wer nicht aufklappt, hat die juengsten gesehen. GEPRUEFT -- pruef-bewerbung-aufgaben 178 -> 184 ok mit fuenf Ungelesenen stehen drei offen (3) und der Rest ist einen Griff entfernt („und 3 weitere") das Band passt in den Bildschirm (436 px bei 1000 px) aufgeklappt stehen alle da (6, „Weniger zeigen") und wieder zu — der Knopf geht in beide Richtungen und die Probezeilen sind wieder weg — der Stand ist wie vorher Die dritte Zeile ist die eigentliche Aussage: „drei Zeilen" waere eine Zahl, „passt in den Bildschirm" ist der Zweck. Die letzte raeumt die vier Probezeilen wieder weg -- ohne sie zaehlten die Pruefungen darunter („1 aeltere Antwort", „2 aeltere Antworten") sechs statt zwei und wuerden rot, ohne dass etwas kaputt ist. Der Knopf geht in BEIDE Richtungen, und auch das steht da: Sonst waere er ein Einwegschalter, und das faellt erst auf, wenn jemand zurueckklappen will. AUSSERDEM AN CASPERLINOS ECHTEN NEUN GEMESSEN (Kopie der Datenbank, eigener Port, nichts im Live-System): neun Antworten, alle ungelesen; „Verstanden" nimmt genau eine; „Alle verstanden" den Rest; nachlesbar bleiben alle neun; ein zweiter Druck zaehlt null; eine fremde Nummer gibt 404. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ef911691b7 |
Der zweite Weg ist weg -- nicht nur sein Knopf
VanVan im Support, Meldung #8: „Wenn man auf ich fange an drueckt steht dort in Bearbeitung und wenn man auf fertig drueckt dann wird es zu erledigt. DIE AUFGABE BLEIBT ABER IM STATUS OFFEN STEHEN." GESTERN HABE ICH DIE HALBE ARBEIT GEMACHT und daneben eine Ausrede geschrieben. Die zwei Knoepfe kamen weg, und in den Kommentar kam: „Der Weg `/mein-stand` bleibt bestehen -- er ist die Schranke, falls ihn jemand direkt anspricht." Eine Route ist keine Schranke gegen sich selbst. Sie setzte weiterhin NUR `aufgaben_zuteilung.zustand` und liess `aufgaben.status` stehen -- also genau den Widerspruch, den VanVan beschrieben hat. Ich hatte ihn unsichtbar gemacht, nicht abgeschafft: kein Knopf mehr, das Verhalten unveraendert im System. GEFUNDEN BEIM NACHMESSEN AM LAUFENDEN SERVER, nicht beim Schreiben. Filipe hat auf den Screenshot gezeigt und gesagt, es sei noch nicht in Ordnung. Statt meine Pruefungen zu zitieren habe ich die Route gelesen -- und dort stand es. NACHGEMESSEN, BEVOR SIE WEGKAM: Kein einziger Aufruf mehr im ausgelieferten Browsercode (grep ueber alle JS- und HTML-Dateien des Workspace). Nur zwei Pruefungen benutzten sie. UND EINE DAVON NICKTE DEN FEHLER AB. In pruef-zuteilung stand: Bea setzt "in Bearbeitung" (HTTP 200) und danach "erledigt" (HTTP 200) Zwei gruene Haken ueber genau dem Verhalten, das gemeldet wurde -- weil sie nur den Rueckgabewert ansahen und nie den Aufgabenstatus daneben. Eine Pruefung, die nur eine Haelfte misst, kann den Widerspruch gar nicht finden. Jetzt steht dort: Bea setzt "in Bearbeitung" (HTTP 200) und BEIDES steht auf "in Arbeit" (Aufgabe arbeit, Zuteilung arbeit) — das war VanVans Befund und danach "erledigt" (HTTP 200) und wieder beides (Aufgabe erledigt, Zuteilung erledigt) WAS JETZT GILT: `PATCH /workspace/api/aufgaben/:id` mit `{ status }`. Er setzt den Status UND zieht die Zuteilung mit (`zuteilungenNachStatus`), kennt dieselbe Sperre fuer dauerhafte Aufgaben und dieselbe Rechtepruefung. Eine Frage, eine Antwort. ENTFERNT STATT AUSKOMMENTIERT -- dieselbe Entscheidung wie bei `/vorlagen/hilfe` am 01.09.: Eine Route, die niemand mehr aufruft, wird beim naechsten Mal fuer lebenden Code gehalten und mitgepflegt. EIN SCHRECKMOMENT UNTERWEGS, der sich als Messfehler herausstellte: Nach der Umstellung meldete pruef-bewerbung-aufgaben eine 404 beim Abhaken -- also der Verdacht, dass eine ZUGETEILTE Aufgabe ueber den Statusweg gar nicht erreichbar ist und ich gerade etwas kaputt gemacht haette. Nachgemessen statt geglaubt: Die Aufgabe steht in ihrer Liste, der PATCH antwortet 200. Die rote Zeile war eine DRITTE Stelle, die ich beim Umstellen uebersehen hatte und die noch auf die alte Route zeigte. Zwei Minuten Messung statt einer Stunde Suche an der falschen Stelle. GEPRUEFT pruef-zuteilung ok, mit zwei neuen Zeilen, die BEIDE Zustaende messen den zweiten Weg (mein-stand) gibt es nicht mehr (404) pruef-bewerbung-aufgaben 178 ok pruef-struktur 102 ok, 414 -> 413 Routen pruef-aufgabenbrett · pruef-modi-katalog 159 · pruef-aufgaben-vorlagen 60 Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d70d00cedc |
Jede Sprachnachricht in einer Fassung, die JEDES Geraet abspielt
Miss im Support, Meldung #12 -- fuenf Runden seit dem 23.09.: „Bei mir laesst sich die Nachricht nicht abspielen." Zuletzt: „Jetzt laedt es die ganze Zeit." Bei allen anderen ging es. GEMESSEN, BEVOR GEBAUT WURDE · Alle sechs Sprachnachrichten im Haus sind audio/webm (Opus). · Miss' Geraet: iPhone, iOS 18.7, WebKit. · Seit der Umstellung am 02.10. (neue Aufnahmen bevorzugen MP4) wurde KEINE EINZIGE neue aufgenommen. Ihr Problem betrifft also ausschliesslich die sechs alten Dateien -- und jede kuenftige aus einem Firefox, der nichts anderes kann. WAS ICH NICHT MESSEN KONNTE, und das gehoert dazu: Ob WebKit WebM/Opus abspielen kann, laesst sich auf diesem Rechner nicht nachsehen -- Playwrights WebKit startet hier nicht (libegl.dll fehlt). Die Vermutung „iPhones koennen kein WebM" ist begruendet, aber von mir nicht gemessen. GENAU DESHALB STELLT DIE LOESUNG DIE FRAGE NICHT. Statt zu raten, welches Geraet welchen Behaelter kann, legt der Server neben jede Sprachnachricht eine zweite Fassung in dem Format, bei dem sich seit zwanzig Jahren alle einig sind: AAC in MP4. Gibt es sie, wird sie abgespielt -- bei jedem, nicht nur auf iPhones. Kein Geraetename im Code, keine Liste, die altert. helfer-ffmpeg.mjs ffmpeg finden, umwandeln, drei Ausgaenge beim Hochladen nebenher, nicht davor: Die Nachricht wartet nicht auf ffmpeg toeneNachruesten() das Netz darunter -- fuer die sechs von frueher und fuer den Fall, dass eine Umwandlung einmal nicht geklappt hat ?form=mp4 dieselbe Route, dieselben Rechte; eine zweite haette dieselbe Sichtbarkeitspruefung ein zweites Mal gebraucht ffmpeg IST ABGESPROCHEN INSTALLIERT (Debian 7.1.5, auf Nachfrage freigegeben). Fehlt es, passiert nichts Schlimmes: Die Sprachnachricht geht wie bisher im Originalformat hinaus, und es steht EINMAL eine Zeile im Protokoll -- nicht bei jedem Hochladen. DREI ENTSCHEIDUNGEN, DIE NICHT NAHELIEGEND WAREN 1. `-movflags +faststart` IST NICHT KOSMETIK. Ohne es steht die Inhaltsuebersicht einer MP4 am ENDE. Das Abspielgeraet muss dann erst bis ans Ende lesen, bevor es anfangen kann -- genau das „laedt die ganze Zeit" aus Miss' Runde 5. Geprueft wird die Reihenfolge der Kaesten in der Datei, nicht die Zeile im Aufruf. 2. DAS ORIGINAL BLEIBT LIEGEN. Ohne `?form=mp4` kommt weiter die WebM. Sie ist das, was aufgenommen wurde; sie durch eine Umrechnung zu ersetzen hiesse, das Original wegzuwerfen. 3. EIN GEMEINSAMER LOESCHER. Zwei Stellen entfernen Anhaenge (Gespraech wegraeumen, Nachricht zuruecknehmen). Beide nahmen genau eine Datei -- ab heute waere bei jeder geloeschten Sprachnachricht eine m4a liegengeblieben, ohne Zeile, die auf sie zeigt. Dieselbe Luecke hatte ich gestern bei den Supportbildern gefunden; hier steht sie von Anfang an an EINER Stelle. ZWEI FUNDE DER PRUEFUNG, BEIDE MEINE EIGENEN · `anhang_datei` STAND NICHT IN DER ABFRAGE der Nachrichtenliste. Die Funktion, die auf der Platte nachsieht, bekam deshalb nichts und sagte brav „gibt es keine zweite Fassung" -- fuer JEDE Nachricht. Alles war gebaut, nichts kam an. Gefunden hat das die Pruefung, nicht das Lesen. · Mein erster Anlauf mass die Aufnahme ueber den Knopf -- und die ist seit dem 02.10. schon MP4, braucht also gar keine zweite Fassung. Die Pruefung wurde rot und hatte recht: Gemessen werden muss der Fall, den es bei Miss gibt. Jetzt nimmt sie ausdruecklich eine WebM auf. Dazu zweimal derselbe alte Tritt: ein Gegen-Apostroph in einem Kommentar INNERHALB eines Template-Literals. Der Server startet dann gar nicht. Steht jetzt als Warnung an beiden Stellen. GEPRUEFT -- pruef-chat-anhaenge 146 -> 163 ok Eine echte WebM/Opus-Aufnahme (31 972 Bytes) wird hochgeladen; die zweite Fassung entsteht von selbst und kommt als audio/mp4 heraus, mit „ftyp"-Marke, mit Accept-Ranges. ffprobe sagt: Original Opus, Zweitfassung AAC, 2,40 s gegen 2,46 s. Die Inhaltsuebersicht steht bei Byte 32, die Tondaten ab 1270 -- also vorne. Beim Loeschen gehen beide Dateien. Gegenproben: ein Bild bekommt keine zweite Fassung; eine halbierte Laenge waere aufgefallen; das Original bleibt unter seiner eigenen Adresse abrufbar. Der dritte Ausgang hat einen eigenen Zaehler: Fehlt ffmpeg, steht „KONNTE NICHT NACHSEHEN" mit Anleitung da -- nicht gruen und nicht rot. Und der Block raeumt hinter sich auf: Mein Probebild liess eine spaetere Pruefung rot werden, weil es die Gespraechsliste veraendert hatte. Eine Pruefung, die den Stand fuer die naechste verschiebt, ist schlimmer als keine. Dazu gruen: pruef-struktur 102 (92 Module) · pruef-ports 10 · pruef-gifs 17 · pruef-treffchat 114 · pruef-chat-optik · pruef-aufbewahrung 45. NUR DAS AGENTURHAUS? NEIN -- der Chat gehoert beiden Haeusern, und die Aenderung gilt fuer beide gleich. Sie aendert nichts an Sichtbarkeit oder Rechten: Wer eine Nachricht hoeren darf, hoert sie jetzt in einem Format, das sein Geraet kann. OFFEN BLEIBT DIE ANTWORT VON MISS. Ob es bei ihr jetzt laeuft, weiss nur sie -- deshalb steht ihre Meldung weiter offen und nicht auf erledigt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
1ce2c3785e |
Der Hinweis an der Anmeldung sagte seit dem 01.10. das Gegenteil
VanVan im Support, Meldung #5, zweite Runde: „Man kann sich jetzt nur noch über die richtige Schaltfläche anmelden. Das funktioniert jetzt. Aber wenn man sich 2x versucht über den falschen Button anzumelden, dann kommt ein irreführender Text wo steht, dass die Auswahl oben nicht schuld ist." SIE HAT RECHT -- UND DER GRUND IST MEINE EIGENE AENDERUNG Auf der Crew-Wand stand ab dem zweiten Fehlversuch: „Zugangscode stimmt nicht. Achte auf die Bindestriche -- die Auswahl oben ist nicht schuld." Das war am 20.09.2026 richtig. Dort gab es den STILLEN ZUGANG: Die rechte Hand und die Modis kamen ueber die Codekennung herein, egal welche Kachel sie antippten. Der Satz „Stimmt die Auswahl oben?" haette sie in eine Schleife geschickt -- alle Kacheln durchprobieren, acht Fehlversuche, Adresse gesperrt. Ein Hinweis, der die Sperre herbeifuehrt, gegen die er helfen soll. Mit VanVans ERSTER Runde derselben Meldung ist der stille Zugang weggefallen („es soll fest sein"). Nachgemessen in workspace.js: Die Kandidaten kommen seither aus `WHERE rolle = ?`, auf beiden Waenden. Die Kachel entscheidet ueberall -- und der Satz sagte ab diesem Tag das Gegenteil der Wahrheit, genau an der Stelle, an der jemand feststeckt. DAS IST DIE SORTE FEHLER, DIE EIN UMBAU HINTERLAESST: Nicht der neue Code war falsch, sondern ein Satz drei Dateien weiter, dessen Voraussetzung er entfernt hat. Er stand sogar ausfuehrlich begruendet da -- und die Begruendung las sich beim Umbau wie eine Bestaetigung, weil sie von einem Zustand sprach, den es nicht mehr gab. Gefunden hat ihn kein Prueflauf, sondern VanVan beim Benutzen. GEAENDERT: Ein Satz fuer beide Waende. Die Fallunterscheidung nach Wand ist weg -- es gibt nur noch eine Regel, also auch nur noch eine Auskunft. Der Hinweis auf die Bindestriche bleibt; er galt nie nur fuer eine Wand. „Zugangscode stimmt nicht. Stimmt die Auswahl oben? Ein Code gehört immer zu genau einer davon – und achte auf die Bindestriche." GEPRUEFT -- pruef-modi-verborgen 87 -> 94 ok Im echten Browser, beide Waende (crew-index.html und index.html), je zweimal mit einem falschen Code: · die Waende sind wirklich verschieden (gate--crew true/false) · „nicht schuld" steht nirgends mehr · stattdessen die Frage nach der Auswahl -- die dort seit dem 01.10. wirklich gilt (Abschnitt 1 derselben Datei misst das) · derselbe Satz auf beiden Waenden · Gegenprobe: nach dem ERSTEN Versuch steht er noch nicht da, dort steht die kurze Absage. Ein Hinweis, der immer kommt, waere keiner. DIE VERSUCHSSPERRE WIRD VOR DER MESSUNG GELEERT. Acht Fehlversuche je Adresse in zehn Minuten -- die Abschnitte davor verbrauchen welche, und ab dem neunten stuende „Zu viele Versuche" statt des Satzes. Das waere ein roter Haken ueber die Messumgebung gewesen, nicht ueber das Programm. Dazu: pruef-struktur 102 ok. BEIDE HAEUSER BETROFFEN, und das ist hier richtig: Es ist dieselbe Anmeldung mit derselben Regel. Nachgewiesen wird genau das -- der Satz ist auf beiden Waenden derselbe, und er stimmt auf beiden. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
f2f11e8091 |
Gelesene Antworten rutschen zur Seite -- statt sich zu stapeln
VanVan im Support, Meldung #15: „Die Modis können die Antworten auf die Bewerbungen im Bereich eure Aufgaben noch nicht einklappen. Das wird mit der Zeit unübersichtlich." WARUM ES NICHT EINFACH EIN SCHALTER GEWORDEN IST Am 30.09. habe ich diesen Kasten absichtlich NICHT einklappbar gebaut, und die Begruendung steht woertlich im Quelltext: „Eine Antwort, die man erst aufklappen muss, ist wieder keine." Sie ist richtig -- fuer eine Antwort, die man noch nicht gelesen hat. Danach ist sie falsch herum, und genau das meldet VanVan. Ein Schalter, der alles wegklappt, haette die naechste Absage mitversteckt: die Zeile, derentwegen der Kasten ueberhaupt entstanden ist. Deshalb nicht „einklappbar", sondern GELESEN: · Was noch niemand quittiert hat, steht offen da -- wie bisher. · „Verstanden" schiebt eine Zeile hinter „N ältere Antworten", zugeklappt, jederzeit wieder aufzumachen. Nichts wird geloescht; eine Absage samt Begruendung wegzuwerfen, weil jemand sie einmal gelesen hat, waere das Gegenteil des Umbaus vom 30.09. · Ab zwei offenen Antworten gibt es „Alle N verstanden" -- wer nach dem Urlaub sieben vorfindet, soll nicht siebenmal tippen, und sieben Anfragen waeren sieben Gelegenheiten, dass eine verloren geht. AM MENSCHEN, NICHT AM GERAET `gesehen_am` steht in `vorlagen_bewerbungen`, nicht im Browserspeicher. „Habe ich das gelesen?" ist eine Frage ueber die Person: Sonst waere dieselbe Antwort auf dem Handy wieder neu, nachdem man sie am Rechner gelesen hat -- und das waere genau die Unuebersichtlichkeit, die gemeldet wurde, nur eine Tuer weiter. Das AUFKLAPPEN der aelteren bleibt dagegen im Augenblick: kein Zustand, den man mitschleppt. Nach dem Neuladen ist wieder zu. GEGEN FREMDE ZEILEN GESCHUETZT: Nur die eigenen, nur die beantworteten, 404 statt 403 -- wie ueberall im Haus. Ein zweites „Verstanden" zaehlt nicht noch einmal, sonst wanderte die Zeile bei jedem Klick ans Ende und man saehe nicht mehr, wann man sie wirklich gelesen hat. WAS ICH FALSCH ERWARTET HATTE: Meine erste Pruefung verlangte, dass nach einem „Verstanden" OBEN NICHTS mehr steht. Sie wurde rot -- Frida hatte zwei Antworten, und der Knopf gilt je Zeile. Die Pruefung hatte recht; dass er nur seine eigene Zeile nimmt, ist das gewollte Verhalten und steht jetzt als Aussage dort. NEBENBEI: Ein 11,2-px-Pfeil (gemeldet von pruef-css-klassen). Unter 11,5 px faengt im Haus die Grenze an, ab der man zusammenkneift -- dass es „nur ein Zeichen" ist, aendert daran nichts. GEPRUEFT pruef-bewerbung-aufgaben 164 -> 178 ok Im echten Browser, am Handy (390 px): die ungelesene Antwort steht offen mit „Verstanden", danach ist genau diese eine Zeile weg (2 -> 1), sie liegt hinter „1 ältere Antwort", zugeklappt wird sie gar nicht erst gebaut, aufgeklappt steht sie samt Begruendung wieder da, „Alle verstanden" raeumt den Rest, nach dem Neuladen gilt beides weiter als gelesen und ist wieder zu. Am Server: fremde Antwort 404, erfundene Nummer 404, zweites „Verstanden" zaehlt 0. pruef-struktur 102 ok, 414 Routen (eine neue) · pruef-css-klassen · pruef-zeichen 7 · pruef-modi-katalog 150 · pruef-vorlagen 24 · pruef-aufgaben-vorlagen 60 NUR DAS AGENTURHAUS. „Eure Aufgaben" liegt unter `/workspace`; am Crew-Haus aendert sich keine Zeile. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
018d02c3b8 |
Vorlagen anpassen: Frist, dauerhaft und eine Anmerkung
VanVan im Support, Meldung #6, zweite Haelfte -- der Rest, der heute frueh ausdruecklich offen stehen blieb: „Bei den Vorlagen laesst sich weder die Frist anpassen noch ‚dauerhaft' einstellen, und eine Anmerkung fehlt auch." EIN ZWEITER KNOPF, NICHT EIN FENSTER FUER ALLE „An alle" verteilt zwoelf Aufgaben mit einem Druck. Haette jedes Uebernehmen jetzt ein Fenster geoeffnet, waere der haeufige Weg langsamer geworden, um den seltenen moeglich zu machen. Neben „Uebernehmen" steht deshalb „Anpassen …" -- an den Creator-Vorlagen und am Katalog, aus derselben Funktion. DAS FENSTER IST DAS DES HAUSES `frageNach` kann seit heute ein DATUM und einen HAKEN, die Anmerkung konnte es als `grund` schon. Ein eigener kleiner Dialog in vorlagenbrett.js waere der zweite im Haus gewesen -- und der, in dem beim naechsten Mal Esc, Fokusfalle oder der Abbruch fehlen. Beide Felder sind standardmaessig aus; fuer die dreissig anderen Aufrufe aendert sich nichts. DREI ENTSCHEIDUNGEN, DIE NICHT NAHELIEGEND WAREN 1. DIE ANMERKUNG WIRD EINE NOTIZ (`aufgaben_notizen`), kein Anhang an der Beschreibung. Sie traegt damit, von wem sie stammt, und die Aufgabe zeigt sie ohnehin an. In die Beschreibung geschrieben waere sie von der Vorlage nicht mehr zu unterscheiden -- und dieselbe Vorlage haette beim naechsten Mal einen anderen Text. 2. EINE DAUERHAFTE AUFGABE BEKOMMT KEINE FRIST, auch wenn eine mitgeschickt wird. Sie waere ab dem naechsten Tag fuer immer ueberfaellig, und eine Warnung, die immer kommt, ist keine mehr. Dieselbe Regel steht seit Langem im Aenderungsweg; haette sie hier gefehlt, gaebe es zwei Antworten auf dieselbe Frage. Im Fenster wird das Datum deshalb GRAU, sobald der Haken sitzt -- ein Datum, das dasteht und nicht gilt, ist schlimmer als keins. 3. „DAUERHAFT" DARF NUR, WER VERTEILEN DARF. Eine dauerhafte Aufgabe laesst sich nicht abhaken (Commit von heute frueh); wer sie sich selbst anlegen koennte, haette etwas, das er nie wieder loswird. Der Haken fehlt deshalb im Fenster eines Creators -- und abgelehnt wird trotzdem am Server, nicht nur ausgeblendet. EIN FUND, DEN DIE PRUEFUNG GEMACHT HAT `Number(tage) || 7` -- die Untergrenze des Datumsfeldes lag dadurch sieben Tage in der Zukunft statt heute, weil Null in JavaScript unwahr ist. Die VORGABE („in 1 Tag") lag damit UNTER der erlaubten Grenze: Wer das Fenster oeffnete und einfach „Uebernehmen" drueckte, bekam eine Absage. `Number.isFinite` fragt, ob eine Zahl da ist, und nicht, ob sie wahr ist -- derselbe Unterschied wie bei `kill -0`. NEBENBEI BEHOBEN: Ein gerades Anfuehrungszeichen in einem deutschen Fehlersatz (gemeldet von pruef-struktur). GEPRUEFT pruef-aufgaben-vorlagen 46 -> 60 ok eigene Frist kommt an (und die Vorlage saehe 5 Tage vor -- die Angabe hat also wirklich gewirkt), Anmerkung wird woertlich zur Notiz mit Namen, ohne Angabe bleibt alles wie bisher, Scout 403 und es entsteht auch nichts, DogFather 200 und KEINE Frist, „morgen" 400, der 45.13. 400, Vergangenheit 400, und als Gegenprobe dieselbe Vorlage ohne Frist 200. Im Browser: der Knopf, das Fenster, die Vorgabe, kein Haken fuer einen Creator, die Aufgabe traegt danach genau die eingetragene Frist samt Notiz -- und Abbrechen legt nichts an. pruef-nachfrage 74 -> 89 ok Datum mit Vorgabe und Untergrenze, Haken 44 px hoch mit 22-px- Kaestchen (nicht ueber die ganze Zeile), Sperre und Gegenprobe, beide Schranken fuer ein zu fruehes Datum einzeln. pruef-struktur 102 · pruef-css-klassen · pruef-modi-katalog 150 · pruef-aufgabenbrett · pruef-vorlagen 24 · pruef-bewerbung-aufgaben 164 · pruef-zuteilung NUR DAS AGENTURHAUS. Vorlagenbrett und Aufgaben liegen unter `/workspace`; am Crew-Haus aendert sich keine Zeile. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b31bd9b515 |
Zwei bis drei Bilder je Supportmeldung -- und zwei Funde unterwegs
VanVan im Support, Meldung #11, VIERMAL gemeldet: „Hier im Supportbereich kann man immer nur ein Bild hinzufuegen bei einer Meldung. 2-3 waeren besser." Und in der zweiten Runde der Satz, auf den es ankommt: „wenn man es nacheinander versucht hinzuzufuegen wird das Bild immer nur ersetzt." EINE TABELLE STATT NEUER SPALTEN `support_bilder` haelt ab jetzt JEDES Supportbild -- das der Meldung (`runde_nr` NULL) und das einer Antwort (`runde_nr` = Runde). Die Alternative waere `bild2_datei`, `bild3_datei` gewesen, und beim vierten Bild wieder. Eine Zeile je Bild kennt keine Obergrenze im Schema; die Grenze steht an EINER Stelle im Code (`BILDER_MAX = 3`) und kommt von dort in die Oberflaeche, statt dort ein zweites Mal zu stehen. DIE ACHT VORHANDENEN BILDER WANDERN MIT. Ohne diesen Schritt haette die neue Tabelle ab heute recht und die alten Bilder waeren unsichtbar -- ohne Fehler, ohne rote Zeile, nur acht leere Karten. Der Umzug steht NACH der Spaltennachruestung: Er liest `urteil_bild_datei`, und die gibt es in einer bestehenden Datenbank erst, nachdem sie ergaenzt wurde. Stuende er davor, scheiterte er genau dort, wo es darauf ankommt -- live, waehrend lokal alles gruen bliebe, weil jede Pruefung ihre Datenbank frisch anlegt. DREI BILDER IN EINER ANFRAGE `x-bilder: 20481,15320` sagt, wo zu schneiden ist, der Rumpf ist die Aneinanderreihung. `multipart/form-data` haette einen Zerleger gebraucht, den dieses Haus nicht hat; drei Anfragen nacheinander haetten den Zustand „Meldung da, Bild zwei laedt noch" erzeugt -- genau den, gegen den die Kommentare an dieser Route schon vorher argumentieren. Die Summe muss auf das Byte stimmen, und jedes Stueck wird einzeln an seinen ersten Bytes erkannt: Wer falsch schneidet, bekommt eine Absage, kein verfaelschtes Bild. Ohne den Kopf gilt der ganze Rumpf als ein Bild -- derselbe Satz mit einer Laenge, damit eine Seite aus dem Zwischenspeicher weiterlaeuft. EINE ROUTE STATT DREI. `/:id/bild` und `/:id/runde/:nr/bild` sind weg; es gibt `/:id/bild/:bid`. Wohin ein Bild gehoert, steht in seiner Zeile -- der Weg muss es nicht wiederholen. Die Meldungsnummer bleibt trotzdem im Pfad: Sie ist die Sichtbarkeitsfrage, und beides muss zusammenpassen (gemessen). ZWEI FUNDE, DIE DIE PRUEFUNG GEMACHT HAT UND NICHT ICH 1. UEBER DIE SEITE KAM GAR KEIN BILD MEHR AN. Beim Melden stand kein `Content-Type`. Das ging gut, solange der Rumpf eine einzelne Datei war -- ein `File` bringt seinen Typ mit. Ein `Blob` aus mehreren hat keinen, `fetch` schickt die Zeile dann gar nicht, `express.raw` fuehlt sich nicht zustaendig, und der Server bekam einen leeren Rumpf. Die Meldung waere durchgegangen, der Text angekommen, die Bilder weg -- ohne Fehlermeldung. Alle Pruefungen am Server waren dabei gruen; gefunden hat es erst der echte Browser. 2. DAS KREUZ DES DRITTEN BILDES LAG AUF DEM ZWEITEN. Der Entfernen-Knopf ist 44 px breit und absolut gesetzt, der Kasten aber nur so breit wie sein Bild. Bei einem schmalen Bild ragt er darueber hinaus -- wer „das zweite weg" antippt, loescht das dritte. `min-width`/`min-height` loesen das an der Ursache: Ein Kasten ist nie schmaler als der Knopf in ihm. WAS ICH FALSCH ANGENOMMEN HATTE: Ich hatte eingebaut, dass ein Nachtrag in derselben Runde die Bilder ersetzt. Die Pruefung dazu wurde rot -- zu Recht: Eine zweite Antwort in derselben Runde kann es nicht geben, die erste verlaesst den Stand „wartet". Der Code waere nie gelaufen und damit nie pruefbar gewesen. Er ist weg; an seiner Stelle steht der Beweis, dass er nicht fehlt. DREI WEITERE ROTE ZEILEN, DIE NICHT ZU DIESEM UMBAU GEHOERTEN * `manager-ziele.js` hatte einen ZWEITEN Notnagel (`frageNach ? … : confirm(…)`). `nachfrage.js` hat denselben laengst, und zwar mit dem vollstaendigen Text; der hiesige war der kuerzere und haette gewonnen. Zwei Antworten auf dieselbe Frage -- gemeldet von `pruef-nachfrage`. * Zwei Mittelpunkte in `reaktion.css` standen woertlich im `content`. Sie liegen im Latin-1-Block, wo `pruef-zeichen` die Truemmer einer verunglueckten Kodierung sucht. Jetzt als Escape -- im Browser nachgemessen, es steht Zeichen fuer Zeichen dasselbe da. * Das Aufraeumen nach 90 Tagen loeschte nur das EINE Bild der Meldung; die Bilder aus den Antwortrunden blieben ohne Zeile auf der Platte liegen. Die Liste kommt jetzt aus einer Abfrage statt aus einer Spalte und kann deshalb nicht wieder unvollstaendig sein. GEPRUEFT pruef-support 78 -> 104 ok darunter: der Umzug der alten Bilder auf einer eigenen Wegwerf-Datenbank -- zweimal und dreimal gestartet, nichts verdoppelt, Datum von damals erhalten pruef-support-bilder NEU, 36 ok (echter Browser) dreimal nacheinander waehlen ergibt drei, das vierte wird mit einem Satz abgelehnt, dasselbe zaehlt nicht doppelt, einzeln entfernen laesst die anderen stehen, alle drei laden wirklich (naturalWidth), Kreuze 44x44 und keines verdeckt (mit Gegenprobe per Deckel), nichts ragt auf 390 px heraus pruef-nachfrage 69 -> 74 ok pruef-struktur 102 ok, 413 Routen (vorher 414: zwei weg, eine neu) pruef-zeichen 7 ok (vorher 1 Fehler) pruef-aufbewahrung 45 ok pruef-manager-ziele 216 ok pruef-ports 10 ok · pruef-portnummern 41 ok (die neue Pruefdatei verschiebt die abgeleiteten Nummern) NUR DAS AGENTURHAUS IST BETROFFEN. Die Supportseite liegt unter `/workspace`; am Crew-Haus aendert sich keine Zeile. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
3ab69d36a5 |
Eine dauerhafte Aufgabe wird nicht abgehakt -- auch nicht ueber den Status
VanVan im Support, Meldung #6: „Der Modi kann die dauerhafte Aufgabe immer noch auf erledigt setzen." DIE SPERRE GAB ES SEIT DEM 30.09. -- ABER NUR AN EINER TUER. `/mein-stand` lehnt „erledigt" bei einer dauerhaften Aufgabe seither ab. Der STATUSWEG (`PATCH /workspace/api/aufgaben/:id`) kannte `dauerhaft` ueberhaupt nicht. Wer die Aufgabe ohnehin aendern durfte -- etwa weil das Uebernehmen aus dem Pool ihn verantwortlich macht -- hakte sie damit einfach ab. Zwei Tueren, eine Regel, und die Regel hing nur an einer. UND ICH HABE DAS LOCH HEUTE FRUEH VERBREITERT. Mit dem Commit davor darf eine Modi den Status ihrer Aufgabe setzen (damit VanVans Satz „es gibt darüber ja den button starten" fuer sie ueberhaupt stimmt). Damit stand ihr genau der Weg offen, der ihr an der anderen Tuer ausdruecklich verwehrt ist. Gefunden habe ich es nicht beim Bauen, sondern beim Lesen der offenen Supportmeldungen -- ihr Satz stand seit dem 28.09. da und passte ploetzlich auf meine eigene Aenderung. GEAENDERT 1. Der Statusweg lehnt „erledigt" bei einer dauerhaften Aufgabe ab, wenn die Person nicht verteilen darf. DERSELBE Fehlercode wie in `/mein-stand` (`dauerhafte_aufgabe`) -- die Oberflaeche uebersetzt ihn schon, und ein zweiter Code fuer dieselbe Sache waere der, den beim naechsten Mal jemand uebersetzt und der andere nicht. 2. Der Knopf faellt weg, der die Absage holen wuerde (`darf_beenden` vom Server). Dieselbe Ueberlegung wie bei „Fertig" auf der Zuteilungskarte, die seit dem 30.09. daneben steht: Ein Knopf, der eine Absage holt, ist schlimmer als keiner. NUR DER LETZTE SCHRITT faellt weg. „starten" und „zur Freigabe" bleiben -- auch eine stehende Aufgabe hat einen Anfang, und der Unterschied zwischen „offen" und „in Arbeit" sagt etwas. 3. BEENDET WIRD SIE VON DER LEITUNG. Das stand seit dem 30.09. als Satz im Kommentar von `/mein-stand`; jetzt stimmt er auch. GEPRUEFT -- UND ZWAR BEIDE TUEREN, sonst wandert der Fehler nur: eine dauerhafte Aufgabe (#3) Tuer 1 (mein-stand) ist zu (409 dauerhafte_aufgabe) Tuer 2 (Status) jetzt auch (409 dauerhafte_aufgabe) anfangen darf sie trotzdem (200) und die Leitung beendet sie (200) und die Oberflaeche erfaehrt es (darf_beenden false) Die dritte Zeile ist die Gegenprobe gegen zu viel Sperre: „gesperrt" darf nicht heissen, dass gar nichts mehr geht. GEPRUEFT: pruef-zuteilung 90 -> 96 ok · pruef-bewerbung-aufgaben 164 · pruef-aufgabenbrett 49 · pruef-aufgaben-vorlagen 46 · pruef-struktur 102. WAS AUS DERSELBEN MELDUNG NOCH OFFEN IST (VanVan, #6): Bei den VORLAGEN laesst sich weder die Frist anpassen noch „dauerhaft" einstellen, und eine Anmerkung fehlt auch. Das ist ein eigener Umbau und steht hier nur, damit es nicht untergeht. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
baf8288433 |
Korrigieren duerfen jetzt beide: Spicy Media und DogFather
Filipe auf die Rueckfrage, wer fremde Eintraege richtigstellen darf: „ja spicy und dogfather". Die Vorlage kannte dort nur DogFather („Vergangene Monate sind gesperrt ... Ausnahme: DogFather"). Das gilt ab jetzt fuer beide -- und zwar fuer BEIDE Faelle, nicht nur fuer einen: * einen fremden Eintrag aendern oder loeschen * einen abgeschlossenen Monat dafuer kurz oeffnen ES IST EINE MENGE UND KEINE ZWEITE LISTE. `darfKorrigieren()` gibt `siehtAlles()` zurueck -- dieselbe Menge, die schon ueber die Team-Uebersicht und die Zielzahlen entscheidet. Eine eigene Aufzaehlung derselben zwei Rollen waere die, die beim naechsten Umbau auseinanderlaeuft. Und inhaltlich gehoert es zusammen: Wer alle Zahlen sieht und die Ziele setzt, muss einen Zahlendreher gerade ruecken koennen; zwei verschiedene Grenzen fuer „darf alles sehen" und „darf etwas richtigstellen" koennte spaeter niemand mehr erklaeren. Der Name der Variablen hiess vorher `istAdmin` -- also die Rechnung statt ihrer Bedeutung. Jetzt heisst sie, was sie beantwortet. NACHVOLLZIEHBAR BLEIBT ES UNVERAENDERT: Jede Korrektur an einem fremden Eintrag und jede Aenderung an einem abgeschlossenen Monat steht mit Name, Rolle und Zeit im Protokoll -- geprueft wird jetzt ausdruecklich, dass dort auch `spicy` auftaucht. GEPRUEFT: 206 Pruefungen, 0 Fehler (vorher 194) Die Grenze wird in beide Richtungen gemessen, nicht nur in eine: Spicy aendert wirklich (200, und der neue Wert steht in der Datenbank), Spicy loescht wirklich -- aber ein Manager und ein fremder Scout werden weiterhin abgewiesen (403), und danach steht immer noch der Wert von Spicy da. Ohne diese Gegenproben hiesse „Spicy darf" moeglicherweise „jeder darf". Loeschen ist eigens geprueft: PATCH und DELETE sind zwei Routen, und zwei Routen koennen auseinanderlaufen. Auch die Freigabe fuer alte Monate wird nach Spicys Korrektur wieder geschlossen gemessen -- eine geoeffnete Tuer ist kein Erfolg. EINE MEINER PRUEFUNGEN WAR WIEDER FALSCH, NICHT DER CODE: Ich hatte erwartet, dass ein Manager mit einer fremden Nummer in der Adresse „nicht bearbeitbar" bekommt. Er bekommt `true` -- weil er gar keine fremde Liste bekommt, sondern seine eigene; die Nummer wird fuer ihn schlicht nicht beachtet. Richtiges Verhalten, falsche Frage. Gemessen wird jetzt, was zaehlt: dass bei ihm kein einziger fremder Eintrag ankommt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b46f75484f |
Ein Klick statt eines Formulars -- der Schnell-Eintrag
Filipe mit dem Bildschirmfoto der Zeilen: „ich will das viel perfekter
und geiler. will dass es viel einfacher ist. am besten so wenig wie
moeglich zu tippen. fertige sachen, bereit um ab zu gehen."
GEZAEHLT, WAS EIN EINTRAG VORHER KOSTETE -- das war der Punkt:
Manager Meeting Knopf, Dialog, Speichern 2 Klicks + Fenster
Schulung dazu die Art waehlen 3 Klicks + Fenster
Werbung dazu den Link tippen 2 Klicks + tippen
Creator dazu den Namen tippen 2 Klicks + tippen
Ein Fenster fuer die Aussage „ich war heute im Meeting" sind drei
Handgriffe fuer null Angaben. Vier Aufgaben im Monat, acht Klicks,
acht Fenster.
JETZT
Manager Meeting EIN Klick („Heute eingetragen")
Schulung EIN Klick (zwei fertige Knoepfe)
Werbung Einfuegen + Eintragen, kein Tippen
Creator ein Klick je Lead -- oder mehrere Namen auf
einmal einwerfen
Am echten Bildschirm nachgemessen: 0/2 vorher, EIN Klick, 1/2 nachher,
„Rueckgaengig" bringt 0/2 zurueck. Nicht „der Knopf ist da", sondern
„danach steht eine andere Zahl dort".
DREI ENTSCHEIDUNGEN DAHINTER
1. DER WEG NIMMT EINE LISTE. „Drei Creator auf einmal" ist EIN
Vorgang. Wer drei Namen aus Discord kopiert, hat das Monatsziel in
einem Zug erledigt -- das ist der eigentliche Gewinn, nicht der
gesparte Klick.
JEDER EINTRAG WIRD EINZELN GEPRUEFT UND EINZELN BEANTWORTET. Die
ganze Liste zurueckzuweisen, weil ein Name schon dasteht, waere
die bequeme und die falsche Loesung: Dann weiss niemand, welcher
der drei das Problem war, und tippt alles noch einmal. Geprueft
wird genau dieser Fall -- zwei gehen durch, einer wird im Klartext
abgelehnt, mit Namen.
2. KEINE SICHERHEITSABFRAGE VORHER, SONDERN „RUECKGAENGIG" DANACH.
Eine Nachfrage bei jedem Klick waere der Handgriff, den wir gerade
abgeschafft haben, in neuer Verkleidung. Sie kostet jeden; das
Zuruecknehmen kostet nur den, der sich vertippt hat. Acht Sekunden
statt drei -- lang genug, um es mit einem Daumen zu treffen.
3. DIE ZULETZT GEWAEHLTE ART IST VORGEWAEHLT -- abgeleitet aus dem
letzten Eintrag, nicht in einer Einstellung gespeichert. Eine
Spalte „Lieblingsart" waere ein zweiter Bestand, der veralten
kann; der letzte Eintrag veraltet nie.
WAS MIR DABEI AUFGEFALLEN IST
Ein Ein-Klick-Knopf macht den Doppeltipper zur wahrscheinlichsten
Fehleingabe -- bei „Heute eingetragen" merkt man nichts davon, es gibt
ja keine Angabe. Zwei Meetings an einem Tag zu VERBIETEN waere aber
falsch, sie sind moeglich. Also ein Hinweis statt einer Sperre:
„Fuer diesen Tag stehen jetzt 2. War das Absicht?" -- und das
Zuruecknehmen liegt ohnehin daneben. Mit Gegenprobe, dass beim ERSTEN
keine Warnung kommt; sonst waere sie keine Warnung, sondern ein
Begleittext.
AUSSERDEM
* Die Zeilen bauen sich beim Eintragen nicht mehr neu, sondern
ziehen nur die Zahlen nach. Sonst verschwaende das Feld, in dem
man gerade tippt, unter der Hand.
* „Einfuegen" holt den Link aus der Zwischenablage -- mit drittem
Ausgang: Firefox gibt sie ohne Erweiterung nicht her, und dann
wird das gesagt, statt dass ein Knopf stumm bleibt.
* Im Dialog drei fertige Tage (Heute / Gestern / Vorgestern) statt
eines Kalenders. Was nicht mehr in diesen Monat gehoert, wird gar
nicht erst angeboten -- am 1. und 2. fallen welche weg.
* Der Dialog heisst jetzt „Mehr Angaben" und ist die Ausnahme fuer
Notiz oder altes Datum. Dass er fuer etwas Normales gebraucht
wurde, war sein Fehler.
GEPRUEFT: 194 Pruefungen, 0 Fehler (vorher 168)
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
f6d2437985 |
Manager-Ziele zu Ende gebaut -- und dabei zwei Loecher gefunden
Filipe: „perfektioniere alles jetzt sofort, es muss ready sein."
Die Vorlage Punkt fuer Punkt gegen das Gebaute gehalten, nicht gegen
meine eigene Liste von heute Mittag. Vier Punkte standen noch offen,
und auf dem Weg dorthin sind zwei Fehler aufgefallen, nach denen
niemand gesucht hat.
DIE ZWEI FEHLER ZUERST -- beide gefunden durch Messen, nicht Denken
1. EINE GELOESCHTE PERSON HAETTE IHRE ZAHLEN MITGENOMMEN.
`mz_eintrag.person_id` stand auf ON DELETE CASCADE. Die Vorlage
sagt aber: „Wer die Rolle verliert, sieht die Kachel nicht mehr;
die Daten bleiben fuer den DogFather erhalten." Mit CASCADE waere
genau das nicht wahr gewesen -- `DELETE FROM personen` haette den
Monatsverlauf eines Menschen lautlos mitgenommen.
Jetzt SET NULL, und Name und Rolle stehen zusaetzlich als Text am
Eintrag (dieselbe Bauweise wie bei support_meldungen). Die Rolle
ist nicht Zierde: Ohne sie wuerde ein abgeschlossener Monat
rueckwirkend an den Zielzahlen einer anderen Rolle gemessen.
Der Umbau laeuft auf dem Bestand von heute Mittag -- Spaltenliste
AUS PRAGMA abgeleitet, nicht gepflegt, und geprueft werden Zeilen
UND Spalten. Am 11.09.2026 hat genau so ein Umbau drei Spalten mit
Inhalt verloren, ohne Fehlermeldung, bei unveraenderter Zeilenzahl.
2. MEIN EIGENER SPERR-TRIGGER HAETTE DAS LOESCHEN BLOCKIERT.
ON DELETE SET NULL ist kein Loeschen, sondern ein UPDATE auf
person_id. Der Trigger sah eine Aenderung an einem abgeschlossenen
Monat und brach ab -- `DELETE FROM personen` waere damit
gescheitert, an einer Stelle, die mit Monatszielen nichts zu tun
hat. Erlaubt ist jetzt genau eine Aenderung an einem alten Monat:
dem Eintrag seinen Besitzer zu nehmen. Als BEDINGUNG und nicht als
`UPDATE OF <spaltenliste>` -- eine Liste muesste jemand pflegen.
Weil `CREATE TRIGGER IF NOT EXISTS` eine geaenderte Fassung nicht
erneuert, wird die alte am INHALT erkannt und ersetzt. Eine
Fassungsnummer muesste jemand hochzaehlen, und das wird vergessen.
DIE VIER OFFENEN PUNKTE DER VORLAGE
04 Jede Aufgabenzeile hat ihr eigenes Zeichen -- aus dem Haus
(`window.Bereiche`), nicht neu gezeichnet: Trichter, Bildschirm,
Buch, Rahmen. Das Statuszeichen bleibt daneben; ein eingefaerbtes
Aufgabenzeichen allein traegt die Stufe nicht.
05 „Farbiger Rand + Badge": Eine Kachel, an der eine Warnung haengt,
traegt jetzt einen feinen Saum -- JEDE Kachel, nicht nur diese.
Eine Regel, die nur an einer Stelle gilt, wird beim naechsten Mal
vergessen.
08 Die Team-Tabelle ist sortierbar: jede Spalte ein Knopf (kein
anklickbares <th> -- das erreicht die Tastatur nicht), mit
aria-sort, und sortiert wird nach ANTEIL statt nach nackter Zahl.
Dazu eine Ampel-Spalte mit Wort. Auf dem Handy verschwindet die
Kopfzeile im Kartenmodus, deshalb steht das Sortieren zusaetzlich
in der Leiste -- sonst waere es auf einem Telefon nicht
vorhanden.
09 Wer die Rolle verliert, steht weiter in der Uebersicht, als
„nicht mehr dabei" und mit der Rolle von damals. Wer geloescht
wurde, erscheint als zusammengefasste Zeile unter dem
mitgeschriebenen Namen.
WAS DER SAUM MICH GELEHRT HAT
Er stand zuerst in start.css und war wirkungslos -- der Browser
lieferte weiter den Faseschatten. Der Grund steht seit dem 25.09.2026
in module.css: `:is()` uebernimmt die Spezifitaet seines staerksten
Arguments, und `.gruppe[data-gruppe]` macht die ganze Modulliste
(0,2,0) -- genau so stark wie `.kachel[data-warn="ja"]`, bei
Gleichstand gewinnt die zuletzt geladene Datei. Dieselbe Falle wie
damals bei den Fokusringen, dieselbe Antwort: Was gegen die Modulform
gewinnen muss, gehoert in die Datei mit der Modulform. Gemerkt habe
ich es nur, weil die Bildmessung den errechneten Schatten AUSGIBT
statt ein Bild zu machen.
Beim Herausschneiden blieb eine Klammer zu viel in start.css stehen --
gefunden von pruef-css-klassen („eine schliessende Klammer ohne
oeffnende"), bevor sie still CSS verschluckt hat.
AUSSERDEM BEHOBEN
* Spicy Media sah an einer FREMDEN Liste „Bearbeiten" und „Loeschen",
und der Server antwortete mit 403. Ein Knopf, der nichts tut, ist
schlimmer als kein Knopf.
* Klick auf eine Person klappt jetzt alle vier Zeilen auf. Die
Vorlage verspricht „zeigt deren Eintraege" -- zugeklappt zeigte
der Klick nur Zahlen.
* Der CSV-Export kennt drei Staende statt zwei: „pflichtig", „neu,
noch ohne Pflicht", „nicht mehr dabei". Vorher hiess beides „nein".
* Das Aufklappen baute die ganze Liste neu und riss den
angeklickten Knopf weg (Fokus sprang nach oben).
GEPRUEFT: 168 Pruefungen, 0 Fehler (vorher 141)
Neu darunter: der Umbau auf einem echten Alt-Bestand (Zeilen, Spalten,
Inhalt, Indizes, Trigger, und ein zweiter Lauf, der nichts mehr tut),
das Loeschen einer Person mit Eintraegen aus einem abgeschlossenen
Monat -- mit Gegenprobe, dass dieselbe Sperre den INHALT weiterhin
nicht aendern laesst.
Zwei meiner neuen Pruefungen haben zuerst sich selbst gemessen statt
den Code: Eine verglich gegen einen Eintrag, den sie vorher geloescht
hatte (404 sah aus wie ein haltender Riegel), die andere meldete eine
fehlende Spalte, die nur ihr eigener Handeinsatz verursacht hatte.
Beide berichtigt.
Am Bildschirm nachgemessen bei 412 px und 1280 px: kein waagerechtes
Schieben, kein eigenes Beruehrziel unter 40 px, genau EINE Kachel mit
Saum und zwanzig ohne.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
db656f6e14 |
Manager-Ziele: vier feste Monatsaufgaben, die sich selbst zuruecksetzen
Filipe mit der Vorlage „Prompt · Kachel Agentur-Aufgaben" (02.10.2026):
Scouts, Manager, DogFather und Spicy Media bekommen vier Pflichten je
Monat -- Creator rekrutieren, Manager-Meeting, Schulung oder Community
Talk, Werbung auf TikTok -- mit Fortschritt, Ampel, Warnungen und
einem Monatsschnitt, der nichts loescht.
DREI ENTSCHEIDUNGEN, DIE VON DER VORLAGE ABWEICHEN -- alle abgestimmt:
1. DIE KACHEL HEISST „Manager-Ziele", nicht „Agentur-Aufgaben".
Es gibt bereits eine Kachel „Agentur" und eine „Aufgaben". Eine
dritte mit beiden Woertern im Namen waere auf einem Handy nicht
mehr auseinanderzuhalten.
2. DIE ZIELZAHLEN GELTEN JE ROLLE, und DogFather UND Spicy Media
duerfen sie aendern. Ein Scout muss nicht dieselbe Zahl schaffen
wie die Leitung.
3. DIE SCOUT-PIPELINE IST ANGEBUNDEN, in beide Richtungen: Vorschlaege
aus uebergebenen Leads, Namensvorschlaege beim Tippen, die
Verbindung bleibt am Eintrag gespeichert. Aber NICHTS zaehlt von
selbst -- gezaehlt wird nur, was ein Mensch bestaetigt hat. Ein
Zaehler, der sich allein fuellt, ist einer, dem niemand glaubt.
WAS ANDERS GEBAUT IST, ALS ES NAHELAG
DAS ZIEL WIRD PRO MONAT EINGEFROREN (`mz_ziel` hat den Monat im
Schluessel). Laege nur ein aktueller Wert in `einstellungen`, schriebe
jede spaetere Aenderung rueckwirkend den ganzen Verlauf um: Ein Monat,
der mit 2/2 abgeschlossen war, staende nach einer Erhoehung auf 4
ploetzlich als „nicht erreicht" da. Ein Verlauf, der sich rueckwirkend
aendert, ist keiner. Es gibt deshalb gar keinen Weg, den laufenden
Monat umzuschreiben -- gespeichert wird immer in den naechsten.
DIE SPERRE VERGANGENER MONATE SITZT IN DER DATENBANK, nicht im Code
(drei Trigger). Die Ausnahme fuer DogFather laesst sich in SQLite
nicht ueber die Sitzung abfragen, also ist sie ein sichtbarer Vorgang:
`mz_freigabe` wird fuer die eine Handlung geoeffnet, im `finally`
wieder geschlossen und verfaellt nach zwei Minuten von selbst. Jede
Korrektur steht mit Name und Zeit im Protokoll.
DER LAUFENDE MONAT STEHT IN EINER TABELLE (`mz_lage`), nicht in
`strftime(...,'localtime')`. Sonst entschiede die Zeitzone des Servers,
und am Monatsersten zwischen 00:00 und 02:00 griffe die Sperre fuer
den falschen Monat. Gerechnet wird durchgehend in Europe/Berlin
(identisch mit dem Europe/Luxembourg der Vorlage, aber dieselbe
Zeitrechnung wie der Rest des Hauses).
KEIN ZWEITER ZAEHLER FUER DIE KACHELWAND. Rand und Abzeichen auf der
Startseite kommen aus `workspace-hinweise.js` und damit aus derselben
Rechnung wie die Seite (`standFuer`). Zwei Rechnungen ueber dieselbe
Sache laufen auseinander, und zwar lautlos.
KEIN IMPORTKREIS ZU workspace-push.js. Die Erinnerungen entstehen hier
als Liste (`zielRufe`), verschickt werden sie im vorhandenen
Fuenf-Minuten-Takt. Der Tag steht im Merkmal -- dadurch geht pro
Person hoechstens EINE Meldung am Tag heraus, obwohl der Lauf
288-mal stattfindet.
GETRENNTE HAEUSER: Auf crew.dogfather-universe.com gibt es diese
Kachel nicht, auch nicht fuer DogFather. Gemessen, nicht angenommen.
GEPRUEFT (141 Pruefungen, 0 Fehler) -- mit Gegenproben zu jeder Sperre
* Vier Rollen kommen herein, drei bekommen 404 (nicht 403), und die
ANZAHL steht in der Bedingung. „Alle abgewiesen" waere auf einer
leeren Liste wahr.
* Die Ampel wird mit EINGESETZTEN Tagen gemessen, nie gegen die
Wanduhr -- diese Pruefung sagt am 16. November dasselbe wie heute.
(gate-oeffnung.mjs im Shop war gruen, bis der Kalender sie
ueberholte.)
* Die Datenbank lehnt einen Eintrag im Vormonat selbst ab; danach
wird nachgewiesen, dass die Freigabe nur EINMAL gewirkt hat.
* Neun Absagen mit dem jeweils richtigen Grund -- und eine
Instagram-Adresse, die durchgehen MUSS, weil sonst nur bewiesen
waere, dass die Pruefung streng ist, nicht dass sie richtig ist.
* Am 7. des Monats ist Ruhe: Ohne diese Zeile bewiese der
Erinnerungs-Block nur, dass immer etwas kommt.
ZWEI BEFUNDE KAMEN AUS DER MESSUNG, NICHT AUS DEM NACHDENKEN
* Beim Aufklappen einer Zeile wurde die ganze Liste neu gebaut --
der angeklickte Knopf existierte danach nicht mehr, der Fokus
sprang an den Seitenanfang. Gefunden hat es die Bildmessung, der
die Schaltflaeche unter der Hand wegbrach.
* Zwei meiner Messungen waren falsch, nicht der Code: Der
Haus-Test schickte den Keks nicht mit (401 statt 404), und
`Response.text()` entfernt ein BOM beim Dekodieren -- der Export
hatte eines, die Pruefung sah es nur nicht. Jetzt wird in Bytes
gemessen.
Kachelton 47 (#7368ff) ist mit tools/kachel-farbe-einzeln.mjs gegen
alle 46 vorhandenen gerechnet, nicht ausgesucht: Abstand 0,0899,
Kontrast 4,61:1. Beruehrziele, waagerechtes Schieben und
Schriftgroessen sind am Bildschirm bei 412 px und 1280 px nachgemessen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
731537b682 |
Eine Wahrheit statt zwei: Der Status der Aufgabe gilt
VanVan im Support (Runde 1, „Ging noch nicht"): „Das dort steht ich
bewerbe mich ist jetzt weg, aber dafür hat er noch mal 2 Buttons
hinzugefügt mit ich fange an und fertig. Wenn man auf ich fange an
drückt steht dort in Bearbeitung und wenn man auf fertig drückt dann
wird es zu erledigt. Die Aufgabe bleibt aber im status offen stehen.
Die beiden Buttons können entfernt werden, weil es darüber ja den
button starten gibt, der auch korrekt funktioniert."
SIE HAT ETWAS GROESSERES GEFUNDEN ALS ZWEI UEBERFLUESSIGE KNOEPFE.
Es gab ZWEI Zustaende nebeneinander, und sie kannten sich nicht:
aufgaben.status offen · arbeit · review · erledigt
aufgaben_zuteilung.zustand angenommen · arbeit · erledigt
Die zwei Knoepfe setzten den zweiten (`/mein-stand`), der
Starten-Knopf den ersten. Auf der Karte stand „in Bearbeitung", in der
Liste „offen" -- und beides stimmte. Das ist schlimmer als ein Fehler:
Es gibt nichts, dem man glauben kann. Zwei Antworten auf dieselbe
Frage sind in diesem Haus verboten, und genau das war es.
WAS ICH BEINAHE FALSCH GEMACHT HAETTE
Ihr Wunsch war „entfernt die Knoepfe". Bevor ich das tue, habe ich
gemessen, was danach bliebe -- am Bildschirm einer Modi mit einer
angenommenen Aufgabe:
Karten-Knoepfe: []
Schritt-Knoepfe: []
KEIN EINZIGER. Die Modi sieht den Starten-Knopf NICHT, weil
`darfAendern` fuer sie falsch ist: Sie ist weder Leitung noch
`creator_id`, `verantwortlich_id` oder `erstellt_von` -- die Zuteilung
laeuft ueber eine eigene Tabelle. VanVan ist Leitung und sieht ihn;
deshalb klang „den gibt es doch" selbstverstaendlich.
Haette ich die Knoepfe einfach geloescht, haette ich der Modi die
einzige Handlung weggenommen, die sie hatte -- eine Meldung „behoben",
nach der weniger geht als vorher.
ALSO WIRD IHR SATZ WAHR GEMACHT
1. Wer eine Aufgabe WIRKLICH hat (angenommen/arbeit/erledigt), darf
ihren STATUS setzen. Damit sieht die Modi denselben Knopf wie alle
-- gemessen: „Schritt-Knoepfe: [starten ▶]".
ENG GEFASST: nur der Status, nur allein in der Anfrage. Die
Pruefung ist `Object.keys(...).length === 1` und nicht „enthaelt
status" -- sonst waere die schmale Tuer die breite mit einem
Zusatzfeld.
2. Der Statuswechsel zieht die Zuteilung MIT. Ohne das waere das
Entfernen eine stille Verschlechterung gewesen: Die Zaehler einer
Person („offen / in Arbeit / erledigt") lesen die ZUTEILUNG, nicht
die Aufgabe. Jede Zuteilung waere fuer immer auf „angenommen"
stehen geblieben, und die Zahlen haetten aufgehoert, die
Wirklichkeit zu zeigen -- ohne dass irgendwo etwas rot wird.
ABGELEITET, NICHT ZWEIMAL GESCHRIEBEN: `STATUS_ALS_ZUSTAND` gibt
es seit dem 22.09. Benutzt wird genau sie, mit EINER Abweichung,
und die steht daneben: Wer zugesagt hat, faellt beim Zurueckdrehen
auf „angenommen", nicht auf „offen". Eine Zusage verschwindet
nicht, weil jemand den Status zurueckstellt.
3. Die zwei Knoepfe sind weg. Der Weg `/mein-stand` bleibt -- er ist
die Schranke fuer den, der die Schnittstelle direkt anspricht.
GEGENPROBEN ZUM ERWEITERTEN RECHT (ein Recht ohne Gegenprobe ist ein
Loch mit Begruendung):
Anna hat eine Aufgabe, die ihr NUR zugeteilt ist
(darf_aendern false, darf_status true)
sie setzt den Status ihrer Aufgabe (200)
mit einem zweiten Feld kommt sie nicht durch (403)
und umschreiben darf sie gar nicht (403)
der Titel steht unveraendert da („Clips schneiden")
und wer sie nicht hat, setzt auch keinen Status (404)
zurueckgedreht steht Anna wieder auf „angenommen"
eine Bewerbung bleibt eine Bewerbung (abgelehnt -> abgelehnt)
ZWEI EIGENE FEHLER, BEIDE VON DER MESSUNG GEFUNDEN:
· Mein erster Zeuge war Bea und die Pool-Aufgabe. Die Gegenprobe
wurde rot: Bea darf sie ohnehin umschreiben, weil das Uebernehmen
aus dem Pool sie verantwortlich macht. An ihr laesst sich ueber die
neue, schmale Tuer gar nichts zeigen. Der reine Fall wird jetzt
GESUCHT (darf_aendern falsch, Zuteilung angenommen) statt
hingeschrieben -- eine feste Nummer waere die naechste, die beim
naechsten Umbau nicht mehr stimmt.
· Mein Abschnitt stellte Annas Aufgabe auf „arbeit" und liess sie so
stehen; ein spaeterer zaehlte ihre „angenommen" und wurde dadurch
rot. Eine Pruefung, die den Bestand fuer die naechste veraendert,
misst ab da etwas anderes als sie glaubt. Jetzt raeumt sie auf --
und die Rueckfahrt ist selbst eine Messung.
ZWEI PRUEFUNGEN MUSSTEN MITZIEHEN, und das ist richtig so: Beide
verlangten „Ich fange an" -- geschrieben von mir am 30.09. fuer
VanVans ERSTE Meldung. Ihre Absicht bleibt woertlich dieselbe („kann
sie wirklich etwas tun?"), nur ist der Griff jetzt der Statusknopf.
`knoepfeAn` sieht dafuer auch neben den Zuteilungsblock: „kann sie
etwas tun?" laesst sich am Block allein nicht beantworten.
GEPRUEFT: pruef-zuteilung 75 -> 90 ok · pruef-bewerbung-aufgaben
162 -> 164 ok · pruef-struktur 99 · pruef-resuemee 35 ·
pruef-aufgabenbrett 49 · pruef-rechtetafel 19 ·
pruef-aufgaben-vorlagen 46.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
4c08c8859d |
Beim Antworten im Support darf jetzt ein Bild mit
VanVan (Support): „Wenn man hier im Support auf deine Frage 'geht es
wieder' reagiert und antwortet, kann man auch kein Bild hinzufügen. Das
müsstest du auch noch hinzufügen, damit man nochmal ein Bild anhängen
kann, wenn das Problem noch besteht oder sich durch die Änderung ein
neues Problem ergeben hat."
Ihr zweiter Halbsatz ist der eigentliche Grund, und ich waere nicht
darauf gekommen: Das Bild beim MELDEN zeigt das ERSTE Problem. Taucht
durch die Aenderung ein neues auf, hilft das alte Bild niemandem.
WO ES LIEGT: AN DER RUNDE, NICHT AN DER MELDUNG
Die Meldung hat schon ein Bild -- das vom ersten Mal. Wuerde es hier
ueberschrieben, waere nach Runde drei nicht mehr zu sehen, womit es
angefangen hat. Genau diese Frage loest einen wiederkehrenden Fehler,
und genau deshalb gibt es die Rundentabelle ueberhaupt (ihre eigene
Begruendung steht seit dem 25.09. darueber).
DERSELBE WEG WIE BEIM MELDEN, NICHT EIN ZWEITER
Text und Urteil reisen im Kopf (`x-text`, `x-geht`), das Bild im
Rumpf, eine Route fuer beides. Die Begruendung stand schon beim
Melden und gilt hier genauso: Zwei Routen haetten einen Zustand
dazwischen -- eine Antwort, die schon zaehlt, waehrend das Bild noch
laedt. Ein leerer Rumpf ist zulaessig; ein Bildschirmfoto ist Hilfe,
keine Huerde.
DIE SPALTEN MUESSEN NACHGETRAGEN WERDEN, und das ist die Stelle, an
der es sonst schiefgeht: Die Tabelle entsteht mit `CREATE TABLE IF NOT
EXISTS`. Auf einer Datenbank, die es schon gibt -- also auf dem Server
-- sieht das den Namen, findet ihn, und ist fertig. Die vier neuen
Spalten kaemen dort NIE an: lokal alles gruen (jede Pruefung legt ihre
Datenbank frisch an), live ein Schreibfehler. Zwanzig Zeilen weiter
oben steht derselbe Fall schon einmal, damals mit einem Index.
Deshalb ein ALTER-Nachtrag, der die Tabelle SELBST fragt
(`PRAGMA table_info`) statt einer gepflegten Liste.
DATENBANK VORHER GESICHERT (Hausregel bei Schemaaenderungen):
`sicherungen/vor-support-rundenbild-20261002-142949.db`, geprueft mit
`integrity_check: ok`, 20 Personen, 16 Runden.
DER DIALOG KANN JETZT EIN BILD -- UND ZWAR NUR, WENN MAN IHN FRAGT
Das Feld ist eine Option von `frageNach` und standardmaessig AUS.
Ohne diese Vorgabe bekaemen die 56 anderen Rueckfragen im Haus ein
Bildfeld, nach dem niemand gefragt hat.
Es steht dort und nicht in support.js, weil Grund und Bild in
DENSELBEN Kasten gehoeren: Zwei Dialoge nacheinander hiessen, dass
jemand beim zweiten abbricht und den ersten umsonst getippt hat --
dieselbe Begruendung, aus der die Anzahl-Zeile dort gelandet ist.
Mit Vorschau. Wer sieht, was er anhaengt, haengt seltener das falsche
Bild an.
IM NOTAUSGANG GIBT ES KEINS, und das wird gesagt statt verschwiegen:
`window.prompt` kann keine Datei. Wer einen Browser ohne `<dialog>`
hat, kann antworten -- nur eben ohne Anhang. `bild: null` sorgt dafuer,
dass die aufrufende Stelle nicht raten muss.
GEPRUEFT
pruef-support 48 -> 78. Fuenf vorhandene Aufrufe mussten auf den neuen
Weg mitgezogen werden -- haette ich das vergessen, haetten sie ab
heute nur noch ihre eigene Veraltung gemessen. Neu dazu:
die Antwort geht mit Bild durch (200)
im Verlauf haengt das Bild an Runde 1
und zwar an DIESER Runde, nicht oben an der Meldung
der Melder bekommt es wieder (200, 70 von 70 Bytes)
und ueber den gemeinsamen Ausliefer-Weg (Accept-Ranges)
die Leitung sieht es auch (200)
ein Fremder bekommt 404 — nicht 403, sonst waere die Nummer verraten
ohne Anmeldung gar nichts (401)
ohne Bild geht es genauso (200)
eine PDF wird abgelehnt (415)
pruef-nachfrage 53 -> 69, am echten Bildschirm, mit echten Dateien
ueber `DataTransfer`:
ohne Angabe bleibt die Bildzeile verborgen
der Knopf ist 44 px hoch (Fingermass)
nach der Wahl steht der Name da, Vorschau ist da
ein 300x900 grosses Bild wird auf 160 px gedeckelt
und der Senden-Knopf steht weiter im Fenster
Gegenprobe: Abbrechen gibt nichts zurueck, auch kein Bild
und beim naechsten Oeffnen ist es leer
ZWEI EIGENE FEHLER, BEIDE VON DER MESSUNG GEFUNDEN:
· Meine erste Fassung las die neue Meldung ueber `.id` statt
`.meldung.id` und meldete „#undefined". Die Pruefung hatte recht,
der Fehler war meiner.
· Die Obergrenze der Vorschau habe ich zuerst an einem 1x1-Bild
gemessen: „3 px, hoechstens 160" -- gruen und wertlos, ein ein
Pixel hohes Bild kann keine Grenze ueberschreiten. Jetzt entsteht
im Browser ein 300x900 grosses, und die Grenze wird wirklich
geprueft.
Dazu unveraendert gruen: pruef-aufbewahrung 45 · pruef-css-klassen 37 ·
pruef-struktur 99.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
58911d7c4f |
Auf dem Handy steht jetzt da, wer reagiert hat
VanVan (Support): „Wenn man auf dem Handy auf die Reaktionen unter einer
Nachricht geht, dann sieht man nicht wer darauf reagiert hat. Auf dem PC
funktioniert es."
DIE URSACHE STAND IM QUELLTEXT, mit Kommentar und allem:
b.title = `${r.wer.join(', ')} · ...`
Ein `title` erscheint beim UEBERFAHREN MIT DER MAUS. Auf einem Finger
gibt es kein Ueberfahren -- und das Antippen schaltet stattdessen die
eigene Reaktion um. Die Auskunft war also nicht versteckt, sondern an
ein Geraet gebunden, das die Haelfte des Teams nicht benutzt. „Auf dem
PC funktioniert es" war der entscheidende Satz ihrer Meldung.
GEAENDERT: Unter den Kacheln steht auf Fingergeraeten eine Zeile mit
den Namen -- je Zeichen, mit dem Zeichen davor:
👍 Patrick · ❤️ VanVan, Miss
WARUM EINE ZEILE UND KEIN LANGDRUECKEN. Ein langer Druck ist die
uebliche Antwort und die schlechteste: Man muss wissen, dass es ihn
gibt. Hier sind es Leute aus EINEM Raum, also kurze Listen -- sie
passen hin. Was dasteht, muss niemand finden.
WARUM NUR AUF DEM FINGER. Am Rechner funktioniert das Ueberfahren, und
eine Dauerzeile unter jeder zweiten Nachricht waere dort Unruhe ohne
Gewinn. Der `title` bleibt unveraendert.
ZWEI KLEINIGKEITEN, DIE KEINE SIND:
· `aria-hidden="true"` an der Zeile. Jede Kachel traegt ihre Namen
schon im `aria-label`; ohne das hoerte ein Vorleseprogramm alles
doppelt.
· Die Farbe ist die der Blase (`--blase-leise`), nicht eine feste.
Derselbe Grund wie bei der Sprachnachricht: Jede Blase traegt die
Farbe ihres Absenders, und eine feste Schrift ergaebe auf Babyblau
wieder 1,91:1.
GEPRUEFT AUF BEIDEN GERAETEN, sonst beweist es nichts (pruef-chat-optik,
62 -> 71). Am Handy MUSS die Zeile da sein, am Rechner MUSS sie fehlen
und der Titel die Namen tragen. Ohne die zweite Haelfte waere eine
Regel, die immer gilt, genauso gruen -- und haette am Rechner eine
Zeile angehaengt, die niemand bestellt hat.
auf dem Handy steht die Zeile da (true)
und sie nennt den Namen: „👍 Patrick"
und ein Vorleseprogramm hoert sie nicht doppelt (aria-hidden)
am Rechner bleibt sie weg — dort funktioniert das Überfahren
und die Namen stehen wie bisher im Titel
Gemessen wird mit einem FREMDEN Namen (DogFather schreibt, Patrick
reagiert). Mit der eigenen Reaktion staende „Du" da, und die Pruefung
haette den Fall nicht gemessen, um den es geht.
GEPRUEFT: pruef-chat-optik 71 ok · pruef-chat 63 ok ·
pruef-chat-aufloesen 126 ok.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
b808171704 |
Der Kamerahinweis wird wieder sichtbar -- und eine eigene Regression weg
ICH HATTE ES GESTERN FALSCH BEHAUPTET UND HEUTE SELBST VERSCHLIMMERT.
Beides steht hier, weil beides zum Befund gehoert.
WAS ICH GESAGT HATTE: „Auf 390 px ist der Hinweis 0 px hoch und
deshalb nicht zu lesen -- wo er hingehoert, ist eine Gestaltungsfrage
und gehoert Filipe."
Der zweite Halbsatz war eine Ausrede. Im Quelltext stand die ganze
Zeit eine 6-Sekunden-Uhr (reaktion.js, `sagFehler`), die ihn wieder
ausblendet. Statt das nachzusehen, habe ich aus zwei Messungen zu
verschiedenen Zeitpunkten einen Widerspruch gebaut (62 px hier, 0 px
dort) und ihn fuer eine Eigenschaft der Breite gehalten.
ALSO ABGETASTET STATT HERGELEITET (390x844, nach dem Laden):
nach 500 ms Text 104 Zeichen · hidden=nein · 0 px
nach 5000 ms Text 104 Zeichen · hidden=nein · 0 px
nach 7000 ms Text 104 Zeichen · hidden=ja · 0 px
Die Uhr stimmt also -- und trotzdem ist er die ganzen sechs Sekunden
NULL PIXEL hoch. Ein `role="alert"`, den niemand sehen kann. Das war
auf 390 px schon vorher so.
UND AUF 320 PIXELN HABE ICH ES HEUTE SELBST KAPUTTGEMACHT. Vorher
bekam `#fehler` dort eine stillschweigende fuenfte Rasterzeile mit
71 Pixeln -- sichtbar, aber auf Kosten des Bildes (56 statt 127).
Seit die Regie aus dem Fluss ist, bleibt fuer diese Zeile nichts
uebrig: Der Hinweis kostete nichts mehr und war dafuer unsichtbar.
Von „sichtbar und zu teuer" auf „gratis und wirkungslos" ist keine
Verbesserung.
DIE URSACHE, und sie steht seit dem 30.09. im Haus beschrieben:
`#fehler` ist ein Kind des Saals ohne Platzangabe. Der Saal hat vier
Zeilen; das Feld landet in einer fuenften, die es nicht gibt.
ERSTER REPARATURVERSUCH, GEMESSEN UND ZURUECKGENOMMEN: `grid-row: 2`
ohne `position: absolute`. Damit belegte das Feld die Zelle, der Raum
wich in eine stillschweigende zweite SPALTE aus, und das BILD fiel auf
0 px (320) bzw. 2 px (360). Bei `.raum` steht der gleiche Satz fuer
eine zweite ZEILE -- derselbe Fehler, andere Achse. Ich habe den
Kommentar gelesen, nachdem die Messung ihn mir bestaetigt hatte, nicht
davor.
SO GEHT ES: dasselbe Muster wie beim Pult. `position: absolute` nimmt
das Feld aus dem Fluss -- es belegt keine Zelle und verdraengt nichts.
`grid-row: 2` sagt dann nur noch, WORIN es liegt, `align-self: end`
setzt es an die Unterkante. Keine gerechnete Zahl.
GEMESSEN DANACH:
320x568 Hinweis 62 px · im Fenster · obenauf · Bild 180 -> 180
390x844 Hinweis 42 px · im Fenster · obenauf · Bild 219 -> 219
430x932 · Bild 242 -> 242
Sichtbar, wenn er kommt. Nach sechs Sekunden wieder weg. Und er
kostet dem Bild kein Pixel mehr.
DIE PRUEFUNG STELLT DEN ZUSTAND SELBST HER (pruef-reaktion-schmal,
38 -> 44). Im Betrieb erscheint der Hinweis, wenn Kamera oder Mikrofon
fehlen -- auf einem Messrechner immer, auf einem Handy mit Freigabe
nie. Eine Pruefung, die darauf wartet, prueft die Messumgebung. Sie
schreibt den Text jetzt selbst hinein, macht ihn sichtbar, misst Hoehe
UND Bildhoehe, und raeumt wieder auf.
GEPRUEFT: pruef-reaktion-schmal 44 ok · pruef-reaktion 421 ok ·
pruef-css-klassen 37 ok · pruef-community-sicht 10 ok ·
pruef-breiten 23 ok.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
4a0ddf7d49 |
Die Regie wird auch auf dem kleinen Handy zur Schublade
Filipe: „auf so apps wie youtube und so geht es doch auch auf dem handy
also perfektionier es endlich."
Er hat recht gehabt, und meine Begruendung von 2026-09 war ueberholt.
WAS AUF 320x568 WIRKLICH PASSIERTE (Regie offen, laufende Sendung):
Bild 0 px · Pult 1324 px IM RASTER · Transportleiste endet bei
1567 von 568 Pixeln Fenster
Die Regie stand im Fluss statt darueber und schob alles hinaus. Ab
360 px war genau das laengst geloest -- es war dieselbe Seite, nur
schmaler. In reaktion.css stand dazu eine Sperre `and (min-width:
360px)` mit der Begruendung, der Kopf der Regie brauche 210 Pixel und
es seien nur 190 da. Fuenf Versuche hatten das nicht geloest.
DIE RECHNUNG STIMMTE NICHT MEHR. Seit 2026-09 gibt es einen Block
`@media (pointer: coarse)` ohne Breitengrenze, der den Kopf strafft.
Nachgemessen am 02.10.: 197 px, nicht 210 -- und mit einer weiteren
Straffung 147. Der Platz, der damals fehlte, war inzwischen da. Wer
der alten Begruendung geglaubt haette, haette nie nachgesehen.
VIER VARIANTEN DURCHGEMESSEN STATT DIE SECHSTE ZU RATEN
(320x568, Regie offen):
heute Bild 0 · Kopf 197 · Schublade 1324
nur Sperre weg Bild 180 · Kopf 197 · Schublade 234 · Inhalt 36
+ Knoepfe enger Bild 180 · Kopf 147 · Schublade 234 · Inhalt 86
+ 86 % statt 72 Bild 180 · Kopf 147 · Schublade 280 · Inhalt 132
Die dritte Variante (Messwerte einzeilig) brachte gegenueber der
zweiten NULL und ist deshalb nicht eingebaut -- die bestehende
coarse-Regel erledigt das schon. Eine Regel, die nichts aendert, ist
eine, die beim naechsten Mal jemand sucht.
GEAENDERT
1. Die beiden Sperren `and (min-width: 360px)` sind weg. Die Regie
liegt jetzt auf JEDEM Fingergeraet ueber dem Bild statt im
Raster, rollt in sich und hat einen stehenden Kopf.
2. Neuer Block fuer unter 360 px: die drei grossen Knoepfe in EINE
Zeile (`nowrap`, weniger Polsterung) und die Schublade darf
86 statt 72 Prozent hoch werden.
DIE 44 PIXEL HOEHE BLEIBEN -- das ist die Daumengrenze des
Hauses. Nur die Breite gibt nach, und nachgemessen wird KEIN
Knopf abgeschnitten (`scrollWidth <= clientWidth`).
Die 86 statt 100 Prozent sind derselbe Gedanke wie die
urspruenglichen 72: Oben bleibt ein Streifen Bild stehen, weil
man sehen muss, worueber man gerade redet.
NACH DEM UMBAU GEMESSEN:
320x568 Bild 180 px (war 0) · Kopf 147 (war 197)
Schublade 280 · sichtbarer Inhalt 132 · Rest rollt 994 px
Transportleiste endet bei 568 von 568
360x640 Bild 203 px unveraendert
390x844 Bild 219 px unveraendert
Zu UND auf ist das Bild auf 320 px jetzt gleich hoch -- das Oeffnen
der Regie kostet es nichts mehr.
EIN NEBENBEFUND HAT SICH MITERLEDIGT. Der Hinweis „Kamera oder
Mikrofon sind nicht freigegeben" sass in einer impliziten FUENFTEN
Rasterzeile (der Saal deklariert vier) und kostete das Bild 71 Pixel
(56 statt 127). Weil das Pult nicht mehr im Fluss steht, gibt es
diese Zeile nicht mehr: gemessen kostet der Hinweis jetzt 0 px
(325 -> 325).
WAS ICH DABEI FALSCH GEMACHT UND ZURUECKGENOMMEN HABE: Ich wollte
den Hinweis zusaetzlich mit `grid-row: 2` festnageln. Gemessen fiel
das Bild daraufhin auf 0 px (320) und 2 px (360) -- die explizite
Platzierung verdraengte die automatische des Bildes. Sofort wieder
entfernt. Die Messung hat es gefunden, nicht das Nachdenken; ohne
den Lauf davor haette ich eine Verschlechterung ausgeliefert.
DIE PRUEFUNG WURDE SCHAERFER, NICHT GRUENER (pruef-reaktion-schmal,
24 -> 38). Bis heute protokollierte sie den Mangel unter 360 px nur,
statt ihn zu behaupten -- richtig, solange es keine Reparatur gab,
falsch in dem Moment, in dem es eine gibt. Jetzt gilt auf JEDER
Breite: Bild behaelt seine Hoehe (zu und auf), Transportleiste bleibt
im Fenster, Inhalt der Schublade erreichbar, drei Knoepfe mit 44 px
unbeschnitten und obenauf, Zu-Knopf in jedem Zustand erreichbar.
Die Konstante `AUS_DEM_FLUSS_AB = 360` ist geloescht -- eine
Konstante, die nichts mehr trennt, ist der Anfang einer Erklaerung,
die nicht stimmt.
GEPRUEFT: pruef-reaktion-schmal 38 ok · pruef-reaktion 421 ok ·
pruef-css-klassen 37 ok · pruef-community-sicht 10 ok ·
pruef-breiten 23 ok · pruef-fingermass 5 ok.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
4324547eb3 |
Teilanfragen: Sprachnachrichten kommen jetzt auch auf dem iPhone an
Filipe: „zeurst schaust du mal ob es im system liegt dass miss, die modi,
keine sprachnachrichten hoeren kann oder ob es an ihr liegt weil bei allen
anderen klappt nur bei ihr nicht"
ES LAG AM SYSTEM.
WAS GEMESSEN WURDE (nicht vermutet)
1. An ihrer Rolle liegt es nicht. Der Weg `/workspace/api/chat/anhang/:id`
fragt drei Dinge: gibt es die Nachricht, ist die Person im Raum, hat sie
das Gespraech weggeraeumt. Keine Rollenpruefung. Gegen eine Wegwerf-
Datenbank gemessen: `anmelden admin=200 modi=200`, Anhang als modi
HTTP 200, 40018 Bytes -- genau wie als admin.
2. Sie ist in allen drei Raeumen mit Sprachnachrichten, geloescht_bis = 0,
alle sechs Tondateien liegen auf der Platte. (Live-Datenbank, nur
gelesen, auf einer Kopie, Kopie danach geloescht.)
3. Sie ist die EINZIGE im Haus mit Safari. Aus dem Caddy-Protokoll, ueber
IP und Minute mit ihren Protokolleintraegen abgeglichen: iPhone,
iOS 18.7, Safari 26.6.1. Alle anderen Geraete der letzten zwei Wochen:
Android-Chrome 3900 Anfragen, Windows-Chrome/Edge/Firefox 2646.
Neun von zehn iPhone-IP-Praefixen sind ihre.
4. DER FEHLER: Der Anhang-Weg beantwortete eine Teilanfrage
(`Range: bytes=0-1`) mit einer vollen HTTP 200 -- ohne `Accept-Ranges`,
ohne `Content-Length`, als `chunked`. Zum Vergleich dieselbe Anfrage an
`express.static`: HTTP 206, `accept-ranges: bytes`,
`content-range: bytes 0-1/2480`.
Safari verlangt fuer <audio> und <video> zwingend Teilanfragen und
verweigert die Wiedergabe bei einer 200. Chrome und Firefox nehmen die
ganze Datei klaglos. Bilder brauchen das nicht -- deshalb sah sie Fotos
und hoerte nichts, und deshalb fiel es sieben Tage lang nur ihr auf.
WAS GEAENDERT IST
A) EIN GEMEINSAMER AUSLIEFERWEG (server/helfer-ausliefern.mjs)
Im Haus gaben ZEHN Stellen eine Datei mit `createReadStream(pfad)
.pipe(res)` hinaus: Chat-Anhang, Chat-GIF, Dateiablage (ansehen und
laden), Material (ansehen und laden), Steckbriefbild, Buehnenbild,
Supportbild, Wissens-PDF. Nur eine davon zu reparieren hiesse, eine
Liste zu fuehren, welche Stelle schon richtig ist -- und die naechste
neue macht es wieder falsch. Alle zehn gehen jetzt ueber
`liefereDatei(req, res, pfad)`: `Accept-Ranges`, `Content-Length`,
206 mit `Content-Range`, 416 mit `bytes */groesse`. Mehrere Bereiche in
einer Anfrage werden absichtlich nicht bedient (das darf ein Server);
die Antwort ist dann die GANZE Datei, nie eine falsche Teilmenge.
WAS ES AUSSER SAFARI BRINGT, gemessen: Eine MP4-Sprachnachricht meldete
in Chromium ohne Teilanfragen 0,23 s statt 1,96 s Laenge -- der Kopf
einer MP4 steht am Ende der Datei. Eine Ogg-Datei meldete „Infinity"
statt 2,02 s. Und ein PDF-Betrachter springt jetzt zu einer Seite, ohne
die ganze Datei zu holen.
B) AUFGENOMMEN WIRD AAC IN MP4 (workspace/assets/js/chat.js)
Die Reihenfolge der Behaelter beantwortete bisher die Frage „was kann
DIESES Geraet am liebsten". Richtig ist „was koennen die ANDEREN
abspielen" -- die hoeren es.
Gemessen mit echten Aufnahmen aus echten Browsern, danach in beiden
Engines abgespielt:
Chromium nimmt auf: webm/opus, mp4(AAC), mp4(Opus)
Firefox nimmt auf: webm/opus, ogg/opus -- MP4 gar nicht
Beide spielen alle vier Behaelter vollstaendig ab (2 s rein, 2 s raus)
ZWEI FALLEN, die die Messung gezeigt hat:
- Ein blankes `audio/mp4` ist nicht AAC: Chromium meldet darauf
`audio/mp4;codecs=opus` zurueck -- MP4 aussen, Opus innen, fuer Safari
genauso unbrauchbar wie WebM. Deshalb steht `audio/mp4;codecs=mp4a.40.2`
VOR dem blanken `audio/mp4`.
- Firefox kann kein MP4 aufnehmen und faellt sauber auf WebM/Opus
zurueck. Kein Rueckschritt -- das ist der heutige Stand.
Die Pruefung nimmt jetzt im echten Browser ueber den echten Knopf auf,
und der Server erkennt: audio/mp4, 45583 Bytes, 2734 ms.
BERICHTIGT: In zwei Kommentaren stand „Safari und das iPhone koennen
nur MP4". Das stimmt nicht. An Miss' eigener Aufnahme nachgemessen:
Behaelter WebM, Mux-Programm „WebKit", Tonspur A_OPUS. Safari NIMMT
WebM auf -- ob es WebM abspielt, ist eine andere Frage.
C) EIN AUSWEG STATT EINER VERTROESTUNG (chat.js, chat.css)
Vorher stand im Fehlerfall „Sprachnachricht laesst sich gerade nicht
laden". Das war fuer Miss die ganze Auskunft, und es stimmte nicht
einmal: Die Datei kam an, ihr Browser konnte den Behaelter nicht.
„Gerade" heisst „gleich nochmal versuchen" -- bei einem fremden
Behaelter hilft kein Versuch mehr.
Jetzt wird unterschieden (Fehlercode 4 = Format, alles andere = Laden)
und daneben steht ein Weg, der wirklich zum Ton fuehrt: Herunterladen,
44 px hoch, in der Farbe der Blase, mit eigenem Vorlesewort. Nur im
Fehlerfall -- ein Knopf an jeder Sprachnachricht waere Unordnung fuer
alle, damit einer Person geholfen ist.
WAS JETZT NACHGEZAEHLT WIRD
- pruef-chat-anhaenge: 119 -> 146 Pruefungen. Dreizehn davon messen
Teilanfragen am Foto (0-9, -8, 5-, ueber das Ende hinaus, 416, mehrere
Bereiche, unverstandener Kopf) und vergleichen jeden Abschnitt BYTEWEISE
mit der vollen Datei -- eine 206 mit den falschen Bytes waere schlimmer
als keine. Drei Gegenproben legen dieselbe Messlatte an erfundene
Antworten (die alte volle 200, falsche Gesamtgroesse, falsche Bytes) und
muessen durchfallen. Neun weitere pruefen die Sprachnachricht selbst und
den Ausweg.
- pruef-wissen-neu: +6. Der Weg zur PDF war der EINZIGE der zehn, den nie
eine Pruefung abgerufen hat -- genau der, bei dem eine Umstellung
unbemerkt danebengeht. Jetzt beide Spielarten (ansehen und laden).
- pruef-struktur: +6. Wer kuenftig wieder `createReadStream(...).pipe(res)`
schreibt, bekommt einen Befund. Mit Gegenproben in beide Richtungen; die
Probetexte sind zusammengesetzt, sonst meldet die Wache ihre eigene
Begruendung als Fund. Pruefdateien sind ausgenommen, weil sie an niemanden
ausliefern -- dort ist ein Weg ohne Teilanfragen die Gegenprobe.
(Beim ersten Lauf hat die Wache sofort meine eigene Messdatei gefunden.)
WAS NICHT NACHGESEHEN WERDEN KONNTE
Ob iOS-Safari WebM/Opus ueberhaupt abspielt. Playwrights WebKit startet auf
diesem Rechner nicht (`icuuc77.dll`, auch nach Neuinstallation), und ein
iPhone habe ich nicht. Der dritte Ausgang: konnte nicht nachsehen. Deshalb
sind A, B und C drei Sicherungen hintereinander statt einer Wette auf eine.
GEPRUEFT (alles einzeln, kein Gesamtlauf)
pruef-chat-anhaenge 146 ok pruef-material 159 ok
pruef-wissen-neu 33 ok pruef-spenden 172 ok
pruef-struktur 85 ok pruef-support 63 ok
pruef-video 74 ok pruef-steckbrief 65 ok
pruef-galerie 26 ok pruef-eintrag-bild 24 ok
pruef-chat 63 ok pruef-chat-optik 62 ok
pruef-haus-trennung 100 ok
Die beiden Haeuser bleiben getrennt (pruef-haus-trennung, 100 ok). Der
Ausliefer-Weg gehoert beiden gleichermassen und traegt nichts Haus-
spezifisches; die Aufnahme betrifft faktisch nur Team Dogi, weil nur dort
der Mikrofonknopf steht („also nur die modis rechte linke hand und
dogfather").
NICHT VON MIR, SCHON VORHER ROT: pruef-gifs meldet zwei Fehler („das GIF
steht danach wirklich im Verlauf", „die Tafel geht zu"). Gegen den
unveraenderten Stand von HEAD nachgemessen -- dieselben zwei Fehler, mit
denselben Zahlen. Ein eigener Befund, kein Nebenschaden dieser Arbeit.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
603319a145 |
Arbeitsschloss: zwei Sitzungen sehen sich jetzt
HEUTE ZWEIMAL NUR GUTGEGANGEN. Zwei Claude-Sitzungen arbeiteten
gleichzeitig in diesem Verzeichnis, ohne voneinander zu wissen.
Keine hat etwas falsch gemacht — sie konnten es nicht wissen.
* Beide haben `git add -A` benutzt. Haette die eine
unfestgeschriebene Arbeit der anderen im Baum gehabt, waere sie
mitcommittet worden — unter fremdem Namen, in einer fremden
Begruendung, und niemandem waere es aufgefallen. Nachgesehen:
diesmal war nichts dabei.
* Beide haben den Stempellauf gestartet. Der schreibt 45 Dateien
um. Wer dort eine offen hatte, bekam sie unter den Haenden weg
geaendert.
Dasselbe hat in RunOne am 03.09.2026 sieben Minuten Ausfall
gekostet. Dort gibt es seitdem `arbeitsschloss.sh`; diese Fassung
uebernimmt seine Lehren.
WAS ES IST UND WAS NICHT. Es ist kein Riegel — wer wirklich muss,
kommt vorbei. Es beantwortet die eine Frage, die heute niemand
beantworten konnte: „arbeitet hier gerade sonst jemand?"
Die teuren Fehler liegen bei einem Schloss alle in derselben
Richtung: Es blockiert zu viel und wird deshalb abgeschafft. Also:
* Es blockiert NICHT, wenn das Schloss DEINES ist. RunOnes erste
Fassung fragte „ist abgeschlossen" statt „haelt es jemand
anders" — damit haette, wer ordentlich abschliesst, nie mehr
ausliefern koennen. Dafuer gibt es `fremd`.
* Es VERFAELLT nach zwei Stunden, und dass da jemand war, steht
beim Uebernehmen dabei.
* Es blockiert NICHT, wenn es selbst unlesbar ist — dritter
Ausgang, kein Stillstand.
* Notausgang: SCHLOSS_ZWANG=ja git commit …
DAS PROBLEM, AN DEM RUNONE HAENGT, IST HIER GELOEST. Dort faellt die
Kennung im Zweifel auf den Systembenutzer zurueck, und zwei
Claudian-Sitzungen laufen BEIDE als `claudian` — die Sicherung griff
ausgerechnet zwischen den zwei Faellen nicht, fuer die sie gebaut
wurde. Deshalb ist dort `export ARBEITER=…` Pflicht, und Pflicht
heisst: man vergisst es.
Hier steht `CLAUDE_CODE_SESSION_ID` in jeder Sitzung und ist je
Sitzung verschieden (nachgesehen, 36 Zeichen UUID). Zwei Sitzungen
auf demselben Windows-Benutzer unterscheiden sich damit von selbst,
ohne dass jemand etwas tun muss. Reihenfolge: ARBEITER, dann
Sitzungskennung, dann Benutzername MIT Warnung.
NIEMAND MUSS DARAN DENKEN:
* die beiden Stempelwerkzeuge nehmen es selbst und geben es selbst
frei — auch nach einem Absturz und bei Strg+C (wie `bauen.sh` im
Shop; eines, an das man denken muss, wird vergessen und ab da
umgangen)
* `tools/git-haken/pre-commit` bricht jeden Commit ab, solange
jemand ANDERS das Schloss haelt. Das ist die Stelle, die heute
gefehlt hat: `git add -A` ist der Griff, den man ohne Nachdenken
macht, und gegen einen Reflex hilft keine Regel auf Papier.
* `core.hooksPath` statt `.git/hooks` — letzteres ist nicht
versioniert und waere nach einem Klon genau dann leer, wenn es
gebraucht wird.
GEPRUEFT, server/pruef-arbeitsschloss.mjs: 33 Pruefungen, 0 Fehler —
in einem WEGWERF-Verzeichnis mit eigenem git, damit kein echtes
Schloss angefasst wird. Darunter am echten git:
ohne Schloss committen -> geht (0)
mit dem EIGENEN Schloss -> geht (0)
mit einem FREMDEN Schloss -> bricht ab (1), nennt wer und warum
und es stehen genau ZWEI Commits da, nicht drei
SCHLOSS_ZWANG=ja -> kommt vorbei
ohne das Schloss-Werkzeug -> laesst durch
Dazu: verfallenes Schloss laesst durch, mit laengerer Frist blockt
dasselbe Schloss wieder (Gegenprobe), unlesbarer Inhalt und
unlesbarer Zeitstempel blockieren nicht.
Portnummern nach der neuen Pruefdatei nachgemessen: Pruefbereich bis
5415, 462 Nummern, 0 Kollisionen. pruef-struktur 75/0,
pruef-fingermass 5/0, pruef-ports 10/0.
In DEPLOY.md steht es jetzt an erster Stelle — eine Sicherung, von
der nur der weiss, der sie gebaut hat, ist die erste, die umgangen
wird.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
1afb38258c |
Anfuehrungszeichen: drei Loecher in meiner eigenen Wache
Die zweite Sitzung hat in den Praesentationen des Vaults 83 Stellen
gefunden — und damit auf Loecher in MEINER Wache gezeigt. Ich habe
sie nachgemessen, alle drei waren echt.
LOCH 1 — SIE SAH NUR `server/workspace-*.js`
Also ausgerechnet nicht `workspace.js`, die groesste Datei des
Hauses. Der weitere Filter fand dort sofort drei Stellen:
workspace.js:3404 Kanal „Chat-Moderation" (Protokoll)
workspace.js:3422 „${titel}" -> ${haus} (Protokoll)
workspace.js:3304 „${… || "ohne Titel"}" (siehe Loch 3)
Das ist heute der DRITTE Fall von „die Wache kennt nur die halbe
Menge" — nach pruef-struktur (sah nur die Pruefdateien, nicht die
Anwendung) und pruef-fingermass (sah keine variable Breite).
LOCH 2 — IHR AUSDRUCK GILT JE ZEILE
Ein `„`, das erst in der naechsten Zeile mit einem geraden `"`
schliesst, fiel durch. Gemessen: drei echte Faelle, zwei davon
sichtbarer Seitentext.
workspace/leistung.html „nicht / zugeordnet"
workspace/leistung.html „Backstage-Tabelle / einfuegen"
workspace/assets/js/ampel.js „noch ' + 'verbessern"
Beim letzten laeuft das Zitat ueber eine Zeichenketten-Verkettung.
Neue Regel ohne Fehlalarme: erst alle RICHTIG geschlossenen Paare
entfernen (auch mehrzeilig), dann die einzeilig falschen (die meldet
die alte Regel). Was danach noch ein `„` hat und binnen drei Zeilen
ein gerades `"`, ist ein Fund. Ausgenommen bleibt das Zeichen ALS
WERT — in `content: "„";` und in den Sprachtabellen ist das `„` der
Inhalt und das `"` die Begrenzung.
LOCH 3 — EINE AUSNAHME, DIE EINEN FUND VERSCHLUCKT HAT
Gefunden durch die ZAHL, nicht durch den Blick: Der weitere Filter
liess die Ausnahmen von 12 auf 13 steigen. Die dreizehnte war
`… „${zeile[titelSpalte] || "ohne Titel"}"`
Der Ausdruck blieb am `"` von `"ohne Titel"` haengen; als Inhalt kam
`${zeile[titelSpalte] || ` heraus, das endet auf ein Leerzeichen,
und damit galt „der Satz geht in der naechsten Zeile weiter". Das
echte Schlusszeichen stand hinter dem `}` und war gerade.
Dass die Ausnahmen gezaehlt UND genannt werden, hat ihn gefunden.
Genau dafuer steht die Zeile dort.
Behoben an der Wurzel: Anfuehrungszeichen innerhalb einer Einsetzung
`${…}` werden vorher durch X ersetzt, bei gleicher Laenge und
gleichen Zeilenumbruechen. Das nimmt einer ganzen Sorte
Fehlklassifizierung die Grundlage — die Ausnahmen fielen danach von
13 auf 11.
UND EIN VIERTES, BEIM MESSEN AUFGEFALLEN
`„Van-Van”` in assets/js/data-modis.js schliesst mit U+201D, dem
ENGLISCHEN Zeichen. Zweimal, beide Male in einer DEUTSCHEN Zeile
(`de:` und `"de-CH":`) — nicht einmal eine Uebersetzung, in der es
richtig waere. Eigene Regel dafuer, die keine Ausnahme braucht: Wer
mit `„` oeffnet, schliesst deutsch; in fremdsprachigen Zeilen steht
gar kein `„` am Anfang.
DIE AUSNAHMEZAHL IST JETZT STRENG. Sie stand auf „hoechstens 12" —
damit waere der Anstieg auf 13 nicht aufgefallen. Jetzt genau 11,
wie bei den Grundlinien in pruef-fingermass.
GEPRUEFT: pruef-struktur 68 -> 75 Pruefungen, 0 Fehler. Dazu
leistung-optik 59/0, ampel 47/0, treff 85/0, modi-verborgen 87/0 —
die Seiten, deren Text ich angefasst habe. Steuerzeichen: 830
Dateien, keines. Beide Stempel gesetzt.
Sechs echte Stellen berichtigt, vier neue Gegenproben.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2b3f140112 |
Wissen: ein gerades Schlusszeichen, von der Wache gefunden
workspace/assets/js/wissen.js:556
... legst du unter „Dateien" ab. (gerades ")
... legst du unter „Dateien“ ab.
Die Zeile ist nicht von mir: Sie kam heute um 14:33 aus einer
zweiten Sitzung im selben Verzeichnis (Commit
|
||
|
DogFatherGitandClaude Opus 5
|
b2b016f8dd |
Reaktion auf 320 px: das Bild ist ganz zu sehen
NACHGEMESSEN, wie es nach dem Einklappen der Reiterleiste wirklich
aussieht — und zwar im ANFANGSZUSTAND, mit zugeklappter Leiste:
Regie Raum Kino Schiene Pult Transport
412x915 45 620 232 388 128 181
390x844 45 549 219 330 128 181
360x640 45 345 203 143 128 181
320x568 45 75 75 1 198 181
Die Regieleiste ist von 101 bzw. 148 auf 45 Pixel geschrumpft — auf
320 px sind das 197 gewonnene Pixel.
EIN MESSFEHLER VON MIR, hier festgehalten: Mein erster Lauf zeigte
die Leiste GROESSER als vorher (148, 195, 242). Das Werkzeug klappt
sie weiter oben selbst auf, um die Register zu messen, und ich habe
danach die Hoehen gelesen. Gemessen war also der falsche Zustand —
eine Messung, die veraendert, was sie misst.
WAS AUF 320 BLEIBT: Der Raum hat 75 Pixel, das Bild wollte 180. Das
Pult liegt mit `z-index: 60` darueber, die Knoepfe sind also
erreichbar — und genau deshalb melden pruef-breiten und pruef-handy
nichts. Zu sehen war vom Bild trotzdem nur das obere Drittel.
`max-height: 100%` an der Leinwand. Gemessen wird der Kasten damit
320x75; die Breite bleibt, das Verhaeltnis gilt nicht mehr — aber
der Spieler darin setzt das Bild mittig mit Balken links und
rechts. Es ist klein und GANZ, statt gross und zu zwei Dritteln
hinter dem Pult.
(Im Kommentar stand zuerst, die Breite folge dem Verhaeltnis. Tut
sie nicht — 320x75, nicht 133x75. Berichtigt, bevor jemand sich
darauf verlaesst.)
AUF 360, 390 UND 412 AENDERT SICH NICHTS: Dort ist der Kasten
hoeher, als 16:9 verlangt, und `max-height` greift nicht ein.
Nachgemessen: 203, 219, 232 — wie vorher.
GEPRUEFT: pruef-handy 186/0, pruef-breiten 23/0, pruef-reaktion
421/0, mess-quer „NICHTS rollt seitlich".
EHRLICH BLEIBT: 320x568 zeigt weiterhin keinen Chat (Schiene 1 px),
und das Bild ist dort 320x75. Mit 198 Pixeln Pult und 181 Pixeln
Transport von 499 geht nicht mehr. Das waere ein eigener Schritt
und eine eigene Entscheidung — kein Nebenbei.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
63a56980c0 |
Wissen: Eine Absage ohne Alternative ist eine halbe Antwort
Wer eine Nicht-PDF in die Ablage zieht, bekam "Das ist keine PDF-Datei." -- richtig, aber eine Sackgasse. Filipe hat heute eine HTML-Praesentation dort abzulegen versucht, keinen Weg genannt bekommen und den Fehler bei sich gesucht. Jetzt steht dabei, wohin sie gehoert: unter "Dateien". Das ist die einzige Stelle, an der wir es ueberhaupt sagen koennen -- beim Auswaehlen ueber den Knopf greift schon `accept`, und die Datei ist im Fenster des Betriebssystems gar nicht erst anklickbar. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5a9f1f467c |
Wissen und Dateien: Zwei Raster, die ihren Inhalt verloren haben
Filipe zum Bildschirmfoto der Wissen-Seite: "erstens sieht das richtig
scheisse aus". Zu sehen war die Kategorie-Auswahl quer ueber "STUFE",
"GERAET", "VEROEFFENTLICHT AM" und den Tag-Knoepfen. Text auf Text.
Zweimal dieselbe Ursache, zweimal ein Raster, das Kinder in eine Zelle
zwingt, die zu klein ist:
1. FORMULAR "NEUE ANLEITUNG" (aufgaben.css). Die Regel
`grid-template-rows: 1fr 44px` gibt jeder Zelle eine feste
Eingabezeile -- richtig und wichtig, damit alle Felder auf einer
Linie sitzen. Die Zelle "Hauptkategorie" enthaelt aber keine
Eingabe, sondern sechs Gruppen mit zwanzig Knoepfen. Gemessen: der
Kasten 40 px hoch, sein Inhalt 442 -- 402 px liefen ueber alles
darunter. Unter 560 px passierte das nicht, weil dort ohnehin
`auto auto` gilt; deshalb sah es am Handy richtig aus.
Es ist exakt die Falle, die eine Regel darueber schon einmal
zugeschnappt ist ("EINE ZELLE, DIE AUFKLAPPT ..."). Dieselbe
Antwort, diesmal fuer .katwahl.
2. DATEILISTE (dateien.css). .datei hat die Spalten `34px 1fr auto`.
Die ersten vier Kinder sitzen richtig; alles danach wird automatisch
platziert und landet in der ZEICHENSPALTE. Gemessen: "Fassung 2" in
34 px Breite, 22 px herausragend; auf 390 px zusaetzlich die
Metazeile ("1,9 MB" in zwei Zeilen) und "Sichtbar fuer" mit 49 px
Ueberstand.
ZWEI NEUE PRUEFUNGEN, und die erste war erst selbst falsch:
pruef-wissen-formular.mjs verglich zunaechst den KASTEN der Auswahl mit
dem der Zelle und meldete gruen, waehrend das Bildschirmfoto die
Ueberlappung deutlich zeigte. Der Kasten ist ja brav 44 px hoch --
herausgelaufen ist sein INHALT. Jetzt wird scrollHeight gegen
clientHeight gemessen, und die Pruefung wird rot, bevor der Fix
dazukommt. pruef-dateien-liste.mjs legt bewusst zweimal dieselbe Datei
ab, damit "Fassung 2" und "nicht mehr aktuell" ueberhaupt entstehen.
Versionsstempel neu gesetzt (202610011426, 670 Verweise in 45 Dateien).
Ohne ihn liegt die Korrektur auf dem Server und kommt bei niemandem an:
Cache-Control steht auf immutable.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
dc5e6a0c24 |
Reaktion: das Chatfeld bekommt einen Namen
pruef-handy-teamdogi meldete auf beiden Geraeten und fuer Modi und
Community dasselbe:
reaktion.html: Bedienelement ohne Namen — input#chat-feld
Sein einziger Name war der PLATZHALTER. Der ist keiner: Er
verschwindet in dem Moment, in dem jemand anfaengt zu tippen, und
danach hat das Feld fuer ein Vorleseprogramm gar keinen Namen mehr.
Der Knopf daneben macht es seit jeher richtig
(`aria-label="Senden"`).
UND DER NAME WANDERT MIT. Das Feld sagt im Platzhalter, warum
gerade nicht geschrieben werden kann — „Der Chat ist gerade zu",
„Du bist gerade stumm geschaltet", „Gerade schreibt nur das Team".
Ein fester `aria-label` haette genau diese Auskunft fuer das Ohr
verschluckt. Er kommt deshalb aus derselben Zeile wie der
Platzhalter: eine Angabe, zwei Ausgaben. Zwei getrennte Texte
waeren die naechste Stelle, an der einer gepflegt wird und der
andere nicht.
GEPRUEFT
pruef-handy-teamdogi 8 Befunde -> 14 Pruefungen, 0 Fehler
pruef-reaktion 421 Pruefungen, 0 Fehler
pruef-handy 186 Pruefungen, 0 Fehler
Damit ist die Liste der alten offenen Punkte abgearbeitet:
- pruef-fingermass (Grundwert 1) unveraendert 1, dazu eine
zweite Zahl fuer die
Faelle, die sie bisher gar
nicht sehen konnte
- Regie/Transport auf 320x568 die Ueberlappung ist weg
- report.html 27x18 px gibt es nicht mehr; beide
Messungen melden die Seite
sauber (Notiz war veraltet)
- Ueberstand pruef-handy-teamdogi 0 Befunde
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
48470961c7 |
Reaktion am Handy: nichts liegt mehr auf einem Knopf
AUSGANGSLAGE, gemessen: pruef-breiten meldete auf sechs von neun
Breiten einen verdeckten Knopf, pruef-handy auf allen drei
Telefonen. Immer dieselbe Stelle: „Offen", „Team" und „Zu" aus dem
Chatkopf lagen auf dem Pult. Wer sie antippte, traf „Starten" oder
„Beenden".
ENDSTAND: pruef-breiten 23 Pruefungen / 0 Befunde, pruef-handy 186 / 0,
mess-quer „NICHTS rollt seitlich", pruef-reaktion 421 / 0.
Davon waren DREI VON VIER Befunden Messfehler. Gefunden, weil ich
ihnen nachgegangen bin statt ihnen zu glauben.
1. pruef-breiten MASS OHNE FINGER
newContext({ viewport: { width: breite, height: hoehe } })
Ohne `hasTouch` meldet der Browser `pointer: fine`, und KEINE
Regel aus `@media (pointer: coarse)` greift — dort stehen die
44-Pixel-Beruehrziele, die ausgeblendeten Tastenkuerzel und seit
heute die eingeklappte Reiterleiste. Auf 320, 390 und 430 Pixeln
wurde also eine Seite vermessen, die es auf keinem Telefon gibt.
Aufgefallen, weil mess-quer dieselbe Seite auf 390 MIT Finger
misst und dort nichts findet. -> 390 und 430 sofort gruen.
2. DER VERDECKUNGS-FINDER KANNTE KEINE ROLLKAESTEN
Gemeldet war auf 1024, 1920 und 2560 immer ein Feld AUS DEM PULT
„unter" der Transportleiste — und auf 1280 und 1440 nichts. Das
Pult rollt in sich; was unten herausgerollt ist, liegt
rechnerisch dort, wo die Leiste steht, und `elementFromPoint`
liefert die Leiste. Verdeckt ist da nichts — es ist weggerollt.
Das Fenster kannte der Finder schon (`r.bottom < 0`), den
Rollkasten nicht. -> drei Breiten gruen, die Gegenproben
(„ein echtes Hindernis wird gefunden") schlagen weiter an.
3. UND EIN ECHTER BEFUND, ZWEIMAL
a) Reiterleiste: acht Register brauchen am Handy zwei Zeilen
(100 px auf 360, 148 auf 320). Sie klappen jetzt hinter ihren
eigenen Wert — dasselbe Muster wie die Tempo-Gruppe, und der
Knopf zeigt, wo man steht. NICHT einzeilig zum Wischen:
Filipes Ansage vom 28.09. galt dem Wischen nach links und
rechts, und mess-quer misst genau das.
b) Bei OFFENER Regie nimmt das Pult auf 412x915 vierhundert-
vierundachtzig der 846 Pixel. Nebeneinander stehen Regie und
Bild erst ab 1100 px. Am Fingergeraet tritt die Chatschiene
deshalb beiseite, solange die Regie offen ist — wer etwas
einstellt, muss das Bild im Auge behalten, den Chat nicht, und
der ist einen Fingertipp entfernt.
4. MEINE EIGENE WACHE WAR BLIND — ZWEIMAL
pruef-fingermass sucht `width: <Zahl>`. In pruef-breiten stand
`width: breite`, eine Variable: kein Treffer, also „in Ordnung".
Sie meldete dabei brav „1 blindes Fenster, unveraendert zur
Grundlinie" — und war selbst blind. Jetzt gibt es einen dritten
Ausgang: Breite vorhanden, aber keine Zahl, und kein hasTouch
daneben -> „konnte nicht nachsehen", mit eigener Grundlinie.
Beim ersten Anlauf meldete der 45 Faelle, darunter jedes
`newContext({ permissions: [...] })`. Zu grob: Ein Fenster ganz
OHNE Breite ist das Standardfenster, kein Telefon. Enger gefasst.
UND DANN WAR DIE ZAHL 0 — WEIL DER AUSDRUCK TOT WAR. Das `\b` in
`/\bwidth\s*:/` war ein echtes Rueckschritt-Zeichen (0x08),
unsichtbar im Quelltext. Heute Nacht hat mich dasselbe schon
einmal eine halbe Stunde gekostet. Mit heilem Ausdruck sind es
39 echte Faelle — etwa mess-chat-liste bei 390 px ohne Finger.
Als Grundlinie festgehalten: Sie darf nur sinken, jede neue
faellt auf, und abgearbeitet wird Datei fuer Datei mit je einem
Lauf danach.
Ein Werkzeug sucht jetzt alle Steuerzeichen im ganzen Haus
(tools, gitignoriert). Es fand zwei: meins von heute und ein
aelteres in pruef-reaktion.mjs — `!/^none\b/.test(wert)` hat
dort nie gegriffen. Beide bytewise ersetzt, 830 Dateien sauber.
5. mess-quer MUSS TUN, WAS EIN MENSCH TUT
Es wartete auf eine SICHTBARE Reiterleiste und lief in die
Zeitsperre, seit sie zugeklappt startet. Jetzt wartet es auf die
Leiste und klappt auf — vor jedem Register, denn ein Klick
schliesst sie wieder.
WAS NICHT GEMACHT WURDE, UND WARUM: Die Messwerte im Pult („Sehen
zu", „Mit Bild", „Gaeste", „Upload") standen in meiner eigenen
Auswahl als Sparposten. Beim Nachsehen steht beim Upload die
Begruendung im Quelltext: „der Unterschied zwischen ,es ruckelt bei
euch?' und ,ich sehe, dass es zu viel wird'". 26 Pixel gegen echte
Information waehrend der Sendung — falscher Tausch.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d7f3e747b8 |
Reaktion: 26 Pixel zurueck fuer den Chat am Handy
Die rechte Gruppe der Transportreihe war auf 360x640 gemessen
122 Pixel hoch statt 44: In der dreispaltigen Reihe bekommt sie nur
89 Pixel Breite und bricht dreimal um. Das Wort „Weiter" davor ist
dabei eine Beschriftung fuer zwei Knoepfe, die ihre Aufgabe selbst
draufstehen haben — „Naechstes" und „Wechseln zu <Titel>".
Dieselbe Ueberlegung wie beim Wort „Tempo", das aus genau diesem
Grund schon weg ist. Am Rechner bleibt es: Dort ist Platz, und dort
ordnet es die Leiste.
GEMESSEN (mess-quer, mit Finger, Regie zugeklappt):
Transportleiste 207 -> 181 px auf 320, 360, 390 und 412
Chatschiene +26 px auf jedem Handy
Rechner/Tablet unveraendert (158 / 185)
WAS DAS NICHT LOEST, UND DAS SAGE ICH LIEBER GLEICH: Die verdeckten
Chatstufen auf 320 und 360 sind weiterhin da. pruef-breiten und
pruef-handy melden unveraendert 6 bzw. 3 Befunde. Der Grund steht
jetzt mit Zahlen im Quelltext — es ist eine Platzfrage, keine
Regelfrage, und sie braucht eine Entscheidung.
EIN VERSUCH, DER ZURUECKGENOMMEN WURDE: `minmax(0, auto)` statt
`auto` an der Kinozeile des Raums. Gemessen null Pixel Unterschied
(Kino vorher wie nachher 203 px). Der Raum ragt naemlich nicht aus
eigener Kraft ueber seine Zeile — die Zeile hat auf 360 px noch
161 Pixel, und ein 16:9-Video auf 360 px Breite will 203. Keine
Angabe an DIESEN Zeilen aendert daran etwas. Die Begruendung steht
jetzt dort, damit es niemand ein zweites Mal probiert.
Eine Regel, die nur aussieht, als taete sie etwas, ist schlimmer
als keine.
GEPRUEFT: pruef-handy 186 Pruefungen (3 Befunde, unveraendert),
pruef-breiten 23 (6 Befunde, unveraendert) — also keine neue
Beanstandung und keine verschwundene Pruefung. Stempel gesetzt.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
95c4599baa |
Anfuehrungszeichen: 199 falsche Schlusszeichen im sichtbaren Text
Deutsch oeffnet mit „ und schliesst mit “. An 199 Stellen, die ein
Mensch liest, stand als Schlusszeichen ein GERADES " -- „Nächstes"
statt „Nächstes“. Auf sechzehn oeffentlichen Seiten, in vierzig
Dateien des Workspace und in zwoelf Servermodulen, die Texte
verschicken.
Auf dem Bildschirm sieht man den Unterschied sofort. Beim Schreiben
nicht: Das gerade " liegt auf der Tastatur, die anderen nicht.
WARUM EIN ERSTER ANLAUF ZURUECKGENOMMEN WURDE
Ein gerades " ist an vielen Stellen SYNTAX und kein Schriftzeichen --
Grenze einer Zeichenkette, Grenze eines HTML-Attributs, Zeichen in
einem regulaeren Ausdruck. Wer stumpf ersetzt, macht aus
„<a href="https://… ein kaputtes Attribut
/^["'„»\s]+|["'“«.\s]+$/ einen kaputten Ausdruck
"… nichts „mal " + "eben …" eine kaputte Zeichenkette
DIE UNTERSCHEIDUNG LAEUFT AN MERKMALEN, NICHT AN EINER LISTE
< > = dazwischen -> HTML-Marke oder Attribut
endet auf Leerzeichen -> die Zeichenkette hoert hier auf, der
Satz geht in der naechsten Zeile weiter.
Ein deutsches Schlusszeichen steht NIE
hinter einem Leerzeichen.
Rueckstrich mittendrin -> regulaerer Ausdruck
${ ohne } -> mitten in einem Ausdruck
Eine Liste erlaubter Ausnahmen waere die naechste, die niemand
pflegt. Zwoelf Stellen bleiben dadurch stehen, alle zwoelf einzeln
angesehen und alle zwoelf zu Recht -- dort steht das richtige
Schlusszeichen ohnehin weiter unten im Satz.
Fuenf davon waren allerdings ECHTE Fehler HINTER dem Link
(`…>HasiDog</a>".`) -- die erste Regel hatte nur das Attribut
gesehen, nicht den Satz danach. Gezielt nachgezogen.
Ein maskiertes `\"` in workspace-vorlagen.js (28 Hooks) wird zu “ --
ohne Rueckstrich, denn “ begrenzt nichts.
KOMMENTARE BLEIBEN, WIE SIE SIND. Dort liest es niemand ausser mir;
eine Wache, die auch Kosmetik anmahnt, wird weggeklickt. Beim ersten
Messen fielen ausserdem acht Stellen aus buehne.html faelschlich an,
weil `/* */` in HTML (in <style> und <script>) nicht ausgeblendet
war -- jetzt schon.
DIE WACHE DAZU
pruef-struktur prueft es ab sofort mit derselben Regel: 322 Dateien
mit sichtbarem Text, 0 Funde, und die zwoelf bewussten Ausnahmen
werden GEZAEHLT und genannt (erlaubt: 12). Eine Ausnahme, die niemand
sieht, waechst -- und irgendwann steht der echte Fall darin.
GEPRUEFT
pruef-struktur 59 -> 68 Pruefungen, 0 Fehler
node --check auf allen geaenderten JS-Dateien
nachgemessen: 199 geaendert, 12 mit Grund stehen geblieben
gruen geblieben: bewerbung-aufgaben 163, nachwuchs 262,
reaktion 421, support 63, content 45, terminregel 35, treff 85
Und nachgesehen, ob eine Pruefung noch die alte Schreibweise
ERWARTET: 13 Fundstellen, alle dreizehn nur Text in ihrer eigenen
Ausgabe, keine einzige ein Vergleich mit dem Seitentext.
GEGENPROBE: In reaktion.html ein Schlusszeichen zurueckgedreht ->
„workspace/reaktion.html:546 „Nächstes"", mit Datei und Zeile. Und
die Erkennung einzeln gegen HTML-Attribut, fortgesetzte
Zeichenkette, regulaeren Ausdruck und eingesetzten Wert geprueft.
Stempel gesetzt: workspace 670 Verweise in 45 Dateien, oeffentlich
554 in 48 Seiten.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8e18c7bcf0 |
Aufgaben: eine Bewerbung auf eine erledigte Aufgabe ist keine mehr
Beim Durchsehen der echten Daten am 30.09. gefunden, Filipe am 01.10.: „mach alles los." GEMESSEN: Zwei Bewerbungen von Miss standen auf „beworben" -- an Aufgaben, die laengst `erledigt` bzw. `review` waren. Bei ihr stand weiter „wartet auf Antwort", und in der Liste der Leitung stand eine Entscheidung an, die es nicht mehr gibt. DAS MUSTER GIBT ES IM HAUS SCHON. `uebernahmeAbschliessen` raeumt genau so die offenen Bewerbungen weg, wenn jemand anderes eine Pool-Aufgabe bekommt -- samt dem Kommentar daneben: „Ohne diese Zeile blieb eine Bewerbung auf ,beworben' stehen, nachdem jemand anders die Aufgabe bekommen hat." Derselbe Fall, ein anderer Ausloeser, dieselbe Behandlung. ZWEI WEGE FUEHREN IN DEN ENDZUSTAND -- erledigen und abbrechen. Beide rufen jetzt dieselbe Funktion; nur einen zu bedienen waere die Haelfte, die man spaeter sucht. Der SATZ ist verschieden: „abgebrochen" ist nicht „erledigt", und wer gewartet hat, soll den Unterschied lesen koennen. KEIN `entschieden_von`. Niemand hat entschieden, die Frage hat sich erledigt. Dadurch faellt die Zeile auch aus der Absagen-Uebersicht von gestern heraus (die fragt `entschieden_von IS NOT NULL`) -- richtig, es ist keine Absage an diesen Menschen. KEINE BENACHRICHTIGUNG. „Deine Bewerbung: diesmal nicht" waere falsch -- es hat niemand nein gesagt. Der Satz steht an der Zeile. Wenn Filipe hier doch eine Meldung will, ist es eine eigene Art mit eigenem Wortlaut, kein Anhaengsel an die bestehende. GEPRUEFT -- pruef-bewerbung-aufgaben 163/0 (9 neue): bewirbt sich -> „beworben" Aufgabe erledigt -> faellt weg, mit Satz, ohne Entscheider Aufgabe abgebrochen -> ebenso, mit anderem Satz Aufgabe noch offen -> Bewerbung bleibt <- die Gegenprobe Ohne die letzte Zeile hiesse „faellt weg" womoeglich nur, dass jede Bewerbung wegfaellt. Ein eigener Messfehler unterwegs: Mein Lesehelfer fragte `/api/aufgaben/:id` und bekam `undefined` -- die Antwort dort hat eine andere Form. Vier Pruefungen waren rot, waehrend der Mechanismus im Protokoll nachweislich lief. Jetzt ueber die Liste, die in dieser Datei erprobt ist. Die eine vorhandene Zeile wird nachgetragen; auf einer Kopie der echten Datenbank durchgespielt (danach 0 offene Bewerbungen auf durchgelaufenen Aufgaben, integrity_check ok). pruef-zuteilung, pruef-aufgabenbrett, pruef-zwischenspeicher. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
09375047a7 |
Entwicklung: die Karte geht auf dem Zugetragenen auf
Filipe, 01.10.2026: „mach alles los." Damit auch der offene Punkt von gestern: „Zugetragen" ist beim Aufmachen einer Karte die Vorgabe. DER ALTE EINWAND BLEIBT GUELTIG -- er steht jetzt in der Bedingung statt im Weg. Er lautete: „Ein Filter, der beim Öffnen schon etwas versteckt, lässt einen Punkte suchen, die gestern noch da waren." Richtig, und er trifft genau EINEN Fall: den, in dem gar nichts zugetragen ist. Dann zeigte „Zugetragen" eine LEERE Karte, und eine leere Karte sieht aus wie ein Fehler. Also: Hat dieser Mensch zugetragene Punkte, steht der Filter darauf. Hat er keine, steht er auf „Alle". Beides ist eine Auskunft, keines ist eine Suche. UND ER WIRD JE MENSCH NEU ENTSCHIEDEN. Bisher blieb der Filter ueber den Personenwechsel hinweg stehen -- richtig, solange er eine Erwartungsstufe meinte („wer Fortgeschritten gewaehlt hat, will das weiter sehen"). „Zugetragen" ist eine Aussage UEBER DIESE PERSON; sie mitzunehmen waere die falsche Frage. GEMESSEN, beide Faelle: Diene (2 zugetragen) -> Filter „Zugetragen", 2 Punkte VanVan (nichts) -> Filter „Alle", 68 Punkte ein Klick auf „Alle" -> wieder 68 Die Messung fragt jetzt, WAS DASTEHT, bevor jemand etwas anfasst. Vorher klickte sie auf den Filter und zaehlte nach -- seit er die Vorgabe ist, haette derselbe Klick ihn AUSgeschaltet. Sie haette das Gegenteil gemessen und trotzdem eine Zahl gemeldet. ZWEI NACHZUEGLER AUS DEM SICHT-WEG VON GESTERN `pruef-werdegang` wurde rot: „403 Forbidden" im Browser, ohne Adresse. Die Meldung sagte nicht, WORAN sie scheitert -- also sagt sie es jetzt (`403 /workspace/api/chat/sicht`). Die Ursache lag in der Messumgebung, nicht im Programm: Der HTTPS-Vorbau der Pruefung reicht den Host OHNE Port weiter, waehrend der Browser seine Herkunft MIT Port schickt. `gleicheHerkunft` vergleicht beides und antwortet folgerichtig 403. mess-reaktion macht es seit Langem richtig; zwei Dateien nicht. Aufgefallen ist es erst jetzt, weil der Sicht-Weg der erste zustandsaendernde POST ist, der auf JEDER Seite laeuft. Live stimmen Herkunft und Host ueberein (beide ohne Port, Caddy reicht den Host durch) -- nachgemessen. GEPRUEFT pruef-werdegang 103/0 (war 103/1), pruef-entwicklung 79/0, pruef-entwicklung-kacheln 34/0, mess-vanvan-karte ohne ein einziges ACHTUNG, pruef-zwischenspeicher 34/0. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
718b267de0 |
Zugang: die gewaehlte Kachel ist bindend
Filipe, 01.10.2026: „mach das. es soll fest sein." VanVan hatte gemeldet: „Man kann sich mit seinem Zugangscode immer noch über jeden Button der Startseite anmelden, egal welche Rolle man hat." ICH HATTE ZUERST ABGERATEN -- und lag falsch, weil ich eine alte Lage beschrieben habe. Am 09.09.2026 hatte Filipe entschieden, dass die Modis KEINE eigene Eingangskachel bekommen: „damit die von der workspace auch nicht mal sehen dass die modis von mir einen eigenen zugang haben." Wer keine Kachel hat, muss irgendeine nehmen koennen -- daher der stille Zugang. SEIT DER HAUSTRENNUNG AM 24.09.2026 STIMMT DAS NICHT MEHR. Auf `crew.` steht laengst ein eigener Kachelsatz mit ALLEN fuenf Rollen: DogFather, rechte Hand, linke Hand, Modi, Community (CREW_KACHEL, und crew-index.html zeigt sie). Das Verbergen leistet seither die ADRESSE -- wer sie nicht kennt, findet die Wand nicht; wer sie kennt, liest die Rollennamen ohnehin offen darauf. Der stille Zugang war damit ein Rest. Er hat niemanden mehr geschuetzt und nur dafuer gesorgt, dass die Kachelwahl folgenlos blieb. Nachgesehen habe ich das erst, NACHDEM Filipe widersprochen hat; die Kachelsaetze standen die ganze Zeit im Quelltext. WAS SICH NICHT AENDERT: Auf der Agenturwand war der stille Zugang nie aktiv. Ein Team-Dogi-Code verhaelt sich dort weiterhin wie ein erfundener -- gleiche Antwort, gleicher Weg, gleiche Dauer. Das ist jetzt ausdruecklich gemessen. EINE PRUEFADRESSE IST KEINE WAND. `127.0.0.1` ist weder crew. noch Agentur. Ohne den stillen Zugang gaelte dort der Agentursatz -- und kein Modi kaeme mehr herein. Fuenfzig Pruefdateien melden Team-Rollen ueber diese Adresse an. Auf einer Adresse ohne Wand gibt es deshalb ALLE Kacheln; welche auf welcher ECHTEN Wand steht, misst pruef-modi-verborgen mit ausdruecklichem Host-Kopf. GEPRUEFT -- pruef-modi-verborgen 87/0 (war 85; die fuenf Zeilen „jede Kachel geht" sind durch sieben ersetzt, die die neue Regel und ihre Gegenproben messen). Die Anzahl ist Zeile fuer Zeile verglichen. Modi-Kachel + Modi-Code -> herein admin/hand/linke/gast -> abgewiesen rechte Hand auf ihrer Kachel -> herein Agenturwand + Modi-Code -> wie ein erfundener pruef-crew-adresse 169/0 (unveraenderte Anzahl, zwei Zeilen umgedreht). SECHZEHN PRUEFDATEIEN MELDETEN SICH UEBER FREMDE KACHELN AN -- ein Rest derselben Zeit. Systematisch gesucht statt einzeln entdeckt: Waere ich dem roten Lauf hinterhergelaufen, haette ich beim zwoelften aufgehoert. UND DABEI EIN EIGENER FEHLER: Mein erster Durchlauf las die Rolle am CODENAMEN ab (CODE-MODI- -> modi). Das ging gut, bis „Nane" kam: ein Modi mit dem Code CODE-NANE-0001. Zwei Pruefungen wurden rot, und zwar an einer Stelle („die Stimmen stimmen"), die mit Anmeldung nichts zu tun hat. Ein Codename ist eine Beschriftung, keine Tatsache -- die Rolle steht in `anlegen()`. Danach abgeleitet blieben genau zwei Abweichungen uebrig, und beide sind absichtliche Gegenproben. Drei Browserpruefungen tippten die Creator-Kachel mit einem Modi-Code. Die Modi-Kachel gibt es nur auf der Crew-Wand, und ein Browser auf 127.0.0.1 bekommt die Agenturwand; sie melden sich jetzt ueber die Schnittstelle an und bekommen den Keks. Gemessen werden soll dort, was ein Modi SIEHT -- nicht, wie er hereinkommt. Grün: pruef-modi-verborgen, pruef-crew-adresse, pruef-treff 85/0, pruef-galerie, pruef-kanaele, pruef-modi-katalog 150/0, pruef-modi-ideen, pruef-modi-kategorien, pruef-modi-checkliste 75/0, pruef-modi-livecheck, pruef-kachelraster, pruef-team-ampel 32/0, pruef-team-stufen 47/0, pruef-wunschliste, pruef-bremse, pruef-gespraech, pruef-personen-formular 43/0, pruef-start-ansicht, pruef-community-sicht, pruef-reaktion 421/0, pruef-abzeichen, pruef-chat, pruef-chat-kanaele 81/0, pruef-entwicklung 79/0, pruef-bewerbung-aufgaben 154/0, pruef-struktur, pruef-zwischenspeicher 34/0. `code_kennung` wird weiter geschrieben, aber nicht mehr gelesen -- sie war der Suchschluessel des stillen Weges. Stehen gelassen: Eine Spalte zu entfernen ist eine Schemaaenderung mit Sicherung, und sie kostet nichts. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4503b1a475 |
Benachrichtigungen: nicht "Verbindung offen", sondern "sieht jemand hin"
Diene im Support (vor 5 Tagen): „Die Benachrichtigungen werden nicht
angezeigt, wenn neue Nachrichten reinkommen. Erst, wenn man die App
öffnet."
ERST GEMESSEN, WAS NICHT DAS PROBLEM IST. Am echten Bestand
nachgesehen: Diene HAT ein angemeldetes Geraet (Android, Chrome, seit
dem 29.09.), und alle zehn Geraete im Haus melden `fehler = 0`. An
der Zustellung liegt es nicht.
DANN NACHGESTELLT (pruef-abzeichen, Abschnitt 8):
Verbindung offen -> KEINE Benachrichtigung
Verbindung zu -> sie kommt
Genau sein Befund.
DER GEDANKE WAR RICHTIG, DIE FRAGE FALSCH. Im Quelltext stand:
if ((zuschauer.get(personId) || new Set()).size) continue;
und daneben die Begruendung -- „wer die Seite offen hat, sieht die
Nachricht ohnehin; ihm auch noch eine Meldung aufs Handy zu schicken
ist der schnellste Weg, dass er Benachrichtigungen abschaltet." Das
stimmt. Nur beantwortet `zuschauer` eine ANDERE Frage: ob eine
VERBINDUNG offen ist. Ein Handy mit der App im Hintergrund haelt sie
weiter -- und der Server hielt Diene fuer anwesend, waehrend sein
Bildschirm schwarz war.
DIE SEITE WEISS ES, DER SERVER NICHT. `document.visibilityState` ist
die einzige Stelle, die den Unterschied kennt. Also sagt sie es --
ueber einen winzigen Weg (`/api/chat/sicht`), beim Aufbau, bei jedem
Wechsel und mit `keepalive` beim Weggehen.
MIT VERFALL, und das ist der wichtige Teil: Ein Geraet, das
abstuerzt, im Funkloch steht oder eingefroren wird, sagt gar nichts
mehr. Ohne Verfall bliebe es fuer immer „sichtbar" und fuer immer
still. Wer nicht widerspricht, gilt nach zweieinhalb Minuten als weg
-- eine Meldung zu viel ist laestig, eine zu wenig ist genau der
Fehler, den Diene gemeldet hat. Dazu alle Minute ein Lebenszeichen,
solange die App vorn liegt.
EINE STELLE FUER DIE FRAGE. Sie wurde an zwei Orten gestellt:
`siehtZu()` und eine Abschrift mitten in `chatEreignis`. Die
Abschrift war die kaputte. Jetzt fragen beide dieselbe Funktion.
GEPRUEFT -- vier Lagen, und die zweite ist die wichtigere
Gegenprobe:
App liegt hinten -> Meldung kommt (war: nichts)
sieht wirklich hin -> KEINE Meldung (Absicht bleibt)
App weggelegt -> Meldung kommt wieder
gar keine Verbindung -> Meldung kommt
Ohne die zweite Zeile hiesse die Reparatur nur „jetzt kommt immer
eine", und das waere der schnellste Weg, dass jemand
Benachrichtigungen abschaltet.
UND EINE PRUEFUNG HAT DEN FEHLER MITGETRAGEN. pruef-anruf-klingelt
hielt den WORTLAUT der kaputten Zeile fest -- genau das, wovor ihr
eigener Kommentar drei Zeilen darueber warnt („Die Pruefung hat den
alten Wortlaut bestaetigt statt sein Verhalten"). Sie prueft jetzt
beides: dass gefragt wird, und dass die Frage die richtige ist.
pruef-abzeichen 26/0, pruef-chat, pruef-anruf 132/0,
pruef-chat-kanaele 81/0, pruef-anruf-klingelt 25/0, pruef-push-ziel
38/0, pruef-arten 28/0, pruef-reaktion 421/0, pruef-struktur,
pruef-zwischenspeicher 34/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d4a3e54a72 |
Aufgaben: dauerhafte Aufgaben, die nicht abgehakt werden
VanVan im Support: „Man kann bei den Aufgaben, wenn man sie verteilt, ob selbst erstellt oder über die Vorlage noch nicht festlegen, dass die Aufgabe dauerhaft sein soll und somit nicht vom Modi in den Status erledigt gesetzt werden kann." Nachgesehen: Das Wort kam im Aufgabenmodul kein einziges Mal vor. Es war keine vergessene Zeile, es fehlte ganz. WAS EINE DAUERHAFTE AUFGABE IST: keine, die man abarbeitet, sondern eine, die man TUT. „Neue begruessen" ist nicht fertig, wenn man es einmal gemacht hat. ZWEI FOLGEN, und die zweite faellt leicht durchs Raster 1. Der Zugeteilte kann sie nicht auf „erledigt" setzen. Die Sperre steht im SERVER -- ein fehlender Knopf ist eine Bitte, abgelehnt wird an der Route. „Ich fange an" bleibt erlaubt: Auch eine stehende Aufgabe hat einen Anfang. 2. SIE HAT KEINE FRIST. Eine dauerhafte Aufgabe mit Frist waere ab dem naechsten Tag fuer immer ueberfaellig -- und eine Warnung, die immer kommt, ist keine mehr. Die Frist wird GELOESCHT, nicht ignoriert: Ein Datum, das dasteht und nicht gilt, ist schlimmer als keins. WER DARF DAS SETZEN: nur, wer verteilt. Koennte der Zugeteilte seine eigene Aufgabe dauerhaft machen, waere das eine Ausrede; koennte er es zuruecknehmen, waere die Sperre ein Knopf weiter offen. Beides nachgemessen. UND SIE LAESST SICH BEENDEN. Eine Pflicht, die niemand mehr beenden kann, waere eine Falle statt einer Regel. DREI STELLEN, KEINE VIERTE: das Anlegeformular auf „Aufgaben", das auf „Eure Aufgaben" (dort wird verteilt) und das Bearbeiten-Feld. Ueber das letzte laeuft VanVans „oder ueber die Vorlage" -- eine Vorlagen-Aufgabe entsteht ohne Formular, ein Schalter im Vorlagenbrett waere eine vierte Stelle fuer dieselbe Frage. An der Karte steht die Marke fuer ALLE, nicht nur fuer den Zugeteilten: Wer sie ansieht, soll wissen, warum dort kein „Fertig" steht. Ein fehlender Knopf ohne Erklaerung liest sich wie ein Fehler. GEPRUEFT pruef-bewerbung-aufgaben 154/0 (10 neue) mit vier Gegenproben: eine GEWOEHNLICHE Aufgabe laesst sich sehr wohl abhaken (sonst hiesse 409 nur, dass niemand je etwas abhaken kann), „Ich fange an" geht weiterhin, der Zugeteilte setzt und nimmt „dauerhaft" nicht, und nach dem Beenden durch die Leitung geht das Abhaken wieder. ZWEI EIGENE FEHLER, beide von Pruefungen gefunden * Ein BACKTICK in einem Kommentar -- mitten in einem Template-String (`SPALTEN`). Er hat ihn beendet, die Datei war syntaktisch kaputt. Dieselbe Familie wie die deutsche Anfuehrung in einem Anfuehrungsstring: ein Zeichen, das in der Umgebung etwas bedeutet. * `toISOString().slice(0,10)` fuer „morgen" -- pruef-struktur hat es noch am selben Abend gefunden. Zwischen 00:00 und 02:00 liegt der UTC-Tag noch auf gestern; die Pruefung haette nachts falsch angeschlagen. Jetzt ueber `tagLokal()`. Und einer, den nur die Messung zeigen konnte: `holen()` in workspace-zuteilung liest die Aufgabe mit einer eigenen, kurzen Spaltenliste. Ohne `dauerhaft` darin fragte die Sperre `a.dauerhaft` und bekam `undefined` -- sie war still wirkungslos, und im Quelltext daneben sah alles richtig aus. pruef-aufgabenbrett, pruef-zuteilung, pruef-aufgaben-vorlagen, pruef-entwicklung 79/0, pruef-css-klassen, pruef-deutsche-texte, pruef-struktur, pruef-zwischenspeicher 34/0. Schemaaenderung: ADD COLUMN dauerhaft. Datenbank vorher gesichert und geprueft (integrity_check ok, 12 Aufgaben). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5e26df788b |
Bewerbungen: die Absage bleibt lesbar, und ihr seht, was ihr absagt
VanVan im Support: „Wenn sich ein Modi auf eine Aufgabe bewirbt und
man diese ablehnt, dann bekommt der Modi keine Benachrichtigung
darüber, dass die Aufgabe abgelehnt wurde und sieht somit auch eine
eventuelle Begründung nicht. Außerdem haben auch wir nirgendwo eine
Übersicht, bei wem wir welche Aufgaben schon abgelehnt haben."
GEMESSEN, BEVOR GEBAUT WURDE -- die Pruefungen standen zuerst da und
waren rot:
Frida sieht ihre beantwortete Bewerbung 0
Die Leitung sieht die Absagen 0
DIE URSACHE. `vorlagenBewerbungenFuer` fragt `WHERE zustand =
'beworben'`. Sobald jemand antwortet, faellt die Zeile aus JEDER
Ansicht heraus -- mitsamt der Begruendung, die Filipe am 23.09.
ausdruecklich verlangt hat („mit einem text als notiz"). Der Satz
wird also verlangt, geschrieben und weggesperrt.
Bei einer ZUSAGE fiel das nicht auf: Dort entsteht eine Aufgabe, und
an ihrer Karte steht die Antwort. Bei einer ABSAGE entsteht nichts.
Die Benachrichtigung selbst gab es (`bewerbung_antwort`, vorgabe an,
fuer ja und nein). Sie war nur das EINZIGE -- wer sie wegwischt oder
kein Geraet angemeldet hat, erfuhr nie, warum.
WAS JETZT DASTEHT
* BEIM BEWERBER: „Antwort auf deine Bewerbung" mit dem Ergebnis, dem
Satz und dem Namen dessen, der geantwortet hat. Beide Ausgaenge --
eine Liste, die nur Absagen sammelt, waere eine andere Sache. Nach
14 Tagen verschwindet sie von selbst.
SIE STEHT VOR DEM ZUKLAPPEN. Beim ersten Anlauf lag sie im Koerper
des Vorlagenbretts, und der wird nur gebaut, wenn das Brett
aufgeklappt ist -- zugeklappt ist die Vorgabe. Eine Antwort, die
man erst aufklappen muss, ist wieder keine.
* BEI DER LEITUNG: „Schon abgesagt", 90 Tage, mit der Zahl JE MENSCH
vorn. Das ist VanVans eigentliche Frage („falls sich jemand immer
wieder bewirbt und immer wieder abgelehnt wird"), und die
beantwortet eine Liste von zwanzig Zeilen nicht.
AUS BEIDEN WEGEN -- Vorlage und Aufgabe. Eine Uebersicht, die nur
die Haelfte zeigt, ist schlimmer als keine: „Frida wurde nie
abgelehnt" waere dann eine Auskunft, die stimmt und taeuscht.
ZUGEKLAPPT. Eine Liste von Absagen, die immer offen steht, ist eine
Sammlung von Nein-Sagen ueber Menschen, mit denen man morgen wieder
arbeitet.
KEIN ROT. Eine Absage ist kein Fehler; „diesmal nicht" ist keine
Aussage ueber den Menschen. Gedeckter Bernstein, und ab zwei Malen
faellt die ZAHL auf -- nicht nur die Farbe.
ZWEI EIGENE FELDER UND NICHT `bewerbungen` ERWEITERT. Dort heisst
eine Zeile im Browser „wartet auf Antwort", samt Zurueckziehen-Knopf.
Beantwortete Zeilen hineinzumischen haette bei einer Absage genau das
gezeigt. Ein Feld, dessen Bedeutung sich aendert, bricht seine Leser
lautlos.
`entschieden_von IS NOT NULL` TRENNT DREI DINGE, die alle `abgelehnt`
heissen: die Leitung hat eine Bewerbung abgelehnt (das hier), die
Person hat eine Zuteilung abgelehnt (ihre Entscheidung), und „von
jemand anderem uebernommen" (gar keine Absage).
Haustrennung gilt: `darfSchreibenMit` je Zeile.
GEPRUEFT
pruef-bewerbung-aufgaben 144/0 (weitere 10 Pruefungen plus zwei
Bilder). Die Gegenprobe steht in der Vorgeschichte: Dieselben
Pruefungen waren vor dem Bau rot.
Zwei eigene Messfehler, beide im Text festgehalten: Ich habe zuerst
auf dem AUFGABENbrett gemessen -- der Vorlagenkatalog steht aber auf
„Eure Aufgaben" (`zweig: 'team'`). Und `innerText` liefert den Text
so, wie er DASTEHT: Die Zeile suchte „Diesmal nicht" und fand
„DIESMAL NICHT", weil das Schild `text-transform: uppercase` traegt.
pruef-vorlagen 24/0, pruef-aufgaben-vorlagen, pruef-zuteilung,
pruef-aufgabenbrett, pruef-entwicklung 79/0, pruef-css-klassen,
pruef-zwischenspeicher 34/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
c933bcd2e0 |
Aufgaben: wer verantwortlich ist, hat auch eine Zuteilung
VanVan im Support: „Wenn ein Modi sich auf eine Aufgabe beworben hat
und die von uns angenommen wurde, dann steht beim Modi unter der
Aufgabe immer noch ich bewerbe mich."
GEMESSEN AN DEN ECHTEN DATEN (lesend, auf einer Kopie):
Aufgaben mit Verantwortlichem: 11
davon OHNE Zuteilungszeile: 8
Darunter Marinas zwei offene Vorlagen-Aufgaben -- genau die zwei
Karten aus ihrem Bildschirmfoto.
DIE URSACHE. `katalogAufgabeAnlegen()` schrieb eine Zeile in
`aufgaben` mit `verantwortlich_id` und KEINE in
`aufgaben_zuteilung`. Das Brett liest aber die Zuteilung, nicht den
Verantwortlichen: Es fand nichts, lieferte `meine_zuteilung: null`,
und die Bedingung im Browser beginnt mit `!mein` -- also bot sie an,
sich auf die eigene Aufgabe zu bewerben.
ES WAR NICHT NUR EIN FALSCHER KNOPF. „Ich fange an" und „Fertig"
haengen an derselben Zeile. Der Mensch bekam eine Karte, auf der er
das Falsche tun konnte und das Richtige nicht.
WARUM DIE VORHANDENE PRUEFUNG ES NICHT FAND: Sie geht den Weg ueber
das AUFGABENbrett -- dort war alles in Ordnung, nachgemessen steht
nach dem Annehmen richtig „Ich fange an | Fertig". VanVans Weg ist
der ueber das VORLAGENbrett, und der endet in einer neu angelegten
Aufgabe. Dieser Weg war nie geprueft.
DREI TEILE
1. `katalogAufgabeAnlegen` legt die Zuteilungszeile mit an. Mit
Zustand: `angenommen`, wenn die Person darum gebeten hat und die
Bitte angenommen wurde; `offen`, wenn die Leitung zutraegt -- dann
steht bei ihr Annehmen/Ablehnen, und das ist richtig, sie hat noch
nicht ja gesagt.
2. Eine Umstellung traegt nach, was schon dasteht. Wiederholbar
(`NOT EXISTS` + `INSERT OR IGNORE`), deshalb bei den Umstellungen
und nicht in einem Skript, das jemand vergisst. Auf einer KOPIE
der echten Datenbank durchgespielt: 8 Zeilen angelegt, danach 0
ohne Zuteilung, `integrity_check ok`. Marinas Karten stehen
danach auf `angenommen`.
3. Ein Riegel im Browser: Auf eine Aufgabe, die mir schon gehoert,
bewirbt man sich nicht. Er faengt jeden weiteren Weg ab, der eine
Aufgabe ohne Zuteilungszeile anlegt -- nicht alle acht kamen aus
der Vorlage.
GEPRUEFT
pruef-bewerbung-aufgaben 126/0 (15 neue: der ganze Vorlagenweg von
der Bewerbung bis zum Knopf auf ihrem Brett). NACHGESTELLT: Ohne die
Zuteilungszeile wird sie rot („und sie hat eine Zuteilungszeile
(undefined)"). pruef-zuteilung, pruef-aufgabenbrett, pruef-vorlagen
24/0, pruef-aufgaben-vorlagen, pruef-struktur, pruef-zwischenspeicher
34/0.
Ein Messfehler unterwegs, im Text festgehalten: Mein neuer Block
bewarb sich auf dieselbe Vorlage wie ein spaeterer Abschnitt und
nahm ihm damit seine -- zehn Pruefungen wurden rot, ohne dass am
Programm etwas falsch war.
Datenbank vor der Umstellung gesichert und geprueft
(integrity_check ok, 12 Aufgaben, 3 Zuteilungen).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
721ad262df |
Entwicklung: „Deine Karte" laesst sich einklappen
VanVan im Support: „Deine Karte im Bereich eure Aufgaben kann man
noch nicht einklappen, was die Seite unnötig lang zieht und
unübersichtlich macht."
GEMESSEN (mess-vanvan-karte, Abschnitt 5). Es ist IHRE eigene Karte,
nicht die eines Modi -- im Bildschirmfoto steht an jedem Punkt „1 ×
Läuft", also eine einzige Antwort. Ueber die rechte Hand urteilt nur
DogFather; bei ihr ist deshalb alles durch und die Karte entsprechend
lang, waehrend ein Modi zwei Stimmen braucht.
vorher nachher
Seite gesamt 7245 px 2945 px
davon „Deine Karte" 6186 px 1886 px (zugeklappt 636 px)
Schalter 0 6 + „Alle"-Knopf
6186 von 7245 px waren eine einzige Karte -- 85 Prozent der Seite,
68 Zeilen am Stueck, kein einziger Schalter.
DERSELBE MECHANISMUS WIE NEBENAN, NICHT EIN ZWEITER. Die Karte der
Leitung klappt seit Langem auf und zu. Die Klassen, der Pfeil, die
Zahl im Kopf und der Knopf „Alle auf-/zuklappen" sind dieselben --
ein zweiter Mechanismus daneben waere der, der beim naechsten Umbau
vergessen wird, und er saehe anders aus, obwohl er dasselbe tut.
Herausgeloest als `klappAbschnitt()`.
WELCHER STEHT OFFEN: Was ich TUN soll („Deine Aufgaben"), und von den
Beobachtungen die erste Kategorie. Alle zu hiesse „jedes Mal erst
suchen", alle auf waere der Zustand von vorher.
DIE ZAHL STEHT IM KOPF (14, 12, 12, 11, 10, 9). Eine zugeklappte
Kategorie, die nicht sagt, wie viel in ihr steckt, klappt man einmal
auf und danach nie wieder zu.
GEPRUEFT
Die Messung ist jetzt selbst die Wache: Sie schlaegt an, wenn es
keine Schalter gibt (so ist der Befund entstanden), wenn Zuklappen
weniger als die Haelfte spart, und wenn es Schalter ohne
„Alle"-Knopf gibt. Alle drei nachgestellt. Ein ANTEIL und keine feste
Pixelzahl -- 68 Punkte heute, vielleicht 90 naechstes Jahr.
pruef-entwicklung 79/0, pruef-werdegang 103/0,
pruef-entwicklung-kacheln 34/0, pruef-css-klassen,
pruef-zwischenspeicher 34/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
51c47e1c07 |
Entwicklung: der Mensch sieht, was seine Aufgabe ist
VanVan im Support: „wenn ich … Aufgaben an einen Modi zutrage und
auch bewerte, dann sieht der Modi zwar die Auswertung im Bereich
Entwicklung, aber bei ihm taucht nichts im Bereich eure Aufgaben
unten in der Karte auf."
IHR FALL NACHGESTELLT (server/mess-vanvan-karte.mjs): VanVan traegt
einem Modi zwei von 68 Punkten zu und bewertet sie, Filipe bewertet
nichts -- genau wie bei ihr.
vorher seine Karte: fertig=0 von 68, alles „offen",
Punktzeilen sichtbar: 0
Kennt sie das Wort „zugetragen"? NEIN
nachher Abschnitt „Deine Aufgaben (2)" mit beiden Titeln
ZWEI DINGE WAREN EINS, DIE GETRENNT GEHOEREN
Was er TUN soll die Zuteilung. Die gibt es, bevor jemand etwas
bewertet, und sie gehoert ihm.
Was man SIEHT die Bewertung. Die erscheint erst, wenn alle
hingesehen haben.
`meine-karte` kannte nur das Zweite. War die Bewertung noch nicht
vollstaendig, stieg die Anzeige mit `return` aus -- und damit sah er
gar nichts, obwohl ihm zwei Aufgaben zugetragen waren. Das ist die
falsche Reihenfolge: Wer seine Aufgabe erst sieht, wenn sich zwei
Leute ueber ihre Ausfuehrung einig sind, kann sie nicht angehen.
Die Regel fuer die Bewertung bleibt unveraendert. Eine einzelne
Meinung soll bei einem Menschen nicht als Urteil des Teams ankommen.
UND DIE ANDERE HAELFTE: NIEMAND SAGTE ES IHR
VanVan hatte gesetzt, es kam nicht an, und nichts auf ihrem
Bildschirm erklaerte das. Ein Mensch, der das zweimal erlebt, hoert
auf zu setzen. An einem Punkt, den sie bewertet hat, steht jetzt
leise: „Er sieht das noch nicht -- es fehlt noch eine Einschaetzung."
Ohne Namen: Wer fehlt, waere eine Aufforderung, jemanden
anzutreiben.
IHRE ZWEITE BEOBACHTUNG, EBENFALLS GEMESSEN
„bei jedem Punkt läuft obwohl auch wenn die Aufgaben darüber gar
nicht zugetragen wurde." Stimmt: Die vier Bewertungsknoepfe („✓
Läuft ↗ Wächst ! Da hakt es – Kann ich nicht sagen") stehen an allen
68 Punkten, auch an den nicht zugetragenen. Beim Durchscrollen liest
man deshalb ueberall „Läuft".
DIE 68 BLEIBEN. Filipe am 25.09.2026 ausdruecklich: „dogfather und
die rechte hand sollen immer noch die 68 sachen sehen wie vorher …
unsere sicht soll sich nicht aendern." Also kein Ausblenden und
keine neue Vorgabe, sondern ein Knopf mehr in der Leiste, die es
schon gibt: „Zugetragen · 2". „Alle" bleibt, was beim Aufmachen
gilt. Gemessen grenzt er auf 2 Punkte ein, Kopf „2 / 2".
NEBENBEI ZUSAMMENGEFUEHRT
* `beurteilerZahl()` an einer Stelle -- beide Enden stellen dieselbe
Frage, zwei Abschriften saegten irgendwann Verschiedenes ueber
denselben Punkt.
* `antwortReihe()` und `punkteGefiltert()` ebenso.
* Die Abfrage stand zuerst je Punkt in der Schleife: 68
Datenbankfragen fuer eine Zahl, die sich nicht aendert.
GEPRUEFT
pruef-entwicklung 79/0 (9 neue, mit Gegenproben in beide Richtungen:
ein nicht zugetragener Punkt traegt die Marke nicht, und sobald der
zweite Beurteiler setzt, geht es durch). mess-vanvan-karte ohne
ACHTUNG. pruef-werdegang 103/0, pruef-entwicklung-kacheln 34/0,
pruef-deutsche-texte, pruef-css-klassen, pruef-zwischenspeicher 34/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
a3ec558127 |
Reaction: der Gleichlauf rechnet ohne Uhrenvergleich
Filipe: „die videos muessen perfekt laufen wenn ich die reaktions
mache."
GEMESSEN, NICHT VERMUTET. mess-reaktion hat einen neuen Abschnitt:
Er liest den Spielstand am ECHTEN <video>-Element in beiden Browsern,
rechnet beide auf denselben Augenblick um und sagt, wie weit Host und
Zuschauerin auseinanderliegen. Die vorhandene Pruefung fragte nur, ob
Start und Stopp ANKOMMEN -- zwei Videos koennen beide laufen und
trotzdem zwanzig Sekunden auseinander sein.
vorher nachher
Im Lauf 0,12 s -0,04 s
Wer dazukommt 6,91 s 0,26 s
Uhr des Geraets 30 s vor -29,97 s 0,26 s
DER SCHLIMMSTE FUND: DIE UHR DES TELEFONS
Der Zuschauer rechnete `Date.now() - stand.gesendet`. `gesendet` kam
vom SERVER, `Date.now()` vom Geraet -- zwei Uhren, die nie jemand
verglichen hat. Wessen Telefon dreissig Sekunden vorgeht, schaute
29,97 s weiter als alle anderen. Kein langsames Netz, kein schwaches
Handy. Oertlich faellt das nie auf: Auf einem Rechner sind beide
Uhren dieselbe.
Jetzt geht ein ALTER hinaus statt einer Uhrzeit -- die Differenz
zweier SERVERzeiten. Der Empfaenger braucht dafuer gar keine Uhr,
nur eine Stoppuhr (`performance.now()`), und die haelt Zeitumstellung
und Aufwachen aus dem Ruhezustand aus.
WEITER
* WER DAZUKOMMT, STEIGT RICHTIG EIN. Der gespeicherte Stand war so
alt wie der letzte Takt des Hosts; neue Spalte `sekunde_am` sagt,
wann er galt.
* DAS TEMPO GEHT IN DIE HOCHRECHNUNG EIN. Bei 2x laeuft die Videouhr
doppelt so schnell -- das fehlte ganz.
* JEDER RECHNET ALLE ZWEI SEKUNDEN SELBST NACH statt nur auf Zuruf.
Wer stockte, hing bis zu fuenf Sekunden hinterher.
* DER VORLAUF NACH EINEM SPRUNG WIRD GEREGELT, nicht geschaetzt --
gemessen wird der Rest, nicht die Ladezeit (siehe unten).
* PUFFERN IST AUCH IN DER TRANSPORTLEISTE KEINE PAUSE. Der
Start-Stopp-Knopf rief beim Puffern `playVideo()` -- wer Pause
drueckte, bekam „weiter". Lampe und Knopfbild flackerten bei jedem
Stocken. Die Lektion vom 29.09. war nur an einer Stelle eingeloest.
* DAS TEMPO MELDET UEBER `hostMelden()` statt ein zweites Mal von
Hand -- es hielt Puffern fuer Stillstand und hielt damit beim
Umschalten alle an.
* EIN VIDEO-RUNDRUF STATT DREI ABSCHRIFTEN. Beim Einbau hatte ich
zuerst nur eine nachgezogen; das Tauschen der beiden Videos haette
still die alte Rechnung weiterverschickt.
DREI EIGENE FEHLER UNTERWEGS, alle im Text festgehalten
1. ZWEI FUNKTIONEN HIESSEN `springen`. Meine „spring AUF die Stelle"
wurde von der vorhandenen „spring UM so viele Sekunden"
ueberschrieben -- lautlos, rueckwirkend fuer die ganze Datei. Ein
Zuschauer bei Sekunde 100, dem „geh auf 101" gesagt wird, waere
bei 201 gelandet. DREI BROWSERLAEUFE HABEN ES NICHT GEFUNDEN:
oertlich blieb der Abstand unter der Sprungschwelle, die Zeile
lief kein einziges Mal. Gefunden hat es erst eine Frage an die
ganze Datei -- die steht jetzt als Pruefung drin und wurde
nachgestellt (rot).
2. DER VORLAUF LERNTE NUR NACH OBEN. Gemessen wurde die Ladezeit
nach einem Sprung; ein Sprung in geladenes Material dauert aber
gar nicht, meldet nichts und lehrt nichts. Ergebnis: -0,95 s
stabil. Jetzt wird das ERGEBNIS geregelt statt der Ursache.
3. DER AUSREISSER VON 39,84 s WAR MEINE EIGENE MESSUNG -- der Block
davor schickt eine erfundene Position. Jetzt wird abgeklungen und
in Messreihenfolge ausgegeben.
GEPRUEFT
pruef-reaktion 421/0 (14 neue, darunter der Riegel gegen die
Rueckkehr der Uhrenrechnung und die Wache gegen doppelte
Funktionsnamen -- beide nachgestellt), mess-reaktion ohne ein
einziges ACHTUNG, pruef-buehne 38/0, pruef-struktur, pruef-
zwischenspeicher 34/0.
Schemaaenderung: ADD COLUMN sekunde_am. Datenbank vorher gesichert
und geprueft (integrity_check ok, 20 Personen).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d5c84c7608 |
Abzeichen am App-Symbol - und die Zahl gehoert zu einem Haus
Die kleine Zahl auf dem Symbol des Startbildschirms. Sie fehlte ganz; setAppBadge kam im Haus kein einziges Mal vor. ZWEI ENTSCHEIDUNGEN Sie zaehlt ungelesene Nachrichten und nichts sonst. Ein Abzeichen muss weggehen koennen: Nachrichten verschwinden, sobald man sie liest; eine ueberfaellige Aufgabe verschwindet nicht dadurch, dass man die App oeffnet. Eine Zahl, die dauerhaft dasteht, ist nach drei Tagen kein Hinweis mehr, sondern ein Fleck. Und sie hat EINE Quelle. Im Browser haengt sie an chatZahlZeigen() - der einen Stelle, an der die Zahl ohnehin gesetzt wird (beim Laden, aus dem Ereignisstrom, beim Lesen). Fuer die geschlossene App - wo das Abzeichen ueberhaupt erst etwas wert ist - reist dieselbe Zahl in der Benachrichtigung mit. Der Service Worker setzt sie nur, wenn eine dabei ist: Eine Aufgabenerinnerung mit "0" haette dem Chat sein Abzeichen weggenommen. DER FUND NEBENBEI Beim Herausloesen der Abfrage fiel auf, dass sie nie nach dem Haus gefragt hat - die Raumliste zwanzig Zeilen darueber tut es laengst. Gemessen: Eine Managerin schreibt DogFather an der Agenturwand an, sein Zaehler auf crew. springt von 0 auf 1. Seit dem 24.09. soll das nicht mehr sein. Aufgefallen ist es erst jetzt, weil dieselbe Zahl ab heute auf dem Startbildschirm steht - und eine Zahl, die etwas Falsches zeigt, ist schlimmer als keine. Behoben ueber hausWo(); die Meldung nimmt das Haus des Raums, aus dem sie stammt. GEPRUEFT server/pruef-abzeichen.mjs, 19 Messungen am echten Weg: ein nachgebauter Browser macht die Benachrichtigung mit seinem privaten Schluessel auf und liest die Zahl heraus. Mit Gegenproben - ohne Zahl kommt keine mit, NaN rutscht nicht durch, eine echte Sieben schon. Und Abschnitt 7 wird rot, sobald man die Hausregel wieder herausnimmt (nachgestellt). Zwei eigene Messfehler unterwegs, beide im Text festgehalten: eine Suche, die im Kommentar landete statt im Code (jetzt ueber jsOhneKommentar), und Aufrufe ohne Host-Feld - ueber 127.0.0.1 gibt es kein Haus, die Pruefung mass also eine Regel an einer Verbindung, die sie gar nicht kennt. helfer-push-aufmachen.mjs: das Entschluesseln stand als lokale Funktion in pruef-push-weg; zwei Abschriften waeren die, die auseinanderlaufen. Nachbarlaeufe gruen: push, push-ziel, push-weg (17 unveraendert), arten, portnummern, struktur, chat, chat-kanaele, chatkachel, anruf, haus-trennung, zwischenspeicher. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
2c12b8706e |
Highlights des Teams sind sofort zu sehen -- ohne zweiten Klick
Filipe, 30.09.2026: „wenn wir bei highlights videos rein setzen will
ich nicht mehr dass wir sie freigeben muessen, sobald die reingesetzt
wurden sollen die sofort zu sehen sein."
=====================================================================
WAS ICH NICHT GETAN HABE, UND WARUM NICHT
=====================================================================
Die naheliegende Loesung waere gewesen, `highlight` aus
`TREFF_FREIGABE_BRETTER` zu streichen. Das waere falsch: Auf diesem
Brett laedt auch die COMMUNITY hoch -- Clips, Bilder, Fanart. Im
Quelltext steht woertlich daneben:
„Zwei Schloesser, weil hier fremde Inhalte hochgeladen werden --
Urheberrecht und Anstand sind nichts, was man nachtraeglich
klaert."
Filipe meint nicht das. Er meint: „wenn WIR videos rein setzen".
=====================================================================
DIE UNTERSCHEIDUNG STAND SCHON IM HAUS -- nur nicht im Code
=====================================================================
Derselbe Quelltext sagt ueber die zwei Freigabe-Bretter
Verschiedenes:
ansteht -> der SCHALTER „Im Treff zeigen". Das Team entscheidet
JE TERMIN, ob die Community ihn sieht.
highlight -> der Urheberrechts- und Anstandsfilter.
Ein Filter fragt „hat das jemand angesehen?". Wenn der, der ihn
bedienen darf, den Eintrag SELBST anlegt, ist die Antwort ja. Genau
diese Begruendung steht seit dem Uebernehmen aus dem Katalog im
Haus: „Eine zweite daneben waere keine Sicherheit, sondern ein
Klick."
Ein Schalter dagegen ist eine Entscheidung je Fall. Termine bleiben
deshalb unberuehrt -- sonst stuende jeder interne Termin sofort im
Treff, und danach hat niemand gefragt.
Neu: `FREIGABE_IST_FILTER` und `sofortFreigeben()` in
workspace-treff.js. DIE BEDINGUNG FRAGT DIE ROLLE, NICHT DEN WEG --
waere der Weg gefragt, waere aus dem Filter ein Loch geworden, sobald
jemand einen zweiten Weg baut. Ein Community-Mitglied ab „Stamm"
darf weiterhin einstellen; sein Eintrag wartet auf das Team.
Gerufen an ZWEI Stellen: beim Videoweg und beim Anlegen von Hand.
Beide hatten es bisher nicht.
=====================================================================
DIE VORHANDENE FREIGABEPRUEFUNG BEWEIST DAS NICHT
=====================================================================
Sie blieb nach der Aenderung gruen -- und das zu Recht: Sie legt ihre
Eintraege unmittelbar in der Datenbank an und prueft damit den
Mechanismus, nicht den Weg. Haette ich mich darauf verlassen, waere
eine Aenderung ausgeliefert worden, fuer die keine Zeile spricht.
pruef-treff (+5): DogFather legt ueber den echten Weg an -> die
Community sieht es SOFORT. Ein TERMIN bleibt verborgen. Die Regel
gibt fuer eine Rolle von aussen NICHT frei und fuer Termine
ueberhaupt nicht.
pruef-video (+3): Der Videoweg hat seinen eigenen Aufruf -- genau
dort wird einer vergessen. Geprueft wird die Freigabezeile selbst,
samt Gegenprobe „freigegeben ist nur, was auch angelegt wurde".
Meinen Abschnitt hatte ich erst HINTER das Abschalten des
nachgebauten TikTok-Dienstes gehaengt -- der Kopf der Datei warnt
woertlich davor („das Abschalten steht ganz hinten"). Gelesen habe
ich ihn, als es rot wurde.
UND `pruef-struktur` HAT MEINE EIGENE NEUE ZEILE GEFANGEN: Sie bildete
das Datum aus UTC statt Ortszeit -- zwischen Mitternacht und zwei Uhr
waere es der falsche Tag gewesen. Behoben mit `tagLokal()`, Minuten
nach dem Schreiben.
Gemessen: pruef-treff 85/0 (war 80), pruef-video 74/0 (war 71),
pruef-highlights 31/0, pruef-bereiche-lesend 37/0,
pruef-treff-werkzeuge 73/0, pruef-alle-sehen-es 43/0,
pruef-community-sicht 10/0, pruef-wege-nach-draussen 67/0,
pruef-struktur 44/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|