Align CI business priority across node counts and model families

[cquil11]

Summary

• give Kimi K3 the same model-family adjustment as DSV4 and the other prioritized model families
• remove the per-additional-node score penalty so node-count remains capacity demand rather than business priority
• document that capacity-aware packing is owned by the dashboard scheduler

Validation

• python -m pytest utils/test_ci_priority.py -q (19 passed)

---

Note

Low Risk
Scoped CI scheduling policy and docs with unit test coverage; no auth, data, or production runtime paths.

Overview
CI business priority scores no longer depend on how many nodes a job requests, and Kimi K3 is scored like the other prioritized model families instead of getting a higher bump.

The additional-node policy knob and the calculate_priority term that subtracted 0.001 per extra node are removed, so node-count stays validated but does not move the numeric priority band. kimik3 in configs/ci-priority.yaml drops from 1.5 to 0.75, matching families such as dsv4. RUNNER_SETUP.md now states that node count is capacity demand and that the dashboard controller packs within each priority band. Tests are updated to assert equal Kimi K3 vs DSV4 scores and unchanged priority for 1/2/3 nodes.

^{Reviewed by Cursor Bugbot for commit 7086474. Bugbot is set up for automated code reviews on this repo. Configure here.}

[claude]

Looks good, straightforward config/logic change.

What was reviewed: the removal of the additional-node tiebreaker adjustment (config and calculate_priority in utils/ci_priority.py — node-count is still validated but no longer affects score), the kimik3 model-prefix weight change from 1.5 to 0.75 to match other models like dsv4, and the corresponding test and documentation updates. Confirmed no other references to additional-node remain in the repo, and the updated tests in utils/test_ci_priority.py match the new config values exactly.

Extended reasoning...

Overview

This PR touches four files in a self-contained CI priority-scoring subsystem: configs/ci-priority.yaml (removes the additional-node: -0.001 tiebreaker adjustment and lowers kimik3 model-prefix weight from 1.5 to 0.75), utils/ci_priority.py (removes the line that applied the additional-node adjustment to the score, while keeping node-count validation intact), utils/runner_setup/RUNNER_SETUP.md (updates prose to reflect that node count is no longer a priority signal), and utils/test_ci_priority.py (renames/rewrites tests to match: test_kimi_k3_and_dsv4_receive_the_same_model_priority, test_node_count_does_not_change_business_priority, test_node_count_validation_survives_classifier_projection).

Security risks

None. This is a pure scoring/priority-weighting change in an internal CI scheduling utility — no auth, crypto, external input parsing changes, or data exposure paths are touched.

Level of scrutiny

Low. The change is small, mechanical, and fully self-consistent: the code change (removing the score += ... additional-node ... line) matches the config change (removing the additional-node key) and the doc change (updated paragraph in RUNNER_SETUP.md), and the test file was updated to reflect the new expected values. I verified there are no other references to additional-node left anywhere in the repo, and cross-checked that the dsv4 weight in the config (0.75) matches the new kimik3 weight, consistent with the new test asserting they're equal.

Other factors

Test coverage is solid and was updated in lockstep with the behavior change: node-count validation (rejecting non-positive/non-int/bool values) is preserved and still tested even though the tiebreaker score effect is gone. I was not able to execute the test suite directly (bash test execution was denied in this sandbox), but manual tracing of calculate_priority confirms the logic matches the new test expectations.