bugfix: handle negative deductions returned by evaluator

models.py

@@ -240,6 +240,13 @@ class Deductions(BaseModel):
     )
     reasons: str = Field(description="Reasons for deductions")
 
+    @field_validator("total", mode="before")
+    @classmethod
+    def normalize_total(cls, value):
+        if value is None:
+            return 0
+        return abs(float(value))
+
 
 class EvaluationData(BaseModel):
     scores: Scores

prompts/templates/resume_evaluation_criteria.jinja

@@ -161,6 +161,7 @@ You are evaluating a resume for a Software Intern position at HackerRank. Analyz
   - production: 0-25 points (maximum 25)
   - technical_skills: 0-10 points (maximum 10)
 - Bonus points total must be <= 20 (maximum 20 points)
+- Deductions total must be >= 0 and represent the deduction magnitude only (use `10`, not `-10`)
 - **OVERALL SCORE LIMIT**: The total score (categories + bonus - deductions) cannot exceed 120 points
 
 **DO NOT RETURN A RESUME SUMMARY. RETURN ONLY THE SCORING EVALUATION IN THE SPECIFIED JSON FORMAT.**
@@ -182,4 +183,4 @@ Analyze the following resume and provide a JSON response with this EXACT structu
 
 Resume to evaluate:
 
-{{ text_content }}
+{{ text_content }}

prompts/templates/resume_evaluation_system_message.jinja

@@ -44,6 +44,7 @@ CRITICAL: You MUST respond with the EXACT JSON structure specified in the prompt
   - technical_skills: 0-10 points (maximum 10)
 - Bonus points total must be <= 20 (maximum 20 points)
 - **CRITICAL**: The total bonus points cannot exceed 20 points under any circumstances
+- Deductions total must be >= 0 and represent the deduction magnitude only (use `10`, not `-10`)
 - **OVERALL SCORE LIMIT**: The total score (categories + bonus - deductions) cannot exceed 120 points
 
-IMPORTANT: Always check the structured 'profiles' section in the resume data before applying deductions for missing GitHub/portfolio. Only apply deductions if profiles are genuinely missing from the structured data. When GitHub data is provided in the resume text (look for '=== GITHUB DATA ===' section), thoroughly analyze the GitHub profile and repository information to enhance your evaluation of open source contributions and project quality. **CRITICAL**: Check the 'project_type' field in GitHub data - 'open_source' means multiple contributors, 'self_project' means single contributor. Self projects should receive low open source scores. When blog data is provided in the resume text (look for '=== BLOG DATA ===' section), analyze the technical blog posts, writing quality, topics covered, and frequency of posting to assess the candidate's technical communication skills and knowledge sharing abilities. High-quality technical blogs with regular posting and diverse technical topics should receive bonus points. IMPORTANT: Look for Google Summer of Code (GSoC), Girl Script Summer of Code, Outreachy, Season of Docs, or similar open source programs in the resume and award bonus points for participation in these prestigious programs. **CRITICAL PROJECT ASSESSMENT**: When evaluating projects, prioritize complexity and real-world impact over quantity. Simple tutorial projects should receive low scores and may trigger deductions. A single complex project is worth more than multiple simple ones. **CRITICAL FAIRNESS**: Ignore all personal demographic information, educational institution names, academic grades, and geographical location when scoring. Focus solely on technical skills, project quality, and professional experience. CRITICAL: You MUST respond with valid JSON that includes ALL required fields (candidate_name, scores, bonus_points, deductions, key_strengths, areas_for_improvement). The response must be valid JSON that matches the exact structure specified. Do not omit any fields or add extra fields. **CRITICAL FOR KEY STRENGTHS**: Only list "open source contributions" or "active open source projects" as key strengths if the candidate has made actual contributions to other people's projects (not just personal repositories). Personal GitHub repositories alone do not qualify as open source contributions. **MANDATORY**: If the evidence states "No evidence of significant open source contributions" or "no demonstrable open source activity beyond personal GitHub projects", then open source should NOT be listed as a key strength. 
+IMPORTANT: Always check the structured 'profiles' section in the resume data before applying deductions for missing GitHub/portfolio. Only apply deductions if profiles are genuinely missing from the structured data. When GitHub data is provided in the resume text (look for '=== GITHUB DATA ===' section), thoroughly analyze the GitHub profile and repository information to enhance your evaluation of open source contributions and project quality. **CRITICAL**: Check the 'project_type' field in GitHub data - 'open_source' means multiple contributors, 'self_project' means single contributor. Self projects should receive low open source scores. When blog data is provided in the resume text (look for '=== BLOG DATA ===' section), analyze the technical blog posts, writing quality, topics covered, and frequency of posting to assess the candidate's technical communication skills and knowledge sharing abilities. High-quality technical blogs with regular posting and diverse technical topics should receive bonus points. IMPORTANT: Look for Google Summer of Code (GSoC), Girl Script Summer of Code, Outreachy, Season of Docs, or similar open source programs in the resume and award bonus points for participation in these prestigious programs. **CRITICAL PROJECT ASSESSMENT**: When evaluating projects, prioritize complexity and real-world impact over quantity. Simple tutorial projects should receive low scores and may trigger deductions. A single complex project is worth more than multiple simple ones. **CRITICAL FAIRNESS**: Ignore all personal demographic information, educational institution names, academic grades, and geographical location when scoring. Focus solely on technical skills, project quality, and professional experience. CRITICAL: You MUST respond with valid JSON that includes ALL required fields (candidate_name, scores, bonus_points, deductions, key_strengths, areas_for_improvement). The response must be valid JSON that matches the exact structure specified. Do not omit any fields or add extra fields. **CRITICAL FOR KEY STRENGTHS**: Only list "open source contributions" or "active open source projects" as key strengths if the candidate has made actual contributions to other people's projects (not just personal repositories). Personal GitHub repositories alone do not qualify as open source contributions. **MANDATORY**: If the evidence states "No evidence of significant open source contributions" or "no demonstrable open source activity beyond personal GitHub projects", then open source should NOT be listed as a key strength. 

tests/models_test.py

@@ -0,0 +1,14 @@
+import unittest
+
+from models import Deductions
+
+
+class DeductionsTest(unittest.TestCase):
+    def test_total_is_normalized_to_positive(self):
+        deductions = Deductions(total=-10, reasons="Broken links")
+
+        self.assertEqual(deductions.total, 10.0)
+
+
+if __name__ == "__main__":
+    unittest.main()