Sonuçları kaydetmek: durumlar, kanıtlar ve record.py

Her dizin denemesi tek bir komutla biter. scripts/record.py, ürün klasöründeki submissions.json dosyasına platform başına tek bir güncel satır yazar ve araç setinin kanıtlanmamış ya da güvensiz saydığı satırları reddeder. Bütün mesele bu reddetmede: takip aracı, “40 dizine gönderdik” cümlesinin “40 form doldurup en iyisini umduk” anlamına gelmesini engelleyen şeydir. Bu rehber durumları, her durumun gerektirdiği kanıtı, komutun bayraklarını ve bir notta nelerin yer alıp alamayacağını anlatıyor. RUNBOOK.md dosyasının ve betiğin kendi kontrollerinin bir özetidir, onların yerini tutmaz.

Komut

Runbook’taki örnek; araç seti dizininden, önceden oluşturulmuş özel bir proje klasörüyle:

Windows’ta aşağıdaki komutlarda python3 yerine py -3 kullan (Python 3.10+ komutun buysa python). Çalışma alanını OneDrive ya da başka senkronizasyon klasörlerinin dışında, özel bir yerel klasörde tut. Çok satırlı kabuk örneklerini PowerShell’de kullanırken komutu tek satıra yaz ve satır sonlarındaki \ karakterlerini kaldır.

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"

İki konumsal argüman (platform kimliği, durum) ve iki zorunlu seçenek (--note, --next-action). İsteğe bağlı bayraklar --public-url, --confirmed-public, --launch-date ve --replace. Platform kimliği küçük harfli bir slug, durum ise aşağıdaki on bir durumdan biri olmalıdır; bir kural karşılanmadığında takip aracı bir açıklamayla çıkar. Yerel paneldeki kayıt formu da aynı fonksiyonu aynı kurallarla çağırır.

On bir durum ve asgari kanıtları

Runbook’taki tablo, kısaca:

Durum	Gözlemlemiş olman gereken
draft	İş hazırlandı; son gönderim onaylanmadı.
prepared_needs_human	Hazırlanan işi, sahibinin yapması gereken belirli bir eylem ya da bir doğrulama adımı (CAPTCHA, 2FA) engelliyor.
submitted_pending_review	Platform gönderimi aldığını açıkça bildirdi; moderasyon sürüyor.
queued	Platform bir sıra konumunu ya da bekleme listesi durumunu onaylıyor.
scheduled	Platform alt sınırda ya da sonrasında bir lansman tarihini onaylıyor; bekleyen onay notta kalır.
live	Herkese açık listeleme doğrulandı, bekleme etiketi yok; herkese açık URL ve --confirmed-public gerekli.
already_listed	Mevcut, herkese açık bir listeleme doğrulandı; live ile aynı gereksinimler geçerli.
blocked	Uygunluk, hesap kapasitesi ya da eksik zorunlu bir bilgi ilerlemeyi engelliyor.
deferred_paid	Kullanılabilir yol ödeme gerektiriyor; hiçbir şey satın alınmadı.
not_a_fit	Ürün, hedef kitle ya da listeleme kriterlerini karşılamıyor.
unavailable	Yol ya da platform şu anda kullanılamıyor; sorunu nota yaz.

En önemli ayrımlar, taslak ile gönderilmiş ve bekleyen ile yayında arasındaki ayrımlardır. Bir teşekkür ekranı listelemeyi yayına almaz. Erişebildiğin bir sayfa hâlâ onay bekliyor olabilir. İşaretlenmiş bir “ortaklarımıza da dağıt” kutusu, ikinci bir platformun herhangi bir şey aldığı anlamına gelmez. Toplamların asla şişmemesi için her platformun sonucu bağımsız kalır.

Betiğin uyguladığı kurallar

• Herkese açık durumlar kanıt ister. live ve already_listed, gözden geçirilmiş bir HTTPS URL’si içeren --public-url (sorgu dizesi, fragment ya da hesap, panel veya giriş yolu olmadan) ve sayfaya baktığına dair beyanın olan --confirmed-public gerektirir.
• Scheduled bir tarih ister. --launch-date YYYY-MM-DD zorunludur ve product.json içindeki earliest_launch_date değerinden önce olamaz; nedenini lansman tarihi alt sınırı rehberi açıklıyor.
• Notlar temiz kalır. Notlar ve sonraki adımlar bağlantı, e-posta adresi, password= tarzı çiftler ya da bilinen token önekleri içeremez. Takip dosyası paylaşılabilir olacak şekilde tasarlanmıştır; hesap URL’leri içeren kanıtların yeri özel bir depolama alanıdır.
• Platform başına bir satır. Platformun zaten bir satırı varsa, --replace vermediğin sürece komut başarısız olur; bunu da ancak hem mevcut satırı hem de platformu inceledikten sonra yap. Değiştirme bilinçli bir işlemdir, asla bir yan etki değildir.
• Sembolik bağlantı yok, atomik yazma, kilit dosyası. Sıkıcı ayrıntılar, ama aynı anda yazan iki ajanın takip dosyasını bozmamasının nedeni bunlar.

Mükerrer gönderim yapmadan devam etmek

Sonraki oturumun başında, herhangi bir forma dokunmadan önce takip dosyasını oku. Önceliği sana devredilen adımlara ve doğrulama zamanı gelmiş planlanmış lansmanlara ver, ardından belirtilen inceleme süresi geçmiş bekleyen gönderimlere geç. Platform inceleme süresi hakkında bilgi vermiyorsa bir süre uydurmak yerine sahibiyle bir takip tarihi üzerinde anlaş. Sırada öne geçmek için asla yeniden gönderim yapma; mevcut kaydı tekrar kontrol et. Takip aracı geçmişi değil, güncel durumu saklar; bir denetim kaydına ihtiyacın varsa hassas bilgileri ayıklanmış çalıştırma özetlerini ayrıca arşivle.

Durumların gerçek platformlardaki örnekleri için gönderim durumları makalesini ve çift saymadan takip üzerine yazılmış daha eski rehberi oku; terimlerin tanımları ise listeleme durumu başlığı altında.