Konten-Fabrik – der ganze Prozess, festgeschrieben

Was das hier ist: die EINE Datei, die den kompletten Weg beschreibt – vom gekauften Google-Konto bis zum Kanal, der automatisch Videos hochlädt. Welche Daten wo liegen, welcher Schritt welche braucht, was ein Skript macht und was Leon von Hand machen muss, und was heute noch fehlt. Stand: 20.07.2026. Historie/Changelog steht NICHT hier, sondern in docs/bereiche/scaling.md. Jonas' Methode dahinter: docs/business/jonas.md §2c.

---

1. Das Gesamtbild – zwei Stränge, aber eine feste Reihenfolge

Der häufigste Denkfehler ist, die Fabrik als eine Kette zu sehen. Es sind zwei Stränge – der Content-Strang darf jederzeit vorbereitet werden, aufs Konto gelegt wird er aber erst nach dem Warmup:

Warum trotzdem zwei Stränge: Ein Konto kann warm und fertig sein, während seine Nische noch nicht steht (CH8/CH9 heute) – und eine Pipeline kann fertig sein, ohne dass ein Konto dafür existiert (History/WhatIf laufen auf Jeans Haupt-Account). Wer beides vermischt, wartet auf das Falsche. Getrennt entwickeln heißt aber nicht gleichzeitig zuweisen: DNA, Name und Branding landen erst auf einem Konto, das das Warmup überstanden hat (Grundregel unten).

⭐ Die Grundregel dahinter (Leon, 21.07.2026)

Ein Kanal besteht zuerst nur aus E-Mail + Nummer + Proxy. Die DNA kommt erst, wenn das Warmup beendet ist.

Die gekauften Teile sind zunächst lose Informationen ohne Kanal. Sie liegen als lose Teile im Regal (HQ → Scaling → Schritt 1 · Zutaten) und werden dort bewusst zu einem Kanal verbunden – ankreuzen, verbinden, fertig ist der neue Platz im channel_registry. Nichts entsteht von selbst. Bis zum Ende des Warmups bleibt dieser Kanal namenlos – keine Nische, kein Titel, kein Branding. Erst danach wird die DNA daraufgelegt und daraus Name, Beschreibung, Avatar und Banner erzeugt (Schritt 2 · Kanal bauen).

Warum: Marke auf ein Konto zu bauen, das die Aufwärmphase noch nicht überstanden hat, ist verlorene Arbeit – fällt das Konto, ist auch der Kanalname weg. Das HQ setzt die Reihenfolge deshalb hart durch (Reife-Gate: Konto · Login · Trust-Anker · Backup-Codes · Warmup), nicht nur als Konvention. Wann welcher Schritt passiert ist, steht als Verlauf unten in der jeweiligen Register-Zeile (channel_history.json + Warmup-Log) – dieselbe Spur schreibt später die Automatik (HZ-244).

---

2. Wo liegt was – die Datentöpfe

