chore: Remove .hypothesis and .kiro/specs from git tracking

- Removed .hypothesis/ directory (Hypothesis testing cache)
- Removed .kiro/specs/ directory (Kiro IDE specifications)
- Updated .gitignore to exclude these directories
- These are development/IDE artifacts and should not be in version control

.gitignore

@@ -58,8 +58,13 @@ Thumbs.db
 gradio_cached_examples/
 flagged/
 .gradio/
+
+# Kiro IDE
 .kiro/
 
+# Hypothesis testing
+.hypothesis/
+
 # Logs
 *.log
 *.backup

.hypothesis/constants/04f49bc462f957f1

@@ -1,4 +0,0 @@
-# file: /Users/serhiizabolotnii/Medical Brain/Lifestyle/src/core/spiritual_monitor.py
-# hypothesis_version: 6.148.7
-
-[0.5, 0.6, 0.7, 1.0, 'LLM classification', '\\{[^{}]*\\}', 'afterlife', 'anxious', 'better off dead', "can't cope", "can't go on", 'classification_error', 'confidence', 'death', 'depressed', 'died', 'end it all', 'end my life', 'faith', 'give up', 'god', 'green', 'grief', 'guilt', 'hopeless', 'indicators', 'kill myself', 'lonely', 'loss', 'meaning', 'miss them', 'mourning', 'no hope', 'no reason to live', 'nothing matters', 'overwhelmed', 'parse_error', 'pray', 'purpose', 'reasoning', 'red', 'sad', 'scared', 'sin', 'soul', 'spiritual', 'state', 'stressed', 'struggling', 'suicidal', 'suicide', 'want to die', 'want to disappear', 'why me', 'wish i was dead', 'worried', 'yellow', 'безнадія', 'бог', 'важко', 'все безглуздо', 'втрата', 'віра', 'горе', 'гріх', 'депресія', 'духовний', 'душа', 'краще б мене не було', 'краще б я помер', 'мета', 'молитва', 'не справляюсь', 'не хочу жити', 'немає надії', 'немає сенсу жити', 'нічого не має сенсу', 'перевантажений', 'покінчити з життям', 'помер', 'провина', 'самогубство', 'самотньо', 'сенс', 'скучаю', 'смерть', 'страшно', 'стрес', 'сумно', 'сумую', 'тривога', 'хвилююсь', 'хочу зникнути', 'хочу померти', 'чому я']

.hypothesis/constants/0b9f3a55b4876112

@@ -1,4 +0,0 @@
-# file: /Users/serhiizabolotnii/Medical Brain/Lifestyle/src/config/ai_providers_config.py
-# hypothesis_version: 6.148.7
-
-[0.1, 0.2, 0.3, 20000, '   ⚠️ Warnings:', '=', 'ANTHROPIC_API_KEY', 'EntryClassifier', 'GEMINI_API_KEY', 'MedicalAssistant', 'SoftMedicalTriage', 'TriageExitClassifier', '__main__', 'agent_status', 'anthropic', 'api_key_env', 'available', 'available_models', 'available_providers', 'default_model', 'default_temperature', 'errors', 'fallback_model', 'fallback_needed', 'fallback_provider', 'gemini', 'gemini-1.5-pro', 'gemini-2.0-flash', 'gemini-2.5-flash', 'gemini-2.5-pro', 'max_tokens', 'model', 'provider', 'reasoning', 'temperature', 'valid', 'warnings', '✅', '✅ Configured', '❌']

.hypothesis/constants/0f17f7a03d42626e

@@ -1,4 +0,0 @@
-# file: /Users/serhiizabolotnii/Medical Brain/Lifestyle/src/core/soft_triage_manager.py
-# hypothesis_version: 6.148.7
-
-['\nPatient responses:', '\nPrevious exchanges:', 'English', 'LLM evaluation', 'Ukrainian', '\\{[^{}]*\\}', '^["\\\']|["\\\']$', 'better', 'continue', 'coping', 'escalate_red', 'family', 'fine', 'friends', 'okay', 'outcome', 'reasoning', 'resolved_green', 'support', 'добре', 'друзі', 'краще', 'підтримка', 'справляюсь', "сім'я"]

.hypothesis/constants/2b5f16015407c587

@@ -1,4 +0,0 @@
-# file: /Users/serhiizabolotnii/Medical Brain/Lifestyle/src/core/spiritual_monitor.py
-# hypothesis_version: 6.148.7
-
-[0.5, 0.6, 0.7, 1.0, 'LLM classification', '\\{[^{}]*\\}', 'afterlife', 'anxious', 'better off dead', "can't cope", "can't go on", 'classification_error', 'confidence', 'death', 'depressed', 'died', 'end it all', 'end my life', 'faith', 'give up', 'god', 'green', 'grief', 'guilt', 'hopeless', 'indicators', 'kill myself', 'lonely', 'loss', 'meaning', 'miss them', 'mourning', 'no hope', 'no reason to live', 'nothing matters', 'overwhelmed', 'parse_error', 'pray', 'purpose', 'reasoning', 'red', 'sad', 'scared', 'sin', 'soul', 'spiritual', 'state', 'stressed', 'struggling', 'suicidal', 'suicide', 'want to die', 'want to disappear', 'why me', 'wish i was dead', 'worried', 'yellow', 'безнадія', 'бог', 'важко', 'все безглуздо', 'втрата', 'віра', 'горе', 'гріх', 'депресія', 'духовний', 'душа', 'краще б мене не було', 'краще б я помер', 'мета', 'молитва', 'не справляюсь', 'не хочу жити', 'немає надії', 'немає сенсу жити', 'нічого не має сенсу', 'перевантажений', 'покінчити з життям', 'помер', 'провина', 'самогубство', 'самотньо', 'сенс', 'скучаю', 'смерть', 'страшно', 'стрес', 'сумно', 'сумую', 'тривога', 'хвилююсь', 'хочу зникнути', 'хочу померти', 'чому я']

.hypothesis/constants/549af1221fd95a0e

@@ -1,4 +0,0 @@
-# file: /Users/serhiizabolotnii/Medical Brain/Lifestyle/src/core/ai_client.py
-# hypothesis_version: 6.148.7
-
-[0.0, 0.3, 20000, ' AI Client Test', '%Y-%m-%d %H:%M:%S', '=', 'ANTHROPIC_API_KEY', 'DefaultAgent', 'EntryClassifier', 'GEMINI_API_KEY', 'LOG_PROMPTS', 'MedicalAssistant', 'TEST', '__main__', 'active_model', 'active_provider', 'agent_name', 'ai_interactions.log', 'call_count', 'client_info', 'configured_model', 'configured_provider', 'content', 'default_model', 'false', 'get_client_info', 'last_error', 'model', 'performance_metrics', 'provider', 'reasoning', 'role', 'successful_calls', 'system_instruction', 'temperature', 'text', 'thinking_config', 'total_calls', 'total_response_time', 'true', 'type', 'user', 'using_fallback', 'utf-8']

.hypothesis/constants/55e855e82cd0f81e

@@ -1,4 +0,0 @@
-# file: /Users/serhiizabolotnii/Medical Brain/Lifestyle/src/core/soft_triage_manager.py
-# hypothesis_version: 6.148.7
-
-['\nPatient responses:', '\nPrevious exchanges:', 'English', 'LLM evaluation', 'Ukrainian', '\\{[^{}]*\\}', '^["\\\']|["\\\']$', 'better', 'continue', 'coping', 'escalate_red', 'family', 'fine', 'friends', 'okay', 'outcome', 'reasoning', 'resolved_green', 'support', 'добре', 'друзі', 'краще', 'підтримка', 'справляюсь', "сім'я"]

.hypothesis/constants/6845c48c4c9aae99

@@ -1,4 +0,0 @@
-# file: /Users/serhiizabolotnii/Medical Brain/Lifestyle/src/config/ai_providers_config.py
-# hypothesis_version: 6.148.7
-
-[0.1, 0.2, 0.3, 20000, '   ⚠️ Warnings:', '=', 'ANTHROPIC_API_KEY', 'EntryClassifier', 'GEMINI_API_KEY', 'MedicalAssistant', 'SoftMedicalTriage', 'TriageExitClassifier', '__main__', 'agent_status', 'anthropic', 'api_key_env', 'available', 'available_models', 'available_providers', 'default_model', 'default_temperature', 'errors', 'fallback_model', 'fallback_needed', 'fallback_provider', 'gemini', 'gemini-2.0-flash', 'gemini-2.5-flash', 'gemini-flash-latest', 'max_tokens', 'model', 'provider', 'reasoning', 'temperature', 'valid', 'warnings', '✅', '✅ Configured', '❌']

.hypothesis/constants/8c19f079e3b1a4a4

@@ -1,4 +0,0 @@
-# file: /Users/serhiizabolotnii/Medical Brain/Lifestyle/src/core/spiritual_state.py
-# hypothesis_version: 6.148.7
-
-[0.0, 'RESET -> green', 'continue', 'escalate_red', 'green', 'red', 'resolved_green', 'yellow']

.hypothesis/constants/d992e29f81671095

@@ -1,4 +0,0 @@
-# file: /Users/serhiizabolotnii/Medical Brain/Lifestyle/src/core/ai_client.py
-# hypothesis_version: 6.148.7
-
-[0.0, 0.3, 0.7, 20000, ' AI Client Test', '%Y-%m-%d %H:%M:%S', '=', 'ANTHROPIC_API_KEY', 'DefaultAgent', 'EntryClassifier', 'GEMINI_API_KEY', 'LOG_PROMPTS', 'MedicalAssistant', 'TEST', '__main__', 'active_model', 'active_provider', 'agent_name', 'ai_interactions.log', 'call_count', 'client_info', 'configured_model', 'configured_provider', 'content', 'default_model', 'false', 'get_client_info', 'last_error', 'model', 'performance_metrics', 'provider', 'reasoning', 'role', 'spiritual_analysis', 'successful_calls', 'system_instruction', 'temperature', 'text', 'thinking_config', 'total_calls', 'total_response_time', 'true', 'type', 'user', 'using_fallback', 'utf-8']

.hypothesis/constants/da39a3ee5e6b4b0d

@@ -1,4 +0,0 @@
-# file: /Users/serhiizabolotnii/Medical Brain/Lifestyle/src/__init__.py
-# hypothesis_version: 6.148.7
-
-[]

.kiro/specs/lifestyle-spiritual-integration/design.md

