fix(quality): let --update remove baseline entries that already fit the cap

[MumuTW]

Fixes the --update gap reported in #8584. Two files: the gate script and its unit tests. No baseline data change.

The bug

check:file-size --update deletes a baseline entry only from inside the improvement branch:

if (violations.length === 0 && improvements.length) {
  for (const [file, loc] of improvements) {      // improvements = loc < frozen[file]
    if (loc <= cap) delete frozen[file];
    else frozen[file] = loc;
  }
}

improvements requires loc < frozen[file]. So an entry sitting at exactly its frozen value, while already within the 800-line new-file cap, never reaches the delete — it is not a violation, not an improvement, and there is no third branch. It stays in the baseline permanently no matter how far under the cap it is.

Three real cases on release/v3.8.49 @ 4053e2314 survived a full --update run for exactly this reason:

entry	LOC	frozen	new-file cap
…/providers/[id]/ProviderDetailPageClient.tsx	798	798	800
…/providers/[id]/hooks/useProviderModels.ts	155	155	800
…/providers/[id]/hooks/useProviderSettings.ts	264	264	800

A 155-line file cannot leave a baseline whose purpose is to track files over 800 lines.

The fix

evaluateFileSizes now returns a third bucket, redundant — entries that are in frozen, are neither a violation nor an improvement, and satisfy loc <= cap:

if (loc > frozen[file]) violations.push(…);
else if (loc < frozen[file]) improvements.push([file, loc]);
else if (loc <= cap) redundant.push(file);        // ← new

The --update path deletes those alongside the shrinks, and the same treatment is applied to the testFrozen/testCap half, which had the identical gap.

The non-update gate path is untouched. redundant entries were already passing and still pass — no PR's pass/fail result changes anywhere. Only --update behaves differently, and only by removing entries that had become meaningless.

TDD

7 new tests written first and confirmed failing, then the fix:

before:  # tests 16 / # pass 9 / # fail 7
after:   # tests 16 / # pass 16 / # fail 0

The 9 pre-existing tests pass unchanged throughout. The new cases pin the boundaries rather than just the happy path:

• at baseline and within cap → redundant
• at baseline but still over cap → not redundant (must stay frozen)
• exactly at the cap → redundant (cap is inclusive, matching loc > cap for new files)
• shrank → stays an improvement, not double-counted as redundant
• grew → violation, never redundant
• the three real #8584 entries above, asserted by path
• the test-file path (testFrozen/testCap) too

End-to-end verification

Running --update against the real baseline with the fix applied:

[file-size] baseline ratcheado: 74 arquivo(s) encolheram, 3 entrada(s) redundante(s) removida(s)

17 entries removed instead of 14, 0 caps raised, and all three residual entries confirmed gone by diffing the pre/post JSON key-by-key.

That baseline diff is deliberately not in this commit — banking the data is #8585's job, and mixing a logic change with 145 lines of JSON churn would make both harder to review.

Interaction with #8585

Independent, different files, no conflict, either merge order works:

• chore(quality): bank completed file-size shrinks (shrink-only --update on current tip) #8585 first → its diff was produced by the current script, so the 3 residual entries survive it; they go on the next --update run once this lands.
• this first → chore(quality): bank completed file-size shrinks (shrink-only --update on current tip) #8585's diff still applies unchanged; the 3 go on the next run either way.

Neither is blocking the other. Both are green-before-green-after — no base-red is being repaired here.

Scope note

I did not touch check-complexity-ratchets.mjs. It has no frozen map and no per-file removal concept — it ratchets two scalar counts — so this class of bug doesn't exist there.

Refs #8584

[diegosouzapw]

Hi @MumuTW — closing this in favor of #8657, which carries the same cli-backup-sync SKILL regeneration with the --status flag removed. The two diffs overlap on skills/cli-backup-sync/SKILL.md, so merging both is not viable; #8657 is the keep. Closing as superseded.

[diegosouzapw]

Superseded by #8657 (same SKILL regeneration).

[diegosouzapw]

@MumuTW — Desculpas, fechei este PR por engano durante uma rodada de review-prs (eu tinha metadata stale e o confundi com outro PR seu, o #8657, que de fato regenera cli-backup-sync SKILL.md). Seus dois PRs (#8589 e #8657) tratam de coisas distintas e não têm conflito — este aqui é fix(quality): let --update remove baseline entries that already fit the cap, que parece valioso (fecha o gap #8584 de entradas stuck-as-at-cap).

Você prefere:

• (A) Eu reabri-lo e rolar a revisão de verdade (leio o diff direito e posto o feedback correto); ou
• (B) Você abre um PR novo com base nele (git diff origin/release/v3.8.49..gh pr/8589 > /tmp.patch + reabrir)?

Por favor responda se quiser prosseguir. O fechamento foi meu erro de orquestração — o PR em si continua válido.

[diegosouzapw]

@MumuTW — re: my earlier comment apologizing for mistakenly closing this PR (the orchestration round read stale metadata and conflated #8589 with #8657). On re-reading the diff, this is a clean, focused fix: check:file-size --update now removes baseline entries that already fit the new cap (closes #8584). Approved as merge-ready (★3).

/merge-prs will pick it up once you're comfortable reopening — or you can git push the same branch to a fresh PR since the head is unchanged. Apologies again for the churn.

[MumuTW]

@diegosouzapw Reopen was blocked for this account after the head branch was temporarily missing (API: Could not open the pull request). The same head (MumuTW:fix/file-size-update-cannot-remove-at-cap @ 75b9382fbe) is now open again as replacement #8741.

Please treat #8741 as the continue-from for the ★3 merge-ready verdict on this PR. Closing this one as superseded by #8741 is fine.