Wysłane, oczekujące, zaplanowane, opublikowane: czemu stany są ważne

Zgłoszenie oczekuje, gdy katalog je otrzymał, ale jeszcze nie podjął decyzji. Jest opublikowane, gdy obca osoba może otworzyć wpis i nie widzi na nim etykiety „oczekuje”. Zaplanowane oznacza, że platforma potwierdziła datę premiery. Samo wysłane znaczy tylko tyle, że kliknąłeś przycisk. Te cztery słowa opisują cztery różne momenty, a tracker, który trzyma je w jednej kolumnie „zrobione”, pokaże sumę, której nikt nie obroni. Ten artykuł wyjaśnia każdy stan, co liczy się jako dowód i jak raportować premierę w katalogach liczbami, które wytrzymują sprawdzenie. Krótką definicję pojęcia nadrzędnego znajdziesz w haśle status wpisu, a codzienną rutynę w przewodniku po śledzeniu zgłoszeń.

Jedna kolumna, pięć pytań

Gdy zgłaszasz produkt do katalogu, osoby, którym zależy na wyniku, chcą wiedzieć różne rzeczy:

• Czy praca po mojej stronie jest skończona? Czy wszystko wypełniłem i kliknąłem przycisk?
• Czy platforma to otrzymała? Strona z podziękowaniem, e-mail, wpis na koncie.
• Czy coś na coś czeka? Moderacja, miejsce w kolejce, zatwierdzenie, data.
• Czy widać to publicznie? Adres URL, który otwiera się komuś niezalogowanemu i nie ma etykiety „oczekuje”.
• Czy muszę coś zrobić? CAPTCHA, monit dwuskładnikowy, odznaka na mojej stronie, decyzja o płatnej ścieżce.

„Zrobione” odpowiada na pierwsze pytanie i po cichu przypisuje sobie czwarte. W ten sposób arkusz, w którym stoi 40, zaczyna oznaczać 6. Różnica między pierwszymi dwoma pytaniami ma własne hasło: szkic vs wysłane.

Oczekujące vs opublikowane, zaplanowane vs wysłane

Te pary ludzie mylą najczęściej. Każdy wiersz to pytanie, które warto zadać, zanim zmienisz status.

Para	Różnica	Dowód, który przesuwa dalej
Wysłane vs oczekujące na weryfikację	Wysłanie to twoje działanie; oczekiwanie na weryfikację to potwierdzenie platformy, że moderacja się zaczęła	Potwierdzenie od platformy: strona sukcesu, e-mail albo wpis w panelu konta
Oczekujące na weryfikację vs opublikowane	Oczekujące czeka na decyzję; opublikowane jest widoczne publicznie i bez etykiety	Publiczny adres URL otwiera się po wylogowaniu, bez etykiety „oczekuje”
Zaplanowane vs opublikowane	Zaplanowane ma potwierdzoną datę; opublikowane ma publiczną stronę	Otwarcie strony w tym dniu lub później
W kolejce vs zaplanowane	W kolejce oznacza miejsce w kolejce; zaplanowane oznacza datę	Platforma podaje datę
Opublikowane vs już obecne w katalogu	Opublikowane wynika z tego zgłoszenia; już obecne istniało, zanim zacząłeś	Wcześniejsze sprawdzenie, czy wpis już istnieje

Ostatni wiersz znaczy więcej, niż się wydaje. Jeśli katalog ma już wpis o twoim produkcie, ponowne zgłoszenie tworzy duplikat, który platforma może odrzucić albo usunąć. Dlatego tracker ma na to osobny stan.

Jedenaście stanów, pogrupowanych według pytania, na które odpowiadają

Tracker LaunchRepo (record.py, który zapisuje submissions.json, oraz te same reguły w lokalnym panelu) używa jedenastu stanów. Każdy wymaga minimalnej obserwacji, zanim wolno go zapisać. Panel przypisuje każdą platformę do dokładnie jednej grupy, więc grupy zawsze sumują się do liczby platform, do których podjęto próbę.

Pytanie	Stan	Grupa w panelu	Następny krok
Praca po twojej stronie	draft	draft	Dokończ i wyślij albo odrzuć
Praca po twojej stronie	prepared_needs_human	needs_you	Wykonaj wskazany krok: CAPTCHA, 2FA, odznaka, decyzja
Otrzymane	submitted_pending_review	pending	Sprawdź ponownie po podanym czasie weryfikacji
Otrzymane	queued	queued	Czekaj na kolejkę; sprawdzaj ponownie, nigdy nie zgłaszaj drugi raz
Otrzymane	scheduled	scheduled	Otwórz wpis w potwierdzonym dniu
Publiczne	live	live	Nic; zachowaj adres URL
Publiczne	already_listed	already_listed	Nic; nie zgłaszaj ponownie
Zatrzymane	blocked	problem	Usuń ograniczenie kwalifikacji albo limitu konta lub zrezygnuj
Zatrzymane	unavailable	problem	Spróbuj ponownie, gdy ścieżka zacznie działać
Zatrzymane	deferred_paid	parked	Twoja decyzja: zapłać poza serią albo pomiń
Zatrzymane	not_a_fit	parked	Brak

