LaunchRepo每一次目录站尝试都以一条命令收尾。scripts/record.py 会在产品文件夹的 submissions.json 中为每个平台写入一行当前记录，并拒绝工具包认为缺乏证据或不安全的记录。这种拒绝正是关键所在：有了追踪器，“我们提交了 40 个目录站”才不会变成“我们填了 40 张表，然后听天由命”。本指南介绍各种状态、每种状态需要的证据、命令的参数，以及备注里能写什么、不能写什么。它是 RUNBOOK.md 和脚本自带检查的摘要，不能替代它们。
命令
操作手册中的示例，在工具包目录中运行，且私有项目文件夹已经创建好：
在 Windows 上，请把下面命令中的 python3 换成 py -3（如果你的 Python 3.10+ 命令是 python，就用 python）。把工作区放在私有的本地文件夹中，不要放在 OneDrive 或其他同步文件夹里。对于多行的 shell 示例，在 PowerShell 中请把命令写成一行，并删掉行尾的 \ 字符。
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"两个位置参数（平台 id、状态）和两个必填选项（--note、--next-action）。可选参数有 --public-url、--confirmed-public、--launch-date 和 --replace。平台 id 必须是小写 slug，状态必须是下面十一种之一；只要有一条规则不满足，追踪器就会退出并说明原因。本地仪表盘的记录表单调用的是同一个函数，规则也完全相同。
十一种状态及其最低证据要求
操作手册中的表格，简要如下：
| 状态 | 你必须观察到什么 |
|---|---|
draft |
工作已准备好；最终提交尚未确认。 |
prepared_needs_human |
已准备好的工作被某个明确的所有者操作或验证（CAPTCHA、两步验证）挡住。 |
submitted_pending_review |
平台明确表示已收到提交；仍待审核。 |
queued |
平台确认了队列位置或候补名单状态。 |
scheduled |
平台确认了一个不早于下限的发布日期；尚未完成的审核写在备注中。 |
live |
已核实公开上架页面，且没有待审核标签；需要公开 URL 和 --confirmed-public。 |
already_listed |
已核实一个现有的公开上架页面；要求与 live 相同。 |
blocked |
资格要求、账号容量或缺少必填信息导致无法推进。 |
deferred_paid |
可用的路径需要付费；没有购买任何东西。 |
not_a_fit |
产品不符合目标用户或收录标准。 |
unavailable |
该路径或平台目前无法使用；在备注中说明问题。 |
最重要的区分是草稿与已提交，以及待审核与已上线。出现感谢页面并不代表上架已经生效。一个能访问到的页面，仍可能处于待审核状态。勾选了“同时分发给我们的合作伙伴”，并不意味着第二个平台真的收到了任何东西。每个平台的结果都独立记录，这样总数就永远不会被夸大。
脚本强制执行的规则
- 公开状态需要证明。
live和already_listed需要--public-url，并提供一个经过查看的 HTTPS URL——不带查询字符串、不带片段标识，也不能是账号、后台或登录路径——同时还需要--confirmed-public，即你声明自己亲眼看过这个页面。 - 已排期需要日期。
--launch-date YYYY-MM-DD是必填项，并且不能早于product.json中的earliest_launch_date；原因见发布日期下限指南。 - 备注保持干净。备注和下一步中不能包含链接、邮箱地址、
password=这类键值对或已知的令牌前缀。追踪器文件本来就是可以分享的；带账号 URL 的证据应当放在私有存储中。 - 每个平台一行。如果该平台已有记录，除非你传入
--replace，否则命令会失败——而且要在检查过现有记录和平台本身之后再传。替换必须是有意为之，绝不能是副作用。 - 不跟随符号链接、原子写入、锁文件。这些细节很枯燥，但正是它们保证了两个智能体同时写入时，追踪器不会损坏。
恢复时避免重复
下一次会话开始时，先读追踪器，再碰任何表单。优先处理人工交接和到期需要核实的已排期发布，然后是已超过声明审核周期的待审核提交。如果平台没有给出审核时间，就和所有者商定一个跟进日期，而不是自己编一个。并且绝不要为了在队列中往前排而重新提交：去复查已有的记录。追踪器保存的是当前状态，而不是历史；如果你需要审计记录，请另外归档经过脱敏的运行摘要。
想看这些状态在真实平台上的实例，请阅读提交状态一文，以及较早的那篇避免重复计数的追踪指南；这些状态词汇本身的定义见上架状态。