Es gibt elf Orte. Mehr nicht. Wenn etwas an einem zwölften Ort steht, ist es ein Fehler. (Stand 27.07. nach HZ-443 – vorher stand hier „acht", während die Tabelle neun Zeilen hatte und drei echte Töpfe gar nicht auftauchten. Eine Karte, die nicht stimmt, ist schlimmer als keine.)

Regel dazu (Memory feedback-modular-source-of-truth): Die Zuordnung Account → Kanal → Container → YT-Ziel muss explizit in den Registern stehen. Implizite Vererbung über Container-Env hätte schon einmal vier Kanäle auf CH1 hochgeladen.

Zwei Regeln, die am 27.07. dazukamen (HZ-443) – beide aus echtem Schaden gelernt:

1. Der Stand eines Kontos wird ERZEUGT, nicht getippt. konto_stand() (dashboard/app.py)

baut ihn aus den harten factory.*-Feldern. Der frühere Freitext status steht nur noch als Notiz daneben, weil er driftete: bei CH3 stand „live · Empty Earth · 2 Videos public", während Empty Earth zu CH2 gehört und wisdom (CH3) null public hat. Wer den Zustand von Hand hinschreibt, schreibt irgendwann etwas Falsches hin.

1. Ein Fakt, ein Feld. Der Trust-Anker lag in factory.anchor, factory.recovery und

einem Top-Level-anchor – drei Wahrheiten, die sich widersprachen (bei CH11–CH14 war er im Log belegt und stand trotzdem auf false). Es gibt jetzt nur factory.anchor; jede Migration trägt ihre Quelle in anchor_note.

Und: „eingeloggt" ist kein Zustand, sondern eine Beobachtung. factory_status.sitzung sagt, was der letzte Lauf gesehen hat. Ist das älter als 12 h, dimmt das HQ die Angabe – CH2 stand am 27.07. auf „eingeloggt" (vom Vorabend) und war real ausgeloggt; ein Backup-Code-Lauf lief deshalb ins Leere.

Backup-Codes liegen in dashboard/config/hq.secrets.json (chmod 600), geschrieben ausschließlich über secrets_store.update(). Stand 27.07. abends: 11 von 14 Konten haben je 10 Codes (CH1–CH4, CH6–CH9, CH11–CH13) – an diesem Abend kamen CH2/CH3 (HZ-452) sowie CH11/CH12/CH13 dazu. Ohne Codes bleiben nur drei, alle aus konto-fremden Gründen: CH5 (SIM nicht betriebsbereit, HZ-470 – im Re-Login-Automaten bis 31.08. ausgesetzt) · CH10 (Captcha seit 27.07., HZ-473) · CH14 (verbrannt, HZ-432). Sobald eines davon anmeldbar ist, dauert das Ziehen ~2 Minuten. Das vault-Feld im Register nennt den Ort der Zugangsdaten (PW/2FA) – Bitwarden bei CH1/CH2, die geschützte Datei bei CH3–CH9 –, nicht den der Codes; diese Zeile las sich früher so, als lägen die Codes selbst dort. Unverändert gilt: das Register speichert nur den Ort, nie ein Geheimnis, und Codes gehen nie ins Terminal-Log (run_channel.py gibt bewusst nur die Anzahl aus).

HQ-Aufteilung + Auto-Generierung (Leon-Auftrag 21.07., HZ-834)

#/area/scaling „Accounts & Scaling" bleibt EIN Bereich (YouTube-Infrastruktur, kein Geschäftsbereich), hat aber seit 21.07. zwei Tabs statt aller Karten untereinander – bewusst Tabs und kein zweiter Nav-Punkt: so einfach wie möglich, so lange wie möglich.

• Tab „Übersicht" (Default) = der Ruhezustand, hier wird nichts ausgelöst: Konten-Fabrik-Matrix

(Bau-Fortschritt je Account), Account-Register (Tabelle) und „Kanal ⇄ Account" (welcher Kanal läuft auf welchem Konto).

• Tab „Bauen" = die drei Schritte am Stück, in der Reihenfolge, in der man sie geht:

1 Zutaten-Regal (lose Teile: synchron aus D.inventar, überlebt Shop-Ausfälle; „＋ Teil hinzufügen" + Paste-Intake + Umtypen + „automatisch zuordnen" + „verbinden"-Ziel neuer Kanal ODER bestehender CHn; Einkauf & Preise in einem <details>) → 2 Zuweisen → alles erzeugen (der Auto-Orchestrator) → 3 Auswählen: Name & Branding (Showroom, wo Leon aus dem Erzeugten pickt).

Belegte Felder werden nie angeboten (Leon-Fund 21.07.): Das Zuweisen-Dropdown eines Regal-Teils listet ausschließlich Konten, denen genau dieses Feld fehlt – ein Konto mit Mail bekommt keine zweite Mail zur Auswahl. Da CH1–CH9 alle Felder gefüllt haben, steht dort in der Regel „kein Konto braucht das"; der Weg ist dann „ankreuzen → verbinden → neuer Kanal". Der frühere Fallback „wenn keiner frei ist, biete alle an" war der Fehler (das Backend lehnte danach mit 400 ab).

„automatisch zuordnen" (POST /hq/api/factory/auto_assign) räumt das Regal in einem Zug leer: (1) jedes Teil geht an das erste Konto, dem genau dieses Feld fehlt – belegte Felder werden nie überschrieben; (2) was dann noch liegt und eine Mail ist, wird der Anfang eines neuen Kanals (CH10, CH11 …) und bekommt je ein übriges Teil der anderen Sorten dazu. Bewusst nur an der Mail, sonst legt ein Fehlklick eine Geisterflotte an. Mit dry:1 liefert der Endpoint nur den Plan – das HQ zeigt ihn zur Bestätigung, bevor irgendetwas ins Register wandert. Geparkte Passwörter/2FA ziehen dabei über _pending_umziehen() in hq.secrets.json um (dieselbe Funktion nutzt „verbinden").

⚠️ Die Schritt-Kette lag zwischenzeitlich über zwei Tabs verteilt und Schritt 2/3 waren vertauscht (der Auto-Lauf erzeugt genau das, was im Showroom gepickt wird – man wäre rückwärts gesprungen). Leon 21.07.: „unlogisch". Merke: eine nummerierte Kette gehört komplett in EINEN Tab und in die Reihenfolge, in der man sie wirklich abarbeitet.

Zwei Bau-Regeln aus der KB gelten hier: keine Emojis im UI (Leon 21.07.) und Knopf-Preise nie hardcoden – der Branding-Preis kommt aus hq.config.json → button_costs.branding (Frontend BC(), Backend _brand_kosten()).

Auto-Orchestrator „Zuweisen → alles erzeugen" (POST /hq/api/factory/auto, Status GET /hq/api/factory/auto_status): EIN Klick weist einem Account eine DNA zu und erzeugt alles – ① Kanal-Entwürfe (_entwurf_make, Text lokal, $0) · ② Branding Avatar+Banner (_brand_job, ~7 Ct) · ③ Pipeline-Fork P1–P5+Publisher deaktiviert ($0). Reife-Gate bleibt hart (409 + fehlt-Liste, bewusstes „trotzdem" möglich). Der Fork läuft übers Wunsch-Datei-Muster (Container darf kein docker/n8n-Host): HQ schreibt channel_clone/fork_requests.json → Host-Cron scripts/fork_apply.py (1×/Min; Allowlist = existierende dna/<slug>.json + recipes/<slug>.json, Doppel-Fork-Sperre gegen registry.json) ruft fork_channel.py → fork_result.json → das HQ trägt den Erfolg EXPLIZIT als channels[]-Eintrag (ch, clone_key, auto_fork: true) ein. Die beiden fork_*-Dateien sind Transport, keine Datentöpfe – Wahrheit steht danach in den Registern. Alles landet im Register + Verlauf: DNA-Zuweisung, Entwürfe, Branding-Generierung, Picks (Name → kanal, Branding → branding) und der Fork schreiben channel_history.json und die Registerfelder – nichts existiert mehr nur als Datei im Ordner. Leons Handgriffe bleiben genau zwei: Name picken, Branding-Variante picken.

