dogfather-universe

641 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	bede91921d	Der sechste Bereich, und zwei Pruefungen, die den Lauf lahmgelegt haben DER AGENTUR-BEREICH (Stufe 4 des Plans) Kernprinzip 04 des Konzepts lautet woertlich "Die Agentur bleibt angebunden" -- und dafuer gab es bis heute nichts. Fuenf Bereiche standen, der sechste fehlte vollstaendig. Damit stand nirgends, welche Kampagne laeuft, welche Schulung ansteht und wie ein Anliegen an die Agentur ausgegangen ist. Das lief ueber private Nachrichten: nicht auffindbar, nicht nachvollziehbar, beim naechsten Mal von vorn. Vier Arten, und die vierte ist der Punkt: kampagne, schulung, anliegen und ZUSTAENDIGKEIT. Die letzte ist keine Verlegenheit, sondern das, was das Konzept ausdruecklich fordert -- Betreuung und Umsetzung sind unsere Seite, offizielle Wege sind Agenturseite. Solange das nur im Kopf steht, wird es bei jedem Streitfall neu verhandelt. Der Umbau war das eigentliche Risiko, nicht der Bereich: Ein CHECK laesst sich in SQLite nicht aendern, die Tabelle muss neu gebaut werden -- und dabei werden ALLE vorhandenen Eintraege umgeschrieben. Deshalb geht pruef-agentur.mjs (31 Pruefungen) den Weg wirklich: Sie baut eine Datenbank im ALTEN Stand nach, fuellt sie mit allen fuenf Bereichen, laesst die echte Anwendung darueberlaufen und zaehlt danach jede Zeile UND jedes Feld nach -- auch die seltenen Spalten (hook, creator_extern), die man beim Abschreiben des Bauplans vergisst. Wichtigste Gegenprobe: Der CHECK muss danach noch BEISSEN. Eine Umstellung, die nebenbei die Schranke entfernt, sieht aus wie ein Erfolg und ist der schlimmere Ausgang. Nebenbei drei abgeschriebene Bereichslisten beseitigt (Wochenbericht, Suche, Report-Ziele). Im Wochenbericht waere der neue Bereich sonst schlicht nicht vorgekommen -- ohne Fehler, ohne Luecke, einfach nicht da. ZWEI PRUEFUNGEN, DIE DEN GESAMTLAUF ZUM STILLSTAND BRACHTEN pruef-call-kategorien.mjs hing DREI STUNDEN. Ursache war ein Zeitzuender in ihr selbst: Sie legte Calls auf "heute 18:00" und erwartete zwei davon unter "Heute". Ab 18 Uhr sind die vorbei, der Server schiebt sie nach "Protokoll fehlt", und die Oberflaeche unterteilt erst ab FUENF anstehenden. Uebrig blieben vier, die Bloecke verschwanden, und die Pruefung wartete auf einen Klick auf einen Block, den es nicht gab. Genau die Sorte Fehler, vor der die Projektnotiz vom 06.09. warnt: Sie war um 17:59 gruen und um 18:01 rot, ohne dass sich am Code etwas geaendert hatte. Jetzt liegen alle Zeiten RELATIV zu jetzt, und die Erwartung wird mit derselben Vorschrift gerechnet, die calls.js benutzt -- statt Zahlen, die nur zu einer bestimmten Tageszeit stimmen. Und der Grund, warum daraus ein Stillstand statt eines Fehlers wurde: index.js setzt bewusst zwei Auffangnetze (uncaughtException, unhandledRejection). Fuer den Betrieb richtig -- ein Fehler darf die Website nicht offline nehmen. Fuer eine Pruefung fatal: Sie importiert index.js in denselben Prozess und erbt die Netze. Ihr eigener Absturz wird dann nur protokolliert, und der Express-Server haelt den Prozess danach ewig am Leben. Kein Fehler, kein Ergebnis, kein Ende. Deshalb zwei Abhilfen, die zusammengehoeren: * server/helfer-notbremse.mjs -- haengt eigene Zuhoerer DANEBEN (process.on ergaenzt, es ersetzt nicht) und beendet den Lauf mit Fehler; dazu ein Wecker. In alle 42 Browserpruefungen eingebaut. Der Betrieb bleibt unveraendert. * tools/alles-pruefen.mjs gibt jeder Datei eine Frist von 600 s. Wer sie reisst, wird abgebrochen und ZAEHLT ALS FEHLGESCHLAGEN, mit der letzten Ausgabe davor als Beleg. Einzelne Dateien nachzuruesten hilft nur bis zur naechsten ohne Notbremse -- deshalb sitzt sie dort, wo sie fuer alle gilt, auch fuer die, die es noch nicht gibt. AUSSERDEM: pruef-breiten.mjs pruefte 16 Seiten aus einer Liste von Hand, chat.html und leistung.html fehlten darin. Der Chat war bei keiner einzigen der neun Breiten je gemessen worden. Wie bei pruef-handy kommt die Liste jetzt aus dem Verzeichnis. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-06 22:06:49 +02:00
DogFatherGitandClaude Opus 5	2bebab156b	Profilbild gebaendigt, Steckbrief von der Creator-Akte getrennt ZWEI FEHLER, DIE FILIPE GESEHEN HAT. 1. DAS PROFILBILD LAG UEBER DER HALBEN SEITE. Als Patrick sein Bild hochlud, zog sich ein roter Balken quer ueber die Startseite. Ursache: Die CSS-Regel .wer__bild hat GEFEHLT. Das Element wurde in kopf.js erzeugt, die Regel dazu nie geschrieben -- und ein <img> ohne Groessenangabe nimmt seine natuerliche Groesse an, bei einem Handyfoto also mehrere tausend Pixel. Dazu fehlte overflow: hidden am Traeger. WARUM KEINE PRUEFUNG DAS GEFUNDEN HAT: Sie lud ein 1x1-Pixel-PNG hoch. Klein, schnell, von Hand gebaut -- und voellig unfaehig, irgendetwas zu ueberdecken. Die Pruefung war gruen, der Fehler war da, und gesehen hat ihn der Nutzer. Sie arbeitet jetzt mit einem 1200x1200-Bild, also in der Groesse, die wirklich hochgeladen wird, und misst danach: Bleibt das Bild in seinem 28-px-Feld, ragt es irgendwo heraus, laeuft die Seite ueber. Gegenprobe gemacht -- ohne die Regel meldet sie 1200x1200 in 28x28 und 918 px Ueberlauf. 2. ZWEI PERSONEN AUF EINEM BILDSCHIRM. Auf der Profilseite stand oben "Profil: SpongBobSchwammKopf" und mittendrin "MEIN PROFIL: Dogfather". Niemand konnte sagen, welche Angabe zu wem gehoert. Es sind auch wirklich zwei verschiedene Dinge: MEIN STECKBRIEF gehoert MIR -- Bild, ein Satz ueber mich, meine Kanaele. Fuehre ich selbst. CREATOR-PROFILE die BETREUUNGSAKTE eines anderen Menschen -- Ziele, 90-Tage-Plan, interne Notizen. Fuehren die Betreuer. Scouts, Manager und DogFather haben jetzt zwei getrennte Kacheln und eine eigene Seite (steckbrief.html, serverseitig geschuetzt). Ein Creator behaelt beides zusammen -- er hat nur eine Seite und sieht dort ausschliesslich sich selbst. Die Logik liegt in einer eigenen Datei statt hinten an profil.js: Sie gehoert der angemeldeten Person, nicht der Akte. ACHTZEHN KACHELN, ACHTZEHN FARBEN. Die neue Kachel haette sich ihren Farbton mit den Creator-Profilen geteilt -- zwei Nachbarn in derselben Farbe. Statt eine Farbe dazuzuerfinden, wurde tools/kachel-farben.mjs fuer 18 Winkel neu gerechnet, samt der neuen Nachbarschaft im Raster. Der kleinste Abstand zweier Nachbarn liegt weiterhin bei 100 Grad. Gefunden hat das die Startseitenpruefung ("17 Farben auf 18 Kacheln"). Die Trennung wird jetzt fuer JEDE Rolle geprueft: welche Kacheln sie sieht, dass auf der Akte kein fremder Steckbrief steht, und dass die eigene Seite die richtige Person zeigt. Eine alte Pruefung, die das Gegenteil verlangte, wurde ersetzt statt stehen gelassen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-01 15:04:23 +02:00
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]>	2026-09-01 11:31:34 +02:00

