main
21
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
5d9c8cd377 |
Haustrennung: kein Eintrag mehr aus dem anderen Haus
Filipe, 24.09.2026: "wenn ich bei der einen was mache soll nichts bei
der anderen passieren." -- und heute: "ja los".
GEMESSEN, BEVOR ETWAS ANGEFASST WURDE (jedes Brett x beide Adressen x
vier Rollen):
AGENTUR-Adresse DogFather 18 Bretter
Manager 6 Bretter
Creator 6 Bretter
Modi kommt nicht rein (401)
CREW-Adresse DogFather 18 Bretter
Modi 13 Bretter
Manager kommt nicht rein (401)
Creator kommt nicht rein (401)
Die Anmeldung war also dicht. Durch griff genau EINE Rolle: DogFather.
Er wohnt in beiden Haeusern, und die Riegel in sichtbarEintrag()
fragten nach der ROLLE, nicht nach der Adresse. Auf der Crew-Adresse
stand damit das Brett der Agentur samt Inhalt.
Nachgemessen ist der Durchgriff AELTER als der gestrige Eventkarten-
Umbau -- zweimal gemessen, mit und ohne ihn, gleiches Ergebnis.
RIEGEL 0 in sichtbarEintrag(): Wer auf einer Adresse angemeldet ist,
sieht nur Eintraege dieses Hauses. Er haengt den uebrigen Riegeln
UM, statt in jeden Ausgang geschrieben zu werden -- die Funktion hat
drei Rueckgabepunkte, und der naechste waere sonst wieder offen.
Nachher, dieselbe Messung: DogFather sieht auf der Agenturadresse nur
Agentur-Eintraege, auf der Crew-Adresse nur die des Rudels. Manager,
Creator und Modi unveraendert.
WAS DABEI SCHIEFGING UND WIE ES AUFFIEL
1. Die erste Fassung liess bei `haus IS NULL` den BEREICH entscheiden.
pruef-haus-trennung.mjs wurde sofort rot: "Lunas Live vom Montag"
verschwand von der Agenturadresse. `live`, `technik` und
`community` tragen BEIDES -- die Kacheln von Team Dogi und die
Creator-Akten. Eine Regel, die jedem Brett genau ein Haus zuweist,
kann das nicht. Jetzt bleibt ein Eintrag ohne Haus sichtbar: ein
Eintrag zu viel faellt auf, ein fehlender nicht.
2. Damit NULL kein Dauerloch ist: FUENF von ACHT Stellen, die
Eintraege anlegen, setzten `haus` gar nicht (workspace-video.js,
-content.js, -bewerbung.js, -treff.js, -vorlagen.js). Nachgetragen.
3. Und `person.haus` war dafuer der falsche Massstab: Legt DogFather
ueber die Agenturadresse ein Highlight an, gehoert es trotzdem dem
Rudel -- sonst sieht die Community es nie. pruef-treff.mjs hat das
gefunden (2 Fehler). Neu: hausFuerNeuenEintrag() -- bei den sieben
Brettern des Rudels entscheidet das BRETT, sonst die Adresse.
NEU: pruef-haus-luecke.mjs (12 Pruefungen). Sie sucht die
Einfuege-Stellen im Quelltext und wird rot, sobald eine neunte
dazukommt, die `haus` vergisst -- mit Gegenprobe, dass das Suchmuster
eine solche Stelle auch wirklich erkennt. Ein Kommentar daneben haette
es nicht verhindert; das steht so schon im Projektgedaechtnis.
NEBENBEI: In bereich.js stand seit gestern `|| "Agentur-Events"` als
Rueckfall fuer das Etikett der Vorschau. pruef-treff.mjs verbietet
das zu Recht -- wie ein Brett heisst, haengt am Haus, und der Server
sagt es. Der Rueckfall ist weg; fehlt die Angabe, steht lieber kein
Etikett da als ein falsches.
pruef-treff.mjs nachgezogen (85 -> 86 Pruefungen, nicht weniger): Die
Zusage "DogFather sieht den Beitrag" wird jetzt auf der Crew-Adresse
geprueft, mit Gegenprobe fuer die Agenturadresse.
GEPRUEFT, alle gruen:
pruef-haus-luecke 12 pruef-haus-trennung 100
pruef-crew-adresse 169 pruef-treff 86
pruef-eventkarte 77 pruef-agentur 62
pruef-haus-seiten 38 pruef-eintrag-bild 24
pruef-vorlagen 24 pruef-video, -content, -bewerbung,
-bereiche-lesend: in Ordnung
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
3e1e0810ba |
Agentur-Events: die Karte als Aushang, Aufgaben zum Abhaken
Filipe, mit einem Bildschirmfoto des Oktober-Events: "ich will das viel geiler viel perfekter. und auch wenn man die eintraegt und so soll viel mehr perfektioniert und uebersichtlicher sein." VORHER GEMESSEN (1280 px, eine einzige Eventkarte): Kartenhoehe 1196 px -- das Fenster ist 900 px davon Banner 638 px -- 53 %, ohne einen Buchstaben Titel steht bei 1482 px -- zweimal scrollen bis zum Namen Titelgroesse 15,36 px -- 1,4 px mehr als der Fliesstext Etikett 10,88 px -- unter der eigenen Grenze (11,5) Datum 3 x -- in drei Zeilen untereinander Knoepfe 4 x gleich -- "loeschen" wie "zur Aufgabe" NACHHER, dieselbe Messung: Karte 618 px, Buehne 203 px, Titel 75 px unter der Kartenkante und 24,8 px gross, Etikett 12 px, das Datum einmal, "loeschen" abgesetzt. DIE KARTE Das Banner ist nicht mehr ein Anhang ueber dem Titel, sondern die Buehne dahinter -- Hoehe gedeckelt, Titel darauf. Dazu die Frage, die bei einem Wettbewerb wirklich zaehlt und bisher nirgends beantwortet wurde: "noch 12 Tage", mit Zeitbalken. Ein Knopf "Banner ganz" holt das vollstaendige Bild zurueck, das beim Umbau sonst verloren gegangen waere -- bei Filipes Banner steht die Ansage IM Bild. DIE AUFGABEN Aus Fliesstext wird eine Liste, und jeder hakt fuer sich ab (neue Tabelle event_punkte, Schluessel aus dem Zeilentext). Umsortieren laesst den Haken, wo er ist; wird die Bedingung selbst umgeschrieben, faellt er -- beides nachgemessen. Die Leitung sieht, wer wie weit ist, eine Creatorin sieht diese Liste gar nicht erst. DAS FORMULAR Ein Feld je Zeile statt eines leeren Textfeldes. Im echten Event stand ".Jeden Tag Live gehen" neben ". 33k Diamanten erreichen" -- einmal mit Leerzeichen, einmal ohne. Das ist die zwangslaeufige Folge davon, dass die Aufzaehlungszeichen von Hand getippt werden; jetzt setzt sie das Formular. Dazu "Laeuft 14 Tage.", eine Warnung bei verdrehtem Zeitraum und eine Vorschau, die dieselbe Funktion benutzt wie die echte Karte. NEBENBEI GEFUNDEN UND BEHOBEN * Das Banner kam bei Creatorn mit 404 zurueck -- also an genau der Karte, die fuer sie gemacht ist. Die Regel "wer das Brett sieht, sieht das Bild" galt nur fuer die sieben Community-Bretter. Jetzt fragt der Bildweg dieselbe Regel wie das Brett (darfEintragSehen); die Gegenprobe zeigt, dass ein fremder Eintrag weiterhin 404 gibt. * Zwei Stellen setzten das Formular zurueck, die kuerzere liess Vorschau und Zeilen-Editor stehen -- beim naechsten "Neuer Eintrag" standen die Aufgaben des vorigen Events noch da. * Der Schriftgrund ragte auf dem Handy 6 px ueber die Karte (feste -20 px gegen 14 px Polsterung); jetzt an die Polsterung gekoppelt. GEPRUEFT pruef-eventkarte.mjs (neu): 77 Pruefungen, 0 Fehler -- mit Gegenproben zu jeder Zusage und einer Kontrastmessung am Bildpunkt auf einem weissen Banner (14,7:1; ohne den Schriftgrund 1,05:1). pruef-agentur.mjs auf die neuen Bausteine nachgezogen, Zahl unveraendert bei 62. pruef-eintrag-bild.mjs 24/0. OFFEN, NICHT AUS DIESEM UMBAU: Das Brett `agentur` ist auf der Crew-Adresse erreichbar. Zweimal gemessen, mit und ohne diese Aenderung -- gleiches Ergebnis. Gehoert zur Trennungsregel vom 24.09.2026 und wird getrennt entschieden. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ae2f12c67d |
"Fuer wen"-Reihe weg -- aber nur bei Team Dogi
Filipe, mit Bildschirmfoto der Leiste "FUER WEN · Alle 3 2 ·
Marina 1 · Diene 0": "brauchen wir nicht auf der aufgaben seite."
GETRENNT GEFUEHRT, wie seit dem 24.09. fuer jeden Umbau. Es ist
DIESELBE Reihe in beiden Haeusern, aber nicht dieselbe Aufgabe:
Team Dogi -> "Fuer wen", darin drei, vier Modis, die ohnehin
alle auf einem Schirm stehen. Ein Filter fuer eine
Liste, die kuerzer ist als er. WEG.
Spicy Media -> "Alle Creator" / "Deine Creator". Scouts und
Manager filtern damit durch ihre Creator, und das
sind deutlich mehr. BLEIBT.
Die Trennung ist eine einzige Zeile an `ich.haus` -- das kommt vom
Server. Eine Rollenliste im Browser waere die zweite Wahrheit und fuer
DogFather, der in beiden Haeusern arbeitet, sogar falsch.
Der Zweig fuer die dritte Beschriftung ist mit entfernt, nicht
stehengelassen: "Fuer wen" ist von nirgends mehr erreichbar, und ein
Zweig, den niemand erreicht, sieht beim Lesen aus wie ein Fall, den
es gibt -- beim naechsten Umbau pflegt ihn jemand mit.
BEWIESEN IN BEIDE RICHTUNGEN, sonst waere die Trennung eine
Behauptung:
* pruef-handy-teamdogi (neu, 3 Pruefungen, 244 -> 247): auf crew.
im echten Browser ist die Reihe weg -- MIT der Gegenprobe, dass
die Seite ueberhaupt steht (4 Knoepfe in der Schwester-Reihe).
"Reihe nicht da" waere sonst auch auf einer kaputten Seite wahr.
* pruef-aufgabenbrett (49, unveraendert): bei Spicy Media steht sie
weiterhin da, mit "Alle, Tili, Luna" und der Beschriftung "Alle
Creator".
ZWEI DINGE AM PRUEFWERKZEUG, die mich heute Zeit gekostet haben:
1. `probleme` wurde seit jeher gefuellt und NIE ausgegeben. Am Ende
stand "1 Befund" und sonst nichts -- wer das liest, weiss DASS
etwas ist, nicht WAS, und muss den ganzen Lauf noch einmal
anstossen. Die Befunde stehen jetzt unter der Zahl.
2. Der Anmeldeweg stand in der Schleife, und fuer die neue Messung
habe ich ihn abgeschrieben -- dabei eine aeltere Fassung erwischt,
ohne `isVisible()` und mit `click()` statt `check()`. Ergebnis:
30 Sekunden Zeitablauf an der Altersfrage, die es fuer DogFather
gar nicht gibt. Jetzt ein Helfer, den beide Aufrufer benutzen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e00a905ce8 |
Dopplung weg: "Bei dir klingelt nichts" stand zweimal auf einem Schirm
Der neue Kasten von heute Mittag hat die alte Tagesblick-Zeile nicht
ersetzt, sondern sich darueber gesetzt. Beide sagten dasselbe,
untereinander, auf derselben Seite.
GEFUNDEN HAT DAS NUR EIN BILDSCHIRMFOTO. Beide Teile waren fuer sich
gruen: pruef-glocke verlangte die Zeile, pruef-push-hinweis den
Kasten, und keine der beiden konnte sehen, dass die andere existiert.
Zahlen zeigen so etwas nie. Deshalb macht pruef-push-hinweis jetzt
bei jedem Lauf ein Foto -- und scrollt vorher hin, weil der erste
Versuch brav die Begruessungskachel zeigte und den Kasten gar nicht
im Bild hatte. Ein Beweisbild ohne das, was es beweisen soll, ist
schlimmer als keins: Man glaubt ja, hingesehen zu haben.
Entfernt wurde die aeltere der beiden (19.09.2026). Sie war gut
gebaut, server-seitig und nicht wegklickbar -- aber sie hat das
Problem nicht geloest: Am 03.10. nachgemessen hatten immer noch
12 von 20 kein Geraet, darunter die linke Hand und ein Modi. Sie SAGT
es und man kann nichts tun; sie fuehrt nur auf eine andere Seite. Der
neue Kasten hat einen Knopf und erklaert den iPhone-Fall, in dem
Web-Push ohne Home-Bildschirm gar nicht geht.
Entscheidung von Filipe am 03.10. Offen gesagt, was damit aufgegeben
ist: Wer "Nicht jetzt" tippt, bekommt keine zweite Erinnerung mehr.
Gegensicherung ist die Personenliste -- dort steht seit heute bei
jeder Person, die nichts bekommt, genau das.
pruef-glocke 36 -> 33, und die Zahl ist erklaert: 5 Pruefungen zur
alten Zeile entfernt, 2 neue dafuer. Die neuen pruefen das
GEGENTEIL von vorher -- dass die Zeile nicht unbemerkt
zurueckkommt -- mit der Zahl der geprueften Hinweise in der
Bedingung, damit eine leere Antwort der Schnittstelle nicht als
"steht nicht drin" durchgeht.
Die alte Gegenprobe ("mit angemeldetem Geraet ist der Hinweis weg")
ist ersatzlos entfallen, nicht aus Bequemlichkeit: Sie waere ab jetzt
IMMER gruen, egal was das Haus tut. Eine Pruefung, die nichts mehr
widerlegen kann, taeuscht nur Deckung vor. Was sie geprueft hat,
prueft pruef-push-hinweis am neuen Kasten, mit einer echten
Anmeldung.
OHNE_ZAHL in start.js bleibt als leere Liste stehen -- der naechste
Zustandshinweis braucht sie wieder, und als Liste ist sie die eine
Stelle dafuer.
Gegengemessen: pruef-tagesblick 23, pruef-start-ansicht 160,
pruef-push-hinweis 16 -- alle 0 Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
cc716a9c1c |
Startseite sagt einmalig Bescheid, wenn jemand nichts bekommt
Am 03.10.2026 nachgemessen: 20 aktive Personen, 8 mit einer Anmeldung. Zwoelf bekamen keine einzige Benachrichtigung -- darunter die linke Hand und ein Modi. Die heute frueh behobene Dringlichkeit hilft diesen zwoelf nichts: Ohne Anmeldung geht gar nichts hinaus. Belegt im neuen Sendeprotokoll, seit dem Deploy heute Mittag: 10 Chat-Meldungen zugestellt, 26 Versuche an "keine_geraete" gescheitert. Genau diese 26 sind der Grund. Keiner der zwoelf wusste es. Die Glocke sagt es nur dem, der sie anschaut -- und genau das hatten sie nie getan. Jetzt steht auf der Startseite eine ruhige Zeile mit zwei Knoepfen: Anschalten oder nicht jetzt. ABGELEITET AUS `lage()`, der Stelle, die es ohnehin weiss. Eine zweite Ableitung daneben waere die, die beim naechsten Umbau etwas anderes behauptet als die Glocke zwei Zentimeter weiter oben. NUR DORT, WO ES ETWAS ZU AENDERN GIBT. Bei "verboten" hilft kein Knopf (das muss man im Browser zuruecknehmen), bei "geht-nicht" erst recht nicht. Auf dem iPhone erklaert er stattdessen den Weg ueber den Home-Bildschirm -- ohne den gibt es dort gar kein Web-Push, und das weiss sonst niemand. NUR AUF DER STARTSEITE, obwohl glocke.js auf 39 Seiten laeuft: Die Seite stellt den Platz, das Skript fuellt ihn -- dasselbe Muster wie `#glocke-platz`. Auf jeder Seite waere er nach dem zweiten Mal Tapete. Ruhig, nicht alarmierend: Es ist kein Fehler, sondern eine Einstellung, die noch niemand getroffen hat. Rot waere hier falsch. pruef-push-hinweis.mjs (neu, 16 Pruefungen). Sie misst VIER Abwesenheiten und nur eine Anwesenheit, weil die Gefahr auf der anderen Seite liegt: weg nach "Nicht jetzt", weg geblieben nach dem Neuladen, nicht da auf anderen Seiten (mit der Gegenprobe, dass die Glocke dort sehr wohl steht -- sonst waere nur gemessen, dass das Skript gar nicht laeuft), und nicht da, wenn die Benachrichtigungen AN sind. Die letzte mit echter Anmeldung, die nachweislich in der Datenbank landet. Dabei gelernt, und es stand nicht im Code: `browser.newContext()` gibt ein Inkognito-Fenster, und Chrome unterstuetzt dort die Push-API nicht -- "deliberately no way to feature-detect this". Die Pruefung meldete zuerst den dritten Ausgang statt gruen, und weil sie die Browsermeldungen mitschreibt, stand die Ursache sofort da. Jetzt laeuft sie mit einem echten Profil. Gegengemessen, dass die zusaetzliche Zeile nichts verschiebt: pruef-glocke 36, pruef-start-ansicht 160, pruef-tagesblick 23, pruef-kachelraster 24, pruef-handy 189, pruef-breiten 23, pruef-lesbarkeit 14, pruef-ueberlappung (20 Breitenpaare) -- alle 0 Fehler. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
628b99943e |
Personenliste zeigt, wen eine Benachrichtigung ueberhaupt erreicht
Am 03.10.2026 am laufenden System nachgemessen: 20 aktive Personen, aber nur 8 mit einer Push-Anmeldung. Zwoelf bekommen keine einzige Benachrichtigung -- darunter ein Modi und die linke Hand. Das war fuer niemanden sichtbar. Die Glocke sagt es nur dem, der sie anschaut, und wer etwas Wichtiges schreibt, konnte nicht wissen, wen es erreicht. Die Dringlichkeit, die heute frueh behoben wurde, hilft diesen zwoelf gar nichts: Ohne Anmeldung geht nichts hinaus. Der Hinweis steht jetzt auf der Personenseite, also dort, wo ohnehin ueber Personen entschieden wird -- nicht auf einer eigenen Seite, die niemand aufruft. Aus DERSELBEN Abfrage wie alles andere; eine zweite waere eine zweite Gelegenheit, dass die Liste etwas anderes sagt als die Wirklichkeit. NUR BEIM FEHLEN, UND DAS IST ABSICHT. Stuende bei jeder Person eine Zeile, stuenden bei zwanzig Personen zwanzig Zeilen da, und die, auf die es ankommt, gingen darin unter -- eine Angabe, die immer kommt, wird nicht mehr gelesen. Schweigen heisst hier: erreichbar. Die Zeilen verschwinden eine nach der anderen, sobald jemand die Glocke anschaltet. Nicht bei gesperrten Personen: Dort ist es keine Luecke, sondern richtig so. pruef-personen-liste 33 -> 37, mit der Gegenprobe in beide Richtungen: Eine Person bekommt im Testbestand ein angemeldetes Geraet, und bei genau ihr darf der Hinweis NICHT stehen. Stuende er ueberall, waere "er steht da" wertlos. Gegengemessen, dass die zusaetzliche Zeile nichts verschiebt: pruef-personen-kachel 45, pruef-hand-personen 49, pruef-modi-verborgen 94, pruef-betreuung 18, pruef-scout-zuteilung (liest dieselbe Klasse .person__bezug) -- alle ohne Fehler. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
db8dd2fbea |
147 Zeichen je Zeile -- am Kontrast lag es nicht
Filipe: „nur die kacheln noch viel geiler. so dass ich die texte auch
besser erkenne."
NAHELIEGEND WAERE GEWESEN, die Farben aufzuhellen. Erst gemessen,
dann gebaut -- und die Vermutung war falsch:
Kontrast .s-karte__text 15,7 : 1 (noetig 4,5)
Kontrast aller zehn Textarten 7,5 bis 15,7 : 1
ZEICHEN JE ZEILE 147 (angenehm 45-75)
Am Kontrast lag es nicht; der ist ueberall ueppig. Es lag an der
ZEILENLAENGE. Auf 1280 px lief der Meldungstext ueber die ganze
Kartenbreite: 1120 px, knapp 150 Zeichen. Beim Zeilenwechsel findet
das Auge die naechste Zeile nicht mehr sicher -- man liest dieselbe
zweimal oder ueberspringt eine. Das ist der groesste Hebel beim
Lesen, und er kostet nichts.
GEAENDERT
Meldungstext 15,2 -> 17 px, max-width 72ch, Zeilenhoehe 1.6
Verlaufstext 14,4 -> 15,2 px, max-width 70ch
Kartenrand 16/18/15/22 -> 18/20/16/24 px
Trennlinie zwischen Meldung und Verlauf
147 -> 78 Zeichen je Zeile (PC), 39 auf dem Handy
`ch` UND NICHT PIXEL: `ch` ist die Breite der Null und waechst mit
der Schrift mit. Eine Angabe in Pixeln waere bei der naechsten
Schriftgroesse wieder falsch -- dieselbe Falle wie jede feste Zahl.
MEHR RAND, WEIL DIE SCHRIFT GEWACHSEN IST. Bei unveraendertem Rand
haette sie die Kante beruehrt, und die Karte waere voller gewirkt
statt lesbarer. Links bleibt es breiter: dort laeuft die
Leuchtschiene in der Farbe des Stands.
DIE TRENNLINIE kostet einen Pixel und beantwortet „wo hoert die
Meldung auf und wo faengt die Vorgeschichte an?". Vorher lief beides
ohne Zaesur ineinander.
EIN FEHLER IN MEINER EIGENEN MESSUNG -- und er haette Schaden
angerichtet
Die erste Fassung der Kontrastrechnung meldete fuer drei gut lesbare
Texte einen Kontrast von 1,04. Ich war nah dran, Farben zu
„reparieren", die in Ordnung sind.
Der Grund: `rgb()` zaehlt 0..255, `color(srgb …)` zaehlt 0..1 -- und
genau das liefert Chrome fuer jedes `color-mix()`. 0,77 als 0,77/255
gelesen ist fast Schwarz. Aufgefallen ist es nur, weil die Zahl
nicht zum Bildschirmfoto passte: Dort waren die Texte deutlich
lesbar.
DESHALB STEHT IN DER PRUEFUNG EINE GEGENPROBE IM BROWSER: Ein
absichtlich zu blasser Absatz wird eingehaengt und MUSS auffallen
(gemessen 1,23 : 1). Ohne sie waere „alle ueber 4,5" auch dann
gruen, wenn die Rechnung kaputt ist -- und genau das war sie.
GEPRUEFT -- pruef-support-bilder 56 -> 64 ok
9 Textarten in der Karte gemessen
der Meldungstext ist 16.96 px gross (mindestens 16)
und bricht nach etwa 78 Zeichen um (hoechstens 85, vorher 147)
der Verlaufstext: 15.2 px, etwa 75 Zeichen
jeder Text haelt die Kontrastschwelle (0 darunter)
— schwaechster 7.55 : 1
Gegenprobe: ein absichtlich blasser Text faellt auf (1.23 : 1)
auf 390 px ragt mit der groesseren Schrift nichts heraus (0 px)
und die Zeile bleibt lesbar lang (etwa 39 Zeichen)
Dazu gruen: pruef-css-klassen · pruef-fingermass.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
a1c2d49260 |
Drei Bilder konnte man schon -- nur sagte es niemand
Filipes Frage: „koennen die leute auch schon mehrere fotos schicken wenn die im support was melden wollen?" Technisch seit dem 02.10. (VanVans Meldung #11), und heute mehrfach am laufenden Server nachgemessen. Beim Nachsehen auf der SEITE stand aber: Knopf: „Bild anhängen" -- Einzahl Unterzeile: „häng ein Bild dran" -- Einzahl daneben: (nichts) Wer nicht zufaellig ein zweites Mal auf den Knopf tippt, schickt eines. Aus seiner Sicht waere VanVans Meldung ungeloest -- und er haette recht. EINE MOEGLICHKEIT, VON DER MAN NICHTS WEISS, GIBT ES NICHT. Das ist dieselbe Sorte wie ein Knopf, der eine Absage holt, nur andersherum: Dort verspricht die Oberflaeche zu viel, hier zu wenig. Beides kostet denselben Menschen dieselbe Zeit. GEAENDERT Knopf: „Bilder anhängen" Unterzeile: „häng Bilder dran" daneben: „bis zu 3 Bilder" -- bevor man etwas waehlt nach einem: „eins.png · 24 KB · noch 2 möglich" Die letzte Zeile ist die wichtigere von beiden: „eins.png · 24 KB" allein sagt nicht, dass ein zweites geht -- und genau an dieser Stelle hoert jemand auf. DIE ZAHL KOMMT VOM SERVER (`bilder_max`) und wird neu geschrieben, sobald sie da ist. Ohne das stuende beim ersten Laden der Vorgabewert dort -- heute zufaellig derselbe, morgen vielleicht nicht. Eine Zahl, die zufaellig stimmt, ist keine Auskunft. GEPRUEFT -- pruef-support-bilder 52 -> 56 ok der Knopf steht in der Mehrzahl („Bilder anhängen") und daneben steht, wie viele gehen („bis zu 3 Bilder") auch die Unterzeile sagt nicht mehr „ein Bild" und daneben steht, dass noch Platz ist („eins.png · 0 KB · noch 2 möglich") Dazu gruen: pruef-zeichen 7 · pruef-css-klassen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ae5b467e9a |
Der Supportverlauf: eine Zeitachse, eine Farbe je Runde
Filipe: „ich will diese komplette seite vom support viel
uebersichtlicher, profissioneller, jede runde soll auch immer eine
spezielle farbe haben und anders aufgestellt aufgeteilt sein damit
man einen viel besseren und krasseren ueberblick hat."
WAS VORHER DASTAND -- an einem Bild mit zwei Runden nachgesehen,
bevor eine Zeile angefasst wurde: vier Textzeilen untereinander,
alle in derselben Farbe. „RUNDE 1", Antwort, „Ging noch nicht · …",
„RUNDE 2". Bei fuenf Runden muss man die Runden ZAEHLEN, statt sie
zu sehen -- und wer spricht, stand nur als kleiner Name daneben.
VIER TEILE SIND NEU
1. EINE LEISTE OBEN. Ein Punkt je Runde, in ihrer Farbe, mit ihrer
Nummer -- und der Rand sagt, wie sie ausgegangen ist. Damit ist
„wie oft ging es schon hin und her?" eine Frage des Hinsehens.
Erst ab zwei Runden: bei einer waere sie ein Punkt neben nichts.
2. EINE ZEITACHSE statt einer Liste. Jede Runde haengt mit einem
Punkt an einer Linie in IHRER Farbe. Die Linie ist ein Rand an
der Runde selbst, nicht am Behaelter -- so traegt jede ihr
eigenes Stueck Achse.
3. ZWEI SPRECHRICHTUNGEN je Runde, als getrennte Kaesten:
„GEANTWORTET" in der Rundenfarbe, darunter „GING NOCH NICHT"
(Bernstein) oder „GEHT WIEDER" (gruen) oder „WARTET AUF
ANTWORT". Vorher standen beide Saetze als Absaetze untereinander
und sahen gleich aus; man musste lesen, um zu wissen, von wem
sie sind. Jetzt sagt es die Form.
4. DIE LETZTEN ZWEI OFFEN, aeltere hinter „3 fruehere Runden
zeigen". Die Leiste sagt ohnehin, wie viele es gab; im Wortlaut
braucht es nicht alle. Zwei und nicht eine: Die letzte sagt, wo
es steht, die vorletzte, woran es davor lag.
DIE FARBE WIRD GERECHNET, NICHT GEPFLEGT
`rundenTon(nr)` gibt 200 + ((nr-1) mod 4) * 32 Grad. Eine Liste mit
fuenf Farben waere die naheliegende Loesung und die falsche: Runde
sechs bekaeme keine. Diese Sorte Liste hat im Haus schon dreimal
etwas gekostet.
DER BEREICH IST ENG UND ABSICHTLICH: 200 bis 296 Grad, Blau ueber
Indigo nach Violett -- die Palette der Seite (babyblau mit lila) und
der Bereich, in dem KEINE Farbe nach „gut" oder „schlecht" aussieht.
Gruen und Bernstein sind fuer den AUSGANG reserviert; waere eine
Rundenfarbe rot, stuenden zwei Aussagen in einer Farbe.
AUGENSCHONEND: 52 % Saettigung, 64 % Helligkeit -- fuer alle Toene
gleich, und nur im CSS. Sonst waere Runde drei blasser als Runde
eins, und augenschonend ist das Gegenteil von zufaellig. Kein Neon,
kein Gluehen. Die Farbe ordnet Zeilen zu; sie schreit nicht.
UND DIE FARBE ALLEIN TRAEGT NICHTS: Die Nummer steht daneben, der
Ausgang in Worten. Fuer Vorleseprogramme gibt es statt elf Punkten
einen Satz.
EIN FUND UNTERWEGS: DIE MESSUNG MASS SEIT ZWEI TAGEN NICHTS
`mess-support-runde.mjs` schickte die Rueckmeldung noch als JSON.
Am 02.10. ist die Route auf den Kopf-Weg umgestellt worden
(`x-geht`, `x-text`); seither antwortete sie mit 400. Gemerkt hat es
niemand, weil diese Datei Bilder macht und keine Rueckgabewerte
prueft: Auf dem Bild stand danach EINE Runde statt vier, und das
sieht aus wie ein Ergebnis. Aufgefallen ist es erst, als die Bilder
vier Rundenfarben zeigen sollten.
Eine Messung, die nach einem Umbau stillschweigend etwas anderes
misst, ist schlimmer als keine -- man glaubt ihr. Sie meldet den
Fehlschlag jetzt mit Code und Text.
GEPRUEFT -- pruef-support-bilder 39 -> 52 ok
die Leiste zeigt jede Runde (5 Punkte) · mit ihrer Nummer
die ersten vier Runden haben vier verschiedene Farben (4)
und die fuenfte faengt die Reihe wieder von vorn an
Gegenprobe: sie sind nicht alle gleich (4 Farben)
auch die Rundennummern tragen ihre Farbe (2 von 2)
offen stehen die letzten zwei Runden (2)
und die aelteren sind einen Griff entfernt
jede Runde zeigt beide Seiten
aufgeklappt stehen alle da (5) · und wieder zu
auf 390 px ragt nichts heraus (0 px)
bei einer einzigen Runde gibt es keine Leiste (0)
Die Gegenprobe „sie sind nicht alle gleich" ist die wichtigste:
Waere `--ton` nicht angekommen, waeren alle Punkte grau -- und „vier
Punkte" waere gruen gewesen, ohne dass eine Farbe zu sehen ist.
Gemessen wird die ANGEZEIGTE Farbe, nicht die Zahl im Attribut.
Dazu gruen: pruef-support 104 · pruef-css-klassen · pruef-zeichen 7 ·
pruef-fingermass 5.
Eine Schriftgroesse musste nachgebessert werden: .7rem sind 11,2 px,
und unter 11,5 px faengt im Haus die Grenze an, ab der man
zusammenkneift.
NUR DAS AGENTURHAUS: Die Supportseite liegt unter `/workspace`.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
ad5e758721 |
922 px auf einem 844-px-Bildschirm -- die halbe Antwort war zu wenig
VanVan im Support, Meldung #15: „Die Modis koennen die Antworten auf die Bewerbungen im Bereich eure Aufgaben noch nicht einklappen. Das wird mit der Zeit unuebersichtlich." Heute Nacht habe ich dazu „Verstanden" gebaut: Gelesenes rutscht hinter eine zugeklappte Zeile. Das ist richtig und war trotzdem nur die halbe Antwort -- denn UNGELESENE stehen absichtlich offen da, und davon hat ein Modi im Haus gerade neun. GEMESSEN STATT GESCHAETZT, an seinem echten Bestand nachgebaut, auf dem Handy (390 x 844 px): Band: 922 px -- hoeher als das ganze Fenster Anteil der Seite: 49 % Das IST ihr Satz. Mein Umbau loeste es erst NACH einem Griff auf „Alle verstanden"; bis dahin stand die Wand unveraendert da. GEAENDERT: Hoechstens drei stehen offen, der Rest ist einen Griff entfernt („und 6 weitere"). Danach: Band: 566 px -- passt in den Bildschirm nach einem Griff: 46 px (zugeklappte Zeile) WARUM NICHT NULL: Eine Absage, die man aufklappen muss, ist keine Nachricht mehr -- das war die Begruendung vom 30.09., und sie gilt. WARUM NICHT ALLE: siehe oben. Drei ist die Zahl, bei der Kopf, Zeilen und Sammelknopf unter einem Bildschirm bleiben. DIE NEUESTEN ZUERST -- der Server sortiert nach `entschieden_am DESC`. Wer nicht aufklappt, hat die juengsten gesehen. GEPRUEFT -- pruef-bewerbung-aufgaben 178 -> 184 ok mit fuenf Ungelesenen stehen drei offen (3) und der Rest ist einen Griff entfernt („und 3 weitere") das Band passt in den Bildschirm (436 px bei 1000 px) aufgeklappt stehen alle da (6, „Weniger zeigen") und wieder zu — der Knopf geht in beide Richtungen und die Probezeilen sind wieder weg — der Stand ist wie vorher Die dritte Zeile ist die eigentliche Aussage: „drei Zeilen" waere eine Zahl, „passt in den Bildschirm" ist der Zweck. Die letzte raeumt die vier Probezeilen wieder weg -- ohne sie zaehlten die Pruefungen darunter („1 aeltere Antwort", „2 aeltere Antworten") sechs statt zwei und wuerden rot, ohne dass etwas kaputt ist. Der Knopf geht in BEIDE Richtungen, und auch das steht da: Sonst waere er ein Einwegschalter, und das faellt erst auf, wenn jemand zurueckklappen will. AUSSERDEM AN CASPERLINOS ECHTEN NEUN GEMESSEN (Kopie der Datenbank, eigener Port, nichts im Live-System): neun Antworten, alle ungelesen; „Verstanden" nimmt genau eine; „Alle verstanden" den Rest; nachlesbar bleiben alle neun; ein zweiter Druck zaehlt null; eine fremde Nummer gibt 404. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ef911691b7 |
Der zweite Weg ist weg -- nicht nur sein Knopf
VanVan im Support, Meldung #8: „Wenn man auf ich fange an drueckt steht dort in Bearbeitung und wenn man auf fertig drueckt dann wird es zu erledigt. DIE AUFGABE BLEIBT ABER IM STATUS OFFEN STEHEN." GESTERN HABE ICH DIE HALBE ARBEIT GEMACHT und daneben eine Ausrede geschrieben. Die zwei Knoepfe kamen weg, und in den Kommentar kam: „Der Weg `/mein-stand` bleibt bestehen -- er ist die Schranke, falls ihn jemand direkt anspricht." Eine Route ist keine Schranke gegen sich selbst. Sie setzte weiterhin NUR `aufgaben_zuteilung.zustand` und liess `aufgaben.status` stehen -- also genau den Widerspruch, den VanVan beschrieben hat. Ich hatte ihn unsichtbar gemacht, nicht abgeschafft: kein Knopf mehr, das Verhalten unveraendert im System. GEFUNDEN BEIM NACHMESSEN AM LAUFENDEN SERVER, nicht beim Schreiben. Filipe hat auf den Screenshot gezeigt und gesagt, es sei noch nicht in Ordnung. Statt meine Pruefungen zu zitieren habe ich die Route gelesen -- und dort stand es. NACHGEMESSEN, BEVOR SIE WEGKAM: Kein einziger Aufruf mehr im ausgelieferten Browsercode (grep ueber alle JS- und HTML-Dateien des Workspace). Nur zwei Pruefungen benutzten sie. UND EINE DAVON NICKTE DEN FEHLER AB. In pruef-zuteilung stand: Bea setzt "in Bearbeitung" (HTTP 200) und danach "erledigt" (HTTP 200) Zwei gruene Haken ueber genau dem Verhalten, das gemeldet wurde -- weil sie nur den Rueckgabewert ansahen und nie den Aufgabenstatus daneben. Eine Pruefung, die nur eine Haelfte misst, kann den Widerspruch gar nicht finden. Jetzt steht dort: Bea setzt "in Bearbeitung" (HTTP 200) und BEIDES steht auf "in Arbeit" (Aufgabe arbeit, Zuteilung arbeit) — das war VanVans Befund und danach "erledigt" (HTTP 200) und wieder beides (Aufgabe erledigt, Zuteilung erledigt) WAS JETZT GILT: `PATCH /workspace/api/aufgaben/:id` mit `{ status }`. Er setzt den Status UND zieht die Zuteilung mit (`zuteilungenNachStatus`), kennt dieselbe Sperre fuer dauerhafte Aufgaben und dieselbe Rechtepruefung. Eine Frage, eine Antwort. ENTFERNT STATT AUSKOMMENTIERT -- dieselbe Entscheidung wie bei `/vorlagen/hilfe` am 01.09.: Eine Route, die niemand mehr aufruft, wird beim naechsten Mal fuer lebenden Code gehalten und mitgepflegt. EIN SCHRECKMOMENT UNTERWEGS, der sich als Messfehler herausstellte: Nach der Umstellung meldete pruef-bewerbung-aufgaben eine 404 beim Abhaken -- also der Verdacht, dass eine ZUGETEILTE Aufgabe ueber den Statusweg gar nicht erreichbar ist und ich gerade etwas kaputt gemacht haette. Nachgemessen statt geglaubt: Die Aufgabe steht in ihrer Liste, der PATCH antwortet 200. Die rote Zeile war eine DRITTE Stelle, die ich beim Umstellen uebersehen hatte und die noch auf die alte Route zeigte. Zwei Minuten Messung statt einer Stunde Suche an der falschen Stelle. GEPRUEFT pruef-zuteilung ok, mit zwei neuen Zeilen, die BEIDE Zustaende messen den zweiten Weg (mein-stand) gibt es nicht mehr (404) pruef-bewerbung-aufgaben 178 ok pruef-struktur 102 ok, 414 -> 413 Routen pruef-aufgabenbrett · pruef-modi-katalog 159 · pruef-aufgaben-vorlagen 60 Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d70d00cedc |
Jede Sprachnachricht in einer Fassung, die JEDES Geraet abspielt
Miss im Support, Meldung #12 -- fuenf Runden seit dem 23.09.: „Bei mir laesst sich die Nachricht nicht abspielen." Zuletzt: „Jetzt laedt es die ganze Zeit." Bei allen anderen ging es. GEMESSEN, BEVOR GEBAUT WURDE · Alle sechs Sprachnachrichten im Haus sind audio/webm (Opus). · Miss' Geraet: iPhone, iOS 18.7, WebKit. · Seit der Umstellung am 02.10. (neue Aufnahmen bevorzugen MP4) wurde KEINE EINZIGE neue aufgenommen. Ihr Problem betrifft also ausschliesslich die sechs alten Dateien -- und jede kuenftige aus einem Firefox, der nichts anderes kann. WAS ICH NICHT MESSEN KONNTE, und das gehoert dazu: Ob WebKit WebM/Opus abspielen kann, laesst sich auf diesem Rechner nicht nachsehen -- Playwrights WebKit startet hier nicht (libegl.dll fehlt). Die Vermutung „iPhones koennen kein WebM" ist begruendet, aber von mir nicht gemessen. GENAU DESHALB STELLT DIE LOESUNG DIE FRAGE NICHT. Statt zu raten, welches Geraet welchen Behaelter kann, legt der Server neben jede Sprachnachricht eine zweite Fassung in dem Format, bei dem sich seit zwanzig Jahren alle einig sind: AAC in MP4. Gibt es sie, wird sie abgespielt -- bei jedem, nicht nur auf iPhones. Kein Geraetename im Code, keine Liste, die altert. helfer-ffmpeg.mjs ffmpeg finden, umwandeln, drei Ausgaenge beim Hochladen nebenher, nicht davor: Die Nachricht wartet nicht auf ffmpeg toeneNachruesten() das Netz darunter -- fuer die sechs von frueher und fuer den Fall, dass eine Umwandlung einmal nicht geklappt hat ?form=mp4 dieselbe Route, dieselben Rechte; eine zweite haette dieselbe Sichtbarkeitspruefung ein zweites Mal gebraucht ffmpeg IST ABGESPROCHEN INSTALLIERT (Debian 7.1.5, auf Nachfrage freigegeben). Fehlt es, passiert nichts Schlimmes: Die Sprachnachricht geht wie bisher im Originalformat hinaus, und es steht EINMAL eine Zeile im Protokoll -- nicht bei jedem Hochladen. DREI ENTSCHEIDUNGEN, DIE NICHT NAHELIEGEND WAREN 1. `-movflags +faststart` IST NICHT KOSMETIK. Ohne es steht die Inhaltsuebersicht einer MP4 am ENDE. Das Abspielgeraet muss dann erst bis ans Ende lesen, bevor es anfangen kann -- genau das „laedt die ganze Zeit" aus Miss' Runde 5. Geprueft wird die Reihenfolge der Kaesten in der Datei, nicht die Zeile im Aufruf. 2. DAS ORIGINAL BLEIBT LIEGEN. Ohne `?form=mp4` kommt weiter die WebM. Sie ist das, was aufgenommen wurde; sie durch eine Umrechnung zu ersetzen hiesse, das Original wegzuwerfen. 3. EIN GEMEINSAMER LOESCHER. Zwei Stellen entfernen Anhaenge (Gespraech wegraeumen, Nachricht zuruecknehmen). Beide nahmen genau eine Datei -- ab heute waere bei jeder geloeschten Sprachnachricht eine m4a liegengeblieben, ohne Zeile, die auf sie zeigt. Dieselbe Luecke hatte ich gestern bei den Supportbildern gefunden; hier steht sie von Anfang an an EINER Stelle. ZWEI FUNDE DER PRUEFUNG, BEIDE MEINE EIGENEN · `anhang_datei` STAND NICHT IN DER ABFRAGE der Nachrichtenliste. Die Funktion, die auf der Platte nachsieht, bekam deshalb nichts und sagte brav „gibt es keine zweite Fassung" -- fuer JEDE Nachricht. Alles war gebaut, nichts kam an. Gefunden hat das die Pruefung, nicht das Lesen. · Mein erster Anlauf mass die Aufnahme ueber den Knopf -- und die ist seit dem 02.10. schon MP4, braucht also gar keine zweite Fassung. Die Pruefung wurde rot und hatte recht: Gemessen werden muss der Fall, den es bei Miss gibt. Jetzt nimmt sie ausdruecklich eine WebM auf. Dazu zweimal derselbe alte Tritt: ein Gegen-Apostroph in einem Kommentar INNERHALB eines Template-Literals. Der Server startet dann gar nicht. Steht jetzt als Warnung an beiden Stellen. GEPRUEFT -- pruef-chat-anhaenge 146 -> 163 ok Eine echte WebM/Opus-Aufnahme (31 972 Bytes) wird hochgeladen; die zweite Fassung entsteht von selbst und kommt als audio/mp4 heraus, mit „ftyp"-Marke, mit Accept-Ranges. ffprobe sagt: Original Opus, Zweitfassung AAC, 2,40 s gegen 2,46 s. Die Inhaltsuebersicht steht bei Byte 32, die Tondaten ab 1270 -- also vorne. Beim Loeschen gehen beide Dateien. Gegenproben: ein Bild bekommt keine zweite Fassung; eine halbierte Laenge waere aufgefallen; das Original bleibt unter seiner eigenen Adresse abrufbar. Der dritte Ausgang hat einen eigenen Zaehler: Fehlt ffmpeg, steht „KONNTE NICHT NACHSEHEN" mit Anleitung da -- nicht gruen und nicht rot. Und der Block raeumt hinter sich auf: Mein Probebild liess eine spaetere Pruefung rot werden, weil es die Gespraechsliste veraendert hatte. Eine Pruefung, die den Stand fuer die naechste verschiebt, ist schlimmer als keine. Dazu gruen: pruef-struktur 102 (92 Module) · pruef-ports 10 · pruef-gifs 17 · pruef-treffchat 114 · pruef-chat-optik · pruef-aufbewahrung 45. NUR DAS AGENTURHAUS? NEIN -- der Chat gehoert beiden Haeusern, und die Aenderung gilt fuer beide gleich. Sie aendert nichts an Sichtbarkeit oder Rechten: Wer eine Nachricht hoeren darf, hoert sie jetzt in einem Format, das sein Geraet kann. OFFEN BLEIBT DIE ANTWORT VON MISS. Ob es bei ihr jetzt laeuft, weiss nur sie -- deshalb steht ihre Meldung weiter offen und nicht auf erledigt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
1ce2c3785e |
Der Hinweis an der Anmeldung sagte seit dem 01.10. das Gegenteil
VanVan im Support, Meldung #5, zweite Runde: „Man kann sich jetzt nur noch über die richtige Schaltfläche anmelden. Das funktioniert jetzt. Aber wenn man sich 2x versucht über den falschen Button anzumelden, dann kommt ein irreführender Text wo steht, dass die Auswahl oben nicht schuld ist." SIE HAT RECHT -- UND DER GRUND IST MEINE EIGENE AENDERUNG Auf der Crew-Wand stand ab dem zweiten Fehlversuch: „Zugangscode stimmt nicht. Achte auf die Bindestriche -- die Auswahl oben ist nicht schuld." Das war am 20.09.2026 richtig. Dort gab es den STILLEN ZUGANG: Die rechte Hand und die Modis kamen ueber die Codekennung herein, egal welche Kachel sie antippten. Der Satz „Stimmt die Auswahl oben?" haette sie in eine Schleife geschickt -- alle Kacheln durchprobieren, acht Fehlversuche, Adresse gesperrt. Ein Hinweis, der die Sperre herbeifuehrt, gegen die er helfen soll. Mit VanVans ERSTER Runde derselben Meldung ist der stille Zugang weggefallen („es soll fest sein"). Nachgemessen in workspace.js: Die Kandidaten kommen seither aus `WHERE rolle = ?`, auf beiden Waenden. Die Kachel entscheidet ueberall -- und der Satz sagte ab diesem Tag das Gegenteil der Wahrheit, genau an der Stelle, an der jemand feststeckt. DAS IST DIE SORTE FEHLER, DIE EIN UMBAU HINTERLAESST: Nicht der neue Code war falsch, sondern ein Satz drei Dateien weiter, dessen Voraussetzung er entfernt hat. Er stand sogar ausfuehrlich begruendet da -- und die Begruendung las sich beim Umbau wie eine Bestaetigung, weil sie von einem Zustand sprach, den es nicht mehr gab. Gefunden hat ihn kein Prueflauf, sondern VanVan beim Benutzen. GEAENDERT: Ein Satz fuer beide Waende. Die Fallunterscheidung nach Wand ist weg -- es gibt nur noch eine Regel, also auch nur noch eine Auskunft. Der Hinweis auf die Bindestriche bleibt; er galt nie nur fuer eine Wand. „Zugangscode stimmt nicht. Stimmt die Auswahl oben? Ein Code gehört immer zu genau einer davon – und achte auf die Bindestriche." GEPRUEFT -- pruef-modi-verborgen 87 -> 94 ok Im echten Browser, beide Waende (crew-index.html und index.html), je zweimal mit einem falschen Code: · die Waende sind wirklich verschieden (gate--crew true/false) · „nicht schuld" steht nirgends mehr · stattdessen die Frage nach der Auswahl -- die dort seit dem 01.10. wirklich gilt (Abschnitt 1 derselben Datei misst das) · derselbe Satz auf beiden Waenden · Gegenprobe: nach dem ERSTEN Versuch steht er noch nicht da, dort steht die kurze Absage. Ein Hinweis, der immer kommt, waere keiner. DIE VERSUCHSSPERRE WIRD VOR DER MESSUNG GELEERT. Acht Fehlversuche je Adresse in zehn Minuten -- die Abschnitte davor verbrauchen welche, und ab dem neunten stuende „Zu viele Versuche" statt des Satzes. Das waere ein roter Haken ueber die Messumgebung gewesen, nicht ueber das Programm. Dazu: pruef-struktur 102 ok. BEIDE HAEUSER BETROFFEN, und das ist hier richtig: Es ist dieselbe Anmeldung mit derselben Regel. Nachgewiesen wird genau das -- der Satz ist auf beiden Waenden derselbe, und er stimmt auf beiden. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
f2f11e8091 |
Gelesene Antworten rutschen zur Seite -- statt sich zu stapeln
VanVan im Support, Meldung #15: „Die Modis können die Antworten auf die Bewerbungen im Bereich eure Aufgaben noch nicht einklappen. Das wird mit der Zeit unübersichtlich." WARUM ES NICHT EINFACH EIN SCHALTER GEWORDEN IST Am 30.09. habe ich diesen Kasten absichtlich NICHT einklappbar gebaut, und die Begruendung steht woertlich im Quelltext: „Eine Antwort, die man erst aufklappen muss, ist wieder keine." Sie ist richtig -- fuer eine Antwort, die man noch nicht gelesen hat. Danach ist sie falsch herum, und genau das meldet VanVan. Ein Schalter, der alles wegklappt, haette die naechste Absage mitversteckt: die Zeile, derentwegen der Kasten ueberhaupt entstanden ist. Deshalb nicht „einklappbar", sondern GELESEN: · Was noch niemand quittiert hat, steht offen da -- wie bisher. · „Verstanden" schiebt eine Zeile hinter „N ältere Antworten", zugeklappt, jederzeit wieder aufzumachen. Nichts wird geloescht; eine Absage samt Begruendung wegzuwerfen, weil jemand sie einmal gelesen hat, waere das Gegenteil des Umbaus vom 30.09. · Ab zwei offenen Antworten gibt es „Alle N verstanden" -- wer nach dem Urlaub sieben vorfindet, soll nicht siebenmal tippen, und sieben Anfragen waeren sieben Gelegenheiten, dass eine verloren geht. AM MENSCHEN, NICHT AM GERAET `gesehen_am` steht in `vorlagen_bewerbungen`, nicht im Browserspeicher. „Habe ich das gelesen?" ist eine Frage ueber die Person: Sonst waere dieselbe Antwort auf dem Handy wieder neu, nachdem man sie am Rechner gelesen hat -- und das waere genau die Unuebersichtlichkeit, die gemeldet wurde, nur eine Tuer weiter. Das AUFKLAPPEN der aelteren bleibt dagegen im Augenblick: kein Zustand, den man mitschleppt. Nach dem Neuladen ist wieder zu. GEGEN FREMDE ZEILEN GESCHUETZT: Nur die eigenen, nur die beantworteten, 404 statt 403 -- wie ueberall im Haus. Ein zweites „Verstanden" zaehlt nicht noch einmal, sonst wanderte die Zeile bei jedem Klick ans Ende und man saehe nicht mehr, wann man sie wirklich gelesen hat. WAS ICH FALSCH ERWARTET HATTE: Meine erste Pruefung verlangte, dass nach einem „Verstanden" OBEN NICHTS mehr steht. Sie wurde rot -- Frida hatte zwei Antworten, und der Knopf gilt je Zeile. Die Pruefung hatte recht; dass er nur seine eigene Zeile nimmt, ist das gewollte Verhalten und steht jetzt als Aussage dort. NEBENBEI: Ein 11,2-px-Pfeil (gemeldet von pruef-css-klassen). Unter 11,5 px faengt im Haus die Grenze an, ab der man zusammenkneift -- dass es „nur ein Zeichen" ist, aendert daran nichts. GEPRUEFT pruef-bewerbung-aufgaben 164 -> 178 ok Im echten Browser, am Handy (390 px): die ungelesene Antwort steht offen mit „Verstanden", danach ist genau diese eine Zeile weg (2 -> 1), sie liegt hinter „1 ältere Antwort", zugeklappt wird sie gar nicht erst gebaut, aufgeklappt steht sie samt Begruendung wieder da, „Alle verstanden" raeumt den Rest, nach dem Neuladen gilt beides weiter als gelesen und ist wieder zu. Am Server: fremde Antwort 404, erfundene Nummer 404, zweites „Verstanden" zaehlt 0. pruef-struktur 102 ok, 414 Routen (eine neue) · pruef-css-klassen · pruef-zeichen 7 · pruef-modi-katalog 150 · pruef-vorlagen 24 · pruef-aufgaben-vorlagen 60 NUR DAS AGENTURHAUS. „Eure Aufgaben" liegt unter `/workspace`; am Crew-Haus aendert sich keine Zeile. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
018d02c3b8 |
Vorlagen anpassen: Frist, dauerhaft und eine Anmerkung
VanVan im Support, Meldung #6, zweite Haelfte -- der Rest, der heute frueh ausdruecklich offen stehen blieb: „Bei den Vorlagen laesst sich weder die Frist anpassen noch ‚dauerhaft' einstellen, und eine Anmerkung fehlt auch." EIN ZWEITER KNOPF, NICHT EIN FENSTER FUER ALLE „An alle" verteilt zwoelf Aufgaben mit einem Druck. Haette jedes Uebernehmen jetzt ein Fenster geoeffnet, waere der haeufige Weg langsamer geworden, um den seltenen moeglich zu machen. Neben „Uebernehmen" steht deshalb „Anpassen …" -- an den Creator-Vorlagen und am Katalog, aus derselben Funktion. DAS FENSTER IST DAS DES HAUSES `frageNach` kann seit heute ein DATUM und einen HAKEN, die Anmerkung konnte es als `grund` schon. Ein eigener kleiner Dialog in vorlagenbrett.js waere der zweite im Haus gewesen -- und der, in dem beim naechsten Mal Esc, Fokusfalle oder der Abbruch fehlen. Beide Felder sind standardmaessig aus; fuer die dreissig anderen Aufrufe aendert sich nichts. DREI ENTSCHEIDUNGEN, DIE NICHT NAHELIEGEND WAREN 1. DIE ANMERKUNG WIRD EINE NOTIZ (`aufgaben_notizen`), kein Anhang an der Beschreibung. Sie traegt damit, von wem sie stammt, und die Aufgabe zeigt sie ohnehin an. In die Beschreibung geschrieben waere sie von der Vorlage nicht mehr zu unterscheiden -- und dieselbe Vorlage haette beim naechsten Mal einen anderen Text. 2. EINE DAUERHAFTE AUFGABE BEKOMMT KEINE FRIST, auch wenn eine mitgeschickt wird. Sie waere ab dem naechsten Tag fuer immer ueberfaellig, und eine Warnung, die immer kommt, ist keine mehr. Dieselbe Regel steht seit Langem im Aenderungsweg; haette sie hier gefehlt, gaebe es zwei Antworten auf dieselbe Frage. Im Fenster wird das Datum deshalb GRAU, sobald der Haken sitzt -- ein Datum, das dasteht und nicht gilt, ist schlimmer als keins. 3. „DAUERHAFT" DARF NUR, WER VERTEILEN DARF. Eine dauerhafte Aufgabe laesst sich nicht abhaken (Commit von heute frueh); wer sie sich selbst anlegen koennte, haette etwas, das er nie wieder loswird. Der Haken fehlt deshalb im Fenster eines Creators -- und abgelehnt wird trotzdem am Server, nicht nur ausgeblendet. EIN FUND, DEN DIE PRUEFUNG GEMACHT HAT `Number(tage) || 7` -- die Untergrenze des Datumsfeldes lag dadurch sieben Tage in der Zukunft statt heute, weil Null in JavaScript unwahr ist. Die VORGABE („in 1 Tag") lag damit UNTER der erlaubten Grenze: Wer das Fenster oeffnete und einfach „Uebernehmen" drueckte, bekam eine Absage. `Number.isFinite` fragt, ob eine Zahl da ist, und nicht, ob sie wahr ist -- derselbe Unterschied wie bei `kill -0`. NEBENBEI BEHOBEN: Ein gerades Anfuehrungszeichen in einem deutschen Fehlersatz (gemeldet von pruef-struktur). GEPRUEFT pruef-aufgaben-vorlagen 46 -> 60 ok eigene Frist kommt an (und die Vorlage saehe 5 Tage vor -- die Angabe hat also wirklich gewirkt), Anmerkung wird woertlich zur Notiz mit Namen, ohne Angabe bleibt alles wie bisher, Scout 403 und es entsteht auch nichts, DogFather 200 und KEINE Frist, „morgen" 400, der 45.13. 400, Vergangenheit 400, und als Gegenprobe dieselbe Vorlage ohne Frist 200. Im Browser: der Knopf, das Fenster, die Vorgabe, kein Haken fuer einen Creator, die Aufgabe traegt danach genau die eingetragene Frist samt Notiz -- und Abbrechen legt nichts an. pruef-nachfrage 74 -> 89 ok Datum mit Vorgabe und Untergrenze, Haken 44 px hoch mit 22-px- Kaestchen (nicht ueber die ganze Zeile), Sperre und Gegenprobe, beide Schranken fuer ein zu fruehes Datum einzeln. pruef-struktur 102 · pruef-css-klassen · pruef-modi-katalog 150 · pruef-aufgabenbrett · pruef-vorlagen 24 · pruef-bewerbung-aufgaben 164 · pruef-zuteilung NUR DAS AGENTURHAUS. Vorlagenbrett und Aufgaben liegen unter `/workspace`; am Crew-Haus aendert sich keine Zeile. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b31bd9b515 |
Zwei bis drei Bilder je Supportmeldung -- und zwei Funde unterwegs
VanVan im Support, Meldung #11, VIERMAL gemeldet: „Hier im Supportbereich kann man immer nur ein Bild hinzufuegen bei einer Meldung. 2-3 waeren besser." Und in der zweiten Runde der Satz, auf den es ankommt: „wenn man es nacheinander versucht hinzuzufuegen wird das Bild immer nur ersetzt." EINE TABELLE STATT NEUER SPALTEN `support_bilder` haelt ab jetzt JEDES Supportbild -- das der Meldung (`runde_nr` NULL) und das einer Antwort (`runde_nr` = Runde). Die Alternative waere `bild2_datei`, `bild3_datei` gewesen, und beim vierten Bild wieder. Eine Zeile je Bild kennt keine Obergrenze im Schema; die Grenze steht an EINER Stelle im Code (`BILDER_MAX = 3`) und kommt von dort in die Oberflaeche, statt dort ein zweites Mal zu stehen. DIE ACHT VORHANDENEN BILDER WANDERN MIT. Ohne diesen Schritt haette die neue Tabelle ab heute recht und die alten Bilder waeren unsichtbar -- ohne Fehler, ohne rote Zeile, nur acht leere Karten. Der Umzug steht NACH der Spaltennachruestung: Er liest `urteil_bild_datei`, und die gibt es in einer bestehenden Datenbank erst, nachdem sie ergaenzt wurde. Stuende er davor, scheiterte er genau dort, wo es darauf ankommt -- live, waehrend lokal alles gruen bliebe, weil jede Pruefung ihre Datenbank frisch anlegt. DREI BILDER IN EINER ANFRAGE `x-bilder: 20481,15320` sagt, wo zu schneiden ist, der Rumpf ist die Aneinanderreihung. `multipart/form-data` haette einen Zerleger gebraucht, den dieses Haus nicht hat; drei Anfragen nacheinander haetten den Zustand „Meldung da, Bild zwei laedt noch" erzeugt -- genau den, gegen den die Kommentare an dieser Route schon vorher argumentieren. Die Summe muss auf das Byte stimmen, und jedes Stueck wird einzeln an seinen ersten Bytes erkannt: Wer falsch schneidet, bekommt eine Absage, kein verfaelschtes Bild. Ohne den Kopf gilt der ganze Rumpf als ein Bild -- derselbe Satz mit einer Laenge, damit eine Seite aus dem Zwischenspeicher weiterlaeuft. EINE ROUTE STATT DREI. `/:id/bild` und `/:id/runde/:nr/bild` sind weg; es gibt `/:id/bild/:bid`. Wohin ein Bild gehoert, steht in seiner Zeile -- der Weg muss es nicht wiederholen. Die Meldungsnummer bleibt trotzdem im Pfad: Sie ist die Sichtbarkeitsfrage, und beides muss zusammenpassen (gemessen). ZWEI FUNDE, DIE DIE PRUEFUNG GEMACHT HAT UND NICHT ICH 1. UEBER DIE SEITE KAM GAR KEIN BILD MEHR AN. Beim Melden stand kein `Content-Type`. Das ging gut, solange der Rumpf eine einzelne Datei war -- ein `File` bringt seinen Typ mit. Ein `Blob` aus mehreren hat keinen, `fetch` schickt die Zeile dann gar nicht, `express.raw` fuehlt sich nicht zustaendig, und der Server bekam einen leeren Rumpf. Die Meldung waere durchgegangen, der Text angekommen, die Bilder weg -- ohne Fehlermeldung. Alle Pruefungen am Server waren dabei gruen; gefunden hat es erst der echte Browser. 2. DAS KREUZ DES DRITTEN BILDES LAG AUF DEM ZWEITEN. Der Entfernen-Knopf ist 44 px breit und absolut gesetzt, der Kasten aber nur so breit wie sein Bild. Bei einem schmalen Bild ragt er darueber hinaus -- wer „das zweite weg" antippt, loescht das dritte. `min-width`/`min-height` loesen das an der Ursache: Ein Kasten ist nie schmaler als der Knopf in ihm. WAS ICH FALSCH ANGENOMMEN HATTE: Ich hatte eingebaut, dass ein Nachtrag in derselben Runde die Bilder ersetzt. Die Pruefung dazu wurde rot -- zu Recht: Eine zweite Antwort in derselben Runde kann es nicht geben, die erste verlaesst den Stand „wartet". Der Code waere nie gelaufen und damit nie pruefbar gewesen. Er ist weg; an seiner Stelle steht der Beweis, dass er nicht fehlt. DREI WEITERE ROTE ZEILEN, DIE NICHT ZU DIESEM UMBAU GEHOERTEN * `manager-ziele.js` hatte einen ZWEITEN Notnagel (`frageNach ? … : confirm(…)`). `nachfrage.js` hat denselben laengst, und zwar mit dem vollstaendigen Text; der hiesige war der kuerzere und haette gewonnen. Zwei Antworten auf dieselbe Frage -- gemeldet von `pruef-nachfrage`. * Zwei Mittelpunkte in `reaktion.css` standen woertlich im `content`. Sie liegen im Latin-1-Block, wo `pruef-zeichen` die Truemmer einer verunglueckten Kodierung sucht. Jetzt als Escape -- im Browser nachgemessen, es steht Zeichen fuer Zeichen dasselbe da. * Das Aufraeumen nach 90 Tagen loeschte nur das EINE Bild der Meldung; die Bilder aus den Antwortrunden blieben ohne Zeile auf der Platte liegen. Die Liste kommt jetzt aus einer Abfrage statt aus einer Spalte und kann deshalb nicht wieder unvollstaendig sein. GEPRUEFT pruef-support 78 -> 104 ok darunter: der Umzug der alten Bilder auf einer eigenen Wegwerf-Datenbank -- zweimal und dreimal gestartet, nichts verdoppelt, Datum von damals erhalten pruef-support-bilder NEU, 36 ok (echter Browser) dreimal nacheinander waehlen ergibt drei, das vierte wird mit einem Satz abgelehnt, dasselbe zaehlt nicht doppelt, einzeln entfernen laesst die anderen stehen, alle drei laden wirklich (naturalWidth), Kreuze 44x44 und keines verdeckt (mit Gegenprobe per Deckel), nichts ragt auf 390 px heraus pruef-nachfrage 69 -> 74 ok pruef-struktur 102 ok, 413 Routen (vorher 414: zwei weg, eine neu) pruef-zeichen 7 ok (vorher 1 Fehler) pruef-aufbewahrung 45 ok pruef-manager-ziele 216 ok pruef-ports 10 ok · pruef-portnummern 41 ok (die neue Pruefdatei verschiebt die abgeleiteten Nummern) NUR DAS AGENTURHAUS IST BETROFFEN. Die Supportseite liegt unter `/workspace`; am Crew-Haus aendert sich keine Zeile. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
3ab69d36a5 |
Eine dauerhafte Aufgabe wird nicht abgehakt -- auch nicht ueber den Status
VanVan im Support, Meldung #6: „Der Modi kann die dauerhafte Aufgabe immer noch auf erledigt setzen." DIE SPERRE GAB ES SEIT DEM 30.09. -- ABER NUR AN EINER TUER. `/mein-stand` lehnt „erledigt" bei einer dauerhaften Aufgabe seither ab. Der STATUSWEG (`PATCH /workspace/api/aufgaben/:id`) kannte `dauerhaft` ueberhaupt nicht. Wer die Aufgabe ohnehin aendern durfte -- etwa weil das Uebernehmen aus dem Pool ihn verantwortlich macht -- hakte sie damit einfach ab. Zwei Tueren, eine Regel, und die Regel hing nur an einer. UND ICH HABE DAS LOCH HEUTE FRUEH VERBREITERT. Mit dem Commit davor darf eine Modi den Status ihrer Aufgabe setzen (damit VanVans Satz „es gibt darüber ja den button starten" fuer sie ueberhaupt stimmt). Damit stand ihr genau der Weg offen, der ihr an der anderen Tuer ausdruecklich verwehrt ist. Gefunden habe ich es nicht beim Bauen, sondern beim Lesen der offenen Supportmeldungen -- ihr Satz stand seit dem 28.09. da und passte ploetzlich auf meine eigene Aenderung. GEAENDERT 1. Der Statusweg lehnt „erledigt" bei einer dauerhaften Aufgabe ab, wenn die Person nicht verteilen darf. DERSELBE Fehlercode wie in `/mein-stand` (`dauerhafte_aufgabe`) -- die Oberflaeche uebersetzt ihn schon, und ein zweiter Code fuer dieselbe Sache waere der, den beim naechsten Mal jemand uebersetzt und der andere nicht. 2. Der Knopf faellt weg, der die Absage holen wuerde (`darf_beenden` vom Server). Dieselbe Ueberlegung wie bei „Fertig" auf der Zuteilungskarte, die seit dem 30.09. daneben steht: Ein Knopf, der eine Absage holt, ist schlimmer als keiner. NUR DER LETZTE SCHRITT faellt weg. „starten" und „zur Freigabe" bleiben -- auch eine stehende Aufgabe hat einen Anfang, und der Unterschied zwischen „offen" und „in Arbeit" sagt etwas. 3. BEENDET WIRD SIE VON DER LEITUNG. Das stand seit dem 30.09. als Satz im Kommentar von `/mein-stand`; jetzt stimmt er auch. GEPRUEFT -- UND ZWAR BEIDE TUEREN, sonst wandert der Fehler nur: eine dauerhafte Aufgabe (#3) Tuer 1 (mein-stand) ist zu (409 dauerhafte_aufgabe) Tuer 2 (Status) jetzt auch (409 dauerhafte_aufgabe) anfangen darf sie trotzdem (200) und die Leitung beendet sie (200) und die Oberflaeche erfaehrt es (darf_beenden false) Die dritte Zeile ist die Gegenprobe gegen zu viel Sperre: „gesperrt" darf nicht heissen, dass gar nichts mehr geht. GEPRUEFT: pruef-zuteilung 90 -> 96 ok · pruef-bewerbung-aufgaben 164 · pruef-aufgabenbrett 49 · pruef-aufgaben-vorlagen 46 · pruef-struktur 102. WAS AUS DERSELBEN MELDUNG NOCH OFFEN IST (VanVan, #6): Bei den VORLAGEN laesst sich weder die Frist anpassen noch „dauerhaft" einstellen, und eine Anmerkung fehlt auch. Das ist ein eigener Umbau und steht hier nur, damit es nicht untergeht. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
baf8288433 |
Korrigieren duerfen jetzt beide: Spicy Media und DogFather
Filipe auf die Rueckfrage, wer fremde Eintraege richtigstellen darf: „ja spicy und dogfather". Die Vorlage kannte dort nur DogFather („Vergangene Monate sind gesperrt ... Ausnahme: DogFather"). Das gilt ab jetzt fuer beide -- und zwar fuer BEIDE Faelle, nicht nur fuer einen: * einen fremden Eintrag aendern oder loeschen * einen abgeschlossenen Monat dafuer kurz oeffnen ES IST EINE MENGE UND KEINE ZWEITE LISTE. `darfKorrigieren()` gibt `siehtAlles()` zurueck -- dieselbe Menge, die schon ueber die Team-Uebersicht und die Zielzahlen entscheidet. Eine eigene Aufzaehlung derselben zwei Rollen waere die, die beim naechsten Umbau auseinanderlaeuft. Und inhaltlich gehoert es zusammen: Wer alle Zahlen sieht und die Ziele setzt, muss einen Zahlendreher gerade ruecken koennen; zwei verschiedene Grenzen fuer „darf alles sehen" und „darf etwas richtigstellen" koennte spaeter niemand mehr erklaeren. Der Name der Variablen hiess vorher `istAdmin` -- also die Rechnung statt ihrer Bedeutung. Jetzt heisst sie, was sie beantwortet. NACHVOLLZIEHBAR BLEIBT ES UNVERAENDERT: Jede Korrektur an einem fremden Eintrag und jede Aenderung an einem abgeschlossenen Monat steht mit Name, Rolle und Zeit im Protokoll -- geprueft wird jetzt ausdruecklich, dass dort auch `spicy` auftaucht. GEPRUEFT: 206 Pruefungen, 0 Fehler (vorher 194) Die Grenze wird in beide Richtungen gemessen, nicht nur in eine: Spicy aendert wirklich (200, und der neue Wert steht in der Datenbank), Spicy loescht wirklich -- aber ein Manager und ein fremder Scout werden weiterhin abgewiesen (403), und danach steht immer noch der Wert von Spicy da. Ohne diese Gegenproben hiesse „Spicy darf" moeglicherweise „jeder darf". Loeschen ist eigens geprueft: PATCH und DELETE sind zwei Routen, und zwei Routen koennen auseinanderlaufen. Auch die Freigabe fuer alte Monate wird nach Spicys Korrektur wieder geschlossen gemessen -- eine geoeffnete Tuer ist kein Erfolg. EINE MEINER PRUEFUNGEN WAR WIEDER FALSCH, NICHT DER CODE: Ich hatte erwartet, dass ein Manager mit einer fremden Nummer in der Adresse „nicht bearbeitbar" bekommt. Er bekommt `true` -- weil er gar keine fremde Liste bekommt, sondern seine eigene; die Nummer wird fuer ihn schlicht nicht beachtet. Richtiges Verhalten, falsche Frage. Gemessen wird jetzt, was zaehlt: dass bei ihm kein einziger fremder Eintrag ankommt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b46f75484f |
Ein Klick statt eines Formulars -- der Schnell-Eintrag
Filipe mit dem Bildschirmfoto der Zeilen: „ich will das viel perfekter
und geiler. will dass es viel einfacher ist. am besten so wenig wie
moeglich zu tippen. fertige sachen, bereit um ab zu gehen."
GEZAEHLT, WAS EIN EINTRAG VORHER KOSTETE -- das war der Punkt:
Manager Meeting Knopf, Dialog, Speichern 2 Klicks + Fenster
Schulung dazu die Art waehlen 3 Klicks + Fenster
Werbung dazu den Link tippen 2 Klicks + tippen
Creator dazu den Namen tippen 2 Klicks + tippen
Ein Fenster fuer die Aussage „ich war heute im Meeting" sind drei
Handgriffe fuer null Angaben. Vier Aufgaben im Monat, acht Klicks,
acht Fenster.
JETZT
Manager Meeting EIN Klick („Heute eingetragen")
Schulung EIN Klick (zwei fertige Knoepfe)
Werbung Einfuegen + Eintragen, kein Tippen
Creator ein Klick je Lead -- oder mehrere Namen auf
einmal einwerfen
Am echten Bildschirm nachgemessen: 0/2 vorher, EIN Klick, 1/2 nachher,
„Rueckgaengig" bringt 0/2 zurueck. Nicht „der Knopf ist da", sondern
„danach steht eine andere Zahl dort".
DREI ENTSCHEIDUNGEN DAHINTER
1. DER WEG NIMMT EINE LISTE. „Drei Creator auf einmal" ist EIN
Vorgang. Wer drei Namen aus Discord kopiert, hat das Monatsziel in
einem Zug erledigt -- das ist der eigentliche Gewinn, nicht der
gesparte Klick.
JEDER EINTRAG WIRD EINZELN GEPRUEFT UND EINZELN BEANTWORTET. Die
ganze Liste zurueckzuweisen, weil ein Name schon dasteht, waere
die bequeme und die falsche Loesung: Dann weiss niemand, welcher
der drei das Problem war, und tippt alles noch einmal. Geprueft
wird genau dieser Fall -- zwei gehen durch, einer wird im Klartext
abgelehnt, mit Namen.
2. KEINE SICHERHEITSABFRAGE VORHER, SONDERN „RUECKGAENGIG" DANACH.
Eine Nachfrage bei jedem Klick waere der Handgriff, den wir gerade
abgeschafft haben, in neuer Verkleidung. Sie kostet jeden; das
Zuruecknehmen kostet nur den, der sich vertippt hat. Acht Sekunden
statt drei -- lang genug, um es mit einem Daumen zu treffen.
3. DIE ZULETZT GEWAEHLTE ART IST VORGEWAEHLT -- abgeleitet aus dem
letzten Eintrag, nicht in einer Einstellung gespeichert. Eine
Spalte „Lieblingsart" waere ein zweiter Bestand, der veralten
kann; der letzte Eintrag veraltet nie.
WAS MIR DABEI AUFGEFALLEN IST
Ein Ein-Klick-Knopf macht den Doppeltipper zur wahrscheinlichsten
Fehleingabe -- bei „Heute eingetragen" merkt man nichts davon, es gibt
ja keine Angabe. Zwei Meetings an einem Tag zu VERBIETEN waere aber
falsch, sie sind moeglich. Also ein Hinweis statt einer Sperre:
„Fuer diesen Tag stehen jetzt 2. War das Absicht?" -- und das
Zuruecknehmen liegt ohnehin daneben. Mit Gegenprobe, dass beim ERSTEN
keine Warnung kommt; sonst waere sie keine Warnung, sondern ein
Begleittext.
AUSSERDEM
* Die Zeilen bauen sich beim Eintragen nicht mehr neu, sondern
ziehen nur die Zahlen nach. Sonst verschwaende das Feld, in dem
man gerade tippt, unter der Hand.
* „Einfuegen" holt den Link aus der Zwischenablage -- mit drittem
Ausgang: Firefox gibt sie ohne Erweiterung nicht her, und dann
wird das gesagt, statt dass ein Knopf stumm bleibt.
* Im Dialog drei fertige Tage (Heute / Gestern / Vorgestern) statt
eines Kalenders. Was nicht mehr in diesen Monat gehoert, wird gar
nicht erst angeboten -- am 1. und 2. fallen welche weg.
* Der Dialog heisst jetzt „Mehr Angaben" und ist die Ausnahme fuer
Notiz oder altes Datum. Dass er fuer etwas Normales gebraucht
wurde, war sein Fehler.
GEPRUEFT: 194 Pruefungen, 0 Fehler (vorher 168)
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
f6d2437985 |
Manager-Ziele zu Ende gebaut -- und dabei zwei Loecher gefunden
Filipe: „perfektioniere alles jetzt sofort, es muss ready sein."
Die Vorlage Punkt fuer Punkt gegen das Gebaute gehalten, nicht gegen
meine eigene Liste von heute Mittag. Vier Punkte standen noch offen,
und auf dem Weg dorthin sind zwei Fehler aufgefallen, nach denen
niemand gesucht hat.
DIE ZWEI FEHLER ZUERST -- beide gefunden durch Messen, nicht Denken
1. EINE GELOESCHTE PERSON HAETTE IHRE ZAHLEN MITGENOMMEN.
`mz_eintrag.person_id` stand auf ON DELETE CASCADE. Die Vorlage
sagt aber: „Wer die Rolle verliert, sieht die Kachel nicht mehr;
die Daten bleiben fuer den DogFather erhalten." Mit CASCADE waere
genau das nicht wahr gewesen -- `DELETE FROM personen` haette den
Monatsverlauf eines Menschen lautlos mitgenommen.
Jetzt SET NULL, und Name und Rolle stehen zusaetzlich als Text am
Eintrag (dieselbe Bauweise wie bei support_meldungen). Die Rolle
ist nicht Zierde: Ohne sie wuerde ein abgeschlossener Monat
rueckwirkend an den Zielzahlen einer anderen Rolle gemessen.
Der Umbau laeuft auf dem Bestand von heute Mittag -- Spaltenliste
AUS PRAGMA abgeleitet, nicht gepflegt, und geprueft werden Zeilen
UND Spalten. Am 11.09.2026 hat genau so ein Umbau drei Spalten mit
Inhalt verloren, ohne Fehlermeldung, bei unveraenderter Zeilenzahl.
2. MEIN EIGENER SPERR-TRIGGER HAETTE DAS LOESCHEN BLOCKIERT.
ON DELETE SET NULL ist kein Loeschen, sondern ein UPDATE auf
person_id. Der Trigger sah eine Aenderung an einem abgeschlossenen
Monat und brach ab -- `DELETE FROM personen` waere damit
gescheitert, an einer Stelle, die mit Monatszielen nichts zu tun
hat. Erlaubt ist jetzt genau eine Aenderung an einem alten Monat:
dem Eintrag seinen Besitzer zu nehmen. Als BEDINGUNG und nicht als
`UPDATE OF <spaltenliste>` -- eine Liste muesste jemand pflegen.
Weil `CREATE TRIGGER IF NOT EXISTS` eine geaenderte Fassung nicht
erneuert, wird die alte am INHALT erkannt und ersetzt. Eine
Fassungsnummer muesste jemand hochzaehlen, und das wird vergessen.
DIE VIER OFFENEN PUNKTE DER VORLAGE
04 Jede Aufgabenzeile hat ihr eigenes Zeichen -- aus dem Haus
(`window.Bereiche`), nicht neu gezeichnet: Trichter, Bildschirm,
Buch, Rahmen. Das Statuszeichen bleibt daneben; ein eingefaerbtes
Aufgabenzeichen allein traegt die Stufe nicht.
05 „Farbiger Rand + Badge": Eine Kachel, an der eine Warnung haengt,
traegt jetzt einen feinen Saum -- JEDE Kachel, nicht nur diese.
Eine Regel, die nur an einer Stelle gilt, wird beim naechsten Mal
vergessen.
08 Die Team-Tabelle ist sortierbar: jede Spalte ein Knopf (kein
anklickbares <th> -- das erreicht die Tastatur nicht), mit
aria-sort, und sortiert wird nach ANTEIL statt nach nackter Zahl.
Dazu eine Ampel-Spalte mit Wort. Auf dem Handy verschwindet die
Kopfzeile im Kartenmodus, deshalb steht das Sortieren zusaetzlich
in der Leiste -- sonst waere es auf einem Telefon nicht
vorhanden.
09 Wer die Rolle verliert, steht weiter in der Uebersicht, als
„nicht mehr dabei" und mit der Rolle von damals. Wer geloescht
wurde, erscheint als zusammengefasste Zeile unter dem
mitgeschriebenen Namen.
WAS DER SAUM MICH GELEHRT HAT
Er stand zuerst in start.css und war wirkungslos -- der Browser
lieferte weiter den Faseschatten. Der Grund steht seit dem 25.09.2026
in module.css: `:is()` uebernimmt die Spezifitaet seines staerksten
Arguments, und `.gruppe[data-gruppe]` macht die ganze Modulliste
(0,2,0) -- genau so stark wie `.kachel[data-warn="ja"]`, bei
Gleichstand gewinnt die zuletzt geladene Datei. Dieselbe Falle wie
damals bei den Fokusringen, dieselbe Antwort: Was gegen die Modulform
gewinnen muss, gehoert in die Datei mit der Modulform. Gemerkt habe
ich es nur, weil die Bildmessung den errechneten Schatten AUSGIBT
statt ein Bild zu machen.
Beim Herausschneiden blieb eine Klammer zu viel in start.css stehen --
gefunden von pruef-css-klassen („eine schliessende Klammer ohne
oeffnende"), bevor sie still CSS verschluckt hat.
AUSSERDEM BEHOBEN
* Spicy Media sah an einer FREMDEN Liste „Bearbeiten" und „Loeschen",
und der Server antwortete mit 403. Ein Knopf, der nichts tut, ist
schlimmer als kein Knopf.
* Klick auf eine Person klappt jetzt alle vier Zeilen auf. Die
Vorlage verspricht „zeigt deren Eintraege" -- zugeklappt zeigte
der Klick nur Zahlen.
* Der CSV-Export kennt drei Staende statt zwei: „pflichtig", „neu,
noch ohne Pflicht", „nicht mehr dabei". Vorher hiess beides „nein".
* Das Aufklappen baute die ganze Liste neu und riss den
angeklickten Knopf weg (Fokus sprang nach oben).
GEPRUEFT: 168 Pruefungen, 0 Fehler (vorher 141)
Neu darunter: der Umbau auf einem echten Alt-Bestand (Zeilen, Spalten,
Inhalt, Indizes, Trigger, und ein zweiter Lauf, der nichts mehr tut),
das Loeschen einer Person mit Eintraegen aus einem abgeschlossenen
Monat -- mit Gegenprobe, dass dieselbe Sperre den INHALT weiterhin
nicht aendern laesst.
Zwei meiner neuen Pruefungen haben zuerst sich selbst gemessen statt
den Code: Eine verglich gegen einen Eintrag, den sie vorher geloescht
hatte (404 sah aus wie ein haltender Riegel), die andere meldete eine
fehlende Spalte, die nur ihr eigener Handeinsatz verursacht hatte.
Beide berichtigt.
Am Bildschirm nachgemessen bei 412 px und 1280 px: kein waagerechtes
Schieben, kein eigenes Beruehrziel unter 40 px, genau EINE Kachel mit
Saum und zwanzig ohne.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
db656f6e14 |
Manager-Ziele: vier feste Monatsaufgaben, die sich selbst zuruecksetzen
Filipe mit der Vorlage „Prompt · Kachel Agentur-Aufgaben" (02.10.2026):
Scouts, Manager, DogFather und Spicy Media bekommen vier Pflichten je
Monat -- Creator rekrutieren, Manager-Meeting, Schulung oder Community
Talk, Werbung auf TikTok -- mit Fortschritt, Ampel, Warnungen und
einem Monatsschnitt, der nichts loescht.
DREI ENTSCHEIDUNGEN, DIE VON DER VORLAGE ABWEICHEN -- alle abgestimmt:
1. DIE KACHEL HEISST „Manager-Ziele", nicht „Agentur-Aufgaben".
Es gibt bereits eine Kachel „Agentur" und eine „Aufgaben". Eine
dritte mit beiden Woertern im Namen waere auf einem Handy nicht
mehr auseinanderzuhalten.
2. DIE ZIELZAHLEN GELTEN JE ROLLE, und DogFather UND Spicy Media
duerfen sie aendern. Ein Scout muss nicht dieselbe Zahl schaffen
wie die Leitung.
3. DIE SCOUT-PIPELINE IST ANGEBUNDEN, in beide Richtungen: Vorschlaege
aus uebergebenen Leads, Namensvorschlaege beim Tippen, die
Verbindung bleibt am Eintrag gespeichert. Aber NICHTS zaehlt von
selbst -- gezaehlt wird nur, was ein Mensch bestaetigt hat. Ein
Zaehler, der sich allein fuellt, ist einer, dem niemand glaubt.
WAS ANDERS GEBAUT IST, ALS ES NAHELAG
DAS ZIEL WIRD PRO MONAT EINGEFROREN (`mz_ziel` hat den Monat im
Schluessel). Laege nur ein aktueller Wert in `einstellungen`, schriebe
jede spaetere Aenderung rueckwirkend den ganzen Verlauf um: Ein Monat,
der mit 2/2 abgeschlossen war, staende nach einer Erhoehung auf 4
ploetzlich als „nicht erreicht" da. Ein Verlauf, der sich rueckwirkend
aendert, ist keiner. Es gibt deshalb gar keinen Weg, den laufenden
Monat umzuschreiben -- gespeichert wird immer in den naechsten.
DIE SPERRE VERGANGENER MONATE SITZT IN DER DATENBANK, nicht im Code
(drei Trigger). Die Ausnahme fuer DogFather laesst sich in SQLite
nicht ueber die Sitzung abfragen, also ist sie ein sichtbarer Vorgang:
`mz_freigabe` wird fuer die eine Handlung geoeffnet, im `finally`
wieder geschlossen und verfaellt nach zwei Minuten von selbst. Jede
Korrektur steht mit Name und Zeit im Protokoll.
DER LAUFENDE MONAT STEHT IN EINER TABELLE (`mz_lage`), nicht in
`strftime(...,'localtime')`. Sonst entschiede die Zeitzone des Servers,
und am Monatsersten zwischen 00:00 und 02:00 griffe die Sperre fuer
den falschen Monat. Gerechnet wird durchgehend in Europe/Berlin
(identisch mit dem Europe/Luxembourg der Vorlage, aber dieselbe
Zeitrechnung wie der Rest des Hauses).
KEIN ZWEITER ZAEHLER FUER DIE KACHELWAND. Rand und Abzeichen auf der
Startseite kommen aus `workspace-hinweise.js` und damit aus derselben
Rechnung wie die Seite (`standFuer`). Zwei Rechnungen ueber dieselbe
Sache laufen auseinander, und zwar lautlos.
KEIN IMPORTKREIS ZU workspace-push.js. Die Erinnerungen entstehen hier
als Liste (`zielRufe`), verschickt werden sie im vorhandenen
Fuenf-Minuten-Takt. Der Tag steht im Merkmal -- dadurch geht pro
Person hoechstens EINE Meldung am Tag heraus, obwohl der Lauf
288-mal stattfindet.
GETRENNTE HAEUSER: Auf crew.dogfather-universe.com gibt es diese
Kachel nicht, auch nicht fuer DogFather. Gemessen, nicht angenommen.
GEPRUEFT (141 Pruefungen, 0 Fehler) -- mit Gegenproben zu jeder Sperre
* Vier Rollen kommen herein, drei bekommen 404 (nicht 403), und die
ANZAHL steht in der Bedingung. „Alle abgewiesen" waere auf einer
leeren Liste wahr.
* Die Ampel wird mit EINGESETZTEN Tagen gemessen, nie gegen die
Wanduhr -- diese Pruefung sagt am 16. November dasselbe wie heute.
(gate-oeffnung.mjs im Shop war gruen, bis der Kalender sie
ueberholte.)
* Die Datenbank lehnt einen Eintrag im Vormonat selbst ab; danach
wird nachgewiesen, dass die Freigabe nur EINMAL gewirkt hat.
* Neun Absagen mit dem jeweils richtigen Grund -- und eine
Instagram-Adresse, die durchgehen MUSS, weil sonst nur bewiesen
waere, dass die Pruefung streng ist, nicht dass sie richtig ist.
* Am 7. des Monats ist Ruhe: Ohne diese Zeile bewiese der
Erinnerungs-Block nur, dass immer etwas kommt.
ZWEI BEFUNDE KAMEN AUS DER MESSUNG, NICHT AUS DEM NACHDENKEN
* Beim Aufklappen einer Zeile wurde die ganze Liste neu gebaut --
der angeklickte Knopf existierte danach nicht mehr, der Fokus
sprang an den Seitenanfang. Gefunden hat es die Bildmessung, der
die Schaltflaeche unter der Hand wegbrach.
* Zwei meiner Messungen waren falsch, nicht der Code: Der
Haus-Test schickte den Keks nicht mit (401 statt 404), und
`Response.text()` entfernt ein BOM beim Dekodieren -- der Export
hatte eines, die Pruefung sah es nur nicht. Jetzt wird in Bytes
gemessen.
Kachelton 47 (#7368ff) ist mit tools/kachel-farbe-einzeln.mjs gegen
alle 46 vorhandenen gerechnet, nicht ausgesucht: Abstand 0,0899,
Kontrast 4,61:1. Beruehrziele, waagerechtes Schieben und
Schriftgroessen sind am Bildschirm bei 412 px und 1280 px nachgemessen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|