设计产品抢先体验计划：从 waitlist 到 GA…

当需要为产品设计从 waitlist 到正式发布（GA）的抢先体验流程时，用它定义阶段阶梯、毕业标准、邀请节流、测试者招募与反馈/推荐机制。

适用场景

解决思路

1. 确认产品、当前阶段、受众和发布目标；若 memory/launch-registry/ 中已有阶段记录则拉取，设计必须扩展而非与之矛盾；从导出数据（Measured）或用户（User-provided）获取当前 waitlist 规模和测试者数量，不要凭空编造基线。
2. 设计阶段阶梯：waitlist → concept → alpha → beta → GA，waitlist 一级在 launch-registry 的规范阶段枚举中记为 draft（可折叠产品不需要的阶段，并说明折叠哪些及原因）；为每个阶段给出目的（回答什么问题）、进入动作和访问范围；应用状态机模式：注册与 opt-in 是同一动作的不同阶段，显式 opt-in/opt-out 覆盖一切定向规则，GA 发布步骤必须明确声明此前 opt-out 的用户是否被纳入，作为显式确认而非静默默认。
3. 为每个阶段设定毕业标准：可量化、可核查，包括核心流程完成率、已审阅的结构化反馈条数、错误容忍度对比产品自身的历史比率；每个阈值在用户自有数据验证前都标注为 Estimated，绝不将其呈现为行业基准。
4. 规划队列门控与邀请节流：两种可行模式——按波次分批邀请约 waitlist 的 5-10%，波次之间留观察窗口（规模为 Estimated，按产品支持能力调整）；或全量邀请但重新定义预期（将发布标注为预览，而非 beta 毕业）；为本产品推荐一种并说明理由。
5. 规划测试者招募与发布日社会证明：测试者来源（waitlist、社区、现有用户）、他们同意的事项（反馈节奏、是否保密）、以及哪些测试者将用于发布日的引述和推荐语；社会证明须合规：不得激励应用商店评价，激励仅限平台自身政策允许的渠道；将收割动作交给 launch-feedback-synthesizer。
6. 编写反馈闭环规范：收集渠道、分诊节奏、状态分类（如 open → planned → shipped / declined），以及规则——每次状态变更都通知其订阅者/提出者；这能闭合让测试者持续反馈的回路，也是发布后 launch-feedback-synthesizer 将运营的闭环。
7. 编写推荐循环机制规范：邀请码或链接、被推荐注册的归因、防滥用防护（每账号邀请上限、一次性邮箱筛查、撤销路径）；仅限机制：循环的经济性（K-factor、激励发放）委托给 newsletter-monetization-planner；推荐或邀请文案中的任何产品声明标注 [needs source] 并通过授权 operation: propose 请求 registry-events.py 路由到 memory/events/claims.ndjson——本技能不裁决声明。
8. 将阶段定义提交给注册表：阶段名称、进入/退出标准、目标日期、GA opt-out 纳入决策，通过授权 operation: propose 请求 registry-events.py 写入 memory/events/launches.ndjson，由 launch-registry 正式化为 RAMP-R1 阶段真实性检查读取的规范记录；本技能绝不直接写规范记录。

适用边界 · 注意事项

• 不负责 waitlist 获客策略或合规的捕获流程规范（应使用 list-growth-designer）。
• 不负责构建注册页/弹窗 UX（应使用 landing-optimizer），也不负责记录 opt-in（consent-registry 是 memory/consent/ 的唯一写入者）。
• 不负责推荐经济性建模（K-factor、发放，应使用 newsletter-monetization-planner），也不持有规范阶段记录（launch-registry 是 memory/launch-registry/ 的唯一写入者）。