agent/docs/image-to-video-live-artwork-test.md

# User artwork live H3 test

2026-09-15 Asia/Shanghai. User supplied IMG_5598.jpeg and explicitly asked to test video generation after discussion of SW Ads upload + H3 generation. Only this supplied image is authorized; old synthetic drafts are not.

Target: one10-second H3 ref2va video through Agent Studio UI, existing9:16/768p defaults. Preserve original painted composition with neutral margins if necessary; subtle flags/sails/water/guest movement; sea and breeze ambience, no dialogue/music. Do not change duration/provider or submit another job without a confirmed safe reason. No account assignment, review approval or advertisement publication.

Task: i2v_2ef50a3d-c9ce-4264-b484-539e0122bb67. Title: 海边洞窟画作 · 10秒实测.

Original photo kept unchanged. Local webpage attachment normalized and copied into the registered durable task. This record currently proves local draft/Skill request only, not upload or H3 success.

Read-only video_h3_workers: four online idle workers before submission. Availability does not prove duration support or cost.

## Actual result: FAILED before reference transfer / H3 submission

- Web form created the registered task and Qwen read the actual Skill and all three references.
- Confirmed the exact supplied artwork/10-second prompt in the separate upload approval and approved once. No H3 generation approval was requested or granted.
- Result became unknown_upload. On-disk record revision2 has no upload receipt, assetId or jobId. State transitioned from initializing_upload to unknown_upload before an upload receipt could be parsed/saved; the sequential put() stage was therefore not reached. Whether a remote initialization ticket was reserved is unknown.
- Read-only current MCP listTools + exact submitted-argument validation passed. Normalized local reference is JPEG,2571635bytes. This diagnostic did not invoke upload or generation.
- Existing code discards the original remote/response-parser error, so the specific upstream or parser cause cannot be recovered from the task record. No blind initialization/import retry, new task or alternate-provider call was made.
- This is a real integration failure, not a video-generation success. The previous automated/boundary tests did not validate this actual initialization response. Repair needs sanitized private error/receipt preservation, actual response-contract diagnosis and another controlled same-image acceptance run.

## Repair investigation

User authorized repair. One controlled metadata-only diagnostic initialization used the same normalized reference hash and a distinct `-diagnostic-1.jpeg` filename. Actual tool response: `{"error_code":"invalid_arguments","detail":"push begin needs: ratio, prompt"}` with MCP `isError:false`; no upload ticket was returned and no picture bytes or H3 request were sent.

Root cause: live input JSON Schema marks these fields optional, but direct-upload begin requires ratio and prompt at runtime. The adapter omitted both and treated the provider error body as a successful payload, then lost the error during receipt parsing. The fix sends the frozen prompt and existing 9:16 ratio on begin/finish, recognizes provider error_code responses, and persists a sanitized failure stage/code without exposing remote details. Three new regression cases failed before the fix and passed afterward. Original unknown task remains quarantined; controlled new same-image acceptance run follows, not a reset of the original record.

## Controlled repair acceptance

New browser-created task: `i2v_4d14f754-c120-4a1d-a1cc-cc39af4bb4e7`, title 海边洞窟画作 · 修复验收10秒. Same user reference, same normalized hash, prompt and 10-second target. Actual Skill and references read; independent upload approval accepted in browser.

Initialization and image-byte PUT succeeded. Saved upload ID `du-f9eae1fb99e045f6`. Finish exposed a second runtime requirement: `{"error_code":"invalid_arguments","detail":"push finish needs: file_name, content_type, size_bytes"}`. Read-only lookup of this exact upload returned initiated, matching filename/hash/2571635 bytes and no asset ID. No second image upload was performed.

Fix now shares identical file metadata between begin and finish, passing the actual validated bytes through service.finalize. Regression test reproduced this finish rejection before the fix and passes afterward. A controlled operator recovery completed this same upload ticket with corrected metadata and returned finalizing. This was an explicit repair intervention, **not an uninterrupted all-web success**. The browser's own i2v_status then recovered the existing task to awaiting_submission. No record reset, ownership reassignment or alternate-provider request occurred.

## Earlier blocker: H3 submission outcome unknown (reconciled below)

The configured Qwen Responses connection returned MODEL_EMPTY_RESPONSE on three continuations. Switching the same gateway/model to Chat Completions (and therefore refreshing the model conversation context) restored actual Skill reads, status tool calls and the independent H3 approval. This does not establish which of protocol/context caused the original empty response. No provider or model change was made.

One H3 generation approval was accepted in the browser, but i2v_submit returned unknown_submission without a job ID. The deployed submit catch still discarded the specific response/parse failure, so no claim that H3 accepted, rejected, or generated a video is supported. Original 10-second parameters retained; no new submission or automated retry followed. Workers being idle does not prove no job was created. Available read-only tools do not expose lookup by idempotency key; harness_run_inspect requires a known run ID or flow kind and did not resolve this task.

