fix(stream-readiness): bump timeout for heavy Claude-format reasoning replicas

[herjarsa]

Summary

Third-party Claude-format replicas (Minimax M2.7/M3, ZAI, bailian,
agentrouter, wafer, …) inherit Anthropic's stream shape but their
reasoning warm-ups routinely exceed the default 80s readiness window.
STREAM_READINESS_TIMEOUT fires before the upstream emits its first
non-ping SSE event, surfacing the request as a stalled task to clients
like OpenChamber / Claude Code — they demand manual continuation on
every long-running task.

Root Cause

open-sse/utils/streamReadinessPolicy.ts only bumped readiness for
codex_gpt_5_5_high_reasoning (#3825). Every other Claude-format
provider inherited the vanilla 80–180s window and tripped 504 on the
reasoning warm-up.

Fix

Mirror the codex-high +30s bump on every provider whose registry
entry has format === 'claude', excluding first-party claude /
anthropic (stable cold starts). The registry is the single source of
truth, so newly-registered replicas inherit the bump without code
changes. Stays within the existing maxTimeoutMs cap so a single env
knob still bounds the readiness window overall.

Tests

• 17/17 tests/unit/stream-readiness-policy.test.ts pass
  (10 existing + 7 new)
• 16/16 tests/unit/stream-readiness.test.ts pass (no regressions)
• 11/11 tests/unit/combo-stream-readiness-fallback.test.ts pass
  (no regressions)
• npm run typecheck:core clean

New tests cover: Minimax M3, ZAI, official claude/anthropic (no bump),
OpenAI (no bump), unknown providers (no false positives), and the
maxTimeoutMs cap with the new bump stacked against large payloads.

Files Changed

• open-sse/utils/streamReadinessPolicy.ts (+33 lines)
• tests/unit/stream-readiness-policy.test.ts (+105 lines)

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[diegosouzapw]

Thanks for this — clean, well-tested generalization of the #3825 mechanism to third-party Claude-format replicas via the registry's format === "claude" field, so new replicas inherit the bump without code changes. Verified: real diff is exactly the claimed 2 files / +138 (no base drift), all 17 stream-readiness-policy tests pass plus the 16 stream-readiness + 11 combo-stream-readiness-fallback regression suites, lint clean, full tsc --noEmit clean, and the bump stays within the existing env-configurable maxTimeoutMs cap — same safety envelope as the codex_gpt_5_5_high_reasoning precedent, not a magic number.

One question: do you have a concrete log/report (like the one on #3825) showing the 504-on-readiness pattern specifically for Minimax/ZAI/bailian/agentrouter/wafer, or is this a by-analogy generalization from the codex fix? Either is fine to merge given how conservative and capped the change is, just want to note it in the PR history.

We'll retarget the base from main to release/v3.8.49 on our side before merging (mechanical, no code change required) — no action needed from you.

[herjarsa]

Diagnostic update — failures are pre-existing on release/v3.8.49, not caused by this PR

History-cleanup already done: this PR is now 2 commits, 3 files (down from the original 9 commits / 100 files drift). Each file in the diff is intentional:

1. open-sse/utils/streamReadinessPolicy.ts — the fix (+33)
2. tests/unit/stream-readiness-policy.test.ts — the tests (+105)
3. config/quality/quality-baseline.json — rebaseline for CI drift (see below)

CI failures are pre-existing, not introduced by this PR

I ran the failing checks locally on the upstream tip (ea5862d1 = release/v3.8.49) with my fix removed and reproduced both failures exactly. Per ~/.agents/workflows/repo-standard/1000-pr-diagnose.md (memory #980), I treat pre-existing failures as out-of-scope for this PR.

Fast Quality Gates — check:mutation-test-coverage

open-sse/utils/publicCreds.ts
  + tests/unit/microsoft-designer-web-6672.test.ts
✗ 1 covering unit test(s) across 1 module(s) are missing from
  stryker.conf.json tap.testFiles. Add them so their mutant kills
  count (--strict).

This is tests/unit/microsoft-designer-web-6672.test.ts (added in PR #6672, merged into release/v3.8.49 via the cliproxy cycle) covering publicCreds.ts without being registered in stryker.conf.json::tap.testFiles. Existing open PRs on release/v3.8.49 already target this exact fix:

• fix(stryker): add Microsoft Designer test to tap.testFiles #7659 fix(stryker): add Microsoft Designer test to tap.testFiles (fix/7657)
• chore(quality): register #6672 test in stryker tap.testFiles (base-red unblock) #7652 chore(quality): register #6672 test in stryker tap.testFiles (fix/release-v3.8.49-stryker-testfiles)

Once either merges into release/v3.8.49, my PR will go green on this check.

Quality Ratchet — zizmorFindings 176 vs baseline 175

zizmorFindings count grew by 1 entirely on the upstream side (workflow changes in release/v3.8.49 cycle, see _rebaseline_2026_07_17_v3849_release: _169 → 175 (+6), then cycle drift continued to 176). My commit 6120561a touches zero workflow files. This matches the precedent documented in the baseline itself:

_rebaseline_2026_06_23_v3835_release: "v3.8.35 cycle drift surfaced by the release-green pre-flight (the Quality Ratchet does NOT run on PR→release fast-gates, so warnings accrued unmeasured across this cycle's parallel-session merges). … all +5 is inherited contributor drift."

The 2nd commit in this PR (f99aa816c) rebaselines the baseline from 175 → 176 (zizmor) and 86.44 → 86.42 (coverage.functions, drift from PR #7625 adding failureTracker.ts), per the same precedent. The re-baseline notes are explicit that the drift is not from #7612.

Summary

File / Commit	Author	Purpose	Reviewer action
6120561a — streamReadinessPolicy.ts (+33) + test.ts (+105)	me	the actual fix	review the diff
f99aa816c — quality-baseline.json (5 +/3 −)	me	rebaseline CI drift	accept (precedent)
(open PR #7659 / #7652)	maintainer	fixes the microsoft-designer-web-6672.test.ts → stryker.conf.json drift that gates my PR	merge first, then my PR auto-turns green

Could a reviewer with merge rights either:

1. merge one of chore(quality): register #6672 test in stryker tap.testFiles (base-red unblock) #7652/fix(stryker): add Microsoft Designer test to tap.testFiles #7659 first and trigger my PR's auto-retry, or
2. tell me to git cherry-pick the stryker fix from chore(quality): register #6672 test in stryker tap.testFiles (base-red unblock) #7652 into my branch here? Happy to do the latter if preferred — just say the word.

cc @diegosouzapw — thanks!

[diegosouzapw]

Merged into release/v3.8.49 — thank you for the contribution, @herjarsa! 🎉 Validated in today's full-suite merge-train (33 PRs, 19k+ tests green) before landing.