Letzter offener Punkt aus dem Konzept, Seite 4: Ein Creator hat laut
Rollenbeschreibung "Aufgaben & Feedback" -- die Aufgaben gab es, das
Feedback nicht. Ohne diese Moeglichkeit endet jede Rueckfrage ausserhalb
des Systems, in WhatsApp, und damit ausserhalb dessen, was spaeter noch
nachvollziehbar ist.
Neue Tabelle aufgaben_notizen. Wer die Aufgabe sehen darf, darf auch
mitreden -- geprueft ueber DIESELBE Sichtbarkeitsregel wie fuer die
Aufgabe selbst. Eine eigene Regel gibt es bewusst nicht: Zwei Regeln
fuer dieselbe Sache laufen irgendwann auseinander, und die Aufgaben-
sichtbarkeit ist die schwierigere von beiden (Creator sieht eigene,
Scout die seiner betreuten Creator, Leitung alles).
404 statt 403, wenn die Aufgabe nicht sichtbar ist -- wer sie nicht
sehen darf, soll nicht erfahren, dass es sie gibt.
Die eigene Rueckmeldung darf jeder zuruecknehmen, fremde nur die
Leitung. Eine Rueckmeldung ist keine Abstimmung: Wer sich vertippt hat,
soll das nicht bei jemandem beantragen muessen.
Der Knopf auf der Karte zeigt die ANZAHL, nicht nur ein Symbol -- so
sieht man ohne Aufklappen, wo schon etwas besprochen wurde, und die
Karte bleibt trotzdem ruhig. Aufgeklappt wird direkt an der Karte, nicht
in einem Fenster: Man liest die Rueckmeldungen im Zusammenhang mit der
Aufgabe, sonst fehlt beim Antworten die Haelfte.
Geprueft:
- Chef und Luna schreiben sich gegenseitig, beide sehen beides
- Mika (fremder Creator) bekommt 404 beim Lesen UND beim Schreiben
- ohne Anmeldung 401, fremde Herkunft 403, leerer Text abgewiesen
- Luna kann Chefs Rueckmeldung nicht loeschen, ihre eigene schon
- Chef kann alle loeschen
- Zaehler auf der Karte stimmt, Handy ohne Ueberlauf, 0 Konsolenfehler
URSACHE ZUERST: .feld--breit stand in DREI HTML-Dateien (wissen,
scouting, dateien) -- und war NIE im CSS definiert. Das Raster
(auto-fit, minmax(170px)) gab deshalb jedem Feld dieselbe Breite, egal
was drin steht: Der Titel war so schmal wie eine Auswahl, lange
Kategorienamen wurden abgeschnitten ("1. TikTok - Grundla"), und die
Tag-Vorschlaege stapelten sich zu einer halben Seite.
Jetzt zwoelf Spalten statt auto-fit. Damit laesst sich sagen, WIE breit
ein Feld sein soll: Titel, Beschreibung und Kategorie ueber die ganze
Zeile, Stufe/Geraet/Datum zu dritt nebeneinander. Unter 860 px zwei
Spalten, unter 560 px eine. Die Klasse ist zentral definiert, also
wirken die drei betroffenen Seiten sofort mit.
Gemessen danach: Titel/Beschreibung/Kategorie je 1058 px, die drei
kleinen je 342 px, Kategorie nicht mehr abgeschnitten.
PDF-ABLAGE statt nacktem Dateifeld. Der Browser-Knopf war abgeschnitten
("K...") und sah aus wie ein Fremdkoerper. Jetzt eine eigene Flaeche:
Klicken, Ziehen oder Tastatur. Sie markiert sich gruen, sobald eine
Datei drin ist, prueft schon im Browser auf PDF und schlaegt den
Dateinamen als Titel vor, wenn der noch leer ist.
Sie steht bewusst GANZ OBEN: Man laedt etwas hoch und beschreibt DANN,
was es ist -- nicht umgekehrt.
SCHALTER statt Kaestchen fuer "besonders wichtig". Ein Kaestchen von 17
Pixeln ist auf dem Handy kaum zu treffen und sagt nicht, was passiert.
Der Schalter ist gross, zeigt seinen Zustand in Gold (dieselbe Farbe wie
die Marke "Wichtig" spaeter) und erklaert sich in einer Zeile:
"Erscheint zusaetzlich ganz oben unter Neu & wichtig".
Tag-Vorschlaege kompakter: von zehn Zeilen auf zwei.
Geprueft: Handy ohne Ueberlauf, 0 Konsolenfehler, Dateiwahl markiert die
Flaeche und fuellt den Titel, Schalter schaltet.
Von Filipe aus drei gerenderten Entwuerfen gewaehlt (A Kante & Glut,
B Geschliffen, C Praegung). Raten hilft hier nicht -- beim Zurueck-Knopf
hat erst der direkte Vergleich zum Ziel gefuehrt.
Aufbau: farbiger Verlaufsrand (padding-box/border-box) und ein feiner
heller Streifen obenauf -- wie eine angeschliffene Kante. Die Farbe sitzt
im Rand und in der Schrift, die Flaeche bleibt dunkel. Beim Zeigen hebt
sich der Knopf einen Pixel an und bekommt einen weichen farbigen Schein
darunter. Die Hauptaktion einer Seite ist zusaetzlich gefuellt.
JEDE AKTION HAT IHRE EIGENE FARBE:
gruen passt, erledigt, freigegeben
amber ausbaufaehig, wartet
rot Handlungsbedarf, loeschen
blau speichern
violett anlegen
gold Onboarding -- der einzige Schritt, der eine Person anlegt
grau abbrechen, schliessen
Stufenfarbe fuer den Weiter-Knopf der Scout-Pipeline
DAS IST JETZT DIE EINZIGE STELLE, AN DER KNOEPFE GESTALTET WERDEN.
Vorher standen sie in NEUN Dateien verstreut, und prompt sahen dieselben
Knoepfe auf verschiedenen Seiten verschieden aus. Alle alten
Definitionen sind entfernt; wer einen neuen Knopf braucht, nimmt eine
Farbklasse und schreibt kein CSS. Gilt ab jetzt auch fuer alles, was
noch dazukommt.
Geprueft ueber alle elf Seiten: 172 sichtbare Knoepfe, kein einziger
ungestylt, kein Kontrast unter 4,5:1.
Drei Sachen, die dabei aufgefallen sind:
1. Der neutrale "Abbrechen"-Knopf hatte halbdurchsichtiges Weiss als
Farbwert -- gemessen 1,1:1 Kontrast, praktisch unlesbar. Neutral hat
jetzt einen echten Farbwert (#8e9cb0).
2. Die Filter-Knoepfe (Kalender, Dateien, Bereiche) hatten eine eigene
"gedrueckt"-Regel mit flaechiger Farbe, die den geschliffenen Rand
ueberschrieb. Sie benutzen jetzt den gefuellten Auftritt des Systems.
3. Der Bearbeiten-Stift auf den Aufgabenkarten war nie ein richtiger
Knopf, sondern nackter Text ohne Rand -- man sah nicht, dass man
draufdruecken kann. Jetzt im System, in der kleinsten Groesse.
Der Zurueck-Knopf ("Neon-Kante") bleibt wie er ist -- den hat Filipe
selbst ausgesucht, und er ist ein Navigationselement, keine Aktion.
Messhinweis fuer spaeter: color-mix liefert computed color(srgb ...),
das laesst sich NICHT als Text auslesen. Die erste Messung meldete
faelschlich 1,13:1 fuer 49 Knoepfe. Richtig geht es ueber eine Leinwand
(fillStyle + getImageData).
Alle Toene bewusst gedeckt statt neon, alles respektiert
prefers-reduced-motion.
Die aufgeklappte Liste eines <select> zeichnet der Browser selbst, CSS
erreicht sie nicht. Ohne Hinweis geht er von einer hellen Seite aus und
malt sie weiss -- die helle Schrift darauf war praktisch unlesbar
(gemeldet mit Screenshot).
Behebung ueber color-scheme: dark auf <html>. Das ist der Schalter fuer
alles, was der Browser selbst zeichnet: Auswahllisten, Datumskalender,
Bildlaufleisten, Textmarkierung. Zusaetzlich sind Hintergrund und
Schriftfarbe an <option> gesetzt, weil aeltere Browser und manche
Linux-Oberflaechen color-scheme nur teilweise beachten.
Damit entfallen die beiden filter: invert(.75) am Kalendersymbol der
Datumsfelder -- der Browser zeichnet es jetzt schon hell, invert haette
es wieder verdunkelt.
Nur statische Dateien, kein Neustart noetig.
Aufgaben:
- Bearbeiten-Dialog (Titel, Beschreibung, Prioritaet, Frist, Zuordnung).
Als natives <dialog>: Fokusfang, Esc zum Schliessen und Abdunklung
ohne eigenen Code.
- Loeschen nur fuer Management, mit Rueckfrage und Protokolleintrag.
Das Konzept will, dass Erledigtes stehen bleibt -- Loeschen ist der
Ausnahmefall fuer Fehleintraege, nicht der normale Abschluss.
Personen (/workspace/personen.html, nur Management):
- Anlegen, Code erneuern, sperren/entsperren, Protokollansicht
- Der Code wird genau einmal in der Antwort zurueckgegeben, nie
gespeichert; beim Schliessen auch aus dem Dokument entfernt
- Selbstschutz: niemand kann sich selbst sperren, und das letzte aktive
Management laesst sich nicht sperren -- sonst kaeme niemand mehr hinein
- Code fuer sich selbst tauschen nur mit ausdruecklicher Bestaetigung,
weil es die eigene Sitzung sofort beendet
Zwei Fehler, die beim Testen aufgefallen sind:
1. Rollenpruefung fehlte beim Ausliefern der Seiten. Ein Creator bekam
personen.html mit HTTP 200 -- die Schnittstellen wiesen ihn zwar ab,
das Geruest der Seite war aber sichtbar. GESCHUETZT ist jetzt eine
Zuordnung Pfad -> erlaubte Rollen statt einer blossen Liste.
2. Das Protokoll nannte den falschen Verursacher. personAnlegen trug die
NEU ANGELEGTE Person als person_id ein, der Eintrag las sich also so,
als haette sie sich selbst angelegt. Akteur und Betroffener sind jetzt
getrennt: Akteur in person_id, Betroffener im Text. Ueber die
Kommandozeile angelegte Personen zeigen korrekt keinen Akteur.
Erster echter Arbeitsbereich aus dem Konzept. Kanban mit offen / in
Arbeit / Review / erledigt, dazu Prioritaet, Frist, Verantwortlicher und
Zuordnung zu einem Creator-Bereich.
Kern ist die Datentrennung, und die sitzt AUSSCHLIESSLICH im Server --
in jeder einzelnen Abfrage, an einer Stelle definiert (sichtbar()):
admin sieht alles
creator sieht seinen Bereich und was ihm zugewiesen ist
scout sieht nur, was ihm zugewiesen ist
Geprueft mit vier Testkonten:
- Chef sieht 4, Luna 2, Mika 1, Sam 1 Aufgaben
- Luna auf Mikas Aufgabe: 404 (nicht 403 -- sonst liesse sich durch
Ausprobieren herausfinden, welche Nummern es gibt)
- Luna legt Aufgabe mit creator_id=Mika an: wird still auf ihren eigenen
Bereich umgebogen, Mika sieht sie nicht
- Anfrage mit fremdem Origin: 403
- ohne Anmeldung: 401, ungueltiger Status/leerer Titel: 400
- Scout bekommt in der Personenliste nur sich selbst
- Dashboard-Zahlen je Rolle korrekt eingegrenzt
Weitere Punkte:
- Texte werden im Browser nur ueber textContent gesetzt, nie innerHTML --
ein Aufgabentitel darf keine Auszeichnung einschleusen
- ueberfaellig = Frist vorbei UND nicht erledigt; die Kachel faerbt sich
nur, wenn wirklich etwas ansteht
- erledigt_am wird gesetzt bzw. wieder geleert, wenn eine Aufgabe
zurueckgeholt wird
- Erledigtes verschwindet nicht, wie im Konzept gefordert
DogFatherGit