test(sse): repair two base-red gates on release/v3.8.49

[backryun]

Why

release/v3.8.49 is red at its own HEAD (36f8fd10) — Quality Gates and Release-Green (continuous) both fail there, with no PR involved. Every PR opened against this base therefore shows the same four red checks regardless of content:

✖ No new ESLint warnings
✖ Fast Quality Gates
✖ Unit Tests fast-path (2/4)
✖ Unit Tests fast-path (4/4)

Ownership check before touching anything — of the base-red triage already in flight, none of these two causes is covered: #8480 is the compression ladder, #8481 the antigravity catalog, #8482 the resilience/translator regressions (its eslint-suppressions.json hunk adds an entry for oauth-refresh-connection-dedup-8059.test.ts, which has no any on this base — that's for its own change, not this drift). Shard 2/4 (combo-quota-share-cooldown-wait) does look like #8482's; it is not touched here.

1. Unit shard 4/4 — chatcore-client-usage-buffer.test.ts, 5/5 failing

#8331/#8356 (e8719783e) inserted an options parameter between clientResponseFormat and deps:

applyClientUsageBuffer(translatedResponse, body, clientResponseFormat, options = {}, deps = DEFAULT_DEPS)

The five call sites still passed deps fourth, so the injected spies landed in the options slot and the real implementations ran — every calls.*.length assertion saw 0 (0 !== 1). The Parameters<typeof applyClientUsageBuffer>[3] cast inside makeDeps() is what let this compile and reach the branch.

Call sites updated to (resp, body, format, {}, deps); the cast repointed to [4].

Two cases added for the parameter that caused the break, since nothing at this layer exercised it:

• preserveContextBudgetInVisibleUsage: true re-folds context_budget_* into the visible fields (the Claude-Code context-accounting path).
• The default path keeps the real, unbuffered fix(api): usage.prompt_tokens inflated by the 2000-token safety buffer in the client response only #8331 numbers — i.e. the safety margin stays out of client-visible metering.

2. No new ESLint warnings — claude-to-openai-think-close-5123.test.ts, 4 errors

Its eslint-suppressions.json entry allows count: 2, but the file had grown to four (chunk: any) callbacks. Suppressions are count-based, so the two extra ones were unsuppressed and npm run lint — the exact command the gate runs — exited 1.

Bumping the frozen count would have hidden it again, so the cause is fixed instead: collectChunks() now returns StreamChunk[] rather than unknown[], narrowing once at the boundary so all four callbacks need no annotation at all. With zero any left, the suppression entry is stale and is removed — a small ratchet improvement rather than a bigger allowlist.

Validation

All on a clean worktree of the base commit:

	before	after
npm run lint	4 errors	clean
chatcore-client-usage-buffer.test.ts	0 pass / 5 fail	7 / 7
claude-to-openai-think-close-5123.test.ts	3 / 3	3 / 3

Test files plus one allowlist deletion; no production code changes.

Note

