4 Commits

Include renames

Author	SHA1	Message	Date
steveandClaude Opus 5	44fcfbb273	feat(videogen): LastImage — pin the trailing keyframe (first-last-frame-to-video) ... videogen.Request gains LastImage alongside InitImage, so one Request covers t2v, i2v and FL2V without a mode flag. With InitImage it pins both ends of the clip; alone it pins the destination and lets the backend invent the approach. The llamaswap provider sends it as a SEPARATE `input_reference_last` part rather than a second `input_reference`. Multipart permits repeated names, but then which frame is first and which is last depends on part ORDER — an ordering contract invisible in the payload, that nothing notices breaking. A backend that does not know the new name ignores the part, the same degradation as any other unknown field. Both parts go through one writeImagePart helper so their encoding cannot drift, and an empty LastImage is rejected up front exactly as InitImage already is. Support is per-model and deliberately NOT advertised in this contract: a backend that ignores a trailing keyframe returns an ordinary clip, which is indistinguishable from success. The doc comment says so, because a caller that needs to know whether the pin took effect has to establish that out of band — and the mort side gates on a convar for exactly this reason. Motivated by mort's #1567 (long-form video): with both ends pinned, drift becomes structurally bounded inside each shot instead of compounding across an autoregressive chain. Tests break-checked: sending the last frame under the shared name fails both the distinct-name assertion and the last-alone case. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01PLjgrxvHjm1sJgUu9zBPH9	2026-08-08 02:47:39 -04:00
steveandClaude Fable 5	776ef6fda9	fix: gadfly review — video-sized response cap, stale comment ... maxVideoResponseBytes (512MB) replaces the shared 64MB JSON cap on the /v1/videos/sync read path (doRaw now takes the cap per call) — 3/6 models flagged that a legitimate long/high-bitrate clip would be discarded after minutes of GPU work. Plus a stale stable-diffusion comment in initImageFilename and a test-handler early return. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01AXQxVhXBw8PwFAtsVrXSmj	2026-07-12 09:57:53 -04:00
steveandClaude Fable 5	89210346b8	fix: address review — fail loud on non-video bodies, dedupe form plumbing, doc parity ... - videoMIME no longer hard-falls-back to video/mp4: a 2xx body that is neither declared nor sniffable as video (JSON job envelope, HTML error page) is now an APIError instead of a 'successful' corrupt clip. - Resolution rides the wire as width/height AND the OpenAI-style size string, so either upstream convention honors an explicit request. - writeFormFields + mimeFromContentType shared helpers replace the copied multipart loop (audio.go/video.go) and Content-Type branch. - ADR-0019 indexed in docs/adr/README.md; README gains the videogen section + support-matrix mention (docs-parity rule). Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01AXQxVhXBw8PwFAtsVrXSmj	2026-07-12 09:53:34 -04:00
steveandClaude Fable 5	4629c6af0f	feat(videogen): canonical video-generation surface + llama-swap client ... New videogen/ contract package (ADR-0019): Request/Result/Model/Provider with the imagegen conventions. Text-to-video and image-to-video are one surface (Request.InitImage, nil = t2v) since hybrid checkpoints like Wan 2.2 TI2V serve both from one model; Result carries a single clip. provider/llamaswap gains VideoModel(id) targeting the blocking POST {base}/v1/videos/sync (multipart, model-routed by the fork's new video routes): vLLM-Omni parameter names, OpenAI-style input_reference file part, optional fields stay off the wire so per-model launch-flag defaults apply. CLAUDE.md package map picks up audio/ (missed in #12) and videogen/. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01AXQxVhXBw8PwFAtsVrXSmj	2026-07-12 09:31:08 -04:00