docs(internal): sync list and watch design notes

Author: liyanbowne

docs/internal/codexm-list-display-design.md

@@ -59,7 +59,7 @@ summary 区不应变成第二张表，也不应展开实现细节或推导过程
 | `ETA` | 预计变为不可用的剩余时间 |
 | `5H USED` | 当前 5 小时窗口使用率 |
 | `1W USED` | 当前 1 周窗口使用率 |
-| `NEXT RESET` | 当前瓶颈窗口的下一次恢复时间 |
+| `NEXT RESET` | 当前账号下一次恢复可用性的关键时间点 |
 
 默认视图不再保留以下列：
 
@@ -209,7 +209,7 @@ Total: bottleneck 0.39 | 5H->1W 0.39 | 1W 0.42 (plus 1W)
 
 ### 5.7 `NEXT RESET`
 
-`NEXT RESET` 只显示当前瓶颈窗口里最关键的那次恢复时间。
+`NEXT RESET` 只显示当前账号下一次恢复可用性的关键时间点。
 
 显示形式：
 
@@ -218,10 +218,17 @@ Total: bottleneck 0.39 | 5H->1W 0.39 | 1W 0.42 (plus 1W)
 
 默认视图不同时展示两个窗口的 reset。
 
+规则：
+
+- 若账号当前已被 `1W` 窗口阻塞，则显示 `1W RESET AT`
+- 若账号当前已被 `5H` 窗口阻塞且 `1W` 未阻塞，则显示 `5H RESET AT`
+- 若 `5H` 和 `1W` 同时阻塞，则显示两者中更晚的那个 reset，因为那才是账号真正恢复可用的时间
+- 若账号当前仍可用，则显示当前更关键约束窗口对应的下一次 reset
+
 设计原因：
 
 - 默认视图里同时放 `5H RESET AT` 和 `1W RESET AT` 会显著加宽表格
-- 用户默认只关心“下一次什么时候会改善当前瓶颈”
+- 用户默认更关心“这个账号什么时候真正恢复可用”，而不是“最早哪个窗口先 reset”
 
 ## 6. 展示格式
 
@@ -236,16 +243,17 @@ Accounts: <x>/<n> usable | blocked: 1W <a>, 5H <b> | plus x<c>, pro x<d>, team x
 规则：
 
 - `usable` 表示当前仍可进入候选集的账号数
-- `1W blocked` 表示 1 周窗口已阻塞的账号数
-- `5H blocked` 表示 5 小时窗口已阻塞但 1 周窗口未阻塞的账号数
-- `plans` 表示按 plan 聚合后的账号数分布
+- `blocked: 1W <a>, 5H <b>` 表示阻塞账号按主阻塞窗口拆分后的计数
+- 其中 `1W` 表示 1 周窗口已阻塞的账号数
+- 其中 `5H` 表示 5 小时窗口已阻塞但 1 周窗口未阻塞的账号数
+- 末尾 plan 段表示按 plan 聚合后的账号数分布
 
 如果某个 plan 的账号数为 0，则不出现在 `plans` 段里。
 
 设计原因：
 
-- `usable` / `1W blocked` / `5H blocked` 是默认 summary 中最有决策价值的池子级信号
-- `plans` 能快速帮助用户理解账号池结构
+- `usable` 和 `blocked` 拆解是默认 summary 中最有决策价值的池子级信号
+- plan 分布能快速帮助用户理解账号池结构
 
 ### 6.1 Total 行格式
 

docs/internal/design-history/2026-04-10-codexm-watch-eta-design.md

@@ -147,28 +147,38 @@ eta = remaining_budget / global_rate_in_1w_units_per_hour
 也就是说：
 
 - `1W` 先按 plan 的周额度 profile 归一化
-- `5H` 先按 plan 的 `5H` 容量 profile 归一化，再换算成 `plus 1W` 单位
+- `5H` 先按同一 plan 的原始 `5H:1W` 比例折算到 `1W`，再换算成 `plus 1W` 单位
 
 实现上集中维护一张 plan profile 表：
 
-| plan | `5H` 容量（plus=1） | `1W` 容量（plus=1） |
+| plan | 原始 `5H:1W` 比例 | `1W` 容量（plus=1） |
 | --- | ---: | ---: |
-| `plus` | 1 | 1 |
-| `prolite` | 5 | 25/6 |
-| `pro` | 10 | 25/3 |
-| `team` | 1 | 1 |
-| `unknown` | 1 | 1 |
+| `plus` | `20/3` | `1` |
+| `prolite` | `50/9` | `25/6` |
+| `pro` | `50/9` | `25/3` |
+| `team` | `20/3` | `1` |
+| `unknown` | `20/3` | `1` |
 
 换算规则：
 
 ```text
 five_hour_equivalent_in_plus_weekly_units =
-  five_hour_percent * plan.five_hour_capacity_in_plus_units / 8
+  (five_hour_percent / plan.five_hour_to_one_week_raw_ratio) *
+  plan.one_week_capacity_in_plus_units
 
 one_week_equivalent_in_plus_weekly_units =
   one_week_percent * plan.one_week_capacity_in_plus_units
 ```
 
+这里不再假设“一周固定包含多少个 5H 窗口”。
+
+实现直接使用每个 plan 的经验原始比例：
+
+- `plus/team` 按 `3:20`
+- `pro/prolite` 按 `9:50`
+
+这样可以把“同一 plan 内的 `5H:1W` 关系”和“不同 plan 间的周额度容量比”分开表达，避免把两层语义混在单一窗口数假设里。
+
 全局速率定义为：
 
 ```text