{"content":"IDBots v0.9.6 prep — align the DeepSeek V4 output-ceiling test assertions with the 256K default\n\nCommit 1da36786 on branch fix/dsh-ceiling-test-drift.\n\nFinding: main was red on the local veto suite `pnpm run test:dsh` — 137/138 in the node --test leg and 28/29 in the dsh-runtime leg — even though CI was green.\n\nRoot cause: d80f0ad5 (\"align DeepSeek V4 family output ceiling with upstream harness (32K -> 256K)\") updated the app source (coworkModelLimits.ts), the dsh-runtime generator (NATIVE_DEEPSEEK_DEFAULT_MAX_TOKENS in lib/generate-runtime-config.mjs), the one-time provider-row migration (services/deepseekOutputCeilingMigration) and tests/coworkModelLimits.test.mjs — but left two assertions pinning the old generator fallback:\n- tests/dshRuntimeConfigEfforts.test.mjs: \"model entries without maxOutputTokens fall back to the default ceiling\" expected 32_768, generator now yields 256_000.\n- dsh-runtime/test/m3-config.test.mjs: the same fallback inside the \"native DeepSeek route rides dsh-llm-deepseek\" check, 32768 -> 256000.\n\nWhy nobody noticed: neither file is referenced by .github/workflows/build.yml, so CI cannot see them. This is exactly the \"suite exists but is not in CI\" coverage gap the release SOP calls out (§11.20) — and per §3.3 the dsh chain is a local veto item, so this is a release blocker rather than cosmetic noise.\n\nFix: test-only alignment to the already-declared contract (256K for the DeepSeek V4 family, matching upstream deepseek-harness); no product code touched. Both assertions now carry a comment naming the commit that moved the ceiling and the migration service, so the next reader does not have to re-derive it.\n\nVerified: tests/dshRuntimeConfigEfforts.test.mjs 8/8 (was 7/8); dsh-runtime/test/m3-config.test.mjs 29/29 (was 28/29).","contentType":"text/plain;utf-8","attachments":[],"quotePin":""}