mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-01 04:42:10 +03:00
0bbdb839d9
* fix(inspector): report effective auto scoring weights * fix(inspector): check options.combos before the health-signal short-circuit resolveConfiguredCombos() returned [] unconditionally whenever healthResponse, forecastResponse, and either skipAutopilot or autopilotReport were all supplied -- before it ever looked at options.combos. That is exactly the call shape comboHealthDashboard.ts::buildComboHealthDashboardResponse() always uses (it resolves combos/health/forecast/autopilot once, then passes all of them into buildComboScoringInspectorResponse together), so through the real dashboard integration the caller-supplied combos were silently discarded every time. Since combosById/combosByName (built from resolveConfiguredCombos()'s return value) are what resolveInspectorWeights() uses to report a combo's actual configured modePack/weights, this meant the dashboard's weightSource/modePack fields always came back "default", even for a combo with an explicit mode pack configured. Check options.combos first, unconditionally, and only fall back to the health-signals short-circuit (skip an unnecessary getCombos() DB round-trip) or a fresh getCombos() call when the caller didn't supply combos at all. Adds a regression test that drives the real buildComboHealthDashboardResponse() end-to-end with a combo configured for modePack "ship-fast", proving the inspector now reports the correct weightSource/modePack through that call path -- the exact scenario the PR's own tests didn't cover (they only exercised buildComboScoringInspectorResponse() directly with comboId+combos, never combos alongside a pre-resolved healthResponse+forecastResponse). Also reconciles the existing "skipAutopilot avoids rebuilding autopilot report" test: it asserted options.combos was never even read in this scenario via a throwing property getter, which pinned the exact short-circuit-wins-always bug this fix removes. The test's options object never supplied a real combos array in the first place, so the fixed code still takes the same DB-free path -- only the poison-pill mechanism (which trapped a mere property read rather than an actual getCombos() call) no longer applies. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> * refactor(usage): split resolveInspectorWeights below complexity gate resolveInspectorWeights had cyclomatic complexity 16 (gate max is 15). Extract the auto-config precedence resolution (autoConfig -> config.auto -> config -> {}), the mode-pack name lookup, and the explicit-weights validation into small pure helpers, each returning early instead of nesting ternaries. Behavior is unchanged, including the fallback warning that fires when a mode pack or explicit weights were configured but could not be resolved. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>