LaunchRepoディレクトリへの申請は、成否にかかわらず、どれも1つのコマンドで締めくくります。scripts/record.pyは、プロダクトフォルダ内のsubmissions.jsonに、プラットフォームごとに現在の状態を表す1行を書き込みます。そして、キットが裏付けがない、または安全でないと判断する行は拒否します。この拒否こそが肝心です。トラッカーがあるからこそ、「40のディレクトリに申請した」が「40のフォームに入力して、うまくいくことを祈った」という意味にならずに済むのです。このガイドでは、状態の種類、それぞれの状態に必要な証跡、コマンドのフラグ、そしてメモに書いてよいこと・いけないことを説明します。これはRUNBOOK.mdとスクリプト自体のチェックの要約であり、それらの代わりになるものではありません。
コマンド
ランブックに載っている例です。作成済みのプライベートなプロジェクトフォルダがある状態で、キットのディレクトリから実行します。
Windowsでは、以下のコマンドのpython3の代わりにpy -3を使ってください（Python 3.10以降のコマンドがpythonの場合はそちらを使います）。ワークスペースは、OneDriveなどの同期フォルダの外にある、プライベートなローカルフォルダに置いてください。複数行にわたるシェルの例をPowerShellで使う場合は、コマンドを1行にまとめ、行末の\を削除してください。
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"位置引数が2つ（プラットフォームID、状態）、必須オプションが2つ（--note、--next-action）です。任意のフラグは--public-url、--confirmed-public、--launch-date、--replaceです。プラットフォームIDは小文字のスラッグで、状態は下記の11種類のいずれかでなければなりません。ルールを満たしていない場合、トラッカーは理由を説明して終了します。ローカルダッシュボードの記録フォームも、同じルールで同じ関数を呼び出します。
11種類の状態と、それぞれに必要な最低限の証跡
ランブックの表を簡潔にまとめると、次のとおりです。
| 状態 | 観察しておく必要があること |
|---|---|
draft |
作業は準備済み。最終的な申請は確認されていない。 |
prepared_needs_human |
オーナーが行うべき具体的な操作や確認（CAPTCHA、二要素認証）のために、準備した作業が止まっている。 |
submitted_pending_review |
プラットフォームが申請の受領を明示している。審査はまだ残っている。 |
queued |
プラットフォームが、列の中での順番、またはウェイティングリストに入っていることを確認している。 |
scheduled |
プラットフォームが下限以降のローンチ日を確定している。未完了の承認はメモに残す。 |
live |
公開された掲載を確認済みで、審査待ちの表示がない。公開URLと--confirmed-publicが必要。 |
already_listed |
既存の公開された掲載を確認済み。要件はliveと同じ。 |
blocked |
参加資格、アカウントの枠、または必須の事実の不足のために先へ進めない。 |
deferred_paid |
利用できるルートには支払いが必要。何も購入していない。 |
not_a_fit |
プロダクトが対象ユーザーや掲載の基準を満たしていない。 |
unavailable |
そのルートまたはプラットフォームが現在利用できない。問題をメモに残す。 |
最も重要な区別は、下書きと申請済みの違い、そして審査待ちと公開中の違いです。お礼の画面が表示されても、掲載が公開されたことにはなりません。アクセスできるページでも、まだ承認待ちの場合があります。「パートナーにも配信する」のチェックボックスをオンにしても、2つ目のプラットフォームが何かを受け取ったことにはなりません。合計が水増しされないよう、各プラットフォームの結果は独立して扱われます。
スクリプトが適用するルール
- 公開状態には証明が必要。
liveとalready_listedには、確認済みのHTTPSのURLを指定した--public-urlが必要です。クエリ文字列、フラグメント、アカウント・ダッシュボード・ログインのパスは使えません。さらに、あなたが実際にそのページを見たという申告である--confirmed-publicも必要です。 - 予約には日付が必要。
--launch-date YYYY-MM-DDは必須で、product.jsonのearliest_launch_dateより前の日付は指定できません。その理由はローンチ日の下限ガイドで説明しています。 - メモはクリーンに保つ。 メモと次のアクションには、リンク、メールアドレス、
password=のようなキーと値の組、既知のトークンのプレフィックスを含めてはいけません。トラッカーのファイルは共有できることを前提としています。アカウントのURLを含む証跡は、プライベートな保存場所に置いてください。 - 1プラットフォームにつき1行。 そのプラットフォームの行がすでにある場合、
--replaceを渡さない限りコマンドは失敗します。渡すのは、既存の行とプラットフォームの両方を確認してからにしてください。置き換えは常に意図して行うものであり、副作用として起きることはありません。 - シンボリックリンク不可、アトミックな書き込み、ロックファイル。 地味な仕組みですが、2つのエージェントが同時に書き込んでもトラッカーが壊れないのは、これらのおかげです。
重複させずに再開する
次のセッションの冒頭では、どのフォームに触れるよりも先にトラッカーを読んでください。人への引き継ぎと、確認の時期が来た予約済みのローンチを優先し、次に、示された審査期間を過ぎた審査待ちの申請を確認します。プラットフォームが審査期間を示していない場合は、勝手に日付を決めずに、オーナーとフォローアップの日付を取り決めてください。そして、列の順番を上げるために再申請することは絶対にせず、既存の記録を再確認してください。トラッカーが保存するのは現在の状態であって、履歴ではありません。監査証跡が必要な場合は、機密情報を除いたランの要約を別途アーカイブしてください。
実際のプラットフォームでの各状態の具体例は、申請状態についての記事と、以前のガイドである二重カウントせずに申請を追跡する方法を参照してください。用語そのものの定義は掲載ステータスにあります。