-
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