Fix/opencode zen muse spark responses - #5716
Conversation
Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
…nd="openai-compatible" Custom provider was fixed to ChatCompletions, ignoring providers.<name>.wire. Now honors per-config wire in both client::provider_wire_format_for_config and config::provider_capability, keeping Custom::wire_policy default as Chat for compat. Aliases: responses/openai-responses/responses-api -> Responses; anthropic/messages/claude -> AnthropicMessages; default -> Chat. Fixes custom muse-spark-1.2 on opencode.ai/zen/v1 needing Responses. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Muse Spark 1.2 contributor-free on https://opencode.ai/zen/v1 only supports POST /v1/responses (Responses API) and rejects Chat Completions. Previously the bundled offering roster and ModelAware resolver treated unknown muse-spark variants as chat or failed closed to unproven, so CodeWhale sent chat payloads that 404. - Add muse-spark-1.2, -contributor, -contributor-free to OPENCODE_ZEN_RESPONSES_MODELS (bundled_offerings) - Add resolver fallback: any muse-spark* under OpencodeZen resolves to endpoint_key responses even without exact catalog match - Update config.example.toml docs (GPT/Muse Spark -> Responses) and add muse-spark-1.2-contributor-free example - Add scripts/opencode-chat2responses-proxy.mjs as zero-Rust chat->responses shim for chat-only clients Custom gateways can already use wire="responses" (ff50458); this fix makes the first-class opencode-zen provider work without hand-written wire config. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Thanks @whp233 for taking the time to contribute. This repository is observing a maintainer-managed PR intake gate in dry-run mode, so this pull request is staying open. This note helps maintainers prepare the allowlist before any enforcement is considered. Please read |
The contribution gate leaves an unlisted contributor's workflow runs at `action_required`, so their CI never starts and the PR sits looking stalled through no fault of theirs. whp233's #5714 and #5716 had SEVEN workflows each parked that way; I approved those runs by hand, but the allowlist is the actual fix. Added (all five have landed or open work): whp233 open PRs #5714, #5716 — the runs that were parked musichen merged #5689 (DeepSeek configured-view picker) M-Maciej merged #5591 (goal continuation cadence) serephus merged #5669 (nixpkgs update) Pinvou fork owner behind #5686 (Moonshot/Kimi native search) Entries use `all:` to match the existing convention for active contributors. No-Issue: contribution-gate hygiene; no issue tracks it Signed-off-by: CodeWhale Bot <bot@codewhale.net>
Every rule here is something that actually went wrong on the 2026-08-29 night shift, written down so the next agent does not rediscover it. Landing other people's work: - A contributor's branch goes stale because WE land things. #5686 was CONFLICTING purely from Route Contract Phase 1 plus that same contributor's own earlier PRs merging into the same files. A maintainer resolves that. - Conflicts that split mid-function do not resolve by keeping both sides — the markers landed inside two function bodies and the naive resolution failed to compile with 'unclosed delimiter'. Take one side whole, re-insert the other's additions at their anchor. - maintainerCanModify did not grant push access to the fork (403), so the resolved merge went to integration/moonshot-kimi-5686-20260829 instead. That integration-branch path is now the documented default for conflicted work. - whp233's #5714 and #5716 each had SEVEN workflows parked at action_required because the author was not on .github/APPROVED_CONTRIBUTORS. The PRs looked stalled; nobody had looked. Five contributors have since been added. - Credit is mechanical: AUTHOR_MAP and .mailmap are project conventions and GitHub reads neither for the contribution graph. Merging under a gate: - #5698 merged while ACCEPTANCE_MATRIX.md still said FAIL and 37 minutes after a review confirming five findings were unchanged. Five real bugs reached main. A gate is its artifact, and check rollups are not the review thread. Claiming a test passed: - cargo test with a non-matching filter exits 0 having run ZERO tests; that was briefly mistaken for a pass here. - A harness scored 72 PASS of which 12 were never evaluated: 'ok = ok and X or True' parses as '(ok and X) or True'. CLAUDE.md already imports this file, so no second entrypoint was created. No-Issue: process documentation from the night shift Signed-off-by: CodeWhale Bot <bot@codewhale.net>
…rule scripts/check-coauthor-trailers.py rejects bot/tool co-author trailers because those trailers feed the GitHub contribution graph and are for humans. That rule was documented nowhere a contributor would look — CONTRIBUTING.md mentioned Co-authored-by only under harvesting, i.e. how WE credit THEM. The cost is real and current: whp233's #5714 and #5716 both fail Lint solely because their assistant appended 'Co-authored-by: Claude <noreply@anthropic.com>' to 3 and 4 commits respectively. Their code is fine. They had no way to know, and this will catch every contributor who uses an AI assistant — which is most of them now. Adds the rule to the Commit Messages section with the exact rebase command, and restates that co-authoring a person requires their GitHub-linked noreply address or the credit silently does not register. No-Issue: contributor documentation gap found while triaging #5714/#5716 Signed-off-by: CodeWhale Bot <bot@codewhale.net>
PR #5716 diverted OpenaiCodex credential resolution to the generic key resolver whenever provider_uses_custom_endpoint() is true, which dropped an explicit OPENAI_CODEX_ACCESS_TOKEN for custom-base-url setups. The shared-seam wiremock test proves the regression: the mock only answers Bearer test-token, so the request came back 404 on all three CI OSes (client::responses::tests::responses_stream_open_preserves_wire_headers_ through_shared_seam). The manual if-condition formatting also failed the Lint job's cargo fmt --check. Restore the pre-PR precedence by trying codex_credentials() first: env credentials still win on custom endpoints (codex_credentials checks env before the official-endpoint consent grant), the official endpoint keeps propagating OAuth errors, and only a custom endpoint with no env token falls back to deepseek_api_key() — preserving the contributor's goal of letting a custom endpoint authenticate with its own configured key. Signed-off-by: CodeWhale Bot <bot@codewhale.net>
|
Thank you @whp233 — the Your fork branch could not be pushed to from this side, so this PR is superseded by #5719, which carries your four commits with your authorship preserved verbatim ( Closing this one in favour of #5719 so the two do not race; please follow and comment there, and if you spot anything in the rescue that diverges from your intent, say so and it gets fixed before merge. The design is yours and #5719 says so in its description. |
|
Superseded by #5719 (your commits and authorship carried intact). |
|
@whp233, a status note so this does not look stalled: your fork branch cannot be pushed from our side, so the fix-forward lives at #5719, which carries your four commits intact in its ancestry (author name and email unchanged; only the bot co-author trailers were stripped, per the repo's credit rule). When #5719 merges, GitHub will mark this PR as merged automatically. What #5719 adds on top: the rustfmt drift in |
2 participants
Summary
Testing
cargo fmt --all -- --checkcargo clippy --workspace --all-targets --all-features --locked(warning-free under the CI allow list)cargo test --workspace --all-features --lockedChecklist