f9bf7d5674ce4e8d7a023a45676fccfc31f3d38a
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
372a0eb95a |
Ampel und Rueckmeldungen - bewerten darf nur die Betreuung
Der Wunsch: "der Creator sieht, ob es gut ist oder schlecht. Und wenn nicht gut, dann muss es verbessert werden -- und nur der Ansprechpartner kann das aendern. Die Creator koennen nur Nachrichten hinterlassen zum Kommunizieren." ZWEI GETRENNTE DINGE, und sie getrennt zu halten ist der ganze Punkt: DIE AMPEL ist eine Beurteilung. Sie gehoert dem Betreuer, und nur er setzt sie. Koennte ein Creator sich selbst auf gruen stellen, waere sie wertlos -- dann stuende ueberall gruen. Der Server lehnt es mit 403 ab und sagt dabei, wer es kann. DIE NACHRICHT ist ein Gespraech. Sie gehoert beiden. Ein Creator, der auf eine Bewertung nicht antworten kann, bekommt ein Urteil statt einer Betreuung. DREI STUFEN, NICHT FUENF. Eine Zahl von 1 bis 5 klingt genauer und ist es nicht: Niemand kann den Unterschied zwischen 3 und 4 erklaeren, und am Ende steht ueberall die 3. Die Frage lautet "reicht das schon?", und darauf gibt es drei ehrliche Antworten -- passt so, noch verbessern, noch nicht angesehen. "NOCH VERBESSERN" VERLANGT EINE BEGRUENDUNG. Eine Bewertung, mit der der Creator nichts anfangen kann, ist nicht streng, sondern nur entmutigend. Der Server lehnt sie ohne Grund ab; die Oberflaeche fragt deshalb gleich danach, statt hinterher eine Fehlermeldung zu zeigen. "Passt so" braucht keinen -- da gibt es nichts zu erklaeren. Die Stufe steht IMMER an der Karte, auch fuer den Creator, auch wenn sie "noch nicht angesehen" lautet. Er soll sehen, wo er steht, ohne fragen zu muessen. Der Grund steht daneben in voller Breite, nicht in einer Ecke. FREMDE NACHRICHTEN BLEIBEN STEHEN -- auch fuer DogFather. Ein Gespraech nachtraeglich umzuschreiben waere schlimmer, als eine unbedachte Aeusserung stehen zu lassen. Wer etwas richtigstellen will, schreibt eine neue. VORLAGEN AUCH FUER COMMUNITY UND TECHNIK (Screens 11 und 12): 14 Moderations-, Aktions- und Konfliktpunkte, 12 Technikpunkte. Ton steht vorn, weil schlechter Ton der Grund Nummer eins ist, warum Leute einen Stream verlassen. Die drei Bereiche laufen jetzt ueber EINE Zuordnung statt drei fast gleicher Bloecke -- sonst weicht der dritte irgendwann ab. Die beiden alten Zweige wurden entfernt: Toter Code, den man stehen laesst, wird beim naechsten Mal fuer lebenden gehalten. Die Ampeln einer ganzen Liste kommen in EINER Abfrage. Zwanzig Eintraege einzeln zu fragen waeren zwanzig Anfragen, und die Seite ruckelte sichtbar beim Aufbau. Die Sichtbarkeitspruefung laeuft dabei je Eintrag, nicht einmal pauschal -- ein fremder Eintrag taucht auch in der Sammelabfrage nicht auf. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5960f6e3c4 |
Unterweisungen mit beidseitiger Bestaetigung - und einer echten Sperre
Der Wunsch: "jeder Scout, Manager oder DogFather muss mit seinen
Creatorn die PDFs durchgehen, und beide druecken dann auf verifiziert,
so dass wir den Beweis haben -- und das ist danach auch nicht mehr zu
aendern."
Das ist kein Haekchen, das ist ein NACHWEIS. Wer so etwas baut, muss
drei Fragen beantworten, sonst ist er wertlos:
WER hat bestaetigt? Beide Seiten getrennt, mit Name, Zeitpunkt und IP.
Eine einzelne Bestaetigung reicht nicht -- "ich habe es ihm gezeigt" und
"er hat es mir gezeigt" sind zwei verschiedene Aussagen, und erst
zusammen ergeben sie einen Beweis. Bestaetigt nur einer, steht die
Unterweisung sichtbar als HALB da, in einer eigenen warnenden Farbe.
Diese Zwischenstufe sichtbar zu machen ist der Punkt: Ein Nachweis, bei
dem nur einer unterschrieben hat, sieht sonst aus wie fertig -- und man
merkt es erst, wenn jemand danach fragt.
WORAUF genau? Nicht auf "die Regeln", sondern auf eine bestimmte Datei.
Beim Bestaetigen wird der SHA-256 der PDF-Datei mitgespeichert. Tauscht
spaeter jemand die Datei aus, passt der Fingerabdruck nicht mehr, und
die Seite sagt das auch ("Das Dokument wurde seit der Bestaetigung
ausgetauscht"). Ohne diesen Wert waere die Bestaetigung ein Zettel ohne
Bezug.
IST ES UNVERAENDERT? Eine abgeschlossene Bestaetigung laesst sich nicht
mehr aendern und nicht loeschen -- und zwar nicht, weil der Code es
nicht anbietet, sondern weil die DATENBANK es ablehnt. Zwei Trigger mit
RAISE(ABORT). Ein Schutz, der nur im Code steht, ist beim naechsten
neuen Weg zur Datenbank wieder weg.
DER VOLLZUG WURDE DURCHGESPIELT. Aus RunOne stammt die Lehre, dass ein
Weg, den man nicht rueckgaengig machen kann, tagelang live sein und NIE
gelaufen sein kann. Die Pruefung bestaetigt deshalb wirklich, schliesst
ab, und versucht dann eine Aenderung -- ueber die Schnittstelle UND
direkt auf der Datenbank. Beide werden abgelehnt.
Und die GEGENPROBE dazu: Der Trigger wird entfernt, dieselbe Aenderung
versucht -- sie geht durch -- und der Trigger wieder gesetzt. Eine
Sperre, die man nicht hat scheitern sehen, ist keine Sperre.
Der Server entscheidet anhand der ROLLE, welche Seite gesetzt wird --
nicht der Absender. Sonst koennte ein Creator die Bestaetigung seines
Betreuers eintragen, und der ganze Nachweis waere wertlos. Eine bereits
gesetzte Seite wird nie ueberschrieben; ein Datum laesst sich also auch
nicht nachtraeglich verschieben.
Die Dokumente kommen aus der Wissens-Bibliothek, es gibt keinen zweiten
Upload-Weg. Sonst gaebe es Dateien, die nur hier existieren -- und
niemand wuesste, welche Fassung die richtige ist. Eine Unterweisung wird
nie geloescht, nur abgeschaltet: Die Nachweise haengen daran.
EIN EIGENER FEHLER, VON DER BROWSERPRUEFUNG GEFUNDEN: Der Aufruf der
Zusatzbloecke stand NACH einem return. laden() steigt frueh aus, wenn
die Liste leer ist -- und dann wurden Vorlagen und Unterweisungen nie
gebaut. Also ausgerechnet auf der leeren Seite, fuer die sie gedacht
sind. Jetzt stehen sie in einem finally.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
fc4fde0f02 |
Buehnen hell, Flaechen dicht - und die Kopfleiste wieder kurz
DIE BUEHNEN WAREN ZU DUNKEL. Bei 0.42 Helligkeit sah man Schemen, nicht die Szene -- "zu dunkel und sieht ganz komisch aus" traf es genau. Jetzt 0.66 mit etwas mehr Farbe (1.08), die Vignette schwaecher (0.52 statt 0.72). Die Bilder kommen durch. MOEGLICH IST DAS NUR MIT DEM GEGENZUG: Alle Kacheln, Karten und Spalten lagen bei 2 bis 3 Prozent WEISS -- also praktisch durchsichtig. Solange der Hintergrund fast schwarz war, fiel das nicht auf; sobald er hell wurde, lief das Bild mitten durch den Text. Jetzt gibt es --flaeche (rgba(9,13,22,.78)), eine deckende dunkle Flaeche, und 44 Stellen in 16 Dateien holen sich ihre Farbe von dort. Der Unterschied ist genau der, den Filipe beschrieben hat: Der Hintergrund bleibt sichtbar, aber ZWISCHEN den Kacheln -- nicht hinter der Schrift. Wer die Flaechen kuenftig dichter oder durchlaessiger will, aendert eine einzige Zeile statt 44. Die Kacheln selbst tragen ihren Farbton jetzt AUF der Flaeche (color-mix mit --flaeche statt mit transparent) -- dadurch bleibt die Farbe erkennbar, ohne dass die Kachel durchsichtig wird. DIE KOPFLEISTE war so breit wie das ganze Fenster, obwohl der Text kurz ist: .marke__text stand auf flex: 1 1 auto. Das war unsichtbar, solange der Schriftzug nur Text war -- seit er einen Rahmen traegt, lief die Pille quer durchs Bild. Jetzt flex: 0 1 auto (schrumpfen ja, wachsen nein). Gemessen: 375 px statt 1280. Kontrast an echten Bildpunkten auf allen sechs Seiten nachgemessen -- haelt trotz des viel helleren Bildes (schlechtester Wert 4,69:1). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
8647138bb4 |
Leere Seiten sehen nicht mehr kaputt aus
Die vier Aufgaben-Spalten waren vier graue Kaesten mit je einem
Gedankenstrich darin. Das sieht aus, als sei die Seite kaputt -- dabei
ist eine leere Spalte ein voellig normaler, oft sogar guter Zustand.
Jetzt hat jede Spalte ihre eigene Farbe nach STATUS (offen blaugrau,
in Arbeit blau, Review gold, erledigt gruen), einen auslaufenden
Streifen oben in dieser Farbe und eine Zeile, die erklaert, was die
Spalte ueberhaupt bedeutet -- "Review" allein sagt einem Neuen nichts.
Statt des Gedankenstrichs steht ein Satz, der die AUSSAGE des
Leerseins traegt: eine leere Review-Spalte bedeutet etwas anderes als
eine leere Erledigt-Spalte.
NEUN KOPIEN DERSELBEN REGEL. .leer-hinweis war in neun CSS-Dateien
definiert -- neunmal fast dasselbe, mit Abstaenden von 22, 26 und 30 px,
weil beim Kopieren jedes Mal etwas anders wurde. Genau davor warnt ein
Kommentar in start.css seit August ("Was auf mehreren Seiten benutzt
wird, gehoert hierher"). Jetzt einmal zentral, und jede Seite hat sie.
Und sie sieht anders aus: Der gestrichelte Rand ist weg. Gestrichelte
Raender sagen "hier fehlt etwas", grau auf grau sagt "unwichtig" --
zusammen also "kaputte Seite". Stattdessen eine ruhige, geschlossene
Flaeche im Farbton der Seite (aus data-ton, also aus der Kachelfarbe)
mit einem leuchtenden Ring. Ein Zeichen waere hier zu laut: Es geht ja
gerade darum, dass nichts da ist -- der Ring markiert die Stelle, ohne
etwas zu behaupten.
Kontrast danach nachgemessen: 4,85:1 im schlechtesten Fall.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGit
|
677bcb5653 |
Workspace: neues Knopf-System "Geschliffen" -- ueberall, eine Stelle
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.
|
||
|
DogFatherGit
|
df9f87af0a |
Workspace: Phase 2 -- LIVE, Content, Technik, Community, Schutz
Fuenf Bereiche auf einmal, aber NICHT fuenf Module. Im Deck haben sie dieselbe Grundform: Eintraege zu einem Creator mit Art, Datum, Titel, Text und Status. Sie unterscheiden sich nur darin, welche Arten es gibt und ob eine Bewertung oder eine Dringlichkeit dazugehoert. Deshalb ein gemeinsamer Unterbau: eine Tabelle, eine Sichtbarkeitsregel, eine Pruefung, eine Ansichtsseite (bereich.html?b=live). Ein Fehler laesst sich damit an EINER Stelle beheben statt an fuenf, und ein weiterer Bereich waere ein Eintrag in BEREICHE -- kein neues Modul. Arten woertlich aus dem Deck (Seiten 7-12): live Vorbereitung / Waehrend LIVE / Auswertung + Bewertung 1-5 content Idee / Produktion / Veroeffentlicht technik Setup / Problem / Loesung / Anleitung + Dringlichkeit community Moderation / Aktion / Konflikt + Dringlichkeit schutz Richtlinie / Vorfall / Eskalation / Gelernt + Dringlichkeit Die Oberflaeche kennt die Bereiche nicht auswendig -- welche Arten und Zusatzfelder es gibt, sagt der Server in der Antwort. Geprueft, und zwar fuer alle fuenf gleichzeitig: - Sichtbarkeit: Chef sieht alles, Luna nur ihren Bereich, Mika nur seinen, Sam (Scout) gar nichts (404 -- Scouts haben mit der Creator-Betreuung nichts zu tun) - Luna legt Eintrag mit creator_id=Mika an: landet still in ihrem eigenen Bereich, Mika sieht ihn nicht - Luna auf Mikas Eintrag: 404; Luna loescht Chefs Eintrag ueber ihren Bereich: 403 (loeschen darf das Management und wer ihn schrieb -- sonst koennte ein Creator eine Notiz ueber sich verschwinden lassen) - Eintrag ueber den falschen Bereich in der Adresse ansprechen: 404 - unbekannte Art 400, Bewertung 9 (erlaubt 1-5) 400, unbekannter Bereich 404, fremde Herkunft 403 Beim Testen sahen Umlaute zunaechst zerstoert aus (efbfbd, das Unicode-Ersatzzeichen). Ursache war der curl-Aufruf: Git Bash kodiert $'\xc3\xbc' nach Locale um. Ueber den echten Weg (Browser) kommen Umlaute, ss und Gedankenstrich unveraendert an und liegen sauber in der Datenbank -- gegengeprueft auf Byte-Ebene. |