3 Commits

Include renames

Author	SHA1	Message	Date
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.	2026-08-28 12:13:11 +02:00
DogFatherGit	45cd0ae226	Workspace: Calls & Meeting-Protokolle -- Phase 3 vollstaendig ... /workspace/calls.html. Calls sind KEINE eigene Terminart neben dem Kalender, sondern dieselben Termine mit art = 'call' oder 'review'. Ein zweiter Terminspeicher waere die sichere Art, irgendwann zwei widerspruechliche Uhrzeiten zu haben. Diese Seite fuegt nur hinzu, was ein Gespraech vom blossen Termin unterscheidet: das Protokoll danach. Die Sichtbarkeitsregel ist Wort fuer Wort dieselbe wie im Kalender -- ein Termin darf nicht in der einen Ansicht auftauchen und in der anderen fehlen. Der tragende Satz von Seite 13, woertlich genommen: "Jeder Call endet mit klaren To-dos, die direkt ins Board uebernommen werden." To-dos werden deshalb NICHT als Text im Protokoll abgelegt, sondern sofort zu echten Aufgaben -- mit dem Gespraech als Herkunft in der Beschreibung, zugeordnet an das Gegenueber des Calls. Sonst steht die Verabredung in einem Dokument, das niemand mehr oeffnet. Geprueft: Protokoll geschrieben -> Aufgaben stehen im Brett. Weitere Punkte: - Reihenfolge der Gruppen ist Dringlichkeit, nicht Chronologie: Ganz oben stehen vergangene Gespraeche OHNE Protokoll. Das ist der einzige Zustand, der etwas von einem verlangt. Nur diese Gruppe ist optisch hervorgehoben; wenn alles schreit, sieht man nichts mehr. - Ein festgehaltenes Protokoll ist danach nur noch lesbar. Ein Gespraech nachtraeglich umschreiben zu koennen waere genau das, was ein Protokoll wertlos macht. - "Naechster Termin" legt den Folgetermin direkt in den Kalender -- mit demselben Gegenueber und demselben Meeting-Link. - Alles in EINER Transaktion. Geprueft mit einem absichtlich kaputten To-do: kein Protokoll, keine halben Aufgaben, kein Folgetermin. - Enter im To-do-Feld legt die naechste Zeile an, damit man eine Liste tippen kann, ohne zur Maus zu greifen. - Meeting-Link nur bei anstehenden Gespraechen und nur, wenn es wirklich eine http(s)-Adresse ist. "bei mir zu Hause" bleibt schlichter Text. Zur Videotechnik selbst bewusst KEINE Entscheidung getroffen: Ein eigener WebRTC-Raum braucht einen TURN-Server, damit Verbindungen hinter Mobilfunk-NAT zustande kommen. Das ist eine Infrastrukturfrage mit laufenden Kosten und gehoert besprochen, nicht nebenbei entschieden. Bis dahin traegt der Termin einfach den Link des Dienstes, der ohnehin benutzt wird. Nebenbei: .knopf-still lag in scouting.css und fehlte dadurch auf calls.html -- dort standen prompt nackte Systemknoepfe. Der Baustein gehoert ins gemeinsame start.css, dort liegt er jetzt.	2026-08-28 11:06:37 +02:00
DogFatherGit	d845d91d70	Workspace: Scout-CRM -- Pipeline, Follow-ups und Uebergabe ... /workspace/scouting.html. Erster Baustein aus Phase 3 und der Bereich, in dem Scouts bisher praktisch nichts hatten. Der Merksatz von Seite 15 ist hier die Sicherheitsregel, nicht nur eine Beschreibung: "Scouts sehen ihre Pipeline -- die Admin-Rolle die Gesamtuebersicht -- Creator keine Scout-internen Daten." - Creator bekommen 404, nicht 403, und zwar auf Schnittstelle UND Seite. Sie sollen nicht einmal erfahren, dass es den Bereich gibt. - Ein Scout sieht ausschliesslich die eigene Pipeline. Geprueft: Patrick bekommt auf Sams Lead 404 beim Lesen, Aendern und Loeschen. - Das Management sieht alles, kann nach Scout filtern und Leads einem Scout zuordnen. Pipeline als gruppierte Liste, nicht als Board: Sechs Spalten waeren auf dem Handy unbedienbar, und Scouts arbeiten unterwegs. Jede Stufe traegt eine eigene Farbe an der linken Kante, die von kuehl (neu entdeckt) nach gruen (uebergeben) laeuft -- die Richtung der Pipeline wird sichtbar, ohne Ampel-Geblinke. Jede Karte hat genau EINEN naheliegenden Schritt ("Weiter zu ..."), der Rest steckt im aufklappbaren Teil. Der Weiter-Knopf traegt bewusst nur die Farbe seiner Stufe statt des vollen Farbverlaufs, sonst waere die Seite ein Streifenmuster aus identischen Leuchtbalken. Faellige Follow-ups stehen als eigene Leiste ganz oben. Das ist der Teil, der ohne System am ehesten untergeht -- nicht der Kontakt selbst, sondern das Nachfassen. Uebergabe ("Creator-Onboarding starten", Seite 15): Aus einem uebergebenen Lead legt das Management mit einem Klick eine echte Person mit Zugangscode an. Der Code wird genau einmal angezeigt, wie in der Personenverwaltung. Die Qualifizierung des Scouts (Plattform, Handle, Potenzial, LIVE-Aktivitaet) wandert dabei automatisch ins Creator-Profil -- sonst muesste das Management abtippen, was laengst dasteht. Geprueft: Lead -> Person -> Profil, alle drei verbunden, zweiter Versuch wird abgelehnt. Ein uebergebener Lead ist Teil der Betreuungsgeschichte -- den loescht nur das Management, nicht der Scout (403). Nebenbei: .knopf-still gab es im Baukasten noch gar nicht, die Zweit- knoepfe waren nackte Systemknoepfe. Jetzt sauber definiert.	2026-08-28 10:57:42 +02:00