Nach der Korrektur von CPUQuota (50% -> 200%) ist die KI benutzbar:
nr_throttled steht bei 0 (vorher 1752 von 1801 Zeitfenstern).
Gemessen NACH der Korrektur:
To-dos aus einem Protokoll : 12,7 s (vorher: Abbruch nach 45 s)
Website waehrend der Arbeit: 0,063 s -- Basis war 0,068 s
Kein Einfluss auf die Website, wie bei der ersten Messung mit zwei
echten Kernen vorhergesagt.
DREI KNOEPFE, alle nach demselben Muster:
- Calls: "To-dos vorschlagen" liest, was im Protokoll schon steht, und
fuellt LEERE To-do-Zeilen. Bereits Getipptes wird nie ueberschrieben.
- Start-Check: "Besser formulieren" macht aus einer Notiz einen
Aufgabentitel. Der einfache Vorschlag (erster Satz der Notiz) bleibt
daneben bestehen -- er funktioniert auch ohne KI.
- Report: "In Worte fassen" fasst die Zahlen in drei Saetzen zusammen.
IST DIE KI AUS, GIBT ES DEN KNOPF NICHT. Jede Seite fragt beim Laden
einmal nach. Ein Knopf, der immer eine Fehlermeldung bringt, ist
schlimmer als gar kein Knopf.
Die Absicherung steht in EINER Datei (assets/js/ki.js), nicht dreimal.
Der Knopf sagt waehrend der Arbeit "Die KI denkt ..." und der Funke
pulst -- zwoelf Sekunden ohne Rueckmeldung fuehlen sich sonst an wie
ein Fehler.
Optisch bewusst ANDERS als die normalen Knoepfe: gestrichelter Rand
statt geschliffener Kante. Ein KI-Knopf tut nichts Endgueltiges, er
schlaegt vor -- das soll man auf den ersten Blick sehen.
ZWEI VERBESSERUNGEN AUS DEM TEST:
1. Der Bereichsname wurde dem Modell mitgegeben und klebte prompt in
der Antwort: "LIVE-Struktur auf 18 und 21 Uhr festlegen". Ohne ihn
kommt eine echte Handlung heraus. Der Befund allein reicht -- er
steht ja ohnehin im richtigen Bereich. Variable entfernt, kein toter
Code.
2. Der Report gab dem Modell "ueberfaellig" ohne Umlaut vor und bekam
es genauso zurueck. Jetzt richtig geschrieben.
Geprueft: Calls 7 s und drei brauchbare To-dos, Start-Check erzeugt
einen Titel, Report drei Saetze, 0 Konsolenfehler.
Auf Wunsch von Filipe. Betrifft ausschliesslich die Anzeige.
Der Rollenschluessel bleibt "admin". Er steckt in der CHECK-Regel der
Datenbank, in jeder bestehenden Sitzung und in jeder Rechteabfrage --
ihn umzubenennen haette alle drei gebrochen, und bestehende Anmeldungen
waeren ungueltig geworden. Umbenannt wird nur, was man LIEST.
Der Anzeigename steht jetzt an EINER Stelle (ROLLEN_NAME in
workspace.js) und kommt ueber /workspace/api/ich als rolle_name mit.
Stand er in elf Dateien, waere er beim naechsten Mal in zehn davon
geaendert.
Dabei aufgefallen: In der Kopfleiste stand auf JEDER Seite der rohe
Rollenschluessel -- "Chef · admin". Das war schon vorher unschoen, faellt
aber jetzt erst richtig auf. Alle elf Seiten zeigen jetzt "Chef ·
DogFather". Geprueft: kein rohes "admin" mehr in der Oberflaeche.
Geaendert: Rollenkachel und Untertitel auf der Anmeldeseite, Kopfleiste
aller Seiten, Rollentext auf dem Dashboard, Rollenmarken und Auswahl in
der Personenverwaltung, die Betreuungs-Auswahl ("nur DogFather"), der
Hinweis auf der Dateienseite, die Erklaerung zur internen Notiz im
Profil, die Hinweise fuer Scouts ohne Zuteilung -- und vier
Fehlermeldungen vom Server.
Schreibweise "DogFather" wie von Filipe geschrieben; das ist auch auf
der oeffentlichen Website die haeufigste Form (717 von 1216).
In den Code-Kommentaren der Fachmodule heisst die Rolle weiterhin "das
Management". Das bleibt bewusst so -- eine Massenaenderung an vierzig
Kommentaren waere reines Risiko ohne sichtbaren Nutzen. Ein Hinweis an
der ROLLEN_NAME-Zuordnung erklaert den Zusammenhang.
/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.
DogFatherGit