4c08c8859d1ddf11ad30bf71b1aa9bdfd99508a5
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  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
|
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
|
257c01b8f0 |
Support: Babyblau mit Lila, und der Melder bekommt seine Knoepfe wirklich
Nachtrag zu
|
||
|
DogFatherGitandClaude Opus 5
|
cebdd88e8d |
Support: der Melder hat das letzte Wort -- und die Kachel bekommt ihren eigenen Stil
Filipe: "ich will dass die leute die mir was geschickt haben im support, auch meine notiz bekommen wenn ich fertig bin. damit die bescheid wissen und dan anklicken koennen, es funktioniert, oder noch nicht. und erst wenn es funktioniert gedrueckt wird, will ich dass alles richtig fertig ist. perfektionier den ganzen weg und mit dem gedanken das manchmal sachen mehrmal nicht sofort perfekt sein werden." DER GANZE WEG, nicht nur der Schlusspunkt: 1. Die Leitung drueckt "Behoben - nachfragen ...". Der Knopf hiess vorher "Erledigt ..." und tat auch das; jetzt stellt er eine Frage, also heisst er auch so. Eine Beschriftung, die etwas anderes sagt als der Knopf tut, glaubt man genau einmal. 2. Die Meldung steht auf "wartet" -- ein vierter Stand zwischen "wird bearbeitet" und "erledigt". Beim Melder heisst er "geht es wieder?", weil er aus SEINER Sicht keine Wartezeit ist, sondern eine Frage. 3. Er sieht die Notiz und zwei Knoepfe. "Geht wieder" ohne Rueckfrage (der haeufige, harmlose Fall). "Noch nicht" verlangt ein Wort -- sonst faengt die Suche von vorn an und die naechste Runde waere dieselbe wie die letzte. 4. "Noch nicht" ist keine Beschwerde, sondern Runde 2: zurueck in Arbeit, Rundenzahl plus eins, Leitung bekommt eine Nachricht, und der Verlauf behaelt, was beim letzten Mal versucht wurde. Niemand faengt von vorn an -- genau der Fall, den Filipe genannt hat. 5. Erst sein "Geht wieder" schliesst die Meldung. Danach kann weder er noch die Leitung sie wieder aufmachen (409). NUR DER MELDER darf bestaetigen, ausdruecklich nicht die Leitung (`person_id !== req.person.id`, nicht "ist Leitung") -- sonst nickt sie ihre eigene Arbeit ab und der ganze Umweg waere Zierde. Eine fremde Meldung gibt 404, nicht 403: Wer sie nicht sehen darf, soll auch nicht erfahren, dass es sie gibt. DER VERLAUF STEHT UNTEREINANDER statt nur der letzten Antwort. Bei Runde drei war sonst nicht mehr zu sehen, was beim ersten Mal versucht wurde, und genau das loest einen wiederkehrenden Fehler. Meldungen von vor diesem Umbau haben keinen Verlauf -- die zeigen wie bisher ihre blosse Antwort, ein leerer Kasten waere schlechter als der alte Satz. DIE KACHEL SIEHT ANDERS AUS (zweiter Wunsch: "viel geiler viel profissioneller ... die hauptfarbe soll babyblau sein mit bissl lila"). `support-seite` traegt den Stil; alle Regeln haengen daran und gelten damit nur hier. Zwei weiche Lichter, Pillen statt Kaesten als Filter, eine leuchtende Naht ueber dem Meldefeld. Augenschonend: gedeckt, kein Neon, Kontrast geprueft. GEMESSEN: - pruef-support: 45 -> 58 Pruefungen, 0 Fehler. Der ganze Weg einmal durch, MIT einer Runde, die schiefgeht. Dazu drei Gegenproben: die Leitung kann nicht fuer den Melder bestaetigen (404), "noch nicht" ohne Wort wird abgelehnt (400), eine geschlossene Meldung bleibt zu (409, aus beiden Richtungen). - Die Schemaaenderung auf einer KOPIE der echten Datenbank durchgespielt: 72 Tabellen, keine Zeile und keine Spalte verloren, support_runden und `runde` da, 'wartet' in der CHECK-Regel. - pruef-css-klassen, pruef-deutsche-texte, pruef-code, pruef-glocke: alle gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
1d41e29bf7 |
Drei weitere Prüfungen, die das Falsche prüften
Der Durchgang, zweiter Teil. Gesucht nach dem schaerfsten Filter, den es dafuer gibt: dem VERSPRECHEN GEGEN DIE WIRKLICHKEIT -- Pruefsaetze, die „jede Rolle" oder „jede Seite" sagen. Genau so ist pruef-glocke heute frueh aufgefallen. 1. pruef-workspace-seiten meldete aufgaben.html als „Breite 1560px". KEIN FEHLER: Die Seite traegt zusaetzlich `.inhalt--brett`, und die setzt ausdruecklich 1560 px -- mit Begruendung in aufgaben.css („ein Brett darf breiter sein als Text, der Kopfbereich bleibt lesbar schmal"). Die Pruefung verglich starr mit 1240 und kannte die Klasse nicht; sie meldete damit eine Absicht als Fehler, seit dem Tag, an dem die Klasse entstand. Mit Gegenprobe belegt: schon vor allen Aenderungen von heute rot. Jetzt kommt die erwartete Breite aus den KLASSEN des Elements. Beide Zahlen bleiben stehen, weil sie etwas aussagen -- kommt weder 1240 noch 1560 an, ist die Regel verloren. 2. pruef-meldungen meldete „ohne Satz: ungueltiger_stand". Zuerst ein ECHTER Fehler, und zwar meiner vom selben Tag: In workspace-support.js stand eine nackte Kennung statt eines Satzes. Behoben -- und danach meldete die Pruefung sie WEITER, weil sie das Zitat im Kommentar las, der die Behebung begruendet. Dieselbe Falle wie ein Grep ueber eine Datei, die ihre eigene Geschichte enthaelt; mir ist sie heute schon einmal passiert. Eine Pruefung, die verbietet, ueber einen behobenen Fehler zu SCHREIBEN, erzieht dazu, die Begruendung wegzulassen. Kommentare zaehlen jetzt nicht mehr; Adressen mit // in Zeichenketten bleiben unberuehrt. 3. pruef-auskunft meldete „NICHT EINGEORDNET: vorlagen_bewerbungen.aufgabe_id". ECHT: Die Spalte zeigt auf eine Aufgabe, nicht auf einen Menschen, und stand in keiner der beiden Listen. Das ist mehr als Ordnungsliebe -- bei einer Auskunftsanfrage muss das Haus sagen koennen, welche Spalten auf eine Person zeigen. Eine unbekannte Spalte ist eine, bei der niemand weiss, ob sie mitgehoert. ZWISCHENSTAND: ACHT Pruefungen an einem Tag, die rot waren oder das Falsche prueften. Das Muster ist immer dasselbe -- eine Liste oder Zahl, die zum Zeitpunkt des Schreibens stimmte. Sie wird nicht falsch, sie wird unzustaendig. Gruen: pruef-meldungen (8), pruef-auskunft (46), pruef-workspace-seiten, pruef-support (45), pruef-vorlagen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
9f5dbb42e3 |
Support: melden mit Bild, und für die Leitung ein Eingang
Filipe: „da fehlt auch eine support kachel. die jeder sieht. jeder
benutzen kann. jeder kann da probleme von der seite melden und
hinweisen. fotos mit schicken mit einem text. … so einfach wie
möglich, will nichts kompliziertes oder zu viel. kurz und knapp …
bei dogfather und der rechten hand soll die kachel anders gebaut sein
weil die sind die die sich um die probleme kümmern."
WARUM DAS NICHT DER VORHANDENE MELDEWEG IST. Es gibt ihn schon
(hilfe.html) und er sieht aehnlich aus. Drei Unterschiede machen ihn
zu etwas anderem:
1. Er ist NICHT fuer alle -- in rechte.js steht
`["gast","hand","admin"]`. Modis, Creator, Scouts, Manager und
die linke Hand hatten gar keinen Weg, einen kaputten Knopf zu
melden.
2. Er kann keine Bilder. Bei „der Knopf tut nichts" ist ein
Bildschirmfoto die halbe Antwort.
3. Er ist bewusst schwer: strikter Wechsel, hoechstens drei offene
Faelle, ein Betreff. Richtig bei einem Vorfall zwischen
Menschen, zu viel fuer „das Datum steht falsch da".
Deshalb eigen und sehr kurz: EIN Feld, EIN Bild, fertig. Kein
Betreff, keine Kategorie, keine Dringlichkeitsstufe -- wer ein
Formular mit fuenf Feldern sieht, meldet den kleinen Fehler nicht,
und genau die kleinen erfaehrt sonst niemand.
DIE LEITUNG SIEHT ETWAS ANDERES: einen Eingang mit Zahlenband
(neu / in Arbeit / erledigt), drei Filtern und zwei Handgriffen --
„Ich kuemmere mich" und „Erledigt …". Zwei, nicht fuenf; eine
Zuweisung an eine Person und Prioritaeten waeren ein Ticketsystem
fuer zwei Menschen, die nebeneinander sitzen. Das Melde-Feld bleibt
auch fuer sie da, rutscht aber unter den Eingang.
Wer zumacht, schreibt einen Satz dazu -- der Melder sieht nur diesen
Satz, und ohne ihn weiss er nicht, ob etwas behoben wurde oder ob
niemand Zeit hatte. Beide Seiten bekommen eine Benachrichtigung.
UEBERNOMMEN STATT NEU ERFUNDEN:
* `dateiErkennen` aus workspace-chat.js -- EXPORTIERT, nicht
abgeschrieben. An ihr haengt die ganze Sicherheit der Uploads
(der Typ kommt aus den ersten Bytes, nicht aus Name oder
Content-Type), und eine zweite Fassung waere die, die beim
naechsten Dateiformat vergessen wird.
* Die zweigeteilte Sicht und `meldungFuer()` (gibt den Datensatz
oder null zurueck, nie true/false) aus dem vertraulichen
Meldeweg.
* Der Upload-Weg (express.raw, Text im Kopf, Ordner unter
DATEN_ORDNER, damit die Sicherungspruefung ihn findet).
DIE KACHEL BEKOMMT JEDER -- an EINER Stelle angehaengt: `bereicheFuer`
haengt sie an jede Rollenliste, statt sie in fuenf Listen
einzutragen. Genau so ist heute der Benachrichtigungs-Knopf auf 14
Seiten verschwunden. Dazu der Eintrag in rechte.js (ohne ihn
verschwindet die Kachel lautlos, `nurOffeneKacheln` filtert dagegen)
und in der Browser-Kachelliste fuer die Agentur-Rollen.
TON 44 GERECHNET, NICHT GEWAEHLT -- und dabei zweimal danebengelegen:
* Ich habe erst einen eigenen Modus in kachel-farben.mjs gebaut.
`tools/kachel-farbe-einzeln.mjs` gibt es aber seit dem 22.09. fuer
genau diesen Zweck. Meine Dopplung ist wieder weg.
* Von Hand hatte ich #bcdbff eingetragen. pruef-kachelfarben lehnte
es ab (Buntheit 0,060, verlangt sind 0,12) -- und das vorhandene
Werkzeug verteidigte es trotzdem, weil sein Abstand gut war. Ein
Werkzeug, das einen regelwidrigen Zustand haelt, weil er zufaellig
gut misst, behebt genau den Fehler nicht, fuer den es da ist.
Behoben: Zuerst die Regeln, dann der Abstand. Ergebnis #fd6401,
Abstand 0,0914 (engstes vorhandenes Paar: 0,0154).
DREI MESSFEHLER VON MIR, die wie schwere Befunde aussahen: `fetch`
verwirft den Host-Kopf (die Community kommt nur auf crew. herein),
die Community bestaetigt ihr Alter (`alter_ok`), und die Startroute
heisst /api/ich. Alle drei stehen in pruef-treff.mjs richtig.
Ein ECHTER Fehler kam dazu: support.html lud bereiche.js nicht, und
kopf.js stuerzte mit „Cannot read properties of undefined (reading
'LEITUNG')" ab -- sichtbar nur in der Browserkonsole. Und
pruef-css-klassen fand sofort, dass auch wahl.js fehlte.
Gemessen: pruef-support 45 Pruefungen, 0 Fehler (alle neun Rollen
kommen herein, jede sieht die Kachel, als Bild getarntes HTML wird
abgelehnt, eine fremde Meldung bleibt fremd, erledigt bleibt
erledigt). Dazu 24 Messungen am Bild in drei Groessen. Gruen:
pruef-kachelfarben (22), pruef-css-klassen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|