1d41e29bf7a25f58001a4aaa72fd22a809c5b724
376
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  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
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
d231e989cf |
Screenshots an einen Beitrag hängen
Filipe (Runde vom 23.09.2026): „mach das man da bitte screenshots oder kurzschnitte von den live reinposten kann. nach dem selben prinzip wie bei den anderen nebendran." ES FEHLTE WENIGER, ALS MEINE EIGENE NOTIZ BEHAUPTETE. Dort stand „ein eigener Brocken (Upload, Groessenpruefung, Sicherheit), kein Nebenbei". Nachgemessen statt geglaubt: Die Spalte `dateien.eintrag_id` gibt es seit dem Video-Einlesen, die Karten zeichnen ihren Bildstreifen bereits, und die Auslieferung entscheidet die Sichtbarkeit schon am BEITRAG statt an der Ablage. Gefehlt hat genau ein Weg -- das Hochladen. Wieder ein Beleg dafuer, dass auch meine eigenen Listen altern. „NACH DEM SELBEN PRINZIP" IST WOERTLICH GENOMMEN: `dateiErkennen` aus dem Chat (eine Fassung, drei Benutzer -- Chat, Support, Beitraege), derselbe Ordner wie die Dateiablage (die Auslieferung kennt nur einen Pfad), `express.raw` mit Rechtepruefung VOR der Annahme des Rumpfes. DER KNOPF STEHT AN DER KARTE, nicht im Anlege-Formular. Ein Bildschirmfoto faellt einem meist spaeter ein -- beim Nachschauen, wenn jemand fragt. Wer es nur beim Anlegen mitgeben koennte, muesste den Beitrag loeschen und neu schreiben. Er erscheint nur, solange noch Platz ist (drei je Beitrag), damit er nie eine Absage bringt. ZWEI FEHLER IN MEINEM EIGENEN CODE, beide beim ersten Laden gefunden: `DATEN_ORDNER` war nicht importiert, und `bereichVon()` hatte ich erfunden -- es gibt sie nicht. Der Bereich steht am Eintrag selbst und ist dort auch richtiger: Er kommt aus der Datenbank, nicht aus der Adresse. UND ZWEI MESSFEHLER, beide dieselbe Sorte wie den ganzen Tag: Ich fragte „darf die Community?" an einem Beitrag, den sie gar nicht sieht (404 -- richtige Antwort, falsche Frage), dann an einem freigegebenen (403 -- sie braucht eine Stufe zum Schreiben, auch das richtig). Die Frage, die wirklich zaehlt, ist eine andere: Gilt fuer ein Bild dieselbe Regel wie fuer einen Beitrag? Gemessen: Beitrag 403, Bild 403. Ein zweiter Weg mit anderen Rechten waere die Tuer, die niemand bemerkt. Gemessen: pruef-eintrag-bild, 24 Pruefungen, 0 Fehler -- darunter als Bild getarntes HTML (415), SVG (415, es ist XML und darf Skripte enthalten), PDF (415), die Grenze von drei am Server, und das Abnehmen samt Datei. Gruen: pruef-highlights (31), pruef-anhaenge, pruef-fassungen, pruef-galerie, pruef-video, pruef-css-klassen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
7acd7a7674 |
Das Suchfeld nimmt wieder Eingaben, eigene Kanalnamen, Community in Kanälen
screen1, drei Teile. === 1. „bei suchen kann man nichts reinschreiben" === MEIN FEHLER VOM SELBEN TAG. Beim Popover-Umbau heute frueh hing die Liste am <body>, damit sie nicht hinter dem modalen Dialog verschwindet. Gemessen: Das Suchfeld war da, der Fokus landete nicht darin, ein getipptes Zeichen kam nicht an. DER GRUND IST DER FOKUS-KAEFIG. Ein Dialog aus showModal() sperrt den Fokus auf seinen eigenen DOM-Baum ein. Die Liste lag im Top Layer -- sichtbar und anklickbar, aber ausserhalb des Kaefigs. Klicken braucht keinen Fokus, Tippen schon. Deshalb fiel es niemandem auf: Die Liste stand da, sie filterte auf Knopfdruck, nur eine Eingabe kam nicht an. DIE LOESUNG WAR EINE KOMBINATION, die ich vorher fuer unmoeglich hielt. Im Dialog wurde die Liste vom clip-path der abgeschraegten Ecke abgeschnitten, draussen war sie nicht bedienbar. Ein POPOVER wird aber in die Top Layer gehoben und dort gezeichnet -- der Beschnitt des Elternteils erreicht es nicht mehr, waehrend der DOM-Baum (und damit der Fokus) der des Dialogs bleibt. Jetzt haengt sie wieder im Dialog UND ist ein Popover: bedienbar und unbeschnitten. Gemessen beides gegeneinander: „comm" getippt -> kommt an, filtert auf 1 Treffer; und die LETZTE Zeile der vollen Liste ist wirklich anklickbar (elementFromPoint trifft sie selbst, nicht den Dialog). Daraus ist pruef-suchfeld geworden -- der Fehler war von aussen nicht zu sehen, und gefunden hat ihn Filipe, nicht ich. === 2. „einen neuen namen erstellen den es noch nicht gibt" === `data-frei="ja"` war in wahl.js seit langem gebaut und wurde NIE GESETZT -- dieselbe Sorte Lueue wie `grund_min` heute Morgen. Jetzt gesetzt; der getippte Text erscheint als eigener Eintrag ganz oben. Der Server nahm bisher nur die neun festen Zustaendigkeiten. Jetzt auch einen eigenen Namen: Der SCHLUESSEL wird daraus abgeleitet („Technik & Ton" -> "eigen-technik-ton"), der ANGEZEIGTE Name bleibt wie geschrieben. Das Praefix ist kein Schmuck -- ohne es entstuende aus dem Namen „Community" derselbe Schluessel wie beim festen Thema, und der eindeutige Index lehnte ihn ab, obwohl der Kanal nicht existiert. Gemessen: genau dieser Fall antwortet jetzt mit 201. Der alte Kommentar sprach sich gegen freie Namen aus („der sichere Weg zu Clipping neben Clipping-Team"). Das Risiko bleibt und wird begrenzt: Derselbe Name zweimal ergibt denselben Schluessel und damit 409. === 3. „kanäle mit den leuten mit der community rolle" === Seit dem 19.09. nimmt `ohneAussen()` die Community aus den Listen aller anderen. Die Begruendung dort ist ausdruecklich: „Ein Zweier-Gespraech ist kein Kanal. Es hat keine Nachtruhe, kein Modi liest mit, und niemand koennte moderieren." Genau diese Begruendung laesst den Kanal offen. Die Sperre bleibt fuer GESPRAECHE und faellt fuer KANAELE -- `?fuer=kanal` an der Partnerliste, und nur fuer den, der Kanaele ueberhaupt aufmachen darf. Sonst waere der Parameter ein Weg, an `ohneAussen` vorbei Namen zu erfahren. Gemessen: DogFather sieht im Gespraech VanVan und Miss, im Kanal zusaetzlich Kessi und Tom (beide Community). Ein Modi bekommt die erweiterte Liste auch mit dem Parameter nicht. Gruen: pruef-suchfeld (8, neu), pruef-chat-kanaele (81), pruef-treffchat, pruef-chat-neu, pruef-freie-namen (32), pruef-nachfrage (53), pruef-css-klassen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
8c599d7961 |
„An alle" bei „An wen" – und kein Creator mehr auf der Team-Seite
=== screen6: „An alle" === Filipe: „bei an ween fehlt noch die option alle neben den namen allen." Der Knopf steht VORN, nicht hinten: Wer etwas an das ganze Team geben will, soll nicht erst an sechs Namen vorbeilesen. Er traegt die Anzahl der Leute und faerbt sich wie die Stufe „Alle" -- beide bedeuten „keine Einschraenkung", und zwei Farben dafuer waeren zwei Aussagen fuer einen Gedanken. Ab zwei Personen; bei einer waere „alle" derselbe Handgriff wie ihr Name. EINE ANFRAGE, NICHT SECHS. Der Browser koennte fuer jede Person einzeln fragen -- und beim dritten von sechs Aufrufen die Verbindung verlieren. Dann haette die Haelfte des Teams die Aufgabe und die andere nicht, und niemand saehe, wo es abgebrochen ist. DER DUPLIKAT-SCHUTZ WANDERTE IN DIE SCHLEIFE. Er fragt, was EINE Person schon liegen hat; stuende er davor, bekaeme nur die erste ihre Pruefung und alle anderen die Vorlage doppelt -- genau so entstanden am 22.09. aus zwei Klicks 112 Aufgaben. Gemessen: erster Klick 36 Aufgaben (12 mal 3 Modis), zweiter Klick 0 angelegt und 36 uebersprungen. Ein gesperrter Modi bekommt nichts, ein Creator auch nicht, und wer gar nicht verteilen darf, kommt ueber „alle" ebenfalls nicht weiter. === screen4: kein anderer Creator === Filipe: „in dieser app gibt es keinen und wird es niemals einen anderen creator geben wie mich." Auf der Aufgabenseite war eine Filterreihe mit „Alle Creator" beschriftet -- und darunter standen Modis. Auf der Team-Adresse gibt es keine Creator und wird es nie geben. Sie heisst dort jetzt „Für wen". DAS HAUS KOMMT VOM SERVER. `/api/ich` schickt jetzt `haus`; es stand schon an der Sitzung und wurde nie mitgeschickt. Eine Rollenliste im Browser waere die naechste zweite Wahrheit -- und falsch fuer DogFather, der in beiden Haeusern arbeitet. NEUN WEITERE „BEFUNDE" WAREN MEINE MESSFEHLER. Meine erste Messung lief ueber 127.0.0.1 und meldete unter anderem „CREATOR WORKSPACE" in der Kopfleiste JEDER Seite. Auf der echten Adresse steht dort „Team Dogi" -- `person.haus` wird aus dem Host abgeleitet, und auf 127.0.0.1 ist das Haus nun einmal die Agentur. Nachgemessen mit gesetztem Host: crew. -> haus="crew", marke="Team Dogi". Die Uebersichtsseite mit ihren Creator-Texten steht auf crew. gar nicht erst in den Kacheln. Gemessen: pruef-an-alle, 19 Pruefungen, 0 Fehler. Gruen: pruef-aufgabenbrett, pruef-aufgaben-vorlagen, pruef-vorlagen, pruef-entwicklung (48), pruef-css-klassen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
710b766ffa |
Die rechte Hand: dieselben Rechte, außer an DogFather
Filipe: „die rechte hand soll das auch sehen. und die selben rechte
da haben wie dogfather. das einzige was sie nicht kann ist die
dogfather rolle oder leute anfassen. also da kann sie nichts
verändern."
ZUERST EIN IRRTUM VON MIR. Ich hatte den Bildschirmfoto-Ausschnitt
fuer die Rechtetafel gehalten und dort gebaut. „Vertritt dich im
Alltag und koordiniert das Team" steht aber in workspace-personen.js:
Gemeint war die PERSONENSEITE. Die Arbeit an der Rechtetafel ist
trotzdem drin (siehe unten) -- sie loeste dasselbe Problem an einer
zweiten Stelle.
=== DIE PERSONENSEITE ===
DIE OBERFLAECHE WAR STRENGER ALS DER SERVER. In personen.js stand
`if (ich.rolle === 'hand') { keine Knoepfe }` mit der Begruendung
„Der Server antwortet ihr auf jeden davon mit 404". Am 22.09. stimmte
das. Seither wurde der Server ZWEIMAL erweitert -- sie durfte
Personen anlegen, Codes neu erzeugen und Rollen aendern -- und diese
Zeile blieb stehen. Sie hatte drei Rechte und sah keinen einzigen
Knopf. Ein Rollenvergleich im Browser ist genau die zweite Wahrheit,
die still veraltet.
Jetzt fragt die Oberflaeche den Server (`darf_zugaenge_verwalten`,
`darf_personen_loeschen`, `rollen_anfassbar`). Dazu kommen SPERREN
und LOESCHEN, die bis heute ausdruecklich bei DogFather lagen --
Filipes „das einzige" ist juenger und eindeutig.
Die Knoepfe „Neuer Code" und „Sperren" standen inline im
DogFather-Zweig; sie sind jetzt Funktionen und werden von beiden
Stellen benutzt. Eine zweite Abschrift waere die geworden, die beim
naechsten Umbau nur halb nachgezogen wird.
ZWEI ECHTE LOECHER FAND DIE NEUE PRUEFUNG:
* `PUT /personen/:id/rolle` hatte `nurDogFatherBeiLeitung` NICHT.
Bis heute folgenlos; mit den neuen Rechten konnte die rechte Hand
darueber die Rolle eines MANAGERS aendern -- waehrend derselbe
Manager fuer DogFather auf crew. gar nicht in der Liste steht.
Zwei Wege, zwei Antworten, und der laxere galt fuer die Rolle mit
weniger Rechten.
* Die Loesch-Route hatte dieselbe Middleware ebenfalls nicht. Das
war harmlos, solange die Route selbst nur DogFather durchliess --
seit die rechte Hand loescht, ist es die Stelle, an der DogFather
geschuetzt wird.
=== DIE RECHTETAFEL (nicht bestellt, aber dasselbe Problem) ===
Dort durfte sie sehen, aber nichts umstellen. Jetzt umstellen wie
DogFather -- ausser der Spalte „DogFather" und der Zeile „Personen &
Zugaenge" (wer die freischaltet, hat Zugaenge vergeben, ohne einen
anzulegen). Zuruecksetzen bleibt bei DogFather: Der Knopf naehme
genau diese zwei Sperren mit, und eine Sperre, die ein zweiter Knopf
daneben aufhebt, ist keine.
Sie kann sich auch selbst nicht aussperren -- das hat er nicht
gesagt, aber eine Sperre, aus der man sich aussperren kann, ist eine
Falle. Ein festes Feld ist jetzt gar kein Knopf mehr und nennt den
Grund, der fuer DIESE Person gilt.
=== DREI MESSFEHLER VON MIR ===
Ein Manager ist auf crew. fuer die LISTE unsichtbar, fuer DogFathers
direkten Zugriff aber nicht -- ich hielt das eine fuer das andere und
erwartete, dass beide abgewiesen werden. Die Loesch-Vorschau (GET)
fehlte in meinem Waechter. Und `rollen_anfassbar` beantwortet eine
andere Frage als „wen sehe ich".
Gemessen: pruef-hand-personen, 40 Pruefungen, 0 Fehler -- jeder der
fuenf Wege einzeln gegen DogFather und die linke Hand, plus die
Gegenprobe, dass DogFather es kann. pruef-rechte-umstellen von 46 auf
56 Pruefungen. Gruen: pruef-personen-liste, pruef-personen-loeschen,
pruef-personen-kachel, pruef-rollen-anlegen, pruef-rechtetafel.
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
4d36f1cbf0 |
Der Benachrichtigungs-Knopf steht jetzt wirklich überall
Filipe: "dieser button soll bei jeder rolle perfekt funktionieren
bitte."
GEMESSEN, NICHT GERATEN. Serverseitig war nichts rollenabhaengig:
alle drei Routen (Schluessel, Stand, Probe) antworten jeder der acht
Rollen mit 200, und `willHaben` haengt an der Person, nicht an der
Rolle. Der Mangel lag woanders -- und genau dort, wo die Rolle
entscheidet: BEI DEN SEITEN.
14 Seiten haben eine Kopfleiste und luden glocke.js nicht. Welche
Seiten jemand benutzt, haengt an seiner Rolle:
Creator -> befinden.html, werdegang.html, teilen.html
Scout -> talente.html, bewerbungen.html
Modi -> treff-moderation.html, treff-regeln.html
Manager -> entwicklung.html, teamlage.html
Keine dieser Seiten hatte den Knopf. Wer dort war, konnte
Benachrichtigungen nicht einschalten -- und hat nicht einmal gesehen,
dass es sie gibt. Das CSS war ueberall schon da (start.css), es
fehlte allein die eine Skriptzeile. Jetzt steht er auf allen 34
Seiten mit Kopfleiste.
AUSGENOMMEN, UND ZWAR NAMENTLICH: anruf-probe.html. Die Seite hat
kein kopf.js, ist eine eigenstaendige Diagnoseseite, und
anruf-probe.js verweist ausdruecklich auf "im Chat oben auf die
Glocke tippen". Die Ausnahme steht in der Pruefung als Name, nicht
als Schweigen.
WARUM DIE PRUEFUNG DAS NICHT GEFUNDEN HAT -- zwei abgeschriebene
Listen, beide unter einer Ueberschrift, die mehr versprach:
"Der Knopf ist UEBERALL" sah 8 von 37 Seiten an.
"JEDE Rolle bekommt ihn" sah 4 von 8 Rollen an -- es fehlten
rechte Hand, linke Hand, Modi und
Spicy Media. Ausgerechnet die Modis
sind die groesste Gruppe im Haus.
Beide waren gruen. Sie haben nicht falsch gemessen, sie haben das
Falsche gemessen. Jetzt kommt die Seitenliste aus dem Verzeichnis
(jede Seite mit Kopfleiste) und die Rollenliste umfasst alle acht --
eine Liste, die niemand pflegt, kann nicht veralten. Und die Zahl
steht in der Bedingung, damit "auf allen 0 geprueften" nicht gruen
sein kann.
Dabei fielen zwei Dinge an der Pruefung selbst an: Ihr `anlegen`
setzte keine `code_kennung`, und ihre Anmeldung klickte stur auf
`.rolle[data-rolle="..."]`. Beides brach bei rechter Hand, linker
Hand und Modi ab -- den drei Rollen mit dem STILLEN ZUGANG, die
absichtlich keine eigene Kachel haben (Filipe, 09.09.2026: "damit die
von der workspace auch nicht mal sehen dass die modis von mir einen
eigenen zugang haben"). Sie tippen auf irgendeine Kachel, der Code
entscheidet. Derselbe Stolperstein hat vorher auch meine eigene
Messung dreimal "kommt nicht hinein" melden lassen -- ein Messfehler,
der wie ein schwerer Befund aussah.
31 -> 36 gepruefte Punkte, keiner weggefallen. Gruen: pruef-glocke,
pruef-push, pruef-push-ziel, pruef-css-klassen. Dazu eine eigene
Messung ueber alle acht Rollen: Knopf da, Routen 200/200/200,
8 Messungen, 0 Befunde.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d85694bd92 |
Keine fertigen Vorschläge mehr bei den Highlights
Filipe: "nimm die sachen da weg bitte. da sollen nur die sachen rein
kommen die die modis, linke und rechte hand oder dogfather
reinsetzen."
In der Spalte "Noch einzusortieren" standen drei vorgefertigte
Vorschlaege ("Was hier hingehoert", "Fanart von DogFather und Casper
ist ausdruecklich erwuenscht", "Ein Ausschnitt, der auf die Clips
soll"). Jemand hatte sie uebernommen, und danach standen sie zwischen
den echten Clips -- mit Datum, mit Verfasser, aeusserlich nicht von
einem echten Eintrag zu unterscheiden.
WARUM DIESES BRETT ANDERS IST ALS DIE UEBRIGEN: Anderswo ist ein
Vorschlag eine ANREGUNG, die man ausfuellt ("Der naechste Stream mit
DogFather" -> Datum eintragen). Highlights ist eine SAMMLUNG echter
Sachen. Ein vorgefertigter Text ist dort kein Anfang, sondern ein
Platzhalter, der aussieht wie Inhalt. Die anderen Bretter behalten
ihre Vorschlaege -- dazu hat er nichts gesagt.
Nebenbefund: Seine Rollenaufzaehlung ist genau TREFF_TEAM_ROLLEN
(modi, hand, linke, admin). Die Rechteregel stimmte also schon.
ZWEI ECHTE MAENGEL FIELEN DABEI AUF, beide beim Versuch, die drei
Eintraege wegzunehmen:
1. Der Knopf "loeschen" schickte DELETE OHNE GRUND. Der Server
verlangt bei einem fremden Beitrag auf einem Treff-Brett einen
(DSA Art. 17) und antwortet mit 400 -- die Oberflaeche zeigte nur
"Loeschen hat nicht geklappt." Zwei Knoepfe nebeneinander, einer
ging ("entfernen"), einer nicht, und die Meldung erklaerte nichts.
Jetzt fragt auch "loeschen" nach dem Grund, wenn der Server einen
braucht -- erkannt an `treffBrett` vom Server, nicht an einer
abgeschriebenen Brettliste -- und die Fehlermeldung gibt wieder,
was der Server gesagt hat.
2. Der Dialog liess DREI Zeichen als Grund durch, der Server verlangt
ZEHN. Wer "spam" tippte, kam durch die Nachfrage und bekam danach
eine Absage. `grund_min` steht seit dem 11.09. in /api/treff/lage
und wurde nie benutzt; jetzt ist es angeschlossen. In nachfrage.js
bestimmt der Aufrufer die Mindestlaenge (`grundMin`), Vorgabe
bleibt 3 -- fuer alle anderen Nachfragen aendert sich nichts.
UND ZWEI PRUEFUNGEN, DIE ROT WAREN, OHNE DASS ETWAS KAPUTT WAR:
- pruef-treff-start verlangte `>= 8` Vorschlaege auf dem Schirm. Das
stimmte bis zum Fenster-Umbau vom 20.09. -- seither kommen
hoechstens VIER (FENSTER = 4). Vier Tage rot, ohne dass es jemand
erfuhr. Gefragt wird jetzt der Server selbst. Und die Brettliste
["treff","anschlag","wunsch","highlight"] wird gegen den Bestand
abgeglichen statt abgeschrieben -- mit ausdruecklichem Nachweis,
dass Highlights keine mehr hat, damit das Wegfallen nicht einfach
eine Pruefung weniger bedeutet. 41 -> 42 Pruefungen.
- pruef-nachfrage zaehlte `installieren.js` als "diese Seite fragt
nach", obwohl der Aufruf dort hinter `if (typeof window.frageNach
=== 'function')` steht. Weil die Datei auf fast jeder Seite liegt,
wurde damit JEDE Seite zur fragenden -- fuenf rote Zeilen, kein
einziger echter Mangel. Ausserdem wurde die Kurzschreibweise
`{ titel, … }` als "ohne Titel" gemeldet. 46 -> 53 Pruefungen, alle
gruen; zwei davon sind neu (Gegenprobe plus Benennung der
Ausnahmen).
Beide mit Gegenprobe (git stash) belegt: schon vor dieser Aenderung
rot.
Gemessen: 11 Messungen, 0 Befunde -- darunter die Gegenprobe, dass
der alte Weg (DELETE ohne Grund) wirklich mit 400 gescheitert waere.
Gruen: pruef-treff-start (42), pruef-nachfrage (53), pruef-highlights
(31), pruef-anschlagbrett (12), pruef-css-klassen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
428235508f |
Noch einmal auf dieselbe Person: die Liste geht wieder zu
Filipe: "ich will das wenn ich wieder auf die person drücke die liste
unten dan wieder zu geht."
Dasselbe Muster, das die Stufenleiste auf derselben Seite schon hat
("Ein zweiter Klick auf dieselbe Stufe hebt den Filter auf") -- nicht
ein zweites, neu erfundenes. Der Weg zurueck ist derselbe Knopf wie
der Weg hin; ein eigener Schliessen-Knopf daneben waere ein zweites
Ziel fuer dieselbe Absicht.
WIEDERHERGESTELLT WIRD DER AUSGANGSZUSTAND, nicht "alles versteckt" --
und das ist ein Unterschied, der beinahe zu einem Fehler geworden
waere. Das Verteil-Band und das Vorlagenbrett stehen naemlich AUCH
OHNE AUSWAHL da; der Start ruft "verteilBandZeigen(null, null)" selbst
auf. Sie mit auszublenden haette ausgesehen wie Zumachen und waere
Wegnehmen gewesen. Sie fallen deshalb nur auf "niemand gewaehlt"
zurueck. Wirklich weg gehen die zwei Kaesten, die es ohne Person gar
nicht gibt: ihre Aufgaben und ihre Karte.
Gemessen wird genau das: Der Zustand VOR der Auswahl wird aufgenommen
und hinterher Feld fuer Feld verglichen (Band, Brett, Aufgaben, Karte,
eigene Karte, Meins). Dazu: ein dritter Druck macht wieder auf (kein
Einwegschalter), und eine ANDERE Person wechselt, statt zuzumachen.
14 Messungen, 0 Befunde. Gruen: pruef-entwicklung (48),
pruef-entwicklung-kacheln.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
362d883392 |
Personen als Kacheln statt Zeilen
Filipe: "gestalte diese seite auch anders bitte. viel krasser geiler uebersichtlicher." Auf das Angebot, die Rollen als Kacheln statt Zeilen zu bauen: "will ich." Entwurf gezeigt, Antwort: "so live". Eine Person war eine Zeile ueber die volle Breite -- links der Name, darunter fuenf halbe Saetze, rechts die Knoepfe. Gemessen: 1128 x 74 px, eine pro Reihe, mit achthundert Pixeln Luft in der Mitte. Jetzt 368 x 221 px, drei nebeneinander: sechs Creator brauchen zwei Reihen statt sechs. Die Angaben stehen in einem Zahlenband statt als Satzreihe -- aus "offene Aufgaben: 0 · 2 offene Sitzung(en) · betreut 3 Creator" werden Felder mit grosser Zahl und kleinem Wort, in jeder Kachel an derselben Stelle. Man vergleicht zwei Personen mit dem Auge, statt in jeder Zeile an einer anderen Stelle nach derselben Zahl zu suchen. Dazu: "vor 21 Tagen" statt "2026-09-15 00:26" (das genaue Datum bleibt als Titel dran), ein Namenszeichen in der Rollenfarbe mit schmalem Farbstreifen oben, und "gesperrt" als Marke in der Warnfarbe statt als graues Wort zwischen fuenf grauen Woertern. ES FAELLT NICHTS WEG. Name, Rolle, gesperrt, Anmeldung, Aufgaben, Sitzungen, betreute Creator, zugeteilte Scouts, "gehoert zu", die Zustaendigkeitsauswahl und alle Knoepfe -- die Messung prueft das ausdruecklich mit, huebsch und unvollstaendig waere schlechter als vorher. Keine feste Spaltenzahl: "auto-fill" laesst den Browser rechnen, bei 1160 px sind es drei, bei 390 px eine. Eine Zahl waere die sechste Wiederholung desselben Fehlers in diesem Haus. Nebenbei zwei Altlasten: .marke-rolle und .betreuung__schild standen auf 11,2 px, unter der Hausgrenze von 11,5. Mit Gegenprobe belegt, dass das schon vorher so war -- jetzt .75rem. Gemessen: 14 Messungen, 0 Befunde (1765 px und 390 px). Gruen: pruef-personen-kachel (45), pruef-personen-liste, pruef-css-klassen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
14c8964b24 |
Die Unterkategorien nach Alter erscheinen jetzt wirklich
Filipe: "wieso sehe ich nichts von diesen unterkategorien?" Weil ich gestern eine Schwelle eingebaut hatte, die er nie verlangt hat: Gegliedert wurde erst ab 13 Eintraegen. Seine Spalten haben 3, 1, 1 und 4 -- er hat die Gliederung also nie zu sehen bekommen. Die Begruendung von gestern stand als Kommentar daneben und klang vernuenftig: "Bei wenigen Eintraegen waere eine Gliederung Aufwand ohne Nutzen: sieben Ueberschriften fuer fuenf Karten." Sie war in beiden Haelften falsch. Erstens war die Ansage klar -- eine eigene Bedingung daranzuhaengen ist keine Sorgfalt, sondern eine Entscheidung, die mir nicht zusteht. Zweitens gab es die sieben Ueberschriften nie: Leere Stufen werden ohnehin uebersprungen, drei Karten ergeben hoechstens drei Ueberschriften. Genau das misst die Messung jetzt mit. Nachgestellt wurde sein Bildschirmfoto: vier Spalten mit 3, 1, 1, 4. DogFather zeigt "Heute 1 (offen) | Gestern 1 (zu) | Diese Woche 1 (zu)", die Sammelspalte vier Stufen bis "Über sechs Monate". Keine Stufe steht leer da (9 geprueft), die neueste ist offen, ein Druck auf die Ueberschrift klappt zu. Gemessen: 10 Messungen, 0 Befunde. Gruen: pruef-highlights (31), pruef-anschlagbrett (12), pruef-css-klassen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
08ff3e5e40 |
Die Liste im Dialog rollt, das Anschlagbrett schreibt nicht mehr ab
Zwei Dinge aus Filipes Durchgang. ERSTENS: "das hoch und runter scollen geht nicht in der liste da." Die Auswahlliste im Kanal-Dialog liegt seit dem Popover-Umbau in der obersten Ebene. Das loest das Abschneiden -- aber der Zeiger steht danach ueber dem Dialog, nicht ueber der Liste, und das Mausrad rollt den Dialog. Der Horcher haengt jetzt am Dokument (capture) und fragt selbst, ob der Zeiger im Rechteck der Liste steht. Gemessen: 5 Messungen, 0 Befunde. ZWEITENS: "gestalte diese seite auch anders ... viel uebersichtlicher." Am Anschlagbrett stand die Herkunft als vollstaendige Abschrift des Titels darueber -- derselbe Satz zweimal, direkt untereinander. Jetzt nennt sie nur noch das Brett, wenn der Titel uebernommen wurde, und kuerzt sonst auf 60 Zeichen an der Wortgrenze. Dazu Karten mit 620 px Hoechstbreite, zwei nebeneinander statt einer Zeile ueber die ganze Breite -- lesbar bleibt, was eine begrenzte Zeilenlaenge hat. Gemessen: 11 Messungen, 0 Befunde; Titel von 352 px statt voller Breite, zwei Spalten a 571 px. Geprueft: pruef-anschlagbrett (12, 0), pruef-css-klassen, pruef-highlights, pruef-chat-kanaele (81, 0), pruef-freie-namen (32, 0). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
7f732cc403 |
Gegliedert nach Alter: sieben Stufen, klappbar
Filipe: "ich will da unterkategorien die man auf und zu klappen kann,
so wie heute gestern, diese woche, diesen monate, über ein monat,
über 6 monate, über ein jahr."
DAS IST DIE BESSERE ANTWORT AUF DIE LANGEN LISTEN als die Zahl von
gestern. Zwoelf ist willkuerlich; eine Gliederung nach Alter
beantwortet die Frage, die man an so eine Liste wirklich stellt --
was ist neu?
DIE ERSTEN VIER STUFEN SIND KALENDERBEZOGEN, die letzten drei
altersbezogen:
Heute, Gestern der Kalendertag
Diese Woche seit MONTAG -- am Dienstag ist der Freitag
davor nicht "diese Woche"
Dieser Monat seit dem Ersten
Ueber einen Monat der Abstand, weil "Mai" niemandem sagt,
Ueber sechs Monate wie lange das her ist
Ueber ein Jahr
Das klingt uneinheitlich und ist genau richtig.
DIE NEUESTE GRUPPE STEHT OFFEN, die aelteren zu. Wer die Seite
aufmacht, will sehen was neu ist -- und alles Aeltere ist sichtbar
VORHANDEN, ohne den Weg zu verstellen. Die eigene Wahl gewinnt und
wird gemerkt, je Gruppe und je Spalte.
EINE LEERE STUFE ERSCHEINT NICHT. Sieben leere Ueberschriften waeren
schlimmer als eine lange Liste. Und gegliedert wird erst UEBER zwoelf
Eintraegen -- darunter waeren es sieben Ueberschriften fuer fuenf
Karten.
Die Zwoelfergrenze von gestern bleibt, gilt aber jetzt JE GRUPPE: Auch
"Ueber ein Jahr" kann dreihundert Eintraege haben, und dann hilft die
Gliederung allein nicht.
GERECHNET WIRD IN ORTSZEIT (window.heuteLokal), nicht in UTC. Ein
Eintrag von gestern 23:40 waere in UTC schon heute und stuende unter
"Heute", waehrend das Datum daneben gestern sagt.
ZWEI DINGE NACHGESEHEN STATT GERATEN:
abschnittKlappbar nimmt als vierten Wert ein BOOLEAN (zuVorgabe),
kein Objekt. Ich hatte "{ offen: ... }" angenommen; beim Nachsehen
in kopf.js stand etwas anderes da.
Jede Gruppe braucht einen eigenen Merker. Ohne ihn teilten sich
"Heute bei DogFather" und "Heute bei HasiDog" denselben Zustand,
und wer die eine zuklappt, klappt die andere mit.
Gemessen mit Eintraegen ueber alle sieben Stufen: 10 Messungen,
0 Befunde -- Reihenfolge, Zahlen, offen/zu, Klapp-Pfeil, kein
seitlicher Ueberstand, und ein Tipp macht eine zugeklappte Gruppe
wirklich auf. pruef-highlights 31, pruef-galerie und
pruef-css-klassen in Ordnung.
NOCH OFFEN -- screen1: "Screenshots oder Kurzschnitte reinposten"
braucht eine Route, die eine Datei an einen EINTRAG haengt. Die gibt
es heute nicht: workspace-video.js legt Coverbilder beim Einlesen
eines TikTok-Links an, workspace-dateien.js laedt hoch, aber ohne
eintrag_id. Das ist ein eigener Brocken und kein Nebenbei.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2bea133feb |
Das Protokoll spricht deutsch -- und zwei Pruefungen messen wieder
Filipe: "ich will dass das alles viel anders und krasser und geiler
gestaltet ist bitte ... viel profissioneller und moderner."
--- DIE PERSONENSEITE ---
Auf seinem Bildschirmfoto stand woertlich, was in der Datenbank steht:
"treff_freigegeben", "video_eingelesen", "einstellung_geaendert". Das
sind Spaltenwerte, keine Saetze fuer Menschen. Daneben die rohe
IP-Adresse, quer ueber ein Viertel der Zeile.
KEINE TABELLE MIT 77 EINTRAEGEN. So viele Aktionen gibt es; eine
Liste davon waere am Tag der naechsten unvollstaendig, und niemand
merkte es -- dann stuende einfach wieder der Rohname da. Dieselbe
Falle wie jede abgeschriebene Liste in diesem Haus.
Stattdessen eine REGEL: Unterstriche werden Leerzeichen, der erste
Buchstabe gross. Das ergibt fuer jede Aktion einen lesbaren Ausdruck,
auch fuer die, die es noch nicht gibt. Nachgeprueft an allen echten
Namen:
treff_freigegeben -> Treff freigegeben
einstellung_geaendert -> Einstellung geändert
chat_zurueckgenommen -> Chat zurückgenommen
vorlage_uebernommen -> Vorlage übernommen
Die Umlaute sind der zweite Teil: In der Datenbank stehen sie als
ae/oe/ue. Blind zurueckzusetzen waere falsch ("neue" wuerde "neü"),
deshalb nur in Wortteilen, die sicher sind -- gemessen an den 77
echten Namen, nicht geraten.
Der Rohname bleibt als Titel an der Zeile: Wer im Server danach sucht,
braucht ihn genau so, wie er in der Spalte steht.
DIE IP TRITT ZURUECK, verschwindet aber nicht: feste schmale Spalte,
leiser Ton. Sie beantwortet eine Frage, die man selten stellt.
UND DIE BESCHREIBUNGEN BRECHEN UM. Die der linken Hand lief ueber 150
Zeichen in einer Zeile; der Augensprung ans naechste Zeilenende ist
dann so weit, dass man die Zeile verliert. Setzer rechnen seit
Jahrhunderten mit 60 bis 80. Gekuerzt wird nichts -- "78ch" misst in
ZEICHEN und stimmt darum auch, wenn die Schrift groesser gestellt wird.
--- UND DIE ZWEI ALTLASTEN, BEIDE GESTERN GEMELDET ---
pruef-chatkachel suchte dreizehn Toene als dreizehn Knoepfe. Das
stimmte, bis die Kachelfarbe ein FARBKREIS wurde (
|
||
|
DogFatherGitandClaude Opus 5
|
7aef7e4b9a |
Keine Liste ohne Ende -- und die vierte Spalte sagt, was zu tun ist
Filipe: "der ohne account ist total sinnlos, mach was anderes draus.
und mach die ganze seite noch viel uebersichtlicher und ohne so dass
es extrem lange listen gibt mit der zeit."
ZWEI SACHEN, UND BEIDE FANGEN MIT NACHSEHEN AN.
--- 1. Was liegt eigentlich in "Ohne Account"? ---
Nachgezaehlt in den echten Daten:
2 x clip <- eine Luecke: ein Clip kommt IMMER von einem Kanal
1 x moment
1 x fanart <- gehoert zu Recht zu keinem Account
Die Spalte mischte also zwei Dinge, die nichts miteinander zu tun
haben: etwas, das einsortiert gehoert, und etwas, das dort richtig
liegt. Und sie hiess nach dem, was FEHLT. Wer die Zahl sah, wusste
nicht, ob er etwas tun muss -- genau das macht sie "sinnlos".
Jetzt entscheidet der Inhalt ueber Namen und Satz:
Clips dabei -> "Noch einzusortieren" + "2 Clips hier haben keinen
Account. Öffne sie und trag ihn nach."
nur Bilder -> "Ohne TikTok-Quelle" + "Eigene Bilder und Fanart
gehören zu keinem Account. Hier ist nichts zu tun."
NICHT IN ZWEI SPALTEN GETRENNT: Das waere eine mehr, und Filipe hat
im selben Satz um weniger gebeten.
--- 2. "mit der zeit" ist der Kern ---
Heute liegen neun Highlights da und alles passt. In einem Jahr sind es
dreihundert, und dann ist jede Spalte eine Rolle ohne Ende. Der Fehler
faellt erst auf, wenn er schon laestig ist -- deshalb jetzt.
Je Abschnitt zwoelf, der Rest auf einen Druck. Zwoelf, weil zwei
nebeneinander passen: sechs Reihen, genug um zu sehen was zuletzt war,
ohne bis zum Anfang der Zeit zu scrollen.
AN EINER STELLE FUER ALLE DREI FORMEN. Die Seite legt Karten an drei
Stellen in einen Kasten -- Kanalspalten, Abschnitte nach Art,
Zeitstrahl. Dreimal dasselbe hinzuschreiben hiesse, dass beim
naechsten Umbau zwei nachgezogen werden und eine vergessen wird.
ES VERSCHWINDET NICHTS, und die Zahlen in den Koepfen zaehlen weiter
ALLE: Eine Ueberschrift, die 12 sagt und 30 meint, waere schlimmer als
eine lange Liste. Gemessen mit 30 Eintraegen: Kopf zeigt 30, Spalte
zeigt 12, Knopf bietet "18 ältere zeigen", nach dem Druck sind alle 30
da und der Knopf ist weg -- er haette nichts mehr zu tun.
Sortiert ist ohnehin nach Datum absteigend, "die ersten zwoelf" sind
also die neuesten zwoelf und nicht die erstbesten.
Gemessen: 8 Messungen mit dem Datenbestand "ein Jahr spaeter",
0 Befunde. pruef-css-klassen und pruef-highlights in Ordnung.
NICHT VON MIR, mit Gegenprobe belegt: pruef-galerie meldet "mit
mehreren Spalten (1)" -- auch mit zurueckgenommener Aenderung. Eine
Altlast, die nachgezogen gehoert.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d868bb1e35 |
Die Personenkacheln: aus drei Zahlen wird ein Bild
Filipe: "ich will dass das alles viel anders und krasser und geiler
gestaltet ist. mal was krass modernes ... viel viel viel
uebersichtlicher."
WAS AUF SEINEM BILDSCHIRMFOTO STAND: sechs Kacheln, jede mit drei
gleich grossen Zahlenkaesten -- und bei fuenf davon exakt dasselbe:
"0 angesehen, 68 noch offen, 0 verschieden gesehen". Achtzehn Kaesten
fuer eine einzige Auskunft: Hier ist noch nichts passiert.
DREI ZAHLEN MUSS MAN LESEN UND VERRECHNEN. Einen Balken sieht man.
Und die Frage, die man an diese Liste stellt, ist nicht "wie viele
genau", sondern "wer ist wie weit". Darum liegt unter jedem Namen
jetzt eine schmale Spur, vier Bildpunkte hoch, die genau das zeigt.
KEINE AMPELFARBEN. Was "genug" ist, haengt davon ab, wie lange jemand
dabei ist; eine Schwelle waere geraten und bei der naechsten Person
falsch. Der Balken sagt, WIE WEIT -- er urteilt nicht. Und er traegt
die Akzentfarbe der Seite, nicht Gruen oder Rot.
EINE NULL IST KEINE WARNUNG. "Verschieden gesehen" ist die einzige
der drei Zahlen, die zu einer Handlung fuehrt: Dort lohnt das
Gespraech. Steht dort eine Null -- der Normalfall --, tritt der Kasten
zurueck. Gleiche Groesse, gleicher Platz, nur leiser. Sonst waeren es
sechs gelbe Nullen, und die eine echte siebte faellt dann nicht mehr
auf.
NICHTS WURDE WEGGENOMMEN. Alle drei Zahlen stehen weiter da, gemessen:
drei Kaesten je Kachel, auf Rechner und Handy. Und ein
Vorleseprogramm bekommt den Balken als Satz ("0 von 68 angesehen,
0 Prozent") -- eine Breite allein sagt ihm nichts.
Augenschonend nach Hausregel: kein Leuchten, kein blendender Verlauf,
und die kurze Bewegung beim Neuzeichnen faellt bei
prefers-reduced-motion ganz weg.
Gemessen: 16 Messungen auf beiden Groessen, 0 Befunde.
pruef-entwicklung-kacheln, pruef-entwicklung (48) und
pruef-css-klassen alle in Ordnung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
f2f3586b5b |
Die Auswahlliste lag hinter dem Dialog
Filipe: "wenn ich auf zustaendigkeit druecke dan erscheint die auswahl
im hintergrund kontrollier das."
KONTROLLIERT, UND ER HAT RECHT. Gemessen im Browser: Der Kanal-Dialog
ist modal, die Liste hing an BODY, und ein Klick in ihre Mitte traf
DIALOG.dialog -- also den Dialog, nicht die Liste. Sie war da, sichtbar
war sie nicht, bedienbar erst recht nicht.
DER GRUND IST EINE EBENE, KEINE ZAHL. Ein Dialog aus showModal() liegt
in der TOP LAYER, einer Schicht ueber dem ganzen Dokument. Kein
z-index holt etwas aus dem Body davor; die Ebene entscheidet.
DER ERSTE VERSUCH WAR FALSCH, und das Bildschirmfoto hat es gezeigt:
Die Liste IN den Dialog zu haengen bringt sie zwar nach vorn -- und
laesst sie am unteren Rand abschneiden. `.dialog` traegt ein
clip-path fuer die abgeschraegte Ecke, und ein clip-path beschneidet
ALLE Nachkommen, auch "position: fixed". Die Liste endete mitten im
Wort "Events".
Damit ging beides nicht: draussen dahinter, drinnen beschnitten.
DER POPOVER IST GENAU DAFUER GEMACHT. Er hebt ein Element in dieselbe
Ebene wie den Dialog, ohne es zu seinem Kind zu machen: kein Beschnitt,
kein z-index-Wettlauf, und der Browser raeumt ihn beim Schliessen
selbst weg. Fehlt er im Browser, bleibt alles wie bisher -- ausserhalb
eines Dialogs aendert sich ohnehin nichts.
Die drei Zeilen in gate.css nehmen die Vorgaben zurueck, die ein
Popover mitbringt (Rahmen, Polster, und "inset: 0" plus "margin: auto",
was ihn in die Bildmitte stellt).
UND MEINE MESSUNG WAR ZUERST FALSCH, nicht der Code: Sie fragte
document.elementFromPoint und bekam DIALOG -- auch als die Liste
sichtbar darueber lag. Top-Layer-Elemente erfasst elementFromPoint
nicht verlaesslich. Gemessen wird jetzt, was ein Mensch tut: auf einen
Eintrag tippen und nachsehen, ob er ankommt. Er kommt an
("chat -> events"), und die Liste schliesst sich danach.
DAZU EINE EIGENE SCHLAMPEREI VON VORHIN: Die neuen Handy-Kacheln auf
"Eure Aufgaben" hatten .7rem = 11,2 px. Die Grenze des Hauses liegt
bei 11,5 px, und sie steht dort aus einem Grund -- Augenschonung ist
Pflicht, nicht Geschmack. pruef-css-klassen hat es gefangen ("43
Stellen unter 11,5 px, eine mehr als die Grundlinie 42"). Genau dafuer
zaehlt sie mit. Jetzt .75rem, und die Zahl steht wieder bei 42.
Gemessen: 7 Messungen am Dialog ohne Befund, css-klassen wieder in
Ordnung.
NICHT VON HEUTE ABEND, aber gefunden: pruef-chatkachel meldet "mit
allen 13 Toenen (2)". Seit Commit
|
||
|
DogFatherGitandClaude Opus 5
|
cbaa529350 |
Eure Aufgaben: die Reihenfolge, in der man denkt
Filipe: "die seite eure aufgaben, ich will dass du die so krass perfektionierst, ich will dass du die so krass uebersichtlich machst." ERST GEMESSEN, DANN ANGEFASST. Mit sechs Leuten, so wie im echten Team: Handy, Person gewaehlt 8281 px = 10,6 Bildschirme Handy, Katalog offen 11636 px = 14,9 Bildschirme Und die Personenwahl -- der ERSTE Schritt -- begann am Handy bei Bildschirm 5,3. Man scrollte an allem vorbei, um anzufangen; und was man dabei ueberscrollte (Formular, Katalog), betraf genau die Person, die man noch gar nicht gewaehlt hatte. DER PLAN STAND SCHON DA. Im HTML steht seit dem 15.09. ein Kommentar: "1. Die Ampel. 2. Die Personen. 3. Die Karte." Genau so war es gedacht -- und genau so war es nicht mehr: Am 22.09. kam das Verteilen auf die Seite, am 23.09. der Katalog, und beide sind davor gerutscht. Der Kommentar beschrieb eine Ordnung, die es nicht mehr gab. Wieder eine Bestandsliste, die altert, waehrend jemand weiterarbeitet. Die Reihenfolge ist jetzt die, in der man denkt: Wie steht das Team? -> Wen nehme ich mir vor? -> Was gebe ich ihm? -> Was liegt schon bei ihm? -> Wie steht er da? Handy: Personenwahl beginnt bei Bildschirm 0,5 statt 5,3 Rechner: bei 0,4 statt 2,0 DIE KACHELN AM HANDY kosteten 1176 px fuer sechs Leute -- anderthalb Bildschirme nur fuer die Frage, wen man sich vornimmt. Grund war "min-width: 260px", und der Grund DAFUER steht daneben: Die drei Bilanz-Kaesten wurden sonst gequetscht. Das stimmt, solange sie NEBENEINANDER stehen. Am Handy stehen sie jetzt untereinander, jeder eine Zeile (Ziffer links, Wort rechts) -- so kommt die Kachel mit der halben Bildschirmbreite aus und zwei passen nebeneinander: 618 px. KEINE ZAHL FAELLT WEG. Wer verteilt, muss sehen, wer schon wie viel hat; das ist der Zweck dieser Kaesten. Sie werden kleiner, nicht weniger. Unter 380 px wieder eine Kachel je Zeile -- zwei haetten dort je 145 px, und "verschieden gesehen" waere nicht mehr zu lesen. DER SPRUNG BEIM KACHELKLICK IST WEG. Er war richtig, solange die Karte direkt unter der Auswahl stand. Jetzt liegen Formular, Katalog und ihre Aufgaben dazwischen -- ein Sprung zur Karte uebersaehe genau die drei Dinge, die man nach der Wahl zuerst braucht. (Filipe, 15.09.: "die seite soll sich nicht immer bewegen wenn ich auf was druecke.") Der Sprung von der Talentseite bleibt, dort ist er gemeint. UND DER CHAT KEHRT DAHIN ZURUECK, WO MAN AUFGEHOERT HAT. Die Linie "Ab hier neu" gibt es seit Tagen -- sie wurde gezeichnet und sofort ueberscrollt, weil der Verlauf beim Oeffnen ans Ende sprang. Wer nach zwei Tagen zurueckkam, landete unten und suchte die Stelle, indem er Uhrzeiten las. Jetzt springt er EINMAL beim Oeffnen dorthin, auf ein Viertel Hoehe: darueber der Zusammenhang, darunter das Neue. Danach gilt wieder die alte Regel, damit eine eintreffende Nachricht einen nicht aus dem Lesen reisst. Gemessen: entwicklung 48, entwicklung-kacheln 15, modi-katalog 133, bewerbung-aufgaben 101, chat-optik -- alle ohne Befund. NOCH NICHT FERTIG: Die Entwicklungskarte ist mit 5975 px weiterhin 72 % der Seite. Das ist der naechste Schritt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5b7708fd10 |
Die Kopfleiste bleibt stehen -- jetzt auf allen Seiten
Filipe: "die leiste soll immer da fest stehen bleiben auch wenn man
runterscrollt, sonnst muss man immer wieder hoch scrollen um zurueck
zu koennen oder so."
GEMESSEN, BEVOR ETWAS ANGEFASST WURDE -- und das war noetig, denn der
Quelltext sagte das Gegenteil:
entwicklung.html sticky klebt
start.html sticky klebt
aufgaben.html relative wandert weg
chat.html relative wandert weg
wissen.html relative wandert weg
Dieselbe Leiste, dasselbe CSS, zwei Verhalten. Der Unterschied war
eine Regel, die es gar nicht darauf angelegt hatte:
body[data-ton] .kopfleiste { position: relative; }
Sie stand dort einzig, damit ein ::before darunter einen Bezugspunkt
bekommt -- die farbige Kante der Seite. Ihre Staerke ist (0,2,1),
genau wie die der Regel, die das Kleben setzt, und sie steht 8400
Zeilen spaeter. Bei gleicher Staerke gewinnt die spaetere.
WARUM MAN DAS IM QUELLTEXT NICHT SIEHT: "data-ton" haengt kopf.js
erst NACH dem Laden an den Body. Im HTML steht es nirgends. Welche
Seite betroffen ist, entscheidet sich also im Browser -- und nur dort
war es zu messen.
ERSATZLOS WEG, nicht ersetzt: "position: sticky" ist selbst ein
Bezugspunkt fuer absolut positionierte Kinder. Das ::before braucht
die Zeile nicht. pruef-kopfleiste-farbe bestaetigt das: 9 geprueft,
0 Fehler, die Kante traegt weiter die Farbe der Seite.
Dazu gilt die Regel jetzt fuer jedes Haus statt nur fuer "body.start"
-- anruf-probe.html traegt "body.haus" und war nie erfasst.
UND DAS SPRUNGZIEL. Wer von "Eure Aufgaben" auf eine Aufgabe tippt,
landet auf aufgaben.html#a123. Mit einer festklebenden Leiste liegt
das Ziel danach exakt darunter -- die Seite springt, und die gesuchte
Karte ist trotzdem nicht zu sehen. Das sieht aus wie ein kaputter
Link. "scroll-padding-top" haelt jetzt Abstand, und zwar aus der
gemessenen Hoehe (--kopf-hoehe, die kopf.js ohnehin fuehrt und in der
auch das Band der fremden Sicht steckt) -- keine feste Zahl: Am
Rechner sind es 118 px, auf einem 390er-Schirm 115.
DAS WAR DIE FUENFTE SPIELART DERSELBEN FALLE. Die vier anderen stehen
seit dem 07.09. im Kommentar daneben; jedes Mal hat eine Regel
"position" gesetzt, um etwas ganz anderes zu erreichen. Damit es
keine sechste gibt, misst pruef-kopf-messen ab jetzt das VERHALTEN:
Sie scrollt und sieht nach, wo die Leiste danach steht. Auf sechs
Seiten statt drei -- die drei neuen sind die, auf denen es gebrochen
war, plus eine ohne Farbton als Gegenprobe. Seiten, die zu kurz zum
Scrollen sind, melden "nicht nachsehbar" statt stillschweigend gruen
zu werden.
Gemessen: pruef-kopf-messen 42 Breiten (davon 14 Klebe-Messungen),
0 beanstandet. pruef-kopfleiste-farbe 9, pruef-ueberlappung 20
Seiten-Breiten-Paare, alle ohne Befund. Sprungziel auf Rechner und
Handy: 6 Messungen, 0 Befunde.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
47cea0533b |
Die Personenreihe im Katalog kommt zurueck
Filipe: "ich hab gesagt du sollst die kachel von aufgabe in die eure
aufgabe kategorie machen und du machst sie ganz weg was soll das, da
ist scheisse wenn du einfach sachen machst die ich nicht verlange."
Er hat recht. Der Auftrag war, den Katalog zu VERSCHIEBEN. Ich habe
ihn verschoben und dabei die Personenreihe darin geloescht -- mit
einer Begruendung, die ich mir selbst gegeben habe. Verlangt war das
nicht.
Sie steht wieder vollstaendig da: die Ueberschrift "An wen", ein Knopf
je Person, daneben wie viel offen ist, und was ueberfaellig liegt
faellt auf ("1 spaet"). Dieselben Bausteine wie vorher, dieselbe
Gestaltung -- am CSS musste nichts geaendert werden, es stand noch da.
WAS SICH GEAENDERT HAT, IST NUR, WAS SIE SETZT. Frueher hatte sie eine
eigene Auswahl (kZiel), die nichts von der Seite wusste: Man konnte
oben den einen und unten den anderen waehlen, und dann standen zwei
Antworten auf einem Bildschirm. Auf "Aufgaben" fiel das nicht auf,
weil es dort oben gar keine Personenwahl gab. Auf "Eure Aufgaben"
waere es aufgefallen.
Jetzt ruft ein Tipp in der Reihe dieselbe Funktion wie ein Tipp auf
eine Kachel -- nicht etwas Aehnliches, sondern denselben Weg. Damit
KANN die Reihe nichts anderes meinen als die Kacheln. Zwei Stellen zum
Bedienen, eine Antwort.
Gemessen, in beide Richtungen: Ein Tipp in der Reihe markiert die
Kachel oben, und ein Tipp auf die Kachel markiert den Knopf in der
Reihe. Dazu Namen, Zahlen und die Spaet-Markierung. 14 Messungen,
0 Befunde. pruef-modi-katalog misst wieder drei Reihen statt zwei --
und neu auch die Kopplung selbst: 133 geprueft (vorher 129), 0 Fehler.
WAS ICH DARAUS MITNEHME: "Verschieben" heisst verschieben. Wenn mir
beim Umzug etwas auffaellt, das ich fuer ueberfluessig halte, ist das
eine Frage an Filipe und keine Entscheidung von mir.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
4454c6d064 |
Ein zweiter Druck legt nichts mehr doppelt an
Filipe: "diese aufgaben die da alle verteilt wurde, die hab ich nicht gemacht also sollen die alle da weg, keine ahnung was du da gemacht hast." WAS WIRKLICH PASSIERT IST, steht in der Datenbank: 2026-09-22T16:05:24 35 Aufgaben 2026-09-22T16:05:25 21 Aufgaben 2026-09-22T16:05:53 56 Aufgaben Zweimal "Alle uebernehmen", 29 Sekunden auseinander, von Ghost. 112 Aufgaben an vier Modis -- 14 Vorlagen, jede doppelt, je 28 pro Person. Alle noch offen, keine einzige angefasst. Der eine Weg dorthin ist seit dem 22.09. zu: Ein Modi darf nicht mehr verteilen (darfAufgabenVerteilen). Der andere war offen -- der zweite Druck selbst. Wer verteilen darf, konnte den Massenknopf beliebig oft betaetigen, und nichts hat ihn aufgehalten. DIE SPERRE GAB ES IM HAUS SCHON, im Termin-Zweig derselben Route: "Was es schon gibt, wird nicht doppelt angelegt." Beim Massenknopf fehlte sie. Dass sie fehlte, ist nicht aufgefallen, weil niemand zweimal drueckt -- bis es jemand tat. NUR DER MASSENKNOPF, NICHT DER EINZELNE. Ein "Nochmal" an einer Karte ist eine bewusste Entscheidung; manches macht man jede Woche neu, und der Knopf sagt es sogar. Ein Griff, der zwoelf Aufgaben auf einmal holt, ist etwas anderes: Ob er schon gedrueckt wurde, sieht man ihm nicht an, und beim zweiten Mal richtet er zwoelffachen Schaden an. UND "OFFEN" HEISST OFFEN. Was erledigt oder abgebrochen ist, darf wiederkommen -- sonst liesse sich eine woechentliche Aufgabe nach dem ersten Abhaken nie wieder holen. Gefragt wird nicht "gab es die schon mal", sondern "liegt die gerade noch da". Die Oberflaeche sagt es jetzt auch: "3 uebernommen. 9 lagen schon offen da - die kommen nicht doppelt." In Gruen, nicht in Rot: Das ist keine Stoerung, sondern die Auskunft, dass die Sperre gegriffen hat. Ein Knopf, der weniger tut als er verspricht UND schweigt, ist schlimmer als einer, der zu viel tut -- man drueckt ihn noch einmal. Gemessen am nachgestellten Vorfall: erster Druck 12 Aufgaben, zweiter Druck 0 statt 12 (waeren 24 geworden). Gegenproben: Abgehaktes laesst sich neu holen, und der einzelne Nochmal-Knopf legt weiter an. 12 Messungen, 0 Befunde. pruef-modi-katalog 129 und pruef-aufgaben-vorlagen bleiben gruen. Die 112 Aufgaben selbst stehen noch in der Datenbank -- sie gehoert dogiweb, ich habe dort nur Leserecht. Der Befehl dafuer geht an Filipe. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
84e4048ab4 |
Der Aufgabenkatalog zieht dorthin, wo verteilt wird
Filipe: "das soll auch bitte nicht in der kategorie aufgaben sondern
eure aufgaben sein bitte. setzt das perfekt da rein und pass es
uebeertrieben krass rein."
Und das ist richtig: "Aufgaben" zeigt, WAS liegt. Verteilt wird seit
dem 22.09. auf "Eure Aufgaben" -- dort wird die Person gewaehlt, dort
steht das Formular, dort ihre Aufgaben. Der Katalog ist nichts anderes
als ein zweiter Weg zu derselben Handlung: 101 fertige Aufgaben statt
einer selbst getippten.
WAS DER ERSTE ANLAUF ZERSTOERT HAETTE. Der Block enthaelt ZWEI
Kataloge, und sie gehen an zwei verschiedene Personenkreise -- das
entscheidet der Server. Team Dogi bekommt die 101 Aufgaben in 14
Kategorien, die Agentur den Creator-Katalog (vier Bereiche, vier
Stufen). Ihn einfach herauszuschneiden und drueben hinzulegen haette
dem zweiten Katalog die Heimat genommen. Gemerkt hat das keine
Ueberlegung, sondern die Frage, wer die Zeile "ich.rolle === 'creator'"
eigentlich bedient -- pruef-aufgaben-vorlagen misst sie seit Tagen.
Deshalb eine gemeinsame Datei (vorlagenbrett.js) statt zweier
Abschriften: Die gemeinsamen Teile -- Abruf, Klappkopf, Uebernehmen --
gibt es weiter genau einmal, und jede Seite sagt beim Einrichten, ob
sie den Team- oder den Creator-Zweig zeigt. Fehlt ihr dabei eine
Angabe, sagt die Datei das in der Konsole, statt stumm nichts zu
zeichnen.
WAS DER UMZUG NEBENBEI LOESCHT: Drueben brauchte der Katalog eine
EIGENE Personenwahl, weil es dort keine gab -- eine dritte Knopfreihe
unter zwei anderen, und die Moeglichkeit, oben den einen und unten den
anderen zu waehlen. Hier ist die Person laengst gewaehlt, mitsamt ihren
Zahlen. Eine Auswahl statt zwei.
DREI DINGE, DIE ERST DADURCH AUFFIELEN:
"schon uebernommen" galt im Team-Katalog fuer JEDEN. Sobald irgendwer
eine Vorlage hatte, stand es an der Karte -- auch fuer alle anderen.
Auf einer Seite ohne Personenwahl fiel das kaum auf; hier waere es
offen falsch: Man waehlt Frida, und der Katalog behauptet, sie habe die
Aufgabe schon, weil Rieke sie hat. Der Creator-Zweig machte es von
Anfang an richtig. Und wer verteilt, bekommt ohne gewaehlte Person gar
keine Markierung mehr: "irgendwer hat sie" liest man als "brauche ich
nicht mehr zu vergeben" und ueberspringt, was dem Menschen vor einem
fehlt.
Der Katalog blieb fuer einen Modi GANZ weg. window.__ich kommt ueber
das Netz und ist beim ersten Zeichnen noch nicht da; ein stummes
"return" liess den Block dauerhaft verschwinden, weil niemand ein
zweites Mal zeichnet. Gefunden hat das kein Codelesen, sondern ein
Bildschirmfoto -- die Seite sah vollstaendig aus, nur ohne den Block.
Gewartet wird jetzt mit der Wartestelle des Hauses.
Und er markierte bei einem Modi nichts mehr: Die Aufgabenliste wurde
nur beim Personenwechsel geholt, und ein Modi waehlt nie jemanden.
Damit war die Sperre gegen das zweite Uebernehmen derselben Vorlage
weg. Jetzt gibt es einen Abrufweg fuer beide.
Der Knopf nennt den Namen ("An Rieke"), der Satz darueber auch. Statt
einer Wegbeschreibung zur Personenwahl steht ein Knopf, der hinfuehrt
-- "waehle oben" waere falsch, die Kacheln stehen weiter unten. Und
"auf dem Brett darunter" stimmt hier nicht mehr: Der Kopftext sagt
jetzt, WAS entsteht, nicht WO es landet.
Gemessen: pruef-modi-katalog 129 (vorher 125), pruef-modi-kategorien
29 (vorher 25 mit 3 Fehlern), pruef-aufgaben-vorlagen, pruef-struktur
und pruef-css-klassen alles in Ordnung. Dazu eine Abnahme ueber beide
Seiten und drei Rollen: 32 Messungen, 0 Befunde -- darunter die
Gegenprobe, dass Marinas uebernommene Aufgabe bei Frida NICHT als
uebernommen gilt.
Die 403-Zeilen in pruef-modi-kategorien waren ebenfalls eine Altlast:
Seit dem 22.09. legt im Team Dogi nur die Leitung an ("sie sich nicht
selber aufgaben geben"), die Pruefung tat es weiter als Modi. Sie misst
das jetzt -- samt der Gegenprobe, die es vorher nicht gab.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
b1319e3124 |
Aufgabenbrett: eine Karte ist ein Stueck Arbeit, keine Tabellenzeile
Filipe: "so wie alles gerade ist ist es zu wenig und zu viel zu
gleich". Die Zahl dahinter, an der echten Datenbank gemessen: 115
offene Aufgaben -- aber nur 17 verschiedene. Jede stand acht Mal da.
URSACHE, nicht Symptom: Am 22.09.2026 wurde dieselbe Vorlage zweimal
verteilt, nachgemessen zwischen 16:05:24 und 16:05:53. Zweimal
gedrueckt, weil beim ersten Mal scheinbar nichts passierte. 56 der
115 Karten sind exakte Doppelte.
WAS SICH AENDERT
Aufgaben mit gleichem Titel, gleicher Frist und gleicher Kategorie
stehen jetzt als EINE Karte da: "0 von 8", ein Balken, und die Leute
als Pillen in ihrer Statusfarbe. Wer sie doppelt hat, traegt x2.
Der Hinweis auf die Doppelten steht EINMAL ueber dem Brett, mit Zahl
-- nicht siebzehnmal an den Karten. Eine Warnung, die auf jeder Karte
steht, ist Tapete (Lehre vom 03.09.2026).
Die Spalten wachsen nach dem, was sie tragen: "Offen" mit 17 Karten
bekam vorher genauso viel Platz wie "Erledigt" mit einer -- beide
369 px, gemessen. Innerhalb der Spalte legen sich die Karten
nebeneinander, sobald Platz da ist (auto-fill, keine feste Spaltenzahl).
Das Vorlagenbrett steht oben, solange das Brett leer ist, und wandert
darunter, sobald etwas daliegt. Die urspruengliche Begruendung ("wer
ein leeres Brett hat, soll nicht daran vorbeiscrollen") gilt nur fuer
den leeren Fall.
Am Handy wird aus "Wer hat gerade was" eine wischbare Reihe statt
gestapelter Pillen, mit Randschattierung als Hinweis, dass es
weitergeht.
GEMESSEN (echte Datenlage: 17 Vorlagen, vier Leute, doppelt verteilt)
Computer 46 077 px -> 2 445 px (18,8-fach kuerzer)
Handy 44 216 px -> 5 763 px ( 7,7-fach kuerzer)
Brett beginnt am Handy bei 798 statt 901 px -- die erste Aufgabe
ist damit ohne Scrollen sichtbar.
DREI BEFUNDE NEBENBEI, ALLE VON MIR
1. team.css: Der Schreiben-Knopf auf der Team-Lage stand bei 42 px.
Am 22.09. habe ich beim Kartenumbau das Polster von 10 auf 9 px
gesenkt und ihn damit unter die Hausregel gedrueckt. Jetzt
min-height statt Polsterrechnung -- die Hoehe haengt nicht mehr
daran, ob jemand spaeter an der Schriftgroesse dreht.
2. chat.css: Die Knoepfe der Aufnahmeleiste standen bei 40 px, der
Weg-Knopf der GIF-Kiste bei 28. Beide in der Nacht zum 23.09.
gebaut. Die Leiste bekommt volle 44 px; der GIF-Knopf bleibt klein
sichtbar und waechst nur in der TREFFERFLAECHE (28 + 2x8 = 44),
und das nur am Finger -- mit der Maus zielt man genau, eine
unsichtbar vergroesserte Flaeche waere dort eine Falle.
3. pruef-chat-anhaenge meldete "aus der Kiste genommen (1 uebrig)".
Kein Codefehler: Die Pruefung setzte `window.confirm = () => true`,
und heute frueh ist dort der Hausdialog an die Stelle getreten. Sie
klickte, die Seite fragte, niemand antwortete. Genau der Fall, vor
dem der Kopf von helfer-nachfrage.mjs seit dem 19.09. warnt -- zum
zweiten Mal, an einer neuen Stelle. Jetzt ueber `bestaetige`, und
damit prueft die Zeile ab sofort mit, DASS gefragt wird.
PRUEFUNGEN
pruef-modi-katalog zaehlte Karten und erwartete +1. Seit der
Gruppierung ist das die alte Anordnung, nicht die Sache: Sie zaehlt
jetzt AUFGABEN ueber data-id/data-ids und meldet "2 -> 3 Aufgaben in
2 Karten" -- damit ist beides belegt, das Anlegen und das
Zusammenfassen.
Alles gruen: aufgabenbrett 49, zuteilung 75, bewerbung-aufgaben 101,
modi-katalog 125, chat-anhaenge 109, chat-optik 56, tippziele 11,
teamlage-karten 39, sprung 43, textform 50, formulare 23,
css-klassen 33, zeichen 7, ueberlappung (20 Paare).
Handy-Rundgang: 220 Seitenaufrufe, 112 776 Elemente, 0 Befunde.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
bff7c6ce14 |
Chat: die Schreibzeile auf dem Handy -- Feld 130 -> 278 px
Filipe schreibt vom Handy. In der Schreibzeile stehen seit heute Nacht
SECHS Dinge: Bueroklammer, Mikrofon, GIF, Emoji, Schreibfeld, Senden --
das Mikrofon und das GIF habe ich selbst dazugestellt.
GEMESSEN, BEVOR ICH ETWAS ANGEFASST HABE (mit echtem Finger, weil
`pointer: coarse` sonst gar nicht greift):
320 px Feld 164
390 px Feld 130 -- und "Senden" ALLEIN auf einer eigenen Zeile
412 px Feld 151 -- dito
Das Feld lag auf seiner Untergrenze von 8 rem. Kaputt war nichts --
nichts ueberlappte, nichts war zu klein --, aber man sah beim Tippen
etwa zwoelf Zeichen, und der Knopf, der die Nachricht wegschickt, war
weiter vom Text entfernt als die Bueroklammer.
Das ist derselbe Fehler wie am 06.09.2026 in anderer Gestalt: Damals
kam ein sechstes Element in die Kopfleiste, und bei 412 px lag ein
Knopf ueber dem anderen.
ZWEI GRUPPEN STATT SECHS EINZELTEILE
------------------------------------
chat__werkzeuge Bueroklammer, Mikrofon, GIF, Emoji
chat__schreibzeile Feld und Senden
Damit bricht die Zeile an der richtigen Stelle: Die Werkzeuge wandern
GEMEINSAM nach oben, Feld und Senden bleiben zusammen. Und ein siebtes
Werkzeug laesst kuenftig die Gruppe wachsen, nicht das Feld schrumpfen
-- das ist der Unterschied zwischen einer Regel und einer Zahl, die man
beim naechsten Knopf neu suchen muss.
DER EMOJI-KNOPF IST ZU DEN WERKZEUGEN GEWANDERT. Er sass neben
"Senden", und auf dem Handy landeten damit Emoji und Senden gemeinsam
unten links. Ein Emoji ist dasselbe wie eine Bueroklammer: etwas, das
man in den Text einfuegt. Senden ist das Gegenteil.
NACHHER:
320 px Feld 214 390 px Feld 278
412 px Feld 299 1280 px Feld 560
Auf dem Handy drei Zeilen (Werkzeuge / F K U S / Feld+Senden), am
Rechner alles nebeneinander.
DIE 10 rem SIND GEMESSEN, NICHT GESCHAETZT
------------------------------------------
Durchgespielt wurden 8, 10, 11, 12 und 13 rem auf 320, 390 und 412 px.
Ab 11 rem kommt auf 320 px eine VIERTE Zeile dazu -- also schlechter
dort, wo der Platz ohnehin am knappsten ist. 10 rem verbessert 390 und
412 deutlich, ohne 320 zu verschlechtern. Die Messreihe steht im
Kommentar; wer daran dreht, misst bitte wieder nach.
EIN ZWISCHENSTAND, DEN ICH VERWORFEN HABE
-----------------------------------------
Der erste Versuch gruppierte nur Feld+Senden und liess Emoji stehen.
Gemessen: Feld 160 statt 180 -- schlechter als der Zustand davor. Ich
habe ihn zurueckgenommen, statt ihn schoenzureden. Was ich nicht
messen kann, liefere ich nicht aus.
GEPRUEFT
--------
pruef-chat-optik: die Schreibzeile ist jetzt Teil der Pruefung.
Breite des Feldes, Senden neben dem Feld, nichts ueberlappt, alles am
Daumen treffbar, kein Querscrollen -- und am Rechner das Gegenteil:
Dort MUESSEN die Werkzeuge daneben stehen, sonst waere die Zeile
unnoetig hoch.
GEGENPROBE mit der alten Fassung: 5 Zeilen werden rot, darunter genau
die beiden Symptome von oben (Feld 130, Senden eine Zeile tiefer).
UND ZWEI EIGENE FEHLER IN DER PRUEFUNG, BEIDE VON DER GEGENPROBE
GEFUNDEN:
* Sie mass mit einem SCOUT -- und der bekommt Mikrofon und GIF gar
nicht zu sehen. Gemessen wurde eine Zeile mit zwei Dingen darin,
waehrend der gefaehrliche Fall der mit vier ist. Aufgefallen, weil
die Gegenprobe 178 px meldete und meine Handmessung 130: zwei
Zahlen fuer dieselbe Sache.
* Eine Zeile war gruen mit `undefined`: Es gab die Gruppe nicht,
`y` war undefiniert, und `(undefined || 0) < 834` ist wahr. Ein
gruener Haken, der nichts angesehen hat -- genau die Sorte, vor
der die Hausregeln warnen.
pruef-chat, pruef-erwaehnung (119), pruef-chat-anhaenge (109):
unveraendert gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
036f30454c |
Vorlagenbrett: was wartet, steht jetzt ganz oben -- quer ueber alle Kategorien
EIN LOCH, DAS ICH SELBST GEBAUT HABE ------------------------------------ Die Bewerbungen stehen an ihrer Karte, und das ist richtig: Man entscheidet ueber eine bestimmte Aufgabe, und ihr Text ist die halbe Auskunft. Nur steht die Karte in EINER von vierzehn Kategorien. Bewirbt sich Frida unter "Wachstum" und DogFather oeffnet wie immer "Chat-Moderation", sieht er nichts -- die Bewerbung ist da, das Brett ist offen, und trotzdem findet er sie nie. Die Benachrichtigung von heute frueh hilft, aber sie ist ein Moment: Wer sie wegwischt, hat keinen zweiten Weg mehr. Ein Brett, auf dem etwas wartet, muss das selbst sagen koennen. Jetzt steht ganz oben, ueber den Kategorie-Reitern: "Eine Bewerbung wartet auf deine Antwort: Marina · Zehn Neue fragen, wie sie hergefunden haben". Ein Tippen springt in die richtige Kategorie, zur richtigen Karte, und hebt sie zwei Sekunden hervor. DER SPRUNG STELLT AUCH DIE STUFE ZURUECK. Ohne das landet man in der richtigen Kategorie und sieht trotzdem nichts, weil der Stufenfilter die Karte gerade ausblendet -- eine Reise ins Nichts ist schlimmer als kein Knopf. ES DIENT BEIDEN SEITEN, und deshalb steht es nur einmal da: Wer entscheidet, liest "wartet auf deine Antwort"; wer sich beworben hat, liest "du hast dich beworben". Der Server schickt ohnehin jedem nur, was ihn angeht. UND WIEDER: ERST STAND DIE ABSICHT NUR IM KOMMENTAR ---------------------------------------------------- Im Kommentar stand "ES STEHT GANZ OBEN, ueber den Kategorie-Reitern". Der Code haengte es darunter -- gesehen auf dem Bildschirmfoto, nicht beim Lesen. Das ist heute das zweite Mal (nach "gleiche Mittel, gleiche Staerke" bei den Handkarten). Ein Kommentar, der eine Absicht beschreibt, erfuellt sie nicht; ich schreibe sie offenbar gern auf, bevor ich sie baue. VORHER GEMESSEN, NICHT VERMUTET ------------------------------- Rundgang als Modi, 390 px, ueber alle 27 Kacheln der Startseite -- die Liste aus den Kacheln GELESEN, nicht aufgeschrieben. Ergebnis: kein Querscrollen, keine zu kleinen Ziele, kein Text auf Text, keine Konsolenfehler. 27 von 27 sauber. Dabei sah ich im Chat einen magentafarbenen Kasten ohne Beschriftung und hielt ihn fuer kaputt. Nachgemessen mit echtem Finger (hasTouch): 44x44-Knopf, 36x36-Farbprobe, quadratisch -- und am Laptop 30x30 / 22x22, ebenfalls quadratisch. Der schmale Balken entstand nur in meinem Messaufbau (390 px OHNE Beruehrung), also in einer Lage, die kein Geraet hat. Kein Fehler, und ich habe nichts "repariert", was nicht kaputt war. GEPRUEFT -------- pruef-modi-katalog: 125 Pruefungen, 0 Fehler (vorher 116). Gemessen wird genau der Fall, um den es geht: eine Bewerbung in einer Kategorie, die gerade NICHT gewaehlt ist. Dazu der Sprung (landet auf der richtigen Karte, und dort stehen Annehmen und Ablehnen), die Daumengroesse (40 px) und der Wortlaut. MIT GEGENPROBE, und die ist der Kern: Wartet nichts, steht auch nichts da. Ohne sie bewiese alles darueber nur, dass das Band immer dasteht -- und ein Hinweis, der immer da ist, wird ueberlesen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
db8ad683a1 |
Der verborgene Rollenname stand offen im Netz -- seit dem 22.09.
Gefunden beim Bauen des Vorlagenbretts, nicht gesucht:
pruef-modi-wortleck war ROT, und zwar seit einem Tag. Sieben
Fundstellen in zwei Dateien, die JEDER bekommt, der die Seite oeffnet
-- ohne Anmeldung, aus dem offenen Netz:
assets/css/team.css --ton-modi, .tmerkmal--r-modi,
.t-gruppe[data-rolle="modi"]
assets/js/teamlage.js die Woerter-Tabelle und drei Rueckfaelle
DER ZUGANG HAELT GENAU SO LANGE, WIE NIEMAND DEN NAMEN IM QUELLTEXT
FINDET. Genau dafuer gibt es diese Pruefung: Am 10.09. hatte ich
denselben Fehler schon einmal gemacht und ihn durch Nachsehen
gefunden, nicht durch Nachdenken -- Nachdenken hatte ich vorher
getan. Seither ist die Regel ein Werkzeug statt eines Vorsatzes.
Nur: Das Werkzeug hat einen Tag lang rot geleuchtet, und niemand hat
hingesehen. Das ist der eigentliche Befund an diesem Commit, und er
steht auch in der Vault-Notiz.
WAS SICH AENDERT
----------------
Die Woerter kommen jetzt vom Server (`rolle_name` aus ROLLEN_NAME) --
so wie ueberall sonst im Haus. Der Browser fuehrt keine eigene Liste
mehr; zwei Listen fuer dieselbe Sache waeren ohnehin zwei
Gelegenheiten, dass eine veraltet.
DIE DREI RUECKFAELLE SIND WEG (`|| 'modi'`, `|| 'Modi'`). Am 21.09.
wurde genau so einer an einer vierten Stelle entfernt, mit zwei
Gruenden: Er schreibt den Namen in eine ausgelieferte Datei, und er
hat noch nie etwas bewirkt -- der Server liefert die Rolle immer mit.
Beides galt fuer diese drei ebenso; sie waren damals nur uebersehen
worden. Fehlt die Rolle jetzt doch einmal, bleibt das Merkmal weg
statt falsch.
DER DRITTE FARBTON HEISST NACH SEINER AUFGABE, nicht nach seinem
Traeger: aus `--ton-modi` wird `--ton-team`, der Grundton des Teams.
Die beiden Haende weichen davon ab -- damit braucht die dritte Rolle
gar keinen eigenen Wahlausdruck mehr, und ihr Name steht nirgends in
der Datei. Das ist nicht nur unverfaenglich, es ist auch richtiger:
Eine Farbe gehoert einer Rolle nicht, sie steht fuer sie.
GEPRUEFT
--------
pruef-modi-wortleck: BESTANDEN, 8 von 8 (vorher 1 Fehler).
Ihre eigene Gegenprobe laeuft mit: eine eingebaute Fundstelle wird
erkannt, und "modifiziert", "Modul", "motion", "Modus" schlagen nicht an.
pruef-teamlage-karten: 39 von 39 weiter gruen -- darunter die Zeilen,
auf die es hier ankommt: "jede Karte nennt ihre Rolle im Klartext
(keine Luecke)" und "jede Ueberschrift nennt ihre Rolle und ihre
Anzahl richtig (Rechte Hand 1 · Linke Hand 1 · Modi 5)". Die Woerter
kommen also weiterhin an, nur aus einer anderen Quelle.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e736a12cff |
Vorlagenbrett: Modis bewerben sich, DogFather und die rechte Hand entscheiden
Filipe: "die modis sollen bei all diesen voschlaegen auch nur bewerben
koennen. die aufgaben aus der vorlage, da sollen die modis sich nur
bewerben koennen und nur dogfather und die rechte hand sollen annehmen
oder ablehnen koennen, mit einem text als notiz."
WAS SICH AENDERT
----------------
Auf dem Vorlagenbrett steht fuer einen Modi jetzt "Bewerben" statt
"Uebernehmen". Wer sich beworben hat, sieht das an der Karte -- samt
dem Satz, WER antwortet, und einem Weg zurueck. DogFather und die
rechte Hand sehen die Bewerbung an derselben Karte, mit Namen und dem
Wort dazu, und daneben "Annehmen" und "Ablehnen". Beide fragen nach
einer Notiz.
"ALSO NUR" GILT AUCH AM SERVER, nicht nur im Browser: Die alte Tuer
antwortet einem Modi mit 403 und dem Satz, was stattdessen geht. Ein
ausgeblendeter Knopf ist eine Bitte, abgelehnt wird in der Route.
DIE LINKE HAND STEHT ABSICHTLICH NICHT BEI DEN ENTSCHEIDERN
------------------------------------------------------------
Sie gehoert seit dem 22.09. ueberall dazu ("ich will dass die linke
hand auch ueberall zu sehen ist"). Hier hat Filipe genau zwei genannt.
Das ist keine Vergesslichkeit von mir, sondern seine Aufzaehlung -- und
dieselbe Grenze zieht das Haus schon bei den Aufgaben-Bewerbungen
(entscheidetUeberAufgaben). Sie darf weiter VERTEILEN; das hat er nicht
angefasst.
Sie ist deshalb die schaerfste Probe in der Pruefung: Wer statt "darf
entscheiden" nur "darf verteilen" abfragt, laesst sie mitentscheiden --
und niemandem faellt es auf, weil alles funktioniert.
DIE AUFGABE ENTSTEHT ERST MIT DER ZUSAGE
----------------------------------------
Der naheliegende Weg waere gewesen, beim Bewerben gleich die Aufgabe
anzulegen und die vorhandene Bewerbung aus aufgaben_zuteilung
daranzuhaengen. Dann stuende nach zwoelf Absagen zwoelfmal Arbeit auf
dem Brett, die niemand bestellt hat -- und um das einzufangen, muesste
das Ablehnen Aufgaben LOESCHEN. Loeschen als Nebenwirkung einer Absage
ist genau die Sorte Regel, die irgendwann das Falsche trifft.
Also eine eigene, kleine Tabelle (vorlagen_bewerbungen). Bis jemand ja
sagt, gibt es nur eine Zeile. Die Woerter sind dieselben wie drueben
(zustand, entscheid_text, entschieden_von) -- zwei Namen fuer dieselbe
Sache waeren zwei Sprachen im selben Haus.
Und die Zusage legt die Aufgabe ueber DIESELBE Funktion an wie das
Uebernehmen (katalogAufgabeAnlegen, neu, aus dem Katalog-Zweig
herausgeloest). Damit sieht eine erbetene Aufgabe aus wie eine
verteilte: gleiche Frist, gleiche Kategorie, gleiche Kennung. Ein
zweiter Weg waere ein zweiter Satz Regeln.
KLEINIGKEITEN, DIE SONST WEHTUN
-------------------------------
* "Alle 12 uebernehmen" gibt es nur fuer die, die verteilen. Ein
"Alle bewerben" waere der schnellste Weg, zwoelf Bitten auf einmal
loszuschicken -- und damit zwoelf Entscheidungen fuer jemand anderen.
* Wer eine Aufgabe schon hat, bekommt keinen Bewerben-Knopf. Der
Server lehnt das ohnehin ab; ein Knopf, der eine Absage holt, ist
schlimmer als keiner.
* Nach einer Absage darf man sich wieder bewerben. Der eindeutige
Index gilt deshalb nur fuer OFFENE Bewerbungen -- ueber alle
Zustaende waere eine Absage ein Bann.
* Gesucht wird ueber den SCHLUESSEL der Vorlage, nicht ueber die
Nummer in der Liste. Die Nummer verschiebt sich, sobald jemand eine
Vorlage einfuegt -- genau dieser Fehler ist am 16.09. schon einmal
passiert.
GEPRUEFT
--------
pruef-modi-katalog: 95 Pruefungen, 0 Fehler (vorher 49).
Die Pruefung ist beim Umbau ROT geworden -- 9 Zeilen, alle dort, wo ein
Modi sich selbst etwas nahm. Richtig so, sie hat die Aenderung bemerkt.
Sie steht jetzt auf dem neuen Weg und misst ihn ganz:
* der Modi kommt an die alte Tuer nicht mehr heran (403, erst_bewerben)
* die Bewerbung legt NOCH KEINE Aufgabe an
* die linke Hand darf verteilen, aber nicht entscheiden (403)
* der Bewerber selbst erst recht nicht (403)
* die Zusage erzeugt die Aufgabe -- mit Kategorie, Frist, Besitzer
* die Notizen stehen in der Datenbank, samt WER entschieden hat
(direkt gelesen: ein Feld, das der Server annimmt und nirgends
speichert, saehe von aussen genauso aus)
* nach einer Absage geht es wieder
* am Bildschirm: alle Knoepfe heissen "Bewerben", kein einziger
"Uebernehmen" mehr, die wartende Karte nennt, wer antwortet --
und DogFather klickt sich durch Annehmen samt Notizfeld, bis die
Aufgabe auf dem Brett steht
Die Gegenprobe in Abschnitt 7 lief mit dem Zugang des Modis und haette
ab heute nur noch bewiesen, dass die Rechtepruefung greift -- sie
benutzt jetzt DogFather. Genau so verliert eine Pruefung still ihren
Sinn.
pruef-aufgaben-vorlagen: unveraendert gruen.
ZWEI FUNDE NEBENHER, BEIDE AELTER ALS DIESE AENDERUNG -- gemessen, nicht
vermutet (mit gestashten Aenderungen gegengeprueft):
* pruef-modi-wortleck ist seit dem 22.09. rot: Der Rollenname steht
in team.css und teamlage.js, also in Dateien, die jeder bekommt.
* pruef-zuteilung stuerzt seit laengerem ab (#neu-oeffnen ist
verborgen). Beides kommt als naechstes, getrennt.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
256ea6f7c0 |
Team-Lage: die linke Hand traegt ihre Farbe -- und die rechte genauso
Filipe, mit dem Bildschirmfoto der Team-Lage: "die farbe der kachel soll die gleiche sein wie die farbe die der text linke hand hat, aber mach es richtig knallig so wie die farben bei den modis und linke hand. soll schoen auffallen bitte." AUF DEM FOTO WAR GENAU DAS DAS PROBLEM -------------------------------------- Die Marke "Linke Hand" leuchtet lila, die Karte darunter war fast farblos: Sie fiel auf den Ton der STUFE zurueck -- dieselbe Lage wie bei der rechten Hand vor dem 20.09. "DIE GLEICHE FARBE" IST NICHTS, WAS MAN AUFSCHREIBT --------------------------------------------------- Es ist etwas, das man ABLEITET. `#f0c14b`, `#d8a7f5` und `#8fd6ff` standen bisher verteilt in den Dateien: bei der Gruppenueberschrift, bei der Rollenmarke, und das Gold ein drittes Mal in module.css an der Karte. Drei Orte fuer dieselbe Farbe sind drei Gelegenheiten, dass einer beim naechsten Anstrich nicht mitgeht -- und dann traegt die Marke ein anderes Lila als die Karte, auf der sie liegt. Jetzt stehen die drei Toene an einer Stelle (:root in team.css) und werden ueberall von dort geholt. Auch die Namensfarbe ist abgeleitet statt aufgeschrieben: Sie war `#f7e3ac` und (im ersten Anlauf fuer die linke Hand) `#f2ddff` -- beides nichts anderes als "der Ton, stark aufgehellt". ICH HAETTE FAST EINE RANGORDNUNG GEBAUT --------------------------------------- Erst habe ich nur die linke Karte angefasst: Lila startet bei 34 % Ton, das Gold lag weiter bei den 11 %, die jede Karte hat. Nebeneinander sah die rechte Hand ploetzlich aus wie die schwaechere von beiden -- eine Rangordnung, die niemand bestellt hat. Daneben stand mein eigener, gerade erst geschriebener Kommentar: "gleiche Mittel, gleiche Staerke". Ein Kommentar, der eine Absicht beschreibt, erfuellt sie nicht. Jetzt EINE Regel fuer beide Haende; der Unterschied ist der Ton und sonst nichts. Wer morgen an der Wirkung dreht, dreht sie fuer beide. "RICHTIG KNALLIG" IST EINE ANWEISUNG, KEINE STIMMUNG ----------------------------------------------------- Deshalb tragen diese beiden Karten ihre Farbe auch in der FLAECHE und nicht nur an der Kante. Augenschonend bleibt es trotzdem, und das ist kein Widerspruch, sondern die Bedingung: kraeftig heisst GESAETTIGT, nicht hell. Der Grund bleibt sehr dunkel, die Farbe liegt als Verlauf darueber. Gemessen bei 1280 und 390 px, am gezeichneten Bildschirm: linke Hand Name 15,11:1 · Kleingedrucktes 8,18:1 · Marke 11,18:1 rechte Hand Name 15,63:1 · Kleingedrucktes 8,07:1 · Marke 12,49:1 Verlangt sind 4,5. MEINE ERSTE MESSUNG WAR FALSCH, UND SIE SAH ECHT AUS ----------------------------------------------------- Sie las `rgb(13, 8, 23)` und `color(srgb 0.87 0.71 0.96)` mit derselben Rechnung. Die zweite Schreibweise zaehlt aber in 0..1, nicht in 0..255 -- die helle Rollenmarke kam damit auf 1,09:1. Eine Zahl, die aussieht wie ein schwerer Befund und keiner ist; haette ich ihr geglaubt, haette ich eine funktionierende Farbe "repariert". Die Umrechnung steht jetzt ausgeschrieben in der Pruefung, samt Grund. GEPRUEFT -------- pruef-teamlage-karten: 39 Pruefungen, 0 Fehler (vorher 25). Neu darin: Traegt die Karte denselben Ton wie ihre Marke? Sind es zwei verschiedene Toene? Liegt die Farbe in der Flaeche? Tragen beide Haende dieselbe Staerke? Und: kann man den Text darauf noch lesen? Mit Gegenproben, die beide Richtungen abdecken: Eine Modi-Karte traegt die Leiste NICHT (sonst faellt keine auf), und mit absichtlich falschem Ton auf der linken Karte werden genau zwei Zeilen rot -- gemessen. Kein Neustart noetig: Es aendert sich nur Ausgeliefertes (CSS, Stempel) und eine Pruefdatei, die der Dienst gar nicht laedt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5e503463f5 |
Chat: die GIF-Kiste des Rudels -- und eine Luecke in der Sicherung
Filipe: "dan will ich auch dass man im chat auch sprachnachrichten und
gifts reinschicken kann. also nur die modis rechte linke hand und
dogfather."
ICH LESE "gifts" ALS GIFs -- die bewegten Bildchen -- und sage das
ausdruecklich, statt es stillschweigend anzunehmen. Im Zusammenhang
("im chat reinschicken", direkt neben Sprachnachrichten) passt nichts
anderes. Sollte er Geschenke gemeint haben, sagt er es, und dann baue
ich das.
EINE EIGENE KISTE STATT GIPHY ODER TENOR
----------------------------------------
Beide brauchen ein Konto und einen Schluessel und bekommen bei jedem
Tastendruck mit, wonach hier gesucht wird -- an eine fremde Firma, aus
einem Arbeitsplatz heraus, in dem sonst nichts nach aussen geht. Dazu
kosten sie ab einer Menge Geld. Beides steht quer zu dem, wie dieses
Haus gebaut ist.
Die Kiste laeuft auf demselben Server wie alles andere, kostet nichts
und wird mit der Zeit besser statt schlechter: Was darin liegt, hat das
Team ausgesucht. Zehn gute GIFs, die alle kennen, sind im Alltag mehr
wert als zehn Millionen fremde -- ein Katalog mit allem ist nicht mehr
Auswahl, sondern weniger.
HABEN WIR DAS SCHON? WIRD AM INHALT BEANTWORTET
-----------------------------------------------
Der Schluessel ist der SHA-256 der Datei. Ueber den NAMEN zu
vergleichen waere die naheliegende Abkuerzung -- und sie versagt genau
dort, wo Dateien "giphy.gif", "giphy(1).gif" und "download.gif"
heissen, also fast immer. Dasselbe Bild waere dreimal dieselbe Kachel.
Dasselbe GIF zweimal hineinzulegen ist deshalb KEIN Fehler: Es ist
drin, und genau das wollte man. Eine Absage waere formal richtig und im
Erleben falsch.
DAS WICHTIGSTE STUECK: ES WIRD KOPIERT, NICHT VERWIESEN
-------------------------------------------------------
Eine Nachricht zurueckzunehmen entfernt ihre Datei von der Platte. Laege
ein Kachel-GIF in demselben Ordner und mehrere Nachrichten zeigten
darauf, naehme das Zuruecknehmen EINER Nachricht das GIF fuer alle
anderen mit -- und in drei Gespraechen stuende ab da ein kaputtes Bild.
Das ist die Sorte Fehler, die erst Wochen spaeter auffaellt und dann
nicht mehr zu reparieren ist.
Deshalb liegt die Kiste in einem eigenen Ordner (chat-gifs/), und beim
Verschicken wird kopiert. Danach ist es ein ganz normaler Anhang: im
Verlauf, in der Suche, zuruecknehmbar, unter derselben Nachtruhe. Keine
zweite Sorte Nachricht mit eigenen Rechten und eigenem Loeschen.
Geprueft wird genau das: GIF hineinlegen, verschicken, aus der Kiste
nehmen -- und danach steht das verschickte immer noch im Gespraech.
"ALSO NUR" GILT AUCH HIER
-------------------------
Ansehen, hineinlegen, verschicken: alle drei nur fuer Team Dogi und
DogFather (istTeamDogi). Der Satz stand im selben Atemzug wie die
Sprachnachrichten; es gibt keinen Grund, warum er fuer das eine gelten
sollte und fuer das andere nicht. Gemessen auch am Knopf vorbei:
403/403/403.
AUGENSCHONEND -- HIER EINE ECHTE FRAGE, KEINE FORMSACHE
--------------------------------------------------------
Zwoelf gleichzeitig laufende Bildchen sind das Gegenteil von ruhig. Wer
"Bewegung reduzieren" gesetzt hat, bekommt deshalb STEHENDE Bilder: das
erste Einzelbild, im Browser auf eine Zeichenflaeche gemalt (kostet
keine zweite Datei), und es laeuft erst, wenn man es anfasst oder mit
der Tastatur darauf steht.
Fuer alle anderen laufen sie. Eine GIF-Auswahl, in der sich nichts
bewegt, ist eine, in der man nicht sieht, was man verschickt -- deshalb
steht dazu eine Gegenprobe in der Pruefung.
NEBENBEFUND, UND ER WIEGT SCHWERER ALS DIE GIFS
-----------------------------------------------
Weil die Kiste einen neuen Datenordner braucht, lief
tools/wiederherstellung-proben.mjs -- und meldete, dass der Ordner
"material" seit dem 22.09. NICHT gesichert wird. 2,4 MB
Materialbibliothek auf dem Server, nach einem Plattenausfall weg, ohne
dass die taegliche Meldung je etwas gesagt haette. Genau die Luecke,
wegen der diese Probe ueberhaupt gebaut wurde -- und sie hat sie
gefunden, weil sie die Ordner aus dem QUELLTEXT liest statt aus einer
gepflegten Liste.
Eingetragen. Danach frisch geholt und zurueckgespielt: 18 von 18 gruen,
"DIE SICHERUNG LAESST SICH ZURUECKSPIELEN" (vorher 3 Fehler).
Dabei war die Gegenprobe daneben selbst kaputt: Sie prueft, ob ein
erfundener Ordner als fehlend erkannt wird, und verlangte dafuer
`=== 1`. Das setzt voraus, dass sonst nichts fehlt. An dem Tag, an dem
wirklich etwas fehlte, wurde sie rot und zeigte damit auf sich selbst
statt auf den Fund -- zwei Meldungen, eine Ursache, und die zweite
lenkt von der ersten ab. Jetzt zaehlt sie die Differenz.
GEPRUEFT
--------
pruef-chat-anhaenge: 109 Pruefungen, 0 Fehler (vorher 86, davor 60).
pruef-chat, pruef-chat-aufloesen (126), pruef-chat-optik: gruen.
tools/wiederherstellung-proben: 18 von 18.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2d14907d0d |
Chat: Sprachnachrichten -- und ein stiller Fehler, der jedes Foto betraf
Filipe: "dan will ich auch dass man im chat auch sprachnachrichten und
gifts reinschicken kann. also nur die modis rechte linke hand und
dogfather."
Dieser Commit macht die Sprachnachrichten. Die GIFs kommen als
naechstes -- ich lese "gifts" als GIFs und sage das ausdruecklich,
statt es stillschweigend anzunehmen.
AUFNEHMEN: TIPPEN, NICHT HALTEN
-------------------------------
Gedruecktbleiben ist der bekanntere Weg und der schlechtere: Wer beim
Sprechen verrutscht, verliert die ganze Aufnahme, und mit einer Hand am
Kaffee haelt niemand neunzig Sekunden still. Einmal tippen startet, das
Haekchen schickt, das Kreuz verwirft.
Drei Minuten Hoechstdauer, danach stoppt sie von selbst -- und schickt
NICHT von selbst ab. Wer die Grenze erreicht, hat gerade mitten im Satz
aufgehoert; das ungefragt zu verschicken waere die schlechteste Sekunde
dafuer.
Unter einer Sekunde wird gar nichts geschickt: Das ist ein Versehen,
kein Inhalt.
Die Aufnahmespur wird beim Beenden UND beim Verlassen der Seite
geschlossen. Ein Mikrofon, das offen bleibt, ist ein Vertrauensbruch,
auch wenn niemand zuhoert.
DREI BEHAELTER, WEIL DIE GERAETE DREI LIEFERN
---------------------------------------------
WebM/Opus (Chrome, Android), MP4/AAC (Safari, iPhone), Ogg/Opus
(Firefox). Wer nur einen nimmt, baut eine Funktion, die bei der Haelfte
des Teams stumm bleibt -- und zwar ohne Fehlermeldung.
DER BEHAELTER ALLEIN GENUEGT NICHT: WebM und MP4 tragen genauso gut
Video. Ein Video, das als "Ton" durchginge, landete in einem
Abspielgeraet ohne Bild -- es liefe, man hoerte etwas, und niemand
wuesste, dass die Haelfte fehlt. Die Erkennung sieht deshalb auf die
KENNUNG DER SPUR: Videospur -> abgelehnt, keine Tonspur -> abgelehnt.
Kein MP3: Kein Aufnahmegeraet im Browser erzeugt MP3. Es zuzulassen
hiesse, eine Tuer fuer Musikdateien aufzumachen, nach der niemand
gefragt hat.
"ALSO NUR" IST DER PUNKT
------------------------
Fotos und PDF darf jeder schicken, auch Creator -- das war eine
Entscheidung vom 09.09. und bleibt. Ton nicht. Geprueft wird in der
Route (istTeamDogi), nicht nur im Browser: Ein ausgeblendeter Knopf ist
eine Bitte, abgelehnt wird erst am Server.
Eigene Byte-Grenze fuer Ton (4 MB statt 12). Zwoelf Megabyte sind fuer
ein Foto richtig und fuer eine Sprachnachricht sinnlos -- das waeren
rund fuenfzig Minuten am Stueck.
Die Laenge kommt vom Absender und ist damit eine BEHAUPTUNG, keine
Messung; das steht so an der Spalte. Sie dient nur der Vorschau, bis
das Abspielgeraet die wahre Laenge kennt. Was schuetzt, sind die Bytes.
"FOTO"/"PDF" STAND AN VIER STELLEN
----------------------------------
Dieselbe Aufzaehlung in Gespraechsliste, Zitat, angehefteter Nachricht
und Benachrichtigung -- jede mit ihrem eigenen Fragezeichen-Doppelpunkt.
Mit der Sprachnachricht waeren es vier Aenderungen gewesen, und die
vierte ist die, die man vergisst. Jetzt anhangWort() an einer Stelle.
DER FUND: JEDES FOTO MELDETE "KEINE VERBINDUNG"
-----------------------------------------------
Beim Anfassen derselben Funktion aufgefallen: In `anhangSchicken` stand
seit dem 19.09. `const { nachricht } = e.daten;` -- ein `e`, das es
dort nicht gibt (gemeint war `ergebnis`). Die Zeile wirft, der `catch`
daneben faengt, und der Absender liest:
"Keine Verbindung -- der Anhang wurde nicht geschickt."
Das Foto war aber da. Es kam Sekunden spaeter ueber den Ereignisstrom
in den Verlauf, mit einer roten Meldung darueber, die das Gegenteil
behauptet -- und der getippte Begleitsatz blieb im Feld stehen, also
schickt man es noch einmal.
WARUM DAS VIER TAGE UNBEMERKT BLIEB, und das ist der lehrreiche Teil:
pruef-chat-anhaenge war die ganze Zeit gruen. Sie schickt mit `fetch`
an die Route -- der bequeme Weg, und er prueft den Server gruendlich.
Sie prueft aber nicht den Weg, den ein Mensch geht. Der Fehler lag
hinter der Bueroklammer, und dort hat nie jemand hingesehen. Dazu
fuehlt er sich wie ein Netzproblem an -- und Netzprobleme sucht niemand
im Programm.
Jetzt geht ein Block durch das Dateifeld selbst und sieht auf das, was
der Mensch danach sieht: steht dort eine Meldung, und ist das Feld
leer? Gegenprobe gefahren -- mit dem alten Fehler wieder eingesetzt
werden genau diese zwei Zeilen rot, mit dem Wortlaut von oben.
Uebernommen wird eine frisch geschickte Nachricht jetzt an EINER
Stelle (nachrichtUebernehmen), fuer Anhang und Sprachnachricht. Zwei
Fassungen waeren zwei Gelegenheiten fuer denselben Fehler.
AUGENSCHONEND
-------------
Kein Blinkpunkt waehrend der Aufnahme -- der ist genau das, was die
Hausregel ausschliesst. Der Punkt atmet langsam (1,8 s, 45 bis 100 %)
und steht bei prefers-reduced-motion ganz still; die laufende Zeit
daneben traegt die Auskunft ohnehin.
Die Farben der Sprachnachricht-Blase kommen aus `--blase-leise`, der
fuer DIESE Blase ausgerechneten leisen Schrift. Eine feste Farbe waere
dieselbe Wette, die am 22.09. beim Loeschknopf 1,91:1 auf Babyblau
ergeben hat.
GEPRUEFT
--------
pruef-chat-anhaenge: 86 Pruefungen, 0 Fehler (vorher 60).
Aufgenommen wird mit MediaRecorder im echten Browser ueber den echten
Knopf, mit Chromiums erfundenem Mikrofon. Damit prueft der Abschnitt
nebenbei das, was keine gebastelte Datei pruefen koennte: ob die
Erkennung im Server versteht, was ein Browser wirklich erzeugt
(gemessen: 35 829 Bytes audio/webm, 2743 ms).
* DogFather sieht den Mikrofonknopf, der Scout nicht
* der Scout schickt dieselbe Aufnahme an der Oberflaeche vorbei:
403, und nichts davon ist gespeichert
* ein Video im Ton-Behaelter: 415
* Laenge, Vorlesewort, Bedienbarkeit, preload=metadata, Breite
* "Sprachnachricht" steht in der Gespraechsliste statt einer leeren
Zeile
pruef-chat, pruef-chat-optik: unveraendert gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
28b0143166 |
Chat: "@rudel" ruft das ganze Team -- und nur die vier duerfen es
Filipe: "dan will ich auch dass nur die modis, rechte hand, linke hand
und dogfather, alle auch auf einmal markieren koennen im chat mit
einem, @rudel ,dann sollen alle eine benarichtigung bekommen."
DAS WAR EINE OFFENE FRAGE, UND ER HAT SIE BEANTWORTET
-----------------------------------------------------
In chat-erwaehnung.js stand seit dem 20.09. woertlich: "KEIN @alle. Es
waere in fuenf Minuten gebaut und ist der zuverlaessigste Weg, dass alle
die Benachrichtigungen abschalten -- und dann kommt auch die an, die
wirklich fuer einen bestimmten Menschen gedacht war. Wenn Filipe es
ausdruecklich will, gehoert dazu eine Entscheidung, WER es benutzen
darf; das ist eine Frage an ihn, keine, die ich hier beantworte."
Seine Antwort ist genau diese Entscheidung, und sie ist die Sicherung:
Team Dogi und DogFather duerfen rufen, sonst niemand.
WEN DER RUF ERREICHT: DAS TEAM IM RAUM, NICHT DEN RAUM
------------------------------------------------------
"Rudel" heisst das Team -- dieselben vier Gruppen, die auch rufen
duerfen. In einem Team-Kanal ist das jeder Anwesende, also "alle auf
einmal". Sichtbar wird der Unterschied im TREFF, und dort haette die
andere Lesart wehgetan: Dort sitzt die Community. Ein Ruf, der jeden
Zuschauer weckt, waere etwas anderes als der bestellte -- und beim
zweiten Mal haetten sie die Benachrichtigungen abgeschaltet.
WO WAS ENTSCHIEDEN WIRD
-----------------------
chat-erwaehnung.js bleibt ohne Abhaengigkeiten (die Pruefung soll sie
lesen koennen, ohne einen Server hochzufahren). Sie sagt nur, DASS
gerufen wurde; der Aufrufer sagt ihr, ob der Schreibende darf. Wer zum
Rudel gehoert, entscheidet workspace-chat.js ueber istTeamDogi().
Das Schluesselwort gewinnt gegen einen Menschen, der "Rudel" heisst.
Heute heisst niemand so -- aber das ist eine Tatsache von heute, kein
Gesetz. So herum verliert niemand eine Meldung (wer so heisst, ist im
Rudel dabei); andersherum haette ein einziger Zugang den Ruf ans Team
stillschweigend abgeschaltet.
istTeamDogi() NEU IN workspace.js
---------------------------------
Derselbe Ausdruck ("admin oder TEAM_DOGI_ROLLEN") stand dort dreimal
wortgleich: siehtModis, kanaeleFuer, kategorienFuer. Drei gleiche
Ausdruecke sind drei Gelegenheiten, dass einer beim naechsten
Rollenzuschnitt nicht mitgeht. Jetzt eine Stelle, die drei benutzen.
DIE NACHRICHT MERKT SICH DEN RUF (Spalte chat_nachrichten.rudel)
----------------------------------------------------------------
Beim Lesen muesste der Browser sonst wissen, ob der Absender es DAMALS
durfte. Er kennt nur dessen heutige Rolle -- wechselt jemand die Rolle,
verschwaende die Hervorhebung rueckwirkend aus einem Satz von vorletzter
Woche. Und es waere die zweite Rechnung ueber dieselbe Frage.
Vorgabe 0; alle alten Nachrichten haben kein Rudel gerufen, und das ist
keine Annahme, sondern eine Tatsache: Das Wort gab es noch nicht.
DIE MELDUNG SAGT, WAS LOS IST
-----------------------------
"X hat das Rudel gerufen", nicht "X hat dich erwaehnt" -- letzteres
stimmt beim Rudel nicht, und wer dreimal liest, dass er gemeint sei,
und jedes Mal merkt, dass es alle betraf, glaubt beim vierten Mal auch
dem echten nicht mehr. Auf DEMSELBEN Schalter wie die Erwaehnung: Ein
vierter Schalter waere der, den jemand abschaltet und der dann genau im
wichtigen Moment fehlt. Jeder Ruf steht im Protokoll (chat_rudel) --
"@rudel wird zu oft benutzt" soll eine Zahl sein koennen, kein Gefuehl.
DIE FARBE WIRD ABGELEITET, NICHT GESETZT
----------------------------------------
Eine Nachricht liegt in der Blase, deren Farbe ihr Absender AUSGESUCHT
hat -- siebzehn Moeglichkeiten. Eine feste Farbe darauf ist eine Wette,
und genau die habe ich am 22.09. beim Loeschknopf verloren (1,91:1 auf
Babyblau, gemessen, nachdem es live war). Die Marke nimmt deshalb
`--blase-text` -- die Schrift, die schriftFuer() fuer DIESE Blase mit
mindestens 7:1 ausgerechnet hat. Unterschieden wird ueber Form statt
Farbton: Toenung, Kante, Gewicht 700, ein Zeichen davor. In der
Auswahlliste darf es einen eigenen Ton haben -- sie liegt auf der
Flaeche des Hauses, deren Farbe feststeht.
DER VORSCHLAG ERSCHEINT NUR, WO ER ETWAS BEWIRKT
------------------------------------------------
In einem Zweier-Gespraech mit einem Creator ist ausser mir niemand aus
dem Team. `darf_rudel` fragt deshalb beides: darf ich, und sitzt hier
noch jemand aus dem Team. Dieselbe Ueberlegung wie beim eigenen Namen,
den die Liste auch nicht anbietet. Die Schranke beim Schreiben haengt
nicht daran -- wer es von Hand tippt, ruft eben niemanden.
GEPRUEFT
--------
pruef-erwaehnung: 119 Pruefungen, 0 Fehler (vorher 66).
Neu darin, und die zweite ist die wichtigere:
* der Modi ruft im Treff genau das Team -- die Liste wird aus der
Besetzung ABGELEITET, nicht abgeschrieben
* der Gast im selben Raum ruft NICHTS: kein Eintrag, kein Merkmal,
kein Vorschlag. Ohne diese Pruefung stuende Filipes "nur die
modis, rechte hand, linke hand und dogfather" bloss im Kommentar
* beide Fassungen der Regel (Server und Browser) an 14 zusaetzlichen
Proben nebeneinander, mit beiden Rechten -- samt Gegenprobe, dass
der Vergleich einen Unterschied ueberhaupt sehen kann
* am Bildschirm: der Ruf steht oben in der Liste, sagt daneben, was
er bedeutet, Enter setzt ihn ein, und im Satz ist er an Gewicht
und Rahmen erkennbar -- nicht nur an der Farbe
Beim Bauen gemessen statt vermutet: Ein Scout und ein Modi kommen gar
nicht in denselben Raum (403, Haeusertrennung) -- deshalb prueft der
Verhaltenstest im Treff. Und ein Gast meldet sich nur mit
Altersbestaetigung an (400 ohne).
Die Nachtruhe des Treffs wird in dieser Pruefung abgeschaltet (gleiche
Stunden = keine Nachtruhe). Sonst waere sie zwischen Mitternacht und
sechs rot und danach gruen -- ein Test, der die Wanduhr misst.
pruef-chat, pruef-treffchat (110), pruef-chat-kanaele (81),
pruef-chat-ausbau (64): alle unveraendert gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2a3058e98e |
screen1, nachgefasst: eine zweite Regel lief ebenfalls ins Leere
Beim Nachsehen auf der echten Domain gefunden -- und zwar als Beispiel fuer genau das, was es zu vermeiden gilt: Mein Live-Test suchte im ausgelieferten CSS nach "columns: 2" und fand einen Treffer. Es war mein eigener Kommentar, der die entfernte Regel beschreibt. Textsuche misst kein Verhalten; das tut die Messung in pruef-befinden. Dabei fiel `#fragen > .e-feld:first-child` auf. Seit die Gruppen ihren eigenen Abschnitt haben, ist ein `.e-feld` kein direktes Kind von `#fragen` mehr -- dieselbe Ursache, die den Spaltenumbruch ausgeloest hat, nur an einer zweiten Regel. Nachgesehen: `.e-feld` wird im ganzen Haus an genau einer Stelle gebaut (befinden.js), und immer in eine `.b-gruppe`. Eine Regel, die nichts mehr trifft, faellt nicht auf -- sie hoert einfach auf zu wirken. Deshalb weg statt stehengelassen. Den Abstand macht jetzt `.b-gruppe:first-of-type` zusammen mit `.b-flaeche .e-feld`. pruef-befinden: 121 Pruefungen, 0 Fehler, Lage unveraendert (1 Flaeche, 6 von 6 Koepfen ueber ihren Fragen, 5 von 5 Uebergaengen). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
19d709250d |
screen1: "Wie geht's dir?" ist EINE Flaeche -- und die Spalten waren der Fehler
Filipe, mit dem Bildschirmfoto der Seite: "ich will dass diese seite
viel uebersichtlicher aussieht, es soll eine riesssen kachel sein wo
alles viel besser und geiler aussieht. los"
WAS ANDERS IST
--------------
Vorher lagen Gruppenkoepfe und Fragen flach nebeneinander in derselben
Spalte: jede Frage eine eigene Kachel mit Rand, Schatten und Fase,
dazwischen ab und zu eine Ueberschrift. Zwoelf Kacheln, kein Zusammenhang.
Jetzt: eine Flaeche (`b-flaeche`), darin je Gruppe ein Abschnitt mit
ihrem Kopf und ihren Fragen. Getrennt wird durch eine Linie, nicht durch
eine Luecke. Die Frage ist darin kein eigener Kasten mehr, sondern ein
flaches Feld; beantwortet erkennt man an der linken Kante. Obendrauf ein
Band, das den eigenen Stand zeigt ("2 von 9 Fragen dieser Runde
beantwortet") -- auf einer Seite, die man ausfuellt, ist genau das die
Uebersicht, die gefehlt hat.
DER EIGENTLICHE FUND: DER SPALTENSATZ
-------------------------------------
Nach dem Umbau stand auf dem Bildschirmfoto rechts oben eine Reihe
Antwortknoepfe ohne Ueberschrift darueber, und die Ueberschrift
"Miteinander" links unten neben fremden Fragen. Eine Ueberschrift, die
neben fremdem Inhalt steht, ordnet den falschen zu -- das ist nicht
unschoen, das ist falsch.
Ursache war `columns: 2` auf `#fragen`, dem Behaelter um ALLES. Solange
darin nur flache Fragen lagen, ging es auf. Seit die Fragen in Gruppen
stecken, schneidet der Spaltenumbruch mitten durch eine Gruppe. Das
`break-inside: avoid` daneben konnte nichts halten: Es galt fuer
`#fragen > .e-punkt`, und ein `.e-punkt` ist seit dem Umbau kein direktes
Kind von `#fragen` mehr. Die Regel lief ins Leere.
Zwei Spalten gibt es weiterhin -- aber INNERHALB einer Gruppe, ueber ein
Raster (`.b-gruppe__fragen`). Ein Raster verteilt Kaesten und bricht
keinen Textfluss um; es kann per Bauart nichts zerschneiden. Damit ist
die Ursache weg und nicht der Schaden ueberklebt.
`.b-feld__liste` stand in derselben Regel und kommt in keiner Seite und
keinem Skript mehr vor -- nachgesehen, nicht vermutet. Faellt mit weg.
GEPRUEFT WIRD DIE LAGE DER KAESTEN, NICHT DIE VERSCHACHTELUNG
-------------------------------------------------------------
pruef-befinden bekommt fuenf Messungen dazu. Wichtig dabei, und der
Grund fuer die Form: Eine Pruefung auf "steht der Kopf im richtigen
Abschnitt?" waere die ganze Zeit gruen gewesen. Nachgemessen war sie es
auch (`kopfInGruppe: true`), waehrend das Bild falsch war. Das HTML war
nie das Problem.
Gemessen wird deshalb, WO die Kaesten liegen: jede Frage unterhalb des
Kopfes ihrer Gruppe, keine Gruppe ragt in die naechste. Gegenprobe
gefahren -- mit dem Spaltensatz zurueck faellt das erste auf 5 von 6 und
das zweite auf 3 von 5, bei 1280 px. Die Pruefung kann also auch "nicht
in Ordnung" sagen.
pruef-befinden: 121 Pruefungen, 0 Fehler (vorher 116).
Gemessen bei 1280 und 390 px, keine Browsermeldungen.
Nebenbei: eine deutsche Anfuehrung in einer Pruefmeldung war mit einem
ASCII-Anfuehrungszeichen geschlossen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
51562eb276 |
screen3: Das Verteil-Formular -- Karten statt Zeilen, und alle auf einmal
"diese kachel soll viel geiler sein, also alles was drin ist soll viel
geiler gestaltet sein, viel hochwertiger, viel profissineller, auch
die möglichkeit alle auf einmal auszuwählen und so. mach es hoch krass
profissionel, übersichtlich und richtig krass geil bitte."
VORHER: ein Kaestchen und ein Name je Zeile, untereinander. Bei sieben
Leuten sieben gleiche Zeilen -- man liest alle, um eine zu finden, und
auf dem Handy kostet das sieben Bildschirmzeilen.
JETZT EINE KARTE JE PERSON, im Raster (am Rechner drei Spalten, auf
dem Handy eine). Drei Dinge machen den Unterschied zwischen "Liste"
und "Auswahl":
1. DIE GANZE KARTE IST DAS ZIEL, nicht das Kaestchen darin. Auf
einem Handy ist ein Kaestchen 20 px breit, eine Karte 200. Das
Kaestchen bleibt trotzdem stehen -- es ist das, was ein
Vorleseprogramm ansagt und was die Tastatur bedient.
2. DIE GEWAEHLTE KARTE SIEHT ANDERS AUS: Rahmen und Flaeche in der
Akzentfarbe. Ein Haken allein ist bei sieben Karten zu wenig.
Ueber `:has(input:checked)` und nicht ueber eine Klasse aus dem
Skript -- der Zustand steht schon im Kaestchen, ihn zusaetzlich
als Klasse zu fuehren waeren zwei Wahrheiten.
3. JEDE KARTE NENNT DIE ROLLE. "Diene" und "Funny" sagen nichts;
"Diene, Modi" schon. Der Rollenname kommt fertig vom Server
(`rolle_name`) -- ihn hier aus einem Schluessel zu uebersetzen
hiesse, die Namen der Rollen in eine Datei zu schreiben, die
jeder herunterlaedt.
ALLE AUF EINMAL -- UND DIE GRUPPEN DAZU
Eine Schnellwahl ueber der Liste: Alle · Rechte Hand · Linke Hand ·
Modi · Keine.
DIE GRUPPEN WERDEN GELESEN, NICHT AUFGEZAEHLT. Welche Rollen
vorkommen, sagt die Liste selbst. Eine feste Aufzaehlung hier waere
die, die beim naechsten Rollenzuschnitt eine Gruppe verschweigt -- und
niemand merkte es, weil die Knoepfe ja funktionieren. Genau diese
Sorte Liste hat gestern die linke Hand auf der Team-Lage verschluckt.
Gruppenknoepfe nur, wenn es mehr als eine Rolle gibt: "Modi" neben
"Alle" bei einer Liste aus lauter Modis waeren zwei Knoepfe fuer
dasselbe.
DER ZAEHLER ist der Teil, der Uebersicht macht: "2 von 7 ausgewaehlt".
Bei sieben Kaestchen sieht man nicht mehr, wie viele angehakt sind --
man zaehlt nach.
Gemessen bei 1280 und bei 390 px: 7 Karten, fuenf Schnellknoepfe, kein
waagerechtes Scrollen, keine Browsermeldung.
pruef-bewerbung-aufgaben: 101 Pruefungen, 0 Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
54d069c2b8 |
screen2: Die Aufgaben-Kachel ist Glitzer-Silber
"ich will dass diese kachel einen richtig geilen silber hat als farbe
bitte. mach es richtig geil, ein glitzer silber."
WARUM DUNKLES SILBER UND KEIN HELLES
"Silber" denkt man sich hell. Auf dieser Wand waere es das Ende der
Lesbarkeit: Die Beschriftung jeder Kachel ist HELL (--text), und eine
helle Flaeche darunter laesst davon nichts uebrig. Ein zweiter Satz
Schriftfarben nur fuer diese eine Kachel waere eine Sonderregel, die
beim naechsten Umbau niemand kennt.
Silber ist deshalb als METALL gebaut, nicht als Farbflaeche: Gunmetal,
dunkel und kuehl, mit hellen Kanten und einer Glanzbahn. Das ist, was
gebuerstetes Metall im Halbdunkel macht -- es liest sich sofort als
Silber, ohne zu blenden.
FUENF EBENEN, VON OBEN NACH UNTEN
1. Der Lesesaum liegt ZUERST, also obenauf -- er ist der Grund,
warum die Flaeche funkeln darf, ohne dass die Schrift leidet.
Dieselbe Bauart wie bei der Regenbogen-Kachel.
2. Das Funkeln: sechzehn helle Punkte, jeder mit Hof, unregelmaessig
gesetzt (ein Raster saehe aus wie ein Muster, nicht wie Glitzer).
STATISCH -- blinkende Punkte waeren genau das, was die Hausregel
verbietet.
3. Eine diagonale Glanzbahn.
4. Gebuerstetes Metall: 3-px-Streifen bei 4,5 % Weiss. Man sieht es
nicht als Streifen, man sieht es als Oberflaeche.
5. Der Grundverlauf, oben heller als unten.
ALS EIGENES MERKMAL, NICHT ALS TON. Silber hat eine Buntheit nahe
null; als Ton eingetragen haette pruef-kachelfarben es zu Recht
abgelehnt (Mindestbuntheit 0,12). `ton: 13` bleibt deshalb stehen und
ist der Rueckfall -- genau so macht es die Willkommenskachel mit
`regenbogen`. Zwei Stellen tragen das Merkmal, weil die Kacheln fuer
die Modis aus dem Server kommen und die fuer alle anderen aus
bereiche.js.
NACH DEM ERSTEN BILD NACHGEBESSERT: Kantenlicht, Eckwinkel und
Schiene blieben gruen -- sie ziehen ihre Farbe aus `--ton`. Eine
gruene Linie um eine silberne Flaeche ist keine silberne Kachel.
`--ton` wird jetzt fuer diese eine Kachel ueberschrieben, NUR in der
Anzeige: `data-ton="13"` bleibt am Element, die Farbwerkzeuge rechnen
weiter mit Zahlen.
GEMESSEN am echten Bildschirm (pruef-kachelfarben): 32 Kacheln, kein
Paar sieht gleich aus, und jeder Kacheltext erreicht 4,5:1 --
schlechtester 5,86:1. Die silberne ist nicht darunter.
Mitgelaufen: pruef-kachelraster (15/0), pruef-css-klassen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d26cdc78ff |
Der Loeschknopf war auf dem Handy unsichtbar -- und mein erster Ersatz unlesbar
GEFUNDEN, WEIL ICH MIR DEN CHAT ANGESEHEN HABE
Nach dem Umbau von gestern Abend habe ich den Chat im Browser
aufgemacht statt nur die Pruefungen zu lesen. Im Bild klaffte zwischen
"reagieren" und "anheften" eine Luecke von 87 px, in der nichts stand.
Nachgemessen: Der Loeschknopf ist dort -- sichtbar 0.
URSACHE: `.chat-nachricht__weg-knopf { opacity: 0 }`, sichtbar erst
beim Ueberfahren mit der Maus. Das war vertretbar, solange er nur die
EIGENE Nachricht zuruecknahm: ein seltener, absichtlicher Griff.
Seit gestern traegt derselbe Knopf das Notfall-Loeschen fuer DogFather
und die rechte Hand. Und damit wird es zum Fehler:
* AUF EINEM HANDY GIBT ES KEIN UEBERFAHREN. Der Knopf war dort
dauerhaft unsichtbar -- eine Funktion, die man auf dem Geraet nicht
erreicht, gibt es auf dem Geraet nicht. Filipe besteht bei jedem
Auftrag darauf, dass es auf dem Handy genauso gut sein muss.
* Er belegte trotzdem Platz. Eine Luecke, die nichts erklaert, sieht
nach einem Fehler aus.
Was davor schuetzt, versehentlich zu loeschen, ist nicht die
Unsichtbarkeit, sondern die Rueckfrage -- die steht seit dem 19.09. als
eigener Dialog da. Ein Knopf, den man nicht findet, schuetzt niemanden;
er verhindert nur, dass jemand ihn absichtlich benutzt.
UND MEIN ERSTER ERSATZ WAR MESSBAR FALSCH
Ich gab dem Notfall-Knopf den Warnton, gedaempft gemischt mit der
leisen Schrift. Nachgerechnet, bevor ich ihn ausgeliefert habe:
auf Babyblau 1,91:1 (noetig 4,5)
auf den dunklen Toenen 4,06 bis 4,13
Unlesbar auf der hellen Kachel, zu wenig auf allen anderen. Die leise
Schriftfarbe ist nicht irgendein Grau -- sie ist genau der Wert, der
auf JEDER Kachel 4,5:1 schafft. Wer daran mischt, gibt diese Zusage
auf.
DER PUNKT TRAEGT DIE FARBE, NICHT DIE SCHRIFT. Denselben Weg geht das
Haus schon beim Namen in der Blase, mit derselben Begruendung: Fuer
eine Schriftfarbe laesst sich bei dreizehn waehlbaren Flaechen kein
Kontrast garantieren, fuer einen 6-px-Punkt daneben ist das egal.
Beim Ueberfahren wird die Schrift HELLER statt bunter -- wer den Knopf
anvisiert, soll ihn am besten lesen koennen, nicht am schlechtesten.
EIN DRITTER FEHLER, DEN DIE GEGENPROBE GEFANGEN HAT
Die neue Pruefung (pruef-loeschen, Abschnitt 5b) sollte zweierlei
sichern: kein `opacity: 0`, und die Notfall-Regel setzt keine eigene
Schriftfarbe. Ich schrieb dafuer `/\bcolor:/` -- gedacht als
Wortgrenze. Geschrieben wurde es durch eine Python-Zeichenkette, und
dort ist \b das BACKSPACE-ZEICHEN. In der Datei stand
`/<0x08>color:/`, ein Ausdruck, der nie etwas findet.
Die Zeile "setzt keine eigene Schriftfarbe" war dadurch GRUEN, ohne je
gesucht zu haben. Aufgefallen ist es nur, weil die Gegenprobe daneben
dieselbe Suche benutzt und ROT wurde -- sie sollte ja etwas finden.
Ohne diese Gegenprobe haette ich eine Pruefung ausgeliefert, die genau
den Fehler nicht sieht, fuer den sie gebaut wurde. Jetzt zwei
schlichte Textsuchen ohne regulaeren Ausdruck.
pruef-loeschen: 25 -> 31, 0 Fehler. Mitgelaufen: pruef-chatkachel (33),
pruef-chat-optik.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6be24e204f |
B3: Jede Seite traegt ihre Farbe -- auch ganz oben in der Leiste
"je nachdem auf welcher seite ich bin wechseln gaaanz oben in der
leiste gewissene symbole und sachen mit ... ich will das auf jeder
seite ... nicht mehr wie auf screen3 sondern genau gleich wie da."
DER BEFUND WAR EINE LADEREIHENFOLGE, KEIN FEHLENDES BAUTEIL
kopf.js setzt `data-ton` am <body> -- auf JEDER Seite, seit Langem.
Die Regel, die daraus eine Akzentfarbe macht, stand aber in
bereich.css:
body[data-ton] { --akzent: color-mix(in srgb, var(--ton) 88%, #6f8cab); }
und bereich.css laden genau DREI von fuenfunddreissig Seiten
(bereich.html, bewerben.html, teilen.html). Auf den anderen
zweiunddreissig war die Farbe da und wurde nicht gelesen.
Das erklaert auch, warum ausgerechnet die Highlights-Seite sein
Vorbild war: Highlights IST bereich.html -- eine der drei.
Die Regel steht jetzt in start.css. Die liegt auf allen
fuenfunddreissig.
UND DIE LEISTE SELBST. "gaaanz oben in der leiste" ist woertlich zu
nehmen: Der Akzent wirkte bisher weiter unten (Knopfraender,
Fokusringe, Linien an Karten), die Leiste blieb auf jeder Seite
gleich. Sie bekommt jetzt eine Kante unten in der Farbe der Seite,
nach rechts auslaufend, und die Knoepfe rechts nehmen die Farbe beim
Beruehren auf. Dauerhaft eingefaerbt waeren es sechs bunte Knoepfe in
derselben Farbe -- dann traegt nicht mehr die SEITE die Farbe,
sondern die Leiste.
GEMESSEN, NICHT BEHAUPTET (pruef-kopfleiste-farbe.mjs, NEU, 9/0)
Im echten Browser, mit getComputedStyle -- ob eine CSS-Regel WIRKT,
steht nicht in der Datei:
aufgaben.html Ton 13 --akzent #12b37e (gruen)
chat.html Ton 4 --akzent #c16302 (orange)
kalender.html Ton 8 --akzent #ab68ff (violett)
Welche Seiten gemessen werden, steht NICHT in der Pruefung: Sie liest
die Kacheln der Startseite und nimmt drei mit verschiedenen Toenen.
Eine Liste dort waere die, die beim naechsten Umbau eine Seite nennt,
die es nicht mehr gibt.
Zwei Gegenproben: dass die Farben VERSCHIEDEN sind (vorher war
--akzent auf 32 von 35 Seiten dieselbe -- eine Pruefung ohne diesen
Teil waere auch im alten Zustand gruen gewesen), und dass ohne
`data-ton` wieder die Hausfarbe gilt (#8ec9ff). Eine Regel, die auch
dort zuschlaegt, wuerde eine Farbe erfinden.
EIGENER FEHLER, beim ersten Lauf dieser Pruefung
------------------------------------------------
Der Kachel-Selektor war falsch (`.kachel[href]` statt `li.kachel` mit
dem Verweis darin) -- sie fand null Kacheln. Das haette auffallen
muessen, tat es aber fast nicht: DREI Zeilen waren trotzdem gruen,
weil `every()` auf einem leeren Feld `true` liefert. Genau die Falle,
vor der die Hausregel warnt, und ich bin hineingelaufen. Die Zahl
steht jetzt in jeder dieser Bedingungen.
Mitgelaufen und gruen: pruef-css-klassen (keine Stilvorlage verliert
still eine Regel), pruef-chatkachel (33), pruef-teamlage-karten (22).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
189d0b3363 |
B1: Das Anschlagbrett haelt 24 Stunden -- und sieht aus wie ein Anschlagbrett
"die sachen sollen in der seite vom anschlagbrett immer automatisch
nach 24h von da verschwinden. weil alles hat seine kategorie und was
nicht ist auch nicht um ewig auf der seite zu bleiben fertig."
SEINE BEGRUENDUNG IST DIE REGEL. Ein Anschlagbrett sagt, was GERADE
gilt. Was laenger gilt, hat seinen eigenen Bereich -- Regeln stehen bei
den Regeln, Termine bei "Was ansteht". Eine Ansage vom letzten
Dienstag, die noch haengt, ist keine Ansage mehr, sondern Papier an der
Wand.
DIE DREI ENTSCHEIDUNGEN, DIE ICH TREFFEN MUSSTE -- und woran ich sie
festgemacht habe:
1. AB WANN LAUFEN DIE 24 STUNDEN? Ab `erstellt`, nicht ab `datum`.
`datum` ist ein vom Team gesetztes Feld und kann in der Zukunft
liegen (es traegt die Termine). Eine Ansage, die morgen gilt, soll
morgen verschwinden und nicht uebermorgen.
2. VERSCHWINDET SIE GANZ? Nein. Er sagt "von DA verschwinden" -- von
der Seite. Geloescht wird nichts: Wer eine Ansage geschrieben hat,
soll sie wiederfinden. Sie kommt als `abgehaengt` mit und steht
zugeklappt unter einer leisen Zeile "Abgehaengt (3)". Auf dem Brett
selbst steht sie damit nicht mehr.
3. WER ENTSCHEIDET? Der Server. Die Stunden im Browser nachzurechnen
waere eine zweite Fassung derselben Regel, und eine davon waere
irgendwann aelter. Die Frist geht als Zahl mit der Antwort.
DAS AUSSEHEN ("viel besser gestaltet, übersichtlicher, moderner,
hochwertiger, professioneller"): Was haengt, sieht jetzt aus wie etwas,
das haengt -- kraeftiger Rand links in der Farbe seiner ART (Ansage
babyblau, Neue Regel gold, Hinweis lila, Danke gruen), ein Schein von
links, mehr Luft. Die Art stand bisher nur im Text; jetzt sieht man
sie. Abgehaengtes ist grau statt durchsichtig -- durchsichtig hiesse,
das Buehnenbild scheint durch, also Text auf einem Foto.
pruef-anschlagbrett.mjs (NEU, 12/0) misst beide Seiten der Grenze
(23 h haengt, 25 h nicht), rechnet relativ zur jetzigen Uhrzeit statt
mit einem festen Datum, und hat den Eintrag, an dem sich alles
entscheidet: alt aufgehaengt, Datum von heute. Wer nach `datum`
filtert, laesst ihn haengen. Dazu zwei Gegenproben: auf jedem anderen
Brett gibt es das Merkmal gar nicht, und wo die Grenze WIRKLICH liegt,
wird aus den Eintraegen nachgerechnet statt aus der Zahl im Modul.
NEBENBEFUND, den erst dieser Commit ausgeloest hat
---------------------------------------------------
pruef-bereiche-lesend stuerzte ab: "listen EACCES 127.0.0.1:5040".
Die Portnummern werden aus der Stelle im Alphabet abgeleitet -- heute
sind fuenf neue Pruefdateien dazugekommen, und dadurch ist diese
Pruefung auf die 5040 gerutscht. Die haelt auf diesem Rechner ein
Windows-Dienst (svchost, PID 7136).
`portMussFreiSein` kannte nur ZWEI Antworten: EADDRINUSE oder frei.
EACCES galt als frei -- die Pruefung lief weiter, bis der echte Server
auf demselben Port startete und mit einem unbehandelten Fehler
abstuerzte. Ein Stapelauszug aus node:net, der wie ein Fehler im Code
aussieht.
Jetzt drei Antworten. Und ein belegter Port wird anders behandelt als
ein gesperrter: Belegt geht vorbei (der andere Lauf hoert auf),
gesperrt nie. Abzubrechen hiesse, die Pruefung waere auf diesem Rechner
dauerhaft nicht ausfuehrbar -- die Sorte Warnung, die immer kommt und
deshalb weggeklickt wird. Ausgewichen wird um einen festen Betrag
(+4000), damit die Nummer abgeleitet und eindeutig bleibt.
Mitgelaufen und gruen: pruef-bereiche-lesend, pruef-css-klassen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
7c23913347 |
B2: Die Regeln sind eine Flaeche statt sechs Kacheln
"lass bitte die ganzen regeln viel geiler und spezieller aussehen und nicht sehr viele kacheln sondern eine riesige wo alles schön aussieht und richtig geil, übersichtlich" Vorher sechs Kaesten untereinander: jeder mit Rand, Grund und Abstand, dazwischen jedes Mal ein Schnitt. Beim Lesen faengt man damit sechsmal neu an -- Regeln lesen sich aber als EIN Text, nicht als sechs Merkzettel. JETZT EINE FLAECHE. Die Abschnitte bleiben, ihre Kaesten nicht: innerhalb der Flaeche trennt eine Linie statt einer Luecke. Dazu ein Schein in der Hausfarbe oben links, der nach einem Drittel ausgelaufen ist -- Text auf einem Verlauf liest sich unruhig, und diese Flaeche ist zum Lesen da. UEBERSICHTLICH HEISST: EINE SPRUNGLEISTE. Eine lange Flaeche ohne Wegweiser ist nicht uebersichtlicher als sechs Kaesten, nur laenger. Die Leiste klebt oben, nennt alle Abschnitte und hebt den hervor, in dem man gerade steht (IntersectionObserver -- beim Rollen zu rechnen kostet auf einem Handy spuerbar Strom). SIE WIRD GELESEN, NICHT GEPFLEGT: Die Eintraege kommen aus den Ueberschriften, die ohnehin dastehen, und fehlende ids entstehen dabei. Eine Liste von Hand waere die, die beim siebten Abschnitt fehlt -- und niemand merkte es, weil die Seite ja funktioniert. Die fuenf Regeln tragen ihre Zahl jetzt in einem eigenen Kreis. Die wichtigste Liste der Seite sah aus wie jede andere Aufzaehlung. ZWEI DINGE, DIE ERST DAS BILDSCHIRMFOTO GEZEIGT HAT 1. AUF DEM HANDY BRAUCHTE DIE LEISTE SECHS ZEILEN -- rund ein Drittel des Bildes, und sie klebt oben fest, also dauerhaft. Ein Wegweiser, der mehr Platz braucht als der Weg, ist keiner. Jetzt eine Zeile, die man seitlich schiebt, mit scroll-snap. Am Rechner bleibt der Umbruch: Dort ist Platz, und alles auf einen Blick schlaegt alles hinter einer Schiebebewegung. 2. DANACH WAR SIE GANZ WEG -- hinter der Kopfleiste. Ursache: `--kopf-hoehe` wurde nur in chat.js gemessen. Auf jeder anderen Seite galt der Rueckfallwert 64 px, und auf einem 390-px-Schirm ist die Kopfleiste rund 115 px hoch. Eine Zahl, die eine Seite misst und eine andere raet, ist schlimmer als gar keine: Auf der einen stimmt sie, auf der anderen nicht, und niemand sucht den Fehler bei einer Zahl. Die Messung steht jetzt in kopf.js -- die Datei liegt auf JEDER Seite -- und zaehlt wie vorher Kopfleiste plus Band mit dem fremden Namen, bei jeder Aenderung neu. chat.js ruft sie nur noch auf. Mitgelaufen und gruen: pruef-treff (80/0), pruef-treff-werkzeuge (73/0), pruef-chat-optik, pruef-css-klassen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
60802170a1 |
B4 + B5: Loeschen heisst Loeschen, die Schrift wechselt mit, und Blau wird Babyblau
Die beiden Auftraege gehoeren zusammen, und zwar in dieser Reihenfolge:
Eine babyblaue Kachel ist HELL. Ohne mitwechselnde Schrift waere sie
unlesbar (1,63:1 gemessen). Erst B4 macht B5 moeglich.
B4a -- LOESCHEN HEISST LOESCHEN
"Geloeschte Nachrichten verschwinden vollstaendig - keine Spur, kein
'wurde geloescht'-Hinweis, bei niemandem, auch nicht bei DogFather."
Bis heute blieb die Zeile stehen: Text geleert, weg_am gesetzt, und im
Chat stand "Nachricht zurueckgenommen". Das war ausdruecklich so
begruendet ("ein Loch im Verlauf wirft mehr Fragen auf"). Das Argument
beantwortet aber eine andere Frage: Ein Hinweis "hier stand etwas"
MARKIERT die Stelle. Wer etwas aus Versehen schreibt, will es weg
haben und nicht unterstrichen.
Jetzt ein echtes DELETE. Vier Raender, an denen eine Spur bleiben
koennte, alle gemessen:
1. die Zeile selbst
2. chat_reaktionen (ON DELETE CASCADE - nachgesehen, nicht angenommen)
3. chat_erwaehnungen (ebenso)
4. letzte_am am Raum - wird neu gerechnet, sonst stuende er oben in
der Liste mit einem Zeitpunkt, zu dem es
nichts mehr gibt
Dazu: ein Zitat auf eine geloeschte Nachricht wird weggelassen; in der
Gespraechsliste steht kein Hinweis mehr; der Knopf heisst "loeschen".
Die 5 alten zurueckgenommenen Zeilen (Text bereits leer) raeumt eine
einmalige, wiederholbare Umstellung ab - mit Sicherung davor, und nur
wenn es wirklich etwas zu tun gibt.
B4b -- WER DARF WAS
"jeder nur seine eigenen - ausser DogFather und rechte Hand"
`darfJedeNachrichtLoeschen` = admin oder hand. NICHT fuehrtTeamDogi
(das schloesse die linke Hand ein) und nicht istLeitung (das schloesse
Spicy Media ein, die private Chats nicht einmal sehen darf). Das Recht
kommt vom Server ins Skript, nicht aus einer Rolle im Browser: chat.js
bekommt jeder, der die Seite oeffnet.
B4c -- DIE SCHRIFT WECHSELT MIT
"am besten schwarz auf hellen Kacheln - und weiss, wenn jemand eine
schwarze Kachel waehlt"
`schriftFuer(farbe)` waehlt zwischen zwei Paaren, gerechnet aus der
Leuchtdichte, mit denselben Schwellen wie das Rechenwerkzeug (7:1 fuer
den Text, 4,5:1 fuer die Fusszeile). Keine dritte Spalte in
CHAT_KACHELN, die jemand pflegen muesste. Flaeche und Schrift werden
im Browser in EINEM Griff gesetzt (blaseFaerben) - zwei Stellen waeren
irgendwann eine helle Kachel mit heller Schrift.
B4d -- DIE NAMEN
Der Name ist jetzt ein eigener Streifen mit Kante darunter, .84rem,
und der Rollenpunkt wird ein 3x14-Balken. Vorher stand er als erste
ZEILE in der Blase und las sich wie der Anfang des Satzes.
B5 -- BABYBLAU
"jedes normales blaues herz durch babyblaues herz ersetzen ... jeder
normale blaue farbe, sei es die kachel im chat oder emojis, nur
babyblau bitte."
* Herz: U+1F499 -> U+1FA75. Nicht geglaubt, sondern gemessen: 43,9 px
breit wie die anderen Herzen, ein Ersatzkaestchen waere 20,7. Die
vier vorhandenen blauen Herzen in der Datenbank wandern mit - sonst
waeren es vier Reaktionen, die ERLAUBT nicht mehr kennt: still weg.
* Kachel: neue, HELLE Kachel "Babyblau" mit dem Wert von --akzent.
Gemessen: Text 10,78:1, Fusszeile 4,87:1. Sie steht bewusst nicht in
der Rechnung des Werkzeugs (das rechnet elf Toene auf EINE
Leuchtdichte) - sie hat eine andere Leuchtdichte und dafuer ihre
eigene Schrift. Dasselbe Versprechen, anderer Weg.
PRUEFUNGEN
pruef-loeschen.mjs (NEU, 20/0): alle vier Raender, die vier Faelle
der Rechtegrenze (auch: die linke Hand darf NICHT), das babyblaue
Herz am laufenden Server, und dass der Satz "Nachricht
zurueckgenommen" nur noch in Kommentaren steht - mit Gegenprobe,
dass die Suche diesen Unterschied wirklich macht.
pruef-chatkachel.mjs (33/0): misst jede Kachel mit IHRER Schrift und
fragt dafuer dieselbe Funktion wie der Server. Neu: dass die
Schrift ueberhaupt wechselt. Die Leuchtdichte-Regel gilt jetzt fuer
die gerechneten Toene - das Versprechen dahinter loest die
Kontrastzeile darueber direkt ein.
Vier alte Pruefungen umgedreht, die den alten Zustand festgeschrieben
hatten: pruef-chat, pruef-chat-ausbau, pruef-chat-aufloesen,
pruef-chat-optik. Alle mit scharferer Messung als vorher (Zahl
davor/danach statt "ein Hinweis ist da").
Mitgelaufen und gruen: pruef-alle-sehen-es, pruef-treffchat (110/0).
Gesichert: workspace-vor-loeschumbau-20260922-233313.db
(946 KB, integrity_check ok, 111 Nachrichten, 49 Reaktionen).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
803750edbc |
Aufgaben verteilen: der Knopf ist nie mehr tot, und die Bewerbung steht im Formular
screen1 -- „dogfather, die rechte hand und die linke hand sollen immer
noch aufgaben werden teilen können plus die option dass die modis sich
für aufgaben bewerben können. weil gerade hängt das und weiß nicht
wieso."
WAS WIRKLICH LOS WAR -- gemessen, nicht geraten
Auf entwicklung.html stand oben „Aufgabe verteilen · Wähl LINKS
jemanden aus", und der Knopf war so lange abgeschaltet. Im Browser
nachgemessen (1420 px, als DogFather):
Band oben 284 px, linke Kante 130 px
Personenwahl oben 490 px, linke Kante 130 px
-> UNTER dem Band, 127 px darunter, gleiche linke Kante
Links war nichts. Wer der Anweisung folgte, schaute auf eine leere
Fläche und hatte einen Knopf, der nicht ging. Das Recht selbst war die
ganze Zeit richtig: `darfAufgabenVerteilen` = Leitung oder Hand, also
DogFather, rechte Hand UND linke Hand -- alle drei mit
`darf_verteilen: true` gemessen.
Kurz: Die Regel stimmte, der Weg dorthin nicht.
WAS JETZT ANDERS IST
1. DER KNOPF IST IMMER BENUTZBAR. Er öffnet das Formular, auch ohne
vorherige Auswahl.
2. DIE FRAGE „für wen" STEHT IM FORMULAR, als erste Zeile, mit allen
Personen zur Wahl. Wer unten eine Kachel angeklickt hat, findet sie
angehakt wieder -- beide Wege führen zum selben Ziel.
3. EINE LISTE STATT ZWEIER. „Noch jemanden dazunehmen" ist weg. Es
waren zwei Bedienungen für dieselbe Frage -- und die
Bewerbungs-Option steckte ausgerechnet in der zugeklappten
zweiten: Sie war nur zu finden, wenn man erst aufklappte UND dort
jemanden ankreuzte. Eine Möglichkeit, die man nicht findet, gibt es
nicht.
4. DIE BEWERBUNG STEHT DA, sobald zwei Leute angehakt sind: „Wer
zuerst Zeit hat, übernimmt. Sie bewerben sich, du nimmst an oder
lehnst ab."
ZWEI FEHLER, DIE DABEI AUFFIELEN
* Nach dem Anlegen wurde `fuerPerson` auf null gesetzt und DANACH
`aufgabenZeigen(fuerPerson, …)` aufgerufen -- die Liste, die zeigen
soll, was gerade entstanden ist, blendete sich damit aus. Die Namen
werden jetzt festgehalten, bevor `reset()` sie abräumt.
* Die Bestätigung sagte immer „steht jetzt bei ihm" -- `fuerName` wird
nur beim Klick auf eine Kachel gefüllt. Sie sagt jetzt, was wirklich
passiert ist, und bei einem Pool, dass eine Bewerbung kommt.
* `e-mehr-art` heisst `e-art`: Der Name sagte „gehört zu ‚noch
jemand'", und das gibt es nicht mehr. Dieselbe Sorte Falle wie
`tperson__namen` heute Nachmittag.
DIE PRÜFUNG HATTE MEINEN FEHLER FESTGESCHRIEBEN
`pruef-bewerbung-aufgaben.mjs` enthielt wörtlich:
ok(vorher.aus === true,
"und ist aus, solange niemand gewaehlt ist");
Sie lief, sie war grün, und sie hat den toten Knopf verteidigt. Das
ist die unangenehmste Sorte: nicht übersprungen, nicht kaputt --
sondern eine Bestätigung meines Entwurfs statt der Sache. Jetzt wird
das Gegenteil verlangt.
Dazu zwei neue Abschnitte (84 -> 101 Prüfungen, 0 Fehler):
6b verteilen OHNE vorherige Auswahl, als Pool, samt Nachweis am
Server (verteilart=pool, zwei Leute darin) und der Meldung, die
nicht „bei ihm" sagen darf
6c alle drei Rollen am Bildschirm: DogFather, rechte Hand, linke
Hand -- mit Gegenprobe, dass ein Modi das Band NICHT sieht
EIGENER MESSFEHLER, offen notiert: Mein erster Versuch, die Bewerbung
nachzustellen, meldete „kein Abruf, nichts passiert". Der Knopf öffnet
eine Rückfrage, und die hatte ich nicht beantwortet. Die Bewerbung war
nie kaputt -- meine Messung war es. Erst der zweite Anlauf zeigte den
ganzen Weg: POST /api/aufgaben/1/bewerben -> {"ok":true,"zustand":"beworben"}.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
ba0e326585 |
Team-Lage: fuenf Stufen mit eigener Farbe, Karten neu gebaut, 404 wirft nicht mehr hinaus
B7 -- "wenn ich auf diese sachen drücke werd ich auf die startseite geschickt" und "ich will das es ein zwei kategorien mehr gibt und das soll geiler aussehen und jede seine eigene farbe, stark erkennbar" 1. DER RAUSWURF. Ein Druck auf einen Stufen-Knopf schickte auf die Startseite. Ursache: `hole()` stand ACHTMAL Zeichen fuer Zeichen gleich in acht Dateien, und darin warf JEDER 404 hinaus -- auch der auf eine blosse Handlung. Jetzt eine gemeinsame `assets/js/holen.js` mit der engeren, abgeleiteten Regel: Ein 404 wirft nur, solange die Seite noch gar nichts bekommen hat. 2. ZWEI STUFEN MEHR, und keine davon erfunden: "Fortgeschritten" gibt es im Entwicklungs-Katalog laengst (ENTWICKLUNG_ERWARTUNG), hier fehlte genau diese Mitte; "Vertretung" stand bis heute IN der Beschreibung von Senior. Keine Datenbankaenderung noetig -- die Spalte ist absichtlich ein TEXT ohne CHECK. 3. DIE FARBEN SIND GERECHNET. Nachgemessen lagen "Probe" und "Standard" bei 0,0576 OKLab-Abstand; MINDEST_ABSTAND ist 0,090 -- die beiden waren nebeneinander dieselbe Farbe, und alle drei lagen unter MINDEST_BUNTHEIT. Die neuen fuenf sind ein Faecher aus fuenf Farbwinkeln im Abstand von 72 Grad; der Versatz ist der, bei dem der kleinste Abstand am groessten wird. Ergebnis: 0,1531 untereinander, 0,1108 zur Rollenmarke daneben, Kontrast 7,4 bis 8,6. B8 -- "die sollen viel krasser geiler und übersichtlicher sein ... und die kacheln sollen viel krass geiler und spezieller aussehen auch der hintergrund, veränder das komplett" 4. DIE KARTE IST NEU: Kopfband in der Farbe der Stufe bis an die Kanten, Zeichen von 44 auf 52 px mit Ring, Zahlenband als eigene Flaeche, neuer Hintergrund (Farbschein unter dem Kopfband, feine Schraffur, dunklere Platte). 781 px hoch gemessen, danach 746. 5. DIE ROLLE STEHT JETZT DA -- als Marke auf der Karte und als Ueberschrift ueber jeder Gruppe. Sortiert war schon vorher nach Rolle; man konnte es nur nicht sehen. DREI FEHLER, DIE DABEI AUFFIELEN * `auto-fit` liess die einzelne Karte der rechten Hand ueber die ganze Bildschirmbreite laufen, sobald gruppiert wurde. `auto-fill` haelt die leeren Spalten offen. * Der Name der Person trug `tperson__namen` statt `tperson__name` -- ein Buchstabe, und damit die Klasse fuer graues Kleingedrucktes. Auf einer Seite ueber Personen war der Name kleiner als die Beschriftung darunter. Gefunden hat es die neue Pruefung, die ueberall "?" las. * `stufeSetzen()` suchte das Stufen-Schild mit `[class*="tmerkmal--"]:not(...)` -- einer Aufzaehlung dessen, was es NICHT ist. Sobald die Rollenmarke davorstand, traf die Suche sie: Ein Druck auf "Standard" haette aus "Modi" das Wort "Standard" gemacht. Und die Karte faerbte sich beim Setzen nicht mit um. DREI PRUEFUNGEN, ALLE MIT GEGENPROBE * pruef-holen.mjs (NEU, 14): fuehrt die echte Datei aus und misst fuenf Wege; dieselben fuenf noch einmal an der ALTEN Fassung, die bei genau zwei durchfallen muss. Dazu: laedt jede der acht Seiten holen.js, und zwar VOR ihrem Skript. * pruef-teamlage-karten.mjs (NEU, 22): im Browser. Gruppen, Rollenwort, Stufenknoepfe nur bei Modis, der Druck selbst (kein Sprung, ein Abruf, Schild und Kartenfarbe ziehen mit), Gegenprobe mit dem zweiten Druck, und die neuen Baender auf 390 px. * pruef-team-stufen.mjs (28 -> 47): die abgeschriebene Liste ["probe","standard","senior"] ist raus -- geprueft werden jetzt Eigenschaften und die Farbabstaende, gelesen aus team.css. Gegenprobe ist der Stand von gestern, der durch dieselbe Messung faellt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
3b76a9aab5 |
screen1 + A5 + B6: „wer zuerst Zeit hat" gilt wieder, und Aufgaben entstehen dort, wo die Person steht
DREI SACHEN, EIN ZUSAMMENHANG.
--- screen1 --------------------------------------------------------
Filipe zu meinem eigenen Satz „wer zuerst Zeit hat — genau das geht ja
nicht mehr": „falls das nicht mehr geht mach das es geht wenn es wieder
geht ist alles gut."
Er hat recht, und ich hatte zu schnell aufgegeben. „Wer zuerst Zeit
hat" muss nicht heissen, dass man sich selbst bedient -- es kann
genauso heissen, dass die ERSTE BEWERBUNG zuerst drankommt. Damit gilt
beides: Die Leitung entscheidet (sein Wunsch von vorhin), und wer
schnell ist, hat den Vorteil (sein Wunsch von eben).
Die Bewerbungen werden jetzt nach EINGANG sortiert, nicht nach Namen
-- die Abfrage sortiert sonst alphabetisch, und dann haette nicht der
Schnelle den Vorteil, sondern Frida. Der Erste bekommt die Marke
„zuerst da" (nur bei mehr als einer -- sonst ist es keine Auskunft,
sondern Fuellwerk).
Geprueft mit Absicht gegen das Alphabet: Nele bewirbt sich zuerst und
steht vorn, obwohl Frida im Alphabet vor ihr kaeme.
--- B6: der Knopf auf dem Aufgabenbrett ----------------------------
Filipe: „dieser button kann da jetzt doch endlich verschwinden, auf
dieser seite sollen ja keine aufgaben mehr verteilt werden."
ER HAT DABEI AUF DEN TEAM-DOGI-BILDSCHIRM GESEHEN, und das ist der
Unterschied zwischen „weg damit" und „weg damit, aber gemessen":
Rolle/Haus aufgaben.html entwicklung.html darfAnlegen
manager/agentur ja NEIN ja
creator/agentur ja NEIN ja
scout/agentur ja NEIN ja
spicy/agentur ja NEIN ja
Haette ich den Knopf einfach entfernt, koennten vier Rollen gar keine
Aufgabe mehr anlegen. Der Server nennt deshalb den ORT, und er leitet
ihn aus den KACHELN der Person ab -- nicht aus dem Seitenrecht (dann
haette DogFather auf der Agenturadresse den Knopf verloren, denn
oeffnen darf er die Seite, nur hat er dort keine Kachel dorthin) und
schon gar nicht aus dem Haus.
--- A5: anlegen, wo die Person steht -------------------------------
Filipe: „dieser buttion da soll nicht einen zu der seite aufgaben
fuehren sondern da in dieser seite die aufgaben erstellen und vergeben
koennen. plus man soll die aufgaben hier in dieser seite auch sehen."
Der Knopf war ein Link auf `aufgaben.html?neu=1`. Jetzt oeffnet er ein
Formular an Ort und Stelle. DREI FELDER, NICHT ZWOELF: Wer hier steht,
hat die Person schon gewaehlt; was fehlt, ist was, bis wann und ob
noch jemand mitmacht. Das grosse Formular auf dem Brett bleibt fuer
den Fall, dass man eine Aufgabe fuer irgendwen irgendwo anlegt -- zwei
vollstaendige Masken fuer dieselbe Sache waeren zwei Gelegenheiten,
eine davon zu vergessen.
Dazu die Aufgaben der gewaehlten Person, auf derselben Seite. Sie
kommen beim Auswaehlen und nicht auf Knopfdruck: Wer jemanden
durchgeht, will wissen, was bei ihm liegt.
Ohne Person ist der Knopf AUS statt weg -- sonst springt die Seite beim
Auswaehlen -- und der Satz daneben sagt, was fehlt.
Gemeldet wird, was der Server WIRKLICH gesetzt hat: `zuteilen` kann
eine Person weglassen (gesperrter Zugang). Wer das verschweigt, laesst
jemanden im Glauben, er habe drei Leute eingetragen.
--- EIN FUND AUF DEM EIGENEN BILDSCHIRMFOTO ------------------------
Die Bestaetigung „Clips vom Samstag schneiden steht jetzt bei Rieke."
stand in WARNROT -- `melde` schreibt immer in denselben Absatz, und
der heisst `.fehler`. Nicht schlimm und genau deshalb heimtueckisch:
Wer Bestaetigungen in Rot liest, sucht den Fehler, und wer sich daran
gewoehnt, ueberliest die echte Warnung. `melde` kennt jetzt eine gute
Nachricht; die Vorgabe bleibt „Fehler", damit die neun vorhandenen
Aufrufe nicht stillschweigend umgefaerbt werden.
GEPRUEFT
pruef-bewerbung-aufgaben 84/0 (von 66) -- neu: die Reihenfolge nach
Eingang mit Gegenprobe gegen das Alphabet, und ein Abschnitt, der A5
und B6 am echten Bildschirm durchspielt (Knopf weg auf dem Brett, kein
Link mehr auf der Entwicklungsseite, Formular oeffnet dort, Aufgabe
steht sofort in der Liste darunter UND wirklich in der Liste des
Servers, Bestaetigung als gute Nachricht gekennzeichnet).
Gruen: pruef-entwicklung, pruef-aufgabenbrett, pruef-css-klassen,
pruef-formulare, pruef-struktur.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
43545e4acd |
A4: Bewerben statt selbst nehmen
Filipe, 22.09.2026: „die modis und linke hand sollen da nichts
uebernehmen koennen von aufgaben, ueberhaupt ueberall sollen die keine
aufgaben selber uebernehmen die ihnen nicht zugetragen sind. ich will
dass die sich fuer aufgaben bewerben koennen aber die rechte hand oder
dogfather muessen annehmen oder ablehnen koennen und das mit einem
kommentar als moeglichkeit sogar noch zum hinzufuegen."
ZWEI FRAGEN, DIE MAN AUSEINANDERHALTEN MUSS -- und das war der Schluessel:
verteilen eine Aufgabe an ANDERE geben
entscheiden bestimmen, wer sie am Ende macht
Sein Satz vom selben Tag („rechte hand linke hand und dogfather ...
koennen alle verteilen") widerspricht dem nicht, er beantwortet die
erste Frage. Die linke Hand verteilt, entscheidet aber nicht -- sie
bewirbt sich wie ein Modi. `entscheidetUeberAufgaben` steht neben
`darfAufgabenVerteilen`, und drei Stellen fragen ab jetzt dieselbe
Funktion.
DAS VERBOT HATTE DREI TUEREN, und die zweite und dritte waren beim
Planen nicht zu sehen:
1. aus dem Pool „uebernehmen" -- die offensichtliche
2. beim Pool „annehmen" -- dasselbe unter anderem Namen: Wer
zusagt, nimmt sie den anderen weg.
Bei „einzeln"/„mehrere" bleibt es
erlaubt -- dort wurde sie ihm
ZUGETRAGEN, und genau das Wort
steht in seinem Satz.
3. beim Verteilen sich selbst eintragen -- die linke Hand darf
verteilen, haette sich also selbst
nehmen koennen. Abgelehnt statt
still gefiltert: Wer sich eintraegt
und sich danach nicht findet, sucht
den Fehler bei sich.
EIN FUND, OHNE DEN A4 GAR NICHT FUNKTIONIERT HAETTE
Die rechte Hand soll entscheiden -- und sah die Aufgabe nicht, um die
es ging. Gemessen an einer Pool-Aufgabe, die DogFather fuer zwei Modis
angelegt hat:
DogFather sieht sie 1 Bewerbung
Modi sieht sie 1 Bewerbung
rechte Hand SIEHT SIE NICHT (Liste leer)
Ihre Sichtregel sammelte Menschen mit einer TEAM_DOGI_ROLLE und fragte,
ob einer als Creator, Verantwortlicher oder Ersteller eingetragen ist.
Bei einer Pool-Aufgabe bleibt `verantwortlich_id` leer (das ist ihr
Sinn), und der Ersteller war DogFather -- der in dieser Liste nicht
steht. Alle drei Bedingungen liefen ins Leere.
Auf der Adresse von Team Dogi sehen die Haende jetzt alles. Das ist
zugleich sein Satz „sehen alle aufgaben". Die Haustrennung bleibt:
`sichtbar()` haengt fuer crew weiterhin `AND ohneAgentur(...)` davor.
WIE DIE BEWERBUNG GEBAUT IST
Kein zweiter Tisch, sondern ein weiterer Zustand derselben Zeile
(`beworben`). Die Frage „wie steht diese Aufgabe bei DIESEM Menschen"
wird dort schon beantwortet; eine zweite Tabelle haette zwei Wahrheiten
ueber dieselbe Beziehung.
Die Worte der Person (`grund`) und der Kommentar der Leitung
(`entscheid_text`) stehen in ZWEI Feldern. In dasselbe waere bequemer
und wuerde die Frage mit der Antwort ueberschreiben -- danach wuesste
niemand mehr, worum jemand gebeten hat. Dasselbe gilt, wenn eine
Bewerbung wegfaellt, weil jemand anders die Aufgabe bekommt: Der
Hinweis kommt in das Feld der Leitung, ihre Worte bleiben stehen.
Der Kommentar ist FREIWILLIG. Die Begruendung beim Ablehnen einer
zugeteilten Aufgabe bleibt Pflicht -- dort sagt jemand ab, der gefragt
wurde. Hier bittet jemand; ein „bitte" braucht keine Begruendung.
Filipes Wort ist „als moeglichkeit".
Die CHECK-Regel wurde ueber `checkListeErweitern` erweitert -- den Weg,
der seit dem 09.09. an einer Stelle steht, mit Sicherung vorher,
Spaltenliste aus PRAGMA und Indizes, die mitgehen.
UND EIN SATZ, DER NICHT MEHR STIMMTE
„Frei fuer 3 Leute — wer zuerst Zeit hat" war die Beschreibung des
Pools, solange sich jeder selbst bedienen durfte. Er sagt jetzt jedem,
was FUER IHN gilt.
GEPRUEFT
Neu: server/pruef-bewerbung-aufgaben.mjs, 66/0 -- die Regel selbst,
alle drei Tueren, der erlaubte Weg, die zwei Felder, das Zurueckziehen,
und ein Abschnitt am echten Bildschirm (ein Modi sieht „Ich bewerbe
mich" statt „Ich uebernehme das"; die rechte Hand sieht die Bewerbung
mit Annehmen und Ablehnen; die Bewerberin sieht KEINEN Block zum
Entscheiden -- sonst waere das Verbot einen Knopf weiter offen).
pruef-zuteilung auf die neue Regel umgestellt (sie hielt „Bea
uebernimmt sie" fest und wurde zu Recht rot) -- misst jetzt denselben
Effekt ueber den neuen Weg. Dazu gruen: pruef-aufgabenbrett,
pruef-meldungen, pruef-sicht, pruef-css-klassen.
ALTLAST, nicht von hier: pruef-rollen meldet einen Fehler an der
Kachel „Zu Team Dogi" (absolute Adresse). Mit `git stash` nachgemessen
-- vorher und nachher identisch.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
b79b75ab70 |
A3: Calls & Protokolle gibt es jetzt auch bei Team Dogi
Filipe, 22.09.2026: „ich will diese kachel vom workspace auch im team
dogi seite. ich will dass jeder immer nur seine eigenen sachen von
seinem kalender sieht mehr nicht. perfektioniere das bitte. jeder der
einen kalender hat soll auch sowas haben danke."
GEMESSEN, BEVOR GEBAUT WURDE:
Rolle Kacheln Kalender Calls
admin 31 ja NEIN
hand 31 ja NEIN
linke 30 ja NEIN
modi 26 ja NEIN
gast 12 nein nein
Die Community hat keinen Kalender. Sein Satz „jeder der einen kalender
hat" beschreibt die Lage also genau -- „alle bekommen es" waere falsch
gewesen.
ES IST EINE REGEL, KEINE VIERFACHE EINTRAGUNG. Hinter jeden Kalender
einer Liste kommt eine Calls-Kachel, in derselben Gruppe. Vier Stellen
von Hand zu pflegen waere die Stelle, an der es beim naechsten neuen
Rollenzuschnitt auseinanderlaeuft. Erkannt wird der Kalender am ZIEL,
nicht am Namen -- Namen sind im Haus schon gewandert, Ziele nicht.
„JEDER SIEHT NUR SEINE EIGENEN" GAB ES SCHON, seit dem 07.09.
(`termineSichtbar`). Es wird jetzt aber nicht mehr GELESEN, sondern am
laufenden Server ausprobiert: Zwei Leute legen je einen Call an und
sehen den des anderen nicht -- auch DogFather nicht. Wer als
Teilnehmer eingetragen ist, sieht ihn schon; das ist die Gegenprobe,
ohne die „niemand sieht etwas" auch bei einer kaputten Liste gruen
waere.
DER TON WAR EINE RECHNUNG UEBER DREI ANLAEUFE
1. Ton 15, derselbe wie im anderen Haus. Als Zahl frei, auf dem
BILDSCHIRM nicht: 0,0139 zu „Was ansteht", unter der Grenze 0,02.
2. Ton 16, ausgerechnet als der entfernteste brauchbare. Die Pruefung
kennt aber zwei Regeln mehr, die ich nicht beruecksichtigt hatte:
Rohabstand >= 0,090 (er lag bei 0,0854) und Buntheit >= 0,12 (er
lag bei 0,116). Und Ton 16 gehoert im anderen Haus zu
„Start-Check" -- ihn umzufaerben haette dort eine Kachel
veraendert, nach der niemand gefragt hat.
3. Unter allen elf freien Toenen erfuellte KEINER alle drei Regeln.
Eine 32. Kachel braucht einen 32. Ton. Also einen neuen gerechnet,
additiv, ohne einen vorhandenen anzufassen:
Ton 43 #027afb Abstand 0,0925 Buntheit 0,212 Kontrast 4,63:1
Es bleibt ein Blau -- die Kachel ist damit als dieselbe
wiedererkennbar wie im anderen Haus.
EIN WIDERSPRUCH IM HAUS, DABEI GEFUNDEN
`tools/kachel-farbe-einzeln.mjs` suchte die Buntheit von 0,30 bis
herunter auf 0,04, `pruef-kachelfarben` verlangt mindestens 0,12. Das
Werkzeug lieferte fuer Ton 43 zuerst ein blasses #bcdbff (Buntheit
0,060) mit dem besten Abstand weit und breit -- und die Pruefung lehnte
es ab. Beide hatten recht; zwei Zahlen fuer dieselbe Regel in zwei
Dateien, die nichts voneinander wissen. Ein Werkzeug, dessen
Vorschlaege die Pruefung danach verwirft, ist schlimmer als keines --
man haelt das Ergebnis fuer fertig.
Die Schwellen stehen jetzt in tools/kachelton-regeln.mjs, und beide
Seiten lesen sie von dort.
NEU: server/pruef-calls-rudel.mjs, 32/0. Sie prueft die REGEL (Calls
genau dann, wenn Kalender -- und direkt dahinter, in derselben
Gruppe), dass Kachel und Zutrittsrecht zusammenpassen, und am
laufenden Server, dass jeder nur seine eigenen sieht.
pruef-kachelfarben 22/0, pruef-start-ansicht, pruef-willkommen,
pruef-struktur, pruef-treff, pruef-modi-checkliste gruen.
ZWEI ALTLASTEN DABEI GEFUNDEN, nicht von dieser Aenderung und noch
nicht behoben (beide vorher schon rot, nachgemessen mit `git stash`):
pruef-kachelraster 3 Fehler (erwartet acht Community-Kacheln,
es sind zehn)
pruef-jeder-hat-eine-seite 1 Fehler („fehlt: linke" -- die Rolle kam
dazu, die Pruefung nicht mit)
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
7ccf904c3c |
Das Aufgaben-Formular: was aufklappt, bekommt jetzt auch Platz
Filipe, 22.09.2026, zum Bildschirmfoto: „wie scheisse sieht das aus,
verbesser das bitte." Zu sehen: „Anlegen" und „Abbrechen" lagen mitten
in der Personenliste.
GEMESSEN statt geraten, bei 1280 px mit aufgeklappter Liste:
Zelle Zeilen Hoehe Inhalt
feld-verant 24px 44px 68 107
feld-mehrere 43px 44px 87 261 <-- 174 zu viel
Jede Zelle des Formularrasters bekommt zwei Zeilen: Beschriftung oben,
Eingabe unten mit festen 44 px. Das ist richtig und der Grund, warum
alle Eingaben auf einer Linie sitzen (17.09.).
`feld-mehrere` ist aber keine Beschriftung mit Eingabe, sondern ein
Knopf mit einer Liste, die aufklappt. Ihr zweites Kind landet in der
44-Pixel-Zeile und laeuft heraus, sobald jemand sie oeffnet. Was
herauslaeuft, belegt keinen Platz -- also legt es sich ueber das
Naechste, und das Naechste sind die Knoepfe.
DIE MESSUNG HAT MICH VOR DEM NAHELIEGENDEN FEHLER BEWAHRT.
Erster Gedanke: „Zellen ohne eigene Eingabe brauchen die zwei Zeilen
nicht" -- `:has(> input, > select, > textarea)`. Die Messung sagt etwas
anderes: Von sieben Zellen haben SECHS ihre Eingabe nicht als direktes
Kind, weil der Auswahl-Baustein sie in ein <div> wickelt. Die Regel
haette fast das ganze Formular getroffen und genau die Ausrichtung
zerstoert, die sie schuetzen soll.
`aria-expanded` ist gemessen das einzige Merkmal, das nur bei dieser
Zelle steht -- und es ist das inhaltlich richtige: Es sagt „dieser
Bereich kann groesser werden". Etwas, das groesser werden kann, darf
keine feste Hoehe haben.
UND DIE PRUEFUNG, DIE ES HAETTE FINDEN MUESSEN
pruef-formulare war gruen -- sie klappt das Feld nie auf. Ein Zustand,
der nie hergestellt wird, kann nicht gemessen werden.
Neuer Abschnitt: Jedes Element mit `aria-expanded` im Formular wird
geoeffnet, danach darf keine Rasterzelle mehr Inhalt haben, als sie
hoch ist. Nicht diese eine Stelle, sondern die Eigenschaft -- damit
faellt auch die naechste auf, die es noch gar nicht gibt.
ZWEI ANLAEUFE DABEI WAREN FALSCH, und der zweite war der gefaehrliche:
1. `scrollHeight` der Zelle meldete elf Zellen als kaputt, die alle
in Ordnung sind: Der Hinweis unter einem Feld haengt seit dem
17.09. absichtlich absolut darunter. Eine Warnung, die bei
richtigem Verhalten anschlaegt, wird abgeschaltet.
2. Nur die direkten Kinder im Fluss -- das war gruen, AUCH MIT DEM
ECHTEN FEHLER. Nachgemessen mit zurueckgenommener Behebung:
immer noch gruen. Das Raster staucht das Kind auf die feste
Zeilenhoehe, das Kind bleibt also brav in der Zelle; was
herauslaeuft, ist der Inhalt darin.
Jetzt misst sie in die Tiefe (ohne Teilbaeume unter absolut gesetzten
Elementen und ohne eigene Rollbereiche) und ist beidseitig belegt:
mit Behebung -> gruen
ohne Behebung -> FEHL „feld-mehrere: Inhalt reicht bis 169 px,
Zelle ist 87 px hoch"
Dazu eine Gegenprobe, die eine Zelle kuenstlich einklemmt.
Ueberlappungen im Formular: von 12 auf 4 -- und die vier sind Absicht
(der echte <select> liegt unsichtbar ueber seinem Knopf).
pruef-formulare, pruef-aufgabenbrett, pruef-css-klassen gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
beb6bc2d62 |
Die Willkommens-Kachel: bunte Punkte statt Balken
Filipe, 22.09.2026: „Ja ist cool mit den ganzen farben, aber ich finde
das passt nicht so gut zum eigentlichen Stil. Würde glaube ich schöner
wirken, wenn die Farben als bunte Punkte auf der gesamten Kachel wären,
vielleicht auch eng an eng und größere und kleinere Punkte, damit es vom
Stil her die Punkte der anderen Kacheln aufgreift, aber trotzdem extrem
heraussticht. Das mit den Farben ist mega. Aber irgendwie passen die
balken/streifen nicht."
ER HAT DEN STIL DES HAUSES GENAUER GELESEN ALS ICH. Jede Kachel der
Startseite ist ein Sternenfeld -- nahe Sterne mit Hof, mittlere Sterne,
ferner Staub, dazu ein schraeger Schleier. Steht so in start.css unter
"NAHE STERNE", seit dem 17.09. Die Streifen waren die einzige Flaeche
weit und breit mit harten Kanten: richtig in der Farbe, falsch in der
Form.
Jetzt 93 Punkte in drei Groessen, jede Groesse einmal alle 31 benutzten
Kacheltoene. Dieselbe Bauart wie ueberall, nur bunt statt weiss -- die
Kachel greift den Stil auf und ist trotzdem die einzige, deren Sterne
Farbe haben.
ABGELEITET, NICHT EINGETRAGEN: Punktzahl, Rasterweite und Reihenfolge
folgen aus der Anzahl der Farben. Der Sprung durch die Farbliste wird
so gewaehlt, dass er teilerfremd zur Laenge ist -- sonst laegen
Nachbarpunkte auf benachbarten Farbwinkeln und es entstuenden Flecken
aus fast gleichen Toenen. Eine feste Zahl wie 7 versagt still, sobald
die Anzahl ein Vielfaches davon ist. Die drei Rasterweiten (197/131/83)
haben bewusst keinen gemeinsamen Teiler; sonst faellt das Feld
regelmaessig aufeinander und man sieht ein Muster.
Der Zufall der Streuung ist ein fester: `Math.random` haette bei jedem
Lauf einen anderen Block ergeben, und jeder Vergleich "hat sich etwas
geaendert?" waere wertlos.
VIER ANLAEUFE FUER DEN LESBAREN TEXT, drei davon falsch:
1. Der Lesesaum der Streifenfassung blieb stehen. Gemessen: 8,27:1 bei
einer Grenze von 4,5. Das war kein Saum, das war ein Deckel -- er
verschluckte die untere Haelfte der Kachel, und genau dort sollten
Punkte sein ("auf der gesamten kachel"). Zurueckgenommen.
2. Danach sass auf dem Handybild ein heller Punkt mitten unter dem Wort
"gibt". Die Messung sagte weiter 8,2:1 und hatte recht: Sie mittelt
ueber die Textflaeche. Ein Punkt hinter einem duennen Buchstaben
verschwindet in diesem Mittel -- im Auge nicht.
3. Also ein dunkler Teich im Kachelhintergrund, 400 px breit. Auf dem
grossen Bildschirm sass er richtig; die Kachel auf dem Handy ist
aber selbst nur 366 px breit, und er hat fast alle Farben
geschluckt. Eine Pixelzahl, die auf einem Geraet passt, ist auf dem
naechsten falsch.
4. Richtig: der dunkle Grund haengt am TEXT, nicht an der Kachel. Dann
ist er immer genau so breit wie das, was er lesbar machen soll --
auf jedem Geraet, ohne eine einzige Schwelle. Und der Verlauf darin
laeuft vor allen vier Kanten aus, sonst sieht man das Rechteck und
es steht eine Karte in der Karte.
Nebenbei die alte Falle wieder getreten und behoben: Ein Backtick in
einem Kommentar, der INNERHALB einer Vorlagenzeichenkette steht,
beendet sie. Steht seit heute als Hinweis daneben.
Gemessen: Willkommen 8,36:1 (Grenze 4,5), schlechteste Kachel im Haus
unveraendert "Aufgaben" mit 4,80:1. pruef-kachelfarben 22/0,
pruef-willkommen, pruef-buehne (Kontrast an echten Bildpunkten, alle
Seiten) -- alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
25de892fdb |
screen5: Aus dem Treff wird das Rudel, aus der Zentrale die IrrenAnstalt
Filipe, 22.09.2026: "ersetze die zentrale durch, Die IrrenAnstalt.
genau so geschrieben bitte. und alles was treff heißt oder wo treff
steht soll durch Rudel ersetzt werden bitte."
Die Schreibweise "IrrenAnstalt" mit grossem A in der Mitte ist so
gewollt. Das steht als Hinweis daneben, damit sie beim naechsten Mal
niemand "korrigiert".
WAS UMBENANNT WURDE: alles, was jemand LIEST -- Kachelnamen,
Ueberschriften, Markenzeilen, Saetze, Meldungen, Aufgabenvorlagen.
116 Zeilen in 42 Dateien.
WAS BLEIBT: Adressen (treff-regeln.html), Bezeichner (TREFF_ROLLEN),
Datenbankwerte (bereich = 'treff'), Abfrageteile (b=treff). Eine
Adresse umzubenennen bricht jedes Lesezeichen, und ein Datenbankwert
umzuschreiben waere eine Umstellung ohne Gegenwert. Dieselbe
Entscheidung wie heute frueh bei Dogi-Media, wo material.html auch
material.html geblieben ist.
DREI GRAMMATIKFEHLER IM EIGENEN ENTWURF, alle vor dem Ausliefern
gefunden -- ein blindes Ersetzen reicht hier nicht:
1. "der Treff" ist maennlich, "das Rudel" saechlich. Ohne Tabelle
waere ueberall "Der Rudel" gestanden. (Und "Treffer" waere zu
"Rudeler" geworden, "Treffen" zu "Rudelen" -- deshalb greift die
Regel nur bei Wortgrenze und nie vor einem Kleinbuchstaben.)
2. BINDESTRICH-ZUSAMMENSETZUNGEN. In "der Treff-Chat" gehoert der
Artikel zu "Chat", nicht zu "Treff". Der erste Durchlauf machte
daraus "das Rudel-Chat", "das Rudel-Kacheln" und "ein Rudel-Raum".
Jetzt greift die Artikelregel nur, wenn das Wort allein steht.
3. GESCHUETZTE LEERZEICHEN. In den Markenzeilen steht
`Der Treff`, damit die zwei Woerter nicht umbrechen. Das
Muster hat daran vorbeigegriffen: "Der Rudel", auf fuenf
Seiten. Jetzt wird das Trennzeichen mitgefasst und unveraendert
wieder eingesetzt.
Gefunden wurden alle drei, weil jede einzelne der 116 Zeilen vor dem
Schreiben als ALT/NEU ausgegeben und gelesen wurde -- und danach
gezielt nach falschen Artikeln gesucht ("den Rudel", "der Rudel",
"einen Rudel"). Uebrig blieben sechs Treffer, und die sind alle
richtig: "einen Rudel-Raum", "der Rudel-Chat", "den Rudel-Regeln" --
Zusammensetzungen, bei denen der Artikel zum letzten Wort gehoert.
UND ZWEI PRUEFUNGEN, die die Umbenennung nicht mitbekommen haetten:
`/Treff/.test(...)` und `/Treff/i.test(...)`. Ein regulaerer Ausdruck
ist keine Zeichenkette -- sie haetten ab sofort nach einem Wort
gesucht, das die Seite nicht mehr sagt, und waeren still rot geworden,
ohne dass etwas kaputt ist.
Geprueft, alle gruen: pruef-treff, pruef-treffchat,
pruef-deutsche-texte, pruef-uebernahme, pruef-crew-adresse,
pruef-willkommen, pruef-wege-nach-draussen, pruef-vorlagen,
pruef-start-ansicht, pruef-struktur.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
091c5f9cd9 |
screen6: Bei DogFather steht jetzt eine Krone
Filipe, 22.09.2026: "bei dogi soll kein husky sein sondern eine krone. die auch extrem auffaellt damit man den unterschied extrem erkennt." WARUM ER RECHT HAT: Drei der fuenf Kacheln auf der Anmeldewand trugen denselben Husky -- DogFather, rechte Hand, linke Hand. Drei gleiche Zeichen untereinander sind kein Zeichen mehr, sondern Tapete; man liest dann nur noch die Namen, und dafuer braucht es kein Bild. WARUM GOLD: Die anderen vier Zeichen liegen alle im Blaubereich (Husky silbern, Pfote blau, Community blaugrau). Eine Krone im selben Farbkreis waere eine andere Form, aber kein anderer Eindruck. Gold ist der einzige Hauston, der hier noch nicht vergeben ist -- und der, den eine Krone ohnehin hat. Es sind vorhandene Hausfarben und kein Leuchten: Der Unterschied kommt aus Form und Farbkreis, nicht aus Helligkeit. Die Wand bleibt augenschonend. WAS SIE NICHT HEISST: Der Untertitel bleibt "Ueberblick & Entscheidungen" -- eine AUFGABE, kein Rang. Die vier anderen Rollen behalten ihre Zeichen unveraendert, an den Texten aendert sich nichts. Das Zeichen sagt "das ist die Rolle, die du suchst", nicht "der steht ueber den anderen". EIN FUND BEIM BAUEN: `.rolle__zeichen` faerbt jedes Rollenzeichen mit dem Ton der Rolle ein -- gedacht fuer gezeichnete Striche. Der Husky (ein Foto) und die Pfote (eigene Verlaeufe) merken davon nichts, weil eine Flaeche ohne `stroke` die Regel stillschweigend ignoriert. Die Krone haette sie sichtbar abbekommen: ein blauer Rand um eine goldene Krone. Ausdruecklich abbestellt. DIE PRUEFUNG HIELT DIE ALTE VORGABE FEST und wurde zu Recht rot: Sie verlangte seit dem 10.09., dass die rechte Hand DASSELBE Zeichen traegt wie DogFather. Beide Fassungen geben eine Anweisung von Filipe wieder; dazwischen ist die linke Hand dazugekommen. Statt die Paarliste umzuschreiben -- die beim naechsten Umbau wieder danebenlaege -- prueft sie jetzt die Eigenschaft, um die es geht: Jede Kachel traegt ein Zeichen, DogFathers kommt genau einmal vor, es ist auf der Seite auch definiert (ein `use` auf eine vertippte Kennung zeichnet lautlos nichts), und die zwei Haende lesen sich weiter als Paar. Mit Gegenprobe. pruef-crew-adresse 153/0 (von 148), pruef-css-klassen grün. Co-Authored-By: Claude Opus 5 <[email protected]> |