main
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
87a3a14978 |
pruef-gifs war nicht kaputt, sondern nachts rot -- und ein Weg war ungeprüft
DIE ZWEI FEHLER AUS DEM LETZTEN LAUF WAREN KEINE FEHLER AM PRODUKT.
FEHL das GIF steht danach wirklich im Verlauf
FEHL und die Tafel geht zu -- man will sehen, wie es ankommt
Gemessen statt geraten: eine Sonde, die jede Anfrage mitschreibt. Die
Antwort stand sofort da, um 04:30 Uhr:
POST /workspace/api/chat/raeume/1/gif
403 {"fehler":"Das Rudel schläft. Ab 06:00 Uhr geht es weiter …",
"nachtruhe":{"zu":true,"ab":0,"bis":6,"minuten":90}}
Die Pruefung klickte „das erste Gespraech in der Liste". Das erste ist
der TREFF, den der Server beim Start selbst anlegt -- und im Treff gilt
die Nachtruhe von 0 bis 6 Uhr. Also: tagsueber gruen, nachts rot, seit
es diese Pruefung gibt. Es ist derselbe Fehler wie am 06.09. im Shop
(„ein Test, der die Wanduhr als Annahme benutzt, misst irgendwann das
Gegenteil") -- dort ein Oeffnungstermin, hier ein Raum mit Nachtruhe.
Warum es nie jemandem auffiel: Fuer Dogfather Universe gibt es keinen
naechtlichen Pruefdienst (nachgesehen: `systemctl list-timers` kennt nur
`vandiy-pruefung` und `runone-pruefung`). Die Pruefung lief immer nur
dann, wenn jemand sie von Hand startete -- und das war bisher nie
nachts.
WAS GEAENDERT IST
1. pruef-gifs legt ein eigenes Gespraech mit Miss an und oeffnet GENAU
DAS. Fuer ein normales Gespraech gibt es keine Nachtruhe; die Messung
gilt jetzt rund um die Uhr. Findet es den Knopf nicht, bricht es laut
ab statt still auf nichts zu klicken.
Gemessen, 04:40 Uhr:
verschicken: {"vorher":0,"nachher":1,"imVerlauf":true,
"adressen":["/workspace/api/chat/anhang/1"],
"tafelZu":true}
17 Pruefungen, 0 Fehler. Und nebenbei belegt die Adresse, was der
Quelltext behauptet: Das GIF wird KOPIERT und haengt danach als
ganz normaler Anhang an der Nachricht.
2. DIE NACHTRUHE IST NICHT UNTER DEN TISCH GEFALLEN -- sie steht jetzt
dort, wo sie hingehoert: in pruef-treffchat (110 -> 114). Dort wird
das Fenster ueber die EINSTELLUNG verschoben, nicht ueber die
Systemuhr, und beide Zustaende kommen in einem Lauf vor.
DENN DER GIF-WEG WAR DORT ALS EINZIGER DER DREI UEBERHAUPT NICHT
GEPRUEFT. Im Quelltext steht neben der Regel woertlich: „Sie nur
beim Text und beim Anhang zu pruefen hiesse, dass man nachts zwar
nicht schreiben, aber ein GIF schicken kann -- der Weg, den jeder
findet, der es einmal versucht." Genau dieser Weg hatte keine
Pruefung. Der Kommentar hat den Fehler beschrieben und nicht
verhindert -- dieselbe Luecke wie beim Spaltenverlust vom 11.09.
Gemessen, beide Zweige in einem Lauf:
Fenster 7–9 Uhr, jetzt 4 -> 404 „Dieses GIF gibt es nicht mehr."
Fenster 4–6 Uhr, jetzt 4 -> 403 „Das Rudel schläft. Ab 06:00 …"
ZWEI ENTSCHEIDUNGEN DABEI, beide mit Grund:
· Gefragt wird als DogFather, nicht als Gast. Die GIF-Kiste gehoert
dem Rudel; ein Gast bekaeme seine 403 von der falschen Schranke
(`nurRudel`) -- gruen, ohne die Nachtruhe je beruehrt zu haben.
· Mit einer Nummer, die es NICHT gibt. Kommt trotzdem die
Nachtruhe-Absage, steht die Schranke VOR dem Nachschlagen.
Stuende sie dahinter, verriete der Server nachts an der Nummer,
welche GIFs es gibt.
AM PRODUKT IST NICHTS GEAENDERT. Nur zwei Pruefdateien -- kein Stempel,
kein Neustart noetig.
GEPRUEFT: pruef-gifs 17 ok (vorher 15 ok / 2 FEHL) ·
pruef-treffchat 114 ok (vorher 110).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e8a5d7bc7e |
pruef-glocke: drei Viertel der Pruefung sind nie gelaufen
8 Pruefungen standen am Ende da. Jetzt sind es 36.
SCHRITT FUER SCHRITT NACHGEMESSEN, statt der Meldung zu glauben:
1. Drei von acht Rollen scheiterten mit „Zeitsperre nach 25 s"
beim Warten auf start.html -- hand, linke, modi. Danach brach
die Datei ab; alles dahinter lief nie.
2. Nicht an der Last: allein dasselbe Bild.
3. Was antwortet die Anmeldung im Browser? 401 ungueltig.
4. Dieselbe Anmeldung ueber die Schnittstelle, am SELBEN laufenden
Server: 200. Es lag also nie am Server.
5. Der Unterschied ist die KACHEL. Es gibt zwei Anmeldeseiten:
workspace/index.html spicy, admin, manager, scout, creator
workspace/crew-index.html admin, hand, linke, modi, gast
Auf 127.0.0.1 kommt die Agenturseite.
KEIN FEHLER AM PRODUKT. Der Server ist auf einer Pruefadresse
absichtlich grosszuegig, damit Pruefungen alles testen koennen (das
steht so im Quelltext); die zwei Seiten sind die Trennung der zwei
Haeuser.
DER FEHLER WAR EIN NOTNAGEL IN DER PRUEFUNG:
const kachel = await seite.$(`.rolle[data-rolle="${rolle}"]`)
|| await seite.$(".rolle");
Er sollte verhindern, dass ein Klick auf eine fehlende Kachel
abbricht. Seit die Kachel am 30.09. BINDEND ist (`718b267d`, auf
Filipes Wunsch), macht er aus „diese Kachel gibt es hier nicht"
etwas Schlimmeres: Er klickt irgendeine, der Server weist zu Recht
ab, und heraus kommt eine Zeitsperre nach 25 Sekunden, die wie ein
Fehler an der Glocke aussieht.
EIN NOTNAGEL, DER STILL DAS FALSCHE GREIFT, IST SCHLIMMER ALS EIN
LAUTER ABBRUCH. Jetzt wird die richtige Seite PROBIERT (nicht aus
einer Liste von Crew-Rollen gelesen -- die waere die naechste, die
beim sechsten Eintrag nicht mitwaechst), und findet sich die Kachel
auf keiner der beiden, bricht es mit Namen ab und zeigt, welche
Kacheln dastehen.
DAS IST HEUTE DER ZWEITE FALL DERSELBEN WURZEL. Bei
pruef-crew-wand-bild war es dieselbe Folgewirkung der bindenden
Kachel, nur sichtbarer. Nach jener Aenderung bin ich die Pruefungen
zum Zugang gelaufen und nicht die, die nebenbei eine Anmeldung
brauchen.
DENSELBEN NOTNAGEL GIBT ES NOCH EINMAL, in pruef-gifs. Dort zielt er
auf `creator`, und die Kachel steht auf der Agenturseite -- er
greift heute nie. Das ist Glueck und kein Entwurf, also ist er auch
dort weg.
GEPRUEFT: pruef-glocke 8 -> 36 Pruefungen, 0 Fehler, alle acht
Rollen. pruef-gifs 17 Pruefungen, 0 Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
24523cdd4b |
Die GIF-Kiste ist fertig – eine Prüfung sagt es jetzt auch
Filipe: „mach das mit den gifs auch fertig."
ERGEBNIS: SIE WAR ES SCHON. Hineinlegen, Kiste anzeigen, verschicken,
herausnehmen, Duplikat-Erkennung am Inhalt, Fortschrittsanzeige mit
Abbruch, Standbild bei „Bewegung reduzieren" -- alles vorhanden, alles
live, und pruef-chat-anhaenge deckt die Wege ab.
SECHS „BEFUNDE" MEINES ERSTEN LAUFS WAREN ALLE MESSFEHLER:
* zu frueh gemessen (`darf_gif` kommt mit den Raumdaten; der Knopf
wird erst danach freigeschaltet)
* kein Content-Type gesetzt -> „Keine Datei empfangen"
* Selektor `.chat-raum` erfunden; die Klasse heisst
`chat-raum__knopf`
* nach `title*='ausnehm'` gesucht; der Knopf heisst „Aus der Kiste
nehmen" und hat die Klasse `gif-kachel__weg`
* `x-name` geschickt; der Server liest `x-dateiname`
* nach einer GIF-Adresse im Verlauf gesucht -- das GIF wird beim
Verschicken KOPIERT und haengt danach als Anhang
* und einmal `curl` auf chat.html ohne Anmeldung: eine Umleitung,
null Treffer, und ich hielt die Tafel fuer nicht ausgeliefert
Ich haette beinahe gebaut, was es laengst gibt -- wie heute frueh beim
Farbwerkzeug. Der Unterschied: Diesmal habe ich vor dem Bauen
nachgesehen.
WAS BLEIBT, IST DIE PRUEFUNG. pruef-chat-anhaenge prueft die WEGE;
ungeprueft war die OBERFLAECHE -- dass der Knopf fuer Team Dogi
erscheint und fuer einen Creator nicht, dass die Tafel aufgeht, dass
an jeder Kachel ein Weg zum Herausnehmen steht, dass ein verschicktes
GIF wirklich im Verlauf landet. Genau dort haette ich gebaut, was es
schon gibt. 17 Pruefungen, 0 Fehler.
=== Und der Durchgang durch die Pruefungen (erster Teil) ===
Gesucht nach dem Muster, das heute fuenfmal zugeschlagen hat:
abgeschriebene Listen. Gefunden: pruef-buehne kennt 19 von 38 Seiten,
pruef-workspace-seiten 18 -- je VIERZEHN mit Kopfzeile und damit
ungeprueft. support.html fehlt in beiden; sie ist heute entstanden.
In pruef-workspace-seiten steht die Lehre woertlich im Kopf: „Eine
Pruefung, die eine Seite nicht kennt, kann auf ihr nichts finden."
Ein Probelauf mit abgeleiteter Liste: 30 statt 18 Seiten, 28 rot --
24 davon, weil die Seite gar kein `data-buehne` traegt. Das ist eine
Gestaltungsfrage (welche Szene wohin), keine Reparatur. DIE
ERWEITERUNG IST DESHALB WIEDER DRAUSSEN: Eine Pruefung, die ab sofort
dauerhaft rot ist, wird ab dem zweiten Mal ueberlesen -- und dann auch
die echte Meldung.
Nebenbefund mit Gegenprobe belegt: `aufgaben.html` ist 1560 px breit
statt 1240 (verursacht von BUTTON.schnitt) -- und war das schon VOR
meiner Aenderung. Die fuenfte bestehende rote Pruefung an diesem Tag.
Beides steht in der Vault-Notiz zum Entscheiden.
Co-Authored-By: Claude Opus 5 <[email protected]>
|