Code Review — Multimedia Endpoint Support

Well-structured PR. All 4 handlers follow consistent patterns, endpoint backfill is correct across all existing handlers, tests are strong (575 lines with specific assertions). One medium finding, two low.

Medium

Fixtures without endpoint match multimedia requests, then 500 at type guard (router.ts:44-48)

Endpoint filtering is one-directional: fixtures WITH endpoint are restricted, but fixtures WITHOUT endpoint match ANY request type. A user with a generic chat fixture:

mock.addFixture({ match: { userMessage: "guitar" }, response: { content: "Chat about guitars" } });

This matches image requests for "guitar". handleImages matches it, then isImageResponse(response) fails → 500. The test only verifies the reverse direction (image fixture doesn't match chat).

Fix: when a request has _endpointType and the matched fixture has no endpoint, verify the response type is compatible with the endpoint before returning the match. Or make filtering bidirectional.

Low

extractFormField regex on binary multipart data (transcription.ts:15-22) — readBody converts binary to UTF-8 string. If file part appears before text fields, mangled bytes could theoretically match the regex. Extremely unlikely with real audio but fragile. A boundary-delimited parser would be more robust.

_endpointType not a declared field (types.ts) — stored via index signature, no type safety. Adding _endpointType?: string to ChatCompletionRequest would catch typos.

Clean

• Image gen (OpenAI + Gemini Imagen), TTS, transcription, video create/poll all correct
• matchFixture endpoint filtering works for the designed direction
• Convenience methods (onImage, onSpeech, etc.) wire correctly
• Video state map with X-Test-Id isolation is correct
• Backfill of _endpointType on all existing handlers is consistent

🤖 Reviewed with Claude Code