这一页记两件事：哪天开卖，以及每一次改期是为什么改的。 改过的日期不会被覆盖掉 —— 旧日期和原因都留在这一页上，跳过票的记录也留着。
待补
不是加载失败，是数据本身还不存在：库里没有发售记录，没有发售日期， 也没有任何一条改期记录。所以这一页不会给出任何一个真实日期 —— 编一个出来比空着糟得多。
下面那张表只列目录已上架的波次 —— 前台的目录读取角色只放行 已上架的系列，没上架的那些在这条路径上根本读不到。 所以这张表不是完整的发售路线图，而是「目录放行的那一部分」。「已上架」不等于「已开卖」 —— 这两件事在这个库里真的分开过：曾经有一个 is_active=false 的波次， 它的 6 个角色在店铺侧全都有在售货号。所以这一列写的是前者，不是后者。
下面这张表来自目录库，每一行都是真的。它只有「有没有开卖」这一位 —— 目录库里存的是波次和角色数，没有存日期，所以日期那一列是空的， 而不是被填了个差不多的数。
| 波次 | 角色数 | 状态 | 发售日期 / 改期原因 |
|---|---|---|---|
| Bad Day · Wave 1 | 8 | 目录已上架 | 待补 —— 目录里没有任何一个字段说得出它哪天开的卖，编不出来也不编 |
| Bad Day · Wave 2 | 6 | 目录已上架 | 待补 —— 目录里没有任何一个字段说得出它哪天开的卖，编不出来也不编 |
| Calaveritas · Wave 1 “SKULLS” | 5 | 目录已上架 | 待补 —— 目录里没有任何一个字段说得出它哪天开的卖，编不出来也不编 |
下面两块是格式演示，不是发售计划
里面的名字、日期、原因全部是写死的占位值，对应不到任何一件商品， 也不代表任何将要发生的事。摆在这里只为说清楚这一页要记什么、 以及记漏了会怎么显示。真实排期一到位，这一整块删掉。
示例 A · 开卖之前（占位值）
示例条目 · 不是真实发售
Opens in 3 days, 4 hours, 20 minutes.
示例日期 · Dec 11, 2026 · 10:00 UTC（占位，未定档）
这个倒计时钉死在一个固定参照时刻上，不会走。就算接了真数据它也只到分钟： 不跳秒、不闪、不变红（P5）。而且「几号几点」和剩余时间永远一起出现 —— 相对时间是辅助，日期才是事实，你得能自己安排，而不是守在屏幕前。
示例 B · 改过两次期（占位值）
Dec 11, 2026
Delayed 2 times · 70 days later than first announced (Oct 2, 2026)
1 delay has no published reason. That is a gap in this record, not a formatting choice.
Oct 2, 2026 to Nov 6, 2026 (+35 days)
Why: 示例文案，不是真实原因。真实原因由运营在改期当天写进 delay_reason，W10 规定这一栏不得留空。
Announced Sep 18, 2026
Nov 6, 2026 to Dec 11, 2026 (+35 days)
No reason published for this delay.
第二条延期故意没写原因，为的是让人看见缺口长什么样：它没有被悄悄跳过， 而是被点名成「没有公布理由」。那一行红字就是 W10 买到的东西。
要把上面演示的那两块换成真的，每一次发售得凑齐下面这些。少一样，这一页就少一列， 而不是拿别的凑：
这些字段一天没有，这一页就一天保持现在这个样子：能说的说清楚，说不了的写「待补」。