dogfather-universe

903 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	67a0eb8717	DogFather konnte einen zweiten DogFather nicht mehr herabstufen Gefunden beim Durchsehen der schnellen Pruefungen: pruef-haus-trennung stand auf 60 ok / 6 Fehler. Drei Ursachen, eine davon ein echter Rueckschritt von gestern. --- 1. DER RUECKSCHRITT --------------------------------------------- In darfRolleAendern stand seit gestern: if (person.rolle === "admin") return ziel.rolle !== "admin"; Das macht aus "DogFather ist nicht mehr VERGEBBAR" ein "an einem DogFather ist nichts mehr zu aendern". Ein zweiter Zugang liess sich damit nie wieder zuruecksetzen -- er waere fuer immer DogFather geblieben. Die Pruefung sagte es woertlich: "solange es zwei gibt, darf einer wechseln (403)". Die beiden echten Gefahren haengen woanders und bleiben unberuehrt: Niemand KANN 'admin' vergeben, und der LETZTE DogFather laesst sich nicht herabstufen. --- 2. ZWEI SCHLOESSER FUER DIESELBE TUER --------------------------- Ich hatte gestern `rollenZumAendern` mit 403 VOR die vorhandene Pruefung gesetzt, die mit 400 "Unbekannte Rolle." antwortet. Damit war die Luecke wieder offen, vor der der Kommentar vom 17.09. direkt daneben warnt: Zwei verschiedene Antworten -- "gibt es nicht" gegen "darfst du nicht" -- verraten beim Durchprobieren, WELCHE Rollen existieren. Jetzt eine Regel an einer Stelle. `darfAnlegen` ist dort raus, weil Vergeben und Anlegen seit gestern verschiedene Dinge sind. Gemessen: admin anlegen = aendern (sieben Rollen) spicy anlegen = aendern (vier) hand anlegen = — aendern = modi, gast manager anlegen = creator aendern = — Und die eigene Zeile bekommt jetzt 400 mit einem Satz statt 403: Es ist keine Rechtefrage, sondern eine unsinnige Bitte. --- 3. DREI ERWARTUNGEN, DIE AELTER WAREN ALS DIE REGEL -------------- Die Pruefung verlangte 403, wo seit dem 17.09. 400 richtig ist -- ihre Zeile stammt vom 10.09., sieben Tage aelter als die Regel. Und sie verlangte 404 fuer "die rechte Hand vergibt keine Rolle", was bis vorgestern stimmte. Dabei fiel auf, dass NICHTS geprueft hat, ob die rechte Hand ihre neue Faehigkeit ueberhaupt ausueben kann -- nur, dass sie es nicht darf. Eine Pruefung, die nur das Verbotene misst, laesst offen, ob das Erlaubte geht. Jetzt beide Richtungen: an einer anderen rechten Hand aendert sie nichts (403) und an DogFather erst recht nicht (403) einen Modi macht sie sehr wohl zur Community (200) und es steht so in der Datenbank (gast) eine zweite rechte Hand ernennt sie nicht (400) Nebenbei: `unbekannte_kachel` (gestern eingefuehrt) hatte keinen Satz in meldung.js -- die Kennung waere woertlich auf dem Bildschirm gelandet. pruef-meldungen hatte es gemeldet. Und ein Absturz beim Bauen: `const anlegen = await hole(...)` weiter unten im selben Block verdeckt die gleichnamige Funktion im GANZEN Block, auch oberhalb seiner eigenen Zeile. pruef-haus-trennung: 70 ok, 0 Fehler (vorher 60/6). Dazu gruen: rollen-anlegen 11/0, personen-loeschen 40/0, rechte-umstellen 46/0, verteilen 11/0, meldungen 8/0. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 23:13:27 +02:00
DogFatherGit	0f5faf7ee6	Eine Seite, die nicht laedt, sagt es -- und bietet einen Weg zurueck Fuenf Suchlaeufe parallel, ihre Funde selbst nachgemessen und behoben. DER GROESSTE: 13 VON 21 SEITEN SCHLUCKTEN JEDEN NETZFEHLER. Jede Seite beginnt mit `try { await hole('/api/ich') } catch { return; }`. Faellt das Netz aus -- Aufzug, U-Bahn, Funkloch --, bricht der Block ab, und die Seite bleibt fuer immer auf "wird geladen …" stehen. Gemessen: 0 von 32 Stellen setzten `aria-busy` im Fehlerfall zurueck, und es gab KEINEN EINZIGEN "Nochmal versuchen" auf allen 21 Seiten. Im Code stand der richtige Satz dazu -- an genau einer Stelle: "Ein Platzhalter, der nie ersetzt wird, ist eine Luege mit Fortschrittsanzeige." Er galt ueberall ausser dort. Neu: window.ladefehler() in meldung.js. Sie ersetzt alles, was gerade "laedt", durch drei Dinge: was los ist, was das bedeutet, und einen Knopf, der es noch einmal versucht -- ohne die Seite neu zu laden. 21 Dateien angeschlossen. Neu: server/pruef-ladefehler.mjs, 26/0, mit abgeklemmtem Netz im echten Browser. UND DIE STARTSEITE WARF BEI EINEM FUNKLOCH AUF DIE ANMELDUNG. `catch { location.assign('/workspace/') }` -- der Mensch glaubt, er sei rausgeworfen, und tippt seinen Code neu. Dabei haelt seine Sitzung 12 Stunden; nur die Anfrage kam nicht durch. Umgeleitet wird jetzt nur noch bei einer ANTWORT, die das sagt (401). DER ANMELDEHINWEIS FUEHRTE MODIS IN DIE SPERRE. Nach zwei Fehlversuchen stand: "Stimmt die Auswahl oben? Ein Code gehoert immer zu genau einer davon." Auf der Crew-Wand ist das FALSCH -- `stillerZugang()` sucht ueber die Codekennung, die angetippte Kachel spielt fuer hand/modi keine Rolle. Sie probieren alle vier durch, sammeln vier Fehlversuche, und nach acht in zehn Minuten ist ihre Adresse gesperrt. Ein Hinweis, der die Sperre herbeifuehrt, gegen die er helfen soll. Auf der Agenturwand stimmt der Satz weiter -- deshalb wird gefragt, auf welcher Wand man steht. Dazu: Die Crew-Wand nannte nur der Community einen Weg ("Frag im Live nach"). Wer zum Team gehoert und dessen Code nicht geht, fand dort niemanden. SACKGASSE AUF DER KERNSEITE EINES MODI. treff-moderation sagte: "Zugaenge legst du in 'Personen & Zugaenge' an" -- eine Seite, die ein Modi nicht oeffnen darf. Am ersten Tag, bei leerer Community, war das der einzige Satz im Abschnitt. Jetzt fragt die Seite ueber `window.__ich.seiten`, ob es den Weg fuer DIESEN Menschen gibt. Und ein 404 wirft ihn nicht mehr wortlos auf die Startseite. TOTE KNOEPFE AN FREMDEN KARTEN. "◀ zurueck" und "▶ In Arbeit" standen an JEDER Aufgabenkarte, auch an fremden. Ein Modi sieht das Brett des ganzen Teams; er tippt, der Server lehnt mit 403 ab, und die Meldung erscheint GANZ OBEN. Bei einer Karte weiter unten sieht er nichts. Zwei Zeilen tiefer stand die Regel im Klartext: "niemandem etwas anzubieten, das dann abgelehnt wird." Der Server schickt jetzt `darf_aendern` mit. 13 STELLEN ROLLTEN GEGEN DEN WILLEN DES NUTZERS. `scrollIntoView({ behavior: 'smooth' })` beachtet "Animationen reduzieren" NICHT. Wer das eingestellt hat, hat es meist wegen Schwindel getan. Zwei Stellen fragten vorher, dreizehn nicht. Jetzt `window.sanft()`, einmal statt dreizehnmal. DAS WORT UEBER DEN BRETTERN EINES MODI HIESS "BETREUUNG". Fest im HTML, ueberschrieben nur bei Brettern mit eigenem `ober` -- sechs haben keines. Jetzt faellt es auf die GRUPPE der Kachel zurueck, ueber die er hergekommen ist. Je Rolle richtig, ohne zweite Liste. DER HINWEIS-ZU-KACHEL-WEG WAR DOPPELT KAPUTT. `bereichZu` suchte nur in GRUPPEN -- der Liste der AGENTUR. Die Kacheln von Team Dogi schickt der Server; fuer einen Modi fand die Zeile entweder nichts oder eine fremde Kachel und uebernahm deren Farbe. Und sie suchte ueber den NAMEN: "LIVE-Analyse" heisst auf der Crew-Adresse "Live-Ablauf". Beim Beheben erst den Namen umgedreht -- und damit die Agenturseite kaputt gemacht (pruef-start-ansicht sofort rot). Jetzt ueber das ZIEL, das in beiden Haeusern dasselbe ist. UND EIN BRETT WAR SEIT GESTERN GESPERRT. `TREFF_BRETTER` wird aus Kachelzielen abgeleitet. Als die Kachel "Regeln & Hilfe" am 19.09. auf `treff-regeln.html` umgelenkt wurde, fiel `regeln` heraus -- und `treff-regeln.html` verweist weiterhin darauf ("Haeufige Fragen stehen auf dem Brett Regeln & Hilfe"). Gefunden hat es pruef-treff, die seit gestern rot war. 72/0. NEBENBEI 7 SEITEN LEICHTER: meldung.js wird jetzt abgeleitet eingebunden -- nur dort, wo sagWas/ladefehler/sanft wirklich gebraucht werden. Die Anmeldewand traegt es nicht mehr. Gruen: pruef-ladefehler 26/0, pruef-sackgassen 11/0 (582 Wege, 0 ins Leere), pruef-start-ansicht, pruef-treff 72/0, pruef-treffchat, pruef-community-sicht 10/0, pruef-aufgabenbrett, pruef-code 17/0, pruef-chat-optik, pruef-nachfrage 49/0, pruef-meldungen 8/0, pruef-css-klassen, pruef-tippziele 11/0, pruef-leerzustand 13/0, pruef-rechtetafel.	2026-09-20 15:49:57 +02:00
DogFatherGitandClaude Opus 5	461d41943a	Keine Maschinensprache mehr auf dem Bildschirm Filipe: "keine kryptischen oder technischen fehlermeldungen, sondern klare aussagen darueber, was passiert ist und wie man das problem loesen kann." DAS PROBLEM, NACHGEMESSEN. Der Server antwortet im Fehlerfall mit { fehler: "..." }. Darin stehen ZWEI verschiedene Dinge, und von aussen sehen sie gleich aus: Maschinenkennungen (nicht_verfuegbar, nicht_gefunden, ungueltig -- 43 verschiedene) und fertige deutsche Saetze. An 84 Stellen stand `textContent = d.fehler` -- ungefiltert. Wer beim Hochladen einer Datei Pech hatte, las woertlich "nicht_verfuegbar" auf dem Bildschirm und wusste nicht einmal, ob er selbst schuld war. Gezaehlt: 474 Antworten mit "nicht_verfuegbar", 392 mit "nicht_gefunden", 125 mit "ungueltig". DREI AUSGAENGE, NICHT ZWEI. `sagWas()` in workspace/assets/js/meldung.js: bekannte Kennung -> ihr Satz unbekannte Kennung -> der Ersatzsatz der Stelle, NIE die Kennung (sie geht in die Konsole, wo sie jemandem auffaellt, der sie beheben kann) fertiger Satz -> unveraendert durch Erkannt wird eine Kennung daran, dass sie nur aus Kleinbuchstaben, Ziffern und Unterstrichen besteht. Ein deutscher Satz hat immer Leerzeichen; eine Kennung nie. Die Unterscheidung ist entschieden, nicht geraten. UND WARUM DIE TABELLE NICHT ALTERN KANN. Eine von Hand gepflegte Liste ist hier schon zweimal teuer geworden (die abgeschriebene Spaltenliste, die feste Umbruchschwelle). Deshalb rechnet pruef-meldungen.mjs die Kennungen AUS DEM SERVER aus statt sie zu kennen -- eine neue ohne Satz macht sie rot. Man kann es nicht mehr vergessen. Sie prueft drei Dinge und beweist zu jedem, dass sie auch "nicht in Ordnung" sagen kann: 1. vollstaendig -- jede Kennung hat einen Satz 2. angeschlossen -- keine Rohanzeige, und jede Seite, deren Skript sagWas benutzt, laedt auch meldung.js 3. lesbar -- kein Satz enthaelt Kennung, Zahl oder englisches Wort GEFUNDEN HAT SIE SOFORT EINEN ECHTEN FEHLER: leistung.html laedt seine Skripte ohne `defer` und fiel damit durch meinen Einbau. Dort waere sagWas nicht definiert gewesen -- aus einer Fehlermeldung waere ein Absturz geworden, also schlimmer als vorher. NEBENBEFUND, DER MICH FAST EINE FALSCHE MELDUNG GEKOSTET HAETTE: "alter_offen" heisst NICHT "etwas Aelteres ist offen", sondern "Altersbestaetigung steht noch aus" (workspace.js:4864). Geraten haette ich es falsch uebersetzt. GEMESSEN: pruef-meldungen 8/0, alle 46 Skripte syntaktisch in Ordnung. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 14:46:13 +02:00

