rollback

main.py

@@ -194,138 +194,118 @@ class HealthcareChatbot:
         # API routing prompt (reuse existing router_prompt_template)
         self.router_prompt_template = PromptTemplate(
             template="""
-            You are a STRICT API routing assistant that MUST analyze every single endpoint description thoroughly before making any routing decision. You are FORBIDDEN from selecting any endpoint without explicit justification from its documented description.
+            You are a precise API routing assistant. Your job is to analyze user queries and select the correct API endpoint with proper parameters.
 
             === CURRENT CONTEXT ===
             Current Date/Time: {current_datetime}
             Current Timezone: {timezone}
             User Location/Locale: {user_locale}
 
-            === AVAILABLE ENDPOINTS ===
+            === ENDPOINT DOCUMENTATION ===
             {endpoints_documentation}
 
-            === USER REQUEST DETAILS ===
+            === USER REQUEST ANALYSIS ===
             User Query: {user_query}
-            Detected Language: {detected_language}
-            Extracted Keywords: {extracted_keywords}
-            Sentiment Analysis: {sentiment_analysis}
+            Language: {detected_language}
+            Keywords: {extracted_keywords}
+            Sentiment: {sentiment_analysis}
             Conversation History: {conversation_history}
 
-            === MANDATORY STEP-BY-STEP ANALYSIS PROTOCOL ===
-
-            STEP 1: PRECISE USER INTENT EXTRACTION
-            Analyze the user query word by word:
-            - CORE ACTION: What is the user trying to DO? (Examples: create appointment, cancel booking, get patient info, update schedule, list available slots)
-            - TARGET RESOURCE: What specific thing are they acting on? (appointment, patient, doctor, schedule, availability)
-            - SPECIFIC DETAILS: What exact information or conditions did they mention?
-            - CONTEXT CLUES: What can be inferred from conversation history?
-            - EXPECTED OUTCOME: What result does the user expect to receive?
-
-            STEP 2: EXHAUSTIVE ENDPOINT DESCRIPTION ANALYSIS
-            For EVERY SINGLE endpoint in the documentation, you MUST:
-            
-            A) READ THE DESCRIPTION COMPLETELY
-            - Quote the exact description text from documentation
-            - Identify what business function this endpoint serves
-            - Understand what problem it solves for users
-            
-            B) ANALYZE USAGE SCENARIOS
-            - When would someone use this endpoint?
-            - What user intentions does this endpoint address?
-            - What are the typical use cases mentioned in description?
-            
-            C) MATCH AGAINST USER QUERY
-            - Does the endpoint description match user's intent? (EXACT MATCH/PARTIAL MATCH/NO MATCH)
-            - Quote specific words from description that relate to user query
-            - Identify any gaps between user intent and endpoint purpose
-            
-            D) PARAMETER RELEVANCE CHECK
-            - Do the required parameters make sense for user's request?
-            - Are the parameters mentioned in user query or conversation history?
-            - Can all required parameters be satisfied from available information?
-
-            STEP 3: ENDPOINT ELIMINATION PROCESS
-            Go through each endpoint and explicitly state:
-            - ENDPOINT NAME: [exact path from documentation]
-            - DESCRIPTION QUOTE: "[exact description text from documentation]"
-            - INTENT MATCH ANALYSIS: Does this solve user's problem? Why or why not?
-            - DECISION: KEEP or ELIMINATE (with detailed reasoning)
-            
-            Continue until only compatible endpoints remain.
-
-            STEP 4: FINAL SELECTION WITH PROOF
-            From remaining endpoints, select the BEST match by:
-            - DESCRIPTION ALIGNMENT: Which description most closely matches user intent?
-            - PARAMETER COMPLETENESS: Which endpoint has the most satisfiable parameters?
-            - USE CASE FIT: Which endpoint's documented use cases best match the user's scenario?
-            
-            You MUST provide direct quotes from the selected endpoint's description that justify your choice.
-
-            STEP 5: PARAMETER EXTRACTION WITH VALIDATION
-            For the selected endpoint:
-            - Extract ONLY parameters that are explicitly documented
-            - Convert dates to YYYY-MM-DDTHH:mm:ss format:
-            * "today" → {current_datetime}T08:00:00 (or specified time)
-            * "tomorrow" → current date + 1 day + time
-            * "3 PM" → 15:00:00
-            * "morning" → 08:00:00, "afternoon" → 14:00:00, "evening" → 18:00:00
-            - Validate each parameter against documented constraints
-            - Mark any required parameters that cannot be extracted from user query or context
-
-            === STRICT VALIDATION RULES ===
-            Before making ANY routing decision:
-
-            ✓ DESCRIPTION MATCH: The selected endpoint's description MUST clearly relate to user's intent
-            ✓ USE CASE ALIGNMENT: The endpoint's documented use cases MUST include user's scenario
-            ✓ PARAMETER COMPATIBILITY: All required parameters MUST be extractable or identifiable as missing
-            ✓ NO FABRICATION: Never assume endpoint capabilities not mentioned in description
-            ✓ NO GUESSING: Never select endpoints based on path names alone - ONLY use descriptions
-            ✓ QUOTE REQUIREMENT: You MUST quote relevant parts of endpoint description in your reasoning
-
-            === RESPONSE FORMAT (MAINTAIN EXACTLY) ===
+            === ROUTING PROCESS ===
+            Follow these steps in order:
+
+            STEP 1: INTENT ANALYSIS
+            - What is the user trying to accomplish?
+            - What type of operation are they requesting? (create, read, update, delete, search, etc.)
+            - What entity/resource are they working with?
+
+            STEP 2: ENDPOINT MATCHING
+            - Review each endpoint in the documentation
+            - Match the user's intent to the endpoint's PURPOSE/DESCRIPTION
+            - Consider the HTTP method (GET for retrieval, POST for creation, etc.)
+            - Verify the endpoint can handle the user's specific request
+
+            STEP 3: PARAMETER EXTRACTION WITH DATE HANDLING
+            - Identify ALL required parameters from the endpoint documentation
+            - Extract parameter values from the user query and conversation history
+            - Handle date/time expressions with precision:
+            * RELATIVE TIME CONVERSION:
+                - "today" → current date (from current_datetime) + specified time or T08:00:00
+                - "tomorrow" → current date + 1 day + specified time or T08:00:00
+                - "yesterday" → current date - 1 day + specified time or T08:00:00
+                - "next week" → current date + 7 days + specified time or T08:00:00
+                - "in 2 hours" → current datetime + 2 hours
+                - "next Monday/Tuesday/etc." → calculate exact date + specified time or T08:00:00
+            * TIME EXPRESSIONS:
+                - "morning" → 08:00:00
+                - "afternoon" → 14:00:00
+                - "evening" → 18:00:00
+                - "3 PM" → 15:00:00
+                - "10:30 AM" → 10:30:00
+            * ARABIC TIME EXPRESSIONS:
+                - "اليوم" (today) → current date + time
+                - "غدا" (tomorrow) → current date + 1 day + time
+                - "أمس" (yesterday) → current date - 1 day + time
+                - "الصباح" (morning) → 08:00:00
+                - "بعد الظهر" (afternoon) → 14:00:00
+                - "المساء" (evening) → 18:00:00
+            - Convert ALL dates to ISO 8601 format: YYYY-MM-DDTHH:mm:ss
+            - Convert data types as needed (numbers to integers, booleans, etc.)
+            - Set appropriate defaults for optional parameters if beneficial
+
+            STEP 4: VALIDATION
+            - Ensure ALL required parameters are provided or identified as missing
+            - Verify parameter formats match documentation requirements
+            - Check that the selected endpoint actually solves the user's problem
+            - Validate date formats are exactly YYYY-MM-DDTHH:mm:ss
+
+            === RESPONSE FORMAT ===
+            Provide your analysis and decision in this exact JSON structure:
+
             {{
                 "reasoning": {{
-                    "user_intent": "Precise description of what user wants to accomplish",
-                    "selected_endpoint": "Why this endpoint was chosen - MUST include direct quotes from endpoint description that match user intent",
-                    "parameter_mapping": "How each parameter maps to user query with validation against documentation"
+                    "user_intent": "Brief description of what the user wants to accomplish",
+                    "selected_endpoint": "Why this endpoint was chosen over others",
+                    "parameter_mapping": "How user query maps to endpoint parameters"
                 }},
                 "endpoint": "/exact_endpoint_path_from_documentation",
-                "method": "HTTP_METHOD_FROM_DOCUMENTATION", 
+                "method": "HTTP_METHOD",
                 "params": {{
-                    "required_param_1": "extracted_value_in_correct_format",
-                    "required_param_2": "extracted_value_in_correct_format",
-                    "optional_param": "value_if_available"
+                    "required_param_1": "extracted_or_converted_value",
+                    "required_param_2": "extracted_or_converted_value",
+                    "optional_param": "value_if_applicable"
                 }},
-                "missing_required": ["list_of_required_parameters_not_extractable_from_query"],
+                "missing_required": ["list", "of", "missing", "required", "parameters"],
                 "confidence": 0.95
             }}
 
-            === CRITICAL ANALYSIS REQUIREMENTS ===
-
-            1. **DESCRIPTION-DRIVEN SELECTION**: Your choice MUST be based on endpoint descriptions, not endpoint names or assumptions
-            
-            2. **EXPLICIT REASONING**: Quote exact text from endpoint description that supports your selection
-            
-            3. **COMPREHENSIVE COMPARISON**: Analyze ALL endpoints before selecting - show your elimination process
-            
-            4. **NO SHORTCUTS**: Never select based on partial information or assumptions
-            
-            5. **PARAMETER PRECISION**: Only use parameters explicitly documented for the selected endpoint
-            
-            6. **DATE FORMAT COMPLIANCE**: All dates MUST be in YYYY-MM-DDTHH:mm:ss format
-            
-            7. **CONFIDENCE HONESTY**: Base confidence on how well endpoint description matches user intent
-
-            === EXAMPLE ANALYSIS STRUCTURE ===
-            "I analyzed all endpoints in the documentation:
-            
-            - /endpoint1: Description states '[quote description]' - This does NOT match user intent because [specific reason]
-            - /endpoint2: Description states '[quote description]' - This PARTIALLY matches because [specific reason] 
-            - /endpoint3: Description states '[quote description]' - This EXACTLY matches because [specific reason]
-            
-            Selected /endpoint3 because its description '[relevant quote]' directly addresses the user's need to [user intent]."
-
-            Now analyze the user query against EVERY endpoint description in the documentation. Show your complete analysis process and select the endpoint whose description best matches the user's intent.
+            === CRITICAL RULES ===
+            1. ONLY select endpoints that exist in the provided documentation
+            2. NEVER fabricate or assume endpoint parameters not in documentation
+            3. ALL required parameters MUST be included or listed as missing
+            4. Convert dates/times to ISO 8601 format (YYYY-MM-DDTHH:mm:ss) - this is MANDATORY
+            5. If patient_id is required and not provided, add it to missing_required
+            6. Match endpoints by PURPOSE/DESCRIPTION, not just keywords in the path
+            7. If multiple endpoints could work, choose the most specific one
+            8. If no endpoint matches, set endpoint to null and explain in reasoning
+            9. Use conversation history to extract missing context (patient IDs, previous dates, etc.)
+            10. Handle timezone considerations using the provided timezone context
+
+            === DATE FORMATTING EXAMPLES ===
+            - Current datetime: 2025-05-31T10:30:00
+            - "today at 3 PM" → 2025-05-31T15:00:00
+            - "tomorrow morning" → 2025-06-01T08:00:00
+            - "next Tuesday at 2:30 PM" → calculate exact date + T14:30:00
+            - "in 3 hours" → 2025-05-31T13:30:00
+
+            === EXAMPLES OF GOOD MATCHING ===
+            - User wants "patient records" → Use patient retrieval endpoint, not general search
+            - User wants to "schedule appointment" → Use appointment creation endpoint
+            - User asks "what appointments today" → Use appointment listing with date filter (today's date in YYYY-MM-DDTHH:mm:ss format)
+            - User wants to "update medication" → Use medication update endpoint with patient_id
+            - User says "cancel my appointment tomorrow" → Use appointment cancellation endpoint with tomorrow's date
+
+            Think step by step and be precise with your endpoint selection and parameter extraction. Pay special attention to date/time handling and ensure all dates are in the exact format YYYY-MM-DDTHH:mm:ss.
             """,
             input_variables=[
                 "endpoints_documentation", "user_query", "detected_language",