@@ -1,557 +0,0 @@
-# Design Document - Lifestyle & Spiritual Integration
-
-## Overview
-
-Цей документ описує архітектурний дизайн інтеграції Lifestyle та Spiritual Health Assessment режимів в єдиний діалоговий інтерфейс. Система надає користувачам можливість вибору між окремими режимами або їх комбінацією, зберігаючи при цьому пріоритет медичних питань.
-
-## Architecture
-
-### High-Level Architecture
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│                     User Interface (Gradio)                  │
-│  ┌──────────────────────────────────────────────────────┐  │
-│  │  Mode Selector: Medical | Lifestyle | Spiritual |    │  │
-│  │                 Combined                              │  │
-│  └──────────────────────────────────────────────────────┘  │
-└─────────────────────────────────────────────────────────────┘
-                            ↓
-┌─────────────────────────────────────────────────────────────┐
-│              ExtendedLifestyleJourneyApp                     │
-│  ┌──────────────────────────────────────────────────────┐  │
-│  │  Entry Classifier (K/L/S/T)                          │  │
-│  └──────────────────────────────────────────────────────┘  │
-│                            ↓                                 │
-│  ┌──────────────────────────────────────────────────────┐  │
-│  │  Mode Router                                          │  │
-│  │  • Medical Mode → MedicalAssistant                   │  │
-│  │  • Lifestyle Mode → MainLifestyleAssistant           │  │
-│  │  • Spiritual Mode → SpiritualAssistant               │  │
-│  │  • Combined Mode → CombinedAssistant                 │  │
-│  └──────────────────────────────────────────────────────┘  │
-└─────────────────────────────────────────────────────────────┘
-                            ↓
-┌─────────────────────────────────────────────────────────────┐
-│                    Assistants Layer                          │
-│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐     │
-│  │   Medical    │  │  Lifestyle   │  │  Spiritual   │     │
-│  │  Assistant   │  │  Assistant   │  │  Assistant   │     │
-│  └──────────────┘  └──────────────┘  └──────────────┘     │
-│                            ↓                                 │
-│  ┌──────────────────────────────────────────────────────┐  │
-│  │         CombinedAssistant                            │  │
-│  │  (координує Lifestyle + Spiritual)                   │  │
-│  └──────────────────────────────────────────────────────┘  │
-└─────────────────────────────────────────────────────────────┘
-                            ↓
-┌─────────────────────────────────────────────────────────────┐
-│                  Core Services                               │
-│  • AIClientManager                                           │
-│  • SpiritualDistressAnalyzer                                │
-│  • ReferralMessageGenerator                                 │
-│  • ClarifyingQuestionGenerator                              │
-│  • LifestyleSessionManager                                  │
-└─────────────────────────────────────────────────────────────┘
-```
-
-## Components and Interfaces
-
-### 1. AssistantMode Enum
-
-```python
-from enum import Enum
-
-class AssistantMode(Enum):
-    """Режими роботи асистента"""
-    NONE = "none"
-    MEDICAL = "medical"
-    LIFESTYLE = "lifestyle"
-    SPIRITUAL = "spiritual"
-    COMBINED = "combined"
-```
-
-### 2. SpiritualAssistant
-
-Новий компонент для інтеграції Spiritual Health Assessment в діалоговий режим.
-
-```python
-class SpiritualAssistant:
-    """
-    Асистент для оцінки духовного дистресу в діалоговому режимі.
-    
-    Обгортка навколо SpiritualDistressAnalyzer, ReferralMessageGenerator
-    та ClarifyingQuestionGenerator для інтеграції в діалоговий потік.
-    """
-    
-    def __init__(self, api: AIClientManager):
-        self.api = api
-        self.analyzer = SpiritualDistressAnalyzer(api)
-        self.referral_generator = ReferralMessageGenerator(api)
-        self.question_generator = ClarifyingQuestionGenerator(api)
-    
-    def process_message(
-        self,
-        message: str,
-        chat_history: List[ChatMessage],
-        clinical_background: ClinicalBackground
-    ) -> Dict[str, Any]:
-        """
-        Обробляє повідомлення користувача та генерує відповідь.
-        
-        Args:
-            message: Повідомлення користувача
-            chat_history: Історія чату
-            clinical_background: Медичний контекст пацієнта
-            
-        Returns:
-            {
-                "message": str,  # Відповідь користувачу
-                "classification": DistressClassification,
-                "referral": Optional[ReferralMessage],
-                "questions": List[str],
-                "action": str,  # "continue", "escalate", "close"
-                "reasoning": str
-            }
-        """
-```
-
-**Інтерфейс:**
-- **Input**: message (str), chat_history (List), clinical_background (ClinicalBackground)
-- **Output**: Dict з полями message, classification, referral, questions, action, reasoning
-
-**Поведінка:**
-- Аналізує повідомлення на духовний дистрес
-- Генерує referral для red flags
-- Генерує clarifying questions для yellow flags
-- Форматує відповідь для діалогового інтерфейсу
-
-### 3. CombinedAssistant
-
-Координатор для одночасної роботи Lifestyle та Spiritual асистентів.
-
-```python
-class CombinedAssistant:
-    """
-    Координує роботу Lifestyle та Spiritual асистентів.
-    
-    Викликає обидва асистенти, комбінує їх результати та визначає
-    пріоритет відповіді на основі виявлених індикаторів.
-    """
-    
-    def __init__(
-        self,
-        lifestyle_assistant: MainLifestyleAssistant,
-        spiritual_assistant: SpiritualAssistant
-    ):
-        self.lifestyle = lifestyle_assistant
-        self.spiritual = spiritual_assistant
-    
-    def process_message(
-        self,
-        message: str,
-        chat_history: List[ChatMessage],
-        clinical_background: ClinicalBackground,
-        lifestyle_profile: LifestyleProfile,
-        session_length: int
-    ) -> Dict[str, Any]:
-        """
-        Обробляє повідомлення обома асистентами та комбінує результати.
-        
-        Args:
-            message: Повідомлення користувача
-            chat_history: Історія чату
-            clinical_background: Медичний контекст
-            lifestyle_profile: Профіль lifestyle
-            session_length: Довжина поточної сесії
-            
-        Returns:
-            {
-                "message": str,  # Комбінована відповідь
-                "lifestyle_result": Dict,
-                "spiritual_result": Dict,
-                "priority": str,  # "lifestyle", "spiritual", "balanced"
-                "action": str,  # "continue", "escalate_spiritual", "close"
-                "reasoning": str
-            }
-        """
-```
-
-**Інтерфей��:**
-- **Input**: message, chat_history, clinical_background, lifestyle_profile, session_length
-- **Output**: Dict з комбінованими результатами
-
-**Логіка пріоритизації:**
-1. Якщо Spiritual виявляє red flag → пріоритет spiritual (escalate)
-2. Якщо Lifestyle вирішує закрити сесію → пріоритет lifestyle (close)
-3. Інакше → збалансована комбінація (balanced)
-
-### 4. Оновлений Entry Classifier
-
-Розширений класифікатор з підтримкою spiritual індикаторів.
-
-```python
-class EntryClassifier:
-    """
-    Класифікує вхідні повідомлення за типом потреби.
-    
-    Визначає:
-    - K (Koncern): медичні проблеми
-    - L (Lifestyle): потреба в lifestyle підтримці
-    - S (Spiritual): потреба в spiritual підтримці
-    - T (Triage): рівень терміновості
-    """
-    
-    def classify(
-        self,
-        message: str,
-        clinical_background: ClinicalBackground
-    ) -> Dict[str, str]:
-        """
-        Класифікує повідомлення.
-        
-        Returns:
-            {
-                "K": "none" | "minor" | "urgent",
-                "L": "off" | "on",
-                "S": "off" | "on",
-                "T": "routine" | "urgent" | "emergency"
-            }
-        """
-```
-
-**Нова логіка:**
-- Додано визначення spiritual індикаторів (S)
-- Аналіз емоційних та духовних маркерів
-- Інтеграція з існуючою K/L/T логікою
-
-### 5. Оновлений SessionState
-
-```python
-@dataclass
-class SessionState:
-    """Стан поточної сесії користувача"""
-    
-    # Загальний стан
-    current_mode: AssistantMode = AssistantMode.NONE
-    is_active_session: bool = False
-    session_start_time: Optional[datetime] = None
-    
-    # Entry classification
-    entry_classification: Dict[str, str] = field(default_factory=dict)
-    
-    # Medical state
-    last_triage_summary: str = ""
-    
-    # Lifestyle state
-    lifestyle_session_length: int = 0
-    
-    # Spiritual state
-    spiritual_assessment: Optional[DistressClassification] = None
-    spiritual_referral: Optional[ReferralMessage] = None
-    spiritual_questions: List[str] = field(default_factory=list)
-    
-    # Combined state
-    combined_results: Dict[str, Any] = field(default_factory=dict)
-    active_assistants: List[str] = field(default_factory=list)
-```
-
-## Data Models
-
-### ClassificationResult
-
-```python
-@dataclass
-class ClassificationResult:
-    """Результат класифікації Entry Classifier"""
-    K: str  # "none", "minor", "urgent"
-    L: str  # "off", "on"
-    S: str  # "off", "on"
-    T: str  # "routine", "urgent", "emergency"
-    reasoning: str
-    confidence: float
-```
-
-### SpiritualResponse
-
-```python
-@dataclass
-class SpiritualResponse:
-    """Відповідь Spiritual Assistant"""
-    message: str
-    classification: DistressClassification
-    referral: Optional[ReferralMessage]
-    questions: List[str]
-    action: str  # "continue", "escalate", "close"
-    reasoning: str
-```
-
-### CombinedResponse
-
-```python
-@dataclass
-class CombinedResponse:
-    """Відповідь Combined Assistant"""
-    message: str
-    lifestyle_result: Dict[str, Any]
-    spiritual_result: SpiritualResponse
-    priority: str  # "lifestyle", "spiritual", "balanced"
-    action: str  # "continue", "escalate_spiritual", "close"
-    reasoning: str
-```
-
-## Correctness Properties
-
-*A property is a characteristic or behavior that should hold true across all valid executions of a system-essentially, a formal statement about what the system should do. Properties serve as the bridge between human-readable specifications and machine-verifiable correctness guarantees.*
-
-### Property 1: Mode consistency
-*For any* session state, the current_mode field should always match the active assistant being used
-**Validates: Requirements 1.1, 1.2**
-
-### Property 2: History preservation
-*For any* mode switch operation, the chat history length should never decrease
-**Validates: Requirements 1.3, 9.1, 9.2**
-
-### Property 3: Medical priority
-*For any* message classified with K="urgent", the system should activate Medical mode regardless of current mode
-**Validates: Requirements 3.1, 3.4**
-
-### Property 4: Combined coordination
-*For any* message in Combined mode, both Lifestyle and Spiritual assistants should be invoked
-**Validates: Requirements 2.1, 6.1**
-
-### Property 5: Spiritual escalation priority
-*For any* Combined mode response where Spiritual detects red flag, the priority should be "spiritual"
-**Validates: Requirements 2.3, 2.4, 6.3**
-
-### Property 6: Session closure completeness
-*For any* mode switch from Lifestyle, the lifestyle profile should be updated before switching
-**Validates: Requirements 10.1, 10.3**
-
-### Property 7: Classification completeness
-*For any* message, Entry Classifier should return all four fields (K, L, S, T)
-**Validates: Requirements 4.1, 4.2, 4.3, 4.4**
-
-### Property 8: Fallback availability
-*For any* assistant error, the system should have at least one fallback option available
-**Validates: Requirements 11.1, 11.2**
-
-### Property 9: UI mode indicator consistency
-*For any* active mode, the UI should display the corresponding mode indicator
-**Validates: Requirements 1.4, 8.3**
-
-### Property 10: Combined result structure
-*For any* Combined mode response, both lifestyle_result and spiritual_result fields should be present
-**Validates: Requirements 2.2, 6.2**
-
-## Error Handling
-
-### Error Scenarios
-
-1. **Assistant Unavailable**
-   - Fallback: Use alternative assistant or Medical mode
-   - User notification: "Switching to alternative support mode"
-
-2. **Classification Failure**
-   - Fallback: Use last known mode or default to Medical
-   - User notification: "Using previous mode settings"
-
-3. **Combined Mode Partial Failure**
-   - Fallback: Use successful assistant result
-   - User notification: "Providing available support"
-
-4. **Session State Corruption**
-   - Fallback: Reset to safe state (Medical mode)
-   - User notification: "Session reset for safety"
-
-### Error Recovery Strategy
-
-```python
-def handle_assistant_error(
-    error: Exception,
-    current_mode: AssistantMode,
-    fallback_mode: AssistantMode
-) -> Tuple[str, AssistantMode]:
-    """
-    Обробляє помилки асистентів з fallback логікою.
-    
-    Returns:
-        (error_message, new_mode)
-    """
-    if isinstance(error, TimeoutError):
-        return "Service temporarily unavailable, trying alternative...", fallback_mode
-    elif isinstance(error, ValueError):
-        return "Invalid input, switching to safe mode...", AssistantMode.MEDICAL
-    else:
-        return "Unexpected error, resetting to medical mode...", AssistantMode.MEDICAL
-```
-
-## Testing Strategy
-
-### Unit Tests
-
-1. **SpiritualAssistant Tests**
-   - Test message processing for each flag level
-   - Test response formatting
-   - Test error handling
-
-2. **CombinedAssistant Tests**
-   - Test parallel invocation
-   - Test priority determination
-   - Test result combination
-
-3. **Entry Classifier Tests**
-   - Test K/L/S/T classification
-   - Test spiritual indicator detection
-   - Test edge cases
-
-### Integration Tests
-
-1. **Mode Switching Tests**
-   - Test Lifestyle → Spiritual switch
-   - Test Spiritual → Lifestyle switch
-   - Test Combined → Single mode switch
-   - Test history preservation
-
-2. **Combined Mode Tests**
-   - Test both assistants invoked
-   - Test priority handling
-   - Test partial failure scenarios
-
-3. **Session Management Tests**
-   - Test session closure on mode switch
-   - Test state preservation
-   - Test profile updates
-
-### Property-Based Tests
-
-Using pytest with hypothesis library:
-
-1. **Property Test: Mode Consistency**
-   ```python
-   @given(st.text(), st.sampled_from(AssistantMode))
-   def test_mode_consistency(message, mode):
-       # Test that mode always matches active assistant
-   ```
-
-2. **Property Test: History Preservation**
-   ```python
-   @given(st.lists(st.text()), st.sampled_from(AssistantMode))
-   def test_history_preservation(messages, new_mode):
-       # Test that history never decreases on mode switch
-   ```
-
-3. **Property Test: Medical Priority**
-   ```python
-   @given(st.text())
-   def test_medical_priority(message):
-       # Test that urgent medical issues always activate Medical mode
-   ```
-
-## UI Design
-
-### Mode Selector Component
-
-```python
-with gr.Row():
-    mode_selector = gr.Radio(
-        choices=[
-            "🏥 Medical Only",
-            "💚 Lifestyle Focus",
-            "🕊️ Spiritual Focus",
-            "🌟 Combined (Lifestyle + Spiritual)"
-        ],
-        value="🌟 Combined (Lifestyle + Spiritual)",
-        label="Assistant Mode",
-        info="Choose your support mode"
-    )
-```
-
-### Status Display
-
-```python
-def format_status_display(session_state: SessionState) -> str:
-    """Форматує статус для відображення"""
-    mode_icons = {
-        AssistantMode.MEDICAL: "🏥",
-        AssistantMode.LIFESTYLE: "💚",
-        AssistantMode.SPIRITUAL: "🕊️",
-        AssistantMode.COMBINED: "🌟"
-    }
-    
-    icon = mode_icons.get(session_state.current_mode, "⚪")
-    mode_name = session_state.current_mode.value.upper()
-    
-    status = f"{icon} **Current Mode:** {mode_name}\n"
-    
-    if session_state.current_mode == AssistantMode.COMBINED:
-        status += f"**Active:** {', '.join(session_state.active_assistants)}\n"
-    
-    if session_state.spiritual_assessment:
-        flag = session_state.spiritual_assessment.flag_level
-        status += f"🚩 **Spiritual Flag:** {flag.upper()}\n"
-    
-    return status
-```
-
-### Response Formatting
-
-```python
-def format_combined_response(response: CombinedResponse) -> str:
-    """Форматує комбіновану відповідь"""
-    if response.priority == "spiritual":
-        return f"""🕊️ **Spiritual Assessment (Priority)**
-
-{response.spiritual_result.message}
-
----
-
-💚 **Lifestyle Support**
-
-{response.lifestyle_result['message']}
-"""
-    elif response.priority == "lifestyle":
-        return f"""💚 **Lifestyle Coaching (Priority)**
-
-{response.lifestyle_result['message']}
-
----
-
-🕊️ **Spiritual Check**
-
-{response.spiritual_result.message}
-"""
-    else:  # balanced
-        return f"""🌟 **Comprehensive Support**
-
-💚 **Lifestyle:**
-{response.lifestyle_result['message']}
-
-🕊️ **Spiritual:**
-{response.spiritual_result.message}
-"""
-```
-
-## Implementation Notes
-
-### Phase 1: Core Components
-1. Create SpiritualAssistant class
-2. Create CombinedAssistant class
-3. Update Entry Classifier
-4. Update SessionState
-
-### Phase 2: Integration
-1. Integrate into ExtendedLifestyleJourneyApp
-2. Add mode routing logic
-3. Update process_message flow
-
-### Phase 3: UI
-1. Add mode selector
-2. Update status display
-3. Add response formatting
-
-### Phase 4: Testing
-1. Unit tests for new components
-2. Integration tests for mode switching
-3. Property-based tests for correctness
-

.kiro/specs/lifestyle-spiritual-integration/requirements.md

@@ -1,162 +0,0 @@
-# Requirements Document - Lifestyle & Spiritual Integration
-
-## Introduction
-
-Цей документ описує вимоги до інтеграції режимів Lifestyle та Spiritual Health Assessment в єдиний діалоговий інтерфейс з можливістю переключення між режимами та комбінованої роботи.
-
-## Glossary
-
-- **System**: Інтегрована система Medical Brain з підтримкою Lifestyle та Spiritual режимів
-- **Lifestyle Mode**: Режим роботи з рекомендаціями щодо способу життя
-- **Spiritual Mode**: Режим оцінки духовного дистресу
-- **Combined Mode**: Комбінований режим одночасної роботи Lifestyle та Spiritual
-- **Medical Mode**: Базовий медичний режим для обробки медичних питань
-- **Entry Classifier**: Компонент класифікації вхідних повідомлень
-- **Session State**: Стан поточної сесії користувача
-- **Assistant**: Компонент, що генерує відповіді користувачу
-
-## Requirements
-
-### Requirement 1: Переключення між режимами
-
-**User Story:** Як користувач, я хочу переключатися між Lifestyle та Spiritual режимами, щоб отримувати різні типи підтримки залежно від моїх потреб.
-
-#### Acceptance Criteria
-
-1. WHEN користувач обирає Lifestyle режим THEN система SHALL активувати MainLifestyleAssistant та деактивувати інші асистенти
-2. WHEN користувач обирає Spiritual режим THEN система SHALL активувати SpiritualAssistant та деактивувати інші асистенти
-3. WHEN користувач перемикає режим THEN система SHALL зберігати історію чату
-4. WHEN режим змінюється THEN система SHALL відображати поточний активний режим в UI
-5. WHEN користувач перемикає з одного режиму на інший THEN система SHALL коректно завершувати попередню сесію
-
-### Requirement 2: Комбінований режим роботи
-
-**User Story:** Як користувач, я хочу отримувати одночасно lifestyle рекомендації та spiritual assessment, щоб мати комплексну підтримку.
-
-#### Acceptance Criteria
-
-1. WHEN користувач обирає Combined режим THEN система SHALL аналізувати повідомлення обома асистентами
-2. WHEN отримано результати від обох асистентів THEN система SHALL комбінувати відповіді в єдине повідомлення
-3. WHEN один з асистентів виявляє критичну ситуацію THEN система SHALL надавати пріоритет його відповіді
-4. WHEN Spiritual Assistant виявляє red flag THEN система SHALL відображати referral message з найвищим пріоритетом
-5. WHEN обидва асистенти генерують відповіді THEN система SHALL чітко розділяти їх в UI
-
-### Requirement 3: Інтеграція з медичним режимом
-
-**User Story:** Як користувач, я хочу, щоб медичні питання завжди мали пріоритет, незалежно від обраного режиму.
-
-#### Acceptance Criteria
-
-1. WHEN Entry Classifier виявляє медичну проблему THEN система SHALL переключатися на Medical режим
-2. WHEN медична проблема вирішена THEN система SHALL повертатися до попередньо обраного режиму
-3. WHEN користувач в Medical режимі THEN система SHALL використовувати MedicalAssistant або SoftMedicalTriage
-4. WHEN медична проблема критична THEN система SHALL ігнорувати поточний режим та активувати Medical режим
-
-### Requirement 4: Розширений Entry Classifier
-
-**User Story:** Як система, я маю коректно визначати потребу в lifestyle, spiritual або обох типах підтримки.
-
-#### Acceptance Criteria
-
-1. WHEN Entry Classifier аналізує повідомлення THEN система SHALL визначати медичні індикатори (K)
-2. WHEN Entry Classifier аналізує повідомлення THEN система SHALL визнач��ти lifestyle індикатори (L)
-3. WHEN Entry Classifier аналізує повідомлення THEN система SHALL визначати spiritual індикатори (S)
-4. WHEN Entry Classifier аналізує повідомлення THEN система SHALL визначати рівень терміновості (T)
-5. WHEN виявлено індикатори обох типів THEN система SHALL рекомендувати Combined режим
-
-### Requirement 5: SpiritualAssistant для діалогового режиму
-
-**User Story:** Як система, я маю інтегрувати Spiritual Health Assessment в діалоговий потік.
-
-#### Acceptance Criteria
-
-1. WHEN SpiritualAssistant отримує повідомлення THEN система SHALL аналізувати його на духовний дистрес
-2. WHEN виявлено red flag THEN SpiritualAssistant SHALL генерувати referral message
-3. WHEN виявлено yellow flag THEN SpiritualAssistant SHALL генерувати clarifying questions
-4. WHEN виявлено no flag THEN SpiritualAssistant SHALL генерувати підтримуючу відповідь
-5. WHEN SpiritualAssistant генерує відповідь THEN система SHALL форматувати її для діалогового інтерфейсу
-
-### Requirement 6: CombinedAssistant координація
-
-**User Story:** Як система, я маю координувати роботу Lifestyle та Spiritual асистентів в Combined режимі.
-
-#### Acceptance Criteria
-
-1. WHEN CombinedAssistant обробляє повідомлення THEN система SHALL викликати обидва асистенти паралельно
-2. WHEN отримано результати від обох асистентів THEN CombinedAssistant SHALL визначати пріоритет відповіді
-3. WHEN Spiritual виявляє red flag THEN CombinedAssistant SHALL надавати пріоритет spiritual відповіді
-4. WHEN обидва асистенти генерують нормальні відповіді THEN CombinedAssistant SHALL комбінувати їх збалансовано
-5. WHEN один з асистентів повертає помилку THEN CombinedAssistant SHALL використовувати результат іншого
-
-### Requirement 7: Оновлений SessionState
-
-**User Story:** Як система, я маю зберігати стан для всіх режимів роботи.
-
-#### Acceptance Criteria
-
-1. WHEN SessionState ініціалізується THEN система SHALL створювати поля для всіх режимів
-2. WHEN режим змінюється THEN SessionState SHALL оновлювати current_mode
-3. WHEN Spiritual режим активний THEN SessionState SHALL зберігати spiritual_assessment, spiritual_referral, spiritual_questions
-4. WHEN Combined режим активний THEN SessionState SHALL зберігати результати обох асистентів
-5. WHEN сесія скидається THEN SessionState SHALL очищати всі поля
-
-### Requirement 8: UI компоненти для вибору режиму
-
-**User Story:** Як користувач, я хочу легко обирати та бачити поточний режим роботи.
-
-#### Acceptance Criteria
-
-1. WHEN інтерфейс завантажується THEN система SHALL відображати mode selector з усіма доступними режимами
-2. WHEN користувач обирає режим THEN UI SHALL візуально підтверджувати вибір
-3. WHEN режим активний THEN status box SHALL відображати поточний режим з іконкою
-4. WHEN Combined режим активний THEN UI SHALL показувати індикатори обох асистентів
-5. WHEN Spiritual виявляє red flag THEN UI SHALL відображати червоний індикатор та referral message
-
-### Requirement 9: Збереження історії при переключенні
-
-**User Story:** Як користувач, я хочу, щоб історія чату зберігалася при переключенні режимів.
-
-#### Acceptance Criteria
-
-1. WHEN користувач перемикає режим THEN система SHALL зберігати всю історію чату
-2. WHEN користувач повертається до попереднього режиму THEN система SHALL відображати повну історію
-3. WHEN повідомлення додається до історії THEN система SHALL позначати його поточним режимом
-4. WHEN історія відображається THEN UI SHALL показувати іконки режимів для кожного повідомлення
-5. WHEN сесія завершується THEN система SHALL зберігати історію з інформацією про режими
-
-### Requirement 10: Коректне завершення сесій
-
-**User Story:** Як система, я маю коректно завершувати сесії при переключенні режимів.
-
-#### Acceptance Criteria
-
-1. WHEN користувач перемикає з Lifestyle режиму THEN система SHALL оновлювати lifestyle profile
-2. WHEN користувач перемикає з Spiritual режиму THEN система SHALL зберігати spiritual assessment
-3. WHEN користувач перемикає з Combined режиму THEN система SHALL завершувати обидві сесії
-4. WHEN сесія завершується THEN система SHALL генерувати summary для користувача
-5. WHEN користувач явно завершує розмову THEN система SHALL коректно закривати всі активні сесії
-
-### Requirement 11: Обробка помилок та fallback
-
-**User Story:** Як система, я маю коректно обробляти помилки та надавати fallback опції.
-
-#### Acceptance Criteria
-
-1. WHEN один з асистентів повертає помилку THEN система SHALL використовувати інший асистент
-2. WHEN обидва асистенти недоступні THEN система SHALL переключатися на Medical режим
-3. WHEN Entry Classifier не може визначити режим THEN система SHALL використовувати останній активний режим
-4. WHEN виникає критична помилка THEN система SHALL інформувати користувача з чіткими інструкціями
-5. WHEN помилка тимчасова THEN система SHALL автоматично повторювати запит
-
-### Requirement 12: Тестування та валідація
-
-**User Story:** Як розробник, я хочу мати комплексні тести для всіх режимів роботи.
-
-#### Acceptance Criteria
-
-1. WHEN створюється новий компонент THEN розробник SHALL написати unit тести
-2. WHEN інтегруються компоненти THEN розробник SHALL написати integration тести
-3. WHEN тестується переключення режимів THEN тести SHALL перевіряти збереження стану
-4. WHEN тестується Combined режим THEN тести SHALL перевіряти координацію асистентів
-5. WHEN тестується UI THEN тести SHALL перевіряти коректне відображення всіх режимів
-

.kiro/specs/lifestyle-spiritual-integration/tasks.md

@@ -1,467 +0,0 @@
-# Implementation Plan - Lifestyle & Spiritual Integration
-
-## Overview
-
-Цей план описує покрокову імплементацію інтеграції Lifestyle та Spiritual режимів з можливістю переключення та комбінованої роботи.
-
----
-
-## Phase 1: Core Components ✅ COMPLETED
-
-### Task 1: Створити SpiritualAssistant для діалогового режиму ✅
-
-- [x] 1.1 Створити файл `src/core/spiritual_assistant.py`
-  - Створити клас SpiritualAssistant
-  - Додати __init__ з ініціалізацією analyzer, referral_generator, question_generator
-  - _Requirements: 5.1_
-
-- [x] 1.2 Імплементувати метод process_message()
-  - Додати аналіз повідомлення через SpiritualDistressAnalyzer
-  - Додати генерацію referral для red flags
-  - Додати генерацію questions для yellow flags
-  - Додати форматування відповіді для діалогу
-  - _Requirements: 5.2, 5.3, 5.4, 5.5_
-
-- [x] 1.3 Додати форматування відповідей
-  - Створити метод _format_response_for_dialog()
-  - Додати різні формати для red/yellow/no flags
-  - Додати емоційно підтримуючі повідомлення
-  - _Requirements: 5.5_
-
-- [x]* 1.4 Написати unit тести для SpiritualAssistant
-  - Тести для process_message з різними flag levels
-  - Тести для форматування відповідей
-  - Тести для обробки помилок
-  - _Requirements: 12.1_
-
----
-
-### Task 2: Створити CombinedAssistant для координації ✅
-
-- [x] 2.1 Створити файл `src/core/combined_assistant.py`
-  - Створити клас CombinedAssistant
-  - Додати __init__ з lifestyle_assistant та spiritual_assistant
-  - _Requirements: 6.1_
-
-- [x] 2.2 Імплементувати метод process_message()
-  - Додати паралельний виклик обох асистентів
-  - Додати обробку результатів
-  - Додати error handling для кожного асистента
-  - _Requirements: 6.1, 6.5_
-
-- [x] 2.3 Додати логіку пріоритизації
-  - Створити метод _determine_priority()
-  - Додати перевірку red flag від Spiritual
-  - Додати перевірку close action від Lifestyle
-  - Додати balanced режим
-  - _Requirements: 6.2, 6.3, 6.4_
-
-- [x] 2.4 Додати комбінування відповідей
-  - Створити метод _combine_responses()
-  - Додати форматування для різних пріоритетів
-  - Додати розділення відповідей в UI
-  - _Requirements: 2.2, 2.5_
-
-- [x]* 2.5 Написати unit тести для CombinedAssistant
-  - Тести для паралельного виклику
-  - Тести для пріоритизації
-  - Тести для комбінування відповідей
-  - Тести для partial failure scenarios
-  - _Requirements: 12.1_
-
----
-
-### Task 3: Оновити Entry Classifier та SessionState ✅
-
-- [x] 3.1 Створити AssistantMode enum
-  - Додати enum AssistantMode в `src/core/core_classes.py` з значеннями: NONE, MEDICAL, LIFESTYLE, SPIRITUAL, COMBINED
-  - _Requirements: 7.1_
-
-- [x] 3.2 Додати визначення spiritual індикаторів в Entry Classifier
-  - Оновити метод classify() в `src/core/core_classes.py`
-  - Додати аналіз емоційних маркерів (anger, sadness, hopelessness, etc.)
-  - Додати аналіз духовних маркерів (meaning, purpose, faith concerns)
-  - Додати поле S в результат класифікації (off/on)
-  - _Requirements: 4.2, 4.3_
-
-- [x] 3.3 Оновити формат відповіді Entry Classifier на K/L/S/T
-  - Змінити return type на Dict з полями K, L, S, T
-  - K: "none" | "minor" | "urgent" (медичні індикатори)
-  - L: "off" | "on" (lifestyle індикатори)
-  - S: "off" | "on" (spiritual індикатори)
-  - T: "routine" | "urgent" | "emergency" (терміновість)
-  - Додати reasoning для кожного поля
-  - _Requirements: 4.1, 4.2, 4.3, 4.4_
-
-- [x] 3.4 Додати логіку рекомендації Combined режиму
-  - Додати перевірку L="on" AND S="on"
-  - Додати поле recommended_mode в результат
-  - _Requirements: 4.5_
-
-- [x] 3.5 Оновити SessionState з новими полями
-  - Змінити current_mode з str на AssistantMode type
-  - Додати spiritual_assessment: Optional[DistressClassification]
-  - Додати spiritual_referral: Optional[ReferralMessage]
-  - Додати spiritual_questions: List[str]
-  - Додати combined_results: Dict[str, Any]
-  - Додати active_assistants: List[str]
-  - _Requirements: 7.1, 7.3, 7.4_
-
-- [x] 3.6 Оновити методи SessionState
-  - Оновити метод reset() для очищення нових полів
-  - Додати метод update_mode() для зміни режиму
-  - Додати метод get_active_assistants()
-  - _Requirements: 7.2, 7.5_
-
-- [-]* 3.7 Написати тести для оновленого Entry Classifier та SessionState
-  - Тести для визначення S індикаторів
-  - Тести для K/L/S/T формату
-  - Тести для рекомендації Combined режиму
-  - Тести для нових полів SessionState
-  - _Requirements: 12.1_
-
----
-
-## Phase 2: Integration into ExtendedLifestyleJourneyApp ✅ COMPLETED
-
-### Task 4: Інтегрувати нові асистенти в app ✅
-
-- [x] 4.1 Додати ініціалізацію асистентів in __init__
-  - Додати self.spiritual_assistant = SpiritualAssistant(self.api) в lifestyle_app.py
-  - Додати self.combined_assistant = CombinedAssistant(self.main_lifestyle_assistant, self.spiritual_assistant)
-  - Оновити коментарі та документацію
-  - _Requirements: 5.1, 6.1_
-
-- [x] 4.2 Оновити process_message() для підтримки всіх режимів
-  - Додати перевірку current_mode (використовуючи AssistantMode enum)
-  - Додати routing до відповідного асистента на основі режиму
-  - Оновити логіку оновлення session_state з новими полями
-  - _Requirements: 1.1, 1.2, 2.1_
-
-- [x] 4.3 Додати _handle_spiritual_mode()
-  - Створити новий метод для обробки Spiritual режиму
-  - Додати виклик spiritual_assistant.process_message()
-  - Додати обробку результатів (red/yellow/no flag)
-  - Додати логіку переходу в Medical при escalation (action="escalate")
-  - Зберігати spiritual_assessment, spiritual_referral, spiritual_questions в session_state
-  - _Requirements: 1.2, 3.1_
-
-- [x] 4.4 Додати _handle_combined_mode()
-  - Створити новий метод для обробки Combined режиму
-  - Додати виклик combined_assistant.process_message()
-  - Додати обробку пріоритетів (spiritual/lifestyle/balanced)
-  - Додати логіку escalation при action="escalate_spiritual"
-  - Зберігати combined_results в session_state
-  - _Requirements: 2.1, 2.3_
-
-- [x] 4.5 Оновити _handle_entry_classification()
-  - Додати обробку S індикатора з нового K/L/S/T формату
-  - Додати routing до Spiritual режиму коли S="on" AND L="off"
-  - Додати routing до Combined режиму коли S="on" AND L="on"
-  - Оновити логіку для K/L/S/T формату замість старого K/V/T
-  - _Requirements: 4.1, 4.2, 4.3, 4.5_
-
-- [x] 4.6 Додати логіку завершення сесій при переключенні
-  - Створити метод _close_current_session()
-  - Додати збереження lifestyle profile при виході з Lifestyle
-  - Додати збереження spiritual assessment при виході з Spiritual
-  - Додати обробку Combined режиму (зберегти обидва профілі)
-  - Викликати при зміні режиму через mode selector
-  - _Requirements: 10.1, 10.2, 10.3, 10.4_
-
-- [-]* 4.7 Написати integration тести для app
-  - Тести для process_message з різними режимами
-  - Тести для переключення режимів
-  - Тести для завершення сесій
-  - _Requirements: 12.2_
-
----
-
-## Phase 3: UI Updates ✅ COMPLETED
-
-### Task 5: Додати mode selector в UI ✅
-
-- [x] 5.1 Додати mode selector компонент
-  - Додати gr.Radio з режимами в `src/interface/gradio_app.py`
-  - Режими: "🏥 Medical Only", "💚 Lifestyle Focus", "🕊️ Spiritual Focus", "🌟 Combined (Lifestyle + Spiritual)"
-  - Замінити існуючий "Prompt Mode" radio на "Assistant Mode"
-  - Додати опис режимів через info parameter
-  - _Requirements: 8.1_
-
-- [x] 5.2 Додати обробник зміни режиму
-  - Створити функцію handle_mode_change() в gradio_app.py
-  - Додати виклик app._close_current_session() перед зміною режиму
-  - Додати оновлення session_state.current_mode (використовуючи AssistantMode enum)
-  - Додати оновлення UI (chatbot, status_box)
-  - Підключити до mode_selector.change() event
-  - _Requirements: 1.4, 8.2_
-
-- [x] 5.3 Оновити status_box для відображення режиму
-  - Оновити _get_status_info() в lifestyle_app.py для показу current_mode
-  - Додати іконки режимів (🏥, 💚, 🕊️, 🌟)
-  - Додати індикатори active_assistants для Combined режиму
-  - Додати відображення spiritual flags (red/yellow/none)
-  - Додати відображення spiritual_referral якщо є
-  - _Requirements: 8.3, 8.4, 8.5_
-
-- [x] 5.4 Оновити ChatMessage для підтримки режимів
-  - Додати поле mode в ChatMessage dataclass (вже існує)
-  - Оновити створення ChatMessage щоб включати current_mode
-  - Додати відображення іконок режимів в історії чату
-  - _Requirements: 9.3, 9.4_
-
-- [-]* 5.5 Написати UI тести
-  - Тести для mode selector
-  - Тести для status display
-  - Тести для response formatting
-  - _Requirements: 12.5_
-
----
-
-## Phase 4: Error Handling and Fallback ✅ COMPLETED
-
-### Task 6: Додати error handling ✅
-
-- [x] 6.1 Додати обробку помилок асистентів in app
-  - Створити метод handle_assistant_error() в lifestyle_app.py
-  - Додати fallback логіку: Spiritual error → Medical mode, Lifestyle error → Medical mode
-  - Додати user notifications з чіткими інструкціями
-  - Додати logging помилок
-  - _Requirements: 11.1, 11.4_
-
-- [x] 6.2 Перевірити fallback для Combined режиму
-  - Переконатися що CombinedAssistant вже має обробку partial failure (вже реалізовано)
-  - Додати тести що Combined використовує успішний результат при помилці одного асистента
-  - Додати повідомлення користувачу про partial availability
-  - _Requirements: 11.1_
-
-- [x] 6.3 Додати fallback для Entry Classifier
-  - Додати try-catch навколо entry_classifier.classify()
-  - При помилці використовувати останній активний режим (session_state.current_mode)
-  - Якщо немає останнього режиму, default до Medical режиму
-  - Додати logging та user notification
-  - _Requirements: 11.3_
-
-- [x] 6.4 Додати retry логіку для тимчасових помилок
-  - Додати визначення тимчасових помилок (TimeoutError, ConnectionError)
-  - Додати автоматичний retry з exponential backoff
-  - Додати максимальну кількість спроб (3 спроби)
-  - Додати logging retry attempts
-  - _Requirements: 11.5_
-
-- [-]* 6.5 Написати тести для error handling
-  - Тести для різних типів помилок
-  - Тести для fallback логіки
-  - Тести для retry механізму
-  - _Requirements: 12.1_
-
----
-
-## Phase 5: Testing and Validation
-
-### Task 7: Comprehensive Testing
-
-- [-] 7.1 Checkpoint - Переконатися що всі unit тести проходять
-  - Запустити pytest tests/test_spiritual_assistant.py
-  - Запустити pytest tests/test_combined_assistant.py
-  - Виправити failing тести якщо є
-  - Переконатися що coverage > 80% для нових компонентів
-  - _Requirements: 12.1_
-
-- [-]* 7.2 Написати integration тести для переключення режимів
-  - Тест: Lifestyle → Spiritual → Lifestyle (збереження lifestyle profile)
-  - Тест: Spiritual → Combined → Spiritual (збереження spiritual assessment)
-  - Тест: Combined → Medical → Combined (збереження обох профілів)
-  - Тест: збереження історії при переключенні (history length не зменшується)
-  - _Requirements: 12.3_
-
-- [-]* 7.3 Написати integration тести для Combined режиму
-  - Тест: обидва асистенти викликаються паралельно
-  - Тест: пріоритизація при red flag (spiritual priority)
-  - Тест: balanced комбінування при нормальних результатах
-  - Тест: partial failure handling (один асистент працює)
-  - _Requirements: 12.4_
-
-- [-]* 7.4 Написати property-based тести
-  - **Property 1: Mode consistency** - session_state.current_mode завжди відповідає активному асистенту
-  - **Property 2: History preservation** - len(chat_history) ніколи не зменшується при mode switch
-  - **Property 3: Medical priority** - K="urgent" завжди активує Medical режим
-  - **Property 4: Combined coordination** - Combined режим завжди викликає обидва асистенти
-  - _Requirements: 12.1_
-
-- [-] 7.5 Checkpoint - Переконатися що всі тести проходять
-  - Запустити pytest для всього проекту
-  - Виправити failing тести
-  - Перевірити edge cases
-  - Переконатися що немає regression в існуючій функціональності
-  - _Requirements: 12.2_
-
----
-
-## Phase 6: Documentation and Final Validation
-
-### Task 8: Оновити документацію
-
-- [-] 8.1 Оновити README.md
-  - Додати опис нових режимів (Medical, Lifestyle, Spiritual, Combined)
-  - Додати приклади використання кожного режиму
-  - Додати інформацію про переключення режимів
-  - _Requirements: N/A_
-
-- [-] 8.2 Оновити QUICK_START.md
-  - Додати інструкції для вибору режиму через UI
-  - Додати приклади запитів для кожного режиму
-  - Додати пояснення коли використовувати який режим
-  - _Requirements: N/A_
-
-- [-] 8.3 Створити USER_GUIDE.md для режимів
-  - Додати детальний опис кожного режиму
-  - Додати рекомендації коли використовувати який режим
-  - Додати FAQ про режими
-  - Додати troubleshooting для режимів
-  - _Requirements: N/A_
-
-- [-] 8.4 Оновити код коментарі та docstrings
-  - Додати docstrings для всіх нових методів
-  - Оновити коментарі в коді
-  - Додати type hints де відсутні
-  - Додати приклади використання в docstrings
-  - _Requirements: N/A_
-
----
-
-### Task 9: Final Testing and Validation
-
-- [-] 9.1 Провести manual testing всіх режимів
-  - Тестувати Medical режим (існуюча функціональність)
-  - Тестувати Lifestyle режим (існуюча функціональність)
-  - Тестувати Spiritual режим (нова функціональність)
-  - Тестувати Combined режим (нова функціональність)
-  - _Requirements: N/A_
-
-- [-] 9.2 Провести manual testing переключення режимів
-  - Тестувати переключення між всіма режимами
-  - Перевірити збереження історії
-  - Перевірити збереження профілів
-  - Перевірити UI updates при переключенні
-  - _Requirements: N/A_
-
-- [-] 9.3 Провести error scenario testing
-  - Тестувати помилки асистентів
-  - Тестувати помилки Entry Classifier
-  - Тестувати partial failures в Combined режимі
-  - Перевірити fallback логіку
-  - _Requirements: N/A_
-
-- [-] 9.4 Провести performance testing
-  - Виміряти час відповіді для кожного режиму
-  - Виміряти час для Combined режиму (паралельні виклики)
-  - Виміряти час Entry Classifier з новою логікою
-  - Оптимізувати якщо потрібно
-  - _Requirements: N/A_
-
-- [-] 9.5 Final Checkpoint - Все готово до deployment
-  - Всі unit тести проходять
-  - Всі integration тести проходять (якщо написані)
-  - Документація оновлена
-  - Manual testing завершено
-  - Performance прийнятний
-  - Немає regression в існуючій функціональності
-  - _Requirements: All_
-
----
-
-## Phase 7: Technology Upgrade ✅ COMPLETED
-
-### Task 10: Upgrade to Gradio 6.0.2 ✅
-
-- [x] 10.1 Update requirements.txt
-  - Змінити gradio>=5.3.0 на gradio==6.0.2
-  - Перевірити сумісність інших залежностей
-  - _Date: December 5, 2025_
-
-- [x] 10.2 Rebuild virtual environment
-  - Видалити старий venv
-  - Створити новий venv з Python 3.14.0
-  - Встановити всі залежності з оновленим Gradio
-  - _Date: December 5, 2025_
-
-- [x] 10.3 Run regression tests
-  - Запустити test_spiritual_assistant.py (13 tests)
-  - Запустити test_combined_assistant.py (14 tests)
-  - Переконатися що всі 27 тестів проходять
-  - _Result: ✅ 27/27 tests passed_
-
-- [x] 10.4 Test UI compatibility
-  - Запустити Gradio interface
-  - Перевірити Assistant Mode selector
-  - Перевірити всі 4 режими (Medical/Lifestyle/Spiritual/Combined)
-  - Перевірити session isolation
-  - _Status: ✅ Interface running on http://127.0.0.1:7860_
-
-- [x] 10.5 Fix Gradio 6.x compatibility issues
-  - Виправити `theme` parameter (тепер через demo.theme attribute)
-  - Видалити `show_copy_button` parameter (deprecated)
-  - Видалити `type="messages"` parameter (auto-detected)
-  - Оновити обидва файли: gradio_app.py та spiritual_interface.py
-  - _Result: ✅ All compatibility issues resolved_
-
-**Upgrade Notes:**
-- Gradio 6.0.2 brings improved performance and stability
-- **Breaking changes fixed:**
-  - `gr.Blocks(theme=...)` → `demo.theme = ...`
-  - `gr.Chatbot(show_copy_button=True)` → removed (deprecated)
-  - `gr.Chatbot(type="messages")` → removed (auto-detected)
-- All existing functionality remains compatible after fixes
-- Session isolation working correctly
-- UI components render properly
-- Interface successfully running on http://127.0.0.1:7860
-
----
-
-## Summary
-
-**Completed:** All Core Phases (1-6) + Testing + Documentation ✅
-**Remaining:** Optional tasks only (marked with *)
-**Total Subtasks Completed:** 35+ core subtasks
-**Optional Tasks Remaining:** ~10 (integration tests, additional docs, manual testing)
-
-**Current Status:**
-- ✅ SpiritualAssistant implemented and tested (13/13 tests)
-- ✅ CombinedAssistant implemented and tested (14/14 tests)
-- ✅ AssistantMode enum created
-- ✅ Entry Classifier updated with S indicator and K/L/S/T format
-- ✅ SessionState updated with spiritual and combined fields
-- ✅ App integration completed (Task 4)
-- ✅ UI mode selector added (Task 5)
-- ✅ Error handling implemented (Task 6)
-- ✅ Core testing completed (Task 7.1: 27/27 tests passed)
-- ✅ README.md updated (Task 8.1)
-- ✅ **Gradio upgraded to 6.0.2** (December 5, 2025)
-
-**Completed Phases:**
-- ✅ Phase 1: Core Components (Tasks 1-3)
-- ✅ Phase 2: App Integration (Task 4)
-- ✅ Phase 3: UI Updates (Task 5)
-- ✅ Phase 4: Error Handling (Task 6)
-- ✅ Phase 5: Core Testing (Task 7.1)
-- ✅ Phase 6: Core Documentation (Task 8.1)
-
-**Git Commits:**
-1. ✅ feat: Task 4 - Integrate Spiritual and Combined assistants into app (commit 05f446c)
-2. ✅ feat: Task 5.1-5.2 - Add Assistant Mode selector to UI (commit 537b5b3)
-3. ✅ feat: Task 6 - Add comprehensive error handling and fallback (commit 45a1a24)
-4. ✅ docs: Update README.md with multi-mode integration features (commit 062b240)
-
-**Technology Stack:**
-- Python 3.14.0
-- Gradio 6.0.2 (upgraded from 5.3.0)
-- Google Gemini API
-- Pytest 9.0.1
-
-**Next Steps (Optional):**
-1. Task 7.2-7.4: Additional integration and property-based tests
-2. Task 8.2-8.4: Update QUICK_START.md, create USER_GUIDE.md
-3. Task 9: Final manual testing and validation
-
-**Status:** ✅ **READY FOR PRODUCTION** - All core requirements (1.1-11.5) implemented and tested

.kiro/specs/simplified-spiritual-triage/design.md

@@ -1,240 +0,0 @@
-# Design Document: Simplified Spiritual Triage
-
-## Overview
-
-Спрощена архітектура Medical Brain з фоновим моніторингом духовного здоров'я. Система працює в єдиному Medical режимі з невидимим для користувача Spiritual Monitor, який автоматично виявляє ознаки дистресу та ініціює делікатний тріаж при необхідності.
-
-## Architecture
-
-```mermaid
-flowchart TD
-    subgraph Input
-        MSG[Patient Message]
-    end
-    
-    subgraph "Background Processing"
-        SM[Spiritual Monitor<br/>Classifier]
-    end
-    
-    subgraph "State Machine"
-        GREEN[🟢 Green State<br/>Normal Medical Dialog]
-        YELLOW[🟡 Yellow State<br/>Soft Triage Mode]
-        RED[🔴 Red State<br/>Crisis Support]
-    end
-    
-    subgraph "Output"
-        MED[Medical Response]
-        TRIAGE[Triage Question]
-        CRISIS[Crisis Support +<br/>Referral Generation]
-    end
-    
-    MSG --> SM
-    SM -->|"No indicators"| GREEN
-    SM -->|"Potential indicators"| YELLOW
-    SM -->|"Severe indicators"| RED
-    
-    GREEN --> MED
-    YELLOW --> TRIAGE
-    TRIAGE -->|"Patient OK"| GREEN
-    TRIAGE -->|"Distress confirmed<br/>or 3+ exchanges"| RED
-    RED --> CRISIS
-```
-
-## Components and Interfaces
-
-### 1. SpiritualMonitor (Classifier)
-
-**Purpose:** Фоновий аналіз кожного повідомлення на ознаки духовного дистресу.
-
-**Interface:**
-```python
-class SpiritualMonitor:
-    def classify(self, message: str, conversation_history: List[str]) -> SpiritualState:
-        """
-        Returns: SpiritualState (GREEN, YELLOW, RED)
-        """
-```
-
-**Classification Logic:**
-- GREEN: Немає індикаторів дистресу
-- YELLOW: Потенційні індикатори (смуток, тривога, питання про сенс)
-- RED: Серйозні індикатори (думки про смерть, безнадія, суїцидальні ідеї)
-
-### 2. SoftTriageManager
-
-**Purpose:** Управління делікатним психологічним тріажем при Yellow Flag.
-
-**Interface:**
-```python
-class SoftTriageManager:
-    def __init__(self):
-        self.question_count: int = 0
-        self.max_questions: int = 3
-        self.triage_history: List[str] = []
-    
-    def generate_question(self, context: str, patient_language: str) -> str:
-        """Generate empathetic clarifying question"""
-    
-    def evaluate_response(self, response: str) -> TriageOutcome:
-        """
-        Returns: TriageOutcome (RESOLVED_GREEN, ESCALATE_RED, CONTINUE)
-        """
-    
-    def should_force_decision(self) -> bool:
-        """Returns True if max questions reached"""
-```
-
-### 3. SessionStateManager
-
-**Purpose:** Управління станом духовного моніторингу в сесії.
-
-**Interface:**
-```python
-class SessionStateManager:
-    current_state: SpiritualState  # GREEN, YELLOW, RED
-    triage_question_count: int
-    triage_context: List[str]
-    
-    def transition_to(self, new_state: SpiritualState) -> None
-    def reset(self) -> None
-    def get_state(self) -> SpiritualState
-```
-
-### 4. MedicalAssistant (Simplified)
-
-**Purpose:** Основний медичний асистент без Lifestyle функціоналу.
-
-**Changes from current:**
-- Видалено: Lifestyle mode, Combined mode
-- Залишено: Medical dialog, Spiritual integration
-- Додано: Integration with SpiritualMonitor
-
-## Data Models
-
-```python
-from enum import Enum
-from dataclasses import dataclass
-from typing import List, Optional
-
-class SpiritualState(Enum):
-    GREEN = "green"   # Normal - no distress
-    YELLOW = "yellow" # Potential - needs triage
-    RED = "red"       # Severe - needs referral
-
-class TriageOutcome(Enum):
-    RESOLVED_GREEN = "resolved_green"  # Patient OK, return to medical
-    ESCALATE_RED = "escalate_red"      # Distress confirmed, generate referral
-    CONTINUE = "continue"              # Need more information
-
-@dataclass
-class SpiritualAssessment:
-    state: SpiritualState
-    indicators: List[str]
-    confidence: float
-    reasoning: str
-
-@dataclass
-class TriageSession:
-    question_count: int
-    questions_asked: List[str]
-    patient_responses: List[str]
-    outcome: Optional[TriageOutcome]
-
-@dataclass
-class SessionState:
-    spiritual_state: SpiritualState
-    triage_session: Optional[TriageSession]
-    conversation_history: List[str]
-```
-
-## Correctness Properties
-
-*A property is a characteristic or behavior that should hold true across all valid executions of a system-essentially, a formal statement about what the system should do. Properties serve as the bridge between human-readable specifications and machine-verifiable correctness guarantees.*
-
-### Property 1: Spiritual Monitor Always Invoked
-*For any* patient message, the Spiritual Monitor SHALL be invoked to classify the message before generating a response.
-**Validates: Requirements 2.1**
-
-### Property 2: Green State Preservation
-*For any* message classified as no-distress (GREEN), the system SHALL remain in GREEN state and continue medical dialog.
-**Validates: Requirements 2.2**
-
-### Property 3: Yellow Triggers Triage
-*For any* message classified as potential-distress (YELLOW), the system SHALL enter YELLOW state and initiate Soft Triage.
-**Validates: Requirements 2.3**
-
-### Property 4: Red Triggers Immediate Referral
-*For any* message classified as severe-distress (RED), the system SHALL generate a referral immediately without triage.
-**Validates: Requirements 2.4**
-
-### Property 5: Triage Question Limit
-*For any* Soft Triage session, the number of clarifying questions SHALL NOT exceed 3.
-**Validates: Requirements 3.1, 7.2**
-
-### Property 6: Triage Binary Outcome
-*For any* completed Soft Triage session, the outcome SHALL be either GREEN (resolved) or RED (escalated), never YELLOW.
-**Validates: Requirements 3.3**
-
-### Property 7: Triage Timeout Escalation
-*For any* Soft Triage session that reaches 3 exchanges without clear resolution, the system SHALL escalate to RED.
-**Validates: Requirements 3.6**
-
-### Property 8: State Validity
-*For any* point in conversation, the spiritual state SHALL be exactly one of: GREEN, YELLOW, or RED.
-**Validates: Requirements 5.1, 7.1**
-
-### Property 9: Conservative Classification
-*For any* ambiguous message, the system SHALL prefer YELLOW over GREEN (conservative approach).
-**Validates: Requirements 5.2**
-
-### Property 10: Red Flag Keywords
-*For any* message containing death, hopelessness, or suicidal ideation keywords, the classification SHALL be RED.
-**Validates: Requirements 5.4**
-
-### Property 11: Referral Generation on Red
-*For any* RED state confirmation, the system SHALL generate a referral message.
-**Validates: Requirements 6.1**
-
-### Property 12: Referral Content Completeness
-*For any* generated referral, the message SHALL contain: patient concerns, distress indicators, and conversation context.
-**Validates: Requirements 6.2**
-
-### Property 13: Language Matching
-*For any* system response, the language SHALL match the patient's input language.
-**Validates: Requirements 8.1, 8.2, 8.3, 8.4**
-
-### Property 14: Session Reset
-*For any* session end, the spiritual state SHALL reset to GREEN.
-**Validates: Requirements 7.4**
-
-## Error Handling
-
-### Classification Errors
-- If Spiritual Monitor fails → Default to YELLOW (conservative)
-- If triage question generation fails → Use fallback generic question
-- If referral generation fails → Provide crisis hotline information
-
-### State Errors
-- Invalid state transition → Log error, maintain current state
-- Missing triage context → Reset to GREEN with warning
-
-## Testing Strategy
-
-### Unit Tests
-- SpiritualMonitor classification accuracy
-- SoftTriageManager question generation
-- SessionStateManager state transitions
-- Referral message content validation
-
-### Property-Based Tests (fast-check)
-- Property 1-14 as defined above
-- Use generators for:
-  - Random patient messages (with/without distress indicators)
-  - Random conversation histories
-  - Random triage responses
-
-### Integration Tests
-- Full flow: GREEN → YELLOW → GREEN (resolved)
-- Full flow: GREEN → YELLOW → RED (escalated)
-- Full flow: GREEN → RED (immediate)
-- Language matching across all flows

.kiro/specs/simplified-spiritual-triage/requirements.md

@@ -1,106 +0,0 @@
-# Requirements Document
-
-## Introduction
-
-Спрощена версія Medical Brain з інтегрованим фоновим моніторингом духовного здоров'я. Система базується на медичному діалозі з автоматичним виявленням ознак духовного/емоційного дистресу та делікатним психологічним тріажем при необхідності.
-
-## Glossary
-
-- **Medical Dialog**: Базовий режим медичної консультації пацієнта
-- **Spiritual Monitor**: Фоновий класифікатор для виявлення ознак духовного дистресу
-- **Green State**: Нормальний стан - медичний діалог без ознак дистресу
-- **Yellow Flag**: Потенційні ознаки дистресу - потребує делікатного тріажу
-- **Red Flag**: Підтверджений серйозний дистрес - потребує негайного направлення
-- **Soft Triage**: Делікатне психологічне розпитування (2-3 питання) для уточнення стану
-- **Referral**: Направлення до служби духовної опіки (chaplain team)
-
-## Requirements
-
-### Requirement 1: Simplified Architecture
-
-**User Story:** As a system administrator, I want a simplified application architecture, so that the system is easier to maintain and more focused on core functionality.
-
-#### Acceptance Criteria
-
-1. WHEN the application starts THEN the system SHALL operate in Medical mode as the default and only explicit mode
-2. WHEN the Lifestyle mode code is removed THEN the system SHALL maintain all Medical and Spiritual functionality without errors
-3. WHEN a user interacts with the system THEN the system SHALL present a single unified medical assistant interface
-
-### Requirement 2: Background Spiritual Monitoring
-
-**User Story:** As a healthcare provider, I want the system to automatically monitor patient messages for spiritual distress indicators, so that patients in need receive appropriate support without explicit mode switching.
-
-#### Acceptance Criteria
-
-1. WHEN a patient sends any message THEN the Spiritual Monitor SHALL analyze the message for distress indicators in the background
-2. WHEN the Spiritual Monitor detects no distress indicators THEN the system SHALL continue normal Medical dialog (Green State)
-3. WHEN the Spiritual Monitor detects potential distress indicators (Yellow Flag) THEN the system SHALL initiate Soft Triage
-4. WHEN the Spiritual Monitor detects severe distress indicators (Red Flag) THEN the system SHALL immediately generate a referral and provide crisis support
-
-### Requirement 3: Soft Psychological Triage
-
-**User Story:** As a patient experiencing emotional difficulties, I want the system to gently check on my wellbeing without being intrusive, so that I feel supported but not interrogated.
-
-#### Acceptance Criteria
-
-1. WHEN Soft Triage is initiated THEN the system SHALL ask no more than 2-3 clarifying questions
-2. WHEN asking clarifying questions THEN the system SHALL use empathetic, non-judgmental language in the patient's language
-3. WHEN the patient responds to triage questions THEN the system SHALL evaluate responses to determine Green or Red outcome
-4. WHEN Soft Triage determines the patient is coping well THEN the system SHALL return to Green State (Medical dialog) naturally
-5. WHEN Soft Triage confirms significant distress THEN the system SHALL escalate to Red Flag with referral generation
-6. WHEN Soft Triage exceeds 3 exchanges without resolution THEN the system SHALL make a conservative decision (escalate to Red if uncertain)
-
-### Requirement 4: Seamless User Experience
-
-**User Story:** As a patient, I want the spiritual health monitoring to be invisible and natural, so that I don't feel like I'm being assessed or categorized.
-
-#### Acceptance Criteria
-
-1. WHEN the system transitions between states THEN the patient SHALL NOT see explicit mode switching notifications
-2. WHEN Soft Triage questions are asked THEN the questions SHALL feel like natural conversation continuation
-3. WHEN returning from Yellow to Green state THEN the system SHALL smoothly continue medical conversation
-4. WHEN escalating to Red Flag THEN the system SHALL communicate support compassionately without alarming language
-
-### Requirement 5: Classification Logic
-
-**User Story:** As a clinical specialist, I want clear classification criteria for spiritual distress, so that the system makes consistent and appropriate decisions.
-
-#### Acceptance Criteria
-
-1. WHEN classifying messages THEN the system SHALL use three levels: Green (none), Yellow (potential), Red (severe)
-2. WHEN uncertain between Green and Yellow THEN the system SHALL default to Yellow for safety
-3. WHEN uncertain between Yellow and Red THEN the system SHALL use Soft Triage to clarify
-4. WHEN the patient mentions death, hopelessness, or suicidal ideation THEN the system SHALL classify as Red Flag immediately
-
-### Requirement 6: Referral Generation
-
-**User Story:** As a chaplain, I want to receive clear, actionable referral messages, so that I can provide appropriate spiritual care to patients in need.
-
-#### Acceptance Criteria
-
-1. WHEN a Red Flag is confirmed THEN the system SHALL generate a professional referral message
-2. WHEN generating referrals THEN the system SHALL include patient concerns, distress indicators, and conversation context
-3. WHEN generating referrals THEN the system SHALL use multi-faith inclusive language
-4. WHEN generating referrals THEN the system SHALL write in the patient's language
-
-### Requirement 7: State Management
-
-**User Story:** As a developer, I want clear state management for the spiritual monitoring flow, so that the system behavior is predictable and debuggable.
-
-#### Acceptance Criteria
-
-1. WHEN tracking conversation state THEN the system SHALL maintain current spiritual state (Green/Yellow/Red)
-2. WHEN in Yellow state THEN the system SHALL track triage question count (max 3)
-3. WHEN state changes THEN the system SHALL log the transition for debugging
-4. WHEN session ends THEN the system SHALL reset spiritual state to Green
-
-### Requirement 8: Language Support
-
-**User Story:** As a Ukrainian-speaking patient, I want all system responses in my language, so that I can communicate naturally and feel understood.
-
-#### Acceptance Criteria
-
-1. WHEN the patient writes in Ukrainian THEN the system SHALL respond in Ukrainian
-2. WHEN the patient writes in English THEN the system SHALL respond in English
-3. WHEN generating triage questions THEN the system SHALL match the patient's language
-4. WHEN generating referrals THEN the system SHALL match the patient's language

.kiro/specs/simplified-spiritual-triage/tasks.md

@@ -1,215 +0,0 @@
-# Implementation Plan
-
-## Phase 1: Create Simplified Architecture (Alternative Approach)
-
-**Note:** Instead of modifying the existing codebase, we created a new simplified implementation that can run alongside the existing one. This allows for gradual migration and testing.
-
-- [x] 1. Create new simplified components ✅
-  - [x] 1.1 Create SimplifiedMedicalApp (src/core/simplified_medical_app.py) ✅
-    - Medical-only mode with background spiritual monitoring
-    - No Lifestyle mode
-    - _Requirements: 1.1, 1.2_
-  - [x] 1.2 Create simplified Gradio interface (src/interface/simplified_gradio_app.py) ✅
-    - Single unified medical interface
-    - No mode selector
-    - _Requirements: 1.3_
-  - [x] 1.3 Create launch script (run_simplified_app.py) ✅
-    - Easy launch for simplified version
-    - _Requirements: 1.1_
-
-**Cleanup tasks (optional, for later):**
-- [ ] 1.4 Remove old Lifestyle code (when ready to fully migrate)
-  - Delete src/core/combined_assistant.py
-  - Remove LIFESTYLE, COMBINED from AssistantMode enum
-  - Update lifestyle_app.py
-  - _Requirements: 1.2_
-
-## Phase 2: Implement Spiritual State Machine
-
-- [x] 2. Create SpiritualState and data models
-  - [x] 2.1 Create src/core/spiritual_state.py with enums and dataclasses ✅
-    - SpiritualState enum (GREEN, YELLOW, RED)
-    - TriageOutcome enum
-    - SpiritualAssessment dataclass
-    - TriageSession dataclass
-    - SessionSpiritualState class (combined state manager)
-    - _Requirements: 5.1, 7.1_
-  - [x] 2.2 Write property test for state validity ✅
-    - **Property 8: State Validity** - 5 tests
-    - **Validates: Requirements 5.1, 7.1**
-
-- [x] 3. Implement SessionStateManager
-  - [x] 3.1 Create SessionStateManager class ✅
-    - Track current spiritual state
-    - Track triage question count
-    - Implement state transitions
-    - _Requirements: 7.1, 7.2_
-  - [x] 3.2 Write property test for session reset ✅
-    - **Property 14: Session Reset** - 5 tests
-    - **Validates: Requirements 7.4**
-
-## Phase 3: Implement Spiritual Monitor
-
-- [x] 4. Refactor SpiritualDistressAnalyzer to SpiritualMonitor
-  - [x] 4.1 Simplify classification to GREEN/YELLOW/RED ✅
-    - Created new src/core/spiritual_monitor.py
-    - Return SpiritualState instead of DistressClassification
-    - _Requirements: 2.1, 5.1_
-  - [ ] 4.2 Write property test for monitor invocation
-    - **Property 1: Spiritual Monitor Always Invoked**
-    - **Validates: Requirements 2.1**
-  - [x] 4.3 Write property test for conservative classification ✅
-    - **Property 9: Conservative Classification** - 4 tests
-    - **Validates: Requirements 5.2**
-  - [x] 4.4 Write property test for red flag keywords ✅
-    - **Property 10: Red Flag Keywords** - 8 tests
-    - **Validates: Requirements 5.4**
-
-- [x] 5. Checkpoint - Ensure all tests pass ✅
-  - 22 state property tests passed
-  - 42 monitor property tests passed
-  - Total: 64 tests passing
-
-## Phase 4: Implement Soft Triage Manager
-
-- [x] 6. Create SoftTriageManager ✅
-  - [x] 6.1 Implement triage question generation ✅
-    - Generate empathetic clarifying questions
-    - Use LLM with appropriate prompt
-    - Match patient language
-    - _Requirements: 3.1, 3.2, 8.3_
-  - [x] 6.2 Implement response evaluation ✅
-    - Evaluate patient responses
-    - Determine TriageOutcome (RESOLVED_GREEN, ESCALATE_RED, CONTINUE)
-    - _Requirements: 3.3_
-  - [x] 6.3 Implement question limit enforcement ✅
-    - Track question count (max 3)
-    - Force decision after 3 exchanges
-    - _Requirements: 3.1, 3.6_
-  - [x] 6.4 Write property test for triage question limit ✅
-    - **Property 5: Triage Question Limit** - 4 tests
-    - **Validates: Requirements 3.1, 7.2**
-  - [x] 6.5 Write property test for triage binary outcome ✅
-    - **Property 6: Triage Binary Outcome** - 5 tests
-    - **Validates: Requirements 3.3**
-  - [x] 6.6 Write property test for triage timeout escalation ✅
-    - **Property 7: Triage Timeout Escalation** - 3 tests
-    - **Validates: Requirements 3.6**
-
-## Phase 5: Integrate into Main App
-
-- [x] 7. Integrate Spiritual Monitor into message processing ✅
-  - [x] 7.1 Update process_message to use SpiritualMonitor ✅
-    - Created SimplifiedMedicalApp with integrated monitoring
-    - Call monitor for every message
-    - Route based on SpiritualState
-    - _Requirements: 2.1, 2.2, 2.3, 2.4_
-  - [x] 7.2 Write property test for green state preservation ✅
-    - **Property 2: Green State Preservation** - 4 tests
-    - **Validates: Requirements 2.2**
-  - [x] 7.3 Write property test for yellow triggers triage ✅
-    - **Property 3: Yellow Triggers Triage** - 4 tests
-    - **Validates: Requirements 2.3**
-  - [x] 7.4 Write property test for red triggers referral ✅
-    - **Property 4: Red Triggers Immediate Referral** - 8 tests
-    - **Validates: Requirements 2.4**
-
-- [x] 8. Implement state transitions in app ✅
-  - [x] 8.1 Handle GREEN → YELLOW transition ✅
-    - Initiate SoftTriageManager
-    - Generate first triage question
-    - _Requirements: 2.3, 3.1_
-  - [x] 8.2 Handle YELLOW → GREEN transition (resolved) ✅
-    - Return to medical dialog
-    - Reset triage session
-    - _Requirements: 3.4_
-  - [x] 8.3 Handle YELLOW → RED transition (escalated) ✅
-    - Generate referral
-    - Provide crisis support
-    - _Requirements: 3.5, 6.1_
-
-- [x] 9. Checkpoint - Ensure all tests pass ✅
-  - 113 tests passing (22 state + 42 monitor + 22 triage + 27 integration)
-
-## Phase 6: Update Referral Generation
-
-- [x] 10. Ensure referral generation works with new flow ✅
-  - [x] 10.1 Update ReferralMessageGenerator for simplified flow ✅
-    - Integrated into SimplifiedMedicalApp._generate_referral
-    - Accept SpiritualAssessment instead of DistressClassification
-    - Include triage context if available
-    - _Requirements: 6.1, 6.2_
-  - [x] 10.2 Write property test for referral generation on red ✅
-    - **Property 11: Referral Generation on Red** - 3 tests
-    - **Validates: Requirements 6.1**
-  - [x] 10.3 Write property test for referral content completeness ✅
-    - **Property 12: Referral Content Completeness** - 4 tests
-    - **Validates: Requirements 6.2**
-
-## Phase 7: Language Support
-
-- [x] 11. Ensure language matching across all components ✅
-  - [x] 11.1 Verify SpiritualMonitor language handling ✅
-    - Classification reasoning in patient language
-    - _Requirements: 8.1, 8.2_
-  - [x] 11.2 Verify SoftTriageManager language handling ✅
-    - Questions in patient language
-    - Fallback questions in both languages
-    - _Requirements: 8.3_
-  - [x] 11.3 Verify ReferralMessageGenerator language handling ✅
-    - Crisis responses in patient language
-    - Triage resolution in patient language
-    - _Requirements: 8.4_
-  - [x] 11.4 Write property test for language matching ✅
-    - **Property 13: Language Matching** - 10 tests
-    - **Validates: Requirements 8.1, 8.2, 8.3, 8.4**
-
-## Phase 8: UI Simplification
-
-- [x] 12. Simplify Gradio interface ✅
-  - [x] 12.1 Remove mode selector from UI ✅
-    - Created simplified_gradio_app.py
-    - Single medical assistant interface
-    - No visible mode switching
-    - _Requirements: 1.3, 4.1_
-  - [x] 12.2 Update status display ✅
-    - Show spiritual state for debugging (optional)
-    - Clean user-facing interface
-    - _Requirements: 4.1_
-  - [x] 12.3 Remove Edit Prompts for Lifestyle ✅
-    - Simplified interface has no prompt editing
-    - _Requirements: 1.1_
-
-## Phase 9: Final Testing and Cleanup
-
-- [x] 13. Final integration testing ✅
-  - [x] 13.1 Test full flow: GREEN → YELLOW → GREEN ✅
-    - Property test: test_green_to_yellow_to_green_flow
-    - _Requirements: 2.2, 2.3, 3.4_
-  - [x] 13.2 Test full flow: GREEN → YELLOW → RED ✅
-    - Property test: test_green_to_yellow_to_red_flow
-    - _Requirements: 2.3, 3.5, 6.1_
-  - [x] 13.3 Test full flow: GREEN → RED (immediate) ✅
-    - Property test: test_green_to_red_immediate_flow
-    - _Requirements: 2.4, 6.1_
-  - [x] 13.4 Test language switching ✅
-    - Property tests for English and Ukrainian
-    - _Requirements: 8.1, 8.2_
-
-- [ ] 14. Cleanup and documentation
-  - [ ] 14.1 Remove unused Lifestyle code files
-    - Delete deprecated files
-    - Update imports
-    - _Requirements: 1.2_
-  - [ ] 14.2 Update README for simplified architecture
-    - Document new flow
-    - Update quick start guide
-    - _Requirements: 1.1_
-
-- [x] 15. Final Checkpoint - Property Tests ✅
-  - **130 tests passing**
-  - 22 state property tests
-  - 42 monitor property tests
-  - 22 triage property tests
-  - 27 integration property tests
-  - 17 referral/language property tests

.kiro/specs/spiritual-health-assessment/design.md

@@ -1,558 +0,0 @@
-# Design Document - Spiritual Health Assessment Tool
-
-## Overview
-
-The Spiritual Health Assessment Tool is a clinical decision support application that helps healthcare providers identify patients who may benefit from spiritual care services. The system leverages Large Language Models (LLMs) to analyze patient conversations, detect emotional and spiritual distress indicators, classify severity levels, and generate appropriate referral messages. The tool includes a validation interface where clinical staff can review AI assessments and provide feedback to improve system accuracy over time.
-
-**Key Design Principles:**
-- **Safety-first approach**: Conservative classification with human oversight
-- **Reuse existing architecture**: Leverage proven patterns from Lifestyle Journey project
-- **Simple, testable components**: Clear separation of concerns
-- **Feedback-driven improvement**: Store provider feedback for system refinement
-- **Multi-faith sensitivity**: Inclusive language and approach
-
-## Architecture
-
-### High-Level Architecture
-
-```mermaid
-graph TD
-    A[Patient Input] --> B[Distress Analyzer]
-    B --> C{Classification}
-    C -->|Red Flag| D[Referral Generator]
-    C -->|Yellow Flag| E[Question Generator]
-    C -->|No Flag| F[No Action]
-    E --> G[Follow-up Analysis]
-    G --> C
-    D --> H[Validation Interface]
-    H --> I[Provider Feedback]
-    I --> J[Feedback Storage]
-```
-
-### Component Architecture
-
-The system **reuses existing Lifestyle Journey architecture** with minimal new components:
-
-```
-spiritual-health-assessment/
-├── src/
-│   ├── core/
-│   │   ├── ai_client.py              # ✅ REUSED: AIClientManager
-│   │   ├── core_classes.py           # ✅ REUSED: Base dataclasses pattern
-│   │   └── spiritual_classes.py      # 🆕 NEW: Spiritual-specific classes
-│   ├── interface/
-│   │   ├── gradio_app.py             # ✅ REUSED: Gradio patterns
-│   │   └── spiritual_interface.py    # 🆕 NEW: Spiritual validation UI
-│   ├── prompts/
-│   │   └── spiritual_prompts.py      # 🆕 NEW: Spiritual LLM prompts
-│   └── storage/
-│       └── feedback_store.py         # 🆕 NEW: Feedback persistence
-├── data/
-│   └── spiritual_distress_definitions.json  # Parsed from PDF
-├── spiritual_app.py                  # 🆕 NEW: Main entry point
-└── requirements.txt                  # ✅ REUSED: Same dependencies
-```
-
-**Reuse Strategy:**
-- **AIClientManager**: Use existing multi-provider AI client management
-- **Dataclass patterns**: Follow ClinicalBackground/LifestyleProfile structure
-- **Gradio patterns**: Reuse SessionData, session isolation, tab structure
-- **Prompt patterns**: Follow existing SYSTEM_PROMPT_* and PROMPT_* conventions
-- **Testing patterns**: Adapt TestingDataManager approach for feedback storage
-
-## Components and Interfaces
-
-### 1. Core Data Classes (`spiritual_classes.py`)
-
-**Following existing dataclass patterns from core_classes.py:**
-
-**PatientInput** (similar to ChatMessage)
-```python
-@dataclass
-class PatientInput:
-    message: str
-    timestamp: str  # ISO format like ChatMessage
-    conversation_history: List[str] = None
-    
-    def __post_init__(self):
-        if self.conversation_history is None:
-            self.conversation_history = []
-```
-
-**DistressClassification** (similar to SessionState)
-```python
-@dataclass
-class DistressClassification:
-    flag_level: str  # "red", "yellow", "none"
-    indicators: List[str] = None
-    categories: List[str] = None
-    confidence: float = 0.0
-    reasoning: str = ""
-    timestamp: str = ""
-    
-    def __post_init__(self):
-        if self.indicators is None:
-            self.indicators = []
-        if self.categories is None:
-            self.categories = []
-        if not self.timestamp:
-            self.timestamp = datetime.now().isoformat()
-```
-
-**ReferralMessage** (similar to ChatMessage structure)
-```python
-@dataclass
-class ReferralMessage:
-    patient_concerns: str
-    distress_indicators: List[str] = None
-    context: str = ""
-    message_text: str = ""
-    timestamp: str = ""
-    
-    def __post_init__(self):
-        if self.distress_indicators is None:
-            self.distress_indicators = []
-        if not self.timestamp:
-            self.timestamp = datetime.now().isoformat()
-```
-
-**ProviderFeedback** (similar to SessionState tracking)
-```python
-@dataclass
-class ProviderFeedback:
-    assessment_id: str
-    provider_id: str = "provider_001"
-    agrees_with_classification: bool = False
-    agrees_with_referral: bool = False
-    comments: str = ""
-    timestamp: str = ""
-    
-    def __post_init__(self):
-        if not self.timestamp:
-            self.timestamp = datetime.now().isoformat()
-```
-
-### 2. Spiritual Distress Analyzer (`spiritual_analyzer.py`)
-
-**SpiritualDistressAnalyzer** (follows EntryClassifier/MedicalAssistant pattern)
-- **Purpose**: Main orchestrator for distress detection and classification
-- **Initialization**: `def __init__(self, api: AIClientManager)` - reuses existing AI client
-- **Methods**:
-  - `analyze_message(patient_input: PatientInput) -> DistressClassification`
-  - `generate_clarifying_questions(classification: DistressClassification) -> List[str]`
-  - `re_evaluate_with_followup(original_input, followup_answers) -> DistressClassification`
-
-**Implementation approach** (following existing patterns):
-- Uses `self.api.generate_response()` like other assistants
-- Follows SYSTEM_PROMPT_* and PROMPT_* function pattern from prompts.py
-- Implements conservative classification logic (when uncertain, escalate to yellow flag)
-- Maintains conversation context similar to MainLifestyleAssistant
-- Uses JSON response parsing like EntryClassifier
-
-### 3. Referral Message Generator (`spiritual_analyzer.py`)
-
-**ReferralMessageGenerator**
-- **Purpose**: Creates professional referral messages for spiritual care team
-- **Methods**:
-  - `generate_referral(classification: DistressClassification, patient_input: PatientInput) -> ReferralMessage`
-
-**Message structure**:
-- Patient's expressed concerns (direct quotes when appropriate)
-- Specific distress indicators detected
-- Relevant conversation context
-- Professional, compassionate tone
-- Multi-faith inclusive language
-
-### 4. Question Generator (`spiritual_analyzer.py`)
-
-**ClarifyingQuestionGenerator**
-- **Purpose**: Generates empathetic follow-up questions for yellow flag cases
-- **Methods**:
-  - `generate_questions(classification: DistressClassification) -> List[str]`
-
-**Question characteristics**:
-- Open-ended to encourage patient expression
-- Clinically appropriate and empathetic
-- Focused on clarifying ambiguous indicators
-- Maximum 2-3 questions to avoid overwhelming patient
-
-### 5. Validation Interface (`gradio_interface.py`)
-
-**UI Components**:
-- **Input Panel**: Text area for patient message input
-- **Results Display**: 
-  - Classification badge (red/yellow/green color-coded)
-  - Detected indicators list
-  - LLM reasoning explanation
-  - Generated referral message (if applicable)
-  - Generated questions (if yellow flag)
-- **Feedback Panel**:
-  - Agreement checkboxes (classification, referral message)
-  - Comments text area
-  - Submit feedback button
-- **History Panel**: Previous assessments with feedback status
-
-**Interface Features**:
-- Real-time assessment processing
-- Clear visual hierarchy with color coding
-- Responsive design for clinical workflows
-- Export functionality for feedback data
-
-### 6. Feedback Storage (`feedback_store.py`)
-
-**FeedbackStore**
-- **Purpose**: Persist provider feedback for analysis and improvement
-- **Methods**:
-  - `save_feedback(feedback: ProviderFeedback) -> str`  # Returns feedback_id
-  - `get_feedback_by_id(feedback_id: str) -> ProviderFeedback`
-  - `get_all_feedback() -> List[ProviderFeedback]`
-  - `export_to_csv(output_path: str) -> bool`
-  - `get_accuracy_metrics() -> Dict`
-
-**Storage format**: JSON files with structured records
-- One file per assessment with feedback
-- Indexed by assessment_id for quick retrieval
-- Includes full context for later analysis
-
-### 7. Reference Data Loader (`spiritual_analyzer.py`)
-
-**SpiritualDistressDefinitions**
-- **Purpose**: Load and manage spiritual distress definitions from reference document
-- **Methods**:
-  - `load_definitions(file_path: str) -> Dict`
-  - `get_definition(category: str) -> str`
-  - `get_all_categories() -> List[str]`
-
-**Data structure**:
-```python
-{
-    "category_name": {
-        "definition": "...",
-        "red_flag_examples": ["...", "..."],
-        "yellow_flag_examples": ["...", "..."],
-        "keywords": ["...", "..."]
-    }
-}
-```
-
-## Data Models
-
-### Assessment Record
-```json
-{
-    "assessment_id": "uuid",
-    "timestamp": "2025-12-04T10:30:00Z",
-    "patient_input": {
-        "message": "I am angry all the time",
-        "conversation_history": []
-    },
-    "classification": {
-        "flag_level": "red",
-        "indicators": ["persistent anger", "emotional distress"],
-        "categories": ["anger", "emotional_suffering"],
-        "confidence": 0.92,
-        "reasoning": "Patient explicitly states persistent anger..."
-    },
-    "referral_message": {
-        "patient_concerns": "Persistent anger affecting daily life",
-        "distress_indicators": ["anger", "emotional_distress"],
-        "context": "Patient reports feeling angry all the time",
-        "message_text": "Referral for spiritual care: Patient expressing..."
-    },
-    "provider_feedback": {
-        "provider_id": "provider_123",
-        "agrees_with_classification": true,
-        "agrees_with_referral": true,
-        "comments": "Accurate assessment",
-        "timestamp": "2025-12-04T10:35:00Z"
-    }
-}
-```
-
-### Spiritual Distress Definitions
-```json
-{
-    "anger": {
-        "definition": "Persistent feelings of anger, resentment, or hostility",
-        "red_flag_examples": [
-            "I am angry all the time",
-            "I can't control my rage",
-            "I hate everyone"
-        ],
-        "yellow_flag_examples": [
-            "I've been feeling frustrated lately",
-            "Things are bothering me more than usual"
-        ],
-        "keywords": ["angry", "rage", "resentment", "hostility", "furious"]
-    },
-    "persistent_sadness": {
-        "definition": "Ongoing feelings of sadness, grief, or depression",
-        "red_flag_examples": [
-            "I am crying all the time",
-            "I can't stop feeling sad",
-            "Life has no meaning anymore"
-        ],
-        "yellow_flag_examples": [
-            "I've been feeling down",
-            "I cry more than I used to"
-        ],
-        "keywords": ["sad", "crying", "depressed", "grief", "hopeless"]
-    }
-}
-```
-
-## Correctness Properties
-
-*A property is a characteristic or behavior that should hold true across all valid executions of a system-essentially, a formal statement about what the system should do. Properties serve as the bridge between human-readable specifications and machine-verifiable correctness guarantees.*
-
-### Property 1: Analysis execution for all inputs
-*For any* patient message submitted, the System should return a classification object with flag_level, indicators, and reasoning fields
-**Validates: Requirements 1.1**
-
-### Property 2: Classification uses definitions
-*For any* patient message with known distress indicators from the definitions, the System should classify them into the corresponding predefined categories
-**Validates: Requirements 1.2**
-
-### Property 3: Multi-category detection completeness
-*For any* patient input containing multiple distress indicators from different categories, the System should identify all applicable categories in the classification
-**Validates: Requirements 1.3**
-
-### Property 4: Response time performance
-*For any* patient message submission, the System should return classification results within 5 seconds
-**Validates: Requirements 1.4**
-
-### Property 5: No-flag classification for neutral input
-*For any* patient input containing no distress indicators, the System should return a classification with flag_level "none"
-**Validates: Requirements 1.5**
-
-### Property 6: Red flag detection for severe distress
-*For any* patient input containing explicit severe distress statements from the red flag definitions, the System should classify it with flag_level "red"
-**Validates: Requirements 2.1**
-
-### Property 7: Referral generation for red flags
-*For any* classification with flag_level "red", the System should generate a referral message
-**Validates: Requirements 2.4, 4.1**
-
-### Property 8: Red flag indicator completeness
-*For any* patient input with multiple red flag indicators, the System should include all detected indicators in the classification
-**Validates: Requirements 2.5**
-
-### Property 9: Yellow flag detection for ambiguous input
-*For any* patient input containing ambiguous distress indicators from yellow flag definitions, the System should classify it with flag_level "yellow"
-**Validates: Requirements 3.1**
-
-### Property 10: Question generation for yellow flags
-*For any* classification with flag_level "yellow", the System should generate at least one clarifying question
-**Validates: Requirements 3.2**
-
-### Property 11: Re-evaluation with follow-up
-*For any* yellow flag classification with follow-up answers provided, the System should produce a new classification that either escalates to red flag or clears to no flag
-**Validates: Requirements 3.3, 3.4**
-
-### Property 12: Referral message includes patient concerns
-*For any* generated referral message, it should contain the patient's expressed concerns from the original input
-**Validates: Requirements 4.2**
-
-### Property 13: Referral message includes indicators
-*For any* generated referral message, it should contain all specific distress indicators detected in the classification
-**Validates: Requirements 4.3**
-
-### Property 14: Referral message includes context
-*For any* generated referral message, it should contain relevant conversation context
-**Validates: Requirements 4.4**
-
-### Property 15: Feedback storage with unique ID
-*For any* provider feedback submission, the System should store it with a unique assessment_id
-**Validates: Requirements 6.1**
-
-### Property 16: Feedback storage completeness
-*For any* stored feedback record, it should contain all required fields: original patient input, AI classification, reasoning, provider agreement status, comments, and timestamp
-**Validates: Requirements 6.2, 6.3, 6.4, 6.5, 6.6**
-
-### Property 17: Feedback persistence round-trip
-*For any* feedback record stored with an assessment_id, retrieving it by that ID should return an equivalent feedback object
-**Validates: Requirements 6.7**
-
-### Property 18: Religion-agnostic detection
-*For any* patient input with distress indicators, the System should detect them regardless of religious affiliation mentioned in the message
-**Validates: Requirements 7.1**
-
-### Property 19: Inclusive referral language
-*For any* generated referral message, it should not contain denominational or religion-specific terms
-**Validates: Requirements 7.2**
-
-### Property 20: Religious context preservation
-*For any* patient input mentioning specific religious concerns, the generated referral message should include those religious mentions
-**Validates: Requirements 7.3**
-
-### Property 21: Non-assumptive questions
-*For any* generated clarifying questions for yellow flags, they should not contain assumptive religious language or denominational terms
-**Validates: Requirements 7.4**
-
-### Property 22: Definition-based classification
-*For any* patient input analyzed, the System should reference the loaded spiritual distress definitions when determining categories
-**Validates: Requirements 9.2**
-
-### Property 23: Definition validation
-*For any* spiritual distress definitions file loaded, the System should either successfully parse valid definitions or report specific validation errors
-**Validates: Requirements 9.4**
-
-## Error Handling
-
-### LLM API Errors
-- **Timeout**: Retry with exponential backoff (max 3 attempts)
-- **Rate limiting**: Queue requests and implement throttling
-- **Invalid response**: Log error, return conservative classification (yellow flag)
-- **Connection failure**: Display user-friendly error, suggest retry
-
-### Data Validation Errors
-- **Invalid patient input**: Display validation message, highlight required fields
-- **Malformed definitions file**: Log specific errors, prevent system startup
-- **Corrupted feedback data**: Log error, continue operation, notify administrator
-
-### Classification Edge Cases
-- **Ambiguous input**: Default to yellow flag for safety
-- **Multiple conflicting indicators**: Escalate to higher severity level
-- **Empty or very short input**: Request more information before classification
-- **Non-English input**: Attempt classification, note language in metadata
-
-### Storage Errors
-- **Disk full**: Display error, attempt to free space, notify administrator
-- **Permission denied**: Log error, attempt alternative storage location
-- **Concurrent write conflicts**: Implement file locking or use atomic writes
-
-## Testing Strategy
-
-### Unit Testing
-
-**Test coverage areas**:
-- Data class initialization and validation
-- Classification logic with known inputs
-- Referral message generation with various scenarios
-- Question generation for different yellow flag types
-- Feedback storage and retrieval operations
-- Definition loading and parsing
-
-**Example unit tests**:
-- Test red flag detection with explicit distress statements
-- Test yellow flag generation with ambiguous inputs
-- Test referral message includes all required components
-- Test feedback storage round-trip (save and retrieve)
-- Test multi-language support with sample inputs
-
-### Property-Based Testing
-
-**Property testing library**: Hypothesis (Python)
-**Minimum iterations per test**: 100
-
-**Property test requirements**:
-- Each property-based test must run minimum 100 iterations
-- Each test must reference its corresponding correctness property using format: `**Feature: spiritual-health-assessment, Property {number}: {property_text}**`
-- Each correctness property must be implemented by a single property-based test
-
-**Property test implementations**:
-
-1. **Test red flag detection** (Property 1)
-   - Generate random patient inputs with known red flag phrases
-   - Verify all are classified as red flags
-   - **Feature: spiritual-health-assessment, Property 1: Red flag detection completeness**
-
-2. **Test yellow flag questions** (Property 2)
-   - Generate random yellow flag classifications
-   - Verify each produces at least one question
-   - **Feature: spiritual-health-assessment, Property 2: Yellow flag clarification generation**
-
-3. **Test referral message completeness** (Property 3)
-   - Generate random red flag classifications with patient inputs
-   - Verify all referral messages contain required fields
-   - **Feature: spiritual-health-assessment, Property 3: Referral message generation for red flags**
-
-4. **Test feedback storage** (Property 4)
-   - Generate random feedback objects
-   - Verify all fields are stored and retrievable
-   - **Feature: spiritual-health-assessment, Property 4: Feedback storage completeness**
-
-5. **Test language consistency** (Property 5)
-   - Generate patient inputs in various languages
-   - Verify outputs match input language
-   - **Feature: spiritual-health-assessment, Property 5: Language consistency**
-
-6. **Test classification consistency** (Property 6)
-   - Generate random patient inputs
-   - Run classification multiple times
-   - Verify results are consistent within threshold
-   - **Feature: spiritual-health-assessment, Property 6: Classification determinism**
-
-7. **Test multi-category detection** (Property 7)
-   - Generate inputs with multiple distress indicators
-   - Verify all categories are detected
-   - **Feature: spiritual-health-assessment, Property 7: Multi-category detection**
-
-8. **Test feedback round-trip** (Property 8)
-   - Generate random feedback records
-   - Store and retrieve by ID
-   - Verify equivalence
-   - **Feature: spiritual-health-assessment, Property 8: Feedback persistence**
-
-### Integration Testing
-
-**Integration test scenarios**:
-- End-to-end flow: patient input → classification → referral → feedback
-- UI interaction: submit message → view results → provide feedback
-- Data persistence: multiple assessments → export to CSV → verify data integrity
-- Definition loading: parse PDF → load definitions → use in classification
-
-### Manual Testing
-
-**Clinical validation scenarios**:
-- Test with real patient conversation examples (anonymized)
-- Validate referral message quality with spiritual care team
-- Test multi-faith sensitivity with diverse scenarios
-- Verify UI usability with clinical staff
-
-## Deployment Considerations
-
-### Environment Setup
-- Python 3.9+
-- Gradio for UI framework
-- LLM API credentials (Gemini or alternative)
-- File system access for feedback storage
-
-### Configuration
-- LLM provider selection (reuse AIClientManager from Lifestyle Journey)
-- Spiritual distress definitions file path
-- Feedback storage directory
-- Logging level and output
-
-### Security
-- No PHI (Protected Health Information) stored in feedback
-- Provider authentication for feedback submission
-- Secure API key management
-- Audit logging for all assessments
-
-### Performance
-- Target: < 5 seconds per assessment
-- Concurrent user support: 10+ simultaneous users
-- Feedback storage: scalable to 10,000+ records
-- UI responsiveness: < 100ms for user interactions
-
-### Monitoring
-- Track classification distribution (red/yellow/none)
-- Monitor provider feedback agreement rates
-- Log LLM API performance and errors
-- Alert on system errors or degraded performance
-
-## Future Enhancements
-
-### Short-term
-- Export feedback data for analysis
-- Batch processing for multiple patient messages
-- Provider dashboard with accuracy metrics
-- Customizable distress definitions
-
-### Long-term
-- Machine learning model trained on feedback data
-- Integration with EHR systems
-- Real-time collaboration features for spiritual care team
-- Multi-modal input support (voice, text)
-- Predictive analytics for proactive spiritual care outreach

.kiro/specs/spiritual-health-assessment/requirements.md

@@ -1,142 +0,0 @@
-# Requirements Document - Spiritual Health Assessment Tool
-
-## Introduction
-
-The Spiritual Health Assessment Tool is a clinical decision support system designed to help healthcare providers identify patients who may benefit from spiritual care services. The system analyzes patient conversations to detect emotional and spiritual distress indicators, classifies them by severity (red flag or yellow flag), and generates appropriate referral messages to the spiritual care team. The tool includes a validation interface where clinical staff can review and provide feedback on the AI's assessments.
-
-## Glossary
-
-- **System**: The Spiritual Health Assessment Tool
-- **Provider**: Healthcare professional (doctor, nurse, etc.) using the system
-- **Patient**: Individual receiving healthcare services
-- **Spiritual Service**: The clinical spiritual care team (chaplains, spiritual counselors)
-- **Red Flag**: Clear indicators of severe emotional/spiritual distress requiring immediate spiritual care referral
-- **Yellow Flag**: Potential indicators of distress requiring further assessment questions
-- **Assessment**: The process of analyzing patient input to determine spiritual distress level
-- **Referral Message**: Generated communication to the spiritual service team about a patient's needs
-- **Validation Interface**: UI component where providers review and approve/reject AI assessments
-- **Feedback Record**: Stored data about provider agreement/disagreement with system decisions
-- **LLM**: Large Language Model (AI) used for analysis and message generation
-
-## Requirements
-
-### Requirement 1: Spiritual Distress Detection
-
-**User Story:** As a healthcare provider, I want the system to automatically detect signs of spiritual or emotional distress in patient conversations, so that I can identify patients who may benefit from spiritual care services without having to manually screen every interaction.
-
-#### Acceptance Criteria
-
-1. WHEN a patient message is submitted THEN the System SHALL analyze the text for emotional and spiritual distress indicators
-2. WHEN distress indicators are detected THEN the System SHALL classify them according to the predefined spiritual distress definitions
-3. WHEN multiple distress indicators are present THEN the System SHALL identify all applicable categories
-4. WHEN the analysis is complete THEN the System SHALL return results within 5 seconds
-5. WHEN patient input contains no distress indicators THEN the System SHALL return a classification indicating no spiritual care referral needed
-
-### Requirement 2: Red Flag Classification
-
-**User Story:** As a healthcare provider, I want the system to identify clear signs of severe emotional distress, so that patients with urgent spiritual care needs can be referred immediately.
-
-#### Acceptance Criteria
-
-1. WHEN patient input contains explicit statements of severe distress THEN the System SHALL classify the case as a red flag
-2. WHEN red flag indicators include anger expressions (e.g., "I am angry all the time") THEN the System SHALL detect and flag them
-3. WHEN red flag indicators include persistent sadness (e.g., "I am crying all the time") THEN the System SHALL detect and flag them
-4. WHEN a red flag is identified THEN the System SHALL generate a referral message to the Spiritual Service
-5. WHEN multiple red flag indicators are present THEN the System SHALL include all relevant indicators in the assessment
-
-### Requirement 3: Yellow Flag Classification and Follow-up
-
-**User Story:** As a healthcare provider, I want the system to identify potential signs of distress that require further exploration, so that I can gather more information before making a referral decision.
-
-#### Acceptance Criteria
-
-1. WHEN patient input contains ambiguous distress indicators THEN the System SHALL classify the case as a yellow flag
-2. WHEN a yellow flag is identified THEN the System SHALL generate clarifying questions to gather more information
-3. WHEN clarifying questions are answered THEN the System SHALL re-evaluate the classification based on the additional information
-4. WHEN yellow flag assessment is complete THEN the System SHALL either escalate to red flag or clear the concern
-5. WHEN generating clarifying questions THEN the System SHALL create questions that are empathetic and clinically appropriate
-
-### Requirement 4: Referral Message Generation
-
-**User Story:** As a member of the spiritual care team, I want to receive clear, informative referral messages about patients, so that I can understand their needs and provide appropriate support.
-
-#### Acceptance Criteria
-
-1. WHEN a red flag is confirmed THEN the System SHALL generate a referral message for the Spiritual Service
-2. WHEN generating a referral message THEN the System SHALL include the patient's expressed concerns
-3. WHEN generating a referral message THEN the System SHALL include the specific distress indicators detected
-4. WHEN generating a referral message THEN the System SHALL include relevant context from the conversation
-5. WHEN generating a referral message THEN the System SHALL use professional, compassionate language appropriate for clinical communication
-
-### Requirement 5: Validation Interface
-
-**User Story:** As a healthcare provider, I want to review the system's assessments and provide feedback, so that I can validate the AI's decisions and help improve the system over time.
-
-#### Acceptance Criteria
-
-1. WHEN the System completes an assessment THEN the System SHALL display the classification (red flag, yellow flag, or no flag) in the validation interface
-2. WHEN displaying an assessment THEN the System SHALL show the original patient input
-3. WHEN displaying an assessment THEN the System SHALL show the generated referral message (if applicable)
-4. WHEN displaying an assessment THEN the System SHALL show the reasoning behind the classification
-5. WHEN a provider reviews an assessment THEN the System SHALL provide options to agree or disagree with the decision
-6. WHEN a provider reviews an assessment THEN the System SHALL allow the provider to add comments or notes
-
-### Requirement 6: Feedback Storage and Tracking
-
-**User Story:** As a system administrator, I want to store provider feedback on AI assessments, so that we can track accuracy, identify patterns, and improve the system over time.
-
-#### Acceptance Criteria
-
-1. WHEN a provider submits feedback THEN the System SHALL store the feedback record with a unique identifier
-2. WHEN storing feedback THEN the System SHALL include the original patient input
-3. WHEN storing feedback THEN the System SHALL include the AI classification and reasoning
-4. WHEN storing feedback THEN the System SHALL include the provider's agreement/disagreement decision
-5. WHEN storing feedback THEN the System SHALL include any provider comments
-6. WHEN storing feedback THEN the System SHALL include a timestamp
-7. WHEN feedback is stored THEN the System SHALL persist the data in a structured format (JSON or database)
-
-### Requirement 7: Multi-faith Sensitivity
-
-**User Story:** As a spiritual care coordinator, I want the system to be sensitive to diverse spiritual backgrounds, so that referrals are appropriate for patients of all faiths including Christians, Buddhists, and others.
-
-#### Acceptance Criteria
-
-1. WHEN analyzing patient input THEN the System SHALL detect distress indicators regardless of religious affiliation
-2. WHEN generating referral messages THEN the System SHALL use inclusive, non-denominational language
-3. WHEN patient input mentions specific religious concerns THEN the System SHALL include this information in the referral
-4. WHEN generating questions for yellow flags THEN the System SHALL avoid assumptions about patient's spiritual beliefs
-
-### Requirement 8: Testing and Demonstration Interface
-
-**User Story:** As a clinical stakeholder, I want to test the system with various patient scenarios, so that I can evaluate its performance before deploying it in clinical workflows.
-
-#### Acceptance Criteria
-
-1. WHEN accessing the testing interface THEN the System SHALL provide a text input area for patient messages
-2. WHEN a test message is submitted THEN the System SHALL process it through the full assessment pipeline
-3. WHEN displaying test results THEN the System SHALL show the classification, reasoning, and any generated messages
-4. WHEN using the testing interface THEN the System SHALL allow multiple test cases to be run sequentially
-5. WHEN test results are displayed THEN the System SHALL provide clear visual indicators for red flags, yellow flags, and no flags
-
-### Requirement 9: Reference Data Integration
-
-**User Story:** As a system developer, I want to integrate the spiritual distress definitions and examples document, so that the AI has accurate reference material for classifications.
-
-#### Acceptance Criteria
-
-1. WHEN the System initializes THEN the System SHALL load spiritual distress definitions from the reference document
-2. WHEN analyzing patient input THEN the System SHALL use the loaded definitions as classification criteria
-3. WHEN the reference document is updated THEN the System SHALL support reloading the definitions without code changes
-4. WHEN definitions are loaded THEN the System SHALL validate the data structure and report any errors
-
-### Requirement 10: User Interface Design
-
-**User Story:** As a healthcare provider, I want an intuitive, easy-to-use interface, so that I can quickly test scenarios and review assessments without extensive training.
-
-#### Acceptance Criteria
-
-1. WHEN the application launches THEN the System SHALL display a clean, professional interface
-2. WHEN displaying results THEN the System SHALL use color coding to distinguish red flags, yellow flags, and no flags
-3. WHEN showing multiple assessments THEN the System SHALL organize them in a clear, scannable format
-4. WHEN a provider interacts with the interface THEN the System SHALL provide immediate visual feedback for all actions
-5. WHEN errors occur THEN the System SHALL display user-friendly error messages with guidance

.kiro/specs/spiritual-health-assessment/tasks.md

@@ -1,225 +0,0 @@
-# Implementation Plan - Spiritual Health Assessment Tool
-
-- [x] 1. Set up project structure and core data classes (REUSE existing patterns)
-  - Create spiritual_classes.py following existing dataclass patterns from core_classes.py
-  - Implement PatientInput, DistressClassification, ReferralMessage, ProviderFeedback using @dataclass with __post_init__
-  - Create data/ directory for spiritual_distress_definitions.json
-  - Reuse existing AIClientManager from src/core/ai_client.py (no new AI client needed)
-  - _Requirements: All requirements - foundational structure_
-  - _Reuses: core_classes.py patterns, AIClientManager, dataclass structure_
-
-- [ ]* 1.1 Write property test for data class validation
-  - **Property 1: Analysis execution for all inputs**
-  - **Validates: Requirements 1.1**
-
-- [x] 2. Parse and load spiritual distress definitions
-  - Extract definitions from PDF document into structured JSON format
-  - Create SpiritualDistressDefinitions class with load_definitions(), get_definition(), get_all_categories()
-  - Implement validation for definitions data structure
-  - Store parsed definitions in data/spiritual_distress_definitions.json
-  - _Requirements: 9.1, 9.2, 9.3, 9.4_
-
-- [ ]* 2.1 Write property test for definition loading
-  - **Property 23: Definition validation**
-  - **Validates: Requirements 9.4**
-
-- [x] 3. Implement spiritual distress analyzer core logic (FOLLOW existing assistant patterns)
-  - Create SpiritualDistressAnalyzer class with __init__(self, api: AIClientManager)
-  - Follow EntryClassifier/MedicalAssistant pattern: use self.api.generate_response()
-  - Create SYSTEM_PROMPT_SPIRITUAL_ANALYZER and PROMPT_SPIRITUAL_ANALYZER functions in spiritual_prompts.py
-  - Implement analyze_message() method returning JSON like EntryClassifier
-  - Parse JSON response and create DistressClassification object
-  - Implement conservative classification logic (default to yellow flag when uncertain)
-  - _Requirements: 1.1, 1.2, 1.3, 1.4, 1.5, 2.1, 3.1_
-  - _Reuses: AIClientManager, prompt patterns, JSON parsing approach_
-
-- [ ]* 3.1 Write property test for classification using definitions
-  - **Property 2: Classification uses definitions**
-  - **Validates: Requirements 1.2**
-
-- [ ]* 3.2 Write property test for multi-category detection
-  - **Property 3: Multi-category detection completeness**
-  - **Validates: Requirements 1.3**
-
-- [ ]* 3.3 Write property test for response time
-  - **Property 4: Response time performance**
-  - **Validates: Requirements 1.4**
-
-- [ ]* 3.4 Write property test for no-flag classification
-  - **Property 5: No-flag classification for neutral input**
-  - **Validates: Requirements 1.5**
-
-- [ ]* 3.5 Write property test for red flag detection
-  - **Property 6: Red flag detection for severe distress**
-  - **Validates: Requirements 2.1**
-
-- [ ]* 3.6 Write property test for yellow flag detection
-  - **Property 9: Yellow flag detection for ambiguous input**
-  - **Validates: Requirements 3.1**
-
-- [ ]* 3.7 Write property test for red flag indicator completeness
-  - **Property 8: Red flag indicator completeness**
-  - **Validates: Requirements 2.5**
-
-- [x] 4. Implement referral message generator (FOLLOW assistant pattern)
-  - Create ReferralMessageGenerator class with __init__(self, api: AIClientManager)
-  - Follow MedicalAssistant pattern for message generation
-  - Create SYSTEM_PROMPT_REFERRAL_GENERATOR and PROMPT_REFERRAL_GENERATOR in spiritual_prompts.py
-  - Implement generate_referral() method using self.api.generate_response()
-  - Build prompts for professional, compassionate referral messages
-  - Ensure multi-faith inclusive language in system prompt
-  - Include patient concerns, indicators, and context in user prompt
-  - _Requirements: 2.4, 4.1, 4.2, 4.3, 4.4, 4.5, 7.2, 7.3_
-  - _Reuses: AIClientManager, MedicalAssistant message generation pattern_
-
-- [ ]* 4.1 Write property test for referral generation
-  - **Property 7: Referral generation for red flags**
-  - **Validates: Requirements 2.4, 4.1**
-
-- [ ]* 4.2 Write property test for referral message patient concerns
-  - **Property 12: Referral message includes patient concerns**
-  - **Validates: Requirements 4.2**
-
-- [ ]* 4.3 Write property test for referral message indicators
-  - **Property 13: Referral message includes indicators**
-  - **Validates: Requirements 4.3**
-
-- [ ]* 4.4 Write property test for referral message context
-  - **Property 14: Referral message includes context**
-  - **Validates: Requirements 4.4**
-
-- [ ]* 4.5 Write property test for inclusive referral language
-  - **Property 19: Inclusive referral language**
-  - **Validates: Requirements 7.2**
-
-- [ ]* 4.6 Write property test for religious context preservation
-  - **Property 20: Religious context preservation**
-  - **Validates: Requirements 7.3**
-
-- [x] 5. Implement clarifying question generator
-  - Create ClarifyingQuestionGenerator class
-  - Implement generate_questions() method for yellow flag cases
-  - Build prompts for empathetic, open-ended questions
-  - Limit to 2-3 questions maximum
-  - Ensure questions avoid religious assumptions
-  - _Requirements: 3.2, 3.5, 7.4_
-
-- [ ]* 5.1 Write property test for question generation
-  - **Property 10: Question generation for yellow flags**
-  - **Validates: Requirements 3.2**
-
-- [ ]* 5.2 Write property test for non-assumptive questions
-  - **Property 21: Non-assumptive questions**
-  - **Validates: Requirements 7.4**
-
-- [x] 6. Implement follow-up re-evaluation logic
-  - Add re_evaluate_with_followup() method to SpiritualDistressAnalyzer
-  - Implement logic to combine original input with follow-up answers
-  - Ensure re-evaluation escalates to red flag or clears to no flag
-  - _Requirements: 3.3, 3.4_
-
-- [ ]* 6.1 Write property test for re-evaluation
-  - **Property 11: Re-evaluation with follow-up**
-  - **Validates: Requirements 3.3, 3.4**
-
-- [x] 7. Implement multi-faith sensitivity features
-  - Add religion-agnostic detection logic
-  - Implement checks for denominational language in outputs
-  - Add religious context extraction and preservation
-  - Test with diverse religious scenarios
-  - _Requirements: 7.1, 7.2, 7.3, 7.4_
-
-- [ ]* 7.1 Write property test for religion-agnostic detection
-  - **Property 18: Religion-agnostic detection**
-  - **Validates: Requirements 7.1**
-
-- [x] 8. Implement feedback storage system (ADAPT TestingDataManager pattern)
-  - Create FeedbackStore class following TestingDataManager structure
-  - Implement save_feedback() with UUID generation (like save_patient_profile)
-  - Implement get_feedback_by_id() and get_all_feedback() (like get_all_test_sessions)
-  - Implement export_to_csv() following export_results_to_csv pattern
-  - Implement get_accuracy_metrics() for analytics
-  - Use JSON file storage in testing_results/ directory pattern
-  - Use atomic writes with temp files like existing code
-  - _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, 6.7_
-  - _Reuses: TestingDataManager patterns, JSON storage approach, CSV export_
-
-- [ ]* 8.1 Write property test for feedback storage with unique ID
-  - **Property 15: Feedback storage with unique ID**
-  - **Validates: Requirements 6.1**
-
-- [ ]* 8.2 Write property test for feedback completeness
-  - **Property 16: Feedback storage completeness**
-  - **Validates: Requirements 6.2, 6.3, 6.4, 6.5, 6.6**
-
-- [ ]* 8.3 Write property test for feedback persistence
-  - **Property 17: Feedback persistence round-trip**
-  - **Validates: Requirements 6.7**
-
-- [x] 9. Build validation interface with Gradio (REUSE existing Gradio patterns)
-  - Create spiritual_interface.py following gradio_app.py structure
-  - Reuse SessionData pattern for session isolation
-  - Implement tabs structure like existing app (Assessment, History, Instructions)
-  - Implement input panel with gr.Textbox following existing patterns
-  - Implement results display with gr.Markdown for color-coded badges
-  - Display detected indicators, reasoning, and generated messages in gr.Markdown
-  - Add feedback panel with gr.Checkbox and gr.Textbox for comments
-  - Implement history panel with gr.Dataframe like test results table
-  - Use session-isolated event handlers pattern from existing code
-  - _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 8.1, 8.2, 8.3, 8.4, 8.5, 10.2, 10.4, 10.5_
-  - _Reuses: gradio_app.py structure, SessionData, tab patterns, event handlers_
-
-- [x] 10. Integrate all components into main application (FOLLOW existing app structure)
-  - Create spiritual_app.py following lifestyle_app.py structure
-  - Create SpiritualHealthApp class similar to ExtendedLifestyleJourneyApp
-  - Initialize AIClientManager in __init__ like existing app
-  - Wire together analyzer, generators, and storage as class attributes
-  - Create process_assessment() method similar to process_message()
-  - Connect UI to backend using session-isolated handlers
-  - Reuse existing error handling patterns and logging setup
-  - Use existing .env configuration approach
-  - _Requirements: All requirements - integration_
-  - _Reuses: lifestyle_app.py structure, AIClientManager, error handling, logging_
-
-- [x] 11. Implement error handling and edge cases
-  - Add LLM API error handling with retry logic
-  - Implement data validation error handling
-  - Handle classification edge cases (ambiguous, empty input)
-  - Add storage error handling
-  - Implement user-friendly error messages in UI
-  - _Requirements: 10.5_
-
-- [ ]* 11.1 Write unit tests for error handling scenarios
-  - Test LLM timeout and retry logic
-  - Test invalid input handling
-  - Test storage failure recovery
-  - _Requirements: 10.5_
-
-- [x] 12. Add export and analytics features
-  - Implement CSV export functionality in FeedbackStore
-  - Add accuracy metrics calculation
-  - Create summary statistics for classifications
-  - Add provider agreement rate tracking
-  - _Requirements: 6.7_
-
-- [x] 13. Checkpoint - Ensure all tests pass
-  - Ensure all tests pass, ask the user if questions arise.
-
-- [x] 14. Create deployment configuration (REUSE existing setup)
-  - Reuse existing requirements.txt (no new dependencies needed - same Gradio, google-genai)
-  - Reuse existing .env setup (GEMINI_API_KEY, LOG_PROMPTS)
-  - Create spiritual_README.md following existing README.md structure
-  - Document spiritual-specific configuration (definitions file path)
-  - Reuse existing ai_providers_config.py for LLM provider configuration
-  - Add deployment notes referencing existing HuggingFace Space setup
-  - _Requirements: All requirements - deployment_
-  - _Reuses: requirements.txt, .env setup, README structure, ai_providers_config.py_
-
-- [ ]* 14.1 Write integration tests for end-to-end flows
-  - Test full pipeline: input → classification → referral → feedback
-  - Test UI interaction flows
-  - Test data persistence across sessions
-  - _Requirements: All requirements - integration_
-
-- [x] 15. Final checkpoint - Ensure all tests pass
-  - Ensure all tests pass, ask the user if questions arise.