670940bd3a63b653631a53a3d6a7a1b6c98cf96e
26
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
670940bd3a |
Stufe 4: eine Bremse -- und eine stille Sperre, die es nicht gibt
Aus dem Plan im Vault. Diese Stufe steht dort bewusst VOR Galerie und
Gespraech: Mehr Sichtbarkeit heisst mehr Angriffsflaeche, und ein
Bereich, der waechst und keine Bremse hat, waechst genau einmal.
DER TREFF HATTE SCHON MEHR, ALS MEIN PLAN ANNAHM
Stufen (WER schreiben darf: neu, dabei, stamm) und Massnahmen (wer
NICHT MEHR darf: Hinweis, Pause, Ausschluss). Gefehlt hat die Frage
dazwischen: WIE SCHNELL. Ein Stammgast konnte in einer Minute vierzig
Beitraege absetzen -- aus Aerger, aus Versehen oder per Skript.
DIE STILLE SPERRE IST VERWORFEN -- nach einer Messung, nicht nach
einem Gefuehl. `gast` ist eine Rolle mit Zugangscode, es gibt KEINE
Selbstanmeldung. Wer ausgeschlossen wird, kann sich nicht neu
anmelden. Damit loest ein Shadowban ein Problem, das dieses System
nicht hat; er bliebe ein Werkzeug, das Menschen taeuscht, ohne etwas
zu verhindern. Steht jetzt in §9 des Plans: was wir NICHT bauen.
DIE BREMSE: 10 Beitraege je Stunde und Person, nur auf den
Community-Brettern. Keine neue Tabelle -- die Antwort steht schon in
`eintraege`, eine Zaehlung ueber die letzte Stunde genuegt. Eine eigene
Tabelle waere ein zweiter Ort fuer dieselbe Wahrheit und muesste
zusaetzlich aufgeraeumt werden.
Die Absage sagt, WANN es weitergeht ("In 37 Minuten"). Ohne Zeitangabe
probiert jemand im Minutentakt weiter -- genau die Last, die man
verhindern wollte.
MEIN ERSTER ENTWURF BREMSTE DIE FALSCHE ARBEIT: Er zaehlte ALLE
Eintraege. Eine Creatorin mit zehn Content-Ideen haette danach im Treff
nichts mehr schreiben koennen. Eine Bremse, die das richtige Verhalten
bestraft, wird abgeschaltet -- und ist ab da wirkungslos.
DIE TEAM-SICHT: "Was hereinkommt", ganz oben auf der Moderationsseite,
vor den offenen Meldungen. Eine Meldung setzt voraus, dass jemand etwas
GESEHEN hat -- und wer acht Bretter durchklicken muss, tut das nicht
achtmal am Tag. Eine Zeile je Beitrag statt einer Karte: Hier
ueberfliegt man, man liest nicht. Der Inhalt steht auf dem Brett; eine
Vorschau waere eine zweite Stelle, an der derselbe Beitrag steht.
NEU: pruef-bremse (16 Pruefungen)
Die Grenze wird aus dem Code GELESEN, nicht abgeschrieben -- sonst
misst die Pruefung beim naechsten Anpassen etwas anderes als der
Server tut. Dazu die drei Fragen: Greift sie? Trifft sie die richtige
Arbeit (Content bleibt offen, das zweite Treff-Brett nicht)? Und laesst
sie den normalen Fall in Ruhe? Gegenprobe: Beitraege auf vorgestern
zurueckdatiert -- danach muss es sofort wieder gehen.
pruef-treff 66, pruef-wunschliste 30, pruef-countdown 22,
pruef-bereiche-lesend, pruef-css-klassen: gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
7eec2edf3f |
Stufe 3: Die Wunschliste bekommt einen Rang und einen Weg
Aus dem Plan im Vault. Eine Wunschliste ohne sichtbare Erfuellung ist
ein Briefkasten ohne Postbote -- nach dem dritten unbeantworteten
Wunsch schreibt niemand mehr.
ZWEIMAL LAG MEIN PLAN DANEBEN, beide Male zu pessimistisch:
- Die Sortierung nach Stimmen GAB es schon, seit dem 11.09.
- Die Datenbank erlaubte 'angenommen' und 'abgelehnt' laengst in ihrer
CHECK-Regel; nur die Pruefung im Server liess sie nicht durch. Die
Tabelle war der Logik voraus.
Auch ein Plan von gestern Nacht ist eine Bestandsliste und altert.
WAS DAZUGEKOMMEN IST
- Vier Zustaende JE BEREICH statt zwei global: Offen -> Wird gemacht
-> Gemacht, dazu "Diesmal nicht". Eine gemeinsame Liste haette
"Diesmal nicht" auch an einem Schutzvorfall erlaubt, und dort
bedeutet es nichts.
- Ein geplanter Tag dazu: "Wird gemacht" allein ist ein Versprechen,
"Wird gemacht -- am 24.09." ist ein Termin.
- Der Rangbalken. Eine Rangfolge sieht man erst, wenn der ABSTAND
sichtbar ist: 12 Stimmen neben 14 sehen sonst aus wie 1 neben 40.
Fuer ein Vorleseprogramm spricht er in Worten.
- Entschiedenes rutscht nach unten, wird aber NICHT geloescht. Gerade
der erfuellte Wunsch ist der Beweis, dass sich Schreiben lohnt.
"DIESMAL NICHT" IST DER WICHTIGSTE DER VIER, und es ist bewusst nicht
rot. Ein Nein ist eine Antwort, Schweigen ist keine -- aber wer ein
rotes Schild an seinem Wunsch sieht, schreibt keinen zweiten.
UND AUF DEM BILDSCHIRMFOTO STAND "WAS IHR EUCH WUENSCHT".
Die Umlaut-Pruefung von gestern Nacht sah es nicht: Sie kannte die
Kataloge und die festen Seitentexte, aber nicht die
Bereichseinstellungen, aus denen JEDE Ueberschrift und jede
Art-Beschriftung kommt. Sechs Stellen ("Fuer den Stream", "Wie es hier
laeuft", "Haeufige Frage", "Ich haette Lust" ...).
Gefunden hat sie kein Gedankengang, sondern ein Blick auf das fertige
Bild. Die Wortliste hatte ausserdem Loecher -- "wuensch" fehlte
schlicht; 23 Stuecke nachgetragen. pruef-deutsche-texte deckt jetzt
auch die 120 Beschriftungen der Bereiche ab (9 -> 12 Pruefungen), mit
einer Gegenprobe auf genau den Satz, der heute Morgen durchrutschte.
NEU: pruef-wunschliste (30 Pruefungen)
Der aelteste Wunsch bekommt die meisten Stimmen -- genau der Fall, der
eine Sortierung nach Datum entlarvt. Dazu: alle vier Zustaende setzen,
ein erfundener nicht, "abgelehnt" am Anschlagbrett ABGELEHNT, der
geplante Tag, die Balkenbreiten (100/33/0 %), und dass der gemachte
Wunsch weiter in der Liste steht -- nur nicht mehr oben.
pruef-countdown 22, pruef-treff 66, pruef-bereiche-lesend,
pruef-deutsche-texte 12: gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
77db1bcc2e |
Stufe 2: "Wann ist der naechste Stream?" steht jetzt oben
Aus dem Plan im Vault. Bei "Was ansteht" gibt es genau EINE Frage, die
ein Zuschauer hat -- und sie stand in Zeile vier einer Liste wie jede
andere Angabe auch.
Jetzt ganz oben, gross:
ALS NAECHSTES
in 12 Std 15 Min
Abendstream
17.09.2026 um 23:30 Uhr
2 weitere Termine danach
Darunter wird die Liste zum ZEITSTRAHL: Heute und morgen · Diese Woche
· Spaeter · Ohne Datum · Vorbei. Vergangenes steht unten, nicht
dazwischen -- ein abgelaufener Termin zwischen kommenden liest sich wie
ein Fehler.
DER PLAN VERSPRACH ETWAS, DAS DIE DATEN NICHT HERGABEN.
"in 3 Std 12 Min" -- aber `eintraege.datum` ist ein TAG, und die
Pruefung im Server lehnte eine Uhrzeit ausdruecklich ab
(`^\d{4}-\d{2}-\d{2}$`). Ein Stundencountdown war unmoeglich.
Das ist die uebliche Sorte Planungsluecke: Sie steht nicht im Plan, sie
steht in der Datenbank. Neue Spalte `uhrzeit`, OPTIONAL -- viele
Termine haben keine ("diese Woche", "im Oktober"), und ein Pflichtfeld
haette dafuer eine erfundene erzwungen. Ohne Uhrzeit zaehlt der
Countdown in Tagen, und "morgen" ist eine ehrliche Antwort.
Der Ton folgt der NAEHE, nicht der Wichtigkeit: Was gleich anfaengt,
ist waermer. Das ist die einzige Information, die eine Farbe hier
tragen kann, ohne zu behaupten, ein Termin sei "besser" als ein
anderer. Kein Blinken, keine Animation -- auf dieser Seite steht
niemand unter Zeitdruck, er will es nur wissen.
NEU: pruef-countdown (22 Pruefungen)
Das Abnahmekriterium aus dem Plan, in Pixeln gemessen: Die Antwort MUSS
im ersten Bildschirm stehen (gemessen 458 px von 844) und groesser sein
als jede Fliesstextzeile (27 px). Dazu: Uhrzeit setzen, wiederfinden
und wieder ENTFERNEN; vier unmoegliche Zeiten; der Zeitstrahl mit
"Vorbei" ganz unten; und der leere Fall, in dem ein SATZ dasteht statt
einer leeren Flaeche.
UND EIN EIGENER FEHLER, gefunden von der eigenen Gegenprobe: Der
Testtitel war "X" -- ein Zeichen, der Server verlangt zwei. Vier
"wird abgelehnt"-Haken waren damit halb aus dem falschen Grund gruen.
Aufgefallen ist es nur, weil die Gegenprobe ("der gueltige Fall muss
durchgehen") danebenlag. Ohne sie haette die Pruefung vier Haken
gesetzt und nichts geprueft.
pruef-treff 66, pruef-bereiche-lesend, pruef-css-klassen gruen -- die
anderen sieben Bretter teilen sich diese Datei.
Der Plan im Vault fuehrt jetzt einen Abschnitt 12: "Was beim Bauen
herauskam, das im Plan nicht stand". Plaene altern, Befunde nicht.
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
|
7b21f247eb |
Der Treff: eine eigene Tür für die Community, und sie sieht nur, was dasteht
Filipe: "eine community rolle und community kategorie, wo die community auch dann nur die sieht" · "wieso nur eine kachel — ich will mehrere, mit mehreren optionen" · "egal welche rolle hinzugefügt wird soll immer nur das sehen was ich erlaube". DIE DRITTE ADRESSE. treff.dogfather-universe.com bekommt eine eigene Weiche (treff-adresse.js), eine eigene Zugangswand, ein eigenes Manifest und acht eigene Bühnenbilder. Ohne sie stünde dort die Wand der Agentur: Spicy-Logo, "Creator Workspace", fünf Rollenkacheln mit den Namen Admin, Manager, Scout, Creator — die komplette Struktur des Unternehmens, vor der Anmeldung, für jeden mit der Adresse. Welche Wand zu welcher Tür gehört, steht jetzt in EINER Tafel (istFremdeWand) statt als Sonderfall im Code. Bei zwei Wänden war ein Sonderfall richtig; bei drei wären es drei geworden, bei vier sechs. SIEBEN BRETTER UND EIN ACHTES NUR FÜRS TEAM. Anschlagbrett, Was ansteht, Der Treff, Wunschliste, Highlights, Regeln & Hilfe, Mitmachen — dazu "Meldungen & Maßnahmen", das ausdrücklich NICHT in TREFF_BEREICHE steht: dort wäre es lautlos bei der Community gelandet und hätte ausgesehen wie die anderen sieben. WAS AUF DEN BRETTERN PASSIERT: "Will ich auch" (eine Stimme je Person, erzwungen durch den Schlüssel, nicht durch eine Prüfung) · Anheften, höchstens drei, gezählt IN der Transaktion · Freigabe vor Sichtbarkeit für Termine und Highlights, wobei Abwesenheit der Ruhezustand ist · Melden mit Pflicht-Grund (DSA Art. 16) · Entfernen mit Grund, der den Beitrag ÜBERLEBT (DSA Art. 17) · drei Stufen, gerechnet statt gespeichert · die Bannleiter: Modi bis 7 Tage, dauerhaft nur DogFather (seine Entscheidung) · "Mitmachen" wird zum Talent, genau einmal. Der Ausschluss wirkt in sitzungLesen() — also nicht nur beim Schreiben. Wer ausgeschlossen ist, ist weg, nicht stumm. ZWEI SEITEN MEHR. treff-regeln.html holt seine ZAHLEN vom Server (Mindestalter 18, Fristen, Anschläge) — ein Regeltext, der eine andere Zahl nennt als die Regel, ist schlimmer als keiner. rechte.html rechnet "Wer sieht was" aus derselben Tafel aus, aus der die Schranke ihre Entscheidung holt. Die Community steht dort bei 3 von 23. SECHS BEFUNDE, KEINEN HAT DAS LESEN GEFUNDEN: · Ein Modi kam über den verborgenen Zugang in den Treff — die Bedingung war durch Ausschluss formuliert und nahm die neue Wand automatisch mit · /api/personen gab einem Mitglied Namen und Rolle von DogFather · Ein DELETE mit Körper wird von Nodes HTTP-Parser mit einem leeren 400 abgewiesen, bevor Express ihn sieht (gemessen). Der Grund reist jetzt in der Adresse · Der Kommentar, der erklärt, warum die Zugangswand keine Rollennamen nennt, nannte selbst einen — in einer ausgelieferten Datei · Zwei Listen für "welche Seiten sind ohne Anmeldung offen". Sie stimmten, weil beide am selben Tag entstanden · Ein Portkonflikt, den ich selbst gebaut hatte (4391 gehört pruef-chat-aufloesen) Dazu zwei feste Zahlen abgeschafft (die 20 in pruef-rechtetafel, die Kachelzahl in pruef-treff) und zwei Werkzeuge, die jetzt SUCHEN statt aufzuzählen: Der Versionsstempel findet seine Manifeste selbst — das dritte hätte sonst keinen bekommen, und die neue App hätte bis zu vier Stunden lang das falsche Zeichen getragen. Das Bildwerkzeug baut beide Zugangswände aus einer Vorlage mit zwei Werten. Zwei neue Kacheltöne, gemessen statt gewählt: #2f2f7f (Abstand 31,4 in Lab) und #7c2771 (29,7). Das schwächste Paar der vorhandenen 34 liegt bei 24,9. Geprüft: treff 69 · treff-werkzeuge 60 · rollen 312 · start-ansicht 147 · crew-adresse 129 · sicht 84 · modi-verborgen 80 · haus-trennung 62 · bereiche-lesend 37 · css-klassen 30 · zwischenspeicher 21 · alle-wege 19 · rechtetafel 19 — alles grün. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
9b47bd3ca0 |
Entwicklung & Nachwuchs -- zwei Bretter fuer DogFather und die rechte Hand
Filipe: "ich will dass ich genau so eine kategorie habe in der dogfather und rechten hand rollen, wo wir aufgaben oder bewertungen ueber modis eingeben koennen. auch fuer zuschauer die vielleicht modis werden koennten waere auch geil. mach dich schlau informier dich so krass wie es nur geht, hol die besten der besten und krassesten sachen, perfektionnier die dan auch alle und dan erst setzt du alles um." === WAS DIE RECHERCHE ERGEBEN HAT === DREI BEFUNDE HABEN DAS DESIGN BESTIMMT, und der erste hat es fast umgedreht: WARUM MODERATOREN AUFHOEREN (Schoepke-Gonzalez u. a., New Media & Society 2024): zwei Hauptgruende -- zu wenig Zeit, und Konflikte im Team beziehungsweise schaedliches Verhalten der Leitung. Eine Bewertungsfunktion ist damit genau das Werkzeug, mit dem man ein Team verliert, wenn man sie als Ueberwachung baut. Das ist kein Bauchgefuehl und keine Zimperlichkeit -- es ist der haeufigste gemessene Grund. WAS HAELT: Anerkennung. Dank und Rueckmeldung erhoehen die Verweildauer messbar; Rollenklarheit senkt Burnout. WORAN MAN GUTE MODERATOREN ERKENNT (ModSquad, Kitfox Games, Discord-Leitfaeden): nicht an Zahlen. Ruhig bleiben, wenn es hitzig wird; von selbst helfen; die Regeln UND die Leute kennen; regelmaessig da sein. Ausdruecklich NICHT: "schreibt viel" -- angenehm im Chat zu sein ist nachweislich etwas anderes. Und der treffsicherste Weg ueberhaupt ist die Empfehlung aus dem Team, gefolgt von einer Probezeit. === WAS DARAUS GEBAUT WURDE === ENTWICKLUNG. Keine Note, sondern eine Aufzeichnung ueber die Zeit, je Person. Fuenf Arten, und ihre REIHENFOLGE ist Absicht: "Das laeuft gut" und "Danke dafuer" stehen vorn. Wer ein Formular oeffnet, dessen erstes Feld "Problem" heisst, schreibt Probleme auf. "ZU VIEL GERADE" IST DIE WICHTIGSTE ART und die, die es sonst nirgends gibt. Der haeufigste Grund zu gehen ist Zeitmangel, und der zeigt sich frueh -- nur schreibt ihn niemand auf, weil es kein Feld dafuer gibt. TALENTE. Die vier Merkmale sind die aus der Literatur, nicht ausgedacht, dazu die Empfehlung aus dem Team. Der Status IST die Probezeit: `offen` heisst beobachtet, `angenommen` heisst angesprochen -- und was daraus wird, entscheidet sich in "Personen & Zugaenge" mit einem Zugang auf Stufe "Probe". Eine eigene Kandidatentabelle waere ein zweiter Ort fuer dieselbe Frage. DIE BRUECKE. Die Person sieht den Entwicklungs-Bereich NICHT -- eine halb sichtbare Akte ist schlimmer als eine geschlossene, weil niemand mehr weiss, was der andere gerade liest. Damit Anerkennung trotzdem ankommt, laesst sich jeder Eintrag EINMAL als Nachricht in den Chat schicken, mit Art, Titel und dem, was daraus folgen soll. Danach steht im Eintrag, wann es geschehen ist: Die Frage "habe ich ihr das eigentlich schon gesagt?" beantwortet man nach zwei Wochen falsch. ZWEI KACHELN UND NICHT DREI: Aufgaben an das Team gibt es laengst, mit Person, Frist und Status. Eine zweite Stelle dafuer waere ein zweiter Ort, an dem man nachsehen muesste, welche Aufgabe wirklich gilt. DIE GRUPPE HEISST NICHT "TEAM FUEHREN". Das waere der bequeme Name und der falsche: Im Haus gilt, dass DogFather nicht ueber seinem Team steht. "Entwicklung & Nachwuchs" sagt, was drinsteht. === KEIN NEUER BAUKASTEN === Beides sind BEREICHE wie das Ideen-Board: dieselbe Tabelle, dieselbe Seite, dieselben Regeln fuers Anlegen, Aendern und Loeschen. Neu sind eine Spalte (`gesendet_am`) und eine Route. Die Sendefunktion selbst steht im Chat-Modul und nicht daneben: Ein Zweier-Gespraech darf es nur einmal geben, die Leseraender muessen mitwandern, Live-Strom und Benachrichtigung haengen daran -- wer das nachbaut, hat zwei Fassungen, und die zweite ist die, in der jemand eine Nachricht nicht bekommt. === WAS DIE PRUEFUNG GEFUNDEN HAT === "Zugeordneter Creator existiert nicht" -- beim Anlegen eines Eintrags ueber ein Teammitglied. Die Regel verlangte einen Creator; bei Entwicklung geht es um Menschen aus dem Team. Die Meldung war dabei selbst irrefuehrend: Die Person existiert sehr wohl, sie ist nur kein Creator. Beides behoben. Und meine EIGENE Pruefung von vor einer Stunde wurde rot: Sie verlangte, dass jede Zusatzkachel in der Gruppe "Team Dogi" steht. Die naheliegende Reparatur waere gewesen, die Gruppe gar nicht mehr zu pruefen -- das haette die Aussage weggeworfen. Jetzt steht die erlaubte Liste ausgeschrieben da: Eine Kachel fuer zwei Menschen darf nicht in einer Gruppe landen, die alle sehen. Kommt eine dritte Gruppe, wird die Zeile rot, und das ist Absicht. Die zwei neuen Farbtoene trennen ueber Saettigung und Helligkeit statt ueber den Farbwinkel -- bei 25 Toenen ist der Kreis voll, und die groessten Luecken waeren ein drittes Gruen zwischen zwei vorhandenen. Bei einer achtundzwanzigsten Kachel brauchen die Kacheln Gruppenfarben statt Einzelfarben; das steht als Notiz im Quelltext. pruef-entwicklung 33 (neu) · pruef-start-ansicht 27 Kacheln, sechs Gruppen · pruef-rollen 278 -> 282 · pruef-modi-checkliste 70 · pruef-haus-trennung 62 · pruef-rueckmeldung 30 · pruef-modi-ideen 30 · pruef-modi-verborgen 80 · pruef-css-klassen gruen · pruef-modi-wortleck 5. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
9c99a5b9c3 |
Zwei Haeuser auf einer Datenbank -- die Team-Adresse zeigt nur das Team
Filipe, mit Bildschirmfoto der Zentrale: "die daten von dieser seite
sollen nichts mit den daten am hut haben von der workspace seite bitte,
die hier soll ihre eigene daten haben und komplett von der anderen
getrennt sein. dogfather soll die daten auch auf der anderen seite
sehen in der team dogi kategorie aber auch nur er und vanvan."
GETRENNT WIRD DER AUSSCHNITT, NICHT DER BESTAND. Eine zweite Datenbank
haette den zweiten Satz unmoeglich gemacht -- er will dieselben Daten
auf beiden Adressen sehen. Es bleibt also alles an einem Ort, und die
ADRESSE entscheidet, welcher Ausschnitt davon herauskommt.
ALLES HAENGT AN EINEM WERT: `person.haus`, gesetzt in sitzungLesen()
aus dem Hostnamen. Von dort reist er mit der Person durch jede
Sichtbarkeitsregel im Haus. Der Grund ist ein praktischer: Die Regeln
bekommen ueberall dieselbe Person gereicht -- sichtbar(person),
sichtbareCreatorIds(person), bereicheFuer(person). Ein zusaetzliches
Argument haette an ueber dreissig Aufrufstellen mitgeschleift werden
muessen, und die eine vergessene waere das Loch gewesen.
RECHTE AENDERT ES NICHT. Es entscheidet, WAS jemand sieht, nicht, was
er darf -- wie die Sicht eines anderen (sichtPerson) das auch nicht tut.
DER FILTER IST DER SPIEGEL EINES VORHANDENEN. Es gab schon
`ohneTeamDogi` ("alles ausser dem Team") fuer Spicy Media. Dazu kommt
jetzt `ohneAgentur` -- gleiche Bauweise, andere Rollenmenge, GEMEINSAME
Implementierung. In der steckt die NULL-Falle (`IS NULL OR NOT IN`,
denn `NULL NOT IN (...)` ist weder wahr noch falsch), und die sieht man
einer Abschrift nicht an.
WARUM NICHT "MINDESTENS EINE SPALTE ZEIGT AUF TEAM DOGI": Das waere die
naheliegende Formulierung und sie waere falsch. Eine Aufgabe, die
DogFather fuer einen Creator anlegt, haette ueber `erstellt_von` (er
gehoert zum Haus) trotzdem gepasst und stuende auf der Team-Seite.
Andersherum stimmt es: Sobald IRGENDEINE Spalte auf Creator, Scout,
Manager oder Spicy Media zeigt, gehoert die Zeile ins andere Haus.
VIER TUEREN, EINE FORM. Aufgaben, Bereiche, Dateien und der Kalender
haben je eine eigene sichtbar()-Funktion. Alle vier bekommen dieselbe
Bedingung an derselben Stelle, in derselben Schreibweise -- damit keine
davon anders aussieht als die anderen. Beim Kalender steht sie in
termineSichtbar() in workspace.js und nicht im Kalendermodul: Sonst
haetten Termine, Wiederholungen und der ICS-Abruf sie einzeln
gebraucht, und der ICS-Abruf ist der, den man vergisst -- er laeuft
ohne Bildschirm.
ZWEI ABFRAGEN GEHEN ABSICHTLICH NICHT DURCH DIE LISTENFUNKTIONEN, und
genau die standen im Bildschirmfoto: der Ring der Zentrale ("9 IM
TEAM", obwohl das Team drei Leute hat -- gezaehlt wurde das ganze Haus)
und die Hinweiszeile darunter ("Creator-Profile sind noch leer"). Im
Quelltext der Zentrale steht sogar ausdruecklich, dass sie die einzige
solche Stelle ist; gefunden habe ich sie trotzdem erst, weil ich der
Zahl im Bild nachgegangen bin. Beide bekommen die Bedingung jetzt aus
derselben Funktion (`hausBedingung`), nicht aus einer zweiten
Rollenliste.
Die Hinweis-Bedingung sitzt am BLOCK und nicht an den vier Abfragen
darin: Wer eine fuenfte hinzufuegt, bekommt sie dadurch mit, ohne daran
zu denken.
DIE KACHELN: Auf crew. liefert der Server dieselbe Liste wie der
rechten Hand -- nicht eine dritte. Fuenfundzwanzig Kacheln, von denen
zwei Drittel Creator und Agentur betreffen, waeren dort Fenster in ein
Haus, in dem er gerade nicht ist, und hinter jedem stuende seit heute
eine leere Liste. Auf workspace. bleibt alles, wie es war: Dort schickt
der Server weiterhin `bereiche: null` ("nimm die Liste aus der Datei").
JEDE MESSUNG STEHT ZWEIMAL DA. Die Trennung kann auf zwei Arten falsch
sein: Sie greift nicht (dann steht die Agentur weiter auf der
Team-Seite, und niemand merkt es, weil alles funktioniert), oder sie
greift zu weit (dann verschwindet auf der Agenturseite etwas -- der
gefaehrlichere Fall, denn eine zu kurze Liste sieht aus wie "nichts zu
tun"). Deshalb folgt auf jede Messung auf crew. dieselbe Messung auf
workspace., mit DERSELBEN Sitzung; der einzige Unterschied ist der
Host-Kopf. Dazu zwei Gegenproben zur Regel selbst: 127.0.0.1 bleibt
unberuehrt (sonst waeren alle Pruefungen im Haus stillschweigend blind
geworden), und eine erfundene Adresse oeffnet kein drittes Haus.
NEBENBEI ZWEI EIGENE FEHLER BEHOBEN: pruef-chat-kanaele und
pruef-rueckmeldung liefen auf Ports, die schon vergeben waren (4359
neben pruef-modi-verborgen, 4371 neben pruef-crew-adresse). Beide sind
umgezogen. Fuenf weitere Doppelungen zwischen fremden Pruefdateien
(4186, 4188, 4189, 4193, 4198) bleiben stehen und sind gemeldet -- an
Dateien zu greifen, an denen gerade eine zweite Sitzung arbeitet, waere
genau der Fehler, den diese Doppelungen ohnehin schon zeigen.
pruef-haus-trennung 32 (neu) · pruef-rollen 277 · pruef-modi-verborgen
78 · pruef-chat gruen · pruef-rueckmeldung 30 · pruef-modi-ideen 30 ·
pruef-crew-adresse 129 · pruef-start-ansicht gruen ·
pruef-zwischenspeicher 21 · pruef-modi-wortleck 5.
BERICHTIGUNG zum vorigen Commit: Dort steht "pruef-rueckmeldung 34".
Es sind 30. Ich hatte die Zeilen geschaetzt statt sie zu lesen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
be121a483e |
Rueckmeldung in beide Richtungen (Kapitel 5 und 6)
Filipe: "Nicht nur ich soll meine Modis bewerten oder ihnen Feedback geben koennen. Auch die Modis sollen mir Feedback geben koennen. Sie sollen mir beispielsweise sagen koennen: Was koennte ich verbessern?" Und der Schlusssatz seines Pflichtenhefts: "Es soll nicht nur dazu dienen, Leistungen zu kontrollieren. Es soll vor allem dabei helfen, als Team besser zu werden." EIN BRETT FUER BEIDE KAPITEL, NICHT ZWEI. Kapitel 5 (gegenseitiges Feedback) und Kapitel 6 (gemeinsame Reflexion) stellen dieselben Fragen -- "was laeuft gut, was laeuft schlecht, was fehlt" --, einmal an eine Person und einmal an das Team. Zwei Bretter haetten bedeutet, dass man beim Schreiben zuerst entscheiden muss, an WEN es geht, bevor man weiss, WAS man sagen will. Hier ist es umgekehrt: erst die Sache, dann die Richtung. DIE NEUN FRAGEN SIND SEINE, wortwoertlich aus dem Pflichtenheft zusammengezogen: laeuft gut · laeuft nicht gut · unbedingt behalten · an DogFather · was dem Team fehlt · Regel aendern · besser organisieren · Idee · Wunsch fuer spaeter. Sie stehen als feste Faecher da und nicht als freies Feld -- genau das ist der Unterschied zwischen einer Sammlung und einem Haufen: Neun Faecher kann man auswerten, tausend Formulierungen nicht. KEIN NEUER BAUKASTEN. Die Rueckmeldung ist ein BEREICH wie das Ideen-Board: dieselbe Tabelle, dieselbe Seite, dieselben Regeln fuers Anlegen, Aendern und Loeschen, dieselbe Zugangssperre. Ein eigenes Modul haette all das ein zweites Mal gebraucht -- und die zweite Fassung waere die gewesen, in der eine Regel fehlt. DIE EINE NEUE SACHE IST DIE RICHTUNG. Beim Schreiben waehlt man zwischen "fuers Team" (Vorgabe) und "nur an DogFather". Ohne diese Wahl haette man eines von beidem verloren: Wer "was koenntest du besser machen" vor versammelter Mannschaft sagen muss, sagt es nicht -- wer alles nur unter vier Augen sagen kann, hat kein Team-Gespraech. UND "NUR DOGFATHER" HEISST NUR DOGFATHER -- die rechte Hand ausdruecklich nicht. Sie sieht sonst ueberall dasselbe wie er; hier nicht, weil das Etikett sonst nicht stimmen wuerde. Eine Zusage mit einer Ausnahme im Kleingedruckten ist keine. Sie schreibt selbst genauso -- auch ueber ihn. DIE ZUSAGE STEHT IN sichtbarEintrag(), also in derselben Funktion, durch die auch das Lesen einer einzelnen Zeile, das Aendern und das Loeschen gehen. Eine Regel, die nur die Liste filtert, laesst die Zeile ueber ihre Nummer trotzdem heraus; die Pruefung klopft deshalb auch von hinten (PATCH und DELETE auf die vertrauliche Zeile: 404, auf die offene: 200). `COALESCE(nur_leitung, 0)`: Jede Zeile, die es vor heute gab, hat dort NULL, und in SQL ist `NULL = 0` nicht falsch, sondern UNBEKANNT. Ohne den Ersatzwert waere der gesamte alte Bestand von einer Minute auf die andere unsichtbar gewesen -- und niemand haette es gemeldet, denn ein leeres Brett sieht nicht nach Fehler aus. Beide Richtungen sind gemessen. KEINE ANONYMITAET, und das ist eine Entscheidung, keine Luecke. In einem Team dieser Groesse waere sie ohnehin keine: An drei Saetzen erkennt jeder jeden. Ein Versprechen, das nicht haelt, ist schlimmer als keines. DER FARBTON DER KACHEL IST AUSGERECHNET, NICHT AUSGESUCHT. Bei 24 vorhandenen Toenen landet ein neuer fast zwangslaeufig neben einem alten, und zwei Kacheln in FAST derselben Farbe sind schlimmer als in derselben -- bei gleicher merkt man den Fehler, bei fast gleicher sucht man ihn. Alle 24 wurden in Farbwinkel umgerechnet; die groesste Luecke liegt zwischen 90 und 160 Grad und ist 70 Grad breit, mehr als doppelt so viel wie die naechste. Der neue Ton sitzt in ihrer Mitte, 8,9 zu 1 auf dunklem Grund. pruef-rueckmeldung 34 (neu) · pruef-rollen 274 -> 277 · pruef-start-ansicht zaehlt jetzt 25 Kacheln und 25 Farben (sie zaehlt selbst, statt eine Zahl festzuhalten -- deshalb blieb sie gruen) · pruef-modi-ideen 30 · pruef-modi-verborgen 78 · pruef-css-klassen gruen · pruef-modi-wortleck 5. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
63b3ace3fa |
Die rechte Hand -- drei Rollen auf der Adresse des Teams
Filipe: "3 rollen. dogfather. rechte hand und modis. perfektionier das." DIE RECHTE MUSSTE ICH NICHT ERFINDEN. Sie stehen im Blueprint V3.0, Kapitel 3.1 und in der Sichtbarkeitsmatrix 3.2: "Gleicher Ueberblick wie Owner. Kann Modis im Alltag koordinieren. Verwaltungsrechte optional durch Owner freischaltbar." Also: alle Aufgaben, Ideen und Angebote des Teams, der Eingang samt Entscheidungen, die Checklisten der Modis zum Ansehen -- aber keine Personenverwaltung (laut Blueprint "optional", also standardmaessig aus) und keine privaten Kalender oder Einzelchats. DER EIGENTLICHE UMBAU WAR NICHT DIE ROLLE, SONDERN EINE MENGE. Bis heute hiess "verborgen" im Code `rolle === "modi"` -- an acht Stellen. Bei ZWEI verborgenen Rollen ist das genau die Sorte Stelle, die man an sieben von acht Orten nachzieht; die achte faellt niemandem auf, weil dort dann einfach jemand sichtbar ist, der es nicht sein sollte. Ein vergessener Rechteschutz meldet sich nie. Jetzt lesen alle Regeln aus TEAM_DOGI_ROLLEN: die SQL-Ausblendung (ohneModi heisst deshalb jetzt ohneTeamDogi), die verborgenen Nummern, die Marke, die Adressregel, die Schranke beim Anlegen. Eine dritte verborgene Rolle waere eine Zeile. Die Menge wohnt in crew-adresse.js und nicht bei den uebrigen Rollen: workspace.js importiert jene Datei. Andersherum waere es ein Kreis -- Node loest ihn auf, aber mit halb gefuellten Modulen, und das faellt erst zur Laufzeit auf. ZWEI LOECHER, GEFUNDEN BEIM SYSTEMATISCHEN NACHLESEN 1. Die Bereichsschranke griff nur bei Modis -- die rechte Hand waere ueber die Adresszeile in die Agentur-Ablage gekommen. 2. Ihr Ideen-Board und ihr Angebote-Brett waeren LEER geblieben: Sie fiel durch den Team-Zweig hindurch in die Betreuungsregel, die fuer sie nichts findet. Derselbe Fehler wie am 01.09. beim Manager und am 09.09. beim Modi -- und er meldet sich nie, weil ein leeres Brett nicht nach Fehler aussieht. NEBENBEI EINE ALTE SCHWACHSTELLE WEG gate.js hatte eine zweite Namensliste fuer die Rollen, mit dem Kommentar daneben, sie sei "genau die Stelle, die beim naechsten Mal wieder vergessen wird" -- was schon passiert war. Mit zwei Zugangswaenden haette sie die Namen BEIDER tragen muessen, in einer Datei, die jeder bekommt. Sie liest den Namen jetzt aus der Kachel, wo er ohnehin steht. Die Zugangswand hat drei Kacheln: DogFather (Husky), Rechte Hand (Pfote, neu) und Modi (derselbe Husky, Wunsch vom 09.09.). Die Pfote liegt am naechsten an "rechte Hand", ohne eine Hand zu sein. GEMESSEN pruef-rollen 274 (statt 245; 128 statt 112 Durchgaenge) pruef-crew-adresse 114 pruef-modi-verborgen 78 (statt 75) pruef-modi-checkliste 59 pruef-crew-wand-bild 45 pruef-modi-ideen 30 pruef-personen-formular 27 (statt 25) pruef-modi-katalog 29 pruef-modi-kategorien 25 pruef-zwischenspeicher 21 pruef-modi-livecheck 16 pruef-modi-wortleck 5 pruef-start-ansicht, pruef-bereiche-lesend Jede gestiegene Zahl hat einen Grund: Die neue Rolle laeuft in DENSELBEN Listen mit wie die Modis, nicht in eigenen. pruef-modi-verborgen war vorher gruen, ohne sie ein einziges Mal angesehen zu haben. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
8bcbd83061 |
Die Modi-Seite gehoert Dogi und den Modis -- Wand, Zeichen, Reiter
Filipe zum Bildschirmfoto der Zugangswand auf crew.: "alles soll auf dogfather und die modis perfektionniert werden auf der neuen modi seite." Dort stand bis eben die gewohnte Wand: Spicy-Media-Logo, "Creator Workspace", der Satz ueber Manager, Scouts und Creator, fuenf Rollenkacheln. Fuer einen Modi war davon nichts richtig. DIE KACHELREIHE FAELLT WEG, und das ist eine Verbesserung: Eine Reihe mit genau einem Eintrag ist keine Auswahl, sondern eine Huerde -- man muesste erst daraufdruecken, bevor das Codefeld etwas annimmt. gate.js prueft jetzt, OB es Kacheln gibt, statt sie vorauszusetzen. DIE BUEHNE IST AUS DEM VORHANDENEN MOTIV GEBAUT, nicht neu erfunden, und das ist kein Sparen: Die Anmeldeseite ist eine MECHANIK. Rechts steht im Bild eine leere Tafel, und gate.css setzt die Karte auf Hundertstel genau dort hinein. Ein frei erfundenes Bild haette diese vier Zahlen mitgenommen. Also dieselbe Szene, ueber den Mischmodus "color" ins Blau umgefaerbt (hue-rotate haette Rot nach Cyan UND Blau nach Gelb gedreht), Dogi anstelle des Spicy-Medaillons, "TEAM DOGI" darunter. Gemessen: rote Bildpunkte 18,1 % -> 0,0 %, Karte auf 0 px genau. NACH DER ANMELDUNG geht es weiter: kopf.js zieht Reitertitel und Zeichen aus `ich.marke` nach -- "Aufgaben · Team Dogi" statt "· Spicy & Dogi", mit dem eigenen Symbol. An einer Stelle statt in 30 HTML-Dateien. DREI FUNDE, DIE NICHT AUS DEM KOPF KAMEN 1. DER KNOPF WAERE SCHLECHTER LESBAR GEWORDEN. Mein erstes Blau endete bei #4aa4cf -- weisse Schrift darauf: 2,8 zu 1. Der rot-blaue Verlauf, den er ersetzt, haelt ueber seine GANZE Laenge 4,65; er war offenbar genau darauf gebaut. Jetzt 5,10 zu 1, am fertigen Bildschirmfoto gemessen statt aus einer einzelnen Farbe hergeleitet. 2. DIE NEUE WAND WAR AUCH AUF workspace. ABRUFBAR. Sie liegt als Datei im selben Ordner. Aufgefallen ist das, weil der Wortleck-Test sie ueberhaupt las -- die Frage WARUM war die Antwort. Ausserhalb von crew. antwortet sie jetzt mit 404; auf den Pruefadressen bleibt sie erreichbar, sonst koennte die Pruefung sie nicht mehr oeffnen und waere gruen ohne etwas zu messen. 3. ZWEI GLEICHE KACHELN AUF DER STARTSEITE, seit dem letzten Deploy live. Die Team-Lage-Kachel von heute Mittag hatte Name, Zeichen, Ton UND Gruppe einer schon vorhandenen -- fuehrte aber woandershin. Gefunden von "jede Kachel hat ihre eigene Farbe (23 Farben auf 24 Kacheln)". Jetzt "Eingang", Gruppe Taeglich, neuer Ton 24 (#8a20cf, Abstand 38,5 im CIELAB-Raum; reines Blau haette 52 gehabt und waere auf dunklem Grund am schlechtesten zu fokussieren). Eine Fehlermeldung zeigte dadurch auf die falsche Seite -- ebenfalls behoben. Und die Pruefung, die es fand, zaehlte nur bereiche.js: Vom Server angehaengte Kacheln kannte sie nicht. Sie fragt jetzt beide Quellen. Der Wortleck-Test meldete ausserdem sieben Fundstellen -- allesamt Kommentare, die ich beim Bauen selbst geschrieben hatte. GEMESSEN pruef-crew-adresse 103 pruef-crew-wand-bild 43 (neu) pruef-modi-checkliste 59 pruef-modi-verborgen 75 pruef-rollen 245 pruef-zwischenspeicher 21 pruef-modi-wortleck 4 pruef-start-ansicht gruen Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
05f262eb61 |
Modis verteilen Aufgaben statt sie zu bekommen -- und Angebote zur Entscheidung
Die drei Beurteilungs-Bereiche liefen bisher in die falsche Richtung: Sie
bewerteten die Modis. Filipe: "die modis sind ja da um mir zu helfen."
Also umgedreht.
WAS SICH GEDREHT HAT
- Alle 101 Punkte sind jetzt Beobachtungen ueber den Stream, nicht
Pflichten des Modis ("Der Ton blieb verstaendlich" statt "Ton geprueft").
- Nur der Modi selbst drueckt auf seiner Liste. Wer sonst darauf zeigt,
bekommt 403 und den Weg zur Team-Lage -- bewerten wird hier niemand.
- "Verbessern" landet als Eingang bei DogFather. Ein Klick macht daraus
eine Aufgabe mit dem Satz des Modis im Text, oder eine Absage mit Grund.
Beides schreibt eine Nachricht zurueck, damit der Modi sieht: angekommen.
ANGEBOTE
Neuer Bereich, in dem Modis planen und vorschlagen: Nutzen und Aufwand
statt Bewertung und Dringlichkeit, dazu ein Feld "was DogFather danach
tun muss". Wird ein Angebot angenommen, entstehen zwei Aufgaben -- eine
beim Modi zum Umsetzen, eine bei DogFather aus genau diesem Feld.
GEMESSEN
pruef-modi-checkliste 59 Pruefungen, 0 Fehler (neu geschrieben)
pruef-rollen 245 statt 244 -- der Zuwachs ist die neue
Angebote-Kachel, alle 11 Modi-Kacheln kommen an
pruef-modi-ideen 30, pruef-modi-verborgen 75, pruef-bereiche-lesend: gruen
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e1608ee783 |
Das Ideen-Board -- und fuenf Kacheln, die ins Leere fuehrten
KAPITEL 5.6: "Sammelstelle fuer Content-, Live- und Community-Ideen mit
Priorisierung." Fast nichts davon musste neu gebaut werden: `eintraege`
hat Titel, Text, Status und `dringlichkeit` (hoch/mittel/niedrig) -- und
das IST die Priorisierung. Eine eigene Tabelle daneben waere eine VIERTE
Sichtbarkeitsregel gewesen; genau deren Vervielfaeltigung hat heute
schon ein Leck verursacht.
Der Bereich gehoert niemandem einzeln (`ohneCreatorBezug`) -- eine Idee
gehoert der Runde. KEIN `fuerAlle`: Das waere der naheliegende Griff
gewesen und der falsche, denn es heisst woertlich JEDER. Wer die
Sammlung sieht, entscheidet dieselbe Regel wie ueberall.
DER RISKANTE TEIL WAR DIE DATENBANK. Die erlaubten Bereiche stehen als
CHECK-Regel, und SQLite kann die nicht aendern -- die Tabelle muss neu
gebaut werden. Die alte Umstellung fuer 'agentur' schreibt dafuer den
ganzen Bauplan von Hand ab; im Kommentar dort steht, dass dabei schon
einmal drei Spalten vergessen wurden. Statt einer vierten Abschrift ist
die Fassung von heute Morgen jetzt tabellenunabhaengig
(checkListeErweitern): Spaltenliste aus der Tabelle, Sicherung vorher,
Zaehlung innerhalb der Transaktion.
UND DABEI WAERE EIN STILLER TOTALAUSFALL PASSIERT. Das Muster fuer den
Tabellenkopf stand in einem Template-Literal -- dort verschluckt
JavaScript den Backslash, aus `\s` wird `s`, das Muster hiess
"CREATE TABLEs+..." und traf nie etwas. Die Umstellung haette
SCHWEIGEND nichts getan: kein Fehler, kein Hinweis, nur ein Bereich, den
es nie gegeben haette. Im Quelltext war das nicht zu sehen; gefunden hat
es eine Messung. Jetzt steht dort gar kein Muster mehr -- alles vor der
ersten Klammer IST der Tabellenkopf, und das kann man nicht falsch
maskieren.
Die Pruefung baut deshalb eine ECHTE ALTE Tabelle und laesst die
Umstellung darauf laufen. Eine frische Datenbank bringt den Bereich
schon mit -- die Umstellung liefe gar nicht erst an, und alles waere
gruen, ohne das Riskante angesehen zu haben.
=== DER GROESSERE FUND ===
FUENF VON ZEHN MODI-KACHELN FUEHRTEN INS LEERE. Der Server hat eine
Liste, welche Rolle welche Seite oeffnen darf; bereich.html und
profil.html schlossen 'modi' aus. Vier Bereichs-Kacheln und das eigene
Profil leiteten wortlos auf die Startseite zurueck.
Der Rollen-Rundgang meldete sie trotzdem als "ok", und zu Recht: Eine
Umleitung ist kein Fehler. Die Seite laedt, keine rote Konsole, keine
4xx-Antwort. Sie ist nur eine ANDERE. Das ist eine eigene Fehlerklasse
-- nicht "kaputt", sondern "fuehrt woandershin" -- und sie faellt nur
dem auf, der die Anwendung benutzt und merkt, dass ein Knopf nichts tut.
Beinahe waere meine eigene Pruefung darauf hereingefallen: Sie fand auf
der zurueckgeleiteten Startseite das Wort "Ideen-Board" -- den Text der
KACHEL -- und hielt sie fuer das Board. Jetzt steht die Adresse in der
Bedingung.
DIE SPERRE DAGEGEN GILT AB SOFORT FUER ALLE: pruef-rollen klickt fuer
JEDE Rolle jede Kachel durch, die sie angeboten bekommt, und verlangt,
dass sie dort ankommt. Geprueft wird die Zusage der Startseite, nicht
eine Liste daneben -- eine Liste koennte selbst veralten. 113 -> 243
Pruefungen; der Zuwachs ist genau das.
Er hat im ersten Anlauf zwei weitere Loecher gefunden:
* "Mein Profil" war die falsche Seite. profil.html ist der
Creator-Entwicklungsplan und antwortet mit 404, wenn die Person kein
Creator ist. Die eigene Seite heisst steckbrief.html.
* content.html stand auf `null` ("jede angemeldete Rolle") -- mit der
neuen Rolle also auch sie. Die Seite laedt, ihre Schnittstelle gibt
404. Das ist die Kehrseite von "geschuetzt ist die Regel, nicht die
Ausnahme": Eine NEUE ROLLE erbt jedes `null` automatisch.
Und ein Modi kommt nur in SEINE Bereiche -- sonst waere er ueber die
Adresszeile in der Agentur-Ablage gelandet. Welche erlaubt sind, wird
aus seinen Kacheln abgeleitet statt danebengeschrieben.
=== KLEINERES, ABER SICHTBARES ===
Ueber dem Board stand "Betreuung" -- die Beschriftung fuer Akten, die
UEBER jemanden gefuehrt werden. Eine Sammelstelle ist das Gegenteil.
Aufgefallen auf dem Bildschirmfoto, wie so oft heute.
Der Farbton der Kachel ist nicht nach Gefuehl gewaehlt: Alle 22
vorhandenen waren belegt, also wurde der Abstand zu jedem ausgerechnet
und der genommen, der sich am deutlichsten unterscheidet, ohne grau zu
wirken (#5f8a9f, Abstand 127).
BEINAHE HAETTE ICH EIN LOCH REPARIERT, DAS ES NICHT GIBT: Meine Pruefung
meldete, die Suche verrate die Ideen an Spicy Media. Tatsaechlich fand
sie null Treffer -- die Pruefung hatte ihren EIGENEN Suchbegriff
wiedergefunden, weil die Antwort ihn im Feld `frage` zurueckspiegelt.
Gezaehlt wird jetzt, was gefunden wurde.
pruef-spicy erwartete den alten Wortlaut der Umstellungsmeldung. Sie
nennt jetzt Tabelle und Spalte statt "Rolle"; geprueft wird der Sinn,
nicht der Satz.
GEPRUEFT: pruef-modi-ideen (30, neu), pruef-rollen (243 statt 113),
pruef-modi-verborgen (75), pruef-modi-katalog (29), pruef-spicy (60),
pruef-css-klassen, pruef-start-ansicht.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
138bcce80b |
Spicy Media sah die Zeilen der Modis -- drei Tabellen, ein Loch
GEMESSEN, NICHT VERMUTET, und es war live: Aufgaben, Bereichs-Eintraege
und Dateien eines Modis waren fuer Spicy Media sichtbar. Die NAMEN der
Modis waren ueberall sauber verborgen -- ihre ZEILEN nicht. Eine halbe
Verborgenheit ist keine.
WARUM ES PASSIEREN KONNTE: Fuer Personen gibt es die Regel EINMAL
zentral (verborgeneIds). Fuer Zeilen gibt es sie DREIMAL -- in
workspace-aufgaben.js, workspace-bereiche.js und workspace-dateien.js --
und alle drei geben Spicy Media dasselbe: "alles ausser dem, was
DogFather gehoert" (ohneDogFather). Ein Modi-Eintrag gehoert ihm nicht,
also fiel er durch.
Manager, Scout und Creator waren nie betroffen, ihre Regeln sind enger.
Der Kalender auch nicht: termineSichtbar() gibt jedem nur Eigenes.
Beides nachgesehen, nicht angenommen.
GEFUNDEN HAT ES KEINE UEBERLEGUNG, sondern eine Pruefung, die etwas
ANLEGT und danach mit fremden Augen nachsieht. Vorher hatte ich nur
Namenslisten geprueft -- und die waren die ganze Zeit gruen. Der Anlass
war nicht einmal Misstrauen gegen diese Stelle: Ich wollte ein
Ideen-Board auf die Eintraege setzen und dabei wissen, wer sie sieht.
BEHOBEN mit ohneModi() als Gegenstueck zu ohneDogFather -- und zwar als
UMHUELLUNG um die drei Regeln, nicht als Flicken darin. Ein Flicken
haette den einen bekannten Zweig geschlossen und den naechsten
Rollenzweig wieder offen gelassen; gemerkt haette es niemand, weil an
der geaenderten Stelle nichts davon steht.
Dazu die `fuerAlle`-Ausnahme bei den Eintraegen: Sie haengt ein ODER an
und haette die Bedingung sonst wieder aufgemacht. Heute hat kein Modi
eine Kachel in einen solchen Bereich -- ein Aufruf an der Oberflaeche
vorbei braucht sie aber nicht. Eine Regel, die nur im Formular gilt,
ist keine Regel.
Nachgesehen, dass die Umhuellung nirgends das falsche Tabellenkuerzel
setzt: Alle Aufrufstellen in workspace-hinweise.js und workspace-suche.js
fuehren die Tabellen als a, d und e -- genau so, wie es dasteht.
NEBENBEI: Das Modi-Team teilt sich jetzt auch die Bereichs-Eintraege,
nicht nur die Aufgaben (Entscheidung Filipe, 09.09.2026: "sie sind
untereinander ein Team"). Ohne diesen Zweig saehe jeder Modi nur, was er
selbst geschrieben hat -- eine gemeinsame Sammlung waere keine.
ZWEI EIGENE FEHLER AUF DEM WEG DAHIN, beide festgehalten:
* Die neue Messung stand HINTER der Gegenprobe. Die macht eine Person
absichtlich zur Creatorin -- die Messung bekam 403 und meldete
"kann nichts anlegen". Gemessen wurde ein Zustand, den es im
Betrieb nicht gibt. Genau davor warnt der Kommentar, den ich selbst
zwei Tage vorher an diese Gegenprobe geschrieben hatte.
* Das "konnte nicht nachsehen" nannte KEINEN Grund. Damit ist der
dritte Ausgang nur dem Namen nach da -- man weiss danach so wenig
wie vorher. Erst mit der Fehlermeldung im Text kam ich auf die Spur.
GEPRUEFT: pruef-modi-verborgen (75, davon 18 neu ueber drei Tabellen und
fuenf Rollen), pruef-spicy (60), pruef-bereiche-lesend,
pruef-aufgabenbrett, pruef-modi-katalog (29).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e8478c9cae |
Spicy sieht DogFathers Sachen nicht mehr -- und sechs Fehler dazu
VIER DINGE AUS DEN BILDSCHIRMFOTOS, jedes ein echter Fehler:
1. SPICY MEDIA SAH DOGFATHERS DATEN. Beim ersten Anlauf bekam die Rolle
dieselbe Regel wie DogFather (`1=1`) -- damit stimmte der Ueberblick
ueber Manager, Scouts und Creator, und nebenbei standen seine eigenen
Termine, Aufgaben, Dateien und Eintraege mit drin. Jetzt gibt es
ohneDogFather() als EINE Stelle dafuer: Zwei Spalten werden geprueft,
`creator_id` (um wen geht es) und `erstellt_von` (wer hat es
geschrieben) -- ein Termin, den er sich selbst anlegt, haengt nur an
der zweiten. `IS NULL OR NOT IN` und nicht bloss `NOT IN`: In SQL ist
`NULL NOT IN (...)` weder wahr noch falsch, die Zeile fiele
stillschweigend heraus.
2. "PERSOENLICHER ZUGANGSCODE · undefined" auf der Anmeldeseite. Eine
zweite Namensliste im Browser, die beim Hinzufuegen der Rolle
niemand gepflegt hat. Ein unbekannter Schluessel faellt jetzt auf
sich selbst zurueck statt auf `undefined` -- haesslich, aber
sichtbar.
3. SPICY KAM NICHT IN DIE PERSONENVERWALTUNG. Der Server liess sie
herein, das Skript warf sie wieder hinaus: zwei Listen fuer dieselbe
Frage, gepflegt wurde nur die erste.
4. DIE ANMELDEKARTE WAR ZU KLEIN FUER FUENF ROLLEN. Der Kommentar an
genau dieser Stelle warnt woertlich davor -- und ich habe getan,
wovor er warnt: eine Rolle eingefuegt und die Zahl daneben nicht
angefasst. Gemessen: Inhalt 573 px in einer 526 px hohen Tafel, die
Fusszeile stand unter dem Rahmen. Schrift kleiner half nicht (sie lag
schon auf dem Anschlag), also sind die Abstaende an neun Stellen
enger. Nachgemessen auf fuenf Groessen: passt ueberall.
DIE ZEIT WAR WIRKLICH FALSCH. Nicht nur in meinem Satz: `datum()` in
personen.js schnitt die ISO-Zeichenkette ab -- und die ist UTC. Im
Protokoll stand 03:00, wo 05:00 war. Das Tueckische daran ist, dass es
nie kaputt aussieht: Eine Uhrzeit ist immer plausibel.
PROFILBILDER WERDEN JETZT GEZEICHNET. Der Server lieferte sie seit
gestern mit, gezeichnet wurden sie nirgends -- deshalb aenderte sich
nichts. Jetzt in der Personenauswahl (Aufgaben, Termine, Dateien,
Bereiche), in der Gespraechsliste und an jeder Nachricht. Der
Anfangsbuchstabe bleibt als Unterlage LIEGEN: Faellt das Bild aus, steht
dort weiter etwas Sinnvolles.
DER CHAT: Gesichter mit Rollenfarbe, Blasen mit Richtung (die erste
einer Folge eckig, die naechsten rund -- so sieht man, wo ein Gedanke
anfaengt), das offene Gespraech mit Schiene, Ungelesenes hervorgehoben,
und das Eingabefeld in einer eigenen Leiste, die sich beim Schreiben
hebt.
ZWEI EIGENE PATZER, beide von Pruefungen gefunden:
- `o is not defined`: Mein Suchmuster hat die zwei Zeilen fuer das
Bild ans DATEIENDE gesetzt statt in die Schleife -- und in
kalender.js an einen <span> statt ans <option>. Gemeldet von
pruef-sicht, das die Browserkonsole mitliest.
- Ein Kommentar mit `bild` in schraegen Anfuehrungszeichen stand INNEN
in einer Vorlagenzeichenkette und hat sie geschlossen. Die halbe SQL
wurde zu Programmtext.
Dazu: `.chat-neu` gibt es nicht (heisst `.chat__eingabe`), und der
Rollenknopf hatte fuer den Manager keinen sichtbaren Fokus -- ein
box-shadow wird von `overflow: hidden` abgeschnitten, ein outline nicht.
Gruen: spicy (43), creator-anlegen (29), personen-liste (33), sicht (48),
chat (48), chat-optik (24), buehne (38), struktur (32), css-klassen (15),
handy (59), breiten (23), formulare (19), start-ansicht (136),
lesbarkeit (14), barrierefrei (18), tempo (8), kopf-messen (3),
glocke (26), haerte (20), manager-sicht (43), alle-wege (19),
aufgabenbrett (44), kalender (84).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
68bc116c36 |
Die Rolle "Spicy Media" -- und drei Fehler, die nur ihre Pruefung fand
DIE PERSONENTABELLE WURDE NEU GEBAUT. Eine Rolle ist ein erlaubter Wert in einer Spalte, und der steckt in einem CHECK -- den kann SQLite nicht aendern. Auf `personen` zeigen ZWEIUNDFUENFZIG Fremdschluessel. Deshalb wird der Bauplan NICHT abgeschrieben, sondern gelesen: Der CREATE-Text kommt aus sqlite_master, darin wird ausschliesslich die Rollenliste ersetzt, und die Kopierliste kommt aus PRAGMA table_info. Die beiden aelteren Umstellungen schreiben ihre Spalten von Hand ab -- `personen` hat seit damals SIEBEN dazubekommen (bild, ueber_mich, tiktok ...). Wer hier abschreibt, verliert alle Profilbilder. ZWEI FRAGEN, DIE MAN AUSEINANDERHALTEN MUSS: siehtAlles() = DogFather ODER Spicy Media -> Listen, Uebersichten istDogFather() = nur DogFather -> loeschen, Rollen, Codes Es waere weniger Arbeit gewesen, istDogFather() um "spicy" zu erweitern -- und genau das waere der Fehler: Spicy Media koennte dann DogFather loeschen. DER CHAT BRAUCHTE NICHTS. Er haengt allein an der Teilnehmerliste und kennt kein "das Management sieht alles". Spicy Media sieht fremde Gespraeche nicht, weil es dafuer keinen Weg gibt -- nicht, weil eine Abfrage es verbietet. DREI ECHTE FEHLER, alle von pruef-spicy gefunden, keiner vorher sichtbar: 1. MEIN EIGENER KOMMENTAR STAND IM BAUPLAN. SQLite hebt den CREATE-Text woertlich auf, samt Kommentaren. Ich hatte "'spicy' steht HIER mit drin" hineingeschrieben -- und die Erkennung suchte genau dieses Wort im ganzen Text. Ergebnis: Die Umstellung hielt die Tabelle fuer erledigt, obwohl die CHECK-Regel noch die alte war. Jetzt wird die Regel herausgeschnitten und NUR darin gesucht; der Kommentar steht ausserhalb des SQL. 2. DER SICHERUNGSNAME HATTE NUR MINUTEN. `VACUUM INTO` weigert sich, eine vorhandene Datei zu ueberschreiben -- zu Recht. Zwei Umstellungen in derselben Minute wollten in dieselbe Datei, die zweite scheiterte, und weil ohne Sicherung nicht umgestellt wird, blieb sie aus. Es sah nach "lief" aus (die Datei lag ja da) und war keine. Jetzt mit Sekunden. 3. EINE FRISCHE DATENBANK LEGTE DIE ALTE ROLLENLISTE AN und stellte beim allerersten Start sofort um -- Tabelle neu bauen, Sicherung schreiben, fuer nichts. Ein Bauplan, der sofort umgebaut werden muss, ist der falsche. Und ein vierter in der Pruefung selbst: Der Chat-Aufbau benutzte einen falschen Weg, das Gespraech entstand gar nicht -- "Spicy Media sieht 0 Gespraeche" war trotzdem gruen, weil es keine gab. Jetzt ist das Anlegen selbst eine Pruefung, und eine Gegenprobe zeigt, dass Max es sehr wohl sieht. DAZU: Manager sehen die Kachel "Personen & Zugaenge" -- die SEITE geht auf, die Schnittstellen nicht. Alles unter /verwaltung haengt weiter an `nurAdmin` und antwortet 404; sie sehen genau den Teil, fuer den es einen Weg gibt. Spicy Media legt Creator UND Manager an (zweite enge Tuer, Rolle steht auch dort nicht im Aufruf; ein Manager kommt durch sie nicht). Der Rollentext des Managers stimmte nicht mehr -- er legt jetzt Creator an. pruef-spicy: 36 Pruefungen, alle gruen. Ausserdem gruen: personen-liste (33), creator-anlegen (29), sicht (48), css-klassen (15), alle-wege (19), haerte (20), manager-sicht (43). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
947c9d8a26 |
Agentur: Eintraege gehoeren allen -- und Events bekommen ein eigenes Formular
Gemessen am 07.09.2026, bevor irgendetwas geaendert wurde: Von drei Agentur-Eintraegen sah eine Creatorin genau EINEN -- den, der ihr zugeordnet war. Ein Event fuer alle traf weder `creator_id = ich` noch `erstellt_von = ich`; die Agentur-Seite war fuer jeden Creator leer. Nicht kaputt, nicht fehlerhaft: leer, so wie eine Seite aussieht, auf der noch nichts steht. Die Pruefung dazu war gruen. Sie legte ihre Testeintraege mit `creator_id: idLuna` an und pruefte damit einen Fall, den es im Alltag nicht gibt. - Bereichseinstellung `fuerAlle` + `ohneCreatorBezug`, daraus abgeleitet sichtbarEintrag(). BEWUSST neben sichtbar() statt darin: an derselben Funktion haengen Aufgaben, Dateien, Termine und Calls -- wer dort "1=1" einschleust, gibt nebenbei fremde Akten frei. Eine Gegenprobe mit einer zweiten Creatorin haelt das fest. - Die Zuordnung bietet nur noch "Agentur" an. Der Server verwirft eine Zuordnung ausserdem selbst -- inklusive des frei getippten Namens, und zwar NACH externPruefen: davor haette der Name den Riegel wieder aufgemacht. - "Event & Kampagne" heisst jetzt "Agentur-Events" und hat ein eigenes Formular: Von/Bis, Titel, Beschreibung, Aufgaben (Punkte und Preise), Regeln. Die Karte zeigt den Zustand als WORT (laeuft bis / startet / vorbei seit), nicht nur als Farbe. - Drei neue Spalten -- und sie stehen auch im Tabellenneubau vom 06.09. Der laeuft NACH dem Spaltennachtrag und haette sie samt Inhalt weggeworfen, ohne Fehler und mit stimmender Zeilenzahl. - Creator sehen weiterhin alles und tragen weiterhin nichts ein (403). Die Unterzeile sagt jetzt "alles, was hier steht" statt "alles, was zu dir gehoert" -- eine vollstaendige Liste soll sich nicht wie ein Ausschnitt lesen. pruef-agentur: 61 Pruefungen (vorher 40), alle gruen. Zwei eigene Fehler nebenbei gefunden und behoben: eine Beschriftung mit 11,2 px (Grenze 11,5) und ein Testdatum aus UTC statt Ortszeit. Zusaetzlich gruen: css-klassen, struktur, formulare, barrierefrei-workspace, handy. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
bede91921d |
Der sechste Bereich, und zwei Pruefungen, die den Lauf lahmgelegt haben
DER AGENTUR-BEREICH (Stufe 4 des Plans)
Kernprinzip 04 des Konzepts lautet woertlich "Die Agentur bleibt
angebunden" -- und dafuer gab es bis heute nichts. Fuenf Bereiche
standen, der sechste fehlte vollstaendig. Damit stand nirgends, welche
Kampagne laeuft, welche Schulung ansteht und wie ein Anliegen an die
Agentur ausgegangen ist. Das lief ueber private Nachrichten: nicht
auffindbar, nicht nachvollziehbar, beim naechsten Mal von vorn.
Vier Arten, und die vierte ist der Punkt: kampagne, schulung, anliegen
und ZUSTAENDIGKEIT. Die letzte ist keine Verlegenheit, sondern das, was
das Konzept ausdruecklich fordert -- Betreuung und Umsetzung sind unsere
Seite, offizielle Wege sind Agenturseite. Solange das nur im Kopf steht,
wird es bei jedem Streitfall neu verhandelt.
Der Umbau war das eigentliche Risiko, nicht der Bereich: Ein CHECK
laesst sich in SQLite nicht aendern, die Tabelle muss neu gebaut werden
-- und dabei werden ALLE vorhandenen Eintraege umgeschrieben. Deshalb
geht pruef-agentur.mjs (31 Pruefungen) den Weg wirklich: Sie baut eine
Datenbank im ALTEN Stand nach, fuellt sie mit allen fuenf Bereichen,
laesst die echte Anwendung darueberlaufen und zaehlt danach jede Zeile
UND jedes Feld nach -- auch die seltenen Spalten (hook, creator_extern),
die man beim Abschreiben des Bauplans vergisst. Wichtigste Gegenprobe:
Der CHECK muss danach noch BEISSEN. Eine Umstellung, die nebenbei die
Schranke entfernt, sieht aus wie ein Erfolg und ist der schlimmere
Ausgang.
Nebenbei drei abgeschriebene Bereichslisten beseitigt (Wochenbericht,
Suche, Report-Ziele). Im Wochenbericht waere der neue Bereich sonst
schlicht nicht vorgekommen -- ohne Fehler, ohne Luecke, einfach nicht da.
ZWEI PRUEFUNGEN, DIE DEN GESAMTLAUF ZUM STILLSTAND BRACHTEN
pruef-call-kategorien.mjs hing DREI STUNDEN. Ursache war ein Zeitzuender
in ihr selbst: Sie legte Calls auf "heute 18:00" und erwartete zwei
davon unter "Heute". Ab 18 Uhr sind die vorbei, der Server schiebt sie
nach "Protokoll fehlt", und die Oberflaeche unterteilt erst ab FUENF
anstehenden. Uebrig blieben vier, die Bloecke verschwanden, und die
Pruefung wartete auf einen Klick auf einen Block, den es nicht gab.
Genau die Sorte Fehler, vor der die Projektnotiz vom 06.09. warnt: Sie
war um 17:59 gruen und um 18:01 rot, ohne dass sich am Code etwas
geaendert hatte. Jetzt liegen alle Zeiten RELATIV zu jetzt, und die
Erwartung wird mit derselben Vorschrift gerechnet, die calls.js benutzt
-- statt Zahlen, die nur zu einer bestimmten Tageszeit stimmen.
Und der Grund, warum daraus ein Stillstand statt eines Fehlers wurde:
index.js setzt bewusst zwei Auffangnetze (uncaughtException,
unhandledRejection). Fuer den Betrieb richtig -- ein Fehler darf die
Website nicht offline nehmen. Fuer eine Pruefung fatal: Sie importiert
index.js in denselben Prozess und erbt die Netze. Ihr eigener Absturz
wird dann nur protokolliert, und der Express-Server haelt den Prozess
danach ewig am Leben. Kein Fehler, kein Ergebnis, kein Ende.
Deshalb zwei Abhilfen, die zusammengehoeren:
* server/helfer-notbremse.mjs -- haengt eigene Zuhoerer DANEBEN
(process.on ergaenzt, es ersetzt nicht) und beendet den Lauf mit
Fehler; dazu ein Wecker. In alle 42 Browserpruefungen eingebaut.
Der Betrieb bleibt unveraendert.
* tools/alles-pruefen.mjs gibt jeder Datei eine Frist von 600 s. Wer
sie reisst, wird abgebrochen und ZAEHLT ALS FEHLGESCHLAGEN, mit der
letzten Ausgabe davor als Beleg. Einzelne Dateien nachzuruesten hilft
nur bis zur naechsten ohne Notbremse -- deshalb sitzt sie dort, wo
sie fuer alle gilt, auch fuer die, die es noch nicht gibt.
AUSSERDEM: pruef-breiten.mjs pruefte 16 Seiten aus einer Liste von Hand,
chat.html und leistung.html fehlten darin. Der Chat war bei keiner
einzigen der neun Breiten je gemessen worden. Wie bei pruef-handy kommt
die Liste jetzt aus dem Verzeichnis.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
540b5d8838 |
Freie Namen, ein Call-Knopf, und drei Seiten, die fuer Scouts kaputt waren
DREI SACHEN AUF EINMAL, alle aus derselben Sitzung.
1. AUSSUCHEN ODER SELBST EINTRAGEN
Wunsch: "ich will da auch sachen selber noch eintragen koennen, also
aussuchen und selbst eintragen."
Jede Personenauswahl (Kalender, Aufgaben, Bereiche, Content, Dateien)
nimmt jetzt auch einen getippten Namen an -- eine Agentur, eine Marke,
einen Gast ohne Konto. Dazu bekommt JEDE Auswahl ab acht Eintraegen
ein Suchfeld: tippen statt scrollen.
Gebaut IM vorhandenen Auswahl-Bauteil (wahl.js), nicht daneben. Der
erste Anlauf war ein zweites Bauteil -- es hat sich prompt mit dem
ersten gebissen, beide haben denselben <select> eingepackt. Ein
zweites haette ausserdem anders ausgesehen und waere beim naechsten
Umbau nur an einer von zwei Stellen nachgezogen worden.
Der freie Name steht in einer EIGENEN Spalte je Feld; die Verknuepfung
bleibt leer. Entweder eine Person ODER ein Name, nie beides.
Filipe hat ausdruecklich auch bei den Creator-Feldern freie Namen
gewollt, nachdem der Nachteil benannt war: Der Eintrag gehoert dann zu
keinem Konto. Damit daraus kein STILLER Ausfall wird, faellt jede
Abfrage, die bisher den Namen der verknuepften Person las, jetzt auf
den freien Text zurueck (externSql) -- gekennzeichnet als "(extern)".
Der Eintrag verschwindet dadurch aus keiner Liste, keiner Suche und
keiner Uebersicht.
2. WO FUEHRE ICH DEN CALL?
Den Knopf gab es, aber nur wenn jemand von Hand einen Link ins
Ortsfeld getippt hatte UND das Gespraech noch bevorstand. Stand dort
"Hier", war nichts zum Anklicken da.
Jetzt hat das Team einen festen Call-Raum (Discord-Sprachkanal), den
das Management einmal hinterlegt. Danach hat JEDER Call den Knopf --
und er bleibt, solange das Gespraech laufen kann, nicht nur bis zur
Startzeit. Ein eigener Link am Termin schlaegt den festen Raum.
3. WAS EINE ROLLE SIEHT, MUSS AUCH FUNKTIONIEREN
Gemeldet: "cigdem kriegt als manager gewisse sachen nicht auf die sie
sieht, check jede rolle ab."
Neue Pruefung server/pruef-rollen.mjs schickt SECHS Rollen-Zustaende
ueber alle 16 Seiten und misst Konsolenfehler, fehlgeschlagene
Serveraufrufe, tote Verweise, haengende Ladeanzeigen und wortlos leere
Seiten. 96 Durchgaenge.
Der sechste Zustand ist der wichtige: eine Rolle OHNE zugeteilte
Creator -- der Normalfall am ersten Tag und Cigdems echte Lage.
Genau dort fielen die Seiten durch, waehrend dieselben Seiten MIT
Zuteilung tadellos waren.
VIER ECHTE FEHLER GEFUNDEN UND BEHOBEN:
a) Eine Aufgabe, die eine Managerin ohne Creator anlegte, war fuer sie
im selben Moment unsichtbar -- creator_id und verantwortlich_id
leer, und "von mir selbst angelegt" stand in keiner
Sichtbarkeitsregel. Nur DogFather sah sie noch. Kein Fehler, keine
Meldung, die Aufgabe war einfach weg. Dasselbe bei den
Bereichseintraegen. Beide Regeln kennen jetzt erstellt_von.
Niemand sieht dadurch etwas Fremdes -- nur das Eigene.
b) Ein Scout ohne zugeteilten Creator bekam auf die GESAMTE
Report-Seite 404, obwohl sie fuer ihn verlinkt ist. Die Seite
antwortet jetzt sauber und leer, statt sich zu verweigern.
c) Start-Check und Report blieben fuer immer auf "wird geladen"
stehen, wenn es nichts zu laden gab.
d) Das Creator-Profil war fuer Scouts ohne Zuteilung wortlos leer --
der erklaerende Satz stand nur in der grauen Unterzeile.
Ausserdem meldete die bestehende Lesbarkeitspruefung zwei neue
Beschriftungen von mir als zu klein fuers Handy (10,88 statt 11,5 px).
Behoben, und dieselbe Groesse an der Serien-Karte gleich mit -- dort
waere es erst aufgefallen, sobald jemand eine Wiederholung anlegt.
GEPRUEFT: pruef-rollen 97, pruef-freie-namen 32 (mit Gegenproben:
Ben sieht Cigdems Aufgabe NICHT; die Saeulen-Zuordnung nimmt
ausdruecklich KEINEN freien Namen). Alle bestehenden Laeufe gruen:
Startansicht 133, Kalender 84, Serien 67, Protokoll 52, Handy 50, Sicht
48, Ampel 47, Content 45, Aufgabenbrett 44, Sprung 43,
Personen-Loeschen 40, Bereiche 37, Uebersicht 33, Workspace-Seiten 32,
Formulare 19, Betreuung 18, Grosscheck 15, Lesbarkeit 14.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
da49a227f1 |
Aufgabenbrett fuer alle Rollen -- und nur DogFather sieht alles
Wunsch vom 01.09.2026: "verbessere die Aufgabenseite auch bei Manager,
Scout und Creator. Die Scouts und Manager sollen vielleicht ein bisschen
mehr Optionen haben, wie ihre zugeteilten Creator. Aber auch die Creator
sollen es besser und detaillierter sehen. ABER NUR DIE ROLLE DOGFATHER
SOLL WIRKLICH WEITERHIN ALLEINE ALLES SEHEN KOENNEN."
(Nachgereicht: "die Seite Aufgabe auch bei DogFather machen bitte.")
ZWEI FEHLER IN DEN RECHTEN, die beim Nachsehen herausfielen:
1. Ein MANAGER sah auf dem Aufgabenbrett GAR NICHTS. Die Regel kannte
nur admin, creator und scout; er fiel in den Zweig "unbekannte
Rolle sieht nichts". Ein leeres Brett sieht aus wie "nichts zu
tun", nicht wie ein Fehler -- deshalb ist das lange niemandem
aufgefallen.
2. In Kalender, Dateien, Bereichen und Content sah derselbe Manager
dagegen ALLES (istLeitung). Zwei entgegengesetzte Antworten auf
dieselbe Frage, in einem Programm.
Jetzt gilt ueberall dasselbe: NUR DogFather sieht alles. Manager und
Scout sehen ihre eigenen Sachen plus die Creator, die ihnen zugeteilt
sind. Dafuer arbeitet betreuteIds() jetzt auch fuer Manager -- die
Datenbank konnte das laengst (in `betreuung` steht eine beliebige
Person), nur diese eine Funktion hat alle ausser Scouts abgewiesen.
GEAENDERT WURDE NUR, WER WAS SIEHT. Was ein Manager DARF -- freigeben,
aendern, Personen verwalten -- haengt weiterhin an istLeitung und ist
unberuehrt. Ohne diese Trennung haette ein Wunsch nach weniger Sicht
stillschweigend die halben Rechte mitgenommen; die Pruefung haelt beides
ausdruecklich fest.
DIE SEITE SELBST bekommt drei Zeilen ueber dem Brett, und die
Reihenfolge ist die Aussage:
1. WAS BRENNT -- ein Satz beim Reinkommen. Ein Brett aus vier Spalten
beantwortet das nicht; man muesste alle vier durchsehen, um zu
wissen, dass nichts brennt.
2. AUSSCHNITTE -- "Nur meine", "Heute faellig", "Ueberfaellig", jeder
mit seiner Zahl am Knopf. Ein Filter, der sich erst nach dem Klick
als leer herausstellt, kostet zweimal Aufmerksamkeit. Sie filtern
das Brett, statt eine zweite Liste aufzumachen: Vier Spalten
nebeneinander sind der Wert dieser Seite.
3. DIE CREATOR -- fuer Betreuer und DogFather, je mit offener Anzahl
und einer Warnzahl fuer Ueberfaelliges. Bei DogFather heisst die
Reihe "Alle Creator", sonst "Deine Creator": "deine" waere bei ihm
eine falsche Auskunft.
Ein Creator bekommt weder "Nur meine" noch die Creator-Reihe -- bei ihm
ist ohnehin alles seins, und ein Filter mit einem einzigen Eintrag ist
ein Knopf, der nichts tut. Die Liste der Creator stammt aus den
Aufgaben selbst und nicht aus einer Personenabfrage: Dann stehen dort
genau die, die man ohnehin sehen darf, und niemals einer mehr.
NEBENBEI (Screen 1): In der Betreuer-Auswahl stand "Dogfather
(DogFather)" -- zweimal dasselbe Wort, nur anders geschrieben. Die
Klammer entfaellt jetzt, wenn sie dasselbe sagt wie der Name.
pruef-aufgabenbrett.mjs prueft die ABGRENZUNG zuerst und an konkreten
Aufgaben, deren Titel verraten, wem sie gehoeren -- eine huebschere
Filterleiste ist eine Annehmlichkeit, eine Rechteregel, die zu viel
zeigt, ist ein Schaden. Dazu eine Gegenprobe zur alten Regel (der
Manager sieht ueberhaupt etwas) und die ausdrueckliche Bestaetigung,
dass er weiterhin anlegen darf.
Ein Fehler steckte in der Pruefung selbst: Sie erwartete beim Creator
eine feste Zahl und haing damit von ihrer eigenen Reihenfolge ab -- der
Abschnitt davor legt eine weitere Aufgabe an. Sie vergleicht jetzt gegen
die Schnittstelle. Das ist ohnehin die bessere Frage: nicht "sind es
drei", sondern "verschluckt die Seite etwas".
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
1c00770ec5 |
Lesbarere Kaesten, und DogFather kann durch fremde Augen sehen
SCREEN 1 -- "die Kachel ganz leicht dunkler, so dass man den Text besser gelesen bekommt, aber nicht zu viel, so dass man den Hasen noch sieht." Die Erklaerkaesten stehen jetzt auf 88 statt 78 Prozent Deckung. Zehn Punkte sind gemessen der Unterschied zwischen muehsam und ruhig lesbar und lassen zwoelf Prozent Bild durch -- das Motiv bleibt sichtbar. "und die von wichtigen und neuen PDFs sollen auch staerker sein." Das war kein Geschmack, sondern ein Fehler: `background` ist eine Eigenschaft, keine Schicht. Die Zeile `background: rgba(232,192,125,.045)` hat die Flaeche nicht getoent, sondern ERSETZT -- uebrig blieben viereinhalb Prozent Deckung. Damit war ausgerechnet die Anleitung, die jeder lesen soll, die am schwersten lesbare der Seite. Die Toenung liegt jetzt als Schicht darueber. Gemessen: 88 % gegen 78 % bei einer gewoehnlichen. pruef-lesbarkeit.mjs misst das an ECHTEN PIXELN (Text kurz unsichtbar machen, Flaeche fotografieren, WCAG-Formel) und kennt ZWEI Grenzen -- lesbar genug UND durchsichtig genug. Mit nur einer haette sie eine schwarze Flaeche am besten gefunden, und das wollte niemand. SCREEN 2 -- "ich will alles von den Scouts und Managern einsehen koennen, auswaehlen, was und von wem. Ueberall, auf jeder Seite. NUR WIR BEIDE SOLLEN DIESE OPTION HABEN." Die naheliegende Loesung waere ein Filter je Seite gewesen -- also eine zweite Rechteregel in zwoelf Modulen, und eine Rechteregel an zwoelf Stellen stimmt irgendwann an elf. Stattdessen wird die PERSON getauscht, nicht die Regel: Waehlt DogFather einen Scout, laufen alle vorhandenen Sichtbarkeitsregeln unveraendert mit diesem Scout. Er sieht exakt dessen Arbeitsplatz -- nicht mehr, nicht weniger. Keine neue Rechteregel. Im Browser genauso: EIN Ort statt vierzehn. fetch wird einmal umgeleitet und haengt den Wert an jede lesende Abfrage an. Neue Seiten sind damit von selbst dabei; man kann es nicht vergessen. Drei Sicherungen: nur admin (auf dem SERVER geprueft, nicht in der Oberflaeche), nur lesend (geschrieben wird immer im eigenen Namen -- sonst staende im Protokoll der falsche Name), nur aktive Personen. Und ein Rahmen um die Seite, solange eine fremde Sicht laeuft. Der gefaehrlichste Fall ist nicht, dass man nicht umschalten kann, sondern dass man vergisst, dass man umgeschaltet hat -- und drei Aufgaben statt dreissig fuer den Bestand haelt. FUENF FEHLER, DIE DIE PRUEFUNGEN GEFUNDEN HABEN: 1. steckbrief.html hat die Kopfleiste NIE gefuellt -- dort stand monatelang "…" statt des eigenen Namens. Aufgefallen, weil der Umschalter dort fehlte. Jetzt zusaetzlich ein Netz darunter: Meldet sich nach kurzer Zeit niemand, holt der Kopf sich selbst, wer angemeldet ist. Die naechste neue Seite kann es nicht mehr vergessen. 2. Der Umschalter sprengte die Kopfleiste (46 px am Rechner, 117 px am Handy) und drueckte den Abmelden-Knopf hinaus. 3. Ich habe das <select> gestaltet -- wahl.js ersetzt aber jedes Auswahlfeld durch einen eigenen Knopf und schrumpft das echte Feld auf einen Pixel. Meine Regeln haben es wieder auf 20 x 44 aufgeblasen, wo es als unsichtbares Hindernis ueber dem Knopf lag. Gestaltet wird jetzt der Knopf. 4. Ein Wettlauf: Auf profil.html rufen zwei Dateien werZeigen() auf. Beide kamen an "gibt es den Umschalter schon?" vorbei, bevor eine ihn angehaengt hatte -- zwei Umschalter uebereinander. Die Sperre gehoert vor das erste await. 5. Die Handy-Pruefung bemaengelte ein Schild, das dort per display:none gar nicht erscheint. Sie sieht jetzt nur noch sichtbaren Text an -- eine Pruefung, die Unsichtbares anmahnt, gewoehnt man sich ab zu lesen. Dazu zwei Messfehler in den Pruefungen selbst: getComputedStyle liefert ein LEBENDES Objekt (die Farbe wurde gelesen, nachdem der Text unsichtbar gemacht war -- gemeldet wurden 1,17:1 fuer tadellos lesbaren Text), und ein Vergleich lief still ins Leere, weil die Vergleichsdaten fehlten. pruef-sicht.mjs stellt den MISSBRAUCH an den Anfang: Scout, Manager und Creator haengen ?sicht= an und muessen ignoriert werden; erfundene Nummern, Buchstaben und ein Einschleusversuch fallen auf die eigene Sicht zurueck; eine abgeschaltete Person liefert keine Sicht mehr; und was DogFather bei fremder Sicht anlegt, steht unter SEINEM Namen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ca10479909 |
Fertige Vorlagen zum Uebernehmen - Content-Ideen und LIVE-Punkte
Der Wunsch stand an fuenf Stellen gleichlautend: "ich will dass da schon fertige Sachen stehen". Eine leere Seite mit einem Knopf "Neuer Eintrag" verlangt vom Creator genau das, was er noch nicht kann -- zu wissen, was ueberhaupt hineingehoert. WARUM VORLAGEN UND KEINE VORAUSGEFUELLTEN DATEN. Man koennte beim Anlegen eines Creators dreissig Eintraege in seine Datenbank schreiben. Das waere falsch: Sie waeren ab dem ersten Tag "seine" Eintraege und damit Altlast; aendert Filipe spaeter eine Formulierung, gilt sie nur fuer neue Creator; und die Liste saehe voll aus, obwohl noch nichts geschehen ist -- das Gegenteil einer ehrlichen Uebersicht. Vorlagen bleiben deshalb VORSCHLAEGE, bis jemand sie uebernimmt. Sie stehen im Code, gelten fuer alle sofort, und werden erst dann zu Daten, wenn sie gebraucht werden. Was uebernommen ist, ist ein ganz normaler Eintrag -- aenderbar, loeschbar, und von spaeteren Aenderungen an der Vorlage unberuehrt. INHALTE, fachlich begruendet: 13 Content-Ideen, jede mit AUSFORMULIERTEM Aufhaenger und Format. Die ersten ein bis drei Sekunden entscheiden ueber die Verbreitung -- "mach was Persoenliches" hilft niemandem, "Das haette ich am Anfang gern gewusst" kann man sagen. Verteilt nach 70/20/10 (Wert, Community, Eigenwerbung). 21 LIVE-Punkte in drei Abschnitten. Der mittlere ist der wichtigste und gibt es sonst nirgends: Was WAEHREND der Sendung auffaellt, ist am naechsten Tag weg. Diese Punkte sind so formuliert, dass man sie in einem Moment anklicken kann, in dem man eigentlich keine Zeit hat. Die Vorbereitung ist die laengste Liste, weil ein LIVE dort steht und faellt. Ton zuerst -- der Grund Nummer eins, warum Leute wieder gehen. "ICH BRAUCHE HILFE" wird eine AUFGABE, keine Nachricht. Eine Nachricht ist gelesen und dann weg; eine Aufgabe bleibt stehen, bis sie jemand erledigt, geht an den zustaendigen Betreuer (ohne Betreuer an die Leitung -- eine Bitte um Hilfe darf nicht ins Leere laufen), traegt hohe Prioritaet und eine Frist von drei Tagen. Ohne Frist bleibt sie liegen; das ist der Unterschied zwischen einer Aufgabe und einem Zettel. "CONTENT-PLANUNG" HEISST JETZT "CONTENT-IDEEN". "Planung" klang nach Terminen und Tabellen; was dort wirklich passiert, ist das Sammeln und Weiterentwickeln von Ideen. Der Kalender daneben plant. EIN CREATOR DARF SEINE EIGENEN EINTRAEGE AENDERN -- aber nur im Bereich Content. Wenn er sich eine Idee uebernimmt, ist das SEINE Idee; sie danach nicht umbenennen zu duerfen waere absurd. LIVE, Technik, Community und Schutz bleiben die Betreuungsakte, dort aendert er nichts. Ein erster Anlauf hatte die Ausnahme fuer alle Bereiche erlaubt -- die Pruefung pruef-bereiche-lesend hat das sofort gemeldet. DREI EIGENE FEHLER, VON DEN PRUEFUNGEN GEFUNDEN: - Der Vorlagenblock vergass nach dem Uebernehmen, was schon geholt war: Die Liste wird neu geladen, der Block neu gebaut, und die Markierung am Element war jedes Mal weg. Jetzt merkt sich das Modul die Auswahl. - Die Regel fuer eigene Eintraege war zu breit (siehe oben). - Die Marken im Vorlagenblock waren auf dem Handy 10,2 px klein. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
43ce6551e2 |
Bereiche nur lesend fuer Creator + Content-Planung als echte Strecke
ZWEI SACHEN, beide auf Wunsch vom 31.08.2026.
1) "die creator sollen da nur die sehen die wir ihnen eintragen, also
dogfather manager und scout."
Vorher durfte ein Creator in LIVE, Content, Technik, Community und Schutz
selbst anlegen, aendern und eigene Eintraege loeschen. Das hebelt den
Zweck dieser Bereiche aus: Sie sind die Betreuungsakte. Wer eine
LIVE-Auswertung umschreiben oder eine unbequeme Notiz verschwinden lassen
kann, macht die Akte wertlos.
Der Creator SIEHT weiterhin alles, was zu ihm gehoert -- vollstaendig.
Er kann es nur nicht veraendern. Umgesetzt als EINE Schranke vor allen
schreibenden Wegen, nicht als Pruefung an drei Stellen: Genau so ist hier
schon einmal ein Loch entstanden (zwei von drei Stellen abgesichert, die
dritte vergessen). 403 mit klarem Text statt 404 -- der Bereich existiert
fuer ihn ja, er steht davor.
Vorsicht Express 4: Der Platzhalter heisst dort `*`, nicht `*name` wie in
Fassung 5. Mit der falschen Schreibweise haette die Sperre stumm nichts
getan -- kein Fehler, keine Warnung.
37 Pruefungen, Schwerpunkt auf den verneinenden Faellen: alle fuenf
Bereiche, alle drei Wege, dazu der eigene Alteintrag (der frueher
ausdruecklich erlaubt war) und der Nachweis, dass hinterher wirklich
nichts veraendert wurde.
2) Content-Planung: aus der Liste wird eine Strecke.
Recherchiert statt geraten. Die Quellen sind an drei Punkten eindeutig:
* "A content calendar for creators is a pipeline, not a datebook" --
eine Wand aus Terminen verbirgt genau die Stellen, an denen es hakt.
* Die ersten ein bis drei Sekunden entscheiden ueber die Verbreitung.
Der Hook ist deshalb ein eigenes Feld auf jeder Karte, kein Fliesstext.
* Regelmaessigkeit schlaegt Menge. Wer regelmaessig senden will, braucht
VORRAT -- und Vorrat ist die eine Zahl, die eine Ideenliste
verschweigt.
Daraus:
* Fuenf Stufen statt drei (Idee, Hook & Skript, Gedreht, Fertig &
geplant, Veroeffentlicht). Alte 'produktion'-Eintraege werden beim
naechsten Start auf 'gedreht' umgestellt -- ohne das fielen sie aus
jeder Spalte heraus.
* Neue Felder hook, format, saeule_id, geplant (ALTER TABLE, gefahrlos).
* Content-Saeulen je Creator, drei bis fuenf, nach der 70/20/10-Regel.
Mit Balance-Balken ueber 90 Tage, nur Veroeffentlichtes -- was auf dem
Kanal steht, ist die Wahrheit ueber seine Ausrichtung.
* Die Kachel VORRAT rechnet in TAGE um ("reicht noch etwa 7 Tage").
"4 Videos uebrig" sagt nichts; die Tage sagen, ob man am Wochenende
drehen muss. Gezaehlt wird nur Gedrehtes und Fertiges -- eine Idee ist
kein Video, und wer Ideen mitzaehlt, steht am Donnerstag ohne Material.
* "Ideen lassen sich direkt in Aufgabe/Termin/LIVE-Thema ueberfuehren"
-- woertlich aus dem Konzept, das letzte unumgesetzte Stueck. Die Idee
bleibt bestehen und bekommt einen Vermerk, damit niemand dieselbe
Aufgabe zweimal anlegt.
Farben: Die fuenf Saeulenfarben sind Daten, keine Dekoration. Geprueft
gegen genau diesen Hintergrund (#0a0d13) auf Helligkeitsband,
Farbstaerke, Farbfehlsichtigkeit (schlechtestes Paar dE 8.4),
Normalsicht-Abstand (19.3) und Kontrast -- alle Pruefungen bestanden.
Immer mit Legende UND Beschriftung; Farbe allein traegt nie die
Information.
Beim Ansehen des ersten Bildes fiel der klassische Brett-Fehler auf: Die
Spalte "Veroeffentlicht" waechst ewig und schiebt alles andere aus dem
Bild. Sie zeigt jetzt die juengsten sechs, der Rest ist einen Klick
entfernt. Die vorderen Spalten bleiben ungekuerzt -- was dort liegt, ist
Arbeit.
Nur EIN Schreiber fuer die Tabelle eintraege: workspace-content.js
enthaelt ausschliesslich, was es woanders nicht gibt (Saeulen,
Kennzahlen, Ueberfuehren). Zwei Module auf denselben Zeilen waeren der
sichere Weg zu zwei Wahrheiten.
45 + 40 Pruefungen, Computer und Handy, dazu die Gegenprobe: Ein Creator
sieht die ganze Strecke, die Kennzahlen und die Verteilung -- und keinen
einzigen Knopf, auch keinen versteckten. Ausgeblendet ist nicht dasselbe
wie nicht vorhanden.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGit
|
389d8c1213 |
Workspace: neue Rolle Manager, feste Rollenreihenfolge, echte Rollenwahl
DREI TEILE. 1) ROLLE "MANAGER" Ein Manager darf alles, was DogFather darf -- mit genau zwei Vorbehalten: Er kann keine Leitung ANLEGEN und an keiner Leitung etwas AENDERN. Sonst koennte er sich einen zweiten Vollzugang schaffen oder DogFather aussperren. "Nur DogFather hat alle endgueltigen Rechte" heisst genau das. Umgesetzt ueber istLeitung() an EINER Stelle statt 44 einzelner Vergleiche auf "admin" im Server und 26 im Browser. DATENBANK-UMSTELLUNG: CREATE TABLE IF NOT EXISTS fasst eine vorhandene Tabelle nicht an -- die CHECK-Regel stand also weiter auf den alten drei Rollen, und ein Manager waere daran gescheitert, obwohl der Code stimmt. SQLite kann eine CHECK-Regel nicht aendern, also: neue Tabelle, Daten hinueber, alte weg, umbenennen. Davor schreibt der Server eine vollstaendige Sicherung (VACUUM INTO, in sich konsistent). Ohne Sicherung wird NICHT umgestellt. Geprueft nach der Umstellung: alle 13 Tabellen mit gleicher Zeilenzahl, PRAGMA integrity_check ok, keine verwaisten Verweise. Die einzige Abweichung war eine Sitzung mehr -- die eigene Anmeldung, die die Umstellung ausgeloest hat. 2) EIN SICHERHEITSLOCH, DAS DER TEST GEFUNDEN HAT Der erste Entwurf sicherte "Person anlegen" und "Person sperren" ab -- und liess "neuer Zugangscode" offen. Ein Manager konnte DogFather einen neuen Code ausstellen, bekam ihn angezeigt und haette ihn damit aus seinem eigenen Konto ausgesperrt. Im Test aufgefallen, weil ich den negativen Fall durchgespielt habe. Behoben nicht durch eine dritte Einzelpruefung, sondern durch eine Schranke an JEDEM Weg mit einer :id. Der naechste Weg, der dazukommt, ist damit automatisch mitgeschuetzt. Nachgeprueft: Manager bekommt 403 beim Code-Erneuern und Sperren von DogFather UND von sich selbst, darf aber Creator und Scouts verwalten. 3) FOLGEFEHLER DER MASSENERSETZUNG Die Regel "niemals den letzten aktiven DogFather sperren" hatte durch die Umstellung auf istLeitung() ploetzlich auch Manager blockiert -- gezaehlt werden aber nur DogFather-Zugaenge. Jetzt istDogFather(). Geprueft: DogFather kann einen Manager sperren, sich selbst nicht. 4) REIHENFOLGE UND ROLLENWAHL Ueberall DogFather, Manager, Scout, Creator. "ORDER BY rolle" waere alphabetisch gewesen (admin, creator, manager, scout) -- also fast genau falsch herum. Jetzt ein gemeinsamer Sortierausdruck aus workspace.js. Das Auswahlmenue fuer die Rolle ist weg. Es kam als weisses Windows-Menue mitten in einer dunklen Oberflaeche und schnitt "Creator" zu "Crea" ab -- gestalten laesst sich ein aufgeklapptes Systemmenue nicht. Ersetzt durch vier sichtbare Schalter mit Symbol, Farbe je Rolle und einer Zeile, was die Rolle bedeutet. Bei "Manager" gegen "DogFather" ist das der Unterschied zwischen Raten und Wissen. DogFather und Manager stehen dort nur zur Wahl, wenn DogFather selbst davorsitzt -- ein Knopf, der immer scheitert, gehoert nicht hin. Nebenbei: Das Namensfeld war auf eine von zwoelf Spalten gequetscht, weil seine Umgebung keine .feld-Klasse trug. Alle Formulare daraufhin durchsucht, keine weiteren Faelle. |
||
|
DogFatherGit
|
5684ff87f1 |
Workspace: "Was ist dran" -- erster Baustein der Automationen (Phase 4)
Bis hierher musste man selbst daran denken, in den richtigen Bereich zu
schauen. Das dreht die Uebersicht auf dem Dashboard jetzt um: Das System
sagt, was liegen bleibt.
Drei Regeln, an die sich das haelt:
1. KEINE eigenen Daten. Ein Hinweis ist immer nur eine Sicht auf etwas,
das ohnehin existiert. Wird die Aufgabe erledigt, verschwindet der
Hinweis von selbst -- es gibt nichts zu quittieren, nichts zu pflegen
und nichts, was veralten kann. Genau daran scheitern die meisten
Erinnerungssysteme.
2. JEDER HINWEIS FUEHRT IRGENDWOHIN. Ein Hinweis ohne Ziel ist nur ein
schlechtes Gewissen. Jeder traegt deshalb einen Link zu der Stelle,
an der sich die Sache tatsaechlich erledigen laesst. Geprueft: Ziel
erreichbar, keine Umleitung.
3. DIESELBE SICHTBARKEIT WIE UEBERALL. Die Regeln werden aus den
Fachmodulen importiert, nicht abgeschrieben (workspace-aufgaben,
-kalender, -dateien, -bereiche exportieren sie jetzt). Ein Hinweis
darf nie etwas verraten, das die zugehoerige Seite verbergen wuerde
-- sonst waere ausgerechnet die Uebersicht das Leck.
Dreizehn Hinweisarten, in drei Stufen. Nur die oberste ist farbig:
waere alles hervorgehoben, waere nichts hervorgehoben. Liegt nichts an,
verschwindet der ganze Block.
Steht bewusst VOR den Zahlen. Die Zahlen sagen, WIE VIEL anliegt --
diese Liste sagt, WAS zu tun ist.
Steuerungswissen bleibt beim Management: Review-Termine, Creator ohne
zustaendige Person und leere Profile erscheinen weder bei Creator noch
bei Scouts -- genau wie die zugehoerigen Profilfelder. Geprueft mit
einem eigenen Leck-Test ueber alle drei Rollen.
Zwei Hinweise, die es ohne diese Uebersicht gar nicht gaebe:
- Aufgaben, die im Review haengen. Sie warten auf jemanden -- die Sorte
Stillstand, die niemandem auffaellt, weil nichts ueberfaellig wird.
- Uebergebene Leads, aus denen nie ein Creator wurde. Sonst ist die
Uebergabe eine Sackgasse, die niemand bemerkt.
Nebenbei: Der Fusstext auf dem Dashboard stammte noch vom ersten Tag
("Die Bereiche werden nach dem Phasenplan gebaut") -- inzwischen sind
Phase 1 bis 3 fertig. Ersetzt durch eine Erklaerung, wie die Uebersicht
funktioniert.
|
||
|
DogFatherGit
|
fa8fbab410 |
Workspace: Scouts betreuen Creator wie das Management
Bisher hatten Scouts mit der Creator-Betreuung nichts zu tun -- keine Profile, keine Betreuungsbereiche, keine Reports. Das aendert sich, mit zwei bewusst gesetzten Grenzen. GRENZE 1: nur zugeteilte Creator, keine Rollenregel. Neue Tabelle betreuung (creator_id PRIMARY KEY -> betreuer_id). Ein Creator hat genau EINE zustaendige Person, damit nie unklar ist, wer gefragt ist. Das Management sieht ohnehin alle und braucht keinen Eintrag. Wer nichts zugeteilt bekommt, sieht weiterhin nichts -- kein Recht entsteht automatisch aus der Rolle. Zugeteilt wird in "Personen & Zugaenge", direkt in der Personenzeile: Betreuung ist eine Eigenschaft der Person, kein eigener Vorgang. Nur das Management darf zuteilen -- koennte ein Scout sich selbst Creator geben, haette er die Rechtevergabe in der Hand, die ihn begrenzen soll. Zustaendig koennen nur aktive Scouts sein, kein Admin (der sieht alles) und kein anderer Creator. Bei der Uebergabe aus der Pipeline passiert die Zuteilung von selbst: Wer jemanden gefunden hat, betreut ihn weiter. Genau darum geht es bei "Creator-Onboarding starten". Umhaengen kann das Management jederzeit. GRENZE 2: betreuen, nicht verwalten. Profile, die fuenf Bereiche und Reports wie ein Manager. ABER: - keine Zugangscodes, kein Sperren von Personen (personen.html bleibt admin-only, unveraendert) - keine management-internen Felder. Der Scout bekommt admin_notiz, plan_start und naechster_review NICHT -- die Felder fehlen in der Antwort komplett, nicht nur in der Anzeige. Eine Notiz UEBER die Betreuung gehoert nicht in die Hand dessen, der betreut. Geprueft: Ein Scout, der admin_notiz mitschickt, aendert sie nicht. Die Regel steht an EINER Stelle (betreuteIds / betreutWo / darfCreator in workspace.js) und wird von sechs Modulen benutzt. Eine Rechteregel, die an sechs Stellen steht, ist eine Rechteregel, die irgendwann an fuenf Stellen stimmt. Genau das ist beim Bauen auch passiert: workspace-calls.js hatte eine wortgleiche Kopie der Kalender-Sichtbarkeit. Erweitert wurde nur der Kalender -- Scouts sahen die Termine ihrer Creator, dieselben Termine als Call aber nicht. Die Kopie ist jetzt weg, calls.js importiert die Regel aus workspace-kalender.js. Zwei Fehler, die die Aenderung selbst erzeugt haette, vorher gefunden: - Report-Entscheidung: ein Scout haette eine Aufgabe angelegt, deren "Creator" er selbst ist -- die waere in jeder Auswertung falsch mitgelaufen. Zeigt jetzt auf einen seiner Creator. - Bereichseintrag: derselbe Fehler. Ein Scout hat gar keinen eigenen Betreuungsbereich. Ein Eintrag ohne oder mit fremder Zuordnung landet beim ersten zugeteilten Creator, nie bei einem fremden. Geprueft: Mikas Bereich bleibt bei jedem Versuch unberuehrt. |
||
|
DogFatherGit
|
df9f87af0a |
Workspace: Phase 2 -- LIVE, Content, Technik, Community, Schutz
Fuenf Bereiche auf einmal, aber NICHT fuenf Module. Im Deck haben sie dieselbe Grundform: Eintraege zu einem Creator mit Art, Datum, Titel, Text und Status. Sie unterscheiden sich nur darin, welche Arten es gibt und ob eine Bewertung oder eine Dringlichkeit dazugehoert. Deshalb ein gemeinsamer Unterbau: eine Tabelle, eine Sichtbarkeitsregel, eine Pruefung, eine Ansichtsseite (bereich.html?b=live). Ein Fehler laesst sich damit an EINER Stelle beheben statt an fuenf, und ein weiterer Bereich waere ein Eintrag in BEREICHE -- kein neues Modul. Arten woertlich aus dem Deck (Seiten 7-12): live Vorbereitung / Waehrend LIVE / Auswertung + Bewertung 1-5 content Idee / Produktion / Veroeffentlicht technik Setup / Problem / Loesung / Anleitung + Dringlichkeit community Moderation / Aktion / Konflikt + Dringlichkeit schutz Richtlinie / Vorfall / Eskalation / Gelernt + Dringlichkeit Die Oberflaeche kennt die Bereiche nicht auswendig -- welche Arten und Zusatzfelder es gibt, sagt der Server in der Antwort. Geprueft, und zwar fuer alle fuenf gleichzeitig: - Sichtbarkeit: Chef sieht alles, Luna nur ihren Bereich, Mika nur seinen, Sam (Scout) gar nichts (404 -- Scouts haben mit der Creator-Betreuung nichts zu tun) - Luna legt Eintrag mit creator_id=Mika an: landet still in ihrem eigenen Bereich, Mika sieht ihn nicht - Luna auf Mikas Eintrag: 404; Luna loescht Chefs Eintrag ueber ihren Bereich: 403 (loeschen darf das Management und wer ihn schrieb -- sonst koennte ein Creator eine Notiz ueber sich verschwinden lassen) - Eintrag ueber den falschen Bereich in der Adresse ansprechen: 404 - unbekannte Art 400, Bewertung 9 (erlaubt 1-5) 400, unbekannter Bereich 404, fremde Herkunft 403 Beim Testen sahen Umlaute zunaechst zerstoert aus (efbfbd, das Unicode-Ersatzzeichen). Ursache war der curl-Aufruf: Git Bash kodiert $'\xc3\xbc' nach Locale um. Ueber den echten Weg (Browser) kommen Umlaute, ss und Gedankenstrich unveraendert an und liegen sauber in der Datenbank -- gegengeprueft auf Byte-Ebene. |