docs: correct Responses stream diagnosis (#150)

Author: BrainerVirus

README.md

@@ -25,7 +25,7 @@ This package is based on **[FanFan4204/opencode-commandcode-provider](https://gi
 - Vision vs text-only comes from the Command Code CLI catalog (`inputModalities` on every SKU). [models.dev](https://models.dev) only adds extra inputs (video/audio/pdf) when it matches.
 - Reasoning effort **variants** on models that declare `reasoningEfforts`.
 - Release date, family, input limits, model status, vendor context limits, and matched context-price tiers flow through the bundled catalog. V2 gets native release, family, input, status, and tier fields; V1 keeps its supported fields and base prices, with `context_over_200k` where representable.
-- The provider's `supported_endpoints` metadata chooses each model's API route. When a model advertises Messages, it uses Anthropic Messages; otherwise Chat Completions is preferred when available, and Responses is used when it is the only advertised route. This avoids malformed annotation events seen on the provider's Responses stream while preserving Responses-only models. V1 maps Responses to `@ai-sdk/openai`; V2 maps it to `aisdk:@ai-sdk/openai`. Claude Sonnet 4.6 returned `MODEL_NOT_IN_PLAN` with the message “available in Pro and above plans or extra on-demand usage”; entitled Claude access has not been live-verified. If a model fails on an account entitled to use it, please [open an issue](https://github.com/BrainerVirus/opencode-commandcode/issues) with the model ID and OpenCode version, or submit a PR with a reproducible fix.
+- The provider's `supported_endpoints` metadata chooses each model's API route. Messages is preferred when advertised; otherwise Chat Completions is preferred, and Responses is used only when it is the sole advertised route. This avoids the malformed Responses function-call start event observed on DeepSeek V4.1 Flash `#max` in OpenCode V2.0.18: `response.output_item.added` contained a `function_call` item without its required `arguments` string. That exact tool-call flow now passes through Chat Completions on V1 and V2. Responses mappings remain available for response-only models, but the current catalog has none. Claude Sonnet 4.6 returned `MODEL_NOT_IN_PLAN` with the message “available in Pro and above plans or extra on-demand usage”; entitled Claude access has not been live-verified. If a model fails on an account entitled to use it, please [open an issue](https://github.com/BrainerVirus/opencode-commandcode/issues) with the model ID and OpenCode version, or submit a PR with a reproducible fix.
 - Quiet OpenCode startup (diagnostics go to `startup.json`, not stdout).
 
 ## How it works

docs/specs/2026-09-28-v2-parity.md

@@ -36,16 +36,24 @@ and [Provider API](https://commandcode.ai/docs/provider) documentation.
 The provider's live `/models` metadata is the route authority when
 `supported_endpoints` is present. Prefer Anthropic Messages when advertised,
 then Chat Completions, and use Responses when it is the only advertised route.
-The order avoids malformed `response.output_text.annotation.added` chunks seen
-on the provider's Responses stream when a model also supports Chat Completions.
+This is a shared endpoint policy, not a DeepSeek-specific model override. The
+actual OpenCode V2.0.18 session error was a `response.output_item.added` event
+whose `function_call` item omitted its required `arguments` string during a
+DeepSeek V4.1 Flash `#max` shell-tool request. The earlier annotation-event
+diagnosis was incorrect. Current Command Code metadata advertises Chat on all
+74 non-Messages-only models, so the policy sends those models through Chat;
+Messages-only models keep Anthropic Messages. The 0.10.2 Responses mappings
+remain for future models that advertise Responses without another route, but
+the current catalog has no such entry. Other models' Responses tool-call streams
+were not individually live-tested.
 V1 uses `@ai-sdk/openai` for Responses and the Anthropic SDK for Messages. V2
 uses `aisdk:@ai-sdk/openai` for Responses and `aisdk:@ai-sdk/anthropic` for
 Messages. OpenCode 2.0.18 accepts the AI SDK package route; its newer native
 `@opencode/ai` package is not present in that tested image. If an older catalog
 lacks route metadata, Claude retains the Messages fallback and other models
-retain Chat Completions. The 0.10.1 catalog has 66 models advertising both Chat
-Completions and Responses, 10 Messages-only, and 8 Chat-only; it has no
-Responses-only model.
+retain Chat Completions. The current 84-model catalog has 66 models advertising
+both Chat Completions and Responses, 10 Messages-only, and 8 Chat-only; it has
+no Responses-only model.
 
 The isolated GOAT-key probes for Claude Sonnet and Haiku returned
 `MODEL_NOT_IN_PLAN`. Claude Sonnet 4.6 reported that it is available on Pro and
@@ -143,13 +151,16 @@ auth and metadata behavior.
 
 Fresh isolated OpenCode V1.18.30 and V2.0.18 starts fetched npm `latest`
 0.10.1 from the bare package entry. A separate isolated cache containing 0.9.1
-stayed on 0.9.1 at V2 startup, confirming that the warm-cache update still needs
-the host's update action. The locally installed V2.0.18 binary loaded the
-working-tree plugin through a temporary `file://` config and returned `OK` for a
-GOAT-key DeepSeek V4.1 Flash request in standalone mode; that model now takes
-Chat Completions when both Chat and Responses are advertised. The simple call
-did not reproduce the reported malformed annotation event, so this verifies the
-Chat route and local host integration rather than that exact stream failure.
-The same working-tree plugin returned `OK` in the official OpenCode V1.18.30
-and V2.0.18 Docker images. The user's active config, session, and auth files
-were not changed.
+stayed on 0.9.1 at V2 startup, confirming that a warm-cache update still needs
+the host's update action. After 0.10.2 was published, the locally installed
+V2.0.18 binary fetched and loaded 0.10.2 from a clean temporary cache with the
+bare package entry, then returned `OK` for a DeepSeek request.
+
+For the actual tool-call regression, a temporary local config pinned the
+working-tree plugin by `file://` path, used DeepSeek V4.1 Flash `#max`, and
+allowed only a `printf*` shell command. The same `printf TOOL_CALL_SMOKE_OK`
+tool request succeeded on the installed local V2.0.18 binary and in the
+official V1.18.30 and V2.0.18 Docker images. These runs verify the formerly
+failing model/variant/tool-call path through the new Chat route; they do not
+validate every model's Responses stream. The user's active config, session, and
+auth files were not changed.