59b2a6d0e5caabc6ad04bd663610f5ea2005a791
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
fe1dad48e5 |
screen1: Wohin ein geholtes Video gelegt wird, darf man waehlen
Filipe: "ich will das wenn man da video holt das man auch aussuchen
kann in welcher account es unten angezeigt werden soll."
Bis heute entschied allein der Link: kanalVonHandle liest den Account
aus der TikTok-Adresse, und dort landete das Video. Das ist gut
geraten, aber es IST geraten -- ein Ausschnitt vom Hauptkanal gehoert
oft unter "Clips", und seit dem 21.09. hat jeder Account seine eigene
Spalte, in der das sichtbar wird.
DIE SCHRANKE BLEIBT UNANGETASTET. Der ABSENDER muss weiterhin einer
der drei eigenen Kanaele sein; gewaehlt wird nur die SPALTE. Sonst
waere aus einer Ablagehilfe ein Loch fuer fremde Inhalte geworden --
die Pruefung haelt genau das fest ("ein fremder Absender kommt auch
MIT Wahl nicht herein", 403).
Ohne Angabe bleibt alles wie bisher. Das ist der haeufigste Fall und
soll keinen zusaetzlichen Handgriff kosten; die Vorgabe heisst "Aus
dem Link erkennen".
ZWEI FUNDE BEIM PRUEFEN
- Die Antwort meldete `auskunft.kanal` -- also das ERKANNTE, nicht
das, wohin der Eintrag wirklich ging. Seit beides auseinanderfallen
kann, haette die Seite "DogFather" gemeldet, waehrend das Video
unter "Clips" steht.
- `coverAbrufe === 3` in pruef-video war eine Rechnung von dem Tag,
an dem die Pruefung drei Videos anlegte. Der neue Abschnitt legte
vier weitere an, und die Zeile wurde rot, ohne dass etwas kaputt
war. Gemeint war nie eine Summe, sondern eine DIFFERENZ: holt
derselbe Link ein zweites Mal? Das bleibt richtig, egal wie viele
Videos davor liefen.
Die Wahl steht UNTER der Zeile, nicht darin: Am 21.09. hat genau so
ein drittes Element in derselben Reihe das Chat-Eingabefeld auf einen
Buchstaben zusammengedrueckt. Am Bildschirm gemessen (1044 px).
Gemessen: pruef-video 71/0 (vier neue Aussagen samt Gegenprobe, dass
ohne Wahl weiterhin der Link entscheidet), pruef-highlights 31/0
(fuenf neue am echten Bildschirm), pruef-meldungen 8/0, pruef-teilen
27/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6e46a08543 |
Portnummern werden abgeleitet, nicht mehr vergeben
Gemessen: 165 Pruefdateien, 129 verschiedene Nummern -- NEUNZEHN
doppelt, vier davon dreifach. Niemand hatte das gewollt; jede neue
Pruefung wurde von einer vorhandenen abgeschrieben, und die Nummer kam
mit. Meine eigene Notiz sagte "sieben" -- auch eine Bestandsliste
altert.
Der Waechter faengt den Schaden ab, aber er kann nur melden, was schon
passiert ist: Zwei Pruefungen mit derselben Nummer koennen nie
gleichzeitig laufen, und ein liegengebliebener Prozess der einen laesst
die andere abbrechen mit einer Meldung, die wie ein Befund aussieht.
Genau das ist mir am 20.09. zweimal passiert.
Jetzt leitet jede Datei ihre Nummer aus ihrer STELLE IM ALPHABET ab
(eigenerPort in helfer-port.mjs), zwei je Datei. Nicht ueber eine
Pruefsumme: Bei 165 Namen in 4900 Nummern waeren nach dem
Geburtstagsproblem rund DREI Zusammenstoesse zu erwarten -- ein Hash
tauscht eine sichtbare Doppelung gegen eine unsichtbare. Die Stelle im
Alphabet ist eindeutig von der Bauart her.
--- ZWEI FEHLER AUF DEM WEG, BEIDE LEHRREICH -------------------------
1. DER ERSTE VERSUCH WAR GRUEN UND KAPUTT. Ersetzt wurde mit einem
Muster: "([^"]*4231[^"]*)". Das hielt
{ host: "127.0.0.1", port: 4231, path: "/404.html" }
fuer eine Zeichenkette -- ein Muster kann eine oeffnende nicht von
einer schliessenden Anfuehrung unterscheiden. Heraus kam
{ host: "127.0.0.1`, port: ${PORT}, path: `/404.html" }
also GUELTIGER Code ohne port-Feld. `node --check` sagte gruen fuer
alle 164 Dateien. Aufgefallen ist es erst, weil ich vier Vertreter
gegen eine vorher gemessene Grundlinie laufen liess: pruef-schranke
39/0 vorher, 38/1 nachher.
Alles zurueckgenommen und mit einem Zerleger neu gemacht, der weiss,
ob eine Stelle Code, Zeichenkette, Vorlage, Kommentar oder
regulaerer Ausdruck ist. In pruef-ics stand die Nummer in einem
regulaeren Ausdruck -- der wird jetzt gebaut statt hingeschrieben.
2. EIN MODUL, DAS BEIM IMPORTIEREN ARBEITET, IST EINE FALLE. Der
zweite Durchgang importierte den ersten, um seine Mechanik zu
benutzen -- und fuehrte dessen Hauptlauf gleich mit aus. Die
zweiten Nummern wurden dadurch als erste behandelt, zwei Aufrufe
bekamen dieselbe Nummer, und in pruef-content stand `const PORT`
zweimal.
--- WAS DAS DAUERHAFT HAELT -----------------------------------------
pruef-portnummern.mjs (neu, 8 Pruefungen) fragt nicht "welche Nummern
sind doppelt", sondern "wer traegt ueberhaupt noch eine von Hand ein"
und "wer startet einen Server, ohne seine Nummer abzuleiten". Die
zweite Frage hat sofort etwas gefunden, das in KEINER Doppelungsliste
stand: pruef-push-weg belegte 4341 und 4342, rief den Waechter aber
gar nicht auf -- dieselbe Nummer wie pruef-agentur. Eine Liste zeigt
nur, was auf ihr steht.
Mit Gegenprobe: Eine unbekannte Datei bekommt keine geratene Nummer,
sondern einen Abbruch, und eine dritte Nummer je Datei gibt es nicht.
--- NACHGEMESSEN ----------------------------------------------------
Sechzehn Pruefungen gegen ihre vorher gemessene Grundlinie, je eine
Vertreterin jeder umgestellten Bauweise (eine Nummer, zwei Nummern,
Nummer in einer Zeichenkette, in einer Vorlage, in einem regulaeren
Ausdruck, dynamische Einfuhr, Nachtlauf mit zwei Laeufen):
crew-adresse 132/0 · schranke 39/0 · content 45/0 · entwicklung 46/0
anruf 127/0 · ics 37/0 · push-weg 20/0 · arten 28/0 · video 67/0
kanalzeile 14/0 · agentur 62/0 · spicy 83/0 · creator-anlegen 50/0
push-ziel 10/0 · portnummern 8/0
Alle exakt wie vorher. Zwei waren schon vorher rot und sind es
unveraendert geblieben (crew-wand-bild 41/4, teilen 14/3) -- per
`git stash` belegt, nicht angenommen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
59c84bd248 |
Videos: Stufe 7 -- aus einem Wunsch wird ein Video, mit Namen
"Ein Video aus einem Wunsch zeigt den Namen." Wer sich etwas gewuenscht hat, soll sehen, dass daraus etwas geworden ist -- das ist der Sinn eines Wunschbretts. Ohne die Verbindung ist die Galerie eine Sammlung, und der Wunsch von letzter Woche bleibt unbeantwortet im Raum stehen. DER KNOPF STEHT AM WUNSCH, nicht im Formular oben. Das ist dieselbe Entscheidung wie bei den Kettenknoepfen daneben, aus demselben Grund (dort woertlich): "Wer ein Formular ausfuellt, denkt nicht an den Wunsch von letzter Woche." Hier denkt er an nichts anderes. DAS LECK, das es nicht geben darf: Der Titel der Quelle wird auf der Kachel ANGEZEIGT. Eine Kette in die Content-Planung waere deshalb kein Schoenheitsfehler, sondern ein Weg, interne Arbeit in die Community zu tragen. Die Quelle muss ein Community-Brett sein -- dieselbe Regel wie beim "Daraus"-Knopf. ZWEI WEGE, EIN ZIEL: "Daraus ein Highlight machen" gibt es laenger. Wer ihn geht und DANACH das Video einfuegt, bekaeme sonst ein zweites Highlight aus demselben Wunsch -- zwei Wege zum selben Ziel, die nichts voneinander wissen. Das Video haengt sich jetzt an den vorhandenen Eintrag. Der Titel bleibt dabei der des Wunsches: Er stammt von einem Menschen, der von TikTok ist eine Bildunterschrift mit Schlagwoertern. Geprueft: pruef-video 51 -> 67. Gegenprobe (Brett-Pruefung und Anhaengen ausgebaut) macht 6 rot, darunter "ein Eintrag aus der Content-Planung kommt NICHT als Quelle durch (201)". UND DAS BILDSCHIRMFOTO HAT ETWAS GEFUNDEN, das keine Zahl gemeldet haette: Das Eingabefeld erschien am ENDE der Karte, unter der Fusszeile -- getrennt von dem Knopf, den man gerade gedrueckt hatte. Alle Pruefungen waren gruen, das Feld war da und reagierte. Jetzt haengt es an der Knopfreihe. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
fb55377e19 |
Videos: Stufe 5 -- fuehrt der Knopf noch irgendwohin?
Ein Video kann bei TikTok geloescht oder auf privat gestellt werden.
Bei uns blieb der Eintrag stehen -- mit Cover, Text und einem Knopf
auf eine Fehlerseite. Das faellt beim Bauen nicht auf und beim Testen
nicht; es faellt dem auf, der klickt, und das ist die Community.
DREI ANTWORTEN, NICHT ZWEI. Die naheliegende Fassung fragt TikTok und
setzt bei einem Fehlschlag "weg". Die waere an einem einzigen
schlechten Nachmittag von TikTok in der Lage, die halbe Galerie als
geloescht zu markieren -- und wer das hinterher sucht, sucht lange,
denn im Protokoll stuende sauber, dass gefragt wurde. Also:
Daten kommen an -> da. Zaehler zurueck, eine frueher gesetzte
Markierung faellt weg (privat gestellte
Videos kommen wieder).
"gibt es nicht" (404) -> ein Fehlversuch. Erst der DRITTE an drei
verschiedenen Tagen markiert.
niemand antwortet -> weiss nicht. Aendert gar nichts, nicht
einmal den Zeitstempel: Wer ihn setzte,
verschoebe die naechste Nachfrage um sieben
Tage, obwohl nichts gemessen wurde.
Drei Geschwindigkeiten beim Nachsehen: unauffaellig woechentlich,
verdaechtig taeglich (sonst dauerte eine Loeschung drei Wochen bis zur
Anzeige), schon markiert wieder woechentlich -- taeglich nachzufragen
waere Hammern fuer eine Auskunft, die wir schon haben. Gefunden hat
das eine rote Pruefung, nicht das Nachdenken davor.
Der Knopf verschwindet nicht, er sagt "Bei TikTok nicht mehr da".
Bewusst kein Rot: Es ist kein Fehler, sondern eine Auskunft -- Titel,
Text und Cover stimmen weiter, die liegen bei uns.
Geprueft: pruef-video 37 -> 51. Gegenprobe (Stoerung als "weg" werten
plus Markieren ab dem ersten Versuch) macht 8 rot, darunter woertlich
"eine Stoerung erhoeht den Zaehler NICHT (0 -> 1)".
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
f05783ebc8 |
Link einfuegen, Video steht in der App -- Stufe A des Video-Plans
Filipe: "damit meine videos auch da auf der app rein kommen ... sobald
ich ein video poste erscheint es sofort in der app fuer die ganze
community ... dass man das Coverbild und den Text sieht ... fuer meinen
Account, dann DogFather Clips und HasiDog."
Der Weg, der HEUTE funktioniert -- ohne Freigabe, ohne Geheimnis, ohne
Wartezeit: Adresse einfuegen, alles andere geht von allein.
Link -> oEmbed (Titel, Cover-Adresse, Account)
-> Cover HERUNTERLADEN und bei uns ablegen
-> Eintrag mit Bild, Text und Knopf zum Video
DAS COVER WIRD KOPIERT, NICHT VERLINKT -- der wichtigste Satz.
TikToks Bildadresse ist signiert und laeuft ab. Heute an einem echten
Video nachgemessen: x-expires = 1789812000, also in 48 Stunden. Wer sie
nur speichert, hat uebermorgen schwarze Kacheln. Beim Bauen merkt man
das nicht und beim Testen auch nicht -- es faellt erst am uebernaechsten
Tag auf, und dann sieht die ganze App kaputt aus.
Deshalb wandert das Bild in dieselbe Ablage wie jeder Anhang und geht
durch dieselbe Bytepruefung. Ein heruntergeladenes Cover ist eine
FREMDE Datei; dass der Typ hier von einem fremden Server behauptet wird
statt vom eigenen Browser, macht ihn nicht glaubwuerdiger.
NUR SEINE EIGENEN KANAELE. Der Account aus der Antwort wird gegen
KANAELE geprueft (kanalVonHandle). Genommen wird author_url (.../@name),
nicht author_name -- der Anzeigename aendert sich, wenn jemand ihn
umstellt. Ein fremdes Video in Filipes Highlights waere nicht bloss
falsch einsortiert, es waere fremder Inhalt unter seinem Namen: 403.
DIE PRUEFUNG SCHALTET TIKTOK AB (server/pruef-video.mjs, 37 Pruefungen)
Ein nachgebauter Dienst auf 127.0.0.1 antwortet wie TikTok, mitsamt
Ablaufstempel. Im letzten Abschnitt wird er ABGESCHALTET. Danach muss
die alte Cover-Adresse ins Leere laufen und unsere weiterhin ein Bild
liefern -- beides wird gemessen, nebeneinander. Waere das Bild nur
verlinkt, waeren beide tot, genau wie uebermorgen im Betrieb.
Die Adresse des Dienstes kommt aus TIKTOK_OEMBED_BASIS. Steht sie nicht
da, gilt TikTok -- kein Verhalten, das sich still aendert. Eine
Pruefung, die das echte TikTok braucht, misst fremde Verfuegbarkeit
statt unseren Code und wird irgendwann rot, ohne dass etwas kaputt ist.
VIER GEGENPROBEN, weil 37 von 37 im ersten Lauf kein Beweis ist:
a) Cover nicht mehr kopieren -> 9 Pruefungen rot
b) author_name statt author_url -> 22 rot
c) Bytepruefung entfernen -> 2 rot (genau Abschnitt 5)
d) Dublettenpruefung entfernen -> 4 rot (genau Abschnitt 4)
Jede schlaegt dort an, wo sie soll. Und eine fuenfte Gegenprobe ist ins
Leere gelaufen: Der Patch lief ueber python3, das es hier nicht gibt --
die Datei blieb unveraendert und der Lauf war gruen. Haette ich die
Ausgabe nicht gelesen, haette ich behauptet, die Pruefung koenne rot
werden, ohne sie je rot gesehen zu haben. Der dritte Ausgang, an mir
selbst.
DAZU:
- eintraege.quelle_url / quelle_kanal / quelle_geholt_am (Umstellung)
- KANAELE bekommt handle, dazu kanalVonHandle()
- videoRouter steht VOR bereicheRouter, sonst schluckt /:bereich ihn
- Eingabefeld und Kanal-Knopf in bereich.html/.js, Farben wie bei den
Aufgaben-Kanaelen
- Stempel 202609171249
Nicht darin: die Kanal-Filterzeile in der Galerie, die Handy-Verknuepfung
(Teilen -> Workspace) und der Zustand "nicht mehr da" fuer geloeschte
Videos. Stufe B (Display API) braucht Filipes Entwickler-Freigabe.
Co-Authored-By: Claude Opus 5 <[email protected]>
|