main
8
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
2f3b8630c7 |
Messungen am Telefon: 37 bekommen ihren Finger
Gestern Mittag gemessen: 39 `newContext`-Aufrufe nehmen ihre Breite
aus einer Variablen und setzen kein `hasTouch`. Ohne das meldet der
Browser `pointer: fine`, und KEINE Regel aus `@media (pointer:
coarse)` greift — dort stehen im ganzen Haus die 44-Pixel-
Beruehrziele, die ausgeblendeten Tastenkuerzel und die
eingeklappte Reiterleiste.
Was das anrichtet, war an pruef-breiten zu sehen: drei Befunde auf
320, 390 und 430 Pixeln, die mit dem Finger allesamt verschwanden —
Messfehler, keine Fehler.
37 DAVON HABEN IHN JETZT. Nur `hasTouch`, nicht `isMobile`: Gefragt
ist genau die eine Sache, um die es geht. `isMobile` waere eine
zweite Aenderung in derselben Zeile, und wenn danach etwas anders
aussieht, wuesste niemand, welche von beiden es war.
ZWEI BLEIBEN STEHEN, beide in pruef-grosscheck.mjs. Die Aenderung
dort waere ein Zweizeiler; sie zu pruefen hiesse, 206 Seiten ueber
vier Rollen laufen zu lassen, und das braucht Filipes Zusage. Eine
Aenderung, die ich nicht pruefen darf, liefere ich nicht aus.
Grundlinie in pruef-fingermass steht deshalb auf 2.
JEDE EINZELN NACHGELAUFEN — 37 Laeufe:
34 gruen, darunter pruef-handy 186, pruef-material 159,
pruef-start-ansicht 160, pruef-kalender 141, pruef-erwaehnung 129,
pruef-bewerbung-aufgaben 163, pruef-neue-seiten 109
3 mit Befunden, ALLE DREI VORBESTEHEND (Gegenprobe: alter Stand
derselben Datei, gleicher Lauf, gleiche Zahl):
pruef-browser 3 (WebKit startet auf diesem Rechner nicht)
pruef-chat-anhaenge 2
pruef-crew-wand-bild 3
EINE ZEITBOMBE GEFUNDEN UND ENTSCHAERFT
pruef-dabei-optik meldete „Haekchen: 0 -> 0" — aber nur, wenn vier
andere Pruefungen gleichzeitig liefen. Allein: „0 -> 1", gruen.
Dort stand `waitForTimeout(250)` mit der Begruendung „250 ms sind
reichlich ueber den 160" (der Dauer der Blende). Auf einem Rechner,
auf dem nebenher vier Browser messen, sind sie es nicht. Die
Pruefung war damit gruen, solange nichts anderes lief, und rot im
Gesamtlauf — also genau dann, wenn niemand sie einzeln nachstellen
kann.
Eine Wartezeit ist eine Annahme ueber den Rechner. Gewartet wird
jetzt auf das, worauf es ankommt: dass das Haekchen da ist. Laeuft
die Frist ab, faellt die Pruefung mit dem ECHTEN Wert um und nicht
mit einem Messfehler. Gegenprobe: unter derselben vierfachen Last,
die sie vorher rot gemacht hat, jetzt gruen.
UND DIE GRUNDLINIE WIEDER STRENG. Ich hatte sie kurz auf
„hoechstens" gestellt — damit haette ein Rueckgang stillschweigend
Platz fuer die naechste Suende gedeckt. Genau davor warnt der Kopf
derselben Datei bei der anderen Grundlinie, und ich habe es eine
Stunde spaeter selbst falsch gemacht.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
718b267de0 |
Zugang: die gewaehlte Kachel ist bindend
Filipe, 01.10.2026: „mach das. es soll fest sein." VanVan hatte gemeldet: „Man kann sich mit seinem Zugangscode immer noch über jeden Button der Startseite anmelden, egal welche Rolle man hat." ICH HATTE ZUERST ABGERATEN -- und lag falsch, weil ich eine alte Lage beschrieben habe. Am 09.09.2026 hatte Filipe entschieden, dass die Modis KEINE eigene Eingangskachel bekommen: „damit die von der workspace auch nicht mal sehen dass die modis von mir einen eigenen zugang haben." Wer keine Kachel hat, muss irgendeine nehmen koennen -- daher der stille Zugang. SEIT DER HAUSTRENNUNG AM 24.09.2026 STIMMT DAS NICHT MEHR. Auf `crew.` steht laengst ein eigener Kachelsatz mit ALLEN fuenf Rollen: DogFather, rechte Hand, linke Hand, Modi, Community (CREW_KACHEL, und crew-index.html zeigt sie). Das Verbergen leistet seither die ADRESSE -- wer sie nicht kennt, findet die Wand nicht; wer sie kennt, liest die Rollennamen ohnehin offen darauf. Der stille Zugang war damit ein Rest. Er hat niemanden mehr geschuetzt und nur dafuer gesorgt, dass die Kachelwahl folgenlos blieb. Nachgesehen habe ich das erst, NACHDEM Filipe widersprochen hat; die Kachelsaetze standen die ganze Zeit im Quelltext. WAS SICH NICHT AENDERT: Auf der Agenturwand war der stille Zugang nie aktiv. Ein Team-Dogi-Code verhaelt sich dort weiterhin wie ein erfundener -- gleiche Antwort, gleicher Weg, gleiche Dauer. Das ist jetzt ausdruecklich gemessen. EINE PRUEFADRESSE IST KEINE WAND. `127.0.0.1` ist weder crew. noch Agentur. Ohne den stillen Zugang gaelte dort der Agentursatz -- und kein Modi kaeme mehr herein. Fuenfzig Pruefdateien melden Team-Rollen ueber diese Adresse an. Auf einer Adresse ohne Wand gibt es deshalb ALLE Kacheln; welche auf welcher ECHTEN Wand steht, misst pruef-modi-verborgen mit ausdruecklichem Host-Kopf. GEPRUEFT -- pruef-modi-verborgen 87/0 (war 85; die fuenf Zeilen „jede Kachel geht" sind durch sieben ersetzt, die die neue Regel und ihre Gegenproben messen). Die Anzahl ist Zeile fuer Zeile verglichen. Modi-Kachel + Modi-Code -> herein admin/hand/linke/gast -> abgewiesen rechte Hand auf ihrer Kachel -> herein Agenturwand + Modi-Code -> wie ein erfundener pruef-crew-adresse 169/0 (unveraenderte Anzahl, zwei Zeilen umgedreht). SECHZEHN PRUEFDATEIEN MELDETEN SICH UEBER FREMDE KACHELN AN -- ein Rest derselben Zeit. Systematisch gesucht statt einzeln entdeckt: Waere ich dem roten Lauf hinterhergelaufen, haette ich beim zwoelften aufgehoert. UND DABEI EIN EIGENER FEHLER: Mein erster Durchlauf las die Rolle am CODENAMEN ab (CODE-MODI- -> modi). Das ging gut, bis „Nane" kam: ein Modi mit dem Code CODE-NANE-0001. Zwei Pruefungen wurden rot, und zwar an einer Stelle („die Stimmen stimmen"), die mit Anmeldung nichts zu tun hat. Ein Codename ist eine Beschriftung, keine Tatsache -- die Rolle steht in `anlegen()`. Danach abgeleitet blieben genau zwei Abweichungen uebrig, und beide sind absichtliche Gegenproben. Drei Browserpruefungen tippten die Creator-Kachel mit einem Modi-Code. Die Modi-Kachel gibt es nur auf der Crew-Wand, und ein Browser auf 127.0.0.1 bekommt die Agenturwand; sie melden sich jetzt ueber die Schnittstelle an und bekommen den Keks. Gemessen werden soll dort, was ein Modi SIEHT -- nicht, wie er hereinkommt. Grün: pruef-modi-verborgen, pruef-crew-adresse, pruef-treff 85/0, pruef-galerie, pruef-kanaele, pruef-modi-katalog 150/0, pruef-modi-ideen, pruef-modi-kategorien, pruef-modi-checkliste 75/0, pruef-modi-livecheck, pruef-kachelraster, pruef-team-ampel 32/0, pruef-team-stufen 47/0, pruef-wunschliste, pruef-bremse, pruef-gespraech, pruef-personen-formular 43/0, pruef-start-ansicht, pruef-community-sicht, pruef-reaktion 421/0, pruef-abzeichen, pruef-chat, pruef-chat-kanaele 81/0, pruef-entwicklung 79/0, pruef-bewerbung-aufgaben 154/0, pruef-struktur, pruef-zwischenspeicher 34/0. `code_kennung` wird weiter geschrieben, aber nicht mehr gelesen -- sie war der Suchschluessel des stillen Weges. Stehen gelassen: Eine Spalte zu entfernen ist eine Schemaaenderung mit Sicherung, und sie kostet nichts. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGit
|
9c45cdc218 |
Drei Pixel breite Kacheln auf kleinen Handys -- und der Block war auf
der Pruefadresse tot DER RASTERFEHLER Auf einem 320 px breiten Geraet waren "Rudel-Chat" und "Anschlagbrett" DREI PIXEL breit: ein senkrechter Strich mit abgeschnittenem Text. Bei 360 px waren es 43 px. Gefunden habe ich es nicht mit einer Pruefung, sondern mit dem Auge, in einem Einzelbild einer Videoaufnahme. Die Ursache stand in start.css: Unter 380 px wird das Kachelraster einspaltig (`grid-template-columns: 1fr !important`), die Willkommenskachel behielt aber ihr `grid-column: span 2` aus einem Block, der 2600 Zeilen spaeter steht und deshalb gewinnt. Ein Gitter mit einer erklaerten Spalte und einem Kind, das zwei braucht, erfindet die zweite -- und teilt den Platz 3 zu 281. WARUM ES KEINE PRUEFUNG GEMERKT HAT, und das ist der eigentliche Befund: pruef-handy misst Ueberhang und Beruehrziele. Eine 3 px breite Kachel ragt nicht hinaus, und ihr Link ist 142 px HOCH -- die Mindestgroesse fuer den Finger war also erfuellt. Beide Pruefungen waren gruen, und die Kachel war unbenutzbar. pruef-kachelraster misst deshalb ab jetzt die BREITE jeder Kachel mit, bei 320, 360 und 390 px. Die Grenze ist abgeleitet und nicht gesetzt: Eine Kachel muss mindestens ein Drittel der Inhaltsbreite haben -- schmaler waere sie auch bei drei Spalten nicht. Dazu wird gezaehlt, wie viele Spuren das Gitter wirklich hat; eine erfundene Spalte faellt damit auf, bevor jemand sie sieht. Gegenprobe gefahren: Ohne die neue Regel meldet die Pruefung "320 px: schmalste Kachel 3 px -- Rudel-Chat 3px, Anschlagbrett 3px" und wird rot. 15 -> 24 Punkte, 0 Fehler. DER NOTIZBLOCK AUF DER PRUEFADRESSE pruef-handy meldete auf notizen.html einen 404 in der Konsole, auf allen drei Geraetebreiten. Kein Anzeigefehler: Die Seite lud, der Block blieb leer. Meine Schranke fragte `haus !== "crew"`. Das klingt richtig und ist es nicht -- auf einer Pruefadresse (127.0.0.1) hat niemand ein Haus, `person.haus` ist dort absichtlich `null`, damit die Pruefungen des Hauses nicht still blind werden. Damit antwortete JEDER Aufruf des Blocks dort mit 404. hausWo() in workspace.js macht es seit dem 24.09. richtig herum: Ist das Haus weder crew noch agentur, wird NICHT gefiltert. Die Schranke folgt jetzt derselben Regel und weist das ANDERE Haus ab statt "alles ausser crew". Die Trennung bleibt unveraendert scharf. pruef-notizen misst ab jetzt BEIDE Enden -- auf `workspace.` 404, auf der Pruefadresse 200. Wer nur eins misst, kann die Schranke jederzeit wieder zu scharf stellen, ohne dass etwas rot wird. 76 -> 79 Punkte. DAS WERKZEUG FUER DIE VIDEOS server/tiktok-videos.mjs nimmt vier Clips ueber die App auf (eigene Wegwerf-Datenbank, eigener Port, nie die echte). Eingebaut ist eine Lecksuche: Nach jedem Seitenwechsel wird der SICHTBARE Text nach Adressen abgesucht, und bei einem Fund bricht die Aufnahme ab. Filipe am 27.09.: "es darf kein link zu sehen sein." Das mit dem Auge zu pruefen waere genau die Sorte Kontrolle, die beim vierten Video nachlaesst. Mit PROBE_LECK=ja laesst sich zeigen, dass sie anschlaegt -- nachgefahren, Rueckgabewert 2. Gemessen: pruef-handy 177/0 (vorher 3 Fehler), pruef-kachelraster 24/0, pruef-notizen 79/0, pruef-start-ansicht 157/0, pruef-handy-teamdogi 0 Befunde. |
||
|
DogFatherGitandClaude Opus 5
|
4a5c69cfc6 |
Die drei Altlasten: ein echter Befund, zwei Pruefungen mit Zahlen von gestern
Alle drei standen seit dem 22.09. in der Notiz und waren mit `git stash` als vorbestehend nachgewiesen. Nachgemessen, einzeln behoben. 1. pruef-jeder-hat-eine-seite -- EIN ECHTER BEFUND "alle 9 Rollen sind zugeordnet -- fehlt: linke" Die LINKE HAND fiel im Steckbrief in den Sammelplatz "Weitere": Auf der Uebersicht ueber die Menschen des Hauses stand sie unter einer Ueberschrift ohne Bedeutung, neben niemandem. Sie gehoert dorthin, wo die rechte Hand steht -- beide fuehren Team Dogi mit. Beim Nachgehen fiel dieselbe Luecke an einer zweiten Stelle auf: In ROLLEN_GRUPPE (der Auswahl, mit wem man schreiben kann) fehlte sie ebenfalls und haette eine eigene Ueberschrift mit genau einem Namen darunter bekommen -- also die Rangordnung, die zwei Zeilen hoeher ausdruecklich vermieden werden sollte. WARUM DIE PRUEFUNG DAS FINDEN KONNTE und ein Mensch nicht: Sie geht ALLE Rollen des Hauses durch, nicht die vier, die zufaellig angelegt sind. Eine Zuordnung, die man an den vorhandenen Leuten prueft, ist eine Aussage ueber die Testdaten. 2. pruef-rollen -- DIE MESSUNG WAR FALSCH, NICHT DIE KACHEL "DogFather Kachel https://crew... LANDET AUF start.html" DogFather bekommt auf der Agenturadresse die Kachel "Zu Team Dogi". Ihr Ziel MUSS eine vollstaendige Adresse sein -- das andere Haus liegt auf einem anderen Rechnernamen. Im Server steht das ausdruecklich (`aussen: true` an der Kachel, samt Begruendung). Die Pruefung klebte jedes Ziel an `BASIS + "/workspace/"`. Bei einer vollstaendigen Adresse kommt dabei Unsinn heraus. Sie kannte ausserdem nur ZWEI Ausgaenge. Ob die andere Tuer aufgeht, laesst sich von hier nicht sagen -- der Browser kennt nur BASIS. Das ist der dritte Ausgang, und er wird jetzt als solcher gemeldet: 314 Pruefungen, 0 Fehler, 1 nicht nachsehbar. Geprueft wird stattdessen, was hier zu pruefen IST: dass die Adresse zu einem Haus fuehrt, das dieses Haus kennt (aus CREW_ADRESSE, nicht abgeschrieben). 3. pruef-kachelraster -- ZWEI ZAHLEN VON GESTERN, UND EIN MESSFEHLER "10 Community-Kacheln" (erwartet 8) und "die doppelt breite Kachel steht an erster Stelle (Platz 0)" `=== 8` stand in der Ueberschrift, im Text und in der Bedingung. Am 22.09. sind Kacheln dazugekommen, und die Pruefung wurde rot, ohne dass am Raster etwas kaputt war. Schwerer wog der zweite Teil: Sie suchte "die Community-Gruppe" ueber deren Ueberschrift, mit der letzten Gruppe als Rueckfall. Fuer DogFather griff der Treffer (1 Kachel), fuer einen Modi der Rueckfall (10) -- und beides hiess in der Meldung "Community-Kacheln". Eine Pruefung, die je nach Rolle etwas anderes misst, kann ihr Ergebnis nicht erklaeren. Jetzt werden ALLE Gruppen gemessen, mit Namen in der Meldung, und die Frage ist ueberall dieselbe: Hat das Raster ein Loch? Die Kachelzahl steht in der Meldung, nicht in der Bedingung. Die Regel "eine doppelt breite Kachel steht vorn" bleibt -- es gibt heute keine solche Gruppe mehr, aber sie gilt fuer die naechste, und die ZAHL der geprueften Gruppen steht daneben. Gemessen sieht DogFather 5 Gruppen (1, 6, 11, 4, 1 Kacheln), ein Modi 6. Kein Loch in einer davon. 15 Pruefungen, 0 Fehler. Mitgelaufen und gruen: pruef-steckbrief, pruef-rechtetafel (19), pruef-chat. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
25de892fdb |
screen5: Aus dem Treff wird das Rudel, aus der Zentrale die IrrenAnstalt
Filipe, 22.09.2026: "ersetze die zentrale durch, Die IrrenAnstalt.
genau so geschrieben bitte. und alles was treff heißt oder wo treff
steht soll durch Rudel ersetzt werden bitte."
Die Schreibweise "IrrenAnstalt" mit grossem A in der Mitte ist so
gewollt. Das steht als Hinweis daneben, damit sie beim naechsten Mal
niemand "korrigiert".
WAS UMBENANNT WURDE: alles, was jemand LIEST -- Kachelnamen,
Ueberschriften, Markenzeilen, Saetze, Meldungen, Aufgabenvorlagen.
116 Zeilen in 42 Dateien.
WAS BLEIBT: Adressen (treff-regeln.html), Bezeichner (TREFF_ROLLEN),
Datenbankwerte (bereich = 'treff'), Abfrageteile (b=treff). Eine
Adresse umzubenennen bricht jedes Lesezeichen, und ein Datenbankwert
umzuschreiben waere eine Umstellung ohne Gegenwert. Dieselbe
Entscheidung wie heute frueh bei Dogi-Media, wo material.html auch
material.html geblieben ist.
DREI GRAMMATIKFEHLER IM EIGENEN ENTWURF, alle vor dem Ausliefern
gefunden -- ein blindes Ersetzen reicht hier nicht:
1. "der Treff" ist maennlich, "das Rudel" saechlich. Ohne Tabelle
waere ueberall "Der Rudel" gestanden. (Und "Treffer" waere zu
"Rudeler" geworden, "Treffen" zu "Rudelen" -- deshalb greift die
Regel nur bei Wortgrenze und nie vor einem Kleinbuchstaben.)
2. BINDESTRICH-ZUSAMMENSETZUNGEN. In "der Treff-Chat" gehoert der
Artikel zu "Chat", nicht zu "Treff". Der erste Durchlauf machte
daraus "das Rudel-Chat", "das Rudel-Kacheln" und "ein Rudel-Raum".
Jetzt greift die Artikelregel nur, wenn das Wort allein steht.
3. GESCHUETZTE LEERZEICHEN. In den Markenzeilen steht
`Der Treff`, damit die zwei Woerter nicht umbrechen. Das
Muster hat daran vorbeigegriffen: "Der Rudel", auf fuenf
Seiten. Jetzt wird das Trennzeichen mitgefasst und unveraendert
wieder eingesetzt.
Gefunden wurden alle drei, weil jede einzelne der 116 Zeilen vor dem
Schreiben als ALT/NEU ausgegeben und gelesen wurde -- und danach
gezielt nach falschen Artikeln gesucht ("den Rudel", "der Rudel",
"einen Rudel"). Uebrig blieben sechs Treffer, und die sind alle
richtig: "einen Rudel-Raum", "der Rudel-Chat", "den Rudel-Regeln" --
Zusammensetzungen, bei denen der Artikel zum letzten Wort gehoert.
UND ZWEI PRUEFUNGEN, die die Umbenennung nicht mitbekommen haetten:
`/Treff/.test(...)` und `/Treff/i.test(...)`. Ein regulaerer Ausdruck
ist keine Zeichenkette -- sie haetten ab sofort nach einem Wort
gesucht, das die Seite nicht mehr sagt, und waeren still rot geworden,
ohne dass etwas kaputt ist.
Geprueft, alle gruen: pruef-treff, pruef-treffchat,
pruef-deutsche-texte, pruef-uebernahme, pruef-crew-adresse,
pruef-willkommen, pruef-wege-nach-draussen, pruef-vorlagen,
pruef-start-ansicht, pruef-struktur.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
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
|
63f2b2bc55 |
Jeder hat einen Steckbrief -- und die Kacheln stehen in der richtigen Reihenfolge
Filipe: "jeder soll ein steckbrief haben, jeder der ein account hat, rechte hand, modis und community, jeder soll genau wie ich foto und so hinzufuegen koennen." Und: "ich will das oben die sachen fuer dogfather sind, dan die sachen fuer modis und dan community bereich." 1. JEDER HAT EINEN STECKBRIEF. In rechte.js fehlte "gast" -- und damit ausgerechnet die groesste Gruppe. Die Seite selbst konnte es die ganze Zeit: `/mein` fragt nach der eigenen Nummer und kennt gar keine Rolle. Es fehlte nur die Tuer und die Kachel. DABEI EIN ZWEITER FUND, der schon laenger da war: In assets/js/steckbrief.js stand eine Liste aus drei Gruppen (Management, Scouting, Creator). Wer in keine passte, verschwand LAUTLOS aus der Uebersicht -- betroffen waren die rechte Hand und die Modis. Ein Modi, der die Seite oeffnete, sah seine eigenen Leute nicht. Kein Fehler, keine leere Liste, sie waren einfach nicht da. Die Zuordnung kommt jetzt vom Server (`abschnittFuer`). Damit kann sie nicht mehr veralten, und in der ausgelieferten Datei steht keine Liste von Rollennamen mehr -- was ohnehin Hausregel ist. Wer kuenftig vergessen wird, landet sichtbar unter "Weitere" statt zu verschwinden; die Gegenprobe dafuer steht in der Pruefung. "Wer hier mitarbeitet" heisst jetzt "Wer hier dabei ist" -- ein Mitglied arbeitet nicht mit, es schaut zu. 2. DIE REIHENFOLGE. Die Moderationskachel trug dieselbe Gruppe wie die sieben Bretter und landete deshalb HINTER ihnen: Wer moderiert, musste an der ganzen Community vorbeiscrollen. Sie hat jetzt eine eigene Gruppe und steht davor. ERST ZU VIEL GEMACHT, DANN KORRIGIERT: Mein erster Entwurf schrieb auch die Reihenfolge der Arbeitsgruppen fest. Die ist an mehreren Stellen bewusst gewaehlt und begruendet -- pruef-start-ansicht hat es sofort gemeldet, zu Recht. Jetzt wandern nur noch Moderation, Community und "Fuer dich" ans Ende; alles andere bleibt, wo es war. 3. ZWEI PRUEFUNGEN, DIE ZUFAELLIG GRUEN WAREN. pruef-kachelraster zaehlte Reihen ueber die Y-Koordinate und wartete feste 500 ms. Die Kacheln laufen aber gestaffelt ein -- mit einer Gruppe mehr war die Messung zu frueh und meldete vier Reihen, wo drei sind. Das Bildschirmfoto derselben Seite zeigte ein makelloses Raster. Jetzt misst sie mit `reducedMotion: reduce`, also den Endzustand. pruef-start-ansicht scrollte 600 px und nahm an, danach liege keine Kachel mehr unter dem Zeiger. Dieselbe Falle wie eine feste Umbruchschwelle: eine Rechnung von gestern. Sie fragt jetzt, was gemeint ist -- leuchtet die ALTE Kachel noch? GEMESSEN: pruef-jeder-hat-eine-seite (neu) 65 Pruefungen 0 Fehler, pruef-steckbrief, pruef-start-ansicht, pruef-kachelraster, pruef-community-sicht alle gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
e4d11caeb0 |
Community-Kacheln: das Loch, die Zwillinge, die unsichtbaren Farben
Filipe, mit einem Bildschirmfoto: "das wie es jetzt ist ist es einfach total scheisse ... gerade einfach nur dahin geknallt und drauf geschissen". Er hatte in allen drei Punkten recht, und alle drei sind messbar. 1. DAS LOCH IM RASTER -- eine Zeile Reihenfolge Drei Spalten, "Der Treff" doppelt breit -- aber an DRITTER Stelle. Nach zwei normalen Kacheln war noch EINE Spalte frei, er passte nicht und rutschte eine Reihe tiefer. Genau das ist die Luecke auf dem Foto. DIE REGEL, und sie gilt fuer jedes Raster im Haus: Eine breite Kachel gehoert an den ANFANG. Steht sie hinten, faellt die Luecke in die MITTE -- und eine Luecke in der Mitte sieht kaputt aus, eine am Ende sieht grosszuegig aus. Jetzt: Treff (2 Spalten) + Anschlagbrett fuellen Reihe 1, drei weitere Reihe 2, der Rest Reihe 3. Fuer DogFather und die Modis geht es genau auf, 3 x 3. Und es stimmt auch inhaltlich: Der Treff IST das Herz dieses Bereichs. 2. ZWEI KACHELN, EIN SYMBOL "Regeln & Hilfe" und "Meldungen & Massnahmen" trugen beide `schutz` -- im Quelltext zweimal, nebeneinander, auf dem Schirm nicht zu unterscheiden. Meldungen bekommt `startcheck`, die abgehakte Liste: Bei Regeln steht, was GILT. Hier steht, was daraus WURDE. 3. DIE FARBEN WAREN DA UND KAMEN NICHT AN Die sieben Toene sind laengst klar verschieden (#cc9451, #668e6e, #cc92c6, #656a9e ...). Der Grund stand direkt daneben: `.kachel:hover::before` und ein ausfuehrlicher Kommentar sprechen von einer Schiene, die "heller wird und weiter in die Platte strahlt" -- nur hatte `.kachel::before` ausser einem Uebergang KEINEN Inhalt. Das Element wurde beim Umbau am 07.09. entfernt, seine Hover-Regeln blieben stehen. Seither trug den Ton nur ein Verlauf, der bei 58 % verschwunden ist; unter dem Buehnenbild reicht das nicht. Das hier ist deshalb kein neuer Einfall, sondern das Wiedereinsetzen dessen, womit der Rest der Datei ohnehin rechnet. Drei Pixel, oben, nach rechts auslaufend -- Farbe an der Kante unterscheidet, Farbe auf der Flaeche blendet. NEU: pruef-kachelraster (15 Pruefungen) Ein Loch wird nicht angesehen, sondern gerechnet: belegte Zellen = Kacheln + 1 je doppelt breiter kleinstmoegliche Reihen = aufgerundet (Zellen / Spalten) Mehr Reihen als das heisst: irgendwo liegt eine Zelle leer, die es nicht muesste. Eine Luecke am ENDE faellt bewusst heraus. Dazu: jedes Zeichen genau einmal (erkannt am SVG-Pfad, nicht an einem Namen -- den gibt es im DOM nicht), jede Kachel mit Schiene, acht verschiedene Toene. Und die Gegenprobe in beide Richtungen: die ALTE Reihenfolge MUSS ein Loch melden, die neue nicht. ZWEI EIGENE FEHLER DABEI, beide durch Messen gefunden: - Ich hielt ein Vollbild-Foto fuer den Beweis, dass keine Kacheln da sind -- sie blenden sich beim Hereinscrollen ein. Die Pruefung scrollt jetzt erst hin. - Ich erwartete sieben Kacheln fuer einen Modi. Er moderiert, also sieht er acht. Der Code hatte recht, meine Annahme nicht. pruef-treff hat die Reihenfolge festgehalten und ist rot geworden -- genau ihre Aufgabe. Erwartung nachgezogen, mit dem Grund daneben. pruef-kachel-universum 37, pruef-haus-seiten 34, pruef-treff 66, pruef-css-klassen und pruef-start-ansicht: gruen. Der ausfuehrliche Plan fuer den ganzen Bereich liegt im Vault: "02 Projekte/Community-Bereich - Plan zur Perfektion" (fuenf Durchgaenge). Co-Authored-By: Claude Opus 5 <[email protected]> |