diff --git a/docs/done/live-channel-v1.md b/docs/done/live-channel-v1.md
index 5eb5049..ee6b174 100644
--- a/docs/done/live-channel-v1.md
+++ b/docs/done/live-channel-v1.md
@@ -36,9 +36,11 @@
   审核）→ 通过后 `submitPromptToQueue`：
   - 命中素材库（中/英文 prompt 精确或子串匹配）→ 直接进入待播队列
     （`status: matched`）。
-  - 未命中 → 调用 H3 Console `POST /v1/videos`（文生视频，832x480/120帧/
-    20步）异步生成，`status: generating`，生成完成后自动写入
-    `library.json` 并推入待播队列（`status: ready`）。
+  - 未命中 → 调用 H3 Console `POST /v1/videos`（文生视频，480x832 竖屏/
+    120帧/20步——第一期默认横屏 832x480，后改为竖屏移动端优先，见
+    commit `1dc7084`）异步生成，`status: generating`，生成完成后自动
+    写入 `library.json` 并推入待播队列（`status: ready`）。存量片段
+    保留生成时的原比例，播放器 `object-fit: contain` 兼容混合比例。
 - 生成是完全后台化的（H3 自建集群单次约 200s），绝不阻塞直播时刻表或
   HTTP 响应。
 - `POST /api/prompt` 是同一条提交路径的非聊天版本（供测试/直接调用）。
@@ -113,7 +115,7 @@
   "promptEn": "...",              // 可选，英文短 prompt
   "fullPrompt": "...",            // 完整生成 prompt（H3 结构化 prompt 或用户原话）
   "videoUrl": "...",              // 可选，外部视频地址（manual 或后台改过播放源）
-  "width": 832, "height": 480,
+  "width": 480, "height": 832,     // 当前默认竖屏；早期/存量片段可能是 832x480 横屏
   "duration": 5,                  // 秒
   "partition": "text",            // text | ref2va | fl2va | manual
   "likes": 0,
diff --git a/docs/structure/architecture.md b/docs/structure/architecture.md
index 8e756a9..6d16c6d 100644
--- a/docs/structure/architecture.md
+++ b/docs/structure/architecture.md
@@ -195,14 +195,15 @@ v2 必须挪到服务端 `.env`，不能再让 key 走浏览器。
 前第一步就是用真实调用验证这条路径，而不是假设它一定按预期工作
 （`docs/todo` 第 8.2 条）。
 
-### 2.4 视频规格：默认竖屏，移动端优先（仅 `dance.html`）
-
-`dance.html` 的生成请求默认用 **480×832**（`live.html` 现有默认
-832×480 的宽高对调），总像素量与现状完全一致，理论上不会拖慢 H3
-Console/fal.ai 的生成耗时（`docs/todo` 4.4 节）。`live.html` 现有横屏
-内容/默认值不变，两个直播间的规格是独立配置，不共享同一份
-`H3_GEN_PARAMS`。播放器 UI 上，`dance.html` 需要一套按 9:16 设计的
-播放器容器，不能直接复用 `live.html` 现有横屏播放器的宽高比。
+### 2.4 视频规格：默认竖屏，移动端优先
+
+`dance.html` 的生成请求默认用 **480×832**（早期横屏默认 832×480 的
+宽高对调），总像素量与现状完全一致，理论上不会拖慢 H3 Console/fal.ai
+的生成耗时（`docs/todo` 4.4 节）。两个直播间的规格是各自独立的
+`H3_GEN_PARAMS` 配置，互不共享——`live.html` 一侧后来也独立改成了
+竖屏默认（`docs/done` 2.2 节），只是刚好两边选型一致，不是同一份配置
+联动的结果。播放器 UI 上，`dance.html` 需要一套按 9:16 设计的播放器
+容器，不能直接复用 `live.html` 现有播放器的宽高比假设。
 
 ### 2.5 与现状的集成点
 
diff --git a/docs/todo/dressup-dance-room-mvcp.md b/docs/todo/dressup-dance-room-mvcp.md
index e67b34a..94ae1d7 100644
--- a/docs/todo/dressup-dance-room-mvcp.md
+++ b/docs/todo/dressup-dance-room-mvcp.md
@@ -116,7 +116,7 @@
 | `backend` | enum | `h3_console` \| `fal`（4.3 节双算力策略，记录这条具体是哪条算力路径生成的，便于追溯成本） |
 | `priority` | enum | `normal` \| `paid_boost`（`paid_boost` = 付费新人物内容，排播时走 2.6 节"插队"通道，不参与投票） |
 | `requestedByUserId` | string \| null | 付费请求必填，免费匿名请求为 null（用 `legacyUid` 兜底） |
-| `width`/`height` | number | `dance` 频道默认 480×832，`live` 频道现状默认已同步改为 480×832（见文末"勘误"一节） |
+| `width`/`height` | number | `dance` 频道默认 480×832；`live` 频道走独立的 `H3_GEN_PARAMS`，目前也是 480×832（`docs/done` 2.2 节），两者不共享同一份配置 |
 
 ### M.8 直播时刻表状态（非持久化数据库表，`live-state.json` 风格的内存+落盘结构，`dance.html` 独立一份）
 