Author

SHA1

Message

Date

DogFatherGitandClaude Opus 5

67a0eb8717

DogFather konnte einen zweiten DogFather nicht mehr herabstufen

Gefunden beim Durchsehen der schnellen Pruefungen: pruef-haus-trennung
stand auf 60 ok / 6 Fehler. Drei Ursachen, eine davon ein echter
Rueckschritt von gestern.

--- 1. DER RUECKSCHRITT ---------------------------------------------

In darfRolleAendern stand seit gestern:

  if (person.rolle === "admin") return ziel.rolle !== "admin";

Das macht aus "DogFather ist nicht mehr VERGEBBAR" ein "an einem
DogFather ist nichts mehr zu aendern". Ein zweiter Zugang liess sich
damit nie wieder zuruecksetzen -- er waere fuer immer DogFather
geblieben. Die Pruefung sagte es woertlich: "solange es zwei gibt,
darf einer wechseln (403)".

Die beiden echten Gefahren haengen woanders und bleiben unberuehrt:
Niemand KANN 'admin' vergeben, und der LETZTE DogFather laesst sich
nicht herabstufen.

--- 2. ZWEI SCHLOESSER FUER DIESELBE TUER ---------------------------

Ich hatte gestern `rollenZumAendern` mit 403 VOR die vorhandene
Pruefung gesetzt, die mit 400 "Unbekannte Rolle." antwortet. Damit war
die Luecke wieder offen, vor der der Kommentar vom 17.09. direkt
daneben warnt: Zwei verschiedene Antworten -- "gibt es nicht" gegen
"darfst du nicht" -- verraten beim Durchprobieren, WELCHE Rollen
existieren.