Author

SHA1

Message

Date

DogFatherGitandClaude Opus 5

bede91921d

Der sechste Bereich, und zwei Pruefungen, die den Lauf lahmgelegt haben

DER AGENTUR-BEREICH (Stufe 4 des Plans)
Kernprinzip 04 des Konzepts lautet woertlich "Die Agentur bleibt
angebunden" -- und dafuer gab es bis heute nichts. Fuenf Bereiche
standen, der sechste fehlte vollstaendig. Damit stand nirgends, welche
Kampagne laeuft, welche Schulung ansteht und wie ein Anliegen an die
Agentur ausgegangen ist. Das lief ueber private Nachrichten: nicht
auffindbar, nicht nachvollziehbar, beim naechsten Mal von vorn.

Vier Arten, und die vierte ist der Punkt: kampagne, schulung, anliegen
und ZUSTAENDIGKEIT. Die letzte ist keine Verlegenheit, sondern das, was
das Konzept ausdruecklich fordert -- Betreuung und Umsetzung sind unsere
Seite, offizielle Wege sind Agenturseite. Solange das nur im Kopf steht,
wird es bei jedem Streitfall neu verhandelt.

Der Umbau war das eigentliche Risiko, nicht der Bereich: Ein CHECK
laesst sich in SQLite nicht aendern, die Tabelle muss neu gebaut werden
-- und dabei werden ALLE vorhandenen Eintraege umgeschrieben. Deshalb
geht pruef-agentur.mjs (31 Pruefungen) den Weg wirklich: Sie baut eine
Datenbank im ALTEN Stand nach, fuellt sie mit allen fuenf Bereichen,
laesst die echte Anwendung darueberlaufen und zaehlt danach jede Zeile
UND jedes Feld nach -- auch die seltenen Spalten (hook, creator_extern),
die man beim Abschreiben des Bauplans vergisst. Wichtigste Gegenprobe:
Der CHECK muss danach noch BEISSEN. Eine Umstellung, die nebenbei die
Schranke entfernt, sieht aus wie ein Erfolg und ist der schlimmere
Ausgang.

