[lorenzozanee]

Summary

Parse DeepSeek Web's native DSML invoke/parameter responses into OpenAI-compatible tool calls, preserving Windows paths and non-ASCII argument content.

Related Issues

Fixes #14208

Validation

Choose change type focused loop Contribution Golden Path. The full unit suite, Vitest, 60% coverage gate, and production build run in CI on PR (#8329):

• Change type: provider (translator)
• Focused tests category gates golden path
• npm run lint
• Reconciled current active release base; focused checks rerun afterward
• Production-code changes include new or updated automated test in PR
• SonarQube is temporarily opt-in while private project has no quota; not PR gate.

Tests Added Or Updated

• tests/unit/deepseek-web-tools-dsml.test.ts — covers native DSML calls with Windows paths and non-ASCII content.
• node --import tsx/esm --test tests/unit/deepseek-web-tools-dsml.test.ts
• node --import tsx/esm --test tests/unit/deepseek-web*.test.ts
• npm run check:open-sse-typecheck
• ESLint, Prettier, and git diff --check passed for the changed files.

Coverage Notes

• The focused regression and DeepSeek Web test suites cover the translator change. No coverage movement was recorded for this change.

Reviewer Notes

• The parser is scoped to DeepSeek Web's native full-width DSML envelope; the existing generic parser and other provider adapters are unchanged.
• Upstream CI, live DeepSeek behavior, Windows runtime behavior, and maintainer intent remain unverified.

[diegosouzapw]

Thank you for tackling the DSML parsing gap from #14208 — the tokenizer-based approach with proper depth tracking is a nice design. Testing it against the exact string from the bug report, though, the DSML_TAG_RE pattern only matches the closing-tag form <｜｜DSML｜｜ /parameter> (slash after the marker); the real upstream output — and the issue's own repro — uses </｜｜DSML｜｜ parameter> (slash before the marker), which this regex never matches, so the original bug report still fails to parse cleanly with this change (file_path ends up swallowing the rest of the payload). #13930 already lands a more permissive normalization that handles both tag-slash placements and is ahead in the queue, so recommending closing this one in its favor — but I'd genuinely welcome a follow-up that ports your depth-tracking tokenizer onto that broader tag matching if you want to keep pushing on it.