@@ -400,20 +400,3 @@ sequenceDiagram
 3. **人物到期检测**：每次消费完 `priorityInbox` 里某人物的一段后，
    `remainingSegments -= 1`，归零则置 `characters.status = expired`
    并从后续排播候选中过滤掉（架构文档 2.7节）。
-
----
-
-## 勘误：`live.html` 分辨率现状更新
-
-写这份需求文档时（`docs/todo/dressup-dance-room.md` 4.4节）记录的是
-"`live.html` 现状横屏 832×480 不变，只有 `dance.html` 默认竖屏"。但
-`server.js` 的 `H3_GEN_PARAMS` 在另一次改动中已经被改成
-`{ width: 480, height: 832 }`（commit `1dc7084`，`live.html` 侧的
-说明是"未来生成的新片段走竖屏，存量片段保留原比例，播放器
-`object-fit: contain` 兼容混合比例"）——也就是说 **`live.html` 现在
-新生成的内容其实也已经是竖屏了**，只是存量片段还是横屏混着播。
-
-`dance.html` 侧的设计不受影响（本来就是独立的 `H3_GEN_PARAMS` 配置，
-见架构文档 2.4节），但需求文档 2/4.4节"live.html 现状横屏不变"这句
-描述已经不准确，建议后续同步一次勘误（不在本次技术设计文档范围内，
-先在此记录，避免依赖这份文档的人被误导）。
diff --git a/docs/todo/dressup-dance-room.md b/docs/todo/dressup-dance-room.md
index 71079a5..2bf594d 100644
--- a/docs/todo/dressup-dance-room.md
+++ b/docs/todo/dressup-dance-room.md
@@ -27,9 +27,8 @@
   不是同一个直播间的两个 tab——它们是两条并行的产品线，共用后端的
   素材库/生成流水线/账号体系等基础设施。
 - **`dance.html` 默认竖屏、移动端优先**——具体规格见第 4.4 节。
-  （勘误：`live.html` 一侧此后也已独立改成竖屏默认，见 4.4 节末尾说明，
-  两个频道各自的 `H3_GEN_PARAMS` 配置互不影响，只是当时判断的"横屏不变"
-  前提已经过时。）
+  `live.html` 一侧此后也独立改成了竖屏默认（`docs/done` 2.2 节），两个
+  频道各自维护自己的 `H3_GEN_PARAMS`，互不影响、互不依赖对方的改动。
 
 ## 3. 观众体验流程（已确认：使用已有资产库免费，新增资产付费）
 
@@ -110,14 +109,16 @@
 Stage1（换装图合成）在两条路径下大概率都是 fal.ai（H3 Console 不产图），
 只有 Stage2（视频生成）真正分叉成两条算力。
 
-### 4.4 视频规格：默认竖屏，移动端优先（已确认，仅 `dance.html`）
+### 4.4 视频规格：默认竖屏，移动端优先（已确认）
 
-- `dance.html` 生成的视频**默认竖屏**（`live.html` 现有横屏内容不受影响，
-  两个直播间各自独立的规格，见第 2 节）。
-- **默认分辨率 480×832**——现有 `server.js` 里 `H3_GEN_PARAMS` 的横屏
-  默认是 832×480（总像素量 ≈ 40 万），480×832 只是宽高对调，总像素量
-  完全不变，理论上不会因为改成竖屏而拖慢生成耗时（H3 集群单条本来就
-  约 200s，见 `H3-CONSOLE.md`，竖屏化不能再让这个数字变得更差）。
+- `dance.html` 生成的视频**默认竖屏**，与 `live.html` 各自维护独立的
+  `H3_GEN_PARAMS` 配置（第 2 节）——`live.html` 一侧后来也独立改成了
+  竖屏默认（`docs/done` 2.2 节），两边不是同一份配置，只是刚好选型
+  一致。
+- **默认分辨率 480×832**——总像素量 ≈ 40 万，与早期横屏默认 832×480
+  完全一致（只是宽高对调），理论上不会因为竖屏化而拖慢生成耗时（H3
+  集群单条本来就约 200s，见 `H3-CONSOLE.md`，竖屏化不能再让这个数字
+  变得更差）。
 - 更高分辨率（576×1024/720×1280 等）画质更好，但会明显增加生成耗时，
   **不作为默认**，可以作为后续付费选项预留（呼应第 7.2 节"新增资产才
   消耗积分"的思路——高清可以是另一档付费能力，不是本期范围，先不做）。
@@ -126,13 +127,6 @@ Stage1（换装图合成）在两条路径下大概率都是 fal.ai（H3 Console
   `live.html` 现有横屏播放器的宽高比，否则会出现大黑边——这是
   `dance.html` 相对 `live.html` 除了"没有文字输入框"之外的第二个视觉
   差异点。
-- **勘误**：`server.js` 的 `H3_GEN_PARAMS`（`live.html` 使用的那份）
-  之后被单独改成了 `480×832`（commit `1dc7084`），也就是说 `live.html`
-  新生成的内容现在其实也是竖屏了，存量片段仍是原比例混播（播放器靠
-  `object-fit: contain` 兼容）。这是 `live.html` 那条独立产品线自己的
-  改动，跟 `dance.html` 的配置互不影响，但上面"仅 `dance.html`"的表述
-  已不完全准确，记录于此，详见 `docs/todo/dressup-dance-room-mvcp.md`
-  文末"勘误"一节。
 
 ### 4.5 失败/超时处理