-
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
-
The previous system prompt asked GLM for a free-form "shot-by-shot" expansion, which reliably produced 4-5 fake cuts with timestamps running out to 8-10s — impossible for a clip fixed at ~5s (H3_GEN_PARAMS.frames / FPS). Rewrote it against docs/h3skill.md (MiniMax's own H3 prompt-writing methodology, added alongside this commit): every chat prompt has no reference images, so it's always T2VA mode, and at ~5s it's one continuous shot, never a montage. The new prompt asks for H3's actual three-field T2VA structure (integrated_multimodal_description / overall_soundscape / non_diegetic_music, fixed order and labels), a single dominant camera movement from the official vocabulary (type + amplitude + speed), concrete lighting (no hollow buzzwords like "8K"/"cinematic" alone), and — previously missing entirely — explicit sound design. Verified against the real GLM endpoint on several sample prompts: single continuous shot throughout, correct field structure, no more impossible multi-shot timestamps. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0144MiJ2cLjMd9jWaeEpVfUJ
-
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