dev-plan-6.md
26.9 KB
换装跳舞直播间 — 第六期开发任务规划（对标 PixVerse "Live Dress"）
需求来源：参考产品 PixVerse world.pixverse.video/live/dress 的抓包/反混淆分析，
详见 docs/reference/pixverse-dress-live/NOTES.md（下称"参考分析"，本文各处
引用其章节标题）。现状代码：dance.html/dance.css（换装跳舞直播间，下称
"我们"）、live.html/live.css（AI 短剧频道，样式基底被 dance.html 复用）。
产品需求见 docs/todo/dressup-dance-room.md（"需求文档"），技术设计见
docs/todo/dressup-dance-room-mvcp.md（MVCP）。第一~五期（T1-T39）均已完成
并提交。任务编号接着往下编。
工时是粗估，单位人天，用来排先后不用来考核。
0. 第六期范围（2026-09-17 已与你过一遍 §2 开放问题，范围已锁定）
做：排队可视化（顶部"正在换装"胶囊 + 排队头像条，T40）、换装选择 面板改版为底部横条 + hover 发送态（T41/T42）、把"传衣服/传人"付费 上传入口合并进这个面板（T42，原来是左栏独立 tab）、上传进度条体验 优化（T44）、聊天弹幕接入 dance room（T46，新增正式任务）、同一 uid 未完成条目时禁止重复免费选衣服的轻量限流（T48，新增）。
不做：不接入 Agora／声网，我们的"直播"本质是服务端预渲染视频片段
按时刻表轮播（M.8），不是真正的实时推流，参考分析里"Agora 数据通道推
事件"那套换成我们已有的轮询（pollState/新增的聊天轮询）语义对齐即
可，不需要引入新的实时通道；不做 PixVerse 的分享海报生成（已确认排
除）；不把投票排序机制换成 PixVerse 那种"FIFO 单请求"（已确认保留投
票机制，只加轻量限流，见 T48）；不改动登录/积分/审核这套商业化规则
本身（T42 只是挪上传入口的位置，付费门槛/积分换算逻辑不变）；不
做整体深色视觉基调重做（已确认保留漫画风，见 §2 决策 1）。
1. 对照表：PixVerse Live Dress vs 我们的 dance.html
| 维度 | PixVerse 参考实现（见参考分析对应章节） | 我们现状（dance.html/dance.css） |
差距结论 |
|---|---|---|---|
| 整体视觉基调 | 深色沉浸式，接近 Instagram/TikTok Stories：无边框卡片、圆角胶囊、毛玻璃蒙层、纯白/浅灰文字 | "漫画风"：白底卡片+3px 黑色描边+硬offset阴影、马卡龙撞色（--accent:#ff90e8）、Tahoma 粗体、Logo 描边+多层投影 |
根本性的风格冲突，不是改几个颜色变量能解决的，是否要整体换肤是最大的开放问题（§1.2 问题 1） |
| 页面布局 | 单栏居中竖版视频铺满可视区，左下弹幕/顶部信息/底部换装条都是悬浮在视频上的浮层，没有常驻侧栏 | 三栏布局：左列表栏（320px 常驻）/中间视频/右选衣服栏（320px 常驻），侧栏挤占视频可视宽度 | 差距大，但改动风险也大——会影响 live.html 共用的 .left-col/.right-col（§1.1 决策已限定只改 dance 独有部分，不动 live.html 布局） |
| "正在为谁换装" | 顶部居中「Now Active \ | @user」胶囊 + 头像，视觉焦点强 | now-playing-box 固定在视频左上角，纯文字（昵称+时间），无头像、不居中、不醒目 |
| 排队可视化 | 顶部一排头像气泡 + 每个头像旁一个迷你换装缩略图角标，直观看到"谁在排队、submit 了什么" | 左栏"待播放" tab 用卡片列表（服装缩略图+文字），无头像，纯列表滚动 | 值得抄头像+角标的横条形式（T40），但我们没有用户头像系统（只有昵称 cookie），需要决定用什么占位图（§1.2 问题 2） |
| 换装选择面板 | 底部横向缩略图条，默认收起成一行，hover 缩略图淡入黑色蒙层+居中"Send"按钮；旁边有"DIY"上传入口内联在同一条里 | 右侧栏网格（.wardrobe-grid，2 列），点击卡片直接提交，无 hover 二次确认；自定义上传是独立付费 tab（传衣服/传人），不在选衣服面板里 |
已确认合并（见 §2 决策 2）：面板改版为横条+hover 发送态（T41/T42），"传衣服/传人"付费上传入口挪进同一个面板，做成一张常驻的"DIY"卡片，付费门槛/积分逻辑不变，只改入口位置 |
| 每用户并发请求数 | 严格限制：每个用户同时只能有 1 条排队中的换装请求（queuePosition===-1 才能发送），FIFO 处理，可主动取消 |
无限制：一个 uid 可以多次 pick，进入队列后靠"点赞"（up-btn）加速排序，是投票模型不是 FIFO |
已确认不改成 FIFO（见 §2 决策 4），保留投票机制；改加一条轻量限流——同一 uid 已有未完成的免费排队条目时禁止再次 pick（T48），付费上传（衣服/人物）不受这条限流影响 |
| 聊天/弹幕 | 左下角持续聊天流（历史+实时），另有独立的"prompt-send"飘字特效叠加在视频上 | dance.html 完全没有聊天——live.html 有聊天面板和后端（/api/chat），但 dance room 从未接入；右栏被"选衣服"占用 |
已确认要做（见 §2 决策 3）：接入 dance room 专属聊天（T46），不做"prompt-send"飘字特效（超出本期范围，仅做常规聊天流） |
| 分享 | 右上角分享按钮 → 竖版海报预览 + Instagram/TikTok/X/Facebook/复制链接 | 无 | 已确认不做（见 §2 决策 3），维持候选任务 T47，未排入本期 |
| 观看人数 | Agora 数据通道实时推送 user-num-change |
/api/dance/live/state 4s 轮询里的 watching 字段，展示上都是"👀 数字"，机制不同但效果对用户来说等价 |
无需改动，轮询频率够用，不是真人数敏感场景 |
| 首次自动播放音频拦截 | 小弹窗「Play live audio? / Keep muted / Play sound」，不挡住画面 | 全屏点击进入蒙层（.splash），挡住画面直到点击 |
我们的方案信息量更大（品牌介绍+免责声明可以一起放），不建议改成小弹窗，全屏蒙层同时也是 5.1 节年龄确认的载体，改小会削弱年龄提示的存在感 |
| 会话健康状态机 | connecting/playing/block/end/error 五态，Agora 事件+轮询双保险防黑屏 |
只有 player 的 error 事件监听，出错直接跳下一条 |
场景本质不同（预渲染轮播 vs 实时推流），黑屏风险类型不一样，不建议照搬整套状态机，现有的"出错跳下一条"已经是对的兜底策略 |
| 上传进度体验 | 伪进度（按文件大小估算时长的缓动动画）+ 真实分片上传进度混合，防止大图卡在 0%/不动 | submitGarmentUpload/submitCharacterUpload 只有"上传中…"文案，没有进度条 |
值得抄（T44），小改动、体验提升明显 |
| 内容审核错误文案 | 区分"明确拒绝"（UPLOAD_AUDIT_REJECTED）vs"审核服务不可用"（UPLOAD_AUDIT_FAILED）两种提示 |
moderateGarmentImage/moderateFaceBlacklist 目前是占位实现（无供应商时 auto_pass），还没有真正的"拒绝"分支需要文案 |
低优先级——等 T26/T32 真正接入审核供应商时再一并做文案区分（T45，标记为"供应商就绪后执行"） |
| 底层通信机制 | REST 建会话（一次性）+ Agora 数据通道推送所有实时事件，客户端动作走统一 POST /live/room/message |
纯 HTTP 轮询：pollState 4s 一次全量拉取 /api/dance/live/state |
不建议改——我们的场景更新频率低（片段级切换，不是逐帧），轮询足够且实现简单，引入 WebSocket/SSE 收益不成比例（不在本期任务里） |
2. 已确认的决策（2026-09-17）
| # | 问题 | 决策 | 落地方式 |
|---|---|---|---|
| 1 | 要不要放弃"漫画风"整体换成 PixVerse 深色极简风？ | 不换，保留漫画风视觉基调 | T40-T42 只改 dance.html 独有部分的布局/交互形式（排队头像条、底部换装横条、hover 发送态），继续用现有白底黑边硬阴影+马卡龙撞色的视觉语言重做，不做像素级抄样式；live.html/live.css 共享部分不受影响 |
| 2 | 排队头像用什么占位？要不要把上传入口合并进选衣服面板？ | 头像用哈希色块；上传入口合并进选衣服面板 | 头像：复用 live.html 已有的 pastel(name) 取色函数（首字+哈希色块），不新增头像存储。上传：原来左栏独立的"传衣服"/"传人" tab 撤掉，改成新换装横条里一张常驻的"DIY"卡片（同 PixVerse 截图里 DIY 卡片的位置感，样式走漫画风），点开后二级选择"传衣服"还是"传人"，分别复用现有 submitGarmentUpload/submitCharacterUpload 的付费逻辑（登录+邮箱验证+扣积分规则完全不变）——"传人"点开后仍然会跳转新房间（location.href = dance.html?characterId=...），这点和"传衣服"（原地生成、留在当前房间）行为不同，DIY 卡片的二级选择要把这个差异讲清楚（比如文案"上传衣服给 TA 穿" vs "上传新角色，开一个新直播间"），不能直接照抄 PixVerse 单一 DIY 入口的样子，否则用户点了"传人"突然跳走会觉得莫名其妙 |
| 3 | 要不要做聊天弹幕、要不要做分享海报？ | 做聊天弹幕（T46），不做分享海报 | 聊天弹幕正式排入本期任务表；分享海报维持候选 T47，本期不排期 |
| 4 | 要不要把"投票排序"换成"每人限一条+FIFO"？ | 不改机制，加一条轻量限流 | 保留投票排序；新增 T48：同一 uid 已有未完成的免费排队条目（pick 产生的 queue 记录，状态非 done/failed）时，再次调用 /api/dance/pick 直接拒绝并提示"你已经有一件衣服在排队了"；付费上传（衣服/人物）不受此限流——已经有积分门槛天然限流，且强行限制会打击"想连续买两个人物片段"这类合理的付费场景 |
3. 依赖关系
graph LR
T40[T40 顶部换装胶囊+排队头像条] --> T42[T42 底部换装横条改版+合并上传入口]
T41[T41 换装卡片 hover 发送态组件] --> T42
T42 --> T43[T43 移动端适配换装横条]
T42 --> T46[T46 聊天弹幕接入 dance room]
T44[T44 上传进度条体验优化]
T48[T48 同 uid 免费排队轻量限流]
T45[T45 审核错误文案区分 · 占位，待供应商接入]
classDef ready fill:#d4f7d4;
class T40,T41,T44,T48 ready
T40/T41/T44/T48 互不依赖，可以完全并行开工；T42 依赖 T40（复用同一套
"当前换装状态"数据结构）和 T41（复用卡片组件），是本期工作量最大的
一项（面板改版+合并上传入口两件事揉在一起）；T43 是 T42 的收尾（移动
端场景下横条要收起成可横滑的一行）；T46 依赖 T42——聊天面板要挂载到
T42 改版后腾出来的右侧栏空间（选衣服从右侧网格变成底部横条后，原
.right-col 空出来，正好给聊天用，不用另外抢布局空间）；T45 依赖
T26/T32 真正接入审核供应商（当前仍是占位实现，日期未定，先记录任务不
排进本期工时）。
4. 任务表
| # | 任务 | 依赖 | 验收标准 | 工时(人天) |
|---|---|---|---|---|
| T40 ✅ | [已完成 2026-09-17] 顶部"正在换装"胶囊 + 排队头像条：把 now-playing-box 改造成居中胶囊形式（🔥 正在换装 · 昵称），沿用漫画风视觉；胶囊下方新增横向排队条，渲染 state.queue 里 status:"generating" 的条目，每项一个昵称首字哈希色块头像 + 迷你服装缩略图角标。实现笔记：没有单独提取共享 .js——现有代码里 live.html/dance.html 本来就大量各自复制小工具函数（escapeHtml/getCookie/ensureIdentity…），是这个项目一直以来的既有约定，只为一个 4 行的 pastel() 函数新起一个共享文件与现状不一致，所以按老样子在 dance.html 里复制了一份，没有改 live.html。原 now-playing-box 的昵称/时间显示拿掉了（昵称并入新胶囊，时间字段 np-time/fmtClock 直接删除——只是切换时刻的时钟展示，没人在用，删了比留着"隐藏但没用"的字段干净），now-playing-box 现在只剩点赞按钮。已用真实房间数据（角色 35b3de40-…）在浏览器里验证胶囊+头像条+T48 的排队禁用态同时正确渲染；node --test *.test.js 141 个测试全绿 |
无 | 有人正在被换装时，视频上方居中显示昵称胶囊；排队条按 queue 数组顺序渲染，每人一个色块头像+缩略图角标；队列为空时横条不占位（hidden）；移动端窄屏下横条可横向滚动不换行（CSS 层面用标准 overflow-x:auto 实现，未做设备级实测，见下方备注） |
1.5 |
| T41 ✅ | [已完成 2026-09-18] 换装卡片 hover"发送"态组件：.wardrobe-card 增加 hover（桌面）/点一下展开+再点确认（移动端）两种交互形态，悬浮/展开时叠一层半透明黑色蒙层+居中"发送"按钮，点击才真正提交，避免像现状一样"点一下就直接提交，容易误触"。实现笔记：用 matchMedia("(hover: hover)") 一次性判断主指针是否真的支持 hover 来分流两套交互（而不是猜 UA/触屏），桌面纯 CSS :hover 驱动，移动端才挂 JS 点击展开逻辑；pickGarment 本体不变，只是触发点从"卡片 click"搬到"发送按钮 click"。真机验证：浏览器自动化的合成 hover 事件不会真正置位 CSS :hover（工具本身的限制，不是代码问题），改用直接点"发送"按钮验证了完整链路（真的打到 POST /api/dance/pick，200），.revealed 展开态的 CSS 路径也单独验证过。已知小限制：移动端展开态是纯前端瞬时 class，4s 一次的 pollState() 整块重渲染会把展开态冲掉——这是现有轮询+整块 innerHTML 重绘架构的通用代价，不是本任务单独引入的问题，代码里留了注释说明 |
无 | 桌面端 hover 卡片才出现"发送"按钮，不 hover 只看到图+名字；移动端用点击展开"发送"按钮再二次点击提交的两段式交互；pickGarment 的实际提交逻辑不变，只是触发时机从"卡片 click"改成"发送按钮 click" |
1 |
| T42 ✅ | [已完成 2026-09-18] 右侧"选衣服"面板 → 底部横条改版 + 合并上传入口：把 pickPanel（现状是右侧栏 2 列网格）在桌面端改造成贴视频底部的横向可滚动一行（复用 T41 的卡片组件），右侧栏收窄/腾出来给 T46 聊天用；横条末尾新增一张常驻"DIY"卡片（虚线描边+上传图标，漫画风样式），点击展开一个二级选择：「传衣服给 TA 穿」（原地生成，复用 submitGarmentUpload，成功后留在当前房间）/「传新角色开新直播间」（复用 submitCharacterUpload，成功后仍然 location.href 跳转新房间，跳转行为不变，只是入口从左栏 tab 挪到这里，文案要明确写出"会离开当前房间"）；左栏 wardrobeTabs 撤掉"传衣服"/"传人"两个 tab，只保留"待播放"（不再需要 tab 切换 UI，leftTab 状态机简化为常量）。实现笔记：DIY 二选一弹窗+上传表单复用 .nickname-modal/.nickname-box 壳子，测试时发现两个真实 bug 并已修：① 上传表单原来住在深色左栏，.upload-panel .hint/.diy-choice-hint 用的是给深色底配的 var(--muted)（半透明白），搬进白色弹窗后几乎看不清，改成深色低透明度；② 未登录点上传会弹 authModal，但它和新加的 diyModal z-index 相同、diyModal 在 DOM 里更靠后，会不受控制地盖住登录框——已在 openAuthModal() 里加一行 diyModal.hidden = true 兜底关掉。live.html/live.css 零改动（git diff --stat 确认），浏览器手工过了一遍确认无回归 |
T40, T41 | 桌面端选衣服区域变成贴视频底部的横向条，可横向滚动查看全部衣柜；"生成中"/"生成失败"两个子区仍在横条内可见；末尾 DIY 卡片点开后能二选一走完整套现有付费上传流程（登录门槛/邮箱验证门槛/积分扣费/退款逻辑完全不变，只是换了入口位置）；点"传新角色"前有明显提示会离开当前房间；左栏只剩"待播放"列表，不再有 tab 按钮；live.html 页面布局和样式不受影响（回归检查：live.html 手工过一遍） |
3 |
| T43 ✅ | [已完成 2026-09-18] 移动端适配换装横条：现状 .mobile-subtabs 在移动端用"待播放/选衣服"两个 tab 切换左右栏；T42 把选衣服面板改成横条后，需要重新设计移动端下这条横条跟"待播放"列表、聊天（T46）三者的切换/共存方式。实现笔记：resize_window 工具在这个环境里对已存在的 MCP 标签页不生效，改用"在当前标签页里插一个 390×844 的真 iframe 指向同一个 URL"的办法拿到货真价实的窄视口渲染（iframe 有自己独立的 layout viewport，@media/vh 都是真的，比硬凑一段 CSS 去猜靠谱）。测出并修了两个真 bug，都不是"锦上添花"而是"挤到不可用"：① .channel{height:100vh} 是硬高度、不是页面可滚的高度上限，T13 遗留的 .player-wrap{width:100%}（宽度驱动 9:16，窄屏下约等于满屏高）+ T42 新增的横条，两个加起来直接把"待播放"压成 24px 一条缝——根因是 .player-wrap 还带着 live.css 基础规则的 flex:1，会无视后面写的 height 去抢 .player-col 的剩余空间；移动端改回"由高度定宽度"（flex:none; height:40vh）后视频让出空间，"待播放"能完整露出不用再内部滚动。② 视频变窄之后，居中的"直播中"胶囊和左上角点赞按钮撞在一起——点赞按钮移动端挪到视频左下角，与顶部几个胶囊错开；这条只影响 dance.html（live.html 的视频从来不限宽，不受影响，也没有改 live.css）。另外把横条卡片调小、去掉横条自己的竖向滚动上限（避免在已经要整页滚的手机页面上再嵌一层内部滚动区域）、给 DIY 弹窗加了窄屏 max-width 兜底。用上述 iframe 方法反复截图验证到视频/横条/"待播放"三块无重叠、无裁切 |
T42 | 移动端（max-width:768px）下选衣服横条可用，不跟视频/待播放列表/聊天重叠或挤压到不可用的程度；触摸横滑流畅 |
1 |
| T44 ✅ | [已完成 2026-09-18] 上传进度条体验优化：submitGarmentUpload/submitCharacterUpload 增加进度条 UI，参照参考分析 §3 的"伪进度+真进度混合"思路——按文件大小估算一个基准时长，setInterval 缓动推进到 ~88%，改用 XMLHttpRequest（fetch 的 FormData 上传拿不到进度事件）的 upload.onprogress 拿真实进度覆盖，完成后跳 100% 再消失；小文件也有 500ms 最短可见时长，不会一闪而过。实现笔记：写成两个共享小工具（uploadWithProgress 包一层 XHR 成 Promise、createUploadProgress 管进度条状态机），两个上传表单各自只多传一个 progressBar 元素，业务逻辑（登录/邮箱验证门槛、错误分支、成功后跳转/刷新）完全没动。浏览器里手动驱动过 createUploadProgress（大文件模拟到 88% 封顶、finish() 正确跳 100% 再隐藏、小文件也有最短停留时间）——真实登录态下的端到端上传没条件测（没有已登录+已验证邮箱的测试账号），但这条改动完全不碰鉴权/积分/生成那些已有逻辑，风险低 |
无 | 上传大图（≥3MB）时进度条平滑增长不卡在 0%；上传完成后进度条走到 100% 再消失；小图（ | 1 |
| T45 | 审核错误文案区分（占位，依赖 T26/T32 真正接入审核供应商后再排期）：moderateGarmentImage/moderateFaceBlacklist 接入真实供应商、有了"明确拒绝"返回值之后，前端区分"内容不合规，请换一张"（verdict: rejected）和"审核服务暂时不可用，请稍后重试"（verdict: service_error）两种提示文案，不再统一用"上传失败" |
T26/T32 供应商接入（当前均是 auto_pass 占位，未排期） |
供应商接入后：明确拒绝和服务异常两种情况前端提示文案不同 | 0.5（供应商就绪后执行，先不计入本期工时） |
| T46 ✅ | [已完成 2026-09-18] 弹幕聊天接入 dance room：新增 dance room 专属聊天接口——POST /api/dance/chat（body {uid, nickname, text, characterId}）、GET /api/dance/chat?characterId=...&cid=...（3s 轮询，同 live.html 的 pollChat 套路）。不能照抄 /api/chat 的实现——查过 server.js:3556 才发现现有 /api/chat 其实是"弹幕决定下一集演什么"的文本转视频请求入口，POST 成功后会直接调 submitPromptToQueue 触发生成任务，配的 isRateLimited（每 IP 5 分钟仅 3 次）也是按"生成任务"的额度设的，照搬到 dance 聊天上会导致发几条消息就被拦；dance room 的换装请求走的是独立的 /api/dance/pick，聊天在这里就是纯聊天，不应该触发任何生成。落地：新增一个不挂 submitPromptToQueue 的 pushDanceChatMessage(characterId, msg)（按 characterId 分桶存储，仿 pushChatMessage 的 300 条上限截断），复用 moderateText（通用违禁词表，语义上适用）过滤消息，新增一个独立的、更宽松的 dance 聊天限流（不复用 isRateLimited 那个 3/5min 的生成配额），具体阈值开工前拉一下建议值（比如每 IP 每分钟 10 条）；复用 live.css 已有的 .chat-list/.chat-msg/.chat-input-row/昵称哈希取色样式，不新增一套聊天 CSS；挂载到 T42 腾出来的右侧栏（.right-col 又拿回来了，这次内容是聊天，不是选衣服）。实现笔记：限流阈值定为 10 条/60s/IP（POST 一进来就先计数，body 校验/审核不通过的请求也占额度，防止用畸形请求循环绕开限流）。落库跟着 saveDanceState() 走，chatMessages 存在每个房间对象里（getDanceRoom 里懒加载补字段，兼容老的 dance-state.json），不单开一个文件。跟 /api/chat 还有一处有意的行为差异：未通过审核的消息不发布到房间（/api/chat 会把违禁词消息也推给所有人看，只是标"未通过审核"）——dance 聊天没有下游状态要展示给别人看，没理由让全房间看到被拒的文字。前端复用了 dance.html 在 T40 时已经加的 pastel() 取色函数，昵称身份行/改昵称走的是既有的 ensureIdentity/openNicknameModal（跟点赞共用同一个昵称 cookie 和同一个弹窗）。新写了一条后端集成测试（GET/POST 往返、跨房间隔离、审核拒绝不落库、参数校验、限流拦截），node --test *.test.js 142 个全绿；浏览器里端到端发送验证过——POST 立即成功、消息在 3s 轮询周期内出现在聊天列表（这是设计使然的轮询延迟，不是 bug，跟 live.html 现有聊天体验一致）。移动端没有另外做聊天/选衣服/待播放三块的收纳优化，沿用 T43 的"整页堆叠、不做 tab 切换"思路，没有超出这条任务本身的范围 |
T42（视觉空间） | 用户在某个人物直播间发的消息只在该直播间聊天里可见，切换到另一个 characterId 的房间看不到；正常聊天频率（比如 1 条/5 秒）不会被限流拦截，压测式狂刷才会被拦；违禁词仍会被拒绝；聊天面板不影响换装横条的可用性；未登录也能发言（走 ensureIdentity() 昵称 cookie）；不会触发任何视频生成任务 |
2.5 |
| T47 | 分享海报功能（已确认本期不做，见 §2 决策 3，保留候选记录避免遗漏）：生成一张竖版海报（当前换装截图+文案），支持复制链接/下载图片；PixVerse 的"直接分享到 Instagram/TikTok/X/Facebook"依赖对方 App 的 Web Share 集成，我们大概率只能做到"复制链接"+"下载图片让用户自己分享" | 无 | 点击分享按钮生成一张包含当前换装画面的竖版图片，可下载/复制链接 | 3（候选，未排期） |
| T48 ✅ | [已完成 2026-09-17] 同 uid 免费排队轻量限流：/api/dance/pick 增加校验——提交前查该 characterId 房间的 danceQueue 里是否已存在同一 uid 且状态未终结（非 done/failed）的条目，若有则直接拒绝（建议 400，error: "你已经有一件衣服在排队了，等它播完再选新的"）；前端 pickGarment/renderPickPanel 对"已有排队中条目"的用户禁用其余衣柜卡片的点击态，给出同样的提示；只限制免费 pick，upload-garment/upload-character（付费）不受影响 |
无（可独立于 T40-T46 先做） | 同一 uid 已有一条排队中的免费选衣服请求时，再次点击其他衣柜卡片被拒绝并看到明确提示；该请求播放完成（终结态）后能正常再选；同一 uid 在有免费请求排队时仍然能正常走付费上传（衣服/人物）不受影响；现有 dance-channel.test.js/dance-mode2.test.js/dance-mode3.test.js 不能红 |
0.5 |
本期总工时约 9 人天（T40-T44 + T46 + T48，不含占位的 T45、维持 候选未排期的 T47）。T40/T41/T44/T48 可完全并行（约 2 人天内出首批可看 效果），关键路径是 T40+T41→T42（本期最重的一项，3 人天）→T43/T46， 约 7 人天。
5. 第六期出口
- dance.html 桌面端有醒目的"正在换装"胶囊 + 排队头像条，视觉焦点从 "一个纯文字框"变成"能一眼看出谁在排队、排到谁了"。
- 选衣服从"网格点了就提交"变成"hover/二次确认再发送"，减少误触，且改 版为贴视频底部的横条，视觉上贴近参考实现的横条+悬浮态。
- "传衣服"/"传人"付费上传入口合并进换装横条的 DIY 卡片，左栏不再需要 tab 切换；上传有真实可感知的进度反馈，不再是一句"上传中…"干等。
- dance room 有了自己的聊天弹幕（按 characterId 隔离），右侧栏从"选衣 服网格"变成聊天面板。
- 同一 uid 不能靠反复免费选衣服刷队列，付费上传不受影响。
live.html与live.css的共享部分不受影响（每个改动都限定在 dance.html 专属的 DOM/CSS 里）。
6. 明确不在第六期范围
- 不接入 Agora/声网或任何实时推流通道。
- 不做深色视觉基调的整体重做（已确认保留漫画风）。
- 不把投票排序模型换成 FIFO 单请求限制（已确认只加 T48 轻量限流）。
- 不做分享海报（候选 T47，需另行确认后才排期）；不做 PixVerse 式的 "prompt-send"飘字弹幕特效（T46 只做常规聊天流）。
- 不改动登录/积分/审核商业化流程本身（T42 只挪上传入口位置）。