a1c2d492602fea3d24af8d50b598d1a5c9deaa1f
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  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
|
d2f02ba84e |
Spenden: Stufen gestaltbar, Bild hochladen, Größe je Stufe
Filipes Wunsch: „mach paar fertige und so dass ich auch hochladen
kann. auch so dass ich das anders gestalten kann oder die größe
verändern kann. ... auch spezielle sachen bei speziellen spenden."
WAS ES SCHON GAB, WAS FEHLTE
Drei Stufen ab Werk, fünf gezeichnete Zeichen, Farbe und Dauer je
Stufe — und sogar schon ein Feld für ein eigenes Bild. Es fehlte der
Weg, das alles zu ÄNDERN: Um eine Stufe umzubenennen, hätte jemand in
die Datenbank greifen müssen.
DIE GRÖSSE IST DAS „SPEZIELLE BEI SPEZIELLEN SPENDEN"
Je Stufe, nicht einmal für alle: Eine Rudel-Legende darf größer
dastehen als ein Danke. Eine einzige Größe für alle wäre wieder eine
Preisliste. Umgesetzt als EINE Schriftgröße, alles darin in `em` —
nicht `transform: scale()`, denn die Karte kommt schon mit
`translateX()` herein, und zwei `transform` an derselben Stelle
schließen einander aus; außerdem wird Text beim Skalieren matschig.
Nur nach oben (1 bis 2,5), und das ist eine ehrliche Grenze: Das
kleinste Wort auf der Karte steht bei 11,52 px, die Hausgrenze ist
11,5. Ein Faktor von 0,8 machte daraus 9,2 px. Kleiner geht an der
richtigen Stelle — die OBS-Tafel hat ihren eigenen Regler in der
Adresse, dort ist es eine Videoeinblendung und kein Text zum Lesen.
AUSPROBIEREN, OHNE EINE SPENDE ANZULEGEN
Der naheliegende Weg wäre gewesen: eine Spende eintragen und danach
löschen. Das ist verboten — in ein laufendes System kommen keine
Testdaten, und „gelöscht" heißt bei Geld nicht „war nie da". Die
Probe schreibt deshalb NICHTS und geht nur an den, der drückt; eine
Probe im ganzen Saal wäre eine Spende, die es nicht gab.
DREI FEHLER, DIE DIE PRÜFUNG GEFUNDEN HAT
1. `protokolliere()` wurde an 17 Stellen falsch herum gerufen —
`(personId, aktion, detail, ip)` statt `(aktion, {…})`. JavaScript
beschwert sich nicht: Das zweite Argument war ein Text, und einen
Text zu zerlegen ergibt lauter `undefined`. Auf dem echten Server
nachgemessen: 39 Protokollzeilen mit Aktionen wie „16.0", alle
ohne Person, ohne Detail, ohne IP. Betroffen waren Material,
Hilfe, Bühne, Reaction und Spenden — also jede Änderung an
Dogi-Media und jede Maßnahme im Live-Chat, ausgerechnet das,
wofür es ein Protokoll gibt. Alle 17 berichtigt, und
pruef-struktur wacht jetzt darüber (mit Gegenprobe).
2. Beim Speichern der Leiter bekam jede Stufe eine NEUE Kennung
(DELETE + INSERT). Ein Bild-Hochladen gegen die eben noch gültige
Kennung antwortete mit 404 — im Alltag trifft das jeden, der einen
zweiten Bildschirm offen hat. Jetzt werden vorhandene Zeilen
geändert statt ersetzt; das Bild bleibt von selbst daran hängen.
3. `ab_cent` ist eindeutig. Zwei Stufen ihre Beträge tauschen zu
lassen scheiterte mit „UNIQUE constraint failed", obwohl das
Ergebnis in Ordnung gewesen wäre: Beim Umschreiben stößt die
Leiter auf sich selbst. Jetzt in drei Schritten — löschen,
geparkte Zwischenwerte, endgültige Werte —, und das ist nach
außen nie sichtbar.
UND DREI, DIE IN MEINER MESSUNG STECKTEN
Die Messung hat eine noch laufende Karte aus dem vorigen Abschnitt
erwischt und daraus drei Fehler gemeldet, die keine waren —
darunter „die Probe läuft im ganzen Saal". Sie zählte außerdem die
versteckten Dateifelder als zu kleine Tippziele. Jetzt räumt sie
vorher auf, wartet auf die Karte MIT DER ERWARTETEN GRÖSSE (die
Karten laufen in einer Schlange — einen Knoten zu entfernen beendet
sie nicht) und lässt die Einblendung zur Ruhe kommen, bevor sie misst.
Ein Bildschirmfoto aus der Einblendphase sah aus, als stünde die
Karte links heraus; nachgemessen: links 18 px, ganz im Bild.
GEMESSEN, NICHT ANGENOMMEN
Karte bei Größe 1: Schrift 16 px, Betrag 25,92 px. Bei Größe 2:
32 px und 51,84 px — Faktor exakt 2,00. Hätte eine einzige Regel noch
in `rem` gestanden, wäre die Karte ungleichmäßig gewachsen, und auf
einem Bild sieht beides nur „größer" aus.
AUCH DAS BILD IST GEPRÜFT
Es liegt am Bühnen-Router und nicht am Spenden-Router: Die
Spendentafel in OBS hat keine Anmeldung, und ein 401 als JSON in
einem `<img>` ergibt ein kaputtes Bild ohne jeden Hinweis. Ohne
Schlüssel, aber mit 128 Bit zufälligem Dateinamen — dieselbe
Größenordnung wie der Bühnenschlüssel, und es ist ein Zierbild, das
ohnehin im Stream steht. Kein Ausbruch aus dem Ordner (vier Wege
geprüft, gemessen wird die Wirkung und nicht der Statuscode).
NACHGETRAGEN AUS BLOCK 4
`reaktion_meldungen` fehlte im Löschkonzept — eine bestehende Prüfung
hat es gefunden. 30 Tage nach dem Erledigen; meistens sind sie
ohnehin früher weg, weil der Live-Chat beim Beenden gelöscht wird und
die Meldungen daran hängen. Wer meldet, muss sich darauf verlassen
können, dass daraus keine dauerhafte Liste wird.
GEPRUEFT
pruef-spenden: 95 Prüfungen (vorher 46), 0 Fehler.
pruef-reaktion 260, pruef-buehne 36, pruef-aufbewahrung 45,
pruef-struktur, pruef-meldungen, pruef-css-klassen, pruef-tippziele,
pruef-deutsche-texte, pruef-auskunft alle grün.
mess-reaktion und mess-buehne: Rückgabewert 0, kein ACHTUNG.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e5cd016b60 |
Aus jedem Fenster kommt man heraus, die Kachel dreht sich, der Eingang sieht aus wie das Haus
VIER DINGE, und das erste ist eine Meldung aus dem Support.
1. MISS KAM AUS "AUFGABE BEARBEITEN" NICHT HERAUS.
„Ich konnte da wieder nicht zurück gehen, musste die App schließen
damit ich wieder auf die Hauptseite kam."
Gemessen (mess-dialog-ausgang.mjs), vier Größen:
412x915 App 782 px Inhalt in 784 px -- knapp ja
412x780 Browser 782 px Inhalt in 742 px -- SACKGASSE
360x640 klein 794 px Inhalt in 602 px -- SACKGASSE
412x430 Tastatur 794 px Inhalt in 392 px -- SACKGASSE
`.dialog` hatte `overflow: hidden`, eine Scroll-Höhe gab es NUR für
`.dialog--breit`. Alles unterhalb des Rands wurde abgeschnitten --
samt "Abbrechen". Jetzt rollt JEDES Fenster, und Kopf wie Knopfzeile
bleiben stehen (`position: sticky`), damit man den Ausgang SIEHT,
ohne erst durch acht Felder zu scrollen. Alle vier Größen: ja.
2. DIE VORLAGENKACHEL DREHT SICH.
„wenn ich drauf drücke dreht sich die kachel und dan seh ich wer es
gemacht hat, und immer noch die option es nochmal zu verteilen falls
neue leute ins team zustoßen."
Vorne bleibt die Kurzfassung ("liegt bei 3 von 4"), hinten stehen
die Namen mit ihrem Stand und zwei Knöpfe: "Nachholen – 1 fehlt"
(oder "Nochmal an alle", wenn wirklich alle sie haben) und "Zurück".
Nach dem Verteilen dreht sie sich von selbst; wer nur nachsehen
will, drückt "Wer hat sie?".
3. DER EINGANG SIEHT AUS WIE DAS HAUS.
Fase und Leuchtschiene statt flachem Kasten, die Schiene in der
Farbe des Stands. Die drei Zahlen werden drei Felder -- und die
"0 neu" leuchtet nicht mehr rot: Eine Warnung, die immer kommt, ist
keine Warnung. Ab 760 px steht das Bild neben dem Text statt
darunter; die Karte war dadurch dreimal so hoch wie nötig.
4. DER CREATOR-KATALOG IST AUF DER TEAM-SEITE WEG.
„es gibt keine creator auf dieser seite" -- dort stand "Wähle oben
einen Creator", eine Aufforderung zu etwas Unmöglichem. Gefragt wird
jetzt nach den Daten (gibt es jemanden, dem ich das geben kann?),
nicht nach der Adresse.
DAZU FERTIG GEMACHT, WAS VON GESTERN OFFEN WAR:
* Die zwei Serien ohne Haus ("Community-Call", "Schulung-Agentur").
Ursache war meine eigene Abschrift: Bei den Terminen frage ich die
Teilnehmerliste, bei den Serien hatte ich sie vergessen. Auf einer
Kopie der echten Datenbank: 0 offene Zeilen.
* Sieben Schreibwege setzen jetzt `haus` (Aufgaben, Einträge,
Dateien, Material, Wissen, Video-Titelbild). Dabei gefunden:
`material` verwaltet seine Spalten SELBST -- meine Spalte stand in
der falschen Liste und fehlte auf einer frischen Datenbank
(78 Fehlschläge in pruef-material, jetzt 159/0).
* unterstuetzen.html lud meldung.js gar nicht -- dort stand das
Maschinenwort des Servers statt eines Satzes (pruef-meldungen 8/0).
DREI VERALTETE PRÜFUNGEN NACHGEZOGEN, jede STRENGER als vorher:
* "der Modi legt eine Aufgabe an (201)" -- seit dem 22.09. ist das
403 und gewollt. Geprüft wird jetzt auch das WORT.
* "calls.html ist verboten" -- Filipe hat die Kachel selbst verlangt
("jeder der einen kalender hat"). Mit Gegenprobe ersetzt.
* "Review" heißt seit dem 20.09. "Zur Freigabe". Der Name wird jetzt
aus STATUS_NAME GELESEN statt abgeschrieben.
GEPRÜFT: modi-katalog 150/0 (war 144), modi-verborgen 85/0 (war 80/2),
haus-trennung 97/0, material 159/0, meldungen 8/0, abbrechen-optik 0
Fehler. Dazu grün: an-alle, vorlagen, support, css-klassen,
aufgabenbrett, aufgaben-vorlagen, unterstuetzung, formulare, loeschen,
nachfrage, kalender, chat, leerzustand.
OFFEN UND NICHT ANGEFASST: pruef-breiten meldet auf report.html ein
Berührziel von 27x18 px. Der Link (`class="zurueck"`) ist auf 30
Seiten derselbe und hat gar keinen eigenen Stil; beanstandet wird nur
diese eine Seite, weil dort hinter ihm nur "· Review" steht und die
Prüfung Fließtext-Links erst ab 12 Zeichen Umgebung ausnimmt. Eine
Klasse auf 30 Seiten ohne Prüflauf zu ändern wäre geraten.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
774eeee3e5 |
Die Umstellung von Dogi-Media merkt jetzt, wenn sie nicht durchkam
BEIM AUSLIEFERN AUFGEFALLEN, NICHT BEIM BAUEN. Nach Neustart und `git pull` standen die zwei neuen Spalten noch nicht in der echten Ablage -- die Umstellung laeuft erst beim ersten angemeldeten Zugriff. Das ist in Ordnung. Beim Nachsehen, WARUM sie noch nicht da waren, fiel aber der eigentliche Mangel auf: `bereit = true` stand UNBEDINGT hinter der Schleife, und der Fehler des `ALTER TABLE` daneben ging still in die Konsole. Ein einziger misslungener Versuch -- Datei gesperrt, Platte voll -- haette die Umstellung damit fuer immer als erledigt vermerkt. Danach scheitert JEDE Liste an `SELECT ... m.gilt_ab`, und zwar fuer alle, mit einem 503 und dem Satz "gerade nicht verfuegbar", der nirgends sagt, woran es liegt. Bis zum naechsten Neustart. Jetzt wird nach der Schleife nachgezaehlt. Fehlt etwas, wird geworfen statt notiert, und der Vermerk bleibt aus -- der naechste Aufruf versucht es also wieder. Ein Aufruf, der mit einer klaren Meldung scheitert, ist besser als hundert, die raetseln. AUF EINER KOPIE DURCHGESPIELT, nicht an den echten Daten erlebt: Sicherung der laufenden Ablage gezogen (`.backup`, integrity_check ok, Zeilenzahlen gegen live geprueft), darauf beide ALTER ausgefuehrt. Die vorhandene Zeile ueberlebt mit leerem Fenster, die Listenabfrage des Servers laeuft wortgleich durch, integrity_check danach ok. pruef-material 159/0 (von 155). Neu ist eine Gegenprobe, die den halb-umgestellten Zustand herstellt -- genau den, der vorher "erledigt" geheissen haette -- und eine Zeile, die die Spalten in der laufenden Ablage nachzaehlt statt sie anzunehmen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
fc823240ab |
screen4: Dogi-Media — bearbeiten, entfernen, von wann bis wann
Filipe, 22.09.2026: "wenn wir in der kategorie material was hochladen
will ich dass die rechte und linke hand es auch bearbeiten und loeschen
koennen. dogfather auch fals es ein fehler gab. ... uebrigens ersetz das
wort material durch Dogi-Media. und mach kategorien welche sind benutzt
welche nicht welche sind noch offen, welche laufen von wan bis wann."
WAS JETZT GEHT
- Rechte Hand, linke Hand und DogFather bearbeiten und entfernen jedes
Stueck, nicht nur ihr eigenes. Bearbeitet wird Text und Zeitfenster,
nicht die Datei: Sonst zeigte dieselbe Nummer etwas anderes als das,
was sich jemand gerade angesehen hat.
- Ein vergebenes Stueck bleibt unberuehrt (409). Wer es genommen hat,
hat sich auf diesen Text verlassen.
- Vier Zustaende, gerechnet statt gespeichert: jetzt frei, kommt noch,
abgelaufen, schon benutzt. Die Kategorieleiste zeigt zu jedem die
Anzahl aus den echten Daten und filtert BEIDE Listen.
- "Material" heisst ueberall "Dogi-Media", der Dateiname bleibt.
DREI FEHLER AUS DEM EIGENEN ENTWURF, ALLE VOR DEM AUSLIEFERN GEMESSEN
1. `tagLokal()` ohne Argument gab "NaN-NaN-NaN" zurueck -- eine
Zeichenkette, die aussieht wie ein Datum. Im Vergleich gewinnt das N
gegen jede Ziffer, also galt JEDES Stueck mit Enddatum vom ersten Tag
an als abgelaufen, und "Kommt noch" gab es nie. Kein Absturz, keine
Meldung. Die drei Kopien der Funktion waren hier auseinandergelaufen;
alle drei haben jetzt die Vorbelegung und werfen bei einer Zahl, die
keine ist.
2. `frageNach` liefert bei einer reinen Rueckfrage `true`, nicht
`{ ok: true }`. Der Entwurf prueft auf `erg?.ok` -- "Entfernen" waere
ein Knopf gewesen, der nichts tut.
3. Drei erfundene Klassennamen (`knopf--leise`, `m-kat__knopf`,
`m-karte__weg-knopf`) statt der vorhandenen des Hauses. Jetzt
`.knopf-still`, `.knopf-still--warn` und die Filterleiste `.filter`.
EIN FUND IM BESTAND, ZWEI WOCHEN ALT
In start.css fehlten an einer Stelle die zwei Zeichen, die einen
Kommentar schliessen. CSS-Kommentare schachteln nicht: Der Block lief
bis zum naechsten Abschluss weiter und verschluckte `.kacheln {`; die
Fehlerbehebung des Browsers nahm danach auch die Regel `.kachel` mit.
In Chromium gemessen, beide Fassungen nacheinander: 738 statt 740
Regeln.
Der Entwurf, der dadurch nie gewirkt hat, ist NICHT wiederhergestellt
worden: Seine Flaeche mischte den Kachelton mit 30/11/3 Prozent ein --
pruef-kachelfarben fiel sofort von 36,5 % auf 4,1 % angekommene Farbe,
und 31 Toene sahen gleich aus. Das ist das Gegenteil dessen, was am
22.09. verlangt war. Er ist geloescht, mit dem Grund daneben. Offen
bleibt eine Frage an Filipe, keine Entscheidung von mir: zu demselben
Entwurf gehoerte ein schmaleres Kachelraster (fuenf bis sechs statt
drei pro Reihe). Das aendert das Aussehen der Startseite sichtbar und
bleibt deshalb, wie es ist.
GEMEINSAME BAUSTEINE AUS DEN SEITENDATEIEN GEHOLT
`.filter` stand Zeichen fuer Zeichen doppelt in dateien.css und
bereich.css, `.feld-hinweis` in aufgaben.css und leistung.css (und die
zwei waren schon auseinandergelaufen). Dogi-Media war jeweils die
dritte Seite, die sie braucht, und laedt keine davon. Derselbe Fehler
wie damals bei .knopf-still und beim Schalter -- jetzt in gate.css
bzw. start.css.
GEPRUEFT
pruef-material 155/0 (von 126, neu: Zeitfenster, Bearbeiten, Entfernen,
Rechte in der Liste und ein Abschnitt am echten Bildschirm mit Browser).
pruef-css-klassen um eine Pruefung erweitert, die genau den
start.css-Fehler findet -- mit sieben Gegenproben, darunter der echte
Fall. pruef-kachelfarben 22/0, pruef-start-ansicht, pruef-struktur,
pruef-meldungen, pruef-zeitraum, pruef-content, pruef-serien 69/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
06f3fecaa7 |
Material: Bilder und Videos zum Posten, jedes nur einmal
Filipe, 22.09.2026: "ich brauch auch noch eine neue kachel im bereich
community, wo wir als team ... bilder reinschicken koennen, mit text
und wo die leute sei es community oder modis sich die bilder nehmen
koennen zum posten. die community soll keine posten koennen ... sobald
ein bild oder ein video ... runtergeladen wurde, soll direkt blockiert
werden ... damit nie ein bild zwei mal gepostet wird ... und die rechte
hand und dogfather, nur die beiden sollen auch immer sehen koennen wer
das bild oder video runtergeladen hat."
DER KERN IST DIE EINMALIGKEIT, und deshalb sind Nehmen und Laden ZWEI
Schritte. "nehmen" schreibt in EINER Abfrage fest, wer es hat -- mit
`WHERE genommen_von IS NULL` in der Bedingung. Wer zu spaet kommt,
aendert null Zeilen und bekommt 409. Ein einziger Schritt ("laden und
dabei markieren") haette dieselbe Luecke wie ein Pool ohne Sperre:
zwei Anfragen, beide sehen "frei", beide laden.
UND DIE SPERRE GILT AUCH FUER DIE VORSCHAU. Waere sie offen
geblieben, waere sie der Weg, ein vergebenes Bild doch noch zu
bekommen (Rechtsklick, speichern) -- und die ganze Einmaligkeit eine
Behauptung. Ausnahme: wer es selbst genommen hat, sieht es weiter.
WER WEN SIEHT, entscheidet der Server, nicht die Seite. Fuer alle
ausser DogFather und der rechten Hand fehlt das Feld `genommen_von`
ganz -- nicht `null`: Ein Feld, das da ist und leer bleibt, laedt
dazu ein, es spaeter "zu fuellen".
pruef-material.mjs (70 Pruefungen, 0 Fehler) misst den ganzen Weg,
mit Gegenprobe zu jeder Grenze. Die Zahl der vergebenen Stuecke steht
in der BEDINGUNG -- ohne sie waere "keine Namen dabei" trivial wahr.
DREI DINGE HAT ERST DER BLICK MIT ECHTEN AUGEN GEFUNDEN
(tools/material-blick.mjs, drei Rollen, vier Bildschirmbreiten):
* "hat es genommen am 22.09.." -- eine deutsche Datumsangabe endet
selbst auf einen Punkt. Kein Pruefprogramm haette danach gefragt.
* Die Knoepfe standen auf drei verschiedenen Hoehen (1127, 1155,
1176), weil der eine Text zwei Zeilen hatte und der naechste
keine. `margin-top: auto` am Fuss statt einer geratenen
Mindesthoehe.
* "Schon benutzt" nahm 273 px Hoehe je Stueck fuer ein einziges
Zeichen -- das Bild ist dort ohnehin nicht mehr abrufbar. Jetzt
eine Zeile mit 96 px.
Am Handy (412 px) blieb es bei EINER Spalte: 3062 px Seitenhoehe fuer
fuenf Stuecke. Filipe: "es ist alles so lang gezogen, muss ewig
scrollen". Statt einer festen Umbruchschwelle -- die am 06.09. schon
zweimal teuer war -- waechst die Spaltenbreite jetzt mit:
`max(160px, 22%)`. Gemessen 360/412/768/1500 px: 2/2/3/3 Spalten,
nirgends ein Ueberlauf, 412 px jetzt 2014 statt 3062 px.
Dazu neun Saetze in meldung.js. Der wichtigste ist "schon_genommen",
und er ist bewusst kein Fehler: Wer ihn liest, hat nichts falsch
gemacht. pruef-meldungen fand dabei einen Rest aus dem Aufgaben-Block
-- `nur_leitung_legt_an` hatte keinen Satz, ein Modi mit altem Tab
haette rohen Maschinentext gelesen.
pruef-material 70/0 · pruef-meldungen 8/0 · pruef-treff 80/0
pruef-rechtetafel 19/0 · pruef-sackgassen 13/0 · pruef-css-klassen ok
pruef-zwischenspeicher 27/0
Co-Authored-By: Claude Opus 5 <[email protected]>
|