138bcce80bebfd5c8bd0c4cff0e07b9aa96b2bbc
157
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 DogFatherGit
|
4d7d9b183b |
Workspace: KI-Vorschlaege in Calls, Start-Check und Report
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. |
||
|
DogFatherGit
|
401c8f006c |
Workspace: Formulare richtig ausgerichtet, PDF-Ablage und Schalter
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.
|
||
|
DogFatherGit
|
1f217041ae |
Workspace: hellere Kategoriekacheln + Dateien gezielt an mehrere Personen
ZWEI WUENSCHE VON FILIPE.
1) KACHELN BESSER SICHTBAR
Erster Versuch war zu zaghaft: die Flaeche ging nur von RGB(17,24,37)
auf (27,36,51), der sichtbare Gewinn kam fast nur vom staerkeren Rand.
Nachgemessen an echten Bildpunkten -- Seite liegt bei RGB(5,7,13).
Jetzt RGB(38,49,67), dazu kraeftigerer Rand und hellerer Symbolring.
Der Beschreibungstext stand auf --text-still und lag damit bei 3,6:1 auf
der neuen Flaeche -- zu blass fuer laufenden Text. Jetzt --text-leise,
gemessen 6,2:1.
Leere Kategorien waren mit opacity .55 fast unlesbar. Jetzt .82 -- sie
sollen erkennbar bleiben, nur zurueckhaltender.
2) DATEIEN AN MEHRERE PERSONEN GEZIELT FREIGEBEN
Bisher hatte eine Datei genau EINEN Bereich (creator_id). Damit liess
sie sich nicht zweien geben, ohne sie zweimal hochzuladen.
Neue Tabelle datei_personen (datei_id + person_id). creator_id bleibt
und behaelt seine Bedeutung: Es sagt, zu wessen BEREICH eine Datei
gehoert -- die neue Tabelle sagt, WER sie sehen darf. Zwei verschiedene
Fragen, deshalb zwei Felder.
Auswahl als einzelne Schalter, nicht als <select multiple>: Dort
verliert man mit einem Fehlklick die ganze Auswahl, und auf dem Handy
ist sie kaum bedienbar. Jeder Name ist ein Schalter, der sichtbar an
oder aus ist, eingefaerbt nach Rolle -- man sieht auf einen Blick, ob
eine Datei an Creator, Scouts oder beide geht.
Wer wen auswaehlen darf:
- DogFather jeden aktiven Menschen ausser sich selbst
- ein Scout NUR die Creator, die er betreut -- sonst koennte er sich
ueber eine Freigabe Zugang zu fremden Bereichen verschaffen
- ein Creator gar niemanden
Jede Id wird beim Speichern erneut gegen die erlaubte Auswahl geprueft.
Geprueft: Sam schickt die Ids 3, 6 und 7 mit (alles Creator, die er
NICHT betreut) -- die Datei landet bei niemandem. Kein Fehler, kein
Zugang: die Ids fallen still durch das Raster.
Weiter geprueft:
- Chef sieht alle drei Testdateien, Luna nur ihre, Sam nur seine,
Patrick keine
- Creator bekommt 403 beim Aendern von Freigaben
- Freigaben sind an jeder Datei sichtbar ("Sichtbar fuer ..."), auch
fuer die, die sie nicht aendern duerfen -- niemand soll raten muessen
- Die Auswahl wird nach dem Hochladen geleert, sonst bekaeme die
naechste Datei stillschweigend dasselbe Publikum
|
||
 DogFatherGitandClaude Opus 5
