-
参考 PixVerse world.pixverse.video/live/dress 的交互设计（分析见 docs/reference/pixverse-dress-live/NOTES.md），按 docs/todo/dev-plan-6.md 的任务表实现： - T40: 顶部"正在换装"胶囊 + 排队头像条 - T41: 换装卡片 hover/点击展开"发送"态，避免误触直接提交 - T42: 右侧"选衣服"网格改为贴视频底部的横条，"传衣服/传人"付费上传 入口合并进横条末尾的 DIY 卡片二选一弹窗，左栏撤掉多余 tab - T43: 修复移动端视频宽度驱动的 9:16 布局把"待播放"挤压到不可用的 问题，改回高度驱动 - T44: 上传进度条（伪进度+真实 XHR 进度混合） - T46: dance room 专属聊天（不复用 /api/chat 以免误触发生成任务， 独立限流/审核/按房间隔离存储） - T48: 同一访客同时只能有一条免费换装请求在排队，付费上传不受影响 新增/修改的后端集成测试覆盖 T46/T48 的核心行为；node --test *.test.js 142/142 通过。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01R4TVxY4MRoxDPwNhcK5Z34
-
Extends the 跳舞直播间 (dance room) system to one independent live room per character, with an operator playback-management/blacklist layer (T39), a "我的作品" page for paid users (T38), a standalone 人衣图生成 admin tool, and a new admin-dance-library.html page for curating the per-character dance clip pool with AI QC. On top of that, dance clips now have an explicit published (上架/下架) status: passing AI QC (or a manual admin override to "correct") auto- publishes a clip, failing it auto-unpublishes it, and only published clips are eligible for a room's random-fill pool — unreviewed/rejected clips stay in the library but no longer autoplay for viewers. Existing already-QC'd "correct" clips are backfilled to published on first boot so the room doesn't go quiet. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MvkJsRcQ2qEuaFea31rBY8
-
…k, stale-task recovery, pagination Person reference photos (any subset of full-body/face x front/side/back) + one garment image -> async background task generating front/side/view composites of that person wearing the garment, via either GPT Image 2 (万界方舟) or wavespeed.ai's Seedream v4. Split into three pages (admin-dressgen.html create / admin-dressgenlist.html list / admin-dressgendetail.html detail) since the combined page's operations column was easy to lose off-screen; the list page's action column is now sticky and every thumbnail opens a click-to-zoom preview. Default provider (image2) auto-falls-back to wavespeed per view on any failure — an explicit, later product decision overriding this session's earlier "no auto-switching around moderation" stance, recorded in the code comment above WAVESPEED_API_KEY. A crashed/restarted process no longer leaves a task stuck in "generating" forever (resumeDressgenTasks(), same idea as T8's resumeDressupGenerations()). GET /api/admin/dressgen is now paginated (?page=&pageSize=, defaults 20) instead of returning the whole file as a bare array. 19 tests in dressgen-generate.test.js, including a real crash-and-restart scenario (SIGKILL against a hanging mock, second process reading the same on-disk store) and the auto-fallback path. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Px7XHxSdWfd5b3vfNMwQjd
-
Breaks down dressup-dance-room.md 9节第5条 (paid character upload, face-blacklist moderation, character lifecycle/quota, priority scheduling for paid_boost content, fal.ai real-time compute, "我的 作品" page, playback management) into T31-T39 with acceptance criteria, estimates, and a dependency graph, matching dev-plan.md through dev-plan-4.md's format. Flags one thing worth being upfront about: T27 (mode 2, completed in the prior phase) never actually integrated fal.ai despite dev-plan-4.md's own T27 row calling for it — it still runs entirely through H3 Console. No FAL_API_KEY has ever been configured, so there was no credential to build or test a real fal.ai path against; T27 shipped a fully working H3 Console path instead, same call as T24 did with Stripe. T33 folds paying off that debt into this phase (mode 3 needs the same fal.ai integration anyway, so building it twice would be wasted work), with the same "build the plumbing, real key unlocks real verification" shape as T24. Also asks the user a real question rather than defaulting silently: T26's "no vendor configured -> auto-pass" precedent doesn't transfer to face-blacklist review of real uploaded faces the way it did for garment photos — the risk profile is different, so T32's default policy when unconfigured is left for the user to decide rather than assumed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011DUiYs6UjxDMkfvnjtsKFo
-
Breaks down dressup-dance-room.md 9节第4条 (credit ledger, Stripe topup, mode 2 paid garment upload — explicitly not mode 3, which is period 5) into T23-T30 with acceptance criteria, estimates, and a dependency graph, matching dev-plan.md/dev-plan-2.md/dev-plan-3.md's format. Key decisions: - credit_ledger joins users/sessions in the same SQLite db.js (T18) — architecture.md 1.4 flagged this atomicity requirement explicitly, this is the other half of why SQLite got picked in period 3. pricing_config stays a JSON file (store.js) since it's not on that hot atomic path. - Flags a real doc inconsistency: architecture.md's diagram labels fal.ai integration "period 5", but dressup-dance-room.md §8 item 10 and §9 item 4 both say mode 2's fal.ai path belongs in period 4. Resolved in favor of the more specific/recent requirements doc. - Flags an uncovered gap: §5 references an image-moderation vendor "TBD, see §8" but §8 has no matching item for it — added as an open question here (§1.2). - Three genuinely external blockers (image moderation vendor, vision model vendor for auto-tagging, real Stripe API keys) are each designed around with a pluggable interface (same pattern as T20's sendVerificationEmail) so building isn't blocked on vendor picks — except the Stripe key itself, which only the user can supply. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011Deddn3sM3oQnmvqWSMb4y
-
Breaks down dressup-dance-room.md 9节 phase 3 (dressup-dance-room.md 9节第3条: email login, bind anonymous viewer_uid to an account, no credits/payment yet) into T18-T22 with acceptance criteria, work estimates, and a dependency graph, same format as dev-plan.md/ dev-plan-2.md. Key decisions: users/sessions land in SQLite per architecture.md 1.4's own trigger condition (credential storage), using Node 24's built-in node:sqlite + node:crypto scryptSync — zero new npm dependency, no package.json needed. Flags one real gap the requirements doc's 待验证 list missed: no email-delivery vendor has been chosen, so T20 ships a pluggable sendVerificationEmail() with a dev-mode bypass rather than blocking on that decision. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011Deddn3sM3oQnmvqWSMb4y
-
Records the 2026-09-02 real-H3 verification of T1-T10 (11 videos / 10 garments, the barefoot reference-video leak finding, the two bugs found and fixed) and cross-references that T11-T17 (dev-plan-2.md) landed the same day from a separate session, so the docs don't read as stale the next time someone opens them. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011Deddn3sM3oQnmvqWSMb4y
-
Breaks down dev-plan.md's phase-2 scope (dressup-dance-room.md 9节 第2条: dance.html + 免费衣柜模式 + 去重缓存, no paid modes/accounts/ credits yet) into T11-T17 with acceptance criteria, work estimates, and a dependency graph, same format as dev-plan.md's T1-T10. Notes that dev-plan.md's own phase-1 exit criterion (batch-generate >=30 seed videos with real assets) is still outstanding and is an operational step, not blocking this plan but blocking the wardrobe actually having content once T11-T17 land. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
buildStage2Prompt() renders MVCP M.15's confirmed one-step six-section template and enforces the two dynamic risks M.15.1 flagged: caps appearanceDescriptor/garmentDescriptor at ~40 words each, and truncates motionDescriptor if it alone would push detailed_description past H6's 500-word cap (the only placeholder that lands in that section). Also fixes the footwear-drift the S1 spike found (model self-selected shoes when the prompt didn't constrain them) — pins footwear to <Picture 1> in both subject_definitions and retention_analysis, and says <Picture 2> doesn't affect it. Propagated the same fix into the M.15 template in the MVCP doc so the doc and the code don't drift. Tests check the mechanical M.15.1 items that are checkable from the rendered string (H1/H5/H6/H9) plus the truncation behavior and the footwear fix. H13 (reference counts) is a submission-payload concern, covered by T8's tests instead.
-
S1: person+garment images directly into ref2va with attribute_transfer produce correct face/outfit/motion in one call — no separate compose step needed. S2: reference_video_urls has a real, strong effect on output motion (A/B tested). S4: H3 Console's own POST /v1/assets endpoint (undocumented until now) solves asset reachability without exposing our own uploads/ publicly. Evidence and scripts in spike/s1-s2-s4-2026-09-02/. Propagated the one-step design into the requirements doc, MVCP design doc, the architecture doc, and H3-CONSOLE.md; dev-plan.md's spike section marked done and its task table updated accordingly.
-
Duration: fixed 10s (within H3's 4-15s hard constraint), frames=240 @ 24fps. Prompt: follows the internal H3 prompt-writing methodology already sitting in the repo (docs/h3skill.md, from a parallel session) — the "all-purpose reference mode" six-section structure. Character appearance details are auto-captioned from the Stage1 composed image (new composed_images. appearanceDescriptor field); dance motion phrasing is admin-authored once per reference video (new dance_refs.motionDescriptor field), since the format requires concrete descriptors and forbids "as shown in the picture." Flagged as needing a pass through h3skill.md's own 22-item mechanical acceptance checklist before production use, not claimed as fully compliant. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SdtXTsDRz5QWMjvt1HBXLz
-
Previously left as inline "勘误" patch notes; now the baseline doc (docs/done) states the current 480x832 default outright, and the dance-room docs describe live.html/dance.html as two independently configured H3_GEN_PARAMS that happen to agree, rather than flagging an erratum. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SdtXTsDRz5QWMjvt1HBXLz
-
Data model, front/back-end view inventory, button-level control design, and per-user-type process flows for the not-yet-built feature. Also corrects the requirements doc's stale "live.html stays landscape" claim now that H3_GEN_PARAMS was changed to portrait there too (commit 1dc7084). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SdtXTsDRz5QWMjvt1HBXLz
-
Documents the new outfit-swap dance live room (dance.html) requirements alongside the existing text-prompt live channel baseline, plus the combined system architecture covering both. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SdtXTsDRz5QWMjvt1HBXLz