Jetzt eine Regel an einer Stelle. `darfAnlegen` ist dort raus, weil
Vergeben und Anlegen seit gestern verschiedene Dinge sind. Gemessen:

  admin   anlegen = aendern (sieben Rollen)
  spicy   anlegen = aendern (vier)
  hand    anlegen = —        aendern = modi, gast
  manager anlegen = creator  aendern = —

Und die eigene Zeile bekommt jetzt 400 mit einem Satz statt 403:
Es ist keine Rechtefrage, sondern eine unsinnige Bitte.

--- 3. DREI ERWARTUNGEN, DIE AELTER WAREN ALS DIE REGEL --------------

Die Pruefung verlangte 403, wo seit dem 17.09. 400 richtig ist --
ihre Zeile stammt vom 10.09., sieben Tage aelter als die Regel. Und
sie verlangte 404 fuer "die rechte Hand vergibt keine Rolle", was bis
vorgestern stimmte.

Dabei fiel auf, dass NICHTS geprueft hat, ob die rechte Hand ihre neue
Faehigkeit ueberhaupt ausueben kann -- nur, dass sie es nicht darf.
Eine Pruefung, die nur das Verbotene misst, laesst offen, ob das
Erlaubte geht. Jetzt beide Richtungen:

  an einer anderen rechten Hand aendert sie nichts (403)
  und an DogFather erst recht nicht (403)
  einen Modi macht sie sehr wohl zur Community (200)
  und es steht so in der Datenbank (gast)
  eine zweite rechte Hand ernennt sie nicht (400)

