6156eb3a052aae1d119066c6648fa37a22b95448
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
6156eb3a05 |
Eine TikTok-Kampagnenseite lesen -- Etappe 1, nur lesen
Etappe 1 des Bauplans "Kampagnen-Kachel aus TikTok-Link": das Auslesen
einer Kampagnenseite, nachweisbar richtig, ohne dass irgendetwas davon
schon eine Kachel erzeugt. Keine Route, keine Spalte, keine Oberflaeche,
keine Netzanfrage im Betrieb. index.js, workspace.js und
workspace-bereiche.js sind unberuehrt; beide Haeuser verhalten sich
unveraendert.
DER WEG NACH DRAUSSEN WIRD GETEILT
helfer-tiktok.mjs nimmt istTikTok und holeMitFrist aus
workspace-video.js auf. Zwei Fassungen von istTikTok waeren die
abgeschriebene Liste aus CLAUDE.md -- und gerade dort faellt es am
teuersten aus: Es ist die eine Stelle, die entscheidet, welchen
fremden Rechner unser Server anfragt. Die Frist ist jetzt ein
Zusatz mit 8000 ms als Vorgabe; das Video bleibt damit beim alten
Verhalten, die Kampagnenseite braucht mehr. pruef-video: 74
Pruefungen, 0 Fehler.
GEMESSEN, NICHT ABGESCHRIEBEN -- und der Bauplan irrte zweimal
1. pageInfo.title IST der Kampagnenname ("Gipfelstuermer"). Nur das
Kopfbild und der Untertitel kommen aus der Vorlage (einem
goldenen Loewen aus einer Nahost-Kampagne vom August 2024). Das
Banner wird deshalb aus props.imageUrl[0].url genommen.
2. Eine BEENDETE Kampagne liefert
activityInfo.ac_schema_with_interaction_rules gar nicht mehr. Das
Geruest steht dann nur unter value.schema, mit Bausteinnamen auf
_rep_remove. Beide Quellen werden gelesen, die Endung wird
abgeschnitten -- sonst liesse sich keine abgelaufene Kampagne
nachtragen.
DAS SCHEMA IST DIE WAHRHEIT, DAS WOERTERBUCH IST NUR DAS WOERTERBUCH
134 Platzhalter im Seitengeruest, 135 Eintraege im Woerterbuch. Der
eine Ueberzaehlige lautet "1 schenkende Person = 100 Punkte" und
gehoert zu einer frueheren Fassung der Kampagne. Wer das Woerterbuch
durchliest, schreibt eine Regel in die Kachel, die nicht gilt, und
das Team richtet seinen Stream danach aus. Nachgeschlagen wird
deshalb nur, nie durchgelaufen.
VIER ECHTE SEITEN ALS PRUEFDATEN
Am 07.10.2026 unangemeldet geholt (userInfo.uid = "0", anchor_id
leer) -- es steckt keine Person darin. Brotli gepackt, 150 KB je
Seite statt 1 MB, beim Anlegen sofort zurueckgelesen und Byte fuer
Byte verglichen. Jede ist mit ihrer SHA-256 festgenagelt: eine
Pruefung, deren Eingabe sich aendern kann, beweist nichts. Woher sie
kommen und was an EINER von ihnen veraendert wurde, steht in
server/pruefdaten/LIESMICH.md.
.gitattributes: server/pruefdaten/** -text. Ohne das schriebe git
kampagne-kaputt.html beim Auschecken auf CRLF um (core.autocrlf=true),
369 Bytes wuerden 378, und die Pruefung meldete einen Schaden, den es
nicht gibt -- die Sorte Fehlalarm, nach der man eine Pruefung
abschaltet. git hat es beim Hinzufuegen selbst angesagt.
pruef-kampagne-lesen.mjs: 108 Pruefungen, 0 Fehler, ohne Server, ohne
Port, ohne Netz, ohne Datenbank. Drei Ausgaenge: gelesen /
Pflichtfeld fehlt / Aufbau unbekannt -- fehlt eine Pruefdatei, endet
sie mit "KONNTE NICHT NACHSEHEN" und Rueckgabewert 2, nicht mit einem
uebersprungenen Abschnitt.
SIEBEN SABOTAGEN, SIEBEN TREFFER
Woerterbuch durchlesen, Tag mit toISOString bilden, auf time_zone
ausweichen, Vorlagenbild als Banner, _rep_remove stehenlassen, eine
Netzanfrage einschmuggeln, ein Byte in einer Pruefdatei kippen --
jede wurde bemerkt, jede in genau dem Abschnitt, in dem sie erwartet
war. Eine Pruefung, die immer bestaetigt, bestaetigt nichts.
ZWEI FUNDE AM RANDE, BEIDE BEIM MESSEN AUFGEFALLEN
mess-fokus.mjs war seit dem 01.10.2026 KAPUTT: Die Einfuhr von
eigenerPort stand INNERHALB eines Blockkommentars (Zeile 27 oeffnet,
Zeile 34 schliesst). Die Datei brach beim Start mit ReferenceError
ab. Niemandem aufgefallen, weil sie von Hand gestartet wird.
Gefunden hat das pruef-struktur.mjs -- aber erst, nachdem seine
Quellenliste ABGELEITET wird statt aufgezaehlt. Dort standen drei
Namen von Hand, obwohl der Kommentar darueber seit immer
"ABGELEITET, NICHT AUFGEZAEHLT" verspricht. Gemessen: 98 Namen und
508 Aufrufe vorher, 148 und 1025 jetzt. In der Luecke dazwischen lag
genau dieser Fehler.
NICHT ANGEFASST, WEIL AUSSERHALB DIESER ETAPPE (vorbestehend, belegt
mit einem Lauf ohne meine Dateien): pruef-struktur meldet weiterhin
vier Befunde -- willkommen.html ohne apple-touch-icon, ohne Manifest
und ohne theme-color, sowie zwei Stellen, die ihren Kalendertag aus
UTC bilden (workspace-anleitung.js:194, pruef-anleitung.mjs:1124).
Ebenso pruef-portnummern: mess-anleitung-crew.mjs rechnet seine zweite
Portnummer als PORT + 1 statt sie abzuleiten.
pruef-eventkarte 94/0 und pruef-agentur 62/0 -- beide gleich wie vor
dem Umbau.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
f6225d7341 |
Ports: auch die Messwerkzeuge leiten ihre Nummer ab
GEMESSEN, BEVOR ICH ETWAS ANGEFASST HABE:
204 pruef-Dateien, abgeleitete Ports 5000-5409 (dicht belegt)
24 mess-Dateien, Nummern von Hand: 4471 bis 5493
davon IM Pruefbereich: 5387, 5397, 5397, 5399, 5399, 5401, 5403, 5405
untereinander doppelt: 5397, 5399, 5461, 5483, 5491
Aufgefallen ist es, weil mess-buehne und mess-reaktion beide auf 5483
lagen und ein haengengebliebener Lauf gestern einen ganzen Messlauf
gekostet hat.
Beim Umbau kam das Groessere heraus: EINUNDZWANZIG der 24 Messdateien
hatten nicht nur eine Nummer von Hand, sondern ueberhaupt keinen
Waechter -- schlicht `const PORT = 5397;`. Liegt dort schon ein
Server, startet der eigene still nicht, und gemessen wird ab da ein
fremder Stand. Genau der Fehler, gegen den helfer-port.mjs gebaut
wurde; die Messdateien standen die ganze Zeit ausserhalb.
WAS JETZT GILT
Zwei Sorten, zwei Bereiche, beide abgeleitet aus der Stelle im
Alphabet -- jede Sorte unter ihresgleichen, sonst verschoebe eine
neue Pruefung die Nummern aller Messungen. Pruefungen ab 5000,
Messungen ab MESS_BASIS = 5900.
5900 und nicht 5500: dazwischen bleibt Platz fuer 245 weitere
Pruefdateien (bei 5500 waeren es 45). Nach oben 5948 + AUSWEICHEN
4000 = 9948, also unter 10080, der naechsten gesperrten Nummer.
Nachgerechnet, nicht geschaetzt -- eine geschaetzte 4500 hatte bei
BASIS schon einmal danebengelegen.
Eine Wache dazu: Waechst der Pruefbereich bis an MESS_BASIS heran,
bricht die Ableitung ab und sagt, was zu tun ist. Eine stille
Ueberschneidung waere genau der Fehler, den das hier beseitigt.
Die zweite Nummer kommt ueber nr=1, nie ueber `PORT + 1`:
portNummer ueberspringt gesperrte Nummern, deshalb kann die naechste
Zahl die Nummer der naechsten DATEI sein, sobald einmal eine Sperre
dazwischenliegt. Heute liegt dort keine -- das ist Glueck, kein
Entwurf.
NEBENBEI GEFUNDEN UND MIT REPARIERT
Sechs bild-*.mjs riefen den Waechter und warfen seine Antwort weg:
await portMussFreiSein(4315, "das Bildwerkzeug");
process.env.PORT = "4315";
const BASIS = "http://127.0.0.1:4315";
Er lief, meldete nichts und wirkte nicht. Gibt das System den Port
dauerhaft nicht her, weicht er auf Port + 4000 aus und GIBT DIE NEUE
NUMMER ZURUECK -- diese Werkzeuge hoerten danach trotzdem auf der
alten und stuerzten mit `listen EACCES` ab, also mit genau dem
Fehler, gegen den er gebaut wurde. Dazu stand die Zahl dreimal je
Datei. Jetzt einmal, und die Antwort wird benutzt.
tiktok-videos.mjs hatte den Waechter ABGESCHRIEBEN -- eine kurze
eigene Fassung ohne den dritten Ausgang: Bei EACCES meldete sie
"belegt" und brach ab, statt auszuweichen. Auf diesem Rechner ist
genau das am 23.09. eingetreten (Port 5040, Windows-Dienst).
mess-fokus und mess-notizblock hatten dieselbe Abschrift. Eine
abgeschriebene Sicherung ist dieselbe Falle wie eine abgeschriebene
Liste.
GEPRUEFT
pruef-portnummern 15 -> 41 Pruefungen, 0 Fehler
pruef-ports 8 -> 10 Pruefungen, 456 statt 408 Ports geprobt
node --check auf allen 33 geaenderten Dateien
Gegenproben, die wirklich rot werden:
- eine Messdatei auf eine feste Nummer zurueckgesetzt -> 2 FEHL,
danach wieder 41/0
- die Wache: in einem Wegwerf-Ordner mit 452 pruef-Dateien bricht
eigenerPort ab statt still zu ueberlappen; eine Datei knapp
darunter bekommt weiter ihre Nummer (5846)
- die Erkennungen fuer feste Nummern, PORT + 1 und weggeworfene
Waechterantworten je gegen einen gebauten Rueckschritt
Am echten Verhalten gemessen:
- mess-chat-liste und mess-alle-einzelsicht (beide vorher 5397)
GLEICHZEITIG gestartet: 5906 und 5900, beide exit=0. Vorher war
das unmoeglich.
- die 48 neuen Nummern 5900-5947 auf diesem Rechner durchprobiert:
keine belegt, keine vom System gesperrt
- bild-chat.mjs durchgelaufen, drei Bilder, exit=0
Kein Eingriff am laufenden Dienst: helfer-port.mjs wird von index.js
und workspace.js nicht geladen (nachgesehen), nur von Pruef- und
Messwerkzeugen. Beide Haeuser unberuehrt -- es wird keine Zeile
angefasst, die eine Seite ausliefert.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
69ba533cee |
Wer mit der Tastatur bedient, sieht wieder, wo er steht
pruef-barrierefrei-workspace, wissen.html, Scout und Creator: Beim
Durchtabben veraendert sich an den Wissenskacheln NICHTS. Kein Rahmen,
kein Ring, keine Kante. Wer nicht mit der Maus arbeitet, tippt blind.
=== EIN SPEZIFITAETS-UNFALL, UND ER BETRIFFT NICHT NUR DIESE SEITE ===
Die Regel war da und richtig geschrieben:
wissen.css .kachel:focus-visible { box-shadow: 0 0 0 3px ... }
Sie kam nur nicht an. Gemessen mit einem neuen Werkzeug
(server/mess-fokus.mjs, echte Tastendruecke, kein focus()):
:focus true :focus-visible true
boxShadow gleich rgba(0,0,0,0.95) 7px 7px 14px -10px inset
outline gleich none
`:focus-visible` griff also, und trotzdem blieb alles, wie es war.
Der Grund steht in module.css, in einer Liste von 45 Klassennamen:
:is(.eintrag-karte, ..., .kachel, ..., .gruppe[data-gruppe], ...)
`:is()` uebernimmt die Spezifitaet seines STAERKSTEN Arguments.
`.gruppe[data-gruppe]` ist eine Klasse PLUS ein Attribut. Damit ist die
ganze Liste (0,2,0) statt (0,1,0) -- genau so stark wie
`.kachel:focus-visible`. Bei Gleichstand gewinnt, was spaeter geladen
wird, und module.css wird zuletzt geladen. Ein einziges Attribut in
einer Aufzaehlung, sechs Zeilen weiter rechts, hat den Fokusring von
jedem Bauteil im Haus verschluckt, dessen Fokusregel aus einer Klasse
besteht.
=== GELOEST WIRD DAS NICHT, INDEM MAN DIE LISTE SCHWAECHER MACHT ===
Das war schon einmal so (`:where()`, Spezifitaet null) und ergab einen
Zwitter aus neuer Form und alter Kante -- der Kommentar in module.css
beschreibt es. Wer die Zahl senkt, verschiebt das Problem auf die
naechste Regel.
Geloest wird es, indem die ANTWORT dort steht: ein Fokusring fuer die
ganze Modulliste, in derselben Datei wie die Form, mit
`:focus-visible` also eine Klasse staerker als die Grundregel. Er gilt
damit fuer jedes Modul im Haus -- auch fuer die, die es noch nicht
gibt, und auch dort, wo nie jemand an eine Fokusregel gedacht hat.
`outline-offset` ist NEGATIV, und das ist kein Geschmack: `clip-path`
(die Fase an der Ecke) schneidet alles ab, was ausserhalb der Form
liegt. Ein Ring mit positivem Abstand waere unsichtbar gewesen -- der
alte war es ja auch. Nach innen gezeichnet bleibt er stehen. Gemessen,
nicht geschlossen.
=== WAS NICHT MITREPARIERT WURDE, UND WARUM ES DASTEHT ===
Derselbe Gleichstand trifft auch Hover-Regeln in frueher geladenen
Dateien: `.ablage:hover` (dateien.css), `.call:hover` (calls.css),
`.kk:hover` (scouting.css), `.fortschritt:hover` (uebersicht.css)
setzen alle `border-color`, und die Grundregel setzt `border: 0`.
Diese vier tun vermutlich nichts.
Angefasst habe ich sie nicht -- es gibt kein Messgeraet dafuer. Fokus
laesst sich pruefen (die Pruefung tabbt und vergleicht), Hover nicht.
Und die naheliegende Loesung wuerde die Form von 45 Bauteilen auf 38
Seiten neu entscheiden; das ohne Messgeraet zu tun waere Raten mit viel
Einsatz. Der Befund steht deshalb als Absatz in module.css, damit der
Naechste nicht wieder bei null anfaengt.
=== UND EINE BEHAUPTUNG VON MIR WIRD ZURUECKGENOMMEN ===
Im Commit
|