[Dingding-leo]

Summary

Fixes #8777.

Adds maxContextWindow support to contextRequirements in combo target filtering and validation schemas.

Changes

• Validation Schema: Added maxContextWindow (number between 0 and 10,000,000) to comboRuntimeConfigSchema in src/shared/validation/schemas/combo.ts and DEFAULT_COMBO_CONFIG in open-sse/services/comboConfig.ts.
• Target Filtering: Updated applyContextRequirements in open-sse/services/combo/contextRequirements.ts to filter out targets with context windows exceeding maxContextWindow. Respects contextFilterMode (strict excludes models with unknown limits, lenient includes them).
• Tests: Added unit & integration test coverage in tests/unit/combo-context-requirements.test.ts and tests/unit/combo/context-requirements-integration.test.ts.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[diegosouzapw]

Heads-up: this PR is running against a stale base

release/v3.8.49 has moved 93 commits ahead of the base this PR was last built against, and several gate failures that were red on the older base have since been repaired on the branch itself:

Gate class	Repaired by
No new ESLint warnings (exit 2 — orphaned suppressions, not a lint violation)	#8706, #8831
Fast Quality Gates / check:file-size / Quality Ratchet	#8585, #8767, plus the post-merge-train re-pins
Docs Gates (fast-path) (missing Polish API_REFERENCE)	#8831
backoff-clamp + compressionDetailNormalizers unit tests	#8706

I verified this on a clean checkout of the current tip (3b515d90b3): lint:json --max-warnings 0, check:file-size, check:docs-sync, error-classification.test.ts (24/24) and check-db-rules.test.ts (22/22) all pass with no changes.

Currently failing here:

• Fast Quality Gates

Please update the branch (the Update branch button, or rebase onto origin/release/v3.8.49) and let CI re-run. That should clear any failure caused by the stale base.

Note this is not a promise that every red disappears — a failure specific to the changes in this PR will survive the rebase, and Build (advisory) is advisory and does not block. Rebasing just removes the noise so what is left is actually yours.

No action was taken on this PR beyond this comment.

[diegosouzapw]

Re-homed to release/v3.8.50: v3.8.49 entered its release freeze, so the branch now belongs to the release captain and development continues on the next cycle. Nothing is wrong with this PR — it just needed a live base. No action needed from you; CI will re-run against the new base.

[diegosouzapw]

Heads-up on the issue reference, not on the change itself: this PR says it fixes #8777, but #8777 is about FITNESS_TABLE rot in open-sse/services/autoCombo/taskFitness.ts (dead rows, version-less family patterns, short-pattern collisions). This diff adds maxContextWindow to contextRequirements (open-sse/services/combo/contextRequirements.ts, comboConfig.ts, schemas/combo.ts) and never touches taskFitness.ts — a different subsystem, so it looks like a wrong issue number.

The change itself looks fine and stands on its own; could you update the reference to the issue it actually addresses (or drop the fixes line)? Left as-is, merging this would auto-close #8777 while the fitness-table problem is still open.

For context: I re-triaged #8777 today and confirmed two of its defects with a reproduction test — getStaticFitnessTableScore("solar-pro3") returns 0.95 because the bare o3 pattern matches by substring, and minimax-m2.7 scores below its older sibling minimax-m2.5. So that issue does need its own fix.