[maxmad64bis]

Summary

#10874 fixed Muse Spark on the opencode provider by declaring targetFormat: "openai-responses" on its registry entries — the model only answers on the Responses API, not /chat/completions. Same upstream family, two more provider registries never got the memo:

• opencode-zen — muse-spark-1.2 had no targetFormat; muse-spark-1.2-contributor-free wasn't even declared.
• opencode-go — all 6 muse-spark-1.2-contributor* effort-tier entries had no targetFormat.

Both share the same executor (opencode) and the same upstream family (opencode.ai/zen/*) as the provider #10874 already fixed, so it's the same bug, just three separate copies of the same registry data drifting independently. Mirrored the same declaration onto both.

Left freebuff's meta/muse-spark-1.2-contributor alone — verified: distinct backend (codebuff.com, dedicated freebuff executor posting to /chat/completions, no Responses API), so the same fix doesn't apply there.

Related Issues

• Closes fix(providers): Muse Spark still returns empty content on opencode-zen and opencode-go (targetFormat missed by #10874) #11048

Validation

• Change type: routing (provider registry — open-sse/config/providers/registry/opencode/{zen,go}/index.ts)
• node --import tsx/esm --test tests/unit/opencode-zen-muse-spark-targetformat-11046.test.ts — 2/2
• Existing suites for these two registries re-run too (opencode-zen-reasoning-effort, opencode-zen-alias-combo-e2e, auth-opencode-zen-noauth-fallback) — 18/18 total
• npm run lint clean
• Branched from current release/v3.8.50 tip
• Test written first against the real registry data, confirmed failing, then fixed

⚠️ base-red inherited: #9985

Tests Added Or Updated

tests/unit/opencode-zen-muse-spark-targetformat-11046.test.ts:

• opencode-zen's muse-spark-1.2 and muse-spark-1.2-contributor-free both resolve to targetFormat: "openai-responses"
• All 6 opencode-go muse-spark effort-tier entries do too

Coverage Notes

Registry data only — no logic changes, covered by the assertions above plus the full existing test suite for both registries.

Reviewer Notes

Didn't touch freebuff — verified it's a genuinely different backend (codebuff.com /chat/completions, dedicated executor, no Responses API involved), so the same fix doesn't apply; not a guess.

This is the second copy of this exact bug found in two days (see #11046/#11047) — same upstream registered under 3 provider entries with no shared source of truth for per-model capability flags, so a fix to one silently doesn't cover the others. Follow-up de-duplication opened as #11051 (extracts the entries that were already byte-identical across opencode-zen/opencode-go into a shared array).

[diegosouzapw]

Nice, clean fix — thanks. This correctly closes the gap where opencode-zen and opencode-go (separate registry entries for the same opencode.ai/zen/v1 upstream) never got the targetFormat: "openai-responses" declaration that #10874 added to the base opencode provider, so Muse Spark requests there still hit /chat/completions and upstream returned an empty message. Verified locally against origin/release/v3.8.50: the new test passes (2/2) and the related existing opencode tests (opencode-muse-spark-responses-10867.test.ts, opencode-go-catalog-alignment.test.ts) stay green (7/7) — no regression. The test acts as a genuine guard (it would fail on the base since the zen/go muse entries lack targetFormat). No mandatory items from review; ready to merge. One optional nit: the new zen muse-spark-1.2-contributor-free entry now duplicates the base provider's id/name with supporting fields — fine as an explicit wire-format overlay, just noting it so future catalog syncs don't drift.