Ergebnisse erfassen: Status, Belege und record.py

Jeder Verzeichnisversuch endet mit einem Befehl. scripts/record.py schreibt pro Plattform eine einzige aktuelle Zeile in submissions.json im Produktordner und weigert sich bei Zeilen, die das Toolkit für unbelegt oder unsicher hält. Diese Weigerung ist der ganze Sinn: Der Tracker verhindert, dass „wir haben bei 40 Verzeichnissen eingereicht“ bedeutet „wir haben 40 Formulare ausgefüllt und gehofft“. Diese Anleitung behandelt die Status, die Belege, die jeder Status braucht, die Flags des Befehls und was in eine Notiz darf und was nicht. Sie ist eine Zusammenfassung von RUNBOOK.md und den Prüfungen des Skripts, kein Ersatz dafür.

Der Befehl

Das Beispiel aus dem Runbook, ausgeführt im Toolkit-Verzeichnis mit einem bereits angelegten privaten Projektordner:

Unter Windows verwendest du in den folgenden Befehlen py -3 statt python3 (oder python, wenn damit Python ab 3.10 gestartet wird). Lege den Arbeitsbereich in einem privaten lokalen Ordner außerhalb von OneDrive und anderen synchronisierten Ordnern an. Mehrzeilige Shell-Befehle führst du in PowerShell in einer Zeile aus; entferne dabei die \ am Zeilenende.

python3 scripts/record.py --project ../private-product pitchwall draft \
  --note "Product import corrected; final form not sent" \
  --next-action "Check saved profile and review final form"

Zwei Positionsargumente (Plattform-ID, Status) und zwei Pflichtoptionen (--note, --next-action). Die optionalen Flags sind --public-url, --confirmed-public, --launch-date und --replace. Die Plattform-ID muss ein Slug in Kleinbuchstaben sein, der Status einer der elf unten, und der Tracker beendet sich mit einer Erklärung, sobald eine Regel nicht erfüllt ist. Das Erfassungsformular des lokalen Dashboards ruft dieselbe Funktion mit denselben Regeln auf.

Die elf Status und ihr Mindestbeleg

Die Tabelle des Runbooks, in Kurzform:

Status	Was du beobachtet haben musst
draft	Arbeit vorbereitet; finale Einreichung nicht bestätigt.
prepared_needs_human	Eine konkrete Owner-Aktion oder Hürde (CAPTCHA, 2FA) blockiert die vorbereitete Arbeit.
submitted_pending_review	Die Plattform hat den Eingang ausdrücklich bestätigt; die Moderation steht aus.
queued	Die Plattform bestätigt eine Warteschlangenposition oder einen Wartelistenstatus.
scheduled	Die Plattform bestätigt ein Launch-Datum am oder nach der Untergrenze; eine ausstehende Freigabe bleibt in der Notiz.
live	Öffentlicher Eintrag verifiziert, kein „ausstehend“-Etikett; öffentliche URL und --confirmed-public erforderlich.
already_listed	Ein bestehender öffentlicher Eintrag verifiziert; dieselben Anforderungen wie live.
blocked	Eignung, Kontokapazität oder ein fehlender Pflichtfakt verhindern Fortschritt.
deferred_paid	Der nutzbare Weg kostet Geld; nichts wurde gekauft.
not_a_fit	Das Produkt erfüllt die Zielgruppen- oder Aufnahmekriterien nicht.
unavailable	Der Weg oder die Plattform ist derzeit nicht nutzbar; das Problem steht in der Notiz.

Die wichtigsten Unterscheidungen sind Entwurf vs. eingereicht und ausstehend vs. live. Ein Danke-Bildschirm macht einen Eintrag nicht live. Eine erreichbare Seite kann trotzdem auf Freigabe warten. Ein angekreuztes „auch an unsere Partner verteilen“ heißt nicht, dass eine zweite Plattform irgendetwas erhalten hat. Das Ergebnis jeder Plattform bleibt unabhängig, damit Summen nie aufgebläht werden.

Die Regeln, die das Skript durchsetzt

• Öffentliche Status brauchen Belege. live und already_listed verlangen --public-url mit einer geprüften HTTPS-URL – kein Query-String, kein Fragment, keine Konto-, Dashboard- oder Login-Pfade – und --confirmed-public, deine Erklärung, dass du die Seite angesehen hast.
• Geplant braucht ein Datum. --launch-date YYYY-MM-DD ist Pflicht und darf nicht vor earliest_launch_date in product.json liegen; die Anleitung zum frühesten Launch-Datum erklärt, warum.
• Notizen bleiben sauber. Notizen und nächste Aktionen dürfen keine Links, E-Mail-Adressen, Paare im Stil von password= oder bekannte Token-Präfixe enthalten. Die Tracker-Datei soll teilbar sein; Belege mit Konto-URLs gehören in private Ablage.
• Eine Zeile pro Plattform. Hat die Plattform schon eine Zeile, schlägt der Befehl fehl, es sei denn, du übergibst --replace – nachdem du sowohl die bestehende Zeile als auch die Plattform geprüft hast. Ersetzen ist Absicht, nie ein Nebeneffekt.
• Keine Symlinks, atomare Schreibvorgänge, eine Lock-Datei. Langweilige Details, aber sie sind der Grund, warum zwei gleichzeitig schreibende Agenten den Tracker nicht beschädigen.

Fortsetzen ohne Duplikate

Lies zu Beginn der nächsten Sitzung den Tracker, bevor du ein Formular anfasst. Priorisiere Übergaben an Menschen und geplante Launches, deren Verifizierung fällig ist, dann ausstehende Einreichungen, deren angegebenes Prüffenster abgelaufen ist. Nennt eine Plattform keine Prüfdauer, vereinbare ein Nachfassdatum mit dem Owner, statt eins zu erfinden. Und reiche nie erneut ein, um in der Warteschlange vorzurücken: Prüfe den bestehenden Eintrag erneut. Der Tracker speichert den aktuellen Zustand, keine Historie; brauchst du einen Prüfpfad, archiviere geschwärzte Lauf-Zusammenfassungen separat.

Ausgearbeitete Beispiele der Status auf echten Plattformen findest du im Artikel zu den Einreichungsstatus und in der älteren Anleitung zum Tracking ohne Doppelzählung; das Vokabular selbst ist unter Listing-Status definiert.