Nebenbei drei abgeschriebene Bereichslisten beseitigt (Wochenbericht,
Suche, Report-Ziele). Im Wochenbericht waere der neue Bereich sonst
schlicht nicht vorgekommen -- ohne Fehler, ohne Luecke, einfach nicht da.

ZWEI PRUEFUNGEN, DIE DEN GESAMTLAUF ZUM STILLSTAND BRACHTEN

pruef-call-kategorien.mjs hing DREI STUNDEN. Ursache war ein Zeitzuender
in ihr selbst: Sie legte Calls auf "heute 18:00" und erwartete zwei
davon unter "Heute". Ab 18 Uhr sind die vorbei, der Server schiebt sie
nach "Protokoll fehlt", und die Oberflaeche unterteilt erst ab FUENF
anstehenden. Uebrig blieben vier, die Bloecke verschwanden, und die
Pruefung wartete auf einen Klick auf einen Block, den es nicht gab.
Genau die Sorte Fehler, vor der die Projektnotiz vom 06.09. warnt: Sie
war um 17:59 gruen und um 18:01 rot, ohne dass sich am Code etwas
geaendert hatte. Jetzt liegen alle Zeiten RELATIV zu jetzt, und die
Erwartung wird mit derselben Vorschrift gerechnet, die calls.js benutzt
-- statt Zahlen, die nur zu einer bestimmten Tageszeit stimmen.

Und der Grund, warum daraus ein Stillstand statt eines Fehlers wurde:
index.js setzt bewusst zwei Auffangnetze (uncaughtException,
unhandledRejection). Fuer den Betrieb richtig -- ein Fehler darf die
Website nicht offline nehmen. Fuer eine Pruefung fatal: Sie importiert
index.js in denselben Prozess und erbt die Netze. Ihr eigener Absturz
wird dann nur protokolliert, und der Express-Server haelt den Prozess
danach ewig am Leben. Kein Fehler, kein Ergebnis, kein Ende.

Deshalb zwei Abhilfen, die zusammengehoeren:
  * server/helfer-notbremse.mjs -- haengt eigene Zuhoerer DANEBEN
    (process.on ergaenzt, es ersetzt nicht) und beendet den Lauf mit
    Fehler; dazu ein Wecker. In alle 42 Browserpruefungen eingebaut.
    Der Betrieb bleibt unveraendert.
  * tools/alles-pruefen.mjs gibt jeder Datei eine Frist von 600 s. Wer
    sie reisst, wird abgebrochen und ZAEHLT ALS FEHLGESCHLAGEN, mit der
    letzten Ausgabe davor als Beleg. Einzelne Dateien nachzuruesten hilft
    nur bis zur naechsten ohne Notbremse -- deshalb sitzt sie dort, wo
    sie fuer alle gilt, auch fuer die, die es noch nicht gibt.