I hit this while validating a TS7-readiness series (#8473, #8483, #8485, #8489 — tracked in #8484): all four carry these same four red checks, none of which they cause. Merging this should clear two of them for every open PR on this base, not just mine.

[backryun]

Pushed a third base-red cause: check:file-size, which is what turns Fast Quality Gates red.

Five files exceed their frozen line counts on release/v3.8.49 at its own HEAD — none of them touched by this PR:

file	frozen	actual
src/lib/tokenHealthCheck.ts	832	841
src/sse/handlers/chat.ts	1865	1866
src/sse/services/auth.ts	2475	2486
open-sse/services/accountFallback.ts	1941	1960
open-sse/services/combo.ts	3630	3642

Growth inherited from already-merged PRs that did not bump their entries, so there is no offending branch left to fix. The baseline already records this exact scenario under _rebaseline_2026_07_02_5798_release_green ("base-red for EVERY PR->release … no offending PR branch left to fix"), and the documented remedy is to raise the frozen values with a justification note — which is what this commit does, to the current base values only. The files stay frozen; an in-flight PR that adds lines bumps its own entry as usual.

Locally on the base commit: check:file-size, check:build-scope, check:pack-policy, typecheck:core, npm run lint all green.

Remaining after this PR

Unit Tests fast-path (2/4) — tests/unit/serial/combo-quota-share-cooldown-wait-timing.test.ts, the case "non quota-share (priority): short 429 cooldown → waits and re-dispatches (2nd pass 200)". It fails on a clean base checkout too, and it exercises the combo cooldown-wait path that #8482 is already rewriting (lockoutHintVerified → lockoutHintMs comparison logic). Left alone deliberately so as not to race that PR.

[backryun]

@diegosouzapw — owner decision needed on the complexity ratchet. It is the last base-red gate on this branch and I did not touch it, because every prior rebaseline of this metric is recorded as owner-approved.

State

check:complexity-ratchets fails on release/v3.8.49 at its own HEAD (36f8fd1):

metric	baseline	measured	delta	file
complexity (cyclomatic + max-lines-per-function)	2130	2169	+39	config/quality/complexity-baseline.json
cognitive-complexity	951	956	+5	config/quality/quality-baseline.json

Trust-but-verify: both numbers are identical on a worktree carrying none of this PR's changes, so this PR is complexity-net-zero — it only touches two test files, eslint-suppressions.json, file-size-baseline.json, and stryker.conf.json.

Why it needs you

The precedent is explicit and recent:

_rebaseline_2026_07_20_owner_night_drain: "Owner-approved (chat, 2026-07-20 ~00:50): 2072->2130. The day's 17 merged PRs consumed the entire slack … Owner chose a wide margin for the remainder of the v3.8.49 cycle instead of per-PR extraction."

That margin is now spent — the cycle has run 39 past it. Same class as before (inherited merge-burst drift; the ratchet does not run on the PR→release fast path, so it accrues unmeasured), but raising a complexity ceiling is a standing policy loosening, not a mechanical unblock like the file-size and stryker entries in this PR, so I'm not doing it unilaterally.

Where the drift sits

Concentrated, if you'd rather extract than raise:

file	cyclomatic/max-lines	cognitive
open-sse/handlers/imageGeneration.ts	27	14
open-sse/executors/chatgpt-web.ts	20	11
open-sse/services/adobeFireflyClient.ts	18	12
src/app/(dashboard)/dashboard/usage/components/EvalsTab.tsx	14	—
open-sse/services/combo.ts	11	6

Options

1. Raise with margin — e.g. complexity 2130 → 2195 and cognitive 951 → 965 (measured + ~26 / +9 headroom for the rest of the cycle). Mirrors the 2026-07-20 decision. I'll push it here with a justification note the moment you say a number.
2. Raise to exactly measured — complexity 2169, cognitive 956. Tightest, but the next merge re-reds the queue.
3. Leave it and let the v3.8.49 release close rebaseline — the file-size note already says the captain's rebaseline-at-release supersedes these; if the release is near, this PR merges with one known-red gate.
4. Extract instead — the three files above account for ~65 of the cyclomatic violations. Separate PR, not this unblock.

I'd suggest (1): it matches your last call on this exact metric and clears the queue for every PR on this base, not just mine. Numbers are yours to set.

Rest of the PR

The other three base-red causes are fixed and verified green locally on the base commit: npm run lint (was 4 errors), check:file-size (5 inherited overages), check:mutation-test-coverage --strict (11 unregistered covering tests), plus chatcore-client-usage-buffer.test.ts back to 7/7 from 0/5. The remaining Unit Tests fast-path (2/4) is the combo cooldown-wait case that #8482 is already rewriting — deliberately untouched.

[diegosouzapw]

Thanks for the thorough diagnosis here — this is exactly the kind of base-red triage we want (root-caused to the actual signature change from #8331/#8356, not just re-suppressed).

I reproduced all three claims independently on a clean worktree of the base tip:

• chatcore-client-usage-buffer.test.ts: confirmed the old 4-arg call sites break under the current (resp, body, format, options, deps) signature (0 !== 1 / TypeError), and your fix brings it to 7/7 including the two new preserveContextBudgetInVisibleUsage cases.
• claude-to-openai-think-close-5123.test.ts: confirmed 4 real any usages vs. the frozen count: 2; your StreamChunk narrowing brings it to a clean lint run and 3/3 passing.
• The file-size-baseline.json and stryker.conf.json chore commits: confirmed both gates fail on the base tip exactly as described and pass after your changes.

One heads-up: I independently opened #8505 about an hour after your last commit here, fixing the same eslint-suppression entry (different approach — a local OpenAIChatChunk type vs. your StreamChunk). Since your PR predates it and also covers the file-size and stryker fixes that #8505 doesn't touch, we'll merge this one and just rebase the small overlapping hunk if #8505 lands first — no action needed on your end unless GitHub flags a conflict, in which case a quick rebase on your branch will do it.

No production code touched, no missing tests, nothing else to flag. Planning to merge as-is.

[backryun]

@diegosouzapw — thanks for the independent reproduction on all three, and for the #8505 heads-up.

Pushed one more commit, because this PR as you reviewed it would still have left check:file-size red on the merge commit.

The accountFallback.ts entry I froze here was 1960 — the value at 36f8fd10, the base tip when I measured. The base has since advanced to 1cafd328c and the file is 1966 there, so the cap was already stale by 6 lines a few hours after I set it. Re-measured to 1966 and extended the baseline note to record why.

I re-checked the other four against the current tip; all still correct:

file	frozen	tip actual
src/lib/tokenHealthCheck.ts	841	841
src/sse/handlers/chat.ts	1866	1866
src/sse/services/auth.ts	2486	2486
open-sse/services/accountFallback.ts	1960 → 1966	1966
open-sse/services/combo.ts	3642	3640

check:file-size is green on the branch again.

Worth naming the pattern rather than just patching it: this is the same structural cause the note already cites — check:file-size does not run on the PR→release fast path, so growth accrues unmeasured between release rebaselines. Any freeze-to-exact-current-value has a shelf life measured in hours while the cycle is busy. So this entry can go stale again before merge. If it does, I'll re-measure — but merging promptly, or letting the release-captain rebaseline absorb it, is the more durable answer than me chasing the tip.

On #8505: no conflict from my side either way. It prunes the same suppression entry with a local OpenAIChatChunk; I used StreamChunk. Whichever lands first, I'll rebase the overlapping hunk out of this PR — the file-size and stryker commits here are untouched by it.

Still open from my side: the complexity-ratchet decision in my comment above (2130 → 2169 measured, cognitive 951 → 956, both net-zero from this PR). I left it alone deliberately. Since posting it I noticed the release-green bot's own footer on #8007 classifies exactly this drift as "expected mid-cycle and rebaselined at release — NOT a contributor concern", which reads like the answer is "leave it to the captain". If that's right, no action needed and I'll stop raising it — just confirming, because check:complexity-ratchets is a separate gate from the release-green validation that footer describes, and it is the last one red here.

[backryun]

Correction to my comment above, now that this has merged.

I wrote — and put into the _rebaseline_2026_07_25_v3849_basered_filesize note that shipped with this PR — that "check:file-size does not run on the PR→release fast path, so growth accrues unmeasured". That is wrong. check:file-size is a step in the fast-gates job of quality.yml and runs on every PR→release/**. I inherited the claim from the older _rebaseline_2026_06_29_v3841_release note and repeated it without checking the workflow.

The drift is real; the reason is different. These gates compare absolute values against the frozen file rather than the PR's own delta, so once the base is over a cap, every PR is red on that gate — which is why red gets merged past, which is how the next unbumped growth lands. This PR is itself an example: it merged with Fast Quality Gates and No new ESLint warnings both still FAILURE, and within hours providers/page.tsx (1990 > 1927, from #8349) and tokenHealthCheck.ts (843 > 841) were over.

Traced it end-to-end and filed #8522 with a proposal to make the PR-time comparison base-relative, keeping the absolute check for push to release/** and nightly release-green. The stale note text should be corrected too — I'll fold that into whichever PR touches the baseline next rather than opening one just for a comment.