Filipe: "jede kiste soll seine eigene farbe haben. und die kacheln sollen
viel spezieller, viel spezieller sein."
BEIM ERSTEN MAL HATTE ICH ABGELEHNT, und das war zu bequem. Mein Einwand
stimmte zwar -- ein Versuch mit frei gewaehlten Farben ergab Paare mit
1,4 Grad Abstand, also praktisch dieselbe Farbe -- aber daraus "geht
nicht" zu machen, war falsch. Es geht, man muss nur rechnen.
Der Denkfehler war die Annahme, alle 17 muessten sich voneinander
unterscheiden. Das Auge vergleicht aber nur, was NEBENEINANDER liegt.
Also:
1. 17 Toene, gleichmaessig um den Farbkreis (je 21 Grad), gerechnet in
OKLCH -- dort sind gleiche Abstaende auch fuer das Auge gleich.
Helligkeit und Farbstaerke konstant, damit keine sich vordraengt. Wo
die Farbstaerke den darstellbaren Bereich verliesse (Gelb und Gruen
frueher als der Rest), wird sie gesenkt, bis sie hineinpasst.
2. Die ZUORDNUNG ist eine Suche ueber die tatsaechlichen Nachbarschaften
im Raster (nebeneinander UND untereinander). Gesucht: die Anordnung
mit dem groesstmoeglichen kleinsten Nachbarabstand. Ergebnis:
mindestens 105,9 Grad zwischen allen Nachbarn.
3. Unter allen Anordnungen, die eine harte Untergrenze schaffen, gewinnt
die passendste: LIVE rot, Technik gelb, Reports gruen, Personen
rot-gold, Schutz stahlblau.
Steht als tools/kachel-farben.mjs im Repo, mit festem Zufallsstartwert --
derselbe Lauf ergibt dieselben Farben. Wer Kacheln umsortiert, aendert
die Nachbarschaften und muss es neu laufen lassen; das steht auch in
start.js.
Geprueft: Helligkeitsband, Farbstaerke und Kontrast bestehen fuer alle
siebzehn gegen genau diesen Hintergrund.
VIEL SPEZIELLER -- das WASSERZEICHEN:
Jede Kachel traegt ihr eigenes Zeichen noch einmal, riesig, angeschnitten
und fast unsichtbar (7 % Deckung) in der Ecke. Das ist der Grund, warum
siebzehn Kacheln nicht mehr wie siebzehn Kaesten aussehen: Jede bekommt
eine eigene grosse Form, ohne dass ein einziges zusaetzliches Bild
geladen wird -- es ist derselbe Pfad, nur groesser. Bewusst so schwach,
dass man es nicht liest, sondern nur spuert. Beim Ueberfahren wird es
etwas deutlicher und wandert zwei Pixel.
Dazu: Zeichenfeld 46 auf 52 px mit farbigem Schein darunter, Name auf
1,06 rem, mehr Polsterung. Alles mit prefers-reduced-motion abgesichert.
44 Pruefungen. Neu: dass jede Kachel eine EIGENE Farbe hat (17 Farben auf
17 Kacheln, gemessen an der berechneten Strichfarbe) und dass das
Wasserzeichen da und schwach genug ist.
Co-Authored-By: Claude Opus 5 <[email protected]>
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]>
Eine Sicherung, die auf derselben Platte liegt wie das Original, ist keine
-- sie hilft gegen versehentliches Loeschen, nicht gegen einen
Plattenausfall. tools/sicherung-holen.sh holt sie deshalb auf den
Arbeitsrechner.
Dabei ist gleich eine zweite Luecke aufgefallen und mitgeschlossen: Die
Datenbank kennt hochgeladene Dateien und die PDFs der Bibliothek nur ueber
ihren Namen -- die Dateien selbst liegen daneben im Dateisystem und
stecken NICHT in der Datenbanksicherung. Nach einem Plattenausfall haette
man eine Bibliothek voller Verweise auf PDFs, die es nicht mehr gibt.
Werden jetzt mitgeholt.
Bewusst nur auf dem PC und nicht zusaetzlich auf dem Server: Eine zweite
Kopie auf derselben Platte haette gegen nichts geholfen, was die erste
nicht schon ueberlebt haette. Und weil scp nie loescht, bleibt ein einmal
geholtes PDF hier erhalten, auch wenn es auf dem Server verschwindet.
Geprueft wird mit Node statt mit dem sqlite3-Programm: Node bringt SQLite
selbst mit, auf diesem Windows-Rechner ist sqlite3 gar nicht da -- die
erste Fassung gab nur Fragezeichen aus und meldete trotzdem "fertig".
WIEDERHERSTELLUNG.md beschreibt drei Faelle (aus Versehen geloescht /
Datenbank zurueckspielen / Server ganz weg), jeweils als EIN Block zum
Kopieren. Der Ruecklauf legt den kaputten Stand mit mv zur Seite statt
ihn zu loeschen -- falls die Sicherung aelter war als gedacht.
Co-Authored-By: Claude Opus 5 <[email protected]>
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]>
DogFatherGitandClaude Opus 5