Nebenbei: `unbekannte_kachel` (gestern eingefuehrt) hatte keinen Satz
in meldung.js -- die Kennung waere woertlich auf dem Bildschirm
gelandet. pruef-meldungen hatte es gemeldet.

Und ein Absturz beim Bauen: `const anlegen = await hole(...)` weiter
unten im selben Block verdeckt die gleichnamige Funktion im GANZEN
Block, auch oberhalb seiner eigenen Zeile.

pruef-haus-trennung: 70 ok, 0 Fehler (vorher 60/6).
Dazu gruen: rollen-anlegen 11/0, personen-loeschen 40/0,
rechte-umstellen 46/0, verteilen 11/0, meldungen 8/0.

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

2026-09-20 23:13:27 +02:00

DogFatherGit

0f5faf7ee6

Eine Seite, die nicht laedt, sagt es -- und bietet einen Weg zurueck

Fuenf Suchlaeufe parallel, ihre Funde selbst nachgemessen und behoben.

DER GROESSTE: 13 VON 21 SEITEN SCHLUCKTEN JEDEN NETZFEHLER.
Jede Seite beginnt mit `try { await hole('/api/ich') } catch { return; }`.
Faellt das Netz aus -- Aufzug, U-Bahn, Funkloch --, bricht der Block ab,
und die Seite bleibt fuer immer auf "wird geladen …" stehen. Gemessen:
0 von 32 Stellen setzten `aria-busy` im Fehlerfall zurueck, und es gab
KEINEN EINZIGEN "Nochmal versuchen" auf allen 21 Seiten.

