[fenix007]

Summary

release/v3.8.49 is red at its own tip (30709255), so every PR against the branch inherits four failing checks regardless of content. This PR repairs what can be repaired from a contributor branch. Four commits, each independent:

#	Commit	Fixes
1	test(resilience)	Unit Tests fast-path (1/4) — 3 assertions
2	fix(quality)	check:db-rules + Unit Tests fast-path (2/4)
3	chore(quality)	No new ESLint warnings
4	chore(quality)	Fast Quality Gates → check:file-size

Every claim below was measured on a pristine origin/release/v3.8.49 checkout with an empty working tree, in a worktree separate from the change.

What was red and why

1. Three backoff assertions (error-classification.test.ts, thundering-herd.test.ts)

b64361dd2 (#8396 / #8446) capped the scaled connection cooldown at BACKOFF_CONFIG.max so a 429/5xx burst cannot black a connection out past the real rate-limit window. Three tests still expected uncapped doubling:

expected  [5000, 10000, 20000, 40000, 80000, 160000]   ← 5000 × 32
actual    [5000, 10000, 20000, 40000, 80000, 120000]   ← BACKOFF_CONFIG.max

The cap is intended behavior, so the expectations follow it. newBackoffLevel clamping is untouched and still asserted.

2. compressionDetailNormalizers not in the allowlist

AssertionError: Unexported db module(s) not in KNOWN_UNEXPORTED: compressionDetailNormalizers

src/lib/db/compressionDetailNormalizers.ts is imported only by db/compression.ts and exists because compression.ts is frozen at its file-size cap (#8388). Re-exporting it through localDb.ts would advertise the barrel-import anti-pattern Hard Rule #2 forbids, so INTENTIONALLY_INTERNAL is the right home. This unblocks both the gate script and its freeze-guard unit test.

3. Stale ESLint suppression

npm run lint:json -- --max-warnings 0 exits 2 with "There are suppressions left that do not occur anymore". Exactly one entry is stale — tests/unit/proxy-registry.test.ts, no-explicit-any 55 → 54. Regenerated with --prune-suppressions; that single count is the whole diff.

4. Inherited file-size growth

✗ src/lib/tokenHealthCheck.ts:                     843 > frozen 841
✗ src/app/(dashboard)/dashboard/providers/page.tsx: 1990 > frozen 1927

Both grew after the last rebaseline (_rebaseline_2026_07_25_v3849_basered_filesize, measured at 36f8fd10) and both came from already-merged PRs — #8426 (4528fc455) and #8349 (58ab8b1d2) — so there is no offending branch left to fix. Same situation and remedy as that entry and as _rebaseline_2026_07_02_5798_release_green; documented in a new _rebaseline_* key.

Commit 4 is deliberately last and self-contained — drop it if you would rather move the frozen values yourself. Structural reduction of the 1990-line providers page is not attempted here.

Deliberately NOT touched: the complexity ratchet

check:complexity-ratchets is also red on the pristine base:

complexity=2169           > baseline 2130
cognitiveComplexity=956   > baseline 951

Per c539d37b2 ("revert unauthorized ratchet rebaseline in #8306"), ratchet rebaselines are reserved for the release captain and the drift is tracked by #8254 / #8256. Left alone. Fast Quality Gates will stay red at that step until those land — the file-size step is simply no longer the thing that kills the job first.

Overlap with the open base-red slices

• fix(resilience,translator): release/v3.8.49 base-red regressions (slice 1) + eslint baseline #8254 also edits config/quality/eslint-suppressions.json (+7−2). Mine is a one-count prune of a different concern; trivially reconcilable either way. Its accountFallback / combo / reasoningPlaceholder fixes address failures that are no longer in the current red set.
• fix(compression): rank codex-responses engine in adaptive ladder maps (base-red slice 2) #8256 (ladder.ts) does not overlap at all.

Both are CONFLICTING right now, which is why the base is still red. Happy to fold this into either one instead if you prefer a single slice.

Verification

Measured before and after, same machine, same Node:

Gate	Base (30709255)	This branch
check:file-size	✗ 2 violations	✅ OK
check:db-rules	✗ 1 module	✅ OK (106 modules, 37 internal)
lint:json --max-warnings 0	✗ exit 2	✅ exit 0
error-classification + thundering-herd + check-db-rules	✗ 55 tests, 4 fail	✅ 55 tests, 0 fail
check:complexity-ratchets	✗ 2169/956	✗ 2169/956 (unchanged, out of scope)

prettier --check clean on all touched files. No production code is modified: the diff is 2 test files, 1 gate script allowlist entry, and 2 quality baselines.

[diegosouzapw]

Thanks for the thorough writeup, and for being upfront about the overlap — "happy to fold this into either one instead" made this much easier to evaluate.

I ran each of the four slices against the other open base-red PRs, on fresh worktrees off the pristine tip. Two of them decide what happens here.

Slice (a), check-db-rules / compressionDetailNormalizers — this one regresses a test. tests/unit/check-db-rules-classification.test.ts asserts an exact count of audited modules. Adding the allowlist entry without extending that test's expected array turns a currently-green test red:

tip puro:      pass 5, fail 0
with this PR:  AssertionError  actual: 37  expected: 36

#8534 makes the same allowlist change and updates the test, so this slice should come from there instead.

Slice (d), the file-size-baseline.json rebaseline — this one is yours alone, and it's the reason to keep this PR open. check:file-size is the first step of the Fast Quality Gates job, so while it's red every PR into the release branch is red regardless of content. It's failing on two files that were grown by already-merged PRs (providers/page.tsx 1927→1990 via #8349, tokenHealthCheck.ts 841→843 via #8426) — there is no offending branch left to fix. No other open PR covers those two files. Verified your slice closes it:

with this PR:  [file-size] OK — 182 arquivos congelados
               [test-file-size] OK

I want to be explicit about one thing, because an earlier read of this PR got it wrong: #8532 also touches page.tsx, but it targets 1918 — a value measured before #8349 landed — and it's being held for the release captain's rebaseline-at-release. So it does not cover this. Your slice (d) is currently the only open path to a green file-size gate.

The other two slices are duplicates: (b) is functionally identical to #8539's fix, and (c) is the same one-line 55 → 54 prune as #8544 (which, being the oldest carrier, is the one we're landing).

So the ask is a trim, not a close: drop slices (a), (b) and (c) — they're covered by #8534, #8539 and #8544 — and keep (d). That leaves a small, focused PR that unblocks the whole queue, and it avoids the test regression in (a).

Your root-causing here was accurate and genuinely useful; the note you wrote into the baseline file documenting why the growth was inherited and unattributable is exactly the right thing for the next person to find.

[diegosouzapw]

Following up on the review above — I went ahead and did the trim on this branch, since the file-size gate was blocking every open PR and your slice (d) was the only open fix for it.

What changed: your four commits became one. I cherry-picked 80fd8984d (chore(quality): rebaseline file-size for inherited base growth) onto the current release tip and dropped the other three, because they landed meanwhile through the PRs that carried them:

slice	now lands via
(a) check-db-rules allowlist	#8534 — which also updates the classification-count test, avoiding the 37 != 36 regression
(b) backoff Math.min assertions	#8539
(c) eslint-suppressions 55 → 54	#8544
(d) file-size-baseline.json rebaseline	this PR — yours

Your commit is untouched and still authored by you; nothing was rewritten, only the three now-redundant commits were left out. The PR is now a single commit, one file, +4/-3.

Verified on the trimmed branch against the current tip:

check:file-size                ✅ OK — 182 arquivos congelados
check:db-rules                 ✅ OK
check:mutation-test-coverage   ✅ OK
typecheck:core                 ✅ OK
lint                           ✅ OK

That is all four previously-red gates green — the base had been failing lint, check:file-size, check:db-rules and check:mutation-test-coverage simultaneously, and this is the last of them.

Thanks for the diagnosis on this one. The part that made the difference was documenting why the growth was inherited and had no offending branch left to fix — that note in the baseline file is what the next person needs to understand why the ceiling moved.