Zapisywanie wyników: stany, dowody i record.py

Każda próba w katalogu kończy się jednym poleceniem. scripts/record.py zapisuje jeden aktualny wiersz na platformę w pliku submissions.json w folderze produktu i odrzuca wiersze, które zestaw uznaje za nieudowodnione lub niebezpieczne. Ta odmowa to sedno sprawy: dzięki trackerowi „zgłosiliśmy produkt do 40 katalogów” nie oznacza „wypełniliśmy 40 formularzy i liczyliśmy na szczęście”. Ten przewodnik omawia stany, dowody wymagane dla każdego z nich, flagi polecenia oraz to, co wolno, a czego nie wolno umieszczać w notatce. To streszczenie RUNBOOK.md i kontroli wbudowanych w skrypt, a nie ich zamiennik.

Polecenie

Przykład z runbooka, uruchamiany z folderu zestawu przy już utworzonym prywatnym folderze projektu:

W Windows w poniższych poleceniach używaj py -3 zamiast python3 (albo python, jeśli tym poleceniem uruchamiasz Pythona 3.10+). Trzymaj przestrzeń roboczą w prywatnym folderze lokalnym, poza OneDrive i innymi folderami synchronizowanymi. W PowerShellu zapisuj wielowierszowe przykłady w jednej linii i usuń końcowe znaki \.

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"

Dwa argumenty pozycyjne (identyfikator platformy, stan) i dwie wymagane opcje (--note, --next-action). Opcjonalne flagi to --public-url, --confirmed-public, --launch-date i --replace. Identyfikator platformy musi być slugiem pisanym małymi literami, stan musi być jednym z jedenastu wymienionych niżej, a gdy jakaś reguła nie jest spełniona, tracker kończy działanie z wyjaśnieniem. Formularz zapisu w lokalnym dashboardzie wywołuje tę samą funkcję z tymi samymi regułami.

Jedenaście stanów i minimalne dowody

Tabela z runbooka w skrócie:

Stan	Co musisz zaobserwować
draft	Praca jest przygotowana; ostateczne zgłoszenie nie zostało potwierdzone.
prepared_needs_human	Przygotowaną pracę blokuje konkretne działanie właściciela lub wyzwanie (CAPTCHA, 2FA).
submitted_pending_review	Platforma wyraźnie potwierdziła otrzymanie zgłoszenia; pozostaje moderacja.
queued	Platforma potwierdza miejsce w kolejce lub na liście oczekujących.
scheduled	Platforma potwierdza datę premiery nie wcześniejszą niż dolna granica; oczekująca akceptacja zostaje odnotowana w notatce.
live	Publiczny wpis zweryfikowany, bez etykiety oczekiwania; wymagane są publiczny URL i --confirmed-public.
already_listed	Zweryfikowano istniejący publiczny wpis; wymagania takie same jak dla live.
blocked	Postęp uniemożliwiają kryteria kwalifikacji, limit konta lub brak obowiązkowej informacji.
deferred_paid	Dostępna ścieżka wymaga płatności; niczego nie kupiono.
not_a_fit	Produkt nie spełnia kryteriów dotyczących odbiorców lub wpisu.
unavailable	Ścieżki lub platformy nie da się obecnie użyć; opisz problem w notatce.

Najważniejsze rozróżnienia to szkic a zgłoszenie oraz oczekujący a opublikowany wpis. Ekran z podziękowaniem nie oznacza, że wpis jest opublikowany. Strona, na którą da się wejść, wciąż może czekać na akceptację. Zaznaczone pole w rodzaju „roześlij też do naszego partnera” nie oznacza, że druga platforma cokolwiek otrzymała. Wynik każdej platformy pozostaje niezależny, żeby sumy nigdy nie były zawyżone.

Reguły egzekwowane przez skrypt

• Stany publiczne wymagają dowodu. live i already_listed wymagają --public-url ze sprawdzonym adresem HTTPS — bez parametrów zapytania, bez fragmentu, bez ścieżek konta, dashboardu czy logowania — oraz --confirmed-public, czyli twojego oświadczenia, że strona została przez ciebie obejrzana.
• Stan zaplanowany wymaga daty. --launch-date YYYY-MM-DD jest obowiązkowe i nie może być wcześniejsze niż earliest_launch_date w product.json; dlaczego, wyjaśnia przewodnik po dolnej granicy daty premiery.
• Notatki pozostają czyste. Notatki i następne kroki nie mogą zawierać linków, adresów e-mail, par w stylu password= ani znanych prefiksów tokenów. Plik trackera ma nadawać się do udostępniania; dowody z adresami URL kont należą do prywatnego magazynu.
• Jeden wiersz na platformę. Jeśli platforma ma już wiersz, polecenie się nie powiedzie, chyba że podasz --replace — po sprawdzeniu zarówno istniejącego wiersza, jak i samej platformy. Zastąpienie jest zawsze zamierzone, nigdy nie jest efektem ubocznym.
• Żadnych dowiązań symbolicznych, zapisy atomowe, plik blokady. Nudne szczegóły, ale to dzięki nim dwóch agentów zapisujących jednocześnie nie uszkodzi trackera.

Wznawianie bez duplikatów

Na początku następnej sesji przeczytaj tracker, zanim dotkniesz jakiegokolwiek formularza. Najpierw zajmij się przekazaniami do człowieka i zaplanowanymi premierami, które czekają na weryfikację, a potem oczekującymi zgłoszeniami, których podany czas moderacji już minął. Jeśli platforma nie podaje czasu moderacji, uzgodnij z właścicielem termin kontroli, zamiast go wymyślać. I nigdy nie zgłaszaj ponownie, żeby przesunąć się w kolejce: sprawdź istniejący zapis. Tracker przechowuje bieżący stan, a nie historię; jeśli potrzebujesz ścieżki audytu, archiwizuj osobno podsumowania serii z usuniętymi danymi wrażliwymi.

Przykłady stanów na prawdziwych platformach znajdziesz w artykule o stanach zgłoszeń i we wcześniejszym przewodniku o śledzeniu zgłoszeń bez podwójnego liczenia; samo słownictwo definiuje hasło listing status.