ea32d6790bbca0d4349d266ff5f0f6779ebc2930
907
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 DogFatherGit
|
ea32d6790b |
Das Auge ist am Finger ein volles Ziel -- und die Leiste bleibt eine Reihe
Filipe zur offenen Entscheidung "36-px-Auge oder 44-px-Fingerziel":
"mach was du am besten haelst es soll nur immer alles einfach zu
bedienen sein und geil aussehen fertig."
DIE ENTSCHEIDUNG WAR EINE SCHEINALTERNATIVE. Gemessen am echten
Aufbau, statt der Notiz zu glauben:
Breite Auge uebrige Knoepfe Leiste
360 px 42 x 44 alle 44 x 44 zwei Reihen
390 px 42 x 44 alle 44 x 44 zwei Reihen
412 px 34 x 44 alle 44 x 44 eine Reihe
1280 px 116 x 32 mit Beschriftung
Die HOEHE stimmte laengst. Es fehlten zwei Pixel Breite -- bei 412 px
zehn. Der Umschalter war als einziger Knopf der Leiste kein volles
Ziel, und ausgerechnet er sitzt zwischen zwei anderen.
ZWEIMAL DIE ALTE FALLE AUF DEM WEG:
Erster Anlauf vergroesserte nur den Knopf. Gemessen bei 412 px:
Knopf 44, Behaelter 36 -- der Knopf ragte 3 px ueber den Nachbarn.
Genau so lag am 11.09. der Umschalter ueber dem Chat-Knopf, und wer
"Meine Sicht" antippte, landete im Chat. Die Lehre von damals steht
in start.css ("wer nur den Rahmen begrenzt, begrenzt nichts") und
gilt andersherum genauso.
Danach brach die Leiste bei 412 um -- "Abmelden" in einer zweiten
Zeile, genau Filipes Beanstandung vom 09.09. Gerechnet: 386 px
noetig, 380 verfuegbar. Sechs Pixel. Sie kommen jetzt aus dem
Weissraum (4->2 zwischen den Zeichenknoepfen, 10->6 zur linken
Gruppe), nicht aus den Tippzielen -- am Ziel zu sparen ist genau der
Fehler, der sie ueberhaupt erst auf 34 und 36 gebracht hat.
NEBENGEWINN, nicht geplant: Bei 390 px -- der haeufigsten Breite --
geht die Leiste dadurch von zwei Reihen auf eine, 117 px auf 69. Bei
360 px bleibt sie zweireihig, und das ist richtig: Dort fehlen auch
so noch zwoelf Pixel, und Umbrechen ist die ehrliche Antwort auf zu
wenig Platz.
Am Rechner unveraendert: 116 x 32 mit Beschriftung, weil dort eine
Maus zielt und kein Daumen. Die Regel haengt an `pointer: coarse`.
Gemessen nachher: alle vier Breiten 44 x 44, keine Ueberlappung,
nichts breiter als der Schirm. pruef-tippziele 11/0,
pruef-css-klassen 30/0.
|
||
|
DogFatherGit
|
2b6c2be1ad |
Die Stelle bleibt -- auch wenn die Seite dazwischen neu laedt
Filipe, zum vierten Mal: "wenn ich in eine kategorie rein gehe und dan zurueck geh die hauptseite immer wieder ganz hoch ... ohne dass die seite hoch scrollt ODER NEU LAEDT." DAS "ODER NEU LAEDT" WAR DER HINWEIS, und ich habe ihn zweimal ueberlesen. kopf.js laedt die Seite selbst neu, sobald der Browser sie aus seinem Rueckwaerts-Speicher holt -- damit keine veralteten Zahlen dastehen. Nach einem Neuladen heisst die Navigationsart aber "reload", nicht "back_forward". UND DIE EIGENTLICHE BOSHEIT stand in einer Zeile, die ich selbst geschrieben habe: Wurde eine Ankunft nicht als Zurueck erkannt, wurde die gemerkte Stelle GELOESCHT. Ein einziges Neuladen reichte -- danach half auch das naechste Zurueckgehen nicht mehr. Deshalb "geht es immer noch nicht", obwohl ich es dreimal fuer behoben hielt. WARUM ES IN JEDER MESSUNG FUNKTIONIERT HAT: kopf.js haelt einen Ereignisstrom offen, und der sperrt den Rueckwaerts-Speicher aus. `persisted` bleibt hier immer false, die Neulade-Zeile lief nie. Auf einem echten Handy greift er sehr wohl. Man muss den Weg gehen, den der Mensch geht -- und wenn man ihn nicht nachstellen kann, baut man gegen ALLE Wege robust statt gegen einen. FUENF AENDERUNGEN: Die Stelle wird LAUFEND gemerkt (gedrosselt auf 250 ms), nicht nur beim Klicken und Verlassen. Deckt auch die Glocke, eine Benachrichtigung und einen Absturz des Reiters ab. Nichts wird mehr geloescht. Die Stelle verfaellt von selbst nach einer Stunde. Wiederhergestellt wird jetzt auch bei "reload" und bei "navigate mit Herkunft aus diesem Haus" -- nicht nur bei "back_forward". Vor dem Neuladen aus dem Rueckwaerts-Speicher wird die Stelle samt Merker festgehalten. Der Pfeil in der Kopfleiste setzt den Merker jetzt fuer BEIDE seiner Wege. Er nimmt history.back() nur, wenn `document.referrer` da ist -- sonst location.assign(), und das ist fuer den Browser ein Hingehen. Hier stand "der braucht nichts"; fuer den zweiten Weg stimmte das nie. Ein Neuanfang faengt weiterhin oben an: keine Herkunft, kein Merker -- also vom Startbildschirm, aus einer Benachrichtigung, ueber die Adresszeile. Beim Bauen fast hineingelaufen: `START` steht in einem anderen Block derselben Datei und waere an der neuen Stelle ein Absturz gewesen -- dieselbe Falle wie bei `$` am 21.09. Jetzt gibt der erste Block ihn einmal bekannt, statt ihn abzuschreiben. Geprueft: pruef-stelle 15/0 (war 9) -- Brotkrume (navigate), Browser-Zurueck (back_forward), NEULADEN (reload), Neuanfang oben, und dass eine fremde Ankunft die Stelle nicht wegwirft. Dazu pruef-sprung 43/0, pruef-start-ansicht 153/0, pruef-css-klassen 30/0. |
||
|
DogFatherGit
|
66789aabcd |
Willkommen: eine Seite, die erklaert, was es hier gibt
Auftrag vom 21.09.2026, Abschnitte 7 und 8. Aus der Kachel "Der Treff" wird die Willkommensseite. WARUM DAS NICHTS VERLIERT, gemessen am echten Bestand: Das Brett "treff" hatte NULL Eintraege, der Treff-Chat daneben 29 Nachrichten. Geredet wird im Chat; das Brett war eine Kachel ohne Inhalt. DIE SEITE ERKLAERT NICHT "DIE WEBSITE", SONDERN DEINE. Sie baut sich aus derselben Kachelliste wie die Startseite, durch denselben Filter (darfSeite). Wer morgen eine Kachel bekommt, bekommt automatisch auch ihre Erklaerung -- und wer eine nicht hat, liest nicht davon. Eine Liste von Dingen, die man nicht darf, ist keine Orientierung. Gemessen: DogFather 30 Kacheln, Modi 25, Community 11 -- und keine einzige davon ist fuer den Betreffenden gesperrt. DREI FEHLER, DIE ERST DAS BILDSCHIRMFOTO GEZEIGT HAT: body class="gate" ist die ANMELDEWAND (display:flex, zentriert). Kopfleiste und Inhalt standen dadurch NEBENEINANDER -- am Handy blieben dem Text 260 von 390 Pixeln. .huelle gibt es im Haus gar nicht. Der Inhalt stand linksbuendig statt mittig, ohne Sicherheitsrand an randlosen Geraeten. Jetzt .inhalt wie jede andere Seite. Der Text stand direkt auf dem Buehnenbild: Kontrast 1.68:1 am Rechner, 2.23:1 am Handy (noetig 4.5). Die Hausregel stand daneben in start.css -- "der Text steht auf eigenen Flaechen" -- und diese Seite hielt sich als einzige nicht daran. Jetzt 5.19 und 7.73. UND EIN LECK, ZUM DRITTEN MAL DIESELBE URSACHE: Die Kachel umzuleiten nahm dem Brett "treff" die Zugehoerigkeit -- TREFF_BRETTER wird aus Kachelzielen abgeleitet. Die Schranke laesst eine AGENTURROLLE unbesehen durch, wenn ein Brett in keiner Liste steht: Eine Creatorin konnte das Brett des Treffs lesen. Behoben, und diesmal dauerhaft laut gemacht: Nachgemessen ist die Trennung exakt und in beide Richtungen deckungsgleich -- die Bretter mit `fuerAlle` sind genau die des Treffs plus die Agenturablage. Das ist eine Eigenschaft des BRETTS und wandert nicht, wenn jemand eine Kachel umleitet. pruef-treff prueft das jetzt. Mein erster Entwurf der Regel war zu breit und meldete `content` und `schutz` -- beides Agenturbretter, die eine Agenturrolle zu Recht liest. Eine Pruefung, die zu viel meldet, wird abgeschaltet. AUSSERDEM: 16 Kennungen aus workspace-zuteilung.js hatten keinen deutschen Satz -- auf dem Bildschirm haette woertlich "nicht_zugeteilt" gestanden. Gefunden von pruef-meldungen am selben Tag. Und zwei Erwartungen in pruef-treff abgeleitet statt gezaehlt: die Zahl der Rollenkacheln auf der Wand (die Anmeldung sucht WHERE rolle=?, eine Rolle ohne Kachel ist unerreichbar) und "die breite Kachel steht vorne" ueber die Eigenschaft statt ueber den Namen. Geprueft: pruef-willkommen 66/0 (neu), pruef-treff 80/0 (war 59 ok / 13 FEHL), pruef-buehne fuer die neue Seite 10/0, pruef-meldungen 8/0, pruef-css-klassen 30/0, pruef-rechtetafel 19/0. |
||
|
DogFatherGit
|
b506c7f533 |
Die Oberflaeche dazu: Resuemee, Annehmen, Ablehnen, Bewerten
Auftrag vom 21.09.2026, Abschnitte 1 bis 5 -- der sichtbare Teil.
UEBER DEM BRETT STEHT JETZT EIN BAND, und es ist rollenabhaengig:
Modi "Deine Aufgaben" -- sein persoenliches Resuemee mit
offen / in Arbeit / erledigt / ueberfaellig, und
darueber EIN Satz, der die Zahlen einordnet. Fuenf
nackte Zahlen sind eine Tabelle, ein Satz ist eine
Auskunft.
DogFather, "Wer hat gerade was" -- eine Zeile je Person mit
beide Haende ihren Marken. Antippen filtert das Brett auf sie,
noch einmal antippen zeigt wieder alles. Ohne das
zweite waere der Filter eine Falle: hinein ja,
heraus nein.
WELCHES BAND JEMAND BEKOMMT, entscheidet `darf_verteilen` vom Server
-- aufgaben.js muss die Rollen dafuer nicht kennen.
AN JEDER KARTE steht jetzt, wer sie hat und wie es bei jedem steht:
Name, Zustand, bei einer Ablehnung der Grund daneben (wer "abgelehnt"
liest, will als Naechstes wissen, warum), bei einer Rueckmeldung der
Text dazu.
Und genau die Knoepfe, die fuer DIESEN Menschen gerade gehen:
Annehmen / Ablehnen, bei einem Pool "Ich uebernehme das", danach
"Ich fange an" und "Fertig". Ein "Annehmen" an einer fremden Aufgabe
waere ein Knopf, der mit 403 antwortet -- und die Meldung erscheint
ganz oben, wo man sie bei einer Karte weiter unten gar nicht sieht.
Diese Lektion stand in aufgaben.js schon einmal.
DIE BEWERTUNG SIND DREI BENANNTE KNOEPFE, keine Auswahl im Dialog.
Abschnitt 5 nennt drei Moeglichkeiten -- als Auswahl hiesse das: erst
klicken, dann lesen, dann waehlen. Als drei Knoepfe sieht man sofort,
was es gibt. Bei "Verbesserungsmoeglichkeiten" ist der Text Pflicht
("soll ein Eingabebereich erscheinen"), bei den anderen freiwillig.
AN MEHRERE VERTEILEN ist ZUSAETZLICH und nicht statt dessen: Eine
Person ist der haeufigste Fall und bleibt ein Klick. Wer mehr will,
klappt "Noch jemanden dazunehmen" auf. Die Namen darin werden aus der
Auswahl darueber ABGELEITET -- zwei Namenslisten in einer Datei, die
jeder herunterlaedt, waeren eine zu viel. Die Frage "wie soll das
laufen" erscheint erst ab zwei Leuten; vorher waere sie eine
Entscheidung ohne Gegenstand.
EIN EIGENES MODUL (zuteilung.js), weil aufgaben.js schon 1900 Zeilen
hat. Die Zustandswoerter kommen vom SERVER, nicht aus einer zweiten
Liste im Browser -- sonst heisst derselbe Zustand an zwei Stellen
anders.
ZWEI DINGE, DIE ERST DAS MESSEN GEZEIGT HAT:
(1) `window.nachfragen` gibt es nicht -- der Dialog heisst `frageNach`
und kennt `grund`/`grundPflicht`, aber keine Auswahl. Ich hatte
eine Schnittstelle benutzt, die ich mir gemerkt statt nachgesehen
hatte. Aus der Not wurde die bessere Loesung: drei Knoepfe.
(2) Auf dieser Seite gibt es KEIN Suchfeld -- `#wer` in der
Kopfleiste ist die Anzeige, wer angemeldet ist. Der Personenfilter
wirkt deshalb unmittelbar am Brett.
pruef-zuteilung: 66/0 (war 48/0) -- 18 davon am echten Bildschirm.
Der Browserteil scheiterte zuerst mit `chrome-error://chromewebdata/`:
crew.dogfather-universe.com steht in Chromiums eingebauter HSTS-Liste,
der Browser schaltet von sich aus auf https, und der Testserver
spricht http. Abschalten geht nicht (die Liste ist einkompiliert).
Jetzt derselbe https-Vorbau wie in pruef-handy-teamdogi -- eine
Nachbildung waere die zweite Fassung, die anders altert.
Nachbarn gruen: pruef-aufgabenbrett 49/0, pruef-verteilen 16/0,
pruef-css-klassen 30/0, pruef-tippziele 11/0.
|
||
|
DogFatherGit
|
ef0fddc724 |
Aufgaben an Menschen: zuteilen, annehmen, ablehnen, bewerten
Auftrag vom 21.09.2026, Abschnitte 2 bis 5 -- der Serverteil.
DREI ARTEN ZU VERTEILEN, und der Unterschied zwischen den letzten
beiden ist der ganze Punkt:
einzeln eine Person, sie macht es
mehrere mehrere Personen, JEDE macht ihren Teil
pool mehrere sehen es, EINE nimmt es -- danach ist es fuer die
anderen weg, damit niemand doppelt arbeitet
EINE EIGENE TABELLE, KEINE SPALTEN AN DER AUFGABE. Abschnitt 4
verlangt ausdruecklich: *"Die Aufgabe muss in der Auswertung auf die
einzelnen zugewiesenen Personen aufgeteilt werden"* -- und gleichzeitig
soll "die urspruengliche gemeinsame Aufgabe ihre uebergeordnete
Struktur" behalten. Eine Aufgabe hat EINEN Titel und EINE Frist, aber
je Mensch einen eigenen Stand, einen eigenen Grund beim Ablehnen, ein
eigenes Erledigt-Datum und eine eigene Rueckmeldung. Das in Spalten zu
pressen hiesse, dieselbe Aufgabe mehrfach anzulegen.
`aufgaben.status` bleibt daneben unberuehrt. Zwei Ebenen, weil es zwei
Fragen sind: "Wie steht die Aufgabe?" und "Wie steht sie bei IHM?" Ein
einziges Feld koennte bei drei Leuten nicht gleichzeitig "angenommen"
und "abgelehnt" sein.
DER WICHTIGSTE EINZELNE HANDGRIFF -- und er steht nicht im Auftrag:
Wer eine Aufgabe BEKOMMEN hat, sieht sie jetzt immer. Bei "mehrere"
und "pool" bleibt `verantwortlich_id` leer, und die alten Sichtregeln
fragen genau danach. Ohne die Erweiterung stuende eine Aufgabe im
Resuemee der Leitung und waere fuer den, der sie machen soll,
unsichtbar -- der unangenehmste denkbare Fehler in einem
Aufgabensystem, und man sieht ihn nirgends. Die Erweiterung ist ein
ODER, kein UND: Sie erweitert die Sicht, die Haustrennung darueber
bleibt ein UND und wirkt weiter.
WAS SONST NOCH ENTSCHIEDEN WURDE, mit Grund im Code:
- Ablehnen braucht eine Begruendung (mind. 3 Zeichen). Ein leeres
Nein ist fuer den, der verteilt hat, keine Information -- er muss
dann nachfragen, und genau das sollte die Nachricht ersparen.
- "Verbesserungsmoeglichkeiten" braucht einen Text. Ein leeres
"kann besser" sagt nichts ausser, dass jemand unzufrieden war.
- Bewertet wird erst, wenn jemand FERTIG ist. Eine Rueckmeldung auf
etwas, das noch laeuft, ist keine Bewertung, sondern eine
Einmischung.
- Beim Pool wird VOR dem Schreiben gefragt, ob schon jemand zugesagt
hat -- sonst nehmen zwei im selben Moment dieselbe Aufgabe und
beide sehen "hat geklappt".
- Wer schon geantwortet hat, behaelt seinen Stand, wenn die Aufgabe
noch einmal gespeichert wird. Sonst muesste er ohne Grund erneut
zusagen.
- Wer nicht mehr dabei ist, faellt raus -- aber nur, solange er noch
nicht geantwortet hat. Jemandem eine angenommene Aufgabe
wegzunehmen, ohne dass er es erfaehrt, waere die unangenehmste Art,
Arbeit zu verlieren.
- "pool" mit einer Person wird "einzeln". Ein Pool aus einem
Menschen ist keiner.
`verantwortlich_id` bleibt und wird mitgefuehrt (einzeln = die Person,
pool = der Uebernehmer, mehrere = leer): Brett, Startseite und
Uebersicht gruppieren danach. Drei gewachsene Ansichten gleichzeitig
umzubauen waere der groessere Eingriff -- und im haeufigsten Fall
sagen beide dasselbe.
KEIN CHECK an der nachgetragenen Spalte `verteilart`, mit Absicht: Ein
CHECK auf einer nachgetragenen Spalte hiesse, die Tabelle neu zu bauen
-- der Weg, der in diesem Haus am 11.09. und heute schon Spalten
gekostet hat. Geprueft wird beim Schreiben.
pruef-zuteilung.mjs, 48 Aussagen -- ein Arbeitstag durchgespielt.
Ein Fehlschlag beim ersten Lauf, und er war lehrreich: "Cem hat keinen
eigenen Stand" schlug fehl, weil Cem die Aufgabe gar nicht SIEHT
(`null?.x` ist `undefined`, nicht `null`). Die Zusicherung konnte
"sieht sie nicht" und "sieht sie ohne Stand" nicht unterscheiden --
also pruefte sie beides nicht richtig. Dass er sie nicht sieht, ist
genau Abschnitt 1: *"Eine Modi darf nicht automatisch die
vollstaendige Aufgabenuebersicht aller anderen Modis sehen."* Beide
Faelle stehen jetzt einzeln da, mit einer Gegenprobe, dass seine Liste
ueberhaupt laedt.
Nachbarn gruen: pruef-verteilen 16/0, pruef-aufgabenbrett 49/0,
pruef-umstellung 18/0.
|
||
|
DogFatherGit
|
21793b6c36 |
Neue Rolle: die linke Hand
Aus dem Auftrag vom 21.09.2026, Abschnitt 6: "Die linke Hand erhaelt
grundsaetzlich dieselben Rechte wie die rechte Hand in allen Bereichen,
die die Modis, Aufgaben, Aufgabenzuweisungen, Uebersichten,
Kommunikation und Auswertungen betreffen. Die linke Hand darf keine
neuen Personen oder Accounts hinzufuegen. Die linke Hand darf keine
privaten bzw. persoenlichen Bereiche oder Informationen von Dogfather
sehen."
GEMESSEN VOR DEM BAUEN: Die Rolle "hand" steht an 35 Stellen im
Servercode und 17-mal in der Rechtetafel. Haette ich ueberall ein
"linke" danebengeschrieben, waere die naechste Stelle, die jemand
hinzufuegt, die erste, die es vergisst -- und eine vergessene Stelle
heisst hier: Die linke Hand sieht etwas nicht, ohne dass jemand merkt,
warum.
DESHALB EINE REGEL STATT DREISSIG ABSCHRIFTEN:
WIE_RECHTE_HAND = new Set(["hand", "linke"]) in workspace.js
istHand(person) fuer die Faehigkeiten
eine Schleife ueber SEITEN fuer die Rechtetafel
Die Schleife gibt der linken Hand jede Seite der rechten -- ausser
fuenf, und jede davon steht mit Grund da:
personen.html legt Personen an
bewerbungen.html fuehrt zu neuen Personen
talente.html fuehrt zu neuen Personen
hilfe.html vertraulicher Meldeweg
rechte.html Rechteverwaltung
Gemessen: 25 Seiten fuer die rechte Hand, 20 fuer die linke. Als
Kacheln: 30 gegen 26 -- die vier verbotenen erscheinen gar nicht erst,
statt beim Antippen abgelehnt zu werden.
ZWEI DINGE, DIE ERST DAS MESSEN GEZEIGT HAT:
(1) OHNE KACHEL AUF DER ANMELDEWAND GIBT ES DIE ROLLE NICHT. Die
Anmeldung sucht `WHERE rolle = ?` auf die angetippte Kachel -- es
gibt keinen rollenuebergreifenden Sonderweg, auch nicht auf der
Crew-Wand. Eine linke Hand haette sich mit dem richtigen Code
NIEMALS anmelden koennen, und der Fehler haette ausgesehen wie ein
falscher Code.
(2) DIE REIHENFOLGE DER DATENBANK-UMSTELLUNG ZAEHLT.
`checkListeErweitern` baut die CHECK-Regel NEU aus der Liste, die
man ihm gibt. Mein Schritt stand zuerst bei der rechten Hand --
der Schritt fuer "gast" darunter nahm die Rolle damit wieder
heraus, denn seine Liste kennt sie nicht. Die Kette ist kumulativ;
neue Schritte gehoeren ans ENDE. Das steht jetzt auch dort.
Dazu zwei kleinere Funde beim Bauen:
- Meine erste Ableitung aenderte die Rollenliste AN ORT UND STELLE.
Mehrere Seiten teilen sich dieselbe Liste (`ALLE`) -- das haette
die Rolle allen Seiten gegeben, die sie benutzen, auch einer
Ausnahme. Faellt nicht auf, solange keine Ausnahme `ALLE` benutzt.
Jetzt eine Kopie je Seite.
- ROLLEN_NAME fehlte der Eintrag: Die linke Hand haette ueberall
"linke" geheissen statt "Linke Hand". Gefunden hat das
pruef-rechtetafel, weil sie diese Tabelle gegen ROLLEN haelt.
Ihre Meldung nennt jetzt, WELCHE Liste was vermisst -- vorher
zeigte sie beim Fehlschlag nur eine der beiden.
NICHT BEKOMMEN -- und jedes einzeln begruendet im Code:
Personen anlegen (ANLEGBAR.linke = []), Rollen aendern
(darfRollenWechseln), Bewerbungen, der vertrauliche Meldeweg. Beim
Meldeweg ist es bewusst das kleinere Recht: Ein Wort von Filipe
oeffnet ihn, eine versehentlich gelesene Meldung laesst sich nicht
zurueckholen.
UNBERUEHRT GEBLIEBEN, obwohl dort "hand" steht:
workspace-leistung.js:406 -- dort heisst "hand" nicht die Rolle,
sondern "von Hand eingetragen".
Am laufenden System gemessen: Datenbank nimmt die Rolle, Anmeldung
HTTP 200, 26 Kacheln, darf_verteilen = true, personen/hilfe/rechte
antworten mit 302, aufgaben und teamlage mit 200.
pruef-rechtetafel 19/0 (war 18/1), pruef-schranke 39/0,
pruef-umstellung 18/0.
|
||
|
DogFatherGit
|
432e533c86 |
Am Handy wird aus einer Kalenderpille ein Punkt
GEMESSEN, was dort wirklich stand:
Fenster Zelle Pille Platz fuer Text
360 px 42 px 32 px 16 px -> 1-2 Buchstaben
390 px 46 px 36 px 20 px -> 2-3 Buchstaben
412 px 49 px 39 px 23 px -> 3 Buchstaben
768 px 95 px 85 px 69 px -> lesbar
"Content-Ideen sammeln" wurde zu "C…" -- eine Zeile, die Hoehe kostet
und nichts sagt. Drei Termine an einem Tag waren drei solche Zeilen.
JETZT: ein Punkt je Termin, nebeneinander. Man sieht, DASS an dem Tag
etwas ist und wie viel, und tippt den Tag an, um zu lesen, was. Der
Tagesdialog dafuer steht seit jeher, ist lesbar und hat 44-px-Zeilen;
er war nur schwer zu finden, solange das Raster so tat, als koenne man
dort lesen.
- Zeitraum: bleibt ein durchgehender Balken. Ihn auch zu Punkten zu
machen naehme genau das weg, wofuer er am 21.09. gebaut wurde.
- Anlass (Feiertag u. a.): ein ECKIGES Zeichen, damit man es vom
runden Termin unterscheidet. "DE…" fuer "Tag der Deutschen
Einheit" sagt genauso wenig.
- Erledigtes: hohl statt voll -- sonst saehe ein abgehakter Termin
aus wie ein offener, und der Kalender loege.
- Die Punkte sind NICHT einzeln antippbar (pointer-events: none).
Ein 8-px-Link waere ein Nadeloehr; so faellt jeder Tipp auf die
Zelle. Am Rechner bleibt die Pille ein Link.
DREI DINGE, DIE ERST DAS BILDSCHIRMFOTO GEZEIGT HAT:
(1) Die Zahlen sagten 8 x 8 -- und der Titel lief trotzdem quer ueber
die Nachbarzellen. Ursache: start.css traegt eine Sammelregel
`body.start .k-pille { font-size: .75rem }`, um ein Element
spezifischer als `.k-tag .k-pille` (0,2,1 gegen 0,2,0). Sie
gewinnt, egal welche Datei spaeter laedt. Aufgeklaert hat es die
Frage an den Browser, WELCHE Regeln auf das Element passen.
(2) `.k-tag` traegt `container-type: inline-size` und ist damit der
Behaelter fuer ihre KINDER. Eine Regel fuer `.k-tag` SELBST in
`@container` wird gegen den naechsten Behaelter darueber geprueft
und greift nie. Die Zelle blieb eine Flex-Spalte, jeder Punkt bekam
eine eigene Zeile. Jetzt fragt die Zelle das Raster -- ein
benannter Behaelter, Schwelle gerechnet: 46 + 8 + 7 x 60 = 474.
(3) Die Kinder der Pille (Uhrzeit, Wiederholzeichen) haben eine eigene
Schriftgroesse und hielten den Punkt auf 26 px Hoehe. Ein 8 x 26
grosser "Punkt" ist ein Strich.
pruef-kalender: 141/0 -- vorher 135 ok und 6 FEHL.
Die sechs waren KEIN Fehler am Kalender, und nur einer davon war neu:
- Vier kamen von Screen 11 (Termin von-bis): Ein Eintrag ueber fuenf
Tage setzt fuenf Marken, und die Pruefung zaehlte Marken statt
Eintraege. Sie hatte am 17.09. schon gelernt, ihre Erwartung
abzuleiten -- veraltet war diesmal nicht die Erwartung, sondern
das, was gemessen wurde. Gezaehlt wird jetzt ueber den VERWEIS
(`zeigen=eintrag-N`), der an jedem Tag derselbe ist. Der `title`
ginge nicht: Er endet mit "(Tag 3 von 5)".
- Zwei waren meine: Die Pruefung las die Farbe aus der linken Kante
-- die faellt beim Punkt weg, also meldete sie "1 Farbe" statt 5.
Gelesen wird jetzt `--pfarbe`, die Quelle selbst.
Neun neue Zusicherungen, darunter die, die beim Bauen gefehlt hat:
"nichts ragt ueber den Rand seiner Zelle hinaus". Groesse allein
genuegt nicht -- die Pille war bereits 8 x 8 und trug trotzdem Text.
Gegenprobe: Raster auf 1200 px aufziehen, Titel muss zurueckkommen.
Nachbarn gruen: pruef-tippziele 11/0 (sieht die 11 neuen Regeln, zaehlt
den Punkt richtig nicht als Tippziel), pruef-css-klassen 30/0,
pruef-zeitraum 16/0, pruef-terminregel 35/0.
|
||
|
DogFatherGit
|
bfbe6feafe |
Fett, kursiv, unterstrichen, durchgestrichen -- ueberall
Filipe, 21.09.2026: "dan will ich dass die leute auch immer die art
von text aussuchen können, fettgedrückt, unterstrichen und so alles.
das überall sei es im chat jeder für sich oder sei es wenn die modis
oder rechte hand oder dogfather eine aufgabe oder sachen posten."
VORHER GEMESSEN: Es gab genau EINE Auszeichnung im ganzen Haus --
fett, und nur auf den Brettern (`mitFett` in bereich.js). Im Chat
konnte niemand etwas hervorheben.
EINE QUELLE FUER DAS GANZE HAUS: workspace/assets/js/textform.js.
Chat, Bretter und Aufgaben zeichnen ihren Text jetzt durch denselben
Zerleger. Drei Fassungen derselben Regel waeren drei Fassungen, die
verschieden altern.
**fett** _kursiv_ __unterstrichen__ ~~durchgestrichen~~
Dazu eine Leiste ueber jedem Schreibfeld: F K U S, 44 px am Finger,
Strg+B/I/U, und ein zweiter Druck nimmt die Zeichen wieder weg.
DIE WORTGRENZEN SIND DER EIGENTLICHE BAU. Ein Zerleger, der alles
auszeichnet, ist schlimmer als keiner: `datei_name_hier` hiesse
plotzlich anders, als es heisst, und `@max_muster` ebenso. Deshalb
stehen bei den Unterstrichen Wortgrenzen -- bei Sternchen und Tilden
nicht, die kommen in Text nicht versehentlich paarweise vor.
GEBAUT MIT createTextNode, NIE innerHTML. Wer Text zu Auszeichnung
macht, ist einen Tippfehler von einer Luecke entfernt. Das ist heute
sicher; pruef-textform misst es, damit es das morgen auch ist.
EIN ECHTER FEHLER DABEI GEFUNDEN -- in meinem eigenen Einbau von
vorhin: Auf dem Aufgabenbrett stand `$('f-text')` in einem Block, der
`$` gar nicht kennt (die Datei hat drei getrennte Bloecke).
`ReferenceError: $ is not defined`, die Leiste kam dort nie an, und
die Seite sah dabei vollkommen normal aus. Derselbe Block beginnt
ausserdem mit `if (!feld) return;` auf ein Aufwand-Feld, das mit
Textgestaltung nichts zu tun hat -- die Leiste haette an einer
voellig fremden Bedingung gehangen. Jetzt ein eigener Block, ohne
fremden Helfer und ohne fremde Bedingung.
Gefunden hat es die Pruefung, weil sie die Leiste AM FELD sucht,
statt den Aufruf im Quelltext zu zaehlen. Sie sammelt seitdem auch
Skriptfehler ein -- ein ReferenceError ist immer ein Befund, auch
wenn man noch nicht weiss, was er anrichtet.
pruef-textform.mjs, 50 Aussagen:
- welche Seite das Modul braucht, wird ABGELEITET (beide
Richtungen: keine ohne, keine umsonst) -- 3 brauchen, 32 nicht
- 13 Regelfaelle im echten Browser an der echten Datei, davon
sechs, die NICHT gestaltet werden duerfen
- eine echte Nachricht wird zu <strong>/<em>/<u>/<s>
- Sicherheitsprobe: <b> und <img onerror> bleiben Text, nichts
wird ausgefuehrt -- und die echte Auszeichnung daneben wirkt
trotzdem (sonst waere nur bewiesen, dass gar nichts passiert)
- die Leiste legt Zeichen wirklich um und wieder ab
- Gegenproben fuer beide Richtungen
Nachbarn unveraendert gruen: pruef-chat-optik 45/0 (war 39 -- die
Antwortleiste kam dazu), pruef-aufgabenbrett 49/0, pruef-nachfrage
49/0, pruef-css-klassen 30/0, pruef-tippziele 11/0, pruef-meldungen
8/0.
|
||
 DogFatherGitandClaude Opus 5
