628b99943ee9413811ad193a7ae9992f4d69a29e
1147
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
14d6f5000c |
Der Titel heisst wieder "Zentrale" -- und gehoert jetzt der Adresse
Filipe: "anstatt irrenanstalt soll da auch Zentrale stehen bitte. auch
getrennt von der team dogi seite da steht was anderes und soll auch so
bleiben."
NACHGEMESSEN, BEVOR ETWAS GEAENDERT WURDE -- und es stand NICHT etwas
anderes. `crewWeiche` biegt fuer das Teamhaus sechs Dinge um (Manifest,
App-Symbole, Zugangswand, Buehnen, Marke, Haus-CSS); `start.html` ist
nicht dabei, und kein Skript hat `#ztitel` je angefasst. Auf BEIDEN
Adressen stand seit dem 22.09.2026 derselbe fest eingebaute Titel.
Verschieden war nur die Zierzeile darueber -- "Spicy Media" gegen
"Team Dogi" --, und die hat vermutlich den Eindruck gemacht.
WAS JETZT GILT
* In start.html steht "Zentrale". Das ist die Vorgabe und gilt fuer
das Agenturhaus.
* Das Wort des Teamhauses kommt vom Server (`titelFuer`, direkt neben
`markeFuer`, nach demselben Muster). Dort bleibt damit woertlich
stehen, was vorher dastand -- ab dem 24.09. wird jeder Umbau je
Haus getrennt gefuehrt, und dies ist der des Agenturhauses. Ob
Filipe dort etwas anderes will, entscheidet er; geraten wird es
nicht.
NACH DER ADRESSE UND NICHT NACH DER ROLLE, anders als bei der Marke:
Ein Titel sagt, WO man ist, eine Marke sagt, zu WEM man gehoert. Auch
der Sicht-Umschalter aendert ihn nicht -- wer eine fremde Sicht oeffnet,
wechselt die Zahlen, nicht das Haus.
UND ER STEHT NICHT MEHR IN EINER DATEI, DIE JEDER HERUNTERLAEDT.
Derselbe Grund wie bei MODI_MARKE zwei Zeilen darueber: Was nur das
Teamhaus angeht, gehoert nicht in start.html, die jeder Creator beim
Oeffnen bekommt. Die Schreibweise mit grossem A in der Mitte ist
weiterhin so gewollt und steht jetzt in workspace.js.
GEMESSEN
* pruef-haus-trennung 97 -> 100 Pruefungen, 0 Fehler. Die drei neuen
verlangen den UNTERSCHIED, nicht den Wortlaut: auf crew. ein
eigener Titel vom Server, auf workspace. keiner (dort gilt die
Seite), und die Zierzeilen sind ebenfalls verschieden. Ein
Vergleich mit "Zentrale" waere beim naechsten Umbenennen rot, ohne
dass etwas kaputt ist -- diese Sorte Fehlalarm hatte ich heute
schon einmal.
* pruef-start-ansicht 157, pruef-deutsche-texte 12 -- unveraendert.
* Angesehen bei 1280 px und 390 px: "◆ SPICY MEDIA ◆" darueber,
"Zentrale" darunter.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e1ee778c04 |
Vier Stufen im Agenturhaus -- und die Modi-Liste verschwindet von dort
Filipe, mit dem Bildschirmfoto der LIVE-Punkte: "diese aufgaben auf
screen. alle auf dieser app getrennt von denen auf der team dogi
website bitte, sehr wichtig. die sollen die manager und scouts bewerten
können mit passt passt nicht verbesserung möglich und was weiß ich. und
die creator sollen sehen was bei ihnen passt oder nicht mit der notiz
vom manager oder scout. spicy und dogfather sollen auch bewerten können
wie vorher. ... und wie gesagt von der team dogi seite da ist ein
anderes system auf diesen aufgaben."
WAS AUF DEM BILDSCHIRMFOTO STAND, WAR NICHT SEINE SEITE
Unter "Vor der Sendung" stand die Liste eines MODIS -- erkennbar am
Satz darueber ("Was du vor und beim Start gesehen hast") und an den
Punkten ("Die Ankuendigung kam rechtzeitig"). Am echten Bestand
nachgemessen: Die Auswahl "Person" fuellte sich aus allen Creatorn PLUS
allen Modis, sortiert nach Namen. Der erste Name im Haus ist "Diene",
eine Modi -- und ohne ausdrueckliche Wahl nimmt die Seite den ersten.
DogFather bekam auf der Agenturadresse also zuverlaessig das Teamhaus
zu sehen, und druecken konnte er dort nichts, weil ein Modi-Bericht nur
dem Modi selbst gehoert.
DIE GRENZE, AN DREI STELLEN STATT AN EINER
* Die Auswahl geht durch EIN Sieb (hat diese Person ueberhaupt eine
Liste, und steht sie in diesem Haus?) statt durch drei einzeln
gepflegte Bedingungen.
* Die Grenze haelt auch gegen eine von Hand eingetragene Nummer --
eine ausgeduennte Auswahlliste ist Kosmetik, solange ?creator_id=
durchgeht.
* Die gueltigen Punkt-Schluessel lagen fuer beide Haeuser in EINER
Menge. Ein Scout konnte damit bei einem Creator den Stand eines
Modi-Punktes setzen: angenommen, gespeichert, nie zu sehen.
* Dazu: `darfCreator` sagt fuer DogFather bei JEDER Nummer ja -- er
konnte einen Stand an einer Managerin oder an sich selbst setzen.
Drei Lagen wie bei den Aufgaben: crew / agentur / keine Adresse. Der
dritte Ausgang ist kein Schlupfloch, sondern die Bedingung dafuer, dass
die Pruefungen ueberhaupt noch etwas messen koennen.
ZWEI SKALEN, WEIL ES ZWEI VERSCHIEDENE DINGE SIND
Agentur (Betreuung urteilt, Creator liest): Passt / Verbesserung
moeglich / Passt nicht / Trifft nicht zu. Team (Modi berichtet,
DogFather behandelt im Eingang): Passt so / Verbessern, unveraendert --
eine Stufe "Passt nicht" haette dort keinen Empfaenger.
"Trifft nicht zu" ist kein Beiwerk: Ohne sie steht ein Punkt, der bei
diesem Creator gar nicht vorkommt, fuer immer auf "offen" und die
Bilanz zaehlt ihn als unerledigt mit.
Die Worte, die Toene und die Frage im Nachfragefenster kommen vom
Server. Der Browser baut Knoepfe, Marken und Kacheln daraus und kennt
keine Stufe beim Namen -- sonst muesste er ausserdem wissen, WANN
welche gilt, und das waere ein Rollenvergleich in einer Datei, die
jeder herunterladen kann.
DIE NOTIZ TRAEGT JETZT AUCH DIE ROLLE
"mit der notiz vom manager oder scout" -- bis hierher stand am Satz nur
ein Vorname. Wer die Namen im ersten Monat nicht kennt, weiss nicht,
wer da urteilt. Jetzt: "Patrick, Scout · 24.09., 23:43".
DIE UMSTELLUNG DER DATENBANK KOMMT NICHT VON MIR
Eine CHECK-Regel laesst sich in SQLite nicht aendern; die Tabelle muss
neu gebaut werden. Ich hatte den Griff hier zuerst ein zweites Mal
geschrieben -- mit Zeilenzaehlung und PRAGMA-Spaltenliste, aber OHNE
die Sicherung davor, ohne die Indizes und ohne `foreign_key_check`
danach. Drei von fuenf Absicherungen fehlten, und keine davon haette
gefehlt, wenn ich die vorhandene Funktion benutzt haette. Genau davor
warnt ihr eigener Kommentar seit dem 09.09.2026.
Jetzt: `checkListeErweitern` aus workspace.js, ausgegeben statt
nachgebaut. Der Marker ist die erste fehlende Stufe und keine
hingeschriebene -- eine feste Angabe waere an dem Tag falsch, an dem
eine weitere dazukommt.
Und danach wird NACHGESEHEN, was wirklich erlaubt ist: Bricht die
Umstellung ab, werden die neuen Stufen auch nicht angeboten. Ein Knopf,
der beim Druecken scheitert, ist schlechter als kein Knopf.
WAS SONST NOCH NACHGEZOGEN WURDE
* Der Zaehler auf der Creator-Startseite zaehlte fest
`stufe = 'verbessern'`. Die staerkste Rueckmeldung, die es gibt,
waere als Einzige nicht dort erschienen. Jetzt aus dem Katalog.
* Der Satz unter "Feste Punkte" stand im Browser und sprach in BEIDEN
Haeusern vom "Creator". Die Teamfassung bleibt wortgleich -- ab dem
24.09. wird jeder Umbau je Haus getrennt gefuehrt, und dies ist der
des Agenturhauses.
* "Passt" setzt weiterhin mit einem Klick. Ein Nachfragefenster vor
dem haeufigsten Klick einer Betreuung, die vierzig Punkte durchgeht,
macht aus einem Durchgang eine Sitzung.
GEMESSEN
* pruef-checkliste-stufen.mjs, neu: 56 Pruefungen, 0 Fehler. Darin
die Umstellung an einer Datenbank mit dem ALTEN Bauplan und echten
Zeilen -- Zeilen, Spalten UND Spalteninhalte nachgezaehlt, plus die
Sicherung. Zu jeder Schranke die Gegenprobe, die durchkommen muss.
* pruef-checkliste 97, pruef-modi-checkliste 75, pruef-haus-trennung
97, pruef-manager-sicht 43 -- alle unveraendert gruen.
* pruef-checkliste rechnete mit festen Zahlen (drei Bilanzkacheln,
zwei Knoepfe je Punkt) und war rot, ohne dass etwas kaputt war. Sie
fragt die Zahlen jetzt bei der Schnittstelle ab und zaehlt sie im
Browser nach. Gleich viele Pruefstellen, 57.
* Bildschirmfotos bei 1280 px und 390 px (Betreuung, Creator, das
Nachfragefenster): vier Knoepfe passen auf dem Handy als 2x2, 0 px
Ueberhang, keine Konsolenfehler.
* Die neuen Toene sind gerechnet, nicht gegriffen: #d97f87 hat die
relative Helligkeit 0,317 -- so hell wie das vorhandene Gruen
(0,320) und heller als das Blaugrau von "offen" (0,241), das den
Barrierefreiheits-Lauf schon bestanden hat. Kein Signalrot: Ein
gedaempftes Rosé sagt "das gehoert geaendert", ein Rot sagt "du
hast versagt".
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
9863645952 |
Die zwei Häuser sind getrennt -- und die Tür geht in beide Richtungen
Filipe: "ich will dass du zuerst die komplette site vn der workspace
seite trennst. da soll nichts verknüpft sein. wenn ich bei der einen
was mache soll nichts bei der anderen passieren. … es soll nur für
dogfather eine kachel geben wo er mit einem einfachen klick von der
einen auf die anderen seite kommt aber sonst garnichts."
Das kehrt die Entscheidung vom 10.09.2026 um ("getrennt wird das
AUSSEHEN, nicht der Bestand"). Wer den alten Kommentar liest, liest
einen überholten Stand -- das steht jetzt an jeder betroffenen Stelle.
WAS GEMESSEN WAR, BEVOR ETWAS GEBAUT WURDE
* Nur drei Module trennten nach Haus (Aufgaben, Bereiche, Dateien).
Chat, Kalender, Wissen, Material, Personenlisten und der Rest nicht.
* Die Trennung war EINSEITIG: nurHaus() griff nur auf crew.
* siehtModis() hebelte sie für DogFather auf der Agenturseite aus --
in seiner Gesprächsliste standen dort beide Häuser nebeneinander.
* Keine haus-Spalte in der Datenbank.
* Der Bestand kreuzte aber kaum: 0 von 86 Terminen gemischt, 0 von 7
Zweier-/Gruppengesprächen, genau EIN Kanal.
WAS JETZT DASTEHT
* Drei Rollenmengen in crew-adresse.js (crew / agentur / beide) und
hausVonRolle(); eine unbekannte Rolle bekommt null, kein Haus.
* Spalte `haus` an acht Wurzeltabellen, nachgetragen aus Belegen:
238 Zeilen eindeutig, die Wissensablage geschlossen der Agentur,
vier Restzeilen namentlich, der gemischte Kanal aufgelöst
(die zwei Scouts gehen heraus, die 7 Nachrichten sind alle vom
Team). Offen bleiben: null.
* nurHaus, hausBedingung und darfAnlegen gelten in BEIDE Richtungen.
* Der siehtModis-Durchgriff ist weg -- aber in DREI Fällen, nicht
zwei: Prüfadressen bekommen gar kein Haus und verhalten sich exakt
wie vorher. Die erste Fassung hatte das übersehen und 19 Prüfungen
umgeworfen, an denen nichts kaputt war.
* Kalender: getrennt, aber "belegt" bleibt (Filipes Entscheidung).
Die Blöcke tragen NUR Beginn und Dauer -- kein Titel, keine Person.
Gebaut als Gegenstück zur Liste (meine Termine MINUS die sichtbaren),
damit beide nicht auseinanderlaufen können.
* Die Wissens-Kachel ist auf der Team-Adresse weg UND die Route
antwortet dort mit 404 -- eine fehlende Kachel ist nur eine Bitte.
* Die Wechsel-Kachel für DogFather geht jetzt in beide Richtungen.
GEPRÜFT: pruef-haus-trennung 97 statt 81, 0 Fehler (vorher 7, alle
haben die alte Regel behauptet). Die neuen Abschnitte sind DORT
eingezogen statt in eine zweite Datei -- `pruef-haustrennung.mjs` hätte
sich von `pruef-haus-trennung.mjs` um einen Bindestrich unterschieden.
Dazu grün: haus-seiten, crew-adresse, chat, chat-kanaele,
kanal-besetzung, kalender, serien, treffchat, wissen-neu,
modi-checkliste, modi-katalog, rechtetafel, personen-liste, sicht,
verborgen, fremde-sicht, alle-wege.
NICHT VON MIR: pruef-treff (3) und pruef-kachel-universum (2) waren
schon vorher rot -- beim Treff auf dem Stand
|
||
|
DogFatherGitandClaude Opus 5
|
40b48e89f1 |
Bei "An alle" sieht man jetzt, wer sie hat und wer nicht
Filipe: "wenn ich eine aufgabe an alle verteile will ich dass dogfather und die rechte hand individuel von jedem sehen wer es gemacht hat oder nicht." Vier Fehler, die zusammenhingen -- alle gemessen, keiner geraten: 1. "Alle" waehlen, "An alle" druecken, nichts passiert. Die Zeile verglich verantwortlich_id !== "alle"; niemand heisst so, also wurde jede Aufgabe uebersprungen und die Liste blieb leer. Die Aufgaben entstanden, man sah es nur nicht. 2. Der Vermerk an der Karte haette bei "alle" den Stand EINER fremden Person gezeigt -- welcher, haengt von der Reihenfolge der Daten ab. Jetzt steht dort, wie weit es ist, und darunter namentlich, wer sie hat: Offen / Erledigt / ueberfaellig / hat sie nicht. Das Wort steht immer dabei, die Farbe ist nur die Abkuerzung. 3. Die "An wen"-Reihe zeigte SECHS Personen, der Server belieferte VIER. Rechte und linke Hand gingen leer aus, ohne ein Wort; einzeln angeschrieben kam "Das gibt es nicht mehr, lade die Seite neu" zu jemandem, den es sehr wohl gibt. Empfaenger sind jetzt Modis UND linke Hand (Filipes Regel vom 22.09.), und die Menge steht EINMAL in workspace.js -- SQL-Abfrage, Annahme und Browserliste leiten sich daraus ab und koennen nicht mehr auseinanderlaufen. 4. Zweimal "An alle" legte alles doppelt an. Der Kommentar im Server behauptete das Gegenteil; aktiv war die Sperre nur beim Massenknopf. "An alle" fuellt jetzt Luecken. Die bewusste Wiederholung bleibt: Steht am Knopf "Nochmal" (weil wirklich alle sie haben), sagt der Browser das ausdruecklich, und dann legt der Server neu an. Geprueft: pruef-modi-katalog 144 statt 133, 0 Fehler -- elf neue Pruefungen fuer Empfaenger, Luecken und die Gegenprobe, dass ein gewolltes "Nochmal" sehr wohl anlegt. Dazu mess-alle-einzelsicht.mjs (eigene Wegwerf-Datenbank, nie die echte) mit Bildern bei 412 und 1280 px. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
67b5e00150 |
Die Support-Kachel steht zwischen "Wer sieht was" und "Vertraulich melden"
Filipe, mit zwei Bildschirmfotos: "die kachel auf screen 2 soll zwischen
den kacheln auf screen3 sein bitte."
ZWEITER FEHLER, DEN ER NICHT GEMELDET HAT -- und der groessere: Die
Support-Kachel hatte GAR KEINE Gruppe. Sie stand deshalb bei JEDER
Rolle in einem eigenen Abschnitt OHNE UEBERSCHRIFT, allein, mit einem
Aufklapp-Kopf, auf dem nur "1" stand. Gebaut habe ich das heute frueh;
auf seinem Bildschirmfoto war es zu sehen, und mir ist es nicht
aufgefallen, weil ich auf die Kachel geschaut habe und nicht auf das,
was um sie herum steht.
Jetzt gehoert sie zu "Fuer dich" und wird VOR den vertraulichen
Meldeweg eingeschoben statt ans Ende gehaengt. Gesucht wird der NACHBAR
ueber sein Ziel, nicht eine Position -- eine feste Zahl waere beim
naechsten Umbau still falsch. Findet sich der Nachbar nicht (ein Modi
hat den Meldeweg nicht), steht sie am Ende der Gruppe.
GEMESSEN, NICHT GERECHNET (1280 px, angemeldet, je Rolle):
admin/hand Fuer dich: Steckbrief | Wissen | Personen & Zugaenge
Wie geht's dir? | Wer sieht was | Support
Vertraulich melden
modi Fuer dich: Steckbrief | Wissen | Wie geht's dir?
Support
gast Fuer dich: Support | Vertraulich melden | Steckbrief
Bei DogFather und der rechten Hand bricht "Vertraulich melden" in eine
eigene Zeile um: Die Gruppe hat jetzt sieben Kacheln, das Raster drei
Spalten, und sieben geht durch drei nicht auf. Die Luecke faellt ans
ENDE -- das ist die bessere der beiden Moeglichkeiten und dieselbe
Regel, die im Kommentar zur Treff-Reihe steht: "eine Luecke in der
Mitte sieht kaputt aus, eine am Ende sieht grosszuegig aus."
NEU: server/mess-kachelreihen.mjs. Die Reihenfolge im Quelltext ist
NICHT die auf dem Bildschirm -- "Willkommen" belegt zwei Spalten,
gruppiert wird nach dem ersten Auftreten einer Gruppe, und eine Kachel
ohne `gruppe` bekommt einen eigenen namenlosen Abschnitt. Genau daran
ist dieser Fehler entstanden. Die Datei misst es im Browser, je Rolle,
und meldet einen Abschnitt ohne Ueberschrift ausdruecklich als Befund.
Sie prueft nichts.
Gemessen: pruef-support 45, pruef-unterstuetzung 70,
pruef-start-ansicht -- gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e11f775489 |
"Unterstuetzen" steht jetzt links, "Mitmachen" in der Mitte
Filipe, mit Bildschirmfoto der letzten Reihe: "wechsel bitte die reihenfolge, links soll unterstuetzen sein, in der mitte dan mittmachen und recht regeln & hilfe." Mein erster Entwurf hatte "Unterstuetzen" HINTER "Mitmachen", mit der Begruendung "erst dazugehoeren, dann etwas beitragen". Die Ueberlegung war nicht falsch -- sie war nur meine. Der Kommentar an der Kachel sagt das jetzt auch so; stehengelassen haette er beim naechsten Lesen eine Reihenfolge begruendet, die es nicht mehr gibt. GEMESSEN STATT GERECHNET: Die Reihenfolge im Feld ist nicht die Reihenfolge im Raster -- "Willkommen" belegt zwei Spalten und verschiebt alles danach. Im Browser nachgesehen (Gast, 1280 px): Reihe 1 Willkommen (2) | Rudel-Chat Reihe 2 Highlights | Anschlagbrett | Was ansteht Reihe 3 Wunschliste | Dogi-Media | Draussen Reihe 4 Unterstuetzen | Mitmachen | Regeln & Hilfe Nebenbei: Die Rasterskizze im Kommentar darueber zeigt den Stand vom 17.09.2026 und stimmt seither nicht mehr mit der Kachelliste ueberein. Sie ist jetzt als solche gekennzeichnet, statt als aktuelle Karte gelesen zu werden. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
aa2e1a4ae2 |
Eine Kachel "Unterstuetzen" -- und die Gespraechsliste neu gebaut
=== 1. UNTERSTUETZEN (neue Kachel im Community-Bereich) ===
Filipe: "ich brauch auch noch eine kachel im community bereich. wo mein
paypal und meine amazon liste sein wird. wo die leute alle supporten
koennen auf andere art anstatt nur tiktok. jeder soll diese kachel sehen
aber nur dogfather soll sie veraendern koennen oder vieles mehr sehen."
Neu: unterstuetzen.html + css + js, server/workspace-unterstuetzung.js,
server/unterstuetzung-tabellen.js. Ton 45 (#7567fe) ist gerechnet, das
Kachelzeichen ist ein Herz ueber zwei offenen Haenden.
DIE WEGE STEHEN IN DER DATENBANK, nicht im Quelltext -- ein Recht, das
man nur ueber einen Entwickler ausueben kann, ist keines. DogFather
schreibt Titel, Text, Knopf und Adresse selbst, blendet Wege aus und
nimmt neue dazu.
DER PAYPAL-LINK STEHT LEER UND UNSICHTBAR DA. Filipe schrieb "mein
paypal kennst du ja schon" -- gesucht im ganzen Haus und im Vault,
nirgends gefunden. Eine Zahlungsadresse zu RATEN waere der
gefaehrlichste Fehler dieser Seite: Geld an einen Fremden, und niemand
merkt es. Also steht dort nichts, der Weg ist ausgeblendet, und die
Seite sagt genau EINER Person, dass er fehlt.
DREI ARTEN, UND DIE DRITTE IST DIE WICHTIGSTE: geld, geschenk, frei.
"Kostet nichts" bekommt dieselbe Kartenform und dieselbe Groesse.
Waeren die freien Wege kleiner oder weiter unten, waere die Aussage
"das ist zweite Wahl" -- und die Mehrheit derer, die hier lesen, waere
damit zweite Wahl.
DIE ZAEHLUNG IST ANONYM, UND ZWAR VON DER TABELLE HER. DogFather sieht,
wie oft ein Weg geoeffnet wurde (7/30 Tage/gesamt). Was er NICHT sieht,
ist WER -- weil es in unterstuetzung_striche keine Spalte dafuer gibt.
Geprueft wird das ueber PRAGMA table_info, nicht ueber eine Abfrage:
eine Abfrage liesse sich morgen erweitern, eine fehlende Spalte nicht.
Schreiben haengt an istDogFather, nicht an istLeitung -- die rechte Hand
fuehrt dieses Team mit und kommt trotzdem nicht an diesen Link. Jede
Adresse wird beim SCHREIBEN geprueft (nur https:// oder eine Seite
dieses Hauses); javascript:, data:, http:// und // werden abgewiesen.
Neu: server/pruef-unterstuetzung.mjs -- 70 Pruefungen, alle gruen.
Sie misst ueber die CREW-ADRESSE: Beim ersten Lauf waren vier Rollen
gruen und der Zuschauer rot, und es sah nach einem Rechtefehler aus.
Es war ein Messfehler -- ueber 127.0.0.1 landet man still im
Agenturhaus, und dort gibt es die Rolle "gast" gar nicht.
=== 2. DIE GESPRAECHSLISTE (screen1 + screen2) ===
Filipe: "ich will dass die komplette kachel viel krasser und geiler
aussieht. der hintergrund der kachel soll gleich bleiben."
Der Hintergrund ist unangetastet. Zwei echte Fehler auf seinem Bild:
- Bei "Das Rudel" stand das "@" rechts oben und die orange "6" eine
ZEILE TIEFER. Der Knopf ist ein Raster mit DREI Spalten und bekam
VIER Kinder -- das vierte fiel um. Ausgerechnet die wichtigste
Auskunft der Liste landete an der unauffaelligsten Stelle.
- Jedes Gespraech mit Profilbild haengte das Bild ZWEIMAL ein: ein
Block stand Zeichen fuer Zeichen doppelt da. Zu sehen war nichts,
gekostet hat es die doppelte Ladelast bei jedem Neuzeichnen.
Und eine tote Regel: `.chat-raum__knopf[data-an="ja"]` beschrieb die
Schiene am offenen Gespraech -- gesetzt wird aber `data-offen` am <li>.
Die Regel griff nie, und daneben stand eine zweite, blassere Fassung
derselben Sache. Jetzt steht alles einmal, und die Schiene ist da.
Dazu: Zeilen als Karten, 44px-Gesichter, ein Zaehler neben "Gespraeche",
Suchfeld als Pille mit Lupe, runder Farbfleck statt Quadrat, und der
leere Raum rechts bekommt eine Mitte statt eines Satzes in der Ecke.
=== 3. VIER FUNDE NEBENBEI ===
- supportAufraeumen() war exportiert und wurde NIRGENDS gerufen. Die
Meldungen samt Bildschirmfotos waeren fuer immer liegen geblieben,
obwohl "90 Tage" dokumentiert ist. Jetzt im Loeschkonzept.
- aufgaben_zuteilung fehlte ebenfalls im Loeschkonzept (seit 21.09.).
pruef-aufbewahrung ist damit wieder gruen.
- pruef-start-ansicht war rot, seit "Aufgaben" am 23.09. die silberne
Kachel bekam -- die ueberschreibt ihr --ton absichtlich. Die
Pruefung nimmt sie jetzt aus UND prueft die Ausnahme selbst.
- pruef-buehne meldete auf entwicklung.html 1,79:1 Kontrast bei "Wen
gehst du durch?" -- die Ueberschrift lag direkt auf dem Foto. Sie
steht jetzt auf einer deckenden Flaeche.
OFFEN: pruef-buehne meldet treff-regeln.html mal "0 von 40", mal "3 von
40" -- dieselbe Seite, verschiedene Antworten. Eine Pruefung, die
schwankt, ist schlimmer als eine rote. Nicht in diesem Zug behoben.
Gemessen: pruef-unterstuetzung 70, pruef-start-ansicht, pruef-buehne
(bis auf den Wackler), pruef-workspace-seiten, pruef-aufbewahrung 45,
pruef-rechtetafel 19, pruef-css-klassen, pruef-chatkachel 36,
pruef-chat-ausbau, pruef-entwicklung-kacheln 31 -- gruen.
Neu: server/mess-chat-liste.mjs (zeigt die Liste mit sieben Gespraechen
verschiedener Art, prueft nichts).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
5b244ab7ec |
Die Personenkachel wird eine Standkarte -- mit den Aufgaben darauf
Filipe: "mach das bitte viel krasser und viel geiler. die aufgaben die
wir verteilen sollen da auch zu sehen sein und so. viel
uebersichtlicher, viel moderner. nicht so banal und einfach."
VORHER: Name, Rolle, ein flacher Balken und drei Zahlenkaesten. Auf
seinem Bildschirmfoto standen in fuenf von sechs Kacheln exakt
dieselben drei Zahlen (0 / 68 / 0) -- achtzehn Kaesten fuer eine
einzige Auskunft. Und die Aufgaben, die er eine Handbreit darunter
verteilt, kamen auf der Kachel derselben Person gar nicht vor.
JETZT drei Zonen in der Reihenfolge, in der man fragt:
KOPF Ring mit dem Anteil in der Mitte, Name, Rolle.
AUFTRAG Wie viele offen, wie viele ueberfaellig, und die naechste
mit Namen und Frist ("seit gestern ueberfaellig").
FUSS "46 von 68 angesehen" -- und "verschieden gesehen" nur
dann, wenn es dort etwas gibt.
Der Ring rechnet mit stroke-dasharray auf einem Kreis vom Umfang 100:
der Anteil in Prozent ist damit buchstaeblich die Strichlaenge. Keine
Ampelfarbe -- was "genug" ist, haengt davon ab, wie lange jemand dabei
ist. Gewarnt wird nur an einem Massstab, der nicht geraten ist: einer
ueberschrittenen Frist.
Die Aufgabenzeile wird aus derselben Liste gerechnet wie das
Verteil-Band und der Katalog (alleAufgabenV) und in aufgabenHolen()
nachgezogen -- an EINER Stelle, damit es keine gibt, die es vergisst.
GITTER STATT FLIESSREIHE: Bei sieben Leuten stand die letzte Kachel
allein in ihrer Zeile und wuchs auf 1160 px neben 379 px der anderen.
Eine Person sah dreimal so wichtig aus, weil die Teamgroesse ungerade
ist.
Drei Funde nebenbei, alle durch die neuen Messungen:
- pruef-schritt verlangte seit dem 23.09. einen Sprung, der an dem
Tag ABSICHTLICH entfernt wurde. Sie war seither rot, ohne dass
etwas kaputt war. Neu gefasst auf den Sprung, den es noch gibt:
den Weg von aussen ueber "?zeigen=person-...".
- Und der war kaputt. Gesprungen wurde, waehrend in der Karte nur
"wird geladen ..." stand -- die Seite war zu kurz zum Scrollen,
der Browser klemmte bei 0 ab. Wer der Talentseite folgte, landete
oben auf der Liste. Gesprungen wird jetzt, wenn die Karte steht.
- Auf demselben Weg rief karte() das Vorlagenbrett, bevor es
eingerichtet war ("zeigen() vor einrichten()"). Das Einrichten ist
vorgezogen. Ueber "?zeigen=" ging vorher KEINE Pruefung.
Gemessen: pruef-entwicklung-kacheln 31 (vorher 16), pruef-schritt 68
(vorher 65), pruef-entwicklung 48, pruef-modi-katalog 133,
pruef-bewerbung-aufgaben 101, pruef-zuteilung, pruef-css-klassen --
alle gruen. Schriftgroessen unter 11,5 px: 40 statt 42.
Neu: server/mess-entwicklung-kacheln.mjs. Die Pruefung braucht einen
kargen Bestand und zeigt deshalb den Sonderfall (alles auf null); diese
Datei legt sieben Leute mit verschiedenen Staenden und Aufgaben an und
macht Bilder fuer 1280 und 390 px. Sie prueft nichts.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
1d41e29bf7 |
Drei weitere Prüfungen, die das Falsche prüften
Der Durchgang, zweiter Teil. Gesucht nach dem schaerfsten Filter, den es dafuer gibt: dem VERSPRECHEN GEGEN DIE WIRKLICHKEIT -- Pruefsaetze, die „jede Rolle" oder „jede Seite" sagen. Genau so ist pruef-glocke heute frueh aufgefallen. 1. pruef-workspace-seiten meldete aufgaben.html als „Breite 1560px". KEIN FEHLER: Die Seite traegt zusaetzlich `.inhalt--brett`, und die setzt ausdruecklich 1560 px -- mit Begruendung in aufgaben.css („ein Brett darf breiter sein als Text, der Kopfbereich bleibt lesbar schmal"). Die Pruefung verglich starr mit 1240 und kannte die Klasse nicht; sie meldete damit eine Absicht als Fehler, seit dem Tag, an dem die Klasse entstand. Mit Gegenprobe belegt: schon vor allen Aenderungen von heute rot. Jetzt kommt die erwartete Breite aus den KLASSEN des Elements. Beide Zahlen bleiben stehen, weil sie etwas aussagen -- kommt weder 1240 noch 1560 an, ist die Regel verloren. 2. pruef-meldungen meldete „ohne Satz: ungueltiger_stand". Zuerst ein ECHTER Fehler, und zwar meiner vom selben Tag: In workspace-support.js stand eine nackte Kennung statt eines Satzes. Behoben -- und danach meldete die Pruefung sie WEITER, weil sie das Zitat im Kommentar las, der die Behebung begruendet. Dieselbe Falle wie ein Grep ueber eine Datei, die ihre eigene Geschichte enthaelt; mir ist sie heute schon einmal passiert. Eine Pruefung, die verbietet, ueber einen behobenen Fehler zu SCHREIBEN, erzieht dazu, die Begruendung wegzulassen. Kommentare zaehlen jetzt nicht mehr; Adressen mit // in Zeichenketten bleiben unberuehrt. 3. pruef-auskunft meldete „NICHT EINGEORDNET: vorlagen_bewerbungen.aufgabe_id". ECHT: Die Spalte zeigt auf eine Aufgabe, nicht auf einen Menschen, und stand in keiner der beiden Listen. Das ist mehr als Ordnungsliebe -- bei einer Auskunftsanfrage muss das Haus sagen koennen, welche Spalten auf eine Person zeigen. Eine unbekannte Spalte ist eine, bei der niemand weiss, ob sie mitgehoert. ZWISCHENSTAND: ACHT Pruefungen an einem Tag, die rot waren oder das Falsche prueften. Das Muster ist immer dasselbe -- eine Liste oder Zahl, die zum Zeitpunkt des Schreibens stimmte. Sie wird nicht falsch, sie wird unzustaendig. Gruen: pruef-meldungen (8), pruef-auskunft (46), pruef-workspace-seiten, pruef-support (45), pruef-vorlagen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
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
|
03220b3924 |
Kanaele machen nur zwei auf
Filipe: "kanaele sollen auch nur die rechte hand und dogfather
aufmachen koennen."
Bis heute galt `fuehrtTeamDogi` -- und das schliesst die LINKE Hand
ein (WIE_RECHTE_HAND = {hand, linke}). Genau die zwei Worte im Auftrag
schliessen sie aus.
`fuehrtTeamDogi` SELBST WIRD NICHT ANGEFASST. Es haengt an elf
weiteren Stellen: Bereiche, Bretter, Sichtbarkeiten, wer einen Kanal
ueberhaupt sieht. Wer die Funktion aendert, aendert zehn Dinge, die
niemand verlangt hat. Stattdessen eine eigene Regel fuer genau diese
eine Frage -- dieselbe Bauweise wie `darfJedeNachrichtLoeschen` ein
paar hundert Zeilen weiter unten, die aus demselben Grund entstanden
ist ("zwei Rollen, woertlich die zwei aus dem Auftrag").
Nicht `istLeitung` uebrigens: Das schlösse Spicy Media ein, und
genannt wurden zwei Rollen, nicht drei.
AN EINER STELLE, NICHT AN ZWEIEN. Der Server lehnt ab, und die
Oberflaeche bietet es gar nicht erst an -- beide fragen dieselbe
Funktion. Ein Knopf, den man sieht und der dann mit 404 antwortet,
ist schlimmer als keiner.
WAS ES NICHT BETRIFFT: Wer in einem BESTEHENDEN Kanal die Leute
aendert. "Aufmachen" beantwortet diese Frage nicht, also bleibt es
dort beim Alten. Falls das auch enger werden soll, sagt Filipe es.
Gemessen, alle vier Rollen durchgespielt:
DogFather darf -> 201, Seite bietet es an
rechte Hand darf -> 201, Seite bietet es an
linke Hand darf NICHT -> 404, Seite bietet es nicht an
ein Modi darf NICHT -> 404, Seite bietet es nicht an
Dazu die Gegenprobe, dass die Absage nichts verraet: Eine erfundene
und eine echte Kategorie sehen fuer die linke Hand gleich aus (404 /
404). Sonst waere aus der Fehlermeldung abzulesen, welche Kanaele es
gibt. 9 Messungen, 0 Befunde. pruef-chat-kanaele: 81 geprueft,
0 Fehler.
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
|
290d7c8d88 |
Zwei Pruefungen massen einen Stand, den es nicht mehr gibt
Beide Befunde sind heute beim Umzug des Vorlagenkatalogs aufgefallen,
gehoeren aber nicht dazu -- sie lagen schon vorher da und haetten bei
jedem Lauf mitgemeldet, bis sie niemand mehr liest.
pruef-struktur las Server-Routen nur in doppelten Anfuehrungszeichen.
Wer eine Route in einer Schleife registriert, schreibt sie aber als
Template:
for (const weg of ["annehmen", "ablehnen"])
router.post(`/workspace/api/vorlagen/bewerbung/${weg}`, ...)
Diese Routen fehlten in der Liste, und die Aufrufe dorthin galten als
"Schnittstelle gibt es nicht" -- obwohl sie laufen. Die Erfassung der
AUFRUFE kannte alle drei Zeichen laengst; nur die der ROUTEN nicht.
Zwei Regeln fuer dieselbe Frage, und eine davon war aelter. Gemessen:
319 statt 315 Routen, und der Fehlalarm ist weg. Die Gegenproben
schlagen weiter an ("erfundene Schnittstelle wird als fehlend
erkannt").
pruef-aufgaben-vorlagen zaehlte KARTEN und erwartete +1. Seit das
Brett gleiche Aufgaben zu einer Sammelkarte zusammenfasst, stimmt das
nicht mehr -- die Pruefung legt kurz davor sieben Vorlagen derselben
Stufe an, und die neue wanderte in eine bestehende Karte. Sie meldete
"9 -> 9" und behauptete damit, das Uebernehmen sei kaputt; drei Zeilen
weiter erkannte sie dieselbe Aufgabe als "schon uebernommen" wieder.
Jetzt zaehlt sie Aufgaben: "9 -> 10 Aufgaben in 9 Karten".
Dieselbe Stelle gab es zweimal. In pruef-modi-katalog ist sie gestern
repariert worden -- hier nicht, weil ich nach dem ersten Fund nicht
weitergesucht habe.
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
|
1851d447c3 |
Der Raumname heilt sich -- und jetzt steht die Gegenprobe dafuer
Nach dem Ausliefern am echten Server nachgesehen: Die Zeile in der Datenbank hiess weiter "Der Treff". Kein Fehler -- treffAngleichen() laeuft beim Abrufen der Gespraechsliste, und seit dem Neustart hatte noch niemand den Chat offen. Sie heilt sich beim ersten Aufruf, und zwar VOR dem Auslesen der Liste: Der Erste, der hinsieht, sieht schon den neuen Namen. Nur war das bis eben eine Herleitung und keine Messung. pruef-erwaehnung traegt den alten Namen jetzt absichtlich wieder ein, BEVOR die Gespraechsliste geladen wird, und prueft danach, dass er weg ist. Ohne diesen Schritt waere die Zeile auch dann gruen, wenn der Abgleich den Namen gar nicht anfasst -- der Raum wird im Test ja neu angelegt und traegt den richtigen Namen von Anfang an. Genau so sieht eine Pruefung aus, die immer bestaetigt. pruef-erwaehnung: 123 (vorher 122). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
7a6749630c |
Das Rudel meint den ganzen Raum -- und die Kachelfarbe wird ein Ring
Zwei Auftraege vom 23.09.2026.
SCREEN 1: "da steht links immer noch der treff anstatt das rudel"
Und er hatte recht, auf eine Art, die niemand sehen konnte:
TREFF_NAME stand schon seit der Umbenennung auf "Das Rudel". Nur
setzt treffRaumId() den Namen ausschliesslich BEIM ANLEGEN -- der
Raum existierte laengst, also blieb die Zeile in der Datenbank auf
"Der Treff" stehen. Im Code das eine, auf dem Bildschirm das andere.
Dieselbe Falle stand direkt nebenan schon beschrieben ("drei Stellen,
von denen die dritte vergessen wird") -- die Vorsorge galt aber nur
fuer die Teilnehmer, nicht fuer den Namen. Eine halbe Selbstheilung
heilt die andere Haelfte nicht. Jetzt gleicht treffAngleichen() auch
den Namen ab; eine kuenftige Umbenennung ist wieder eine Zeile.
(IS NOT statt !=: Bei NULL ergaebe != in SQLite NULL, und die Zeile
bliebe unveraendert liegen.)
"und wenn wir da im chat @rudel machen will ich dass jeder in dem
chat markiert wird. nicht nur team ... und sehr wichtig ich rede nur
von dem chat wo die ganze community auch drin ist."
Bis heute erreichte der Ruf ueberall nur Team Dogi. Die Begruendung
stand im Code und war nicht falsch -- im Rudel-Raum sitzt die
Community. Genau das will Filipe jetzt, und zwar nur dort:
im Rudel-Raum -> alle, die drin sind
ueberall sonst -> Team Dogi, unveraendert
Was die alte Sorge entschaerft: RUFEN darf weiterhin nur Team Dogi --
kein Zuschauer kann alle wecken. Und die Nachtruhe gilt dort ohnehin.
darf_rudel folgt derselben Frage. Sonst entstuende ein stiller
Widerspruch: Ein Modi mit neun Zuschauern und ohne zweites
Teammitglied traefe mit @rudel neun Leute -- der Vorschlag beim
Tippen waere aber ausgeblendet. Die Funktion gaebe es, und niemand
faende sie.
Das Schild sagt jetzt die Wahrheit: "alle in diesem Chat" statt
"alle im Team". Stuende dort weiter das alte, waere es im Rudel-Raum
gelogen -- und zwar nach unten, also in die Richtung, in der man
leichtfertig drueckt.
Gegenprobe in pruef-erwaehnung: In der Testgruppe sitzen DogFather
und zwei Scouts; ein @rudel dort ruft NIEMANDEN. Waere die Regel
versehentlich im ganzen Haus aktiv, waeren die Scouts markiert.
"sonst nichts anfassen" ist damit gemessen, nicht versprochen.
SCREEN 2: "so eine art diagramm, wo man mit einem kreis herum gehen
kann und die farbe ganz genau selber auswaehlen kann"
Der Haken daran ist nicht die Optik. Die zwoelf Kacheln waren
GERECHNET, damit niemand sich unlesbar machen kann -- alle auf
derselben Leuchtdichte. Ein Farbkreis, der einfach den Farbton dreht,
wirft das weg: Ein gesaettigtes Gelb ist um ein Vielfaches heller als
ein gesaettigtes Blau, und helle Schrift ist darauf nicht mehr zu
lesen.
Der Ring ist deshalb KEINE neue Rechnung, sondern dieselbe in 360
Schritten statt in zwoelf. tools/chat-kacheln-rechnen.mjs --kreis
schreibt server/chat-kreis.js; buntest() und die Kontrastpruefung
darin gelten unveraendert. Ergebnis: ein Ring gleicher Helligkeit --
kein blendendes Gelb, kein abgesoffenes Blau. Das sieht ruhiger aus
als der uebliche Farbkreis, und genau das ist der Punkt.
Der Browser rechnet nichts. Er bekommt die 360 fertigen Farben und
legt sie in dieselbe Tabelle wie die Kacheln -- ab da ist "ton-214"
ein Schluessel wie "veilchen", und jede Stelle, die eine Farbe
nachschlaegt, funktioniert unveraendert.
Welche Kacheln neben dem Ring bleiben, wird ABGELEITET statt
aufgezaehlt: Grau hat keinen Farbton, Babyblau ist die eine helle mit
eigener Schrift. Nachgemessen liegen die elf bunten zwischen 0,0 und
2,4 von ihrer Ringfarbe entfernt, Grau bei 75,4 und Babyblau bei
192,9 -- zwischen 2,4 und 75 ist so viel Luft, dass die Schwelle
nicht knapp ist.
Gespeichert wird erst beim Loslassen. Wer einmal um den Ring fuehrt,
erzeugte sonst dreihundert Anfragen.
Gemessen (pruef-chat-neu, jetzt 32 Pruefungen, als Modi auf crew. mit
dem Finger): 265 px gross, aus 361 Farben gemalt, touch-action none
(sonst schiebt das Handy die Seite weg statt zu drehen), Drehen auf
drei Uhr ergibt genau Winkel 90, die Mitte zeigt exakt #675102,
vorgelesen als "Goldbraun, 90 Grad", in der Datenbank steht ton-90,
Pfeiltaste dreht ein Grad weiter. Und das eigentliche Versprechen:
alle 360 Toene tragen die Schrift der Blase, knappster Faktor 1,000.
Dabei zwei eigene Fehler, beide aufgeschrieben: Der erste Anlauf
wartete 30 Sekunden auf den Farbknopf -- am Handy weicht die Spalte
mit den Gespraechen zur Seite, sobald ein Chat offen ist. "Ist im
HTML" und "ist erreichbar" sind zwei Aussagen. Und die Schriftfarben
wurden an der falschen Klasse gemessen, was einen roten Haken an
einer heilen Stelle ergab.
Ausserdem: Das native confirm() beim Herausnehmen eines GIFs ist
weg -- meine eigene Abkuerzung vom Morgen. Gemeldet hat es
pruef-nachfrage, allerdings erst, nachdem der verlorene Backslash in
derselben Datei repariert war.
Zahlen: pruef-erwaehnung 122 (vorher 119), pruef-chat-neu 32
(vorher 19), pruef-nachfrage 46 bestanden.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
a9d920e7d0 |
Vier stillgelegte Pruefungen, zwei kaputte Zeichen -- und die Wache dagegen
Gefunden beim Vorbereiten der KLIPY-Anbindung, nicht gesucht.
DER VERLORENE BACKSLASH
In fuenf Dateien stand in einem Suchmuster das BYTE 0x08 statt der
zwei Zeichen \ und b. Gemeint war die Wortgrenze; 0x08 ist das
Rueckschritt-Zeichen und kommt in keinem Text vor. Gemessen:
/<0x08>modis?<0x08>/i.test("Die Modis sind da") -> false
/\bmodis?\b/i .test("Die Modis sind da") -> true
Folgen, je Stelle:
pruef-nachwuchs Das Muster stand in einer VERNEINUNG. Die
Zeile lautete damit ok(!false) -- dauerhaft
gruen, ohne etwas zu messen. Ausgerechnet
die Zeile, die das Durchsickern des
Rollennamens verhindern soll.
pruef-personen-formular dasselbe Muster, dieselbe Verneinung
pruef-nachfrage hatDialogMitFeld war immer falsch. Seiten
mit einem Formular-Dialog galten als "totes
Gewicht" -- der Kommentar direkt darueber
warnt woertlich vor genau diesem Schaden.
pruef-entwicklung zwei von drei Alternativen tot
workspace-treff.js nur ein Kommentar, aber unlesbar
ZWEI KAPUTTE ZEICHEN, BEIDE SICHTBAR
content: "<0x15>C9<0x00>A0" in chat.css. Gemeint war U+25C9 und
ein geschuetztes Leerzeichen. Live stand woertlich "C9 A0" vor
jedem hervorgehobenen @rudel -- am echten Server nachgemessen.
content: "¹3" in chat.css UND entwicklung.css. Gemeint war ein
Haken. Auf der gewaehlten Kachel stand "¹3"; zu sehen in Filipes
Bildschirmfoto.
Repariert wird mit der Escape-Schreibweise ("\2713"), nicht mit dem
Zeichen selbst: Sie besteht nur aus ASCII und ueberlebt jede
Kodierung.
WAS DIESE FEHLERART BESONDERS MACHT
Niemand sieht sie beim Lesen. Der erste war committet, ausgeliefert
und lag live -- und als ich in der Datei danach suchte, meldete grep
"Binary file matches" und zeigte die Zeile gar nicht erst an. Wer den
Unterschied durchsieht, liest content: "C9 A0" und denkt sich nichts.
Deshalb neu: server/pruef-zeichen.mjs (7 Pruefungen). Sie sucht rohe
Steuerzeichen in allen ausgelieferten und allen Serverdateien, dazu
Ersatzzeichen und Kodierungstruemmer in CSS-content-Angaben. Mit
Gegenprobe in beide Richtungen -- sie weist an einer selbst gebauten
Datei nach, dass sie anschlaegt, UND dass sie bei einer sauberen
schweigt.
Die erste Fassung der Regel war zu weit: Sie meldete acht KORREKTE
Zeichen (✓, ↯, ↻, „, ⚠). Eine Warnung, die immer kommt, ist keine
Warnung mehr. Die engere Regel kommt aus dem Befund selbst -- der
Latin-1-Block U+0080..U+00BF, in dem echte Typografie nie steht.
Nachgemessen ueber alle 203 content-Angaben im Haus: keine einzige
benutzt ihn.
GEHEIMNISSE STEHEN NICHT MEHR IM PROTOKOLL
einstellungSetzen() schrieb immer Name UND Wert. Nachgemessen in der
echten Datenbank: kopie_schluessel steht vollstaendig drin,
vapid_paar wurde bei 120 Zeichen abgeschnitten -- kurz VOR dem
privaten Teil. Dass der heil blieb, lag an einer Laengengrenze, nicht
an einer Absicht. Keine offene Tuer (das Protokoll liegt hinter
nurAdmin), aber der Wert wandert in jede Sicherung.
Es ist eine REGEL und keine Liste: Wer eine Einstellung so benennt,
meint ein Geheimnis. Stehen bleibt, DASS sich etwas geaendert hat,
wann und durch wen -- nur der Wert fehlt.
EINE VERALTETE PRUEFUNG, UMGEDREHT STATT GELOESCHT
pruef-nachwuchs verlangte, dass die rechte Hand keine Zugaenge
anlegen kann. Das war bis zum 22.09. richtig; dann hat Filipe es
umgedreht ("damit sie das auch machen kann wenn er live ist"). Die
Pruefung war seither rot, ohne dass es auffiel -- sie lief nicht.
Jetzt prueft sie beides: dass die rechte Hand es darf UND dass die
Grenzen stehen (sperren 404, Protokoll 404). Eine Erlaubnis ohne
Grenze ist keine Entscheidung, sondern ein Loch.
Und tools/nachtlauf.mjs wird nachgetragen -- bisher unversioniert.
Zahlen: pruef-nachwuchs 260, pruef-entwicklung 48,
pruef-personen-formular 43, pruef-zeichen 7 (neu), pruef-ports 8.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
c0d2896419 |
pruef-chat-neu: die drei neuen Sachen am Stueck, als Modi, auf dem Handy
Jedes Stueck war geprueft -- und jedes in einer anderen Lage als der
echten:
pruef-chat-anhaenge Sprachnachricht und GIF, aber als DogFather
auf der AGENTURadresse, mit der Maus
pruef-erwaehnung der Rudel-Ruf, aber gegen den Server
Der Fall, den Filipe wirklich hat -- ein MODI auf crew., mit dem
FINGER, und ein zweiter Mensch, der es bekommen soll -- war nie am
Stueck gemessen. Genau in solchen Luecken sitzen die Fehler, die
niemand sieht: Jeder Einzeltest ist gruen, und zusammen geht es
trotzdem nicht.
ZWEI BROWSER, ZWEI MENSCHEN. Eine Sprachnachricht, die nur beim
Absender im Verlauf steht, ist keine. Jede der drei Proben wartet
deshalb darauf, dass die ZWEITE Person sie von selbst bekommt -- ohne
Neuladen.
19 Pruefungen, 0 Fehler:
* Sprachnachricht: Knopf da, Zeit laeuft, Blase mit Laenge, passt auf
390 px, kommt bei der zweiten Modi an
* GIF-Kiste: passt auf den Bildschirm, sagt was zu tun ist, GIF
hineinlegen, verschicken, ankommen -- und die zweite Modi sieht
dasselbe GIF in IHRER Kiste (sie gehoert dem Rudel)
* Rudel-Ruf: das @ oeffnet die Liste, "rudel" steht oben mit "alle im
Team" daneben, 44 px hoch, im Bild; die Nachricht kommt an, der Ruf
leuchtet beim Empfaenger (Gewicht 700), und in der Datenbank stehen
genau die Richtigen -- die andere Modi und DogFather, nicht der
Rufer selbst
ZWEI EIGENE FEHLER BEIM BAUEN, beide in der Datei aufgeschrieben, weil
sie sich wiederholen werden:
(1) OHNE NOTBREMSE. Der erste Lauf blieb stehen und sah von aussen
aus wie "laeuft noch" -- ich musste ihn von Hand abbrechen. Ein
Werkzeug, das haengt, ist schlimmer als eines, das scheitert;
das steht seit dem 06.09. in den Hausregeln, und ich habe es
beim Bauen eines Wegwerf-Werkzeugs trotzdem weggelassen.
(2) MIT ENTER ABGESCHICKT. Auf einem Beruehrgeraet schickt Enter
ABSICHTLICH nicht ab -- sonst kaeme man nie zu einer zweiten
Zeile. Die Messung meldete daraufhin "kommt nicht an"; in
Wahrheit war nie etwas abgeschickt worden. Dasselbe Muster wie
beim `pointer: coarse` heute frueh: Wer im falschen
Geraeteprofil misst, misst ein anderes Programm.
Die Datei ist aus einem Wegwerf-Werkzeug entstanden. Sie bleibt, weil
der Weg, den sie geht, sonst von keiner Pruefung gegangen wird.
pruef-ports: 8 von 8 -- die neue Datei verschiebt die Portnummern
aller spaeteren, und das haelt.
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
|
1f2a4d335e |
Eine Bewerbung, die niemand sieht, ist keine
Beim Weiterarbeiten am Vorlagenbrett nachgemessen und gefunden:
`benachrichtige` kam in workspace-zuteilung.js KEIN EINZIGES MAL vor,
in workspace-vorlagen.js auch nicht.
Beide Bewerbungswege waren gebaut, beide funktionierten -- und beide
waren stumm:
* Bewirbt sich Frida, erfaehrt DogFather es nur, wenn er von sich
aus das Brett aufmacht.
* Antwortet er, erfaehrt Frida es nur, wenn SIE von sich aus
nachsieht.
Das ist keine Kleinigkeit, das ist die Funktion. Wer sich bewirbt,
wartet -- und Warten ohne Rueckmeldung fuehlt sich nach zwei Tagen an
wie "interessiert keinen". Genau das soll eine Bewerbung verhindern.
WER ES ERFAEHRT -- ABGELEITET, NICHT AUFGEZAEHLT
------------------------------------------------
Die naheliegende Zeile waere `rolle IN ('admin','hand')` gewesen; so
steht sie in workspace-hilfe.js. Das ist eine Abschrift, und
Abschriften altern: Kaeme morgen eine Rolle dazu, die entscheiden
darf, bekaeme sie keine einzige Meldung -- und niemand merkte es, weil
ja alles funktioniert.
Gefragt wird deshalb die Regel selbst (entscheidetUeberAufgaben),
Person fuer Person. Und zusaetzlich darfSchreibenMit: Wer den Bewerber
gar nicht sehen darf, bekommt auch keine Meldung ueber ihn. Das ist
keine Vorsicht um ihrer selbst willen -- ohne diese Zeile erfuehre die
Agentur ueber eine Push-Nachricht, dass es Team Dogi ueberhaupt gibt.
Gemessen: Die Bewerbung eines Modis erreicht genau zwei Leute
(admin, hand) von sechs Aktiven. Nicht die linke Hand (sie entscheidet
hier nicht mit), niemand aus dem anderen Haus, und nicht der Bewerber
selbst.
ZWEI SCHALTER, ZWEI ENTSCHEIDUNGEN
----------------------------------
"bewerbung_neu" trifft den, der antwortet -- an einem lebhaften Tag
mehrfach, das kann man stumm stellen wollen. "bewerbung_antwort"
trifft den, der wartet; sie kommt einmal, und niemand will sie stumm
stellen. Eine gemeinsame Art hiesse: beides zusammen abschalten oder
beides zusammen ertragen. Dieselbe Ueberlegung wie beim Chat
(Nachricht / Erwaehnung).
Beide von sich aus an. Keine Ausnahme von der Ruhezeit: Eine Bewerbung
wartet, ein Anruf nicht.
DIE NOTIZ STEHT IN DER MELDUNG
------------------------------
Filipe hat sie ausdruecklich verlangt ("mit einem text als notiz").
Sie erst zu verlangen und dann an genau der Stelle zu verschweigen, an
der man sie liest, waere die halbe Funktion. Und das Ergebnis steht im
TITEL -- "angenommen" oder "diesmal nicht" -- damit man es lesen kann,
ohne zu oeffnen. Auch die gute Nachricht.
Der Wortlaut steht in zwei reinen Funktionen (bewerbungText,
antwortText), exportiert, damit eine Pruefung sie lesen kann, ohne
einen Push-Dienst nachzubauen. Genau an so einer Stelle steckte am
18.09. der Fehler "Nachricht von [object Object]", der von aussen
nicht messbar war.
EINE STELLE FUER BEIDE WEGE
---------------------------
workspace-bewerbung-melden.js. Zwei Fassungen waeren zwei
Gelegenheiten, dass eine davon die Ruhezeit, die Abschaltbarkeit oder
die Haeusertrennung vergisst -- und dieselbe Person laese zweimal
etwas Verschiedenes ueber denselben Vorgang.
Die Meldung wird NICHT abgewartet (`void`): Ob sie durchgeht, haengt
am Push-Dienst, an der Ruhezeit und an den Einstellungen des
Empfaengers. Nichts davon darf entscheiden, ob die Bewerbung
gespeichert ist -- die ist es laengst.
NOCH EINE ROTE PRUEFUNG, DIE NIEMAND GESEHEN HAT
-------------------------------------------------
pruef-push-ziel meldete: "aber nicht auf eine Seite, die es fuer ihn
nicht gibt (/workspace/calls.html)". Das sah aus wie ein Befund und
war eine erfuellte Bestellung -- Filipe hatte am 22.09. genau das
Gegenteil bestellt ("jeder der einen kalender hat soll auch sowas
haben"). Nachgemessen: Modi, rechte und linke Hand haben je eine
Calls-Kachel.
Die Pruefung steht jetzt andersherum: Die Calls-Seite MUSS stehen
bleiben. Dieselbe Zeile schuetzt damit das, was sie vorher verboten
hat -- und wird rot, wenn die Kachel je wieder verschwindet. Das
Umlenken selbst bleibt geprueft (Scouting, zweimal).
Das ist die DRITTE stille rote Pruefung an einem Tag (nach
pruef-modi-wortleck und pruef-zuteilung). Die Frage an Filipe, ob ein
naechtlicher Lauf sie selbst anstossen soll, steht in der Vault-Notiz
und wird nicht von mir allein entschieden.
GEPRUEFT
--------
pruef-modi-katalog: 116 Pruefungen, 0 Fehler (vorher 95).
Neu: die beiden Schalter, wer es erfaehrt (samt Gegenprobe, dass es
nicht einfach alle sind: 2 von 6), und der Wortlaut an acht Proben.
Dabei war meine eigene erste Messung falsch -- sie erwartete eine
Kuerzung bei 50 Zeichen, die nur gilt, wenn eine Notiz danebensteht.
Steht als Begruendung in der Pruefung.
pruef-push-ziel: 11 von 11 (vorher 1 Fehler).
pruef-zuteilung, pruef-push, pruef-push-weg: gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6862bba437 |
pruef-zuteilung stuerzte ab -- an einer Entscheidung vom 22.09.
Beim Nachsehen im Umfeld des Vorlagenbretts gefunden: Die Pruefung
lief gar nicht mehr durch. Sie wartete dreissig Sekunden auf
"#neu-oeffnen" und brach dann ab -- und pruefte damit auch alles
danach nicht mehr.
Der Knopf ist nicht kaputt, er ist WEG -- und zwar auf Ansage:
Filipe, 22.09.2026: "dieser button kann da jetzt doch endlich
verschwinden, auf dieser seite sollen ja keine aufgaben mehr
verteilt werden."
Verteilt wird seither auf der Entwicklungsseite. Die Pruefung ist mit
umgezogen und misst dort dasselbe wie vorher: Stehen Leute zur
Auswahl, und erscheint die Frage "wie soll das laufen" erst, wenn es
wirklich mehrere sind? (4 zur Wahl, vorher verborgen, danach sichtbar.)
DAS IST DIE DRITTE SORTE FEHLER aus den Hausregeln -- kein
uebersprungener Test und kein gruener, der das Falsche prueft, sondern
einer, der seine VORAUSSETZUNG verloren hat. Von aussen sah er aus wie
ein Befund am Programm; er war einer an der Pruefung.
UND DASS DER KNOPF DORT WEG BLEIBT, WIRD JETZT MITGEPRUEFT. Sonst
koennte er stillschweigend zurueckkommen, und Filipes Ansage waere
rueckgaengig, ohne dass es jemand merkt. Genau so entstehen die
Funktionen, von denen niemand weiss, wann sie wiedergekommen sind.
Beim Umbau lief ich selbst in die naechste Stufe desselben Fehlers:
Der erste Anlauf mass null Kaestchen und meldete vier rote Zeilen. Das
Formular startet zugeklappt, und die Liste wird erst beim Aufklappen
gebaut -- gemessen war also eine Seite, die niemand aufgemacht hatte.
Steht jetzt als Begruendung daneben.
pruef-zuteilung: 75 Pruefungen, 0 Fehler (vorher: Absturz nach 40).
Nichts davon ist ausgeliefert -- es aendert sich nur eine Pruefdatei,
die der Dienst gar nicht laedt.
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]>
|