d76d9aa5da001d79216d63f89276fc82bb9e86a1
51
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  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
|
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
|
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
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
39dd666b17 |
Der Treff zieht in Team Dogi ein — die dritte Adresse ist wieder weg
Filipe, nachdem er die dritte Wand gesehen hatte: "das soll keine app für sich sein, dass soll in der crew seite adaptiert werden, da rein perfektionniert." WAS VERSCHWINDET: treff.dogfather-universe.com samt Weiche (treff-adresse.js), Zugangswand, Manifest und acht Bühnenbildern. Kein DNS-Eintrag, kein zweiter Caddy-Block, kein zweites App-Symbol. Die Gründe, die DAFÜR sprachen, stehen jetzt als Kommentar in crew-adresse.js statt als Code -- sie gelten weiter, und beim nächsten Mal wird jemand dieselbe Idee haben: eine App je Ursprung, und ein Schloss mehr zwischen der Community und den Daten der Agentur. WAS DER VERZICHT KOSTET, benannt statt übersehen: · Die Community steht vor derselben Wand wie das Team und liest dort die Namen der drei Team-Rollen. Filipes Entscheidung auf die Frage: vierte Kachel "Community" statt gar keiner Kacheln. · Ein Schloss weniger. Was vorher die Adresse getrennt hat, muss jetzt jede einzelne Regel halten -- deshalb prüft pruef-treff-werkzeuge seit heute zehn Dinge mehr (70 statt 60). EINE LÜCKE, DIE DABEI AUFGEFALLEN IST -- und die es schon vorher gab: Ein Mitglied der Community stand in der Auswahl, wen man zu einem Termin einlädt, wem man eine Aufgabe gibt und mit wem man einen Chat anfängt. Für DogFather bedeutet fast jede Liste "alle". Jetzt zu, über eine Hülle (ohneAussen) um die fünf Listen, die von Zusammenarbeit handeln -- damit sie auch für die Listen gilt, die es noch nicht gibt. Die Verwaltungsliste in "Personen & Zugänge" zeigt sie weiterhin, sonst legt er einen Zugang an und der verschwindet im selben Moment. DREI BEFUNDE AUS DEN PRÜFUNGEN, wieder keiner vom Lesen: · Mein eigener Kommentar auf der Wand nannte eine Rolle der Agentur -- in einer Datei, die jedes Community-Mitglied im Quelltext liest. Zum zweiten Mal an einem Tag, und zum zweiten Mal ausgerechnet in einem Kommentar, der erklärt, warum man das nicht tut. · Die Prüfung "der Satz nennt die Modis" durchsuchte den QUELLTEXT und wäre grün geblieben, obwohl der Satz auf dem Bildschirm längst ein anderer ist -- sie fand ihn in einem Kommentar. Sie misst jetzt die sichtbare Unterzeile. · Der erste Entwurf der Adressregel sperrte die Community auch auf localhost aus -- eine Bedingung durch AUSSCHLUSS, zum dritten Mal an einem Tag. Jede Zeile nennt jetzt die Adresse, FÜR DIE sie gilt. Und zwei feste Zahlen weniger: Die Kachelreihe wird nicht mehr gezählt, sondern beim Namen genannt (admin, hand, modi, gast) -- eine Zahl war dort schon zweimal rot, ohne dass etwas kaputt war. Der App-Name wird nicht nur geprüft, sondern der UNTERSCHIED zur Agenturadresse. Die App heißt auf crew. jetzt "DogFather Universe" statt "Team Dogi" -- sie gehört ab heute beiden (Entscheidung Filipe). Geprüft: rollen 312 · crew-adresse 132 · kalender 104 · sicht 84 · modi-verborgen 80 · chat-kanaele 79 · treff-werkzeuge 70 · haus-trennung 62 · treff 58 · chat 48 · treff-seiten 42 · bereiche-lesend 37 · start-ansicht 147 · css-klassen 30 · zwischenspeicher 21 · alle-wege 19 · rechtetafel 19 -- alles grün. Die 58 bei pruef-treff sind elf weniger als gestern: Mit der dritten Adresse fallen ihre 26 Weichen-Prüfungen weg, ersetzt durch 10 für die eine Wand plus die neuen in 7b. 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
|
3cda64568d |
Die Modi-App bekommt ihre eigene Adresse: crew.dogfather-universe.com
Filipe: "ich will dass es eine eigene app wird" -- und dann "subdomain
machen jetzt sofort". Name von ihm gewaehlt: crew. (unauffaellig).
Auf einem Ursprung laesst sich genau EINE App installieren (w3c/manifest
Nr. 1180). Derselbe Grund, aus dem der Workspace am 06.09. umgezogen ist.
Getrennt wird ueber den HOSTNAMEN: ein Dienst, eine Datenbank, ein
Verzeichnis wie bisher.
DIE REGEL STEHT AN EINER STELLE
crew-adresse.js beantwortet: Darf diese Rolle auf dieser Adresse
angemeldet sein? Eingehaengt in sitzungLesen() -- durch die Funktion geht
jedes der 26 Fachmodule und jede Seitenschranke. Eine Middleware daneben
kann man in einem neuen Modul vergessen, und ein vergessener Rechteschutz
faellt nicht auf, weil dann alles geht.
crew. nur Modis; jeder andere bekommt 401 wie bei einem Tippfehler
workspace. keine Modis mehr; sie bekommen den Weg zur neuen Adresse
localhost UNVERAENDERT
Die dritte Zeile ist der Kern: Die Regel ist eine AUFZAEHLUNG der drei
echten Adressen, nicht "alles ausser crew". Sonst wuerden sieben andere
Pruefdateien ab sofort messen, dass ein Modi nirgends hereinkommt -- gruen,
weil sie nichts mehr finden.
ZWEI APPS, ZWEI NAMEN
Beide Adressen liefern dieselben HTML-Dateien. Auf crew. wird
/workspace/app.webmanifest serverseitig auf crew.webmanifest umgebogen --
so braucht keine der 30 Seiten eine zweite Zeile, die man bei der 31.
vergisst. "Team Dogi" statt "Creator Workspace", eigenes Zeichen:
derselbe Husky, aber ohne Chili (die gehoert zu Spicy Media, nicht zu
ihnen) und im Modi-Ton #5f8a9f.
tools/crew-symbol.mjs erzeugt die sechs Symbole und bricht ab, wenn sie
sich zu weniger als 10 % vom Workspace-Symbol unterscheiden. Gemessen:
43 bis 53 %.
GEMESSEN
pruef-crew-adresse 74 Pruefungen, 0 Fehler -- mit Gegenprobe: der Modi
bekommt in der Datenbank die Rolle 'manager', danach
MUSS dieselbe Sitzung auf crew. ins Leere laufen
pruef-rollen 245, unveraendert (die Regel ist lokal wirkungslos)
pruef-workspace-umzug 31 Faelle
pruef-zwischenspeicher 21 -- ein Stempel im Haus, jetzt ueber 23 Dateien
Der Server kennt die Adresse damit. DNS und Caddy bleiben Filipes Schritt.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6122ea6972 |
Eigene Checklisten fuer die Modis -- und eine Seite fuer euch beide
Wunsch Filipe (10.09.2026): *"diese kategorien mussen auf dieser seite auch noch auf die modis perfektionniert werden, da mussen lauter sachen sein die vanvan und ich danach verteilen können und da anpassen können ob gut oder nicht."* Und: *"da soll es eine kategorie geben für uns beide nur sonst keinen wo wir dass alles sehen und behandeln können."* === TEIL 1: SEIN EIGENER PUNKTESATZ === 101 Punkte in workspace-modi-punkte.js -- Live-Ablauf 40, Community 36, Technik 25. Die vorhandenen sagen "Upload messen", "Sendeplan festlegen", "Verweildauer vergleichen": Ein Modi sendet nicht, er moderiert. Ihm dieselbe Liste vorzulegen hiesse, ihn an Dingen zu messen, die nicht seine Arbeit sind. DIESELBE EINTEILUNG (Vor/Waehrend/Nach usw.), nur andere Punkte darin. Zwei verschiedene Einteilungen waeren zwei Dinge zum Lernen statt einem, und die Oberflaeche kaeme ohne Umbau nicht damit zurecht. DIE SCHLUESSEL BEGINNEN MIT "m-". Der Stand haengt an (bereich, schluessel, person) -- ohne Praefix koennte ein Modi-Punkt eines Tages denselben Namen tragen wie ein Creator-Punkt und dessen Bewertung erben. BEIDE SAETZE STEHEN IN GUELTIG. Stuenden dort nur die Creator-Punkte, kaeme die Liste an und jeder Klick darauf brachte einen 404 -- die Sorte Fehler, die man erst beim Benutzen merkt. Ein Modi sieht SEINE Liste, ohne jemanden auszuwaehlen (wie ein Creator), und bewertet sich nicht selbst. Ohne diese Zeile waere er in den Betreuer-Zweig gefallen, haette eine Auswahl fremder Creator vorgesetzt bekommen und seine eigene Liste gar nicht gesehen. DER HEIKELSTE PUNKT WAR EIN ANDERER: `darfCreator` sagt bei siehtAlles() pauschal ja -- und darin steckt auch Spicy Media. Wer die Modi-Auswahl daran haengt, oeffnet sie ihr nebenbei mit, ohne dass an der Stelle etwas davon steht. Deshalb eine eigene Regel (darfPerson), und die Pruefung versucht es ueber die Liste, ueber die Adresse UND ueber das Bewerten. Die Auswahl heisst bei der DogFather-Rolle jetzt "Person" statt "Creator" -- ein Feld namens "Creator", in dem ein Modi steht, ist falsch beschriftet. Das Wort kommt vom Server; ein Rollenvergleich im Browser waere die Stelle, an der der Name in einer ausgelieferten Datei landet. === TEIL 2: DIE GEMEINSAME SEITE === teamlage.html, nur fuer die DogFather-Rolle -- also Filipe und VanVan. Fuer alle anderen gibt es weder die Kachel noch die Seite noch die Schnittstelle (404, wie bei einer Adresse, die es nicht gibt). Zwei Schloesser, absichtlich: die Schranke und die Abfrage. Faellt eines weg, haelt das andere. Je Person: offene und ueberfaellige Aufgaben, beigetragene Ideen, Rueckmeldungen, und je Bereich gut/verbessern/offen. Jede Zeile fuehrt in den Bereich -- MIT DER PERSON VORAUSGEWAEHLT. Dafuer liest die Checkliste jetzt `creator_id` aus der Adresse; ohne das landet man auf der erstbesten Person und weiss beim zweiten Suchen nicht mehr, warum man hier war. SIE ZAEHLT, SIE BEWERTET NICHT. Bewertet wird dort, wo die Punkte stehen. Eine zweite Stelle dafuer waere eine zweite Stelle, an der es auseinanderlaeuft. UND SIE IST KEINE UEBERWACHUNG. Ueber team.html steht schon, dass eine Seite mit Zahlen ueber Kollegen als Kontrolle gelesen wird -- und dann arbeitet niemand mehr offen damit. "Offen" heisst hier deshalb ausdruecklich: darueber habt ihr noch nicht geredet. Eine Merkliste fuer euch beide, keine Note. ALLES IN VIER ABFRAGEN, nicht vier je Person -- bei zehn Modis waeren das vierzig. Denselben Fehler hat das Haus bei den Terminen schon gemacht und ihn dort vermerkt. KEINE NEUEN CSS-KLASSEN: Fuer genau diese Karten gibt es sie schon (tperson, tz, schritt -- aus team.html). Elf neue haetten gepflegt werden muessen fuer ein Aussehen, das bereits da ist. ZUSATZKACHELN sind ein neuer, kleiner Mechanismus: `bereiche` ERSETZT die Liste im Browser (fuer Rollen, die dort nicht vorkommen), `bereiche_zusatz` HAENGT an. Gebraucht fuer Kacheln, die nur eine einzige Rolle bekommt -- in bereiche.js duerften sie nicht stehen, weil eine Kachel, die nur bei einem erscheint, die Frage aufwirft, fuer wen sie ist. Findet sich die genannte Gruppe nicht, wird eine eigene angelegt: Sonst faellt die Kachel lautlos weg, sobald jemand eine Gruppe umbenennt. EHRLICH ZUM UMFANG: Technik ist mit 25 Punkten der duennste Bereich. Das ist Absicht -- der technische Spielraum eines Moderators ist kleiner als der eines Streamers. Auffuellen haette Fuellmaterial in eine Liste gebracht, die Filipe und VanVan durchgehen muessen. GEPRUEFT: pruef-modi-checkliste (39, neu), pruef-rollen (244 statt 243 -- die neue Kachel wird angeklickt und muss ankommen), pruef-modi-verborgen (75), pruef-workspace-seiten. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b45de940e8 |
Rund um das Team -- die Arbeitslage von Managern und Scouts
Filipe: "so eine kategorie wie ueber die creator will ich dass nur fuer
die spicy und dogfather rolle auch ueber manager und scouts gibt ...
ich will dass es so ultra krass gut ist dass die spicy und dogfather
rolle einen kompletten teil haben mit daten ueber die arbeit von den
manager und scout. keine geheimen sachen also termine, chats und
geheime dateien soll auch so bleiben dass keiner."
--- ZUERST DIE KOPFLEISTE ---
Filipe meldete, die Kopfleiste sei bei DogFather "nicht gemacht".
Nachgemessen auf ALLEN 18 Seiten, in allen fuenf Rollen, bei drei
Breiten: einzeilig, Spanne 4 px. Und die neuen Dateien liegen
nachweislich auf dem Server (
|
||
|
DogFatherGit
|
ec55b6c8d3 |
WIP Zentrale-Kachel nach VanVans Werktisch — NOCH NICHT FERTIG
Aufbau steht (Ring links, Titel mittig, Uhr rechts), aber pruef-start-ansicht meldet 3 Befunde am MAUS-LICHT der Kacheln. Gemessen: alter Stand 0 Befunde, dieser Stand 3 — kommt also von hier. Kein JS-Fehler (pageerror/console sind still), also Zeitverhalten: Die zusaetzliche Abfrage /api/zentrale verzoegert vermutlich den Aufbau der Kacheln ueber den Zeitpunkt hinaus, an dem kopf.js lichtFolgen ruft. Ausserdem offen: 2 Schriftgroessen unter 11,5 px (pruef-css-klassen). NICHT ausliefern. |
||
|
DogFatherGitandClaude Opus 5
|
233cd76d78 |
Der Handy-Durchgang: drei echte Bedienfehler, alle vom selben Ursprung
Filipe: "ich will dass du die komplette seite auf dem handy abcheckst.
ich will dass alles perfekt aussieht und bedienbar ist."
DER SCHWERSTE FUND: Auf ZWOELF Seiten war der "Meine Sicht"-Umschalter
nicht bedienbar -- wer darauf tippte, landete im Chat.
Bei 412 px (der haeufigsten Android-Breite ueberhaupt) brach die
Kopfleiste nicht um, der Umschalter wurde auf 50 px zusammengedrueckt,
sein Knopf behielt aber seine 104 px Mindestbreite und lag damit quer
ueber dem Chat-Knopf. Sichtbar war davon nichts.
Und die Ursache steht seit dem 05.09. woertlich im Kommentar daneben:
"Die Rechnung ging genau auf, solange rechts VIER Dinge standen. Mit der
Glocke sind es FUENF, und bei 320 px passte es nicht mehr." Am 06.09.
habe ich den Chat-Knopf dazugesetzt -- SECHS -- und die Schwelle bei 380
gelassen. Derselbe Fehler, eine Position weiter.
Die Lehre ist nicht "380 auf 430 erhoehen"; das waere er ein drittes
Mal, nur mit einer anderen Zahl. Eine feste Schwelle ist eine Rechnung,
die jemand einmal aufgestellt hat und die beim naechsten Knopf still
falsch wird. `flex-wrap: wrap` OHNE Schwelle rechnet nicht, sondern
misst -- es bricht genau dann um, wenn der Platz nicht reicht.
DASSELBE NOCH EINMAL, am anderen Ende: Bei 1280 px brauchte die Leiste
1235 px (Marke 375 + Bedienelemente 844 + Abstand 16) und hatte 1200.
Auch hier war der Chat-Knopf der Tropfen. Sie brach um, sobald das
Skript die Bedienelemente eingehaengt hatte, und schob die ganze Seite
52 px nach unten -- CLS 0,94. Jetzt gibt die MARKE nach (sie darf
gekuerzt werden, ein Knopf nicht), und umgebrochen wird nur noch auf
sehr schmalen Geraeten.
WEITERE ECHTE FUNDE:
* /workspace/api/chat/ungelesen wurde auf JEDER Seite ZWEIMAL geholt:
einmal beim Laden, einmal Millisekunden spaeter beim Aufgehen des
Ereignisstroms. Der 'open'-Zuhoerer war fuer Wiederverbindungen
gedacht und feuerte auch beim ersten Mal.
* Drei Kacheln teilten sich einen Farbton mit einer anderen (18 Farben
auf 21 Kacheln). Filipe wollte ausdruecklich, dass jede ihre eigene
hat. Nicht eine Farbe dazuerfunden -- der ganze Farbkreis ist mit
tools/kachel-farben.mjs neu in 21 geteilt; kleinster Abstand zweier
Nachbarn jetzt 120 Grad (vorher 106). Dabei fiel eine feste 16 in
der Mischschleife auf: Bei 18 Kacheln wurden die letzten beiden nie
mitgemischt.
* Der Agentur-Untertitel wurde auf dem Handy abgeschnitten.
* Ein zugeklappter <details>-Kasten (Kalender-Abo) verdeckte einen
Filter-Chip: Chromium versteckt dessen Inhalt ueber
`content-visibility`, nicht ueber `display` -- die Kaesten behalten
eine Groesse. Dieselbe Falle wie bei den Zeitbloecken, dieselbe
Loesung.
UND DREI PRUEFUNGEN, DIE SELBST FALSCH LAGEN:
* "achtzehn Kacheln" stand als feste Zahl im Test. Eine Pruefung, die
bei jeder neuen Kachel rot wird, erzieht dazu, ihr Rotwerden zu
ignorieren. Sie zaehlt jetzt aus bereiche.js.
* "das Licht der Kalender-Kachel (tuerkis) muss mehr Blau als Rot
haben" -- Wissen von aussen, und nach dem Neurechnen war der
Kalender rosa. Gemessen wird jetzt gegen den Ton der Kachel selbst.
* pruef-workspace-umzug meldete sein Ergebnis in eigenen Worten. Der
Gesamtlauf las daraus NULL Pruefungen und schrieb bei JEDEM Lauf ein
FEHL, obwohl alle 31 Punkte bestanden. Ein Fehlalarm, der immer
kommt, macht den einen echten unsichtbar.
Und weil "BUTTON 'Meine Sicht' verdeckt" mich eine Stunde gekostet hat,
sagen pruef-handy und pruef-tempo jetzt DAZU, was verdeckt und was
springt -- mit Elternkette und Koordinaten. Ein Befund, den man nicht
verorten kann, ist ein halber.
NEU: der Kalender zum Abonnieren (Stufe 3.2). Persoenlicher, jederzeit
widerrufbarer Link fuer Google, Apple und Outlook. 36 Pruefungen, die
das ICS ZURUECKLESEN statt es anzusehen -- entfaltet, entschluesselt,
verglichen. Wichtigster Punkt: Der Weg ohne Anmeldung darf nichts
zeigen, was der Weg mit Anmeldung nicht zeigt.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
c8a4e7628c |
Stufe 1+2: Zahlen ueber das Geschaeft, und eine Fruehwarnung
Der grosse Befund aus dem Plan vom 31.08.2026: Der Workspace organisiert ARBEIT hervorragend, wusste ueber das GESCHAEFT aber nichts. Keine Diamanten, keine LIVE-Tage, keine Verweildauer. Damit hing die ganze Betreuung in der Luft -- der Start-Check bewertete ohne zu messen, der Report fragte "was hat funktioniert" ohne Beleg, das 90-Tage-Ziel war ein Satz statt eines Fortschritts. STUFE 1 -- LEISTUNG Eine Zeile je Creator und TAG (nicht Woche: Feineres laesst sich immer zusammenfassen, Groeberes nie aufteilen). Diamanten, LIVE-Dauer, gueltiger Tag, Zuschauer im Schnitt und in der Spitze, Verweildauer, Schenker, neue Follower -- und eine NOTIZ. Ohne sie sieht man in drei Monaten einen Einbruch und weiss nicht mehr, dass die Person Grippe hatte. DIE VERWEILDAUER IST DIE LEITZAHL (Recherche 06.09.2026): 2026 haengt der Algorithmus alles an der Completion Rate, und sie gehoert als BETRIEBSkennzahl behandelt -- sie soll die naechste Runde steuern, nicht die letzte erklaeren. Jede Zahl kommt mit Vergleich, Verlauf und Einordnung. Eine Zahl ohne diese drei ist eine Eitelkeitszahl: Sie sieht nach Auskunft aus und ist keine, weil man nichts entscheiden kann. Zwei Wege hinein: Schnelleingabe und CSV-Import aus dem offiziellen Export, mit Vorschau vor dem Uebernehmen. STUFE 2 -- FRUEHWARNUNG Sechs benannte Signale (Zahlen fallen, LIVE-Tage brechen weg, lange nicht angemeldet, kein Gespraech, Aufgabenstau, Start-Check haengt) und daraus EIN ruhiger Satz: "Bei Nora wuerde ich diese Woche nachfassen." BEWUSST KEIN SCORE. Eine Note von 1 bis 100 wirkt objektiv und ist es nicht; sie verfuehrt dazu, Menschen nach einer Zahl zu behandeln. Am Score kann man nichts tun, am Signal schon. Deshalb Saetze statt Punkte, und jedes Signal einzeln nachvollziehbar. Ein CREATOR sieht die Fruehwarnung nicht: Das ist eine Arbeitsgrundlage fuer die Betreuung, keine Mitteilung an die betroffene Person. ZWEI ECHTE FEHLER, VON DER PRUEFUNG GEFUNDEN 1. ZAHLENFORMAT, Faktor tausend daneben. "1.250" wurde als 1,25 gelesen und "1,234" als 1,234. Die Regel "das letzte Trennzeichen ist das Dezimalzeichen" liefert bei nur EINEM Trennzeichen fuer beide Faelle das Falsche -- und die Zahl sieht danach trotzdem plausibel aus. Jetzt entscheidet, wie viele Ziffern dahinter stehen: genau drei heisst Tausendertrenner. 2. DIE ZIELE-ROUTE WURDE VERSCHLUCKT. Express nimmt die erste passende Route, und `:tag` passt auch auf "ziele" -- ein PUT auf .../ziele landete in der Tages-Route und scheiterte am Datumsmuster. Die Meldung sagte "ungueltig", was auf die Zahlen deutet, nicht auf den Weg. Reihenfolge getauscht. Beides waere still gewesen: falsche Zahlen sehen richtig aus, und ein Ziel, das sich nicht setzen laesst, probiert man zweimal und laesst es dann. pruef-leistung.mjs: 47 Punkte, darunter jede Rechnung einzeln nachgerechnet (Durchschnitte ohne Tage ohne Wert, Prozent von null, Wochengrenzen), Import zweimal eingelesen, deutsche und englische Zahlenformate, Rechte, und die Gegenprobe, dass die Fruehwarnung bei Unauffaelligkeit SCHWEIGT. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
9dc35f5da6 |
Chat wieder einhaengen -- die Datei ist jetzt da
Nachtrag zu |
||
|
DogFatherGitandClaude Opus 5
|
8e3eccc7a8 |
Alte Workspace-Adresse abgeschaltet statt weitergeleitet
Auf Filipes Wunsch: dogfather-universe.com/workspace/ soll nicht mehr existieren, er gibt den neuen Link selbst an Creator und Scouts weiter. Vorher stand dort eine Weiterleitung - die haette die alte Adresse auf unbestimmte Zeit am Leben gehalten. Der Server antwortet dort jetzt mit 410 Gone. Beides - 404 und 410 - heisst "gibt es hier nicht"; 410 sagt zusaetzlich "gab es, ist absichtlich weg, kommt nicht wieder". Genau der Sachverhalt. Suchmaschinen nehmen die Adresse dadurch schneller heraus, und in einem Protokoll ist ein 410 sofort als gewollt erkennbar, waehrend ein 404 immer nach Versehen aussieht. Statt einer nackten Fehlermeldung kommt eine kurze Hinweisseite mit der neuen Adresse. Wer hier landet, hat einen alten Link oder eine alte Verknuepfung und soll erfahren, wohin der Workspace gezogen ist, statt vor einem leeren Fenster zu sitzen. Bewusst OHNE Verweis zum Anklicken, damit niemand aus Versehen ein neues Lesezeichen auf den alten Weg setzt. Schnittstellen-Aufrufe unter /workspace/api/ bekommen JSON statt HTML - ein alter, noch offener Browser-Tab wuerde sonst die Hinweisseite als Daten zu lesen versuchen und einen unverstaendlichen Fehler zeigen. Die Pruefung deckt weiterhin 21 Faelle ab und ist mitgezogen: Der gefaehrlichste Fall heisst jetzt nicht mehr "Endlosschleife", sondern "die neue Adresse mit abschalten" - wer nicht auf den Hostnamen prueft, sperrt den Workspace fuer alle aus. Alle gruen, Gegenprobe schlaegt an. Diesmal vor dem Commit den Diff Datei fuer Datei kontrolliert - beim letzten Mal hatte ich hier eine fremde uncommittete Zeile mitgenommen und damit die Website fuer zwei Minuten abgeschossen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
09a4cfdeab |
AUSFALL BEHOBEN: versehentlich mitcommitteten Import zurueckgenommen
Die Website war ab 16:27 unerreichbar (HTTP 502, 29 Neustartversuche).
Ursache war mein Commit
|
||
|
DogFatherGitandClaude Opus 5
|
58b8ef233a |
Creator Workspace zieht auf eine eigene Adresse um
Der Workspace laeuft ab sofort auf workspace.dogfather-universe.com. Die
alte Adresse dogfather-universe.com/workspace/ leitet dorthin weiter.
Grund: Chrome laesst neben der Hauptseite, deren Bereich "/" die ganze
Domain umfasst, keine zweite App auf derselben Adresse zu. Unter dem alten
Pfad liess sich der Workspace nur als Verknuepfung ablegen, nie als
richtige App installieren - im Menue stand "Oeffnen in DOGFATHER
UNIVERSE" statt "Seite als App installieren". Das ist kein Fehler,
sondern Absicht (w3c/manifest Nr. 1180: verschachtelte Bereiche auf einem
Ursprung sind "strongly not recommended"). Auf der neuen Adresse hat
Filipe die App erfolgreich installiert.
Der PFAD /workspace/ bleibt erhalten. An ihm haengen 150 Server-Routen,
107 API-Aufrufe und 26 Server-Dateien - ihn wegzuschneiden waere ein
grosser Umbau ohne Gewinn, denn der Konflikt entsteht durch die
gemeinsame ADRESSE, nicht durch den Pfad. Dadurch musste am Code nichts
weiter geaendert werden.
Die Entscheidung steht in einer eigenen Datei (workspace-umzug.js), weil
sie zwei Stellen hat, an denen ein Denkfehler teuer waere und die man
einer Bedingung nicht ansieht:
1. ENDLOSSCHLEIFE - derselbe Dienst bedient beide Adressen. Ohne
Hostpruefung leitet die neue Adresse auf sich selbst, und der
Workspace waere sofort nach dem Neustart fuer alle unerreichbar.
2. PRAEFIX-IRRTUM - "faengt an mit /workspace" trifft auch
/workspaceXYZ und /workspace-alt.
Als eigene Funktion ist beides pruefbar, ohne den Server zu starten:
pruef-workspace-umzug.mjs deckt 21 Faelle ab (alte/neue Adresse, mit und
ohne www, Gross-/Kleinschreibung, Portangabe, lokale Testadressen, beide
Praefix-Fallen). Alle gruen. Gegenprobe gemacht: Baut man die
Endlosschleife absichtlich ein, meldet die Pruefung 3 Fehler; baut man den
Praefix-Irrtum ein, meldet sie 2. Sie kann also auch "nein" sagen.
Bewusst 302 und nicht 301: Ein 301 wird vom Browser dauerhaft gemerkt und
laesst sich praktisch nicht zurueckholen - waere an der Umleitung etwas
falsch, waere die alte Adresse fuer jeden, der sie einmal aufgerufen hat,
dauerhaft unbrauchbar.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
627f710d71 |
Aufgaben abbrechen, Teilnehmerwahl fuer alle, Benachrichtigungen
Zwei Wuensche vom 05.09.2026, dazu drei Fehler, die dabei ans Licht kamen.
ABBRECHEN (Wunsch: "in jedem status die aufgaben auch abbrechen koennen,
nur ich die manager und scouts")
Neuer Status mit Pflicht-Grund, aus jedem der vier Status heraus.
Festgehalten wird auch, WO die Aufgabe stand -- "im Review abgebrochen"
ist eine andere Aussage als "nie angefangen", und das Wiederaufnehmen
geht dorthin zurueck statt nach "offen".
Eigener Weg statt "abgebrochen" in der Statusliste: Dort entscheidet
darfAendern(), und das laesst auch den zustaendigen Creator aendern.
Der gewoehnliche PATCH kann diesen Zustand deshalb gar nicht erreichen
-- auch nicht fuer DogFather, sonst waere die Grund-Pflicht umgehbar.
Abgebrochenes steht in einem zugeklappten Bereich unter dem Brett, nicht
als fuenfte Spalte: Am Handy waeren dann alle fuenf unlesbar schmal.
Verschwinden darf es nicht, sonst waere der Abbruch ein Loeschen mit
Zwischenschritt.
Die Tabelle musste dafuer getauscht werden (SQLite kann CHECK nicht
aendern). Vorher auf einer Kopie durchgespielt: 40 von 40 Aufgaben,
Inhalte, Verweise und Indizes geprueft, Gegenprobe zeigt, dass der CHECK
noch lebt.
TEILNEHMERWAHL (Wunsch: "das soll viel besser aussehen und fuer jeden
verfuegbar sein")
Auf dem Bildschirm klebten die Namen aneinander: "DogfatherDogFather".
Ursache war, dass kalender.html das Stylesheet mit diesen Klassen nie
eingebunden hat -- sie standen in dateien.css. Vierzig gruene Pruefungen
zur Teilnehmerwahl hatten das nicht gemerkt, weil keine je gefragt hat,
ob es AUSSIEHT wie gedacht.
Jetzt eigene Klassen im eigenen Stylesheet, nach Rollen gruppiert: Die
Rolle steht einmal als Ueberschrift statt neunmal am Namen. Damit ist
das Kleben an der Wurzel weg, nicht zugepflastert.
"Fuer jeden" war mehr als ein hidden zu entfernen: darfEintragen() haette
einem Creator nur sich selbst erlaubt. Er haette seinen Scout gesehen,
angeklickt, und der Server haette ihn still weggelassen -- ein Knopf, der
nichts tut. einladbareIds() schaut jetzt in beide Richtungen, bewusst
getrennt von /api/personen: Wer die erweitert, gibt einem Creator
nebenbei die Moeglichkeit, seinem Scout Aufgaben zuzuweisen.
BENACHRICHTIGUNGEN (Wunsch: "sowas, und dass es perfekt funktioniert
fuer jeden")
Web Push nach RFC 8291/8292, ohne fremde Abhaengigkeit. Der Knopf sagt
in jeder Lage die Wahrheit, auch die unbequemen: abgelehnt (mit dem
Hinweis, wo man es zuruecknimmt), iPhone im Reiter (mit Anleitung),
Browser ohne Push. Ein Knopf, der bei abgelehnter Berechtigung nur
nichts tut, ist der sichere Weg zu "das funktioniert nicht".
DREI FEHLER, DIE DABEI AUFFIELEN
1. Ein defekter Zugangsdatensatz sperrte ALLE einer Rolle aus. Wirft
hashe() bei einer Person, flog die ganze Anmeldung in den catch: 503
"nicht verfuegbar" fuer jeden mit dieser Rolle. Aufgefallen durch
einen eigenen Testfehler. Jetzt wird die defekte Person uebersprungen
und laut protokolliert; die Gegenprobe zeigt, dass ein falscher Code
weiterhin abgelehnt wird.
2. Die Glocke sprengte die Kopfleiste -- zweimal. Bei 320 px lag die
Lupe des Suchknopfes auf dem Sicht-Umschalter (ein Knopf, der auf 12
Seiten ins Leere tippt), bei 768 px wurde der Abmelden-Knopf bis zu
15 px aus dem Bild geschoben, weil die Textgrenze auf 760 stand und
ein Tablet 768 hat. Nachgewiesen durch Messen mit und ohne Glocke,
nicht durch Vermuten.
3. .block__frage war viermal gestaltet und stand auf einer Seite, die
keine dieser Dateien laedt -- derselbe Fehler wie bei der
Teilnehmerwahl. Gefunden von der neuen Klassenpruefung beim ersten
Lauf.
NEUE PRUEFUNGEN
pruef-css-klassen jede gestaltete Klasse muss auf ihrer Seite ankommen
(unterscheidet Struktur-Anker von echtem Verlust)
pruef-dabei-optik die Wahl im Browser, an den echten Pixeln
pruef-abbrechen Umstellung auf einer Kopie, Rechte, Rueckweg
pruef-abbrechen-optik Knopf, Dialog, Bereich, Handy
pruef-glocke Zustaende, An/Abmelden, jede Rolle
pruef-push(-weg) Rechnung gegen die RFC-Vektoren, Zustellung
pruef-struktur prueft jetzt zusaetzlich, ob sich jedes Server-Modul als
ESM laden laesst. node --check auf einer .js-Datei prueft als CommonJS
und meldete "ok", waehrend der Import scheiterte.
Gesamtlauf: 55 von 55 Dateien, 1973 von 1973 Punkten.
Was NICHT geprueft werden konnte und deshalb dasteht: Der Schritt
"Browser holt eine Adresse beim Push-Dienst" braucht eine Verbindung zu
Googles FCM, die ein Pruef-Browser nicht hat. Die Pruefung misst das
zuerst und meldet es als dritten Ausgang, statt gruen zu sein.
Verschluesselung und Zustellung sind getrennt geprueft; diese eine
Strecke beweist sich erst auf dem Server.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
51c3d4402b |
Audit des Creator Workspace, App-Symbole fuer alle Apps der Domain
AUDIT (Auftrag: vollstaendiger Durchgang, Fehler direkt beheben)
Ausgangslage waren 40 Pruefungen mit 1616 Einzelpunkten, alle gruen.
Acht neue Pruefungen kamen dazu; sie haben gefunden, was die alten nicht
sehen konnten.
Der schwerste Fund: Die Zugangsschranke verglich req.path EXAKT gegen
eine Liste. Express raeumt Punkt-Segmente selbst weg, mehrfache
Schraegstriche aber nicht. Damit kam //workspace/start.html OHNE
Anmeldung mit HTTP 200, und ein Creator bekam ueber
/workspace//personen.html die Verwaltungsseite. Die DATEN waren nie
betroffen (nachgemessen: 404 bzw. 401). Behoben durch Normalisierung
UND eine Umkehr der Logik -- jetzt ist jede .html geschuetzt ausser der
Anmeldeseite, statt nur die in der Liste. Eine vergessene neue Seite
steht damit nicht mehr versehentlich offen.
Weiter behoben:
* Kaputter/abgebrochener Rumpf ergab 500 in HTML statt 400 in JSON --
die Oberflaeche ruft ueberall a.json() und lief in einen zweiten
Fehler; der Knopf hing ohne Meldung.
* POST /zustand/sichern war der einzige von 60 schreibenden Wegen
ohne Herkunftspruefung.
* workspace-sicherung.js gab interne Pfade in Fehlermeldungen nach
aussen; alle 23 anderen Module antworten neutral.
* admin_notiz war als einziges von 14 Feldern ohne <label>.
* Der aktive Filter hatte keinen sichtbaren Fokus (CSS-Spezifitaet
0,3,0 schlug 0,2,0) -- genau der Knopf, auf dem man steht.
* h1 -> h3 ohne Zwischenstufe auf zwei Seiten.
* HSTS ging auch ueber http mit (RFC 6797, 7.2 verbietet das).
* upgrade-insecure-requests galt auch auf 127.0.0.1 -- dadurch war
WebKit/Safari ueberhaupt nicht pruefbar, also der Browser, den
jedes iPhone benutzt.
* pruef-grosscheck las readdirSync(".") und pruefte aus server/
gestartet NULL oeffentliche Seiten -- meldete aber "ok".
Neue Pruefungen: struktur, schranke, haerte, alle-wege,
barrierefrei-workspace, breiten, tempo-workspace, browser.
Jede mit Gegenprobe und mit der geprueften Anzahl in der Bedingung.
Vier davon sind beim Bauen durch die eigene Gegenprobe aufgeflogen und
haetten sonst dauerhaft gruen gemeldet, ohne etwas zu messen.
APP-SYMBOLE (Wunsch: alle Apps der Domain, jede anders, ausser
safeaddress)
Zehn Apps, zehn Stile, zehn in OKLCH gerechnete Farben. Zusammen haelt
sie dasselbe Logo, dieselbe Eckenrundung und eine gemeinsame gedeckte
Farbreihe. Beim Bauen wird gemessen, ob sich das Logo vom Grund abhebt
(19 bis 58 Helligkeitsstufen).
Dabei aufgefallen: Das Kundenportal hatte kein eigenes Manifest und
trug Namen und Symbol der Webdesign-Seite. Der Workspace hatte gar
keins und war als App nicht installierbar. Beide haben jetzt eins.
Geaendert wurde AUSSCHLIESSLICH das Symbol. Ein Zwischenstand hatte
auch die Themenfarben gesetzt; das war mehr als bestellt und wurde
zurueckgenommen.
Werkzeuge: tools/logo-freistellen.mjs, tools/app-symbole.mjs,
tools/app-symbole-einbinden.mjs -- alles im Browser gerechnet, kein
Bildprogramm, keine neue Abhaengigkeit.
Gitea und Nextcloud sind bereits live und nachgeprueft.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
23429627ef |
Termine, die von allein weiterlaufen -- bis man sie abstellt
Wunsch: "ich will dass ich da im kalender auch sachen machen die jede
woche jeden monat automatisiert immer weiter laufen so wie ich es
auswaehle bis ich es selber deaktiviere. aktiviere diese option fuer
jeden."
Acht Rhythmen (taeglich, werktags, woechentlich, alle zwei Wochen,
monatlich am Datum, am Monatsletzten, am n-ten Wochentag, jaehrlich),
wahlweise mit Enddatum oder ohne Ende. Fuer JEDE Rolle -- Creator und
Scouts legen sie fuer sich selbst an, mit denselben Grenzen wie beim
einzelnen Termin.
WARUM ECHTE TERMINE UND KEINE GERECHNETEN AUSPRAEGUNGEN
Der naheliegende Weg waere gewesen, die Wiederholung nur beim Anzeigen
auszurechnen. Das waere ein stiller Ausfall geworden: ACHT andere Stellen
lesen die Tabelle termine direkt -- Calls, Protokolle, Berichte,
Hinweise/Ampel, Suche, Aufgaben ("naechster Termin"), Uebersicht und die
Startseite. In all diesen Ansichten haette schlicht nichts gestanden, und
aufgefallen waere es erst Monate spaeter. Stattdessen macht ein
Nachfueller aus der Regel echte Zeilen (Horizont 180 Tage) -- jedes andere
Modul sieht sie mit, ohne dass dort eine Zeile geaendert werden musste.
Beim geplanten ICS-Abo gilt dasselbe.
KEIN ZEITGEBER. Der Nachfueller laeuft beim Serverstart, beim Anlegen und
Aendern und beim Oeffnen des Kalenders (dort hoechstens alle fuenf
Minuten). Er ist idempotent. Ein Cron waere eine weitere Sache gewesen,
die stillschweigend ausfallen kann.
WAS BEIM ABSTELLEN PASSIERT: Vergangene Termine und alles, was jemand von
Hand angefasst hat (verschoben, umbenannt, abgehakt), bleibt stehen. Nur
die unberuehrte Zukunft wird aus dem Kalender genommen. Wer einen
einzelnen Tag loescht, streicht nur diesen einen -- der Tag wird als
Ausnahme vermerkt, sonst legte der Nachfueller ihn wieder an.
ZEITUMSTELLUNG: Gerechnet wird auf reinen Datumstexten in UTC-Mittag, die
Uhrzeit wird als Text angehaengt. 18:00 bleibt dadurch 18:00 und wandert
im Oktober nicht auf 17:00.
DIE SICHTBARKEITSREGEL STEHT JETZT NUR NOCH EINMAL (workspace.js,
termineSichtbar) statt zweimal fast gleich. Zwei Fassungen waeren
auseinandergelaufen -- und dann haette eine Wiederholung jemandem etwas
gezeigt, was der einzelne Termin ihm verbirgt.
IN DER OBERFLAECHE beschriften sich die Rhythmen nach dem gewaehlten
Datum ("jeden Dienstag", "jeden Monat am letzten Dienstag") statt
abstrakt ("woechentlich"), inklusive des ehrlichen Hinweises, dass "jeden
31." den Februar auslaesst. Darunter steht der ganze Satz in Worten. Eine
neue Leiste "Laeuft von allein" zeigt alle laufenden Wiederholungen mit
Abstell-Schalter -- was von selbst weiterlaeuft, muss man sehen koennen.
GEPRUEFT: 67 Pruefungen (server/pruef-serien.mjs), darunter von Hand
nachgeschlagene Datumsangaben fuer jeden Takt (der letzte Dienstag im
Dezember 2026 ist der 29., nicht der 22.; der 29. Februar nur in
Schaltjahren) und vier GEGENPROBEN, die beweisen, dass die Pruefungen
auch "nicht in Ordnung" sagen koennen. Die Anzahl der Pruefungen steht in
der Bedingung, nicht nur im Meldetext. Bestehende Pruefungen unveraendert
gruen: Kalender 84, Sicht 48, Startansicht 133, Protokoll 52, Ampel 47,
Handy 50, Aufgabenbrett 44, Sprung 43, Personen-Loeschen 40, Uebersicht
33, Workspace-Seiten 32, Formulare 19, Betreuung 18, Grosscheck 15,
Lesbarkeit 14.
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
|
9267797d1d |
Feste Checklisten statt Vorschlaege - in allen vier Bereichen
"Die neuen Sachen in der LIVE-Analyse soll der Creator FEST sehen, auch
schoen kategorisiert, und der Ansprechpartner soll anklicken koennen,
wenn er findet, dass der Creator was verbessern sollte."
DER UMBAU. Vorher waren die Punkte Vorschlaege zum Uebernehmen: Man
holte sie sich und bekam einen eigenen Eintrag. Das war falsch gedacht.
Eine Checkliste, die man erst anfordern muss, ist keine Checkliste --
und schlimmer: Zwei Creator haetten unterschiedliche Listen gehabt, je
nachdem wer sich was geholt hat. Genau das macht einen Vergleich
unmoeglich, und um Vergleich geht es bei einer Betreuung.
Jetzt stehen dieselben Punkte fuer JEDEN fest da, gruppiert:
LIVE 21 Punkte -- vor, waehrend, nach der Sendung
Community 14 Punkte -- Moderation vorbereiten, aufbauen, wenn es kippt
Technik 12 Punkte -- Einrichtung, Ausfall, was geholfen hat
Content 13 Ideen -- nach Saeule (70/20/10) statt nach Ablauf
Jede Gruppe hat einen Satz, der erklaert, wofuer sie da ist. Eine
Ueberschrift allein sagt das nicht.
Was sich je Creator unterscheidet, ist nur der STAND -- und den setzt
die Betreuung: "Passt so" oder "Verbessern". Ein Creator kann sich nicht
selbst bewerten; koennte er es, stuende alles auf gruen. "Verbessern"
verlangt einen Satz, WAS zu verbessern ist -- eine Bewertung, mit der er
nichts anfangen kann, ist nicht streng, sondern nur entmutigend.
Der Creator sieht alles: die Stufe, den Grund, den Namen und den
Zeitpunkt. Und er kann an JEDEM Punkt antworten -- das ist der Kanal,
ueber den er ueberhaupt etwas sagen kann.
Oben steht eine Bilanz in einer Zeile: wie viele passen, wie viele sind
zu verbessern, wie viele hat noch niemand angesehen. Das ist die Frage,
die beide Seiten zuerst haben.
STABILE SCHLUESSEL statt Positionen. Ein Stand haengt am Schluessel des
Punktes ("ton-geprueft"), nicht an seiner Nummer. Haenge er an der
Position, waere beim Einfuegen eines Punktes in der Mitte jede Bewertung
dahinter am falschen Punkt -- und niemand wuerde es merken, weil beides
plausibel aussieht. 64 Punkte haben jetzt einen.
"Offen" loescht den Stand, statt ihn auf "offen" zu setzen: Ein
Datensatz, der nichts aussagt, ist Ballast.
ZWEI EIGENE FEHLER, VON DEN PRUEFUNGEN GEFUNDEN:
1. DAS CSS LAG IN DER FALSCHEN DATEI. Ich hatte es in content.css
geschrieben -- bereich.html laedt die gar nicht. Die Punkte standen
auf drei von vier Seiten nackt und ohne Flaeche da. Es ist derselbe
Fehler wie im August bei .knopf-still, .schalter und .kopf-zeile, und
es gibt seitdem eine Warnung dazu in start.css. Sie hat nichts
genutzt, solange keine Pruefung sie nachhielt.
Jetzt gibt es eine: Sie misst, ob eine Karte wirklich eine Kante und
Polsterung hat -- nicht nur, ob das Element existiert. Gegenprobe
gemacht: Klasse umbenannt, Pruefung meldet "STIL FEHLT".
2. Ein Betreuer sah beim Oeffnen keine Bewertungsknoepfe, weil noch kein
Creator gewaehlt war -- und musste erst raten, dass er oben jemanden
auswaehlen soll. Jetzt nimmt der Server den ersten betreuten Creator,
wenn keiner angegeben ist.
Die alte Oberflaechenpruefung fuer den Vorschlaege-Block wurde entfernt
statt angepasst: Sie verlangte etwas, das es nicht mehr gibt. Eine
dauerhaft rote Pruefung ist schlimmer als keine -- man gewoehnt sich
daran, und beim naechsten echten Fehler sieht niemand hin.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
372a0eb95a |
Ampel und Rueckmeldungen - bewerten darf nur die Betreuung
Der Wunsch: "der Creator sieht, ob es gut ist oder schlecht. Und wenn nicht gut, dann muss es verbessert werden -- und nur der Ansprechpartner kann das aendern. Die Creator koennen nur Nachrichten hinterlassen zum Kommunizieren." ZWEI GETRENNTE DINGE, und sie getrennt zu halten ist der ganze Punkt: DIE AMPEL ist eine Beurteilung. Sie gehoert dem Betreuer, und nur er setzt sie. Koennte ein Creator sich selbst auf gruen stellen, waere sie wertlos -- dann stuende ueberall gruen. Der Server lehnt es mit 403 ab und sagt dabei, wer es kann. DIE NACHRICHT ist ein Gespraech. Sie gehoert beiden. Ein Creator, der auf eine Bewertung nicht antworten kann, bekommt ein Urteil statt einer Betreuung. DREI STUFEN, NICHT FUENF. Eine Zahl von 1 bis 5 klingt genauer und ist es nicht: Niemand kann den Unterschied zwischen 3 und 4 erklaeren, und am Ende steht ueberall die 3. Die Frage lautet "reicht das schon?", und darauf gibt es drei ehrliche Antworten -- passt so, noch verbessern, noch nicht angesehen. "NOCH VERBESSERN" VERLANGT EINE BEGRUENDUNG. Eine Bewertung, mit der der Creator nichts anfangen kann, ist nicht streng, sondern nur entmutigend. Der Server lehnt sie ohne Grund ab; die Oberflaeche fragt deshalb gleich danach, statt hinterher eine Fehlermeldung zu zeigen. "Passt so" braucht keinen -- da gibt es nichts zu erklaeren. Die Stufe steht IMMER an der Karte, auch fuer den Creator, auch wenn sie "noch nicht angesehen" lautet. Er soll sehen, wo er steht, ohne fragen zu muessen. Der Grund steht daneben in voller Breite, nicht in einer Ecke. FREMDE NACHRICHTEN BLEIBEN STEHEN -- auch fuer DogFather. Ein Gespraech nachtraeglich umzuschreiben waere schlimmer, als eine unbedachte Aeusserung stehen zu lassen. Wer etwas richtigstellen will, schreibt eine neue. VORLAGEN AUCH FUER COMMUNITY UND TECHNIK (Screens 11 und 12): 14 Moderations-, Aktions- und Konfliktpunkte, 12 Technikpunkte. Ton steht vorn, weil schlechter Ton der Grund Nummer eins ist, warum Leute einen Stream verlassen. Die drei Bereiche laufen jetzt ueber EINE Zuordnung statt drei fast gleicher Bloecke -- sonst weicht der dritte irgendwann ab. Die beiden alten Zweige wurden entfernt: Toter Code, den man stehen laesst, wird beim naechsten Mal fuer lebenden gehalten. Die Ampeln einer ganzen Liste kommen in EINER Abfrage. Zwanzig Eintraege einzeln zu fragen waeren zwanzig Anfragen, und die Seite ruckelte sichtbar beim Aufbau. Die Sichtbarkeitspruefung laeuft dabei je Eintrag, nicht einmal pauschal -- ein fremder Eintrag taucht auch in der Sammelabfrage nicht auf. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5960f6e3c4 |
Unterweisungen mit beidseitiger Bestaetigung - und einer echten Sperre
Der Wunsch: "jeder Scout, Manager oder DogFather muss mit seinen
Creatorn die PDFs durchgehen, und beide druecken dann auf verifiziert,
so dass wir den Beweis haben -- und das ist danach auch nicht mehr zu
aendern."
Das ist kein Haekchen, das ist ein NACHWEIS. Wer so etwas baut, muss
drei Fragen beantworten, sonst ist er wertlos:
WER hat bestaetigt? Beide Seiten getrennt, mit Name, Zeitpunkt und IP.
Eine einzelne Bestaetigung reicht nicht -- "ich habe es ihm gezeigt" und
"er hat es mir gezeigt" sind zwei verschiedene Aussagen, und erst
zusammen ergeben sie einen Beweis. Bestaetigt nur einer, steht die
Unterweisung sichtbar als HALB da, in einer eigenen warnenden Farbe.
Diese Zwischenstufe sichtbar zu machen ist der Punkt: Ein Nachweis, bei
dem nur einer unterschrieben hat, sieht sonst aus wie fertig -- und man
merkt es erst, wenn jemand danach fragt.
WORAUF genau? Nicht auf "die Regeln", sondern auf eine bestimmte Datei.
Beim Bestaetigen wird der SHA-256 der PDF-Datei mitgespeichert. Tauscht
spaeter jemand die Datei aus, passt der Fingerabdruck nicht mehr, und
die Seite sagt das auch ("Das Dokument wurde seit der Bestaetigung
ausgetauscht"). Ohne diesen Wert waere die Bestaetigung ein Zettel ohne
Bezug.
IST ES UNVERAENDERT? Eine abgeschlossene Bestaetigung laesst sich nicht
mehr aendern und nicht loeschen -- und zwar nicht, weil der Code es
nicht anbietet, sondern weil die DATENBANK es ablehnt. Zwei Trigger mit
RAISE(ABORT). Ein Schutz, der nur im Code steht, ist beim naechsten
neuen Weg zur Datenbank wieder weg.
DER VOLLZUG WURDE DURCHGESPIELT. Aus RunOne stammt die Lehre, dass ein
Weg, den man nicht rueckgaengig machen kann, tagelang live sein und NIE
gelaufen sein kann. Die Pruefung bestaetigt deshalb wirklich, schliesst
ab, und versucht dann eine Aenderung -- ueber die Schnittstelle UND
direkt auf der Datenbank. Beide werden abgelehnt.
Und die GEGENPROBE dazu: Der Trigger wird entfernt, dieselbe Aenderung
versucht -- sie geht durch -- und der Trigger wieder gesetzt. Eine
Sperre, die man nicht hat scheitern sehen, ist keine Sperre.
Der Server entscheidet anhand der ROLLE, welche Seite gesetzt wird --
nicht der Absender. Sonst koennte ein Creator die Bestaetigung seines
Betreuers eintragen, und der ganze Nachweis waere wertlos. Eine bereits
gesetzte Seite wird nie ueberschrieben; ein Datum laesst sich also auch
nicht nachtraeglich verschieben.
Die Dokumente kommen aus der Wissens-Bibliothek, es gibt keinen zweiten
Upload-Weg. Sonst gaebe es Dateien, die nur hier existieren -- und
niemand wuesste, welche Fassung die richtige ist. Eine Unterweisung wird
nie geloescht, nur abgeschaltet: Die Nachweise haengen daran.
EIN EIGENER FEHLER, VON DER BROWSERPRUEFUNG GEFUNDEN: Der Aufruf der
Zusatzbloecke stand NACH einem return. laden() steigt frueh aus, wenn
die Liste leer ist -- und dann wurden Vorlagen und Unterweisungen nie
gebaut. Also ausgerechnet auf der leeren Seite, fuer die sie gedacht
sind. Jetzt stehen sie in einem finally.
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
|
299ef0d506 |
Eigenes Profil fuer jeden - mit Bild und Kanaelen
SCREEN 1: Jeder im Workspace hat jetzt seinen eigenen Steckbrief -- Creator, Scout, Manager und DogFather gleichermassen. Ein Bild, ein Satz ueber sich, und die Kanaele, auf denen er unterwegs ist. Er steht ganz oben auf profil.html, ueber der Creator-Akte; die ist etwas anderes (die fuehren die Betreuer, den Steckbrief fuehrt man selbst). Das Bild erscheint sofort ueberall: in der Kopfleiste jeder Seite und in der Begruessung. /api/ich liefert es deshalb gleich mit -- das spart auf jeder Seite eine zweite Abfrage und verhindert, dass die Plakette erst als Buchstabe erscheint und dann umspringt. Faellt das Bild aus, steht der Buchstabe da: Er wird nicht ersetzt, sondern liegt darunter. WARUM KEINE ECHTE TIKTOK-ANMELDUNG. "Mit TikTok verbinden" klingt nach OAuth. Das waere: ein Entwicklerkonto mit App-Freischaltung, eine Pruefung durch TikTok (Wochen, widerrufbar), je Person ein Zugriffstoken, das ablaeuft, erneuert werden muss und -- wenn es abhandenkommt -- fremden Zugriff auf ein fremdes Konto bedeutet. Dafuer bekaeme man Follower-Zahlen. Gebraucht wird hier aber "Wer ist das, und wo finde ich ihn?". Dafuer genuegt der oeffentliche Name. Gespeichert wird deshalb NUR das Handle -- kein Token, kein Passwort, nichts, was abhandenkommen kann. Daraus wird ein Verweis auf den Kanal. Vier Kanaele: TikTok, Instagram, YouTube, Twitch. Sollen spaeter echte Zahlen dazukommen, ist das ein eigenes Vorhaben -- der Name hier bleibt dann trotzdem richtig. Eingefuegt werden darf, was Leute wirklich in der Zwischenablage haben: "@name", "https://www.tiktok.com/@name" oder der Name allein. Alles wird auf den Namen zurueckgefuehrt, statt eine Fehlermeldung zu zeigen. SICHERHEIT beim Bild -- die drei Stellen, an denen Profilbilder typischerweise scheitern: 1. Der Typ wird an der SIGNATUR der Datei geprueft, nicht am Content-Type, den der Absender behauptet. Ein umbenanntes SVG mit Skript darin kaeme sonst durch und liefe im Namen der Domain -- mit der Sitzung des Betrachters. 2. Auf der Platte bekommt jede Datei einen Zufallsnamen. Kein Name kann Pfade verlassen oder etwas ueberschreiben. 3. Ausgeliefert mit nosniff und einer eigenen, alles verbietenden Inhaltsregel. Das Bild liegt als Datei neben der Datenbank, nicht darin: Bilder in SQLite blaehen jede Sicherung auf, und die laeuft jede Nacht. Niemand schreibt einem anderen ins Profil -- auch DogFather nicht. Ein Satz ueber sich und der eigene Kanalname gehoeren der Person. Wer wen SEHEN darf, folgt der bekannten Regel: Leitung alle, Scout seine Creator, Creator sich und seine Betreuer. Fremde Profile sind 404, nicht 403. ZWEI FUNDE DURCH DIE PRUEFUNG: - Der TikTok-Link, den die App beim Teilen kopiert, endet auf "?lang=de&is_from_webapp=1". Der wurde abgelehnt: "sieht nicht richtig aus" -- obwohl es der offizielle Link ist. Jetzt werden Parameter und Anker mit abgeschnitten. - Ein zu grosses Bild ergab "500 Serverfehler" statt einer Ansage. Der PayloadTooLargeError lief bis in die allgemeine Fehlerbehandlung durch. Jetzt 413 mit dem Satz, wie viel erlaubt ist. Von Hand haette das vermutlich nie jemand probiert. Vor der Schemaaenderung wurde eine geprueft vollstaendige Sicherung gezogen (VACUUM INTO, Integritaet ok, 6 Personen). 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]>
|
||
|
DogFatherGitandClaude Opus 5
|
17c605b93d |
Sicherung: laeuft von allein, und ein stiller Ausfall faellt auf
Filipe zu Recht: "wieso soll ich diesen Befehl einmal die Woche eingeben,
ich will einmal und dass es dann alleine laeuft". Ein Befehl, den man
selbst eintippen muss, wird irgendwann vergessen -- und zwar genau dann,
wenn er zaehlt.
tools/sicherung-einrichten.ps1 legt eine Windows-Aufgabe an: taeglich
statt woechentlich (der Lauf dauert Sekunden, bei woechentlich waere die
Kopie im schlimmsten Fall sechs Tage alt), 13:30 statt nachts (der
Rechner laeuft nicht durch), und mit StartWhenAvailable -- war der
Rechner aus, holt Windows den Lauf beim naechsten Hochfahren nach. Ohne
diesen Schalter fiele jeder verpasste Termin ersatzlos aus. Braucht keine
Administratorrechte und macht am Ende gleich einen Probelauf: eine
Einrichtung, die man nicht ausprobiert, ist eine Vermutung.
Damit entsteht aber ein neues, schlimmeres Problem: Wenn die Aufgabe
still klemmt oder der Rechner wochenlang aus ist, merkt es NIEMAND. Man
glaubt, man haette eine Kopie ausser Haus, und hat sie nicht. Deshalb
meldet sich das Abholskript nach jedem Lauf beim Server zurueck, und die
Automationen-Seite zeigt, wie alt die Kopie ist -- nach zehn Tagen wird
sie auffaellig.
Die Rueckmeldung laeuft ueber einen eigenen langen Schluessel, nicht ueber
einen Zugangscode: Das Skript laeuft unbeaufsichtigt und muesste einen
Code sonst dauerhaft auf der Platte halten. Der Schluessel kann NUR einen
Zeitstempel setzen -- nichts lesen, nichts aendern. Verglichen wird
zeitunabhaengig.
Dabei eine unauffaellige Falle gefunden: In workspace-aufgaben.js steht
`aufgabenRouter.use("/workspace/api", angemeldet)` -- eine Schranke ueber
JEDEN Pfad unter /workspace/api, nicht nur die eigenen. Alle spaeter
eingehaengten Module leben stillschweigend davon. Die Rueckmeldung wurde
dort mit 401 abgewiesen, bevor ihr Schluessel ueberhaupt geprueft wurde;
der richtige Schluessel sah dadurch aus wie ein Fehler in der Pruefung.
Das Sicherungsmodul haengt jetzt VOR dem Aufgabenmodul und bringt seine
eigene Schranke mit -- damit haengt es an keinem anderen Modul mehr.
Ausserdem: Die Ueberschrift im Kasten nennt jetzt den GRUND, aus dem er
gelb ist. Vorher stand dort "Zuletzt gesichert vor 2 Minuten", waehrend
die Farbe wegen der fehlenden Kopie warnte -- die Anzeige widersprach
sich selbst und man sucht den Fehler an der falschen Stelle.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
7a393b9335 |
Workspace: naechtliche Sicherung, die auch wirklich Daten enthaelt
Bisher wurde nur EINMAL gesichert: direkt vor einer Umstellung der
Datenbank. Faellt die Platte aus, ist alles weg -- die komplette
Betreuung, jede Aufgabe, jedes Protokoll. Das war das einzige Risiko im
System, das auf einen Schlag ALLES kostet.
Beim Nachsehen auf dem Server kam ein zweiter, schwerwiegenderer Befund
dazu:
workspace.db 4.096 B
workspace.db-wal 2.101.232 B
Im WAL-Betrieb landen Schreibvorgaenge zuerst im -wal und wandern erst
beim Checkpoint in die Hauptdatei. Der lief seit dem ersten Tag nicht.
Wer also workspace.db kopiert haette -- der naheliegendste Sicherungsweg
ueberhaupt -- haette eine LEERE Datenbank gesichert und es nicht gemerkt.
Der Test stellt genau das nach: aus der reinen Dateikopie waren 0 von 200
Aufgaben lesbar.
Deshalb:
- Nie eine Dateikopie. Immer VACUUM INTO -- SQLite schreibt selbst, liest
das WAL mit, Ergebnis ist in sich stimmig auch waehrend Schreibzugriffen.
- Vor jeder Sicherung ein erzwungener Checkpoint (TRUNCATE). Haelt die
Hauptdatei aktuell und das WAL klein.
- Jede frische Sicherung wird SOFORT wieder geoeffnet und geprueft: auf
Unversehrtheit UND darauf, dass Personen darin stehen -- gegen genau den
Fall einer technisch einwandfreien, aber leeren Datei. Faellt sie durch,
wird sie geloescht statt behalten.
- Erst unter Zwischennamen schreiben, dann pruefen, dann umbenennen. Sonst
stuende nach einem Abbruch eine halbe Datei unter dem richtigen Namen.
- Aufbewahrung 7 taeglich / 4 woechentlich / 6 monatlich, je Art getrennt
aufgeraeumt, damit taegliche nie die monatlichen verdraengen.
Laeuft IM Prozess, nicht als Systemdienst: keine Aenderung an Systemdateien
noetig, die Datenbank ist ohnehin offen, und es kommt mit jedem git pull
mit. Statt setTimeout auf 24 h wird viertelstuendlich geprueft, ob fuer
HEUTE schon eine liegt -- das ueberlebt Neustarts und Ausfaelle.
Dazu eine Zustandsansicht auf der Automationen-Seite: wann zuletzt, wie
gross, wie viele Personen darin, wie viel wartet noch im WAL, wie viel
Platz ist frei. Plus "Jetzt sichern" von Hand. Nur Leitung, 404 statt 403
fuer alle anderen.
Geprueft (server/pruef-sicherung.mjs, 27 Pruefungen) einschliesslich des
Ernstfalls: Sicherung schreiben, Datenbank zerstoeren, zurueckspielen,
Vollstaendigkeit und Schreibbarkeit nachweisen. Eine ungetestete Sicherung
ist eine Vermutung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
c0ac041122 |
Workspace: Versionsstempel gegen Cloudflares 4-Stunden-Cache
Filipe sah die neue Kachel nicht, obwohl sie live war. Ursache gemessen, nicht vermutet: Node liefert : Cache-Control: no-cache (richtig) Cloudflare macht: Cache-Control: max-age=14400 (ueberschreibt es) cf-cache-status: REVALIDATED, Server: cloudflare Cloudflares voreingestellte Browser-Cache-Zeit von vier Stunden setzt sich ueber das no-cache des Servers hinweg -- aber NUR bei JS und CSS. HTML kommt mit DYNAMIC und no-cache immer frisch durch (geprueft an /creator.html und /workspace/). Genau deshalb genuegt ein Stempel in der HTML: neue Seite -> neue Adresse -> Cloudflare kennt sie nicht -> frische Datei. Keine Cloudflare-Einstellung noetig, nichts, worauf ich warten muss. tools/workspace-stempel.mjs setzt den Stempel auf alle 71 Verweise in 13 Dateien. Der Lauf ist wiederholbar: ein vorhandener Stempel wird ersetzt, nicht angehaengt (geprueft). Gehoert ab jetzt vor jeden Deploy, der JS oder CSS im Workspace anfasst. Ich verlasse mich damit nicht mehr aufs Erinnern -- das war der eigentliche Fehler. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGit
|
9b2e09be58 |
Workspace: Wissens-Bibliothek -- 20 Kategorien, Suche, Filter, Pflege
Wichtigster Befund vorab: Es gab noch KEINEN PDF-Bereich. Weder auf der Website (28 Seiten, keine davon Anleitungen) noch auf dem Server (null PDFs). Es wurde also nichts umstrukturiert, sondern neu gebaut -- und damit war die erste Frage nicht "wie sieht es aus", sondern "wie kommen die PDFs spaeter rein". Eine feste Liste im Code waere nach drei Monaten unbrauchbar gewesen. Filipe hat entschieden: eigener Pflegebereich, und alles nur fuer das Team. Die Bibliothek liegt deshalb komplett im Workspace hinter dem Login, nicht auf der oeffentlichen Seite. GLIEDERUNG Zwanzig Kategorien woertlich nach Vorgabe, gebuendelt in sechs Welten: TikTok, Streaming einrichten, Bild & Ton, Uebertragung & Aussehen, Inhalt & Menschen, Hilfe & Schnellstart. Zwanzig gleich aussehende Kacheln untereinander findet niemand -- gebuendelt sucht man erst die Welt, und darin stehen nur noch drei bis vier. Jede Welt hat ihre eigene Farbe, jede Kategorie ihr eigenes Symbol (20 verschiedene, keins doppelt). Die Kategorietexte sind Filipes Beschreibungen -- sie beantworten beim Einsortieren die einzige Frage, die man wirklich hat. Die Gliederung steht im Code, nicht in der Datenbank: Sie ist eine bewusste Ordnung, keine Nutzdaten. JEDE PDF HAT GENAU EINE HAUPTKATEGORIE, alles Weitere laeuft ueber Tags -- so gibt es jede Anleitung nur einmal, sie ist aber ueber mehrere Begriffe auffindbar. Genau wie gefordert. SUCHE UND FILTER Suche ueber Titel, Beschreibung, Tags und Dateiname. Filter nach Stufe (Einsteiger / Fortgeschritten / Profi), Geraet und Tag. Zwei Details: - "PC" zeigt auch die Anleitungen, die fuer BEIDE Geraete gelten -- sonst filtert man sich versehentlich die Haelfte weg. - Der Tag-Filter sucht mit Kommas drumherum, sonst wuerde "pc" auch bei "pc-spiele" anschlagen. Sobald gesucht oder gefiltert wird, verschwinden die Kacheln und es erscheinen Treffer. Wer sucht, will nicht erst noch klicken. Der Zustand steht in der Adresse (?k=obs&tag=...). Damit funktionieren Zurueck-Taste, Neuladen und Weiterschicken. Eine Kategorie, die man niemandem verlinken kann, ist keine Seite. Geprueft. SICHERHEIT Hochgeladen wird nur, was WIRKLICH eine PDF ist -- geprueft an den ersten Bytes (%PDF-), nicht an der Dateiendung. Die kann jeder umbenennen. Geprueft mit einer als .pdf getarnten HTML-Datei mit Skript: abgewiesen. Nur weil diese Pruefung existiert, darf die Datei ueberhaupt im Browser angezeigt werden statt bloss heruntergeladen -- und selbst dann mit strenger CSP und nosniff. Lesen darf jeder Angemeldete, pflegen nur DogFather. Geprueft: Creator und Scout bekommen 403 beim Hochladen und sehen keine Bearbeiten-Knoepfe. Ohne Anmeldung ist auch die Datei selbst nicht erreichbar (401). Bricht das Anlegen nach dem Schreiben ab, wird die Datei wieder geloescht -- sonst laege sie fuer immer verwaist auf der Platte. Beim Bearbeiten wird die Datei bewusst NICHT ersetzt. Wer eine neue Fassung hat, stellt sie neu ein. So bleibt nachvollziehbar, was wann galt. Geprueft: 20 Kacheln, 20 verschiedene Symbole, Kategorie oeffnen, Suche, Tag-Klick, Browser-Zurueck, Handy ohne Ueberlauf, 0 Konsolenfehler. |
||
|
DogFatherGit
|
55450aa83f |
Workspace: Start-Check / Erstanalyse -- Onboarding vollstaendig
Letztes unumgesetztes Stueck aus dem Konzept, Seite 5, Block 03. Profil,
Ziele und 90-Tage-Plan gab es schon -- die Erstanalyse dazwischen fehlte.
"Die Betreuung startet strukturiert: Ausgangslage verstehen, Ziele
festlegen und daraus konkrete Arbeitspakete bauen."
Der letzte Halbsatz ist der entscheidende. Ein Check, der mit einer Note
endet, ist eine Beurteilung. Ein Check, der mit Aufgaben endet, ist
Betreuung. Jeder Punkt mit Handlungsbedarf bietet deshalb direkt an,
daraus eine Aufgabe zu machen -- mit dem Befund als Herkunft und
automatisch hoher Prioritaet. Dieselbe Linie wie beim Review ("endet mit
einer Entscheidung") und beim Call ("endet mit To-dos").
Die vier Felder aus dem Deck, mit je vier Punkten: Profil & Auftritt,
LIVE-Struktur, Content-Muster, Community & Modis. Drei Stufen: Passt,
Ausbaufaehig, Handlungsbedarf.
Die Punkte stehen fest im Code, NICHT in der Datenbank. Eine
Erstanalyse, bei der jeder eigene Punkte anlegt, ist keine Erstanalyse
mehr -- man koennte zwei Creator nicht mehr vergleichen, und genau das
ist ihr Zweck.
Sichtbarkeit, bewusst anders als beim Profil:
- LESEN darf auch der Creator selbst. Der Check ist Teil SEINES
Entwicklungsplans ("jeder Creator bekommt einen eigenen, lebenden
Entwicklungsplan"), kein Urteil hinter seinem Ruecken. Wer etwas
festhalten will, das er nicht sehen soll, hat dafuer die interne
Notiz im Profil -- die bleibt beim Management.
- AENDERN duerfen nur Management und zustaendiger Scout. Es ist eine
Fremdeinschaetzung; koennte der Creator sie selbst setzen, waere es
eine Selbsteinschaetzung. Geprueft: Luna bekommt 403 beim Bewerten und
beim Anlegen einer Aufgabe, sieht aber ihren Check inklusive Notizen.
- Ein nicht zustaendiger Scout bekommt 404, nicht 403.
Kein Speichern-Knopf: Jede Bewertung und jede Notiz wird sofort
gesichert. Eine Erstanalyse geht man im Gespraech durch -- da will
niemand am Ende noch an einen Knopf denken.
Ein leergeraeumter Punkt (keine Bewertung, keine Notiz) wird geloescht
statt als leere Zeile stehen zu bleiben. So sagt der Bestand direkt, wie
weit die Analyse ist.
Zwei neue Hinweise auf dem Dashboard:
- "Creator ohne Start-Check" -- die Sorte Luecke, die sonst niemandem
auffaellt, weil ja nichts fehlt: es fing nur nie an.
- "Punkt im Start-Check braucht Handlung", sichtbar fuer alle, die den
Check auch sehen duerfen.
Aus dem Test: Sechzehn dauerhaft offene Notizfelder machten die Seite
7026 px lang. Das Feld erscheint jetzt erst mit der Bewertung -- vorher
hat man ohnehin nichts zu notieren. 2460 px.
|
||
|
DogFatherGit
|
3a1ab64c26 |
Workspace: Suche ueber alle Bereiche (Phase 4)
Auf JEDER Seite, nicht auf einer eigenen. kopf.js baut sie selbst in die Kopfleiste ein -- eine Suche, die man nur auf einer Extraseite findet, benutzt niemand. Mit "/" oeffnen, mit Esc schliessen. Durchsucht: Aufgaben, Termine, Calls, Gespraechsprotokolle, Dateien, die fuenf Betreuungsbereiche, die Scout-Pipeline und die offenen Felder der Creator-Profile. Zwei Dinge machen den Unterschied zwischen einer Suche und einer brauchbaren Suche: 1. SIE DARF NICHTS FINDEN, WAS DIE SEITE VERBERGEN WUERDE. Eine Suche ist die verlockendste Stelle fuer ein Datenleck: Man tippt einen Namen und bekommt Treffer aus Bereichen, die man nie oeffnen duerfte. Jede Quelle wird deshalb mit der Sichtbarkeitsregel ihres eigenen Moduls abgefragt -- importiert, nicht abgeschrieben. Die management-internen Profilfelder (admin_notiz, plan_start, naechster_review) werden GAR NICHT durchsucht, auch nicht fuer das Management: Ein Treffer daraus taucht sonst spaeter in einer Ansicht auf, die diese Felder nicht zeigen darf. Wer die Notiz lesen will, oeffnet das Profil. Geprueft mit einem eigenen Leck-Test: "GEHEIM" (Inhalt einer internen Notiz) findet niemand, auch der Chef nicht. Die Lead-Notiz eines Scouts findet nur er selbst und das Management, nicht der andere Scout. 2. SIE MUSS SAGEN, WO ETWAS STEHT. Jeder Treffer traegt einen Ausschnitt RUND UM die Fundstelle, nicht die ersten Zeichen des Feldes -- man sieht sofort, warum etwas gefunden wurde. Bei Profiltreffern steht dabei, welches Feld getroffen hat, bei Protokollen ob es unter "Besprochen" oder "Entscheidung" stand. Und jeder Treffer fuehrt an die Stelle, an der man weiterarbeiten kann. LIKE-Sonderzeichen werden maskiert. Ohne das waere die Suche nach "100%" eine Suche nach "100 gefolgt von irgendwas" und "a_b" faende auch "axb" -- beides falsch und beides faellt erst spaet auf. Geprueft: "100%" und "a_b" finden genau ihren Eintrag, "axb" findet nichts. Bewusst kein Volltextindex (FTS5): Die Datenmengen sind klein, und LIKE braucht keinen zweiten Datenstand, der irgendwann auseinanderlaeuft. Kleinigkeiten aus dem Test: - Das Overlay stand auf voller Hoehe, auch bei zwei Treffern -- der Schleier ist flex und stand auf dem voreingestellten stretch. Jetzt flex-start, das Fenster waechst mit dem Inhalt (417 statt 780 px bei drei Treffern). - Das eingebaute Kreuz von type="search" sass direkt neben dem Esc-Knopf: zwei Wege fuer dasselbe, dicht nebeneinander. Entfernt. - Das CSS liegt in gate.css, nicht in einer Seiten-Datei -- genau der Fehler, der bei .knopf-still schon einmal passiert ist. |
||
|
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
|
45cd0ae226 |
Workspace: Calls & Meeting-Protokolle -- Phase 3 vollstaendig
/workspace/calls.html. Calls sind KEINE eigene Terminart neben dem Kalender, sondern dieselben Termine mit art = 'call' oder 'review'. Ein zweiter Terminspeicher waere die sichere Art, irgendwann zwei widerspruechliche Uhrzeiten zu haben. Diese Seite fuegt nur hinzu, was ein Gespraech vom blossen Termin unterscheidet: das Protokoll danach. Die Sichtbarkeitsregel ist Wort fuer Wort dieselbe wie im Kalender -- ein Termin darf nicht in der einen Ansicht auftauchen und in der anderen fehlen. Der tragende Satz von Seite 13, woertlich genommen: "Jeder Call endet mit klaren To-dos, die direkt ins Board uebernommen werden." To-dos werden deshalb NICHT als Text im Protokoll abgelegt, sondern sofort zu echten Aufgaben -- mit dem Gespraech als Herkunft in der Beschreibung, zugeordnet an das Gegenueber des Calls. Sonst steht die Verabredung in einem Dokument, das niemand mehr oeffnet. Geprueft: Protokoll geschrieben -> Aufgaben stehen im Brett. Weitere Punkte: - Reihenfolge der Gruppen ist Dringlichkeit, nicht Chronologie: Ganz oben stehen vergangene Gespraeche OHNE Protokoll. Das ist der einzige Zustand, der etwas von einem verlangt. Nur diese Gruppe ist optisch hervorgehoben; wenn alles schreit, sieht man nichts mehr. - Ein festgehaltenes Protokoll ist danach nur noch lesbar. Ein Gespraech nachtraeglich umschreiben zu koennen waere genau das, was ein Protokoll wertlos macht. - "Naechster Termin" legt den Folgetermin direkt in den Kalender -- mit demselben Gegenueber und demselben Meeting-Link. - Alles in EINER Transaktion. Geprueft mit einem absichtlich kaputten To-do: kein Protokoll, keine halben Aufgaben, kein Folgetermin. - Enter im To-do-Feld legt die naechste Zeile an, damit man eine Liste tippen kann, ohne zur Maus zu greifen. - Meeting-Link nur bei anstehenden Gespraechen und nur, wenn es wirklich eine http(s)-Adresse ist. "bei mir zu Hause" bleibt schlichter Text. Zur Videotechnik selbst bewusst KEINE Entscheidung getroffen: Ein eigener WebRTC-Raum braucht einen TURN-Server, damit Verbindungen hinter Mobilfunk-NAT zustande kommen. Das ist eine Infrastrukturfrage mit laufenden Kosten und gehoert besprochen, nicht nebenbei entschieden. Bis dahin traegt der Termin einfach den Link des Dienstes, der ohnehin benutzt wird. Nebenbei: .knopf-still lag in scouting.css und fehlte dadurch auf calls.html -- dort standen prompt nackte Systemknoepfe. Der Baustein gehoert ins gemeinsame start.css, dort liegt er jetzt. |
||
|
DogFatherGit
|
d845d91d70 |
Workspace: Scout-CRM -- Pipeline, Follow-ups und Uebergabe
/workspace/scouting.html. Erster Baustein aus Phase 3 und der Bereich,
in dem Scouts bisher praktisch nichts hatten.
Der Merksatz von Seite 15 ist hier die Sicherheitsregel, nicht nur eine
Beschreibung: "Scouts sehen ihre Pipeline -- die Admin-Rolle die
Gesamtuebersicht -- Creator keine Scout-internen Daten."
- Creator bekommen 404, nicht 403, und zwar auf Schnittstelle UND Seite.
Sie sollen nicht einmal erfahren, dass es den Bereich gibt.
- Ein Scout sieht ausschliesslich die eigene Pipeline. Geprueft: Patrick
bekommt auf Sams Lead 404 beim Lesen, Aendern und Loeschen.
- Das Management sieht alles, kann nach Scout filtern und Leads einem
Scout zuordnen.
Pipeline als gruppierte Liste, nicht als Board: Sechs Spalten waeren auf
dem Handy unbedienbar, und Scouts arbeiten unterwegs. Jede Stufe traegt
eine eigene Farbe an der linken Kante, die von kuehl (neu entdeckt) nach
gruen (uebergeben) laeuft -- die Richtung der Pipeline wird sichtbar,
ohne Ampel-Geblinke.
Jede Karte hat genau EINEN naheliegenden Schritt ("Weiter zu ..."), der
Rest steckt im aufklappbaren Teil. Der Weiter-Knopf traegt bewusst nur
die Farbe seiner Stufe statt des vollen Farbverlaufs, sonst waere die
Seite ein Streifenmuster aus identischen Leuchtbalken.
Faellige Follow-ups stehen als eigene Leiste ganz oben. Das ist der
Teil, der ohne System am ehesten untergeht -- nicht der Kontakt selbst,
sondern das Nachfassen.
Uebergabe ("Creator-Onboarding starten", Seite 15): Aus einem
uebergebenen Lead legt das Management mit einem Klick eine echte Person
mit Zugangscode an. Der Code wird genau einmal angezeigt, wie in der
Personenverwaltung. Die Qualifizierung des Scouts (Plattform, Handle,
Potenzial, LIVE-Aktivitaet) wandert dabei automatisch ins Creator-Profil
-- sonst muesste das Management abtippen, was laengst dasteht. Geprueft:
Lead -> Person -> Profil, alle drei verbunden, zweiter Versuch wird
abgelehnt.
Ein uebergebener Lead ist Teil der Betreuungsgeschichte -- den loescht
nur das Management, nicht der Scout (403).
Nebenbei: .knopf-still gab es im Baukasten noch gar nicht, die Zweit-
knoepfe waren nackte Systemknoepfe. Jetzt sauber definiert.
|
||
|
DogFatherGit
|
072ded20a2 |
Workspace: Reports & Review -- Phase 2 vollstaendig
/workspace/report.html. Fuehrt bewusst KEINE eigenen Eintraege, sondern fasst zusammen, was in Aufgaben, Bereichen, Terminen und Dateien schon steht: "Fortschritt wird nicht gefuehlt, sondern nachvollziehbar gemacht". Die vier Abschnitte sind woertlich die Fragen aus dem Deck, Seite 16: Was wurde erledigt? Was blockiert? Was hat funktioniert? Was kommt als Naechstes? Zwei Punkte daraus sind ernst genommen: 1. "Vorher / nachher" (Historie). Jede Zahl wird mit demselben, unmittelbar davorliegenden Zeitraum verglichen. Eine Zahl allein sagt wenig -- 3 erledigte Aufgaben sind gut oder schlecht, je nachdem ob es vorher 1 oder 9 waren. Bei Zahlen, wo mehr SCHLECHTER ist (offene Probleme), ist die Trendfarbe umgedreht. 2. "Jeder Review endet mit einer Entscheidung, nicht nur mit einer Zusammenfassung." Der Report legt deshalb direkt eine Aufgabe an -- ohne Seitenwechsel, mit hoher Prioritaet und optionaler Frist. Geprueft: Eintrag im Report -> Aufgabe erscheint im Brett. "Was blockiert?" zeigt zusaetzlich die drei am laengsten offenen Aufgaben mit Namen, nicht nur eine Zahl. Sichtbarkeit: - Scout: 404, sowohl Schnittstelle als auch Seite (leitet weg) - Creator: sieht nur sich. Geprueft -- Luna fordert ?creator=3 (Mika) an und bekommt einen Report ueber SICH, der Parameter wird fuer Nicht-Management ignoriert - Der Review-Termin aus dem Profil ist Steuerungswissen und wird einem Creator auch hier nicht mitgeschickt, genau wie im Profil selbst Damit ist Phase 2 aus dem Konzept vollstaendig. |
||
|
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. |
||
|
DogFatherGit
|
81b51ab94f |
Workspace: Dateiablage mit Freigabe-Ablauf (Phase 1 vollstaendig)
/workspace/dateien.html -- Ablegen per Ziehen oder Auswaehlen, Entwurf -> Review -> Freigabe, Filter je Zustand. OHNE NEUE ABHAENGIGKEIT. Uploads laufen ueblicherweise ueber multer. Hier schickt der Browser die Datei roh im Rumpf, der Name steht im Kopf (URI-kodiert, damit Umlaute heil ankommen). express.raw() bringt den passenden Empfaenger schon mit -- kein Zerlegen von multipart/form-data von Hand, was gerade hier heikel waere. Die drei Punkte, an denen Dateiablagen typischerweise scheitern: 1. Die Dateien liegen AUSSERHALB des Repos (workspace-daten/dateien/). Lagen sie darin, wuerde express.static sie ungeprueft ans Netz geben. 2. Auf der Platte traegt jede Datei einen erzeugten Zufallsnamen, der Originalname steht nur in der Datenbank. Geprueft mit dem Dateinamen "../../etc/passwd": gespeichert wurde "passwd", auf der Platte ein Zufallsname IM Ordner -- nichts ist ausgebrochen. 3. Ausgeliefert wird immer als Download mit neutralem Typ, dazu nosniff und CSP sandbox. Geprueft mit einer hochgeladenen boese.html: kommt als application/octet-stream zurueck, kann also keinen Code im Namen der Domain ausfuehren. Freigabe nach Konzept: Der Zustand "freigegeben" ist eine Abnahme und bleibt dem Management vorbehalten. Geprueft -- Luna kann Entwurf -> Review, aber nicht freigeben (403); eine freigegebene Datei kann sie weder aendern noch loeschen. Sichtbarkeit wie ueberall: Chef 2 Dateien, Luna 1, Mika 0. Zugriff auf eine fremde Datei: 404, nicht 403. Ein Fehler beim Testen gefunden: Bei zu grosser Datei brach express.raw ab, BEVOR der eigene Code lief -- der Fehler landete im allgemeinen Behandler als HTTP 500. Fuer die Nutzerin sah das aus wie ein kaputter Server statt wie "Datei zu gross". Jetzt faengt ein eigener Fehlerbehandler am Ende des Routers das ab und antwortet mit 413 und einer verstaendlichen Meldung. Damit ist Phase 1 aus dem Konzept vollstaendig. |
||
|
DogFatherGit
|
ef79659f8f |
Workspace: Kalender mit Terminen, Calls und Aufgaben-Fristen
/workspace/kalender.html -- letzter grosser Baustein aus Phase 1.
Zeigt zwei Quellen in EINER Ansicht, wie im Konzept gefordert
("Kalender & Calls" neben "Deadlines" und "Wiedervorlagen"):
* eigene Termine (Arten: Call, Termin, Review)
* Fristen offener Aufgaben, nur lesend eingeblendet
Nach Tagen gruppiert statt als Monatsraster: Es geht um wenige, dafuer
konkrete Termine. Eine Liste liest sich dabei besser und funktioniert auf
dem Handy ohne Umbau. Zeitraum umschaltbar: 14 / 30 / 90 Tage, wobei 90
den 90-Tage-Plan aus dem Konzept abdeckt.
Sichtbarkeit wie bei den Aufgaben, wieder an einer Stelle definiert.
Geprueft mit drei Konten:
Chef 2 Termine + 2 Fristen | Luna 2 + 1 | Sam 0 + 1
Die Fristen folgen dabei exakt der Aufgaben-Regel -- Sam sieht nur seine.
Loeschen darf das Management und wer den Termin selbst angelegt hat.
Sonst koennte ein Creator einen Call absagen, den das Management
angesetzt hat. Geprueft: Luna auf Chefs Call 403, auf ihren eigenen 200,
Sam sieht ihn gar nicht (404).
Weiteres:
- Ort/Link wird nur dann als Verweis dargestellt, wenn er wirklich mit
http(s) beginnt -- sonst liesse sich javascript: einschleusen
- Zeitpunkt und Dauer werden geprueft (kaputtes Datum 400,
5000 Minuten 400)
- Beginn steht als lokale Zeit ohne Zeitzone: Alle Beteiligten sitzen in
derselben, eine falsch umgerechnete Uhrzeit waere schlimmer als gar
keine Umrechnung
|
||
|
DogFatherGit
|
8bfd2ae166 |
Workspace: Creator-Profile (Onboarding aus dem Konzept)
/workspace/profil.html -- Stammdaten, Ziele und 90-Tage-Plan, genau nach Seite 5 des Konzepts. Management waehlt oben den Creator aus, ein Creator sieht nur sein eigenes Profil. Sicherheitskern ist das Feld admin_notiz. Das Konzept fordert "private Admin-Notizen separat". Die Notiz wird deshalb nicht im Browser ausgeblendet, sondern gar nicht erst gesendet: Die Spaltenliste der Abfrage haengt an der Rolle (FELDER_OFFEN / FELDER_ADMIN). Dasselbe gilt fuer Plan-Start und Review-Termin. Geprueft: - In der kompletten Rohantwort an den Creator kommt der Inhalt der internen Notiz 0-mal vor - Creator auf fremdes Profil: 404 (lesend wie schreibend) - Scout auf ein Profil: 404, profil.html leitet ihn weg - Creator setzt admin_notiz selbst: wird stillschweigend ignoriert, der Inhalt bleibt unveraendert - Profil einer Nicht-Creator-Person: 404 Dabei ist ein aelterer Fehler aufgefallen: /api/ich lieferte nur Name und Rolle, nicht die eigene Nummer. Dadurch rief die Profilseite eines Creators /api/profil/undefined auf und blieb leer. Derselbe Fehler machte in der Personenverwaltung den Selbstvergleich unwirksam -- beim eigenen Eintrag erschien ein "Sperren"-Knopf, den der Server dann ablehnte. /api/ich liefert jetzt zusaetzlich die id. Im Protokoll landen nur die Feldnamen, nie die Inhalte: Im Profil stehen persoenliche Angaben, die nicht zusaetzlich im Audit-Log auftauchen sollen. |
||
|
DogFatherGit
|
232a2003dd |
Workspace: Aufgaben bearbeiten, Personenverwaltung im Browser
Aufgaben: - Bearbeiten-Dialog (Titel, Beschreibung, Prioritaet, Frist, Zuordnung). Als natives <dialog>: Fokusfang, Esc zum Schliessen und Abdunklung ohne eigenen Code. - Loeschen nur fuer Management, mit Rueckfrage und Protokolleintrag. Das Konzept will, dass Erledigtes stehen bleibt -- Loeschen ist der Ausnahmefall fuer Fehleintraege, nicht der normale Abschluss. Personen (/workspace/personen.html, nur Management): - Anlegen, Code erneuern, sperren/entsperren, Protokollansicht - Der Code wird genau einmal in der Antwort zurueckgegeben, nie gespeichert; beim Schliessen auch aus dem Dokument entfernt - Selbstschutz: niemand kann sich selbst sperren, und das letzte aktive Management laesst sich nicht sperren -- sonst kaeme niemand mehr hinein - Code fuer sich selbst tauschen nur mit ausdruecklicher Bestaetigung, weil es die eigene Sitzung sofort beendet Zwei Fehler, die beim Testen aufgefallen sind: 1. Rollenpruefung fehlte beim Ausliefern der Seiten. Ein Creator bekam personen.html mit HTTP 200 -- die Schnittstellen wiesen ihn zwar ab, das Geruest der Seite war aber sichtbar. GESCHUETZT ist jetzt eine Zuordnung Pfad -> erlaubte Rollen statt einer blossen Liste. 2. Das Protokoll nannte den falschen Verursacher. personAnlegen trug die NEU ANGELEGTE Person als person_id ein, der Eintrag las sich also so, als haette sie sich selbst angelegt. Akteur und Betroffener sind jetzt getrennt: Akteur in person_id, Betroffener im Text. Ueber die Kommandozeile angelegte Personen zeigen korrekt keinen Akteur. |
||
|
DogFatherGit
|
2eecb40537 |
Workspace: Aufgabenbrett und Dashboard-Zahlen
Erster echter Arbeitsbereich aus dem Konzept. Kanban mit offen / in Arbeit / Review / erledigt, dazu Prioritaet, Frist, Verantwortlicher und Zuordnung zu einem Creator-Bereich. Kern ist die Datentrennung, und die sitzt AUSSCHLIESSLICH im Server -- in jeder einzelnen Abfrage, an einer Stelle definiert (sichtbar()): admin sieht alles creator sieht seinen Bereich und was ihm zugewiesen ist scout sieht nur, was ihm zugewiesen ist Geprueft mit vier Testkonten: - Chef sieht 4, Luna 2, Mika 1, Sam 1 Aufgaben - Luna auf Mikas Aufgabe: 404 (nicht 403 -- sonst liesse sich durch Ausprobieren herausfinden, welche Nummern es gibt) - Luna legt Aufgabe mit creator_id=Mika an: wird still auf ihren eigenen Bereich umgebogen, Mika sieht sie nicht - Anfrage mit fremdem Origin: 403 - ohne Anmeldung: 401, ungueltiger Status/leerer Titel: 400 - Scout bekommt in der Personenliste nur sich selbst - Dashboard-Zahlen je Rolle korrekt eingegrenzt Weitere Punkte: - Texte werden im Browser nur ueber textContent gesetzt, nie innerHTML -- ein Aufgabentitel darf keine Auszeichnung einschleusen - ueberfaellig = Frist vorbei UND nicht erledigt; die Kachel faerbt sich nur, wenn wirklich etwas ansteht - erledigt_am wird gesetzt bzw. wieder geleert, wenn eine Aufgabe zurueckgeholt wird - Erledigtes verschwindet nicht, wie im Konzept gefordert |
||
|
DogFatherGit
|
f3a55af80f |
Creator Workspace: Anmeldung, Sitzungen und Audit-Log
Erster funktionierender Login fuer /workspace. Bewusst OHNE neue Abhaengigkeiten: Node 24 bringt node:sqlite mit, Hashing und Zufall kommen aus node:crypto. Nichts zu kompilieren, keine fremde Lieferkette an einer Stelle, an der es um Zugangsdaten geht. Sicherheit: - Codes liegen nur als scrypt-Hash (N=32768) mit eigenem Salt in der DB - Vergleich in konstanter Zeit (timingSafeEqual) - Sitzungstoken 32 Byte Zufall, in der DB nur als SHA-256 - Cookie httpOnly, SameSite=lax, Path=/workspace, secure abhaengig von req.secure (live immer an, nur der lokale http-Test kommt ohne aus) - Sperre nach 8 Fehlversuchen je IP fuer 10 Minuten -- danach ist auch der richtige Code blockiert (geprueft) - gleiche Fehlermeldung bei falscher Rolle und falschem Code - Audit-Log fuer Anmeldung, Fehlversuch, Sperre, Abmeldung, Codewechsel Die Datenbank liegt AUSSERHALB des Repos (../workspace-daten/): sonst waere sie ueber express.static aus dem Netz erreichbar, und ein git pull wuerde Nutzdaten anfassen. workspace.js kann die Website nicht mitreissen: node:sqlite wird erst bei Bedarf per createRequire geladen, jede Route faengt ihre Fehler selbst ab. Faellt die DB aus, antwortet nur /workspace/api/* mit 503. Codes werden ausschliesslich auf der Kommandozeile erzeugt (server/workspace-code.js) und dort einmal angezeigt -- nie in Git. Ausserdem: start.html als geschuetzte Seite nach dem Anmelden. Der Schutz sitzt serverseitig vor express.static, nicht nur im Browser. |
||
|
DogFatherGitandClaude Opus 5
|
03a533f143 |
Inhaltsrichtlinie (CSP): mit Pruefsummen statt mit unsafe-inline
Fuenf Schutz-Kopfzeilen waren gesetzt, die wichtigste fehlte. Sie entscheidet als einzige darueber, ob eingeschleuster Text zu ausgefuehrtem Code wird oder sichtbarer Text bleibt. WARUM NICHT DER BEQUEME WEG Ueblich waere script-src 'self' 'unsafe-inline'. Eine Zeile, nichts geht kaputt -- und der Schutz ist weg: Der Browser kann nicht unterscheiden, ob ein Skript im Seitentext vom Entwickler stammt oder von einem Angreifer. Das Ergebnis ist eine Kopfzeile, die gut aussieht und im Ernstfall nichts tut. Der Bestand liess den sauberen Weg zu: keine fremden Skriptquellen, keine externen Schriften, ein Inline-Block je Seite. Von jedem Block wird die Pruefsumme gebildet. DIE PRUEFSUMMEN STEHEN BEWUSST NICHT IM CODE Das waere hier eine Falle mit Ansage: Statische Dateien gehen per "git pull" live, OHNE Neustart. Eine fest hinterlegte Summe waere nach der naechsten Textaenderung falsch -- und die Seite wuerde ihr eigenes Skript nicht mehr ausfuehren. Sichtbar erst im Browser des Besuchers, nicht beim Deploy, und aussehend wie kaputtes JavaScript. Deshalb liest die Middleware die Datei selbst und merkt sich das Ergebnis, solange die Aenderungszeit gleich bleibt. Ein Test aendert index.html im laufenden Betrieb und prueft, dass die Summe nachzieht und die Seite weiterlaeuft. WAS DER TEST GEFUNDEN HAT Die erste Fassung haette die Startseite und stimmen.html beschaedigt: Team-Fotos, Event des Jahres und die Stimmen kommen von der postfach-Subdomain, img-src erlaubte nur 'self'. Der Deploy haette Erfolg gemeldet, der Server waere gestartet -- und die Bilder waeren weg gewesen. Gefunden, weil der Test alle 48 Seiten in einem echten Browser oeffnet und mitschreibt, was blockiert wird. Ein zweiter Fehlschlag lag am Test selbst: Er verlangte eine Pruefsumme auf jeder Seite, auch auf denen ohne Inline-Block. Ein Test, der Unmoegliches fordert, wird frueher oder spaeter abgeschaltet -- er unterscheidet jetzt nach dem tatsaechlichen Inhalt der Datei. DREI onclick-ATTRIBUTE ENTFERNT Sie haetten 'unsafe-inline' erzwungen. Zweimal ein "Coming soon"-Knopf, dessen onclick nur Klicks abfing -- ein <a> ohne href tut das von selbst, ganz ohne Skript. Einmal ein Schliessen-Knopf im Verwaltungsbereich, jetzt mit angehaengtem Zuhoerer. GEGENPROBE Ohne sie waere der Rest wertlos: Eine Richtlinie, die alles erlaubt, blockiert auch nichts und besteht jede Pruefung. Der Test schleust deshalb echten Code ein -- ein Inline-Skript und eines von fremder Adresse -- und beide muessen scheitern. style-src behaelt 'unsafe-inline': 587 style-Attribute im Bestand, deren Umbau ein echtes Risiko fuers Aussehen waere, bei kleinem Gewinn. Ueber Stile laesst sich verschleiern und ueberdecken, aber kein Code ausfuehren. Bleibt als eigener Punkt auf der Liste. 15 Pruefungen gruen, 48 Seiten sauber, Portfolio-Suite unveraendert 35. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4b3ec450d5 |
Webdesign-Bereich: Fundament, oeffentliche Seiten, Zugangsschutz, PayPal
Umsetzung des "Website Masterplan" (16 Seiten) unter /webdesign. Zugangsschutz mit EIGENER Schranke (server/webdesign-gate.js) statt gate.js: gate.js laesst seit dem oeffentlichen Start am 21.08.2026 jeden durch, weil die Pruefung auf SITE_PUBLIC_LAUNCH_AT als allererste Zeile steht. Haette man /webdesign dahintergehaengt, waere der ausdruecklich nicht-oeffentliche Bereich inklusive Preisen und spaeteren Kundendaten ab der ersten Sekunde fuer jeden lesbar gewesen. Eigenes Sitzungs-Cookie, bereich="webdesign" im Token, damit ein gueltiges Universe-Cookie hier NICHT gilt. 37/37 Tests. Sieben oeffentliche Seiten in fuenf Sprachen (de, de-CH mit echtem Dialekt, en, fr, pt). Preise, Zeitrahmen, Paketnamen und die 30-%-Regel stehen an genau EINER Stelle in wd-core.js -- der Masterplan verlangt "ueberall widerspruchsfrei", und vier Kopien laufen bei der ersten Preisaenderung auseinander. Als App installierbar auf Handy und PC. Der Service Worker speichert bewusst KEINE HTML-Seite zwischen: nach dem Abmelden wuerden sonst geschuetzte Seiten weiter ausgeliefert, ohne dass der Server je gefragt wird. 18/18 Tests. Handy-Abnahme ueber alle Seiten in fuenf Breiten (320-1440) und fuenf Sprachen: 40/40. Der Test fand 35 echte Fehler (Touch-Ziele unter 44px), behoben im Designsystem statt einzeln pro Seite. PayPal (Wunsch 22.08.2026 "sofort auf meinem paypal"): Orders API mit intent=CAPTURE, also sofortiger Einzug statt blosser Reservierung. Gebuehr und Nettobetrag getrennt gespeichert. Betraege durchgehend als Ganzzahl in Cent. Gefaelschte Webhooks werden abgewiesen. Fail closed solange Zugangsdaten fehlen. 28/28 Tests gegen einen nachgebauten PayPal-Server. Datenbank: 15 Tabellen mit Praefix wd_, fachlich vollstaendig vom Universe getrennt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
6dad6a5af5 |
Fix: Deploys blieben bei Besuchern bis zu 4 Std im Browser-Cache haengen
Nutzer-Report: sah den Nav-Fix und die neue installierbare Verwaltungsseite trotz erfolgreichem Deploy nicht. Ursache: Express schickt standardmaessig KEIN Cache-Control mit -- da die Seite hinter Cloudflare (orange-cloud) liegt, sprang Cloudflare dafuer mit seinem eigenen Standardwert ein (Browser Cache TTL 4 Std, per curl bestaetigt: max-age=14400). Ein frischer Deploy war dadurch bis zu 4 Std lang im eigenen Browser-Cache jedes/jeder Besuchers unsichtbar. Cloudflare respektiert ein vom Origin gesetztes Cache-Control -- jetzt explizit "no-cache" gesetzt (erzwingt Revalidierung per ETag bei jedem Laden, kein Performance-Verlust durch schnelle 304-Antworten bei unveraendertem Inhalt). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
9adebd9bc4 |
KRITISCH: Server-Quellcode + kompletter Git-Verlauf waren oeffentlich abrufbar
Sicherheits-Audit vor dem geplanten oeffentlichen Start morgen (21.08.2026, Nutzer-Anfrage: "duerfen die leute keinen zugriff auf veraenderungen haben"). SITE_DIR ist der GESAMTE Repo-Ordner (join(__dirname, "..")), express.static lieferte daher nicht nur die Website aus, sondern auch: - server/ (inkl. gate.js, das komplette Sicherheitskonzept im Klartext) - server-internal/ (Admin-/Supporter-Backend-Quellcode) - cloudflare-worker/ (altes Backend) - .git/ (VOLLSTAENDIGE Commit-Historie, rekonstruierbar per Git-Dump) - CLAUDE.md, DEPLOY.md, wrangler.toml, netlify.toml, gate-worker.js, gate.html.bak-07-08-2026 (Alt-Backup-Datei einer frueheren Session) Live nachgewiesen (mit gueltigem Zugangscode -- morgen faellt die Schranke fuer ALLE weg): /server/gate.js und /.git/config lieferten HTTP 200. Ursache: serve-static blockt per Default nur Dateien, deren EIGENER Name mit einem Punkt beginnt (server/.env -> zufaellig schon 404), aber NICHT rekursiv -- .git/config wird trotzdem ausgeliefert, weil "config" selbst nicht mit einem Punkt beginnt, nur der Ordner davor. Fix: eigene Sperr-Middleware VOR express.static, unabhaengig von gateMiddleware (bleibt also auch nach dem Entfernen der Zugangsschranke wirksam). Blockt ganze Ordner (server/, server-internal/, cloudflare-worker/) + versteckte Ordner/Dateien rekursiv (jedes Pfadsegment, das mit "." beginnt, ausser .well-known) + eine feste Liste an Alt-Dateien + jedes *.bak-Muster, damit auch kuenftige Backup-Reste automatisch mitgeschuetzt sind. Lokal mit echtem Express-Server verifiziert (gateMiddleware absichtlich deaktiviert, um exakt den morgigen "oeffentlich"-Zustand zu simulieren): alle vorher gefundenen Luecken jetzt 404, alle echten Seiten/Assets (index.html, main.css, main.js, manifest.json, robots.txt, favicon) weiterhin 200. Getrennt prooft: server-internal/ (eigener Dienst unter postfach.dogfather-universe.com, Port 4200) hat sein EIGENES, unabhaengiges Session-System -- jede /admin/*-Route ist einzeln per requireTeamSession-Middleware abgesichert (in index.js durchgezaehlt, keine Ausnahme gefunden), live mit einer unauthentifizierten Anfrage gegen /admin/users/list bestaetigt (401). Dieser Dienst war nie vom Website-Gate abhaengig und ist von diesem Fund nicht betroffen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGit
|
d6489f787a |
Sicherheits- und Stabilitaetskorrekturen nach vollstaendiger Pruefung
- Login-Sperre war umgehbar: clientKey() vertraute dem Header CF-Connecting-IP. Bei Cloudflare war das sicher (CF ueberschreibt ihn), auf dem eigenen Server nicht: der Ursprungsserver ist auch direkt unter seiner IP erreichbar, dort konnte der Header frei gesetzt und die 5-Versuche-Sperre komplett ausgehebelt werden (nachgewiesen). Jetzt req.ip hinter trust proxy. - Absturzsicherheit: Express 4 faengt Fehler aus async-Handlern nicht ab, eine einzige fehlerhafte Anfrage konnte den ganzen Dienst beenden. wrap() um alle Handler, zentraler Fehler-Handler, unhandledRejection/uncaughtException-Netz. - Sicherheits-Header (X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, HSTS) wurden bisher nur ueber die Datei _headers gesetzt, die auf dem eigenen Server wirkungslos ist. Jetzt im Express-Server. - x-powered-by abgeschaltet. - Datenschutzerklaerung/AGB: nannten Cloudflare als Hoster und eine Cloudflare-D1- Datenbank. Jetzt korrekt netcup (Rechenzentrum Nuernberg) als Hoster, Cloudflare als vorgeschaltetes CDN mit Drittlandhinweis. |