|
7305f694d5 |
Die Stelle bleibt -- auch wenn man ueber die Kopfzeile zurueckgeht
Filipe, zum vierten Mal: "muss ich jedes mal wenn ich von einer seite
zurück scrolle immer wieder runter scrollen um weiter zu schauen und
das nervt."
DIE WIEDERHERSTELLUNG GAB ES SEIT DEM 20.09. -- sorgfaeltig gebaut,
mit Warten auf die nachgeladene Hoehe, mit Aufgeben nach drei
Sekunden, mit "wer selbst scrollt, gewinnt".
SIE LIEF NUR FAST NIE. Denn sie lief ausschliesslich bei
`navigation.type === "back_forward"`, also beim Zurueck-Knopf des
Browsers. Im Haus geht man anders zurueck: ueber die Kopfzeile ("TEAM
DOGI › HIGHLIGHTS"), und dort steht ein ganz gewoehnliches
`<a href="start.html">`. Fuer den Browser ist das eine Fahrt
VORWAERTS. Die Bedingung war also falsch -- und der else-Zweig
loeschte die eben gemerkte Stelle noch dazu.
IM KOPF DERSELBEN DATEI STAND DIE LOESUNG ALS ABSICHT: "Ein eigener
Merker faengt den Fall ab, dass der Zurueck-Knopf der Kopfleiste
benutzt wurde." Gebaut wurde er nie.
UND DESHALB HAT ES IN JEDEM TEST FUNKTIONIERT: Wer mit `goBack()`
prueft, prueft den einen Weg, den niemand geht. Gemessen am 21.09.:
ueber goBack sauber wiederhergestellt, ueber den Link in der
Kopfzeile oben gelandet. Gefunden hat es Filipes Bildschirmvideo --
17 Sekunden, drei Bilder, und der Ablauf war eindeutig.
Der Merker gibt es jetzt wirklich: Beim Klick auf einen EIGENEN
Zurueck-Weg (`.zurueck`, `.zurueck-knopf`) wird das Ziel notiert; wer
dort binnen 30 Sekunden ankommt, bekommt seine Stelle zurueck. Er
gilt fuer genau eine Ankunft -- wer die Seite eine Minute spaeter
normal oeffnet, faengt wieder oben an. Und NUR fuer diese zwei
Klassen, nicht fuer jeden Link: Sonst landete man beim Oeffnen eines
Brettes mitten darin.
Dazu der Rueckwaerts-Speicher des Browsers: Holt er eine Seite aus dem
Speicher, laeuft keine Zeile mehr, und unser `manual` verbietet ihm
gleichzeitig, die Stelle selbst wiederherzustellen. Ein `pageshow`
faengt das ab. Dieser Fall ist NICHT gemessen -- in Playwright greift
der Speicher nicht -- sondern aus der Spezifikation begruendet. Das
steht auch so im Kommentar, damit niemand spaeter glaubt, er sei
nachgewiesen.
NEU: pruef-stelle.mjs, 9 Pruefungen. Sie geht beide Wege zurueck --
Kopfzeile UND Browser -- und haelt ausdruecklich fest, dass der erste
KEIN "back_forward" ist. Dazu die Gegenprobe, dass eine frisch
geoeffnete Seite oben anfaengt: Ohne sie waere alles auch dann gruen,
wenn die Seite IMMER zur alten Stelle springt, und das waere
schlimmer als das Problem.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
9a30f9e304 |
Beim Antworten war das Schreibfeld einen Buchstaben breit
Filipes Bildschirmfoto: Die Antwortleiste nimmt die ganze Breite, und daneben steht ein Schreibfeld, in dem der Text senkrecht laeuft -- "defi / niti / v / hah / a". DIE ABSICHT STAND DA, DIE REGEL NICHT. `.chat__eingabe` ist eine Reihe OHNE Umbruch, und die Antwortleiste ist darin ein gleichberechtigtes Element -- sie nimmt ihren Platz NEBEN dem Schreibfeld. Das `margin-bottom: 8px` an der Leiste sagt seit jeher, dass sie darueber gehoert; durchgesetzt wurde es nie. Dazu stand am Schreibfeld `min-width: 0`. Das ist woertlich die Erlaubnis, auf nichts zu schrumpfen -- und genau das hat es getan. BEHOBEN MIT EINER REGEL, NICHT MIT EINER ZAHL: Die Zeile darf jetzt umbrechen, die Antwortleiste nimmt sich mit `flex-basis: 100%` immer die ganze Zeile, und das Schreibfeld hat eine Untergrenze von 8rem. Bricht es darunter, bricht lieber die Zeile um, als dass das Feld unbenutzbar wird. Gemessen an der schmalsten Breite, die das Haus kennt: 320 px: Schreibfeld 166 px, Antwortleiste 670 px (eigene Zeile) 430 px: Schreibfeld 216 px Vorher: rund 30 px. pruef-chat-optik prueft das jetzt mit -- und nicht nur die Breite des Feldes, sondern auch, dass die Leiste wirklich eine eigene Zeile nimmt. Ohne die zweite Zeile waere die erste nur zufaellig gruen, solange der zitierte Text kurz genug ist. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
314561fb64 |
Aufgaben an bestimmte Leute verteilen -- jetzt auch sichtbar
Filipe: "ich sehe noch immer nicht dass dogfather oder die rechte hand wenn sie aufgaben verteilen die spezifisch an leute verteilen können. mach das endlich auch weil das ist seeehr wichtig damit wir arbeiten können mit den leuten." GEMESSEN, BEVOR GEBAUT WURDE -- und die Messung hat zwei verschiedene Antworten gegeben: DogFather Feld sichtbar, vier Menschen in der Auswahl Rechte Hand Feld VERSTECKT, Auswahl leer Fuer ihn gab es die Zuteilung also, fuer sie nicht. Beides war falsch, jedes auf seine Art. 1. DIE RECHTE HAND KAM NIE AN DIE FELDER Das Absenden fragte `ich.darf_verteilen` -- das sagt der Server: Leitung ODER rechte Hand (seit 20.09.). Das ANZEIGEN fragte eine andere Menge aus bereiche.js: spicy, admin, manager. Zwei Bedingungen fuer dieselbe Sache, und eine davon war nie nachgezogen worden. Der Server haette ihre Zuteilung angenommen; sie konnte sie nur nirgends eintragen. Vier Stellen betroffen, und eine davon war gefaehrlich: Beim BEARBEITEN wurde `verantwortlich_id` nicht mitgeschickt -- die rechte Hand haette durch blosses Speichern die Zuteilung einer Aufgabe stillschweigend geloescht. Kein Fehler, keine Meldung, die Aufgabe gehoert danach niemandem. Alle vier fragen jetzt den Server. `LEITUNG.has(ich.rolle)` bleibt nur noch als Rueckfall hinter `??`, fuer den Fall einer aelteren Serverfassung. 2. UND FUER DOGFATHER LAG ES AM WORT Das Feld hiess "Verantwortlich" und stand auf "—". Das liest sich wie eine Eigenschaft der Aufgabe, nicht wie eine Frage an einen selbst. Es heisst jetzt "Wer macht es?", der leere Wert "— noch niemand —", und darunter steht, was die Auswahl bewirkt: Die Aufgabe steht bei ihm unter "Nur meine", und er bekommt eine Meldung. Eine Frage beantwortet man. Ein Strich uebersieht man. WARUM KEINE PRUEFUNG DAS GEFUNDEN HAT: Alle fragten den Server, und der war in Ordnung -- Rechte da, Leute da, Zuteilung wird angenommen. Eine Erlaubnis, an die niemand herankommt, sieht von dort aus wie eine Erlaubnis. pruef-verteilen liest deshalb jetzt auch den Quelltext der Oberflaeche: dieselbe Frage an beiden Stellen, und die Beschriftung muss eine Frage sein. Kommentare zaehlen dabei nicht mit -- beim ersten Lauf hat die Pruefung meine eigene Begruendung als Befund gezaehlt. pruef-verteilen 16/0 · pruef-aufgabenbrett in Ordnung Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
8a214ecd0e |
Keine Mischung mehr -- Team Dogi nur noch bei Team Dogi
Filipe: "ich will dass du im workspace alles von team dogi weg nimmst.
nur was ich im kalender eintrage soll ich im workspace sehen und im
team dogi. aber die kacheln von team dogi soll ich nur bei team dogi
sehen und die von workspace nur bei workspace bitte. ich will keine
mischung mehr von kacheln. wie gesagt nur die der kalender soll
verbunden sein von dogfather sonst nichts."
GEMESSEN, WIE SCHLIMM ES WAR: Auf der Agenturadresse bekam DogFather
0 eigene Kacheln ueber die Schnittstelle und 17 fremde -- Dein Team,
Ideen-Board, Rueckmeldung, Wer sieht was, Entwicklung, Werdegang,
Talente und den ganzen Treff samt Moderation. Zwei Betriebe auf einer
Seite.
Das Bittere daran: Dieselbe Datei hatte den Fehler fuer die ANDERE
Richtung am 10.09. schon erkannt und behoben ("Fuenfundzwanzig
Kacheln, von denen zwei Drittel Creator, Scouts und Agentur betreffen,
waeren dort Fenster in ein Haus, in dem er gerade nicht ist"). Nur
andersherum stand es weiter so.
DIE AUSNAHME BRAUCHTE NICHTS: Nachgemessen filtern die Terminabfragen
in workspace-kalender.js NICHT nach Haus. Was er eintraegt, steht
ohnehin auf beiden Adressen. Die Verbindung, die er will, existierte
schon -- sie musste nur nicht zerschnitten werden.
STATT SIEBZEHN BRETTERN STEHT DORT EINE TUER. Ohne sie waere von der
Agenturadresse aus kein Weg mehr zu Team Dogi sichtbar; er muesste die
Adresse tippen. Das ist die Sorte Sackgasse, die dieses Haus nicht
baut. Eine Tuer ist keine Mischung: Sie zeigt kein Brett, sie geht
hinueber. Und sie kommt vom Server, nur fuer `admin` -- in keiner
ausgelieferten Datei steht sie.
MEIN ERSTER ENTWURF GAB SIE AUCH DER RECHTEN HAND UND DER MODERATION.
pruef-modi-checkliste hat es sofort gemeldet: "Modi bekommt 1
Zusatzkachel(n), erwartet keine". Wer NUR zu Team Dogi gehoert, hat
auf der Agenturadresse nichts zu suchen -- die Tuer waere dort seine
einzige Kachel gewesen, also eine Seite, die aus nichts als einem
Ausgang besteht.
VIER PRUEFUNGEN VERLANGTEN DANACH DIE ALTE WELT. Keine davon war ein
Mangel; alle vier haben am falschen Ort gesucht:
pruef-haus-trennung verlangte woertlich, dass die Team-Kachel AUCH
auf der Agenturadresse steht. Sie prueft jetzt die Trennung in
beide Richtungen -- kein Brett von Team Dogi drueben, aber die
eine Tuer -- und leitet die Namen aus der Antwort von crew. ab,
statt sie abzuschreiben.
pruef-start-ansicht zaehlte acht Gruppennamen in fester
Reihenfolge. Gemeint war eine Ordnung ("die Community steht ganz
unten, denn dort stehen Namen und Saetze von Zuschauern"), und
die wird jetzt als Regel geprueft -- bedingt, mit drittem Ausgang
auf Adressen, wo es diese Gruppen gar nicht gibt.
pruef-treff und pruef-rueckmeldung fragten ueber die Agenturadresse
nach Brettern, die dort nicht mehr stehen. Sie fragen jetzt dort,
wo diese Bretter zuhause sind.
EINE HALBE STUNDE WAERE DABEI FAST VERLOREN GEGANGEN: `fetch` kann den
Host-Kopf nicht setzen -- er ist ein verbotener Kopfzeilenname und
wird STILLSCHWEIGEND verworfen. Die Anmeldung ueber die Crew-Wand
genuegt nicht; jede einzelne Abfrage braucht die Adresse. Deshalb geht
die Messung jetzt ueber http.request, so wie es `anmelden()` in
derselben Datei laengst tut.
pruef-haus-trennung 74/0 · pruef-modi-checkliste 75/0 · pruef-treff
72/0 · pruef-rueckmeldung 30/0 · pruef-start-ansicht 153/0 ·
pruef-haus-seiten 34/0 · pruef-entwicklung 46/0 · pruef-befinden
113/0 · pruef-rechte-umstellen 46/0
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
a39d02da5a |
Ein Vorschlag ist ein Vorschlag -- DogFather entscheidet
Filipe: "bei diesen vorschlägen ist sehr wichtig dass immer wenn es um
was geht was ich machen soll oder so dass immer erwähnt wird dass ich
immer am ende entscheide ob ich was mache oder nicht. ich kann immer
annehmen oder ablehnen. über all auf der website soll dass bei den
vorschlägen erwähnt werden."
WARUM DAS MEHR IST ALS HOEFLICHKEIT: Auf den Karten stehen Saetze wie
"Was soll DogFather im naechsten Stream unbedingt machen?" oder
"Welches Spiel soll DogFather mal ausprobieren?". Wer so gefragt wird,
schreibt etwas hin -- und rechnet damit. Passiert es dann nicht, sieht
es aus wie ein gebrochenes Versprechen, obwohl nie eines gegeben
wurde. Der Satz verhindert genau diese Enttaeuschung vorher, statt sie
hinterher zu erklaeren.
GEMESSEN, BEVOR GEBAUT WURDE -- und die Messung hat den Auftrag
groesser gemacht: Die Vorschlagskarten sieht NUR das Team. Die
Community bekommt sie mit 404 gar nicht; sie liest nur, was daraus auf
dem Brett landet. Ein Satz allein ueber den Karten haette also genau
die Leute nicht erreicht, um die es geht.
Deshalb steht er jetzt an ZWEI Stellen, aus EINER Quelle:
- ueber den Vorschlagskarten (das Team beim Auswaehlen)
- auf dem Brett selbst, unter der Ueberschrift (die Community beim
Lesen)
WELCHE BRETTER IHN TRAGEN, WIRD ABGELEITET: genau die, fuer die es
ueberhaupt Vorschlaege gibt. Eine zweite Liste "Bretter mit Hinweis"
waere die naechste, die altert -- wer ein Brett in den Katalog
aufnimmt, denkt nicht daran, es auch dort einzutragen. Auf einem Brett
fuer Termine oder Dateien steht er nicht: Ein Hinweis, der ueberall
steht, wird nirgends gelesen.
EINMAL UND NICHT AUF JEDER KARTE. Vier Karten nebeneinander mit
viermal demselben Satz liest niemand mehr. Er steht ueber dem Block,
wo man ihn liest, bevor man die erste antippt.
Der Text selbst steht an genau einer Stelle im Haus
(VORSCHLAG_HINWEIS), und pruef-vorschlaege haelt beide Anzeigeorte
dagegen -- mit Gegenprobe, dass ein Brett ohne Vorschlaege ihn NICHT
traegt.
pruef-vorschlaege: 28 Pruefungen, 0 Fehler (war 21)
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2c2c42d4aa |
Drei rote Zeilen im Werdegang -- alle drei verlangten Altes
Keine davon war ein Mangel an der Seite. Alle drei verlangten einen Zustand, den Filipe am 19.09.2026 ausdruecklich geaendert hat. 1. "alphabetisch (Rieke, Diene)" Filipe am 19.09.: "die reihenfolge der listen soll immer angepasst sein hatten wir doch schon. die rechte hand rolle immer zuerst und dan die modis." Der Server sortiert seitdem nach ROLLEN_SORTIERUNG, dann nach Namen -- die Pruefung verlangte weiter rein alphabetisch. Sie prueft jetzt dieselbe Ordnung, abgeleitet aus derselben Konstante wie der Server. Wer dort eine Rolle verschiebt, verschiebt sie hier mit. Was bleibt, ist die eigentliche Aussage: sortiert wird nach etwas, das nichts ueber die Person sagt -- eine Liste nach Aktivitaet waere eine Rangliste mit anderem Namen, eine nach Rolle ist es nicht. 2. "jede Zelle traegt ihr Zeichen, nicht nur ihre Farbe" Im Quelltext der Seite steht seit dem 19.09. woertlich: "Leer ist jetzt WIRKLICH leer -- kein Zeichen, dafuer ein gestrichelter Rahmen. Man sieht das Fehlen, statt es zu lesen." Die Pruefung verlangte das Gegenteil. Gemessen werden jetzt beide Haelften, und die zweite ist die wichtigere: Stuende in einer leeren Zelle doch ein Zeichen, waere "noch nichts gesetzt" nicht mehr von "gesetzt" zu unterscheiden -- und das faellt beim Hinsehen nicht auf, weil es nach Inhalt aussieht. 3. "unter dem Diagramm steht eine Legende (7 Eintraege)" Hier stand `=== 2`. Inzwischen sind es sieben: zwei fuer die Bewegungsrichtung, vier Stufen und der leere Zustand. Wieder eine Rechnung von gestern. Gefragt wird jetzt, was die Legende leisten muss: zu JEDER Stufe, die der Server kennt, ein Eintrag -- und einer fuer den leeren Zustand. Kommt eine Stufe dazu, waechst die Erwartung mit. ZWEIMAL HAT MICH DABEI DIE ZAHL IN DER BEDINGUNG GERETTET. Erst fragte ich die Stufen an der Liste ab -- die liefert sie gar nicht, sie stehen an der einzelnen Karte. Ohne `stufenSoll.length > 0` waere der Vergleich gegen eine leere Liste gelaufen und haette "die Legende nennt jede davon" bestaetigt, ohne eine einzige zu kennen. Dieselbe Zeile hatte zuvor schon in pruef-modi-checkliste einen stillen Totalausfall verhindert. pruef-werdegang: 103 Pruefungen, 0 Fehler (war 95, davon 3 rot) Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
9d4a40ff58 |
Zwei Pruefungen waren rot, weil etwas richtig gemacht wurde
pruef-auskunft und pruef-treff-werkzeuge -- beide bestraften eine Verbesserung. Das ist die unangenehmste Sorte roter Pruefung: Wer sie zweimal so erlebt, faengt an, rote Laeufe zu erklaeren statt sie zu lesen. 1. "DIE COMMUNITY HAT KEINEN STECKBRIEF" So stand es woertlich in der Bedingung. Am 19.09. hat Filipe genau das Gegenteil entschieden -- "jeder soll ein steckbrief haben, jeder der ein account hat ... jeder soll genau wie ich foto und so hinzufuegen koennen" -- und die Community hat seitdem einen. Was die Zeile schuetzen wollte, steht in ihrem eigenen Kommentar: "Ohne die zweite Stelle haette die Gruppe mit den wenigsten Rechten auch dieses nicht -- und sie ist die groesste." Die Sorge ist richtig und hat mit der Anzahl der Seiten nichts zu tun. Die Frage lautet: KOMMT JEDE ROLLE AN IHRE AUSKUNFT? Genau das wird jetzt gemessen -- welche Seiten den Knopf tragen, aus den Dateien gelesen statt aufgezaehlt, und ob jede der acht Rollen mindestens eine davon erreichen darf, aus der Rechtetafel gelesen statt angenommen. Mit Gegenprobe (eine erfundene Rolle erreicht keine) und mit der Zahl in der Bedingung. 2. "DIE COMMUNITY STEHT BEI 8 VON 33" Hier stand `community.seiten < 5`. Die Zahl stimmte an dem Tag, an dem sie geschrieben wurde. Seither hat der Treff eigene Seiten bekommen -- Regeln, Steckbrief, Hilfe, Draussen -- und die Community steht bei acht. Die Pruefung war rot, WEIL der Treff gewachsen ist. Dieselbe Fehlerklasse wie die Umbruchschwelle vom 06.09.: Wer eine Zahl notiert, notiert einen Zustand, keine Regel. Gemeint war eine ORDNUNG: Ein Mitglied sieht weniger als die Moderation, die weniger als die rechte Hand, die weniger als DogFather. Nachgemessen 8 / 19 / 25 / 32 von 33. Geprueft wird jetzt das Verhaeltnis -- und zusaetzlich, dass die Community das Minimum ueber ALLE acht Rollen ist, nicht nur in dieser Kette. Das bleibt richtig, wenn der Treff weiterwaechst, und faellt sofort auf, wenn jemand die Reihenfolge versehentlich umdreht. pruef-auskunft 46/0 (war 46, davon 1 rot) pruef-treff-werkzeuge 73/0 (war 70, davon 1 rot) Damit sind alle vier Pruefungen gruen, die heute frueh rot waren. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
95d753791d |
Die dritte Fassung derselben Pruefung -- diesmal ohne Liste
pruef-modi-checkliste war rot: "und alle stehen in einer Gruppe fuer
euch beide -- ausser: Der Treff, Treff-Chat, Anschlagbrett, ..."
DIE URSACHE WAR EINE GEPFLEGTE LISTE, zum zweiten Mal. Erst stand dort
`["Team Dogi"]`, dann `["Team Dogi", "Entwicklung & Nachwuchs"]`, und
daneben der Satz: "Kommt eine dritte Gruppe, wird diese Zeile rot. Das
ist Absicht." Am 21.09. kam sie -- der Treff -- und nichts daran war
falsch.
WARUM DIE FRAGE SELBST NICHT MEHR PASSTE: `bereiche_zusatz` hiess
einmal "die eine Kachel, die nur ihr zwei habt". Seit es den Treff
gibt, steht dort fuer DogFather auch der GANZE Treff -- zehn Kacheln
in der Gruppe "Community", die die rechte Hand, die Moderation und
jedes Mitglied ebenso sehen. Das ist der zweite Haushalt, kein Mangel:
Fuer ihn ist der Treff eine Zugabe, fuer sie das Zuhause.
MEIN ZWEITER VERSUCH WAR SCHLECHTER ALS DER ERSTE, und gefangen hat
das nur die Gegenprobe. Ich wollte die verbotenen Gruppen MESSEN statt
sie aufzuzaehlen: "welche Gruppen sieht ein Creator, welche Spicy
Media?" Nachgemessen sind das in dieser Pruefdatenbank NULL -- beide
haben dort gar keine Kacheln. Die Bedingung waere damit immer wahr
gewesen, und aus einer roten Pruefung waere eine gruene geworden, die
nichts mehr misst. Gefangen hat es allein die Zahl in der Bedingung
(`sehenAlle.size >= 2`). Ohne sie haette ich eine Pruefung stillgelegt
und es fuer eine Reparatur gehalten.
JETZT WIRD NACH DER KACHEL GEFRAGT, NICHT NACH IHRER GRUPPE: Gibt es
unter den Zugaben mindestens eine, die sonst NIEMAND hat? Gemessen am
Ziel, gegen Modi, Spicy Media und Creator zusammen. Das ist die
urspruengliche Aussage, und sie altert nicht -- die Gruppe war immer
nur ein Hilfsmerkmal.
Die alte Gruppen-Zeile steht nicht mehr daneben. Sie waere jetzt immer
wahr, und eine Zeile, die immer bestaetigt, bestaetigt nichts.
Die Meldung sagt seitdem auch etwas:
DogFather davon 3, die sonst niemand hat (Dein Team, Wer sieht
was, Talente), erwartet mindestens eine
Creator davon 0, die sonst niemand hat, erwartet keine
75 Pruefungen, 0 Fehler (war 70, davon 2 rot)
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
25b5cf6224 |
"Unveraenderlich" stand auch auf Adressen, die sich aendern
Beim Nachmessen der Crew-Sperre von vorhin: Der Ursprung lieferte korrekt 404 und eine bereinigte gate.css -- Cloudflare lieferte weiterhin die ALTE Fassung, 27 806 Byte, `cf-cache-status: HIT`. DIE URSACHE STAND IM EIGENEN KOMMENTAR. In index.js hiess es: "`originalUrl` steht hier nicht zur Verfuegung -- geprueft wird deshalb die Dateiart." Nachgemessen stimmt das nicht: `res.req .originalUrl` ist da und liefert "/start.html?v=123". Die Annahme war nie geprueft worden, und aus ihr folgte eine Zusage, die das Haus nicht halten kann: JEDE CSS- und JS-Datei ging mit `max-age=31536000, immutable` hinaus -- auch unter ihrer Adresse OHNE Stempel. "immutable" heisst woertlich: Der Inhalt unter DIESER Adresse aendert sich nie. Fuer `gate.css?v=...` stimmt das, der Name wechselt ja mit dem Inhalt. Fuer `gate.css` ist es falsch -- und dort haette die alte Fassung ein Jahr im Zwischenspeicher gelegen, waehrend der Server laengst etwas anderes sagt. Ein Zwischenspeicher, der etwas Falsches zeigt, ist schlimmer als gar keiner: man glaubt ihm. Jetzt haengt die Zusage an der Bedingung, die sie traegt. Mit Stempel bleibt alles wie bisher -- die Seiten rufen ohnehin immer `?v=...` auf, dort kostet es nichts. Ohne Stempel wird nachgefragt. Die oeffentliche Seite benutzt ebenfalls `?v=` (mit Buchstabe am Ende); geprueft wird nur, OB einer da ist, nicht wie er aussieht. DIESELBE SORTE FEHLER GLEICH NEBENAN: pruef-zwischenspeicher hat einen Abschnitt "Was einen Stempel traegt, darf liegenbleiben" -- und rief die Dateien OHNE Stempel ab. Auch hier beschrieb der Text etwas, das der Code nicht tat. Er liest den Stempel jetzt aus der Seite und misst damit genau die Adresse, die ein Browser anfordert. Dazu vier neue Zeilen fuer den umgekehrten Fall, mit Gegenprobe an derselben Datei -- sonst waere "ohne Stempel: no-cache" auch dann gruen, wenn ALLES auf no-cache stuende, und jeder Seitenaufruf waere unnoetig langsam. UND MEIN EIGENER FEHLER VON GESTERN, behoben: Die Stempelpruefung verglich seit dem 20.09. den Stempel mit dem ZEITPUNKT des letzten Commits an assets/. Das kann gar nicht aufgehen -- der Stempel wird immer VOR dem Committen gezogen, die Commit-Zeit ist also immer die juengere. Stempeln um 12:59 und Committen um 13:00 genuegte fuer einen Fehlalarm; heute ist genau das passiert. Gefragt wird jetzt die REIHENFOLGE der Commits, die hat keine Uhr: Liegt der letzte Commit an den HTML-Seiten (dort steht der Stempel) auf oder nach dem letzten an assets/? `merge-base --is-ancestor` beantwortet das ohne Zeitstempel. Mit Gegenprobe ueber das Elternteil -- und mit drittem Ausgang, wenn es keines gibt. pruef-zwischenspeicher: 27 Pruefungen, 0 Fehler (war 22, davon 2 rot) NOCH OFFEN und nur von Filipe zu machen: Cloudflare haelt die alten Fassungen unter den stempellosen Adressen weiter im Zwischenspeicher. Der Ursprung ist sauber; geleert werden muss der Rand einmal von Hand. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ea8ceaa539 |
Das Farbhaus von Team Dogi lag oeffentlich im Netz
Ausgeloest von pruef-modi-wortleck, die seit Tagen rot war: "24
Fundstellen -- der verborgene Zugang waere damit auffindbar." Die
erste Frage war, ob sie recht hat. Gemessen: ja, und schlimmer als
gedacht.
WER DIESE DATEIEN BEKOMMT: Nicht nur Kollegen. `curl` ohne jeden Keks
auf workspace.dogfather-universe.com liefert die Skripte und
Stilvorlagen des Arbeitsplatzes mit HTTP 200 -- fuer jeden im Netz
lesbar.
DARUNTER crew-haus.css, 27 806 Byte, das ganze Farbhaus von Team Dogi
samt seiner Kommentare. In deren Kopf stand seit dem 10.09. woertlich
"Diese Datei wird NUR auf crew.dogfather-universe.com ausgeliefert."
Das war eine Behauptung, keine Tatsache: Die Weiche biegt `haus.css`
auf diesen Namen um, wer den Namen direkt nannte, ging an ihr vorbei.
Ein Kommentar, der eine Absicht beschreibt, erfuellt sie nicht.
Zwei Stellen im Haus haben sich damit widersprochen -- die Datei sagte
"nur auf crew.", pruef-crew-adresse verlangte ausdruecklich das
Gegenteil ("sie ist kein Geheimnis"). Durchgesetzt war die offene
Fassung. Filipe hat am 21.09. entschieden: zusperren. Die alte
Begruendung dagegen war die Sorge, eine Sperre koenne die Pruefung
blind machen -- die ist jetzt beantwortet statt vermieden: Jeder
Eintrag der Tafel wird in BEIDE Richtungen gemessen, und dass die
Umbiegung von `haus.css` auf crew. weiterhin greift, ebenfalls.
DIE ADRESSE WAR DAS EIGENTLICHE GEHEIMNIS, nicht das Wort. Die
Rollennamen stehen auf der Zugangswand von Team Dogi ohnehin offen --
so gewollt. WO sie liegt, stand dagegen im Klartext in gate.css,
gate.js und crew-haus.css, alle drei oeffentlich abrufbar. Jetzt steht
sie in keiner ausgelieferten Datei mehr.
DIE PRUEFUNG SELBST HATTE DREI MAENGEL:
1. Sie kannte die Mehrzahl nicht. `\bmodi\b` fand "ein Modi", nicht
"die Modis" -- 23 weitere Stellen, darunter der Satz "Fuer die
rechte Hand und die Modis gibt es dort den stillen Zugang". Also
genau die Auskunft, die sie verhindern soll, in der Form, die sie
nicht sah.
2. Ihre Ausnahmeliste war abgeschrieben. Sie nannte eine Datei; die
zweite, die der Server auf crew. begrenzt, haette sie nie
erfahren. Ausgenommen ist jetzt genau das, was der Server auch
durchsetzt (GEHOERT_ZU_ADRESSE) -- kein Muster, sondern die
Durchsetzung selbst.
3. Sie mahnte 45 Kommentare an. Filipes Entscheidung: in Kommentaren
ja, in Code und sichtbaren Texten nein. Rot, das immer da ist,
wird ueberlesen -- und dann faengt sie auch den echten Fall nicht.
Dafuer neu: helfer-ohne-kommentar.mjs, ein Zerleger, der Kommentare
zeichengenau durch Leerzeichen ersetzt, ohne Zeichenketten,
Vorlagen oder Suchmuster zu beschaedigen. KEIN Suchausdruck -- genau
daran ist am 20.09. die Portumstellung gescheitert, mit gueltigem
JavaScript ohne das Feld `port`. Dreizehn Proben in beide Richtungen
beweisen, dass er weder zu viel noch zu wenig wegnimmt; ein Zerleger,
der zu viel nimmt, macht die ganze Pruefung STILL gruen.
Von 45 blieben damit drei echte, alle behoben:
- daten.modis -> daten.leute (Feldname in der Auskunft, also Code)
- zwei Saetze, die Menschen lesen, auf "die Moderation" umgestellt --
fuer jemanden, der neu im Treff ist, sogar klarer
Nebenbei, beim selben Durchgang gefunden und geschlossen:
- teamlage.js fiel auf einen Rollennamen zurueck. Nachgemessen: Die
Stilvorlage kennt zu dieser Karte gar keine solche Regel -- der
Rueckfall hat nie etwas bewirkt und nur das Wort ausgeliefert.
- werdegang.js fuehrte die Saetze ueber den Rollengruppen selbst,
mit den Rollennamen als Schluessel. Der Kommentar daneben
behauptete sogar, sie seien "abgeleitet, nicht abgeschrieben".
Sie kommen jetzt vom Server, und pruef-werdegang misst, dass
jede Gruppe ihren eigenen behaelt.
pruef-modi-wortleck 8/0 (war 5, davon 1 rot)
pruef-crew-adresse 144/0 (war 135)
pruef-werdegang 98 statt 95 Pruefungen, dieselben 3 alten Fehler
pruef-team-ampel 32/0, pruef-team-stufen 28/0, pruef-hilfe 84/0
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
eca9aed279 |
Der Treff sagt jetzt, ob gerade gestreamt wird
Filipe zu dieser Seite: "mach was anderes daraus oder mach es viel krass und geiler ... erstell was was mich von den socken schmeisst. es soll wirklich sogar ein wow effekt fuer die community ergeben." Dazu die eine Auflage: die Kachel bleibt. WAS SIE WAR: zwei Karten mit zwei Adressen. Sauber gebaut, richtig beschriftet -- und niemand kam ein zweites Mal wieder. Wer im Treff ist, kennt die Website. Den Rabattcode merkt man sich beim ersten Mal. DIE FRAGE, DIE WIRKLICH JEMAND HAT, IST EINE ANDERE: Laeuft er gerade? Und wenn nicht -- wie lange noch? Die Antwort kennt das Haus seit dem 20.08.: postfach.dogfather-universe.com/live-status, derselbe Dienst, von dem der oeffentliche Streamplan lebt. Im Treff gab es sie bisher nicht. Jetzt steht oben ein Puls: ein Ring, der sich ueber den Tag bis zur naechsten Sendezeit fuellt, darin der Countdown auf die Sekunde. Sendet er, wird die Karte rot, atmet im Ruhepuls und traegt den Titel des Streams plus einen Weg hin. Darunter die drei Accounts und -- wenn die Verwaltung eines eintraegt -- das besondere Event mit eigener Uhr. DREI AUSGAENGE, NICHT ZWEI. Das ist der eigentliche Unterschied zur oeffentlichen Seite: streamplan.js faengt dort jeden Fehler ab und setzt `istLive = false`. Aus "wir konnten nicht fragen" wird "er sendet nicht" -- und wer das liest, macht die Seite zu und verpasst den Stream. Der Dienst liefert `autoHealthy` sogar mit; gelesen wird es draussen nicht. Hier schon: Bei einer Stoerung steht "Konnten wir gerade nicht nachsehen", dazu der Hinweis, dass das NICHT heisst, dass kein Stream laeuft. Der Countdown laeuft dabei weiter -- er braucht kein Netz. NICHTS IST ABGESCHRIEBEN. Die drei Accounts kommen ueber /workspace/api/draussen aus derselben KANAELE-Liste, an der die Aufgabenverteilung haengt; die Adressen baut der Steckbrief. Die Sendezeit steht im Server, und pruef-draussen haelt sie gegen FIX_STUNDE in streamplan.js -- verschiebt jemand den Termin und aendert nur einen Ort, wird die Pruefung rot. Gemessen, bevor gebaut wurde: der Dienst antwortet und meldet sich gesund, CORS steht auf *, und `connect-src` der Treff-Seiten fuehrt postfach bereits. Ohne das Letzte waere der Abruf still blockiert worden und haette ausgesehen wie ein toter Dienst. Die Kachel heisst jetzt "Draussen" statt "Unsere Seiten" -- drei Dinge statt zwei Adressen. Ziel und Datei bleiben gleich. pruef-wege-nach-draussen schreibt den Namen nicht mehr ab, sondern verlangt, dass Kachel und Seitenueberschrift uebereinstimmen. Zwei Namen fuer denselben Ort waren schon einmal ein echter Fehler. Nebenbefund, dort gleich behoben: Dieselbe Pruefung verlangte, dass die Community-Kacheln restlos in Dreierreihen aufgehen -- obwohl ihr eigener Kommentar sagt, eine freie Zelle am Ende sei erlaubt. Sie war rot bei einwandfreiem Raster. Gemessen wird jetzt, was wirklich schiefgeht: eine doppelt breite Kachel, die in der letzten Spalte beginnt und die Zelle davor leer laesst. Mit Gegenprobe. pruef-draussen: 39 Pruefungen, alle vier Lagen im echten Browser -- die Stoerung wird dafuer absichtlich hergestellt. pruef-wege-nach-draussen: 67 statt 66, keine Fehler mehr. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
9a71f3a242 |
Eine Null zu viel -- HasiDog-Videos waeren abgelehnt worden
In KANAELE stand "@hasidog00804". Der Account heisst "@hasidog0804". Nachgemessen bei TikTok selbst: der richtige hat 65 Follower, der andere liefert "Couldn't find this account". Das war nicht kosmetisch. `kanalVonHandle` ordnet ein hochgeladenes Video ueber genau diesen Text einem Kanal zu. Ein echtes HasiDog-Video waere mit 403 abgelehnt worden -- und die Begruendung haette gelautet: "ist keiner deiner Kanaele. Moeglich sind: @dogfather0804, @hasidog00804, @dogis.modi.gang." Eine Sackgasse, die zusaetzlich eine Adresse nennt, die es nicht gibt. WARUM ES KEINE PRUEFUNG GEFUNDEN HAT: pruef-kanalzeile und pruef-teilen hatten denselben Handle abgeschrieben. Zwei Abschriften desselben Tippfehlers bestaetigen sich gegenseitig -- beide waren gruen. Sie leiten ihn jetzt aus KANAELE ab und koennen ihn damit gar nicht mehr eigenstaendig falsch haben. Gefunden hat es ein Vergleich: Die oeffentliche Website verlinkt dieselben Accounts und hatte die richtige Schreibweise. Genau das ist jetzt Abschnitt 7 von pruef-kanaele -- alle Handles muessen auch draussen vorkommen, mit Gegenprobe, dass eine falsche Adresse durchfaellt. Ohne Netz, damit eine Stoerung bei TikTok nicht zu einem roten Alarm im Haus wird. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
2a6008d699 |
Versionsstempel auf 202609211145
chat.css hat sich geaendert. Ohne den Stempel behaelt jeder Browser seine alte Kopie, und die groesseren Farbkacheln kaemen bei niemandem an. 505 Verweise in 37 Dateien. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
8bd6474844 |
Die Farbkacheln im Chat waren mit dem Daumen zu klein
30x30 ist mit der Maus bequem und am Handy zu klein; die Grenze im Haus sind 44px. Angehoben wird nur auf Fingergeraeten (pointer: coarse), sonst staende der Knopf am Rechner unnoetig gross neben einer Zeile, die selbst nur 30 hoch ist. Sichtbar bleibt die Kachel gleich gross -- gewachsen ist die Flaeche, die den Finger annimmt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
e12074c32c |
Der Stempel wird mit der Uhr verglichen, nicht mit dem Commit
pruef-zwischenspeicher verlangte, dass derselbe Commit die Stilvorlage UND die HTML aendert. Das ist der Normalfall, aber nicht die Regel: Wird der Stempel in einem Folge-Commit nachgezogen, kommt die Aenderung genauso an -- die Pruefung blieb trotzdem rot und beschuldigte einen Commit, an dem nichts falsch war. Eine rote Zeile, die rot bleibt, bringt Menschen dazu, Rot zu uebersehen. Verglichen wird jetzt der Stempel selbst mit dem Zeitpunkt der letzten Aenderung an assets/. Ein Stempel, der juenger ist, wurde danach gezogen -- egal in welchem Commit. Das ist strenger als vorher, nicht lockerer: Eine HTML-Aenderung aus einem ganz anderen Grund (ein Tippfehler im Text) haette die alte Pruefung besaenftigt, ohne dass der Stempel gezogen wurde. Dazu ein Fund am Rand: anruf-probe.html trug ein handgeschriebenes ?v=202609191018 am Manifest-Link. Kein Werkzeug pflegt diese Stelle, keine der 20 anderen Seiten hat so etwas -- sie waere still veraltet. Entfernt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
200728c8e7 |
Der leere Ring zeigte "100 %" -- das las sich wie "alles geschafft"
Die Pruefung verlangte prozent === 100, wenn gar nichts zu tun war. Der Gedanke war richtig (ein leerer Ring darf nicht wie Versagen aussehen), die Umsetzung nicht: Gelesen wird zuerst die Zahl in der Mitte, und "100 %" heisst fuer jeden Menschen "fertig". Am ersten Tag, ohne eine einzige Aufgabe, stand das als groesstes Element der Startseite. Seit dem 19.09. steht dort ein Strich. Ein Anteil von nichts ist keine Null und keine Hundert, sondern nicht definiert. Die Pruefung fragt jetzt danach -- und damit gleichzeitig schaerfer: Solange gar keine Zahl dasteht, kann dort auch nicht versehentlich der Uhrzeitwert stehen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
782a9116f2 |
Zwei Pruefungen rechneten in UTC und schlugen abends falschen Alarm
pruef-zeitraum und pruef-highlights bildeten ihren Tagesstempel mit toISOString(). Das ist UTC. Zwischen 22:00 und Mitternacht deutscher Zeit ist das schon der naechste Tag -- die Pruefungen verglichen dann einen Eintrag von heute mit dem Datum von morgen und meldeten einen Fehler, wo keiner war. Der Zeitraum-Filter im Haus rechnet richtig; er benutzt tagLokal() aus helfer-zeit.mjs. Nur die Pruefungen darueber hatten ihre eigene, falsche Rechnung. Jetzt benutzen sie denselben Helfer wie der Code, den sie pruefen -- damit koennen die beiden gar nicht mehr auseinanderlaufen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
acd3e1f385 |
Zwei Tabellenumbauten haetten 15 Spalten still geloescht
`personen` und `aufgaben` wurden beim Freischalten eines neuen
CHECK-Werts von Hand neu gebaut -- die Spaltenliste stand zweimal im
Code abgeschrieben (CREATE und INSERT). Gemessen:
aufgaben: 23 Spalten, 18 aufgezaehlt -> vorlage, kategorie,
aus_eintrag_id, aufwand, aus_punkt weg
personen: 19 Spalten, 9 aufgezaehlt -> bild, ueber_mich, tiktok,
instagram, youtube, twitch, chat_kachel, code_kennung,
stufe, alter_bestaetigt_am weg
Bei `personen` haengen daran die Profilfotos und die
Altersbestaetigung: Alle waeren nach einem Rueckspielen still wieder
unbestaetigt gewesen, ohne Fehlermeldung, bei unveraenderter
Zeilenzahl. Die Zeilenzaehlung, die als Sicherung gedacht war, kann
einen Spaltenverlust gar nicht sehen.
Es ist derselbe Fehler wie am 11.09. an der Eintragstabelle (24 hinein,
21 heraus). Damals wurde `checkListeErweitern` gebaut, das die Spalten
aus PRAGMA table_info ABLEITET -- eine Liste, die niemand pflegt, kann
nicht veralten. Diese beiden Bloecke waren aelter und wurden bei der
Umstellung uebersehen. Jetzt gehen alle 16 Umstellungen denselben Weg,
kein Neubau zaehlt mehr von Hand.
Auf dem laufenden Server ist nichts verloren (24 Spalten, CHECK
vollstaendig) -- die Falle stand fuer den Tag, an dem jemand eine
Sicherung zurueckspielt.
Gefunden hat es nicht das Lesen, sondern pruef-abbrechen: Sie baut
absichtlich eine ALTE Datenbank und liess die Umstellung darauf laufen
-- danach meldete der Server "no such column: a.aufwand".
Neu: pruef-umstellung.mjs (18 Pruefungen) haelt die Fehlerklasse
dauerhaft zu. Sie baut eine echte alte Datenbank mit gefuellten
Spalten, laesst die Umstellung laufen und zaehlt danach Spalten UND
Inhalte. Mit Gegenprobe: ein absichtlich fehlerhafter Umbau zeigt, dass
die Zeilenzahl dabei stimmt und trotzdem Daten fehlen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
0082c74bd7 |
Versionsstempel nachgezogen
pruef-zwischenspeicher hat es gemeldet: Der Commit davor hat Stilvorlagen und Skripte geaendert, aber keine HTML -- damit bleibt der Verweis `?v=...` stehen, der Browser haelt seine alte Kopie fuer aktuell (ein Jahr, unveraenderlich), und die Reparatur kaeme bei niemandem an. Genau der Fall, fuer den die Pruefung gebaut wurde: Ein Deploy, der fehlerfrei durchlaeuft und trotzdem nichts ausliefert. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
67a0eb8717 |
DogFather konnte einen zweiten DogFather nicht mehr herabstufen
Gefunden beim Durchsehen der schnellen Pruefungen: pruef-haus-trennung stand auf 60 ok / 6 Fehler. Drei Ursachen, eine davon ein echter Rueckschritt von gestern. --- 1. DER RUECKSCHRITT --------------------------------------------- In darfRolleAendern stand seit gestern: if (person.rolle === "admin") return ziel.rolle !== "admin"; Das macht aus "DogFather ist nicht mehr VERGEBBAR" ein "an einem DogFather ist nichts mehr zu aendern". Ein zweiter Zugang liess sich damit nie wieder zuruecksetzen -- er waere fuer immer DogFather geblieben. Die Pruefung sagte es woertlich: "solange es zwei gibt, darf einer wechseln (403)". Die beiden echten Gefahren haengen woanders und bleiben unberuehrt: Niemand KANN 'admin' vergeben, und der LETZTE DogFather laesst sich nicht herabstufen. --- 2. ZWEI SCHLOESSER FUER DIESELBE TUER --------------------------- Ich hatte gestern `rollenZumAendern` mit 403 VOR die vorhandene Pruefung gesetzt, die mit 400 "Unbekannte Rolle." antwortet. Damit war die Luecke wieder offen, vor der der Kommentar vom 17.09. direkt daneben warnt: Zwei verschiedene Antworten -- "gibt es nicht" gegen "darfst du nicht" -- verraten beim Durchprobieren, WELCHE Rollen existieren. Jetzt eine Regel an einer Stelle. `darfAnlegen` ist dort raus, weil Vergeben und Anlegen seit gestern verschiedene Dinge sind. Gemessen: admin anlegen = aendern (sieben Rollen) spicy anlegen = aendern (vier) hand anlegen = — aendern = modi, gast manager anlegen = creator aendern = — Und die eigene Zeile bekommt jetzt 400 mit einem Satz statt 403: Es ist keine Rechtefrage, sondern eine unsinnige Bitte. --- 3. DREI ERWARTUNGEN, DIE AELTER WAREN ALS DIE REGEL -------------- Die Pruefung verlangte 403, wo seit dem 17.09. 400 richtig ist -- ihre Zeile stammt vom 10.09., sieben Tage aelter als die Regel. Und sie verlangte 404 fuer "die rechte Hand vergibt keine Rolle", was bis vorgestern stimmte. Dabei fiel auf, dass NICHTS geprueft hat, ob die rechte Hand ihre neue Faehigkeit ueberhaupt ausueben kann -- nur, dass sie es nicht darf. Eine Pruefung, die nur das Verbotene misst, laesst offen, ob das Erlaubte geht. Jetzt beide Richtungen: an einer anderen rechten Hand aendert sie nichts (403) und an DogFather erst recht nicht (403) einen Modi macht sie sehr wohl zur Community (200) und es steht so in der Datenbank (gast) eine zweite rechte Hand ernennt sie nicht (400) Nebenbei: `unbekannte_kachel` (gestern eingefuehrt) hatte keinen Satz in meldung.js -- die Kennung waere woertlich auf dem Bildschirm gelandet. pruef-meldungen hatte es gemeldet. Und ein Absturz beim Bauen: `const anlegen = await hole(...)` weiter unten im selben Block verdeckt die gleichnamige Funktion im GANZEN Block, auch oberhalb seiner eigenen Zeile. pruef-haus-trennung: 70 ok, 0 Fehler (vorher 60/6). Dazu gruen: rollen-anlegen 11/0, personen-loeschen 40/0, rechte-umstellen 46/0, verteilen 11/0, meldungen 8/0. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
445ea88f2b |
fetch verweigert Port 5060 -- und sagt dasselbe wie ein toter Server
Nach der Umstellung auf abgeleitete Nummern bekam pruef-chat-kanaele
die 5060 und stuerzte ab:
TypeError: fetch failed
Der Server lief nachweislich ("Server laeuft auf http://127.0.0.1:5060"),
die Anmeldung ueber `http.request` hatte sogar geklappt, und BASIS war
sauber ("http://127.0.0.1:5060", 21 Zeichen, PORT eine Zahl). Nur die
`fetch`-Aufrufe scheiterten.
5060 ist SIP und steht auf der "bad ports"-Liste der
Fetch-Spezifikation. Node hat sie uebernommen: `fetch` baut dorthin
keine Verbindung auf, noch bevor ein Paket fliegt. Die Ursache steht
nur in `.cause` -- "bad port" statt "ECONNREFUSED". Die Meldung
obendrueber ist beide Male dieselbe, und wer sie liest, sucht am
Server.
Gegengeprueft mit einem echten Zuhoerer auf beiden Nummern:
5060 -> fetch failed (bad port)
5062 -> fetch failed (ECONNREFUSED) <- also normal erreichbar
`eigenerPort` ueberspringt die gesperrten Nummern jetzt (portNummer).
Uebersprungen wird nach der REGEL, nicht nach einer Tabelle von
Sonderfaellen: die n-te brauchbare Nummer ab 5000. Eindeutig bleibt es,
weil die Reihenfolge feststeht.
pruef-portnummern (11 statt 8) prueft es doppelt: gegen die Liste UND
am echten Verhalten -- ein Zuhoerer auf 5060 muss fuer `fetch` tot
sein, einer auf einer abgeleiteten Nummer erreichbar. Ohne die zweite
Haelfte waere die Liste nur eine Behauptung ueber Node, und
Behauptungen altern.
Nebenbefund: Auch im alten, von Hand vergebenen Bereich lag eine
gesperrte Nummer -- die 4190. Sie war nie vergeben, rein zufaellig.
pruef-chat-kanaele: 79 Pruefungen, 0 Fehler -- wieder auf der
Grundlinie, die vor der Umstellung gemessen wurde.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
aa8842e72e |
Zwei Pruefungen waren rot, weil Namen sich geaendert hatten
Beide meldeten seit Tagen einen Fehler, den es nicht gab. Eine rote Pruefung, die rot BLEIBT, gewoehnt einem das Hinsehen ab -- ab da uebersieht man auch die echte. --- pruef-teilen: 14 ok / 3 Fehler -> 27 ok / 0 -------------------- Sie suchte `.teilen__brett`. Die Seite baut `.tl-brett`; die Klassen wurden irgendwann umbenannt, und die Pruefung suchte seitdem nach Elementen, die es nicht gibt. Gemeldet hat sie das sogar richtig -- "drei Ziele zur Auswahl (0)" --, nur hat niemand die Klammer gelesen. Danach lief sie in einen Klick-Zeitablauf und brach ab, weswegen DREIZEHN weitere Pruefungen nie stattfanden. --- pruef-crew-wand-bild: 41 ok / 4 Fehler -> 45 ok / 0 ------------ Zwei feste Erwartungen aus einer Zeit, die vorbei ist: 1. `/Team Dogi/` im Reiter. Die App heisst seit dem Treff-Umzug "DogFather Universe". Statt den neuen Namen einzutragen -- und damit dieselbe Zeitbombe mit neuem Datum zu stellen -- kommt er jetzt aus `crew.webmanifest`. Benennt jemand die App um, folgt der Reiter, und beides bleibt gruen. Weichen sie auseinander, sieht der Mensch im Reiter einen anderen Namen als auf seinem Startbildschirm, und genau das soll die Pruefung finden. 2. `kacheln === 3`, seit Filipe am 10.09. sagte "3 rollen. dogfather. rechte hand und modis". Am 19.09. zog der Treff in Team Dogi ein und die Community kam als vierte dazu -- die Zahl war ab da falsch, die Wand richtig. Verglichen wird jetzt die MENGE der Rollen, nicht ihre Anzahl: Eine Zahl sagt beim Scheitern "3 erwartet, 4 gefunden" und verschweigt, WELCHE. Beide Male war die Seite richtig und die Pruefung veraltet -- das ist dieselbe Krankheit wie bei den Portnummern und bei pruef-entwicklung: ein Name oder eine Zahl, abgeschrieben an einer zweiten Stelle, die niemand mitpflegt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
6e46a08543 |
Portnummern werden abgeleitet, nicht mehr vergeben
Gemessen: 165 Pruefdateien, 129 verschiedene Nummern -- NEUNZEHN
doppelt, vier davon dreifach. Niemand hatte das gewollt; jede neue
Pruefung wurde von einer vorhandenen abgeschrieben, und die Nummer kam
mit. Meine eigene Notiz sagte "sieben" -- auch eine Bestandsliste
altert.
Der Waechter faengt den Schaden ab, aber er kann nur melden, was schon
passiert ist: Zwei Pruefungen mit derselben Nummer koennen nie
gleichzeitig laufen, und ein liegengebliebener Prozess der einen laesst
die andere abbrechen mit einer Meldung, die wie ein Befund aussieht.
Genau das ist mir am 20.09. zweimal passiert.
Jetzt leitet jede Datei ihre Nummer aus ihrer STELLE IM ALPHABET ab
(eigenerPort in helfer-port.mjs), zwei je Datei. Nicht ueber eine
Pruefsumme: Bei 165 Namen in 4900 Nummern waeren nach dem
Geburtstagsproblem rund DREI Zusammenstoesse zu erwarten -- ein Hash
tauscht eine sichtbare Doppelung gegen eine unsichtbare. Die Stelle im
Alphabet ist eindeutig von der Bauart her.
--- ZWEI FEHLER AUF DEM WEG, BEIDE LEHRREICH -------------------------
1. DER ERSTE VERSUCH WAR GRUEN UND KAPUTT. Ersetzt wurde mit einem
Muster: "([^"]*4231[^"]*)". Das hielt
{ host: "127.0.0.1", port: 4231, path: "/404.html" }
fuer eine Zeichenkette -- ein Muster kann eine oeffnende nicht von
einer schliessenden Anfuehrung unterscheiden. Heraus kam
{ host: "127.0.0.1`, port: ${PORT}, path: `/404.html" }
also GUELTIGER Code ohne port-Feld. `node --check` sagte gruen fuer
alle 164 Dateien. Aufgefallen ist es erst, weil ich vier Vertreter
gegen eine vorher gemessene Grundlinie laufen liess: pruef-schranke
39/0 vorher, 38/1 nachher.
Alles zurueckgenommen und mit einem Zerleger neu gemacht, der weiss,
ob eine Stelle Code, Zeichenkette, Vorlage, Kommentar oder
regulaerer Ausdruck ist. In pruef-ics stand die Nummer in einem
regulaeren Ausdruck -- der wird jetzt gebaut statt hingeschrieben.
2. EIN MODUL, DAS BEIM IMPORTIEREN ARBEITET, IST EINE FALLE. Der
zweite Durchgang importierte den ersten, um seine Mechanik zu
benutzen -- und fuehrte dessen Hauptlauf gleich mit aus. Die
zweiten Nummern wurden dadurch als erste behandelt, zwei Aufrufe
bekamen dieselbe Nummer, und in pruef-content stand `const PORT`
zweimal.
--- WAS DAS DAUERHAFT HAELT -----------------------------------------
pruef-portnummern.mjs (neu, 8 Pruefungen) fragt nicht "welche Nummern
sind doppelt", sondern "wer traegt ueberhaupt noch eine von Hand ein"
und "wer startet einen Server, ohne seine Nummer abzuleiten". Die
zweite Frage hat sofort etwas gefunden, das in KEINER Doppelungsliste
stand: pruef-push-weg belegte 4341 und 4342, rief den Waechter aber
gar nicht auf -- dieselbe Nummer wie pruef-agentur. Eine Liste zeigt
nur, was auf ihr steht.
Mit Gegenprobe: Eine unbekannte Datei bekommt keine geratene Nummer,
sondern einen Abbruch, und eine dritte Nummer je Datei gibt es nicht.
--- NACHGEMESSEN ----------------------------------------------------
Sechzehn Pruefungen gegen ihre vorher gemessene Grundlinie, je eine
Vertreterin jeder umgestellten Bauweise (eine Nummer, zwei Nummern,
Nummer in einer Zeichenkette, in einer Vorlage, in einem regulaeren
Ausdruck, dynamische Einfuhr, Nachtlauf mit zwei Laeufen):
crew-adresse 132/0 · schranke 39/0 · content 45/0 · entwicklung 46/0
anruf 127/0 · ics 37/0 · push-weg 20/0 · arten 28/0 · video 67/0
kanalzeile 14/0 · agentur 62/0 · spicy 83/0 · creator-anlegen 50/0
push-ziel 10/0 · portnummern 8/0
Alle exakt wie vorher. Zwei waren schon vorher rot und sind es
unveraendert geblieben (crew-wand-bild 41/4, teilen 14/3) -- per
`git stash` belegt, nicht angenommen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d79cb9196b |
Die Entwicklungs-Pruefung war rot, ohne dass etwas kaputt war
Sie hielt seit dem 19.09. eine Namensliste fest: !["Eure Aufgaben", "Talente"].includes(k.name) Als ein Modi eine eigene Kachel bekam -- "Deine Aufgaben", weil "Eure" aus seiner Sicht falsch ist -- wurde sie rot. Nichts war kaputt, der Name hatte sich geaendert. Das ist die abgeschriebene Liste zum dritten Mal in diesem Haus, und diesmal traf sie eine Pruefung: Eine rote Pruefung, die rot BLEIBT, gewoehnt einem das Hinsehen ab und ist damit schaedlicher als gar keine. Erst nachgemessen, ob die Kachel ueberhaupt falsch ist: In workspace-entwicklung.js steht const personen = leitung ? db().prepare(...) : []; Ein Modi bekommt dort eine LEERE Liste -- er sieht auf der Seite nur sich selbst. Die Kachel war also richtig, die Pruefung nicht. An ihre Stelle treten zwei Messungen: 1. DAS VERSPRECHEN STATT DES NAMENS. Filipe hatte gemeldet, dass auf der Kachel "die Antworten sieht nur du" stand und sie trotzdem auf eine Seite mit fremden Namen fuehrte. Das ist eine Eigenschaft des Untertitels, nicht des Namens. Wer morgen eine Kachel "Dein Kopf" nennt und dasselbe verspricht, ist mitgeprueft -- die Namensliste haette ihn durchgelassen. 2. DIE ECHTE GRENZE, die bisher NIEMAND gemessen hat. Ob eine Kachel richtig zeigt, ist Beschriftung; ob die Seite dahinter fremde Namen herausgibt, sind Daten -- und nur das schuetzt jemanden wirklich. Gemessen wird jetzt beides: Ein Modi bekommt auf /entwicklung/lage NIEMANDEN (0), DogFather und die rechte Hand bekommen sehr wohl welche (2). Die zweite Zeile ist die Gegenprobe zur ersten -- waere der Filter einfach zu, saehe auch die Leitung nichts, und die Modi-Zeile waere trotzdem gruen. Nebenbei: Beim ersten Lauf stand `lage.code === 200` statt `lage.status` -- der Helfer heisst anders. Beide Zeilen wurden dadurch ROT, obwohl die Zahlen (2 und 0) von Anfang an stimmten. Der richtige Ausgang: lieber laut scheitern als still bestaetigen. pruef-entwicklung: 46 Pruefungen, 0 Fehler (vorher 43 mit 1 Fehler). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b0e7542507 |
Der Anrufkasten zeigt, WER dran ist -- nicht dreimal "Verbunden"
Filipe, zu Screen 1: "wenn ich anrufe soll das auch viel besser geiler und spezieller aussehen aber es soll nicht raushaengen." Erst gemessen: Es haengt nichts raus. Der Kasten ist 374 px am Handy, 340 am Rechner, 72 Teile geprueft, kein einziges ueber dem Rand. Die Optik war also gar nicht der Mangel -- zwei andere Dinge waren es. 1. DER NAME DES ANRUFERS GING IMMER VERLOREN. `wer(raumName || "Anruf")` lief VOR `kastenBauen()`. Das Element #anruf-wer gab es zu dem Zeitpunkt noch nicht, die Zuweisung lief ins Leere, und oben stand bei jedem Anruf das Wort "Anruf". Die Reihenfolge ist umgedreht: erst bauen, dann beschriften. 2. IN EINEM ANRUF OHNE VIDEO STAND JE PERSON DAS WORT "Verbunden". Bei dreien dreimal dasselbe Wort -- und man sah nicht, WER dabei war. In einer Gruppe ist genau das die Frage: Ist Kessi schon drin? Jetzt steht dort ein Kreis mit den Anfangsbuchstaben und der echte Name; waehrend es klingelt ein wartendes Gesicht mit dem Namen dessen, den man anruft. Vorher war die Flaeche in dieser Sekunde leer, und ein leerer Kasten mit "Es klingelt ..." sieht aus wie einer, der haengt -- ausgerechnet im unsichersten Moment. Der Name kommt NICHT aus einer Abfrage. Wer anruft, bekannt beim Start nur sich selbst; alle weiteren kommen ausschliesslich ueber das Ereignis "dabei", und genau dort fehlte das Einsammeln. Deshalb sah der ANRUFER unter jedem Kreis "Jemand" -- die Angerufenen nicht. UND DIE PRUEFUNG WAR ZU NACHSICHTIG. Sie verlangte einen Namen "laenger als ein Zeichen"; der Rueckfalltext "Jemand" ist sechs Zeichen lang und kam damit durch. Gruen, waehrend der Hauptfall kaputt war. Die zweite Fassung verglich gegen eine abgeschriebene Namensliste -- die nannte "Jonas, Luna, Mara, Pat", angelegt werden aber "Filipe, Rieke, Kessi, Tili", und der Kommentar daneben behauptete schon da, sie sei abgeleitet. Jetzt ist sie es wirklich: Die Namen werden beim Anlegen eingesammelt, und geprueft wird, dass jeder GENAU DIE BEIDEN ANDEREN sieht -- nicht "irgendeinen echten Namen", denn der eigene Name im eigenen Kasten waere auch einer. pruef-anruf: 127 Pruefungen, 0 Fehler. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
9d086eccaf |
Chat: das Buehnenbild scheint durch, jeder Account bekommt seine Kachel
Hinter jeder Seite steht ohnehin eine Buehne (neun Szenen, fuer den
Chat die Lounge). Sie lag bisher hinter einer deckenden Flaeche --
vorhanden, geladen, unsichtbar. Sie durchscheinen zu lassen kostet
keine einzige Datei mehr, und auf der Adresse von Team Dogi kommt
damit von selbst deren eigene Fassung.
Das geht aber NUR, wenn der Text auf einer deckenden Kachel steht.
Sonst liegt Schrift auf einem Foto: an der dunklen Stelle lesbar, an
der hellen nicht, und beim Scrollen wechselt es. Filipes zweiter Satz
("die texte sollen immer in einer kachel sein") ist deshalb kein
Zusatzwunsch, sondern die Bedingung fuer den ersten.
Und jeder Account waehlt seinen Ton. Zwoelf Stueck, alle gleich
dunkel und gleich gesaettigt -- sie unterscheiden sich im Farbton und
in sonst nichts. Ein freier Farbwaehler klingt grosszuegiger und ist
die schlechtere Loesung: Mit ihm laesst sich Schwarz auf Schwarz
einstellen oder Neongelb, das allen anderen in die Augen sticht. Die
Kachel gehoert einem selbst, GESEHEN wird sie von allen anderen.
Gemessen: der schlechteste Kontrast liegt bei 13,9:1 (noetig 7).
Drei eigene Fehler beim Bauen, alle von der Pruefung gefunden:
1. Es gibt ZWEI Regeln fuer dieselbe Kachel (Grundform und
Feinschliff). Ich hatte nur die erste umgestellt, die zweite gewann
-- die eigene Kachel waere durchsichtig geblieben.
2. Die Pruefung las backgroundColor und pruefte den Alphawert. Eine
Kachel mit einem VERLAUF hat dort rgba(0,0,0,0); sie meldete
"durchsichtig" bei einer Kachel, die voellig deckt. Jetzt werden
zwei Bildpunkte verglichen, einmal mit und einmal ohne Buehnenbild
-- das misst die Sache selbst, nicht ihren Stellvertreter.
3. Dieselbe Pruefung suchte nur die rgba-Schreibweise. Chrome gibt
das Ergebnis von color-mix als color(srgb r g b / a) zurueck; der
Rueckfall war "Alpha 1", und sie meldete "deckt" bei einer
Flaeche, die durchscheint. Genau das Gegenteil.
pruef-chatkachel.mjs: 27 Pruefungen, mit eingebauter Gegenprobe (auf
der freien Flaeche MUSS sich etwas aendern, sonst misst der Vergleich
nichts). pruef-chat-optik und pruef-erwaehnung unveraendert gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
9c96612321 |
Am Handy lag Text auf Text -- im Satz ueber Vertraulichkeit
Auf der Befindens-Seite ueberlagerten sich bei 430 px zwei Absaetze um 18 Pixel. Betroffen war ausgerechnet "Deine Antworten liest niemand ausser dir" -- also der Satz, in dem das Vertrauen entsteht, das die ganze Seite braucht. Ursache war eine feste Zahl: -18px Abstand, gerechnet gegen die 26 px, die das Element darueber mitbringt. In einer Kopfzeile setzt start.css dieses margin-bottom aber auf 0. Aus 26 minus 18 wurde 0 minus 18. Zwei fuer sich richtige Regeln, und dazwischen ein Schaden, den keine von beiden verursacht. Die Lehre ist nicht "-18 auf -8 aendern" -- das waere dieselbe Zahl mit anderem Wert und beim naechsten Zusammentreffen wieder falsch. Jetzt bestimmt der Absatz davor seinen Abstand selbst, und nur dann, wenn der Zusatz wirklich folgt (:has). Acht Pixel, in jeder Umgebung. Gefunden hat es ein Bildschirmfoto, nicht das Lesen: Beide Regeln sehen einzeln vernuenftig aus. Die Messung steht jetzt fest in pruef-befinden.mjs (113/0), mit Gegenprobe: Mit dem alten Wert wird sie rot, ohne ihn gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
2719bd9b88 |
Wie geht es dir: achtzehn Fragen in sechs Feldern, eine Zusammenfassung
Sechs Fragen mehr (jetzt 18), und alle in sechs Feldern gegliedert: Last & Erholung, Miteinander, Sinn & Anerkennung, Klarheit & Rueckhalt, Grenzen & Sicherheit, Weiterkommen & Ausblick. Die Felder sind nicht ausgedacht -- es sind die Gebiete, die die Forschung zu belasteten Rollen durchgehend abfragt. Die drei neuen Luecken, die sie schliessen: Schlaf (zeigt Erschoepfung frueher als jede andere Frage), Widersprechen (der Kern dessen, was psychologische Sicherheit heisst) und Mitreden (viel Anforderung bei wenig Einfluss ist die Kombination, aus der Erschoepfung entsteht). Jede neue Frage hat ihre belegte Einordnung -- eine Frage ohne Grundlage ist eine Frage, die jemand gut fand. DIE ROTATION MUSSTE NEU. Der Katalog ist nach Themen sortiert; wer daraus drei aufeinanderfolgende nimmt, bekommt drei aus demselben Feld. Jetzt wird der Ring vorher verzahnt -- erst je eine Frage aus jedem Feld, dann je eine zweite. Ein Fenster trifft damit von selbst verschiedene Felder. Ein erster Anlauf reservierte feste Plaetze fuer die kernlosen Felder. Begruendet mit einer Auswertung je Feld, die es gar nicht gibt -- und er kostete: zwoelf Runden, bis jede Frage einmal gestellt war, fast ein halbes Jahr. Gefunden hat das pruef-befinden.mjs, nicht das Nachdenken. Mit dem verzahnten Ring und vier Plaetzen je Runde sind es vier Runden. DIE EINE ZUSAMMENFASSUNG AM ENDE, nicht eine je Kategorie. Sie sagt in dieser Reihenfolge: die Lage in einem Satz, was traegt (benannt, nicht als Zahl), hoechstens EINE Sache zum Hinschauen, ein Schluss, der zur Lage passt. Umgekehrt waere es eine Maengelliste mit Trostpflaster, und so etwas beantwortet man beim naechsten Mal nicht mehr ehrlich. ZUR FRAGE NACH DER BESTEN KOSTENLOSEN MOEGLICHKEIT: bewusst KEINE KI. Das sind Gesundheitsdaten (wer nachts wach liegt, wer angefeindet wird, wer ans Aufhoeren denkt) -- deshalb sind sie im ganzen Haus als nurSelbst markiert. Kostenlose KI-Angebote bezahlt man mit den Daten. Ein Sprachmodell erfindet ausserdem, und zwar ueberzeugend. Und ein fremder Dienst faellt aus. Jeder Grund reicht einzeln. Die Begruendung steht ausfuehrlich in workspace-befinden-resuemee.js. Nebenbefund behoben: Die Zusammenfassung blieb direkt NACH einer abgeschlossenen Runde leer -- da ist keine Antwort mehr "frisch". Genau der Moment, in dem man sie sehen will. Auch eine Pruefung korrigiert: Sie verbot den Text "entwicklung.js" irgendwo in der Datei und schlug an einem Kommentar an, der die Serverdatei benennt. Sie misst jetzt die Skript-Quellen. pruef-befinden.mjs 112/0, pruef-resuemee.mjs 35/0 (neu). Offener Befund, aelter als diese Aenderung: pruef-entwicklung.mjs meldet "ein Modi: keine Kachel fuehrt mehr ersatzweise auf die Entwicklungsseite" -- auch ohne diese Commits. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
1bdeccc054 |
Highlights: drei Accounts nebeneinander, nach Zeit geteilt
DogFather, HasiDog und DogFather Clips haben eigene Zuschauer und einen eigenen Ton -- das steht so schon an KANAELE im Server. Eine gemeinsame Galerie behauptete, sie waeren ein Topf; wer fuer Clips schneidet, suchte in jeder Reihe nach den Kacheln, die ihn angehen. Jetzt drei Spalten nebeneinander, jede zuklappbar, jede mit ihrem Handle und ihrer Zahl. Eine vierte Spalte gibt es nur, wenn sie gebraucht wird: Bilder ohne TikTok-Link gehoeren zu keinem Account, und sie verschwinden zu lassen waere der schlimmere Fehler. Die Reihenfolge kommt vom SERVER. Der Browser hatte dafuer eine eigene kleine Liste (KANAL_WORT) -- dieselben drei Namen in anderer Reihenfolge, ohne Handles. Beim vierten Account waere genau diese Kopie die vergessene. Dazu eine Zeitleiste: Aktuell (heute), Diese Woche, Dieser Monat, Dieses Jahr, Alles. Kalenderzeitraeume, keine Rueckblicke -- wer am Dienstag "diese Woche" fragt, meint Montag und Dienstag. Jeder Knopf traegt seine Zahl; ohne sie klickt man ins Leere und weiss nicht, ob es am Filter lag. Und beim Anlegen laesst sich der Account waehlen -- fuer Bilder und Momente ohne Link. Bei einem TikTok-Link leitet der Server ihn weiterhin aus dem Handle ab; das ist genauer, weil niemand sich vertippen kann. Beim Bauen gemessen statt vermutet: Der Spaltenkasten lag IM Galerie-Raster von #liste und bekam eine Zelle von 376 px -- Elternbreite 1160. Die drei standen untereinander. Die Galerie gehoert jetzt in die Spalte, nicht um sie herum. pruef-highlights.mjs: 26 Pruefungen, mit Gegenproben (Gast bekommt die Liste nicht, erfundener Account wird abgelehnt, zweiter Klick hebt den Filter auf). pruef-video.mjs weiterhin 67/0. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d77dd216c5 |
Ein Termin von-bis belegt jeden Tag dazwischen
Zwei Fehler, nicht einer. Der sichtbare: Die Kachel stand nur am Anfangstag. Wer im Monatsraster auf den Mittwoch sah, sah nichts -- obwohl die Aktion von Montag bis Freitag lief. Der unsichtbare, und der ist der schlimmere: Der SERVER suchte Eintraege, deren ANFANG im sichtbaren Fenster liegt. Eine Aktion vom 28.09. bis zum 05.10. kam im Oktober deshalb ueberhaupt nicht an -- nicht "nur am ersten Tag markiert", sondern gar nicht da. Wer im Oktober plante, sah eine freie Woche, die belegt war. Jetzt entscheidet die UEBERSCHNEIDUNG, nicht der Anfang. Gebaut wurde es in nachTag() -- der einzigen Stelle, an der Eintraege auf Tage verteilt werden. Monat, Woche, Liste und Zeitstrahl holen sich alle dort; vier Ansichten einzeln nachzuruesten waeren vier Stellen, an denen die fuenfte vergessen wird. Das Ende wird abgeleitet, nicht gepflegt: aus event_ende ODER aus Uhrzeit plus Dauer. Ein Live von 22:00 ueber vier Stunden endet um 02:00 am naechsten Tag -- das stand bisher nirgends, obwohl die Zahlen da waren. Der Tagesdialog filterte selbst auf den Anfangstag. Im Raster war der Mittwoch markiert, tippte man ihn an, stand da "An diesem Tag steht nichts." Jetzt fragt er dieselbe Stelle wie das Raster. pruef-zeitraum.mjs: 16 Pruefungen, beide Fehler einzeln, mit drei Gegenproben (vor dem Anfang, nach dem Ende, Punkttermin). pruef-terminregel.mjs weiterhin 35/0. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
947ea7ff49 |
Fertige Vorschlaege lassen sich wechseln
Bisher kamen ALLE auf einmal -- damit gab es nichts zu wechseln, die Liste war entweder ganz da oder ganz weg. Bei 17 Vorschlaegen (Brett "regeln") ist eine Wand aus Karten ausserdem das Gegenteil von "uebernehmen, was passt". Jetzt vier auf einmal, und ein Knopf holt die naechsten vier. Der Server rechnet die Stelle mit Rest -- nach dem letzten kommt wieder der erste. Es gibt also keinen Zustand "durchgeklickt, jetzt leer". Bei hoechstens vier offenen Vorschlaegen erscheint der Knopf gar nicht: Ein Knopf, der dieselben Karten noch einmal malt, ist ein Knopf, der nichts tut. Was es NICHT ist: Die Vorschlaege werden nicht erzeugt. Sie sind ein geschriebener Vorrat von 113 Stueck auf 16 Brettern. pruef-vorschlaege.mjs: 21 Pruefungen. Die entscheidende vergleicht die Titel vorher und nachher -- ein Knopf, der nur gedrueckt werden kann, besteht jede Pruefung, die nur nach dem Knopf sucht. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
c4e26409b9 |
Die Seite laesst sich als App installieren
Das Manifest war lange vollstaendig -- die App LIESS sich installieren. Nur bot das ausschliesslich der Browser an, versteckt in seinem Dreipunktemenue. Wer es nicht sucht, findet es nie. Und ohne installierte App gibt es auf dem Handy keine verlaesslichen Benachrichtigungen; genau daran hing im September das Telefonieren. Jetzt steht der Knopf in der Kopfleiste, auf allen Seiten, mit drei Antworten statt einer: schon installiert -> gar kein Knopf Browser bietet an -> der Knopf fragt ihn Safari am iPhone -> der Knopf erklaert den Weg Der dritte Fall ist der gefaehrliche: Dort gibt es beforeinstallprompt nicht und wird es nicht geben. Ein Knopf, der am iPhone nichts tut, waere schlimmer als keiner -- man drueckt ihn und sucht den Fehler bei sich. pruef-installieren.mjs: 14 Pruefungen, alle drei Zustaende, mit Gegenprobe in der installierten App. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
586eb51504 |
Profilfotos im Chat, rechte Hand zuerst, Karten lesbar
---- SCREEN 9: DIE FOTOS ------------------------------------------- Filipe: "da soll man im chat auch die profilfotos von den leuten sehen wenn die schon eins drin haben." ZWEI Luecken, beide an Stellen, wo ein Feld weggeworfen wurde: 1. Die GESPRAECHSLISTE bekam kein Bild. `teilnehmerVon` liest es aus der Datenbank, die Detailansicht nimmt es mit -- die Zeile fuer die Liste warf es weg. Folge: im offenen Gespraech ein Gesicht, in der Liste daneben ein Buchstabe. Vom selben Menschen. 2. Eine FRISCH GESENDETE Nachricht trug kein Bild. Der Verlauf beim Laden schon. Folge: Wer gerade zusieht, bekommt einen Buchstaben; wer neu laedt, ein Gesicht -- der Unterschied haengt nur daran, wann man geschaut hat. Der Buchstabe bleibt als Unterlage LIEGEN und wird nicht ersetzt: Laedt das Bild nicht, steht dort weiterhin etwas Sinnvolles statt eines kaputten Bildsymbols. Vier Stellen, ein Verhalten. ---- SCREEN 3: REIHENFOLGE UND AUSSEHEN ---------------------------- Filipe: "ich will dass hier wie ueberall die reihenfolge immer rechte hand und dan erst die modis." Die Abfrage sortierte nach `aktiv DESC, name` -- die ROLLE wurde nicht einmal mitgelesen. Die Seite konnte gar nicht wissen, wer rechte Hand ist; sie sortierte alphabetisch, und damit stand Diene vor Funny, weil D vor F kommt. Jetzt mit ROLLEN_SORTIERUNG -- derselben Regel, die auch Personenliste, Chat und Rechtetafel benutzen. "die kiste von rechte hand soll auch noch vieeeeeel krasser und spezieller aussehen ... der hintergrund von den kacheln soll auch viel krasser und geiler sein und so dass man texte und so besser erkennt. weil gerade ist es schwer lesbar." ZUERST DAS LESEN: Der Grund fuer die schlechte Lesbarkeit war der durchscheinende Untergrund -- die Karten lagen auf dem Buehnenbild, und ein Foto wird stellenweise hell. Sie bekommen jetzt eine DECKENDE Unterlage und erst darueber die Verlaeufe. Die Verlaeufe sieht man weiterhin, nur nicht mehr das Bild dahinter. DANN DAS BESONDERE: Die rechte Hand bekommt einen goldenen Ton, eine deutlich hellere Kante und eine schmale Leiste an der linken Seite -- man sieht den Rang aus zwei Metern, ohne ein Wort zu lesen. KEIN zweiter Bauplan: dieselbe Karte, dieselben Felder, nur ein Merkmal am Element. Zwei Karten zu bauen hiesse, jede kuenftige Aenderung zweimal zu machen. ---- EINE PRUEFUNG, DIE EINE POSITION FESTNAGELTE ------------------ `ok(leute[0]?.id === idMarina, "die Aktiven stehen oben")` wurde rot, sobald die rechte Hand nach vorn sortierte. Richtig wurde sie dadurch nicht: Die Aussage "die Aktiven stehen oben" hat mit Marinas Platz nichts zu tun. Jetzt prueft sie die EIGENSCHAFT (keine Pause vor einer Aktiven) -- eine Pruefung, die eine Position festnagelt, verbietet jede Umsortierung, auch die gewollte. GEPRUEFT: pruef-team-stufen 28/0 (zwei Aussagen mehr), pruef-erwaehnung 69/0 (zwei mehr: das Bild kommt in der Liste an, und wer keines hat, bekommt auch keines vorgegaukelt), pruef-css-klassen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
c59517cb23 |
Ein Anruf faengt leise an
Filipe: "uebrigens soll man auswaehlen koennen ob man lautsprecher will oder nicht bitte. es soll ohne lautsprecher anfangen das gespraech und nur wenn man drauf klickt soll es laut werden ... es soll nicht raushaengen oder so, das ist nicht cool." DER GRUND IST DER STREAM. Ein Anruf, der beim Annehmen sofort aus den Lautsprechern kommt, ist im schlimmsten Fall fuer alle Zuschauer zu hoeren, bevor irgendjemand reagieren kann. Das laesst sich nicht zurueckholen. HIER STAND `hoeren = true` mit der Begruendung: "Wer den Ton abgestellt hat, will ihn nicht beim naechsten Gespraech wieder an." Das war richtig gedacht und ist jetzt umgedreht -- aus demselben Grund, nur in die andere Richtung: Der Zustand soll NICHT ueberdauern. Eine Entscheidung von vorhin darf nicht fuer ein Gespraech gelten, von dem man noch nichts wusste. Zurueckgesetzt wird an BEIDEN Wegen, beim Anrufen und beim Rangehen -- einer allein waere die Haelfte, und die andere Haelfte faellt niemandem auf, bis es einmal zu laut war. UND MAN SIEHT ES. Leise anfangen ohne Hinweis waere die naechste Sackgasse: "ich hoere nichts" ohne Grund und ohne Weg. Ein Balken sagt es, solange es gilt, und verschwindet in dem Moment, in dem man den Ton anmacht. Er ist SELBST der Knopf -- wer liest "tippen, um den Ton anzumachen", will genau das tun. Gedaempftes Bernstein statt Alarmrot: Es ist kein Fehler, sondern ein Zustand. DABEI EINEN EIGENEN FEHLER GEFANGEN: Der Balken fragte `!anruf` -- und diese Variable wird erst gesetzt, NACHDEM der Kasten aufgeht. Beim Aufbauen blieb er deshalb versteckt, und man sass in einem stummen Gespraech ohne einen Satz dazu. Genau der Zustand, den er verhindern soll. Jetzt haengt er am sichtbaren Kasten. DIE PRUEFUNG WURDE ROT und hat damit ihre Arbeit getan -- sie hielt das alte Verhalten fest. Umgedreht, nicht gestrichen: Die wichtigste Falle (ueberlebt der Schalter das Neuzeichnen, wenn jemand auflegt?) bleibt, nur der erwartete Zustand hat sich gedreht. GEPRUEFT: pruef-anruf 117/0 (war 114) -- drei Aussagen mehr, darunter dass der Hinweis da ist, 44 px hoch und im richtigen Moment verschwindet. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
01151574ae |
Die rechte Hand verteilt Aufgaben und wechselt Rollen
Filipe: "jeder soll sich selber aufgabe vergeben koennen aber nur die
rechte hand und dogfather aufgaben an andere verteilen." Und: "ich will
dass ich da auch die rollen der leute wechseln kann ohne dass ich denen
einen neuen account machen muss ... perfektionier das fuer die rolle
dogfather und rechte hand."
---- AUFGABEN VERTEILEN ---------------------------------------------
Die Regel gab es schon -- sie fragte `istLeitung`, und darin steht die
rechte Hand NICHT. Sie konnte also keine Aufgabe weitergeben.
`hand` DORT EINZUTRAGEN WAERE FAHRLAESSIG GEWESEN: `istLeitung` wird an
57 Stellen in 19 Dateien gefragt -- unter anderem im vertraulichen
Meldeweg, in der Personenverwaltung und in den Auswertungen ueber
Menschen. Das haette in einem Zug ueber Einsicht in fremde Meldungen
entschieden, und das hat niemand gewollt.
Stattdessen `darfAufgabenVerteilen` -- eine eigene Regel mit eigenem
Namen. Man sieht an der Aufrufstelle, worum es geht, und wer sie
spaeter aendert, aendert genau diese eine Sache.
Wer nicht verteilen darf, bekommt KEINE Absage: Die Aufgabe landet bei
ihm selbst. Das ist genau, was Filipe wollte ("jeder soll sich selber
aufgabe vergeben koennen") und freundlicher als ein Fehler.
---- ROLLEN WECHSELN ------------------------------------------------
Auch das gab es schon, samt dem wichtigen Satz in der Rueckfrage: "Der
Zugangscode bleibt derselbe." Es konnte nur DogFather (und Spicy
Media).
DREI GRENZEN, JEDE MIT GRUND:
* Niemand wird zu "admin" -- unveraendert seit dem 11.09.2026.
* Die rechte Hand ernennt keine zweite rechte Hand. Wer jemanden auf
die eigene Ebene hebt, vergibt Vertrauen, das ihm nicht gehoert.
Und wer eine Rolle UEBER sich aendern koennte, koennte sich selbst
befoerdern, indem er zuerst den anderen herabstuft.
* Niemand aendert die eigene Rolle -- sonst waere jede Grenze nur ein
Umweg.
SPICY MEDIA BEHAELT, WAS SIE HATTE. Beim ersten Anlauf waere sie durch
die neue Regel ausgesperrt gewesen -- ein Rueckschritt, den ich selbst
verursacht haette. Sie steht jetzt ausdruecklich in der Tabelle.
---- UND DIE OBERFLAECHE RECHNET NICHT MEHR SELBST ------------------
Die Rollenwahl nahm die Knoepfe des ANLEGE-Formulars. Fuer die rechte
Hand ist das leer -- sie legt niemanden an. Die Wahl waere leer
geblieben, das Recht unbenutzbar.
Der Server schickt jetzt zwei Listen mit: wozu ich machen darf
(`rollen_zum_aendern`) und wessen Rolle ich anfassen darf
(`rollen_anfassbar`). Beide aus denselben Funktionen wie die Schranke.
Damit kann die Seite weder zu streng sein (ein Recht, das niemand
findet) noch zu grosszuegig (ein Knopf, der eine Absage bringt) -- der
Fehler vom 10.09.2026, als zwei Listen drei Zeilen auseinander
einander widersprachen.
Dabei fast hineingelaufen: `ROLLEN_REIHE` ist die SORTIERUNG, und
darin fehlt "gast" mit Absicht. Wer sie fuer eine Aufzaehlung nimmt,
verliert die Community still -- genau diese Verwechslung hat am
17.09.2026 schon einmal verhindert, dass sich jemand zu "Community"
machen liess.
---- AUSSERDEM ------------------------------------------------------
Screen 2: "Unsere Seiten" und "Regeln & Hilfe" haben die Plaetze
getauscht -- nur diese zwei.
GEPRUEFT: pruef-verteilen 11/0 (neu, inkl. der Abgrenzung "darf
verteilen, ist aber NICHT Leitung"), pruef-rollen-anlegen 11/0,
pruef-personen-formular 36/0, pruef-personen-liste 33/0,
pruef-personen-loeschen 40/0, pruef-rechtetafel 19/0, pruef-treff 72/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e378514bb4 |
Einmal anmelden reicht -- und beim Zurueckgehen bleibt die Seite stehen
Filipe: "kannst du bitte machen dass die leute sich nur einmal anmelden
muessen und dan nur noch abgemeldet werden wenn sie sich selbst
abmelden. damit sie auch die benarichtigungen sofort kriegen ... und
auch sofort die anrufe annehmen koennen."
---- 1. DIE ANMELDUNG BLEIBT ----------------------------------------
VORHER: zwoelf Stunden, feste Frist ab dem Anmelden. Wer morgens um
acht anfing, flog abends um acht raus -- mitten im Betrieb. Und wer
abgemeldet ist, hat die Seite nicht offen; ein Anruf erreicht ihn dann
nur noch ueber die Benachrichtigung, und bis er sich wieder angemeldet
hat, ist das Klingeln vorbei. Genau das beschreibt Filipe.
JETZT: ein gleitendes Fenster von 180 Tagen, das sich bei jeder Nutzung
verlaengert. Wer die Seite benutzt, bleibt angemeldet -- ohne Ende.
NICHT UNENDLICH, und das ist Absicht: In diesem Haus liegen
vertrauliche Meldungen ueber Menschen. Ein Zugang, der nie ablaeuft,
ist auf einem verlorenen Handy fuer immer offen. Ein halbes Jahr ohne
Besuch schliesst das Geraet und ist niemandem zu viel zugemutet.
An EINER Stelle gebaut: `sitzungLesen` -- durch die gehen alle 26
Fachmodule. Ein Parameter mehr haette 26 Aufrufe geaendert und beim 27.
Modul vergessen werden koennen; `req.res` haengt ohnehin an der
Anfrage. Verlaengert wird erst, wenn weniger als die Haelfte des
Fensters uebrig ist -- sonst waere das ein Schreibzugriff bei jedem
Bild und jedem Herzschlag des Ereignisstroms.
Drei Texte, die noch "zwoelf Stunden" behaupteten, sagen es jetzt
richtig -- inklusive der Abmelde-Nachfrage, die jetzt dazusagt, dass
man angemeldet bleiben SOLLTE, um Anrufe zu bekommen.
---- 2. BEIM ZURUECKGEHEN BLEIBT DIE STELLE -------------------------
Filipe, zum dritten Mal und in Grossbuchstaben. Also erst gemessen:
gescrollt auf: 900
gemerkt: 900
gelandet: 1054 <- 154 px daneben, zuverlaessig
Die Wiederherstellung LIEF also -- sie traf nur nicht. Ursache ist
Chromes Scroll-Verankerung: Waechst Inhalt OBERHALB der Stelle,
verschiebt der Browser den Bildlauf mit, damit das Sichtbare stehen
bleibt. Im Alltag genau richtig; beim Wiederherstellen das Gegenteil.
Sie wird jetzt fuer die Dauer des Wiederherstellens abgeschaltet und
danach wieder eingeschaltet -- nicht dauerhaft, sonst spraenge einem im
Chat der Text unter dem Finger weg. Dazu wird die Stelle nachgesetzt,
solange die Seite noch waechst, und aufgehoert, sobald sie 400 ms lang
ruhig ist. Ergebnis: 900 -> 900, und es bleibt dort.
DAZU, und das ist der groessere Teil: Der Ereignisstrom in kopf.js
laeuft auf 32 Seiten und wird jetzt beim Weggehen geschlossen. Eine
offene EventSource sperrt den Vor-/Zurueck-Speicher des Browsers aus --
deshalb wurde bisher JEDE Rueckkehr ein vollstaendiger Neuaufbau.
Filipe hat genau das beschrieben ("OHNE DASS DIE SEITE ... NEU LAEDT").
EHRLICH DAZU: Playwright schaltet diesen Speicher fuer Tests ab, und er
liess sich hier nicht einschalten. Ich kann also NICHT messen, dass er
jetzt greift -- die Aenderung ist trotzdem richtig (eine offene
Verbindung ist die dokumentierte Sperre, und ein Strom, der beim
Weggehen offen bleibt, ist ohnehin ein Zuhoerer, den niemand mehr
liest). Gemessen und abgesichert ist der Weg OHNE diesen Speicher --
also der schlechteste Fall.
---- 3. DABEI GEFUNDEN: pruef-schranke mass seit neun Tagen nichts --
Sie suchte `const GESCHUETZT = {` per Textmuster in workspace.js. Diese
Tabelle ist am 11.09.2026 nach rechte.js umgezogen -- seitdem fand das
Muster nichts, und die Pruefung meldete "0 geschuetzte Seiten", "alle 0
Seiten leiten um", "0 Schreibweisen ausprobiert". Drei rote Zeilen, die
nach einem Zaehlfehler aussahen und in Wahrheit hiessen: hier wird
nichts mehr geprueft.
Jetzt wird die Tabelle IMPORTIERT. Ein Textmuster auf fremden
Quelltext reisst beim naechsten Umzug still; ein import reisst laut.
Ergebnis: 33 geschuetzte Seiten, 363 Schreibweisen -- alles gruen.
GEPRUEFT: pruef-rollstelle 8/0 (neu, mit Spur ueber die Zeit und zwei
Gegenproben), pruef-schranke (war rot), pruef-code 17/0,
pruef-haerte 20/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
75019ec8c3 |
Am Handy stand nicht da, mit wem man schreibt
Gemessen in der Kopfzeile eines Gespraechs, Name "Team-Runde":
360 px -> 0 px sichtbar (98 noetig)
390 px -> 12 px
412 px -> 33 px
1280 px -> passt
Auf JEDEM Telefon stand also kein Name da -- man oeffnet ein Gespraech
und sieht nicht, mit wem. Und weil die Zeile nicht leer aussieht
(Zurueck-Pfeil, fuenf Knoepfe), wirkt sie nicht kaputt, sondern eng.
URSACHE: `flex: 1` heisst ausgeschrieben `1 1 0%` -- Grundbreite NULL.
Damit "passt" der Name rechnerisch immer, egal wie eng es ist, und es
bricht nie etwas um. Die Knopfreihe daneben hat `flex: none` und
schrumpft nie; seit die Knoepfe am Finger 44 px breit sind, bleibt bei
sechs Knoepfen nichts uebrig.
Zwei Stellen setzten dieselbe Eigenschaft, die spezifischere gewann --
die erste Reparatur wirkte deshalb nur bei 360 px und sonst nicht.
Beide nennen jetzt dieselbe Grundbreite.
KEINE NEUE SCHWELLE: `flex-wrap` bricht genau dann um, wenn der Platz
wirklich nicht reicht. Dieses Haus ist an festen Breiten schon zweimal
gescheitert (Kopfleiste, 06.09.2026); kommt morgen ein siebter Knopf
dazu, stimmt es weiter. Ergebnis: 244 / 268 / 289 px statt 0 / 12 / 33.
---- WARUM DER HANDY-RUNDGANG DAS NICHT GEFUNDEN HAT ----------------
Zwei eigene Entscheidungen, jede fuer sich vernuenftig, zusammen ein
Loch:
1. `sichtbar()` verlangt `width > 0`. Ein auf null gequetschtes
Element ist unsichtbar -- und "unsichtbar" hiess "nichts zu
pruefen". Genau falsch herum: Nichts zu sehen IST der Befund.
2. `text-overflow: ellipsis` gilt als Absicht. Das stimmt auch --
ein langer Name soll gekuerzt werden. Es stimmt nur nicht mehr,
wenn nichts uebrig bleibt.
Die neue Regel ist bewusst schmal: gemeldet wird nur, was unter 40 px
sichtbar ist und mindestens das Doppelte braeuchte. "Jede Kuerzung
melden" waeren die ~350 Fehlalarme, die diese Pruefung schon einmal
zugedeckt haben.
NACHGEMESSEN: 206 Seitenaufrufe, 91 638 Elemente. Die Regel schlaegt
an genau EINER Stelle an (kalender.html, sechsmal) und sonst nirgends
-- 64 -> 70 Befunde. Die Pruefung ist genauer geworden, nicht die App
schlechter.
DER KALENDER-FUND BLEIBT OFFEN: Im Monatsraster ist ein Tag am Handy
36 px breit, ein Eintrag braucht 186 bis 317. Das ist kein Versehen im
Code, sondern die Frage, ob die Monatsansicht am Telefon ueberhaupt
die richtige Vorgabe ist -- eine Entscheidung, keine Reparatur.
GEPRUEFT: pruef-chat-optik 39/0 (drei neu, mit einer Gegenprobe, die
den gemessenen Fall HERSTELLT -- fuenf Knoepfe wie in einer Gruppe;
der erste Anlauf blieb gruen, weil in einem Zweiergespraech nur drei
stehen und der Platz auch ohne Reparatur reicht: 12 px mit der alten
Angabe, 268 mit der neuen, im selben Aufbau).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2a26a49f91 |
Mit "@" jemanden im Chat ansprechen
Filipe: "ich will das man die leute mit @ markieren kann im chat."
MARKIEREN IST KEINE FARBE, SONDERN EINE ANSPRACHE. Sie funktioniert
nur, wenn drei Dinge zusammen stimmen: Der Richtige ist gemeint, er
MERKT es, und man sieht es im Satz. Fehlt eines davon, ist es eine
Attrappe -- und zwar eine, die gut aussieht.
WER GEMEINT IST, ENTSCHEIDET DER SERVER. Der Browser schickt nur Text.
Damit wirkt ein von Hand getipptes "@VanVan" genauso wie eines aus der
Auswahlliste, und niemand kann jemanden ansprechen, der gar nicht im
Raum sitzt -- auch nicht ueber die Schnittstelle.
Die Regeln stehen in server/chat-erwaehnung.js, jede mit Begruendung.
Zwei davon sind keine Feinheit, sondern der Unterschied zwischen
brauchbar und laestig:
* Das Zeichen VOR dem "@" darf kein Buchstabe sein. Sonst piepst
jede E-Mail-Adresse im Chat jemanden an
("[email protected]").
* Das Zeichen DANACH auch nicht, und der laengste Name gewinnt.
Sonst spricht "@Tilikum" Tili an.
MAN MERKT ES AUCH OHNE OFFENEN RAUM. Eine Zahl in der Gespraechsliste
sagt "hier ist etwas" -- nicht, ob es an dich war. Wer morgens vier
Raeume mit Zahlen sieht, macht den lautesten zuerst auf, und dort
steht selten das, was auf ihn wartet. Jetzt steht ein "@" daneben.
UND DIE MELDUNG AUFS HANDY SAGT ES: "VanVan hat dich erwaehnt" statt
"Nachricht von VanVan". Als EIGENE Art, die sich getrennt abschalten
laesst -- wer den lauten Chat stumm stellt, will trotzdem wissen, wenn
ihn jemand direkt anspricht. Ohne Ausnahme von der Ruhezeit: Ein Anruf
wartet auf eine Antwort, ein "@Anna" nicht.
DIE AUSWAHL BEIM TIPPEN loest drei Dinge, die man sonst selbst wissen
muesste: wie die Person genau heisst, wer ueberhaupt im Raum ist, und
ob man sich vertippt hat. Tastatur zuerst (Pfeile, Enter, Tab, Escape).
Sie erzwingt nichts -- wer weitertippt, schreibt einfach weiter.
ZWEI RECHNUNGEN, EINE ANTWORT: Der Browser braucht dieselbe Aufloesung,
um sofort hervorzuheben. Genau dort laufen Dinge auseinander, und dann
haette die Seite jemanden hervorgehoben, den niemand benachrichtigt
hat. pruef-erwaehnung LIEST die Browserfassung aus der Datei und fuehrt
sie aus -- ein Nachbau wuerde pruefen, ob ich zweimal dasselbe
schreiben kann.
---- DABEI GEFUNDEN: "gelesen bis 999999" ----------------------------
Der Server nahm fuer den Lesestand JEDE ganze Zahl an. Wer einmal eine
Zahl hinter allem Vorhandenen schickte, sah in diesem Gespraech nie
wieder einen Zaehler und nie wieder ein @-Zeichen: Alles Kuenftige galt
als gelesen, bevor es geschrieben war. Das faellt niemandem als
Zusammenhang auf -- man merkt nur, dass "die Benachrichtigungen nicht
gehen".
Der Browser schickt heute immer die letzte gesehene Nummer, ist also
nicht der Grund. Aber eine Grenze, die nur davon lebt, dass der
Aufrufer sich benimmt, ist keine. Jetzt wird auf die juengste
Nachricht des Raums begrenzt -- abgeleitet, nicht geraten.
Gefunden hat es meine eigene Pruefung: Sie setzte zum Aufraeumen 99999
und wunderte sich danach, warum das frische "@" nicht leuchtete.
WOHER MAN ERFAEHRT, DASS ES DAS GIBT: Im Chat gibt es keinen
Hilfeknopf. Der Hinweis steht deshalb im Leersatz einer neuen Gruppe --
dort, wo man beim ersten Oeffnen ohnehin hinsieht, und nur ab drei
Leuten. In einem Zweiergespraech waere er Ballast.
GEPRUEFT: pruef-erwaehnung 67/0 (neu) -- 13 Regelfaelle ohne Server,
der Weg durch die Schnittstelle, das Zeichen in der Liste samt
Gegenprobe bei jemandem, der dabei aber nicht gemeint war, beide
Aufloesungen nebeneinander, und der ganze Ablauf am echten Bildschirm
bis "Enter waehlt und schickt NICHT ab".
Dazu pruef-chat 48/0, pruef-chat-optik 36/0, pruef-treffchat 110/0,
pruef-chat-kanaele 79/0, pruef-glocke 31/0, pruef-push 24/0,
pruef-anruf-klingelt, pruef-css-klassen, pruef-meldungen,
pruef-nachfrage, pruef-tippziele.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
409ed551f3 |
"Review" heisst jetzt "Zur Freigabe" -- und Datumsfelder sind so hoch wie alle anderen
Im Code stand die Begruendung selbst: "«Review» allein sagt einem Neuen nichts." Das Wort ist englisch, ein Hauptwort ohne Handlung, und es verraet nicht, WER jetzt dran ist. "Zur Freigabe" sagt beides: fertig von mir, wartet auf jemanden. Geaendert wurde nur, was ein Mensch LIEST -- der Zustandsschluessel bleibt `review`, der gehoert der Datenbank. Betroffen: Spalte und Weiterknopf im Aufgabenbrett, Dateien-Filter, Startseiten-Zaehler, Kachel-Unterzeile, Hinweis "Datei wartet auf Freigabe", Report. NICHT geaendert: der Kalender. Dort ist `review` eine TERMINART (ein Gespraech, in dem man zurueckschaut), kein Zustand. Ich hatte das beim Umbenennen selbst verwechselt und wieder zurueckgenommen -- ein Kommentar an der Stelle haelt die zwei Bedeutungen jetzt auseinander. pruef-sprung hing an der Wortwahl (`/review/i` auf der Beschriftung) und wurde rot, obwohl der Filter richtig stand. Sie prueft jetzt `data-status` -- den Schluessel, der sich nicht mit der Sprache aendert. DAZU, unabhaengig gefunden: Datumsfelder waren 48 px hoch, alle anderen Felder 44. Gemessen auf drei Seiten bei 390 px. Alle liegen auf dem 44-px-Beruehrziel -- nur das Datumsfeld drueckte sich darueber, weil Chromium in `::-webkit-datetime-edit` eine eigene Innenpolsterung setzt, die sogar ein gesetztes `height: 44px` ueberstimmt. Zwei Anteile, einzeln nachgemessen (jeder allein 48->46, erst beide zusammen 48->44): 1 px Polsterung oben und unten im Feldkasten, und eine Zeilenhoehe von 24 statt 22. Keine feste Hoehe gesetzt -- die Zeilenhoehe wird aus Beruehrziel und Polsterung gerechnet, damit sie mitwandert, wenn sich eines davon aendert. Geprueft: pruef-formulare 19/0 (war 16 mit 3 Fehlern), pruef-sprung 43/0, pruef-start-ansicht 151/0, pruef-aufgabenbrett 49/0, pruef-uebersicht 35/0, pruef-uebersicht-browser 20/0, pruef-deutsche-texte, pruef-css-klassen. Ausserdem: vorlagen.js geloescht (8,2 KB). `vorlagenBlock(` wurde in |
||
|
DogFatherGit
|
0f5faf7ee6 |
Eine Seite, die nicht laedt, sagt es -- und bietet einen Weg zurueck
Fuenf Suchlaeufe parallel, ihre Funde selbst nachgemessen und behoben.
DER GROESSTE: 13 VON 21 SEITEN SCHLUCKTEN JEDEN NETZFEHLER.
Jede Seite beginnt mit `try { await hole('/api/ich') } catch { return; }`.
Faellt das Netz aus -- Aufzug, U-Bahn, Funkloch --, bricht der Block ab,
und die Seite bleibt fuer immer auf "wird geladen …" stehen. Gemessen:
0 von 32 Stellen setzten `aria-busy` im Fehlerfall zurueck, und es gab
KEINEN EINZIGEN "Nochmal versuchen" auf allen 21 Seiten.
Im Code stand der richtige Satz dazu -- an genau einer Stelle:
"Ein Platzhalter, der nie ersetzt wird, ist eine Luege mit
Fortschrittsanzeige." Er galt ueberall ausser dort.
Neu: window.ladefehler() in meldung.js. Sie ersetzt alles, was gerade
"laedt", durch drei Dinge: was los ist, was das bedeutet, und einen
Knopf, der es noch einmal versucht -- ohne die Seite neu zu laden.
21 Dateien angeschlossen. Neu: server/pruef-ladefehler.mjs, 26/0, mit
abgeklemmtem Netz im echten Browser.
UND DIE STARTSEITE WARF BEI EINEM FUNKLOCH AUF DIE ANMELDUNG.
`catch { location.assign('/workspace/') }` -- der Mensch glaubt, er sei
rausgeworfen, und tippt seinen Code neu. Dabei haelt seine Sitzung 12
Stunden; nur die Anfrage kam nicht durch. Umgeleitet wird jetzt nur
noch bei einer ANTWORT, die das sagt (401).
DER ANMELDEHINWEIS FUEHRTE MODIS IN DIE SPERRE.
Nach zwei Fehlversuchen stand: "Stimmt die Auswahl oben? Ein Code
gehoert immer zu genau einer davon." Auf der Crew-Wand ist das FALSCH
-- `stillerZugang()` sucht ueber die Codekennung, die angetippte
Kachel spielt fuer hand/modi keine Rolle. Sie probieren alle vier
durch, sammeln vier Fehlversuche, und nach acht in zehn Minuten ist
ihre Adresse gesperrt. Ein Hinweis, der die Sperre herbeifuehrt, gegen
die er helfen soll. Auf der Agenturwand stimmt der Satz weiter --
deshalb wird gefragt, auf welcher Wand man steht.
Dazu: Die Crew-Wand nannte nur der Community einen Weg ("Frag im Live
nach"). Wer zum Team gehoert und dessen Code nicht geht, fand dort
niemanden.
SACKGASSE AUF DER KERNSEITE EINES MODI.
treff-moderation sagte: "Zugaenge legst du in 'Personen & Zugaenge'
an" -- eine Seite, die ein Modi nicht oeffnen darf. Am ersten Tag, bei
leerer Community, war das der einzige Satz im Abschnitt. Jetzt fragt
die Seite ueber `window.__ich.seiten`, ob es den Weg fuer DIESEN
Menschen gibt. Und ein 404 wirft ihn nicht mehr wortlos auf die
Startseite.
TOTE KNOEPFE AN FREMDEN KARTEN.
"◀ zurueck" und "▶ In Arbeit" standen an JEDER Aufgabenkarte, auch an
fremden. Ein Modi sieht das Brett des ganzen Teams; er tippt, der
Server lehnt mit 403 ab, und die Meldung erscheint GANZ OBEN. Bei
einer Karte weiter unten sieht er nichts. Zwei Zeilen tiefer stand die
Regel im Klartext: "niemandem etwas anzubieten, das dann abgelehnt
wird." Der Server schickt jetzt `darf_aendern` mit.
13 STELLEN ROLLTEN GEGEN DEN WILLEN DES NUTZERS.
`scrollIntoView({ behavior: 'smooth' })` beachtet "Animationen
reduzieren" NICHT. Wer das eingestellt hat, hat es meist wegen
Schwindel getan. Zwei Stellen fragten vorher, dreizehn nicht.
Jetzt `window.sanft()`, einmal statt dreizehnmal.
DAS WORT UEBER DEN BRETTERN EINES MODI HIESS "BETREUUNG".
Fest im HTML, ueberschrieben nur bei Brettern mit eigenem `ober` --
sechs haben keines. Jetzt faellt es auf die GRUPPE der Kachel zurueck,
ueber die er hergekommen ist. Je Rolle richtig, ohne zweite Liste.
DER HINWEIS-ZU-KACHEL-WEG WAR DOPPELT KAPUTT.
`bereichZu` suchte nur in GRUPPEN -- der Liste der AGENTUR. Die
Kacheln von Team Dogi schickt der Server; fuer einen Modi fand die
Zeile entweder nichts oder eine fremde Kachel und uebernahm deren
Farbe. Und sie suchte ueber den NAMEN: "LIVE-Analyse" heisst auf der
Crew-Adresse "Live-Ablauf". Beim Beheben erst den Namen umgedreht --
und damit die Agenturseite kaputt gemacht (pruef-start-ansicht sofort
rot). Jetzt ueber das ZIEL, das in beiden Haeusern dasselbe ist.
UND EIN BRETT WAR SEIT GESTERN GESPERRT.
`TREFF_BRETTER` wird aus Kachelzielen abgeleitet. Als die Kachel
"Regeln & Hilfe" am 19.09. auf `treff-regeln.html` umgelenkt wurde,
fiel `regeln` heraus -- und `treff-regeln.html` verweist weiterhin
darauf ("Haeufige Fragen stehen auf dem Brett Regeln & Hilfe").
Gefunden hat es pruef-treff, die seit gestern rot war. 72/0.
NEBENBEI 7 SEITEN LEICHTER: meldung.js wird jetzt abgeleitet
eingebunden -- nur dort, wo sagWas/ladefehler/sanft wirklich
gebraucht werden. Die Anmeldewand traegt es nicht mehr.
Gruen: pruef-ladefehler 26/0, pruef-sackgassen 11/0 (582 Wege, 0 ins
Leere), pruef-start-ansicht, pruef-treff 72/0, pruef-treffchat,
pruef-community-sicht 10/0, pruef-aufgabenbrett, pruef-code 17/0,
pruef-chat-optik, pruef-nachfrage 49/0, pruef-meldungen 8/0,
pruef-css-klassen, pruef-tippziele 11/0, pruef-leerzustand 13/0,
pruef-rechtetafel.
|
||
|
DogFatherGit
|
cc39552b4f |
Eine Eingabe geht nicht mehr wortlos verloren
Filipe: "Was passiert, wenn jemand eine Funktion abbricht?" GEMESSEN: Acht Dialoge im Workspace enthalten Eingabefelder -- "Aufgabe bearbeiten" (10 Felder), der Tageseintrag in der Leistung (8), Ziele, Netzwerk, Import, ein neuer Chat-Raum, ein Creator. Bei allen galt: Esc, Klick daneben oder "Abbrechen" wirft ALLES weg, wortlos. Wer zehn Felder ausgefuellt hat und mit dem Daumen den Rand trifft, faengt von vorn an. Neu: window.verwurfWache() in nachfrage.js. BEIDE SCHLIESSWEGE, denn sie laufen verschieden: Esc / Klick daneben loest `cancel` aus, close() wird NICHT gerufen "Abbrechen"-Knopf ruft close(), loest kein `cancel` aus Wer nur einen abfaengt, hat eine halbe Sicherung -- und die ist schlimmer als keine, weil man ihr vertraut. NICHT VON HAND VERTEILT: Jeder Dialog mit Feldern bekommt sie automatisch (ausser dem Nachfrage-Dialog selbst -- er wuerde beim Schliessen nach sich selbst fragen, in sich selbst, und haenge fuer immer). Wer morgen einen neunten baut, hat sie, ohne daran zu denken. UND SIE FRAGT NUR BEI WIRKLICHER AENDERUNG. Beim Oeffnen wird ein Abbild der Felder genommen, beim Schliessen verglichen. Wer einen Dialog aufmacht und gleich wieder zu, merkt nichts. ZWEI SACHEN BEIM BAUEN GEMESSEN STATT VERMUTET: MEINE EIGENE "ROBUSTHEIT" HAT DIE WACHE STILL AUSGESCHALTET. Gegen den Fall "Felder werden erst nach dem Oeffnen gefuellt" hatte ich einen zweiten Schnappschuss beim Hineinklicken (`focusin`) eingebaut. Gemessen: Der entstand NACH dem Tippen -- Fokus und Werteingabe passieren im selben Atemzug. `beimOeffnen` war danach gleich dem getippten Text, und der Dialog ging wortlos zu. Die Sicherung sah eingebaut aus und tat nichts. Jetzt wird im naechsten BILD nachgetragen: Was das Skript beim Oeffnen nachtraegt, ist drin; getippt haben kann in derselben Sechzehntelsekunde niemand. (Nachgemessen: Alle acht Dialoge fuellen heute VOR showModal.) ZWEIMAL ESC HINTEREINANDER SCHLIESST TROTZDEM. Das ist Chromiums "close watcher": Eine Seite darf den Nutzer nicht mit Esc einsperren. Die Regel ist richtig; dagegen anzubauen waere falsch. Sie steht deshalb im Code und in der Pruefung -- festgehalten, nicht umgangen. Der Knopf unterliegt ihr nicht, und am Handy gibt es ohnehin kein Esc. Elf Speicherwege rufen `vergessen()`, damit nach erfolgreichem Speichern nicht gefragt wird. Eine Warnung nach dem Speichern waere genau die, die man wegklickt -- und danach auch die echte. pruef-nachfrage 49/0 (war 33), davon zehn am Bildschirm: unberuehrt geht er ohne Nachfrage zu nach einer Aenderung fragt Esc nach, der Dialog bleibt offen "Weiter bearbeiten" laesst ihn offen UND der Text steht noch da auch der Abbrechen-Knopf fragt -- jedes Mal "Verwerfen" schliesst wirklich, und der Text steht nirgends pruef-aufgabenbrett, -leistung, -uebersicht-browser, -chat-optik, -css-klassen gruen, pruef-tippziele 11/0. |
||
|
DogFatherGit
|
285038f400 |
Der vertrauliche Meldeweg vergisst jetzt -- und sagt, bis wann
Zwei Entscheidungen, die offenstanden. Beide getroffen, nachdem
gemessen war, was wirklich da ist.
1. WIE LANGE BLEIBEN ABGESCHLOSSENE FAELLE? 90 Tage.
Die Entscheidung war bereits getroffen: `AUFBEWAHRUNG_TAGE = 90` steht
seit dem 19.09. in hilfe-tabellen.js, mit Begruendung ("ein Fall kommt
manchmal wieder auf"). Nur hat sie NIEMAND durchgesetzt --
`hilfeAufraeumen()` gab es, und der einzige Aufrufer war ihre eigene
Pruefung. Der Kommentar darueber behauptete "Wird beim Start
aufgerufen (siehe index.js)"; das war nie wahr.
Jetzt steht die Regel in workspace-aufbewahrung.js, dem Loeschkonzept,
das sich selbst durchsetzt -- beim Start und danach taeglich. Die
zweite Fassung in workspace-hilfe.js ist WEG, nicht doppelt: Zwei
DELETEs auf dieselben Daten waeren morgen verschieden, und der
Unterschied fiele erst auf, wenn er zaehlt.
GEMESSEN VOR DEM EINSCHALTEN:
In der echten Datenbank steht heute KEIN einziger Fall. Der erste
Lauf loescht nichts, und der erste Fall kann fruehestens in drei
Monaten 90 Tage alt werden. Jetzt einschalten ist frei -- spaeter
waere es der riskante Moment gewesen.
PRAGMA foreign_keys steht im Dienst auf 1, und hilfe_nachrichten
traegt ON DELETE CASCADE. An einem echten Fall mit Nachricht
nachgemessen: vorher 1/1, nachher 0/0. Ohne diese Messung waere
der Fall verschwunden und der eigentliche Text liegengeblieben.
2. SOLL EIN GESCHLOSSENER FALL WIEDER ZU OEFFNEN SEIN? Nein.
Im Kopf von workspace-hilfe.js steht: "EIN GESCHLOSSENER FALL IST
GESCHLOSSEN. Auch fuer die Leitung -- sonst ist 'zugemacht' eine
Meinung und keine Tatsache." Das ist eine gute Regel, und sie bleibt.
Nachgemessen, dass sie auch traegt: Ein Melder kann seinen
geschlossenen Fall weiter LESEN, und ein geschlossener Fall zaehlt
nicht gegen das Limit von drei offenen. Wer eine Wiederholung melden
will, kann das also jederzeit -- die Bauweise ist stimmig.
NUR WUSSTE DAS NIEMAND. Dort stand ein Satz: "Dieser Fall ist
abgeschlossen (Datum)." Jetzt stehen drei -- und sie beantworten die
drei Fragen, die man in dem Moment hat:
Kann ich noch schreiben? Nein, und er laesst sich nicht oeffnen.
Bleibt das hier stehen? Bis zum TT.MM.JJJJ, dann geloescht.
Und wenn es wieder passiert? Neu melden, der alte zaehlt nicht mit.
Das Datum kommt vom Server (`lesbar_bis`), die Frist ebenso -- sie
steht nur an EINER Stelle. Und sie steht jetzt auch im Dialog BEIM
Schliessen: Wer eine Uhr startet, soll das vorher wissen, nicht
danach.
OHNE UHRZEIT, und das ist kein Schoenheitsgrund: Ein Fall, der am
20.09. um 14:04 (Sommerzeit) geschlossen wird, verfaellt 90 Tage
spaeter um 13:04 -- die Uhr wird dazwischen zurueckgestellt. Richtig
gerechnet, sieht aus wie ein Fehler. Wer eine Stunde sucht, die es
nicht gibt, hat Zeit verloren.
UND DIE URSACHE, DAMIT ES NICHT WIEDER PASSIERT:
hilfe_faelle kam am 19.09. dazu, das Loeschkonzept ist vom 15.09., und
nichts hat die beiden je verglichen. Neue Pruefung in
pruef-aufbewahrung: Jede Tabelle mit einer Spalte, die "hier ist etwas
zu Ende" sagt, MUSS im Konzept stehen.
Kein "jede Tabelle muss drinstehen": 46 Tabellen, 41 mit
Personenbezug -- das gaebe 38 Meldungen, von denen fast alle falsch
waeren (sie sind ueber personen_geloescht gedeckt). Eine Pruefung,
die 38-mal meldet, wo einmal richtig waere, wird abgeschaltet.
Gesucht wird das schmale Merkmal: GENAU ZWEI Tabellen im Haus tragen
so eine Spalte. Beide jetzt im Konzept -- hilfe_faelle mit Frist,
aufgaben ausdruecklich OHNE (erledigte Aufgaben sind
Arbeitsdokumentation, keine Meldung ueber einen Menschen).
pruef-hilfe 84/0 (war 59) -- darunter zehn neue am Bildschirm:
"drei Saetze statt einem", "sie stehen untereinander, nicht
nebeneinander" (ein <p> in einem <p> waere ungueltig, der Container
ist jetzt ein <div>), "und WANN, mit Datum".
pruef-aufbewahrung 45/0 (war 41), mit Gegenprobe.
|