ea53d950cdde4a30d5a82e5d57cd0691a671543c
10
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
95c4599baa |
Anfuehrungszeichen: 199 falsche Schlusszeichen im sichtbaren Text
Deutsch oeffnet mit „ und schliesst mit “. An 199 Stellen, die ein
Mensch liest, stand als Schlusszeichen ein GERADES " -- „Nächstes"
statt „Nächstes“. Auf sechzehn oeffentlichen Seiten, in vierzig
Dateien des Workspace und in zwoelf Servermodulen, die Texte
verschicken.
Auf dem Bildschirm sieht man den Unterschied sofort. Beim Schreiben
nicht: Das gerade " liegt auf der Tastatur, die anderen nicht.
WARUM EIN ERSTER ANLAUF ZURUECKGENOMMEN WURDE
Ein gerades " ist an vielen Stellen SYNTAX und kein Schriftzeichen --
Grenze einer Zeichenkette, Grenze eines HTML-Attributs, Zeichen in
einem regulaeren Ausdruck. Wer stumpf ersetzt, macht aus
„<a href="https://… ein kaputtes Attribut
/^["'„»\s]+|["'“«.\s]+$/ einen kaputten Ausdruck
"… nichts „mal " + "eben …" eine kaputte Zeichenkette
DIE UNTERSCHEIDUNG LAEUFT AN MERKMALEN, NICHT AN EINER LISTE
< > = dazwischen -> HTML-Marke oder Attribut
endet auf Leerzeichen -> die Zeichenkette hoert hier auf, der
Satz geht in der naechsten Zeile weiter.
Ein deutsches Schlusszeichen steht NIE
hinter einem Leerzeichen.
Rueckstrich mittendrin -> regulaerer Ausdruck
${ ohne } -> mitten in einem Ausdruck
Eine Liste erlaubter Ausnahmen waere die naechste, die niemand
pflegt. Zwoelf Stellen bleiben dadurch stehen, alle zwoelf einzeln
angesehen und alle zwoelf zu Recht -- dort steht das richtige
Schlusszeichen ohnehin weiter unten im Satz.
Fuenf davon waren allerdings ECHTE Fehler HINTER dem Link
(`…>HasiDog</a>".`) -- die erste Regel hatte nur das Attribut
gesehen, nicht den Satz danach. Gezielt nachgezogen.
Ein maskiertes `\"` in workspace-vorlagen.js (28 Hooks) wird zu “ --
ohne Rueckstrich, denn “ begrenzt nichts.
KOMMENTARE BLEIBEN, WIE SIE SIND. Dort liest es niemand ausser mir;
eine Wache, die auch Kosmetik anmahnt, wird weggeklickt. Beim ersten
Messen fielen ausserdem acht Stellen aus buehne.html faelschlich an,
weil `/* */` in HTML (in <style> und <script>) nicht ausgeblendet
war -- jetzt schon.
DIE WACHE DAZU
pruef-struktur prueft es ab sofort mit derselben Regel: 322 Dateien
mit sichtbarem Text, 0 Funde, und die zwoelf bewussten Ausnahmen
werden GEZAEHLT und genannt (erlaubt: 12). Eine Ausnahme, die niemand
sieht, waechst -- und irgendwann steht der echte Fall darin.
GEPRUEFT
pruef-struktur 59 -> 68 Pruefungen, 0 Fehler
node --check auf allen geaenderten JS-Dateien
nachgemessen: 199 geaendert, 12 mit Grund stehen geblieben
gruen geblieben: bewerbung-aufgaben 163, nachwuchs 262,
reaktion 421, support 63, content 45, terminregel 35, treff 85
Und nachgesehen, ob eine Pruefung noch die alte Schreibweise
ERWARTET: 13 Fundstellen, alle dreizehn nur Text in ihrer eigenen
Ausgabe, keine einzige ein Vergleich mit dem Seitentext.
GEGENPROBE: In reaktion.html ein Schlusszeichen zurueckgedreht ->
„workspace/reaktion.html:546 „Nächstes"", mit Datei und Zeile. Und
die Erkennung einzeln gegen HTML-Attribut, fortgesetzte
Zeichenkette, regulaeren Ausdruck und eingesetzten Wert geprueft.
Stempel gesetzt: workspace 670 Verweise in 45 Dateien, oeffentlich
554 in 48 Seiten.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGit
|
7351820c55 |
Der Waechter gegen Namensstreit gilt jetzt fuer das ganze Haus
Er wurde gestern fuer `reaktion.css` gebaut, nachdem `.stufen` dort
zweimal stand und die Stufenleiter der Spenden dadurch das Aussehen
der Chat-Leiste bekam -- drei Stufen nebeneinander, 572 Pixel in
einer 327 Pixel schmalen Spalte, mit der waagerechten Rollleiste auf
Filipes Bildschirmfoto.
Eine Wache, die nur eine Datei ansieht, findet genau die Fehler
dieser einen Datei. Auf alle 36 Stilvorlagen angewandt fand sie
GENAU EINE weitere Stelle.
DER FUND: `.wahl2__eintrag` in gate.css
Zeile 1584 display: block (mit text-overflow: ellipsis)
Zeile 2634 display: flex (fuer Personenbilder, 08.09.2026)
Kein Streit zweier Bauteile, sondern eine spaetere Erweiterung --
und trotzdem ein echter Fehler: `text-overflow: ellipsis` wirkt bei
`display: flex` NICHT auf ein anonymes Flex-Kind. Der Knopf
„… eintragen" in jeder Auswahl des Hauses hat langen Text seither
HART abgeschnitten statt mit „…" gekuerzt.
GEMESSEN -- und nur im Bild zu sehen: `scrollWidth` ist in beiden
Faellen gleich (364 px bei 200 px Breite). Die Zahlen sagten
„kein Unterschied", das Bildschirmfoto zeigte einen. Ein Beleg mehr
dafuer, dass zwei gleiche Zahlen nicht dasselbe Ergebnis bedeuten.
REPARIERT
- Der eigene Eintrag bekommt einen `.wahl2__name`-Span, wie jeder
andere Eintrag auch. Damit kuerzt er wieder mit „…".
- Die zwei Grundregeln sind eine. Wer die erste las, glaubte an
`display: block` -- 1050 Zeilen weiter stand das Gegenteil.
DIE WACHE
923 Grundregeln in 36 Stilvorlagen, keine Klasse zweimal
verschieden gebaut. Gezaehlt wird nur, was sich widersprechen
kann: nicht dieselbe Klasse in einem Zusammenhang (`.saal .pult`),
nicht eine Variante in einer Medienabfrage, nicht
„erst versteckt, dann gezeigt". Sechs Gegenproben, darunter der
echte Fall vom 28.09. und eine Klasse im Kommentar.
GEPRUEFT: css-klassen, freie-namen, suchfeld, tippziele alle EXIT 0.
|
||
|
DogFatherGitandClaude Opus 5
|
7acd7a7674 |
Das Suchfeld nimmt wieder Eingaben, eigene Kanalnamen, Community in Kanälen
screen1, drei Teile. === 1. „bei suchen kann man nichts reinschreiben" === MEIN FEHLER VOM SELBEN TAG. Beim Popover-Umbau heute frueh hing die Liste am <body>, damit sie nicht hinter dem modalen Dialog verschwindet. Gemessen: Das Suchfeld war da, der Fokus landete nicht darin, ein getipptes Zeichen kam nicht an. DER GRUND IST DER FOKUS-KAEFIG. Ein Dialog aus showModal() sperrt den Fokus auf seinen eigenen DOM-Baum ein. Die Liste lag im Top Layer -- sichtbar und anklickbar, aber ausserhalb des Kaefigs. Klicken braucht keinen Fokus, Tippen schon. Deshalb fiel es niemandem auf: Die Liste stand da, sie filterte auf Knopfdruck, nur eine Eingabe kam nicht an. DIE LOESUNG WAR EINE KOMBINATION, die ich vorher fuer unmoeglich hielt. Im Dialog wurde die Liste vom clip-path der abgeschraegten Ecke abgeschnitten, draussen war sie nicht bedienbar. Ein POPOVER wird aber in die Top Layer gehoben und dort gezeichnet -- der Beschnitt des Elternteils erreicht es nicht mehr, waehrend der DOM-Baum (und damit der Fokus) der des Dialogs bleibt. Jetzt haengt sie wieder im Dialog UND ist ein Popover: bedienbar und unbeschnitten. Gemessen beides gegeneinander: „comm" getippt -> kommt an, filtert auf 1 Treffer; und die LETZTE Zeile der vollen Liste ist wirklich anklickbar (elementFromPoint trifft sie selbst, nicht den Dialog). Daraus ist pruef-suchfeld geworden -- der Fehler war von aussen nicht zu sehen, und gefunden hat ihn Filipe, nicht ich. === 2. „einen neuen namen erstellen den es noch nicht gibt" === `data-frei="ja"` war in wahl.js seit langem gebaut und wurde NIE GESETZT -- dieselbe Sorte Lueue wie `grund_min` heute Morgen. Jetzt gesetzt; der getippte Text erscheint als eigener Eintrag ganz oben. Der Server nahm bisher nur die neun festen Zustaendigkeiten. Jetzt auch einen eigenen Namen: Der SCHLUESSEL wird daraus abgeleitet („Technik & Ton" -> "eigen-technik-ton"), der ANGEZEIGTE Name bleibt wie geschrieben. Das Praefix ist kein Schmuck -- ohne es entstuende aus dem Namen „Community" derselbe Schluessel wie beim festen Thema, und der eindeutige Index lehnte ihn ab, obwohl der Kanal nicht existiert. Gemessen: genau dieser Fall antwortet jetzt mit 201. Der alte Kommentar sprach sich gegen freie Namen aus („der sichere Weg zu Clipping neben Clipping-Team"). Das Risiko bleibt und wird begrenzt: Derselbe Name zweimal ergibt denselben Schluessel und damit 409. === 3. „kanäle mit den leuten mit der community rolle" === Seit dem 19.09. nimmt `ohneAussen()` die Community aus den Listen aller anderen. Die Begruendung dort ist ausdruecklich: „Ein Zweier-Gespraech ist kein Kanal. Es hat keine Nachtruhe, kein Modi liest mit, und niemand koennte moderieren." Genau diese Begruendung laesst den Kanal offen. Die Sperre bleibt fuer GESPRAECHE und faellt fuer KANAELE -- `?fuer=kanal` an der Partnerliste, und nur fuer den, der Kanaele ueberhaupt aufmachen darf. Sonst waere der Parameter ein Weg, an `ohneAussen` vorbei Namen zu erfahren. Gemessen: DogFather sieht im Gespraech VanVan und Miss, im Kanal zusaetzlich Kessi und Tom (beide Community). Ein Modi bekommt die erweiterte Liste auch mit dem Parameter nicht. Gruen: pruef-suchfeld (8, neu), pruef-chat-kanaele (81), pruef-treffchat, pruef-chat-neu, pruef-freie-namen (32), pruef-nachfrage (53), pruef-css-klassen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
08ff3e5e40 |
Die Liste im Dialog rollt, das Anschlagbrett schreibt nicht mehr ab
Zwei Dinge aus Filipes Durchgang. ERSTENS: "das hoch und runter scollen geht nicht in der liste da." Die Auswahlliste im Kanal-Dialog liegt seit dem Popover-Umbau in der obersten Ebene. Das loest das Abschneiden -- aber der Zeiger steht danach ueber dem Dialog, nicht ueber der Liste, und das Mausrad rollt den Dialog. Der Horcher haengt jetzt am Dokument (capture) und fragt selbst, ob der Zeiger im Rechteck der Liste steht. Gemessen: 5 Messungen, 0 Befunde. ZWEITENS: "gestalte diese seite auch anders ... viel uebersichtlicher." Am Anschlagbrett stand die Herkunft als vollstaendige Abschrift des Titels darueber -- derselbe Satz zweimal, direkt untereinander. Jetzt nennt sie nur noch das Brett, wenn der Titel uebernommen wurde, und kuerzt sonst auf 60 Zeichen an der Wortgrenze. Dazu Karten mit 620 px Hoechstbreite, zwei nebeneinander statt einer Zeile ueber die ganze Breite -- lesbar bleibt, was eine begrenzte Zeilenlaenge hat. Gemessen: 11 Messungen, 0 Befunde; Titel von 352 px statt voller Breite, zwei Spalten a 571 px. Geprueft: pruef-anschlagbrett (12, 0), pruef-css-klassen, pruef-highlights, pruef-chat-kanaele (81, 0), pruef-freie-namen (32, 0). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
f2f3586b5b |
Die Auswahlliste lag hinter dem Dialog
Filipe: "wenn ich auf zustaendigkeit druecke dan erscheint die auswahl
im hintergrund kontrollier das."
KONTROLLIERT, UND ER HAT RECHT. Gemessen im Browser: Der Kanal-Dialog
ist modal, die Liste hing an BODY, und ein Klick in ihre Mitte traf
DIALOG.dialog -- also den Dialog, nicht die Liste. Sie war da, sichtbar
war sie nicht, bedienbar erst recht nicht.
DER GRUND IST EINE EBENE, KEINE ZAHL. Ein Dialog aus showModal() liegt
in der TOP LAYER, einer Schicht ueber dem ganzen Dokument. Kein
z-index holt etwas aus dem Body davor; die Ebene entscheidet.
DER ERSTE VERSUCH WAR FALSCH, und das Bildschirmfoto hat es gezeigt:
Die Liste IN den Dialog zu haengen bringt sie zwar nach vorn -- und
laesst sie am unteren Rand abschneiden. `.dialog` traegt ein
clip-path fuer die abgeschraegte Ecke, und ein clip-path beschneidet
ALLE Nachkommen, auch "position: fixed". Die Liste endete mitten im
Wort "Events".
Damit ging beides nicht: draussen dahinter, drinnen beschnitten.
DER POPOVER IST GENAU DAFUER GEMACHT. Er hebt ein Element in dieselbe
Ebene wie den Dialog, ohne es zu seinem Kind zu machen: kein Beschnitt,
kein z-index-Wettlauf, und der Browser raeumt ihn beim Schliessen
selbst weg. Fehlt er im Browser, bleibt alles wie bisher -- ausserhalb
eines Dialogs aendert sich ohnehin nichts.
Die drei Zeilen in gate.css nehmen die Vorgaben zurueck, die ein
Popover mitbringt (Rahmen, Polster, und "inset: 0" plus "margin: auto",
was ihn in die Bildmitte stellt).
UND MEINE MESSUNG WAR ZUERST FALSCH, nicht der Code: Sie fragte
document.elementFromPoint und bekam DIALOG -- auch als die Liste
sichtbar darueber lag. Top-Layer-Elemente erfasst elementFromPoint
nicht verlaesslich. Gemessen wird jetzt, was ein Mensch tut: auf einen
Eintrag tippen und nachsehen, ob er ankommt. Er kommt an
("chat -> events"), und die Liste schliesst sich danach.
DAZU EINE EIGENE SCHLAMPEREI VON VORHIN: Die neuen Handy-Kacheln auf
"Eure Aufgaben" hatten .7rem = 11,2 px. Die Grenze des Hauses liegt
bei 11,5 px, und sie steht dort aus einem Grund -- Augenschonung ist
Pflicht, nicht Geschmack. pruef-css-klassen hat es gefangen ("43
Stellen unter 11,5 px, eine mehr als die Grundlinie 42"). Genau dafuer
zaehlt sie mit. Jetzt .75rem, und die Zahl steht wieder bei 42.
Gemessen: 7 Messungen am Dialog ohne Befund, css-klassen wieder in
Ordnung.
NICHT VON HEUTE ABEND, aber gefunden: pruef-chatkachel meldet "mit
allen 13 Toenen (2)". Seit Commit
|
||
|
DogFatherGitandClaude Opus 5
|
df0e74f751 |
Bearbeiten zeigt jetzt, was schon eingetragen war -- und loescht es nicht mehr
Filipe, screen19: "wenn ich auf bearbeiten drücke will ich dass mir immer
die daten angezeigt werden die schon ausgewählt wurden, damit ich auch
immer sehe okee das war alles und das änder ich."
Das war nicht nur unbequem, es war ein DATENVERLUST. Das Feld "Mit wem"
wurde beim Bearbeiten nie gefuellt und stand leer da. Beim Speichern wird
`teilnehmer_extern` aber trotzdem mitgeschickt -- der leere Wert
ueberschrieb also den vorhandenen. Wer einen Termin mit einem frei
eingetragenen Namen ("BananaStift") bearbeitete und speicherte, hatte den
Namen danach verloren, ohne ihn je gesehen zu haben. Nichts stuerzte ab,
nichts meldete sich; er war einfach weg.
DIE URSACHE lag tiefer als im Kalender: `window.personenwahl` konnte
lesen (`wert`, `extern`) und leeren (`zuruecksetzen`), aber NICHT
fuellen. Ein Bearbeiten-Formular hatte gar keine Moeglichkeit, einen
freien Namen anzuzeigen. Deshalb kommt die Reparatur in zwei Teilen:
wahl.js neue Funktion `setzen(wert, externText)`. Sie behandelt
die beiden Faelle als das, was sie sind: entweder eine
Person aus der Liste ODER ein freier Name -- nie beides.
Das eine setzt das andere zurueck.
kalender.js belegt das Gegenueber beim Bearbeiten vor, aus
creator_id / teilnehmer_id / teilnehmer_extern. Nur fuer
die Leitung, wie beim Speichern auch -- fuer die anderen
Rollen gibt es das Feld gar nicht.
Der Server lieferte die noetigen Felder die ganze Zeit mit
(t.teilnehmer_extern, t.creator_id, t.teilnehmer_id) -- es hat sie nur
niemand abgeholt.
Nachgemessen: `personenwahl('f-teilnehmer').setzen('', 'BananaStift')`
ergibt extern="BananaStift", wert="" -- der freie Name steht im Feld,
die Personennummer ist leer. pruef-kalender EXIT=0 (84),
pruef-serien EXIT=0 (69).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e8478c9cae |
Spicy sieht DogFathers Sachen nicht mehr -- und sechs Fehler dazu
VIER DINGE AUS DEN BILDSCHIRMFOTOS, jedes ein echter Fehler:
1. SPICY MEDIA SAH DOGFATHERS DATEN. Beim ersten Anlauf bekam die Rolle
dieselbe Regel wie DogFather (`1=1`) -- damit stimmte der Ueberblick
ueber Manager, Scouts und Creator, und nebenbei standen seine eigenen
Termine, Aufgaben, Dateien und Eintraege mit drin. Jetzt gibt es
ohneDogFather() als EINE Stelle dafuer: Zwei Spalten werden geprueft,
`creator_id` (um wen geht es) und `erstellt_von` (wer hat es
geschrieben) -- ein Termin, den er sich selbst anlegt, haengt nur an
der zweiten. `IS NULL OR NOT IN` und nicht bloss `NOT IN`: In SQL ist
`NULL NOT IN (...)` weder wahr noch falsch, die Zeile fiele
stillschweigend heraus.
2. "PERSOENLICHER ZUGANGSCODE · undefined" auf der Anmeldeseite. Eine
zweite Namensliste im Browser, die beim Hinzufuegen der Rolle
niemand gepflegt hat. Ein unbekannter Schluessel faellt jetzt auf
sich selbst zurueck statt auf `undefined` -- haesslich, aber
sichtbar.
3. SPICY KAM NICHT IN DIE PERSONENVERWALTUNG. Der Server liess sie
herein, das Skript warf sie wieder hinaus: zwei Listen fuer dieselbe
Frage, gepflegt wurde nur die erste.
4. DIE ANMELDEKARTE WAR ZU KLEIN FUER FUENF ROLLEN. Der Kommentar an
genau dieser Stelle warnt woertlich davor -- und ich habe getan,
wovor er warnt: eine Rolle eingefuegt und die Zahl daneben nicht
angefasst. Gemessen: Inhalt 573 px in einer 526 px hohen Tafel, die
Fusszeile stand unter dem Rahmen. Schrift kleiner half nicht (sie lag
schon auf dem Anschlag), also sind die Abstaende an neun Stellen
enger. Nachgemessen auf fuenf Groessen: passt ueberall.
DIE ZEIT WAR WIRKLICH FALSCH. Nicht nur in meinem Satz: `datum()` in
personen.js schnitt die ISO-Zeichenkette ab -- und die ist UTC. Im
Protokoll stand 03:00, wo 05:00 war. Das Tueckische daran ist, dass es
nie kaputt aussieht: Eine Uhrzeit ist immer plausibel.
PROFILBILDER WERDEN JETZT GEZEICHNET. Der Server lieferte sie seit
gestern mit, gezeichnet wurden sie nirgends -- deshalb aenderte sich
nichts. Jetzt in der Personenauswahl (Aufgaben, Termine, Dateien,
Bereiche), in der Gespraechsliste und an jeder Nachricht. Der
Anfangsbuchstabe bleibt als Unterlage LIEGEN: Faellt das Bild aus, steht
dort weiter etwas Sinnvolles.
DER CHAT: Gesichter mit Rollenfarbe, Blasen mit Richtung (die erste
einer Folge eckig, die naechsten rund -- so sieht man, wo ein Gedanke
anfaengt), das offene Gespraech mit Schiene, Ungelesenes hervorgehoben,
und das Eingabefeld in einer eigenen Leiste, die sich beim Schreiben
hebt.
ZWEI EIGENE PATZER, beide von Pruefungen gefunden:
- `o is not defined`: Mein Suchmuster hat die zwei Zeilen fuer das
Bild ans DATEIENDE gesetzt statt in die Schleife -- und in
kalender.js an einen <span> statt ans <option>. Gemeldet von
pruef-sicht, das die Browserkonsole mitliest.
- Ein Kommentar mit `bild` in schraegen Anfuehrungszeichen stand INNEN
in einer Vorlagenzeichenkette und hat sie geschlossen. Die halbe SQL
wurde zu Programmtext.
Dazu: `.chat-neu` gibt es nicht (heisst `.chat__eingabe`), und der
Rollenknopf hatte fuer den Manager keinen sichtbaren Fokus -- ein
box-shadow wird von `overflow: hidden` abgeschnitten, ein outline nicht.
Gruen: spicy (43), creator-anlegen (29), personen-liste (33), sicht (48),
chat (48), chat-optik (24), buehne (38), struktur (32), css-klassen (15),
handy (59), breiten (23), formulare (19), start-ansicht (136),
lesbarkeit (14), barrierefrei (18), tempo (8), kopf-messen (3),
glocke (26), haerte (20), manager-sicht (43), alle-wege (19),
aufgabenbrett (44), kalender (84).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
Claudian
|
b941080694 |
Die Namensliste ging beim Scrollen zu
FILIPE, mit Bildschirmfoto der Personenauswahl: "wenn ich da scollen will geht das immer zu"
Er hatte recht, und es war eine einzige Zeile in workspace/assets/js/wahl.js:
addEventListener('scroll', schliessen, true);
Das dritte Argument bedeutet "in der Einfangphase lauschen" -- und damit auf JEDES
Scroll-Ereignis im ganzen Dokument, auch auf das in der Liste selbst. Wer die Namensliste
herunterrollen wollte, schloss sie im selben Moment. Bei acht Eintraegen faellt das kaum
auf; beim ganzen Manager- und Scout-Team ist die Liste unbedienbar.
Zumachen MUSS sie trotzdem, wenn die Seite scrollt: Sie haengt an position:fixed und
schwaemme sonst neben ihrem Knopf davon. Deshalb wird jetzt unterschieden, WO gescrollt
wurde -- ein Scroll-Ereignis der Seite hat document als Ziel, das ist nicht in der Liste
enthalten, also schliesst sie wie bisher.
Dazu overscroll-behavior: contain in gate.css. Ohne das reicht der Browser das Rollen am
Listenende an die Seite weiter, die Seite bewegt sich -- und daran schliesst die Liste zu
Recht. Der Fehler waere zur Haelfte zurueck gewesen.
GEPRUEFT im echten Browser am echten wahl.js und gate.css (pruef-wahl-scrollen.mjs, 7
Pruefungen), und zwar BEIDE Haelften der Zusage: Liste scrollt -> bleibt offen, Seite
scrollt -> geht zu. Eine Reparatur, die nur die eine Richtung sichert, waere die naechste
Ueberraschung.
Gegenprobe: alte Zeile testweise eingesetzt -> 2 Pruefungen fallen durch. Reparatur ->
alle 7 gruen.
Die Pruefung hat sich beim Bauen DREIMAL geweigert, etwas zu bestaetigen, das sie nicht
gemessen hatte -- "die Liste ist gar nicht laenger als ihr Fenster", "scrollTop = 0". Jedes
Mal lag es an meinem Aufbau (zu hohes Fenster, fehlende Stylesheets, Mausrad ohne Wirkung),
nie an der Reparatur. Gruen gemeldet haette sie es nie.
Der Versionsstempel muss mit: Cloudflare haelt JS und CSS vier Stunden im Browser fest.
Ohne neue Adresse saehe Filipe die Reparatur bis zu vier Stunden lang nicht.
HINWEIS ZUM COMMIT: In diesem Verzeichnis lag zum Zeitpunkt der Arbeit fremde,
uncommittete Arbeit -- vier Server-Dateien (heute 16:41-16:53 geaendert), sieben neue
Pruefdateien, ~110 Bildschirmfotos, eine Fokusring-Korrektur in gate.css und eine
Beschriftung in profil.html. Nichts davon ist hier drin. Bereitgestellt wurde ausdruecklich
nach Pfad, und die beiden Dateien mit gemischtem Inhalt (gate.css, profil.html) wurden dafuer
aus HEAD geholt und nur um den eigenen Anteil ergaenzt. Die fremde Arbeit steht unveraendert
im Arbeitsstand.
|
||
|
DogFatherGitandClaude Opus 5
|
540b5d8838 |
Freie Namen, ein Call-Knopf, und drei Seiten, die fuer Scouts kaputt waren
DREI SACHEN AUF EINMAL, alle aus derselben Sitzung.
1. AUSSUCHEN ODER SELBST EINTRAGEN
Wunsch: "ich will da auch sachen selber noch eintragen koennen, also
aussuchen und selbst eintragen."
Jede Personenauswahl (Kalender, Aufgaben, Bereiche, Content, Dateien)
nimmt jetzt auch einen getippten Namen an -- eine Agentur, eine Marke,
einen Gast ohne Konto. Dazu bekommt JEDE Auswahl ab acht Eintraegen
ein Suchfeld: tippen statt scrollen.
Gebaut IM vorhandenen Auswahl-Bauteil (wahl.js), nicht daneben. Der
erste Anlauf war ein zweites Bauteil -- es hat sich prompt mit dem
ersten gebissen, beide haben denselben <select> eingepackt. Ein
zweites haette ausserdem anders ausgesehen und waere beim naechsten
Umbau nur an einer von zwei Stellen nachgezogen worden.
Der freie Name steht in einer EIGENEN Spalte je Feld; die Verknuepfung
bleibt leer. Entweder eine Person ODER ein Name, nie beides.
Filipe hat ausdruecklich auch bei den Creator-Feldern freie Namen
gewollt, nachdem der Nachteil benannt war: Der Eintrag gehoert dann zu
keinem Konto. Damit daraus kein STILLER Ausfall wird, faellt jede
Abfrage, die bisher den Namen der verknuepften Person las, jetzt auf
den freien Text zurueck (externSql) -- gekennzeichnet als "(extern)".
Der Eintrag verschwindet dadurch aus keiner Liste, keiner Suche und
keiner Uebersicht.
2. WO FUEHRE ICH DEN CALL?
Den Knopf gab es, aber nur wenn jemand von Hand einen Link ins
Ortsfeld getippt hatte UND das Gespraech noch bevorstand. Stand dort
"Hier", war nichts zum Anklicken da.
Jetzt hat das Team einen festen Call-Raum (Discord-Sprachkanal), den
das Management einmal hinterlegt. Danach hat JEDER Call den Knopf --
und er bleibt, solange das Gespraech laufen kann, nicht nur bis zur
Startzeit. Ein eigener Link am Termin schlaegt den festen Raum.
3. WAS EINE ROLLE SIEHT, MUSS AUCH FUNKTIONIEREN
Gemeldet: "cigdem kriegt als manager gewisse sachen nicht auf die sie
sieht, check jede rolle ab."
Neue Pruefung server/pruef-rollen.mjs schickt SECHS Rollen-Zustaende
ueber alle 16 Seiten und misst Konsolenfehler, fehlgeschlagene
Serveraufrufe, tote Verweise, haengende Ladeanzeigen und wortlos leere
Seiten. 96 Durchgaenge.
Der sechste Zustand ist der wichtige: eine Rolle OHNE zugeteilte
Creator -- der Normalfall am ersten Tag und Cigdems echte Lage.
Genau dort fielen die Seiten durch, waehrend dieselben Seiten MIT
Zuteilung tadellos waren.
VIER ECHTE FEHLER GEFUNDEN UND BEHOBEN:
a) Eine Aufgabe, die eine Managerin ohne Creator anlegte, war fuer sie
im selben Moment unsichtbar -- creator_id und verantwortlich_id
leer, und "von mir selbst angelegt" stand in keiner
Sichtbarkeitsregel. Nur DogFather sah sie noch. Kein Fehler, keine
Meldung, die Aufgabe war einfach weg. Dasselbe bei den
Bereichseintraegen. Beide Regeln kennen jetzt erstellt_von.
Niemand sieht dadurch etwas Fremdes -- nur das Eigene.
b) Ein Scout ohne zugeteilten Creator bekam auf die GESAMTE
Report-Seite 404, obwohl sie fuer ihn verlinkt ist. Die Seite
antwortet jetzt sauber und leer, statt sich zu verweigern.
c) Start-Check und Report blieben fuer immer auf "wird geladen"
stehen, wenn es nichts zu laden gab.
d) Das Creator-Profil war fuer Scouts ohne Zuteilung wortlos leer --
der erklaerende Satz stand nur in der grauen Unterzeile.
Ausserdem meldete die bestehende Lesbarkeitspruefung zwei neue
Beschriftungen von mir als zu klein fuers Handy (10,88 statt 11,5 px).
Behoben, und dieselbe Groesse an der Serien-Karte gleich mit -- dort
waere es erst aufgefallen, sobald jemand eine Wiederholung anlegt.
GEPRUEFT: pruef-rollen 97, pruef-freie-namen 32 (mit Gegenproben:
Ben sieht Cigdems Aufgabe NICHT; die Saeulen-Zuordnung nimmt
ausdruecklich KEINEN freien Namen). Alle bestehenden Laeufe gruen:
Startansicht 133, Kalender 84, Serien 67, Protokoll 52, Handy 50, Sicht
48, Ampel 47, Content 45, Aufgabenbrett 44, Sprung 43,
Personen-Loeschen 40, Bereiche 37, Uebersicht 33, Workspace-Seiten 32,
Formulare 19, Betreuung 18, Grosscheck 15, Lesbarkeit 14.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGit
|
7c81b17f9c |
Workspace: alle Auswahlfelder ohne Systemmenue
Filipe: "die kisten wo die namen drin stehen um auszuwaehlen -- kannst du doch ueberall besser aussehen lassen". Betraf nicht eine Stelle, sondern 28 Auswahlfelder auf zehn Seiten. Deshalb EIN Baustein (assets/js/wahl.js) statt zehn Einzelloesungen. WIE ER ARBEITET: Das echte <select> bleibt im Dokument und behaelt seinen Wert -- es wird nur unsichtbar. Darueber liegt ein eigener Knopf mit eigener Liste. Damit funktioniert alles weiter, was schon da war: jedes `feld.value`, jedes `change`-Ereignis, jedes Formular. Ich musste keine einzige der zehn Seiten in ihrer Logik anfassen. Faellt das Skript aus, ist wieder das gewohnte Systemmenue da. DREI ENTSCHEIDUNGEN, DIE WICHTIG WAREN: 1. Nicht display:none fuer das echte Feld, sondern ein Pixel und durchsichtig. Ein per display:none verstecktes Feld faellt aus der Formularpruefung des Browsers heraus -- `required` wuerde stumm nicht mehr greifen. 2. Die Liste haengt an position:fixed, nicht am Elternelement. In einer Karte mit overflow:hidden waere sie sonst abgeschnitten. Passt sie nach unten nicht mehr hin, klappt sie nach oben. 3. Ein MutationObserver erfasst Felder, die erst spaeter entstehen, und Eintraege, die nachgeladen werden. Neu gezeichnet wird im naechsten Bild -- so wird ein direkt nach dem Fuellen gesetztes `feld.value` noch mitgenommen. Geprueft an der Scout-Pipeline: Prioritaet und Stufe entstehen erst beim Aufklappen, beide werden aufgewertet, der gewaehlte Wert kommt beim Speichern richtig an. Tastatur wie gewohnt: Pfeile oeffnen und blaettern, Buchstaben springen zum passenden Eintrag, Esc schliesst, Klick daneben auch. Gruppen (optgroup) werden als Zwischenueberschrift dargestellt. Geprueft ueber zehn Seiten: 28 Felder, KEINES mehr als Systemmenue, Werte kommen an, Seite reagiert auf die Auswahl, Handy ohne Ueberlauf, 0 Konsolenfehler. |