|
c0ac041122 |
Workspace: Versionsstempel gegen Cloudflares 4-Stunden-Cache
Filipe sah die neue Kachel nicht, obwohl sie live war. Ursache gemessen, nicht vermutet: Node liefert : Cache-Control: no-cache (richtig) Cloudflare macht: Cache-Control: max-age=14400 (ueberschreibt es) cf-cache-status: REVALIDATED, Server: cloudflare Cloudflares voreingestellte Browser-Cache-Zeit von vier Stunden setzt sich ueber das no-cache des Servers hinweg -- aber NUR bei JS und CSS. HTML kommt mit DYNAMIC und no-cache immer frisch durch (geprueft an /creator.html und /workspace/). Genau deshalb genuegt ein Stempel in der HTML: neue Seite -> neue Adresse -> Cloudflare kennt sie nicht -> frische Datei. Keine Cloudflare-Einstellung noetig, nichts, worauf ich warten muss. tools/workspace-stempel.mjs setzt den Stempel auf alle 71 Verweise in 13 Dateien. Der Lauf ist wiederholbar: ein vorhandener Stempel wird ersetzt, nicht angehaengt (geprueft). Gehoert ab jetzt vor jeden Deploy, der JS oder CSS im Workspace anfasst. Ich verlasse mich damit nicht mehr aufs Erinnern -- das war der eigentliche Fehler. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGit
|
1c3e642f12 |
Workspace: Rolle "Management" heisst jetzt "DogFather"
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.
|
||
|
DogFatherGit
|
516a003dc8 |
Dateien: Hochladen nur fuer Management und Scouts
Wunsch vom 28.08.2026: "die dateien sollen nur die manager oder scout
hochladen koennen aber nicht die creator."
Serverseitig ueber DARF_HOCHLADEN. Die Pruefung steht bewusst VOR
express.raw -- wer nicht darf, wird abgewiesen, bevor auch nur ein Byte
entgegengenommen wird. Sonst wanderten bis zu 25 MB durch die Leitung,
nur um danach verworfen zu werden.
Ein Creator sieht und oeffnet weiterhin die Dateien seines Bereichs.
Statt des Ablegefeldes steht dort jetzt, warum es fehlt -- ein einfach
verschwundenes Feld wirkt wie ein Fehler.
Geprueft: Management 201, Scout 201, Creator 403 mit klarer Meldung;
Creator sieht und laedt weiterhin.
--------------------------------------------------------------------
Dabei ein Fehler aufgefallen, der mehrere Seiten betraf:
Das hidden-Attribut blendet nur ueber eine sehr schwache Browserregel
aus -- JEDE eigene display-Angabe schlaegt sie. Betroffen waren:
* das Ablegefeld fuer Dateien (display: grid) -> ein Creator sah es
trotz hidden weiterhin
* die Verwaltungsfelder "Plan-Start" und "Naechster Review" im
Creator-Profil (ebenfalls grid) -> ein Creator sah sie ebenfalls
* der Zurueck-Knopf (inline-flex) -> waere vor dem Laden des Skripts
kurz sichtbar gewesen
Behoben mit einer Regel in gate.css: [hidden] { display: none !important }
Beim Profil waren nie Daten betroffen -- der Server schickt die Felder
an einen Creator gar nicht erst mit, sie waren leer. Sichtbar sein
sollten sie trotzdem nicht.
Aufgefallen ist es erst im Screenshot. Der vorige Test hatte auf das
hidden-ATTRIBUT geprueft, und das war ja gesetzt. Die Pruefung schaut
jetzt auf die tatsaechliche Sichtbarkeit (isVisible).
Ausserdem: In der Regex zum Saeubern von Dateinamen standen die
Steuerzeichen als rohe Bytes statt als Escape-Sequenz. Die Funktion
arbeitete korrekt, aber die Datei galt dadurch als binaer -- grep
verweigerte sie, und Editoren haetten sie zerstoeren koennen. Jetzt
steht dort \x00-\x1f als Text.
|
||
|
DogFatherGit
|
81b51ab94f |
Workspace: Dateiablage mit Freigabe-Ablauf (Phase 1 vollstaendig)
/workspace/dateien.html -- Ablegen per Ziehen oder Auswaehlen, Entwurf -> Review -> Freigabe, Filter je Zustand. OHNE NEUE ABHAENGIGKEIT. Uploads laufen ueblicherweise ueber multer. Hier schickt der Browser die Datei roh im Rumpf, der Name steht im Kopf (URI-kodiert, damit Umlaute heil ankommen). express.raw() bringt den passenden Empfaenger schon mit -- kein Zerlegen von multipart/form-data von Hand, was gerade hier heikel waere. Die drei Punkte, an denen Dateiablagen typischerweise scheitern: 1. Die Dateien liegen AUSSERHALB des Repos (workspace-daten/dateien/). Lagen sie darin, wuerde express.static sie ungeprueft ans Netz geben. 2. Auf der Platte traegt jede Datei einen erzeugten Zufallsnamen, der Originalname steht nur in der Datenbank. Geprueft mit dem Dateinamen "../../etc/passwd": gespeichert wurde "passwd", auf der Platte ein Zufallsname IM Ordner -- nichts ist ausgebrochen. 3. Ausgeliefert wird immer als Download mit neutralem Typ, dazu nosniff und CSP sandbox. Geprueft mit einer hochgeladenen boese.html: kommt als application/octet-stream zurueck, kann also keinen Code im Namen der Domain ausfuehren. Freigabe nach Konzept: Der Zustand "freigegeben" ist eine Abnahme und bleibt dem Management vorbehalten. Geprueft -- Luna kann Entwurf -> Review, aber nicht freigeben (403); eine freigegebene Datei kann sie weder aendern noch loeschen. Sichtbarkeit wie ueberall: Chef 2 Dateien, Luna 1, Mika 0. Zugriff auf eine fremde Datei: 404, nicht 403. Ein Fehler beim Testen gefunden: Bei zu grosser Datei brach express.raw ab, BEVOR der eigene Code lief -- der Fehler landete im allgemeinen Behandler als HTTP 500. Fuer die Nutzerin sah das aus wie ein kaputter Server statt wie "Datei zu gross". Jetzt faengt ein eigener Fehlerbehandler am Ende des Routers das ab und antwortet mit 413 und einer verstaendlichen Meldung. Damit ist Phase 1 aus dem Konzept vollstaendig. |