发布势能延续

发布之后的第二周悬崖

多数发布的流量尖峰在几天内就会衰减殆尽，团队要么被动看着数据往下掉，要么用毫无章法的二次推送硬撑。@user_2c0f1e77/aaron-momentum-planner 要解决的正是 T+1 到 T+30 这个窗口内的势能延续问题：不是再凑几篇内容，而是把这段时间排成一张发布势能时刻表。

核心能力

它只做一件事：决定某个时刻什么时候发生。具体分四步推进：

• 读取衰减数据。以你自己的发布周基线为参照，而不是套用行业「正常第二周衰减率」——它并不假设任何外部基准。
• 生成 T+1→T+30 时刻表。每个时刻都要分类：milestone（用户、营收、使用量里程碑）、shipped-loop（值得发一条公告的发布）、badge / award（平台徽章、榜单收录、奖项窗口）。纯内容分发位不允许出现在这张表上。
• 判定再发布资格。只有当一个版本带来实质能力、新受众或真实阶段跃迁（beta→GA）时才算新的发布时刻；同一产品重新发帖不算。同时，它会按 major / medium / minor 给 changelog 和 release-notes-as-GTM 分档，默认往小档靠，避免 minor 发布烧掉全渠道注意力。
• 路由流量并预订下一个 Tier-1 时刻。为流量导向自有资产撰写 brief，交给 page-play-builder、content-writer、list-growth-designer 执行；同时检查下一个 Tier-1 候选与上次 Tier-1 的间距，间距过密时以日期形式标记为受众疲劳风险，而不是直接否决。

适用边界

• 它只排时刻。30 天内容复用图和付费放大执行日历归 content-amplifier；完整的下一次发布规划归 launch-tier-planner。
• 它不直接写 memory/launch-registry/，也不写 calendar.md——只通过 registry-events.py 提交候选，launch-registry 是唯一写入方。
• 时刻表上出现的每个指标都必须带 Measured / User-provided / Estimated 标签；公告里的里程碑数字一律视为待举证声明，它会标注 [needs source] 并提交，但不做事实裁定。
• 它不假设下一个发布日做什么内容，也不保证外部渠道（HN 二审池、编辑邀请重发）一定可用——那些是社区经验值，需要自行核实。