Im Code stand der richtige Satz dazu -- an genau einer Stelle:
"Ein Platzhalter, der nie ersetzt wird, ist eine Luege mit
Fortschrittsanzeige." Er galt ueberall ausser dort.

Neu: window.ladefehler() in meldung.js. Sie ersetzt alles, was gerade
"laedt", durch drei Dinge: was los ist, was das bedeutet, und einen
Knopf, der es noch einmal versucht -- ohne die Seite neu zu laden.
21 Dateien angeschlossen. Neu: server/pruef-ladefehler.mjs, 26/0, mit
abgeklemmtem Netz im echten Browser.

UND DIE STARTSEITE WARF BEI EINEM FUNKLOCH AUF DIE ANMELDUNG.
`catch { location.assign('/workspace/') }` -- der Mensch glaubt, er sei
rausgeworfen, und tippt seinen Code neu. Dabei haelt seine Sitzung 12
Stunden; nur die Anfrage kam nicht durch. Umgeleitet wird jetzt nur
noch bei einer ANTWORT, die das sagt (401).

DER ANMELDEHINWEIS FUEHRTE MODIS IN DIE SPERRE.
Nach zwei Fehlversuchen stand: "Stimmt die Auswahl oben? Ein Code
gehoert immer zu genau einer davon." Auf der Crew-Wand ist das FALSCH
-- `stillerZugang()` sucht ueber die Codekennung, die angetippte
Kachel spielt fuer hand/modi keine Rolle. Sie probieren alle vier
durch, sammeln vier Fehlversuche, und nach acht in zehn Minuten ist
ihre Adresse gesperrt. Ein Hinweis, der die Sperre herbeifuehrt, gegen
die er helfen soll. Auf der Agenturwand stimmt der Satz weiter --
deshalb wird gefragt, auf welcher Wand man steht.
Dazu: Die Crew-Wand nannte nur der Community einen Weg ("Frag im Live
nach"). Wer zum Team gehoert und dessen Code nicht geht, fand dort
niemanden.

SACKGASSE AUF DER KERNSEITE EINES MODI.
treff-moderation sagte: "Zugaenge legst du in 'Personen & Zugaenge'
an" -- eine Seite, die ein Modi nicht oeffnen darf. Am ersten Tag, bei
leerer Community, war das der einzige Satz im Abschnitt. Jetzt fragt
die Seite ueber `window.__ich.seiten`, ob es den Weg fuer DIESEN
Menschen gibt. Und ein 404 wirft ihn nicht mehr wortlos auf die
Startseite.

TOTE KNOEPFE AN FREMDEN KARTEN.
"◀ zurueck" und "▶ In Arbeit" standen an JEDER Aufgabenkarte, auch an
fremden. Ein Modi sieht das Brett des ganzen Teams; er tippt, der
Server lehnt mit 403 ab, und die Meldung erscheint GANZ OBEN. Bei
einer Karte weiter unten sieht er nichts. Zwei Zeilen tiefer stand die
Regel im Klartext: "niemandem etwas anzubieten, das dann abgelehnt
wird." Der Server schickt jetzt `darf_aendern` mit.

13 STELLEN ROLLTEN GEGEN DEN WILLEN DES NUTZERS.
`scrollIntoView({ behavior: 'smooth' })` beachtet "Animationen
reduzieren" NICHT. Wer das eingestellt hat, hat es meist wegen
Schwindel getan. Zwei Stellen fragten vorher, dreizehn nicht.
Jetzt `window.sanft()`, einmal statt dreizehnmal.

DAS WORT UEBER DEN BRETTERN EINES MODI HIESS "BETREUUNG".
Fest im HTML, ueberschrieben nur bei Brettern mit eigenem `ober` --
sechs haben keines. Jetzt faellt es auf die GRUPPE der Kachel zurueck,
ueber die er hergekommen ist. Je Rolle richtig, ohne zweite Liste.

DER HINWEIS-ZU-KACHEL-WEG WAR DOPPELT KAPUTT.
`bereichZu` suchte nur in GRUPPEN -- der Liste der AGENTUR. Die
Kacheln von Team Dogi schickt der Server; fuer einen Modi fand die
Zeile entweder nichts oder eine fremde Kachel und uebernahm deren
Farbe. Und sie suchte ueber den NAMEN: "LIVE-Analyse" heisst auf der
Crew-Adresse "Live-Ablauf". Beim Beheben erst den Namen umgedreht --
und damit die Agenturseite kaputt gemacht (pruef-start-ansicht sofort
rot). Jetzt ueber das ZIEL, das in beiden Haeusern dasselbe ist.

UND EIN BRETT WAR SEIT GESTERN GESPERRT.
`TREFF_BRETTER` wird aus Kachelzielen abgeleitet. Als die Kachel
"Regeln & Hilfe" am 19.09. auf `treff-regeln.html` umgelenkt wurde,
fiel `regeln` heraus -- und `treff-regeln.html` verweist weiterhin
darauf ("Haeufige Fragen stehen auf dem Brett Regeln & Hilfe").
Gefunden hat es pruef-treff, die seit gestern rot war. 72/0.

NEBENBEI 7 SEITEN LEICHTER: meldung.js wird jetzt abgeleitet
eingebunden -- nur dort, wo sagWas/ladefehler/sanft wirklich
gebraucht werden. Die Anmeldewand traegt es nicht mehr.

Gruen: pruef-ladefehler 26/0, pruef-sackgassen 11/0 (582 Wege, 0 ins
Leere), pruef-start-ansicht, pruef-treff 72/0, pruef-treffchat,
pruef-community-sicht 10/0, pruef-aufgabenbrett, pruef-code 17/0,
pruef-chat-optik, pruef-nachfrage 49/0, pruef-meldungen 8/0,
pruef-css-klassen, pruef-tippziele 11/0, pruef-leerzustand 13/0,
pruef-rechtetafel.

2026-09-20 15:49:57 +02:00

DogFatherGitandClaude Opus 5

461d41943a

Keine Maschinensprache mehr auf dem Bildschirm

Filipe: "keine kryptischen oder technischen fehlermeldungen, sondern
klare aussagen darueber, was passiert ist und wie man das problem
loesen kann."

DAS PROBLEM, NACHGEMESSEN.

Der Server antwortet im Fehlerfall mit { fehler: "..." }. Darin stehen
ZWEI verschiedene Dinge, und von aussen sehen sie gleich aus:
Maschinenkennungen (nicht_verfuegbar, nicht_gefunden, ungueltig -- 43
verschiedene) und fertige deutsche Saetze.

An 84 Stellen stand `textContent = d.fehler` -- ungefiltert. Wer beim
Hochladen einer Datei Pech hatte, las woertlich "nicht_verfuegbar" auf
dem Bildschirm und wusste nicht einmal, ob er selbst schuld war.

Gezaehlt: 474 Antworten mit "nicht_verfuegbar", 392 mit
"nicht_gefunden", 125 mit "ungueltig".

DREI AUSGAENGE, NICHT ZWEI.

`sagWas()` in workspace/assets/js/meldung.js:
  bekannte Kennung   -> ihr Satz
  unbekannte Kennung -> der Ersatzsatz der Stelle, NIE die Kennung
                        (sie geht in die Konsole, wo sie jemandem
                        auffaellt, der sie beheben kann)
  fertiger Satz      -> unveraendert durch

Erkannt wird eine Kennung daran, dass sie nur aus Kleinbuchstaben,
Ziffern und Unterstrichen besteht. Ein deutscher Satz hat immer
Leerzeichen; eine Kennung nie. Die Unterscheidung ist entschieden,
nicht geraten.

UND WARUM DIE TABELLE NICHT ALTERN KANN.

Eine von Hand gepflegte Liste ist hier schon zweimal teuer geworden
(die abgeschriebene Spaltenliste, die feste Umbruchschwelle). Deshalb
rechnet pruef-meldungen.mjs die Kennungen AUS DEM SERVER aus statt sie
zu kennen -- eine neue ohne Satz macht sie rot. Man kann es nicht mehr
vergessen.

Sie prueft drei Dinge und beweist zu jedem, dass sie auch "nicht in
Ordnung" sagen kann:
  1. vollstaendig -- jede Kennung hat einen Satz
  2. angeschlossen -- keine Rohanzeige, und jede Seite, deren Skript
     sagWas benutzt, laedt auch meldung.js
  3. lesbar -- kein Satz enthaelt Kennung, Zahl oder englisches Wort

GEFUNDEN HAT SIE SOFORT EINEN ECHTEN FEHLER: leistung.html laedt seine
Skripte ohne `defer` und fiel damit durch meinen Einbau. Dort waere
sagWas nicht definiert gewesen -- aus einer Fehlermeldung waere ein
Absturz geworden, also schlimmer als vorher.

NEBENBEFUND, DER MICH FAST EINE FALSCHE MELDUNG GEKOSTET HAETTE:
"alter_offen" heisst NICHT "etwas Aelteres ist offen", sondern
"Altersbestaetigung steht noch aus" (workspace.js:4864). Geraten
haette ich es falsch uebersetzt.

GEMESSEN: pruef-meldungen 8/0, alle 46 Skripte syntaktisch in Ordnung.

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

2026-09-19 14:46:13 +02:00