Beim Installieren als App sahen alle Dienste gleich aus. Nicht wegen der
Symbole - die sind seit heute Mittag gut unterscheidbar - sondern wegen
der Farbe: zwoelf von vierzehn trugen dasselbe Fast-Schwarz (#05070b,
#05070d, #0a0910, #0b0d10, #0d0817, #0e0a16). Das ist die theme_color,
also am PC die Titelleiste des App-Fensters und am Handy die Statusleiste.
Neu, je App eine Farbe, abgeleitet vom eigenen Symbol:
Hauptseite #065f76 Petrol (Symbol stahlblau)
DogiCrew-Verwaltung #8d4125 Kupfer (Symbol orange)
Webdesign #564e95 Violett (Symbol lila)
Kundenportal #924985 Magenta (Symbol pink)
WD-Verwaltung #b44f5e Rose (Symbol rot)
Creator Workspace #0674b9 Blau (Symbol nachtblau)
Nextcloud (#17a5a6) bleibt unveraendert - als einzige hob sie sich schon ab.
WICHTIG war, beide Stellen zu aendern: Die meta-Angabe im HTML
ueberschreibt die theme_color aus dem Manifest. Nur das Manifest zu
aendern haette gar nichts bewirkt.
Der background_color (Startbildschirm beim Oeffnen) bleibt bewusst sehr
dunkel, nur leicht in Richtung der App-Farbe getoent - kraeftig ist nur
die schmale Leiste, damit nichts grossflaechig aufblitzt (Vorgabe
augenschonend).
Wie die Farben entstanden sind: Zwei Entwuerfe fielen bei der eigenen
Pruefung durch. In HSL gerechnet lagen Workspace und Webdesign bei einem
Farbabstand von 12.6 statt der noetigen 25 - auf dem Papier 30 Grad
auseinander, fuers Auge dasselbe Blauviolett. Auch der zweite Versuch
scheiterte (Hauptseite zu nah an Nextclouds Tuerkis, 19.1). Neun Farben
bei gleicher Helligkeit passen schlicht nicht mit genug Abstand auf den
Farbkreis. Erst mit der Helligkeit als dritter Dimension und einem
Optimierer, der den KLEINSTEN Abstand im Satz maximiert, kam ein Satz
heraus, der haelt: kleinster Abstand 25.5.
Geprueft: 68 Farbpruefungen (weisse Schrift ueberall lesbar 5.0-7.2:1,
keine blendet, jede hebt sich vom bisherigen Schwarz ab, alle Paare
>= 25 Delta E) und 101 Browserpruefungen ueber 16 Seiten (Manifest und
meta stimmen ueberein, genau eine theme-color je Seite, Symbole
vorhanden) - alle gruen, Gegenprobe schlaegt an.
Co-Authored-By: Claude Opus 5 <[email protected]>
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]>
Nutzer-Wunsch 20.08.2026: "ich will die Verwaltungsseite auch herunter
laden koennen, so dass ich die originale website und die verwaltungsseite
2 mal getrennt installieren kann, auf dem pc und handy."
- Eigenes manifest-verwaltung.json (eigene "id"/"scope" nur fuer
verwaltung.html, eigener Name "DogiCrew-Verwaltung", eigenes
Icon-Set) statt des site-weiten manifest.json (scope "/") -- macht sie
zu einer technisch eigenstaendigen App-Identitaet, installierbar
parallel zur Haupt-Website, auf Desktop und Handy.
- Neue Icons: bestehendes Husky-Logo mit Violett/Gold-Verlauf statt
Babyblau (passend zum "Jewelen-Tresor"-Look der Verwaltungsseite),
damit beide installierten Apps auch optisch klar unterscheidbar sind.
- Kein zweiter Service Worker noetig -- /sw.js laeuft bereits site-weit
auf Scope "/" und deckt verwaltung.html automatisch mit ab.
Co-Authored-By: Claude Opus 5 <[email protected]>
DogFatherGitandClaude Opus 5