⚠️ Rangfolge seit 20.07.2026: hq.secrets.json schlägt die Kauf-Datei. run_channel.py las Passwort und Seed bis dahin aus filesForClaude/channel_accounts_CH3-CH9.txt. Sobald ein Konto rotiert wird (Schritt 5b), steht dort der Verkäufer-Stand – der nächste Login hätte sich mit dem alten Passwort anmelden wollen. Deshalb gewinnen jetzt die Secrets; Platzhalter („⟨…⟩", wie bei CH1/CH2) werden dabei ignoriert, damit sie nie ein echtes Passwort überschreiben. Geschrieben wird ausschließlich über scaling/secrets_store.py (atomar, chmod 600, alter Wert bleibt als pw_prev / twofa_prev stehen).

---

3. Der Prozess, Schritt für Schritt

Jeder Schritt nennt: Input (was er braucht) · Werkzeug · Output/Beweis · Stand.

Verhältnis zu den zwei HQ-Panels: Die Schritte 1–3 hier (Konto, Nummer, Profil+Proxy) sind zusammen Schritt 1 · Zutaten im HQ – reinpasten, fertig. Die Schritte 4–6 (Login, Anker, Warmup) sind die Reifung; sie haben kein eigenes Panel, ihr Fortschritt steht in der Register-Zeile und ihr Ablauf im Verlauf darunter. Schritt 2 · Kanal bauen im HQ entspricht Schritt 9 (Content) und wird erst nach Schritt 6 freigegeben – DNA erst nach Warmup.

Schritt 1 – Google-Konto

• Input: Geld (~44 ct aged Gmail über SMM-Panel) oder Zeit (selbst anlegen).
• Werkzeug: manuell. Jonas' Weg: pro Kanal zwei Konten – Haupt + Editor (siehe Schritt 7).
• Output: Mail + Passwort in hq.secrets.json bzw. der Account-Datei.
• Stand: 9/9 vorhanden. Zweitkonten für den Editor-Trick: fehlen (HZ-219).

Schritt 2 – Nummer + SMS-Verify

• Input: physische SIM (heute: 9 deutsche Prepaid, 3-3-3 auf o2/Vodafone/Telekom) oder US-Nummer.
• Werkzeug: manuell; Nummer landet als sim_number im Register.
• Output/Beweis: sim_number + sim_carrier + sim_keepalive (Prepaid verfällt sonst).
• Stand: 9/9 zugeordnet. ⚠️ „zugeordnet" heißt NICHT „im Google-Konto hinterlegt" – das

ist Schritt 5. US-Nummern später über Multilogin (Leon-Entscheid 20.07., HZ-220).

Schritt 3 – Antidetect-Profil + eigener Proxy

• Input: Proxy (1 IP = 1 Identität, niemals teilen – Memory feedback-proxy-nie-teilen).
• Werkzeug: AdsPower (läuft headless am Server, scaling/adspower_drive.py) oder

Multilogin (scaling/multilogin_drive.py, mimic 150.4).

• Output: adspower-Profil-ID + proxy_endpoint/proxy_geo/proxy_expires im Register.
• ⚠️ Fingerprint muss widerspruchsfrei sein: cmd_kernel() setzt UA und Kernel zusammen.

Chrome-148-UA auf Kernel 134 ohne Client Hints ist ein starkes Bot-Signal (Bug, gefixt 20.07.).

• Stand: 9/9 Profile, Proxys DE.

Schritt 4 – Login + 2FA ✅ läuft automatisch

• Input: Mail, Passwort, TOTP-Seed, Profil-ID, Proxy-Creds – alle aus den Töpfen (Schritt 2).
• Werkzeug: scaling/run_channel.py CH9 → startet Profil → account_login.py →

Captcha bei Bedarf über lokales Whisper (whisper_captcha.py, $0, kein bezahlter Solver) → TOTP selbst gerechnet (RFC 6238, kein pyotp).

• Output/Beweis: {"logged_in": true}, Endadresse myaccount.google.com, Screenshot je

Schritt in scaling/ch_shots/<CH>/; schreibt factory.login = true ins Register.

• Stand: CH9 und CH8 echt durchgelaufen (20.07.; bei CH9 kam nicht einmal ein Captcha).

CH8s Erfolg steht als factory.login im Register – vom Skript geschrieben, nicht behauptet. Rest der Flotte: Werkzeug steht, muss pro Account einmal laufen.

• Fallen, die es gekostet hat: Googles Mail-Feld ist type="text" (#identifierId), nicht

type=email · vor Sicherheitseinstellungen kommt erneut Passwort + TOTP · input[type=tel] matcht auch das 2FA-Feld → nur tippen, wenn die URL wirklich rescuephone ist.

Schritt 5 – Trust-Anker (Recovery + Authenticator + Backup-Codes)

• Warum: Jonas' Kernpunkt – mit Authenticator und Backup-Codes hat Google so viele

Beweise, dass es einen Login von fremder IP „nicht ablehnen kann". Das ist der Schutz gegen Verify-Sperren, nicht Bequemlichkeit.

• Input: eingeloggtes Profil (Schritt 4) + sim_number + Passwort + TOTP-Seed.
• Werkzeug: run_channel.py recovery <CH> (recovery_add.py). Dry-Run ist Default –

ohne --live wird nichts gespeichert.

• ⚠️ Korrektur 20.07. (vorher falsch angenommen): Für das Setzen der Recovery-Nummer kommt

keine SMS – Google speichert sie direkt und legt stattdessen eine Sicherheits-Wartezeit darüber. Der Parameter --sms-code bleibt für den Fall, dass Google doch fragt; ein Leon-Handgriff ist er nicht. (Die SMS-Hürde HZ-220 betrifft nur Nummern-Beschaffung und Neuanlage von Konten.)

• Backup-Codes: run_channel.py backupcodes <CH> --live erzeugt sie und legt sie in

hq.secrets.json ab (chmod 600). Nicht ins Register. Kein Handgriff mehr. ⚠️ --live allein ersetzt vorhandene Codes NICHT – es liest sie nur. Bei einem gekauften Konto sind vorhandene Codes aber möglicherweise die des Verkäufers: dann --live --neu, das erzwingt neue und macht die alten ungültig.

• Nachweis, dass der Anker wirklich hält: run_channel.py check <CH> – liest (ohne etwas zu

ändern) Recovery-Seite, Zwei-Schritt-Seite und Sicherheits-Seite und meldet: steht die Nummer, fordert Google eine Bestätigung nach, ist ein Authenticator aktiv. Nötig, weil ein normaler Login-Lauf nur already_logged_in sagt und damit nichts beweist.

• Stand: CH8 und CH9 vollständig verankert (20.07.: Nummer + Authenticator + je 10

Backup-Codes, per check gegengelesen). CH1–CH7 offen → im HQ steht an deren Nummer weiter ⚠ statt 🔒.

• ⏳ Offen und wichtig: Google fordert eine neu eingetragene Nummer laut Leon oft erst **1–2 Tage

später beim nächsten Login nach. Am Eintragungstag sagt check deshalb zwangsläufig „keine Nachforderung". Der Anker gilt erst als bewiesen, wenn ein zweiter Check Tage später sauber ist (Ticket HZ-824, Zyklus 2 Tage) – erst dann** die restlichen sieben Accounts nachziehen.

• Falle, die es gekostet hat: ctx.pages[0] griff einen beliebigen offenen Tab des Profils

ab (dort lief YouTube) → immer ctx.new_page() benutzen. Und Googles wahrer Elementname steht im aria-label („Save phone number"), nicht im sichtbaren Text.

Schritt 5a – RUHEN LASSEN nach dem ersten Login (Leon 28.07.2026)

• Regel: Nach dem ersten erfolgreichen Login wird das Konto ~3 Tage in Ruhe gelassen,

bevor Passwort und Authenticator rotiert werden. Nicht am selben Tag einloggen, umstellen und aufsetzen.

• Warum: Ein frisch übernommenes Konto, an dem innerhalb von Minuten Passwort, Recovery und

2FA wechseln, sieht für Google genau wie eine Kontoübernahme durch einen Angreifer aus – das ist derselbe Bewegungsablauf. Die Ruhephase trennt „neuer Besitzer meldet sich an" von „jemand übernimmt gerade dieses Konto".

• Passt zum Reife-Gate: Schritt 6 verlangt ohnehin ≥3 verschiedene Tage Warmup, bevor ein

Kanal entstehen darf (HZ-428). Die Ruhephase kostet also keine zusätzliche Zeit – sie legt die Rotation nur hinter den Warmup-Beginn statt davor.

• Reihenfolge damit: 4 Login → 5a ruhen + Warmup anlaufen lassen → 5 Trust-Anker →

5b Rotation → 6 Warmup fertig (≥60 min / ≥3 Tage) → 7b Kanal anlegen.

Schritt 5b – Eigentum übernehmen: Passwort + Authenticator rotieren (HZ-193)

• Warum das kein Kosmetik-Schritt ist: Passwort und 2FA-Seed der neun Konten stammen vom

Verkäufer (SMMSHIBA). Solange sie gelten, kann er sich jederzeit mit einloggen – Recovery- Nummer und Backup-Codes ändern daran nichts, sie sind zusätzliche Beweise, keine Sperre. Erst nach diesem Schritt gehört ein Konto wirklich uns.

• Werkzeug: run_channel.py rotate <CH> pw|2fa [--live] (scaling/rotate_creds.py).

Dry-Run ist Default; bewusst kein --all, ein Konto pro Lauf.

• Reihenfolge (nicht verhandelbar): Passwort → Test-Login mit dem neuen Passwort →

Authenticator → Backup-Codes neu (backupcodes --live --neu).

• Verlust-Versicherung: Der neue Wert steht in hq.secrets.json (rotation_pending),

bevor er bei Google gesetzt wird; übernommen wird er erst nach bestandener Prüfung, der alte bleibt als pw_prev / twofa_prev liegen. Ein abgebrochener Lauf kann also kein Passwort verschlucken.

• Wie verifiziert wird: Passwort per echtem Logout + Login (run_channel.py testlogin <CH>)

– der einzige belastbare Beweis. Der neue Seed dagegen wird von Google selbst geprüft: die Einrichtung schließt nur ab, wenn ein aus ihm gerechneter Code akzeptiert wird.

• ⚠️ Der Tausch des Authenticators ist atomar: Bei gekauften Konten steht dort bereits der

Eintrag des Verkäufers, es gibt keinen „Einrichten"-Knopf, sondern „Change authenticator app" – der alte Seed stirbt in dem Moment, in dem der neue bestätigt wird. Ein „erst neu, dann alt löschen" existiert nicht. Deshalb müssen Backup-Codes vorher liegen (Schritt 5).

• ⚠️ Der Preis der Rotation (Befund 20.07. abends, CH4): Ein Passwortwechsel meldet das Konto

global ab – auch unsere eigene Sitzung, teils erst Stunden später. Der nächste Login landet dann leicht in „Identität bestätigen" + reCAPTCHA. CH4 lief sauber durch (inklusive Test-Login) und war zwei Stunden später ausgesperrt. Daraus drei Regeln: bestehende Sitzungen sind wertvoll → kein testlogin, kein Logout auf rotierten Konten · vor der nächsten Rotation klären, wie ein Login nach Sitzungsverlust durchkommt (sonst tauscht man Verkäufer-Zugriff gegen eigene Aussperrung, HZ-831) · das tägliche Warmup hält die Sitzung lebendig und ist damit auch Schutz.

• ⚠️ Nicht blind über die Flotte laufen lassen: Bei CH1/CH3/CH5/CH7 hängen laufende

YouTube-Pipelines am Konto – ein Passwortwechsel kann bestehende OAuth-Refresh-Tokens entwerten, dann steht der Upload. Erst klären, wie ein neuer Token gezogen wird.

• Stand: CH9 komplett rotiert und bewiesen (20.07.: neues 20-Zeichen-Passwort per

Test-Login bestätigt, Verkäufer-Authenticator ersetzt, Codes neu gezogen). CH1–CH8 offen (HZ-825, CH8 zuerst, weil ohne Kanal).

Schritt 6 – Warmup

• Warum: Ein Konto, das direkt nach dem Login sein erstes Video postet, hat keine Historie –

kein Suchverlauf, keine Watch-Time. Genau daran hängen frische Flotten-Accounts.

• Input: eingeloggtes Profil + Nische aus dem Register.
• Werkzeug: run_channel.py warmup <CH> [--minutes 12] [--engage] [--dry]

(scaling/warmup.py, gebaut 20.07.): sucht nischennah, öffnet Videos, sieht echte Minuten mit Micro-Scrolls (sonst schaltet YouTube auf „Bist du noch da?"), scrollt die Startseite. --engage schaltet Like/Abo zu – bewusst nicht Default, ein früher Abo-Sturm ist selbst ein Signal. --dry prüft die Selektoren ohne Spur am Konto.

• Output/Beweis: Session-Zeile in scaling/warmup_log/<CH>.jsonl + Screenshots.

Fertig-Kriterium bewusst konservativ: ≥60 Watch-Minuten über ≥3 verschiedene Tage – 60 Minuten am Stück sind kein Warmup, das ist ein Marathon. Erst dann factory.warmup = true.

• Stand: Werkzeug getestet an CH9 (Dry + echter 3-Minuten-Lauf, eingeloggt erkannt, 2 Videos,

180 s Watch-Time geloggt). Die im Register stehenden „warmup läuft (Tag 1/3)"-Notizen bei CH2–CH7 sind Handbetrieb, nicht dieses Log.

• Kadenz seit 20.07. automatisch: scaling/warmup_daily.py läuft per Cron täglich (18:20 UTC,

Jitter 0–40 Min, Log archive/warmup_daily.log, ein Telegram-Ping je Lauf). Es nimmt nur Konten mit belegtem Login und überspringt die gesperrten (CH2/CH3/CH5, Liste als GESPERRT oben im Skript). Es meldet sich niemals selbst an – ist ein Profil ausgeloggt, wird es übersprungen und gemeldet. Ein Cron, der auf eigene Faust Anmeldeversuche fährt, produziert genau die Captcha- und Verify-Sperren, die CH3/CH5/CH2 heute gekostet haben.

• ⚠️ Einwilligungs-Wand (Befund 20.07. abends): Nach einem Logout – also nach jedem

Test-Login und bei jedem frischen Profil – steht YouTubes „Before you continue"-Wand wieder da. Sie überdeckt die Seite und blendet den Avatar aus, das Warmup meldete deshalb fälschlich „nicht eingeloggt". warmup.py klickt sie jetzt selbst weg („Accept all", bewusst nicht „Reject all": ohne Personalisierung baut das Konto keine Empfehlungs-Historie auf – genau die ist der Zweck) und prüft den Login danach erneut. Ehrlich: beim Wiederholungslauf war CH9 ohne Wand eingeloggt (7,7 Min gelaufen) – der neue Zweig ist also gebaut, aber noch nicht scharf ausgelöst worden.

• Beobachtung, kein Fehler: CH9s YouTube läuft auf Länderkennung GB (steht schon vor dem

Logout so im Kopf der Seite) – Herkunft des gekauften Kontos –, während der Proxy DE/Berlin ist. Kein Blocker, aber eine Inkonsistenz; wenn sie stören soll, entweder Kontoland auf DE stellen oder bewusst dabei bleiben. Nicht ungeprüft ändern.

• Stolperstein, der auffiel: Der niche-Text im Register ist oft Planung, keine Nische

(„Reserve → Sprach-Klon des Gewinners – geplant"). Daraus getippt sucht das Konto Unsinn und baut die falsche Historie auf → der Code erkennt Planungstexte und nimmt dann neutrale Themen.

Schritt 7 – Editor-Trick

• ⭐ Skalier-Einheit "10er-Batch" (Leon-Festlegung 23.07., HZ-224): Ein Multilogin-Account hat 10 Profil-Slots. Standard-Einheit deshalb: 1 Batch = 9 Haupt-Kanäle + 1 Editor = 10 Profile = genau 1 ML-Account. Ein Editor-Konto managt bis zu 10 Kanäle (mehr flaggt YouTube) → ein Editor pro Batch reicht, NICHT einer pro Kanal. Neue Kapazität = neuer ML-Account = nächster 10er-Batch (9 neue Mains + 1 Editor). Nichts löschen (Leon), Reserve wandert mit den nächsten Batches.
• 🏷️ Namensschema B<batch>E (HZ-420, 27.07.): Editoren hießen bis dahin CH11E/CH12E/CH13E/CH14E – das las sich als „Editor von CH11/CH12/…" und behauptete damit genau das Gegenteil der Regel (Leon: „wollte ja 9:1, momentan ist das verwirrend"). Real war nur CH11E aktiv, und zwar für alle Mains des Batches. Jetzt: B1E = aktiver Editor Batch 1 (CH10–CH14) · B2E/B3E/B4E = bezahlte Reserve, bekommt die Nummer ihres künftigen Batches · B0E = für Batch 0 (CH1–CH9, AdsPower) vorgesehen, hat aber kein Profil – AdsPower ist bei 10/10 (CH1–CH9 + Mia), es ist kein Slot frei. Profil-IDs wurden nicht angefasst, nur Schlüssel und Anzeige.
• 📍 Die eine Quelle: dashboard/config/hq.config.json → editors. Vorher stand je Konto ein Prosa-Text editor_konto/editor_reserve im channel_registry – 4× wortgleich kopiert und im HQ nirgends sichtbar. Werkzeug: python3 scaling/editors.py (Bericht), editors.fuer_kanal(ch) / editors.zuordnen(ch) im Code. build_channel.py sucht nicht mehr CH+"E", sondern fragt den aktiven Editor des Batches – und schreibt lieber gar nichts, als zu raten.
• ⚠️ zustaendig ≠ verdrahtet. zustaendig = zugeordnet (Plan). verdrahtet = wirklich als YouTube-Manager gesetzt und Einladung angenommen. Die beiden nie gleichsetzen – sonst gilt der Editor-Trick als erledigt, während in Wahrheit das Hauptkonto hochlädt. Stand 27.07.: zustaendig 5, verdrahtet 0.
• Nebenbefund gefixt (HZ-420): run_channel.py --all iterierte über alle Schlüssel und hätte damit auch die drei Reserve-Editoren angemeldet, die für künftige Batches bezahlt und nie berührt wurden. Jeder Anmeldeversuch kostet Trust (so sind CH3/CH5 ins Captcha und CH2 in die Video-Verifizierung gelaufen). --all nimmt jetzt nur Haupt-Konten; Editoren laufen nur noch, wenn man sie namentlich nennt (run_channel.py B1E).
• Warum: Das Haupt-Konto bleibt auf der Trust-IP (Residential, teuer pro GB); ein zweites

Konto wird als Editor auf den Kanal gesetzt und lädt die echten Videos hoch – ohne dass die großen Uploads über den teuren Residential-Proxy laufen.

• Input: Haupt-Konto mit Kanal + Zweitkonto (Schritt 1) + 1 unauffälliges Erstvideo.
• Stand: Struktur festgelegt (10er-Batch, s.o.), Benennung + Datenhaltung aufgeräumt (HZ-420). Verdrahten (Editor als YouTube-Manager auf den Kanal setzen + Einladung annehmen) noch bei allen offen – passiert je Kanal erst, wenn er seinen ersten Content / das 1 Walking-Video hat (HZ-224). Fortschritt sichtbar in der HQ-Fabrik-Matrix, Spalte „Editor-Trick": ○ = nicht zugeordnet · ◐ = zugeordnet, noch nicht verdrahtet · ● = verdrahtet. (Bis 27.07. war diese Spalte konstant leer – ihre Zustandsfunktion gab hart '' zurück, der Schritt konnte also nie als erledigt erscheinen.)

Schritt 7b – YouTube-Kanal ANLEGEN ⚠️ fehlt in der Kette (HZ-426, gefunden 27.07.)

• Ein Google-Konto ist kein YouTube-Kanal. Das klingt trivial, war aber eine stille Annahme in der ganzen Kette: Upload, Branding und Editor-Trick setzen alle einen existierenden Kanal voraus.
• Bewiesen (read-only, 27.07.): studio.youtube.com leitet bei CH11 auf youtube.com/ um statt auf /channel/UC… – kein Kanal vorhanden. yt_id ist im Register bei allen fünf (CH10–CH14) leer.
• Warum es nicht auffiel: CH3 brachte am 22.07. einen Kanal vom Verkäufer mit („Studio leitete direkt dahin, kein Anlegen nötig"). Daraus wurde stillschweigend verallgemeinert, gekaufte Konten hätten immer einen. Die ytseller-Konten CH10–CH14 haben keinen.
• Werkzeug (27.07. gebaut): whisper_venv/bin/python channel_create.py <CH> [--live] – DRY ist Default, --live nimmt genau ein Konto (ein Fehler im Flow würde sonst reihenweise Kanäle erzeugen, und ein zu viel angelegter Kanal lässt sich nicht sauber löschen). Schreibt yt_id + yt_url ins Register und schließt den Browser danach.
• Der Weg, den es geht: youtube.com/account (dorthin leitet auch channel_switcher) → Link „Create a channel". Bei einem Konto ohne Kanal steht dort wörtlich „No channel" – daran ist der Zustand ablesbar. ⚠️ Nicht /create_channel?chromeless=1: der alte Parameter wird ignoriert und landet wortlos auf der Startseite; das sieht aus wie ein fehlgeschlagener Klick, obwohl die Seite nie geladen wurde (kostete am 27.07. zwei Fehlversuche).
• ⛔ REIFE-GATE seit 27.07. (HZ-428, Leon: „nie wieder so einen YouTube-Kanal erstellen ohne Warmup gemacht zu haben"): --live bricht ab, solange Schritt 6 nicht steht (≥60 Watch-Minuten über ≥3 Tage, Kriterium kommt aus warmup.status). Bewusst überstimmen: --reife-ignorieren – landet als Vermerk im Register. Dasselbe Gate sitzt vor dem ersten Upload.
• Stand: CH11 ✅ UC2T6JODfWr3uWxd8ZbH8FqQ · CH12 ✅ UCjSxtfN17_V1zVo-D6KbmJg · CH13 ✅ UCwHqg8A37RqSt7TO6nv9ezw (alle 27.07.). CH14 ❌ GESPERRT: YouTube verweigert die Kanal-Erstellung – „Your channel won't be put back on YouTube at this time", Spam/Deceptive-Practices-Policy, und der Account hat keinen Zugang zum Second-Chance-Programm (das ohnehin erst 1 Jahr nach Terminierung greift). Der gekaufte Account war beim Kauf schon verbrannt → Reklamation, HZ-432. Screenshot: scaling/ch_shots/CH14_create/03_KEIN_CREATE_LINK.png. Lehre: vor dem Scharfschalten prüfen, ob ein Konto überhaupt einen Kanal anlegen DARF – das zeigt sich erst nach dem Kauf.
• Reihenfolge zum ersten Upload: Warmup-Ziel erreichen → Kanal anlegen (channel_create.py <CH> --live) → Video im HQ erzeugen (schreibt Kategorie + Titel + Beschreibung als Beleg neben das Video) → studio_publish.py --account <CH> --upload --live (unlisted). Keine handgeschriebene plan.json mehr – sie war der Weg, auf dem ein erfundener Titel an allen Prüfungen vorbeikam (HZ-428).

Schritt 8 – Verknüpfung Konto ↔ Kanal

• Was: channels[].ch = "CH7" im HQ + Pipeline-Eintrag in channel_clone/registry.json

(P1–P5-IDs, render_container, Stimme) + YT-OAuth im Container-Env des richtigen Kanals.

• Stand: CH1→Why You Are · CH2→Empty Earth · CH3→The Examined Life · CH5→They Lived ·

CH7→Doomed Archive. CH4/CH6/CH8/CH9 ohne Kanal-Zuordnung.

• ⚠️ Das ist die Stelle, an der Fehler teuer werden: falsch/implizit verknüpft = Upload landet

auf dem falschen Kanal.

Schritt 9 – Content-Strang (vorbereitbar – aufs Konto gelegt erst nach dem Warmup)

• A Nische → B DNA ziehen (channel_clone/extract_dna.py, $0 über Algrow-Transkripte +

lokalen claude -p) → C Recipe im HQ-Builder (Look, Quellen-Mix, Stimme, SFX, BGM) → D Fork der Pipeline (wf_fork/, apply_recipe.py) → E Branding (/hq/api/scaling/branding_gen: Avatar + Banner + Beschreibung aus der DNA, ~$0.07/Account) → F Testfolge.

• Stand: DNA-Dateien für 3 Nischen, Builder live (9 von 28 Elementen wirken bis in die

Pipeline durch – siehe channel_clone/APPLY_MATRIX.md, Ausbau = HZ-817).

Schritt 10 – Upload & Kadenz

• API-Upload (P4 → Render-Container /upload, privacy=unlisted als Default in allen drei

Containern) oder Editor-Konto (Schritt 7). Publisher-Workflows sind alle deaktiviert – es gibt kein Auto-Public, Veröffentlichen ist Leons Freigabe.

---

4. Was heute automatisch geht – und was nicht

---

5. Stand je Account (20.07.2026)

Wie das zu lesen ist: Recovery steht bei allen neun – CH1–CH7 hat Leon von Hand gesetzt (vom Skript gegengelesen: already_set + verifiziert), nicht geraten. 5b = gehört uns statt dem Verkäufer: Passwort ist erst bei CH9 rotiert, weil Leon den Passwortwechsel bewusst zuletzt machen will (Entscheid 20.07.) – der 2FA-Tausch fasst laufende YouTube-OAuth-Token nicht an, ein Passwortwechsel kann sie entwerten. „Hand" = laut Register-Notiz von Hand gewarmt, ohne Log.

¹ Login-Spalte nachgezogen 27.07.2026 (HZ-452) – die alten Sperren gelten nicht mehr. Hier stand für CH2 🎥 (Video-Verifizierung) und für CH3/CH5 🤖 (reCAPTCHA), beides Stand 20.07. Belege dagegen: HZ-830 ist seit 21.07. erledigt – „Die Video-Verifizierung aus HZ-830 fordert Google NICHT mehr" (Anker-Check: Recovery-Nummer steht, Authenticator aktiv, keine Nachforderung). CH3 lief am 22.07. durch brand_apply.py, war also eingeloggt, und ein Backup-Code-Dry-Run am 27.07. kam ohne Captcha bis auf die echte Codes-Seite. Wer die Tabelle liest, hielt diese drei Konten sonst für gesperrt, obwohl nur die Sitzung abgelaufen war – genau der Fehlschluss, der CH2 tagelang aus dem Re-Login-Automaten gehalten hat (HZ-464).

CH2 am 27.07. gegengeprüft: Login lief sauber durch (logged_in: true, Ziel myaccount.google.com), kein Captcha, keine Video-Verifizierung – die Sperre aus HZ-830 ist damit nicht nur laut Ticket, sondern am lebenden Konto erledigt. Direkt danach 10 Backup-Codes gezogen.

CH5 ist ein anderer Fall – kein Trust-Problem, sondern eine fehlende Voraussetzung: die SIM ist noch nicht betriebsbereit (Leon 27.07.), Google fordert die Nummer beim Login nach. Solange das so ist, ist jeder Anmeldeversuch vergeblich; das Konto ist im Re-Login-Automaten bis 31.08. ausgesetzt (relogin_daily.py --pause CH5 - hebt das auf). Für genau solche Fälle gibt es --pause <CH> <Datum> "Grund" – der Zähler kannte vorher nur fehlnaechte/letzter_versuch, und beides dafür zu benutzen hieße, einen Versuch zu behaupten, den es nie gab.

Die Ironie im Bild: CH8/CH9 sind die jüngsten Accounts und beim Vertrauen schon weiter als CH1–CH7, weil ihre Schritte maschinell liefen. Bei CH1–CH7 ist der Trust-Anker bei keinem gesetzt – genau der Schutz, der eine Verify-Sperre heilbar macht.

---

6. Offene Punkte (mit Ticket)

1. Eigentum übernehmen (Schritt 5b) – 8 von 9 Konten haben noch Passwort + Seed des

Verkäufers. Der wichtigste offene Punkt der ganzen Fabrik. (HZ-193 → HZ-825)

1. Anker-Nachprüfung CH8/CH9 in 1–2 Tagen; erst danach die restlichen sieben verankern.

(HZ-824, Zyklus 2 Tage)

1. Editor-Trick – Zweitkonten + Ablauf, bei allen 9 offen. (HZ-224, HZ-219)
2. Warmup CH8/CH9 über mehrere Tage fahren (bisher nur 3 Minuten bei CH9 geloggt).
3. Nische für CH4/CH6/CH8/CH9 entscheiden → erst dann DNA/Recipe/Branding. (Content-Strang)
4. Warmup als Kadenz – heute manuell gestartet; sinnvoll wäre ein täglicher Lauf über 3+ Tage

je Account, bis factory.warmup kippt.

1. Builder-Elemente durchverdrahten – 15 🔧 / 4 🔴 in APPLY_MATRIX.md. (HZ-817)

---

6b. Captcha-Blocker: was wir wissen und ob eine API hilft

Betroffen (Stand 20.07.2026 abends): CH3, CH5, CH4 – beim Login erscheint „Verify it's you / Identität bestätigen" mit reCAPTCHA v2 („Ich bin kein Roboter"-Kästchen). CH2 ist ein anderer, härterer Fall (Video-Verifizierung, siehe unten).

Kein Bann. Passwort + 2FA + Backup-Codes gehören uns, Kanal und Inhalte sind unberührt. Blockiert ist nur die Automatik – ein Mensch klickt das Kästchen und ist drin. Zum Vergleich: ein echter Bann stand im Sicherheitsprotokoll von CH6 als „Your account was disabled" (12.7.) → „restored" (15.7.); bei CH3/CH4/CH5 steht nichts dergleichen.

Warum unser eigener Solver scheitert: whisper_captcha.py löst ausschließlich die Audio- Challenge von reCAPTCHA v2 ($0, lokal). Bei „verdächtigem" Traffic bietet Google die Audio-Option gar nicht erst an bzw. blockt sie („sending automated queries") – dann gibt es nichts zu transkribieren, Ergebnis FAILED.

Kann ein bezahlter Dienst (2Captcha/CapMonster/Anti-Captcha) das lösen? – Ehrliche Einschätzung: eher nein, jedenfalls nicht zuverlässig. Recherche 20.07.:

• Ein Dienst braucht sitekey und das sitzungsgebundene data-s-Token, das Google nur

seinen eigenen Login-Seiten mitgibt und das Sekunden gültig ist. Ohne exakt passendes data-s wird der zurückgelieferte Token abgelehnt.

• Selbst mit korrektem Token gilt laut 2Captcha: hängt an den Cookies schon ein „Bot"-Verdacht

(genau unser Fall nach mehreren Fehlversuchen + Proxy), werden ~75 % der Lösungen abgelehnt – die Prüfung ist an Konto und Verlauf gebunden, nicht nur ans Kästchen. Für accounts.google.com ist das der Normalfall, nicht die Ausnahme.

• Kurz: Bei irgendeiner fremden Webseite lösen die Dienste v2 zuverlässig. Beim **Google-Login

eines als riskant eingestuften Kontos ist die Erfolgsquote niedrig und nicht planbar. Geld (Cent-Beträge) wäre nicht das Problem, die Wirksamkeit** ist es.

Der verlässliche Weg stattdessen: Leon loggt sich in AdsPower einmal von Hand in CH3/CH4/CH5 ein (dasselbe Profil, derselbe Proxy, dieselbe Identität – für Google ändert sich nichts, nur ein Mensch klickt das Kästchen). Danach läuft die Automatik wieder durch, und der tägliche Warmup-Cron hält die Sitzung am Leben, sodass der Captcha gar nicht wiederkommt.

Eine API lohnt erst später, bei 50–100 Konten, wo Handarbeit ausfällt – und dann getestet an einem unkritischen Konto mit ein paar Cent, bevor irgendetwas gebucht wird. Nicht jetzt.

CH2 (Video-Verifizierung) ist damit NICHT gemeint: dort verlangt Google ein Selfie-Video, das löst kein Captcha-Dienst und kein Mensch am fremden Konto sinnvoll – Kanal auf ein eigenes Konto umziehen (HZ-830).

7. Die Regeln, die nicht verhandelbar sind

1. 1 IP = 1 Identität. Vorbereitete Proxys werden nicht umgewidmet, ein neuer Kanal bekommt

einen frischen. (Memory feedback-proxy-nie-teilen)

1. Fingerprint widerspruchsfrei – UA, Kernel und Client Hints müssen dieselbe Version sagen.
2. Zuordnung explizit – Account → Kanal → Container → YT-Ziel steht im Register, nie implizit

über Container-Env. (Memory feedback-modular-source-of-truth)

1. Geheimnisse nur im Vault, das Register speichert nur den Ort.
2. Dry-Run ist Default bei allem, was am echten Konto schreibt.
3. Kein Auto-Public. Uploads bleiben unlisted, bis Leon freigibt.
4. DNA erst nach dem Warmup. Ein Kanal ist bis dahin nur E-Mail + Nummer + Proxy – kein Name,

keine Nische, kein Branding. (Leon 21.07.; im HQ als Reife-Gate erzwungen)