Jedenaście brzmi jak dużo. W praktyce każdy stan istnieje dlatego, że połączenie go z sąsiednim przynajmniej raz dało błędny raport. Przewodnik po zapisywaniu wyników pokazuje dokładne polecenia dla każdego stanu.

Przykład 1: SaaSHub, publiczny, ale oczekujący

Zgłoszenie do SaaSHub, opisane w publicznym przewodniku po zgłoszeniu do SaaSHub, dało stronę produktu, którą mógł otworzyć każdy, kto miał link. Strona miała jednak widoczną etykietę: Pending approval (oczekuje na zatwierdzenie).

Tracker z jedną kolumną zapisze to jako zrobione, a nawet jako opublikowane, bo strona się ładuje. Reguła LaunchRepo jest odwrotna: sama publiczna dostępność nie jest dowodem akceptacji. Wpis pozostaje submitted_pending_review, dopóki strona mówi, że oczekuje. Przechodzi do live dopiero wtedy, gdy ktoś otworzy go ponownie, nie zobaczy etykiety oczekiwania i zapisze adres URL z wyraźną flagą potwierdzenia. W dniu zgłoszenia liczba opublikowanych wpisów nie wzrosła; zamiast tego wiersz dostał datę ponownego sprawdzenia.

Przykład 2: TinyLaunch, zaplanowany z otwartym zatwierdzeniem

TinyLaunch, opisany w przewodniku po zgłoszeniu do TinyLaunch, zaproponował przyszły tygodniowy termin premiery w darmowej ścieżce Standard. Po potwierdzeniu daty panel platformy pokazywał go obok Waiting for approval (czeka na zatwierdzenie).

Są dwa złe sposoby, żeby to zapisać: live, bo w kalendarzu jest data, albo submitted_pending_review, bo zatwierdzenie jest otwarte. Tracker zapisuje scheduled z potwierdzoną datą, a otwarte zatwierdzenie trzyma w notatce. Oba fakty zostają zachowane: data istnieje i może się nie utrzymać. Tracker odrzuca też datę scheduled wcześniejszą niż minimalna data premiery produktu, więc darmowy termin w najbliższy poniedziałek nie może ruszyć, zanim twoja strona premiery będzie gotowa. Hasło zaplanowany wpis opisuje ten stan w jednym akapicie.

Czego tracker nie przyjmie

Reguły spisane na stronie łatwo pominąć. Tych pilnuje skrypt. Poniżej prawdziwe uruchomienie z 30 września 2026 roku w świeżym obszarze roboczym z przykładowym produktem: sześć wyników odpowiadających publicznym przewodnikom, a potem próba przestawienia SaaSHub na opublikowany. buckets.py to czterolinijkowy skrypt pomocniczy napisany na potrzeby tego artykułu; wypisuje to, co zwraca funkcja grupująca samego panelu.

$ python3 scripts/record.py --project projects/my-product saashub submitted_pending_review --note 'Public page labelled Pending approval' --next-action 'Recheck the label after the review window'
Recorded saashub: submitted_pending_review
$ python3 scripts/buckets.py
{"attempted": 6, "submitted": 4, "pending": 2, "scheduled": 2, "problem": 2}
$ python3 scripts/record.py --project projects/my-product saashub live --note 'Page loads' --next-action None
Tracker rejected input: Public states require a reviewed URL and --confirmed-public
$ python3 scripts/record.py --project projects/my-product saashub live --public-url https://www.saashub.com/my-product --confirmed-public --note 'Pending label gone' --next-action None
Tracker rejected input: Platform exists: inspect the record and use --replace intentionally
$ python3 scripts/record.py --project projects/my-product saashub live --replace --public-url https://www.saashub.com/my-product --confirmed-public --note 'Pending label gone' --next-action None
Recorded saashub: live
$ python3 scripts/buckets.py
{"attempted": 6, "submitted": 4, "pending": 1, "scheduled": 2, "live": 1, "problem": 2}

Dzieją się tu trzy rzeczy. „Strona się ładuje” nie wystarcza do live: tracker wymaga zweryfikowanego publicznego adresu URL i flagi potwierdzenia. Istniejący wiersz nigdy nie zostaje po cichu nadpisany: zmiana wymaga świadomego --replace. A przestawienie SaaSHub przenosi jedną platformę z oczekujących do opublikowanych, podczas gdy wysłane zostaje na 4, bo zmiana statusu to nie nowe zgłoszenie. Gdy opublikowany wpis zostanie zapisany, wiersz zawiera adres URL, który każdy może sprawdzić.

Trzy liczby zamiast jednej sumy

Dobry raport nigdy nie podaje jednej liczby. Podaje trzy, a każda odpowiada na inne pytanie:

1. Wysłane: do ilu platform trafił produkt. W panelu to pending + queued + scheduled + live.
2. Opublikowane: do ilu publicznych wpisów możesz dziś podać link.
3. Wymaga ciebie: ile wierszy czeka na człowieka.