AUSSERDEM: pruef-breiten.mjs pruefte 16 Seiten aus einer Liste von Hand,
chat.html und leistung.html fehlten darin. Der Chat war bei keiner
einzigen der neun Breiten je gemessen worden. Wie bei pruef-handy kommt
die Liste jetzt aus dem Verzeichnis.

Co-Authored-By: Claude Opus 5 <[email protected]>

2026-09-06 22:06:49 +02:00

DogFatherGitandClaude Opus 5

2bebab156b

Profilbild gebaendigt, Steckbrief von der Creator-Akte getrennt

ZWEI FEHLER, DIE FILIPE GESEHEN HAT.

1. DAS PROFILBILD LAG UEBER DER HALBEN SEITE. Als Patrick sein Bild
   hochlud, zog sich ein roter Balken quer ueber die Startseite.

   Ursache: Die CSS-Regel .wer__bild hat GEFEHLT. Das Element wurde in
   kopf.js erzeugt, die Regel dazu nie geschrieben -- und ein <img> ohne
   Groessenangabe nimmt seine natuerliche Groesse an, bei einem Handyfoto
   also mehrere tausend Pixel. Dazu fehlte overflow: hidden am Traeger.

   WARUM KEINE PRUEFUNG DAS GEFUNDEN HAT: Sie lud ein 1x1-Pixel-PNG hoch.
   Klein, schnell, von Hand gebaut -- und voellig unfaehig, irgendetwas
   zu ueberdecken. Die Pruefung war gruen, der Fehler war da, und gesehen
   hat ihn der Nutzer. Sie arbeitet jetzt mit einem 1200x1200-Bild, also
   in der Groesse, die wirklich hochgeladen wird, und misst danach: Bleibt
   das Bild in seinem 28-px-Feld, ragt es irgendwo heraus, laeuft die
   Seite ueber. Gegenprobe gemacht -- ohne die Regel meldet sie
   1200x1200 in 28x28 und 918 px Ueberlauf.

2. ZWEI PERSONEN AUF EINEM BILDSCHIRM. Auf der Profilseite stand oben
   "Profil: SpongBobSchwammKopf" und mittendrin "MEIN PROFIL: Dogfather".
   Niemand konnte sagen, welche Angabe zu wem gehoert.

   Es sind auch wirklich zwei verschiedene Dinge:
     MEIN STECKBRIEF  gehoert MIR -- Bild, ein Satz ueber mich, meine
                      Kanaele. Fuehre ich selbst.
     CREATOR-PROFILE  die BETREUUNGSAKTE eines anderen Menschen --
                      Ziele, 90-Tage-Plan, interne Notizen. Fuehren die
                      Betreuer.

   Scouts, Manager und DogFather haben jetzt zwei getrennte Kacheln und
   eine eigene Seite (steckbrief.html, serverseitig geschuetzt). Ein
   Creator behaelt beides zusammen -- er hat nur eine Seite und sieht
   dort ausschliesslich sich selbst. Die Logik liegt in einer eigenen
   Datei statt hinten an profil.js: Sie gehoert der angemeldeten Person,
   nicht der Akte.

ACHTZEHN KACHELN, ACHTZEHN FARBEN. Die neue Kachel haette sich ihren
Farbton mit den Creator-Profilen geteilt -- zwei Nachbarn in derselben
Farbe. Statt eine Farbe dazuzuerfinden, wurde tools/kachel-farben.mjs
fuer 18 Winkel neu gerechnet, samt der neuen Nachbarschaft im Raster.
Der kleinste Abstand zweier Nachbarn liegt weiterhin bei 100 Grad.
Gefunden hat das die Startseitenpruefung ("17 Farben auf 18 Kacheln").

Die Trennung wird jetzt fuer JEDE Rolle geprueft: welche Kacheln sie
sieht, dass auf der Akte kein fremder Steckbrief steht, und dass die
eigene Seite die richtige Person zeigt. Eine alte Pruefung, die das
Gegenteil verlangte, wurde ersetzt statt stehen gelassen.

Co-Authored-By: Claude Opus 5 <[email protected]>

2026-09-01 15:04:23 +02:00

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]>

2026-09-01 11:31:34 +02:00