-
H3's 4 GPUs run one sharded model (H3-CONSOLE.md /v1/status), not 4 independent workers, so a batch of N jobs is served ~serially. The poll loop's old fixed 200-iteration budget (~1000s at the 5s default interval) didn't account for queue depth: submitting a 9-job batch hit this live and 9/11 jobs got marked "generation timed out" locally while still sitting healthy in H3's queue (queue_position confirmed via GET /v1/videos/:id). Also treats H3's "cancelled" status as terminal, matching "error"/"failed". Recovered the wrongly-failed jobs by resetting them to "generating" in generation-jobs.json (their h3JobId was already set, so resumeDressupGenerations() picked them back up without resubmitting to H3) rather than resubmitting and burning the queue further. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011Deddn3sM3oQnmvqWSMb4y
-
ingest.js's syncLibrary() only carries a library entry forward as-is when edited is true; otherwise its periodic auto-sync (every 5 min) rebuilds the record from the raw H3 job and silently drops channel/characterId/garmentId/refDanceVideoId. That broke the M.7 dedupe cache and would have let dance clips leak into the regular live-channel pool once channel got wiped. Caught while running a real batch generation: the second sync cycle stripped a clip's traceability fields within 5 minutes of it landing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011Deddn3sM3oQnmvqWSMb4y
-
Fetches characters/garments/dance-refs alongside the library on load and joins each clip's characterId/garmentId/refDanceVideoId back to their names, so an operator can see "谁的脸 + 谁的衣服 + 哪条参考视频" per row (M.7). No composedImageId column — the one-step pipeline never produces an intermediate composed image. Extends the dressup-generate.test.js happy-path test to confirm the join resolves real names, not just matching ids. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
POST /api/admin/batch-gen takes {characterId, garmentIds[], refDanceVideoIds?[]}, expands to one job per garment (cross-producted with refDanceVideoIds when given, else one random active dance-ref per garment like the single-generate default), and submits each through the same submitGeneration() helper the single POST /api/admin/generate route now uses — so the M.7 dedupe cache (existing characterId+ garmentId combo) is honored per combo, not just per batch. GET /api/admin/batch-gen/status?batchId= returns that batch's generationJobs records for progress polling. admin-batch-gen.html: pick one character, multiple garments, and optionally pin specific reference dances; submits the batch, polls status every 3s into a progress table, and lets failed rows be retried individually via POST /api/admin/generate. Linked from the other admin pages' nav. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -
generateDanceVideo() takes a queued generationJobs record through prompt build -> forward character/garment/dance-ref uploads to H3 Console's /v1/assets -> POST /v1/videos -> poll -> push a traced clip into library.json (characterId/garmentId/refDanceVideoId). Mirrors generateForPrompt's submit/poll/persist shape but keyed off the new generationJobs store so a restart resumes any in-flight job by its h3JobId, same as resumeGenerations() does for the live queue. POST /api/admin/generate accepts characterId/garmentId (+ optional refDanceVideoId, else a random active dance-ref is picked) and skips straight to the cached clip if that character x garment combo was already generated (M.7 dedupe). GET /api/admin/generate/:id polls job status. Tests spin up a mock H3 Console over HTTP so the full submit/poll/land path runs offline. Also fixes two existing test fixtures (dressup-crud, admin-pages-flow) that spawn server.js without copying prompt-template.js — worked until T8 added the first require() of it into server.js, at which point the spawned server silently failed to boot. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
