7d77f3ea6bb6fbb2ad83dfe77ef333b7613b4e63
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
7d77f3ea6b |
Die Zeichen bekommen eine Flaeche -- aus Konturen werden Piktogramme
"ich will die symbole in den kacheln noch viel krasser und geiler."
Bis eben war jedes Zeichen eine reine Kontur. Sauber, aber neutral --
siebzehn gleich starke Umrisse nebeneinander, wie aus jedem
Symbolbaukasten.
Jetzt besteht jedes aus ZWEI Teilen:
FUELLUNG eine gefuellte Grundform, gedeckt hinterlegt
LINIE die scharfe Zeichnung darueber, mit dem Verlauf von gestern
Das ist der Unterschied zwischen einem Symbol und einem Piktogramm.
Sobald ein Teil FLAECHE hat, bekommt das Zeichen ein Vorn und ein
Hinten, und das Auge erkennt es, ohne es zu lesen.
Gefuellt wird immer das, WORUM ES GEHT -- nie alles:
Kalender der Kopf des Blattes (daran erkennt man ihn aus drei Metern)
Aufgaben die mittlere Spalte -- "in Arbeit", dort passiert etwas
Dashboard zwei der vier Felder ueber Eck, das gibt Rhythmus
Ordner der Korpus ohne die Lasche, damit die Stufe sichtbar bleibt
Berichte aus drei Strichen werden drei SAEULEN (ein Balkendiagramm
hat Balken)
Start-Check nur der Haken -- ein gefuelltes Klemmbrett waere ein Kasten
Personen der Kopf; bei zwei Personen nur der VORDERE, daraus
entsteht die Tiefe
Buch die linke Seite -- eine im Licht, eine im Schatten
Technik die drei Griffe
LIVE der Sender in der Mitte; gefuellte Wellen saehen aus wie
ein Auge
Trichter nur der obere Teil, sonst kippt das Zeichen nach unten
20 % Deckkraft sind gemessen, nicht geraten: darueber wird das Zeichen
zum Fleck und die Linie darin unsichtbar, darunter sieht man die Flaeche
gar nicht. Beim Ueberfahren geht sie auf 30 %, als kaeme Licht dazu.
WARUM NICHT EINFACH DICKER -- der Unterschied zum gescheiterten Versuch
von gestern: Der legte eine dicke, WEICHGEZEICHNETE KOPIE DER LINIE
darunter und hat damit jede Luecke zugeschmiert (aus dem Kalender wurde
ein leerer Kasten). Eine Flaeche ist etwas anderes als ein aufgeblasener
Strich: Sie liegt INNERHALB der Kontur und laesst die Zwischenraeume
unberuehrt. Genau deshalb funktioniert es jetzt.
Im Wasserzeichen und im Kontrastmodus bleibt die Flaeche aus -- dort
wuerde sie den Text hinterlegen bzw. zu einem massiven Block werden.
GEPRUEFT: Buehne 38 (Textkontrast an echten Bildpunkten -- die Flaeche
darf die Lesbarkeit nicht antasten), Startansicht 133, Rollen 97,
Handy 50, Team 30, Grosscheck 15, Lesbarkeit 14. Alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
a9815e291a |
Ein Hintergrund fuer alles -- und Zeichen, die endlich vollstaendig sind
ZWEI AUFTRAEGE.
1. DER NEUE HINTERGRUND
Das Dogfather/Spicy-Media-Bild loest die neun Buehnen ab. Der Login
behaelt ausdruecklich sein eigenes Bild (body.gate, unangetastet) --
dort wird der Zugangscode eingegeben, und genau das sollte bleiben.
Nicht einfach hingelegt: Das Bild ist sehr kraeftig, vor allem die
rote Haelfte. Ohne Behandlung fiel der Textkontrast auf 3,03:1
(noetig sind 4,5:1) -- ausgerechnet in der Personenverwaltung und auf
dem Aufgabenbrett. Gemessen hat das server/pruef-buehne.mjs, das den
Kontrast an bis zu 36 echten Bildpunkten je Seite nachrechnet.
In vier Schritten angepasst und jedes Mal nachgemessen:
-0,14 Helligkeit -> 4,12:1 (immer noch zu wenig)
-0,20 Helligkeit -> 4,48:1 (zwei Hundertstel zu wenig)
-0,23 Helligkeit -> 4,63:1 bestanden, alle Seiten
Dazu Saettigung 0,72 und Gamma 0,91 -- dieselbe Behandlung, die auch
die alten Buehnen bekommen haben (tools/buehne-bauen.mjs arbeitet mit
Helligkeit 0,66 bis 0,88). Das Bild bleibt ein Bild und wird nicht
zur Tapete, aber Text steht darauf lesbar.
2. DIE ZEICHEN
Sie bekommen einen VERLAUF: oben hell, nach unten gedaempft -- eine
Lichtquelle ueber dem Zeichen, wie in der echten Welt. Dazu ein
weicher Schlagschatten in der eigenen Farbe. Der Verlauf ist EINMAL
definiert und arbeitet mit currentColor: ein Verlauf fuer siebzehn
Kachelfarben.
ZWEI SACKGASSEN AUF DEM WEG, beide aufgeschrieben statt weggeraeumt:
a) Erst lag unter jeder Linie eine dicke, weichgezeichnete Kopie --
"Licht, das die Linie wirft". Bei einem grossen Symbol traegt das.
Hier nicht: Ein Zeichen ist 24 Einheiten breit und 25 px gross,
eine Einheit ist also ein Pixel. Linie 1,65 plus Schein 2,5 fuellt
jede Luecke, die enger als vier Einheiten ist -- aus dem Kalender
wurde ein leerer Kasten. Gesehen habe ich das erst bei dreifacher
Vergroesserung; auf dem normalen Schirm sah es nur "satter" aus.
Die Lage ist wieder weg.
b) Der Verlauf lief zunaechst in OBJEKTKOORDINATEN. Damit wird er auf
den Umriss jedes einzelnen Pfades gerechnet -- und eine waagerechte
Linie hat die Hoehe null. Der Verlauf ist dann entartet, und der
Browser zeichnet den Pfad GAR NICHT. Verschwunden waren dadurch:
die Querlinie im Kalender, alle drei Regler-Striche in Technik,
die Grundlinie der Berichte. Jetzt laeuft er in Benutzer-
koordinaten ueber die festen 24 Einheiten -- was ohnehin richtiger
ist, denn das Licht kommt von oben und nicht von jedem Strich
einzeln.
AUSSERDEM ECHT REPARIERT: Das Technik-Zeichen hatte drei Griffe aus
Boegen der Laenge null ("a1.4 1.4 0 1 0 0-.02z") -- sie wurden nie
gezeichnet. Uebrig blieben drei nackte Striche, die aussahen wie ein
Menue-Symbol. Jetzt sind es echte Kreise. Kalender und Dashboard haben
mehr Luft zwischen ihren Linien bekommen, damit sie bei 25 px nicht
zu einer Flaeche verschmelzen.
GEPRUEFT: Buehne 38 (Kontrast an echten Bildpunkten), Startansicht 133,
Rollen 97, Handy 50, Grosscheck 15, Lesbarkeit 14 -- alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
0404f8c0c1 |
Dreizehn Lecks: eine Managerin sah die Creator aller anderen
Wunsch: "jeder manager soll auch immer nur seine und die seiner scouts
zugeteilten creator und creator daten sehen. und nicht die der anderen."
DIE KETTE WAR GEBAUT -- SIE WURDE NUR NICHT BENUTZT
Manager -> seine Scouts -> deren Creator steht seit dem 01.09.2026 an
genau einer Stelle (betreuteIds). Die Frage war eine andere: Benutzt sie
auch JEDER Weg, der Creator-Daten herausgibt? Ueber zwanzig Stellen
prueften die ROLLE statt der ZUTEILUNG -- "ist Leitung? dann alles".
NICHT GELESEN, SONDERN GEMESSEN
server/pruef-manager-sicht.mjs baut zwei Managerinnen mit vollstaendig
getrennten Creators. Bei der fremden heisst ALLES "GEHEIM..." -- Aufgabe,
Termin, Bereichseintrag, Datei, Steckbrief, Content-Saeule. Danach wird
jede der 31 Leseschnittstellen abgefragt und die ganze Antwort danach
durchsucht. Ein Leck faellt damit auf, egal wo es sitzt und egal, ob ich
es beim Lesen uebersehen haette.
GEFUNDEN: DREIZEHN. Alle geschlossen:
Kalender fremde Fristen -- besonders unangenehm, weil es
nicht wie ein Leck aussieht: eine kleine orange
Marke mit einem Titel, in dem fremde Vorhaben stehen
Personenauswahl alle Namen im Zuweisungsfeld
Dateien alle Namen in der Freigabe-Auswahl
Uebersicht Gesamtuebersicht ueber ALLE Creator
Report Auswahl UND Auswertung ueber den ganzen Bestand
Start-Check alle Creator zur Auswahl
Steckbriefe Bild, Kanaele, "ueber mich" von allen
Profile alle Profile, samt interner Notiz
Schulung Schulungsstand aller Creator
Suche Creator-Profile aller -- die unauffaelligste Stelle:
Man sucht etwas anderes und bekommt fremde Namen
Content-Balance Themensaeulen fremder Kanaele (die Abfrage daneben
war korrekt eingeschraenkt, DIESE hatte eine eigene
Bedingung)
darfCreator eine einzige Zeile -- sie hing an Profil,
Start-Check und Uebersicht gleichzeitig. Es reichte,
eine Nummer in die Adresse zu schreiben.
Die Antwort steht jetzt an EINER Stelle: sichtbareCreatorIds und
sichtbarePersonenIds in workspace.js. Rueckgabe null heisst "alle" und
gilt allein DogFather -- bewusst kein leeres Feld: Eine leere Liste
bedeutet "niemand", und die Verwechslung der beiden macht aus einer
Sperre eine Freigabe.
ZWEI DINGE, DIE ICH MIR SELBST NACHTRAGEN MUSS
1. Beim Stopfen fehlte einmal ein Import. Der Weg warf einen Fehler,
antwortete 503 -- und weil in einer Fehlermeldung kein "GEHEIM" steht,
meldete die Pruefung "kein Leck". Sie war gruen, weil der Weg KAPUTT
war. Die Pruefung zaehlt jetzt beides: nichts durchsickern UND
antworten.
2. Ein Fehlalarm: Die Suche gibt den SUCHBEGRIFF in ihrer Antwort
zurueck. Wer nach "GEHEIM" sucht, findet das Wort zwangslaeufig --
auch bei null Treffern. Ich haette um ein Haar ein Leck "repariert",
das es nie gab. Das Echo wird jetzt entfernt, bevor gemessen wird.
FOLGEN, bewusst in Kauf genommen:
* Ein Manager ohne Zuteilung sieht keinen Creator. Die Uebersicht sagt
ihm das jetzt in einem Satz, statt leer zu bleiben.
* Er kann nur noch IN SEINEN Creator-Bereichen schreiben (darfCreator).
ZWEI PRUEFUNGEN UMGEDREHT statt geloescht -- eine geloeschte Pruefung
hinterlaesst keine Spur davon, dass hier einmal etwas anderes galt:
pruef-uebersicht ("Manager sieht dasselbe" -> "nur seine zugeteilten",
mit beiden Faellen) und pruef-scout-zuteilung ("sieht die ganze
Personenliste" -> "landet auf der Startseite").
GEPRUEFT: 43 neue Pruefungen, dazu 23 bestehende Laeufe gruen --
Startansicht 133, Rollen 97, Kalender 84, Serien 67, Steckbrief 65,
Handy 50, Sicht 48, Ampel 47, Content 45, Aufgabenbrett 44, Schulung 41,
Bereiche 37, Scout-Zuteilung 36, Uebersicht 35, Personenliste 33,
Freie Namen 32, Team 30, Protokoll-Loeschen 20, Personenformular 20,
Formulare 19, Betreuung 18, Code 17, Grosscheck 15.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e7b277b7fc |
Die Startseite log nicht -- sie war nur alt. Und Protokolle lassen sich loeschen
Drei Meldungen aus einer Nachricht.
1. "WIRD IMMER NOCH ANGEZEIGT"
Ein Protokoll war geschrieben, die Startseite meldete trotzdem weiter
"1 Gespraech hat noch kein Protokoll".
NACHGESTELLT statt vermutet: Der Server lag die ganze Zeit richtig.
Der Hinweis erscheint, sobald ein vergangenes Gespraech kein Protokoll
hat, und verschwindet in dem Moment, in dem eines geschrieben ist --
nachgemessen, beides.
Falsch war der BILDSCHIRM. Browser legen eine verlassene Seite
vollstaendig beiseite (bfcache) und holen sie beim Zurueckgehen
unveraendert hervor, mitsamt allen Zahlen vom ersten Laden. Kein
Skript laeuft dabei erneut. Wer ein Protokoll schreibt und dann auf
"Zurueck" tippt, sieht zwangslaeufig den Stand von vorher.
Das ist kein Schoenheitsfehler: Eine Zahl, die etwas Falsches
behauptet, ist schlimmer als gar keine -- man glaubt ihr ja. Und sie
kostet danach Vertrauen in ALLE Zahlen.
kopf.js laedt eine zurueckgeholte Seite jetzt neu. Nur dann
(`event.persisted`), nicht bei jedem Anzeigen -- sonst waere es eine
Endlosschleife. Gilt fuer jede Workspace-Seite, nicht nur die
Startseite.
2. PROTOKOLLE LOESCHEN -- NUR DOGFATHER
Bewusst istDogFather und nicht istLeitung: Ein Manager hat sonst
ueberall dieselben Rechte, hier ausdruecklich nicht. Wer ein Protokoll
entfernen darf, kann nachtraeglich bestimmen, was besprochen wurde.
Geloescht wird NUR das Protokoll. Das Gespraech bleibt im Kalender und
rutscht wieder zu "Protokoll fehlt" -- die Handlung ist damit
umkehrbar: neu schreiben, fertig. Die daraus entstandenen AUFGABEN
bleiben ebenfalls stehen; sie sind echte Arbeit, die jemand uebernommen
hat, und mit einem Klick auf ein Protokoll zu verschwinden waere ein
stiller Datenverlust an ganz anderer Stelle.
Der Knopf steht nur bei DogFather. Ein Knopf, der bei anderen
erscheint und dann abgewiesen wird, ist eine Einladung zum Aergernis.
3. IMMER NUR EINS OFFEN
Vorher liessen sich beliebig viele Protokolle gleichzeitig aufklappen
-- die Seite wurde so lang, dass die Liste darunter aus dem Blick
geriet. Ein neu geoeffnetes Gespraech schliesst jetzt das vorherige.
Beim Laden ist alles zu.
GEPRUEFT: server/pruef-protokoll-loeschen.mjs, 20 Pruefungen. Die
Zurueck-Pruefung misst an EINZAHL gegen MEHRZAHL ("1 Gespraech HAT" gegen
"2 Gespraeche HABEN") -- die Zahl selbst steht in einem eigenen Feld und
taucht im Fliesstext nicht auf. Drei Gegenproben: dass der Hinweis nach
dem Reparieren ueberhaupt noch anschlaegt (sonst waere "verschwunden"
auch bei kaputtem Hinweis gruen), dass eine Managerin 403 bekommt und das
Protokoll danach unveraendert dasteht, und dass der Loeschknopf bei ihr
gar nicht erst gezeichnet wird. Bestehende Laeufe gruen: Startansicht 133,
Rollen 97, Kalender 84, Serien 67, Protokoll-Klappe 52, Handy 50, Ampel
47, Freie Namen 32, Code 17.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
fc26597083 |
Wer sich einen neuen Code gibt, sperrt sich nicht mehr selbst aus
Gemeldet: "ich hab einen neuen code fuer mich gemacht aber ich wurde raus
gekickt bevor ich den neuen code kopieren konnte jetzt komm ich nicht mehr
rein."
DER FEHLER
Ein neuer Code beendete ALLE Sitzungen der Person -- auch die, in der der
Code gerade auf dem Bildschirm stand. Der naechste Aufruf der Seite lief in
ein "nicht angemeldet", die Umleitung zur Anmeldung nahm den Kasten samt
Code mit, und der Code ist nirgends noch einmal abrufbar (in der Datenbank
steht nur seine Pruefsumme). Ergebnis: ausgesperrt, Rueckweg nur ueber
einen Eingriff auf dem Server.
Bitter daran: Die Rueckfrage sagte das sogar an ("Deine aktuelle Sitzung
wird sofort beendet") -- als Warnung formuliert, nicht als Fehler erkannt.
Ein Ablauf, den man nur mit gutem Timing ueberlebt, ist keiner.
DREI RIEGEL, NICHT EINER
1. DIE EIGENE SITZUNG BLEIBT. codeNeu() beendet weiterhin alle Sitzungen
der Person -- ausser der einen, aus der heraus der Code gerade erneuert
wird. Sicherheitlich kostet das nichts: Wer den Code tauscht, hat sich
mit genau dieser Sitzung soeben ausgewiesen und haelt sie in Haenden.
Alle ANDEREN Geraete fliegen weiterhin hinaus -- das ist der Sinn der
Uebung und wird eigens geprueft.
2. DER KASTEN BLEIBT STEHEN. Solange ein frischer Code angezeigt wird,
springt die Personenseite nicht mehr von selbst zur Anmeldung. Selbst
wenn eine Sitzung aus einem anderen Grund endet (Zeitablauf, Neustart),
bleibt der Code lesbar, bis er weggeklickt ist -- mit einem Hinweis,
ihn jetzt abzuschreiben. Ein Code, den man nicht mehr lesen kann, ist
schlimmer als gar keiner.
3. EINE TUER VON AUSSEN: tools/notfall-code.sh. Setzt auf dem Server einen
neuen Code, zeigt ihn an und loescht die Sperre nach acht Fehlversuchen
gleich mit. Weigert sich, als root zu laufen (sonst gehoerten die
Hilfsdateien der Datenbank danach root und der Dienst koennte nicht
mehr schreiben). Dokumentiert als "Fall 0" in WIEDERHERSTELLUNG.md --
dem ersten Fall, den man aufschlaegt, wenn nichts kaputt ist ausser
dem Zugang.
KEIN fest hinterlegter Notfall-Code in der Anwendung: Der waere eine
Hintertuer, die dauerhaft offensteht, fuer jeden der sie findet, ohne
dass es auffiele. Dieser Weg verlangt Zugang zum Server, hinterlaesst
einen Protokolleintrag, und es gibt nichts zu erraten.
Die Rueckfrage sagt jetzt, was wirklich passiert, statt vor etwas zu
warnen, das nicht mehr eintritt.
GEPRUEFT: server/pruef-code.mjs, 17 Pruefungen -- darunter die Gegenprobe,
dass das ZWEITE Geraet derselben Person sehr wohl abgemeldet wird (ohne sie
waere die Reparatur auf dem Weg, einen neuen Code zur Formalie zu machen),
dass der alte Code nicht mehr gilt, dass beim Erneuern eines FREMDEN Codes
weiterhin alles hinausfliegt, und dass die Seite nach dem Erzeugen nicht
zur Anmeldung springt. Das Notfall-Skript ist mit beiden Wegen getestet
(Treffer und unbekannter Name). Bestehende Laeufe gruen: Rollen 97,
Personen-Liste 33, Sicht 48.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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]>
|
