b85740dc2004faff06283f0e2bac115279d69ad6
26
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
b85740dc20 |
Talente: der Uebergang, an dem die meisten verlorengehen
Filipe: "ich will dass du die 2 kategorien perfektionnierst. ich will
die noch viel besser, perfektionniert, viel geiler und krasser. es
soll so einfach wie moeglich sein fuer jeden."
Die AUSWAHL war der gut gebaute Teil dieser Seite: 21 Merkmale, sechs
Warnzeichen, ein Trichter mit Standzeiten. Die Stelle, an der Teams
tatsaechlich Leute verlieren, liegt dahinter -- zwischen dem "ja" und
der ersten echten Schicht. Wer zusagt und danach zwei Wochen nichts
hoert, hat innerlich schon abgesagt, und auf der Karte steht weiter
"angesprochen".
In der Beschreibung der Stufe "Probe" stand seit dem ersten Tag
"fester Buddy". Ein Feld dafuer gab es nicht. Ein Versprechen im Text
ist keine Eigenschaft des Systems -- erst eine Regel, die NEIN sagen
kann, ist eine.
Ab jetzt:
- Auf die Probe kommt niemand ohne einen Namen und ein Datum. Die
Absage sagt, welches von beiden fehlt, und die Karte bleibt dabei
stehen, wo sie war.
- Die Karte zeigt beides: wer einarbeitet, wann die erste Schicht
ist -- in einem Satz, den man laut vorlesen kann ("Erste Schicht
ist morgen."). Ein Termin weiter als 14 Tage ist erlaubt, wird
aber benannt.
- Drei Dinge fuer den ersten Tag stehen auf der Probekarte: was
gilt, was du darfst, wen du fragst. Keine Haken -- der Buddy soll
sie lesen, nicht abarbeiten.
- Buddy und Termin lassen sich spaeter aendern, OHNE die Standzeit
zurueckzusetzen: Sie ist die Auskunft ueber uns, nicht ueber den
Kandidaten.
- Wer geht, ist kein Buddy mehr -- stillgelegt wie geloescht. Die
Karte sagt dann "bitte neu bestimmen" und ist am Rand markiert.
Recherche (Quellen im Kopf von workspace-talent-punkte.js): Discord
nennt Buddy und Mentoring als die beiden Trainingswege, die
funktionieren; aus der Freiwilligenarbeit kommt dieselbe Aussage mit
Zahlen. Und: Am ersten Tag braucht jemand drei Dinge, nicht dreissig.
Was die Pruefung gefunden hat: buddy_weg fragte "buddy_id gesetzt UND
Person weg" -- damit war der zweite Weg blind. Wird ein Mensch
geloescht, setzt ON DELETE SET NULL die Spalte auf NULL, die Karte sah
unauffaellig aus, und eine laufende Probe stand ohne jeden Buddy da.
server/pruef-uebergang.mjs 61 Pruefungen, 0 Fehler (Port 4420)
pruef-nachwuchs 123, pruef-entwicklung 43, pruef-css-klassen -- 0 Fehler
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d4730deb30 |
Wie geht's dir? bekommt eine eigene Seite
Filipe, zum Bildschirmfoto der Kachel: "ich will dass du diese seite
perfektionnierst den gerade wenn ich drauf druecke geht die
entwicklungsseite auf."
Der Fehler war schlimmer als ein falscher Verweis. Auf der Kachel
steht "die Antworten sieht nur du" -- und sie oeffnete eine Seite
voller Namen und Beobachtungen ueber ANDERE Menschen. Wer ihr glaubt
und drauftippt, sieht im ersten Moment das Gegenteil dessen, was
draufsteht.
Jetzt: eine Seite, ein Zweck.
workspace/befinden.html + assets/js/befinden.js die eigene Seite
server/workspace-befinden.js Rhythmus + Verlauf
entwicklung.html nur noch ein Verweis
Was die Recherche zu Puls-Abfragen ergeben hat (Quellen im Kopf des
Moduls): kurz halten (fuenf bis fuenfzehn Fragen -- sechs bleiben
sechs), WIEDERHOLEN (zweiwoechentlich), und der VERLAUF ist die
Auskunft, nicht der Einzelwert. Bisher beantwortete man die sechs
Fragen einmal, und die Antwort stand fuer immer -- ein Befinden von
vor drei Monaten ist keine Auskunft mehr, sondern ein Andenken.
Der Verlauf gehoert ihr allein: eigene Tabelle, kein von_id, kein
anderer Weg im Haus liest sie. Im Protokoll steht nur, DASS eine
Runde war, nie was darin stand. Die Ampel zaehlt weiterhin nur den
aktuellen Stand und kennt keine Namen.
Zwei Dinge, die erst die Pruefung gefunden hat:
- Wer die neue Seite oeffnete, ohne dass vorher jemand die
Entwicklungsseite besucht hatte, bekam "no such table" und eine
503. entwicklung_stand wird beim ersten Aufruf angelegt, nicht
beim Start. Die Tabelle wird jetzt angefordert, nicht ein zweites
Mal abgeschrieben.
- pruef-entwicklung suchte die Kachel ueber ziel ===
"entwicklung.html" und hat den gemeldeten Fehler damit
mitgetragen. Sie sucht jetzt die eigene Seite -- und prueft
zusaetzlich, dass keine Kachel mehr ersatzweise dorthin fuehrt.
Ausserdem weg: die tote Funktion meins() in entwicklung.js (sie
zeichnete in drei Stellen, die es nicht mehr gibt) und der Titel
"Wie geht's dir?", den diese Seite fuer einen Modi trug -- er
versprach etwas anderes als die Seite zeigt, also derselbe Fehler
wie an der Kachel.
server/pruef-befinden.mjs 48 Pruefungen, 0 Fehler (Port 4419)
pruef-entwicklung 43 (vorher 40), 0 Fehler
pruef-nachwuchs 123, pruef-rechtetafel 19, pruef-rechte-umstellen 46,
pruef-css-klassen -- alle 0 Fehler
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2712473f16 |
Womit anfangen? -- Stufe 9 ist damit vollstaendig
Letztes Stueck aus dem Plan zur Perfektion: "Wichtig-vs-Aufwand im Report". DIE FRAGE, DIE EINE AUFGABENLISTE NICHT BEANTWORTET Ein Brett mit dreissig offenen Karten sagt, WAS zu tun ist. Es sagt nicht, WOMIT man anfaengt. "Wichtig" allein hilft dabei nicht: Sind acht Karten wichtig, ist keine davon die erste. Die zweite Angabe, die dafuer fehlte, ist der AUFWAND -- eine Spalte, mehr nicht. "Wichtig" gibt es schon, das ist die Prioritaet; es wird kein zweites Feld dafuer erfunden. VIER FELDER, UND JEDES SAGT, WAS ZU TUN IST wichtig + klein SOFORT in einer halben Stunde erledigt, und es zaehlt wichtig + gross EINPLANEN braucht einen Termin, keinen guten Willen normal + klein NEBENBEI wenn zwischendurch Luft ist normal + gross SPAETER ehrlich: das wird gerade nichts Die Namen sind Handlungsanweisungen, keine Etiketten. "Quadrant 2" sagt niemandem, was er tun soll. OHNE SCHAETZUNG VERSCHWINDET NICHTS Der Aufwand ist freiwillig -- und laesst sich zuruecknehmen. Aufgaben ohne Schaetzung landen deshalb nicht stillschweigend irgendwo, sondern in einer eigenen, klar benannten Gruppe: "noch nicht eingeschaetzt". Eine Uebersicht, die einen Teil der Arbeit unsichtbar macht, ist schlimmer als keine -- man verlaesst sich darauf und uebersieht genau das, was fehlt. Die Pruefung zaehlt deshalb nach, dass die Summe der Felder die Summe der offenen Aufgaben ist. DREI STUFEN, NICHT FUENF. Fuenf klingen genauer und sind es nicht: Niemand unterscheidet verlaesslich zwischen "eher mittel" und "eher gross". Drei kann man ohne Nachdenken vergeben, und nur was ohne Nachdenken geht, wird auch gepflegt. KEINE CHECK-LISTE IN DER DATENBANK. Die erlaubten Werte stehen in workspace-womit.js; eine CHECK-Liste daneben waere eine zweite Wahrheit, die beim naechsten Wert ueber einen Tabellenneubau nachgezogen werden muesste -- und dabei sind im Projekt schon dreimal Spalten verlorengegangen. Geprueft wird beim Schreiben, an der Stelle, die die Liste kennt. Die Oberflaeche baut ihre Auswahl ebenfalls aus dieser Liste, statt drei <option>-Zeilen zu fuehren. PRUEFUNGEN: pruef-womit neu mit 41, davon 10 im Browser. Darunter die Zeile, die zaehlt: nichts verschwindet. STUFE 9 IST DAMIT DURCH: Idee -> Aufgabe, Dateifassungen, Anhaenge an Aufgaben, Eskalationsstufe, Wichtig-vs-Aufwand. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
2d5972f45f |
Wie lange geht das schon so -- Eskalation statt eines Schalters
Stufe 9 aus dem Plan: "Eskalationsstufe sichtbar". Damit ist Stufe 9
bis auf einen Punkt durch.
DER MANGEL, GEMESSEN
"Ueberfaellig" war ein Schalter: an oder aus. Eine Aufgabe, deren Frist
gestern lief, sah genauso aus wie eine, die seit drei Wochen liegt --
dasselbe Wort, dieselbe Farbe, derselbe Platz.
Damit verliert das Wort seine Bedeutung. Stehen auf einem Brett zwanzig
Karten "ueberfaellig", sagt keine davon mehr etwas; man ueberliest sie
alle, auch die, die seit einem Monat blockiert.
ZWEI VERSCHIEDENE FRAGEN, DIE NICHT VERMISCHT WERDEN DUERFEN
FRIST UEBERSCHRITTEN Es war etwas versprochen, der Termin ist
vorbei. Eine Tatsache.
faellig (ab 1 Tag) -> liegt (ab 3) -> haengt (ab 8)
NICHTS PASSIERT Keine Frist, aber seit 14 Tagen hat niemand
die Karte angefasst. Eine Beobachtung.
Die erste ist haerter und steht vorn. Eine Aufgabe ohne Frist ist nicht
"zu spaet" -- sie ist nur still. Beides in einen Topf zu werfen hiesse,
jemandem einen gebrochenen Termin vorzuwerfen, den er nie zugesagt hat.
Deshalb ist "still" auch farblos gezeichnet, gestrichelt statt gefuellt.
DAS IST KEINE MAHNUNG
Dieselbe Haltung wie bei der Standzeit im Talente-Trichter: Die Zahl ist
eine Auskunft ueber UNS, kein Vorwurf an eine Person. Deshalb steht
nirgends ein Name, und die hoechste Stufe heisst "haengt", nicht
"versaeumt".
DIE SCHWELLEN SIND GESETZT, NICHT GEMESSEN -- und das steht so im Code:
unter 3 Tagen reicht ein Wochenende; ab 3 ist es ein Zustand; ab 8 (ueber
eine Woche) kommt es ohne Hilfe auch naechste Woche nicht dazu. Aendert
sich eine Zahl, aendert sie sich an einer Stelle, und die Oberflaeche
zieht mit -- sie bekommt das WORT vom Server.
AM SERVER GERECHNET. Startseite, Brett und Uebersicht lesen dieselbe
Liste. Drei Stellen, die dieselbe Frage selbst beantworten, geben
irgendwann drei Antworten -- genau der Fehler, der im Projekt schon bei
der Rollenreihenfolge und beim Wort "Agentur" passiert ist.
DIE FARBE IST NICHT DIE AUSKUNFT: In jedem Kaestchen steht ein Wort
("liegt seit 5 Tagen"), nicht nur ein roterer Punkt.
PRUEFUNGEN: pruef-eskalation neu mit 40, davon 6 im Browser. Gemessen
wird an den GRENZEN, nicht in der Mitte -- jede Schwelle dreimal: einen
Tag davor, genau darauf, einen Tag danach. Die wichtigste ist die erste:
am Tag der Frist ist nichts ueberfaellig. Wer bis zum 15. Zeit hat, ist
am 15. puenktlich; eine Eskalation, die einen Tag zu frueh anschlaegt,
verliert genau das Vertrauen, das sie braucht.
Die Pruefung benutzt einen FESTEN Zeitpunkt als Eingabe, keine
Wanderuhr -- sonst misst sie irgendwann das Gegenteil.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
1386534051 |
Anhaenge an Aufgaben -- ohne eine zweite Dateiablage
Stufe 9 aus dem Plan. Eine Aufgabe "Vertrag pruefen" ohne den Vertrag daneben ist eine Aufforderung zum Suchen. KEIN ZWEITER HOCHLADEWEG Dateien leben in der Dateiablage -- mit ihrer Sichtbarkeit, ihren Freigaben, ihren Fassungen und ihrem Protokoll. Ein eigener Weg an der Aufgabe waere eine zweite Ablage mit einer zweiten Rechtelogik gewesen, und die zweite ist immer die, die etwas durchlaesst. Deshalb nur eine Spalte: Die Datei WEISS, zu welcher Aufgabe sie gehoert. Hochgeladen wird ueber denselben Weg wie immer, mit einem Kopf mehr. Alles andere bleibt, wo es schon richtig ist -- die Anhaenge tragen deshalb auch ihre Fassungsnummer und die Warnung "nicht mehr aktuell" mit, ohne dass dafuer eine Zeile geschrieben werden musste. DER RIEGEL Waere `x-aufgabe` ungeprueft, waere der Kopf ein Weg, die Existenz fremder Aufgaben zu erfahren -- man muesste nur Zahlen durchprobieren. Geprueft wird deshalb gegen dieselbe Schranke wie fuer die Datei selbst: `darfCreator`, die eine Stelle im Haus, an der diese Frage beantwortet wird. Eine eigene Herleitung hier waere eine zweite Meinung darueber gewesen. (Erster Anlauf: genau so eine Herleitung, mit einer Funktion, die gar nicht importiert war.) Gemessen: Ein Scout darf an die Aufgabe SEINER Creatorin, an die eines fremden Creators nicht -- mit wortgleicher Absage wie bei einer erfundenen Nummer. Der Unterschied waere sonst die Auskunft. Und es bleibt auch keine lose Datei liegen: Die Pruefung findet vor dem ersten Byte statt. ON DELETE SET NULL, NICHT CASCADE Der wichtigste Teil der Spalte: Wer eine Aufgabe loescht, will die Aufgabe loeschen, nicht den Vertrag, der daran hing. Die Datei verliert nur ihren Bezug und steht danach wieder in der Ablage. Gemessen. EIN EIGENER FEHLER, GEFUNDEN BEIM MESSEN Der Verweis am Anhang zeigte auf /workspace/api/dateien/:id -- den es gar nicht gibt, der Weg heisst /inhalt. Die Pruefung ruft ihn jetzt wirklich auf und erwartet 200, statt nur die Adresse zu vergleichen. PRUEFUNGEN: pruef-anhaenge neu mit 37, davon 8 im Browser. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
478a2895b5 |
Dateifassungen: die alte Fassung sieht man ihr an
Stufe 9 aus dem Plan: "Dateiversionen statt Ueberschreiben".
GEMESSEN, BEVOR ETWAS GEBAUT WURDE -- DER PLAN LAG DANEBEN
Ueberschrieben wurde nie: `name_datei` ist eindeutig und zufaellig,
jedes Hochladen legt eine neue Zeile an. Der wirkliche Mangel ist ein
anderer, und er ist gefaehrlicher als Ueberschreiben:
Zwei Dateien gleichen Namens standen BEZIEHUNGSLOS nebeneinander. Die
alte kann "freigegeben" sein, die neue "entwurf" -- und wer die Liste
ansieht, laedt die freigegebene herunter. Also die falsche. Kein
Fehler, keine Meldung, nur die alte Fassung in der Hand.
WAS JETZT PASSIERT
Beim Hochladen erkennt der Server die Vorgaengerin selbst: gleicher
Originalname, gleicher Creator-Bezug, und sie darf nicht schon ersetzt
sein. An der Datei steht danach "Fassung 2"; an der alten steht "nicht
mehr aktuell".
AUTOMATISCH, NICHT GEFRAGT -- eine Abwaegung: Wer die Verknuepfung
vergisst, hat zwei Dateien ohne Zusammenhang, und irgendwann laedt
jemand die alte herunter. Wer sie faelschlich bekommt, SIEHT das
sofort und loest sie mit einem Klick. Der stille Schaden ist groesser
als der sichtbare.
BEI ZWEIFEL WIRD NICHT GERATEN. Gibt es zwei unersetzte Dateien
gleichen Namens, bleibt die neue eigenstaendig.
LOESEN GEHT NUR AN DER AKTUELLEN FASSUNG. Wer eine ueberholte loest,
macht daraus eine zweite aktuelle -- und hat das Problem zurueck.
DIE NUMMER IST GERECHNET, NICHT GESPEICHERT. Eine Spalte "version"
muesste beim Loeschen einer mittleren Fassung nachgezogen werden, und
genau das vergisst man. Faellt die erste weg, zaehlt die zweite
wieder als erste -- richtig, denn mehr weiss das System dann nicht.
EIN RING IN DEN DATEN HAELT DIE SEITE NICHT AN. Kann ueber die Wege
hier nicht entstehen, aber ein Fehler anderswo koennte ihn erzeugen,
und ein Stillstand ist schlimmer als ein Fehler. Gemessen: 1 ms.
ZWEI SITZUNGEN IM SELBEN VERZEICHNIS
Der vorige Commit (
|
||
|
DogFatherGitandClaude Opus 5
|
d2210fdd77 |
Der Erklaerkasten auf jeder Seite ist weg
Filipe, mit dem Kasten im Bild: "das muss sofort weg. ueberall das ist scheisse." Entfernt, nicht ausgeblendet: - workspace/assets/js/erklaerung.js - server/workspace-erklaerung.js samt Router-Einbindung in index.js - server/pruef-erklaerung.mjs - der Stilblock in start.css - die Skript-Zeile auf allen 25 Seiten AUSGEBLENDET WAERE KEIN ENTFERNEN. Der Weg haette weiter geantwortet, das Skript waere weiter geladen worden, und beim naechsten Umbau waere der Kasten irgendwo wieder aufgetaucht. Was weg soll, wird weggenommen. NACHGEMESSEN STATT ANGENOMMEN: - kein Verweis auf die geloeschten Dateien mehr im Repo, - der Server startet ohne Fehler (frische Datenbank, Protokoll leer), - keine Reste (erkl__, erklaerung.js) in Seiten oder Stilvorlagen. Vier andere Pruefungen nennen ebenfalls "Erklaerung" -- sie meinen ANDERE: den Satz im Neu-Fenster des Chats, die Stufen-Seite, die Rollenkarten. Die bleiben unberuehrt; nachgesehen, nicht vermutet. pruef-workspace-seiten, pruef-css-klassen und pruef-lesbarkeit laufen gruen. Die Zahl der Pruefungen sinkt um die der geloeschten Datei -- das ist hier richtig: Sie prueften etwas, das es nicht mehr gibt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d76d9aa5da |
Aus einer Idee wird Arbeit -- mit einem Knopf statt mit Abtippen
Stufe 9 aus dem Plan zur Perfektion: "Idee -> Aufgabe/Termin".
WARUM DAS MEHR IST ALS EINE BEQUEMLICHKEIT
Das ganze Haus steht auf einem Satz: "Was hier nicht steht, passiert
nicht." Ein Ideenbrett, aus dem keine Aufgabe werden kann, ist der eine
Ort, an dem dieser Satz nicht gilt -- dort steht etwas, und passieren
tut es trotzdem nicht. Wer eine Idee umsetzen wollte, tippte sie ein
zweites Mal ab. Und was man abtippt, tippt man irgendwann nicht mehr ab.
DREI ENTSCHEIDUNGEN
GENAU EINMAL. Ein zweiter Versuch fuehrt nicht zu einer zweiten
Aufgabe, sondern zum Verweis auf die vorhandene (409). Gefragt wird
an der AUFGABE, nicht an der Idee: Dort steht die Tatsache, und sie
kann nicht auseinanderlaufen.
DIE IDEE BLEIBT STEHEN. Sie wird nicht verschoben und nicht geloescht
-- wer nachsieht, was aus einem Gedanken geworden ist, soll den
Gedanken noch finden, und daneben die Antwort.
DIE AUFGABE WEISS, WOHER SIE KAM. `aus_eintrag_id` mit echtem
Fremdschluessel, nicht als Text im Beschreibungsfeld. Ein Verweis, den
nur ein Mensch lesen kann, ist kein Verweis. ON DELETE SET NULL, nicht
CASCADE: Wird die Idee geloescht, bleibt die Arbeit.
NICHT AUS JEDEM BRETT
Aus einem Beitrag im Treff wird keine Aufgabe. Was jemand aus der
Community schreibt, gehoert ihm; daraus stillschweigend Arbeit zu
machen waere eine Verwendung, mit der er nicht rechnet. Welche Bretter
es sind, entscheidet der Server -- die Oberflaeche fragt nach, statt
eine zweite Liste zu fuehren.
WAS ABSICHTLICH NICHT MITWANDERT: die Frist. Eine Idee hat keinen
Termin; wer ihr beim Uebernehmen automatisch einen gaebe, erfaende ihn.
Die Dringlichkeit wandert dagegen mit -- dieselben drei Stufen.
ZUSTAENDIG IST, WER UEBERNIMMT, nicht wer die Idee aufgeschrieben hat.
Eine Aufgabe, die jemandem ohne sein Zutun zugeteilt wird, wird nicht
angefangen.
ZWEIMAL AM FALSCHEN ORT GELANDET
Der Knopf stand erst in `if (lage.team)`, dann immer noch innerhalb von
`if (treffBrett && lage)` -- also beide Male ausgerechnet am Treff und
an keinem Arbeitsbrett. Gefunden hat das beide Male die Pruefung im
Browser ("0 Knoepfe auf dem Ideenbrett"), nicht das Lesen. Jetzt steht
er in der allgemeinen Knopfreihe, hinter `darfEintragen()` -- eine
Uebernahme ist ein Schreibvorgang.
Und die Gegenprobe zur Brettliste lief anfangs ins Leere: Sie fragte
nach `BEREICHE[b].treff`, ein Merkmal, das es nicht gibt, und fand null
Treff-Bretter -- eine Gegenprobe, die nichts gegenprueft. TREFF_BRETTER
steht in workspace.js.
PRUEFUNGEN: pruef-uebernahme neu mit 39, davon 4 im Browser (der Klick
muss eine Aufgabe in der DATENBANK erzeugen, nicht nur eine Meldung).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
b9f261bbac |
Das Mindestalter wird eingeloest statt behauptet -- Stufe 8 ist damit durch
Auf der Regelseite des Treffs steht seit dem 11.09. "ab 18". Geprueft
wurde es nirgends: MINDESTALTER war ein Text auf einer Seite, sonst
nichts. Eine Regel, die nur dasteht, ist keine -- im Streitfall ist sie
sogar schlechter als keine, weil man sie versprochen hat.
DIE FRAGE STEHT AN DER TUER
Ein Community-Mitglied bestaetigt beim ERSTEN Hereinkommen, mindestens
18 zu sein. Danach nie wieder.
An der Tuer und nicht auf einer Seite dahinter: Eine Sperre auf den
Brettern liesse sich ueber eine andere Adresse umgehen und muesste
auf jeder kuenftigen Seite mitgedacht werden. Die Tuer gibt es genau
einmal.
Ein EIGENER Fehler (400 alter_offen), nicht "ungueltig": Hier ist der
Code richtig. Wer dieselbe Antwort bekaeme wie bei einem Tippfehler,
tippte seinen Code immer wieder neu ein, und es wuerde nie besser.
Und es zaehlt NICHT als Fehlversuch. Sonst sperrt sich jemand mit dem
richtigen Code nach acht Anlaeufen selbst aus.
Nur die Community: Wer zum Team gehoert, hat seinen Zugang von
DogFather persoenlich bekommen -- da ist die Frage vorher geklaert.
NUR EIN ZEITSTEMPEL, KEIN GEBURTSDATUM
Gebraucht wird die Antwort auf "hat bestaetigt, und wann" -- nicht der
Geburtstag. Ein Geburtsdatum waeren mehr Daten fuer dieselbe Auskunft,
und Datenminimierung gilt auch fuer das eigene Nachweisbeduerfnis. Eine
Spalte, mehr nicht.
DIE RECHTSGRUNDLAGE FOLGT AUS DER ROLLE -- UND WIRD NICHT GESPEICHERT
Ein Modi arbeitet hier (Vertrag), ein Community-Mitglied ist freiwillig
da (Einwilligung). Was sich ableiten laesst, bekommt keine Spalte:
sonst gaebe es zwei Wahrheiten, von denen eine veraltet, sobald jemand
die Rolle wechselt. Sie steht jetzt in jeder Auskunft (Art. 15 Abs. 1
lit. a) und im Loeschkonzept.
MINDESTALTER ZIEHT INS IMPORTFREIE BLATT
Die Tuer braucht die Zahl jetzt auch, und ein Import zwischen
workspace.js und workspace-treff.js waere ein Kreis -- genau der Grund,
aus dem treff-tabellen.js existiert. Die Zahl steht weiterhin an EINER
Stelle; der Regeltext bekommt sie unveraendert.
EIN EIGENER FEHLER, GEFUNDEN VON DER PRUEFUNG
Ich hatte `export { MINDESTALTER } from "./treff-tabellen.js"` benutzt --
eine Durchreiche. Der Name ist damit fuer IMPORTEURE da, aber nicht in
der Datei selbst. Die Regelroute benutzt ihn selbst und lief in einen
ReferenceError, und zwar erst beim Aufruf. pruef-alter hat es gesehen,
nicht das Auge.
VIER PRUEFUNGEN MUSSTEN NACHZIEHEN
pruef-treff, pruef-treff-werkzeuge, pruef-auskunft und pruef-neue-seiten
melden sich als Community an. Sie schicken das Haekchen jetzt mit --
aber NUR fuer 'gast'. Ginge es immer mit, koennte keine Pruefung mehr
sehen, ob der Server es fuer das Team ueberhaupt ignoriert.
PRUEFUNGEN: pruef-alter neu mit 35, davon 7 im Browser. Darunter die,
die man vergisst: Wird beim ZWEITEN Mal wieder gefragt? (nein) -- denn
eine Abfrage, die jedes Mal kommt, wird weggeklickt, ohne gelesen zu
werden, und bestaetigt ab da nichts mehr.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6643e530a8 |
Auskunft auf Knopfdruck -- und die Quellenliste pflegt sich selbst
Zweite Haelfte von Stufe 8, Art. 15 DSGVO. Jeder Mensch hier darf wissen, was ueber ihn gespeichert ist: DogFather, die rechte Hand, jeder Modi, jede Creatorin -- und jedes Mitglied der Community. DIE LISTE DER QUELLEN WIRD ABGELEITET, NICHT GEPFLEGT Eine Auskunft, die eine Tabelle vergisst, ist schlimmer als keine: Sie ist eine falsche Aussage ueber die Daten eines Menschen. Eine handgeschriebene Liste "wo Personendaten liegen" waere in dem Moment falsch, in dem jemand eine Tabelle dazubaut -- und genau diese Bauart ist im Projekt schon dreimal schiefgegangen. Deshalb fragt das Modul die Datenbank selbst: `PRAGMA foreign_key_list` liefert jede Spalte, die auf `personen` zeigt. Gemessen: 62 Spalten in 38 von 42 Tabellen. VIER SPALTEN ZEIGEN AUF ETWAS, OHNE ES ZU SAGEN Es gibt genau vier Spalten im Haus, die auf `_id` enden und keinen Fremdschluessel deklarieren: eintraege.saeule_id keine Person treff_entfernt.eintrag_id keine Person protokoll.person_id IST eine Person treff_entfernt.autor_id IST eine Person Beide Personenspalten haben denselben Grund, keinen Fremdschluessel zu haben: Sie sollen eine geloeschte Person ueberdauern. Sie stehen namentlich im Modul -- und pruef-auskunft schlaegt an, sobald eine fuenfte dazukommt, die niemand eingeordnet hat. Die Liste ist damit klein genug, um richtig zu sein, und kann nicht heimlich veralten. ZWEI DINGE STEHEN NIE DRIN Zugangsgeheimnisse (Hash, Salt, Kennung) -- Risiko ohne Nutzen. Andere Menschen -- wer eine Massnahme gesetzt hat, ist dessen Datum, nicht meines. Eine Regel fuer alle Tabellen, keine Ausnahmeliste: Steht in einer Zeile ueber mich die Nummer eines anderen, wird daraus "eine andere Person". Meine eigene bleibt stehen, sonst waere die Auskunft unbrauchbar -- und genau das ist die Gegenprobe dazu. DER KNOPF STEHT AUF ZWEI SEITEN Steckbrief und Treff-Regeln -- die beiden Seiten, die einem Menschen selbst gehoeren. Die Community hat keinen Steckbrief; ohne die zweite Stelle haette ausgerechnet die groesste Gruppe mit den wenigsten Rechten auch dieses nicht. Die Pruefung liest das aus der Rechtetafel nach, statt es zu behaupten. Die Datei entsteht im Browser aus der Antwort -- es bleibt also nichts auf dem Server liegen. Wer ueber wen Auskunft gezogen hat, steht im Protokoll: Eine vollstaendige Sammlung der Daten eines Menschen ist das Empfindlichste, was dieses Haus herausgibt. NEBENBEI GEFUNDEN Ich hatte `.block__kopf` und `.block__frage` geliehen -- die stehen in automation.css, und keine der beiden Seiten laedt die. Der Kasten waere ohne Abstaende dagestanden. Gefunden von pruef-css-klassen, nicht vom Auge. Jetzt eigene Klassen in start.css. PRUEFUNGEN: pruef-auskunft neu mit 46. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
e975983ad1 |
Das Loeschkonzept ist kein Dokument, sondern eine Tabelle, die sich durchsetzt
Stufe 8 aus dem Plan zur Perfektion: "Loeschkonzept je Datenart ·
IP-Adressen im Protokoll nach 30 Tagen weg. Je mehr Daten, desto teurer
das Nachholen."
WARUM NICHT ALS NOTIZ
Ein Loeschkonzept als Dokument ist nach dem ersten neuen Feld falsch,
und niemand merkt es. workspace-aufbewahrung.js ist beides: die
Uebersicht, was wie lange aufgehoben wird -- UND das Programm, das es
tut. Was dort nicht steht, wird nicht geraeumt; was dort steht, wird
geraeumt.
GEMESSEN, BEVOR ETWAS GEBAUT WURDE
42 Tabellen durchgesehen. Drei halten IP-Adressen:
versuche.ip wird beim Anmelden im Fenster geraeumt ok
sitzungen.ip nur beim Abmelden -- ABGELAUFENE Sitzungen
standen ewig da, samt IP und Browser Luecke
protokoll.ip wurde nirgends geraeumt, wuchs ewig Luecke
Zwei echte Luecken also, nicht fuenf vermutete.
DREI SORTEN EINTRAG, UND DIE DRITTE IST DIE WICHTIGSTE
raeumen Diese Datei loescht selbst.
fremd Eine andere Stelle loescht -- hier wird nur GEZAEHLT.
Bricht die andere Stelle, steht die Zahl trotzdem da.
bleibt Wird absichtlich aufgehoben, mit Begruendung.
Ein Loeschkonzept, das nur Loeschungen auffuehrt, ist ein halbes: Die
begruendete Aufbewahrung ist der Teil, nach dem gefragt wird. Jede
Zeile nennt Frist, Zweck, Rechtsgrundlage und Wirkung.
SICHTBAR, NICHT NUR WIRKSAM
Auf automation.html -- dort steht alles, was ohne Zutun laeuft, und
genau das ist es. Bei jeder Zeile die Zahl, wie viele Datensaetze sie
gerade betrifft, und ein Knopf "Jetzt aufraeumen", damit es kein
schwarzer Kasten ist. Die Sorte steht als WORT daneben, nicht nur als
Farbe.
BEI ETWAS, DAS LOESCHT, IST DIE WICHTIGERE HAELFTE: WAS ES NICHT LOESCHT
Zu jeder Loeschung eine Gegenprobe:
IP nach 30 Tagen weg -> und die von vor 29 Tagen bleibt
IP weg -> und die ZEILE bleibt (nur das Feld)
abgelaufene Sitzung weg -> und die gueltige bleibt
abgelaufene Sitzung weg -> und ich bin danach noch angemeldet
Die letzte ist die unbequemste und die wichtigste: Ein Aufraeumlauf,
der die eigene Anmeldung mitnimmt, wirft im Betrieb alle hinaus -- und
zwar einmal taeglich. Dazu: ein zweiter Lauf muss NICHTS mehr finden
(sonst waere "aufgeraeumt" nicht von "nichts getan" zu unterscheiden),
und eine Zaehlung ueber eine fehlende Tabelle ergibt `null`, nicht 0.
NEBENBEI: EINE EIGENE DOPPLUNG VON GESTERN
Drei der Seitenerklaerungen sagten in "Wofuer" und "Du tust" fast
dasselbe (report 80 %, treff-regeln 67 %, startcheck 50 %). Gestern
hatte ich nur den Fall geprueft, an dem ich mich verbrannt hatte --
"Wofuer" gegen die Unterzeile -- und die naheliegendere Dopplung
uebersehen. Jetzt gemessen, schlechtester Wert 25 %.
PRUEFUNGEN: pruef-aufbewahrung neu mit 41, davon 7 im Browser
(der Knopf muss eine Zahl wirklich fallen lassen, und die IP muss
danach in der Datenbank weg sein). pruef-erklaerung 44 -> 47.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
4571b15494 |
Die Wochenzahlen erklaeren sich -- und die Zeitraum-Karte bekommt eine Rangfolge
Zwei Bildschirmfotos, zwei Sachen. 1) "wieso werden die zahlen oben nicht ausgefuellt von der excel datei?" Weil kein einziger Tag erfasst ist -- die Backstage-Ausgabe enthielt einen Zeitraum, und aus einer Summe ueber dreizehn Tage laesst sich nicht ablesen, wie ein einzelner Tag lief. Das stand nirgends. Stattdessen standen dort sieben Karten mit "0" und "wie in der Vorwoche": Das sieht aus wie ein Fehler, und die Frage entsteht genau an dieser Stelle. Also steht die Antwort jetzt auch dort -- nicht in einer Notiz, nicht in einem Hilfetext. UND SIE NENNT DEN WEG, nicht nur den Grund: "In Backstage den Zeitraum auf EINEN Tag stellen, herunterladen, hier einlesen -- je Tag einmal." Ein Hinweis ohne Ausweg ist eine Sackgasse mit Erklaerung. Sobald EIN Tag da ist, verschwindet der Kasten und die Karten kommen zurueck. Genau das ist die Gegenprobe; ohne sie hiesse alles andere nur, dass die Karten jetzt immer weg sind. 2) "das muss viel geiler aussehen und viel klarer." Er hatte recht: Die erste Fassung war eine Liste ohne Rangfolge -- Spanne, Diamanten, LIVE, Follower, alles gleich gross, nichts sprang heraus. Wer draufschaut, will ZWEI Dinge in einer halben Sekunde wissen: WELCHER Zeitraum und WIE VIELE Diamanten. Jetzt: die Spanne als Ueberschrift, die Zahl der Tage als Marke daneben, die Diamanten gross mit dem Schnitt direkt darunter, alles Uebrige unter einem Strich. Links eine Kante in der Hausfarbe -- sie sagt "andere Sorte Zahl", ohne dass ein Wort dafuer noetig waere. Das ist wichtig: Wer einen Zeitraum fuer einen Tageswert haelt, rechnet mit ihm weiter. GEMESSEN IN PIXELN, NICHT NACH GEFUEHL: Die Hauptzahl muss mindestens 1,6-mal so gross sein wie ein Nebenwert (gemessen: 30 px zu 15 px), sonst ist es wieder eine Liste. Eine Pruefung, die "sieht gut aus" sagt, sagt nichts. pruef-backstage-import 118 -> 127. Der leere Zustand wird HERGESTELLT und nicht abgewartet -- eine Pruefung, die auf einen Zustand hofft, prueft irgendwann gar nichts mehr. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
0d3a4b78cd |
Zwei Befunde aus dem Handy-Lauf -- und eine Regel, die ihre eigene Ausnahme nicht kannte
Filipe hat die beiden breiten Sichtpruefungen freigegeben. pruef-handy
meldete vier Fehlschlaege, pruef-lesbarkeit war gruen.
BEIDE BEFUNDE WAREN NICHT VON MEINER AENDERUNG -- gemessen, nicht
vermutet: crew-index.html laedt weder kopf.js noch erklaerung.js, und
mein Commit hat dort nur die Versionsnummer angefasst. Die betroffene
Regel steht seit dem 27.08.2026 so da.
1. ZU KLEINE SCHRIFT AUF DER ZUGANGSWAND VON TEAM DOGI
`.marke` stand auf schmalen Bildschirmen auf .68rem = 10,88 px und
damit unter der Hausuntergrenze von 11,5 px -- betroffen waren die
Woerter "DogFather" und "Team Dogi". Das ist die erste Seite, die ein
neuer Modi ueberhaupt sieht, und sie wird mit dem Daumen bedient.
Jetzt .72rem = 11,52 px, dieselbe Hebung wie seinerzeit in heim.css.
Die Grundlinie in pruef-css-klassen wird MITGEZOGEN (43 -> 42):
Sonst duerfte der Fortschritt lautlos wieder verlorengehen, und eine
Grundlinie, die nur nach oben nachgibt, ist keine.
2. DIE BERUEHRZIEL-REGEL ZITIERTE WCAG 2.5.8, ABER NICHT IHRE AUSNAHME
Gemeldet wurden die zwei Verweise im Fliesstext der Treff-Regeln
("Der Treff", "Regeln & Hilfe", je 20 px hoch). 2.5.8 nimmt genau das
aber ausdruecklich aus: "Inline: The target is in a sentence or its
size is otherwise constrained by the line-height of non-target text."
Sie auf 24 px zu bringen hiesse, die Zeilenhoehe eines Absatzes zu
sprengen -- also einen Text kaputtzumachen, um eine Regel zu
erfuellen, die diesen Text gar nicht meint. Die Ausnahme ist eng
gefasst: nur <a>, nur wirklich inline, und nur wenn im selben Absatz
auch Text steht, der nicht zum Link gehoert. Ein allein stehender
Link bleibt ein Beruehrziel.
UND DIESE DATEI HATTE BIS HEUTE GAR KEINE GEGENPROBE. Sie konnte
also nie zeigen, dass sie ein zu kleines Ziel ueberhaupt bemerkt --
erst recht nicht, seit die Regel eine Ausnahme hat. Jetzt in beide
Richtungen: ein allein stehendes 20x20-Ziel MUSS auffallen, ein
gleich grosser Verweis im Satz darf es NICHT.
PRUEFUNGEN: pruef-handy 136 -> 138 (vier Fehlschlaege behoben, zwei
Gegenproben dazu), keine einzige weniger. pruef-lesbarkeit gruen
(12 s). pruef-css-klassen, pruef-erklaerung und pruef-neue-seiten nach
der gate.css-Aenderung noch einmal gelaufen, alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
de19684883 |
Jede Seite erklaert sich selbst -- drei Zeilen, und die dritte rechnet sich aus
Filipe: "ich will in jeder seite auch eine kleine detaillierte aber
schnelle erklaerung kurz und knapps noch zu jeder seite."
DREI ZEILEN AUF JEDER DER 25 SEITEN
WOFUER was auf dieser Seite steht
DU TUST was man hier konkret macht
MERKE nur dort, wo es etwas gibt, das man falsch versteht
SIEHT wer diese Seite ueberhaupt oeffnen kann
Offen sichtbar und nicht hinter einem Aufklapper: "schnell" war seine
Bedingung, und eine Erklaerung, die man erst aufklappen muss, ist
genau dann nicht da, wenn man sie braucht.
DIE ZEILE "SIEHT" IST GERECHNET, NICHT GESCHRIEBEN
Sie kommt aus der Rechtetafel -- aus derselben, aus der auch die
Schranke ihre Entscheidung holt. Haette ich sie danebengeschrieben,
waere sie beim ersten Umstellen in "Wer sieht was" still falsch
geworden, in einem Satz, der behauptet, wer etwas sieht. Die Pruefung
stellt die Tafel deshalb wirklich um und sieht nach, ob der Satz
mitwandert.
Die Erklaerung haengt hinter derselben Schranke wie die Seite: Wer sie
nicht oeffnen darf, bekommt 404 -- nicht 403, sonst waere dieser Weg
eine Landkarte des Hauses.
Eingebunden ist sie nicht ueber eine Liste von Dateinamen, sondern
ueber "wer kopf.js laedt": die 26. Seite ist damit automatisch dabei.
Fuenf Seiten haben keine Kopfzeile (Chat, Kalender, Start, Team,
Teamlage) -- dort haengt der Kasten an <main>, sonst waeren
ausgerechnet die haeufigsten Seiten lautlos leer geblieben.
ZWEI EIGENE MAENGEL, GEFUNDEN DURCH HINSEHEN, NICHT DURCH DIE PRUEFUNG
Die erste Fassung war gruen -- und stand mitten auf dem Buehnenbild,
mit einem Lichtfleck hinter "SIEHT". Und "Wofuer" sprach fast woertlich
die Unterzeile darueber nach. Beides misst die Pruefung jetzt: Kontrast
mit dem dritten Ausgang ("steht auf der Buehne" ist kein Ergebnis) und
die Wortueberschneidung mit der Unterzeile.
ZWEI BEFUNDE, DIE SCHON VORHER ROT WAREN
1. pruef-tempo-workspace verglich die UNKOMPRIMIERTE Groesse gegen eine
Grenze, die fuer die Leitung gedacht war -- waehrend der Kommentar
daneben "das ist, was wirklich ueber die Leitung ging" behauptete.
Live steht Caddy davor. Nachgemessen an der echten Adresse:
start.css 345 KB -> 111 KB zstd. Die Pruefung wog also 1,2 MB, wo
Filipe 500 KB bekommt. Jetzt wird Komprimierbares im Pruefstand
gzip-gepackt (115 KB gegen 111 KB live -- auf vier Prozent genau),
geurteilt wird ueber die uebertragene Groesse, berichtet werden
beide. Dabei prompt in die dokumentierte Falle getappt: `body()` auf
einen Ereignisstrom endet nie, der Lauf blieb stehen. Jetzt
ausgenommen, plus Notbremse je Koerper.
2. pruef-ueberlappung konnte seit Tagen nicht mehr zeigen, dass sie
eine Ueberlappung ueberhaupt findet: Ihre Gegenprobe legt einen Knopf
auf einen anderen, traf aber 6 px daneben. Zwei Ursachen in einer
Zeile -- `position: fixed` bezieht sich auf einen Vorfahren mit
`transform`, und die `transition` der Knoepfe liefert beim sofortigen
Messen die Lage von vorher. Jetzt `transform` + `transition: none`:
34x36 px erkannt, 20 Seiten-Breiten-Paare, 0 Befunde.
PRUEFUNGEN: pruef-erklaerung neu mit 44, davon 8 im Browser (Seite mit
und ohne Kopfzeile, Handy, Kontrast, Echo). Mein Schild stand auf
10,88 px und lag unter der Hausgrenze von 11,5 -- gefunden von
pruef-css-klassen, nicht vom Auge.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
0cce22c08c |
Der Einzel-Import kennt den dritten Ausgang jetzt auch
Nach dem Umbau von heute Nachmittag habe ich nachgesehen, WER
tagAusZelle() sonst noch ruft -- und genau dort die naechste Luecke
gefunden, bevor sie jemanden getroffen hat.
DIE FUNKTION HAT SEIT HEUTE DREI AUSGAENGE (Tag, Zeitraum, Grund).
Gekannt hat den dritten nur der Backstage-Weg. Im Einzel-Import stand
weiterhin `gelesen.tag` -- bei einem Zeitraum `undefined`:
VORSCHAU: `undefined > heute` ist false, die Zeile faellt durch
und landet mit `tag: undefined` in der Liste.
SCHREIBWEG: `if (!tag)` greift, die Zeile wird still uebersprungen.
Die Vorschau haette also eine Zeile versprochen, die danach nirgends
steht. Zwei Aussagen ueber dieselbe Datei, die einander widersprechen,
und beide sehen fuer sich plausibel aus -- das ist der Unterschied, den
niemand bemerkt.
Das ist an diesem Tag die FUENFTE Wiederholung derselben Sache: eine
Regel, mehrere Aufrufer, und einer kennt sie nicht. Ein dritter Ausgang
taugt nur, wenn ihn ALLE Aufrufer kennen.
Jetzt legt auch der Einzel-Import einen Zeitraum in leistung_zeitraum
ab -- dieselbe Tabelle, dieselbe Regel, dieselbe Anzeige. Und die
Dauer-Einheit gilt dort ebenfalls; sie fehlte in der Vorschau noch.
DIE MELDUNG SAGT JETZT, WAS ANGEKOMMEN IST: "1 Zeitraum uebernommen"
statt "1 Tage uebernommen". Bei einer Backstage-Ausgabe ueber zwei
Wochen haette man sie sonst in der Tagesliste gesucht und nicht
gefunden.
pruef-backstage-import 106 -> 118. Die Pruefung, auf die es ankommt,
vergleicht VORSCHAU UND ERGEBNIS: Was die Vorschau verspricht, muss
danach dastehen -- genau die Aussage, die vorher falsch gewesen waere.
Dazu, dass in der Vorschau die Spanne steht und kein leerer Tag, und
die Gegenprobe, dass eine echte Tagesdatei weiterhin als Tage durchgeht.
ZWEI EIGENE FEHLER DABEI: Ich habe `.length` auf eine Zahl angewendet
(`fehlerhaft` ist eine Anzahl, keine Liste) -- immer `undefined`, immer
rot. Und zum zweiten Mal heute den Absolutwert gemessen, wo die
Veraenderung gehoert: Lumi hatte aus einem frueheren Teil der Pruefung
schon eine Tageszeile in derselben Spanne.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e82bf45f0d |
Ein Zeitraum geht jetzt durch -- als Zeitraum, nicht als Tag
Filipe: "verbesser das, also ich will dass das auch so geht, mach dass
es funktioniert, ich will es so einfach und perfekt wie moeglich. also
sieh zu dass die excel auch so durch geht."
Backstage gibt eine Ausgabe fuer einen ZEITRAUM heraus --
"2026-09-01 ~ 2026-09-13", eine Zeile je Creator, alle Zahlen
aufsummiert. Am Vormittag wurde so eine Zeile abgewiesen. Jetzt geht
sie durch.
DREI WEGE WAEREN MOEGLICH GEWESEN, ZWEI DAVON WAEREN
ZAHLENFAELSCHUNG:
* auf den ersten Tag schreiben -> dreizehn Tage auf einem Tag; die
Zahl steht da, sie ist gross, sie sieht richtig aus, und niemand
kann spaeter sagen, was darin steckt;
* gleichmaessig verteilen -> erfundene Tage, die es nie gab.
Der dritte ist dieser: den Zeitraum ALS Zeitraum ablegen. Was drinsteht,
ist dann wahr -- und was er nicht sagt (welcher Tag wie lief),
behauptet er auch nicht.
EIGENE TABELLE UND NICHT EIN FELD IN `leistung`: Dort ist der
Schluessel (creator, tag). Ein Zeitraum ab dem 1. September wuerde mit
dem ECHTEN 1. September zusammenstossen, und eine der beiden Zahlen
waere weg. Getrennt kann keines das andere ueberschreiben -- und die
Wochenzahlen bleiben, was sie sind: aus Tagen gerechnet.
Der Schluessel ist (creator, von, bis): Dieselbe Datei zweimal
einzulesen ersetzt denselben Zeitraum, statt ihn zu verdoppeln.
AUF DER SEITE steht ein eigener Block zwischen Woche und Tageszeilen:
die Spanne vorn, die Zahl der Tage als Marke daneben, die Werte
darunter. Dazu EINE Umrechnung, und nur diese: "Ø 4.129 Diamanten pro
Tag" -- als Durchschnitt bezeichnet, nirgends gespeichert. Wer eine
Woche vergleichen will, braucht sie; wer sie fuer einen echten Tag
haelt, hat das Wort nicht gelesen. Darueber steht woertlich, dass diese
Zahlen nicht in die Wochenzahlen eingehen.
MIT DER ECHTEN DATEI GEMESSEN: alle 8 Zeilen gehen durch, 8 als
Zeitraum, 0 abgelehnt. Spanne 01.09.-11.09. = 11 Tage, Diamanten
53.679, Dauer 5171 Minuten.
pruef-backstage-import 86 -> 106. Die Pruefung, auf die es ankommt, ist
nicht "es wird gespeichert", sondern "es wird NICHT in die Woche
gemischt": kein Tag kommt hinzu, die Wochenzahl bleibt Ziffer fuer
Ziffer dieselbe. Dazu die Gegenprobe, dass ein Zeitraum von EINEM Tag
weiterhin ein Tag bleibt -- sonst hiesse alles andere nur, dass jetzt
alles als Zeitraum abgelegt wird.
DREI PRUEFUNGEN GEDREHT, KEINE GELOESCHT: Zwei behaupteten noch die
Ablehnung vom Vormittag. Und tagAusZelle() hat jetzt DREI Ausgaenge
statt zwei (Tag, Zeitraum, Grund) -- geprueft wird, dass nie zwei davon
gleichzeitig kommen. Gaebe es zwei, entschiede jeder Aufrufer selbst,
was Vorrang hat, und der zweite entschiede anders als der erste. Genau
daran ist heute frueh der Zeitraum-Schutz gescheitert.
ZWEI EIGENE MESSFEHLER, beide von der Pruefung gefunden: Ich verlangte
"kein einziger Tag in der Spanne" und uebersah, dass weiter oben schon
ein Tag geschrieben worden war, der hineinfaellt -- gemessen wird jetzt
die VERAENDERUNG. Und ich mass den Zeitraum-Block, waehrend ein anderer
Creator geoeffnet war: keine Frage an die Seite, sondern an die falsche
Person.
Nebenbei zum zweiten Mal heute: eine Versalzeile mit 10,88 px. Auf
.72rem angehoben, bevor pruef-css-klassen sie findet.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
0207b05da6 |
Die Rechte Hand steht ueber den Modis -- sortiert statt geschrieben
Filipe, mit dem Bildschirmfoto: "rechte hand soll immer ueber modi stehen bitte." DIE REIHENFOLGE STAND AN ZWEI STELLEN, und die zweite war falsch herum: ROLLEN_REIHE hatte die Rechte Hand laengst vor den Modis (und die SQL-Sortierung leitet sich daraus ab) -- aber `zusatzrollen` in workspace-personen.js schrieb sie von Hand, und dort kam Modi zuerst. Genau diese Liste baut die Abschnitte auf der Personenseite und die zusaetzlichen Knoepfe im Anlegen-Formular. Das ist an diesem Tag das VIERTE Mal dieselbe Sache: eine Aussage, zwei Listen, und die zweite ist die, die abweicht. Vorher: der Zeitraum-Schutz (an einer von drei Stellen), die Dauer-Einheit (dieselbe), das Recht zum Aufloesen (Liste kannte es, Nachrichtenweg nicht). Deshalb wird jetzt SORTIERT und nicht geschrieben: Die Liste geht durch ROLLEN_REIHE. Wer die Reihenfolge aendern will, aendert sie dort -- und alles andere zieht nach, statt nachgezogen werden zu muessen. Was in ROLLEN_REIHE nicht vorkommt (heute "gast"/Community), wandert ans Ende statt stillschweigend nach vorn. pruef-haus-trennung 63 -> 66. GEPRUEFT WIRD DIE REIHENFOLGE, NICHT DIE ANWESENHEIT: "beide sind da" waere auch dann gruen gewesen, wenn sie vertauscht sind -- und genau das war der Fall. Dazu eine Zeile, die nachweist, dass die Reihenfolge wirklich aus ROLLEN_REIHE kommt und nicht nur zufaellig stimmt; sonst haette jemand sie auch von Hand andersherum schreiben koennen: richtig im Ergebnis, falsch im Aufbau, und beim naechsten Mal wieder auseinander. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
9f277435a5 |
Reaktionen: Vorschlaege, ganzer Katalog, eigene Favoriten
Filipe: "soll viel besser und geiler sein und man soll auch auswaehlen
koennen, also paar als vorschlaege mit der moeglichkeit andere
auszuwaehlen und als favoriten zu speichern."
Aus einem Streifen mit sechs Zeichen ist eine Karte geworden:
Vorschlaege oben, Suchfeld, darunter der Katalog in sechs Gruppen --
82 Zeichen, jedes mit deutschen Suchwoertern. Wer "feuer" tippt, muss
nicht scrollen.
DREI LISTEN, DREI FRAGEN, und sie werden gern verwechselt:
KATALOG Was gibt es? fest, workspace-reaktionen.js
VORSCHLAG Was steht vorn, solange fest -- bis jemand eigene
ich nichts gewaehlt habe? Favoriten hat
FAVORITEN Was hat DIESER Mensch in der Datenbank
sich gemerkt?
Nur der Katalog entscheidet, was ANGENOMMEN wird. Vorschlag und
Favoriten sind Reihenfolge, keine Erlaubnis -- sonst koennte man sich
ueber einen Favoriten etwas erlauben, das im Katalog nicht steht. Die
erlaubte Menge wird aus dem Katalog ABGELEITET; eine zweite Liste
daneben waere die, in der ein Zeichen fehlt, das die Oberflaeche
anbietet.
FAVORITEN HAENGEN AM MENSCHEN, NICHT AM GERAET. Im Browser abgelegt
waeren sie am Handy andere als am Rechner und beim naechsten Loeschen
der Seitendaten weg.
DER STERN SCHALTET EINEN MODUS, statt an jedem Zeichen einen zweiten
Knopf zu haben: Am Handy gibt es kein "daneben zeigen". Im Merk-Modus
faerbt sich die ganze Tafel, damit niemand reagiert, wenn er merken
wollte. Die Tafel bleibt dabei offen -- acht Favoriten waeren sonst
acht Mal Aufmachen -- und die Vorschlagszeile aendert sich sofort mit.
DIE GRENZE SAGT BESCHEID, statt still den aeltesten wegzuwerfen: Wer
einen neunten merken will, bekommt "nimm erst einen weg". Ein Favorit,
der ohne Ansage verschwindet, sieht wie ein Fehler aus.
Eine Selbstpruefung beim Laden meldet doppelte Zeichen im Katalog und
Vorschlaege, die nicht darin stehen -- beides waere in der Tafel still.
pruef-chat-aufloesen 85 -> 115. Gemessen wird, was PASSIERT, nicht dass
es Elemente gibt: dass die Suche wirklich eingrenzt (1 statt 82) und
das Richtige findet, dass ein Fehlgriff "Nichts zu ... gefunden" sagt
statt eine leere Flaeche zu zeigen, und vor allem, dass im Merk-Modus
KEINE Reaktion entsteht -- an der Zahl der Reaktionen gemessen, nicht
an der Absicht.
NEBENBEFUND AUS DER EIGENEN PRUEFUNG: pruef-css-klassen hat meine
Gruppenueberschrift mit 10,56 px abgelehnt (Grenze 11,5). Richtig so --
eine gesperrte Versalzeile ist ohnehin schwerer zu lesen, die darf
nicht auch noch die kleinste sein. Auf .72rem angehoben, statt die
Grundlinie zu verschieben.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
47269bda21 |
Chat: auf eine Nachricht reagieren, ohne zu antworten
Filipe: "ich will dass man auf die nachrichten auch reagieren kann mit einem emoji, die nachricht selbst ohne zu antworten." Neben "antworten" steht jetzt "reagieren". Ein Klick klappt sechs Zeichen auf, ein zweiter Klick setzt es -- und unter der Nachricht steht, wer mit was reagiert hat. EINE FESTE AUSWAHL, KEIN FREIES FELD (👍 ❤️ 😂 😮 🔥 🙏). Drei Gruende, der erste ist der wichtigste: Eine feste Liste laesst sich pruefen -- was dort nicht drinsteht, kommt nicht in die Datenbank, kein beliebiger Text, keine 4-KB-Zeichenketten. Zweitens sehen alle dasselbe. Drittens kann man sechs Zeichen ueberfliegen; eine volle Tafel ist eine Suchaufgabe, und dann tippt man doch wieder "ok". DIE LISTE STEHT AUF DEM SERVER und wird an die Oberflaeche geliefert. Stuende sie im Browser, gaebe es sie zweimal -- und die zweite Fassung waere die, in der ein Zeichen fehlt, das der Server noch annimmt. Faellt der Abruf aus, erscheint KEINE Auswahl statt einer mit erfundenen Zeichen. DER PRIMAERSCHLUESSEL BEANTWORTET "WIE OFT?": (nachricht, person, zeichen). Eine Person darf verschiedene Zeichen geben, jedes aber nur einmal -- und zwar durchgesetzt von der Datenbank, nicht von einer Abfrage davor, die man vergessen kann. Derselbe Klick noch einmal nimmt es zurueck; das erspart einen zweiten Weg, den man auch absichern muesste. KEIN ZAEHLER IN chat_nachrichten. Eine mitgefuehrte Zahl muesste bei jedem Hin und Her stimmen und ist genau die Art Angabe, die irgendwann nicht mehr stimmt und die niemand nachrechnet. Gezaehlt wird beim Lesen -- in EINER Abfrage fuer alle 200 Nachrichten, nicht je Zeile eine. WER ES WAR, STEHT IM TITEL. "Drei Daumen" sagt weniger als "Ayla, Ben und Cem", und es sind Leute aus demselben Raum. KEINE BENACHRICHTIGUNG AUFS HANDY. Wer im Raum ist, sieht es sofort; wer nicht, bekommt nichts. Ein Daumen ist keine Nachricht -- wer dafuer geweckt wird, schaltet Meldungen ab. Was NICHT geht: wer nicht im Raum ist (404), ein erfundenes Zeichen (400), eine zurueckgenommene Nachricht (409). Und mit der Nachricht verschwinden die Reaktionen (CASCADE). pruef-chat-aufloesen 59 -> 85. Gemessen wird der BESTAND, nicht die Antwort -- und im Browser der KNOPF, nicht nur das Recht: dass die Auswahl aufklappt, sich nach dem Klick von selbst schliesst, die Reaktion darunter erscheint, als die eigene erkennbar ist und ein Klick darauf sie wieder wegnimmt. EINE EIGENE PRUEFUNG WAR ZU SCHWACH: "bei Cem ist ueberall selbst=true" war trivial wahr, weil es nur EINE Sorte gab. Jetzt bekommt eine andere Person ein drittes Zeichen, und in derselben Antwort muss eines auf true und eines auf false stehen. Eine Angabe, die nie `false` sein kann, sagt nichts. Im CSS keine vierte Abschrift: "reagieren" haengt an derselben Regel wie "antworten" -- neben anheften und kopieren waere es die vierte fast gleiche gewesen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
6ed61a6b3d |
Die Zeitraum-Regel galt nur an einer Stelle -- Filipe fand die andere
"jetzt hab ich eine hochgeladen ber sehe sie nicht."
WAS PASSIERT IST, aus der Datenbank gelesen und nicht vermutet: Seine
Backstage-Ausgabe lief durch den EINZEL-Import ("Aus Datei einlesen")
und schrieb genau eine Zeile -- creator_id 2, Tag 2026-09-01, alle
Werte 0, Quelle "import", erfasst 11:52. Unsichtbar war sie aus zwei
Gruenden: Der 1. September liegt 13 Tage zurueck (die Liste zeigt
sieben), und es stand nichts darin.
DREI FEHLER AUF EINMAL, und alle drei waren meine:
1. DER ZEITRAUM-SCHUTZ STAND NUR IM BACKSTAGE-WEG. Ich hatte ihn heute
frueh gebaut, gemessen, geprueft -- und an genau einer von drei
Stellen eingesetzt. "2026-09-01 ~ 2026-09-11" wurde im Einzel-Import
weiterhin zum 1. September.
Das ist an diesem Tag das DRITTE Mal dieselbe Sache: eine Regel,
zweimal aufgeschrieben, und die zweite Abschrift ist die
unvollstaendige. Jetzt steht sie EINMAL in `tagAusZelle()` und wird
dreimal benutzt. Sie liefert immer genau eines von beidem: Tag oder
Grund -- nie beides, nie keines.
2. DIE DAUER-EINHEIT FEHLTE DORT EBENFALLS. Auch das hatte ich nur im
Backstage-Weg eingesetzt.
3. DIE DATEI GEHOERTE GAR NICHT DORTHIN. Sie enthaelt ALLE
Creator:innen; der Einzel-Import schreibt auf EINE Person. Es gab
keine Fehlermeldung -- es passierte nur nichts Sichtbares, und das
ist die schlechteste aller Antworten.
Jetzt erkennt der Weg eine Namensspalte mit mehreren verschiedenen
Eintraegen und sagt: "In dieser Datei stehen 3 verschiedene Creator
(Spalte ...). Dieser Weg schreibt auf EINE Person. Nimm
'Backstage-Tabelle einfuegen'." Mit Gegenprobe, dass eine Datei mit
EINEM Creator weiterhin durchgeht.
pruef-xlsx 60 -> 67, pruef-backstage-import 82 -> 86.
NEBENBEFUND AUS DER EIGENEN PRUEFUNG: Mein Testfile fuer den
Einzel-Import hatte selbst zwei verschiedene Creator -- die neue Sperre
hat es sofort abgewiesen. Das war ihr erster echter Treffer, und es
zeigt, dass ich den Weg beim Schreiben der Pruefung selbst falsch
verstanden hatte. Jetzt steht dort, wofuer er da ist: eine Person,
mehrere Tage.
Die Zeile vom 1. September steht noch in der Datenbank. Sie zu
entfernen ist Filipes Entscheidung, nicht meine.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
58932ece8c |
Excel-Dateien werden gelesen -- und drei Fallen dahinter entschaerft
Filipe: "mach doch bitte so dass man alle dateien hoch laden könne auch
excel dateien. gib gas und krieg das hin."
server/workspace-xlsx.js liest .xlsx mit Bordmitteln: Eine .xlsx ist ein
ZIP mit XML darin, und Node kann beides (`zlib.inflateRawSync`). Kein
zusaetzliches Paket fuer eine Datei mit neun Zeilen.
GEMESSEN AN ZWEI ECHTEN BACKSTAGE-AUSGABEN vom 11. und 12.09.2026, die
auf dem Rechner lagen -- nicht an der Dokumentation. Sie haben mir an
drei Stellen widersprochen, und JEDE davon waere sonst ein stiller
Fehler geworden:
1. DER ZEITRAUM. In "Datenzeitraum" steht `2026-09-01 ~ 2026-09-11`.
`datumLesen` griff sich davon den ersten Tag -- elf Tage Diamanten
waeren auf den 1. September gebucht worden. Die Zahl steht da, sie
ist gross, sie sieht richtig aus, und niemand kann spaeter sagen,
dass elf Tage darin stecken. Neu: `zeitraumLesen`; eine Zeile mit
einem Zeitraum ueber mehrere Tage wird abgelehnt UND begruendet
("Stell in Backstage den Zeitraum auf EINEN Tag"). Ein Zeitraum von
einem Tag geht durch.
2. DIE EINHEIT. "LIVE-Dauer" enthaelt `86Std. 10Min. 52Sek.`.
`zahlLesen` ergab daraus `null` -- die Dauer fiel weg. Bei einem
anderen Trennzeichen waere es schlimmer gewesen: 86 statt 5171,
Faktor 60 daneben und plausibel. Neu: `dauerLesen`, versteht die
deutsche und englische Schreibweise, die Uhrzeitform und weiterhin
die blosse Zahl.
3. DIE DATUMSSPALTE. `/datum|date|tag|day/i` erklaerte "Tage seit dem
Beitritt" zur Datumsspalte (Wert "65") und traf in der
Leistungstabelle "Gueltige LIVE-Gehen-Tage" genauso. Jetzt nur noch
als ganzes Wort, dafuer mit "zeitraum" -- Backstages Spalte wurde
bisher nur zufaellig gefunden, weil in "Daten" die Silbe "date"
steckt.
Gefunden hat das keine Ueberlegung, sondern der ganze Weg einmal mit
der echten Datei durchlaufen.
WEITER GEBAUT:
- Titelzeilen werden uebersprungen: "Creator:innen verwalten" hat in
Zeile 1 nur "Exportiert am :…", die Ueberschriften stehen darunter.
Die Regel misst (drei gefuellte Felder UND halb so breit wie die
breiteste Zeile), statt eine feste Zahl zu nehmen.
- Fehlende Zellen verschieben nichts: Eine leere Zelle steht in der
Datei gar nicht; wer der Reihe nach liest, verrutscht ab dort jede
Spalte, und die Zeile sieht voll aus.
- Datums-Seriennummern werden nur umgerechnet, wenn das FORMAT es sagt
(sonst stuende 46271 in der Vorschau). Der Nullpunkt ist an zwei
nachschlagbaren Werten festgenagelt.
- Der Backstage-Dialog nimmt die Datei jetzt AUCH -- dort gehoert sie
hin, denn Filipes Ausgabe enthaelt alle Creator auf einmal. Sie fuellt
das Einfuegefeld; ab da laeuft derselbe Weg wie beim Einfuegen. Keine
zweite Fassung derselben Regeln.
- Die alte .xls (BIFF, kein ZIP) wird erkannt und bekommt einen Weg
gezeigt, statt "ging nicht" zu sagen.
NEU: pruef-xlsx.mjs (60) -- baut seine Dateien selbst (ZIP-Schreiber in
helfer-xlsx-bauen.mjs), damit keine Creator-Daten ins Repo wandern und
auch Faelle pruefbar sind, die es als Datei nicht gibt: kaputtes
Verzeichnis, fehlendes Blatt, abgeschnittene Datei. Jeder davon mit
Gegenprobe, dass die heile Datei durchgeht.
pruef-backstage-import 77 -> 82, dabei zwei Pruefungen GEDREHT: Die
.xlsx bekommt keine Absage mehr, sondern eine Vorschau.
DREI EIGENE FEHLER DABEI, alle von einer Messung gefunden:
- Ich hielt Seriennummer 46264 fuer den 06.09.; es ist der 30.08. Der
Code hatte recht. Deshalb stehen jetzt zwei nachschlagbare Anker drin.
- Eine Zeile war gruen, weil mein Muster den SPALTENNAMEN
"Datenzeitraum" traf statt der Begruendung. Jetzt wird auf den Text
der Ablehnung geprueft.
- Beim Umbau habe ich pruef-backstage-import beschaedigt (ein
Suchtreffer weiter oben als gemeint) und aus Git zurueckgeholt.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e3aeeb01cd |
Rollen wechseln: auch Spicy Media -- und DogFather ist nicht mehr vergebbar
Filipe: "ich will dass die rolle spicy und dogfather, auch die rollen
wechseln koennen wenn die personen schon drin sind. von alle
kategorien, creator, scouts, manager spicy. dogfather soll man nicht
auswaehlen koennen. das ist die einzige die man nicht auswaehlen kann
bitte."
ZWEI AENDERUNGEN, BEIDE IN EINER LISTE (ANLEGBAR):
admin: alles AUSSER der eigenen Rolle
spicy: spicy, manager, scout, creator (vorher ohne spicy)
Weil die Oberflaeche ihre Knoepfe aus derselben Auskunft baut
(`darf_anlegen` in /api/ich), verschwindet DogFather damit von selbst
aus JEDER Auswahl -- beim Anlegen wie beim Wechseln, bei Spicy Media
wie bei DogFather. Eine Liste, zwei Formulare, kein Nachziehen.
WAS DAS BEDEUTET, damit es niemand spaeter sucht: Es laesst sich kein
zweiter DogFather-Zugang mehr anlegen und niemand mehr zu einem
befoerdern. Der bestehende ist durch Sicherung 3 geschuetzt (nie den
letzten herabstufen) und kann nicht versehentlich verschwinden.
Zurueckdrehen laesst sich das nur in ANLEGBAR.
DIE TUER: /verwaltung haengt an nurAdmin, und dort steht jetzt eine
DRITTE enge Ausnahme -- PUT auf genau /personen/<Ziffern>/rolle, fuer
genau die Rollen aus darfRollenWechseln(). Gleiche Bauweise wie die
beiden davor (Liste fuer Spicy Media, Liste fuer die rechte Hand). Was
NICHT mitgeht: Codes, Sperren, Loeschen, Zuteilung, Protokoll.
EINE NEUE SICHERUNG, weil sich die Tuer geoeffnet hat: An einer
DogFather-Zeile aendert nur DogFather. Die bestehenden Pruefungen sehen
auf die ZIEL-Rolle ("darfst du 'manager' vergeben?") -- dass die
BETROFFENE Person DogFather ist, kam darin bis heute nicht vor.
Sicherung 3 haette es heute zufaellig abgefangen, weil es genau einen
gibt; eine Sperre, die nur wegen einer Zahl im Bestand haelt, ist
keine.
DIE OBERFLAECHE: "Rolle aendern" und "Loeschen" hingen an EINER Zeile
(`ich.rolle === 'admin'`). Sie gehoeren nicht zusammen -- Loeschen
bleibt bei DogFather. Und die CSS-Regel, die fuer Spicy Media die ganze
Knopfreihe ausblendete, ist weg: Welche Knoepfe es gibt, entscheidet
jetzt personen.js, und was nicht entsteht, muss man nicht verstecken.
pruef-spicy 62 -> 83. Gemessen wird jede der vier Kategorien EINZELN
(waere nur eine offen, saehe "geht" genauso aus), dazu: admin weder von
Spicy Media noch von DogFather vergebbar, an DogFathers Zeile aendert
sie nichts (und er ist danach nachweislich noch admin), ein Manager
kommt an den Weg nicht, loeschen bleibt zu -- und im Browser, dass der
KNOPF da ist, nicht nur das Recht. Genau daran war heute frueh im Chat
eine Stunde draufgegangen.
Dabei zwei eigene Messfehler gefunden: Die Knoepfe entstehen erst in
einer AUFGEKLAPPTEN Kategorie (vorher zu frueh gemessen), und /api/ich
wird jetzt als Vorbedingung geprueft.
DREI PRUEFUNGEN GEDREHT, KEINE GELOESCHT:
- pruef-personen-formular: 7 Karten, `admin` fehlt (eigene Aussage).
Die Zeichenpruefung verglich die rechte Hand gegen die Admin-KARTE --
die es nicht mehr gibt; sie lief gegen `undefined`. Ersatz ist das
Zeichen selbst, und der Kommentar sagt, dass das schwaecher ist.
- pruef-haus-trennung: Der zweite DogFather entsteht jetzt im Bestand
statt ueber die Schnittstelle, und DASS die Schnittstelle ihn
ablehnt, ist der erste Prueffall geworden. Sonst waere "nie den
letzten DogFather" ab heute ungeprueft -- weil ihre Voraussetzung
schwerer herzustellen ist.
- pruef-creator-anlegen: aus einer Aussage zwei (die vier sind da UND
admin fehlt).
Gruen: personen-liste, personen-kachel, verborgen, manager-sicht,
creator-anlegen, haus-trennung, personen-formular, spicy, rollen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
1ab2729e47 |
Die rechte Hand steht ueberall an zweiter Stelle - und im Kalender ueberhaupt
Filipe, mit Bildschirmfoto der Liste "Wen gehst du durch?" (Diene, Dogi,
VanVan - alphabetisch, die rechte Hand ganz rechts): "rechte hand soll
immer als erstes sein. ueberall. wie in dem sinne soll sie ganz links
sein. ausser bei personen und zugaenge soll sie ueber jedem aber unter
dogfather sein. ich will dass auch ueberall immer nach der hirarchie
gearbeitet wird."
EINE REIHENFOLGE, NICHT ZWEI REGELN
ROLLEN_REIHE in workspace.js ist jetzt:
Spicy Media > DogFather > Rechte Hand > Manager > Scout > Creator > Modi
Er hat zwei Faelle beschrieben, aber es braucht nur eine Reihenfolge: In
den Team-Listen kommt DogFather gar nicht vor (er beurteilt, er wird
nicht beurteilt) - dort steht sie dadurch automatisch ganz vorn. In
"Personen & Zugaenge" steht er drin, also steht sie dort hinter ihm.
Zwei Sonderfaelle waeren zwei Stellen, an denen es auseinanderlaeuft.
Dass Spicy Media davor bleibt, ist seine ausdrueckliche Entscheidung auf
Nachfrage. 'gast' steht bewusst nicht in der Liste und faellt ans Ende.
ROLLEN_SORTIERUNG (der SQL-Ausdruck) wird jetzt aus ROLLEN_REIHE
ABGELEITET statt danebengeschrieben. Bis heute stand die Reihenfolge
zweimal da; beim Hochziehen der rechten Hand haetten beide geaendert
werden muessen. Eine Liste, die niemand pflegt, kann nicht veralten -
derselbe Grundsatz wie beim Spaltenverlust vom 06.09.
WAS DABEI AUFFIEL, OHNE DASS JEMAND DANACH GESUCHT HAT
Der Server sortierte laengst richtig. DREI Auswahllisten im Browser
haben seine Reihenfolge wieder verworfen und nach einer eigenen Liste
mit fuenf Agentur-Rollen neu gezeichnet - Team Dogi kommt darin nicht
vor und DARF es nicht (bereiche.js laedt jeder herunter).
- Chat-Auswahl und Sicht-Umschalter: Team Dogi landete in einem
Nachzuegler-Block ganz unten, hinter jedem Creator.
- Teilnehmerwahl im Kalender: dort gab es nicht einmal einen
Nachzuegler-Block. Die rechte Hand und die Modis standen GAR NICHT
zur Auswahl. DogFather konnte sein eigenes Team zu keinem Termin
einladen, und auf dem Bildschirm sah das vollkommen normal aus.
Das ist derselbe Fehler zum vierten Mal (Chat 10.09., Personenliste
10.09., Sicht-Umschalter 11.09., Kalender 11.09.). Deshalb keine vierte
Einzelreparatur, sondern eine Stelle: window.Bereiche.gruppieren()
gruppiert in genau der Reihenfolge, in der der Server die Menschen
schickt - ohne einen einzigen Rang zu kennen. Fehlt der Helfer, wird
eine Gruppe mit allen gezeichnet: nicht schoen, aber sichtbar, und
niemand verschwindet. Der Kalender-Weg schickt die Ueberschrift jetzt
mit, wie der Chat es laengst tut.
PRUEFUNGEN
pruef-nachwuchs 109 -> 123 (Abschnitt 12: die Reihenfolge, mit der
Gegenprobe, dass sie NICHT alphabetisch ist -- Rieke
steht alphabetisch hinten, mit "Anna" waere jede
Zeile gruen ohne etwas zu messen)
pruef-dabei-optik misst die Wahl jetzt im Browser: ist Team Dogi
ueberhaupt da, und steht es vorn
pruef-rollen 315 (vorher 312), 423 s gemessen. Die Notbremse lag
bei 480 s und hat angeschlagen - kein Haenger,
sondern zu wenig Luft, seit die rechte Hand vier
Kacheln mehr hat. Jetzt 900 s, mit der Messung
daneben und dem Hinweis, beim naechsten Mal nicht
die Zahl zu erhoehen, sondern nachzusehen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
bba3642664 |
Aus der Probe wird ein Zugang - und die Seite sagt nicht mehr "Agentur"
Die drei offenen Punkte aus Abschnitt 9 des Plans, plus Filipes zweite
Ansage: "auf dieser seite soll nichts stehen von agentur, diese seite
hier ist nur fuer mich meine modis und meine community."
1. PROBE -> ZUGANG (ein Knopf statt eines Satzes)
Auf der Stufe "Probe" stand bisher "Zugang in Personen & Zugaenge
anlegen, Rolle Modi" - und wer das vergass, hatte eine Karte auf "Im
Team" und keinen Menschen darin. Jetzt haengt das Anlegen am Schritt
selbst.
Ueber DENSELBEN Weg wie in "Personen & Zugaenge", nicht ueber einen
zweiten: POST /workspace/api/verwaltung/personen, mit ihrer
Rechtepruefung, ihrem Protokolleintrag und ihrem genau einmal
angezeigten Code. Der Talente-Server legt selbst keinen einzigen Zugang
an, und die Pruefung zaehlt nach, dass es bei einem Weg bleibt.
Der Code steht im gleichen Kasten wie dort - die Gestaltung ist aus
personen.css nach start.css umgezogen, weil talente.html sie sonst nicht
laedt. Ein Geheimnis sieht im ganzen Haus gleich aus. Er steht
ausserhalb der Liste, sonst waere er in dem Moment weg, in dem er
entsteht: wenn die Karte auf "Im Team" springt.
Die rechte Hand bekommt an dieser Stelle KEINEN Knopf, sondern einen
Satz. Ein Knopf, der ihr jedes Mal "darfst du nicht" antwortet, waere
schlechter als gar keiner - er verspricht etwas.
2. DIE EIGENE KARTE (Abschnitt "Deine Karte")
Wer beschrieben wird, darf es lesen - aber erst, wenn ALLE gesetzt
haben (sonst waere die erste Einschaetzung eine Vorgabe fuer die
zweite), und ohne Namen und ohne Anlasstext. Gemessen in beide
Richtungen: vorher nicht sichtbar, nachher sichtbar.
3. DER VORLAGENTEXT
Gebaut aus den angeklickten Merkmalen, in einem Feld zum Aendern, nicht
zum Abschicken. Ohne Merkmale steht auch keines drin.
4. "GILT FUER" SAGT DER SERVER
In bereich.js stand woertlich "Agentur" - richtig auf der
Agenturadresse, falsch auf jeder anderen. Jetzt liefert der Server
`gehoert` ("Der Treff" / "Team Dogi" / "Agentur"); gemessen mit einem
einzigen Menschen auf zwei Adressen.
PRUEFUNGEN: treff 58 -> 66, nachwuchs 69 -> 109, neue-seiten 70 -> 93.
Die Katalogseiten werden jetzt auch mit den Augen der rechten Hand
angesehen - ohne das waere "Deine Karte" nie auf einem Bildschirm
gewesen. Und pruef-neue-seiten wartet nicht mehr 900 ms, sondern bis
sich der Text nicht mehr aendert: Die Karte stand da und wurde
trotzdem als fehlend gemeldet, weil zu frueh gelesen wurde.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
44e5ace109 |
"Wer sieht was" auf beiden Adressen — und die Tafel lässt sich umstellen
Filipe: "ich will die kategorie auch auf der team dogi seite für die dogfather und rechte hand rollen ... und wenn man drauf drückt, perfektionieren so dass ich die da auch manuell wechseln und speichern kann." DIE KACHEL STAND NUR AUF DER AGENTURSEITE. Auf der Team-Dogi-Seite arbeitet ihr aber täglich; dort nicht nachsehen zu können, wer was darf, hieße, die Frage an dem Ort zu stellen, an dem man gerade nicht ist. Sie steht jetzt auf beiden — einmal beschrieben, zweimal benutzt. ANSEHEN BEIDE, UMSTELLEN NUR DOGFATHER. Die rechte Hand bekommt dieselbe Tafel und keine Knöpfe; nicht weil das Skript sie versteckt, sondern weil der Server darf_aendern: false schickt. Wer Rechte vergeben kann, kann sich Rechte vergeben — diese eine Tür bleibt bei ihm. WAS GESPEICHERT WIRD, IST NUR DER UNTERSCHIED. In der Datenbank steht eine Zeile nur, wenn sie vom Grundstand in rechte.js abweicht. Damit bedeutet der Code weiterhin etwas: Man sieht, was gedacht war, und daneben, was jemand daraus gemacht hat. "Zurück auf Grundstand" ist ein DELETE, und eine neue Seite erbt automatisch den Grundstand — eine vollständige Kopie in der Datenbank hätte sie nicht gekannt und sie wäre für alle zu gewesen, ohne dass es jemand entschieden hätte. DREI FELDER SIND FEST: DogFather kann sich die Rechte-, die Personen- und die Startseite nicht selbst wegnehmen. Eine Einstellung, aus der man sich aussperren kann, ist keine Einstellung, sondern eine Falle — und sie wäre genau einen Fehlklick entfernt gewesen. GESPEICHERT WIRD SOFORT, mit jedem Klick. Kein "Speichern" am Ende: Bei zweihundert Feldern ist das die Stelle, an der eine halbe Änderung verlorengeht, und eine halbe Änderung an Rechten ist die gefährlichste Lage von allen. Rückfrage gibt es nur beim ÖFFNEN — etwas wegzunehmen sieht sofort jemand, etwas aufzumachen unter Umständen lange niemand. DER BEFUND, DEN DIE PRÜFUNG GEFUNDEN HAT: Nimmt man einem Modi eine Seite weg, greift die Schranke sofort — und die KACHEL blieb stehen. Ein Knopf, der auf die Startseite zurückwirft. Der Satz "Kachel und Tür gehören zusammen" steht seit dem 06.09. im Code; bis heute war er eine Bitte an den, der beides pflegt. Jetzt ist er eine Rechnung: Beide Kachellisten — die des Servers und die im Browser — werden gegen dieselbe Tafel gefiltert, aus der die Schranke ihre Entscheidung holt. Geprüft wird nicht, ob die Antwort 200 lautet, sondern ob sich das VERHALTEN ändert: Der Modi kommt danach wirklich nicht mehr hinein — mit Gegenprobe davor. Und eine Umstellung überlebt einen Neustart; ohne tafelLaden() beim Start hätte wieder der Grundstand gegolten, und es hätte ausgesehen wie vorher. Geprüft: rollen 315 · start-ansicht 147 · crew-adresse 132 · sicht 84 · modi-verborgen 80 · neue-seiten 70 · treff-werkzeuge 70 · nachwuchs 69 · treff 58 · rechte-umstellen 46 · entwicklung 40 · css-klassen 30 · zwischenspeicher 21 · alle-wege 19 · rechtetafel 19 — alles grün. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
dfd951861a |
Entwicklung & Nachwuchs: zwei Kataloge zum Anklicken statt zwei leerer Formulare
Filipe: "ich will dass diese zwei kategorien perfektionniert werden, ich
will dass fertige aufgaben da stehen und so ... so dass dogfather und
rechte hand es so einfach wie möglich haben aber so professionell wie
auch nur möglich."
Bis heute waren beide Kacheln ein leeres Formular: Titel tippen, Art
wählen, Text schreiben. Ein leeres Feld beantwortet keine Frage — es
stellt sie noch einmal.
ENTWICKLUNG: 34 Beobachtungen in fünf Blöcken, vier Antworten je Zeile
(Läuft · Wächst gerade · Da hakt es · Kann ich nicht sagen). Es sind
BEOBACHTUNGEN, keine Eigenschaften — "Absagen kommen rechtzeitig" statt
"ist zuverlässig". Eine Eigenschaft kann man nur bestätigen oder
bestreiten; ein Verhalten kann man gesehen haben oder nicht.
TALENTE: 21 Merkmale in fünf Gruppen, 6 Warnzeichen getrennt geführt,
fünf Trichterstufen mit je GENAU EINEM nächsten Schritt. Eine Liste
wächst und wird nie wieder angesehen; ein Trichter fragt bei jeder Karte
"und jetzt?". Die Standzeit steht dabei — "seit 41 Tagen beobachtet"
ist eine Auskunft über uns, nicht über den Kandidaten.
VIER RIEGEL, JEDER MIT GEGENPROBE:
· Block 5 ("Wie geht es dir damit?") gehört der Person — lesend UND
schreibend, auch vor DogFather. Er kommt gar nicht erst aus dem
Server; Schreiben gibt dasselbe 404 wie ein erfundener Schlüssel.
Nach außen dringt eine Ampel OHNE Namen, und die schweigt, solange
das Team so klein ist, dass "jemandem geht es zu viel" dasselbe wäre
wie ein Name.
· Der Stand des anderen kommt erst nach dem eigenen Klick — sonst
klickt man dasselbe. Sichtbar ist nur, DASS es einen gibt: sonst
sähen "noch niemand" und "du darfst es nicht sehen" gleich aus.
· "Da hakt es" ohne Anlass wird abgelehnt. "Läuft" nicht — 28
Pflichtfelder je Person wären das Gegenteil von "so einfach wie
möglich".
· Talente gehört DogFather und der rechten Hand. Ein Modi bekommt 404
auf Seite UND Schnittstelle.
WAS NICHT GEBAUT IST, UND WARUM: keine Punktzahl, kein Durchschnitt,
keine Rangliste, keine Gesamtnote. Eine Zahl über einem Menschen wird
gelesen, verglichen und weitererzählt. Und kein Rot — "da hakt es" ist
eine Beobachtung, kein Alarm.
DER PLAN LAG AN EINER STELLE FALSCH, gemessen statt vermutet: Er sagte
"keine neue Tabelle, der Stand liegt in punkt_stand". Dort ist der
Schlüssel (bereich, schluessel, creator_id) — genau EIN Stand je Punkt
und Person. Zwei unabhängige Augenpaare passen da nicht hinein, ohne
eine lebende Tabelle neu zu bauen. Also eine eigene.
EIN RÜCKSCHLAG, DEN NUR DIE PRÜFUNG GEFUNDEN HAT: Die Liste der
Bretter, die ein Modi oder die rechte Hand öffnen darf, wird aus den
KACHELZIELEN abgeleitet. Als die Kacheln auf die neuen Seiten zeigten,
fielen beide Bretter heraus — und die Seite verlinkte auf ein 404. Kein
Fehler im Riegel, sondern in seiner Quelle.
Dazu zwei kleinere Funde vom Hinsehen statt vom Messen: Die Ampel sagte
"Solange ihr zu 1 seid" (jetzt drei Sätze für drei Lagen), und die
Fußzeile der Talente-Seite lag auf der Bühne — die Kontrastprüfung hatte
sie übersprungen, weil ein Link darin steht. Beide behoben, und die
Prüfung hat den stillen Aussetzer gleich mit verloren.
Geprüft: rollen 314 · start-ansicht 147 · crew-adresse 132 · neue-seiten
70 · nachwuchs 69 · entwicklung 40 · css-klassen 30 · zwischenspeicher
21 · alle-wege 19 · rechtetafel 19 — alles grün.
Was noch fehlt, steht in der Notiz, Abschnitt 9: die eigene Karte für
die Person, der Übergang "Probe" → Zugang, der Vorlagentext zum
Ansprechen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|