fix: normalize default weights to sum to 1.0 instead of 1.15

[ayushi2577]

fixes issue - #116

Problem

The default _weights in scorer.py summed to 1.15 instead of 1.0,
inflating scores near the flag (0.25) and throttle (0.55) thresholds.
The min(total, 1.0) clamp hid the issue for high scores but silently
caused overly aggressive verdicts for borderline requests.

Also, the ConfigSnapshot override path only replaced payload, behavior,
and identity weights — leaving context and ip_rep at inflated defaults.

Fix

• Normalized _weights so they sum exactly to 1.0
• Added normalization in the ConfigSnapshot override path

Fixes #128

[Wahid7852]

Overall though, the bug and the reasoning behind the fix look legitimate but hey, can you please check these reviews out and just do a minor tweaks in your changes. The more tests and secure the code, the better it is, right?

[Wahid7852]

🕵🏼 was it AI and your AI messed it up? lol

[ayushi-ag-25]

well i got confused in the issue numbers and for the test part i will do it soon and would be back with results

[ayushi2577]

Hey @Wahid7852 ,
I went through all your comments and made the changes:

1. Added validation in the snap path for negative weights and zero sum — both raise ValueError now
2. Added test_negative_weight_raises and test_all_zero_weights_raises as the safeguards you suggested
3. Added test_identity_heavy_detection to confirm identity-heavy signals still work after the weight drop
4. Switched assertions to pytest.approx(rel=1e-3) as you suggested
5. Updated the command probe threshold since the score naturally changed after normalization — not a regression

for the testing part below are the screenshots

Also, honestly the zero-sum edge case was a good catch, I hadn't thought about what happens when someone passes all zeros through config, that could've been a silent bug for a while

[ayushi2577]

@Wahid7852, i went through all your comments and basically i have added validation for negative and zero-sum weights (both raise ValueError now), added the three tests you suggested, switched assertions to pytest.approx, and verified identity-heavy detections still work fine after the weight drop. Should be good to go! i have also attached the screenshots of tests in my last comment on pr

[Wahid7852]

hey @ayushi2577 the validation and tests look good, before we merge, total_snap == 0 should be <= 0 to also catch edge cases where the sum is negative, and test_identity_heavy_detection uses score > 0.15 but the normalized identity weight is exactly 0.15 so that assertion would fail a correct result, needs to be tightened up.

[Wahid7852]

^

[ayushi2577]

Fixed both
Changed == 0 to <= 0 to also catch negative sum edge cases, and tightened the identity test to pytest.approx(0.20, rel=1e-3) and pytest.approx(0.15, rel=1e-3) for the breakdown. Thanks for the sharp catch!

[ayushi2577]

you can review it now as I have done all requested changes

[ayushi2577]

Resaved as plain UTF-8

[Wahid7852]

final changes. promise.

[ayushi2577]

Done, I have updated the error message to say 'snap weights', added the assert for the default path, and added a comment explaining why context and ip_rep aren't validated.

[Wahid7852]

@0-Shimanshu LGTM

[0-Shimanshu]

@0-Shimanshu LGTM

i will do it after i check one thing
because i closed one other pr for this same issue

[ayushi2577]

@0-Shimanshu I request to review and merge it

[ayushi2577]

@Wahid7852 and @0-Shimanshu
I expect there are no other changes needed can u review and merge it?

[0-Shimanshu]

@ayushi2577 did you check the normalising function ?
i think i had a normalising function to make sum to 1 even if it exceeds/.

[ayushi2577]

Yeah I checked ,
the original code only had normalization in the snap override path (if total_w > 0), but the default _weights dict itself was never normalized and summed to 1.15. My fix normalizes _weights at module load time so the default path is also always exactly 1.0.

[Wahid7852]

@0-Shimanshu merge?

[0-Shimanshu]

@0-Shimanshu merge?

kinda confused about this cause decreasing value is not the right way to go i think here
because there possibilty user introduce new signal so new weight then same problem then also will come i think