Reconciliation identifiers (not credentials):
- Task: i2v_4d14f754-c120-4a1d-a1cc-cc39af4bb4e7
- Reference asset: casset-01ddea3b9bb14c2f
- Submit outcome timestamp: 2026-09-15T05:50:46.577Z
- Idempotency key: i2v_4d14f754-c120-4a1d-a1cc-cc39af4bb4e7/ba340e1bc788b28d9d54bcb7861027df1197135de3b08556e24d8a32c39a9d06

Follow-up repair saves original mutation responses in private 0600 per-task files before interpreting them, binding operation/revision/request hash; public messages contain only controlled stage/error codes. Regression reproduced missing receipt persistence and sanitized submit diagnostic failure before fixes. At this checkpoint no video had been delivered and the task remained quarantined pending backend reconciliation.

## Confirmed rejection and controlled recovery — 2026-09-15

The operator located the actual SW Ads gateway source and performed a narrowly scoped READ ONLY query against the corresponding service database. Matching the original idempotency key or reference asset within the correct organization returned **0 media jobs**. Only after that verification, a same-original-key diagnostic returned `invalid_arguments: idempotency_key must be at most 87 characters`. The gateway adds a caller namespace within a 128-character limit and rejects overlength keys before job creation. No duplicate generation was created by this diagnostic.

The adapter now sends a 68-character key containing a full SHA-256 binding of task ID and frozen request hash. Regression first reproduced the rejection, then proved accepted submission, stable duplicate identity and distinct identities for different tasks/requests. Existing unknown-submission guards were not relaxed.

`scripts/recover-confirmed-artwork-submit.mjs` performed one exact-task recovery with the local server stopped: required revision14/unknown state/no job/exact asset and hashes; saved the original record and reconciliation evidence privately; preserved owner and draft; reused the existing image asset without another upload; submitted through the production service. It is a one-shot operator intervention, not evidence of uninterrupted all-web success.

Confirmed real job: **cmjob-894ca2faddd34ff7**. Receipt and main task record are saved. The restarted Agent Studio shows this same job as generating and polls it without resubmission.

The real backend artifact contract uses `storage_url`, not `url`. Another red-green regression covers registered MP4 collection alongside JSON metadata and blocks conflicting URLs or foreign-job artifacts.

## Actual delivered preview and browser verification

The same job succeeded. The normal server collected its MP4 automatically, but strict validation correctly rejected the provider's 10.125-second video / 10.112-second audio (243 frames at 24fps, 768×1344). No second generation was submitted.

The collector now handles a bounded provider frame overrun of at most0.25seconds: it requires sufficient audio/video, compatible constant frame timing, trims only the tail at original speed, preserves the provider MP4, and applies the original Skill's full technical verification to the result. It never stretches, loops, pads missing time or accepts a too-short output. A real-FFmpeg regression exercises original-speed frame count, exact duration, original-byte preservation, and short/excessive-output rejection.

For this already-failed task, the stopped-server local-only `recover-artwork-duration.mjs` checks exact revision28/job/source hash, backs up the record, processes the registered local candidate, and registers the verified result. This is a second explicit operator recovery, not an uninterrupted all-web claim.

- Original `candidate.mp4`: SHA256 e7f0597eede161024de72aed6106e513f6972a7b7006ff40dcdbdea90cee583d, retained unchanged.
- Final `video.mp4`: SHA256 26a7b49e5f49b9b5507340669dc902ebd1583ebfcad06fd724e8831c8afd06c2, 9,772,338bytes.
- Actual video **10.000s**, actual audio **10.000s**, **768×1344,24fps**, complete decode and original Skill audio checks passed.
- Agent Studio task is `ready` and displays player/download. Browser metadata: duration10,readyState4,errornull. Keyboard-started playback reached currentTime10,endedtrue,errornull.
- Local download endpoint returned HTTP200,video/mp4,attachment disposition and the exact final byte count.
- Contact sheet sampled five moments. **Creative deviation:** H3 introduced real hands handling the painting and camera movement; it did not follow the intended fixed-camera subtle animation inside the painting. This is an integration preview, not a creative-quality pass. Audio content has not been listened to; no claim of full audio review.
- Final full verification before copy-only UI text update: **226 tests**, lint and typecheck passed; build passed. Independent read-only review found no blocking issue in key/artifact handling or duration processing. The one-shot credential helper now checks terminal echo is disabled; the actual credential entry already used disabled echo.

Result: actual supplied image → real H3 job → automatic local collection → exact-duration local processing → web playback/download demonstrated, with the operator repair interventions and visual limitation explicitly recorded. No CMS, account assignment, review approval, publication or duplicate generation.