Te same reguły decydują, co liczy się do celu serii. Runbook zestawu liczy platformę raz, gdy po raz pierwszy osiągnie submitted_pending_review, queued, scheduled lub live. Szkice, przekazania człowiekowi, płatne ścieżki, odrzuceni kandydaci i already_listed nigdy nie przybliżają celu, a późniejsze aktualizacje tej samej platformy nie liczą się ponownie. Prawdziwe zgłoszenie, które moderacja później odrzuci, pozostaje policzone jako wysłane; poprawia się tylko potwierdzenie zapisane przez pomyłkę, za pomocą --invalidate-run-confirmation.

Nasz własny pilotaż pokazuje, dlaczego ten podział ma znaczenie. Log SeoMap z 14 września 2026 roku, opublikowany na stronie założyciela, zawierał 211 prób zgłoszeń: 20 opublikowanych, 97 oczekujących na weryfikację i 24 zaplanowane. Pozostałe 70 prób nie osiągnęło żadnego z tych trzech stanów. „211 zrobionych” byłoby prawdą w jednym sensie i nieprawdą w każdym użytecznym.

Dlaczego agent potrzebuje tego bardziej niż ty

Jeśli ręcznie zgłaszasz produkt do pięciu katalogów, pamiętasz, który oczekuje, a który pokazał kalendarz. Agent AI, który prowadzi sesję, zamyka ją i wznawia jutro, być może jako inny agent na innym komputerze, tego nie pamięta. Najpierw czyta tracker i decyduje na podstawie stanu:

• Wiersze prepared_needs_human i premiery scheduled, które czekają na sprawdzenie, idą pierwsze.
• Wiersze submitted_pending_review, których podany czas weryfikacji minął, są sprawdzane ponownie: istniejący zapis, nigdy nowe zgłoszenie, żeby przeskoczyć kolejkę.
• Wierszy live agent nie rusza.

Każda z tych decyzji jest błędna, jeśli błędny jest stan. Zapisanie SaaSHub jako opublikowanego pierwszego dnia oznaczałoby, że nikt nie sprawdziłby, czy wpis został zatwierdzony. Zapisanie TinyLaunch jedynie jako wysłanego oznaczałoby, że nikt nie zweryfikowałby strony w dniu premiery. Stany są pamięcią agenta, a lokalny dashboard to miejsce, w którym je odczytujesz.

Jeśli przygotowujesz własną serię, strona jak działa LaunchRepo pokazuje, gdzie w procesie znajduje się tracker, a strona dla założycieli SaaS opisuje produkt z prawdziwym kalendarzem premiery. Tracker, panel i 299 aktywnych playbooków (według stanu z 24 września 2026 roku) dostajesz w ramach jednorazowej licencji.

Najczęściej zadawane pytania

Czym różni się oczekujące od opublikowanego?

Oczekujące oznacza, że katalog otrzymał twoje zgłoszenie i nie zakończył weryfikacji. Opublikowane oznacza, że wpis jest publiczny i nie ma etykiety oczekiwania. Strona, którą da się otworzyć, wciąż może oczekiwać, więc sprawdzaj etykietę, a nie tylko adres URL.

Czy zaplanowany wpis jest już opublikowany?

Nie. Zaplanowany oznacza, że platforma potwierdziła datę premiery; wpis staje się publiczny tego dnia, a zatwierdzenie wciąż może być otwarte. Otwórz stronę w tym dniu lub później, zanim zapiszesz ją jako opublikowaną.

Czy strona z podziękowaniem oznacza, że moje zgłoszenie zostało przyjęte?

Nie. Strona z podziękowaniem pokazuje, że formularz został wysłany. Co najwyżej dowodzi otrzymania, więc status to oczekujące na weryfikację, dopóki platforma nie opublikuje wpisu.

Jak długo zgłoszenia pozostają oczekujące?

Tak długo, jak trwa weryfikacja na platformie. Darmowe ścieżki są często powolne; jeden z przewodników na tej stronie odnotowuje szacunek ponad 30 dni. Kieruj się czasem podanym przez platformę albo ustal datę ponownego sprawdzenia, jeśli platforma żadnego nie podaje.

Czy zgłosić ponownie, jeśli wpis wciąż oczekuje?

Nie. Sprawdź istniejące zgłoszenie po upływie czasu weryfikacji i skontaktuj się z platformą, jeśli jej zasady na to pozwalają. Ponowne zgłoszenie może tworzyć duplikaty i nie przesuwa cię wyżej w kolejce.

Źródła: RUNBOOK.md (tabela stanów, reguły liczenia i korekt), scripts/record.py i scripts/dashboard_status.py w zestawie LaunchRepo 1.9.0; prawdziwe uruchomienie trackera 30 września 2026 roku; publiczne przewodniki po SaaSHub i TinyLaunch (obserwacje z 13 września 2026 roku); log SeoMap z 14 września 2026 roku na stronie założyciela.