[Bug] developer role rejected (HTTP 400) by custom domestic (China) OpenAI-compatible providers

[YeMuLong]

Title: [Bug] Custom providers via OpenAI-compatible endpoint return HTTP 400: developer is not one of ['system','assistant','user','tool','function']

Body:

Summary

When adding a custom provider through an OpenAI-compatible endpoint (e.g.
Volcengine Ark https://ark.cn-beijing.volces.com/api/v3 or Alibaba
DashScope/Bailian https://dashscope.aliyuncs.com/compatible-mode/v1), the
first request fails with:400 {"error":{"code":"invalid_parameter_error","param":null,
"message":"developer is not one of ['system', 'assistant', 'user', 'tool', 'function']",
"type":"invalid_request_error"}}

Environment

• dsh: 0.1.0-rc.6 (npm @deepseek-ai/dsh)
• OS: macOS (Apple Silicon)
• Model: any domestic (China) cloud model (Volcengine doubao-seed-2.1-turbo,
  DashScope qwen3.7-max, etc.)
• Protocol: chat-completions

Root cause

dsh routes model requests through @earendil-works/pi-ai's
openai-completions adapter. In dist/api/openai-completions.js,
supportsDeveloperRole is computed as:

supportsDeveloperRole: isOpenRouterDeveloperRoleModel || (!isNonStandard && !isOpenRouter),where isNonStandard only lists western vendors (NVIDIA, cerebras, xAI,
Together, Chutes, deepseek.com, ZAI, Moonshot, opencode, Cloudflare,
ant-ling). Domestic (China) cloud endpoints such as volces.com and
aliyuncs.com are NOT in that list, so pi-ai treats them as "standard"
endpoints, reports supportsDeveloperRole: true, and — combined with a
reasoning-enabled model — sends the developer role. These domestic OpenAI-
compatible APIs only accept ['system','assistant','user','tool','function']
and reject developer with HTTP 400.

This is systematic: ANY custom endpoint not in pi-ai's list hits the same
issue, not just Volcengine/Bailian (same class of bug reported for
OpenClaw, OpenCode, Roo Code, Kilo Code, MiniMax etc.).

Workaround (verified)

Patch node_modules/@deepseek-ai/dsh/node_modules/@earendil-works/pi-ai/dist/api/openai-completions.js line ~1148:

- supportsDeveloperRole: baseUrl.includes("volces.com") ? false : (isOpenRouterDeveloperRoleModel || (!isNonStandard && !isOpenRouter)),
+ supportsDeveloperRole: (baseUrl.includes("volces.com") || baseUrl.includes("aliyuncs.com")) ? false : (isOpenRouterDeveloperRoleModel || (!isNonStandard && !isOpenRouter)),

After restarting dsh, the model works (pi-ai falls back to the system role).

Suggested fix

Add domestic cloud domains (volces.com, aliyuncs.com, bigmodel.cn,
baidubce.com, etc.) to the isNonStandard list — minimal change; OR
Better: invert the default — only treat endpoints pi-ai explicitly knows
(official OpenAI/Anthropic/...) as supportsDeveloperRole-capable, and
default custom endpoints to false (safe for all OpenAI-compatible
third-party APIs); ORExpose a config flag (e.g. supportsDeveloperRole) per model/provider so
users can opt in/out without editing node_modules.

[zoahdev]

Landed a dsh-side fix (rather than patching node_modules):

zoahdev/deepseek-harness@fix/pi-ai-supports-developer-role-flag

llm-pi-ai now exposes a compat.supportsDeveloperRole switch (route-level and per-model). It overrides pi-ai's vendor-list auto-detection, so a custom endpoint can set compat: { supportsDeveloperRole: false } and pi-ai falls back to the system role — no more HTTP 400, no editing node_modules.

This is your option 3 (config flag), which is the durable one: option 1 (grow the domain list) never ends, and option 2 (invert the default) breaks providers that do support it. The flag lets each endpoint state the truth. llm-pi-ai suite 210/210.