fix(video): use Router's canonical create and status routes - #59
Conversation
The published client posted to /v1/video/generate, which Router answers with 404. Router serves POST /v1/videos and GET /v1/videos/:id. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…' into pc-tcloud-59
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
drewstone
changed the title
drewstone
left a comment
drewstone
left a comment
There was a problem hiding this comment.
Independent source review approved the current four-file diff. Router mounts POST /v1/videos and GET /v1/videos/:id; the SDK and contract assertions now match. Exact-head SDK workflow 36235365715 is successful. Fresh local SDK validation passed 296 tests, with 32 conditional skips. Package publication and provider video execution remain unclaimed.
|
Publication has an active owner in the recovery release lane. Please avoid a second publisher or a separate 0.5.3 backport. |
2 participants
The SDK sent video creation and status requests to paths Router does not serve. It now sends POST /v1/videos and GET /v1/videos/:id.
This existing ChatGPT fleet delivery includes four files: the two SDK route corrections, their contract assertions, the SDK version 0.5.3, and the pinned PR workflow for a frozen workspace install, SDK build, tests, and package creation.
Verified head: d59a9fd.
Current Router source mounts both routes. SDK workflow run 36235365715 passed at this head. Local SDK tests passed, and an independent source review approved the four-file diff. No funded video generation or package publication is claimed.
After source merge, package publication uses the owning release workflow with operator authorization. A created video job must reach a terminal result before anyone claims a completed video.