e3aeeb01cde0b32fb0ecc7590befcfecaa887c45
9
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
a04748b82f |
Excel-Dateien: keine Sackgasse mehr im Auswahlfenster
Filipe: "wenn ich auf screen1 druecke geht mein ordner auf aber meine
excel datei kann ich nicht auswaehlen wieso??"
Im Feld stand accept=".csv,text/csv,text/plain". Die .xlsx war damit
ausgegraut -- ohne ein Wort dazu. Eine Sackgasse ohne Wegweiser ist
schlimmer als eine Absage mit Begruendung: Man sucht den Fehler bei
sich.
WARUM SIE NICHT EINFACH GELESEN WIRD: Der Leser dahinter (csvZerlegen)
versteht Text -- Komma, Semikolon, Tabulator. Eine .xlsx ist in
Wahrheit ein ZIP-Archiv. Als Text gelesen ergibt sie Zeichensalat, und
der schlimmste Ausgang waere nicht "geht nicht", sondern eine Vorschau
mit Zahlen aus dem Dateikopf. Das Feld einfach zu oeffnen, ohne den
Fall zu behandeln, haette aus einer klaren Sperre einen unklaren
Fehlschlag gemacht.
Jetzt laesst sich jede Datei waehlen, und WAS sie ist, sagt der INHALT
-- die ersten Bytes, nicht die Endung. Eine umbenannte Datei ist keine
andere Datei. .xlsx beginnt mit "PK" (ZIP), die alte .xls mit dem
OLE-Kennzeichen D0 CF 11 E0.
Und dann steht da, was stattdessen zu tun ist, mit ZWEI Wegen:
1. In Excel markieren, Strg+C, und den Knopf "Backstage-Tabelle
einfuegen" nehmen -- der versteht TAB-getrennte Zeilen, also genau
das, was beim Kopieren aus Excel in der Zwischenablage liegt. Das
geht sofort und ohne Umspeichern.
2. Oder in Excel als "CSV UTF-8" speichern.
Der erste Weg funktionierte schon vorher -- er stand nur nirgends.
Nebenbei: Eine leere Datei meldet jetzt "Die Datei ist leer" statt
durch die Vorschau zu laufen, und eine abgewiesene Datei bleibt nicht
im Feld stehen.
pruef-backstage-import 66 -> 72. Geprueft wird an einem echten
ZIP-Kopf, nicht an der Endung: Die Testdatei heisst .xlsx UND traegt
das Kennzeichen -- eine Pruefung ueber den Namen waere gruen, ohne die
Erkennung je zu beruehren. Mit Gegenprobe, dass eine echte CSV
denselben Weg weiterhin durchlaeuft; sonst hiesse das nur, dass gar
nichts mehr eingelesen wird.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
14ed467928 |
Der Weg ueber die TikTok-Datei des Creators ist entfernt
Filipe, mit den drei Knoepfen im Bild: "ich will nur dass wir manager
scouts, dogfather oder spicy sachen eintragen koennen und nicht die
creator. ich will keine daten von denen kriegen, nur wir."
Gebaut am Vormittag, am Nachmittag wieder ausgebaut. Der Weg war
technisch in Ordnung -- und er war der einzige, bei dem ein CREATOR uns
etwas gibt: seine eigene Datenkopie aus der TikTok-App. Genau das soll
nicht sein. Es bleiben die beiden Wir-Wege: die eigene Datei und die
Backstage-Tabelle der Agentur.
VOLLSTAENDIG ENTFERNT, NICHT VERSTECKT:
- beide Schnittstellen (/tiktok-datei und /tiktok-datei/vorschau)
- der Leser workspace-tiktok-datei.js (263 Zeilen)
- Knopf, Fenster, Dateiauswahl, Vorschau, Stilregeln
- der fertige Text, der einen Creator um seine Daten bittet
- der Erklaersatz unter der Knopfreihe
Ein Weg, der nur unsichtbar ist, ist weiterhin ein Weg -- wer die
Adresse kennt, benutzt ihn. Und eine Bitte an einen Creator um seine
Daten soll in diesem Haus nirgends mehr stehen, auch nicht in einem
Fenster, das niemand oeffnet.
GEPRUEFT WIRD JETZT DIE ABWESENHEIT, an drei Stellen: Knopf weg,
Fenster weg, und die Schnittstelle antwortet DOGFATHER mit 404 -- dem
staerksten Zugang, den es gibt. Bekommt er 404, bekommt ihn jeder.
Daneben die Gegenprobe, dass der Backstage-Weg weiterhin mit 200
antwortet; sonst bewiese das 404 nur einen Tippfehler.
pruef-tiktok-datei.mjs (47 Pruefungen) faellt mit dem Weg weg. Die
Zahl sinkt dadurch, und das ist hier richtig: Sie pruefte etwas, das
es nicht mehr gibt. Was bleibt, sind sechs Pruefungen, die das
Fehlen sichern -- pruef-backstage-import 63 -> 66.
NEBENBEI GEDREHT, NICHT GELOESCHT: pruef-leistung-optik behauptete
noch die Regel vom 07.09. ("beim Manager fehlt die Kachel", "die Seite
weist den Creator ab"). Beide Aussagen sind jetzt umgekehrt und messen
zusaetzlich, was vorher niemand gemessen hat: dass die Creatorin auf
der Zahlen-Seite ihre EIGENEN Zahlen sieht und trotzdem keinen
einzigen Knopf zum Eintragen hat -- beides zusammen, denn "keine
Knoepfe" waere auch auf einer leeren Seite wahr. 56 -> 59.
Nicht von mir, nachgemessen gegen den Stand ohne diese Aenderungen:
pruef-struktur meldet dieselben 6 Fehler (crew-index/teamlage nicht
verlinkt, start.css 348 KB, totes CSS .nase, UTC-Datum).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8d3a79ed2a |
Zahlen-Seite: wieder fuer alle fuenf Rollen
Filipe, mit der Kachel im Bild: "jetzt soll jede rolle diese kachel sehen. spicy, dogfather, manager, scout und creator. aber die creator kriegen dan quasi nur ihre daten zu sehen und der manager scout dogfather oder spicy koennen eintragen." Damit ist die Sperre vom 07.09.2026 aufgehoben. Geaendert sind genau zwei Zeilen -- die Kachel in bereiche.js und die Tuer in workspace.js. Ausdruecklich als Liste der fuenf Rollen, NICHT als `null`: `null` hiesse auch jede Rolle, die es noch nicht gibt. WER WAS DARF, musste ich nicht bauen -- es stand schon da und konnte nur niemand benutzen: sichtbareCreatorIds() gibt einem Creator genau seine eigene Nummer, darfEintragen() ist Leitung plus Scout. Das ist exakt Filipes Satz, ohne eine einzige Aenderung am Server. WAS DER UMBAU AUFGEDECKT HAT: "Aus Datei einlesen" hatte als einziger Knopf NIE eine Rechteregel -- folgenlos, solange nur DogFather hereinkam, ab heute haette ein Creator ihn gesehen und eine Absage bekommen. Alle drei Eintrag-Knoepfe stehen jetzt in EINER Liste mit ihrer Regel daneben, und der Knopf startet `hidden`, damit er nicht kurz aufblitzt. Gefunden hat das nicht das Nachdenken, sondern die Gegenprobe von heute Mittag: Sie wurde rot, weil der Test-Scout auf der Startseite landete -- waehrend ich nebenan eine Erklaerung "fuer Scouts und Manager" schrieb fuer eine Seite, die beide gar nicht oeffnen konnten. pruef-backstage-import: 36 -> 50 Pruefungen. Gemessen wird der UNTERSCHIED zwischen den Rollen, nicht die Anwesenheit von irgendetwas: jeder Knopf einzeln, bei Scout und Creator, dazu die Kachel auf der Startseite und die Gegenprobe, dass die Zahlen des Creators trotzdem dastehen. Sonst waere "der Creator sieht keinen Knopf" auch dann gruen, wenn seine Seite leer bliebe. Mit SCHIRM=1 legt die Pruefung zwei Bilder ab, eins je Rolle. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
f171d0cffd |
Workspace: Anleitung neben beiden Import-Knoepfen
Scouts und Manager sollen nicht raten muessen, woher die Zahlen kommen.
Unter der Knopfreihe steht jetzt dauerhaft (sobald einer der beiden Knoepfe
sichtbar ist), was die beiden Quellen sind: Backstage-Tabelle = Agenturzahlen
fuer alle auf einmal, TikTok-Datei = die Datei, an die nur der Creator selbst
kommt.
Backstage-Dialog: fuenf nummerierte Schritte. Der wichtigste davon ist
"Ueberschriftenzeile mitmarkieren" -- ohne sie kann der Server die Spalten
nicht benennen, und genau das war beim Testen der haeufigste Fehlgriff.
Dazu zwei stille Absaetze: woher die Zuordnung kommt (TikTok-Name im
Steckbrief) und warum das nicht automatisch geht.
TikTok-Dialog: der fertige Text zum Weiterleiten an den Creator, mit
Kopierknopf. Nennt JSON statt TXT (eine TXT-Datei laesst sich nicht
auswerten), die 1-4 Tage Wartezeit, und dass die Datei nur gelesen und
nicht gespeichert wird.
Bewusst KEIN erfundener Klickpfad durch Backstage: TikTok dokumentiert die
Menuenamen nirgends oeffentlich, und eine erfundene Beschriftung ist beim
naechsten Umbenennen schlimmer als keine. Beschrieben wird deshalb, WORAUF
zu achten ist ("die Tabelle mit den Zahlen"), das bleibt wahr.
Der Kopierknopf meldet einen Fehlschlag, statt Erfolg vorzutaeuschen.
pruef-backstage-import: 29 -> 36 Pruefungen, alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
027c372afd |
Die TikTok-Datei des Creators -- ohne Entwicklerkonto
Filipe: "tiktok entwicklerkonto hab ich nicht und werd ich nicht
bekommen."
Damit sind zwei der drei Wege aus dem Plan vom 10.09. erledigt: Login
Kit und die Datenportabilitaets-API haengen beide an einer App auf
developers.tiktok.com. Sie sind nicht verschoben, sie sind weg.
DER DRITTE BRAUCHT KEINES. Jeder TikTok-Nutzer kann seine eigenen Daten
selbst herunterladen (Profil -> Einstellungen -> Konto -> Deine Daten
herunterladen, Format JSON). Die Datei enthaelt laut TikToks eigener
Datentypen-Liste einen Abschnitt "TikTok LIVE" mit dem Go-LIVE-Verlauf.
Der Creator gibt sie her, mit eigenen Haenden -- legitimer wird es
nicht, und es ist jetzt der einzige verbliebene Weg an TikTok-Daten.
ICH KENNE DAS FORMAT NICHT -- UND BAUE TROTZDEM.
TikTok dokumentiert, DASS es den Verlauf gibt, nicht wie die Schluessel
heissen. Der naheliegende Weg waere, Namen zu raten. Das waere die
schlechteste Loesung: Er fiele bei der ersten echten Datei auseinander,
und zwar STILL -- "0 Eintraege gefunden" sieht aus wie "war nicht live".
Deshalb wird gesucht statt geraten. Der Leser geht die Datei durch,
sammelt ALLE Listen, deren Eintraege ein Datum tragen (gemessen am
INHALT, nicht am Feldnamen), schlaegt eine Zuordnung vor und legt sie
zur Auswahl vor -- mit Anzahl, Zeitraum, Beispielzeile und dem, was
dabei herauskaeme. Bestaetigt wird von Hand. Damit ist der Leser
unabhaengig davon, wie die Felder heissen.
DIE EINHEIT IST DIE FALLE. "83" kann Sekunden, Minuten oder Stunden
sein. Geraten wird NICHT aus der Zahl, sondern aus dem Schluesselnamen
-- und wo der schweigt, aus der Form ("01:23:45" ist eindeutig).
Schweigen beide, kommt null zurueck. Eine Dauer, die um Faktor 60
danebenliegt, sieht richtig aus und ist es nicht.
MEHRERE LIVES AN EINEM TAG SIND EIN TAG: Dauer und Diamanten addiert,
bei den Zuschauern gewinnt die hoehere Spitze -- ein Durchschnitt aus
zwei Streams waere eine Zahl, die es nie gegeben hat.
DIE DATEI UEBERSCHREIBT NICHTS. Anders als der Backstage-Import, der
die Wahrheit der Agentur bringt, ist diese Datei die ZWEITE Quelle. Wo
schon eine Zahl steht -- von Hand oder aus Backstage --, bleibt sie
stehen (COALESCE statt REPLACE). Sonst wuerde ein Dateiupload
stillschweigend die offiziellen Zahlen ersetzen, und niemand wuesste
hinterher, welche gilt.
UND SIE WIRD NICHT GESPEICHERT. Gelesen, ausgewertet, verworfen. In
derselben Datei stehen Direktnachrichten, Such- und Ansehverlauf; die
haben auf diesem Server nichts zu suchen. "Income and Wallet" bleibt
ebenfalls liegen: Diamanten sind Leistung, Auszahlungen sind Gehalt.
GEPRUEFT OHNE ECHTE DATEI -- MIT DREI ERFUNDENEN (47 Pruefungen):
A englisch, flach, Dauer in Sekunden
B deutsch, verschachtelt, Dauer als "01:23:45"
C Sekundenstempel, Dauer in Minuten, andere Namen
+ eine Datei ganz ohne Verlauf -> muss abgelehnt werden
Eine Pruefung gegen EINE ausgedachte Form wuerde nur beweisen, dass
mein Leser meine eigene Erfindung liest. Drei verschiedene zeigen, dass
er das Prinzip kann und nicht eine Form.
EIN EIGENER FEHLER, von der Pruefung gefunden: Der Nachrichtenverlauf
in Form A hatte nur EINEN Eintrag und fiel damit unter die
Mindestgroesse von zwei. Die Pruefung "der LIVE-Verlauf steht oben"
hatte danach nur einen Kandidaten und bewies gar nichts -- eine
Rangfolge laesst sich nur an mindestens zwei Dingen zeigen. Jetzt sind
es drei Nachrichten, und die Rangfolge ist wirklich gemessen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
017375d333 |
Backstage: eine Tabelle einfuegen, alle Creator auf einmal
Filipe: "mach diesen ganzen plan jetzt sofort auf einen schlag fertig."
Das ist Stufe 0 des Plans vom 10.09. -- der Teil, der ohne TikTok
auskommt und deshalb sofort baubar war.
WARUM EINFUEGEN UND NICHT ABRUFEN. Die Recherche vom 10.09. ergab:
TikTok LIVE Backstage hat keine Schnittstelle und keinen Export (zwei
unabhaengige Quellen), und in der offiziellen Scope-Liste von TikTok
gibt es nichts zu LIVE, Diamanten oder Netzwerkdaten. Was es gibt, ist
eine Tabelle im Browser. Also: markieren, kopieren, einfuegen. Kein
Token, kein Zugangsdatum, keine Erweiterung, die Backstages interne
Abfragen mitliest -- letzteres waere ein Verstoss gegen die
Nutzungsbedingungen und riskiert ausgerechnet das Netzwerkkonto.
DER UNTERSCHIED ZUM VORHANDENEN IMPORT ist genau eine Frage: Zu wem
gehoert diese Zeile? Der alte Weg nimmt eine Datei fuer EINEN Creator,
Backstage zeigt ALLE. Zugeordnet wird ueber `personen.tiktok` -- den
oeffentlichen Namen ohne @, den es im Steckbrief laengst gibt. Ohne @,
ohne Gross-/Kleinschreibung, ohne unsichtbare Zeichen aus der
Zwischenablage; faellt das aus, ueber den angezeigten Namen. Beides
ergebnislos -> die Zeile wird GEMELDET, nicht geraten. Eine falsch
zugeordnete Zahl ist schlimmer als eine fehlende, weil die fehlende
auffaellt.
DER TABULATOR WAR DER GANZE KNACKPUNKT. `csvZerlegen` kannte nur Komma
und Semikolon. Eine aus dem Browser kopierte Tabelle ist aber
TAB-getrennt -- ohne diese Zeile waere alles in Spalte 1 gelandet und
die Vorschau haette "keine Datumsspalte" gemeldet: eine richtige
Meldung auf eine falsche Faehrte. Gewaehlt wird jetzt das HAEUFIGSTE
der drei Zeichen, nicht das erste gefundene.
WAS NICHT PASSIERT, und genau das ist geprueft:
- unbekannte Person -> gemeldet mit Namen, nicht geraten
- Zeile ohne eine einzige Zahl -> uebersprungen (sie wuerde sonst
einen echten Tag mit Nullen ueberschreiben)
- Datum in der Zukunft -> abgelehnt
- dieselbe Tabelle zweimal -> ersetzt, verdoppelt nicht
- eine von Hand geschriebene Notiz -> ueberlebt den Import
- es wird niemand nebenbei angelegt
- kein Datum in der Tabelle und keines angegeben -> es wird GEFRAGT
NEUE PRUEFUNG (pruef-backstage-import, 29 Pruefungen) mit einer echten,
tab-getrennten Backstage-artigen Tabelle: drei Creator, einer davon
ohne Handle, einer mit abweichender Schreibweise, einer gar nicht im
Haus.
DREI EIGENE FEHLER, alle von der Pruefung gefunden:
* Die Spaltenerkennung nahm nur EINE Personenspalte. Ein Creator ohne
Handle fiel als "keine Person in der Zeile" durch, obwohl sein Name
danebenstand. Jetzt werden beide Spalten gemerkt und je Zeile
nacheinander versucht.
* Ein Scout bekam 400 statt 403 -- er kam durch `darfEintragen`
(das Scouts einschliesst) und scheiterte erst daran, dass er keinen
der Creator sieht. Richtige Antwort aus dem falschen Grund. Der
Netzwerk-Weg haengt jetzt an `istLeitung`, genau wie der Knopf.
* Die Vorschau meldete "2 von 3" statt "3 von 4" -- Folge des ersten
Fehlers.
Der Fusstext der Seite nannte zwei Wege, es sind jetzt drei. Ein Text,
der etwas anderes sagt als die Software tut, ist schlimmer als keiner.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
ac432d85e1 |
Spicy Media: sieben stille Luecken -- und der Kalender zeigt wirklich nur noch Eigenes
Filipe hat drei Sachen gemeldet. Zwei davon waren nicht das, wonach sie
aussahen.
1. "BEI DER SPICY ROLLE IST DA EIN PROBLEM" (Creator-Profil laedt nicht)
Nicht diese Seite war kaputt. In NEUN Skripten stand dieselbe Zeile
const LEITUNG = new Set(['admin', 'manager']);
und in keinem davon 'spicy'. profil.js nahm deshalb den Creator-Zweig
und lud das EIGENE Profil -- ein Spicy-Zugang ist kein Creator, also
404. Acht der neun sind nicht kaputtgegangen; sie haben sich still
falsch verhalten.
Die Liste steht jetzt EINMAL in bereiche.js. Beim Aufraeumen kamen mit
derselben Suche sechs weitere Luecken heraus, alle vom selben Typ:
* Aufgaben abbrechen -- Server UND Knopf ohne 'spicy'
* Teilen-Knopf in der Kopfleiste -- ohne 'spicy'
* Chat: die Gespraechsliste laeuft ueber eine feste Rollenfolge.
Wer nicht darin steht, taucht gar nicht auf -- eine Person, die es
fuer die anderen nicht gibt.
* Kalender: dieselbe Rollenfolge, dort landete Spicy Media durch
indexOf() === -1 ganz oben statt an ihrem Platz.
* Dashboard: "Creator anlegen" nur fuer admin/manager -- der Server
haette sie gelassen, den Knopf hat sie nie gesehen.
* Personenliste: ROLLENNAME ohne 'spicy'. Der Auffangwert
`|| p.rolle` schrieb "spicy" statt "Spicy Media" -- plausibel
genug, um jahrelang zu bleiben.
`pruef-css-klassen.mjs` verlangt jetzt, dass kein Workspace-Skript sich
wieder eine eigene Rollenliste baut. Mit Gegenprobe, dass der Sucher so
eine Liste auch wirklich findet.
2. "DIE ZAHLEN DIESE KATEGORIE NICHT SEHEN"
Kachel und Seite waren beim Anlegen der Rolle auf ["spicy","admin"]
gesetzt worden -- "dieselben Rechte ausser Automationen". Beides jetzt
auf DogFather allein.
3. "IN CIGDEMS KALENDER STEHT IMMER NOCH MEIN MANAGER MEETING"
Das war MEIN Denkfehler von heute Frueh, nicht ein vergessener Fall.
Ich hatte "geht alle an" als "kein Teilnehmer eingetragen" definiert --
also entschied der Server, was alle angeht, und nicht der, der den
Termin anlegt. Wer niemanden eintraegt, meint aber meistens nicht
"alle", sondern "mich".
Der Fall ist entfallen. Sichtbar ist ein Termin jetzt nur noch fuer
den, der ihn angelegt hat, dem er zugeordnet ist, der das Gegenueber
ist -- oder der in der Teilnehmerliste steht. Damit ist das Markieren
im Termin die einzige Antwort auf "wen geht das an": eine sichtbare
Entscheidung im Formular statt einer unsichtbaren Regel im Server.
Calls & Protokolle rufen dieselbe Funktion auf und koennen deshalb gar
nicht auseinanderlaufen -- das war Filipes vierter Wunsch, und er ist
mit derselben Zeile erledigt.
Am laufenden System als Cigdem nachgemessen: Profil laedt ("Profil:
Luna"), Zahlen-Kachel weg und Seite gesperrt, im Kalender NUR der
Termin, bei dem sie markiert ist, Calls zeigt genau denselben.
Fuenf Pruefungen auf die endgueltige Regel umgeschrieben statt
geloescht (sicht, spicy, teilnehmer, scout-zuteilung, css-klassen).
Die dritte Drehung bei scout-zuteilung steht mit allen drei Staenden
in der Akte -- eine geloeschte Pruefung hinterlaesst keine Spur davon,
dass hier einmal etwas anderes galt.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
1b2874299e |
Uhr und Glocke in die Begruessung, Teilen in die Leiste, ein echter Fehler weg
Neun Punkte aus Filipes Bildschirmfotos. Der wichtigste war kein
Aussehen, sondern ein Fehler:
UEBEREINANDERLIEGENDE TEXTE IN DER SICHERUNGSLISTE. Das Datum entstand
aus `name.split('-').slice(1).reverse().join('.')`. Bei
"woechentlich-2026-09-06.db" ging das gut; die Sicherungen vor einem
Umbau heissen aber "vorher-2026-09-02-160012438.db" -- mit Zeitstempel.
Heraus kam "160012438.02.09.2026", dreimal so lang wie die 96-px-Spalte,
und es lief ueber den Nachbartext. Ein Muster, das Bestandteile ZAEHLT
statt sie zu SUCHEN, bricht beim ersten Namen mit einem Teil mehr. Jetzt
ein Suchmuster nach vier-zwei-zwei Ziffern -- und in der CSS eine
Kuerzung, damit der NAECHSTE zu lange Text nur abgeschnitten wird. Eine
Spalte mit fester Breite ohne Kuerzung ist immer eine Zeitbombe.
DIE BEGRUESSUNGSKACHEL. Runde Digitaluhr rechts: zwei Ringe um dieselbe
Mitte -- innen die Sekunde, aussen der Stand der Stunde. Kein
setInterval(1000): Ein fester Takt laeuft mit der Zeit aus dem Tritt und
ueberspringt Sekunden; gewartet wird bis zur naechsten VOLLEN Sekunde.
Die Glocke ist aus der Kopfleiste hierhergezogen -- mit Rueckfall, denn
zwoelf andere Seiten haben diesen Platz nicht. Nebenbei ist die Leiste
damit um ein Element leichter; sie ist am 06.09. schon einmal an einem
sechsten zerbrochen.
TEILEN-KNOPF in der Leiste, nur fuer Scout, Manager und DogFather.
Geteilt wird der EINGANG, nicht die aktuelle Seite: Ein Link auf
bereich.html?b=schutz schickt jemanden auf eine Seite, die er nicht
sehen darf. Wo es navigator.share gibt, wird es benutzt; sonst
Zwischenablage; wo beides fehlt, erscheint der Knopf gar nicht -- ein
dritter Ausgang statt einer Schaltflaeche, die nichts tut.
WEITER: Kachelreihenfolge Steckbrief -> Profile -> Zahlen. Die
Tagesliste laesst sich zuklappen und zeigt dann SIEBEN Tage (die Woche,
nicht die vier von ueberall sonst). Dialoge, Automationen-Karten,
Sicherungsblock, KI-Kasten und Call-Karten bekommen dasselbe Material
wie die Kacheln -- Leuchtschiene, Materialstaerke, Glanz.
Profilbilder brauchten nichts: Der Weg gibt es fuer jede Rolle bereits
(steckbrief.html fuer die Betreuung, derselbe Block auf profil.html fuer
Creator, Hochladen schreibt immer auf req.person.id).
ZWEI EIGENE FEHLER, beide gemessen statt vermutet:
- Die Koernung lag in vier neuen Bloecken auf DERSELBEN Ebene wie die
Spiegelung und erbte deren 50 % Deckkraft. Gemessen rgb(56,44,58)
statt rgb(20,26,38) -- die Karten sahen durchsichtig aus, obwohl sie
zu 95 % decken. Derselbe Fehler wie heute Nachmittag an der
Anmeldekarte. Koernung gehoert auf eine eigene Ebene mit overlay.
- `.glocke-platz:empty { display: none }` liess die Kachel wachsen,
sobald die Glocke geladen war. Layout-Sprung von start.html: 0,708.
Platz wird jetzt reserviert -> 0,473.
pruef-struktur: `-breit` gehoert in die Stufen-Ausnahme. Schaerfe kostet
Bytes (hohe Frequenzen lassen sich nicht wegrechnen), die mittlere Stufe
wuchs auf 230-300 KB. Die Regel bleibt inhaltlich: gross nur, WENN eine
kleinere Stufe daneben steht. Die Verkettung der beiden replace() waere
ein stiller Fehler gewesen -- fuer uhd haette sie nach `-schmal` gesucht.
Gruen: kopf-messen (3), breiten (23), glocke (26), css-klassen (15),
struktur (32), buehne (38), start-ansicht (136), handy (59),
formulare (19), barrierefrei (18), lesbarkeit (14), tempo (8).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
953c3f5721 |
Zahlen bekommen eine Oberflaeche, das Dashboard bekommt Zahlen
Der Server konnte seit gestern rechnen -- und niemand konnte etwas
eintragen. Ein Rechenwerk ohne Oberflaeche ist kein Modul, sondern ein
Versprechen. Das ist jetzt eingeloest:
* leistung.html: Wochenkarten (Wert, Vergleich zur Vorwoche,
Verlaufslinie), Ziele als Fortschrittsbalken, die letzten 14 Tage
zum Eintragen -- auch die LEEREN, denn eine Luecke ist selbst die
Auskunft. Import aus dem TikTok-Export mit Vorschau VOR dem
Schreiben.
* Kachel "Zahlen" als erste der Gruppe "Rund um den Creator", eigenes
Zeichen (steigende Linie, kein zweites Balkendiagramm).
* Dashboard: jede Creator-Karte traegt jetzt Diamanten, LIVE-Tage und
Verweildauer. Bis heute zeigte sie ausschliesslich ARBEIT -- ein
Creator konnte null ueberfaellige Aufgaben haben und gleichzeitig
seit drei Wochen einbrechen, und die Karte sah tadellos aus.
* Die Fruehwarnung steht oben im Dashboard. Sechs benannte Signale im
Klartext mit Beleg, bewusst OHNE Punktzahl -- ein Wert wie
"Abwanderungsrisiko 73" klingt nach Wissenschaft und ist eine
Behauptung, der man nicht widersprechen kann.
* chat.html?mit=<person>: der Weg von der Warnung ins Gespraech. Gab
es vorher nicht; ein Hinweis ohne Weg dahin ist nur ein schlechtes
Gewissen.
GEFUNDEN VON DEN PRUEFUNGEN, nicht von der Theorie:
1. Die Verlaufslinie zeichnete fuer vier der sieben Groessen NICHTS.
Der Server liefert im Verlauf nur drei Reihen; fuer den Rest kam
undefined an. `=== null` faengt das nicht, Number(undefined) ist
NaN, und ein <polyline points="NaN,NaN"> ist im DOM vorhanden und
auf dem Bildschirm unsichtbar -- ohne Fehlermeldung. Die Pruefung
misst deshalb die PUNKTE, nicht die Anwesenheit des Elements.
2. Fuenf Schriftgroessen im CHAT lagen unter 11,5 px (.68/.7 rem) und
waren seit vorgestern drin. Die Grundlinie der Groessenpruefung
stand auf 43, gemessen wurden 48. Nicht die Grundlinie angehoben,
sondern die fuenf Stellen behoben: Eine Grundlinie, die mitwaechst,
ist keine mehr.
pruef-leistung-optik.mjs: 57 Pruefungen, zwei echte Browser, Gegenprobe
zu jeder Aussage -- auch dazu, dass die Vorschau vor dem Bestaetigen
wirklich noch nichts geschrieben hat und dass ein Creator seine Zahlen
zwar SIEHT, sie aber weder eintragen noch die Fruehwarnung ueber sich
lesen kann (auch nicht ueber eine von Hand gebaute Anfrage).
Co-Authored-By: Claude Opus 5 <[email protected]>
|